Difference between revisions of "Product CTS"
| Line 18: | Line 18: | ||
===Summary=== | ===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. | + | The HL7 Common Terminology Services (HL7 CTS) defines an Application Programming Interface (API)service interface that can be used by HL7 Version 3 software when accessing terminological content. |
| + | |||
===Description=== | ===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. | 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. | 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. | *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 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. | *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. | 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. | ||
| Line 31: | Line 35: | ||
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. | 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. | ||
| + | |||
| + | |||
===Business Case (Intended Use, Customers)=== | ===Business Case (Intended Use, Customers)=== | ||
| + | * Terminology service users and providers | ||
* | * | ||
| − | + | ||
===Benefits=== | ===Benefits=== | ||
| − | * | + | * Benefits for designers and implementation developers |
| − | * | + | ** Software can be written once and won’t need to understand each terminology vendor’s database and/or API |
| + | ** Hides much of the complexity inherent in modern terminology systems. | ||
| + | |||
| + | * Benefits for terminology software developers | ||
| + | ** Basic functional requirements for terminology services are clearly specified | ||
| + | ** Implementation can be based on existing databases and software | ||
| + | ** A common entry point to terminology content | ||
| + | |||
| + | |||
===Implementations/ Case Studies (Actual Users)=== | ===Implementations/ Case Studies (Actual Users)=== | ||
| − | * | + | * Apelon, Inc. - Wrapper over DTS API |
| − | * | + | * Intel |
| + | * Mayo Clinic - Wrapper over LexEVS | ||
| + | |||
===Resources=== | ===Resources=== | ||
| + | |||
====Work Groups==== | ====Work Groups==== | ||
* [http://wiki.hl7.org/index.php?title=Vocabulary Vocabulary] WG | * [http://wiki.hl7.org/index.php?title=Vocabulary Vocabulary] WG | ||
| + | |||
====Education==== | ====Education==== | ||
* See more at http://www.hl7.org/implement/training.cfm | * See more at http://www.hl7.org/implement/training.cfm | ||
| + | * HL7 Vocabulary WG Advanced Terminology Tutorials | ||
| + | |||
=====Certification Available===== | =====Certification Available===== | ||
*none | *none | ||
====Presentations==== | ====Presentations==== | ||
| − | * | + | * HL7 Vocabulary WG Advanced Terminology Tutorials |
| + | |||
====Relationship to/ Dependencies on, other standards==== | ====Relationship to/ Dependencies on, other standards==== | ||
| − | * | + | * See CTS specification for details |
| + | |||
====Links to current projects in development==== | ====Links to current projects in development==== | ||
* ANSI/HL7 V3 CTS, V1-2005, currently under ISO ballot IS #27951 | * ANSI/HL7 V3 CTS, V1-2005, currently under ISO ballot IS #27951 | ||
| − | * | + | * Common Terminology Services Release 2 [http://www.hl7.org/dstucomments/showdetail.cfm?dstuid=50] |
Revision as of 20:17, 27 October 2009
Contents
Product Brief - CTS - Common Terminology Services
back to Main_Page CTS - Common Terminology Services)
Topics
Standard Category
Health Information Modeling Standards: V3 Foundation Vocabulary Domains
Integration Paradigm
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)service interface 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.
Business Case (Intended Use, Customers)
- Terminology service users and providers
Benefits
- Benefits for designers and implementation developers
- Software can be written once and won’t need to understand each terminology vendor’s database and/or API
- Hides much of the complexity inherent in modern terminology systems.
- Benefits for terminology software developers
- Basic functional requirements for terminology services are clearly specified
- Implementation can be based on existing databases and software
- A common entry point to terminology content
Implementations/ Case Studies (Actual Users)
- Apelon, Inc. - Wrapper over DTS API
- Intel
- Mayo Clinic - Wrapper over LexEVS
Resources
Work Groups
- Vocabulary WG
Education
- See more at http://www.hl7.org/implement/training.cfm
- HL7 Vocabulary WG Advanced Terminology Tutorials
Certification Available
- none
Presentations
- HL7 Vocabulary WG Advanced Terminology Tutorials
Relationship to/ Dependencies on, other standards
- See CTS specification for details
Links to current projects in development
- ANSI/HL7 V3 CTS, V1-2005, currently under ISO ballot IS #27951
- Common Terminology Services Release 2 [1]
