TRAG - Recommendations made

Resolved Discussions

Status: All
Creators: All Creation period Categories: All

With the impending plans to move to a more Frequent Delivery schedule of the SNOMED CT International Edition (starting with a monthly cycle within the next year), we are now considering the requirements for review and feedback periods inherent in the current Release schedule. Given the relative stability of recent releases, and the increased pressure that a Monthly release schedule would put upon the reviewers in the community, we are now considering removing the Beta and Member release p

Status: New 18 View 0 Comment Comments enabled In the category: Resolved Discussions

Hi everyone Thanks again for all of your invaluable feedback - so helpful in fact that we've changed the proposal in line with your suggestions, and as Rory said we've now proposed a full interim International release to the Member Forum (as opposed to the original Delta package): https://confluence.ihtsdotools.org/display/MEMBERFORUM/URGENT%3A+Feedback+requested The plan is therefore to deploy the updated package next week, once we've received and managed any feedback from the MF or

Status: Resolved 363 View 23 Comment Comments enabled In the category: Resolved Discussions
Comment Last useful answer, Apr 3, 2020. All contributions
Our Terminology ER personnel thank you for the confirmation, it gives more predictability regarding extension options. Agree.
MRCM format update
Added by Andrew Atkinson on Dec 12, 2019

A new tool is being developed to maintain and publish the MRCM, from the 20200731 release. Because the original tooling did not define a canonical attribute order when auto-generating the domain templates, the order of attributes in these domain templates will not be preserved. It is therefore proposed that any affected rows (whose domain template is reordered) is reversioned - i.e. a new row is created in the MrcmDomain refset, with the same UUID, a new effectiveTime and reordered domainT

Status: Resolved 38 View 1 Comment Comments enabled In the category: Resolved Discussions
Comment Last useful answer, Apr 2, 2020. All contributions
I don’t see any problems with this proposal. (I assume that the reason for change of the MRCM itself is documented somewhere accessible for the release recipients.)

I'm just revising our validations for the Refset Descriptor Refset. (Upon realising after realising we had none!). And have wondering if the entries should remain active for retired reference sets? The specs (5.2.4.1 Reference Set Descriptor) seem to be silent on the issue... (Unless noted elsewhere)? So I've looked for guidance in the data... The non-human refset is the only refset that I can think of that's been inactive. And it's descriptor history is a bit murky.. id effectivetime

Status: Resolved 41 View 2 Comment Comments enabled In the category: Resolved Discussions
Comment Last useful answer, Apr 3, 2020. All contributions
Considering the design ideas behind RF2 I would prefer to keep the refset description active in the same way and with the same reasons as why descriptions to inactive concepts stay active. They still appropriately describe the inactive component. (The only exception is, of cause, if the refset descriptior contains an error, but in that case it should be replaced with a new and correct active refset descriptior.)

Hi everyone Another topic for discussion in the face to face meetings - the standardisation of the SNOMED CT policy towards re-activation of RF2 records. For example, we have had instances where MRCM records were originally inactivated, and replaced with updated versions that were subsequently proven to be less valid than the original records. The question was then whether or not to re-activate the original records, or to inactivate the new (invalid replacements) and create new vali

Status: Resolved 19 View 2 Comment Comments enabled In the category: Resolved Discussions
Comment Last useful answer, Oct 25, 2019. All contributions
For the MRCM, and probably any refset, reactivation has negligible negative consequence I can think of. E.g. A concept being, a member of the refset, not a member, and a once again a member. A new UUID for the return of membership offers no value I can think of. Similarly with the MRCM, typical usage is only interested in "current active" entries. Pretty much all componentIds. ConceptIds are main (only?) componentId with baggage. Maps, translations, refsets all hang off this. We have occasionally reactivated concepts. The main reason being we had known users relying on the concept, and we didn't agree with the inactivation**. (The alternative would be, recreate in AU, get the user to "remap", optionally tell SI we thought the inactivation was incorrect, if they agree, they create a new concept, we subsequently retire ours as duplicate in a later release, then user remaps again... Note: the last part is worse case scenario where the new AU conceptId not promoted). Mistakes happen, and reactivation seems like a good way to resolve that minimises the burden on endusers. Such mistakes are hopefully identified reasonably quickly, say within a release or two. I wouldn't reactivate anything that's never actually been active in SNOMED CT. I don't think I would go looking for inactive concepts to reactivate, to satisfy new content requests. ** We've noticed an increase in questionable inactivations in July 19, that I'm yet to raise with SI.

