Enhancements

Concept Identifiers

HL7 CTS specifications assume that when consumers of terminology services make API calls, they will refer to the concept ID within the terminology source where the concept belongs. Thus, if consumers make a call targeted at SNOMED, then they will use SNOMED IDs, if they make a query to ICD9, they will be returned ICD9 codes, etc.

At the VHA, all terminologies in use, whether they are VHA native like allergies or adopted like SNOMED problem list, we assign VHA unique IDs (VUIDs) to all entries.

It may be more desirable to be able to refer to IDs as an object made of the concept ID and the terminology source ID to eliminate ambiguities and increase user flexibility.

Questions

[hrs] I'm not certain that I understand this requirement. What prevents the VA from creating a VA codeSystem OID which they use in the local messages and then creating a mapping between the VA code system and the SNOMED, ICD9, etc. code systems?

[rah] My take on the requirement was that if the IDs were stored as objects the mapping would be more consistent and predictable between different local extentions of the same code system (aka assigning a CUI to a VUID and a MUID (Mayo Unique Identifier, if there is such a thing.)

Performance

Too many roundtrips to the terminology server

In considering VHA clinical applications requirements for terminology services, we are finding that these requirements are stated at a higher level than the CTS APIs are defined. For instance, pharmacy has a use case in which the user would like to find the drug categories used to treat a given disease. To satisfy this requirement with CTS 1.0 APIs will require 'many roundtrips to the terminology server,' and thus affects performance. In general, at VHA, we are planning to offer CTS APIs access but also offer customized APIs to our stakeholders (e.g., pharmacy). Both CTS APIs and the customized APIs will be satisfied by a common layer of APIs that minimizes the 'roundtrips to the server and optimizes performance.

Options

• What operations need to be batched?
• Should this be implemented as additional operations where needed:

reply[] = function(Arg[] arg)

• Or should there be an overall control structure of some sort:

beginBatch()

function(Arg arg)

function(Arg arg)

...

function(Arg arg)

reply[] = doBatch()

Local Extensions

If at the VHA we add local properties to a given code system (e.g., SNOMED-CT). Then, for instance, does the method ‘lookupCodeSystemInfo' return all properties including the local extensions added by the VHA? We would think CTS should let the user decide whether they want the local terminology extensions to be returned as well or not.

It should support SNOMED mechanisms for dealing with SNOMED core content and local extensions to that core. # The subset mechanism is today required in SNOMED to browse the descriptions (vocabulary) while supporting Realm localization. Part of this can be accomplished with CTS I, but some issues might not. There is also an update to the subset mechanism that is still under discussion in SNOMED that would increase the gap with CTS I. This is particularly true in non-US settings.

With an extensible and subsetable terminology, the definition of what a coding system is becomes blurred. There is perhaps the need to specify what configuration I might be referring to. For example testing subsumption between a concept that belongs to an extension and another that belongs to the core. There should be also some discussions on extensions.

[hrs] This is an unresolved issue within the vocab TC as well. It definitely needs discussion in terms of extensions and revisions to the CTS 2.0 model as well as the API

Serialized functions

The subset mechanism also includes a subset flavor that enables the navigation of SNOMED without using the default subtype hierarchy. Most users browsing the terminology would prefer an intuitive display of the concepts instead of the result of the plain DL classification. In this context, the "children" to display depend on the navigation view, and may include (or not) the actual subtypes of the concept.

[hrs] If I can be allowed to generalize, this is a request for a "compound function" - give me all concepts that are subtypes of 'X' that have the word "Y" in their definition or "Z" and "T" in their names.

• Should these be implemented where needed:

reply = function(ConceptId[] subtypes, WordAndProperty match[])

• or should we try to put together an operator language like caBIO
• or should we build a query language like jTerm?

[jmy] To continue the generalized thread, each feature in a "compound function" may or may not be supported in a given code server implementation or code set/terminology. Identified search delimiter requirements include hierarchies, substring flavors and languages in designations and any other properties, local and "entry status aware" search, multiple search keys etc. This can result in some interesting "conformance levels" (as in CodeAPI/Finland), where the first option from the list above was used.

Local configuration

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.

Authentication and provision for session information should be considered. In loosely coupled environments (stateless) like the web, I should send the appropriate configuration for my requests in each request, or be able to reference a session token.

Configuration parameters should have some kind of extensibility. This subject was discussed in CTS I ballot resolution and deferred for this stage.

Unmet functional requirements in CTS (Bob Dolin)

• Need the ability to differentiate different versions of a value set.
• Need the ability to define value set specific properties. The current CTS model only supports properties on a CodeSystem. For instance, a concept may have a different display name depending on its Context of Use, or it may be that new concepts in a value set are in a draft state until they have been reviewed.
• Need the ability to query the MapEntries of a particular CodeMap. As noted above, I think the validateTranslation and translateCode functions should be modified to support this.
• Need the ability to perform subsumption queries - for instance, when searching SNOMED CT, I need to find all concepts that are a subtype of 243796009 "Context-dependent Categories" with an AssociatedFinding relationship to 195967001 "Asthma" or any of its descendants.
• Need the ability to set the value of value set specific properties. The current CTS includes query functions, and no update functions.