21st Century Cures Act

regulatory framework regulatory compliancehealthcareinteroperabilityprivacy
Source: HHS System: https://www.congress.gov Code: Cures Act Reviewed: 07/01/2026 License: CC-BY-4.0

21st Century Cures Act

One-sentence definition: The 21st Century Cures Act (H.R. 34, 2016) is the federal law that established the information blocking prohibition, directed ONC to develop USCDI and mandate FHIR-based APIs through certification criteria, and created the patient access rights framework that underlies US health data interoperability regulation.

Full Definition

The 21st Century Cures Act was signed into law on December 13, 2016. While its scope is broad — covering drug development, medical devices, mental health, and other health domains — its most consequential provisions for health IT are found in Title IV: the interoperability and information blocking provisions that reshaped how health data is accessed, exchanged, and controlled in the United States.

The core interoperability provisions directed ONC to write rules prohibiting information blocking, requiring certified health IT to support standardized APIs for patient access, and establishing USCDI as the required data set. ONC implemented these requirements through the 21st Century Cures Act Final Rule, published in March 2020 and phased in through 2021–2022. CMS simultaneously published a companion rule (CMS-9115-F) requiring FHIR-based APIs for payer patient access.

The Cures Act represented a shift in the federal government’s approach to health IT: from incentivizing adoption (HITECH’s Meaningful Use program) to mandating interoperability and penalizing obstruction. Its information blocking prohibition created legal liability for practices that had previously been widespread and unregulated.

For the implementing regulations, ONC certification requirements, information blocking exceptions, and enforcement details — see the canonical reference → ONC, Cures Act, and Information Blocking.

Context and Usage

Where This Term Appears

The Cures Act is referenced throughout health IT compliance and implementation:

  • ONC regulations — 45 CFR Parts 170 and 171 implement the Act’s health IT provisions; rulemaking documents cite specific statutory sections
  • CMS regulations — CMS-9115-F (2020) and CMS-0057-F (2024) implement the Act’s patient access requirements for payers
  • Industry contracts — vendor agreements, data use agreements, and API terms of service cite Cures Act compliance obligations
  • Certification documentation — ONC’s Health IT Certification Program certifies systems against Cures Act-derived criteria
  • Legal and compliance discussions — “Cures Act compliance” refers specifically to the information blocking, API, and USCDI requirements

Common Usage Examples

In conversation: “That contract clause restricting data portability was written before the Cures Act — legal says it may constitute information blocking now.”

In documentation: “This endpoint implements the Cures Act § 4006 standardized API requirement, supporting FHIR R4 and US Core profiles.”

In technical contexts: A health IT developer confirming their product meets the 45 CFR 170.315(g)(10) certification criterion — the Cures Act-derived requirement for patient-facing FHIR APIs.

Why the Cures Act Exists

The Cures Act’s health IT provisions were a response to documented failures of prior interoperability approaches and specific patterns of anticompetitive behavior in health IT markets. Congressional hearings preceding the Act established that:

  • EHR vendors were writing contracts that prevented hospitals from sharing patient data with competing systems
  • Patient portals were technically compliant with Meaningful Use but designed to be difficult for patients to use
  • Health information blocking — deliberately making data exchange difficult or expensive — was widespread and profitable

The Cures Act addressed these problems by shifting the legal default: sharing is required unless a specific exception applies, and obstruction is a violation. Combined with the API mandate (which required technical mechanisms for sharing), the Act aimed to make data blocking both illegal and technically difficult.

Key Provisions for Health IT

Information Blocking Prohibition

The Act’s § 3022 prohibits covered actors — health IT developers, health information networks, and healthcare providers — from engaging in practices that are likely to interfere with, prevent, or materially discourage access, exchange, or use of EHI. The prohibition is backed by civil monetary penalties and, for health IT developers, potential loss of ONC certification. ONC published eight regulatory exceptions under which otherwise-interfering practices are permitted.

Patient Access to EHI

The Act directed HHS to establish requirements for patients to access their electronic health information. This was implemented through ONC’s API certification criteria and CMS’s Patient Access API rule. The combined effect: patients can access their own data through standard FHIR APIs at no cost, using apps of their choosing, without depending on a provider portal.

