Thursday, December 31, 2015

Blog review of 2015

I blogged half as many articles as last year, and yet my readership only dropped by 16%. I am amazed at all you loyal readers. I wish I had more than 28 blog articles this year to give you. Falling mostly in the category of FHIR, Consent/AccessControl, or De-Identification. I hope that they were useful. Thanks.

  1. Break-Glass on FHIR solution
  2. Break-Glass on FHIR
  3. HEART profiles for review, comment, and approval
  4. Building a MHD Client before MHD is DSTU2 aligned
  5. IHE updating FHIR Profiles to align with DSTU2
  6. FHIR Security initiatives
  7. FHIR does not need a deidentify=true parameter
  8. What is MHD beyond XDS-on-FHIR?
  9. Searching for an ATNA Audit Record Repository
  10. MHD Connectathon Results
  11. FHIR Security: Do (Not) Worry
  12. FYI: Update on the creation of Joint workgroup between #IHE and #HL7 including #FHIR topics
  13. IHE MHD and DSG now open for Public Comment
Consent & Access Control
  1. Guest Post: Use-Case - Security Audit Prompts Investigation
  2. Don't disassemble ATNA, what you are looking for is there.
  3. Where do I record the Reason that an auditable event happened?
  4. How to set the ConfidentialityCode
  5. Strawman on Consent Directive
  6. Privacy Principles
  7. Why Mutual-Authorized-TLS?
  8. TLS (not SSL) Connectathon trials and tribulations
  9. Applying CyberSecurity Standards to Medical Device Design
  10. FHIR Security initiatives
  11. FHIR does not need a deidentify=true parameter
  12. FHIR Security: Do (Not) Worry
  1. De-Identification for Family Planning
  2. NIST seeks comments on De-Identification
  3. Is it really possible to anonymize data?
  4. FHIR does not need a deidentify=true parameter
  1. Response to Keith's ask on my theory of Interoperability
  2. IHE FormatCodes are mandatory
  3. In Wisconsin we have Interoperability
  4. IHE MHD and DSG now open for Public Comment

Sunday, December 27, 2015

Break-Glass on FHIR solution

I explain the use-case and environment behind Break-Glass on FHIR. In there I explain that it is unusual to need Break-Glass, but that it is still an important capability in healthcare.  In this article I will outline a few solutions that exist, and hint at some other solutions.

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'.

Followed later, hopefully, by 110138, Emergency Override Stopped . This is not always possible to know, as not all user experiences are specifically session oriented. But often times the user experience is clear when the event starts and when it stops.

Future experimentation on Break-Glass

This is a good experimentation topic. I don't think the best solution has yet been found. So here are a few alternatives to play with. 

Using Security-Labels

The security-labels include the full vocabulary from the Healthcare Privacy and Security Classification System (HCS), so there are security tags that can be used to indicate for each Resource instance if it is "Normal" or "Restricted". Thus the data that falls into the "Break-Glass" use, would be marked "Restricted", while "Normal" (or less) would be available for "Treatment". 

This is the most likely way to identify information that should be blocked except for "Break-Glass", but is not specifically necessary. This solution does require well managed tags on all data.

Using OAuth for Break-Glass

One thought I have is to leverage OAuth 'scope'. In normal operation one would always ask for an OAuth token using a scope value that limits access to "Treatment", which would be 'normal treatment'. When needing to declare Break-Glass, one would ask for a OAuth 'scope' with "Emergency Treatment". In this way the OAuth authority can reject, because the user doesn't own the rights to Break-Glass, or if it does return the security-token it is an indication to the Server that Break-Glass has been declared and given to the user.

Using side-channel requests

A classic solution is to provide an alternative service that one could query to see if information would be suppressed. You would send the request  you would like to ask a Server, and you get back an indication of if information would be suppressed without Break-Glass. The problem this has is that it requires another round-trip.

ConclusionNot done yet... need experimentation and lessons-learned sharing... so please share.


Monday, December 21, 2015

Break-Glass on FHIR

