What we learned building patient-authorized FHIR connections across EHRs.

Updated: 2026-08-25 · 14 min read

The bottom line

FHIR creates a common resource model, but a production patient-access connection still varies by organization discovery, OAuth registration, SMART metadata, scopes, patient context, token lifecycle, and resource availability. A reliable aggregation layer must preserve those differences as explicit state rather than hiding them behind a universal-coverage claim.

Key takeaways

• Vendor support and production-ready connectivity are different claims; FinchNode tracks them separately.
• The recurring engineering work is discovery, authorization, patient context, normalization, provenance, and lifecycle handling—not merely issuing a FHIR GET request.
• One API can give an application a stable contract while still reporting source-specific limits and incomplete data honestly.

Evidence boundary: Based on FinchNode implementation work, public vendor documentation, synthetic testing, directory validation, and the production-readiness evidence available on August 25, 2026.

Author: FinchNode Engineering

Evidence boundary: what this report does and does not claim

These notes describe FinchNode’s implementation experience, not a certification of every endpoint operated by an EHR vendor. We count an integration as fully validated only after the relevant registration, authorization, callback, token exchange, patient context, representative FHIR reads, and lifecycle behavior have been observed in the applicable environment.

As of this review, Epic is the only FinchNode integration treated internally as production-ready. Several other adapters have meaningful code, directory, approval, or sandbox evidence but still lack a completed live production patient lifecycle. Publishing that distinction is important because a supported vendor logo is not evidence that every organization or record will work.

No patient records, credentials, access tokens, or protected health information were used to prepare this public report.

The implementation patterns we observed

The exact state changes as onboarding advances, so this table records the evidence available on the review date rather than making a permanent coverage promise.

What repeated across integrations

• A source-selection step must resolve the organization the patient recognizes to the endpoint the application needs.
• Authorization metadata, redirect URIs, client type, scopes, and PKCE behavior must match the registered application exactly.
• The authorized patient context must be bound to the source connection before clinical resources are read.
• FHIR searches can return empty, partial, paginated, duplicated, or differently profiled results without the connection itself being broken.
• Refresh, expiry, revocation, disconnect, and reauthorization require explicit lifecycle states and audit evidence.
• Every normalized record needs source identity and freshness metadata so applications can explain where it came from.

What did not become uniform

FHIR R4 does not make every organization expose the same profiles, search parameters, history, notes, or terminology. Even inside one vendor family, tenant configuration and product versions can change the result. Patient matching and portal enrollment can also prevent a technically correct authorization request from producing a usable record.

FinchNode therefore treats completeness, source status, and provenance as part of the API response. The platform should never manufacture a complete longitudinal record when a source returned less information.

The architecture that survived those differences

1. 1. Resolve the source

   Search a maintained organization directory and retain the selected endpoint identity.

2. 2. Discover and authorize

   Read supported SMART metadata, create a state-bound authorization request, and validate the callback.

3. 3. Bind patient context

   Associate the granted source patient identifier with an application-scoped FinchNode subject.

4. 4. Retrieve with limits

   Follow server-provided pagination, record OperationOutcome details, and avoid assuming unsupported searches.

5. 5. Normalize without erasing provenance

   Create stable application categories while preserving source identifiers, resource type, and timestamps.

6. 6. Enforce sharing and lifecycle state

   Apply the application-specific consent boundary to reads, webhooks, revocation, and deletion.

More FinchNode interoperability guides

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

Frequently asked questions