Life Sciences

Interact with Epic on FHIR to Visualize Patient Data

September 13, 2022 — by Franziska Rau &  Ali Asghar Marvi
Interact with Epic on FHIR to Visualize Patient Data

Consolidate Patient Data in a Dashboard with KNIME

Healthcare data is complex. It is stored in multiple places, in multiple computer systems, and comes from multiple departments. This makes it difficult to use, measure, and share.

The Fast Healthcare Interoperability Resource (FHIR) was defined to improve data interoperability. It is one of the most popular protocols for joining disparate systems and it facilitates exchanging and sharing information on clinical health data and other electronic health records. It allows interoperability among healthcare systems to provide information to organizations and individuals on a wide variety of smartphones or computers. It also enables third-party vendors to create their own custom applications based on FHIR standards.

In this article, we’d like to show how you can build a browser-based application with KNIME that accesses healthcare data via the FHIR-based API that is provided by Epic on FHIR.

Application-based Interoperability for Seamless Data Exchange

EPIC on FHIR Dashboard in KNIME

Many electronic health record systems utilize the FHIR standard and provide free resources for developers to create healthcare apps for patients and healthcare organizations

FHIR utilizes an application programming interface (API) to exchange electronic health records (EHR) and electronic medical records (EMR). The protocol uses common standards such as JSON, XML, or RDF on REST-based protocols.

Epic on FHIR or Cerner are examples of such free resources for developers. They provide not only FHIR-based resources, but also a complete set of additional features like dedicated servers, cloud services, sandbox data to play with, and much more.

The Epic-on-FHIR Sandbox Environment

In this article, we will talk about how we accessed example data using the FHIR-based APIs provided by Epic on FHIR and consolidated and visualized it in a dashboard.

The Sandbox Test Data by Epic consists of a set of patients, each with a unique FHIR ID and corresponding resources of their medical history. In the screenshot below (Fig. 1) you can see there is a test patient called Derrick Lin with a FHIR ID and portal login credentials for the sample patient application.

Application credentials are for testing by developers, however we want to talk more about the applicable resources against the FHIR ID, and demonstrate how we called some of them in KNIME and visualized it all in a consolidated dashboard.

Fig:1 Sample of FHIR patients from the sandbox environment provided by EPIC.

How to Call Epic-on-FHIR Web Services in KNIME

The first and most important step is to create an account on Epic on FHIR. Once that’s done, head to the “API Specifications” tab on the menu bar to see the list of available APIs (Fig. 2). 

For our example, we will only call four web services:

  • Patient.Read (R4) - basic patient information like name, age, address and more

  • Condition.Search (R4) - all past conditions of a patient

  • MedicationRequest.Search (Orders) (R4) - medication prescription based on conditions

  • Goal.Search (Patient) (R4) - medical prescription of various therapies

Each service is based on the R4 version of HL7 for data interoperability. It takes the patient's FHIR ID as input, and the relevant data is returned in XML format. It is subsequently converted into JSON format to extract the necessary fields, and finally, visualized in KNIME.

Fig. 2: Snippet showing the huge list of web services available (left) in EPIC on FHIR

Web Services for Patient Conditions, Prescriptions, and Health Goals

Web services or APIs are called into KNIME and parsed to extract the information we want to visualize. In our example, we used the FHIR ID of the test patient, Derrick Lin, highlighted in Fig. 1. This patient is fictitious, and is from the Sandbox environment provided by Epic.

In order to call each web service, Epic requires a bearer token to be sent as header. You’ll see the bearer token in the Raw Request (Fig. 3) of any selected API from the list (Fig. 2). The workflow requires that you add this token in the configuration window, and it is propagated as a flow variable for each web service call.

Fig.3: Bearer token from trying out a patient’s web service.

Let’s now have a closer look at these web services.

Patient.Read (R4) for Basic Patient Information

This web service is called in KNIME using the “GET Request” node. The xml returned is converted to JSON format, and necessary fields are picked using the “JSON Path” node. The extracted fields include “Official Name,” “Date of Birth,” “Sex,” etc. This is the demographic and administrative information of the person receiving healthcare from the organization.

https://fhir.epic.com/interconnect-fhir-oauth/api/FHIR/R4/Patient/eq081-VQEgP8drUUqCWzHfw3

Fig.4: Rest endpoint for the patient. The part highlighted in bold is the FHIR id of the patient.
Condition.Search (R4) for a Patient’s Previous Conditions

Similarly to calling a patient's rest-based endpoint, the “Condition” web service searches for the condition and diagnosis of a given patient, along with their clinical status and reason for visit – in this case for “Derrick.” The parsed data is visualized inside the view component. This web service takes in a patient’s FHIR ID as a search parameter.

https://fhir.epic.com/interconnect-fhir-oauth/api/FHIR/R4/Condition?patient=eq081-VQEgP8drUUqCWzHfw3

Fig. 5: Rest endpoint to search condition of a given patient.
MedicationRequest.Search (Orders) (R4) for Medication Prescriptions

Based on the diagnosis, a patient is prescribed medication or any relevant therapy along with dosage by the practitioner. In this case, this web service returns the medication request by the patient. This could be used by relevant pharmacies or medical institutions to keep track of patient’s consumption. The rest endpoint (Fig. 6) takes in the patient's FHIR ID as a search parameter in the form of a query parameter.

https://fhir.epic.com/interconnect-fhir-oauth/api/FHIR/R4/MedicationReq…?patient=eq081-VQEgP8drUUqCWzHfw3

Fig. 6: Rest endpoint to search prescribed medication of a given patient.
Goal.Search (Patient) (R4) for the Targeted Health Outcome

Every prescribed medication has an end goal associated with a patient: Obviously, an improvement of their existing conditions. The “Goal” rest service is called to identify desired health outcomes associated with Derrick. This rest point also takes in the patient's FHIR ID as a search input (Fig. 7).

https://fhir.epic.com/interconnect-fhir-oauth/api/FHIR/R4/Goal?patient=eq081-VQEgP8drUUqCWzHfw3

Fig. 7: Rest endpoint to search desired health goal of a given patient.

Visualizing Healthcare Data in a Dashboard

After consuming all the rest points and parsing the necessary information, we visualized it using Tile View for each category. All tiles are put together inside a component and organized to view it in one consolidated dashboard. To learn more about creating a dashboard in KNIME, this blog will help you understand its fundamentals.

Fig. 7: Consolidated visualization of data from each EPIC on FHIR services.

An EPIC-on-FHIR Patient Dashboard

In summary we can say that we have successfully accessed several EPIC on FHIR services in KNIME to visualize a sample patient from a sandbox environment.

However, it is important to note that for production-based environments, any health institution using EPIC on FHIR needs to have a middleware to cater for authentication issues – such as getting access tokens in this case. The visualization in KNIME will be the final step.

Try out our example workflow for this dashboard and download it from the KNIME Hub: EPIC on FHIR (Patient Dashboard).

Explore the workflow behind the Epic-on-FHIR Patient Dashboard on the KNIME Hub

You Might Also Like

What are you looking for?