What impact will FHIR have on the Healthcare Integration Market?

Oct 30, 2013

Yesterday, I gave a FHIR update as a keynote presentation at the International HL7 Interoperability conference (IHIC) on the subject. You can get my slides from the IHIC website or the FHIR SVN. As part of that presentation, I discussed the likely impact of FHIR on the Healthcare Integration Market. ## FHIR will Drive Interoperability Costs Down FHIR is going to reduce the cost of interoperability. Here’s why:

  • FHIR is designed for implementers
  1. It’s written to be understood and implemented
  2. The resources are described in the language of the problem
  3. There is Quality and Consistency, but in the background
  4. Version Stability is inherent in it’s design - ithasto be, because it’s a repository specification (like DICOM)
  5. FHIR comes with 1000s of examples
  6. There’s broad and deep (and growing) Implementation assistance: code, Live Servers, Regular Connectathons
  • FHIR Re-uses Technology and Patterns
  1. We copy Facebook, Google, Twitter, Stack Overflow, etc wherever we can
  2. The skills and libraries for this are widely available
  3. The RESTful API can be used in all sorts of creative ways
  • FHIR is Free and Accessible
  1. There’s no limitations on use of distribution. This is particular good for open source.
  2. It’s published as web site - send direct links to the current site, no problems with currency of versions
  3. All documentation, tutorials, etc, are published under open licenses

The combination of all this is going to drive the cost of providing interoperability down (see John Halamka’s take on this). It’ll be easier to develop, troubleshoot, maintain, and leverage in production environments and there’ll be more and cheaper people to do the technical work.

And the best part is that competing approaches - the ones that already exist - they’re going to have to compete: their cost has to go down as well. This effect is already being felt in other HL7 standards (IP changes, extensive examples, more focus on implementers). It’s all good.

Except maybe for people like me.

Market Spend will go up

But actually, I think that the amount of money that is spent on Healthcare Integration is going to go up dramatically. The reason is simple, and can be described really simply, using a derivation of the Velominati rule #12:

The correct amount of integration isn * 2, where n is the amount you currently have

I’ve seen this again and again - the more integration you get, the more you need. And since FHIR is going to make it easier to get integration to pay off, people are going to want more - lot’s more.

The total amount spent on Healthcare Integration will rise dramatically. But the work will change - the technical challenges will recede into the background, and while that will lift people’s expectations of what they can get, policy and informatics questions are just going to get harder as integration scales up. So, maybe people like me don’t need to worry so much after all.

Where will FHIR be used?

Since the start of  the FHIR project, I’ve been predicting that FHIR will initially be used in new areas where there is not a lot of existing implementation, In particular:

  • Personal Health data + access to institution health records + Social/Mobile/Big Data. I call this “connected health”
  • Device Data management (particularly as an adjunct to connected health)

A quick scan of the PHR Market - 100s of providers, 1000’s of health data providers (at least), and about $100,000 per connection between PHR and data provider (that’s what my market scan tells me is the overall total cost including contracting, management, development, testing, support…) should tell anyone that this isn’t going to work. The PHR/Data provider connection needs to be commoditized. And that’s the first place that FHIR’s going to have an effect.

But another area’s been sneaking up in the implementation work that we’ve done to date:

  • Existing Healthcare Regional and National Repositories

These already exist, and so we (the initial project team) didn’t really expect that FHIR would start to be used in these quickly. But I’m hearing that these projects are really feeling the overall cost factor - they need more bang per buck. But the work with IHE to include FHIR as part of the XDS suite (through the MHD project) and the possibility of using FHIR piecemeal as adjuncts to existing repositories has lead to much more interest in this space than I expected to see at this stage of the process.

But there’s one last area, a real frequently asked question: will FHIR replace version 2 messaging? From the beginning, we’ve designed FHIR so that it has the capability, but we really didn’t expect that this would happen anytime soon - v2 is pretty well understood and why would you change what works? We expected this to happen only very slowly, and mainly driven by external use impacting on existing internal processes. But after the IHIC meeting, I’m not so sure.

Jamie Ferguson (CIO at Kaiser Permanente) gave a great presentation about new policy directions in the security/privacy space. I’ve known that this has to happen, particular in the post-Snowden era, but I’d never stopped to consider the full ramifications of this. Jamie’s presentation goes through the full ramifications of the changes afoot in society and technology now - I highly recommend his slides, which you can get on this IHIC website. Where this is of interest to FHIR is that the logical consequence of Jamie’s policy directions is that every existing interface is going to have to be revisited and re-implemented to support all this. And further, we’d have to retool HL7 v2 to support all this, while FHIR already does - I think (We need to do more work around this - I think we have the touch points, but we definitely need more work yet. We’ll have to make this a focus of a future connectathon).

So now I’m beginning to wonder - we might see FHIR replacing HL7 v2 rather sooner than we expected.