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 24, 2011

Seamless Interoperability

The IOM just released a 273 page report advising that what providers need is seamless interoperability.  To put "Seamless Interoperability"  into recent words used by, Bob Dolin, Chair of HL7:  "It just works!"

What would it mean for two Health IT systems to be seamlessly interoperable?

  1. Would the two systems automatically recognize each other's presences and start negotiating how they would exchange data?  Your printer and operating system can do that today for most systems.  If I install CPOE and an LIS already exists, how much work should be required to make the two be aware of each other?  
  2. How much should be configurable?  When I install a printer driver, I sometimes get a choice of printer control languages (more standards).  I can use HP PCL or PostScript.  Do I get to choose which, does it automatically support both?  In this example, do I get to chose between HL7 V2.3.1 or 2.5.1 or are both supported.
  3. In HL7, there are a set of messages for dealing with labs that support a variety of workflows.  What workflows should we support?  To change a lab, do we cancel the old and submit a new one, or change the original order?  Who is allowed to change the order?  Can the lab do it, or only the ordering provider?
  4. What vocabulary is used to identify the labs being ordered?  I've argued for quite some time that LOINC can do the job, but others insist on using proprietary vocabulary.  How does that get mapped back to the EHR so that we can track results over time?
  5. What can be ordered? And what results will that order generate?

Some of these decisions are made locally by the provider, based on their organizations policies and workflows.  Others are negotiated with someone else.  Some are made by the supplier.  You cannot order something from a supplier that they don't provide.

Not all of this is about interoperability standards and technology.  Some of it has to do with making business practices work seamlessly as well.  While people complain about all of the optionality in HL7, some of it (not all of it mind you, but a good portion of it) is there because these business processes exist and need to be supported in some part of the world.

It would be an interesting exercise to see how willing organizations are to standardize (and potentially change) their existing business practices in order to support seamless interoperability.


  1. There is no such thing as shrink-wrapped interoperability. Why? In the absence of unambiguous policies, it is the equivalent of the Halting Problem.

    Generally, without unambiguous policies and the means to keep them up-to-date for all parties, IT is a waste of time, effort, and money. That has been demonstrated many, many times.

  2. Mutual understanding is not all or nothing: system A may get some of what system B can export and vica-versa but, rarely, will two parties understand each other completely. And that's fine, certainly for read-only exchange.

    To take your labs example - some local codes may have loinc equivalents, some may not. If both systems understand the same local codes, then all is well. Otherwise, they fall back to loinc. Over time, hopefully there's more loinc and more mutual understanding. Perhaps clearer than printer drivers, you have browser behavior. Old browsers don't collapse because they see a new HTML5 "section" tag.

    Interop, beyond the (trivial) "email or soap" stuff, is not all-or-nothing. If that's what is meant above by seem-less, then seem-less is achievable. If seem-less == exact match then ...