Production access is free and self-serve with an account. · Try the demo
Patient-authorized EHR integration
A transparent implementation report covering the patterns that repeated, the behaviors that did not, and the evidence boundary behind FinchNode’s current integration work.
Updated: 2026-08-25 · 14 min read
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.
Evidence boundary: Based on FinchNode implementation work, public vendor documentation, synthetic testing, and directory validation as of August 25, 2026.
Author: FinchNode Engineering
These notes describe FinchNode’s implementation experience, not a certification of every endpoint operated by an EHR vendor. They cover registration, authorization, callback, token exchange, patient context, representative FHIR reads, and lifecycle behavior as observed during integration work.
A supported vendor logo is not evidence that every organization or record will work. Endpoint routing, approved scopes, and the data an organization publishes all differ, so plan for source-specific variation rather than uniform coverage.
No patient records, credentials, access tokens, or protected health information were used to prepare this public report.
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.
| Source family | Observed engineering pattern | What varies by organization |
|---|---|---|
| Epic / MyChart | Standalone patient OAuth, PKCE-capable authorization, organization endpoint routing | Endpoint routing and the resources each organization publishes |
| Oracle Health | Directory-driven tenant routing plus tenant SMART/OIDC discovery | Tenant environment, discovered metadata, and granted scopes |
| athenahealth | Separate preview and production registrations with signed OIDC validation | Practice-level registration and the branded login the patient sees |
| Veradigm / Allscripts | Organization-specific FHIR routing with authorization metadata on distinct hosts | Authorization host and FHIR base per organization |
| MEDITECH | Strict callback registration, PKCE, and environment-specific FHIR bases | Environment-specific FHIR bases and callback registration |
| Medicare Blue Button | Beneficiary authorization for claims and coverage rather than an EHR clinical record | Coverage and claims CMS holds for the beneficiary |
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.
Search a maintained organization directory and retain the selected endpoint identity.
Read supported SMART metadata, create a state-bound authorization request, and validate the callback.
Associate the granted source patient identifier with an application-scoped FinchNode subject.
Follow server-provided pagination, record OperationOutcome details, and avoid assuming unsupported searches.
Create stable application categories while preserving source identifiers, resource type, and timestamps.
Apply the application-specific consent boundary to reads, webhooks, revocation, and deletion.
No. FinchNode provides one application contract across supported patient-access sources. Availability still depends on the organization endpoint, application approval, patient authorization, scopes, and returned data.
FHIR standardizes resources and API patterns, but servers can support different profiles, searches, data histories, terminology, and tenant configurations. The underlying patient record can also differ by organization.
Registration, endpoint routing, authorization, callback and token exchange, patient context, representative data reads, refresh or expiry, revocation, disconnect, and monitoring.
No. It is an implementation field report with explicit evidence limits. It should not be read as a vendor performance score or universal compatibility certification.