The evolution of HL7 Standards: V2 to FHIR

HL7 is the abbreviation for the term, Health Level-7.   The organization, HL7, provides international standards for the structuring and transmission of clinical and administrative data in the healthcare domain.   One HL7 interoperability specification used for many years has been version 2.x, otherwise known as V2.  V2 has been a standard used to codify medical (led by billing) information and transmit it between computerized medical systems. The standard was developed and finalized during the 1980s, and thus was optimized for lower memory and storage usage in the very early stages of networked computing; thus it was an implicitly typed flat-file.

While everything in V2 was text-based, it was a grid of information separated by a vertical text character known as a “pipe” (|). In order for a user to read it, he/she had to know the order of the fields and needed different glossaries to sort out the meanings of various codes.  It was very thorough, but at the same time, having information in the wrong order or adding extra information could break the meaning of the whole message.  It also only allowed for about 20% customization.

Here’s more information, including examples, of HL7 V2.    Source:  Ringholm Whitepapers: http://ringholm.com/docs/04300_en.htm

After V2, came Version 3 (V3).  V3 was an additional standard to V2 developed during the 1990s that focused on customization and incorporation of web-service technologies and the Extensible Markup Language (XML) that came with it.  The data was explicitly typed (being defined by an element or attribute title) and could more flexibly be regulated and defined by schemas.  There was also more flexibility introduced with extension logic. But while it was easier for humans to read, it involved massive documents and very rigid structures and programs that were designed to work with large document-object-models. Often, a user needed a computer program to interpret the meaning in an easy-to-comprehend format.

Here’s more information, including examples, of HL7 V3.  Source:  Ringholm Whitepapers: http://ringholm.com/docs/04300_en.htm

Along with V3 came a data exchange model known as Clinical Document Architecture (CDA).  While HL7 V2 and V3 were focused on messaging (updating various systems and their users about changes), CDA focused more on patient documents at a given point in time (e.g., a patient’s Hospital Discharge Summary document). It also aimed to standardize Clinical Documents and make them more human-readable when it came to patient information.  It included a simplified, flexible schema and had an explicit human-JavaScript Object Notation (JSON)readable section at the end which summarily stated the document information and purpose.

Here’s more information, including examples, of CDA.  Source:  Github Project Examples: https://github.com/brettmarquard/HL7-C-CDA-Task-Force-Examples/blob/master/No_Known_Medication_Allergies_Status_with_Author_Timestamp.xml

Fast Healthcare Interoperability Resources (FHIR) is a very new draft standard for the exchange of resources.  FHIR is a set of “best-of” standards and implementation resources from HL7 V2, HL7 V3, and HL7 CDA.  FHIR is broken up into resources that can be combined to handle the majority of emerging medical messaging and documentation needs, and each resource has a common way to identify them, common metadata, and a human readable portion.

Like other HL7 evolutions, FHIR is taking advantage of newer web technologies that emerged in the 2010s; integrating with standards like JavaScript Object Notation (JSON) in addition to XML and describing how to build a Representational State Transfer (REST) –based message processing architecture. Thus, not only can one use HL7 compliant messages and documents from phones, but one can implement HL7 standards and guidelines in the new massive cloud computing resources. The human (vs computer) readability has also been enhanced: with sections that came at the end of CDA documents now interspersed within each FHIR resource.  Data can be codified in JSON in addition to XML which makes it easier for lighter weight applications to process. A large focus of the FHIR resources is also on implementation guidelines that can be used by developers for a wider range of platforms, devices, and technologies. New document structures can be defined and imported to support emerging information needs that weren’t considered when FHIR was first drafted, and HL7 provides more information and examples about how to interpret FHIR messages on different platforms.

You can learn more about FHIR at this site:  http://hl7.org/implement/standards/fhir/

It is also important to note that HL7 V2, V3, CDA and other released standards can be found in both legacy as well as newly developed IT systems. today and in new systems.  HL7 is creating and updating standards to be used as tools in response to an ever changing landscape of needs, but isn’t trying to influence which standards are used for various messaging and documentation functions.  Most of the guidance HL7 issues have to do more with data integrity and security using whatever standard developers choose.