Patient-Centered Radiology with FHIR: an Introduction to the Use of FHIR to Offer Radiology a Clinically Integrated Platform

FHIR is an interoperability standard developed by Health Level Seven (HL7) that functions as an API for developers to access needed clinical information from the EMR. FHIR leverages decades of experience in healthcare interoperability with HL7 Version 2, the predominant interoperability standard used today in medical systems for EMR integration. HL7 Version 2 utilized a push-based broadcast messaging system to pass information between systems. To access information with HL7 Version 2, external software would need to listen to a stream of messages that describe clinical events. Only upon receipt of a message could external software collect and process the information. This message-based system of HL7 differs from FHIR’s service-oriented system which permits external software to ask specific clinical questions and obtain an immediate response. An example is being able to ask, “Who are the patients that are currently admitted to the hospital?” with FHIR, instead of compiling a list of patients by listening to a stream of admission and discharge events with HL7 messages. This service-based approach promises benefits such as interoperability, extensibility, and speed when searching for specific information in many different clinical applications [5‐7].

A second key advantage of FHIR is the World Wide Web Consortium (W3C) compliant format that follows a language and structure well-established and commonly utilized in the web development community. It is the same format that organizations such as Facebook or Twitter use in their APIs. The structure is called a representational state transfer (RESTful) architecture which standardizes methods to search for, update, and delete data. This also differs from HL7 which required creation of its own transport mechanism when first developed in the 1980s.

One clear benefit with FHIR for the field of radiology is the ability to quickly probe for relevant clinical information. The power of FHIR comes from the simplicity of the queries to fetch specific data, eliminating the need for complex searches in the EMR. One example is the ability to query specifically for the presence of an iodinated contrast allergy, instead of authenticating with the EMR and searching through a list of all the patient’s allergies. With FHIR, imaging software can query clinical information mined from the EMR and integrate it with other clinical systems used by the radiologist.

SIIM hosts a cloud-based FHIR server as part of its annual hackathon [8]. This server is accessible to SIIM members yearlong after registration for an api key. The URL to the FHIR server is:

Registration for an api key for SIIM members [9] can be done at:

A variety of free and public servers are also available to software developers for testing.

Toronto’s University Health Network (UHN) hosts a convenient public set of FHIR servers prepopulated with a large amount of test data and readily accessible through a user-friendly browser interface [10].