Standardized API Requirements

ONC’s Cures Act rule required certified health IT to support a FHIR R4 API for patient access (45 CFR 170.315(g)(10)). This API must support US Core profiles, SMART on FHIR authorization, and publication of a capability statement. The requirement applies to any health IT developer whose product is ONC-certified — a category that includes most commercial EHRs sold in the US market.

EHI Export Capabilities

The Act required certified health IT to support export of all EHI in a patient’s record — not just the USCDI elements — in a computable format. This provision (45 CFR 170.315(b)(10)) was intended to prevent vendor lock-in by ensuring patients and providers can extract complete records when changing systems.

Affected Parties

Healthcare Providers

Hospitals, physician practices, and other healthcare providers are covered actors subject to the information blocking prohibition. They cannot use contractual or operational practices to prevent patients or authorized parties from accessing EHI. Enforcement is through OIG rather than ONC; penalties for providers include exclusion from federal healthcare programs.

Health IT Developers

EHR vendors and other health IT developers of certified products are subject to both the information blocking prohibition and the ONC certification requirements. They must build and maintain the FHIR APIs, support USCDI data elements, and not engage in blocking practices — including through licensing agreements, technical design choices, or fee structures.

Health Information Networks

HIEs, HIOs, and other health information networks (HINs) are covered actors subject to the information blocking prohibition. A network that facilitates exchange for a fee but structures access to favor certain participants or exclude competitors may be engaging in information blocking.

Relationship to Other Terms

  • ONC — the agency that implemented the Act’s health IT provisions and oversees certification and information blocking compliance for health IT developers
  • Information Blocking — the specific prohibition created by the Act; governed by ONC at 45 CFR Part 171
  • USCDI — the data standard the Act directed ONC to establish and maintain
  • CMS — the agency whose companion rule implemented patient access API requirements for payers
  • FHIR — the technical standard required by ONC’s implementing certification criteria

Common Misconceptions

Misconception 1: Cures Act Only Affects Vendors

  • Incorrect belief: The Cures Act’s information blocking provisions are only a concern for EHR vendors and health IT developers.
  • Reality: Healthcare providers and health information networks are also covered actors subject to the information blocking prohibition. A hospital system that restricts patient data portability through operational practices, referral network agreements, or fee structures may be violating the Act regardless of which EHR it uses.
  • Why it matters: Compliance programs at healthcare organizations need to address information blocking as an organizational risk — not just a vendor requirement to pass along in procurement.

Misconception 2: All Data Must be Shared Freely

  • Incorrect belief: The Cures Act requires all health data to be accessible to anyone without restriction.
  • Reality: The Act prohibits interference with access to EHI but defines eight regulatory exceptions — including exceptions for privacy, security, preventing harm, and reasonable fees. The Act does not eliminate privacy rights, security controls, or the ability to charge for data services; it creates a framework within which those controls must operate.
  • Why it matters: Organizations that over-restrict data sharing out of excessive caution about HIPAA or other privacy rules may be engaging in information blocking; organizations that share data indiscriminately may be violating HIPAA. The Cures Act exceptions and HIPAA’s minimum necessary standard need to be applied together.

Why the Cures Act Matters

The 21st Century Cures Act is the foundational legislative instrument for US health data interoperability. Every major health IT regulatory development since 2020 — ONC’s information blocking rules, US Core FHIR profiles, USCDI versions, CMS payer API requirements, TEFCA — flows from or aligns with its provisions.

For health IT teams, “Cures Act compliance” is not a single checkbox. It encompasses API implementation (FHIR R4 + US Core + SMART on FHIR), data element support (USCDI version certified against), information blocking policy review (contracts, fees, operational practices), and EHI export capability. Understanding the Act’s structure is the prerequisite for understanding why these individual requirements exist and how they relate to each other.

Cross-References

  • ONC — the agency that implements the Act’s health IT provisions
  • Information Blocking — the core prohibition created by the Act
  • USCDI — the data standard the Act mandated
  • CMS — the agency implementing the Act’s payer-side requirements
  • FHIR — the technical standard required by ONC’s implementing rules

Last reviewed: January 7, 2026 Definition authority: HHS/ONC Content status: Canonical reference