CTS2/doc/Purpose

Why use a terminology service?

Terminology services are useful for all of the reasons you’d use a service for any function your application requires:

• Standard, publicly defined resources support interoperability with partners (customers, providers, and other partners)
• Separation of resources supports business agility because sufficiently distinct resources can be modified independently
• Using existing capabilities reduces development cost (e.g., implementers in Figure 1 reduce the number of interfaces to develop from four to one by using a standard)

Error creating thumbnail: Unable to save thumbnail to destination

Figure 1: Standards support interoperability at reduced cost

Not all development tasks can or should be solved with services: there is some overhead associated with establishing a service infrastructure. But while terminology management may be simple in some domains, in many domains it can become surprisingly complex and require a great deal of effort. This is especially true in the clinical domain: clinical terminologies are complex enough to merit robust and consistent capabilities for support and use.

CTS2 is designed to allow clinical data managers and application development teams to separate the effort of deploying and maintaining terminology assets from their business-—whether in order to outsource it, enable internal reuse, better communicate with partners, or just layer the application architecture to protect components from change.

For example, imagine you are responsible for an application that uses country codes. You can hunt down a set of codes (there are several), and you may find the information necessary to choose the correct one for your purpose. Part of that information will be the change control schedule: where do you go for updates, and how often do you need to do so? How does your application expect to see deprecated values? Other information may address translation and mapping issues: does your application need the 2-character or the 3-character ISO codes? Perhaps you have a partner that uses FIPS codes, and you need to translate. For a more complex example, your value set may be defined by a rule rather than an explicit list; e.g., “all of the SNOMED CT concepts that are infections and have associated devices.” Now even your simple consumption use case is complex: it can’t just look up a code because the allowed values are subject to rules: you have to infer them. Then, when SNOMED CT is updated, the value set changes, and your application will need to know that—even if the subject matter expert in charge of the value set isn’t around to let you know.

You may need to build functionality to manage discovery, loading, updates, translations, deprecation, inference, and validation, and you can do this for the dozens or hundreds of lists you need—each with its own formats, labels, release schedules, rules—and, possibly, translation maps. For each of these tasks, CTS2 has already performed the analysis and designed the interface. If you use these defined interface definitions, you’ll be able to communicate effectively with others who have implemented the standard, internally and externally.

Why use the CTS2 terminology service?

Services to be used exclusively inside an organization can adopt any design that is convenient, though ensuring the various teams use a consistent design can be a challenge. But outside of an organization, services are valuable only if business partners understand them. Communication standards (like fax machines) benefit from the “network effect,” where the more widely adopted a tool is, the more valuable it becomes.

CTS2 is a balloted standard, with requirements developed by Health Level 7 (HL7), the leading health informatics standards development organization, and design by the Object Management Group (OMG), a leading computer standards consortium.

CTS2 is modular. You can implement exactly as much of it as you have a business case to justify, and you can postpone, delegate, or ignore the rest. Prior to the publication of CTS2, Integrating the Healthcare Enterprise (IHE) created a “profile” called Sharing Value Sets (SVS) that implements two terminology services (value set retrieval and value set query). Several organizations have implemented this profile, finding it appealing because of its small size. Unfortunately, the implementation is different from CTS2.

However, because CTS2 is modular, it’s quite possible to build out from these high-demand services to more specialized ones, and to approach the decision of whether and when to migrate services already built in SVS only when it makes sense to do so. This can be done whether these initial services were built with SVS or CTS2. This flexibility is a central part of CTS2’s modular design, supporting a “linear value proposition” (as suggested by Charlie Mead); i.e., you don’t need to implement the entire standard, but just what you need and have resources for. If you later decide you need more functionality, you can increase your investment at the level and rate you choose.

CTS2 is lightweight. The architecture leverages RESTful design to make client method calls simpler and to make resources discoverable.

Speaking of ease of implementation, you may also wonder if you could simply use an existing product to manage and serve your terminology needs. You absolutely can: the software you choose to build or buy is a separate question from that of what the interfaces should look like. The standard only addresses how software components communicate, so it is quite feasible to choose products that support CTS2, or to wrap APIs from homegrown applications in CTS2-compliant interfaces. This can be done incrementally, on an as-needed basis.

However, software vendors implement features (like CTS2 interfaces) when their customers require them, so do be sure to let your vendor know you're interested in products that support interoperability with standards, including CTS2.

---

Navigation – Common Terminology Services (CTS2)

Home
About CTS2
Purpose
CTS2 History
Business Case
How it works
Federation
Functionality
Implementing CTS2
Architecture
Development
Resources
Purpose
FAQ
Business Case
Glossary of Terms
Specification
REST
SOAP
HL7 SFM
Development
CTS2 Development Framework
Implementations
Github Page
Community
Who is Using CTS2?
Get Help
Links