Descriptions:
| Term | description type | Language/acceptability | Language/acceptability | Case significance |
|---|---|---|---|---|
| Burn of [body structure] caused by [agent] (disorder) | FSN | us:P | gb:P | ci |
Burn of [body structure] caused by [agent] | SYN | us:P | gb:P | ci |
Concept model:
| Attribute Group Cardinality | Attribute Cardinality | Attribute in Group Cardinality | Attribute | Value |
|---|---|---|---|---|
| 0..0 | 1..1 | |||
| 1..1 | 1..1 | |||
1..* | 1..1 | |||
| 0..1 | [body structure] << 123037004 |Body structure (body structure)| | |||
| 0..1 |
Definition status:
900000000000073002 |Defined (core metadata concept)|
Applies To:
<< 125666000 |Burn (disorder)|
Template language
[[~1..1]] { [[~1..1]] 42752001 |Due to (attribute)| = [[+id(<< 773760007 |Traumatic event (event)| ) @event]] } ,
[[~1..*]] {
[[~1..1]] 116676008 |Associated morphology (attribute)| = [[+id(<< 48333001 |Burn injury (morphologic abnormality)| ) @morph]],
[[~0..1]] 363698007 |Finding site (attribute)| = [[+id(<< 123037004 |Body structure (body structure)| ) @site]],
[[~0..1]] 246075003 |Causative agent (attribute)| = [[+id (<< 105590001 |Substance (substance)| OR << 260787004 |Physical object (physical object)| OR << 78621006 |Physical force (physical force)| ) @agent ]]
}
Rules for description generation:
JIRA tickets
INFRA-7139 - Getting issue details... STATUS
15 Comments
Jim Case
Yongsheng Gao , Peter G. Williams
This is a revised template that includes the additional DUE TO relationship. The old version has seven sub-templates that are all in "READY FOR IMPLEMENTATION" status. They primarily constrain the ASSOCIATED MORPHOLOGY and FINDING SITE relationships. I have tried to generalize this template to allow for all of the subtypes, but wonder about the value of these subordinate templates. They essentially enforce the proper level of anatomy for the burns, but they are mostly focused on skin and we can have burns in other tissues/organs. My impression is that we can archive these as well as being a bit more detailed than we really need.
Need the template language added.
Your thoughts?
Peter G. Williams
Well for sure it's a cost/benefit question and - for now - creating and maintaining templates is quite manually intensive. It feels like going to the level of particular anatomy is more detailed than we've been for other templates.
My vote would be to keep it generic for now -"good enough" - and in the future when we have the tooling to copy/tweak/promote templates with more ease, we could come back to the more specialized subsets.
Yongsheng Gao
Hi Jim Case, I have changed the cardinality of 'finding site' to optional 0..1 in the role group. This will cover the high-level burn concepts which do not specify the site. Should we also include 'causative agent' as optional to support burns caused by substances or physical objects?
Those sub-templates for burns have specified constraints on finding sites based on the degree of burns. 'Skin structure' should be used for the 1st and 2nd degree of burns where a specific body region is specified. Note, the 1st-degree burn should be 'epidermis', but we have not specified in such a way because we do not have the coverage in anatomy.
In contrast, 'Skin/subcutaneous tissue' should be used for the 3rd and 4th degree of burns where a specific region is specified. As you noticed, the 4th degree of burn could involve deeper structures e.g. muscles. The specific deeper structure, e.g muscle, would be modelled in a second role group. This would allow classification for disorder of skin/subcutaneous tissue, and disorder of deeper structures.
The descriptions are also specified in those templates, e.g. full-thickness burn with a synonym of 'third-degree burn, etc. So, I think there are values to keep the sub-templates until we have a 'smart' way to dynamically apply the constraints.
Jim Case
Yongsheng Gao,
Yes, we should include an optional CAUSATIVE AGENT relationship.
I agree that the differentiation between the degree of burn is relevant enough to keep the sub-templates, but we should be judicious in how many are needed. As you suggest, 1st and second degree burns can be handled by one template and I think 3rd and 4th degree burns can be handled with an additional template allowing an optional second RG as you describe. Thus only two subtemplates would be needed. Now the question is, whether we need this more general template since the two subtemplates with the additional causative agent relationship covers all types (except I suppose the generic "Burn of X")
Yongsheng Gao
Hi Jim Case Two sub-templates should be sufficient to cover the range restriction. The synonym for the degree of burn could be generated based on the morphology value. This template would be suitable for generic 'Burn of X' which allows taking value beyond skin/subcutaneous tissue.
Yongsheng Gao
Hi Jim Case, I added the causative agent in the model. Please check if you are happy with the range constraint. If no futher changes, I will raise a ticket for implementation.
Cheers,
Yong
Jim Case
Yongsheng Gao, do we have instances of burns caused by pharmaceutical products?
Yongsheng Gao
Hi Jim Case, I did an ECL query and found none. So, I have removed the pharmaceutical product from the range constraint.
Jim Case
OK, so now we can implement
Kai Kewley
Yongsheng Gao I like the new format of the Concept model table with all the cardinality information in the first two columns. It looks much cleaner.
I have a bit of a concern about the column naming. To be consistent with the snomed computable languages documentation and tooling I would expect the first column to be named "Group Cardinality" and the second column to be named something like "In Group Cardinality". What do you think?
Ref:
Yongsheng Gao
Thanks Kai Kewley, I also had a discussion with Sonja Ulrich about this. The attribute cardinality is a constraint on the number of times that a specific attribute may be included in the same concept definition or expression. This is needed regardless if an attribute is grouped or not. In particular, it can specify the cardinality of attributes that are never grouped. Otherwise, we cannot specify cardinality for never grouped attributes. I have updated the name of the first column to 'Attribute or role group cardinality'. So, if an attribute is not grouped, this is an 'attribute cardinality'. It is a 'role group cardinality' if the cardinality is applied to multiple attributes or self-grouped attributes. Because 'role group' is an attribute, therefore, they are truly 'attribute cardinality'. There is no ambiguity of the second column on 'attribute cardinality in role group'. Please let me know this clarified the potential ambiguity of cardinalities.
Kai Kewley
Yongsheng Gao Thanks for the update, the naming is a bit better. It feels like we are trying to fit three of four columns of information into two columns to minimise space and make it quicker to read. That's totally understandable.
How about having the first column always for Group Cardinality. The first column could be blank for ungrouped relationships, that would make it very clear that the relationship is not grouped. It will also always make the values in the first column apply to groups only and I think that will make it easier to read down the rows without doing an extra cognitive step.
The second column could be always for attribute cardinality. If the attribute is grouped then we know this is stating the "in-group" cardinality and if the attribute is not grouped we know it's just attribute cardinality. Maybe the name of the column could simply be Attribute Cardinality. I feel this would more consistent use of columns so quicker to read and understand?
I think this would still allow us to express everything we need to express. I don't think we need to be able to state the attribute cardinality and the in-attribute cardinality separately for templates (at the current level of template complexity). No doubt we will need more columns in the future!
Yongsheng Gao
Hi Kai Kewley, the attribute in group cardinality is a special case because the maximum number is 1. This is different from other attribute cardinality restrictions. Ideally, this should be kept as a separate column. As per your comment, for those who are not familiar with OWL implementation, it might not be easy to realise that 'role group' is an object attribute. We can split the first column into two and explicitly represent attribute cardinality and role group cardinality. So, we are aligned with the definitions: The attribute cardinality is a constraint on the number of times that a specific attribute may be included in the same concept definition or expression. The attribute group carinality is a constraint on the number of times that an attribute group may be included in the same concept definition or expression.. The attribute in group cardinality is a constraint on the number of times that a specific attribute may be included in the same attribute group. These three columns should be able to support all use cases for cardinalities.
Sonja Ulrich, could you ask the technical team to look into this template as an example for cardinality format? If no further changes, we can apply this format to all active templates.
Chris Swires
Looks perfect to me now Yongsheng Gaocc: Sonja Ulrich
Yongsheng Gao
Thanks Chris Grasso Kai Kewley Sonja Ulrich , I also updated the Template specification,