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.
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.
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
- 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