How do interface engines support 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...? When looking at an engine replacement, what should be considered?
Answer from 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... Governance Board Co-Chair and Corepoint Health CTO Dave Shaver:
Tags: FHIR, FHIRworks
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 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... 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 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... 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 Electronic Medical Record (EMR), 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 can be... 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 Hospital Information System (HIS) is the main system in a hospital used by most caregivers. Sends ADT broadcasts to all ancillary applications. The HIS is typically the patient administrative system and order entry system for a hospital. Synonyms: Ho... (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.