SNOMED ECL refinement/cardinality & large-hierarchy $expand have no cost/time bound (examples of poorly-performing queries)

[jmandel]

Summary

tx caps expansion by enumeration size (whole-system / large includes return 422 too-costly (>3000)), but ECL refinement + cardinality constraints and large-hierarchy descendant expansions have no cost or time bound — they run to completion regardless of how expensive the evaluation is. Below are example ECL queries that perform poorly.

Measurement note: to avoid loading the public server, I did not time these against tx.fhir.org. The timings below come from a local instance of the same server (FHIRsmith, run from the published source) plus our own build/replay logs. The point here is the shape of the queries — examples of work the engine doesn't bound. Please measure on your own infrastructure.

Example queries that perform poorly

1. Refinement + cardinality (the same evaluator as tx.fhir.org SNOMED ECL bugs: memberOf sentinel leakage and cardinality counting #230's cardinality bug):

   http://snomed.info/sct?fhir_vs=ecl/<< 38341003 |Diabetes mellitus| : [2..5] 363698007 |Finding site| = *
   

   ~18 s locally (HTTP 200, total 58). It materializes the whole << 38341003 descendant set and then, per concept, evaluates the role-group attribute cardinality.

2. Heavier cardinality/refinement expansions in the same class were observed up to ~88 s in our logs.

3. Large-hierarchy descendant / refinement expansions are the other slow class.

The gap

The too-costly guard fires on enumeration size, but not on the evaluation cost of a refinement/cardinality constraint (or a large-hierarchy refinement). So these bypass the cap and run unbounded — there is no per-request time budget or refinement-cost ceiling.

Why it matters

Each such request occupies the engine for tens of seconds; a handful in flight concurrently is an availability / DoS-resistance risk, with no mechanism to shed or bound the load.

Relationship to #230

The cardinality evaluator exercised by example (1) is the same one #230 (Bug 3) flags as computing the wrong count — so it is both incorrect and unbounded; a single fix to that path could address both.

Framing

This is a robustness / performance observation, not a spec-conformance violation — FHIR doesn't mandate a cost bound, and tx already chooses to cap by enumeration size. The ask is for that cost cap (or a per-request time budget) to also cover refinement/cardinality and large-hierarchy evaluation.