Fine tuning delete capabilities for clinical users

Management and Administration
1

cmswest wrote on Wednesday, July 17, 2013:

Hello again fellow users. I’m hoping to fine tune a user’s access to enable the deleting of basically everything but the patient itself. Currently, this message is displayed for super users when clicking on the Delete button under the patient name:

Do you really want to delete patient ### and all subordinate data? This action will be logged!

Unfortunately in the hectic atmosphere of a medical there’s been a few times that yes has been mistakenly chosen. Too often this leads to time consuming sql database recovery from backups.

Any ideas?

2

tmccormi wrote on Wednesday, July 17, 2013:

Do not give users admin privileges. Only the user “admin” should be able
to do that.

Tony

3

yehster wrote on Wednesday, July 17, 2013:

Arguably, not even administrators should be able to delete, and things should be flagged “Entered in Error” instead. The “EIE” option was added for immunization entries, something similar for patient data would be a good feature. Then if done inadvertently to a patient, it would be easier to undo.

4

drkay wrote on Wednesday, July 17, 2013:

Tony- I’ve had to give my back office MAs admin privileges so they can make simple corrections, like if they type the weight in pounds in the kilogram section accidentally, then need to correct it. Is there another privilege level that allows them to correct their mistakes? If they can’t correct their errors, the growth charts become a mess!

5

fsgl wrote on Wednesday, July 17, 2013:

Hello, Stephen.

I presume the physicians in your practice are trying to edit the medical record and are hitting the Delete button in error.

Medical-legally this is problematic. If the EMR is your only record and should you need to defend yourselves in a legal proceeding, you don’t want to give the appearance of altering the medical record. You and your colleagues need to put addenda into the record to correct any entries. I believe that entries are time stamped so that is a pitfall also.

If the purpose is to mark the patient as having transferred out of your practice, it should not be so difficult to add another tab in Demographics for that purpose along side of the Misc tab for deceased patients.

I just took a look at the Demo. If the physicians in the practice sign in just with functions assigned only to that group, then Administration functions and the Delete button won’t be available, lessening the chance for mayhem.

The number of Physicians-Administrators should be limited and major changes should be reserved for the quiet part of the day. Too many cooks will spoil the soup and haste makes waste as you already know.

6

cmswest wrote on Wednesday, July 17, 2013:

This is happening in a similar manner to Dr Kay’s MAs; the ability to delete medications and problems to present a nice looking note is the over arching goal. I’m not sure the physician’s would accept a decision to use EIE even if it was available in the patient note.

7

yehster wrote on Wednesday, July 17, 2013:

A proper implementation of EIE should provide basically the same visual presentation as delete, with the exception of minor (hopefully unobtrusive) controls to allow for review.

8

fsgl wrote on Wednesday, July 17, 2013:

Medical Problems and Medications are understood be current listings. Deletion of resolved problems and discontinued medications is acceptable if this has been documented in the SOAP notes or as addenda.

Deletion of SAOP notes to give a “pretty” appearance makes the defense of the medical record almost impossible because plaintiff’s attorney would assert that the medical record has been tampered with, hence the defendant’s veracity has just gone out the window. Another aphorism about missing the forest for the trees.

9

yehster wrote on Wednesday, July 17, 2013:

Whether people are doing it this way or not, the “intended” mechanism for removing meds/problems from a listing is to set the “end date” which effectively flags them as inactive.

10

tmccormi wrote on Wednesday, July 17, 2013:

Technically nothing is really deleted as all the data and the action is stored in the log table and can be easily accessed and also recovered though not so easily.
–Tony

11

tmccormi wrote on Wednesday, July 17, 2013:

The clinician roles should give access to make edits and changes to medical data expect those tagged as security “High”. They should NOT need admin priveleges to do that, if they do then there is a ACL issue that needs fixing.
–Tony

12

drkay wrote on Wednesday, July 17, 2013:

OK, good to know. I downgraded them to clinicians.

What should we do if they document vitals on the wrong patient? They need to delete the whole form, or is there a better way to do that?

13

fsgl wrote on Thursday, July 18, 2013:

Retention of resolved medical diagnoses and discontinued medications for chronically ill patients with myriad co-morbidities would make it unwieldy and defeats the purpose of having a quick thumbnail sketch.

Meaningful Use calculations call for Current and Active Diagnoses and an Active Medication list. Keeping the old data would render errors if there is not a built-in mechanism for the exclusion of inactive items from the calculations.

14

yehster wrote on Thursday, July 18, 2013:


This is the code which is supposed to filter inactive entries based on end_date.
However, in examining the code now, I realize that there is a likely
bug for issues/meds that are resolved “during” a reporting period
since it only uses a single “target date.”

15

cmswest wrote on Thursday, July 18, 2013:

