This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Difference between revisions of "CTS2/doc/CTS2 History"

From HL7Wiki
Jump to navigation Jump to search
 
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>[[CTS2/doc/File:cts2fig1.png]]</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>[[CTS2/doc/File:cts2fig2.png]]</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.

Cts2fig1.png
Figure 2: The development of the CTS2 1.0 Standard

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.

Cts2fig2.png
Figure 3: CTS2 Artifacts

These artifacts are all related, but they are of different kinds.

  1. 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.
  2. 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.”
  3. 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.
  4. 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.
  5. 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.

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