21st Century Cures Act Compliance: A Complete Developer Guide (2026)

Key Takeaways

• The 21st Century Cures Act requires healthcare organizations and their technology vendors to provide patients with electronic access to their health data without delay and without information blocking.
  
  
• Information blocking — the practice of interfering with, preventing, or discouraging access, exchange, or use of electronic health information (EHI) — carries penalties of up to $1 million per violation for health IT developers.
  
  
• As of October 2022, information blocking rules apply to ALL electronic health information, not just USCDI v1 data elements. If your software restricts, limits, or delays patient access to any EHI, you may be violating the Cures Act.
  
  
• Healthcare software developers must build systems that support open APIs (FHIR-based), patient data access, and seamless interoperability — or risk penalties and loss of ONC certification.
  
  
• Eight specific exceptions exist where restricting access is permitted, but each has strict conditions that must be documented and justified.

1. What Is the 21st Century Cures Act

The 21st Century Cures Act was signed into law in December 2016 with broad goals to accelerate medical product development, bring innovations to patients faster, and advance healthcare interoperability. For healthcare IT, the most significant provisions are the information blocking rules and the requirements for standardized, open APIs for health data exchange.

The Office of the National Coordinator for Health Information Technology (ONC) and the Centers for Medicare & Medicaid Services (CMS) issued final rules in 2020 implementing the Cures Act’s interoperability provisions. These rules fundamentally changed how healthcare software must handle patient data access and exchange.

For software developers, the Cures Act means one thing: your systems must allow health data to flow freely to patients, providers, and authorized third parties using standardized APIs. Any practice that interferes with this data flow — whether intentional or through poor system design — can constitute information blocking.

2. Information Blocking Rule Explained

Information blocking is the single most important concept in the Cures Act for healthcare software developers. It is defined as a practice that is likely to interfere with, prevent, or materially discourage access, exchange, or use of electronic health information (EHI).

What Constitutes Information Blocking

Restricting data access. Preventing patients, providers, or authorized third parties from accessing EHI through your software. This includes not offering APIs, requiring cumbersome processes to access data, or limiting what data can be accessed.

Imposing unreasonable fees. Charging excessive fees for data access, API usage, or interoperability that effectively discourage data exchange. Reasonable fees for value-added services are permitted, but fees that function as barriers to basic data access are not.

Imposing unreasonable contract terms. Using license agreements, terms of service, or contractual provisions that restrict how health data can be used, shared, or accessed. Non-compete clauses that lock data into proprietary formats, gag clauses that prevent discussing interoperability limitations, and exclusivity arrangements that prevent connecting to competing systems can all constitute information blocking.

Technical interference. Designing systems that make data exchange unnecessarily difficult. This includes using proprietary data formats when standards exist, implementing APIs that are unreasonably slow or unreliable, requiring unnecessary manual steps for data export, and not supporting standard terminologies or transport protocols.

Delaying data access. Making data available but with unreasonable delays. If your system can provide data in real-time but imposes artificial delays (batch processing when real-time is feasible, queuing requests unnecessarily), this can constitute information blocking.

What Does NOT Constitute Information Blocking

Not every restriction on data access is information blocking. The Cures Act recognizes that there are legitimate reasons to limit data access in certain circumstances:

• Protecting patient privacy (when the patient has requested restrictions)
• Maintaining system security (preventing unauthorized access)
• Following state or federal laws that restrict disclosure of certain data types (substance abuse treatment records under 42 CFR Part 2, for example)
• Reasonable system maintenance and downtime
• Addressing imminent patient safety concerns

However, each of these situations must meet the specific conditions of one of the eight recognized exceptions (covered in Section 5).

3. Who Is Subject to Information Blocking Rules

Three categories of entities — called “actors” — are subject to the information blocking rules:

Healthcare Providers

Any hospital, physician, clinic, or other healthcare provider that participates in Medicare, Medicaid, or other federal healthcare programs. This covers virtually all healthcare providers in the United States.

Provider examples: Hospitals, health systems, physician practices, clinics, behavioral health providers, home health agencies, skilled nursing facilities, laboratories, imaging centers.

Health Information Networks (HINs) and Health Information Exchanges (HIEs)

Organizations that facilitate the exchange of health data between healthcare entities. This includes regional HIEs, national networks like CommonWell and Carequality, and any entity that provides health information exchange services.

Health IT Developers of Certified Health IT

Any company that develops, maintains, or distributes health IT that is certified under the ONC Health IT Certification Program. This is the category most relevant to healthcare software companies.

