21st Century Cures Act Final Rule: Key Health Data Privacy Considerations

On the eve of a key compliance date, the HHS Office of the National Coordinator for Health Information Technology (ONC) extended deadlines for entities working in health information technology to comply with a new federal rule intended to “promote health care choice and competition across the United States” and “advance interoperability and support the access, exchange, and use of electronic health information.” Organizations now have until 2021 and 2022 to comply with key provisions of the 21st Century Cures Act.

In March, the ONC announced the Final Rule, which implements certain provisions of the 21st Century Cures Act, under the President’s 2017 Executive Order 13813. The Final Rule became effective on June 30, 2020, requiring organizations that hold patient data to take steps intended to make the information more portable and useful for individuals. However, the ONC initially deferred enforcement to November 2, 2020 in response to the COVID-19 pandemic and has now further extended compliance dates into next year and 2022. The agency will host an informational public webinar on the topic at 3pm ET today (registration for that webinar is available here).

As organizations move to implement privacy and data-related provisions of the 21st Century Cures Act final rule, they are weighing key privacy considerations, including:

• privacy exceptions around “information blocking;”
• privacy and security transparency attestation criteria;
• appropriate means of disclosing patient data under the HIPAA Privacy Rule right of access provisions; and
• privacy best practice recommendations for third-party app developers, as offered by the ONC and others, interfacing with HIPAA-covered electronic health information (EHI).

1. Privacy Exceptions Around Information Blocking

The Final Rule clarifies the definition of “information blocking” in the 21st Century Cures Act. The Act restricts information blocking by organizations that hold patient data, with the goal that more portable, interoperable health information will benefit individuals, clinicians, and researchers. The rule focuses on what qualifies as the intentionalwithholding of patient health information either from provider to provider or provider to patient data transfers. Three categories of “actors” are regulated by the rule’s information blocking provisions: 1) healthcare providers (e.g. healthcare facilities, laboratories, pharmacies, physicians, and providers), 2) health information networks; and 3) health information technology (IT) developers of certified health IT.

The Final Rule also discusses when “an actor’s practice of not fulfilling a request to access, exchange, or use EHI in order to protect an individual’s privacy” may not be considered information blocking (referred as the “Preventing Harm Exception”). Measures that would otherwise qualify as “information blocking” can be exempt from the rule’s restrictions on blocking if they are intentional measures to safeguard individual EHI privacy. In such circumstances, organizations must weigh net individual benefits to granting EHI access against net privacy risks. However, if the net portability benefits outweigh the privacy risks, arguments can be made that refusing a request to access, exchange, or use EHI would qualify as “information blocking.” The ONC will evaluate alleged violations of information blocking regulations on a case-by-case basis.

2. Privacy and Security Transparency Attestation Criteria

The ONC adopted privacy and security transparency attestation criteria while also recognizing the wide variation that exists in authentication needs and approaches across the health industry. The criteria is intended to serve as a key accountability mechanism to bolster security and privacy safeguards for health data held by covered organizations. Noting the large public support for multi-factor authentication (MFA) as a privacy and security certification criteria for developers of certified health IT, the ONC generally views MFA and “encrypting authentication credentials” as “best practices for privacy and security in healthcare settings.”

Although the ONC supports these two measures as best practices, there may be cases where either one or both measures could be inapplicable or inappropriate (e.g. when a Health IT Module does not support MFA). In such cases, in the spirit of consistency and transparency to engender goodwill among users and regulators, developers can provide rationale or context when attesting “no” to certain privacy and security attestation criteria.

3. Disclosing Patient Data Under the HIPAA Privacy Rule Right of Access Provisions

Right of access provisions under HIPAA regulation 45 CFR 164.524(a)(1) give individuals a right of access to their Protected Health Information (PHI) in the form of a “designated record set.” This includes EHI, health insurance claims data, and any information used “by or for the covered entity to make decisions about individuals.” The right of access provision excludes information that is not used to make decisions about individuals (e.g. provider performance evaluations or quality control records) and other information that is outside the scope of the “designated record set.”

