I’ve been playing with phpgacl (http://phpgacl.sourceforge.net/) which has been discussed here earlier as a good/fast way to add access controls to OpenEMR.
It looks very do-able. The most important part seems to be coming up with a good protection model. That’s where I would like some feedback.
To move forward with this, we need to identify and categorize the different resources in OpenEMR that are to be protected. That is, given users and groups of users, what are the different things in OpenEMR to which access will be explicitly allowed or denied?
It’s not necessary to identify things that any user who can log in will be allowed to access. Neither is it necessary to identify functionality that will always be allowed or disallowed if some broader area is similarly allowed or disallowed. We want to be flexible, but not so much that we scare people away.
With the above in mind, here is a list that I came up with for the purposes of discussion:
Accounting section:
* Billing - add or modify
* Billing - view
* Reporting - any transactions
* Reporting - my transactions
* EOBs - data entry
Administration section:
* Calendar settings
* Database reporting
* Forms
* Practice Settings
* Users and groups
Thank you for start discussion about Access control to OpenEMR. Yes, it’s very important part of our system.
My quick answer.
First of all we are need define the basic structure of access control. For example, as start, I think that our system must be have the following groups:
1. Admins
2. Authorized Users
3. Registered Users
4. Unregistered Users (??)
Every user can have access to different components level (or as you wrote the section/module level). We are also need have the "Permission table" where every admin can change users rights. Every new Section/Module must be include into such table.
I think that it will give us more optimal and flexible decision.
Tekkno Genius - Yes of course, I forgot the superbill. That can go into the Administration section. Thanks.
Nikolai - phpgacl defines Access Control Objects (ACOs) which would correspond to the "things to be protected" which I listed, and also Access Request Objects (AROs) which are the users as you describe.
Definition and grouping of the AROs will be up to the users, and can be handled through the user interface that is part of phpgacl. The details of that do not affect the changes that we make to OpenEMR for access control, but we can dertainly discuss those also. For those we might have groups like: Administrators, Doctors, Assistants, Accounting, Front Office, etc.
Definition and grouping of the ACOs needs to be done in advance, and affects the software changes a great deal. That’s why I have started this discussion.
I have checked in a new module, library/acl.inc, as a starting point for OpenEMR’s interfacing to phpGACL. I suggest that anyone who is interested take a look at it.
This does not create a requirement to install or use phpGACL, nor does it change any current behavior in OpenEMR. What it does do is allow developers to start adding code to perform proper access checks where they are appropriate.
With or without such added code, OpenEMR should behave as it does currently if phpGACL is not installed.
By way of example, I have also modified interface/main/main_navigation.php to call the new access control API to determine if the Administration or Billing links should be displayed. So you might want to take a look at that also.
The general philosophy should be to not give the user the option of choosing an action for which they are not authorized; and if they attempt to do that action anyway (perhaps by direct entry of a URL), then it is appropriate to use something like a "die" statement to terminate the script.
Looks like I will have to write a bit of documentation now…