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.
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.
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.
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.