HL7 MFN_Znn Site-Defined Master File Notification

The escape hatch for local master files that need structured records outside the standard MFN events.
HL7 message structure MFN_Znn 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_Znn.MF_SITE_DEFINED
 Mf Site Defined group Yes Yes
MFE
 Master File Entry Yes No
anyHL7Segment
 Anyhl7segment group Yes No

MFN_Znn is the site-defined master-file notification pattern. Use it when the master file is not simple enough for MFN_M13 and does not fit a standard MFN structure such as charge descriptions, locations, studies, observations, or inventory items.

That freedom is useful, but it comes with a bill. The record segment after MFE is site-defined, so the interface profile must define the Z segment fields, keys, action behavior, and versioning rules clearly.

A small MFN Znn example

MSH|^~\&|CATALOG|CITYHOSP|EHR|CITYHOSP|20260722122000||MFN^M14^MFN_Znn|MFNZ0001|P|2.5.1 MFI|ZCLINIC^Local clinic master^L|CATALOG^CITYHOSP|UPD|20260722122000|20260722124000|AL MFE|MAD|MFNZ0001|20260722124000|CLN123^North Clinic^L|CE ZCL|CLN123|North Clinic|A|123 Clinic Road^^Auckland^^1010|+64-9-555-0100|PRIMARYCARE

What workflow it represents

The sender owns a local master file that standard HL7 does not model well enough for the implementation. The receiver loads the site-defined record so later interfaces can reference the same local keys.

This can be completely reasonable for local clinics, device pools, reporting categories, operational codes, or other site-specific reference data. It becomes painful when the Z segment is undocumented or when it duplicates a standard master file that would have been easier to support.

How to read the structure

MSH carries the MFN message with a site-defined structure. MFI identifies the local master file. Each MF_SITE_DEFINED group contains MFE followed by one required site-defined or other HL7 segment that carries the record itself.

The app structure panel shows this as any HL7 segment because the real shape belongs to the local profile. Treat that as a contract to document, not permission to improvise field meanings per interface.

MFK_M01 remains the practical application acknowledgment pattern for record-level acceptance or rejection.

Implementation traps

The biggest trap is using Znn when a standard MFN message exists. Local segments are sometimes necessary, but they reduce portability and make future migrations harder.

The second trap is changing the Z segment quietly. If the sender adds a field or reuses an old field for a new meaning, every receiver parser has to guess whether the record is old, new, or broken.

Also agree whether the local file is replaced as a whole or updated record by record. That rule belongs in the interface specification, not in tribal memory.

Reference notes

HL7 v2+ describes the site-defined master-file transaction for master files that are not simple and are not otherwise defined by HL7. The structure is MFI plus repeating MFE-led site-defined records.