Critical point: If your software is ONC-certified (or uses ONC-certified components), your company is an “actor” under the information blocking rules and subject to penalties. Even if your software is not certified, if you are a business associate or subcontractor to a certified health IT developer, information blocking rules may affect you through contractual obligations.

If your organization develops EHR integration solutions or healthcare interoperability platforms, understanding these rules is essential.

4. What Counts as Electronic Health Information

The scope of EHI under the information blocking rules has expanded significantly since the initial implementation.

Initial Scope (Before October 6, 2022)

Initially, the information blocking rules applied only to EHI as defined by the USCDI v1 (United States Core Data for Interoperability) data elements. This included a limited set of clinical data: patient demographics, allergies, medications, conditions, lab results, vital signs, procedures, clinical notes, immunizations, and a few other data classes.

Current Scope (October 6, 2022 and Beyond)

Since October 6, 2022, the definition of EHI expanded to include essentially ALL electronic health information in a designated record set as defined by HIPAA. This means:

• All clinical data (not just USCDI elements)
• Billing and claims data
• Insurance and coverage information
• Care plans and assessments
• Imaging reports and studies
• Pathology reports
• Genetic and genomic data
• Patient-generated health data
• Administrative data related to patient care
• Any other information used to make decisions about the patient

What this means for developers: Your software cannot selectively expose only certain data elements through APIs while keeping other data inaccessible. If the data exists in your system and relates to patient care, it must be accessible through standardized APIs (subject to the recognized exceptions).

5. The Eight Information Blocking Exceptions

The Cures Act recognizes eight specific exceptions where restricting access to EHI is permitted. To qualify for an exception, you must meet ALL of the stated conditions — not just some of them.

Exception 1: Preventing Harm

You may restrict access to EHI if a licensed healthcare professional determines, on an individualized basis, that providing the data would pose a substantial risk of harm to a patient or another person.

Conditions:

• The determination must be made by a licensed healthcare professional with a patient relationship
• The risk must be individualized (not a blanket policy)
• The restriction must be the minimum necessary to prevent the harm
• The practice must be consistent with organizational policies

Example: A psychiatrist determines that releasing certain mental health notes to a patient’s spouse would endanger the patient due to a domestic violence situation. The psychiatrist documents the individualized assessment and restricts only the specific notes that pose a risk.

This exception does NOT cover: Blanket policies that restrict all patients from accessing certain categories of data. Restricting access because the provider is concerned about litigation. Withholding information because it might upset the patient.

Exception 2: Privacy

You may restrict access to EHI to protect patient privacy, but only under specific conditions.

Conditions:

• The restriction must be based on applicable privacy laws (HIPAA, state laws, 42 CFR Part 2)
• If the restriction is based on patient request, the request must be documented
• If the restriction is precautionary (not required by law), you must have a reasonable belief that the patient would not want the information shared
• The restriction must not be broader than necessary

Example: A patient specifically requests that their HIV test results not be shared with a third-party app. The provider restricts access to only those specific results while maintaining access to all other EHI.

Exception 3: Security

You may restrict access to EHI to protect the security of electronic systems and data.

Conditions:

• The practice must be directly related to safeguarding the confidentiality, integrity, or availability of EHI
• The practice must be tailored to specific security risks
• The practice must be implemented consistently (not selectively applied to block certain users or applications)
• The practice must not be more restrictive than necessary

Example: Temporarily disabling API access during an active security incident while the vulnerability is being remediated. Requiring OAuth 2.0 authentication for all API access. Rate-limiting API calls to prevent denial-of-service attacks.

This exception does NOT cover: Refusing to implement APIs because of security concerns. Requiring unnecessarily burdensome authentication that discourages data access. Using security as a pretext to block competitors from accessing data.

Exception 4: Infeasibility

You may restrict access if fulfilling the request is infeasible due to circumstances beyond your control.

Conditions:

• The infeasibility must be due to factors outside your reasonable control
• You must demonstrate that you have made reasonable efforts to fulfill the request
• The infeasibility must be temporary (you must work to resolve it)
• You must provide a reasonable timeline for when access will be available

Example: A natural disaster destroys your data center and you cannot provide API access until systems are restored. A third-party system you depend on for data access is experiencing an extended outage.

This exception does NOT cover: Not having built API capabilities yet. Budget constraints that prevented you from implementing interoperability features. Choosing not to prioritize interoperability development.

Exception 5: Health IT Performance

Health IT developers may take reasonable actions to maintain or improve health IT performance, provided certain conditions are met.

Conditions:

