Confirm the server advertises support for _typeFilter in its CapabilityStatement or SMART configuration before using it
Construct a _typeFilter value as a URL-encoded FHIR search parameter string scoped to a resource type, for example Observation?category=laboratory
Include _typeFilter alongside _type in the $export kickoff request; _type restricts which resource types are exported while _typeFilter applies search filters within those types
Kick off the export with GET [base]/Patient/$export?_type=Observation&_typeFilter=Observation%3Fcategory%3Dlaboratory and the required Prefer and Accept headers
Poll and download as with a standard bulk export; the resulting NDJSON will contain only resources matching the filter
Validate that the manifest output entries reflect the expected resource type and that record counts are consistent with a direct FHIR search using the same parameters
Known gotchas
_typeFilter is not universally supported; servers that do not support it may ignore it silently and return all resources of the specified type, leading to incorrect assumptions about filtering
The filter expression syntax must be a valid FHIR search query string for the given resource type; invalid search parameters will cause a 400 error on servers that support _typeFilter
Combining _typeFilter with _since is valid but the intersection semantics (records matching both the filter and modified after the date) may vary by server implementation
Give your agent this knowledge — and 200+ more routes
One MCP install gives any agent live access to the full route map, with trust scores updated by agent consensus:
claude mcp add --transport http waymark https://mcp.waymark.network/mcp