HL7 MFN Messages: Master Files Notification

HL7 MFN messages keep shared reference data in sync — the master files that every other interface depends on but that no single clinical message carries. An MFN message notifies receiving systems that a master file has changed: a new practitioner added to the staff directory, a bed renamed in the location file, a charge revised in the charge description master. Where an ADT message carries one patient's state and an ORM message carries one order, an MFN message carries changes to the dictionaries those messages reference. This page explains what an MFN message represents, the trigger events that distinguish one master file from another, the MFI-plus-repeating-MFE pattern at the core of the message, and how MFN relates to FHIR. Sample content is constructed for illustration with fictional identifiers.

What an MFN message represents

An MFN message — MFN stands for Master Files Notification — communicates a change to a master file: a reference table shared across systems, such as the staff/practitioner directory, the location dictionary, the charge description master, or a test/observation catalogue. The message tells receivers which file changed, which records within it changed, and whether each record was added, updated, deleted, or deactivated.

Two segments give the message its shape. The MFI Master File Identification segment, which appears once, names the master file being updated and the file-level action. The MFE Master File Entry segment then opens a group that repeats once per record changed, and each MFE is followed by the master-file-specific segment or segments that carry the actual record. The trigger event in MSH-9 declares which master file — and therefore which specific segments — the message carries.

The sender is the system that owns the master file — often a registration, credentialing, or chargemaster system — and the receivers are the systems that hold their own copy of that reference data and must keep it aligned. Because so many interfaces resolve codes against these dictionaries, a drift in a master file surfaces later as an unrecognised practitioner, location, or charge code in an otherwise valid message.

When an MFN message is sent

An MFN message is sent when a master file changes and the owning system needs the change propagated. A single message can report one record or many: the MFE group repeats, so an entire batch of staff additions or location renames can travel together. The receiver acknowledges the notification with an MFK Master File Acknowledgment, which reports whether the file and each record were applied.

Trigger events

Unlike a single-event message, MFN defines a family of trigger events, each tied to the master file it notifies. The trigger event in MSH-9 selects which master-file-specific segments follow each MFE. HL7 v2.5.1 Chapter 8 defines:

• MFN^M01 – Master file not otherwise specified (for backward compatibility only).
• MFN^M02 – Staff/practitioner master file.
• MFN^M03 – Service/test/observation master file (for backward compatibility only).
• MFN^M04 – Charge description master file.
• MFN^M05 – Location master file.
• MFN^M06 – Clinical study with phases and scheduled master file.
• MFN^M07 – Clinical study without phases but with scheduled master file.
• MFN^M08 – Test/observation (numeric) master file.
• MFN^M09 – Test/observation (categorical) master file.
• MFN^M10 – Test/observation batteries master file.
• MFN^M11 – Test/calculated observations master file.
• MFN^M12 – Test/observation (other attributes) master file.
• MFN^M13 – Master file — general.
• MFN^M14 – Master file — site defined.
• MFN^M15 – Inventory item master file.

The M01 and M03 events are retained for backward compatibility. The remaining events each pair the common MFI-plus-MFE skeleton with a different set of master-file-specific segments, summarised below.

Integration topology

The diagram shows the master-file owner emitting a change through the integration engine to the systems that maintain their own copy of the reference data.

{{diagram: master-file owner (registration / credentialing / chargemaster) → MFN message → integration engine → EHR / Lab / Billing / ancillary systems → MFK acknowledgment}}

Typical senders: registration or patient-administration system, credentialing or provider-directory system, chargemaster, and laboratory dictionary management.

Typical receivers: EHR, laboratory information system, billing, and any ancillary system that resolves codes against the shared master file.

Direction: notification from the file owner to the subscribers, answered per message by an MFK acknowledgment.

Segments in an MFN message

Every MFN message shares the same outer skeleton — MSH, then MFI, then a repeating MFE group — and the trigger event decides which master-file-specific segments fill that group. Cardinality follows HL7 notation: [X] optional, {X} repeating, [{X}] optional and repeating; a bare code is required. Each segment code links to its canonical field-by-field reference.

[ ] = optional, { } = repeating

Master-file-specific segments by trigger event

The group that follows each MFE differs per event. The verified v2.5.1 structures for the most commonly integrated events:

The canonical segment pages carry the full field-by-field detail. The constant across every event is the pattern: MFI names the file once, the MFE group repeats per record, and the event in MSH-9 chooses the payload.

Sample MFN message

Note. Constructed for illustration. Identifiers, names, and dates are fictional.

MSH|^~&|HRSYS|MERCYGEN|EHR|MERCYGEN|202006150900||MFN^M02^MFN_M02|MSG00021|P|2.5.1
MFI|PRA^Practitioner Master File^HL70175|MCM|UPD|202006150900||AL
MFE|MAD|||PROV998^MERCYGEN^MR
STF|PROV998|PROV998^MERCYGEN^MR|ROE^MARY^E^^^^L|P|F|19751104|A
PRA|PROV998||CARD^Cardiology^L|||201501010000

