I would like to add security at the Form level in encounters.
For example, a medical nurse cannot open the mental health clinician’s progress notes.
I can see a reasonably easy way to make this work using the Admin->Forms screen. All forms would, by default, not be restricted. This keeps the software functioning as-is without adversely affecting current installations or upgrades. In the case where a Form should have limited access an Admin can lock it down by role (clinician, front-office, etc) in addition to by user.
Jason, that would be a great added benefit. I recently created an additional demographics form to complement the default demographics. I made this additional demographics form via Mark’s formscript.pl. This form needs to be accessed by front desk personal. So I needed to find a way to allow front desk personal to have access to this additional demographics “encounter” form yet prevent them from accessing encounters from a physician or another health clinician.
Be careful not to re-invent phpGACL here. What you want to do is assign an ACO (access control object) to the thing that is to be protected (the form), and then in the form logic call acl_check() to make sure the user has access to that ACO.
hey,
Agree with Rod, I’d add more granularity to the patient note acos. There is sensitivity acos but not sure what they are used for (seems like encounters?) For example, the note writer could attach certain new acos to note, such as (could also have note create defaults ie psych notes always mental):
mental
sensitive
etc.
Then you’d stay in line with the gacl stuff, ie separate the role creating (what groups have access to certain acos) from the controlled items.
The author only thing will not be able to follow gacl very well. Can’t make an aco for every user. I guess you could flag with an authOnly aco, and then ensure the user will have to be the author and have access to the authOnly aco. I think author only is a useful addition (I think this is a CCHIT thing also), but should also make a way for an admin to see these (so not lost if author goes away). Could do this by having authOnly and authOnly_a (the second could be the all seeing aco that could then be assigned to the super admin) acos set to form if flagged for author only.
Adding new aco’s is straightforward, and to ensure it’s documented and including in releases/upgrades should incorporate in following files:
- Header notes of the library/acl.inc file
- acl_setup.php file
- acl_upgrade.php file
Is there any documentation on phpGACL that anyone can recommend other than the manual? The manual that comes with it goes into a detailed description using a Star Wars analogy. I follow that with no problem, but at the end, the author goes into the implementation and I get lost. I have looked at it a few times over the years that we have been using it and I still don’t totally get the specifics of the implementation. The end of the manual even says that it is incomplete and it appears that development on the project ended a while ago. I understand what an ACO and ARO are, but I don’t get what the other string are that make acl_check a 4 argument function (I know, in OpenEMR, it is 2 args because the ARO args come from the logged in user). I also cannot figure out how to get around in the phpGACL control panel and get anything done. It seems to take me around in circles. Using this control panel is barely explained in the manual. Maybe I am missing something, but I would like to make better use of acl if possible. Maybe there is a book out there or something.