HL7 MFN Messages Explained: Master File Notification

MFN stands for Master File Notification, and it is the message type nobody thinks about until something breaks.

Every other HL7 message is about a patient. MFN is not. It distributes the reference data that all the other messages depend on: the list of clinicians, the list of wards and locations, the departments, the orderable services, the charge codes. When a new consultant joins, a ward is renumbered, or a test is added to the pathology catalogue, MFN is how that change reaches every connected system without somebody updating six configuration screens by hand.

Why reference data deserves its own interface

Consider what happens without it. A hospital adds a new orderable test. The laboratory system knows about it immediately. The ordering system does not, so nobody can order it. Someone adds it manually to the ordering system, with a slightly different code. Now order messages arrive at the laboratory carrying a service identifier the laboratory does not recognise, and they reject — or worse, they are accepted and mapped to something approximately similar.

Multiply that by every system, every code list and every year of operation, and you have the underlying cause of a surprising proportion of "the interface is broken" tickets. The interface is fine. The two ends disagree about what the codes mean.

The structure of an MFN message

MFN messages share a common shape and vary by the master file being distributed:

• MFI — master file identification: which file this is, and the overall action.
• MFE — master file entry: the action for one specific record (add, update, deactivate), its identifier and effective date.
• A file-specific segment carrying the actual content.

The common variants:

• MFN^M02 — staff/practitioner master file. Uses STF and PRA segments for clinicians and their practice details.
• MFN^M05 — location master file. Uses LOC, LDP, LCH and LCC for locations, departments and their characteristics.
• MFN^M08 to M12 — observation/test master files. The orderable service catalogue.
• MFN^M04 — charge description master. The billable items that DFT messages reference.
• MFN^M01 — a generic master file update where nothing more specific fits.

MFE-1 carries the record-level action code: MAD to add, MUP to update, MDC to deactivate, MDL to delete, MUP being by far the most common in steady state.

Effective dates are the point

MFE-3 and MFE-4 carry the effective date range for the record, and this is what makes MFN more than a glorified data dump. A ward that closes at the end of the month, a clinician who leaves in six weeks, a test that becomes orderable from the first of the quarter — MFN can distribute all of that in advance, with the date on which it takes effect.

Systems that ignore effective dates and simply apply everything on receipt produce a specific and confusing failure: reference data that is correct for today but wrong for a historical record. A discharge summary regenerated next year shows the ward's new name, not the one the patient was actually in.

Where MFN interfaces go wrong

Nobody owns them. Patient interfaces have obvious owners and obvious alarms. Reference data interfaces are often set up once, work, and are then forgotten. When they stop, nothing fails immediately — the existing codes keep working. The damage shows up weeks later as orders that will not map.

Deactivation treated as deletion. A clinician who has left still appears on thousands of historical records. Deactivating them means they cannot be selected for new work; deleting them breaks every record that references them. MDC and MDL are not synonyms.

One-way assumptions. Master files usually flow from one authoritative source outward. When a downstream system also allows local editing of the same list, the two diverge, and the next MFN either overwrites local changes or is rejected. Decide which system owns each list and enforce it.

No visibility of what was applied. When a code stops working, the first question is when it changed and what it changed to. If your MFN processing does not keep a history of applied changes, that question has no answer.

Practical advice

Treat reference data with the same seriousness as patient data: monitor the interface, alert when messages stop arriving, keep a full history of applied changes, and honour effective dates. Reconcile the full master file periodically against the source rather than trusting that every incremental update arrived — this is exactly the situation where a missing message hides indefinitely.

FHIR covers this ground with Practitioner, PractitionerRole, Location, Organization, HealthcareService and the terminology resources CodeSystem, ValueSet and ConceptMap. Terminology management in FHIR is considerably more rigorous than MFN ever was — but the organisational discipline it requires is the same, and that is usually the harder half.

If your reference data has quietly drifted apart, I can help you get it back in step.