Electronic health records and the HL7 standard
In order to develop and exchange Electronic Health Records (EHRs) in an interopeable and exchangeable manner a set of standardized formats and definitions is required. In this context HL7 (Health Level Seven International) is a set of standards developed and endorsed by the healthcare IT standard-setting authority HL7 International. Accredited by the American National Standards in 1994, HL7 International was founded in 1987 as a nonprofit organization with members in more than 50 countries. HL7 International promotes worldwide interoperability in healthcare IT through multi-year balloting system in which members vote and add commentary rounds on the standard and by providing guidance about how to implement the aforementioned standards. Referring to layer 7 in the Open Systems Interconnection (OSI) reference model, the seven in the organization’s name is the final layer (application layer) in the communication model. A variety of applications is used by healthcare providers for anything from keeping up with patient vital signals to billing. Even though different software and data sources often need to talk to each other, the communication and interoperability between these hard to achieve. Another layer of problems arises when two healthcare providers (e.g. two hospitals) need to share information. HL7 as a standard, aims to bridge the gap between health IT applications and different data sources. This later facilitates sharing healthcare data and makes it more efficient. In other words, HL7 standards act connects healthcare services such as electronic health records and modern information technology. This latter increases the number of services and implicit contexts that can be included in aggregating the patient record in a longitudinal and time sensitive manner. HL7 also provides possibility for shift towards innovative healthcare solutions and the adoption of novel devices and data types.
Example HL7 Message
Although HL7 messages are in human-readable format, though they may require some effort to interpret. As seen in the sample HL7 message below HL7 messages consists of one or more segments, with each segment being displayed on a different line of text. Within each segment there are one or more composites (also known as fields) a pipe character is used to separate one composite from another. If a composite contains other composites, these sub-composites (or sub-fields) are normally separated by ^ characters.
Sample HL7 message:
Typically initiated by registration applications, ADT Messages are among the most widely used of all message types and very common in HL7 context. They communicate patient demographic and visit information, as well as the reason why the message is being sent. Along the same lines when a patient’s record is updated, an ADT message is sent. This way, all systems can maintain the patient’s current contact information, insurance, and next of kin, as well as their current location and attending doctor. There are different types of ADT messages that are used for various trigger events. Some of the most commonly used ADT messages include:
- ADT-A02 – patient transfer
- ADT-A03 – patient discharge
- ADT-A04 – patient registration
- ADT-A05 – patient pre-admission
- ADT-A08 – patient information update
- ADT-A11 – cancel patient admit
- ADT-A12 – cancel patient transfer
- ADT-A13 – cancel patient discharge
FHIR vs HL7
From traditional document-based messaging paradigms to the most current REST APIs the EHR standards develop to define the rules to support new use cases and maintain their applicability. It is noticeable, that standards must solve real problems and address market demands so people can save or make money, in other words, standards do not exist in a vacuum. Healthcare providers are required to access multiple electronic systems to see relevant information of a patient. This can be even more challenging if they provide services in outpatient clinics that are not integrated with the local hospital system. Along these lines, complicated and heavy standards will be ultimately rejected by the markets through a correction process. This is where most recent HL7 interoperability standards, namely Fast Healthcare Interoperability Resources (FHIR) exercise their value. FHIR provides a common terminology and structure around clinical data information (e.g. procedures, diagnoses, etc.) where data can be exchanged across EHRs without risk of misinterpretation and uncertainty. Both FHIR and HL7 are crucial to the future of electronic health records (EHR). Even though it has been around for years, FHIR might not be as well-known as HL7. However, recently there is an emerging interest in FHIR.
How does FHIR differ from HL7?
FHIR was created by HL7 and there’s no competition per se between each interface utility. FHIR was developed in the perspective of integration of application programming interface (API) and web services like those already deployed in social media newsfeeds and many other domains outside of healthcare. HL7 is not connected to an API so for it to be functional there is a necessity to be written by a programmer or programming team to connect the systems that need interfacing as well as support and maintenance to ensure their integrity. In contrast, FHIR API method enables communication between multiple sources such as EHRs, mobile applications, devices, and more seamless. In other words, FHIR circumvents the difficulties of “traditional” EHR interfacing based on HL7 messages. One of the advantages of FHIR is the support strong foundation in web standards such as XML, JSON, HTTP. This latter comes with authentication and security baked in which is indispensable in EHR settings. Also, compatibility with JSON which is the simplest format imaginable with free facilitates interoperability efforts. Moreover, new features such as compartments (methods to find all linked resources given one resource) that are not really standardized in any kind of way, can be intengrated to FHIR as the standard grows. Along these lines companies like Apple try to FHIR’s patient-centric mobile solutions app, which empowers different stakeholders (patients, elderly people) to connect and manage their clinical records securely.