Authorization Review - Click through

tmccormi wrote on Wednesday, December 23, 2009:

We just added the ability to 3.1  for the supervising Dr (or any authorizer)  to use the patient notes/authorization list to click thru to the encounter to review it prior to authorization.  This also logs the authorization at the encounter level instead of just the patient level.  

The log file record has the patient id in the comments and the encounter id in the notes… kludge but the log files are barely useful right now in any case.

The current code is a quick hack as the customer needed it, literally, right now.   So if people think it would be useful we’ll clean it up an post it.   Only authorization.php and logs.inc are effected.

-Tony

sunsetsystems wrote on Wednesday, December 23, 2009:

It sounds like a generally useful feature.  Why don’t you clean it up for posting to the SF development tip.

Rod 
(http://www.sunsetsystems.com/)

tmccormi wrote on Thursday, December 24, 2009:

The physician was thrilled this morning ….  will do.

Tony

tmccormi wrote on Monday, January 04, 2010:

During the use of this change we have discovered what I consider to be a very big hole in this process.  So I posted as much on the Help forum, but have not gotten any feedback.  Here is the gist of what is required on a role basis:

Role 1: Med Tech - can only enter New Encounter/Chief Compliant and Vitals. Should not have even read access to the rest of the medical forms (SOAP2, ROS, etc)

Role 2: Nurse - can enter/edit selected forms included MTech stuff, like ROS and Nurse Evaluation but NOT SOAP. Does not have a calendar and cannot see authorizations for anyone.

Role 3: Nurse Prac - Must have a calendar for schedule appts and can enter/edit all medical form types. The NP encounters must be reviewed and authorized by the Supervising Physician

Role 4: Supervising Physician: This person is not onsite and needs to see and review and authorize ALL encounters. They do not have an appt calendar entry and are, therefore not ‘Authorized’ by have a “See Authorizations” setting of ‘ALL’

There are two issues:

1. The NP has to have a appt calendar,
    so they have to be Authorized, therefore their encounter will not list
    when the Physician logs in.
2. The supervisor does not need to (or want
    to) see the MedTech and Nursing
    encounters.  That is they are not
    “valid” until the NP finishes them
    and approves them.

What I think the solution should be:

1. Separate the ‘Authorized’ check box into Authorized, which means that the user can authorize encounter and notes AND ‘Calendar’ which means that show up on appointment calendar or not.
2. Then add a new field to the users table called: Authorizing Role.  This is just a selection of roles from the ACL table.
3. Update the authorization screen to show only the encounters/notes that were posted by a user whose Authorizer’s Role matches the logged in users Role.

Example:
  MedTech has a role (derived from Clinician) call MedTech, the Authorizer’s Role is Clinician
  Nurse Prac has the role Clinician and the Authorizer’s Role is Physician
  The Doctor has the role Physician and no Authorizer’s Role set.

1. The NP login shows the MEDTechs encounters and notes
2. The Dr login shows the NP’s encounters

What about that?

-Tony<br>www.mi-squared.com

tmccormi wrote on Monday, January 04, 2010:

Note: Just to be clear, by Role I mean Access Control Level setting. 

To see encounter and notes for authorization you need all of the following:

- Authorized = true
- See Authorizations = Only Mine, ACL Role or All
- Your ACL Role must match the encounter/note post user Authorizer’s ACL Role.

<br>
Note the addition of ACL Role to the See Authorizations list.  That may be redundant, but it might not.  Only Mine and All would override all ACL settings, perhaps.

sunsetsystems wrote on Monday, January 04, 2010:

Trying to be more clear - does “Role” mean phpGACL ARO group name?

(In phpGACL terminology, ARO means Access Request Object, the “things requesting access”, normally users.  They can be organized into groups such as Physicians, Clinicians, Accounting, etc.)

Offhand your suggestion sounds reasonable, especially if multiple roles may be selected (in which case “See All” is not necessary).  Might be good though, for some docs to comment.

Rod 
(http://www.sunsetsystems.com/)

tmccormi wrote on Monday, January 04, 2010:

Yes Role = phpGACL ARO group name.   I don’t see why have multiple possible “Authorizer ACL Roles” would be a problem.

tmccormi wrote on Tuesday, January 05, 2010:

OK, just to let you all know how this is proceeding.  The customer needed a much shorter term fix (ie: tonight) than the problem warrants.  So here is what we did.  It has it limitations, but I think it will do the trick for now.  The fix is really a change to the appointment scheduling system to make it not care if the Nurse Practitioner is NOT authorized.   That way all the NPs stuff needs to be seen by the Dr that IS authorized, but does NOT need an appointment calendar.  We only patched the Outlook version.

We separated the Authorized into Authorized and Show Calendar and removed the requirement to be authorized in order to show up as a provider that can have appointments.

This and the click through stuff we already did makes an OK hack.

Here’s the list of changed files, just for your amusement, I guess…

alter table users add column calendar tinyint(4) not null default 0;

Changed files:

<pre>
A interface/main/main_info.php
A interface/main/calendar
A interface/main/calendar/add_edit_event.php
A interface/main/calendar/modules
A interface/main/calendar/modules/PostCalendar
A interface/main/calendar/modules/PostCalendar/common.api.php
A interface/main/calendar/modules/PostCalendar/pnuserapi.php
A interface/main/calendar/modules/PostCalendar/pntemplates
A interface/main/calendar/modules/PostCalendar/pntemplates/default
A interface/main/calendar/modules/PostCalendar/pntemplates/default/views
A interface/main/calendar/modules/PostCalendar/pntemplates/default/views/month
A interface/main/calendar/modules/PostCalendar/pntemplates/default/views/month/ajax_template.html
A interface/main/calendar/modules/PostCalendar/pntemplates/default/views/week
A interface/main/calendar/modules/PostCalendar/pntemplates/default/views/week/ajax_template.html
A interface/main/calendar/modules/PostCalendar/pntemplates/default/views/day
A interface/main/calendar/modules/PostCalendar/pntemplates/default/views/day/ajax_template.html
A interface/usergroup
A interface/usergroup/usergroup_admin.php
A interface/usergroup/user_admin.php
A library/auth.inc
A library/patient.inc
</pre>

tmccormi wrote on Tuesday, January 05, 2010:

As a side note (or two)  the Access Control Group should have an ‘Has Calendar’ permission instead of handling this outside of ACL.

The Authorization(more) link takes you to a different place with different CSS and display formatting just to remove the limit to the list of things on the lower pane to authorize.  That’s just silly.  Show All or (more) should just remove the limit and rerun the same code.

sunsetsystems wrote on Tuesday, January 05, 2010:

Tony, as I understand your description, the work you did to separate Authorized and Calendar was already done in July of last year.  Even down to the same users.calendar column name.  Check the 3.2 or 3.3 development demo.

Sorry I did not realize sooner that was what you were talking about.

Rod 
(http://www.sunsetsystems.com/)

tmccormi wrote on Wednesday, January 06, 2010:

Good to know, our customers use only released code (3.1) of course, so that’s where it had to be fixed.   I’m not in the habit of looking at code that I’m not using in production yet.  

However, this is just hack, not the real issue which is finer grain ACL and authorization process.