2017-10-16 - TRAG Meeting Agenda/Minutes


16th October 2017  -  13:30 - 17:00 (Room: Warsaw, Crowne Plaza Bratislava + Conference Call)

25th April 2017  -  09:00 - 12:00 (Room: Warsaw, Crowne Plaza Bratislava + Conference Call)



Meeting Recording



  • 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


Thanks to our outgoing members for all of their help.

Welcome to our three new members!



Conclusion of previous Discussions topics





Release version control proposal updated to use the actual Release Date + Time instead of EffectiveTime in the Release Package Naming convention.

This change was communicated out, and has now been implemented in the January 2017 International Edition, plus all subsequent derivative packages.

TRAG to report on any issues experienced as a result of the change?

  • Release versioning changes have now been implemented in both the International Edition and all derivative packages (including the "Z" suffix)
  • Any issues experienced? NONE
  • Any suggestions for improvement? NO
  • If not, Andrew Atkinson to close down.

Naming convention was updated in order to target the specific Laterality that we're discussing in this respect - now called the "Lateralizable body structure reference set".

TRAG to report on any issues experienced when using it?

  • Laterality refset now published in the International Edition - any issues experienced using it? YES - SEE BELOW
  • Any suggestions for improvement? NO
  • If not, Andrew Atkinson to close down.

Everyone was in agreement that removing the Perl script from the International Edition is a good idea, as long as we clearly communicate the change out, and ensure that the users are a) aware of where to get it now, and b) assured that it still has the same support from IHTSDO as it always has.

This change was communicated out, and has now been implemented in the January 2017 International Edition.

TRAG to report on any issues experienced as a result of the change?

  • Perl script now separated from the International Edition - any issues experienced? NO
  • Any suggestions for improvement? NO
  • If not, Andrew Atkinson to close down.


Everyone is now happy with the segregation of the Release Notes from the International edition package (in fact ADHA have already effected this change)

This change was communicated out, and has now been implemented in the January 2017 International Edition.

TRAG to report on any issues experienced as a result of the change?

  • Release Notes now separated from the International Edition - any issues experienced? NO
  • Any suggestions for improvement? NO
  • If not, Andrew Atkinson to close down.


No-one has an interest in this at present, as everyone who is in a position to evaluate the Releases have already got processes in place for this. The clinical level of review that this type of Beta browser could engender should already have taken place long before we get to the Alpha/Beta stages, and so this shouldn't be encouraged at this point. In particular, this could be dangerous due to the unconfirmed content being too easily accessed and used in clinical systems if we make it available at this stage (whilst simultaneously stating that no-one should use it as such in the Readme file and Release Notes).

TRAG to confirm whether or not there are any new use cases for this, and if not if they're happy to close this discussion down.

  • Any new requirement for this feature?
  • If not, Andrew Atkinson to close down.

Both dependencies now called out in all Release packages.

TRAG to report on any issues experienced as a result of the change?

  • We are now ensuring that both dependencies are called out in ALL cases (as even though the dependency is inferred the TIG still requires us to state it)
  • If no further issues/concerns, Andrew Atkinson to close down.

This is planned for implementation in the July 2017 International Edition.

TRAG to confirm if there are any new issues before we proceed?

Given that this is part of the natural content authoring cycle for July now, do we need specific advanced comms on this, or just put details in the Release Notes?

  • This change was successfully implemented in the July 2017 International Edition.
  • Did anyone have any issues with the volume involved? NO
  • If not, Andrew Atkinson to close down.

10AllThis was resolved in the September 2017 US Edition - any further comments on the Negative Delta approach that was used in the resolution should be posted to the following thread: "Negative Delta" file approach
  • This was resolved in the September 2017 US Edition
  • Any suggestions for improvement? YES - See Negative Delta file approach discussions below...
  • If not, Andrew Atkinson to close down.

12Active discussions   
13Association Reference naming conventionAll

