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

   
   

   ---

   ---

   At the last HL7 meeting in Atlanta Ellen Ryske "volunteered" me (and herself) for providing feedback on behalf of SNOMED on this matter, based on some discussions held during CTS I ballot resolution. Ellen felt SNOMED should contribute to the evolution of CTS II, but she is leaving the CAP this month and on the other hand the SNOMED unit is undergoing a major reorganization during this first quarter of 2005. I am hopeful the new SNOMED direction would enable new collaboration scenarios with HL7 and with other communities.

   Our research unit in Buenos Aires continued working during 2004 on several SNOMED related technical areas (internationalization, vocabulary, mapping and metrics, and collaborative terminology development) contributing our findings thorugh the SNOMED technical working group (but without funding support from CAP), as a complement to our work with the ongoing maintenance of the Spanish Edition of SNOMED CT (which is funded by CAP) and its eventual locale-specific flavors. In this transition period, as SNOMED transforms into a more open organization, there are some delays in the incorporation of updates to the existing structure and mechanisms.

   Then, my personal view is that there are some issues that should be addressed in the SNOMED technical side and business model before broader discussion of what features of terminologies like SNOMED the CTS II spec should address. For example:

   1. In my perception, the existing SNOMED mechanisms and their intended usage are not clear to many people that otherwise would be able to provide valuable feedback. This may be due to the fact that original design documents are not available any more for download, and that the documentation that distilled them is charged a separate fee.
   2. While the open working groups created in 2004 promoted participation, the process by which that participation would turn into deliverables still needs some workup.
   3. There are some known issues with some mechanisms for which fixes still have not been approved.
   4. An improving SNOMED-HL7 relationship with closer technical collaboration might help in several areas.

   Overall, I feel any contribution I may provide today regarding ideas aroung CTS II is mostly my personal opinion, biased in the direction I would like SNOMED to follow, but not necessarily representative of the actual direction SNOMED would follow. I mean, before CTS II we should rework the way we are currently working/collaborating.

   I will forward you the comments of our terminology research group in a separate mail, as this is kind of personal comment. Official SNOMED comments would perhaps come later.

   Look forward to see you next week.

   Best regards,

   Guillermo

   Guillermo Reynoso, MD BA Terminology Research Center at the Infosalud Foundation Buenos Aires, Argentina