You may be familiar with Epic’s privacy tool called “Break the Glass”. In short, it forces users to think twice about the patient information they are about to access. It displays a security screen that requires users to enter the reason why he or she needs to access a record that has been marked sensitive. The goal is to prevent users from accidentally looking at or clicking into a record that they did not actually intend to access.
The name fits: don’t break the glass… unless it’s absolutely necessary.
Epic organizations that implement this feature are essentially applying an extra layer of security on specific records, which they deem extremely sensitive. The list of sensitive records could be created one-record-at-a-time, or applied across an entire department or floor (e.g. psychiatric units). Each time an employee accesses one of these sensitive records, it is recorded and sent to the privacy office.
It is not always clear what privacy officers should do with all of these escalated accesses. Should they audit every one of them?
If privacy officers are to audit each escalated access, there are some challenges they should consider:
There are many legitimate reasons why a provider would “Break the Glass” to access a patient’s record. What if there was an emergency? What if they had an appointment with that patient?
Massive amounts of accesses
The sheer volume of “Break the Glass” accesses can be overwhelming. Legitimate or not, it takes time to comb through the “Break the Glass” alerts.
All other non-protected accesses
To limit the number of “Break the Glass” accesses, hospitals often choose to deploy “Break the Glass” only on specific patient sub-populations. As a result, snooping or other inappropriate accesses to unprotected populations will never be detected.
In short, “Break the Glass” accesses can waste privacy officer time and overlook violations due to the massive number of accesses needing manual review. Moreover, privacy officers might miss violations because “Break the Glass” only protects subpopulations.
A critical question then remains for privacy officers: Is this small, albeit helpful, security measure enough to keep PHI secure?
To make “Break the Glass” more manageable, false positives must be drastically reduced or eliminated. Filtering false positives requires a system that considers clinical context: if the system can determine the clinical or operational reason why an access occurred (e.g., an appointment, medication, oncology treatment, etc.), the access is likely appropriate. By filtering appropriate accesses, there are fewer for manual review, thus saving privacy officers’ limited time.
Clinical context is not limited to Break the Glass alerts. Privacy officers can deploy similar filtering methods across the entire access log to identify high-risk accesses. This type of access monitoring with filtering allows privacy officers to go beyond static rules-based methods and investigate suspicious behavior that was previously buried in the data.
You can find more on that topic in my previous blog Under the HIPAA Radar.