| |
|
|
FHIR for HL7v2 expertsPublication date: Aug 18, 2023
If you have a background in HL7 version 2, and you start looking at FHIR, there are many things that seem familiar. After all, it's the same problem space. There are differences as well
- this blog aims to describe the main features of FHIR using HL7 v2 terms.
When creating the schedule for DevDays 2023 we had an open slot on the first day, where we usually slot introductory tutorial presentations. I decided to add a presentation for the HL7 version 2 crowd. Most of the data exchanges within healthcare organizations are (and will be) based on HL7 version 2, which means quite a few attendees of our FHIR training courses representing these organizations have had zero exposure to FHIR. The recording of the tutorial can be found below. A few of the highlights have been documented below the video itself. Segment versus ResourceThe core of the Hl7 v2 message is a the segment, the key data structure defined for reusabiilty across all message types. FHIR has Resources as the core element of reusability. Data types in HL7v2 and FHIR are more or less the same. The PID Segment maps to the Patient FHIR Resource, PV1 to Encounter and AL1 to AllegyIntolerance. There is not an exact match however, the scope of v2 segments may be different than the scope of a FHIR resource, as such there may not be a 1-1 mapping.Scope of the model, extensibilityIn HL7 version 2 the model tries to be all encompassing, i.e. to support nearly all use cases and contexts. Hence we have v2 segments with lots of fields, and we even need multiple segments to be able to model all data elements (think of PV1/PV2 or IN1/IN2/IN3). Even though segments have lots of fields most v2 implementers will know that in practice more often than not only the first dozen or so fields will be frequently populated.FHIR has a 80/20 rule, whereby they consciously only support the 80% most common use cases, those significantly reducing the size of the resource model. If you have a use case that's in the 20%, you have to use the FHIR extension mechanism. Extensions are a 'normal' part of FHIR. HL7 v2 doesn't allow a lot in terms of extensions: Z-Segments, codes in User Defined Tables. FHIR extensions can be used to extend Resources or even Data Types. ReferencesWithin a HL7 v2 message, the various segments (implicitly) have relationships between them because of the syntax of the message type. Given the fragment below we know that the visit (PV1) is a visit by Adele Jones (PID). It's kind of an implicit reference from the visit (PV1) to the visiting patient (PID).PID|||1000||Jones^Adele|.. PV1|I||ICU In FHIR all Resources have a logical identifier, which can be compared to a primary key in the database. If we have separate Patient and Encounter tables, then Patient Adele Jones could have logical id af45, and the Encounter logical id eb78. References are explicit in FHIR, so the reference to Patient af45 would be stored in a data item in the Encounter resource. The concept of logical ids doesn't exist in HL7 v2. in HL7 v2 we only have business identifiers (e.g. patient id, clinician id, placer order number), which can also be used as a referencing mechanism. The example below 'references' the mother of a patient by means of a business identifier. How a receiver resolves that business identifier actually hasn't been defined by the HL7 v2 standard. PID||..|28328^^MOTHERID|.. Code managementHL7 version 2 defines HL7 Tables (owned/managed by HL7) and User Defined Tables. Recent versions have CWE/CNE data types instead of the older CE data type. Still, the terminology model has matured quite a bit since the HL7 version 2 days. Notably the development of HL7 version 3 has led to a mature terminology model, which has been embraced and further enhanced by FHIR.Conformance ProfilesSupport for Conformance Profiles, which express in a computable way how one uses/should use HL7 version 2 in a particular context, where included in the HL7 version 2 standard 15 years after the creation of HL7 version 2. Uptake was unfortunately low, we got stuck with text in PDF documents (if there is any documentation at all). In FHIR, a conformance profiling mechanism plus supporting tooling has been available since day 1. Uptake of tools to validate profiles, and tools to express FHIR conformance profiles is near universal.Messaging versus RESTThe key difference between HL7 v2 and FHIR is that HL7v2 is a messaging exchange, whereas FHIR exchanges are mainly REST based. Sure, FHIR also supports FHIR Messaging, but the number of implementations thereof is very small.
Will FHIR replace HL7 v2?The volume of data exchanged with v2 is a lot more than the data exchanged with FHIR. We're going to end up with a mixture of standards for a long while. FHIR won't replace HL7 v2 in the short run - why waste money on replacing something that works perfectly well? You'd only do so if there are new use cases, new workflows or legal requirements that require you to go beyond what HL7 v2 has to offer.It's the same problem space. Whether HL7 v2 or FHIR, you're facing similar challenges and creating similar solutions. -Rene PermaLink to this page: https://www.ringholm.com/column/FHIR_for_HL7_version2_experts.htm
Index of columns:
About Ringholm bvRingholm bv is a group of European experts in the field of messaging standards and systems integration in healthcare IT. We provide the industry's most advanced training courses and consulting on healthcare information exchange standards.See https://www.ringholm.com for additional information. |
Rene is the Tutor-in-chief of Ringholm. [e-mail] |