Information Blocking Under the Cures Act: What Health IT Developers Must Do
Healthcare software needs to make electronic health information easier to access, exchange, and use. But some technical or business practices can make sharing this information unnecessarily difficult.
The 21st Century Cures Act addresses this problem through its information blocking provisions. These rules affect certain healthcare providers, health IT developers, and health information networks.
For developers building healthcare applications, EHR integrations, and data exchange systems, understanding these requirements is important.
What Is Information Blocking?
Information blocking means a practice that is likely to interfere with the access, exchange, or use of electronic health information (EHI), except when the practice is required by law or covered by an applicable exception.
Interference can include preventing access, creating unnecessary barriers, or making it materially harder for another party to use or exchange health information.
For example, a system may create problems if it:
- Unreasonably delays access to requested patient information.
- Blocks data exchange without an appropriate reason.
- Uses technical restrictions that unnecessarily prevent approved access.
- Makes it difficult for patients to share their health information with other applications.
Not every delay or technical limitation is information blocking. The circumstances, the type of actor, the applicable knowledge standard, and other parts of the rule matter.
Who Must Follow the Information Blocking Rules?
The regulations identify three main categories of actors:
| Actor | What It Means |
|---|---|
| Healthcare providers | Individuals and organizations that meet the regulatory definition of a healthcare provider. |
| Health IT developers of certified health IT | Developers or vendors that develop or offer at least one health IT module certified under the ONC Health IT Certification Program. |
| HIEs and HINs | Health information exchanges and networks that meet the regulatory definitions. |
A general software company is not automatically a health IT developer of certified health IT just because it builds healthcare software. The definition depends on whether it develops or offers certified health IT. However, an organization may fall under another actor category depending on its activities.
The knowledge standard also differs. For health IT developers of certified health IT and HIEs or HINs, the rule considers whether they know, or should know, that a practice is likely to interfere with access, exchange, or use of EHI. Healthcare providers have a different knowledge standard.
The 10 Information Blocking Exceptions
The regulations include 10 exceptions. They describe situations in which certain practices will not be considered information blocking when all applicable conditions are met.
The exceptions are voluntary. A practice that does not meet an exception is not automatically information blocking. It must be assessed under the full regulatory definition.
Exceptions for Not Fulfilling a Request
| Exception | Simple Explanation |
|---|---|
| Preventing Harm | Allows certain practices intended to prevent harm to a patient or another person, when the required conditions are met. |
| Privacy | Covers certain practices that protect individual privacy and comply with the exception's conditions. |
| Security | Covers reasonable and necessary steps to protect electronic health information from security risks. |
| Infeasibility | Applies when fulfilling a request is not feasible under the circumstances described in the rule. |
| Health IT Performance | Allows certain practices needed to maintain or improve health IT performance, subject to specific conditions. |
| Protecting Care Access | Covers certain practices involving reproductive healthcare information in the circumstances described by the rule. |
Exceptions for How Requests Are Fulfilled
| Exception | Simple Explanation |
|---|---|
| Manner | Allows an actor to fulfill a request in a particular manner or, when the required conditions apply, an alternative manner. |
| Fees | Allows certain fees for accessing, exchanging, or using EHI when the regulatory requirements are met. |
| Licensing | Covers certain licensing of interoperability elements needed to access, exchange, or use EHI. |
Exception Related to TEFCA
| Exception | Simple Explanation |
|---|---|
| TEFCA Manner | Allows certain requests to be fulfilled through TEFCA when the actor, requestor, and exchange arrangements meet the specified conditions. |
These exceptions are not general permission to withhold information, charge any amount, or restrict data sharing. Each has its own requirements under 45 CFR Part 171.
What Should Health IT Developers Do?
Developers should consider information sharing throughout the software development process. A system may work as designed but still create unnecessary barriers to accessing or exchanging health information.
Here are practical areas to review.
1. Review API Access
APIs allow applications to exchange information with other systems. Developers should review whether access restrictions, authentication requirements, or technical limitations create unnecessary barriers.
Access controls are important, but they should have a clear technical or operational purpose.
2. Avoid Unnecessary Data Restrictions
Applications should support appropriate access to requested health information. Developers should review whether data is being unnecessarily hidden, delayed, or excluded.
For example, an integration should not restrict information simply because the receiving application was developed by another vendor.
3. Document Technical Limitations
Sometimes a system cannot provide information in the requested format or through the requested method.
Developers should document the technical issue, the affected data, the steps taken to address it, and any alternative method discussed with the requestor.
Clear records can help explain why a particular technical decision was made.
4. Review Fees and Licensing Terms
Fees and licensing arrangements can affect data exchange. Developers should review whether their pricing, contracts, or licensing conditions meet the relevant requirements.
A commercial agreement should not be used to create unnecessary barriers to accessing or exchanging EHI.
5. Test Data Exchange Workflows
Testing should cover more than whether an API returns a successful response.
Development teams should also check:
- Whether authorized requests receive the expected information.
- Whether access restrictions have a clear purpose.
- Whether errors and delays are recorded.
- Whether alternative exchange methods work when needed.
- Whether changes to APIs affect existing integrations.
How FHIR and USCDI Fit Into Information Sharing
FHIR and USCDI are important parts of modern healthcare interoperability, but they serve different purposes.
FHIR, or Fast Healthcare Interoperability Resources, is a standard for exchanging healthcare information. Developers use FHIR APIs to connect applications and healthcare systems through structured data resources.
USCDI, or United States Core Data for Interoperability, defines a standardized set of health data classes and elements for nationwide exchange.
Both can support more consistent data exchange. They can also help development teams plan API structures and integration workflows.
However, using FHIR or supporting USCDI does not automatically establish compliance with the information blocking regulations. Developers must also consider the applicable requirements and the way their systems handle requests for EHI.
For more background, see our guides on What Is USCDI?, Why FHIR Interoperability Is a Business Requirement, and Patient Data Interoperability.
A Practical Checklist for Developers
Before releasing or updating a healthcare integration, teams can review these questions:
| Area | What to Check |
|---|---|
| API access | Can authorized applications access the information they are permitted to receive? |
| Data exchange | Are there unnecessary restrictions on sharing EHI? |
| Authentication | Are access controls appropriate for the system and its users? |
| Error handling | Are failed requests and technical issues recorded? |
| Data formats | Can the system support appropriate exchange formats and standards? |
| Fees and licensing | Have pricing and licensing practices been reviewed against applicable requirements? |
| Documentation | Are technical decisions and limitations clearly recorded? |
| Testing | Have common data access and exchange workflows been tested? |
This checklist is a practical development aid, not a substitute for assessing the specific requirements that apply to an organization.
Frequently Asked Questions
What is the main purpose of the 21st Century Cures Act information blocking rule?
The rule aims to prevent practices that unnecessarily interfere with the access, exchange, or use of electronic health information. It supports better information sharing across healthcare systems.
Does the information blocking rule apply to every healthcare software company?
No. The rule identifies specific categories of actors, including healthcare providers, health IT developers of certified health IT, and HIEs or HINs. A software company must be assessed against the regulatory definitions to determine whether it falls into one of these categories.
Does using FHIR guarantee compliance?
No. FHIR supports standardized data exchange, but using it does not automatically satisfy information blocking requirements. The way a system handles access and exchange requests also matters.
What happens if a developer commits information blocking?
The consequences depend on the type of actor. Health IT developers of certified health IT and HIEs or HINs may face civil monetary penalties of up to $1 million per violation if HHS OIG determines that they committed information blocking. Healthcare providers are subject to a separate disincentive framework.
Are the information blocking exceptions mandatory?
No. The exceptions are voluntary. They describe practices that will not be considered information blocking when their specific conditions are met. A practice that does not meet an exception is not automatically a violation.
Conclusion
Information blocking is an important consideration for healthcare technology teams. Developers should understand how their applications handle requests for electronic health information and avoid unnecessary restrictions on data access and exchange.
Clear API behavior, appropriate access controls, documented technical limitations, and well-tested integration workflows can help teams build systems that support interoperability.
The goal is not simply to connect two healthcare systems. It is to make appropriate health information available for authorized access and use.
Disclaimer: This article is for general informational purposes only. It is not legal advice.
Official Sources
