2022-04-05 - TRAG Meeting Agenda/Minutes
Date
5th April 2022 - 09:00 - 12:30 GMT (08:00 - 11:30 UTC)
Room: Gallery 4-5
6th April 2022 - 09:00 - 12:30 GMT (08:00 - 11:30 UTC)
Room: Gallery 4-5
Dial in details:
Attendees
@Andrew Atkinson, Chair
@Mounir Bouzanih (Unlicensed), member
@Mikael Nyström (Unlicensed), member
@Patrick McLaughlin, member
@Alejandro Lopez Osornio, member
@Stuart Abbott (Unlicensed), member
@Matt Cordell, member
@Orsolya Bali (Unlicensed), member
@Dion McMurtrie, guest/observer
@michael lawley, guest/observer
@Reuben Daniels, guest/observer
@Suzy Roy, staff/observer
@Former user (Deleted), staff/observer
@Chris Morris, staff/observerst
Apologies
@Former user (Deleted)member
Objectives
Briefly discuss each item
Agree on the plan to analyse and resolve each issue, and document the Action points
All those with Action points assigned to them to agree to complete them before the next face to face conference meeting
Discussion items
Subject | Owner | Notes | Action | |
|---|---|---|---|---|
| 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 | Frequent Delivery Rollout | This has been completed in Q1 2022 | There were multiple sub-topics covered off here Everyone discussed and we came to conclusions that were extremely useful in the design and implementation of Frequent Delivery The transition was successfully completed with the final 6 monthly release being the January 31 2022 Release Two subsequent Monthly Releases have now been published successfully:
| |
| 4 | Orphanet Production release | The first SNOMED CT to Orphanet (Rare Diseases) Map package Production Release will be published on 30/09/2021 Full details will be included in the Release Notes. | Does anyone have any questions/issues to raise before the Production release is published later this month? No - in which case we'll proceed as planned Topic to be closed down in October 2021 TRAG meetings unless new issues are raised... | |
| 5 | COVID-19 Vaccines content | COVID-19 Vaccines content was included in the January 2021 International Edition and added to the GPS. Further important Vaccines content will be included in the July 2021 release + the September 2021 GPS release. Updates about content relating to COVID-19 can be found here: https://snomed.atlassian.net/wiki/display/snomed/SNOMED+CT+COVID-19+Related+Content | Does anyone have any questions/issues to raise before the International Edition content is finalised in a few weeks? No - in which case we'll proceed as planned Topic to be closed down in October 2021 TRAG meetings (after July 2021 Production release) unless new issues are raised. OR if there are more requirements raised for future releases in terms of COVID-19 Vaccines content... | |
| 6 | Spanish contingent | This is for discussion with all those interested in the Spanish Edition, in particular the refinement of the content and the processes behind the feedback procedure. | The SECRS project is now in full use each cycle, to propose new changes to the Spanish Edition content, that get picked up, discussed and actioned accordingly by termMed in advance of each release. We then use these tickets as another baseline for validation of the Spanish Edition release packages. Please let us know if anything is not working as expected, so that we can refine this new process? Topic to be closed down in October 2021 TRAG meetings unless new issues are raised. | |
| 7 | All | This consultation period has closed, so we just want to ensure that there are no other questions/considerations to be discussed before closing it down? | Comments and feedback welcomed... Matt Cordell confirmed he received the answers required, so no further feedback Nothing further to discuss from anyone else either, and so topic to be closed down in October 2021 TRAG meetings unless new issues are raised. | |
| 8 | URGENT: CONCRETE DOMAINS Consultation + * MAG crossover | All | The short term proposal of precoordinating the numbers and measures as concepts (and therefore not changing the RF2 format) was generally well accepted, though there were concerns raised regarding the longevity of this approach, and whether or not this addresses the original target of the project (which was to allow a standardised approach across all extensions, instead of perpetuating distinct coding for different users). The other concern raised was that any solution needs to be implemented rapidly, as otherwise the various members will be forced to start/continue implementing their own solutions. @Peter Williams, therefore, has taken this forward in the Modelling AG and further implementation. The functionality has been rolled in to the wider discussion of enhancing SNOMED’s DL capabilities. The Modelling AG is planning a targeted discussion on this in June 2017, and will then produce a document which would then be reviewed by the MAG at the October conference.This Proposal document will be shared when complete. Last update from Peter was that the OWL Refset solution allows us to classify with concrete domains. The thing we’re still discussing, is how to represent that in the release. The current most popular approach suggested is to create a 2nd Inferred file ("sct2_RelationshipConcreteValues_Delta_INT_[date].txt") which contains concrete values in the destination column, rather than SCTIDs. This allows them to be added without impact to the current approach i.e. ignore it if you don’t want to use them. The new file would only contain concrete values. At the same time, existing drugs strengths and counts expressed using concepts (which represent those same numeric values) will be inactivated. SNOMED International will inactivate the existing strength / concentration attributes which use concepts-as-numbers and replace them with new ones (using the same FSNs) and switch the target/value to the corresponding concrete numeric. This enhancement will increase the analytical power of SNOMED CT through the use of numeric queries and assist with interoperability by removing the need for extension maintainers to all - separately - add concepts representing numbers in order to publish their own drug dictionaries. | October 2018 - @Former user (Deleted)to give an update on the MAG's plans? No further updates yet, check back in April 2019.... Consultation: SNOMED International are now running a consultation around the introduction of Concrete Domains to SNOMED CT.I you are interested in this area, and/or wish to express an opinion on this proposed change, please read the following information and complete the feedback form if desired:http://www.snomed.org/news-and-events/articles/addition-concrete-domains-consultation Update from Peter Williams after subsequent MAG discussions - NEW MAG Proposal: ANYONE HAVE ANY FEEDBACK?? The MAG have only received formal feedback (via the online form - I know some of you commented direct on the page!) from ONE person so far, so can we please make a point of providing some feedback on this ASAP - even if it's just to say that you're in complete agreement? Thanks! We should also be issuing advice to downstream users of the drug model to avoid using the current concepts as numbers as they will soon be disappearing - can we please have confirmation of who knows that they have users impacted by this, and that they'll provide the advice immediately? Can anyone foresee any impact (negative or positive) on the Release(s)? NO Does the introduction of a second inferred file present any risk of confusion, etc? NO Are there any perceived restrictions around the use of concrete domains in inferred format? NO Should the new inferred file take exactly the same format as the current file? Current proposal removes the DestinationID field completely and replaces it with the new "Value" field But in theory, we could just hold the Values in the existing DestinationID field, if there's a strong business case for people to need the same format as the existing Inferred file? (hard coding of field names in import systems, etc) NO, THE NEW FORMAT IS ACCEPTABLE Will the inactivation of the existing concepts containing drugs strengths/counts cause anyone problems? NO, BUT MORE COMMS NEEDED TO WANR PEOPLE THEY'LL BE INACTIVATED EVERYONE HAPPY THAT COMMS HAVE BEEN SUFFICIENT?? Neither happy or not - we'll send out some advanced comms to the usual suspects shortly... @Andrew Atkinson Are they any users, for example, for currently use these concepts, who are unable to switch to the new approach? YES plenty, so we just need to continue to ensure this is an OPTIONAL file (to consume, it must be mandatory to include in the Release package) April 2020 - Any further feedback? (especially from any further updates from MAG plans) YES - the new question is whether or not we actually NEED to inactivate all previous concepts, or if (as we are only changing one attribute) we can leave them active and just update the attributes? Question sent to MAG Jim also kindly agreed to ask Editorial AG in meeting on 6th April... ANSWER - yes, these concepts will necessarily be inactivated - is everyone on board with this? OCTOBER 2020 - Discuss everything in the URGENT: CONCRETE DOMAINS Consultation proposal - in particular all impacts to RF2 package + naming conventions, etc: File naming convention / package location: "SnomedCT_InternationalRF2_Production_20210731T120000Z/Full/Terminology/ sct2_RelationshipConcreteValues_Full_INT_20210731.txt" Generally, rules and behaviour of the Concrete Value file is identical to that of the Relationship file DestinationId column replaced with a value column An additional column has been provide for a comparison operator, but this must - for now - be set to the equals sign in all cases. IMMUTABLE fields: sourceId, typeId, value, relationshipGroup, characteristicTypeId , modifierId Initial Questions: Concrete Domains RF2 Impact Analysis - The planned impact will be (likely to increase in Jan 2021) We will inactivate the existing strength / concentration attributes which use concepts-as-numbers and replace them with new ones (using the same FSNs) and switch the target/value to the corresponding concrete numeric 28,218 inactivations of current Relationship records 28,218 new Relationship records in the new Concrete Domains file There will be an equivalent change in the stated view, but since OWL is already capable of supporting concrete values, this will only result in changes within the OWL expressions: 13515 OWL Axioms are likely to change in the OWLExpression file MAG Confirmed yesterday that we cannot use true/false instead of 1/0 for booleans, due to the lack of EL support for this! They are suggesting the use of concepts 31874001 |True (qualifier value)| and 64100000 |False (qualifier value)| as an alternative. New proposal will be posted here: Either confirm no issues or provide feedback urgently, as we are in the middle of developing the Tech Preview for Jan 2021 as we speak.... TRAG agreed to provide feedback asap if anything is required... URGENT: CONCRETE DOMAINS WILL BE INCLUDED IN THE JULY 2021 INTERNATIONAL EDITION RELEASE FOR THE FIRST TIME We therefore now need any final feedback to be submitted immediately, as the feedback window closed last week on 15th April!! We will therefore be proceeding with the Production release as of next week, so this is the last call for feedback of any kind! NO FURTHER FEEDBACK (other than potentially Michael Lawley who has just tried to access the Tech Preview and can't - Matt sending it to him now, and @michael lawley to provide any feedback urgently this week) Therefore at the end of this week we will close this topic down and progress with the Production release as part of the July 2021 International Edition... Released on July 2021 as planned - any feedback? If not we can close this topic down... |
| 9 | ||||
| 10 | ||||
| 11 | Active Discussions for April 2022 | |||
| 12 | Welcome and thank you! | Thanks very much for all your hard work to our outgoing members. Welcome to new members! | - | |
| 13 | Member Nominations | As some of you may already known, Alejandro has now joined the SNOMED International team! | So whilst he's still going to attend the TRAG meetings in order to provide his vital insights, we will now have a vacant chair position. Please ask anyone you know who might be interested (and who has the requisite domain knowledge and expertise) to apply to myself and Fleur - thanks! | |
| 14 | @Ed Cheetham | This topic was closed down by the TRAG a few years ago due to the lack of requirements vs the complexity of finding a robust solution. However, new requirements and a potential solution from @Ed Cheetham have now been submitted for our review and discussion - please see here for details: Refset containing the semantic tags? We will discuss in detail in the next TRAG meeting in April, however please feel free to contribute to the online discussion in the above link in the meantime. | Slide deck here for advanced review: Feedback from the group: Excellent identification of issues that need addressing The first target should be to discuss the application of the Validation that Ed has kindly brought to us, both in the AP + Release validation stages. The second sim is to bring the discussions on the potential Formalisation of the Semantic tags to the relevant AG's for furhter consideration Yong has kindly agreed to add this to the agenda for the next MAG meeting, to be discussed further..... | |
| 15 | All | To be discussed in April 2022, in time to make a final decision before the 2022 Derivative cycle begins shortly afterwards...
| Feedback? As Matt mentioned, another option is to try to feed the derivative authoring process with monthly updates, thus reducing the necessary workload in the final Release cycle. However, in order to have the desired effect, this would also require us to not only author new changes more frequently, but also to migrate each derivative multiple times per year, in line with each monthly release. Whilst this could resolve the time crunch in August, it would necessarily introduce an additional overhead to the workload of the authors throughout the year, ...as even though they'd technically migrate the same number of concepts over 6 monthly migrations as they would in one large migration per 6 months, the process is cumbersome enough to have an impact on capacity ...this could (in theory) have a slightly positive effect however, as it would mean that authors get to know the migration process more intimately, if having to do it every month instead of every 6 or 12 months! We need to discuss with WCI to ensure that the tool would support this however... ...for example, we'd almost certainly need a new Delta generation process in the Refset tool, in order to enable it to provide roll-up Delta files for the past 6 or 12 months' worth of migrations in one file... The vast majority of the group are in favour of retaining the Jan + July releases as the dependent releases for all derivatives, mostly because of the comms that we sent out confirming that most users won't be impacted by the Monthly Releases if they don't want to be, as they can continue to use only the Jan/July releases for the foreseeable future. This is especially true for NRC's like Sweden, who Mikael says are using quite a few derivatives to package up different products for their users, and so having a conflict between the dependent releases of their extensions and thos of the derivatives will be very unhelpful for them We need, therefore, to explore different options, such as a) Updating the refsets monthly (though this is confirmed as an overhead for the team by Maria) b) Removing the review stage for all derivatives (except those which are brand new), s most feedback on BAU derivatives finds nothing of use nowadays... c) Postponing the final delivery of the refsets impacted by lack of people to review in July/August to November say, so the reviews can take place in September and work can continue after that. This si probably the most popular option in the group, but then not many people in the group are dependent on the derivatives releases... | |
| 16 | NEW DEPRECATION PROCESS! | Link here (if JMI completed in time - if not push this to October 2022) | April 2022 We will shortly be refining the deprecation process for SNOMED CT Products, especially derivatives such as Nursing Activities + Nursing Health Issues. If you have any pre-emptive ideas of how we can improve this process, please let us know now, as this is the time when we can easily impact the final solution? For example: Communication improvements? Comm out as far and wide as possible... Changes to the way we leave (or don't leave) the deprecated packages in MLDS? Some suggested leaving on MLDS for a short period (1 year?) then removing to keep MLDS clean Most others prefer to ALWAYS leave the latest (in this case Final Deprecated) version on MLDS permanently, so people know HOWEVER, this should be accompanied by clear labellling on MLDS to state a) That the product is deprecated b) the reason for deprecation (no longer used vs INVALID vs Dangerous, etc!) c) And keep the packages in a separate folder in MLDS marked "Deprecated" to make it very clear to only use them if you know what you're doing Changes to the way in which we deprecate the RF2 records? (inactivation, just leave them active but static, etc) This should be optional depending on the Reason for Deprecation (ie) a) If it is just no longer being maintained, then everything should remain Active, with a note clearly stating that there is no longer ACTIVE MAINTENANCE being done on this Product, and so should be used with caution as it's definitely out of date b) If the content is "WRONG" or "UNSAFE" then it should be inactivated and flagged as Unsafe for use c) etc Changes to the way we deal with the metadata? (inactivating refsetDescriptor records, module records, etc?) Metadata can never be "unsafe" in and of itself, and so refsetDescriptor and Module records ashould always remain active in all cases October 2022 Confirm if everyone is happy with the new process? Confirm if they are then also happy with applying the new process to all following planned deprecations: 2x Nursing Refsets Old FORMAT MedDRA Maps (but not entire Product) | |
| 17 | All | OCTOBER 2021 - Confirm transition is in progress, and request assistance from anyone interested in helping with the validation efforts for the soft launch releases... provide early visibility of the changes to the original proposal (ie): The map files (ICD-0/ICD-10) will no longer be separated from the INT Edition package They will also not be put onto their own separate Release Schedule. As long as the soft launch releases continue to go well, we will aim to keep the maps up to date with each INT Release, and therefore publish them as part of the INT Edition. FINAL DECISIONS: PROVIDED FULL VISIBILITY OF ALL DECISIONS + FINAL STATE OF THE PLANS FOR JAN 2022 onwards. No objections or queries raised, so in theory this topic can be closed down in April 2022 TRAG meeting, unless any new issues are raised in Q1 2022... | This is out most important topic for this week - we're currently in the development phase for all of the dependent work, so any questions about this, or issues to be raised must be done immediately if they are to be taken into account for the transition! Introduction + HIGH LEVEL walk through of current Proposal... (not enough time for a full detailed walk through, so if you could please read through it in advance and be ready with any questions that would be great?) APRIL 2021 - Confirm requirements are now complete and sufficient to successfully make the move to Continuous Delivery... October 2021: We are now in the trial period, whereby we're generating and validating "soft launch" monthly releases. So far the progress has been good, with the main focus on: Ensuring that the automated validation scope covers as many scenarios as possible Confirming that the new authoring process is working, and that the content team have the support they require in order to complete the new gateways. Verify that no issues are making it through to the Release cycle (which is now only a few days long) Anything that does needs to be added into the automated validation suite Timing the end to end process to ensure that the timings are refined enough to hit the much shorter deadlines. The initial soft launch releases have been sent to various stakeholders in the community for review SO FAR NO FEEDBACK!! (positive or otherwise!) Please respond asap... PLEASE VOLUNTEER if you believe that you can help out with these validation efforts It is in your own best interests to help ensure that the quality of the monthly releases is as high as possible Although we will have the ability to release fixes to issues in the next monthly release, it still means re-importing the updated release into your systems! April 2022: We have now published the first 2 Monthly Releases!! Obviously we're still proceeding across multiple fronts with improvements, in particular to the automation of the process + the validation Has anyone trialled the Delta File Generation Tool as yet? 1. Any feedback? YES GABOR HAS TRIED IT AND FED BACK ISSUES TO PETER - PETER IS STILL WORKING ON IMPROVEMENTS SUCH AS THE Snowstorm issue whereby if there are multiple different states for the same component withint the Delta period, snowstorm loses the history of all those changes and just spits out a (random) one line state! So if a concept has started active, been inactivated and then reactivated in the Delta timeframe, snowstorm might decide to spit out active or inactive as the latest state! It will also lose those 3 changes and only export one change! OCTOBER 2022 - VALIDATION advances: OWL testing - anyone worked on this as yet? Template validation - thoughts? Need to identify Modelling areas that need improving - for example where concepts have 2x parents, this is usually an indication of areas that need re-modelling Need automation of the QA system itself - so some quick way to validate RVF + DROOLS Assertions, both old + especially new! MOST IMPORTANTLY, how do we avoid the usual pitfall of automated testing (ie) that the effort involved in maintaining the automated assertions and keeping them up to date with the content changes, doesn't start to exceed the effort involved in testing manually?! Anyone with experience of a good answer to this? Whitelisting - API required? | |
| 18 | a) Release Notes | The original plan was to automate the Release Notes in order to detail every change to the Release in each Month's Release Notes. | However, in order to ensure that we deliver the full necessary scope of the work to support the actual Frequent RF2 releases, we have had to defer this to phase 2. The Release Notes will therefore continue to be manual for the first few releases, which may mean they are more high level and less detailed than they would otherwise have been. Anyone experienced any issues as a result of this? What's everyone's opinion on the current International Edition Release Notes? Are they too high level? Or are they too detailed? We could in theory move almost ALL of the detail to the Early Visibility page, and just leave the monthly Release Notes high level, describing which projects are being published in each monthly release? Thoughts? | |
| 19 | b) Managed Service rollout | Whilst the overall MS move to Frequent Delivery won't be made available to MS customers until after the International Edition transition, we also don't want to diverge the code bases. Therefore, we need to consider and include configuration items within the code to allows the MS Projects to move through the new Frequent Delivery workflow WITHOUT moving to Frequent delivery (for example, we could just enable the basic mandatory automated SAC and nothing else?) | We have already had to introduce a small amount of change into the MS authoring processes, in order to ensure that the MS code base remains in line with the International code. Comments and feedback welcome... **** SI have now made the decision to standardise ALL of our Products in terms of the format of the packages APRIL 2022 - only feedback was from Guillermo, who confirmed they are still creating extensions with Delta files - we assured him that we're not at the point of enforcing the new standards across ALL SNOMED Releases, just across all products published by SNOMED INTERNATIONAL - so he can continue to include/exclude the Delta files as required in his own extensions. | |
| 20 | c) Critical Incident Policy update | We need to refine the Critical Incident Policy:
| October 2022 What other criteria do we need to use? How strict should we be with the criteria? We need to balance the risk of NOT fixing an issue vs the risk of impact to a stable Release candidate from the fix... As discussed yesterday, we should keep the policy flexible on the solution that will need to be implemented in order to resolve any critical incidents: | |
Copyright © 2026, SNOMED International