Difference between revisions of "CTS2"
| (6 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
| − | == ''' | + | == '''please see [[Common Terminology Services - Release 2 (Normative)]]''' == |
| − | The | + | {| 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. | ||
| + | |||
| + | |} | ||
| + | |||
| + | 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 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. | 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 [http://informatics.mayo.edu/LexGrid/index.php?page=ctsspec CTS Specification], which is both a functional and API specification. | + | |
| + | This differs from the initial [http://informatics.mayo.edu/LexGrid/index.php?page=ctsspec CTS Specification], which is both a functional and API specification. | ||
| + | |||
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. | ||
| − | |||
| − | |||
Latest revision as of 16:16, 13 July 2012
Contents
please see Common Terminology Services - Release 2 (Normative)
|
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. |
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
