Content Managers Advisory Group

Page tree

Cathy Richardson

Owner
5271 View 12 Comment In discussion Comments enabled In the category: Undefined

Note: This item has been moved from the Blog section of this space. Comments and feedback should be added here.

To resolve any conflicts in understanding of the SNOMED CT license for members about what content changes are permitted within extensions, the IHTSDO member countries are seeking consensus as to what types of changes are allowed.
Whilst it the IHTSDO could declare or prohibited certain extension types outright, consensus with members of the Content Managers advisory group would ensure any decisions are align with member expectations and requirements.
The original discussion paper is available here. Members are asked to provide comment on the following statements:
Members are allowed to create new concepts.
Members are allowed to fully define concepts they create.
Members are allowed to state additional IS A relationships against core (international) concepts. (Specifically to newly created concepts.)
Members are allowed to classify terminology extensions.
Members are allowed to retire (redundant) IS A relationships (not necessarily stated).
Members are allowed to add additional defining (non-IS A) relationships to primitive core concepts.
Members are allowed to retire content considered "inappropriate".
Retire concepts
Retire relationships
Retire descriptions

Additional descriptions and language preferences are unanimously supported. Any of the above edits, are required to be RF2 compliant, with the ability to extract an "unaltered" international release if required.
Ian/Matt

Contributors (6)

