What the 21st Century Cures Act Is and Why Health IT Teams Cannot Ignore It

Signed December 13, 2016, the Cures Act amended the Public Health Service Act and the Federal Food, Drug, and Cosmetic Act. Title IV carries the health IT provisions relevant to developers, providers, and exchange networks.

Vendors and providers tend to discuss the Cures Act as a single mandate, which makes scoping conversations imprecise. In practice the obligations trace to specific sections, each with its own regulatory implementation and enforcement mechanism. Section 4002 governs certification conditions, 4003 defines interoperability and authorizes the trusted exchange framework, 4004 prohibits information blocking, 4005 established developer reporting, and Section 3060 sits in a different title entirely, carving certain clinical decision support software out of the FDA device definition. Knowing which section drives a requirement tells you which agency enforces it.

Statute alone does not tell you what to build. The operative requirements live in regulation, and that regulation has been revised roughly annually since 2020. ONC published the Cures Act Final Rule on May 1, 2020, establishing information blocking definitions, exceptions, and the standardized API certification criterion. The HTI rule series then reshaped those requirements in stages: HTI-1 in January 2024, a limited HTI-2 in December 2024, followed by HTI-3 and HTI-4, and the HTI-5 deregulatory proposal in December 2025. Teams still building against 2020 guidance are working from a superseded rulebook.

Information blocking is the provision with teeth. Any practice likely to interfere with access, exchange, or use of electronic health information is prohibited unless a regulatory exception applies. The exception set has grown from the original eight to include the TEFCA manner exception added by HTI-1 and a care access protection exception added by HTI-2. Critically, exceptions are affirmative defenses that must be met in full, documented contemporaneously, and applied consistently. A practice that nearly satisfies an exception satisfies nothing, which is where most vendor exposure originates.

For engineering teams, the Cures Act translates into a specific technical stack rather than a policy posture. Certified health IT must expose a standardized FHIR API supporting both single patient and population level access, authenticated through OAuth 2.0 and OpenID Connect, returning data elements defined by the United States Core Data for Interoperability. Patient-facing applications must be able to register and connect without special effort or unreasonable fees. If your product consumes EHR data, these same requirements define what you can rely on being available from certified systems.

Compliance readiness is demonstrable or it is not real. The organizations that handle scrutiny well have documentation showing which requests were received, how each was handled, which exception was relied on where one was, and who approved that decision. The organizations that struggle have reasonable practices and no record of them. Work through the items below before an inquiry rather than after, because response windows for nonconformity notices are short and reconstructing intent retroactively is unconvincing to reviewers.

HTI-5 pulls in two directions at once, and reading it as simple deregulation leads to poor planning. On certification, it proposes removing 34 of 60 criteria and revising seven, including the decision support intervention transparency requirements introduced by HTI-1. On information blocking, it tightens definitions and narrows exceptions ASTP/ONC believes have been misused, particularly around manner and fees. The net effect for most vendors is fewer certification artifacts to maintain and less room to justify withholding data. Plan capacity accordingly.