Content Managers Advisory Group

Page tree

Date

8th, March 2016 at 20:00 - 21:00 UTC

GoToMeeting Details

https://www.gotomeeting.com/join/145184445

Attendees

  • John Fountain, Daniel Karlssen, Olivier Bodenreider, Camilla Wiberg Danielsen , Elaine Wooler, Rossana y Betania, Elze de Groot

OBSERVERS - Penni Hernandez, Cathy Richardson, Toni Morrison

Apologies

  • Linda Parisien

Objectives

  • Review of proposed changes to laterality representation, and agreement of way forward
  • Review of proposals for extension modification, and agreement of way forward
  • Update on development of default drug model for national extensions

Discussion items

ItemDescriptionOwnerNotesAction
1WelcomeIGR
  •  
2Apologies/conflicts of interestIGR 
  •  
3Laterality proposalIGR/ALL
  •  
4Default drug model updateIGR 
  •  
5Extension modificationIGR/Matt

  • Document - "Clarification of license conditions to

    allow extension builders to modify the

    international content".

  •  
6Any other businessALL  
7Date of next meeting   

Meeting Files

  File Modified
PDF File ClarificationofExtensionModifcations.pdf 2016-Mar-07 by Ian Green

 

Previous Meetings

TitleCreatorModified
No content found.

 

6 Comments

  1. Linda Parisien

    Hi Ian,

    Do you have a written document on the 'Extension modification' topic?

    1. Ian Green

      Hi Linda,

      Go to tonights meeting page, its under meeting files,

      Talk later,

      Ian

      1. Linda Parisien

        Thanks Ian.

        Here are my comments after reading the document:

        1- I agree with the idea of adding info in the TIG, but I think this topic requires additional educational information from the model, editorial and description logic perspectives as to what is not allowed to do and why vs the preferred way to develop content or the best practices for developing/extending content.

        2- If countries are allowed to change rules for their extensions, I think that would be useful to have a space for sharing of the what, the why and the outcomes and impacts.

  2. Linda Parisien

    I will not be able to join the call today. Hopefully this session will be recorded. I will listen the recording and provide any requested feedback if appropriate. Thanks.

  3. Daniel Karlsson

    I will be able to join the call tonight (today, tomorrow, ...), any way my comments are:

    1. being a non-native English speaker I have always interpreted the phrase as "don't change the meaning of international release content" not as "you can't change any derivative" (where the DNF is a derivative of the stated form).
    2. addressing pressing quality issues I believe should be managed centrally (with possibility of distributing the actual modeling)

    1. Matt Cordell

      Apologies for missing this meeting, and it's taken me a while to get around to finding this discussion. And thanks Ian for presenting the item.

      There's two reasons for the proposal.

      1. While it would be ideal for all quality issues to be managed centrally, realistically I don't think it's feasible. The number of tracker items is large, and the IHTSDO has limited resources. Everyone's seen items that are years old. As an NRC, when a customer raises an issue - unless the NRC fixes it, they're at the mercy of the international releases scheduling. And have to continue taking enquiries about the issue until it's resolved. This has local reputational consequences for SNOMED CT extensions, but these could spread globally. Extensions are obligated to pass these changes up to the core, so they should eventually propagate to all members.
        There's obviously a scale of complexity in the potential changes from spelling mistakes to missing relationships, to large scale modelling.
        Ultimately it'd be great if NRCs could resolve these issues as they saw appropriate, coordinate with other members and IHTSDO as required. And the IHTSDO still has final say on if the changes are internationally valid/quality.
      2. Simply creating valid DNF extensions. With the "Aspirin tablet" example in the paper. If extensions created Defined content as per the "prohibited" example (which is the goal) - unless redundant IS A relationships are able to be retired, the extensions isn't really DNF compliant. We're using Snorocket as our classifier at the moment, and our classification process won't touch core relationships.

      At least some members are already making such changes, and the paper was really intended to provided a clarification so everyone is on the same page.