ONC 21st Century Cures Act Final Rule
ONC 21st Century Cures Act Final Rule
The ONC 21st Century Cures Act Final Rule (85 FR 25642, published May 1, 2020) is the primary vehicle through which the Office of the National Coordinator for Health Information Technology implemented the interoperability and information blocking provisions of the 21st Century Cures Act (Public Law 114-255). It targets two entities: health IT developers seeking ONC certification, and healthcare providers using certified health IT.
Where CMS interoperability rules (CMS-9115-F, CMS-0057-F) mandate what payers must do, the ONC Cures Rule mandates what health IT products must support and what actors must not do. The two regulatory frameworks operate in parallel and are both required for comprehensive interoperability.
For payer-specific obligations, see CMS Interoperability Rules. For the information blocking prohibition specifically, see Information Blocking Rule.
What the rule covers
The ONC Cures Rule has four primary areas:
- USCDI — the standardized data set that certified health IT must support
- FHIR API certification criterion — the specific technical requirement for EHR certification
- Information blocking prohibition — implementing the § 3022 prohibition from the statute
- Health IT certification program updates — restructuring the ONC Health IT Certification Program
United States Core Data for Interoperability (USCDI)
USCDI is ONC’s standardized list of health data classes and constituent data elements that certified health IT must be capable of accessing, exchanging, and using. It defines what data must be supported; US Core FHIR profiles define the technical how for FHIR-based exchange.
USCDI v1 data classes (effective 2020 rule)
| Data class | Representative data elements |
|---|---|
| Patient demographics | Name, date of birth, sex, race, ethnicity, address, phone, email |
| Clinical notes | Consultation notes, discharge summary, history and physical, imaging narrative, laboratory report, pathology report, procedure note, progress note (8 note types) |
| Allergies and intolerances | Substance, reaction, severity |
| Care team members | Practitioner, role, period |
| Clinical tests | Test name, result, interpretation (non-laboratory) |
| Goals | Goal description, target date |
| Health concerns | Problem type, onset, status |
| Immunizations | Vaccine administered, date, lot number |
| Laboratory | Test name, result, unit, reference range, interpretation |
| Medications | Medication name, dose, frequency, route, status |
| Problems | Diagnosis code, onset, resolution, status |
| Procedures | Procedure name, date performed |
| Provenance | Author, date, organization |
| Smoking status | Smoking status value |
| Unique device identifier (UDI) | Device identifier, issuing agency |
| Vital signs | Blood pressure, body height, body weight, BMI, heart rate, O2 saturation, respiratory rate, temperature |
USCDI update cycle
ONC updates USCDI on a defined schedule. Each new version adds data classes and elements:
| Version | Effective | Key additions |
|---|---|---|
| USCDI v1 | 2021 | Baseline data classes above |
| USCDI v2 | 2022 adoption criteria | Sexual orientation, gender identity, social determinants of health (SDOH) |
| USCDI v3 | 2023 adoption criteria | Encounter information, planned interventions, diagnostic imaging orders |
| USCDI v4 | 2024/2025 adoption | Expanded SDOH, average blood pressure, patient-reported data |
ONC certifies health IT against specific USCDI versions. The adoption of a new USCDI version into certification criteria follows a structured rulemaking process — ONC does not automatically require the latest version immediately upon publication.
USCDI+ (sector-specific extensions)
ONC introduced USCDI+ as a framework for defining sector-specific data sets beyond the base USCDI. USCDI+ is not a certification requirement — it is a voluntary framework organizations can use to signal alignment with sector-specific needs.
Current USCDI+ domains:
- Behavioral health — mental health diagnoses, substance use disorder data, SDoH screening results
- Cancer — oncology-specific data elements
- Public health — electronic case reporting, immunization registry data elements
FHIR API certification criterion: 45 CFR § 170.315(g)(10)
The most technically significant element of the ONC Cures Rule is the standardized API certification criterion at 45 CFR § 170.315(g)(10), titled “Standardized API for patient and population services.” This criterion replaced the earlier application access criterion and established FHIR R4 as the required standard for certified EHR products.
What the criterion requires
Health IT developers seeking certification must demonstrate that their product:
- Implements FHIR R4 as the base standard for the API
- Supports US Core profiles for all USCDI data elements — the FHIR representation of the USCDI data classes
- Implements SMART App Launch — specifically the authorization code grant (for patient-facing access) and the backend services profile (for system-to-system access)
- Supports required SMART scopes — granular scopes for patient-level and user-level data access (
patient/*.read,user/*.read, and resource-specific variants) - Publishes a FHIR capability statement and a SMART discovery document (
.well-known/smart-configuration) - Does not block authorized access — the certification criterion explicitly prohibits technical barriers to authorized third-party application access
Patient and population services
The criterion covers two contexts:
Patient services — a patient (or patient-authorized app) can retrieve their own data. This is the technical foundation for the CMS-9115-F Patient Access API obligation. A covered payer that is also a health IT developer must support this; a health system’s EHR must support it so that patients can access their records via third-party apps.
Population services — a clinician or care team member can query data across a patient population. This uses the SMART backend services profile and is relevant for population health management, quality reporting, and care management platforms.
Certification scope
The (g)(10) criterion applies to health IT developers seeking and maintaining ONC certification. Health systems that use certified EHRs benefit from (but do not independently seek) this certification — the certification belongs to the EHR vendor’s product, not the health system’s deployment.
Information blocking prohibition
The ONC Cures Rule implemented the § 3022 information blocking prohibition from the 21st Century Cures Act statute. ONC’s role was to define the prohibition and the eight exceptions in regulation. OIG’s role is enforcement and penalties.
Key elements ONC defined in the rule:
- Who is an “actor” (health IT developers, HINs, HIEs, providers — not payers)
- What counts as electronic health information (EHI) — the scope expanded to all ePHI in phase 2 (October 2022)
- The eight exceptions that define safe harbors for practices that would otherwise constitute information blocking
The information blocking prohibition is not a certification criterion — it is a statutory prohibition that applies independently of whether an organization has a certified product. But the certification program is ONC’s primary enforcement lever for health IT developers: engaging in information blocking can result in loss of certification.
See Information Blocking Rule for full coverage of all eight exceptions and the penalty structure.
Health IT certification program updates
The ONC Health IT Certification Program (the program that results in listings on the Certified Health IT Product List, CHPL) was restructured by the Cures Rule.
Certification structure changes
Modular certification: The rule formalized a modular approach — health IT products can be certified against individual criteria rather than requiring a monolithic “complete EHR” certification. This enables components, modules, and apps to seek certification for specific criteria.
Base EHR definition update: The minimum set of criteria that constitutes a “certified EHR technology” (CEHRT) was updated to include the new FHIR API criterion. A product that does not include (g)(10) certification cannot constitute CEHRT for Promoting Interoperability purposes.
Real World Testing: The rule introduced a “real world testing” requirement — certified health IT developers must test their certified products against real-world data and use cases and report results to ONC annually. This addressed concerns that products passing certification tests in controlled environments might not perform as expected in production.
Connection to Promoting Interoperability
The Promoting Interoperability (PI) program (formerly Meaningful Use) requires eligible hospitals and clinicians to use ONC-certified health IT (CEHRT). The certification requirement means:
- Providers cannot use uncertified EHRs and participate in PI programs
- EHR vendors must maintain certification to remain viable for PI-participating customers
- Loss of certification is a significant market consequence — it effectively disqualifies the product for PI use
This connection is what makes ONC certification criteria meaningful in market terms. The (g)(10) FHIR criterion is not just a technical standard — it is a market requirement for EHR vendors serving PI-participating providers.
Timelines
| Requirement | Compliance date |
|---|---|
| (g)(10) certification criterion available for testing | March 2020 |
| Initial compliance deadline for (g)(10) | December 31, 2022 |
| Phase 1 information blocking (USCDI data scope) | April 5, 2021 |
| Phase 2 information blocking (full ePHI scope) | October 6, 2022 |
| Real world testing first reporting cycle | 2022 |
| USCDI v2 adoption into certification criteria | 2022 rulemaking |
| OIG information blocking enforcement rules published | 2023 |
| First CMP actions against health IT developers | 2024–2025 |
Implications for EHR developers
The ONC Cures Rule directly shapes the product requirements for health IT developers:
API openness is a certification requirement. A certified EHR product must expose a FHIR R4 API with SMART App Launch support. Restricting or degrading this API — even for competitive reasons — risks both information blocking penalties and certification withdrawal.
USCDI coverage drives roadmaps. Each USCDI update that is adopted into certification criteria creates a new product requirement. EHR vendors must track the ONC certification update cycle and plan USCDI coverage accordingly.
Real world testing creates ongoing accountability. Annual real world testing reporting means certification is not a one-time event. Vendors must demonstrate continued conformance in production environments.
Information blocking is an existential risk. For a certified health IT developer, an OIG finding of information blocking can result in certification withdrawal — effectively removing the product from the market for PI-participating customers.
Implications for healthcare providers
Providers are actors under the information blocking prohibition and must use certified health IT. The practical implications:
EHR procurement is constrained by certification. A health system cannot use an uncertified EHR and participate in Promoting Interoperability programs. Vendor selection must include certification status verification.
Patient data access is a legal obligation. Providers must allow patients to access their records through the FHIR API supported by their certified EHR. Restricting this access — even if the EHR vendor would technically allow it — can constitute information blocking by the provider.
Promoting Interoperability scoring. The PI program measures interoperability activities including e-prescribing, health information exchange, and patient data access. Information blocking findings result in a zero score on the PI measure, with corresponding payment implications.
Relationship to CMS rules
ONC and CMS rules address the same interoperability goals through different regulatory mechanisms targeting different entities.
| Dimension | ONC Cures Rule | CMS Interop Rules |
|---|---|---|
| Primary target | Health IT developers, providers | Payers (MA, Medicaid, CHIP, QHP) |
| Mandate type | Certification criteria + information blocking prohibition | API implementation mandates |
| Enforcement body | OIG (CMPs), ONC (certification) | CMS (public reporting, CMPs) |
| Technical lever | ONC Health IT Certification Program (CHPL) | FHIR API compliance audits |
Both sets of rules cite FHIR R4, US Core, and SMART App Launch. A payer building a Patient Access API (CMS-9115-F) typically integrates with EHR products that have (g)(10) certification (ONC Cures Rule). The two rule sets are designed to interlock.
See also
- Information Blocking Rule — the § 3022 prohibition in detail: actors, exceptions, penalties
- CMS Interoperability Rules — CMS-9115-F and CMS-0057-F overview
- TEFCA — ONC’s nationwide exchange framework, authorized by the same statute
- Patient Access API — CMS-9115-F Patient Access, which relies on (g)(10) certified EHR APIs