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

Tuesday, October 13, 2015

Guest Post: Use-Case - Security Audit Prompts Investigation

Glen Marshall is well known in Healthcare Security circles, and he continues to contribute in Retirement. He produced this use-case and I found it so well written, and it explains Security Audit Logging (FHIR AuditEvent) as distinct from Provenance (FHIR Provenance) so well, that I asked him if I could publish it as a guest post. I got his approval almost a month ago, so here it is.