Here as we wrap up our 3 part series on FHIR, we will discuss the business implications which FHIR brings along with it.
If you have not read Part 1 or Part 2, please do so to understand more about FHIR and why it stands for the changing, better times for the healthcare industry.
Business Case for FHIR
FHIR has been able to solve both rigid custom HL7 V2 integration and non-practical cum hard-to-do HL7 V3 integrations. In the EMR space in doctor’s practices, HL7 integration has already become the exception rather than the norm. While many of the different EMR vendors are encouraging integration through their own web service APIs, the quality of those APIs vary from EMR vendor to vendor – some are RESTful, some use SOAP, but these still use custom implementation. While each EMR vendor is trying to create an eco-system of compatible products that can complement their products – implementing FHIR based APIs will allow such vendors to develop compatible APIs which can be used for interoperability and exchange of data.
EHR Interoperability
EHR vendors are required to use Public APIs to obtain MU3 certification. This is the right opportunity for an EHR to expose significant resources using FHIR.
This is how FHIR can be easily built into EHR & later all the data exchanges can be converted via FHIR API. The diagram below represents how Electronic Health Record system can update few resources like Patient, Medications, Allergies, Labs, Appointments, and Diagnosis into a FHIR repository with the help of HTTP PUT operations while doing CRUD operations on these objects in their database. These resources can then be bundled together in the context of patient portal which can query FHIR server for these resources and get updated copy each time. Same implementation can be done with the mobile device using same real time API for a read-only view of patient information and basic clinical data.
Same Restful API can be used to meet Application Access certification criteria for meaningful use wherein serialized JSON response of FHIR resource can be used to generate exchange data with third party application.
ONC has already added below mentioned criteria in MU3 wherein EMR need to develop Public API to facilitate exchange of information from EMR to third party system.
Here is the list of measures:
| §170.315(g)(7) | Application Access – Patient Selection
Ability of EHR API to be able to receive a query for a specific patient id and return data which can be used by subsequent requests |
| §170.315(g)(8) | Application Access – Data Category Request
Ability of an API to request for patient data for each of the individual data categories specified in the Common Clinical Data Set and returns the full set of data for that data category as well as ability to respond to patient data requests based on specific date criteria. |
From HL7 V2 and CDA to FHIR
Most healthcare provider organizations already have to deal with multiple standards (e.g. HL7 v2,
CDA, X12, DICOM) and mappings between them, the mapping between FHIR and these other standards is no different from any the current mappings. Given that FHIR is based on HL7 V2 and CDA, and that there is a conscious effort to align the resource definitions with CDA, the mapping between the various HL7 standards will be relatively straightforward. Any of the existing interface engines should be able to support such mappings. Tools for mapping of current standards to and from FHIR are expected to become available as the use of FHIR spreads.
For example, in a laboratory systems when the tests are ordered by sending a HL7 message to the lab and the results are received in an HL7 format and incorporated within the application, or when a provider sends a referral to another provider through a CCDA document structure.
In HL7 pipe and hat format, the PID segment (shown in red) for an ADT-A01 message would look like this:
Here, PID is a segment for Patient Identification.
| Segment | Purpose | FHIR Resource |
| PID | Patient Identification | Patient |
The FHIR bundle would look as below. The bundle is an atom feed, and the id of the bundle is a globally unique ID (E.g. a UUID) that represents the FHIR message as a whole. This is distinct to the MessageHeader ID which is important when dealing with errors that occur during messaging.
where, Resources used will be:
- MessageHeader
- Observation
- Patient (Subject of the observation)
- Provider (Performer of the observation)
Patient
Here, we need to find the Patient from the FHIR server or any other repository and retrieve its URL. We will search for a patient using the patient identifier from the PID segment. Query the FHIR server as:
GET [patientserver]/patient?identifier={identifier}
Below image gives an example of FHIR considering only few fields as compared to the HL7 message to give a picture of how the response will be received.
Extensibility to new platforms
There is no specification in FHIR that a system should only support one paradigm. A complex implementation will involve using multiple paradigms smartly.
For e.g. A hospital may be using primarily messaging paradigm for meeting request/response workflow for exchanging information, but it needs to use documents paradigm for supporting exchange/storage of discharge summaries, progress notes, clinical summaries etc. It may also need to expose registries, appointments, patient portal and referral information via REST & few custom services for decision support. Various platforms like the PMS, EHR, Patient portal, Labs, CDC’s can be integrated using FHIR. Once the APIs are exposed, any other system can communicate using FHIR once the authentication is granted.
Bottom Line
With providers complaining of the current EHR system lacking the necessary formatting regulations that ensures smooth communications between all sources, the idea of a centralized interoperability using FHIR gives way to more flexible concept and promises to be a long term solution over multiple existing standards. FHIR is easy to learn and implement with lower cost. It’s free, flexible, and scales well from simple to complex systems. It has the potential to solve the real need of the healthcare ecosystem and help the users using the system.
FHIR is catching fire across the healthcare users and Nalashaa has been helping various clients in implementing FHIR standards. We understand the application of FHIR with different systems and can provide the best approach to leveraging the FHIR standards.
Kiran Sangem
Latest posts by Kiran Sangem (see all)
- Part 3 – FHIR: Why every EHR should follow the FHIR path - October 28, 2016