Home/Federal/Federal Register/2024-29683

Rule2024-29683

Health Data, Technology, and Interoperability: Protecting Care Access

Primary source

Metadata and text below are from the Federal Register, a public-domain U.S. government work. Always verify the official published version before relying on it for any legal matter.

Published

December 17, 2024

Effective

December 17, 2024

Issuing agencies

Health and Human Services Department

Abstract

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.

Full Text

<html>
<head>
<title>Federal Register, Volume 89 Issue 242 (Tuesday, December 17, 2024)</title>
</head>
<body><pre>
[Federal Register Volume 89, Number 242 (Tuesday, December 17, 2024)]
[Rules and Regulations]
[Pages 102512-102565]
From the Federal Register Online via the Government Publishing Office [<a href="http://www.gpo.gov">www.gpo.gov</a>]
[FR Doc No: 2024-29683]

[[Page 102511]]

Vol. 89

Tuesday,

No. 242

December 17, 2024

Part VII

Department of Health and Human Services

-----------------------------------------------------------------------

45 CFR Part 171

Health Data, Technology, and Interoperability: Protecting Care Access;
Final Rule

Federal Register / Vol. 89, No. 242 / Tuesday, December 17, 2024 /
Rules and Regulations

[[Page 102512]]

-----------------------------------------------------------------------

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, <a href="http://HealthIT.gov">HealthIT.gov</a>, 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: <a href="https://www.healthit.gov/topic/information-blocking/">https://www.healthit.gov/topic/information-blocking/</a>.
---------------------------------------------------------------------------

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

[[Page 102513]]

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 <a href="https://www.brookings.edu/articles/a-sustainable-business-model-for-health-information-exchange-platforms-the-solution-to-interoperability-in-health-care-it/">https://www.brookings.edu/articles/a-sustainable-business-model-for-health-information-exchange-platforms-the-solution-to-interoperability-in-health-care-it/</a>; 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 (TEFCATM)''
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\ <a href="https://www.hhs.gov/about/news/2024/07/10/hhs-proposes-hti-2-rule-improve-patient-engagement-information-sharing-public-health-interoperability.html">https://www.hhs.gov/about/news/2024/07/10/hhs-proposes-hti-2-rule-improve-patient-engagement-information-sharing-public-health-interoperability.html</a>.
---------------------------------------------------------------------------

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

