2016-02-17 - TRAG Meeting Agenda/Minutes


17 Feb 2016  -  21:00


  • 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 face to face April conference meeting

Discussion items


Progress update on reviews of previous Discussions topics:

  • Release versioning
  • Additional, non-defining Relationships
  • Release packaging conventions
  • Modularisation of SNOMED CT
    • An agreement to create a top level module above the core/metadata modules has been reached - Dion is producing an Alpha release - ETD?

*** We need to achieve these reviews in time for the April conference.

*** Please can you add a comment once you've reviewed each discussion topic, even if you have no feedback - then we can ensure that everyone has reviewed before we proceed?


Andrew Atkinson explained that we had not as yet received enough feedback to consider the Discussion topics reviewed and approved. Everyone therefore agreed to review all of the Discussion topics and add their comments (even if this was just to say that they had no further comment) before the April meeting.


Release Management Critical Incident Process - we have completed a prospective process (please see the attached doc), please review it and then we can discuss filling in the specifics such as who prioritises the incidents/agrees the plan of action, who to sends the comms to (just Release Management Confluence Blog?),  etc.

*** Particular attention should be paid to the Process diagram on page 9, where the Terminology Release Advisory Group is down to assist in the triage and resolution planning for the Incidents - does the group think this is a reasonable scope, or should this be assigned to a dedicated sub-group of the AG?

AllAndrew Atkinson explained the purpose and scope of the document. Everyone agreed to review the new Process and provide their comments (even if this was just to say that they had no further comment) before the April meeting.

Continuous Delivery - as previously discussed an implication of moving to Continuous Delivery is multiple effectiveTimes in each release - is this an issue? (TIG allows for it already, but we’ve never done it before)

Liam to confirm if he got a response from his team?


Mikael Nyström asked if we would move to multiple releases per day (as if so the Date field would need to become a DateTime field) - Andrew Atkinson confirmed that this was extremely unlikely (even in the long term), as the current plan is a phased approach, starting at monthly releases and working down through weekly to daily releases in the long run. The efficiency gains are outweighed by the overheads once you move to multiple releases per day, and so this is unlikely to ever be a realistic option.

Corey Smith asked if the 6 monthly releases would stay on January 31st and July 31st - Andrew Atkinson confirmed that they would for the foreseeable future, but that we will ensure that the Release versioning will be flexible enough to cope if we were to move the dates at some point in the future... (so the version would link to whatever date range existed between the new 6 monthly release dates, allowing people to effectively trace back the changes between the 6 monthly releases)

Eric Robertson confirmed that he could see no issues with multiple effective times, but will ask his vendors.

  • Liam Coughlan to talk to a broader audience on 23rd Feb 2016 - will feedback then.
  • Eric Robertson to talk to vendors and confirm no issues with multiple effective times.


New Metadata concepts for derivative releases

The good news is that we have now introduced the separate modules for new derivative product releases.

  1. The first question is whether we now need an agreed set of editorial guidance for metadata concepts?  For example, we created new modules for the ICNP and GP/FP releases, in order that we could re-package them according to our previous discussions on modularisation of derivative releases - we named them as follows, but should we agree conventions to follow when naming them, or are we happy to name them however we see fit?
        • International Health Terminology Standards Development Organization general and family practitioner module 715152001
        • International Classification for Nursing Practice and SNOMED CT equivalency mapping module 715151008

  2. The second question is whether or not we should treat the two derivative releases (ICNP & GP/FP) which had already reached Production stage as "new" releases (i.e. Delta files contain ALL content, Sept 2015 editions effectively treated as Beta releases), or as "subsequent" releases (i.e. Delta files contain ONLY new/updated content, relative to the Sept 2015 editions which are treated as Production releases)?

    ***** The result of Andrew Atkinson's investigation was that the IHTSDO approach to the segregation of modules was pitched at the correct level. The new derivative modules have purposefully been created as children of the Core module, in order to ensure that each product retains the required dependency on the core content of SNOMED CT. None of these products should be considered standalone, and if they are implemented as such then the expected gaps in analysis will be highlighted accordingly.
  1. Mikael Nyström would like to have guidelines, so that if NRC's start to create their own modules, then they should also follow the same guidelines.

