Stream: implementers
Topic: Query via contained resource
Dave Barnet (Nov 07 2018 at 13:31):
I have an Observation resource that has an assessment score. It contains other Observation that hold assessment sub-score (that go to make up the container score). These contained sub-score Observations point out to (by using related.target) actual Observations that are used to create the sub-scores (so for example a pulse rate of 80 bpm might translate to a sub-score of 1, which goes to make up an overall score). Is there a query such that I can return a Bundle of the container Observation, its contained Observation (this is easy as they are the same Observation), as well as the Observations that each contained sub-score has as its related.target?
If there is a query construct, are there any FHIR test servers that would support the query?
Or is it a case of querying for the container Observation, and then querying for the contained related.target links one-by-one?
Lloyd McKenzie (Nov 07 2018 at 13:37):
Typically the sub-scores wouldn't be "contained" - they'd be components. For example, with an APGAR, the overall score would be in Observation.value and the various sub-scores (color, cry, etc.) would be sent as components. The derivation relationships from other Observations would be at the overall Observation level rather than per component - though if you deemed it necessary, you could add extensions that would differentiate which derivedFrom observations were relevant to each component. That would make the query slightly simpler as you could simply say _include=Observation:derived-from. With your structure, you'd need to do _include:iterate=Observation:derived-from. That'll recurse through all of the derivedFrom relationships of all returned resources.
Dave Barnet (Nov 07 2018 at 13:55):
I went down the contained route, following the Glasgow Coma Scale example http://hl7.org/fhir/stu3/observation-example-glasgow.xml.html. It seems to offer of advantages such as keeping the related.target links with the sub-scores neatly, without the need for extensions to the Observation resource.
IF I keep this structure, I guess that the retrieval of the actual Observations will have to be done as a separate query (get the main Observation with the contained Observations, then for each contained Observation get the actual Observation).
Grahame Grieve (Nov 08 2018 at 01:24):
I would have thought that _include should be able to chase those down and return them
Grahame Grieve (Nov 08 2018 at 01:25):
certainly graphQL or graph definition is able to
Last updated: Apr 12 2022 at 19:14 UTC
