National content identified by a second country as useful
While not currently common we are receiving requests where an NRC identifies a concept in another country’s extension that they would like to see promoted to the International Edition, so they too can use that concept.
At present a formalised process does not exist and to support the development of one we are seeking input from CMAG members. When finalised this will be included in the CRS guidance.
Would you please add your comments here on how you see this process working by July 12th. Your thoughts will be pulled together, and a draft process developed. We will look to finalise agreement on this at the August 2019 meeting.
Thank you.
Actions: Feedback period extended to Friday 30th August.
Date | Requested action | Requester(s) | Response required by: | Comments |
|---|---|---|---|---|
14 August 2019 | Response on topic noted above. | @Maria Braithwaite @Cathy Richardson
| @Camilla Wiberg Danielsen @Daniel Karlsson Aug 30, 2019 @Former user (Deleted) Aug 30, 2019 @Elze de Groot (Unlicensed) Aug 30, 2019 @Former user (Deleted) Aug 30, 2019 @Linda Parisien Aug 30, 2019 @Matt Cordell @Former user (Deleted) Aug 30, 2019 @Jostein Ven (Unlicensed) Aug 30, 2019 @Theresa Barry Aug 30, 2019 @Former user (Deleted) Aug 30, 2019 | Please post your responses as comments below. |
Comments
Although we still have little use of SNOMED CT in DK and very little experience with the issues in implementations that this type of promotion might give, I agree with Matt. Remember to take into account that the same concept may exist in two (or more) extensions. Therefore, there will have to be a procedure to decide which concept ID should be promoted. /Camilla
In Canada, we are also in favor of any actions that would allow for decreasing the development and maintenance efforts, as well as increase accessibility to already existing content. That also comes with some considerations: the first country to submit is currently the one that will see its conceptID kept, that is fine. How can we assure that content meeting many countries requirement stay active in core overtime? How much time will it take for SI to integrate in core the requested content that meets more than one country's requirements? Will the "needing country" still have to create content in its extension and eventually will have to inactivate that content once available from core, with additionaly, a change to the conceptID?
I think currently the way to validate if similar content is available is to do a search in each countries editions. This is quite laborious and really ineffective, non sustainable. How can we enhance this?
What would be helpful is to be able to search by concept definition in the browsers, so we could flag concepts that might have a variance lexically, but are semantically equivalent.
I am interested in hearing more from Matt on how Australia intends to "We're about the start consuming this directly."....
Hi Linda, Our most immediate focus in this regard is the Dietetics/Nutrition content. There is international demand to standardise the codes used in this field, and much of the content already exists in the US content. It's preferable to the users we adopt the US codes, rather than recreate in AU (as they'd then have to maintain a map).
Our plan would be to extract the concept IDs identified by our users, and all associated components described above and then publishing them on an AU module.
Should the content be promoted (by US) to the International edition at a later date:
If all the US Ids are maintained, the core module will supersede the earlier AU version.
If only the concept ID is maintained, we (AU NRC) would have a bit of maintenance to clean things up. (e.g. multiple FSNs on a concept, duplicate relationships or axioms). All of which we'd detect automatically (but resolve manually, for now).
The genetic work done by the Nebraska extension is a possible candidate too, but not an immediate priority.
I haven't looked at the content in other extensions enough, to see what else we might be interested in. So at the moment, it's just based on external user requests.
We'd probably periodically check the extension (e.g. US) for any changes to content we've pulled. (Dependent on parallel core promotion.)
We'd certainly support this from both ends.
Us and our Users would much prefer any extension content we have created be persisted rather than replaced by INT concepts at a later date. (Users especially map owners are challenged with maintenance).
There is content in other extensions (not just NRC) that our users want. We're about the start consuming this directly.
I've raised this several times over the years (vertical promotion and horizontal promotion, respectively for the above scenarios), and it's been discussed but never pursued but SI. I think mainly because it only impacts NRCs and users. And there's no problem for the International release to do nothing.
The benefits of doing this properly are that users get more content, with less maintenance burden. Maintenance being the focus. And Identifiers being key to maintenance.
With the upcoming changes to DL, more than one axiom can co-exist at the same time - so little maintenance issue there.
Inferred relationships - Would be nice to retain IDs. But I think we've given up on trying to avoid churning relationship IDs. It's really difficult, especially around grouped attributes, and there isn't any obvious benefit for users.
Description ID - this is mainly about minimising the impact on the originators of new descriptions. We've done a lot of work introducing consistent preferred terms. If such terms were duplicated in core - we'd need to retire ours. But to be honest this process can be automated. It just introduces bloat, in terminology files. Users should be doing much with description IDs (though some do). Extensions who maintain translations might also have comments? I'm not sure about the process.
Concept ID - this is crucial. Everything revolves around the conceptId - so retaining this means less cost on maps, refsets, decision support, longitudinal analytics etc.
Refsets - This is a separate issue. personally, I'd prefer core to contain no refsets, that are not core...
So in short, I'm all for this. And keep the Concept ID is critical. Not keeping the concept ID is against the best interest of the originating extension, and all their users.