HL7 MFD Messages: Master File Delayed Application Acknowledgement

HL7 MFD messages are the deferred application-level acknowledgement a receiving system sends back after it was unable to process an MFN master files notification immediately. Where an MFK message acknowledges an MFN in real time, an MFD is sent later — once the receiving application has had time to complete processing — reporting both a message-level outcome in MSA and a record-level outcome for each deferred entry in MFA. This page explains what an MFD message represents, the trigger events that carry it, every segment the message can contain and what each one holds, and how an MFD deferred acknowledgement relates to FHIR. Sample content is constructed for illustration with fictional identifiers.

What an MFD message represents

An MFD message — MFD stands for Master File Delayed Application Acknowledgement — is the response a receiving system returns when it could not process an MFN master files notification at the time it was received and instead deferred application-level processing to a later point. The originating MFN must have carried the response level code D (deferred application acknowledgement requested) in MFI-6; only that value triggers the MFD flow. When MFI-6 is AL or ER and immediate processing is possible, the receiver returns an MFK instead.

The MFD carries the same acknowledgement fields as an MFK but is sent asynchronously, after the deferred processing window has elapsed. It echoes the MSA message-level outcome and the MFI master file identification from the original notification, and adds one MFA segment per master file entry that was eventually processed. The sender of an MFD message is the receiving system — the one that accepted the original MFN and deferred processing — and the receiver is the system that originated the master file update. MFD is a pure protocol message: it carries no clinical event of its own, only the deferred outcome of processing the notification that preceded it.

When an MFD message is sent

An MFD message is sent after a deferred processing window has elapsed, in response to an MFN master files notification that carried MFI-6 value D. The receiving application may defer processing for any operational reason — a batch window, a scheduled maintenance period, or a downstream dependency not yet available — and the MFD travels back to the originator once processing is complete. Because the MFD arrives out-of-band relative to the original transport exchange, the originating system must be prepared to correlate it asynchronously using MSA-2.

A single MFN can carry multiple master file entries across multiple MFE segments, and the responding MFD carries one MFA for each of them, reporting the deferred outcome per record.

Trigger events

The MFD message type carries one trigger event per MFN event it deferred-acknowledges:

• MFD^M01 — Deferred acknowledgement for MFN^M01 (master file not otherwise specified)
• MFD^M02 — Deferred acknowledgement for MFN^M02 (master file — staff practitioner)
• MFD^M03 — Deferred acknowledgement for MFN^M03 (master file — test/observation)
• MFD^M04 — Deferred acknowledgement for MFN^M04 (master file — charge description)
• MFD^M05 — Deferred acknowledgement for MFN^M05 (master file — patient location)
• MFD^M06 — Deferred acknowledgement for MFN^M06 (master file — clinical study with phases and schedules)
• MFD^M07 — Deferred acknowledgement for MFN^M07 (master file — clinical study without phases but with schedules)
• MFD^M08 — Deferred acknowledgement for MFN^M08 (master file — test/observation numeric)
• MFD^M09 — Deferred acknowledgement for MFN^M09 (master file — test/observation categorical)
• MFD^M10 — Deferred acknowledgement for MFN^M10 (master file — test/observation batteries)
• MFD^M11 — Deferred acknowledgement for MFN^M11 (master file — test/observation calculated)
• MFD^M12 — Deferred acknowledgement for MFN^M12 (master file — additional basic observation attributes)
• MFD^M13 — Deferred acknowledgement for MFN^M13 (master file — practitioner organization unit)
• MFD^M14 — Deferred acknowledgement for MFN^M14 (master file — site-defined)
• MFD^M15 — Deferred acknowledgement for MFN^M15 (master file — inventory item)

The trigger event in MSH-9 of the MFD must match the trigger event of the MFN it is deferred-acknowledging, so a receiver of an MFN^M05 patient location notification that deferred processing returns MFD^M05.

Integration topology

The diagram shows the receiving system returning a deferred master files acknowledgement to the originating system after completing a batch processing window.

{{diagram: originating system → MFN notification (MFI-6=D) → receiving system → [deferred processing] → MFD acknowledgement → originating system}}

Typical senders: any system that receives MFN master file notifications and defers application-level processing — EHRs with scheduled batch import windows, laboratory information systems, pharmacy systems, or integration engines that queue updates for off-hours processing.

Typical receivers: the system that originated the MFN master file notification — a master data management platform, a registration system, or an integration engine distributing master file updates that requested deferred acknowledgement.

Direction: the MFD always travels in the opposite direction from the MFN it acknowledges; it is strictly an asynchronous response message, never an unsolicited notification.

Segments in an MFD message

The MFD message is compact: it carries a message header, a message acknowledgement, optional error detail, a master file identification echo, and one master file acknowledgement segment per record processed. 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

The MFA group repeats once per master file entry deferred-processed, so a single MFD message can report a mixed outcome across a batch of records — some accepted, some rejected — without the sender needing to resubmit the entire notification. The canonical segment pages carry the full field-by-field detail.

Sample MFD message

Note. Constructed for illustration. Message control identifiers, dates, and facility names are fictional.

MSH|^~&|LABSYS|MERCYGEN|MDM|MERCYGEN|20260605020000||MFD^M02^MFD_MFA|DFR00007|P|2.5.1
MSA|AA|MSG00061|Master file deferred processing completed
MFI|STF^Staff Master File^HL70175|||UPD|D
MFA|MAD|20260605020000|0^Accepted^HL70181|S12347^GARCIA^ELENA^M
MFA|MAD|20260605020000|0^Accepted^HL70181|S12348^PATEL^RAJAN^K