We've finalised a plan for the next two International Releases, and so any feedback you have on the viability of the plan is needed urgently - thanks! The plan is as follows: January 2019: The International Edition package (let’s call it packageA) will include both active Stated Rel’s + partial OWL file (combined) We will also publish a separate optional package (packageB) containing a complete set of OWL records (including all axioms - sufficient, transitivity etc) set to Jan 2019 effec

Status: Resolved 130 View 25 Comment Comments enabled In the category: Resolved Discussions
Comment Last useful answer, Nov 22, 2018. All contributions
Thanks for your answers and clarifications aatkinson, I'm happy with the plan and I'm pretty clear on what is going to happen now.

In 2018 the Content Managers Advisory Group is looking to undertake a work item focusing on national pre-release processes. This work is aimed to support a collaborative understanding of what NRCs are including in their pre-release processes together with identification of potential opportunities to improve these processes. Given the remit of the Terminology Release Advisory Group, the Content Managers Advisory Group would like to raise the potential for this to be a joint Advisory Group a

Status: Resolved 144 View 8 Comment Comments enabled In the category: Resolved Discussions
Comment Last useful answer, Feb 28, 2018. All contributions
Hi apatel, Would you please contact me via cri@snomed.org mailto:cri@snomed.org in relation to this request please. Thank you, Cathy

Hi everyone Fairly straight-forward one here - the Association Reference file has historically been named slightly inaccurately, called 'der2_cRefset_AssociationReferenceSnapshot_INT_*.txt' etc, which implies it's name to be "Association Reference Reference Set" rather than the correct "Association Reference Set".  So the proposal is to simply rename the file(s) to something like 'der2_cRefset_AssociationSnapshot_INT_*.txt', or similar? I'm guessing that some re-work would be required fo

Status: Resolved 92 View 7 Comment Comments enabled In the category: Resolved Discussions
Comment Last useful answer, Oct 14, 2018. All contributions
RESOLUTION:  This was implemented it in the Jan 2018 International Edition release, plus in the various derivative products based on this release.

Hi everyone Another conundrum for you :-) We have found some examples, in this case in the US edition, of concepts that were promoted to the International Edition, but remain in the US maintained module in the US branch. There are 5 concepts found to be in this situation ie concept table updated in the US module after the concept has been promoted to core: id core_effectiveTime core_activeFlag us_effectiveTime us_activeFlag term 11000119105 20150131 0 20150301 0 History of peanut all

Status: Resolved 125 View 11 Comment Comments enabled In the category: Resolved Discussions
Comment Last useful answer, May 22, 2017. All contributions
RESOLUTION:  Peter Williams resolved this issue in the code as per the agreed approach with the TRAG.  We also raised the long term discussion on the "Negative Delta" proposal, so please post any future comments on this to the new page here:  "Negative Delta" file approach

Hi everyone We've found several AttributeValue records (193 pairs) which have 2 states in the files for the same effectiveTime - one Active and one Inactive. For example: id effectivetime active moduleid refsetid referencedcomponentid valueid 34105af2-75df-4851-bb1b-10481862a050 20170131 1 900000000000207008 900000000000490003 2475924014 900000000000495008 402ef83b-0033-5802-b73e-a9d92c98fa48 20170131 0 900000000000207008 900000000000490003 2475924014 900000000000495008 Our fi

Status: Resolved 85 View 4 Comment Comments enabled In the category: Resolved Discussions
Comment Last useful answer, Oct 14, 2018. All contributions
RESOLUTION: Matt and Mikael confirmed that this is a valid situation, and therefore no action is required.  TRAG agreed unanimously.
1 2 3 ... Next Last