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

Difference between revisions of "CTS2"

From HL7Wiki
Jump to navigation Jump to search
m
Line 20: Line 20:
  
  
=== CTS 2 Call Schedule ===
+
=== Administrative Items ===
 +
 
 +
==== Conference Call Schedule ====
 +
*[[CTS Meetings|Meetings]]
 +
*[[Relationships with other Organizations / Initiatives]]
 +
 
 +
 
 +
=== Documents and Infrastructure ===
 +
 
  
 
=== CTS 2 Discussion Items ===
 
=== CTS 2 Discussion Items ===
 
 
*[[InitialMailing]]
 
*[[InitialMailing]]
 
**[[CTS 2 Responses|Responses]]
 
**[[CTS 2 Responses|Responses]]
Line 36: Line 43:
  
 
*[[Discussion, FAQ, etc.]]
 
*[[Discussion, FAQ, etc.]]
 
*Administration
 
**[[Relationships with other Organizations / Initiatives]]
 
**[[CTS Meetings|Meetings]]
 

Revision as of 18:12, 13 January 2007

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 Functional Model.

The implication of this decision is that The CTS 2 specification will be a developed as a functional specification 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 afunctional 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


Documents and Infrastructure

CTS 2 Discussion Items