PDex IG STU 2.1.0 and CARIN BB IG STU 2.0.0 both ship under the Patient Access API umbrella, and the resource scopes overlap in ways that confuse first-time implementers. This is not a hypothetical confusion; payers spend real engineering time arguing which IG owns which resource. The honest answer is that the two are designed to complement, not compete, but a clean implementation requires picking the right profile for each resource and being explicit about it. This comparison lays out where each IG wins and how production payers actually split the work. For broader context, FHIR vendor evaluation guides covers the platform-level question.
What Each IG Actually Covers
CARIN BB IG STU 2.0.0 focuses on claims and benefits. It defines ExplanationOfBenefit profiles for medical, pharmacy, oral, and vision claims, plus Coverage and Patient profiles aligned with the claims context. It includes recent additions for Vision and Dental EOB. The intended audience is members consuming their claims history through a third-party app.
PDex IG STU 2.1.0 focuses on clinical data exchange. It defines profiles for clinical resources (Observation, Condition, Procedure, AllergyIntolerance, etc.) plus Coverage, Patient, and Practitioner resources. The intended audience is broader, covering both member-facing apps and other payers receiving data under Payer-to-Payer Data Exchange.
The overlap appears in three resources: Coverage, Patient, and the boundary case of how clinical claims (medical EOB with diagnoses and procedures) relate to clinical resources (Condition, Procedure).
Where CARIN BB Wins
CARIN BB wins for any resource centered on the claims and benefits flow. ExplanationOfBenefit is unambiguously CARIN BB territory. The Coverage profile in CARIN BB is tuned for benefits context (deductibles, copays, network status from the member's view). The value-set bindings are calibrated for claims data: adjustment reason codes, place-of-service codes, service categories.
For a member checking their EOB history, CARIN BB is the profile set they expect to see.
Where PDex Wins
PDex wins for any resource centered on clinical data exchange. Condition, Procedure, MedicationStatement, Observation, AllergyIntolerance are PDex profiles. The Coverage profile in PDex is tuned for clinical context (enrollment information another payer needs during transfer). The value sets align with USCDI clinical data classes.
For a payer-to-payer transfer or a provider accessing member clinical data, PDex is the profile set that matches the use case.
How Production Implementations Resolve the Overlap
Most production CMS-0057-F implementations use both IGs in parallel, with explicit routing rules. The Patient Access API serves ExplanationOfBenefit and Coverage (benefits context) using CARIN BB profiles. The same Patient Access API serves Condition, Procedure, and clinical Observation using PDex profiles. The Patient resource is typically conformant to both IG sets, with the broader PDex profile chosen as the canonical representation.
Implementations that try to force one IG to cover everything end up with awkward profile bindings and downstream search-parameter quirks. Implementations that split cleanly along the use-case boundary tend to be easier to extend and easier to debug.
The Drug Formulary Case
US Drug Formulary IG STU 2.0.1 is a third IG required under Patient Access for the formulary data scope. It does not overlap with CARIN BB or PDex; formulary data has its own profile set. Mentioning it here only to note that "PDex or CARIN BB" is a two-way framing of a three-way Patient Access IG picture, and the third IG is its own consideration.
Practical Rule of Thumb
A simple rule that holds up across most production implementations: if the resource is what the member sees on an EOB statement, use CARIN BB. If the resource is what the receiving payer or treating provider needs about the member's clinical picture, use PDex. If the resource is Coverage or Patient and both could apply, use PDex as the canonical and reference CARIN BB profile from the EOB context.
For the CARIN BB-specific implementations, the Top 5 CARIN BB IG implementations covers the leading vendors. For the platform-level question of Patient Access API delivery, the Top 5 Patient Access API platforms for CMS-0057-F covers the broader set.