Human to Ontology Translation

Ontologies are formal computer scientific representations of knowledge. An ontology models the hierarchical (parent/child) relationships between concepts, and the cross-linking relationships between these concepts. For example, ontologies such as the FDA drugs database, MeSH, the NCI Thesaurus, and SNOMED can tell you that 'bupropion' is an aminoketone phenylethylamine derivative, it is an antidepressant, and it is an FDA approved drug. Therefore, once a computer receives some input and identifies the 'bupropion' concept in an ontology, there are many useful functions it can perform and inferences that it can make.
However, ontology designers (humans) are generally NOT attempting to help the computer interpret the wild and wolly free-text input that it receives from the real world. Even when a computer is talking to another computer, they may be using different encoding schemes (different ontologies). When talking to a human, the situation is even more complex because no one has even been able to get a human to adhere to a single coding scheme; we prefer to use language the way we have been using it all our lives.
So people designing and building medical information systems are left with an important problem. Our 'semantic fingerprinting' engine has been designed and developed to solve exactly this problem : identifying ontological concepts in real-world free-text human input. Other posts (Introducing Document DNA, Builts-in Synonyms) have discussed how this technology works. I'd like to take the remainder of this post to describe a couple of practical applications.
CCR Merging
The Continuity of Care Record is a specification developed for exchanging patient health information among providers. The idea is that as a patient moves from provider to provider, their CCR moves seamlessly with them. Each provider adds new information about new diagnoses, tests, drugs prescribed, elements of family history, etc. The meat of a CCR is these informational records. Each record is composed of a 'Text' name (the human readable name), and a 'Code', which identifies the record in the coding scheme (the ontology). You can see immediately what the problem is going to be with exchanging CCRs; there are many different coding schemes, with varying levels of completeness in the areas of drugs, diseases, procedures, signs and symptoms, etc. Suppose care provider A sends a CCR to B, who sends it to C, who sends it back to A. Suppose that B and C use different coding schemes than A for at least some of the information. How is A going to be able to tell which records in the CCR have changed? The Text and Codes may have changed, yet represent the same information.
The semantic fingerprint provides a robust way to compare the Text of two fields, and determine whether they are the same concept, unrelated concepts, or closely related concepts. In the first case, even though the Codes may be different, we can be sure that both CCRs are talking about the same thing, and choose whichever code we prefer. In the second case, we can be sure that the records are different. The semantic fingerprint can even help with the third case. Suppose a record goes out with the diagnosis of 'multiple sclerosis' and comes back with 'neuromyelitis optica'. In some ontologies, neuromyelitis optica is a child of multiple sclerosis. In other ontologies, it is a related disorder but not a child. We can prompt a physician to examine other information in the CCR, such as notes, to help disambiguate.
In any case, by changing the representation of the CCR from Text and Code fields to the semantic fingerprint, we can quickly identify the unchanged records and the new records, and we have a powerful tool to help disambiguate the records whose status is unclear.
Code Conversion
When providers standardize on different ontologies, a difficult translation problem arises. While each one of them has chosen an ontology to use internally, in order to communicate with each other they must be able to translate into other coding schemes.
Rather than developing a translator for each foreign coding scheme and trying to maintain it in the face of ambiguity and constant change, a provider can first translate to a semantic fingerprint (or use the semantic fingerprint as their native representation). Each bit in a semantic fingerprint can provide the code or codes for any of the source ontologies that comprise the semantic fingerprint model. Again, this capability is enabled by relying on the rigorous and extensive vocabulary of medicine to unify and segregate concepts from multiple ontologies based on their synonyms.
If the destination ontology does not contain a concept (SNOMED has the 'remittent-progressive multiple sclerosis' concept but MeSH does not; the FDA drug database contains 'AMBRISENTAN' but SNOMED does not), the system can either choose a more general concept that is available in the destination ontology ('multiple sclerosis', 'endothelin receptor antagonist'), or provide the concept in the source coding scheme, or take some alternative hybrid approach.
Concept Versioning
The body of medical knowledge is being constantly updated and revised. Guidelines are changed, new drug interactions and side effects are discovered, new drugs are approved and new indications are added to existing drugs. For this reason, as well as error correction and re-organization of existing concepts, medical ontologies are constantly changing; most are updated at least monthly, often weekly. Therefore any system which is ontology-based must be constantly revised and updated.
Each semantic fingerprint is based on a specific version. The changes between versions are available through the semantic fingerprint API, and each new version consists of a curated, consistent merging of the source ontologies. So rather than having to track and manage many ontology versions, a semantic fingerprint-based system simply stores the model version along with each fingerprinted record. When the model changes, the fingerprinted records which may have been affected can be incrementally updated.