Convert your FHIR JSON -> XML and back here. The CDA Book is sometimes listed for Kindle here and it is also SHIPPING from Amazon! See here for Errata.

Tuesday, May 4, 2010

Meaningful Interoperability is not defined by Meaningful Use

I spent an hour today on a call with NIST (along with many other HL7 leaders) regarding the testing framework they are presently developing for meaningful use.  One of the the issues that NIST correctly identified is that the standards selected for meaningful use are not sufficient to support interoperability.  They pointed out to ONC that the SDOs have spent many person-years developing implementation guides that ensure interoperability.  Because these were not selected by the IFR, NIST has been directed to fill the gaps in a few short weeks.

To resolve this problem, NIST is working with HL7 and other SDOs to identify what is enough to ensure interoperability.  They are in fact, creating "baby" implementation guides.  I would not want to be stuck in between their rock and hard place right now.  The danger here is that years of consensus building and implementation efforts could be completely irrellevant if the wrong choices are made. Hopefully the choices that are made by NIST and the SDOs will enable use of and not conflict with existing guides; without requiring their use.  Yet those same choices need to be strict enough to ensure interoperability.

If you look at the schedules that NIST has to commit to, this is insanity.  HL7, IHE and HITSP spent years developing standards and implementation guides that do exacly what is needed for various use cases in the IFR (immunizations being one of those). The number of person-hours spent developing and refining these guides and building concensus around how they should look is immense.

The EHRA also recognized this as a problem, and is currently reviewing a set of recommendations to its members on what implementation guides should be used.

My recommendation to NIST is to implement NO MORE than what is in the rules in their testing framework, even if it doesn't guarantee interoperability.  Then, to ensure interoperability, the next part of the process would be to verify products DEMONSTRATE interoperability with other systems using those standards.  The vendor community has been doing this at IHE Connectathons for years.  Demonstration is one of four ways to validate conformance (The other three are Test, Inspection and Analysis).  Combining a demonstration of interoperability with verification that the product is correctly implementing the base standard would be an effective way to meet the goals of the IFR and the Certification process.

In this way, we can use the standards specified in the IFR, and the implementation guides that we chose to support, without concerning ourselves with reinvention, insane schedules, and introduction of incompatibilities.


  1. This is what we get when healthcare IT standards, and healthcare in general, are politicized.

    It is also what we'd get if there has been willful ignorance of the work that SDOs and standards consortia have done over the past ten years. I hope that is not the case, and would be more than a little discouraged if it is.

  2. That is what happens when you let those with no knowledge of the business define the "Standards"

  3. Re: the previous 2 comments, remember that standards development, just as any other aspects of health IT, cannot ever be separated from the messiness of life that happens outside of the purity of a protocol document. The politics is part of the reality that must be accommodated and dealt with, not railed against.

    The key question: why weren't the interoperability standards selected by the IFR? Whatever the reason, it needs to be prevented for future decisions.