HL7 Vocabulary TC: Common Terminology Services Overview

1. CTS II HL7 Working Group Meeting Vocabulary TC CTS II - HL7 Vocabulary TC

2. CTS II • Short intro - Why Common Terminology Services (CTS)? • Status of CTS • CTS II Mailing and Feedback • Next Steps CTS II - HL7 Vocabulary TC

3. Common Terminology Services • Interface specification • Model and definitions • Series of “contracts” between client and server • Specifies what needs to happen, not how • example: boolean isConceptIdValid( in ConceptId concept_id, in boolean activeConceptsOnly ) raises (UnknownCodeSystem, UnexpectedError); CTS II - HL7 Vocabulary TC

4. CTS I • ‘Final draft’ published • http://informatics.mayo.edu/informatics_pages/standards/cts/specification/ctsSpec/cts.htm • Awaiting negative ballot withdrawal • Solbrig • Markwell • (2 others) • Issue: mixture of “translation” / “mapping” CTS II - HL7 Vocabulary TC

5. CTS II Status • Decision at Atlanta Meeting was to send out a general mailing asking about scope, purpose, requirements, etc. • Sent Fall 2004 • HL7 Vocab / ISO TC 215 / TermInfo mailer • Select individuals • Rector / Campbell / Rossi Mori / .. CTS II - HL7 Vocabulary TC

6. CTS II Mailing Questions • Question 1: Should CTS II specify API’s for: • Authoring?  If so, are there any standards (e.g. DIG, SNOMED-CT) that should be considered and, if so, how should they be integrated?  Are there any areas that should specifically be avoided?  Should the authoring API’s include description logic classifiers?Import/Export?  Should these standards be represented as API’s, data structures or both?  Does the specification need to include “delta’s” – the ability to exchange a block of update rules?Provenance?   What sort of provenance information needs to be included in the API’s?  Does authentication need to be included in the specification?  Does the API need to support role and access constraints?Are there other areas as well? CTS II - HL7 Vocabulary TC

7. CTS IIMailing Questions • Question 2: TechnologyThe current CTS specification is has OMG IDL, Java and SOAP bindings.  Should CTS II use the same approach, or is there a different technology that would make more sense.  Has the OMG Model Driven Architecture (MDA) matured to the point that it would be useful?  Are other options available?What technologies will the specification have to interoperate with?  (e.g. OWL, OBO) CTS II - HL7 Vocabulary TC

8. CTS IIMailing Questions • Question 3: RequirementsThe CTS II API, at a minimum, needs to support the requirements presented by the Enterprise Healthcare Record (EHR), which includes NHII RHIO and the NCI.  What other requirements does CTS II need to address?   What resources should the TC use to discover them? CTS II - HL7 Vocabulary TC

9. CTS IIMailing Responses • Extensions/corrections to current spec • New functionality CTS II - HL7 Vocabulary TC

10. Extensions / Corrections CTS II - HL7 Vocabulary TC

11. Extensions / CorrectionsConcept Identifiers • 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. CTS II - HL7 Vocabulary TC

12. Extensions / CorrectionsConcept Identifiers • Batch Submission '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. CTS II - HL7 Vocabulary TC

13. Extensions / CorrectionsLocal 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. CTS II - HL7 Vocabulary TC

14. Extensions / CorrectionsLocal Extensions (cont.) It should support SNOMED mechanisms for dealing with SNOMED core content and local extensions to that core.     a) 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. CTS II - HL7 Vocabulary TC

15. Extensions / CorrectionsLocal Extensions (cont.) 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. CTS II - HL7 Vocabulary TC

16. Extensions / CorrectionsLocal Extensions (cont.) • c) 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. CTS II - HL7 Vocabulary TC

17. Extensions / CorrectionsLocal Extensions (cont.) • d) 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.    e) 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. CTS II - HL7 Vocabulary TC

18. Extensions / CorrectionsLocal Extensions (cont.) • 5. 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.6. Configuration parameters should have some kind of extensibility. This subject was discussed in CTS I ballot resolution and deferred for this stage. CTS II - HL7 Vocabulary TC

19. Extensions / CorrectionsProcess • An improving SNOMED-HL7 relationship with closer technical collaboration might help in several areas. CTS II - HL7 Vocabulary TC

20. New Functionality CTS II - HL7 Vocabulary TC

21. New FunctionalityVersioning We understand HL7 CTS 1.0 does not support versioning. We have began implementing our own versioning tructures and APIs. We look forward to seeing this topic addressed in version 2.0. CTS II - HL7 Vocabulary TC

22. New FunctionalityAuthoring / Updates • 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. CTS II - HL7 Vocabulary TC

23. New FunctionalityAuthoring / Updates (cont) 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. CTS II - HL7 Vocabulary TC

24. New FunctionalityAuthoring / Updates (cont) • 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. CTS II - HL7 Vocabulary TC

25. New FunctionalityAuthoring / Updates (cont) 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. CTS II - HL7 Vocabulary TC

26. New FunctionalityDL’s and Classifiers 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. CTS II - HL7 Vocabulary TC

27. New FunctionalityDL’s and Classifiers (cont) I think you should be looking at the Resource Description Framework (RDF). CTS II - HL7 Vocabulary TC

28. New FunctionalityHL7 Support • Templates • CDA CTS II - HL7 Vocabulary TC

29. New FunctionalityHL7 Support • The situation is this...In an instance of observation, act.observation.code may be specified as a domain with, for example, 3 values...Domain = "Skin Exam"Skin Exam Values = ("Skin color"; "Presence of rash"; "Edema")If act.observation.code = "Skin color", then a value set for act.observation.value might be ("red"; "white"; "blue")If act.observation.code = "Presence of rash", then a value set for act.observation.value might be ("present"; "not present")If act.observation.code = "Edema", then a value set for act.observation.value might be ("not present"; "1+"; "2+"; "3+"; "4+")Therefore, there seems to be several potential domains for act.observation.valueDomain = "Skin color"Skin color Values = ("red"; "white"; "blue")Domain = "Presence of rash"Presence of rash Values = ("present"; "not present")Domain = "Edema"Edema Values = ("not present"; "1+"; "2+"; "3+"; "4+")?Is there a mechanism in our current tooling to:?1) record these domain relationships2) constrain the domain of act.observation.value to be used only when a specific value is selected in the domain value set in act.observation.code CTS II - HL7 Vocabulary TC

30. New FunctionalityHL7 Support  I think of templates as use case specific applications and the terminology services as “precompiled” terminology expressions, so to speak CTS II - HL7 Vocabulary TC

31. CTS IIOther Issues • “In principle I would be in favour of adopting this specification as a future ISO standard. However I think it is not appropriate at this time to promote such a standard as a fast track action. Fast track in my view is only appropriate for matured work from other groups. As discussions in HL7 have started on a CTS2, and because the specification has hardly been implemented around the world, I presently do not yet see much reason for adoption by ISO of this work.” CTS II - HL7 Vocabulary TC

32. Synopsis • Versioning • Performance & Configuration • Subsetting & Additional identifier issues • Collaborative input / full authoring • Not much input on DL & Scope • No input on bindcing CTS II - HL7 Vocabulary TC

33. Next Steps • Should we do anything? • If so, what? • HL7 Specific Support • Extensions – make CTS I do the job • Updates / submissions • HL7 has to do this anyway, so something will have to haappen • SNOMED relationship? • Terminfo Relationship? CTS II - HL7 Vocabulary TC

34. Next Steps • CTS I support • Who will promote / support / review? • Extensibility policy • Java SIG • CDC • NCI • Name for “Son of CTS”? • Who? CTS II - HL7 Vocabulary TC