`[Federal Register Volume 89, Number 241 (Monday, December 16, 2024)]
[Rules and Regulations]
[Pages 101772-101817]
From the Federal Register Online via the Government Publishing Office [www.gpo.gov]
[FR Doc No: 2024-29163]



[[Page 101771]]

Vol. 89

Monday,

No. 241

December 16, 2024

Part III





Department of Health and Human Services





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





45 CFR Parts 170, 171, and 172





Health Data, Technology, and Interoperability: Trusted Exchange 
Framework and Common Agreement (TEFCA); Final Rule

  Federal Register / Vol. 89, No. 241 / Monday, December 16, 2024 / 
Rules and Regulations  

[[Page 101772]]


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

DEPARTMENT OF HEALTH AND HUMAN SERVICES

Office of the Secretary

45 CFR Parts 170, 171, and 172

RIN 0955-AA07


Health Data, Technology, and Interoperability: Trusted Exchange 
Framework and Common Agreement (TEFCA)

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 a 
proposed rule published in August 2024 and in doing so advances 
interoperability and supports the access, exchange, and use of 
electronic health information. Specifically, this final rule amends the 
information blocking regulations by including definitions related to 
the Trusted Exchange Framework and Common Agreement (TEFCA) Manner 
Exception. It also implements provisions related to the TEFCA, which 
will support the reliability, privacy, security, and trust within 
TEFCA. Lastly, this final rule includes corrections and updates to 
current regulatory provisions of the Office of the National Coordinator 
for Health Information Technology (ONC) Health IT Certification 
Program.

DATES: This final rule is effective on January 15, 2025.

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 Major Provisions
    1. ONC Health IT Certification Program
    a. Administrative Updates
    b. Correction--Privacy and Security Certification Framework
    2. Information Blocking Enhancements
    3. Trusted Exchange Framework and Common Agreement\TM\
    C. Costs and Benefits
II. Background
    A. Statutory Basis
    B. Regulatory History
III. ONC Health IT Certification Program
    A. Administrative Updates
    1. Updates Pursuant to 2014 Edition Removal
    a. Removal of ``Complete EHR'' References
    b. Removal of ``EHR Modules'' References
    2. Removal of Time-Limited Criteria
    3. Privacy and Security Framework Incorporation of DSI Criterion
    B. Correction--Privacy and Security Certification Framework
IV. Information Blocking Enhancements--Part 171, Subpart D (TEFCA)
    A. Definitions
    B. TEFCA\TM\ Manner Exception
V. Trusted Exchange Framework and Common Agreement\TM\
    A. Subpart A--General Provisions
    B. Subpart B--Qualifications for Designation
    C. Subpart C--QHIN\TM\ Onboarding and Designation Processes
    D. Subpart D--Suspension
    E. Subpart E--Termination
    F. Subpart F--Review of RCE[supreg] or ASTP/ONC Decisions
    G. Subpart G--QHIN\TM\ Attestation for the Adoption of the 
Trusted Exchange Framework and Common Agreement\TM\
VI. Severability
VII. Collection of Information Requirements--Qualified Health 
Information Networks\TM\
VIII. Regulatory Impact Analysis
    A. Statement of Need
    B. Alternatives Considered
    C. Overall Impact--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 
responsibilities to the Assistant Secretary for Technology Policy and 
Office of the National Coordinator for Health Information Technology 
(hereafter ASTP/ONC) \1\ for the implementation of certain provisions 
in Title IV of the 21st Century Cures Act (Pub. L. 114-255, Dec. 13, 
2016) (Cures Act) that are designed to: advance interoperability; 
support the access, exchange, and use of electronic health information 
(EHI); and identify reasonable and necessary activities that do not 
constitute information blocking.\2\ ASTP/ONC is responsible for the 
implementation of certain provisions of the Health Information 
Technology for Economic and Clinical Health Act (Pub. L. 111-5, Feb. 
17, 2009) (HITECH Act) including: requirements that the National 
Coordinator perform duties consistent with the development of a 
nationwide health information technology infrastructure that allows for 
the electronic use and exchange of information and that promotes a more 
effective marketplace, greater competition, and increased consumer 
choice, among other goals. This final rule fulfills statutory 
requirements; advances equity, innovation, and interoperability; and 
supports the access to, and exchange and use of, EHI.
---------------------------------------------------------------------------

    \1\ The Office of the National Coordinator for Health 
Information Technology (ONC) was the previous name of this office. 
See Federal Register: Statement of Organization, Functions, and 
Delegations of Authority; Office of The National Coordinator for 
Health Information Technology (89 FR 60903, July 29, 2024).
    \2\ Reasonable and necessary activities that do not constitute 
information blocking, also known as information blocking exceptions, 
are identified in 45 CFR part 171, subparts B, C and D. ASTP/ONC's 
official website, HealthIT.gov, offers a variety of resources on the 
topic of Information Blocking, including fact sheets, recorded 
webinars, and frequently asked questions. To learn more, please 
visit: https://www.healthit.gov/topic/information-blocking/.
---------------------------------------------------------------------------

B. Summary of Major Provisions

General Comments
    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 (HTI-2 Proposed Rule) (89 FR 
63498). 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 Trusted Exchange Framework and Common 
Agreement (TEFCA) information blocking exception and part 172 
proposals, and a limited set of the proposed ONC Health IT 
Certification Program (Program) administrative updates. Comments 
received in response to other proposals from the HTI-2 Proposed Rule 
are beyond the scope of this final rule, are still being reviewed and 
considered, and may be the subject of subsequent final rules related to 
such proposals in the future.
    As discussed above, the name of the office changed from the Office 
of the National Coordinator for Health Information Technology (ONC) to 
now be 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 released on July 
29, 2024.\3\ When the HTI-2 Proposed Rule appeared in the Federal 
Register on August 5, 2024, it referred to the office as ``ONC.'' It 
was not until days after the HTI-2 Proposed Rule had been released to 
the public (on

[[Page 101773]]

July 10, 2024) \4\ that the name officially changed. Accordingly, where 
we referred to ``ONC'' in the HTI-2 Proposed Rule, we continue to refer 
to ``ONC'' when referencing the HTI-2 Proposed Rule in this final rule. 
However, in the comment summaries, responses, and regulatory text of 
this final rule, we have revised those references to refer to ``ASTP/
ONC.'' In this final rule, we acknowledge these changes where we have 
finalized regulatory text as proposed except for the changed reference 
to ``ASTP/ONC.'' We note that this change is technical in nature and 
does not affect any substantive rights or obligations.
---------------------------------------------------------------------------

    \3\ Federal Register: Statement of Organization, Functions, and 
Delegations of Authority; Office of The National Coordinator for 
Health Information Technology (89 FR 60903).
    \4\ https://www.hhs.gov/about/news/2024/07/10/hhs-proposes-hti-2-rule-improve-patient-engagement-information-sharing-public-health-interoperability.html.
---------------------------------------------------------------------------

1. ONC Health IT Certification Program
a. Administrative Updates
    In section III.A.1, we discuss the removal of the ``Complete EHR'' 
and ``EHR Module'' terms from certain sections within subpart E of 45 
CFR part 170.
    As discussed in section III.A.2, we have removed from 45 CFR part 
170, Sec.  170.550(m), ``Time-limited certification and certification 
status for certain ONC Certification Criteria for Health IT,'' and 
removed the certification criteria with time-limited certification and 
certification status, including Sec.  170.315(a)(10) and (13), (b)(6), 
(e)(2), and (g)(8). Additionally, as discussed in section III.A.2, we 
have revised Sec.  170.315(b)(7) and (8) to remove Sec.  
170.315(b)(7)(ii) and (b)(8)(i)(B), which were time-limited provisions 
(now expired) that permitted health IT to demonstrate security tagging 
of Consolidated-Clinical Document Architecture (C-CDA) documents at the 
document level. In section III.A.3, we discuss the final revision of 
Sec.  170.550(h), the Privacy and Security Certification Framework 
requirements, that adds the certification criterion ``decision support 
interventions'' (Sec.  170.315(b)(11)) to the list of certification 
criteria in Sec.  170.550(h)(3)(ii).
b. Correction--Privacy and Security Certification Framework
    We have finalized a correction to the Privacy and Security 
Certification Framework in Sec.  170.550(h). As discussed in section 
III.B, we have added Sec.  170.550(h)(4) that existed prior to the 
``21st Century Cures Act: Interoperability, Information Blocking, and 
the ONC Health IT Certification Program'' final rule (85 FR 25642, May 
1, 2020) (ONC Cures Act Final Rule) being finalized but was erroneously 
deleted.
2. Information Blocking Enhancements
    In this final rule, with consideration of public comments, we have 
finalized the TEFCA Manner Exception in subpart D of part 171 with no 
revisions. We have also codified definitions of certain terms relevant 
to the Trusted Exchange Framework and Common Agreement\TM\ (TEFCA\TM\) 
in Sec.  171.401.
3. Trusted Exchange Framework and Common Agreement\TM\
    As discussed in this final rule, we have codified (in new 45 CFR 
part 172) provisions related to TEFCA to provide greater process 
transparency and to further implement section 3001(c)(9) of the PHSA, 
as added by the Cures Act. The finalized 45 CFR part 172 establishes 
the processes associated with the qualifications necessary for an 
entity to receive and maintain Designation (as defined in Sec.  
172.102) as a Qualified Health Information Network (QHIN) capable of 
trusted exchange under the Common Agreement. The final provisions 
codified in part 172 also establish the procedures governing Onboarding 
(as defined in Sec.  172.102) of QHINs and Designation of QHINs, 
suspension, termination, and administrative appeals to ASTP/ONC, as 
described in Sec.  172.100(c)(1) of this final rule. We believe 
establishing these provisions in regulation support reliability, 
privacy, security, and trust within TEFCA, which furthers our 
obligations to ``support'' TEFCA under sections 3001(c)(9)(A) and (B) 
of the PHSA and TEFCA's ultimate success. In addition, in subpart G of 
part 172, we have codified requirements related to QHIN attestation for 
the adoption of TEFCA. This subpart implements section 3001(c)(9)(D) of 
the PHSA. Section 3001(c)(9)(D)(i) requires the publication on ASTP/
ONC's website of a list of the health information networks (HINs) that 
have adopted the Common Agreement and are capable of trusted exchange 
pursuant to the Common Agreement. Section 3001(c)(9)(D)(ii) requires 
HHS to establish, through notice and comment rulemaking, a process for 
HINs that voluntarily elect to adopt TEFCA to attest to such adoption.

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) 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 not a significant regulatory action under section 3(f) of 
Executive Order 12866. Accordingly, we have not prepared a detailed 
Regulatory Impact Analysis (RIA). We did, however, include some 
quantitative analysis of the costs and benefits of this final rule.

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 amended the Public 
Health Service Act (PHSA) and created ``Title XXX--Health Information 
Technology and Quality'' (Title XXX) to improve healthcare 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 the HITECH Act by modifying or 
adding certain provisions to the PHSA relating to health IT.
ONC Health IT Certification Program Rules
    Section 3001(c)(5) of the PHSA provides the National Coordinator 
with the authority to establish a certification program or programs for 
the voluntary certification of health IT. Section 3001(c)(5)(A) 
specifies that the National Coordinator, in consultation with the 
Director of the National Institute of Standards and Technology (NIST), 
shall keep or recognize a program or programs for the voluntary 
certification of health IT that is in compliance with applicable 
certification criteria adopted under section 3004 of the PHSA.

[[Page 101774]]

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).
Trusted Exchange Framework and Common Agreement
    Section 4003(b) of the Cures Act added section 3001(c)(9)(B)(i) to 
the PHSA, which requires the National Coordinator ``to convene 
appropriate public and private stakeholders'' with the goal of 
developing or supporting a Trusted Exchange Framework and a Common 
Agreement (collectively, TEFCA) for the purpose of ensuring full 
network-to-network exchange of health information. Section 
3001(c)(9)(B) outlines provisions related to the establishment of a 
Trusted Exchange Framework for trust policies and practices and a 
Common Agreement for exchange between health information networks 
(HINs)--including provisions for the National Coordinator, in 
collaboration with the NIST, to provide technical assistance on 
implementation and pilot testing of TEFCA. Section 3001(c)(9)(C) 
requires the National Coordinator to publish TEFCA on its website and 
in the Federal Register. Section 3001(c)(9)(D)(i) requires the National 
Coordinator to publish a list of HINs that have adopted TEFCA. Section 
3001(c)(9)(D)(ii) requires the Secretary to establish a process for 
HINs to attest that they have adopted TEFCA.

B. Regulatory History

    The Secretary issued an interim final rule with request for 
comments on January 13, 2010, ``Health Information Technology: Initial 
Set of Standards, Implementation Specifications, and Certification 
Criteria for Electronic Health Record Technology'' (75 FR 2014), which 
adopted an initial set of standards, implementation specifications, and 
certification criteria. On March 10, 2010, the Secretary issued a 
proposed rule, ``Proposed Establishment of Certification Programs for 
Health Information Technology'' (75 FR 11328), that proposed both 
temporary and permanent certification programs for the purposes of 
testing and certifying health IT. A final rule establishing the 
temporary certification program was published on June 24, 2010, 
``Establishment of the Temporary Certification Program for Health 
Information Technology'' (75 FR 36158), and a final rule establishing 
the permanent certification program was published on January 7, 2011, 
``Establishment of the Permanent Certification Program for Health 
Information Technology'' (76 FR 1262).
    We have engaged in multiple rulemakings to update standards, 
implementation specifications, certification criteria, and the Program, 
a history of which can be found in the October 16, 2015, final rule, 
``2015 Edition Health Information (Health IT) Certification Criteria, 
2015 Edition Base Electronic Health Record (EHR) Definition, and ONC 
Health IT Certification Program Modifications'' (80 FR 62602) (2015 
Edition Final Rule). The history can be found at 80 FR 62606. A final 
rule making corrections and clarifications was published for the 2015 
Edition Final Rule on December 11, 2015 (80 FR 76868), to correct 
preamble and regulatory text errors and clarify requirements of the 
Common Clinical Data Set (CCDS), the 2015 Edition privacy and security 
certification framework, and the mandatory disclosures for health IT 
developers.
    The 2015 Edition Final Rule established a new edition of 
certification criteria (``2015 Edition health IT certification 
criteria'' or ``2015 Edition'') and a new 2015 Edition Base EHR 
definition. The 2015 Edition established the minimum capabilities and 
specified the related minimum standards and implementation 
specifications that Certified EHR Technology (CEHRT) would need to 
include to support the achievement of ``meaningful use'' by eligible 
clinicians, eligible hospitals, and critical access hospitals under the 
Medicare and Medicaid EHR Incentive Programs (EHR Incentive Programs) 
(now referred to as the Promoting Interoperability Programs and the 
Promoting Interoperability performance category under MIPS) when the 
2015 Edition is required for use under these and other programs 
referencing the CEHRT definition. The final rule also adopted a 
proposal to change the Program's name to the ``ONC Health IT 
Certification Program'' from the ONC HIT Certification Program, 
modified the Program to make it more accessible to other types of 
health IT beyond EHR technology and for health IT that supports care 
and practice settings beyond the ambulatory and inpatient settings, and 
adopted new and revised Principles of Proper Conduct (PoPC) for ONC-
ACBs.
    After issuing a proposed rule on March 2, 2016, ``ONC Health IT 
Certification Program: Enhanced Oversight and Accountability'' (81 FR 
11056), we published a final rule by the same title (81 FR 72404) (EOA 
Final Rule) on October 19, 2016. The EOA Final Rule finalized 
modifications and new requirements under the Program, including 
provisions related to our role in the Program. The final rule created a 
regulatory framework for our direct review of health IT certified under 
the Program, including, when necessary, requiring the correction of 
non-conformities found in health IT certified under the Program and 
suspending and terminating certifications issued to Complete EHRs and 
Health IT Modules. The final rule also set forth processes for us to 
authorize and oversee accredited testing laboratories under the 
Program. In addition, it included provisions for expanded public 
availability of certified health IT surveillance results.
    On March 4, 2019, the Secretary published a proposed rule titled 
``21st Century Cures Act: Interoperability, Information Blocking, and 
the ONC Health IT Certification Program'' (84 FR 7424) (ONC Cures Act 
Proposed Rule). 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. 
We also requested comment in the ONC Cures Act Proposed Rule (84 FR 
7467) as to whether certain health IT developers should be required to 
participate in TEFCA as a means of providing assurances to their 
customers and ONC that they are not taking actions that constitute 
information blocking or any other action that may inhibit the 
appropriate exchange, access, and use of EHI, with the goal of 
developing or supporting TEFCA for the purpose of ensuring full 
network-to-network exchange of health information.
    On May 1, 2020, the ONC Cures Act Final Rule was published (85 FR 
25642). The final rule implemented certain provisions of the Cures Act, 
including Conditions and Maintenance of Certification requirements for 
health IT developers, the voluntary certification of health IT for use 
by pediatric health providers, and 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, and the implementation of

[[Page 101775]]

information blocking policies that support patient electronic access. 
Additionally, the final rule modified the 2015 Edition health IT 
certification criteria and Program in other ways to advance 
interoperability, enhance health IT certification, and reduce burden 
and costs, as well as improving patient and health care provider access 
to EHI and promoting 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 
healthcare 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, the Secretary published a proposed rule titled 
``Health Data, Technology, and Interoperability: Certification Program 
Updates, Algorithm Transparency, and Information Sharing'' (88 FR 
23746) (HTI-1 Proposed Rule). 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 criterion 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 Secretary issued the ``Health Data, 
Technology, and Interoperability: Certification Program Updates, 
Algorithm Transparency, and Information Sharing'' final rule (HTI-1 
Final Rule), 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 Program updates included revised certification criteria 
for ``decision support interventions,'' ``patient demographics and 
observations,'' and ``electronic case reporting,'' as well as adopted a 
new baseline version of the USCDI standard, USCDI Version 3. 
Additionally, the HTI-1 Final Rule provided enhancements to support 
information sharing under the information blocking regulations. 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 Secretary published a proposed rule titled 
``Health Data, Technology, and Interoperability: Patient Engagement, 
Information Sharing, and Public Health Interoperability'' (89 FR 63498) 
(HTI-2 Proposed Rule). The HTI-2 Proposed Rule sought to advance 
interoperability, improve transparency, and support the access, 
exchange, and use of electronic health information through 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 the reliability, privacy, security, and trust within TEFCA. 
This final rule is the second ``Health Data, Technology, and 
Interoperability'' final rule that seeks to advance interoperability, 
improve transparency, and support the access, exchange, and use of 
electronic health information.

III. ONC Health IT Certification Program

A. Administrative Updates

1. Updates Pursuant to 2014 Edition Removal
    We proposed to remove the ``Complete EHR'' and ``EHR Module'' terms 
from certain sections within subpart E of 45 CFR part 170 because by 
the time we would finalize any proposal in a final rule, the terms 
would no longer be relevant (89 FR 63614). As described below, due to 
the amount of time that has elapsed since the June 30, 2020, effective 
date of the ONC Cures Act Final Rule's removal of the 2014 Edition from 
subparts A, B, and C of part 170, we believe removing obsolete terms as 
the Program evolves over time maintains clarity of the regulatory text 
and Program provisions, particularly for regulated entities and 
interested parties.
a. Removal of ``Complete EHR'' References
    Because the ability to maintain Complete EHR certification was only 
permitted with health IT certified to the 2014 Edition certification 
criteria, the ``Complete EHR'' concept was discontinued for the 2015 
Edition (80 FR 62719). In order to finalize removal of the 2014 
Edition, the ONC Cures Act Final Rule removed the 2014 Edition 
certification criteria in Sec.  170.314 from the Program regulations in 
45 CFR part 170, Sec.  170.545, and references to ``Complete EHR'' from 
the regulation text (85 FR 25655 through 25656). In the HTI-1 Final 
Rule, we removed the ``Complete EHR'' language from all reference 
points in Sec. Sec.  170.523 and 170.524 (89 FR 1209 through 1210).
    However, as explained in the HTI-2 Proposed Rule (89 FR 63614), 
until now, we have retained references to ``Complete EHRs'' in certain 
provisions within subpart E of 45 CFR part 170:
     The definition of ``gap certification'' (Sec.  170.502).
     Authorization scope for ONC-ATL status (Sec.  170.511).
     Requirements for ONC-ACBs to refund fees to developers 
seeking certification under certain circumstances (Sec.  
170.523(j)(3)).
     Applicability of a newer version of a minimum standard 
(Sec.  170.555(b)(2)).
    The ``Complete EHR'' concept remained relevant for supporting 
continuity through these provisions at that time because the 2014 
Edition was not removed from the CFR until the ONC Cures Act Final Rule 
(85 FR 25655). As explained in the HTI-2 Proposed Rule, the ONC Cures 
Act Final Rule became effective on June 30, 2020,

[[Page 101776]]

and records for the 2014 Edition were required to be retained 
(including Complete EHRs) until June 30, 2023, under 45 CFR 
170.523(g)(1) (89 FR 63614).
    However, beginning with the 2015 Edition, Complete EHR 
certifications could no longer be issued and December 31, 2023, has 
passed. Thus, we proposed to remove references to ``Complete EHRs'' 
from the provisions listed above as of the effective date of this final 
rule.
b. Removal of ``EHR Modules'' References
    As explained in the 2015 Edition Final Rule (80 FR 62604), in order 
to better reflect the scope of ONC's authority under the PHSA (section 
3000(5)) and to make the Program more open and accessible, we replaced 
the term ``EHR Module'' with ``Health IT Module.''
    As noted above, consistent with the three-year records retention 
requirement for ONC-ACBs (45 CFR 170.523(g)(1)), June 30, 2023, marked 
the end of a three-year minimum retention period (36 calendar months) 
since we finalized, in the ONC Cures Act Final Rule, the removal of the 
2014 Edition from 45 CFR part 170, subparts A, B, and C (85 FR 25656). 
Similarly, December 31, 2023, marked the end of the third calendar year 
following the calendar year in which the ONC Cures Act Final Rule 
became effective. Because we passed both rules' three-year retention 
requirements for ONC-ACBs and the term ``EHR Module'' is no longer 
relevant, we proposed to remove from Sec.  170.523(f) reference to 
``EHR Modules.'' In the HTI-2 Proposed Rule (89 FR 63614 through 
63615), we included the explanation for removing the term ``EHR 
Modules'' from Sec.  170.523(f) in the preamble. However, we 
erroneously neglected to include the removal of ``EHR Modules'' in the 
regulatory text for Sec.  170.523(f). Because we included our intent to 
remove all of the references to EHR Modules in the HTI-2 Proposed Rule 
and there were no comments on the removal of the term generally, we 
have included the revision to the regulatory text for Sec.  170.523(f) 
in this final rule.
    Comments. We did not receive any comments in response to our 
proposals to remove the terms ``Complete EHR'' and ``EHR Module.''
    Response. Because these terms are no longer relevant and retaining 
them may cause confusion for the public, we have adopted our proposals 
without revisions.
2. Removal of Time-Limited Criteria
    In the ONC Cures Act Final Rule, we finalized Sec.  170.550(m) 
``time-limited certification and certification status for certain 2015 
Edition certification criteria,'' which provided that for five specific 
certification criteria, an ONC-ACB may only issue a certification to a 
Health IT Module and permit continued certified status for a specified 
time period (85 FR 25952). The five criteria with time-limited 
certification and certification status are the ``drug-formulary and 
preferred drug list checks'' certification criterion (Sec.  
170.315(a)(10)), ``patient-specific education resources'' (Sec.  
170.315(a)(13)), ``data export'' certification criterion (Sec.  170.315 
(b)(6)), ``secure messaging'' certification criterion (Sec.  
170.315(e)(2)), and ``application access--data category request'' 
(Sec.  170.315(g)(8)). Because the specified time periods for 
certification to these criteria have elapsed, we proposed to remove all 
of the certification criteria referenced in Sec.  170.550(m) in one 
action by removing and reserving Sec.  170.550(m) in its entirety (89 
FR 63615 and 63616). We also proposed to remove and reserve these 
aforementioned certification criteria from the specific CFR locations 
in which they are adopted. In the ONC Cures Act Final Rule, we also 
finalized revisions in Sec.  170.315(b)(7)(ii) and (b)(8)(i)(B) to 
allow security tagging of Consolidated-Clinical Document Architecture 
(C-CDA) documents at the document level only for the period until 24 
months after publication date of the final rule (85 FR 25667). Because 
that time period has elapsed, we proposed to revise Sec.  170.315(b)(7) 
and (8) to remove Sec.  170.315(b)(7)(ii) and (b)(8)(i)(B) (89 FR 
63616).
    Comments. The majority of comments received on this proposal 
objected in particular to the removal of the ``patient-specific 
education resources'' certification criterion in Sec.  170.315(a)(13). 
They stated that while innovation has progressed, patient-specific 
educational resources remain essential in supporting clinicians during 
patient interactions. Another commenter expressed concern over the lack 
of Fast Healthcare Interoperability Resources (FHIR[supreg])-based 
standards for patient education resources. The commenter stated that 
although some patient education resources align with FHIR standards to 
bolster patient engagement, no specific FHIR standards align with the 
HL7 Context-Aware Knowledge Retrieval (Infobutton) standard. The same 
commenter recommended that until clear FHIR standards are established, 
patient education resources should be codified in regulations and EHR 
certification criteria. One commenter stated that while automation and 
algorithms have advanced, this technology is not universally available 
or fully developed across all health IT systems and removing this 
criterion could create a gap in systems where this capability is less 
robust, particularly in underserved communities. One commenter stated 
that providing patient-specific educational resources contributes to 
better long-term outcomes, supporting chronic disease management, 
treatment adherence, and overall public health. Another commenter 
suggested that instead of eliminating the certification, updating the 
criterion to reflect advancements in automation and AI-driven patient 
education would encourage ongoing innovation.
    Response. We thank commenters for providing feedback on the removal 
of ``patient-specific education resources'' certification criterion in 
Sec.  170.315(a)(13). However, we believe commenters expressing 
specific concerns about maintaining the criterion may have 
misunderstood the proposal. The discussion of removing the ``patient-
specific education resources'' certification criterion in Sec.  
170.315(a)(13) and the decision to end its applicability within the 
Program as of January 1, 2022, was finalized in the ONC Cures Act Final 
Rule. In the ONC Cures Act Final Rule, we finalized Sec.  170.550(m), 
``Time-limited certification and certification status for certain ONC 
Certification Criteria for Health IT,'' which provided that for five 
specific certification criteria, an ONC-ACB may only issue a 
certification to a Health IT Module and permit continued certified 
status for a specified time period (85 FR 25952). One of those criteria 
included the ``patient-specific education resources'' certification 
criterion in Sec.  170.315(a)(13).
    Specifically, in the ONC Cures Act Final Rule, we finalized 
requirements in Sec.  170.550(m)(1) permitting ONC-ACBs to issue 
certificates for the ``patient-specific education resources'' 
certification criterion in Sec.  170.315(a)(13) up until January 1, 
2022 (85 FR 25661). We stated that we believed that health IT's 
capabilities to identify appropriate patient education materials was 
widespread among health IT developers and their customers, and noted 
innovation had occurred for these capabilities, including the use of 
automation and algorithms to provide appropriate education materials to 
patients in a timely manner (85 FR 25661). In addition, the ``patient-
specific education resources''

[[Page 101777]]

certification criterion in Sec.  170.315(a)(13) included no means to 
advance innovations such as FHIR-based educational resources or 
patient-engagement applications. Therefore, in the ONC Cures Act Final 
Rule we also stated that we believed this certification criterion was 
no longer the best way to encourage innovation and advancement in the 
capabilities of health IT to support clinician-patient interactions and 
relationships (85 FR 25661).
    As the discussion of removing the ``patient-specific education 
resources'' certification criterion in Sec.  170.315(a)(13) and the 
decision to end its applicability within the Program as of January 1, 
2022, was finalized in the ONC Cures Act Final Rule seems to have been 
misunderstood by those commenters, we believe those comments are not 
applicable to our proposal and out of scope for this rulemaking. We 
have finalized the proposal to remove and reserve Sec.  170.315(a)(13).
    We did not receive comments on the other proposals to remove time-
limited certification criteria. Therefore, except as to the modified 
reference or references to `ASTP/ONC,' we have finalized as proposed 
and remove and reserve those criteria. We have also finalized the 
proposal to revise Sec.  170.315(b)(7) and (8) to remove Sec.  
170.315(b)(7)(ii) and (b)(8)(i)(B), which were time-limited provisions 
(now expired) that permitted health IT to demonstrate security tagging 
of C-CDA documents at the document level.
3. Privacy and Security Framework Incorporation of DSI Criterion
    In the ONC HTI-1 Final Rule, we established a revised certification 
criterion (``decision support interventions'' (Sec.  170.315(b)(11))) 
to replace the ``clinical decision support'' certification criterion 
(Sec.  170.315(a)(9)) effective January 1, 2025 (89 FR 1196 through 
1197). However, we neither proposed nor finalized corresponding privacy 
and security certification requirements for Health IT Modules 
certifying to the ``decision support interventions'' certification 
criterion. This omission was an oversight. In the HTI-2 Proposed Rule, 
we proposed to add the ``decision support interventions'' certification 
criterion (Sec.  170.315(b)(11)) to the list of certification criteria 
in Sec.  170.550(h)(3)(ii) (89 FR 63616).
    To provide developers of certified health IT time to comply with 
these proposed requirements, we specifically proposed to require, in 
Sec.  170.550(h)(3)(ii), that Health IT Modules certified to the 
``decision support interventions'' (Sec.  170.315(b)(11)) must also be 
certified to the specific privacy and security certification criteria 
on and after January 1, 2028. We stated that these specific privacy and 
security certification criteria are: ``authentication, access control, 
and authorization'' in Sec.  170.315(d)(1); ``auditable events and 
tamper-resistance'' in Sec.  170.315(d)(2); ``audit report(s)'' in 
Sec.  170.315(d)(3); ``automatic access time-out'' in Sec.  
170.315(d)(5); ``emergency access'' in Sec.  170.315(d)(6); ``end-user 
device encryption'' in Sec.  170.315(d)(7); ``encrypt authentication 
credentials'' in Sec.  170.315(d)(12); and ``multi-factor 
authentication'' in Sec.  170.315(d)(13). In the HTI-2 Proposed Rule 
preamble (89 FR 63616), when listing the specific privacy and security 
certification criteria that a Health IT Module certified to the 
``decision support interventions'' (Sec.  170.315(b)(11)) certification 
criterion must also be certified to, we neglected to include 
``emergency access'' in Sec.  170.315(d)(6). However, because we 
stated, in the HTI-2 Proposed Rule, that we were proposing to require 
in Sec.  170.550(h)(3)(ii) that Health IT Modules certified to the 
``decision support interventions'' (Sec.  170.315(b)(11)) must also be 
certified to the specific privacy and security certification criteria 
on and after January 1, 2028, and because Sec.  170.315(d)(6) is one of 
the specific privacy and security certification criteria referenced in 
Sec.  170.550(h)(3)(ii), we believe that the public was informed of the 
requirement to certify to Sec.  170.315(d)(6) as well despite our 
erroneous omission in the preamble.
    Comments. We did not receive any comments specific to this proposal 
to add the ``decision support interventions'' certification criterion 
(Sec.  170.315(b)(11)) to the list of certification criteria in Sec.  
170.550(h)(3)(ii). We did, however, receive comments addressing other 
provisions related to decision support interventions and timelines that 
are beyond the scope of this final rule and are still being reviewed 
and considered for purposes of issuing subsequent final rules for such 
proposals in the future.
    Response. Except as to the modified reference or references to 
