The OM5 segment defines a battery (set) of observations within the observation/test master catalog. A battery is an orderable grouping — such as a complete blood count or a basic metabolic panel — whose individual component tests are themselves cataloged elsewhere in the same master file. OM5 declares which child tests belong to the battery and, optionally, which observation ID suffixes qualify those components. It is one of the "omx-2" master-file segments and always follows the general OM1 segment for the same catalog entry.
Purpose
OM5 lets a system that maintains an observation/test master file describe a composite orderable. Where OM1 carries the general attributes of any single master-file entry, OM5 specializes that entry into a battery by enumerating the tests included within it. The component identifiers in OM5-2 reference other observation/test catalog entries by their primary identifier, so a downstream system can expand a battery order into its constituent results. OM5 carries no result values itself; it is a definitional segment describing catalog structure, not patient data.
Used in
OM5 appears inside MFN (Master File Notification) messages that build or update an observation/test master catalog. See MFN messages. Within the test/observation master file, the OMx segments follow OM1 (the general segment) for the same catalog entry: OM1 establishes the entry, and OM5 (alongside OM2, OM3, OM4, OM6, and OM7) supplies the type-specific attributes. A single MFN message can carry many such entries, each introduced by an MFE event segment.
Field-by-field reference
Source: HAPI HL7v2 v2.5.1 javadocs (OM5 javadoc) for sequence, name, data type, and repetition. Length is not published in the javadocs (—); Required and Table # are filled from the HL7 v2.5.1 standard where well-established.
| Seq | Name | Data Type | Length | Req | Repeat | Table # | Description |
|---|---|---|---|---|---|---|---|
| OM5-1 | Sequence Number - Test/Observation Master File | nm | — | R | — | — | Primary sequence key linking to the master-file entry |
| OM5-2 | Test/Observations Included within an Ordered Test Battery | ce | — | O | Y | — | Component tests that make up the battery |
| OM5-3 | Observation ID Suffixes | st | — | O | — | — | Allowed suffix codes qualifying observation IDs |
Most-used fields
OM5-1 (Sequence Number) is the required primary key that ties this battery definition back to the OM1 entry it specializes; every OMx segment for a given catalog item carries the same value. OM5-2 (Test/Observations Included) is the heart of the segment — it repeats once per component test, each reference using a coded element whose identifier matches the primary key of another catalog entry. OM5-3 (Observation ID Suffixes) is used less often and records the suffix tokens that may legally append to component observation identifiers.
Version differences (2.3 to 2.8.2)
OM5 has been remarkably stable across versions. It was present in v2.3 and earlier with the same three-field shape — sequence number, included observations, and suffixes — and that structure carries forward unchanged through v2.5.1 (the version documented here) and into v2.7, v2.8, and v2.8.2. The coded data type used for OM5-2 follows the broader HL7 trend: legacy CE in v2.5.1, with later releases preferring CWE in many master-file contexts, though OM5 itself retained CE-style coding for component references. No fields were added or removed across this range, making OM5 one of the simpler OMx segments to support across mixed-version interfaces.
Common mistakes
A frequent error is treating OM5 as a result-bearing segment; it defines catalog structure only and never carries patient observations. Another is omitting OM5-1 or letting it drift out of sync with the OM1 sequence number for the same entry — the two must match for the battery to bind to its general definition. Integrators also forget that OM5-2 repeats: each component test is its own repetition, not a single field packed with component delimiters at the wrong level. Finally, the component identifiers in OM5-2 must resolve to real entries elsewhere in the master file; dangling references break battery expansion downstream.
Examples
Minimal valid segment:
OM5|1
Fully-populated segment:
OM5|1|718-7^Hemoglobin^LN~789-8^Erythrocytes^LN~787-2^MCV^LN|&S
Annotated breakdown:
OM5|1|718-7^Hemoglobin^LN~789-8^Erythrocytes^LN~787-2^MCV^LN|&S
| | |
| | +-- OM5-3 Observation ID Suffixes
| +-- OM5-2 Test/Observations Included (3 repetitions, ~ separated)
+-- OM5-1 Sequence Number - Test/Observation Master File (primary key = 1)
In-context excerpt (MFN master-file message defining a battery):
MSH|^~&|LABCAT|VORRO|LIS|MERCY|20260610120000||MFN^M08^MFN_M08|MSG00041|P|2.5.1
MFI|OMA^Observation Master^HL70175|VORRO|UPD|20260610120000||AL
MFE|MAD|MFE0001|20260610120000|CBC001^Complete Blood Count^L|CE
OM1|1|CBC001^Complete Blood Count^L|CE|0|||||||||||||||||||||F
OM5|1|718-7^Hemoglobin^LN~789-8^Erythrocytes^LN~4544-3^Hematocrit^LN
Second in-context excerpt (two batteries in one notification):
MSH|^~&|LABCAT|VORRO|LIS|MERCY|20260610121500||MFN^M08^MFN_M08|MSG00042|P|2.5.1
MFI|OMA^Observation Master^HL70175|VORRO|UPD|20260610121500||AL
MFE|MAD|MFE0002|20260610121500|BMP001^Basic Metabolic Panel^L|CE
OM1|2|BMP001^Basic Metabolic Panel^L|CE|0|||||||||||||||||||||F
OM5|2|2345-7^Glucose^LN~2160-0^Creatinine^LN~3094-0^BUN^LN~2951-2^Sodium^LN
MFE|MAD|MFE0003|20260610121500|LIPID01^Lipid Panel^L|CE
OM1|3|LIPID01^Lipid Panel^L|CE|0|||||||||||||||||||||F
OM5|3|2093-3^Cholesterol^LN~2571-8^Triglycerides^LN~2085-9^HDL^LN
FHIR mapping
No segment-level ConceptMap is published in the v2-to-FHIR IG for OM5. As an observation-catalog/master-file segment, OM5 maps conceptually to the FHIR ObservationDefinition resource. A battery defined in OM5 corresponds to a grouping ObservationDefinition (or a panel definition) whose members reference the ObservationDefinition resources derived from the component catalog entries listed in OM5-2. Because the mapping is conceptual rather than published, integrators building FHIR targets should model batteries explicitly rather than relying on an automated transform.
Engine considerations
Most interface engines, including the HAPI HL7v2 parser, model OM5 with exactly three fields and expose OM5-2 as a repeating accessor returning an array. When generating OM5, ensure the repetition separator (~) is used between component tests rather than packing them into a single repetition. Engines that validate referential integrity against the master file should resolve each OM5-2 identifier to a catalog entry; engines that do not should at least preserve repetition order, since some consumers infer reporting sequence from it. The empty-field minimal form (OM5|1) is valid and should round-trip without error.
How Vorro parses and produces OM5
When parsing inbound MFN messages, Vorro reads OM5-1 as the primary key and joins the battery definition to the matching OM1 entry, then materializes each OM5-2 repetition as a distinct component reference in the normalized catalog model. Component identifiers are resolved against previously parsed master-file entries so the battery can be expanded on demand. When producing OM5, Vorro emits OM5-1 from the entry's normalized key, writes one OM5-2 repetition per cataloged component in stable order, and includes OM5-3 only when suffix metadata is present. Empty trailing fields are suppressed to keep the segment compact.
