2023-04-03 - TRAG Meeting Agenda/Minutes

1

Welcome!

All

Thanks to our members for all of their help. Welcome to our observers!

INTRODUCTIONS...

We've got several topics that we've resolved and closed down

As always, we won't waste time going through them again in detail, but if you'd like to read through them they're listed below...  

I'll also run through them very quickly from a high level, and if you have any further questions/news on any of the discussions please let me know now and we can decide whether or not to re-open them...

2

Conclusion of previous Discussions topics

3

MedDRA Production release

The first SNOMED CT MedDRA Simple Map package Production Release will published on 30/04/2021

This will include 2 maps - full details will be included in the Release Notes.

4

The possibility of updating inactive content

All

https://projects.jira.snomed.org/browse/MSSP-1670

Please see the ticket above for full explanation - in brief:

• Descriptions in the 20220731 International edition snapshot description file appear to contain ASCII Character 160 for Non-breaking space, when the character should be ASCII 32 for a standard space. ASCII Character 160 could potentially create issues with ETL processes.

• The suggestion is that issues caused by non-printable ASCII / UNICODE / UTF-8 characters need to be covered under their own policy because simple inactivation does not resolve the issues caused by these characters in ETL and interoperability processes.

• Unfortunately removing these characters from inactive content contravenes our current policy, which is to only update inactive content (whether this be via the AP or via a back-end fix by the tech team) where a "critical issue" has been found. The term "critical" is used specifically to clearly denote only those issues which present risks such as clinical patient-safety or legal liability, for example.  Therefore, in order for us to flag up these inactive records as a clinical safety issue, we'd need evidence of reports from users explaining how they present such a risk to their patients.  

• Confirmed by the content team that validation for non-breaking spaces is in place already for active content, and so no improvement to validation is required.

• From what we can tell, many of these have been in the release for years now, but we have not received any feedback that it has caused an issue thus far. This is therefore not a "critical" issue - however we'd appreciate community to confirm if there would be any issues with making the fixes directly on inactive descriptions?

• The following Descriptions in the 20220731 International edition snapshot description file were found to contain ASCII Character 160 for Non-breaking space, when the character should be ASCII 32 for a standard space. ASCII Character 160 creates issues with many ETL processes.

• All of these issue are in inactive descriptions:

•  

  ID Column Issue
  2869833013 [term] Code:160, Position:27
  2870804019 [term] Code:160, Position:27
  2871691013 [term] Code:160, Position:16
  2880511019 [term] Code:160, Position:21
  2880958016 [term] Code:160, Position:118|Code:160, Position:149
  2881152012 [term] Code:160, Position:118|Code:160, Position:124
  2882107012 [term] Code:160, Position:118|Code:160, Position:149
  2882999016 [term] Code:160, Position:118|Code:160, Position:124
  2884068015 [term] Code:160, Position:21
  3030804017 [term] Code:160, Position:30
  3030901012 [term] Code:160, Position:30

• The suggestion is that "issues caused by non-printable ASCII / UNICODE / UTF-8 characters need to be covered under their own policy because simple inactivation does not resolve the issues caused by these characters in ETL and interoperability processes. Given the amount of inactive SNOMED content present in the data stream, it would be best if these characters could be removed entirely from even inactive descriptions. While working in healthcare implementations, the presence of ASCII Character 160 (non-breaking space) in the LOINC descriptions broke the entire ETL process between the data warehouse and Research databases and required me to jump through some programming hoops to remove these characters from the LOINC descriptions."

• Whilst we appreciate the impact that these characters might have on ETL processes,  from a content team perspective, this is not a critical issue.  All of the current issues are related to inactive descriptions and validations are in place to prevent this from occurring in the future. 

• Unfortunately removing these characters from inactive content contravenes current SI policy, which is to only update inactive content (whether this be via the AP or via a back-end fix by the tech team) where a "critical issue" has been found.  The term "critical" is used specifically to clearly denote only those issues which present risks such as clinical patient-safety or legal liability, for example.  Therefore, in order for us to flag up these inactive records as a clinical safety issue, we'd need evidence of reports from users explaining how they present such a risk to their patients.  

• SI are always reluctant to change SNOMED CT history. However, there are situations where we have had to do that in the past. We are therefore bringing this to the TRAG for consideration...

• A couple of people thought it might be easier to update the inactive content rather than getting repeated complaints over the years - however the vast majority disagreed, and thought that not only was it a waste of valuable resource to update inactive content, but more importantly actually contravened the spec at this level!  This is because the INT Edition specifies itself as a UTF-8 format, and the ASCII 160 characters are UTF-8 compliant!  Therefore where would we stop once we start excluding certain UTF-8 characters from the INT Edition? 

• Instead, it should be the responsibility of the end implementations to exclude any characters that disagree with their ETL routines/programs.

• Repsonse added to https://projects.jira.snomed.org/browse/MSSP-1670

