A common limitation of managed FHIR servers is how they restrict the number of “included” resources returned in a FHIR query.
Users are often unaware of this until they hit the problem in code, encountering an OperationOutcome in the returned Bundle telling them their results were truncated.
Here’s what that looks like.
Yesterday I received an email from Microsoft saying they were working to address this in their Azure FHIR servers and will be increasing “included” resources from 100 to 1,000 later in February.
You can read the email below, and while it’s great that they’re addressing this, my reading of the email suggests that they are are only raising this limit for resources returned using the “_include” parameter.
Update: Thanks to Mikael Weaver from Microsoft for clarifying that “_revinclude” resources are also covered by the limit increase. This is very good news.
The current limitation of 100 included resources for “_revinclude” queries is a real problem, as it makes the _revinclude parameter essentially unusable for an application working with real-world data.
Even a simple everyday query like this could hit the 100 include resource limit:
Give me 20 Encounters for a specific Patient along with the Observations made.
Any time I bring this up, FHIR server providers try to explain how “logical” resource truncation is, as you can’t know in advance how many resources might be returned.
Say that to SQL Server, and Postgres, and every other relational database we’ve been using for 50 years. I spent many of my dev days re-writing poorly written SQL queries containing horrendous JOINs and inline calls to stored procedures.
It shouldn’t be the FHIR server’s job to police inefficient or long running queries. They should return the data they’re asked for and leave the code optimization to the developers who understand their own data.
Rant aside, kudos to Microsoft for addressing this important issue.
---