2021-04-20 - TRAG Meeting Agenda/Minutes
Date
20th April 2020 - 10:00 - 13:00 GMT (09:00 - 12:00 UTC)
Room: NONE - Conference Call ONLY!
Please enter the call via the OpenAir app instead of direct through Zoom - thanks!
21st April 2020 - 10:00 - 13:00 GMT (09:00 - 12:00 UTC)
Room: NONE - Conference Call ONLY!
Please enter the call via the OpenAir app instead of direct through Zoom - thanks!
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
@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
@Orsolya Bali (Unlicensed), member
@Former user (Deleted)member
Meeting Recording
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 APRIL 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 | 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... | |
| 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 year? 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... | |
| 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 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 | 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. | |
| 12 | 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... |
| 13 | @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... | |
| 14 | 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... |
| 15 | Discussion of proposed format and packaging of new combined Freeset product + | All | TRAG to review and provide feedback and ideas for business case(s)... | Andrew Atkinson to present the current proposal, and gather feedback Feedback: Uncertainty on use cases - however this was mitigated by the specific messaging from SNOMED licensed users to non-licensed recipients... Content DICOM in particular no representative without sub-division, PLUS actually risky with unverified attributes... AAT to discuss further with Jane, etc Agreed that SI are confident that DICOM will provide some use Using the US PT instead of the FSN (whilst providing less exposure of the IP) prevents visibility of the hierarchy (due to lack of semantic tag) - however the reason for this is because the target users (who are NOT current SNOMED licensed users) will find more use from the PT in drop-downs, messaging, etc than the FSN... Now included both! Everyone happy with each subsequent release being a snapshot - so additions added but inactivations just removed - as long as we include something in the legal licence statement to state that use of all concepts that have ever been included is in perpetuity (even after they've been inactivated) New requirements have suggested that we need to now include a full historical audit trail, even in the Freeset formatted file! This means we've included an Active flag column to allow this to be added in future releases... We don't need to do this for a few months, so we need feedback now on whether or not we think this is a good idea? Any potential drawbacks? None idenitifed in Oct 2019 - but no-one has used it yet! Check again in April 2020 - no NONE - go ahead! This is a dependency for signing off the final version of the Release packaging conventions and File Naming Conventions item (next) In addition, Members would also like a Proposal to create an additional Simple refset (full RF2) of the entire GPS freeset in order to enable active/inactive querying etc by licenced users... Potential to automate the creation of this using ECL queries if we ensure all freesets are included in the refset tool.. Would people still see a valid business case for including an RF2 refset file in the GPS package as well? OCTOBER 2019 - NOT IN THE ROOM - BUT RORY HAS BEEN ASKED FOR IT BY SEVERAL PEOPLE, SO WE NEED TO DO IT This will be in line with the September 2020 GPS release. Any potential drawbacks with doing this? NO If so, should it be part of the existing GPS release package, or a separate file released at the same time? Separate, released at same time - this is because the use case is different for each file type - Users who don't have SNOMED CT will use freeset format file to scope which concepts they can receive successfully Users who already have SNOMED CT will use the RF2 file format to scope which concepts they can send successfully to those who aren't regular SNOMED users... APRIL 2020 - Any other feedback from actually using the GPS freeset file???? no - everyone would just like the RF2 file version in Sept 2020 as planned... GPS RF2 format package published as promised on 30/09/2020 - ANYONE USED IT ALREADY?? Any feedback yet? @Matt Cordell about to use it - he will send feedback once uploaded the new RF2 file. .....Matt never loaded it in the end, so no feedback other than generally that the format looks useful Peter Williams + Michael Lawley confirmed the real benefit was the the PHIR project - it's working well for that so far PLEASE CAN YOU DOWNLOAD IT AND PROVIDE FEEDBACK ASAP (even if it's just that it "all looks good"!).... +++++ feedback on the Freeset format as well... AAT to then update the Release packaging conventions and File Naming Conventions with the final decisions on the freeset format, ONCE the next GPS release has been published and we've had time to receive any useful feedback on it all... |
| 16 | All | TRAG to review and provide final feedback. Reuben to provide feedback on progress of the URI specs + FHIR specs updates... | Document updated by @Andrew Atkinson in line with the recommendations from the last meeting, and then migrated to a Confluence page here: SNOMED CT Release Configuration and Packaging Conventions To be reviewed in detail by everyone, and all feedback to be discussed in the meetings. AS OF OCTOBER 2017 MOST PEOPLE STILL NEEDED TIME TO REVIEW THE DOC - @Andrew Atkinson INFORMED EVERYONE THAT THIS DOCUMENT WILL BE ENFORCED AS OF THE JAN 2018 RELEASE AND THEREFORE WE NEED REVIEWS COMPLETED ASAP... so now need to check if reviews still outstanding, or if all complete and signed off?? AAT to add in to the Release Versioning spec that the time stamp is UTC AAT to add the trailing "Z" into the Release packaging conventions to bring us in line with ISO8601 AAT to add new discussion point in order to completely review the actual file naming conventions. An example, would be to add into the Delta/Full/Snapshot element the dependent release that the Delta is from (eg) "_Delta-20170131_" etc. AAT to discuss with Linda/David. Or we hold a zero byte file in the Delta folder containing this info as this is less intrusive to existing users. Then publish the proposal, and everyone would then take this to their relevant stakeholders for feedback before the next meeting in October. If this is ratified, we would then update the TIG accordingly. AAT to add in a statement to the section 4 (Release package configuration) to state that multiple Delta's are not advised within the same package. AAT to add in appendix with human readable version of the folder structure. Done - see section 7 IN ADDITION, we should discuss both the File Naming convention recommendations in the Requirements section (at the top of the page), PLUS Dion's suggestions further below (with the diagram included). @Dion McMurtrie to discuss syndication options for MLDS in October 2018 - see hwat they've done (using Atom) and discuss with Rory as to what we can do. Suzy would be interested is this as well from an MS persepctive. UK also interested. This shouldn't hold up the publishing of the document. Discussions to continue in parallel with the creation of this document... @Reuben Daniels to raise a ticket to update the fhir specs accordingly @Reuben Daniels to talk to Linda to get URI specs updated accordingly. URI Specs to be updated and aligned accordingly - @Reuben Daniels to assist EVERYONE TO REVIEW TONIGHT AND SIGN OFF TOMRORROW ONLY outstanding point from earlier discussing was Dion's point from the joint AG where he talked about nailing down the rules for derivative modules... - @Dion McMurtrie to discuss/agree in the October 2018 meetings - REPORT FROM DION?? Everyone is now happy with the current version, therefore @Andrew Atkinson to publish - we can then start refining it as we use it. @Andrew Atkinson to therefore agree all of the relevant changes that will be required as a result of this document internally in SNOMED International, and publish the document accordingly. FIRST POINT WAS THEREFORE TO have it reviewed internally by all relevant stakeholders... This has been completed and signed off Do we consider anything in here needs to be incorporated into the TIG? or perhaps just linked through? or not relevant and just separate? YES - NOT RELEVANT!! the litmus test should be whether or not implementers still use the TIG, or whether people now use separate documentation instead? ?????????? We also need to make a decision on the final Freeset distribution format(s), as I want to ensure we only have a MAXIMUM of 2 distribution formats - RF2 + the agreed new Freeset format (whatever that may be) YES everyone is happy with this! Add this into the Release Packaging Conventions and publish APRIL 2021 - DO WE NEED TO MAKE ANY REFINEMENTS IN ORDER TO PREPARE FOR CONTINUOUS DELIVERY? Did ADHA need any formatting changes when moving to monthly? No, nothing beyond the new .json file and refinements to that We really need to tackle the Delta from and to release version in the Delta file naming, and possibly package file naming. At the moment it is impossible to know what a Delta is relative to making it hard to safely process it. Perhaps beyond the scope of this document, but quite important THIS IS NOW ADDRESSED IN THE NEW Metadata file: Standard July 2020 International Edition metadata file: NON-Standard July 2020 International Edition Rollup Delta metadata file: January 2021 International Edition metadata file: March 2021 Belgium Extension metadata file: DOES IT NOW COVER EVERYTHING NEEDED??? No! We'll continue to discuss and agree ideas for new fields in this file as we progress towards Frequent Delivery.... This will therefore be rolled into the holistic discussions on Metadata in the new Metadata Working Group... THIS NEEDS TO BE CONTINUALLY REFINED OVER THE NEXT YEAR WHEN WORKING TOWARDS MORE FREQUENT DELIVERY: Once all happy, the document will be published and opened up to anyone to view. Everyone was invited to either join the Working Group, or contribute ideas towards it - we will therefore continue to report back on how this is going... | |
| 17 | Plans for the transition from Stated Relationship file to OWL refset files * MAG crossover | All | This is part of the wider Drugs and Substances improvements that are currently taking place. Other than the obvious content updates, these technical changes are those which will be likely to have the highest impact on those within our AG. | @Former user (Deleted) to talk to Yong and others in the MAG about his proposals for future proofing against the possibility of having multiple ontologies referenced, prefixed axioms, etc. Harold confirmed nothing to report Some opposition to reverting back to having the OWL file on-demand for Jan 2019 - need to discuss through with Kai in tomorrow's session - preference is to release both Stated Rel's + the "addtiional" info only in the OWL files - as with July 2018 release. Is this the current intention? Done - Jan 2019 was implemented as requested - did anyone manage to use it and trial it effectively? Any feedback? |
Copyright © 2026, SNOMED International