I was asked to explain how Break-Glass works. There is not a solitary answer, as the context is very important.
A method used by authorized clinical people to gain access to information that the patient has indicated they want held more confidential, when that clinician has made a medical assessment that there is a safety concern that the confidential information may help shed light.
- Used only in Treatment use-cases. It would be inappropriate for a Billing/Payment use-case to invoke Break-Glass.
- Not the Emergency-Room use-case. The Emergency-Room tends to focus on stabilizing the patient and this can often be done in complete absence of historic data. Further when data are available, the clinicians in the Emergency-Room tend to already be operating at elevated privilege.
- Used only by authorized users. Not all clinicians are going to be given this authority.
- Medical safety concern. The clinician is expected to be making a medical safety decision. This concern is often gathered as rational for invoking Break-Glass.
- Post analysis. Break-Glass events should happen very rarely, but when they do the Audit Log must be relied upon to provide transparency to the activities. Thus, the Audit Log might be more detailed during a Break-Glass activity. The activity of Break-Glass should cause a post analysis, where the Audit Log is examined for if the declaration of Break-Glass was necessary and appropriate.
- Patient Privacy Consent restricts some data for Treatment. Note that if no restrictions for Treatment are given, then Break-Glass doesn't apply as it would result in no additional data access.
- Patient Privacy Consent does not forbid Break-Glass. There are some settings where it is allowed for a patient to indicate they would rather suffer safety concerns than have the data exposed. Most settings don't allow this kind of thing, trusting their clinicians more.
In general there are a variety of ways to solve.
- Internal logic of the EHR. If the use-case does not need to extend outside of the EHR, then there is no need for a standardized solution.
- Some workflow mechanism. It is possible for Break-Glass to be supported in ways that have nothing to do with the Security layer. These solutions tend to treat Break-Glass as a pathway thru the other clinical flows.
- PurposeOfUse of BTG (Break-the-Glass). Typically, clinical flows use TREAT as the PurposeOfUse to indicate the request is triggered by a normal treatment use-case and that the data returned would be used for normal treatment use-cases. The BTG would be an additional PurposeOfUse to indicate that Break-Glass has been appropriately declared.
How does User know Break-Glass could be used?
- It is possible that there is no feedback mechanism. Thus, those with the authority to Break-Glass would simply declare Break-Glass when they "felt" that data might be being blinded that might have some impact on safety.
- The advantage of this is that the clinician is never presented with some indication. There have been incidents that some clinicians overly focus on the blinded data if they know that there are data that are blinded.
- The disadvantage of this is that unnecessary Break-Glass events will be declared. This disrupts the clinician's flow, forcing them to detect if the Break-Glass action gave them more data or not; and causes safety / privacy investigation of many Break-Glass actions.
- An advantage is that this does not require any additional detection logic on normal transaction requests, and does not have an atypical response.
- This approach might be useful as a steppingstone to a more mature solution.
- FHIR OperationOutcome. All responses to requests in FHIR can carry a OperationOutcome. The OperationOutcome could indicate that BTG could be used. This would be indicated with an issue in the OperationOutcome that is clearly just information / informational. But would require that there be some yet-to-be-defined code to indicate that Break-Glass may be useful
- The FHIR Bundle that is returned might have a Bundle.meta.security tag that indicates that some data were redacted (REDACTED). This is a Bundle security tag, as it is about the transaction results, and not about any specific data inside the Bundle (actually about data not in the Bundle). This tag would not be included for those users not authorized to declare Break-Glass.
- There might be a service request to see if data are blinded. Might be a simple service that returns true if some blinding rules are found in the patient's Consent.
- With OAuth, if the JWT was exposed (possibly thru an introspection API), then the conditions in the JWT might indicate if blinding rules are expected to be applied. This does not indicate they were needed to be applied, just that there are residual obligations to be enforced at the Resource Server / Enforcement Point.
- ???? I don't know of another method. There might be something in http? I don't know of anything that would be linked to OAuth or any profile of OAuth.
FHIR Technical Solutions for declaring Break-Glass
- OAuth. The OAuth flow could provide the User-Interface that the Clinician uses to request and get Break-Glass permission. The token issued would indicate normal or break-glass in some token opaque way (many tokens are opaque to all but the OAuth authority and the resource-service enforcement).
- OAuth using the BTG PurposeOfUse. There are JWT mechanisms for encoding PurposeOfUse in the JWT in the IHE Implementation Guide on using OAuth with FHIR.
- An advantage of this is also that the declaration of Break-Glass is later followed by a return to normal. Which tends to follow the flow seen at the Clinician side, meaning the clinician is not exposed to each FHIR request/response; they are presented with a set of data retrieved over many FHIR request/responses; they then declare a Break-Glass and then more FHIR request/responses happen.
- It is possible this is simply an AuditEvent that indicates that Break-Glass is declared. Thus the Enforcement Point would look to AuditEvent for a Break-Glass declaration that is outstanding.
- It is also possible that some other FHIR Resource is used.
- It is also possible that no FHIR Resource is used, but some non-FHIR mechanism
- Possibly OAuth Authorization Decision point
- This mechanism is not using security mechanism, so it should not be seen as a security solution. It would be very easy to hack the FHIR API to add this.
- Note this solution could also be used to carry the other PurposeOfUse indiators, like TREAT
I am so sorry that there is not one solution. I assert that the reason there is not one clear solution has to do with the very fact that there is not much discussion of this flow in public spaces. I think that if there were a public discussion, we could eliminate some of these with rational as to why they are not as good as others, and likely come up with solutions I have not thought of.