Corey Smith would also like us to ensure that we have the ability to change the names, and have an audit trail of changes.

2. All agreed that the best way to approach this is to retire the previous release components, and create a completely new release with the new modules inherent. In addition, we need traceability back through to the retired concepts, which should be possible due to the fact that the new Modules are within the Core module itself ****** though this raises the question of the effectiveness of the new modules in segregating the content, as they are within the core module?


  • Andrew Atkinson to add a new discussion topic and set initial guidelines so that everyone can review and feedback before the April meeting.

  • Andrew Atkinson to investigate whether or not the approach to segregating the modules is effective, or if it needs to be re-considered.
  • Robert Turnbull has added the creation of editorial guidance for the new metadata concepts to the work plan for the Product Architecture team, for them to action.


MLDS as the sole distribution platform

Has everyone successfully used MLDS to access the Release packages now?

We have purposefully not uploaded older versions of Release packages (especially those from more than 2 years ago), as although normal Release Management calls for a clear audit trail going back as far as possible, in our particular case it’s potentially dangerous to have old, outdated data available for people to accidentally use. Archived packages therefore, will be available on request only, with valid reasons stated - are there any perceivable problems with this approach?

AllEveryone is happy with this approach, so long as the older releases are available on demand for anyone who has a potentially valid use cases (research purposes, etc). All on board with n-1 or n-2 in terms of actual releases rather than years, so could cut it down even further in future (especially given the inherent audit trail within the terminology)
  • Andrew Atkinson to consider further reducing the available releases to n-2 versions rather than n-2 years...

Member question:

Any case studies on using multiple language within the same package? We have a member who is attempting this:

We have recommended using multiple language files, one for each language, as this way you can remain in line with our filename formatting conventions, and set the language code in the filename to the relevant code for each language.  Not only does this make the package more human readable, but it also allows for multiple dialects to be represented within each language file.

However, they responded as follows:

In your example of en-gb and en-us I do agree with you and with patient language I can agree with your solution of separated RF-2 files because it is about the whole SNOMED CT international set. But when I think of jargon it seems a little bit devious to me. In that case it's about a subset of SNOMED CT (actually a refset) where in some cases a synonym becomes a prefered term and the other way round.

For example in the cardiologist refset:

Disorder of heart (disorder)

Disorder of heart -> preferred term for the Netherlands (dutch translation) - all specialists like internal medicin

Cardiac disorder 

Morbus cordis -> preferred term for cardiologist


The case is the only thing that is different is that there is a pointer to preferred accept for synonym. The description is usable for as well cardiologist as the general translation. So is it really necessary to make a separate RF-2 for every discipline that want some other preferred terms as in the general translation, is that the most efficient way to do that?


No use cases, but feels like they will have to choose which is their preferred term (either globally or manually). This is an implementation issue however, and so no-one can see any way in which we could improve the IHTSDO offering.

They should also be made aware that the Latin terms have dialects as well, in that Dutch Latin is different from Swedish Latin, etc


Member question (related):

Any case studies on the following situation, requiring

I have a question for you about namespaces and country specific translations. Currently, we have two extensions: one in English and one in French.

·         EN Namespace: 1000087

·         FR Namespace: 1000077

For the French, we only author descriptions.  These are French translations of core or local concepts.  Currently, we produce two separate extension files, one for the full English extension (concepts, descriptions, relationships) and one for the French descriptions. Going forward I would like to produce one extension that includes both EN and FR together, ultimately as an edition.

Can we just simplify and use one namespace ID?

