Frequently Asked Questions

A determination as to whether a delay would be an interference that implicates the information blocking regulation would require a fact-based, case-by-case assessment of the circumstances.  That assessment would also determine whether the interference is with the legally permissible access, exchange, or use of EHI; whether the actor engaged in the practice with the requisite intent; and whether the practice satisfied the conditions of an exception. Please see 45 CFR 171.103 regarding the elements of information blocking.

Unlikely to be an Interference

If the delay is necessary to enable the access, exchange, or use of EHI, it is unlikely to be considered an interference under the definition of information blocking (85 FR 25813).

For example, if the release of EHI is delayed in order to ensure that the release complies with state law, it is unlikely to be considered an interference so long as the delay is no longer than necessary (see also 85 FR 25813). Longer delays might also be possible, and not be considered an interference if no longer than necessary, in scenarios where EHI must be manually retrieved and moved from one system to another system (see, for example, 85 FR 25866-25887 regarding the manual retrieval of EHI in response to a patient request for EHI).

Likely to be an Interference

It would likely be considered an interference for purposes of information blocking if a health care provider established an organizational policy that, for example, imposed delays on the release of lab results for any period of time in order to allow an ordering clinician to review the results or in order to personally inform the patient of the results before a patient can electronically access such results (see also 85 FR 25842 specifying that such a practice does not qualify for the “Preventing Harm” Exception).

To further illustrate, it also would likely be considered an interference:

• where a delay in providing access, exchange, or use occurs after a patient logs in to a patient portal to access EHI that a health care provider has (including, for example, lab results) and such EHI is not available—for any period of time—through the portal.
• where a delay occurs in providing a patient’s EHI via an API to an app that the patient has authorized to receive their EHI.

“Proactively” or “proactive” is not a regulatory concept included within the information blocking regulations. Rather, the information blocking regulations focus on whether a practice (an act or omission) constitutes information blocking. Further, an important consideration is whether the practice is likely to interfere with, prevent, or materially discourage the access, exchange, or use of EHI. In this regard, we direct readers to the following FAQ, which explains when a delay in making EHI available through a “patient portal” or an API for patients could constitute an interference and thus implicate the information blocking regulations:

When would a delay in fulfilling a request for access, exchange, or use of EHI be considered an interference under the information blocking regulation?

While the information blocking regulations do not require actors to proactively make electronic health information (EHI) available, once a request to access, exchange or use EHI is made actors must timely respond to the request (for example, from a patient for their test results). Delays or other unnecessary impediments could implicate the information blocking provisions.

In practice, this could mean a patient would be able to access EHI such as test results in parallel to the availability of the test results to the ordering clinician.

Please review the other questions under this heading for more information.

No. The definition of information blocking (45 CFR 171.103) does not include practices that interfere with access, exchange or use of EHI when they are specifically required by applicable law (see 85 FR 25794). To the extent the actor’s practice is likely to interfere with access, exchange, or use of EHI beyond what would be specifically necessary to comply with applicable law, the practice could implicate the information blocking definition.

No. The information blocking regulations (45 CFR Part 171) have their own standalone provisions (see 42 U.S.C. 300jj-52). The fact that an actor covered by the information blocking regulations meets its obligations under another law applicable to them or its circumstances (such as the maximum allowed time an actor has under that law to respond to a patient’s request) will not automatically demonstrate that the actor’s practice does not implicate the information blocking definition.

If an actor who could more promptly fulfill requests for legally permissible access, exchange, or use of EHI chooses instead to engage in a practice that delays fulfilling those requests, that practice could constitute an interference under the information blocking regulation, even if requests affected by the practice are fulfilled within a time period specified by a different applicable law.

It will not be considered an “interference” with the access, exchange, or use of EHI if:

• Foremost, the information provided by actors focuses on any current privacy and/or security risks posed by the technology or the third-party developer of the technology;
• Second, this information is factually accurate, unbiased, objective, and not unfair or deceptive; and
• Finally, the information is provided in a non-discriminatory manner.

For example, actors may establish processes where they notify a patient, call to a patient’s attention, or display in advance (as part of the app authorization process within certified API technology) whether the third-party developer of the app that the patient is about to authorize to receive their EHI has attested in the positive or negative as to whether the third party’s privacy policy and practices (including security practices) meet particular benchmarks. However, such processes must be non-discriminatory in that they must be used in the same manner for all third-party apps/developers.

