This wiki has undergone a migration to Confluence found Here

New Functionality

From HL7Wiki
Revision as of 21:19, 25 March 2005 by Hsolbrig (talk | contribs)
Jump to navigation Jump to search

Rule based mapping

There may be several mappings from a terminology to a classification, depending on the use case. This may need further discussion. I recognize that there is no solid spec on rule based mapping, should it exist other requirements might arise (defer to CTS III?) - I mean, currently, only simple, deterministic mappings are supported, as the initial scope was rather to support HL7 vocabulary needs rather than a general purpose terminology server.

Versioning and Provenance

We understand HL7 CTS 1.0 does not support versioning. We have began implementing our own versioning structures and APIs. We look forward to seeing this topic addressed in version 2.0.


We would welcome some discussion on authoring APIs and collaboration APIs. In evolving, large scale terminologies there should be means to support collaborative development and user feedback/change requests. At least at the vocabulary level, initially. Please note that collaboration/feedback would be easy to standardize, while authoring might depend a lot on many other variables (authoring environment, concept model, artifact (concept, vocabulary, mapping)). Yes, a collaboration API might be easier and more effective in the short term (to standardize the interface between users/vendors and terminology developers) rather than standardizing the actual authoring tool (I mean, something like addDescriptionSugestion rather than addDescription).

The SCT Spanish edition is currently maintained in a collaborative environment through the internet. We see a need to give vendors guidance regarding how they connect their implementations and channel user requests. While the specific authoring webservices are rather specific to our implementation of the vocabulary maintenance workspace.

One more piece of information: at the current time, VHA is using Apelon's tools for authoring and maintenance (ie, write APIs). This yield to a hybrid environment made of Apelon tools and VHA deployment/runtime access tools and is less than optimal. We can already see that an integrated environment would be more manageable.


  • Everyone appears to agree that some level of authoring support is needed. As quoted above, Guillermo believes that a reasonable approach would be to specify an API that supports a collaboration/feedback mechanism. The VA, however, has registered a strong interest in a full-fledged authoring API - something that supports validation.
    • Collaboration/feedback - a mechanism that supports the parameterized submission of revision requests to an authoritative source and, possibly, a response mechanism. The advantages of this approach include:
      • Development of a mechanism that allows clear and crisp update requests
      • Validation and verification is left to the authoritative source instead of attempting to account for it in the specification
    • Full authoring - a mechanism that would allow insertion, retirement and updates on concepts, relations, value sets, vocabulary domains, etc. The advantages of this approach inclued:
      • Standardized way to do things.

== Updates --