Xlate: XML to HL7 ( Fatal Error )

[Andre van Olden]

Receiving Fatal Error from an Xlate where I am trying to copy data from an XML element to an OBX segment.

The XML element does contain formatting characters ( line feeds etc.. ) and I need these for the formatted OBX.5.

If I remove these control characters, the error goes away, but I need the formatting to remain for the display of the OBX in the receiving system.

Tried compiling the .xsd with Formatting = ON with no success.  Any assistance would be appreciated.

Topic

[Jim Kosloskey]

Andre,

I am no XML expert by any means but isn’t there an escape mechanism in XML to escape control characters (like line feed) in the body of a data element?

Moreover, if the receiving system is truly parsing HL/7 properly, I would expect the system to choke on unescaped line feeds imbedded in the observation text as that signifies end of segment in HL/7.

email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.

[Robert Kersemakers]

Hi Andre,

You will need to replace the line feeds coming from your XML with .br for your HL7 in order to save the formatting. As Jim said: a line feed in HL7 means the end of the segment and will give you errors.

There are only a few escape characters in XML:

<        <    less than >       >    greater than

&    &    ampersand

'    ‘     apostrophe

"    ”     quotation mark

Everything else in between start/end tag is considered data, so you can include line breaks etc.

Zuyderland Medisch Centrum; Heerlen/Sittard; The Netherlands

[Rick Martin]

Hi Andre,

Long time no talk!  Are the embedded characters encoded in the XML like this: ?

I had posted something about that on this board last year.  In my case, the parser was treating those sequences as actual carriage return/line feeds.  I ended up having to strip them from the XML document before processing.  If you need them in the final document, you will probably have to substititute them with something else prior to processing.

Rick

[John Hervatin]

I have seen receiving systems that don’t like the .br.  Another substitution you could make is a tilde.  Then you will have created repetitions of the OBX-5 field.  Many receivers display each repetion on a separate line, so the tilde acts like a line break.

[Robert Milfajt]

There was an excellent explanation of this in another thread.  The problem had to do with Cloverleaf only supporting ISO-8859 and not utf-8 or utf-16.  I cannot remember, but it was version specific.  Can someone dig up a link to that thread, it came out within the last few week.

Robert Milfajt
Northwestern Medicine
Chicago, IL

[Robert Milfajt]

Here is the other thread which explains this and the workaround.

https://usspvlclovertch2.infor.com/viewtopic.php?t=3006&highlight=utf16

Hope this helps,

Robert Milfajt
Northwestern Medicine
Chicago, IL

[Author]

Replies