Medical Terminologies

Why are standards for various types of Healthcare IT message structures not enough for interoperability between providers? Unless one has spent a lot of time considering the intricate problems of Healthcare IT (HIT) interoperability, the problems of the exchange of clinical messages are not easily perceived. It is not just the message formats that need to be defined, it is the actual contents of the data fields which must be interpreted as well. Think about the way each provider, (be it a doctor's office or a hospital network), stores the data in their EHR system. IT systems traditionally have stored their data by storing codes which represent a set of values. Different HIT systems evolved to code their values different ways. One provider might store a Blood type of O+ as a numeric value of 1935. Another system might store the text "O+". If one looks at the bits and bytes in the actual data file, these are not the same. If one sends data alone, the meaning of the number 1935 is not easily understood by a person. One has to know the sending database's terminologies to know what 1935 meant to the sender. That requires mapping one set of codes to another so they can be translated. Once one knows that "O+" translates to 1935 and vice versa, progress is made. However, as mapping all possible clinical values takes years to finish and requires several teams of experts, it gets too expensive. Hence, in comes the need for standard international terminologies.

When exchanging data, one has to map your data elements to the data elements of the destination system. When you are sending data outside your organization or network. There is another problem inherent in mappings. That is one of the granularity of the concepts. If two systems have different granularities, that means they have established different levels of detail for similar concepts and as a consequence of that decision, the concepts will not map directly one to another. In a simple sense, one is more detailed that other.

To eliminate the need to map data, if systems use the same terminologies, they can exchange data that is understandable. Then when you send me a code 10928, I already know what that means. We both have the same standardized terminologies.

Medical Terminologies and Service Oriented Architecture (SOA)

When one uses a terminology, you can create a Service Oriented Architecture terminology service to access it. Then everyone can use a common service to query the terminology. Then you have to learn how to use the service like a method or function call. Medical Terminology differs from country to country. You can also use a terminology service to ask "How do you say Rhinitis in German?" Add to different concepts for the same word, different languages for the same word and one avoids the confusion level of a veritable tower of Babel. SNOMED CT handles these different foreign languages.

Medical Concepts: Making Sense of Apples and Oranges

We all know the common saying about comparing apples to oranges. To keep our concepts straight with medical terminology, we must compare apples to apples and oranges to oranges. But in Healthcare IT, we have not just two fruits to keep straight, but a huge variety of data fields and EHR fruit salads concocted by an array of EHR systems. We want healthcare providers and government entities to talk to each other, private hospitals, clinics, and private practitioners. We as patients want to talk to our doctor's offices, testing labs, pharmacies, and insurance companies. The contents of the EHRs and test results must be able to be sent, understood, and processed with the meanings intact. But the human body is complex and is subject to many diseases which are diagnosed & treated. Samples are tested, and drugs are prescribed. Many hundreds of thousands of concepts are involved here.

What is a concept? If you were to tell a web browser you want to search for the keyword orange, what kind of object should it look for? Do you want the color orange or do you want the fruit called orange? There are multiple concepts of the word 'orange'. Getting to the intended concept of 'orange' is achieving semantic understanding of the data. We have to qualify that this person wants orange as in paint and that person wants to eat an orange as in fruit. Now we know the underlying concept for the word. Ontologies are used to create hierarchies so we can pinpoint where in the hierarchy a particular concept falls.

"Medical concept representation is not an end in itself but is desirable for the capabilities it provides. There are at least three activities that would be made possible by a consistent representation of medical concepts:
1) the real-time exchange of medical data;
2) the exchange of decision-support programs including alerts, protocols, care pathways, and care plans; and
3) the pooling of data for outcomes research, quality assurance programs, and clinical research.
One proposed model of medical concept representation, which we adopt here,5 breaks the representation model into three components: a medical vocabulary or lexicon, a semantic data model (an information model), and a knowledge base. We discuss only the first two of these components in the following paragraphs.

The first component, a structured medical vocabulary, is an organized set of terms or words with associated codes. Coded medical vocabularies are one of the foremost issues in the field of medical informatics. Indeed, Dr. Smith noted that a unified controlled medical vocabulary was one of the grand challenges of medical informatics. There is a large and growing set of publications related to the development and use of structured medical vocabularies.

The second component of medical concept representation, a semantic data model (SDM), is a description (template or data structure) of how vocabulary items can be combined to make a valid representation of medical information. Semantic data models have also generated a large number of publications. Often unrecognized as SDMs are the health care data exchange standards, particularly CEN TC251/PT-00822 and CEN TC251/PT-02223 of Technical Committee 251 (Health Informatics) of the European Committee for Standardization; HL7 (Health Level 7); the DICOM standards; and specifications E123829 and E139430 of the American Society for Testing and Materials (ASTM). These standards describe the interchange format and syntax for messages that can be exchanged between medical computing systems."

Let's take the need for semantic understanding to a document which has text about an encounter with a patient. It's a whole lot harder isn't it? A doctor has written the word "cold" in his notes about a patient. The word "cold" is called the surface form of the term. The surface form is what we use in every day speech. But a surface form can be linked to multiple concepts. If one uses just the word cold without the proper context, is the patient cold temperature-wise (97 degrees F) or do they have a "cold" meaning rhinitis? What is the intended meaning of cold? How do we transmit data so it has the proper has meaning? Standardized medical terminologies solve this problem. For instance, a standard called SNOMED Clinical Terminology assigns concepts to these words to provide them with meaning and context. When we send the word cold, we will know if we mean cold as in "Rhinitis" or "I feel cold and I have a fever". In this extensive hierarchical framework of concepts and synonyms, one can find a resting place for unanchored parlance. An organization called IHTSDO owns and administers the terminology contained in SNOMED CT. SNOMED CT is one of the largest terminologies today. Doctors can use these concepts, not just the surface form, to arrive at a specific meaning. Drop down lists will help them find and enter the best phrases.

The U.S. has a national license to use SNOMED. Before SNOMED was available, healthcare organizations developed their own reference tables of concepts and codes, which cost vendors a lot of money to do. Now we have many healthcare organizations with their own reference codes. So, when we send data from one organization to another, we are dealing with too many different local reference terminology systems.

For example, one entity might send me the value for a piece of data called sex which contains the number 22. What does this mean? What happened to just "M" and "F" for male and female? Well, the FBI has 23 different codes for sex, as their values include “male”, “female”, "male posing as female", "female posing as male", etc. What I expected to receive was the concept of medical gender. Really what the FBI needs is a "Sexual Appearance" concept apart from just one basic concept of medical gender. Their concepts rightly come from the job function they perform: it is their job to identify people. Healthcare providers need to treat people. Hospitals use a concept called administrative gender. What is going to sort out all these concepts? The SNOMED CT is a framework in which these concepts are sorted out in a vast carefully curated hierarchical database of 900,000 entries. In here a map is built which points individual words to their concepts properly. SNOMED CT is updated periodically by people who are professional medical Terminologists.

The International Classification of Diseases, ICD, is another large terminology. When one uses a terminology, you create a Service Oriented Architecture terminology service to access it. Then everyone can use a common service to query the terminology. Then you have to find out about and learn how to use the service like a subroutine.