Contact Us

Contact Us

The Current State of FHIR Implementation by EHR Vendors

FHIR Implementation in EHRs Compared to Actual FHIR Standards

FHIR is becoming a defacto choice for healthcare integrations. However, major EHRs are lacking the full-scale implementation of FHIR. They do provide access to individual patient data if patient identifiers are known. CDS-Hooks and SMART on FHIR seem to be the best option to integrate individual patient’s data into ancillary healthcare systems. However, most EMRs have not implemented the full scope of FHIR to provide data when there is a need to get a group of patients who fall into a certain category or meet a filtering criterion.

In this article, we explore different options available to fetch multiple patients data from major EMRs (Cerner, Epic, Allscripts) using FHIR.

For this article, let’s assume that there is an outbreak of a certain type of virus and a healthcare administrator has asked Technosoft to find all patients who have gone through a certain lab test at an outpatient facility.

 

FHIR Option 1: The Direct Option

The straight forward option Technosoft integration team thought was to pull ProcedureRequest FHIR resource and filter on the basis of the class field in the associated encounter FHIR resource.

The “class” field in Encounter FHIR resource could have helped us to identify if the Encounter was associated with a patient in the outpatient facility. For example, if we wanted to filter out for ED,  as per “http://hl7.org/fhir/v3/ActCode” system the code for such patients would have been “EMER”.

The approach here would be to pull all the ProcedureRequest in a given date/time range and then filter out the ones that have the associated Encounter for the outpatient facility. Since it is not possible in FHIR via a single request as we wanted to filter out the resources on the basis of the associated resource data point; we could break it down to make multiple requests in order to pull the desired data. It seemed doable with multiple requests as per the documented FHIR specs. However, each of the major EMRs had their own restrictions as following:

Epic

  • ProcedureRequest FHIR resource is only available in EPIC App Orchard Program as STU3 resource, even though it exists in actual FHIR specs since/before DSTU2, which means only the organizations that have upgraded to STU3 version of FHIR for EPIC will be able to expose the endpoints for this FHIR resource.
  • Even for STU3 upgraded organizations, Search parameters for ProcedureRequest FHIR resource only allow for consumers to query data on the basis of a patient or encounter reference. It does not allow to query data for date/time range or for multiple patients at once.

Cerner

  • ProcedureRequest FHIR resource is available as DSTU2 version resource. Cerner is working on an upgrade to R4 directly but that is still work in progress where this resource should ideally be renamed to ServiceRequest.
  • Search parameters for ProcedureRequest FHIR resource only allow for consumers to query data on the basis of a patient reference. They do not allow to query data only for date/time range as it requires the patient reference even with _lastUpdated parameter as well.

Allscripts

  • ProcedureRequest FHIR resource is not available in Allscripts.

So this basic direct option cannot be used to gather data for multiple patients. With that, we tried to go an indirect path.

 

FHIR Option 2: Pull All Encounters and then get Procedures of the Encounters to find our patients

The approach here was to pull all the Encounter resources in a given date/time range with the filter on “class” field to only pull the resources associated with an outpatient facility. Once we had encounters then we could have filtered out the ones against which the particular lab test had been requested by pulling the ProcedureRequest FHIR resource with encounter reference. Again it seemed doable as per the documented FHIR specs but EHRs have their own limitations in the features described below.

Epic

  • Encounter FHIR resource is only available in EPIC App Orchard Program as STU3 resource, even though it exists in actual FHIR specs since/before DSTU2. This means only the organizations that have upgraded to STU3 version of FHIR for EPIC will only be able to expose the endpoints for this FHIR resource.
  • Search parameters for Encounter FHIR resource only allow for consumers to query data on the basis of a patient/subject reference. It also allows us to filter on the basis of class but even with that parameter, we will still have to provide a patient/subject reference to query the data.

