Will FHIR ensure better consistency?
How do we get more consistent in our approach to interoperability? I think as we learned in the days of HL7 v2, we can extend HL7 v2 through the use of Z segments that allow us to send virtually any data that we want. We learned that if there’s no standard way to profile a Z segment, they truly become proprietary.
That’s an important parallel to draw to what we do with proprietary APIs. A proprietary API is almost always synchronous with the database. They may not allow true interoperability, but they do allow the application to talk to the data and its source of truth. These APIs present the same challenges as Z segments in v2.
In developing HL7 FHIR, we followed the 80% rule: if we believe that 80% of the vendors would likely support or need this segment, we try to standardize that portion of the data model to provide for interoperability with other systems. If it doesn’t meet the 80% threshold, we push it off to an extension, which is to a Z segment.
FHIR allows developers and providers to extend the data profile through extensions, but there is a formal framework that allows those extensions to be profiled and shared. For example: If there’s a particular state requirement or a particular cancer reporting infrastructure issue, rather than having to create Z segments, FHIR can build a standard profile and publish it online so all parties can see what those extensions look like.
How should providers evaluate an integration engine’s readiness for FHIR APIs?
Most providers are either unsure about how they’re going to address FHIR or they are looking at their current vendors to address it for them.
I would broadly suggest there are many reasons to upgrade your platform if you’re still writing code to build interfaces. (Read my post Comparing interface engines) There are other options that allow interfaces to be created more simply and more succinctly. You might look at uplifting your technology over time, rather than rip and replace. You can look to add or augment your engine with a Corepoint product that is more efficient at building interfaces, particularly using FHIR.
I recommend that providers look very carefully at the vendors they are using and depending on. In the context of an integration engine, see what level of participation they have in the industry organizations, such as HL7 and IHE International. Are they helping to build and fine-tune standards such as FHIR? Do they hold committee membership?
This type of evaluation goes beyond simply checking a box that says “they support FHIR.” Vendors that actively participate in standards development stay two steps ahead other vendors. Here at Corepoint, for example, playing a leadership role in the industry helps our development team get a head start on product features that will be perfected and tested long before they become needed throughout the industry.
When will major EHRs begin offering FHIR APIs? How will they function?
It’s accurate to say that every major EHR vendor – especially those participating in The Argonaut Project – claim to have a FHIR API available on their product.
However, available on product and available for use in your IT department are two different things. For example, if you’re on a 2013 version of your EHR and the 2016 version happens to be the one with FHIR, the upgrade process may take six-months, involve the entire organization, and cost millions of dollars.
That problem has to be solved. It isn’t yet clear whether EHR vendors are going to provide FHIR modules for free. It’s also not clear if those vendors are going to give those APIs full CRUD access – the ability to create, read, update, and delete. Most EHRs, in the context of Argonaut, are only offering read-only APIs. Those allow applications to query and interact with the source of truth in a very small way.
FHIR will solve problems first and foremost that aren’t solvable today and I believe the workflow process is going to drive how FHIR APIs are offered in the future. As vendors use FHIR internally, they’ll expose those capabilities to their customer base.
I’ve seen most EHR vendors participating in the HL7 FHIR Connectathons and I have seen the depth of their functionality. In this environment, their offerings are coming together pretty quickly in comparison to how long it took the industry to adopt HL7 v2.
