Break glass (which draws its name from breaking the glass to pull a fire alarm) refers to a quick means for a person who does not have access privileges to certain information to gain access when necessary. Systems containing primary source data (information) for treatment, must develop, document, implement and test break glass procedures that would be used in the event of an emergency requiring access to ePHI. These systems must have a clearly stated and widely understood procedure for allowing access via alternate and/or manual methods.
The system administrator should document any actual emergency access for later audit & review. Typically, a special audit trail is created to monitor such access. Standard access controls should be established with sufficient rules to minimize the number of times break–the–glass needs to occur.
Break–glass is based upon pre–staged “emergency” user accounts, managed in a way that can make them available with reasonable administrative overhead. This solution can be used with a broad range of existing systems and architectures that require operators to login, such as with username and password, before access is granted. The break–glass intended to specifically cover emergency cases and should not be used as a replacement for a helpdesk.
User authentication system is a typical mechanism used to control and monitor access to sensitive data. It is designed to preserve security by restricting access. In clinical care, a delay in access is likely to disrupt patient care that may cause patient discomfort, injury or worse. For this reason HIPAA requires covered entities to have mechanisms in place that assure patient care is not impaired by problems with the user identification and authentication.
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:
The break–glass solution is based on pre–staged emergency user accounts, managed and distributed in a way that can make them quickly available without unreasonable administrative delay. This solution should be simple, effective, and reliable.
Emergency Accounts should be created in advance to allow careful thought to go into the access controls and audit trails associated with them. The following factors should be considered:
Pre–staged accounts need to be carefully managed to provide timely access when needed. Break–glass requires that the emergency–account details be made available in an appropriate and reasonable manner. These details may be provided on media such as a printed page, a magnetic–stripe card, a smart card or a token. Some distribution possibilities for break–glass emergency accounts include the following:
A best–practice would place the pre–staged emergency accounts into the responsible care of an individual. This Emergency Account Manager would be someone readily available during operating hours and one who understands the sensitivity and priority of the emergency accounts (e.g. a business manager, charge nurse or security officer). The distribution procedure would include a sign–out method requiring that an acceptable form of identification be provided. This identity would be recorded before the accounts are made available. Following such a procedure assures that activities performed using the emergency account may eventually be associated with an authorized individual, creates accountability and can assure non–repudiation.
The use of emergency accounts needs to be carefully monitored. The audit mechanisms should be used and a procedure defined to examine the security audit trails on a regular basis to identify any use of the emergency accounts. In addition, systems can alert the security administrator in the event an emergency account is activated. These enhanced capabilities are highly desirable, but they are not required for the break–glass mechanism to work. If the system or application software cannot provide an audit trail that shows simple account activity like login attempts, then the use of break–glass needs to be carefully considered before implementing. Break–glass may still remain a valid system, but it will require the use of a manual (e.g. paper–ink) log.
Documentation should describe the intended use of such accounts and the consequences of their inappropriate use. Details should be clearly documented and then communicated to the relevant workforce. It should be clear that all use of emergency accounts is closely monitored. A periodic review and retraining of staff should be done to make sure the break–glass procedure continues to be relevant.
Each use of an emergency account should be reviewed. The use of an emergency account may be valid, or it might indicate a malicious act. Unacceptable use needs to be recorded and acted upon. Frequent use may indicate problems with the normal user authentication mechanism. This regular monitoring of pre–staged emergency accounts should also include exercising some of them to ensure that they do work, and that their use can be detected. This is similar to testing fire alarms, to be sure that they will work in a real emergency.
A procedure should be established to clean up after an emergency account has been used. Consider addressing the following:
Reference: This documentation was written using text from a whitepaper developed by the Joint NEMA/COCIR/JIRA Security and Privacy Committee (SPC) – December 2004.