HL7 vs FHIR - Evolution around Healthcare Interoperability
Howdy! We are back with yet another post on interoperability, this time we are covering how we reached here!
Introduction
Interoperability is the ability of different information systems and devices to access, exchange, integrate and use data in a coordinated manner, spanning within and across organizations and regions and has proved to be one of the most complex and challenging imperatives for healthcare. The current pandemic reiterates the importance of being able to exchange data understandably, accurately, securely and quickly.
Interoperability is achieved in part using consistent standards that define the syntactic and semantic meaning of information. With the growing volume of health data, standards were needed to support interoperability.
Increased adoption of the EHR and the explosion of a number of clinical applications created the necessity for a standard consistent language to streamline the exchange of information between electronic health applications. This led to the emergence of HL7 standards. HL7 is a set of international standards that provides a framework for the exchange, integration, sharing and retrieval of health information. HL7 stands for Health Level 7 and was created by Health Level Seven International, a non-profit organization. HL7 can be described as a transfer protocol used to exchange data between health care databases. It is called level 7 because it focuses on the application layer, also referred to as layer 7. The standards define how patient information needs to be structured, packaged and communicated between disparate healthcare applications.
Before advent of HL7 exchange standards, healthcare IT systems performed data exchanges by creating customized interfacing systems that were built through extensive programming efforts. Since there had been no standard data formats for collecting and storing patient data, the value of building such interfaces was prohibitive. HL7 data standards served to simplify such implementations, greatly reducing the cost and time involved in custom interface programming.
HL7 Messages
Health data that uses HL7 standards is sent as a collection of one or more messages. Each message transmits one record or item of health-related information. Examples of HL7 messages include patient records, laboratory records and billing information.
HL7 messages, comprising of sequential segments, are triggered by events such as “Patient Admission”. Such segments may be “required”, “optional” or “repeatable”.
There are different types of HL7 messages designed to exchange data between healthcare applications and may include patient data, laboratory records and billing information.
Example, HL7 ADT (Admit, Discharge and Transfer) messages are used to exchange information such as patient demographics, patient visit and patient registration and so on. Being one of the most widely used message type, provides information for trigger events such as patient admissions, registrations, cancellations, updates, discharges, patient data merges, etc.
The following sample shows a HL7 2.4 ADT^A04: Patient Registration message:
MSH|^~\&|MESA_ADT|XYZ_ADMITTING|iFW|ZYX_HOSPITAL|||ADT^A04|103102|P|2.4||||||||
EVN||200007010800||||200007010800
PID|||583295^^^ADT1||DOE^JANE||19610615|M-||2106-3|123 MAIN STREET^^GREENSBORO^NC^27401-1020|GL|(919)379-1212|(919)271-3434~(919)277-3114||S||PATID12345001^2^M10|123456789|9-87654^NC
NK1|1|BATES^RONALD^L|SPO|||||20011105
PV1||E||||||5101^NELL^FREDERICK^P^^DR|||||||||||V1295^^^ADT1|||||||||||||||||||||||||200007010800||||||||
PV2|||^ABDOMINAL PAIN
OBX|1|HD|SR Instance UID||1.123456.2.2000.31.2.1||||||F||||||
AL1|1||^PENICILLIN||PRODUCES HIVES~RASH
AL1|2||^CAT DANDER
DG1|001|I9|1550|MAL NEO LIVER, PRIMARY|19880501103005|F||
PR1|2234|M11|111^CODE151|COMMON PROCEDURES|198809081123
ROL|45^RECORDER^ROLE MASTER LIST|AD|CP|KATE^SMITH^ELLEN|199505011201
GT1|1122|1519|BILL^GATES^A
IN1|001|A357|1234|BCMD|||||132987
IN2|ID1551001|SSN12345678
HL7 standard versions
HL7 Version 2:
One of the most widely used versions of HL7 is the HL7 version 2 (HL7v2). This version included information such as patient administrative activities, demographics, medical orders, results, and financial information. With this version backward compatibility is maintained allowing communication between legacy and modern applications.
HL7 Version 3:
HL7 version 3 (HL7v3) has been created using lessons learned and best practices from previous versions. As compared to the previous version, it is more context rich and based on the Reference Information Model (RIM). This allows HL7v3 to be more standardized with format consistencies. XML has been used to be make it more human readable.
However, reasons like no backward compatibility and increased complexity have hindered its adoption. HL7v3 now is being primarily referenced while implementing the Clinical Document Architecture (CDA).
This weeks post is sponsored by Taliun. You can now get 2 weeks discovery and assessment services on healthcare integration strategies worth $3000 for free.
Clinical Document Architecture (CDA)
CDA standards created by HL7 is an electronic equivalent of a paper document. It is built on the framework of HL7 Version 3. CDA can be versioned, containing human readable representation of the content (essentially viewable on a browser). CDA can be both a simple set of information containing an image, or it may be as complex as a complete Transfer of Care Summary.
Examples of CDA include discharge summary, referral, clinical summary, history/physical examination, diagnostic report, prescription, or public health report. Text, images, and multimedia can be included within a CDA.
Consolidated CDA (C-CDA)
C-CDA can be defined as a set of consolidated CDA documents. It is an implementation guide which includes a library of templates.
C-CDA streamlines the existing CDA standard by compiling all of the most common CDA document types into one implementation guide which serves as a reference for all the document summaries utilized.
C-CDA contains specifications for document types such as Consultation Note, Operative Note, H&P Note and so on.
Continuity Of Care Record (CCR)
CCR is an XML -based standard for transmitting care summary records between healthcare applications when a patient is being transferred to another provider.
The CCR standard was published in January 2006.
CCR was created with the goal of providing the most relevant data needed for providers to deliver the best quality care to their patients. It serves to enable easy access to critical information from the patient’s previous encounter when the patient consults another provider, thereby ensuring continuity of care.
Although the CCR it is not a discharge summary document, upon a patient’s discharge, the CCR can be provided to a patient that contains a summary of the treatments and care provided to offer to his/her primary care physician.
Continuity of Care Document (CCD)
CCD was created as an alternate implementation to CCR for sharing patient summary data. CCD includes the combined benefits of Continuity of Care Record (CCR) and the Clinical Document Architecture Release 2 (CDA) specifications and was a collaboration of HL7 International and ASTM.
CCD therefore consists of CCR contents fit into the framework of the CDA. The first release of CCD was in April 2007.
CCD is an XML based standard displayed on a Web browser using a style sheet and can be rendered as HTML or PDF.
CCD consists of a set of templates that defines how to use CDA elements to communicate clinical data. However, the scope of the clinical data within the templates is set by the CCR dataset.
Fast Healthcare Interoperability Resources (FHIR): The new path towards health interoperability
Early 2010s saw the growing use of smartphones and the ubiquity of the internet, and the health information exchange process needed to be recalibrated in a more contemporary context. This led to the emergence of a promising new HL7 standard called as “FHIR”.
FHIR was developed by the HL7 organization and released in 2014. Pronounced as ‘Fire’, it is an acronym for Fast Healthcare Interoperability Resources and is a standard for exchanging healthcare information combining the best features from HL7 v2, HL7 v3, and CDA, while leveraging the latest web service technologies.
FHIR appeared as a game changer as compared to the previous HL7 standards and can be credited to its “universal applicability”. FHIR opened the door to data locked up within mobile devices, apps and wearables. Traditional HL7 standards on their own were not found to be configured to work with nonclinical applications, like mobile devices.
Also, interoperability in the HL7 V2 and V3 era was based on simple message passing. While adequate for non-real-time, non-interactive data sharing, message passing could not meet the needs of complex and tight system-to-system integrations. API usage though existed, but prior to FHIR, there was no applicable standard available, so vendors typically implemented only proprietary APIs. Widespread interoperability is obviously hindered if every connection requires a non-standard approach. The value of FHIR got noticed by the industry experts who went on to create a set of implementation guides to ensure that the APIs would be used consistently across vendor systems.
SMART on FHIR: Poised to transform data interoperability
SMART stands for Substitutable Medical Applications and Reusable Technologies and is an open standard based technology platform that enables creation of a library of interoperability-supporting, vendor-independent health apps that seamlessly and securely run across the healthcare system. SMART-compliant EHR systems running on top of a FHIR server is commonly referred to as “SMART on FHIR”. FHIR utilizes SMART framework to authenticate and integrate third party applications with EHRs.
Smart on FHIR can be used to create an app once and have it run anywhere in the healthcare system.
With the Smart on FHIR framework it is possible to directly embed third party app functionalities within the EHR/PHR by allowing the apps to run natively inside any compliant EHR/PHR that supports the SMART standard. Smart on FHIR is built on dual technologies: The SMART Platform, and HL7 FHIR. SMART is on the application side while FHIR is all about the data.
The SMART on FHIR APIs are widely used. Apple uses the APIs to connect its health app to hundreds of healthcare systems. Countless other app and platform developers, including Google, Amazon, and Verily are using it as well.
CDS Hooks: The latest in the FHIR stack
The SMART On FHIR has had a lot of success in getting different types of applications integrated into several EHR systems. However, to launch an app, the user must decide which is the appropriate app to be launched and at which point in their workflow. CDS Hooks is an attempt to help clinicians know what they should be running by running checks automatically for them ahead of time, and then providing information with the context within the EHR. So CDS Hooks is a complementary technology to Smart Apps because it makes it easier to run the right app at the right time and it can save explicit steps.
CDS Hooks is a vendor agnostic remote decision support standard launched by the Smart Health team. This technology is used to notify the user when specific activities occur within an EHR user session. For example, when a new patient record is opened, or when a medication is prescribed, CDS hooks can be invoked within the EHR to display actionable suggestions, or links to launch a SMART app from within the workflow.
Summarizing the Difference:
Healthcare interoperability has made significant strides in the recent years. While the previous HL7 standards focused on bringing together health data from various sources, latest HL7 Smart on FHIR and CDS Hooks enable clinicians to share patient details with outside experts and partners to enhance care. The wide scale adoption of the latest technologies of Smart on FHIR and CDS Hooks can not only alleviate the cumbersome integration process for EHRs and health apps but can also enable an app to be developed once, and then being run seamlessly inside many different EHRs. With these advancements in the health interoperability, the healthcare technology is changing into an unbundled set of applications built on top of an API platforms.
Another difference between HL7 and FHIR is around “flat file” HL7 v2 vs FHIR is based on RESTful web services such as JSON and RDF data formats. With dev community adopting these technologies in speed due to familiarity across tech industry, it will ensure the RESTful API approach simply acts as a de facto for easier exchange of data and hence becoming the ground for cross device & network interoperability.