12 Comments

  1. Elaine Wooler

    Hi I have started a discussion regarding this in the UK which I'm hoping I will have feedback on by our next meeting.

  2. Elaine Wooler

    Following a brief discussion I've had some comments that to be able to provide some useful feedback would it be possible to restate the questions as follows:

    a) Could we have a declaration of whether/where each question refers to international components or extension components, and clearer language on the nature and direction of relationship changes (what does ‘against’ mean in “...state additional IS A relationships against core...”  people think they know but others would like it specifically stated.

    b) Could we have worked examples for each change pattern (including non-pharmacy examples)

    c) Corresponding illustrations of how the distributed data (actual rows in actual files) would change – we can then see, for example, how the ‘retirement’ proposal at the end interacts with established module/component ownership constraints.

    Sorry this is a bit more work but I think we might get more consistent and objective responses.

    Many thanks

    Elaine

    1. Matt Cordell

      Thanks Elaine,

      a) Anything an extension builder (usually NRC) does is an extension. This could be concepts, descriptions, or relationships.

      • Descriptions - non-contentious. Mandatory for translations.
      • Concepts - non-contentious if NRC only creates primitive concepts. (see relationships).
                        - There's some desire to also retire concepts we simply don't want. Generally these would be defects, that might remain unresolved in the international release for years - for various reasons. Not actioning them gives our stakeholders the impression we've ignored the problem. Fortuneatly there's very few of these, and usually we implement some work around.
      • Relationships - This is what's really under discussion.relationships where the sourceId is an international (core) concept
        If the NRC is creates Fully defined concepts, and uses a classifier - It's quite possible that relationships will be added to core concepts. ("against").
        core relationships could also be inactivated if they're redundant, due to the new extension concepts being intermediates

      b) Examples to follow/in other responses.

      c) The changes can all be managed through the RF2 history mechanism. Here's an example of a concept we retired this month, and how it could/should end up in the January 2017 core.

      384613002 20030131 1 900000000000207008 900000000000074008
      384613002 20160731 0 32506021000036107 900000000000074008
      384613002 20170731 0 900000000000207008 900000000000074008

      • The first row here is when the concept was created in 2003.
      • The second row is the concept being retired on the AU module (32506021000036107)
      • The third row is the retirement appearing in the subsequent international release (on the core module).
      • The middle row never appears in the international release.
      • The Full Australian release would show all three rows after we update to January 2017* if the retirement was considered valid. The IHTSDO might disagree with our choice to retire and not "promote" the change.

      (This process should also be how the IHTSDO manages general content promotion. (ie. All IDs are retained, and modules changed) - this reduces maintenance burden for those who create extensions, and encourages promoting content to the core - and hopefully improving the overall quality of the product.)

  3. John Fountain

    I've raised this issue within the NRC, via a national SNOMED discussion group and with specific vendors.

    There is no tangible response thus far.

    I would agree with Elaine that more detail regarding the statements, with examples, would be helpful in encouraging feedback/comment.

    Cheers

     John

  4. Linda Parisien

    Hi, I can't recall was the ' The original discussion paper' ... that is not available above... can we add it please? Thanks.

  5. Linda Parisien

    Hi, I would also like to see some examples related to relationships. I'm not sure when we would want to add to primitive core concepts defining (non-IS A) relationships. Can you provide use cases? 

    It think we would also need to make sure our actions are based on best practices.

    1. Matt Cordell

      This probably isn't such a priority (and we haven't done edits such as this yet), but the use case would be to contribute to the modelling/improving the product. There's a legacy content that's primitive, and could be defined. As well as legacy content that's poorly modelled. I've just included it, so that we might get clarification if it's an option.
      It'd be nice if this option was available to NRCs, but again no obligation for IHTSDO to take it on (especially if it's not-valid).

  6. Cathy Richardson

    The relevant paper is located on the topic page: Extension Management Proposal

    Regards,

    Cathy

  7. Elze de Groot

    The discussion of above was started because according to the license agreement (interpretation-dependent) members were not allowed to create concepts that were not leaf concepts. That ofcourse would be unacceptable, because in this way you aren't able to create new concept in the right place in the  hierarchy and ih this way you are not able to define the concept in a proper way.

    Of the list of statements above I miss the extension involvement. Ofcourse members cannot change or retire concepts from the core. But they should be able to create new concepts and descriptions in the extension in a correct way.

    I don't see the usecase for being able to retire concepts of the core. There is a change request service when a concept should be retired because of an error or other reason. When a member don't want to use the concepts in its country, don't add it to your refsets. Or is there an usecase?

     

    My comments of the list:

    Members are allowed to create new concepts .-> YES for their extension

    Members are allowed to fully define concepts they create. -> YES for their extension

    Members are allowed to state newly created additional IS A relationships against core (international) concepts. -> YES, if this means that the core concepts can be the subtypes of primitive or fully defined extension concepts

    Members are allowed to classify terminology extensions. -> YES please! We already do so. The primitive parent approach is the best way to get the newly created concept in the right place in the hierarchy.

    Members are allowed to retire (redundant) IS A relationships (not necessarily stated). -> this is a tricky one. Because you add a new concept between two core concept, the ISA relationship between the two concepts becomes unneccessary in the extension (it still exists but is replaced by two new relationships). I don't think you want to retire this relationship, because it still accounts, it is still true, but you don't want it to show up in your (for example) browser or tree.

    Members are allowed to add additional defining (non-IS A) relationships to primitive core concepts -> Yes but then it becomes a new concept in the extension. When the member wants to retire a relationship because of an error, the member is able to request a change to the concept.

    Members are allowed to retire content considered "inappropriate". -> only extension concepts

    Retire concepts -> only extension concepts

    Retire relationships -> When you want to retire a (attribute) relationship of a core concept, the meaning changes and it becomes a new concept in the extension. When the member wants to retire a relationship because of an error, the member is able to request a change to the concept.

    Retire descriptions -> only extension descriptions

     

     

    1. Matt Cordell

      re: the redundant IS A. The reason you've stated (tree view) is why you might want to. Part of producing the distributed normal form should be removing these. It's odd leaving some not others, but probably harmless for transitive queries.

  8. Matt Cordell

    Here's some examples of concepts we've created. (examples are links to Shrimp)

    |Tree nut|  - this was a requested intermediate primitive concept, and various existing core concepts had IS A relationships added to them (with "Tree nut" as the destination). This one, we published with the redundant IS A, but I just noticed the Shrimp graph hides that (smile).

    And here's a few surgical procedures we've modelled, that subsume existing concepts.

    |Debridement of lower limb|

    |Closed reduction of fracture of distal tibia|

    |Phalangectomy of finger|

    And another example of a recent defect reported to us - 253973006|Endemic polyarthritis|. We haven't retired the IS A relationship yet, and still determining were exactly it should sit in the heirarchy (239883006|Endemic osteoarthritis| or higher...) as well as the relationship 602001|Ross river disease| (and others) should have to it.

  9. Matt Cordell

    Discussion concerning new version of document posted August 4 2016 continues over here.