/>iAs consumerism in healthcare increases, companies and the individuals they serve are increasingly sharing data with third-party application developers that provide innovative ways to manage health and wellness, among numerous other products that leverage individuals’ identifiable health data. As the third-party application space continues to expand and data sharing becomes more prevalent, it is critical that such data sharing is done in a responsible manner and in accordance with applicable privacy and security standards. Yet, complying with applicable standards requires striking the right balance between rules promoting interoperability vis-à-vis prohibiting information blocking vs. ensuring patient privacy is protected. This is especially difficult when data is sent to third party applications that remain largely unregulated from a privacy and security perspective. Navigating this policy ‘tug of war’ will be critical for organizations to comply with the rules, but also maintain consumer confidence.
The Push for Greater Data Sharing
As discussed in a recent blog post by our colleagues, Trish Wagner and Ebunola Aniyikaiye, the Office of the National Coordinator for Health Information Technology (“ONC”) published a Final Rule promoting interoperability and prohibiting information blocking of electronic health information (“EHI”). The ONC Final Rule, which became effective on June 30, 2020, requires developers of certified health IT to include secure, standards-based application programming interfaces (“APIs”) to support patients’ access and control of their EHI. Through these APIs, patients may easily access and transfer their EHI to mobile apps of their choice. In many ways, this requirement comports with the patient’s right of access under the Health Insurance Portability and Accountability Act of 1996 and its implementing regulations (collectively “HIPAA”).
In line with the ONC Final Rule, CMS also finalized its Interoperability and Patient Access rules that requires Medicare Advantage plans, managed Medicaid and CHIP plans, and qualified health plans (“QHPs”) offered through the federal Exchanges to share claims data electronically with patients through APIs. Additionally, CMS made interoperability a Condition of Participation for hospitals, including Critical Access and Psychiatric Hospitals. Under these new rules, patients are afforded greater access to their EHI with the hope that they are empowered to be more informed decision makers.
The Pull of Individual Privacy
One significant concern and criticism raised about the ONC Final Rule related to its apparent lack of privacy safeguards related to data moving from the custody of HIPAA-regulated entities to the custody of largely unregulated third-party app developers. This was specifically highlighted in a letter to ONC from all the former National Health IT Coordinators of ONC prior to finalization of the rules. In particular, the former Coordinators stated,
“. . . these rules do not, however, fully address patient and consumer privacy protections. In parallel, we recommend that CMS and ONC, together with other relevant agencies and departments (such as the HHS Office of Civil Rights and the Federal Trade Commission) and private-sector colleagues, develop a companion consumer privacy framework. . . . Consumers should clearly understand how their data is being used by third-party APIs and how to exercise their consent options. A process should be put in place to ensure appropriate privacy protections are in place for consumers as the API market develops.” (emphasis added).
While efforts are underway on Capitol Hill, within various states and in the private sector to fill this privacy gap, it is important to note the ONC Final Rule does afford Actors eight exceptions to the information blocking rules. Of note, two exceptions relate to privacy and security, but these are limited in terms of what qualifies as a “reasonable and necessary” activity.
To qualify for the Privacy Exception, an Actor must meet any of the following conditions: (1) if a Federal or state law requires some precondition (e.g. consent) prior to sharing EHI, (2) health IT developers that are not otherwise subject to HIPAA may prevent transfer of EHI for privacy protective reasons, (3) denial of a patient’s right to access comports with HIPAA, or (4) if the individual has expressed a desire to not share his/her EHI.
To qualify for the Security Exception, an Actor must meet ALL of the following conditions: the practice must be (1) directly related to confidentiality, integrity and availability of EHI, (2) tailored to specific security risks, and (3) implemented in a consistent and non-discriminatory manner. There must also be a qualifying policy or other documentation of the determination as well. ONC recognized that many Actors are likely subject to the HIPAA Security Rule, and thus likely have policies that would comport with this exception.
When Can Third-Party Apps be Vetted Before Sharing EHI
The 21st Century Cures Act gave HHS broad authority to prohibit information blocking and to protect patient’s private information, but stopped short of extending its regulatory authority over app developers not covered under HIPAA. In line with this authority, the ONC Final Rule discourages vetting of third-party apps that is arbitrary, capricious, anti-competitive or discriminatory in nature. Further, any vetting that does occur must not otherwise violate the information blocking provisions or other applicable laws and regulations. The ONC Final Rule also takes that position that there should be few, if any, security concerns about the risks posed related to the use of certified API technology by third-party apps seeking to receive EHI from an Actor because the third-party apps would only be permitted to receive EHI at the patient’s direction. Similarly, CMS declined to establish a certification program for third-party app developers. Instead, CMS encouraged requesting third-party app developers to attest to having certain privacy and security provisions in their privacy policies prior to affording apps access to an open API. As such, the agencies drew a fine line between “vetting” and “verifying” and there would generally not be a basis for “vetting” third-party apps on security grounds if such apps were chosen by the individuals to facilitate their access to their EHI.
There are some specific carve outs from this more general rule. First, Actors that are subject to HIPAA, do have the ability to conduct any “vetting” in accordance with HIPAA they deem necessary of third-party app developers that serve as business associates before transmitting EHI. Second, Actors are permitted and encouraged to provide education to individuals about the privacy and security of third-party apps to assist individuals in deciding the risks associated with such apps. Such education communications must also comport with several requirements including the following: (1) they must be consistent regarding the advantages/disadvantages of transmitting EHI, (2) the information must focus on current privacy and/or security risks posed by an app or the third-party app developer, (3) the information must be factually accurate, unbiased, objective, and not unfair or deceptive, (4) the information must be provided in a non-discriminatory manner, and (5) Actors may not prevent an individual from deciding to provide its EHI to a technology developer or app despite the risks. Yet, in light of an information blocking claim, OIG and ONC may still review the communications made about privacy and security of third-party apps. Further, individuals using third-party apps can rely on federal and state consumer protection laws in the event an app developer uses or discloses personal information in violation of applicable privacy policies.
How Should HIPAA entities Vet Third-Party Apps Before Sharing EHI
To the extent permitted or required under applicable ONC and HIPAA standards, there are several risk dimensions of third-party apps that may be evaluated. From a security perspective, vetting should examine if third-party apps pose any direct risks to the systems to which they will connect. This can include review of controls related to transmission encryption, authentication and authorization. This vetting will largely be limited to technical controls associated with the apps. To the extent interconnection is through a Certified API technology under the ONC Final Rule, the third-party app may be verified for authenticity in accordance with those rules.
To the extent that the third-party app developer is a business associate under HIPAA, security reviews can include deeper reviews of administrative, physical and technical controls required by the HIPAA Security Rule. This review can go beyond technical safeguards such as access controls, anti-malware controls, audit controls, reliability, resilience and others. The review can also examine organizational controls such as training and workforce clearance procedures as well as physical security associated with vendor facilities hosting data. There are several resources to consider when evaluating the security of third-party apps such as guidance issued by FTC, OCR, NIST and MITRE.
From a privacy perspective, third-party apps can be evaluated to ensure EHI is not handled or exposed in unauthorized or impermissible ways. Vetting can review third-party app privacy policies for transparency around data collection, use and disclosure. This can also involve determinations about the level of consent required to support EHI transfer to a third-party app. To the extent the third-party app serves as a business associate, a covered entity may also evaluate whether there are grounds to prevent a transfer of data such as grounds to deny a patient’s right to access or grant a patient’s request to restrict access to their data.
Striking the Right Balance When Vetting Third-Party Apps
The extent of vetting that occurs will largely be driven by how the ONC and HIPAA rules apply to the disclosing organization as well as any third-party apps receiving EHI. Based on those boundaries, it is reasonable to conduct some vetting to gain assurances that EHI will be transferred in a secure manner and be handled in accordance with transparent privacy policies. Further, to reduce risk of information blocking claims under the ONC Rule, it is prudent to develop policies that govern such vetting practices. Such policies should be designed to support robust and consistent vetting, but should also include prohibitions related to unfair, deceptive, anti-competitive and discriminatory practices and for now will be left to industry and the marketplace to self-regulate.
