EHR-FHIR Integration for Payer Data Exchange: What Actually Ships

EHR-FHIR integration for payer data exchange follows Da Vinci patterns. Understanding what ships in production shapes realistic expectations.

Data flows in production

1. Provider → Payer. Prior authorization via Da Vinci PAS; claims via X12 837. 2. Payer → Provider. Da Vinci PDex Provider Access delivers coverage, clinical data. 3. Payer → Patient. Patient Access API exposes member data. 4. Payer → Payer. Cross-payer member data via Bulk Data IG.

CMS-0057 timeline

FHIR resources involved

1. **Patient — Member identity. 2. Coverage — Insurance coverage. 3. ExplanationOfBenefit — Claims adjudication. 4. Claim — Claims data. 5. Condition, Observation, MedicationRequest** — Clinical data.

Common integration challenges

1. Terminology binding differences. 2. MPI federation across payer + provider. 3. Auth model coordination. 4. Rate limiting for provider queries. 5. Consent tracking.

Vendor state (mid-2026)

Integration surface

1. FHIR REST endpoints per API. 2. SMART Backend Services for auth. 3. Bulk data storage. 4. Terminology server. 5. Audit trail.

Common EHR-payer integration mistakes

1. Custom auth vs. SMART BE. 2. Manual data mapping vs. Da Vinci profiles. 3. Sync-only bulk export. 4. Missing race/ethnicity extensions. 5. Aggressive rate limits.

EHR-FHIR integration for payer data exchange is CMS-mandated in 2026. Da Vinci profiles + SMART auth are the shipping path; custom is legacy.