HL7 MFE Segment: Master File Entry

The MFE (Master File Entry) segment represents a single record-level action within a master file notification. Where the MFI segment declares which master file is being updated and at what level, MFE states what happens to one specific entry inside that file — add it, update it, deactivate it, or replace its key — and carries the primary key that identifies the record being acted upon. Each MFE introduces a record group whose trailing segments (such as LOC, STF, OM1) supply the actual record content.

Purpose

The MFE segment exists to attach a record-level event to an individual master file entry and to identify that entry by its primary key. It tells the receiver precisely what mutation to apply (the record-level event code), optionally links the change to a sender-assigned control ID for acknowledgment, marks when the change becomes effective, and names the key (and the type of that key) for the record. MFE is therefore the per-record verb of a master file message, sitting between the file-level MFI and the content segments that describe the entry.

Used in

MFE appears in MFN messages (Master File Notification) of every trigger variant — MFN^M01 through MFN^M16 — wherever individual master records are added, updated, or removed. In a typical MFN message it follows the single MFI segment and repeats once per record, each MFE introducing the segment group that carries the body of that record.

Field-by-field reference

Source: HAPI HL7v2 v2.5.1 javadocs (MFE) for sequence, name, data type, and repetition. Length is not published in the javadocs (—); Required and Table # are filled from the HL7 v2.5.1 standard where well-established.

Seq	Name	Data Type	Length	Req	Repeat	Table #	Description
MFE-1	Record-Level Event Code	id	—	R	—	HL70180	Action to apply to this record (add, update, delete)
MFE-2	MFN Control ID	st	—	O	—	—	Sender-assigned identifier for acknowledging this entry
MFE-3	Effective Date/Time	ts	—	O	—	—	Date/time the record-level change takes effect
MFE-4	Primary Key Value - MFE	varies	—	R	Y	—	Primary key identifying the master file record
MFE-5	Primary Key Value Type	id	—	O	Y	HL70355	Data type of the corresponding primary key value

Most-used fields

MFE-1 Record-Level Event Code: the required verb; receivers branch on MAD (add), MUP (update), MDC (deactivate), and related codes to decide how to process the record.
MFE-4 Primary Key Value - MFE: the required key; it ties the action to a specific master record and matches the key carried in the content segments that follow.
MFE-5 Primary Key Value Type: declares the data type of MFE-4 so the receiver can parse the key correctly; it repeats in lockstep with MFE-4.
MFE-2 MFN Control ID: enables granular acknowledgment via MFA, letting the receiver accept some entries and reject others within one message.
MFE-3 Effective Date/Time: lets senders schedule when a change becomes active rather than applying it immediately on receipt.

Version differences (2.3 to 2.8.2)

MFE has carried its record-level event code, control ID, effective date/time, and primary key from its earliest definitions. In v2.3 the primary key was a single value with an accompanying type field; v2.4 and v2.5.1 formalize MFE-4 as a repeating field of varying data type paired with the repeating MFE-5 Primary Key Value Type, allowing composite keys to be expressed. The v2.5.1 roster documented here — five fields with the repeating MFE-4/MFE-5 pair — is the stable modern shape. Versions 2.6 through 2.8.2 keep the same five fields; later refinements affect the breadth of the record-level event table (HL70180) and clarify the use of the VARIES type rather than changing the segment structure. Parsers handling v2.5.1 MFE generally process adjacent versions without change, provided they treat MFE-4 and MFE-5 as parallel repeating arrays.

Common mistakes

Treating MFE-4 as single-valued: it is a repeating VARIES field, and composite keys span multiple repetitions that must be read in parallel with MFE-5.
Letting MFE-4 and MFE-5 fall out of alignment: the nth Primary Key Value Type describes the nth Primary Key Value; mismatched ordering corrupts key interpretation.
Hard-coding a parser for MFE-4 because it is VARIES — the actual data type (often CE, CWE, or a string) depends on the master file, so the parser must consult MFE-5.
Ignoring MFE-1 and applying every record as an add; updates and deactivations require different downstream handling.
Assuming MFE-2 is required for acknowledgment; it is optional, and omitting it forces whole-message rather than per-entry acknowledgment.

