Difference between revisions of "CTS2"
| Line 1: | Line 1: | ||
== '''CTS 2.0 Specification page''' == | == '''CTS 2.0 Specification page''' == | ||
| − | The Common Terminology Services 2.0 Specification | + | The Common Terminology Services 2.0 Specification are an ''extension'' the [http://informatics.mayo.edu/LexGrid/index.php?page=ctsspec HL7 CTS Specification]. The intent of this set of pages to to gather requriements and associated discussion regarding the specification. |
{| style="border:3px solid; background:#efefef;" | {| style="border:3px solid; background:#efefef;" | ||
| | | | ||
| + | |||
| + | The HL7 CTS 2 SFM was balloted as a DSTU. The purpose of the DSTU process is specifically designed to provide a framework to develop trial artifacts to test and validate via implementation prior to standardization. The CTS 2 DSTU has expired after a two year period, but has resulted in at least two implementations, andd has influenced the development of many other terminology service implementations. It is necessary now to adjust the CTS 2 SFM to reflect real-world implementation experience. | ||
| + | |||
| + | This project will focus on on what is supported between the SFM and the OMG PIM. New requirements care expected to be surfaced, but will be logged for inclusion in alternate versions of CTS 2. | ||
| + | |||
| + | |} | ||
'''NOTE:''' The Vocabulary Technical Committee voted on January 11, 2007 in San Diego, California to adopt the methodology developed by the Healthcare Service Specification Project ([http://hssp.wikispaces.com/ SOA SIG & HSSP]) for the development of the CTS 2 Service Functional Model (SFM). | '''NOTE:''' The Vocabulary Technical Committee voted on January 11, 2007 in San Diego, California to adopt the methodology developed by the Healthcare Service Specification Project ([http://hssp.wikispaces.com/ SOA SIG & HSSP]) for the development of the CTS 2 Service Functional Model (SFM). | ||
| − | The implication of this decision is that The CTS 2 specification will be a developed as a Functional | + | The implication of this decision is that The CTS 2 specification will be a developed as a Functional Model specification, that seeks to detail the “behavioral requirements that specify how a proposed system will process and handle information. It details the features and rules that must be present to fully implement the functionality desired.” [From the Sparx Enterprise Architect] |
| Line 20: | Line 26: | ||
Technical specifications will come from the work done by [http://hssp.wikispaces.com/ HSSP]within OMG. SFMs provide the grounds for an RFP issued by OMG to industry. The RFPs issued by OMG solicit industry submitters, who are ultimately the authors of technical specifications. The OMG reviews candidate submissions and selects the submission best supporting the RFP. Submitters often collaborate to produce a joint submission. | Technical specifications will come from the work done by [http://hssp.wikispaces.com/ HSSP]within OMG. SFMs provide the grounds for an RFP issued by OMG to industry. The RFPs issued by OMG solicit industry submitters, who are ultimately the authors of technical specifications. The OMG reviews candidate submissions and selects the submission best supporting the RFP. Submitters often collaborate to produce a joint submission. | ||
| − | |||
| − | |||
Revision as of 16:08, 13 July 2012
Contents
CTS 2.0 Specification page
The Common Terminology Services 2.0 Specification are an extension the HL7 CTS Specification. The intent of this set of pages to to gather requriements and associated discussion regarding the specification.
|
The HL7 CTS 2 SFM was balloted as a DSTU. The purpose of the DSTU process is specifically designed to provide a framework to develop trial artifacts to test and validate via implementation prior to standardization. The CTS 2 DSTU has expired after a two year period, but has resulted in at least two implementations, andd has influenced the development of many other terminology service implementations. It is necessary now to adjust the CTS 2 SFM to reflect real-world implementation experience. This project will focus on on what is supported between the SFM and the OMG PIM. New requirements care expected to be surfaced, but will be logged for inclusion in alternate versions of CTS 2. |
NOTE: The Vocabulary Technical Committee voted on January 11, 2007 in San Diego, California to adopt the methodology developed by the Healthcare Service Specification Project (SOA SIG & HSSP) for the development of the CTS 2 Service Functional Model (SFM).
The implication of this decision is that The CTS 2 specification will be a developed as a Functional Model specification, that seeks to detail the “behavioral requirements that specify how a proposed system will process and handle information. It details the features and rules that must be present to fully implement the functionality desired.” [From the Sparx Enterprise Architect]
The functional specification is extraordinarily “vanilla” in its approach and in its language. It is intended to broadly define a whole host of issues, and necessarily loses some of its power to recommend. But it is the first step in a process.
This differs from the initial CTS Specification, which is both a functional and API specification.
Technical specifications will come from the work done by HSSPwithin OMG. SFMs provide the grounds for an RFP issued by OMG to industry. The RFPs issued by OMG solicit industry submitters, who are ultimately the authors of technical specifications. The OMG reviews candidate submissions and selects the submission best supporting the RFP. Submitters often collaborate to produce a joint submission.
Administrative Items
Conference Call Schedule
Organizational Relationships
Documents and Infrastructure
- Current CTS 2 Functional Model (document)
- LexBIG Use Case Specification (document)
- HSSP Development Framework (link to hssp site)
- HSSP Slides (link to HSSP Site)
CTS 2 Discussion Items
- Functional Requirements
