In April 2021, the 21st Century Cures Act Final Rule went into effect, prohibiting healthcare entities from information blocking to break down barriers that have historically limited patient access to electronic personal health information (ePHI). To allow entities an opportunity to phase in their compliance, the initial rollout of the rule only covered a subset of electronic health information (EHI). However, as of October 6, 2022, entities will be responsible for complying with information blocking as it applies to the full scope of EHI.
Information blocking may be the most important change to health information since HIPAA. However, it’s important to point out that information blocking is not a HIPAA rule and applies to all healthcare providers—not just HIPAA-covered entities.
Information blocking relates to any practice that might interfere with access, exchange, or use of ePHI, including any designated record set, regardless if a covered entity maintains the group of records or if the records are maintained for a covered entity.
In short, with few exceptions, healthcare providers, tech vendors, health information exchanges, and health information networks (HIN) can’t prevent EHI access. The rule assumes that if HIPAA permits a patient or any other entity or individual to access records, they should be given access without delay, using almost any technology the requester chooses. Those requests do not have to be event-triggered.
For healthcare providers, it’s about knowing which practices are considered unreasonable and likely to interfere with, prevent, or materially discourage access, exchange, or use of EHI.
If an organization fails to provide access, without delay, to a person permitted access under HIPAA and other laws, that may be considered information blocking.
The ultimate goal is to improve healthcare data flow and facilitate improved and coordinated patient care with more patient engagement in healthcare decisions.
Who must be compliant?
Information blocking affects three types of entities:
-
Healthcare providers (regardless of HIPAA status).
-
Health information exchanges (HIE) and HIN. This is broadly defined and can include any entity that helps two or more providers exchange data. It also applies to a HIPAA business associate if the associate has an exchange role.
-
Health IT developers who offer Certified Electronic Health Record Technology.
If any of these organizations are also HIPAA-covered entities, there is an expectation that they must comply with HIPAA and the rules of the 21st Century Cures Act. Healthcare providers who aren’t HIPAA-covered entities must still comply with information blocking.
Exceptions to information blocking
There are two categories of exceptions applicable to information blocking: denial exceptions, and approval and process exceptions related to how requests are fulfilled.
There are eight specific exceptions, with complex implementation standards that allow providers to deny ePHI requests without being seen as information blocking. The following is an overview of those exceptions.
Denial exceptions
1. Preventing harm exception
The preventing harm exception recognizes that organizations may deny requests if doing so protects patients or others from harm. Therefore, it’s essential to document the potential risk and harm that triggered the exception.
In using this exemption, healthcare providers must demonstrate:
-
A reasonable belief that access denial would substantially reduce the risk of harm to a patient or another person that would otherwise occur if fulfilled.
-
Denial must be no broader than necessary to substantially reduce the risk of harm.
-
There are two ways to determine risk of harm. The first is on an individualized basis when a licensed healthcare professional (who has a current or prior clinician–patient relationship with the patient) is exercising professional judgment. The other way is from data known or reasonably suspected to be misidentified or mismatched, corrupt due to technical failure, or erroneous for another reason.[1]
2. Privacy exception
The privacy exception recognizes that an organization should not be required to use or disclose ePHI in a way that state or federal privacy laws prohibit. Information blocking does not render those laws obsolete.
“To satisfy this exception, [an organization’s] privacy-protective practice must meet at least one of the four sub-exceptions:
-
“Precondition not satisfied: If [an organization] is required by a state or federal law to satisfy a precondition (such as a patient consent or authorization) prior to providing access, exchange, or use of EHI, [it] may choose not to provide access, exchange, or use of such EHI if the precondition has not been satisfied under certain circumstances.
-
“Health IT developer of certified health IT not covered by HIPAA: If an [organization] is a health IT developer of certified health IT that is not required to comply with the HIPAA Privacy Rule, [it] may choose to interfere with the access, exchange, or use of EHI for a privacy-protective purpose if certain conditions are met.
-
“Denial of an individual’s request for their EHI consistent with 45 CFR 164.524(a) (1) and (2): An [organization] that is a covered entity or business associate may deny an individual’s request for access to his or her EHI in the circumstances provided under 45 CFR 164.524(a)(1) and (2) of the HIPAA Privacy Rule.
-
“Respecting an individual’s request not to share information: An [organization] may choose not to provide access, exchange, or use of an individual’s EHI if doing so fulfills the wishes of the individual, provided certain conditions are met.”[2]
This exception mirrors HIPAA Privacy Rule provisions about which ePHI patients can access.
It’s worth noting that it could be considered information blocking if an organization encourages patients to allow their providers access but infer the patient should be more selective in agreeing to access for others.
3. Security exception
The security exception covers all legitimate security practices by organizations but does not prescribe a maximum level of security or dictate a one-size-fits-all approach.
It is not considered information blocking if an organization interferes with access to protect ePHI security.
For instance, a practice believes data release would compromise data security. If a request threatens patient information, the security exception may be applicable. This should be consistent, nondiscriminatory, and tailored to specific security threats. It doesn’t cover practices that claim to promote security but are unreasonably broad and onerous. The security exception should not be a broad brush for request denials.
If an organization uses this exception, it must demonstrate that the denial is directly related to ePHI safeguarding based on specific security risks. That should include updated and relevant privacy and security policies. If those don’t exist, the organization should implement those to help mitigate practices that could prohibit or delay ePHI data sharing.
4. Infeasibility exception
The infeasibility exception notes that legitimate challenges could limit an organization’s ability to comply with a request. For example, the organization may not have—and may be unable to get—requisite technological capabilities, legal rights, or other means necessary to enable access, exchange, or use.
An organization may deny a request if it is considered infeasible. Before applying this exception, see if other exceptions may be more appropriate. The infeasibility exception should cover issues outside of an organization’s control.
The practice must meet one of the following conditions:
-
“Uncontrollable events: [The organization] cannot fulfill the request for access, exchange, or use of [EHI] due to a natural or human-made disaster, public health emergency, public safety incident, war, terrorist attack, civil insurrection, strike or other labor unrest, telecommunication or internet service interruption, or act of military, civil or regulatory authority.
-
“Segmentation: [The organization] cannot fulfill the request for access, exchange, or use of [EHI] because [it] cannot unambiguously segment the requested [EHI].
-
“Infeasibility under the circumstances: [The organization] demonstrates through a contemporaneous written record or other documentation its consistent and non-discriminatory consideration of certain factors that led to its determination that complying with the request would be infeasible under the circumstances.”[3]
If using this exception, the organization should provide a written response to the requester within 10 business days of getting the request, including why the request is infeasible.
5. Health IT performance exception
The health IT performance exception recognizes that it requires maintenance and sometimes improvements for health IT to perform properly and efficiently. This may require some health IT systems to go offline temporarily and can be for scheduled or unscheduled reasons.
The practice must:
-
“Be implemented for a period of time no longer than necessary to achieve the maintenance or improvements for which the health IT was made unavailable or the health IT’s performance degraded;
-
“Be implemented in a consistent and non-discriminatory manner; and
-
“Meet certain requirements if the unavailability or degradation is initiated by a health IT developer of certified health IT, HIE, or HIN.”[4]
An organization may act against a third-party app that is negatively impacting the health IT’s performance, provided that the practice is:
-
“For a period of time no longer than necessary to resolve any negative impacts;
-
“Implemented in a consistent and non-discriminatory manner; and
-
“Consistent with existing service level agreements, where applicable.
“If the unavailability is in response to a risk of harm or security risk, [the organization] must only comply with the Preventing Harm or Security Exception, as applicable.”[5]
The IT performance exception is for those issues that temporarily prohibit access and should be used consistently and in a nondiscriminatory manner.
Approval and process exception examples
In addition to denial exceptions for the information blocking, there are also a few approval and process exception examples. These exceptions are related to how organizations fulfill access requests.
These exceptions may trigger actions that hinder requests rather than outright denying them.
6. Content and manner exception
The content and manner exception provides clarity and flexibility to organizations about the required content of an organization’s response to a request for access and how the organization may fulfill the request. The organization must fulfill a request in any manner requested unless technically unable or if they cannot reach agreeable terms with the requester to satisfy the request.
Content condition considers the scope of the data involved in information blocking. If the request is outside the scope, it would not be information blocking if the organization doesn’t provide the data. Manner condition considers how the organization must fulfill an access request to satisfy the exception. Here, suppose the organization can’t technically meet the request in the manner requested or can’t reach agreeable terms with the requester. In that case, it may be necessary to fulfill the request in an alternative manner.
7. Fees exception
The fees exception enables organizations to charge fees related to technology development and service provisions that enhance interoperability. For instance, if the request comes from an attorney or life insurance agency and the organization currently charges a records request fee, that could likely continue. However, there are several requirements for fee basis, including anticompetitive, consistency, nondiscriminatory, and others, so organizations should review their current fee practices against these requirements to ensure the fees are allowable under the exception.
With the fees exception, it’s important to note:
-
You should not charge for records if HIPAA does not allow it.
-
You should observe HIPAA limits.
-
You should not change the policy to charge for records if it doesn’t exist now.
-
You should examine fee charges to determine if the process should continue.
Also, consider the “Proposed Modifications to the HIPAA Privacy Rule to Support, and Remove Barriers to, Coordinated Care and Individual Engagement, Notice of Proposed Rulemaking,” from January 21, 2021, that provides a summary of how different types of access and recipients of the PHI would affect the proposed allowable access fees.[6]
8. Licensing exception
Finally, the licensing exception allows organizations to protect the value of their innovations and charge reasonable royalties to earn returns on the investments they made to develop, maintain, and update those innovations. This often refers to electronic health records (EHRs).
The licensing exception allows vendors to continue to license technology without it being considered information blocking. Health IT developers that require licensing and licensing fees for interoperability components should understand that this exception could protect them if customers can’t access information because they failed to license the necessary functionality.
The licensing exception protects intellectual property rights based on particular timing and licensing conditions.
Ensuring prompt access, exchange, and use
Beyond understanding what information blocking is and which exceptions exist, it’s also important to consider implementation.
Compliant organizations should have well-defined processes to evaluate and review requests, maintain documentation for compliance purposes and determine how denials are consistently tailored to one or more exceptions.
A playbook is an excellent foundation for implementation because it can help manage the convergence of people, processes, and technology to ensure reasonable and appropriate procedures and processes for compliance success.
People: Know who is asking for and responding to records requests and how.
-
Identify organizational stakeholders related to information blocking.
-
Start an information-blocking compliance workgroup. The workgroup should designate an organizational leader and consist of a multidisciplinary team of stakeholders such as legal, clinical, IT, and others to identify, assess, implement, and advocate for corporate compliance.
-
Determine how to categorize and organize sharing and exchange. For example, does this require a technical solution or human intervention to process every request? Who within the organization is responsible for responding to requests?
-
Discover and assess vendors that exchange, use, or access ePHI on the organization’s behalf, request confirmation of the vendor’s compliance program, and confirm that the vendor does not engage in information blocking.
-
Identify requester types. Not all requesters are treated the same under the rules, and most organizations categorize request types and requesters. Requesters may be individuals (adults or minors), personal/legal representatives, or other providers.
Processes: Assess current access processes to determine gaps or compliance issues.
-
Evaluate HIPAA policies and procedures to determine if they’re up to date and functioning.
-
Review, update, or create organizational policies, procedures, and processes for compliance.
-
Revise policies that knowingly delay disclosure.
-
Identify which new policies to create to document exceptions.
-
Monitor privacy practices and look for improvement opportunities.
-
Determine whether current access, exchange, or use rules and processes are “enough” to avoid the implication of information blocking.
-
Decide when refusals are currently permitted and if those instances are still valid under the information blocking framework.
-
Conduct a legal review of contracts, business associate agreements, data use agreements, or licenses.
-
Understand that business associates who assist with record release or transfer may need additional instruction.
-
Review and amend, as necessary, contracts and agreements that impose restrictions on the other party’s access, exchange, or use of ePHI for compliance with the regulatory exceptions.
-
Determine incident management processes and procedures. For example, how to handle a request when it can’t be immediately provided.
-
Implement a complaint process for reporting information-blocking complaints.
-
Monitor, investigate, and enforce compliance through risk assessments and investigations.
-
Train workforce members on information-blocking compliance.
-
Remediate any issues, including implementing Consumer Assistance Programs and disciplinary actions for those who violate the policies.
-
Consider combining information-blocking training with HIPAA compliance training.
Technology: Understand the technology required to respond to records requests.
-
Determine the organization’s capability to readily accommodate various electronic access methods.
-
Assess all points of access and exchange, including technology and application programming interfaces (APIs) in use.
-
Conduct a risk analysis of the new system or application implementations.
-
Determine whether an exchange with a particular application creates too much risk.
-
Remediate technical vulnerabilities, test APIs and infrastructure, and monitor the environment.
-
Discuss upgrades or settings with EHR vendors.
-
Understand patient portal capabilities.
-
Understand which APIs vendors supply.
-
Review protocols and data streams to ensure no unintentional blocking occurs.
-
Identify other electronic data transfer mechanisms.
Information blocking and exceptions policy
Organizations must draft an information blocking and exceptions policy to ensure compliance with information blocking regulations. Because of the overlap with HIPAA issues, it may be helpful to consider including this new policy as an addendum to current HIPAA policies and procedures.
These policies should establish well-defined processes that demonstrate the organization’s ability to:
-
Evaluate and review requests.
-
Maintain documentation for compliance purposes.
-
Determine how denials are consistently tailored to one or more of the information blocking exceptions.
Also consider:
-
Putting exceptions into written policies.
-
Paying attention to extensive criteria for each exception.
-
Crosswalking with HIPAA policies.
-
Conducting an internal analysis may require multidisciplinary input (clinical, legal/compliance, health information management, information systems, information security, etc.).
-
Understanding that exceptions require application in a nondiscriminatory manner for like-requesters to stop providers from favoring their own systems or blocking out competitors.
-
Drilling down to assess operations, policies, and practices. There is not a one-size-fits-all situation.
Takeaways
-
With few exceptions, healthcare providers, tech vendors, health information exchanges, and health information networks can’t prevent electronic personal health information (ePHI) access.
-
Information blocking assumes that if HIPAA permits a patient or any other entity or individual to access records, they should be given access without delay, using almost any technology the requester chooses. Those requests do not have to be event-triggered.
-
HIPAA-covered entities are expected to comply with HIPAA and the rules of the 21st Century Cures Act.
-
There are eight specific exceptions to the rule, with complex implementation standards allowing providers to deny ePHI requests without being considered information blocking.
-
Organizations should have well-defined processes to evaluate and review requests, maintain documentation for compliance purposes, and determine how denials are consistently tailored to one or more exceptions.
