Publish-box (todo)

• Comparison Appendix
• V2 Messaging
• V3 (Messaging)
• CDA
• Other

7.18.1 HL7 Version 2

FHIR Infrastructure Work Group

Maturity Level: N/A

Standards Status: Informative

HL7 V2 was HL7's first information exchange standard and is one of its most widely adopted, being prominent in in-patient settings throughout the world, though also used in a variety of other contexts as well. HL7 V2 uses messages composed of re-usable segments to communicate healthcare-related information between a sending and receiving system as well as to invoke particular behavior (patient transfers, lab orders, etc.) It also supports one-way communication through notifications, provides support for queries and other workflows.

7.18.1.1 HL7 V2 Similarities and Differences

Event-based: FHIR supports an event-based messaging paradigm similar to the HL7 V2 messaging structure (though, unlike HL7 V2, FHIR supports other paradigms as well including documents, REST and other service models). Refer to the Message Header resource.

Granularity: HL7 V2's "Segment" structure provides re-usable chunks of data that roughly correspond to FHIR's idea of resources. However, HL7 V2 segments can't be independently manipulated. Additionally, not all segments have the characteristics of independent identity held by FHIR resources. Due to differences in scope and approach to extensibility, HL7 V2 segments and datatypes are frequently cluttered with data elements that are not used by (or even understood by) the majority of implementations.

Segments can be composed into repeating and/or optional collections called "groups" to represent full healthcare business objects. For example, the "Order" component of an OMP (Pharmacy/Treatment Order Message) includes:

• an ORC segment dealing with workflow aspects of the order
• an RXO segment dealing with pharmacy-specific order aspects
• optional TQ1 and TQ2 segments describing the timing of the order
• optional NTE segments dealing with supplemental notes or rendering of the order
• optional RXR segments describing route information
• etc.

The HL7 V2 approach to granularity emphasizes re-use of "patterns" of information. For example, timing and route information are not useful on their own, but they are useful in many circumstances. Due to the 3-level nesting limit, separate segments are also required for data structures that would otherwise nest too deeply. FHIR takes a different approach to reusability, focusing on objects that can be maintained independently. The MedicationRequest resource encompasses all of the aspects of the above segments, with the exception of some of the workflow aspects of ORC which is handled by the Task resource. The MedicationRequest resource is itself complex, having nested structures for dosage instructions, dispensing instructions, etc. that are not simple datatypes.

Extensibility: HL7 V2 provides an extensibility mechanism through the use of "Z-segments". The meaning of these extensions is opaque without prior manual explanation by the sender. Extensions are supposed to be restricted to data elements that do not affect the meaning of the "standard" segments. FHIR Extensions, on the other hand, can appear at any level (including within datatypes). ModifierExtensions may be used in circumstances where an extension can change the meaning of other elements (e.g. the introduction of a negation indicator on a record). Finally, the meaning of FHIR extensions is discoverable by resolving the URI that defines the extension. The URI approach also ensures that extensions created by independent systems won't collide. (This can be an issue with Z-segments.)

Inter-version compatibility: HL7 version 2 has strict processes for maintaining forward and backward compatibility. Content can only be added to the end of existing fields, components, etc. Applications are expected to ignore unexpected content or repetitions. FHIR promises similar compatibility rules. The path to an element within a FHIR instance will remain unchanged in future versions. Specific rules on handling "new" elements (ignoring, checking for "must understand" indicators, etc.) will be developed during the STU period.

Human readability: In general, HL7 V2 instances do not provide for human readable versions of the content exchanged. While some systems may make use of NTE segments to provide a human-readable rendering of all or part of a message payload, the rules for when or if this occurs is site-specific. FHIR requires human readable content to be provided for each resource.

Update behavior: HL7 V2 data is typically exchanged in "snapshot" mode - updates are communicated by sending a complete copy of the instance with the new data filled in. However, some segments and messages in HL7 V2 support more sophisticated exchanges where only changed data is sent and codes or special values indicate what sort of change is to occur (e.g. add this address, remove this name). Out-of-the-box, FHIR only functions using snapshot mode. While the use of ModifierExtensions to introduce equivalent behavior to HL7 V2 is possible, doing so would create interoperability issues and would make use of the resources difficult outside the messaging paradigm.

Optionality & Profiles: Both HL7 V2 and FHIR provide a similar degree of flexibility at the international standard level. Most data elements are optional. However, there are two differences. FHIR resources are much more limited in terms of what elements are included in the core specification - only those elements that the vast majority of systems will support. HL7 V2 tends to include many elements that are used in only very limited circumstances. FHIR uses extensions for those circumstances. HL7 V2 and FHIR both provide formal mechanisms for defining profiles to give guidance on the use of the specification. However, the HL7 V2 mechanism has not been widely used. FHIR Profiles form an essential component of the methodology and are built into tooling, increasing the likelihood of their use.

