Common Terminology Services

From Clinfowiki
Jump to: navigation, search


With the wide number of terminologies available for use in EHR systems, a need for a standard methodology for accessing and maintaining the content of these terminologies emerged. Clinical, billing, and supporting terminologies such as SNOMED-CT, ICD9/10, CPT, HCPCS, LOINC, RxNorm, UMLS, and others vary widely in their schemata. The Common Terminology Services (CTS) have been developed to provide a standardized set of computer services for querying a terminology through standardized, technology-independent interfaces to help enable interoperability. These services comprise the CTS application programming interface (API) for providing a common terminology server, and calls to access such a server. CTS does not dictate how a service should be programmed; rather, it provides a defined interface for how the technology should communicate with consuming programs.

One aim of CTS is to provide a simple interface to program to, rather than trying to interface with the HL7 Reference Information Model (RIM). As with other specifications, writing to the CTS allows one to "swap out" the terminology server and introduce in a new one without recoding any of the consuming application or system.

CTS Version 1

The first version of Common Terminology Services, CTS1, was published through HL7 and ISO. The latest version of CTS1, Version 1.2 was published in November 2004.[1]. The National Cancer Institute has published a reference implementation of CTS1. This specification provides services at two layers to access terminologies: the Message API at the upper layer and the Vocabulary API at the lower layer. The messaging layer provides communication interface with the higher order objects in a vocabulary, such as value sets, domains, and coded attributes, and interfaces with the terminology server's messaging technology. The vocabulary API layer communicates between the messaging layer and the base terminology repository, and deals with the more granular elements of a terminology, such as its constituent concepts, descriptions, relationships, and attributes.

CTS1 is intended only for accessing a vocabulary, and explicitly excludes any authoring or maintenance functionality. As such, it is not intended to be an interface for terminology management. CTS2 optionally addresses this expanded functionality.


CTS1 is modular, and broken up into the following module groupings:

  1. Messaging and Vocabulary API
  2. Runtime and Browsing Functions
  3. Dividend Requirements Profile
  4. Translation
  5. Individual Specification Components

Data Types

CTS also defines data types used by different modules in the API. This allows for the creation of matching data types in the implementers system for ease of integration. Examples of such data types are an ISO Object Identifier (OID), Concept Code (identifier in the source terminology), and ConceptStatusCode (indication of the status within the terminology of a concept, such as "Active", "Retired", etc.).

CTS Version 2 (CTS2)

CTS2 has been in development for several years, and was developed to expand the breadth of terminology services and to address criticisms aimed at CTS1. CTS2 is under the auspices of the Object Management Group (OMG), rather than HL7. Early in its proposal, it was stated that the CTS2 API needs to support the needs of an Enterprise Healthcare Record.

The final CTS2 specification, after a period of proposal, editing, and modifications, was submitted to the OMG on May 23, 2011[2]. CTS2 forms the backbone of the National Center for Biomedical Ontology (NCBO) Bioportal system, and is in use within the Mayo Clinic's open-source LexEVS terminology server.

Modular Implementation

Most of CTS1 functionality is subsumed in the new CTS2 thematic area of "Search/Query." Three other areas have been added to the list of services. An implementing system does not need to exhaustively implement all of the areas and all of an area's complete service list in order to be CTS2 compliant. This modular approach is done so that, in it provides a "linear value proposition"[3] where simple implementations are developed easily and inexpensively, and only when advanced functionality is required by the consuming systems use-cases is it developed. The proposal also notes that the modular approach facilitates a federated system development[4]. By this definition, a system that already implements the existing CTS1 1.2 specification is minimally CTS2 compliant.

CTS2 Thematic Areas

The four major thematic areas that form the modules are:

  1. Administration: managing the terminologies. These functions including loading vocabularies, input and output, and activation and retiring.
  2. Search / Query: retrieving terminology elements through browsing and searching mechanisms.
  3. Authoring / Maintenance: minimal operational creation and editing of terminology elements. Limiting access and granular control needs to be provided by the implementing system.
  4. Associations: mapping services, creating interconnections (crosswalks) between vocabularies.


CTS has been implemented by:

  1. Intel SOA Expressway for Healthcare [5]
  2. Mayo Clinic LexEVS [6]
  3. IHTSDO reportedly will develop a SNOMED-CT CTS2 implementation guide.[7]

External Links

  • [8] Mayo Clinic's CTS2 OMG submission page.
  • [9] CTS2 NCI specification page.
  • [10] National Center for Biomedical Ontology Bioportal

External Informatics Organizations Links

  • [11] Object Management Group (OMG)
  • [12] Health Level Seven International (HL7)
  • [13] National Cancer Institute (NCI)
  • [14] National Center for Biomedical Ontology (NCBO)
  • [15] International Health Terminology Standards Development Organisation (IHTSDO)

Submitted by Lawrence Gerstley