How do interface engines support FHIR? When looking at an engine replacement, what should be considered?
Answer from HL7 FHIR Governance Board Co-Chair and Corepoint Health CTO Dave Shaver:
I think the first thing I would look for is a vendor that’s engaged in the FHIR community and supporting the creation of the standard.
From a technical perspective, or maybe a motivating example perspective, one of the things we see happening — I’ll go back to my device example where we’ve got an EHR on the left and I’ve got my device on the right. And there’s a desire from the device’s standpoint to use this example, as I’m going to publish a FHIR resource, which is an observation.
What I need is an integration engine in the middle to take that FHIR resource and map it through some environment from FHIR into an HL7 result. So this could be an HL7 V2 result and the logic that’s in the middle with the interface engine will do that transformation. An engine will take a FHIR bundle or FHIR resource and translate it into a v2 result so that my old school EMR over here, which doesn’t yet support FHIR, will be able to effectively utilize the data.
We can imagine doing the same thing where I’ve got an ADT feed that’s coming out of my HIS (health information system) and I bring it into my interface engine. And the engine has the ability to use a database and take that v2 information and push it into a database. So this would be, effectively, a FHIR repository.
That FHIR repository now has the ability to be queried. The engine could provide a FHIR query mechanism that could respond to requests from a device. We will be able to — without having to involve my HIS vendor — effectively take my ADT data, push it into the FHIR repository, serve it up through a FHIR API, and translate the results back.
And eventually, once I’ve got a FHIR API, these interfaces could swing over and talk directly to my EHR. Or I could continue to run the engine between these different translations of FHIR.
Another challenge we’re going to have is — continuing with the same example — there’s an application on the left and on the right and we want to do a query. The problem is, of course, FHIR is very extensible. So we’ve got “FHIR flavor one” and “FHIR flavor two” and they’re not completely compatible.
Or, we’re potentially losing information in the extensions. You can imagine that an interface engine sitting in the middle can translate from one flavor of FHIR to another.
So I would be looking for a vendor that is working on solving and educating and working with the industry to solve these problems. One that has the technical componentry to support things like REST-based web services, XML and JSON.
It is key, in my opinion, for a vendor to be active in the process of the creation of FHIR because they will be in the best position to anticipate and adopt new processes that will help their customers.
