CTS2/doc/Business Case
CTS2 aims to support three key objectives:
- The ability to communicate unambiguously with business partners, including both the use of commonly understood terminology services and the more widespread use of commonly understood terms in clinical communications that such services would encourage
- The separation of capabilities to support business agility, including the creation of new functionality that employs existing services as well as the insulation of both services and clients from changes in their respective implementations
- The ability to reduce investment, whether by internal reuse of software components, the outsourcing of services, or the selection of standards-compliant vendors in order to reduce interface development costs
In support of these objectives, CTS2 adopts a modular design. An implementer need not implement all of the services in the specification in order to be compliant. One may implement a subset of services, and subsets of functions within those services. This design is intended to support a “linear value proposition”—the idea that simple requirements should be simple to implement, and that the complexity of the implementation increases in direct proportion with the complexity of the service requirements. You don’t have to implement (or even understand) all of CTS2 functionality in order to use it to meet your needs.
A second key design feature extends that modularity to the organizational dimension: services can be federated. An implementer may implement some services, but choose to syndicate other services provided by other implementers. This lets the most knowledgeable organizations provide services in their areas of expertise without having to attempt to duplicate work done in other domains by other expert organizations. Note that this feature makes it possible for an organization to maintain responsibility for some of its own terminology services while retaining the ability to outsource others. Figure 4 illustrates one scenario where a business client may use multiple service providers—and, if necessary, switch among them with minimal effort.
Finally, for service clients, the burden of implementation is minimized by the adoption of a RESTful architecture. The benefit side of the business case equation does not have to be very heavy because the cost of implementation is minimal. A RESTful service call can be composed in a single line, with no addressing or messaging overhead beyond a simple URI, resulting in an XML response legible to a wide variety of tools.
These design decisions support three key scenarios:
- You create or manage terminologies. You’ll build or buy a tool that provides terminology creation and maintenance functionality, but you’ll want to expose its capabilities in a standard way to make it useful to as broad a population as possible.
- You develop or integrate applications that use terminologies. You need services that support your application’s terminology needs; asking for them in a standard way will diversify your buy options and maximize the value of your build and buy options.
- You provide terminology products. You can appeal to customers who want the above benefits by providing them in a standard way.
Most potential users face a combination of these scenarios. If you manage a clinical facility, you manage applications that use terminologies, but you also maintain local code tables (locations, products) and subsets of standard terminologies (formularies, protocols). If you provide terminology services, it’s possible that federation will allow you to offer a more complete line of content. And anyone responsible for software development may benefit from using standards in internally developed services.
Managing terminologies
Whatever software product you use as a terminology repository, standard interfaces will allow you to distribute the work without insisting that everyone use the same tool. Authoring applications tend to be more specialized, so a service architecture might be further down the priority list for that case, but maintenance may require support from a wide variety of stakeholders on a much more well-defined set of tasks. Some maintenance, in fact, may not be necessary, if updates to the assets to be maintained could be acquired via federated service calls.
Developing client applications
Client applications benefit from services because they decouple the application from the provider. An application can request the service from any compliant provider using exactly the same call: only the address changes. This eliminates at least one mechanism of vendor lock-in, and it gives you the flexibility to evolve your application architecture at an appropriate rate of investment.
In the event a standard service does not meet all of your requirements, it can be wrapped in a richer custom service. The outer service can continue to provide differentiation, and while it isn’t standard, at least one cleanly separable component of it is.
Developing service applications
Standard interfaces increase the value of any service. This is most obvious when your service must support a variety of clients: a routine to map clinical diagnoses into billable codes, for example, will be valuable for every specialty in the facility.
Though even one-off requirements have a way of growing over time, building for the future is expensive and difficult to justify. This is why the CTS2 specification is modular: you standardize the services you need to standardize when you need to. If the legacy module for drug checks is working, there’s no need to standardize it until your projected cost of support begins to outweigh the cost of conversion.
Stability
CTS2 is a standard. This means that your business partners, should they choose to use a common language for your interfaces, are more likely to choose it. But it also means that it’s stable. There is a change control process, so if changes are needed, they can be made, but if made, they will apply to a separate version of the standard, and a key requirement for revisions is that they be backward compatible with previous versions. Your decisions of whether and when to adopt the new standard will be completely under your control. For more information about the OMG revision and enhancement processes, please refer to the OMG Policies and Procedures. [no link available]
| 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 |
