HL7 v2 acknowledgement utility
Generate practical HL7 acknowledgement messages or inspect an existing ACK for MSA result, ERR details, message-control-ID matching, routing reversal, and acknowledgement-mode fields.
ACK workflow
This is a practical integration debugging aid, not a certified HL7 conformance validator. It reads field and encoding delimiters from MSH where possible.
The generated MSA-2 value comes from the original MSH-10 control ID.
Generated ACK will appear here.
| # | Location | HL7 error | Severity | Diagnostic | User message |
|---|
ACK analysis report will appear here.
Supported in this version
AA, AE, AR, CA, CE, and CR results; sender/receiver reversal; MSH-10 to MSA-2 correlation; optional MSA text; and ERR location, severity, diagnostic, and user-message fields.
MSA result interpretation, original control-ID comparison, MSH-15/MSH-16 request interpretation, sender/receiver checks, version and trigger checks, and multiple ERR segments.
Reads modern ERR-2 locations and falls back to legacy ERR-1 location data, displaying segment, occurrence, field, repetition, component, and subcomponent positions.
It does not apply a site-specific HL7 profile, validate every version-dependent field rule, send messages, or prove that an application processed a message correctly.
FAQ
AA indicates application acceptance, AE indicates an application error, and AR indicates application rejection. The analyzer also recognises the commit acknowledgement codes CA, CE, and CR.
MSA-2 identifies the message control ID being acknowledged. Supplying the original message lets the tool show whether it matches the original MSH-10 value.
They indicate when accept and application acknowledgements are requested. The analyzer translates common AL, NE, ER, and SU values when the original message is supplied.
No. Local profiles can impose additional segments, fields, message structures, code systems, or acknowledgement rules. Treat the output as a practical starting point for development and testing.
No. Use synthetic or properly de-identified test messages only.
Practical guide
An HL7 acknowledgement is not merely “success” or “failure.” The code identifies the acknowledgement family and outcome, while the message control ID and ERR details connect the response to the inbound message and explain what the receiver accepted, could not process, or rejected.
These codes are normally carried in MSA-1. MSA-2 should identify the original message, typically by echoing the inbound MSH-10 message control ID.
Commit and application acknowledgements are distinct stages in enhanced acknowledgement mode. A commit accept does not automatically mean downstream application processing has completed successfully.
Worked example
Inbound: MSH-10 = MSG-20260721-0001
ACK: MSA|AE|MSG-20260721-0001
ERR: ERR||PID^1^3^1|102^Data type error^HL70357|EThe AE indicates an application-level error. The matching MSA-2 correlates the ACK to the inbound message. The ERR location points toward PID-3 in the first PID segment and first repetition, while the error code and severity provide additional diagnostic context.
Exact ERR population varies by HL7 version and receiver. Some systems return only free text, while others provide segment, field, repetition, component, code, severity, and application-specific diagnostic information.
Generation and troubleshooting
Authorship and review
Maintained and technically reviewed by Health Data Tools, drawing on more than 15 years of healthcare integration experience across HL7, FHIR, CDA, APIs, PKI, and clinical integration systems.
Technically reviewed:
Official references
These references support the technical context. Local implementation guides, vendor profiles, and receiving-system rules still take precedence for a specific interface.