Difference between revisions of "CTS2/doc/CTS2 History"
| Line 1: | Line 1: | ||
Several service definition efforts predate CTS2, including Lexicon Query Service (LQS), NCI’s evolution of LQS into [https://wiki.nci.nih.gov/display/LexEVS/LexGrid LexGrid], and HL7’s functionally more limited Common Terminology Service (CTS). CTS2 aims to <b>support rich functionality without overwhelming implementers with complexity</b>. It approaches this problem by providing designs for maximum capability, but breaking the specification into modular chunks and supporting limited scope implementations for organizations that only need limited capabilities—or that want to prove the solution before increasing their investment. | Several service definition efforts predate CTS2, including Lexicon Query Service (LQS), NCI’s evolution of LQS into [https://wiki.nci.nih.gov/display/LexEVS/LexGrid LexGrid], and HL7’s functionally more limited Common Terminology Service (CTS). CTS2 aims to <b>support rich functionality without overwhelming implementers with complexity</b>. It approaches this problem by providing designs for maximum capability, but breaking the specification into modular chunks and supporting limited scope implementations for organizations that only need limited capabilities—or that want to prove the solution before increasing their investment. | ||
| − | <center>[[ | + | <center>[[File:cts2fig1.png]]</center> |
<center><i>Figure 2</i>: The development of the CTS2 1.0 Standard</center> | <center><i>Figure 2</i>: The development of the CTS2 1.0 Standard</center> | ||
| Line 9: | Line 9: | ||
<i>Figure 3</i>, below, illustrates the artifacts you may run into and their relationships. While the term “CTS2” usually refers to the Object Management Group (OMG) specification, you may hear the term used to mean any of the artifacts represented here. | <i>Figure 3</i>, below, illustrates the artifacts you may run into and their relationships. While the term “CTS2” usually refers to the Object Management Group (OMG) specification, you may hear the term used to mean any of the artifacts represented here. | ||
| − | <center>[[ | + | <center>[[File:cts2fig2.png]]</center> |
<center><i>Figure 3</i>: CTS2 Artifacts</center> | <center><i>Figure 3</i>: CTS2 Artifacts</center> | ||
Latest revision as of 07:01, 22 December 2015
Several service definition efforts predate CTS2, including Lexicon Query Service (LQS), NCI’s evolution of LQS into LexGrid, and HL7’s functionally more limited Common Terminology Service (CTS). CTS2 aims to support rich functionality without overwhelming implementers with complexity. It approaches this problem by providing designs for maximum capability, but breaking the specification into modular chunks and supporting limited scope implementations for organizations that only need limited capabilities—or that want to prove the solution before increasing their investment.
Figure 2 outlines the history of the development of CTS2, via the OMG development process. This is a standard and public process for specification development, and the chart illustrates the stages of public input. The National Cancer Institute’s LexGrid page provides a more detailed timeline here.
Figure 3, below, illustrates the artifacts you may run into and their relationships. While the term “CTS2” usually refers to the Object Management Group (OMG) specification, you may hear the term used to mean any of the artifacts represented here.
These artifacts are all related, but they are of different kinds.
- A requirements document: In 2009, the Health Level Seven Vocabulary working group, recognizing that a standard terminology service would be valuable for all the reasons outlined above, defined a set of requirements for such a server. These requirements were balloted and published as the CTS2 Service Functional Model, or SFM, available from HL7.
- A design specification: The requirements document was then presented to the OMG, which released an RFP for the development of a specification to support those requirements. The resulting OMG specification, Common Terminology Services 2 (available at the OMG web site), is the logical design for a solution that meets the requirements defined by HL7. This is what is most commonly understood to be meant by “CTS2.”
- An application meeting that specification, or an implementation of one of those applications: Several enterprises have now developed implementable software applications that are CTS2-compliant, and some have implemented that software to provide CTS2 services for terminologies in their domains of interest. See Implementations for more details.
- A development framework: In order to reduce the effort required to develop CTS2-compliant applications, Mayo has developed a set of tools to support CTS2 service and client development called the CTS2 Framework.
- An allied design specification (not shown): Some organizations implemented services based on the HL7 requirements specification, before the OMG design specification was released. These groups have collaborated on an HL7 conformance profile, CTS2N, for the SFM based on their implementations. This profile also makes an effort to harmonize with the CTS2 specification.
| 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 |
