Difference between revisions of "Product CTS"
Charliemccay (talk | contribs) |
|||
| (9 intermediate revisions by 3 users not shown) | |||
| Line 42: | Line 42: | ||
===Business Case (Intended Use, Customers)=== | ===Business Case (Intended Use, Customers)=== | ||
* Terminology service users and providers | * Terminology service users and providers | ||
| − | |||
===Benefits=== | ===Benefits=== | ||
* Benefits for designers and implementation developers | * Benefits for designers and implementation developers | ||
| − | ** Software can be written once | + | ** Software can be written once without the need to understand each terminology vendor’s database and/or API |
** Hides much of the complexity inherent in modern terminology systems. | ** Hides much of the complexity inherent in modern terminology systems. | ||
| Line 57: | Line 56: | ||
===Implementations/ Case Studies (Actual Users)=== | ===Implementations/ Case Studies (Actual Users)=== | ||
* Apelon, Inc. - Wrapper over DTS API | * Apelon, Inc. - Wrapper over DTS API | ||
| − | * Intel | + | * Intel SOA Expressway for Healthcare, which provides a standard CTS interface overtop of the open source Apelon DTS terminology engine. [http://software.intel.com/en-us/blogs/2008/10/02/designing-for-gray-scale-under-the-hood-of-medical-terminology-translation/] [http://software.intel.com/en-us/blogs/2008/09/23/semantic-normalization-making-sense-out-of-health-data/] |
| − | * Mayo Clinic - Wrapper over LexEVS | + | * Mayo Clinic - Wrapper over LexEVS, and MS access for HL7 |
| + | * Centers for Disease Control and Prevention (CDC) Vocabulary Server - PHIN VADS [http://phinvads.cdc.gov], PHIN VADS Developer's Guide[http://phinvads.cdc.gov/vads/developersGuide.action], VADS online support forum [http://www.phconnect.org/group/phinvads] | ||
| + | * HL7 implementation of CTS on GForge as the engine behind the Harmonization tool (not maintained since the alpha release) | ||
===Resources=== | ===Resources=== | ||
| Line 82: | Line 83: | ||
* ANSI/HL7 V3 CTS, V1-2005, currently under ISO ballot IS #27951 at [http://www.hl7.org/special/Committees/projman/searchableProjectIndex.cfm?action=edit&ProjectNumber=483 Project Insight # 483] | * ANSI/HL7 V3 CTS, V1-2005, currently under ISO ballot IS #27951 at [http://www.hl7.org/special/Committees/projman/searchableProjectIndex.cfm?action=edit&ProjectNumber=483 Project Insight # 483] | ||
* [http://www.hl7.org/dstucomments/showdetail.cfm?dstuid=50 Common Terminology Services Release 2] at [http://www.hl7.org/special/Committees/projman/searchableProjectIndex.cfm?action=edit&ProjectNumber=324 Project Insight # 324] | * [http://www.hl7.org/dstucomments/showdetail.cfm?dstuid=50 Common Terminology Services Release 2] at [http://www.hl7.org/special/Committees/projman/searchableProjectIndex.cfm?action=edit&ProjectNumber=324 Project Insight # 324] | ||
| + | [[Category:Products]] | ||
Latest revision as of 11:04, 30 November 2010
Product Brief - CTS - Common Terminology Services
Contents
- 1 Product Brief - CTS - Common Terminology Services
- 1.1 Product Name - CTS - Common Terminology Services
back to Main_Page back to Product_List
Product Name - CTS - Common Terminology Services
Topics
Standard Category
Health Information Modeling Standards: V3 Foundation Vocabulary Domains
Integration Paradigm
SOA based terminology service, Services
Type
Normative, ANSI Standard, ISO Standard
Releases
- ANSI/HL7 V3 CTS, V1-2005; ISO/HL7 27951:2009(E)
- Common Terminology Services Release 2 HL7 V3 CTS, R2 - HL7 Version 3 Standard: Common Terminology Services, Release 2
DSTU - Oct 2009
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 without the 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 SOA Expressway for Healthcare, which provides a standard CTS interface overtop of the open source Apelon DTS terminology engine. [1] [2]
- Mayo Clinic - Wrapper over LexEVS, and MS access for HL7
- Centers for Disease Control and Prevention (CDC) Vocabulary Server - PHIN VADS [3], PHIN VADS Developer's Guide[4], VADS online support forum [5]
- HL7 implementation of CTS on GForge as the engine behind the Harmonization tool (not maintained since the alpha release)
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 at Project Insight # 483
- Common Terminology Services Release 2 at Project Insight # 324