What this sample shows

The MFD^M02 in MSH-9 identifies this as a deferred acknowledgement to an MFN^M02 staff practitioner notification. MSA carries AA in MSA-1 — application accept — and echoes message control id MSG00061 in MSA-2, which is the MSH-10 of the originating MFN. The MFI echoes the master file identifier STF (staff master file) and the response level code D (deferred), confirming this late response was the agreed behaviour for this exchange. Two MFA segments follow — one per staff record deferred-processed — each reporting event code MAD (master file add), the effective datetime of the batch window (20260605020000), error return code 0 (accepted), and the primary key value identifying the staff member (S12347 and S12348).

Working with MFD messages

MFD is only sent when MFI-6 is D

The MFD flow is activated exclusively by the D response level code in MFI-6 of the originating MFN. If the originating notification carried AL (always) or ER (error only), the receiver returns an MFK immediately — not an MFD. Originating systems that do not set MFI-6 to D should never expect an MFD to arrive; waiting for one causes a sender to hang or time out unnecessarily.

Correlate on MSA-2, not on MSH-10

The field that links an MFD back to its originating MFN is MSA-2, which carries the message control id from the MFN's MSH-10. Do not attempt to correlate on MSH-10 of the MFD itself — that is the MFD's own control id, assigned by the responder. Build your correlation table by storing the MFN's MSH-10 on send and looking it up in MSA-2 on receipt, and design the correlator to handle an indeterminate delay between send and receipt.

Handle partial success from MFA

A message-level AA in MSA-1 does not mean every record succeeded. Inspect each MFA segment individually: MFA-3 carries the record-level error return code, and a batch of entries can include a mix of accepted and rejected records under a single AA. Resubmit only the rejected entries, identified by their primary key values in MFA-4, rather than resubmitting the entire notification.

Match MFA count to MFE count

The number of MFA segments in a well-formed MFD should equal the number of MFE segments in the originating MFN. If the counts differ, treat the discrepancy as an integration defect on the responder's side — not all entries were acknowledged — and raise an alert rather than silently assuming the missing entries were accepted.

Vendor variance. Some systems return a plain ACK or an MFK at the time of receipt rather than deferring and sending an MFD, even when the originating MFN carried MFI-6 value D. Others omit the MFA segments entirely and report only the message-level outcome in MSA. Confirm the deferred acknowledgement behaviour a partner system will produce against their interface specification before relying on the MFD flow or on record-level error codes.

FHIR equivalent

MFD is a protocol-level deferred acknowledgement message with no clinical FHIR equivalent. There is no FHIR resource that models the act of deferring and later acknowledging a master file notification — FHIR's interaction model uses HTTP status codes and OperationOutcome resources to communicate success or failure synchronously, making a deferred acknowledgement message type unnecessary in a RESTful exchange.

The HL7 v2-to-FHIR Implementation Guide provides no message map for MFD and no ConceptMap for the MFI or MFA segments. If a receiving system exposes a FHIR endpoint, the outcome that an MFD would carry is instead communicated through the HTTP response code and, for detailed errors, an OperationOutcome in the response body — and the asynchronous deferred pattern would be modelled using FHIR's async request pattern rather than a separate message type.

Common pitfalls

Pitfall. Expecting an MFD when the originating MFN did not carry MFI-6 value D. Only a deferred-acknowledgement request produces an MFD; an AL or ER response level code produces an MFK instead, and NE produces no application-level response at all.

Pitfall. Correlating the MFD to its originating MFN using MSH-10 of the MFD instead of MSA-2. The MFD's own MSH-10 is a new control id assigned by the responder and has no relationship to the originating notification; MSA-2 is the field that echoes the MFN's control id.

Pitfall. Treating a message-level AA as confirmation that every deferred record was accepted. Inspect each MFA segment for record-level error codes — a deferred batch acknowledgement can accept some entries and reject others under the same AA.

How Vorro handles MFD messages

Vorro supports the full deferred acknowledgement workflow for master files exchanges. When an outbound MFN is configured with MFI-6 value D, Vorro stores the originating MSH-10 and marks the notification as pending deferred acknowledgement. On receipt of the MFD, Vorro correlates it to the originating MFN using MSA-2, records the message-level outcome from MSA, and inspects each MFA segment to determine the deferred record-level result for every entry in the original notification. Entries rejected in MFA-3 are flagged for resubmission without requiring the sender to resend the full batch, and structured error detail from ERR is surfaced in the integration dashboard. Vorro also handles partners that return an MFK or plain ACK in place of an MFD, mapping the acknowledgement code to an equivalent message-level outcome so the deferred workflow resolves without manual intervention.

Related messages

• MFN — the master files notification that an MFD message deferred-acknowledges.
• MFK — the immediate master files acknowledgement returned when MFI-6 is AL or ER rather than D.
• MFR — the master files response, which returns master file entries in reply to an MFQ query.

Sources

• HL7 v2-to-FHIR IG — message maps index — confirms no message map for MFD
• HL7 v2-to-FHIR IG — segment maps index — confirms no ConceptMap for MFI or MFA
• HL7 Messaging Standard Version 2.5.1 product brief