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?

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?

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?

5

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?

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

Cardiopathy

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?

Michael Lawley's issue with the MDRS:

Ignored data from module '449080006' found in 

/SnomedCT_RF2Release_INT_20160131/Snapshot/Refset/Metadata/xder2_ssRefset_ModuleDependencySnapshot_INT_20160131.txt

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

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

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?