The OMC segment supplements an observation/test master catalog entry by describing the observing material or class to which the observation applies — for example, restricting a glucose observation to plasma versus whole blood, or scoping an organism identification to a particular specimen class. It records the scope of the comment, the material class observed, and the source-of-comment metadata that qualify how a master-file observation should be interpreted. It is one of the "omx-2" master-file segments and follows the general OM1 segment for the same catalog entry.
Note on version: the OMC segment was introduced in HL7 v2.7 and is therefore not present in the HAPI HL7v2 v2.5.1 model package. The v2.5.1 javadoc URL listed in the sources resolves to "not found," and the v2.5.1 segment package contains only OM1 through OM7. The field-by-field reference below documents the OMC structure as defined by the HL7 standard so this Academy page is complete; when working strictly within a v2.5.1 interface, expect OMC to be absent.
Purpose
OMC narrows or qualifies a master-file observation by the material or class it is observed in. Where OM1 carries the general definition of an entry, OMC attaches the observing-material context that determines when the observation definition applies. It carries a segment action code so a master-file update can add, update, or delete the qualification, a comment-scope code that says what the comment applies to, and coded values describing the material observed and the source of the comment. OMC holds no patient data; it documents the material context of a cataloged observation.
Used in
OMC 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 OMC supplies observing-material context alongside the other OMx segments. Each entry in the notification is introduced by an MFE event segment. Because OMC is a v2.7+ segment, it is used only in interfaces operating at HL7 v2.7 or later.
Field-by-field reference
Source: Caristix HL7 v2.5.1 definition (OMC definition) 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. The OMC class is not present in the v2.5.1 model package (the segment was added in v2.7); the structure below follows the HL7 standard definition of OMC.
| Seq | Name | Data Type | Length | Req | Repeat | Table # | Description |
|---|---|---|---|---|---|---|---|
| OMC-1 | Sequence Number - Test/Observation Master File | nm | — | R | — | — | Primary sequence key linking to the master-file entry |
| OMC-2 | Segment Action Code | id | — | O | — | HL70206 | Add, update, or delete this qualification |
| OMC-3 | Segment Unique Key | ei | — | O | — | — | Unique key identifying this segment instance |
| OMC-4 | Comment Source | ce | — | O | — | — | Source of the observing-material comment |
| OMC-5 | Comment | ce | — | O | — | — | The material/class comment for the observation |
| OMC-6 | Comment Type | ce | — | O | — | — | Type or class of the observing material |
| OMC-7 | Comment Scope | ce | — | O | — | — | Scope of the comment for the observation |
Most-used fields
OMC-1 (Sequence Number) is the required primary key joining the material/class qualification to its OM1 entry; it must match the sequence number used by the other OMx segments for the same item. OMC-2 (Segment Action Code) is essential in update notifications, telling the receiver whether to add, change, or remove the qualification. OMC-5 (Comment) carries the actual material or class value that scopes the observation, and OMC-6 (Comment Type) classifies that value. OMC-4 (Comment Source) and OMC-7 (Comment Scope) provide provenance and applicability that downstream systems use to decide when the qualification is relevant.
Version differences (2.3 to 2.8.2)
OMC does not exist in v2.3, v2.4, v2.5, or v2.5.1 — it was introduced in HL7 v2.7 to give master-file builders a way to qualify observations by observing material and class. From v2.7 onward, through v2.8 and v2.8.2, the segment carries the action-code, unique-key, comment-source, comment, comment-type, and comment-scope fields described above, with coded fields expressed using the CWE-style data types favored in those releases. Interfaces operating below v2.7 will not emit or accept OMC; an interface upgraded to v2.7+ gains the segment without changes to the surrounding OM1-led structure.
Common mistakes
The most common mistake is expecting OMC in a v2.5.1 (or earlier) interface, where the segment simply does not exist; sending it on such a connection will be rejected or ignored. Another is omitting OMC-2 in an update notification, which leaves the receiver unsure whether to add or replace the qualification. Integrators also confuse OMC with the NTE notes segment — OMC is a structured, coded material/class qualifier, not free-text commentary. Finally, OMC-1 must match the OM1 sequence number for the same entry, or the qualification detaches from its general definition.
Examples
Minimal valid segment:
OMC|1
Fully-populated segment:
OMC|1|A|OMC-KEY-0001^VORRO^GUID|LAB^Laboratory^L|PLAS^Plasma^L|MATCLS^Material Class^L|TEST^Applies to test^L
Annotated breakdown:
OMC|1|A|OMC-KEY-0001^VORRO^GUID|LAB^Laboratory^L|PLAS^Plasma^L|MATCLS^Material Class^L|TEST^Applies to test^L
| | | | | | |
| | | | | | +-- OMC-7 Comment Scope
| | | | | +-- OMC-6 Comment Type (material class)
| | | | +-- OMC-5 Comment (the material/class value)
| | | +-- OMC-4 Comment Source
| | +-- OMC-3 Segment Unique Key (EI)
| +-- OMC-2 Segment Action Code (A = add)
+-- OMC-1 Sequence Number - Test/Observation Master File (primary key = 1)
In-context excerpt (MFN master-file message qualifying an observation by material):
MSH|^~&|LABCAT|VORRO|LIS|MERCY|20260610150000||MFN^M08^MFN_M08|MSG00071|P|2.7
MFI|OMA^Observation Master^HL70175|VORRO|UPD|20260610150000||AL
MFE|MAD|MFE0030|20260610150000|GLU01^Glucose^L|CE
OM1|30|GLU01^Glucose^L|NM|0|||||||||||||||||||||F
OMC|30|A|OMC-KEY-0030^VORRO^GUID|LAB^Laboratory^L|PLAS^Plasma^L|MATCLS^Material Class^L|TEST^Applies to test^L
Second in-context excerpt (two observations with material qualifications):
MSH|^~&|LABCAT|VORRO|LIS|MERCY|20260610151000||MFN^M08^MFN_M08|MSG00072|P|2.7
MFI|OMA^Observation Master^HL70175|VORRO|UPD|20260610151000||AL
MFE|MAD|MFE0031|20260610151000|GLU01^Glucose^L|CE
OM1|31|GLU01^Glucose^L|NM|0|||||||||||||||||||||F
OMC|31|A|OMC-KEY-0031^VORRO^GUID|LAB^Laboratory^L|WB^Whole Blood^L|MATCLS^Material Class^L|TEST^Applies to test^L
MFE|MAD|MFE0032|20260610151000|CULT01^Culture^L|CE
OM1|32|CULT01^Culture^L|ST|0|||||||||||||||||||||F
OMC|32|A|OMC-KEY-0032^VORRO^GUID|MICRO^Microbiology^L|CSF^Cerebrospinal Fluid^L|MATCLS^Material Class^L|TEST^Applies to test^L
FHIR mapping
No segment-level ConceptMap is published in the v2-to-FHIR IG for OMC. As an observation-catalog/master-file segment, OMC maps conceptually to the FHIR ObservationDefinition resource. The observing material or class recorded in OMC-5/OMC-6 corresponds to the specimen or material context on an ObservationDefinition (for instance, its qualified-interval or specimen-related elements), and the comment scope in OMC-7 narrows when that definition applies. Because no published transform exists, integrators building a FHIR target should model the observing-material qualification explicitly rather than relying on an automated conversion.
Engine considerations
Because OMC is a v2.7+ segment, the HAPI HL7v2 v2.5.1 model does not include an OMC class — engines pinned to v2.5.1 will treat an inbound OMC as an unknown or generic segment. When operating at v2.7 or later, engines model OMC with its action code and coded comment fields and expose them as single values. When producing OMC, populate OMC-2 in update notifications so the receiver knows the intended action, and keep OMC-1 aligned with the OM1 sequence number. The minimal form (OMC|1) is valid and should round-trip cleanly. Do not emit OMC on connections negotiated below v2.7.
How Vorro parses and produces OMC
When parsing inbound MFN messages at v2.7 or later, Vorro reads OMC-1 as the primary key and attaches the observing-material qualification to the matching OM1 entry, capturing the action code, unique key, comment source, material/class value, type, and scope in the normalized catalog model. For interfaces negotiated below v2.7, Vorro does not expect OMC and treats any occurrence as a non-standard extension. When producing OMC, Vorro emits OMC-1 from the normalized key, sets OMC-2 to reflect the master-file action, and writes the coded material/class fields in their fixed positions, suppressing trailing empty fields. OMC is generated only when the negotiated version supports it.
