This topic contains 3 replies, has 2 voices, and was last updated by Eliot Muir 8 years, 8 months ago.

HL7 Message Encoding

roho July 17, 2014 at 11:59 am

For an LLP Listener, you can configure which encoding the incoming HL7 messages will be using.
But the messages contain information about their encoding in the MSH-18 field.

How about adding in a future version of Iguana an option to have the LLP Listener setting overridden by the MSH-18 field? E.g. if the setting is “Western Windows-1252”, and there comes a message containing “UNICODE UTF-8”, it is treated correctly as UTF-8? (Or vice versa)

A similar feature could be imagined for the LLP client, although for outgoing messages we have better control of the character set (and usually the character set of outgoing messages is fixed).

What do you think of this proposal? Do you shun the effort of parsing the MSH header? Or maybe I am being totally unworldly here?

Eliot Muir July 17, 2014 at 12:12 pm

We have had the idea before – it’s very low in our priorities. I am not sure how widely honoured this part of the standard is. In theory you might be able to use the RESTful API for the channel log to get a whole of message that comes in, parse it and the channel API to stop the channel with the LLP listener, reconfigure it and see if it works.

The risk with this is whether or not the payback in effort would be worth it on how widely implemented support is for this MSH field and then if the names used match the names in Iguana etc. etc. fun times!

Do 30 interfaces and then revisit it and see if this would have been a big time saver would be my thoughts.

roho July 17, 2014 at 12:25 pm

Ouf, that really sounds like not much fun. And if you don’t know how well-honoured this field is, myself even less so. (Even worse, in HL7 v2.4 there was only the string “UNICODE”, and you could just hope that this would mean UTF-8. Back in 2000, people were not so aware of the topic yet.) And do people even use accented letters in HL7 messages…?

One alternative I could think of is to have the character set as an optional parameter of hl7.parse(). That way, I could read the message header, and if the encoding is wrong, call hl7.parse() again with the correct encoding.

But I can understand that you have more important things to do 🙂

Eliot Muir July 17, 2014 at 12:57 pm

I’m sure you’ll have better insight into it than I will with a few months of doing interfacing in Europe.

At some point one could expose a API call in Lua to the iconv library we use I guess. I wouldn’t couple hl7.parse to character encoding directly though…

BTW – are you likely to make it to our user conference?