Easy one to start with - this is the proposal to change the naming convention of the AssociationReference files, to more accurately depict the content of the files. AU expressed some concerns over the summer regarding the publication of their Edition - so the question is whether everyone's happy to proceed with the changes now?

If so, should we target Jan 2018 or is this too soon - better to socialise the changes for several months first and target the July 2018 release instead?

  • Everyone agreed that this is a valid approach
  •  Andrew Atkinson to send out early warning comms
  • This will then be implemented in the Jan 2018 release
14Replacement of the Refset Descriptor file with a machine readable Release Package metadata fileAllSee David's proposal here: Reference set metadata (plus sub page)
15Categorisation of Alpha/Beta feedbackAllTRAG to discuss and agree on categorisation of the Alpha/Beta/Member release feedback issues, in time for the November 2017 International Edition
  • Andrew Atkinson Document the proposed categories, and provide many examples of each level to at least start the discussion off.
    1. Segregate into technical and clinical issues
    2. Continue to communicate through the JIRA tickets, so there's a good audit trail
    3. Provide access to the JIRA tickets not just through Release notes at the end of the Release cycle, but also mid-cycle so people can see what we're discussing/agreeing...
16First Time ReleasesAllTRAG to confirm agreement on the best approach.
  •  Andrew Atkinson added the fact that the Delta should be populated into the Packaging conventions document (section 4.5)
  • If the TRAG are in agreement with the final solution, we will send out comms accordingly. YES EVERYONE AGREED
  • Andrew Atkinson to communicate the changes out
  • Andrew Atkinson to discuss with E-learning dept to ensure Training courses are updated accordingly, along with potentially the definition in the TIG.

Release packaging conventions and File Naming Conventions


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. MOST PEOPLE STILL NEED 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...
  • ALSO we need to discuss Dion's point from the joint AG where he talked about nailing down the rules for derivative modules... - EVERYONE AGREED - Andrew Atkinson to discuss with Dion McMurtrie
  • 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).
  • Andrew Atkinson to then 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.
  • Andrew Atkinson to then ensure all relevant sections incorporated in the TIG (or at least linked through)
  • Once complete, the document should be published and opened up to anyone to view.
  • Andrew Atkinson to discuss syndication options for MLDS with Dion McMurtrie - 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.
  • 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
  • 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

Modularisation of SNOMED CT


