Difference between revisions of "ACL Fine Granular Control"

From OpenEMR Project Wiki
 
(216 intermediate revisions by 2 users not shown)
Line 1: Line 1:
=='''Introduction'''==
=='''Preface'''==
A practice, with staff performing a multitude of tasks, at some point, would  wish to delineate the degree of access to the various parts of OpenEMR.  Because the Navigation Menu is the nexus of all modules, it is this part of the application that users seek to customize access for staff, commensurate  with their duties.
A practice, with staff performing a multitude of tasks, at some point, would  wish to delineate the degree of access to the various parts of OpenEMR.  Because the Navigation Menu is the nexus of all modules, it is this part of the application that users seek to customize access for staff, commensurate  with their duties.


Ideally [[Adding_and_Removing_User_Permissions|changing permissions]] should be as simple as described in the Wiki article, but that is not the case.  Because [[Access_Controls_Listing|permissions]] tend to overlap and because each permission may encompass more functions than its stated title, fine granular control is difficult to achieve.   
Ideally [[Adding_and_Removing_User_Permissions|changing permissions]] should be as simple as described in the Wiki article, but that is not the case.  Because [[Access_Controls_Listing|permissions]] tend to overlap and because each permission may encompass more functions than its stated title, fine granular control is difficult to achieve.   


Adding to the complexity is the fact that new snippets need to be added to the relevant .php file.  Forum members are all too aware that, even with the help of developers, at least 2 pages of discussion are usually required to accomplish the task.  Fine tuning is possible with a healthy dose of patience.
Increasing the complexity is the fact that new snippets need to be added to the relevant .php file.  Forum members are all too aware that, even with the help of developers, at least 2 pages of discussion are usually required to accomplish one single task.  Fine tuning is possible with a healthy dose of patience.
   
   
There is an excellent explanation of ACL by the authors of the module.  It can be found by navigating from Administration->ACL-> Advanced link in the heading->Manual tab.  "Star Wars" ''aficionados'' will appreciate the analogy.
There is an excellent explanation of ACL by the authors of the module.  It can be found by navigating from Administration->ACL-> (Advanced) link in the heading->Manual tab.  "Star Wars" ''aficionados'' will appreciate the analogy.




Line 12: Line 12:




'''Two important concepts are:''' 
Two important concepts are ARO or Access Request Objects (the Group to whom access is granted) and ACO or Access Control Objects (functions to which access is being granted).


ARO = Access Request Objects (the Group to whom access is granted).
If a practice has many groups of ARO's beyond the default, it may be easier to start with the Front Office because it has the most limited access.  From that set of ACO's the practice can configure additional layers of ACO's.
ACO = Access Control Objects (functions to which access is being granted).
 
 
If a practice has many groups of ARO's beyond the default, it may be easier to start with the Front Desk because it has the most limited access.  From that set of ACO's the practice can configure additional layers of ACO's.
 
We will endeavor to add as many examples as possible, as they become available, to permit the user to do this on his own.  There will be many times when it is impossible not to ask for help in the Fora, so feel free .




Line 27: Line 20:
*Experiment on a test copy.
*Experiment on a test copy.


*<span style = "color:red;">'''Backup'''</span> before attempting on the production copy.  White screens tend to make even the most hardy amongst us faint with fear.
*<span style = "color:red;">'''Backup'''</span> or create a <span style = "color:red;">'''system image'''</span> before attempting on the production copy.  White screens tend to make even the most hardy amongst us faint with fear.
 


=='''Building Blocks'''==
=='''Elements'''==
In addition to the ACL module, the user must become familiar with the various aspects of the Navigation Menu, the Array and the Disallowed sections of the openemr/interface/main/left_nav.php that governs it and the .php files that generate the frames in question. (This can not be done in any of the Demo versions, this has to be done on your own local or hosted Open-EMR system)
The user must become familiar with the various aspects of the Menu, the Array and the Disallowed sections of openemr/interface/main/left_nav.php that govern the Menu, Globals settings, the Access Control Administration (Advanced) and the .php files that generate the frames in question.


