CORE HL7 Postmaster 2.2.5 and Higher
Created with the CORE HL7 API Libraries for .Net 8
Part 3: Preferred Text Encoding
Preferred Text Encoding: Your selection here doesn't really matter UNLESS you are processing HL7 messages which contain special characters from the extended ASCII character set (like • € ‚ ƒ … † ‡ ˆ ‰ ‹ Œ ‘ ’ “ ” • – — ˜ ™ › œ Ÿ ¼ ½ ¾ © ®).
In this section you only have 2 choices UTF-8 (the default) or ANSI (which is Windows 1252). If everyone played by the rules it shouldn't matter because HL7 messages should be plain ASCII text (only containing values from the first 128 characters of any ASCII table) and "special characters" are properly "escaped" into ASCII using the HL7 Escape Rules. If they ARE plain ASCII text then it doesn't matter which Preferred Text Encoding you select because for plain ASCII text UTF-8 and ANSI are identical and interchangeable. It's only when text data contains EXTENDED ASCII characters (like the • etc.) that Preferred Text Encoding comes into play and then it can be very important.
An example of this can be:
If your trading partner is actually sending you HL7 messages into a CORE Postmaster Listener Data Source which contain special characters and they are in an ANSI stream format the bullet character (•) would be represented by 1 byte (HEX 95), if the stream is UTF-8 the bullet character would be represented by 3 bytes (HEX E2,80, A2). So the problem comes when the Listener actually has to write the HL7 message out to a file in the Central Distribution Folder. IF it writes an ANSI message out using UTF-8 encoding (or vice versa) this will cause these special characters to become "garbled" and unrecognizable. Another example might be if you are importing HL7 messages into a database. The database itself has it's own collation, so you might find that importing an ANSI file results in special characters being garbled in your database (or vice versa).
So you can choose the Preferred Text Encoding and your Listener will save your files to disk using that encoding. Your Listener will automatically detect as the messages come in whether they contain any special characters and if they do they will translate those characters into the proper values for your Preferred Text Encoding.
Example: Your HL7 message contains a bullet character (•) and in the inbound stream and it is ANSI (HEX 95), if your Preferred Text Encoding is UTF-8 we would automatically replace that with the UTF-8 values (HEX E2,80, A2) and the HL7 message would be written into Central Distribution as a properly encoded UTF-8 file.
The Final Takeaway: IF any HL7 message enters your Postmaster via a file in the Central Distribution Folder in a properly encoded file (either UTF-8 or ANSI) AND the message contains special characters, then it will be properly re-encoded to your Preferred Text Encoding before being dispatched to any of your Destinations.
IMPORTANT NOTE: This "re-encoding" only occurs when dispatching messages from Central Distribution to Destinations. If your Postmaster is a Type 1 (see Postmaster Types) then it will depend on HOW the message files arrive in Central Distribution. For example:
•If from a CORE HL7 Listener (either a Listener Data Source, or from the CORE HL7 TCP/IP Listener) the files will be properly encoded to match your Preferred Text Encoding.
•If from a Folder Data Source no re-encoding takes place. Files are just moved into Central Distribution.
•If from a CORE SQL Data Source no re-encoding takes place and message encoding will typically match the database COLLATION.
•From other sources - No re-encoding takes place. If the files are properly encoded everything will work. If they were improperly encoded when being written then the special characters are likely irretrievable at that point.
