SNOMED CT Editorial Advisory Group

Page tree

DateAuthorVersionComment
2017-10-01James T. Case2.0Major revision of the initial response to the discussion paper submitted by the Australian NRC
2017-12-19James T Case2.1Additional section added specifying restrictions on the allowed actions by extensions




Introduction

A discussion paper from the Content Managers Advisory Group, entitled Discussion Paper - Allowance of Extensions to Modify Core Content was submitted to SNOMED International management to resolve issues surrounding the interpretation of the allowable changes national extensions may make to the International release of SNOMED CT.  The discussion paper outlines a number of proposed clarifications to the interpretation of what is allowed and details the requirements for those changes.  This response proposes a set of policy statements that explicitly state what can and cannot be done to content of the International release by national extensions.

While this response is principality focused on the needs of national extensions, the general policies discussed here will apply to all extensions, regardless if they are directly dependent on the International release or another edition.  

Background

The primary concern expressed is the interpretation of Clause 4.1 of the SNOMED CT® AFFILIATE LICENSE AGREEMENT, which states: 

“Subject to clause 2.1.4, the Licensee may not modify any part of the SNOMED CT Core distributed as part of the International Release or as part of a Member’s National Release.”

Clause 2.1.4 states:

 “(The Licensor grants the Licensee, license to) modify the manner of formatting of the copy of the SNOMED CT Core distributed to the Licensee as part of the International Release or as part of a Member’s National Release”

 According to the discussion paper, there are two primary issues associated with this clause:

 "This restriction on modifications has been interpreted generally in two ways. 

  1. The RF2 distribution must not be modified, beyond appending additional rows. Overwriting data in the distribution files - such that an extension violates the append only model is not allowed (editor's addition). Additionally, the full history provided by the international release must provided, i.e. extensions may not omit anything;

  2. International components must not be modified.
    Overriding the international content through either:

    • the addition of new versions for international components within extensions; or

    • the addition of relationships to international concepts and changing their DL definition.

Restrictions covered by B have been shown to be impractical and prohibit proper quality terminology authoring."

Proposed actions allowed for National Extensions

The discussion paper proposes seven actions that national extensions may want to perform in the course of their content development and maintenance:

  1. Create new concepts.

  2. Fully define concepts they create.

  3. Classify terminology extensions.

  4. State additional IS A relationships against core (international) concepts.

  5. Retire (redundant) IS A relationships (not necessarily stated).

  6. Add additional defining (non-IS A) relationships to primitive international concepts.

  7. Retire content considered "inappropriate" - concepts, descriptions or relationships

The paper then goes into substantial detail justifying the need to perform each of these actions.  A request was forwarded to SNOMED International management for review and clarification of the interpretation of clause 4.1 and acceptance of the allowable proposed actions available to national extension managers.

This document attempts to clarify the interpretation of Clause 4.1 and clarify the allowable changes that an extension may make in their module to address perceived issues with the International release.

Evaluation of proposed allowable actions for national extensions

The initial draft of this policy document was extensively discussed at the Editorial Advisory Group face-to-face meeting in London, 2017. The consensus at the conclusion of this discussion topic was:

  • The interpretation by the EAG of section 2.1.4 was that of option A, i.e. "The RF2 distribution [of the International release] must not be modified... Overwriting data in the distribution files - such that an extension violates the append only model is not allowed...the full history [of] ...the international release must provided.
  • Conversely, the full content of the original RF2 International release distribution must be extractable from any RF2 distribution of a extension edition (combination of International and extension content), without the need for any data transformation.
  • The use cases for modifications to core international content were recognized as generally valid and as potentially causing classification changes to inferred views of international content in a extension release.
  • All modifications to the International release must be appended to the RF2 files within a Module ID owned by the extension.  Changes to the SNOMED International Module are not allowed.
  • Substantive errors in or improvement to content in the International release that are mitigated by content in an extension should be forwarded to SNOMED International in a timely fashion to improve the quality of the International release.

Summary of allowed actions by Extensions

In light of the above conclusions, append only changes may be made within an approved extension module, regardless of the impact on the inferred relationships of International release concepts, provided the following are adhered to:

  • These allowances are ONLY applicable to RF2 releases, where a full history of content changes is distributed
  • RF1 distributions that are derived from RF2 extensions that involve changes to inferences in the International release are in violation of Clause 4.1 of the affiliate license (source of the changes cannot be tracked, original International release cannot be extracted)
  • Classification inferences in an edition that result in differences from the International release must not be represented as SNOMED International content.
  • Due to the changes to International classifications caused by modifications by national extensions, a disclaimer notifying users of the differences between the extension release and the International release must accompany the national extension distribution files.

Actions not allowed by Extensions

In spite of the relative freedom implied by the above statements, there are some actions that can potentially be performed which violate the basic premise of achieving semantic interoperability or create structural or clinical quality issues, which must be avoided.  The following actions are not sanctioned, even if performed within the module of the extension

  • Changes to the GB and US language refsets are not allowed.  Creation of a new dialect refset is the appropriate approach to specifying a particular preferred term.
  • Creation of stated IS-A relationships that result in ancestors from mutiple top-level hierarchies. (e.g. Clinical finding and Procedure)
  • Creation of concepts that are a duplication of existing International concepts.


Example disclaimer for extensions that modify core components

The __________ extension has added components that, following classification, change the inferred relationships of some International concepts. These changes result in differences between the International release and the _________ edition (International release plus extension content)  with regards to taxonomy and definitions of affected International release concepts. Implementers are cautioned to be aware of these differences when inferred relationships from this edition are used in analyses or when expanding intentional refsets.


14 Comments

  1. Jim Case

    A draft disclaimer has been added.  I would appreciate comments or suggestions.  I would like to keep this short, but explicit, so word-smithing is appreciated

  2. Matt Cordell

    Short response looks great Jim. My only suggestions is a minor change for first part of the disclaimer.
             
                 The __________ edition has added extension components that, ...

  3. Paul Amos

    Hi Jim,

    My comments are below - apologies, did this a couple of weeks ago by return but to the no-reply address!!

    --------------

    Hi Jim,

    The only change I might suggest is to the following in the first paragraph:

    'change the inferred relationships of some International concepts'

    Suggested change:

    'change the inferred relationships of some concepts within the International release'

    Appreciate it adds a few words but think it might be more explicit.

    My final comment is; do we know for sure whether these changes may could result in a patient safety risk. If there is, should we advise a patient safety risk assessment?

    Best wishes

    Paul

  4. Daniel Karlsson

    Sorry for coming in late in this particular discussion thread but I find these rules way too permissive. E.g. this would allow extensions to remodel | Clinical finding | as a | Procedure | by adding two lines of RF2. If this is necessary at this stage due to circumstance X and Y (I'm not convinced) then there should be a plan for when and how to replace these rules with a better solution.

    Also, scrapping the international interoperability claims of SNOMED CT seems (at least!) like a GA decision.


    1. Jim Case

      Daniel,

      While the allowable modifications do seem to be excessively permissible, they also rely on the consensus acceptance of the general editorial principles and "good vocabulary practice".  The claim of international interoperability really only applies to the International release anyway, as the addition of realm specific content is, by its very nature, not internationally interoperable.  However, to ensure that we are clear that it is not the wild west out there, I have added a new section that explicitly states what is NOT allowed.  Feel free to suggest other line items, but the goal is to allow extensions to overcome the current issues that prevent them from providing their implementers the content that they need.

      One of the goals of this is to "institutionalize" what is already occurring in various NRCs to meet their customer needs.  

      1. Daniel Karlsson

        Hi Jim and All,

        the main difference here is that we now allow changes to things which make the International release no longer internationally interoperable. I do think that additional rules can be set up to deal with situations where this is (as I understand from the discussion) a necessary evil. Those rules could include:

        • Whenever an extension contains content which effectively lead to changes to the stated form of the international release this must be reported to SNOMED International.
        • Such reports must include a problem description and a conditional timed deprecation plan (given that problem X is solved...). Reports should preferably also include suggested changes to the International release to address the problem circumvented through the changes applied.

        1. Jim Case

          Daniel,

          To be a little more precise, the allowance does not change the international release at all.  What does change is the inferences in the national edition, which may result in inference changes within that edition.  If I exchange an international concept with someone who is using either only the international edition or another national extension that may have its own edition with changes to the international release, then that concept would appear within that edition as modified by that extension.  There would be no visible changes to users of only the international release as the concept ID would be interpreted based on the release being used.

           I agree with your statement (almost completely) that "Whenever an extension contains content which effectively lead to changes to the stated form of the international release this must be reported to SNOMED International." I think that is explicitly stated in the document.  However, I think that most of these would be resolved as high priority requests within an editorial cycle as opposed to having a specific new process to resolve.  They would be no different than the error corrections we currently receive. 

          1. Daniel Karlsson

            Ok, I might have misunderstood third bullet, top of page 4 as it was at the extension managers discretion to report changes. I still do think that a deprecation plan should be mandatory, i.e. when will the release be back in line and what are the consequences of the deviation.

            1. Jim Case

              Some of the deviations that an extension requires may not internationally applicable, which would be the reason ti might not be reported

              1. Daniel Karlsson

                Do you have examples?

  5. Matt Cordell

    I like the idea of Extensions submitting the list of changes. Additions+Inactivations. Escpecially if the IDs for additions are retained (big grin)

    An example of an exception, might be if an extension creates an intermediate primitive that is of no interest to others and not promoted.

    The interoperability scenario exists already, even in the absence of any extensions. It's not uncommon for two systems to be running different versions of the terminology. Say January 2017 & July 2017. Depending on sender/recipient there may be unknown or inactive codes received by either system. Similarly the same query may produce different results from each system.

    I agree with Jim's comment about assuming everyone adheres "general editorial principles" and "good vocabulary practice". There's an inherit risk with extensions simply existing that crazy could be done. Even without touching International concepts, an extension could create concepts that violate the concept model.

    1. Daniel Karlsson

      The example would be great use case for GCIs, avoiding need for these kinds of changes.

      Isn't the idea that we're trying to limit craziness? "General editorial principles" and "good vocabulary practice" are vague statements unless there are also clear(er) rules. We cannot avoid issues that might require prompt resolution in extensions, but we can at least limit the consequences by providing some predictability.

      1. Jim Case

        We attempt to document the "general editorial principles" in the SNOMED Editorial guide.  There are some things that we might not cover, but the general rules for how to add content properly are there for everyone to see.  While I admit there is some craziness out there, there is little we can do to stop it or enforce it. But at the same time, due to constraints that we need to have in order to maintain as much integrity as possible in the international release, there will be times when extension will need/want to add things that we don't want in the International release.  Some examples include the pre-coordination patterns that we have not accepted and, if added to extensions, might impact international concept inferences.  

        As far as I know, we have not discussed how to handle abuse of the terminology by an extension namespace holder.  Might be an interesting discussion. 

  6. Elaine Wooler

    Hi apologies for the delay in getting feedback to you.  I have been collating comments which can take some time and discussion.  I have a spreadsheet of comments but don't have permission to attach that here so will send separately.  A summary is below:

    1. Concerns were raised with the liberal approach suggested to extensions modifying core content that deviation between the international and national release may persist.  The product would therefore not meet the Desideratum of ‘multiple consistent views’ [1].  SNOMED International needs to address the risk of divergence resulting in persistent inconsistencies between international and national data.  This would have implications for international suppliers.
    2. Existing SNOMED International documentation is at odds with this permissive approach as the proposal to allow extensions to modify international components conflicts with the following documented statements from SNOMED International:
          • The organization responsible for managing and maintaining components in a module, is the organization that created that moduleId.
          • A component can be moved from any Extension to the International Release without a change to its SCTID .
          • A component can be moved from an Extension to a parent or ancestor Extension without a change to its SCTID .
          • A component can be moved from the International Release back to its originating Extension without a change to its SCTID.
          • Components that originated in the International Release must not be moved to any Extension without a change to the SCTID.

    This calls in to question exactly what a module signifies for any given component which needs to be answered by SNOMED International.

    1. UK opinion is divided however:
        • The UK pharmacy data cannot integrate with the international data unless changes are made to the international data itself , so we need to support change freedoms.
        • Certain change types (including some of the pharmacy changes) fundamentally change the knowledge published in the international data, challenging not unreasonable assumptions (tacitly and explicitly promoted in SNOMED CT) about the nature of the international product and how it might be used – as raised in Item 1 above.
    2. It is suggested that SNOMED International add to any proposal text that clarifies what is expected of suppliers:
      • If you are using data in a jurisdiction that makes any change to particular component types in international data, and if you have products written and tested against these component types in the international data, then these products must be re-tested and potentially revised when used within that jurisdiction.
      • This would then allow changes such as those that are required for pharmacy but suggests that they should say what has been changed.

    [1] https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3415631/

    Many thanks

    Elaine