• The practice must be implemented for a legitimate purpose (maintenance, updates, security patching)
• Users must be given advance notice when possible
• The practice must not be used to lock out competitors or restrict interoperability
• Downtime or restrictions must be limited to what is necessary

Example: Scheduled system maintenance that requires temporarily taking APIs offline. Rolling out a security patch that requires brief API downtime. Performance optimization that temporarily limits API throughput.

Exception 6: Content and Manner

You may offer EHI access in a specific content or manner, provided you also offer alternatives.

Conditions:

• You must offer the data in at least one standardized format (FHIR, C-CDA, or other ONC-specified standard)
• If the requestor asks for a format you do not support, you must offer an alternative
• You must provide the data in a timely manner
• You cannot charge unreasonable fees for standard format access

Example: A third-party app requests data in a proprietary format. You offer the data in FHIR R4 format instead, which is a recognized standard. This is permitted as long as you provide the data in a timely manner.

Exception 7: Fees

You may charge reasonable fees for data access, provided the fees do not constitute information blocking.

Conditions:

• Fees must be based on objective, verifiable costs
• Fees must not be based on the volume of data or number of requests in a way that discourages access
• Fees must be non-discriminatory (same fees for all similarly situated requestors)
• Fees for basic data access to patients must be zero or minimal
• Fee schedules must be publicly available

Example: Charging a reasonable fee for custom API development or premium support services. Charging for value-added analytics built on top of standard data access.

This exception does NOT cover: Charging patients for access to their own data. Charging excessive per-API-call fees that discourage interoperability. Charging competitors higher fees than partners.

Exception 8: Licensing

You may require reasonable licensing terms for the use of your interoperability elements (APIs, data formats, documentation).

Conditions:

• Licensing terms must be non-discriminatory
• Licensing fees must be reasonable and based on objective criteria
• Licensing must not be used to prevent or discourage interoperability
• You must negotiate licensing terms in good faith and without unreasonable delay

6. ONC Health IT Certification Requirements

The ONC Health IT Certification Program establishes the standards and criteria that health IT must meet to be certified. Certification is required for EHR systems used by providers participating in CMS programs (Medicare Promoting Interoperability, MIPS, etc.).

Key Certification Criteria Relevant to Developers

API Certification (§ 170.315(g)(10)): Certified health IT must support a standardized HL7 FHIR-based API that allows patients and authorized third parties to access EHI. This API must conform to specific technical standards including FHIR R4, SMART on FHIR, and the Bulk Data Access specification.

Patient Demographics and Observations (§ 170.315(a)(5)): Certified systems must be able to record, change, and access patient demographic and observation data conforming to USCDI standards.

Clinical Information Reconciliation (§ 170.315(b)(2)): Certified systems must be able to reconcile medications, allergies, and problems from external sources.

Transitions of Care (§ 170.315(b)(1)): Certified systems must be able to create and receive C-CDA documents for care transitions.

Electronic Prescribing (§ 170.315(b)(3)): Certified systems must support electronic prescribing standards.

Conditions and Maintenance of Certification

Certified health IT developers must meet ongoing conditions to maintain certification:

Information blocking attestation. Developers must attest that they do not engage in information blocking practices.

Assurances. Developers must provide assurances that they will not interfere with users’ ability to access, exchange, or use EHI.

Communications. Developers must not prohibit or restrict communications regarding usability, interoperability, security, or user experiences with the health IT.

APIs. Developers must publish APIs using adopted standards, allow use without special effort, and not impose fees that discourage use.

Real world testing. Developers must conduct real world testing of certified health IT functionality and submit results to ONC annually.

7. USCDI and Standardized API Requirements

The United States Core Data for Interoperability (USCDI) defines the minimum set of data classes and elements that must be exchangeable through standardized APIs.

USCDI Version Progression

How USCDI Affects Your Software

If your software stores, processes, or exchanges any USCDI data elements, your API must be capable of exposing those elements in standardized FHIR R4 format. This is true whether your software is ONC-certified or connects to ONC-certified systems.

Each USCDI version adds new data classes that your software may need to support. When ONC advances the required USCDI version for certification, certified health IT developers have a defined timeline to update their systems.

For developers building healthcare interoperability solutions, staying current with USCDI versions is a continuous requirement.

8. FHIR API Requirements Under the Cures Act

The Cures Act mandates the use of HL7 FHIR (Fast Healthcare Interoperability Resources) as the standard for patient and provider access APIs. Here is what developers must implement:

Required FHIR Specifications

HL7 FHIR R4: The base FHIR standard version required for certification. All API endpoints must conform to FHIR R4 specifications.

