TSC Product List CTS

Product Brief - CTS - Common Terminology Services

back to 2009_TSC_Product_Visibility

Type

Normative, ANSI Standard

Releases

• ANSI/HL7 V3 CTS, V1-2005, currently under ISO ballot IS #27951
• in-process: CTS2, see Project 324

Summary

The HL7 Common Terminology Services (HL7 CTS) defines an Application Programming Interface (API) that can be used by HL7 Version 3 software when accessing terminological content.

Description

The Common Terminology Services (CTS) specification was developed as an alternative to a common data structure. Instead of specifying what an external terminology must look like, HL7 has chosen to identify the common functional characteristics that an external terminology must be able to provide. As an example, an HL7 compliant terminology service will need to be able to determine whether a given concept code is valid within the particular resource. Instead of describing a table keyed by the resource identifier and concept code, the CTS specification describes an Application Programming Interface (API) call that takes a resource identifier and concept code as input and returns a true/false value. Each terminology developer is free to implement this API call in whatever way is most appropriate for them.

Before proceeding, we need to first state some things that the CTS specification is not designed to do.

• The current version of CTS is not intended to be a complete terminology service. The scope of CTS is restricted to the functionality needed to design, implement and deploy an HL7 Version 3 compliant software package. In much the same spirit as the XML/SGML relationship, the HL7 CTS is meant to represent a proper subset of functionality that may be provided by more sophisticated APIs such as that represented by the OMG TQS specification.
• CTS is not intended to be a general purpose query language. It is intended to specify only the specific services needed in the HL7 implementation.
• CTS does not specify how the service is to be implemented. It is intentionally silent when it comes to service advertising and discovery, establishing and maintaining connections, and the delivery and routing of messages. It is presumed that a CTS implementation will use the underlying architecture that is most appropriate for the given implementation circumstances.

The Health Level Seven (HL7) Version 3 standards are based on a Reference Information Model (RIM) which is flexible and general in structure. Representation of information within this model is dependent on the availability of terminological resources which can be used to populate the properties of the model with appropriate semantic content. Whenever possible, the HL7 Version 3 Standard references existing terminological resources instead of attempting to create a new resource within the standard itself.

These external terminological resources can vary considerably in both content and structure. The HL7 standard needs to be able to identify a minimum set of characteristics that any terminological resource must possess if it is to be used in a HL7 messaging environment. One approach to this task would be to specify a common data structure which all terminological resources would have to fit. This approach, however, is not without drawbacks. First, a common data structure would have to represent a ‘least common denominator’, which could mask more advanced content and functional characteristics that might be particular to a specific terminology. Another drawback is that this approach puts much of the responsibility for maintaining and updating the content on the HL7 standards body rather than the individual terminology developers.

The Common Terminology Services (CTS) specification was developed as an alternative to a common data structure. Instead of specifying what an external terminology must look like, HL7 has chosen to identify the common functional characteristics that an external terminology must be able to provide. As an example, an HL7 compliant terminology service will need to be able to determine whether a given concept code is valid within the particular resource. Instead of describing a table keyed by the resource identifier and concept code, the CTS specification describes an Application Programming Interface (API) call that takes a resource identifier and concept code as input and returns a true/false value. Each terminology developer is free to implement this API call in whatever way is most appropriate for them.

Resources

Work Groups

• Vocabulary WG