[[Page 102514]]

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 Sec. 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 Sec. 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 Sec. 171.102 a
definition of ``reproductive health care'' and comments received in
response to that proposal. Comments received specific to other proposed
revisions to Sec. 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 (Sec. 171.202 and Sec. 171.204) and solicited comment on
potential revisions to one exception in subpart D (Sec. 171.403). We
proposed revisions to paragraphs (a), (d), and (e) of Sec. 171.202 (89
FR 63620 through 63622, and 63803) and to paragraphs (a)(2), (a)(3) and
(b) of Sec. 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 Sec. 171.202 and paragraph
(a)(2) of Sec. 171.204. Comments received specific to proposed
revisions to Sec. 171.202(d), Sec. 171.204(a)(3), and Sec.
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 Sec. 171.206 (89 FR 63627 through 63639, and 63804).
We have finalized the proposed Protecting Care Access Exception (Sec.
171.206), and we address comments relevant to it in this final rule.
Comments received specific to the Requestor Preferences Exception
(Sec. 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 Sec. 171.401 definitions of certain terms
relevant to the Trusted Exchange Framework and

[[Page 102515]]

Common AgreementTM (TEFCATM) (89 FR 63642, 63804,
and 63805) and in Sec. 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
TEFCATM in Sec. 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 (Sec. 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 (Sec. 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 Sec. 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 (Sec.
171.202) or solely by the Preventing Harm Exception (Sec. 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 Sec. 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 (Sec. 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

[[Page 102516]]

``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: <a href="https://www.healthit.gov/faq/which-patient-access-cases-does-preventing-harm-exception-recognize-substantial-harm">https://www.healthit.gov/faq/which-patient-access-cases-does-preventing-harm-exception-recognize-substantial-harm</a>.\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
<a href="http://HealthIT.gov">HealthIT.gov</a>'s Information Blocking FAQs page (<a href="https://www.healthit.gov/faqs?f%5B0%5D=term_parent%3A7011">https://www.healthit.gov/faqs?f%5B0%5D=term_parent%3A7011</a>).
---------------------------------------------------------------------------

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, <a href="http://HealthIT.gov">HealthIT.gov</a>. We offer a range of resources for
health care providers across a broad array of care settings online,
free of charge. (Start at <a href="https://www.healthit.gov/topic/health-it-health-care-settings/health-it-health-care-settings">https://www.healthit.gov/topic/health-it-health-care-settings/health-it-health-care-settings</a>). For example, we
offer an educational module for LTPAC providers \13\ and our Health IT
Playbook (<a href="https://www.healthit.gov/playbook/">https://www.healthit.gov/playbook/</a>) has implementation
resources for LTPAC providers.\14\ From an information-blocking
perspective, information resources currently available at <a href="https://www.healthit.gov/informationblocking">https://www.healthit.gov/informationblocking</a> 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\ <a href="https://www.healthit.gov/sites/default/files/ltpac_healthit_educationmodule_8-7-17_ecm.pdf">https://www.healthit.gov/sites/default/files/ltpac_healthit_educationmodule_8-7-17_ecm.pdf</a>.
\14\ <a href="https://www.healthit.gov/playbook/care-settings/">https://www.healthit.gov/playbook/care-settings/</a>.
\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: <a href="https://www.healthit.gov/sites/default/files/2024-03/InformationBlockingPresentationPDF_LTPAC_2.22.24.pdf">https://www.healthit.gov/sites/default/files/2024-03/InformationBlockingPresentationPDF_LTPAC_2.22.24.pdf</a> (A link to view
the recorded webinar is available from <a href="https://www.healthit.gov/topic/information-blocking">https://www.healthit.gov/topic/information-blocking</a>).
---------------------------------------------------------------------------

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, <a href="http://HealthIT.gov">HealthIT.gov</a>.\16\
---------------------------------------------------------------------------

\16\ <a href="https://www.healthit.gov/topic/privacy-security-and-hipaa">https://www.healthit.gov/topic/privacy-security-and-hipaa</a>.
---------------------------------------------------------------------------

B. Exceptions

1. Privacy Exception Updates
a. Privacy Exception--Definition of Individual
For purposes of the Privacy Exception, the term ``individual'' is
defined in Sec. 171.202(a)(2). When the Privacy Exception in Sec.
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 Sec. 171.202(a)(2)(iii), (iv), and (v) cross-

[[Page 102517]]

references paragraphs (a)(1) and (2) of Sec. 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 Sec.
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 Sec. 171.202 defines the term
``individual'' in part by referring to its definition in 45 CFR
160.103. In Sec. 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 Sec. 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 Sec. 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 Sec. 171.102 and is, by cross-reference to 45
CFR 160.103, the same definition used for purposes of the HIPAA
Privacy Rule. The Sec. 160.103 definition of ``person'' clarifies
the meaning of ``natural person'' within it. We use ``natural
person'' with that same meaning in Sec. 171.202(a)(2) and
throughout this discussion of Sec. 171.202(a)(2). Consistent with
the Sec. 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 Sec. 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 Sec. 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 Sec. 171.202 as (a)(2)(iii), (iv), and (v) the paragraphs
finalized and codified in Sec. 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 Sec.
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 Sec. 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 Sec. 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 Sec. 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'' (Sec. 171.202(a)(iii)) is different from
``legal representative'' (Sec. 171.202(a)(iv)) and requesting that we
provide an example of someone who is not a personal representative
under Sec. 171.202(a)(2)(iii) but is a legal representative who can
make health care decisions under Sec. 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 Sec. 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'' (Sec. 171.202(a)(iii)) and a
``legal representative'' (Sec. 171.202(a)(iv)). As explained in the
ONC Cures Act Final Rule (85 FR 25847), ``Sec. 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, Sec. 171.202(a)(iii)
refers specifically, and only, to a person who is a ``personal
representative''

[[Page 102518]]

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, <a href="http://HHS.gov">HHS.gov</a>.\20\
---------------------------------------------------------------------------

\19\ 45 CFR 164.502(g) sets forth the HIPAA Privacy Rule's
``personal representative'' standard and implementation
specifications.
\20\ <a href="https://www.hhs.gov/hipaa/for-professionals/privacy/guidance/personal-representatives/index.html">https://www.hhs.gov/hipaa/for-professionals/privacy/guidance/personal-representatives/index.html</a>
---------------------------------------------------------------------------

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 Sec.
171.202(a)(i) in Sec. 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 Sec. 171.202(a)(2) applies for
purposes of all of the sub-exceptions (paragraphs (b), (c), (d), and
(e)) of the Privacy Exception (Sec. 171.202). This definition
explicitly includes both ``individuals'' as defined in 45 CFR 160.103
(Sec. 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\ (Sec. 171.202(a)(2)(ii)). Thus, the definition of
``individual'' is constructed to account for both Sec. 171.102
``actors'' who are, and Sec. 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 Sec. 171.102 and is, by cross-reference to 45
CFR 160.103, the same definition used for purposes of the HIPAA
Privacy Rule. The Sec. 160.103 definition of ``person'' clarifies
the meaning of ``natural person'' within it. We use ``natural
person'' with that same meaning in Sec. 171.202(a)(2) and
throughout this discussion of Sec. 171.202(a)(2). Consistent with
the Sec. 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, Sec.
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 Sec. 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 Sec. 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 (Sec. 171.202).
Consistent with the Sec. 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
Sec. 171.102, and in the definition of ``individual'' in Sec.
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 (Sec. 171.206), which is finalized in this final rule. We
therefore address other comments regarding the meaning of ``patient''
in the context of Sec. 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 Sec. 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 Sec. 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%20treatmen
t%20can%20begin), and Rita Rubin, ``How Abortion Bans Could Affect
Care for Miscarriage and Infertility,'' JAMA (June 28, 2022),
(available at <a href="https://jamanetwork-com.hhsnih.idm.oclc.org/journals/jama/fullarticle/2793921?resultClick=1">https://jamanetwork-com.hhsnih.idm.oclc.org/journals/jama/fullarticle/2793921?resultClick=1</a>). (URLs retrieved May 23,
2024.)
---------------------------------------------------------------------------

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

[[Page 102519]]

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 Sec. 171.202(e). Accordingly, we proposed to
remove the ``unless otherwise required by law'' limitation from Sec.
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 Sec. 171.202(e) could serve as a useful
complement to the Precondition Not Satisfied sub-exception (Sec.
171.202(b)). We also noted in the HTI-2 Proposed Rule, and reaffirm
here, that the Sec. 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 Sec. 171.202, we now also note that each
sub-exception under the Privacy Exception (Sec. 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 Sec. 171.202) need not
also satisfy any other sub-exception (any other of paragraphs (b)
through (e) within Sec. 171.202) in order to be covered by the Privacy
Exception (Sec. 171.202).
We noted in the HTI-2 Proposed Rule that the proposed revision to
Sec. 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 Sec. 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
Sec. 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 Sec. 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

[[Page 102520]]

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 Sec. 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 Sec. 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 Sec. 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 Sec. 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 Sec. 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 Sec. 171.202(e)(4).
Comments. Several commenters expressed concerns that the proposed
revisions to Sec. 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 Sec. 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).

[[Page 102521]]

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 Sec. 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 Sec. 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 Sec. 171.202(e) Privacy sub-exception. We did not
propose, nor are we finalizing, any revisions to the requirements of
the Sec. 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 Sec. 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 Sec. 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 Sec. 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 Sec. 171.202(e) do not
change how any other Federal, State, or Tribal law applies to proxy
requests. We stress that the revisions to Sec. 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 <a href="https://www.hhs.gov/hipaa/for-professionals/faq/personal-representatives-and-minors/index.html">https://www.hhs.gov/hipaa/for-professionals/faq/personal-representatives-and-minors/index.html</a>, <a href="https://www.hhs.gov/hipaa/for-professionals/privacy/laws-regulations/index.html">https://www.hhs.gov/hipaa/for-professionals/privacy/laws-regulations/index.html</a>, and
<a href="https://www.hhs.gov/hipaa/for-professionals/privacy/guidance/personal-representatives/index.html">https://www.hhs.gov/hipaa/for-professionals/privacy/guidance/personal-representatives/index.html</a>.
---------------------------------------------------------------------------

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 Sec. 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 Sec.
171.202(e)(3) requirements, would therefore not be covered by the
Privacy Exception (Sec. 171.202), and could implicate the information
blocking definition in Sec. 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 <a href="http://HealthIT.gov">HealthIT.gov</a>. 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 <a href="https://www.healthit.gov/feedback">https://www.healthit.gov/feedback</a>
---------------------------------------------------------------------------

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

[[Page 102522]]

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 Sec. 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 Sec. 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 Sec. 170.315(d)(14), an addition to ASTP/
ONC's Privacy and Security Framework under the Program in Sec.
170.550(h), and a revision to an existing ``view, download, and
transmit to 3rd party'' certification criterion in Sec. 170.315(e)(1)
(88 FR 23822 through 23824). We sought public comment on these
proposals--the new criterion in Sec. 170.315(d)(14), the inclusion of
the request capability for patients in Sec. 170.315(e)(1), and the
requirements with the Privacy and Security Framework in Sec.
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 Sec. 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 Sec. 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 (Sec. 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 Sec. 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 Sec. 171.201.
---------------------------------------------------------------------------

\27\ The actor would still need to meet the requirements of
Sec. 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 Sec. 171.202 Privacy sub-exception in our revisions to Sec.
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 Sec. 171.202(e) (89 FR
63623). In another section of this final rule preamble, we discuss the
revisions we have finalized to Sec. 171.204(a)(2), including a
reference to the entire Sec. 171.202 Privacy sub-exception in Sec.
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 Sec. 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

[[Page 102523]]

cases as illustrative examples, while reminding readers that this is
not an exhaustive list. The revised Sec. 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 Sec. 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 Sec.
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 Sec. 171.202(e).
Another use case to which the revised Sec. 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 Sec. 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 Sec. 171.102.
Notably, the Sec. 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 Sec. 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 Sec.
171.202(e). We refer readers to our official website, <a href="http://HealthIT.gov">HealthIT.gov</a>, 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 Sec. 171.202(e) Privacy sub-
exception only so long as the practice satisfies the requirements found
in Sec. 171.202(e)(1)-(4). The requirements in Sec. 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''
(Sec. 171.202(e)(1)). We also remind readers that the term
``individual'' is defined for purposes of the Privacy Exception in
Sec. 171.202(a), as discussed in this final rule.
We appreciate the opportunity to emphasize that the revised Sec.
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 Sec. 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 Sec. 171.202(e)(1) from the individual (as described
in Sec. 171.202(a)(2)(i) and (ii)) or their representative (as
described in Sec. 171.202(a)(2)(iii) or (iv)) or a person having
authority to act on behalf of a deceased person (as described in Sec.
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 Sec. 171.202(e) (individual's request not to share EHI) sub-
exception is applicable to any actor's practice that meets its
requirements. The Sec. 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 Sec. 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

[[Page 102524]]

oversight. One commenter expressed concern about verbal requests, which
were not an aspect of the proposed revisions to Sec. 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 Sec. 171.202(e)(1), which do not mention verbal
requests, or the documentation provisions of Sec. 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 Sec. 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 Sec. 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, <a href="http://HealthIT.gov">HealthIT.gov</a>: ``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: <a href="https://www.healthit.gov/faq/how-would-any-claim-or-report-information-blocking-be-evaluated">https://www.healthit.gov/faq/how-would-any-claim-or-report-information-blocking-be-evaluated</a>.
---------------------------------------------------------------------------

2. Infeasibility Exception Updates
In the ONC Cures Act Final Rule, we established the Infeasibility
Exception (Sec. 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 Sec. 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 Sec. 171.204(b) responding
to requests condition and any one of the conditions in Sec.
171.204(a).
In the HTI-1 Final Rule (89 FR 1373 through 1387 and 1436), we
finalized the following revisions to Sec. 171.204:
<bullet> clarification of the Sec. 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;
<bullet> addition of two new conditions (third party seeking
modification use and manner exception exhausted, respectively
subparagraphs (3) and (4)) under paragraph (a); and
<bullet> renumbering the infeasible under the circumstances
condition from Sec. 171.204(a)(3) to Sec. 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
Sec. 171.204(a)(5)) or the Sec. 171.204(a)(2) segmentation condition,
and we did not make any changes to Sec. 171.204(b). In the HTI-2
Proposed Rule (89 FR 63623), we proposed to modify:
<bullet> the Sec. 171.204(a)(2) segmentation condition as
described in the HTI-2 Proposed Rule (89 FR 63623 through 63624);
<bullet> the Sec. 171.204(a)(3) third party seeking modification
use condition as described in the HTI-2 Proposed Rule (89 FR 63624
through 63625); and
<bullet> the Sec. 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 Sec.
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 Sec. 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 Sec.
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
Sec. 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 Sec. 171.204(a)(2) describes why
certain EHI cannot or will not be made available, including more
specific cross-

[[Page 102525]]

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 Sec. 171.204(a)(2)(i), and
EHI that the actor may choose to withhold in accordance with the
Preventing Harm Exception in Sec. 171.204(a)(2)(ii). We proposed to
revise the condition (Sec. 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 (Sec. 171.206) and the
existing Privacy Exception (Sec. 171.202) in addition to the existing
Preventing Harm Exception (Sec. 171.201) (which currently has an
explicit cross-reference).
We stated that focusing Sec. 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 Sec. 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 Sec. 171.204(a)(2)
would retain in subparagraph (ii) the explicit reference to the
Preventing Harm Exception (Sec. 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 (Sec. 171.201) (89 FR 63623).
We proposed to explicitly add reference to Sec. 171.202 in our
revision to subparagraph (ii) of Sec. 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 Sec. 171.202(e)
sub-exception). In addition, we noted that citing Sec. 171.202 in the
proposed revision to subparagraph (ii) of Sec. 171.204(a)(2) would
expand explicit application of the Sec. 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 Sec.
171.202(b)(3) as currently codified). We explained that by referencing
all of the Privacy Exception (Sec. 171.202), the proposed revision to
Sec. 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
Sec. 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 (Sec. 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 Sec.
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
(Sec. 171.202(d)) in the revised Sec. 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 Sec. 171.204(a)(2) segmentation condition with or without cross-
reference to (or that would include) ``denial of access based on
unreviewable grounds'' (Sec. 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 Sec. 171.202 Privacy Exception, the practice must
meet the requirements set forth in any one of the sub-exceptions
enumerated in Sec. 171.202(b) through (e). We explained that
referencing the entirety of Sec. 171.202 in Sec. 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 Sec. 171.202(c) sub-exception. (As used in Sec. 171.202,
``HIPAA Privacy Rule'' means 45 CFR parts 160 and 164 (Sec.
171.202(a)(1).)
We noted that because the Sec. 171.202(c) sub-exception is
applicable only where a health IT developer of certified health IT is
not required to

[[Page 102526]]

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 (Sec. 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'' (Sec. 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 Sec.
171.204(a)(2)(ii) segmentation condition only the Privacy Exception
sub-exceptions other than Sec. 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 Sec. 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 Sec. 171.206 in the revised Sec.
171.204(a)(2)(ii) because the proposed Sec. 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
Sec. 171.206 have been satisfied would not render Sec. 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 Sec. 171.206 in the proposed revised
Sec. 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 (Sec. 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 Sec.
171.206 exception, including the Sec. 171.206(a) threshold condition
that would be relevant to any practice to which Sec. 171.206 could
apply as well as when the Sec. 171.206(b) patient protection or Sec.
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 Sec. 171.206 exception in this final rule's preamble.
Comments. The majority of commenters supported our proposal to
focus subparagraph (i) of Sec. 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
Sec. 171.204(a)(2)(i) as proposed. Sub-paragraph (i) of the
segmentation condition (Sec. 171.204(a)(2)) of the Infeasibility
Exception (Sec. 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 Sec. 171.201 Preventing
Harm Exception, now shown in subparagraph (ii) of Sec. 171.204(a)(2).
Response. Therefore, we have finalized, as proposed, retention of
the explicit cross-reference to Sec. 171.201 Preventing Harm Exception
in sub-paragraph (ii) of Sec. 171.204. The Sec. 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 (Sec.
171.201).
Comments. The majority of commenters strongly supported our
proposal to explicitly add a cross-reference in Sec. 171.204(a)(2)(ii)
to the entirety of Sec. 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

[[Page 102527]]

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 (Sec. 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 (Sec. 171.204(a)(2))
to cross-reference the entirety of the Privacy Exception (Sec.
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 Sec. 171.202 Privacy Exception, we have
finalized, as proposed, subparagraph (ii) of the segmentation condition
(Sec. 171.204(a)) of the Infeasibility Exception to cross-reference
the entirety of the Privacy Exception (Sec. 171.202)).
We discuss comments specific to cross-referencing Sec. 171.202
Privacy Exception in the segmentation condition (Sec.
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 (Sec. 171.202(d)) in the revised
Sec. 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 Sec. 171.202(a)(2)(ii) to include a cross-reference to the
entirety of Sec. 171.202. By referencing all of the Privacy Exception
(Sec. 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 Sec. 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
(Sec. 171.204(a)(2)) the Privacy Exception sub-exceptions other than
Sec. 171.202(c) ``health IT developer of certified health IT not
covered by HIPAA'' sub-exception instead of the entirety of Sec.
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 ``infeasibility by design'' and
urged ASTP/ONC to clarify that actors may not use the Infeasibility
Exception's segmentation condition in this manner.
Some commenters expressed their concern that some organizations
rely on the segmentation condition as a shield to not share EHI for
purposes of business expediency instead of separating discrete data
that an entity has requested for a legitimate business purpose. The
commenters asserted that actors understand that segmentation
capabilities are not available in most EHRs, and the segmentation
condition provides a justification for not sharing EHI when sharing is
legally permissible. One commenter expressed concerns with including
the Privacy Exception sub-exceptions other than Sec. 171.202(c)
``health IT developer of certified health IT not covered by HIPAA,''
yet acknowledged that the segmentation condition is necessary until
more robust segmentation capabilities are available. The commenter
stated that it was ``not clear how to provide the environment,
incentives, and potential penalties'' to ameliorate the behavior of
actors that abuse the segmentation condition.
Another commenter expressed concerns that including the Sec.
171.202 Privacy Exception cross-reference in its entirety could
inadvertently create challenges for third-party companies to

[[Page 102528]]

access and utilize patient data, and result in incentives to limit the
development of health care solutions that could improve experiences for
providers, patients, and payers.
Response. We thank commenters for their input addressing the
alternative proposal. After consideration of the comments received, we
have not adopted the alternative proposal. We have finalized the
segmentation condition (Sec. 171.204(a)(2)) revision as proposed at 89
FR 63803.
We understand and appreciate commenters' concerns about expanding
the segmentation condition to include an explicit cross-reference to
the entirety of Sec. 171.202 in Sec. 171.204(a)(2), however we are
not convinced that these concerns outweigh, at this point in time, the
need for including a cross-reference to the entirety of Privacy
Exception (Sec. 171.202) in the segmentation condition (Sec.
171.204(a)(2)(ii)). A large number of comments received in response to
the proposals addressed in this final rule expressed concerns and
stated it is a reality that many actors use health IT that cannot
currently, due to technology limitations, unambiguously segment from
other EHI the EHI that they must withhold under laws that apply to them
or that they may choose to withhold in accordance with another
information blocking exception (such as Sec. 171.202(e), which is
available to all actors). Adopting the cross-reference to the entirety
of the Privacy Exception (Sec. 171.202) in the segmentation condition
in Sec. 171.204(a)(2), provides certainty and clarity for all actors
that they can both avoid committing information blocking and protect
individuals' privacy interests in accordance with the laws that apply
to them--be those laws Federal, State, or Tribal--even if the actor
that is unable to unambiguously segment their EHI is a health IT
developer of certified health IT not covered by HIPAA. Finalizing the
revisions to Sec. 171.204(a)(2) as proposed (89 FR 63803) also avoids
adding further complexity because it more precisely identifies for
actors the practices that would not be considered information blocking
without treating certain actors differently, thus the revisions do not
create additional burden for health IT developers not covered by HIPAA
that would not likewise apply to actors covered by HIPAA. Additionally,
we are not persuaded that it is necessary to exclude non-covered actors
in finalized Sec. 171.204(a)(2)(ii), given the relatively small subset
of actors and circumstances where the distinction between including or
excluding Sec. 171.202(c) from the cross-reference in Sec.
171.204(a)(2)(ii) is likely relevant because the vast majority of
health IT developers of certified health IT operate as business
associates or covered entities under HIPAA. We agree with commenters
that it is important to ensure that non-covered actors that offer
products or services not regulated by the HIPAA Privacy Rule, and are
still subject to the information blocking provisions, should have the
ability to seek coverage under the provisions finalized in Sec.
171.204(a)(2)(ii) due to the limitations of current segmentation
capabilities in health IT.
We note, however, that any abuse of the segmentation condition of
the Infeasibility Exception (or any component of any information
blocking exception) would be of concern to ASTP/ONC, and we plan to
continue monitoring for any signals that this may be occurring. We
would anticipate taking appropriate educational, outreach, and (where
applicable) enforcement steps in response to such signals and may
consider future rulemaking, as necessary, to amend any provision in 45
CFR part 171 in response to changing market conditions.
We also plan to continue to engage with the health IT, standards,
health care provider, and patient advocacy communities to encourage
innovative approaches to development and implementation of more
granular and interoperable segmentation capabilities. We encourage
anyone who believes they may have experienced or observed information
blocking by any health care provider, health IT developer of certified
health IT, or HIN or HIE to share their concerns with us through the
Information Blocking Portal on ASTP/ONC's website, <a href="http://HealthIT.gov">HealthIT.gov</a>.
Information received by ASTP/ONC through the Information Blocking
Portal as well as the Health IT Feedback and Inquiry Portal helps
inform the development of resources we make publicly available on ASTP/
ONC's website, <a href="http://HealthIT.gov">HealthIT.gov</a>.
Comments. A small number of commenters opposed our proposal to
include the cross-reference in the segmentation condition (Sec.
171.204(a)(2)(ii)) to any sub-exception within the Privacy Exception
(Sec. 171.202) because they believed ASTP/ONC could accomplish the
same objectives by adding functionality or requirements similar to our
proposed ``patient right to request a restriction on use or
disclosure'' certification criterion requirement in the ONC Health IT
Certification Program (Program). These commenters opposed any revisions
to the Infeasibility Exception's segmentation condition in Sec.
171.204(a)(2).
Response. We thank the commenters for their concerns and
recommendation, but we did not propose changes to the ONC Health IT
Certification Program related to segmentation capabilities in the HTI-2
Proposed Rule. The proposals related to actors lacking segmentation
capabilities in the HTI-2 Proposed Rule are related to information
blocking. These comments are out of scope of this final rule. In
addition, we note that information blocking provisions are relevant
where actors deploy a wide range of health IT beyond what is currently
certified under the ONC Health IT Certification Program. We refer
readers to the HTI-1 Final Rule (89 FR 1298 through 1305) for an
explanation on our decision to decline adopting our proposal for a
``patient right to request a restriction on use or disclosure''
certification criterion in the Program, most notably because of limited
developer capabilities to manage the complexities of every patient
request and a lack of configured privacy and security systems for this
data, which can lead to unintended consequences on patient data.
As mentioned above, we plan to continue to engage with the health
IT, health care provider, and patient advocacy communities to encourage
innovative approaches to development and implementation of more
granular and interoperable segmentation capabilities.
Comments. Some commenters expressed support for expanding the
segmentation condition to include the entirety of the Privacy Exception
because it would protect the EHI of survivors of violence. Some
commenters endorsed modifying the Infeasibility Exception's
segmentation condition to explicitly account for circumstances where
the provider cannot comply with a request without disclosing exposure
to violence. One commenter expressed concern that clarifying the
segmentation condition by adding a cross-reference to the Privacy
Exception may not be adequate to address a patient's privacy concerns
with respect to exposure to violence. The commenter claimed that due to
the complexity of information blocking rules, health care providers do
not understand or employ the existing segmentation condition or the
currently codified Privacy Exception adequately, risking harm to the
patient. The same commenter stated that our proposal is a step in the
right direction regarding protecting sensitive medical information, but
the commenter expressed concern that in practice, providers are not
aware of how to apply the Privacy Exception and instead share private
patient information in fear of

[[Page 102529]]

information blocking accusations. Commenters urged ASTP/ONC to clarify
the information blocking requirements regarding releasing sensitive
patient data in online portals as it relates to the Privacy Exception
and the Infeasibility Exception's segmentation condition.
Response. We thank the commenters for their support and for
bringing to our attention their concerns about health care providers
not withholding EHI due to fear of information blocking accusations
even when the Privacy Exception would apply if the actor chose to
withhold some or all of the patient's EHI. In the HTI-2 Proposed Rule,
we proposed to revise the Sec. 171.202(e) Privacy sub-exception (89 FR
63622). We have finalized the Sec. 171.202(e) revision in this rule.
We believe the revision will make it easier for actors to feel
confident in their ability to satisfy the Sec. 171.202(e) Privacy sub-
exception if the actor chooses to honor an individual's request not to
share EHI. The Privacy sub-exception ``individual's request not to
share EHI'' (Sec. 171.202(e)) is agnostic as to why the individual
wants to restrict sharing of their EHI, and as to what topics or other
subset of their EHI the individual might ask an actor not to share.
Thus, Sec. 171.202(e) is not limited to situations where an individual
asks an actor not to share information about the individual's exposure
to violence, but it would apply where the individual requests that the
actor not share that information.
We are aware that adding a cross-reference in Sec.
171.204(a)(2)(ii) to the entirety of Sec. 171.202 does not expand the
Privacy Exception's coverage for an actor's electing to withhold
exposure to violence or other information that an actor may consider
sensitive where none of the sub-exceptions in Sec. 171.202(b), (c),
(d), or (e) is applicable. We did not propose in the HTI-2 Proposed
Rule such an expansion of the Privacy Exception, nor of any other
exception. Where no applicable law requires, and no other exception
applies to an actor's choosing to, withhold EHI indicating exposure to
violence from access, exchange, or use permitted by applicable law, the
Infeasibility Exception's segmentation condition will not operate to
cover the actor's withholding of such EHI or of other EHI that the
actor may be unable to unambiguously segment from it. We did not
propose in the HTI-2 Proposed Rule to modify Sec. 171.204(a)(2) so
that it could operate in such a manner. Therefore, any expansion of the
Infeasibility Exception or another exception to cover actors' electing
to withhold EHI indicating exposure to violence or other EHI on the
basis that the actor finds it to be sensitive would be beyond the scope
of this rule (or another final rule addressing any other proposals made
in the HTI-2 Proposed Rule). We refer commenters and other interested
parties to 45 CFR part 171 for the full conditions of all information
blocking exceptions, and to ASTP/ONC's official website, <a href="http://HealthIT.gov">HealthIT.gov</a>,
for the array of resources (such as FAQs, fact sheets, and webinars) we
have published about information blocking exceptions. As additional
resources become available, including for the newly finalized
Protecting Care Access Exception, we anticipate making them available
at <a href="http://HealthIT.gov">HealthIT.gov</a>.
We note that some actors may operate under one or more laws that
restrict information about individuals' exposure to violence in ways
that the HIPAA Privacy Rule does not. We also appreciate the
opportunity these commenters have provided us to remind all actors that
where applicable law prohibits a specific access, exchange, or use of
information, complying with such laws is ``required by law'' for
purposes of the information blocking regulations. Practices that are
``required by law'' are not considered ``information blocking'' (see,
for example, 89 FR 1351 and 85 FR 25794). As we noted in the HTI-2
Proposed Rule (89 FR 63623 through 63624), focusing subparagraph (i) of
Sec. 171.204(a)(2) solely on EHI that applicable law prohibits an
actor from making 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 prohibits the actor from
making covered information available.
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, the
feedback, and questions we receive are appreciated and help to inform
our development of information resources that we make publicly
available on <a href="http://HealthIT.gov">HealthIT.gov</a>. Informal channels include, for example, the
Health IT Feedback and Inquiry Portal that is available year-round and
not tied to the comment period for a proposed rule. To find the portal,
please click, paste, or search <a href="https://www.healthit.gov/feedback">https://www.healthit.gov/feedback</a>.
Comment. One commenter urged ASTP/ONC to exercise caution as it
considers policies about segmenting patient data that could be
necessary to provide patient care. The commenter expressed concerns
over the potential for patient harm with competing State and Federal
laws and regulations and noted that segmentation could lead to
incomplete clinical information.
Response. We thank the commenter for their perspective. As we have
stated, all information blocking exceptions are voluntary; the
existence of an exception that could apply to an actor's choice to
withhold EHI from access, exchange, or use under the exception's
conditions is not intended to create an affirmative obligation that any
actor do so. For example, if an actor believes that withholding EHI in
accordance with the Preventing Harm Exception (Sec. 171.201) would in
fact create more risk to the patient than would be prevented--either by
application of Sec. 171.201 alone or in combination with the
Infeasibility Exception due to the actor's lack of segmentation
capabilities--then we presume the actor would not choose to withhold
the EHI just because an exception (or combination of exceptions) exists
that could apply if the actor did choose to withhold the EHI.
We recognize that the landscape of Federal, State, and (where
applicable) Tribal laws that affect when sharing patient health
information is not permitted, conditionally permissible, permitted, or
required is complex. Resolving that complexity would be beyond the
scope of this final rule. We plan to continue working with the health
care, health IT, patients, and privacy advocate communities in the
hopes of encouraging innovation that will advance availability and use
of increasingly granular, interoperable, and flexible data segmentation
capabilities to help actors safeguard patients' privacy interests and
comply with various applicable laws while optimizing data sharing to
promote care coordination, safety, and quality.
Comment. One commenter acknowledged their support for the overall
intent of the proposal but stated that ASTP/ONC should leave the
definition as described in the HIPAA policy. The commenter recommended
that ASTP/ONC clarify this definition to fit ``the TEFCA rule.''
Response. It is unclear to us which specific HIPAA definition the
commenter is referring to and therefore it is not clear how they may
have envisioned us incorporating such a description into the
segmentation condition (Sec. 171.204(a)(2)). It is also not clear from
the comment what the commenter was referring to as ``the TEFCA rule''
or how they intended to suggest the infeasibility exception might, in
the commenter's view, better align with whatever aspect of TEFCA the
commenter may have intended to reference. We could interpret the

[[Page 102530]]

comment as suggesting that ASTP/ONC should finalize our proposed
revisions to the segmentation condition of the Infeasibility Exception
because the prior references in Sec. 171.204(a)(2)(i) and (ii) (before
this final rule) may have, in the commenter's assessment, not made it
as easy for an actor to know when the segmentation condition would
apply to a specific situation. We would agree that the original scope
of Sec. 171.204(a)(2)(i) and (ii) can be presented in a way that is
easier to read, and to that end we proposed the improved wording and
structure of Sec. 171.204 in the HTI-2 Proposed Rule alongside the
proposal to reference all of the Privacy Exception and the new
Protecting Care Access Exception.
In light of the ambiguity of the comment, we note that information
blocking regulations are issued under separate statutory authority from
HIPAA regulations and TEFCA. We work to ensure the regulations do not
conflict with one another and align requirements where practical given
the different purpose and function of the information blocking
regulations in comparison to the HIPAA Privacy Rule or TEFCA.
Additionally, we do not define terms, nor did we propose to define
terms in the segmentation condition (Sec. 171.204(a)). The proposed
(and finalized) subparagraph (ii) of the segmentation condition (Sec.
171.204(a)(2)(ii) adds the cross-reference to Sec. 171.202 where we
define the term ``HIPAA Privacy Rule.'' As noted in the HTI-2 Proposed
Rule (89 FR 63624), the HIPAA Privacy Rule definition in Sec.
171.202(a)(1), as used in Sec. 171.202, ``HIPAA Privacy Rule'' means
45 CFR parts 160 and 164 (Sec. 171.202(a)(1)). Given the ambiguity of
the comment and our interpretation, we decline to consider aligning the
definition in Sec. 171.202(a)(1) to other definitions discussed in the
HTI-2 Proposed Rule.
Comments. In general, commenters expressed strong support to expand
explicit application of the segmentation condition to the Privacy
Exception to account for certain situations where an actor is subject
to multiple laws with conflicting or inconsistent pre-conditions,
noting that it provides clarity and is helpful. Commenters expressed
appreciation for the expansion because it allows providers to enact
uniform policies that outline their inability to segment data, and
justify their nondisclosure, allowing providers to prioritize the
important work of caring for patients.
Response. We thank commenters for their support and have finalized,
as proposed, Sec. 171.204(a)(2)(ii).
Comments. A few commenters seemed to misinterpret our proposal to
expand the segmentation condition, as well as the existing codified
requirements of the segmentation condition in Sec. 171.204(a)(2) that
we did not propose to revise in the HTI-2 Proposed Rule. Commenters
cited the OCR ``Privacy Rule to Support Reproductive Health Care
Privacy'' Final Rule's valid attestation requirements as a pre-
condition that must be satisfied by the health care provider before
disclosing specific EHI. The commenters suggested that the proposed
revised segmentation condition would now apply if a physician does not
receive a valid attestation, and it would allow the physician or their
EHR developer to withhold most of the medical record if prohibited from
sharing specific EHI based on OCR, State, or other privacy regulations.
Response. As discussed above, the expanded segmentation condition
applies 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 Sec. 171.202(b) but cannot
unambiguously segment EHI for which a more restrictive precondition has
not been met from other EHI that the actor could lawfully share in the
jurisdictions with less restrictive preconditions. We refer readers to
the HTI-2 Proposed Rule (89 FR 63627 through 63642) for a discussion of
the new Protecting Care Access Exception (Sec. 171.206) and alignment
with the 2024 HIPAA Privacy Rule.
Comments. Commenters had differing views on whether expanding the
segmentation condition's coverage could affect the speed with which
actors move to adopt or improve segmentation capabilities. Most
commenters stated that expanding the segmentation condition's coverage
would not discourage health IT developers from developing segmentation
capabilities or health care providers from adopting the technology.
Several commenters stated that including the entirety of Sec. 171.202
would not cause a delay in development or adoption of segmentation
capabilities. Commenters noted that health care providers would welcome
the technology and acknowledged that some heath IT developers are
working to improve segmentation capabilities, but that the availability
of the segmentation condition is necessary in the interim until health
IT capabilities mature. Commenters stated that the Sec.
171.204(a)(2)(ii) segmentation condition would improve
interoperability, and in turn patient safety and privacy, until health
IT capabilities fully support more granular segmentation.
One commenter suggested that ASTP/ONC should not be concerned if
the expanded segmentation condition disincentivizes the development of
data segmentation capabilities because there are other policy avenues
to address these concerns, notably through certification criteria
requirements and Centers for Medicare & Medicaid Services (CMS)
regulations that incorporate by reference the technical standards
needed for segmentation. The commenter believed that addressing these
concerns through other federal regulations would lead to speedier
adoption of segmentation capabilities. The commenter further stated
that the interests of interoperability are not advanced by denying
actors--particularly those that do not develop or control the health
technologies--the protection of the segmentation condition given the
realities of current health IT capabilities and third-party payer
systems.
However, some commenters expressed concerns that expanding the
segmentation condition's coverage would encourage the health IT
industry to delay development and adoption of robust segmentation
capabilities at the peril of promoting interoperability and possibly
patient safety. One commenter stated that the expansion would result in
incentives to limit the development of health care solutions that could
improve experiences for providers, patients, and payers. Another
commenter stated that the entire health IT industry is delaying the
development of segmentation capabilities, regardless of whether a
health IT developer is required to comply with the HIPAA Privacy Rule.
Response. We thank commenters for their suggestions and insights in
responding to our question on the expansion of the Infeasibility
Exception's segmentation condition in Sec. 171.204(a)(2)(ii) and
whether there are potential effects on the speed with which actors move
to adopt or improve segmentation capabilities. As commenters noted, the
health IT that is currently available cannot easily sequester granular
data. To the extent that adopting the expanded segmentation condition's
coverage does or does not affect the speed with which actors move to
adopt or improve segmentation capabilities, we agree that the
availability of the segmentation condition is necessary, at this time,

[[Page 102531]]

until health IT capabilities mature, and more interoperable and
granular segmentation capabilities improve. We recognize the need to
promote interoperability, but we also consider patient privacy and
safety when promoting interoperability. We thank commenters for sharing
their thoughts on how the Infeasibility Exception's segmentation
condition provides an interim solution for actors to limit sharing
sensitive EHI without violating the information blocking regulations.
We appreciate the commenter's observations that policy development
and requirements in other Federal programs could encourage the
development of data segmentation capabilities and that our proposal
would not disincentivize these developments. As stated, we plan to
continue to engage with the health IT, standards, health care provider,
and patient advocacy communities, as well as our Federal partners, to
encourage innovative approaches to development and implementation of
more granular and interoperable segmentation capabilities. We will
continue to monitor and analyze approaches by health IT developers for
real world implementation of segmentation capabilities and the adoption
of the technology by health care providers.
Comment. One commenter urged ASTP/ONC to examine how it can spur
action to respond to growing threats to patient privacy, the patient-
physician relationship, and patient and clinician safety.
Response. Although the comment is beyond the scope of this final
rule, we thank the commenter for sharing their thoughts. We recognize
these topics are important to patients, physicians, other clinicians,
and the health care system as a whole. ASTP/ONC plans to continue our
efforts to foster development of a nationwide health IT infrastructure
in a manner consistent with, among other important goals, improving
health care quality, reducing medical errors, reducing health
disparities, and advancing the delivery of patient-centered medical
care while ensuring that each patient's health information is secure
and protected in accordance with applicable law. As we mention above,
whether received through the public comments process for a proposed
rule or through informal channels, the feedback, and questions we
receive are appreciated and help to inform our development of
information resources that we make publicly available on <a href="http://HealthIT.gov">HealthIT.gov</a>.
Informal channels include, for example, the Health IT Feedback and
Inquiry Portal that is available year-round and not tied to the comment
period for a proposed rule. To find the portal, please click, paste, or
search <a href="https://www.healthit.gov/feedback">https://www.healthit.gov/feedback</a>.
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. As we previously noted in our discussion of the Privacy
Exception in this final rule, 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 63498). With respect to our
proposals regarding the Infeasibility Exception, the proposal in Sec.
171.204(a)(2)(ii) expands the application of the Infeasibility
Exception's segmentation condition to all situations where an actor is
unable to segment EHI from other requested EHI that the actor has
chosen to withhold consistent with the Privacy Exception (Sec.
171.202) or Protecting Care Access Exception (Sec. 171.206). The
information an actor is prohibited by applicable law from making
available may vary based on what laws, including the HIPAA Privacy
Rule, do or do not apply to the actor. However, the Infeasibility
Exception's segmentation condition does not have different requirements
based on whether an actor must also comply with the HIPAA Privacy Rule.
Because the finalized segmentation condition (Sec. 171.204(a)(2))
adds a cross-reference to the entirety of the Privacy Exception, we
remind readers that the Sec. 171.202(e) sub-exception's alignment with
the individual's right under the HIPAA Privacy Rule to request
restrictions does not limit the sub-exception's availability to actors
who are also subject to the HIPAA Privacy Rule's requirements (89 FR
1353). We refer readers to the HTI-2 Proposed Rule (89 FR 63620 through
63622) for further discussion of the Privacy sub-exception
``individual's request not to share EHI'' (Sec. 171.202(e)).
Comments. Commenters commended ASTP/ONC for expanding the
segmentation condition to specifically cross-reference the proposed
Protecting Care Access Exception in Sec. 171.206 noting that it
logically aligns with the cross-reference in Sec. 171.204(a)(ii) to
Sec. 171.201 and the proposed cross-reference to Sec. 171.202.
Commenters noted that the reference to the Protecting Care Access
Exception in the segmentation condition of Sec. 171.204(a)(2)(ii) is a
positive revision because it allows actors to consider segmentation
limitations when evaluating whether the withholding of reproductive
health information was properly tailored. Commenters stated that it is
technically difficult for health care providers to fulfill requests
without sharing protected reproductive health information, making it
necessary for the new Protecting Care Access Exception cross-reference
in the Infeasibility Exception's segmentation condition. Commenters
appreciated the flexibility the proposal provides for health care
providers declining to share reproductive health information without
facing information blocking consequences. Commenters stated that ASTP/
ONC should not penalize health care providers for honoring patients'
preferences to refrain from sharing EHI or to withhold EHI that could
expose patients to legal consequences for receiving lawful reproductive
care when segmentation of that data is not feasible.
Response. We thank commenters for their support and have finalized,
as proposed, the cross-reference to the Protecting Care Access
Exception (Sec. 171.206) in the subparagraph (ii) of the segmentation
condition of the Infeasibility Exception (Sec. 171.204(a)(2)(ii)).
We explained in the HTI-2 Proposed Rule (89 FR 63624) that the
Sec. 171.206 Protecting Care Access Exception applies 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 have
finalized the cross-reference to the Protecting Care Access Exception
(Sec. 171.206) in the segmentation condition (Sec. 171.204(a)(2)(ii))
because the finalized Sec. 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.
The actor's lack of technical capability to sequester only the EHI for
which relevant conditions of Sec. 171.206 have been satisfied does not
render Sec. 171.206 applicable to interference with the lawful access,
exchange, or use of other EHI pertaining to the same individual(s).
Therefore, the reference to Sec. 171.206 in the finalized Sec.
171.204(a)(2)(ii) accommodates circumstances where an actor lacks the
technical capability to unambiguously segment the EHI the actor has
chosen to withhold consistent with the finalized Protecting Care Access
Exception (Sec. 171.206) from other EHI that they could lawfully make
available. The

[[Page 102532]]

requirements for an actor's practice to satisfy the new finalized
Protecting Care Access Exception (Sec. 171.206), including the Sec.
171.206(a) threshold condition that is relevant to any practice to
which Sec. 171.206 could apply as well as when the Sec. 171.206(b)
patient protection or Sec. 171.206(c) care access conditions are
relevant, are discussed in detail in the HTI-2 Proposed Rule (89 FR
63633 through 63638).
3. New Protecting Care Access Exception
a. Background and Purpose
As we explained in the ONC Cures Act Final Rule, the information
blocking provision in PHSA section 3022 was enacted in response to
concerns about practices that ``unreasonably limit the availability and
use of electronic health information (EHI) for authorized and permitted
purposes'' because such practices ``undermine public and private sector
investments in the nation's health IT infrastructure, and frustrate
efforts to use modern technologies to improve health care quality and
efficiency, accelerate research and innovation, and provide greater
value and choice to health care consumers'' (85 FR 25790). We also
noted in the ONC Cures Act Final Rule that research suggests that
information blocking practices ``weaken competition among health care
providers by limiting patient mobility'' and that the information
blocking provision of the 21st Century Cures Act works to deter
practices that ``unnecessarily impede the flow of EHI or its use to
improve health and the delivery of care'' (85 FR 25791). As required by
section 3022(a)(3) of the PHSA, we recognized that certain reasonable
and necessary activities that could otherwise meet the definition of
information blocking should not be considered information blocking, and
therefore, established the initial eight ``exceptions'' to the
definition of information blocking (see 45 CFR 171 Subpart B and C; a
ninth exception was established by the HTI-1 Final Rule in Subpart D
(89 FR 1437)). Each reasonable and necessary activity identified as an
exception to the information blocking definition does not constitute
information blocking for purposes of section 3022(a)(1) of the PHSA if
the conditions of the exception are met (85 FR 25649).
Between when the first eight regulatory exceptions to the
information blocking definition were finalized in 2020 and the proposal
of the Protecting Care Exception in the HTI-2 Proposed Rule (89 FR
63627 through 63639 and 63804), the legal landscape had changed
significantly for many patients seeking, and for health care providers
providing, reproductive health care. In the wake of the decision in
Dobbs v. Jackson Women's Health Organization, 597 U.S. 215 (2022)
decision, some states have newly enacted or are newly enforcing
restrictions on access to reproductive health care. Uncertainties and
other concerns that people who seek reproductive health care and people
who provide or facilitate that care have about the legal landscape in
the wake of the Supreme Court's ruling--and subsequent state
restrictions on reproductive health care--have had far-reaching
implications for health care beyond access to abortion. The changing
legal landscape increases the likelihood that a patient's EHI may be
disclosed in ways that erode trust in health care providers and the
health care system, ultimately chilling an individual's willingness to
seek, or other persons' willingness to provide or facilitate, lawful
health care as well as individuals' willingness to provide full
information to their health care providers.
As noted in the HTI-2 Proposed Rule (89 FR 63627), a person's
ability to access care of any kind depends on a variety of factors
including whether the care is available. For health care to be
available, licensed health care professionals and health care
facilities must be willing to provide it--and people other than the
licensed health care professionals must be willing to take on various
roles essential to delivering care in this modern, technology-enabled
environment. Also, patients' access to care may rely in part on
services or supports from other persons, such as a spouse, partner, or
friend.
In the current legal environment, various jurisdictions are
enforcing laws, or contemplating legislation, that purports to
authorize administrative, civil, or criminal legal action against
persons who engage in reproductive health care that is required or
authorized by Federal law or that is permitted by the law of the
jurisdiction where the care is provided. Fear of being investigated or
of having to defend themselves against potential legal liability under
such laws, even where the health care is lawful under the circumstances
in which it was provided, may impact people's willingness to provide or
assist in reproductive health care.
On April 26, 2024, OCR issued the 2024 HIPAA Privacy Rule to adopt
a prohibition on the use or disclosure of PHI by an entity regulated
under the HIPAA Privacy Rule, in certain circumstances, for the
following purposes:
<bullet> To conduct a criminal, civil, or administrative
investigation into any person for the mere act of seeking, obtaining,
providing, or facilitating lawful reproductive health care.
<bullet> To impose criminal, civil, or administrative liability on
any person for the mere act of seeking, obtaining, providing, or
facilitating reproductive health care.
<bullet> To identify any person for any purpose described above.
As noted in the National Coordinator's May 13, 2024, blog post
titled ``Supporting Information Privacy for Patients, Now and Always:
Four Reminders of How HHS Information Blocking Regulations Recognize
Privacy Rules,'' \36\ on and after the 2024 HIPAA Privacy Rule's
effective date, a HIPAA covered entity's or business associate's
practice of denying a request for a use or disclosure of PHI where the
use or disclosure is prohibited under that rule is excluded from the
information blocking definition (45 CFR 171.103) because that denial is
required by law. Therefore, the practice does not need to be covered by
any information blocking exception because it is not considered
information blocking.
---------------------------------------------------------------------------

\36\ This HealthITbuzz blog post is available at <a href="https://www.healthit.gov/buzz-blog/information-blocking/supporting-information-privacy-for-patients-now-and-always-four-reminders-of-how-hhs-information-blocking-regulations-recognize-privacy-rules">https://www.healthit.gov/buzz-blog/information-blocking/supporting-information-privacy-for-patients-now-and-always-four-reminders-of-how-hhs-information-blocking-regulations-recognize-privacy-rules</a>.
---------------------------------------------------------------------------

As we noted in the HTI-2 Proposed Rule (89 FR 63628), the 2024
HIPAA Privacy Rule also established a requirement for HIPAA covered
entities and business associates to obtain attestations prior to using
or disclosing PHI potentially related to reproductive health care for
certain purposes (see 45 CFR 164.509; 89 FR 33063). The Precondition
Not Satisfied (45 CFR 171.202(b)) sub-exception of the information
blocking Privacy Exception outlines a framework actors can follow so
that the actors' practices of not fulfilling requests to access,
exchange, or use EHI would not be considered information blocking when
a precondition of applicable law has not been satisfied. By meeting the
Precondition Not Satisfied sub-exception's requirements, the actor can
have confidence that their practices of not sharing EHI because they
have not obtained the required attestation will not be considered
information blocking.\37\
---------------------------------------------------------------------------

\37\ We did not propose in the HTI-2 Proposed Rule, nor have we
finalized in this final rule, any changes to the Privacy Exception's
Precondition Not Satisfied sub-exception (Sec. 171.202(b)). As the
National Coordinator had reminded interested members of the public
prior to HHS releasing the HTI-2 Proposed Rule: ``the information
blocking regulations are designed to consider applicable law,
including HIPAA rules.'' (Tripathi, M, ``Supporting Information
Privacy for Patients, Now and Always: Four Reminders of How HHS
Information Blocking Regulations Recognize Privacy Rules,''
HealthITbuzz blog dated May 13, 2024, available at: <a href="https://www.healthit.gov/buzz-blog/information-blocking/supporting-information-privacy-for-patients-now-and-always-four-reminders-of-how-hhs-information-blocking-regulations-recognize-privacy-rules">https://www.healthit.gov/buzz-blog/information-blocking/supporting-information-privacy-for-patients-now-and-always-four-reminders-of-how-hhs-information-blocking-regulations-recognize-privacy-rules</a>.)

---------------------------------------------------------------------------

[[Page 102533]]

In preamble discussion of the background and purpose of the
proposed Protecting Care Access Exception (89 FR 63628), we observed
that the 2024 HIPAA Privacy Rule's new protections do not prohibit use
or disclosure of PHI for various purposes other than those specified in
45 CFR 164.502(a)(5)(iii), although the protections include additional
preconditions or limitations on disclosures for certain purposes (for
more information, please see the 2024 HIPAA Privacy Rule (89 FR 32976)
and consider visiting the <a href="http://HHS.gov">HHS.gov</a> Health Information Privacy section's
HIPAA and Reproductive Health page: <a href="https://www.hhs.gov/hipaa/for-professionals/special-topics/reproductive-health/index.html">https://www.hhs.gov/hipaa/for-professionals/special-topics/reproductive-health/index.html</a>). The 2024
HIPAA Privacy Rule does not require a HIPAA covered entity or business
associate to obtain the attestations specified in 45 CFR 164.509 before
disclosing PHI (including PHI potentially related to reproductive
health care) for permissible purposes other than those specified in 45
CFR 164.512(d), (e), (f), or (g)(1). For example, the HIPAA Privacy
Rule continues to allow uses and disclosures of PHI for treatment,
payment, or health care operations purposes (see 45 CFR 164.506) that
do not meet any of the prohibitions set out in 45 CFR
164.524(a)(5)(iii). Thus, an actor choosing to deny requests for
access, exchange, or use of EHI for a purpose permitted under HIPAA
could be implicating the information blocking definition unless another
applicable law requires the denial, or another regulatory exception
applies. Similarly, an actor conditioning fulfilment of such requests
on preconditions that an actor chooses to set (such as that the
requestor provides an attestation that is not required by any privacy
law that applies in the circumstances) could implicate the information
blocking definition unless an exception applies to that practice.
In the HTI-2 Proposed Rule (89 FR 63628), we provided a brief
review of how the information blocking regulations, which are based on
statutory authority separate from HIPAA, operate (independently of
regulations promulgated under HIPAA). This background information is
repeated here because it may help readers understand how and why an
actor may be concerned about potentially implicating the information
blocking definition (and civil monetary penalties or appropriate
disincentives for information blocking authorized by the information
blocking statute) if the actor engages in practices that the HIPAA
Privacy Rule would require of a HIPAA covered entity or business
associate when the actor is not required to comply with the HIPAA
Privacy Rule.
First, information blocking regulations apply to health care
providers, health IT developers of certified health IT, and health
information networks (HIN) and health information exchanges (HIE), as
each is defined in 45 CFR 171.102. Any individual or entity that meets
one of these definitions is an ``actor'' and subject to the information
blocking regulations in 45 CFR part 171, regardless of whether they are
also a HIPAA covered entity or business associate as those terms are
defined in 45 CFR 160.103. Second, for purposes of the information
blocking regulations, the definition of ``EHI'' applies to information
``regardless of whether the group of records are used or maintained by
or for a covered entity as defined in 45 CFR 160.103'' (Sec. 171.102,
emphasis added). Therefore, it is possible for an information blocking
actor that is not required to comply with the HIPAA Privacy Rule to
have EHI that is not also PHI. It is also possible for an actor (such
as a HIN/HIE) to not be a HIPAA covered entity itself and to exchange,
maintain, or otherwise handle EHI on behalf of network participants
that are not required to comply with the HIPAA Privacy Rule.
Where an actor that is not a HIPAA covered entity has EHI that is
not maintained on behalf of a HIPAA covered entity, the actor may be
concerned about potential information blocking consequences if the
actor were to engage in a practice such as denying requests for access,
exchange, or use of EHI that indicates or potentially relates to
reproductive health care for purposes for which the 2024 HIPAA Privacy
Rule would prohibit use or disclosure of PHI or would require an
attestation as a precondition for permitting disclosure of PHI.
There is a sub-exception within the Privacy Exception currently
codified in Sec. 171.202(c) that is available to a health IT developer
of certified health IT ``not covered by HIPAA.'' The sub-exception is
available ``if the actor is a health IT developer of certified health
IT that is not required to comply with the HIPAA Privacy Rule, when
engaging in a practice that promotes the privacy interests of an
individual'' (Sec. 171.202(c)). However, this exception represents a
departure from our general approach of designing each information
blocking exception to be available to all actors (regardless of whether
they must comply with the HIPAA Privacy Rule). The Sec. 171.202(c)
sub-exception is also not available to actors who meet the Sec.
171.102 definition of ``health care provider'' or ``HIN/HIE'' without
meeting the ``health IT developer of certified health IT'' definition,
even if they are not required to comply with the HIPAA Privacy Rule.
(We refer actors and other persons interested in learning more about
how the information blocking regulations, and particularly the
exceptions, work in concert with the HIPAA Rules and other privacy laws
to support health information privacy, to the discussion of this topic
in the HTI-1 Final Rule at 89 FR 1351 through 1354.)
As we explained in the HTI-2 Proposed Rule (89 FR 63629), we
understand that some health care providers and other actors may have
concerns about the risk of potential exposure to legal action flowing
from the uses and disclosures of EHI indicating or (in the case of
patient health concern(s) or history) potentially relating to
reproductive health care that remains permissible under applicable law.
For example, the HIPAA Privacy Rule permits a HIPAA covered entity to
disclose an individual's PHI to a health care provider who is not a
HIPAA covered entity for treatment activities. Once PHI is in the
possession, custody, or control of an entity that is not regulated
under the HIPAA Privacy Rule, the information is no longer protected by
the HIPAA Privacy Rule.
Thus, as we noted in the preamble discussion of the proposed
Protecting Care Access Exception (89 FR 63629), the HIPAA Privacy
Rule's strengthened protections for PHI would not preclude a health
care provider (or other recipient of PHI for other permissible
purposes) who is not a HIPAA covered entity or business associate from
further disclosing individually identifiable health information to
someone who might then use the information to potentially impose
criminal, civil, or administrative liability on any person for the mere
act of seeking, obtaining, providing, or facilitating reproductive
health care (or any other care) that was lawful under the circumstances
in which it was provided.

[[Page 102534]]

As we reiterated in the HTI-2 Proposed Rule (89 FR 63629), the
information blocking statute is separate from the HIPAA statute and the
information blocking regulations operate both separately and
differently from the HIPAA regulations. One point of such difference
that is key to understanding why we proposed a new ``Protecting Care
Access Exception'' (Sec. 171.206) is that a HIPAA covered entity or
business associate is not required by the HIPAA Privacy Rule to make a
use or disclosure that the HIPAA Privacy Rule merely permits.\38\
Actors subject to the information blocking regulations, however, could
implicate the information blocking definition if they ``interfere
with'' any access, exchange, or use of EHI except as required by law or
covered by an exception. It is the implication of the ``information
blocking'' definition (and the potential to incur penalties or
disincentives for engaging in information blocking) that would cause an
actor to be concerned about, for instance, refusing to disclose EHI
indicating reproductive health care for permissible purposes to an
entity not required to comply with the HIPAA Privacy Rule and whom the
actor has reason to believe does not safeguard the privacy or security
of individuals' health information in compliance with the same
standards as would be required of a HIPAA covered entity or business
associate.
---------------------------------------------------------------------------

\38\ The HIPAA Privacy Rule does not generally require uses and
disclosures of PHI but merely permits uses and disclosures for
various purposes. Disclosures that are required under the HIPAA
Privacy Rule are identified in 45 CFR 164.502(a)(2).
---------------------------------------------------------------------------

In a variety of situations where a patient or an actor may be
concerned that an access, exchange, or use of EHI may implicate any
person's physical safety interests or the individual's privacy
interests, other exceptions (such as the Preventing Harm Exception in
Sec. 171.201 or three of the four sub-exceptions of the Privacy
Exception in Sec. 171.202) have long been available to any actor who
wants to engage in practices that are likely to interfere with EHI
access, exchange, or use consistent with the conditions of the
applicable exception. We noted this in the HTI-2 Proposed Rule (89 FR
63629) and emphasize again here that such other exceptions remain
available to all actors. Each of the information blocking exceptions
codified in subparts B, C, and D of 45 CFR part 171 applies under the
conditions specified in the exception.
In the HTI-2 Proposed Rule (89 FR 63629), we noted that there were
at that time no exceptions in 45 CFR part 171 designed to accommodate
concerns an actor may have about a patient's, health care provider's,
or other person's risk of potential exposure to legal action
(investigation, action in court, or imposition of liability) that could
arise from \39\ the access, exchange, or use for permissible purposes
specific EHI (that is, one or more data points) that indicates
reproductive health care was sought, obtained, provided, or
facilitated. None of the exceptions, we noted, were designed to
accommodate similar concerns an actor may have about risk of patients'
potential exposure to legal action that could arise from the sharing
for permissible purposes of EHI that indicates health condition(s) or
history for which reproductive health care is often sought, obtained,
or medically indicated.\40\ Thus, we explained that where preconditions
(under the HIPAA Privacy Rule or other applicable law--or both, where
applicable) to the provision of access, exchange, or use of EHI have
been met, and another exception (such as the Privacy Exception (Sec.
171.202) or Preventing Harm Exception (Sec. 171.201)) does not apply,
attempts to limit the disclosure of EHI for the purposes addressed in
the patient protection or care access condition of the proposed
Protecting Care Access Exception (Sec. 171.206(b) or (c)) could
constitute information blocking (89 FR 63629). An actor's practice will
only meet the statutory or regulatory definition of information
blocking if it meets all of the definition's elements, including the
knowledge standard applicable to the actor engaged in the practice.
---------------------------------------------------------------------------

\39\ For purposes of this discussion and of the proposed
Protecting Care Access Exception, we noted that a risk need not be
one that is certain to occur, or that is likely to occur immediately
following, an access, exchange, or use of EHI in order to be one
that could arise from the access, exchange, or use.
\40\ In this preamble, we at some points use for brevity and
readability ``potentially related to reproductive health care'' as
shorthand for EHI that shows or would carry a substantial risk of
supporting an inference that (as described in proposed Sec.
171.206(b)(1)(iii)) the patient has health condition(s) or history
for which reproductive health care is often sought, obtained, or
medically indicated.
---------------------------------------------------------------------------

Even for actors to whom the HIPAA Privacy Rule does not apply,
other laws (Federal, State, or Tribal) may apply preconditions that
must be satisfied in order for EHI to be shared without violating these
laws. For any actor, compliance with such other applicable law does not
implicate the information blocking definition, as discussed in the HTI-
1 Final Rule preamble (see 89 FR 1351-1354) and in information
resources available on ASTP/ONC's official website (<a href="http://HealthIT.gov">HealthIT.gov</a>).
However, where the preconditions under such other applicable law are
met, any practice by an actor that is likely to interfere with access,
exchange, or use of EHI could implicate the information blocking
definition (Sec. 171.103) unless the actor's practice is covered by an
exception set forth in 45 CFR part 171.
In proposing the Protecting Care Access Exception (Sec. 171.206),
we noted (89 FR 63629) that it would be available to any actor,
regardless of whether the actor is also a HIPAA covered entity or
business associate. The exception was proposed to apply regardless of
whether another exception could also apply to an actor's practice(s)
assuming that the applicable conditions were satisfied. Also, we noted
in the HTI-2 Proposed Rule that other exceptions would continue to be
available in circumstances where the conditions of the Protecting Care
Access Exception cannot be met but the conditions of the other
exception(s) can be met (89 FR 63629).
At the bottom of 89 FR 63629 (in the last column as printed in the
Federal Register), the HTI-2 Proposed Rule included a reminder that
each information blocking exception and each provision of each
exception is designed to stand independent of any and every other
exception unless, and to the extent that, any specific provision of an
exception explicitly references another exception. Even in instances
with such references, the dependency is limited to the exact provision
or function of the provision that relies upon the cross-reference.
Thus, we explained in proposing the Protecting Care Access Exception
that the exception would operate independently of any provision of any
other exception in part 171 and any provision in 45 CFR 171 that does
not reference it (89 FR 63629). We stated in proposing the Protecting
Care Access Exception that it was our intent that if any provision in
Sec. 171.206 were held to be invalid or unenforceable facially, or as
applied to any person, plaintiff, or stayed pending further judicial or
agency action, such provision shall be severable from other provisions
of Sec. 171.206 that do not rely upon it and from any other provision
codified in 45 CFR part 171 that does not explicitly reference Sec.
171.206 even if such provisions were to be established or modified
through this same rulemaking action (89 FR 63629 and 63630). It
continues to be HHS's intent that if any provision of Sec. 171.206, as
finalized in this final rule, were held to be invalid or unenforceable
facially, or as applied to any person, plaintiff, or

[[Page 102535]]

stayed pending further judicial or agency action, such provision shall
be severable from other provisions of Sec. 171.206 that do not rely
upon it and from any other provision codified in 45 CFR part 171 that
does not explicitly reference Sec. 171.206 even if such provisions
were to be established or modified through this same final rule.
As we noted in the HTI-2 Proposed Rule (89 FR 63630), a patient's
ability to access care can be adversely affected when a provider
believes they could be exposed to legal action based on the mere fact
that care is provided. Given the demonstrated chilling effect of some
states' laws on the availability of medically appropriate care, it is
reasonable and necessary for actors to mitigate risks of potential
exposure of health care professionals and other persons who provide or
facilitate, as well as those who seek or obtain, reproductive health
care that is lawful under the circumstances in which the care is
provided to legal action based on the mere fact that such care was
sought, obtained, provided, or facilitated. Thus, we stated (89 FR
63630), a new exception was needed to address actors' concerns about
potentially implicating the information blocking definition (Sec.
171.103) if they choose not to share applicable EHI in the
circumstances where the Protecting Care Access Exception (Sec.
171.206) would apply. We stated that this exception (Sec. 171.206) is
important and intended to ensure health care providers do not feel the
need to adopt paper or hybrid recordkeeping methods in place of fully
electronic, interoperable formats (89 FR 63630).\41\ We explained that
we believe it is reasonable and necessary for an actor to restrict
access, exchange, or use of specific EHI that indicates or (under Sec.
171.206(b)) is potentially related to reproductive health care so that
health care providers continue to use modern, interoperable health IT
that better promotes patient safety than would paper or hybrid
recordkeeping methods (89 FR 63630). We clarified that creating an
information blocking exception that would exclude from the information
blocking definition an actor's restricting EHI sharing under the
conditions of the Protecting Care Access Exception (Sec. 171.206) is
necessary to preserve and promote public trust in health care
professionals, health care, and the health information infrastructure.
---------------------------------------------------------------------------

\41\ As defined in Sec. 171.102 and excluding certain
information as specified in subparagraphs (1) and (2) of this
definition, EHI is electronic protected health information (ePHI)
(defined in 45 CFR 160.103) that is or would be in the designated
record set (defined in 45 CFR 164.501) regardless of whether the
group of records are used or maintained by or for a covered entity
as defined in 45 CFR 160.103.
---------------------------------------------------------------------------

The Protecting Care Access Exception (Sec. 171.206), as proposed
(89 FR 63630) and as finalized in this final rule, is intended to
address actors' concerns about potentially implicating the information
blocking definition if they choose not to share EHI in a scenario that
an actor believes in good faith could risk exposing a patient,
provider, or facilitator of lawful reproductive health care to
potential legal action based on the mere fact that reproductive health
care was sought, obtained, provided, or facilitated (89 FR 63632).
Under the patient protection condition (Sec. 171.206(b)), the
exception is also intended to address such concerns and belief, on the
part of the actor, specific to EHI indicating a patient has health
condition(s) or history for which reproductive health care is often
sought, obtained, or medically indicated.
The HIPAA Privacy Rule does not prohibit the use or disclosure of
PHI that indicates or is potentially related to ``reproductive health
care'' as defined in 45 CFR 160.103 if the use or disclosure is not for
a purpose described at 45 CFR 164.502(a)(5)(iii) and the use or
disclosure is otherwise required or permitted by the HIPAA Privacy
Rule. Therefore, the Protecting Care Access Exception is needed where
an information blocking actor (whether or not that actor is required to
comply with the HIPAA Privacy Rule) is concerned about the information
blocking implications of limiting sharing of EHI when the actor
believes such limits could reduce a risk of potential exposure to legal
action (as defined in Sec. 171.206(e)) in connection with an access,
exchange, or use of such EHI for a permissible purpose.
We recognize that no information blocking exception can address all
concerns a person may have about potential legal action for the mere
act of seeking, obtaining, providing, or facilitating reproductive
health care. However, we clarify that, to the extent such concerns may
be mitigated by an information blocking exception that applies where an
actor chooses to withhold relevant EHI from access, exchange, or use
that all other applicable law would permit and where no other existing
information blocking exception applies, we believe an exception that
applies to such withholding of EHI is reasonable and necessary. We
noted our concern that actors' uncertainty about whether such
withholding of EHI could implicate the information blocking definition
could prevent actors from withholding EHI unless an exception applies.
Thus, we believe the Protecting Care Access Exception is needed to
address actors' concerns specific to information blocking related to
the risk of providers changing or limiting what care they are willing
to offer (such as when a professional changes practice specialty or a
hospital closes a service or department).
When providers limit what care they are willing to offer or what
new patients they are willing to accept, it may be more difficult for
those who seek care to get access to the care they need. When patients'
needs are not being met, they lose trust in the health care system and
in their physicians. Trust in one's own physician, in general,
correlates with better care satisfaction and outcomes.\42\ This may
also be true of trust in other types of health care professionals, such
as nurses, physician assistants, pharmacists, or organizational
providers such as hospitals or long-term/post-acute care facilities.
Thus, we believe that addressing actors' uncertainty specific to
information blocking with the Protecting Care Access Exception would
promote better patient satisfaction and health outcomes as well as
continued development, public trust in, and effective nationwide use of
health information technology infrastructure to improve health and
care.
---------------------------------------------------------------------------

\42\ Birkh[auml]uer, J., Gaab, J., Kossowsky, J., Hasler, S.,
Krummenacher, P., Werner, C., & Gerger, H. (2017). Trust in the
health care professional and health outcome: A meta-analysis. PloS
one, 12(2), e0170988. <a href="https://doi.org/10.1371/journal.pone.0170988">https://doi.org/10.1371/journal.pone.0170988</a>.
---------------------------------------------------------------------------

Moreover, actors' uncertainty about the potential information
blocking implications of not sharing all of the EHI that applicable
laws would permit them to share could undermine health care
professionals' (and other health care providers') confidence in their
ability to protect the privacy and confidentiality of their patients'
EHI. Such a lack of confidence on the part of health care providers can
in turn erode a patient's trust.
As we noted in the HTI-2 Proposed Rule (89 FR 63630), patient trust
in physician confidentiality and competence is associated with patients
being less likely to withhold information from doctors and more likely
to agree it is important for health care providers to share information
with each other.\43\ Thus, we clarified that the

[[Page 102536]]

Protecting Care Access Exception in Sec. 171.206--which would apply
under specified conditions to actors' practices of choosing not to
share specific EHI (where such sharing would be otherwise lawful)--is
reasonable and necessary to preserve patient trust in the health IT
infrastructure and information sharing, as well as to protect the
availability and safety of care, and to promote better care outcomes
(89 FR 63630).
---------------------------------------------------------------------------

\43\ Iott, B.E., Campos-Castillo, C., & Anthony, D.L. (2020).
Trust and Privacy: How Patient Trust in Providers is Related to
Privacy Behaviors and Attitudes. AMIA . . . Annual Symposium
proceedings. AMIA Symposium, 2019, 487-493 <a href="https://pmc.ncbi.nlm.nih.gov/articles/PMC7153104/">https://pmc.ncbi.nlm.nih.gov/articles/PMC7153104/</a>.
---------------------------------------------------------------------------

One of the goals of the information blocking exceptions is ``to
accommodate practices that, while they may inhibit access, exchange, or
use of EHI, are reasonable and necessary to advance other compelling
policy interests . . .'' including ``[p]romoting public confidence in
the health IT infrastructure by supporting the privacy and security of
EHI and protecting patient safety,'' as we explained in the ONC Cures
Act Final Rule (85 FR 25791). In the absence of an information blocking
exception applicable to risks of legal actions that actors believe
could arise from the sharing of EHI for permissible purposes (for
instance, with entities not required to comply with the HIPAA Privacy
Rule), we are concerned actors may be unwilling to engage in these
practices that--for example--advance public confidence in health IT
infrastructure and protect patient safety.
If other actors are unwilling to engage in such practices, health
care providers may convey to patients an inability to withhold EHI even
when they believe withholding the EHI could mitigate the potential
risks cognizable in the current environment. If patients are aware that
health care providers believe that they are unable to avoid sharing EHI
to mitigate risks of potentially exposing care providers, recipients,
or facilitators to legal action then patients may be less willing to be
candid with their providers about their health history, conditions, or
other information relevant to the patient's care. Without that candor,
health care providers may be unable to provide care that will best meet
the patient's needs. In addition, a care provider's lack of confidence
or competence in their ability to adequately safeguard the privacy of
information that care recipients share with them could erode the mutual
trust that contributes to better care outcomes by promoting more
effective relationships between care providers (including clinicians)
and the individuals receiving care.
In the absence of an exception applicable to practices that the
proposed Protecting Care Access Exception would cover, we are concerned
that health IT developers of certified health IT and HINs/HIEs may be
unwilling to take the actions necessary to address their own, or their
customer health care provider's, good faith belief that particular
sharing of specific EHI could create the risk of potential exposure of
a health care provider (or persons seeking, obtaining, providing, or
facilitating care) to legal action regarding health care items and
services that are lawful under the circumstances in which such health
care is provided. Thus, health care providers in these situations may
believe they are faced with a choice between changing what care they
offer (such as when a hospital closes a department) or switching at
least some portions of their clinical records from electronic to paper
formats specifically to avoid concerns that they may be engaged in
information blocking.
For health care professionals in reproductive health care
specialties or whose practice necessarily includes patients who need
reproductive health care, a partial or complete switch to paper-based
recordkeeping for that care may seem like their only option in the
absence of the Protecting Care Access Exception. Because the
information blocking definition references ``electronic health
information'' rather than all ``protected health information,'' the
information blocking regulations do not apply to health information
maintained only in paper format. A reversal to paper-based methods of
keeping even a relatively small portion of the records currently
managed u

[…truncated; see source link]

View on FederalRegister.gov →Plain-text source

Indexed from Federal Register on December 17, 2024.

This is legal information, not legal advice. Laws vary by jurisdiction and change frequently. Always verify current law with official sources and consult a licensed attorney in your jurisdiction for advice on your specific situation.