FHIR: Modernized Healthcare EDI

Enterprise organizations constantly push for ways to modernize and streamline their data movement. EDI standards (e.g. ANSI X12, HL7) have long been the dominant paradigm for data modeling and communication within the healthcare industry, but a new data standard developed by HL7 International has already garnered significant attention among savvy industry professionals.

The Fast Healthcare Interoperability Resource, or FHIR (pronounced "fire"), promises a sleek and convenient alternative to EDI-driven data exchange. This article aims to provide an overview of what FHIR is and why you might incorporate FHIR into your data processing solution.

What is FHIR?

FHIR solves the same problem that EDI solves: in order to effectively communicate data, there must be a standard way of modeling that data so that all parties can understand what the data represents. At its core, FHIR is simply a description of how healthcare data can be organized and presented so that the meaning of the data is clear.

Fundamental to the development of FHIR was the need to simplify how healthcare data can be exchanged between parties. As healthcare data becomes more widely digitized, and the interoperability between different healthcare systems becomes critical, FHIR's streamlined data model aims to help mitigate the compounding complexity of building robust healthcare data solutions.

In order to better understand FHIR, its worth digging into the technical details that distinguish it from its predecessor -- EDI.

What Makes FHIR Different from EDI?

FHIR is an API-driven data standard, while EDI is a document-driven data standard. This difference has two major implications:

• FHIR data payloads can be more flexible, since they are based on API resources rather than full EDI documents
• FHIR data transfer is simpler than EDI (FHIR uses the same transfer technology used by ordinary web browsers)

API Resources versus EDI Documents

To understand why FHIR data payloads can be more flexible, its helpful to understand the concept of API resources. An API resource represents any set of information that can be sensibly grouped together. As a basic example, it may make sense to group a name, address, and phone number together in order to represent a shipping customer. The FHIR specifications define many different API resources that represent the common "units" of healthcare data exchange: patients, claims, service locations, etc.

API resources, such as those defined by FHIR, can be grouped into hierarchies to create more complex data models out of relatively simple building blocks. As a result, API-driven technologies like FHIR can support a wide range of communications by combining API resources in customized ways. In contrast, EDI document models are designed from the top-down to capture a rigid set of information. While these document models are effective at defining specific data transactions, they are limited in their flexibility and allow little in the way of customization.

API Requests versus EDI Transfer

APIs operate using a request-response model. This means that communicating using the FHIR standard functions similarly to asking a question and immediately receiving an answer. This is the same technology used by a common web browser: when you click on a link, your browser requests the corresponding web page from a server, and the server's response is what you see on your screen.

In contrast, EDI requires a separate protocol to transfer documents to remote parties. Common transfer protocols include AS2 and AS4, and while these protocols do effectively transfer data, they add layers of data packaging, extra mechanisms for receipt and proof-of-delivery, and other complexities. The request-response model of API communication provides the same benefits that these transfer protocols offer, but does so in a considerably more streamlined manner.

Why Should You Use FHIR?

Even outside of the healthcare industry, data movement is consistently becoming more API-driven. The benefits that FHIR provides compared to EDI are an example of this more global trend, and they include:

• Simplicity
• Flexibility
• Enhanced Interoperability

FHIR simplifies healthcare data exchange by reducing the layers of complexity required to package data and send it to a remote party. Additionally, the FHIR standard uses the same simple request-response technology to send and receive data that forms the backbone of the internet.

FHIR allows for more flexible data consumption by replacing rigid EDI documents with flexible API resources. Resources serve as logical building blocks out of which customized data models can be built. EDI documents, on the other hand, provide functional but inelastic representations of healthcare data.

Interoperability is another benefit of moving towards API-driven communication. The simplicity and flexiblity of API resources helps tremendously during the process of converting data from various disparate sources into an outbound API request. In other words, FHIR makes it easier to convert your data into the format required to communicate with others.

CData Arc Supports FHIR

CData Arc includes powerful API connectivity tools that can augment EDI solutions with modern data standards. The REST Connector can generate customized dynamic web requests to interface with any standard REST API like FHIR. CData Arc's workflow canvas makes it easy to add FHIR-driven communication to your existing EDI solution.

In order to ensure that API integrations fit seamlessly into your existing data flow, CData Arc's visual data mapping tools simplify the process of converting your data into the format that FHIR requires.

For more information on FHIR support in CData Arc, please feel free to reach out to our technical team at [email protected].

Download a 30-Day Free Trial of CData Arc

Download CData Arc to start modernizing your healthcare data processing today.

Download CData Arc