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

1The 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). 

2Reasonable 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/informationblocking/. 

3Federal Register: Statement of Organization, 

Functions, and Delegations of Authority; Office of 

The National Coordinator for Health Information 

Technology (89 FR 60903). 

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 AgreementTM

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. TEFCATM Manner Exception 

V. Trusted Exchange Framework and 

Common AgreementTM

A. Subpart A—General Provisions 

B. Subpart B—Qualifications for 

Designation 

C. Subpart C—QHINTM Onboarding and 

Designation Processes 

D. Subpart D—Suspension 

E. Subpart E—Termination 

F. Subpart F—Review of RCE® or ASTP/ 

ONC Decisions 

G. Subpart G—QHINTM Attestation for the 

Adoption of the Trusted Exchange 

Framework and Common AgreementTM

VI. Severability 

VII. Collection of Information 

Requirements—Qualified Health 

Information NetworksTM

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. 

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 


lotter on DSK11XQN23PROD with RULES3
Federal Register / Vol. 89, No. 241 / Monday, December 16, 2024 / Rules and Regulations 101773 

4https://www.hhs.gov/about/news/2024/07/10/ 

hhs-proposes-hti-2-rule-improve-patientengagement-information-sharing-public-healthinteroperability.html. 

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. 

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, 

§ 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 § 170.315(a)(10) and (13), 

(b)(6), (e)(2), and (g)(8). Additionally, as 

discussed in section III.A.2, we have 

revised § 170.315(b)(7) and (8) to 

remove § 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 § 170.550(h), the Privacy and 

Security Certification Framework 

requirements, that adds the certification 

criterion ‘‘decision support 

interventions’’ (§ 170.315(b)(11)) to the 

list of certification criteria in 

§ 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 § 170.550(h). As 

discussed in section III.B, we have 

added § 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 

AgreementTM (TEFCATM) in § 171.401. 

3. Trusted Exchange Framework and 

Common AgreementTM

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 § 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 § 172.102) of 

QHINs and Designation of QHINs, 

suspension, termination, and 

administrative appeals to ASTP/ONC, as 

described in § 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. 


lotter on DSK11XQN23PROD with RULES3
101774 Federal Register / Vol. 89, No. 241 / Monday, December 16, 2024 / Rules and Regulations 

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 nonconformities 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 


lotter on DSK11XQN23PROD with RULES3
Federal Register / Vol. 89, No. 241 / Monday, December 16, 2024 / Rules and Regulations 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 § 170.314 from 

the Program regulations in 45 CFR part 

170, § 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 §§ 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’’ 

(§ 170.502). 

• Authorization scope for ONC–ATL 

status (§ 170.511). 

• Requirements for ONC–ACBs to 

refund fees to developers seeking 

certification under certain 

circumstances (§ 170.523(j)(3)). 

• Applicability of a newer version of 

