Download as PDF

INFORMATION BLOCKING FOR ACOs 

The Department of Health and Human Services (HHS) finalized information blocking disincentives, or penalties, that will be imposed on health care providers effective July 31, 2024. Complaints of information blocking are referred to and investigated by the HHS Office of Inspector General (OIG). For investigations of health care providers, OIG expects to focus on information blocking practices that:

  • Resulted in, are causing, or have the potential to cause patient harm;
  • Significantly impacted a provider’s ability to care for patients;
  • Were of long duration; and
  • Caused financial loss to federal health care programs, or other government or private entities.

Disincentives
Medicare Shared Savings Program ACOs
CMS will screen ACOs, ACO participants, and ACO providers/suppliers for an OIG determination of information blocking and deny the addition of such a health care provider as a Medicare Shared Savings Program (MSSP) participant for a period of at least one year. In the case of an ACO applicant that is a health care provider, CMS may deny the ACO’s application to participate in the MSSP for the upcoming performance year. For ACOs that are already participating in the MSSP, CMS may terminate the ACO’s participation agreement. NAACOS advocated against this punitive approach, and in the final rule CMS notes the agency will use enforcement discretion with ACOs. CMS will consider an OIG information blocking determination considering the relevant facts and circumstances such as the nature of the health care provider’s information blocking, the health care provider’s diligence in identifying and correcting the problem, the time since the information blocking occurred, whether the provider was previously subject to a disincentive in another program, and other factors before applying a disincentive.

Hospitals
An eligible hospital or critical access hospital (CAH) that commits information blocking will not meet meaningful use requirements during the calendar year of the electronic health record (EHR) reporting period in which OIG refers its determination to CMS. The impact on an eligible hospital will be the loss of 75 percent of the annual market basket increase; for a CAH, payment will be reduced to 100 percent of reasonable costs instead of 101 percent.

Clinicians
A Merit-based Incentive Payment System (MIPS) eligible clinician or group practice that commits information blocking will not be a meaningful EHR user during the calendar year of the performance period in which OIG refers its determination to CMS. The impact on a MIPS eligible clinician or group that is required to report on the MIPS Promoting Interoperability performance category will be to earn a zero score for that category, which is typically a quarter of the total final score.

What Is Information Blocking
For the past several years, HHS has been encouraging and requiring the sharing of electronic health information between and among health care providers, health plans, and patients. Several regulations set forth the data and standards that must be used to share that information, and many of these requirements are included in the certification standards for electronic health IT products. To assist the industry in implementing and using information sharing, and to promote interoperability of the information, HHS has also issued requirements that prohibit “information blocking” – that is actions taken by vendors, health information networks, and providers that are “likely to interfere with access, exchange, or use of electronic health information.” (CFR 171.103 (a))

There are differences between the requirements for health care providers versus other entities regarding information blocking. For health care providers, an action is considered information blocking if “such provider knows that such practice is unreasonable and is likely to interfere with access, exchange, or use of electronic health information.” (CFR 171.103 (b) (2)) However, for a health IT developer of certified health IT, health information network or health information exchange, an action would be considered information blocking if “such developer, network or exchange knows, or should know, that such practice is likely to interfere with access, exchange, or use of electronic health information.” This places a slightly higher bar on developers and networks knowing the requirements of information sharing and blocking. 

The prohibition against information blocking applies to all Electronic Health Information (EHI), basically all records maintained by or for a covered entity that are:

  • The medical records and billing records about individuals maintained by or for a covered health care provider;
  • The enrollment, payment, claims adjudication, and case or medical management record systems maintained by or for a health plan; or
  • Used, in whole or in part, by or for the covered entity to make decisions about individuals.

EHI excludes psychotherapy notes or information compiled in reasonable anticipation of, or for use in, a civil, criminal, or administrative action or proceeding. This includes not only clinical information but also the administrative and billing information that an entity holds. These two types of information can be held in separate systems or databases, so both must be considered in avoiding information blocking. 

Key Impact on Health Care Providers
Health care providers must make all EHI available to patients in an agreed upon electronic format, with little to no cost to the patient. This may be done through a portal, via USB or CDs, or through apps on a patient’s phone (e.g., Apple Health). Additionally, health IT vendors must provide electronic copies of data to health care providers when the provider wishes to change vendors, enabling them to import data seamlessly into a new system. This eliminates a significant roadblock to changes IT systems and vendors.

