ONC says actors that require third-party apps to be “vetted” by them for security reasons before allowing patients to use such apps to receive EHI via API technology certified to the Standardized API certification criterion is likely to be information blocking.
ONC concludes “there should be few, if any, security concerns about risks posed by patient-facing apps.”
- Actors may still “educate” patients about privacy and security risks associated with third-party apps, and this would not be information blocking.
Subscribe HERE to Legal HIE’s backend compliance library to gain access to tools, checklists, whitepapers, sample policies and a lot more to help your organization stay on top of the newest compliance challenges in 2023!
On May 1, the Office of National Coordinator (ONC) posted a new FAQ where it responded to questions concerning “vetting” of third-party applications under the Information Blocking Rule (IBR). In sum, ONC essentially concludes that an actor that attempts to engage in any additional vetting of patient-facing apps selected by an individual would likely be found to be engaged in impermissible interference under the IBR. Here is ONC’s FAQ#51 on this issue (with some editing by me):
Q: If an actor requires third-party applications (“apps”) to be “vetted” by them for security reasons before allowing patients to use such apps to receive EHI via API technology certified to the Standardized API certification criterion, is that practice likely to be an interference under the information blocking regulations?
“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. In addition, the Standardized API certification criterion focuses on “read-only” responses to patient directed requests for EHI to be transmitted. 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.” FAQ51.1.2023MAY
In the FAQ, ONC offers a definition of “vetting” (even though such term is not defined in the IBR):
“ ‘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.”
ONC also clarifies that actors that are also HIPAA-covered entities, such as health care providers, would continue to be permitted to conduct whatever “vetting” they deem necessary of entities (e.g., app developers) that would be their business associates under HIPAA before they start using or maintaining EHI on behalf of the actor.
It is worth noting that in an earlier FAQ from November 2020 ONC appears to distinguish taking steps to “educate” patients about the privacy and security risks posed by third-party apps that the patient chooses. In that post, ONC explained:
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. FAQ27.1.2020NOV
ONC then elaborated further:
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:
1. The privacy policy is made publicly accessible at all times, including updated versions;
2. The privacy policy is shared with all individuals that use the technology prior to the technology’s receipt of EHI from an actor;
3. The privacy policy is written in plain language and in a manner calculated to inform the individual who uses the technology;
4. 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
5. 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). FAQ27.1.2020NOV
In light of the foregoing, actors that have developed and are using their own “vetting” process for evaluating security standards for patient-facing apps before allowing individuals to connect to their electronic health record (EHR) should re-evaluate those processes. ONC’s November 2020 FAQ offers a good roadmap for actors to consider adopting to help individuals make good choices about the apps they use. My concern with relying solely on the security criteria required for API certification is that it is too low of a bar to adequately protect patients and other individuals from developers of apps that fail to keep promises to keep individuals’ information confidential. One doesn’t need to look farther than GoodRx and BetterHelp to see that.
