2024-04-15 - TRAG Meeting Agenda/Minutes

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...

Conclusion of previous Discussions topics

Annotations - Release Dates

ALL

The release date depends on two factors:

1. Firstly, the authoring platform being ready for annotations (which will be November 2023)

2. Secondly, content authored for annotations. Language tags only involve about 8 concepts under 900000000000506000 |Language type reference set (foundation metadata concept)|. The attribution could be done by technical batch changes.

Because of the change to release date (to the 1st of the month), it is therefore unlikely to be possible to prepare everything in time for the December 2023 release. We are therefore currently aiming for the January 2024 releases - as this will also provide the largest audience for these major new changes (as opposed to Feb/March which most users still do no consume).

Annotations - refsetDescriptor records

ALL

Once we've agreed the filenaming conventions, we also need to quickly confirm that everyone is happy with the Attribute Types + Descriptions that will be applied to them in the refsetDescriptor files - as this is all automated now, and so I need to verify that it creates the refsetDescriptor records with the desired attribute types, descriptions, etc 

• we have included the descriptor records for these new refsets in the document:

  • SNOMED CT Annotations

Annotations - file naming conventions

ALL

Now that we've got the Language Code approach confirmed, we need to agree the file naming conventions for the 4x new refset types that will be included in the International Edition going forwards (although only the 2x String Value refsets will now be introduced initially - see below).

The four planned refsets are as follows:

• 1292996001 |Member annotation with component value reference set (foundation metadata concept)|

• 1292995002 |Member annotation with string value reference set (foundation metadata concept)|

• 1292994003 |Component annotation with component value reference set (foundation metadata concept)|

• 1292992004 |Component annotation with string value reference set (foundation metadata concept)| 

So they will be held in the /Refset/Content /Refset/Metadata subfolders, and the initial naming convention would suggest something along the lines of:

• der2_sscsRefset_MemberAnnotationComponentValueSnapshot_INT_[date].txt

• der2_sscsRefset_MemberAnnotationStringValueSnapshot_INT_[date].txt

• der2_scsRefset_ComponentAnnotationComponentValueSnapshot_INT_[date].txt

• der2_scsRefset_ComponentAnnotationStringValueSnapshot_INT_[date].txt

However we're happy to take any feedback on these before finalising them?

FYI We've decided to release the first 2x definite refsets (as empty files only for now) into the December 2023 Release, in order to trial it and get people used to them - we may introduce the other 2x in future releases if required:

• der2_sscsRefset_MemberAnnotationStringValueSnapshot_INT_[date].txt

• der2_scsRefset_ComponentAnnotationStringValueSnapshot_INT_[date].txt

In addition to this, we need to roll out the new refsets to all SNOMED Products - for example, National extensions will create their own annotation attributes and values in addition to those we have covered in the annotation document, such as information about medicinal products.   Other examples include the category annotation attribute for LOINC, which could belong to the LOINC module. 

We would therefore be looking to use conventions like this for Extensions:

• der2_sscsRefset_MemberAnnotationComponentValueSnapshot_[CountryCode + Namespace]_[date].txt

• der2_sscsRefset_MemberAnnotationStringValueSnapshot_[CountryCode + Namespace]_[date].txt

• der2_scsRefset_ComponentAnnotationComponentValueSnapshot_[CountryCode + Namespace]_[date].txt

• der2_scsRefset_ComponentAnnotationStringValueSnapshot_[CountryCode + Namespace]_[date].txt

And conventions like this for Derivatives:

• der2_sscsRefset_[derivative name]MemberAnnotationComponentValueSnapshot_INT_[date].txt

• der2_sscsRefset_[derivative name]MemberAnnotationStringValueSnapshot_INT_[date].txt

• der2_scsRefset_[derivative name]ComponentAnnotationComponentValueSnapshot_INT_[date].txt

• der2_scsRefset_[derivative name]ComponentAnnotationStringValueSnapshot_INT_[date].txt

(eg)

• der2_sscsRefset_OrphanetMemberAnnotationComponentValueSnapshot_INT_20240131.txt

• der2_sscsRefset_OrphanetMemberAnnotationStringValueSnapshot_INT_20240131.txt

• der2_scsRefset_OrphanetComponentAnnotationComponentValueSnapshot_INT_20240131.txt

• der2_scsRefset_OrphanetComponentAnnotationStringValueSnapshot_INT_20240131.txt

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.

Proposal to change the International Monthly release dates to the 1st of the month

ALL

PROPOSAL:

• We have had multiple instances recently of concepts being promoted to the International Edition before they were officially Published. This has then had the effect of introducing duplicates into the Extensions, as the concepts have been Published on the same date - for example on 31st of the next month, when both the local concept was Published in the Extension + the promoted concept was Published simultaneously in the International Edition, both with the same effectiveDate.

• There is no way to extend the RVF validation to cover this scenario, as the two Releases are completely distinct, due to the relevant Extension releases being dependent on International Edition packages from far before the invalid promotion occurred.

• We are, therefore, introducing manual validation at the point of Promotion, to try and catch any such invalid CRS requests at source, before they are promoted.

• However, as this is a manual process it still has vulnerabilities, and so we are planning to move the International Edition releases to the 1st of each month, instead of the last day of each month.  This would prevent the vast majority of clashes with Extensions that are normally published on the last day of the month as well - the only remaining risk would be the USA which is published on 1st March and September each year.

• We cannot predict any risks or potential downsides to moving to the 1st of the month, and so we will be moving ahead with this once we have sent out communications and given the community a reasonable notice period to prepare for the change.  Therefore, please let us know immediately if you can foresee any potential issues with this proposal, or have any valid business reasons why this change will have a negative impact?

• October 2022 - EVERYONE ON BOARD!!!

