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.
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.
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.
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.