1. 1/24/2005CTS II - HL7 Vocabulary TC CTS II HL7 Working Group Meeting Vocabulary TC

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

3. 1/24/2005CTS II - HL7 Vocabulary TC 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);

4. 1/24/2005CTS II - HL7 Vocabulary TC CTS I Final draft published –http://informatics.mayo.edu/informatics_pages /standards/cts/specification/ctsSpec/cts.htmhttp://informatics.mayo.edu/informatics_pages /standards/cts/specification/ctsSpec/cts.htm Awaiting negative ballot withdrawal –Solbrig –Markwell –(2 others) Issue: mixture of translation / mapping

5. 1/24/2005CTS II - HL7 Vocabulary TC 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 /..

6. 1/24/2005CTS II - HL7 Vocabulary TC CTS II Mailing Questions Question 1: Should CTS II specify APIs 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 APIs include description logic classifiers? Import/Export? Should these standards be represented as APIs, data structures or both? Does the specification need to include deltas – the ability to exchange a block of update rules? Provenance? What sort of provenance information needs to be included in the APIs? 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?

7. 1/24/2005CTS II - HL7 Vocabulary TC CTS II Mailing Questions Question 2: Technology The 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)

8. 1/24/2005CTS II - HL7 Vocabulary TC CTS II Mailing Questions Question 3: Requirements T he 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?

9. 1/24/2005CTS II - HL7 Vocabulary TC CTS II Mailing Responses Extensions/corrections to current spec New functionality

10. 1/24/2005CTS II - HL7 Vocabulary TC Extensions / Corrections

11. 1/24/2005CTS II - HL7 Vocabulary TC Extensions / Corrections Concept 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.

12. 1/24/2005CTS II - HL7 Vocabulary TC Extensions / Corrections Concept 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.

13. 1/24/2005CTS II - HL7 Vocabulary TC Extensions / Corrections 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.

14. 1/24/2005CTS II - HL7 Vocabulary TC Extensions / Corrections Local 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.

15. 1/24/2005CTS II - HL7 Vocabulary TC Extensions / Corrections Local 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.

16. 1/24/2005CTS II - HL7 Vocabulary TC Extensions / Corrections Local 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.

17. 1/24/2005CTS II - HL7 Vocabulary TC Extensions / Corrections Local 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.

18. 1/24/2005CTS II - HL7 Vocabulary TC Extensions / Corrections Local 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.

19. 1/24/2005CTS II - HL7 Vocabulary TC Extensions / Corrections Process An improving SNOMED-HL7 relationship with closer technical collaboration might help in several areas.

20. 1/24/2005CTS II - HL7 Vocabulary TC New Functionality

21. 1/24/2005CTS II - HL7 Vocabulary TC New Functionality Versioning 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.

22. 1/24/2005CTS II - HL7 Vocabulary TC New Functionality Authoring / 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.

23. 1/24/2005CTS II - HL7 Vocabulary TC New Functionality Authoring / 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.

24. 1/24/2005CTS II - HL7 Vocabulary TC New Functionality Authoring / 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.

25. 1/24/2005CTS II - HL7 Vocabulary TC New Functionality Authoring / 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.

26. 1/24/2005CTS II - HL7 Vocabulary TC New Functionality DLs 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.

27. 1/24/2005CTS II - HL7 Vocabulary TC New Functionality DLs and Classifiers (cont) I think you should be looking at the Resource Description Framework (RDF).

28. 1/24/2005CTS II - HL7 Vocabulary TC New Functionality HL7 Support Templates CDA

29. 1/24/2005CTS II - HL7 Vocabulary TC New Functionality HL7 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.value Domain = "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 relationships 2) 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

30. 1/24/2005CTS II - HL7 Vocabulary TC New Functionality HL7 Support I think of templates as use case specific applications and the terminology services as precompiled terminology expressions, so to speak

31. 1/24/2005CTS II - HL7 Vocabulary TC CTS II Other 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.

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

33. 1/24/2005CTS II - HL7 Vocabulary TC 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?

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