none
BTAHL7 and NAK RRS feed

  • Question

  • We've setup a two-way MLLP receive adapter in Biztalk 2010 for (HL7 v2.3-)ADT communication with our HIS.
    All works well except when the HIS sends an invalid message;

    We've sent an ADT^A31 with PID-30 (Patient Death Indicator) = "1" (while this (optional) field only accepts "Y" or "N").
    The message arrives successfully in the messagebox with ParseError = true (as it should), but the pipeline still sends an (posititeve) ACK message (with MSA-1 = "CA") (instead of an NAK) despite having received an invalid message.

    In the BTAHL7 configuration explorer the 'Acknowledgment type' is set to OriginalMode, ACK-routing to the send pipeline is enabled and validation of body segments and custum data types is checked.

    Any help would be appriciated.

     


    Don't panic
    Monday, July 18, 2011 10:27 AM

Answers

  • DogGuts,

    In OriginalMode i would not expect CA as acknowledge but AA. Keep in mind you cannot override the AcknowledgeType in the BTAHL7 configuration if the type is set in the message header. Can you post the header of the message ?

    Treflor

     

    Thursday, July 21, 2011 1:44 PM

All replies

  • DogGuts,

    In OriginalMode i would not expect CA as acknowledge but AA. Keep in mind you cannot override the AcknowledgeType in the BTAHL7 configuration if the type is set in the message header. Can you post the header of the message ?

    Treflor

     

    Thursday, July 21, 2011 1:44 PM
  • ...Keep in mind you cannot override the AcknowledgeType in the BTAHL7 configuration if the type is set in the message header. ...

     

    Thanks Treflor,


    I had the (wrong) impression that I could override the acknownledgeType despite already being set in the received message.


    Just for the record, here's a header from the sending application;
    MSH|^~\&|CLINICOM|UZGENT|BIZTALK|UZGENT|201107261734||ADT^A31|20110726173428568519|T^I|2.3|||AL|NE

    The sending system only asked for an accept acknowledgement (MSH-15=AL) and never for an application acknownledgement (MSH-16=NE).

    Changing the values (in the sending system) to MSH-15=NE and MSH-16=AL, fixed the problem and Biztalk started sending out NAK's with nice ERR-segments (albeit AFAIK I could 've just omitted MSH-15 and MSH-16 with the same result).

    thanks alot!

     


    Don't panic
    Tuesday, July 26, 2011 3:43 PM