Use of _include in FHIR

Question

In the FHIR query spec it states that the _include parameter can be added to the query URL to request that specified referenced resources are returned in full to prevent further network requests to retrieve these resources.

i.e.

diagnosticreport/search?_include=DiagnosticReport.subject&_include=Patient.provider

This construct requires that you know the resources that are going to be referenced in the result set in advance of the query being made. I suspect for resources such as "Observation" where there will potentially be many profiles with each profile potentially having different extensions, this will not be the case.

Is it feasible to have a syntax whereby all of the referenced resources are "included"?

Winkelman

Answer 1

Umm, that might be possible. Though there's a the risk that you'd get a swag of resources you had no idea why you were getting. And the server might be more inclined to reject that kind of request. It's certainly a lot slower for a server - it has to evaluate a lot more content to decide what references to include or not.

Caddoan

I accept that it would load the server, but the alternative for a messaging based interaction would be the initial query followed by a succession of follow on queries in order to resolve the full information content of the returned "message" - I suspect that would add up to a lot more load on the server, though admittedly it would not be expended in one hit. – Winkelman

well, we would could define wild cards in the format- i.e. _include=DiagnosticReport.*. Or _include=*. – Caddoan

yeah, so, you request _include=* - how many million resources get returned with that? you could get the entire resource set... I added a note that both client and server should be careful with that one – Caddoan

Answer 2

This page: https://www.hl7.org/implement/standards/FHIR/search.html#return describes the following:

2.2.4.1 Include Paths
Include paths may include wild cards, such as MedicationDispense.results.*, or even _include=*, though both clients and servers need to take care not to request or return too many resources when doing this. Most notably, re-applying inclusion paths over newly included resources might lead to cycles or the retrieval of the full patient's file: resources are organized into an interlinked network and broad _include paths may eventually traverse all possible paths on the server. For servers, these recursive and wildcard _includes are demanding and may slow the search response time significantly. Servers are expected to limit the number of iterations done and are not obliged to honor requests to include additional resources in the search results.

Somatic

Updated link : hl7.org/implement/standards/FHIR/search.html#revinclude – Adalineadall

Both _include and _revinclude use the wild card "*" for the search parameter name, indicating that any search parameter of type=reference be included. – Adalineadall

Though both clients and servers need to take care not to request or return too many resources when doing this. Most notably, using iterative wildcards inclusions might lead to the retrieval of the full patient's record, or even more than that: resources are organized into an interlinked network and broad _include paths may eventually traverse all possible paths on the server. For servers, these iterative and wildcard _includes are demanding and may slow the search response time significantly. – Adalineadall