Answered by Dave Shaver, Corepoint Health CTO, member of the HL7 Board of Directors, and co-chair of the HL7 FHIR Governance Committee. For a comprehensive look at how FHIR APIs will fundamentally change health data exchange, download our whitepaper: The future of interoperability: Web APIs & HL7 FHIR.
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.
An HL7 standard that is short for Fast Healthcare Interoperability Resources and pronounced “Fire”. The standard defines a set of “Resources” that represent granular clinical concepts. The resources provide flexibility for a range of healthca... 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 Electronic Health Record (EHR), as defined in Defining Key Health Information Technology Terms (The National Alliance for Health Information Technology, April 28, 2008): An electronic record of health-related information on an individual that conform... 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 The Argonaut Project addresses the recommendations of the JASON Task Force, a joint task force of the ONC‘s HIT Standards and Policy Committees and is a joint project between HL7 International and several vendor and provider organizations. The purp..., 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 FHIR stands for Fast Healthcare Interoperable Resource. This emerging standard combines the best features of HL7 V2, HL7 V3, and CDA, while leveraging the latest web service technologies. The design of FHIR is based on RESTful web services. With REST... 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 is a Standards Developing Organization accredited by the American National Standards Institute (ANSI) to author consensus-based standards representing a board view from healthcare system stakeholders. HL7 has compiled a collection of message form... v2.Tags: FHIR