Dion McMurtrie completed the Alpha release - did anyone have chance to review it? (I haven't had any requests for access to the remainder of the package)

The subject of Modularisation needs to be discussed between the various AG's who are considering the topic, before we can proceed with the Release-specific sections.


  • Understand the Use cases thoroughly, and refine the proposal doc to provide people with more real information - Dion McMurtrie TO PROVIDE THESE USE CASES FOR Andrew Atkinson TO DOCUMENT
  • Does the POC allow for concepts to be contained within multiple modules? NO - BUT DION CAN'T THINK OF ANY CONCRETE EXAMPLES WHERE THIS WOULD BE NECESSARY
  • What about cross module dependencies? Michael Lawley's idea on having a separate Module purely for managing module dependencies

IHTSDO Release Management Communication Plan review


This document was reviewed in detail and all feedback was discussed and agreed upon - new version (v0.3) is available for review, attached to the IHTSDO Release Management Communication Plan review page.

AAT has added in details to state that we'll prefix the comms with "Change" or "Release" in order to distinguish between the type of communications. See version 0.4 now - IHTSDO Release Management Communication plan v0.4.docx

Once we've collated the feedback from the revised comms processes that we've implemented over the past year (in the items above), we'll incorporate that into the final version and discuss with the SNOMED International Executive Lead for Communications (Kelly Kuru), to ensure that it is aligned with the new overall Communication strategy. Once complete, the Release Management comms plan will be transferred to Confluence and opened up for everyone to view.

We have publicised the Release Management confluence portal to both NRC's and the end users to get people to sign up as and when they require the information. Do we know of anyone still not getting the information they need?

We also agreed last time that the community needs more visibility of significant, unusual changes (such as bulk plural change, or case significance change). These changes should be communicated out not just when they're assigned to a release, but actually well in advance (ie) as soon as the content team start authoring it, regardless of which future release it will actually make it in. I have therefore created a new Confluence page here: January 2020 Early Visibility Release Notices - Planned changes to upcoming SNOMED International Release packages

I've left the previous items up (from the July 2017 International Edition) because there are no examples yet from the Jan 2018 editing cycle - so please take a look and provide feedback on whether or not this is useful, and how it can be improved.


Member Release period


Most NRC's (Australia, USA, Sweden, etc) were agreed that there was no longer any need for this Member Release period, as they only ever use the Member Release for preliminary internal validation, etc. However, Guillermo Reynoso expressed concerns that the removal of this phase would present a barrier to their support of members such as Netherlands, Uruguay, etc - and also with their translation of the Spanish edition.

The UK also need to confirm whether or not this would present them with a problem, given their release cycle timelines...

TRAG to discuss whether or not there are any new pro's/con's to removing the Member Release period?

Could we, for example, use the new Alpha release stage to remove the Member Release period (in order to gain an extra month of authoring)? This has resulted in us now having 5 testing phases to each International Edition:

  1. On-going testing during the authoring cycle, both through front end validation, plus weekly issue resolution using the advanced notice provided by the Daily Build.
  2. pre-Alpha testing
  3. Alpha testing
  4. Beta testing
  5. Member Release period

We now have a well refined process, which has resulted in our having removed the issues from the Member Release period. This is because we are now catching most issues in the Alpha stage, instead of in the Beta stage, and therefore the Beta is now as it should be - as close to Production level as possible.

If we have a clean Member release period for say, 2 more release cycles, can we consider the Member Release period obsolete?

In order to make this plan work, we would need to all agree the following:

  • We would need full, consistent cooperation of members in terms of allocating sufficient resource to implement thorough Alpha and Beta testing.
  • We would need to ensure enough time between Alpha and Beta phases to ensure full feedback allowed.
  • We would need to triage any Beta issues effectively to ensure that the release remains stable for all but critical issues found in the Beta period.
  •  No-one had any problem with removing the Member Release period - even Chris Morris confirmed that the UKTC only take the release from the Production status onwards (31st Jan / 31st July), and therefore removing the Member Release period would have no impact for them
  • Andrew Atkinson to discuss with Guillermo Reynoso, who is the only outstanding opponent to this proposal, and see if we can work out how to ensure that they can still meet their translation commitments...
  • Andrew Atkinson to discuss with Rory and decide if it's better to just leave this one to expire naturally as part of the introduction of Continuous Delivery (as that will inherently remove the Member release period)?
21AttributeValue records with both and Active and Inactive record for the same contentAllMatt and Mikael are convinced that this is a valid situation, so we just need to confirm that everyone is happy with not implementing any solution to this one...
  •  No-one is concerned about this, so Andrew Atkinson will close this down and run internal clean up at some point in future
22"Negative Delta" file approachAllThis approach was successfully implemented in order to resolve the issues found in the September 2017 US Edition - is everyone comfortable with using this approach for all future similar situations? If so we can document it as the accepted practice in these circumstances...
  •  NO! Everyone is decidedly uncomfortable with this solution! In particular Keith Campbell, Michael Lawley and Guillermo are all vehemently opposed to changing history.
  • The consensus is that in the particular example of the US problem, we should have instead granted permission for the US to publish an update record in the International module, thus fixing the problem (though leaving the incorrect history in place). This would have been far preferable to changing history.
  • ACTION POINT FOR EVERYONE: (Dion McMurtrie, Matt Cordell, Orsolya Bali, Suzy Roy, Corey Smith, Harold Solbrig, Mikael Nyström, Chris Morris
    We therefore all need to come up with potential scenarios where going forward we may need to implement a similar solution to the Negative Delta, and send them to AAT. Once I've documented them all, we can then discuss again and agree on the correct approach in each place, then AAT will document all of these as standard, proportionate responses to each situation, and we will use these as guidelines in future. If we have issues come up that fall outside of these situations, we'll then come back to the group to discuss each one subjectively, and then add them back into the list of agreed solutions.
  1. Preference now is to retain EVERYTHING in the Full file, regardless of errors - this is because the Full File should show the state at that point in time, even if it was an error! This is because there is not an error in the Full file, the Full file is accurately representing the error in the content/data at that time.
  2. The problem here is that the tools are unable to cope with historical errors - so we perhaps need to update the tools to allow for these errors.
  3. So we need the tools to be able to whitelist the errors, and honestly document the KNOWN ISSUES (preferably in a machine readable manner), so that everyone knows what the historical errors were.
  4. The manner of this documentation is up for debate - perhaps we add it to a new refset? Then we could use something very similar in format to the Negative delta, but instead of it actually changing history retrospectively, we simply document them as known issues, and allowing people to deal with the information in their own extensions and systems in whatever way they feel is appropriate.
  5. Only situation we can think of where we couldn't apply the above gentle response, would be copyright infringement - whereby if we discovered (several releases after the fact) that we had released content that was in direct infringement of copyright, then we would potentially have to revoke all releases since the issues occurred. However, this would raise a very interesting situation where patient safety might be compromised - as if we remove all historical content that contravened the copyright, then we run the risk of patient data being impacted, thus potentially adversely affecting decision support. This is simple to resolve when the problem is in the latest release (simply recall the release), but if found in a 5 year old release for example, it could be very problematic to recall 5 years' worth of content and change it!

This should all be documented and disseminated to get confirmation of approval from everyone.


More Frequent Delivery


We need to reconsider this on-going item, as we now have new members with additional experience, and we have also now lived with the more stable International Edition release process for the past couple of years.

Last time we discussed this everyone thought it a good idea in principle, but were concerned that we are not yet in a position to deliver the same level of quality on a daily basis than as on a monthly basis (due to the current gap in our manual/automated testing). Therefore we were going to discuss this once we had further progressed our automated testing - however as the new working group for the RVF service will testify this is a slow process, and therefore it may not be possible to wait for this to be completed in its entirety.

We have identified several additional potential issues with moving to Continuous Delivery, which we should consider before proposing a solution:

  • Perceived quality issues:

    • There would be no time for Alpha or Beta Releases - so all Members would have to be comfortable with issues in Production for until the next interim release

    • All issues that normally get tidied up as part of the normal Content Authoring cycle will become public - they will get fixed quickly but in the meantime there may be an impact to the reputation of the quality of SNOMED CT.

  • Roll up Releases:

    1. The 6 monthly delta releases would need to be relative to the prior 6 month release, and therefore named as such somehow (ie) we would need to somehow make it explicit as to which previous release the delta is a differential to.
    2. Other possibility is that each month is the same interim release, and then every 6 months we also release the Delta's relative to the priori 6 monthly release, in addition to the usual monthly release.  In this case we would need to reserve the 31st Jan + 31st July effectiveTime's /package naming for the 6 monthly roll up releases, so that the users who want to remain on 6 monthly schedule would remain unaffected.
  • The other option is to have no roll up releases at all, thus releasing a stand-alone package every day/week/month, depending on the agreed frequency. The issue with this approach though is that anyone using the Delta files (rather than Snapshot) for uploads would need to keep up with the continuous schedule.



  • Allows people to choose whether or not the users take one release every 6 months, or frequent monthly releases...
  • Derivative maps wouldn't be a huge issue as just release them whenever we had a chance, dependent on whichever edition
  • One of the plus points are that when we're still at 6 monthly releases, if the vendors miss a release its a big deal, whereas if they miss monthly releases then they have a smaller impact


  • One drawback is for the non english speaking members, who need to keep up with translations - shouldn't really have an impact if they keep up with each smaller release.
  • Could be painful for translations when a monthly release happens to contain a drop of a huge project like Drugs or something...
  • What about interoperability issues, with some people taking each monthly release, and others still waiting for every 6 months? ADHA believe this hasn't caused a huge problem for them, just an addition to the existing problem even with 6 monthly releases...
  • Also need to implement the metadata for identifying which dependent release each Delta is relative to...
  • Refsets aren't too much work to keep up to date - however Mapping is a different ball game - this can take some time
  • Maps that are still inherent in the int Edition (ICD-0 ICD-11 etc) are potentially problematic, and the workflow would need to be carefully worked out...
  • If your projects happen to drop in-between the normal 6 monthly releases, then someone who might have taken Jan and July still, might miss out on the important big releases that happen in April and November!
  • Also quality might be an issue - need to have the automated testing completely airtight before we move to continuous delivery! Thereafter you would run all major validation at input stage and ensure authors only ever promote to MAIN when everything perfectly clean. Then we run Daily builds with automated release validation every night, and provides a RAG status on release issues every morning. Then by the end of the month, we publish the last Green Daily build!

Andrew Atkinson to use all of this to continue internal discussions on whether or not moving to Continuous Delivery is feasible, and if so plan what the timelines would look like...

24Republication of core module contentDion McMurtrie

Dion was unable to make the second meeting of the TRAG in October 2017, so we need to discuss this in April 2017 - Dion's latest comment (via email) was:

Sorry I’ll miss tomorrow with SNOMED on FHIR, and I should have mentioned this earlier, but I’ve been getting questions about https://confluence.ihtsdotools.org/display/TRAG/Republication+of+core+module+content back home. 

I think substantially this is the discussion we had today about modularisation, specifically the thing we can action in the short term about ensuring rules are declared for derivative module concepts to be defined on the new module and any metadata (refset concepts for example) go on that module.

Then the other part to it is analysing the violations of these rules that currently exist and if/how/when to fix them.

Can we agree that we can progress this item soon? I think it represents the low hanging parts of the module discussion we had today.

Dion then commented on the TRAG discussion page:

Having re-read this I now disagree with myself  I think lateralisable body structure is core. Anyway I is probably not a controversial issue whether to include it or not anyway - it should be included.

Yong's response was:

Sorry, I am at the FHIR meeting as well. It is an important topic and would be very helpful if we can progress. 

My view is that derivatives should be on different modules. Currently, the module dependency refset only has three active entries. One entry is about the dependency between the core module and module component module. The other two are related to ICD10 mapping module. We discussed to use this refset for generating OWL ontology imports statement. So, we need to avoid ontology imports for derivatives, e.g. most refsets. 

If we are not going to distinguish derivatives from core content in dependency refset,  we might need to look at specifying imports in the OWL ontology refset. I will cover this in the MAG meeting this afternoon.

  •  April 2018
25Member Forum item: "Development of a validation service where releases can be submitted for testing"All

Last meeting the TRAG proposed use cases for creating an actual service (with a user-friendly UI, etc) to enable people to load up their release packages and run them through the standard validation assertions.

Standardisation is the primary use case here - everyone agrees that there is a significant benefit to interoperability by ensuring that all RF2 packages are standard and conformant to the basic standards at least - and so this is a strong business case for the service.

We agreed that whilst we have the appetite to have one, this will be a long term goal - to get us started we should use the open sourced RVF as a basis to refine the rules.

We therefore setup a working group to decide a) What the scope/targets should be b) What technology platform would be most appropriate c) What the high level rules should be (packaging format, content etc) - Working Group: Generic Validation service

