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

Difference between revisions of "Enhancements"

From HL7Wiki
Jump to navigation Jump to search
Line 1: Line 1:
 +
== 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 ==
 
== Performance ==
'Too many roundtrips to the terminology server'
+
''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.  
+
''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 ===
 
=== Options ===

Revision as of 15:52, 25 March 2005

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()

Serialized functions

There have been requests for complex functions - 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?