The Final Rule provides guidance on the appropriate means of disclosing or ensuring patient access to PHI under the HIPAA right of access provisions. The phrase “appropriate means” rests on the nature and scope of the definition of “interoperability element” within the Final Rule, which is defined as:

“Hardware, software, integrated technologies or related licenses, technical information, privileges, rights, intellectual property, upgrades, or services that:

(1) may be necessary to access, exchange, or use EHI; and

(2) is controlled by the actor, which includes the ability to confer all rights and authorizations necessary to use the element to enable the access, exchange, or use of EHI.”

Web and mobile applications (e.g. direct-to-consumer apps) that rely on application programming interfaces (APIs) fall within the definition and scope of “interoperability element.” Privacy considerations emerge, however, when web and mobile applications interface with EHI systems, especially when the applications are run or hosted by third parties that are not HIPAA covered entities or business associates. Some public comments on the Final Rule discuss privacy concerns, including the potential for EHI to be mismatched or mishandled when shared via web or mobile applications that rely on APIs (third-party or otherwise). Despite these concerns, the ONC states that the rule’s “Preventing Harm Exception” should not interfere with legally permissible access, exchange, or use of patient EHI.

4. Best Practice Recommendations for EHI in Interoperable Mobile Applications

Recent expert analysis notes that “there is concern and uncertainty about transmitting a patient’s data to a health app of unknown security and privacy protection and whether the physician or covered entity may be liable if the patient’s app or its developer subsequently breaches or improperly uses or discloses the data.” There may be healthcare providers and patient app users with unresolved privacy and security concerns about adopting web or mobile applications to transmit, receive, or access health information.

To help address these concerns, the CARIN Trust Framework and Code of Conduct and Attestation (CARIN Code) offers an opportunity for consumer-facing apps that “collect personal data and are offered to and used by consumers in the United States, regardless of whether or not they are covered by HIPAA,” to publicly commit to standards of transparency, consent, use and disclosure, individual access, security, provenance, and accountability.

According to the CARIN Alliance, apps can “publicly endorse and agree to a set of questions regarding how they use, manage, and secure the consumer’s health data based on the principles in the code of conduct.”

App developer privacy policies, which are enforceable by the Federal Trade Commission and State Attorneys General, are an important area to consider when analyzing the privacy practices of mobile apps that interface with systems housing EHI. Beyond language in the Final Rule, the ONC provides five recommendations for privacy policies and practices to which third-party apps should adhere with regard to the access, exchange, or use of EHI. One key recommendation: a privacy policy should include “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).”

In 2016, FPF published Best Practices for Consumer Wearables and Wellness Apps and Devices. Although these FPF best practices exclude data governed by HIPAA (i.e. EHI), moving forward FPF will continue to convene industry and key other stakeholders to determine privacy best practices in light of the ONC Final Rule, CARIN Code, and other relevant guidance.

Public-facing commitment opportunities like the CARIN Code and FPF’s Best Practices for Consumer Wearables and Wellness Apps and Devices and Privacy Best Practices for Consumer Genetic Testing Services give organizations that generate and manage health data across the patient-consumer spectrum important opportunities to establish public trust and engage in transparent, enforceable self-regulation. In the absence of a comprehensive, federal privacy law, it is important for stakeholders that collect and use health data to establish privacy best practices and standards that add value to health management across the broadening patient-consumer spectrum.

Subscribe to the FPF mailing list to stay up to date on these issues and check out more of our top stories in health.

For additional information about FPF’s Health Initiative, please contact Dr. Rachele Hendricks Sturrup ([email protected]) and Katelyn Ringrose ([email protected]).

Acknowledgements to Samuel Adams, Policy Intern, for his background research and editorial contributions and Katelyn Ringrose, Policy Fellow, for her editorial contributions.