New post
Question
· Nov 26

HL7 Encoding issue

#HL7 #InterSystems IRIS for Health

Dear All,

I have been sent an HL7 message as a file with the MSH segment as follows....

MSH|^~\&|SendingApp|pms3medd|HealthLink|cribrumt|20241121050000|PKI|ORU^R01|01_ASCIItest_2|P|2.3.1||||||UNICODE

I try picking up the file with a "EnsLib.HL7.Service.FileService" business service using a  EnsLib.File.InboundAdapter adaptor.  The Character set is set to "Native" and the Default Char Encoding to latin 1.

I am seeing the following error:

ERROR <Ens>ErrGeneral: Incorrect Character Encoding/Translation Table used for file.(Native/RAW)
+
ERROR <Ens>ErrException: <TRANSLATE>ParseIOStream+71 ^EnsLib.HL7.Parser.1 -- logged as '-'
number - @''

 

I have tried adjusting the the cCharacter set and the Default Char Encoding to no avail.  Has anyone encountered this problem before? Note that I need this interface to pick up ASCII encode messages as well.

 

Reagrds

 

Brad

Product version: IRIS 2024.1
Discussion (4)1
Log in or sign up to continue
Julian Matthews · Nov 26

Hey Brad.

The adapter has two sets of options here which can lead to confusion. We first have the charset for the adapter for the File adapter elements, and then the Default Char Encoding for the HL7 adapter elements.

As a starting point, I would try changing the Charset setting to Binary, and then setting the DefCharEncoding to UNICODE to match what is in your header.

0 0
Julian Matthews · Nov 27

Hey Brad.

Apologies, I'm not entirely sure why I typed unicode in full upper-case when that's not present in the helper dialog or the drop down.

How confident are you that what you're receiving is actually unicode?

The adapter by default will look at what's in MSH:18 and will only use the selection in the adapter setting if this is blank in the message.

Firstly, try setting this to "!latin1" (without the quotes) to force it to operate as latin1 as per the support info for DefCharEncoding:

Putting ! before the encoding name will force the use of the named encoding and will ignore any value found in MSH:18.

If that fails, I'd then cycle through the other options starting with "!utf-8" and then one of the variants of Unicode available when using the drop down

Be careful - there are some overlaps when it comes to come encodings where things look fine until certain symbols come into play, at which point you end up with some interesting outputs. 

0 0