Have you ever launched a FHIR search that was fast in development, watched it stay fast during pilot, and then discovered it takes eight seconds to return on the day production traffic doubled? Search parameter combinations often behave that way. A single parameter is indexable; two are usually fine; three or four in the same query can push the server into a query plan that scans data instead of seeking indexes. The surprise is on the day the volume finally reveals the plan.
The trick is to characterize the plan before scale arrives. For related walkthroughs, related FHIR explainers is the collection on the home page.
Single-Parameter Searches Are Almost Always Cheap
A search on Patient?identifier=... uses the identifier index and completes in milliseconds. A search on Observation?patient=... uses the patient reference index and stays fast even at high volume. Single-parameter searches are the well-lit path in FHIR; almost every engine handles them well.
Reports that only measure single-parameter searches paint an optimistic picture. The trap arrives with combinations.
Two Parameters Are Where the First Surprises Live
Combining two parameters can still hit an index, but only if the engine has a composite index that matches the combination. Observation?patient=X&code=Y might be indexed on a well-configured engine and not on another. The combination that flies on one deployment can crawl on another.
The single move that surfaces the trap is to run the combinations you care about against a realistic dataset before production. A pass through the site's FHIR p99 latency lookup is a fast way to check the published tail figure per combination category, engine, and resource type.
Three Parameters Are Where the Tail Explodes
Observation?patient=X&code=Y&date=ge2024-01-01 is the case where most engines abandon the index and fall back to a filtered scan. Filtered scans are fine at small dataset sizes and painful at large ones.
The combinations most likely to trip the tail share a shape: a patient or subject reference, a coding filter, and a date range. That shape describes almost every chart-review query in existence, which is why the tail matters. For the wider latency-budget framing, FHIR latency budgets need to be per-resource, not global covers how to name the threshold.
Modifiers Multiply the Surprise
Modifiers like :not, :above, :below, and :contains change the query plan more than the syntax suggests. A :not on a code parameter can turn an index seek into a full scan. A :contains on a string parameter usually forces a linear search across every value.
Every deployment that offers advanced modifiers should measure their latency separately. Reports that lump modified searches with plain ones average across two very different regimes.
`_include` Turns One Query Into Many
_include and _revinclude are the most powerful and most misunderstood parameters in FHIR search. A single _include=Observation:patient turns a search over Observations into a search plus a follow-up read of every referenced Patient. The follow-up reads are almost always fast, and the parallelism makes the overall latency pleasant.
The surprise is at scale: when the include set is large, the coordinated round trips add real overhead. For the Bundle side of the same shape, how Bundle size drives tail latency in FHIR covers the transactional case.
Naming the Combinations Explicitly
Deployments that track search-parameter combinations as a first-class metric surface the tail early. The reporting shape that works is a matrix: rows for resource types, columns for combination cardinality, cells for the p99 latency. That matrix says at a glance where the traps live.
For the clinician-side view of what the tail feels like when it fires, measuring FHIR latency the way clinicians actually perceive it is the accompanying reference.
Search parameter combinations do not care about your dashboard framing. Naming them ahead of the volume is what keeps the surprise off the incident-review calendar.
Sources
- HL7 FHIR core specification of search parameters - HL7 FHIR core specification of search parameters, canonical reference on combination semantics and _include