Rediger

Del via


Acknowledgments Known Issues

This section contains useful information that may help you avoid acknowledgment (ACK) errors.

HL7 V2.1 acknowledgment message accepted even if it contains MSA6 field

Microsoft BizTalk Accelerator for HL7 (BTAHL7) will accept a HL7 V2.1 acknowledgment message even if contains the MSA6 field.

MSA-01 value not generated for commit acknowledgment errors

BTAHL7 does not generate an MSA-01 acknowledgment code for commit acknowledgments errors (CE).

Two-way MLLP adapter might not detect a problem with an ACK

When BTAHL7 receives an ACK on a two-way MLLP adapter, the adapter performs a lightweight validation on the ACK to determine its validity. If it is found to be valid, the MSA1 field is extracted, and depending on its value, the adapter retries, suspends, or deletes the original message to which the ACK was responding. However, since the validation performed by the adapter is not a complete validation, it is possible that the adapter will not detect a problem with the ACK. For instance, the adapter could determine that the ACK is valid, and delete the original message, whereas the pipeline would determine that the ACK was not well-formed, and suspend the ACK message.

V2.XML ACKs with multiple errors will fail validation

If an incoming V2.XML message contains more than one error, the BTAHL7 parser may generate a V2.XML ACK with more than one error in the error field. Such a V2.XML ACK will fail validation, because the HL7 standard specifies that the parser can report only one error in a V2.XML ACK error field.

MLLP performance counters do not count ACKs

One measure of BTAHL7 performance is the number of messages processed by an MLLP adapter, as indicated by MLLP performance counters. This count measures the number of messages received or transmitted. However, the count does not measure the number of ACKs either received or sent.

NAK generated by two-way MLLP adapter

When a two-way MLLP adapter suspends a message, BTAHL7 generates a NAK (negative acknowledgment) and places it in the MessageBox database. This may be unexpected behavior. You may want to remove the NAK from the MessageBox database or map it into another message.

Data type of an ACK to a batch message

In an ACK message generated in response to a batch message, the MSH10 field (message control ID) will be a GUID, rather than being based on the data type of the MSH10 field in the batch message.

Generated acknowledgments DOC type

BTAHL7 generates acknowledgments using the DOC type http://microsoft.com/HealthCare/HL7/2X#ACK_24_GLO_DEF or http://microsoft.com/HealthCare/HL7/2X#ACK_25_GLO_DEF. If your destination party uses a different namespace, you must apply a body map in the send port; otherwise, you may encounter serialization errors.

See Also

Known Issues