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.

Monday, November 23, 2015

HEART profiles for review, comment, and approval

The HEART workgroup has developed three profiles that have been stable since April. They now want these formally reviewed for comments, with the expectation that this will result in a vote for approval as "Implementers Draft" status (equivalent to IHE "Trial Implementation", and HL7 "Draft Standard for Trial Use"). The three profiles that are ready for review for comment and approval are:
The profiles are very generic and not specific to healthcare. They are profiles simply to bring focus on the simple use of OpenID Connect, OAuth 2.0, and UMA. Review these with a focus on readability and reusability. Don't look in these for anything special for healthcare. Actually if you find something special for healthcare in here, please comment on that.

These have been stable since April, so they have been available for comment for 7 months. The specific call right now is to get these closed out as Implementer Draft status in two to three weeks. So now is the time to look at them if you have not yet looked at them. If you have looked at them, then now is the time to comment.

How to Comment and get involved

Please get involved, this is an important effort to the advancement of healthcare user authentication, authorization, privacy, and security. This work is critical to success of FHIR, and usable for any HTTP (RESTful) efforts in healthcare.

To get involved go to the HEART home and follow the instructions:

HEART scopes
The fourth profile is one written based on the prior foundational work from the SMART effort. This profile is a library of OAuth 2.0 Scopes. That is, scopes to be used when asking for OAuth authorization decisions, or to decorate an OAuth security token. This library is not only specific to healthcare, but specific to FHIR. So please review this profile for how useful these scopes are. Are the scopes at the proper level of abstraction? Are the scopes useful? Are there additional scopes that should be listed.

Might be useful to have scopes that are more broad? Might be useful to have scopes that are considering DICOM WADO/QIDO?

Future HEART

There is continuing work going on in the HEART workgroup. So  please don't look to these three profiles as the only work from HEART. They are actually work finished 6 months or more ago. The effort today is on defining patient managed authorizations, such as consent as controlled by the patient themselves.

Clearly this will enhance the scopes beyond the fixed list in the scopes profile. 

Also, See my blog on  FHIR Security initiatives

Friday, November 20, 2015

Building a MHD Client before MHD is DSTU2 aligned

To implement a Document Consumer is the easiest of the MHD actors. It is also the one that has the best opportunity for an application developer to be creative and add value. So I will focus on Document Consumer actor from MHD.

XDS Profile found in the FHIR specification:

I would caution against the use of the xds profile in FHIR. It was started by Grahame and I, but it didn’t get any attention between the DSTU1 and DSTU2 stage. So the only thing you will find there is minimal fixes to cause the FHIR specification to build. Fixing this profile in FHIR was part of my motivation for creating the HSI workgroup in HL7, however that workgroup is restricted to not owning anything in HL7. So they couldn’t take ownership and improve it.

This means that the xds profile in FHIR might be right, but it might not. I simply don’t know, because we never had time to work on it.

Use DSTU2, following the spirit of MHD

Reminder, that IHE is going to be updating MHD to match HL7 FHIR DSTU2 So, you should really focus on the ‘spirit of MHD’, while implementing HL7 FHIR DSTU2. This is not what the MHD profile is based on today, but will be what it is based on in early 2016.


As a Document Consumer you mostly use FHIR as it is defined. Focusing on DocumentManifest and DocumentReference

There is a Mapping you can find on these FHIR Resource definitions to the XDS metadata definitions. These mappings are pretty direct. Mostly because these FHIR Resources were directly created as modeled from XDS. Find the mappings to SumissionSet and mappings to DocumentEntry.

Testing prior to European Connectathon

IHE will not be testing MHD at the USA connectathon, because we don't yet have the MHD ready and therefore they also have had no time to develop test tools. However there is intention to have MHD ready for European Connectathon - April 2016 in Bochum/Germany.

Before then, I would recommend you simply point your client at Grahame’s FHIR server, or any of the other Publicly Available FHIR Servers. This is what we did at the IHE Connectathon last year with DSTU1. As a Client you should not be able to tell if the server is just a FHIR server, or if it is a proxy to XDS, or if it is a proxy to something else (like an API to an EHR).

The problem of course is that as a Document Consumer actor, you can only query against the resources found in the FHIR server you are pointing at. I wish I had a good answer to this. Developing good examples would be very helpful. Even better is to get these good examples into the FHIR specification, as then they automatically end up in Grahame's FHIR Server. But today there isn't much default content.

