CTS and Composition
Q: One questing that came up last week at the HL7-OMG Services meeting in SLC was the capability for CTS to resolve composition. Does the current CTS specification outline the capability of resolving post-coordinated compositional expressions against a pre-coordinated term?
What I'm getting at specifically is say we have a compositional expression, c1 generated by some software. c1 was created by a software system that decided that 'pain' is a finding/condition/what have you, that is applied to or exists at the anatomical location 'arm'.
c1:
Pain (code_for_pain)
| |--hasAnotomicalLocation --> arm (code_for_arm)
Now, there happens to exist a code in the same terminology for 'arm pain', lets call it p1. Does CTS allow the capability to resolve compositional expression 'c1' to the pre-coordinated term p1 within the same terminology.
A: The CTS Messaging API translateCode is specifically designed to handle this problem. Referencing: http://informatics.mayo.edu/LexGrid/downloads/CTS/specification/ctsSpec/cts.htm#CTSTransCodedAtt
translateCode takes a HL7 CD as an input and returns the resulting "translation" in the required CD format. The "applicationContext_code" is intended to provide the "Realm" or "context" for the target of the translation. translateCode doesn't provide an explicit mechanism to say "give me the me the expanded translation" or "give me the most compact translation", although a an implementer might be able to overload the context to accomplish this. It should be noted, however, the the messaging API has been intentionally limited to the immediate requirements of the HL7 messaging use cases and, as a result, is not designed to translation browsing and the like.
The OMG Lexicon Query Services specification (http://www.omg.org/cgi-bin/doc?formal/2000-06-31) actually specified three functions:
Minimal_common_supertype - Determines the “difference” between the two concept
expressions and returns it in the form of a third concept expression.
Maximal_common_subtype - Returns the concept expression which is the “closest” valid supertype of the supplied list of concepts expressions. The application is notified if there is no valid minimal common supertype short of the universal type.
Expression_difference - Returns the concept expression which is the “closest” valid subtype of the supplied list of concepts expressions. The application is notified if there is no valid maximal common subtype short of the absurd type.
It should be noted that both the CTS and LQS specifications are interface specifications, which means that they define the contract between the client and the service, but they don't tell the service provider how it is to be implemented.
Early drafts of the CTS specification also included similar functionality. The committee decided to remove this functionality from the first draft in favor of simplification. This gives me an opportunity, however to stress a point about the CTS specification that may be misunderstood. The specification is not designed to be limiting, in the sense of if it isn't in the CTS spec, you can't to it. Its purpose is to standardize a core set of common functionality. If you've got to look up the preferred English designation for a concept code, you might as well do it the same way that everyone else does. If, however, you want to do something like compute a maximal common subtype, there is nothing that prevents you from extending the specification to support what is needed.
The one thing that we would request, however, is that these sort of extensions be fed back to the Vocab TC and the CTS2 group so that they can be standardized at a future date.