The good news is that we've now used the initial discussions we had as part of the working group to refine the requirements for the ongoing RVF improvement program. This is due to complete within the next few months, at which point the working group will meet again in order to begin the full gap analysis between the various streams of validation that we all have.

Liara also discussed validation with ADHA during the London conference - Dion do you have a quick update on where those discussions got up to?

  • Andrew Atkinson to ensure that the generic service is flexible enough to fail gracefully if certain extensions don't contain some of the expected files, etc.
  • We should also provide a standard Manifest to show what files they should include wherever possible (even if blank)
26Text definition became the en-GB preferred term of an international conceptAll

Thanks to the UKTC for identifying and raising this issue - it has helped us to further refine our Validation service.

The question for the TRAG is: are there any other similar scenarios that we should attempt to pre-empt by adding validation to cover them, before they occur? 

All agreed this is a very difficult issue to identify - can't use length, and no hard and fast rules. So perhaps the only rule we could apply is that all records in the TextDefinition file must be a Definition?

  • April 2018 - Any suggestions for improvement?
  • If not then we'll close it down, as the UKTC has been informed of plans to resolve it, the content fix was implemented in the July 2017 release, and the RVF improvement ticket has been raised (RVF-273).
27Deprecation of antecedent (old) SNOMED worksAll

This is the number one priority for the TRAG this session - to come to an agreement on the cleanest method of removing the SNOMED RT Identifier refset.

