Custom SearchParameter with nested FHIRPath expression on Consent.provision.provision returns all resources (over-matching)

[oeme-github]

Bug Description

Blaze accepts registration of custom SearchParameters via REST (HTTP 201), but does not correctly apply them when the FHIRPath expression addresses nested provision.provision elements of a FHIR R4 Consent resource. All resources are returned regardless of the search value (over-matching).

Simple SearchParameters without nested access work correctly.

Environment

• Blaze version: 1.9.0 (also confirmed on 1.7.0)
• FHIR version: R4
• SearchParameter types affected: token, date, code — all when expression targets Consent.provision.provision.*

Reproduction

Register a custom SearchParameter targeting nested provisions:

{
  "resourceType": "SearchParameter",
  "id": "mii-sp-consent-provisioncode",
  "url": "https://www.medizininformatik-initiative.de/fhir/modul-consent/SearchParameter/mii-sp-consent-provisioncode",
  "name": "mii-provision-provision-code",
  "status": "active",
  "code": "mii-provision-provision-code",
  "base": ["Consent"],
  "type": "token",
  "expression": "Consent.provision.provision.code"
}

Load 5 Consent fixtures — 4 with provision code .3.19 (BIOMAT erheben), 1 without (expired Consent with no nested provisions).

# Expected: 4 results (expired Consent has no .3.19 provision)
GET /fhir/Consent?mii-provision-provision-code=urn:oid:2.16.840.1.113883.3.1937.777.24.5.3|2.16.840.1.113883.3.1937.777.24.5.3.19
# → total: 5 ❌ (all 5 returned, including expired)

Same over-matching occurs for type (permit/deny) and period (date) parameters on provision.provision:

# Expected: 2 results (2 Consents have deny provisions)
GET /fhir/Consent?mii-provision-provision-type=deny
# → total: 5 ❌

# Expected: 4 results (expired Consent provisions ended in 2010)
GET /fhir/Consent?mii-provision-provision-period=ge2030-01-01
# → total: 5 ❌

The over-matching also persists in combined queries (patient filter + composite SP):

# Expected: 0 results (patient-001's Consent has .3.19 only as permit, not deny)
GET /fhir/Consent?patient=Patient/test-patient-001
                 &mii-provision-provision-code-type=urn:oid:...|...3.19$deny
# → total: 1 ❌

What works correctly

SearchParameter on provision.policy.uri (single-level, not nested under provision.provision) works as expected — only matching resources are returned.

Expected behavior

Only resources whose provision.provision elements match the search value should be returned.

Note on v1.8.0 fix #3642

#3642 fixed an AbstractMethodError when composite token-token parameters are used as a secondary (seek) clause. That fix resolved the crash but did not address the underlying over-matching: even after v1.9.0, the above queries return all resources regardless of the search value.

Reference

These SearchParameters are part of the MII (Medizininformatik-Initiative) Broad Consent Implementation Guide:
https://simplifier.net/MedizininformatikInitiative-ModulConsent

Related discussion in the MII consent module repository: kerndatensatzmodul-consent#123