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?

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.

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?