No, it would not be information blocking if the actor’s practice of not fulfilling a request in such circumstances meets the Privacy Exception (45 CFR 171.202). All actors remain responsible for disclosing EHI only when the disclosure is allowed under all applicable federal laws. For example, actors who are HIPAA covered entities or business associates must comply with the HIPAA Privacy Rule and any other applicable federal laws that limit access, exchange, or use of EHI in particular circumstances. Adherence to such federal laws is not information blocking, if the other conditions of the Privacy Exception are also met.*

In particular, where federal law such as the HIPAA Privacy Rule does not permit EHI to be used or disclosed unless certain requirements (“preconditions”) are met, then an actor’s practice of not fulfilling a request to access, exchange, or use EHI when these preconditions are not met is not information blocking.*** The Precondition Not Satisfied (45 CFR 171.202(b)) sub-exception of the Privacy Exception outlines a framework for actors to follow so that the actors’ practices of not fulfilling requests to access, exchange, or use EHI would not constitute information blocking when a precondition of applicable law has not been satisfied.

One example that highlights the alignment between the HIPAA Privacy Rule and the information blocking regulations is when a law enforcement official requests records of abortions performed from a clinic. As explained in the “HIPAA Privacy Rule and Disclosures of Information Relating to Reproductive Health Care” guidance issued by the Office for Civil Rights, there are certain preconditions that must be met before this disclosure can be made: “If the request is not accompanied by a court order or other mandate enforceable in a court of law, the Privacy Rule would not permit the clinic to disclose PHI in response to the request. Therefore, such a disclosure would be impermissible and constitute a breach of unsecured PHI requiring notification to HHS and the individual affected.” In this example, federal law does not permit the disclosure of EHI unless certain requirements are met, and therefore, the actor’s practice not to disclose EHI would not be information blocking. We note that this is just one example of how the HIPAA Privacy Rule gives individuals confidence that their protected health information, including information relating to abortion and other sexual and reproductive health care, will be kept private. Please see the guidance from the Office for Civil Rights for additional information and examples.

A second example of the alignment between the HIPAA Privacy Rule and the information blocking regulations is in circumstances where the HIPAA Privacy Rule permits a covered entity to use or disclose EHI only following receipt of a valid HIPAA authorization from the individual (patient) or the individual’s personal representative. If an actor does not have a valid HIPAA authorization from the individual or their personal representative that permits the use or disclosure of EHI for the requested purpose, then a precondition for disclosure is not satisfied. Accordingly, the actor’s practice of not disclosing EHI would not be considered information blocking if it is consistent with the requirements of the Precondition Not Satisfied sub-exception.

To emphasize, wherever any federal law requires the authorization of the individual to disclose the EHI, an individual may always choose not to give such authorization, and an actor who does not disclose the EHI would not be information blocking if the actor meets all applicable requirements of the Privacy Exception.

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