`ASTP/ONC,' we have finalized this provision as proposed.

B. Correction--Privacy and Security Certification Framework

    We proposed to make a correction to the Privacy and Security 
Certification Framework in Sec.  170.550(h) (89 FR 63508). We revised 
Sec.  170.550(h) in the ONC Cures Act Final Rule but intended for Sec.  
170.550(h)(4) to remain unchanged. However, when we drafted the 
amendatory instructions, we erroneously included the instruction to 
revise all of paragraph (h) (85 FR 25952). Due to this error, when the 
CFR was updated, Sec.  170.550(h)(4) was removed. Therefore, we 
proposed to add Sec.  170.550(h)(4) back to the CFR [45 CFR 
170.550(h)(4) (Jan. 1, 2020)] as it existed prior to the ONC Cures Act 
Final Rule (89 FR 63508). We included the complete language to be added 
to Sec.  170.550(h) in the proposed and in the regulatory text of this 
final rule so that there is sufficient notice of the language that was 
previously omitted.
    Comments. We did not receive any comments on this proposal.
    Response. We have corrected this provision in this final rule to 
add Sec.  170.550(h)(4) back in the CFR.

IV. Information Blocking Enhancements--Part 171, Subpart D (TEFCA\TM\)

    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). We proposed to 
revise two existing exceptions in subpart B of 45 CFR part 171 
(Sec. Sec.  171.202 and 171.204). 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) and (3) and (b) of Sec.  171.204 (89 FR 
63622 through 63628 and 63803). We proposed two new exceptions, one in 
each in subparts B and C of part 171. The Protecting Care Access 
Exception was proposed as new Sec.  171.206 (89 FR 63627 through 63639 
and 63804) and the Requestor Preferences Exception as new Sec.  171.304 
(89 FR 63639 through 63642, 63804 and 63805). We proposed to codify in 
Sec.  171.401 definitions of certain terms relevant to the Trusted 
Exchange Framework and Common Agreement\TM\ (TEFCA\TM\) (89 FR 63642, 
63804, and 63805) and in 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). Lastly, we solicited comment on potential revisions 
to the TEFCA Manner Exception in subpart D (Sec.  171.403).

[[Page 101778]]

    In this final rule, we only address comments on the proposal to 
codify definitions of certain TEFCA terms in Sec.  171.401 and comments 
received in response to our potential revisions to the TEFCA Manner 
Exception. All other information blocking (part 171) proposals from the 
HTI-2 Proposed Rule and comments received on those proposals are beyond 
the scope of this final rule but may be a subject of another final 
rule.
    In the HTI-2 Proposed Rule (89 FR 63642 and 63643), we discussed 
that in the HTI-1 Proposed Rule (88 FR 23872), we proposed to add a 
TEFCA manner condition to the proposed revised and renamed Manner 
Exception. In the HTI-2 Proposed Rule, we re-stated that this approach 
``aligns with the Cures Act's goals for interoperability and the 
establishment of TEFCA by acknowledging the value of TEFCA in promoting 
access, exchange, and use of EHI in a secure and interoperable way'' 
(88 FR 23872). In the HTI-1 Final Rule (89 FR 1437), in part 171, we 
finalized a new subpart D, ``Exceptions That Involve Practices Related 
to Actors' Participation in The Trusted Exchange Framework and Common 
Agreement (TEFCA).'' We noted that the new subpart consists of three 
sections, Sec.  171.400, ``Availability and effect of exceptions,'' 
which mirrors Sec. Sec.  171.200 and 171.300, stating that a practice 
shall not be treated as information blocking if the actor satisfies an 
exception to the information blocking provision as set forth in subpart 
D by meeting all applicable requirements and conditions of the 
exception at all relevant times (89 FR 1388). We reserved Sec.  171.401 
for definitions in a future rulemaking, and also reserved Sec.  171.402 
for future use. In Sec.  171.403 we finalized a new TEFCA Manner 
Exception based on the TEFCA manner condition we proposed in HTI-1 
Proposed Rule.

A. Definitions

    While we reserved Sec.  171.401 for possible future use as a 
``definitions'' section in the HTI-1 Final Rule, we declined to 
finalize any definitions in the HTI-1 Final Rule. Instead, we referred 
readers to the definitions in the most recent version of the Common 
Agreement (88 FR 76773) for the terms relevant to the new exception (89 
FR 1388). For example, we noted that when we referred to Framework 
Agreement(s), we meant any one or combination of the Common Agreement, 
a Participant-QHIN Agreement, a Participant-Subparticipant Agreement, 
or a Downstream Subparticipant Agreement, as applicable (86 FR 76778). 
We noted that this approach would allow us to maintain consistency and 
harmony between the Common Agreement and the new subpart D regulatory 
text.
    In the HTI-2 Proposed Rule, we proposed to include definitions in 
Sec.  171.401 by cross-referencing the TEFCA definitions included in 
the proposed new 45 CFR part 172, ``Trusted Exchange Framework and 
Common Agreement.'' We specifically proposed to adopt in Sec.  171.401 
the definitions from Sec.  172.102 for the following terms: Common 
Agreement, Framework Agreement, Participant, Qualified Health 
Information Network or QHIN\TM\, and Subparticipant. The definitions 
would apply to all of subpart D.
    Comments. We did not receive any comments regarding our proposal to 
adopt in Sec.  171.401 the definitions from 45 CFR part 172, ``Trusted 
Exchange Framework and Common Agreement,'' for the terms: Common 
Agreement, Framework Agreement, Participant, Qualified Health 
Information Network or QHIN, and Subparticipant. Comments regarding the 
substance of those definitions are addressed in section V. of this 
final rule.
    Response. We have finalized the definitions as proposed. The above 
terms will have the meaning given to them in Sec.  172.102.

B. TEFCA\TM\ Manner Exception

    As briefly discussed above, we finalized a new TEFCA Manner 
Exception in the HTI-1 Final Rule. In the HTI-1 Final Rule, we stated 
that the TEFCA Manner Exception (Sec.  171.403) provides that an 
actor's practice of limiting the manner in which it fulfills a request 
to access, exchange, or use EHI to be providing such access, exchange, 
or use to only via TEFCA will not be considered information blocking 
when it follows certain conditions (89 FR 1388). Those conditions 
require that (1) the actor and requestor both be part of TEFCA; (2) 
that the requestor is capable of such access, exchange, or use of the 
requested EHI from the actor via TEFCA; and (3) any fees charged by the 
actor and the terms for any license of interoperability elements 
granted by the actor in relation to fulfilling the request are required 
to satisfy, respectively, the Fees Exception (Sec.  171.302) and the 
Licensing Exception (Sec.  171.303). In addition to these three 
requirements, we noted (89 FR 63643) that we also included a limitation 
in Sec.  171.403(c), stating that the exception is available only if 
the request is not made via the standards adopted in 45 CFR 170.215, 
which include the FHIR Application Programming Interface (API) 
standards.
    We noted (89 FR 63643) that our finalized TEFCA Manner Exception 
differed from the proposed TEFCA manner condition in two ways. First, 
when we proposed the TEFCA manner condition, we stated that the Fees 
Exception and the Licensing Exception would not apply, because ``we 
mistakenly assumed that all actors participating in TEFCA would have 
already reached overarching agreements on fees and licensing such that 
there would be no need for application of the Fees and Licensing 
Exceptions'' (89 FR 1389). We stated that we believe that by soliciting 
comments specifically on this point, we provided notice to parties that 
we either would or would not apply the Fees and Licensing Exceptions. 
In response to our proposal in the HTI-1 Proposed Rule, some commenters 
expressed concern that because the Common Agreement prohibits fees 
between QHINs\TM\ but is otherwise silent on fees between Participants 
and Subparticipants, the proposal could allow actors to charge fees to 
access, exchange, or use EHI that did not comply with the Fees or 
Licensing Exceptions. Some commenters also expressed that this could 
have the effect of disincentivizing participation in TEFCA and could 
cause actors to use other options of electronic exchange outside of 
TEFCA, where the actors believed the Fees and Licensing Exceptions 
would apply. As such, in the HTI-1 Final Rule, we finalized the TEFCA 
Manner Exception to include that any fees charged by the actor, and any 
licensing of interoperability elements, must satisfy the Fees Exception 
(Sec.  171.302) and the Licensing Exception (Sec.  171.303) (89 FR 
1389). In the HTI-2 Proposed Rule, we stated that while we continue to 
believe that it was clear that the alternative would be to apply the 
exceptions, we requested comment on whether there are drawbacks to 
applying the Fees and Licensing Exceptions, and if we should continue 
to apply them to the TEFCA Manner Exception as currently required in 
Sec.  171.403(d).
    We noted (89 FR 63643) that the other change made to the proposed 
TEFCA manner condition was the limitation that carves out requests made 
for access, exchange, or use of EHI via FHIR API standards (89 FR 
1389). We finalized this limitation in response to comments noting that 
a request could be made for access, exchange, or use via FHIR-based API 
and an actor could respond in a different manner and satisfy the 
exception (89 FR 1390 and 1391). Commenters on the HTI-1 Proposed Rule 
further noted that this potential

[[Page 101779]]

outcome could undermine our stated purpose in incentivizing TEFCA 
participation with the new exception (See 89 FR 1390). In the HTI-2 
Proposed Rule (89 FR 63643), we solicited comment on this limitation 
within the TEFCA Manner Exception for requests via FHIR API standards. 
For example, we solicited comment on whether the limitation should be 
expanded to include exchange based on versions of the FHIR standards 
that are more advanced than those adopted in 45 CFR 170.215 or approved 
through the 45 CFR 170.405(b)(8), ``Standards Version Advancement 
Process--voluntary updates of certified health IT to newer versions of 
standards and implementation specifications.'' We noted that as of the 
time we issued the HTI-2 Proposed Rule, the limitation would only cover 
requests made via FHIR API standards codified in Sec.  170.215, 
including standards that may be updated from time to time through Sec.  
170.405(b)(8), which may involve a delay before the version is formally 
approved under Standards Version Advancement Process (SVAP).
    We also sought comment on a different approach (89 FR 63643). We 
noted that eventually all TEFCA QHINs will be required to support 
exchange via FHIR API standards. A Participant or Subparticipant who 
makes a request for access, exchange, or use of EHI via FHIR API will 
at first make such a request through a QHIN, but in time, a Participant 
or Subparticipant could directly request access, exchange, or use of 
EHI via FHIR API standards from another Participant or Subparticipant 
in a different QHIN. We stated that one option would be to sunset the 
limitation in Sec.  171.403(c) once all QHINs can support brokered 
FHIR. Another option would be to sunset the limitation in Sec.  
171.403(c) if all QHINs, Participants and Subparticipants support 
facilitated FHIR exchange. We also stated that as an alternative to 
these options, we could maintain the exception as is, regardless of 
FHIR API adoption among TEFCA entities. We requested comment on all of 
the options, including whether or not the limitation should remain as 
it is currently.
    Comments. The majority of comments we received on whether there are 
drawbacks to applying the Fees and Licensing Exceptions, and if we 
should continue to apply them to the TEFCA Manner Exception as 
currently required in Sec.  171.403(d), were in support of the 
exception as finalized in the HTI-1 Final Rule. Commenters expressed 
appreciation that ASTP/ONC listened to their feedback in response to 
the HTI-1 Proposed Rule and added the Fees and Licensing Exceptions 
applicability to the TEFCA Manner Exception. Commenters noted that 
including the applicability of the Fees and Licensing Exceptions would 
mitigate risks that some organizations could exploit their TEFCA 
participation to consolidate market power and stifle competition.
    Response. We appreciate the commenters' support. We are retaining 
the exception as finalized in HTI-1 Final Rule, such that there will be 
no changes finalized in this final rule and the Fees and Licensing 
Exceptions will apply to an actor seeking to use the TEFCA Manner 
Exception.
    Comments. One commenter recommended modifying the TEFCA Manner 
Exception so that both the requestor and responder must agree on the 
mechanism (FHIR or other transmission protocol) within TEFCA used to 
exchange EHI, in order to accommodate TEFCA participants who may not 
yet have enabled FHIR transactions for TEFCA.
    Response. We appreciate the comment and the opportunity to clarify 
that the exception does not apply to requests made via the standards 
adopted in 45 CFR 170.215, including version(s) of those standards 
approved pursuant to 45 CFR 170.405(b)(8) (the Standards Version 
Advancement Process, or SVAP). The standards adopted in Sec.  170.215 
include the FHIR standards the commenter describes. When actors seek to 
use the TEFCA Manner Exception, as finalized in 45 CFR 171.403, the 
exception includes a ``requestor capability'' condition (Sec.  
171.403(b)) that limits the exception to only be available when the 
requestor is capable of such access, exchange, or use of the requested 
EHI from the actor via TEFCA. Therefore, if the requestor is unable to 
receive the EHI from the actor using a FHIR transaction via TEFCA, this 
exception would not be available to the actor. We believe this provides 
enough flexibility for actors to use this exception when the requestors 
are able to access the requested EHI, while ensuring that actors who do 
not yet have FHIR-based exchange capabilities will not be expected to 
share via FHIR.
    Comments. A few commenters suggested that ASTP/ONC revise the TEFCA 
Manner exception to state that if an actor charges fees to access data 
through TEFCA, the TEFCA Manner Exception will not apply, and the 
requestor would be entitled to EHI through a different manner. One 
commenter stated that ASTP/ONC should state that charging fees to 
access data through TEFCA negates the TEFCA Manner Exception and actors 
that do not provide a secondary method of exchange would be considered 
information blockers.
    Response. We decline to adopt these suggestions. We have retained 
the finalized exception from the HTI-1 Final Rule. We reiterate that 
certain fees are permitted under the Fees Exception, and that an actor 
participating in TEFCA would still be subject to the restrictions of 
the Fees Exception if the actor is seeking to make use of the TEFCA 
Manner Exception (for example, by responding via TEFCA even if the 
request was not received via TEFCA). We note that, per Sec.  
171.403(c), the TEFCA Manner Exception is not available if a requestor 
requests EHI via the standards adopted in 45 CFR 170.215, including 
version(s) of those standards approved pursuant to 45 CFR 
170.405(b)(8). Under those conditions described in Sec.  171.403(c), a 
fee could still be considered an interference if it does not meet the 
requirements of the Fees Exception (or the practice is not covered by 
another exception).
    Comments. Many commenters supported retaining the limitation in the 
TEFCA Manner Exception to exclude requests made via the standards 
adopted in Sec.  170.215. Commenters stated that removing the condition 
in Sec.  171.403(c) could disincentivize joining TEFCA for entities 
seeking to leverage FHIR-based exchange. Some of those commenters also 
suggested that the condition should be removed once everyone exchanging 
data on TEFCA is required to support the more advanced FHIR standard. 
One commenter recommended removing the condition now, and others 
recommending ASTP/ONC consider sunsetting the condition in the future 
but stated that it was premature to do so now. Most commenters 
supported maintaining the condition for now, and recommended ASTP/ONC 
revisit the exception in the future.
    Response. We appreciate the comments and agree that the condition 
remains useful for advancing interoperability as discussed in the HTI-2 
Proposed Rule. We also agree that it is premature to remove the 
condition at this time. As noted above, we are maintaining the TEFCA 
Manner Exception as finalized in the HTI-1 Final Rule.
    Comments. A few commenters expressed concerns that actors who 
participate in TEFCA may seek to use this exception to cover practices 
involving the access, exchange, or use of EHI with entities or 
requestors who do not participate in TEFCA. The commenters asked for 
clarification on this point.
    Response. We appreciate the opportunity to clarify that this

[[Page 101780]]

exception is only available when both the actor and the requestor 
participate in TEFCA as QHINs, Participants, or Subparticipants (Sec.  
171.403(a)). An actor who participates in TEFCA may not use this 
exception to cover any practice related to the access, exchange, or use 
of EHI with an entity who is not a TEFCA QHIN, Participant, or 
Subparticipant.
    Comments. Some commenters expressed concerns related to the ``TEFCA 
SOP XP Implementation: Health Care Operations'' because the standard 
operating procedure (SOP) would allow providers and developers to 
charge health plans to access data under the health care operations 
exchange purpose.
    Response. Commenters correctly point out that health care providers 
and developers of certified health IT (``actors'' for purposes of the 
information blocking regulations) are permitted to charge fees under 
TEFCA for the health care operations exchange purpose as well as other 
exchange purposes.\5\ However, these fees would need to meet the Fees 
Exception (Sec.  171.302) under the information blocking regulations 
and if charged in conjunction with an actor choosing to voluntarily use 
and meet the conditions of the TEFCA Manner Exception. We decline, 
however, to state in this final rule whether any specific fee amount 
that may be charged as a permitted fee under TEFCA meets the conditions 
of the Fees Exception.
---------------------------------------------------------------------------

    \5\ 4.2 Required Information and Permitted Fees and Table 2 at 
https://rce.sequoiaproject.org/wp-content/uploads/2024/08/SOP-Exchange-Purposes_CA-v3_508.pdf.
---------------------------------------------------------------------------

    Comments. We received many comments in response to our question 
regarding whether the limitation should be expanded to include exchange 
based on versions of the FHIR standards that are more advanced than 
those adopted in 45 CFR 170.215 or approved through the 45 CFR 
170.405(b)(8), ``Standards Version Advancement Process--voluntary 
updates of certified health IT to newer versions of standards and 
implementation specifications.'' Some commenters suggested that the 
limitation should only apply to requests made via standards adopted in 
Sec.  170.215 or through the Standards Version Advancement Process 
(SVAP). Some suggested that if the actor supports the more advanced 
FHIR standard that has not yet been adopted, then the actor must 
respond to a request via that standard. The commenters stated that if 
the actor does not support the more advanced FHIR standard at the time 
of the request, then the TEFCA Manner Exception should still be 
available.
    Response. We appreciate the comments. Until adoption of the FHIR 
standard is widespread, we think it is sufficient to reserve the carve-
out only for versions of the FHIR standard adopted under Sec.  170.215 
or approved through the SVAP process. We believe including standards 
approved through the SVAP process, as well as those adopted under Sec.  
170.215, provides the right balance of ensuring newer versions of the 
FHIR standard can be used without expanding the carve-out to the point 
that it subsumes the exception itself.
    Comments. One commenter encouraged us to clarify that the exception 
does not mean an organization participating in TEFCA can or will only 
share data with other organizations participating in TEFCA. Another 
commenter recommended that the mutuality requirement be phased out so 
that an actor's participation in TEFCA allows them to claim the TEFCA 
Manner Exception regardless of the requestor's participation.
    Response. We appreciate the opportunity to draw attention to Sec.  
171.403(a), as finalized in the HTI-1 Final Rule, which states that the 
actor and requestor must both be part of TEFCA for the exception to be 
available. A request to access, exchange, or use EHI that an actor 
receives from a requestor who does not participate in TEFCA as a QHIN, 
Participant, or Subparticipant does not qualify for the TEFCA Manner 
Exception (89 FR 1388). Nor does anything in this exception, or 
anything else in the information blocking regulations, permit a TEFCA 
entity actor to interfere with a non-TEFCA entity's request to access, 
exchange, or use EHI, unless required by law or covered by an 
exception. We decline to adopt the suggestion to remove the mutuality 
requirement because it would be detrimental to exchange and could force 
participation in a voluntary exchange framework. We remind all 
interested parties that participation in TEFCA is voluntary, and no 
actor is required to join TEFCA.
    Comments. Some commenters expressed concerns that the TEFCA Manner 
Exception could have unintended consequences. For example, one 
commenter expressed concern that the TEFCA Manner Exception could tip 
the scales to prioritize TEFCA exchange over all other interoperability 
pathways and noted that TEFCA does not offer solutions to all needs, 
including, for example, write-back capabilities and non-EHI data. A few 
commenters encouraged ASTP/ONC to regularly review the need for the 
TEFCA Manner Exception, and to update or sunset the exception in the 
future.
    Response. We appreciate the comments. We agree that retaining 
multiple pathways to interoperability is important. We will continue to 
monitor the interaction between TEFCA and the TEFCA Manner Exception.
    Comment. One commenter suggested encouraging TEFCA participation by 
expanding the TEFCA Manner Exception. The commenter noted that the 
exception states that if both parties (requestor and responder) 
participate in TEFCA, it is not information blocking to only fulfill 
requests for EHI via TEFCA. The commenter asserted that this 
incentivizes a requestor not to become a TEFCA participant, since the 
exception does not apply against a requestor as long as it is not a 
TEFCA participant. Instead, the commenter suggested that we incentivize 
entities to join TEFCA by adjusting the exception to place a burden on 
any requester who is not currently a TEFCA QHIN, participant, or sub-
participant to explain why joining TEFCA is infeasible or poses an 
undue burden for their request. The commenter stated this would satisfy 
the stated goals of the exception and drive adoption within the 
industry.
    Response. We thank the commenter for their suggestions. These 
suggestions are outside the scope of our solicitation of comments on 
the TEFCA Manner Exception.

V. Trusted Exchange Framework and Common Agreement\TM\

    Section 3001(c)(9)(B)(i) of the PHSA provides the National 
Coordinator with the authority to ``develop or support a trusted 
exchange framework for trust policies and practices and for a common 
agreement for exchange between health information networks.'' The 
components of this Trusted Exchange Framework and Common Agreement\TM\ 
(TEFCA\TM\) include the Trusted Exchange Framework (a common set of 
principles designed to facilitate trust between health information 
networks (HINs)) and the Common Agreement (the agreement Qualified 
Health Information Networks[supreg] (QHINs\TM\) sign), which includes, 
among other provisions, privacy, compliance, and security 
requirements). The Common Agreement also references the QHIN Technical 
Framework (QTF) (which describes technical requirements for exchange 
among QHINs) as well as, where necessary, SOPs. These documents further 
the statute's overall goal of ensuring full network-to-network exchange 
of health information by

[[Page 101781]]

establishing an organizational, operational, and technical floor for 
nationwide interoperability and securely facilitating the exchange of 
information across different networks nationwide.
    By providing a common and consistent approach for the exchange of 
health information across many different networks, TEFCA simplifies and 
significantly reduces the number of separate networks that individuals, 
health care providers, and other interested parties need to be a part 
of in order to access the health information they seek. HINs that 
voluntarily join TEFCA will facilitate exchange in a secure and 
interoperable manner. TEFCA establishes a method for authenticating 
trusted HIN participants, potentially lowering the cost and expanding 
the nationwide availability of secure health information exchange 
capabilities. The establishment of technical services for HINs that 
voluntarily join TEFCA, such as an electronic address directory and 
security services, will help to scale network exchange nationwide. In 
addition, the organizational and operational policies established 
through TEFCA enable the exchange of health information among HINs and 
include minimum conditions required for such exchange to occur.
    Updates in Common Agreement Version 2.1 reflect the latest 
technical specifications, among other changes, including updates to 
network-based exchange using FHIR APIs, which are a cornerstone of the 
interoperability initiatives of not only ASTP/ONC but also of other 
Federal agencies such as the Centers for Medicare & Medicaid Services 
(CMS), Centers for Disease Control and Prevention (CDC), Health 
Resources & Services Administration (HRSA), and U.S. Department of 
Veterans Affairs (VA).
    Under TEFCA, QHINs play an important role in advancing secure, 
standardized health information exchange. QHINs have significant 
organizational and technical capabilities, facilitate exchange at the 
highest level of the TEFCA infrastructure, and are the entities with 
which Participants (and their Subparticipants) connect to engage in 
TEFCA Exchange. ``TEFCA Exchange,'' which we proposed to define in 
Sec.  172.102, means the transaction of electronic protected health 
information (ePHI) between Nodes \6\ using a TEFCA-specific purpose of 
use code, meaning a code that identifies the Exchange Purpose for which 
exchange is occurring. QHINs voluntarily agree to follow certain 
organizational and operational policies that allow Participants 
(entities who have entered into an agreement with the QHIN that 
includes the Participant/Subparticipant Terms of Participation) and 
Subparticipants (entities that have entered into an agreement with a 
Participant or other Subparticipant that includes the Participant/
Subparticipant Terms of Participation) to simplify their operations and 
promote efficiency of scale.
---------------------------------------------------------------------------

    \6\ Node means a technical system that is controlled directly or 
indirectly by a QHIN, Participant, or Subparticipant and that is 
listed in the RCE Directory Service.
---------------------------------------------------------------------------

    QHINs must meet policy and technical requirements under the Common 
Agreement. The QTF and SOPs provide additional information on how QHINs 
meet those requirements. As finalized, QHINs must comply with the 
provisions in this final rule. QHINs also perform an important role by 
ensuring that Participants and Subparticipants meet the requirements of 
TEFCA.
    As we discussed in the HTI-2 Proposed Rule (89 FR 63644), we 
proposed to establish rules in 45 CFR part 172 to implement our 
obligations under section 3001(c)(9)(D) of the PHSA to publish a 
directory of HINs that ``have adopted the common agreement and are 
capable of trusted exchange pursuant to the common agreement'' and to 
establish a process through notice-and-comment rulemaking for HINs to 
attest to adopting TEFCA.
    The provisions also establish the qualifications for HINs to 
receive and maintain Designation as a QHIN capable of trusted exchange 
pursuant to TEFCA, as well as establish procedures governing QHIN 
Onboarding and Designation, suspension, termination, and administrative 
appeals to ONC as described in the sections below. In the HTI-2 
Proposed Rule, we stated that we believe establishing these provisions 
in regulation would strengthen the trust of interested parties in TEFCA 
and support its success at scale.
    Comments. A majority of commenters supported ONC's proposal to 
adopt rules in 45 CFR part 172 regarding TEFCA. A number of commenters 
encouraged ASTP/ONC to prioritize focusing on high-quality data within 
data sharing and creating more equal information exchange to advance 
interoperability.
    Many commenters highlighted that strong TEFCA requirements allow 
organizations who exchange information to avoid national security and 
fraud risk and have protection against outside bad actors. Several 
commenters also expressed support for the implementation of the QTF to 
support data exchange and noted the importance of TEFCA ensuring the 
exchange of reliable and high-quality data.
    Response. We thank commenters for their support of our proposal to 
adopt rules in 45 CFR part 172 regarding TEFCA and their support for 
our implementation of TEFCA. We agree with commenters about the 
importance of TEFCA in advancing interoperability and high-quality data 
exchange. We appreciate commenters' concerns about potential risks of 
data exchange without TEFCA infrastructure. We are working to fulfill 
TEFCA's statutory purpose of ensuring full network-to-network exchange 
of health information, while also recognizing that appropriate 
guardrails and protections for information exchange are needed. We 
agree with commenters who encouraged us to prioritize high-quality data 
and we are also exploring how TEFCA can help improve data quality for 
TEFCA Exchange.
    Comments. Some commenters recommended that ASTP/ONC should codify 
all TEFCA requirements so that TEFCA requirements and applicable SOPs 
not included in the HTI-2 Proposed Rule may be subject to notice and 
comment rulemaking. These commenters also suggested that ASTP/ONC 
should become more involved in enforcing TEFCA requirements and 
providing incentives and removing disincentives for entities to 
participate in TEFCA. Some of these commenters also expressed that 
TEFCA should remain in alignment with Health Insurance Portability and 
Accountability Act of 1996 (HIPAA) \7\ unless there are strong policy 
reasons for TEFCA to diverge from HIPAA. One commenter requested that 
ASTP/ONC clarify within TEFCA any HIPAA interactions and protections 
related to disclosures.
---------------------------------------------------------------------------

    \7\ Public Law 104-191, 110 Stat. 1936.
---------------------------------------------------------------------------

    Response. We appreciate the comments. In the Cures Act, Congress 
directed ONC to convene public-private and public-public partnerships 
to build consensus and develop or support a trusted exchange framework, 
including the Common Agreement (42 U.S.C. 300jj-11(c)(9)(A)). The 
statute provides that the Common Agreement--which must be published in 
the Federal Register, but which is not subject to notice and comment 
(42 U.S.C. 300jj-11(c)(9)(C))--may include a common method for 
authenticating trusted health information network participants, a 
common set of rules for trusted

[[Page 101782]]

exchange, organizational and operational policies to enable the 
exchange of health information among networks, including minimum 
conditions for such exchange to occur, and a process for filing and 
adjudicating noncompliance with the terms of the common agreement (42 
U.S.C. 300jj-11(c)(9)(B)). ASTP/ONC has convened such partnerships, and 
we believe the Common Agreement is generally best developed through 
those channels, as provided for in the Common Agreement to which QHINs 
agree. We believe the current process strikes the right balance between 
ASTP/ONC oversight, public engagement, and the use of a public-private 
partnership to both ensure important input from interested parties and 
maintain flexibility to adapt to the ever-evolving interoperability 
landscape. Finally, TEFCA is aligned with the HIPAA Privacy, Security, 
and Breach Notification Rules in the sense that an entity is able to 
comply with the HIPAA Rules and TEFCA at the same time. But we do not 
agree with commenters who suggest that TEFCA should presumptively copy-
and-paste definitions or requirements from the HIPAA Rules into TEFCA. 
The HIPAA Rules and TEFCA are authorized by different statutes that 
pursue different goals, and while those goals might sometimes overlap, 
other times they might not. In order to recognize overlap between the 
two legal frameworks and reduce regulatory burden while balancing other 
policy interests, including trusted exchange, ASTP/ONC has sometimes 
aligned TEFCA requirements. However, ASTP/ONC may develop definitions 
and requirements within TEFCA that are narrower or broader than 
corresponding definitions and requirements within the HIPAA Rules to 
satisfy competing policy interests and achieve TEFCA's statutory goal 
of ensuring full network-to-network exchange of health information.
    Comments. One commenter recommended that ASTP/ONC require QHINs to 
have a privacy official and a chief information security to monitor 
data privacy. Another commenter specifically expressed support for the 
requirement that any organization aspiring to become a QHIN must adhere 
to specific privacy and security guidelines, with additional 
stipulations for those providing Individual Access Services.
    Response. We appreciate the commenter's support for TEFCA's 
existing privacy and security requirements, as well as the additional 
requirements for QHINs that provide Individual Access Services. 
Regarding the comment recommending that each QHIN be required to have a 
privacy official and a chief information security to monitor data 
privacy, we note that we proposed and have finalized Sec.  
172.201(c)(8), which requires QHINs to maintain privacy and security 
policies that permit the entity to support TEFCA Exchange. The QHIN 
Security Requirements for the Protection of TEFCA Information SOP \8\ 
provides additional information on how that requirement can be met, 
including by QHINs having a chief information security officer (CISO). 
CISOs are responsible for the overall security posture of a QHIN with 
respect to their participation in TEFCA. This includes technical, 
administrative, and physical security safeguards and documentation 
thereof for a QHIN.
---------------------------------------------------------------------------

    \8\ QHIN Security Requirements for the Protection of TEFCA 
Information SOP, https://rce.sequoiaproject.org/wp-content/uploads/2024/08/QHIN-Security-for-the-Protection-of-TI-21.pdf.
---------------------------------------------------------------------------

    Comments. A number of commenters supported ASTP/ONC's approach of 
proposing to codify TEFCA requirements but expressed concern that it 
could be adopting TEFCA requirements into a regulatory framework too 
quickly and requested that ASTP/ONC provide information regarding our 
intentions to adopt other TEFCA requirements in the future. These 
commenters recommended that ASTP/ONC take a cautionary approach and 
potentially delay the adoption of further TEFCA requirements, citing 
that TEFCA is intended to be fluid and evolve more quickly than 
regulations. One commenter also urged ASTP/ONC take care with future 
adoptions of TEFCA requirements that we do not undermine the 
independence of the Recognized Coordinating Entity[supreg] 
(RCE[supreg]).
    Several commenters were concerned that codifying TEFCA hampers the 
ability of TEFCA to change and adapt as needed, and a few of these 
commenters suggested that the codification of TEFCA requirements is 
unnecessary because TEFCA infrastructure is supported by its 
contractional nature. One commenter specifically recommended that ASTP/
ONC incorporate TEFCA and relevant SOPs by reference rather than adopt 
sections of TEFCA as regulations out of concern that adopting sections 
of TEFCA as regulations would undermine the sections of TEFCA that are 
not adopted as a whole and would require future rulemaking actions to 
modify the sections of TEFCA that have been codified as regulations.
    Response. We appreciate commenters' support of our proposals and 
also understand the concerns about the adoption of TEFCA requirements 
in regulation and the need for TEFCA to evolve as the interoperability 
landscape changes. The provisions we have finalized in 45 CFR part 172 
mainly address QHIN appeals (subpart F) and the underlying requirements 
regarding which decisions may ultimately be appealed (subparts B 
through E). We believe establishing QHIN appeal rights in regulation 
will enhance trust in the TEFCA framework, as QHINs--that have invested 
significant time and resources into becoming a QHIN--will know that 
processes exist to appeal decisions that could have a significant 
impact of their businesses and the exchange of information for their 
Participants and Subparticipants. That said, we do not believe it would 
benefit TEFCA to codify all TEFCA requirements in regulation due to the 
need, as commenters noted, for TEFCA to move quickly and evolve with 
the ever-changing interoperability landscape. We appreciate commenters' 
suggestions regarding the future adoption of other TEFCA requirements 
in regulation and will consider them in the future.
    Subpart G in 45 CFR part 172, which addresses QHIN attestation for 
the adoption of the Trusted Exchange Framework and the Common 
Agreement, has been adopted in accordance with statutory requirements. 
Specifically, section 4003(b) of the Cures Act added section 
3001(c)(9), ``Support for Interoperable Networks Exchange,'' to the 
PHSA. Section 3001(c)(9)(D)(ii) requires HHS to establish, through 
notice and comment rulemaking, a process for HINs that voluntarily 
elect to adopt TEFCA to attest to such adoption of the trusted exchange 
framework and common agreement. Section 3001(c)(9)(D)(i) requires the 
National Coordinator to publish on ONC's website a list of the HINs 
that have adopted the Common Agreement and are capable of trusted 
exchange pursuant to the Common Agreement.
    For these reasons, we decline to adopt TEFCA solely through 
incorporation by reference instead of through a regulatory framework.
    We also received numerous comments that were out of scope or that 
recommended that ASTP/ONC adopt new requirements that we did not 
propose and are not addressed in this rulemaking.
    Comments. A number of comments addressed concerns about the role 
and authority of QHINs in relation to TEFCA Participants. Some 
commenters urged

[[Page 101783]]

ASTP/ONC to take a more direct role in monitoring and enforcing 
compliance and bolstering Participant confidence as TEFCA participation 
expands and monitoring by QHINs potentially becomes more difficult. 
Several commenters were concerned that there was no investigative body 
for independent oversight within TEFCA and suggested ASTP/ONC should 
monitor for the possibility of QHINs exercising outsized influence. A 
few commenters recommended that ASTP/ONC create an oversight board, or 
a body associated with the Office of the Inspector General (OIG), to 
provide independent review within TEFCA. These commenters also 
suggested that ASTP/ONC should include a mechanism for patient-
identified issues.
    Some commenters suggested that ASTP/ONC require that a QHIN create 
a continuity plan that includes support for the migration of 
Participants and Subparticipants if a QHIN is terminated or sanctioned. 
Additionally, one commenter requested information on how the TEFCA 
requirements will impact existing SOPs and whether the RCE will 
continue to have the authority to modify requirements for QHINs through 
the SOPs.
    Response. We thank commenters for their feedback. We appreciate 
commenters' concerns regarding the role of QHINs in TEFCA governance 
but have decided not to make any related changes in this final rule. We 
believe QHINs are best positioned to have primary oversight 
responsibility over their customers (i.e., Participants) and should 
have autonomy to make decisions about their networks so long as such 
decisions do not conflict with the requirements for TEFCA Exchange. We 
note that there is strong representative and participatory network 
governance built into the TEFCA infrastructure, including the 
requirement that QHINs must maintain a representative and participatory 
group or groups with the authority to approve processes for governing 
the Designated Network (Sec.  172.201(c)(7)). Regarding the comments 
related to including additional oversight within the TEFCA framework, 
including the suggestion of including HHS OIG in TEFCA governance and 
oversight, we believe that doing so is not necessary and could limit 
the flexibility of TEFCA's public-private model of exchange and 
governance. We believe the oversight provided by ASTP/ONC, including as 
established in provisions we are finalizing in 45 CFR part 172, meets 
the needs of the TEFCA community and provides strong support for TEFCA. 
ASTP/ONC will continue to monitor TEFCA, and we will consider 
additional measures should circumstances arise that show that QHINs 
require additional oversight.
    We appreciate the suggestion regarding creation of a mechanism for 
patient-identified issues and note that there are already mechanisms in 
place for reporting of patient-identified issues. Patients can report 
issues to ASTP/ONC through the TEFCA tab in the Health IT Feedback and 
Inquiry Portal available at https://inquiry.healthit.gov/support/plugins/servlet/desk/portal/2. Patients may also report issues to the 
RCE at https://rce.sequoiaproject.org/contact/. We encourage patients 
to report any issues they are experiencing to ASTP/ONC, the RCE, or 
both so that we can continue to improve TEFCA Exchange.
    We also appreciate the suggestion that we require QHINs to create a 
continuity plan that includes support for the migration of Participants 
and Subparticipants if a QHIN is terminated or sanctioned. We did not 
propose to require a continuity plan in the HTI-2 Proposed Rule and 
believe it would be appropriate for the public to have an opportunity 
to submit comments before we could adopt this type of requirement. 
Therefore, we have decided not to finalize a requirement regarding 
creation of a continuity plan in this final rule. We may consider 
including such a requirement in a future rulemaking. In the meantime, 
we encourage QHINs and their Participants to discuss the details 
regarding continuity of service and consider addressing such details in 
the respective Framework Agreement between the two parties.
    Regarding the comment concerning how the TEFCA requirements will 
impact existing SOPs, we note that the SOPs can be updated to align 
with updated requirements. We expect that the RCE will continue to 
support the development of SOPs, as they have to this point.
    Comments. Multiple commenters raised concerns about the adoption of 
the Exchange Purposes (XPs) SOP version 3.0 without a public comment 
period. These commenters highlighted in particular that the recent XPs 
SOP version 3.0 allows health care providers to charge for data 
exchanges and requested that ASTP/ONC not allow entities to charge fees 
for TEFCA-based data exchanges.
    Response. We thank commenters for raising this concern to our 
attention. While we understand the importance of this issue, it falls 
outside the scope of this final rule. The provisions regarding fees and 
the XP SOP version 3.0 are not addressed within this final rule. We 
encourage further engagement on the topic of fees through public TEFCA 
meetings, webinars, and other feedback opportunities.
    Comments. Several commenters advocated for the inclusion of State, 
Tribal, Local, and Territorial (STLT) public health agencies in the 
governance of TEFCA and QHINs to identify priority use cases. A few of 
these commenters also noted that the exchange of Prescription Drug 
Monitoring Program (PDMP) information through TEFCA is incompatible 
with PDMPs' data confidentiality and privacy requirements and suggested 
that PDMPs be excluded from TEFCA requirements.
    A few commenters additionally noted that there is no Common 
Agreement for advisory boards and suggested that ASTP/ONC recognize 
advisory boards, including or referencing groups such as patients, 
providers, payors, and public health. One commenter recommended that 
TEFCA advisory groups include expanded roles for health plan 
representatives.
    Response. We thank commenters for their input. The involvement of 
state and local public health agencies, as well as advisory boards, in 
TEFCA is an important consideration, and we will consider the related 
suggestions as we implement and refine the TEFCA governance process. We 
encourage interested communities to continue engaging with us as these 
aspects of the TEFCA framework are refined. We welcome all feedback 
from interested parties, which can be submitted via the ASTP/ONC 
website at https://inquiry.healthit.gov/support/plugins/servlet/desk/portal/2/create/61, for consideration and potential inclusion within 
the TEFCA framework.
    We do not understand the comment that there is no Common Agreement 
for advisory boards. We appreciate the suggestion for enhancing TEFCA's 
governance. We are currently considering ways to ensure that different 
groups, such as patients, providers, payors, and public health, are 
represented within TEFCA's governance, which could include the 
development of advisory boards or councils. However, we did not make a 
proposal in this rulemaking regarding advisory boards, and it would be 
appropriate for the public to have an opportunity to submit comments 
before we could adopt these types of changes. We may consider 
addressing this issue in a future rulemaking.
    We appreciate the comment that the exchange of PDMP information 
through TEFCA is incompatible with PDMPs' data confidentiality and 
privacy

[[Page 101784]]

requirements and the suggestion that PDMPs be excluded from TEFCA 
requirements. We have decided not to make any related changes in this 
final rule because we did not make any proposals about PDMPs, and it 
would be appropriate for the public to have an opportunity to submit 
comments before we could adopt these types of changes. We may consider 
addressing this issue in a future rulemaking.
    Comments. Several commenters were concerned that the TEFCA 
requirements prioritize TEFCA participation over other mechanisms of 
interoperability. A few commenters were concerned that the TEFCA 
requirements allow participants to not respond to queries from entities 
that are not TEFCA participants when the data exchange is lawful 
thereby allowing data from certain providers to be siloed. These 
commenters suggested that ASTP/ONC clarify that the refusal by entities 
connected to TEFCA to lawfully exchange data with entities that are not 
licensed health care professionals is information blocking. Commenters 
also requested that ASTP/ONC publish a request for information (RFI) on 
the treatment of all federally defined health care providers under 
TEFCA. One commenter also advocated that TEFCA requirements should 
focus on treatment and individual access exchange.
    Response. We thank commenters for their feedback. The concerns 
raised regarding TEFCA requirements and their interaction with other 
interoperability mechanisms are out of scope for this final rule, since 
the TEFCA requirements do not apply to other mechanisms of 
interoperability. However, we would like to direct commenters to the 
TEFCA Manner Exception in 45 CFR 171.403, finalized in the HTI-1 Final 
Rule (89 FR 1387 through 1388). This exception applies when, among 
other necessary conditions, both the actor and requestor participate in 
TEFCA as QHINs, Participants, or Subparticipants (Sec.  171.403(a); 89 
FR 1388). When the necessary conditions under Sec.  171.403 are met, 
the actor's practice of fulfilling requests for access, exchange, or 
use of EHI exclusively via TEFCA will not be considered information 
blocking. We recommend reviewing this exception for further clarity on 
TEFCA participation and its interplay with information blocking.
    Comments. One commenter expressed concern about the perceived lack 
of intellectual property protections in TEFCA and recommended that 
ASTP/ONC increase intellectual property protections within TEFCA.
    Response. We thank the commenter their feedback. The issue of 
intellectual property protections within TEFCA is outside the scope of 
this final rule, as we did not propose, and this final rule does not 
address, such provisions. We welcome all feedback from interested 
parties, which can be submitted via the ASTP/ONC website at https://inquiry.healthit.gov/support/plugins/servlet/desk/portal/2/create/61, 
for consideration and potential inclusion within the TEFCA framework.
    Comments. A number of commenters who expressed support for TEFCA 
were concerned that compliance with TEFCA requirements could be 
difficult for non-medical specialist entities and entities with limited 
financial or infrastructure resources. Some of these commenters 
recommended that ASTP/ONC and the RCE consider providing educational 
initiatives, incentives, and technical and financial support to 
providers with limited resources that transition to joining TEFCA. 
These commenters also expressed concern that participation fees for 
TEFCA participants should be fair and scaled to the size of and 
potential use by participants and non-duplicative.
    Some commenters requested that ASTP/ONC provide TEFCA Participants 
more time to prepare when new requirements are adopted as part of 
updates to the Common Agreement or when SOPs are updated. One commenter 
also recommended that ASTP/ONC and the RCE establish steps and goals to 
guide how entities will transition to TEFCA participation. One 
commenter recommended that ASTP/ONC adopt more specific definitions of 
Participants and Subparticipants for TEFCA to reduce ambiguity. One 
commenter particularly requested that ASTP/ONC delay requiring 
emergency medical services agencies to comply with TEFCA requirements 
that involve significant technological hurdles or require significant 
financial and infrastructure resources, and that ASTP/ONC convene a 
working group to determine how emergency medical services agencies can 
comply with TEFCA requirements in the future.
    Response. We thank commenters for their feedback. We appreciate 
commenters' concerns about potential financial and technological 
limitations for some entities regarding TEFCA. We are exploring ways to 
assist such entities and ensure that the benefits of TEFCA are not 
disproportionately allocated to larger, for-profit entities. In order 
to inform such efforts, we are focused on collecting and analyzing 
exchange metrics as TEFCA matures to better understand where exchange 
gaps persist.
    We understand that cost is a concern for many organizations, 
particularly small and rural providers. We continue to engage with 
providers to understand these concerns and providers' needs better and 
to develop strategies to assist small and rural providers with TEFCA 
implementation. We are also developing, along with the RCE, various 
resources to clarify various questions about TEFCA participation and 
implementation. We appreciate the request that ASTP/ONC provide TEFCA 
Participants more time to prepare when new requirements are adopted as 
part of updates to the Common Agreement or when SOPs are updated and 
will consider the request as we work to expand TEFCA Exchange and 
update TEFCA requirements over time.
    We also appreciate the recommendation that ASTP/ONC and the RCE 
establish steps and goals to guide how entities will transition to 
TEFCA participation and agree that ASTP/ONC and the RCE should provide 
resources and information to support the transition to TEFCA Exchange. 
As such, ASTP/ONC and the RCE have recently released a plethora of 
resources to assist entities considering transitioning to TEFCA 
Exchange, which are available on the ASTP/ONC \9\ and RCE \10\ 
websites. In addition, we continue to support the transition to TEFCA 
Exchange through regular webinars and information sessions for the 
public.
---------------------------------------------------------------------------

    \9\ https://www.healthit.gov/topic/interoperability/policy/trusted-exchange-framework-and-common-agreement-tefca.
    \10\ https://rce.sequoiaproject.org/tefca/.
---------------------------------------------------------------------------

    We appreciate the recommendation that ASTP/ONC adopt more specific 
definitions of Participants and Subparticipants for TEFCA to reduce 
ambiguity; however, we have not changed the definitions in this final 
rule because we do not believe the definitions are ambiguous.
    Last, we are aware that emergency medical service providers and 
agencies may face obstacles in joining TEFCA, and we are considering 
options for addressing such potential obstacles. We plan to conduct 
additional outreach to the emergency medical service community to 
better understand their concerns and the issues this community faces 
and will consider other ways to assess the issue(s) moving forward.
    Comments. One commenter suggested that ASTP/ONC should mandate that 
health information exchanges respond to every QHIN request with sharing 
data

[[Page 101785]]

and participate in TEFCA with at least one QHIN.
    Response. We thank the commenter for their feedback. This comment 
is out of scope for this rulemaking, and therefore, we decline to adopt 
this suggested change. We also note that we generally believe that 
participation in TEFCA should remain voluntary and decline to mandate 
TEFCA participation.
    Comments. A number of commenters expressed concern about the 
interactions of TEFCA requirements with HIPAA requirements, and with 
other ASTP/ONC and CMS regulations creating an overly complex 
regulatory framework for interoperability. Commenters urged ASTP/ONC to 
ensure that TEFCA requirements are compatible with other 
interoperability and information blocking rulemaking. Another commenter 
also urged ASTP/ONC to collaborate with CMS to provide endpoint 
directories and use RESTful FHIR interoperability protocols.
    These commenters noted the importance of keeping TEFCA 
participation voluntary. A few commenters expressed concern that the 
TEFCA requirements proposed together with other ASTP/ONC and CMS 
regulations will pressure entities to solely engage with entities 
connected to TEFCA.
    Response. We thank commenters for their feedback and appreciate 
commenters' concerns about how TEFCA requirements will interact with 
other regulatory requirements. ASTP/ONC has worked, and will continue 
to work, with our Federal partners, including CMS, in developing and 
implementing TEFCA. We are working to align TEFCA requirements with 
other ASTP/ONC, CMS, and OCR \11\ requirements when possible, and while 
we have not required any entity to participate in TEFCA, we are trying 
to ensure that TEFCA complements other Federal requirements to reduce 
complexity and encourage more seamless nationwide exchange. For 
example, as explained in more detail above, entities are able to comply 
with both HIPAA (HIPAA Privacy, Security, and Breach Notification 
Rules) and TEFCA. While ASTP/ONC may develop definitions and 
requirements within TEFCA that are narrower or broader than 
corresponding definitions and requirements within the HIPAA Rules, 
ASTP/ONC does try to align TEFCA requirements with the requirements in 
the HIPAA Rules when possible.
---------------------------------------------------------------------------

    \11\ The HHS Office for Civil Rights has authority for 
implementing and enforcing HIPAA.
---------------------------------------------------------------------------

    Comment. One commenter recommended that we refer to, prioritize as 
a goal, recognize, or focus on high-quality data within data sharing, 
since one of TEFCA's goals is to create an atmosphere of trust.
    Response. We thank the commenter for their feedback. We agree with 
the importance of data quality within health information exchange. We 
believe our proposals support data quality by advancing the 
standardization of health information exchange and helping to improve 
the completeness and comprehensiveness of data being exchanged. 
However, additional operational aspects and practical implementations 
of data quality measures are beyond the scope of this final rule.
    Comment. Multiple commenters sought clarification on laboratory 
involvement with respect to TEFCA proposals. One commenter requested 
clarification about the participation of laboratories in QHINs and the 
use of TEFCA as a means for health information exchange in the current 
environment, where FHIR functionality is not available. Another 
commenter sought clarification on the value proposition for rerouting 
laboratory results through TEFCA, given that the existing HL7 v2 
messaging framework effectively supports public health reporting. If 
there is value in rerouting, they questioned what requirements must 
QHINs meet to facilitate HL7 v2 messaging. The commenter expressed 
concerns about how the process would introduce additional complexity by 
requiring QHINs to convert HL7 v2 messages into XCDR, which the 
receiving QHIN would then need to extract and forward to the connected 
public health agency. Given these concerns, the commenter suggested 
that ASTP/ONC and the RCE consider selectively endorsing existing 
technologies, such as HL7 v2, to operate under the Common Agreement, 
akin to how eCR reporting is implemented under Carequality.
    Response. We appreciate this feedback, but these comments are out 
of scope for this rule. We did not propose and are not finalizing 
requirements for laboratories to participate in TEFCA or technical 
requirements to facilitate HL7 v2 messaging within TEFCA.
    Comment. One commenter recommended that TEFCA governance documents 
be updated to define responsibilities for Participants and QHINS 
related to disclosures and third-party vetting, as well as how requests 
are intended to operate within the HIPAA framework and who would 
monitor/enforce such requirements.
    Response. We thank the commenter for the feedback. The HTI-2 
Proposed Rule outlines the approach among ONC, the RCE, and QHINs to 
monitor and enforce proposed requirements under TEFCA.
    Comment. One commenter noted that requiring EHRs to demonstrate a 
connection with an established QHIN or with health information 
exchanges for health IT to achieve certification will help ensure 
efficient data sharing and support interoperability goals.
    Response. We appreciate the feedback on our proposals. However, 
this comment is out of scope for this final rule, as we have neither 
proposed nor are we finalizing a requirement for Health IT Modules to 
demonstrate a connection with an established QHIN or with a health 
information exchange for the Health IT Module to obtain certification 
to any criterion or criteria under the ONC Health IT Certification 
Program (Program). Nonetheless, we highlight that, as noted in the HTI-
2 Proposed Rule (89 FR 63510 and 63511), we intend to accomplish the 
overall goal of full network-to-network exchange of health information 
by establishing a floor for interoperability under TEFCA across the 
country. We believe the suggested EHR requirement might conflict with 
our intent to encourage innovation, facilitate incremental progress, 
and promote flexibility.
    Comment. One commenter shared multiple suggestions for encouraging 
TEFCA participation. The commenter noted that TEFCA participation may 
be encouraged by increasing the utility of TEFCA participation to an 
entity's patients. They noted that incorporating a mechanism for 
patients to correct or add to their interoperable records would be 
beneficial. Rather than limiting TEFCA Individual Access Services (IAS) 
requests to access and deletion options, they also suggested providing 
an option for patients to amend or augment their records through a 
patient portal so that these changes could be automatically 
incorporated into their records exchanged through TEFCA.
    Response. We thank the commenter for their suggestions. We agree 
with the value of patient engagement. However, the suggestions are 
beyond the scope of this final rule, as we did not propose and are not 
finalizing related policies specifically designed encourage TEFCA 
participation.

A. Subpart A--General Provisions

    For the purposes of subpart A, we proposed (89 FR 63644) in Sec.  
172.100 of the HTI-2 Proposed Rule the basis, purpose, and scope for 
the proposed TEFCA provisions in 45 CFR part 172.

[[Page 101786]]

We proposed in Sec.  172.100(a) that the basis for these provisions 
would be to implement section 3001(c)(9) of the PHSA (42 U.S.C. 300jj-
11(c)(9)). We proposed in Sec.  172.100(b) the dual purposes of 
proposed part 172: (1) to ensure full network-to-network exchange of 
health information; and (2) to establish a voluntary process for QHINs 
to attest to adoption of the Trusted Exchange Framework and Common 
Agreement. We explained that Sec.  172.100(b)(1) supports the statutory 
basis because the organizational and operational policies covered by 
part 172 would enable the exchange of health information among health 
information networks using the common set of rules found in these 
regulations. We also noted that Sec.  172.100(b)(2) supports the 
statutory basis because it implements section 3001(c)(9)(D) of the 
PHSA. We proposed in Sec.  172.100(c) the scope for part 172, which 
would include: (1) minimum qualifications needed to be Designated as a 
QHIN capable of trusted exchange under TEFCA; (2) procedures governing 
QHIN Onboarding and Designation, suspension, termination, and further 
administrative review; (3) attestation submission requirements for a 
QHIN to attest to its adoption of TEFCA; and (4) ONC attestation 
acceptance and removal processes for publication of the list of 
attesting QHINs in the QHIN Directory.
    In proposed Sec.  172.101, we specified the applicability of part 
172 by proposing that part 172 would apply only to Applicant QHINs, 
QHINs, and terminated QHINs. In the HTI-2 Proposed Rule, we noted that 
our proposed QHIN definition in Sec.  172.102 captures suspended QHINs 
(since a suspended QHIN is still a QHIN) and so we did not address them 
separately in proposed Sec.  172.101. In Sec.  172.102, we proposed 
definitions for certain terms in part 172. In the HTI-2 Proposed Rule, 
we stated that we intended the definitions provided in the Common 
Agreement to be consistent with these proposed definitions. We also 
stated that differences in phrasing would generally be attributable to 
differences in context, though in the case of any true conflict, we 
stated that we intend the regulatory definitions to control.
    Additionally, ASTP/ONC has hired a contractor to help administer 
and implement TEFCA Exchange. This contractor, chosen through a 
competitive solicitation, is known as the RCE. While the RCE is 
currently one entity, in the future, we noted in the HTI-2 Proposed 
Rule, ONC may choose to assign some or all of its responsibilities to a 
different entity or multiple entities. We noted that assigning 
responsibilities to a different or multiple entities in the future 
could, for example, allow for more efficient use of resources or best 
leverage expertise. In Sec.  172.103, ``Responsibilities ONC may 
delegate to the RCE,'' we proposed that ONC may assign certain 
responsibilities to such an entity or entities for these purposes. We 
note that we changed the title of this section from the proposed 
title--``Responsibilities ONC may delegate to the RCE''--to 
``Responsibilities ASTP/ONC may delegate to the RCE'' because of the 
recent change to the name of our office and to conform with similar 
changes made throughout this final rule. In addition to changes to the 
proposed text described below, we have also finalized references to 
``ONC'' in subpart A of the proposed rule to instead refer to ``ASTP/
ONC.'' For further discussion of the use of ``ASTP/ONC,'' please see 
the Executive Summary of this final rule.
    We proposed in Sec.  172.103(a)(1) through (4) that ONC may assign 
any of its responsibilities in subparts C (``QHIN Onboarding and 
Designation Process'') and D (``Suspension'') and Sec. Sec.  172.501 
(``QHIN self-termination'') and 172.503 (``Termination by mutual 
agreement''). In Sec.  172.103(b), we proposed that any authority 
exercised by the RCE under this section is subject to review by ONC 
under subpart F (``Review of RCE Decisions'').
    Comments. One commenter argued that any TEFCA expansion to new 
purposes should be driven by Congressional mandate and conducted 
transparently with opportunities for public input. The commenter 
emphasized that an open process ensures that stakeholders' diverse 
perspectives are considered fully and that the TEFCA framework evolves 
to serve all stakeholders' collective interests. The commenter 
cautioned against mission creep and recommended establishing clear 
guardrails for any future expansion of TEFCA's use cases, including 
rigorous evaluation, comprehensive needs assessments and industry 
engagement. Other commenters advised ASTP/ONC to avoid sub-regulatory 
guidance and instead follow standard rulemaking procedures, including 
60-day public comment periods for proposed changes or additions to 
TEFCA SOPs. One commenter expressed that all substantive issues and 
core concepts, such as, but not limited to, foundational definitions of 
the different exchange purposes, should be codified in regulation 
following the notice and comment rulemaking process, rather than being 
addressed in TEFCA documents such as SOPs, which do not undergo the 
same rigorous review process as do regulations. Another commenter 
further argued that any future regulatory changes should relate back to 
the text of the Cures Act.
    Response. We thank the commenter for the feedback. We have 
developed and implemented TEFCA consistent with the 21st Century Cures 
Act (section 3001(c)(9) of the PHSA, as added by the 21st Century Cures 
Act (Pub. L. 114-255, Dec. 13, 2016)). That statute sets out at least 
one broad statutory purpose: ensuring full network-to-network exchange 
of health information. TEFCA as currently designed furthers that 
purpose. We do agree that TEFCA should generally be related to that 
goal or other ones suggested in the statute--for instance, that the 
exchange should be ``trusted''--but we believe that statute envisions 
that TEFCA will be flexible within that broad goal, consistent with the 
need for flexibility in rapidly developing spaces like health 
information technology and health information exchange. For example, 
section 3001(c)(9)(B) identifies a list of potential topics the Common 
Agreement ``may include,'' but does not require the Common Agreement to 
address those topics or suggest that those topics are the only ones the 
Common Agreement can address.
    We appreciate the commenters' suggestion to follow standard 
rulemaking procedures. As noted previously in this rulemaking, we 
believe the inclusion of TEFCA provisions in this rulemaking will 
strengthen the trust of interested parties in TEFCA and support its 
success at scale. We likewise believe that TEFCA must remain flexible 
and agile, in order to enable nationwide exchange at scale.
    Comments. Commenters supported the general definitions related to 
TEFCA proposed in regulatory text, suggesting that those terms may 
arise in other regulatory programs and can be later cross-referenced.
    Response. We thank commenters for their support and have finalized 
the definitions related to TEFCA we proposed in Sec.  172.102 with some 
modifications based on comments we received and as explained hereafter.
    Comments. One commenter expressed concern about codifying 
definitions from the Common Agreement in regulation and specifically 
identified inconsistencies between the Common Agreement and the 
proposed regulatory definitions. The commenter noted that some 
definitions in the HTI-2 Proposed Rule do not fully align with the 
Common Agreement (e.g., Threat Condition and Recognized Coordinating 
Entity) and some of the definitions (e.g.,

[[Page 101787]]

XP Code) are included in the regulation but not used in the proposed 
regulatory text. The commenter also noted that certain definitions in 
the HTI-2 Proposed Rule refer to applicable SOPs (e.g., the definition 
for Participant/Subparticipant Terms of Participation), while others do 
not--including when the Common Agreement does refer to the SOP. For 
example, Exchange Purposes in the proposed regulatory text omits 
reference to SOPs, though the Common Agreement includes such reference. 
The commenter states that leaving out references to SOPs could change 
the meaning of the Common Agreement and render the SOPs inapplicable. 
The commenter also stated that the term ``Responding Node'' is used in 
the definition of Required Information but not defined in the 
regulation. Further the commenter noted that some definitions refer to 
``ONC (or an RCE)'' (e.g., threat condition), other times there is no 
mention of an RCE, even though the Common Agreement includes such a 
reference (e.g., Qualified Health Information). The commenter suggested 
that differing definitions between the Common Agreement and the 
regulatory text will lead to confusion and misinterpretation. The 
commenter also expressed concern that, if such inconsistencies are 
finalized in the regulatory text, they could necessitate subsequent 
amendments to the Common Agreement that are inconsistent with the 
public input used to establish the definitions in the Common Agreement.
    Response. We appreciate the comments that opined on the potential 
for confusion and misinterpretation related to certain proposed 
definitions. We also appreciate the input related to clear and 
consistent alignment between the regulatory definitions and the Common 
Agreement. As noted in the proposed rule, we intend for the definitions 
in this final rule to be consistent with the definitions in the Common 
Agreement and the SOPs. We have adopted this approach to maintain 
consistency between the Common Agreement and the regulatory text (89 FR 
63642). However, in some cases we used different verbiage in the HTI-2 
Proposed Rule to accommodate discussion of different contexts such as 
future or past circumstances. In other cases, differences between 
definitions in the regulation text and the Common Agreement may be the 
result of inconsistencies in the level of specification between the 
Common Agreement and definitions in the HTI-2 Proposed Rule. However, 
we agree with the commenter that these differences in the definitions 
between the Common Agreement or SOPs and this rulemaking may lead to 
confusion and misinterpretation or the need for amendments to the 
Common Agreement. Therefore, in this final rule we have addressed 
inconsistencies by revising the final regulatory text wherever feasible 
to directly align with definitions in the Common Agreement and SOPs. 
Below we explain how, in response to public comment, we have further 
aligned definitions in this final rule to the definitions in the Common 
Agreement and SOPs.
    Regarding the comment that leaving out references to SOPs could 
change the meaning of the Common Agreement and render the SOPs 
inapplicable, we reiterate our statement in the HTI-2 Proposed Rule 
that in the case of any true conflict, we intend for the regulatory 
definitions to control (89 FR 63644). We also note that, as stated, our 
definitions in the HTI-2 Proposed Rule included references to SOPs (see 
for example, Sec.  172.102, definitions of ``Governance Services'' and 
``Participant/Subparticipant Terms of Participation''). We have further 
updated definitions in this final rule to incorporate reference to SOPs 
where necessary to align with the Common Agreement as described below.
    Regarding the definition of ``Threat Condition,'' we agree with the 
comment that the definition in this final rule should be identical to 
the definition in the Common Agreement. Given our stated intent for the 
TEFCA-specific definitions in these regulations to align with the 
definitions in the Common Agreement and SOPs (89 FR 63642), and public 
comments that clearly stated a preference for aligning the definitions 
in this final rule to the definitions in the Common Agreement and SOPs, 
we have finalized this definition to align with the definition in the 
Common Agreement. As such, we have modified the proposed definition and 
finalized the definition of ``Threat Condition'' as set out in the 
regulatory text at the end of this document.
    Regarding the definition of ``Recognized Coordinating Entity,'' we 
agree with the commenter that the definition in this final rule should 
be identical to the definition in the Common Agreement. Given our 
intent for the TEFCA-specific definitions in these regulations to align 
with the definitions in the Common Agreement and SOPs (89 FR 63642), 
and public comments that clearly stated a preference for aligning the 
definitions in this final rule to the definitions in the Common 
Agreement and SOPs, we have finalized this definition to align with the 
definition in the Common Agreement. As such, we have modified the 
proposed definition and finalized the definition of ``Recognized 
Coordinating Entity[supreg] (RCE[supreg])'' as set out in the 
regulatory text at the end of this document.
    Regarding the comment that ``XP Code'' is included in the 
regulation, but not used in the regulatory text, we are not clear on 
the specific issue the commenter is raising. We note that ``Exchange 
Purpose Code or XP Code'' was defined in the regulatory text for the 
Proposed Rule (89 FR 63806) as a code that identifies the Exchange 
Purpose being used for TEFCA Exchange. We use only ``Exchange Purpose 
Code'' in the discussion in this final rule, but we recognize 
interested parties may commonly use ``XP Code''. Therefore, as noted in 
the HTI-2 Proposed Rule, we interpret the ``or'' between ``Exchange 
Purpose Code'' and ``XP Code'' in the definition to indicate that the 
two terms are interchangeable. Accordingly, we have decided that use of 
either term is appropriate throughout the regulation (89 FR 63806) and 
have finalized the definition of ``Exchange Purpose Code or XP Code'' 
as proposed.
    Regarding the comment that certain definitions refer to applicable 
SOPs (e.g., the definition for Participant/Subparticipant Terms of 
Participation) while others do not, we note that this inconsistency was 
not intentional. Given our intent for the TEFCA-specific definitions in 
these regulations to align with the definitions in the Common Agreement 
and SOPs (89 FR 63642), and the public comments that clearly stated a 
preference for aligning the definitions in this final rule to the 
definitions in the Common Agreement and SOPs, we have finalized the 
definition of ``Exchange Purpose(s) or XP(s)'' to align with the 
definition in the Common Agreement. As such, we have modified the 
definition of ``Exchange Purpose(s) or XP(s)'' to align with the Common 
Agreement definition, which includes mention of SOP(s).
    Regarding the comment that the term ``Responding Node'' was 
included in the proposed definition of ``Required Information'' but not 
proposed to be defined in Sec.  172.102, we note that this 
inconsistency was not intentional. In order to address commenters' 
reasonable expectation that we would define terms necessary to 
understand other terms we proposed to define where such definitions are 
consistent with those in the Common Agreement per our stated intent of 
alignment (89 FR 63642), we have finalized the definition of 
``Responding Node'' in Sec.  172.102.

[[Page 101788]]

    Regarding the comment that some definitions refer to ``ONC (or an 
RCE)'' (e.g., Threat Condition), and other times there is no mention of 
an RCE even though the Common Agreement includes such a reference 
(e.g., Qualified Health Information Network), we intentionally 
referenced the RCE in certain circumstances and not others in the 
definitions we proposed in Sec.  172.102. Our goal with the proposed 
definitions was to afford ourselves flexibility in the event that one 
day there is no longer an RCE. We emphasize, however, that the current 
RCE, the Sequoia Project, is now in the second year of a five-year 
contract with ASTP/ONC.
    Comments. One commenter identified what they believed to be two 
typos in proposed 45 CFR 172.102. The commenter noted that a few 
definitions, notably the proposed definitions for the HIPAA Privacy 
Rule and the HIPAA Security Rule, reference the regulations at 45 CFR 
part 160 and subparts A and E of 45 CFR part 164, as well as to 45 CFR 
part 160 and subparts A and C of 45 CFR part 164. The commenter asked 
for clarification on what subparts were meant to be referenced.
    Response. The terms HIPAA Privacy Rule and the HIPAA Security Rule 
are both defined in Sec.  172.102 by referencing their codifications in 
the CFR. Both rules have slightly different citations. The citation for 
the HIPAA Privacy Rule is 45 CFR part 160 and subparts A and E of 45 
CFR part 164. The HIPAA Security Rule is located at 45 CFR part 160 and 
subparts A and C of 45 CFR part 164. Because those are the correct 
citations for the HIPAA Privacy and Security Rules, we have finalized 
the HIPAA Privacy Rule and the HIPAA Security Rule definitions in Sec.  
172.102 as proposed.
    Comments. One commenter recommended a revision to the definition of 
``Framework Agreements'' to include only those documents for which a 
draft was made available to the public and the public has some 
opportunity to provide input on the draft before a final version is 
effective. The commenter requested that we require such a process for 
all Framework Agreements. The commenter noted that the RCE should make 
SOP drafts available for public feedback or any other transparent 
process around their establishment and review. The commenter noted 
further that under the proposed rule, ASTP/ONC can review an RCE 
decision, but that there is no process for a QHIN or a participant to 
appeal or require formal review of an SOP. The commenter cited an SOP 
issued last summer that the commenter believed significantly narrowed 
the scope of required response for treatment purposes, which it said 
cut off access to the networks for hundreds of thousands of patients. 
The commenter believed that the proposed rule would allow this result 
to happen again.
    Response. We appreciate the comments. However, the definition of 
``Framework Agreement(s)'' we proposed tracks the definition in the 
Common Agreement, and we believe that deviating from the definition in 
the Common Agreement for such a foundational concept might be confusing 
or suggest differences between the meaning of Framework Agreements in 
the Common Agreement and the regulation that we do not intend. Nor do 
we agree with the commenters who suggest that we should require more 
process for SOPs than is laid out in the Common Agreement (at section 
5.3 of version 2.0). That process--to which QHINs, Participants, and 
Subparticipants agree by signing the Framework Agreements--balances the 
need for input by the public with the need to respond quickly in a 
fast-developing space. We understand that, as the commenter points out, 
sometimes individual entities will disagree with particular SOPs, but 
that is part of the balance struck in the Common Agreement's 
procedures, and we decline the invitation to impose a higher regulatory 
standard on SOPs than set forth in the Common Agreement. We believe 
that transparency is essential to TEFCA's success because it is in the 
best interest of individuals whose health information is exchanged via 
TEFCA and is central to the efforts of HHS to enhance and protect the 
health and well-being of all Americans. Since we began developing TEFCA 
following the passage of the Cures Act in 2016, ASTP/ONC and the RCE 
have held dozens of webinars, listening sessions, and other feedback 
opportunities with the public and interested communities to promote 
transparency and provide the opportunity for public comment. We will 
continue to offer robust feedback opportunities related to TEFCA in the 
future. In addition, ASTP/ONC's processes for gathering feedback on 
TEFCA documents, processes, and procedures have been transparent and 
consistent--and the feedback we have received has informed the 
development of and changes to the Common Agreement and Terms of 
Participation, both of which are included in the finalized definition 
of ``Framework Agreement(s),'' as well as SOPs, which are not.
    We do not believe that the appeals process we have finalized in 45 
CFR part 172 should be expanded to include appeals of SOPs. Section 5 
of the Common Agreement \12\ discusses TEFCA's change management 
process for updating the Common Agreement and SOPs. This process was 
developed with significant input from prospective QHINs, interested 
communities, Federal partners, and the public. It provides 
opportunities for input from multiple different kinds of entities that 
participate in TEFCA. ASTP/ONC must approve all changes, additions, or 
deletions. In addition, section 15 of the Common Agreement \13\ 
addresses dispute resolution, and section 15.6 addresses the escalation 
of certain disputes to ASTP/ONC.\14\ We note these sections to 
highlight that the governance in place for TEFCA ensures that changes 
to TEFCA's policies and procedures are informed by feedback and driven 
by a strong, consistent process with ASTP/ONC oversight embedded 
throughout the processes.
---------------------------------------------------------------------------

    \12\ Common Agreement for Nationwide Health Information 
Interoperability (healthit.gov).
    \13\ Id.
    \14\ Id.
---------------------------------------------------------------------------

    Besides the revisions to the Definitions section discussed above, 
subpart A was finalized as proposed with a few modifications. 
Specifically, the name ``ONC'' used in the title of proposed Sec.  
171.103, as well as the proposed text of Sec.  171.103(a), has been 
finalized as ``ASTP/ONC'' to reflect the recent change to our office's 
name and ensure consistency in the use of ASTP/ONC throughout this 
final rule. In addition, we have added language requiring an RCE to 
seek and receive ASTP/ONC's prior authorization before making certain 
decisions (e.g., interim or final designation decisions (Sec.  
172.303(b)), setting onboarding requirements and determining a QHIN has 
complied with those requirements (Sec.  172.304(b) and (c)), and 
deeming a QHIN application withdrawn for failure to respond to 
information requests during the designation process (Sec.  172.305(c)). 
We have added language to Sec.  172.103(b) to clarify that ASTP/ONC 
cannot subdelegate the authority to grant prior authorization to an 
RCE. These revisions, taken together, help to ensure that an RCE 
remains subordinate to ASTP/ONC and provides only fact-gathering, 
ministerial, and administrative support to ASTP/ONC.

B. Subpart B--Qualifications for Designation

    In the HTI-2 Proposed Rule (89 FR 63644), we discussed that in 
subpart B,

[[Page 101789]]

we proposed qualifications for Designation. In Sec.  172.200, we 
proposed to tie QHIN status to meeting the requirements specified in 
Sec.  172.201. We proposed that an Applicant QHIN (as we proposed to 
define it in Sec.  172.102) would need to meet all requirements in 
Sec.  172.201 to be Designated, and a QHIN would need to continue to 
meet all requirements in Sec.  172.201 to maintain its Designation. We 
noted that the requirements we proposed in Sec.  172.201 would be 
ongoing; a QHIN that does not meet those requirements at all times 
would be subject to suspension or termination, consistent with the 
regulations we proposed in subparts D and E of part 172. In the HTI-2 
Proposed Rule, we stated that the continuing obligation to meet the 
requirements in Sec.  172.201 would help to ensure the reliability of 
TEFCA Exchange and that QHINs could not maintain their status based on 
technology and standards that have become obsolete. Because the 
obligations would be ongoing, throughout this section we referred to 
Applicant QHINs as well as Designated QHINs as ``QHINs'' unless there 
was a need to differentiate.
    As we explained in the HTI-2 Proposed Rule (89 FR 63645), the 
Designation qualifications proposed in Sec.  172.201 described certain 
requirements for Designation. For an entity to become a QHIN, that 
entity must sign the Common Agreement, thus memorializing its agreement 
to the comprehensive Designation requirements--as well as other 
requirements--for trusted exchange under TEFCA. The comprehensive 
Designation requirements in the Common Agreement correspond to the 
proposed requirements included in this subpart.
    In Sec.  172.201, we proposed Designation requirements in three 
categories: (a) ownership; (b) exchange requirements; and (c) 
Designated Network Services.
    In Sec.  172.201(a), we proposed the ownership requirements. In 
Sec.  172.201(a)(1), we proposed that a QHIN must be a U.S. Entity, as 
we proposed to define ``U.S. Entity/Entities'' in Sec.  172.102. Under 
that proposed definition, a U.S. Entity must be a corporation, limited 
liability company, partnership, or other legal entity organized under 
the laws of a state or commonwealth of the United States or the Federal 
law of the United States, be subject to the jurisdiction of the United 
States and the state or commonwealth under which it was formed, and 
have its principal place of business be in the United States under 
Federal law. Additionally, we proposed that none of the entity's 
directors, officers, or executives, and none of the owners with a five 
percent (5%) or greater interest in the entity, may be listed on the 
Specially Designated Nationals and Blocked Persons List published by 
the United States Department of the Treasury's Office of Foreign Asset 
Control or on the Department of Health and Human Services, Office of 
Inspector General's List of Excluded Individuals/Entities. We explained 
that this requirement would help to promote organizational and 
operational policies that enable the exchange of health information 
among networks by ensuring that those who actually control the health 
information exchanged under these provisions are subject to U.S. laws, 
and it would help to avoid giving access to that information to actors 
whom the government has previously identified as national security or 
fraud risks.
    We requested comment on whether the above approach, including the 
specific five percent (5%) threshold, will effectively limit access of 
bad actors trying to join TEFCA as a QHIN, or whether commenters 
believe the threshold should be a different percentage.
    In Sec.  172.201(a)(2), we proposed that an Applicant QHIN must not 
be under Foreign Control, which is a term we proposed to define in 
Sec.  172.102. If, in the course of reviewing a QHIN application, ONC 
believes or has reason to believe the Applicant QHIN may be under 
Foreign Control, ONC would refer the case to the HHS Office of National 
Security (ONS) for review. If information available to ONS supports a 
determination of Foreign Control, ONS will notify ONC. An application 
will be denied if ONS notifies ONC that the Applicant is under Foreign 
Control.
    Given the scale of the responsibilities that a Designated QHIN 
would have with respect to supporting health information exchange and 
the importance that healthcare data has to the critical infrastructure 
of our nation's health care system, we noted in the HTI-2 Proposed Rule 
that we believe that a QHIN should not be under Foreign Control. We 
stated we believe the requirements proposed in Sec.  172.201(a)(1) and 
(2), in conjunction with the proposed definitions that those provisions 
reference, are necessary to ensure that all QHINs are subject to United 
States law and that compliance by QHINs is enforceable under United 
States law. Further, we stated these proposals are designed to 
strengthen the security of the network. We added in the HTI-2 Proposed 
Rule that we believe that the above proposals would promote 
organizational and operational policies that enable the exchange of 
health information among networks by minimizing the risk to TEFCA that 
may be posed by foreign state actors who wish to harm the United 
States, lessening the risks of subjecting QHINs to potentially 
conflicting foreign laws, and encouraging trust in the security of 
exchange under the system.
    In the HTI-2 Proposed Rule (89 FR 63645), we noted that within the 
proposed definition of ``U.S. Entity/Entities'' in Sec.  172.102, we 
proposed that for an entity seeking to become a QHIN to meet the 
definition, none of the entity's directors, officers, or executives, 
and none of the owners with a five percent (5%) or greater interest in 
the entity, can be listed on the Specially Designated Nationals and 
Blocked Persons List published by the United States Department of the 
Treasury's Office of Foreign Asset Control or on the Department of 
Health and Human Services, Office of Inspector General's List of 
Excluded Individuals/Entities. We also noted that we believe the five 
percent (5%) threshold strikes the right balance between protecting the 
security of the network from high-risk or known bad actors and 
achieving practical administrability of TEFCA. We noted individuals 
with less than five percent (5%) ownership in an entity would likely 
have limited means of influencing the actions of an entity connected to 
TEFCA. In the HTI-2 Proposed Rule, we stated we believe that entities--
particularly those with a large number of shareholders--would face 
undue hardship without this sort of exception for small shareholders. 
In the HTI-2 Proposed Rule, we noted this regulation only would provide 
the standard that ONC would apply when evaluating QHINs; it would not 
supersede any stricter requirements imposed by other applicable laws, 
including, for example national security laws. It remains the 
responsibility of QHINs (and any other entity) to comply with all 
applicable laws.
    In Sec.  172.201(b), we proposed exchange requirements for QHINs. 
In the HTI-2 Proposed Rule, we stated we believe these exchange 
requirements are necessary to build a data sharing infrastructure that 
is private and secure and that meets all the requirements of PHSA 
section 3001(c)(9). We believe each of the exchange requirements below 
is important to the implementation and operationalization of TEFCA 
Exchange, as described in Sec.  172.201, at scale. We proposed that an 
entity seeking to become a QHIN must, beginning at the time of 
application,

[[Page 101790]]

either directly or through the experience of its parent entity, meet 
certain exchange requirements, including: (1) be capable of exchanging 
information among more than two unaffiliated organizations; (2) be 
capable of exchanging all Required Information (as that term is defined 
in Sec.  172.102); (3) be exchanging information for at least one of 
the Exchange Purposes (as that term is defined in Sec.  172.102) 
authorized in the Common Agreement or an SOP(s); (4) be capable of 
receiving and responding to transactions from other QHINs for all 
Exchange Purposes; and (5) be capable of initiating transactions for 
the Exchange Purposes that such entity will permit its Participants and 
Subparticipants to use through TEFCA Exchange.
    In the HTI-2 Proposed Rule we stated that, collectively, we believe 
these requirements are tailored to help ensure that a QHIN is capable 
of TEFCA Exchange, supports a trusted exchange framework, and maintains 
consistent practices of exchanging information at scale to support 
nationwide interoperability. The first requirement, proposed in Sec.  
172.201(b)(1), that the entity seeking to become a QHIN be capable of 
exchanging information among more than two unaffiliated organizations, 
is a requirement that would ensure a minimum technical ability exists 
and that exchange would be enabled beyond just the QHIN itself.
    We discussed (89 FR 63646) that the second requirement, proposed in 
Sec.  172.201(b)(2), is also a minimum condition, except it is directed 
at the minimum quantity of data a QHIN must be capable of exchanging. 
This proposed requirement would ensure that every QHIN can exchange 
Required Information (as that term is defined in proposed Sec.  
171.102) and provides certainty to Participants and Subparticipants who 
seek to join a QHIN that there is a minimum scope of data that they can 
reliably expect to be able to exchange via TEFCA Exchange Purposes.
    The proposed requirements in Sec.  172.201(b)(3) through (5) are 
intended to establish basic parameters and expectations for QHINs in 
order to qualify for Designation. We proposed, in Sec.  172.201(b)(3), 
that a QHIN or Applicant QHIN must be exchanging information for at 
least one Exchange Purpose. If a QHIN is not exchanging information for 
at least one of the Exchange Purposes authorized under TEFCA (for 
examples, see the ``Exchange Purpose'' definition proposed in Sec.  
172.102) at the time of application, we noted in the HTI-2 Proposed 
Rule that it is not meeting a minimum condition necessary for such 
exchange to occur and cannot be Designated. While exchange for an 
Exchange Purpose under TEFCA requires an Exchange Purpose Code, 
Applicant QHINs can demonstrate that they are meeting the requirement 
to exchange information for at least one of the Exchange Purposes by 
conducting exchange for an Exchange Purpose without use of an Exchange 
Purpose Code.
    We proposed in Sec.  172.201(b)(4) to require a QHIN to be capable 
of receiving and responding to transactions from other QHINs for all 
Exchange Purposes, to ensure that health information can be exchanged 
among health information networks under TEFCA. For this same reason, we 
proposed in Sec.  172.201(b)(5) to require a QHIN to be capable of 
initiating transactions for the Exchange Purposes that such entity will 
permit its Participants and Subparticipants to use through TEFCA 
Exchange. We noted that ensuring that QHINs will respond to Participant 
or Subparticipant requests for information, and that the Participants 
or Subparticipants are able to receive the information from QHINs, 
enables health information exchange among the QHINs, Participants and 
Subparticipants.
    We noted in the HTI-2 Proposed Rule that a QHIN's ability to 
transact for all Exchange Purposes is a threshold requirement for an 
entity that seeks Designation and is essential for ensuring that the 
TEFCA framework facilitates exchange for each Exchange Purpose 
authorized in the Common Agreement or an SOP(s) for implementation. We 
also noted that, without this requirement, there would be no certainty 
that the TEFCA framework would advance exchange beyond the Treatment 
Exchange Purpose, which is the most prevalent purpose for health 
information exchange today and the purpose of use that most health care 
entities seeking Designation would be most familiar with. TEFCA's 
network connectivity--including this requirement that QHINs have the 
ability to exchange for all Exchange Purposes--and scale would help, 
for example, health care providers gain access to more comprehensive 
and complete information about their patients, which can support 
improved care, better outcomes, decreased provider burden, and reduced 
costs.
    Entities performing TEFCA Exchange as described in Sec.  172.201 
would have the option to request information for all Exchange Purposes. 
At the time of publication of this final rule, TEFCA supports exchange 
for the following Exchange Purposes: treatment; payment; health care 
operations; public health; Individual Access Services (IAS), and 
government benefits determination. Over time, additional Exchange 
Purposes may be added. Information regarding whether responses are 
required for a given Exchange Purpose would be included in an SOP.
    In Sec.  172.201(c), we proposed that an Applicant QHIN must meet 
certain Designated Network Services requirements. Based on our 
experience in the health IT ecosystem, we noted that we believe 
adequate network performance is important for the success of TEFCA, as 
those participating in TEFCA Exchange would be most likely to trust the 
TEFCA infrastructure if it is performing at a high level. We also 
expressed that unreliable network performance would dilute confidence 
in the network and discourage participation.
    In Sec.  172.201(c)(1), we proposed that a QHIN must maintain the 
organizational infrastructure and legal authority to operate and govern 
its Designated Network. For instance, under this proposal, QHINs would 
be required to have a representative and participatory group or groups 
that approve the processes for fulfilling the TEFCA governance 
functions and that participate in governance for the Designated 
Network. In Sec.  172.201(c)(2), we proposed that a QHIN must maintain 
adequate written policies and procedures to support meaningful TEFCA 
Exchange as described in Sec.  172.201 and fulfill all responsibilities 
of a QHIN in the part (which an entity agrees to by signing the Common 
Agreement). For instance, under this proposal, QHINs would be required 
to have a detailed written policy that describes the oversight and 
control of the technical framework that enable TEFCA Exchange.
    In Sec.  172.201(c)(3), we proposed that a QHIN must maintain a 
Designated Network (as proposed to be defined in Sec.  172.102) that 
can support a transaction volume that keeps pace with the demands of 
network users. We noted in the HTI-2 Proposed Rule that since TEFCA is 
a nationwide network and will be used daily to support various health 
data needs to inform care delivery, quality assessments, public health, 
and health care operations, QHINs must be capable of transacting high 
volumes of data reliably and at scale. In Sec.  172.201(c)(4), we 
proposed that a QHIN must maintain the capacity to support secure 
technical connectivity and data exchange with other QHINs. One of the 
most fundamental aspects of interoperable network exchange is

[[Page 101791]]

technical connectivity, which makes network-to-network exchange 
possible and, therefore, was important to include in this regulation.
    In Sec.  172.201(c)(5) through (7), we proposed certain 
requirements related to governance for TEFCA to ensure all QHINs are 
aligned and able to manage risk effectively. In Sec.  172.201(c)(5), we 
proposed that a QHIN must maintain an enforceable dispute resolution 
policy governing Participants in the Designated Network that permits 
Participants to reasonably, timely, and fairly adjudicate disputes that 
arise between each other, the QHIN, or other QHINs. This proposed 
requirement would afford flexibility to QHINs to establish their own 
dispute resolution process while ensuring the process is timely and 
fair. We expressed that disputes may arise for a variety of reasons, so 
the QHIN, as the entity overseeing its Participants, is best placed to 
handle such disputes in a way that minimizes disruptions for the rest 
of the network. Ensuring that a QHIN has such a dispute resolution 
policy would, therefore, likely minimize such disruptions.
    Similarly, in Sec.  172.201(c)(6), we proposed that a QHIN maintain 
an enforceable change management policy consistent with its 
responsibilities as a QHIN. A change management policy establishes the 
standard procedures to approve different types of changes to TEFCA 
documents (e.g., standard operating procedures) and policies and will 
help to avoid changes that are disruptive or in conflict across 
entities.
    In Sec.  172.201(c)(7), we proposed that a QHIN must maintain a 
representative and participatory group or groups with the authority to 
approve processes for governing the Designated Network. We explained 
(89 FR 63647) that the participatory network governance built into the 
TEFCA infrastructure is important to ensure that the requisite 
engagement exists between QHINs, Participants, and Subparticipants 
engaged in TEFCA Exchange. In the HTI-2 Proposed Rule, we stated that 
we believe the above requirements are fundamental aspects of a network-
of-networks focused on participatory governance and the ability to 
adapt to an ever-changing health information exchange landscape.
    In the HTI-2 Proposed Rule, regarding the proposed requirement in 
Sec.  172.201(c)(7) specifically, we emphasized that TEFCA uses a 
representative and participatory governance structure. Representative 
and participatory governance gives those participating in the network a 
role in informing the policies and decisions that ultimately would 
affect them. We explained that such a governance structure helps to 
motivate health care entities and their networks to voluntarily join 
TEFCA. We also noted that we believe that requiring a QHIN to have a 
representative and participatory group or groups that has the ability 
to review and provide input on the governance requirements of the 
QHIN's Designated Network is an optimal approach for this requirement.
    In Sec.  172.201(c)(8), we proposed that an entity seeking to 
become a QHIN must maintain privacy and security policies that permit 
the QHIN to support TEFCA Exchange. We identified certain policies that 
fell within this requirement (89 FR 63647), which we have slightly 
modified here for clarity and technical accuracy, and which included 
the following:
     Maintaining certification under a nationally recognized 
security framework by a qualified, independent third party that ensures 
its assessments are consistent with the NIST Cybersecurity Framework 
(CSF) (using both NIST 800-171 (Rev. 2) and NIST 800-53 (Rev. 5) as a 
reference), ensuring the QHIN performs HIPAA Security Rule risk 
analyses (as required by Sec.  164.308(a)(1)(ii)(A)) and verifies all 
requirements for technical audits and assessments are met.
     Having a qualified, independent third party complete an 
annual security assessment consistent with the NIST Cybersecurity 
Framework (CSF) (using both NIST 800-171 (Rev. 2) and NIST 800-53 (Rev. 
5) as a reference). The third party would review the QHIN for 
consistency with HIPAA Security Rule risk analysis requirements at 
Sec.  164.308(a)(1)(ii)(A). Additionally, the annual security 
assessment must include comprehensive internet-facing penetration 
testing, must include an internal network vulnerability assessment, and 
must use methodologies and security controls consistent with Recognized 
Security Practices, as defined by Public Law 116-321 (42 U.S.C. 17931 
and 300jj-52).
     Employing a Chief Information Security Officer with 
executive-level responsibility.
     Disclosing any breaches of electronic protected health 
information (including disclosure of any such breaches within the three 
(3) years preceding applying to become a QHIN) to the RCE and to all 
QHINs that are likely impacted.
     Complying with 45 CFR part 164, subparts A, C, and E, as 
applicable, as if the QHIN were a covered entity as described in that 
regulation.
     Maintaining and complying with a written privacy policy.
    We noted in the HTI-2 Proposed Rule that these policies and 
requirements would provide privacy and security protections for the 
health information that will be exchanged through TEFCA. All entities 
that elect to participate in TEFCA, including entities that are not 
regulated under HIPAA, would be expected to meet a high bar for privacy 
and security given the nature of the data being exchanged. We stated 
that it is unlikely that an entity would wish to participate in a 
network without privacy and security standards, thereby inhibiting 
TEFCA exchange.
    To further support the security of TEFCA, we proposed in Sec.  
172.201(c)(9) that a QHIN must maintain data breach response and 
management policies that support secure TEFCA Exchange. For instance, 
given the number of electronic connections TEFCA will support, a data 
breach response and management policy would support a transparent 
process and timely awareness of a data breach or other security events 
(e.g., ransomware attacks) which could enable the QHIN to manage secure 
connectivity services without disrupting patient care.
    In Sec.  172.201(c)(10), we proposed that a QHIN must maintain 
adequate financial and personnel resources to support all its 
responsibilities as a QHIN, including, at a minimum, sufficient 
financial reserves or insurance-based cybersecurity coverage, or a 
combination of both. We noted in the HTI-2 Proposed Rule that this 
requirement would help to provide stability to TEFCA in the event of 
unexpected financial or economic occurrences--whether system-wide or 
specific to individual QHINs. For instance, we stated that this 
requirement could be met if the QHIN has available a minimum amount of 
cash, cash equivalents, borrowing arrangements (e.g., a line of 
credit), or a mix of the three that is equal to six (6) calendar months 
of operating reserves. Regarding insurance requirements, a QHIN's 
general liability coverage and the cyber risk/technology coverage 
should each have limits of at least $2,000,000 per incident and 
$5,000,000 in the aggregate, which limits can be met through primary 
coverage, excess coverage, available internal funds, or a combination 
thereof. We noted that the requirements proposed herein may be 
insufficient for larger QHINs and recognized that certain QHINs will 
meet and exceed these minimums.
    QHINs will be the central connection points for TEFCA Exchange, 
responsible for routing queries, responses, and messages among many 
participating entities and individuals. We proposed,

[[Page 101792]]

in Sec.  172.201(c)(10), that QHINs must have sufficient financial 
resources and personnel capacity to perform such functions 
successfully. We also noted we believe that QHINs must be prepared to 
address incidents should they arise and must have the ability to 
fulfill potential liability obligations, either through insurance, 
sufficient financial reserves, or some combination of the two.
    We stated that one goal of TEFCA is to support patients gathering 
their healthcare information. In Sec.  172.202, ``QHINS that offer 
individual access services,'' we proposed IAS requirements for a QHIN 
to obtain and maintain Designation under TEFCA if that QHIN voluntarily 
offers IAS. In Sec.  172.202(a), we proposed that a QHIN would be 
required to obtain express consent from any individual before providing 
IAS, as defined in Sec.  172.102. We noted that we believe this is an 
important requirement so that individuals who use IAS that a QHIN 
offers are informed of the privacy and security practices that are 
being employed to protect their data. In Sec.  172.202(b), we proposed 
that a QHIN would be required to make publicly available a privacy and 
security notice that meets minimum TEFCA privacy and security standards 
to support transparent exchange practices. We stated that we believe 
this requirement would provide transparency to all individuals who are 
considering using IAS regarding how their data is protected and secured 
by a QHIN providing IAS.
    In Sec.  172.202(c), we proposed a QHIN that is the IAS provider 
for an individual would be required to delete the individual's 
Individually Identifiable Information (as defined in Sec.  172.102) 
maintained by the QHIN upon request by the individual except as 
prohibited by Applicable Law or where such information is contained in 
audit logs. We noted (89 FR 63648) that we believe this requirement 
would provide individuals with reassurance that they control access to 
their data. We also expressed that we believe the carve out for audit 
logs is appropriate because audit logs are generally used to provide 
chronological records of system activities and should not be deleted. 
In Sec.  172.202(d), we proposed that a QHIN would be required to 
permit any individual to export in a computable format all of the 
individual's Individually Identifiable Information maintained by the 
QHIN as an IAS provider. We stated that we believe this requirement 
would ensure that individuals may access, control, and use their own 
data held by an IAS provider.
    In Sec.  172.202(e), we proposed that all Individually Identifiable 
Information the QHIN maintains must satisfy certain criteria, 
including: (1) all Individually Identifiable Information must be 
encrypted; (2) without unreasonable delay and in no case later than 
sixty (60) calendar days following discovery of the unauthorized 
acquisition, access, Disclosure, or Use of Individually Identifiable 
Information, the QHIN must notify, in plain language, each individual 
whose Individually Identifiable Information has been or is reasonably 
believed to have been affected by unauthorized acquisition, access, 
Disclosure, or Use involving the QHIN; and (3) a QHIN must have an 
agreement with a qualified, independent third-party credential service 
provider and must verify, through the credential service provider, the 
identities of individuals seeking IAS prior to the individuals' first 
use of such services and upon expiration of their credentials. We noted 
that to the extent the QHIN is already required by Applicable Law to 
notify an individual as described in proposed Sec.  172.202(e)(2), we 
did not propose that it be required to duplicate such a notification. 
Lastly, the proposed requirement in Sec.  172.202(e)(3) would set a 
baseline for proving the identity of IAS users that are requesting data 
via TEFCA Exchange.
    Comments. Multiple commenters expressed support for the provisions 
of this subpart that will establish the qualifications for HINs to 
receive and maintain Designation as a QHIN, including as an IAS 
provider. Multiple commenters also expressed support for the proposed 
qualification requirements. Other commenters cautioned that additional 
requirements of QHINs could limit entities from participating in TEFCA 
or deter them from considering becoming a QHIN.
    Response. We appreciate commenters' support for the proposed 
qualifications for QHIN Designation. We also understand commenters' 
caution to ASTP/ONC regarding additional requirements and appreciate 
the need within TEFCA to establish strong guardrails for QHIN 
participation while not unduly burdening Applicant QHINs and QHINs. We 
agree with commenters that additional requirements for QHINs are not, 
at this time, appropriate as we work to balance flexibility, 
participation, and our commitment to strong guardrails for QHIN 
participation. The current requirements were developed based on ASTP/
ONC's and the RCE's collective experience with health information 
exchange and were informed by a wide range of interested communities 
and the public. As TEFCA evolves, we will continue to consider ways to 
strengthen it and ensure that QHINs are held to a high but reasonable 
standard. In this final rule, we have finalized all subpart B proposals 
without revision.
    Comments. One commenter asked whether any changes to the proposed 
QHIN designation process would be retroactively applicable to entities 
currently undergoing that process. Another commenter expressed support 
for the previous ``sub-regulatory'' approach for establishing criteria 
and requirements for QHIN Designation that allowed for flexibility. 
Some commenters also recommended new requirements. Commenters 
recommended aligning qualifications with existing Department of 
Homeland Security standards and/or FedRAMP certification standards for 
cybersecurity. Another commenter recommended background checks, 
validation of National Provider Identifiers (NPIs), and a rigorous 
review of organizational credentials. A separate commenter encouraged 
ASTP/ONC's continued emphasis on and improvement of security and 
privacy requirements. Another commenter recommended that we leverage 
QHIN qualification criteria to require that pharmacists, with an 
established treatment relationship with patients, have access to 
clinical data.
    Response. Regarding the question whether any changes to the 
proposed QHIN Designation process would be retroactively applicable to 
entities currently undergoing that process, we note that we are 
finalizing the QHIN Designation requirements and process within the 
HTI-2 Proposed Rule, and as discussed above, without revision in this 
final rule. The provisions will be effective upon the effective date 
specified for this final rule in the ``effective date'' section. The 
qualification requirements we have finalized in 45 CFR part 172, 
subpart B, align with and have no substantive differences from the 
requirements for and process followed by all Designated QHINs and 
Applicant QHINs.
    We appreciate the comment in support of the previous sub-regulatory 
approach that we have utilized in TEFCA to this point to establish the 
processes within the TEFCA framework.
    We appreciate the suggestions for updating the existing QHIN 
Designation requirements within the TEFCA framework (e.g., aligning 
qualifications with existing Department of Homeland Security standards 
and/or FedRAMP certification standards for cybersecurity, improving 
privacy and security requirements, emphasis on background checks, 
validation of NPIs, and a

[[Page 101793]]

rigorous review of organizational credentials). We emphasize our 
confidence in the strength of the existing requirements. We may 
consider some of these suggested changes for future rulemaking. While 
we cannot adopt the various new QHIN Designation requirements 
recommended by commenters because we did not propose them, we do note 
that we consulted with various Federal agencies and industry partners 
in developing the QHIN Designation requirements around privacy and 
security that align with Federal agency participation requirements.
    We appreciate the recommendation that we leverage QHIN 
qualification criteria to require that pharmacists, with an established 
treatment relationship with patients, have access to clinical data; 
however, we do not understand how the QHIN qualification criteria 
directly relate to the suggested requirement. We encourage the 
commenter to review the Exchange Purpose Vetting Process SOP, which 
provides helpful information for entities that seek to exchange 
information for treatment via TEFCA.
    As noted in our response to comments above, we proposed to adopt in 
regulation certain provisions related to TEFCA in order to provide 
greater process transparency and further implement section 3001(c)(9) 
of the PHSA, as added by the Cures Act. We believe codifying TEFCA 
through regulation facilitates alignment with the broader legislative 
goals around nationwide health information exchange, interoperability, 
privacy, and security.
    Comments. One commenter suggested that the qualification related to 
transaction volume establish specific performance metrics for the speed 
of data transfer. In particular, the commenter argued that 48-hour 
turnarounds for use cases such as prior authorization would be 
untenable.
    Response. We appreciate commenter's suggestion related to 
transaction volume. The RCE and ASTP/ONC plan to develop performance 
metrics and service level agreements for TEFCA as we develop more 
experience and a better understanding about the needs of the TEFCA 
community. We will consider this comment as we develop the performance 
metrics and service level agreements for TEFCA.
    Comments. One commenter suggested that the 5% ownership requirement 
for ``bad'' actors should not be increased and that lowering the 
threshold could be appropriate for good cause. Another commenter 
suggested that ASTP/ONC clarify that the 5% threshold is for an 
individual and that collusion between multiple individuals would have a 
threshold of over 25%. The commenter was supportive of the proposal 
that QHINs would be ineligible if they are found to be under Foreign 
Control.
    Response. We thank the commenters for the suggestion and the 
support of our proposal regarding Foreign Control. We continue to 
believe, based on significant feedback from interested communities, 
cybersecurity and security experts, and the public, that the five 
percent (5%) threshold is appropriate and strikes the right balance 
between protecting the security of the network from high-risk and known 
bad actors and achieving practical administrability of TEFCA. 
Individuals with less than 5% ownership in an entity would likely have 
limited means of influencing the actions of an entity connected to 
TEFCA. We appreciate the reasoning for the proposal of an aggregate 
threshold but have decided not to implement that suggested change 
because it would be extremely difficult and burdensome to determine 
whether a group of actors is ``colluding'' as suggested by commenter, 
as determining whether ``collusion'' is present could require 
information that may not be readily available.
    Comments. One commenter suggested that we publish all 
``Designation'' documentation on our website for public review.
    Response. While ASTP/ONC supports and promotes transparency where 
possible and appropriate, we decline to adopt the commenter's 
recommendation in this instance. Foremost, we did not propose such an 
approach and thus all potentially affected entities have not had an 
opportunity to comment on the matter. In addition, some of the 
information received from Applicant QHINs may include confidential 
information.

C. Subpart C--QHIN\TM\ Onboarding and Designation Processes

    In the HTI-2 Proposed Rule, we stated that (89 FR 63648) TEFCA 
establishes a universal floor for interoperability across the country 
through a network of networks. In 2019, ONC issued a Notice of Funding 
Opportunity and subsequently awarded a cooperative agreement to The 
Sequoia Project to serve as the RCE to support the implementation of 
TEFCA. In August 2023, ONC awarded The Sequoia Project a five-year 
contract to continue serving as the RCE.
    To establish nationwide health information exchange, TEFCA calls 
for the Designation of QHINs--HINs that agree to the common policy, 
functional, and technical requirements for TEFCA Exchange. The QHIN 
Designation Requirements as described in Sec.  172.201 define the 
baseline legal and technical requirements for secure information 
sharing on a nationwide scale--all under commonly agreed-to rules. 
Exchange through TEFCA simplifies connectivity and creates efficiency 
by establishing a standardized approach to exchange policies and 
technical frameworks.
    Under the 2019 to 2023 cooperative agreement \15\ and the current 
RCE contract,\16\ the RCE's role has been to support the implementation 
of TEFCA, including the solicitation and review of applications from 
HINs seeking QHIN status and administration of the Designation and 
monitoring processes. For entities seeking Designation, the application 
provides the RCE with the information needed to determine a prospective 
QHIN's ability to meet its obligations and responsibilities for TEFCA 
Exchange. All work or activities conducted by the Sequoia Project in 
their capacity as the RCE under the RCE contract, including work or 
activities related to Designation, is conducted on behalf of ONC.
---------------------------------------------------------------------------

    \15\ Notice of Funding Opportunity (NOFO)--Trusted Exchange 
Framework and Common Agreement--Recognized Coordination Entity (RCE) 
Cooperative Agreement, https://www.healthit.gov/sites/default/files/facas/TEFCA%20NOFO_FINAL_508.pdf.
    \16\ See USASPENDING.gov, https://www.usaspending.gov/award/CONT_AWD_75P00123C00019_7570_-NONE-_-NONE-.
---------------------------------------------------------------------------

    In subpart C of part 172, we described the proposed QHIN Onboarding 
and Designation processes. Onboarding, as we proposed to define it in 
Sec.  172.102, is the process a prospective QHIN must undergo to become 
a QHIN and become operational in the production environment.\17\ 
Designation, as we proposed to define it in Sec.  172.102, is the 
written determination that an Applicant QHIN has satisfied all 
regulatory requirements and is now a QHIN.\18\
---------------------------------------------------------------------------

    \17\ 87 FR 2822.
    \18\ 87 FR 2818.
---------------------------------------------------------------------------

    In Sec.  172.300, we explained that subpart C of part 172 would 
establish for QHINs the application, review, Onboarding, withdrawal, 
and redetermination processes that ONC will follow for Designation. We 
noted that establishing these processes will ensure that ONC (or an 
RCE) takes a consistent approach to QHIN Onboarding and Designation.
    We stated that the first step in becoming a QHIN under TEFCA is 
submission of an application. In Sec.  172.301, we proposed to 
establish the information Applicant QHINs must submit in order to be 
Designated as a

[[Page 101794]]

QHIN. We proposed that an Applicant QHIN must submit: (1) a completed 
QHIN application; and (2) a signed copy of the Common Agreement. 
Regarding the first proposed requirement, in Sec.  172.301(a), we noted 
that we may update the application over time and the most recent 
version will be available on ONC's and the RCE's website. The 
application will specify what supporting documentation an Applicant 
QHIN must submit. We proposed the second requirement in Sec.  
172.301(b) because the Applicant QHIN would sign the Common Agreement 
upon application, but the RCE would only countersign and create a 
binding agreement with the Applicant QHIN once the Applicant QHIN 
completes Onboarding and is Designated.
    We stated that the next step to becoming a QHIN is application 
review. In Sec.  172.302, we proposed a process, with required 
timelines and allowable extensions, for ONC (or an RCE) to review 
applications. We proposed in Sec.  172.302(a) that, on receipt of an 
application, ONC (or an RCE) will review the application to determine 
if the Applicant QHIN has completed all parts of the application and 
provided the necessary supporting documentation. Further, we proposed 
that, if the QHIN Application is not complete, ONC (or an RCE) will 
notify the applicant in writing of the missing information within 
thirty (30) calendar days of receipt of the application. Last, we 
proposed (89 FR 63649) that ONC (or an RCE) may extend this period by 
providing written notice to the Applicant QHIN. We noted that ``written 
notice'' throughout part 172 would include notice provided by email to 
the points of contact the Applicant QHIN listed in their application.
    In the HTI-2 Proposed Rule we stated that we believe the above 
timeframe and allowable extensions would allow ONC (or an RCE) enough 
time to perform a thorough review of each application and ensure that 
ONC (or an RCE) is provided with the responses and supporting 
documentation needed to assess the merits of an application. We also 
noted that we believe the 30-day review timeframe--along with the 
ability of ONC (or an RCE) to extend this period by providing written 
notice to the Applicant QHIN--strikes the right balance between moving 
an application forward as quickly as possible while still providing ONC 
(or an RCE) with enough time to conduct a review of the application to 
ensure it is complete and contains all the required material.
    We proposed in Sec.  172.302(b) that once the QHIN application is 
complete, ONC (or an RCE) will review the application to determine 
whether the Applicant QHIN satisfies the requirements for Designation 
set forth in Sec.  172.201, and, if the Applicant QHIN proposes to 
provide IAS, the requirements set forth in Sec.  172.202. We proposed 
this step to make clear that ONC (or an RCE) will review an application 
not only for completeness but also to determine if the qualifications 
are met. We also proposed ONC (or an RCE) would complete its review 
within sixty (60) calendar days of providing the Applicant QHIN with 
written notice that its application is complete. We further proposed 
that ONC (or an RCE) may extend this period by providing written notice 
to the Applicant QHIN. We noted in the HTI-2 Proposed Rule that we 
believe that sixty (60) calendar days will generally be an adequate 
amount of time to conduct a thorough, comprehensive review of the 
substance of the application. However, we also noted that we are 
cognizant that there may be complex applications that require 
additional time for review and, therefore, proposed that ONC (or an 
RCE) may extend this period by providing written notice to the 
Applicant QHIN.
    We proposed in Sec.  172.302(c) that ONC (or an RCE) may contact 
the Applicant while the application is being reviewed to request 
additional information. ONC (or an RCE) will provide the timeframe for 
responding to its request and the manner to submit additional 
information, which may be extended on written notice to the Applicant 
QHIN. We noted we believe this provision would be beneficial because 
the Applicant QHIN will need to provide detailed responses that may be 
complex and will vary among Applicant QHINs. We also stated we 
anticipate there will often need to be a discussion between ONC (or an 
RCE) and the Applicant QHIN to reach a resolution and shared 
understanding. This provision would provide for this vital 
communication between ONC (or an RCE) and the Applicant QHINs. We 
proposed that an Applicant QHIN must respond to ONC (or an RCE) within 
the timeframe ONC (or an RCE) identifies because ONC (or an RCE) will 
be in the best position to understand the complexity of the question 
and estimate a reasonable amount of time for the Applicant QHIN to 
respond. That said, we noted that we understand that each application, 
as well as the questions associated with each application, will vary 
significantly on a case-by-case basis and, therefore, proposed that ONC 
(or an RCE) may extend the timeframe by providing written notice to the 
Applicant QHIN. We stated that we believe this approach creates 
appropriate flexibility regarding timing of Applicant QHIN responses, 
while still leaving the discretion to decide the need for and length of 
such extensions.
    We proposed in Sec.  172.302(d) that failure to respond to a 
request within the proposed timeframe, or in the manner specified, is a 
basis for a QHIN Application to be deemed withdrawn, as set forth in 
Sec.  172.305(c). In such situations, we proposed that ONC (or an RCE) 
would provide the Applicant QHIN with written notice that the 
application has been deemed withdrawn. We stated that we believe this 
requirement is important to support an efficient application process 
and to ensure that Applicant QHINs respond to requests in a timely 
manner. We reiterated that under proposed Sec.  172.302(c), as 
discussed above, ONC (or an RCE) can extend the timeframe for 
responding to a request for information. We noted that an Applicant 
QHIN should request an extension if it does not believe it can meet the 
proposed response timeframe.
    We proposed in Sec.  172.302(e) that if, following submission of 
the application, any information submitted by the Applicant QHIN 
becomes untrue or materially changes, the Applicant QHIN must notify 
ONC (or an RCE), in the manner specified by ONC (or an RCE), of such 
changes in writing within five (5) business days of the submitted 
material becoming untrue or materially changing. This proposed 
requirement takes into consideration the possibility that, over the 
course of ONC's (or an RCE's) review of an application, an Applicant 
QHIN's circumstances or information provided with the Applicant QHIN's 
application may change. This provision would ensure that if such 
changes occur, the Applicant QHIN would promptly notify ONC (or an RCE) 
of such changes. We stated that we believe, based on ONC's experience 
with health IT implementation and coordination efforts, that five (5) 
business days is enough time for the Applicant QHIN to notify ONC (or 
an RCE) of the change(s).
    In Sec.  172.303, we proposed requirements related to QHIN approval 
and Onboarding. We proposed in Sec.  172.303(a) that an Applicant QHIN 
would have the burden of demonstrating its compliance with all 
qualifications for Designation in Sec.  172.201, and, if the Applicant 
QHIN proposes to provide IAS, the qualifications in Sec.  172.202. We 
proposed in Sec.  172.303(b) that if ONC (or an RCE) determines an 
Applicant QHIN meets the requirements for Designation

[[Page 101795]]

set forth in Sec.  172.201, and, if the Applicant QHIN proposes to 
provide IAS, the qualifications set forth in Sec.  172.202, then ONC 
(or an RCE) will notify the Applicant QHIN in writing that it has 
approved its application, and the Applicant QHIN can proceed with 
Onboarding. These proposed requirements are important for ensuring that 
the Applicant QHIN is notified of its status and support the 
transparency and efficiency of the Onboarding process.
    We proposed in Sec.  172.303(c) that an approved Applicant QHIN 
would be required to submit a signed version of the Common Agreement 
within a timeframe set by ONC (or an RCE). This proposed provision is 
important in addition to Sec.  172.301(b) (which would require an 
Applicant QHIN to submit a signed version of the Common Agreement when 
applying) to ensure that, if the Common Agreement changes between the 
time the QHIN applies and when it is approved, the QHIN will have 
signed the most recent version. We did not propose a specific timeframe 
for submission, and instead proposed to allow ONC (or an RCE) to set 
the timeframe for each Applicant QHIN, since we believe each timeframe 
should be tailored to the needs of the Applicant QHIN and the 
complexity of each application.
    We proposed in Sec.  172.303(d) that an approved Applicant QHIN 
must complete the Onboarding process set forth by ONC (or an RCE), 
including any tests required by ONC (or an RCE) to ensure the Applicant 
QHIN's network can connect to those of other QHINs, within twelve (12) 
months of approval of the QHIN application, unless that time is 
extended in ONC's (or an RCE's) sole discretion by up to twelve (12) 
months. Based on our experience with health IT implementation and 
discussions with the current RCE, we stated that we believe the 
proposed twelve (12) month timeframe is sufficient time for approved 
Applicant QHINs to complete the Onboarding process including any tests 
with QHINs and other Applicant QHINs. We expressed that we believe this 
timeframe strikes an appropriate balance between the need to onboard 
QHINs promptly and the need to ensure that all QHINs can connect 
immediately and seamlessly once Designated. We noted that during the 
Onboarding process, the Applicant QHIN would have regular check-ins 
with ONC (or an RCE) to monitor the progress on any outstanding 
requirements, to coordinate technical testing, and to address any 
issues that could put the Applicant QHIN in jeopardy of failing to meet 
the proposed Onboarding timeframe detailed above.
    In Sec.  172.304, we proposed the specific procedural requirements 
for the Designation of QHINs. In Sec.  172.304(a), we proposed the 
process that would follow an Applicant QHIN's satisfaction of the 
Onboarding process requirements. We proposed that once the Onboarding 
process requirements are satisfied, the Common Agreement would be 
countersigned and the Applicant QHIN would receive a written 
determination indicating that it had been Designated as a QHIN, along 
with a copy of the countersigned Common Agreement.
    In Sec.  172.304(b), we proposed that within thirty (30) calendar 
days of receiving its written determination of Designation, each QHIN 
would be required to demonstrate in a manner specified by ONC (or an 
RCE) that it has completed a successful transaction with all other in-
production QHINs according to standards and procedures for TEFCA 
Exchange. This proposed provision is important because it would ensure 
that a Designated QHIN is able to exchange information with other 
QHINs, which is a core function of QHINs. We stated we believe that the 
thirty (30)-day timeframe will afford a Designated QHIN ample time to 
move from testing to production. We also stated we believe that the 
standards and procedures for such exchanges should remain flexible such 
that ONC (or an RCE) may update the requirements from time to time as 
appropriate. QHINs which are unable to complete a successful 
transaction within the finalized time period would have their 
Designation revoked.
    We proposed in Sec.  172.304(c) that if a QHIN is unable to 
complete the requirement in Sec.  172.304(b), described above, within 
the thirty (30)-day period provided, the QHIN would be required to 
provide to ONC (or an RCE) a written explanation as to why the QHIN is 
unable to complete the requirement within the allotted time and include 
a detailed plan and timeline for completion of the requirement. We 
proposed that ONC (or an RCE) will then review and approve or reject 
the QHIN's plan, basing its decision on the reasonableness of the 
explanation based on the specific facts and circumstances, within five 
(5) business days of receipt. We proposed that if the QHIN fails to 
provide ONC (or an RCE) its plan or ONC (or an RCE) rejects the QHIN's 
plan, ONC (or an RCE) will rescind its approval of the application, 
rescind the QHIN Designation, and deny the application. We stated that 
we believe these proposals would provide QHINs with the appropriate 
flexibility to request an extension if the circumstances do not allow 
the QHIN to meet the timeline. We also expressed that we believe the 
proposed five (5)-business day timeframe would provide ONC (or an RCE) 
with enough time to review the request and reach a decision regarding 
the request based on the information provided. We proposed that within 
thirty (30) calendar days of the end of the term of the plan, each QHIN 
must demonstrate in a manner specified by ONC (or an RCE) that it has 
completed a successful transaction with all other in-production QHINs 
according to standards and procedures for TEFCA Exchange. We noted that 
we believe that the thirty (30)-day timeframe will afford a Designated 
QHIN ample time to move from testing to production.
    In Sec.  172.304(d), we proposed that a QHIN Designation will 
become final sixty (60) days after a Designated QHIN has submitted its 
documentation, in a manner specified by ONC (or an RCE), that it has 
completed a successful transaction with all other in-production QHINs. 
This proposal will allow ONC (or an RCE) to exercise its ability to 
review a Designation.
    In Sec.  172.305, we proposed requirements related to withdrawal of 
an application. In Sec.  172.305(a), we proposed that an Applicant QHIN 
may withdraw its application by providing ONC (or an RCE) with written 
notice in a manner specified by ONC (or an RCE). In Sec.  172.305(b), 
we proposed that an Applicant QHIN may withdraw its application at any 
point prior to Designation. In Sec.  172.305(c), we proposed that on 
written notice to the Applicant QHIN, an application may be deemed as 
withdrawn as a result of the Applicant QHIN's failure to respond to 
requests for information from ONC (or an RCE). We stated that we 
believe the approach in proposed Sec.  172.305 would create an 
efficient process for ONC (or an RCE) to deem applications withdrawn if 
an Applicant QHIN fails to respond to requests for information, and 
also supports a flexible process by allowing an Applicant QHIN, for 
whatever reason, to decide to withdraw its application without penalty. 
Given the requirements placed on Applicant QHINs seeking to be 
Designated, we stated we think it is reasonable to believe that some 
Applicant QHINs will need to withdraw their applications to address any 
number of issues that could arise during the application process.
    In Sec.  172.306, we proposed that if an Applicant QHIN's 
application is denied, the Applicant QHIN will be provided with written 
notice that includes the basis for the denial. We did not propose a 
specific template that would be used to explain the basis of a denial, 
as such

[[Page 101796]]

explanation would likely vary based on the specific facts and 
circumstances.
    In Sec.  172.307, we proposed requirements for re-application. In 
Sec.  172.307(a), we proposed that Applicant QHINs may resubmit their 
applications by complying with the provisions of Sec.  172.301 in the 
event that an application was denied or withdrawn. We noted that re-
application pursuant to Sec.  172.307(a) would also be conditioned on 
meeting the requirements of proposed paragraphs (b) through (d) of 
Sec.  172.307, as applicable. We proposed in Sec.  172.307(b) that an 
Applicant QHIN may reapply at any time after it has voluntarily 
withdrawn its application as specified in Sec.  172.305(a). We wanted 
to create flexibility for Applicant QHINs to reassess their 
applications and, if desired, resubmit the application. We also stated 
we believe that providing an Applicant QHIN that withdraws its 
application with discretion to choose when to re-apply would result in 
better applications and create administrative efficiency. This is 
because Applicant QHINs would be motivated to self-identify issues and 
correct them in a subsequent application. Also, Applicant QHINs that 
withdraw applications early would allow ONC (or an RCE) to avoid 
expending resources to review and identify such issues.
    In Sec.  172.307(c), we proposed that if ONC (or an RCE) deems an 
application to be withdrawn as a result of the Applicant QHIN's failure 
to respond to requests for information from ONC (or an RCE), then the 
Applicant QHIN may reapply by submitting a new application no sooner 
than six (6) months after the date on which its previous application 
was submitted. We proposed that the Applicant QHIN must respond to the 
prior request for information and must include an explanation as to why 
no response was previously provided within the required timeframe. We 
proposed in Sec.  172.307(d) that if ONC (or an RCE) denies an 
application, the Applicant QHIN may reapply by submitting a new 
application consistent with the requirements in Sec.  172.301, no 
sooner than six (6) months after the date shown on the written notice 
of denial. The application must specifically address the deficiencies 
that constituted the basis for denying the Applicant QHIN's previous 
application.
    We noted in the HTI-2 Proposed Rule that we believe the proposed 
six (6)-month minimum time period before re-application, in Sec.  
172.307(c) and (d), would support efficiency in the review process, as 
ONC (or an RCE) could shift its attention to other Applicant QHINs or 
issues while the Applicant QHIN whose application was withdrawn as a 
result of the Applicant QHIN's failure to respond to requests for 
information or was denied reconsiders its application and addresses the 
previously identified deficiency or deficiencies. Because the Applicant 
QHIN that withdraws its application has not had its application denied 
or deemed withdrawn for failure to respond to ONC (or an RCE) requests 
for information, the Applicant QHIN may be prepared to reapply much 
sooner than is the case for Applicant QHINs that have had their 
application denied or deemed withdrawn. We welcomed comments on the 
proposed processes and requirements in this subpart. Specifically, we 
requested comment on whether the six-month timeframe for re-application 
after an application has been deemed to be withdrawn as a result of the 
Applicant QHIN's failure to respond to requests for information or has 
been denied is appropriate, as well as other timeframes we proposed.
    In addition to changes to the proposed regulatory text explained 
below, and as explained elsewhere in this final rule, we have finalized 
references to ``ONC'' in subpart B of the proposed rule as ``ASTP/
ONC.'' In some instances (for example, in Sec.  172.303(d)), we also 
modified proposed regulatory text to ensure that the proper possessive 
is used and finalized text reading ``ASTP/ONC's'' instead of ``ONC's.'' 
For further discussion of the use of ``ASTP/ONC,'' please see the 
Executive Summary of this final rule.
    Comments. One commenter stated that it was a seamless process to 
connect to the TEFCA network through the QHIN, but recommended there 
not be a means where users are opted into exchange via a QHIN by 
default.
    Response. While we appreciate the feedback, this comment is beyond 
the scope of the proposed regulations because we did not make any 
proposals related to a QHIN's policies and procedures related to 
opting-in (or not opting-in). Since the comment is out of scope it 
would not be appropriate to respond to such policy concerns here. 
However, we welcome all feedback from interested parties, which can be 
submitted via the ASTP/ONC website at https://inquiry.healthit.gov/support/plugins/servlet/desk/portal/2/create/61, for consideration and 
potential inclusion within the TEFCA framework.
    Comments. Overall, commenters were supportive of our proposal to 
codify requirements related to QHIN Designation, Onboarding and dispute 
resolution at this time. However, a couple of commenters expressed 
concern that the codification could slow down the onboarding process 
and eliminate the adaptability for future QHINs. One commenter stated 
that the proposed regulation could hinder the RCE's and ASTP/ONC's 
ability to make quick, necessary adjustments based on real-world 
implementation feedback from future QHIN applicants. This commenter 
said that codifying the requirements could limit the number of QHINs in 
the network by potentially discouraging or disqualifying future QHINs 
due to a less forgiving application process. The commenter opined that 
this might hinder the emergence of innovative solutions and potentially 
lead to less favorable terms for Participants and Subparticipants.
    Response. We appreciate the feedback and the commenters' concerns. 
By codifying the QHIN Designation, Onboarding, and dispute resolution 
requirements, we establish a baseline for expectations for QHINs. We 
believe this is supported by Congress' instruction that the Common 
Agreement may include ``a common method for authenticating trusted 
health information network participants'' (42 U.S.C. 300jj-
11(c)(9)(B)(i)(I)). For commenters concerned about potential future 
requirements, while we appreciate the feedback, this comment is beyond 
the scope of the proposed regulations. However, we welcome all feedback 
from interested parties, which can be submitted via the ASTP/ONC 
website at https://inquiry.healthit.gov/support/plugins/servlet/desk/portal/2/create/61, for consideration and potential inclusion within 
the TEFCA framework.
    Comments. One commenter requested that the Onboarding process be 
clarified to give more information regarding the redetermination 
process for QHIN application.
    Response. We appreciate the comment but decline to make any changes 
to the Onboarding process. We believe the current Onboarding process, 
as well as the redetermination process, are sufficiently detailed so 
that QHINs will know what to expect while ensuring flexibility remains 
in place to allow for reconsideration based on a variety of 
circumstances.
    Comments. Commenters requested that ASTP/ONC make TEFCA's 
onboarding process become more stringent to keep the system free of bad 
actors. In addition to a stricter onboarding process, the commenters 
also recommended active monitoring and swift enforcement, and the 
creation of a mandatory notification system to alert legitimate 
practices when their NPIs and credentials are used in data exchanges, 
ensuring they are aware of

[[Page 101797]]

all activities tied to their identities. Another commenter emphasized 
that this has become a serious issue under TEFCA, particularly as the 
HITECH Act's requirement to share patient information with a third 
party at the patient's direction at minimal cost encourages some 
entities to misrepresent that they are acting on behalf of the patient.
    Response. We appreciate the comments and concern. We believe that 
Onboarding and Designation provisions we are finalizing, including the 
substantive requirements at Sec. Sec.  172.201 and 172.202, establish a 
rigorous testing and onboarding process that will prevent bad actors 
from misusing the TEFCA framework. Specifically, since we proposed 
substantive requirements for QHIN approval and Onboarding, and QHIN 
designation, in Sec. Sec.  172.303 and 172.304 in the HTI-2 Proposed 
Rule, we have developed a robust vetting process for ensuring that 
Participants and Subparticipants that want to query for treatment 
exchange through TEFCA using the code that requires a response are in 
fact providers that require the information for treatment of a patient. 
In addition, the Treatment XP Implementation SOP \19\ establishes a 
definition for TEFCA required treatment that includes the requirement 
that the TEFCA required treatment XP code can only be asserted by a 
QHIN, Participant, or Subparticipant if the Query is in connection with 
or intended to inform health care services that an entity identified in 
the SOP is providing or intends to provide to a patient through 
synchronous or asynchronous interaction (either in-person or virtual) 
with a Licensed Individual Provider. This definition is narrower than 
the HIPAA Rules' definition of treatment and we believe necessary to 
build trust within the TEFCA community. We will consider expanding the 
scope of disclosures that are required under TEFCA's treatment Exchange 
Purpose over time.
---------------------------------------------------------------------------

    \19\ XP Implementation: Treatment, https://rce.sequoiaproject.org/wp-content/uploads/2024/07/SOP-Treatment-XP-Implementation_508.pdf.
---------------------------------------------------------------------------

    We have decided not to implement a mandatory notification system as 
suggested because we believe the approach we are taking to address the 
possibility of misuse of the TEFCA network, as discussed above, is more 
appropriate, and that a mandatory notification system could be overly 
burdensome, particularly given the extremely large number of 
transactions we anticipate occurring through TEFCA once fully 
implemented.
    Comments. One commenter questioned why Sec.  172.304 references 
provisional designation when the RCE is currently revising the 
Onboarding and Designation SOP to remove references to provisional 
status.
    Response. We agree that the references to ``provisional'' 
designation are confusing and unnecessary. We have revised the 
regulatory language in Sec.  172.304 to remove reference to provisional 
Designation and reiterate that a QHIN is Designated when the Common 
Agreement is countersigned. As we proposed and have finalized, the 
Designation is rescindable if the requirements for exchange are not met 
within the 60-day limit described in Sec.  172.304(d), otherwise, the 
Designation is final.
    Comments. One commenter offered support of the six-month timeframe 
for re-application after an application has been withdrawn or denied. 
The commenter stated that it is important for ASTP/ONC to take the time 
it needs and assure security and appropriateness.
    Response. We appreciate this comment in support of a six-month 
timeframe and have finalized the provision in Sec.  172.307(c) as 
proposed.
    Comment. One commenter emphasized the need for strict enforcement 
of deadlines and application criteria. The commenter also recommended 
that if the requirements were not met, the application should not only 
be withdrawn but also prompt an audit of the applicant's activities and 
a review of any data exchanges that took place during the application 
process. The commenter also suggested expanding the criteria for 
withdrawing an application to include not just failures to respond but 
also the discovery of fraudulent activities or the use of illegitimate 
credentials at any point during the application process.
    Response. We appreciate the feedback. We decline to adopt stricter 
deadlines and application criteria. We believe the current structure 
accounts for these concerns, for instance, by requiring a QHIN to 
specifically address any unresolved issues upon reapplication. 
Regarding the suggestions to require an audit of the applicant's 
activities and a review of any data exchange that took place during the 
application process and expanding the criteria for withdrawing an 
application, we have decided not to implement the changes in this 
rulemaking because we believe such potential changes should be reviewed 
and considered by the public. We may consider the changes in future 
rulemaking.
    We have finalized all of subpart C as proposed, except that we 
removed language referring to provisional Designation in Sec.  172.304 
for the reasons explained above. In addition, we have added language 
requiring an RCE to seek and receive ASTP/ONC's prior authorization 
before making interim or final designation decisions (Sec.  
172.303(b)), setting onboarding requirements and determining a QHIN has 
complied with those requirements (Sec.  172.304(b) and (c)), and 
deeming a QHIN application withdrawn for failure to respond to 
information requests during the Designation process (Sec.  172.305(c)). 
Under Sec.  172.103(b), ASTP/ONC cannot subdelegate to the RCE those 
requirements for prior agency authorization. Combined with the review 
provisions that apply to all RCE actions in subpart F of part 172, this 
language helps to ensure that an RCE remains subordinate to ASTP/ONC 
and provides only fact-gathering, ministerial, and administrative 
support to ASTP/ONC.

D. Subpart D--Suspension

    Within this subpart, in the HTI-2 Proposed Rule, we proposed 
provisions associated with suspension, notice requirements for 
suspension, and the effect of suspension. In Sec.  172.401, we proposed 
provisions related to ONC (or the RCE) suspension of a QHIN or directed 
suspension of a Participant or Subparticipant. In Sec.  172.401(a), we 
proposed that ONC (or an RCE) may suspend a QHIN's authority to engage 
in TEFCA Exchange if the ONC (or an RCE) determines that a QHIN is 
responsible for a Threat Condition. Within the TEFCA infrastructure, 
QHINs are expected to meet a high bar for security, including, but not 
limited to, third-party certification to industry-recognized 
cybersecurity standards; compliance with the HIPAA Security Rule or the 
standards required by QHIN participation that mirror the HIPAA Security 
Rule requirements; annual security assessments; designation of a Chief 
Information Security Officer; and having cyber risk coverage.
    This proposed provision would support the overall security of TEFCA 
and align with the security requirements for QHINs by enabling ONC (or 
an RCE) to suspend a QHIN's authority to engage in TEFCA Exchange if 
the QHIN is responsible for a Threat Condition. According to the 
definition proposed in Sec.  172.102, a Threat Condition may occur in 
three circumstances: (i) a breach of a material provision of a 
Framework Agreement that has not been cured within fifteen (15) 
calendar days of receiving notice of the material breach (or such other 
period of time to which contracting parties have agreed), which

[[Page 101798]]

notice shall include such specific information about the breach that is 
available at the time of the notice; or (ii) a TEFCA Security Incident, 
as that term is defined in Sec.  172.102; or (iii) an event that ONC 
(or an RCE), a QHIN, its Participant, or their Subparticipant has 
reason to believe will disrupt normal TEFCA Exchange, either due to 
actual compromise of, or the need to mitigate demonstrated 
vulnerabilities in, systems or data of the QHIN, Participant, or 
Subparticipant, as applicable; or through replication in the systems, 
networks, applications, or data of another QHIN, Participant, or 
Subparticipant; or (iv) any event that could pose a risk to the 
interests of national security as directed by an agency of the United 
States government. We proposed this policy because we believe that in 
each of these situations, in order to protect the security of TEFCA 
Exchange, ONC (or an RCE) must be able to take immediate action to 
suspend a QHIN's authority to engage in TEFCA exchange and limit the 
potential effects of the Threat Condition.
    In Sec.  172.401(b), we proposed if ONC (or an RCE) determines that 
one of a QHIN's Participants or Subparticipants has done something or 
failed to do something that results in a Threat Condition, ONC (or an 
RCE) may direct the QHIN to suspend that Participant's or 
Subparticipant's authority to engage in TEFCA Exchange. This provision 
proposed to extend the ONC (or an RCE's) authority to suspend a QHIN's 
authority to engage in TEFCA Exchange to also include the authority to 
order a QHIN to suspend a Participant's or Subparticipant's authority 
to engage in TEFCA Exchange. We stated that we believe this provision 
would help protect the security of TEFCA Exchange because any Threat 
Condition--whether due to the action or inaction by a QHIN, 
Participant, or Subparticipant--could jeopardize the security of TEFCA 
and must be addressed once identified. We also noted we believe that in 
order to protect the security of TEFCA Exchange, ONC (or an RCE) must 
be able to take immediate action to order a QHIN to suspend a 
Participant's or Subparticipant's authority to engage in TEFCA Exchange 
and limit the potential effects of a Threat Condition resulting from 
something a Participant or Subparticipant has done or failed to do.
    In Sec.  172.401(c), we proposed that ONC (or an RCE) will make a 
reasonable effort to notify a QHIN in writing, in advance, of ONC's (or 
an RCE's) intent to suspend the QHIN or to direct the QHIN to suspend 
one of the QHIN's Participants or Subparticipants, and give the QHIN an 
opportunity to respond. Such notice would identify the Threat Condition 
giving rise to such suspension. We acknowledged that a suspension would 
significantly disrupt the activities of a QHIN, Participant, or 
Subparticipant and therefore Sec.  172.401(c) proposed to require ONC 
(or an RCE) to make a reasonable effort to notify affected parties in 
advance of the ONC's (or an RCE's) intent to suspend. We proposed to 
only require ONC (or an RCE) to make a reasonable effort to notify the 
entity because the circumstances surrounding a Threat Condition may 
limit ONC's (or an RCE's) ability to provide advance written notice to 
the QHIN or the QHIN's Participants or Subparticipants, despite ONC's 
(or an RCE's) best efforts. In Sec.  172.401(d), we proposed ONC (or an 
RCE) shall lift a suspension once the Threat Condition is resolved. We 
stated we believe that it would no longer be necessary to continue a 
suspension once a Threat Condition is resolved.
    We stated in the HTI-2 Proposed Rule that we believe the provisions 
outlined in Sec.  172.401 would help maintain the integrity of TEFCA 
and offer a transparent approach to suspension that would communicate 
the reason for suspension, require timely notification of suspension, 
and afford QHINs an opportunity to resolve the issue(s)--including in 
concert with their Participants or Subparticipants--that led to the 
suspension and to resume TEFCA Exchange.
    In Sec.  172.402, we proposed provisions related to selective 
suspension of TEFCA Exchange between QHINs. In Sec.  172.402(a), we 
proposed that a QHIN may, in good faith and to the extent permitted by 
Applicable Law, suspend TEFCA Exchange with another QHIN because of 
reasonable concerns related to the privacy and security of information 
that is exchanged. In Sec.  172.402(b), we proposed that if a QHIN 
decides to suspend TEFCA exchange with another QHIN, it is required to 
promptly notify, in writing, ONC (or an RCE) and the QHIN with which it 
is suspending exchange of its determination and the reason(s) for 
making the decision.
    These proposed provisions are intended to further strengthen the 
privacy and security protections within TEFCA by extending suspension 
rights to QHINs to suspend exchange with another QHIN due to reasonable 
concerns related to the privacy and security of information that is 
exchanged. We emphasize that we proposed the concerns must be 
``reasonable'' and must be related to the ``privacy and security of 
information that is exchanged'' in order to ensure that suspension of 
TEFCA Exchange between QHINs is not based on other factors, such as 
competitive advantage. We solicited comments on examples of reasonable 
concerns related to the privacy and security of information that is 
exchanged. These proposed requirements would support trust between 
QHINs, which is a foundational element of TEFCA and would help TEFCA 
establish a universal floor for interoperability across the country. We 
stated that we believe prompt notification of the selective suspension 
to ONC (or an RCE) and the suspended QHIN would enable all parties 
involved to be aware of the situation in a timely fashion and take 
action to maintain the privacy and security of TEFCA Exchange 
activities.
    In Sec.  172.402(c), we proposed that if a QHIN suspends TEFCA 
Exchange with another QHIN under Sec.  172.402(a), it must, within 
thirty (30) calendar days, initiate the TEFCA dispute resolution 
process in order to resolve the issues that led to the decision to 
suspend, or the QHIN may end its suspension and resume TEFCA Exchange 
with the other QHIN within thirty (30) calendar days of suspending 
TEFCA Exchange with the QHIN. We proposed this provision to provide the 
parties with an opportunity to resolve concerns related to privacy and 
security and potentially continue exchange once the issues have been 
resolved. We stated we believe the thirty (30)-day timeframe would 
provide sufficient time to resolve issues that led to the suspension, 
end the suspension, and resume TEFCA Exchange activities in a timely 
manner. Ultimately, TEFCA will be most impactful and successful if 
QHINs trust each other and are able to confidently exchange information 
with each other, so it is in the best interests of the QHINs involved, 
as well as TEFCA overall, to address and resolve a selective suspension 
quickly, and by the least disruptive means possible.
    In Sec.  172.402(d), we proposed that, provided that a QHIN 
suspends TEFCA exchange with another QHIN in accordance with other 
provisions in Sec.  172.402 and in accordance with Applicable Law, such 
selective suspension would not be deemed a violation of the Common 
Agreement. This provision would promote the integrity of TEFCA by 
ensuring that a QHIN with reasonable and legitimate concerns related to 
the privacy and security of information that is exchanged would not be 
deterred from suspending exchange activities with another QHIN for fear 
of being in violation of the Common Agreement.
    As described elsewhere in this final rule, we have finalized 
references to

[[Page 101799]]

``ONC'' in subpart D of the proposed rule as ``ASTP/ONC.'' For further 
discussion of the use of ``ASTP/ONC,'' please see the Executive Summary 
of this final rule.
    Comments. One commenter was supportive of the criteria and process 
we proposed for the suspension. However, the commenter also highlighted 
the need to ensure that when a QHIN is suspended, Participants and 
Subparticipants utilizing that QHIN are protected from actions taken by 
HHS, ASTP/ONC or the OIG including but not limited to information 
blocking requirements.
    Another commenter was concerned about the lack of clarity regarding 
the suspension of a QHIN and requested that ASTP/ONC clarify the 
obligations of hospitals and health systems in such cases to ensure 
compliance with interoperability rules.
    Response. We appreciate the concerns the commenter raised regarding 
protecting Participants and Subparticipants from actions taken by HHS, 
ASTP/ONC or the OIG including but not limited to actions related to 
information blocking requirements. We note that, in the event of 
suspension of a QHIN's ability to participate in exchange activities 
under the Common Agreement, the Common Agreement requires the QHIN to 
communicate with its Participants that all TEFCA Exchange on behalf of 
the QHIN's Participants will also be suspended during any period of the 
QHIN's suspension (see section 17.4.4 of Common Agreement Version 2.1). 
The Common Agreement also requires the QHIN to require its Participants 
to communicate with their Subparticipants that all TEFCA Exchange on 
behalf of the QHIN's Subparticipants will be suspended during any 
period of the QHIN's suspension (see section 17.4.4 of Common Agreement 
Version 2.1). We believe these provisions provide appropriate 
transparency to entities affected by a suspension.
    With regard to the comments related to protection from actions 
taken by HHS, ASTP/ONC or the OIG including but not limited to actions 
related to information blocking requirements, we note that Participants 
and Subparticipants remain subject to all applicable laws (e.g., HIPAA 
Privacy, Security, and Breach Notification Rules, and information 
blocking regulations). We encourage Participants and Subparticipants to 
review the information blocking regulations, including the exceptions, 
to determine their applicability to an actor's facts and circumstances. 
We also refer readers to section 17.4.4 of the Common Agreement (which 
discusses the effect of suspension).
    We also encourage organizations that connect to a QHIN to discuss 
transition plans in the event of a suspension with the QHIN and review 
any appropriate material or requirements.
    Comments. One commenter requested additional information from ASTP/
ONC on the consequence for repeated Threat Conditions coming from any 
one QHIN after a Threat Condition has been cured.
    Response. We thank the commenter for the suggestion. We did not 
make any proposals related to consequences for repeated Threat 
Conditions coming from any one QHIN after a Threat Condition has been 
cured; nonetheless, we agree with the commenter that we should consider 
how to address such situations and whether they warrant additional 
scrutiny. Because we did not make any proposals related to such 
consequences, we believe it would be appropriate to solicit public 
comment before adopting consequences of this nature, so we have 
finalized this rule without addressing that specific issue. We may 
consider this suggestion in a future rulemaking.
    In Sec.  172.401(d), we modified the final regulatory text to 
better align with Sec.  172.401(b). Specifically, in Sec.  172.401(b), 
we state that ASTP/ONC would provide direction to the QHIN to suspend 
one of the QHIN's Participants or Subparticipants. In Sec.  172.401(d), 
we proposed that ONC (or, with ONC's prior authorization, an RCE) shall 
lift a suspension of either the QHIN or one of the QHIN's Participants 
or Subparticipants once the Threat Condition is resolved. We have 
changed the final regulatory text in Sec.  172.401(d) to state that 
ASTP/ONC (or, with ASTP/ONC's prior authorization, an RCE) shall 
provide direction to the QHIN to lift the suspension of one of the 
QHIN's Participants or Subparticipants once the Threat Condition is 
resolved. We believe this finalized text better aligns with the text in 
Sec.  172.401(b), which states that ASTP/ONC (or, with ASTP/ONC's prior 
authorization, an RCE) will provide direction to the QHIN regarding the 
suspension of one of its Participants or Subparticipants.
    Comments. A few commenters suggested updates to Sec.  172.401 to 
clarify the requirements for selective suspension. One commenter 
suggested that a QHIN should be permitted to selectively suspend 
exchange with another QHIN's Participant(s) or Subparticipant(s). The 
commenter noted that a more targeted suspension is reasonable and 
practical to implement while any specific issues are addressed. Another 
commenter requested that ASTP/ONC specify that a QHIN may implement a 
selective suspension due to concerns about patient safety and data 
integrity.
    Response. We appreciate the commenters' support for selective 
suspension for QHINs. Section 172.402(a), which we have finalized as 
proposed, states that a QHIN may, in good faith and to the extent 
permitted by Applicable Law, suspend TEFCA Exchange with another QHIN 
because of reasonable concerns related to the privacy and security of 
information that is exchanged. We decline to modify Sec.  172.402 to 
permit a QHIN to selectively suspend exchange with another QHIN's 
Participant(s) or Subparticipant(s). We appreciate the request for a 
more targeted selective suspension in certain circumstances, but we 
believe each QHIN should be responsible for ensuring that its 
Participants and Subparticipants are meeting applicable requirements. 
We believe the finalized language in Sec.  172.402(a) that states that 
a QHIN may suspend exchange between another QHIN if there is reasonable 
concern about the privacy and security of the data, as well as the 
finalized language in Sec.  172.402(b) that states that the QHIN must 
notify the other QHIN of the suspension in writing, creates appropriate 
guardrails for selective suspension.
    We have finalized the provisions in subpart D as proposed, except 
as follows. We have added to Sec.  172.401(a) language requiring an RCE 
to seek and receive ASTP/ONC's prior authorization before suspending a 
QHIN. We have added to Sec.  172.401(b) language requiring an RCE to 
seek and receive ASTP/ONC's prior authorization before directing the 
QHIN to suspend a Participant's or Subparticipant's TEFCA Exchange. We 
have added to Sec.  172.401(d) language requiring an RCE to seek and 
receive ASTP/ONC's prior authorization before lifting a suspension of 
either a QHIN or one of a QHIN's Participants or Subparticipants once 
the Threat Condition is resolved. We have modified Sec.  172.103(b) to 
clarify that ASTP/ONC cannot subdelegate to the RCE those requirements 
for prior agency authorization. Combined with the review provisions 
that apply to all RCE actions in subpart F of part 172, this language 
helps to ensure that an RCE remains subordinate to ASTP/ONC and 
provides only fact-gathering, ministerial, and administrative support 
to ASTP/ONC. We have also revised the text of Sec.  172.401 for added 
clarity.
    We also would like to clarify one point regarding the proposed 
security requirements for QHINs. Earlier in this section we stated that 
within the TEFCA

[[Page 101800]]

infrastructure, QHINs are expected to meet a high bar for security, 
including compliance with the HIPAA Security Rule or the standards 
required by the HIPAA Security Rule. We make the distinction between 
``compliance with the HIPAA Security Rule'' and compliance with the 
standards required by QHIN participation that mirror the HIPAA Security 
Rule requirements because some entities may not be a covered entity or 
business associate (i.e., a Non-HIPAA Entity) that are regulated by the 
HIPAA Security Rule. In order for TEFCA to have consistent security 
standards, we proposed that even though Non-HIPAA Entities cannot be 
covered by HIPAA, we can still apply comparable security standards to 
such entities. To be clear, the HHS Office for Civil Rights (OCR) is 
the only entity that may determine a HIPAA covered entity's compliance 
with the HIPAA Security Rule. Any determination by a third party or by 
the RCE that a QHIN meets the QHIN requirements does not constitute a 
determination by HHS of the QHIN's compliance with the requirements of 
the HIPAA Security Rule.

E. Subpart E--Termination

    In this subpart, we proposed provisions related to a QHIN's right 
to terminate its own Designation, ONC's (or an RCE's) obligation to 
terminate a QHIN's Designation and related notice requirements, and 
requirements related to the effect of termination. In Sec.  172.501, we 
proposed that a QHIN may terminate its own QHIN Designation at any time 
without cause by providing ninety (90) calendar days prior written 
notice. This provision supports the voluntary nature of TEFCA by 
allowing a QHIN that, for whatever reason, no longer wants to serve as 
a QHIN, to terminate its own QHIN Designation with ninety (90) calendar 
days prior written notice. We stated we believe a QHIN should be able 
to terminate its Designation, regardless of the circumstances or reason 
and that ninety (90) calendar days would provide enough time for ONC, 
the RCE and the departing QHIN to analyze and address the impacts of 
the QHIN's departure.
    In Sec.  172.502, we proposed that a QHIN's Designation will be 
terminated with immediate effect by ONC (or an RCE) giving written 
notice of termination to the QHIN if the QHIN: (a) fails to comply with 
any regulations of the part and fails to remedy such material breach 
within thirty (30) calendar days after receiving written notice of such 
failure; provided, however, that if a QHIN is diligently working to 
remedy its breach at the end of this thirty (30) day period, then ONC 
(or an RCE) must provide the QHIN with up to another thirty (30) 
calendar days to remedy its material breach; or (b) a QHIN breaches a 
material provision of the Common Agreement where such breach is not 
capable of remedy. We requested comments on examples of material 
provisions of the Common Agreement where a breach is not capable of 
remedy.
    We stated in the HTI-2 Proposed Rule that we believe these 
proposals would promote transparency in TEFCA and strengthen the 
underlying trust among and between entities connected to TEFCA. These 
termination provisions would enable ONC (or an RCE) to take swift 
action to remove a non-compliant QHIN and ensure that entities that 
fail to meet their obligations as QHINs (by failing to comply with the 
regulations of the part or by breaching a material provision of the 
Common Agreement) are no longer able to act as QHINs under the TEFCA 
framework. Without the ability for ONC (or an RCE) to terminate non-
compliant QHINs, this trust--which is foundational to TEFCA and 
necessary for the ultimate success of TEFCA--could quickly erode and 
undermine TEFCA's progress.
    In Sec.  172.503, we proposed that QHINs and ONC (or an RCE) would 
be able to terminate the QHIN's Designation at any time and for any 
reason by mutual, written agreement. Allowing two parties to terminate 
an agreement by mutual, written agreement ensures that two parties are 
not forced to follow an agreement that neither wants to follow. In the 
HTI-2 Proposed Rule, ONC stated we believe it is reasonable and 
efficient to allow termination at any time where both ONC (or an RCE) 
and the QHIN are satisfied that a QHIN's termination is in the best 
interest of all.
    During the comment period we noticed discrepancies between the use 
of business days and calendar days when discussing termination in 
preamble and regulation text. Accordingly, we updated the use of 
business days (and adopted the full proposed definition of business 
days in regulation text) and calendar days in the preamble discussion 
in this subpart to match the use of business days and calendar days in 
the regulation text we proposed in this subpart.
    As described elsewhere in this final rule, we have finalized 
references to ``ONC'' in subpart E of the proposed rule as ``ASTP/
ONC.'' For further discussion of the use of ``ASTP/ONC,'' please see 
the Executive Summary of this final rule.
    Comments. Several commenters noted strong support for the 
termination process of QHINs when necessary, particularly in cases of 
financial instability, violations of guidelines, or failure to meet 
established qualifications and regulations. Commenters emphasized the 
importance of having the ability to decertify non-compliant QHINs as 
needed to uphold the integrity of the system.
    Some commenters raised concerns regarding the implications of the 
termination of a QHIN's Designation, particularly for Participants and 
Subparticipants, as well as hospitals and health systems that rely on 
these networks. Commenters highlighted the lack of a migration plan and 
support system for these groups, which raises questions about their 
options during a transition. Additionally, commenters expressed 
concerns about compliance reporting and potential information blocking 
claims affecting Participants and Subparticipants if a QHIN is 
terminated.
    Response. We thank these commenters for these comments. We 
appreciate commenters' concerns related to termination of QHINs 
generally, and more specifically related to the effects of a 
termination on Participants and Subparticipants and the lack of a 
migration plan, but we believe these comments are out of scope for this 
final rule because we did not include any proposals in the HTI-2 
Proposed Rule to address the effects of a termination.
    We also believe the comments related to protection from compliance 
reporting requirements and the information blocking regulations are out 
of scope for this final rule because such comments relate to 
information blocking enforcement. Nonetheless, it is important to 
emphasize that when a QHIN is terminated, its Participants and 
Subparticipants will be unable to exchange or respond to queries 
through that QHIN--meaning TEFCA Exchange would not be possible through 
that QHIN. We invite Participants and Subparticipants to review the 
exceptions to the information blocking regulations to determine if the 
facts of their specific scenarios would fit under an information 
blocking exception. We also refer readers to section 17.3.5 of the 
Common Agreement (section 10.3 of the Terms of Participation) which 
discusses the effect of termination.
    We encourage organizations that connect to a QHIN to discuss 
transition plans with the QHIN as they are discussing connecting to 
that QHIN and establishing the parameters of their relationship with 
the QHIN. We also note that, based on the requirements for Designation 
we have finalized, QHINs should be high-functioning entities that

[[Page 101801]]

can support nationwide exchange at scale, and such organizations will 
have strong incentives to ensure their ongoing participation as QHINs.
    Comments. One commenter sought clarification on the rationale 
behind ASTP/ONC's decision to include all termination provisions of the 
Common Agreement in the regulation except for section 17.3.5, ``Effect 
of Termination of the Common Agreement.'' The commenter further stated 
that its request for clarification underscores the need for 
transparency and understanding of the regulatory framework affecting 
QHINs and their stakeholders.
    Response. We appreciate this comment. We did not propose to include 
provisions related to the effect of termination of the Common Agreement 
because we do not believe that provisions focused on the effect of a 
termination are necessary in this rulemaking. The termination 
provisions we included in this rulemaking explain the requirements and 
processes for termination. If a QHIN is terminated and decides to 
appeal the decision, the requirements and processes in this rulemaking 
would be integral in deciding whether the appeal would be successful. 
On the other hand, provisions related to the effect of termination 
would have little bearing on the ultimate success of an appeal and thus 
we do not think it is necessary to include such provisions in this 
rulemaking. As the commenter noted, there is a provision in the Common 
Agreement that addresses the effect of termination.
    We have finalized all provisions in subpart E as proposed. In 
addition, we have added to Sec.  172.502 language requiring an RCE to 
seek and receive ASTP/ONC's prior authorization before terminating a 
QHIN. Under Sec.  172.103(b), ASTP/ONC cannot subdelegate to the RCE 
this requirement for prior agency authorization. Combined with the 
review provisions that apply to all RCE actions in subpart F of part 
172, this language helps to ensure that an RCE remains subordinate to 
ASTP/ONC and provides only fact-gathering, ministerial, and 
administrative support to ASTP/ONC.

F. Subpart F--Review of RCE[supreg] or ASTP/ONC Decisions

    ASTP/ONC oversees the RCE's work and has the right to review the 
RCE's conduct and its execution of nondiscrimination and conflict of 
interest policies that demonstrate the RCE's commitment to treating 
QHINs in a transparent, fair, and nondiscriminatory way.\20\ In subpart 
F, we proposed to establish processes for review of RCE or ONC actions, 
including QHIN appeal rights and the process for filing an appeal. 
These appeal rights would ensure that a QHIN or Applicant QHIN that 
disagrees with certain RCE or ONC decisions will have recourse to 
appeal those decisions. Our proposed Sec.  172.600 reflects this 
overall scope as an applicability section for this subpart.
---------------------------------------------------------------------------

    \20\ See Common Agreement section 3.1, 89 FR 35107 (May 1, 
2024), https://www.federalregister.gov/documents/2024/05/01/2024-09476/notice-of-publication-of-common-agreement-for-nationwide-health-information-interoperability-common.
---------------------------------------------------------------------------

    In Sec.  172.601, we proposed provisions to establish ONC's 
authority to review RCE determinations, policies, and actions, as well 
as procedures for exercising such review. We proposed in Sec.  
172.601(a) that ONC may, in its sole discretion, review all or any part 
of any RCE determination, policy, or action. In Sec.  172.601(b) we 
proposed ONC may, in its sole discretion and on notice to affected 
QHINs or Applicant QHINs, stay any RCE determination, policy, or other 
action. In Sec.  172.601(c), we proposed ONC may, in its sole 
discretion and on written notice, request that a QHIN, Applicant QHIN, 
or the RCE provide ONC additional information regarding any RCE 
determination, policy, or other action. In Sec.  172.601(d), we 
proposed that on completion of its review, ONC may affirm, modify, or 
reverse the RCE determination, policy, or other action under review. 
Additionally, we proposed to provide notice to affected QHINs or 
Applicant QHINs that includes the basis for ONC's decision. In Sec.  
172.601(e), we proposed ONC will provide written notice under this 
section to affected QHINs or Applicant QHINs in the same manner as the 
original RCE determination, policy, or other action under review. We 
stated we believe these proposals provide transparency into the level 
of oversight ONC has in reviewing RCE determinations, policies, or 
actions and firmly establish ONC's authority to affirm, modify, or 
reverse such determinations, policies, and actions. We also noted we 
believe these provisions are important to assure QHINs and Applicant 
QHINs that we have the ability to effectively exercise oversight of the 
RCE, as well as provide all parties with an interest in the 
administration of TEFCA with confidence that we can and will take 
necessary action to ensure that QHINs and Applicant QHINs comply with 
the regulations we proposed in part 172.
    In Sec.  172.602, we proposed to establish bases for Applicant 
QHINs and QHINs to appeal decisions to ONC. We proposed that an 
Applicant QHIN or QHIN may appeal certain decisions to ONC or a hearing 
officer, as appropriate. In Sec.  172.602(a)(1), we proposed that an 
Applicant QHIN would be able to appeal the denial of its application. 
In Sec.  172.602(a)(2), we proposed that a QHIN would be able to appeal 
a decision to (1) suspend a QHIN or instruct a QHIN to suspend its 
Participant or Subparticipant; or (2) terminate a QHIN's Common 
Agreement. We requested comment on the proposed bases for appeal.
    In Sec.  172.603, we proposed the method and timing for filing an 
appeal. In Sec.  172.603(a), we proposed that to initiate an appeal, an 
authorized representative of the Applicant QHIN or QHIN must submit 
electronically, in writing to ONC, a notice of appeal that includes the 
date of the notice of appeal, the date of the decision being appealed, 
the Applicant QHIN or QHIN who is appealing, and the decision being 
appealed within fifteen (15) calendar days of the Applicant QHIN's or 
QHIN's receipt of the notice of denial of an application, suspension or 
instruction to suspend its Participant or Subparticipant, or) 
termination. With regard to an appeal of a termination, the fifteen 
(15) calendar day timeframe may be extended by ONC up to another 
fifteen (15) calendar days if the QHIN has been granted an extension 
for completing its remedy under Sec.  172.502(a). The notice of appeal 
would serve to notify ONC that the Applicant QHIN or QHIN is planning 
to file an appeal and would require inclusion of only the minimum 
amount of information necessary to provide such notice (i.e., the date 
of the notice of appeal, the date of the decision being appealed, the 
Applicant QHIN or QHIN who is appealing, and what is being appealed). 
As such, we stated we believe fifteen (15) business days would be an 
adequate amount time for deciding whether to initiate an appeal and 
submitting such information.
    In Sec.  172.603(b), we proposed that an authorized representative 
of an Applicant QHIN or QHIN must submit electronically, to ONC, within 
thirty (30) calendar days of filing the intent to appeal: (1) A 
statement of the basis for appeal, including a description of the facts 
supporting the appeal with citations to documentation submitted by the 
QHIN or Applicant QHIN; and (2) Any documentation the QHIN would like 
considered during the appeal.
    We stated we expect that it would take an Applicant QHIN or QHIN 
some

[[Page 101802]]

time to collect all of the relevant information and documentation to 
support its appeal, and accordingly proposed a timeframe for requesting 
an appeal of thirty (30) calendar days from the filing of the intent to 
appeal with ONC. We welcomed comments on whether this timeframe, as 
well as the timeframe for submitting an intent to appeal, are adequate 
and appropriate.
    In Sec.  172.603(c), we proposed that an Applicant QHIN or QHIN 
filing the appeal may not submit on appeal any evidence it did not 
submit prior to the appeal, except by permission of the hearing 
officer. We stated we believe this provision balances a QHIN or 
Applicant QHIN's right to introduce evidence with the need for orderly 
proceedings. We are aware that under our proposed regulations, QHINs 
facing suspension or termination do not have an express right to 
introduce evidence. We solicited comments on whether and when a QHIN 
facing suspension or termination should have a right to introduce that 
evidence--for example as part of demonstrating that a material breach 
has been remedied or is capable of remedy under Sec.  172.502, at the 
hearing officer stage, or some combination of the two based on 
circumstances of the suspension or termination.
    In Sec.  172.604, we proposed that an appeal would not stay a 
suspension or termination, unless otherwise ordered by ONC or the 
hearing officer assigned under Sec.  172.605(b). This means that in the 
event of an appeal of a suspension or termination, the appeal would not 
stop the suspension or termination from being effective. We stated we 
believe this proposed approach is important because a QHIN would only 
be suspended or terminated for infractions that could, for example, 
jeopardize the privacy and security of TEFCA Exchange.
    Before a QHIN is terminated under Sec.  172.502(a), we noted the 
QHIN would have already been given an opportunity to remedy the breach 
unless the breach is not capable of remedy. The move by ONC or an RCE 
to terminate a QHIN would mean either the QHIN tried and failed to 
remedy the issue, or a remedy is not possible. In either case, we 
stated we believe it would be appropriate not to stay the termination. 
In the case of a suspension, the QHIN would have been found to be 
responsible for a Threat Condition, and we stated we believe the risk 
to the privacy and security of the TEFCA ecosystem would far outweigh 
any perceived benefit of staying the suspension.
    In Sec.  172.605, we proposed provisions related to the assignment 
of a hearing officer. In Sec.  172.605(a), we proposed that, in the 
event of an appeal, the National Coordinator may exercise authority 
under Sec.  172.601 to review the RCE determination being appealed. We 
further proposed an appealing QHIN or Applicant QHIN that is not 
satisfied with ONC's subsequent determination may appeal that 
determination to a hearing officer by filing a new notice of appeal and 
other appeal documents that comply with Sec.  172.603. In Sec.  
172.605(b), we proposed if ONC declines review under paragraph (a), or 
if ONC made the determination under review, ONC would arrange for 
assignment of the case to a hearing officer to adjudicate the appeal.
    We specified in proposed Sec.  172.605(c) that the hearing officer 
must be an officer appointed by the Secretary of Health and Human 
Services (for more information about officers and appointments, see 
section III.D.5.c of the HTI-2 Proposed Rule, 89 FR 63612 through 
63615). In Sec.  172.605(d), we proposed, the hearing officer may not 
be responsible to, or subject to the supervision or direction of, 
personnel engaged in the performance of investigative or prosecutorial 
functions for ONC, nor may any officer, employee, or agent of ONC 
engaged in investigative or prosecutorial functions in connection with 
any adjudication, in that adjudication or one that is factually 
related, participate or advise in the decision of the hearing officer, 
except as a counsel to ONC or as a witness.
    In Sec.  172.606, we proposed requirements related to adjudication. 
In Sec.  172.606(a), we proposed that the hearing officer would decide 
issues of law and fact de novo and would apply a preponderance of the 
evidence standard when deciding appeals. De novo review means that the 
hearing officer would decide the issue on appeal without deference to a 
previous decision (i.e., ONC's or the RCE's decision to (1) deny an 
application, (2) suspend a QHIN or to instruct a QHIN to suspend its 
Participant or Subparticipant, or (3) terminate a QHIN's Common 
Agreement). We stated we believe de novo review is appropriate for 
appeals by Applicant QHINs or QHINs because ONC ultimately has 
responsibility for TEFCA operations and implementation, even though the 
RCE is a contractor acting on ONC's behalf. Given the gravity and 
potentially significant implications (financial, effect on existing 
contracts, etc.) of a denied application, suspension, or termination, 
we noted we believe the hearing officer the National Coordinator 
arranges to be assigned should make an independent decision, taking all 
of the facts and evidence the parties present into consideration.
    As described in the HTI-2 Proposed Rule, the ``preponderance of the 
evidence'' standard means the burden of proof is met when the party 
with the burden (the appealing Applicant QHIN or QHIN) convinces the 
fact finder (hearing officer) that there is a greater than 50% chance 
that the claim is true. This standard is used in most civil cases and 
would only require the appealing party to show that a particular fact 
or event was more likely than not to have occurred. We stated we 
believe this threshold creates the right balance for requiring an 
appealing Applicant QHIN or QHIN to make a strong case to succeed on 
appeal, while not imposing a standard that would be extremely difficult 
for the appeal Applicant QHIN or QHIN to meet. We requested comment on 
whether the ``preponderance of the evidence'' is the appropriate 
standard, or if another standard (e.g., clear and convincing evidence, 
beyond a reasonable doubt, etc.) would be more suitable.
    In Sec.  172.606(b), we proposed that a hearing officer would make 
a determination based on the written record or any information from a 
hearing conducted in-person, via telephone, or otherwise (for example, 
via video teleconference). We proposed that the written record would 
include ONC's or the RCE's determination and supporting information, as 
well as all appeal materials submitted by the Applicant QHIN or QHIN 
pursuant to Sec.  172.603. We proposed these requirements for the 
written record because it is important that the written record reflect 
both the position of ONC or the RCE and the Applicant QHIN or QHIN. We 
proposed that the hearing officer would have sole discretion to conduct 
a hearing in certain situations. We proposed that the hearing officer 
could conduct a hearing to require either party to clarify the written 
record under Sec.  172.606(b)(1). Last, we proposed that the hearing 
officer could conduct a hearing if they otherwise determine a hearing 
is necessary. We stated we believe the last provision is necessary 
because it gives the hearing officer discretion to conduct a hearing 
based on the specific circumstances surrounding the appeal, even if the 
need for the hearing does not fit under the first or second criteria 
detailed above.
    In Sec.  172.606(c), we proposed that a hearing officer would 
neither receive witness testimony nor accept any new information beyond 
what was provided in accordance with paragraph (b) of this section, 
except for good cause shown by

[[Page 101803]]

the party seeking to submit new information. We noted we believe this 
provision will help ensure that the appeals process is consistent and 
fair for all involved.
    In Sec.  172.607, we proposed requirements related to a decision by 
the hearing officer. In Sec.  172.607(a), we proposed that the hearing 
officer would issue a written determination. We requested comment on 
whether we should include a specific timeframe for issuing the written 
determination, or whether abstaining from including a specific 
timeframe is a better approach given the varying complexity and 
circumstances of each appeal.
    To ensure accountability, and to ensure that the hearing officer's 
decisions would be subject to the discretionary review of a principal 
officer of the United States, we proposed in Sec.  172.607(b) that a 
hearing officer's decision on an appeal is the final decision of HHS 
unless within 10 business days, the Secretary, at the Secretary's sole 
discretion, chooses to review the determination. We also proposed that 
ONC would notify the appealing party if the Secretary chooses to review 
the determination and once the Secretary makes his or her 
determination. We did not propose a specific timeframe for the 
Secretary to complete their review (if the Secretary chooses to review) 
because we believe that if the Secretary makes the decision to review a 
hearing officer's determination, the Secretary would be informed enough 
on the issues of the case to determine an appropriate review timeframe.
    As described elsewhere in this final rule, we have finalized 
references to ``ONC'' in subpart F of the proposed rule as ``ASTP/
ONC.'' For further discussion of the use of ``ASTP/ONC,'' please see 
the Executive Summary of this final rule.
    Comments. Commenters were generally supportive of ASTP/ONC's 
proposal for a review process of RCE or ASTP/ONC decisions but 
expressed concerns regarding the scope and standard of ASTP/ONC's 
review of RCE and prior ASTP/ONC decisions. In particular, some 
commenters stated that ASTP/ONC's discretion for review of RCE or prior 
ASTP/ONC decisions would be too broad and suggested that ASTP/ONC 
include narrower requirements for when a Hearing Officer can review RCE 
or prior ASTP/ONC decisions de novo, such as limiting use of the de 
novo standard to only when it was a denial of QHIN designation. A few 
commenters also suggested that ASTP/ONC specify a timeframe for ASTP/
ONC review and decision and similarly for review and written decisions 
by a hearing officer. One commenter recommended that a hearing officer 
have 30 days to issue a written decision on an appeal.
    Response. We appreciate commenters concerns about the scope of 
ASTP/ONC's ability to review decisions and the timeframe for when a 
hearing officer must issue a decision. In this final rule, we finalize 
all subpart F proposals as proposed, except for revisions made in 
response to comments as discussed here. As TEFCA participation grows, 
it is important for ASTP/ONC and a hearing officer to be able to review 
decisions that are impactful to TEFCA participation, and in a manner 
that gives all TEFCA participants confidence in TEFCA. A de novo 
standard supports such confidence because the hearing officer can 
exercise independent judgment and review of all relevant facts and law. 
As for the timeframe for reviews, a 30-day timeframe for issuing a 
decision by either ASTP/ONC or a hearing officer under subpart F could 
be too limiting in complex cases. However, we do believe that providing 
clarity on timeframes for decisions would be helpful to parties subject 
to ASTP/ONC and/or hearing officer decisions. Accordingly, we have 
revised subpart F in two ways. We have specified in Sec.  172.601(f) 
that ASTP/ONC will issue a decision within a timeframe agreed to by the 
affected Applicant QHIN or QHIN, as applicable, the RCE, and ASTP/ONC. 
ASTP/ONC may, however, at its sole discretion, extend the timeframe for 
a decision as circumstances necessitate. This remains consistent with 
our proposal in that we did not place a time limit on issuing a 
decision. ASTP/ONC will issue a decision by mailing or sending 
electronically written notice of such decision as specified in Sec.  
172.601(e). Similarly to ASTP/ONC timeframe revision, we have revised 
Sec.  172.607(a) to specify that the hearing officer will issue a 
written determination within a timeframe agreed to by the affected 
Applicant QHIN or QHIN, as applicable, and ASTP/ONC and approved by the 
hearing officer. The hearing officer may, at their sole discretion, 
extend the timeframe for a written determination as circumstances 
necessitate. Again, this is consistent with our proposal in that we did 
not place a time limit on issuing a decision.
    We have also revised the format of Sec.  172.603(a) to provide 
clarity regarding the method and timing for an applicant QHIN or QHIN 
to file an appeal. The addition of the numerated list in Sec.  
172.603(a) is a formatting change made for clarity.
    In addition, we have added to Sec. Sec.  172.601(a) and (b) and 
172.605(a) language that if ASTP/ONC reviews (under Sec.  172.601(a)) 
or stays (under Sec.  172.601(b)) an RCE determination for which 
regulations in part 172 required ASTP/ONC's prior authorization, no 
agent, official, or employee of ASTP/ONC who helped to evaluate or 
decide the prior authorization, or a prior authorization involving the 
same party(s) or underlying facts, may participate in deciding or 
advising ASTP/ONC on its review of (including whether it should stay) 
that determination. This language will help protect any review by ASTP/
ONC of the RCE from influence by someone who previously authorized the 
RCE action under review, protect the fairness and integrity of ASTP/
ONC's review process, and preserve the separation of functions within 
ONC.
    Comments. A commenter raised concerns that the scope of subpart F 
was too limiting. The commenter recommended that disputes between 
QHINs, and between a QHIN and a Participant, should be afforded review 
and appeal under the regulations. The commenter argued that a QHIN's 
dispute resolution policy, which it is required to maintain per subpart 
B, would be ineffective in resolving disputes between QHINs or with a 
Participant of another QHIN. The commenter further asserted that a 
QHIN's decision to take action against a Participant significantly 
affects that Participant, their patients, and other Participants 
(including from other QHINs) that rely on the Participant's data to 
make care decisions. As such, the commenter specifically recommended 
that we include a process for appeal and ASTP/ONC review of QHIN 
decisions to suspend Participants or Subparticipants, including 
providing a Participant the opportunity to appeal such decisions. The 
commenter also recommended that a QHIN be afforded the right to appeal 
an instruction (presumably by the RCE or ASTP/ONC) to suspend a 
Participant or Subparticipant.
    Response. We did not propose the scope of review and appeals that 
the commenter recommends, and the public was not put on notice that 
such a policy might be finalized and given an opportunity to comment. 
Thus, we decline to adopt such an approach in this final rule.
    We note that we considered proposing to extend the appeal process 
to Participants and Subparticipants but decided against proposing that 
approach for a couple reasons. First, we believe that QHINs should have 
the autonomy

[[Page 101804]]

to make decisions within their respective networks. Second, we note 
that Participants and Subparticipants are able to join different QHINs 
if they cannot resolve a dispute with an existing QHIN.
    For similar reasons, we believe the Dispute Resolution Process 
should be limited to disputes filed by the RCE or a QHIN. A QHIN could 
elevate a dispute on behalf of its Participant or Subparticipant to the 
Dispute Resolution Process, but we believe that is a decision that 
should be left to the respective QHIN.

G. Subpart G--QHINTM Attestation for the Adoption of the 
Trusted Exchange Framework and Common AgreementTM

    Section 4003(b) of the Cures Act added section 3001(c)(9), 
``Support for Interoperable Networks Exchange,'' to the PHSA. Section 
3001(c)(9)(D)(ii) requires HHS to establish, through notice and comment 
rulemaking, a process for HINs that voluntarily elect to adopt TEFCA to 
attest to such adoption of the framework and agreement. Section 
3001(c)(9)(D)(i) also requires the National Coordinator to publish on 
ONC's website a list of the HINs that have adopted the Common Agreement 
and are capable of trusted exchange pursuant to the Common Agreement.
    QHINs are the only entities permitted to ``adopt'' the Common 
Agreement, which is accomplished by becoming a signatory to the Common 
Agreement. As such, we proposed that only QHINs would be able to attest 
to the adoption of the Common Agreement and the Trusted Exchange 
Framework. While the Trusted Exchange Framework was foundational for 
creating the provisions of the Common Agreement, it is, as noted above, 
a separate set of principles. Therefore, we proposed that for purposes 
of attesting to the adoption of the Trusted Exchange Framework, QHINs 
would be required to expressly attest to their agreement and adherence 
to the Trusted Exchange Framework.\21\
---------------------------------------------------------------------------

    \21\ The Trusted Exchange Framework (TEF): Principles for 
Trusted Exchange (January 2022), https://www.healthit.gov/sites/default/files/page/2022-01/Trusted_Exchange_Framework_0122.pdf.
---------------------------------------------------------------------------

    We described that once attestation is complete and deemed valid, 
QHINs would be publicly listed on ONC's website. This regulatory 
provision would implement the HIN attestation provision from the Cures 
Act and would provide benefits to the public, Federal partners, and 
interested parties. For example, a Federal website listing of attesting 
QHINs would make it easy for the public to identify whether an entity 
is or is not a QHIN and provide a resource for Federal partners to help 
determine whether participants in some of their programs also belong to 
a network that is recognized as a QHIN. Section 3001(c)(9)(E) provides 
the option for Federal agencies to require, under certain 
circumstances, adoption of TEFCA for health information exchange 
networks that they contract with or enter into agreements with.
    To implement sections 3001(c)(9)(D)(i) and (ii) of the PHSA, we 
proposed to establish subpart G in part 172, titled ``QHIN Attestation 
for the Adoption of the Trusted Exchange Framework and Common 
Agreement.''
    We proposed in Sec.  172.700 that subpart G would establish the 
attestation submission requirements applicable to QHINs. In Sec.  
172.701, we proposed attestation submission requirements for QHINs and 
review and acceptance processes that ONC will follow for TEFCA 
attestations. In Sec.  172.701(b), we proposed that in order to be 
listed in the QHIN Directory described in proposed Sec.  172.702, a 
QHIN would be required to submit to ONC an attestation affirming 
agreement with and adherence to the Trusted Exchange Framework and its 
adoption of the Common Agreement. We further proposed in Sec.  
172.701(b) that a QHIN would be required to submit to ONC identifying 
information consisting of its name, address, city, state, zip code, and 
a hyperlink to its website. We also proposed that the QHIN would be 
required to submit to ONC identifying information about its authorized 
representative including the representative's name, title, phone 
number, and email address. We proposed that a QHIN would also be 
required to provide documentation confirming its Designation as a QHIN. 
We also proposed that a QHIN would be required to provide ONC with 
written notice of any changes to its identifying information provided 
in accordance with Sec.  172.701 within 30 calendar days of the 
change(s) to its identifying information. We noted we believe the above 
provisions provide clear instructions for submitting a QHIN attestation 
that will support a consistent and transparent QHIN attestation process 
and provides ONC with the information needed to identify the entity and 
contact the authorized representative.
    We proposed in Sec.  172.701(c) that a QHIN must electronically 
submit its attestation and documentation specified in Sec.  172.701(b) 
either via an email address identified by ONC or via a submission on 
the ONC website, if available. We proposed in Sec.  172.701(d) that 
once a QHIN has submitted its attestation and documentation, ONC would 
either accept or reject the submission within 30 calendar days. We 
proposed that ONC would accept the submission if it determines that the 
QHIN has satisfied the requirements of Sec.  172.701(b) and (c). In 
such instances, we proposed that ONC would provide written notice to 
the applicable QHIN's authorized representative that the submission has 
been accepted. In Sec.  172.701(d), we also proposed that ONC would 
reject a submission if it determines that the requirements of Sec.  
172.701(b) or (c), or both, have not been satisfied. In such instances, 
we proposed that ONC would provide written notice to the QHIN's 
authorized representative of the determination along with the basis for 
the determination. We proposed that an ONC determination would be a 
final agency action and not subject to administrative review, except 
the Secretary may choose to review the determination as provided in 
Sec.  172.607(b). However, we proposed that a QHIN may, at any time, 
resubmit an attestation and documentation in accordance with Sec. Sec.  
172.701(b) and (c). We stated we believe these submission procedures 
will support a consistent and transparent QHIN attestation process. We 
welcomed comments on these procedures.
    In Sec.  172.702, we proposed the requirements for a QHIN 
directory. We proposed in Sec.  172.702(a) that this subpart would 
establish processes for publishing a directory of QHINs on the ONC 
website. We proposed in Sec.  172.702(b)(1) that, within fifteen (15) 
calendar days of notifying a QHIN that its submission has been 
accepted, ONC would publish, at a minimum, the QHIN's name in the QHIN 
directory.
    We proposed Sec.  172.702(b)(2) to identify within the QHIN 
directory those QHINs that have been suspended under the Common 
Agreement. A QHIN directory that includes QHINs that have adopted the 
Common Agreement and are capable of TEFCA Exchange and those QHINs 
suspended under the Common Agreement offers a transparent list of QHINs 
participating in TEFCA. As noted above, the QHIN directory may serve as 
a useful tool for the public, Federal partners, and other interested 
parties seeking information about QHINs. Therefore, we welcomed 
comments regarding the information we proposed to include in the QHIN 
directory.
    We proposed in Sec.  172.702(c) to establish requirements for 
removal of a QHIN from the QHIN directory. We proposed in Sec.  
172.702(c)(1) that ONC will remove a QHIN that is no longer eligible 
for QHIN status from the QHIN

[[Page 101805]]

directory. We proposed that a QHIN whose Common Agreement has been 
terminated would no longer be considered a QHIN and so would be removed 
from the QHIN directory. We noted the removal of a QHIN whose Common 
Agreement has been terminated from the QHIN Directory would be a 
ministerial action by ONC.
    We proposed in Sec.  172.702(c)(2) that upon termination of a 
QHIN's Common Agreement, ONC (or an RCE) will send a written statement 
of intent to remove the QHIN from the QHIN Directory to the authorized 
representative of the QHIN. Under Sec.  172.702(c)(3), we proposed that 
the written statement would include, as appropriate, (i) the name of 
the terminated QHIN and the name and contact information of the 
authorized representative of the QHIN; (ii) a short statement setting 
forth findings of fact with respect to any violation of the Common 
Agreement or other basis for the QHIN's termination; (iii) other 
materials as the RCE may deem relevant. In Sec.  172.702(d), we 
proposed that a QHIN that is removed from the QHIN Directory would 
remain removed until a new attestation is accepted by ONC in accordance 
with the processes specified in subpart G of the part. In Sec.  
172.702(e), we proposed that an ONC determination under Sec.  172.702 
is final agency action and not subject to further administrative 
review, except the Secretary may choose to review the determination as 
provided in Sec.  172.607(b). We stated we believe this proposal was 
appropriate because a QHIN would have had ample opportunity to appeal 
its termination under the provisions in proposed subpart F (89 FR 
63654).
    We sought comments on alternative ways to structure the 
requirements to remove a QHIN from the QHIN directory.
    Comments. Multiple commenters agreed with our proposal to require 
QHINs to attest, with one commenter noting the potential burden 
attestation could cause for all other Participants and Subparticipants. 
Another commenter, while not suggesting we impose attestation 
requirements, recommended that we include all TEFCA Participants, 
Subparticipants and delegates along with their entity type (e.g., 
health plan, provider, delegate of provider) and relationship(s) in a 
publicly accessible directory on ASTP/ONC's website. The commenter 
asserted that this would provide greater transparency and help health 
care organizations understand the networks that other entities 
participate in to determine whether a connection already exists or if a 
new exchange needs to be set-up.
    Response. We appreciate commenters' agreement with our proposal and 
one commenter's suggestions. In this final rule, we have finalized a 
requirement, in order to be listed in the QHIN Attestation Directory, 
that applies only to QHINs that attest. We have also finalized all 
subpart G proposals as proposed, except for revisions made in response 
to comments discussed here and below. We generally strive to improve 
transparency where appropriate and permissible. Congress authorized, in 
PHSA section 3001(c)(9)(D), a directory of health information networks, 
which is a directory narrower in scope than the commenter suggested and 
that we proposed. Therefore, we decline to adopt the commenter's 
suggested changes to the scope of information included in the QHIN 
Attestation Directory. We will consider ways in which TEFCA can improve 
such transparency for QHINs, Participants, Subparticipants, and the 
public at large.
    Comments. One commenter did not support the QHIN attestation 
proposal, arguing that it was unnecessary and duplicative of a QHIN 
signing the Common Agreement. The commenter further questioned the 
requirement to ``adhere to'' the Trusted Exchange Framework (TEF), 
noting that, by its own terms, it is a compilation of non-binding 
principles. Another commenter similarly argued that the TEF was broad 
and could not be practically ``adhered to.'' Both of these commenters 
inquired as to what ``adhere to'' meant in terms of the TEF, with one 
suggesting that ``adhere to'' be replaced with ``agreement with.'' One 
commenter suggested that we clarify that any rejection of an 
attestation by ASTP/ONC will not affect the QHIN's designation status 
or ability to participate in TEFCA.
    Response. Establishing a process for attesting to the adoption of 
TEFCA by QHINs that voluntarily elect to adopt TEFCA fulfills a 
statutory obligation by ASTP/ONC. Such a process is paired with the 
public posting on our website of a directory of these QHINs, which may 
provide easy recognition and validation for the public of those 
entities that have been deemed QHINs under TEFCA. We agree with 
commenters that our proposed wording in Sec.  172.701(b)(1)(i)(A) of 
``. . . [a]greement with and adherence to the [TEF] . . . .'' may cause 
confusion and perceived contradiction with what are characterized as 
broad, non-binding principles. The statute uses the term ``adoption'' 
with regard to both the Common Agreement and TEF. As such, we are 
reverting to use of this term under our regulatory process for 
attesting to adoption of the Common Agreement and the TEF by revising 
Sec.  172.701(b)(1)(i) to read as follows: ``[a]ttestation affirming 
its adoption of the Common Agreement and Trusted Exchange Framework.'' 
For clarity, by attesting to ``adopt'' the TEF, we mean a QHIN would 
practice and use the TEF principles. We also clarify that the 
regulatory process for QHIN attestation is separate and distinct from 
the regulatory criteria we are finalizing for obtaining and maintaining 
QHIN status, as well as any requirements in the Common Agreement.
    Comments. Multiple commenters expressed a need for a definitive 
attestation schedule for QHINs. One commenter suggested that we 
incorporate the required attestation into the RCE's onboarding and 
designation process.
    Response. Attestation would be expected each time a QHIN signs the 
Common Agreement, including new versions, and/or the TEF is updated. To 
be listed on the ASTP/ONC website, QHINs would need to comply with the 
attestation submission and acceptance requirements of Sec.  172.701. As 
proposed and finalized in Sec.  172.701 a QHIN will be able to 
electronically submit its attestation via email or via the ASTP/ONC 
website, if available. The exact timing (beyond when signing the Common 
Agreement and/or when the TEF is updated) and specifics of the 
submission method, such as by use of a voluntary standard form, will 
not be codified in regulation through this final rule, but will be 
determined in a manner that best aligns with statutory obligations and 
overall efficiencies.
    Comments. Multiple commenters expressed concern that use of ``QHIN 
Directory'' will confuse stakeholders, as the Common Agreement refers 
to an ``RCE Directory Service'' and the QHIN Technical Framework (QTF) 
refers to a ``QHIN Directory.'' One commenter suggested that we 
establish a hyperlink from our website to the RCE website because the 
RCE maintains a list of QHINs.
    Response. Our approach, finalized in this final rule, fulfills a 
specific statutory requirement to post the names on our website. We 
agree with the commenters that ``QHIN Directory'' may cause some 
confusion. Therefore, in alignment with the statutory instruction, we 
are renaming the directory ``QHIN Attestation Directory'' and have 
revised references throughout Sec. Sec.  172.701 and 172.702 
accordingly to refer to the ``QHIN Attestation Directory'' rather than 
the QHIN Directory. We have also

[[Page 101806]]

revised Sec.  172.702(a) (``Applicability'') to more clearly align with 
statutory instruction by stating ``[t]his subpart establishes processes 
for publishing a directory on the ASTP/ONC website of QHINs that 
voluntarily elect to adopt TEFCA and attest to such adoption.'' We also 
note, in response to comment, that we currently provide a hyperlink to 
the RCE website from our website.
    As described elsewhere in this final rule, we have finalized 
references to ``ONC'' in subpart G of the proposed rule as ``ASTP/
ONC.'' For further discussion of the use of ``ASTP/ONC,'' please see 
the Executive Summary of this final rule. We also made a minor change 
to Sec.  172.702(c)(3)(iii) by removing the word ``the'' before ASTP/
ONC, to align with other references to ASTP/ONC. This change is for 
clarity and is non-substantive.

VI. Severability

    As we explained in the HTI-2 Proposed Rule (89 FR 63511), it was 
our intent that if any provision of the proposed rule were, if or when 
finalized, held to be invalid or unenforceable--facially or as applied 
to any person, plaintiff, or circumstance--or stayed pending further 
judicial or agency action, such provision shall be severable from other 
provisions finalized, and from rules and regulations otherwise in 
effect, and not affect the remainder of provisions finalized. It was 
and continues to be our intent that, unless such provision shall be 
held to be utterly invalid or unenforceable, it be construed to give 
the provision maximum effect permitted by law including in the 
application of the provision to other persons not similarly situated or 
to other, dissimilar circumstances from those where the provision may 
be held to be invalid or unenforceable.
    This final rule establishes part 172 and finalizes revisions to 
certain sections within 45 CFR parts 170 and 171. The provisions 
finalized in this final rule, whether codified in 45 CFR part 170, 171, 
or 172, are intended to and will operate independently of each other 
and of provisions finalized in previous rules, even if multiple of them 
may serve the same or similar general purpose(s) or policy goal(s). 
Where any section or paragraph in part 170, 171, or 172 is necessarily 
dependent on another, the context generally makes that clear (such as 
by cross-reference to a particular standard, requirement, condition, or 
pre-requisite, or other regulatory provision). Where any section or 
paragraph within 45 CFR part 170, 171, or 172 includes a dependency on 
any provision of any section or paragraph of any part in title 45 of 
the CFR, or in any other title of the CFR, that is stayed or held 
invalid or unenforceable (as described in the preceding paragraph), we 
intend that other provisions of such paragraph(s) or section(s) in 45 
CFR part 170, 171, or 172 that operate independently of said provision 
would remain in effect.
    For example, if the regulation at Sec.  171.403 TEFCA Manner 
Exception were stayed or held facially invalid or unenforceable in 
whole or in part, we would intend for the other information blocking 
exceptions in part 171 to remain available to actors, and for all 
sections and paragraphs within parts 170 and 172 to also continue to be 
in effect. To provide another example, if any provision of any section 
or paragraph of part 172 were stayed or held utterly invalid or 
unenforceable, we would intend for all other sections in part 172 that 
do not depend upon the stayed or invalidated provisions to remain in 
full effect. Similarly, if any provision of part 172 were stayed or 
held to be invalid or unenforceable as applied to any person, 
plaintiff, or circumstance, it is our intent that such provision--and 
any section or paragraph of part 172, 171, or 170 that may reference 
such provision--be construed to give the provision maximum effect 
permitted by law including in the application of the provision to other 
persons not similarly situated or to other, dissimilar circumstances 
from those where the provision may be held to be invalid or 
unenforceable.
    To ensure our intent for severability of provisions is clear in the 
CFR, we proposed (as explained at 89 FR 63511) the addition to 
Sec. Sec.  170.101 (89 FR 63766) and 171.101 (89 FR 63802), and 
inclusion in the newly codified Sec.  172.101 (89 FR 63805), of a 
paragraph stating our intent that if any provision is held to be 
invalid or unenforceable it shall be construed to give maximum effect 
to the provision permitted by law, unless such holding shall be one of 
utter invalidity or unenforceability, in which case the provision shall 
be severable from the part and shall not affect the remainder thereof 
or the application of the provision to other persons not similarly 
situated or to other dissimilar circumstances.
    We did not receive any comments specific to our proposal to codify 
paragraphs stating our intent for severability in part 170, 171, or 172 
or regarding our explanation that the provisions finalized in this rule 
are intended to and will operate independently of each other. We have 
finalized as proposed, the addition to Sec. Sec.  170.101 and 171.101, 
and inclusion in the newly codified Sec.  172.101, a paragraph stating 
our intent for severability of provisions in each of these parts. We 
affirm and emphasize our intent that if any provision of this final 
rule were held to be invalid or unenforceable--facially or as applied 
to any person, plaintiff, or circumstance--or stayed pending further 
judicial or agency action, such provision shall be severable from other 
provisions of this rule, and from rules and regulations currently in 
effect, and not affect the remainder of this rule. We further affirm 
and emphasize our intent that if any provision codified in part 170, 
171, or 172, whether finalized in this or a prior rule, were to be held 
to be invalid or unenforceable--facially or as applied to any person, 
plaintiff, or circumstance--or stayed pending further judicial or 
agency action, such provision shall be severable from other provisions 
of this rule, and from rules and regulations currently in effect, and 
not affect the remainder of this final rule. It is also our intent 
that, unless such provision shall be held to be utterly invalid or 
unenforceable, it be construed to give the provision maximum effect 
permitted by law including in the application of the provision to other 
persons not similarly situated or to other, dissimilar circumstances 
from those where the provision may be held to be invalid or 
unenforceable.

VII. Collection of Information Requirements--Qualified Health 
Information Networks\TM\

    Under the Paperwork Reduction Act of 1995 (PRA), codified as 
amended at 44 U.S.C. 3501 et seq., agencies are required to provide a 
60-day notice in the Federal Register and solicit public comment on a 
proposed collection of information before it is submitted to OMB for 
review and approval. In order to fairly evaluate whether an information 
collection should be approved by the OMB, section 3506(c)(2)(A) of the 
PRA requires that we solicit comment on the following issues:
    1. Whether the information collection is necessary and useful to 
carry out the proper functions of the agency.
    2. The accuracy of the agency's estimate of the information 
collection burden;
    3. The quality, utility, and clarity of the information to be 
collected; and
    4. Recommendations to minimize the information collection burden on 
the affected public, including automated collection techniques.
    Under the PRA, the time, effort, and financial resources necessary 
to meet

[[Page 101807]]

the information collection requirements referenced in this section are 
to be considered. We solicited comment on our assumptions as they 
relate to the PRA requirements summarized in this section.

Qualified Health Information Networks\TM\

    As stated in the HTI-2 Proposed Rule (89 FR 63661), we proposed in 
Sec.  172.301 to establish the information Applicant QHINs must submit 
in order to be Designated as a QHIN. We proposed that an Applicant QHIN 
must submit: (1) a completed QHIN application; and (2) a signed copy of 
the Common Agreement. We noted that we may update the application over 
time and the most recent version will be available on ASTP/ONC's and 
the RCE's website.
    In Sec.  172.701, we proposed attestation submission requirements 
for QHINs and review and acceptance processes that ONC would follow for 
TEFCA attestations. In Sec.  172.701(b), we proposed that in order to 
be listed in the QHIN Directory described in proposed Sec.  172.702, a 
QHIN would be required to submit to ONC an attestation affirming 
agreement with and adherence to the Trusted Exchange Framework and its 
adoption of the Common Agreement. We further proposed in Sec.  
172.701(b) that a QHIN would be required to submit to ONC identifying 
information consisting of its name, address, city, state, zip code, and 
a hyperlink to its website. We also proposed that the QHIN would be 
required to submit to ONC identifying information about its authorized 
representative including the representative's name, title, phone 
number, and email address.
    We proposed that a QHIN would also be required to provide 
documentation confirming its Designation as a QHIN. We also proposed 
that a QHIN would be required to provide ONC with written notice of any 
changes to its identifying information provided in accordance with 
Sec.  172.701 within 30 calendar days of the change(s) to its 
identifying information.
    We stated our belief that QHINs would face minimal burden in 
complying with the proposed application, attestation, and supporting 
documentation requirements. For the purposes of estimating the 
potential burden, we estimated that 15 Applicant QHINs would apply and 
subsequently submit an attestation to ONC. We stated that it would take 
approximately one hour on average for an applicant QHIN to submit a 
completed QHIN application. We also stated that it would also take 
approximately one hour on average for a QHIN to complete and submit to 
ONC their attestation and required documentation. We stated that we 
expect a general office clerk could complete these required 
responsibilities.\22\ We welcomed comments on whether more or fewer 
QHINs should be included in our estimate. We also welcomed comments on 
whether more or less time should be included in our estimate.
---------------------------------------------------------------------------

    \22\ According to the May 2022 Bureau of Labor Statistics 
occupational employment statistics, the mean hourly wage for Office 
Clerks, General (43-9061) is $19.78.

      Table 2--Estimated Annualized Total Burden Hours for QHINs To Comply With Application and Attestation
                                                  Requirements
----------------------------------------------------------------------------------------------------------------
                                                                     Number of
               Code of Federal Regulations section                applicant QHIN  Average burden       Total
                                                                     or QHINs          hours
----------------------------------------------------------------------------------------------------------------
45 CFR 172.301..................................................              15               1              15
45 CFR 172.701..................................................              15               1              15
                                                                 -----------------------------------------------
    Total Burden Hours..........................................  ..............  ..............              30
----------------------------------------------------------------------------------------------------------------

    Comments. We did not receive any comments related to information 
collection activities for QHINs.
    Response. We have finalized our regulatory collection of 
information requirements as proposed, but with unrelated revisions to 
subparts B, C, and G.

VIII. Regulatory Impact Analysis

A. Statement of Need

    This final rule is necessary to meet our statutory responsibilities 
under the Cures Act and to advance HHS policy goals to promote 
interoperability and information sharing.

B. Alternatives Considered

    We have been unable to identify alternatives that would 
appropriately implement our responsibilities under the Cures Act and 
support interoperability and information sharing consistent with our 
policy goals. We believe our policies take the necessary steps to 
fulfill the mandates specified in the PHSA, as amended by the HITECH 
Act and the Cures Act, in the least burdensome way. We welcomed 
comments on our assessment and any alternatives we should have 
considered.
    Comments. We did not receive any comments on alternatives that we 
should have considered related to the provisions included in this final 
rule.
    Response. We have finalized our assessments on the proposals 
finalized in this final rule.

C. Overall Impact--Executive Orders 12866 and 13563--Regulatory 
Planning and Review Analysis

    We have examined the impacts of this final rule as required by 
Executive Order 12866 on Regulatory Planning and Review (September 30, 
1993), Executive Order 13563 on Improving Regulation and Regulatory 
Review (January 18, 2011), Executive Order 14094, entitled 
``Modernizing Regulatory Review'' (April 6, 2023), the Regulatory 
Flexibility Act (RFA) (September 19, 1980, Pub. L. 96354), section 202 
of the Unfunded Mandates reform Act of 1995 (March 22, 1995; Pub. L. 
104-4), the Small Business Regulatory Enforcement Fairness Act of 1996 
(also known as the Congressional Review Act, 5 U.S.C. 801 et seq.), and 
the Executive Order 13132 on Federalism (August 4, 1999).
    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). The 
Executive Order 14094 amends section 3(f) of Executive Order 12866. The 
amended section 3(f) of Executive Order 12866 defines a ``significant 
regulatory action'' as an

[[Page 101808]]

action that is likely to result in a rule: (1) having an annual effect 
on the economy of $200 million or more in any 1 year (adjusted every 3 
years by the Administrator of OMB's OIRA for changes in gross domestic 
product), or adversely affect in a material way the economy, a sector 
of the economy, productivity, competition, jobs, the environment, 
public health or safety, or State, local, territorial, or tribal 
governments or communities; (2) creating a serious inconsistency or 
otherwise interfering with an action taken or planned by another 
agency; (3) materially altering the budgetary impacts of entitlement 
grants, user fees, or loan programs or the rights and obligations of 
recipients thereof; or (4) raise legal or policy issues for which 
centralized review would meaningfully further the President's 
priorities or the principles set forth in the Executive order, as 
specifically authorized in a timely manner by the Administrator of OIRA 
in each case.
    An RIA must be prepared for rules with significant regulatory 
action(s) and/or with significant effects as per section 3(f)(1) ($200 
million or more in any 1 year). OIRA has determined that this final 
rule is not a significant regulatory action under 3(f) of Executive 
Order 12866, as amended by E.O. 14094. Accordingly, we have not 
prepared a detailed RIA. We did, however, include some quantitative 
analysis of the costs and benefits of this final rule.
    Pursuant to Subtitle E of the Small Business Regulatory Enforcement 
Fairness Act of 1996 (also known as the Congressional Review Act, 5 
U.S.C. 801 et seq.), OIRA has determined that this final rule does not 
meet the criteria set forth in 5 U.S.C. 804(2).
Trusted Exchange Framework and Common Agreement\SM\
    The regulations in 45 CFR part 172 outline the application 
requirements an Applicant Qualified Health Information Network[supreg] 
(QHIN\TM\) must submit in order to be Designated as a QHIN, ongoing 
Designation requirements, and the requirements that an entity would 
attest to meeting as a QHIN under the TEFCA framework. We estimate that 
an Applicant QHIN will spend on average an hour to complete the 
application process. We estimate that an average QHIN will spend at 
most one hour to complete the attestation process. As we stated in the 
regulatory impact analysis in the HTI-2 Proposed Rule, we consider 
these efforts to be de minimis.
    We do not assess the burden of a QHIN to appeal a Recognized 
Coordinating Entity[supreg] (RCE\TM\) decision as part of their 
participation in the TEFCA framework, as this rulemaking creates the 
appeals process for QHINs but does not require it. Further, we expect 
that appeals will most often follow RCE decisions related to QHIN 
participation in the TEFCA framework, rather than ASTP/ONC decisions. 
We, therefore, do not assess the burden of the appeals process as part 
of this rulemaking's impact analysis.
    Comments. We did not receive any comments on the costs and benefits 
related to the provisions included in this final rule.
    Response. We have finalized our regulatory impact analyses on the 
matters finalized in this final rule as discussed above and in the HTI-
2 Proposed Rule.

D. Regulatory Flexibility Act

    The RFA requires agencies to analyze options for regulatory relief 
of small businesses if a rule has a significant impact on a substantial 
number of small entities. The Small Business Administration (SBA) 
establishes the size of small businesses for Federal Government 
programs based on average annual receipts or the average employment of 
a firm.\23\
---------------------------------------------------------------------------

    \23\ The SBA references that annual receipts mean ``total 
income'' (or in the case of a sole proprietorship, ``gross income'') 
plus ``cost of goods sold'' as these terms are defined and reported 
on Internal Revenue Service tax return forms.
---------------------------------------------------------------------------

    Although we did not include an analysis of the proposed TEFCA 
regulations in the HTI-2 Proposed Rule, we have included an analysis of 
the finalized TEFCA regulations in this final rule. We estimate that up 
to 15 Applicant QHINs would apply and subsequently submit an 
attestation to ASTP/ONC to be listed in the QHIN Attestation Directory. 
Section 3001(c)(9)(B)(i) of the PHSA provides the National Coordinator 
with the authority to ``develop or support a trusted exchange framework 
for trust policies and practices and for a common agreement for 
exchange between health information networks.'' The components of this 
Trusted Exchange Framework and Common Agreement\TM\ (TEFCA\TM\) include 
the Trusted Exchange Framework (a common set of principles designed to 
facilitate trust between health information networks (HINs)) and the 
Common Agreement (the agreement Qualified Health Information 
Networks[supreg] (QHINs\TM\) sign), which includes, among other 
provisions, privacy, compliance, and security requirements). The Common 
Agreement also references the QHIN Technical Framework (QTF) (which 
describes technical requirements for exchange among QHINs) as well as, 
where necessary, SOPs.
    By providing a common and consistent approach for the exchange of 
health information across many different networks, TEFCA simplifies and 
significantly reduces the number of separate networks that individuals, 
health care providers, and other interested parties need to be a part 
of in order to access the health information they seek. Health 
information networks that voluntarily join TEFCA will facilitate 
exchange in a secure and interoperable manner. TEFCA establishes a 
method for authenticating trusted health information network 
participants, potentially lowering the cost, and expanding the 
nationwide availability of secure health information exchange 
capabilities. The establishment of technical services for health 
information networks that voluntarily join TEFCA, such as an electronic 
address directory and security services, will be critical to scale 
network exchange nationwide. In addition, the organizational and 
operational policies established through TEFCA enable the exchange of 
health information among health information networks and include 
minimum conditions required for such exchange to occur. We believe our 
qualification criteria is structured in a way that it encourages 
participation from small entities.
    We believe that many health information networks impacted by this 
final rule most likely fall under the North American Industry 
Classification System (NAICS) code 541511 ``Custom Computer Programming 
Services.'' \24\ OMB advised that the Federal statistical establishment 
data published for reference years beginning on or after January 1, 
2022, should be published using the 2022 NAICS United States codes.\25\ 
The SBA size standard associated with this NAICS code is set at $34 
million annual receipts or less. There is enough data generally 
available to establish that between 75% and 90% of entities that are 
categorized under the NAICS code 541511 are under the SBA size 
standard.
---------------------------------------------------------------------------

    \24\ https://www.sba.gov/sites/sbagov/files/2023-06/Table%20of%20Size%20Standards_Effective%20March%2017%2C%202023%20%282%29.pdf.
    \25\ https://www.sba.gov/article/2022/feb/01/guidance-using-naics-2022-procurement.
---------------------------------------------------------------------------

    We estimate that this final rule would have effects on health 
information networks, some of which may be small entities. We believe, 
however, that we have adopted the minimum number of requirements 
necessary to accomplish our primary policy goal of enhancing

[[Page 101809]]

interoperability. Further, as discussed in this RIA above, there are 
very few appropriate regulatory or non-regulatory alternatives that 
could be developed to lessen the compliance burden associated with this 
final rule because the policies are derived directly from legislative 
mandates in the Cures Act.
    Comments. We received no comments on our approach.
    Response. We have finalized our approach and analysis as discussed 
above. We do not believe that this final rule would create a 
significant impact on a substantial number of small entities, and the 
Secretary certifies that this final rule would not have a significant 
impact on a substantial number of small entities.

E. Executive Order 13132--Federalism

    Executive Order 13132 establishes certain requirements that an 
agency must meet when it promulgates a rule that imposes substantial 
direct requirement costs on state and local governments, preempts state 
law, or otherwise has federalism implications.
    Comments We received no comments.
    Response. Nothing in this final rule imposes substantial direct 
compliance costs on state and local governments, preempts state law, or 
otherwise has federalism implications.

F. Unfunded Mandates Reform Act of 1995

    Section 202 of the Unfunded Mandates Reform Act of 1995 requires 
that agencies assess anticipated costs and benefits before issuing any 
rule that imposes unfunded mandates on state, local, and tribal 
governments or the private sector requiring spending in any one year of 
$100 million in 1995 dollars, updated annually for inflation. The 
current inflation-adjusted statutory threshold is approximately $183 
million in 2024.
    Comments. We received no comments on the application of this law to 
our proposals finalized in this final rule.
    Response. The estimated potential cost effects of this final rule 
do not reach the statutory threshold; therefore, this final rule does 
not impose unfunded mandates on state, local, and tribal governments, 
or the private sector.

List of Subjects

45 CFR Part 170

    Computer technology, Electronic health record, Electronic 
information system, Electronic transactions, Health, Healthcare, Health 
information technology, Health insurance, Health records, Hospitals, 
Laboratories, Medicaid, Medicare, Privacy, Public health, Reporting and 
recordkeeping requirements, Security.

45 CFR Part 171

    Computer technology, Electronic health record, Electronic 
information system, Electronic transactions, Health, Healthcare, Health 
care provider, Health information exchange, Health information 
technology, Health information network, Health insurance, Health 
records, Hospitals, Privacy, Public health, Reporting and recordkeeping 
requirements, Security.

45 CFR Part 172

    Computer technology, Electronic health record, Electronic 
information system, Electronic transactions, Health, Healthcare, Health 
information technology, Health insurance, Health records, Hospitals, 
Laboratories, Medicaid, Medicare, Privacy, Public health, Security.

    For the reasons set forth in the preamble, 45 CFR subtitle A, 
subchapter D, is amended as follows:

PART 170--HEALTH INFORMATION TECHNOLOGY STANDARDS, IMPLEMENTATION 
SPECIFICATIONS, AND CERTIFICATION CRITERIA AND CERTIFICATION 
PROGRAMS FOR HEALTH INFORMATION TECHNOLOGY

0
1. The authority citation for part 170 continues to read as follows:

    Authority:  42 U.S.C. 300jj-11; 42 U.S.C 300jj-14; 5 U.S.C. 552.


0
2. Revise Sec.  170.101 to read as follows:


Sec.  170.101   Applicability.

    (a) The standards, implementation specifications, and certification 
criteria adopted in this part apply to health information technology 
and the testing and certification of Health IT Modules.
    (b) If any provision of this part is held to be invalid or 
unenforceable facially, or as applied to any person, plaintiff, or 
circumstance, it shall be construed to give maximum effect to the 
provision permitted by law, unless such holding shall be one of utter 
invalidity or unenforceability, in which case the provision shall be 
severable from this part and shall not affect the remainder thereof or 
the application of the provision to other persons not similarly 
situated or to other dissimilar circumstances.

0
3. Amend Sec.  170.315 by:
0
a. Removing and reserving paragraphs (a)(10) and (13) and (b)(6);
0
b. Revising paragraphs (b)(7) and (8); and
0
c. Removing and reserving paragraphs (e)(2) and (g)(2).
    The revisions read as follows:


Sec.  170.315   ONC certification criteria for Health IT.

* * * * *
    (b) * * *
    (7) Security tags--summary of care--send. Enable a user to create a 
summary record formatted in accordance with the standard adopted in 
Sec.  170.205(a)(4) that is tagged as restricted and subject to 
restrictions on re-disclosure according to the standard adopted in 
Sec.  170.205(o)(1) at the document, section, and entry (data element) 
level.
    (8) Security tags--summary of care--receive. (i) Enable a user to 
receive a summary record that is formatted in accordance with the 
standard adopted in Sec.  170.205(a)(4) that is tagged as restricted 
and subject to restrictions on re-disclosure according to the standard 
adopted in Sec.  170.205(o)(1) at the document, section, and entry 
(data element) level; and
    (ii) Preserve privacy markings to ensure fidelity to the tagging 
based on consent and with respect to sharing and re-disclosure 
restrictions.
* * * * *

0
4. Amend Sec.  170.502 by revising the definition of ``Gap 
certification'' to read as follows:


Sec.  170.502   Definitions.

* * * * *
    Gap certification means the certification of a previously certified 
Health IT Module(s) to:
    (1) All applicable new and/or revised certification criteria 
adopted by the Secretary at subpart C of this part based on test 
results issued by a NVLAP-accredited testing laboratory under the ONC 
Health IT Certification Program or an ONC-ATL; and
    (2) All other applicable certification criteria adopted by the 
Secretary at subpart C of this part based on the test results used to 
previously certify the Health IT Module(s) under the ONC Health IT 
Certification Program.
* * * * *

0
5. Revise Sec.  170.511 to read as follows:


Sec.  170.511   Authorization scope for ONC-ATL status.

    Applicants may seek authorization from the National Coordinator to 
perform the testing of Health IT Modules to a portion of a 
certification criterion, one certification criterion, or many or all 
certification criteria adopted by the Secretary under subpart C of this 
part.

0
6. Amend Sec.  170.523 by revising paragraphs (f) introductory text and 
(j)(3) to read as follows:

[[Page 101810]]

Sec.  170.523   Principles of proper conduct for ONC-ACBs.

* * * * *
    (f) Certified product listing. Provide the Assistant Secretary for 
Technology Policy/Office of the National Coordinator for Health 
Information Technology (ASTP/ONC), no less frequently than weekly, a 
current list of Health IT Modules that have been certified that 
includes, at a minimum:
* * * * *
    (j) * * *
    (3) Previous certifications that it performed if its conduct 
necessitates the recertification of Health IT Module(s).
* * * * *

0
7. Amend Sec.  170.550 by revising paragraph (h)(3)(ii) and adding 
paragraph (h)(4) to read as follows:


Sec.  170.550   Health IT Module certification.

* * * * *
    (h) * * *
    (3) * * *
    (ii) Section 170.315(a)(4), (10), and (13) and, on and after 
January 1, 2028, (b)(11), are also certified to the certification 
criteria specified in Sec.  170.315(d)(1) through (3), (5) through (7), 
and (12), and, for the time period up to and including December 31, 
2027, (d)(13).
* * * * *
    (4) Methods to demonstrate compliance with each privacy and 
security criterion. One of the following methods must be used to meet 
each applicable privacy and security criterion listed in paragraph 
(h)(3) of this section:
    (i) Directly, by demonstrating a technical capability to satisfy 
the applicable certification criterion or certification criteria; or
    (ii) Demonstrate, through system documentation sufficiently 
detailed to enable integration, that the Health IT Module has 
implemented service interfaces for each applicable privacy and security 
certification criterion that enable the Health IT Module to access 
external services necessary to meet the privacy and security 
certification criterion.
* * * * *

PART 171--INFORMATION BLOCKING

0
8. The authority citation for part 171 continues to read as follows:

    Authority: 42 U.S.C. 300jj-52; 5 U.S.C. 552.


0
9. Amend Sec.  171.101 by adding paragraph (c) to read as follows:


Sec.  171.101   Applicability.

* * * * *
    (c) If any provision of this part is held to be invalid or 
unenforceable facially, or as applied to any person, plaintiff, or 
circumstance, it shall be construed to give maximum effect to the 
provision permitted by law, unless such holding shall be one of utter 
invalidity or unenforceability, in which case the provision shall be 
severable from this part and shall not affect the remainder thereof or 
the application of the provision to other persons not similarly 
situated or to other dissimilar circumstances.

0
10. Add Sec.  171.401 to read as follows:


Sec.  171.401   Definitions.

    Common Agreement has the meaning given to it in 45 CFR 172.102.
    Framework Agreement has the meaning given to it in 45 CFR 172.102.
    Participant has the meaning given to it in 45 CFR 172.102.
    Qualified Health Information Network or QHIN has the meaning given 
to it in 45 CFR 172.102.
    Subparticipant has the meaning given to it in 45 CFR 172.102.

0
11. Add part 172 to read as follows:

PART 172--TRUSTED EXCHANGE FRAMEWORK AND COMMON AGREEMENT

Subpart A--General Provisions
Sec.
172.100 Basis, purpose, and scope.
172.101 Applicability.
172.102 Definitions.
172.103 Responsibilities ASTP/ONC may delegate to the RCE.
Subpart B--Qualifications for Designation
172.200 Applicability.
172.201 QHIN Designation requirements.
172.202 QHINS that offer Individual Access Services.
Subpart C--QHIN Onboarding and Designation Processes
172.300 Applicability.
172.301 Submission of QHIN application.
172.302 Review of QHIN application.
172.303 QHIN approval and Onboarding.
172.304 QHIN Designation.
172.305 Withdrawal of QHIN application.
172.306 Denial of QHIN application.
172.307 Re-application.
Subpart D--Suspension
172.400 Applicability.
172.401 QHIN suspensions.
172.402 Selective suspension of exchange between QHINs.
Subpart E--Termination
172.500 Applicability.
172.501 QHIN self-termination.
172.502 QHIN termination.
172.503 Termination by mutual agreement.
Subpart F--Review of RCE or ASTP/ONC Decisions
172.600 Applicability.
172.601 ASTP/ONC review.
172.602 Basis for appeal by QHIN or Applicant QHIN.
172.603 Method and timing for filing an appeal.
172.604 Effect of appeal on suspension and termination.
172.605 Assignment of a hearing officer.
172.606 Adjudication.
172.607 Determination by the hearing officer.
Subpart G--QHIN Attestation for the Adoption of the Trusted Exchange 
Framework and Common Agreement
172.700 Applicability.
172.701 Attestation submission and acceptance.
172.702 QHIN Attestation Directory.

    Authority: 42 U.S.C. 300jj-11; 5 U.S.C. 552.

Subpart A--General Provisions


Sec.  172.100   Basis, purpose, and scope.

    (a) Basis and authority. The provisions of this part implement 
section 3001(c)(9) of the Public Health Service Act.
    (b) Purpose. The purpose of this part is to:
    (1) Ensure full network-to-network exchange of health information; 
and
    (2) Establish a voluntary process for a Qualified Health 
Information Network\TM\ (QHIN\TM\) to attest to adoption of the Trusted 
Exchange Framework and Common Agreement\TM\ (TEFCA\TM\).
    (c) Scope. This part addresses:
    (1) Minimum qualifications needed for a health information network 
to be Designated as a QHIN capable of trusted exchange under TEFCA.
    (2) Procedures governing QHIN Onboarding and Designation, 
suspension, termination, and further administrative review.
    (3) Attestation submission requirements for a QHIN to attest to its 
adoption of TEFCA.
    (4) ASTP/ONC attestation acceptance and removal processes for 
publication of attesting QHINs in the QHIN Attestation Directory.


Sec.  172.101   Applicability.

    (a) This part applies to Applicant QHINS, QHINs, terminated QHINs, 
and the Recognized Coordinating Entity.
    (b) If any provision of this part is held to be invalid or 
unenforceable facially, or as applied to any person, plaintiff, or 
circumstance, it shall be construed to give maximum effect to the 
provision permitted by law, unless such holding shall be one of utter 
invalidity or unenforceability, in which case the provision shall be 
severable from this part and shall not affect the remainder thereof or 
the application of the provision to other persons not similarly

[[Page 101811]]

situated or to other dissimilar circumstances.


Sec.  172.102   Definitions.

    For purposes of this part, the following definitions apply:
    Applicable Law. All Federal, State, local, or Tribal laws and 
regulations then in effect and applicable to the subject matter in this 
part. For the avoidance of doubt, Federal agencies are subject only to 
Federal law.
    Applicant QHIN. Any organization with a pending QHIN application 
before the Assistant Secretary for Technology Policy/Office of the 
National Coordinator for Health Information Technology (ASTP/ONC).
    Business Associate Agreement (BAA). A contract, agreement, or other 
arrangement that satisfies the implementation specifications described 
within 45 CFR parts 160 and subparts A, C, and E of 45 CFR part 164, as 
applicable.
    Business day or business days. Monday through Friday, except the 
legal public holidays specified in 5 U.S.C. 6103 and any day declared 
to be a holiday by Federal statute or Executive order.
    Common Agreement. The most recent version of the agreement 
referenced in section 3001(c)(9) of the Public Service Health Act as 
published in the Federal Register.
    Confidential Information. Any information that is designated as 
Confidential Information by the person or entity that discloses it, or 
that a reasonable person would understand to be of a confidential 
nature and is disclosed to another person or entity pursuant to TEFCA 
Exchange. For the avoidance of doubt, ``Confidential Information'' does 
not include electronic protected health information (ePHI). 
Notwithstanding any label to the contrary, ``Confidential Information'' 
does not include any information that:
    (1) Is or becomes known publicly through no fault of the recipient; 
or
    (2) Is learned by the recipient from a third party that the 
recipient reasonably believes is entitled to disclose it without 
restriction; or
    (3) Is already known to the recipient before receipt from the 
discloser, as shown by the recipient's written records; or
    (4) Is independently developed by recipient without the use of or 
reference to the discloser's Confidential Information, as shown by the 
recipient's written records, and was not subject to confidentiality 
restrictions prior to receipt of such information from the discloser; 
or
    (5) Must be disclosed under operation of law, provided that, to the 
extent permitted by Applicable Law, the recipient gives the discloser 
reasonable notice to allow the discloser to object to such 
redisclosure, and such redisclosure is made to the minimum extent 
necessary to comply with Applicable Law.
    Connectivity Services. The technical services provided by a QHIN, 
Participant, or Subparticipant to its Participants and Subparticipants 
that facilitate TEFCA Exchange and are consistent with the technical 
requirements of the TEFCA framework.
    Covered Entity. Has the meaning assigned to such term at 45 CFR 
160.103.
    Designated Network. The health information network that a QHIN uses 
to offer and provide Designated Network Services.
    Designated Network Services. The Connectivity Services and/or 
Governance Services.
    Designation (including its correlative meanings ``Designate,'' 
``Designated,'' and ``Designating''). The written determination that an 
Applicant QHIN has satisfied all requirements and is now a QHIN.
    Disclosure (including its correlative meanings ``Disclose,'' 
``Disclosed,'' and ``Disclosing''). The release, transfer, provision of 
access to, or divulging in any manner of TEFCA Information (TI) outside 
the entity holding the information.
    Electronic Protected Health Information (ePHI). Has the meaning 
assigned to such term at 45 CFR 160.103.
    Exchange Purpose(s) or XP(s). The reason, as authorized by a 
Framework Agreement, including the applicable standard operating 
procedure(s) (SOP(s)), for a transmission, Query, Use, Disclosure, or 
Response transacted through TEFCA Exchange.
    Exchange Purpose Code or XP Code. A code that identifies the 
Exchange Purpose being used for TEFCA Exchange.
    Foreign Control. A non-U.S. Person(s) or non-U.S. Entity(ies) 
having the direct or indirect power, whether or not exercised, to 
direct or decide matters materially affecting the Applicant's ability 
to function as a QHIN in a manner that presents a national security 
risk.
    Framework Agreement(s). With respect to QHINs, the Common 
Agreement; and with respect to a Participant or Subparticipant, the 
Participant/Subparticipant Terms of Participation (ToP).
    Governance Services. The governance functions described in 
applicable SOP(s), which are performed by a QHIN's Designated Network 
Governance Body for its Participants and Subparticipants to facilitate 
TEFCA Exchange in compliance with the then-applicable requirements of 
the Framework Agreements.
    Health information network or HIN. The meaning assigned to it in 45 
CFR 171.102.
    Individual has the meaning assigned to such term at 45 CFR 
171.202(a)(2).
    HIPAA. The Health Insurance Portability and Accountability Act of 
1996.
    HIPAA Privacy Rule. The regulations set forth in 45 CFR part 160 
and subparts A and E of 45 CFR part 164.
    HIPAA Rules. The regulations set forth at 45 CFR parts 160, 162, 
and 164.
    HIPAA Security Rule. The regulations set forth in 45 CFR part 160 
and subparts A and C of 45 CFR part 164.
    Individual. Has the meaning assigned to such term at 45 CFR 
171.202(a)(2).
    Individual Access Services (IAS). The services provided to an 
Individual by a QHIN, Participant, or Subparticipant that has a direct 
contractual relationship with such Individual in which the QHIN, 
Participant or Subparticipant, as applicable, agrees to satisfy that 
Individual's ability to access, inspect, or obtain a copy of that 
Individual's Required Information using TEFCA Exchange.
    Individually Identifiable Information. Refers to information that 
identifies an Individual or with respect to which there is a reasonable 
basis to believe that the information could be used to identify an 
Individual.
    Node. A technical system that is controlled directly or indirectly 
by a QHIN, Participant, or Subparticipant and that is listed in the RCE 
Directory Service.
    Non-U.S. Entity. Any entity that is not a U.S. Entity.
    Non-U.S. Person. Any Individual who is not a U.S. Qualified Person.
    Onboarding. The process a prospective QHIN must undergo to become a 
QHIN and become operational in the production environment.
    Organized Health Care Arrangement. Has the meaning assigned to such 
term at 45 CFR 160.103.
    Participant. A U.S. Entity that has entered into the Participant/
Subparticipant Terms of Participation in a legally binding contract 
with a QHIN to use the QHIN's Designated Network Services to 
participate in TEFCA Exchange in compliance with the Participant/
Subparticipant Terms of Participation.

[[Page 101812]]

    Participant/Subparticipant Terms of Participation (ToP). The 
requirements to which QHINs must contractually obligate their 
Participants to agree; to which QHINs must contractually obligate their 
Participants to contractually obligate their Subparticipants and 
Subparticipants of the Subparticipants to agree, in order to 
participate in TEFCA Exchange including the QHIN Technical Framework 
(QTF), all applicable SOPs, and all other attachments, exhibits, and 
artifacts incorporated therein by reference.
    Qualified Health Information Network[supreg] or QHIN\TM\. A Health 
Information Network that has been so Designated.
    Query(s) (including its correlative uses/tenses ``Queried'' and 
``Querying''). The act of asking for information through TEFCA 
Exchange.
    Recognized Coordinating Entity[supreg] (RCE[supreg]). The entity 
selected by ASTP/ONC that enters into the Common Agreement with QHINs 
in order to impose, at a minimum, the requirements of the Common 
Agreement, including the SOPs and the QTF, on the QHINs and administer 
such requirements on an ongoing basis. The RCE is a Party to the Common 
Agreement.
    Required Information. The Electronic Health Information, as defined 
in 45 CFR 171.102, that is:
    (1) Maintained in a Responding Node by any QHIN, Participant, or 
Subparticipant prior to or during the term of the applicable Framework 
Agreement; and
    (2) Relevant for a required XP Code.
    Responding Node. A Node through which the QHIN, Participant, or 
Subparticipant Responds to a received transaction for TEFCA Exchange.
    Response(s) (including its correlative uses/tenses ``Responds,'' 
``Responded'' and ``Responding''). The act of providing the information 
that is the subject of a Query or otherwise transmitting a message in 
response to a Query through TEFCA Exchange.
    Subparticipant: a U.S. Entity that has entered into the 
Participant/Subparticipant Terms of Participation in a legally binding 
contract with a Participant or another Subparticipant to use the 
Participant's or Subparticipant's Connectivity Services to participate 
in TEFCA Exchange in compliance with the Participant/Subparticipant 
Terms of Participation.
    TEFCA Dispute Resolution Process. An informal, non-binding process 
under TEFCA through which QHINs can meet, confer, and seek to amicably 
resolve disputes.
    TEFCA Exchange. The transaction of information between Nodes using 
an XP Code.
    TEFCA Information or TI. Any information that is transacted through 
TEFCA Exchange except to the extent that such information is received 
by a QHIN, Participant, or Subparticipant that is a Covered Entity, 
Business Associate, or non-HIPAA entity that is exempt from compliance 
with the Privacy section of the applicable Framework Agreement and is 
incorporated into such recipient's system of record, at which point the 
information is no longer TEFCA Information with respect to such 
recipient and is governed by the HIPAA Rules and other Applicable Law.
    TEFCA Security Incident. (1) An unauthorized acquisition, access, 
Disclosure, or Use of unencrypted TEFCA Information using TEFCA 
Exchange, except any of the following:
    (i) Any unintentional acquisition, access, Use, or Disclosure of 
TEFCA Information by a Workforce Member or person acting under the 
authority of a QHIN, Participant, or Subparticipant, if such 
acquisition, access, Use, or Disclosure:
    (A) Was made in good faith;
    (B) Was made by a person acting within their scope of authority;
    (C) Was made to another Workforce Member or person acting under the 
authority of any QHIN, Participant, or Subparticipant; and
    (D) Does not result in further acquisition, access, Use, or 
Disclosure in a manner not permitted under Applicable Law and the 
Framework Agreements.
    (ii) A Disclosure of TI where a QHIN, Participant, or 
Subparticipant has a good faith belief that an unauthorized person to 
whom the Disclosure was made would not reasonably have been able to 
retain such information.
    (iii) A Disclosure of TI that has been de-identified in accordance 
with the standard at 45 CFR 164.514.
    (2) Other security events that adversely affect a QHIN's, 
Participant's, or Subparticipant's participation in TEFCA Exchange.
    Threat Condition. (1) A breach of a material provision of a 
Framework Agreement that has not been cured within fifteen (15) 
calendar days of receiving notice of the material breach (or such other 
period of time to which the Parties have agreed), which notice shall 
include such specific information about the breach that the RCE has 
available at the time of the notice; or
    (2) A TEFCA Security Incident; or
    (3) An event that the RCE, a QHIN, its Participant, or their 
Subparticipant has reason to believe will disrupt normal TEFCA 
Exchange, either due to actual compromise of, or the need to mitigate 
demonstrated vulnerabilities in systems or data, of the QHIN, 
Participant, or Subparticipant, as applicable, or could be replicated 
in the systems, networks, applications, or data of another QHIN, 
Participant, or Subparticipant; or
    (4) Any event that could pose a risk to the interests of national 
security as directed by an agency of the United States government.
    Trusted Exchange Framework. The most recent version of the 
framework referenced in section 3001(c)(9) of the Public Service Health 
Act published in the Federal Register.
    U.S. Entity/Entities. Any corporation, limited liability company, 
partnership, or other legal entity that meets all of the following 
requirements:
    (1) The entity is organized under the laws of a state or 
commonwealth of the United States or the Federal law of the United 
States and is subject to the jurisdiction of the United States and the 
state or commonwealth under which it was formed;
    (2) The entity's principal place of business, as determined under 
Federal common law, is in the United States; and
    (3) None of the entity's directors, officers, or executives, and 
none of the owners with a five percent (5%) or greater interest in the 
entity, are listed on the Specially Designated Nationals and Blocked 
Persons List published by the United States Department of the 
Treasury's Office of Foreign Asset Control or on the United States 
Department of Health and Human Services, Office of Inspector General's 
List of Excluded Individuals/Entities.
    U.S. Qualified Person. Those individuals who are U.S. nationals and 
citizens at birth as defined in 8 U.S.C. 1401, U.S. nationals but not 
citizens of the United States at birth as defined in 8 U.S.C. 1408, 
lawful permanent residents of the United States as defined in 
Immigration and Nationality Act, and non-immigrant aliens who are hired 
by a U.S. Entity as an employee in a specialty occupation pursuant to 
an H-1B Visa.
    Use(s) (including correlative uses/tenses, such as ``Uses,'' 
``Used,'' and ``Using''). With respect to TI, means the sharing, 
employment, application, utilization, examination, or analysis of such 
information within an entity that maintains such information.


Sec.  172.103   Responsibilities ASTP/ONC may delegate to the RCE.

    (a) ASTP/ONC may delegate to the RCE the TEFCA implementation

[[Page 101813]]

responsibilities specified in the following sections:
    (1) Any section(s) of subpart C of this part;
    (2) Any section(s) of subpart D of this part;
    (3) Section 172.501; and
    (4) Section 172.503.
    (b) Notwithstanding any delegation, any authority exercised by the 
RCE under this section is subject to review under subpart F of this 
part and to any requirement in this part that the RCE receive ASTP/
ONC's prior authorization before taking a specific action.

Subpart B--Qualifications for Designation


Sec.  172.200   Applicability.

    This subpart establishes Designation qualifications.
    (a) Applicant QHIN. An Applicant QHIN must meet all requirements in 
Sec.  172.201 to be Designated. An Applicant QHIN that proposes to 
offer Individual Access Services must also meet all requirements in 
Sec.  172.202 to be Designated.
    (b) QHIN. A QHIN must continue to meet all requirements in Sec.  
172.201 to maintain its Designation. A QHIN that offers Individual 
Access Services must also continue to meet all requirements in Sec.  
172.202 to maintain its Designation.
    (c) Performance of TEFCA Exchange. The Designation qualifications 
in Sec. Sec.  172.201 and 172.202 describe certain requirements for 
Designation.


Sec.  172.201  QHIN Designation requirements.

    (a) Ownership requirements. An entity must:
    (1) Be a U.S. Entity;
    (2) Not be under Foreign Control.
    (b) Exchange requirements. An entity must, beginning at the time of 
application, either directly or through the experience of its parent 
entity:
    (1) Be capable of exchanging information among more than two 
unaffiliated organizations;
    (2) Be capable of exchanging all Required Information;
    (3) Be exchanging information for at least one Exchange Purpose 
authorized under TEFCA;
    (4) Be capable of receiving and responding to transactions from 
other QHINs for all Exchange Purposes authorized under TEFCA; and
    (5) Be capable of initiating transactions for the Exchange Purposes 
authorized under TEFCA that such entity will permit its Participants 
and Subparticipants to use through TEFCA Exchange.
    (c) Designated Network Services requirements. An entity must:
    (1) Maintain the organizational infrastructure and legal authority 
to operate and govern its Designated Network;
    (2) Maintain adequate written policies and procedures to support 
meaningful TEFCA Exchange and fulfill all responsibilities of a QHIN in 
this part;
    (3) Maintain a Designated Network that can support a transaction 
volume that keeps pace with the demands of network users;
    (4) Maintain the capacity to support secure technical connectivity 
and data exchange with other QHINs;
    (5) Maintain an enforceable dispute resolution policy governing 
Participants in the Designated Network that permits Participants to 
reasonably, timely, and fairly adjudicate disputes that arise between 
each other, the QHIN, or other QHINs;
    (6) Maintain an enforceable change management policy consistent 
with the responsibilities of a QHIN;
    (7) Maintain a representative and participatory group or groups 
with the authority to approve processes for governing the Designated 
Network;
    (8) Maintain privacy and security policies that permit the entity 
to support TEFCA Exchange;
    (9) Maintain data breach response and management policies that 
support meaningful TEFCA Exchange; and
    (10) Maintain adequate financial and personnel resources to support 
all its responsibilities as a QHIN, including sufficient financial 
reserves or insurance-based cybersecurity coverage, or a combination of 
both.


Sec.  172.202   QHINs that offer Individual Access Services.

    The following requirements apply to QHINs that offer Individual 
Access Services:
    (a) A QHIN must obtain express consent from any individual before 
providing Individual Access Services.
    (b) A QHIN must make publicly available a privacy and security 
notice that meets minimum TEFCA standards.
    (c) A QHIN, that is the IAS provider for an Individual, must delete 
the individual's Individually Identifiable Information maintained by 
the QHIN upon request by the individual except as prohibited by 
Applicable Law or where such information is contained in audit logs.
    (d) A QHIN must permit any Individual to export in a computable 
format all of the Individual's Individually Identifiable Information 
maintained by the QHIN as an Individual Access Services provider.
    (e) All Individually Identifiable Information the QHIN maintains 
must satisfy the following criteria:
    (1) All Individually Identifiable Information must be encrypted.
    (2) Without unreasonable delay and in no case later than sixty (60) 
calendar days following discovery of the unauthorized acquisition, 
access, Disclosure, or Use of Individually Identifiable Information, 
the QHIN must notify in plain language each Individual whose 
Individually Identifiable Information has been or is reasonably 
believed to have been affected by unauthorized acquisition, access, 
Disclosure, or Use involving the QHIN.
    (3) A QHIN must have an agreement with a qualified, independent 
third-party credential service provider and must verify, through the 
credential service provider, the identities of Individuals seeking 
Individual Access Services prior to the Individuals' first use of such 
services and upon expiration of their credentials.

Subpart C--QHIN Onboarding and Designation Processes


Sec.  172.300   Applicability.

    This subpart establishes, as to QHINs, the application, review, 
Onboarding, withdrawal, and redetermination processes for Designation.


Sec.  172.301   Submission of QHIN application.

    An entity seeking to be Designated as a QHIN must submit all of the 
following information in a manner specified by ASTP/ONC:
    (a) Completed QHIN application, with supporting documentation, in a 
form specified by ASTP/ONC; and
    (b) A signed copy of the Common Agreement.


Sec.  172.302   Review of QHIN application.

    (a) ASTP/ONC (or an RCE) will review a QHIN application to 
determine if the Applicant QHIN has completed all parts of the 
application and provided the necessary supporting documentation. If the 
QHIN application is not complete, the applicant will be notified in 
writing of the missing information within thirty (30) calendar days of 
receipt of the application. This timeframe may be extended by providing 
written notice to the Applicant QHIN.
    (b) Once the QHIN application is complete, ASTP/ONC (or an RCE) 
will review the application to determine whether the Applicant QHIN 
satisfies the requirements for Designation set forth in Sec.  172.201 
and, if the Applicant QHIN proposes to provide IAS, the requirements 
set forth in Sec.  172.202. ASTP/ONC (or an RCE) will complete its 
review within sixty (60) calendar days of the Applicant QHIN being

[[Page 101814]]

provided with written notice that its application is complete. This 
timeframe may be extended by providing written notice to the Applicant 
QHIN.
    (c) Additional information may be requested from the Applicant QHIN 
while ASTP/ONC (or an RCE) is reviewing the application. The timeframe 
for responding to the request and the manner to submit additional 
information will be provided to the applicant and may be extended on 
written notice to the Applicant QHIN.
    (d) Failure to respond to a request within the proposed timeframe 
or in the manner specified is a basis for a QHIN Application to be 
deemed withdrawn, as set forth in Sec.  172.305(c). In such situations, 
the Applicant QHIN will be provided with written notice that the 
application has been deemed withdrawn.
    (e) If, following submission of the application, any information 
submitted by the Applicant QHIN becomes untrue or materially changes, 
the Applicant QHIN must notify ASTP/ONC (or an RCE) in the manner 
specified by ASTP/ONC (or an RCE) of such changes in writing within 
five (5) business days of the submitted material becoming untrue or 
materially changing.


Sec.  172.303   QHIN approval and Onboarding.

    (a) An Applicant QHIN has the burden of demonstrating its 
compliance with all qualifications for Designation in Sec.  172.201 
and, if the Applicant QHIN proposes to provide IAS, the qualifications 
in Sec.  172.202.
    (b) If ASTP/ONC (or, with ASTP/ONC's prior authorization, an RCE) 
determines that an Applicant QHIN meets the requirements for 
Designation set forth in Sec.  172.201, and if the Applicant QHIN 
proposes to provide IAS, the qualifications set forth in Sec.  172.202, 
then ASTP/ONC (or, with ASTP/ONC's prior authorization, an RCE) will 
notify the applicant in writing that its application has been approved, 
and the Applicant QHIN may proceed with Onboarding.
    (c) An approved Applicant QHIN must submit a signed version of the 
Common Agreement within a timeframe set by ASTP/ONC (or an RCE).
    (d) An approved Applicant QHIN must complete the Onboarding 
process, including any tests required to ensure the Applicant QHIN's 
network can connect to those of other QHINs and other Applicant QHINs, 
within twelve (12) months of approval of its QHIN application, unless 
that timeframe is extended in ASTP/ONC's (or an RCE's) sole discretion 
by up to twelve (12) months.


Sec.  172.304   QHIN Designation.

    (a) If all requirements of the Onboarding process specified in 
Sec.  172.303 have been satisfied:
    (1) The Common Agreement will be countersigned; and
    (2) The Applicant QHIN will be provided with a written 
determination indicating that the applicant has been Designated as a 
QHIN, along with a copy of the countersigned Common Agreement.
    (b) Within thirty (30) calendar days of receiving its Designation, 
each QHIN must demonstrate in a manner specified by ASTP/ONC (or, with 
ASTP/ONC's prior authorization, an RCE) that it has completed a 
successful transaction with all other in-production QHINs according to 
standards and procedures for TEFCA Exchange.
    (c) If a QHIN is unable to complete the requirement in paragraph 
(b) of this section within the thirty (30)-day period provided, the 
QHIN must provide ASTP/ONC (or an RCE) with a written explanation of 
why the QHIN has been unable to complete a successful transaction with 
all other in-production QHINs within the allotted time and include a 
detailed plan and timeline for completion of a successful transaction 
with all other in-production QHINs. ASTP/ONC (or, with ASTP/ONC's prior 
authorization, an RCE) will review and either approve or reject the 
QHIN's plan based on the reasonableness of the explanation and the 
specific facts and circumstances, within five (5) business days of 
receipt. If the QHIN fails to provide its plan or the plan is rejected, 
ASTP/ONC (or, with ASTP/ONC's prior authorization, an RCE) will rescind 
its approval of the application, rescind the QHIN Designation, and deny 
the application. Within thirty (30) calendar days of end of the term of 
the plan, each QHIN must demonstrate in a manner specified by ASTP/ONC 
(or, with ASTP/ONC's prior authorization, an RCE) that it has completed 
a successful transaction with all other in-production QHINs according 
to standards and procedures for TEFCA Exchange.
    (d) A QHIN Designation will become final sixty (60) days after a 
Designated QHIN has submitted its documentation that it has completed a 
successful transaction with all other in-production QHINs.


Sec.  172.305   Withdrawal of QHIN application.

    (a) An Applicant QHIN may voluntarily withdraw its QHIN application 
by providing written notice in a manner specified by ASTP/ONC (or an 
RCE).
    (b) An Applicant QHIN may withdraw its QHIN application at any 
point prior to Designation.
    (c) Upon written notice to the Applicant QHIN, a QHIN application 
may be deemed withdrawn by ASTP/ONC (or, with ASTP/ONC's prior 
authorization, an RCE) as a result of the Applicant QHIN's failure to 
respond to requests for information from ASTP/ONC (or an RCE).


Sec.  172.306   Denial of QHIN application.

    If an Applicant QHIN's application is denied, the Applicant QHIN 
will be provided with written notice that includes the basis for the 
denial.


Sec.  172.307   Re-application.

    (a) Subject to paragraphs (b) through (d) of this section, 
applications may be resubmitted by Applicant QHINs by complying with 
the provisions of Sec.  172.301 in the event that an application is 
denied or withdrawn.
    (b) The Applicant QHIN may reapply at any time after it has 
voluntarily withdrawn its application as specified in Sec.  172.305(a).
    (c) If ASTP/ONC (or an RCE) deems a QHIN application to be 
withdrawn as a result of the Applicant QHIN's failure to respond to 
requests for information, then the Applicant QHIN may reapply by 
submitting a new QHIN application no sooner than six (6) months after 
the date on which its previous application was submitted. The Applicant 
QHIN must respond to the prior request for information and must include 
an explanation as to why no response was previously provided within the 
required timeframe.
    (d) If ASTP/ONC (or an RCE) denies a QHIN application, the 
Applicant QHIN may reapply by submitting a new application consistent 
with the requirements in Sec.  172.301 no sooner than six (6) months 
after the date shown on the written notice of denial. The application 
must specifically address the deficiencies that constituted the basis 
for denying the Applicant QHIN's previous application.

Subpart D--Suspension


Sec.  172.400   Applicability.

    This subpart describes suspension responsibilities, notice 
requirements for suspension, and the effect of suspension.


Sec.  172.401   QHIN suspensions.

    (a) ASTP/ONC (or, with ASTP/ONC's prior authorization, an RCE) may 
suspend a QHIN after determining that the QHIN is responsible for a 
Threat Condition.

[[Page 101815]]

    (b) ASTP/ONC (or, with ASTP/ONC's prior authorization, an RCE) may 
direct the QHIN to suspend that Participant's or Subparticipant's 
authority to engage in TEFCA Exchange on determining that one of a 
QHIN's Participants or Subparticipants has done something or failed to 
do something that resulted in a Threat Condition.
    (c) ASTP/ONC (or an RCE) will make a reasonable effort to notify a 
QHIN in writing in advance of an intent to suspend the QHIN or to 
provide direction to the QHIN to suspend one of the QHIN's Participants 
or Subparticipants, and to give the QHIN an opportunity to respond. 
Such notice will identify the Threat Condition giving rise to such 
suspension.
    (d) ASTP/ONC (or, with ASTP/ONC's prior authorization, an RCE) 
shall lift a suspension of the QHIN, or provide direction to the QHIN 
to lift the suspension of one of the QHIN's Participants or 
Subparticipants, once the Threat Condition is resolved.


Sec.  172.402   Selective suspension of exchange between QHINs.

    (a) A QHIN may, in good faith and to the extent permitted by 
Applicable Law, suspend TEFCA Exchange with another QHIN because of 
reasonable concerns related to the privacy and security of information 
that is exchanged.
    (b) If a QHIN decides to suspend TEFCA Exchange with another QHIN, 
it is required to promptly notify, in writing, ASTP/ONC (or an RCE) and 
the QHIN with which it is suspending exchange of its decision and the 
reason(s) for making the decision.
    (c) If a QHIN suspends TEFCA Exchange with another QHIN under 
paragraph (a) of this section, it must, within thirty (30) calendar 
days, initiate the TEFCA Dispute Resolution Process in order to resolve 
the issues that led to the decision to suspend, or the QHIN may end its 
suspension and resume TEFCA Exchange with the other QHIN within thirty 
(30) calendar days of suspending TEFCA Exchange with the QHIN.
    (d) Provided that a QHIN suspends TEFCA Exchange with another QHIN 
in accordance with this section and in accordance with Applicable Law, 
such suspension will not be deemed a violation of the Common Agreement.

Subpart E--Termination


Sec.  172.500   Applicability.

    This subpart establishes QHIN termination responsibilities, notice 
requirements for termination, and the effect of termination.


Sec.  172.501   QHIN self-termination.

    A QHIN may terminate its own Designation at any time without cause 
by providing ninety (90) calendar days prior written notice.


Sec.  172.502   QHIN termination.

    A QHIN's Designation will be terminated with immediate effect by 
ASTP/ONC (or, with ASTP/ONC's prior authorization, an RCE) giving 
written notice of termination to the QHIN if the QHIN:
    (a) Fails to comply with any of the regulations of this part and 
fails to remedy such material breach within thirty (30) calendar days 
after receiving written notice of such failure; provided, however, that 
if a QHIN is diligently working to remedy its material breach at the 
end of this thirty- (30-) day period, then ASTP/ONC (or an RCE) must 
provide the QHIN with up to another thirty (30) calendar days to remedy 
its material breach; or
    (b) A QHIN breaches a material provision of the Common Agreement 
where such breach is not capable of remedy.


Sec.  172.503   Termination by mutual agreement.

    A QHIN's Designation may be terminated at any time and for any 
reason by mutual, written agreement between the QHIN and ASTP/ONC (or 
an RCE).

Subpart F--Review of RCE or ASTP/ONC Decisions


Sec.  172.600   Applicability.

    This subpart establishes processes for review of RCE or ASTP/ONC 
actions, including QHIN appeal rights and the process for filing an 
appeal.


Sec.  172.601   ASTP/ONC review.

    (a) ASTP/ONC may, in its sole discretion, review all or any part of 
any RCE determination, policy, or action. If ASTP/ONC reviews an RCE 
determination that required ASTP/ONC's prior authorization under this 
part, no ASTP/ONC officer, employee, or agent who was engaged with 
helping to evaluate or decide the prior authorization, or a prior 
authorization involving the same party(s) or underlying facts, may 
participate in deciding or advising ASTP/ONC on its review of that 
determination.
    (b) ASTP/ONC may, in its sole discretion and on notice to affected 
QHINs or Applicant QHINs, stay any RCE determination, policy, or other 
action pending ASTP/ONC review. If ASTP/ONC stays an RCE determination 
that required ASTP/ONC's prior authorization under this part, no ASTP/
ONC officer, employee, or agent who was engaged with helping to 
evaluate or decide the prior authorization, or a prior authorization 
involving the same party(s) or underlying facts, may participate in 
deciding or advising ASTP/ONC on whether it should stay that 
determination.
    (c) ASTP/ONC may, in its sole discretion and on written notice, 
request that a QHIN, Applicant QHIN, or the RCE provide ASTP/ONC 
additional information regarding any RCE determination, policy, or 
other action.
    (d) On completion of its review, ASTP/ONC may affirm, modify, or 
reverse the determination, policy, or other action under review. ASTP/
ONC will provide notice to affected QHINs or Applicant QHINs that 
includes the basis for ASTP/ONC's decision.
    (e) ASTP/ONC will provide written notice under this section to 
affected QHINs or Applicant QHINs in the same manner as the original 
RCE determination, policy, or other action under review.
    (f) ASTP/ONC will issue a decision under this section within a 
timeframe agreed to by the affected Applicant QHIN or QHIN, as 
applicable, the RCE, and ASTP/ONC. ASTP/ONC may, at its sole 
discretion, extend the timeframe for a decision as circumstances 
necessitate.


Sec.  172.602   Basis for appeal by QHIN or Applicant QHIN.

    (a) An Applicant QHIN or QHIN may appeal the following decisions to 
ASTP/ONC or a hearing officer, as appropriate:
    (1) Applicant QHIN. An Applicant QHIN may appeal a denial of its 
QHIN application.
    (2) QHIN. A QHIN may appeal:
    (i) A decision to suspend the QHIN or to instruct the QHIN to 
suspend its Participant or Subparticipant.
    (ii) A decision to terminate the QHIN's Common Agreement.
    (b) [Reserved]


Sec.  172.603   Method and timing for filing an appeal.

    (a) To initiate an appeal, an authorized representative of the 
Applicant QHIN or QHIN must submit electronically, in writing to ASTP/
ONC, a notice of appeal that includes the date of the notice of appeal, 
the date of the decision being appealed, the Applicant QHIN or QHIN 
that is appealing, and the decision being appealed within fifteen (15) 
calendar days of the Applicant QHIN's or QHIN's receipt of the notice 
of:
    (1) Denial of a QHIN application;
    (2) Suspension or instruction to suspend its Participant or 
Subparticipant; or

[[Page 101816]]

    (3) Termination. With regard to an appeal of a termination, the 15-
calendar day timeframe may be extended by ASTP/ONC up to another 
fifteen (15) calendar days if the QHIN has been granted an extension 
for completing its remedy under Sec.  172.502(a).
    (b) An authorized representative of an Applicant QHIN or QHIN must 
submit electronically to ASTP/ONC, within thirty (30) calendar days of 
filing the intent to appeal, the following:
    (1) A statement of the basis for appeal, including a description of 
the facts supporting the appeal with citations to documentation 
submitted by the QHIN or Applicant QHIN; and
    (2) Any documentation the QHIN would like considered during the 
appeal.
    (c) The Applicant QHIN or QHIN filing the appeal may not submit on 
appeal any evidence that it did not submit prior to the appeal except 
evidence permitted by the hearing officer under Sec.  172.606.


Sec.  172.604   Effect of appeal on suspension and termination.

    An appeal does not stay the suspension or termination, unless 
otherwise ordered by ASTP/ONC or the hearing officer assigned under 
Sec.  172.605(b).


Sec.  172.605   Assignment of a hearing officer.

    (a) On receipt of an appeal under Sec.  172.603, ASTP/ONC may 
exercise its authority under Sec.  172.601 to review an RCE 
determination being appealed. If ASTP/ONC exercises its authority under 
Sec.  172.601 to review an RCE determination that required ONC's prior 
authorization under this part, no ASTP/ONC officer, employee, or agent 
who was engaged with helping to evaluate or decide the prior 
authorization, or a prior authorization involving the same party(s) or 
underlying facts, may participate in deciding or advising ASTP/ONC on 
its review of that determination. An appealing QHIN or Applicant QHIN 
that is not satisfied with ASTP/ONC's subsequent determination may 
appeal that determination to a hearing officer by filing a new notice 
of appeal and other appeal documents that comply with Sec.  172.603.
    (b) If ASTP/ONC declines review under paragraph (a) of this 
section, or if ASTP/ONC made the determination under review, ASTP/ONC 
will arrange for assignment of the case to a hearing officer to 
adjudicate the appeal.
    (c) The hearing officer must be an officer appointed by the 
Secretary of Health and Human Services.
    (d) The hearing officer may not be responsible to, or subject to 
the supervision or direction of, personnel engaged in the performance 
of investigative or prosecutorial functions for ASTP/ONC, nor may any 
officer, employee, or agent of ASTP/ONC engaged in investigative or 
prosecutorial functions in connection with any adjudication, in that 
adjudication or one that is factually related, participate or advise in 
the decision of the hearing officer, except as a counsel to ASTP/ONC or 
as a witness.


Sec.  172.606   Adjudication.

    (a) The hearing officer will decide issues of law and fact de novo 
and will apply a preponderance of the evidence standard when deciding 
appeals.
    (b) In making a determination, the hearing officer may consider:
    (1) The written record, which includes:
    (i) The RCE's or ASTP/ONC's determination and supporting 
information; and
    (ii) Appeal materials submitted by the Applicant QHIN or QHIN under 
Sec.  172.603.
    (2) Any information from a hearing conducted in-person, via 
telephone, or otherwise. The hearing officer has sole discretion to 
conduct a hearing:
    (i) To require either party to clarify the written record under 
paragraph (b)(1) of this section; or
    (ii) If the hearing officer otherwise determines a hearing is 
necessary.
    (c) The hearing officer will neither receive witness testimony nor 
accept any new information beyond what was provided in accordance with 
paragraph (b) of this section, except for good cause shown by the party 
seeking to submit new information.


Sec.  172.607   Determination by the hearing officer.

    (a) The hearing officer will issue a written determination within a 
timeframe agreed to by the affected Applicant QHIN or QHIN, as 
applicable, and ASTP/ONC and approved by the hearing officer. The 
hearing officer may, at their sole discretion, extend the timeframe for 
a written determination as circumstances necessitate.
    (b) The hearing officer's determination on appeal is the final 
decision of HHS unless within ten (10) business days, the Secretary, in 
the Secretary's sole discretion, chooses to review the determination. 
ASTP/ONC will notify the appealing party if the Secretary chooses to 
review the determination and will provide notice of the Secretary's 
final determination.

Subpart G--QHIN Attestation for the Adoption of the Trusted 
Exchange Framework and Common Agreement


Sec.  172.700   Applicability.

    This subpart applies to QHINs.


Sec.  172.701   Attestation submission and acceptance.

    (a) Applicability. This subpart establishes:
    (1) The attestation submission requirements for QHINs.
    (2) The review and acceptance processes that ASTP/ONC will follow 
for TEFCA attestations.
    (b) Submission of QHIN attestation. (1) In order to be listed in 
the QHIN Attestation Directory described in Sec.  172.702, a QHIN must 
submit all of the following information to ASTP/ONC:
    (i) Attestation affirming its adoption of the Common Agreement and 
Trusted Exchange Framework.
    (ii) General identifying information, including:
    (A) Name, address, city, state, zip code, and a hyperlink to its 
website.
    (B) Designation of an authorized representative, including the 
representative's name, title, phone number, and email address.
    (iii) Documentation confirming its Designation as a QHIN.
    (2) A QHIN must provide ASTP/ONC with written notice of any changes 
to its identifying information provided in accordance with this 
paragraph (b) within thirty (30) business days of the change(s) to its 
identifying information.
    (c) Submission method. A QHIN must electronically submit its 
attestation and documentation either via an email address identified by 
ASTP/ONC or via a submission on the ASTP/ONC website, if available.
    (d) Review and acceptance. (1) Within thirty (30) business days, 
ASTP/ONC will either accept or reject an attestation submission.
    (2) ASTP/ONC will accept an attestation if it determines that the 
QHIN has satisfied the requirements of paragraphs (b) and (c) of this 
section. ASTP/ONC will provide written notice to the applicable QHIN's 
authorized representative that the attestation has been accepted.
    (3) ASTP/ONC will reject an attestation if it determines that the 
requirements of paragraph (b) or (c) of this section, or both, have not 
been satisfied.
    (4) ASTP/ONC will provide written notice to the QHIN's authorized 
representative of the determination along with the basis for the 
determination.
    (5) An ASTP/ONC determination under this section is final agency 
action

[[Page 101817]]

and not subject to further administrative review, except the Secretary 
may choose to review the determination as provided in Sec.  172.607(b). 
However, a QHIN may, at any time, resubmit an attestation in accordance 
with paragraphs (b) and (c) of this section.


Sec.  172.702   QHIN Attestation Directory.

    (a) Applicability. This subpart establishes processes for 
publishing a directory on the ASTP/ONC website of QHINs that 
voluntarily elect to adopt the Common Agreement and Trusted Exchange 
Framework and attest to such adoption.
    (b) Publication. (1) Within fifteen (15) calendar days of notifying 
a QHIN that its QHIN submission has been accepted, ASTP/ONC will 
publish, at a minimum, the QHIN's name in the QHIN Attestation 
Directory on the ASTP/ONC website.
    (2) ASTP/ONC will identify within the QHIN Attestation Directory 
those QHINs that are suspended under the Common Agreement.
    (c) Removal from the QHIN Attestation Directory. (1) A QHIN whose 
Common Agreement has been terminated no longer qualifies to be included 
in the QHIN Attestation Directory as it is no longer considered a QHIN 
and will be removed from the QHIN Attestation Directory.
    (2) Upon termination of a QHIN's Common Agreement, ASTP/ONC (or an 
RCE) will send a written a statement of intent to remove the QHIN from 
the QHIN Attestation Directory to the authorized representative of the 
QHIN.
    (3) Any written statement given under paragraph (c)(2) of this 
section shall consist of the following, as appropriate:
    (i) The name of the terminated QHIN and the name and contact 
information of the authorized representative of the QHIN.
    (ii) A short statement setting forth findings of fact with respect 
to any violation of the Common Agreement or other basis for the QHIN's 
termination under the Common Agreement and justifying the termination 
on the basis of those findings of facts.
    (iii) Other materials as ASTP/ONC (or the RCE) may deem relevant.
    (d) Duration. A QHIN that is removed from the QHIN Attestation 
Directory will remain removed until a new attestation is accepted by 
ASTP/ONC in accordance with the processes specified in this subpart.
    (e) Final agency action. An ASTP/ONC determination under this 
section is final agency action and not subject to further 
administrative review, except the Secretary may choose to review the 
determination as provided in Sec.  172.607(b).

Xavier Becerra,
Secretary, Department of Health and Human Services.
[FR Doc. 2024-29163 Filed 12-11-24; 8:45 am]
BILLING CODE 4150-45-P`