PCF_20: Should PCF include break-glass when there is no clear way to declare break-glass

[JohnMoehrke]

There is support in a Consent for provisions when break-glass is declared, and there are support for conveying break-glass between the decision and enforcement. However, there is no clear way to declare break-glass, or to inform a client that the user is authorized to declare break-glass and would get access to more data.

There are many ways envisioned to declare break-glass:

• oAuth access token request (ITI-71) includes the purposeOfUse of BTG, in addition to normal purposeOfUse (e.g. Treatment, Payment, Operations).
• oAuth access token request (ITI-71) has a user-interface that would ask the user to declare break-glass. Unclear when this user-interface would engage, as it clearly can't engage every request.
• some non-security method such as the http Category, as outlined in a dragon note on the FHIR specification
• indication given in FHIR OperationOutcome that some data was filtered that would not need to be filtered if break-glass was declared
• other non standard method

[slagesse-epic]

I think at minimum this capability should be moved to be Intermediate or Advanced. The fact that there is not currently a single, obvious way to declare break-glass implies that this capability is unlikely to be included in basic or "first step" privacy systems.

[JohnMoehrke]

Note that the use of BTG purposeOfUse in the IUA access control request could be one mechanism that we define. I think that this would need to be a change in IUA, not necessarily PCF.

I still might accept that this is a second generation goal.

[JohnMoehrke]

Note that break-glass needs comprehensive assessment:

• XUA and IUA support PurposeOfUse and that vocabulary does have BTG. So minimally they do already support it. Likely need flow outlined.
• Results returned that have been filtered, the client app is authorized for the data, and where the user has permission to break-glass but has not yet invoked break glass -- need some way to signal client that break-glass declaration might return different results?
  • Note that OperationOutcome can carry this, so it is more a defining it.
  • Alternative is there is no signal at all. Thus the clinician just needs to guess that break-glass might be useful. This may result in many unnecessary break-glass, and may result in non-break-glass when one might have been useful.
• when break-glass is declared audit logging needs to indicate why.
  • indicating why is likely a client side auditEvent thing, as there is no 'why' element in IUA/XUA today. Just a way to indicate BTG.
  • could update IUA/XUA to include channeling why. Seems this would be proper, but would also be a much broader change.
  • note that client is already trusted with the data, so it should be recognized as trusted to record the auditEvent
• break-glass policy environments need to administratively follow-up on each use of break-glass to assure it was following policy and necessary. This could be done with BALP, but might be useful to be profiled into BALP.