The particular benchmarks an actor might identify in this example could be the minimum expectations described below, more stringent “best practice” expectations that may be set by the market, or some combination of minimum and “best practice” expectations. 

As described in the Final Rule at 85 FR 25816, all third-party privacy policies and practices should, at a minimum, adhere to the following:

• The privacy policy is made publicly accessible at all times, including updated versions;
• The privacy policy is shared with all individuals that use the technology prior to the technology’s receipt of EHI from an actor;
• The privacy policy is written in plain language and in a manner calculated to inform the individual who uses the technology;
• The privacy policy includes a statement of whether and how the individual’s EHI may be accessed, exchanged, or used by any other person or other entity, including whether the individual’s EHI may be sold at any time (including in the future); and
• The privacy policy includes a requirement for express consent from the individual before the individual’s EHI is accessed, exchanged, or used, including receiving the individual’s express consent before the individual’s EHI is sold (other than disclosures required by law or disclosures necessary in connection with the sale of the application or a similar transaction).

No. The information blocking regulation in 45 CFR part 171 do not require actors to violate business associate agreements (BAA) or associated service level agreements.

However, the terms or provisions of such agreements could constitute an interference (and thus could be information blocking) if used in a discriminatory manner by an actor to forbid or limit access, exchange, or use of electronic health information (EHI) that otherwise would be a permitted disclosure under the Privacy Rule.

For example, a BAA entered into by one or more actors that permits access, exchange, or use of EHI by certain health care providers for treatment should generally not prohibit or limit the access, exchange, or use of the EHI for treatment by other health care providers of a patient. See also the section discussing business associate agreements in the Final Rule at 85 FR 25812.

Correction: The wording in the second paragraph of this FAQ was corrected on 04/09/2021 to align with preamble text in the Final Rule (85 FR 25812).

No. Facts and circumstances will determine whether the information blocking regulations are implicated. Information blocking is defined, in relevant part, as a practice that is likely to interfere with, prevent, or materially discourage the access, exchange, or use of EHI (see 45 CFR 171.103; and 45 CFR 171.102 for the definition of “interfere with”).

A “practice” is further defined as an “act or omission” (45 CFR 171.102). As such, any act or omission, whether or not in response to a request for access, exchange, or use of EHI, could implicate the information blocking regulation if the act or omission interferes with, prevents, or materially discourages the access, exchange, or use of EHI. For example, as specified in section 3022(a)(2)(C) of the Public Health Service Act, added by the 21^st Century Cures Act, the practice of implementing health information technology in ways that are likely to restrict access, exchange, or use of EHI with respect to exporting complete information sets or transitioning between health IT systems could be considered information blocking. Similarly, the practice of including a contract provision that restricts access, exchange, or use of EHI could, under certain circumstances, implicate the information blocking regulations (see 85 FR 25812 for further discussion of contracts that may implicate the information blocking regulations). Further, omissions, including, but not limited to the following, could similarly implicate the information blocking regulations under certain circumstances: failure to exchange EHI; failure to make EHI available for use; and not complying with another law that requires access, exchange, or use of EHI.

If an actor is required to comply with another law that relates to the access, exchange, or use of EHI (as defined in 45 CFR 171.102), failure to comply with that law may implicate the information blocking regulations. This FAQ provides two examples of laws where non-compliance by an actor may implicate the information blocking regulations.  

Example 1 – ADT Notifications

In the Centers for Medicare & Medicaid Services (CMS) Interoperability and Patient Access Final Rule (85 FR 25510, 25602-03), CMS modified the Conditions of Participation (CoPs) to require hospitals (42 C.F.R. § 482.24(d)), psychiatric hospitals (42 C.F.R. § 482.61(f)), and critical access hospitals (CAHs) (42 C.F.R. § 485.638(d)) to send electronic patient event notifications of a patient’s admission, discharge, and transfer (ADT) to another health care facility or to another provider or practitioner (“ADT notifications”). The CMS regulations do not require such hospitals to first receive a request for access, exchange, or use of EHI for the obligation to send the ADT notification to be triggered. Thus, if a hospital (an “actor” under 45 CFR 171.102) does not comply with the regulatory requirement to send the ADT notification, its noncompliance could be an interference with the access, exchange, or use of EHI under the information blocking regulations. 

