Skip to content
The Algorithm
The Algorithm/Knowledge Base/CPCDS (Common Payer Consumer Data Set)
Healthcare Compliance

CPCDS (Common Payer Consumer Data Set)

The payer-side data model that maps adjudicated claims to FHIR resources for patient-facing interoperability under the CMS Interoperability Rule.

What You Need to Know

The Common Payer Consumer Data Set (CPCDS) is a data model and implementation guide developed by HL7 and adopted by CMS to define how health insurance payers should map their claims and encounter data to FHIR R4 resources for exposure through the Patient Access API mandated by the CMS Interoperability and Patient Access Final Rule (CMS-9115-F). The rule, finalized in May 2020 and fully effective July 2021, requires CMS-regulated payers — Medicare Advantage, Medicaid, CHIP, and QHP issuers on federally facilitated exchanges — to make claims and clinical data available to patients via a FHIR-based Patient Access API using SMART on FHIR authorization. CPCDS defines the specific mappings from adjudicated claim fields (from X12 835 and institutional/professional claim sources) to FHIR resources including ExplanationOfBenefit, Coverage, Patient, Practitioner, Organization, and related resources conforming to the CARIN Blue Button Implementation Guide.

Engineering a CPCDS-compliant Patient Access API requires implementing the CARIN Blue Button 2.0 IG, which profiles base FHIR R4 resources with US Core extensions and payer-specific must-support elements. The ExplanationOfBenefit (EOB) resource is the central FHIR artifact, carrying claim header information, diagnosis codes, procedure codes, adjudication details (paid amounts, patient liability, adjustment reason codes), and service line detail in a deeply nested structure. CPCDS maps distinguish between inpatient institutional, outpatient institutional, oral (dental), pharmacy, and professional/non-clinician EOB profiles — each with distinct cardinality and must-support requirements. A payer's claims data warehouse typically stores normalized relational data that must be denormalized and transformed into FHIR-native JSON structures, requiring ETL pipelines that maintain referential integrity across the linked FHIR resource graph (Coverage references Patient; EOB references Coverage, Patient, Practitioner, Organization).

A notable nuance of CPCDS implementation is the Provider Directory API, which is a companion requirement under the same CMS rule. Payers must also expose provider network information via a FHIR API conforming to the DaVinci PDEX Plan Net IG, which is architecturally separate from the Patient Access API but shares the same FHIR server infrastructure in most implementations. The Payer-to-Payer API, added via the CMS Interoperability Rule Part 2 (CMS-0057-F, effective 2024), further requires payers to exchange patient clinical and claims data with a patient's new payer when coverage changes — introducing OAuth 2.0 B2B trust federation requirements between payer FHIR servers. Engineering teams must also implement the FHIR Bulk Data Access (SMART Backend Services) specification for population-level data access alongside the patient-level SMART on FHIR flows, as CMS requires both.

How We Handle It

We implement CARIN Blue Button 2.0-conformant FHIR servers with claims-to-EOB transformation pipelines that ingest adjudicated X12 835 data and produce profile-valid FHIR resources with automated conformance validation on every transform cycle. Our Patient Access API deployments include SMART on FHIR authorization servers, token introspection endpoints, and patient identity proofing integrations that meet CMS requirements without requiring manual patient matching. We design payer-to-payer exchange architectures using SMART Backend Services for compliant B2B data transfer under CMS-0057-F timelines.

Services
Service
Healthcare Technology
Service
Compliance Infrastructure
Service
Data Engineering & Analytics
Related Frameworks
CARIN Blue Button 2.0 IG
HL7 FHIR R4
CMS-9115-F
SMART on FHIR
DaVinci PDEX
DECISION GUIDE

Compliance-Native Architecture Guide

Design principles and a structured checklist for building software that is compliant by default — not compliant by retrofit. Covers data architecture, access controls, audit trails, and vendor due diligence.

§

Compliance built at the architecture level.

Deploy a team that knows your regulatory landscape before they write their first line of code.

Start the conversation
Related
Service
Healthcare Technology
Service
Compliance Infrastructure
Service
Data Engineering & Analytics
Related Framework
CARIN Blue Button 2.0 IG
Related Framework
HL7 FHIR R4
Related Framework
CMS-9115-F
Platform
ALICE Compliance Engine
Service
Compliance Infrastructure
Engagement
Surgical Strike (Tier I)
Why Switch
vs. Accenture
Get Started
Start a Conversation
Engage Us