Difference between revisions of "CTS2"
| Line 7: | Line 7: | ||
| | | | ||
| − | '''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 Functional Model. | + | '''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 | + | The implication of this decision is that The CTS 2 specification will be a developed as a Functional Mdel 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. | ||
Revision as of 15:18, 16 January 2007
Contents
CTS 2.0 Specification page
The Common Terminology Services 2.0 Specification will be an extension the HL7 CTS Specification. The intent of this set of pages to to gather requriements and associated discussion regarding the specification.
|
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 Mdel 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
