Common Terminology Services (CTS)
Accessing and utilizing terminology resources are a common and necessary function for many healthcare IT applications. Whether the application is grounded in decision support, charge capture or EHR integration, the ability to access terminology resources is a necessary function for enabling interoperability within and across disparate healthcare IT systems.
Common Terminology Services
The challenge of defining a predictable set of vocabulary APIs has been addressed by HL7s Common Terminology Services (CTS) standard. The CTS defines the minimum set of functions required for terminology interoperability within the scope of HL7’s messaging and vocabulary browsing requirements.
While the CTS has been implemented as the basis for several HL7 compliant vocabulary service constructs, how the CTS APIs are implemented is left up to the developer. Due to the variety of vocabulary models and vocabulary uses surrounding each separate vocabulary application, CTS APIs can be implemented in multiple ways, each making sense when considered within the context of each implementation domain. The most oft sighted example of is a charge capture application, requiring near real time access to a vocabulary resource, contrasted with a decision support application, requiring true real time access of the vocabulary resource.
The OHF goal of providing HL7 CTS standard APIs is laudable, but begs the question: What is the end goal? Since vocabulary models and vocabulary uses differ so dramatically, to what model or implementation should the CTS be implemented? How can OHF implement CTS in such a way that it be relevant to such a diverse audience?
One possible answer is employing a common terminology model to which the CTS APIs can be written against. A common terminology model is a meta-model to which many terminology models can be mapped. The common model maintains the semantics of each individual terminology resource mapped into it, while providing a common denominator of understanding for all terminology users. The CTS is then implemented to ‘talk to’ the common model. This is in contrast to implementing CTS for each individual vocabulary application. Thus, the CTS APIs return the required vocabulary content by accessing the common model, providing the availability of multiple vocabularies by a consistent API call.
If all of your terminology content is stored in a common format, then tool writing becomes much easier as you no longer need to write different tools for each terminology. If you have standardized API's for accessing the content, then your applications that use the content no longer have to have custom code for each terminology.
One such model is the Lexical Grid model developed at the Mayo Clinic. LexGrid is an Open Source vocabulary model capable of maintaining the semantics of multiple vocabulary resources in one meta-model. The LexGrid Model is a proposal for standard storage format for terminologies and ontologies. The LexGrid Model defines how terminologies should be formatted and represented programmatically. It also defines several different server storage mechanisms and a XML format.
The LexGrid model has already been selected by HL7 as the vocabulary model in which the HL7 vocabulary will be represented.
Combining OHF, CTS and LexGrid
The OHF goal of providing HL7 CTS standard APIs can be achieved by using both HL7 CTS APIs and LexGrid. By providing HL7 CTS APIs that query against the LexGrid model, along with examples and instructions on how to semantically represent vocabularies within LexGrid, a common set of HL7 standard CTS APIs can be provided that will communicate with LexGrid, and thus the vocabulary resources represented within LexGrid. This allows a single set of APIs to be developed that can work with multiple vocabulary resources for multiple purposes. Developers will no longer need to develop custom terminology resource implementations for custom applications, but can map their required terminology to LexGrid, and make use of already implemented HL7 standard APIs to access the terminology content.
The OHF goal of providing HL7 CTS standard APIs is a necessary but not sufficient part of the OHF Framework Terminology solution. To help achieve terminology interoperability, a common terminology service must be developed. Implementing already standard terminology service APIs against a common terminology model will go a long way in providing standard terminology interoperability within the healthcare arena.