Clovertech

Carriage Returns in Hl7 Messages

› Clovertech Forums › Read Only Archives › Cloverleaf › Cloverleaf › Carriage Returns in Hl7 Messages

  • Creator
    Topic
  • December 5, 2006 at 1:30 pm #48929
    Ray Mullen
    Participant

      Hi I have a simple question, We are only fairly new to HL7 so excuse the simplicity in the question.

      We are currrently setting up a new interface to pass a specific Lab result from our Lab system to a new HL7 Interface. The messgage from the Lab is in a fixed record layout and is translated to a HL7 ORU_R01 message.

      The problem is there are carriage returns line feeds in a text field that is being mapped to the 3rd Field ( Comment ) in the NTE Segment. The vendor said that he cannot accept these messages that every HL7 Message is delimited by Otherwise theres no way to know what segment is next and there are extra ‘s appearing, ie where the text field has ‘s in the field.

      I Understand that each hl7 segment is determined by and on analysing the file I can see that this is correct , but where the field that has carriage returns in it,  it is also followed by a line feed.

      Basically the supplier wants me to strip out the carriage returns, which I know can be easily done ,

      But the question I have is , Is this the normal thing to do ?, or should he be dealing with it at his end , just need to know for further interfaces. The supplier wants the carriage returns replaced with ( ~ repetition characters ) or he cant accept them.

      Thanks in advance

      Regards

      Ray

    • Creator
      Topic
    Viewing 3 reply threads
    • Author
      Replies
      • December 5, 2006 at 2:23 pm #60136
        Jim Kosloskey
        Participant

          Ray,

          Having to reconstruct messages is fairly common especially when converting from one message structure to another.

          However, this is pretty simple work inside the Xlate (some Tcl will likely be required).

          You essentially will be moving the text delimited by CR/LF inside a fixed field to a NTE repetition rather than converting CR/LF to ~.

          Of course, this could be entirely done in Tcl without using an Xlate as well.

          My preference is using Tcl to extend the Xlate not to replace the Xlate.

          Have fun,

          Jim Kosloskey

          email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.

        • December 6, 2006 at 1:55 pm #60137
          Ray Mullen
          Participant

            Hi Jim , Thanks for the reply, appreciate your time,  I spoke to supplier

            and he said i need to clean all the “in field” text to remove any OR B)If multiple lines required, I should be using the “repetition seperator” eg |line1~line~line3…| within the field where The are replaced by <~>

            In your example do you mean within the translate , when i map the field to the NTE Segment create multiple NTE segments?.  Using Iteration in the translate, Not too sure how to go about this.

            I have created a bit of TCL in the Translate that looks like this,

            regsub -all — {r} $xlateInVals {~} xlateInVals

            set xlateOutVals $xlateInVals

            Am I going about this the right way?

            Thanks

            Ray

          • December 6, 2006 at 4:09 pm #60138
            Jim Kosloskey
            Participant

              Ray,

              Using iteration might be possible depending on the construction of your inbound message. However I suspect the field in question has CR scattered throught and not on any fixed repetition.

              So the approach you are taking will work. Just remember xlateInVals and xlateOutVals are Tcl LISTS and you need to treat them that way.

              Also be aware that the ~ is the default HL/7 repetition separator BUT if the vendor decides to change what he wants for separation characters (MSH-1 and MSH-2) you will need to change to match. The standard allows for these to be negotiated by trading partners.

              Also be aware that text fields (especially from non structured – not HL/7, X12, EDIFACT, etc. – messages) are likely to contain HL/7 separator characters (default |^~&). Inclusion of those characters in the HL/7 message you are sending indicates some sort of separation which is incorrect.

              It is likely the receiving system’s parser will choke on them.

              Check with the receiving system to see if they support the escaping of HL/7 separator characters in text as specified in the HL/7 standard (Chapter 2 section 2.9). They should but many don’t.

              This section of the standard is one that, in my opinion, is not partner negotiable. If you are HL/7 compliant, then you need to support this concept.

              Any way if the imbedded separator characters will be an issue, you will need to do something about it – depending on whether the receiving system supports escaping them in the HL/7 standard way.

              If they do – follow the standard as described in 2.9.

              If they don’t you will need to figure something out.

              Jim Kosloskey

              email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.

            • December 6, 2006 at 4:45 pm #60139
              Ray Mullen
              Participant

                Hi Jim,

                Thanks for your reply, it  was really informative and has given me a lot of food for thought.  I’m only new to Hl7 so still a lot to take in.

                I appreciate the time you have spent responding to my query.

                Ray

            • Author
              Replies
            Viewing 3 reply threads
            • The forum ‘Cloverleaf’ is closed to new topics and replies.