Cerner

  • Encounter FHIR resource is available as DSTU2 version resource. Cerner is working on an upgrade to R4 directly but that still work in progress.
  • Search parameters for Encounter FHIR resource only allow consumers to query data on the basis of a patient/subject reference or the identifier of the resource, there is no other parameter to query this resource.

Allscripts

  • Encounter FHIR resource is not available in Allscripts.

So this option of getting all the encounters of a location was not allowed by the major EMRs. So Technosoft integration team started to look for non-FHIR data retrieval options. Without there seem to be two sets of options: good Old HL7 2.x and vendor-specific proprietary API.

 

Option#3 – Consume EHR’s provided APIs to pull data instead of FHIR APIs

We tried to answer the question of whether this EMRs would allow access to multiple patient’s data through their API.

The approach here was to pull the desired data or Orders by using the EHR’s provided APIs instead of FHIR. Since there is no standard for these APIs each EHR exposes different endpoints with different limitations for data operations. Features/Limitations for each of the mentioned EHRs is described below:

Epic

  • The documentation of these APIs is only available for the organizations who have signed up for Epic App Orchard Program.
  • The API closest to our use case we could find is “GetPatientSchedulableOrders”. However, it has the same limitation as FHIR that consumers can only pull orders for a specific patient.
  • Epic provides access to its Caboodle database. Developers are given better access to data through different query options but this data is not real-time and thus this option can serve well for historic data review and reporting but not for a real-life patient response system.

Cerner

  • Cerner does not provide any API to pull orders.

Allscripts

Allscripts has three different products for EHRs, we have explored all these products and their associated API functionality described below.

  • Allscripts Professional EHR™ API: This API provides an API endpoint named “GetOrders” which has the capability to pull orders for all patients or for any specific patient. The only issue is that it does not have any department information or any encounter reference which would allow us to identify if a given patient is in a specific outpatient facility.
  • Allscripts TouchWorks® EHR API: This API provides an API endpoint named “GetOrders” which has the capability to pull orders for a patient or by start date/time. The only issue is that it does not have any department information however it does provide a reference to Encounter in the response for each order. The only issue is that there is no API to pull more details of a specific encounter. Even the GetEncounterList API that they provide does not have a parameter to filter the data on the basis of the encounter ID. The only workaround, in this case, could be to pull all the encounters of a specific patient associated with the order and then filter the API response to match the encounter ID and keep doing this until one finds the match. But this does not seem to be an optimal or efficient solution at all as there are multiple API requests involved just to pull complete detail of one order and even then location information would still need to be ascertained.
  • Allscripts Sunrise™ API: his API provides an API endpoint named  “GetOrders” which has the capability to pull orders for a patient and start date/time of the search. Both these parameters are required which means one can only query data for a patient at a time for a given date/time range.

 

Option 4: HL7 2.x

When all other options failed, we looked back to the older version of HL7, HL7 2.x. With HL7 2.x, we can always get an inbound Orders interface (ORU:O01) and an inbound Results Interface (ORM:R01) from any of the major EHRs. R01 can provide us with all the results for the facility. And Technosoft integration team can program the interface engine to receive only the results for a particular location. Same is true for the Orders interface.

However, this approach is time-consuming and requires expensive interface processing and implementation that lead to the invent of FHIR, in the first place. So even though this option of data retrieval is available, it is not the most desirable by most of the healthcare IT folks in the industry. And this is the fallback option one may take if all else fails.

It looks like there are issues and limitations in all the options and for each of the discussed EHRs. The FHIR standard, DSTU2-R4, provides ways to get to this data but the current level of FHIR implementation by the major EHRs do not provide such support. Vendor’s own proprietary APIs can be used with some limitations. HL7 2.x seems to be the only option for this use case. However, it has its own limitations. On the flip side, FHIR, CDS Hooks and SMART on FHIR seems to be the best option to access individual patient data.

Do you have a need to interface with a particular EMR and want to get a particular set of data? Please contact us and we can help you find the right option.

 

Starting any Healthcare Integration Project? Get Your questions answered in a Free 30 minutes consultancy!