Review the Data Exchange Standards

Learning Objectives

After completing this unit, you’ll be able to:

• Explain the role of APIs in interoperability.
  
• Describe the purpose of the HL7v2 and FHIR R4 standards.
  

For an increasingly distributed healthcare system to function seamlessly, we need EHRs to share data, and for that, we need interoperable systems. An interoperable system in Health Cloud depends on an application programming interface (API).

APIs in Interoperability

An application programming interface is a computing interface that allows applications to talk to one another. Considered to be standard building blocks of business capabilities, APIs are reusable units that expose data securely. APIs create a layer of abstraction to simplify programming and hide the underlying complexity of software systems. APIs enable developers to connect software systems without having to create complicated source code or understand the inner workings of each system. Simply put, APIs are the messengers of a software system.

We need this API engagement layer for data exchange to take place. However, to drive interoperability, we must go a few steps further and take advantage of APIs. There are three areas of continued focus and investment: open APIs, orchestration services, and standards adoption. Let’s look at each of these.

Open APIs

In an interoperable environment, organizations need to transmit data securely. For this purpose, organizations must build enterprise-scale API management systems. For example, Salesforce supports commonly used APIs such as REST, SOAP, Bulk, and Streaming as well as API-enabled fields that support synchronous or asynchronous flows. Open APIs ensure that the endpoints through which data is exchanged are secure. 

Orchestration Services

Reusability is another important factor in achieving interoperability. We must move away from point-to-point integration and toward enterprise reusability through orchestration services that use APIs to bring data, devices, and applications together. Unified data can then be used by applications owned and managed by the business, bringing the end user closer to the business.

Standards Adoption

Although open APIs and orchestration services drive interoperability, they depend on adoption of industry standards. The Cures Act Rule and Interoperability & Patient Access rule both emphasize interoperability for exchanging health data and allowing patients to access their own health information. And they both identify Health Level 7® (HL7) and Fast Healthcare Interoperability Resources® Release 4.0.1 (FHIR R4) as the foundational standards to enable data exchange. The Cures Act Rule also identifies the United States Core Data for Interoperability (USCDI) standard as necessary for adoption. Together, HL7, FHIR, and USCDI standards aim to drive interoperability by integrating clinical and patient data. Strong standards adoption leads to better data integration and more interoperable systems.

Explore the HL7 and FHIR Standards

Standards are crucial for interoperability. HL7 and FHIR are the standards that healthcare applications use to communicate with each other.

Health Level Seven International is a not-for-profit organization that creates industry-wide standards for the transfer of clinical and administrative data between software applications. The organization created the two standards: HL7 and FHIR. For clarity in this module, when we talk about HL7, we mean the standard. We refer to the organization as Health Level Seven International.

The HL7 Standard

HL7 has its own set of words with specific rules for structuring sentences. It also comes in various versions, with HL7v2 being Health Level Seven International’s most commonly used information exchange standard. HL7 uses messages with reusable segments to convey health information between systems. Data that isn’t defined in an HL7 message can be added via locally defined message segments known as z segments, placed anywhere in the standard HL7 message.

But the different versions of HL7 can’t talk to one another. So if Hospital A uses HL7v2, and Hospital B uses HL7v3, the two hospitals can’t communicate with each other. Despite HL7v2’s incompatibility with HL7v3, HL7v2 is widely used because it is highly flexible. HL7v2 has various versions, such as HL7v2.1, HL7v2.3, up to HL7v2.6, which are backward compatible with each other. However, please note HL7v2 versions are compatible only with previous HL7v2 versions. For example, HL7v2.4 is backward compatible with HL7v2.3, but HL7v2.3 is not forward compatible with HL7v2.6.

So what does an HL7v2 message look like? Let’s review a sample message.

You might recognize various abbreviations in the message, like MSH, PV1,^, and so on. These are special characters that mean specific things.

• MSH signifies the beginning of every HL7 message.
  
• PV1 means that the message is about a Patient Visit event.
  
• ADT indicates an Admit, Discharge, Transfer event.
  
• | is a special character that divides a message into segments.
  
• ^ is a special character that divides information within a segment into subparts.
  

But HL7 isn’t the only standard used by interoperable systems. There’s also FHIR.

The FHIR Standard

Created by Health Level Seven International, FHIR is an API standard that enables the exchange of clinical and administrative data between software applications such as EHRs. Health Level Seven International’s latest release is FHIR v4.0.1, which is very popular and widely used for these reasons.

• Many resources reached a normative stage in FHIR R4, meaning that they are developmentally complete and won’t be significantly altered in the future. FHIR R4 can therefore be implemented by the industry and expected to remain stable.
  
• FHIR R4 is backwards compatible. This ensures a smooth exchange of data with systems using older versions of FHIR.
  
• Like HL7v2, FHIR R4 supports an event-based messaging paradigm. But unlike HL7v2, it also supports other paradigms such as REST, documents, and other service models.
  
• While HL7 uses a complex file format called the electronic data interchange (EDI), FHIR R4 uses REST API, which is simpler than EDI. To learn more, see Use REST API in the Lightning Platform API Basics module on Trailhead.
  

The basic building block of FHIR, a resource is an entity that contains data that can be stored or exchanged between health record systems. A resource type can be clinical, administrative, or financial, each involving further subtypes.

A resource has these components.

1. A set of structured data types with reusable patterns of elements.
   
2. An identifiable address (the URL). This address can be a movable location URL indicating where it can be accessed, or the canonical URL, which is an inherent and fixed identifier that is part of the resource.
   
3. Metadata, which provides technical and workflow context to the resource. These are mostly optional.
   
4. An identifiable FHIR version against which the standard is written. If the FHIR version changes, the contents of the resource change too.
   
5. A human readable part that contains a summary of the resource.
   

This is an example of the Patient-example-mom resource. The data type (id) has a human readable summary (mom), a metadata (here empty), a URL (Link) and refers to an identifiable FHIR version (v4.0.1).

In the next unit, we dive into the Health Cloud clinical data model, which aligns with FHIR R4.

Resources

• External Site: HL7 International
• External Site: HL7 FHIR Release 4
• External Site: Data Types
• External Site: HL7 FHIR Release 4 (Patient-example-mom)
• External Site: What is an API? (Application Programming Interface)