locked
ACK original message correlation in MSH.10 RRS feed

  • Question

  • Hi,

    I have an inbound HL7 ORM message as given below

    MSH|^~\&|LDM|Main Clinics,52|XYZ|XYZ|20161225024238||ORM^O01|912|P|2.3|||ER|AL
    PID|1|CEU-000167|11694||Salaam^Rajhi^A||19730101120000|M|||||||
    PV1|1||||||^^^^^^^||||||||||||OU_00001-000276
    ORC|SC|c5e1df88-bdc5-e611-9423-180373b13231||16|SC||^^^^^R^^^^||20161225|||^^^^^
    OBR|1|ON1585|ON1585|^^^85025-00^Complete Blood Count - (CBC)^|R|20161219000000|20161225024241||||L||||||||||||||F||||
    NTE|1|L|Sample Collected^rem^test|Phlebotomy

    on message receive biztalk generates ACK message as response on 2way receive port automatically as below

    MSH|^~\&|XYZ|XYZ|LDM|Main Clinics,52|20170124091620||ACK^O01^ACK|192|P|2.3|||NE
    MSA|AA|912


    Here MSH.10 of original message is 912 and ACK's MSH.10 is 192(autogenerated)

    i want to have a correlation b/w MSH.10 of original message and MSH.10 of ACK

    let me know if you need more clarity

    Looking forward to early response


    thanks

    noor syed





    • Edited by noor syed Tuesday, January 24, 2017 11:18 AM
    Tuesday, January 24, 2017 9:18 AM

Answers

  • The correct answer: don't even try. This is not standard HL7.

    The ref value is in MSA02 per HL7.

    This is not a problem with HL7 or BizTalk Server. This is a problem created by your Trading Partner.

    If this is being pushed by a Trading Partner, the first response is simply NO, because this is not standard HL7.

    If they keep pushing this, your next step is to inform your management that because the Trading Partner is requiring non standard HL7, it will take you a lot of extra time and money to support this. You will need a completely custom numbering scheme.

    Here a nice description of MSH10. It makes no reference to returning the originating Message ID. hl7resources.com/Public/index.html?a55433.htm

    Friday, January 27, 2017 1:22 PM
    Moderator

All replies

  • Just to elaborate the requirement. We need the same message control id of the originated message in ACK. That the Original Message MSH.10 == ACK MSH.10

    What we are seeing is BizTalk is generating the message control id (MSH.10) of the ACK by doing a swapping of the original message control id. Based on the HL7 standard we need both the MSH.10 to be exactly same. Please suggest

    Wednesday, January 25, 2017 11:50 AM
  • Is it possible to put a map on the send side? That way you can map it any way you want. I mean if it is not possible to fix this with configuration.
    Wednesday, January 25, 2017 8:34 PM
  • Hi ,

    thanks for the response,

    In maps we can only map the body segment, here we need MSH.10 which can't be done in maps.

    if we run it in Original mode with no value in MSH.15 and MSH.16 of the actual message we are  not getting the ACK generated.

    Is this something done wrong in accelerator configuration explorer, the MSH.4 and MSH.5 equals party name XYZ.is there any other vital configuration part or convention we are missing to have BTAHL7 Configuration Explorer to work properly in original mode.

    Thursday, January 26, 2017 2:11 PM
  • HOLD ON!

    Exactly why do you want to do this?  There is nothing in HL7 that remotely requires this and would require a completely custom numbering scheme.

    My opinion, it's very bad idea to even try.

    MSA02 is the message reference per HL7.

    • Proposed as answer by Angie Xu Friday, February 10, 2017 8:25 AM
    Thursday, January 26, 2017 4:55 PM
    Moderator
  • The correct answer: don't even try. This is not standard HL7.

    The ref value is in MSA02 per HL7.

    This is not a problem with HL7 or BizTalk Server. This is a problem created by your Trading Partner.

    If this is being pushed by a Trading Partner, the first response is simply NO, because this is not standard HL7.

    If they keep pushing this, your next step is to inform your management that because the Trading Partner is requiring non standard HL7, it will take you a lot of extra time and money to support this. You will need a completely custom numbering scheme.

    Here a nice description of MSH10. It makes no reference to returning the originating Message ID. hl7resources.com/Public/index.html?a55433.htm

    Friday, January 27, 2017 1:22 PM
    Moderator