HL7 MFK messages are the acknowledgement a receiving system sends back after processing an MFN master files notification. An MFK message tells the original sender whether the master file update was accepted, rejected, or partially processed, reporting both a message-level outcome in MSA and a record-level outcome for each entry in MFA. This page explains what an MFK message represents, the trigger events that carry it, every segment the message can contain and what each one holds, and how an MFK acknowledgement relates to FHIR. Sample content is constructed for illustration with fictional identifiers.
What an MFK message represents
An MFK message — MFK stands for Master Files Acknowledgement — is the response a receiving system returns to confirm or reject an MFN master files notification. Where an application acknowledgement (ACK) reports only message-level acceptance, an MFK goes further: it echoes the MFI master file identification from the original notification and adds one MFA segment per master file entry that was processed, so the sender can determine exactly which records succeeded and which failed.
The sender of an MFK message is the receiving system — the one that accepted the original MFN — and the receiver is the system that originated the master file update. MFK is a pure protocol message: it carries no clinical event of its own, only the outcome of processing the notification that preceded it. Because the MFA segment reports a record-level error code for each entry, an MFK can acknowledge partial success: some entries accepted, others rejected, within a single response.
When an MFK message is sent
An MFK message is sent in response to an MFN master files notification, when the receiving application is configured to return an application-level acknowledgement rather than a simple ACK. The response level code in MFI-6 of the originating MFN governs when the MFK is expected: a value of AL requests an MFK for every notification, ER requests an MFK only when errors occur, and NE suppresses the MFK entirely. A single MFN can carry multiple master file entries across multiple MFE segments, and the responding MFK carries one MFA for each of them.
Trigger events
The MFK message type carries one trigger event per MFN event it acknowledges:
MFK^M01— Acknowledges MFN^M01 (master file not otherwise specified)MFK^M02— Acknowledges MFN^M02 (master file — staff practitioner)MFK^M03— Acknowledges MFN^M03 (master file — test/observation)MFK^M04— Acknowledges MFN^M04 (master file — charge description)MFK^M05— Acknowledges MFN^M05 (master file — patient location)MFK^M06— Acknowledges MFN^M06 (master file — clinical study with phases and schedules)MFK^M07— Acknowledges MFN^M07 (master file — clinical study without phases but with schedules)MFK^M08— Acknowledges MFN^M08 (master file — test/observation numeric)MFK^M09— Acknowledges MFN^M09 (master file — test/observation categorical)MFK^M10— Acknowledges MFN^M10 (master file — test/observation batteries)MFK^M11— Acknowledges MFN^M11 (master file — test/observation calculated)MFK^M12— Acknowledges MFN^M12 (master file — additional basic observation attributes)MFK^M13— Acknowledges MFN^M13 (master file — practitioner organization unit)MFK^M14— Acknowledges MFN^M14 (master file — site-defined)MFK^M15— Acknowledges MFN^M15 (master file — inventory item)
The trigger event in MSH-9 of the MFK must match the trigger event of the MFN it is responding to, so a receiver of an MFN^M02 staff practitioner notification returns MFK^M02.
Integration topology
The diagram shows the receiving system returning a master files acknowledgement to the originating system after processing an MFN notification.
{{diagram: originating system → MFN notification → receiving system → MFK acknowledgement → originating system}}
Typical senders: any system that receives and processes MFN master file notifications — EHRs, laboratory information systems, pharmacy systems, ADT engines, or integration engines acting as terminal consumers.
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.
Direction: the MFK always travels in the opposite direction from the MFN it acknowledges; it is strictly a response message, never an unsolicited notification.
Segments in an MFK message
The MFK 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.
| Segment | Description |
|---|---|
MSH | Message Header. Opens every MFK message. It names the sending and receiving applications and facilities, stamps the creation time, declares the trigger event in MSH-9 (for example MFK^M02), carries the message control id in MSH-10, and pins the HL7 version. The trigger event in MSH-9 must mirror the trigger event of the MFN being acknowledged. Receivers route on MSH-9 and correlate the response to its originating notification via MSA. |
MSA | Message Acknowledgement. The message-level outcome of processing the MFN. MSA-1 carries the acknowledgement code: AA (application accept), AE (application error), or AR (application reject). MSA-2 echoes the message control id from MSH-10 of the originating MFN, which the sender uses to correlate this response to the notification it sent. MSA-3 carries an optional text message describing the outcome. |
[{ERR}] | Error. Structured error detail when the acknowledgement code in MSA-1 is AE or AR. ERR-3 carries the HL7 error code, ERR-4 the severity, and ERR-5 the application error code. Optional and repeating — multiple ERR segments describe multiple message-level errors. Record-level errors are reported in MFA rather than here. |
MFI | Master File Identification. Echoes the master file identification from the originating MFN. MFI-1 carries the master file identifier (for example STF for staff or OM1 for observation), identifying which master file this acknowledgement applies to. MFI-3 carries the file-level event code, and MFI-6 echoes the response level code the sender requested, confirming which acknowledgement policy was in effect. |
[{MFA}] | Master File Acknowledgement. One segment per MFE entry in the originating MFN, reporting the record-level outcome for each master file entry processed. MFA-1 carries the record-level event code mirroring the event code from the corresponding MFE-1. MFA-2 carries the date and time the entry was acknowledged. MFA-3 carries the error return code indicating whether the record was accepted or rejected and why. MFA-4 carries the primary key value identifying which master file record this outcome applies to, matching MFE-4 in the originating notification. Optional and repeating — omitted when no record-level reporting is required. |
[ ] = optional, { } = repeating
The MFA group repeats once per master file entry processed, so a single MFK 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 MFK message
Note. Constructed for illustration. Message control identifiers, dates, and facility names are fictional.
MSH|^~&|LABSYS|MERCYGEN|MDM|MERCYGEN|20260604083000||MFK^M02^MFK_M01|ACK00099|P|2.5.1
MSA|AA|MSG00055|Master file notification processed successfully
MFI|STF^Staff Master File^HL70175|||UPD|AL
MFA|MAD|20260604083000|0^Accepted^HL70181|S12345^SMITH^JOHN^A
MFA|MAD|20260604083000|0^Accepted^HL70181|S12346^JONES^MARY^B
What this sample shows
The MFK^M02 in MSH-9 identifies this as an acknowledgement to an MFN^M02 staff practitioner notification. MSA carries AA in MSA-1 — application accept — and echoes message control id MSG00055 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 AL (always), confirming this response was expected. Two MFA segments follow — one per staff record processed — each reporting event code MAD (master file add), an acknowledgement timestamp, error return code 0 (accepted), and the primary key value identifying the staff member (S12345 and S12346).
Working with MFK messages
Correlate on MSA-2, not on MSH-10
The field that links an MFK 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 MFK itself — that is the MFK'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.
Idempotency and deduplication
Use MSH-10 of the MFK as the deduplication key for the acknowledgement itself. A network retry can deliver the same MFK twice; treating a repeated control id as a duplicate prevents a replayed acknowledgement from triggering a second resubmission of the original notification or posting a duplicate audit entry.
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 a hundred 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 MFK 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 instead of an MFK even when the originating MFN requested an application-level acknowledgement via
MFI-6. Others omit theMFAsegments entirely and report only the message-level outcome inMSA. Confirm the acknowledgement behaviour a partner system will produce against their interface specification before relying on record-level error codes.
FHIR equivalent
MFK is a protocol-level acknowledgement message with no clinical FHIR equivalent. There is no FHIR resource that models the act of acknowledging a master file notification — FHIR's interaction model uses HTTP status codes and OperationOutcome resources to communicate success or failure, making a dedicated acknowledgement message type unnecessary in a RESTful exchange.
The HL7 v2-to-FHIR Implementation Guide provides no message map for MFK and no ConceptMap for the MFI or MFA segments. If a receiving system exposes a FHIR endpoint, the outcome that an MFK would carry is instead communicated through the HTTP response code and, for detailed errors, an OperationOutcome in the response body.
Common pitfalls
Pitfall. Correlating the MFK to its originating MFN using
MSH-10of the MFK instead ofMSA-2. The MFK's ownMSH-10is a new control id assigned by the responder and has no relationship to the originating notification;MSA-2is the field that echoes the MFN's control id.
Pitfall. Treating a message-level
AAas confirmation that every record was accepted. Inspect eachMFAsegment for record-level error codes — a batch acknowledgement can accept some entries and reject others under the sameAA.
Pitfall. Expecting an MFK when the originating MFN carried
MFI-6valueNE(never). No MFK will be returned; waiting for one causes a sender to hang or time out unnecessarily.
How Vorro handles MFK messages
Vorro processes MFK messages as first-class responses in the master files workflow. On receipt of an MFK, 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 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 a plain ACK in place of an MFK, mapping the ACK acknowledgement code to an equivalent message-level outcome so the workflow completes without manual intervention.
Related messages
- MFN — the master files notification that every MFK message acknowledges.
- MFQ — the master files query, used to request master file entries by key.
- 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 MFK
- HL7 v2-to-FHIR IG — segment maps index — confirms no ConceptMap for MFI or MFA
- HL7 Messaging Standard Version 2.5.1 product brief