===Menu===
[[Main_Screen_%26_Navigation_4.1.3#Navigation_Menu|Navigation Menu]] provides an in-depth look at the left side bar.  
[[Main_Screen_%26_Navigation_4.1.3#Navigation_Menu|Navigation Menu]] provides an in-depth look at the left side bar.  


To find the  " xxxxxxx.php " for the frame that is to be hidden:  right click in the frame -> choose:  "This Frame" -> "Open In Another Tab". The URL will give the path to the .php file.
===Left_nav.php===
 
This .php file that governs Left Navigation holds one of the two keys to denial of access.  


=='''Left_Nav.Php'''==
====Array====
===Array Section===
The Array section, shown below, describes most of what is listed in the Navigation Menu; but not all of it and at times beyond it.  Not everything in the Menu can be found here and, at the same time, Array addresses non-Menu functions.  Our task is to find the correct primary document (if available) for hiding the part of the Menu that is of interest to us.
The Array section, shown below, describes most of what is listed in the Navigation Menu; but not all of it and at times beyond it.  Not everything in the Menu can be found here and at the same time Array addresses non-Menu functions.  Our task is to find the correct primary document (if available) for hiding the part of the Menu that is of interest to us.




Line 48: Line 40:




Each of the documents has a short descriptor, a more detailed descriptor, information regarding reference point (whether global or about patients) and generally the location of the pertinent .php file.  Some of the documents are self-evident, while others are more opaque.  All will have comments in '''bold'''.
Each of the documents has a short descriptor, a more detailed descriptor, information regarding reference point (whether global or about patients or encounters) and generally the location of the pertinent .php file.  Some of the documents are self-evident, while others are more opaque.  All will have comments in '''bold'''.


*"'ros' => array(xl('Roster')    , 0, 'reports/players_report.php?embed=1')": '''Roster of players''', for Athletic teams '''Enable this in Globals -> Features -> Athletic teams.'''
*"'ros' => array(xl('Roster')    , 0, 'reports/players_report.php?embed=1')": '''Roster of players''', for Athletic teams; probably not relevant to most practices.


*"'cal' => array(xl('Calendar')  , 0, 'main/main_info.php')": '''Calendar for scheduling appointments'''.
*"'cal' => array(xl('Calendar')  , 0, 'main/main_info.php')": '''Calendar for scheduling appointments'''.
 
*"'app' => array(xl('Portal Activity')  , 0, '../myportal/index.php')": '''Patient Portal, if enabled'''.
*"'app' => array(xl('Portal Activity')  , 0, '../myportal/index.php')": '''Patient Portal, if enabled'''.


Line 100: Line 92:
*"'lab' => array(xl('Check Lab Results')  , 0, 'orders/lab_exchange.php')": '''Lab Exchange in Administration, Globals, Connectors'''.
*"'lab' => array(xl('Check Lab Results')  , 0, 'orders/lab_exchange.php')": '''Lab Exchange in Administration, Globals, Connectors'''.


*"'dem' => array(xl('Patient')  , 1,  "patient_file/summary/demographics.php")": '''Demographics section of Patient Summary'''.
*"'dem' => array(xl('Patient')  , 1,  "patient_file/summary/demographics.php")": '''Patient Summary, otherwise referred to as "Demographics"'''.


*"'his' => array(xl('History')  , 1, 'patient_file/history/history.php')": '''History tab of Patient Summary'''.
*"'his' => array(xl('History')  , 1, 'patient_file/history/history.php')": '''History tab of Patient Summary'''.
Line 147: Line 139:




===Disallowed Section===
====Disallowed====
If we can work from the Disallowed section, it would be great because it is less difficult to insert snippets here.
If we can work from the Disallowed section, it would be helpful.


[[File:Disallowed.png]]
[[File:Disallowed.png]]


=='''Hiding The Calendar'''==
There exist practices that don't want the Front Office to view the Calendar.  It is a rare occurrence because the Front Office is usually predominately responsible for booking appointments.  We will use this example because the exercise is fairly straightforward.


*Move the ACO, Patients, Appointments; to the right.
===Globals===
Because the Globals section of Administration in Left Navigation regulates many of the Menu items, settings from there are used to refine access.  Become familiar with these settings.
 
 
 
===ACO's===
If the user cannot find an appropriate ACO, chances are that it must be created ''de novo''.  This task can be accomplished from Access Control List Administration, (Advanced) link in the heading.  This will be described in more details below in the example about Reports.
 
 
===.Php===
Fine granular control of these functions is the main goal of this exercise.  Fine tuning cannot be achieved without knowing the path to the specific .php file.  To find the .php for the frame that is to be hidden, right click in the frame -> choose "This Frame" -> "Open In Another Tab".  The URL will give the path to the .php file.
 
 
=='''Methods'''==
There are essentially two ways to hide Menu items.  The first involves snippets from Globals, Array, Disallowed, an ACO and the specific .php file.  The second requires only a related ACO and the specific .php file.  By far the latter is the easier of the two, because less code changes and therefore less testing are needed.
 
An example of the first method is described in  hiding Calendar and Reports. The second method is used for the other examples.


[[File:No calendar1.png|center]]
An exception to the above is the restriction of clinical notes from non-attending physicians as discussed below in the section on Encounter.  The only action required of the user is to move the restricted ACO into the Inactive column.  No snippet insertion is necessary because the revelant .php file has the ACL checks built-in.




*Note that the Array section has a "cal" document,"'cal' => array(xl('Calendar'), ..."; so we have a fortuitous start.
=='''Denial'''==
The following examples of access denial will be arranged alphabetically for easy reference instead of the order in the Menu.


*Because the Calendar can be disabled from Globals, a statement must address this fact.  The second statement asks if the ARO has permission to view the Calendar.  Insert this snippet into Line 189 in the Disallowed section:


===Administration===
Access Control is fully functional for the various groups of ARO's, therefore fine granular control is available presently.  Should a new situation arise, wherein more control is requested by the community, we will elaborate at that time.


::<nowiki>$disallowed['cal'] = !(GLOBALS['disable_calendar');] || acl_check('patients','appointments','', 'write'));</nowiki>


[[File:No calendar2.png|center]]
===Calendar===
There exist practices that don't want the Front Office to view the Calendar.  It is a rare occurrence because the Front Office is predominately responsible for booking appointments.  We will use this example because the exercise is fairly straightforward.
 
*Move the ACO to the right.
 
[[File:Movecal1.png|center]]
 
 
*Note that that the Array section has a "cal" document,"'cal' => array(xl('Calendar'), ..."; so we have a fortuitous start.
 
*Note also the path is at the top of the screenshot, which helps to orient the user.
 
*Because the Calendar can be disabled from Globals, a statement must address this fact.  The second statement asks if the ARO has permission to view the Calendar. 
 
*Insert this snippet into Line 189:
 
 
::::<nowiki>$disallowed['cal'] = !(GLOBALS['disable_calendar'] || acl_check('patients','appointments','', 'write'));</nowiki>
[[File:Ohno1.png]]




Line 173: Line 198:
*The openemr/interface/main/calendar/index.php handles the Calendar.
*The openemr/interface/main/calendar/index.php handles the Calendar.


*Insert the 2 snippets:
::::require_once("$srcdir/acl.inc");
::::<nowiki>if (!acl_check('patients','appointment','','write')) die("Access Denied.");</nowiki>
[[File:Ncln.png|center]]
===Fees===
Should the Administrator decide that because Physicians are not involved in billing, this entire section of the Menu will be off-limits to that group. One or more of the subsections can be hidden.  If the user understands how to hide one subsection, then he is capable of hiding the balance.
*Move the ACO to the right.
[[File:No fee1.png|center]]
====Billing====
*In the script for the Billing Manager, insert the following:
::::if (!acl_check('encounters','coding_a')) die("Access Denied.");
[[File:Billing.png|center]]
===Messages===
Unless the practice consists only of the physician, most offices will find the Message Center useful.  Method two is deployed to hide it.  It is extremely difficult to use the more elaborate technique because there is no Global setting which can act as a "handle" for hiding.   
*Choose an ACO from Administration, which is generally reserved for Administrators.  It is ''unnecessary'' for the ACO to bear a direct relationship to the Message Center, merely one which is unlikely to be granted to the other ARO's.
*Insert this snippet:
::::if (!acl_check('admin','database')) die("Access Denied.");
[[File:Msg.png|center]]
===Miscellaneous===
Use the same technique to hide these items as deployed in Messages.
====Patient Education====
*Insert this snippet:
::::if (!acl_check('admin','database')) die("Access Denied.");
[[File:Pted.png|center]]
===Modules===
Modules have not been implemented; but when that has been achieved, use the simpler hiding technique.
===Patients===
Every practice will need access to Patients/Clients, but there will be situations wherein some modules should have restricted access.
====Documents====
It is not possible to hide an individual Category of the Documents Tab of the Patient Summary.  It is an all-or-none situation.
*Be certain that the ARO does not have the ACO, Patients, Documents.
[[File:Docs1.png|center]]
*Into openemr/controller.php insert this snippet:
::::if (!acl_check('patients','documents')) die("Access Denied.");
[[File:Docs2.png|center]]
====Encounter====
Should a user require sole access to his own clinical notes, but deny access for other users; the ACO, Encounters, Notes - my encounters, should be in the Active column; while Encounters, Notes - any encounters, must be in the Inactive column.  No snippet needs to be inserted.
[[File:5eh.png|center]]
====Encounter History====
New Encounter and clinical notes in past encounters will be off-limits if this ACO has not been granted.  Because the Administrative and Clinical tabs are still available, it may be necessary to hide Encounter History completely.
*Check that the ACO is in the Inactive column.
[[File:1eh.png|center]]
*Into openemr/interface/main/left_nav.php, insert:
::::<nowiki>$disallowed['enc'] = !(acl_check('encounters','notes_a','','write'));</nowiki>
[[File:6eh.png|center]]
*Into openemr/interface/patient_files/encounter/forms.php, insert:
::::require_once("$srcdir/acl.inc");
::::<nowiki>if (!acl_check('encounters','notes_a','','write')) die("Access Denied.");
</nowiki>
[[File:4eh.png|center]]
====EOB====
If Physicians have no responsibilities for billing, it would be unnecessary for this ARO to make entries in the EOB Posting Invoice.  A good choice for an appropriate ACO would be Encounters, Coding - anything.  Navigating to the frame of interest and opening that frame in another tab will inform the user that the path is openemr/interface/patient_file/history/encounters.php.
*Move the ACO to the right.
[[File:Codinga.png|center]]
*Insert this snippet:
::::if (!acl_check('encounters','coding_a')) die("Access Denied.");
[[File:Eobentry.png|center]]


*Insert the 2 snippets:




::<nowiki>require_once("$srcdir/acl.inc");</nowiki>
::<nowiki>if (!acl_check('patients','appointment','','write')) die("Not authorized!");</nowiki>
[[File:No calendar3.png|center]]


=='''Hiding Contributed Forms'''==
====Forms====
Despite the fact that the Front Office should not have access to forms like Review of Systems Checks and SOAP, it does.
Despite the fact that the Front Office should not have access to forms like Review of Systems and SOAP, it does.


*We are fortunate once again that the document, 'enc', exists in the Array section; permitting us to insert the following:
*The public document, 'enc', exists in the Array section; permitting us to insert the following:




::<nowiki>disallowed['enc'] = !(acl_check('encounters','notes','','write'));</nowiki>
::::<nowiki>$disallowed['enc'] = !(acl_check('encounters','notes','','write'));</nowiki>  


[[File:No form.png|center]]
[[File:No form.png|center]]
Line 195: Line 340:




::<nowiki>require_once("$srcdir/acl.inc");</nowiki>
::::require_once("$srcdir/acl.inc");  
::<nowiki>if (!acl_check('encounters','notes_a','','write')) die("Not authorized!");</nowiki>
::::<nowiki>if (!acl_check('encounters','notes_a','','write')) die("Access Denied.");  
</nowiki>
[[File:1ros.png|center]]


[[File:No form ros checks.png|center]]




[[File:Nosoap.png|center]]
*Note that this technique is similar to that employed in Encounter History, but specificity was achieved by the insertion of the second set of snippets to the targeted forms.




=='''Hiding Fee Sheet from Physicians'''==
===Procedures===
In practices where Physicians have no responsibilities for entering charges, the Administrator may wish to hide the Fee Sheet from this ARO.  Without the help of developers, this example would be very difficult for most users.
This example deployed the easier method for hiding one subsection.


*Move the ACO to the left.
[[File:No fee1.png|center]]


====Configuration====


*There is no useful public document; but a convenient snippet was found, to which was added:
*Insert this snippet:
 
 
::::if (!acl_check('admin','database')) die("Access Denied.");
[[File:Proc.png|center]]
 
 
 
 
===Reports===
This task tends to be more difficult because there are no ACO's except Financial Reporting as vehicles.  Although the listing of various reports will be visible, but access will be denied. 
 
The more elaborate technique is demonstrated to provide a mini-tutorial on adding ACO's.  Fine granular control can be had with the other way, but each of the 34 .php files will require snippet insertions.  On balance the "difficult" technique turns out to be more ''facile'' in this case.
 
*<span style = "color:red;">'''N.B.'''</span>  The process of creating new ACO's does not permit deletions in ACL Admin.  Any deletion will cause the loss of the ACL module entirely.  Additionally if the Disallowed section is configured incorrectly, Administration in Left Navigation will malfunction. It is strongly advised that a [[Macrium_Reflect_Backup_and_Recovery|system image]] be procured beforehand, should these two mishaps occur in a production copy.
 
 
====ACO's====
Go to  Aministration->ACL, click the (Advanced) link in the header.
 
*We need to create a new section first.  This is done by navigating from the ACL Admin tab and clicking the Edit button in Sections.
[[File:Adding.png|center]]
 
 
*Make the appropriate entries and click Submit.
[[File:Adding1a.png|center]]
 
 
*Click the Edit button under Access Control Objects.
[[File:Adding2.png|center]]
 
 
*Make the appropriate entries and click Submit.
[[File:Adding3.png|center]]
 
 
*At this point no ARO has the new set of Reports ACO's, so they must be granted.  Move the ACO's to the left for Administrators.
[[File:Admmv.png|center]]
 
 
*In this example Physicians will be denied.  Ensure that they have no access to Financial and other Reports.
[[File:Nomed1.png|center]]
 
[[File:Nomd.png|center]]
 
 
 
====Disallowed====
Despite the fact that there exists a public document, rep, in Array; a snippet cannot simply be inserted, because all users will be denied access to Reports.  The workaround is to employ a Globals statement.  Because many modules are regulated by Globals, it can be used to refine access.
 
*Check that both "Enable CQM Reporting" and "Enable AMC Reporting" are selected in Administration.Globals.
 
*Insert into /openemr/interface/main/left_nav.php Lines 189 to 194:
 
 
::::$disallowed['rep'] = !($GLOBALS['enable cqm reporting'] || $GLOBALS['enable amc reporting'] ||
::::acl_check('accounting', 'financial_reporting_m') || acl_check('accounting', 'financial_reporting_a') ||
 
::::acl_check('reports', 'clients') || acl_check('reports', 'clinic') || acl_check('reports', 'visits') ||
 
::::acl_check('reports', 'procedures') || acl_check('reports', 'insurance') ||
 
::::acl_check('reports', 'blank_forms') || acl_check('reports', 'services'));
 
[[File:Norprts.png]]
 
 
 
====.Php====
Mercifully it is not necessary to insert snippets into all 34 .php files under the Reports subsections, only to the three Blank Forms.
 
*Insert into openemr/interface/patient_file/summary/demographics_print.php, openemr/interface/patient_file/printed_fee_sheet.php and openemr/interface/patient_file/transaction/print_referral.php the following:
 
 
::::require_once("$srcdir/acl.inc");
::::if (!acl_check('reports','blank')) die("Access Denied.");
 
[[File:Bdemo.png|center]]
 
[[File:Bfs.png|center]]
 
[[File:Bref.png|center]]
 
 
 
=='''Grant'''==
This section will give examples of restoring access that had been previously hidden.
 
 
===Patients===
In general the Front Office has access to the Patient Summary but not to all the forms in Encounters.  It should not have access to such forms as SOAP and ROS.
 
 
====Code====
If the Front Office is responsible for entering charges and answering questions about a patient's ledger; the fact that the Code portion of the Visit History is hidden, renders the staff member's work inefficient.
 
[[File:Phx0.png|center]]
 
 
*To grant access; the ACO, coding_a, must be moved to the Active column.
[[File:Phx1.png|center]]
 
 
 
*Delete Lines 465 to 470 in openemr/interface/patient_file/history/encounters.php.
[[File:Phx2.png|center]]
 
 
*Change Line 518 to the following:
 
::::if ($auth_<span style = "color:red;">coding_a</span>) {
[[File:Phx4.png]]




::<nowiki>&& acl_check('encounters','coding_a'))</nowiki>


[[File:Nofee5.png]]
=='''Acknowledgment'''==


'''Stephen Waite''' of Case Management Solutions whose ''solutions'' are the exemplars of simplicity with elegance.


'''El Jefe''' whose single snippet ("special sauce") and support laid the foundation for this article. 


*In the Fee Sheet script, insert the following:




::<nowiki>if (!acl_check('encounters','coding_a')) die("Not authorized!");</nowiki>


[[File:No fee3.png|center]]


::::::::<span style = "color:green;">''If your head is not spinning after all these code changes, three cheers for you''!!!</span>


[[File:ThumbsUp.GIF|center]]






:::::::<span style = "color:green;">''If your head is not spinning after all these code changes, three cheers for you''!!!</span>








[[Category:User Guide 4.1.2]][[Category:User Guide 4.1.1]][[Category:User Guide 4.1.0]][[Category:User Guide]][[Category:Configuration Guide]]
[[Category:User Guide 4.2.0]][[Category:User Guide 4.1.2]][[Category:User Guide 4.1.1]][[Category:User Guide 4.1.0]][[Category:User Guide]][[Category:Configuration Guide]]

Latest revision as of 21:01, 17 March 2016

Preface

A practice, with staff performing a multitude of tasks, at some point, would wish to delineate the degree of access to the various parts of OpenEMR. Because the Navigation Menu is the nexus of all modules, it is this part of the application that users seek to customize access for staff, commensurate with their duties.

Ideally changing permissions should be as simple as described in the Wiki article, but that is not the case. Because permissions tend to overlap and because each permission may encompass more functions than its stated title, fine granular control is difficult to achieve.

Increasing the complexity is the fact that new snippets need to be added to the relevant .php file. Forum members are all too aware that, even with the help of developers, at least 2 pages of discussion are usually required to accomplish one single task. Fine tuning is possible with a healthy dose of patience.

There is an excellent explanation of ACL by the authors of the module. It can be found by navigating from Administration->ACL-> (Advanced) link in the heading->Manual tab. "Star Wars" aficionados will appreciate the analogy.


Explain.png


Two important concepts are ARO or Access Request Objects (the Group to whom access is granted) and ACO or Access Control Objects (functions to which access is being granted).

If a practice has many groups of ARO's beyond the default, it may be easier to start with the Front Office because it has the most limited access. From that set of ACO's the practice can configure additional layers of ACO's.


Advisory

  • Experiment on a test copy.
  • Backup or create a system image before attempting on the production copy. White screens tend to make even the most hardy amongst us faint with fear.

Elements

The user must become familiar with the various aspects of the Menu, the Array and the Disallowed sections of openemr/interface/main/left_nav.php that govern the Menu, Globals settings, the Access Control Administration (Advanced) and the .php files that generate the frames in question.

Menu

Navigation Menu provides an in-depth look at the left side bar.

Left_nav.php

This .php file that governs Left Navigation holds one of the two keys to denial of access.

Array

The Array section, shown below, describes most of what is listed in the Navigation Menu; but not all of it and at times beyond it. Not everything in the Menu can be found here and, at the same time, Array addresses non-Menu functions. Our task is to find the correct primary document (if available) for hiding the part of the Menu that is of interest to us.


Array5.png
Array2.png


Each of the documents has a short descriptor, a more detailed descriptor, information regarding reference point (whether global or about patients or encounters) and generally the location of the pertinent .php file. Some of the documents are self-evident, while others are more opaque. All will have comments in bold.

  • "'ros' => array(xl('Roster') , 0, 'reports/players_report.php?embed=1')": Roster of players, for Athletic teams; probably not relevant to most practices.
  • "'cal' => array(xl('Calendar') , 0, 'main/main_info.php')": Calendar for scheduling appointments.
  • "'app' => array(xl('Portal Activity') , 0, '../myportal/index.php')": Patient Portal, if enabled.
  • "'msg' => array(xl('Messages') , 0, 'main/messages/messages.php?form_active=1')": Messages Center.
  • "'pwd' => array(xl('Password') , 0, 'usergroup/user_info.php')": Password, under Miscellaneous.
  • "'prf' => array(xl('Preferences') , 0, 'super/edit_globals.php?mode=user')": Preferences, under Miscellaneous.
  • "'adm' => array(xl('Admin') , 0, 'usergroup/admin_frameset.php')": Users, under Administration.
  • "'rep' => array(xl('Reports') , 0, 'reports/index.php')": Reports, for Clients, Clinic, Visits and Financial.
  • "'ono' => array(xl('Ofc Notes') , 0, 'main/onotes/office_comments.php')": Ofc Notes, under Miscellaneous.
  • "'fax' => array(xl('Fax/Scan') , 0, 'fax/faxq.php')": Administration, Globals, Miscellaneous tab.
  • "'adb' => array(xl('Addr Bk') , 0, 'usergroup/addrbook_list.php')": Address Book under Miscellaneous.
  • "'orl' => array(xl('Proc Prov') , 0, 'orders/procedure_provider_list.php')": Providers under Procedures.
  • "'ort' => array(xl('Proc Cat') , 0, 'orders/types.php')": Categories of tests in Configuration under Procedures.
  • "'orc' => array(xl('Proc Load') , 0, 'orders/load_compendium.php')": Load Compendium under Procedures.
  • "'orb' => array(xl('Proc Bat') , 0, 'orders/orders_results.php?batch=1')": Batch Results under Procedures.
  • "'ore' => array(xl('E-Reports') , 0, 'orders/list_reports.php')": Electronic Reports under Procedures.
  • "'ppo' => array(xl('CMS Portal'), 0, 'cmsportal/list_requests.php')": CMS Portal.
  • "'cht' => array(xl('Chart Trk') , 0, '../custom/chart_tracker.php')": Chart Tracker under Miscellaneous.
  • "'imp' => array(xl('Import') , 0, '../custom/import.php')": New Documents for import, under Miscellaneous.
  • "'bil' => array(xl('Billing') , 0, 'billing/billing_report.php')": Billing module under Fees.
  • "'sup' => array(xl('Superbill') , 0, 'patient_file/encounter/superbill_custom_full.php')": Superbill under Visits, Reports.
  • "'aun' => array(xl('Authorizations'), 0, 'main/authorizations/authorizations.php')": Authorization under Miscellaneous.
  • "'new' => array(xl('New Pt') , 0, 'new/new.php')": New/Search under Patients/Clients.
  • "'ped' => array(xl('Patient Education'), 0, 'reports/patient_edu_web_lookup.php')": Patient Education under Miscellaneous.
  • "'lab' => array(xl('Check Lab Results') , 0, 'orders/lab_exchange.php')": Lab Exchange in Administration, Globals, Connectors.
  • "'dem' => array(xl('Patient') , 1, "patient_file/summary/demographics.php")": Patient Summary, otherwise referred to as "Demographics".
  • "'his' => array(xl('History') , 1, 'patient_file/history/history.php')": History tab of Patient Summary.
  • "'ens' => array(xl('Visit History'), 1, 'patient_file/history/encounters.php')": Visit History under Visits,Patients/Clients.
  • "'nen' => array(xl('Create Visit'), 1, 'forms/newpatient/new.php?autoloaded=1&calenc=')": Create Visit under Visits, Patients/Clients.
  • "'pre' => array(xl('Rx') , 1, 'patient_file/summary/rx_frameset.php')": Prescription module.
  • "'iss' => array(xl('Issues') , 1, 'patient_file/summary/stats_full.php?active=all')": Issues tab of Patient Summary.
  • "'imm' => array(xl('Immunize') , 1, 'patient_file/summary/immunizations.php')": Immunizations module of Patient Summary.
  • "'doc' => array(xl('Documents') , 1, '../controller.php?document&list&patient_id={PID}')": Documents tab of Patient Summary.
  • "'orp' => array(xl('Proc Pending Rev'), 1, 'orders/orders_results.php?review=1')": Pending Review under Procedures.
  • "'orr' => array(xl('Proc Res') , 1, 'orders/orders_results.php')": Patient Results under Procedures.
  • "'lda' => array(xl('Lab overview') , 1, 'patient_file/summary/labdata.php')": Lab Overview under Procedures.
  • "'tan' => array(xl('Configure Tracks') , 0, 'forms/track_anything/create.php')": Track Anything module, if enabled.
  • "'prp' => array(xl('Pt Report') , 1, 'patient_file/report/patient_report.php')": Report tab of Patient Summary.
  • "'prq' => array(xl('Pt Rec Request') , 1, 'patient_file/transaction/record_request.php')": Record Request in Transaction tab of Patient Summary.
  • "'pno' => array(xl('Pt Notes') , 1, 'patient_file/summary/pnotes.php')": Notes in Patient Summary.
  • "'tra' => array(xl('Transact') , 1, 'patient_file/transaction/transactions.php')": Transaction tab of Patient Summary.
  • "'sum' => array(xl('Summary') , 1, 'patient_file/summary/summary_bottom.php')": Summary under Patients/Clients.
  • "'enc' => array(xl('Encounter') , 2, 'patient_file/encounter/encounter_top.php')": New Encounter from Encounter History drop down menu.
  • "'erx' => array(xl('e-Rx') , 1, 'eRx.php')": E-Prescribe if enabled.
  • "'err' => array(xl('e-Rx Renewal') , 1, 'eRx.php?page=status')": E-Prescription renewal.
  • "'pay' => array(xl('Payment') , 1, '../patient_file/front_payment.php')": Payment under Fees.
  • "'edi' => array(xl('EDI History') , 0, 'billing/edih_view.php')": EDI History under Fees.
  • "'dld' => array(xl('Display Documents'), 0, 'main/display_documents.php')": Display from Documents tab of Patient Summary.


Disallowed

If we can work from the Disallowed section, it would be helpful.

Disallowed.png


Globals

Because the Globals section of Administration in Left Navigation regulates many of the Menu items, settings from there are used to refine access. Become familiar with these settings.


ACO's

If the user cannot find an appropriate ACO, chances are that it must be created de novo. This task can be accomplished from Access Control List Administration, (Advanced) link in the heading. This will be described in more details below in the example about Reports.


.Php

Fine granular control of these functions is the main goal of this exercise. Fine tuning cannot be achieved without knowing the path to the specific .php file. To find the .php for the frame that is to be hidden, right click in the frame -> choose "This Frame" -> "Open In Another Tab". The URL will give the path to the .php file.


Methods

There are essentially two ways to hide Menu items. The first involves snippets from Globals, Array, Disallowed, an ACO and the specific .php file. The second requires only a related ACO and the specific .php file. By far the latter is the easier of the two, because less code changes and therefore less testing are needed.

An example of the first method is described in hiding Calendar and Reports. The second method is used for the other examples.

An exception to the above is the restriction of clinical notes from non-attending physicians as discussed below in the section on Encounter. The only action required of the user is to move the restricted ACO into the Inactive column. No snippet insertion is necessary because the revelant .php file has the ACL checks built-in.


Denial

The following examples of access denial will be arranged alphabetically for easy reference instead of the order in the Menu.


Administration

Access Control is fully functional for the various groups of ARO's, therefore fine granular control is available presently. Should a new situation arise, wherein more control is requested by the community, we will elaborate at that time.


Calendar

There exist practices that don't want the Front Office to view the Calendar. It is a rare occurrence because the Front Office is predominately responsible for booking appointments. We will use this example because the exercise is fairly straightforward.

  • Move the ACO to the right.
Movecal1.png


  • Note that that the Array section has a "cal" document,"'cal' => array(xl('Calendar'), ..."; so we have a fortuitous start.
  • Note also the path is at the top of the screenshot, which helps to orient the user.
  • Because the Calendar can be disabled from Globals, a statement must address this fact. The second statement asks if the ARO has permission to view the Calendar.
  • Insert this snippet into Line 189:


$disallowed['cal'] = !(GLOBALS['disable_calendar'] || acl_check('patients','appointments','', 'write'));

Ohno1.png


  • The openemr/interface/main/calendar/index.php handles the Calendar.
  • Insert the 2 snippets:


require_once("$srcdir/acl.inc");
if (!acl_check('patients','appointment','','write')) die("Access Denied.");
Ncln.png


Fees

Should the Administrator decide that because Physicians are not involved in billing, this entire section of the Menu will be off-limits to that group. One or more of the subsections can be hidden. If the user understands how to hide one subsection, then he is capable of hiding the balance.

  • Move the ACO to the right.
No fee1.png


Billing

  • In the script for the Billing Manager, insert the following:


if (!acl_check('encounters','coding_a')) die("Access Denied.");
Billing.png


Messages

Unless the practice consists only of the physician, most offices will find the Message Center useful. Method two is deployed to hide it. It is extremely difficult to use the more elaborate technique because there is no Global setting which can act as a "handle" for hiding.

  • Choose an ACO from Administration, which is generally reserved for Administrators. It is unnecessary for the ACO to bear a direct relationship to the Message Center, merely one which is unlikely to be granted to the other ARO's.
  • Insert this snippet:


if (!acl_check('admin','database')) die("Access Denied.");
Msg.png


Miscellaneous

Use the same technique to hide these items as deployed in Messages.

Patient Education

  • Insert this snippet:


if (!acl_check('admin','database')) die("Access Denied.");
Pted.png


Modules

Modules have not been implemented; but when that has been achieved, use the simpler hiding technique.


Patients

Every practice will need access to Patients/Clients, but there will be situations wherein some modules should have restricted access.

Documents

It is not possible to hide an individual Category of the Documents Tab of the Patient Summary. It is an all-or-none situation.

  • Be certain that the ARO does not have the ACO, Patients, Documents.
Docs1.png


  • Into openemr/controller.php insert this snippet:


if (!acl_check('patients','documents')) die("Access Denied.");
Docs2.png



Encounter

Should a user require sole access to his own clinical notes, but deny access for other users; the ACO, Encounters, Notes - my encounters, should be in the Active column; while Encounters, Notes - any encounters, must be in the Inactive column. No snippet needs to be inserted.

5eh.png



Encounter History

New Encounter and clinical notes in past encounters will be off-limits if this ACO has not been granted. Because the Administrative and Clinical tabs are still available, it may be necessary to hide Encounter History completely.

  • Check that the ACO is in the Inactive column.
1eh.png


  • Into openemr/interface/main/left_nav.php, insert:


$disallowed['enc'] = !(acl_check('encounters','notes_a','','write'));
6eh.png


  • Into openemr/interface/patient_files/encounter/forms.php, insert:


require_once("$srcdir/acl.inc");
if (!acl_check('encounters','notes_a','','write')) die("Access Denied.");
4eh.png



EOB

If Physicians have no responsibilities for billing, it would be unnecessary for this ARO to make entries in the EOB Posting Invoice. A good choice for an appropriate ACO would be Encounters, Coding - anything. Navigating to the frame of interest and opening that frame in another tab will inform the user that the path is openemr/interface/patient_file/history/encounters.php.

  • Move the ACO to the right.
Codinga.png


  • Insert this snippet:


if (!acl_check('encounters','coding_a')) die("Access Denied.");
Eobentry.png



Forms

Despite the fact that the Front Office should not have access to forms like Review of Systems and SOAP, it does.

  • The public document, 'enc', exists in the Array section; permitting us to insert the following:


$disallowed['enc'] = !(acl_check('encounters','notes','','write'));
No form.png


  • Into each of script for the forms, insert these 2 snippets:


require_once("$srcdir/acl.inc");
if (!acl_check('encounters','notes_a','','write')) die("Access Denied.");
1ros.png


  • Note that this technique is similar to that employed in Encounter History, but specificity was achieved by the insertion of the second set of snippets to the targeted forms.


Procedures

This example deployed the easier method for hiding one subsection.


Configuration

  • Insert this snippet:


if (!acl_check('admin','database')) die("Access Denied.");
Proc.png



Reports

This task tends to be more difficult because there are no ACO's except Financial Reporting as vehicles. Although the listing of various reports will be visible, but access will be denied.

The more elaborate technique is demonstrated to provide a mini-tutorial on adding ACO's. Fine granular control can be had with the other way, but each of the 34 .php files will require snippet insertions. On balance the "difficult" technique turns out to be more facile in this case.

  • N.B. The process of creating new ACO's does not permit deletions in ACL Admin. Any deletion will cause the loss of the ACL module entirely. Additionally if the Disallowed section is configured incorrectly, Administration in Left Navigation will malfunction. It is strongly advised that a system image be procured beforehand, should these two mishaps occur in a production copy.


ACO's

Go to Aministration->ACL, click the (Advanced) link in the header.

  • We need to create a new section first. This is done by navigating from the ACL Admin tab and clicking the Edit button in Sections.
Adding.png


  • Make the appropriate entries and click Submit.
Adding1a.png


  • Click the Edit button under Access Control Objects.
Adding2.png


  • Make the appropriate entries and click Submit.
Adding3.png


  • At this point no ARO has the new set of Reports ACO's, so they must be granted. Move the ACO's to the left for Administrators.
Admmv.png


  • In this example Physicians will be denied. Ensure that they have no access to Financial and other Reports.
Nomed1.png
Nomd.png


Disallowed

Despite the fact that there exists a public document, rep, in Array; a snippet cannot simply be inserted, because all users will be denied access to Reports. The workaround is to employ a Globals statement. Because many modules are regulated by Globals, it can be used to refine access.

  • Check that both "Enable CQM Reporting" and "Enable AMC Reporting" are selected in Administration.Globals.
  • Insert into /openemr/interface/main/left_nav.php Lines 189 to 194:


$disallowed['rep'] = !($GLOBALS['enable cqm reporting'] || $GLOBALS['enable amc reporting'] ||
acl_check('accounting', 'financial_reporting_m') || acl_check('accounting', 'financial_reporting_a') ||
acl_check('reports', 'clients') || acl_check('reports', 'clinic') || acl_check('reports', 'visits') ||
acl_check('reports', 'procedures') || acl_check('reports', 'insurance') ||
acl_check('reports', 'blank_forms') || acl_check('reports', 'services'));

Norprts.png


.Php

Mercifully it is not necessary to insert snippets into all 34 .php files under the Reports subsections, only to the three Blank Forms.

  • Insert into openemr/interface/patient_file/summary/demographics_print.php, openemr/interface/patient_file/printed_fee_sheet.php and openemr/interface/patient_file/transaction/print_referral.php the following:


require_once("$srcdir/acl.inc");
if (!acl_check('reports','blank')) die("Access Denied.");
Bdemo.png
Bfs.png
Bref.png


Grant

This section will give examples of restoring access that had been previously hidden.


Patients

In general the Front Office has access to the Patient Summary but not to all the forms in Encounters. It should not have access to such forms as SOAP and ROS.


Code

If the Front Office is responsible for entering charges and answering questions about a patient's ledger; the fact that the Code portion of the Visit History is hidden, renders the staff member's work inefficient.

Phx0.png


  • To grant access; the ACO, coding_a, must be moved to the Active column.
Phx1.png


  • Delete Lines 465 to 470 in openemr/interface/patient_file/history/encounters.php.
Phx2.png


  • Change Line 518 to the following:
if ($auth_coding_a) {

Phx4.png


Acknowledgment

Stephen Waite of Case Management Solutions whose solutions are the exemplars of simplicity with elegance.

El Jefe whose single snippet ("special sauce") and support laid the foundation for this article.



If your head is not spinning after all these code changes, three cheers for you!!!
ThumbsUp.GIF
Retrieved from "https://www.open-emr.org/wiki/index.php?title=ACL_Fine_Granular_Control&oldid=21951"