Skip to content
The Algorithm
The Algorithm/Knowledge Base/21st Century Cures Act
Healthcare Regulation

21st Century Cures Act

The 2016 law that banned information blocking and mandated patient data access, reshaping how EHRs, payers, and health IT vendors must operate.

What You Need to Know

The 21st Century Cures Act (Public Law 114-255), enacted December 2016, is a sweeping health IT law with multiple enforcement arms. Title IV establishes the information blocking prohibition — making it unlawful for health IT developers, health information exchanges, health information networks, and healthcare providers to engage in practices that interfere with the access, exchange, or use of electronic health information (EHI). The ONC implemented information blocking rules at 45 CFR Part 171, defining eight exceptions (including the Privacy Exception, Security Exception, Preventing Harm Exception, and Infeasibility Exception) that permit certain restrictions. The law also mandated ONC Certification for health IT, required EHR vendors to provide open APIs without special effort or fees, and directed CMS to implement interoperability requirements for payers. Civil penalties for information blocking can reach $1 million per violation for health IT developers and networks.

The engineering reality is that "information blocking" is defined expansively: any practice that is "likely to interfere" with EHI access, not just deliberate obstruction. This catches a wide range of common engineering decisions — rate limiting APIs too aggressively, requiring non-standard authentication for data access, failing to support standard export formats, designing data migration processes that make switching vendors costly, or contractual terms prohibiting data portability. Health IT developers certified under ONC must implement FHIR-based standardized APIs (§ 170.315(g)(10)) that allow patients and authorized third parties to access all EHI covered by the US Core Data for Interoperability (USCDI) standard — currently USCDI v3 for 2023 certification. Failure to provide API access without special effort, fees, or terms is itself an information blocking act, not just a certification failure.

The Act's information blocking prohibition intersects with HIPAA in nuanced ways. HIPAA permits but does not require many data restrictions — the Cures Act removes the option to use HIPAA as justification for blocking EHI access unless a specific exception applies. The Preventing Harm Exception requires a reasonable belief that access will endanger patient safety — it is not a general clinical discretion carve-out. The Privacy Exception aligns closely with HIPAA consent requirements but goes further in some respects: EHI scope is broader than HIPAA's definition of PHI, covering all individually identifiable health information in electronic form. For health IT developers, the interaction with USCDI version updates creates ongoing engineering obligations: as USCDI expands (v1 had 21 data classes; v3 has substantially more), certified systems must update their FHIR API implementations to include newly required data elements within ONC-specified timelines.

How We Handle It

We audit health IT architectures against ONC's eight information blocking exceptions, documenting which practices are covered by which exception and implementing technical controls that demonstrate affirmative compliance rather than mere absence of blocking. Our API implementations follow § 170.315(g)(10) to the letter — no hidden fees, no special registration flows, token-based access matching SMART on FHIR 2.0 scopes aligned to USCDI data classes. We build API usage analytics that distinguish legitimate rate limiting from patterns that could be characterized as interference.

Services
Service
Healthcare Technology
Service
Compliance Infrastructure
Service
Regulatory Intelligence
Related Frameworks
ONC Interoperability RuleTEFCA
HL7 FHIR R4
USCDI
HIPAA
DECISION GUIDE

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.

§

Compliance built at the architecture level.

Deploy a team that knows your regulatory landscape before they write their first line of code.

Start the conversation
Related
Service
Healthcare Technology
Service
Compliance Infrastructure
Service
Regulatory Intelligence
Related Framework
ONC Interoperability Rule
Related Framework
TEFCA
Related Framework
HL7 FHIR R4
Platform
ALICE Compliance Engine
Service
Compliance Infrastructure
Engagement
Surgical Strike (Tier I)
Why Switch
vs. Accenture
Get Started
Start a Conversation
Engage Us