CTS 2 - Executive Summary

The ability to share, query and maintain value sets (or other terminology artifacts) using an accepted industry standard service interface will allow standard terminology content to be readily disseminated and validated. The need for such an interface becomes more critical as organizations begin to undertake the enhancement and maintenance of terminologies to support alternate language translations, jurisdictional extensions to standard terminologies, or maintenance and development of local terminologies. Currently, these organizations employ a variety of tools and technologies to manage terminologies and value sets.

Common Terminology Services – Release 2 (CTS 2) provides a consensus API that can be integrated over top of existing terminology systems, allowing disparate terminology systems to interoperate via CTS 2 interfaces while maintaining and fulfilling their local, often specific, terminology functional requirements.

With formal support from 14 separate organizations – including (but certainly not limited to) 3M Health Information Systems, Intermountain Healthcare, IHTSDO, Mayo Clinic, NCI Enterprise Vocabulary Services, and the University of Oxford, Department of Computer science – CTS 2 encompasses the best practices and ideas of the terminology management and user community.

With this in mind tools such as Apelon’s open source DTS 4.0 will include support for CTS 2, allowing it to interoperate with other CTS 2 services such as NCBO, while continuing to include DTS specific functionality that is not appropriate to be included in an international standard terminology service.

CTS 2 was developed collaboratively under the Health Level 7 (HL7) and the Object Management Group (OMG) Healthcare Services Specification Project (HSSP). The HSSP process integrates these distinct standards communities allowing them to operate as a single project, while at the same time leveraging each community to its strengths. For CTS 2, this means that HL7 can focus on specifying the requirements for a robust terminology service with the understanding that the technical specification of those requirements will be completed in a later phase of the project. The OMG community is then able to take the vetted requirements developed in the HL7 community and request that the vendor community develop a technical specification meeting those requirements based on real world business needs.