US Core Implementation Guide: The US Core IG defines the minimum conformance requirements for FHIR servers in the US healthcare context. It specifies which FHIR resources must be supported, required search parameters, required data elements within each resource, and terminology bindings.

SMART on FHIR: The SMART App Launch Framework is required for application authorization. Certified APIs must support the SMART launch sequences (EHR launch and standalone launch) using OAuth 2.0.

Bulk Data Access: The FHIR Bulk Data Access specification is required for system-level data export. This allows authorized applications to export large datasets asynchronously using the FHIR $export operation.

Minimum Required FHIR Resources

Based on US Core and USCDI requirements, your FHIR API must support at minimum:

• Patient
• AllergyIntolerance
• CarePlan
• CareTeam
• Condition
• Coverage
• Device (implantable devices)
• DiagnosticReport
• DocumentReference
• Encounter
• Goal
• Immunization
• Location
• Medication
• MedicationRequest
• Observation (laboratory, vital signs, social history, SDOH)
• Organization
• Practitioner
• PractitionerRole
• Procedure
• Provenance
• QuestionnaireResponse (for assessments)
• ServiceRequest

API Performance Requirements

ONC does not specify exact performance benchmarks, but your API must be available and responsive enough that access is not effectively blocked by poor performance. Slow, unreliable, or frequently unavailable APIs can be considered information blocking under the technical interference category.

Best practices: maintain 99.9%+ API uptime, respond to single-resource queries within 2 seconds, support concurrent connections appropriate to your user base, and provide status endpoints for monitoring availability.

9. Patient Access and Provider Directory APIs

CMS issued its own interoperability rules complementing the Cures Act, requiring specific APIs for health plans and payers.

Patient Access API (CMS-9115-F)

Health plans participating in Medicare Advantage, Medicaid, CHIP, and federal exchange plans must implement a Patient Access API that allows members to access their claims and encounter data, clinical data, and plan coverage information through third-party applications.

Requirements:

• FHIR R4-based API
• Must include: claims/encounter data, clinical data (if maintained), plan coverage and formulary information
• Must be available to patients at no cost
• Must support third-party application access with patient consent

Provider Directory API

Health plans must implement a publicly accessible Provider Directory API that exposes provider network information in FHIR format. This includes provider names, specialties, locations, contact information, and network status.

Payer-to-Payer Data Exchange

Starting in 2026, health plans must support payer-to-payer data exchange, allowing a patient’s health data to follow them when they switch insurance plans. This requires FHIR-based APIs that can send and receive patient data between payers with patient consent.

Impact on Software Developers

If you are building software for health plans, payers, or organizations that work with payers, these CMS API requirements directly affect your development roadmap. Your systems must support FHIR R4, the CARIN Blue Button IG (for claims data), the DaVinci PDex IG (for payer data exchange), and the Plan-Net IG (for provider directories).

10. Penalties and Enforcement

Health IT Developer Penalties

Health IT developers of certified health IT face the most specific penalties under the Cures Act:

• Up to $1,000,000 per information blocking violation. This is a civil monetary penalty enforced by the HHS Office of Inspector General (OIG).
• Decertification. ONC can decertify health IT products that fail to meet certification requirements or engage in information blocking. Decertification effectively removes the product from the market for providers participating in CMS programs.
• Loss of certification conditions. Failure to meet ongoing conditions of certification (information blocking attestation, API availability, real world testing) can trigger enforcement actions.

Healthcare Provider Penalties

Providers who engage in information blocking face “appropriate disincentives” determined by HHS. As of 2026, specific provider penalties are still being defined through rulemaking, but expected disincentives include:

• Reduced Medicare reimbursement
• Exclusion from Medicare incentive programs
• Public reporting of information blocking practices
• Potential civil monetary penalties (pending final rulemaking)

Health Information Network Penalties

HINs and HIEs that engage in information blocking face civil monetary penalties similar to health IT developers, up to $1,000,000 per violation.

Enforcement Activity

The HHS OIG began accepting information blocking complaints in 2021 and has been investigating reported violations. While large public enforcement actions are still emerging, the investigation pipeline is active and growing. Organizations should not assume that the relatively low number of publicized enforcement actions means the rules are not being enforced.

11. What Healthcare Software Developers Must Do

Build FHIR-Native APIs

If you are developing healthcare software that stores or processes EHI, build FHIR R4 APIs from the start — not as an afterthought. Retrofitting FHIR onto a proprietary data model is significantly more expensive and error-prone than designing for FHIR from day one.