What this sample shows

The MFN^M02 in MSH-9 marks a staff/practitioner master file notification. The MFI identifies the file being updated as the practitioner master file and declares the file-level action UPD (update). The MFE opens one record group with the record-level event code MAD — add this record — and a primary key value PROV998 in MFE-4 that ties the rest of the group to a single master-file entry. The STF carries the staff record: the staff id PROV998, the name, and an active status. The PRA adds practitioner detail, here a cardiology specialty. To add a second practitioner in the same message, the sender would repeat the MFE group with a new primary key.

Working with MFN messages

Route on the trigger event, then read the MFE event code

MSH-9 tells the receiver which master file the message concerns and therefore which segments to expect after each MFE. Within the message, MFE-1 then says what to do with each record — add, update, delete, or deactivate. Both levels matter: the trigger event selects the parser, and the record-level event code drives whether a row is inserted, changed, or retired.

Use the primary key to link the group

MFE-4, the primary key value, uniquely identifies the record within the file named in MFI, and every segment that follows the MFE belongs to that one entry. Match incoming records on this key rather than on a name or a description, which can change between notifications.

Idempotency and deduplication

Use MSH-10, the message control id, as the deduplication key, and treat the primary key in MFE-4 together with the record-level event code as the natural business key for a record change. Master-file feeds are replayed after outages, and treating a repeated control id as a duplicate prevents a replayed notification from re-adding or re-deleting a record.

Acknowledge with MFK

A receiver answers an MFN with an MFK Master File Acknowledgment that reports the outcome at the file and record level. Wire the MFK return path before relying on the feed, so a rejected record is visible rather than silently dropped.

Vendor variance. Many systems implement only the master files they own — a credentialing system may send M02 and nothing else, a chargemaster only M04. Several events are retained for backward compatibility (M01, M03). Confirm a partner's supported trigger events and segment usage against their interface specification rather than assuming the full set in the base standard.

FHIR equivalent

There is no FHIR message that corresponds to MFN the way a Bundle corresponds to ADT. Conceptually, master-file notifications align with FHIR's terminology and administration resources depending on the file — a staff/practitioner file (M02) maps toward Practitioner, a location file (M05) toward Location, and a coded test/observation catalogue toward a CodeSystem — but these are conceptual alignments, not a published exchange.

Critically, there is no published mapping to lean on. The HL7 v2-to-FHIR Implementation Guide provides no message map for any MFN trigger event and no ConceptMap for the MFI or MFE segments. The IG's published message maps cover only a subset of message types — among them ADT events, OML_O21, ORM_O01, VXU_V04, ORU_R01, MDM_T02, and SIU_S12 — and MFN is not among them. Any FHIR representation of a master-file notification is therefore composed manually, choosing the target resource from the trigger event and reading the record from the master-file-specific segments.

Common pitfalls

Pitfall. Treating the message type alone as enough to parse. The segments after each MFE depend on the trigger event in MSH-9; a parser that ignores the event and expects one fixed layout will misread every file but one.

Pitfall. Matching records by name or description instead of the primary key in MFE-4. Names and descriptions change between notifications; the primary key is what identifies the record across updates.

Pitfall. Ignoring the record-level event code. An MFE-1 of MDL deletes or MDC deactivates a record — applying it as an add or update leaves retired entries live in the receiver's copy of the file.

How Vorro handles MFN messages

Vorro ingests the MFN feed over MLLP or another transport, deduplicates on MSH-10, and routes by the trigger event in MSH-9 so the right master-file-specific segments are parsed after each MFE. It applies each record by the event code in MFE-1 and keys on the primary key in MFE-4, returns an MFK acknowledgment to the sender, and fans the change out to every subscribed destination in the format that system expects. Where a FHIR destination is configured, Vorro maps a record to the conceptually aligned resource manually, since the v2-to-FHIR Implementation Guide publishes no map for this message.

Related messages

• MFK — the Master File Acknowledgment that answers an MFN at the file and record level.
• ADT — patient administration events that reference the staff and location master files MFN maintains.
• ORM — orders that resolve test, charge, and provider codes against those same master files.

Sources

• HL7 v2-to-FHIR IG — message maps index — confirms no message map for any MFN trigger event
• HL7 v2-to-FHIR IG — segment maps index
• HL7 Messaging Standard Version 2.5.1 product brief
• HL7 v2.5.1 Chapter 8 — Master Files (hl7.eu standard mirror) — trigger events, MFI and MFE definitions
• HL7 v2.5.1 Chapter 8 — Master Files (vico.org standard mirror) — trigger events and record-level event codes
• HAPI HL7v2 v2.5.1 apidocs — MFN_M02 message and MF_STAFF group — verified v2.5.1 segment structure
• HAPI HL7v2 v2.5.1 apidocs — MFN_M05 message and MF_LOCATION group — verified v2.5.1 location group structure </content>

</invoke>