Stream: terminology
Topic: subproperties in $lookup Operation
Simone Heckmann (Nov 10 2017 at 08:29):
What is the meaning of the property.subproperty return paramters in the $lookup-operation
http://build.fhir.org/codesystem-operations.html#lookup
The CodeSystem doesn't have such a property...
Peter Jordan (Nov 10 2017 at 09:14):
These sub-properties are principally for returning SNOMED CT attributes contained in relationship groups. Understand that there isn't a sub-property element in the CodeSystem resource, not sure if one is required because at this level it's not easy to find common patterns across different code systems.
Grahame Grieve (Nov 10 2017 at 10:05):
we're trialling stuff. might be an extension or not, and probably will be consistent
Elise Myers (Aug 13 2019 at 00:04):
I think I understand how FHIR sub-properties can express SNOMED CT relationship groups. However, all examples I can find of sub-properties in the CodeSystem resource don't use the property.code field which, according to the most recent spec, has a 1..1 cardinality. What is meant to go in the property.code field for these grouped sub-properties?
Michael Lawley (Aug 13 2019 at 05:49):
That's an interesting conundrum; for SNOEMD CT I would expect that the natural value would be the SNOMED code for |Role group| 609096000 - http://ontoserver.csiro.au/shrimp/?concept=609096000
Rob Hausam (Aug 13 2019 at 13:13):
@Elise Myers I don't think I'm following how examples of "sub-properties" aren't using CodeSystem.property.code, since it is required. I must be missing something. Which examples are you referring to?
Elise Myers (Aug 13 2019 at 16:18):
@Rob Hausam In the XML on this ticket https://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=14329 , you can see that the property parameters and their sub-properties utilize parts and have name values but no codes. In figure 2 in these docs about modeling SNOMED CT https://confluence.ihtsdotools.org/display/DOCEG/Relationship+Group , it looks like the yellow ovals are sub-property codes, the blue boxes are sub-property values and the where the encompassing property.code should be is where that empty circle is to the left.
Elise Myers (Aug 13 2019 at 16:22):
@Michael Lawley that makes sense to me. But then, would a single concept with multiple grouping of sub-properties have multiple properties with that same code?
Michael Lawley (Aug 13 2019 at 20:01):
Yes, they would, and that is exactly how the underlying OWL modelling in SNOMED CT works.
However, I'm not convinced that the 1..1 cardinality for code is correct, nor that this necessarily is the right / best way to expose the SNOMED sub-properties.
Peter Jordan (Aug 14 2019 at 07:27):
Two questions for me...
a. When should a Role Group be included - only if all properties are requested (i.e. where the property is 410662002 |Concept model attribute|), or also if any individual property or combination of properties is requested?
b. When a Role Group is included, should that be regarded as the property and all members of that Role Group as sub-properties?
Looking at an extreme case - 86299006 |Tetralogy of Fallot (disorder)| This concept has 4 Role Groups consisting of the same combination of property types with varying values. How useful is it to include the Role Groups if only a single property (e.g. in this case 246454002 |Occurrence (attribute)|) is requested? It so happens that 246454002 |Occurrence (attribute)| = 255399007 |Congenital (qualifier value)| is a member of all 4 Role Groups for this concept - does adding the Role Group in this example provide any value other than (maybe) indicating that repeating the same property/value combination 4 times isn't a server bug?
Michael Lawley (Aug 15 2019 at 07:35):
This question really does open up a can of worms.
Let's start by considering some simple cases :
76069003 |Disorder of bone|, which has a |Finding site| of |Bone structure|, and125605004 |Fracture of bone|, which has a |Morphology| of |Fracture| and also a |Finding site| of |Bone structure|, with the two things "grouped" together.
One might expect a $lookup on the first to return property[0].code=|Finding site| and property[0].valueCode=|Bone Structure|.
What about the second? Since they are grouped, then they should be represented as sub-properties with property[0].subproperty[0].code = |Morphology|, property[0].subproperty[0].valueCode = |Fracture|, property[0].subproperty[1].code = |Finding site|, and property[0].subproperty[1].valueCode = |Bone structure|.
But actually, the SNOMED attribute |Finding site| is always grouped, even if there's only a single relationship, so the first should really be property[0].subproperty[0].code = |Finding site|, and property[0].subproperty[0].valueCode = |Bone structure|.
And then we need to address the mandatory property[0].code value for both of these - i.e., what are they sub-properties of? Since July 2013 SNOMED has had 609096000 |Role group|, so this seems a reasonable option.
But now we look at the $lookup operation itself. It's up to the server to decide what (sub-)properties are returned unless one or more property parameters are suppled. How does a client request a sub-property? Do they just use the only parameter that's available? If so, then what happens when you do a $lookup on 125605004 |Fracture of bone| with property=|Finding site| -- should both sub-properties always be returned, or should that be at the server's discretion? Furthermore, what should happen for a $lookup for property 609096000 |Role group|?
Grahame Grieve (Aug 15 2019 at 09:24):
my take on this is that this is delegated to a SNOMED CT implementation guide, which we are working on
Grahame Grieve (Aug 15 2019 at 09:25):
Also note that a server can return additional properties than those listed if it wants
Peter Jordan (Aug 15 2019 at 09:33):
We discussed this issue in this week's SNOMED on FHIR meeting and decided to try and get more opinions by carrying on the debate here!
My inclination, where an individual property belonging to an explicit Role Group is requested, is to return all members of that Role Group as sub-properties of that group in order to provide the full context in which the requested property belongs.
Grahame Grieve (Aug 15 2019 at 09:33):
ok, so given that, I'll engage seriously. What kind of client wants to decompose this stuff fully?
Grahame Grieve (Aug 15 2019 at 09:34):
and if it does, why?
Grahame Grieve (Aug 15 2019 at 09:35):
I would think that the only client interested in this stuff can parse an expression itself
Peter Jordan (Aug 15 2019 at 09:38):
Good question, I raised that in the meeting. Traversing a complex parameters resource with numerous parts, etc. isn't a trivial exercise....and yes, I also suggested that I'd be inclined to request the Necessary Normal Form Expression and parse that. Others weren't totally convinced by that.
Grahame Grieve (Aug 15 2019 at 09:41):
I'll look forward to hearing why....
Last updated: Apr 12 2022 at 19:14 UTC
