This wiki has undergone a migration to Confluence found Here
CTS 2 comments OmarBouddou
Jump to navigation
Jump to search
To: Solbrig, Harold R. Cc: Crandall, Glen (EDS); Lincoln, Mike Sent: 1/18/2005 4:07 PM Harold,
Please find below a few comments from the VHA Enterprise Terminology Services team regarding our preliminary experience with HL7 CTS 1.0 specifications. I hope these will be useful in your considerations for version 2.0.
We appreciate your work,
Omar Bouhaddou Department of Veterans Affairs VHA Enterprise Terminology Services (858) 832-1310 (801) 755-3263 (mobile)
- Concept IDs 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.
- Versioning 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.
- '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. 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.
- Local terminology 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.