Examples

A minimal valid segment (required event code and key only):

MFE|MAD|||LAB1042^^^MERCYLAB|CE

A fully-populated segment with a composite key:

MFE|MUP|CTRL-7781|20260610142500|GLUCOSE-FAST^Fasting Glucose^L~PANEL-METAB^Metabolic Panel^L|CWE~CWE

Annotated breakdown:

MFE|MUP|CTRL-7781|20260610142500|GLUCOSE-FAST^Fasting Glucose^L~PANEL-METAB^Metabolic Panel^L|CWE~CWE
    |   |         |              |                                                            |
    |   |         |              |                                                            +--> MFE-5 Primary Key Value Type (repeats, parallel to MFE-4)
    |   |         |              +---------------------------------------------------------------> MFE-4 Primary Key Value (VARIES, repeats)
    |   |         +------------------------------------------------------------------------------> MFE-3 Effective Date/Time
    |   +----------------------------------------------------------------------------------------> MFE-2 MFN Control ID
    +--------------------------------------------------------------------------------------------> MFE-1 Record-Level Event Code (MUP = update)

In-context excerpt inside an MFN message (location master):

MSH|^~&|FACMGR|MERCYGEN|ADT|MERCYGEN|20260610142500||MFN^M05^MFN_M05|MSG00021|P|2.5.1
MFI|LOC^Location Master^HL70175|MERCYGEN|UPD|20260610142500|20260610142500|AL
MFE|MUP|CTRL-0001|20260610142500|WEST-3B^^^MERCYGEN|PL
LOC|WEST-3B^^^MERCYGEN|West Wing 3B Med-Surg Unit|N|1234^Mercy General Hospital

A second in-context excerpt (staff master with two record entries):

MSH|^~&|HRSYS|MERCYGEN|SCHED|MERCYGEN|20260610150000||MFN^M02^MFN_M02|MSG00022|P|2.5.1
MFI|STF^Staff Master^HL70175|MERCYGEN|UPD|20260610150000|20260610150000|AL
MFE|MAD|CTRL-0010|20260610150000|STF-55012|ST
STF|STF-55012|55012^^^MERCYGEN^PRN|Okafor^Adaeze^M|P|F|19850412
MFE|MUP|CTRL-0011|20260610150000|STF-55013|ST
STF|STF-55013|55013^^^MERCYGEN^PRN|Lindqvist^Erik^J|P|M|19790923

FHIR mapping

No segment-level ConceptMap is published in the v2-to-FHIR IG for MFE. The MFE segment is conceptual record-level control metadata rather than a clinical or administrative resource. Its intent surfaces in FHIR through Bundle entry semantics — the record-level event code (add, update, delete) is analogous to the HTTP verb on a transaction Bundle entry, and MFE-4 corresponds to the identifier of the resource that entry creates or modifies. There is no one-to-one resource for MFE itself.

Engine considerations

Engines must read MFE-1 first and route the trailing record group accordingly, since add, update, and deactivate actions usually map to different downstream operations. Because MFE-4 is a VARIES type, robust engines look at MFE-5 to determine how to parse the key and never assume a fixed data type. The repeating MFE-4/MFE-5 pairing means composite-key master files require parallel iteration; engines that read only the first repetition will mishandle multi-part keys. If per-entry acknowledgment is required, the engine must preserve MFE-2 and echo it in the corresponding MFA segment. Engines should also honor MFE-3 effective dating rather than applying every change immediately.

How Vorro parses and produces MFE

On ingest, Vorro reads MFE-1 to determine the record action and uses it to select the appropriate persistence operation against the target master. It pairs each MFE-4 repetition with the matching MFE-5 type code, parsing the VARIES value according to the declared type, and carries MFE-2 through so that acknowledgment messages can reference individual entries. MFE-3 is honored as the effective timestamp when the downstream model supports scheduled changes. When producing MFN messages, Vorro emits one MFE per outbound record, writing the correct record-level event code, generating or echoing a control ID, and serializing composite keys as aligned MFE-4 and MFE-5 repetitions so receivers can reconstruct the key unambiguously.

Sources

← Back to HL7 v2 Guide