Programmer's < fumble jeopardizes thousands of medical reports

I wouldn't necessarily think this is an XML / escaping issue without knowing how their reports are stored. It may be as simple as a bad rule for non-printable characters for display, as DICOM tools can have varying abilities to deal with encodings other than ISO-8859-1. (On a PACS they may well be DICOM structured report rather than XML.)

Not an isolated incident

This looks like poor escaping. There is supposedly a standard for interfacing between medical systems called "HL7". V2 of HL7 is bad enough. V3 is starting to be rolled-out and it is a total cluster****.

Anyway, as a regular user of these medical systems (not an administrator), I have yet to see one which correctly handles escaping across the various interfaces. Every single system I have used so far, at multiple hospitals and outsourcing firms, screws something up.

For example, a common issue is incorrect handling of escaping. The character & is a special character in HL7, so needs to be escaped. However, it is rare for the receiving system to de-escape the text. Hence "The patient was advised to attend A&E" becomes "The patient was advised to attend A\T\E".

Another common issue is incorrect handling of character sets. HL7 is meant to use UTF8. Occasionally, sending systems often screw-up the conversion from Win1252, or fail to do it, or do some sort of other incorrect conversion. More commonly, however, the receiving systems often assume that the incoming data is ASCII or ISO8501 and this buggers up accents (which some voice recognition software includes in phrases such as deja vu, or in the names of eponymous medical conditions). One example of this which has recently come to light is that dictating the word "dash" into dictation software generates an 'n-dash' character, which then gets lost in an incorrect character set conversion and converted to a question mark. This can significantly change the context of a medical opinion, by turning it into a question.

Having had discussions with a bunch of vendors installing the software I use, most of them aren't interested. I certainly showed the rep from one the chaos coming from loss of accented characters - there was no interest to fix it other than "don't use accented characters in your reports/letters", after their tech support closed the ticket as "won't fix".

Of course, it often isn't one vendor's fault - and at some sites, there are multiple systems doing incorrect escaping or format conversion - so you get HL7 escape characters interspersed with HTML codes like <BR>, or you get real beauties like A&E becoming A&bsol;&bsol;T&bsol;&bsol;E (at least 3 incorrect escaping there).