Saturday, December 30, 2017

HIE Future is Bright - stepping into 2018

This is my overall summary of the Healthcare Standards, Privacy, and Security space. It happens that the framework for explaining why the future is bright for HIE comes from the Wisconsin HIE (WISHIN) fall summit. Note slide decks are now available.  They used the following diagram to show what they viewed as the HIE future. I like it, so will use it here

This is such an exciting perspective of what the Wisconsin HIE delivers today, and where they are targeting for future support. The other slide decks further elaborate on this plan. It is driven by delivering Value, not just Volume.  They had a segment that focused on Care Coordination as a driver of these changes.

I have written articles about each of these transitions and more. Here they are

My Perspective

The big factors as I see it:
  1. The Document model is still very important, even if it is frustrating. This is especially true of historic episodes and visits. These historic events need to have the full context of them, which is what a Document model provides.  
    • The good news is that FHIR has a Document model, and the FHIR Document model has a directly convertible data model
    • A FHIR Document travels an HIE easily
    • CDA will fade, but never disappear. It is just way too hard to get right.
  2. The future will be more about automating the consumption. Up to now we have focused on getting EHR to publish or simply make available the data they have. This first step is critical to Interoperability. We now need to focus more on data consumption, as the way we consume Documents is not optimal or even functional.
    • The good news is that FHIR is a fantastic API for consuming data. So there is a rich opportunity to make the consumption experience better 
    • Enterprise class API  ==>  FHIR API to Document Sharing
    • FHIR has subscription model, to make service-to-service API more efficient and responsive
    • FHIR has ability to bundle and disassemble without conversion or loss
  3. The future will connect the nation. Today there are a small number of very large networks, but there are no linkage between them. So if you happen to live in a part of the country where you need to go to doctors within different networks, then you must manually transfer the data yourself
    • The good news is that there are talks and actions to unite eHEX, CareQuality, CommonWell, and others.
    • Not just technically, but also logically. We need nation wide policies on the use of Vocabulary, Document formats, and Care Planning
  4. The bad news is that Security and Privacy are going to get worse before they get better. This is more a statement of security than Privacy. I don't see any of these future benefits abusing Privacy, but I am worried that Privacy-By-Design isn't ingrained. I am more worried about Security, in that the security model for FHIR is very immature, and the junction between FHIR and the other worlds where the data exists.  This is not to say that OAuth is bad, but rather the healthcare use of OAuth is not mature, and the healthcare needs of OAuth are well beyond what OAuth was designed to do.
    • The good news is that there really is plenty of time in the coming years to work this out. What we need is interested bodies to get involved with open consensus prototyping, trial, documentation, and improvement.

The future might get the Patient more center to their own care. Today the GP drives everything. I don't think they want to, but it is just too hard to do anything else. Some say there is business pressure to keep control within that doctors office, I don't think this is all that true. I think it is more simply too hard. First, most patients are not technically savvy, that is changing. Second, most patients are not feeling well, so it is hard to take leadership. MOST important it takes a community to put the patient at the center, and we don't yet have a connected community.

These will not happen in 2018, I am just predicting they will be the central motivations that will influence change. If they happen, all the better. We must remember that change takes far longer than one expects it should.

Some blog articles I am working on:

  • Direct HISP on FHIR - replacing XCA api with a FHIR api
  • Meaningful Use means IHE PDQm, MHD, QEDm, and mXDE
  • Reverse MHD
Please contact me if you have a topic you would like me to cover.

Monday, December 18, 2017

IHE PDQm and MHD - FHIR conformance resources

I have been pushing IHE to add FHIR conformance resources to their publication mechanism. I now have published the full set of FHIR conformance resources for PDQm and MHD profiles. Also available is mCSD by Luke.

A bit of background. FHIR conformance resources are available to carry programatically the constraints that historically IHE has written narratively into an IHE Profile. An IHE Profile is a standard that takes a Use-Case and creates an Interoperability solution. This is done using long standing IHE Governance through a standards selection process, standards development process, public comment review, trial-implementation phase, and connectathon testing.

An IHE Profile is very similar to an HL7 Implementation Guide. Each organization has variances, but both can do similar effort. IHE has been doing Profiling since 1998

IHE as an standalone organization can very easily and cleanly Profile large use-cases that require the interaction with many different standards. Profiling that needs to simultaneously invoke HL7 v2, DICOM, and eb-Registry are the biggest strengths of IHE. Where as HL7 is more limited to writing focused Implementation Guides around the HL7 specific standards like FHIR (US-Core) or CDA (C-CDA). Much more is likely going to be said about this in the future. HL7 and IHE are working to find a good way to cooperate and complement.

Patient Demographics Query for Mobile (PDQm)

I will be clear the reason this is an IHE profile is because of long standing set of Profiles of the exact same use-cases that show how to constrain HL7 v2 messaging, and HL7 v3 messaging. Thus, they are historically in IHE from 2003 (14 years ago). Given that IHE had PDQ and PDQv3 published, the IHE audience wanted to see the FHIR flavor. Thus PDQm exists. The reality is that this profile is about as unconstrained as a profile can be. But because it exists, we need to publish FHIR conformance resources.

The best place to go is to the IHE wiki page for PDQm, as any updates that happen in the future will be updated on that page. There is a section on this wiki page dedicated to PDQm FHIR resources. That page is also what all of the FHIR conformance resources point to as the narrative 'implementation guide'.

Informatively the PDQm profile is also published on Simplifier. See

These conformance resources are also registered at

The following links are to current copy in Simplifier. The canonical URI is also given as the permanent URI. The canonical URI is not usable in a browser, but may be used at the FHIR registry

Note that previously we did publish a StructureDefinition for the PDQm Patient Resource. This has been removed as IHE PDQm does not constrain the Patient Resource at all, and therefore the STU3 Patient StructureDefintion is now referenced.

The conformance resources are also available on the FTP site

Mobile Healthcare Documents (MHD)

The MHD profile is also an IHE profile due to the history of IHE XDS/XCA/XDR/XDM etc. The Document Sharing family. Thus IHE shows how to use the FHIR standard as an API to these XD* environments.

The best place to go is to the IHE wiki page for MHD, as any updates that happen in the future will be updated on that page. There is a section on this wiki page dedicated to MHD FHIR resources. That page is also what all of the FHIR conformance resources point to as the narrative 'implementation guide'.

Informatively MHD profile is also published on Simplifier as a set of FHIR conformance resources, that are also registered at

Note the following links are to current instances maintained in Simplifier. This URL may change over time, which is why the canonical URI is provided. The canonical URI can not be used for browser navigation, but can be used for lookup at registry or simplifier as search capability allows.

Prior conformance resources have been registered, they should now be marked retired


I likely have made mistakes... Please point them out to me so I can fix them. I am very open to opportunities for improvement.