This wiki has undergone a migration to Confluence found Here
Difference between revisions of "New Functionality/Enhancements"
Jump to navigation
Jump to search
| Line 10: | Line 10: | ||
**CTS is intentionally silent when it comes to service advertising and discovery, establishing and maintaining connections, and the delivery and routing of messages. It is presumed that a CTS implementation will use the underlying architecture that is most appropriate for the given implementation circumstances. Does this include the above requirement? Is this something we would like to revisit for CTSII? | **CTS is intentionally silent when it comes to service advertising and discovery, establishing and maintaining connections, and the delivery and routing of messages. It is presumed that a CTS implementation will use the underlying architecture that is most appropriate for the given implementation circumstances. Does this include the above requirement? Is this something we would like to revisit for CTSII? | ||
** Can this be addressed by the HL7-OMG Services Infrastructure group? | ** Can this be addressed by the HL7-OMG Services Infrastructure group? | ||
| + | ** Server metadata (CodeAPI/Finland) contains operations for: server product (product name, version, contact info etc.), supported code sets and their versions, supported conformance levels | ||
<br/> | <br/> | ||
<p> | <p> | ||
[[http://informatics.mayo.edu/wiki/index.php/CTSII_Use_Cases#CTS2_Use_Cases BACK]] | [[http://informatics.mayo.edu/wiki/index.php/CTSII_Use_Cases#CTS2_Use_Cases BACK]] | ||
Revision as of 15:22, 17 June 2005
Use Case Name: Server Metadata
- Description: There should be a way to interrogate the server on the supported mechanisms/artifacts and their versions as today we can do for coding systems
- (details as needed)
- Who needs it and why? - The service itself should be capable of returning provenance details such as the supported mechanisms/artifacts and their versions conained within the service. This information
- Why should this be standardized? - Within the domain of CTS, the interrogatoin of the artifacts/mechanisms provided by each individual instance should be standardized. This will allow for predicatable and efficient identification of the sought after artifacts by users/bots.
- Questions and issues:
- Need to select a minimum set of metadata that will identify the assets/services provided by the service. Can this be coordinate with the Value Set registry discussions currently ongoing o the Vocab mailer?
- CTS is intentionally silent when it comes to service advertising and discovery, establishing and maintaining connections, and the delivery and routing of messages. It is presumed that a CTS implementation will use the underlying architecture that is most appropriate for the given implementation circumstances. Does this include the above requirement? Is this something we would like to revisit for CTSII?
- Can this be addressed by the HL7-OMG Services Infrastructure group?
- Server metadata (CodeAPI/Finland) contains operations for: server product (product name, version, contact info etc.), supported code sets and their versions, supported conformance levels
[BACK]
