Edition vs Extension Packaging Naming conventions

SNOMED Groups Terminology Release AG
,
1

As a result of the gradual move towards more Editions, we now have a requirement from various Members to publish BOTH Edition and Extension packages.

In order to support this, we need to differentiate between those 2x types of packages in the Package Naming Conventions.

The Release Package Naming conventions already allow for this, so the question is which option people would prefer (eg)

  • Release Package Naming Conventions | SNOMED International Documents

    • So it seems obvious that we’d use the existing Optional tag in the second element (Scope (optional)) within the existing conventions, in order to denote this distinction.

    • The First question is whether to use the FULL “Edition”/“Extension” naming tag, or whether or not this might start causing problems for users with some of the already lengthy Package names

    • So the Full naming option would look like this:

      • SnomedCT_InternationalRF2_PRODUCTION_20241001T120000Z.zip → SnomedCT_InternationalRF2Edition_PRODUCTION_20241001T120000Z.zip

      • SnomedCT_ManagedServiceNZ_PRODUCTION_NZ1000210_20241001T000000Z.zip → SnomedCT_ManagedServiceNZExtension_PRODUCTION_NZ1000210_20241001T000000Z.zip

      • SnomedCT_ManagedServiceNL_PRODUCTION_NL1000146_20240930T120000Z.zip → SnomedCT_ManagedServiceNLEdition_PRODUCTION_NL1000146_20240930T120000Z.zip

      • xSnomedCT_ManagedServiceKR_BETA_KR1000267_20240930T120000Z.zip → xSnomedCT_ManagedServiceKRExtension_BETA_KR1000267_20240930T120000Z.zip

      • BOTH:

        • SnomedCT_ManagedServiceBE_PRODUCTION_BE1000172_20241015T120000Z.zip → SnomedCT_ManagedServiceBEExtension_PRODUCTION_BE1000172_20241015T120000Z.zip

        • SnomedCT_ManagedServiceBE_PRODUCTION_BE1000172_20241015T120000Z.zip → SnomedCT_ManagedServiceBEEdition_PRODUCTION_BE1000172_20241015T120000Z.zip

    • Whereas the abbreviated version would look like this (this would obviously be shorter/cleaner, but the question is more whether or not it might cause confusion for those who don’t know about it?)

      1. SnomedCT_ManagedServiceBE_PRODUCTION_BE1000172_20241015T120000Z.zip → SnomedCT_ManagedServiceBEExt_PRODUCTION_BE1000172_20241015T120000Z.zip

      2. SnomedCT_ManagedServiceBE_PRODUCTION_BE1000172_20241015T120000Z.zip → SnomedCT_ManagedServiceBEEd_PRODUCTION_BE1000172_20241015T120000Z.zip

    • The Second question is what to do about Derivative Release packages? Do we:

      • 1. Name them as Extensions? (eg) SnomedCT_SNOMEDOrphanetMapPackageExtension_PRODUCTION_20241031T120000Z.zip

      • 2. Name them as Derivatives? (and add a new option into the Package Naming Conventions) (eg) SnomedCT_SNOMEDOrphanetMapPackageDerivative_PRODUCTION_20241031T120000Z.zip

      • 3. Keep them the same, and just retain the “Optional” status of this tag? (eg) SnomedCT_SNOMEDOrphanetMapPackage_PRODUCTION_20241031T120000Z.zip

      • TREAT THEM AS DERIVATIVES (and use this naming convention, as in option 2 above) AS THEY ARE PRACTICALLY DIFFERENT FROM EXTENSIONS (even if not technically) BECAUSE YOU CAN BOLT ON A DERIVATIVE PACKAGE TO AN EDITION RELEASE WITHOUT HAVING TO RECLASSIFY OR REBUILD THE PACKAGE - BUT AN EXTENSION BEING ADDED IN REQUIRES RECLASSIFICATION, REVALIDATION etc

    • .

    • INITIAL FEEDBACK (Oct 2024):

      1. All agreed to proceed with the new naming convention

      2. Derivatives - use “Derivative” +

        1. AAT to SOCIALISE FIRST

        2. AAT to then Add it into the Release File Spec (no need to change Release Package Naming conventions, as they already allow for this)

        3. AAT to then start changing naming conventions accordingly in Production releases, from an agreed date in 2025 onwards…

    • TRAG TO COMPLETE A PROPOSAL IN October 2025, INCLUDING:

      • JSON file

        • The intention would be to also include a new computer-readable tag in the JSON file so that everyone can automatically assess the package, without relying solely on the package name?

        • Unless this would be a problem for anyone?

        • What would be the prefered format for this?

          • Should we add a new tag into the top level of the structure?? (eg)

            • {
              “effectiveTime”: “20240701”,
              “previousPublishedPackage”: “SnomedCT_IPS_PRODUCTION_20231031T120000Z.zip”,
              “PackageType”:“EXTENSION”

            • “licenceStatement”: “”,
              “languageRefsets”: [
              {
              “id”: “900000000000508004”,
              “term”: “GB English”
              },
              {
              “id”: “900000000000509007”,
              “term”: “US English”
              }
              ],
              “packageComposition”: {
              “essentialComponents”: {},
              “optionalComponents”: {}
              }
              }

          • OR should we add it in lower down in the hierarchy?

            • {
              “effectiveTime”: “20240701”,
              “previousPublishedPackage”: “SnomedCT_IPS_PRODUCTION_20231031T120000Z.zip”

            • “licenceStatement”: “”,
              “languageRefsets”: [
              {
              “id”: “900000000000508004”,
              “term”: “GB English”
              },
              {
              “id”: “900000000000509007”,
              “term”: “US English”
              }
              ],

            • “packageComposition”: {

            • "essentialComponents": {

            •             **"PackageType":"EDITION"**

            •                                                    },
"optionalComponents": {
           "SNOMEDMapSource": "SNOMED CT version 20240701, released July 2024",
           "externalMapSource": "EDQM version January 2024",
           "MapDirectionality": "Map file der2_sRefset_EDQMtoSNOMEDSimpleMapSnapshot_INT_20240701.txt is mapped from EDQM to SNOMED CT."

            • HIGH LEVEL IN THE HIERARCHY

      • TIMELINE:

        • URGENT CHANGE, BECAUSE IT WILL BRING SIGNIFICANT BENEFITS BOTH TO:

          • Automated processes, to allow reliable machine-readable identify Editions/Extensions

          • Manual processes, to allow for human readable identification

        • THIS TAKES ADVANTAGE OF AN EXISTING OPTIONAL ELEMENT IN THE FILE NAMING SPEC

          • - so NO change to spec, just use of unused feature!

        • Do we need to socialise this and provide a significant window of time for people to prepare?

          • Obviously this could have a significant impact on the users who import and consume packages, esepcially if routines have been hardcoded…

        • .

        • Or can we just publicise that we’re going to go ahead with the changes asap?

          • .

        • In either case, what timeline are we talking about?

          • Can we do it immediately, or should we propose that we change it as of, say the July 2026 release?

          • .

          • Or do we need even longer run up to it in order to allow for those who may need to change their systems?

      • SEND OUT WARNING COMMS FOR ???JAN 2026/JULY 2026??? WITH CAVEAT THAT “IF ANYONE HAS CRITICAL OBJECTIONS TO THIS PLEASE RAISE NOW”

        • THEN ASK UK TO PUT OUT BRIEF REQUEST (linking in our comms) TO ASK THEIR USERS IF ANY OBJECTIONS
        • THEN FINALLY SEND OUT CONFIRMATION THAT WE WILL TRANSITION IN ???JAN 2026/JULY 2026??? …

  • TRAG Proposal to then be shared with the Member Forum with a target timeframe for making the changes (informed by conversations in TRAG and the eventual scope/detail of the changes)

    • For the target timeframe to include a period of time to allow Member Forum Representatives opportunity to engage and seek feedback from users to determine if they can manage the changes by the target timeframe set.

  • MF to the be advised of the Proposal, review it and respond within the timeline