When a payer's Patient Access API exposes member data, the consumers fall into three categories. Members using third-party apps (the original CMS-9115-F use case). Other payers receiving data under Payer-to-Payer Data Exchange. Providers' EHRs consuming the member's shared history. The EHR-side consumption is the integration most often underestimated, because Patient Access is usually discussed as a member-facing feature. Five integration patterns have emerged for EHRs consuming Patient Access in 2026. For the EHR-payer integration hub on this site, these are the practical paths.
1. Member-Initiated Pull Through SMART App Launch
The pattern that fits CMS-0057-F naturally. The member shares their Patient Access credentials or authorizes a SMART app inside the provider's EHR to pull their prior payer history. The EHR launches the SMART app, the app calls the prior payer's Patient Access API, and the data flows into the EHR's clinical view.
The pattern preserves member consent (the member initiates the share) and works with existing SMART App Launch infrastructure most major EHRs already support. The trade-off is the member friction; some members skip the share, leaving the EHR without the prior history.
2. Standing Authorization for Network Plans
A pattern that emerges in narrow-network plans where the EHR has standing authorization to query the payer's Patient Access API for any member of the plan. The pattern works when the member's enrollment in the plan implicitly authorizes the EHR-payer data exchange for clinical purposes.
The legal and consent framework for this is delicate; not all plans support it, and member-rights considerations vary by state. Where it works, the friction reduction for providers is significant.
3. EHR-Mediated Member Verification With Pull
A pattern that splits the share into two steps. The provider's EHR collects member verification (insurance card, member ID, demographic data) at intake. The EHR uses this verification to call the prior payer's Patient Access API, with member acknowledgment captured at the intake desk rather than through a separate SMART app launch.
The pattern works for providers with structured intake processes. It pushes some of the authentication complexity to the EHR's intake workflow rather than asking the member to launch a separate app.
4. Care-Coordination Pull Through Provider Access API
A pattern that uses the Provider Access API (rather than Patient Access) for the EHR-side pull. When the EHR is consuming data for a provider who is in-network with the payer, the Provider Access API is the appropriate channel and does not require per-request member consent.
The pattern fits provider organizations whose EHRs handle in-network member care. The complexity shifts to attribution: the Provider Access API requires the payer to know which members the requesting provider is attributed to.
5. Hybrid Pattern Combining Multiple Access Methods
A pattern that combines all of the above into one cohesive EHR workflow. Member-initiated share covers easy cases. Standing authorization covers narrow-network in-plan situations. Provider Access covers attribution-aware in-network cases. The EHR's data layer normalizes data from all sources into the clinical view.
This hybrid is operationally complex but provides the most complete data picture. Larger EHR deployments and integrated health systems with substantial payer-provider relationships tend toward this pattern.
How to Pick the Pattern for Your Provider Network
The pattern choice depends on the provider's relationship with the payer, the EHR's technical capability, and the member-experience priorities. Provider organizations with narrow-network relationships and integrated payer infrastructure use Patterns 2 and 4. Provider organizations with diverse payer relationships use Pattern 1 (Member-Initiated). Highly integrated health systems use the hybrid.
The patterns are not mutually exclusive. A typical health system uses Pattern 1 for out-of-network member care, Pattern 4 for in-network attributed members, and falls back to Pattern 3 for ambiguous cases.
For the synchronous notification side of EHR-payer interaction that complements these pull patterns, the CDS Hooks vs FHIR Subscriptions comparison covers the notification layer. For Epic-specific integration patterns within these flows, the Best practices for Epic integration with payer FHIR APIs covers the platform-specific guidance.