Your FHIR API must conform to the US Core Implementation Guide, support SMART on FHIR authorization, support Bulk Data Access for system-level export, and expose all USCDI data elements that your system maintains.

Support Patient Access

Patients have the right to access their data through third-party applications of their choosing. Your software must support this by implementing a patient-facing FHIR API, supporting patient-authorized third-party application access via OAuth 2.0, not imposing unnecessary barriers to patient data access, and providing data in a timely manner (not batched or delayed).

Eliminate Information Blocking Practices

Review your current software and business practices for anything that could constitute information blocking:

Technical practices: Proprietary data formats, non-standard APIs, unnecessarily slow data export, lack of bulk data support, APIs that are frequently unavailable.

Business practices: Contractual terms that restrict data portability, excessive fees for API access, licensing terms that discourage interoperability, exclusivity arrangements that prevent connections to competing systems.

Organizational practices: Internal policies that restrict data sharing beyond legal requirements, lack of processes for responding to data access requests, insufficient resources allocated to interoperability.

Document Everything

For every instance where you restrict access to EHI, document which exception applies, why the exception conditions are met, the scope and duration of the restriction, and the decision-making process. This documentation is your defense if OIG investigates an information blocking complaint.

Stay Current with Standards

The regulatory and technical landscape is evolving continuously. Monitor ONC rulemaking for changes to certification requirements, USCDI version updates, new implementation guides, and enforcement guidance. Allocate development resources specifically for regulatory compliance — this is not a one-time project.

If you are building telemedicine platforms or patient portal solutions, Cures Act compliance must be integrated into your development process from the beginning.

12. Common Compliance Mistakes Developers Make

Mistake 1: Treating FHIR as Optional

Some developers treat FHIR API implementation as a nice-to-have feature. Under the Cures Act, if your software is certified or connects to certified systems, FHIR support is a regulatory requirement. Delaying FHIR implementation creates compliance risk and potential information blocking liability.

Mistake 2: Implementing Incomplete FHIR Resources

Exposing a FHIR Patient resource with only name and date of birth does not meet US Core requirements. Each FHIR resource has minimum required data elements, required search parameters, and required terminology bindings defined by the US Core IG. Partial implementations can constitute information blocking if they prevent access to data that should be available.

Mistake 3: Ignoring Bulk Data Requirements

Many developers focus on single-patient API access and neglect the Bulk Data Access specification. Bulk Data is required for system-level data export and is essential for population health, analytics, and payer data exchange use cases. Without Bulk Data support, your certified health IT is non-compliant.

Mistake 4: Using FHIR Versions Other Than R4

The Cures Act specifically requires FHIR R4. Implementing FHIR DSTU2 or STU3 does not meet the regulatory requirement. If your system currently uses an older FHIR version, you must migrate to R4.

Mistake 5: Blocking Third-Party Application Access

Some developers restrict which third-party applications can connect to their APIs — approving “preferred partners” while blocking competitors. Unless the restriction meets one of the eight exceptions (most commonly the Security exception), this is information blocking.

Mistake 6: Not Conducting Real World Testing

Certified health IT developers must conduct annual real world testing and submit results to ONC. This is not optional. Failure to conduct and report real world testing is a violation of certification conditions.

Mistake 7: Overlooking the Expanded EHI Definition

Since October 2022, information blocking rules apply to ALL electronic health information, not just USCDI data elements. Developers who designed their APIs to expose only USCDI v1 data and nothing else may be non-compliant if their systems contain additional EHI that is not accessible through the API.

Mistake 8: Failing to Update Contracts and Licensing

Old contracts and licensing agreements may contain terms that constitute information blocking — data portability restrictions, excessive fees, non-compete clauses that limit interoperability. Review and update all customer-facing and partner-facing agreements for Cures Act compliance.

Next Steps

The 21st Century Cures Act is not a future requirement — it is actively enforced today. Healthcare software developers who build interoperability into their systems from the start will have a competitive advantage over those scrambling to retrofit compliance.

If your organization is developing healthcare software and needs guidance on Cures Act compliance, FHIR API implementation, or ONC certification requirements, connect with our interoperability team or explore our FHIR and HL7 integration services.

Related Resources:

• FHIR and HL7 Integration Services
• EHR Integration Solutions
• Telemedicine App Development
• Patient Portal Development
• Epic EHR Integration Guide
• HL7 vs FHIR: Complete Comparison

Taction Software is a US-based healthcare IT company specializing in healthcare interoperability, FHIR API development, and regulatory compliance for healthcare software. Get in touch to discuss your Cures Act compliance requirements.