• TRAG RECOMMENDATION WAS TAKEN - our SI specs specify UTF-8 format, and as ASCII 160 characters in question are UTF-8 compliant, any changes would be contravening our own specifications.  Therefore all were agreed that no changes should be made in the content - instead it should be the responsibility of the end implementations to exclude any UTF-8 characters that cause issues for their ETL routines.

5

AttributeValue field immutability in the RF2 files

ALL

Just a very quick one (especially for those who were in the MAG yesterday and have already heard this!) - the immutability of the valueID field is specified as being "depends on specific use" - see here:

• 5.2.1.3 Attribute Value Reference Set

The MAG are all happy to change this to "mutable", and so are we - however I just wanted to give those here who weren't in the MAG a chance to raise a valid objection in case anyone can identify a really strong reason why this field shouldn't be mutable??

No objections raised

6

Active Discussions for April 2023

7

Welcome and thank you!

Welcome to new members!

8

Member Nominations

Please let us know if anyone is interested (and who has the requisite domain knowledge and expertise) in applying for a seat on the TRAG - thanks!

We're looking for new members to take the place of some outgoing chairs - if you have any Nominations please let me know either this week or by email after.   Thanks!

9

Derivative product Release package formats

Kai

The SI Standards for Derivative packaging formats (and therefore the precedents set for all existing Releases such as MedDRA, GMDN, etc), are that we create packages that are inherently dependent on the relevant International Edition package (as per the MDRS). 

These Derivatives are solely single refsets/maps, and so don’t mean anything to the end users without the supporting terms and other components from the International content. 

This is why we have always created the metadata components (refset/module concepts, descriptions, relationships, etc) in the International content, and then made the Derivatives dependent on the relevant International Edition.

Recently however, during the creation of the new EDQM maps, the question was raised as to whether or not we should change to include the metadata concepts in Derivative packages themselves, rather than in the International Edition.  This would not make them stand-alone (like the IPS sub-ontology for example), as they would still be dependent on the International Edition.

However, as a Derivative with its own module there may be benefits of the package containing its own metadata concepts?

The main benefit so far identified has been to avoid the situation experienced in the EDQM Alpha release:

• the metadata for the EDQM product was published in the December 2022 International Edition,

• and so the EDQM map content was upgraded in line with the December 2022 International content.   

• the maps themselves however were not updated, and were still based on July 2022,

• but the release itself was dependent on the December 2022 International Edition.  

• this created a slight contradiction in terms of the map release which appeared to be based on December 2022, but actually the metadata itself was the only thing baselined on this release.  The content was only brought up to date with the July 2022 release.

• Having said all this, the flip side is that if we just push the collaborators to request the metadata to be added to the International Edition at an earlier time, then this situation can also be avoided!

HOWEVER, is it possible that the issue below in the RT2 release process could also be mitigated by moving the metadata into the Derivative packages themselves?  If we did this, could we potentially then retain the Derivative content in the Refsets' child branches and release from there?

(eg) 

• For GPFP we would maintain the content via the RT2 FE which would read/write to MAIN/Refsets/GPFP

• Given that we would then also include the Module + other metadata in the same branch (instead of in MAIN),

• ...Could we then version say into MAIN/Refsets/GPFP/2023-04-30, and Release straight out of that branch??

Changing the way we do things currently would take some work, and so would require a strong business case in order to 

a) Change our standards

b) Incur the cost of making the technical + release changes

Thoughts on the original decision to package them in this way?

Thoughts on the benefits/risks of refining this standard?

•  

  YES - we need to put a proposal forward to:

  a) DEMOTE the various Derivative metadata components down from the INT Edition in the July 2023 Release

       (this would simply involve inactivating them all in the International Edition)

  b) PROMOTE  them in the various Derivative packages in the Sept/October 2023 Derivative releases.

       (this would simply involve activating them in the relevant Derivative packages)

  ********* SEE OPTION 2 in the Refset  processes in the post-RT2 agenda item for FULL proposal ******

   

10

Refset  processes in the post-RT2 world

All

Options to be discussed (see local Notes "RT2 New Process")

MAIN POINTS:

• The International Derivative releases have always been dependent on Jan/July, in order to align with the fact that most end users still only take the Jan/July releases, and not the other monthly releases.

• The new RT2 integration with snowstorm branches greatly improves the quality, because it allows the authors to run full validation against the new derivative content BEFORE promoting, thereby allowing identification + fixing of most issues before they hit the Release cycle. (eg)

  • MAIN/Refsets/GPFP,   MAIN/Refsets/ICNP,  etc

• However, in order to actually RELEASE these derivative products, we’ll need to Promote the Refset content up to MAIN/ (as the metadata content is in the International Edition, and we can’t currently export content from multiple snowstorm branches into SRS for the same release, just from one branch)

