# Health Data, Technology, and Interoperability: Protecting Care Access

> Briefs, arguments, decisions, and more.

URL: https://www.frixlaw.com/law-library/documents/fr%3A2024-29683

## Record

- **Collection:** Federal Register
- **Document type:** Rule
- **Published:** December 17, 2024
- **Citation:** 89 FR 102512

## Text

DEPARTMENT OF HEALTH AND HUMAN SERVICES
Office of the Secretary
45 CFR Part 171
RIN 0955-AA06
Health Data, Technology, and Interoperability: Protecting Care Access

AGENCY:

Assistant Secretary for Technology Policy/Office of the National Coordinator for Health Information Technology, Department of Health and Human Services (HHS).

ACTION:

Final rule.

SUMMARY:

This final rule has finalized certain proposals from the Health Data, Technology, and Interoperability: Patient Engagement, Information Sharing, and Public Health Interoperability Proposed Rule (HTI-2 Proposed Rule) and in doing so supports the access, exchange, and use of electronic health information. Specifically, this final rule amends the information blocking regulations to revise two existing information blocking exceptions and establish an additional reasonable and necessary activity that does not constitute information blocking referred to as the Protecting Care Access Exception.

DATES:

This final rule is effective on December 17, 2024.

FOR FURTHER INFORMATION CONTACT:

Kate Tipping, Office of Policy, Assistant Secretary for Technology Policy (ASTP)/Office of the National Coordinator for Health Information Technology, 202-690-7151.

SUPPLEMENTARY INFORMATION:

Table of Contents

I. Executive Summary

A. Purpose of Regulatory Action

B. Summary of Information Blocking Enhancements

C. Costs and Benefits

II. Background

A. Statutory Basis

B. Regulatory History

III. Information Blocking Enhancements

A. Out of Scope Comments

B. Exceptions

1. Privacy Exception Updates

a. Privacy Exception—Definition of Individual

b. Privacy Sub-exception—Individual's Request Not To Share EHI

2. Infeasibility Exception Updates

3. New Protecting Care Access Exception

a. Background and Purpose

b. Threshold Condition and Structure of Exception

c. Patient Protection Condition

d. Care Access Condition

e. Presumption Provision and Definition of “Legal Action”

IV. Severability

V. Waiver of Delay in Effective Date

VI. Regulatory Impact Analysis

A. Statement of Need

B. Alternatives Considered

C. Overall Impact—

1. Executive Orders 12866 and 13563—Regulatory Planning and Review Analysis

D. Regulatory Flexibility Act

E. Executive Order 13132—Federalism

F. Unfunded Mandates Reform Act of 1995

I. Executive Summary

A. Purpose of Regulatory Action

The Secretary of Health and Human Services has delegated responsibility to the Assistant Secretary for Technology Policy and Office of the National Coordinator for Health Information Technology (hereafter ASTP/ONC)
1

to identify reasonable and necessary activities that do not constitute information blocking.
2

This final rule fulfills this responsibility; advances equity and innovation; and supports the access to, and exchange and use of, electronic health information (EHI).

1
The Office of the National Coordinator for Health Information Technology (ONC) was the previous name of this office. See
Federal Register
: Statement of Organization, Functions, and Delegations of Authority; Office of The National Coordinator for Health Information Technology
(89 FR 60903, July 29. 2024).

2
Reasonable and necessary activities that do not constitute information blocking, also known as information blocking exceptions, are identified in 45 CFR part 171, subparts B, C and D. ASTP/ONC's official website, HealthIT.gov, offers a variety of resources on the topic of Information Blocking, including fact sheets, recorded webinars, and frequently asked questions. To learn more, please visit:
https://www.healthit.gov/topic/information-blocking/.

The final rule is also consistent with Executive Order (E.O.) 14036. E.O. 14036, Promoting Competition in the American Economy,
3

issued on July 9, 2021, established a whole-of-government effort to promote competition in the American economy and reaffirmed the policy stated in E.O. 13725 of April 15, 2016 (Steps to Increase Competition and Better Inform Consumers and Workers to Support Continued Growth of the American Economy).
4

In this rule, we have finalized enhancements to support information sharing under the information blocking regulations and promote innovation and competition, while ensuring patients' privacy and access to care remain protected. Addressing information blocking is critical for promoting innovation and competition in health IT and for the delivery of health care services to individuals, as discussed in both the March 4, 2019, proposed rule, “21st Century Cures Act: Interoperability, Information Blocking, and the ONC Health IT Certification Program” (84 FR 7508 and 7523) (ONC Cures Act Proposed Rule) and the May 1, 2020 final rule, “21st Century Cures Act: Interoperability, Information Blocking, and the ONC Health IT Certification Program” (85 FR 25790 and 25791) (ONC Cures Act Final Rule), and reiterated in the January 9, 2024 final rule, “Health Data, Technology, and Interoperability: Certification Program Updates, Algorithm Transparency, and Information Sharing” (89 FR 1195) (HTI-1 Final Rule). Specifically, we described (84 FR 7508 and 85 FR 25791) how the information blocking provision (section 3022 of the Public Health Service Act (PHSA) (42 U.S.C. 300jj-52)) provides a comprehensive response to the issues identified by empirical and economic research that suggested that information blocking may weaken competition, encourage consolidation, and create barriers to entry for developers of new and innovative applications and technologies that enable more effective uses of EHI to improve population health and the patient experience.
5

As we explained in the ONC Cures Act Final Rule, the PHSA information blocking provision itself expressly addresses practices that impede innovation and advancements in EHI access, exchange, and use, including care delivery enabled by health IT (85 FR 25820, citing section 3022(a)(2) of the PHSA). Actors subject to the information blocking provisions may, among other practices, attempt to exploit their control over interoperability elements to create barriers to entry for competing technologies and services that offer greater value for health IT customers

and users, provide new or improved capabilities, and enable more robust access, exchange, and use of EHI (85 FR 25820).
6

Information blocking may also harm competition not just in health IT markets, but also in markets for health care services (85 FR 25820). In the ONC Cures Act Final Rule, we described practices that dominant market providers may leverage and use to control access and use of their technology, resulting in technological dependence and possibly leading to barriers to entry by would-be competitors, as well as making some market providers vulnerable to acquisition or inducement into arrangements that enhance the market power of incumbent providers to the detriment of consumers and purchasers of health care services (85 FR 25820). The revisions to the information blocking regulations, including the addition of the new exception finalized in this final rule, will continue to promote innovation and support the lawful access, exchange, and use of EHI, while strengthening support for individuals' privacy and EHI sharing preferences.

3
Executive Order 14036: Promoting Competition in the American Economy, Jul 9, 2021 (86 FR 36987).

4
Executive Order 13725: Steps to Increase Competition and Better Inform Consumers and Workers to Support Continued Growth of the American Economy, Apr 15, 2016 (81 FR 23417)

5

See, e.g.,
Martin Gaynor, Farzad Mostashari, and Paul B. Ginsberg, Making Health Care Markets Work: Competition Policy for Health Care,
JAMA,
317(13) 1313-1314 (Apr. 2017); Diego A. Martinez et al., A Strategic Gaming Model for Health Information Exchange Markets,
Health Care Mgmt. Science
21, 119-130 (Sept. 2016); (“[S]ome healthcare provider entities may be interfering with HIE across disparate and unaffiliated providers to gain market advantage.”); Niam Yaraghi, A Sustainable Business Model for Health Information Exchange Platforms: The Solution to Interoperability in Healthcare IT (2015), available at
https://www.brookings.edu/articles/a-sustainable-business-model-for-health-information-exchange-platforms-the-solution-to-interoperability-in-health-care-it/;
Thomas C. Tsai Ashish K. Jha, Hospital Consolidation, Competition, and Quality: Is Bigger Necessarily Better? 312 JAMA 312(1), 29030 (Jul 2014).

6

See also
Martin Gaynor, Farzad Mostashari, and Paul B. Ginsberg, Making Health Care Markets Work: Competition Policy for Health Care,
JAMA,
317(13) 1313-1314 (Apr. 2017).

B. Summary of Information Blocking Enhancements

We received approximately 270 comment submissions on the broad range of proposals included in the “Health Data, Technology, and Interoperability: Patient Engagement, Information Sharing, and Public Health Interoperability” proposed rule (89 FR 63498) (HTI-2 Proposed Rule). We thank all commenters for their thoughtful input. For the purposes of this final rule, we have reviewed and responded to comments on a narrowed set of proposals. Specifically, we summarize and respond to comments related to the proposals finalized in this rule (described below). Comments received in response to other proposals from the HTI-2 Proposed Rule are beyond the scope of this final rule, have been addressed in the “Health Data, Technology, and Interoperability: Trusted Exchange Framework and Common Agreement (TEFCA
TM
)” final rule (RIN 0955-AA07) (HTI-2 Final Rule) or are still being reviewed and considered. Comments related to proposals not discussed in this final rule or the HTI-2 Final Rule may be the subject of subsequent final rules related to such proposals in the future.

On July 25, 2024, HHS announced a reorganization that, among other things, renamed the Office of the National Coordinator for Health Information Technology (ONC). ONC is now dually titled as the Assistant Secretary for Technology Policy and Office of the National Coordinator for Health Information Technology (ASTP/ONC) per the
Federal Register
notice that appeared in the
Federal Register
on July 29, 2024.
7

It was not until days after the HTI-2 Proposed Rule's content had been released to the public (on July 10, 2024)
8

that the name change was announced. Therefore, when the HTI-2 Proposed Rule appeared in the
Federal Register
on August 5, 2024, it retained reference to the office as “ONC.” We continue to refer to “ONC” when referencing the HTI-2 Proposed Rule in this final rule. However, in the comment summaries and responses of this final rule, we have revised and replaced “ONC” references with “ASTP/ONC.”

7
Statement of Organization, Functions, and Delegations of Authority; Office of The National Coordinator for Health Information Technology
(89 FR 60903).

8

https://www.hhs.gov/about/news/2024/07/10/hhs-proposes-hti-2-rule-improve-patient-engagement-information-sharing-public-health-interoperability.html.

In this final rule, we have finalized the addition of a definition of “reproductive health care” to the defined terms for purposes of the information blocking regulations, which appear in 45 CFR 171.102. We have finalized select proposed revisions (proposed in the HTI-2 Proposed Rule at 89 FR 63620 through 63627 and 89 FR 63803) for two existing information blocking exceptions (Privacy Exception and Infeasibility Exception) in subpart B of 45 CFR part 171. Finally, we have finalized a new information blocking exception (Protecting Care Access) in subpart B of part 171.

C. Costs and Benefits

Executive Orders 12866 and 13563 direct agencies to assess all costs and benefits of available regulatory alternatives and, if regulation is necessary, to select regulatory approaches that maximize net benefits (including potential economic, environmental, public health and safety effects, distributive impacts, and equity). Executive Order 14094 (Modernizing Regulatory Review) (hereinafter, the Modernizing E.O.) amends section 3(f) of Executive Order 12866 (Regulatory Planning and Review). The amended section 3(f) of Executive Order 12866 defines a “significant regulatory action.” The Office of Management and Budget's (OMB) Office of Information and Regulatory Affairs (OIRA) has determined that this final rule is a significant regulatory action under section 3(f) of Executive Order 12866 as amended by E.O. 14094.

II. Background

A. Statutory Basis

The Health Information Technology for Economic and Clinical Health Act (HITECH Act), Title XIII of Division A and Title IV of Division B of the American Recovery and Reinvestment Act of 2009 (Pub. L. 111-5), was enacted on February 17, 2009. The HITECH Act added to the Public Health Service Act (PHSA) “Title XXX—Health Information Technology and Quality” (Title XXX) to improve health care quality, safety, and efficiency through the promotion of health IT and EHI exchange.

The 21st Century Cures Act (Pub. L. 114-255) (Cures Act) was enacted on December 13, 2016, to accelerate the discovery, development, and delivery of 21st century cures, and for other purposes. The Cures Act, through Title IV—Delivery, amended Title XXX of the PHSA by modifying or adding certain provisions to the PHSA relating to health IT.

Information Blocking Under the 21st Century Cures Act