The approach we agreed last time was to a) remove it from the Release completely b) Create the standard static package separately.

We also discussed at great length with the Legal team, and agreed that due to the fact that by its very inclusion in the International Edition package we are continuing to licence the SNOMED Identifier refset, we would be significantly increasing the risk of legal liability due to unauthorised use of the unlicensed content. 

We therefore agreed that the best practice approach was to remove the SNOMED Identifier refset in its entirety, rather than merely inactivating the content.


  • AAT communicated the decision to the members who raised the issue of our contravention of the RF2 standard, in order to explain to them why this is preferable to increasing our legal liability.
  • AAT removed the SNOMED Identifier refset from the July 2017 International Edition release package, and create the distinct static package as per the previous comms.

To provide a shared resource and a single source of truth on these antecedent issues we created a set of FAQs available at our SNOMED International website here: https://ihtsdo.freshdesk.com/support/solutions/folders/4000013539

  • April 2018 - This change was successfully implemented in the July 2017 International Edition.
  • Did anyone have any issues with the removal itself?
  • Did anyone have any issues themselves, or feedback from their community on how the communication went this time? We went further than normal to ensure that everyone had visibility of the changes, and understood all of the issues and rationale behind the decisions made - so any feedback would be great to see if we can improve even further next time? Any feedback to be fed into the IHTSDO Release Management Communication Plan review
  • If not, Andrew Atkinson to close down.

