17 Feb 2016 - 21:00
Progress update on reviews of previous Discussions topics:
*** 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?
|All||Andrew 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.
New Metadata concepts for derivative releases
The good news is that we have now introduced the separate modules for new derivative product releases.
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?
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?
|All||Everyone 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)|
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
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
|Michael||Defered 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
|Liam||Andrew 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.
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.
|IHTSDO Release Management Critical Incident process.docx||1||2016-02-17 16:43|
|Retirement of Refset Final.docx||1||2016-04-01 09:31|
|No content found.|