Special encoding character sequence

[Eileen Pitts]

I need to send over a special encoding character sequence but I don’t know how to get a cent sign.  They want “cent sign ~ @.  Anyone have any ideas?

Topic

[Russ Ross]

The cent sign might be different characters on different platforms because it is outside the normal characters and has the potential to be displayed differently on different systems depending on the selected font.

What you might do is ask the vendor to specify what HEX character he wants you to use.

Otherwise, you may have to use a hex-editor on the foriegn system and play around to figure out what will work in your case.

I have a DMS to TRAN integration that I ended up changing the MSH encoding characters so not to be within the printable range and just by chance one of them is the cent sign.

That made it easy for me to attach a screen shot to illustrate that the character hex A2 on my AIX system displays as the cent sign.

Russ Ross
RussRoss318@gmail.com

[Anonymous]

Could you post how it was possible to change the encoding characters and the field delimiter? I tried this in an xlate without success.

Thanks. 😮

[Keith McLeod]

In the Xlate I copy | into MSH:1

and then copy ^~& to MSH:2 so it looks like:

copy =| –> 0(0).MSH.00001

copy {=^~&} –> 0(0).MSH.00002

Note: The Curly Braces are added by program…=^~& is what I typed in.

This makes the outbound messages contain the normal HL7 specifiers.  I use this for systems receiving messages from STAR.  Hope this helps……

[Russ Ross]

Unfortunately, I too gave up on doing it in the xlate like I wanted because the version of TCL under QDX 5.2.1P2 for AIX that I currently use handles Unicode ( UTF-8 ) and explodes what we want to be a one byte HEX A2 character into 2 bytes, thus making a mess out of things.

As I had mentioned, I found this painful just like you are.

I had to look at what we did to get around it because my mind had blocked out the unpleasant past.

I see that we had the source system put the funky character in the message and that comes across since cloverleaf will pass what it gets but gives you hell when you try to hardcode HEX A2 in the translate or any TCL code.

Then we changed all translates that wanted typical encoding characters to overwrite the funky encoding character coming from the source system.

If you really wanted to do it in the translate, I would see if there was a way to deactivate the Unicode ( UTF-8 ) feature in TCL.

The world is still trying to come to grips with a character set that everybody can use.

Russ Ross
RussRoss318@gmail.com

[Anonymous]

Sorry, but I really need the transformation. The sending system uses standard chars, but the receiving system can only handle the special char:

Field Delimiting Character:

[Russ Ross]

I may have some good news for you.

My initial testing looks promising; you be the judge.

I also want to make mention that Jim Kosloskey and I worked together on the original problem faced by Phil Connolly to figure out that unicode ( UTF-8 ) was the underlying problem, which used up 3 peoples time over about a 2 day period.

Thanks to Phil and Jim for their cooperation to help get to the bottom of the matter.

Jim is also quick to adimantly recommed that the vendors handle HL7 escaping of field & endcoding characters that appear in textual fields within the HL7 message.

I agree with Jim but have found many vendors are unaware of that part of the HL7 standard and many do not conform to it but yet claim to be HL7 compliant.

Driving to work today this unicode ( UTF-8 ) hurdle was like a splinter in my mind.

I started to wonder how I might get around the problem if I too wasn’t able to modify the message on the source system.

The trick is to modify the message without using TCL since it will make many of the extended characters become 2 bytes instead of the desired one byte.

Unfortantely, the copy via Xlate has the behaivor of using TCL to do the copy.

In your case if you map the encoding characters

Russ Ross
RussRoss318@gmail.com

[Author]

Replies