Several of these servers can be accessed with simple URL calls through the browser, allowing testing of queries and analysis of responses returned. For querying the SIIM FHIR server as recommended in the hackathon, a free tool called Postman (available https://​www.​getpostman.​com/​) permits users to query a FHIR server in an easy-to-use interface and view the results without writing code. Figure 1 shows how to configure Postman to use the SIIM Hackathon FHIR server, noting how to include the required apikey in the application calls to the server.

In practice, an application would make the API calls to the FHIR server to obtain data and display it in the software’s user interface. Note that many of these FHIR servers are in variable stages of development and may not support all features at this time, and the servers and standards themselves are subject to active revision which may have changed from this writing. It is likely that many of the queries in this article will require modification with ongoing changes to FHIR and updates to the SIIM FHIR server; however, the fundamental principles and design of the queries will be similar.

The fundamental building block of FHIR is called a “resource”—or the type of information of interest in the EMR one is seeking to obtain. For example, a specific patient can be queried by accessing the “Patient” resource. A particular physician can be queried through the “Practitioner” resource. The “DiagnosticOrder” resource contains the orders placed by clinicians for imaging studies and can be used to generate worklists, as described in the following section (note: this has been named “ProcedureRequest” in FHIR Release 3). Table 1 highlights the FHIR resources most relevant to medical imaging. The complete list of the FHIR resources is well-documented on the HL7 website [12]:

Constructing a query is as simple as putting the name of the desired resource at the end of the server URL. For example, all DiagnosticOrders can be accessed with the URL:

Querying the URL will display the results of all DiagnosticOrders—regardless of status or type of study—in a standardized format called JavaScript Object Notation (JSON) which is a human-readable text that is commonly used to pass data in development environments and can be processed in a variety of software tools. The results of this query include data for a large number of DiagnosticOrders as illustrated in Fig. 2. Each individual DiagnosticOrder contains additional elements that include information such as the status of the order, the physician who placed the order, and the specific type of order. These attributes give an indication of how the resource can be queried.

The power of FHIR comes from the ability to construct queries with parameters to specify a search. For example, the DiagnosticOrder resource contains a “status” parameter which indicates whether an order has been requested, completed, or canceled. All pending orders that have been requested but not yet completed can be queried by including the “status” parameter in the query as follows:

http://​api.​hackathon.​siim.​org/​fhir/​DiagnosticOrder?​status=​requested

In the setting of radiology, these parameters can be used to generate worklists and protocol lists in conjunction with parameters that specify the imaging modality or body site.

The DiagnosticOrder resource can be queried by the parameter “code,” where “code” is a numeric representation of the type of order, such as a radiograph of the abdomen or a CT scan of the chest. As displayed in Fig. 2, the code for a CT chest is “24627-2”, noting that the system of coding refers to the Logical Observation Identifiers Names and Codes (LOINC) database [13]. Querying for all pending chest CTs would then be as follows:

http://​api.​hackathon.​siim.​org/​fhir/​DiagnosticOrder?​status=​requested&​code=​24627-2Queries like this can be used to generate radiology worklists and can also serve to dynamically compute metrics such as the number of pending studies.

The patient-centered approach that is made possible through FHIR comes from the ability to obtain clinically relevant patient information and integrate it directly with the medical imaging software that is used to protocol or read studies. Clinical information can then be actively used within the radiology workflow rather than being locked away in the EMR.

The following queries demonstrate how to first access information related to the patient and subsequently use it to query for information relevant to protocoling and reading studies.

Most resources contain an element called “subject” or “patient” and this is a link to access the resource of the patient, typically of the form “Patient/id” such as:

Patient/123

“123” here refers to the patient’s identifier in the FHIR server. Accessing the Patient resource can be done as:

This query will provide basic information such as the patient’s gender and date of birth.

The patient identifier can be used in conjunction with other FHIR resources to search for relevant patient data in the EMR. For example, when protocoling a study, the radiologist requires information related to the patient’s kidney function from a lab test called the creatinine in addition to information such as the patient’s allergies.

Searching for the patient’s creatinine with FHIR can be done with a single query as follows:

In this query, Observation is the resource that contains the results of laboratory data, 123 refers to the patient’s identifier, and 2160-0 is the LOINC code for creatinine.

Retrieving the patient’s allergies can similarly be performed with the patient identifier parameter on the AllergyIntolerance resource:

This query would generate a list of the patient’s allergies. With FHIR, a single query can be used to search specifically for contrast allergies:

where 407935004 is the Systematized Nomenclature of Medicine (SNOMED) code for contrast media.

When reading a study, a radiologist often utilizes information such as a history of the patient’s surgeries, laboratory values, and clinical notes to provide a more educated interpretation of a study.

Generating a list of a patient’s prior surgeries can be performed by querying the Procedure resource:

Laboratory values can also be easily integrated into the reading environment. For example, a radiologist reading a thyroid scan can have access to laboratory tests that indicate the patient’s thyroid function via:

where 24348-5 is the LOINC code for the thyroid-stimulating hormone panel.

FHIR also provides the potential of querying clinical notes. With FHIR, a single query could be used to access the last clinical assessment written by the ordering provider of the study. Each DiagnosticOrder resource contains a reference to a Practitioner resource who ordered the study in the format:

where 5144 refers to the practitioner’s identifier on the FHIR server. The Practitioner resource contains useful information such as the clinician’s contact information and can be used as a parameter with other resources to query for assessments or notes. A query for the last clinical note written by the ordering provider of the study could be performed via:

where ClinicalImpression is a resource in development for storing clinical notes.

The annual SIIM Hackathon challenges users to develop software integrations using standards like FHIR to innovate new solutions to healthcare problems. Samples from the 2016 SIIM Hackathon are included in Fig. 3a–c and illustrate what a fully integrated system with FHIR and DICOMWeb could look like in the radiology workplace. Instead of having a worklist driven by imaging, at the forefront is the patient with the relevant clinical information logically organized (Fig. 3a, b). With API tools like DICOMWeb, medical images can be directly embedded into the clinical workflow (Fig. 3b) [14]. API access to the data in the FHIR server also offers real-time quality metrics (Fig. 3c). All these features can be streamlined into a single platform which can unify the radiology workflow into a cohesive user experience driven by a patient-first clinical focus.