Starting April 5th, 2021, the ONC’s Cures Act Final Rule prohibits most types of information blocking involving electronic health information (EHI). This regulation’s primary goal is to improve patient access to their healthcare information through greater interoperability. Understanding what information blocking is and how you may be doing it unintentionally in your organization is the key to becoming compliant.
Why Was the Cures Act Final Rule Created?
Modern technology has improved many aspects of healthcare, and it should be easy for patients to have access to their EHI in the way that’s most convenient to them. This regulation opens up the doors for easily getting this information through an application of the patient’s choosing. Creating custom integrations to accommodate all types of software is unfeasible for healthcare organizations, so this rule also provides an approach to implementing interoperability through a cost-effective, automated option: certified standardized Application Programming Interfaces (API).
Information Blocking Basics
For these APIs to function as intended, they must be able to access EHI without information blocking. At its core, information blocking involves interference in the use, access, or exchange of EHI, and it should be avoided outside of a few exceptions. Given the broad nature of this regulation, it’s entirely possible that your policies, procedures, contracts, and systems could easily lead to accidental information blocking.
The people and entities who must follow this regulation include:
- Healthcare providers
- Health information networks
- Health information exchanges
- Health IT developer of certified health IT
Data Included in the Information Blocking Rule
The EHI that must be available is limited between April 5th, 2021, and October 6th, 2022. This period only requires covered entities to adhere to the United States Core Data for Interoperability data classes:
- Unique device identifiers, if the patient has implantable medical devices
- Health concerns and problems
- Members of the patient’s care team
- Clinical notes
- Vital sign readings
- Whether the patient is a smoker
- Immunization records
- Medical procedures
- Medications taken
- Patient assessments
- Medical treatment plan
- Medical goals
- Lab results
- Record metadata
After this period, the scope broadens significantly, as everything defined under HIPAA’s designated record set will then fall under it. This data includes the records used to make decisions about the patient’s medical care and their health plan enrollments, claims, payments, and billing information.
Information Blocking Penalties
Covered entities except for healthcare providers could get a fine of up to $1 million for each violation of the information blocking rule. As of this writing, healthcare providers do not have specifically defined penalties, but they could face disincentives as well.
Examples of Information Blocking
Information blocking comes in many forms, so it’s essential to account for all the possible ways that you could be falling out of regulatory compliance. When you’re evaluating your healthcare systems, you’ll want to watch out for the following issues that could prevent EHI interoperability:
- Policies and practices that restrict the covered EHI from being used for permitted purposes. For example, you may have cybersecurity rules in place that stop certified third-party APIs from pulling data into their applications.
- Nonstandard health IT implementations. When you selected and deployed your current infrastructure, you may have built around highly specialized requirements or needed to work with a limited budget. Your systems may end up much more complex to work with. In this situation, the roadblocks in the way to the EHI may be considered information blocking, as it presents an undue burden to access.
- Another implementation challenge involves restrictions surrounding full EHI exports for a patient. For example, they may want to export all their health records into a new application. If they can’t do that with your system, then you may be out of compliance.
- Many practices often restrict most lab and diagnostic results from going to a patient portal before being physician-reviewed and signed-off on. This is considered by many to no longer be appropriate under the information blocking rule.
- Information blocking can also involve more abstract practices that involve fraud, abuse, and waste. It also covers anything that impedes the implementation of new and modernized health IT.
What Situations are Exceptions to Information Blocking Rules
Avoiding information blocking does not mean that you need to open up EHI data sets without restriction. The Cures Act also defines several exceptions that it calls “reasonable and necessary activities.”
These activities fall under two classes and have eight categories in total. The exception classes are “not fulfilling requests” and “procedures for fulfilling requests.”
Some examples of not fulfilling EHI requests include:
- Needing to deny a request to prevent harm from occurring to a person.
- Protecting the security of the patient’s EHI.
- Failing to fulfill a request to keep the patient’s privacy safe.
- Denying requests that are infeasible for the actor to fulfill.
- Maintaining the overall performance of health IT systems through temporary unavailability, such as planned maintenance windows.
Some examples of EHI request procedures that are not considered information blocking include:
- Limiting the content included in the response or the method used for fulfillment.
- Charging fees for EHI requests.
- Licensing interoperability elements that the organization developed to fulfill requests.
Bringing Your Organization into Information Blocking Compliance
Your organization’s health IT is a complex mix of systems that all have information blocking potential, especially when it comes to your EHR. Partnering with experienced health information technology consulting partners helps you achieve your information blocking compliance goals. Schedule a consultation with TempDev to learn how we can help by calling 888.TEMP.DEV or clicking here.