Pages

Tuesday, March 19, 2013

Healthcare: Fail Open vs Fail Closed

One of the specific sensitivities we have in healthcare when thinking through Privacy and Security is the issue of what happens during failures of the “access control infrastructure”. For example when a natural disaster takes out some component of the security layer, such as User-Authentication.

In industries like Banking, this is very simple, they ‘fail-closed’. That is they tell you that the computers are not working, so come back tomorrow. The delay in providing you banking services is acceptable relative to the unacceptable potential that providing inappropriate services would have. They view this as an overall risk assessment harmonizing various business risks.

There is a different model of ‘fail-open’, that is to allow access when there is a failure. An example is that emergency-exit doors will open in an emergency, and there is ramifications to using these doors when there is no emergency. This is a weak example of fail-open, but I use it as illustrative. The idea in fail-open is to allow something that under normal conditions would not be allowed. Another example is the ‘break-glass’ functionality that protects a fire-alarm button, or fire-extinguisher. One must ‘break-glass’ to get to these tools, but normally one can’t use them. Note that these use-cases are also related to human safety. Not all fail-open are related to human safety, but human safety is a large body of the use-cases that call for fail-open.

Many healthcare use-cases should fail-closed as well. In fact I think there are far MORE use-cases in healthcare that should fail-closed than people think there are. That is that too many times I hear people saying that in healthcare all ‘treatment’ use-cases should be considered to be overwhelmingly safety over privacy. This generalization is incorrect. The generalization in healthcare should start with the same presumption of fail-closed without overwhelming justification to fail-open.

The cases where healthcare should use fail-open are few, but important. These use-cases are those related to safety of the provider and patient. That is to say when the failure to provide services will cause more damage to the provider or to the patient than the possible security or privacy breach. This is not a trivial decision. What is important is that there needs to be overwhelming evidence that a fail-open decision is the right decision, otherwise the default action should always be to fail-closed.

Some examples where overwhelming evidence is available: For example where a wide scale disaster causes a facility wide emergency-mode. An example is a natural disaster. Where there is an administrative decision that the needs of the local population care are overwhelmingly in favor of any possible abuse that might happen without control. These are cases where the health information might be broadly viewable, these are cases where creation of specific orders are allowed broadly, such as simple prescriptions; yet other orders, such as reconstructive surgery might be forbidden.

Another example that is often used is when the healthcare provider has some professional judgment reason that they feel is overwhelmingly important to their treatment. This is often seen as a “break-glass” workflow. Or seen as this is a case where a doctor can override a patient privacy restriction. Often times this comes with required justification text to be written by the doctor. This often is constrained to view for a short period of time. Note that patient opt-out needs to consider if overrides should be allowed or not, there are indeed some patients that would rather die than have information exposed, when they are well informed this might be acceptable.

A similar example is when the system making the query is unable to provide a user-assertion that is good-enough. For example the user can’t be 2-factor authenticated because the fingerprint reader is broken, but is authenticated using lesser means. The system querying is highly authenticated using system-level-authentication (ATNA). This system level authentication could be evidence that the conditions are good enough. This is a judgment, not a general rule.

In all of these fail-open cases, an audit log covers recording details so that after things settle down and normal mode is returned that someone can be sure that the overwhelming evidence was indeed in place. If the overwhelming evidence was not in place, then the individual should be punished according to the organizations policy.

About Me

The information posted here are mine and not necessarily represent By Light Professional IT Services Inc. I am a Standards Architect specializing in Standards Architecture in Interoperability, Security, and Privacy for By Light Professional IT Services Inc. Primarily involved in the international standards development and the promulgation of those standards. Co-chair of the HL7 Security workgroup, a member of the FHIR Management Group, FHIR core team, and co-chair of IHE IT Infrastructure Planning Committee. Participate in ASTM, DICOM, HL7, IHE, ISO/TC-215, Kantara, W3C, IETF, OASIS-Open, and other. Was a core member of the Direct Project specification writing, authoring the security section, and supporting risk assessment. Active in many regional initiatives such as the S&I Framework, SMART, HEART, CommonWell, Carequality, Sequoia (NwHIN-Exchange), and WISHIN. Active in the Healthcare standardization since 1999, during which time authored various standards, profiles, and white papers.

Surely there are other copyright and trademarks that I should recognize, but everyone else seems to be reasonable; expecting readers of blogs know that I am not trying to claim or take ownership of their copyright and trademarks.