This solution is based on a Client/Server relationship where the security subsystem is managing Access Control between the Client and the Server.. This diagram and definitions from the FHIR specification
|The consumer that is using a healthcare related system|
|The client application the user is using (application, mobile app, website, etc.)|
|The security system (authentication and access control)|
|The clinical/healthcare repository|
Notify that Break-Glass 'could' be used.This is not specifically necessary, as a user/system could always indicate that Break-Glass is being invoked. If it is not authorized, then this request would be rejected. If it is authorized by no new information then nothing more is returned. The problem is that without a way to notify that break-glass could be used, then the degenerate system results: Either normal RBAC, or it is always an emergency. Thus for true Break-Glass, one really needs a way to indicate that information is being withheld that could be accessed if Break-Glass was declared. Note that this notification should not be used when there is data being withheld that is not accessible under Break-Glass.
The way that is in the FHIR Specification today is to include in the OperationOutcome.issue.code the value "suppressed", with severity at "informational". This would indicate that for a normal request that the normal results were returned (Informational but suppressed). This does require that suppressed is not used for any other purpose. This is not obvious today, but could be an operational requirement in a specific environment, likely under some Implementation Guide.
As discussion on the FHIR mailing list have shown, not all operations can easily have both success and also have an OperationOutcome resource, so this model only works where OperationOutcome can be carried on the Response.
Indicate that Break-Glass is being used.On the Security-Labels page is a proposal for how to indicate that Break-Glass is requested. I don't recall reviewing this text, so it was a surprise when Grahame pointed it out to me. It seems odd to be on the Security-Labels page rather than the Security page. It doesn't even use a security label.
This solution proposes that a URI could be defined to indicate that "Break-Glass" is being requested. This URI is then represented in the HTTP Request as a web category .
I would see this as more experimental, but given that it is in the specification today, I must at least acknowledge that it is more than just something for people to experiment with and give us comments. That said, if you have comments, I would be very happy to receive them.
Audit Log that Break-Glass has been used.When Break-Glass is used it is important to record in the audit log that Break-Glass was used. This triggers the Privacy and Security office working with the Clinical Safety office to investigate if it was appropriate use of Break-Glass. In FHIR AuditEvent, there is a defined way to indicate that Break-Glass has been used. Benefit of basing this on ATNA. Here is the critical aspects:
AuditEvent.type --> 110113, Security Alert
AuditEvent.subtype --> 110127, Emergency Override Started
AuditEvent.recorded --> When it happened
AuditEvent.agent --> Who declared break-glass
AuditEvent.agent.location --> Where is this agent
AuditEvent.agent.policy --> Policy enabling break-glass
AuditEvent.outcomeDesc --> Free-text explanation of why
AuditEvent.purposeOfEvent --> Why break-glass(ETREAT)
Where an entry in AuditEvent.outcomeDesc, could carry the 'text' description that the user is prompted to enter. This is a common UX for Break-Glass, where the user must type in a free-text explanation of why they feel it is warranted to 'break-glass'.