7.18.1.2 HL7 V2 Interoperability Considerations

Mapping: One of the biggest challenges with HL7 V2 interoperability is the variation of implementation. Even when identical scenarios are being handled in similar business environments, the data elements supported can vary and even the place where a given data element is placed in an instance can vary. As a result, defining consistent mapping rules between HL7 V2 and FHIR at an international or even regional level is not terribly realistic. The FHIR mappings provided give a starting point for consideration, but mappings will generally need to be done on an implementation by implementation basis.

Extensions: While some HL7 V2 elements will map to FHIR core, a large percentage will not. Where a HL7 V2 element is not supported by core, an extension will be needed to share the information. Where there is interest, HL7 may choose to publish and maintain extensions for HL7 V2 elements that are not supported as part of the core FHIR specification. The FHIR extension registry should be searched prior to defining local extensions. If time permits, the relevant HL7 WG should be contacted with a request to define additional HL7 V2 extensions if needed ones are not present. If time does not permit, applications can define their own extensions, but should have a migration plan for if/when HL7 defines it later. For Z-segments, URIs should be defined to be specific to the system/environment that defined the Z-segment (e.g. http://acme.org/fhir/extensions/consent), not based on the name of the Z-segment itself (given that Z-segments with the same name but different meaning may exist) (e.g. http://hl7.org/ZAC).

Resource identification: HL7 V2 messages will often reference objects that have already been referred to in previous messages. When converting the messages to FHIR, these references will need to point to the same resource URI. Given that not all HL7 V2 message objects have identifiers in the message, this can be somewhat problematic. An approach to handling this issue exists for FHIR transactions. However, the ramifications of using this approach in a messaging environment have not yet been resolved. Implementers will need to explore their own strategies as part of early adoption.

Merging references and resources: HL7 V2 message instances may well reference the same "object" numerous times. For example, a message containing a patient's medication history is likely to include references to the same clinicians and clinics/hospitals many times. While in some cases, the data captured for a given object might be identical in all uses, in other cases the information might vary. For example, the sending system might convey historical phone numbers for old records and current phone numbers for newer records. Alternatively, the message design might allow expression of different amounts of detail in different portions of the message or the sending application might simply be designed to convey different amounts of detail in different portions of the message (e.g. conveying phone number for an ordering clinician, but not for a data-entry clinician). When converting to FHIR, all references to the same "object" will generally have a single resource identifier and be referenced only once in the instance - with the complete set of information needed/available. This creates two challenges:

1. How does the conversion software recognize when two portions of a message are referencing the same object? While some references may have unique identifiers or names that are sufficient to confirm "same object", others might not - though some other combination of attributes may be sufficient. The specific rules will need to be determined by the implementer performing the conversion.
2. If multiple versions of data are present, what set of data should be used - or should multiple versions be sent with distinct history ids? (And if the latter, what is the 'order' of the versions? If the order of the versions can be determined by data in the message (e.g. assuming older order dates have "older" demographics), dates can be specified on the entry updated element to indicate relative ordering. If the ordering can't be determined, it will be difficult to merge the data into a single resource or represent it using multiple resources.

Identified vs. Contained resources: Each HL7 V2 message will be mapped to multiple resource instances - often 10s or even 100s of resource instances. To maintain consistency with the HL7 V2 messaging paradigm, all resource data will typically be sent over the wire as part of the FHIR message rather than being sent by reference as would be typical in a RESTful implementation. However, FHIR provides two different ways of communicating the resources as part of the message bundle: they can either be sent as "fully identified" resources (direct entries in the bundle with their own identity, and able to be the subject of independent transactions), or they can be sent as contained resources, meaning they are only identified relative to another resource and cannot be retrieved or otherwise manipulated on their own. A HL7 V2 to FHIR conversion process will need to make the determination of what data elements are or must be present, for a resource to be fully identified. In some cases, the determination will be done at the time of mapping. In other cases, it may depend on the content of a particular instance. As an example, an XCN containing just a name (|^Smith^John|) doesn't contain enough information to discern the physician from any other John Smith, so will need to be a contained resource, whereas an XCN of |12345^Smith^John| generally does, though the conversion process will need to be aware of the scope and management processes around the identifier.

Generating human-readable content: FHIR requires that every resource have a human readable narrative that contains all information relevant to human decision-making. When converting from HL7 V2, developers (likely with guidance from clinicians) will need to determine what information from the message should be rendered and how to generate this content.

Delete indicator and update modes:In HL7 V2, "action" codes can determine whether particular segments represent information to be added, updated or deleted. Fields can be populated with a "delete indicator" (two consecutive double-quotes with no other characters) to note a field is to be deleted. An omitted element or repetition is generally interpreted as "retain existing data unchanged". This contrasts with the FHIR approach of requiring all data to be present as a snapshot. Systems will either need to build in logic to generate a full snapshot of each resource or consider using the Patch Operation instead.