FHIR - what is interoperability?

Apr 12, 2013

Well, FHIR is starting to really make progress. There’s been quite a few blog posts about it recently: * http://blog.interfaceware.com/hl7/why-fhir-will-burn-cda/

Not everyone is convinced yet, but the proof of this pudding is in the eating, not academic evaluation of the source of the ingredients.

Not only is the full breadth of the specification coming together (http://hl7.org/implement/standards/fhir/resourcelist.htm), the HL7 governance & development processes are settling down, the load on my test server is going up (I can tell, I get the amazon bill!), and implementation experience is growing, with some projects going into production this year.

Which means, yes, prior to the finalization of the specification itself. In fact, that’s always been a feature of the FHIR experience: the advantages of FHIR are sufficiently compelling that projects are choosing to adopt it now, in spite of the fact that it’s not final - it’s already the best option (or is that, the least worst option?). When people talk to me about the features of FHIR that drive this, they consistently mention the following things:

  • Simplicity
  • Current technology (REST, JSON..)
  • The tooling stack that’s part of FHIR
  • Extensibility

The really intriguing item in this list is the tooling stack - one of the things people really like about FHIR is that they can (potentially) leverage the existing approaches, resources, and technology to create functionality of their own in a new space.

That actually presents a challenge to HL7. One of the goals for HL7, which is an essential part of the goals for FHIR, is “Out of the Box” interoperability. It’s a widely shared experience of HL7 implementers - two different products have made different choices about how to implement v2, so when you try to connect them up, they can’t talk to each other. Typically, rectifying this costs >$50,000 all up (including project management, vendor costs, total life cycle etc). So the HL7 community really wants different implementations to simply work together. Note that by “the HL7 community” I am describing one part of it - the part where implementers buy software from vendors to meet their business requirements.

Meeting this goal means locking down FHIR so that only HL7 can publish the engineering constructs, so that everyone can just work together. On top of this, it means good definitions, careful induction of new use cases, etc. To me, this is the classic HL7 context.

But there’s a different group of implementers at the table too. Mostly, these are institutions that perform a substantial amount of in-house development. For these developers, the ability to naturally and seamlessly leverage FHIR in other directions is very much an attraction. The fact that the solutions they develop doing this won’t interoperate with other implementations “out of the box” is completely irrelevant since they’ll never interoperate with them at all anyway.

The problem with this is that we all actually live in a continuum between the two extremes - all implementers have a mix of custom and OTS software. It’s just that the percentages differ between them, and across time as the bespoke vs commodity pendulum swings. There’s a new component to this in FHIR: external public-ish web sites (such as if, e.g. Facebook decided to put up a FHIR server linked to face book accounts for people’s own PHR - it’s not quite public, but it’s certainly not private). These will change the weighting - but not the overall picture.

I think that we are going to have to define some special conformance level. something like “Commodity FHIR”, where out of the box interoperability is an expectation, and an alternative one like “FHIR-leveraged” where interoperability out of the box isn’t assured. Is going to be messy, and it’s going to cause everyone trouble. But this mess isn’t of FHIR’s making - it’s a problem inherent in the real world.