There is nothing in the translation guides or the TIG about needing a different namespace to support a translation that I could find. Have we perhaps made it more complicated by authoring in two extensions? Can you please tell me if we need a separate namespace for the French according to any IHTSDO best practices where namespace mgmt. is concerned?

Do you have any insight into how the Danish and/or Swedish extensions are handled in both EN and in their respective languages?


Swedish and English descriptions were first of all assigned different namespaces, but they then realised that this was unnecessary in RF2 - so only one namespace ID is planned for use in Sweden for multiple languages.

Corey Smith also thought that there would need to be a very good reason to split the namespace ID's due to the maintenance overhead, but then they need to consider the versioning implications of only having one namespace ID.

So again no hard and fast rules, just opinions on how they could do it.


Michael Lawley's issue with the MDRS:

Ignored data from module '449080006' found in 


This is basically saying that the MDRS data in the Snapshot file includes rows that it shouldn’t — the Snapshot is of http://snomed.info/sct/900000000000207008/version/20160131 and thus should only contain data from the module 900000000000207008 and modules that it depends on, as stated in the MDRS - the only one is 900000000000012004

 I can also confirm that loading from the distributed Snapshot data (but computing the actual rows from the MDRS info) and loading from the Full data (and also, obviously, computing the actual rows from the MDRS info) produces the same number of concepts, descriptions, relationships and associated axioms for the classifier.

IHTSDO responded that the current approach is in line with the TIG on this (and has been historically, as this approach has been taken in previous releases with no reported problems) - please see the following direction for stating dependencies:

"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."    www.snomed.org/tig?t=trg2rfs_spec_module_depend_usage

Michael responded to say that the issue he was raising is that the module 449080006 is not one of the module that the international release depends on itself (it us not a target module of 900000000000207008), and therefore no rows with 449080006 should be included in the Snapshot data files.

To be clear, I believe neither of these rows should be in the Snapshot MDRS

 MichaelDefered to next meeting when Dion McMurtrie is available... 

Liam Coughlan's issue on the standardisation of Release folder naming conventions:

It was unclear whether we should be replicating the same folder structure which has been adopted by IHTSDO and whether this will put us at an advantage to meet future strategic changes (i.e. easier to have this structure if we adopt a more frequent release cycle) . Our proposal is for example: 

RF1 UK example would change from

SnomedCT_GB1000000_20151001 to SnomedCT_RF1Release_GB1000000_20151001

 LiamAndrew Atkinson provided advice on this based on IHTSDO approach to the naming conventions - all agreed.

Liam Coughlan's issue on the retirement of refsets:

We have noticed the following behaviour with Refsets and needed confirmation from IHTSDO on whether this is deliberate before we decide on whether we need to correct any functionality or not:

Refsets retired in April 2015:

Concepts retired from Metadata

All members set to inactive

All history of membership intact.

What happened in Oct 2015 via migration utility:

Concepts still in Metadata as retired

All history of the membership removed as if the refset never existed.

IHTSDO position:

There are two possible approaches here, as detailed above - both have issues, but the last time we discussed this the prevailing preference in the Advisory Group was to retain the history in the International edition.

The major issue with this is that then if a customer wants to consume the segregated refset, they would then have to download the entire International edition just to gain access to the history for that one refset.

Does anyone have another, less problematic solution to propose?


Most people still of the opinion that the history should be retained in the International edition - however everyone is mindful of the theoretical use case of the customer who wants to consume the segregated refset.

Andrew Atkinson provided the concrete example of GMDN refset from last year, which was required for consumption outside of the International edition after retirement - however this is an outlying example as this situation should never re-occur (due to the fact that any other product with similar licensing restrictions will, going forward, always be published separately to the International edition from inception).

The group therefore requested further examples and use cases to consider - Liam Coughlan agreed to investigate and provide these accordingly.

  • Liam Coughlan to investigate the potential use cases for the customers who may want to consume the segregated refset, and provide examples so that everyone can consider the issue further.

Meeting Files


Previous Meetings

No content found.