FHIR Anonymization and De-Identification

How filters apply

A property filter is part of an authorization rule. The validator runs first; if it grants access, the filter list is applied to the resource before it leaves the server. Each filter targets a property using a FHIRPath expression and applies a transformation: `NullFilter` removes the field, `RandomFilter` replaces it with a synthetic value of the right type.

The search side-channel problem

Property filters redact responses, but the underlying data stays indexed and searchable. A determined client can probe redacted values through `_sort`, `_include`, `_filter`, chained search parameters, or value-based searches. Closing this requires explicit configuration.

Declare `blocked-search-params` on the rule. Any search using a listed parameter (or include directive) is rejected with 403 Forbidden. The list must cover every search parameter that could reveal a redacted field, including parameters introduced through `_include` chains.

Two safer patterns avoid this audit entirely. Grant `read` (single-resource by ID) without `search` for the property-filtered role; clients can only access resources they already know the ID of, and there is no search surface to exploit. Or use `graphql-read` with inline reference expansion: references are resolved by ID server-side, and property filters apply to all expanded resources without exposing a client-controlled search.

GraphQL and HFQL behavior

GraphQL read with inline reference expansion is the recommended access path for property-filtered roles that need to traverse a resource graph. HFQL is fail-closed against `blocked-search-params`: when the list is configured for a resource type, all HFQL queries on that type are rejected outright. GraphQL search has the same risks as REST search and must be blocked the same way.

Where filters do and do not help

Filters are an enforcement mechanism. Whether a filtered view qualifies as de-identified, pseudonymized, or anonymized under a specific regulatory standard depends on the data, the recipient, the legal basis, and the broader processing context. Filters do not replace a privacy assessment; they make the chosen policy enforceable.

FAQ