I need to setup access controls per folder in the documents section. There are certain document categories I wish to make unavailable to lower permission users. Any developers think this is achievable, or do I need to use an all or nothing approach with access to the documents module?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It's a bit complicated as Document Folders are not individually managed and are not really folders at all, just entries in the documents table.
Current ACL is based on access to fixed features, menus, reports, modules etc and prevents the program from being run by the wrong user.
This is more like preventing access to certain data elements. Perhaps a general permission tool that uses Table/ID information like the e-sign does to filter reads/views from database? ie: prevent read if userid=X and Table=Y and record id=Z
Would only work for simple cases, complex joins would be a issue, but it might do the job.
--Tony
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'd love to tinker around with the code to see if there is a solution I could come up with, but I just don't have the time at the moment. I'm hoping to sponsor the development if someone feels this idea can be accomplished.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
A call to acl_check when the categories tree is built in this class file would allow filtering.
The most flexible thing to do would probably be to add a "restricted" column to the categories table and use that to indicate which categories aren't displayed.
Thanks for posting Dr. Lee. The ACL article has definitely expanded since the last time I checked.
To give a little more insight, I need a transcription only permission that will limit access to only the folders necessary to complete their job. The main folder I'm looking to deny access to is the billing folder. A workaround would be to deny access to the entire documents module and send dictation files/exam forms via email, but that just adds work. Also doesn't seem like the most HIPAA friendly way of doing things.
An alternative solution would be the ability to attach a pdf copy of EOBs directly to the transaction in the billing module. Then there would be no need to upload that information to documents. Thoughts?
Last edit: Frankie 2015-04-21
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
That will certainly come into play, but I'm specifically looking for the ability to deny access to document categories by way of the link on the demographics page. I actually completely forgot about accessing documents through the Encounter View, as I've disabled that on my installation.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If not the EOB route, then try the ACO for Documents. See above attachment.
Only 1 .php file for the insert statement:
if (!acl_check('patients','documents')) die("Access Denied.");
The other alternative is to try inserting into the Disallowed section:
$disallowed['doc'] = !(GLOBALS['allow_encounter_claims'] || acl_check('patients','documents'));
with this in the .php file:
require_once("$srcdir/acl.inc");
if (!acl_check('patients','documents')) die("Access Denied.");
Please remember to backup or create system image before working on production copy.
Last edit: fsgl 2015-04-22
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This functionality has been implemented and is ready for code-review.
I've done preliminary testing, and Frankie will hopefully report in soon with issues he finds when trying it out on his system.
In addition to hiding the categories, documents which are in restricted categories are not included in the listing of documents in the past encounters screen or in the patient_report screen.
Furthermore, when the controller is used to access a document directly, (e.g. if a user tries to use an arbitrary document id in the GET request) if the document belongs to a restricted category, an access denied message is generated rather than displaying the document.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Finally got a chance to look at this, and got to say, the code is hard to follow for someone who is not familiar with Knockout. As I noted in my review comment, there should be peer discussion before adding a new framework to the project.
I need to setup access controls per folder in the documents section. There are certain document categories I wish to make unavailable to lower permission users. Any developers think this is achievable, or do I need to use an all or nothing approach with access to the documents module?
It's a bit complicated as Document Folders are not individually managed and are not really folders at all, just entries in the documents table.
Current ACL is based on access to fixed features, menus, reports, modules etc and prevents the program from being run by the wrong user.
This is more like preventing access to certain data elements. Perhaps a general permission tool that uses Table/ID information like the e-sign does to filter reads/views from database? ie: prevent read if userid=X and Table=Y and record id=Z
Would only work for simple cases, complex joins would be a issue, but it might do the job.
--Tony
Short answer:
1. deny ACO, see attachment.
2. deny access to all 6 Categories.
Long answer.
Did not test secondary to an overdose of ACL tinkering.
Last edit: fsgl 2015-04-21
I'd love to tinker around with the code to see if there is a solution I could come up with, but I just don't have the time at the moment. I'm hoping to sponsor the development if someone feels this idea can be accomplished.
A call to acl_check when the categories tree is built in this class file would allow filtering.
The most flexible thing to do would probably be to add a "restricted" column to the categories table and use that to indicate which categories aren't displayed.
https://github.com/openemr/openemr/blob/master/library/classes/CategoryTree.class.php#L43
Thanks for posting Dr. Lee. The ACL article has definitely expanded since the last time I checked.
To give a little more insight, I need a transcription only permission that will limit access to only the folders necessary to complete their job. The main folder I'm looking to deny access to is the billing folder. A workaround would be to deny access to the entire documents module and send dictation files/exam forms via email, but that just adds work. Also doesn't seem like the most HIPAA friendly way of doing things.
An alternative solution would be the ability to attach a pdf copy of EOBs directly to the transaction in the billing module. Then there would be no need to upload that information to documents. Thoughts?
Last edit: Frankie 2015-04-21
Try EOB.
Last edit: fsgl 2015-04-21
That will certainly come into play, but I'm specifically looking for the ability to deny access to document categories by way of the link on the demographics page. I actually completely forgot about accessing documents through the Encounter View, as I've disabled that on my installation.
I like Kevin's suggestion (which is almost always the case). This could be done fairly easily by any of us in the "developer for hire" category.
--Tony
www.mi-squared.com
If not the EOB route, then try the ACO for Documents. See above attachment.
Only 1 .php file for the insert statement:
if (!acl_check('patients','documents')) die("Access Denied.");
The other alternative is to try inserting into the Disallowed section:
$disallowed['doc'] = !(GLOBALS['allow_encounter_claims'] || acl_check('patients','documents'));
with this in the .php file:
require_once("$srcdir/acl.inc");
if (!acl_check('patients','documents')) die("Access Denied.");
Please remember to backup or create system image before working on production copy.
Last edit: fsgl 2015-04-22
Test copy got an IV bolus of Narcan.
Tested fine.
See Documents for details & screenshots.
Last edit: fsgl 2015-04-22
https://github.com/yehster/openemr/commit/0e574ab0374f96857d28c54d72ae675227a52306
This functionality has been implemented and is ready for code-review.
I've done preliminary testing, and Frankie will hopefully report in soon with issues he finds when trying it out on his system.
In addition to hiding the categories, documents which are in restricted categories are not included in the listing of documents in the past encounters screen or in the patient_report screen.
Furthermore, when the controller is used to access a document directly, (e.g. if a user tries to use an arbitrary document id in the GET request) if the document belongs to a restricted category, an access denied message is generated rather than displaying the document.
Finally got a chance to look at this, and got to say, the code is hard to follow for someone who is not familiar with Knockout. As I noted in my review comment, there should be peer discussion before adding a new framework to the project.
Rod
http://www.sunsetsystems.com/
I added a commit note pointing to a bit of code that will take care of my objections.
Rod
http://www.sunsetsystems.com/