Epic Payer Platform

What is Epic Payer Platform?

Epic Payer Platform is Epic's network for two-way data exchange between health plans and provider organizations that use Epic. Epic describes it as bringing tools for claims, prior authorizations, decision support, care management, referrals and scheduling into clinicians' existing Epic workflows, so payer information arrives without faxes, separate portals or extra clicks.

It is a collaboration arrangement rather than a single API. A plan works with Epic and with each provider organization to switch on the exchanges it needs, and the technical pieces underneath use interfaces Epic documents publicly, such as FHIR APIs, HL7 v2 feeds, flat files and CDS Hooks.

What does Payer Platform exchange?

Epic's Payer Platform overview lists five kinds of exchange. Each one answers a specific problem between a plan and a provider.

• Clinical insights: Providers and care managers review care gaps, diagnoses and claims information from payers at the point of care and in population health work.
• Information before claims: Providers share information with payers before submitting claims, aimed at reducing denials.
• Authorizations: Authorization decisions come back in real time for participating payers, so patients wait less for care.
• Coverage: An automatic coverage finder creates coverage records in registration from health plans that use Payer Platform.
• Required sharing: Providers send payers the information they are required to share, automatically rather than by hand.

Notice the direction of each flow. Some data moves from plan to provider, such as care gaps and claims history. Some moves from provider to plan, such as clinical documents and visit notices. A plan's integration has to handle both directions, with different owners and controls for each.

How do payers reach Epic provider systems?

Epic's payer connection playbook on fhir.epic.com describes four building blocks: roster management, clinical data exchange, encounter notification, and member insights with care gaps. A plan usually needs all four to get value from the connection.

• Roster management: Providers import the plan's member identifiers into Epic from a flat file of demographics, one line per patient. The identifiers then filter later requests and feeds to the plan's own members.
• Clinical data exchange: Payers can request a C-CDA for a patient or an encounter through the DocumentReference (Generated CCDA) FHIR API, and use Epic's wider FHIR library for more specific data.
• Encounter notification: Providers can turn on the HL7 v2 Outgoing ADT interface and the X12 278N notice of admission so the plan learns of visits, and the Outgoing Appointment Scheduling interface for upcoming ones.
• Care gaps: Providers can load care gaps in bulk through the Care Gaps Exchange flat file, built to Epic's community specification, and CDS Hooks can call the plan's service during a visit to show gaps or member insights.

Roster management is the foundation. Without a reliable member identifier on the patient record, every later feed either sends the plan too much data or misses members. Patient matching through the FHIR Patient $match operation, using the roster's demographics and identifier, is how a plan finds the right FHIR patient record before asking for more.

Each block is switched on by the provider organization, not by Epic alone. A plan that connects to ten health systems runs ten sets of conversations about which feeds to enable, for which members, and with what filters.

Where does prior authorization fit?

Prior authorization runs on three FHIR workflows built from Da Vinci implementation guides: Coverage Requirements Discovery, Documentation Templates and Rules, and Prior Authorization Support. Epic documents its own versions of these APIs for health systems, payers and delegates.

Epic's prior authorization playbook states that its prior authorization API functionality is released in the February 2026 version of Epic, and that the APIs were built around the Da Vinci 2.1 FHIR implementation guide without following it exactly. Teams should read Epic's individual API specifications rather than assume the guide's behavior.

• Coverage Requirements Discovery: When an order is placed or an appointment booked, the provider's Epic system asks the payer's service whether authorization is needed and what documentation applies.
• Documentation Templates and Rules: The payer supplies questionnaires with clinical logic, which the clinician completes inside Epic.
• Prior Authorization Support: The completed request goes to the payer, which returns an approval, a denial with reasons or a pended status asking for more.

For a plan, the practical result is that its CRD, DTR and PAS services become endpoints that Epic provider systems call during ordering and scheduling. The plan must host them reliably, version them, and answer within the decision times its own policies and regulators set.

What does the plan's side of the build include?

The plan's side is a set of jobs and services that sit between its core administration system and each provider connection. Most of them are small, but each needs an owner, monitoring and a test plan.

