The Evolution of Interoperability Standards

Healthcare has undergone many changes in the past few years and to make the care ecosystem work better, organizations need to be able to quickly and securely share information.

That's why the Fast Healthcare Interoperability Resources (FHIR) was created as a standard for healthcare data interoperability to help make healthcare data more efficient, transparent, and secure. FHIR is a set of guidelines for exchanging electronic health information. It allows the uninterrupted exchange of clinical data between disparate systems and applications.

In this blog, we'll look at FHIR from the perspective of its predecessor interoperability standards. FHIR is designed to address the shortcomings of these previous approaches to truly (and securely) enable frictionless liquidity of healthcare information.

Healthcare’s Journey from Initial HL7 Versions to FHIR

FHIR was created by the non-profit organization HL7 (Health Level Seven) and is designed to be used by healthcare organizations of all sizes to enable interoperability.

Interoperability refers to the ability of different systems to work together. Healthcare has seen tremendous investment in digitization at the point of care in the past 30 years resulting in multiple silos of data. Interoperability aims to break down these silos by allowing every provider, payer, patient, and system to access relevant information when needed.

FHIR is the latest, and greatest, the definition of a set of standards to provide a common language for this interoperability. It defines how electronic health information should be formatted and coded so it can be exchanged between different systems. These standards are designed to make it easier for different systems to share data.

FHIR can be utilized in many different apps, including cloud apps, mobile apps, EHRs, etc. FHIR's objective is to reduce complexity across systems while maintaining privacy and security.

FHIR is built upon the set of HL7 standards that preceded its development, primarily HL7 V2 and V3. It addresses significant limitations of the previous standards in its versatility and flexibility and is designed from the ground up to be easy to use for web developers.

HL7 V2

HL7 V2 was first released in 1989 and remains the ubiquitous standard for exchanging information between systems within a health system. It’s primarily a push-based notification mechanism. A new event—such as patient registration, lab result, scheduling event, or clinical note—is articulated in a document that is routed to and consumed by other systems within the IT landscape. For example, when a patient transfers from the ED to the inpatient, administrative (and some clinical) information is codified into an Admit Discharge Transfer (ADT) message by the ED system to properly inform the inpatient systems about this transfer.

HL7 V2 uses the X12 standard for structuring messages, which incorporates a predefined pattern of pipes (|) and carets (^) to contain patient-specific information. This lean structure was great back in the days when bandwidth was expensive but it is very inflexible for extending data sharing beyond a core set of known patient characteristics. Sharing non-standard data elements utilizes an approach called “Z-segments” which requires the sending and receiving systems to coordinate on the meaning of unlabeled data and is prone to error.

HL7 V2 handles specific administrative and clinical events. It does not address how to share a complete patient health record between systems, say to enable efficient coordination of care for providers on the care team using different clinical systems.

HL7 V3

HL7 V3, also known as Clinical Document Architecture (CDA), was released in 2010 to address these challenges. It provided a way to render a complete patient history into a single document, such as the Continuity of Care Document (CCD) for sharing longitudinal information with the care teams. It leveraged eXtensible Markup Language (XML) instead of X12 where the data describes itself within the document which provided for greater and more flexible handling of data extensions and an easier programming model.

Using X12, you would need to know that the patient’s last name is the seventh field created within the fifth piped field on a line labeled as “PID.” With XML, it is the field tagged <family> within the field tagged <name>, a much simpler approach for programmers.

Electronic Health Record systems adopted this standard through legislative efforts (meaningful use), though establishing true interoperability has proved to be a significant challenge. For complicated clinical patients, this document was massive and very unwieldy and became complex to attempt to process the clinical details into a health record. It required a manual reconciliation workflow for a clinician to decide what to accept to ensure the sanctity of the health record and avoid adding a lot of redundant information. Its primary usage became not one of true system interoperability, but another document that the physician at the point of care would need to page through and interpret along with the information in his or her EHR.

HL7 V4: FHIR

HL7 V4, or FHIR, does an elegant job of addressing limitations of V2 and V3. It defines a set of resources, each one is a snippet of health information (e.g. medications, allergies, demographics) which can be independently leveraged (like V2) or stitched together into a complete picture of health (like V3). This provides a consistent approach to represent health information for really any type of data sharing scenarios.

These resources are exchanged using self-describing formats, primarily JavaScript Object Notation (JSON) which provides a simple data programming model. A human can look at a FHIR resource and understand what is being conveyed without having to reference a complex schema.

FHIR is also inherently extensible to handle new data elements. Each resource has a predefined set of attributes and built-in is the ability to define new elements for data exchange.

FHIR is primarily used today for pulling information. For example, retrieving a progress note for a specific patient, though can also be used in push exchange and batch scenarios.

And lastly, FHIR is designed explicitly for web development and uses the preferred RESTful interface model for data exchange—the prevalent programming model for the web. This is a model familiar to developers across industries and greatly lowers the learning curve for developers.

The Road Ahead

Interoperability is recognized as a key foundation capability that will open up the digital silos of healthcare data and enable innovation and digital transformation. FHIR has been architected as healthcare’s lingua franca for this data flow, overcoming many limitations of previous standards.

Over the next few posts, I’ll explore the value that FHIR can unlock while also discussing the limitations of interoperability that FHIR by itself does not address.