Changelog ORM LFDv2 to ORM v3

Introduction

Using an interface with ZorgDomein based on HL7v2 messages, a XIS can receive and process requests for diagnostic research automatically. ZorgDomein currently supports OML and ORM messages for these communication flows. The last major revision of these messages was in 2016. Since that moment ZorgDomein has implemented many improvements and adjustments to its order module. Additionally, several customers and XIS vendors have suggested improvements for the implementation of the ORM and OML messages. Therefore, ZorgDomein has composed a new specification for the ORM message that implements most of these improvements and suggestions. This new specification is based on the existing ORM LFDv2 message specification.

This changelog documents all modifications, additions, and clarifications made to the OML (Order Message List) specification during the transition from version 2 to version 3. The OML message encompasses all HL7 segments needed to transmit diagnostic test orders, including message headers, patient demographics, insurance, ordering details, specimens, and observations. The changes are categorized into three types:

• Unchanged: Elements that retain the same structure and semantics
• Modified: Elements where the content, format, or interpretation has changed
• New: Elements introduced for the first time in V3
• Removed / Relocated: Elements that have been removed or moved to a different segment

MSH Segment: Message Header

The message header is unchanged between LFDv2 and V3. The trigger event and message structure remain the same, although the underlying HL7 version is upgraded from v2.4 to v2.5.1.

NTE Segment: Notes & Comments (MSH-level)

The NTE segment at MSH level is entirely new in V3, introducing two patterns for cluster identification and file attachment metadata.

NTE Option 1: ZorgDomein Cluster Name (Change 9)

Messages sent by ZorgDomein are always directed to a “cluster” (an organizational unit). V3 explicitly includes the cluster name to enable downstream systems to process this routing detail.

Placement: Appears once immediately after MSH.

NTE Option 2: Attached Files Summary (Change 15)

For request forms with attachments, V3 includes a summary of those attachments in an NTE segment, making their presence explicit.

Placement: Appears once at MSH level when attachments exist.

PID Segment: Patient Identification

Patient Addresses (PID-11) (Change 14)

Some ZorgDomein request forms offer the ability to provide a home visit address (e.g., for home blood collection). V3 supports multiple address types in PID-11.

Impact: V3 may include an additional PID-11 occurrence with PID-11.7 = "C" when a home visit address has been entered by the requester, in addition to the standard mailing address (PID-11.7 = "M").

PV1 Segment: Patient Visit

In-Patient Location Details (Change 11)

V3 reserves PV1-3 fields for future use to support logistic blood sampling details for in-patients. In LFDv2, these details were supplied as OBX segments for each test.

Impact: These fields are reserved and will replace the OBX-based approach for in-patient location data in a future release.

ORC Segment: Order Common

ORC undergoes the most significant changes in V3, introducing address and contact details, sub-request identification, location AGB-codes, and priority handling.

Placer Order Number (Change 18)

Impact: LFDv2 reused the same ZD-number as the placer order number for all ORC-OBR combinations within a message, making it non-unique. V3 introduces a unique and persistent placer order number per ORC-OBR, which remains stable across update messages.

Sub-Request Identifier (Change 8)

Impact: ZorgDomein may split a request into multiple sub-requests, each with its own HL7 message. The sub-request identifier in ORC-4 corresponds to the bar code on the patient message. In LFDv2, ORC-4 contained only the overarching ZD-number, causing issues when scanning bar codes. The overarching ZD-number remains available in PID-3.

Enterer’s Location (Change 4)

In LFDv2, ORC-13 mixed organization and location details inconsistently. V3 restricts ORC-13 exclusively to the requester’s location.

Impact: Organization-level details (previously duplicated in ORC-13) are now exclusively in ORC-17. ORC-13 is reserved for location-specific details only.

Priority (Change 17)

Important: In LFDv2, priority code "S" was used when the acting referrer wished results to be called in or faxed. In V3, priority code "C" is used for this scenario, aligning with HL7 table 0485.

