Announcement

Collapse
No announcement yet.

end of segment characters

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

  • end of segment characters

    Hi,

    I have a channel that uses an LLP Sender. The end of segment character is 0x0D - the default. However, the interface specialist for the receiving system tells me he's not seeing 0X0D, but 0x0A (line feed).

    In my template, I have three segments defined:

    Code:
    MSH|^~\&|MEDPLUS|PG|TouchScript|Interface|${date.get('yyyyMMddHHmmss')}||ADT^A31|${message_id}|D|2.2||||||
    EVN|A31|${date.get('yyyyMMddHHmmss')}||||
    PID|||${patientid}-${patientcaseid}|${userdefinedkey}|${lastname}^${firstname}^${middleinitial}||${birthdate}|${gender}|||${address}^${address2}^${city}^${state}^${zip}||${homephone}|||${maritalstatus}|||${socialsecurity}|||||||||
    I'm sure the 0x0A he's reporting is because I have line feeds in my template. I deleted the line feeds (so all the lines run together), but then he said he didn't see any segment separator at all.

    Am I doing something wrong?


    Thanks,

    --
    James

  • #2
    Re:end of segment characters

    James,

    This should be a quick fix. Can you post your channel please?

    Your template will need the line breaks after segments.
    Jon Bartels

    Zen is hiring!!!!
    http://consultzen.com/careers/
    Talented healthcare IT professionals wanted. Engineers to sales to management.
    Good benefits, great working environment, genuinely interesting work.

    Comment


    • #3
      Re:end of segment characters

      I've attached a copy of my channel. Thanks for your help.

      --
      James
      ADT_A31_Channel___LLP.xml (29670 bytes)

      Comment


      • #4
        Re:end of segment characters

        Don't worry about the template: the message created don't use the control character used in the templates.

        I recomend you using a net sniffer (like wireshark) to check what's really happening.

        Comment


        • #5
          Re:end of segment characters

          albertosaez wrote:
          Don't worry about the template: the message created don't use the control character used in the templates.

          I recomend you using a net sniffer (like wireshark) to check what's really happening.
          I followed your advice and did some packet sniffing. He's right - no 0X0D, just 0X0A between segments. I don't follow your comment about control characters in the template.

          I've attached a screenshot showing the summary tab of my channel setup. As you can see, the end of segment character is 0x0d.

          Surely I'm doing something wrong, but I've no idea what. Any further advice would be greatly appreciated.


          EDIT: my screen capture was too large to upload to the forum, so I posted it
          here.


          --
          James

          Post edited by: jswaff, at: 06/06/2008 14:11

          Post edited by: jswaff, at: 06/06/2008 14:13

          Comment


          • #6
            Re:end of segment characters

            If I'm following you right, Mirth is sending the right <cr> character (0X10), but the receiver application is getting 0x0A.


            You should check with a sniffer at the receiver side too to be sure, but if this strange issue is happening, it could be caused by some net hardware.

            By the way, Have you try sending test messages using HL7Browser or similar software ?

            Comment


            • #7
              Re:end of segment characters

              albertosaez wrote:
              If I'm following you right, Mirth is sending the right <cr> character (0X10), but the receiver application is getting 0x0A.


              You should check with a sniffer at the receiver side too to be sure, but if this strange issue is happening, it could be caused by some net hardware.

              By the way, Have you try sending test messages using HL7Browser or similar software ?
              No, I don't think we're on the same page. The receiver is getting exactly what's in my template. He's seeing 0x0a (decimal 10==LF) between segments, because I have line feeds between the segments in the template.

              What I don't understand is where the end-of-segment separator character comes in to play. It's clearly set up to be 0x0d, and that's what the receiver wants, but Mirth is not sending 0x0d between segments. I've verified this using tcpdump and a hex editor on the sender side.

              I'm still new to Mirth so I'm leaning more towards this being a user error on my side, not a Mirth error, but I'm not entirely sure of that.

              --
              James

              Comment


              • #8
                Re:end of segment characters

                Now I can see the problem.

                I've checked your channel. The problem is that you're using the output data in the Template of the destination.

                The template should be used in the transformer, into the outbound template. Instead Mapper steps you should use Message Builder steps.


                In the destitantion form, you should use the default value at the "template" textbox (${message.encodedData})

                Comment


                • #9
                  Re:end of segment characters

                  Thanks for your help. I think I'm almost there.

                  I've set up the outbound template in the destination transformer. Here it is:

                  Code:
                  MSH|^~\&|MEDPLUS|PG|TouchScript|Interface|${date.get('yyyyMMddHHmmss')}||ADT^A31|1234|D|2.2||||||
                  EVN|A31|${date.get('yyyyMMddHHmmss')}||||
                  PID|||709-1|VEN709|Swafford^James^F||19750301|m|||addy1^addy2^Greenville^NC^27858||(555)555-5555|||M|||123-45-6789|||||||||
                  I've deleted all the mapper steps and added a few message builder steps.

                  The message segment is something like: tmp['PID']['PID.3']['PID.3.1']
                  and the mapping value something like: msg['pc.patientid'].toString()

                  When using a file writer, the values I'm mapping are just blank now. The value from the template isn't used, nor the value from the database/inbound message.

                  Thank you again,
                  --
                  James

                  Comment


                  • #10
                    Re:end of segment characters

                    jswaff wrote:
                    Thanks for your help. I think I'm almost there.

                    I've set up the outbound template in the destination transformer. Here it is:

                    Code:
                    MSH|^~&|MEDPLUS|PG|TouchScript|Interface|${date.get('yyyyMMddHHmmss')}||ADT^A31|1234|D|2.2||||||
                    EVN|A31|${date.get('yyyyMMddHHmmss')}||||
                    PID|||709-1|VEN709|Swafford^James^F||19750301|m|||addy1^addy2^Greenville^NC^27858||(555)555-5555|||M|||123-45-6789|||||||||
                    I've deleted all the mapper steps and added a few message builder steps.

                    The message segment is something like: tmp['PID']['PID.3']['PID.3.1']
                    and the mapping value something like: msg['pc.patientid'].toString()

                    When using a file writer, the values I'm mapping are just blank now. The value from the template isn't used, nor the value from the database/inbound message.

                    Thank you again,
                    --
                    James
                    Just a quick note to say I figured out the problem above. I went ahead and mapped ALL the values, and some showed up in the output and some didn't. Those that didn't are the ones that had the table qualifier prepended to the field name.

                    When I changed the mapping value from
                    msg['pc.patientid'].toString() to msg['patientid'].toString(), they all showed up.

                    I still have to set up the LLP sender and verify the 0x0d character is there (my original problem), but I'm confident it will be... I only had a minute and wanted to post that the above was solved.

                    THANK YOU! I hope I can give back to this project in the future. Honestly, I think the documentation is kind of lacking, but the support has been fantastic.

                    Thanks again,

                    --
                    James

                    Comment

                    Working...
                    X