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.
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.
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.
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.
Other Information
User Identity and Authentication
- IHE efforts in RESTful security
- Identity Proofing and Authentication -- Patient vs Provider
- Level setting on Level of Assurance
- What User Authentication to use?
- Authentication and Level of Assurance
Patient Privacy controls (aka Consent, Authorization, Data Segmentation)
- Defining Privacy
- Simple and Effective HIE Consent
- IHE - Privacy and Security Profiles - Basic Patient Privacy Consents
Access Control (Consent enforcement)
- Advanced Access Controls to support sensitive health topics
- Policy Enforcing XDS Registry
- IHE - Privacy and Security Profiles - Access Control
- Data Classification - a key vector enabling rich Security and Privacy controls
- Handling the obligation to prohibit Re-disclosure
- Access Controls: Policies --> Attributes --> Implementation
Audit Control
- Simplifying Security Audit Standards
- IHE - Privacy and Security Profiles - Audit Trail and Node Authentication
- Accountability using ATNA Audit Controls
- ATNA and Accounting of Disclosures
- ATNA audit log recording of Query transactions
- ATNA + SYSLOG is good enough
Good post, really. I particularly appreciated the last statement, that policy makers should base their trust-elevation policies (in a factor-lacking system) on a risk-assessment base. Usually they say that ``if you can't provide LoA4, you are not allowed, in any case''. Which is a bit unreasonable in my opinion.
ReplyDeleteWow, John, Excellent post. You have successfully changed my opinion towards the possibility that fail-closed can be a reasonable default in the health IT domain.
ReplyDelete