NON-ASCII Character

Clovertech Forums Read Only Archives Cloverleaf Cloverleaf NON-ASCII Character

  • Creator
    Topic
  • #51958
    Robert Hamden
    Participant

      I have a sending system providing an dOBX with the 1/2 as a symbol, CLoverleaf translate it to something different:
      OBX|3|FT|Instruction^Dosing Instruction^DAWNCF|1|Warfarin Sun Mon Tue Wed Thu Fri Sat.brmg        2? 2? 2? 2? 2? 2? 2
      [code]OBX|3|FT|Instruction^Dosing Instruction^DAWNCF|1|Warfarin Sun Mon Tue Wed Thu Fri Sat.brmg        2? 2? 2? 2? 2? 2? 2

    Viewing 7 reply threads
    • Author
      Replies
      • #72493
        Jim Kosloskey
        Participant

          When you look at the inbound message in SMAT and/or run it through the HL/7 tester does the 1/2 symbol appear?

          What release of Cloverleaf?

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

        • #72494
          Robert Hamden
          Participant

            5.5

            When I run the message through the tester I get the odd symbol you see in the second line of code.

          • #72495
            Jim Kosloskey
            Participant

              Well obviously the source system is deploying a different use of extended ASCII than Clovelreaf is.

              Is the hex value preserved (I suspect it is) in the translated message?

              If so what does the receiving system display that extended ASCII hex value as (not everyone uses the same representations for the extended ASCII character set)? If the receiving system does not display that hex value as 1/2 then you will need to come to some resolution (perhaps a regsub of that hex value for something like .5).

              If the receiving system does display that hex value correctly then the only issue is what is displayed in Cloverleaf(R) and how big an issue is that?

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

            • #72496
              Robert Hamden
              Participant

                The receiving system displays the 1/2 symbol with no problems.

                So is there a way to set the thread to use extended ASCII as the clinical requirement is to have the 1/2 symbol as apposed to .5

              • #72497
                Jim Kosloskey
                Participant

                  If the receiving system displays the hex value for 1/2 correctly then you need to check the hex value for that character in the Xlated message and compare it to the hex value for the same character in the inound message.

                  You can do that by saving the inbound message to a file and running hcihd from the command line pointing to the file. You can then find the appropriate byte and see what the hex character for that byte is.

                  Then run the Xlate tester against the inbound file saving the result to a file. Then again using hcihd agianst the Xlated file see if the same byte has the same hex character.

                  If it does, give the Xlated message to the receiving system and have them check to see if it displays correctly.

                  I all of the above is true, what do you care what it looks like in the tester, the receiving system is getting the same value as the sending system is sending.

                  Now if the hex character changes after the Xlate then that is something to address.

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

                • #72498
                  Robert Milfajt
                  Participant

                    Robert, can you provide the hex values of the 1/2 symbol in the original message and the translated message?

                    Robert Milfajt
                    Northwestern Medicine
                    Chicago, IL

                  • #72499

                    From dev …

                    Quote:

                    Before 5.8 as long as there is no Tcl involved with the message it should work in translations. If Tcl touches the message then all may be lost and translations have a way of using Tcl when you least expect it.

                    In 5.8 extended ASCII and ASCII are NOT the same thing so the input encoding should be set to 8859-1 or cp1252 or things go bad real fast. The two standards differ but not sure the one half character is one of the differences.

                    Please note that there is an encoding option in the test routines in 5.8 and it must also be set as above if the input message is not pure ASCII (byte values below 127) or UTF-8.

                    -- Max Drown (Infor)

                  • #72500
                    Mark Mathews
                    Participant

                      You might try changing the encoding format of the inbound message from UTF-8 to greek.

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