3: Exchange Standards
Fast Healthcare Interoperability Resources (FHIR)
(Image Source: iStock Photos, DrPAS©)
Healthcare system interoperability requires foundational, structural, and semantic interoperability. The Fast Healthcare Interoperability Resources (FHIR) standard, developed by HL7, provides a mechanism to use common web tools and standards to achieve healthcare system interoperability. FHIR was developed in response to changing technologies and the need to support development using modern application design.
FHIR is a combination of a data structure and a method for sharing that data. FHIR builds on standards that were developed previously, including V2 and V3 with CDA. FHIR uses a modular approach to introducing how different parts of the specification function.
Some key standard elements that comprise FHIR’s framework for interoperability include:
- Secure data exchange using Application Programming Interfaces (APIs) over existing networks.
- Data structure in "Resources" using XML, JSON, or RDF formats.
- Semantic interoperability using existing terminology standards.
Let’s look at each of these elements.
Application Programming Interfaces (APIs)
In addition to providing specifications for information structure, syntax, and semantics for health information, FHIR specifications consider the method of exchange. FHIR takes advantage of pre-existing standards or de-facto standards for information exchange over the Internet, including Application Programming Interfaces (APIs).
An API uses an Internet URL (uniform resource locator) to send a request to a system. Just like you can type the address of a website into a browser and the browser will retrieve the page, you (or an automated system) can construct an API request to send via the Internet, requesting specific information from the recipient simply using a URL.
APIs are used widely, in all kinds of institutions and in many types of services. For example, the weather application on your smart phone uses an API to request and retrieve the latest weather information. An online flight comparison tool uses an API to retrieve and display information from different airlines. The request and the response occur without your awareness, but the interaction is as simple as a regular URL call and response.
The URL includes the address of the system or server on the Internet followed by a string of characters that specify what information is requested and in what format. The recipient system can then programmatically respond.
The parameters are determined by the system or server that hosts the data. Any system that offers API access to their data will provide a guide that lists their available data and the syntax to use to retrieve it.
RESTful API
The most common type of API is a RESTful API, and that is the type specified in FHIR. Standard RESTful API commands are used in an API request to interact with a FHIR resource: GET, POST, PUT, and DELETE. For example, to read a resource, you would send the command GET with the parameters specifying the resource.
For example, a patient uses her mobile EHR app to list her current medications. Her patient number is 1234567. Her EHR system is available at https://myEHR.com/. The app builds the API request behind the scenes:
Data Structure in FHIR
FHIR Resources represent common healthcare-related concepts such as those used in electronic health records. These are the data points that might be identified and collected. FHIR Resources are categorized based on their purpose, such as Individuals, Diagnostics, and Billing. A full list of Resources by category can be viewed on the FHIR website.
Activity
To get a sense of what a resource can look like, let’s look at an important one: Patient. Review the Patient Resource content page.
Does this look familiar?
It should remind you of the static definition from V2 that we looked at before. If you click on the XML tab under "8.1.3 Resource Content," you can see what the XML version of a patient resource might look like.
Also notice the "Examples" tab at the top of the page. This shows examples of common patient situations, such as "Newborn patient example" and "Mother of newborn patient example."
Resources are like V2 segments in that they define meaningful pieces of data that are stored or exchanged, but, unlike V2 segments, FHIR Resources can be queried or updated independently. FHIR uses XML, JSON (JavaScript Object Notation) or TTL (Turtle), which is an RDF (Resource Description Framework) format specification, to represent resources.
A resource includes a human-readable text representation or narrative (using HTML) as well as structured data, so that Resources can be used by humans as well as machines.
What is RDF (Resource Description Framework)?
RDF is a data model for metadata. It’s special for two reasons:
- It enables you to describe relationships between resources and link them, and
- By describing this relationship, it allows you to merge data even when the structures of your datasets are different.
Medical Subject Headings (MeSH) are available in an RDF format. Learn more about RDF and MeSH.
Let’s look at the narrative for an example observation in FHIR alongside the same information in machine-readable XML. This observation is a lab report for a blood culture for bacteria:
| Generated Narrative: Observation | XML |
|---|---|
<?xml version="1.0" encoding="UTF-8"?>
|
|
| Resource Observation "f206" |
<id value="f206"/>
|
|
code: Blood culture (acmelabs.org#104177; LOINC#600-7 "Bacteria identified in Blood by Culture") |
<code>
|
| subject: Patient/f201: Roel "Roel" |
<subject>
|
| issued: 11 Mar 2013, 8:28:00 pm |
<issued value="2013-03-11T10:28:00+01:00"/>
|
| performer: Practitioner/f202: Luigi Maas "Luigi Maas” |
<performer>
|
| value: Staphylococcus aureus (SNOMED CT#3092008) |
<valueCodeableConcept>
|
| interpretation: Positive (ObservationInterpretation#POS) |
<interpretation>
|
| method: Blood culture for bacteria, including anaerobic screen (SNOMED CT#104177005) |
<method>
|
</Observation>
|
Terminology Standards in FHIR
Terminologies are used throughout FHIR, whenever possible, to clearly define concepts for common use. CodeSystem is a type of FHIR Resource, allowing anyone implementing FHIR to define a code system or standard terminology from other FHIR resources.
In the observation example above, a LOINC code was used to specify the lab test:
| Generated Narrative: Observation | XML |
|---|---|
|
code: Blood culture (acmelabs.org#104177; LOINC#600-7 "Bacteria identified in Blood by Culture") |
<code>
|
The code for Staphylococcus aureus from SNOMED CT was used, eliminating any ambiguity about the bacteria identified in the patient’s blood culture.
| Generated Narrative: Observation | XML |
|---|---|
| method: Blood culture for bacteria, including anaerobic screen (SNOMED CT#104177005) |
<method>
|
Value Sets
Because terminologies and coding systems can be enormous, with sections not relevant to clinical use, implementers can choose from a variety of value sets, which are subsets of terminology and coding systems used for a particular function. For example, there is a value set to code a patient’s condition, called the condition-code value set, which is made up of a subset of terms from SNOMED CT. FHIR specifies how to define value sets. Learn more on the FHIR website.
As previously mentioned, the NLM maintains the Value Set Authority Center (VSAC), which provides downloadable access to all official versions of value sets specified by the Centers for Medicare & Medicaid Services (CMS) for clinical use. NLM also provides a FHIR terminology service for accessing VSAC value sets and supporting code systems using the FHIR standard.
Profiles
The base FHIR specification describes a set of base resources. These are designed to be very flexible and accommodating for ease of exchange. However, depending on context, it may be necessary to constrain, or limit, the options and actions of a resource. For example, certain use cases require additional specifications for resources to be fully functional or meaningful in the real-life context. A profile is a set of constraints on a resource.
The U.S. Core Profiles (and Implementation Guide) is an example of constraining the base resources for a more specific purpose: Meeting reporting requirements that are specific to the United States. Race and Ethnicity are unique reporting data elements in the U.S., and therefore they are constrained to be specific kinds of observations with a specific list of values.
FHIR Implementation Guide
Remember that implementation guides provide specific instructions and can be essential tools in standardizing the exchange of information across systems. In addition to the C-CDA Implementation Guide and the U.S. Core Profiles (and Implementation Guide) mentioned earlier, the FHIR Implementation Guide is available on the HL7 web site. The FHIR Implementation Guide provides instructions for data structures, data exchange, and security and privacy. It also offers real-world use cases such as how to use FHIR for medication management or appointment scheduling.