SNOMED CT Templates

Page tree

StatusIn PROD
Version

1.0

Latest version2.0

Descriptions:

Termdescription typeLanguage/acceptabilityLanguage/acceptabilityCase significance
[Periods of life] [Fracture morphology] of [bone structure] (disorder)FSNus:Pgb:Pci
[Periods of life] [Fracture morphology] of [bone structure]SYNus:Pgb:Pci


Concept model:

Attribute Cardinality

AttributeValuerole group numberAttribute Group Cardinality
1..1

116680003 |Is a (attribute)|

64572001 |Disease (disorder)|

0



N/A

1..1

116676008 |Associated morphology (attribute)|

[Fracture morphology] << 72704001 |Fracture (morphologic abnormality)|

1






1..*

1..1

363698007 |Finding site (attribute)|

[bone structure] << 272673000 |Bone structure (body structure)|

1
0..1

246454002 |Occurrence (attribute)|

[Periods of life] <<  282032007 |Periods of life (qualifier value)|

1

Definition status:  


900000000000073002 |Defined (core metadata concept)|

Applies To:

<< 125605004 |Fracture of bone (disorder)|

Rules for description generation:

  1. Remove the semantic tag, e.g. (body structure)
  2. Remove 'Structure of' from [body structure] if term starts with 'Structure of'   e.g. 709530002|Structure of phalanx of hand (body structure)|
  3. Remove 'structure' from [body structure] if term contains 'structure', e.g. 69536005|Head structure (body structure)|   24097009|Bone structure of hand (body structure)|

JIRA ticket:

QI-54 - Getting issue details... STATUS

INFRA-2549 - Getting issue details... STATUS

