HL7 v2 MSA Segment Guide: Fields, Format, and Testing Gotchas
MSA is the entire payload of a bare-bones ACK message, and it is the segment interface engines check first to decide whether a message actually made it through — get the mapping wrong here and a sending system can sit there believing a message landed when it never did.
MSA is the Message Acknowledgment segment in HL7 v2. It appears in ACK messages and tells the sending system what happened to the message it just transmitted: whether it was accepted (AA), errored (AE), or rejected (AR), and it echoes back the original message's control ID so the sender can match the acknowledgment to the right outbound message. An optional text field can carry human-readable detail about what went wrong.
The fields that actually matter in practice
Example
A synthetic MSA segment acknowledging a message with an application error — the control ID and error text are both fabricated for this example.
Where this trips people up
A lot of test suites only ever generate happy-path ACKs with AA and an empty MSA-3, because that is the response a healthy integration returns most of the time. That leaves the retry, alerting, and error-logging logic that fires on AE and AR completely unexercised until a real outage happens. The other frequent miss is treating MSA-2 as decorative: if a test generator doesn't actually thread the original MSH-10 value into the ACK's MSA-2, correlation logic that matches acknowledgments back to sent messages never gets a real test, and a sender can end up waiting indefinitely on a response that already arrived under the wrong control ID.