Here we are going to discuss the Emergency Access procedure in OpenEMR and the technical requirements are described at the end.
We have framed the technical requirements based on our understanding and your comments are welcome…
**Introduction:**
The individual facility can describe the guidelines for an emergency situation. An emergency access solution should be used only when normal processes are insufficient (e.g. the helpdesk or system administrator is unavailable). Examples of situations when ‘break glass’ emergency access might be necessary:
• Forgotten Username/Password (e.g. after extended absence or vacation)
• Locked Password (e.g. mis-typed too many times)
• No User Account (e.g. a clinician from another organization or a new clinician is assisting a facility during an emergency)
• An emergency medical situation thrusts an individual into a role where s/he lacks sufficient access rights (e.g. an administrative assistant is entering orders during an emergency)
**Break glass procedure**
1. Creation of a break glass user account
This can be done while setting up the Facility in OpenEMR. Usernames must be meaningful (breakglass01) with strong password policy. Adding a new access control for break glass is required.
2. Distribution of break glass account – by the administrator or operation manager
3. Once the emergency account is activated, an alert should be sent to the administrator and the other top level people. All activities during the emergency period should be logged (regardless of the log level set)
4. Disable or delete the account after its use since the password is known.
5. The details about the break glass emergency access should be documented and then communicated to the relevant workforce.
**Technical requirements**
1. Creation of a new access control policy for break glass.
2. When the break glass policy is chosen while user creation, the account should be disabled by default. The email-ids of the persons who need to be intimated during an emergency situation can be obtained here.
3. When the break glass account is activated (during emergency situation), an automatic mail should be sent to the configured mail ids. While activation, the details like the person for whom the emergency access is given and the reason for the same can be specified.
4. Irrespective of the log level, all activities during emergency access should be logged
5. After the emergency period, the account should be deleted
When the "Emergency Situation" occurs, requiring someone to "turn on" the "breakglass" access is really no more reliable than the circumstance under which no help desk is available. Think about yesterday’s (9/11/09) anniversary. So it really has to be available from the outset. But once activated, it should have its password revised by the system administrator once the emergency need is passed, effectively resetting it so it is available for the next time.
Most banks and other sensitive data sites have an "emergency access" process which uses a "reminder" email to the email address of record, or sends a new temporary password. Might it not be better to allow Users to request a "cryptic reminder" at the login screen which will allow them to remember their actual password? I would suggest an absolute lockout if the entry attempt occurs more than three times in a single calendar day.
I can understand the need for an unlisted user to READ patient data and login under the "breakglass" protocol. But is not WRITING to that record without having been listed as an authorized user an invitation to unauthorized access, itself a violation of the same HIPAA? It would seem to me a more appropriate configuration would be to have a "superuser" with full change capability, whose login details could only be accessed from a separate storage location on the machine via the use of the "breakglass" protocol. That way, an emergency user could rapidly be added to the authorized user group by anyone, but they would first have to jump through those two hoops. And all those activities would be logged. I have concerns about the usability of OpenEMR by someone who has never seen the system, and is in an emergency situation. Sometimes some data entry is worse than none.
Key to all of those, based on my experience with ISO and QS documents control, is the maintenance, access and dissemination of the emergency passwords. They must have a defined list of recipients which is maintained by the security administrator, they must be changed frequently, and most tricky; if you really want non-users to be able to access them, there must be an added security system to protect that, or the system is just as open as if NO security was involved. And the converse of that is true also; unless those who might need to know of its availability could access it when it actually is appropriate, it is worthless. That is a pretty tall order to deliver on both.
I envision a ‘break glass’ situation where the special user is essentially a full admin of the system. So, no new software needs to be written. This can be handled entirely through business process.
If we’d like it to be made clear to OpenEMR users or IT departments, then we should add some content to the install/upgrade documentation and perhaps even an on-screen prompt to create a special ‘break-glass’ user.
More to the point… I think it’s important for these discussions to restate the actual wording of the original requirements, and where they refer to other documents (such as HIPAA) to state the relevant referred-to wording.
Otherwise we’ll become embroiled in everyone’s personal opinions of what constitutes good security, and lose focus on the goal of producing certifiable software.
This belongs to 164.312(a)(2)(ii) section of HIPAA (under Technical Safeguards) and the purpose is to "Establish (and implement as needed) procedures for obtaining necessary electronic protected health information during an emergency"
FYI,
Break the Glas is more of a business practice, with support from a technical component. It requires setting up accounts that are to be used in an emergency. From a technical standpoint these accounts should be monitored, but then again for security purposes, an audit trail should be provided so that every account can be monitored.
The Break Glass Accounts should be set to the minimum privilege level necessary for function.
The Break Glass Accounts should have strong passwords.
Yale has published a very well written 'Break The Glass" paper at:
Hello Team,
We want to integrate audit log and emergency access procedure meaningful criteria into our application. Problem that we are getting here is that if audit log in globals.php is disabled ie $GLOBALS=0; and audit events are enabled ie
$GLOBALS=array(“patient-record”=>1, “scheduling”=>1, “query”=>1, “order”=>1, “security-administration”=>1, “backup”=>1, ) In this case only login ,logout and view logs are created whereas in test case report it is written that "all the events performed by break glass user are logged. For insert statements, check sum should generate and Under USER field, Breakglass user name should get log " .But this is not working , is there any other changes that we have to do for emergency access procedure.
We suppose you have chosen emergency username other than ‘Breakglass’ or ‘Emergency’ hence the issue. For emergency access procedure, the username should start with ‘breakglass’ or ‘emergency’.
For more information, please go through the readme file of emergency user in Documentation folder.