API Tooling

If you target FHIR DSTU2, then the HAPI tools that are published in the FHIR specification are perfect for you to use. which has many tools


 There is a google group for MHD implementers, Just ask to join, I will accept any asks.

There is also good help from the FHIR community.


We are not where we want to be, but then if we were we would want to be further... So accept where we are and help move us to where we should be. By trying to implement as I have described, you will learn. What you learn, I encourage you to share with the community. The more we share, the more the FHIR and IHE specifications get better. The better they are, the more likely Interoperability happens with quality and efficiency. So please help in what ever way you can. Not everyone is asked to write specification, but everyone can contribute. The smallest question posted to a mailing list can be the most valuable thing.

Past articles on the topic

Thursday, November 19, 2015

IHE updating FHIR Profiles to align with DSTU2

IHE has a set of profiles based on FHIR (MHD, PDQm, PIXm, mACM, RESTful ATNA Query, CMAP, GAO, and RECON). But they are based on earlier versions of HL7 FHIR. Now that DSTU2 is formally published, IHE needs to update their profiles to DSTU2.

IHE kicked off this week Monday a bi-weekly effort to update MHD to DSTU2;

IHE kicks off next Monday a bi-weekly effort to update all the other FHIR profiles.

I encourage you all to participate. The hope is that we have them done by February so that they are ready for EU Connectathon.

I am especially interested in specific changes. We have started a punch list so that we convert them all in similar ways. I am specifically interested in how to write these profiles efficiently in a way that targets the reader needs.

Tuesday, October 20, 2015

Response to Keith's ask on my theory of Interoperability

Keith asks

A theory of interoperability

Definitions of interoperability surround us, but all the attention in the world to definitions make very little difference in the end.
What is your theory of interoperability?  How would you test it?

My theory of Interoperabilty: Starts with a desired outcome that has a known value. Without this use-case driving interoperability you are just talking technical capabilities. Meaning, the reason why one can get PDF out of WORD, but not PDF into WORD, is because the desired outcome with a known value is to produce a report that can be rendered easily but not modified easily. Hence this is a delivered Interoperability.

In healthcare, I fully understand why a Patient would want to enable a specialist to gain full access to their medical history. A understood outcome with a known value. This is why I very much support and work hard to enable providers to communicate in as full fidelity as possible, while also enabling Patients to control that communication flow (Privacy Consent). See In Wisconsin we have Interoperability

While I am really not a fan of mechanisms that put the Patient as the means of communications. I understand that this could be the least common denominator, but why try to improve in such a undesireable way. This said, we do have the Meaningful Use feature of "Download". In fact my healthcare provider has provided this for a very long time, and I have downloaded my data. I have a copy of my data, in form of both PDF and CDA. So I have in my hands what, as healthcare standards geek, understand as the most highly interoperable form possible. YET, I have no clue what to do with this data. Why do I have it? Why do I need it? See I feel BlueButton advancement

yes, I know that I am lucky to be in good enough health that I 'don't need it'... and I feel for anyone that really does need it and can't get it....  This is why I continue to work on solutions that don't make practical sense to me personally.

Interoperability delivers a desired outcome that has a known value.

Friday, October 16, 2015

IHE FormatCodes are mandatory

The expectation that the IHE ITI Technical Committee had on formatCodes was that the Affinity Domain would not want random and unspecified documents registered. As documents that can't be understood by Document Consumers are not helpful to the Affinity Domain. The Affinity Domain, which is some kind of an organization, would have some Process where those that had a new format would argue the usefulness of their document format. This Affinity Domain process would, if approved, add that formatCode to the acceptable formats in that Affinity Domain, thus triggering the Registry requirement to validate formatCodes.

These codes would be either pre-coordinated, such as with IHE Document Content profiles; or would be assigned by the Affinity Domain. In this way the Affinity Domain would be able to make sure that only document types that they agreed with would be registered, and those that were not approved would be rejected. The rejection of a document type in this case could trigger the people using that specific Document Source to come to the Affinity Domain organizers and follow their Process to get their format approved. In this way the Affinity Domain starts with nothing approved. Even the IHE defined Document Content profiles are not pre-approved. Just because a formatCode exists does not mean that it is understood by Document Consumers, or that it is considered useful within that Affinity Domain.

