HL7 MFN_M12 Additional Basic Observation/Service Attributes

Catalog updates for extra orderable-service attributes that do not fit the numeric, categorical, battery, or calculated pages.
HL7 message structure MFN_M12 groups and segments from HL7 v2.5.1 Hide structure

These are the generated groups and segments for the version selected at the top of the page. The article explains the workflow, and this panel follows the chosen HL7 version.

Message Structure

SegmentNameRequiredRepeatable
MSH
 Message Header Yes No
SFT
 Software Segment No Yes
MFI
 Master File Identification Yes No
MFN_M12.MF_OBS_ATTRIBUTES
 Mf Obs Attributes group Yes Yes
MFE
 Master File Entry Yes No
OM1
 General Segment Yes No
OM7
 Additional Basic Attributes No No

MFN_M12 publishes additional basic attributes for an observation or service item. In practice, this is where a catalog owner can send service category, effective dates, default duration, consent behavior, orderable locations, special-order flags, and related charge-master pointers.

It is useful when the receiver already knows the general observation from OM1, but needs operational metadata to support ordering, scheduling, consent prompts, routing, or charge selection.

A small MFN M12 example

MSH|^~\&|CATALOG|CITYHOSP|EHR|CITYHOSP|20260722114000||MFN^M12^MFN_M12|MFN120001|P|2.5.1 MFI|OME^Other Observation/Service Item master file^HL70175|CATALOG^CITYHOSP|UPD|20260722114000|20260722120000|AL MFE|MAD|MFN120001|20260722120000|MRKNEE^MRI knee without contrast^L|CE OM1|1|MRKNEE^MRI knee without contrast^L|TX|N|IMG^City Hospital Imaging^L|MRI knee without contrast||||MRI Knee|MRI Knee WO Contrast|Y OM7|1|MRKNEE^MRI knee without contrast^L|IMG^Imaging^L|Diagnostic imaging services|MRI knee|20260722||45|min^minute^UCUM||Y|CONSENT-MRI^MRI consent^L|20260722||12|mo^month^UCUM|||20260722120000|12345^Taylor^Morgan^^^^^^CITYHOSP|RAD^^^CITYHOSP|A|N|MRIKNEE^MRI knee charge^L

What workflow it represents

The sender is usually an enterprise catalog, radiology/catalog system, LIS, or integration layer that owns service metadata. Receivers may use it for order entry, scheduling defaults, consent prompts, location-based availability, service categorization, and billing crosswalks.

This message often sits close to ORM_O01 and OML_O21 workflows, because ordering screens and validation rules need catalog details before the first patient-specific order is placed.

How to read the structure

MSH, MFI, and MFE provide the usual master-file wrapper. MFI-1 commonly identifies the other observation/service item master file for these additional service attributes.

Each MF_OBS_ATTRIBUTES group contains required OM1 for the general observation or service definition. OM7 is optional in the local v2.5.1 structure and carries the additional basic attributes such as category, timing, consent, orderable location, formulary/special-order status, and charge-master key.

If the receiver may reject a service because a category, location, consent rule, or charge key is unknown, use MFK_M01 and inspect the record-level feedback.

Implementation traps

The first trap is letting OM7 become a dumping ground. It can carry useful operational attributes, but the interface agreement still needs to say which fields the receiver actually honors.

Consent metadata is especially easy to overtrust. A consent indicator or identifier can help order entry prompt the user, but it does not prove a patient consent was collected for a specific encounter. Keep catalog-level consent rules separate from patient-level consent records.

Also be careful with location and charge links. A service may be orderable at one location and performed or billed somewhere else. If those distinctions matter, spell them out instead of assuming one code can stand in for all of them.

Reference notes

HL7 v2+ identifies M12 as the additional basic observation/service attributes event. Its structure includes OM1 for the general definition and OM7 for the additional basic attributes.