• HOWEVER, WE NEED TO ENSURE THAT IN ORDER TO PREVENT CONFLICTS, WE ARE NOT JUST MOVING THE DATE TO 1st OF EACH MONTH, BUT ALSO THAT THE SNAPSHOT CALCULATION INCORPORATES ModuleID CONSIDERATIONS AS WELL AS MOVING THE DATE 

• April 2023:

• Latest plan is to transition in August 2023, so the International Edition Release schedule would be:

  • 30th June 2023

  • 31st July 2023

  • 1st September 2023

  • 1st October 2023

LOINC Extension Alpha release

All

The Alpha release of the new LOINC Extension was deployed by Regenstrief recently - has anyone used it yet?  

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:

Community Consulation: Proposed changes to the Spanish Edition delivery timelines

Guillermo / Alejandro

We are considering refining the delivery timelines for the Spanish Edition release. Currently it's published twice a year, on 30th April and 31st October.

We are considering various options, including (but not limited to):

1. Early publication - retaining the dependency on the January/July International Edition content, but bringing the Spanish Edition release date forward to either

   1. 28th February and 31st August, or

   2. 31st March and 30th September

   3. Pros:

      1. This will reduce the version offset between the International and Spanish Editions, which may be the primary goal of the end users? (confirmation of this and in particular evidence as to why this is currently a problem for them would be useful in order to make this a priority....)

      2. This will also retain the standard January/July baseline on the International Edition content

   4. Cons:

      1. This would be dependent upon delivery to SI being completed by either a) 15th Feb and 15th August, or b) 28th Feb and 31st August respectively (at the latest), due to conflicting MS priorities in March/September.  The translation suppliers would therefore need to be comfortable with the ability to meet these timelines between the new monthly International release dates of 1st Feb + 1st August (for the Jan/July releases) and the end of the month.

         1. NOTE:  The timelines are shorted in the case of option a), as we have more capacity to drive the SE through in February/August than we do in March/Sept

      2. Significant increased risk to delivery timelines, due to March/September being extremely busy months for the Managed Service and Derivative releases.  Complex  and time-consuming releases such as US, NL, NZ, coupled with the build and validation of all Derivative releases in these months, make adding additional overhead to this month extremely risky.

      3. Significant increased risk to quality of content, as any issues found may be identified too late to be resolved in the current cycle, and would therefore need to be carried over  as Known Issues to be fixed in the next release.  This may be a concern for the end users.

2. Retaining the dependency on the January/July International Edition content, retaining the April/October release dates for the Spanish Edition, but allowing more time for translation each cycle (this would therefore only require delivery to SI being completed by 31st March and 30th September respectively).

   1. Pros:

      1. This will provide more time time for translation suppliers to translate all International Content.

      2. This will guarantee delivery timelines, and content quality by providing enough time to resolve issues in the current cycle.

      3. This will also retain the standard January/July baseline on the International Edition content

   2. Cons:

      1. This will NOT reduce the version offset between the International and Spanish Editions, which may be the primary goal of the end users? (confirmation of this and in particular evidence as to why this is currently a problem for them would be useful in order to make this a priority....)

      2. This additional time may not be useful, as the Translation suppliers are already managing to deliver slightly earlier in the cycle.

3. Retaining the April/October release dates for the Spanish Edition, but bringing the dependency of the Spanish Edition forward, allowing it to be baselined on a later International Edition - for example February and August.  

   1. Pros:

      1. This will reduce the version offset between the International and Spanish Editions, which may be the primary goal of the end users? (confirmation of this and in particular evidence as to why this is currently a problem for them would be useful in order to make this a priority....)

      2. This would be dependent upon delivery to SI being completed by 31st March and 30th September respectively.

      3. This would therefore still provide enough time to guarantee delivery timelines

      4. It would also ensure content quality by providing enough time to resolve issues in the current cycle.

   2. Cons:

      1. Changing the dependent International content may not be as palatable to the end users, as they would need to be careful as to which International Edition to download in conjunction with the Spanish Edition.

OPTIONS TO BE DISCUSSED AND ONE PROPOSAL TO BE AGREED, SO THAT WE CAN DISSEMINATE TO THE COMMUNITY AND TRANSITION AS SOON AS POSSIBLE.

Annotations - outcome of today's MAG discussions

1. Language code to be removed from the implementation entirely - they're extraneous at present, and no valid use case is apparent at present.  Therefore the preference is to simplify the current implementation wherever possible, and manage any language considerations using the moduleID for now.

2. Agreement on the distinction between data and metadata - for now we will use the new refsets to annotate metadata only, and data will be addressed using additional relationships.  Only remaining question will then be how to distinguish between what is technically data vs metadata!

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

Active Discussions for October 2023

Welcome and thank you!

Welcome to new members!

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!

Association Relationship file

All

In the MAG the requirement for the new Association Relationships (previously called "Additional Relationships") has been identified.

Although they will take the same form as the Inferred Relationships, and therefore be stored in the same format as the Inferred Rel's in the RF2 package, there was still a discussion on whether or not they should be held in the Inferred Rel's file or a completely separate file.

The arguments for retaining them in the Inferred File are:

The arguments for putting them into a separate file (with the same format as the Inferred file) are:

The arguments for the latter, therefore, appear to be more compelling, and this is the MAG's recommendation.

However, if anyone has any strong opinions either way then please raise them now?

Association Relationship file naming conventions

All

Once the above decision on the implementation of the Association Relationship records has been made, we then need to consider the naming and packaging conventions for any new files that are required.

The proposal would be to follow previous conventions, and therefore be something like this:

• sct2_AssociationRelationship_Snapshot_INT_[date].txt

• sct2_AssociationRelationshipConcreteValues_Snapshot_INT_[date].txt

Derivative product Release package formats