a minimum standard (§ 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, 


lotter on DSK11XQN23PROD with RULES3
101776 Federal Register / Vol. 89, No. 241 / Monday, December 16, 2024 / Rules and Regulations 

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 

§ 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 

§ 170.523(f) in the preamble. However, 

we erroneously neglected to include the 

removal of ‘‘EHR Modules’’ in the 

regulatory text for § 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 § 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 § 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 ‘‘drugformulary and preferred drug list 

checks’’ certification criterion 

(§ 170.315(a)(10)), ‘‘patient-specific 

education resources’’ (§ 170.315(a)(13)), 

‘‘data export’’ certification criterion 

(§ 170.315 (b)(6)), ‘‘secure messaging’’ 

certification criterion (§ 170.315(e)(2)), 

and ‘‘application access—data category 

request’’ (§ 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 

§ 170.550(m) in one action by removing 

and reserving § 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 § 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 § 170.315(b)(7) and (8) to remove 

§ 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 ‘‘patientspecific education resources’’ 

certification criterion in 

§ 170.315(a)(13). They stated that while 

innovation has progressed, patientspecific educational resources remain 

essential in supporting clinicians during 

patient interactions. Another 

commenter expressed concern over the 

lack of Fast Healthcare Interoperability 

Resources (FHIR®)-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 AIdriven patient education would 

encourage ongoing innovation. 

Response. We thank commenters for 

providing feedback on the removal of 

‘‘patient-specific education resources’’ 

certification criterion in 

§ 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 

§ 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 

§ 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 § 170.315(a)(13). 

Specifically, in the ONC Cures Act 

Final Rule, we finalized requirements in 

§ 170.550(m)(1) permitting ONC–ACBs 

to issue certificates for the ‘‘patientspecific education resources’’ 

certification criterion in § 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 ‘‘patientspecific education resources’’ 


lotter on DSK11XQN23PROD with RULES3
Federal Register / Vol. 89, No. 241 / Monday, December 16, 2024 / Rules and Regulations 101777 

certification criterion in § 170.315(a)(13) 

included no means to advance 

innovations such as FHIR-based 

educational resources or patientengagement 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 § 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 § 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 

§ 170.315(b)(7) and (8) to remove 

§ 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’’ (§ 170.315(b)(11))) to 

replace the ‘‘clinical decision support’’ 

certification criterion (§ 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 

(§ 170.315(b)(11)) to the list of 

certification criteria in 

§ 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 

§ 170.550(h)(3)(ii), that Health IT 

Modules certified to the ‘‘decision 

support interventions’’ 

(§ 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 

§ 170.315(d)(1); ‘‘auditable events and 

tamper-resistance’’ in § 170.315(d)(2); 

‘‘audit report(s)’’ in § 170.315(d)(3); 

‘‘automatic access time-out’’ in 

§ 170.315(d)(5); ‘‘emergency access’’ in 

§ 170.315(d)(6); ‘‘end-user device 

encryption’’ in § 170.315(d)(7); ‘‘encrypt 

authentication credentials’’ in 

§ 170.315(d)(12); and ‘‘multi-factor 

authentication’’ in § 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’’ 

(§ 170.315(b)(11)) certification criterion 

must also be certified to, we neglected 

to include ‘‘emergency access’’ in 

§ 170.315(d)(6). However, because we 

stated, in the HTI–2 Proposed Rule, that 

we were proposing to require in 

§ 170.550(h)(3)(ii) that Health IT 

Modules certified to the ‘‘decision 

support interventions’’ 

(§ 170.315(b)(11)) must also be certified 

to the specific privacy and security 

certification criteria on and after January 

1, 2028, and because § 170.315(d)(6) is 

one of the specific privacy and security 

certification criteria referenced in 

§ 170.550(h)(3)(ii), we believe that the 

public was informed of the requirement 

to certify to § 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 

(§ 170.315(b)(11)) to the list of 

certification criteria in 

§ 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 § 170.550(h) (89 FR 

63508). We revised § 170.550(h) in the 

ONC Cures Act Final Rule but intended 

for § 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, § 170.550(h)(4) was 

removed. Therefore, we proposed to add 

§ 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 

§ 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 

§ 170.550(h)(4) back in the CFR. 

IV. Information Blocking 

Enhancements—Part 171, Subpart D 

(TEFCATM) 

In the HTI–2 Proposed Rule, we 

proposed revisions to defined terms for 

purposes of the information blocking 

regulations, which appear in 45 CFR 

171.102. Specifically, we proposed to 

clarify the definition of ‘‘health care 

provider’’ (89 FR 63616, 63617, and 

63802) and adopt definitions for three 

terms not previously included in 

§ 171.102: ‘‘business day’’ (89 FR 63601, 

63602, 63626, and 63802), ‘‘health 

information technology or health IT’’ 

(89 FR 63617 and 63802), and 

‘‘reproductive health care’’ (89 FR 63633 

and 63802). We proposed to revise two 

existing exceptions in subpart B of 45 

CFR part 171 (§§ 171.202 and 171.204). 

We proposed revisions to paragraphs 

(a), (d), and (e) of § 171.202 (89 FR 

63620 through 63622 and 63803) and to 

paragraphs (a)(2) and (3) and (b) of 

§ 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 

§ 171.206 (89 FR 63627 through 63639 

and 63804) and the Requestor 

Preferences Exception as new § 171.304 

(89 FR 63639 through 63642, 63804 and 

63805). We proposed to codify in 

§ 171.401 definitions of certain terms 

relevant to the Trusted Exchange 

Framework and Common AgreementTM

(TEFCATM) (89 FR 63642, 63804, and 

63805) and in § 171.104 descriptions of 

certain practices that constitute 

interference with the access, exchange, 

and use of electronic health information 

(EHI) (89 FR 63617 through 63620, 

63802, and 63803). Lastly, we solicited 

comment on potential revisions to the 

TEFCA Manner Exception in subpart D 

(§ 171.403). 


lotter on DSK11XQN23PROD with RULES3
101778 Federal Register / Vol. 89, No. 241 / Monday, December 16, 2024 / Rules and Regulations 

In this final rule, we only address 

comments on the proposal to codify 

definitions of certain TEFCA terms in 

§ 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, 

§ 171.400, ‘‘Availability and effect of 

exceptions,’’ which mirrors §§ 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 § 171.401 for 

definitions in a future rulemaking, and 

also reserved § 171.402 for future use. In 

§ 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 § 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 ParticipantQHIN Agreement, a ParticipantSubparticipant 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 

§ 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 § 171.401 the 

definitions from § 172.102 for the 

following terms: Common Agreement, 

Framework Agreement, Participant, 

Qualified Health Information Network 

or QHINTM, and Subparticipant. The 

definitions would apply to all of subpart 

D. 

Comments. We did not receive any 

comments regarding our proposal to 

adopt in § 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 § 172.102. 

B. TEFCATM 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 (§ 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 (§ 171.302) and the 

Licensing Exception (§ 171.303). In 

addition to these three requirements, we 

noted (89 FR 63643) that we also 

included a limitation in § 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 QHINsTM 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 (§ 171.302) and the Licensing 

Exception (§ 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 § 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 


lotter on DSK11XQN23PROD with RULES3
Federal Register / Vol. 89, No. 241 / Monday, December 16, 2024 / Rules and Regulations 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 

§ 170.215, including standards that may 

be updated from time to time through 

§ 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 § 171.403(c) once all QHINs can 

support brokered FHIR. Another option 

would be to sunset the limitation in 

§ 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 § 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 

§ 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 

(§ 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 § 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 § 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 § 170.215. Commenters stated that 

removing the condition in § 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 


lotter on DSK11XQN23PROD with RULES3
101780 Federal Register / Vol. 89, No. 241 / Monday, December 16, 2024 / Rules and Regulations 

5 4.2 Required Information and Permitted Fees 

and Table 2 at https://rce.sequoiaproject.org/wpcontent/uploads/2024/08/SOP-Exchange-Purposes_

CA-v3_508.pdf. 

exception is only available when both 

the actor and the requestor participate 

in TEFCA as QHINs, Participants, or 

Subparticipants (§ 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 

(§ 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. 

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 

§ 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 § 170.215 or approved 

through the SVAP process. We believe 

including standards approved through 

the SVAP process, as well as those 

adopted under § 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 

§ 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 nonTEFCA 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 AgreementTM

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 AgreementTM

(TEFCATM) 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® (QHINsTM) 

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 


lotter on DSK11XQN23PROD with RULES3
Federal Register / Vol. 89, No. 241 / Monday, December 16, 2024 / Rules and Regulations 101781 

6Node 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. 7Public Law 104–191, 110 Stat. 1936. 

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 

§ 172.102, means the transaction of 

electronic protected health information 

(ePHI) between Nodes 6 using a TEFCAspecific 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. 

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. 

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 


lotter on DSK11XQN23PROD with RULES3
101782 Federal Register / Vol. 89, No. 241 / Monday, December 16, 2024 / Rules and Regulations 

8QHIN 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. 

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 publicprivate 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 networkto-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 

§ 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. 

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®

(RCE®). 

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 everchanging 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 


lotter on DSK11XQN23PROD with RULES3
Federal Register / Vol. 89, No. 241 / Monday, December 16, 2024 / Rules and Regulations 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 (§ 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 publicprivate 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 


lotter on DSK11XQN23PROD with RULES3
101784 Federal Register / Vol. 89, No. 241 / Monday, December 16, 2024 / Rules and Regulations 

9https://www.healthit.gov/topic/interoperability/ 

policy/trusted-exchange-framework-and-commonagreement-tefca. 

10https://rce.sequoiaproject.org/tefca/. 

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 

(§ 171.403(a); 89 FR 1388). When the 

necessary conditions under § 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 nonmedical 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 nonduplicative. 

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/ONC9

and RCE 10 websites. In addition, we 

continue to support the transition to 

TEFCA Exchange through regular 

webinars and information sessions for 

the public. 

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 


lotter on DSK11XQN23PROD with RULES3
Federal Register / Vol. 89, No. 241 / Monday, December 16, 2024 / Rules and Regulations 101785 

11The HHS Office for Civil Rights has authority 

for implementing and enforcing HIPAA. 

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 OCR11

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. 

Comment. One commenter 

recommended that we refer to, prioritize 

as a goal, recognize, or focus on highquality 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 thirdparty 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 § 172.100 of 

the HTI–2 Proposed Rule the basis, 

purpose, and scope for the proposed 

TEFCA provisions in 45 CFR part 172. 


lotter on DSK11XQN23PROD with RULES3
101786 Federal Register / Vol. 89, No. 241 / Monday, December 16, 2024 / Rules and Regulations 

We proposed in § 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 § 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 

§ 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 § 172.100(b)(2) supports the 

statutory basis because it implements 

section 3001(c)(9)(D) of the PHSA. We 

proposed in § 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 § 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 § 172.102 

captures suspended QHINs (since a 

suspended QHIN is still a QHIN) and so 

we did not address them separately in 

proposed § 172.101. In § 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 § 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 § 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 §§ 172.501 

(‘‘QHIN self-termination’’) and 172.503 

(‘‘Termination by mutual agreement’’). 

In § 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 § 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., 


lotter on DSK11XQN23PROD with RULES3
Federal Register / Vol. 89, No. 241 / Monday, December 16, 2024 / Rules and Regulations 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, § 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® (RCE®)’’ 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 § 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 § 172.102. 


lotter on DSK11XQN23PROD with RULES3
101788 Federal Register / Vol. 89, No. 241 / Monday, December 16, 2024 / Rules and Regulations 

12Common Agreement for Nationwide Health 

Information Interoperability (healthit.gov). 

13 Id. 

14 Id. 

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 

§ 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 § 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 § 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 fastdeveloping 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. 

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 § 171.103, as well as the 

proposed text of § 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 

(§ 172.303(b)), setting onboarding 

requirements and determining a QHIN 

has complied with those requirements 

(§ 172.304(b) and (c)), and deeming a 

QHIN application withdrawn for failure 

to respond to information requests 

during the designation process 

(§ 172.305(c)). We have added language 

to § 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 factgathering, 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, 


lotter on DSK11XQN23PROD with RULES3
Federal Register / Vol. 89, No. 241 / Monday, December 16, 2024 / Rules and Regulations 101789 

we proposed qualifications for 

Designation. In § 172.200, we proposed 

to tie QHIN status to meeting the 

requirements specified in § 172.201. We 

proposed that an Applicant QHIN (as 

we proposed to define it in § 172.102) 

would need to meet all requirements in 

§ 172.201 to be Designated, and a QHIN 

would need to continue to meet all 

requirements in § 172.201 to maintain 

its Designation. We noted that the 

requirements we proposed in § 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 § 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 

§ 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 § 172.201, we proposed 

Designation requirements in three 

categories: (a) ownership; (b) exchange 

requirements; and (c) Designated 

Network Services. 

In § 172.201(a), we proposed the 

ownership requirements. In 

§ 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 § 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 § 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 § 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 

§ 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 § 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 § 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 

§ 172.201, at scale. We proposed that an 

entity seeking to become a QHIN must, 

beginning at the time of application, 


lotter on DSK11XQN23PROD with RULES3
101790 Federal Register / Vol. 89, No. 241 / Monday, December 16, 2024 / Rules and Regulations 

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 § 172.102); (3) be 

exchanging information for at least one 

of the Exchange Purposes (as that term 

is defined in § 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 § 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 

§ 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 § 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 

§ 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 

§ 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 § 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 § 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 § 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 § 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 § 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 § 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 § 172.201(c)(2), 

we proposed that a QHIN must maintain 

adequate written policies and 

procedures to support meaningful 

TEFCA Exchange as described in 

§ 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 § 172.201(c)(3), we proposed that a 

QHIN must maintain a Designated 

Network (as proposed to be defined in 

§ 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 § 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 


lotter on DSK11XQN23PROD with RULES3
Federal Register / Vol. 89, No. 241 / Monday, December 16, 2024 / Rules and Regulations 101791 

technical connectivity, which makes 

network-to-network exchange possible 

and, therefore, was important to include 

in this regulation. 

In § 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 § 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 § 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 § 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-ofnetworks 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 

§ 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 § 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 

§ 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 

§ 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 § 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 § 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, 


lotter on DSK11XQN23PROD with RULES3
101792 Federal Register / Vol. 89, No. 241 / Monday, December 16, 2024 / Rules and Regulations 

in § 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 § 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 

§ 172.202(a), we proposed that a QHIN 

would be required to obtain express 

consent from any individual before 

providing IAS, as defined in § 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 

§ 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 § 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 

§ 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 

§ 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 § 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 § 172.202(e)(2), we did not 

propose that it be required to duplicate 

such a notification. Lastly, the proposed 

requirement in § 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 


lotter on DSK11XQN23PROD with RULES3
Federal Register / Vol. 89, No. 241 / Monday, December 16, 2024 / Rules and Regulations 101793 

15Notice 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. 

16See USASPENDING.gov, https://

www.usaspending.gov/award/CONT_AWD_

75P00123C00019_7570_-NONE-_-NONE-. 

17 87 FR 2822. 

18 87 FR 2818. 

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—QHINTM 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 § 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. 

In subpart C of part 172, we described 

the proposed QHIN Onboarding and 

Designation processes. Onboarding, as 

we proposed to define it in § 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 § 172.102, is the 

written determination that an Applicant 

QHIN has satisfied all regulatory 

requirements and is now a QHIN.18

In § 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 

§ 172.301, we proposed to establish the 

information Applicant QHINs must 

submit in order to be Designated as a 


lotter on DSK11XQN23PROD with RULES3
101794 Federal Register / Vol. 89, No. 241 / Monday, December 16, 2024 / Rules and Regulations 

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 

§ 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 § 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 § 172.302, we proposed a process, 

with required timelines and allowable 

extensions, for ONC (or an RCE) to 

review applications. We proposed in 

§ 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 § 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 § 172.201, and, 

if the Applicant QHIN proposes to 

provide IAS, the requirements set forth 

in § 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 § 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 § 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 § 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 

§ 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 § 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 § 172.303, we proposed 

requirements related to QHIN approval 

and Onboarding. We proposed in 

§ 172.303(a) that an Applicant QHIN 

would have the burden of 

demonstrating its compliance with all 

qualifications for Designation in 

§ 172.201, and, if the Applicant QHIN 

proposes to provide IAS, the 

qualifications in § 172.202. We 

proposed in § 172.303(b) that if ONC (or 

an RCE) determines an Applicant QHIN 

meets the requirements for Designation 


lotter on DSK11XQN23PROD with RULES3
Federal Register / Vol. 89, No. 241 / Monday, December 16, 2024 / Rules and Regulations 101795 

set forth in § 172.201, and, if the 

Applicant QHIN proposes to provide 

IAS, the qualifications set forth in 

§ 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 § 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 § 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 § 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 § 172.304, we proposed the specific 

procedural requirements for the 

Designation of QHINs. In § 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 § 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 § 172.304(c) that if a 

QHIN is unable to complete the 

requirement in § 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 § 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 § 172.305, we proposed 

requirements related to withdrawal of 

an application. In § 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 § 172.305(b), we proposed that an 

Applicant QHIN may withdraw its 

application at any point prior to 

Designation. In § 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 § 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 § 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 


lotter on DSK11XQN23PROD with RULES3
101796 Federal Register / Vol. 89, No. 241 / Monday, December 16, 2024 / Rules and Regulations 

explanation would likely vary based on 

the specific facts and circumstances. 

In § 172.307, we proposed 

requirements for re-application. In 

§ 172.307(a), we proposed that 

Applicant QHINs may resubmit their 

applications by complying with the 

provisions of § 172.301 in the event that 

an application was denied or 

withdrawn. We noted that reapplication pursuant to § 172.307(a) 

would also be conditioned on meeting 

the requirements of proposed 

paragraphs (b) through (d) of § 172.307, 

as applicable. We proposed in 

§ 172.307(b) that an Applicant QHIN 

may reapply at any time after it has 

voluntarily withdrawn its application as 

specified in § 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 selfidentify 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 § 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 § 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 § 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 reapplication, in § 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 § 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 


lotter on DSK11XQN23PROD with RULES3
Federal Register / Vol. 89, No. 241 / Monday, December 16, 2024 / Rules and Regulations 101797 

19 XP Implementation: Treatment, https://

rce.sequoiaproject.org/wp-content/uploads/2024/ 

07/SOP-Treatment-XP-Implementation_508.pdf. 

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 §§ 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 §§ 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. 

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 § 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 

§ 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 

§ 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 § 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 § 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 

(§ 172.303(b)), setting onboarding 

requirements and determining a QHIN 

has complied with those requirements 

(§ 172.304(b) and (c)), and deeming a 

QHIN application withdrawn for failure 

to respond to information requests 

during the Designation process 

(§ 172.305(c)). Under § 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 § 172.401, we 

proposed provisions related to ONC (or 

the RCE) suspension of a QHIN or 

directed suspension of a Participant or 

Subparticipant. In § 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 

§ 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 


lotter on DSK11XQN23PROD with RULES3
101798 Federal Register / Vol. 89, No. 241 / Monday, December 16, 2024 / Rules and Regulations 

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 § 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 § 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 § 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 

§ 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 § 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 § 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 § 172.402, we proposed provisions 

related to selective suspension of 

TEFCA Exchange between QHINs. In 

§ 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 

§ 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 § 172.402(c), we proposed that if a 

QHIN suspends TEFCA Exchange with 

another QHIN under § 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 § 172.402(d), we proposed that, 

provided that a QHIN suspends TEFCA 

exchange with another QHIN in 

accordance with other provisions in 

§ 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 


lotter on DSK11XQN23PROD with RULES3
Federal Register / Vol. 89, No. 241 / Monday, December 16, 2024 / Rules and Regulations 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 § 172.401(d), we modified the final 

regulatory text to better align with 

§ 172.401(b). Specifically, in 

§ 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 § 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 § 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 § 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 § 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 

§ 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 

§ 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 

§ 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 § 172.401(a) 

language requiring an RCE to seek and 

receive ASTP/ONC’s prior authorization 

before suspending a QHIN. We have 

added to § 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 § 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 § 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 § 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 


lotter on DSK11XQN23PROD with RULES3
101800 Federal Register / Vol. 89, No. 241 / Monday, December 16, 2024 / Rules and Regulations 

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 § 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 § 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 § 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 


lotter on DSK11XQN23PROD with RULES3
Federal Register / Vol. 89, No. 241 / Monday, December 16, 2024 / Rules and Regulations 101801 

20See 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-commonagreement-for-nationwide-health-informationinteroperability-common. 

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 § 172.502 language 

requiring an RCE to seek and receive 

ASTP/ONC’s prior authorization before 

terminating a QHIN. Under § 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® 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 § 172.600 reflects this overall 

scope as an applicability section for this 

subpart. 

In § 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 

§ 172.601(a) that ONC may, in its sole 

discretion, review all or any part of any 

RCE determination, policy, or action. In 

§ 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 § 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 § 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 

§ 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 § 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 § 172.602(a)(1), we proposed that an 

Applicant QHIN would be able to 

appeal the denial of its application. In 

§ 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 § 172.603, we proposed the method 

and timing for filing an appeal. In 

§ 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 

§ 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 § 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 


lotter on DSK11XQN23PROD with RULES3
101802 Federal Register / Vol. 89, No. 241 / Monday, December 16, 2024 / Rules and Regulations 

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 § 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 § 172.502, at the 

hearing officer stage, or some 

combination of the two based on 

circumstances of the suspension or 

termination. 

In § 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 § 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 

§ 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 § 172.605, we proposed provisions 

related to the assignment of a hearing 

officer. In § 172.605(a), we proposed 

that, in the event of an appeal, the 

National Coordinator may exercise 

authority under § 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 § 172.603. In § 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 § 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 § 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 § 172.606, we proposed 

requirements related to adjudication. In 

§ 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 § 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 

§ 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 § 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 § 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 


lotter on DSK11XQN23PROD with RULES3
Federal Register / Vol. 89, No. 241 / Monday, December 16, 2024 / Rules and Regulations 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 § 172.607, we proposed 

requirements related to a decision by 

the hearing officer. In § 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 § 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 

§ 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 § 172.601(e). 

Similarly to ASTP/ONC timeframe 

revision, we have revised § 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 

§ 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 

§ 172.603(a) is a formatting change made 

for clarity. 

In addition, we have added to 

§§ 172.601(a) and (b) and 172.605(a) 

language that if ASTP/ONC reviews 

(under § 172.601(a)) or stays (under 

§ 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 


lotter on DSK11XQN23PROD with RULES3
101804 Federal Register / Vol. 89, No. 241 / Monday, December 16, 2024 / Rules and Regulations 

21The 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. 

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

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 § 172.700 that subpart 

G would establish the attestation 

submission requirements applicable to 

QHINs. In § 172.701, we proposed 

attestation submission requirements for 

QHINs and review and acceptance 

processes that ONC will follow for 

TEFCA attestations. In § 172.701(b), we 

proposed that in order to be listed in the 

QHIN Directory described in proposed 

§ 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 § 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 § 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 § 172.701(c) that a 

QHIN must electronically submit its 

attestation and documentation specified 

in § 172.701(b) either via an email 

address identified by ONC or via a 

submission on the ONC website, if 

available. We proposed in § 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 

§ 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 

§ 172.701(d), we also proposed that 

ONC would reject a submission if it 

determines that the requirements of 

§ 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 

§ 172.607(b). However, we proposed 

that a QHIN may, at any time, resubmit 

an attestation and documentation in 

accordance with §§ 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 § 172.702, we proposed the 

requirements for a QHIN directory. We 

proposed in § 172.702(a) that this 

subpart would establish processes for 

publishing a directory of QHINs on the 

ONC website. We proposed in 

§ 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 § 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 § 172.702(c) to 

establish requirements for removal of a 

QHIN from the QHIN directory. We 

proposed in § 172.702(c)(1) that ONC 

will remove a QHIN that is no longer 

eligible for QHIN status from the QHIN 


lotter on DSK11XQN23PROD with RULES3
Federal Register / Vol. 89, No. 241 / Monday, December 16, 2024 / Rules and Regulations 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 § 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 § 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 § 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 § 172.702(e), we proposed 

that an ONC determination under 

§ 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 

§ 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 nonbinding 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 § 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 

§ 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 § 172.701. As proposed 

and finalized in § 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 §§ 172.701 and 

172.702 accordingly to refer to the 

‘‘QHIN Attestation Directory’’ rather 

than the QHIN Directory. We have also 


lotter on DSK11XQN23PROD with RULES3
101806 Federal Register / Vol. 89, No. 241 / Monday, December 16, 2024 / Rules and Regulations 

revised § 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 § 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 

§ 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 §§ 170.101 (89 FR 63766) 

and 171.101 (89 FR 63802), and 

inclusion in the newly codified 

§ 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 

§§ 170.101 and 171.101, and inclusion 

in the newly codified § 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 NetworksTM

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 


lotter on DSK11XQN23PROD with RULES3
Federal Register / Vol. 89, No. 241 / Monday, December 16, 2024 / Rules and Regulations 101807 

22According to the May 2022 Bureau of Labor 

Statistics occupational employment statistics, the 

mean hourly wage for Office Clerks, General (43– 

9061) is $19.78. 

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 

NetworksTM

As stated in the HTI–2 Proposed Rule 

(89 FR 63661), we proposed in § 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 § 172.701, we proposed attestation 

submission requirements for QHINs and 

review and acceptance processes that 

ONC would follow for TEFCA 

attestations. In § 172.701(b), we 

proposed that in order to be listed in the 

QHIN Directory described in proposed 

§ 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 § 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 § 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. 

TABLE 2—ESTIMATED ANNUALIZED TOTAL BURDEN HOURS FOR QHINS TO COMPLY WITH APPLICATION AND ATTESTATION

REQUIREMENTS

Code of Federal Regulations section 

Number of 

applicant 

QHIN or 

QHINs 

Average 

burden hours Total 

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 


lotter on DSK11XQN23PROD with RULES3
101808 Federal Register / Vol. 89, No. 241 / Monday, December 16, 2024 / Rules and Regulations 

23The 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. 

24https://www.sba.gov/sites/sbagov/files/2023- 

06/Table%20of%20Size%20Standards_

Effective%20March%2017%2C%202023

%20%282%29.pdf. 

25https://www.sba.gov/article/2022/feb/01/ 

guidance-using-naics-2022-procurement. 

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 AgreementSM

The regulations in 45 CFR part 172 

outline the application requirements an 

Applicant Qualified Health Information 

Network® (QHINTM) 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® (RCETM) 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

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 AgreementTM

(TEFCATM) 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® (QHINsTM) 

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. 

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 


lotter on DSK11XQN23PROD with RULES3
Federal Register / Vol. 89, No. 241 / Monday, December 16, 2024 / Rules and Regulations 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 

■ 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. 

■ 2. Revise § 170.101 to read as follows: 

§ 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. 

■ 3. Amend § 170.315 by: 

■ a. Removing and reserving paragraphs 

(a)(10) and (13) and (b)(6); 

■ b. Revising paragraphs (b)(7) and (8); 

and 

■ c. Removing and reserving paragraphs 

(e)(2) and (g)(2). 

The revisions read as follows: 

§ 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 § 170.205(a)(4) that 

is tagged as restricted and subject to 

restrictions on re-disclosure according 

to the standard adopted in 

§ 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 § 170.205(a)(4) that is tagged as 

restricted and subject to restrictions on 

re-disclosure according to the standard 

adopted in § 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. 

* * * * * 

■ 4. Amend § 170.502 by revising the 

definition of ‘‘Gap certification’’ to read 

as follows: 

§ 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 NVLAPaccredited 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. 

* * * * * 

■ 5. Revise § 170.511 to read as follows: 

§ 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. 

■ 6. Amend § 170.523 by revising 

paragraphs (f) introductory text and 

(j)(3) to read as follows: 


lotter on DSK11XQN23PROD with RULES3
101810 Federal Register / Vol. 89, No. 241 / Monday, December 16, 2024 / Rules and Regulations 

§ 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). 

* * * * * 

■ 7. Amend § 170.550 by revising 

paragraph (h)(3)(ii) and adding 

paragraph (h)(4) to read as follows: 

§ 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 

§ 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 

■ 8. The authority citation for part 171 

continues to read as follows: 

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

552. 

■ 9. Amend § 171.101 by adding 

paragraph (c) to read as follows: 

§ 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. 

■ 10. Add § 171.401 to read as follows: 

§ 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. 

■ 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 

§ 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 

NetworkTM (QHINTM) to attest to 

adoption of the Trusted Exchange 

Framework and Common AgreementTM

(TEFCATM). 

(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. 

§ 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 


lotter on DSK11XQN23PROD with RULES3
Federal Register / Vol. 89, No. 241 / Monday, December 16, 2024 / Rules and Regulations 101811 

situated or to other dissimilar 

circumstances. 

§ 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 thenapplicable 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. 


lotter on DSK11XQN23PROD with RULES3
101812 Federal Register / Vol. 89, No. 241 / Monday, December 16, 2024 / Rules and Regulations 

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® or QHINTM. 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®

(RCE®). 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. 

§ 172.103 Responsibilities ASTP/ONC may 

delegate to the RCE. 

(a) ASTP/ONC may delegate to the 

RCE the TEFCA implementation 


lotter on DSK11XQN23PROD with RULES3
Federal Register / Vol. 89, No. 241 / Monday, December 16, 2024 / Rules and Regulations 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 

§ 172.200 Applicability. 

This subpart establishes Designation 

qualifications. 

(a) Applicant QHIN. An Applicant 

QHIN must meet all requirements in 

§ 172.201 to be Designated. An 

Applicant QHIN that proposes to offer 

Individual Access Services must also 

meet all requirements in § 172.202 to be 

Designated. 

(b) QHIN. A QHIN must continue to 

meet all requirements in § 172.201 to 

maintain its Designation. A QHIN that 

offers Individual Access Services must 

also continue to meet all requirements 

in § 172.202 to maintain its Designation. 

(c) Performance of TEFCA Exchange. 

The Designation qualifications in 

§§ 172.201 and 172.202 describe certain 

requirements for Designation. 

§ 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. 

§ 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 thirdparty 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 

§ 172.300 Applicability. 

This subpart establishes, as to QHINs, 

the application, review, Onboarding, 

withdrawal, and redetermination 

processes for Designation. 

§ 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. 

§ 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 § 172.201 and, if the Applicant 

QHIN proposes to provide IAS, the 

requirements set forth in § 172.202. 

ASTP/ONC (or an RCE) will complete 

its review within sixty (60) calendar 

days of the Applicant QHIN being 


lotter on DSK11XQN23PROD with RULES3
101814 Federal Register / Vol. 89, No. 241 / Monday, December 16, 2024 / Rules and Regulations 

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 § 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. 

§ 172.303 QHIN approval and Onboarding. 

(a) An Applicant QHIN has the 

burden of demonstrating its compliance 

with all qualifications for Designation in 

§ 172.201 and, if the Applicant QHIN 

proposes to provide IAS, the 

qualifications in § 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 § 172.201, and if the 

Applicant QHIN proposes to provide 

IAS, the qualifications set forth in 

§ 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. 

§ 172.304 QHIN Designation. 

(a) If all requirements of the 

Onboarding process specified in 

§ 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. 

§ 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). 

§ 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. 

§ 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 

§ 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 § 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 § 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 

§ 172.400 Applicability. 

This subpart describes suspension 

responsibilities, notice requirements for 

suspension, and the effect of 

suspension. 

§ 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. 


lotter on DSK11XQN23PROD with RULES3
Federal Register / Vol. 89, No. 241 / Monday, December 16, 2024 / Rules and Regulations 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. 

§ 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 

§ 172.500 Applicability. 

This subpart establishes QHIN 

termination responsibilities, notice 

requirements for termination, and the 

effect of termination. 

§ 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. 

§ 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. 

§ 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 

§ 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. 

§ 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. 

§ 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] 

§ 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 


lotter on DSK11XQN23PROD with RULES3
101816 Federal Register / Vol. 89, No. 241 / Monday, December 16, 2024 / Rules and Regulations 

(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 § 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 § 172.606. 

§ 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 

§ 172.605(b). 

§ 172.605 Assignment of a hearing officer. 

(a) On receipt of an appeal under 

§ 172.603, ASTP/ONC may exercise its 

authority under § 172.601 to review an 

RCE determination being appealed. If 

ASTP/ONC exercises its authority under 

§ 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 

§ 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. 

§ 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 

§ 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. 

§ 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 

§ 172.700 Applicability. 

This subpart applies to QHINs. 

§ 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 

§ 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 


lotter on DSK11XQN23PROD with RULES3
Federal Register / Vol. 89, No. 241 / Monday, December 16, 2024 / Rules and Regulations 101817 

and not subject to further administrative 

review, except the Secretary may choose 

to review the determination as provided 

in § 172.607(b). However, a QHIN may, 

at any time, resubmit an attestation in 

accordance with paragraphs (b) and (c) 

of this section. 

§ 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 

§ 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 


lotter on DSK11XQN23PROD with RULES3