David,

1. BTG is a common healthcare concept. The Draft BTG profile seems to describe
a concept somewhat different. I've included a short paper which provides
definitions, descriptions and requirements for BTG and "emergency access" as two
distinct and different concepts within the healthcare domain. Here is a short
description from HL7's Access Control Service Functional Model:

"Break‐glass is named after the glass panel that protects a fire alarm. Everyone
in the building is authorized to use the fire alarm to report a fire, but the
ramifications of misuse are substantial. The fragile glass panel is sufficient
to avoid accidental triggering, and it forces the user to stop and think

before acting. In the context of this document, a “Break Glass” scenario
involves a situation where the access control policy will authorize the user to
access certain information or functionality, but only after the user attests
that one or more relevant conditions exist."

2. As described in the draft profile, the most important concept is that the
profile requires a BTG permission. This does not match the notion of BTG as
used in healthcare which is much more like a user controlled "gateway" much such
as a fire alarm. I'll explain by means of a use case:

In this healthcare scenario, a user is authorized to access patient records (has
appropriate permissions). Some records (e.g., VIP) are sequestered behind a BTG
barrier. A user attempting to access a VIP record will be presented with a
warning banner indicating that the record is protected and that access will
subject the user to increased auditing (and perhaps other controls such as
notifications to system admins). In any case, the requester has two options; 1)
abort or 2) continue. If 2) is chosen the record is presented. The
distinguishing characteristic is that no elevation of user permissions and no
special "BTG permission" is required, the user is already in the "clinician"
group authorized to view records. This is analogous to students in a high
school. They are all members of a group who are "authorized" to pull the fire
alarm. Doing so falsely will subject the student to discipline but the student
does not need the teachers authorization to pull the alarm when conditions
warrant.

This is distinguished from emergency access of the first kind (normal emergency
room operations). In emergency access #1, the context of the emergency
(significant harm or risk of death to the patient) needs to be presented so that
the access control system evaluates the appropriate policy set (e.g. A clinician
at one hospital may not be authorized access to records at another under normal
conditions of “treatment”). In emergency access #1, the XSPA SAML attribute
assertion profile provides an "Emergency Access" purpose of use attribute. This
purpose of use allows the PDP to select and evaluate the appropriate policy for
the "emergency" condition as opposed to normal "treatment". Again, it is not
the user permissions that are evaluated but the fundamental context of the
policy environment.

There is emergency access of the second kind which is a variation of emergency
access #1. In emergency access #2, the requester makes the request for
information under the purpose of use of treatment and clinical role.
Authorization to view the record under these conditions is denied (perhaps an
underlying privacy policy is being enforced). In response the clinician
responds by elevating permissions by asserting the “emergency role” in the XSPA
SAML Assertion profile thereby elevating privileges under the same POU of
“treatment” and overriding the original policy decision. In our work in HL7 we
have found the “emergency” role/permission unnecessary as POU has the added
benefit of putting in place (and managing) an emergency context vice a simple
role. Emergency #2 is probably closer to what is intended by the Draft BTG
profile but is significantly different from what is described above.

I believe additional discussion is warranted on the fundamental concepts of the
Draft BTG profile, first to ensure common understanding of the different forms
of access, the uses of policy, purpose of use and permission and second to
establish sound use cases that will sufficiently clarify the purpose and
conditions under which use of such a profile is warranted.

Regards, Mike Davis, CISSP

Department of Veterans Affairs

Office of Health Information

Security Architect

760-632-0294