How the 21st Century Cures Act Shapes Health IT

The 21st Century Cures Act is a U.S. federal statute passed in 2016. Many of the interoperability and data access requirements health IT teams work with today stem from regulations written under its authority. In the U.S., that framework helps identify when configuration or workflow decisions may carry regulatory implications and when compliance or legal colleagues should be involved. In other jurisdictions, the Cures Act still shapes interoperability expectations because vendors design products to meet its requirements.

In 2016, most hospitals and ambulatory practices had adopted electronic health records through Meaningful Use. Adoption was largely complete, but exchange was not. Data often remained inside individual systems, and sharing depended on custom interfaces, layered agreements, or manual workarounds shaped by both technical and business constraints.

The Cures Act addressed that environment through several connected policy and interoperability requirements. It:

→ Required certified health IT to support APIs without special effort
→ Established a baseline for interoperable data
→ Directed HHS to advance a nationwide trusted exchange framework
→ Prohibited information blocking
→ Expanded ONC's authority over certification

Those levers now operate as a coordinated framework. Together they define how data must be accessed, what must be included, how exchange is structured across organizations, and which practices are no longer acceptable.

APIs as the Foundation for Access

The Cures Act required certified health IT to provide APIs that allow access to electronic health information without special effort. ONC translated that requirement into certification criteria, including FHIR Release 4-based APIs tied to Certified Electronic Health Record Technology (CEHRT). This was not optional for vendors seeking certification.

Two types of APIs became central.

👤 Single-patient APIs allow individuals to connect third-party applications to their EHR and retrieve their electronic health information at no cost. This drove significant work around app registration, authentication workflows such as SMART on FHIR, and validation that required data elements were accessible through API endpoints.

👥 Bulk data APIs support population-level access. They enable payers, researchers, public health agencies, and organizations transitioning between EHR vendors to retrieve structured data at scale. They also support value-based care models that depend on large-volume exchange.

For health IT teams, this shifted interoperability from building interfaces to managing API capabilities. It required attention to mapping, data completeness, authentication configuration, and version control. API functionality now operates within a regulated certification framework rather than being treated as an optional feature.

USCDI and the Expanding Scope of Exchange

The United States Core Data for Interoperability (USCDI) defines the baseline data classes and elements that must be available for nationwide interoperability under ONC regulations. While the Cures Act did not name this standard directly, it directed HHS to advance standardized data exchange, and USCDI emerged from that authority.

With each new version, the required baseline expands. Additional data classes and elements are incorporated, increasing what must be accessible through certified capabilities such as APIs and export functions. As a result, interoperability expectations do not stay static. They expand with each version.

This expansion connects directly to electronic health information (EHI). Early information blocking compliance aligned with a narrower subset of data. In October 2022, the scope expanded to include all electronic protected health information within designated record sets. That change significantly widened operational expectations around access, exchange, and export.

The Standards Version Advancement Process (SVAP) allows vendors to adopt updated standards without waiting for full rulemaking cycles. As a result, baseline expectations can advance more quickly than many teams anticipate. Understanding which versions your organization supports is important because it directly affects interoperability expectations, certification capabilities, and compliance scope.

TEFCA and Nationwide Exchange

Section 4003 of the Cures Act directed HHS to establish a nationwide framework for health information exchange. That directive led to the Trusted Exchange Framework and Common Agreement, or TEFCA.

TEFCA creates a coordinated governance structure through Qualified Health Information Networks (QHINs) operating under a single Common Agreement. Instead of relying on only bilateral exchange relationships, organizations can participate in a broader network designed to support nationwide interoperability.

Recent updates incorporate FHIR-based exchange, reinforcing alignment between API requirements and network-level exchange. TEFCA reflects a shift toward structured national coordination instead of isolated technical connections.

Information Blocking as the Behavioural Guardrail

Information blocking refers to practices that interfere with the access, exchange, or use of electronic health information. The prohibition originates in the Cures Act, while detailed definitions, exceptions, and enforcement regulations were established through regulation. It applies to providers, developers, exchanges, and networks.

The regulations included defined exceptions for reasonable and necessary activities such as protecting privacy, ensuring security, preventing harm, and addressing infeasibility. These exceptions are conditional and require organizations to document that specific criteria are met.

For health IT professionals, the practical implication is clear. Initiatives affecting connectivity, third-party access, API configuration, export functionality, or exchange pathways may have regulatory implications. When decisions influence access, exchange, or use of EHI, compliance and legal colleagues should be part of the review process.

Certification Changes and Vendor Accountability

The Cures Act also expanded ONC's authority over the Health IT Certification Program, turning certification into an ongoing accountability structure tied to federal policy.

Under Conditions and Maintenance of Certification, vendors must:

✔ Publicly disclose API terms and documentation
✔ Limit unreasonable fees tied to interoperability capabilities
✔ Protect provider communications about usability and system performance
✔ Conduct and publish real-world testing results

These requirements address vendor transparency and market behaviour alongside technical capability. Vendors seeking certification to participate in the U.S. market design products to meet these standards, and those design decisions often influence global product strategy.

Seeing the Framework in Your Own Work

The Cures framework was designed so that each component reinforces the others.

👩🏻‍💻 APIs establish how information can be accessed
📋 The data baseline defines what must be included
🌐 TEFCA structures how it moves across organizations
🚫 Information blocking addresses practices that interfere with access
✅ Certification requirements hold vendors accountable over time

For many teams, these pieces appeared as separate initiatives rolled out over several years. In reality, they stem from the same federal policy direction.

You are likely working within that framework when a decision:

➡ Affects access, exchange, or use of electronic health information
➡ Involves certified health IT capabilities
➡ Touches API functionality or export processes
➡ Influences data portability or third-party connectivity
➡ Relates to participation in nationwide exchange frameworks

At that point, the discussion sits within a regulated structure shaped by the Cures Act. Recognizing that context helps health IT, compliance, and legal teams work together more deliberately rather than reacting after decisions have already been made.