circumflex character

[tyler tesson]

We have recently ran into an issue when Epic beaker sends us a circumflex character (circumflex is a mini carrot

Topic

[tyler tesson]

attachment

[Kevin Kinnell]

Tyler —

We haven’t run into this problem with Epic.  Is there a profile variable for the character encoding in that results AIP?  Try checking your ASCII_CHARS_TRASLATION_TABLE setting — your table may be messed up.

You should talk to your TS about this.  You shouldn’t getting Unicode (probably Unicode, anyway) out of Epic unless you’re getting results as a formatted report, not HL7.

[Elisha Gould]

Are you using cloverleaf 5.8 or greater?

It can be a little painfull to get this to work in 5.8+ as extended characters are converted between encodings and the binary data differs between each encoding type.

In 5.8+, cloverleaf will handle data internally in utf-8 format.

It will convert from the specified encoding for the inbound thread to utf-8 and to the specified encoding on the outbound thread.

To handle this case you will need to set inbound to the encoding used by Epic, and the outbound to the encoding used by the other side.

If you need to perform mapping, you will need to use the utf-8 character, rather than whatever Epic is sending.

If you need to work with the original data, you’ll need to use “encoding convertto identity” then convert back to utf-8 once done.

[Charlie Bursell]

How are you viewing the output?  There is a goo chance the circumflex is there and just not displaying.  All of screen displays from Cloverleaf will display UTF-8 and thus the box.

Copy the output to WordPad or similar and see what you get

[tyler tesson]

we are using version 5.8.5. Right now encoding for the inbound and outbound is set at ASCII. When I pasted the inbound and outbound smat in wordpad I do not see the circumflex or the small box, it is just blank, which reflects what the vendor is saying. Our Epic TS does not think they can fix this on their end, so they want us to explore all avenues on our end, but I’m not able to find a successful one that this point. Epic has their encoding set as the same as all the other interfaces that go through us, which we use ASCII.

Attached is wordpad.

[Kevin Kinnell]

Epic is sending UTF8, which for most purposes is ASCII.  Probably the font in use in the client is missing a glyph for the circumflex codepoint, which is why you see a box.

Try looking at a hex-dump of the message if you want to get the real details.

Can the AIP be tweaked to send the escape for the component separator?  Fixing this might take an SLG, if you haven’t opened one.

Otherwise, you might try doing a map to the escape in the engine.

If neither of those is an option, can Beaker send the measurement unit in some other format?  Maybe 1E3 would be acceptable.

[tyler tesson]

When I look at it in SMAT and test it using the following encoding I see the circumflex and the string map to change it works.

arabic, cyrillic, GB2312, greek, hebrew, latin1,2,3,4, windows 1253.

But the thread it comes inbound on splits to 3 different vendors, so if I changed the encoding from ASCII couldn’t it potentially affect the other vendors. Also, how do you perform hex-dump?

[Kevin Kinnell]

No, you definitely don’t want to change it from ASCII, but you do want it to come into the thread and change it to ASCII.  Since you can’t see it in ASCII but can see it in another encoding, you can fix this in the engine by accepting the encoding, and then substituting the component escape for the circumflex.  You have to make sure you are not getting any other encoded characters from Epic, or you will be doing a translation for each of them.  When the output is “clean” you can send it, as ASCII, to the downstream systems.

Cloverleaf has hcihexdump for dumping a file from the command line.  Programming editors usually have a way to view files as hex.

And, not to harp on it, but Epic should be fixing this.  The Bridges TS and the Beaker TS need to have a little talk and get this working as ASCII encoded HL7.

[tyler tesson]

I think believe I am following you,  Kevin, but I want to make sure. So I leave the encoding on the Inbound and Outbound thread set as ASCII.

Then:

you can fix this in the engine by accepting the encoding, and then substituting the component escape for the circumflex.

Is this going to be done in a tcl? How do I accept the encoding, then substitute the component escape. Sorry, I haven’t done much outside of the standard ASCII encoding.

[Kevin Kinnell]

It would be best if your thread was set to accept the encoding Epic is sending.  This might take some experimentation to figure out.  The most likely guess is Latin-1, I think, even if all of the settings say it’s ASCII.  You know it isn’t really ASCII, because you see the circumflex.  I’m assuming you’re seeing the

[Author]

Replies