Section 4004 of the Cures Act added section 3022 of the Public Health Service Act (PHSA) (42 U.S.C. 300jj-52, “the information blocking provision”). Section 3022(a)(1) of the PHSA defines practices that constitute information blocking when engaged in by a health care provider, or a health information technology developer, exchange, or network. Section 3022(a)(3) authorizes the Secretary to identify, through notice and comment rulemaking, reasonable and necessary activities that do not constitute information blocking for purposes of the definition set forth in section 3022(a)(1).

B. Regulatory History

On March 4, 2019, the ONC Cures Act Proposed Rule was published in the
Federal Register
(84 FR 7424). The proposed rule proposed to implement certain provisions of the Cures Act that would advance interoperability and support the access, exchange, and use of electronic health information.

On May 1, 2020, the ONC Cures Act Final Rule was published in the
Federal Register
(85 FR 25642). The final rule implemented certain provisions of the Cures Act, including Conditions and Maintenance of Certification requirements for health IT developers

and the voluntary certification of health IT for use by pediatric health providers, and identified reasonable and necessary activities that do not constitute information blocking. The final rule also implemented certain parts of the Cures Act to support patients' access to their EHI. Additionally, the ONC Cures Act Final Rule modified the 2015 Edition health IT certification criteria and ONC Health IT Certification Program (Program) in other ways to advance interoperability, enhance health IT certification, and reduce burden and costs, as well as to improve patient and health care provider access to EHI and promote competition. On November 4, 2020, the Secretary published an interim final rule with comment period titled “Information Blocking and the ONC Health IT Certification Program: Extension of Compliance Dates and Timeframes in Response to the COVID-19 Public Health Emergency” (85 FR 70064) (Cures Act Interim Final Rule). The interim final rule extended certain compliance dates and timeframes adopted in the ONC Cures Act Final Rule to offer the health care system additional flexibilities in furnishing services to combat the COVID-19 pandemic, including extending the applicability date for information blocking provisions to April 5, 2021.

On April 18, 2023, a proposed rule titled, “Health Data, Technology, and Interoperability: Certification Program Updates, Algorithm Transparency, and Information Sharing” (88 FR 23746) (HTI-1 Proposed Rule) was published in the
Federal Register
. The HTI-1 Proposed Rule proposed to implement the Electronic Health Record (EHR) Reporting Program provision of the Cures Act by establishing new Conditions and Maintenance of Certification requirements for health IT developers under the Program. The HTI-1 Proposed Rule also proposed to make several updates to certification criteria and implementation specifications recognized by the Program, including revised certification criteria for: “clinical decision support” (CDS), “patient demographics and observations”, and “electronic case reporting.” The HTI-1 Proposed Rule also proposed to establish a new baseline version of the United States Core Data for Interoperability (USCDI). Additionally, the HTI-1 Proposed Rule proposed enhancements to support information sharing under the information blocking regulations.

On January 9, 2024, the HTI-1 Final Rule was published in the
Federal Register
, which implemented the EHR Reporting Program provision of the 21st Century Cures Act and established new Conditions and Maintenance of Certification requirements for health IT developers under the Program (89 FR 1192). The HTI-1 Final Rule also made several updates to certification criteria and standards recognized by the Program. The HTI-1 Final Rule provided enhancements to support information sharing under the information blocking regulations, including clarifying certain definitions and establishing a new “TEFCA Manner” Exception—which provides that an actor's practice of not fulfilling a request to access, exchange, or use EHI in any alternative manner besides via TEFCA will not be considered information blocking when the practice follows certain conditions (
see
45 CFR 171.403 and 89 FR 1387 through 1394). Through these provisions, we sought to advance interoperability, improve algorithm transparency, and support the access, exchange, and use of EHI. The HTI-1 Final Rule also updated numerous technical standards in the Program in additional ways to advance interoperability, enhance health IT certification, and reduce burden and costs for health IT developers and users of health IT.

On August 5, 2024, the HTI-2 Proposed Rule was published in the
Federal Register
(89 FR 63498). The HTI-2 Proposed Rule is the second of the Health Data, Technology, and Interoperability rules that seek to advance interoperability, improve transparency, and support the access, exchange, and use of electronic health information. The HTI-2 Proposed Rule included proposals for: standards adoption; adoption of certification criteria to advance public health data exchange; expanded uses of certified application programming interfaces, such as for electronic prior authorization, patient access, care management, and care coordination; and information sharing under the information blocking regulations. Additionally, the HTI-2 Proposed Rule proposed to establish a new baseline version of the USCDI standard and proposed to update the ONC Health IT Certification Program to enhance interoperability and optimize certification processes to reduce burden and costs. The HTI-2 Proposed Rule also proposed to implement certain provisions related to TEFCA, which would support reliability, privacy, security, and trust within TEFCA. In the HTI-2 Final Rule (RIN 0955-AA07), we codified definitions of certain TEFCA terms in § 171.401 of the information blocking regulations and finalized the 45 CFR part 172 TEFCA provisions.

III. Information Blocking Enhancements

In the HTI-2 Proposed Rule, we proposed revisions to defined terms for purposes of the information blocking regulations, which appear in 45 CFR 171.102. Specifically, we proposed to clarify the definition of “health care provider” (89 FR 63616, 63617, and 63802) and adopt definitions for three terms not previously included in § 171.102: “business day” (89 FR 63601, 63602, 63626, and 63802), “health information technology or health IT” (89 FR 63617 and 63802), and “reproductive health care” (89 FR 63633 and 63802). Of these, we address in this final rule only the proposal to add to § 171.102 a definition of “reproductive health care” and comments received in response to that proposal. Comments received specific to other proposed revisions to § 171.102 are beyond the scope of this final rule but may be the subject(s) of a different final rule or rules related to such proposal(s).

We proposed to revise two existing exceptions in subpart B of 45 CFR part 171 (§ 171.202 and § 171.204) and solicited comment on potential revisions to one exception in subpart D (§ 171.403). We proposed revisions to paragraphs (a), (d), and (e) of § 171.202 (89 FR 63620 through 63622, and 63803) and to paragraphs (a)(2), (a)(3) and (b) of § 171.204 (89 FR 63622 through 63628, and 63803). In this final rule, we address comments received on or relevant to proposed revisions to paragraphs (a) and (e) of § 171.202 and paragraph (a)(2) of § 171.204. Comments received specific to proposed revisions to § 171.202(d), § 171.204(a)(3), and § 171.204(b) are beyond the scope of this final rule but may be the subject(s) of a future final rule related to such proposal(s).

We proposed two new exceptions, the Protecting Care Access Exception and the Requestor Preferences Exception, in subparts B and C of part 171 respectively. The Protecting Care Access Exception was proposed as new § 171.206 (89 FR 63627 through 63639, and 63804). We have finalized the proposed Protecting Care Access Exception (§ 171.206), and we address comments relevant to it in this final rule. Comments received specific to the Requestor Preferences Exception (§ 171.304) proposal (89 FR 63639 through 63642, 63804 and 63805) are beyond the scope of this final rule but may be a subject of a future final rule related to that proposal.

We proposed to codify in § 171.401 definitions of certain terms relevant to the Trusted Exchange Framework and

Common Agreement
TM
(TEFCA
TM
) (89 FR 63642, 63804, and 63805) and in § 171.104 descriptions of certain practices that constitute interference with the access, exchange, and use of electronic health information (EHI) (89 FR 63617 through 63620, 63802, and 63803). We do not address either of those proposals in this final rule, and comments regarding them are also beyond the scope of this final rule. However, in the HTI-2 Final Rule (RIN 0955-AA07), we finalized the proposed definitions of certain terms relevant to TEFCA
TM
in § 171.401.

A. Out of Scope Comments

In addition to comments received on proposals that we included in the HTI-2 Proposed Rule, we received numerous comments that were beyond the scope of any proposal in the HTI-2 Proposed Rule. For example, we received comments recommending that ASTP/ONC revise an information blocking exception to which we had not proposed any revisions. We also received comments recommending that we adopt new requirements for actors' conduct or technology regarding which we did not make any related proposals in the HTI-2 Proposed Rule. While we do not specifically address in this final rule all comments received on matters beyond the scope of the HTI-2 Proposed Rule, nor do we intend to address them all in any other final rule, we do address some of them (below) prior to more in-depth discussions of comments received that are specifically related to proposals addressed in this final rule.

Comment.
One commenter expressed support for greater transparency and timely access to health information for patients. However, they stated that the regulations as they exist today do not appropriately mitigate patient harm within the “Preventing Harm Exception.” They stated a belief that the Preventing Harm Exception does not account for the harm caused by immediate patient access to distressing or confusing laboratory test or imaging results. They stated a belief that “the strict definition outlined by ONC does not include emotional harm.” The commenter stated that certain scenarios require particularly sensitive care conversations, where patients are able to process the results with an experienced health care professional. Therefore, they urged that we clarify that the Preventing Harm Exception includes emotional distress.

Response.
We thank the commenter for their feedback. As discussed in context of finalized revisions to the
segmentation
condition of the Infeasibility Exception (§ 171.204(a)(2)), this rule retains application of the Infeasibility Exception in circumstances where an actor cannot unambiguously segment EHI they have chosen to withhold consistent with the Preventing Harm Exception (§ 171.201) from other EHI that they could share under applicable law. Any modification to the Preventing Harm Exception or other revision to 45 CFR part 171 to create a regulatory exception designed to cover situations where a health care provider may want to limit a patient's own access to their health information based on concern about the information being upsetting or confusing the patient is beyond the scope of this final rule. We did not propose in the HTI-2 Proposed Rule any changes to the Preventing Harm Exception. The revisions we did propose to the Infeasibility Exception or Privacy Exception, or establishment of the new Protecting Care Access Exception, finalized in this rule do not change or conflict with any condition of the Preventing Harm Exception in § 171.201. We emphasize that the Preventing Harm Exception and the Protecting Care Access Exception operate independently of one another and of all other exceptions. An actor's practice does not need to satisfy any portion of any other exception in order to satisfy the Preventing Harm Exception. Likewise, an actor's practice need not satisfy any portion of any other exception to satisfy the Protecting Care Access Exception. We refer readers to the discussion in the HTI-1 Final Rule of how “stacking” of exceptions may be relevant because an actor wishes to engage in one or more practice(s) that are covered in part, but not fully covered, solely by the Privacy Exception (§  171.202) or solely by the Preventing Harm Exception (§  171.201) (89 FR 1352 through 1354). As we noted and emphasized in the HTI-1 Final Rule (89 FR 1354), the example detailed in that discussion was an example scenario where an individual has requested restrictions that the actor has chosen to honor, but there may be a wide variety of scenarios where “stacking” other combinations of various exceptions with one another, or with restrictions on use or disclosure of EHI under applicable law, may occur. The Protecting Care Access Exception finalized in this rule may be combined (or “stacked”) with the Infeasibility Exception when both are applicable. Later in this final rule, we discuss the revised
segmentation
condition of the Infeasibility Exception and when it may be applicable in complement to another exception under which an actor may have chosen to withhold a portion of the EHI the actor would be permitted by applicable law to make available to a requestor for permissible purposes.

Specific to this commenter's concerns about allowing patients to access EHI before it has been explained to them or with limited context, we recognize that patients have different degrees of health literacy as well as different individual preferences for when and how to receive information that may be upsetting. We are aware that some patients may experience emotional distress from accessing new information about their health without additional context or explanation of what the information means for their health or care. We also recognize that many clinical situations are too nuanced to provide the context a patient needs through means other than a conversation with a health care professional. However, as we noted in the ONC Cures Act Final Rule (
85 FR 25824 and 25825
), it would be challenging to define an appropriate and unique standard for purposes of the Preventing Harm Exception for non-physical harms that all actors, as defined in §  171.102, could apply consistently and, most importantly, without unduly restricting patients' rights to access their health information. We may consider exploring options to address such concerns in future rulemaking, but we note that we would not interpret anything in 45 CFR part 171 as compelling a patient to review information before the patient is ready.

To ensure that this discussion does not introduce confusion about the applicability of the Preventing Harm Exception (§ 171.201),
9

we remind readers that the Preventing Harm Exception relies on the same types of harm that apply for a covered entity to deny access to protected health information (PHI) under the Health Insurance Portability and Accountability Act of 1996 (HIPAA) Privacy Rule.
10

For example, in situations where a patient's representative is accessing the patient's EHI (such as a parent accessing EHI of their minor child), the Preventing Harm Exception relies on the same

