GuillermoReynoso Guillermo Reynoso - BA Terminology Research Center, Infosalud Foundation

Here are some quick comments on our perspective on CTS II

Scope

1. 1. 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.
   • 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.
   • 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.
   • 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.
   • 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.
2. 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. 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.
3. Of course we would love to see some discussion on change sets, but then we should first discuss a common terminology reference model?.
4. 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.
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.
7. 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.

   Some of these comments are high level and eventually would need to be dissected and some others are too detailed for this stage. I apologize for the inconvenience.

   Best regards,

   Guillermo

   Guillermo Reynoso, MD BA Terminology Research Center at the Infosalud Foundation Buenos Aires, Argentina Editor, SNOMED CT Spanish Edition Consultant, SNOMED International Editorial Board