New in V3: Ordering Facility Address (Change 3)

V3 introduces complete address details of the requester’s location in ORC-22.

New in V3: Ordering Facility Contact (Change 3)

Impact: V3 enables direct identification and communication with the ordering facility, supporting automated routing and contact workflows.

OBR Segment: Observation Request

Placer Order Number (Change 18)

Universal Service Identifier — Test Groups & Healthcare Products (Changes 1, 2, 10)

V3 introduces a unified approach for test groups and healthcare products:

Change 2 — Always include all tests: LFDv2 omitted individual ORC-OBR combinations for tests within a fully-required test group. V3 always includes an individual ORC-OBR combination for every requested test, even when part of a test group with only required tests. This resolves issues with multi-material (MMB) orders where different specimens relate to individual tests.

Change 10 — Deduplication via healthcare product ORC-OBR: V3 introduces an additional ORC-OBR combination representing the request as a whole (i.e. the ZorgDomein healthcare product). General questions applying to the entire request are listed as OBX segments under this healthcare product ORC-OBR — and are no longer repeated under each individual test’s ORC-OBR. This ORC-OBR is always the first order in the message.

Collector Information (Change 16)

ORM LFDv2 did not include collection details. V3 adds full collector information to ORM messages:

New in V3: Specimen Source Details — OBR-15 (Change 7)

V3 introduces specimen source details directly in the OBR segment for ORM messages:

Result Copies To (Change 5)

V3 expands the recipient record to support future identification by initials, organization, and specialism.

Note: OBR-28.16 (“Name Context”) is used for the organization name. Strict HL7 interpretations may consider this non-standard, as the XCN data type does not formally define an organization component, but no better alternative is available.

NTE Segment: Notes & Comments (OBR-level)

Research Method (Change 7)

The research method name (relevant primarily for medical microbiology requests) cannot be expressed as an OBX observation. V3 uses an NTE segment at OBR level instead:

OBX Segment: Observation/Result

Coding System Standardization (Change 12)

Multiple Choice Questions (Change 13)

Impact: LFDv2’s approach of repeating OBX-5 had limited support among XIS vendors. V3 uses separate OBX segments for each selected answer, improving compatibility.

New in V3: Requested Tests within Test Groups (Change 1)

For each problem-based test group, V3 includes OBX segments listing the individual tests selected within that group:

Impact: In LFDv2, test group details were only included when all tests were required. V3 always includes test group details and the associated individual tests, regardless of their required/optional status.

New in V3: Collected Specimen Count (Change 7)

ORM does not have a SPM-13 field like OML. V3 represents specimen count as an OBX segment under the OBR:

New in V3: Container Barcode (Change 16)

OML uses SPM-2.1.1 for the container barcode. In ORM, this is represented as an OBX segment:

Key Differences: ORM V3 vs OML V3

Since both ORM and OML receive the same core improvements, the table below highlights where ORM behaves differently from OML V3:

Migration Checklist

When upgrading from ORM v2 to v3:

Technical Glossary

• LFDv2: Previous version of the ZorgDomein ORM message specification (“Laatste Formele Definitie v2”)
• ZorgDomein: Dutch healthcare cluster/domain identifier
• AGB-code: Dutch healthcare provider registration number (Algemeen Gegevens Beheer)
• VEKTIS: Dutch healthcare sector coding organization reference
• HL7 Table 0396: Standard HL7 coding system identifiers
• HL7 Table 0485: Standard HL7 priority codes (e.g., A=ASAP, C=Callback, R=Routine, S=Stat, U=Urgent)
• HL7 Table 0487: Standard HL7 specimen source type codes
• HL7 Table 0488: Standard HL7 specimen collection method codes
• Coding System “L”: HL7 v2.x standard marker for local/proprietary codes
• Probleemgestuurd pakket: Problem-based test group in ZorgDomein
• Sub-request: A split of a ZorgDomein request into separate HL7 messages, each with a unique identifier