Hi
I can see that front desk user level has been given the access and update rights encounter details like vitals forms.
I want to restrict the forms update right from the front desk staff . I tried to work with ACL but not successful. Please advice me how to do this
Further I want to know whether is there any user level for the in house “pharmacist” because after the consultation pharmacist need to see the prescription and issue the drugs . I have used CAMOS for the prescription . If there is no special user level kindly tell me how you are practice this in your clinics.
This thread discusses fine granular control of ACL.
If a new ARO is created for Pharmacist, he can be granted the ACO, Pharmacy Dispensary. This would work from the Prescription module in the Patient Summary, not in CAMOS.
ARO = Access Request Objects/group to whom the access is granted.
ACO = Access Control Objects/type of access granted.
Excellent explanation found in Administration/ACL/Advanced (link to the right of the heading)/Manual.
The OP in the above cited thread had the Front Desk do billing. As a result, access to the New Encounter form was necessary. It’s not possible to enter a charge without creating a new Encounter.
Physicians/Clinicians in that practice were not responsible for billing, hence the objective of that thread was to hide both the New Encounter form & the Fee Sheet from these two ARO’s.
Yes hiding fee sheet from the Physicians/Clinician make sense but I wonder why "front desk staff have been given rights to update encounter details , vitals…etc
I want to remove those privileges from front desk user.
To effectively remove the ACO’s (despite them being in the Inactive column), one snippet is required for the left navigational side bar & a second set for each of the 4 forms in var/www/openemr/interface/forms, to the specific form then to the new.php file in that folder. See attachment for vitals.
Because I am uncertain of the exact syntax & placement of the snippets, a developer will have to jump in.
“By default the Front Desk should not have access to the 4 forms because the Encounter grouping is already in the Inactive column…”
According above statement I should not have access( as front desk user) to the Vitals from but my front desk user have … Kindly tell me what I have done wrong…
Please see the attachments
The problem is that the ACL module is not fully functional. That is the reason users have to go through the trouble of code changes. After using OpenEMR for 4 years, this process is still very difficult for me.
In your case we need a script in var/www/openemr/interface/main/left_nav.php to hide the 4 forms in the Menu & a “not authorized” statement for each of the forms in var/ww/openemr/interface/…new.php.
I notice that the second screenshot is localhost on Windows 7. Not hosted?
We need to know which OS because the paths are different.
Because I’m not a programmer & because code changes must be exact/precise, we need to wait for a developer to help with the snippets. If no response we can always ask for help directly.
Developers must be very busy at present, so I’ll take a crack at this.
Please try this out on a test copy first. If it does work, backup the production copy before attempting any code modifications.
There is a “disallowed” section in the left_nav.php file. I think inserting the snippet in Line 189 may work. See first attachment.
There needs to be a “Not authorized” statement in the denied form, such as Vitals. See attachment 2.
If other forms are to be made inaccessible, the same statement must be inserted in each of new.php file for that specific form. I think a good placement would be after the “require” statement.
For the new.php file, I think will need to require the acl library below the other require statements(this defines and allows use of the acl_check() function):
require_once("$srcdir/acl.inc");
If I can get beyond the crazy romanization that the Communists use in the PRC (c for t’z, q for ch, x for sh, etc.; give me Wade-Giles, any day!), perhaps I try adding an addendum to your ACL article.
Hiding stuff in the left navigational bar seems to be a popular topic. Unfortunately it is shrouded in big globs of mist & murkiness.
Thanks you very much fsgl and Brady
Yes its working fine and restrict front Desk user the access to vitals and other forms.
BUT It also RESTRICT the access to the setting up “APPOINTMENTs” by front desk.
As setting up appointment is essential function to the front desk please kindly help me to further modify the above script. (I’m testing these on local wamp server. Os windows 7 32 bit )
Thanks
If you still are having trouble backing up on the 32 bit device, have a look at this thread.
Sorry, Calendar access denial was not part of the plan.
I suppose I’m going to have to learn how to grep.
Will work on it when I get home.
Pimm,
I think I’m going to write a new article. The revisions & editing will be so extensive that I wish to spare Brady’s article all the trauma.
You’re right. Every ACO has a slightly different twist & therefore solution.
Won’t be able to get to it at the moment because more research is needed.
Pinyin (romanized Mandarin Chinese) is not very intuitive to learn even when one speaks the other major dialect. Can’t read Tang dynasty poetry in the original Classical Chinese without learning the modern stuff as well.
Hi All
Yes documentation is not much clear.So it;s great idea from pieter…
This may not be the correct forum but i would like to suggest developers to create few more user roles.
Pharmacist : as most of GPs clinics have their own pharmacy (I’m sorry I’m talking about my country and not sure about other areas … ) There is pharmacist/Staff person to issue drugs after the consultation.
So pharmacist user would be able to see the prescription of the encounter to issue the drugs
Laboratory Technicians : some GP clinics have their in house laboratory as well. So similar to above Laboratory use should be able to see the ordered procedures and feed the results manually.
Yes im still have the back up issue in both local server (windows 32) and hosted version (linux server)
Thanks for your reference I’ll check and update you.
This is a more reliable backup method for Windows & may circumvent 32 bit problem.
If you want redundancy by also backing up with built-in utility & are experiencing difficulties, please continue in the other thread. It gets confusing with cross posts in different threads.
Will response about the other ARO’s when I’m back in the office.
ACL is a challenge. the explanation in the manual is clear and precise. It shows where to go and what to expect.
Lot of experimenting and copy paste should give you any fine-tuning you need.
Administration => ACL => Advanced => Manual CLICK. Now go through the whole manual to understand the principals of permissions: Allow and Deny
Make your own new group. Start with allowing most things. Than slowly deny parts that are FORBIDDEN materials. (Their example of Captain, Crew and persons on a cruise ship is similar to an medical office) Sometimes the individual can view, but not change or touch, etc.
Remember, next to ACL it is just enough to talk with everybody in the office and explain why they should or should not take a peak at certain things. Also tell them everything is in a logfile. From time of login, till time of logout. The only weak part of login and logout is, if somebody knows the USERNAME AND Password and make a false entrance into OpenEMR. So everybody will be convinced to keep their username and password a secret. Change password on frequently intervals. (This can also made as an automatism in Globals => Security => Strong Passwords)
Good to read many Forum advises, given about Security on hosting sites. The fines are not pretty usually explained by heavy if you fail to do what is supposed to be done to secure medical information from spying eyes.
With EMR, the time of paper solution-file systems is gone. All seeming secrets should now be hidden for spying eyes, compared to the office of pre-EMR times it need a new mindset, but the old set with charts was not so bad as many try to show, it just needed dedicated people.