Break-Glass is the term used for an exceptional case where a treating clinician is allowed to see information that the patient has asked be blinded. Recognize that break-glass is not an universally accepted use-case. Break-glass is specific to protecting safety of the patient or care-giver during treatment.

The first condition that leads to break-glass is that the Patient is given the ability to restrict access to some or all of their data for ‘treatment’ use-cases (PurposeOfUse==Treatment), and that patient has authorized ‘break-glass’. We clearly want to enable this use-case, and it is part of our current Privacy Consent Directive IG. (A work in progress, Note we are not limiting ourselves to treatment Privacy Consent, just haven’t gotten that far yet). The patient might have included in their “Consent” clauses that restrict this authorization (only specific individuals, only specific conditions, only at specific locations, not a specific individual, etc).

So given the context of the user request (who, what, where, when, why), we check the patients Privacy Consents on file (or defaulted into), to determine if there is anything needing to be blinded. If there is nothing that needs to be blinded, then no need for break-glass. This is most often because the consent doesn’t have any restrictions for treatment.– thus nothing special needed in the response to enable break-glass.

At this point we recognize that there is information that the Consent would have us blind from the user given the context of the request (who, what, where, when, why). So the next part is to determine if this user would be able to declare break-glass. Recognize that not all ‘users’ should be allowed to declare break-glass. This might simply be that licensed clinicians at the organization are authorized to declare break-glass, or might be only a subset of clinicians. So in addition to the normal Role-Based-Access-Control, there would be an additional ‘permission’ that would be necessary for a user to be able to declare break-glass. Thus lacking this permission, the FHIR Server would silently blind the user to any data that is restricted by Consent. – thus nothing special needed in the response to enable break-glass.

It is also possible at this point that what the clinician is doing is not a use-case that would call for break-glass. I don't have example handy, but this is related to the reasons why break-glass is not universally accepted as necessary or even useful. There have been cases where break-glass was supported, but they removed it because they found clinical practice was impeded by clinicians obsessing over the information that was blinded from their access, ultimately they chose to not tell clinician’s that information was blinded.

So, by this point we know there this is a use-case where break-glass applies, the patient has authorized break-glass, there is a need to blind some information from this user, and that the user does possess the permission to declare break-glass; so it is only now that we need to do something special. We have two cases that need some special handling:
  1. How do we know that the user has declared break-glass?
  2. How do we tell them that there is further information they could get if they declared break-glass?
No clear solution, although I could follow up in a smaller audience with some potential solutions using tags, parameters, oauth scope, UMA, alternate transactions, redirection workflow, etc. I encourage discussion, and experimentation. I might blog further on these potential solutions.

Any time break-glass is invoked the Audit Log must show this, as use of break-glass permission should be followed up by the Safety and Privacy officials to determine that it was appropriate.


Monday, December 14, 2015

De-Identification for Family Planning

 A project I participated in inside IHE applying the de-Identification handbook I helped create. Very important prototyping of this concept to an important topic. Many lessons learned and need to be learned wider. Checkout other blog posts I have on De-Identification

IHE IT Infrastructure Technical Framework Supplements Published for Public Comment

The IHE IT Infrastructure Technical Committee has published the following supplements to the IHE IT Infrastructure Technical Framework for public comment in the period from December 14, 2015 through February 5, 2016:
  • De-Identification for Family Planning (De-ID for FP)
  • Re-documentation Document Sharing Profiles Edition
The documents are available for download at Comments submitted by February 5, 2016 will be considered by the IHE IT Infrastructure Technical Committee in developing the trial implementation versions of the supplements. Comments can be submitted at IT Infrastructure Public Comments.

The committee has also published the following white paper for public comment in the period from December 14, 2015 through February 5, 2016:
  • Analysis of De-Identification Algorithms for Family Planning Data Elements
The document is available for download at Comments submitted by February 5, 2016  will be considered by the IHE IT Infrastructure Technical Committee in developing the subsequent version of the white paper. Comments can be submitted at IT Infrastructure Public Comments.