[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xacml] Draft BTG Profile
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 -----Original Message----- Dear List about a year ago we discussed the standardisation of the
Break The Glass response (see Seth Proctor's message of 17 Dec 2009) and
decided that a profile to standardise the BTG response would be useful.
Unfortunately Seth left Sun before we got around to writing it. Consequently Stijn Lievens and myself from Kent have
produced a first version (attached) for your consideration. I know its not in
the correct format yet, but we can fix that once the technical content has been
agreed. Comments appreciated regards David -- ***************************************************************** David W. Chadwick, BSc PhD Professor of Information Systems Security School of
Computing, University of Kent, Canterbury, CT2 7NF Skype Name: davidwchadwick Tel: +44 1227 82 3221 Fax +44 1227 762 811 Mobile: +44 77 96 44 7184 Email: D.W.Chadwick@kent.ac.uk Home Page:
http://www.cs.kent.ac.uk/people/staff/dwc8/index.html Research Web site:
http://www.cs.kent.ac.uk/research/groups/iss/index.html Entrust key validation string: MLJ9-DU5T-HV8J PGP Key ID
is 0xBC238DE5 ***************************************************************** |
HL7 Emergency Access Abstract.doc
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]