Examples of information blocking:

  • Charging fees for patients to access information
  • Limiting how long a provider or patient can access information for
  • Refusal to enable patient access to software or interfaces
  • Restrictions on authorized access, such as healthcare specialists
  • Restricting exchange or sharing capabilities
  • Excessive fees to export data when switching from one EHR to another.
  • Implementing non-standardized or complex technology
  • Writing terms and conditions or contracts that limit, discourage or restrict access
  • Placing excessive fees on consumers for creating unique EHR interfaces or connecting with other HIT systems
  • Configuring or implementing technology in ways that limit the types of data that can be exported or used from the technology, such as using non-standard implementation methods

Exceptions to Information Blocking Prohibitions
There may be legitimate reasons for a provider or vendor to block information. Accordingly, the Office of the National Coordinator for Health IT (ONC) established nine exceptions of reasonable and necessary practices that will not be considered information blocking. If an action meets the conditions of one or more exceptions, such practices will not be considered information blocking. Entities should carefully consider whether their actions meet these exceptions and consistently apply their actions. Specific policies should be developed to guide the exception decisions.

Exception 1 –  Preventing Harm
It will not be information blocking for an actor to engage in practices that are reasonable and necessary to prevent harm to a patient or another person, provided certain conditions are met. 

  • The actor must hold a reasonable belief that the practice will substantially reduce a risk of harm;
  • The actor’s practice must be no broader than necessary;
  • The actor’s practice must satisfy at least one condition from each of the following categories: type of risk, type of harm, and implementation basis; and
  • The practice must satisfy the condition concerning a patient right to request review of an individualized determination of risk of harm.

Each case is evaluated individually. Decisions can be based on who makes the request (patient, patient representative) and whether the harm may be done to the requestor or another person. Some examples may be:

  • Declining to share data that is corrupt, inaccurate, or erroneous.
  • Declining to share data arising from misidentifying a patient or mismatching a patient’s EHI.
  • Refraining from a disclosure that would endanger the life or physical safety of a patient or another person.   The provider who made the determination must have done so in the context of a current or prior clinician-patient relationship.

Exception 2 – Privacy
It will not be information blocking if an actor does not fulfill a request to access, exchange, or use EHI in order to protect an individual’s privacy, provided certain conditions are met. To satisfy this exception, an entity’s privacy-protective practice must meet at least one of the four sub-exceptions listed below.

  1. State or Federal law requires some preconditions to be met, but they haven’t been. If an actor 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, the actor may choose not to provide access, exchange, or use of such EHI if the precondition has not been satisfied under certain circumstances.
  2. Health IT developer of certified health IT is not covered by HIPAA. If an actor is a health IT developer of certified health IT that is not required to comply with the HIPAA Privacy Rule, the actor may choose to interfere with the access, exchange, or use of EHI for a privacy-protective purpose if certain conditions are met.
  3. Denying a request because the HIPAA Privacy Rule prohibits it. Denial of an individual’s request for their EHI consistent with 45 CFR 164.524(a) (1) and (2) of the HIPAA Privacy Rule (psychotherapy notes, information for an investigation, obtained under confidentiality from another person).
  4. Denying a request because an individual has requested in not be shared. An actor 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. Entities should consult with HIPAA Privacy Officers to develop appropriate policies and procedures to implement this exception. It is important to be consistent in these decisions.

Exception 3 – Security
It will not be information blocking for an actor to interfere with the access, exchange, or use of EHI in order to protect the security of EHI, provided certain conditions are met. The practice must be:

  • Directly related to safeguarding the confidentiality, integrity, and availability of EHI;
  • Tailored to specific security risks; and
  • Implemented in a consistent and non-discriminatory manner.
  • The practice must either implement a qualifying organizational security policy or implement a qualifying security determination.

This exception allows an entity not to comply with a request if, under the entity’s security policy, a security risk is identified. For example, a request may come from an unknown entity or another entity known to expose data. It may also be a request from an individual attempting to impersonate another individual, or using technology known to be malicious. An entity should develop policies to identify such situations and follow them. These policies should be developed and made available to guide these decisions.

Exception 4 – Infeasibility
It will not be information blocking if an actor does not fulfill a request to access, exchange, or use EHI due to the infeasibility of the request, provided certain conditions are met. ONC recognizes that there may be circumstances where a request cannot be fulfilled for technological, legal, or operational reasons. Several categories of these circumstances are provided; they include:

  • Uncontrollable events: such as 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.  These events must have specifically impacted the entity.
  • Segmentation: In some circumstances, the entity cannot unambiguously segment the requested EHI.  This may be due to a technological limitation or that the request includes conditions that are not included in an entity’s records. 
  • Infeasibility under the circumstances: The actor 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. This could be due to an absence of an employee, or even that the request does not make any sense. A written response to the requestor must be given within 10 business days of receipt of the request with the reason(s) why the request is infeasible.

