HL7 MFN_M01 Master File Notification

The older catch-all master-file update message.
HL7 message structure MFN_M01 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_M01.MF
 Mf group Yes Yes
MFE
 Master File Entry Yes No
anyHL7Segment
 Anyhl7segment group No No

MFN_M01 is the older "master file not otherwise specified" notification. It was used when a system needed to publish changes to shared reference data but the update did not fit one of the more specific master-file events. In modern HL7 material this event is withdrawn, so use it mainly when you are supporting an existing v2.5.1-era interface.

Master-file messages are how systems keep reference data synchronized: provider lists, test catalogs, locations, charge codes, service codes, and local catalog values. A single bad catalog update can quietly affect thousands of later orders and results, so these messages deserve more respect than their plain structure suggests.

A small MFN M01 example

MSH|^~\&|CATALOG|CITYHOSP|LIS|CITYHOSP|20260718120000||MFN^M01^MFN_M01|MFN010001|P|2.5.1 MFI|LABTEST^Laboratory test master^HL70175|CATALOG^CITYHOSP|UPD|20260718120000|20260718130000|AL MFE|MUP|MFN010001|20260718130000|CBC^Complete blood count^L|CE OM1|1|CBC^Complete blood count^L|NM~ST|Y|LAB^City Hospital Laboratory^L|Complete blood count panel NTE|1||Updated display name and active catalog metadata.

What workflow it represents

The sender is the system that owns or manages a master file. The receiver is another application that needs a synchronized copy or subset of that file. The receiver may update automatically, hold changes for review, or reject records it cannot safely apply.

The application acknowledgment is usually MFK_M01. For high-risk catalogs, I would rather see record-level acknowledgments than only a message-level ACK, because one failed record in a large update can matter a lot.

How to read the structure

MSH identifies the notification. MFI identifies the master file and the file-level action. Each master-file group starts with MFE, which carries the record-level event and primary key.

The actual record follows MFE. In MFN_M01 the local profile decides which HL7 or custom segment carries that record. For a test catalog update it might be OM1; for a location update it might be a location segment; for a site-specific catalog it may be a local Z segment.

Implementation traps

Do not treat MFE as the whole record. It tells you which record is changing and how, but the record details are in the segment or segments that follow it.

Also be careful with replace-file behavior. A file-level replace can mean "delete anything not in this feed" in one interface and "refresh these records" in another. That difference is the sort of small sentence in an interface spec that saves a long afternoon.

Reference notes

HL7 v2+ master-file material describes master files as common reference files that need synchronization across applications. It also notes that MFI identifies the file, MFE carries record-level event and key information, and the actual record follows MFE in HL7-defined or site-defined segments. M01 is withdrawn in later versions, so prefer a more specific master-file event for new work.