How Meaningful Use Perpetuates The EMR Communication Barrier

As we move towards interoperability, patient data is constantly changing hands, but proprietary EHR vendor codes inhibit the true exchange of patient information.

By Dr. Jon Handler, CMIO, M*Modal

Care improves when clinicians have all the relevant parts of a patient’s medical record. This can only happen when different electronic health records (EHRs) share a patient’s data with one another. Recognizing this, our government is promoting EHR interoperability through Meaningful Use (MU) incentives that require EHRs to speak a “common language” when sharing patient data. This solution creates significant problems (if it succeeds). History has shown that languages evolve based on the needs of their speakers and attempts to create a standard language for complex domains have failed. Fortunately, there’s a better approach that’s also much cheaper and easier to implement.

Do we need more than one language? Anthropologist Franz Boas sparked century of controversy in 1911 by writing that the Inuit tribes had dozens of words for “snow.” The Inuit language is polysynthetic – adding suffixes to a root word creates new words. Critics argued that these modifications are not new words. However, a Smithsonian anthropologist recently concluded that the Inuit language does have many more words for “snow” than English. For example, Inuit has different words for snow conducive to sledding and snow ill-suited for sledding. These distinctions may be of little value to a Floridian, but they are crucial to those who live near the Arctic.

One language may also have many sublanguages – each serving its speakers’ needs. As a result, two people can speak the same “language” but not the same sublanguage and therefore not understand one another. An English-speaking patient may not understand his English-speaking doctor (e.g. “your serum calcium of 12.4 and your symptomatology suggest a parathyroid condition”). Parents may not understand their own children’s text messages (e.g. “ROFL TTYL”).

Furthermore, a sublanguage may have many sub-sublanguages. For example, a pathologist might carefully distinguish between a whole blood, serum, and capillary glucose, while an emergency physician might consider all these “clinically equivalent” and not distinguish between them at all.

If we tried to eliminate these language differences the effort would likely be a high-cost failure, and if it worked we would end up with chaos. Either Floridians would be forced to learn, remember, and use dozens of words for ice that have no relevance to their lives, or Inuits would be forced to use a single word for ice and have no way to communicate vital information to one another.

There was an attempt to create a single world language – “Esperanto.” Many believed that a common spoken language would reduce misunderstanding and facilitate world peace. After nearly 150 years, the EU has the largest number of Esperanto speakers at 0.02 percent of its population. In contrast, 51 percent of the EU can speak English – the closest we have to a common world language – but half still cannot. To communicate across languages, we most often use a translation tool (e.g. Google Translate, a translation dictionary, or a multilingual person). This “Universal Translator” approach has proven to be more feasible, more useful, more successful, and (paradoxically) less prone to misunderstanding than the “Esperanto” approach of forcing everyone to learn the same language.

Electronic health records suffer from similar language barriers. Many utilize proprietary terminologies. For example, EHR #1 might encode the concept of “Serum Glucose Level” as “38478934B” while EHR #2 might encode it as “SerGlc.” EHRs use proprietary terminologies for two common reasons:

1. The EHR handles concepts not found in existing terminologies. For example, there may not be an existing terminology that can handle the concept of “not taking medications for two days due to a temporarily contaminated water supply.”
2. The proprietary terminology locks customers into the vendor. For example, to perform analytics on their own EHR data, a customer might be forced to purchase the vendor’s analytics or data export and translation modules.

Alas, the government has chosen to solve this problem using the “Esperanto” approach by choosing the terminologies EHRs must use when sharing data (e.g. LOINC for labs, RxNorm for medications, and SNOMED-CT for problems). Every shared EHR entry without an exact MU terminology match will require data transformation – either to a more general term (data loss) or to a more specific term (data distortion). SNOMED-CT is a great clinical terminology, but it is incomplete and imperfect.  What happens when a specialty system shares a data element not found in SNOMED-CT, such as “not taking medications for two days due to a temporarily contaminated water supply?” If the nearest SNOMED-CT match is “Noncompliance: medication regimen” then critical data has been lost. What if the mapping team (or algorithm) determines that the nearest map to SNOMED-CT is “Patient non-compliant – refused intervention/support?” Now the data has been distorted into something truly different than what was originally recorded. Some vendors may be less diligent about mappings. What stops a vendor from mapping "Stage 3 Klaskin Tumor" to the SNOMED-CT concept of "Cancer," or worse, "Disease?" Assessing mapping quality requires each customer site to compare the shared data against the source system – an expensive, manual process, especially if the source data is encoded in a secret terminology.