28New SEP Refset to be included in the July 2017 International EditionAll

Last meeting the TRAG reviewed the proposal and provided feedback.

  • This change was successfully implemented in the July 2017 International Edition.
  • Has anyone had any issues with the refsets? NO
  • Has anyone had any feedback from their community on the refsets and their real world application? NO
  • Has anyone had any feedback from their community on how the communication went? Any feedback to be fed into the IHTSDO Release Management Communication Plan review NO
  • Andrew Atkinson to close down.
29SNOMED to OWL Perl script open-source proposalAll

TRAG to consider the implications of the new scripts being compiled by the Modelling AG

Last time we all agreed to 1) Wait for the document to be completed by the MAG which defines exactly what SNOMED CT should look like in OWL 2) Ensure that both the old PERL and the new Python scripts work completely and document all caveats 3) Ensure when we open source them both, we clearly call out what kind of SNOMED packages each does/doesn't work with (eg) International + extensions, but not derivatives?

Harold Solbrig to provide an update on when the MAG the document to be available.

  •  April 2018 - Harold to provide an update...
30Implementation Load TestAll

RVF has now been open sourced to allow people to contribute towards it more easily, so that Implementation issues can be reverse engineered into the assertions. All of the NRC validation systems should remain separate, in order to ensure as great a coverage across the board as possible.

