What is the CARIN Alliance?
If you’ve ever wondered why a patient in 2026 can finally pull their claims data into a third-party app on their phone — without begging a payer for a CSV export — much of the answer traces back to the CARIN Alliance. The group has spent the better part of a decade pushing a fairly simple idea: patients should be able to direct their own health and claims data to wherever they want it to go, using open standards rather than proprietary integrations. Most of the FHIR-based consumer access flows now mandated under CMS rules carry CARIN’s fingerprints somewhere in their specification history.
Tell Us Your Requirements
Our experts are ready to understand your business goals.
Trusted by Industry Leaders Worldwide
Awards & Recognitions
Definition of the CARIN Alliance
The CARIN Alliance (Creating Access to Real-time Information Now) is a non-partisan, multi-stakeholder collaborative working to advance consumer-directed exchange of health information. Founded in 2016 and convened under the auspices of Leavitt Partners, the Alliance brings together payers, providers, government agencies, technology vendors, consumer advocates, and standards bodies to develop and promote technical specifications, policy frameworks, and trust models that enable patients to access and share their own health data using third-party applications of their choice.
The Alliance’s work spans three main lanes:
Technical specifications. CARIN authors and stewards FHIR Implementation Guides — most notably the CARIN Consumer Directed Payer Data Exchange (CARIN BB) profile, also known as Blue Button 2.0 for commercial payers. These specifications define how claims, encounters, medications, providers, and coverage data are exposed via FHIR APIs that patients can authorize third-party applications to access.
Trust framework. CARIN has developed the CARIN Code of Conduct, a self-attested framework that third-party consumer applications can adopt. The Code addresses privacy, security, transparency, and consent practices for apps that handle patient-directed health data outside HIPAA’s traditional covered entity boundary.
Policy advocacy. The Alliance contributes to federal and state policy conversations around consumer access — including ONC’s certification rules, CMS’s Patient Access API requirements, the Information Blocking framework, and state-level data exchange legislation.
In simple terms: CARIN Alliance is the standards-and-policy collaborative that built the FHIR rails for consumer-directed claims and clinical data access — and the trust framework that governs how third-party apps can responsibly use that data.
How CARIN Alliance Standards Work in Practice
The most operationally significant piece of CARIN’s work is the CARIN Blue Button (CARIN BB) Implementation Guide. Here’s how it functions in a real consumer access flow.
A patient downloads a third-party application — a personal health record app, a financial tool, a healthcare shopping platform. The app needs to access the patient’s claims and coverage data from their commercial health plan. Under the CMS Interoperability and Patient Access Final Rule, the payer is required to expose this data through a standardized FHIR API.
The patient initiates an authorization flow, typically using SMART on FHIR with OAuth 2.0. The patient logs into their payer portal through the app’s authorization redirect, consents to share specific data with the app, and the app receives an access token scoped to that patient and that data set.
The app then issues FHIR API calls against the payer’s CARIN BB endpoint. The responses come back as standardized FHIR resources — ExplanationOfBenefit for claims, Patient for demographics, Coverage for plan information, Practitioner and Organization for provider details, and Medication/MedicationDispense for pharmacy data. CARIN BB profiles each of these resources with US-specific constraints, value sets, and required elements.
The app processes the data, presents it to the patient, and may share it (with further patient consent) to other entities — a financial planning tool, a second-opinion service, a research registry. The CARIN Code of Conduct governs the app’s privacy and security practices throughout this chain.
Key CARIN Specifications and Adjacent Standards
- 01
CARIN Consumer Directed Payer Data Exchange (CARIN BB)
The flagship Implementation Guide. CARIN BB profiles FHIR R4 resources for commercial payer claims data, modeled after the original Medicare Blue Button 2.0 specification but extended for the commercial market. CMS regulations now reference CARIN BB as the specification payers should align with for consumer-facing FHIR APIs.
- 02
CARIN IG for Digital Insurance Card
A specification for digital health insurance cards exchanged via FHIR — addressing the perennially clunky problem of patients presenting paper or PDF insurance cards at every point of care.
- 03
CARIN Real Time Pharmacy Benefit Check
A specification for real-time pharmacy benefit and formulary information at the point of prescribing — letting clinicians see medication coverage, prior authorization requirements, and patient cost-sharing while writing the prescription.
- 04
CARIN Code of Conduct
The Alliance’s self-attested trust framework for third-party applications handling patient-directed data. Apps publicly attest to specific privacy, security, transparency, and consent practices. The Code is a complement to — not a substitute for — formal regulatory compliance.
- 05
Adjacent and Supporting Standards
CARIN’s work depends on a stack of underlying standards: HL7 FHIR R4 as the data model, SMART on FHIR for the authorization framework, OAuth 2.0 and OpenID Connect for token-based access, US Core profiles for clinical data alignment, and HIPAA plus the FTC’s Section 5 authority for the privacy/security backdrop.
- 06
Regulatory Hooks
The CMS Interoperability and Patient Access Final Rule (May 2020) and its expansion through the Prior Authorization Final Rule (2024) require certain payers — Medicare Advantage, Medicaid managed care, CHIP, and qualified health plans on federally-facilitated exchanges — to implement Patient Access APIs aligned with CARIN BB. The 21st Century Cures Act, Information Blocking rules, and ONC HTI-1 all reinforce the underlying right to consumer data access.
Implementation Considerations
Building a CARIN-aligned consumer access capability is rarely just a technical exercise. A few areas tend to determine whether the implementation actually works.
Authorization UX matters more than the FHIR plumbing. A patient who cannot navigate a payer’s authorization screen will never reach the data, no matter how well the API is built. Most CARIN BB rollout problems trace to confusing authorization flows, poor mobile rendering, or session timeouts that strand patients mid-consent.
Identity proofing is the quiet hard problem. Connecting an authenticated portal user to the right patient record — and ensuring an attacker can’t enroll under someone else’s identity to harvest their data — sits at the core of CARIN-style access. NIST SP 800-63 IAL2-equivalent identity proofing is the practical bar.
Plan for app vetting. Some payers want to maintain an “approved app” list. The CMS rules limit how restrictive this can be — payers can communicate non-binding information about whether an app has attested to the CARIN Code, but they cannot block patient-authorized access on the grounds that the app isn’t on a preferred list.
Map the data carefully. Payer claims systems weren’t designed with FHIR in mind. Mapping legacy 837/835 transactions, internal claim adjudication structures, and provider directories into ExplanationOfBenefit and related resources takes more iteration than teams expect. Edge cases — capitated claims, bundled payments, reversed adjudications, late adjustments — break the first drafts of every mapping.
Performance and rate limits. Apps issuing bulk historical claims pulls can overwhelm payer FHIR endpoints if rate limits aren’t set thoughtfully. CARIN BB doesn’t dictate rate limit policy, so each implementer makes their own — which means apps have to handle widely varying limits across payers.
Consent revocation. Patients need a clean path to revoke an app’s access. CMS requires this. Building the revocation flow, the audit trail, and the downstream propagation (the app should also stop calling the API) is more involved than a simple “delete token” button.
Don’t treat the Code of Conduct as a one-time check. Apps attest to the Code, then evolve their practices over time. Payers and providers offering CARIN-aligned APIs should have a process to surface current attestation status to patients in the authorization flow.
How Taction Helps with CARIN Alliance Implementations
Taction works on the integration layer for healthcare organizations and health IT vendors building toward — or operating within — the CARIN ecosystem. The pattern is familiar by now: payers and providers know they need to expose patient-directed FHIR APIs, but the upstream data plumbing rarely matches what FHIR profiles assume. That gap is where most of our work lives.
What we do:
- CARIN BB FHIR API implementation — We build payer-side FHIR endpoints conforming to the CARIN Consumer Directed Payer Data Exchange Implementation Guide, including the ExplanationOfBenefit, Coverage, Patient, Practitioner, Organization, and pharmacy resource profiles.
- Claims-to-FHIR transformation — We build the transformation layer that maps legacy 837/835 claims, internal adjudication systems, and member/provider directories into CARIN BB-compliant FHIR resources.
- SMART on FHIR authorization infrastructure — We design and build the OAuth 2.0 / OpenID Connect authorization servers, consent capture flows, and token management infrastructure that consumer-directed access depends on.
- App vetting and Code of Conduct workflow — We build the app registration, attestation tracking, and patient-facing transparency tooling that supports CARIN Code of Conduct alignment.
- Mirth Connect and integration channels — Our Mirth Connect consulting team builds and maintains the integration channels that move data between core payer systems, FHIR servers, and external consumer applications.
- Identity proofing and consent management — We build the identity verification and consent management infrastructure that consumer access flows require, aligned with NIST SP 800-63 guidance.
Related Terms and Resources
Explore related glossary terms:
- What is FHIR? — The data standard underlying CARIN’s specifications
- What is HL7? — The standards body that publishes the FHIR foundation CARIN profiles
- What is Healthcare Interoperability? — The broader category CARIN’s work sits within
- What is the 21st Century Cures Act? — The regulatory framework driving consumer access requirements
- What is HIPAA Compliance? — The privacy baseline that CARIN’s Code of Conduct sits adjacent to