• Before you’re allowed to promote in the AP, you HAVE TO re-base and validation FIRST

  • The re-base process will pull the content through from the LATEST International content in MAIN, which may include monthly content from later releases than the recent JAN/JULY release that we originally wanted to base the Derivative release upon!

• This makes it inherently less flexible in terms of preventing re-basing against later monthly International releases, and therefore extremely difficult to retain dependency on JAN/JULY releases.

OPTIONS:

1. BEST option appears to be to allow the Derivative refsets to be dependent on the month prior to that in which they're Published (eg) March/September for most derivatives.

2. However, is it possible that if we were to make a different decision on the item above, then this issue in the RT2 release process could also be mitigated by moving the metadata into the Derivative packages themselves?  If we did this, could we potentially then retain the Derivative content in the Refsets' child branches and release from there?

   (eg) 

   • For GPFP we would maintain the content via the RT2 FE which would read/write to MAIN/Refsets/GPFP

   • Given that we would then also include the Module + other metadata in the same branch (instead of in MAIN),

   • ...Could we then version say into MAIN/Refsets/GPFP/2023-04-30, and Release straight out of that branch??

3. The final option is moving to Monthly releases for Derivative products as well - however:

   1. This is problematic from a capacity/practical point of view, and

   2. This would require significant discussions with all of our collaborating entities to sign off on new agreements (for those who have tangible inputs into the process), including monthly deadlines, etc - This could not be achieved quickly so would need to be discussed with 2024 in mind at the earliest. 

      1. The alternative to this would be to move just SOME of the derivatives (the straightforward refsets for example which don't require much/any external collaboration) to monthly schedules, and keep the others on annual/6 monthly schedules.

      2. However, this would be a significant operational issue, as the processes are already complex enough without introducing further complexity in terms of different derivatives runing on completely different processes.

We should discuss options and agree the best way forward for retaining quality within the Release process vs impact to the users.

11

Community Consulation: Proposed changes to the RF2 Identifier File Specification

All

Full details can be found in:  SNOMED International Proposal to change the RF2 Identifier File specification

Main points for TRAG consideration:

• Proposed Changes to RF2 - any issues with the proposal?

  The current column headers for this file are:

  The new proposed format is:

  The data types will remain the same, as detailed in the current RF2 specification:  4.2.4 Identifier File Specification   

• Perceived Impact - is this the case?

  This change is not expected to have any impact on implementers of existing systems, as SNOMED International are not aware of organisations who currently represent entities from other code systems directly in SNOMED CT, as opposed to mapping to it.   As such, consumption of the new file would only be required by organisations who have an interest is working with such content.

• FEEDBACK - Walk through the feedback received so far and confirm if any further points?

  • SNOMED International Proposal to change the RF2 Identifier File specification

Feedback requested:

12

IPS Terminology Product

All

Quick run through of the changes that we're proposing to make in the final Production release in Q4 2022, as compared to the BETA release

(ie) discussion of the feedback that we accepted and have implemented in the Production release:

1.  INCLUSION OF THE “EML” (new Drugs refset) IN THE FEEDER FOR THIS PRODUCT FROM 2022 ONWARDS

2. IPS Terminology URI:

• The terminology code system & code system version used to refer to the IPS Terminology are shown below:

  • Code system

    • coding.system = "http://snomed.info/sct"

  • Code system version

    • coding.version = "http://snomed.info/ips/999991001000101"

    • coding.version = "http://snomed.info/ips/999991001000101/version/<publicationDate>"

    • e.g. "http://snomed.info/ips/999991001000101/version/20220430"

         *** PLEASE SEE SECTION E here for final solution:

• • Using a Terminology Server 

ACTIONS:

13

SNOMED Release Package causing file path length issues in Windows environments.

@Patrick McLaughlin @John Snyder 

WEDNESDAY (MEETING 2) WHEN US NRC IS IN ATTENDANCE:

• The base file name is 63 characters:  SnomedCT_ManagedServiceUS_PRODUCTION_US1000124_20230301T120000Z.zip

• When the zip package is decompressed on a windows based computer using 7zip, the base folder name is the same length as the zip package file name:

• Drilling down into the second level directory, we see that the base folder is duplicated:

• The user must click through the duplicate folder before actually getting to the Full and Snapshot folders:

• •  

• The duplicated folder is easily viewable when looking at the file path.

• • C:\Users\snyderjw\Desktop\SNOMED\

  • ...SnomedCT_ManagedServiceUS_PRODUCTION_US1000124_20230301T120000Z\...

  • ...SnomedCT_ManagedServiceUS_PRODUCTION_US1000124_20230301T120000Z

• To access files in the release package, the SNOMED path and file name can reach up to 218 characters.

• • ..\SnomedCT_ManagedServiceUS_PRODUCTION_US1000124_20230301T120000Z\...

  • ...SnomedCT_ManagedServiceUS_PRODUCTION_US1000124_20230301T120000Z\

  • ...Snapshot\Refset\meta\