Frequently Asked Questions

Yes, any individual or entity that meets the definition of at least one category of actor—“health care provider,” “health IT developer of certified health IT,” or “health information network or health information exchange” —as defined in 45 CFR 171.102  is subject to the information blocking regulations in 45 CFR part 171. The information blocking regulations in 45 CFR part 171 apply to a health care provider, as defined in the Public Health Service Act and incorporated in 45 CFR 171.102, regardless of whether any of the health IT the provider uses is certified under the ONC Health IT Certification Program.

Yes, any individual or entity that meets the definition of at least one category of actor —“health care provider,” “health IT developer of certified health IT,” or “health information network or health information exchange” — as defined in 45 CFR 171.102 is subject to the information blocking regulation in 45 CFR part 171. The information blocking regulations in 45 CFR part 171 apply to an entity that meets the HIN or HIE definition regardless of whether any of the health IT the HIN or HIE uses is certified under the ONC Health IT Certification Program.

The definition of “health information network (HIN) or health information exchange (HIE)” in 45 CFR 171.102 is a single, functional definition. We did not specifically exclude any particular entities from the definition, nor did we specifically identify particular entities in the definition. In order to determine whether your organization is a HIN/HIE for information blocking purposes, you should assess whether your organization’s functional activity meets the HIN/HIE definition in 45 CFR 171.102. The Information Blocking Actors fact sheet on HealthIT.gov presents the actor definitions in an easy-to-use format.

The answer depends on whether your company or organization meets the definition of “health IT developer of certified health IT” in 45 CFR 171.102. Under the definition, an individual or entity that develops or offers health IT is a “health IT developer of certified health IT” so long as that individual or entity develops or offers at least one Health IT Module certified under the ONC Health IT Certification Program. However, the definition explicitly excludes a health care provider that self-develops Health IT that is not offered to others. The Information Blocking Actors fact sheet on HealthIT.gov presents the actor definitions in an easy-to-use format.

Updated:

This FAQ has been updated to reflect the effective date of the HTI-1 Final Rule.

Yes. For purposes of the information blocking regulation, a “health IT developer of certified health IT” is defined in 45 CFR 171.102. With the sole exception of a health care provider that self-develops certified health IT that is not offered to others, this definition is met by any individual or entity that develops or offers health IT certified under the ONC Health IT Certification Program. If an individual or entity offers certified health IT for any period of time on or after the applicability date of 45 CFR part 171, then they would be considered to be a “health IT developer of certified health IT” for purposes of their conduct during that time. The information blocking provision would not apply to conduct the individual or entity engaged in after they no longer have or no longer offer any certified health IT. However, claims of information blocking with respect to conduct occurring while the individual or entity had certified health IT could be acted upon by HHS after the individual or entity no longer had or offered certified health IT. (See also ONC Cures Act Final Rule page 85 FR 25797).

Updated:

This FAQ has been updated to reflect the effective date of the HTI-1 Final Rule.

For purposes of the information blocking regulation in 45 CFR part 171, the term "actor" includes health care providers, health IT developers of certified health IT, and health information networks (HIN) or health information exchanges (HIE), as defined in 45 CFR 171.102. Although health plans and other payers are not specifically identified within any of these definitions, they also are not specifically excluded. To the extent an individual or entity that is a payer also meets the 45 CFR 171.102 definition of "health care provider," "health IT developer of certified health IT" or "health information network or health information exchange," that individual or entity would be considered an "actor" for purposes of information blocking. In addition, the HIN/HIE definition is a functional definition and should be reviewed for potential applicability to a health plan’s activities. The Information Blocking Actors fact sheet on HealthIT.gov presents these definitions in an easy-to-use format. (See also Cures Act Final Rule page 85 FR 25803)

In some instances, a business associate will be an actor under the information blocking regulation in 45 CFR part 171 and in other situations, it may not be an actor. The information blocking regulations in 45 CFR part 171 apply to health care providers, health IT developers of certified health IT, and health information networks (HIN) and health information exchanges (HIE), as each is defined in 45 CFR 171.102. Any individual or entity that meets one of these definitions is an “actor” and subject to the information blocking regulation in 45 CFR part 171, regardless of whether they are also a HIPAA covered entity (CE) or business associate (BA).

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).