Announcement

Collapse

Mirth Connect 3.12.0 Released!

Mirth Connect 3.12.0 is now available as an appliance update and on our GitHub page. This release includes database performance improvements, improves visual HL7 representation, message pruning, keystore handling, PDF generation, community contributions, and fixes several security vulnerabilities. This release also contains many improvements to commercial extensions. See the release notes for the list of fixes and updates.

Download | See What's New | Upgrade Guide | Release Notes

For discussion on this release, see this thread.
See more
See less

Mirth's handling of HL7 acknowledgments

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Mirth's handling of HL7 acknowledgments

    I am seeking some help to get mirth to pass through an HL7 acknowledgment message without alteration. I have placed Mirth between a registration system and an MDS system because neither vendor will modify their interface. I am using Mirth to transform the registration HL7 messages into a message the MDS system will process. But I want the MDS system's HL7 acknowledgment message sent back to the registration system without being altered. If the the HL7 ACK is an AA there is no alteration, however, for AE and AR HL7 acknowledgement message types, Mirth inserts it's own message between the LLP start character and the MSH of the HL7 acknowledgment messages as follows:

    <0b>MSH|^~&|MDS|Fac1|^Registration|^Admin|20080729 124930||ACK|1|T|2.3<CR>
    MSA|AA<CR>
    <1c><CR>



    <0b>NACK sent from receiver: [Application Error]

    : MSH|^~&|MDS|Fac1|^Registration|^Admin|200807291249 30||ACK|2|T|2.3<CR>
    MSA|AE<CR>
    <1c><CR>



    <0b>NACK sent from receiver: [Application Reject]

    PV1: MSH|^~&|MDS|Fac1|^Registration|^Admin|200807291249 30||ACK|3|T|2.3<CR>
    MSA|AR|100<CR>
    ERR|PV1^3<CR>
    <1c><CR>

    I thank you in advance for any help I may receive. APX_to_IG.xml (7258 bytes)

  • #2
    Re:Mirth's handling of HL7 acknowledgments

    I apologize for the typographical errors in my included HL7 acknowledgment messages. I have corrected them below. But, while the editor and preview show the backslash in the position for the escape character in the encoding characters, it does not appear in the message when viewed from the forum.

    <0b>MSH|^~\&|^MDS|^Fac1|^Registration|^Admin|20080 729124930||ACK|1|T|2.3<CR>
    MSA|AA<CR>
    <1c><CR>


    <0b>NACK sent from receiver: [Application Error]

    : MSH|^~\&|^MDS|^Fac1|^Registration|^Admin|200807291 24930||ACK|2|T|2.3<CR>
    MSA|AE<CR>
    <1c><CR>


    <0b>NACK sent from receiver: [Application Reject]

    PV1: MSH|^~\&|^MDS|^Fac1|^Registration|^Admin|200807291 24930||ACK|3|T|2.3<CR>
    MSA|AR|100<CR>
    ERR|PV1^3<CR>
    <1c><CR>

    Post edited by: dlbaugh, at: 08/01/2008 17:14

    Post edited by: dlbaugh, at: 08/01/2008 17:28

    Comment


    • #3
      Don,

      Did you ever manage to get a resolution to this issue as I am facing a similar one. I need to send the original NACK back to the sending application but cannot work out what I need to do.

      Thanks,

      Richard

      Comment


      • #4
        On the source LLP listener "Send ACK" option, select "respond from" and select the destination which ACK you need to send back to the source system. With the default option "Yes", a Mirth generated ACK will be sent to the source system.
        Daniel Svanstedt
        Software Engineer
        Mirth Corporation

        Want professional services, support, and enterprise or virtual appliances? It's all available from the Mirth Corporation:
        Mirth Support | Mirth Training | Mirth Appliances | Online Training | Developer Q&A

        Don't forget, Mirth Support gives you access to all of our online training videos, and silver support gives you access to developer Q&As!

        Comment


        • #5
          To get rid of the ...

          NACK sent from receiver: [Application Error]

          ...in the message sent back to the source, keep using the Respond From on the listener side but also on the destination side turn Process HL7 ACK to No. This should send exactly what the destination responded with without any additions added by the engine.

          Comment


          • #6
            Originally posted by Frostfire View Post
            To get rid of the ...

            NACK sent from receiver: [Application Error]

            ...in the message sent back to the source, keep using the Respond From on the listener side but also on the destination side turn Process HL7 ACK to No. This should send exactly what the destination responded with without any additions added by the engine.
            Good tip, thanks for posting that!
            Jacob Brauer
            Director, Software Development
            NextGen Healthcare

            sigpic

            Comment


            • #7
              thanks, I needed this solution as well!

              however, there's still one minor issue: the response message now maps as

              SUCCESS: [] MSH|^~\&|APP|FAC|||20100714183105...
              (where the [] seems to be a carriage return )

              Is there any way to strip that too?

              thanks in advance!

              Comment


              • #8
                I've done something similar where I'm routing different HL7 messages to different ports on another server depending on what the message type was.

                I was getting the extra bit at the beginning of the message as well, this is what I did.

                In a postprocessor step I captured the Response of my destination while stripping the \x0B that seemed to be in the response (ADT being the name of one of my destination connectors)

                Code:
                var ADTStatusMessage = new String(responseMap.get('ADT').getMessage()).replace(/\x0B/g,'');
                Then created a custom response using

                Code:
                responseMap.put("MessageResponse", ResponseFactory.getSuccessResponse(ADTStatusMessage));
                There is a lot of other things I'm doing depending on if the response is a success/failure, etc... but I think this bit might point you in the right direction.

                Comment


                • #9
                  I had the same problem with removing the first 0x0b from the NACK and this works! It's quite strange that Mirth adds an extra 0x0b before a NACK.

                  Mirth Sends: <0x0b><0x0b>ACK message<0x1c><0x0d> and because of the extra <0x0b> the NACK errors on the receiving system. So with this I transformed the NACK to <0x0b>ACK message<0x1c><0x0d>.

                  Comment

                  Working...
                  X