“substantial harm” standard that applies under the HIPAA Privacy Rule to a HIPAA covered entity's denial of a personal representative's access of an individual's PHI on “reviewable grounds” (see 45 CFR 164.524(a)(3)(iii)).
11

“Substantial harm” includes “substantial physical, emotional, or psychological harm” (see, for example, HIPAA Privacy Rule preamble at 65 FR 82556). We have published an illustrative chart of the patient access cases where the Preventing Harm Exception recognizes “substantial harm,” in a frequently asked question (IB.FAQ42.1.2022FEB) that is available at:
https://www.healthit.gov/faq/which-patient-access-cases-does-preventing-harm-exception-recognize-substantial-harm.
12

9
For the Preventing Harm Exception to cover an actor's practice likely to interfere with access, exchange, or use of EHI (by the patient or by anyone else who may, under applicable law, access, exchange, or use the patient's EHI for permissible purposes), the actor's practice must meet the applicable conditions of the exception at all relevant times. We refer readers to 45 CFR 171.201 for the full conditions of the Preventing Harm Exception, and those seeking additional information about those conditions to their preamble discussion in the ONC Cures Act Final Rule (85 FR 25821 to 25844).

10
45 CFR part 160 and subparts A and E of 45 CFR part 164.

11
The “substantial harm” standard also applies to denial of access to PHI that references another person (other than a health care provider), see 45 CFR 164.524(a)(3)(ii).

12
This FAQ can also be found, alongside others about the Preventing Harm Exception, other exceptions, and other topics, on HealthIT.gov's Information Blocking FAQs page (
https://www.healthit.gov/faqs?f%5B0%5D=term_parent%3A7011
).

Comment.
One commenter noted that information blocking could seriously harm the free market and the health care services market if left unchecked. The commenter expressed that the information blocking provisions set the country up for the future by promoting innovation, while simultaneously ensuring lawful access, exchange, and use of electronic health information. The commenter noted that the inclusion of information blocking provisions ensures that barriers to entry are not created for competing technologies, allowing for competition and unhindered development of improved technologies.

Response.
We agree with and appreciate the commenter's feedback.

Comments.
Multiple commenters requested clarification or sought additional education on a variety of topics related to information blocking or to information sharing. One commenter sought guidance on how to understand information blocking concepts and relationships between concepts. They suggested that we provide decision trees, relationship diagrams, or possibly supplemental educational materials. A commenter requested a concerted effort by key HHS entities, including the Office for Civil Rights (OCR) and ASTP/ONC, to bolster patient and provider community education about the HIPAA Privacy Rule, its updates, and related information blocking exceptions. This commenter emphasized the importance of patient understanding in assuring data sharing consent is true, informed consent. The commenter encouraged us to continue investing in the education of individuals whose data is exchanged in support of patient and population health goals, especially as data sharing becomes more widespread under TEFCA and other frameworks.

Another commenter urged that we place a special emphasis on educating consumers and other parties about limitations in the ability for long-term and post-acute care (LTPAC) providers to furnish some information electronically due to current standards limitations. This commenter expressed concerns regarding legitimate circumstances where certain patient health information from LTPAC providers is not currently feasible to be exchanged via a portal or third-party app and how this could potentially result in a high volume of avoidable consumer information blocking complaints and investigations directed at LTPAC providers. Another commenter expressed that it is important to promote interoperability and exchange between LTPAC providers and the EHRs of patients' doctors.

Response.
We thank commenters for requesting these clarifications. We note that we have offered information sessions and published sub-regulatory guidance documents, fact sheets, and frequently asked questions to provide supplemental information about the information blocking regulations.

We agree that it is important to educate patients about data sharing and its implications. However, discussion of specific additional investment in educational initiatives, as one commenter suggested, is beyond the scope of this final rule. Similarly, we recognize the importance of educating consumers about the limitations of EHI exchange, including particular care and practice settings (such as LTPAC) where the functionalities supported by currently deployed health IT may be more variable than in other settings (such as acute-care hospitals or physician practices). However, providing such education is not in scope for this final rule and would be more effective, we believe, in different contexts than this final rule. We refer readers seeking resources and information for LTPAC providers to advance their adoption and use of interoperable health IT and health information exchange to support care coordination and outcomes to ASTP/ONC's official website, HealthIT.gov. We offer a range of resources for health care providers across a broad array of care settings online, free of charge. (Start at
https://www.healthit.gov/topic/health-it-health-care-settings/health-it-health-care-settings
). For example, we offer an educational module for LTPAC providers
13

and our Health IT Playbook (
https://www.healthit.gov/playbook/
) has implementation resources for LTPAC providers.
14

From an information-blocking perspective, information resources currently available at
https://www.healthit.gov/informationblocking
are relevant to actors, including LTPAC and other health care providers.
15

We will continue to look for ways to engage and educate the health IT community, including patients, about our regulations.

13

https://www.healthit.gov/sites/default/files/ltpac_healthit_educationmodule_8-7-17_ecm.pdf.

14

https://www.healthit.gov/playbook/care-settings/.

15
In addition to fact sheets, FAQs, blogs, we offer recorded webinars, including a three-webinar series designed for the health care provider audience as a whole and one that we designed for and delivered to an LTPAC audience. The LTPAC webinar slides are available at:
https://www.healthit.gov/sites/default/files/2024-03/InformationBlockingPresentationPDF_LTPAC_2.22.24.pdf
(A link to view the recorded webinar is available from
https://www.healthit.gov/topic/information-blocking
).

Comment.
One commenter suggested requiring exam room laptops to be locked after every patient. They expressed concerns about patient record visibility between visits, noting that physicians should be required to enter their passwords to access the information when they enter the room.

Response.
Although the concern raised by this comment is beyond the scope of the HTI-2 Proposed Rule, we thank the commenter for their feedback. We strive to promote and recommend best practices for securing EHI. Additional privacy and security information, resources, and tools for both consumers and health care providers are available through ASTP/ONC's official website, HealthIT.gov.
16

16

https://www.healthit.gov/topic/privacy-security-and-hipaa.

B. Exceptions

1. Privacy Exception Updates

a. Privacy Exception—Definition of Individual

For purposes of the Privacy Exception, the term “individual” is defined in § 171.202(a)(2). When the Privacy Exception in § 171.202 and paragraph (a)(2) were initially established by the ONC Cures Act Final Rule, the codified text included a typographical error that was not identified until after publication. In the ONC Cures Act Final Rule (at 85 FR 25957) and the current Code of Federal Regulations, the text of § 171.202(a)(2)(iii), (iv), and (v) cross-

references paragraphs (a)(1) and (2) of § 171.202 instead of paragraphs (a)(2)(i) and (ii) when referencing a person who is the subject of EHI in defining the term “individual.” We proposed to make a technical correction to cross-references within the text of § 171.202(a)(2)(iii), (iv), and (v) to accurately cross-reference paragraph (a)(2)(i), (a)(2)(ii), or both, as applicable.

Paragraph (a)(2) of the current § 171.202 defines the term “individual” in part by referring to its definition in 45 CFR 160.103. In § 171.202(a)(2)(i), we cross-referenced to the definition of “individual” as defined in the HIPAA Privacy Rule at 45 CFR 160.103. In § 171.202(a)(2)(ii), we provided a second definition: “any other natural person who is the subject of the electronic health information being accessed, exchanged, or used.”
17

Then, in (a)(2)(iii), (iv), and (v), we expanded on those two definitions in order to include persons legally acting on behalf of such individuals or their estates in certain circumstances. However, the current text of § 171.202(a)(2)(iii), (iv), and (v) incorrectly referenced a “person described in paragraph (a)(1) or (2) of this section” instead of referencing a “person described in paragraph (a)(2)(i) or (ii) of this section.”

17
The definition of “person” for purposes of 45 CFR part 171 is codified in § 171.102 and is, by cross-reference to 45 CFR 160.103, the same definition used for purposes of the HIPAA Privacy Rule. The § 160.103 definition of “person” clarifies the meaning of “natural person” within it. We use “natural person” with that same meaning in § 171.202(a)(2) and throughout this discussion of § 171.202(a)(2). Consistent with the § 171.102 definition of “person” by cross-reference to the definition of “person” in 45 CFR 160.103, “natural person” in context of the information blocking regulations means “a human being who is born alive.”