Do these mapping issues sound improbable? Even when experts try their best, published data shows that three professional coders select the same SNOMED-CT code only one-third of the time! There is similar data for LOINC. Enforced use of a standard terminology guarantees data loss and/or distortion as content is mapped back and forth between proprietary and standard terminologies –  like a horrible game of "telephone."  The more often data is passed from EHR to EHR, the worse this issue gets. Even when all EHRs "speak the same language" they will still be using terms that other EHRs don't understand. EHRs will not "just work together" once they all speak the same language any more than world peace would result if we all spoke Esperanto.

There is a better way – the “Universal Translator.” In 1986, the National Library of Medicine at the NIH created the UMLS Metathesaurus to enable interoperability between systems, including EHRs. The Metathesaurus identifies synonyms across vocabularies using “Concept Unique Identifiers” (CUIs). The same thing in two different vocabularies gets the same CUI. In this way, the Metathesaurus serves as a “Universal Translator” across more than 100 source vocabularies. The Metathesaurus even includes many parent-child relationships, so a slightly more general (parent) concept can often be chosen if an exact match does not exist between terminologies.

Healthcare interoperability would be better served and more successful if the government allowed and incentivized EHRs to share data using their proprietary terminologies and to publish those terminologies into the Metathesaurus. Each entry would include a human-readable description and a mapping to an existing CUI. Then computers could automatically determine that “38478934B” in EHR #1, “SerGlc” in EHR #2, and “35211-2” in LOINC refer to the same thing, because they are all mapped to the same CUI code. A person could use the human-readable descriptions to determine that all these codes refer to the serum glucose level (see Figure 1).

Figure 1

If a CUI for a proprietary code does not already exist, then the vendor does two things:

1. Creates a new CUI in the Metathesaurus (along with a human-readable description).
2. Adds a new “child” relationship connecting the new CUI to at least one existing parent code. This enables other EHRs to translate the new CUI into a concept they understand with the least amount of data loss. For example, the vendor might create a new CUI for “Stage 3 Klaskin Tumor” because there is no such concept today in SNOMED-CT. Then the vendor creates a “child” relationship to the existing parent CUI for “Klaskin Tumor” (see Figure 2).

Figure 2

These new entries cannot affect any other entry (“corrupt the database”) because every Metathesaurus item gets tagged with a vendor-specific code.

With this “Universal Translator” approach, an EHR can share data in its native language, completely eliminating data loss and distortion at the time of export. This might also be cheaper and easier for the sending EHR. If needed, the receiving EHR can use the Metathesaurus to translate the new data into a format it can understand. If properly designed, the receiving system can also store an unaltered copy of the original data and forward it to another EHR on request. This would end the miscommunication resulting from serial data transformations. The Metathesaurus makes all mappings visible to everyone. Anyone could notify a vendor of a bad mapping, and customers could put workarounds in place until the problematic mappings are corrected. Customers would also no longer be held hostage to a vendor through proprietary data mappings. The Metathesaurus would enable customers to use their own data in its native format. Vendors will be forced to compete on the value they provide rather than the patient data they can hold hostage.

We can achieve interoperability more effectively and efficiently by choosing the “Universal Translator” approach rather than Meaningful Use’s current “Esperanto” approach. We are at high risk of MU causing serious problems, and this simple change can resolve the issue. Our country has already made huge investments in the UMLS Metathesaurus – now it’s time to reap the benefits.