The OM7 segment carries additional basic attributes for an entry in the test/observation master catalog — attributes that govern how a service is categorized, when it is effective, how long it runs by default, where it can be ordered, and what consent it requires. Where OM1 supplies the general definition of a master-file entry, OM7 layers on orderability and consent metadata that an ordering system needs to present and validate the service. It is one of the "omx-2" master-file segments and follows the general OM1 segment for the same catalog entry.
Purpose
OM7 enriches a master-file entry with attributes that matter at order time rather than at result time. These include a universal service identifier, one or more service categories with descriptions and synonyms, effective start and end dates for the service, a default duration and frequency, a set of consent attributes (indicator, identifier, effective window, interval, and waiting period), an effective date of change, the user who entered the record, the locations where the service is orderable, formulary status, a special-order indicator, and a charge-description-master primary key. OM7 carries no patient data; it documents the orderability profile of the cataloged service.
Used in
OM7 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 OM7 (alongside OM2 through OM6) 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 (OM7 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 |
|---|---|---|---|---|---|---|---|
| OM7-1 | Sequence Number - Test/Observation Master File | nm | — | R | — | — | Primary sequence key linking to the master-file entry |
| OM7-2 | Universal Service Identifier | ce | — | O | — | — | Coded identifier of the orderable service |
| OM7-3 | Category Identifier | ce | — | O | Y | — | Service category code, may repeat |
| OM7-4 | Category Description | tx | — | O | — | — | Free-text description of the category |
| OM7-5 | Category Synonym | st | — | O | Y | — | Alternate names for the category, may repeat |
| OM7-6 | Effective Test/Service Start Date/Time | ts | — | O | — | — | When the service becomes effective |
| OM7-7 | Effective Test/Service End Date/Time | ts | — | O | — | — | When the service ceases to be effective |
| OM7-8 | Test/Service Default Duration Quantity | nm | — | O | — | — | Default duration amount for the service |
| OM7-9 | Test/Service Default Duration Units | ce | — | O | — | — | Units for the default duration |
| OM7-10 | Test/Service Default Frequency | is | — | O | — | — | Default ordering frequency code |
| OM7-11 | Consent Indicator | id | — | O | — | HL70136 | Whether consent is required |
| OM7-12 | Consent Identifier | ce | — | O | — | — | Coded identifier of the consent |
| OM7-13 | Consent Effective Start Date/Time | ts | — | O | — | — | When consent becomes effective |
| OM7-14 | Consent Effective End Date/Time | ts | — | O | — | — | When consent expires |
| OM7-15 | Consent Interval Quantity | nm | — | O | — | — | Interval amount between consents |
| OM7-16 | Consent Interval Units | ce | — | O | — | — | Units for the consent interval |
| OM7-17 | Consent Waiting Period Quantity | nm | — | O | — | — | Waiting period amount before service |
| OM7-18 | Consent Waiting Period Units | ce | — | O | — | — | Units for the consent waiting period |
| OM7-19 | Effective Date/Time of Change | ts | — | O | — | — | When this record last changed |
| OM7-20 | Entered By | xcn | — | O | — | — | User who entered the record |
| OM7-21 | Orderable-at Location | pl | — | O | Y | — | Locations where the service is orderable |
| OM7-22 | Formulary Status | is | — | O | — | — | Formulary classification of the service |
| OM7-23 | Special Order Indicator | id | — | O | — | HL70136 | Whether the service is a special order |
| OM7-24 | Primary Key Value - CDM | ce | — | O | Y | — | Charge-description-master primary key, may repeat |
Most-used fields
OM7-1 (Sequence Number) is the required primary key joining these attributes to the OM1 entry. OM7-2 (Universal Service Identifier) names the orderable service with a coded element and is the field most often consumed by ordering systems. OM7-3 (Category Identifier) and OM7-4/OM7-5 (Category Description and Synonym) drive how the service is grouped and searched in an order catalog. OM7-6 and OM7-7 (effective start and end) define the service's active window. The consent cluster (OM7-11 through OM7-18) is heavily used in environments where ordering is gated by patient consent. OM7-21 (Orderable-at Location) constrains where the service may be placed, and OM7-24 (Primary Key Value - CDM) links the service to charge-master entries for billing.
Version differences (2.3 to 2.8.2)
OM7 was introduced in HL7 v2.4 to consolidate additional service-orderability attributes, so it is not present in v2.3. From v2.4 through v2.5.1 (documented here) the segment carried the 24 fields described above, including the consent cluster and the orderable-at location. Later versions (v2.7, v2.8, v2.8.2) preserved the field layout while migrating several coded fields from CE to CWE and refining the data types used for identifiers and timestamps in line with broader HL7 modernization. The overall sequence and meaning of the fields remained stable, so interfaces built against v2.5.1 OM7 generally map cleanly to later versions with attention to the coded-element type change.
Common mistakes
The most common error is field misalignment: OM7 is a long segment, and a single dropped delimiter shifts every later field, so the consent window or orderable-at location ends up in the wrong position. Integrators also confuse the repeating fields — OM7-3, OM7-5, OM7-21, and OM7-24 may each repeat with ~, while the consent date fields do not. Another mistake is populating OM7-2 with a local-only code where a recognized coding system is expected, which undermines downstream service matching. Finally, OM7-1 must match the OM1 sequence number for the same entry; a mismatch detaches the attributes from their general definition.
Examples
Minimal valid segment:
OM7|1
Fully-populated segment:
OM7|1|GLU01^Glucose Fasting^L|CHEM^Chemistry^L|Routine clinical chemistry|Sugar~Blood Glucose|20260101000000|20271231235959|30|min^minutes^UCUM|QD|Y|CONS01^Standard Lab Consent^L|20260101000000|20271231235959|1|yr^year^UCUM|0|hr^hours^UCUM|20260601090000|U1001^Nguyen^Tran^^^Dr|MAIN^^^MERCY^^^^^Main Lab~SAT1^^^MERCY^^^^^Satellite 1|FORM^Formulary|N|CDM1001^Glucose Charge^L
Annotated breakdown:
OM7|1|GLU01^Glucose Fasting^L|CHEM^Chemistry^L|...|Sugar~Blood Glucose|...|MAIN^...~SAT1^...|...|CDM1001^Glucose Charge^L
| | | | | |
| | | | | +-- OM7-24 Primary Key Value - CDM (repeats)
| | | | +-- OM7-21 Orderable-at Location (2 reps, ~ separated)
| | | +-- OM7-5 Category Synonym (2 reps, ~ separated)
| | +-- OM7-3 Category Identifier (repeats)
| +-- OM7-2 Universal Service Identifier
+-- OM7-1 Sequence Number - Test/Observation Master File (primary key = 1)
In-context excerpt (MFN master-file message defining service attributes):
MSH|^~&|ORDCAT|VORRO|EHR|MERCY|20260610140000||MFN^M08^MFN_M08|MSG00061|P|2.5.1
MFI|OMA^Observation Master^HL70175|VORRO|UPD|20260610140000||AL
MFE|MAD|MFE0020|20260610140000|GLU01^Glucose Fasting^L|CE
OM1|20|GLU01^Glucose Fasting^L|NM|0|||||||||||||||||||||F
OM7|20|GLU01^Glucose Fasting^L|CHEM^Chemistry^L|Routine chemistry|Sugar|20260101000000||||QD|N
Second in-context excerpt (two services with consent and locations):
MSH|^~&|ORDCAT|VORRO|EHR|MERCY|20260610141000||MFN^M08^MFN_M08|MSG00062|P|2.5.1
MFI|OMA^Observation Master^HL70175|VORRO|UPD|20260610141000||AL
MFE|MAD|MFE0021|20260610141000|HIV01^HIV Screen^L|CE
OM1|21|HIV01^HIV Screen^L|NM|0|||||||||||||||||||||F
OM7|21|HIV01^HIV Screen^L|SERO^Serology^L|HIV screening|HIV Test|20260101000000|||||Y|CONS02^HIV Consent^L|20260101000000||||||20260601090000|U1002^Patel^Anil^^^Dr|MAIN^^^MERCY^^^^^Main Lab|FORM^Formulary|N
MFE|MAD|MFE0022|20260610141000|CULT01^Blood Culture^L|CE
OM1|22|CULT01^Blood Culture^L|ST|0|||||||||||||||||||||F
OM7|22|CULT01^Blood Culture^L|MICRO^Microbiology^L|Aerobic and anaerobic culture|Culture~Blood Cx|20260101000000||120|min^minutes^UCUM|PRN|N
FHIR mapping
No segment-level ConceptMap is published in the v2-to-FHIR IG for OM7. As an observation-catalog/master-file segment, OM7 maps conceptually to the FHIR ObservationDefinition resource (and, for orderability, to related definitional resources such as ActivityDefinition or PlanDefinition in a fuller model). The universal service identifier, categories, effective dates, and consent attributes correspond to elements and extensions on that definition. Because no published transform exists, integrators building a FHIR target should map these orderability attributes explicitly rather than relying on an automated conversion.
Engine considerations
OM7 is one of the longer OMx segments, so engines must handle a high field count and several repeating fields (OM7-3, OM7-5, OM7-21, OM7-24). The HAPI HL7v2 parser exposes the repeating fields through array accessors and the rest as single values. When producing OM7, suppress trailing empty fields to keep the segment readable, but never reorder fields — position is meaning. Timestamp fields (OM7-6, OM7-7, OM7-13, OM7-14, OM7-19) should be emitted in valid TS format with appropriate precision. The minimal form (OM7|1) is valid and should round-trip without error. Engines should preserve repetition order in OM7-21 and OM7-24, since consumers may treat the first repetition as primary.
How Vorro parses and produces OM7
When parsing inbound MFN messages, Vorro reads OM7-1 as the primary key and attaches the orderability profile to the matching OM1 entry. Repeating fields — categories, synonyms, orderable-at locations, and CDM keys — are materialized as ordered lists in the normalized catalog model, and the consent cluster is captured as a structured consent profile with its effective window, interval, and waiting period. When producing OM7, Vorro emits OM7-1 from the normalized key, writes single-valued attributes in their fixed positions, and renders each repeating field with ~ separators in stable order. Empty optional fields are left blank and trailing empties are suppressed.
