FHIR Chat · Does the order of _include parameter matter? · implementers

Stream: implementers

Topic: Does the order of _include parameter matter?

view this post on Zulip Vlad Ganshin (Oct 01 2021 at 11:26):

Hi. Could you help me to understand the semantic behind _include/_revinclude?

I have next model: CarePlan which points to Tasks (via activity-reference search-param) and Goals (via goal search-param). And I have Provenance resources, which point to all three my resource types (CarePlan, Task, Goal) via target search-param.

As I understood the doc, non-iterate _include/_revinclude depend only on the first resourceType we search on.
:iterate modifier says, that _include/_revinclude should be processed based on gathered result from previous includes.

So, it looks like the order of _include/_revinclude in query-string only matter in the case we have :iterate modifier. Is it correct?

Here are few examples:

  1. These requests will return the same results, which is bundle of CarePlans and Tasks&Goals related to. So, the order or _include doesn't matter.
GET /CarePlan?_include=activity-reference,goal
GET /CarePlan?_include=goal,activity-reference
GET /CarePlan?_include=activity-reference&_include=goal
GET /CarePlan?_include=goal&_include=activity-reference
  1. Same results again. Same as previous one, but Provenance resources related to CarePlan will be added too.
GET /CarePlan?_include=activity-reference,goal&_revinclude=Provenance:target
GET /CarePlan?_revinclude=Provenance:target&_include=activity-reference,goal
GET /CarePlan?_include=activity-reference,goal&_revinclude:iterate=Provenance:target:CarePlan
GET /CarePlan?_revinclude:iterate=Provenance:target&_include=activity-reference,goal
  1. This one will return all CarePlans, related Goals,Task and Provenances related to CarePlans,Goals & Tasks.
GET /CarePlan?_include=activity-reference,goal&_revinclude:iterate=Provenance:target
  1. This one will return all CarePlans, related Goals,Task and Provenances related to CarePlans & Goals (not Tasks).
GET /CarePlan?_include=goall&_revinclude:iterate=Provenance:target&_include=activity-reference

P.S. By the same results per group I mean the set of returned resources, they may be returned in any order in the entry.

view this post on Zulip René Spronk (Oct 01 2021 at 13:52):

_(rev)include (without using :iterate) will only be related to the inclusion of resources referencing/referenced by the focal resource of the search, therefore the order in which one _(rev)includes doesn't matter one bit.
With :iterate, the sequence also doesn't matter. The server will have to keep on expanding all :iterate includes (repeatedly, all of the :iterates, again and again and again) until it has reached the full result set.

view this post on Zulip René Spronk (Oct 01 2021 at 13:54):

This is by design, partly because the underlying web standards for URLs states that the order of the search parameters may be swapped around at will.

view this post on Zulip Vlad Ganshin (Oct 01 2021 at 16:33):

Thank you! It's clear now. One more thing I read up from the doc

_include and _revinclude parameters do not include multiple values. Instead, the parameters are repeated for each different include criteria.

http://hl7.org/fhir/search.html#revinclude
So, samples with multiple values (like GET /CarePlan?_include=activity-reference,goal) are invalid.

view this post on Zulip Lloyd McKenzie (Oct 02 2021 at 01:41):

Iterate means you keep re-running the iterates until you quit finding new resources to include - or the server decides it's had enough fun iterating and quits for performance reasons.

view this post on Zulip Lloyd McKenzie (Oct 02 2021 at 01:42):

And yes, _include=activyt-reference,goal would be invalid

Last updated: Apr 12 2022 at 19:14 UTC


An HL7 Website -