Handling misconfigured HL7 ACK/NCK messages and using Save Reply = IndexNotOk
Over the years, we keep monitoring Orphan Messages, and I have begun to notice the number of ACK/NCK's that do not match the Scheme in which the message was sent so it can't not align or signify that the message was OK. For example, if we send an ADT^A08 HL7 message to the vendor, and they send back a A08 instead of an ACK as the message type.
Currently our default is to have Save Replies on EnsLib.HL7.Operation set to IndexNotOk's. if we look at the previous example where we received a
MSH|^~\&|20260521113540|A08|xxxxxxxxx||||||||||||
MSA|AA|xxxxxxx|20260521113540|A08||
as the ACK but the system can verify it is an OK message because A08 does not exist in the schema, does it make sense to have everything always set to IndexNotOKs?
What have others done with this setting when Vendors are sending back garbage within the ACK, so it does not match up to any schema?
Comments
If the remote system sends back an HL7 reply that is not a “simple OK ACK message,” then IndexNotOKs is consistent with the documented purpose of the setting: it saves replies that are not simple OK ACKs and indexes them. That includes things like error NACKs and query responses. IndexNotOKs is also the documented default behavior for HL7 business services unless deprecated parameters were overridden. [1]
For the specific behavior you are seeing with malformed replies, there is relevant guidance from the retrieved material: if an ACK received from an external system does not match a schema, it can be stored but not create a Message Header or entry in the IOLog, which is one of the cited causes of orphaned HL7 messages. That matches your observation of orphan ACK/NCK traffic when the vendor sends back something like A08 instead of ACK. [2]
The same retrieved material states that for this schema-mismatch case, the solution is to correct the schema for the ACK. [2]
So based on the documents, the answer is:
- Yes, IndexNotOKs makes sense if your goal is to retain and index replies that are not simple OK ACKs, including problematic replies you may want to investigate. [1]
- No document retrieved says that IndexNotOKs itself fixes malformed vendor ACKs or prevents orphaning. The orphaning behavior described is tied to replies that do not match schema. [2]
- The documented remediation for malformed ACKs that do not match schema is to correct the schema for those ACKs. [2]
The available documentation does not provide guidance on “what others have done” as a best-practice recommendation beyond those points. It does, however, identify two ACK-related orphan scenarios:
- Negative ACKs processed as Completed by Reply Action Codes can be stored without creating a Message Header or IOLog entry. [2]
- ACKs that do not match schema can also be stored without creating a Message Header or IOLog entry. [2]
If you want, I can help you turn this into a concrete configuration review checklist focused only on the settings mentioned in the retrieved material, such as Save Replies, Ack Mode, Get Reply, and Reply Code Actions.
Sources: