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:

• HEART profile for OAuth 2.0.
  
• HEART profile for OpenID Connect.
• HEART profile for User-Managed Access (UMA).

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: https://openid.net/wg/heart/

HEART scopes

• HEART profile for Fast Healthcare Interoperability Resources (FHIR) OAuth 2.0 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

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.

FHIR DSTU2 http://hl7.org/implement/standards/fhir/

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 http://hl7.org/implement/standards/fhir/downloads.html

Community

 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.

Conclusion

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

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;
http://wiki.ihe.net/index.php?title=MHD_Status

IHE kicks off next Monday a bi-weekly effort to update all the other FHIR profiles.
http://wiki.ihe.net/index.php?title=Updates_of_Profiles_to_FHIR_DSTU2

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.