This wiki has undergone a migration to Confluence found Here

New Functionality/Enhancements

From HL7Wiki
Jump to navigation Jump to search

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 query operations for: server product (product name, version, contact info etc.), supported code sets and their versions, supported conformance levels


Use Case Name: Terminology Metadata - Local Extentions

  • Description: The user locates a terminology supported by CTS (via some query mechanism.) The user wants to determine if there are any local extentions to that terminology.
    • (details as needed)
  • Who needs it and why? - The service itself should be capable of returning provenance details such as whether there are any local extentions to that terminology.
  • Why should this be standardized? - There needs to be a standard mechanism available for a user to determine whether there are any local extensions to a terminology.


  • Questions and issues:


[BACK]