The ONC Cures Act Final Rule preamble demonstrates our intent for the definition of “individual” in paragraph (a)(2) of § 171.202. Citing the ONC Cures Act Proposed Rule at 84 FR 7526, we stated in the ONC Cures Act Final Rule preamble (85 FR 25846 through 25847) that “the term `individual' encompassed any or all of the following: (1) An individual defined by 45 CFR 160.103; (2) any other natural person who is the subject of EHI that is being accessed, exchanged or used; (3) a person who legally acts on behalf of a person described in (1) or (2), including as a personal representative, in accordance with 45 CFR 164.502(g); or (4) a person who is a legal representative of and can make health care decisions on behalf of any person described in (1) or (2); or (5) an executor or administrator or other person having authority to act on behalf of the deceased person described in (1) or (2) or the individual's estate under State or other law.” Further, still referencing the ONC Cures Act Proposed Rule preamble, we wrote at 85 FR 25845 that “(3) encompasses a person with legal authority to act on behalf of the individual, which includes a person who is a personal representative as defined under the HIPAA Privacy Rule.” The paragraph designated as “(a)(3)” in the ONC Cures Act Proposed Rule at 84 FR 7602 and referenced simply as “(3)” in the discussion at 85 FR 25845 was designated as (a)(2)(iii) in § 171.202 as finalized at 85 FR 25957 and currently codified.

We stated in the HTI-2 Proposed Rule (89 FR 63620) that the quotes from the ONC Cures Act Final Rule preamble above demonstrate a consistent intention across the ONC Cures Act Proposed and Final Rules to cross-reference in the paragraphs finalized (at 85 FR 25957) and codified in § 171.202 as (a)(2)(iii), (iv), and (v) the paragraphs finalized and codified in § 171.202(a)(2)(i) and (ii). Accordingly, we proposed the technical correction in the revised text of 45 CFR 171.202 (89 FR 63803) to reflect the correct reading and intent (89 FR 63620).

In drafting our proposed technical correction to § 171.202(a)(2), we determined that the cross-reference to (a)(2)(ii), a natural person who is the subject of the EHI being exchanged
other than
an individual as defined in 45 CFR 160.103, is not needed in describing (in (a)(2)(iii)) a person acting as a personal representative in making decisions related to health care specifically in accordance with 45 CFR 164.502(g) (89 FR 63620 to 63621). As we explained in the HTI-2 Proposed Rule (89 FR 63621), this is because 45 CFR 164.502(g) pertains to personal representatives of individuals as defined in 45 CFR 160.103 (persons who are the subject of PHI) under the HIPAA Privacy Rule. A person described in (a)(2)(i) is an individual as defined in 45 CFR 160.103 for purposes of the HIPAA Privacy Rule.
18

However, (a)(2)(ii) describes “any
other
natural person who is the subject of the EHI being accessed, exchanged, or used” (emphasis added) rather than an “individual” who is the subject of PHI under the HIPAA Privacy Rule. Such
other
person (described in (a)(2)(ii)) would not have a person who is a “personal representative” specifically in accordance with the 45 CFR 164.502(g) provisions pertaining to “personal representatives” under the HIPAA Privacy Rule. Therefore, we proposed to strike the unnecessary reference to § 171.202(a)(2)(ii) (a subject of EHI who does
not
meet the 45 CFR 160.103 (HIPAA Privacy Rule) definition of “individual”) from the § 171.202(a)(2)(iii) description of a person who acts as a personal representative specifically in accordance with the HIPAA Privacy Rule provisions in 45 CFR 164.502(g). By striking an unnecessary cross-reference, the proposal would simplify the regulatory text without changing what the § 171.202(a)(2) definition of “individual” means or how it applies in practice.

18
In the second sentence that begins on page 89 FR 63621 in the HTI-2 Proposed Rule, the reference to “45 CFR 170.103” instead of “45 CFR 160.103” was a typographical error. Other references to the HIPAA Privacy Rule's definition of “individual” in the HTI-2 Proposed Rule correctly reference 45 CFR 160.103, including the reference in the first sentence of the paragraph in which the “45 CFR 170.103” typographical error appears. In this summary of our explanation at 89 FR 63620 through 63621, we have used the correct reference (45 CFR 160.103) rather than reproducing the error that appeared at 89 FR 63621.

Comments.
We received two comments stating support for the proposal and none opposing. We received one comment questioning whether “personal representative” (§ 171.202(a)(iii)) is different from “legal representative” (§ 171.202(a)(iv)) and requesting that we provide an example of someone who is not a personal representative under § 171.202(a)(2)(iii) but is a legal representative who can make health care decisions under § 171.202(a)(2)(iv). This comment stated that the clarification would be useful to all actors.

Response.
We appreciate commenters taking the time to provide feedback on this proposal. Having reviewed and considered all comments received on the § 171.202(a)(2) technical correction, we have finalized it as proposed.

We also appreciate the opportunity to explain again the difference between a “personal representative” (§ 171.202(a)(iii)) and a “legal representative” (§ 171.202(a)(iv)). As explained in the ONC Cures Act Final Rule (85 FR 25847), “§ 171.202(a)(2)(iii) encompasses only a person who is a personal representative as defined under the HIPAA Privacy Rule.” As revised by this final rule, that subparagraph reads, in its entirety: “A person who legally acts on behalf of a person described in paragraph (a)(2)(i) of this section in making decisions related to health care as a personal representative, in accordance with 45 CFR 164.502(g).” Thus, § 171.202(a)(iii) refers specifically, and only, to a person who is a “personal representative”

consistent with 45 CFR 164.502(g).
19

We refer readers interested in learning more about personal representatives under the HIPAA Privacy Rule to 45 CFR 164.502(g), 45 CFR 164.524, and to guidance provided in the OCR section of the Department's official website,
HHS.gov.
20

19
45 CFR 164.502(g) sets forth the HIPAA Privacy Rule's “personal representative” standard and implementation specifications.

20

https://www.hhs.gov/hipaa/for-professionals/privacy/guidance/personal-representatives/index.html

We distinguish a “personal representative” under the HIPAA Privacy Rule (specifically, consistent with 45 CFR 164.502(g)) from all other persons who are
legal
representatives and who can make health care decisions on behalf of the individual who is the subject of EHI (whether or not that EHI is also PHI). We include reference to § 171.202(a)(i) in § 171.202(a)(iv) because—in limited circumstances as permitted under State law, or Tribal law where applicable—a family member may be the
legal
representative to act on behalf of a patient to make health care decisions in emergency situations even if that family member may not be the “personal representative” of the individual in accordance with 45 CFR 164.502(g).

Comments.
We received several comments requesting that we clarify how or where the HTI-2 Proposed Rule treats an actor that is a covered entity differently than an actor that is not a covered entity.

Response.
It is not clear whether these comments refer to all or only some of the information blocking enhancement proposals in the HTI-2 Proposed Rule (89 FR 63616 through 63643 and 89 FR 63802 through 63805). Therefore, to ensure it is easy for readers to map our answer to each of the proposals finalized in this rule, we summarize and respond to these comments in context of each of the enhancements finalized in this final rule.

The definition of “individual” in § 171.202(a)(2) applies for purposes of all of the sub-exceptions (paragraphs (b), (c), (d), and (e)) of the Privacy Exception (§ 171.202). This definition explicitly includes both “individuals” as defined in 45 CFR 160.103 (§ 171.202(a)(2)(i)) and “any other natural person who is the subject of the electronic health information being accessed, exchanged, or used”
21

(§ 171.202(a)(2)(ii)). Thus, the definition of “individual” is constructed to account for both § 171.102 “actors” who are, and § 171.102 “actors” who are not, subject to the HIPAA regulations in 45 CFR parts 160, 162, and 164.

21
The definition of “person” for purposes of 45 CFR part 171 is codified in § 171.102 and is, by cross-reference to 45 CFR 160.103, the same definition used for purposes of the HIPAA Privacy Rule. The § 160.103 definition of “person” clarifies the meaning of “natural person” within it. We use “natural person” with that same meaning in § 171.202(a)(2) and throughout this discussion of § 171.202(a)(2). Consistent with the § 171.102 definition of “person” by cross-reference to the definition of “person” in 45 CFR 160.103, “natural person” in context of the information blocking regulations means “a human being who is born alive.”

Comments.
We received several comments requesting or recommending that we clarify or reaffirm what “natural person” means when used in defining “individual” or “patient” for purposes of the information blocking regulations.

Response.
Although the comments requesting clarification of what “natural person” means within the definition of “individual” did not specifically connect the request to the Privacy Exception, § 171.202(a)(2) is the only place in 45 CFR part 171 where we have codified a definition of the word “individual.” That definition includes at § 171.202(a)(2)(ii) “any other natural person who is the subject of the electronic health information being accessed, exchanged, or used.” Therefore, we believe responding to comments requesting clarity or confirmation of what “natural person” means within the definition of “individual” in context of the technical correction to § 171.202(a)(2) will make it easier for actors to find when they need it to understand and, if they choose to, apply the Privacy Exception (§ 171.202).

Consistent with the § 171.102 definition of “person” by cross-reference to the definition of “person” in 45 CFR 160.103, “natural person” in context of the information blocking regulations means “a human being who is born alive.” In 2002, Congress enacted 1 U.S.C. 8, which defines “person,” “human being,” “child,” and “individual.” The statute specifies that these definitions shall apply when determining the meaning of any Act of Congress, or of any ruling, regulation, or interpretation of the various administrative bureaus and agencies of the United States. When used in any definition of “patient” outlined in 45 CFR part 171, the term “natural person” has the same meaning that it has within the definition of “person” in § 171.102, and in the definition of “individual” in § 171.202(a)(2)(ii), which is a human being who is born alive. The term “patient” was included in the proposed Protecting Care Access Exception (§ 171.206), which is finalized in this final rule. We therefore address other comments regarding the meaning of “patient” in the context of § 171.206 in the section of this rule's preamble that is specific to the Protecting Care Access Exception.

b. Privacy Sub-Exception—Individual's Request Not To Share EHI

In the HTI-2 Proposed Rule, we proposed to slightly modify the header of § 171.202(e) for ease of reference to “individual's request not to share EHI” (89 FR 63622). More importantly, we proposed to revise the sub-exception to remove a limitation that applied the exception only to individual-requested restrictions on EHI sharing where the sharing is not otherwise required by law. Thus, we proposed to extend the availability of the § 171.202(e) sub-exception to an actor's practice of implementing restrictions the individual has requested on the access, exchange, or use of the individual's EHI even when the actor may have concern that another law or instrument could attempt to compel the actor to fulfill access, exchange, or use of EHI contrary to the individual's expressed wishes.

The original text and scope of 45 CFR 171.202(e) was established in 2020 by the ONC Cures Act Final Rule (85 FR 25642). When the sub-exception was established, health care providers and other actors did not raise explicit concerns regarding when they must comply with statutes, regulations, or instruments (such as subpoenas) issued under the laws of states in which they are not licensed, do not reside, and do not furnish care. In 2022, the Supreme Court decision in
Dobbs
v.
Jackson Women's Health Organization
overturned precedent that protected a federally protected constitutional right to abortion and altered the legal and health care landscape.
22

Since the Court's decision, across the United States, a variety of states have newly enacted or are newly enforcing restrictions on access to abortion and other reproductive health care. The Court's ruling—and subsequent state restrictions—have had far-reaching implications for health care beyond the effects on access to abortion.
23

22

See
142 S. Ct. 2228.

23

See
Melissa Suran, “Treating Cancer in Pregnant Patients After Roe v Wade Overturned,” JAMA (Sept. 29, 2022), (available at
https://jamanetwork.com/journals/jama/fullarticle/2797062#:~:text=The%20US%20Supreme%20Court,before%20cancer%20treatment%20can%20begin
), and Rita Rubin, “How Abortion Bans Could Affect Care for Miscarriage and Infertility,” JAMA (June 28, 2022), (available at
https://jamanetwork-com.hhsnih.idm.oclc.org/journals/jama/fullarticle/2793921?resultClick=1).
(URLs retrieved May 23, 2024.)

In light of the changing landscape and the limitation of § 171.202(e) as

established by the ONC Cures Act Final Rule (85 FR 25958), we noted in the HTI-2 Proposed Rule our concern that actors might deny or terminate an individual's requested restrictions on sharing their EHI specifically due to uncertainty about whether the actor is aware of and can account for any and all laws that might override the individual's requested restrictions (89 FR 63622). Due to that uncertainty, an actor who might otherwise be inclined to agree to an individual's request not to share their EHI could be concerned about potential information blocking implications of honoring the individual's requests in the face of demands for disclosure that
might
ultimately be enforced in a court of competent jurisdiction. In particular, as we noted at 89 FR 63622, we were and are concerned that actors may be unwilling to consider granting individuals' requests for restrictions to sharing their EHI, or may prematurely terminate some or all requested restrictions, based on uncertainty as to whether information blocking penalties or appropriate disincentives might be imposed if the actor ultimately is required by another law to disclose the information. For example, we understand actors are concerned about potentially implicating the information blocking definition by delaying a disclosure of EHI pursuant to a court order that the actor is aware is being contested, so that the actor can wait to see if the order will, in fact, compel the actor to make EHI available for access, exchange, or use contrary to the individual's request for restrictions to which the actor had agreed consistent with § 171.202(e). Accordingly, we proposed to remove the “unless otherwise required by law” limitation from § 171.202(e) to help address actors' uncertainty about various state laws' applicability as they relate to information blocking (89 FR 63622).

We explained in the HTI-2 Proposed Rule (89 FR 63622) that the proposed revision to § 171.202(e) could serve as a useful complement to the Precondition Not Satisfied sub-exception (§ 171.202(b)). We also noted in the HTI-2 Proposed Rule, and reaffirm here, that the § 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 one or more preconditions has not been satisfied for the access, exchange, or use to be permitted under applicable Federal, State, or Tribal laws. For actors' and other interested parties' clarity regarding the relationship between paragraphs (b) and (e) of § 171.202, we now also note that each sub-exception under the Privacy Exception (§ 171.202) stands alone and operates independently of each other sub-exception. Thus, an actor's practice that fully meets the requirements of
any one
sub-exception (paragraph (b), (c), (d), or (e) of § 171.202) need not also satisfy any other sub-exception (any other of paragraphs (b) through (e) within § 171.202) in order to be covered by the Privacy Exception (§ 171.202).

We noted in the HTI-2 Proposed Rule that the proposed revision to § 171.202(e) would not operate to override other law compelling disclosure against the individual's wishes (89 FR 63622). The revision is intended to offer actors who elect to honor an individual's requested restrictions certainty that applying those restrictions will not be considered information blocking so long as the actor's practices in doing so satisfy the requirements of the § 171.202(e) sub-exception. Whether any other law in fact applies to any given actor and compels production of any EHI (or other data) is beyond the scope of this final rule.

If a law requires a particular actor to fulfill a request to access, exchange, or use EHI without the individual's authorization, permission, or consent, the actor might be compelled to comply with that law independent of the information blocking statute and 45 CFR part 171. This has been the case since the first eight information blocking exceptions were finalized in the ONC Cures Act Final Rule (85 FR 25642) and will continue to be the case despite the revision to § 171.202(e) proposed in the HTI-2 Proposed Rule (89 FR 63622 and 63803) and finalized in this final rule.

We reiterate here for emphasis the reminder we included in the HTI-2 Proposed Rule (89 FR 63622) that HIPAA covered entities and business associates must comply with the HIPAA Privacy Rule, including privacy protections in the “HIPAA Privacy Rule to Support Reproductive Health Care Privacy” final rule (89 FR 32976, April 26, 2024) (2024 HIPAA Privacy Rule) and any other applicable Federal laws that govern the use of EHI. For example, an actor's practice likely to interfere with an individual's access, exchange, or use of EHI (as defined in 45 CFR 171.102) might satisfy an information blocking exception without complying with the actor's separate obligations under 45 CFR 164.524 (HIPAA Privacy Rule's individual right of access). In such cases, an actor that is a HIPAA covered entity or business associate would be subject to penalties for violating the HIPAA Privacy Rule.

Comments.
The overwhelming majority of comments supported the proposed revisions to § 171.202(e) and provided multiple reasons for their support. Many commenters specifically agreed with our reasoning that in the current environment, actors may be unwilling to consider granting individuals' requests for restrictions on sharing of their EHI, or may prematurely terminate requested restrictions, due to uncertainty about whether laws might exist that would override the individual's requested restrictions and fear of resulting information blocking penalties or appropriate disincentives.

Several commenters stated that the proposed revisions will offer meaningful protections against criminalization risks faced by patients and give greater certainty to health care providers who otherwise might deny an individual's requested restrictions on sharing their EHI due to uncertainty about laws that could supersede these requests. Several commenters specifically highlighted uncertainty regarding potential legal risks related to reproductive health care as reasons for supporting the proposed revisions. Several commenters stated that the proposed revisions will give physicians and other actors the confidence to delay the disclosure of EHI in accordance with this sub-exception when they are aware that a court order is being contested. One commenter noted that currently, confusion and concern about withholding EHI at the request of a patient due to a contested court order leads physicians and other actors to disclose EHI against a patient's wishes out of fear of information blocking accusations or penalties.

Several commenters stated that the proposed revisions would benefit actors by reducing information blocking compliance burdens, noting that the proposed revisions reduce burden and costs by simplifying the analysis of whether the sub-exception is applicable. One commenter also stated that the proposed revisions are needed to align with the proposed Protecting Care Access Exception given the variability regarding what information must be disclosed in connection with reproductive health care services in different jurisdictions. Some commenters stated that the proposed revisions would provide actors with greater flexibility in managing EHI sharing. Additionally, commenters stated that clarifying the applicability of various laws related to information blocking through the proposed revisions

will protect patients and physicians, encourage the use of health IT, and support care coordination.

Several commenters in support of the proposed revisions stressed that the revisions would help maintain and strengthen a patient's ability to trust their providers and would improve the patient-provider relationship, as patients and providers would be empowered to discuss and determine the level of risk a patient is willing to take. Commenters stated that patient preferences should always be the priority when providers are faced with an EHI disclosure request. One commenter noted the proposed revisions balance ensuring patient autonomy over their EHI while upholding existing legal frameworks for EHI disclosure.

Response.
We appreciate the many comments in favor of the proposed revisions to § 171.202(e) and recognition of the benefits that we outlined in the HTI-2 Proposed Rule (89 FR 63622). Having reviewed and considered all comments received relevant to this sub-exception, we have finalized the revision to the Privacy sub-exception “individual's request not to share EHI” in § 171.202(e) as proposed in the HTI-2 Proposed Rule (89 FR 63803).

Comments.
Several commenters expressed concerns about potential unintended legal consequences for actors who restrict the sharing of EHI under the information blocking regulations when it is contrary to an existing law. These commenters generally did not support the proposed revisions and recommended that ASTP/ONC maintain the existing limitation allowing the use of this sub-exception unless disclosure is required by law. One commenter stated that not allowing reliance on this sub-exception when the disclosure is required by law would align the sub-exception with HIPAA and thus reduce complexity for actors and serve public policy since restricting the sharing of EHI could adversely affect patient care in cases such as emergency treatment.

Response.
We appreciate these comments and reiterate that the finalized revisions to § 171.202(e) do not override other laws compelling disclosure against the individual's wishes, as we noted when we proposed them (89 FR 63622). As we stated in the HTI-2 Proposed Rule, where there may be a law requiring a particular actor to fulfill a request to access, exchange, or use EHI without the individual's authorization, permission, or consent, the actor might be compelled to comply with that law independent of the information blocking statute (section 3022 of Title XXX of the PHSA) and 45 CFR part 171 (89 FR 63622).

Knowing that the exception does not override any other law(s) with which an actor knows they must comply, any actor can choose to honor an individual's request to the extent that they are able under such law(s) and can choose how to communicate to the individual the limits of the actor's ability to honor that request under such law(s). For example, an actor that is also required to comply with the HIPAA Privacy Rule with respect to an individual's information could choose to agree to honor requests for restrictions on disclosures of PHI that the HIPAA Privacy Rule does not require (see 45 CFR 164.502(a)(2) “Covered entities: Required disclosures”). Such an actor could also choose how to communicate to an individual that the actor is able to honor the request for restrictions only to the extent that the restrictions do not prevent the actor from disclosing PHI as required under 45 CFR 164.502(a)(2).

The § 171.202(e) sub-exception applies to requests that an actor chooses to honor and that the HIPAA Privacy Rule
permits
(but does not
require
) the actor to honor, as well as to scenarios where the actor is not required to comply with the HIPAA Privacy Rule. We remind readers that where an actor that is subject to the HIPAA Privacy Rule is required to agree to an individual's requested restriction on use or disclosure of PHI that is also EHI, such as where 45 CFR 164.522(a)(1)(ii) and (vi) applies, the actor's agreeing to and applying such restrictions is “required by law.”
24

The revisions to § 171.202(e) finalized in this rule are intended to address concerns of actors who are worried about potential implications specific to the information blocking regulations (45 CFR part 171) of attempting to honor an individual's request (that they want to agree to honor) in the face of uncertainty about whether some statute they are not certain is applicable, or some other legally enforceable mandate (such as a contested court order), may or may not ultimately compel them to make EHI available for access, exchange, or use.

24
Where applicable law prohibits a specific access, exchange, or use of information, the information blocking regulations consider the practice of complying with such laws to be “required by law.” Practices that are “required by law” are not considered “information blocking” (
see
the statutory information blocking definition in section 3022(a)(1) of the PHSA and the discussion in the HTI-1 Final Rule at 89 FR 1351 and in the ONC Cures Act Final Rule at 85 FR 25794).

Regarding potential adverse impacts of restricted sharing based on the individual's request that some or all of their EHI not be shared for certain or any purpose(s), it is important to recognize that the sub-exception is not intended to create an affirmative obligation on the part of any actor to agree to honor any particular individual request(s) that the individual's EHI not be shared to the full extent permitted by applicable law (HIPAA Privacy Rule, other Federal law that may apply such as 42 CFR part 2, or, where applicable, State or Tribal laws). Moreover, as we explained when we originally finalized this sub-exception in the ONC Cures Act Final Rule, we recognize that an individual's requested restriction may need to be compromised in emergency treatment situations and therefore we provided for the ability of an actor to terminate an individual's requested restriction under limited circumstances (85 FR 25859). We did not propose, nor have we finalized, any revisions to the termination provisions of this sub-exception in § 171.202(e)(4).

Comments.
Several commenters expressed concerns that the proposed revisions to § 171.202(e) may undermine information sharing and interoperability of EHI as well as inhibit sharing for treatment and other allowable purposes. One commenter provided examples to illustrate the concern, including: if a patient requests that EHI from a visit with a specialist be restricted from their primary care provider; restricting EHI needed for coordinated care and safe medication management; and limiting the sharing of health information used for operational purposes such as teaching that are permitted under HIPAA.

Response.
We appreciate the opportunity to clarify why we do not agree that the proposed revisions to this exception would inhibit information sharing or interoperability of EHI on the whole. To satisfy the existing requirements in § 171.202(e)(3), which we did not propose to revise and have not revised in this final rule, the actor's practice must be implemented in a consistent and non-discriminatory manner. As we noted when we originally finalized the sub-exception in the ONC Cures Act Final Rule, this provides basic assurance that the practice is directly related to the risk of disclosing EHI contrary to the wishes of an individual and is not being used to interfere with access, exchange, or use of EHI for other purposes (85 FR 25857). We further noted that this condition requires that the actor's privacy-protective practice must be based on objective criteria that apply uniformly for all substantially similar privacy risks (85 FR 25857).

Specific to concerns about an individual potentially requesting restrictions on EHI sharing that an actor believes would, if implemented, compromise the patient's health or care, we emphasize that the § 171.202(e) sub-exception, like all information blocking exceptions, is voluntary. Exceptions are intended to offer actors certainty that the practices in which they choose to engage consistent with the conditions of an exception will not be considered information blocking, but they are not intended to create, and do not create, an affirmative obligation for any actor to choose to engage in all of the practices that could potentially be covered by any given exception(s). If an actor is unwilling to agree to an individual's requested restrictions on sharing the individual's EHI for teaching or another permitted purpose, nothing in 45 CFR part 171 is intended to obligate the actor to honor the individual's request. We note, however, that an actor's practice to honor or decline individual requests for restrictions in a discriminatory manner—such as based on whether the individual's other health care provider(s) or those providers' health IT developer(s) were competitor(s) or affiliate(s) of the actor—would be inappropriate and could implicate the information blocking definition.

Comments.
Several commenters focused on minor patients' EHI and the applicability of the sub-exception in proxy situations. One commenter stated that it is important to consider who is making the request not to share EHI. The commenter noted that there may be times when the adolescent is making the request not to share information and times when the parent is making the request, stating that it would be helpful for ASTP/ONC to explicitly clarify that an adolescent's request not to share information is allowed under the sub-exception unless otherwise prohibited by State law. Another commenter stated that ASTP/ONC must ensure that providers have flexibility to address the confidentiality needs of minor patients and reflect specific state or local requirements, noting the variation in federal and state rules and regulations around parent/guardian access to adolescent data. Other commenters sought clarification that this sub-exception would apply to proxy consent situations.

Response.
We clarify that, as proposed (89 FR 63622) and finalized, the revisions to § 171.202(e) offer actors who elect to honor an individual's request not to share EHI certainty that applying the requested restrictions on sharing will not be considered information blocking so long as the actor's practices in doing so satisfy the requirements of the § 171.202(e) Privacy sub-exception. We did not propose, nor are we finalizing, any revisions to the requirements of the § 171.202(e) Privacy sub-exception that would categorically limit application of the sub-exception to only requests from individuals who are not unemancipated minors. Thus, it is possible that the exception could apply to some scenarios where a parent seeks access, exchange, or use of a non-emancipated minor's EHI when an actor has agreed to the request of the minor (as the individual as described in § 171.202(a)(2)(i) or (ii)) that the EHI not be made available to the minor's parents or other representatives. However, we remind actors and other interested parties that where an actor's practice meets the sub-exception's requirements, the revised § 171.202(e) Privacy sub-exception (like any Privacy sub-exception or any other exception codified in subparts B, C, or D of 45 CFR part 171), simply offers actors assurance that the practice will not constitute “information blocking” under 45 CFR part 171. We emphasize that the revisions to § 171.202(e) do not change how the HIPAA Privacy Rule, or other Federal, State, or Tribal law, applies to adults or minors. In various circumstances, one or more of such other laws may require disclosure of all of an unemancipated minor's health information to the minor's personal representative (consistent with 45 CFR 164.502(g)) or other legal representative as established by applicable law. We also refer readers to the information about how the HIPAA Privacy Rule applies to minors that can be found at 45 CFR 164.502(g) and on the OCR website.
25

We also note that revisions to § 171.202(e) do not change how any other Federal, State, or Tribal law applies to proxy requests. We stress that the revisions to § 171.202(e) do not override other law compelling disclosure against the individual's wishes, and whether courts will or should apply any particular Federal, State, or Tribal law to any actor to compel disclosure of any type of information to any requestor for any purpose is beyond the scope of this final rule.

25

See https://www.hhs.gov/hipaa/for-professionals/faq/personal-representatives-and-minors/index.html,

https://www.hhs.gov/hipaa/for-professionals/privacy/laws-regulations/index.html,
and
https://www.hhs.gov/hipaa/for-professionals/privacy/guidance/personal-representatives/index.html.

Comments.
A couple of commenters expressed concern that patients requesting restrictions on sharing of EHI may lack an understanding of the potential safety impact of not sharing complete health information with their other providers as well as the feasibility of the request to not share information. These commenters generally recommended that if finalized as proposed, ASTP/ONC should provide education on these issues for patients and other interested parties.

Response.
We reiterate that the § 171.202(e) Privacy sub-exception does not create an affirmative obligation for any actor to agree to any individual's request for restrictions on access, exchange, or use of the individual's EHI. Where no other applicable law
requires
the actor to agree to an individual's requested restriction, the actor would have discretion to discuss the potential implications of a requested restriction on the availability of information to the individual's other health care providers before agreeing to the request, to not agree to apply restrictions the actor believes introduce unacceptable risks to the patient's health or safety, and to explain to the individual why the actor will not honor the individual's request(s) to which the actor chooses not to agree. We reiterate, however, that if an actor's practice specific to granting individual requests for restrictions is implemented in an inconsistent or discriminatory manner, that practice would not meet the § 171.202(e)(3) requirements, would therefore not be covered by the Privacy Exception (§ 171.202), and could implicate the information blocking definition in § 171.103.

We also appreciate the opportunity to remind readers of our continued commitment to support EHI sharing consistent with patient preferences and applicable law. Whether received through the public comments process for a proposed rule or through informal channels, we appreciate the feedback and questions we receive. They help to inform our development of information resources that we make publicly available on
HealthIT.gov
. Informal channels include, for example, the Health IT Feedback and Inquiry Portal
26

that is available year-round and not tied to the comment period for a proposed rule.

26
To find the portal, please click, paste, or search
https://www.healthit.gov/feedback

Comments.
A couple of commenters expressed concern about the feasibility of actors implementing individuals' requested restrictions on the sharing of EHI, and some stated that the technology to operationalize segmentation of data does not exist. One commenter recommended that if revisions to the Privacy Exception are

finalized as proposed, ASTP/ONC should pursue certification program initiatives to create the needed technology. Another commenter recommended that ASTP/ONC help ensure that operationalizing data segmentation is an immediate priority for health IT developers by offering financial incentives for developers enabling restrictions on sharing of EHI.

Response.
We appreciate these comments regarding segmentation technology relevant to circumstances where an actor may wish to agree to an individual's request that only some of the individual's EHI not be shared. In proposing to revise § 171.204(e), we recognized the importance of data segmentation technology for exchanging sensitive health data and enabling access, exchange, and use of EHI (89 FR 63634). We also noted our awareness of the limitations of current health IT capabilities for data segmentation and of external efforts to develop technical standards that over time may result in increasingly advanced data segmentation capabilities in EHR systems and other health IT (89 FR 63634). These statements are also relevant in the context of the § 171.202(e) Privacy sub-exception and an actor's practice of implementing restrictions requested by an individual on the access, exchange, or use of the individual's EHI. As we indicated in the HTI-1 Final Rule (89 FR 1301), we continue to encourage and engage with industry and standards development community efforts to advance standards supporting privacy workflows and to monitor the continued evolution of relevant standards to consider in new or revised criteria in future rulemaking. In the HTI-1 Final Rule, we specifically discussed the HL7 data segmentation for privacy (DS4P) implementation guides (89 FR 1301). It is not clear from the comments we received what mechanism(s) the commenters may have envisioned ASTP/ONC using to make data segmentation innovation and advancement an immediate priority for health IT developers, or to offer financial incentives to developers.

In the HTI-1 Proposed Rule, we made several proposals related to the ONC Health IT Certification Program to support additional tools for implementing patient requested privacy restrictions. We proposed a new certification criterion in § 170.315(d)(14), an addition to ASTP/ONC's Privacy and Security Framework under the Program in § 170.550(h), and a revision to an existing “view, download, and transmit to 3rd party” certification criterion in § 170.315(e)(1) (88 FR 23822 through 23824). We sought public comment on these proposals—the new criterion in § 170.315(d)(14), the inclusion of the request capability for patients in § 170.315(e)(1), and the requirements with the Privacy and Security Framework in § 170.550(h)—both separately and as a whole. We specifically sought comment on the feasibility of each part in terms of technical implementation and usefulness for patients and covered entities using these capabilities. We proposed and sought comment on several alternatives which would add standards to the proposed new certification criterion and would specifically leverage HL7 DS4P IGs for the new certification criterion in § 170.315(d)(14). We also proposed and sought comment on alternate proposals that looked exclusively at the HL7 Privacy and Security Healthcare Classification System (HCS) Security Label Vocabulary within the HL7 DS4P IGs for a source taxonomy for the “flag” applied to the data (88 FR 23822). We sought comment on the health IT development burden associated with implementation of the capabilities including for the individual certification criterion referenced in the Privacy and Security Framework in § 170.550(h). As noted in the HTI-1 Final Rule, we also expressed our concerns about feasibility, timelines, and the overall complexity of the workflows and the related capabilities associated with this right as well as our intent to propose several options for consideration by the health care and health IT communities (89 FR 1301). We refer readers to the HTI-1 Final Rule for discussion of these proposals and of public comments received in response to the primary and alternative proposals we made specific to functionalities supporting individuals' requests for restrictions (89 FR 1298 through 1305).

The
segmentation
condition (§ 171.204(a)(2)) of the Infeasibility Exception specifies a condition
27

under which an actor who is not able to segment EHI that the actor must
28

or may have chosen to withhold
29

from other EHI that the actor could share with a requestor (or various requestors) for permissible purposes can ensure that not fulfilling a request to access, exchange, or use the requested EHI is not information blocking. The § 171.204(a)(2)
segmentation
condition has applied, since it was established in the ONC Cures Act Final Rule (85 FR 25867 and 25958), where the actor cannot fulfill a request for access, exchange, or use of EHI because the actor cannot unambiguously segment the requested EHI from EHI that cannot be made available due to an individual's preference, cannot be made available by law, or that may be withheld in accordance with § 171.201.

27
The actor would still need to meet the requirements of § 171.204(b) for the Infeasibility Exception to apply.

28
An example of when an actor must withhold EHI would be if an individual chose not to give consent that is a pre-requisite for a particular access, exchange, or use to be permissible under applicable State or Tribal law.

29
An example of when an actor may have chosen to withhold EHI would be if an actor chose to agree to an individual's request that the individual's EHI not be shared.

In the HTI-2 Proposed Rule, we proposed to explicitly reference the entire § 171.202 Privacy sub-exception in our revisions to § 171.204(a)(2) and noted that this would ensure that the
segmentation
condition would continue to apply where the actor cannot segment EHI which the actor has chosen to withhold in honoring an individual's request not to share EHI consistent with § 171.202(e) (89 FR 63623). In another section of this final rule preamble, we discuss the revisions we have finalized to § 171.204(a)(2), including a reference to the entire § 171.202 Privacy sub-exception in § 171.204(a)(2)(ii). We also refer readers to the discussion in the HTI-1 Final Rule of how “stacking” of exceptions may occur where an actor may wish to engage in one or more practice(s) that are covered in part, but not fully covered, by one exception (such as the Privacy Exception). The HTI-1 Final Rule discussion (89 FR 1353 and1354) includes an illustrative example where the actor has elected to grant an individual's request consistent with § 171.202(e).

Comments.
A couple of commenters expressed a need for clarification on how the proposed revisions to this sub-exception work. These commenters asked for examples of use cases and urged ASTP/ONC to develop comprehensive guidance to ensure actors understand when and how the sub-exception applies. One commenter recommended that ASTP/ONC work across agencies and with other parties, including payers, to provide more clarity around the sub-exception to help ensure it is not overinterpreted or used to limit sharing of EHI unnecessarily. Specific areas where clarity was requested included standards for segmenting clinical data, differences in clinical versus claim codes, how third-party, non-HIPAA regulated entities can be held to standards, including standards required under TEFCA, and how entities can rely on the stated purpose of the information request.

Response.
We appreciate the comments and offer the following use

cases as illustrative examples, while reminding readers that this is
not
an exhaustive list. The revised § 171.202(e) Privacy sub-exception could also be met in other scenarios (use cases) not specifically discussed here.

One use case where the revised § 171.202(e) Privacy sub-exception is intended to apply is where an actor is concerned about implicating the information blocking definition by delaying a disclosure of EHI pursuant to a court order that the actor is aware is being contested (89 FR 63622). In this use case, the actor could choose to meet the requirements of the revised Privacy sub-exception in § 171.202(e) in order to have assurance that it will not be “information blocking” to delay release of EHI in compliance with an individual's request for restrictions while waiting to see if the order will eventually compel the actor to make EHI available for access, exchange, or use contrary to the individual's request for restrictions to which the actor had agreed consistent with § 171.202(e).

Another use case to which the revised § 171.202(e) Privacy sub-exception would apply is where an actor is inclined to grant an individual's request for restrictions but is uncertain whether other authority might compel the actor to provide access, exchange, or use of EHI despite the individual's wishes and is concerned about potentially implicating the information blocking definition if, after granting the request, the actor learns of or confirms that such other authority compels provision of access, exchange, or use of EHI contrary to the individual's expressed wishes. (We discussed this use case, in explaining the need for this revision, in the HTI-2 Proposed Rule at 89 FR 63622). In this use case, an actor could choose to meet the requirements of the revised Privacy sub-exception in § 171.202(e) and have assurance that honoring the individual's request and applying those restrictions in the interim or for other requestors will not be considered information blocking even if other law ultimately compels disclosure to specific requestor(s) (for permissible purposes)
30

against the individual's wishes.

30
For purposes of the information blocking regulations (45 CFR part 171), “permissible purpose” is defined in § 171.102. Notably, the § 171.102 definition of “permissible purpose” would
not
apply to a purpose for which access, exchange, or use of EHI is prohibited by Federal or, where applicable, State or Tribal law. Examples of such federal law prohibitions are not limited to but do include the HIPAA Privacy Rule's prohibition of the use and disclosure of genetic information for underwriting purposes (45 CFR 164.502(a)(5)(i) and the HIPAA Privacy Rule's prohibition of using or disclosing reproductive health care information for the activities identified in 45 CFR 164.502(a)(5)(iii)(A)(
1
)-(
3
) (subject to paragraphs (B) and (C) of 45 CFR 164.502(a)(5)(iii)).

However, we reiterate that a practice satisfying the conditions and requirements to be covered by any exception to the information blocking definition simply means HHS will not consider the practice to be “information blocking” under 45 CFR part 171 or the information blocking statute (PHSA section 3022). We emphasize, again, that the revisions to § 171.202(e) do not operate to override other law compelling disclosure against the individual's wishes, and if a court with jurisdiction over the actor and subject matter enforces, via court order, a law that requires a particular actor to fulfill access, exchange, or use of EHI without the individual's authorization, permission, or consent, the actor would be compelled to comply with that law independent of the information blocking statute and 45 CFR part 171.

The specific requests for clarity on segmentation standards, other standards-related issues, TEFCA, and reliability of information requests are beyond the scope of the proposal to revise § 171.202(e). We refer readers to our official website,
HealthIT.gov
, for more information on the ONC Health IT Certification Program, TEFCA, and a wide variety of other health IT topics in addition to information blocking and note that we continue to work alongside federal partners and other interested parties, including providers and payers, to serve as a resource to the entire health system in support of the adoption of health information technology and the promotion of nationwide, standards-based health information exchange to improve health care.

Comments.
A couple of commenters expressed concern that not sharing EHI could be a default position for actors and stated that sharing of data in the spirit of the information blocking rules should be the default position. These commenters sought clarification that an actor must receive a specific request from an individual in order to trigger this exception.

Response.
An actor's practice of honoring an individual's request not to share EHI will be covered by the § 171.202(e) Privacy sub-exception only so long as the practice satisfies the requirements found in § 171.202(e)(1)-(4). The requirements in § 171.202(e)(1)-(4), to which we did not propose changes and have made no changes, include that “the individual requests that the actor not provide such access, exchange, or use of electronic health information without any improper encouragement or inducement of the request by the actor” (§ 171.202(e)(1)). We also remind readers that the term “individual” is defined for purposes of the Privacy Exception in § 171.202(a), as discussed in this final rule.

We appreciate the opportunity to emphasize that the revised § 171.202(e) Privacy sub-exception remains specific to restrictions an individual requests and that are applied on an individual basis. We emphasize that in order to be covered by the § 171.202(e) Privacy sub-exception, an actor's practice of restricting the access, exchange, or use of any individual's EHI must be triggered by a request consistent with § 171.202(e)(1) from the individual (as described in § 171.202(a)(2)(i) and (ii)) or their representative (as described in § 171.202(a)(2)(iii) or (iv)) or a person having authority to act on behalf of a deceased person (as described in § 171.202(a)(2)(v)).

Comments.
Several commenters requested that we clarify how or where the HTI-2 Proposed Rule treats an actor that is a covered entity differently than an actor that is not a covered entity.

Response.
It is not clear whether these comments refer to all or only some of the information blocking enhancement proposals discussed in the HTI-2 Proposed Rule (89 FR 63616). Therefore, to ensure it is easy for readers to map our answer to each of the proposals finalized in this rule, we summarize and respond to these comments in the context of each of the enhancements finalized in this final rule.

The § 171.202(e) (individual's request not to share EHI) sub-exception is applicable to any actor's practice that meets its requirements. The § 171.202(e) sub-exception is available, and all of its requirements apply equally, to any actor's practice without regard to whether the actor also happens to be a HIPAA covered entity or business associate.

Please see our additional responses addressing these comments in other sections of this final rule.

Comments.
Several comments received were beyond the scope of the proposed revisions to the sub-exception. One commenter commented on the documentation provisions in § 171.202(e)(2), which we did not propose to revise. The commenter noted that the current language requires documentation of the request not to share EHI in a timely manner and stated that if an actor fails to do so, then the actor could be subject to an information blocking claim for not sharing the information and the individual requesting the restriction would suffer unintended consequences of an actor's

oversight. One commenter expressed concern about verbal requests, which were not an aspect of the proposed revisions to § 171.202(e). Another commenter recommended that ASTP/ONC and the HHS Office of Inspector General begin investigations into information blocking no earlier than January 1, 2027, if the provider claims they are protected under the Privacy Exception, in order to give providers at least one year to integrate the new patient requested restrictions technology into their practices.

Response.
We appreciate these comments, however we did not propose or solicit comment on any potential revision(s) to the request provisions of § 171.202(e)(1), which do not mention verbal requests, or the documentation provisions of § 171.202(e)(2). We also did not propose to establish a moratorium on OIG investigating any claim of information blocking, or on ASTP/ONC reviewing potential non-conformities of ONC-Certified Health IT with ONC Health IT Certification Program (Program) requirements—such as a Program-participating developer's potential non-compliance with § 170.401 Information Blocking Condition and Maintenance of Certification requirements. We do not believe such moratorium is necessary. Like all other information blocking exceptions, the Privacy Exception and each of its sub-exceptions is
voluntary
and does not require an actor to deploy or use specific technology(ies) as a condition of a practice by the actor being covered by the exception.

We recognize that it may be easier or more efficient for an actor to engage in practices covered by some exceptions if they have more comprehensive or advanced technological capabilities than if they have only limited or outdated technological capabilities. For example, for an actor to conform practices to § 171.202(e) if they have efficient electronic workflows for receiving (or otherwise logging) individuals' requests that the individual's EHI not be shared, identifying whatever subset of such requests as applicable law(s) require the actor to honor,
31

and considering whether the actor is willing to agree to other individual-requested restrictions. However, as we have maintained since establishing the first eight exceptions in the ONC Cures Act Final Rule, “failure to meet the conditions of an exception does not automatically mean a practice constitutes information blocking” (85 FR 25649).
32

Although we encourage actors to voluntarily conform their practices to the conditions of an exception suited to the practice and its purpose, an actor's choice to do so simply provides them an enhanced level of assurance that the practices do not meet the definition of information blocking. If subject to an investigation by OIG, each practice that implicates the information blocking provision would be analyzed on a case-by-case basis (
see, e.g.,
85 FR 25842). Each information blocking case, and whether the actor's practice would meet all conditions of an exception, will depend on its own unique facts and circumstances (85 FR 25868). We refer any party interested in a short, easy-to-read explanation of how any claim or report of information blocking would be evaluated to the following FAQ available on ASTP/ONC's website, HealthIT.gov: “How would any claim or report of information blocking be evaluated?”
33

31
For example, an actor that is subject to the HIPAA Privacy Rule is required to agree to an individual's requested restriction on use or disclosure of PHI where 45 CFR 164.522(a)(1)(ii) and (vi) apply. (As noted earlier in this discussion, where that is the case and the PHI is also EHI, the actor's agreeing to and applying such restrictions we would consider to be “required by law.”)

32

See also, e.g.,
IB.FAQ29.2.2024APR: “If an actor does not fulfill a request for access, exchange, and use of EHI in “any manner requested” that they have the technical capability to support, is the actor automatically an information blocker unless they satisfy at least one of the information blocking exceptions?”

33
IB.FAQ46.1.2022FEB, FAQ-specific URL:
https://www.healthit.gov/faq/how-would-any-claim-or-report-information-blocking-be-evaluated
.

2. Infeasibility Exception Updates

In the ONC Cures Act Final Rule, we established the Infeasibility Exception (§ 171.204) (85 FR 25865 through 25870, and 85 FR 25958). Under the Infeasibility Exception, it is not considered information blocking if an actor, as defined in § 171.102, does not fulfill a request to access, exchange, or use EHI due to the infeasibility of the request, provided the actor satisfies the § 171.204(b)
responding to requests
condition and any one of the conditions in § 171.204(a).

In the HTI-1 Final Rule (89 FR 1373 through 1387 and 1436), we finalized the following revisions to § 171.204:

• clarification of the § 171.204(a)(1)
uncontrollable events
condition requirement that the uncontrollable event must have an actual negative impact on an actor's ability to fulfill EHI access, exchange, or use in order for
uncontrollable events
condition to apply;

• addition of two new conditions (
third party seeking modification use
and
manner exception exhausted,
respectively subparagraphs (3) and (4)) under paragraph (a); and

• renumbering the
infeasible under the circumstances
condition from § 171.204(a)(3) to § 171.204(a)(5).

However, in the HTI-1 rulemaking, we did not change the substance of the
infeasible under the circumstances
condition (now codified in § 171.204(a)(5)) or the § 171.204(a)(2)
segmentation
condition, and we did not make any changes to § 171.204(b). In the HTI-2 Proposed Rule (89 FR 63623), we proposed to modify:

• the § 171.204(a)(2)
segmentation
condition as described in the HTI-2 Proposed Rule (89 FR 63623 through 63624);

• the § 171.204(a)(3)
third party seeking modification use
condition as described in the HTI-2 Proposed Rule (89 FR 63624 through 63625); and

• the § 171.204(b)
responding to requests
condition as discussed in the HTI-2 Proposed Rule (89 FR 63625 through 63627).

In this final rule, we have finalized modifications to the § 171.204(a)(2)
segmentation
condition of the Infeasibility Exception. We do not address in this final rule our HTI-2 Proposed Rule proposals to revise § 171.204(a)(3) and (b). We may address in a future final rule revisions to the Infeasibility Exception that we do not address in this final rule.

In the HTI-2 Proposed Rule, we explained that the § 171.204(a)(2)
segmentation
condition applies where the actor is not able to fulfill a request for access, exchange, or use of EHI specifically because the actor cannot unambiguously segment from other requested EHI the EHI that cannot be made available by law or due to an individual's preference, or that may be withheld in accordance with § 171.201 (89 FR 63623). We noted that in practice, “by law or due to an individual's preference” would include situations where: an actor has chosen to honor an individual's request for restrictions on sharing of some of the individual's EHI; an individual's authorization or consent is a pre-requisite for a particular use or disclosure of the individual's EHI to be lawful and the individual has not provided such authorization or consent; or law applicable in the circumstances of the request restricts sharing of the individual's EHI.

In the HTI-2 Proposed Rule (89 FR 63623 through 63624), we proposed updates to the
segmentation
condition to enhance clarity and certainty, and to provide for its application to additional situations. We proposed to update how the text of § 171.204(a)(2) describes why certain EHI cannot or will not be made available, including more specific cross-

references to relevant provisions within 45 CFR part 171.

In the HTI-2 Proposed Rule (89 FR 63623), we noted that the
segmentation
condition references EHI that cannot be made available due to an individual's preference or by law in § 171.204(a)(2)(i), and EHI that the actor may choose to withhold in accordance with the Preventing Harm Exception in § 171.204(a)(2)(ii). We proposed to revise the condition (§ 171.204(a)(2)) as follows: to focus subparagraph (i) on EHI that is not permitted by applicable law to be made available, and to explicitly cross-reference in subparagraph (ii) the proposed Protecting Care Access Exception (§ 171.206) and the existing Privacy Exception (§ 171.202) in addition to the existing Preventing Harm Exception (§ 171.201) (which currently has an explicit cross-reference).

We stated that focusing § 171.204(a)(2)(i) solely on EHI that an actor is not permitted by applicable law to make available for a requested access, exchange, or use will reinforce for actors and other interested persons that actors cannot make EHI available when applicable law, such as the HIPAA Privacy Rule or 42 CFR part 2, does not permit covered information to be made available (89 FR 63623). Under the revision we proposed of § 171.204(a)(2)(i), the
segmentation
condition would continue to apply as it does today when an actor cannot unambiguously segment EHI that, under applicable law, is permitted to be available to a particular person for a particular purpose from EHI that is not permitted to be available to that person for that purpose. We noted in the HTI-2 Proposed Rule that this would include situations where the actor cannot unambiguously segment EHI for which preconditions for permitting use or disclosure under the HIPAA Privacy Rule (or other applicable law) have not been met from EHI for which such preconditions have been met, as well as scenarios where use or disclosure of specific EHI for a particular purpose is prohibited by applicable law (89 FR 63623).

We explained that the proposed revision to § 171.204(a)(2) would retain in subparagraph (ii) the explicit reference to the Preventing Harm Exception (§ 171.201). Thus, we noted that the Infeasibility Exception's revised
segmentation
condition would continue to apply where the actor cannot unambiguously segment other EHI from EHI that the actor has chosen to withhold in accordance with the Preventing Harm Exception (§ 171.201) (89 FR 63623).

We proposed to explicitly add reference to § 171.202 in our revision to subparagraph (ii) of § 171.204(a)(2) in order to ensure that the
segmentation
condition would continue to apply in scenarios where the actor cannot unambiguously segment other EHI they could lawfully make available from the EHI that the actor has chosen to honor the individual's request not to share (consistent with § 171.202(e) sub-exception). In addition, we noted that citing § 171.202 in the proposed revision to subparagraph (ii) of § 171.204(a)(2) would expand explicit application of the § 171.204(a)(2)
segmentation
condition to certain situations where an actor subject to multiple laws with inconsistent preconditions adopts uniform privacy policies and procedures to adopt the more restrictive preconditions (as provided for under the Privacy sub-exception Precondition Not Satisfied, see § 171.202(b)(3) as currently codified). We explained that by referencing all of the Privacy Exception (§ 171.202), the proposed revision to § 171.204(a)(2)(ii) would allow the Infeasibility Exception's
segmentation
condition to apply in scenarios where an actor has adopted the more restrictive of multiple laws' preconditions for sharing of some information about an individual's health or care consistent with § 171.202(b). Specifically, the condition would apply when such an actor cannot unambiguously segment EHI for which a more restrictive precondition has not been met from other EHI that the actor could lawfully share in jurisdictions with less restrictive preconditions.

We also noted (89 FR 63623) that by referencing all of the Privacy Exception (§ 171.202), the proposed revision would extend the
segmentation
condition's coverage to situations where the actor is unable to unambiguously segment EHI that could be made available from specific EHI that the actor may choose to withhold from the individual or their (personal or legal) representative consistent with the § 171.202(d) Privacy sub-exception “denial of individual access based on unreviewable grounds.”

In the HTI-2 Proposed Rule (89 FR 63623 and 63624), we identified a possibility that individuals and interested parties could be concerned that extending the
segmentation
condition's coverage could affect the speed with which actors move to adopt or improve segmentation capabilities. We noted that segmentation capabilities may need to be improved to sequester the EHI that may be withheld from an individual on certain unreviewable grounds from
other
EHI an actor may have for that individual. For instance, we explained that in comparison to health information that may need to be sequestered for other reasons, different or additional segmentation functionality may be needed to sequester from other EHI only that information created or obtained in the course of research that includes treatment and only for as long as the research is in progress (89 FR 63624).
34

We noted that while the actor that is a HIPAA covered entity would still need to satisfy the individual's right of access to other PHI to the extent possible (see 45 CFR 164.524(d)(1)), the form and format in which the PHI is readily producible (see 45 CFR 164.524(c)(2)) may not be supported by the same electronic manner of access, exchange, or use that the individual would prefer. Therefore, we invited commenters to share any concerns or other perspectives they may wish to share relevant to this issue. We also proposed in the alternative to reference only Privacy Exception sub-exceptions
other than
denial of access based on unreviewable grounds (§ 171.202(d)) in the revised § 171.204(a)(2)
segmentation
condition. We noted that including this alternative proposal in the HTI-2 Proposed Rule meant we could decide to finalize the revision to the § 171.204(a)(2)
segmentation
condition with or without cross-reference to (or that would include) “denial of access based on unreviewable grounds” (§ 171.202(d)).

34
Please
see
45 CFR 164.524(a)(2)(iii) for the HIPAA Privacy Rule's full “unreviewable grounds for denial” circumstances to which this example alludes.

We noted (89 FR 63624) that for an actor's practice to be consistent with the § 171.202 Privacy Exception, the practice must meet the requirements set forth in any one of the sub-exceptions enumerated in § 171.202(b) through (e). We explained that referencing the entirety of § 171.202 in § 171.204(a)(2)(ii) would, therefore, also extend application of the Infeasibility Exception's
segmentation
condition to situations where a health IT developer of certified health IT that is not required to comply with the HIPAA Privacy Rule may withhold EHI they could otherwise lawfully make available based on an organizational privacy policy consistent with the § 171.202(c) sub-exception. (As used in § 171.202, “HIPAA Privacy Rule” means 45 CFR parts 160 and 164 (§ 171.202(a)(1).)

We noted that because the § 171.202(c) sub-exception is applicable only where a health IT developer of certified health IT is not required to

comply with the HIPAA Privacy Rule, it would apply in situations where the health IT developer of certified health IT is not required to comply with the individual right of access in 45 CFR 164.524. We stated that we believe it is possible that some individuals might seek health care or other services from such developers' customers (including health care providers) who are not HIPAA covered entities. We noted that in such situations, a State or Tribal law may operate to provide the individual a right to access their health information that the actor has.
35

We explained that although the number of such situations may be relatively small, we do recognize it is possible for some individuals to find themselves in situations where no other law explicitly guarantees them a right to access EHI of which the individual is the subject (or the legal representative of the subject). We noted that in such situations, the individual may rely solely on the information blocking statute to ensure actors will not unreasonably and unnecessarily interfere with the individual's EHI access, exchange, or use. We requested comments about potential unintended consequences of extending the (§ 171.204(a)(2))
segmentation
condition to situations where a health IT developer is not required to comply with HIPAA and cannot segment EHI they have
chosen
to withhold consistent with the actor's own organizational privacy policies from other EHI. We also asked if extending the
segmentation
condition to situations where a health IT developer has chosen to withhold EHI consistent with the Privacy sub-exception “health IT developer of certified health IT not covered by HIPAA” (§ 171.202(c)) pose too much risk of such developers avoiding individuals' EHI requests by choosing not to develop segmentation capabilities in the health IT they provide their customers who are not HIPAA covered entities. We also included an alternative proposal to reference in the revised § 171.204(a)(2)(ii)
segmentation
condition only the Privacy Exception sub-exceptions
other than
§ 171.202(c) “health IT developer of certified health IT not covered by HIPAA” sub-exception (89 FR 63624).

35
Determining what other laws may operate, or how, in specific circumstances is beyond the scope of this final rule.

We noted that as discussed in the HTI-2 Proposed Rule (89 FR 63624), the § 171.206 Protecting Care Access Exception would apply to practices that an actor chooses to implement that are likely to interfere with access, exchange, or use of specific EHI (including, but not limited to, withholding such EHI) when relevant conditions are met. We proposed to reference § 171.206 in the revised § 171.204(a)(2)(ii) because the proposed § 171.206(a)
threshold
condition's requirements include (among others) a requirement that the actor's practice be no broader than necessary to reduce the risk of potential exposure of any person(s) to legal action that the actor believes could arise from the particular access, exchange, or use of the specific EHI. We noted that the actor's lack of technical capability to sequester only the EHI for which relevant conditions of § 171.206 have been satisfied would not render § 171.206 applicable to interference with the lawful access, exchange, or use of other EHI pertaining to the same individual(s). We explained that, therefore, proposed reference to § 171.206 in the proposed revised § 171.204(a)(2)(ii) would accommodate circumstances where an actor lacks the technical capability to unambiguously segment the EHI the actor has chosen to withhold consistent with the Protecting Care Access Exception (§ 171.206) from other EHI that they could lawfully make available.

In the HTI-2 Proposed Rule (89 FR 63624), we noted that the requirements for an actor's practice to satisfy the proposed new § 171.206 exception, including the § 171.206(a)
threshold
condition that would be relevant to any practice to which § 171.206 could apply as well as when the § 171.206(b)
patient protection
or § 171.206(c)
care access
conditions are relevant, were discussed in detail in the HTI-2 Proposed Rule preamble (89 FR 63627 through 63639). Similarly, we discuss comments received and the finalized requirements for the new § 171.206 exception in this final rule's preamble.

Comments.
The majority of commenters supported our proposal to focus subparagraph (i) of § 171.204(a)(2)(i)
segmentation
condition to continue to apply to EHI that is not permitted by applicable law to be made available, stating that the proposed revision provides clarity and certainty for actors who choose to withhold certain patient EHI. Commenters also stated that the proposed revision reduces burden on actors when determining whether and which EHI may meet the Infeasibility Exception and mentioned that providers currently must use extensive time and resources to redact sensitive information before disclosure. Commenters expressed support for the proposal, asserting that the revision addresses technical health IT systems issues (
i.e.,
where systems do not have the capabilities to unambiguously segment EHI). Commenters further noted that our proposal would result in improved patient experience, engagement, and safety. Several commenters applauded ASTP/ONC for our proposal noting that it allows individuals more control over their health data.

Response.
We thank commenters for their support and have finalized § 171.204(a)(2)(i) as proposed. Sub-paragraph (i) of the
segmentation
condition (§ 171.204(a)(2)) of the Infeasibility Exception (§ 171.204), as revised, focuses solely on EHI that is not permitted by applicable law to be made available for a requested access, exchange, or use.

Comment.
We did not receive substantive feedback regarding our proposal to retain explicit cross-reference § 171.201 Preventing Harm Exception, now shown in subparagraph (ii) of § 171.204(a)(2).

Response.
Therefore, we have finalized, as proposed, retention of the explicit cross-reference to § 171.201 Preventing Harm Exception in sub-paragraph (ii) of § 171.204. The § 171.204(a)(2)
segmentation
condition continues to apply where an actor cannot unambiguously segment other EHI from EHI that the actor has chosen to withhold in accordance with the Preventing Harm Exception (§ 171.201).

Comments.
The majority of commenters strongly supported our proposal to explicitly add a cross-reference in § 171.204(a)(2)(ii) to the entirety of § 171.202 Privacy Exception, noting that it safeguards patient privacy and sensitive health information, enhances clarity and certainty, provides flexibility, reduces compliance burden on actors, and accounts for health IT system limitations until segmentation capabilities are more mature. Commenters commended ASTP/ONC for the proposal, noting that the provisions are a positive step that allow providers to prioritize caring for patients and will significantly improve patient and family experience, engagement, and safety.

Many commenters endorsed the proposal to expand the
segmentation
condition's coverage stating that it would lead to improved patient privacy and provided several examples of situations where health care providers are unable to segment granular health data. Some commenters specifically referenced the benefits of the proposal for health care providers who treat patients exposed to violence and who request to keep their sensitive information private. Commenters also noted that it would help patients with stigmatizing diagnoses keep their

information private. Another commenter pointed to their support for the proposed revised
segmentation
condition as it relates to the continued expansion of USCDI data elements and the implications on patient privacy and the potential harm of releasing sensitive information.

Commenters commended ASTP/ONC for the clarity and certainty that our proposal provides for actors to confidently withhold EHI without fear of an information blocking claim or risks of an information blocking determination. For example, one commenter noted that many laboratories do not have the technology to keep certain sensitive results separate, and this proposal would allow laboratories to confidently not share this data without fear of violating information blocking regulations. Commenters also stated that the proposal would have the benefit of providing additional necessary protections and assurances for health care providers who seek to not share a patient's EHI due to risks of an information blocking claim or determination. Commenters asserted that the proposal ensures that actors have clarity that use of exceptions to prevent the disclosure of specific EHI is not considered information blocking. One commenter noted that the proposal is especially helpful for health care providers who lack resources and access to more sophisticated health IT systems.

Many commenters stressed that current health IT systems cannot provide the level of segmentation that is required to safeguard patient data. Commenters specifically noted that health IT systems lack the necessary data segmentation capabilities to map to how Local, State, Federal, and Tribal health data privacy laws are written and cannot apply the variation on disclosure requirements. Commenters stressed that it is technically impossible for EHRs to segment EHI that is protected and treated differently by various privacy laws depending on the jurisdiction and circumstances. Many commenters who endorsed the proposal stated that the
segmentation
condition is necessary in the interim until technology that can separate and sequester sensitive data is available. Commenters stressed that the proposal ultimately eases the burden on actors, especially health care providers, associated with compliance with the information blocking regulations given there are factors outside of their control, like the limited segmentation capabilities in EHRs.

Some commenters specifically supported the proposal to reference the entirety of the Privacy Exception in the Infeasibility Exception's
segmentation
condition because it would expand the applicability of the
segmentation
condition to health IT developers of certified health IT that are not required to comply with the HIPAA Privacy Rule.

The majority of commenters recommended that we finalize subparagraph (ii) of the
segmentation
condition (§ 171.204(a)(2)) to cross-reference the entirety of the Privacy Exception as proposed.

Response.
We thank commenters for their support to expand subparagraph (ii) of the
segmentation
condition (§ 171.204(a)(2)) to cross-reference the entirety of the Privacy Exception (§ 171.202). We also appreciate commenters concerns that technology does not currently have the capability to sequester EHI that is protected and treated differently by laws in various jurisdictions. In the HTI-2 Proposed Rule we noted the importance of data segmentation, our awareness of the limitations of current health IT capabilities for data segmentation and of external efforts to develop technical standards that over time may result in increasingly advanced data segmentation capabilities in EHR systems and other health IT, and the variability in heath IT products capabilities to segment data (89 FR 63634). We agree with commenters that revisions to the
segmentation
condition are necessary to provide for circumstances where an actor cannot sequester EHI from other EHI that is treated differently depending on the jurisdiction and circumstances. Therefore, after consideration of the comments and the strong support for the
segmentation
condition proposal to include the entirety of the § 171.202 Privacy Exception, we have finalized, as proposed, subparagraph (ii) of the
segmentation
condition (§ 171.204(a)) of the Infeasibility Exception to cross-reference the entirety of the Privacy Exception (§ 171.202)).

We discuss comments specific to cross-referencing § 171.202 Privacy Exception in the
segmentation
condition (§  171.204(a)(2)(ii)) in more detail below.

Comments.
No commenters supported our alternative proposal to reference the Privacy Exception sub-exceptions
other
than denial of access based on unreviewable grounds (§  171.202(d)) in the revised § 171.204(a)(2)
segmentation
condition in response to our alternative proposal request for comment.

Response.
We have not finalized the alternative proposal. We have finalized § 171.202(a)(2)(ii) to include a cross-reference to the entirety of § 171.202. By referencing all of the Privacy Exception (§  171.202), the
segmentation
condition's coverage includes situations where the actor is unable to unambiguously segment EHI that could be made available from specific EHI that the actor may choose to withhold from the individual or their (personal or legal) representative consistent with the §  171.202(d) Privacy sub-exception “denial of individual access based on unreviewable grounds.”

Comments.
Some commenters supported our alternative proposal to reference in subparagraph (ii) of the revised
segmentation
condition (§ 171.204(a)(2)) the Privacy Exception sub-exceptions other than §  171.202(c) “health IT developer of certified health IT not covered by HIPAA” sub-exception instead of the entirety of § 171.202. Commenters expressed concern that expanding the application of the Infeasibility Exception's
segmentation
condition to situations where a health IT developer of certified health IT that is not required to comply with the HIPAA Privacy Rule could lead health IT vendors to abuse the Infeasibility Exception by inappropriately limiting the format, volume, and categories of health care data because they have deliberately designed their health IT system to limit shared data. Some commenters referred to the practice as “i

[Text truncated at 120,000 characters. The full text is on the page linked above.]

---

Source: Frix Law Library, https://www.frixlaw.com/law-library/documents/fr%3A2024-29683. Public record. Not legal advice.
