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

New Functionality

From HL7Wiki
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.

Authoring

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.

Authoring environments in my view are out of scope for CTS II. There are just too many things to address, and the audience would be very much limited. As we said before, it would be nice to receive contributions in a standardized way, but the inner workings of evaluating and committing changes are perhaps implementation specific. Still, vocabulary level would be accessible.

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.

Issues

  • 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.

CL Classifiers

Once full authoring is admitted, the question rises whether DL classifiers should be supported as well and, if so, how. Not that DL classifiers represent a service that is consumed by the CTS2 implementations rather than published.

Authoring environments should be classifier independent (able to connect to different classifiers). So the DIG spec should be supported for the communication between authoring tools and classifiers.


Updates

Of course we would love to see some discussion on change sets, but then we should first discuss a common terminology reference model?.

Including a way to request updates from one terminology version to another would be very good for incremental updates. Again, the way the updates are represented might need a kind of terminology reference model.

By updates we are referring to the ability to publish and distribute content in a standardized format. Note that it isn't totally obvious how the update/distribution mechanism differs from authoring, as updates could be viewed as a collection of authoring instructions.

Templates

I think of templates as use case specific applications and the terminology services as “precompiled” terminology expressions, so to speak

Should the CTS2 specification support a set of API's that implement the functionality required by templates?

CDA

How does the CTS2 specification merge with the CDA?

(Juha Mykkänen) For the convenience of CDA developers, an idea was introduced (for CodeAPI in Finland) that there should be an operation that would directly return a CDA element (XML segment) for a given entry.

Canonical transformation service

(Bob Dolin) From the TermInfo project, we've identified the need for a service that can transform various pre- and post-coordinated expressions into a canonical form. For instance, I may receive an OBX segment that includes a LOINC code in OBX-3, where the LOINC code contains a pre-coordinated method. I may receive an OBX segment from someone else with a different LOINC code in OBX-3 and a method code in OBX-17. A "canonical transform" service could compare these to see if they are equivalent, if one subsumes the other, if the method code in OBX-17 conflicts with a pre-coordinated method in the LOINC code, etc.