Example 2 – Public Health Reporting

Where a law requires actors to submit EHI to public health authorities, an actor’s failure to submit EHI to public health authorities could be considered an interference under the information blocking regulations. For example, many states legally require reporting of certain diseases and conditions to detect outbreaks and reduce the spread of disease. Should an actor that is required to comply with such a law fail to report, the failure could be an interference with access, exchange, or use of EHI under the information blocking regulations.

Please see the following FAQ for more information on how practices would be evaluated to determine whether the unique facts and circumstances constitute information blocking: How would any claim or report of information blocking be evaluated?

It would likely not be an interference when an actor follows an individual patient’s, or patient’s representative’s, request to delay release of the patient’s electronic health information (EHI) to the patient or to the patient’s representative. 

In the preamble to the 21st Century Cures Act final rule, we recognized that “some delays may be legitimate” (85 FR 25813) and not an interference (as defined in 45 CFR 171.102). However, the unique facts and circumstances of each situation would need to be evaluated. Generally, a delay should be for no longer than necessary to fulfill each patient’s request (see 85 FR 25813; see also 85 FR 25878 and 45 CFR 171.301(b)(2)(i)). 

When assessing whether a delay may be information blocking, facts indicating that an actor created extended or unnecessary delays may be evidence of an actor's intent to interfere with, prevent, or materially discourage access, exchange, or use of EHI (85 FR 25813). For example, when an actor delays the release of EHI in response to a patient’s request, relevant considerations for assessing whether the delay may be information blocking could include, without limitation, whether: the patient and actor agree on the timeframe or conditions for the delay (e.g., after 3 days or upon their clinician’s review, respectively), the timeframe or conditions are met, and there were no extended or unnecessary delays in meeting the timeframe or conditions.

Please see the following FAQ for more information on how practices would be evaluated to determine whether the unique facts and circumstances constitute information blocking: How would any claim or report of information blocking be evaluated?

Please also see the following FAQ regarding when a delay in making EHI available through a “patient portal” or an application programming interface (API) for patients could constitute an interference and thus implicate the information blocking regulations: When would a delay in fulfilling a request for access, exchange, or use of EHI be considered an interference under the information blocking regulation? 

There is no specific regulatory provision under the information blocking regulations that expressly requires actors to make individuals aware of newly available EHI, whether from a recent clinical encounter or newly available historical EHI not previously accessible to a patient. In most circumstances, practices to notify patients (e.g., by text alert or email) about newly available EHI or stopping such notifications would likely not be considered information blocking.
 
Please see the following FAQ for more information on how practices would be evaluated to determine whether the unique facts and circumstances constitute information blocking: How would any claim or report of information blocking be evaluated?

Yes. For API technology (i.e., a Health IT Module) to be certified to the Standardized API certification criterion (§ 170.315(g)(10)), it must incorporate a number of security requirements, including the use of OAuth2 (see, e.g., 85 FR 25741). In addition, the Standardized API certification criterion focuses on “read-only” responses to patient directed requests for EHI to be transmitted (see 85 FR 25742, “C. Standardized API for Patient and Population Services”). This means there should be few, if any, security concerns about the risks posed by patient-facing apps to the disclosing actor's health IT systems (because the apps would only be permitted to receive EHI at the patient's direction from the certified API technology). Thus, for third-party applications chosen by individuals to receive their EHI from API technology certified to the Standardized API certification criterion, there would generally not be a need for “vetting” the security of the app and such vetting actions would likely be an interference (85 FR 25815).

We do note, however, that actors, such as health care providers, have the ability to conduct whatever “vetting” they deem necessary of entities (e.g., app developers) that would be their business associates under HIPAA before the entities start using or maintaining EHI on behalf of the actor. In this regard, covered entities must conduct necessary vetting in order to comply with the HIPAA Security Rule (85 FR 25815).

^[1] “Vetting,” in the context of third party applications (apps), includes a determination regarding the security features of the app, such as whether the app poses a security risk to the actor's API (85 FR 25815).