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.

Monday, October 19, 2015

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.

I have a theory that people will believe two systems are interoperable when they can observe that the systems work together in simple ways with little to no effort, and in complex ways with some effort. In neither case does that effort require substantial coordination between multiple parties (to achieve interoperability at the technical level).

This is a theory rather than a definition, and needs to be tested.  It's based on interoperability between applications I use on a regular basis.  Here are some of the applications and/or technologies I use, and some answers to whether or not I think they are interoperable.

Is a spreadsheet interoperable with a database?  Most are.  You can readily use a spreadsheet to query and update a database.

Is a word process interoperable with the PDF format?  Not quite.  You can easily generate PDFs, but you cannot read PDFs or update them without the full blown edition of Acrobat.

Is a word process interoperable with XML formats?  Again, not quite.  I can read and write a specific XML format (or perhaps even multiple depending on my word processor), but not generalizably so.  It takes a bit of work to get useful XML out of some word processing content.

Is social media interoperable with my Word Processor?  No.  Can I make it work?  Of course I can, but I don't think that my writing software to make it work fits within the definition of interoperability.

Is my e-mail interoperable with my blog?  Yes.  It readily supports simple stuff (notifications and postings), but not complex interactions without a good bit of work.

Is my e-mail interoperable with my tablet and smart-phone?  Yes.  Frustratingly though, I cannot do everything on my tablet that I could on my computer.  More than enough to make it frustrating to not be able to do more...

Is a patient registration system interoperable with an EHR or departmental system?  Most require a bit of work to perform this "simple" and even "designed" capability.  Is that interoperability?  Most users would probably say no.

What is your theory of interoperability?  How would you test it?


  1. If I have to enumerate and characterize each instance of two or more software applications and/or data resources working with each other to satisfy my requirements, then I am not in an ecosystem of interoperability. We have tools to facilitate interoperability, and we have planned interoperability of varying quality & completeness, but that just makes-up for a general lack.

    For instance, I was questioning 10 years ago whether consumer devices for health monitoring should be considered health data. At the time, they were not. Now they are, and we have apps to help make them interoperate with PHRs. But there is still an artificial wall between the consumer views and the care provider views.

    More recently, my wife had a surgical procedure and we were more than a little annoyed with the continued reliance on sneaker-net, fax, and phone calls. And this was from providers who all had MU-certified systems.

    Until interoperability is an effortless default that non-technical consumers can depend on, we lack interoperability.

    1. It's not about enumeration Glen, it's about having a better way to express the meaning of Interoperability. Existing definitions (or efforts to devise better definitions) suck. So rather than devising a new definition, I'm exploring a new way of looking at it. You give some great examples that could be used to test interoperability in a healthcare environment.

    2. It's a bit like a Turing test: interoperability has been achieved when one can't distinguish between manually entered data from a faxed document on the one hand, and electronic/structured exchange on the other.

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

    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?

    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.

  3. Sorry to be so basic, but interoperability is much like a relationship. Starts out on the basic and simple level of exchange, but as the relationship deepens, needs change and are driven by the context of the relationship. Same with interoperability. Every provider should have the ability to exchange simply, yet interoperable with any other provider...on demand. Past that, if and when there is a driving business need (thus deepened relationship) that justifies the cost and need for further functionality, the work is accomplished. Let's solve national interoperability first - the ability to exchange simply and easily without having to rely on the fax...then move people forward. No more star wars...

  4. Sorry to be so basic, but interoperability is much like a relationship. Every provider of healthcare services, should be natively capable of connecting broadly and simply. Then, when the need arises and business justifies the expense and effort, advanced interoperability shoudl be considered & implemented. Advanced interoperability, much like relationships, will take on different attributes based upon the driving factors. Let's solve our basic national connectivity challenges to allow everyone to connect simply and efficiently, without having to rely on the fax.