I believe that making an issue/problem/medication inactive does not prevent it from being listed in the printable report as I practiced on Phil Belford on the demo site. So without the ability to delete these if entered in error would result in a lot of work for the admin to keep up with clerical errors.

16

fsgl wrote on Thursday, July 18, 2013:

If you go->Administration->ACL->Access Control List Administration (advanced) and create a new group, Administrators “Lite”, giving physicians the ability to edit without the ability to delete a patient account, it would be ideal. The manual is the last tab.

The Access Control Object, Superuser, needs to be modified, so that deletion of a patient account is disabled. The subdivision of the Superuser functions is not readily visible and available, consequently it is unclear if deploying Access eXtension Objects would be of any use.

Another option is the creation of a new section, Account Deletion, placing it on the bottom of the Patient Summary screen and hiding the Delete button within this section with plenty of warning in red not to touch it. Presently the Delete button is too dangerously close to History/Report/Documents/Transactions/Issues for the comfort of the practice.

A third option is to move the Delete button to the upper right hand corner of the Patient Summary screen where it is less likely to be clicked accidentally.

17

fsgl wrote on Saturday, July 20, 2013:

Found this webpage, PhpGacl and Ranjith’s 1/25/2013 how-to.

It would make no sense to have the phpGACL module in the first place if the solution is only possible with code modification. An end user should be able to create a new Access Control Object, dig into it and disallow account deletion from the module alone. The problem is that neither the manual nor the Wiki tells us how to do it.

Brady did a lot of work on Access Control List Administration. If his ears are burning and because more help is needed for super fine-grained control, perhaps he will parachute in. If we’re at an impasse, emailing him may be in order.

18

drkay wrote on Monday, July 22, 2013:

OK, I gave all of my medical assistant (MA) staff “Clinician” and “Front Office” ACL privileges. Now, they can’t see notes entered by other staff. For example, the front office documents the exact type of (California) aid the patient is receiving in a LBF titled “Eligibility” for each visit. Now, no one other than administrators can see that form, so the back office doesn’t know what kind of vaccines to give the patient (VFC or private). Also, when the back office staff fills out a vitals form, no one except administrators can see the vitals/weight, etc.

What ACL level do I need to give my MAs so they can see these basic notes?

19

fsgl wrote on Monday, July 22, 2013:

Just logged on the Demo as Fred Stone, Clinician, and was able to view Insurance, Vitals and Clinical Notes as well as write Clinical notes. The Layout Based Visit Module is out of whack for the past few days, so did not try it.

See the Access Control List for Clinicians in the attachment.

20

bradymiller wrote on Wednesday, July 24, 2013:

Hi,

I was asked to address the following here:
“We’re stumped about how to disable patient account deletion while preserving the balance of Superuser functions.”

here is the code of that patient delete button:

  if (acl_check('admin', 'super')) {
   echo "<td style='padding-left:1em;'><a class='css_button iframe' href='../deleter.php?patient=" .
    htmlspecialchars($pid,ENT_QUOTES) . "' onclick='top.restoreSession()'>" .
    "<span>".htmlspecialchars(xl('Delete'),ENT_NOQUOTES).
    "</span></a></td>";
  }

Note this button access is controlled by the admin->super ACO, which is described here:
http://www.open-emr.org/wiki/index.php/Access_Controls_Listing#Superuser_-can_delete_patients.2C_encounters.2C_issues.28super.29

Note that the ACL stuff is extremely minimal at this point and really just scratching the surface of what phpGACL can do. Guessing that at some point in the future, there will be much more granularity (ie. hundreds of ACO keys and several more return values).

There’s not really a “correct” way to add aco’s. If you are thinking of adding one or more, then bounce the idea of of us and can we can let you know if it makes sense (or if expanding a current aco makes more sense etc.). The one thing to always ensure, though, is to think of an ACO as a key to unlock something and don’t add ACO’s that deny access; otherwise it just gets too confusing.

Sometimes can also incorporate cool things as is what is done in the add list widget ACO’s, which are easy to customize. Could consider something like this in the basic deleter script (for example, each item that can be deleted from there would be the id of an aco with a ‘delete’ return value; can then also use these in the related Delete links to hide the pertinent delete links). And when deleting a whole patient, then would want to ensure the user had delete privileges of all the elements that would be deleted in addition to the main delete patient aco. Anyways, just thoughts. Whomever does the actual work will get to dictate the direction/solution.

I think an important step simply documenting the function of the current ACO’s (which is why I started the above wiki page awhile ago). Then easier to figure out how to add new ACO’s. There is also a “versioning” mechanism for the gacl stuff, so that it is incorporated into the upgrading safely. Here’s some tips for developers on adding new aco’s: http://www.open-emr.org/wiki/index.php/PhpGacl#Adding_new_ACO.2FACLs

-brady
OpenEMR