Republication of core module content

Pupose

The modularisation of SNOMED CT International currently causes issues for at least the Australian extension of SNOMED CT. Specifically content included on the SNOMED CT Core and SNOMED CT model component modules which is not really "core" content cannot be legally omitted in an extension's Edition publication, however use cases exist to exclude this non-core content.

The purpose of this paper is to raise awareness of this issue and look for actions which can be taken to clarify the rules for republication of modules while facilitating these use cases.

Objective

This paper has a few purposes

Clarify the rules for republication of a module within an edition - e.g. SNOMED CT Core in an extension Edition.
Have non-core content removed from the core modules to facilitate regional flexibility for extensions (and generally tidy up what has bled through)
Define rules for modularisation of non-core content published in the International Edition

Background

A module in SNOMED CT is an atomic unit of release (although I can't find anything in the specification which says this!). That is if you include a module in a release, then you need to include all of it or none of it. This stands to reason because

extensions are not supposed to modify the content of a module they extend (although there is controversy about exactly what this means...)
omitting part of a module can't be detected by a consumer without them getting the original module source - essentially this is modification by omission

SNOMED CT International consists of two main modules

SNOMED CT Core (almost all of SNOMED CT)
SNOMED CT model component (the metadata)

There are other modules shipped with the International Edition used for additional "optional" derivative works, but the main "core" modules are the two above.

This was initially an issue for extra derivative projects (ICD10 map for example) that the IHTSDO worked on and put on the SNOMED CT Core module, but mostly these have been moved to their own modules. This allows extension builders to produce an Edition with the core, their extension, and only the relevant derivatives from the International Edition for their consumers. For example it allows an extension builder to omit the ICD10 map if it should not be used in their jurisdiction to avoid confusion.

Unfortunately due to a number of historical issues and a lack of clear policy for module use, both the SNOMED CT Core and SNOMED CT model component modules have had non-core content creep into them.

Specifically the following artefacts are produced on SNOMED CT Core, and are perhaps not "core" or it may not be desirable to pass these on.

Artefact	Comments

Artefact	Comments
GB English language reference set	This is an historical oddity that both GB and US language preferences are distributed in the International Edition. I'm not sure if the UK use this reference set and/or create their own. However from an extension perspective, particularly English speaking, it is desirable to not pass on this artefact and only our en-AU language reference set to avoid any confusion or error on the part of our implementers.
US English language reference set	RF2 more or less requires a language reference set for a release to function properly, and it makes sense that it is US English which is the default language of SNOMED CT. However again, from an extension builder's perspective it is desirable to pass on only the language reference set you wish implementers to use.
Lateralisable body structure reference set	This is arguably not "core" content, however it is useful. I see no particular need for an extension release to desire to suppress this content, however strictly it isn't core.
ICD-O simple map reference set	Odd that this map isn't on its own module while the ICD10 map is. Some extension builders may want to omit it for local reasons, for example they may have their own mapping they prefer implementers to use for local reasons. (SNOMED CT-AU has no such issues with this artefact specifically)
CTV3 simple map	This historical mapping between CTV3 and SNOMED CT carried over from RF1 when RF2 was created. Again in jurisdictions with no prior use of CTV3 omitting this is the best way to ensure that implementers don't mistakenly find a use for it.
SNOMED RT ID simple map	Very much the same as the CTV3 map, although this artefact is formally being deprecated shortly anyway.
Stated relationships	This one seems silly, however SNOMED CT-AU does not publish a Stated Relationships file with its distribution. The reason for this is that the number of consumers who have requested the stated form are very, very few, compared to the implementation challenge of implementers coming to rely on the relationship patterns they find in the stated relationships file which may incorrectly appear stable. The prime example of this (and why this was done for SNOMED CT-AU) is AMT v3, which has a very structured, automated stated form which appears in some ways similar to AMT v2. For implementation transition reasons the stated form was withheld so that AMT v2 implementers didn't find something "familiar" in the stated relationships and come to rely on the patterns within them, which are subject to change, as an alternative to the DNF. This will become much less of an issue if/when SNOMED CT moves to an OWL based stated form.

Aside from these specific artefacts there is also an issue of metadata bleeding through from optional modules into the SNOMED CT model component module. For example while the content of the ICD10 map reference sets is on the appropriate module, the reference set concepts and associated metadata is on the SNOMED CT model component module. The metadata for an optional module should also be on that optional module (including the module concept itself) so there is no bleed through from the optional modules into the core. This would allow the optional modules to much more cleanly "unplug" when not loaded with the core.

Recommendation

Note this is as yet incomplete and requires collaboration, validation and feedback to refine to an actionable position! This is just a straw man first pass!

Clarify in the Technical Implementation Guide that a module is a atomic unit of release and must be included in its entirety or not at all (if this doesn't already exist somewhere I couldn't find)
Clarify that language reference sets are an exemption to the "atomic unit of release" rule in that they are jurisdictionally variable and while the module content may be valuable in another setting the language preferences aren't necessarily.
Stop publishing the GB English language reference set in the International Edition and leave this to the UK national extension (I've not checked this with the UK so at this stage this is an unvalidated purist position, needs checking with the UK)
Move non-core content from the SNOMED CT Core and SNOMED CT model component modules, specifically
- Lateralisable body structure reference set
- ICD-O simple map reference set
- CTV3 simple map
- SNOMED RT ID simple map - although this may be redundant shortly if it is removed completely
Move metadata associated with optional content (e.g. ICD10 reference set concepts) from the SNOMED CT model component module to the optional module their associated content is on
Define a set of rules for modularisation of non-core content in the International Edition, and even definition of "non-core content". These rules may be generalised to guidelines for other content producers
One rule of modularisation should be that a module should be as self contained as possible and that the creation of the module concept and all metadata required by the content on the module should also be created and maintained on that module. As promotion to a "higher" module in the dependency tree is relatively straightforward, publication at the lowest possible module should be preferred with later promotion as necessary.