How reliable are the _include and _revinclude parameters in FHIR?
Not very is the answer. Not reliable enough that you can depend on getting the resources you asked for in your search query.
I have a FHIR server on Azure that I use for testing Vanya. It’s populated with a hundred bundles of Synthea data. Maybe 20,000 resources in total. That’s not a lot of data.
I ran a simple query to test the _revinclude parameter and this is what came back:
- 20 Encounters
- 100 Observations
- 1 OperationOutcome
Here’s the query: /Encounter?_count=20&_revinclude=Observation:encounter
And here’s the message in the OperationOutcome: “Include result was truncated”
The Azure documentation is clear on this.
- “Items retrieved with _include are limited to 100”
- “Items retrieved with _revinclude are limited to 100”
You’ll find it documented near the bottom of the search help page.
So let’s be clear. This is not a bug. This is a limitation. There is no ‘fix’ in the pipeline. This is the FHIR server working as expected.
I’ve worked with Azure’s FHIR servers for a few years — long enough to have built ‘workarounds’ for this problem.
It’s messy, and it means abandoning _include and _revinclude unless you already know how many resources you’ll get back.
Replace my simple query with two queries and some code:
- /Encounter?_count=20
- Extract IDs for all Encounters
- /Observation?encounter=id1,id2,id3,id4,id5,etc.
- Match up the two result sets
This came up recently on the FHIR chat forum, where the prevailing opinion seemed to be that this was ok, if not ideal.
Speaking from the business user side, this is most definitely not ok. In a real world business application, there is no room for truncated query results.
_include and _revinclude either work or they don’t. Either support them or don’t.
My test server: 100 patient bundles, not 100 million!
I single out Azure, but theirs is not the only FHIR server that truncates results. How does your server handle my simple, everyday query?
---