21st Century Cures Act: Data Architecture Requirements for Health IT Teams

Introduction

The 21st Century Cures Act information blocking provisions went into full effect in October 2022. OIG enforcement began in 2024. For health IT teams, the practical implication is clear: systems that restrict or impede the flow of electronic health information — even through technical friction, not just explicit blocking — are now subject to civil monetary penalties. The architecture requirements that follow from the Act are specific: [[FHIR](/terms/FHIR)](/terms/FHIR) R4 APIs, bulk data export, and patient-facing data access flows that cannot be gatekept.

This guide translates the Cures Act's information blocking provisions and ONC's implementing regulations into concrete data architecture requirements.

---

What the Cures Act Prohibits

The information blocking provisions prohibit actors (health IT developers, health information networks, health care providers) from practices that are likely to interfere with access, exchange, or use of electronic health information (EHI), unless the practice qualifies for one of eight defined exceptions.

The eight exceptions (practices that are NOT information blocking):

1. Preventing harm
2. Privacy (HIPAA/state privacy law compliance)
3. Security
4. Infeasibility
5. Health IT performance
6. Content and manner (format restrictions)
7. Fees
8. Licensing

The key architectural implication: if your system technically enables information access but imposes unreasonable friction (slow APIs, complex authentication, expensive licensing fees), ONC can determine that the friction itself constitutes information blocking.

---

ONC Certified Health IT Requirements

ONC's 21st Century Cures Act Final Rule (ONC-Cures) requires EHR developers to achieve certification against the ONC Health IT Certification Program. For certified health IT, the following technical capabilities are mandatory:

Standardized API for Patient and Population Services

Certified EHRs must implement the ONC FHIR API certification criteria, which requires:

• FHIR R4 server supporting the US Core Implementation Guide
• SMART on FHIR authorization (both patient-facing and system scopes)
• Bulk Data Access (FHIR Bulk Data IG) for population-level queries
• Support for all required US Core resources

Required US Core resources (abridged):

Patient, AllergyIntolerance, CarePlan, CareTeam,
Condition (Problems and Health Concerns), Coverage,
Device (Implantable), DiagnosticReport (Lab, Cardiology, Radiology),
DocumentReference, Encounter, ExplanationOfBenefit,
Goal, Immunization, Location, Medication, MedicationDispense,
MedicationRequest, Observation (Lab, Vital Signs, Smoking Status),
Organization, Practitioner, PractitionerRole, Procedure,
Provenance, QuestionnaireResponse, RelatedPerson, ServiceRequest, Specimen

---

Bulk Data Export Architecture

The Cures Act requires population-level data access via FHIR Bulk Data. For health systems, this means implementing the $export operation at the Group or Patient level.

Bulk Export Pipeline Design

# FHIR Bulk Export operation handler (simplified)
async def handle_bulk_export_request(
    group_id: str,
    resource_types: list[str],
    since: str,
    requester_id: str,
    purpose: str  # TREATMENT, PAYMENT, OPERATIONS, INDIVIDUAL_ACCESS
):
    # 1. Authorize the request (SMART backend services or patient SMART flow)
    if not await authorize_bulk_request(requester_id, purpose, group_id):
        raise UnauthorizedError("Requester not authorized for this bulk export")

    # 2. Log the export request (information blocking audit)
    export_id = await log_export_request(requester_id, group_id, resource_types, purpose)

    # 3. Queue async export job (bulk exports take time)
    await queue_export_job(export_id, group_id, resource_types, since)

    # 4. Return 202 Accepted with Content-Location for polling
    return {
        "status": 202,
        "content_location": f"/$export-status/{export_id}"
    }

The bulk export must produce NDJSON files (newline-delimited JSON) in FHIR R4 format, organized by resource type.

---

Information Blocking Audit Logging

Every API request that involves EHI access should be logged for information blocking compliance. The log must be able to demonstrate that access was provided (not blocked) to authorized requesters.

CREATE TABLE governance.ehi_access_log (
  access_id             BIGINT GENERATED ALWAYS AS IDENTITY,
  access_ts             TIMESTAMP     NOT NULL,
  requester_id          VARCHAR(100)  NOT NULL,
  requester_type        VARCHAR(30),              -- PATIENT, PROVIDER, PAYER, HIE
  access_purpose        VARCHAR(50),              -- TPO, INDIVIDUAL_ACCESS, PUBLIC_HEALTH
  fhir_operation        VARCHAR(50),              -- read, search-type, $export, etc.
  resources_requested   VARCHAR(500),             -- comma-separated resource types
  access_granted        BOOLEAN       NOT NULL,
  denial_exception      VARCHAR(50),              -- if denied: which exception applies
  denial_reason_detail  VARCHAR(500),
  response_time_ms      INT,                      -- for performance friction detection
  ehi_record_count      INT,                      -- how many EHI records accessed
  PRIMARY KEY (access_id)
);

Track response_time_ms — consistently slow API responses for specific requesters could be construed as information blocking by technical impediment.

---

Patient-Facing Data Access

The Cures Act explicitly protects patient rights to access their own EHI. Your patient access architecture must:

• Allow patients to designate third-party apps to access their data on their behalf
• Not restrict which third-party apps can connect (subject to security review exceptions)
• Not charge patients for accessing their own data through API

The patient-facing SMART on FHIR flow:

[Patient] → [Third-Party App] → [Authorization Server (SMART)] → [FHIR Server]
                                         ↓
                                [Patient authenticates]
                                [Grants scopes: patient/*.read]
                                         ↓
                                [Access token issued]
                                         ↓
                           [App queries FHIR Server with token]
                           [Patient data returned]

---

Common Cures Act Architecture Gaps

1. FHIR server with incomplete US Core coverage: Missing resources (DiagnosticReport, DocumentReference, Provenance) creates an information blocking risk for those data types.

2. Bulk export not implemented: Organizations that offer patient-level FHIR but not bulk export are not meeting the population-level access requirement.

3. Slow API responses for third-party apps: If your API responds in 200ms for internal consumers but 5 seconds for third-party app consumers, that performance disparity is an information blocking red flag.

4. Authentication friction for third-party apps: Requiring manual review and multi-week approval for third-party app registration — without a security-based justification — can constitute information blocking.

---

Key Takeaways

• Information blocking is not just about explicit restriction — unreasonable technical friction (slow APIs, complex authentication, high fees) can constitute blocking.
• US Core compliance is the FHIR baseline for Cures Act compliance. Gaps in US Core resource coverage create direct compliance risk.
• Bulk Data Export is mandatory, not optional. Population-level FHIR access must be supported alongside patient-level access.
• Log every EHI access event, including response time. Audit logs are your primary evidence that access was provided, not blocked.
• Use the [Schema Diff](/tools/schema-diff) to track changes to your FHIR-backing data models — a schema change that removes a mapped US Core resource creates an immediate Cures Act compliance gap.