The OM6 segment defines an observation whose value is computed from other observations rather than measured directly. Examples include an anion gap derived from electrolyte results, a corrected calcium adjusted for albumin, or an estimated glomerular filtration rate calculated from creatinine and demographics. OM6 attaches a derivation rule to a master-file entry so that downstream systems understand the observation is calculated and, where the rule is machine-readable, can recompute it. It is one of the "omx-2" master-file segments and follows the general OM1 segment for the same catalog entry.
Purpose
OM6 specializes a master-file entry into a calculated observation. OM1 carries the general attributes of the entry; OM6 adds the formula or textual rule that produces its value from inputs that are themselves cataloged observations. The derivation rule in OM6-2 is free text, so it may range from a human-readable description to a structured expression understood by a particular calculation engine. OM6 holds no patient result; it documents how a derived result should be obtained, supporting transparency, validation, and reproducibility of computed values.
Used in
OM6 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 OM6 (alongside OM2 through OM5 and OM7) supplies the type-specific attributes. Each entry in the notification is introduced by an MFE event segment.
Field-by-field reference
Source: HAPI HL7v2 v2.5.1 javadocs (OM6 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 |
|---|---|---|---|---|---|---|---|
| OM6-1 | Sequence Number - Test/Observation Master File | nm | — | R | — | — | Primary sequence key linking to the master-file entry |
| OM6-2 | Derivation Rule | tx | — | O | — | — | Formula or text describing how the value is calculated |
Most-used fields
OM6-1 (Sequence Number) is the required primary key joining this derivation definition to its OM1 entry; it must match the sequence number used by the other OMx segments for the same catalog item. OM6-2 (Derivation Rule) is the defining field — it holds the calculation expression or narrative that explains how the observation is produced from its inputs. Because OM6-2 is a TX field, it can hold formatted text and is the natural place to document operand observation identifiers, units, rounding, and any conditional logic the calculation requires.
Version differences (2.3 to 2.8.2)
OM6 has carried the same two fields — sequence number and derivation rule — consistently from v2.3 onward, through v2.5.1 (documented here) and into v2.7, v2.8, and v2.8.2. No fields were added or removed across this range. The chief evolution is contextual rather than structural: later HL7 guidance and accompanying implementation material encouraged more structured, machine-evaluable expressions in the derivation rule, but the field's TX data type and the segment's overall shape remained unchanged. This stability makes OM6 straightforward to support across mixed-version interfaces.
Common mistakes
A common mistake is treating OM6-2 as if it were a coded or numeric field; it is free text and should not be parsed as a fixed structure unless a local convention is agreed upon. Another is letting OM6-1 diverge from the OM1 sequence number for the same entry, which breaks the binding between the general definition and its derivation rule. Integrators sometimes also forget to escape HL7 delimiter characters (such as ^, |, or ~) that legitimately appear inside a formula written in OM6-2; without escaping, the formula corrupts the segment. Finally, OM6 should not be used to transmit a calculated patient result — that belongs in an OBX in a result message, not in the master file.
Examples
Minimal valid segment:
OM6|1
Fully-populated segment:
OM6|1|Anion Gap = (Sodium + Potassium) - (Chloride + Bicarbonate)
Annotated breakdown:
OM6|1|Anion Gap = (Sodium + Potassium) - (Chloride + Bicarbonate)
| |
| +-- OM6-2 Derivation Rule (free-text formula describing the calculation)
+-- OM6-1 Sequence Number - Test/Observation Master File (primary key = 1)
In-context excerpt (MFN master-file message defining a calculated observation):
MSH|^~&|LABCAT|VORRO|LIS|MERCY|20260610130000||MFN^M08^MFN_M08|MSG00051|P|2.5.1
MFI|OMA^Observation Master^HL70175|VORRO|UPD|20260610130000||AL
MFE|MAD|MFE0010|20260610130000|AGAP01^Anion Gap^L|CE
OM1|10|AGAP01^Anion Gap^L|NM|0|||||||||||||||||||||F
OM6|10|Anion Gap = (Sodium + Potassium) - (Chloride + Bicarbonate)
Second in-context excerpt (two calculated observations in one notification):
MSH|^~&|LABCAT|VORRO|LIS|MERCY|20260610131000||MFN^M08^MFN_M08|MSG00052|P|2.5.1
MFI|OMA^Observation Master^HL70175|VORRO|UPD|20260610131000||AL
MFE|MAD|MFE0011|20260610131000|CCA01^Corrected Calcium^L|CE
OM1|11|CCA01^Corrected Calcium^L|NM|0|||||||||||||||||||||F
OM6|11|Corrected Calcium = Total Calcium + 0.8 * (4.0 - Albumin)
MFE|MAD|MFE0012|20260610131000|EGFR01^Estimated GFR^L|CE
OM1|12|EGFR01^Estimated GFR^L|NM|0|||||||||||||||||||||F
OM6|12|eGFR computed from Creatinine, age, sex per CKD-EPI 2021 equation
FHIR mapping
No segment-level ConceptMap is published in the v2-to-FHIR IG for OM6. As an observation-catalog/master-file segment, OM6 maps conceptually to the FHIR ObservationDefinition resource. A calculated observation defined by OM6 corresponds to an ObservationDefinition whose narrative or extension captures the derivation rule from OM6-2; the input observations referenced in that rule correspond to other ObservationDefinition resources. Because no published transform exists, integrators should model derived observations and their formulas explicitly when building a FHIR target.
Engine considerations
Interface engines, including the HAPI HL7v2 parser, model OM6 with two fields and treat OM6-2 as a single, non-repeating TX value. The key concern when producing OM6 is delimiter safety: any reserved character inside the formula must be escaped using the message's escape sequences, or the segment will be mis-parsed. Engines should preserve the raw text of OM6-2 without normalizing whitespace, since formula readability matters to downstream reviewers. The minimal form (OM6|1) is valid and should round-trip cleanly. Engines do not evaluate the derivation rule; computation is the responsibility of the consuming application.
How Vorro parses and produces OM6
When parsing inbound MFN messages, Vorro reads OM6-1 as the primary key and binds the derivation definition to the matching OM1 entry, then stores OM6-2 as the entry's derivation rule with HL7 escape sequences decoded into their literal characters. When producing OM6, Vorro emits OM6-1 from the normalized entry key and writes the derivation rule into OM6-2, re-encoding any reserved characters so the formula survives transport intact. If no rule is present the segment is emitted in its minimal form, and trailing empty fields are suppressed.
