Fetch patient data with a FHIR API: Patient, labs, conditions, and medications.

Updated: 2026-08-25 · 11 min read

The bottom line

Read the Patient resource first, then issue patient-scoped searches for the clinical resources your app is authorized to access. Follow the server’s Bundle `next` links verbatim, retain provenance, and distinguish an empty search from a failed search.

Key takeaways

• A successful FHIR search returns a `searchset` Bundle, including when it contains zero matching resources.
• Follow the server-provided `next` URL rather than constructing page numbers yourself.
• Do not assume MedicationRequest alone represents every medication list returned by every source.

Evidence boundary: Examples follow FHIR R4 REST and Bundle semantics and use fictional URLs and patient identifiers.

Author: FinchNode Engineering

Start with an explicit request plan

Follow FHIR Bundle pagination safely

type FhirResource = { resourceType: string; id?: string };
type Bundle = {
  resourceType: 'Bundle';
  type: 'searchset';
  entry?: Array<{ resource?: FhirResource }>;
  link?: Array<{ relation: string; url: string }>;
};

export async function readAll(url: string, token: string, maxPages = 20) {
  const resources: FhirResource[] = [];
  let next: string | undefined = url;

  for (let page = 0; next && page < maxPages; page += 1) {
    const response = await fetch(next, {
      headers: { accept: 'application/fhir+json', authorization: `Bearer ${token}` },
    });
    if (!response.ok) throw await fhirError(response);
    const bundle = (await response.json()) as Bundle;
    if (bundle.resourceType !== 'Bundle') throw new Error('unexpected_fhir_response');
    resources.push(...(bundle.entry ?? []).flatMap((item) => item.resource ? [item.resource] : []));
    next = bundle.link?.find((link) => link.relation === 'next')?.url;
  }

  return resources;
}

Representative patient-scoped searches

Search support is advertised by a server’s CapabilityStatement and implementation guide. Treat these URLs as patterns, not a promise that every source accepts every parameter.

GET {fhirBase}/Patient/{patientId}
GET {fhirBase}/Observation?patient={patientId}&category=laboratory&_count=100
GET {fhirBase}/Condition?patient={patientId}&_count=100
GET {fhirBase}/MedicationRequest?patient={patientId}&_count=100

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

Normalize after preserving the source

• Store the FHIR base, resource type, logical ID, business identifiers, and `meta.lastUpdated`.
• Keep coding systems alongside display text; do not collapse different code systems into an unlabeled string.
• Represent missing values as unavailable instead of inventing defaults.
• Deduplicate only with source-aware identifiers and domain-specific rules.
• Keep the raw source resource or an integrity-protected reference when your policy permits it.

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.
• 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.
• FHIR Patient $everything: pagination, missing data, and production caveats.

Frequently asked questions