Formats not defined by IHE are thus registered as Affinity Domain specific codes. Cases where a JPEG or PNG mime-type is needing to be registered could be discussed within that Affinity Domain to understand the details on what kind of a document is actually being recorded. The Affinity Domain could decide that the JPEG or PNG file is appropriate to register as it has a specific value, and it would assign an Affinity Domain specific code to be used. It is likely that the Affinity Domain would assign a more specific code than the Mime-Type, as they would recognize the medical significance of the JPEG. Thus the Affinity Domain could recognize multiple JPEG files for various purposes (One could point out that this variance is better managed with typeCode and classCode).   This does not diminish the usefulness of mime-type, as often that is all the Document Consumer cares about.

I am not sure IHE ever said that the Registry couldn't have been told that it's validation requirement for formatCode was to accept all codes (.*). We simply put in that it was required that validation rules would exist…

The question that triggered this post is one that asks for a general mechanism where the document is really not more distinguishable at the FormatCode level than is already defined by the mime-type. One alternative suggested is a blanket FormatCode (undifferentiated), a set of blanket FormatCodes (image, text, etc), or allowance to use mime-type as the FormatCode (which would need some codesystem). For example where the file is simply a picture from a phone-camera, a JPEG. Note that all the other metadata is useful and not in question, just not clear what to do with FormatCode.

I would push back on requests to just accept all JPEG; as I am sure there is more detail. I am guessing that we would understand that although the file format is JPEG, that the use-case is specific to something. (Note I am not picking on JPEG specifically, but using it as a representation of any class of mime-type identified document)

So this is why we defined formatCode as mandatory, and why we didn't define a type for 'any'… We wanted the Affinity Domain to be in control.

More blog articles on Document Sharing Management (Health Information Exchange - HIE)

Thursday, October 15, 2015

FHIR Security initiatives

I am asked how someone can get engaged with developments in Privacy/Security around FHIR. I am very happy that people want to help. I am especially encouraging to anyone that has either coding experience, or deployment experience; as I find that too many people engaged in Privacy/Security around FHIR are coming from the theoretical perspective. This is a good perspective, but not sufficient to give us practical solutions. What we need today is practical solutions, that are on the trajectory of a theoretical horizon.

HEART – where I think bleeding edge work is being done. This group is initiated by the OAuth / OpenID Connect / UMA communities. There are some key people involved from healthcare, more people are always welcome. There are participation from Patient advocates as well. It has taken input from various Healthcare initiatives including SMART, and Argonaut. They will be starting with simple things, but eventually want to show how a patient can interact using UMA to authorize others to gain access to their PHR. The drawback at this point is that this seems to be rather USA centric and FHIR centric, although I don't think that is the goal of the community.

IHE – Internet User Assertion (IUA) -  This is a simple profile of OAuth2/OpenID-Connect.  There is some work underway to improve on this initial specification. Taking on some of the lessons learned from SMART, and regional deployments. This is focused tightly on just the interaction necessary to enable protected API use.  This includes DICOM and FHIR. So it is not specific to FHIR, but can be used with FHIR.  This specifies three levels: Bearer token, JWT token, and SAML encapsulated.

IHE also has a Basic Patient Privacy Consent (BPPC) profile, and there is a proposal for developing an advancement that can carry coded exceptions or additions.

SMART, -- This group has developed, among other things, a specification for OAuth based solution for authorized applications and the users using the applications. I understand that this is further being developed now under Argonaut Project. It is very FHIR  centric.

HL7 Security WG -- I am co-chair of this workgroup. This workgroup maintains the FHIR AuditEvent and FHIR Provenance resources; as well as the security guidance pages. This workgroup maintains security-tagging within the FHIR Resource header. So that each resource can be tagged with security (privacy) relevant tags that can be used in the Access Control decision, and can carry Obligations to a recipient. This workgroup cooperates with the CBCC workgroup on Privacy matters

HL7 CBCC WG -- This is the workgroup that is working on Patient Privacy Consent.  They have a CDA implementation. They are now working on a FHIR specification. The FHIR specification is currently a Profile upon Contract.

see also my blog topic on mobile security and FHIR Security: Do (Not) Worry (start worrying now).