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

The operation can simplify record retrieval, but it does not promise every resource, identical server behavior, or a small response.

[Production-grade access is free with an account.](https://finchnode.com/signup) The $0/month plan includes 100 connected patient-months, 100,000 production API calls per month, one production application, and an unlimited synthetic sandbox.

- Author: [FinchNode Engineering](https://finchnode.com/authors/finchnode-engineering)

- Published: 2026-08-25

- Last reviewed: 2026-08-25

- Canonical URL: https://finchnode.com/blog/fhir-patient-everything-guide

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

## 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.

## A bounded request is easier to operate

```http
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.

### Primary sources

- [FHIR R4 Patient $everything](https://hl7.org/fhir/R4/operation-patient-everything.html)
- [FHIR R4 paging and HTTP behavior](https://hl7.org/fhir/R4/http.html)

## Frequently asked questions

### Does Patient $everything return the complete medical record?

It returns the related information the server has and the authorization context permits. That is not a guarantee of every historical record, source, document, or data category.

### Can a $everything response be paginated?

Yes. Servers can require or support paging. Follow the Bundle `next` link and use bounded retrieval safeguards.

### Can I filter Patient $everything?

FHIR R4 defines parameters including start, end, `_since`, `_type`, and `_count`, but clients should confirm the target server’s implementation behavior.

### What should I do if $everything is unsupported?

Use the server’s CapabilityStatement and implementation guide to construct supported resource-specific patient searches.