Do you mean in HL7 messages? The only time something get’s messed up is if someone uses one of the separator characters like a bar or caret. The other characters should move on through without problems. In the old software before 3.7.1 nulls caused a problem because they were string terminators in TCL but that was fixed long ago.
I’m sorry, yes, I mean in HL7 result messages (OBX segments specifically). We have some results that have special characters (e.g. greek symbols such as alpha, beta, delta; degree marks; and trademark symbols).
I was wondering how others handle those types of things? Are they typcially just stripped out or converted to something else?
As Greg already pointed out: the characters you mention will not be a problem for Cloverleaf!
It all depends on the character set that the receiving system is able to manage. I only had to strip these special characters when sending messages in EDIFACT format, as EDIFACT only uses part of the ASCII character set.
What you should watch out for (and Greg mentioned this also) is when the sending system is sending text with HL7 separator characters. If the sending system is sending HL7 messages itself, these characters will already be converted: a ‘&’ will become a ‘T’.
If the sending system isn’t sending HL7 messages, but flat records for example, you need to make sure to convert the separator characters in texts before/during translation into HL7.
Zuyderland Medisch Centrum; Heerlen/Sittard; The Netherlands
Author
Replies
Viewing 2 reply threads
The forum ‘Cloverleaf’ is closed to new topics and replies.