It loses something in translation
By Shawn Vincent
Have you seen Translation Party yet? It’s one of the wonders created by having access to free machine translations provided by Google. Translation Party translates what you type in between languages and then spits out the result. I love this thing! I’ll use it to illustrate how healthcare standards can produce garbled results as terms get translated back and forth over time.
This morning, I typed this in:
“Standards provide the technical language and medical terminology to enable the thousands of healthcare providers across the country to communicate and share health information in a consistent, safe and reliable manner.”
Translation Party ran for a while, translating back and forth between English and Japanese, and came out with this:
“Serving thousands of its shared oral and communication information technology security standard medical security protection medical terminology national integrity.”
Hilarious, right? It’s like a badly translated assembly manual for a kid’s toy. I especially like “national integrity.” And where did “oral” come from? “Medical terminology” apparently survived unscathed.
Now imagine all medical records going through something similar before being seen by a medical professional. Horrifying, right? Nobody would seriously consider this, right?
Actually, this is what we do for most integration projects. And we generally make it worse over time.
Systems written by various vendors have different internal “languages” for representing medical data. Some systems represent a medication as a single entity. Some systems represent them as a series of actions (start, discontinue, hold, resume, etc.) that lead to its current state. Some systems represent data as free text. Some systems use highly structured information. Most systems use various code systems for things.
Every time you translate from one language into another, you introduce error. My favorite example in health care is from a presentation by David Markwell (http://www.hiqa.ie/system/files/workshop_HI_CicSnomedCt_20100127.pdf).
SNOMED CT and ICD-9 each have a code for “Anemia.” SNOMED CT has “271737000 – Anemia,” while ICD-9-CM has “285.9 – Anemia, NOS.”
This looks like straightforward one-to-one mapping, until you realize that “271737000” includes anemia caused by chronic blood loss, and “285.9” explicitly excludes it!
Translating these codes just got a whole heck harder. To accurately translate, you need to dig through the patient chart for evidence of chronic blood loss.
What do people do in a situation like this? Well, most teams typically just map one-to-one and figure that the few times that the error occurs, probably nobody will get too badly hurt.
Doing anything better than this is usually prohibitively expensive. Normally, decisions like this don’t even get publicized or raised as issues to management of the project.
Remember Translation Party’s garbled translation? There are thousands of examples like this, many of them way more subtle and harder to detect. Combine this with the fact it is impossible to test for errors like this in real world systems, and you’ve got a real problem on your hands.
So this is a problem with translation, and one we have to deal with when we connect systems together. As long as we go in with our eyes wide open, we can defend ourselves: get great clinical analysis from the teams doing the translation work and budget the necessary time to do a great job.
Standards make the situation worse.
In normal systems integration (without standards), you just wire a network between the two systems, hire a great team, and build translations. This is what is known as “point-to-point” integration. It’s typically a lot of work, but it gets done. There’s always something lost in translation, but you can get better translations by spending more time and energy.
Of course, the systems integration cost is unacceptable in many cases; we’ve already spent too much on health care, right? People don’t want to build a thousand point-to-point translations.
Enter standards. The normal argument goes: with standards, everybody just has to translate once to the standard. Then you get inter-operability for lower cost. This is fine as far as it goes, but be aware that the claimed cost savings comes with a different cost: lower quality translations.
As Translation Party has shown for human languages, every time you translate, you lose a bit of meaning.
If you introduce an HL7v3 standard interface between the two legacy systems, you need to translate from legacy system 1 to HL7v3, then translate again from HL7v3 to legacy system.
The extra translation loses more information and introduces new errors.
This is not just true in theory – it holds in practice as well. In our experience, translating data between EMR systems using provincial standards, is much harder to do a good job translating by using an intermediate format than going straight from one system to another.
So what concrete advice can we give to resolve this?
1. Translation is inevitable: For the short to medium term, if you are connecting two systems, prepare yourself to do the translation work.
2. Translation is hard and time-consuming: for most translation projects; there’s a lot of hard work involved and you need good people. Invest in a good team and budget enough time.
3. Translation is lousy: know that your interface will not be perfect. If you don’t invest enough in the translations, it might be downright poor. Wise project leaders might demand a report of the potentially lousy translations made.
4. Remember Translation Party: transforming multiple times can really degrade meaning. Be wary of adding another translation step between your data and yourself. If you have to accept such a system, spend time ensuring that the end-to-end translation is acceptable.
The cost savings of standards may outweigh the danger of the additional translation step. Maybe getting any data at all, however mangled, is better than no data. But go in with your eyes wide open and be aware of the risks and challenges.
Check out Google’s Translation Party at http://translationparty.com/
Shawn Vincent is Director of Development at Telus Health.
Posted March 14, 2013