FHIR Patient $everything: pagination, missing data, and production caveats.

Updated: 2026-08-25 · 9 min read

The bottom line

Patient `$everything` requests the information a server can return for an authorized patient. The response is a `searchset` Bundle and can be filtered, paged, limited, or unsupported. Production clients need size limits, continuation handling, and resource-specific fallbacks.

Key takeaways

• The operation returns what the server has and the user is authorized to access—not a universal complete record.
• Use `_type`, `start`, `end`, `_since`, and `_count` only when the server supports the desired behavior.
• Follow Bundle links and cap pages, bytes, and elapsed time.

Evidence boundary: Grounded in the FHIR R4 Patient `$everything` operation and standard Bundle paging behavior.

Author: FinchNode Engineering

A bounded request is easier to operate

GET {fhirBase}/Patient/{patientId}/$everything
  ?start=2025-01-01
  &end=2026-08-25
  &_type=Condition,Observation,MedicationRequest,AllergyIntolerance
  &_count=200

Accept: application/fhir+json
Authorization: Bearer {accessToken}

Treat the Bundle as an unordered retrieval result

The FHIR R4 operation defines a `searchset` Bundle. It can include the Patient, related clinical resources, and supporting referenced resources. It does not define an inherent display order, so build a timeline from clinical dates rather than Bundle entry position.

Production guardrails

• Reject `next` links that leave the trusted FHIR host policy.
• Apply maximum pages, response bytes, resources, and elapsed time.
• Persist a resumable cursor or server continuation only when the source contract permits it.
• Record OperationOutcome entries and warnings instead of discarding them.
• Fall back to resource-specific searches when the operation is unsupported or too broad.
• Deduplicate supporting resources without assuming Bundle order or uniqueness.

More FinchNode interoperability guides

• What we learned building patient-authorized FHIR connections across EHRs.
• SMART on FHIR OAuth with PKCE in React and Node.js.
• Fetch patient data with a FHIR API: Patient, labs, conditions, and medications.
• Epic and MyChart FHIR integration for patient-facing applications.
• Oracle Health FHIR integration: discovery, authorization, and tenant routing.
• How to normalize FHIR data across EHRs without losing the source.

Frequently asked questions