However, it makes sense to ensure the critical tests are included in all systems, in order to ensure that if, say, one NRC doesn't have the capacity to run Alpha/Beta testing for a certain release, we don't miss critical checks out. We are working on this in the Working Group, and also in the RVF Improvement program, where we are including the DROOLS rules, etc. These are also being incorporated into the front end input validation for the SCA.

TRAG to therefore discuss taking the Implementation Load test forward, including the potential to incorporate key rules from NRC validation systems into the RVF. So we should discuss the tests that are specific to the Implementation of vendor and affiliate systems, in order that we can facilitate the best baseline for the RVF when agreeing the generic testing functionality in the Working Group.

  • Matt Cordell will promote some useful new ADHA specific rules to the RVF so we can improve the scope...
  • Chris Morris to do the same - get the RVF up and running and then promote any missing rules that they run locally.
31Discussion on the conflict between Extension content and International contentAll

The answer to this may be quite simple:

  1. If extensions promote content via RF2 delta, we just need to retain all ID's, and only change the ModuleID and effectiveTime, and therefore it is all managed by effectiveTime.
  2. If IHTSDO reject content this is also managed
  3. The only issue then comes if IHTSDO want to change the FSN, then we ned a way to manage the change of the meaning of the concept without creating 2 FSN's - as then we need a feedback loop to ensure that it's also corrected at source in the extension as well as in the International edition.

TRAG to continue the discussion and come to a conclusion that will work for all.

  • Has this been answered in its entirety by Jim's new agreed approach? (link here to his final position)
  • Most people consider that Jim's approach covers this under most circumstances. We also need to ensure that we follow the approach listed to the left - so we should confirm all of this has been working in practice in April 2018, and if so close down.

Spanish Namespace switch 

AllHas anyone though of any issues whatsoever with termMed creating a new namespace for the Spanish edition? If not, they are planning to implement this for the October 2017 Spanish Edition.
  •  Everyone is happy with this change, so we will keep this topic open for another 2 conferences to keep an eye on any unintended impact (as the first Spanish Edition containing the new namespace will not be published until the 31st October 2017), so people should continue to provide feedback.
33Additional, non-defining RelationshipsAll

TRAG to continue the ongoing discussions. The SEP refsets have now been deployed, so are we happy that this has resolved the majority of the issues, or do we still need to push for a full re-factoring of the anatomy content asap?

No change expected for the Jan 2018 release.   Part-Of relationships will once again become defining once we have the OWL Refset changes in place.   So they will become stated relationships rather than additional.

  •  April 2018 - based on how the Jan 2018 release goes, we should ensure that the SEP refsets are still valid. We also need to discuss the impact of the OWN refset changes.... (ask Harold for an update on the MAG discussions on this)
34Shared ClassifierAll

TRAG to consider the full implications of the proposal to have a shared classifier.

This has now been given the green light internally - so the question now is how we can help to refine the proposal?

Harold to give an update on the MAG's plans?

35Proposed changes to the classification wrapper to support new Drug ModelAll

TRAG to consider the full implications of the proposed changes

Harold to give an update on the MAG's plans?

36Combining the Component Model and Core Modules into oneAllTRAG to provide any further evidence for/against this proposal, to add to the internal discussions that are currently ongoing
  •  April 2018
37New Early Visibility pageAll

Has everyone checked out the new page here:

January 2020 Early Visibility Release Notices - Planned changes to upcoming SNOMED International Release packages

Any suggestions for improvements, etc?

  •  April 2018

Concrete Domains


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 G. Williams, therefore, will take 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 currently most popular approach suggested is to create a 2nd inferred file 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.

Harold to give an update on the MAG's plans?

39AG Declarations of InterestAllCould each of you please go in and update your information? If there has been no change, then you can simply update the last column with the date. 
  •  April 2018
40Any other questions / issues?All