In the finding/procedure with explicit context (FWEC/PWEC) entries of the international MRCM refsets there are constraints that appear to prohibit the use of procedure-related attributes for finding situations and finding-related attributes for procedure situations:
[0..0] 408729009 |Finding context| = *, [0..0] 246090004 |Associated finding| = * in the domain constraints/templates and attribute rules for PWEC and [0..0] 408730004 |Procedure context| = *, [0..0] 363589002 |Associated procedure| = * in the domain constraints/templates and attribute rules for FWEC
This kind of makes sense - if the intent is to make FWEC and PWEC disjoint (and avoid having single codes/expressions represent entire clinical stories of multiple things observed and done). However, if this is indeed the case, how come the data contains the following, all of which are modelled as both a PWEC and a FWEC?:
ConceptId FSN 32271000119102 History of delivery of macrosomal infant (situation) 36601000119109 History of repair of tetralogy of Fallot (situation) 37851000119107 History of correction of ventricular septal defect (situation)
Details of the actual modelling aside, are these as they are because the MRCM rules as published aren't fully yet in use, or are the rules in combination 'permissive', somehow giving precedence to the rules that 'allow' modelling over those that disallow? Or something else...
The outcome of our internal discussion is that the associated MRCM rules are correct, but these 3 concepts slipped through the validation net as they are incorrectly modelled. The actions that we will take are (a) include this as a known issue in the 20190131 release notes, (b) correct the modelling of these 3 concepts for 20190731, to ensure that they only belong to 1 of the mentioned hierarchies, (c) improve our validation processes so that they will pick up these domain errors in future.
The authoring environment used by SNOMED I (and Sweden through Managed Services) does allow those concepts to be authored, saved, classified and validated. Also, the domain of 246090004 | Associated finding | is 413350009 | Finding with explicit context (situation) | according to MRCM 20190131 WIP. Stated and inferred view below:
BTW why are not 129125009 | Procedure with explicit context (situation) |'s attributes grouped?
Also BTW, I think the examples should all be PWECs only and the finding should be a focus of the associated procedure.
Thanks for your comments on this. The inferred view in this example is picking up the |Procedure context| and |Temporal context| attributes from |Procedure with explicit context|, which are defined as ungrouped (and therefore in separate role groups) in the parent concept |Procedure with explicit context|. I will discuss this with the internal team, and report back.
If the procedure context and temporal context relationships are, in fact, implicitly grouped then the diagramming is incorrect; it should show the open-circle role groups for the inferred form
I guess this authoring environment uses the same or similar diagram rendering as the SNOMED browser, still not showing the RG0 group circles, still showing the same modeling error of not grouping the attributes. From the SNOMED browser:
Bit late to this aspect of the discussion. Isn't it simply the case that the diagramming guideline, like an SCG rendering of a concept definition, is just a slave to the published definition itself? If the definition includes group 0/ungrouped roles then these are not treated as grouped, and will be displayed as such.
I recall (but in truth still don't fully understand!) that a careful DL analysis (by Jeremy, Ronald and Stefan in the past and I'm sure by others since) made the case for treating group 0 roles 'as if they are grouped' and this is/was manifest in the owl representation (? each in role in its own 'group of one'), but I don't see how we can assume that group 0 roles are implicitly 'grouped together'. If the SCT modelling is wrong (if it is concluded that they should be grouped) then that is a different question, and addressing this in the data would then result in grouped roles in the diagram.
Yes, these are two separate issues: 1. diagram not showing RG0 attributes in their full, 2. should the attributes in the 129125009 | Procedure with explicit context (situation) | definition be grouped. 1. has been discussed in the DL Subgroup as well as in the MAG and the conclusion has been that "implicitness" in the diagramming standard does not help anyone. The term "ungrouped" does only apply to attributes like "laterality". 2. Role grouping is also an ongoing discussion in MAG and, at least, inconsistent role grouping is incompatible with many other SNOMED CT patterns ("x with y" to name just one) (I also had a presentation in Vancouver).
Apologies - but I will need to get back to you on these questions next year! The relevant people are on leave at the moment, so I won't have answers for you until they (and I return) in mid January.
Hi Daniel, Just following up on this - I understand that both issues will be resolved in the 20190731 international edition. That is (1) the modelling of |Procedure with explicit context| and |Finding with explicit context| to use role groups, and (2) the display of role group circles on self-grouped relationships.
309635005 H/O: Admission in last year for diabetes foot problem 309636006 History of hospital admission in last year for hyperglycaemic disorder
...are both modelled as an FWEC and a PWEC.
The MRCM prohibition constraints that theoretically prevent this are still present, so it's odd that these sorts of constructs can still be created and published.
15 Comments
Ed Cheetham
Dear all
Quick question:
In the finding/procedure with explicit context (FWEC/PWEC) entries of the international MRCM refsets there are constraints that appear to prohibit the use of procedure-related attributes for finding situations and finding-related attributes for procedure situations:
[0..0] 408729009 |Finding context| = *, [0..0] 246090004 |Associated finding| = * in the domain constraints/templates and attribute rules for PWEC
and
[0..0] 408730004 |Procedure context| = *, [0..0] 363589002 |Associated procedure| = * in the domain constraints/templates and attribute rules for FWEC
This kind of makes sense - if the intent is to make FWEC and PWEC disjoint (and avoid having single codes/expressions represent entire clinical stories of multiple things observed and done). However, if this is indeed the case, how come the data contains the following, all of which are modelled as both a PWEC and a FWEC?:
ConceptId FSN
32271000119102 History of delivery of macrosomal infant (situation)
36601000119109 History of repair of tetralogy of Fallot (situation)
37851000119107 History of correction of ventricular septal defect (situation)
Details of the actual modelling aside, are these as they are because the MRCM rules as published aren't fully yet in use, or are the rules in combination 'permissive', somehow giving precedence to the rules that 'allow' modelling over those that disallow? Or something else...
Thanks
Ed
Linda Bird
Excellent point Ed!
I will discuss this internally, and let you know the outcome.
Kind regards,
Linda.
Ed Cheetham
Brilliant - thanks Linda.
Ed
Linda Bird
Hi Ed,
Thanks again for your feedback!
The outcome of our internal discussion is that the associated MRCM rules are correct, but these 3 concepts slipped through the validation net as they are incorrectly modelled. The actions that we will take are (a) include this as a known issue in the 20190131 release notes, (b) correct the modelling of these 3 concepts for 20190731, to ensure that they only belong to 1 of the mentioned hierarchies, (c) improve our validation processes so that they will pick up these domain errors in future.
Thanks again! Happy holidays!
Kind regards,
Linda.
Ed Cheetham
Thanks Linda
You have a good break too.
Kind regards
Ed
Daniel Karlsson
Hi Ed,
you are an excellent issue finder!
The authoring environment used by SNOMED I (and Sweden through Managed Services) does allow those concepts to be authored, saved, classified and validated. Also, the domain of 246090004 | Associated finding | is 413350009 | Finding with explicit context (situation) | according to MRCM 20190131 WIP. Stated and inferred view below:
BTW why are not 129125009 | Procedure with explicit context (situation) |'s attributes grouped?
Also BTW, I think the examples should all be PWECs only and the finding should be a focus of the associated procedure.
Linda Bird
Hi Daniel,
Thanks for your comments on this. The inferred view in this example is picking up the |Procedure context| and |Temporal context| attributes from |Procedure with explicit context|, which are defined as ungrouped (and therefore in separate role groups) in the parent concept |Procedure with explicit context|. I will discuss this with the internal team, and report back.
Kind regards,
Linda.
Michael Lawley
If the procedure context and temporal context relationships are, in fact, implicitly grouped then the diagramming is incorrect; it should show the open-circle role groups for the inferred form
Linda Bird
I agree with you Michael!
Daniel Karlsson
I guess this authoring environment uses the same or similar diagram rendering as the SNOMED browser, still not showing the RG0 group circles, still showing the same modeling error of not grouping the attributes. From the SNOMED browser:
Ed Cheetham
Thanks Daniel/all
Bit late to this aspect of the discussion. Isn't it simply the case that the diagramming guideline, like an SCG rendering of a concept definition, is just a slave to the published definition itself? If the definition includes group 0/ungrouped roles then these are not treated as grouped, and will be displayed as such.
I recall (but in truth still don't fully understand!) that a careful DL analysis (by Jeremy, Ronald and Stefan in the past and I'm sure by others since) made the case for treating group 0 roles 'as if they are grouped' and this is/was manifest in the owl representation (? each in role in its own 'group of one'), but I don't see how we can assume that group 0 roles are implicitly 'grouped together'. If the SCT modelling is wrong (if it is concluded that they should be grouped) then that is a different question, and addressing this in the data would then result in grouped roles in the diagram.
Ed
Daniel Karlsson
Yes, these are two separate issues: 1. diagram not showing RG0 attributes in their full, 2. should the attributes in the 129125009 | Procedure with explicit context (situation) | definition be grouped. 1. has been discussed in the DL Subgroup as well as in the MAG and the conclusion has been that "implicitness" in the diagramming standard does not help anyone. The term "ungrouped" does only apply to attributes like "laterality". 2. Role grouping is also an ongoing discussion in MAG and, at least, inconsistent role grouping is incompatible with many other SNOMED CT patterns ("x with y" to name just one) (I also had a presentation in Vancouver).
/Daniel
Linda Bird
Hi Daniel,
Apologies - but I will need to get back to you on these questions next year! The relevant people are on leave at the moment, so I won't have answers for you until they (and I return) in mid January.
Happy holidays!
Kind regards,
Linda.
Linda Bird
Hi Daniel, Just following up on this - I understand that both issues will be resolved in the 20190731 international edition. That is (1) the modelling of |Procedure with explicit context| and |Finding with explicit context| to use role groups, and (2) the display of role group circles on self-grouped relationships.
Ed Cheetham
I see that this error pattern is back:
309635005 H/O: Admission in last year for diabetes foot problem
309636006 History of hospital admission in last year for hyperglycaemic disorder
...are both modelled as an FWEC and a PWEC.
The MRCM prohibition constraints that theoretically prevent this are still present, so it's odd that these sorts of constructs can still be created and published.