2021-10-18 - TRAG Meeting Agenda/Minutes
Date
18th October 2021 - 10:00 - 13:00 GMT (09:00 - 12:00 UTC)
Room: NONE - Conference Call ONLY!
Please enter the call via the OpenAir app if possible - thanks!
19th October 2021 - 10:00 - 13:00 GMT (09:00 - 12:00 UTC)
Room: NONE - Conference Call ONLY!
Please enter the call via the OpenAir app if possible - thanks!
Dial in details:
Attendees
@Andrew Atkinson, Chair
@Mounir Bouzanih (Unlicensed), member
@Mikael Nyström, 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
@Harold Solbrig, 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... | ***** IN ORDER TO RETAIN SOME KIND OF SEMBLANCE OF A NORMAL MEETING, PLEASE CAN JUST THE TRAG MEMBERS KEEP YOUR CAMERA's SWITCHED ON, WHILST OBSERVERS PLEASE KEEP THEM OFF IF POSSIBLE ******
We've got several topics that we've resolved and closed down - As always, we won't waste time going through them again, but if you'd like to read through them they're listed below.... |
| 2 | Conclusion of previous Discussions topics | |||
| 3 | Spanish Member Collaboration Process refinements | Spanish Edition users only | There was a presentation made at 17:10 by Arturo Romero Gutierrez, to walk through the improvements to this process that have been discussed and agreed since the inception of this new process, and what the Spanish Edition users need to commit to in order to be contributing part of this process. Everyone was welcome to stay and participate! | GREAT NEWS ON THIS TOPIC IS THAT WE'VE NOW USED THIS PROCESS END TO END FOR THE FIRST TIME THIS CYCLE, AND SO THE OCTOBER 2021 Spanish Edition WILL CONTAIN MULTIPLE FIXES FOR ISSUES RAISED BY THE SPANISH COMMUNITY, AND REPORTED/RESOLVED THROUGH THE NEW PROCESS - thanks everyone! We can therefore close this down as complete and working as expected, unless anyone has any further comments/refinements to propose? Presentation from Arturo Agreement from all Spanish Edition users who were present (Alejandra, Suzy + Alejandro) to collaborate and contribute to the refined process We then formalised the process and distributed the document out to all interested parties Arturo, Guillermo, and all others to report back on how the process is working for them? October 2019 cycle worked well for Arturo + Guillermo. October 2020......? Still working well? finally used it for a joint discussion topic = https://projects.jira.snomed.org/browse/SECRS-4 ARTURO VERY HAPPY! He is now comfortable that the process works (as we have now followed it all the way through from inception to implementation with the desired results) + ...that the process supports the thorough analysis and required application of these type of longer term ideas + ...that it still supports the rapid and effective resolution of the large number of minor issues. He is therefore happy for us to close this discussion down as having been addressed. |
| 4 |
|
|
|
|
| 5 |
|
|
|
|
| 6 | Active discussions for April 2021
| |||
| 7 | Welcome and thank you! |
| Thanks very much for all your hard work to our outgoing members. Welcome to new members! | - |
| 8 | 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! |
| 9 | 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... |
| 10 | 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... |
| 11 | 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. | |
| 12 | 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. | |
| 13 | 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... |
| 14 | Proposal for a complimentary file to the MDRS - the "ECRS" ("Edition Composition Reference Set") | @Dion McMurtrie @michael lawley | The TRAG had discussions a couple of years ago to clarify the best application of the Module Dependency Reference Set (MDRS) - some background reading is here:
Michael and Dion then walked through the proposal and answered questions, but Michael and Linda both confirmed that the use case was not a critical priority at the time, and therefore didn't need to be actively discussed until new cases were proposed... WE THEREFORE CLOSED THE DISCUSSION DOWN AT THE TIME DUE TO A LACK OF MULTIPLE USE CASES, AND SO THIS WAS DE-PRIORITISED UNTIL SUCH TIME AS MORE USE CASES CAME TO LIGHT. | We have now identified more use cases for this proposal, as the new automated MDRS validation picks up what appear at first to be false positives, but which are actually valid failures due to the historical shortcomings of the MDRS format. We therefore need to discuss and agree an approach that allows us to both express the correct moduleDependencies + the new module composition (to express which modules comprise the Edition package, for URI + validation purposes). This should then be used to properly validate the MDRS and moduleDependencies within the Edition and Extension packages. There was a lot of feedback on the original proposal - however in this meeting we should: a) Ask Dion/Michael to walk through the proposal in person to ensure that everyone's on the same page (and remembers the original discussions) b) Answer the feedback (plus any new feedback in light of new situations and/or use cases) c) Agree what the final proposal should be, and what are the next steps we need to take in order to get it signed off (MAG, design authority, etc?) Michael, Dion and Reuben were going to create the Australian version as an example, in order to include that in Michael's updated version of the proposal document - did this happen? New proposal for representing the ECRS information in the .JSON Metadata file will be kindly brought to the table by Dion + Michael tomorrow, for further review This will include an example of how the INT Edition might look... As part of the discussions on this topic, we need to decide what to do about the transitivity of dependencies in the MDRS - Linda will kindly present the background and options to discuss... Initial discussion were had on 18th October 2021, leading to a provisional decision that the best course of action might be to: State that transitivity is the primary method, but that Explicit statement of all moduleDependencies (even though that could be inferred through their transitive inclusion) would remain an option in all cases, to be used whenever the transitive dependencies would lead to potential confusion or conflict, for example in the case where two different components (eg. ICD-10 map + IPS refset) of an Edition (eg. Pangea Edition) were themselves dependent on two different versions of the same product (eg. the July 2021 INT Edition + the October 2021 INT Edition respectively). In this case the MDRS in the Edition which incorporates the modules would explicitly state the dependencies of all it's constituent modules, and therefore resolve the conflict that would otherwise have arisen - so in this example, the Pangea Edition would explicitly state that both ICD-10 + IPS modules were dependent on the October 2021 INT Edition NB the curator of the Pangea Edition would first be responsible for testing and confirming that the ICD-10 maps (which were implicitly dependent on the July 2021 INT Edition rather than October) worked cleanly with the October 2021 release as well, before publishing the Pangea Edition. However, the one drawback raised in response to this option was that we need a strong use case to warrant changing the RF2 spec. So we need to decide if we're happy that the use cases in the proposal are strong enough for that (ie) FINAL DECISIONS: a) We will use the new JSON data on Package Composition to resolve the issues with the false positive results in the current MDRS RVF assertions, by having the assertions check the new JSON data to confirm whether or not the modules that are not explicitly called out in the packages' MDRS file (as its an extension or similar), or that have conflicting versions. b) We will use the new .JSON data to allow correct resolution of URI's c) We will NOT change the RF2 spec to move to transitive dependencies in the MDRS. 5.2.4.2 Module Dependency Reference Set - currently states "Dependencies are not transitive and this means that dependencies cannot be inferred from a chain of dependencies. If module-A depends on module-B and module-B depends on module-C, the dependency of module-A on module-C must still be stated explicitly." Despite this being a valid theoretical stance (as dependencies are inherently transitive), the weight of historical data across all products for the past many years means that introducing a new approach whereby all dependencies are assumed to be transitive unless there's a problem and are therefore stated, could result in confusion when taken in the context of all previous releases where stated dependencies are NOT only there if there's a problem! We will therefore continue to review this use case in future TRAG meetings, to see if the case for changing the spec becomes strong enough to warrant a change to all our products, plus a change that runs contrary to all historical releases. New planned changes to .JSON metadata file: Update to the .JSON file metadata - addition of "Package Composition" data |
| 15 | RVF improvement discussions | @Dion McMurtrie | CSIRO have been working on improvements to the RVF, and would like to report on and discuss some of the results with us... | Dion to Present current status + plan... Comments and feedback welcomed... Plenty of feedback and so further discussions required as we move through the project... The main feedback for the past few months has been the RVF failures for the new MDRS assertions, which appear at first glance to be false positives. However, they have been proven to be valid failures, as long as you consider that the MDRS format itself is (and has always been) inherently flawed. The closure of this topic is therefore dependent on the outcome of the discussions on the Proposal for a complimentary file to the MDRS - the "ECRS" ("Edition Composition Reference Set") If this concludes that we need to change the MDRS, then this RVF topic can be closed down. If, however, we decide to retain the MDRS format, then we need to revisit these RVF assertions... We need to use the new planned changes to .JSON metadata file: Update to the .JSON file metadata - addition of "Package Composition" data in order to fix the RVF assertions and remove the false positives... |
| 16 | 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. | Does anyone have any last minute questions/issues to raise before the Production release is published? No - in which case we'll proceed as planned Topic to be closed down in October 2021 TRAG meetings (after Production release) unless new issues are raised... TOPIC TO BE RE-OPENED DUE TO FEEDBACK FROM THE COMMUNITY ON THE FORMAT OF THE MedDRA to SNOMED MAP FILES: We should open up a new topic to review the proposal (incoming from the Implementation team) for a new format for reverse direction maps... FINAL DECISIONS: We will take this proposal to the MAG, and if ratified we will: a) take the plans forward with the content team, in order to include the necessary new concepts in the January 2022 International Edition b) update the RF2 spec accordingly NOW we need to agree how to communicate it out to the community ahead of the April 2022 MedDRA release... Is it enough to: a) send out general comms to the Release distribution list confirming the upcoming changes b) + send the same comms out to those users who we know downloaded the April 2021 MedDRA release package? Or do we need to do something more? No, that's adequate In addition, we need to agree how to build the MedDRA package in April 2022, in order to clearly show a distinction from the April 2021 release (in the old format), whilst also retaining the historical audit trail. Everyone agreed that we need to produce the April 2022 MedDRA package: a) in the new format (as per "Redesign of the Map Reference Set formats") b) with the April 2021 map file(s) removed c) BUT the new format map files should contain both the new data, PLUS all the historical MedDRA data (from 2021) in the NEW FORMAT. This means that the NEW file should look exactly like it would be if we had actually published the original April 2021 MedDRA release in the NEW FORMAT (with all original data from 2021 + all new inactivations/changes from the latest cycle) |
| 17 | All | Please find below a proposal for redesigning the map reference sets to support maps in either direction: https://docs.google.com/document/d/14bmRaVQYI7-Kz2EPgv00muGqdO6wRrMycCPCJqp5W2s
| If you could please review before the TRAG meeting and provide any feedback that would be great? We can then discuss any issues in the next TRAG meeting in October. This needs to be signed off at this business meeting, as once approved we'll be: a) Pushing early warning comms out to the community to advise of the upcoming changes to the MedDRA map format in April 2022 + b) Moving ahead with preparations and build of the new MedDRA maps So please speak now if you have any concerns at all! Issues raised? Whether we should instead create generic parent concepts for the new Correlation Types (ie) Instead of replacing the existing correlation concepts, we would add generic parents which would be used for the new Map refsets (that are "something else TO Snomed"), but leave the existing "Snomed TO something else" concepts in place as their children, in order to prevent the entire community from having to re-publish all of their maps as a result of the existing Correlation concepts having to be inactivated: PARENTS: <sctId> |Source to SNOMED CT target map correlation value| <sctId> |Broad to narrow map from map source to SNOMED CT target| <sctId> |Exact match map from map source to SNOMED CT target| <sctId> |Narrow to broad map from map source to SNOMED CT target| <sctId> |Partial overlap between map source and SNOMED CT target| <sctId> |Map source not mappable to SNOMED CT| <sctId> |Map source to SNOMED CT target correlation not specified| CHILDREN: 447247004 |SNOMED CT source to target map correlation value| 447559001 |Broad to narrow map from SNOMED CT source to map target| 447557004 |Exact match map from SNOMED CT source to map target| 447558009 |Narrow to broad map from SNOMED CT source to map target| 447560006 |Partial overlap between SNOMED CT source and map target| 447556008 |SNOMED CT source not mappable to target coding scheme| 447561005 |SNOMED CT source to map target correlation not specified| This proposal was signed off, ready to take to the MAG on 20/10/2021... HOWEVER, WE'RE STILL MISSING THE IDENTIFICATION OF THE ACTUAL MAP PRODUCT ITSELF, AND THE VERSION OF THAT ENTITY (eg) "ICNP version Jan 2019" should exist as metadata somewhere within the ICNP map product package... + possibly even the direct URI? SUGGESTION IS TO USE THE JSON FILE FOR THIS - @Andrew Atkinson to take this forward in the Metadata working group... ANOTHER DISCUSSION POINT FOR THE JSON FILE: Are the "DeltaToDate" and "DeltaFromDate" fields in the JSON file now misleading in the new world of Frequent Delivery where we have no Delta files in the INT package itself?! "deltaFromDate" : "20210930", "deltaToDate" : "20211031", FINAL DECISIONS: Agreed that these fields should ONLY be available in packages with Delta files Monthly International Releases going forward, should instead just have: EffectiveTime PreviousPublishedPackage (that the current release is based upon) Any retracted releases + their replacements | |
| 18 | @Matt Cordell | Question here is whether or not RefsetDescriptor records themselves should remain active for retired reference sets? TRAG to decide on correct policy and feedback to Matt... | The consensus so far is that we should keep the RefsetDescriptor records themselves active, which has been the precedent for all cases in RF2 history so far, with the exception of the Non-human refset which was physically removed from the International Edition package. The UKTC and others have previously requested these RefsetDescriptor records to be inactivated (https://projects.jira.snomed.org/browse/ISRS-112, etc) - for consistency purposes, but the corollary of this is that the refset structure itself (which the refsetDescriptor describes) remains valid and active, despite the refset itself having been inactivated. TRAG TO DISCUSS AND AGREE BEST SOLUTION... Then propose an addition to the TIG to provide clear guidance on this for all users... AGREED: Happy to leave the RefsetDescriptor Active for all normal circumstances If we're removing the Refset entirely from the Extension/Edition, we should a) if it's just for space or something, then leave refsetDescriptor record in place b) if it's for CRITICAL INCIDENTS ONLY (and even then only certain subsets of this - most likely only legal issues), we'll remove RefsetDescriptor completely @Matt Cordell to write up and send to all of us for review.... confirmed on 20/04/2021 that Matt will write this up and present to the TRAG in future meetings we will then incorporate the new conventions into the TIG and other documentation in order to ensure consistent approaches for all users going forward... Matt has written this up now for review: Matt to present and discuss... FINAL DECISIONS: Matt Presented - no contentious points, so Matt is ready to take this proposal further... | |
| 19 | ||||