• Roster export: A scheduled job that builds the member demographics file for each provider organization and tracks what changed since the last run.
• Matching service: Logic that resolves each provider record to a member, holds uncertain matches for review, and logs every decision.
• Document intake: A FHIR client that requests C-CDA documents for members and passes them to care management or claims review.
• Event intake: Listeners for ADT and 278N admission notices, which update care management queues and trigger outreach after discharge.
• Care gap publisher: A job that turns the plan's quality measures into gap records in Epic's format and sends closures as well as openings.
• Hook and authorization services: The CDS Hooks service and the CRD, DTR and PAS endpoints, each with response time alerts.

Keep these pieces separate from the core administration system. When one provider organization changes a feed or a filter, the change should touch one connector, not the plan's claims engine.

Connection roles in Epic's documentation

Epic's prior authorization playbook separates connections by who runs Epic and who answers the requests. Knowing which role applies tells a team which app registrations and scopes it needs.

• Health system connecting with an Epic payer: The provider side sends CRD, DTR and PAS requests to a plan that also runs Epic.
• Payer system connecting with an Epic provider: A plan, or its vendor, answers the CRD, DTR and PAS requests coming from a health system on Epic.
• Delegate for an Epic payer: An organization that handles CRD, DTR or PAS for a payer under a delegation arrangement connects with the same apps and scopes as a payer system.
• Payer connecting with an Epic delegate: A payer that has delegated part of the work to an organization running Epic sends requests on to that delegate.

The same playbook notes that an Epic-to-Epic connection made without Payer Platform needs an extra step, downloading a client ID from the other organization. Confirm early whether both sides will use Payer Platform, because it changes the setup steps.

What should a plan settle before connecting?

Settle members, use cases and ownership before writing code. This checklist covers the decisions that shape the build.

• 1. Use case order: Choose the first exchange, such as care gaps at the point of care or admission notices, and the outcome it should change.
• 2. Member identifiers: Decide which identifier goes on the roster, how often the roster refreshes, and how terminated members are removed.
• 3. Data minimum: Agree with each provider which feeds and fields the plan receives, filtered to its members, and nothing more.
• 4. Care gap format: Map the plan's gap definitions to Epic's community specification, including how a gap is marked closed.
• 5. Service hosting: Plan uptime, response time targets and versioning for CDS Hooks and prior authorization services that Epic systems call during visits.
• 6. Feedback: Decide how the plan uses CDS Hooks feedback on what clinicians did, and who reviews it.
• 7. Per-provider rollout: Budget time for each provider organization's review, configuration and testing, not one rollout for all.

Where payer to provider connections stall

• Stale rosters: Members who left the plan keep receiving gap alerts, and new members are missing from feeds.
• Weak matching: Members are matched on name and birth date alone, and data lands on the wrong patient.
• Unclosable gaps: Care gaps are loaded without a way to close them, so clinicians see the same gap after addressing it.
• Slow hook services: A CDS Hooks service that answers slowly gets switched off, because it delays the clinician's screen.
• Too much data: Feeds are not filtered to the roster, and the plan receives visit notices for people it does not cover.
• Guide assumptions: A team codes to the Da Vinci guide alone and misses where Epic's APIs differ.

Each of these is cheaper to fix in design than after launch. Test with a small set of members at one provider organization before widening the roster.

How Agnotic can help

A plan's connection to Epic providers is a set of small, well-run services rather than one large integration. Agnotic Technologies builds them for the client: roster file generation and refresh, care gap files mapped to Epic's specification, CDS Hooks services with fast response and feedback capture, admission and visit notice intake, and CRD, DTR and PAS services built to Epic's published API specifications.

Agnotic also builds the monitoring that shows each provider connection's health, from roster match rates to hook response times, so the plan's team can see problems before clinicians do.

Sources

• Epic Vendor Services: Payer Platform overview
• Epic on FHIR: Payer connections to Epic provider systems playbook
• Epic on FHIR: Prior authorization playbook