HL7 MFI Segment: Master File Identification

The MFI (Master File Identification) segment opens a master file notification by declaring which master file the message concerns and how it should be processed as a whole. It names the master file, identifies the owning application, states the file-level event (replace the entire file, or update record by record), records entered and effective timestamps, and sets the response level that governs how detailed an acknowledgment the receiver must return. MFI is the file-level header that frames every MFE record action that follows.

Purpose

The MFI segment exists to scope a master file message. It tells the receiver exactly which master file is being synchronized (for example, the staff, location, or test definition master), which application owns that file, and whether the message replaces the whole file or applies discrete record-level changes. It also carries the date the data was entered and the date the changes take effect, and it specifies the response level code so the sender can demand anything from no acknowledgment to a full per-record acknowledgment. There is exactly one MFI per MFN message.

Used in

MFI appears in MFN messages (Master File Notification) across all trigger variants. It is the first segment after MSH in an MFN message and occurs exactly once, immediately preceding the repeating MFE record groups it scopes.

Field-by-field reference

Source: HAPI HL7v2 v2.5.1 javadocs (MFI) 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
MFI-1	Master File Identifier	ce	—	R	—	HL70175	Identifies which master file the message concerns
MFI-2	Master File Application Identifier	hd	—	O	—	—	Application that owns or maintains the master file
MFI-3	File-Level Event Code	id	—	R	—	HL70178	Whether to replace or update the file
MFI-4	Entered Date/Time	ts	—	O	—	—	Date/time the change was entered into the source
MFI-5	Effective Date/Time	ts	—	O	—	—	Date/time the file-level change takes effect
MFI-6	Response Level Code	id	—	R	—	HL70179	Level of acknowledgment the receiver must return

Most-used fields

MFI-1 Master File Identifier: the required code that tells the receiver which master file is in play; all downstream routing and table selection depends on it.
MFI-3 File-Level Event Code: the required verb at file scope; REP signals a full replacement while UPD signals record-by-record changes carried in the MFE segments.
MFI-6 Response Level Code: the required acknowledgment contract; it determines whether the receiver returns no MFA, an error-only MFA, or a per-record MFA.
MFI-2 Master File Application Identifier: identifies the owning application, important in environments where several applications maintain different masters.
MFI-5 Effective Date/Time: sets when the file-level change becomes active, supporting scheduled cutovers.

Version differences (2.3 to 2.8.2)

MFI has been stable since its introduction in the master files chapter. v2.3 already defined the master file identifier, application identifier, file-level event code, entered and effective timestamps, and response level code. v2.4 and v2.5.1 retain the same six fields without structural change; v2.5.1 is documented here and matches the HAPI javadocs above. From v2.6 through v2.8.2 the six-field roster is unchanged, with later refinements limited to the contents of the bound tables — the master file identifier table (HL70175), file-level event code table (HL70178), and response level code table (HL70179) — rather than the segment shape. A parser written against v2.5.1 MFI therefore interoperates cleanly across the version range.

Common mistakes

Sending more than one MFI per message: there is exactly one MFI; multiple master files require multiple MFN messages.
Confusing the file-level event code in MFI-3 with the record-level event code in MFE-1; the former scopes the whole file, the latter each record, and they use different tables.
Using REP (replace) in MFI-3 without sending the complete file, which causes the receiver to delete records that were merely omitted.
Treating MFI-6 as optional; the response level code is required and dictates the acknowledgment behavior the sender expects.
Sending free text in MFI-1 instead of a coded value from the master file identifier table, breaking the receiver's table-driven routing.

Examples

A minimal valid segment (required identifier, event code, and response level):

MFI|STF^Staff Master^HL70175|||||AL

A fully-populated segment:

MFI|LOC^Location Master^HL70175|FACMGR^1.2.840.114398.1.42^ISO|UPD|20260610140000|20260610142500|AL

Annotated breakdown:

MFI|LOC^Location Master^HL70175|FACMGR^1.2.840.114398.1.42^ISO|UPD|20260610140000|20260610142500|AL
    |                          |                               |   |               |              |
    |                          |                               |   |               |              +--> MFI-6 Response Level Code (AL = always)
    |                          |                               |   |               +-----------------> MFI-5 Effective Date/Time
    |                          |                               |   +---------------------------------> MFI-4 Entered Date/Time
    |                          |                               +-------------------------------------> MFI-3 File-Level Event Code (UPD = update)
    |                          +-----------------------------------------------------------------------> MFI-2 Master File Application Identifier (HD)
    +--------------------------------------------------------------------------------------------------> MFI-1 Master File Identifier (CE)

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

MSH|^~&|FACMGR|MERCYGEN|ADT|MERCYGEN|20260610142500||MFN^M05^MFN_M05|MSG00031|P|2.5.1
MFI|LOC^Location Master^HL70175|FACMGR^1.2.840.114398.1.42^ISO|UPD|20260610140000|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, full replacement):

MSH|^~&|HRSYS|MERCYGEN|SCHED|MERCYGEN|20260610150000||MFN^M02^MFN_M02|MSG00032|P|2.5.1
MFI|STF^Staff Master^HL70175|HRSYS^1.2.840.114398.1.77^ISO|REP|20260610150000|20260611000000|ER
MFE|MAD|CTRL-0010|20260611000000|STF-55012|ST
STF|STF-55012|55012^^^MERCYGEN^PRN|Okafor^Adaeze^M|P|F|19850412

FHIR mapping

No segment-level ConceptMap is published in the v2-to-FHIR IG for MFI. The MFI segment is conceptual record-level control metadata that scopes a master file message rather than describing a clinical or administrative entity. In FHIR, its file-scope and event intent surface through transaction or batch Bundle semantics — the file-level event code (replace vs. update) is analogous to the operation applied to a Bundle of resources, and MFI-1 identifies the kind of resource collection being synchronized. There is no single FHIR resource that corresponds to MFI.

Engine considerations

Engines must read MFI-1 to select the correct downstream master and table set, and MFI-3 to decide between full-replacement and incremental-update processing — a REP event typically implies that records absent from the message should be retired, which is dangerous to misinterpret. MFI-6 establishes the acknowledgment contract, so the engine must be prepared to emit the matching MFA detail level. Since there is exactly one MFI per message, engines should reject messages with zero or multiple MFI segments. Effective and entered timestamps (MFI-4, MFI-5) should be preserved for audit and for honoring scheduled changes. Because the bound tables evolve across versions, engines should treat unknown MFI-1 or MFI-3 codes as pass-through with a warning rather than failing outright.

How Vorro parses and produces MFI

On ingest, Vorro reads MFI-1 to route the message to the correct master file handler and inspects MFI-3 to choose between replace and update strategies, applying replacement semantics only when REP is explicitly present. It records the entered and effective timestamps for audit and scheduling, and it reads MFI-6 to determine how much acknowledgment detail to generate. When producing an MFN message, Vorro writes a single MFI as the first segment after MSH, populating the master file identifier and owning application, setting the file-level event code to match the intended operation, stamping the entered and effective dates, and selecting a response level code consistent with the acknowledgment behavior negotiated with the receiver.

Sources

← Back to HL7 v2 Guide