HL7v2 is the most widely used healthcare messaging standard for exchanging clinical and patient information between systems. The goal of HL7v2 was to provide enterprise-wide interoperability between health information systems using standardized messages representing clinical event information - such as patient administrative activities, demographics, medical orders, results and financial information.
With no other standards available at the time, a custom HL7v2 format was created based on pipe and hat encoding and has continued to be developed “ad hoc” over the years. All v2.X versions maintain backward compatibility to ensure legacy and modern applications can communicate simply by ignoring unexpected content or repetitions.
The HL7v2 standard is not a complete plug-and-play solution for interoperability and it is often referred to as the “non-standard standard” as it provides around 80% of the interface foundation with 20% still requiring some customization on an interface-by-interface basis. This is due to the nature of healthcare and its different interactions with patients, healthcare personnel, clinical and operational data. Each hospital, urgent care center, ambulatory care facility, imaging center, laboratory, and other care facilities have unique clinical systems and operations, making each implementation of HL7 require a slightly unique representation of the data. The standard enables this flexibility through allowing flexibility in defining optional and repeating segments, optional fields, and additional custom z-segments.
HL7v3 has been developed over a 10+ year period using lessons learned and best practices from previous versions with the goal of creating a more firm and context rich standard that supports healthcare workflows through the exchange of data between healthcare organizations and providers. HL7 developed v3 based on a methodology of shared models, the Reference Information Model (RIM), enabling more reuse, standardization and format consistency. XML is used as the message syntax for a more human readable, but larger message.
Due to several reasons, including its complexity and the fact that HL7v3 is not backwards compatible with HL7v2.X, has hindered its adoption across healthcare organizations with existing v2 implementations. HL7v3 is primarily referenced when implementing Clinical Documentation Architecture (CDA) for exchanging electronic documents, typically between provider and patient or for public health and quality reporting initiatives.
FHIR is the latest standard to be developed under the HL7 organization. Pronounced ‘Fire’ , FHIR stands for Fast Healthcare Interoperability Resources. It is a standard for exchanging healthcare information electronically and combines the best features from HL7 v2, HL7 v3, and CDA, while also adding several significant improvements over previous standards.
FHIR includes data formats (resources on patients, medications, encounters, etc.) as well as application programming interfaces (APIs) that exchange these resources. It was developed to become a dominant standard that allows external parties to access information from EMRs through the use of applications. It also allows third parties to create their own applications that can access these servers. For example, EHRs such as Epic and Cerner, have their own FHIR app stores where providers (doctors, clinicians, etc.) as well as patients can access their data through these 3rd party applications. FHIR standards utilize SMART (Substitutable Medical Applications, Reusable Technologies), an authentication framework for the connection of 3rd party applications to EMRs.
Comparatively, FHIR offers several advantages over existing HL7 standards:
Similar to the previous HL7 standards, FHIR has also undergone several rounds of versioning, with each new version implementing changes and improvements around resource types, bindings, code elements, modifier statuses and default values:
|Dec 27, 2018||4.0.0||Release 4 (1st Normative Content and Trial Use Developments)|
|Feb 21, 2017||3.0.0||Release 3 (STU - Standard for Trial Use)|
|Oct 24, 2015||1.0.0||DSTU2 (Second Draft Standard for Trial Use)|
|Sept 30, 2014||0.0.82||DSTU1 (First Draft Standard for Trial Use)|
Each FHIR version is both forwards and backwards compatible, allowing for older specification versions to remain interoperable with future versions. Iguana is able to support all four FHIR versions and has the flexibility to allow SMART on FHIR applications to be built within it. These applications are able to connect to EMRs and can be authenticated according to SMART standards. In addition, SMART on FHIR apps built within Iguana can be made to adhere to Da Vinci Project use cases.
To learn more about how Iguana can assist in connecting to EMRs through the use of SMART on FHIR application or for anything else integration related, contact us.