24 Comments

  1. Peter G. Williams

    Hi Yongsheng Gao Kai Kewley   I'd like to add a section to these pages, something like "Application" or "Applies To" and then have a list of concepts, from which point down this template can be applied.    So in this case that would be << 125605004 |Fracture of bone (disorder)|   

    I don't think it's possible to determine that information from this page as it stands?   I'd also like to represent that in the JSON.    The immediate use case is to allow automation of checking for template conformance in the appropriate sub-hierarchies.     A secondary use case would be in the form of Author Decision Support so that we could offer the user the appropriate template(s) for what they're working on once we know the parent (interesting workflow / UI implication there that we'd need to be told the immediate parent but the template will assert the proximal primitive eg Disorder).

    I didn't want to just make that change because I heard Yong say there was already some code to generate the JSON from these confluence pages?

  2. Kai Kewley

    Hi Peter G. Williams . Yes please that would be useful.


    We can just update the template generation code which has just really a workflow helper for me:

    https://git.ihtsdotools.org/ihtsdo/snomed-template-service/blob/master/src/test/java/org/ihtsdo/otf/authoringtemplate/TemplateAuthoringHelper.java

    Example input - https://gist.github.com/kaicode/16916275b80b4d9b1859cc7258f28716 (I copy the contents of a 'Concept model:' table not including the header).

  3. Yongsheng Gao

    Peter G. Williams, It sounds good and convenient.   

    Yes, this concept can be determined from the template as it stands. It is fully defined as |Disease|:{|associated morphology = fracture, |finding site| = |bone structure|}. It is possible that a precordinated concept might not exist for a template. For example, the template created by Jim for pathologic fracture of bone structure due to a disorder. 

  4. Peter G. Williams

    Jim Case  I wondered what you thought of my suggested optional attributes here - Due To and Occurrence.     I'm trying to make the concept  206211008 |Fracture of humerus due to birth trauma (disorder)| acceptable.   What do you think?   FYI Yongsheng Gao Kai Kewley this necessitated adding both attribute and group cardinality into the table.

  5. Jim Case

    Peter G. Williams, interesting that you bring that up because I just drafted a new template for birth trauma after revising that section this week.

    See: Disorder due to birth trauma - In progress

    You can see that it is a different pattern than the normal fracture template

  6. Jim Case

    Peter G. Williams I am trying to understand the meaning of "role group cardinality".  Does this mean that multiple attributes of the same type are allowed within a role group?  If so, this is not correct.  While it may seem that there is need to do this, it would be an extremely rare exception and I would not want to instantiate it in a template

    Also, as you can see from the "Disorder due to birth trauma" template, the DUE TO relates to a procedure and not a finding. 

    1. Peter G. Williams

      Hi Jim Case, no the "Attribute Cardinality" tells you how many attributes of the same type you can have in any given group.   In this case that's a minimum of 1 and a maximum of 1.  So there must be one, and only one, present.   

      Role group cardinality indicates how many copies of that role group you could have.    So for example one role group describing a fracture of finger, and then another one describing a fracture of wrist.    It's confusing to have that cell repeated when there should just be one for the group as a whole.  I'll see if I can merge the cells....

    2. Peter G. Williams

      Re birth trauma:  Oh right.   I was trying to make this concept align:  722904004 |Depressed fracture of skull due to birth trauma (disorder)|  where the "Due to" is 56110009 |Birth trauma of fetus (disorder)|

      But your template would be preferable since it's more specific.   I'll wait to discuss on our call before removing "Due To" in the above.

  7. Yongsheng Gao

    attribute Cardinality: The number of times the given attribute can be assigned a distinct (non-redundant) value within the definition of each concept or expression.

    attribute In Group Cardinality: The number of times the given attribute can be assigned a distinct (non-redundant) value within a single relationship group as part of the definition of a concept or expression.

    The attribute cardinalities are fine. The number for attributeInGroupCardinality for "due to" should be 0..0, and rest attributes should be 1..1.


    1. Peter G. Williams

      Hi Yong, thanks for your attempt to clarify how the cardinality is being expressed here.

      I'm trying to indicate that a role group may appear multiple times, for example in  75857000 |Fracture of radius AND ulna (disorder)|   

      I've indicated the cardinality outside of role group, applying to the whole thing (which is why I merged those cells in the table) eg

      64572001 |Disease (disorder)|:

      [[~1..*]] {

      116676008 |Associated morphology (attribute)| = [[+id(<< 72704001 |Fracture (morphologic abnormality)|) @fracture]],

      363698007 |Finding site (attribute)|  =  [[+id(<< 272673000 |Bone structure (body structure)|) @bone]]

      }

      1. Yongsheng Gao

        Peter G. Williams, the following is a cutdown expresion with modification of attribute cardinality value (in front of {}). The ranges are not refined for attributes. So, you can see that your expression is ended up with the same expression to the standard for attribute cardinality.

        [[+id(64572001 |Disease (disorder)|)]]: [[1..*]] { [[1..1]] 363698007 |Finding site| = [[+id(<< 442083009 |Anatomical or acquired body structure (body structure)|)]], [[1..1]] 116676008 |Associated morphology| = [[+id(<< 49755003 |Morphologically abnormal structure (morphologic abnormality)|)]] }

        Furthermore, the flexibility for allowing multiple role groups could potentially miss the incorrect modeling of two or more role groups that are caused by the incorrect IS A relationships in foundational hierarchies. 

        1. Peter G. Williams

          Thanks Yongsheng Gao.   Working from this page: 6.3 Cardinality  suggests that the cardinality that is written directly next to attributes is called "Attribute Cardinality" and the cardinality that is outside of the curly braces (applying to the group as a whole) is called "Attribute Group Cardinality".   If the MRCM or template language makes a distinction of "Attribute IN group Cardinality" then...well that's confusing.

          I agree that allowing multiple groups containing the same set of attributes will miss the cases where we're picking up an inferred group which is some less specific thing.   There are very few of these "AND" concepts that require multiple finding sites all with fractures.   We might get a better "Hit" rate if I specify only one of each of the groups, and skip concepts that lexically match AND.

          I'll remove those optional attributes and work with the separate pattern as suggested.

        2. Peter G. Williams

          That said, I do see that there's a difference to whether or not the attribute cardinality appears inside a group brace (so restricting the number of appearances within any one group) and if it appeared "ungrouped" where it would apply to those attributes appearing across any group, or ungrouped.

  8. Yongsheng Gao

    The optional model for due to and occurrence should also be represented in the description pattern. I would prefer to have a separate temple as Jim has developed. 

  9. Jim Case

    Peter G. Williams, yes, you would not see that the entire birth trauma hierarchy has been remodeled as it is in final review.  It is much better after the revision, all 80 subtypes are SD.

    1. Peter G. Williams

      Great news!  I'm sorry that this is turning out to be so manually intensive however.  We could maybe discuss on the next call if there are more general rules that could be applied to bring concepts into line.   Nicki's hierarchy for example has a hard rule that every concept must have a Clinical Course of Chronic and I should add that in if it's not present.   However there may not be such, consistent, simple steps to follow for fractures.

      1. Jim Case

        It is turning out that the amount of "clinical" inconsistencies are a barrier to improvement by structural changes alone.  However, the pattern analyses are very helpful in determining what changes need to be made.  I would have liked very much to focus solely on the structural stuff, and even though, as you state the classification changes are minimal, they are still incorrect as they currently exist.  Maybe I am trying to bite off more than I should (sad)

  10. Peter G. Williams

    Hi Suzanne Santamaria what do you think about adding "Event" to the due to attribute there?   I could only see two concepts affected - one due to fall and the other due to car accident.   

    1. Suzanne Santamaria

      Peter G. Williams Yes that is appropriate. Sorry I missed it.

  11. Yongsheng Gao

    Suzanne Santamaria and Peter G. Williams, I would recommend to remove 'Due to' attribute. This template would be the simple template. The fracture due to event can be a new template. I assume that it is not a co-occurrent and due to pattern. Cheers, Yong

    1. Suzanne Santamaria

      Yongsheng Gao and Peter G. Williams I have removed the Due to attribute. This is not a co-occurrent and due to pattern. Thanks, Yong.

  12. Michael Chu

    Yongsheng Gao  As attribute 246454002 |Occurrence (attribute) is optional do we remove term slot [Periods of life] from the FSN and preferred term when the attribute is absent?

  13. Yongsheng Gao

    Michael Chu Yes, please. As a general rule, the description slot needs to be removed if the optional attribute is absent in the logic model of a concept. Cheers, Yong

    1. Michael Chu

      Ok great thanks.