We need clinicians (and possibly the receptionists) to be able to read but not update the patient encounter forms as they answer patient calls. The default settings do not let anyone except physicians look at the encounter details.
When we add the authorization ‘Notes - Any encounters’ to the clinician group, they are able to see the forms created by the physicians and other clinicians. The side effect though is that they are also able to edit the details.
Is there a setting to let clinicians view the forms (e.g. SOAP) but not change them?
I see your issue. I have run into similar difficulties before.
You might have to dive into advanced phpGACL configuration by clicking on “advanced” within the ACL page. Here, if you do not have prior experience working with phpGACL, it is not going to be easy.
There is a phpGACL manual on the “advanced” page that will give you some guidance but I recommend you try this on a test installation first.
In future, maybe we can request our developers to expand the list on the ACL page to enable us control access more finely. This is because phpGACL is not easy for a starter-at least it wasn’t for me and i put the issue on hold for the time being.
It’s a bit more complicated than that. The Administration->ACL screen is all you should need. The Advanced stuff is only really for debugging or for developers whom want to 1) Add their own ACO’s or 2) require hierarchical user aco groups. If you can’t find the pertinent control in Administration->ACL, then that access control doesn’t exist in the codebase yet. As an example, look through the menu code interface/main/left_nav.php and you’ll see a bunch of acl_check() function throughout for example:
<pre><?php if (acl_check(‘admin’, ‘acl’ )) genMiscLink(‘RTop’,‘adm’,‘0’,xl(‘ACL’),‘usergroup/adminacl.php’); ?></pre>
The above only will allow access to the Administration->ACL link to users that have been given access to the Admin->acl ACO. So the access controls need to be developed at the codebase level and not simply placed in the advanced php-gacl GUI.
It’s a bit more complicated than that. The Administration->ACL screen is all you should need. The Advanced stuff is only really for debugging or for developers whom want to 1) Add their own ACO’s or 2) require hierarchical user aco groups. If you can’t find the pertinent control in Administration->ACL, then that access control doesn’t exist in the codebase yet. As an example, look through the menu code interface/main/left_nav.php and you’ll see a bunch of acl_check() function throughout for example:
<?php if (acl_check('admin', 'acl' )) genMiscLink('RTop','adm','0',xl('ACL'),'usergroup/adminacl.php'); ?>
The above only will allow access to the Administration->ACL link to users that have been given access to the Admin->acl ACO. So the access controls need to be developed at the codebase level and not simply placed in the advanced php-gacl GUI.
Why do user marked as provider automatically ‘Authorize’ encounters when just viewing the encounter.
I am currently testing OpenEMR with the intent of deploying it in a small practice.
However I have some questions about the authorization mechanism.
1. Only providers can appear on the calendar, so anyone who needs to scheduled has to be a provider…
…fine so far
2. Added users to groups such as Physicians and Clinicians
…. Fine so far
3. Set physicians to be able to authorize Encounters etc and Clinicians to be UNABLE to authorize anything
Now the problems start
1. When Clinicians create encounters the encounters are automatically authorized and sent to billing
the only way to stop this is to disable their provider status and therefore their calendar access.
Not Good from my perspective.
2 With Clinicians no longer marked as providers the Physicians need to do the Authorizations.
3. As soon as any user marked as Provider/Physician in this case, even views the Encounter or makes any changes to the fee sheet for example. The Encounter is again automatically ‘Authorized’ and sent to billing.
Is their a fix for this or some work around as it really is a major pain to have to go into the db to set the ‘authorized’ field to 0 if the user did not want to authorize the encounter etc.