Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

I've seen referenced in literature the need to have a "break glass" mode in Healthcare IT applications. In this mode, the access controls in an application can be bypassed for an emergency when it is critical for a user to gain access to imaging data. Typically, the facility will have some sort of policy in place to justify using the mode after the fact.

I'm wondering if many facilities are demanding this feature in heathcare applications? I don't recall seeing this in many real applications.

share|improve this question

migrated from healthcareit.stackexchange.com May 1 '12 at 11:12

This question came from our site for healthcare IT professionals and solution providers.

7 Answers 7

up vote 14 down vote accepted

My healthcare organization uses Break The Glass with our EMR. I work on the IT side of things so I'm not sure how it applies to the clinicians, but for us it is setup so that if we access any patient record we are required to Break The Glass. In doing so we are forced to enter a comment as to why we need access to the record.

It's a good feature - with the introduction of the HITECH act, and of course with HIPAA, it is important to document why you went into a patient's chart.

As a patient, you have the right to request the names of all of the employees who accessed your medical record and you also have the right to know why they needed to see your chart. By forcing the Break the Glass feature, we as employees are forced to create this documentation. If we didn't have this documentation and a lawsuit was brought against my organization, the individuals who accessed the chart could be held liable if they cannot produce sufficient reason for entering the chart.

So in short, no it is not required, but it is an excellent way to mitigate risk - not only for your organization but for the individuals who can be held liable by HITECH and HIPAA.

share|improve this answer
2  
Similar system in place here. Though not called "break the glass", you have to self-actualize your access request if you attempt to access patient records outside your own ward (or patients deemed to be "yours", for various reasons). For attendings who roam between departments (for instance 'specialty' on call), this means clicking "to provide healthcare service" when they open the record. Similarly there are overrides for "for research", etc. Allowing for slightly (but only slightly) more meaningful post-access audits. –  andy Oct 27 '11 at 7:04

There is no broad requirement for that specific feature as far as I'm aware. However, as a medical application you will normally consider the hazards of the system and mitigations.

If one of your hazards is "can't get at the images when I need immediate access for emergency diagnosis" then it's quite likely that one of your mitigations would be a "break glass mode". I have certainly seen systems offering backdoor (non-GUI) access into the image archive for precisely this reason. As @Marshall Anschutz said, this all depends on how life-critical the image operations are.

I cannot comment as to the demand for this feature, but I think that falls secondary to the need for the feature from a safety perspective.

share|improve this answer

As a physician, even though I can think of situations where having immediate, unrestricted access to clinical information can be critical, I can't think of an "emergency break glass" feature as an absolute requirement for an electronic healthcare information system. The security risks of having unrestricted access are too high, and besides, think of the following: a similar feature is definitely not available with traditional, paper-based systems, and yet they are still used to good effect (if, for whatever reason, you can't access a physical record because it has been misplaced, or is otherwise "locked away" from you, that's it, and you'll have to make do just with what you have at hand).

In my opinion, having this kind of feature just adds an unacceptable security risk. The proper way of ensuring patient safety with timely and appropriate access to clinical information is by correctly instructing our systems' users in knowing and using our security and authentication measures.

share|improve this answer
3  
I agree with your first paragraph, but the general effect of rigid/inflexible access control systems is that they are circumvented. If the system does not provide for "on call"-specialists to self-actualize when they attend patients outside their own department, the solution is often to give them untethered access to everything, which is worse (IMO). –  andy Oct 27 '11 at 7:08

Personally, I always think of a "break glass" setup when considering the use of data in an emergency setting. Take an emergency room for example: in my mind, all ER doctors should be able to pull all records from the ER terminals. You handle issues by means of exception logging. If a patient's record is accessed without a check-in, then you can investigate after the fact. You don't lock-out access because they may have arrived in cardiac arrest and the triage desk never sees them.

Similarly, you keep a stack of valid and unassigned cards behind the nurses desk. If one of them is used and not assigned to a person within a few hours, you can investigate after the fact... but I wouldn't risk a scenario where a doctor loses his card and can't access data until requesting a new card from IT.

Access control is part of the solution. Good auditing and trigger rules make up the gap so that you don't stop something necessary. For a clinical setup, the 'all access' card deck might be the one you keep in a drawer and always investigate their use after the fact.

share|improve this answer

There may be a requirement such as this depending on the application; however, it is most likely limited to certain applications. i.e. heart monitoring devices in a hospital. Whereas, an electronic claims submission system would never have the requirement to allow modifying who submitted the claim by the normal end user, as that may violate the premise of such a system's security.

In short, this may be a requirement, but it depends on who the target end user is, and how life-critical the operation it performs would be.

share|improve this answer
    
I would expect "Break the Glass" mode to allow reading existing data, and possibly appending additional data -- which is different from modifying existing data. I wouldn't expect to see a "Break the Glass" mode for an electronic claims submission, which is not time-critical (no one will die if the claim is not submitted for another day or two), but I might expect to see it for read access to medical charts. –  D.W. May 2 '12 at 0:35

If such requirements exist (not arguing against them mind you) then we should inform creators of centralized systems. Many systems I have seen have very strict security policies in place, some will squarely lock you out if, say you mistype your password more than 3 times. the lockout occurs centrally such that even if we allow the user to bypass all out application`s security policies he will still be blocked from accessing the central database.

In some case it is not vitally important (least not directly) to access a patient`s current demographic information but getting the latest INR results however could be vital.

Personally I never had to implement such bypass. Most applications and systems I was involved with were never intended to be used in emergency situation so the situation never really came up.

However if I were to implement such measures I would keep a special thorough audit tracking log of all operations performed while under this mode.

share|improve this answer

In a former job our EMR was set up with "Break the Glass" for our VIP patients and all employees, you couldn't access their health record without clicking another box stating you understand your actions are being logged.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.