Editor’s Note: Earlier this year, the federal Office of the National Coordinator for Health Information Technology (ONC) and the Department of Health and Human Services (HHS) issued proposed rules implementing the information blocking prohibition in the 21st Century Cures Act. “Information blocking” refers to activities that unreasonably limit the availability and use of electronic health information (EHI), undermining public and private investments in the nation’s health IT infrastructure and frustrating efforts to use technology to improve healthcare quality and efficiency.
The proposed rule—designed to create a more interoperable healthcare system that supports seamless data exchange and improved care coordination—is likely to be adopted in final form in late 2019 or early 2020. (Since the webinar, the rule has moved a step closer to being finalized and is now under review by the Office of Management and Budget, the last step before publication.) Once the rule goes into effect, it will impose significant compliance obligations on healthcare stakeholders, including providers, electronic health record vendors and health information exchanges. Noncompliance could trigger serious consequences. For example, health information exchanges and networks are subject to penalties of up to $1 million for lack of interoperability.
In a recent webinar, Manatt Health explained what the new rule will mean for healthcare organizations—and how healthcare stakeholders can be sure they are prepared and compliant when the new rule is implemented. In part 1 of our article summarizing the webinar, below, we provide a background and overview of the new rule, as well as review the exceptions to the definition of information blocking. Watch for part 2 of our summary in December, sharing guidance on how to comply. Click here to view the full webinar free on demand (and earn CLE)—and here to download a free copy of the presentation.
Background of the Proposed Rule
The proposed rule was issued on March 4, 2019, by the Federal Office of the National Coordinator for Health Information Technology (ONC). Among other things, it implements the information blocking provision of the 21st Century Cures Act, which was enacted in December 2016.
The 21st Century Cures Act was designed to help accelerate medical product development and innovations in patient care. It was enacted in response to concerns that some individuals and entities were engaging in practices that unreasonably limited the availability and use of electronic health information. The information blocking rule focuses on eliminating barriers to data sharing within the healthcare system. It defines the practices that constitute information blocking by a healthcare provider, health IT developer, health information exchange or health information network. It also authorizes the Department of Health and Human Services (HHS) to identify reasonable and necessary activities that do not constitute information blocking.
The proposed rule has not been finalized so is still subject to change. Healthcare stakeholders, however, will benefit from starting to plan now for how they will address the information blocking requirements once they are implemented.
Overview of the Proposed Rule
The proposed rule applies to four categories of individuals and entities—healthcare providers, health IT developers, health information networks (HINs) and health information exchanges (HIEs). It covers electronic health information (EHI), which is electronic protected health information, as defined under the Health Information Portability and Accountability Act (HIPAA), as well as any other information that:
- Is transmitted by or maintained in electronic media;
- Identifies the individual with respect to which there is a reasonable basis to believe the information could be used to identify the individual; and
- Relates to the past, present or future health or condition of an individual; the provision of healthcare to an individual; or the past, present or future payment for the provision of healthcare to an individual.
As with HIPAA, EHI does not include information that has been de-identified.
The standards for complying with the proposed rule are somewhat more lenient for healthcare providers than for healthcare IT developers, HIEs and HINs. For healthcare providers, the proposed rule applies to any practice that a provider knows is unreasonable and is likely to interfere with, prevent or materially discourage the access, exchange or use of EHI. For technology developers, HIEs and HINs, the proposed rule applies to any practice the developer, exchange or network knows, or should know, is likely to interfere with, prevent or materially discourage access, exchange or use of EHI.
What exactly does the rule mean by access, exchange or use? Access means the ability to make EHI available for use, including the ability to retrieve it from the source systems in which it is maintained. Exchange means the ability for EHI to be securely and efficiently transmitted among different technologies, systems, platforms and networks in a manner that allows it to be accessed and used. Finally, use means the ability to access relevant EHI; comprehend its structure, content and meaning; and read, write, modify or manipulate it to achieve a desired outcome.
Five Categories of Prohibited Activities
The proposed rule includes five categories of prohibited activities.
1. Restrictions on access, exchange or use limiting or restricting the interoperability of health IT
Restrictions in this category can be formal or informal. Examples of formal restrictions include:
- Health system policies that require staff to get consent before sharing patient information with unaffiliated providers, even though consent isn’t required by law;
- Electronic health record (EHR) developers with software licenses that prohibit customers from disclosing technical interoperability information without which the customers and their IT contractors cannot efficiently export and convert EHI for use in other applications; and
- HINs that prohibit participating entities from transmitting the EHI they receive through the network to entities that are not participants.
An example of an informal restriction would be a health system that claims incorrectly that HIPAA or other legal requirements prevent it from exchanging EHI with unaffiliated providers.
2. Limiting or restricting the interoperability of health IT
Examples include:
- A hospital that directs an EHR developer to configure its technology so users cannot easily send electronic patient referrals and associated EHI to unaffiliated providers;
- An EHR developer that imposes exorbitant fees or takes other steps to prevent a third-party clinical decision support app from writing data to the developer’s software, because the developer offers software that competes with the third-party app; and
- A provider that has the ability to provide same-day access to a patient’s EHI in the format requested by the patient’s providers but takes several days to respond.
3. Impeding innovations and advancements in access, exchange or use of health IT-enabled care delivery
Examples include:
- An EHR developer that requires third-party applications to be vetted for security before use but does not promptly conduct the vetting or conducts it in a discriminatory way; and
- A health system with an EHR platform that provides limited connectivity with competing hospitals and facilities, but insists that physicians use its systems and threatens to revoke privileges for those who don’t comply.
4. Nonstandard implementation practices
An example of this prohibited category would be if there is a commonly accepted technical standard to achieve an objective, but a provider, EHR developer, HIN or HIE doesn’t implement that standard, fails to update it, or implements it in a way that deviates from formal specifications.
5. Rent-seeking and other opportunistic pricing practices
Examples include:
- An EHR developer that charges more than its actual costs to provide interfaces, connections, data conversions or other services that are necessary for interoperability; and
- An EHR developer that charges more to export or use EHI in certain situations and for certain purposes that compete with the EHR developer’s own products or services.
The Carve-Out: No Violation if Required by Law
There is an important carve-out in the information blocking rule stating that the rule does not apply to conduct required by state or federal law. An example would be if a patient requests that a provider not disclose his or her protected health information to a health plan regarding services that have been paid for by the patient out of pocket. Under HIPAA, the provider is required to withhold that information. Therefore, the information blocking rule is not implicated. The carve-out ensures that entities and individuals don’t need to choose which law to comply with when determining their actions.
The Seven Exceptions to the Information Blocking Rule
There are seven exceptions to the information blocking rule. Many rely on concepts such as reasonableness that require individuals to make judgment calls rather than applying “bright line” standards. The benefit of having no bright line is that the rule allows flexibility in looking at specific circumstances. The flip side, however, is that it leaves room for second-guessing decisions. The seven exceptions to the rule are:
1. Preventing harm
The first exception is that there is a reasonable belief the practice will directly and substantially reduce the likelihood of harm. There are three categories of harm defined in the rule—corrupt or inaccurate data being incorporated into the patient’s record, misidentification of the patient, and the likelihood that disclosing the information would endanger the life or physical safety of the patient or another person. The determination on what is necessary to prevent harm can be made in two ways—(1) through a written organizational policy that is based on relevant experience, implemented in a consistent and nondiscriminatory manner, and no broader than necessary; or (2) on a case-by-case basis, again based on relevant experience and no broader than required.
2. Promoting the privacy of EHI
The second exception is that information can be withheld to promote the privacy of EHI. This exception is applicable when there is no legal prohibition on disclosing the information, as discussed in the required by law carve-out. For this exception, the actor must satisfy a precondition, such as getting the consent or authorization of the individual to transmit the information or verifying the identity of the individual or entity requesting the information. If the precondition relies on consent, the actor must do everything within its control to give the individual the opportunity to consent. The preamble to the rule clarifies that the actor does not have to exhaust every possibility of obtaining consent. On the other hand, the actor has an obligation to contact the patient and provide a consent form. As in the first exception, any decision to withhold data has to be tailored to a specified privacy risk and implemented in a consistent, nondiscriminatory manner. Also similar to the first exception, decisions can be made pursuant to a written policy or on a case-by-case basis.
3. Promoting the security of EHI
The third exception allows information to be withheld to promote the security of EHI. The standard is that the practice has to be directly related to safeguarding the confidentiality, integrity and availability of EHI; tailored to a specified security risk; and, again, implemented in a consistent and nondiscriminatory manner. One obvious application would be if there were a temporary vulnerability in a system creating insecurity. Once the vulnerability was eliminated, however, the exception would no longer apply.
As with the first two exceptions, there are two approaches to making a decision about whether the standard is satisfied. The first is a written organizational policy that ensures the decision directly responds to the identified security risks, aligns with consensus or best practice standards, and provides objective time frames and other parameters. The second is for decisions to be made on a case-by-case basis, when findings show the practice is necessary to mitigate risk and there are no reasonable, less restrictive safeguards.
4. Recovering costs reasonably incurred
The first three exceptions justify withholding the information entirely. The fourth exception conditions the provision of the information on some type of compensation from the party requesting access. Under this exception, it is permissible to recover costs that are reasonably incurred by the actor that is disclosing the information. Those costs have to be based on objective, verifiable criteria. They also must be reasonably allocated across all customers. Charges cannot be based on whether the requestor is a competitor or on the sales, profit or revenue derived by the requestor. It is permissible to mark up the charges to make a profit. The key is that the charges must be related to the costs that the party making the information available is incurring. They should not be based on a strategic evaluation of how important the information is to the requestor, how much money the requestor has or other business relationships between the actor and the requestor.
Clearly, judgment calls are critical in implementing this exception. To help narrow the range of costs an actor can charge for, there are costs explicitly excluded, including costs due to nonstandard IT design; costs associated with intangibles, such as depreciation; fees prohibited by HIPAA access rules; fees based on electronic access by an individual; certain fees related to exporting EHI; and fees for exporting or converting data from EHR to another system, unless those fees were agreed upon in the service agreement executed when the provider first acquired the EHR. The fees cannot be imposed at a later date after the provider is already locked into the system.
5. Responding to requests that are infeasible
The fifth exception deals with responding to requests that are infeasible. The standard for this exception is that the request for information imposes a substantial burden on the actor. Since what constitutes a substantial burden can be the subject of dispute, the rule provides examples of factors that must be taken into account, including the type of EHI and purpose of the request, the cost of compliance, the actor’s resources, whether the actor provides comparable access to itself or its partners, whether the actor controls the predominant platform, whether the information is maintained on behalf of the person whose access will be enabled, whether the requestor has other means of access, and the cost of alternative means of access. Acceptable burdens do not include facilitating competition or preventing the collection of a fee.
6. Licensing interoperability elements on reasonable, nondiscriminatory terms
The sixth exception focuses on licensing interoperability elements on reasonable nondiscriminatory terms. In contrast to the reasonable cost exception, this exception is not about the actor incurring costs specifically in connection with an information request. Instead it deals with situations where an actor has developed some sort of technology for transmitting the information—and it is deemed reasonable for the actor to receive a return on its development investment through a licensing fee. The rule requires the actor to respond to the request and offer the license within 10 business days. A response would include advising the requestor on the type of license needed and making a proposal for the agreement. There is no requirement on how long negotiations to finalize the arrangement can last after the proposal is delivered.
Actors are prohibited from impeding the efficient use of any element for any authorized purpose; impeding the efficient development, deployment or use of a product or service for which there is a demand; and making changes that interfere with interoperability. The license must convey a wide range of rights, including the right to develop interoperable products; market, offer and distribute products; and enable the use of products in production environments. The actor can charge a reasonable royalty, based on objective and verifiable criteria (not competitive considerations) that are uniformly applied. Ancillary restrictions, such as non-competes or obligations to buy other products, are prohibited.
7. Maintaining and improving health IT performance
The final exception focuses on maintaining and improving health IT performance. This exception is designed to allow for downtime to conduct system maintenance. It ensures that any delays for maintenance are not considered information blocking. The downtime must be no longer than necessary to maintain or improve the technology; implemented consistently and in a nondiscriminatory manner; and, if it’s initiated by the IT developer, HIE, or HIN, agreed to by the customer.
Key Takeaway
The key takeaway from understanding the exceptions is that it is critical for all actors to go through the process of considering different options for applying the exceptions, making determinations of what’s reasonable and documenting the decision process. The more an actor documents its process and the facts supporting that its decisions are reasonable, the better position it will be in to withstand any challenges.
Note: Watch for part 2 of our summary in December, sharing guidance on how to comply with the information blocking rule. Click here to view the full webinar free on demand (and earn CLE)—and here to download a free copy of the presentation.