Exception 5 – Health IT Performance
It will not be information blocking for an actor to take reasonable and necessary measures to make health IT temporarily unavailable or to degrade the health IT’s performance for the benefit of the overall performance of the health IT, provided certain conditions are met. Health IT systems do not necessarily run 24/7 at peak performance, and are often down temporarily for regular maintenance, upgrades, new software installs, or other technological reasons. Recognizing this, ONC provided an exception for those circumstances, allowing for the temporary suspension of responses.

Guidance on this exception includes:

  • The practice must be implemented for 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;
  • It must be implemented in a consistent and non-discriminatory manner; in other words, the system cannot be shut down to avoid giving data to specific other entities or be timed to avoid critical deadlines.
  • It must meet certain other requirements if the unavailability or degradation is initiated by a health IT developer of certified health IT, HIE, or HIN.

An entity may take action 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.

Note that if the issue causing the unavailability is because of a risk of harm or security risk, you need only comply with the Preventing Harm or Security Exception, as applicable.

Exception 6 – Manner Exception
This exception defines how (in what manner) a request may be fulfilled, allowing for potential alternatives.  It also tells when an entity need not fulfill such a request.

  • An entity must fulfill a request for electronic health information in any manner requested, unless the entity is technically unable to fulfill the request or cannot reach agreeable terms with the requestor to fulfill the request in the manner requested.  If agreed upon, fees and licenses can be negotiated.
  • There may be alternatives to the specific requests, and an entity can work with the requestor to provide an alternative means which may cost more. However, an entity is not required to provide the data in the requested manner and can use the following alternatives (in order):
    • Using the certified EHR standards that have been published by HHS
    • Using other standards which have been published by the Federal Government or a standards developing organization accredited by the American National Standards Institute.
    • Using an alternative machine-readable format, including the means to interpret the electronic health information, agreed upon with the requestor.
    • Fees or licenses required must meet the requirements listed in the Fees and Licenses exceptions.

Exception 7  – Fees Exception
An entity may charge fees, including fees that result in a reasonable profit margin, for accessing, exchanging, or using EHI, provided certain conditions are met.

  • The fees must be based on objective and verifiable criteria that are uniformly applied for all similar classes of persons or entities and requests.
  • The fees must be reasonably related to the actor’s costs of providing the type of access, exchange, or use of EHI.
  • Fees cannot be based on whether the requestor or other person is a competitor, potential competitor, or will be using the EHI in a way that facilitates competition
  • The exception does not apply to a fee based in any part on the electronic access by an individual, their personal representative, or another person or entity designated by the individual to access the individual’s EHI, or a fee to perform an export of electronic health information via the capability of Certified EHRs or other Health IT.

Exception 8  – License Exception
An entity (primarily a vendor) can license interoperability elements for EHI to be accessed, exchanged, or used, provided certain conditions are met. This exception allows entities to protect the value of their innovations and charge reasonable royalties to earn returns on the investments they have made to develop, maintain, and update those innovations. To meet this exception, an entity must:

  • Begin license negotiations with the requestor within 10 business days from receipt of the request and negotiate a license within 30 business days from receipt of the request and
  • Include reasonable terms.

This may occur when providers wish to update their systems when they get specific requests for EHI.  They can negotiate with a vendor to allow the request to be fulfilled and pay a reasonable license fee.

Exception 9  – TEFCA Exception
The Trusted Exchange Framework and Common Agreement (TEFCA) is a new structure developed through ONC that creates a standardized method for the exchange of data for all members of this exchange. Specific entities are still enrolling, and rules are now being finalized. The intent is to allow providers throughout the country to access any individual’s EHI when needed.

ONC has provided a new exception that if you and the requestor are members of TEFCA, then not fulfilling a request to access, exchange, or use EHI in a manner other than via TEFCA will not be considered information blocking when the following conditions are met:

  • The requestor is capable of such access, exchange, or use of the requested EHI from the actor via TEFCA;
  • The request for access, exchange, or use of EHI is not via the API standards;
  • Any fees charged by the actor in relation to fulfilling the request satisfy the fees exception; and
  • Any license of interoperability elements granted by the actor in relation to fulfilling the request satisfies the license exception.