Health Data, Technology, and Interoperability: Trusted Exchange Framework and Common Agreement (TEFCA), 101772-101817 [2024-29163]
Download as PDF
<![CDATA[
101772
Federal Register / Vol. 89, No. 241 / Monday, December 16, 2024 / Rules and Regulations
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)
Assistant Secretary for
Technology Policy/Office of the
National Coordinator for Health
Information Technology, Department of
Health and Human Services (HHS).
ACTION: Final rule.
AGENCY:
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:
SUMMARY:
lotter on DSK11XQN23PROD with RULES3
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
VerDate Sep<11>2014
19:09 Dec 13, 2024
Jkt 265001
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
1 The Office of the National Coordinator for
Health Information Technology (ONC) was the
previous name of this office. See Federal Register:
Statement of Organization, Functions, and
Delegations of Authority; Office of The National
Coordinator for Health Information Technology (89
FR 60903, July 29, 2024).
2 Reasonable and necessary activities that do not
constitute information blocking, also known as
information blocking exceptions, are identified in
45 CFR part 171, subparts B, C and D. ASTP/ONC’s
official website, HealthIT.gov, offers a variety of
resources on the topic of Information Blocking,
including fact sheets, recorded webinars, and
frequently asked questions. To learn more, please
visit: https://www.healthit.gov/topic/informationblocking/.
PO 00000
Frm 00002
Fmt 4701
Sfmt 4700
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
3 Federal Register: Statement of Organization,
Functions, and Delegations of Authority; Office of
The National Coordinator for Health Information
Technology (89 FR 60903).
E:\FR\FM\16DER3.SGM
16DER3
Federal Register / Vol. 89, No. 241 / Monday, December 16, 2024 / Rules and Regulations
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
lotter on DSK11XQN23PROD with RULES3
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
4 https://www.hhs.gov/about/news/2024/07/10/
hhs-proposes-hti-2-rule-improve-patientengagement-information-sharing-public-healthinteroperability.html.
VerDate Sep<11>2014
19:09 Dec 13, 2024
Jkt 265001
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,
PO 00000
Frm 00003
Fmt 4701
Sfmt 4700
101773
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.
E:\FR\FM\16DER3.SGM
16DER3
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.
lotter on DSK11XQN23PROD with RULES3
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
VerDate Sep<11>2014
19:09 Dec 13, 2024
Jkt 265001
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
PO 00000
Frm 00004
Fmt 4701
Sfmt 4700
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
E:\FR\FM\16DER3.SGM
16DER3
lotter on DSK11XQN23PROD with RULES3
Federal Register / Vol. 89, No. 241 / Monday, December 16, 2024 / Rules and Regulations
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
VerDate Sep<11>2014
19:09 Dec 13, 2024
Jkt 265001
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.
PO 00000
Frm 00005
Fmt 4701
Sfmt 4700
101775
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,
E:\FR\FM\16DER3.SGM
16DER3
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.
lotter on DSK11XQN23PROD with RULES3
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.
VerDate Sep<11>2014
19:09 Dec 13, 2024
Jkt 265001
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
PO 00000
Frm 00006
Fmt 4701
Sfmt 4700
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’’
E:\FR\FM\16DER3.SGM
16DER3
Federal Register / Vol. 89, No. 241 / Monday, December 16, 2024 / Rules and Regulations
lotter on DSK11XQN23PROD with RULES3
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’’
VerDate Sep<11>2014
19:09 Dec 13, 2024
Jkt 265001
(§ 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.
PO 00000
Frm 00007
Fmt 4701
Sfmt 4700
101777
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).
E:\FR\FM\16DER3.SGM
16DER3
101778
Federal Register / Vol. 89, No. 241 / Monday, December 16, 2024 / Rules and Regulations
lotter on DSK11XQN23PROD with RULES3
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
VerDate Sep<11>2014
19:09 Dec 13, 2024
Jkt 265001
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.
PO 00000
Frm 00008
Fmt 4701
Sfmt 4700
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
E:\FR\FM\16DER3.SGM
16DER3
lotter on DSK11XQN23PROD with RULES3
Federal Register / Vol. 89, No. 241 / Monday, December 16, 2024 / Rules and Regulations
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
VerDate Sep<11>2014
19:09 Dec 13, 2024
Jkt 265001
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
PO 00000
Frm 00009
Fmt 4701
Sfmt 4700
101779
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
E:\FR\FM\16DER3.SGM
16DER3
lotter on DSK11XQN23PROD with RULES3
101780
Federal Register / Vol. 89, No. 241 / Monday, December 16, 2024 / Rules and Regulations
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
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.
VerDate Sep<11>2014
19:09 Dec 13, 2024
Jkt 265001
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
PO 00000
Frm 00010
Fmt 4701
Sfmt 4700
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
E:\FR\FM\16DER3.SGM
16DER3
lotter on DSK11XQN23PROD with RULES3
Federal Register / Vol. 89, No. 241 / Monday, December 16, 2024 / Rules and Regulations
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 TEFCA6 Node means a technical system that is
controlled directly or indirectly by a QHIN,
Participant, or Subparticipant and that is listed in
the RCE Directory Service.
VerDate Sep<11>2014
19:09 Dec 13, 2024
Jkt 265001
specific purpose of use code, meaning a
code that identifies the Exchange
Purpose for which exchange is
occurring. QHINs voluntarily agree to
follow certain organizational and
operational policies that allow
Participants (entities who have entered
into an agreement with the QHIN that
includes the Participant/Subparticipant
Terms of Participation) and
Subparticipants (entities that have
entered into an agreement with a
Participant or other Subparticipant that
includes the Participant/Subparticipant
Terms of Participation) to simplify their
operations and promote efficiency of
scale.
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
PO 00000
Frm 00011
Fmt 4701
Sfmt 4700
101781
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
7 Public
E:\FR\FM\16DER3.SGM
Law 104–191, 110 Stat. 1936.
16DER3
lotter on DSK11XQN23PROD with RULES3
101782
Federal Register / Vol. 89, No. 241 / Monday, December 16, 2024 / Rules and Regulations
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
VerDate Sep<11>2014
19:09 Dec 13, 2024
Jkt 265001
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.
8 QHIN Security Requirements for the Protection
of TEFCA Information SOP, https://
rce.sequoiaproject.org/wp-content/uploads/2024/
08/QHIN-Security-for-the-Protection-of-TI-21.pdf.
PO 00000
Frm 00012
Fmt 4701
Sfmt 4700
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
E:\FR\FM\16DER3.SGM
16DER3
lotter on DSK11XQN23PROD with RULES3
Federal Register / Vol. 89, No. 241 / Monday, December 16, 2024 / Rules and Regulations
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
VerDate Sep<11>2014
19:09 Dec 13, 2024
Jkt 265001
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
PO 00000
Frm 00013
Fmt 4701
Sfmt 4700
101783
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
E:\FR\FM\16DER3.SGM
16DER3
lotter on DSK11XQN23PROD with RULES3
101784
Federal Register / Vol. 89, No. 241 / Monday, December 16, 2024 / Rules and Regulations
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.
VerDate Sep<11>2014
19:09 Dec 13, 2024
Jkt 265001
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
PO 00000
Frm 00014
Fmt 4701
Sfmt 4700
better understand where exchange gaps
persist.
We understand that cost is a concern
for many organizations, particularly
small and rural providers. We continue
to engage with providers to understand
these concerns and providers’ needs
better and to develop strategies to assist
small and rural providers with TEFCA
implementation. We are also
developing, along with the RCE, various
resources to clarify various questions
about TEFCA participation and
implementation. We appreciate the
request that ASTP/ONC provide TEFCA
Participants more time to prepare when
new requirements are adopted as part of
updates to the Common Agreement or
when SOPs are updated and will
consider the request as we work to
expand TEFCA Exchange and update
TEFCA requirements over time.
We also appreciate the
recommendation that ASTP/ONC and
the RCE establish steps and goals to
guide how entities will transition to
TEFCA participation and agree that
ASTP/ONC and the RCE should provide
resources and information to support
the transition to TEFCA Exchange. As
such, ASTP/ONC and the RCE have
recently released a plethora of resources
to assist entities considering
transitioning to TEFCA Exchange,
which are available on the ASTP/ONC 9
and RCE 10 websites. In addition, we
continue to support the transition to
TEFCA Exchange through regular
webinars and information sessions for
the public.
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
9 https://www.healthit.gov/topic/interoperability/
policy/trusted-exchange-framework-and-commonagreement-tefca.
10 https://rce.sequoiaproject.org/tefca/.
E:\FR\FM\16DER3.SGM
16DER3
lotter on DSK11XQN23PROD with RULES3
Federal Register / Vol. 89, No. 241 / Monday, December 16, 2024 / Rules and Regulations
and participate in TEFCA with at least
one QHIN.
Response. We thank the commenter
for their feedback. This comment is out
of scope for this rulemaking, and
therefore, we decline to adopt this
suggested change. We also note that we
generally believe that participation in
TEFCA should remain voluntary and
decline to mandate TEFCA
participation.
Comments. A number of commenters
expressed concern about the
interactions of TEFCA requirements
with HIPAA requirements, and with
other ASTP/ONC and CMS regulations
creating an overly complex regulatory
framework for interoperability.
Commenters urged ASTP/ONC to
ensure that TEFCA requirements are
compatible with other interoperability
and information blocking rulemaking.
Another commenter also urged ASTP/
ONC to collaborate with CMS to provide
endpoint directories and use RESTful
FHIR interoperability protocols.
These commenters noted the
importance of keeping TEFCA
participation voluntary. A few
commenters expressed concern that the
TEFCA requirements proposed together
with other ASTP/ONC and CMS
regulations will pressure entities to
solely engage with entities connected to
TEFCA.
Response. We thank commenters for
their feedback and appreciate
commenters’ concerns about how
TEFCA requirements will interact with
other regulatory requirements. ASTP/
ONC has worked, and will continue to
work, with our Federal partners,
including CMS, in developing and
implementing TEFCA. We are working
to align TEFCA requirements with other
ASTP/ONC, CMS, and OCR 11
requirements when possible, and while
we have not required any entity to
participate in TEFCA, we are trying to
ensure that TEFCA complements other
Federal requirements to reduce
complexity and encourage more
seamless nationwide exchange. For
example, as explained in more detail
above, entities are able to comply with
both HIPAA (HIPAA Privacy, Security,
and Breach Notification Rules) and
TEFCA. While ASTP/ONC may develop
definitions and requirements within
TEFCA that are narrower or broader
than corresponding definitions and
requirements within the HIPAA Rules,
ASTP/ONC does try to align TEFCA
requirements with the requirements in
the HIPAA Rules when possible.
11 The HHS Office for Civil Rights has authority
for implementing and enforcing HIPAA.
VerDate Sep<11>2014
19:09 Dec 13, 2024
Jkt 265001
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.
PO 00000
Frm 00015
Fmt 4701
Sfmt 4700
101785
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.
E:\FR\FM\16DER3.SGM
16DER3
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
VerDate Sep<11>2014
19:09 Dec 13, 2024
Jkt 265001
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
PO 00000
Frm 00016
Fmt 4701
Sfmt 4700
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.,
E:\FR\FM\16DER3.SGM
16DER3
lotter on DSK11XQN23PROD with RULES3
Federal Register / Vol. 89, No. 241 / Monday, December 16, 2024 / Rules and Regulations
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
VerDate Sep<11>2014
19:09 Dec 13, 2024
Jkt 265001
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
PO 00000
Frm 00017
Fmt 4701
Sfmt 4700
101787
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.
E:\FR\FM\16DER3.SGM
16DER3
lotter on DSK11XQN23PROD with RULES3
101788
Federal Register / Vol. 89, No. 241 / Monday, December 16, 2024 / Rules and Regulations
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
VerDate Sep<11>2014
19:09 Dec 13, 2024
Jkt 265001
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.
PO 00000
Frm 00018
Fmt 4701
Sfmt 4700
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,
12 Common Agreement for Nationwide Health
Information Interoperability (healthit.gov).
13 Id.
14 Id.
E:\FR\FM\16DER3.SGM
16DER3
lotter on DSK11XQN23PROD with RULES3
Federal Register / Vol. 89, No. 241 / Monday, December 16, 2024 / Rules and Regulations
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
VerDate Sep<11>2014
19:09 Dec 13, 2024
Jkt 265001
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
PO 00000
Frm 00019
Fmt 4701
Sfmt 4700
101789
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,
E:\FR\FM\16DER3.SGM
16DER3
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
VerDate Sep<11>2014
19:09 Dec 13, 2024
Jkt 265001
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
PO 00000
Frm 00020
Fmt 4701
Sfmt 4700
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
E:\FR\FM\16DER3.SGM
16DER3
lotter on DSK11XQN23PROD with RULES3
Federal Register / Vol. 89, No. 241 / Monday, December 16, 2024 / Rules and Regulations
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
VerDate Sep<11>2014
19:09 Dec 13, 2024
Jkt 265001
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.
PO 00000
Frm 00021
Fmt 4701
Sfmt 4700
101791
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,
E:\FR\FM\16DER3.SGM
16DER3
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.
VerDate Sep<11>2014
19:09 Dec 13, 2024
Jkt 265001
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.
PO 00000
Frm 00022
Fmt 4701
Sfmt 4700
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
E:\FR\FM\16DER3.SGM
16DER3
lotter on DSK11XQN23PROD with RULES3
Federal Register / Vol. 89, No. 241 / Monday, December 16, 2024 / Rules and Regulations
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
VerDate Sep<11>2014
19:09 Dec 13, 2024
Jkt 265001
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
PO 00000
Frm 00023
Fmt 4701
Sfmt 4700
101793
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
15 Notice of Funding Opportunity (NOFO)—
Trusted Exchange Framework and Common
Agreement—Recognized Coordination Entity (RCE)
Cooperative Agreement, https://www.healthit.gov/
sites/default/files/facas/TEFCA%20NOFO_FINAL_
508.pdf.
16 See USASPENDING.gov, https://
www.usaspending.gov/award/CONT_AWD_
75P00123C00019_7570_-NONE-_-NONE-.
17 87 FR 2822.
18 87 FR 2818.
E:\FR\FM\16DER3.SGM
16DER3
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
VerDate Sep<11>2014
19:09 Dec 13, 2024
Jkt 265001
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.
PO 00000
Frm 00024
Fmt 4701
Sfmt 4700
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
E:\FR\FM\16DER3.SGM
16DER3
lotter on DSK11XQN23PROD with RULES3
Federal Register / Vol. 89, No. 241 / Monday, December 16, 2024 / Rules and Regulations
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
VerDate Sep<11>2014
19:09 Dec 13, 2024
Jkt 265001
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
PO 00000
Frm 00025
Fmt 4701
Sfmt 4700
101795
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
E:\FR\FM\16DER3.SGM
16DER3
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
VerDate Sep<11>2014
19:09 Dec 13, 2024
Jkt 265001
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
PO 00000
Frm 00026
Fmt 4701
Sfmt 4700
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
E:\FR\FM\16DER3.SGM
16DER3
lotter on DSK11XQN23PROD with RULES3
Federal Register / Vol. 89, No. 241 / Monday, December 16, 2024 / Rules and Regulations
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.
19 XP Implementation: Treatment, https://
rce.sequoiaproject.org/wp-content/uploads/2024/
07/SOP-Treatment-XP-Implementation_508.pdf.
VerDate Sep<11>2014
19:09 Dec 13, 2024
Jkt 265001
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
PO 00000
Frm 00027
Fmt 4701
Sfmt 4700
101797
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
E:\FR\FM\16DER3.SGM
16DER3
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
VerDate Sep<11>2014
19:09 Dec 13, 2024
Jkt 265001
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
PO 00000
Frm 00028
Fmt 4701
Sfmt 4700
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
E:\FR\FM\16DER3.SGM
16DER3
lotter on DSK11XQN23PROD with RULES3
Federal Register / Vol. 89, No. 241 / Monday, December 16, 2024 / Rules and Regulations
‘‘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
VerDate Sep<11>2014
19:09 Dec 13, 2024
Jkt 265001
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
PO 00000
Frm 00029
Fmt 4701
Sfmt 4700
101799
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
E:\FR\FM\16DER3.SGM
16DER3
101800
Federal Register / Vol. 89, No. 241 / Monday, December 16, 2024 / Rules and Regulations
lotter on DSK11XQN23PROD with RULES3
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
VerDate Sep<11>2014
19:09 Dec 13, 2024
Jkt 265001
(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,
PO 00000
Frm 00030
Fmt 4701
Sfmt 4700
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
E:\FR\FM\16DER3.SGM
16DER3
Federal Register / Vol. 89, No. 241 / Monday, December 16, 2024 / Rules and Regulations
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.
lotter on DSK11XQN23PROD with RULES3
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
VerDate Sep<11>2014
19:09 Dec 13, 2024
Jkt 265001
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.
20 See Common Agreement section 3.1, 89 FR
35107 (May 1, 2024), https://
www.federalregister.gov/documents/2024/05/01/
2024-09476/notice-of-publication-of-commonagreement-for-nationwide-health-informationinteroperability-common.
PO 00000
Frm 00031
Fmt 4701
Sfmt 4700
101801
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
E:\FR\FM\16DER3.SGM
16DER3
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
VerDate Sep<11>2014
19:09 Dec 13, 2024
Jkt 265001
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
PO 00000
Frm 00032
Fmt 4701
Sfmt 4700
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
E:\FR\FM\16DER3.SGM
16DER3
lotter on DSK11XQN23PROD with RULES3
Federal Register / Vol. 89, No. 241 / Monday, December 16, 2024 / Rules and Regulations
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
VerDate Sep<11>2014
19:09 Dec 13, 2024
Jkt 265001
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.
PO 00000
Frm 00033
Fmt 4701
Sfmt 4700
101803
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
E:\FR\FM\16DER3.SGM
16DER3
101804
Federal Register / Vol. 89, No. 241 / Monday, December 16, 2024 / Rules and Regulations
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.
lotter on DSK11XQN23PROD with RULES3
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
21 The Trusted Exchange Framework (TEF):
Principles for Trusted Exchange (January 2022),
https://www.healthit.gov/sites/default/files/page/
2022-01/Trusted_Exchange_Framework_0122.pdf.
VerDate Sep<11>2014
19:09 Dec 13, 2024
Jkt 265001
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
PO 00000
Frm 00034
Fmt 4701
Sfmt 4700
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
E:\FR\FM\16DER3.SGM
16DER3
lotter on DSK11XQN23PROD with RULES3
Federal Register / Vol. 89, No. 241 / Monday, December 16, 2024 / Rules and Regulations
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
VerDate Sep<11>2014
19:09 Dec 13, 2024
Jkt 265001
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,
PO 00000
Frm 00035
Fmt 4701
Sfmt 4700
101805
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
E:\FR\FM\16DER3.SGM
16DER3
101806
Federal Register / Vol. 89, No. 241 / Monday, December 16, 2024 / Rules and Regulations
lotter on DSK11XQN23PROD with RULES3
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
VerDate Sep<11>2014
19:09 Dec 13, 2024
Jkt 265001
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
PO 00000
Frm 00036
Fmt 4701
Sfmt 4700
§§ 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
E:\FR\FM\16DER3.SGM
16DER3
Federal Register / Vol. 89, No. 241 / Monday, December 16, 2024 / Rules and Regulations
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.
101807
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
Number of
applicant
QHIN or
QHINs
Code of Federal Regulations section
Total
45 CFR 172.301 ..........................................................................................................................
45 CFR 172.701 ..........................................................................................................................
15
15
1
1
15
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.
lotter on DSK11XQN23PROD with RULES3
Average
burden hours
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
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
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
22 According to the May 2022 Bureau of Labor
Statistics occupational employment statistics, the
mean hourly wage for Office Clerks, General (43–
9061) is $19.78.
VerDate Sep<11>2014
19:09 Dec 13, 2024
Jkt 265001
PO 00000
Frm 00037
Fmt 4701
Sfmt 4700
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
E:\FR\FM\16DER3.SGM
16DER3
101808
Federal Register / Vol. 89, No. 241 / Monday, December 16, 2024 / Rules and Regulations
lotter on DSK11XQN23PROD with RULES3
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
VerDate Sep<11>2014
19:09 Dec 13, 2024
Jkt 265001
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
23 The
SBA references that annual receipts mean
‘‘total income’’ (or in the case of a sole
proprietorship, ‘‘gross income’’) plus ‘‘cost of goods
sold’’ as these terms are defined and reported on
Internal Revenue Service tax return forms.
PO 00000
Frm 00038
Fmt 4701
Sfmt 4700
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
24 https://www.sba.gov/sites/sbagov/files/202306/Table%20of%20Size%20Standards_
Effective%20March%2017%2C%202023
%20%282%29.pdf.
25 https://www.sba.gov/article/2022/feb/01/
guidance-using-naics-2022-procurement.
E:\FR\FM\16DER3.SGM
16DER3
Federal Register / Vol. 89, No. 241 / Monday, December 16, 2024 / Rules and Regulations
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
List of Subjects
lotter on DSK11XQN23PROD with RULES3
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
19:09 Dec 13, 2024
Jkt 265001
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:
■
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.
VerDate Sep<11>2014
health, Reporting and recordkeeping
requirements, Security.
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).
PO 00000
Frm 00039
Fmt 4701
Sfmt 4700
101809
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:
E:\FR\FM\16DER3.SGM
16DER3
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:
■
lotter on DSK11XQN23PROD with RULES3
9. Amend § 171.101 by adding
paragraph (c) to read as follows:
■
Applicability.
*
*
*
*
*
(c) If any provision of this part is held
to be invalid or unenforceable facially,
VerDate Sep<11>2014
19:09 Dec 13, 2024
Jkt 265001
§ 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.
Authority: 42 U.S.C. 300jj–52; 5 U.S.C.
552.
§ 171.101
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:
Subpart F—Review of RCE or ASTP/ONC
Decisions
172.600 Applicability.
172.601 ASTP/ONC review.
PO 00000
Frm 00040
Fmt 4701
Sfmt 4700
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
E:\FR\FM\16DER3.SGM
16DER3
Federal Register / Vol. 89, No. 241 / Monday, December 16, 2024 / Rules and Regulations
situated or to other dissimilar
circumstances.
lotter on DSK11XQN23PROD with RULES3
§ 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
VerDate Sep<11>2014
19:09 Dec 13, 2024
Jkt 265001
(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).
PO 00000
Frm 00041
Fmt 4701
Sfmt 4700
101811
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.
E:\FR\FM\16DER3.SGM
16DER3
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.
VerDate Sep<11>2014
19:09 Dec 13, 2024
Jkt 265001
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
PO 00000
Frm 00042
Fmt 4701
Sfmt 4700
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
E:\FR\FM\16DER3.SGM
16DER3
Federal Register / Vol. 89, No. 241 / Monday, December 16, 2024 / Rules and Regulations
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.
lotter on DSK11XQN23PROD with RULES3
§ 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:
VerDate Sep<11>2014
19:09 Dec 13, 2024
Jkt 265001
(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:
PO 00000
Frm 00043
Fmt 4701
Sfmt 4700
101813
(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
E:\FR\FM\16DER3.SGM
16DER3
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.
lotter on DSK11XQN23PROD with RULES3
§ 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.
VerDate Sep<11>2014
19:09 Dec 13, 2024
Jkt 265001
§ 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).
PO 00000
Frm 00044
Fmt 4701
Sfmt 4700
(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.
E:\FR\FM\16DER3.SGM
16DER3
Federal Register / Vol. 89, No. 241 / Monday, December 16, 2024 / Rules and Regulations
(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.
lotter on DSK11XQN23PROD with RULES3
(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.
VerDate Sep<11>2014
19:09 Dec 13, 2024
Jkt 265001
§ 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/
PO 00000
Frm 00045
Fmt 4701
Sfmt 4700
101815
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
appeal.
Method and timing for filing an
(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
E:\FR\FM\16DER3.SGM
16DER3
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).
lotter on DSK11XQN23PROD with RULES3
§ 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
VerDate Sep<11>2014
19:09 Dec 13, 2024
Jkt 265001
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
officer.
Determination by the hearing
(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.
PO 00000
Frm 00046
Fmt 4701
Sfmt 4700
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
E:\FR\FM\16DER3.SGM
16DER3
Federal Register / Vol. 89, No. 241 / Monday, December 16, 2024 / Rules and Regulations
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.
lotter on DSK11XQN23PROD with RULES3
(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
VerDate Sep<11>2014
19:09 Dec 13, 2024
Jkt 265001
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
PO 00000
Frm 00047
Fmt 4701
Sfmt 9990
101817
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
E:\FR\FM\16DER3.SGM
16DER3
]]>Agencies
[Federal Register Volume 89, Number 241 (Monday, December 16, 2024)]
[Rules and Regulations]
[Pages 101772-101817]
From the Federal Register Online via the Government Publishing Office [www.gpo.gov]
[FR Doc No: 2024-29163]
[[Page 101771]]
Vol. 89
Monday,
No. 241
December 16, 2024
Part III
Department of Health and Human Services
-----------------------------------------------------------------------
45 CFR Parts 170, 171, and 172
Health Data, Technology, and Interoperability: Trusted Exchange
Framework and Common Agreement (TEFCA); Final Rule
Federal Register / Vol. 89, No. 241 / Monday, December 16, 2024 /
Rules and Regulations
[[Page 101772]]
-----------------------------------------------------------------------
DEPARTMENT OF HEALTH AND HUMAN SERVICES
Office of the Secretary
45 CFR Parts 170, 171, and 172
RIN 0955-AA07
Health Data, Technology, and Interoperability: Trusted Exchange
Framework and Common Agreement (TEFCA)
AGENCY: Assistant Secretary for Technology Policy/Office of the
National Coordinator for Health Information Technology, Department of
Health and Human Services (HHS).
ACTION: Final rule.
-----------------------------------------------------------------------
SUMMARY: This final rule has finalized certain proposals from a
proposed rule published in August 2024 and in doing so advances
interoperability and supports the access, exchange, and use of
electronic health information. Specifically, this final rule amends the
information blocking regulations by including definitions related to
the Trusted Exchange Framework and Common Agreement (TEFCA) Manner
Exception. It also implements provisions related to the TEFCA, which
will support the reliability, privacy, security, and trust within
TEFCA. Lastly, this final rule includes corrections and updates to
current regulatory provisions of the Office of the National Coordinator
for Health Information Technology (ONC) Health IT Certification
Program.
DATES: This final rule is effective on January 15, 2025.
FOR FURTHER INFORMATION CONTACT: Kate Tipping, Office of Policy,
Assistant Secretary for Technology Policy (ASTP)/Office of the National
Coordinator for Health Information Technology, 202-690-7151.
SUPPLEMENTARY INFORMATION:
Table of Contents
I. Executive Summary
A. Purpose of Regulatory Action
B. Summary of Major Provisions
1. ONC Health IT Certification Program
a. Administrative Updates
b. Correction--Privacy and Security Certification Framework
2. Information Blocking Enhancements
3. Trusted Exchange Framework and Common Agreement\TM\
C. Costs and Benefits
II. Background
A. Statutory Basis
B. Regulatory History
III. ONC Health IT Certification Program
A. Administrative Updates
1. Updates Pursuant to 2014 Edition Removal
a. Removal of ``Complete EHR'' References
b. Removal of ``EHR Modules'' References
2. Removal of Time-Limited Criteria
3. Privacy and Security Framework Incorporation of DSI Criterion
B. Correction--Privacy and Security Certification Framework
IV. Information Blocking Enhancements--Part 171, Subpart D (TEFCA)
A. Definitions
B. TEFCA\TM\ Manner Exception
V. Trusted Exchange Framework and Common Agreement\TM\
A. Subpart A--General Provisions
B. Subpart B--Qualifications for Designation
C. Subpart C--QHIN\TM\ Onboarding and Designation Processes
D. Subpart D--Suspension
E. Subpart E--Termination
F. Subpart F--Review of RCE[supreg] or ASTP/ONC Decisions
G. Subpart G--QHIN\TM\ Attestation for the Adoption of the
Trusted Exchange Framework and Common Agreement\TM\
VI. Severability
VII. Collection of Information Requirements--Qualified Health
Information Networks\TM\
VIII. Regulatory Impact Analysis
A. Statement of Need
B. Alternatives Considered
C. Overall Impact--Executive Orders 12866 and 13563--Regulatory
Planning and Review Analysis
D. Regulatory Flexibility Act
E. Executive Order 13132--Federalism
F. Unfunded Mandates Reform Act of 1995
I. Executive Summary
A. Purpose of Regulatory Action
The Secretary of Health and Human Services has delegated
responsibilities to the Assistant Secretary for Technology Policy and
Office of the National Coordinator for Health Information Technology
(hereafter ASTP/ONC) \1\ for the implementation of certain provisions
in Title IV of the 21st Century Cures Act (Pub. L. 114-255, Dec. 13,
2016) (Cures Act) that are designed to: advance interoperability;
support the access, exchange, and use of electronic health information
(EHI); and identify reasonable and necessary activities that do not
constitute information blocking.\2\ ASTP/ONC is responsible for the
implementation of certain provisions of the Health Information
Technology for Economic and Clinical Health Act (Pub. L. 111-5, Feb.
17, 2009) (HITECH Act) including: requirements that the National
Coordinator perform duties consistent with the development of a
nationwide health information technology infrastructure that allows for
the electronic use and exchange of information and that promotes a more
effective marketplace, greater competition, and increased consumer
choice, among other goals. This final rule fulfills statutory
requirements; advances equity, innovation, and interoperability; and
supports the access to, and exchange and use of, EHI.
---------------------------------------------------------------------------
\1\ The Office of the National Coordinator for Health
Information Technology (ONC) was the previous name of this office.
See Federal Register: Statement of Organization, Functions, and
Delegations of Authority; Office of The National Coordinator for
Health Information Technology (89 FR 60903, July 29, 2024).
\2\ Reasonable and necessary activities that do not constitute
information blocking, also known as information blocking exceptions,
are identified in 45 CFR part 171, subparts B, C and D. ASTP/ONC's
official website, HealthIT.gov, offers a variety of resources on the
topic of Information Blocking, including fact sheets, recorded
webinars, and frequently asked questions. To learn more, please
visit: https://www.healthit.gov/topic/information-blocking/.
---------------------------------------------------------------------------
B. Summary of Major Provisions
General Comments
We received approximately 270 comment submissions on the broad
range of proposals included in the ``Health Data, Technology, and
Interoperability: Patient Engagement, Information Sharing, and Public
Health Interoperability'' proposed rule (HTI-2 Proposed Rule) (89 FR
63498). We thank all commenters for their thoughtful input. For the
purposes of this final rule, we have reviewed and responded to comments
on a narrowed set of proposals. Specifically, we summarize and respond
to comments related to the Trusted Exchange Framework and Common
Agreement (TEFCA) information blocking exception and part 172
proposals, and a limited set of the proposed ONC Health IT
Certification Program (Program) administrative updates. Comments
received in response to other proposals from the HTI-2 Proposed Rule
are beyond the scope of this final rule, are still being reviewed and
considered, and may be the subject of subsequent final rules related to
such proposals in the future.
As discussed above, the name of the office changed from the Office
of the National Coordinator for Health Information Technology (ONC) to
now be dually titled as the Assistant Secretary for Technology Policy
and Office of the National Coordinator for Health Information
Technology (ASTP/ONC) per the Federal Register notice released on July
29, 2024.\3\ When the HTI-2 Proposed Rule appeared in the Federal
Register on August 5, 2024, it referred to the office as ``ONC.'' It
was not until days after the HTI-2 Proposed Rule had been released to
the public (on
[[Page 101773]]
July 10, 2024) \4\ that the name officially changed. Accordingly, where
we referred to ``ONC'' in the HTI-2 Proposed Rule, we continue to refer
to ``ONC'' when referencing the HTI-2 Proposed Rule in this final rule.
However, in the comment summaries, responses, and regulatory text of
this final rule, we have revised those references to refer to ``ASTP/
ONC.'' In this final rule, we acknowledge these changes where we have
finalized regulatory text as proposed except for the changed reference
to ``ASTP/ONC.'' We note that this change is technical in nature and
does not affect any substantive rights or obligations.
---------------------------------------------------------------------------
\3\ Federal Register: Statement of Organization, Functions, and
Delegations of Authority; Office of The National Coordinator for
Health Information Technology (89 FR 60903).
\4\ https://www.hhs.gov/about/news/2024/07/10/hhs-proposes-hti-2-rule-improve-patient-engagement-information-sharing-public-health-interoperability.html.
---------------------------------------------------------------------------
1. ONC Health IT Certification Program
a. Administrative Updates
In section III.A.1, we discuss the removal of the ``Complete EHR''
and ``EHR Module'' terms from certain sections within subpart E of 45
CFR part 170.
As discussed in section III.A.2, we have removed from 45 CFR part
170, Sec. 170.550(m), ``Time-limited certification and certification
status for certain ONC Certification Criteria for Health IT,'' and
removed the certification criteria with time-limited certification and
certification status, including Sec. 170.315(a)(10) and (13), (b)(6),
(e)(2), and (g)(8). Additionally, as discussed in section III.A.2, we
have revised Sec. 170.315(b)(7) and (8) to remove Sec.
170.315(b)(7)(ii) and (b)(8)(i)(B), which were time-limited provisions
(now expired) that permitted health IT to demonstrate security tagging
of Consolidated-Clinical Document Architecture (C-CDA) documents at the
document level. In section III.A.3, we discuss the final revision of
Sec. 170.550(h), the Privacy and Security Certification Framework
requirements, that adds the certification criterion ``decision support
interventions'' (Sec. 170.315(b)(11)) to the list of certification
criteria in Sec. 170.550(h)(3)(ii).
b. Correction--Privacy and Security Certification Framework
We have finalized a correction to the Privacy and Security
Certification Framework in Sec. 170.550(h). As discussed in section
III.B, we have added Sec. 170.550(h)(4) that existed prior to the
``21st Century Cures Act: Interoperability, Information Blocking, and
the ONC Health IT Certification Program'' final rule (85 FR 25642, May
1, 2020) (ONC Cures Act Final Rule) being finalized but was erroneously
deleted.
2. Information Blocking Enhancements
In this final rule, with consideration of public comments, we have
finalized the TEFCA Manner Exception in subpart D of part 171 with no
revisions. We have also codified definitions of certain terms relevant
to the Trusted Exchange Framework and Common Agreement\TM\ (TEFCA\TM\)
in Sec. 171.401.
3. Trusted Exchange Framework and Common Agreement\TM\
As discussed in this final rule, we have codified (in new 45 CFR
part 172) provisions related to TEFCA to provide greater process
transparency and to further implement section 3001(c)(9) of the PHSA,
as added by the Cures Act. The finalized 45 CFR part 172 establishes
the processes associated with the qualifications necessary for an
entity to receive and maintain Designation (as defined in Sec.
172.102) as a Qualified Health Information Network (QHIN) capable of
trusted exchange under the Common Agreement. The final provisions
codified in part 172 also establish the procedures governing Onboarding
(as defined in Sec. 172.102) of QHINs and Designation of QHINs,
suspension, termination, and administrative appeals to ASTP/ONC, as
described in Sec. 172.100(c)(1) of this final rule. We believe
establishing these provisions in regulation support reliability,
privacy, security, and trust within TEFCA, which furthers our
obligations to ``support'' TEFCA under sections 3001(c)(9)(A) and (B)
of the PHSA and TEFCA's ultimate success. In addition, in subpart G of
part 172, we have codified requirements related to QHIN attestation for
the adoption of TEFCA. This subpart implements section 3001(c)(9)(D) of
the PHSA. Section 3001(c)(9)(D)(i) requires the publication on ASTP/
ONC's website of a list of the health information networks (HINs) that
have adopted the Common Agreement and are capable of trusted exchange
pursuant to the Common Agreement. Section 3001(c)(9)(D)(ii) requires
HHS to establish, through notice and comment rulemaking, a process for
HINs that voluntarily elect to adopt TEFCA to attest to such adoption.
C. Costs and Benefits
Executive Orders 12866 and 13563 direct agencies to assess all
costs and benefits of available regulatory alternatives and, if
regulation is necessary, to select regulatory approaches that maximize
net benefits (including potential economic, environmental, public
health and safety effects, distributive impacts, and equity). Executive
Order 14094 (Modernizing Regulatory Review) amends section 3(f) of
Executive Order 12866 (Regulatory Planning and Review). The amended
section 3(f) of Executive Order 12866 defines a ``significant
regulatory action.'' The Office of Management and Budget's (OMB) Office
of Information and Regulatory Affairs (OIRA) has determined that this
final rule is not a significant regulatory action under section 3(f) of
Executive Order 12866. Accordingly, we have not prepared a detailed
Regulatory Impact Analysis (RIA). We did, however, include some
quantitative analysis of the costs and benefits of this final rule.
II. Background
A. Statutory Basis
The Health Information Technology for Economic and Clinical Health
Act (HITECH Act), Title XIII of Division A and Title IV of Division B
of the American Recovery and Reinvestment Act of 2009 (Pub. L. 111-5),
was enacted on February 17, 2009. The HITECH Act amended the Public
Health Service Act (PHSA) and created ``Title XXX--Health Information
Technology and Quality'' (Title XXX) to improve healthcare quality,
safety, and efficiency through the promotion of health IT and EHI
exchange.
The 21st Century Cures Act (Pub. L. 114-255) (Cures Act) was
enacted on December 13, 2016, to accelerate the discovery, development,
and delivery of 21st century cures, and for other purposes. The Cures
Act, through Title IV--Delivery, amended the HITECH Act by modifying or
adding certain provisions to the PHSA relating to health IT.
ONC Health IT Certification Program Rules
Section 3001(c)(5) of the PHSA provides the National Coordinator
with the authority to establish a certification program or programs for
the voluntary certification of health IT. Section 3001(c)(5)(A)
specifies that the National Coordinator, in consultation with the
Director of the National Institute of Standards and Technology (NIST),
shall keep or recognize a program or programs for the voluntary
certification of health IT that is in compliance with applicable
certification criteria adopted under section 3004 of the PHSA.
[[Page 101774]]
Information Blocking Under the 21st Century Cures Act
Section 4004 of the Cures Act added section 3022 of the Public
Health Service Act (PHSA) (42 U.S.C. 300jj-52, ``the information
blocking provision''). Section 3022(a)(1) of the PHSA defines practices
that constitute information blocking when engaged in by a health care
provider, or a health information technology developer, exchange, or
network. Section 3022(a)(3) authorizes the Secretary to identify,
through notice and comment rulemaking, reasonable and necessary
activities that do not constitute information blocking for purposes of
the definition set forth in section 3022(a)(1).
Trusted Exchange Framework and Common Agreement
Section 4003(b) of the Cures Act added section 3001(c)(9)(B)(i) to
the PHSA, which requires the National Coordinator ``to convene
appropriate public and private stakeholders'' with the goal of
developing or supporting a Trusted Exchange Framework and a Common
Agreement (collectively, TEFCA) for the purpose of ensuring full
network-to-network exchange of health information. Section
3001(c)(9)(B) outlines provisions related to the establishment of a
Trusted Exchange Framework for trust policies and practices and a
Common Agreement for exchange between health information networks
(HINs)--including provisions for the National Coordinator, in
collaboration with the NIST, to provide technical assistance on
implementation and pilot testing of TEFCA. Section 3001(c)(9)(C)
requires the National Coordinator to publish TEFCA on its website and
in the Federal Register. Section 3001(c)(9)(D)(i) requires the National
Coordinator to publish a list of HINs that have adopted TEFCA. Section
3001(c)(9)(D)(ii) requires the Secretary to establish a process for
HINs to attest that they have adopted TEFCA.
B. Regulatory History
The Secretary issued an interim final rule with request for
comments on January 13, 2010, ``Health Information Technology: Initial
Set of Standards, Implementation Specifications, and Certification
Criteria for Electronic Health Record Technology'' (75 FR 2014), which
adopted an initial set of standards, implementation specifications, and
certification criteria. On March 10, 2010, the Secretary issued a
proposed rule, ``Proposed Establishment of Certification Programs for
Health Information Technology'' (75 FR 11328), that proposed both
temporary and permanent certification programs for the purposes of
testing and certifying health IT. A final rule establishing the
temporary certification program was published on June 24, 2010,
``Establishment of the Temporary Certification Program for Health
Information Technology'' (75 FR 36158), and a final rule establishing
the permanent certification program was published on January 7, 2011,
``Establishment of the Permanent Certification Program for Health
Information Technology'' (76 FR 1262).
We have engaged in multiple rulemakings to update standards,
implementation specifications, certification criteria, and the Program,
a history of which can be found in the October 16, 2015, final rule,
``2015 Edition Health Information (Health IT) Certification Criteria,
2015 Edition Base Electronic Health Record (EHR) Definition, and ONC
Health IT Certification Program Modifications'' (80 FR 62602) (2015
Edition Final Rule). The history can be found at 80 FR 62606. A final
rule making corrections and clarifications was published for the 2015
Edition Final Rule on December 11, 2015 (80 FR 76868), to correct
preamble and regulatory text errors and clarify requirements of the
Common Clinical Data Set (CCDS), the 2015 Edition privacy and security
certification framework, and the mandatory disclosures for health IT
developers.
The 2015 Edition Final Rule established a new edition of
certification criteria (``2015 Edition health IT certification
criteria'' or ``2015 Edition'') and a new 2015 Edition Base EHR
definition. The 2015 Edition established the minimum capabilities and
specified the related minimum standards and implementation
specifications that Certified EHR Technology (CEHRT) would need to
include to support the achievement of ``meaningful use'' by eligible
clinicians, eligible hospitals, and critical access hospitals under the
Medicare and Medicaid EHR Incentive Programs (EHR Incentive Programs)
(now referred to as the Promoting Interoperability Programs and the
Promoting Interoperability performance category under MIPS) when the
2015 Edition is required for use under these and other programs
referencing the CEHRT definition. The final rule also adopted a
proposal to change the Program's name to the ``ONC Health IT
Certification Program'' from the ONC HIT Certification Program,
modified the Program to make it more accessible to other types of
health IT beyond EHR technology and for health IT that supports care
and practice settings beyond the ambulatory and inpatient settings, and
adopted new and revised Principles of Proper Conduct (PoPC) for ONC-
ACBs.
After issuing a proposed rule on March 2, 2016, ``ONC Health IT
Certification Program: Enhanced Oversight and Accountability'' (81 FR
11056), we published a final rule by the same title (81 FR 72404) (EOA
Final Rule) on October 19, 2016. The EOA Final Rule finalized
modifications and new requirements under the Program, including
provisions related to our role in the Program. The final rule created a
regulatory framework for our direct review of health IT certified under
the Program, including, when necessary, requiring the correction of
non-conformities found in health IT certified under the Program and
suspending and terminating certifications issued to Complete EHRs and
Health IT Modules. The final rule also set forth processes for us to
authorize and oversee accredited testing laboratories under the
Program. In addition, it included provisions for expanded public
availability of certified health IT surveillance results.
On March 4, 2019, the Secretary published a proposed rule titled
``21st Century Cures Act: Interoperability, Information Blocking, and
the ONC Health IT Certification Program'' (84 FR 7424) (ONC Cures Act
Proposed Rule). The proposed rule proposed to implement certain
provisions of the Cures Act that would advance interoperability and
support the access, exchange, and use of electronic health information.
We also requested comment in the ONC Cures Act Proposed Rule (84 FR
7467) as to whether certain health IT developers should be required to
participate in TEFCA as a means of providing assurances to their
customers and ONC that they are not taking actions that constitute
information blocking or any other action that may inhibit the
appropriate exchange, access, and use of EHI, with the goal of
developing or supporting TEFCA for the purpose of ensuring full
network-to-network exchange of health information.
On May 1, 2020, the ONC Cures Act Final Rule was published (85 FR
25642). The final rule implemented certain provisions of the Cures Act,
including Conditions and Maintenance of Certification requirements for
health IT developers, the voluntary certification of health IT for use
by pediatric health providers, and reasonable and necessary activities
that do not constitute information blocking. The final rule also
implemented certain parts of the Cures Act to support patients' access
to their EHI, and the implementation of
[[Page 101775]]
information blocking policies that support patient electronic access.
Additionally, the final rule modified the 2015 Edition health IT
certification criteria and Program in other ways to advance
interoperability, enhance health IT certification, and reduce burden
and costs, as well as improving patient and health care provider access
to EHI and promoting competition. On November 4, 2020, the Secretary
published an interim final rule with comment period titled
``Information Blocking and the ONC Health IT Certification Program:
Extension of Compliance Dates and Timeframes in Response to the COVID-
19 Public Health Emergency'' (85 FR 70064) (Cures Act Interim Final
Rule). The interim final rule extended certain compliance dates and
timeframes adopted in the ONC Cures Act Final Rule to offer the
healthcare system additional flexibilities in furnishing services to
combat the COVID-19 pandemic, including extending the applicability
date for information blocking provisions to April 5, 2021.
On April 18, 2023, the Secretary published a proposed rule titled
``Health Data, Technology, and Interoperability: Certification Program
Updates, Algorithm Transparency, and Information Sharing'' (88 FR
23746) (HTI-1 Proposed Rule). The HTI-1 Proposed Rule proposed to
implement the Electronic Health Record (EHR) Reporting Program
provision of the Cures Act by establishing new Conditions and
Maintenance of Certification requirements for health IT developers
under the Program. The HTI-1 Proposed Rule also proposed to make
several updates to certification criteria and implementation
specifications recognized by the Program, including revised
certification criterion for: ``clinical decision support'' (CDS),
``patient demographics and observations'', and ``electronic case
reporting.'' The HTI-1 Proposed Rule also proposed to establish a new
baseline version of the United States Core Data for Interoperability
(USCDI). Additionally, the HTI-1 Proposed Rule proposed enhancements to
support information sharing under the information blocking regulations.
On January 9, 2024, the Secretary issued the ``Health Data,
Technology, and Interoperability: Certification Program Updates,
Algorithm Transparency, and Information Sharing'' final rule (HTI-1
Final Rule), which implemented the EHR Reporting Program provision of
the 21st Century Cures Act and established new Conditions and
Maintenance of Certification requirements for health IT developers
under the Program (89 FR 1192). The HTI-1 Final Rule also made several
updates to certification criteria and standards recognized by the
Program. The Program updates included revised certification criteria
for ``decision support interventions,'' ``patient demographics and
observations,'' and ``electronic case reporting,'' as well as adopted a
new baseline version of the USCDI standard, USCDI Version 3.
Additionally, the HTI-1 Final Rule provided enhancements to support
information sharing under the information blocking regulations. Through
these provisions, we sought to advance interoperability, improve
algorithm transparency, and support the access, exchange, and use of
EHI. The HTI-1 Final Rule also updated numerous technical standards in
the Program in additional ways to advance interoperability, enhance
health IT certification, and reduce burden and costs for health IT
developers and users of health IT.
On August 5, 2024, the Secretary published a proposed rule titled
``Health Data, Technology, and Interoperability: Patient Engagement,
Information Sharing, and Public Health Interoperability'' (89 FR 63498)
(HTI-2 Proposed Rule). The HTI-2 Proposed Rule sought to advance
interoperability, improve transparency, and support the access,
exchange, and use of electronic health information through proposals
for: standards adoption; adoption of certification criteria to advance
public health data exchange; expanded uses of certified application
programming interfaces, such as for electronic prior authorization,
patient access, care management, and care coordination; and information
sharing under the information blocking regulations. Additionally, the
HTI-2 Proposed Rule proposed to establish a new baseline version of the
USCDI standard and proposed to update the ONC Health IT Certification
Program to enhance interoperability and optimize certification
processes to reduce burden and costs. The HTI-2 Proposed Rule also
proposed to implement certain provisions related to TEFCA, which would
support the reliability, privacy, security, and trust within TEFCA.
This final rule is the second ``Health Data, Technology, and
Interoperability'' final rule that seeks to advance interoperability,
improve transparency, and support the access, exchange, and use of
electronic health information.
III. ONC Health IT Certification Program
A. Administrative Updates
1. Updates Pursuant to 2014 Edition Removal
We proposed to remove the ``Complete EHR'' and ``EHR Module'' terms
from certain sections within subpart E of 45 CFR part 170 because by
the time we would finalize any proposal in a final rule, the terms
would no longer be relevant (89 FR 63614). As described below, due to
the amount of time that has elapsed since the June 30, 2020, effective
date of the ONC Cures Act Final Rule's removal of the 2014 Edition from
subparts A, B, and C of part 170, we believe removing obsolete terms as
the Program evolves over time maintains clarity of the regulatory text
and Program provisions, particularly for regulated entities and
interested parties.
a. Removal of ``Complete EHR'' References
Because the ability to maintain Complete EHR certification was only
permitted with health IT certified to the 2014 Edition certification
criteria, the ``Complete EHR'' concept was discontinued for the 2015
Edition (80 FR 62719). In order to finalize removal of the 2014
Edition, the ONC Cures Act Final Rule removed the 2014 Edition
certification criteria in Sec. 170.314 from the Program regulations in
45 CFR part 170, Sec. 170.545, and references to ``Complete EHR'' from
the regulation text (85 FR 25655 through 25656). In the HTI-1 Final
Rule, we removed the ``Complete EHR'' language from all reference
points in Sec. Sec. 170.523 and 170.524 (89 FR 1209 through 1210).
However, as explained in the HTI-2 Proposed Rule (89 FR 63614),
until now, we have retained references to ``Complete EHRs'' in certain
provisions within subpart E of 45 CFR part 170:
The definition of ``gap certification'' (Sec. 170.502).
Authorization scope for ONC-ATL status (Sec. 170.511).
Requirements for ONC-ACBs to refund fees to developers
seeking certification under certain circumstances (Sec.
170.523(j)(3)).
Applicability of a newer version of a minimum standard
(Sec. 170.555(b)(2)).
The ``Complete EHR'' concept remained relevant for supporting
continuity through these provisions at that time because the 2014
Edition was not removed from the CFR until the ONC Cures Act Final Rule
(85 FR 25655). As explained in the HTI-2 Proposed Rule, the ONC Cures
Act Final Rule became effective on June 30, 2020,
[[Page 101776]]
and records for the 2014 Edition were required to be retained
(including Complete EHRs) until June 30, 2023, under 45 CFR
170.523(g)(1) (89 FR 63614).
However, beginning with the 2015 Edition, Complete EHR
certifications could no longer be issued and December 31, 2023, has
passed. Thus, we proposed to remove references to ``Complete EHRs''
from the provisions listed above as of the effective date of this final
rule.
b. Removal of ``EHR Modules'' References
As explained in the 2015 Edition Final Rule (80 FR 62604), in order
to better reflect the scope of ONC's authority under the PHSA (section
3000(5)) and to make the Program more open and accessible, we replaced
the term ``EHR Module'' with ``Health IT Module.''
As noted above, consistent with the three-year records retention
requirement for ONC-ACBs (45 CFR 170.523(g)(1)), June 30, 2023, marked
the end of a three-year minimum retention period (36 calendar months)
since we finalized, in the ONC Cures Act Final Rule, the removal of the
2014 Edition from 45 CFR part 170, subparts A, B, and C (85 FR 25656).
Similarly, December 31, 2023, marked the end of the third calendar year
following the calendar year in which the ONC Cures Act Final Rule
became effective. Because we passed both rules' three-year retention
requirements for ONC-ACBs and the term ``EHR Module'' is no longer
relevant, we proposed to remove from Sec. 170.523(f) reference to
``EHR Modules.'' In the HTI-2 Proposed Rule (89 FR 63614 through
63615), we included the explanation for removing the term ``EHR
Modules'' from Sec. 170.523(f) in the preamble. However, we
erroneously neglected to include the removal of ``EHR Modules'' in the
regulatory text for Sec. 170.523(f). Because we included our intent to
remove all of the references to EHR Modules in the HTI-2 Proposed Rule
and there were no comments on the removal of the term generally, we
have included the revision to the regulatory text for Sec. 170.523(f)
in this final rule.
Comments. We did not receive any comments in response to our
proposals to remove the terms ``Complete EHR'' and ``EHR Module.''
Response. Because these terms are no longer relevant and retaining
them may cause confusion for the public, we have adopted our proposals
without revisions.
2. Removal of Time-Limited Criteria
In the ONC Cures Act Final Rule, we finalized Sec. 170.550(m)
``time-limited certification and certification status for certain 2015
Edition certification criteria,'' which provided that for five specific
certification criteria, an ONC-ACB may only issue a certification to a
Health IT Module and permit continued certified status for a specified
time period (85 FR 25952). The five criteria with time-limited
certification and certification status are the ``drug-formulary and
preferred drug list checks'' certification criterion (Sec.
170.315(a)(10)), ``patient-specific education resources'' (Sec.
170.315(a)(13)), ``data export'' certification criterion (Sec. 170.315
(b)(6)), ``secure messaging'' certification criterion (Sec.
170.315(e)(2)), and ``application access--data category request''
(Sec. 170.315(g)(8)). Because the specified time periods for
certification to these criteria have elapsed, we proposed to remove all
of the certification criteria referenced in Sec. 170.550(m) in one
action by removing and reserving Sec. 170.550(m) in its entirety (89
FR 63615 and 63616). We also proposed to remove and reserve these
aforementioned certification criteria from the specific CFR locations
in which they are adopted. In the ONC Cures Act Final Rule, we also
finalized revisions in Sec. 170.315(b)(7)(ii) and (b)(8)(i)(B) to
allow security tagging of Consolidated-Clinical Document Architecture
(C-CDA) documents at the document level only for the period until 24
months after publication date of the final rule (85 FR 25667). Because
that time period has elapsed, we proposed to revise Sec. 170.315(b)(7)
and (8) to remove Sec. 170.315(b)(7)(ii) and (b)(8)(i)(B) (89 FR
63616).
Comments. The majority of comments received on this proposal
objected in particular to the removal of the ``patient-specific
education resources'' certification criterion in Sec. 170.315(a)(13).
They stated that while innovation has progressed, patient-specific
educational resources remain essential in supporting clinicians during
patient interactions. Another commenter expressed concern over the lack
of Fast Healthcare Interoperability Resources (FHIR[supreg])-based
standards for patient education resources. The commenter stated that
although some patient education resources align with FHIR standards to
bolster patient engagement, no specific FHIR standards align with the
HL7 Context-Aware Knowledge Retrieval (Infobutton) standard. The same
commenter recommended that until clear FHIR standards are established,
patient education resources should be codified in regulations and EHR
certification criteria. One commenter stated that while automation and
algorithms have advanced, this technology is not universally available
or fully developed across all health IT systems and removing this
criterion could create a gap in systems where this capability is less
robust, particularly in underserved communities. One commenter stated
that providing patient-specific educational resources contributes to
better long-term outcomes, supporting chronic disease management,
treatment adherence, and overall public health. Another commenter
suggested that instead of eliminating the certification, updating the
criterion to reflect advancements in automation and AI-driven patient
education would encourage ongoing innovation.
Response. We thank commenters for providing feedback on the removal
of ``patient-specific education resources'' certification criterion in
Sec. 170.315(a)(13). However, we believe commenters expressing
specific concerns about maintaining the criterion may have
misunderstood the proposal. The discussion of removing the ``patient-
specific education resources'' certification criterion in Sec.
170.315(a)(13) and the decision to end its applicability within the
Program as of January 1, 2022, was finalized in the ONC Cures Act Final
Rule. In the ONC Cures Act Final Rule, we finalized Sec. 170.550(m),
``Time-limited certification and certification status for certain ONC
Certification Criteria for Health IT,'' which provided that for five
specific certification criteria, an ONC-ACB may only issue a
certification to a Health IT Module and permit continued certified
status for a specified time period (85 FR 25952). One of those criteria
included the ``patient-specific education resources'' certification
criterion in Sec. 170.315(a)(13).
Specifically, in the ONC Cures Act Final Rule, we finalized
requirements in Sec. 170.550(m)(1) permitting ONC-ACBs to issue
certificates for the ``patient-specific education resources''
certification criterion in Sec. 170.315(a)(13) up until January 1,
2022 (85 FR 25661). We stated that we believed that health IT's
capabilities to identify appropriate patient education materials was
widespread among health IT developers and their customers, and noted
innovation had occurred for these capabilities, including the use of
automation and algorithms to provide appropriate education materials to
patients in a timely manner (85 FR 25661). In addition, the ``patient-
specific education resources''
[[Page 101777]]
certification criterion in Sec. 170.315(a)(13) included no means to
advance innovations such as FHIR-based educational resources or
patient-engagement applications. Therefore, in the ONC Cures Act Final
Rule we also stated that we believed this certification criterion was
no longer the best way to encourage innovation and advancement in the
capabilities of health IT to support clinician-patient interactions and
relationships (85 FR 25661).
As the discussion of removing the ``patient-specific education
resources'' certification criterion in Sec. 170.315(a)(13) and the
decision to end its applicability within the Program as of January 1,
2022, was finalized in the ONC Cures Act Final Rule seems to have been
misunderstood by those commenters, we believe those comments are not
applicable to our proposal and out of scope for this rulemaking. We
have finalized the proposal to remove and reserve Sec. 170.315(a)(13).
We did not receive comments on the other proposals to remove time-
limited certification criteria. Therefore, except as to the modified
reference or references to `ASTP/ONC,' we have finalized as proposed
and remove and reserve those criteria. We have also finalized the
proposal to revise Sec. 170.315(b)(7) and (8) to remove Sec.
170.315(b)(7)(ii) and (b)(8)(i)(B), which were time-limited provisions
(now expired) that permitted health IT to demonstrate security tagging
of C-CDA documents at the document level.
3. Privacy and Security Framework Incorporation of DSI Criterion
In the ONC HTI-1 Final Rule, we established a revised certification
criterion (``decision support interventions'' (Sec. 170.315(b)(11)))
to replace the ``clinical decision support'' certification criterion
(Sec. 170.315(a)(9)) effective January 1, 2025 (89 FR 1196 through
1197). However, we neither proposed nor finalized corresponding privacy
and security certification requirements for Health IT Modules
certifying to the ``decision support interventions'' certification
criterion. This omission was an oversight. In the HTI-2 Proposed Rule,
we proposed to add the ``decision support interventions'' certification
criterion (Sec. 170.315(b)(11)) to the list of certification criteria
in Sec. 170.550(h)(3)(ii) (89 FR 63616).
To provide developers of certified health IT time to comply with
these proposed requirements, we specifically proposed to require, in
Sec. 170.550(h)(3)(ii), that Health IT Modules certified to the
``decision support interventions'' (Sec. 170.315(b)(11)) must also be
certified to the specific privacy and security certification criteria
on and after January 1, 2028. We stated that these specific privacy and
security certification criteria are: ``authentication, access control,
and authorization'' in Sec. 170.315(d)(1); ``auditable events and
tamper-resistance'' in Sec. 170.315(d)(2); ``audit report(s)'' in
Sec. 170.315(d)(3); ``automatic access time-out'' in Sec.
170.315(d)(5); ``emergency access'' in Sec. 170.315(d)(6); ``end-user
device encryption'' in Sec. 170.315(d)(7); ``encrypt authentication
credentials'' in Sec. 170.315(d)(12); and ``multi-factor
authentication'' in Sec. 170.315(d)(13). In the HTI-2 Proposed Rule
preamble (89 FR 63616), when listing the specific privacy and security
certification criteria that a Health IT Module certified to the
``decision support interventions'' (Sec. 170.315(b)(11)) certification
criterion must also be certified to, we neglected to include
``emergency access'' in Sec. 170.315(d)(6). However, because we
stated, in the HTI-2 Proposed Rule, that we were proposing to require
in Sec. 170.550(h)(3)(ii) that Health IT Modules certified to the
``decision support interventions'' (Sec. 170.315(b)(11)) must also be
certified to the specific privacy and security certification criteria
on and after January 1, 2028, and because Sec. 170.315(d)(6) is one of
the specific privacy and security certification criteria referenced in
Sec. 170.550(h)(3)(ii), we believe that the public was informed of the
requirement to certify to Sec. 170.315(d)(6) as well despite our
erroneous omission in the preamble.
Comments. We did not receive any comments specific to this proposal
to add the ``decision support interventions'' certification criterion
(Sec. 170.315(b)(11)) to the list of certification criteria in Sec.
170.550(h)(3)(ii). We did, however, receive comments addressing other
provisions related to decision support interventions and timelines that
are beyond the scope of this final rule and are still being reviewed
and considered for purposes of issuing subsequent final rules for such
proposals in the future.
Response. Except as to the modified reference or references to
`ASTP/ONC,' we have finalized this provision as proposed.
B. Correction--Privacy and Security Certification Framework
We proposed to make a correction to the Privacy and Security
Certification Framework in Sec. 170.550(h) (89 FR 63508). We revised
Sec. 170.550(h) in the ONC Cures Act Final Rule but intended for Sec.
170.550(h)(4) to remain unchanged. However, when we drafted the
amendatory instructions, we erroneously included the instruction to
revise all of paragraph (h) (85 FR 25952). Due to this error, when the
CFR was updated, Sec. 170.550(h)(4) was removed. Therefore, we
proposed to add Sec. 170.550(h)(4) back to the CFR [45 CFR
170.550(h)(4) (Jan. 1, 2020)] as it existed prior to the ONC Cures Act
Final Rule (89 FR 63508). We included the complete language to be added
to Sec. 170.550(h) in the proposed and in the regulatory text of this
final rule so that there is sufficient notice of the language that was
previously omitted.
Comments. We did not receive any comments on this proposal.
Response. We have corrected this provision in this final rule to
add Sec. 170.550(h)(4) back in the CFR.
IV. Information Blocking Enhancements--Part 171, Subpart D (TEFCA\TM\)
In the HTI-2 Proposed Rule, we proposed revisions to defined terms
for purposes of the information blocking regulations, which appear in
45 CFR 171.102. Specifically, we proposed to clarify the definition of
``health care provider'' (89 FR 63616, 63617, and 63802) and adopt
definitions for three terms not previously included in Sec. 171.102:
``business day'' (89 FR 63601, 63602, 63626, and 63802), ``health
information technology or health IT'' (89 FR 63617 and 63802), and
``reproductive health care'' (89 FR 63633 and 63802). We proposed to
revise two existing exceptions in subpart B of 45 CFR part 171
(Sec. Sec. 171.202 and 171.204). We proposed revisions to paragraphs
(a), (d), and (e) of Sec. 171.202 (89 FR 63620 through 63622 and
63803) and to paragraphs (a)(2) and (3) and (b) of Sec. 171.204 (89 FR
63622 through 63628 and 63803). We proposed two new exceptions, one in
each in subparts B and C of part 171. The Protecting Care Access
Exception was proposed as new Sec. 171.206 (89 FR 63627 through 63639
and 63804) and the Requestor Preferences Exception as new Sec. 171.304
(89 FR 63639 through 63642, 63804 and 63805). We proposed to codify in
Sec. 171.401 definitions of certain terms relevant to the Trusted
Exchange Framework and Common Agreement\TM\ (TEFCA\TM\) (89 FR 63642,
63804, and 63805) and in Sec. 171.104 descriptions of certain
practices that constitute interference with the access, exchange, and
use of electronic health information (EHI) (89 FR 63617 through 63620,
63802, and 63803). Lastly, we solicited comment on potential revisions
to the TEFCA Manner Exception in subpart D (Sec. 171.403).
[[Page 101778]]
In this final rule, we only address comments on the proposal to
codify definitions of certain TEFCA terms in Sec. 171.401 and comments
received in response to our potential revisions to the TEFCA Manner
Exception. All other information blocking (part 171) proposals from the
HTI-2 Proposed Rule and comments received on those proposals are beyond
the scope of this final rule but may be a subject of another final
rule.
In the HTI-2 Proposed Rule (89 FR 63642 and 63643), we discussed
that in the HTI-1 Proposed Rule (88 FR 23872), we proposed to add a
TEFCA manner condition to the proposed revised and renamed Manner
Exception. In the HTI-2 Proposed Rule, we re-stated that this approach
``aligns with the Cures Act's goals for interoperability and the
establishment of TEFCA by acknowledging the value of TEFCA in promoting
access, exchange, and use of EHI in a secure and interoperable way''
(88 FR 23872). In the HTI-1 Final Rule (89 FR 1437), in part 171, we
finalized a new subpart D, ``Exceptions That Involve Practices Related
to Actors' Participation in The Trusted Exchange Framework and Common
Agreement (TEFCA).'' We noted that the new subpart consists of three
sections, Sec. 171.400, ``Availability and effect of exceptions,''
which mirrors Sec. Sec. 171.200 and 171.300, stating that a practice
shall not be treated as information blocking if the actor satisfies an
exception to the information blocking provision as set forth in subpart
D by meeting all applicable requirements and conditions of the
exception at all relevant times (89 FR 1388). We reserved Sec. 171.401
for definitions in a future rulemaking, and also reserved Sec. 171.402
for future use. In Sec. 171.403 we finalized a new TEFCA Manner
Exception based on the TEFCA manner condition we proposed in HTI-1
Proposed Rule.
A. Definitions
While we reserved Sec. 171.401 for possible future use as a
``definitions'' section in the HTI-1 Final Rule, we declined to
finalize any definitions in the HTI-1 Final Rule. Instead, we referred
readers to the definitions in the most recent version of the Common
Agreement (88 FR 76773) for the terms relevant to the new exception (89
FR 1388). For example, we noted that when we referred to Framework
Agreement(s), we meant any one or combination of the Common Agreement,
a Participant-QHIN Agreement, a Participant-Subparticipant Agreement,
or a Downstream Subparticipant Agreement, as applicable (86 FR 76778).
We noted that this approach would allow us to maintain consistency and
harmony between the Common Agreement and the new subpart D regulatory
text.
In the HTI-2 Proposed Rule, we proposed to include definitions in
Sec. 171.401 by cross-referencing the TEFCA definitions included in
the proposed new 45 CFR part 172, ``Trusted Exchange Framework and
Common Agreement.'' We specifically proposed to adopt in Sec. 171.401
the definitions from Sec. 172.102 for the following terms: Common
Agreement, Framework Agreement, Participant, Qualified Health
Information Network or QHIN\TM\, and Subparticipant. The definitions
would apply to all of subpart D.
Comments. We did not receive any comments regarding our proposal to
adopt in Sec. 171.401 the definitions from 45 CFR part 172, ``Trusted
Exchange Framework and Common Agreement,'' for the terms: Common
Agreement, Framework Agreement, Participant, Qualified Health
Information Network or QHIN, and Subparticipant. Comments regarding the
substance of those definitions are addressed in section V. of this
final rule.
Response. We have finalized the definitions as proposed. The above
terms will have the meaning given to them in Sec. 172.102.
B. TEFCA\TM\ Manner Exception
As briefly discussed above, we finalized a new TEFCA Manner
Exception in the HTI-1 Final Rule. In the HTI-1 Final Rule, we stated
that the TEFCA Manner Exception (Sec. 171.403) provides that an
actor's practice of limiting the manner in which it fulfills a request
to access, exchange, or use EHI to be providing such access, exchange,
or use to only via TEFCA will not be considered information blocking
when it follows certain conditions (89 FR 1388). Those conditions
require that (1) the actor and requestor both be part of TEFCA; (2)
that the requestor is capable of such access, exchange, or use of the
requested EHI from the actor via TEFCA; and (3) any fees charged by the
actor and the terms for any license of interoperability elements
granted by the actor in relation to fulfilling the request are required
to satisfy, respectively, the Fees Exception (Sec. 171.302) and the
Licensing Exception (Sec. 171.303). In addition to these three
requirements, we noted (89 FR 63643) that we also included a limitation
in Sec. 171.403(c), stating that the exception is available only if
the request is not made via the standards adopted in 45 CFR 170.215,
which include the FHIR Application Programming Interface (API)
standards.
We noted (89 FR 63643) that our finalized TEFCA Manner Exception
differed from the proposed TEFCA manner condition in two ways. First,
when we proposed the TEFCA manner condition, we stated that the Fees
Exception and the Licensing Exception would not apply, because ``we
mistakenly assumed that all actors participating in TEFCA would have
already reached overarching agreements on fees and licensing such that
there would be no need for application of the Fees and Licensing
Exceptions'' (89 FR 1389). We stated that we believe that by soliciting
comments specifically on this point, we provided notice to parties that
we either would or would not apply the Fees and Licensing Exceptions.
In response to our proposal in the HTI-1 Proposed Rule, some commenters
expressed concern that because the Common Agreement prohibits fees
between QHINs\TM\ but is otherwise silent on fees between Participants
and Subparticipants, the proposal could allow actors to charge fees to
access, exchange, or use EHI that did not comply with the Fees or
Licensing Exceptions. Some commenters also expressed that this could
have the effect of disincentivizing participation in TEFCA and could
cause actors to use other options of electronic exchange outside of
TEFCA, where the actors believed the Fees and Licensing Exceptions
would apply. As such, in the HTI-1 Final Rule, we finalized the TEFCA
Manner Exception to include that any fees charged by the actor, and any
licensing of interoperability elements, must satisfy the Fees Exception
(Sec. 171.302) and the Licensing Exception (Sec. 171.303) (89 FR
1389). In the HTI-2 Proposed Rule, we stated that while we continue to
believe that it was clear that the alternative would be to apply the
exceptions, we requested comment on whether there are drawbacks to
applying the Fees and Licensing Exceptions, and if we should continue
to apply them to the TEFCA Manner Exception as currently required in
Sec. 171.403(d).
We noted (89 FR 63643) that the other change made to the proposed
TEFCA manner condition was the limitation that carves out requests made
for access, exchange, or use of EHI via FHIR API standards (89 FR
1389). We finalized this limitation in response to comments noting that
a request could be made for access, exchange, or use via FHIR-based API
and an actor could respond in a different manner and satisfy the
exception (89 FR 1390 and 1391). Commenters on the HTI-1 Proposed Rule
further noted that this potential
[[Page 101779]]
outcome could undermine our stated purpose in incentivizing TEFCA
participation with the new exception (See 89 FR 1390). In the HTI-2
Proposed Rule (89 FR 63643), we solicited comment on this limitation
within the TEFCA Manner Exception for requests via FHIR API standards.
For example, we solicited comment on whether the limitation should be
expanded to include exchange based on versions of the FHIR standards
that are more advanced than those adopted in 45 CFR 170.215 or approved
through the 45 CFR 170.405(b)(8), ``Standards Version Advancement
Process--voluntary updates of certified health IT to newer versions of
standards and implementation specifications.'' We noted that as of the
time we issued the HTI-2 Proposed Rule, the limitation would only cover
requests made via FHIR API standards codified in Sec. 170.215,
including standards that may be updated from time to time through Sec.
170.405(b)(8), which may involve a delay before the version is formally
approved under Standards Version Advancement Process (SVAP).
We also sought comment on a different approach (89 FR 63643). We
noted that eventually all TEFCA QHINs will be required to support
exchange via FHIR API standards. A Participant or Subparticipant who
makes a request for access, exchange, or use of EHI via FHIR API will
at first make such a request through a QHIN, but in time, a Participant
or Subparticipant could directly request access, exchange, or use of
EHI via FHIR API standards from another Participant or Subparticipant
in a different QHIN. We stated that one option would be to sunset the
limitation in Sec. 171.403(c) once all QHINs can support brokered
FHIR. Another option would be to sunset the limitation in Sec.
171.403(c) if all QHINs, Participants and Subparticipants support
facilitated FHIR exchange. We also stated that as an alternative to
these options, we could maintain the exception as is, regardless of
FHIR API adoption among TEFCA entities. We requested comment on all of
the options, including whether or not the limitation should remain as
it is currently.
Comments. The majority of comments we received on whether there are
drawbacks to applying the Fees and Licensing Exceptions, and if we
should continue to apply them to the TEFCA Manner Exception as
currently required in Sec. 171.403(d), were in support of the
exception as finalized in the HTI-1 Final Rule. Commenters expressed
appreciation that ASTP/ONC listened to their feedback in response to
the HTI-1 Proposed Rule and added the Fees and Licensing Exceptions
applicability to the TEFCA Manner Exception. Commenters noted that
including the applicability of the Fees and Licensing Exceptions would
mitigate risks that some organizations could exploit their TEFCA
participation to consolidate market power and stifle competition.
Response. We appreciate the commenters' support. We are retaining
the exception as finalized in HTI-1 Final Rule, such that there will be
no changes finalized in this final rule and the Fees and Licensing
Exceptions will apply to an actor seeking to use the TEFCA Manner
Exception.
Comments. One commenter recommended modifying the TEFCA Manner
Exception so that both the requestor and responder must agree on the
mechanism (FHIR or other transmission protocol) within TEFCA used to
exchange EHI, in order to accommodate TEFCA participants who may not
yet have enabled FHIR transactions for TEFCA.
Response. We appreciate the comment and the opportunity to clarify
that the exception does not apply to requests made via the standards
adopted in 45 CFR 170.215, including version(s) of those standards
approved pursuant to 45 CFR 170.405(b)(8) (the Standards Version
Advancement Process, or SVAP). The standards adopted in Sec. 170.215
include the FHIR standards the commenter describes. When actors seek to
use the TEFCA Manner Exception, as finalized in 45 CFR 171.403, the
exception includes a ``requestor capability'' condition (Sec.
171.403(b)) that limits the exception to only be available when the
requestor is capable of such access, exchange, or use of the requested
EHI from the actor via TEFCA. Therefore, if the requestor is unable to
receive the EHI from the actor using a FHIR transaction via TEFCA, this
exception would not be available to the actor. We believe this provides
enough flexibility for actors to use this exception when the requestors
are able to access the requested EHI, while ensuring that actors who do
not yet have FHIR-based exchange capabilities will not be expected to
share via FHIR.
Comments. A few commenters suggested that ASTP/ONC revise the TEFCA
Manner exception to state that if an actor charges fees to access data
through TEFCA, the TEFCA Manner Exception will not apply, and the
requestor would be entitled to EHI through a different manner. One
commenter stated that ASTP/ONC should state that charging fees to
access data through TEFCA negates the TEFCA Manner Exception and actors
that do not provide a secondary method of exchange would be considered
information blockers.
Response. We decline to adopt these suggestions. We have retained
the finalized exception from the HTI-1 Final Rule. We reiterate that
certain fees are permitted under the Fees Exception, and that an actor
participating in TEFCA would still be subject to the restrictions of
the Fees Exception if the actor is seeking to make use of the TEFCA
Manner Exception (for example, by responding via TEFCA even if the
request was not received via TEFCA). We note that, per Sec.
171.403(c), the TEFCA Manner Exception is not available if a requestor
requests EHI via the standards adopted in 45 CFR 170.215, including
version(s) of those standards approved pursuant to 45 CFR
170.405(b)(8). Under those conditions described in Sec. 171.403(c), a
fee could still be considered an interference if it does not meet the
requirements of the Fees Exception (or the practice is not covered by
another exception).
Comments. Many commenters supported retaining the limitation in the
TEFCA Manner Exception to exclude requests made via the standards
adopted in Sec. 170.215. Commenters stated that removing the condition
in Sec. 171.403(c) could disincentivize joining TEFCA for entities
seeking to leverage FHIR-based exchange. Some of those commenters also
suggested that the condition should be removed once everyone exchanging
data on TEFCA is required to support the more advanced FHIR standard.
One commenter recommended removing the condition now, and others
recommending ASTP/ONC consider sunsetting the condition in the future
but stated that it was premature to do so now. Most commenters
supported maintaining the condition for now, and recommended ASTP/ONC
revisit the exception in the future.
Response. We appreciate the comments and agree that the condition
remains useful for advancing interoperability as discussed in the HTI-2
Proposed Rule. We also agree that it is premature to remove the
condition at this time. As noted above, we are maintaining the TEFCA
Manner Exception as finalized in the HTI-1 Final Rule.
Comments. A few commenters expressed concerns that actors who
participate in TEFCA may seek to use this exception to cover practices
involving the access, exchange, or use of EHI with entities or
requestors who do not participate in TEFCA. The commenters asked for
clarification on this point.
Response. We appreciate the opportunity to clarify that this
[[Page 101780]]
exception is only available when both the actor and the requestor
participate in TEFCA as QHINs, Participants, or Subparticipants (Sec.
171.403(a)). An actor who participates in TEFCA may not use this
exception to cover any practice related to the access, exchange, or use
of EHI with an entity who is not a TEFCA QHIN, Participant, or
Subparticipant.
Comments. Some commenters expressed concerns related to the ``TEFCA
SOP XP Implementation: Health Care Operations'' because the standard
operating procedure (SOP) would allow providers and developers to
charge health plans to access data under the health care operations
exchange purpose.
Response. Commenters correctly point out that health care providers
and developers of certified health IT (``actors'' for purposes of the
information blocking regulations) are permitted to charge fees under
TEFCA for the health care operations exchange purpose as well as other
exchange purposes.\5\ However, these fees would need to meet the Fees
Exception (Sec. 171.302) under the information blocking regulations
and if charged in conjunction with an actor choosing to voluntarily use
and meet the conditions of the TEFCA Manner Exception. We decline,
however, to state in this final rule whether any specific fee amount
that may be charged as a permitted fee under TEFCA meets the conditions
of the Fees Exception.
---------------------------------------------------------------------------
\5\ 4.2 Required Information and Permitted Fees and Table 2 at
https://rce.sequoiaproject.org/wp-content/uploads/2024/08/SOP-Exchange-Purposes_CA-v3_508.pdf.
---------------------------------------------------------------------------
Comments. We received many comments in response to our question
regarding whether the limitation should be expanded to include exchange
based on versions of the FHIR standards that are more advanced than
those adopted in 45 CFR 170.215 or approved through the 45 CFR
170.405(b)(8), ``Standards Version Advancement Process--voluntary
updates of certified health IT to newer versions of standards and
implementation specifications.'' Some commenters suggested that the
limitation should only apply to requests made via standards adopted in
Sec. 170.215 or through the Standards Version Advancement Process
(SVAP). Some suggested that if the actor supports the more advanced
FHIR standard that has not yet been adopted, then the actor must
respond to a request via that standard. The commenters stated that if
the actor does not support the more advanced FHIR standard at the time
of the request, then the TEFCA Manner Exception should still be
available.
Response. We appreciate the comments. Until adoption of the FHIR
standard is widespread, we think it is sufficient to reserve the carve-
out only for versions of the FHIR standard adopted under Sec. 170.215
or approved through the SVAP process. We believe including standards
approved through the SVAP process, as well as those adopted under Sec.
170.215, provides the right balance of ensuring newer versions of the
FHIR standard can be used without expanding the carve-out to the point
that it subsumes the exception itself.
Comments. One commenter encouraged us to clarify that the exception
does not mean an organization participating in TEFCA can or will only
share data with other organizations participating in TEFCA. Another
commenter recommended that the mutuality requirement be phased out so
that an actor's participation in TEFCA allows them to claim the TEFCA
Manner Exception regardless of the requestor's participation.
Response. We appreciate the opportunity to draw attention to Sec.
171.403(a), as finalized in the HTI-1 Final Rule, which states that the
actor and requestor must both be part of TEFCA for the exception to be
available. A request to access, exchange, or use EHI that an actor
receives from a requestor who does not participate in TEFCA as a QHIN,
Participant, or Subparticipant does not qualify for the TEFCA Manner
Exception (89 FR 1388). Nor does anything in this exception, or
anything else in the information blocking regulations, permit a TEFCA
entity actor to interfere with a non-TEFCA entity's request to access,
exchange, or use EHI, unless required by law or covered by an
exception. We decline to adopt the suggestion to remove the mutuality
requirement because it would be detrimental to exchange and could force
participation in a voluntary exchange framework. We remind all
interested parties that participation in TEFCA is voluntary, and no
actor is required to join TEFCA.
Comments. Some commenters expressed concerns that the TEFCA Manner
Exception could have unintended consequences. For example, one
commenter expressed concern that the TEFCA Manner Exception could tip
the scales to prioritize TEFCA exchange over all other interoperability
pathways and noted that TEFCA does not offer solutions to all needs,
including, for example, write-back capabilities and non-EHI data. A few
commenters encouraged ASTP/ONC to regularly review the need for the
TEFCA Manner Exception, and to update or sunset the exception in the
future.
Response. We appreciate the comments. We agree that retaining
multiple pathways to interoperability is important. We will continue to
monitor the interaction between TEFCA and the TEFCA Manner Exception.
Comment. One commenter suggested encouraging TEFCA participation by
expanding the TEFCA Manner Exception. The commenter noted that the
exception states that if both parties (requestor and responder)
participate in TEFCA, it is not information blocking to only fulfill
requests for EHI via TEFCA. The commenter asserted that this
incentivizes a requestor not to become a TEFCA participant, since the
exception does not apply against a requestor as long as it is not a
TEFCA participant. Instead, the commenter suggested that we incentivize
entities to join TEFCA by adjusting the exception to place a burden on
any requester who is not currently a TEFCA QHIN, participant, or sub-
participant to explain why joining TEFCA is infeasible or poses an
undue burden for their request. The commenter stated this would satisfy
the stated goals of the exception and drive adoption within the
industry.
Response. We thank the commenter for their suggestions. These
suggestions are outside the scope of our solicitation of comments on
the TEFCA Manner Exception.
V. Trusted Exchange Framework and Common Agreement\TM\
Section 3001(c)(9)(B)(i) of the PHSA provides the National
Coordinator with the authority to ``develop or support a trusted
exchange framework for trust policies and practices and for a common
agreement for exchange between health information networks.'' The
components of this Trusted Exchange Framework and Common Agreement\TM\
(TEFCA\TM\) include the Trusted Exchange Framework (a common set of
principles designed to facilitate trust between health information
networks (HINs)) and the Common Agreement (the agreement Qualified
Health Information Networks[supreg] (QHINs\TM\) sign), which includes,
among other provisions, privacy, compliance, and security
requirements). The Common Agreement also references the QHIN Technical
Framework (QTF) (which describes technical requirements for exchange
among QHINs) as well as, where necessary, SOPs. These documents further
the statute's overall goal of ensuring full network-to-network exchange
of health information by
[[Page 101781]]
establishing an organizational, operational, and technical floor for
nationwide interoperability and securely facilitating the exchange of
information across different networks nationwide.
By providing a common and consistent approach for the exchange of
health information across many different networks, TEFCA simplifies and
significantly reduces the number of separate networks that individuals,
health care providers, and other interested parties need to be a part
of in order to access the health information they seek. HINs that
voluntarily join TEFCA will facilitate exchange in a secure and
interoperable manner. TEFCA establishes a method for authenticating
trusted HIN participants, potentially lowering the cost and expanding
the nationwide availability of secure health information exchange
capabilities. The establishment of technical services for HINs that
voluntarily join TEFCA, such as an electronic address directory and
security services, will help to scale network exchange nationwide. In
addition, the organizational and operational policies established
through TEFCA enable the exchange of health information among HINs and
include minimum conditions required for such exchange to occur.
Updates in Common Agreement Version 2.1 reflect the latest
technical specifications, among other changes, including updates to
network-based exchange using FHIR APIs, which are a cornerstone of the
interoperability initiatives of not only ASTP/ONC but also of other
Federal agencies such as the Centers for Medicare & Medicaid Services
(CMS), Centers for Disease Control and Prevention (CDC), Health
Resources & Services Administration (HRSA), and U.S. Department of
Veterans Affairs (VA).
Under TEFCA, QHINs play an important role in advancing secure,
standardized health information exchange. QHINs have significant
organizational and technical capabilities, facilitate exchange at the
highest level of the TEFCA infrastructure, and are the entities with
which Participants (and their Subparticipants) connect to engage in
TEFCA Exchange. ``TEFCA Exchange,'' which we proposed to define in
Sec. 172.102, means the transaction of electronic protected health
information (ePHI) between Nodes \6\ using a TEFCA-specific purpose of
use code, meaning a code that identifies the Exchange Purpose for which
exchange is occurring. QHINs voluntarily agree to follow certain
organizational and operational policies that allow Participants
(entities who have entered into an agreement with the QHIN that
includes the Participant/Subparticipant Terms of Participation) and
Subparticipants (entities that have entered into an agreement with a
Participant or other Subparticipant that includes the Participant/
Subparticipant Terms of Participation) to simplify their operations and
promote efficiency of scale.
---------------------------------------------------------------------------
\6\ Node means a technical system that is controlled directly or
indirectly by a QHIN, Participant, or Subparticipant and that is
listed in the RCE Directory Service.
---------------------------------------------------------------------------
QHINs must meet policy and technical requirements under the Common
Agreement. The QTF and SOPs provide additional information on how QHINs
meet those requirements. As finalized, QHINs must comply with the
provisions in this final rule. QHINs also perform an important role by
ensuring that Participants and Subparticipants meet the requirements of
TEFCA.
As we discussed in the HTI-2 Proposed Rule (89 FR 63644), we
proposed to establish rules in 45 CFR part 172 to implement our
obligations under section 3001(c)(9)(D) of the PHSA to publish a
directory of HINs that ``have adopted the common agreement and are
capable of trusted exchange pursuant to the common agreement'' and to
establish a process through notice-and-comment rulemaking for HINs to
attest to adopting TEFCA.
The provisions also establish the qualifications for HINs to
receive and maintain Designation as a QHIN capable of trusted exchange
pursuant to TEFCA, as well as establish procedures governing QHIN
Onboarding and Designation, suspension, termination, and administrative
appeals to ONC as described in the sections below. In the HTI-2
Proposed Rule, we stated that we believe establishing these provisions
in regulation would strengthen the trust of interested parties in TEFCA
and support its success at scale.
Comments. A majority of commenters supported ONC's proposal to
adopt rules in 45 CFR part 172 regarding TEFCA. A number of commenters
encouraged ASTP/ONC to prioritize focusing on high-quality data within
data sharing and creating more equal information exchange to advance
interoperability.
Many commenters highlighted that strong TEFCA requirements allow
organizations who exchange information to avoid national security and
fraud risk and have protection against outside bad actors. Several
commenters also expressed support for the implementation of the QTF to
support data exchange and noted the importance of TEFCA ensuring the
exchange of reliable and high-quality data.
Response. We thank commenters for their support of our proposal to
adopt rules in 45 CFR part 172 regarding TEFCA and their support for
our implementation of TEFCA. We agree with commenters about the
importance of TEFCA in advancing interoperability and high-quality data
exchange. We appreciate commenters' concerns about potential risks of
data exchange without TEFCA infrastructure. We are working to fulfill
TEFCA's statutory purpose of ensuring full network-to-network exchange
of health information, while also recognizing that appropriate
guardrails and protections for information exchange are needed. We
agree with commenters who encouraged us to prioritize high-quality data
and we are also exploring how TEFCA can help improve data quality for
TEFCA Exchange.
Comments. Some commenters recommended that ASTP/ONC should codify
all TEFCA requirements so that TEFCA requirements and applicable SOPs
not included in the HTI-2 Proposed Rule may be subject to notice and
comment rulemaking. These commenters also suggested that ASTP/ONC
should become more involved in enforcing TEFCA requirements and
providing incentives and removing disincentives for entities to
participate in TEFCA. Some of these commenters also expressed that
TEFCA should remain in alignment with Health Insurance Portability and
Accountability Act of 1996 (HIPAA) \7\ unless there are strong policy
reasons for TEFCA to diverge from HIPAA. One commenter requested that
ASTP/ONC clarify within TEFCA any HIPAA interactions and protections
related to disclosures.
---------------------------------------------------------------------------
\7\ Public Law 104-191, 110 Stat. 1936.
---------------------------------------------------------------------------
Response. We appreciate the comments. In the Cures Act, Congress
directed ONC to convene public-private and public-public partnerships
to build consensus and develop or support a trusted exchange framework,
including the Common Agreement (42 U.S.C. 300jj-11(c)(9)(A)). The
statute provides that the Common Agreement--which must be published in
the Federal Register, but which is not subject to notice and comment
(42 U.S.C. 300jj-11(c)(9)(C))--may include a common method for
authenticating trusted health information network participants, a
common set of rules for trusted
[[Page 101782]]
exchange, organizational and operational policies to enable the
exchange of health information among networks, including minimum
conditions for such exchange to occur, and a process for filing and
adjudicating noncompliance with the terms of the common agreement (42
U.S.C. 300jj-11(c)(9)(B)). ASTP/ONC has convened such partnerships, and
we believe the Common Agreement is generally best developed through
those channels, as provided for in the Common Agreement to which QHINs
agree. We believe the current process strikes the right balance between
ASTP/ONC oversight, public engagement, and the use of a public-private
partnership to both ensure important input from interested parties and
maintain flexibility to adapt to the ever-evolving interoperability
landscape. Finally, TEFCA is aligned with the HIPAA Privacy, Security,
and Breach Notification Rules in the sense that an entity is able to
comply with the HIPAA Rules and TEFCA at the same time. But we do not
agree with commenters who suggest that TEFCA should presumptively copy-
and-paste definitions or requirements from the HIPAA Rules into TEFCA.
The HIPAA Rules and TEFCA are authorized by different statutes that
pursue different goals, and while those goals might sometimes overlap,
other times they might not. In order to recognize overlap between the
two legal frameworks and reduce regulatory burden while balancing other
policy interests, including trusted exchange, ASTP/ONC has sometimes
aligned TEFCA requirements. However, ASTP/ONC may develop definitions
and requirements within TEFCA that are narrower or broader than
corresponding definitions and requirements within the HIPAA Rules to
satisfy competing policy interests and achieve TEFCA's statutory goal
of ensuring full network-to-network exchange of health information.
Comments. One commenter recommended that ASTP/ONC require QHINs to
have a privacy official and a chief information security to monitor
data privacy. Another commenter specifically expressed support for the
requirement that any organization aspiring to become a QHIN must adhere
to specific privacy and security guidelines, with additional
stipulations for those providing Individual Access Services.
Response. We appreciate the commenter's support for TEFCA's
existing privacy and security requirements, as well as the additional
requirements for QHINs that provide Individual Access Services.
Regarding the comment recommending that each QHIN be required to have a
privacy official and a chief information security to monitor data
privacy, we note that we proposed and have finalized Sec.
172.201(c)(8), which requires QHINs to maintain privacy and security
policies that permit the entity to support TEFCA Exchange. The QHIN
Security Requirements for the Protection of TEFCA Information SOP \8\
provides additional information on how that requirement can be met,
including by QHINs having a chief information security officer (CISO).
CISOs are responsible for the overall security posture of a QHIN with
respect to their participation in TEFCA. This includes technical,
administrative, and physical security safeguards and documentation
thereof for a QHIN.
---------------------------------------------------------------------------
\8\ QHIN Security Requirements for the Protection of TEFCA
Information SOP, https://rce.sequoiaproject.org/wp-content/uploads/2024/08/QHIN-Security-for-the-Protection-of-TI-21.pdf.
---------------------------------------------------------------------------
Comments. A number of commenters supported ASTP/ONC's approach of
proposing to codify TEFCA requirements but expressed concern that it
could be adopting TEFCA requirements into a regulatory framework too
quickly and requested that ASTP/ONC provide information regarding our
intentions to adopt other TEFCA requirements in the future. These
commenters recommended that ASTP/ONC take a cautionary approach and
potentially delay the adoption of further TEFCA requirements, citing
that TEFCA is intended to be fluid and evolve more quickly than
regulations. One commenter also urged ASTP/ONC take care with future
adoptions of TEFCA requirements that we do not undermine the
independence of the Recognized Coordinating Entity[supreg]
(RCE[supreg]).
Several commenters were concerned that codifying TEFCA hampers the
ability of TEFCA to change and adapt as needed, and a few of these
commenters suggested that the codification of TEFCA requirements is
unnecessary because TEFCA infrastructure is supported by its
contractional nature. One commenter specifically recommended that ASTP/
ONC incorporate TEFCA and relevant SOPs by reference rather than adopt
sections of TEFCA as regulations out of concern that adopting sections
of TEFCA as regulations would undermine the sections of TEFCA that are
not adopted as a whole and would require future rulemaking actions to
modify the sections of TEFCA that have been codified as regulations.
Response. We appreciate commenters' support of our proposals and
also understand the concerns about the adoption of TEFCA requirements
in regulation and the need for TEFCA to evolve as the interoperability
landscape changes. The provisions we have finalized in 45 CFR part 172
mainly address QHIN appeals (subpart F) and the underlying requirements
regarding which decisions may ultimately be appealed (subparts B
through E). We believe establishing QHIN appeal rights in regulation
will enhance trust in the TEFCA framework, as QHINs--that have invested
significant time and resources into becoming a QHIN--will know that
processes exist to appeal decisions that could have a significant
impact of their businesses and the exchange of information for their
Participants and Subparticipants. That said, we do not believe it would
benefit TEFCA to codify all TEFCA requirements in regulation due to the
need, as commenters noted, for TEFCA to move quickly and evolve with
the ever-changing interoperability landscape. We appreciate commenters'
suggestions regarding the future adoption of other TEFCA requirements
in regulation and will consider them in the future.
Subpart G in 45 CFR part 172, which addresses QHIN attestation for
the adoption of the Trusted Exchange Framework and the Common
Agreement, has been adopted in accordance with statutory requirements.
Specifically, section 4003(b) of the Cures Act added section
3001(c)(9), ``Support for Interoperable Networks Exchange,'' to the
PHSA. Section 3001(c)(9)(D)(ii) requires HHS to establish, through
notice and comment rulemaking, a process for HINs that voluntarily
elect to adopt TEFCA to attest to such adoption of the trusted exchange
framework and common agreement. Section 3001(c)(9)(D)(i) requires the
National Coordinator to publish on ONC's website a list of the HINs
that have adopted the Common Agreement and are capable of trusted
exchange pursuant to the Common Agreement.
For these reasons, we decline to adopt TEFCA solely through
incorporation by reference instead of through a regulatory framework.
We also received numerous comments that were out of scope or that
recommended that ASTP/ONC adopt new requirements that we did not
propose and are not addressed in this rulemaking.
Comments. A number of comments addressed concerns about the role
and authority of QHINs in relation to TEFCA Participants. Some
commenters urged
[[Page 101783]]
ASTP/ONC to take a more direct role in monitoring and enforcing
compliance and bolstering Participant confidence as TEFCA participation
expands and monitoring by QHINs potentially becomes more difficult.
Several commenters were concerned that there was no investigative body
for independent oversight within TEFCA and suggested ASTP/ONC should
monitor for the possibility of QHINs exercising outsized influence. A
few commenters recommended that ASTP/ONC create an oversight board, or
a body associated with the Office of the Inspector General (OIG), to
provide independent review within TEFCA. These commenters also
suggested that ASTP/ONC should include a mechanism for patient-
identified issues.
Some commenters suggested that ASTP/ONC require that a QHIN create
a continuity plan that includes support for the migration of
Participants and Subparticipants if a QHIN is terminated or sanctioned.
Additionally, one commenter requested information on how the TEFCA
requirements will impact existing SOPs and whether the RCE will
continue to have the authority to modify requirements for QHINs through
the SOPs.
Response. We thank commenters for their feedback. We appreciate
commenters' concerns regarding the role of QHINs in TEFCA governance
but have decided not to make any related changes in this final rule. We
believe QHINs are best positioned to have primary oversight
responsibility over their customers (i.e., Participants) and should
have autonomy to make decisions about their networks so long as such
decisions do not conflict with the requirements for TEFCA Exchange. We
note that there is strong representative and participatory network
governance built into the TEFCA infrastructure, including the
requirement that QHINs must maintain a representative and participatory
group or groups with the authority to approve processes for governing
the Designated Network (Sec. 172.201(c)(7)). Regarding the comments
related to including additional oversight within the TEFCA framework,
including the suggestion of including HHS OIG in TEFCA governance and
oversight, we believe that doing so is not necessary and could limit
the flexibility of TEFCA's public-private model of exchange and
governance. We believe the oversight provided by ASTP/ONC, including as
established in provisions we are finalizing in 45 CFR part 172, meets
the needs of the TEFCA community and provides strong support for TEFCA.
ASTP/ONC will continue to monitor TEFCA, and we will consider
additional measures should circumstances arise that show that QHINs
require additional oversight.
We appreciate the suggestion regarding creation of a mechanism for
patient-identified issues and note that there are already mechanisms in
place for reporting of patient-identified issues. Patients can report
issues to ASTP/ONC through the TEFCA tab in the Health IT Feedback and
Inquiry Portal available at https://inquiry.healthit.gov/support/plugins/servlet/desk/portal/2. Patients may also report issues to the
RCE at https://rce.sequoiaproject.org/contact/. We encourage patients
to report any issues they are experiencing to ASTP/ONC, the RCE, or
both so that we can continue to improve TEFCA Exchange.
We also appreciate the suggestion that we require QHINs to create a
continuity plan that includes support for the migration of Participants
and Subparticipants if a QHIN is terminated or sanctioned. We did not
propose to require a continuity plan in the HTI-2 Proposed Rule and
believe it would be appropriate for the public to have an opportunity
to submit comments before we could adopt this type of requirement.
Therefore, we have decided not to finalize a requirement regarding
creation of a continuity plan in this final rule. We may consider
including such a requirement in a future rulemaking. In the meantime,
we encourage QHINs and their Participants to discuss the details
regarding continuity of service and consider addressing such details in
the respective Framework Agreement between the two parties.
Regarding the comment concerning how the TEFCA requirements will
impact existing SOPs, we note that the SOPs can be updated to align
with updated requirements. We expect that the RCE will continue to
support the development of SOPs, as they have to this point.
Comments. Multiple commenters raised concerns about the adoption of
the Exchange Purposes (XPs) SOP version 3.0 without a public comment
period. These commenters highlighted in particular that the recent XPs
SOP version 3.0 allows health care providers to charge for data
exchanges and requested that ASTP/ONC not allow entities to charge fees
for TEFCA-based data exchanges.
Response. We thank commenters for raising this concern to our
attention. While we understand the importance of this issue, it falls
outside the scope of this final rule. The provisions regarding fees and
the XP SOP version 3.0 are not addressed within this final rule. We
encourage further engagement on the topic of fees through public TEFCA
meetings, webinars, and other feedback opportunities.
Comments. Several commenters advocated for the inclusion of State,
Tribal, Local, and Territorial (STLT) public health agencies in the
governance of TEFCA and QHINs to identify priority use cases. A few of
these commenters also noted that the exchange of Prescription Drug
Monitoring Program (PDMP) information through TEFCA is incompatible
with PDMPs' data confidentiality and privacy requirements and suggested
that PDMPs be excluded from TEFCA requirements.
A few commenters additionally noted that there is no Common
Agreement for advisory boards and suggested that ASTP/ONC recognize
advisory boards, including or referencing groups such as patients,
providers, payors, and public health. One commenter recommended that
TEFCA advisory groups include expanded roles for health plan
representatives.
Response. We thank commenters for their input. The involvement of
state and local public health agencies, as well as advisory boards, in
TEFCA is an important consideration, and we will consider the related
suggestions as we implement and refine the TEFCA governance process. We
encourage interested communities to continue engaging with us as these
aspects of the TEFCA framework are refined. We welcome all feedback
from interested parties, which can be submitted via the ASTP/ONC
website at https://inquiry.healthit.gov/support/plugins/servlet/desk/portal/2/create/61, for consideration and potential inclusion within
the TEFCA framework.
We do not understand the comment that there is no Common Agreement
for advisory boards. We appreciate the suggestion for enhancing TEFCA's
governance. We are currently considering ways to ensure that different
groups, such as patients, providers, payors, and public health, are
represented within TEFCA's governance, which could include the
development of advisory boards or councils. However, we did not make a
proposal in this rulemaking regarding advisory boards, and it would be
appropriate for the public to have an opportunity to submit comments
before we could adopt these types of changes. We may consider
addressing this issue in a future rulemaking.
We appreciate the comment that the exchange of PDMP information
through TEFCA is incompatible with PDMPs' data confidentiality and
privacy
[[Page 101784]]
requirements and the suggestion that PDMPs be excluded from TEFCA
requirements. We have decided not to make any related changes in this
final rule because we did not make any proposals about PDMPs, and it
would be appropriate for the public to have an opportunity to submit
comments before we could adopt these types of changes. We may consider
addressing this issue in a future rulemaking.
Comments. Several commenters were concerned that the TEFCA
requirements prioritize TEFCA participation over other mechanisms of
interoperability. A few commenters were concerned that the TEFCA
requirements allow participants to not respond to queries from entities
that are not TEFCA participants when the data exchange is lawful
thereby allowing data from certain providers to be siloed. These
commenters suggested that ASTP/ONC clarify that the refusal by entities
connected to TEFCA to lawfully exchange data with entities that are not
licensed health care professionals is information blocking. Commenters
also requested that ASTP/ONC publish a request for information (RFI) on
the treatment of all federally defined health care providers under
TEFCA. One commenter also advocated that TEFCA requirements should
focus on treatment and individual access exchange.
Response. We thank commenters for their feedback. The concerns
raised regarding TEFCA requirements and their interaction with other
interoperability mechanisms are out of scope for this final rule, since
the TEFCA requirements do not apply to other mechanisms of
interoperability. However, we would like to direct commenters to the
TEFCA Manner Exception in 45 CFR 171.403, finalized in the HTI-1 Final
Rule (89 FR 1387 through 1388). This exception applies when, among
other necessary conditions, both the actor and requestor participate in
TEFCA as QHINs, Participants, or Subparticipants (Sec. 171.403(a); 89
FR 1388). When the necessary conditions under Sec. 171.403 are met,
the actor's practice of fulfilling requests for access, exchange, or
use of EHI exclusively via TEFCA will not be considered information
blocking. We recommend reviewing this exception for further clarity on
TEFCA participation and its interplay with information blocking.
Comments. One commenter expressed concern about the perceived lack
of intellectual property protections in TEFCA and recommended that
ASTP/ONC increase intellectual property protections within TEFCA.
Response. We thank the commenter their feedback. The issue of
intellectual property protections within TEFCA is outside the scope of
this final rule, as we did not propose, and this final rule does not
address, such provisions. We welcome all feedback from interested
parties, which can be submitted via the ASTP/ONC website at https://inquiry.healthit.gov/support/plugins/servlet/desk/portal/2/create/61,
for consideration and potential inclusion within the TEFCA framework.
Comments. A number of commenters who expressed support for TEFCA
were concerned that compliance with TEFCA requirements could be
difficult for non-medical specialist entities and entities with limited
financial or infrastructure resources. Some of these commenters
recommended that ASTP/ONC and the RCE consider providing educational
initiatives, incentives, and technical and financial support to
providers with limited resources that transition to joining TEFCA.
These commenters also expressed concern that participation fees for
TEFCA participants should be fair and scaled to the size of and
potential use by participants and non-duplicative.
Some commenters requested that ASTP/ONC provide TEFCA Participants
more time to prepare when new requirements are adopted as part of
updates to the Common Agreement or when SOPs are updated. One commenter
also recommended that ASTP/ONC and the RCE establish steps and goals to
guide how entities will transition to TEFCA participation. One
commenter recommended that ASTP/ONC adopt more specific definitions of
Participants and Subparticipants for TEFCA to reduce ambiguity. One
commenter particularly requested that ASTP/ONC delay requiring
emergency medical services agencies to comply with TEFCA requirements
that involve significant technological hurdles or require significant
financial and infrastructure resources, and that ASTP/ONC convene a
working group to determine how emergency medical services agencies can
comply with TEFCA requirements in the future.
Response. We thank commenters for their feedback. We appreciate
commenters' concerns about potential financial and technological
limitations for some entities regarding TEFCA. We are exploring ways to
assist such entities and ensure that the benefits of TEFCA are not
disproportionately allocated to larger, for-profit entities. In order
to inform such efforts, we are focused on collecting and analyzing
exchange metrics as TEFCA matures to better understand where exchange
gaps persist.
We understand that cost is a concern for many organizations,
particularly small and rural providers. We continue to engage with
providers to understand these concerns and providers' needs better and
to develop strategies to assist small and rural providers with TEFCA
implementation. We are also developing, along with the RCE, various
resources to clarify various questions about TEFCA participation and
implementation. We appreciate the request that ASTP/ONC provide TEFCA
Participants more time to prepare when new requirements are adopted as
part of updates to the Common Agreement or when SOPs are updated and
will consider the request as we work to expand TEFCA Exchange and
update TEFCA requirements over time.
We also appreciate the recommendation that ASTP/ONC and the RCE
establish steps and goals to guide how entities will transition to
TEFCA participation and agree that ASTP/ONC and the RCE should provide
resources and information to support the transition to TEFCA Exchange.
As such, ASTP/ONC and the RCE have recently released a plethora of
resources to assist entities considering transitioning to TEFCA
Exchange, which are available on the ASTP/ONC \9\ and RCE \10\
websites. In addition, we continue to support the transition to TEFCA
Exchange through regular webinars and information sessions for the
public.
---------------------------------------------------------------------------
\9\ https://www.healthit.gov/topic/interoperability/policy/trusted-exchange-framework-and-common-agreement-tefca.
\10\ https://rce.sequoiaproject.org/tefca/.
---------------------------------------------------------------------------
We appreciate the recommendation that ASTP/ONC adopt more specific
definitions of Participants and Subparticipants for TEFCA to reduce
ambiguity; however, we have not changed the definitions in this final
rule because we do not believe the definitions are ambiguous.
Last, we are aware that emergency medical service providers and
agencies may face obstacles in joining TEFCA, and we are considering
options for addressing such potential obstacles. We plan to conduct
additional outreach to the emergency medical service community to
better understand their concerns and the issues this community faces
and will consider other ways to assess the issue(s) moving forward.
Comments. One commenter suggested that ASTP/ONC should mandate that
health information exchanges respond to every QHIN request with sharing
data
[[Page 101785]]
and participate in TEFCA with at least one QHIN.
Response. We thank the commenter for their feedback. This comment
is out of scope for this rulemaking, and therefore, we decline to adopt
this suggested change. We also note that we generally believe that
participation in TEFCA should remain voluntary and decline to mandate
TEFCA participation.
Comments. A number of commenters expressed concern about the
interactions of TEFCA requirements with HIPAA requirements, and with
other ASTP/ONC and CMS regulations creating an overly complex
regulatory framework for interoperability. Commenters urged ASTP/ONC to
ensure that TEFCA requirements are compatible with other
interoperability and information blocking rulemaking. Another commenter
also urged ASTP/ONC to collaborate with CMS to provide endpoint
directories and use RESTful FHIR interoperability protocols.
These commenters noted the importance of keeping TEFCA
participation voluntary. A few commenters expressed concern that the
TEFCA requirements proposed together with other ASTP/ONC and CMS
regulations will pressure entities to solely engage with entities
connected to TEFCA.
Response. We thank commenters for their feedback and appreciate
commenters' concerns about how TEFCA requirements will interact with
other regulatory requirements. ASTP/ONC has worked, and will continue
to work, with our Federal partners, including CMS, in developing and
implementing TEFCA. We are working to align TEFCA requirements with
other ASTP/ONC, CMS, and OCR \11\ requirements when possible, and while
we have not required any entity to participate in TEFCA, we are trying
to ensure that TEFCA complements other Federal requirements to reduce
complexity and encourage more seamless nationwide exchange. For
example, as explained in more detail above, entities are able to comply
with both HIPAA (HIPAA Privacy, Security, and Breach Notification
Rules) and TEFCA. While ASTP/ONC may develop definitions and
requirements within TEFCA that are narrower or broader than
corresponding definitions and requirements within the HIPAA Rules,
ASTP/ONC does try to align TEFCA requirements with the requirements in
the HIPAA Rules when possible.
---------------------------------------------------------------------------
\11\ The HHS Office for Civil Rights has authority for
implementing and enforcing HIPAA.
---------------------------------------------------------------------------
Comment. One commenter recommended that we refer to, prioritize as
a goal, recognize, or focus on high-quality data within data sharing,
since one of TEFCA's goals is to create an atmosphere of trust.
Response. We thank the commenter for their feedback. We agree with
the importance of data quality within health information exchange. We
believe our proposals support data quality by advancing the
standardization of health information exchange and helping to improve
the completeness and comprehensiveness of data being exchanged.
However, additional operational aspects and practical implementations
of data quality measures are beyond the scope of this final rule.
Comment. Multiple commenters sought clarification on laboratory
involvement with respect to TEFCA proposals. One commenter requested
clarification about the participation of laboratories in QHINs and the
use of TEFCA as a means for health information exchange in the current
environment, where FHIR functionality is not available. Another
commenter sought clarification on the value proposition for rerouting
laboratory results through TEFCA, given that the existing HL7 v2
messaging framework effectively supports public health reporting. If
there is value in rerouting, they questioned what requirements must
QHINs meet to facilitate HL7 v2 messaging. The commenter expressed
concerns about how the process would introduce additional complexity by
requiring QHINs to convert HL7 v2 messages into XCDR, which the
receiving QHIN would then need to extract and forward to the connected
public health agency. Given these concerns, the commenter suggested
that ASTP/ONC and the RCE consider selectively endorsing existing
technologies, such as HL7 v2, to operate under the Common Agreement,
akin to how eCR reporting is implemented under Carequality.
Response. We appreciate this feedback, but these comments are out
of scope for this rule. We did not propose and are not finalizing
requirements for laboratories to participate in TEFCA or technical
requirements to facilitate HL7 v2 messaging within TEFCA.
Comment. One commenter recommended that TEFCA governance documents
be updated to define responsibilities for Participants and QHINS
related to disclosures and third-party vetting, as well as how requests
are intended to operate within the HIPAA framework and who would
monitor/enforce such requirements.
Response. We thank the commenter for the feedback. The HTI-2
Proposed Rule outlines the approach among ONC, the RCE, and QHINs to
monitor and enforce proposed requirements under TEFCA.
Comment. One commenter noted that requiring EHRs to demonstrate a
connection with an established QHIN or with health information
exchanges for health IT to achieve certification will help ensure
efficient data sharing and support interoperability goals.
Response. We appreciate the feedback on our proposals. However,
this comment is out of scope for this final rule, as we have neither
proposed nor are we finalizing a requirement for Health IT Modules to
demonstrate a connection with an established QHIN or with a health
information exchange for the Health IT Module to obtain certification
to any criterion or criteria under the ONC Health IT Certification
Program (Program). Nonetheless, we highlight that, as noted in the HTI-
2 Proposed Rule (89 FR 63510 and 63511), we intend to accomplish the
overall goal of full network-to-network exchange of health information
by establishing a floor for interoperability under TEFCA across the
country. We believe the suggested EHR requirement might conflict with
our intent to encourage innovation, facilitate incremental progress,
and promote flexibility.
Comment. One commenter shared multiple suggestions for encouraging
TEFCA participation. The commenter noted that TEFCA participation may
be encouraged by increasing the utility of TEFCA participation to an
entity's patients. They noted that incorporating a mechanism for
patients to correct or add to their interoperable records would be
beneficial. Rather than limiting TEFCA Individual Access Services (IAS)
requests to access and deletion options, they also suggested providing
an option for patients to amend or augment their records through a
patient portal so that these changes could be automatically
incorporated into their records exchanged through TEFCA.
Response. We thank the commenter for their suggestions. We agree
with the value of patient engagement. However, the suggestions are
beyond the scope of this final rule, as we did not propose and are not
finalizing related policies specifically designed encourage TEFCA
participation.
A. Subpart A--General Provisions
For the purposes of subpart A, we proposed (89 FR 63644) in Sec.
172.100 of the HTI-2 Proposed Rule the basis, purpose, and scope for
the proposed TEFCA provisions in 45 CFR part 172.
[[Page 101786]]
We proposed in Sec. 172.100(a) that the basis for these provisions
would be to implement section 3001(c)(9) of the PHSA (42 U.S.C. 300jj-
11(c)(9)). We proposed in Sec. 172.100(b) the dual purposes of
proposed part 172: (1) to ensure full network-to-network exchange of
health information; and (2) to establish a voluntary process for QHINs
to attest to adoption of the Trusted Exchange Framework and Common
Agreement. We explained that Sec. 172.100(b)(1) supports the statutory
basis because the organizational and operational policies covered by
part 172 would enable the exchange of health information among health
information networks using the common set of rules found in these
regulations. We also noted that Sec. 172.100(b)(2) supports the
statutory basis because it implements section 3001(c)(9)(D) of the
PHSA. We proposed in Sec. 172.100(c) the scope for part 172, which
would include: (1) minimum qualifications needed to be Designated as a
QHIN capable of trusted exchange under TEFCA; (2) procedures governing
QHIN Onboarding and Designation, suspension, termination, and further
administrative review; (3) attestation submission requirements for a
QHIN to attest to its adoption of TEFCA; and (4) ONC attestation
acceptance and removal processes for publication of the list of
attesting QHINs in the QHIN Directory.
In proposed Sec. 172.101, we specified the applicability of part
172 by proposing that part 172 would apply only to Applicant QHINs,
QHINs, and terminated QHINs. In the HTI-2 Proposed Rule, we noted that
our proposed QHIN definition in Sec. 172.102 captures suspended QHINs
(since a suspended QHIN is still a QHIN) and so we did not address them
separately in proposed Sec. 172.101. In Sec. 172.102, we proposed
definitions for certain terms in part 172. In the HTI-2 Proposed Rule,
we stated that we intended the definitions provided in the Common
Agreement to be consistent with these proposed definitions. We also
stated that differences in phrasing would generally be attributable to
differences in context, though in the case of any true conflict, we
stated that we intend the regulatory definitions to control.
Additionally, ASTP/ONC has hired a contractor to help administer
and implement TEFCA Exchange. This contractor, chosen through a
competitive solicitation, is known as the RCE. While the RCE is
currently one entity, in the future, we noted in the HTI-2 Proposed
Rule, ONC may choose to assign some or all of its responsibilities to a
different entity or multiple entities. We noted that assigning
responsibilities to a different or multiple entities in the future
could, for example, allow for more efficient use of resources or best
leverage expertise. In Sec. 172.103, ``Responsibilities ONC may
delegate to the RCE,'' we proposed that ONC may assign certain
responsibilities to such an entity or entities for these purposes. We
note that we changed the title of this section from the proposed
title--``Responsibilities ONC may delegate to the RCE''--to
``Responsibilities ASTP/ONC may delegate to the RCE'' because of the
recent change to the name of our office and to conform with similar
changes made throughout this final rule. In addition to changes to the
proposed text described below, we have also finalized references to
``ONC'' in subpart A of the proposed rule to instead refer to ``ASTP/
ONC.'' For further discussion of the use of ``ASTP/ONC,'' please see
the Executive Summary of this final rule.
We proposed in Sec. 172.103(a)(1) through (4) that ONC may assign
any of its responsibilities in subparts C (``QHIN Onboarding and
Designation Process'') and D (``Suspension'') and Sec. Sec. 172.501
(``QHIN self-termination'') and 172.503 (``Termination by mutual
agreement''). In Sec. 172.103(b), we proposed that any authority
exercised by the RCE under this section is subject to review by ONC
under subpart F (``Review of RCE Decisions'').
Comments. One commenter argued that any TEFCA expansion to new
purposes should be driven by Congressional mandate and conducted
transparently with opportunities for public input. The commenter
emphasized that an open process ensures that stakeholders' diverse
perspectives are considered fully and that the TEFCA framework evolves
to serve all stakeholders' collective interests. The commenter
cautioned against mission creep and recommended establishing clear
guardrails for any future expansion of TEFCA's use cases, including
rigorous evaluation, comprehensive needs assessments and industry
engagement. Other commenters advised ASTP/ONC to avoid sub-regulatory
guidance and instead follow standard rulemaking procedures, including
60-day public comment periods for proposed changes or additions to
TEFCA SOPs. One commenter expressed that all substantive issues and
core concepts, such as, but not limited to, foundational definitions of
the different exchange purposes, should be codified in regulation
following the notice and comment rulemaking process, rather than being
addressed in TEFCA documents such as SOPs, which do not undergo the
same rigorous review process as do regulations. Another commenter
further argued that any future regulatory changes should relate back to
the text of the Cures Act.
Response. We thank the commenter for the feedback. We have
developed and implemented TEFCA consistent with the 21st Century Cures
Act (section 3001(c)(9) of the PHSA, as added by the 21st Century Cures
Act (Pub. L. 114-255, Dec. 13, 2016)). That statute sets out at least
one broad statutory purpose: ensuring full network-to-network exchange
of health information. TEFCA as currently designed furthers that
purpose. We do agree that TEFCA should generally be related to that
goal or other ones suggested in the statute--for instance, that the
exchange should be ``trusted''--but we believe that statute envisions
that TEFCA will be flexible within that broad goal, consistent with the
need for flexibility in rapidly developing spaces like health
information technology and health information exchange. For example,
section 3001(c)(9)(B) identifies a list of potential topics the Common
Agreement ``may include,'' but does not require the Common Agreement to
address those topics or suggest that those topics are the only ones the
Common Agreement can address.
We appreciate the commenters' suggestion to follow standard
rulemaking procedures. As noted previously in this rulemaking, we
believe the inclusion of TEFCA provisions in this rulemaking will
strengthen the trust of interested parties in TEFCA and support its
success at scale. We likewise believe that TEFCA must remain flexible
and agile, in order to enable nationwide exchange at scale.
Comments. Commenters supported the general definitions related to
TEFCA proposed in regulatory text, suggesting that those terms may
arise in other regulatory programs and can be later cross-referenced.
Response. We thank commenters for their support and have finalized
the definitions related to TEFCA we proposed in Sec. 172.102 with some
modifications based on comments we received and as explained hereafter.
Comments. One commenter expressed concern about codifying
definitions from the Common Agreement in regulation and specifically
identified inconsistencies between the Common Agreement and the
proposed regulatory definitions. The commenter noted that some
definitions in the HTI-2 Proposed Rule do not fully align with the
Common Agreement (e.g., Threat Condition and Recognized Coordinating
Entity) and some of the definitions (e.g.,
[[Page 101787]]
XP Code) are included in the regulation but not used in the proposed
regulatory text. The commenter also noted that certain definitions in
the HTI-2 Proposed Rule refer to applicable SOPs (e.g., the definition
for Participant/Subparticipant Terms of Participation), while others do
not--including when the Common Agreement does refer to the SOP. For
example, Exchange Purposes in the proposed regulatory text omits
reference to SOPs, though the Common Agreement includes such reference.
The commenter states that leaving out references to SOPs could change
the meaning of the Common Agreement and render the SOPs inapplicable.
The commenter also stated that the term ``Responding Node'' is used in
the definition of Required Information but not defined in the
regulation. Further the commenter noted that some definitions refer to
``ONC (or an RCE)'' (e.g., threat condition), other times there is no
mention of an RCE, even though the Common Agreement includes such a
reference (e.g., Qualified Health Information). The commenter suggested
that differing definitions between the Common Agreement and the
regulatory text will lead to confusion and misinterpretation. The
commenter also expressed concern that, if such inconsistencies are
finalized in the regulatory text, they could necessitate subsequent
amendments to the Common Agreement that are inconsistent with the
public input used to establish the definitions in the Common Agreement.
Response. We appreciate the comments that opined on the potential
for confusion and misinterpretation related to certain proposed
definitions. We also appreciate the input related to clear and
consistent alignment between the regulatory definitions and the Common
Agreement. As noted in the proposed rule, we intend for the definitions
in this final rule to be consistent with the definitions in the Common
Agreement and the SOPs. We have adopted this approach to maintain
consistency between the Common Agreement and the regulatory text (89 FR
63642). However, in some cases we used different verbiage in the HTI-2
Proposed Rule to accommodate discussion of different contexts such as
future or past circumstances. In other cases, differences between
definitions in the regulation text and the Common Agreement may be the
result of inconsistencies in the level of specification between the
Common Agreement and definitions in the HTI-2 Proposed Rule. However,
we agree with the commenter that these differences in the definitions
between the Common Agreement or SOPs and this rulemaking may lead to
confusion and misinterpretation or the need for amendments to the
Common Agreement. Therefore, in this final rule we have addressed
inconsistencies by revising the final regulatory text wherever feasible
to directly align with definitions in the Common Agreement and SOPs.
Below we explain how, in response to public comment, we have further
aligned definitions in this final rule to the definitions in the Common
Agreement and SOPs.
Regarding the comment that leaving out references to SOPs could
change the meaning of the Common Agreement and render the SOPs
inapplicable, we reiterate our statement in the HTI-2 Proposed Rule
that in the case of any true conflict, we intend for the regulatory
definitions to control (89 FR 63644). We also note that, as stated, our
definitions in the HTI-2 Proposed Rule included references to SOPs (see
for example, Sec. 172.102, definitions of ``Governance Services'' and
``Participant/Subparticipant Terms of Participation''). We have further
updated definitions in this final rule to incorporate reference to SOPs
where necessary to align with the Common Agreement as described below.
Regarding the definition of ``Threat Condition,'' we agree with the
comment that the definition in this final rule should be identical to
the definition in the Common Agreement. Given our stated intent for the
TEFCA-specific definitions in these regulations to align with the
definitions in the Common Agreement and SOPs (89 FR 63642), and public
comments that clearly stated a preference for aligning the definitions
in this final rule to the definitions in the Common Agreement and SOPs,
we have finalized this definition to align with the definition in the
Common Agreement. As such, we have modified the proposed definition and
finalized the definition of ``Threat Condition'' as set out in the
regulatory text at the end of this document.
Regarding the definition of ``Recognized Coordinating Entity,'' we
agree with the commenter that the definition in this final rule should
be identical to the definition in the Common Agreement. Given our
intent for the TEFCA-specific definitions in these regulations to align
with the definitions in the Common Agreement and SOPs (89 FR 63642),
and public comments that clearly stated a preference for aligning the
definitions in this final rule to the definitions in the Common
Agreement and SOPs, we have finalized this definition to align with the
definition in the Common Agreement. As such, we have modified the
proposed definition and finalized the definition of ``Recognized
Coordinating Entity[supreg] (RCE[supreg])'' as set out in the
regulatory text at the end of this document.
Regarding the comment that ``XP Code'' is included in the
regulation, but not used in the regulatory text, we are not clear on
the specific issue the commenter is raising. We note that ``Exchange
Purpose Code or XP Code'' was defined in the regulatory text for the
Proposed Rule (89 FR 63806) as a code that identifies the Exchange
Purpose being used for TEFCA Exchange. We use only ``Exchange Purpose
Code'' in the discussion in this final rule, but we recognize
interested parties may commonly use ``XP Code''. Therefore, as noted in
the HTI-2 Proposed Rule, we interpret the ``or'' between ``Exchange
Purpose Code'' and ``XP Code'' in the definition to indicate that the
two terms are interchangeable. Accordingly, we have decided that use of
either term is appropriate throughout the regulation (89 FR 63806) and
have finalized the definition of ``Exchange Purpose Code or XP Code''
as proposed.
Regarding the comment that certain definitions refer to applicable
SOPs (e.g., the definition for Participant/Subparticipant Terms of
Participation) while others do not, we note that this inconsistency was
not intentional. Given our intent for the TEFCA-specific definitions in
these regulations to align with the definitions in the Common Agreement
and SOPs (89 FR 63642), and the public comments that clearly stated a
preference for aligning the definitions in this final rule to the
definitions in the Common Agreement and SOPs, we have finalized the
definition of ``Exchange Purpose(s) or XP(s)'' to align with the
definition in the Common Agreement. As such, we have modified the
definition of ``Exchange Purpose(s) or XP(s)'' to align with the Common
Agreement definition, which includes mention of SOP(s).
Regarding the comment that the term ``Responding Node'' was
included in the proposed definition of ``Required Information'' but not
proposed to be defined in Sec. 172.102, we note that this
inconsistency was not intentional. In order to address commenters'
reasonable expectation that we would define terms necessary to
understand other terms we proposed to define where such definitions are
consistent with those in the Common Agreement per our stated intent of
alignment (89 FR 63642), we have finalized the definition of
``Responding Node'' in Sec. 172.102.
[[Page 101788]]
Regarding the comment that some definitions refer to ``ONC (or an
RCE)'' (e.g., Threat Condition), and other times there is no mention of
an RCE even though the Common Agreement includes such a reference
(e.g., Qualified Health Information Network), we intentionally
referenced the RCE in certain circumstances and not others in the
definitions we proposed in Sec. 172.102. Our goal with the proposed
definitions was to afford ourselves flexibility in the event that one
day there is no longer an RCE. We emphasize, however, that the current
RCE, the Sequoia Project, is now in the second year of a five-year
contract with ASTP/ONC.
Comments. One commenter identified what they believed to be two
typos in proposed 45 CFR 172.102. The commenter noted that a few
definitions, notably the proposed definitions for the HIPAA Privacy
Rule and the HIPAA Security Rule, reference the regulations at 45 CFR
part 160 and subparts A and E of 45 CFR part 164, as well as to 45 CFR
part 160 and subparts A and C of 45 CFR part 164. The commenter asked
for clarification on what subparts were meant to be referenced.
Response. The terms HIPAA Privacy Rule and the HIPAA Security Rule
are both defined in Sec. 172.102 by referencing their codifications in
the CFR. Both rules have slightly different citations. The citation for
the HIPAA Privacy Rule is 45 CFR part 160 and subparts A and E of 45
CFR part 164. The HIPAA Security Rule is located at 45 CFR part 160 and
subparts A and C of 45 CFR part 164. Because those are the correct
citations for the HIPAA Privacy and Security Rules, we have finalized
the HIPAA Privacy Rule and the HIPAA Security Rule definitions in Sec.
172.102 as proposed.
Comments. One commenter recommended a revision to the definition of
``Framework Agreements'' to include only those documents for which a
draft was made available to the public and the public has some
opportunity to provide input on the draft before a final version is
effective. The commenter requested that we require such a process for
all Framework Agreements. The commenter noted that the RCE should make
SOP drafts available for public feedback or any other transparent
process around their establishment and review. The commenter noted
further that under the proposed rule, ASTP/ONC can review an RCE
decision, but that there is no process for a QHIN or a participant to
appeal or require formal review of an SOP. The commenter cited an SOP
issued last summer that the commenter believed significantly narrowed
the scope of required response for treatment purposes, which it said
cut off access to the networks for hundreds of thousands of patients.
The commenter believed that the proposed rule would allow this result
to happen again.
Response. We appreciate the comments. However, the definition of
``Framework Agreement(s)'' we proposed tracks the definition in the
Common Agreement, and we believe that deviating from the definition in
the Common Agreement for such a foundational concept might be confusing
or suggest differences between the meaning of Framework Agreements in
the Common Agreement and the regulation that we do not intend. Nor do
we agree with the commenters who suggest that we should require more
process for SOPs than is laid out in the Common Agreement (at section
5.3 of version 2.0). That process--to which QHINs, Participants, and
Subparticipants agree by signing the Framework Agreements--balances the
need for input by the public with the need to respond quickly in a
fast-developing space. We understand that, as the commenter points out,
sometimes individual entities will disagree with particular SOPs, but
that is part of the balance struck in the Common Agreement's
procedures, and we decline the invitation to impose a higher regulatory
standard on SOPs than set forth in the Common Agreement. We believe
that transparency is essential to TEFCA's success because it is in the
best interest of individuals whose health information is exchanged via
TEFCA and is central to the efforts of HHS to enhance and protect the
health and well-being of all Americans. Since we began developing TEFCA
following the passage of the Cures Act in 2016, ASTP/ONC and the RCE
have held dozens of webinars, listening sessions, and other feedback
opportunities with the public and interested communities to promote
transparency and provide the opportunity for public comment. We will
continue to offer robust feedback opportunities related to TEFCA in the
future. In addition, ASTP/ONC's processes for gathering feedback on
TEFCA documents, processes, and procedures have been transparent and
consistent--and the feedback we have received has informed the
development of and changes to the Common Agreement and Terms of
Participation, both of which are included in the finalized definition
of ``Framework Agreement(s),'' as well as SOPs, which are not.
We do not believe that the appeals process we have finalized in 45
CFR part 172 should be expanded to include appeals of SOPs. Section 5
of the Common Agreement \12\ discusses TEFCA's change management
process for updating the Common Agreement and SOPs. This process was
developed with significant input from prospective QHINs, interested
communities, Federal partners, and the public. It provides
opportunities for input from multiple different kinds of entities that
participate in TEFCA. ASTP/ONC must approve all changes, additions, or
deletions. In addition, section 15 of the Common Agreement \13\
addresses dispute resolution, and section 15.6 addresses the escalation
of certain disputes to ASTP/ONC.\14\ We note these sections to
highlight that the governance in place for TEFCA ensures that changes
to TEFCA's policies and procedures are informed by feedback and driven
by a strong, consistent process with ASTP/ONC oversight embedded
throughout the processes.
---------------------------------------------------------------------------
\12\ Common Agreement for Nationwide Health Information
Interoperability (healthit.gov).
\13\ Id.
\14\ Id.
---------------------------------------------------------------------------
Besides the revisions to the Definitions section discussed above,
subpart A was finalized as proposed with a few modifications.
Specifically, the name ``ONC'' used in the title of proposed Sec.
171.103, as well as the proposed text of Sec. 171.103(a), has been
finalized as ``ASTP/ONC'' to reflect the recent change to our office's
name and ensure consistency in the use of ASTP/ONC throughout this
final rule. In addition, we have added language requiring an RCE to
seek and receive ASTP/ONC's prior authorization before making certain
decisions (e.g., interim or final designation decisions (Sec.
172.303(b)), setting onboarding requirements and determining a QHIN has
complied with those requirements (Sec. 172.304(b) and (c)), and
deeming a QHIN application withdrawn for failure to respond to
information requests during the designation process (Sec. 172.305(c)).
We have added language to Sec. 172.103(b) to clarify that ASTP/ONC
cannot subdelegate the authority to grant prior authorization to an
RCE. These revisions, taken together, help to ensure that an RCE
remains subordinate to ASTP/ONC and provides only fact-gathering,
ministerial, and administrative support to ASTP/ONC.
B. Subpart B--Qualifications for Designation
In the HTI-2 Proposed Rule (89 FR 63644), we discussed that in
subpart B,
[[Page 101789]]
we proposed qualifications for Designation. In Sec. 172.200, we
proposed to tie QHIN status to meeting the requirements specified in
Sec. 172.201. We proposed that an Applicant QHIN (as we proposed to
define it in Sec. 172.102) would need to meet all requirements in
Sec. 172.201 to be Designated, and a QHIN would need to continue to
meet all requirements in Sec. 172.201 to maintain its Designation. We
noted that the requirements we proposed in Sec. 172.201 would be
ongoing; a QHIN that does not meet those requirements at all times
would be subject to suspension or termination, consistent with the
regulations we proposed in subparts D and E of part 172. In the HTI-2
Proposed Rule, we stated that the continuing obligation to meet the
requirements in Sec. 172.201 would help to ensure the reliability of
TEFCA Exchange and that QHINs could not maintain their status based on
technology and standards that have become obsolete. Because the
obligations would be ongoing, throughout this section we referred to
Applicant QHINs as well as Designated QHINs as ``QHINs'' unless there
was a need to differentiate.
As we explained in the HTI-2 Proposed Rule (89 FR 63645), the
Designation qualifications proposed in Sec. 172.201 described certain
requirements for Designation. For an entity to become a QHIN, that
entity must sign the Common Agreement, thus memorializing its agreement
to the comprehensive Designation requirements--as well as other
requirements--for trusted exchange under TEFCA. The comprehensive
Designation requirements in the Common Agreement correspond to the
proposed requirements included in this subpart.
In Sec. 172.201, we proposed Designation requirements in three
categories: (a) ownership; (b) exchange requirements; and (c)
Designated Network Services.
In Sec. 172.201(a), we proposed the ownership requirements. In
Sec. 172.201(a)(1), we proposed that a QHIN must be a U.S. Entity, as
we proposed to define ``U.S. Entity/Entities'' in Sec. 172.102. Under
that proposed definition, a U.S. Entity must be a corporation, limited
liability company, partnership, or other legal entity organized under
the laws of a state or commonwealth of the United States or the Federal
law of the United States, be subject to the jurisdiction of the United
States and the state or commonwealth under which it was formed, and
have its principal place of business be in the United States under
Federal law. Additionally, we proposed that none of the entity's
directors, officers, or executives, and none of the owners with a five
percent (5%) or greater interest in the entity, may be listed on the
Specially Designated Nationals and Blocked Persons List published by
the United States Department of the Treasury's Office of Foreign Asset
Control or on the Department of Health and Human Services, Office of
Inspector General's List of Excluded Individuals/Entities. We explained
that this requirement would help to promote organizational and
operational policies that enable the exchange of health information
among networks by ensuring that those who actually control the health
information exchanged under these provisions are subject to U.S. laws,
and it would help to avoid giving access to that information to actors
whom the government has previously identified as national security or
fraud risks.
We requested comment on whether the above approach, including the
specific five percent (5%) threshold, will effectively limit access of
bad actors trying to join TEFCA as a QHIN, or whether commenters
believe the threshold should be a different percentage.
In Sec. 172.201(a)(2), we proposed that an Applicant QHIN must not
be under Foreign Control, which is a term we proposed to define in
Sec. 172.102. If, in the course of reviewing a QHIN application, ONC
believes or has reason to believe the Applicant QHIN may be under
Foreign Control, ONC would refer the case to the HHS Office of National
Security (ONS) for review. If information available to ONS supports a
determination of Foreign Control, ONS will notify ONC. An application
will be denied if ONS notifies ONC that the Applicant is under Foreign
Control.
Given the scale of the responsibilities that a Designated QHIN
would have with respect to supporting health information exchange and
the importance that healthcare data has to the critical infrastructure
of our nation's health care system, we noted in the HTI-2 Proposed Rule
that we believe that a QHIN should not be under Foreign Control. We
stated we believe the requirements proposed in Sec. 172.201(a)(1) and
(2), in conjunction with the proposed definitions that those provisions
reference, are necessary to ensure that all QHINs are subject to United
States law and that compliance by QHINs is enforceable under United
States law. Further, we stated these proposals are designed to
strengthen the security of the network. We added in the HTI-2 Proposed
Rule that we believe that the above proposals would promote
organizational and operational policies that enable the exchange of
health information among networks by minimizing the risk to TEFCA that
may be posed by foreign state actors who wish to harm the United
States, lessening the risks of subjecting QHINs to potentially
conflicting foreign laws, and encouraging trust in the security of
exchange under the system.
In the HTI-2 Proposed Rule (89 FR 63645), we noted that within the
proposed definition of ``U.S. Entity/Entities'' in Sec. 172.102, we
proposed that for an entity seeking to become a QHIN to meet the
definition, none of the entity's directors, officers, or executives,
and none of the owners with a five percent (5%) or greater interest in
the entity, can be listed on the Specially Designated Nationals and
Blocked Persons List published by the United States Department of the
Treasury's Office of Foreign Asset Control or on the Department of
Health and Human Services, Office of Inspector General's List of
Excluded Individuals/Entities. We also noted that we believe the five
percent (5%) threshold strikes the right balance between protecting the
security of the network from high-risk or known bad actors and
achieving practical administrability of TEFCA. We noted individuals
with less than five percent (5%) ownership in an entity would likely
have limited means of influencing the actions of an entity connected to
TEFCA. In the HTI-2 Proposed Rule, we stated we believe that entities--
particularly those with a large number of shareholders--would face
undue hardship without this sort of exception for small shareholders.
In the HTI-2 Proposed Rule, we noted this regulation only would provide
the standard that ONC would apply when evaluating QHINs; it would not
supersede any stricter requirements imposed by other applicable laws,
including, for example national security laws. It remains the
responsibility of QHINs (and any other entity) to comply with all
applicable laws.
In Sec. 172.201(b), we proposed exchange requirements for QHINs.
In the HTI-2 Proposed Rule, we stated we believe these exchange
requirements are necessary to build a data sharing infrastructure that
is private and secure and that meets all the requirements of PHSA
section 3001(c)(9). We believe each of the exchange requirements below
is important to the implementation and operationalization of TEFCA
Exchange, as described in Sec. 172.201, at scale. We proposed that an
entity seeking to become a QHIN must, beginning at the time of
application,
[[Page 101790]]
either directly or through the experience of its parent entity, meet
certain exchange requirements, including: (1) be capable of exchanging
information among more than two unaffiliated organizations; (2) be
capable of exchanging all Required Information (as that term is defined
in Sec. 172.102); (3) be exchanging information for at least one of
the Exchange Purposes (as that term is defined in Sec. 172.102)
authorized in the Common Agreement or an SOP(s); (4) be capable of
receiving and responding to transactions from other QHINs for all
Exchange Purposes; and (5) be capable of initiating transactions for
the Exchange Purposes that such entity will permit its Participants and
Subparticipants to use through TEFCA Exchange.
In the HTI-2 Proposed Rule we stated that, collectively, we believe
these requirements are tailored to help ensure that a QHIN is capable
of TEFCA Exchange, supports a trusted exchange framework, and maintains
consistent practices of exchanging information at scale to support
nationwide interoperability. The first requirement, proposed in Sec.
172.201(b)(1), that the entity seeking to become a QHIN be capable of
exchanging information among more than two unaffiliated organizations,
is a requirement that would ensure a minimum technical ability exists
and that exchange would be enabled beyond just the QHIN itself.
We discussed (89 FR 63646) that the second requirement, proposed in
Sec. 172.201(b)(2), is also a minimum condition, except it is directed
at the minimum quantity of data a QHIN must be capable of exchanging.
This proposed requirement would ensure that every QHIN can exchange
Required Information (as that term is defined in proposed Sec.
171.102) and provides certainty to Participants and Subparticipants who
seek to join a QHIN that there is a minimum scope of data that they can
reliably expect to be able to exchange via TEFCA Exchange Purposes.
The proposed requirements in Sec. 172.201(b)(3) through (5) are
intended to establish basic parameters and expectations for QHINs in
order to qualify for Designation. We proposed, in Sec. 172.201(b)(3),
that a QHIN or Applicant QHIN must be exchanging information for at
least one Exchange Purpose. If a QHIN is not exchanging information for
at least one of the Exchange Purposes authorized under TEFCA (for
examples, see the ``Exchange Purpose'' definition proposed in Sec.
172.102) at the time of application, we noted in the HTI-2 Proposed
Rule that it is not meeting a minimum condition necessary for such
exchange to occur and cannot be Designated. While exchange for an
Exchange Purpose under TEFCA requires an Exchange Purpose Code,
Applicant QHINs can demonstrate that they are meeting the requirement
to exchange information for at least one of the Exchange Purposes by
conducting exchange for an Exchange Purpose without use of an Exchange
Purpose Code.
We proposed in Sec. 172.201(b)(4) to require a QHIN to be capable
of receiving and responding to transactions from other QHINs for all
Exchange Purposes, to ensure that health information can be exchanged
among health information networks under TEFCA. For this same reason, we
proposed in Sec. 172.201(b)(5) to require a QHIN to be capable of
initiating transactions for the Exchange Purposes that such entity will
permit its Participants and Subparticipants to use through TEFCA
Exchange. We noted that ensuring that QHINs will respond to Participant
or Subparticipant requests for information, and that the Participants
or Subparticipants are able to receive the information from QHINs,
enables health information exchange among the QHINs, Participants and
Subparticipants.
We noted in the HTI-2 Proposed Rule that a QHIN's ability to
transact for all Exchange Purposes is a threshold requirement for an
entity that seeks Designation and is essential for ensuring that the
TEFCA framework facilitates exchange for each Exchange Purpose
authorized in the Common Agreement or an SOP(s) for implementation. We
also noted that, without this requirement, there would be no certainty
that the TEFCA framework would advance exchange beyond the Treatment
Exchange Purpose, which is the most prevalent purpose for health
information exchange today and the purpose of use that most health care
entities seeking Designation would be most familiar with. TEFCA's
network connectivity--including this requirement that QHINs have the
ability to exchange for all Exchange Purposes--and scale would help,
for example, health care providers gain access to more comprehensive
and complete information about their patients, which can support
improved care, better outcomes, decreased provider burden, and reduced
costs.
Entities performing TEFCA Exchange as described in Sec. 172.201
would have the option to request information for all Exchange Purposes.
At the time of publication of this final rule, TEFCA supports exchange
for the following Exchange Purposes: treatment; payment; health care
operations; public health; Individual Access Services (IAS), and
government benefits determination. Over time, additional Exchange
Purposes may be added. Information regarding whether responses are
required for a given Exchange Purpose would be included in an SOP.
In Sec. 172.201(c), we proposed that an Applicant QHIN must meet
certain Designated Network Services requirements. Based on our
experience in the health IT ecosystem, we noted that we believe
adequate network performance is important for the success of TEFCA, as
those participating in TEFCA Exchange would be most likely to trust the
TEFCA infrastructure if it is performing at a high level. We also
expressed that unreliable network performance would dilute confidence
in the network and discourage participation.
In Sec. 172.201(c)(1), we proposed that a QHIN must maintain the
organizational infrastructure and legal authority to operate and govern
its Designated Network. For instance, under this proposal, QHINs would
be required to have a representative and participatory group or groups
that approve the processes for fulfilling the TEFCA governance
functions and that participate in governance for the Designated
Network. In Sec. 172.201(c)(2), we proposed that a QHIN must maintain
adequate written policies and procedures to support meaningful TEFCA
Exchange as described in Sec. 172.201 and fulfill all responsibilities
of a QHIN in the part (which an entity agrees to by signing the Common
Agreement). For instance, under this proposal, QHINs would be required
to have a detailed written policy that describes the oversight and
control of the technical framework that enable TEFCA Exchange.
In Sec. 172.201(c)(3), we proposed that a QHIN must maintain a
Designated Network (as proposed to be defined in Sec. 172.102) that
can support a transaction volume that keeps pace with the demands of
network users. We noted in the HTI-2 Proposed Rule that since TEFCA is
a nationwide network and will be used daily to support various health
data needs to inform care delivery, quality assessments, public health,
and health care operations, QHINs must be capable of transacting high
volumes of data reliably and at scale. In Sec. 172.201(c)(4), we
proposed that a QHIN must maintain the capacity to support secure
technical connectivity and data exchange with other QHINs. One of the
most fundamental aspects of interoperable network exchange is
[[Page 101791]]
technical connectivity, which makes network-to-network exchange
possible and, therefore, was important to include in this regulation.
In Sec. 172.201(c)(5) through (7), we proposed certain
requirements related to governance for TEFCA to ensure all QHINs are
aligned and able to manage risk effectively. In Sec. 172.201(c)(5), we
proposed that a QHIN must maintain an enforceable dispute resolution
policy governing Participants in the Designated Network that permits
Participants to reasonably, timely, and fairly adjudicate disputes that
arise between each other, the QHIN, or other QHINs. This proposed
requirement would afford flexibility to QHINs to establish their own
dispute resolution process while ensuring the process is timely and
fair. We expressed that disputes may arise for a variety of reasons, so
the QHIN, as the entity overseeing its Participants, is best placed to
handle such disputes in a way that minimizes disruptions for the rest
of the network. Ensuring that a QHIN has such a dispute resolution
policy would, therefore, likely minimize such disruptions.
Similarly, in Sec. 172.201(c)(6), we proposed that a QHIN maintain
an enforceable change management policy consistent with its
responsibilities as a QHIN. A change management policy establishes the
standard procedures to approve different types of changes to TEFCA
documents (e.g., standard operating procedures) and policies and will
help to avoid changes that are disruptive or in conflict across
entities.
In Sec. 172.201(c)(7), we proposed that a QHIN must maintain a
representative and participatory group or groups with the authority to
approve processes for governing the Designated Network. We explained
(89 FR 63647) that the participatory network governance built into the
TEFCA infrastructure is important to ensure that the requisite
engagement exists between QHINs, Participants, and Subparticipants
engaged in TEFCA Exchange. In the HTI-2 Proposed Rule, we stated that
we believe the above requirements are fundamental aspects of a network-
of-networks focused on participatory governance and the ability to
adapt to an ever-changing health information exchange landscape.
In the HTI-2 Proposed Rule, regarding the proposed requirement in
Sec. 172.201(c)(7) specifically, we emphasized that TEFCA uses a
representative and participatory governance structure. Representative
and participatory governance gives those participating in the network a
role in informing the policies and decisions that ultimately would
affect them. We explained that such a governance structure helps to
motivate health care entities and their networks to voluntarily join
TEFCA. We also noted that we believe that requiring a QHIN to have a
representative and participatory group or groups that has the ability
to review and provide input on the governance requirements of the
QHIN's Designated Network is an optimal approach for this requirement.
In Sec. 172.201(c)(8), we proposed that an entity seeking to
become a QHIN must maintain privacy and security policies that permit
the QHIN to support TEFCA Exchange. We identified certain policies that
fell within this requirement (89 FR 63647), which we have slightly
modified here for clarity and technical accuracy, and which included
the following:
Maintaining certification under a nationally recognized
security framework by a qualified, independent third party that ensures
its assessments are consistent with the NIST Cybersecurity Framework
(CSF) (using both NIST 800-171 (Rev. 2) and NIST 800-53 (Rev. 5) as a
reference), ensuring the QHIN performs HIPAA Security Rule risk
analyses (as required by Sec. 164.308(a)(1)(ii)(A)) and verifies all
requirements for technical audits and assessments are met.
Having a qualified, independent third party complete an
annual security assessment consistent with the NIST Cybersecurity
Framework (CSF) (using both NIST 800-171 (Rev. 2) and NIST 800-53 (Rev.
5) as a reference). The third party would review the QHIN for
consistency with HIPAA Security Rule risk analysis requirements at
Sec. 164.308(a)(1)(ii)(A). Additionally, the annual security
assessment must include comprehensive internet-facing penetration
testing, must include an internal network vulnerability assessment, and
must use methodologies and security controls consistent with Recognized
Security Practices, as defined by Public Law 116-321 (42 U.S.C. 17931
and 300jj-52).
Employing a Chief Information Security Officer with
executive-level responsibility.
Disclosing any breaches of electronic protected health
information (including disclosure of any such breaches within the three
(3) years preceding applying to become a QHIN) to the RCE and to all
QHINs that are likely impacted.
Complying with 45 CFR part 164, subparts A, C, and E, as
applicable, as if the QHIN were a covered entity as described in that
regulation.
Maintaining and complying with a written privacy policy.
We noted in the HTI-2 Proposed Rule that these policies and
requirements would provide privacy and security protections for the
health information that will be exchanged through TEFCA. All entities
that elect to participate in TEFCA, including entities that are not
regulated under HIPAA, would be expected to meet a high bar for privacy
and security given the nature of the data being exchanged. We stated
that it is unlikely that an entity would wish to participate in a
network without privacy and security standards, thereby inhibiting
TEFCA exchange.
To further support the security of TEFCA, we proposed in Sec.
172.201(c)(9) that a QHIN must maintain data breach response and
management policies that support secure TEFCA Exchange. For instance,
given the number of electronic connections TEFCA will support, a data
breach response and management policy would support a transparent
process and timely awareness of a data breach or other security events
(e.g., ransomware attacks) which could enable the QHIN to manage secure
connectivity services without disrupting patient care.
In Sec. 172.201(c)(10), we proposed that a QHIN must maintain
adequate financial and personnel resources to support all its
responsibilities as a QHIN, including, at a minimum, sufficient
financial reserves or insurance-based cybersecurity coverage, or a
combination of both. We noted in the HTI-2 Proposed Rule that this
requirement would help to provide stability to TEFCA in the event of
unexpected financial or economic occurrences--whether system-wide or
specific to individual QHINs. For instance, we stated that this
requirement could be met if the QHIN has available a minimum amount of
cash, cash equivalents, borrowing arrangements (e.g., a line of
credit), or a mix of the three that is equal to six (6) calendar months
of operating reserves. Regarding insurance requirements, a QHIN's
general liability coverage and the cyber risk/technology coverage
should each have limits of at least $2,000,000 per incident and
$5,000,000 in the aggregate, which limits can be met through primary
coverage, excess coverage, available internal funds, or a combination
thereof. We noted that the requirements proposed herein may be
insufficient for larger QHINs and recognized that certain QHINs will
meet and exceed these minimums.
QHINs will be the central connection points for TEFCA Exchange,
responsible for routing queries, responses, and messages among many
participating entities and individuals. We proposed,
[[Page 101792]]
in Sec. 172.201(c)(10), that QHINs must have sufficient financial
resources and personnel capacity to perform such functions
successfully. We also noted we believe that QHINs must be prepared to
address incidents should they arise and must have the ability to
fulfill potential liability obligations, either through insurance,
sufficient financial reserves, or some combination of the two.
We stated that one goal of TEFCA is to support patients gathering
their healthcare information. In Sec. 172.202, ``QHINS that offer
individual access services,'' we proposed IAS requirements for a QHIN
to obtain and maintain Designation under TEFCA if that QHIN voluntarily
offers IAS. In Sec. 172.202(a), we proposed that a QHIN would be
required to obtain express consent from any individual before providing
IAS, as defined in Sec. 172.102. We noted that we believe this is an
important requirement so that individuals who use IAS that a QHIN
offers are informed of the privacy and security practices that are
being employed to protect their data. In Sec. 172.202(b), we proposed
that a QHIN would be required to make publicly available a privacy and
security notice that meets minimum TEFCA privacy and security standards
to support transparent exchange practices. We stated that we believe
this requirement would provide transparency to all individuals who are
considering using IAS regarding how their data is protected and secured
by a QHIN providing IAS.
In Sec. 172.202(c), we proposed a QHIN that is the IAS provider
for an individual would be required to delete the individual's
Individually Identifiable Information (as defined in Sec. 172.102)
maintained by the QHIN upon request by the individual except as
prohibited by Applicable Law or where such information is contained in
audit logs. We noted (89 FR 63648) that we believe this requirement
would provide individuals with reassurance that they control access to
their data. We also expressed that we believe the carve out for audit
logs is appropriate because audit logs are generally used to provide
chronological records of system activities and should not be deleted.
In Sec. 172.202(d), we proposed that a QHIN would be required to
permit any individual to export in a computable format all of the
individual's Individually Identifiable Information maintained by the
QHIN as an IAS provider. We stated that we believe this requirement
would ensure that individuals may access, control, and use their own
data held by an IAS provider.
In Sec. 172.202(e), we proposed that all Individually Identifiable
Information the QHIN maintains must satisfy certain criteria,
including: (1) all Individually Identifiable Information must be
encrypted; (2) without unreasonable delay and in no case later than
sixty (60) calendar days following discovery of the unauthorized
acquisition, access, Disclosure, or Use of Individually Identifiable
Information, the QHIN must notify, in plain language, each individual
whose Individually Identifiable Information has been or is reasonably
believed to have been affected by unauthorized acquisition, access,
Disclosure, or Use involving the QHIN; and (3) a QHIN must have an
agreement with a qualified, independent third-party credential service
provider and must verify, through the credential service provider, the
identities of individuals seeking IAS prior to the individuals' first
use of such services and upon expiration of their credentials. We noted
that to the extent the QHIN is already required by Applicable Law to
notify an individual as described in proposed Sec. 172.202(e)(2), we
did not propose that it be required to duplicate such a notification.
Lastly, the proposed requirement in Sec. 172.202(e)(3) would set a
baseline for proving the identity of IAS users that are requesting data
via TEFCA Exchange.
Comments. Multiple commenters expressed support for the provisions
of this subpart that will establish the qualifications for HINs to
receive and maintain Designation as a QHIN, including as an IAS
provider. Multiple commenters also expressed support for the proposed
qualification requirements. Other commenters cautioned that additional
requirements of QHINs could limit entities from participating in TEFCA
or deter them from considering becoming a QHIN.
Response. We appreciate commenters' support for the proposed
qualifications for QHIN Designation. We also understand commenters'
caution to ASTP/ONC regarding additional requirements and appreciate
the need within TEFCA to establish strong guardrails for QHIN
participation while not unduly burdening Applicant QHINs and QHINs. We
agree with commenters that additional requirements for QHINs are not,
at this time, appropriate as we work to balance flexibility,
participation, and our commitment to strong guardrails for QHIN
participation. The current requirements were developed based on ASTP/
ONC's and the RCE's collective experience with health information
exchange and were informed by a wide range of interested communities
and the public. As TEFCA evolves, we will continue to consider ways to
strengthen it and ensure that QHINs are held to a high but reasonable
standard. In this final rule, we have finalized all subpart B proposals
without revision.
Comments. One commenter asked whether any changes to the proposed
QHIN designation process would be retroactively applicable to entities
currently undergoing that process. Another commenter expressed support
for the previous ``sub-regulatory'' approach for establishing criteria
and requirements for QHIN Designation that allowed for flexibility.
Some commenters also recommended new requirements. Commenters
recommended aligning qualifications with existing Department of
Homeland Security standards and/or FedRAMP certification standards for
cybersecurity. Another commenter recommended background checks,
validation of National Provider Identifiers (NPIs), and a rigorous
review of organizational credentials. A separate commenter encouraged
ASTP/ONC's continued emphasis on and improvement of security and
privacy requirements. Another commenter recommended that we leverage
QHIN qualification criteria to require that pharmacists, with an
established treatment relationship with patients, have access to
clinical data.
Response. Regarding the question whether any changes to the
proposed QHIN Designation process would be retroactively applicable to
entities currently undergoing that process, we note that we are
finalizing the QHIN Designation requirements and process within the
HTI-2 Proposed Rule, and as discussed above, without revision in this
final rule. The provisions will be effective upon the effective date
specified for this final rule in the ``effective date'' section. The
qualification requirements we have finalized in 45 CFR part 172,
subpart B, align with and have no substantive differences from the
requirements for and process followed by all Designated QHINs and
Applicant QHINs.
We appreciate the comment in support of the previous sub-regulatory
approach that we have utilized in TEFCA to this point to establish the
processes within the TEFCA framework.
We appreciate the suggestions for updating the existing QHIN
Designation requirements within the TEFCA framework (e.g., aligning
qualifications with existing Department of Homeland Security standards
and/or FedRAMP certification standards for cybersecurity, improving
privacy and security requirements, emphasis on background checks,
validation of NPIs, and a
[[Page 101793]]
rigorous review of organizational credentials). We emphasize our
confidence in the strength of the existing requirements. We may
consider some of these suggested changes for future rulemaking. While
we cannot adopt the various new QHIN Designation requirements
recommended by commenters because we did not propose them, we do note
that we consulted with various Federal agencies and industry partners
in developing the QHIN Designation requirements around privacy and
security that align with Federal agency participation requirements.
We appreciate the recommendation that we leverage QHIN
qualification criteria to require that pharmacists, with an established
treatment relationship with patients, have access to clinical data;
however, we do not understand how the QHIN qualification criteria
directly relate to the suggested requirement. We encourage the
commenter to review the Exchange Purpose Vetting Process SOP, which
provides helpful information for entities that seek to exchange
information for treatment via TEFCA.
As noted in our response to comments above, we proposed to adopt in
regulation certain provisions related to TEFCA in order to provide
greater process transparency and further implement section 3001(c)(9)
of the PHSA, as added by the Cures Act. We believe codifying TEFCA
through regulation facilitates alignment with the broader legislative
goals around nationwide health information exchange, interoperability,
privacy, and security.
Comments. One commenter suggested that the qualification related to
transaction volume establish specific performance metrics for the speed
of data transfer. In particular, the commenter argued that 48-hour
turnarounds for use cases such as prior authorization would be
untenable.
Response. We appreciate commenter's suggestion related to
transaction volume. The RCE and ASTP/ONC plan to develop performance
metrics and service level agreements for TEFCA as we develop more
experience and a better understanding about the needs of the TEFCA
community. We will consider this comment as we develop the performance
metrics and service level agreements for TEFCA.
Comments. One commenter suggested that the 5% ownership requirement
for ``bad'' actors should not be increased and that lowering the
threshold could be appropriate for good cause. Another commenter
suggested that ASTP/ONC clarify that the 5% threshold is for an
individual and that collusion between multiple individuals would have a
threshold of over 25%. The commenter was supportive of the proposal
that QHINs would be ineligible if they are found to be under Foreign
Control.
Response. We thank the commenters for the suggestion and the
support of our proposal regarding Foreign Control. We continue to
believe, based on significant feedback from interested communities,
cybersecurity and security experts, and the public, that the five
percent (5%) threshold is appropriate and strikes the right balance
between protecting the security of the network from high-risk and known
bad actors and achieving practical administrability of TEFCA.
Individuals with less than 5% ownership in an entity would likely have
limited means of influencing the actions of an entity connected to
TEFCA. We appreciate the reasoning for the proposal of an aggregate
threshold but have decided not to implement that suggested change
because it would be extremely difficult and burdensome to determine
whether a group of actors is ``colluding'' as suggested by commenter,
as determining whether ``collusion'' is present could require
information that may not be readily available.
Comments. One commenter suggested that we publish all
``Designation'' documentation on our website for public review.
Response. While ASTP/ONC supports and promotes transparency where
possible and appropriate, we decline to adopt the commenter's
recommendation in this instance. Foremost, we did not propose such an
approach and thus all potentially affected entities have not had an
opportunity to comment on the matter. In addition, some of the
information received from Applicant QHINs may include confidential
information.
C. Subpart C--QHIN\TM\ Onboarding and Designation Processes
In the HTI-2 Proposed Rule, we stated that (89 FR 63648) TEFCA
establishes a universal floor for interoperability across the country
through a network of networks. In 2019, ONC issued a Notice of Funding
Opportunity and subsequently awarded a cooperative agreement to The
Sequoia Project to serve as the RCE to support the implementation of
TEFCA. In August 2023, ONC awarded The Sequoia Project a five-year
contract to continue serving as the RCE.
To establish nationwide health information exchange, TEFCA calls
for the Designation of QHINs--HINs that agree to the common policy,
functional, and technical requirements for TEFCA Exchange. The QHIN
Designation Requirements as described in Sec. 172.201 define the
baseline legal and technical requirements for secure information
sharing on a nationwide scale--all under commonly agreed-to rules.
Exchange through TEFCA simplifies connectivity and creates efficiency
by establishing a standardized approach to exchange policies and
technical frameworks.
Under the 2019 to 2023 cooperative agreement \15\ and the current
RCE contract,\16\ the RCE's role has been to support the implementation
of TEFCA, including the solicitation and review of applications from
HINs seeking QHIN status and administration of the Designation and
monitoring processes. For entities seeking Designation, the application
provides the RCE with the information needed to determine a prospective
QHIN's ability to meet its obligations and responsibilities for TEFCA
Exchange. All work or activities conducted by the Sequoia Project in
their capacity as the RCE under the RCE contract, including work or
activities related to Designation, is conducted on behalf of ONC.
---------------------------------------------------------------------------
\15\ Notice of Funding Opportunity (NOFO)--Trusted Exchange
Framework and Common Agreement--Recognized Coordination Entity (RCE)
Cooperative Agreement, https://www.healthit.gov/sites/default/files/facas/TEFCA%20NOFO_FINAL_508.pdf.
\16\ See USASPENDING.gov, https://www.usaspending.gov/award/CONT_AWD_75P00123C00019_7570_-NONE-_-NONE-.
---------------------------------------------------------------------------
In subpart C of part 172, we described the proposed QHIN Onboarding
and Designation processes. Onboarding, as we proposed to define it in
Sec. 172.102, is the process a prospective QHIN must undergo to become
a QHIN and become operational in the production environment.\17\
Designation, as we proposed to define it in Sec. 172.102, is the
written determination that an Applicant QHIN has satisfied all
regulatory requirements and is now a QHIN.\18\
---------------------------------------------------------------------------
\17\ 87 FR 2822.
\18\ 87 FR 2818.
---------------------------------------------------------------------------
In Sec. 172.300, we explained that subpart C of part 172 would
establish for QHINs the application, review, Onboarding, withdrawal,
and redetermination processes that ONC will follow for Designation. We
noted that establishing these processes will ensure that ONC (or an
RCE) takes a consistent approach to QHIN Onboarding and Designation.
We stated that the first step in becoming a QHIN under TEFCA is
submission of an application. In Sec. 172.301, we proposed to
establish the information Applicant QHINs must submit in order to be
Designated as a
[[Page 101794]]
QHIN. We proposed that an Applicant QHIN must submit: (1) a completed
QHIN application; and (2) a signed copy of the Common Agreement.
Regarding the first proposed requirement, in Sec. 172.301(a), we noted
that we may update the application over time and the most recent
version will be available on ONC's and the RCE's website. The
application will specify what supporting documentation an Applicant
QHIN must submit. We proposed the second requirement in Sec.
172.301(b) because the Applicant QHIN would sign the Common Agreement
upon application, but the RCE would only countersign and create a
binding agreement with the Applicant QHIN once the Applicant QHIN
completes Onboarding and is Designated.
We stated that the next step to becoming a QHIN is application
review. In Sec. 172.302, we proposed a process, with required
timelines and allowable extensions, for ONC (or an RCE) to review
applications. We proposed in Sec. 172.302(a) that, on receipt of an
application, ONC (or an RCE) will review the application to determine
if the Applicant QHIN has completed all parts of the application and
provided the necessary supporting documentation. Further, we proposed
that, if the QHIN Application is not complete, ONC (or an RCE) will
notify the applicant in writing of the missing information within
thirty (30) calendar days of receipt of the application. Last, we
proposed (89 FR 63649) that ONC (or an RCE) may extend this period by
providing written notice to the Applicant QHIN. We noted that ``written
notice'' throughout part 172 would include notice provided by email to
the points of contact the Applicant QHIN listed in their application.
In the HTI-2 Proposed Rule we stated that we believe the above
timeframe and allowable extensions would allow ONC (or an RCE) enough
time to perform a thorough review of each application and ensure that
ONC (or an RCE) is provided with the responses and supporting
documentation needed to assess the merits of an application. We also
noted that we believe the 30-day review timeframe--along with the
ability of ONC (or an RCE) to extend this period by providing written
notice to the Applicant QHIN--strikes the right balance between moving
an application forward as quickly as possible while still providing ONC
(or an RCE) with enough time to conduct a review of the application to
ensure it is complete and contains all the required material.
We proposed in Sec. 172.302(b) that once the QHIN application is
complete, ONC (or an RCE) will review the application to determine
whether the Applicant QHIN satisfies the requirements for Designation
set forth in Sec. 172.201, and, if the Applicant QHIN proposes to
provide IAS, the requirements set forth in Sec. 172.202. We proposed
this step to make clear that ONC (or an RCE) will review an application
not only for completeness but also to determine if the qualifications
are met. We also proposed ONC (or an RCE) would complete its review
within sixty (60) calendar days of providing the Applicant QHIN with
written notice that its application is complete. We further proposed
that ONC (or an RCE) may extend this period by providing written notice
to the Applicant QHIN. We noted in the HTI-2 Proposed Rule that we
believe that sixty (60) calendar days will generally be an adequate
amount of time to conduct a thorough, comprehensive review of the
substance of the application. However, we also noted that we are
cognizant that there may be complex applications that require
additional time for review and, therefore, proposed that ONC (or an
RCE) may extend this period by providing written notice to the
Applicant QHIN.
We proposed in Sec. 172.302(c) that ONC (or an RCE) may contact
the Applicant while the application is being reviewed to request
additional information. ONC (or an RCE) will provide the timeframe for
responding to its request and the manner to submit additional
information, which may be extended on written notice to the Applicant
QHIN. We noted we believe this provision would be beneficial because
the Applicant QHIN will need to provide detailed responses that may be
complex and will vary among Applicant QHINs. We also stated we
anticipate there will often need to be a discussion between ONC (or an
RCE) and the Applicant QHIN to reach a resolution and shared
understanding. This provision would provide for this vital
communication between ONC (or an RCE) and the Applicant QHINs. We
proposed that an Applicant QHIN must respond to ONC (or an RCE) within
the timeframe ONC (or an RCE) identifies because ONC (or an RCE) will
be in the best position to understand the complexity of the question
and estimate a reasonable amount of time for the Applicant QHIN to
respond. That said, we noted that we understand that each application,
as well as the questions associated with each application, will vary
significantly on a case-by-case basis and, therefore, proposed that ONC
(or an RCE) may extend the timeframe by providing written notice to the
Applicant QHIN. We stated that we believe this approach creates
appropriate flexibility regarding timing of Applicant QHIN responses,
while still leaving the discretion to decide the need for and length of
such extensions.
We proposed in Sec. 172.302(d) that failure to respond to a
request within the proposed timeframe, or in the manner specified, is a
basis for a QHIN Application to be deemed withdrawn, as set forth in
Sec. 172.305(c). In such situations, we proposed that ONC (or an RCE)
would provide the Applicant QHIN with written notice that the
application has been deemed withdrawn. We stated that we believe this
requirement is important to support an efficient application process
and to ensure that Applicant QHINs respond to requests in a timely
manner. We reiterated that under proposed Sec. 172.302(c), as
discussed above, ONC (or an RCE) can extend the timeframe for
responding to a request for information. We noted that an Applicant
QHIN should request an extension if it does not believe it can meet the
proposed response timeframe.
We proposed in Sec. 172.302(e) that if, following submission of
the application, any information submitted by the Applicant QHIN
becomes untrue or materially changes, the Applicant QHIN must notify
ONC (or an RCE), in the manner specified by ONC (or an RCE), of such
changes in writing within five (5) business days of the submitted
material becoming untrue or materially changing. This proposed
requirement takes into consideration the possibility that, over the
course of ONC's (or an RCE's) review of an application, an Applicant
QHIN's circumstances or information provided with the Applicant QHIN's
application may change. This provision would ensure that if such
changes occur, the Applicant QHIN would promptly notify ONC (or an RCE)
of such changes. We stated that we believe, based on ONC's experience
with health IT implementation and coordination efforts, that five (5)
business days is enough time for the Applicant QHIN to notify ONC (or
an RCE) of the change(s).
In Sec. 172.303, we proposed requirements related to QHIN approval
and Onboarding. We proposed in Sec. 172.303(a) that an Applicant QHIN
would have the burden of demonstrating its compliance with all
qualifications for Designation in Sec. 172.201, and, if the Applicant
QHIN proposes to provide IAS, the qualifications in Sec. 172.202. We
proposed in Sec. 172.303(b) that if ONC (or an RCE) determines an
Applicant QHIN meets the requirements for Designation
[[Page 101795]]
set forth in Sec. 172.201, and, if the Applicant QHIN proposes to
provide IAS, the qualifications set forth in Sec. 172.202, then ONC
(or an RCE) will notify the Applicant QHIN in writing that it has
approved its application, and the Applicant QHIN can proceed with
Onboarding. These proposed requirements are important for ensuring that
the Applicant QHIN is notified of its status and support the
transparency and efficiency of the Onboarding process.
We proposed in Sec. 172.303(c) that an approved Applicant QHIN
would be required to submit a signed version of the Common Agreement
within a timeframe set by ONC (or an RCE). This proposed provision is
important in addition to Sec. 172.301(b) (which would require an
Applicant QHIN to submit a signed version of the Common Agreement when
applying) to ensure that, if the Common Agreement changes between the
time the QHIN applies and when it is approved, the QHIN will have
signed the most recent version. We did not propose a specific timeframe
for submission, and instead proposed to allow ONC (or an RCE) to set
the timeframe for each Applicant QHIN, since we believe each timeframe
should be tailored to the needs of the Applicant QHIN and the
complexity of each application.
We proposed in Sec. 172.303(d) that an approved Applicant QHIN
must complete the Onboarding process set forth by ONC (or an RCE),
including any tests required by ONC (or an RCE) to ensure the Applicant
QHIN's network can connect to those of other QHINs, within twelve (12)
months of approval of the QHIN application, unless that time is
extended in ONC's (or an RCE's) sole discretion by up to twelve (12)
months. Based on our experience with health IT implementation and
discussions with the current RCE, we stated that we believe the
proposed twelve (12) month timeframe is sufficient time for approved
Applicant QHINs to complete the Onboarding process including any tests
with QHINs and other Applicant QHINs. We expressed that we believe this
timeframe strikes an appropriate balance between the need to onboard
QHINs promptly and the need to ensure that all QHINs can connect
immediately and seamlessly once Designated. We noted that during the
Onboarding process, the Applicant QHIN would have regular check-ins
with ONC (or an RCE) to monitor the progress on any outstanding
requirements, to coordinate technical testing, and to address any
issues that could put the Applicant QHIN in jeopardy of failing to meet
the proposed Onboarding timeframe detailed above.
In Sec. 172.304, we proposed the specific procedural requirements
for the Designation of QHINs. In Sec. 172.304(a), we proposed the
process that would follow an Applicant QHIN's satisfaction of the
Onboarding process requirements. We proposed that once the Onboarding
process requirements are satisfied, the Common Agreement would be
countersigned and the Applicant QHIN would receive a written
determination indicating that it had been Designated as a QHIN, along
with a copy of the countersigned Common Agreement.
In Sec. 172.304(b), we proposed that within thirty (30) calendar
days of receiving its written determination of Designation, each QHIN
would be required to demonstrate in a manner specified by ONC (or an
RCE) that it has completed a successful transaction with all other in-
production QHINs according to standards and procedures for TEFCA
Exchange. This proposed provision is important because it would ensure
that a Designated QHIN is able to exchange information with other
QHINs, which is a core function of QHINs. We stated we believe that the
thirty (30)-day timeframe will afford a Designated QHIN ample time to
move from testing to production. We also stated we believe that the
standards and procedures for such exchanges should remain flexible such
that ONC (or an RCE) may update the requirements from time to time as
appropriate. QHINs which are unable to complete a successful
transaction within the finalized time period would have their
Designation revoked.
We proposed in Sec. 172.304(c) that if a QHIN is unable to
complete the requirement in Sec. 172.304(b), described above, within
the thirty (30)-day period provided, the QHIN would be required to
provide to ONC (or an RCE) a written explanation as to why the QHIN is
unable to complete the requirement within the allotted time and include
a detailed plan and timeline for completion of the requirement. We
proposed that ONC (or an RCE) will then review and approve or reject
the QHIN's plan, basing its decision on the reasonableness of the
explanation based on the specific facts and circumstances, within five
(5) business days of receipt. We proposed that if the QHIN fails to
provide ONC (or an RCE) its plan or ONC (or an RCE) rejects the QHIN's
plan, ONC (or an RCE) will rescind its approval of the application,
rescind the QHIN Designation, and deny the application. We stated that
we believe these proposals would provide QHINs with the appropriate
flexibility to request an extension if the circumstances do not allow
the QHIN to meet the timeline. We also expressed that we believe the
proposed five (5)-business day timeframe would provide ONC (or an RCE)
with enough time to review the request and reach a decision regarding
the request based on the information provided. We proposed that within
thirty (30) calendar days of the end of the term of the plan, each QHIN
must demonstrate in a manner specified by ONC (or an RCE) that it has
completed a successful transaction with all other in-production QHINs
according to standards and procedures for TEFCA Exchange. We noted that
we believe that the thirty (30)-day timeframe will afford a Designated
QHIN ample time to move from testing to production.
In Sec. 172.304(d), we proposed that a QHIN Designation will
become final sixty (60) days after a Designated QHIN has submitted its
documentation, in a manner specified by ONC (or an RCE), that it has
completed a successful transaction with all other in-production QHINs.
This proposal will allow ONC (or an RCE) to exercise its ability to
review a Designation.
In Sec. 172.305, we proposed requirements related to withdrawal of
an application. In Sec. 172.305(a), we proposed that an Applicant QHIN
may withdraw its application by providing ONC (or an RCE) with written
notice in a manner specified by ONC (or an RCE). In Sec. 172.305(b),
we proposed that an Applicant QHIN may withdraw its application at any
point prior to Designation. In Sec. 172.305(c), we proposed that on
written notice to the Applicant QHIN, an application may be deemed as
withdrawn as a result of the Applicant QHIN's failure to respond to
requests for information from ONC (or an RCE). We stated that we
believe the approach in proposed Sec. 172.305 would create an
efficient process for ONC (or an RCE) to deem applications withdrawn if
an Applicant QHIN fails to respond to requests for information, and
also supports a flexible process by allowing an Applicant QHIN, for
whatever reason, to decide to withdraw its application without penalty.
Given the requirements placed on Applicant QHINs seeking to be
Designated, we stated we think it is reasonable to believe that some
Applicant QHINs will need to withdraw their applications to address any
number of issues that could arise during the application process.
In Sec. 172.306, we proposed that if an Applicant QHIN's
application is denied, the Applicant QHIN will be provided with written
notice that includes the basis for the denial. We did not propose a
specific template that would be used to explain the basis of a denial,
as such
[[Page 101796]]
explanation would likely vary based on the specific facts and
circumstances.
In Sec. 172.307, we proposed requirements for re-application. In
Sec. 172.307(a), we proposed that Applicant QHINs may resubmit their
applications by complying with the provisions of Sec. 172.301 in the
event that an application was denied or withdrawn. We noted that re-
application pursuant to Sec. 172.307(a) would also be conditioned on
meeting the requirements of proposed paragraphs (b) through (d) of
Sec. 172.307, as applicable. We proposed in Sec. 172.307(b) that an
Applicant QHIN may reapply at any time after it has voluntarily
withdrawn its application as specified in Sec. 172.305(a). We wanted
to create flexibility for Applicant QHINs to reassess their
applications and, if desired, resubmit the application. We also stated
we believe that providing an Applicant QHIN that withdraws its
application with discretion to choose when to re-apply would result in
better applications and create administrative efficiency. This is
because Applicant QHINs would be motivated to self-identify issues and
correct them in a subsequent application. Also, Applicant QHINs that
withdraw applications early would allow ONC (or an RCE) to avoid
expending resources to review and identify such issues.
In Sec. 172.307(c), we proposed that if ONC (or an RCE) deems an
application to be withdrawn as a result of the Applicant QHIN's failure
to respond to requests for information from ONC (or an RCE), then the
Applicant QHIN may reapply by submitting a new application no sooner
than six (6) months after the date on which its previous application
was submitted. We proposed that the Applicant QHIN must respond to the
prior request for information and must include an explanation as to why
no response was previously provided within the required timeframe. We
proposed in Sec. 172.307(d) that if ONC (or an RCE) denies an
application, the Applicant QHIN may reapply by submitting a new
application consistent with the requirements in Sec. 172.301, no
sooner than six (6) months after the date shown on the written notice
of denial. The application must specifically address the deficiencies
that constituted the basis for denying the Applicant QHIN's previous
application.
We noted in the HTI-2 Proposed Rule that we believe the proposed
six (6)-month minimum time period before re-application, in Sec.
172.307(c) and (d), would support efficiency in the review process, as
ONC (or an RCE) could shift its attention to other Applicant QHINs or
issues while the Applicant QHIN whose application was withdrawn as a
result of the Applicant QHIN's failure to respond to requests for
information or was denied reconsiders its application and addresses the
previously identified deficiency or deficiencies. Because the Applicant
QHIN that withdraws its application has not had its application denied
or deemed withdrawn for failure to respond to ONC (or an RCE) requests
for information, the Applicant QHIN may be prepared to reapply much
sooner than is the case for Applicant QHINs that have had their
application denied or deemed withdrawn. We welcomed comments on the
proposed processes and requirements in this subpart. Specifically, we
requested comment on whether the six-month timeframe for re-application
after an application has been deemed to be withdrawn as a result of the
Applicant QHIN's failure to respond to requests for information or has
been denied is appropriate, as well as other timeframes we proposed.
In addition to changes to the proposed regulatory text explained
below, and as explained elsewhere in this final rule, we have finalized
references to ``ONC'' in subpart B of the proposed rule as ``ASTP/
ONC.'' In some instances (for example, in Sec. 172.303(d)), we also
modified proposed regulatory text to ensure that the proper possessive
is used and finalized text reading ``ASTP/ONC's'' instead of ``ONC's.''
For further discussion of the use of ``ASTP/ONC,'' please see the
Executive Summary of this final rule.
Comments. One commenter stated that it was a seamless process to
connect to the TEFCA network through the QHIN, but recommended there
not be a means where users are opted into exchange via a QHIN by
default.
Response. While we appreciate the feedback, this comment is beyond
the scope of the proposed regulations because we did not make any
proposals related to a QHIN's policies and procedures related to
opting-in (or not opting-in). Since the comment is out of scope it
would not be appropriate to respond to such policy concerns here.
However, we welcome all feedback from interested parties, which can be
submitted via the ASTP/ONC website at https://inquiry.healthit.gov/support/plugins/servlet/desk/portal/2/create/61, for consideration and
potential inclusion within the TEFCA framework.
Comments. Overall, commenters were supportive of our proposal to
codify requirements related to QHIN Designation, Onboarding and dispute
resolution at this time. However, a couple of commenters expressed
concern that the codification could slow down the onboarding process
and eliminate the adaptability for future QHINs. One commenter stated
that the proposed regulation could hinder the RCE's and ASTP/ONC's
ability to make quick, necessary adjustments based on real-world
implementation feedback from future QHIN applicants. This commenter
said that codifying the requirements could limit the number of QHINs in
the network by potentially discouraging or disqualifying future QHINs
due to a less forgiving application process. The commenter opined that
this might hinder the emergence of innovative solutions and potentially
lead to less favorable terms for Participants and Subparticipants.
Response. We appreciate the feedback and the commenters' concerns.
By codifying the QHIN Designation, Onboarding, and dispute resolution
requirements, we establish a baseline for expectations for QHINs. We
believe this is supported by Congress' instruction that the Common
Agreement may include ``a common method for authenticating trusted
health information network participants'' (42 U.S.C. 300jj-
11(c)(9)(B)(i)(I)). For commenters concerned about potential future
requirements, while we appreciate the feedback, this comment is beyond
the scope of the proposed regulations. However, we welcome all feedback
from interested parties, which can be submitted via the ASTP/ONC
website at https://inquiry.healthit.gov/support/plugins/servlet/desk/portal/2/create/61, for consideration and potential inclusion within
the TEFCA framework.
Comments. One commenter requested that the Onboarding process be
clarified to give more information regarding the redetermination
process for QHIN application.
Response. We appreciate the comment but decline to make any changes
to the Onboarding process. We believe the current Onboarding process,
as well as the redetermination process, are sufficiently detailed so
that QHINs will know what to expect while ensuring flexibility remains
in place to allow for reconsideration based on a variety of
circumstances.
Comments. Commenters requested that ASTP/ONC make TEFCA's
onboarding process become more stringent to keep the system free of bad
actors. In addition to a stricter onboarding process, the commenters
also recommended active monitoring and swift enforcement, and the
creation of a mandatory notification system to alert legitimate
practices when their NPIs and credentials are used in data exchanges,
ensuring they are aware of
[[Page 101797]]
all activities tied to their identities. Another commenter emphasized
that this has become a serious issue under TEFCA, particularly as the
HITECH Act's requirement to share patient information with a third
party at the patient's direction at minimal cost encourages some
entities to misrepresent that they are acting on behalf of the patient.
Response. We appreciate the comments and concern. We believe that
Onboarding and Designation provisions we are finalizing, including the
substantive requirements at Sec. Sec. 172.201 and 172.202, establish a
rigorous testing and onboarding process that will prevent bad actors
from misusing the TEFCA framework. Specifically, since we proposed
substantive requirements for QHIN approval and Onboarding, and QHIN
designation, in Sec. Sec. 172.303 and 172.304 in the HTI-2 Proposed
Rule, we have developed a robust vetting process for ensuring that
Participants and Subparticipants that want to query for treatment
exchange through TEFCA using the code that requires a response are in
fact providers that require the information for treatment of a patient.
In addition, the Treatment XP Implementation SOP \19\ establishes a
definition for TEFCA required treatment that includes the requirement
that the TEFCA required treatment XP code can only be asserted by a
QHIN, Participant, or Subparticipant if the Query is in connection with
or intended to inform health care services that an entity identified in
the SOP is providing or intends to provide to a patient through
synchronous or asynchronous interaction (either in-person or virtual)
with a Licensed Individual Provider. This definition is narrower than
the HIPAA Rules' definition of treatment and we believe necessary to
build trust within the TEFCA community. We will consider expanding the
scope of disclosures that are required under TEFCA's treatment Exchange
Purpose over time.
---------------------------------------------------------------------------
\19\ XP Implementation: Treatment, https://rce.sequoiaproject.org/wp-content/uploads/2024/07/SOP-Treatment-XP-Implementation_508.pdf.
---------------------------------------------------------------------------
We have decided not to implement a mandatory notification system as
suggested because we believe the approach we are taking to address the
possibility of misuse of the TEFCA network, as discussed above, is more
appropriate, and that a mandatory notification system could be overly
burdensome, particularly given the extremely large number of
transactions we anticipate occurring through TEFCA once fully
implemented.
Comments. One commenter questioned why Sec. 172.304 references
provisional designation when the RCE is currently revising the
Onboarding and Designation SOP to remove references to provisional
status.
Response. We agree that the references to ``provisional''
designation are confusing and unnecessary. We have revised the
regulatory language in Sec. 172.304 to remove reference to provisional
Designation and reiterate that a QHIN is Designated when the Common
Agreement is countersigned. As we proposed and have finalized, the
Designation is rescindable if the requirements for exchange are not met
within the 60-day limit described in Sec. 172.304(d), otherwise, the
Designation is final.
Comments. One commenter offered support of the six-month timeframe
for re-application after an application has been withdrawn or denied.
The commenter stated that it is important for ASTP/ONC to take the time
it needs and assure security and appropriateness.
Response. We appreciate this comment in support of a six-month
timeframe and have finalized the provision in Sec. 172.307(c) as
proposed.
Comment. One commenter emphasized the need for strict enforcement
of deadlines and application criteria. The commenter also recommended
that if the requirements were not met, the application should not only
be withdrawn but also prompt an audit of the applicant's activities and
a review of any data exchanges that took place during the application
process. The commenter also suggested expanding the criteria for
withdrawing an application to include not just failures to respond but
also the discovery of fraudulent activities or the use of illegitimate
credentials at any point during the application process.
Response. We appreciate the feedback. We decline to adopt stricter
deadlines and application criteria. We believe the current structure
accounts for these concerns, for instance, by requiring a QHIN to
specifically address any unresolved issues upon reapplication.
Regarding the suggestions to require an audit of the applicant's
activities and a review of any data exchange that took place during the
application process and expanding the criteria for withdrawing an
application, we have decided not to implement the changes in this
rulemaking because we believe such potential changes should be reviewed
and considered by the public. We may consider the changes in future
rulemaking.
We have finalized all of subpart C as proposed, except that we
removed language referring to provisional Designation in Sec. 172.304
for the reasons explained above. In addition, we have added language
requiring an RCE to seek and receive ASTP/ONC's prior authorization
before making interim or final designation decisions (Sec.
172.303(b)), setting onboarding requirements and determining a QHIN has
complied with those requirements (Sec. 172.304(b) and (c)), and
deeming a QHIN application withdrawn for failure to respond to
information requests during the Designation process (Sec. 172.305(c)).
Under Sec. 172.103(b), ASTP/ONC cannot subdelegate to the RCE those
requirements for prior agency authorization. Combined with the review
provisions that apply to all RCE actions in subpart F of part 172, this
language helps to ensure that an RCE remains subordinate to ASTP/ONC
and provides only fact-gathering, ministerial, and administrative
support to ASTP/ONC.
D. Subpart D--Suspension
Within this subpart, in the HTI-2 Proposed Rule, we proposed
provisions associated with suspension, notice requirements for
suspension, and the effect of suspension. In Sec. 172.401, we proposed
provisions related to ONC (or the RCE) suspension of a QHIN or directed
suspension of a Participant or Subparticipant. In Sec. 172.401(a), we
proposed that ONC (or an RCE) may suspend a QHIN's authority to engage
in TEFCA Exchange if the ONC (or an RCE) determines that a QHIN is
responsible for a Threat Condition. Within the TEFCA infrastructure,
QHINs are expected to meet a high bar for security, including, but not
limited to, third-party certification to industry-recognized
cybersecurity standards; compliance with the HIPAA Security Rule or the
standards required by QHIN participation that mirror the HIPAA Security
Rule requirements; annual security assessments; designation of a Chief
Information Security Officer; and having cyber risk coverage.
This proposed provision would support the overall security of TEFCA
and align with the security requirements for QHINs by enabling ONC (or
an RCE) to suspend a QHIN's authority to engage in TEFCA Exchange if
the QHIN is responsible for a Threat Condition. According to the
definition proposed in Sec. 172.102, a Threat Condition may occur in
three circumstances: (i) a breach of a material provision of a
Framework Agreement that has not been cured within fifteen (15)
calendar days of receiving notice of the material breach (or such other
period of time to which contracting parties have agreed), which
[[Page 101798]]
notice shall include such specific information about the breach that is
available at the time of the notice; or (ii) a TEFCA Security Incident,
as that term is defined in Sec. 172.102; or (iii) an event that ONC
(or an RCE), a QHIN, its Participant, or their Subparticipant has
reason to believe will disrupt normal TEFCA Exchange, either due to
actual compromise of, or the need to mitigate demonstrated
vulnerabilities in, systems or data of the QHIN, Participant, or
Subparticipant, as applicable; or through replication in the systems,
networks, applications, or data of another QHIN, Participant, or
Subparticipant; or (iv) any event that could pose a risk to the
interests of national security as directed by an agency of the United
States government. We proposed this policy because we believe that in
each of these situations, in order to protect the security of TEFCA
Exchange, ONC (or an RCE) must be able to take immediate action to
suspend a QHIN's authority to engage in TEFCA exchange and limit the
potential effects of the Threat Condition.
In Sec. 172.401(b), we proposed if ONC (or an RCE) determines that
one of a QHIN's Participants or Subparticipants has done something or
failed to do something that results in a Threat Condition, ONC (or an
RCE) may direct the QHIN to suspend that Participant's or
Subparticipant's authority to engage in TEFCA Exchange. This provision
proposed to extend the ONC (or an RCE's) authority to suspend a QHIN's
authority to engage in TEFCA Exchange to also include the authority to
order a QHIN to suspend a Participant's or Subparticipant's authority
to engage in TEFCA Exchange. We stated that we believe this provision
would help protect the security of TEFCA Exchange because any Threat
Condition--whether due to the action or inaction by a QHIN,
Participant, or Subparticipant--could jeopardize the security of TEFCA
and must be addressed once identified. We also noted we believe that in
order to protect the security of TEFCA Exchange, ONC (or an RCE) must
be able to take immediate action to order a QHIN to suspend a
Participant's or Subparticipant's authority to engage in TEFCA Exchange
and limit the potential effects of a Threat Condition resulting from
something a Participant or Subparticipant has done or failed to do.
In Sec. 172.401(c), we proposed that ONC (or an RCE) will make a
reasonable effort to notify a QHIN in writing, in advance, of ONC's (or
an RCE's) intent to suspend the QHIN or to direct the QHIN to suspend
one of the QHIN's Participants or Subparticipants, and give the QHIN an
opportunity to respond. Such notice would identify the Threat Condition
giving rise to such suspension. We acknowledged that a suspension would
significantly disrupt the activities of a QHIN, Participant, or
Subparticipant and therefore Sec. 172.401(c) proposed to require ONC
(or an RCE) to make a reasonable effort to notify affected parties in
advance of the ONC's (or an RCE's) intent to suspend. We proposed to
only require ONC (or an RCE) to make a reasonable effort to notify the
entity because the circumstances surrounding a Threat Condition may
limit ONC's (or an RCE's) ability to provide advance written notice to
the QHIN or the QHIN's Participants or Subparticipants, despite ONC's
(or an RCE's) best efforts. In Sec. 172.401(d), we proposed ONC (or an
RCE) shall lift a suspension once the Threat Condition is resolved. We
stated we believe that it would no longer be necessary to continue a
suspension once a Threat Condition is resolved.
We stated in the HTI-2 Proposed Rule that we believe the provisions
outlined in Sec. 172.401 would help maintain the integrity of TEFCA
and offer a transparent approach to suspension that would communicate
the reason for suspension, require timely notification of suspension,
and afford QHINs an opportunity to resolve the issue(s)--including in
concert with their Participants or Subparticipants--that led to the
suspension and to resume TEFCA Exchange.
In Sec. 172.402, we proposed provisions related to selective
suspension of TEFCA Exchange between QHINs. In Sec. 172.402(a), we
proposed that a QHIN may, in good faith and to the extent permitted by
Applicable Law, suspend TEFCA Exchange with another QHIN because of
reasonable concerns related to the privacy and security of information
that is exchanged. In Sec. 172.402(b), we proposed that if a QHIN
decides to suspend TEFCA exchange with another QHIN, it is required to
promptly notify, in writing, ONC (or an RCE) and the QHIN with which it
is suspending exchange of its determination and the reason(s) for
making the decision.
These proposed provisions are intended to further strengthen the
privacy and security protections within TEFCA by extending suspension
rights to QHINs to suspend exchange with another QHIN due to reasonable
concerns related to the privacy and security of information that is
exchanged. We emphasize that we proposed the concerns must be
``reasonable'' and must be related to the ``privacy and security of
information that is exchanged'' in order to ensure that suspension of
TEFCA Exchange between QHINs is not based on other factors, such as
competitive advantage. We solicited comments on examples of reasonable
concerns related to the privacy and security of information that is
exchanged. These proposed requirements would support trust between
QHINs, which is a foundational element of TEFCA and would help TEFCA
establish a universal floor for interoperability across the country. We
stated that we believe prompt notification of the selective suspension
to ONC (or an RCE) and the suspended QHIN would enable all parties
involved to be aware of the situation in a timely fashion and take
action to maintain the privacy and security of TEFCA Exchange
activities.
In Sec. 172.402(c), we proposed that if a QHIN suspends TEFCA
Exchange with another QHIN under Sec. 172.402(a), it must, within
thirty (30) calendar days, initiate the TEFCA dispute resolution
process in order to resolve the issues that led to the decision to
suspend, or the QHIN may end its suspension and resume TEFCA Exchange
with the other QHIN within thirty (30) calendar days of suspending
TEFCA Exchange with the QHIN. We proposed this provision to provide the
parties with an opportunity to resolve concerns related to privacy and
security and potentially continue exchange once the issues have been
resolved. We stated we believe the thirty (30)-day timeframe would
provide sufficient time to resolve issues that led to the suspension,
end the suspension, and resume TEFCA Exchange activities in a timely
manner. Ultimately, TEFCA will be most impactful and successful if
QHINs trust each other and are able to confidently exchange information
with each other, so it is in the best interests of the QHINs involved,
as well as TEFCA overall, to address and resolve a selective suspension
quickly, and by the least disruptive means possible.
In Sec. 172.402(d), we proposed that, provided that a QHIN
suspends TEFCA exchange with another QHIN in accordance with other
provisions in Sec. 172.402 and in accordance with Applicable Law, such
selective suspension would not be deemed a violation of the Common
Agreement. This provision would promote the integrity of TEFCA by
ensuring that a QHIN with reasonable and legitimate concerns related to
the privacy and security of information that is exchanged would not be
deterred from suspending exchange activities with another QHIN for fear
of being in violation of the Common Agreement.
As described elsewhere in this final rule, we have finalized
references to
[[Page 101799]]
``ONC'' in subpart D of the proposed rule as ``ASTP/ONC.'' For further
discussion of the use of ``ASTP/ONC,'' please see the Executive Summary
of this final rule.
Comments. One commenter was supportive of the criteria and process
we proposed for the suspension. However, the commenter also highlighted
the need to ensure that when a QHIN is suspended, Participants and
Subparticipants utilizing that QHIN are protected from actions taken by
HHS, ASTP/ONC or the OIG including but not limited to information
blocking requirements.
Another commenter was concerned about the lack of clarity regarding
the suspension of a QHIN and requested that ASTP/ONC clarify the
obligations of hospitals and health systems in such cases to ensure
compliance with interoperability rules.
Response. We appreciate the concerns the commenter raised regarding
protecting Participants and Subparticipants from actions taken by HHS,
ASTP/ONC or the OIG including but not limited to actions related to
information blocking requirements. We note that, in the event of
suspension of a QHIN's ability to participate in exchange activities
under the Common Agreement, the Common Agreement requires the QHIN to
communicate with its Participants that all TEFCA Exchange on behalf of
the QHIN's Participants will also be suspended during any period of the
QHIN's suspension (see section 17.4.4 of Common Agreement Version 2.1).
The Common Agreement also requires the QHIN to require its Participants
to communicate with their Subparticipants that all TEFCA Exchange on
behalf of the QHIN's Subparticipants will be suspended during any
period of the QHIN's suspension (see section 17.4.4 of Common Agreement
Version 2.1). We believe these provisions provide appropriate
transparency to entities affected by a suspension.
With regard to the comments related to protection from actions
taken by HHS, ASTP/ONC or the OIG including but not limited to actions
related to information blocking requirements, we note that Participants
and Subparticipants remain subject to all applicable laws (e.g., HIPAA
Privacy, Security, and Breach Notification Rules, and information
blocking regulations). We encourage Participants and Subparticipants to
review the information blocking regulations, including the exceptions,
to determine their applicability to an actor's facts and circumstances.
We also refer readers to section 17.4.4 of the Common Agreement (which
discusses the effect of suspension).
We also encourage organizations that connect to a QHIN to discuss
transition plans in the event of a suspension with the QHIN and review
any appropriate material or requirements.
Comments. One commenter requested additional information from ASTP/
ONC on the consequence for repeated Threat Conditions coming from any
one QHIN after a Threat Condition has been cured.
Response. We thank the commenter for the suggestion. We did not
make any proposals related to consequences for repeated Threat
Conditions coming from any one QHIN after a Threat Condition has been
cured; nonetheless, we agree with the commenter that we should consider
how to address such situations and whether they warrant additional
scrutiny. Because we did not make any proposals related to such
consequences, we believe it would be appropriate to solicit public
comment before adopting consequences of this nature, so we have
finalized this rule without addressing that specific issue. We may
consider this suggestion in a future rulemaking.
In Sec. 172.401(d), we modified the final regulatory text to
better align with Sec. 172.401(b). Specifically, in Sec. 172.401(b),
we state that ASTP/ONC would provide direction to the QHIN to suspend
one of the QHIN's Participants or Subparticipants. In Sec. 172.401(d),
we proposed that ONC (or, with ONC's prior authorization, an RCE) shall
lift a suspension of either the QHIN or one of the QHIN's Participants
or Subparticipants once the Threat Condition is resolved. We have
changed the final regulatory text in Sec. 172.401(d) to state that
ASTP/ONC (or, with ASTP/ONC's prior authorization, an RCE) shall
provide direction to the QHIN to lift the suspension of one of the
QHIN's Participants or Subparticipants once the Threat Condition is
resolved. We believe this finalized text better aligns with the text in
Sec. 172.401(b), which states that ASTP/ONC (or, with ASTP/ONC's prior
authorization, an RCE) will provide direction to the QHIN regarding the
suspension of one of its Participants or Subparticipants.
Comments. A few commenters suggested updates to Sec. 172.401 to
clarify the requirements for selective suspension. One commenter
suggested that a QHIN should be permitted to selectively suspend
exchange with another QHIN's Participant(s) or Subparticipant(s). The
commenter noted that a more targeted suspension is reasonable and
practical to implement while any specific issues are addressed. Another
commenter requested that ASTP/ONC specify that a QHIN may implement a
selective suspension due to concerns about patient safety and data
integrity.
Response. We appreciate the commenters' support for selective
suspension for QHINs. Section 172.402(a), which we have finalized as
proposed, states that a QHIN may, in good faith and to the extent
permitted by Applicable Law, suspend TEFCA Exchange with another QHIN
because of reasonable concerns related to the privacy and security of
information that is exchanged. We decline to modify Sec. 172.402 to
permit a QHIN to selectively suspend exchange with another QHIN's
Participant(s) or Subparticipant(s). We appreciate the request for a
more targeted selective suspension in certain circumstances, but we
believe each QHIN should be responsible for ensuring that its
Participants and Subparticipants are meeting applicable requirements.
We believe the finalized language in Sec. 172.402(a) that states that
a QHIN may suspend exchange between another QHIN if there is reasonable
concern about the privacy and security of the data, as well as the
finalized language in Sec. 172.402(b) that states that the QHIN must
notify the other QHIN of the suspension in writing, creates appropriate
guardrails for selective suspension.
We have finalized the provisions in subpart D as proposed, except
as follows. We have added to Sec. 172.401(a) language requiring an RCE
to seek and receive ASTP/ONC's prior authorization before suspending a
QHIN. We have added to Sec. 172.401(b) language requiring an RCE to
seek and receive ASTP/ONC's prior authorization before directing the
QHIN to suspend a Participant's or Subparticipant's TEFCA Exchange. We
have added to Sec. 172.401(d) language requiring an RCE to seek and
receive ASTP/ONC's prior authorization before lifting a suspension of
either a QHIN or one of a QHIN's Participants or Subparticipants once
the Threat Condition is resolved. We have modified Sec. 172.103(b) to
clarify that ASTP/ONC cannot subdelegate to the RCE those requirements
for prior agency authorization. Combined with the review provisions
that apply to all RCE actions in subpart F of part 172, this language
helps to ensure that an RCE remains subordinate to ASTP/ONC and
provides only fact-gathering, ministerial, and administrative support
to ASTP/ONC. We have also revised the text of Sec. 172.401 for added
clarity.
We also would like to clarify one point regarding the proposed
security requirements for QHINs. Earlier in this section we stated that
within the TEFCA
[[Page 101800]]
infrastructure, QHINs are expected to meet a high bar for security,
including compliance with the HIPAA Security Rule or the standards
required by the HIPAA Security Rule. We make the distinction between
``compliance with the HIPAA Security Rule'' and compliance with the
standards required by QHIN participation that mirror the HIPAA Security
Rule requirements because some entities may not be a covered entity or
business associate (i.e., a Non-HIPAA Entity) that are regulated by the
HIPAA Security Rule. In order for TEFCA to have consistent security
standards, we proposed that even though Non-HIPAA Entities cannot be
covered by HIPAA, we can still apply comparable security standards to
such entities. To be clear, the HHS Office for Civil Rights (OCR) is
the only entity that may determine a HIPAA covered entity's compliance
with the HIPAA Security Rule. Any determination by a third party or by
the RCE that a QHIN meets the QHIN requirements does not constitute a
determination by HHS of the QHIN's compliance with the requirements of
the HIPAA Security Rule.
E. Subpart E--Termination
In this subpart, we proposed provisions related to a QHIN's right
to terminate its own Designation, ONC's (or an RCE's) obligation to
terminate a QHIN's Designation and related notice requirements, and
requirements related to the effect of termination. In Sec. 172.501, we
proposed that a QHIN may terminate its own QHIN Designation at any time
without cause by providing ninety (90) calendar days prior written
notice. This provision supports the voluntary nature of TEFCA by
allowing a QHIN that, for whatever reason, no longer wants to serve as
a QHIN, to terminate its own QHIN Designation with ninety (90) calendar
days prior written notice. We stated we believe a QHIN should be able
to terminate its Designation, regardless of the circumstances or reason
and that ninety (90) calendar days would provide enough time for ONC,
the RCE and the departing QHIN to analyze and address the impacts of
the QHIN's departure.
In Sec. 172.502, we proposed that a QHIN's Designation will be
terminated with immediate effect by ONC (or an RCE) giving written
notice of termination to the QHIN if the QHIN: (a) fails to comply with
any regulations of the part and fails to remedy such material breach
within thirty (30) calendar days after receiving written notice of such
failure; provided, however, that if a QHIN is diligently working to
remedy its breach at the end of this thirty (30) day period, then ONC
(or an RCE) must provide the QHIN with up to another thirty (30)
calendar days to remedy its material breach; or (b) a QHIN breaches a
material provision of the Common Agreement where such breach is not
capable of remedy. We requested comments on examples of material
provisions of the Common Agreement where a breach is not capable of
remedy.
We stated in the HTI-2 Proposed Rule that we believe these
proposals would promote transparency in TEFCA and strengthen the
underlying trust among and between entities connected to TEFCA. These
termination provisions would enable ONC (or an RCE) to take swift
action to remove a non-compliant QHIN and ensure that entities that
fail to meet their obligations as QHINs (by failing to comply with the
regulations of the part or by breaching a material provision of the
Common Agreement) are no longer able to act as QHINs under the TEFCA
framework. Without the ability for ONC (or an RCE) to terminate non-
compliant QHINs, this trust--which is foundational to TEFCA and
necessary for the ultimate success of TEFCA--could quickly erode and
undermine TEFCA's progress.
In Sec. 172.503, we proposed that QHINs and ONC (or an RCE) would
be able to terminate the QHIN's Designation at any time and for any
reason by mutual, written agreement. Allowing two parties to terminate
an agreement by mutual, written agreement ensures that two parties are
not forced to follow an agreement that neither wants to follow. In the
HTI-2 Proposed Rule, ONC stated we believe it is reasonable and
efficient to allow termination at any time where both ONC (or an RCE)
and the QHIN are satisfied that a QHIN's termination is in the best
interest of all.
During the comment period we noticed discrepancies between the use
of business days and calendar days when discussing termination in
preamble and regulation text. Accordingly, we updated the use of
business days (and adopted the full proposed definition of business
days in regulation text) and calendar days in the preamble discussion
in this subpart to match the use of business days and calendar days in
the regulation text we proposed in this subpart.
As described elsewhere in this final rule, we have finalized
references to ``ONC'' in subpart E of the proposed rule as ``ASTP/
ONC.'' For further discussion of the use of ``ASTP/ONC,'' please see
the Executive Summary of this final rule.
Comments. Several commenters noted strong support for the
termination process of QHINs when necessary, particularly in cases of
financial instability, violations of guidelines, or failure to meet
established qualifications and regulations. Commenters emphasized the
importance of having the ability to decertify non-compliant QHINs as
needed to uphold the integrity of the system.
Some commenters raised concerns regarding the implications of the
termination of a QHIN's Designation, particularly for Participants and
Subparticipants, as well as hospitals and health systems that rely on
these networks. Commenters highlighted the lack of a migration plan and
support system for these groups, which raises questions about their
options during a transition. Additionally, commenters expressed
concerns about compliance reporting and potential information blocking
claims affecting Participants and Subparticipants if a QHIN is
terminated.
Response. We thank these commenters for these comments. We
appreciate commenters' concerns related to termination of QHINs
generally, and more specifically related to the effects of a
termination on Participants and Subparticipants and the lack of a
migration plan, but we believe these comments are out of scope for this
final rule because we did not include any proposals in the HTI-2
Proposed Rule to address the effects of a termination.
We also believe the comments related to protection from compliance
reporting requirements and the information blocking regulations are out
of scope for this final rule because such comments relate to
information blocking enforcement. Nonetheless, it is important to
emphasize that when a QHIN is terminated, its Participants and
Subparticipants will be unable to exchange or respond to queries
through that QHIN--meaning TEFCA Exchange would not be possible through
that QHIN. We invite Participants and Subparticipants to review the
exceptions to the information blocking regulations to determine if the
facts of their specific scenarios would fit under an information
blocking exception. We also refer readers to section 17.3.5 of the
Common Agreement (section 10.3 of the Terms of Participation) which
discusses the effect of termination.
We encourage organizations that connect to a QHIN to discuss
transition plans with the QHIN as they are discussing connecting to
that QHIN and establishing the parameters of their relationship with
the QHIN. We also note that, based on the requirements for Designation
we have finalized, QHINs should be high-functioning entities that
[[Page 101801]]
can support nationwide exchange at scale, and such organizations will
have strong incentives to ensure their ongoing participation as QHINs.
Comments. One commenter sought clarification on the rationale
behind ASTP/ONC's decision to include all termination provisions of the
Common Agreement in the regulation except for section 17.3.5, ``Effect
of Termination of the Common Agreement.'' The commenter further stated
that its request for clarification underscores the need for
transparency and understanding of the regulatory framework affecting
QHINs and their stakeholders.
Response. We appreciate this comment. We did not propose to include
provisions related to the effect of termination of the Common Agreement
because we do not believe that provisions focused on the effect of a
termination are necessary in this rulemaking. The termination
provisions we included in this rulemaking explain the requirements and
processes for termination. If a QHIN is terminated and decides to
appeal the decision, the requirements and processes in this rulemaking
would be integral in deciding whether the appeal would be successful.
On the other hand, provisions related to the effect of termination
would have little bearing on the ultimate success of an appeal and thus
we do not think it is necessary to include such provisions in this
rulemaking. As the commenter noted, there is a provision in the Common
Agreement that addresses the effect of termination.
We have finalized all provisions in subpart E as proposed. In
addition, we have added to Sec. 172.502 language requiring an RCE to
seek and receive ASTP/ONC's prior authorization before terminating a
QHIN. Under Sec. 172.103(b), ASTP/ONC cannot subdelegate to the RCE
this requirement for prior agency authorization. Combined with the
review provisions that apply to all RCE actions in subpart F of part
172, this language helps to ensure that an RCE remains subordinate to
ASTP/ONC and provides only fact-gathering, ministerial, and
administrative support to ASTP/ONC.
F. Subpart F--Review of RCE[supreg] or ASTP/ONC Decisions
ASTP/ONC oversees the RCE's work and has the right to review the
RCE's conduct and its execution of nondiscrimination and conflict of
interest policies that demonstrate the RCE's commitment to treating
QHINs in a transparent, fair, and nondiscriminatory way.\20\ In subpart
F, we proposed to establish processes for review of RCE or ONC actions,
including QHIN appeal rights and the process for filing an appeal.
These appeal rights would ensure that a QHIN or Applicant QHIN that
disagrees with certain RCE or ONC decisions will have recourse to
appeal those decisions. Our proposed Sec. 172.600 reflects this
overall scope as an applicability section for this subpart.
---------------------------------------------------------------------------
\20\ See Common Agreement section 3.1, 89 FR 35107 (May 1,
2024), https://www.federalregister.gov/documents/2024/05/01/2024-09476/notice-of-publication-of-common-agreement-for-nationwide-health-information-interoperability-common.
---------------------------------------------------------------------------
In Sec. 172.601, we proposed provisions to establish ONC's
authority to review RCE determinations, policies, and actions, as well
as procedures for exercising such review. We proposed in Sec.
172.601(a) that ONC may, in its sole discretion, review all or any part
of any RCE determination, policy, or action. In Sec. 172.601(b) we
proposed ONC may, in its sole discretion and on notice to affected
QHINs or Applicant QHINs, stay any RCE determination, policy, or other
action. In Sec. 172.601(c), we proposed ONC may, in its sole
discretion and on written notice, request that a QHIN, Applicant QHIN,
or the RCE provide ONC additional information regarding any RCE
determination, policy, or other action. In Sec. 172.601(d), we
proposed that on completion of its review, ONC may affirm, modify, or
reverse the RCE determination, policy, or other action under review.
Additionally, we proposed to provide notice to affected QHINs or
Applicant QHINs that includes the basis for ONC's decision. In Sec.
172.601(e), we proposed ONC will provide written notice under this
section to affected QHINs or Applicant QHINs in the same manner as the
original RCE determination, policy, or other action under review. We
stated we believe these proposals provide transparency into the level
of oversight ONC has in reviewing RCE determinations, policies, or
actions and firmly establish ONC's authority to affirm, modify, or
reverse such determinations, policies, and actions. We also noted we
believe these provisions are important to assure QHINs and Applicant
QHINs that we have the ability to effectively exercise oversight of the
RCE, as well as provide all parties with an interest in the
administration of TEFCA with confidence that we can and will take
necessary action to ensure that QHINs and Applicant QHINs comply with
the regulations we proposed in part 172.
In Sec. 172.602, we proposed to establish bases for Applicant
QHINs and QHINs to appeal decisions to ONC. We proposed that an
Applicant QHIN or QHIN may appeal certain decisions to ONC or a hearing
officer, as appropriate. In Sec. 172.602(a)(1), we proposed that an
Applicant QHIN would be able to appeal the denial of its application.
In Sec. 172.602(a)(2), we proposed that a QHIN would be able to appeal
a decision to (1) suspend a QHIN or instruct a QHIN to suspend its
Participant or Subparticipant; or (2) terminate a QHIN's Common
Agreement. We requested comment on the proposed bases for appeal.
In Sec. 172.603, we proposed the method and timing for filing an
appeal. In Sec. 172.603(a), we proposed that to initiate an appeal, an
authorized representative of the Applicant QHIN or QHIN must submit
electronically, in writing to ONC, a notice of appeal that includes the
date of the notice of appeal, the date of the decision being appealed,
the Applicant QHIN or QHIN who is appealing, and the decision being
appealed within fifteen (15) calendar days of the Applicant QHIN's or
QHIN's receipt of the notice of denial of an application, suspension or
instruction to suspend its Participant or Subparticipant, or)
termination. With regard to an appeal of a termination, the fifteen
(15) calendar day timeframe may be extended by ONC up to another
fifteen (15) calendar days if the QHIN has been granted an extension
for completing its remedy under Sec. 172.502(a). The notice of appeal
would serve to notify ONC that the Applicant QHIN or QHIN is planning
to file an appeal and would require inclusion of only the minimum
amount of information necessary to provide such notice (i.e., the date
of the notice of appeal, the date of the decision being appealed, the
Applicant QHIN or QHIN who is appealing, and what is being appealed).
As such, we stated we believe fifteen (15) business days would be an
adequate amount time for deciding whether to initiate an appeal and
submitting such information.
In Sec. 172.603(b), we proposed that an authorized representative
of an Applicant QHIN or QHIN must submit electronically, to ONC, within
thirty (30) calendar days of filing the intent to appeal: (1) A
statement of the basis for appeal, including a description of the facts
supporting the appeal with citations to documentation submitted by the
QHIN or Applicant QHIN; and (2) Any documentation the QHIN would like
considered during the appeal.
We stated we expect that it would take an Applicant QHIN or QHIN
some
[[Page 101802]]
time to collect all of the relevant information and documentation to
support its appeal, and accordingly proposed a timeframe for requesting
an appeal of thirty (30) calendar days from the filing of the intent to
appeal with ONC. We welcomed comments on whether this timeframe, as
well as the timeframe for submitting an intent to appeal, are adequate
and appropriate.
In Sec. 172.603(c), we proposed that an Applicant QHIN or QHIN
filing the appeal may not submit on appeal any evidence it did not
submit prior to the appeal, except by permission of the hearing
officer. We stated we believe this provision balances a QHIN or
Applicant QHIN's right to introduce evidence with the need for orderly
proceedings. We are aware that under our proposed regulations, QHINs
facing suspension or termination do not have an express right to
introduce evidence. We solicited comments on whether and when a QHIN
facing suspension or termination should have a right to introduce that
evidence--for example as part of demonstrating that a material breach
has been remedied or is capable of remedy under Sec. 172.502, at the
hearing officer stage, or some combination of the two based on
circumstances of the suspension or termination.
In Sec. 172.604, we proposed that an appeal would not stay a
suspension or termination, unless otherwise ordered by ONC or the
hearing officer assigned under Sec. 172.605(b). This means that in the
event of an appeal of a suspension or termination, the appeal would not
stop the suspension or termination from being effective. We stated we
believe this proposed approach is important because a QHIN would only
be suspended or terminated for infractions that could, for example,
jeopardize the privacy and security of TEFCA Exchange.
Before a QHIN is terminated under Sec. 172.502(a), we noted the
QHIN would have already been given an opportunity to remedy the breach
unless the breach is not capable of remedy. The move by ONC or an RCE
to terminate a QHIN would mean either the QHIN tried and failed to
remedy the issue, or a remedy is not possible. In either case, we
stated we believe it would be appropriate not to stay the termination.
In the case of a suspension, the QHIN would have been found to be
responsible for a Threat Condition, and we stated we believe the risk
to the privacy and security of the TEFCA ecosystem would far outweigh
any perceived benefit of staying the suspension.
In Sec. 172.605, we proposed provisions related to the assignment
of a hearing officer. In Sec. 172.605(a), we proposed that, in the
event of an appeal, the National Coordinator may exercise authority
under Sec. 172.601 to review the RCE determination being appealed. We
further proposed an appealing QHIN or Applicant QHIN that is not
satisfied with ONC's subsequent determination may appeal that
determination to a hearing officer by filing a new notice of appeal and
other appeal documents that comply with Sec. 172.603. In Sec.
172.605(b), we proposed if ONC declines review under paragraph (a), or
if ONC made the determination under review, ONC would arrange for
assignment of the case to a hearing officer to adjudicate the appeal.
We specified in proposed Sec. 172.605(c) that the hearing officer
must be an officer appointed by the Secretary of Health and Human
Services (for more information about officers and appointments, see
section III.D.5.c of the HTI-2 Proposed Rule, 89 FR 63612 through
63615). In Sec. 172.605(d), we proposed, the hearing officer may not
be responsible to, or subject to the supervision or direction of,
personnel engaged in the performance of investigative or prosecutorial
functions for ONC, nor may any officer, employee, or agent of ONC
engaged in investigative or prosecutorial functions in connection with
any adjudication, in that adjudication or one that is factually
related, participate or advise in the decision of the hearing officer,
except as a counsel to ONC or as a witness.
In Sec. 172.606, we proposed requirements related to adjudication.
In Sec. 172.606(a), we proposed that the hearing officer would decide
issues of law and fact de novo and would apply a preponderance of the
evidence standard when deciding appeals. De novo review means that the
hearing officer would decide the issue on appeal without deference to a
previous decision (i.e., ONC's or the RCE's decision to (1) deny an
application, (2) suspend a QHIN or to instruct a QHIN to suspend its
Participant or Subparticipant, or (3) terminate a QHIN's Common
Agreement). We stated we believe de novo review is appropriate for
appeals by Applicant QHINs or QHINs because ONC ultimately has
responsibility for TEFCA operations and implementation, even though the
RCE is a contractor acting on ONC's behalf. Given the gravity and
potentially significant implications (financial, effect on existing
contracts, etc.) of a denied application, suspension, or termination,
we noted we believe the hearing officer the National Coordinator
arranges to be assigned should make an independent decision, taking all
of the facts and evidence the parties present into consideration.
As described in the HTI-2 Proposed Rule, the ``preponderance of the
evidence'' standard means the burden of proof is met when the party
with the burden (the appealing Applicant QHIN or QHIN) convinces the
fact finder (hearing officer) that there is a greater than 50% chance
that the claim is true. This standard is used in most civil cases and
would only require the appealing party to show that a particular fact
or event was more likely than not to have occurred. We stated we
believe this threshold creates the right balance for requiring an
appealing Applicant QHIN or QHIN to make a strong case to succeed on
appeal, while not imposing a standard that would be extremely difficult
for the appeal Applicant QHIN or QHIN to meet. We requested comment on
whether the ``preponderance of the evidence'' is the appropriate
standard, or if another standard (e.g., clear and convincing evidence,
beyond a reasonable doubt, etc.) would be more suitable.
In Sec. 172.606(b), we proposed that a hearing officer would make
a determination based on the written record or any information from a
hearing conducted in-person, via telephone, or otherwise (for example,
via video teleconference). We proposed that the written record would
include ONC's or the RCE's determination and supporting information, as
well as all appeal materials submitted by the Applicant QHIN or QHIN
pursuant to Sec. 172.603. We proposed these requirements for the
written record because it is important that the written record reflect
both the position of ONC or the RCE and the Applicant QHIN or QHIN. We
proposed that the hearing officer would have sole discretion to conduct
a hearing in certain situations. We proposed that the hearing officer
could conduct a hearing to require either party to clarify the written
record under Sec. 172.606(b)(1). Last, we proposed that the hearing
officer could conduct a hearing if they otherwise determine a hearing
is necessary. We stated we believe the last provision is necessary
because it gives the hearing officer discretion to conduct a hearing
based on the specific circumstances surrounding the appeal, even if the
need for the hearing does not fit under the first or second criteria
detailed above.
In Sec. 172.606(c), we proposed that a hearing officer would
neither receive witness testimony nor accept any new information beyond
what was provided in accordance with paragraph (b) of this section,
except for good cause shown by
[[Page 101803]]
the party seeking to submit new information. We noted we believe this
provision will help ensure that the appeals process is consistent and
fair for all involved.
In Sec. 172.607, we proposed requirements related to a decision by
the hearing officer. In Sec. 172.607(a), we proposed that the hearing
officer would issue a written determination. We requested comment on
whether we should include a specific timeframe for issuing the written
determination, or whether abstaining from including a specific
timeframe is a better approach given the varying complexity and
circumstances of each appeal.
To ensure accountability, and to ensure that the hearing officer's
decisions would be subject to the discretionary review of a principal
officer of the United States, we proposed in Sec. 172.607(b) that a
hearing officer's decision on an appeal is the final decision of HHS
unless within 10 business days, the Secretary, at the Secretary's sole
discretion, chooses to review the determination. We also proposed that
ONC would notify the appealing party if the Secretary chooses to review
the determination and once the Secretary makes his or her
determination. We did not propose a specific timeframe for the
Secretary to complete their review (if the Secretary chooses to review)
because we believe that if the Secretary makes the decision to review a
hearing officer's determination, the Secretary would be informed enough
on the issues of the case to determine an appropriate review timeframe.
As described elsewhere in this final rule, we have finalized
references to ``ONC'' in subpart F of the proposed rule as ``ASTP/
ONC.'' For further discussion of the use of ``ASTP/ONC,'' please see
the Executive Summary of this final rule.
Comments. Commenters were generally supportive of ASTP/ONC's
proposal for a review process of RCE or ASTP/ONC decisions but
expressed concerns regarding the scope and standard of ASTP/ONC's
review of RCE and prior ASTP/ONC decisions. In particular, some
commenters stated that ASTP/ONC's discretion for review of RCE or prior
ASTP/ONC decisions would be too broad and suggested that ASTP/ONC
include narrower requirements for when a Hearing Officer can review RCE
or prior ASTP/ONC decisions de novo, such as limiting use of the de
novo standard to only when it was a denial of QHIN designation. A few
commenters also suggested that ASTP/ONC specify a timeframe for ASTP/
ONC review and decision and similarly for review and written decisions
by a hearing officer. One commenter recommended that a hearing officer
have 30 days to issue a written decision on an appeal.
Response. We appreciate commenters concerns about the scope of
ASTP/ONC's ability to review decisions and the timeframe for when a
hearing officer must issue a decision. In this final rule, we finalize
all subpart F proposals as proposed, except for revisions made in
response to comments as discussed here. As TEFCA participation grows,
it is important for ASTP/ONC and a hearing officer to be able to review
decisions that are impactful to TEFCA participation, and in a manner
that gives all TEFCA participants confidence in TEFCA. A de novo
standard supports such confidence because the hearing officer can
exercise independent judgment and review of all relevant facts and law.
As for the timeframe for reviews, a 30-day timeframe for issuing a
decision by either ASTP/ONC or a hearing officer under subpart F could
be too limiting in complex cases. However, we do believe that providing
clarity on timeframes for decisions would be helpful to parties subject
to ASTP/ONC and/or hearing officer decisions. Accordingly, we have
revised subpart F in two ways. We have specified in Sec. 172.601(f)
that ASTP/ONC will issue a decision within a timeframe agreed to by the
affected Applicant QHIN or QHIN, as applicable, the RCE, and ASTP/ONC.
ASTP/ONC may, however, at its sole discretion, extend the timeframe for
a decision as circumstances necessitate. This remains consistent with
our proposal in that we did not place a time limit on issuing a
decision. ASTP/ONC will issue a decision by mailing or sending
electronically written notice of such decision as specified in Sec.
172.601(e). Similarly to ASTP/ONC timeframe revision, we have revised
Sec. 172.607(a) to specify that the hearing officer will issue a
written determination within a timeframe agreed to by the affected
Applicant QHIN or QHIN, as applicable, and ASTP/ONC and approved by the
hearing officer. The hearing officer may, at their sole discretion,
extend the timeframe for a written determination as circumstances
necessitate. Again, this is consistent with our proposal in that we did
not place a time limit on issuing a decision.
We have also revised the format of Sec. 172.603(a) to provide
clarity regarding the method and timing for an applicant QHIN or QHIN
to file an appeal. The addition of the numerated list in Sec.
172.603(a) is a formatting change made for clarity.
In addition, we have added to Sec. Sec. 172.601(a) and (b) and
172.605(a) language that if ASTP/ONC reviews (under Sec. 172.601(a))
or stays (under Sec. 172.601(b)) an RCE determination for which
regulations in part 172 required ASTP/ONC's prior authorization, no
agent, official, or employee of ASTP/ONC who helped to evaluate or
decide the prior authorization, or a prior authorization involving the
same party(s) or underlying facts, may participate in deciding or
advising ASTP/ONC on its review of (including whether it should stay)
that determination. This language will help protect any review by ASTP/
ONC of the RCE from influence by someone who previously authorized the
RCE action under review, protect the fairness and integrity of ASTP/
ONC's review process, and preserve the separation of functions within
ONC.
Comments. A commenter raised concerns that the scope of subpart F
was too limiting. The commenter recommended that disputes between
QHINs, and between a QHIN and a Participant, should be afforded review
and appeal under the regulations. The commenter argued that a QHIN's
dispute resolution policy, which it is required to maintain per subpart
B, would be ineffective in resolving disputes between QHINs or with a
Participant of another QHIN. The commenter further asserted that a
QHIN's decision to take action against a Participant significantly
affects that Participant, their patients, and other Participants
(including from other QHINs) that rely on the Participant's data to
make care decisions. As such, the commenter specifically recommended
that we include a process for appeal and ASTP/ONC review of QHIN
decisions to suspend Participants or Subparticipants, including
providing a Participant the opportunity to appeal such decisions. The
commenter also recommended that a QHIN be afforded the right to appeal
an instruction (presumably by the RCE or ASTP/ONC) to suspend a
Participant or Subparticipant.
Response. We did not propose the scope of review and appeals that
the commenter recommends, and the public was not put on notice that
such a policy might be finalized and given an opportunity to comment.
Thus, we decline to adopt such an approach in this final rule.
We note that we considered proposing to extend the appeal process
to Participants and Subparticipants but decided against proposing that
approach for a couple reasons. First, we believe that QHINs should have
the autonomy
[[Page 101804]]
to make decisions within their respective networks. Second, we note
that Participants and Subparticipants are able to join different QHINs
if they cannot resolve a dispute with an existing QHIN.
For similar reasons, we believe the Dispute Resolution Process
should be limited to disputes filed by the RCE or a QHIN. A QHIN could
elevate a dispute on behalf of its Participant or Subparticipant to the
Dispute Resolution Process, but we believe that is a decision that
should be left to the respective QHIN.
G. Subpart G--QHINTM Attestation for the Adoption of the
Trusted Exchange Framework and Common AgreementTM
Section 4003(b) of the Cures Act added section 3001(c)(9),
``Support for Interoperable Networks Exchange,'' to the PHSA. Section
3001(c)(9)(D)(ii) requires HHS to establish, through notice and comment
rulemaking, a process for HINs that voluntarily elect to adopt TEFCA to
attest to such adoption of the framework and agreement. Section
3001(c)(9)(D)(i) also requires the National Coordinator to publish on
ONC's website a list of the HINs that have adopted the Common Agreement
and are capable of trusted exchange pursuant to the Common Agreement.
QHINs are the only entities permitted to ``adopt'' the Common
Agreement, which is accomplished by becoming a signatory to the Common
Agreement. As such, we proposed that only QHINs would be able to attest
to the adoption of the Common Agreement and the Trusted Exchange
Framework. While the Trusted Exchange Framework was foundational for
creating the provisions of the Common Agreement, it is, as noted above,
a separate set of principles. Therefore, we proposed that for purposes
of attesting to the adoption of the Trusted Exchange Framework, QHINs
would be required to expressly attest to their agreement and adherence
to the Trusted Exchange Framework.\21\
---------------------------------------------------------------------------
\21\ The Trusted Exchange Framework (TEF): Principles for
Trusted Exchange (January 2022), https://www.healthit.gov/sites/default/files/page/2022-01/Trusted_Exchange_Framework_0122.pdf.
---------------------------------------------------------------------------
We described that once attestation is complete and deemed valid,
QHINs would be publicly listed on ONC's website. This regulatory
provision would implement the HIN attestation provision from the Cures
Act and would provide benefits to the public, Federal partners, and
interested parties. For example, a Federal website listing of attesting
QHINs would make it easy for the public to identify whether an entity
is or is not a QHIN and provide a resource for Federal partners to help
determine whether participants in some of their programs also belong to
a network that is recognized as a QHIN. Section 3001(c)(9)(E) provides
the option for Federal agencies to require, under certain
circumstances, adoption of TEFCA for health information exchange
networks that they contract with or enter into agreements with.
To implement sections 3001(c)(9)(D)(i) and (ii) of the PHSA, we
proposed to establish subpart G in part 172, titled ``QHIN Attestation
for the Adoption of the Trusted Exchange Framework and Common
Agreement.''
We proposed in Sec. 172.700 that subpart G would establish the
attestation submission requirements applicable to QHINs. In Sec.
172.701, we proposed attestation submission requirements for QHINs and
review and acceptance processes that ONC will follow for TEFCA
attestations. In Sec. 172.701(b), we proposed that in order to be
listed in the QHIN Directory described in proposed Sec. 172.702, a
QHIN would be required to submit to ONC an attestation affirming
agreement with and adherence to the Trusted Exchange Framework and its
adoption of the Common Agreement. We further proposed in Sec.
172.701(b) that a QHIN would be required to submit to ONC identifying
information consisting of its name, address, city, state, zip code, and
a hyperlink to its website. We also proposed that the QHIN would be
required to submit to ONC identifying information about its authorized
representative including the representative's name, title, phone
number, and email address. We proposed that a QHIN would also be
required to provide documentation confirming its Designation as a QHIN.
We also proposed that a QHIN would be required to provide ONC with
written notice of any changes to its identifying information provided
in accordance with Sec. 172.701 within 30 calendar days of the
change(s) to its identifying information. We noted we believe the above
provisions provide clear instructions for submitting a QHIN attestation
that will support a consistent and transparent QHIN attestation process
and provides ONC with the information needed to identify the entity and
contact the authorized representative.
We proposed in Sec. 172.701(c) that a QHIN must electronically
submit its attestation and documentation specified in Sec. 172.701(b)
either via an email address identified by ONC or via a submission on
the ONC website, if available. We proposed in Sec. 172.701(d) that
once a QHIN has submitted its attestation and documentation, ONC would
either accept or reject the submission within 30 calendar days. We
proposed that ONC would accept the submission if it determines that the
QHIN has satisfied the requirements of Sec. 172.701(b) and (c). In
such instances, we proposed that ONC would provide written notice to
the applicable QHIN's authorized representative that the submission has
been accepted. In Sec. 172.701(d), we also proposed that ONC would
reject a submission if it determines that the requirements of Sec.
172.701(b) or (c), or both, have not been satisfied. In such instances,
we proposed that ONC would provide written notice to the QHIN's
authorized representative of the determination along with the basis for
the determination. We proposed that an ONC determination would be a
final agency action and not subject to administrative review, except
the Secretary may choose to review the determination as provided in
Sec. 172.607(b). However, we proposed that a QHIN may, at any time,
resubmit an attestation and documentation in accordance with Sec. Sec.
172.701(b) and (c). We stated we believe these submission procedures
will support a consistent and transparent QHIN attestation process. We
welcomed comments on these procedures.
In Sec. 172.702, we proposed the requirements for a QHIN
directory. We proposed in Sec. 172.702(a) that this subpart would
establish processes for publishing a directory of QHINs on the ONC
website. We proposed in Sec. 172.702(b)(1) that, within fifteen (15)
calendar days of notifying a QHIN that its submission has been
accepted, ONC would publish, at a minimum, the QHIN's name in the QHIN
directory.
We proposed Sec. 172.702(b)(2) to identify within the QHIN
directory those QHINs that have been suspended under the Common
Agreement. A QHIN directory that includes QHINs that have adopted the
Common Agreement and are capable of TEFCA Exchange and those QHINs
suspended under the Common Agreement offers a transparent list of QHINs
participating in TEFCA. As noted above, the QHIN directory may serve as
a useful tool for the public, Federal partners, and other interested
parties seeking information about QHINs. Therefore, we welcomed
comments regarding the information we proposed to include in the QHIN
directory.
We proposed in Sec. 172.702(c) to establish requirements for
removal of a QHIN from the QHIN directory. We proposed in Sec.
172.702(c)(1) that ONC will remove a QHIN that is no longer eligible
for QHIN status from the QHIN
[[Page 101805]]
directory. We proposed that a QHIN whose Common Agreement has been
terminated would no longer be considered a QHIN and so would be removed
from the QHIN directory. We noted the removal of a QHIN whose Common
Agreement has been terminated from the QHIN Directory would be a
ministerial action by ONC.
We proposed in Sec. 172.702(c)(2) that upon termination of a
QHIN's Common Agreement, ONC (or an RCE) will send a written statement
of intent to remove the QHIN from the QHIN Directory to the authorized
representative of the QHIN. Under Sec. 172.702(c)(3), we proposed that
the written statement would include, as appropriate, (i) the name of
the terminated QHIN and the name and contact information of the
authorized representative of the QHIN; (ii) a short statement setting
forth findings of fact with respect to any violation of the Common
Agreement or other basis for the QHIN's termination; (iii) other
materials as the RCE may deem relevant. In Sec. 172.702(d), we
proposed that a QHIN that is removed from the QHIN Directory would
remain removed until a new attestation is accepted by ONC in accordance
with the processes specified in subpart G of the part. In Sec.
172.702(e), we proposed that an ONC determination under Sec. 172.702
is final agency action and not subject to further administrative
review, except the Secretary may choose to review the determination as
provided in Sec. 172.607(b). We stated we believe this proposal was
appropriate because a QHIN would have had ample opportunity to appeal
its termination under the provisions in proposed subpart F (89 FR
63654).
We sought comments on alternative ways to structure the
requirements to remove a QHIN from the QHIN directory.
Comments. Multiple commenters agreed with our proposal to require
QHINs to attest, with one commenter noting the potential burden
attestation could cause for all other Participants and Subparticipants.
Another commenter, while not suggesting we impose attestation
requirements, recommended that we include all TEFCA Participants,
Subparticipants and delegates along with their entity type (e.g.,
health plan, provider, delegate of provider) and relationship(s) in a
publicly accessible directory on ASTP/ONC's website. The commenter
asserted that this would provide greater transparency and help health
care organizations understand the networks that other entities
participate in to determine whether a connection already exists or if a
new exchange needs to be set-up.
Response. We appreciate commenters' agreement with our proposal and
one commenter's suggestions. In this final rule, we have finalized a
requirement, in order to be listed in the QHIN Attestation Directory,
that applies only to QHINs that attest. We have also finalized all
subpart G proposals as proposed, except for revisions made in response
to comments discussed here and below. We generally strive to improve
transparency where appropriate and permissible. Congress authorized, in
PHSA section 3001(c)(9)(D), a directory of health information networks,
which is a directory narrower in scope than the commenter suggested and
that we proposed. Therefore, we decline to adopt the commenter's
suggested changes to the scope of information included in the QHIN
Attestation Directory. We will consider ways in which TEFCA can improve
such transparency for QHINs, Participants, Subparticipants, and the
public at large.
Comments. One commenter did not support the QHIN attestation
proposal, arguing that it was unnecessary and duplicative of a QHIN
signing the Common Agreement. The commenter further questioned the
requirement to ``adhere to'' the Trusted Exchange Framework (TEF),
noting that, by its own terms, it is a compilation of non-binding
principles. Another commenter similarly argued that the TEF was broad
and could not be practically ``adhered to.'' Both of these commenters
inquired as to what ``adhere to'' meant in terms of the TEF, with one
suggesting that ``adhere to'' be replaced with ``agreement with.'' One
commenter suggested that we clarify that any rejection of an
attestation by ASTP/ONC will not affect the QHIN's designation status
or ability to participate in TEFCA.
Response. Establishing a process for attesting to the adoption of
TEFCA by QHINs that voluntarily elect to adopt TEFCA fulfills a
statutory obligation by ASTP/ONC. Such a process is paired with the
public posting on our website of a directory of these QHINs, which may
provide easy recognition and validation for the public of those
entities that have been deemed QHINs under TEFCA. We agree with
commenters that our proposed wording in Sec. 172.701(b)(1)(i)(A) of
``. . . [a]greement with and adherence to the [TEF] . . . .'' may cause
confusion and perceived contradiction with what are characterized as
broad, non-binding principles. The statute uses the term ``adoption''
with regard to both the Common Agreement and TEF. As such, we are
reverting to use of this term under our regulatory process for
attesting to adoption of the Common Agreement and the TEF by revising
Sec. 172.701(b)(1)(i) to read as follows: ``[a]ttestation affirming
its adoption of the Common Agreement and Trusted Exchange Framework.''
For clarity, by attesting to ``adopt'' the TEF, we mean a QHIN would
practice and use the TEF principles. We also clarify that the
regulatory process for QHIN attestation is separate and distinct from
the regulatory criteria we are finalizing for obtaining and maintaining
QHIN status, as well as any requirements in the Common Agreement.
Comments. Multiple commenters expressed a need for a definitive
attestation schedule for QHINs. One commenter suggested that we
incorporate the required attestation into the RCE's onboarding and
designation process.
Response. Attestation would be expected each time a QHIN signs the
Common Agreement, including new versions, and/or the TEF is updated. To
be listed on the ASTP/ONC website, QHINs would need to comply with the
attestation submission and acceptance requirements of Sec. 172.701. As
proposed and finalized in Sec. 172.701 a QHIN will be able to
electronically submit its attestation via email or via the ASTP/ONC
website, if available. The exact timing (beyond when signing the Common
Agreement and/or when the TEF is updated) and specifics of the
submission method, such as by use of a voluntary standard form, will
not be codified in regulation through this final rule, but will be
determined in a manner that best aligns with statutory obligations and
overall efficiencies.
Comments. Multiple commenters expressed concern that use of ``QHIN
Directory'' will confuse stakeholders, as the Common Agreement refers
to an ``RCE Directory Service'' and the QHIN Technical Framework (QTF)
refers to a ``QHIN Directory.'' One commenter suggested that we
establish a hyperlink from our website to the RCE website because the
RCE maintains a list of QHINs.
Response. Our approach, finalized in this final rule, fulfills a
specific statutory requirement to post the names on our website. We
agree with the commenters that ``QHIN Directory'' may cause some
confusion. Therefore, in alignment with the statutory instruction, we
are renaming the directory ``QHIN Attestation Directory'' and have
revised references throughout Sec. Sec. 172.701 and 172.702
accordingly to refer to the ``QHIN Attestation Directory'' rather than
the QHIN Directory. We have also
[[Page 101806]]
revised Sec. 172.702(a) (``Applicability'') to more clearly align with
statutory instruction by stating ``[t]his subpart establishes processes
for publishing a directory on the ASTP/ONC website of QHINs that
voluntarily elect to adopt TEFCA and attest to such adoption.'' We also
note, in response to comment, that we currently provide a hyperlink to
the RCE website from our website.
As described elsewhere in this final rule, we have finalized
references to ``ONC'' in subpart G of the proposed rule as ``ASTP/
ONC.'' For further discussion of the use of ``ASTP/ONC,'' please see
the Executive Summary of this final rule. We also made a minor change
to Sec. 172.702(c)(3)(iii) by removing the word ``the'' before ASTP/
ONC, to align with other references to ASTP/ONC. This change is for
clarity and is non-substantive.
VI. Severability
As we explained in the HTI-2 Proposed Rule (89 FR 63511), it was
our intent that if any provision of the proposed rule were, if or when
finalized, held to be invalid or unenforceable--facially or as applied
to any person, plaintiff, or circumstance--or stayed pending further
judicial or agency action, such provision shall be severable from other
provisions finalized, and from rules and regulations otherwise in
effect, and not affect the remainder of provisions finalized. It was
and continues to be our intent that, unless such provision shall be
held to be utterly invalid or unenforceable, it be construed to give
the provision maximum effect permitted by law including in the
application of the provision to other persons not similarly situated or
to other, dissimilar circumstances from those where the provision may
be held to be invalid or unenforceable.
This final rule establishes part 172 and finalizes revisions to
certain sections within 45 CFR parts 170 and 171. The provisions
finalized in this final rule, whether codified in 45 CFR part 170, 171,
or 172, are intended to and will operate independently of each other
and of provisions finalized in previous rules, even if multiple of them
may serve the same or similar general purpose(s) or policy goal(s).
Where any section or paragraph in part 170, 171, or 172 is necessarily
dependent on another, the context generally makes that clear (such as
by cross-reference to a particular standard, requirement, condition, or
pre-requisite, or other regulatory provision). Where any section or
paragraph within 45 CFR part 170, 171, or 172 includes a dependency on
any provision of any section or paragraph of any part in title 45 of
the CFR, or in any other title of the CFR, that is stayed or held
invalid or unenforceable (as described in the preceding paragraph), we
intend that other provisions of such paragraph(s) or section(s) in 45
CFR part 170, 171, or 172 that operate independently of said provision
would remain in effect.
For example, if the regulation at Sec. 171.403 TEFCA Manner
Exception were stayed or held facially invalid or unenforceable in
whole or in part, we would intend for the other information blocking
exceptions in part 171 to remain available to actors, and for all
sections and paragraphs within parts 170 and 172 to also continue to be
in effect. To provide another example, if any provision of any section
or paragraph of part 172 were stayed or held utterly invalid or
unenforceable, we would intend for all other sections in part 172 that
do not depend upon the stayed or invalidated provisions to remain in
full effect. Similarly, if any provision of part 172 were stayed or
held to be invalid or unenforceable as applied to any person,
plaintiff, or circumstance, it is our intent that such provision--and
any section or paragraph of part 172, 171, or 170 that may reference
such provision--be construed to give the provision maximum effect
permitted by law including in the application of the provision to other
persons not similarly situated or to other, dissimilar circumstances
from those where the provision may be held to be invalid or
unenforceable.
To ensure our intent for severability of provisions is clear in the
CFR, we proposed (as explained at 89 FR 63511) the addition to
Sec. Sec. 170.101 (89 FR 63766) and 171.101 (89 FR 63802), and
inclusion in the newly codified Sec. 172.101 (89 FR 63805), of a
paragraph stating our intent that if any provision is held to be
invalid or unenforceable it shall be construed to give maximum effect
to the provision permitted by law, unless such holding shall be one of
utter invalidity or unenforceability, in which case the provision shall
be severable from the part and shall not affect the remainder thereof
or the application of the provision to other persons not similarly
situated or to other dissimilar circumstances.
We did not receive any comments specific to our proposal to codify
paragraphs stating our intent for severability in part 170, 171, or 172
or regarding our explanation that the provisions finalized in this rule
are intended to and will operate independently of each other. We have
finalized as proposed, the addition to Sec. Sec. 170.101 and 171.101,
and inclusion in the newly codified Sec. 172.101, a paragraph stating
our intent for severability of provisions in each of these parts. We
affirm and emphasize our intent that if any provision of this final
rule were held to be invalid or unenforceable--facially or as applied
to any person, plaintiff, or circumstance--or stayed pending further
judicial or agency action, such provision shall be severable from other
provisions of this rule, and from rules and regulations currently in
effect, and not affect the remainder of this rule. We further affirm
and emphasize our intent that if any provision codified in part 170,
171, or 172, whether finalized in this or a prior rule, were to be held
to be invalid or unenforceable--facially or as applied to any person,
plaintiff, or circumstance--or stayed pending further judicial or
agency action, such provision shall be severable from other provisions
of this rule, and from rules and regulations currently in effect, and
not affect the remainder of this final rule. It is also our intent
that, unless such provision shall be held to be utterly invalid or
unenforceable, it be construed to give the provision maximum effect
permitted by law including in the application of the provision to other
persons not similarly situated or to other, dissimilar circumstances
from those where the provision may be held to be invalid or
unenforceable.
VII. Collection of Information Requirements--Qualified Health
Information Networks\TM\
Under the Paperwork Reduction Act of 1995 (PRA), codified as
amended at 44 U.S.C. 3501 et seq., agencies are required to provide a
60-day notice in the Federal Register and solicit public comment on a
proposed collection of information before it is submitted to OMB for
review and approval. In order to fairly evaluate whether an information
collection should be approved by the OMB, section 3506(c)(2)(A) of the
PRA requires that we solicit comment on the following issues:
1. Whether the information collection is necessary and useful to
carry out the proper functions of the agency.
2. The accuracy of the agency's estimate of the information
collection burden;
3. The quality, utility, and clarity of the information to be
collected; and
4. Recommendations to minimize the information collection burden on
the affected public, including automated collection techniques.
Under the PRA, the time, effort, and financial resources necessary
to meet
[[Page 101807]]
the information collection requirements referenced in this section are
to be considered. We solicited comment on our assumptions as they
relate to the PRA requirements summarized in this section.
Qualified Health Information Networks\TM\
As stated in the HTI-2 Proposed Rule (89 FR 63661), we proposed in
Sec. 172.301 to establish the information Applicant QHINs must submit
in order to be Designated as a QHIN. We proposed that an Applicant QHIN
must submit: (1) a completed QHIN application; and (2) a signed copy of
the Common Agreement. We noted that we may update the application over
time and the most recent version will be available on ASTP/ONC's and
the RCE's website.
In Sec. 172.701, we proposed attestation submission requirements
for QHINs and review and acceptance processes that ONC would follow for
TEFCA attestations. In Sec. 172.701(b), we proposed that in order to
be listed in the QHIN Directory described in proposed Sec. 172.702, a
QHIN would be required to submit to ONC an attestation affirming
agreement with and adherence to the Trusted Exchange Framework and its
adoption of the Common Agreement. We further proposed in Sec.
172.701(b) that a QHIN would be required to submit to ONC identifying
information consisting of its name, address, city, state, zip code, and
a hyperlink to its website. We also proposed that the QHIN would be
required to submit to ONC identifying information about its authorized
representative including the representative's name, title, phone
number, and email address.
We proposed that a QHIN would also be required to provide
documentation confirming its Designation as a QHIN. We also proposed
that a QHIN would be required to provide ONC with written notice of any
changes to its identifying information provided in accordance with
Sec. 172.701 within 30 calendar days of the change(s) to its
identifying information.
We stated our belief that QHINs would face minimal burden in
complying with the proposed application, attestation, and supporting
documentation requirements. For the purposes of estimating the
potential burden, we estimated that 15 Applicant QHINs would apply and
subsequently submit an attestation to ONC. We stated that it would take
approximately one hour on average for an applicant QHIN to submit a
completed QHIN application. We also stated that it would also take
approximately one hour on average for a QHIN to complete and submit to
ONC their attestation and required documentation. We stated that we
expect a general office clerk could complete these required
responsibilities.\22\ We welcomed comments on whether more or fewer
QHINs should be included in our estimate. We also welcomed comments on
whether more or less time should be included in our estimate.
---------------------------------------------------------------------------
\22\ According to the May 2022 Bureau of Labor Statistics
occupational employment statistics, the mean hourly wage for Office
Clerks, General (43-9061) is $19.78.
Table 2--Estimated Annualized Total Burden Hours for QHINs To Comply With Application and Attestation
Requirements
----------------------------------------------------------------------------------------------------------------
Number of
Code of Federal Regulations section applicant QHIN Average burden Total
or QHINs hours
----------------------------------------------------------------------------------------------------------------
45 CFR 172.301.................................................. 15 1 15
45 CFR 172.701.................................................. 15 1 15
-----------------------------------------------
Total Burden Hours.......................................... .............. .............. 30
----------------------------------------------------------------------------------------------------------------
Comments. We did not receive any comments related to information
collection activities for QHINs.
Response. We have finalized our regulatory collection of
information requirements as proposed, but with unrelated revisions to
subparts B, C, and G.
VIII. Regulatory Impact Analysis
A. Statement of Need
This final rule is necessary to meet our statutory responsibilities
under the Cures Act and to advance HHS policy goals to promote
interoperability and information sharing.
B. Alternatives Considered
We have been unable to identify alternatives that would
appropriately implement our responsibilities under the Cures Act and
support interoperability and information sharing consistent with our
policy goals. We believe our policies take the necessary steps to
fulfill the mandates specified in the PHSA, as amended by the HITECH
Act and the Cures Act, in the least burdensome way. We welcomed
comments on our assessment and any alternatives we should have
considered.
Comments. We did not receive any comments on alternatives that we
should have considered related to the provisions included in this final
rule.
Response. We have finalized our assessments on the proposals
finalized in this final rule.
C. Overall Impact--Executive Orders 12866 and 13563--Regulatory
Planning and Review Analysis
We have examined the impacts of this final rule as required by
Executive Order 12866 on Regulatory Planning and Review (September 30,
1993), Executive Order 13563 on Improving Regulation and Regulatory
Review (January 18, 2011), Executive Order 14094, entitled
``Modernizing Regulatory Review'' (April 6, 2023), the Regulatory
Flexibility Act (RFA) (September 19, 1980, Pub. L. 96354), section 202
of the Unfunded Mandates reform Act of 1995 (March 22, 1995; Pub. L.
104-4), the Small Business Regulatory Enforcement Fairness Act of 1996
(also known as the Congressional Review Act, 5 U.S.C. 801 et seq.), and
the Executive Order 13132 on Federalism (August 4, 1999).
Executive Orders 12866 and 13563 direct agencies to assess all
costs and benefits of available regulatory alternatives and, if
regulation is necessary, to select regulatory approaches that maximize
net benefits (including potential economic, environmental, public
health and safety effects, distributive impacts, and equity). The
Executive Order 14094 amends section 3(f) of Executive Order 12866. The
amended section 3(f) of Executive Order 12866 defines a ``significant
regulatory action'' as an
[[Page 101808]]
action that is likely to result in a rule: (1) having an annual effect
on the economy of $200 million or more in any 1 year (adjusted every 3
years by the Administrator of OMB's OIRA for changes in gross domestic
product), or adversely affect in a material way the economy, a sector
of the economy, productivity, competition, jobs, the environment,
public health or safety, or State, local, territorial, or tribal
governments or communities; (2) creating a serious inconsistency or
otherwise interfering with an action taken or planned by another
agency; (3) materially altering the budgetary impacts of entitlement
grants, user fees, or loan programs or the rights and obligations of
recipients thereof; or (4) raise legal or policy issues for which
centralized review would meaningfully further the President's
priorities or the principles set forth in the Executive order, as
specifically authorized in a timely manner by the Administrator of OIRA
in each case.
An RIA must be prepared for rules with significant regulatory
action(s) and/or with significant effects as per section 3(f)(1) ($200
million or more in any 1 year). OIRA has determined that this final
rule is not a significant regulatory action under 3(f) of Executive
Order 12866, as amended by E.O. 14094. Accordingly, we have not
prepared a detailed RIA. We did, however, include some quantitative
analysis of the costs and benefits of this final rule.
Pursuant to Subtitle E of the Small Business Regulatory Enforcement
Fairness Act of 1996 (also known as the Congressional Review Act, 5
U.S.C. 801 et seq.), OIRA has determined that this final rule does not
meet the criteria set forth in 5 U.S.C. 804(2).
Trusted Exchange Framework and Common Agreement\SM\
The regulations in 45 CFR part 172 outline the application
requirements an Applicant Qualified Health Information Network[supreg]
(QHIN\TM\) must submit in order to be Designated as a QHIN, ongoing
Designation requirements, and the requirements that an entity would
attest to meeting as a QHIN under the TEFCA framework. We estimate that
an Applicant QHIN will spend on average an hour to complete the
application process. We estimate that an average QHIN will spend at
most one hour to complete the attestation process. As we stated in the
regulatory impact analysis in the HTI-2 Proposed Rule, we consider
these efforts to be de minimis.
We do not assess the burden of a QHIN to appeal a Recognized
Coordinating Entity[supreg] (RCE\TM\) decision as part of their
participation in the TEFCA framework, as this rulemaking creates the
appeals process for QHINs but does not require it. Further, we expect
that appeals will most often follow RCE decisions related to QHIN
participation in the TEFCA framework, rather than ASTP/ONC decisions.
We, therefore, do not assess the burden of the appeals process as part
of this rulemaking's impact analysis.
Comments. We did not receive any comments on the costs and benefits
related to the provisions included in this final rule.
Response. We have finalized our regulatory impact analyses on the
matters finalized in this final rule as discussed above and in the HTI-
2 Proposed Rule.
D. Regulatory Flexibility Act
The RFA requires agencies to analyze options for regulatory relief
of small businesses if a rule has a significant impact on a substantial
number of small entities. The Small Business Administration (SBA)
establishes the size of small businesses for Federal Government
programs based on average annual receipts or the average employment of
a firm.\23\
---------------------------------------------------------------------------
\23\ The SBA references that annual receipts mean ``total
income'' (or in the case of a sole proprietorship, ``gross income'')
plus ``cost of goods sold'' as these terms are defined and reported
on Internal Revenue Service tax return forms.
---------------------------------------------------------------------------
Although we did not include an analysis of the proposed TEFCA
regulations in the HTI-2 Proposed Rule, we have included an analysis of
the finalized TEFCA regulations in this final rule. We estimate that up
to 15 Applicant QHINs would apply and subsequently submit an
attestation to ASTP/ONC to be listed in the QHIN Attestation Directory.
Section 3001(c)(9)(B)(i) of the PHSA provides the National Coordinator
with the authority to ``develop or support a trusted exchange framework
for trust policies and practices and for a common agreement for
exchange between health information networks.'' The components of this
Trusted Exchange Framework and Common Agreement\TM\ (TEFCA\TM\) include
the Trusted Exchange Framework (a common set of principles designed to
facilitate trust between health information networks (HINs)) and the
Common Agreement (the agreement Qualified Health Information
Networks[supreg] (QHINs\TM\) sign), which includes, among other
provisions, privacy, compliance, and security requirements). The Common
Agreement also references the QHIN Technical Framework (QTF) (which
describes technical requirements for exchange among QHINs) as well as,
where necessary, SOPs.
By providing a common and consistent approach for the exchange of
health information across many different networks, TEFCA simplifies and
significantly reduces the number of separate networks that individuals,
health care providers, and other interested parties need to be a part
of in order to access the health information they seek. Health
information networks that voluntarily join TEFCA will facilitate
exchange in a secure and interoperable manner. TEFCA establishes a
method for authenticating trusted health information network
participants, potentially lowering the cost, and expanding the
nationwide availability of secure health information exchange
capabilities. The establishment of technical services for health
information networks that voluntarily join TEFCA, such as an electronic
address directory and security services, will be critical to scale
network exchange nationwide. In addition, the organizational and
operational policies established through TEFCA enable the exchange of
health information among health information networks and include
minimum conditions required for such exchange to occur. We believe our
qualification criteria is structured in a way that it encourages
participation from small entities.
We believe that many health information networks impacted by this
final rule most likely fall under the North American Industry
Classification System (NAICS) code 541511 ``Custom Computer Programming
Services.'' \24\ OMB advised that the Federal statistical establishment
data published for reference years beginning on or after January 1,
2022, should be published using the 2022 NAICS United States codes.\25\
The SBA size standard associated with this NAICS code is set at $34
million annual receipts or less. There is enough data generally
available to establish that between 75% and 90% of entities that are
categorized under the NAICS code 541511 are under the SBA size
standard.
---------------------------------------------------------------------------
\24\ https://www.sba.gov/sites/sbagov/files/2023-06/Table%20of%20Size%20Standards_Effective%20March%2017%2C%202023%20%282%29.pdf.
\25\ https://www.sba.gov/article/2022/feb/01/guidance-using-naics-2022-procurement.
---------------------------------------------------------------------------
We estimate that this final rule would have effects on health
information networks, some of which may be small entities. We believe,
however, that we have adopted the minimum number of requirements
necessary to accomplish our primary policy goal of enhancing
[[Page 101809]]
interoperability. Further, as discussed in this RIA above, there are
very few appropriate regulatory or non-regulatory alternatives that
could be developed to lessen the compliance burden associated with this
final rule because the policies are derived directly from legislative
mandates in the Cures Act.
Comments. We received no comments on our approach.
Response. We have finalized our approach and analysis as discussed
above. We do not believe that this final rule would create a
significant impact on a substantial number of small entities, and the
Secretary certifies that this final rule would not have a significant
impact on a substantial number of small entities.
E. Executive Order 13132--Federalism
Executive Order 13132 establishes certain requirements that an
agency must meet when it promulgates a rule that imposes substantial
direct requirement costs on state and local governments, preempts state
law, or otherwise has federalism implications.
Comments We received no comments.
Response. Nothing in this final rule imposes substantial direct
compliance costs on state and local governments, preempts state law, or
otherwise has federalism implications.
F. Unfunded Mandates Reform Act of 1995
Section 202 of the Unfunded Mandates Reform Act of 1995 requires
that agencies assess anticipated costs and benefits before issuing any
rule that imposes unfunded mandates on state, local, and tribal
governments or the private sector requiring spending in any one year of
$100 million in 1995 dollars, updated annually for inflation. The
current inflation-adjusted statutory threshold is approximately $183
million in 2024.
Comments. We received no comments on the application of this law to
our proposals finalized in this final rule.
Response. The estimated potential cost effects of this final rule
do not reach the statutory threshold; therefore, this final rule does
not impose unfunded mandates on state, local, and tribal governments,
or the private sector.
List of Subjects
45 CFR Part 170
Computer technology, Electronic health record, Electronic
information system, Electronic transactions, Health, Healthcare, Health
information technology, Health insurance, Health records, Hospitals,
Laboratories, Medicaid, Medicare, Privacy, Public health, Reporting and
recordkeeping requirements, Security.
45 CFR Part 171
Computer technology, Electronic health record, Electronic
information system, Electronic transactions, Health, Healthcare, Health
care provider, Health information exchange, Health information
technology, Health information network, Health insurance, Health
records, Hospitals, Privacy, Public health, Reporting and recordkeeping
requirements, Security.
45 CFR Part 172
Computer technology, Electronic health record, Electronic
information system, Electronic transactions, Health, Healthcare, Health
information technology, Health insurance, Health records, Hospitals,
Laboratories, Medicaid, Medicare, Privacy, Public health, Security.
For the reasons set forth in the preamble, 45 CFR subtitle A,
subchapter D, is amended as follows:
PART 170--HEALTH INFORMATION TECHNOLOGY STANDARDS, IMPLEMENTATION
SPECIFICATIONS, AND CERTIFICATION CRITERIA AND CERTIFICATION
PROGRAMS FOR HEALTH INFORMATION TECHNOLOGY
0
1. The authority citation for part 170 continues to read as follows:
Authority: 42 U.S.C. 300jj-11; 42 U.S.C 300jj-14; 5 U.S.C. 552.
0
2. Revise Sec. 170.101 to read as follows:
Sec. 170.101 Applicability.
(a) The standards, implementation specifications, and certification
criteria adopted in this part apply to health information technology
and the testing and certification of Health IT Modules.
(b) If any provision of this part is held to be invalid or
unenforceable facially, or as applied to any person, plaintiff, or
circumstance, it shall be construed to give maximum effect to the
provision permitted by law, unless such holding shall be one of utter
invalidity or unenforceability, in which case the provision shall be
severable from this part and shall not affect the remainder thereof or
the application of the provision to other persons not similarly
situated or to other dissimilar circumstances.
0
3. Amend Sec. 170.315 by:
0
a. Removing and reserving paragraphs (a)(10) and (13) and (b)(6);
0
b. Revising paragraphs (b)(7) and (8); and
0
c. Removing and reserving paragraphs (e)(2) and (g)(2).
The revisions read as follows:
Sec. 170.315 ONC certification criteria for Health IT.
* * * * *
(b) * * *
(7) Security tags--summary of care--send. Enable a user to create a
summary record formatted in accordance with the standard adopted in
Sec. 170.205(a)(4) that is tagged as restricted and subject to
restrictions on re-disclosure according to the standard adopted in
Sec. 170.205(o)(1) at the document, section, and entry (data element)
level.
(8) Security tags--summary of care--receive. (i) Enable a user to
receive a summary record that is formatted in accordance with the
standard adopted in Sec. 170.205(a)(4) that is tagged as restricted
and subject to restrictions on re-disclosure according to the standard
adopted in Sec. 170.205(o)(1) at the document, section, and entry
(data element) level; and
(ii) Preserve privacy markings to ensure fidelity to the tagging
based on consent and with respect to sharing and re-disclosure
restrictions.
* * * * *
0
4. Amend Sec. 170.502 by revising the definition of ``Gap
certification'' to read as follows:
Sec. 170.502 Definitions.
* * * * *
Gap certification means the certification of a previously certified
Health IT Module(s) to:
(1) All applicable new and/or revised certification criteria
adopted by the Secretary at subpart C of this part based on test
results issued by a NVLAP-accredited testing laboratory under the ONC
Health IT Certification Program or an ONC-ATL; and
(2) All other applicable certification criteria adopted by the
Secretary at subpart C of this part based on the test results used to
previously certify the Health IT Module(s) under the ONC Health IT
Certification Program.
* * * * *
0
5. Revise Sec. 170.511 to read as follows:
Sec. 170.511 Authorization scope for ONC-ATL status.
Applicants may seek authorization from the National Coordinator to
perform the testing of Health IT Modules to a portion of a
certification criterion, one certification criterion, or many or all
certification criteria adopted by the Secretary under subpart C of this
part.
0
6. Amend Sec. 170.523 by revising paragraphs (f) introductory text and
(j)(3) to read as follows:
[[Page 101810]]
Sec. 170.523 Principles of proper conduct for ONC-ACBs.
* * * * *
(f) Certified product listing. Provide the Assistant Secretary for
Technology Policy/Office of the National Coordinator for Health
Information Technology (ASTP/ONC), no less frequently than weekly, a
current list of Health IT Modules that have been certified that
includes, at a minimum:
* * * * *
(j) * * *
(3) Previous certifications that it performed if its conduct
necessitates the recertification of Health IT Module(s).
* * * * *
0
7. Amend Sec. 170.550 by revising paragraph (h)(3)(ii) and adding
paragraph (h)(4) to read as follows:
Sec. 170.550 Health IT Module certification.
* * * * *
(h) * * *
(3) * * *
(ii) Section 170.315(a)(4), (10), and (13) and, on and after
January 1, 2028, (b)(11), are also certified to the certification
criteria specified in Sec. 170.315(d)(1) through (3), (5) through (7),
and (12), and, for the time period up to and including December 31,
2027, (d)(13).
* * * * *
(4) Methods to demonstrate compliance with each privacy and
security criterion. One of the following methods must be used to meet
each applicable privacy and security criterion listed in paragraph
(h)(3) of this section:
(i) Directly, by demonstrating a technical capability to satisfy
the applicable certification criterion or certification criteria; or
(ii) Demonstrate, through system documentation sufficiently
detailed to enable integration, that the Health IT Module has
implemented service interfaces for each applicable privacy and security
certification criterion that enable the Health IT Module to access
external services necessary to meet the privacy and security
certification criterion.
* * * * *
PART 171--INFORMATION BLOCKING
0
8. The authority citation for part 171 continues to read as follows:
Authority: 42 U.S.C. 300jj-52; 5 U.S.C. 552.
0
9. Amend Sec. 171.101 by adding paragraph (c) to read as follows:
Sec. 171.101 Applicability.
* * * * *
(c) If any provision of this part is held to be invalid or
unenforceable facially, or as applied to any person, plaintiff, or
circumstance, it shall be construed to give maximum effect to the
provision permitted by law, unless such holding shall be one of utter
invalidity or unenforceability, in which case the provision shall be
severable from this part and shall not affect the remainder thereof or
the application of the provision to other persons not similarly
situated or to other dissimilar circumstances.
0
10. Add Sec. 171.401 to read as follows:
Sec. 171.401 Definitions.
Common Agreement has the meaning given to it in 45 CFR 172.102.
Framework Agreement has the meaning given to it in 45 CFR 172.102.
Participant has the meaning given to it in 45 CFR 172.102.
Qualified Health Information Network or QHIN has the meaning given
to it in 45 CFR 172.102.
Subparticipant has the meaning given to it in 45 CFR 172.102.
0
11. Add part 172 to read as follows:
PART 172--TRUSTED EXCHANGE FRAMEWORK AND COMMON AGREEMENT
Subpart A--General Provisions
Sec.
172.100 Basis, purpose, and scope.
172.101 Applicability.
172.102 Definitions.
172.103 Responsibilities ASTP/ONC may delegate to the RCE.
Subpart B--Qualifications for Designation
172.200 Applicability.
172.201 QHIN Designation requirements.
172.202 QHINS that offer Individual Access Services.
Subpart C--QHIN Onboarding and Designation Processes
172.300 Applicability.
172.301 Submission of QHIN application.
172.302 Review of QHIN application.
172.303 QHIN approval and Onboarding.
172.304 QHIN Designation.
172.305 Withdrawal of QHIN application.
172.306 Denial of QHIN application.
172.307 Re-application.
Subpart D--Suspension
172.400 Applicability.
172.401 QHIN suspensions.
172.402 Selective suspension of exchange between QHINs.
Subpart E--Termination
172.500 Applicability.
172.501 QHIN self-termination.
172.502 QHIN termination.
172.503 Termination by mutual agreement.
Subpart F--Review of RCE or ASTP/ONC Decisions
172.600 Applicability.
172.601 ASTP/ONC review.
172.602 Basis for appeal by QHIN or Applicant QHIN.
172.603 Method and timing for filing an appeal.
172.604 Effect of appeal on suspension and termination.
172.605 Assignment of a hearing officer.
172.606 Adjudication.
172.607 Determination by the hearing officer.
Subpart G--QHIN Attestation for the Adoption of the Trusted Exchange
Framework and Common Agreement
172.700 Applicability.
172.701 Attestation submission and acceptance.
172.702 QHIN Attestation Directory.
Authority: 42 U.S.C. 300jj-11; 5 U.S.C. 552.
Subpart A--General Provisions
Sec. 172.100 Basis, purpose, and scope.
(a) Basis and authority. The provisions of this part implement
section 3001(c)(9) of the Public Health Service Act.
(b) Purpose. The purpose of this part is to:
(1) Ensure full network-to-network exchange of health information;
and
(2) Establish a voluntary process for a Qualified Health
Information Network\TM\ (QHIN\TM\) to attest to adoption of the Trusted
Exchange Framework and Common Agreement\TM\ (TEFCA\TM\).
(c) Scope. This part addresses:
(1) Minimum qualifications needed for a health information network
to be Designated as a QHIN capable of trusted exchange under TEFCA.
(2) Procedures governing QHIN Onboarding and Designation,
suspension, termination, and further administrative review.
(3) Attestation submission requirements for a QHIN to attest to its
adoption of TEFCA.
(4) ASTP/ONC attestation acceptance and removal processes for
publication of attesting QHINs in the QHIN Attestation Directory.
Sec. 172.101 Applicability.
(a) This part applies to Applicant QHINS, QHINs, terminated QHINs,
and the Recognized Coordinating Entity.
(b) If any provision of this part is held to be invalid or
unenforceable facially, or as applied to any person, plaintiff, or
circumstance, it shall be construed to give maximum effect to the
provision permitted by law, unless such holding shall be one of utter
invalidity or unenforceability, in which case the provision shall be
severable from this part and shall not affect the remainder thereof or
the application of the provision to other persons not similarly
[[Page 101811]]
situated or to other dissimilar circumstances.
Sec. 172.102 Definitions.
For purposes of this part, the following definitions apply:
Applicable Law. All Federal, State, local, or Tribal laws and
regulations then in effect and applicable to the subject matter in this
part. For the avoidance of doubt, Federal agencies are subject only to
Federal law.
Applicant QHIN. Any organization with a pending QHIN application
before the Assistant Secretary for Technology Policy/Office of the
National Coordinator for Health Information Technology (ASTP/ONC).
Business Associate Agreement (BAA). A contract, agreement, or other
arrangement that satisfies the implementation specifications described
within 45 CFR parts 160 and subparts A, C, and E of 45 CFR part 164, as
applicable.
Business day or business days. Monday through Friday, except the
legal public holidays specified in 5 U.S.C. 6103 and any day declared
to be a holiday by Federal statute or Executive order.
Common Agreement. The most recent version of the agreement
referenced in section 3001(c)(9) of the Public Service Health Act as
published in the Federal Register.
Confidential Information. Any information that is designated as
Confidential Information by the person or entity that discloses it, or
that a reasonable person would understand to be of a confidential
nature and is disclosed to another person or entity pursuant to TEFCA
Exchange. For the avoidance of doubt, ``Confidential Information'' does
not include electronic protected health information (ePHI).
Notwithstanding any label to the contrary, ``Confidential Information''
does not include any information that:
(1) Is or becomes known publicly through no fault of the recipient;
or
(2) Is learned by the recipient from a third party that the
recipient reasonably believes is entitled to disclose it without
restriction; or
(3) Is already known to the recipient before receipt from the
discloser, as shown by the recipient's written records; or
(4) Is independently developed by recipient without the use of or
reference to the discloser's Confidential Information, as shown by the
recipient's written records, and was not subject to confidentiality
restrictions prior to receipt of such information from the discloser;
or
(5) Must be disclosed under operation of law, provided that, to the
extent permitted by Applicable Law, the recipient gives the discloser
reasonable notice to allow the discloser to object to such
redisclosure, and such redisclosure is made to the minimum extent
necessary to comply with Applicable Law.
Connectivity Services. The technical services provided by a QHIN,
Participant, or Subparticipant to its Participants and Subparticipants
that facilitate TEFCA Exchange and are consistent with the technical
requirements of the TEFCA framework.
Covered Entity. Has the meaning assigned to such term at 45 CFR
160.103.
Designated Network. The health information network that a QHIN uses
to offer and provide Designated Network Services.
Designated Network Services. The Connectivity Services and/or
Governance Services.
Designation (including its correlative meanings ``Designate,''
``Designated,'' and ``Designating''). The written determination that an
Applicant QHIN has satisfied all requirements and is now a QHIN.
Disclosure (including its correlative meanings ``Disclose,''
``Disclosed,'' and ``Disclosing''). The release, transfer, provision of
access to, or divulging in any manner of TEFCA Information (TI) outside
the entity holding the information.
Electronic Protected Health Information (ePHI). Has the meaning
assigned to such term at 45 CFR 160.103.
Exchange Purpose(s) or XP(s). The reason, as authorized by a
Framework Agreement, including the applicable standard operating
procedure(s) (SOP(s)), for a transmission, Query, Use, Disclosure, or
Response transacted through TEFCA Exchange.
Exchange Purpose Code or XP Code. A code that identifies the
Exchange Purpose being used for TEFCA Exchange.
Foreign Control. A non-U.S. Person(s) or non-U.S. Entity(ies)
having the direct or indirect power, whether or not exercised, to
direct or decide matters materially affecting the Applicant's ability
to function as a QHIN in a manner that presents a national security
risk.
Framework Agreement(s). With respect to QHINs, the Common
Agreement; and with respect to a Participant or Subparticipant, the
Participant/Subparticipant Terms of Participation (ToP).
Governance Services. The governance functions described in
applicable SOP(s), which are performed by a QHIN's Designated Network
Governance Body for its Participants and Subparticipants to facilitate
TEFCA Exchange in compliance with the then-applicable requirements of
the Framework Agreements.
Health information network or HIN. The meaning assigned to it in 45
CFR 171.102.
Individual has the meaning assigned to such term at 45 CFR
171.202(a)(2).
HIPAA. The Health Insurance Portability and Accountability Act of
1996.
HIPAA Privacy Rule. The regulations set forth in 45 CFR part 160
and subparts A and E of 45 CFR part 164.
HIPAA Rules. The regulations set forth at 45 CFR parts 160, 162,
and 164.
HIPAA Security Rule. The regulations set forth in 45 CFR part 160
and subparts A and C of 45 CFR part 164.
Individual. Has the meaning assigned to such term at 45 CFR
171.202(a)(2).
Individual Access Services (IAS). The services provided to an
Individual by a QHIN, Participant, or Subparticipant that has a direct
contractual relationship with such Individual in which the QHIN,
Participant or Subparticipant, as applicable, agrees to satisfy that
Individual's ability to access, inspect, or obtain a copy of that
Individual's Required Information using TEFCA Exchange.
Individually Identifiable Information. Refers to information that
identifies an Individual or with respect to which there is a reasonable
basis to believe that the information could be used to identify an
Individual.
Node. A technical system that is controlled directly or indirectly
by a QHIN, Participant, or Subparticipant and that is listed in the RCE
Directory Service.
Non-U.S. Entity. Any entity that is not a U.S. Entity.
Non-U.S. Person. Any Individual who is not a U.S. Qualified Person.
Onboarding. The process a prospective QHIN must undergo to become a
QHIN and become operational in the production environment.
Organized Health Care Arrangement. Has the meaning assigned to such
term at 45 CFR 160.103.
Participant. A U.S. Entity that has entered into the Participant/
Subparticipant Terms of Participation in a legally binding contract
with a QHIN to use the QHIN's Designated Network Services to
participate in TEFCA Exchange in compliance with the Participant/
Subparticipant Terms of Participation.
[[Page 101812]]
Participant/Subparticipant Terms of Participation (ToP). The
requirements to which QHINs must contractually obligate their
Participants to agree; to which QHINs must contractually obligate their
Participants to contractually obligate their Subparticipants and
Subparticipants of the Subparticipants to agree, in order to
participate in TEFCA Exchange including the QHIN Technical Framework
(QTF), all applicable SOPs, and all other attachments, exhibits, and
artifacts incorporated therein by reference.
Qualified Health Information Network[supreg] or QHIN\TM\. A Health
Information Network that has been so Designated.
Query(s) (including its correlative uses/tenses ``Queried'' and
``Querying''). The act of asking for information through TEFCA
Exchange.
Recognized Coordinating Entity[supreg] (RCE[supreg]). The entity
selected by ASTP/ONC that enters into the Common Agreement with QHINs
in order to impose, at a minimum, the requirements of the Common
Agreement, including the SOPs and the QTF, on the QHINs and administer
such requirements on an ongoing basis. The RCE is a Party to the Common
Agreement.
Required Information. The Electronic Health Information, as defined
in 45 CFR 171.102, that is:
(1) Maintained in a Responding Node by any QHIN, Participant, or
Subparticipant prior to or during the term of the applicable Framework
Agreement; and
(2) Relevant for a required XP Code.
Responding Node. A Node through which the QHIN, Participant, or
Subparticipant Responds to a received transaction for TEFCA Exchange.
Response(s) (including its correlative uses/tenses ``Responds,''
``Responded'' and ``Responding''). The act of providing the information
that is the subject of a Query or otherwise transmitting a message in
response to a Query through TEFCA Exchange.
Subparticipant: a U.S. Entity that has entered into the
Participant/Subparticipant Terms of Participation in a legally binding
contract with a Participant or another Subparticipant to use the
Participant's or Subparticipant's Connectivity Services to participate
in TEFCA Exchange in compliance with the Participant/Subparticipant
Terms of Participation.
TEFCA Dispute Resolution Process. An informal, non-binding process
under TEFCA through which QHINs can meet, confer, and seek to amicably
resolve disputes.
TEFCA Exchange. The transaction of information between Nodes using
an XP Code.
TEFCA Information or TI. Any information that is transacted through
TEFCA Exchange except to the extent that such information is received
by a QHIN, Participant, or Subparticipant that is a Covered Entity,
Business Associate, or non-HIPAA entity that is exempt from compliance
with the Privacy section of the applicable Framework Agreement and is
incorporated into such recipient's system of record, at which point the
information is no longer TEFCA Information with respect to such
recipient and is governed by the HIPAA Rules and other Applicable Law.
TEFCA Security Incident. (1) An unauthorized acquisition, access,
Disclosure, or Use of unencrypted TEFCA Information using TEFCA
Exchange, except any of the following:
(i) Any unintentional acquisition, access, Use, or Disclosure of
TEFCA Information by a Workforce Member or person acting under the
authority of a QHIN, Participant, or Subparticipant, if such
acquisition, access, Use, or Disclosure:
(A) Was made in good faith;
(B) Was made by a person acting within their scope of authority;
(C) Was made to another Workforce Member or person acting under the
authority of any QHIN, Participant, or Subparticipant; and
(D) Does not result in further acquisition, access, Use, or
Disclosure in a manner not permitted under Applicable Law and the
Framework Agreements.
(ii) A Disclosure of TI where a QHIN, Participant, or
Subparticipant has a good faith belief that an unauthorized person to
whom the Disclosure was made would not reasonably have been able to
retain such information.
(iii) A Disclosure of TI that has been de-identified in accordance
with the standard at 45 CFR 164.514.
(2) Other security events that adversely affect a QHIN's,
Participant's, or Subparticipant's participation in TEFCA Exchange.
Threat Condition. (1) A breach of a material provision of a
Framework Agreement that has not been cured within fifteen (15)
calendar days of receiving notice of the material breach (or such other
period of time to which the Parties have agreed), which notice shall
include such specific information about the breach that the RCE has
available at the time of the notice; or
(2) A TEFCA Security Incident; or
(3) An event that the RCE, a QHIN, its Participant, or their
Subparticipant has reason to believe will disrupt normal TEFCA
Exchange, either due to actual compromise of, or the need to mitigate
demonstrated vulnerabilities in systems or data, of the QHIN,
Participant, or Subparticipant, as applicable, or could be replicated
in the systems, networks, applications, or data of another QHIN,
Participant, or Subparticipant; or
(4) Any event that could pose a risk to the interests of national
security as directed by an agency of the United States government.
Trusted Exchange Framework. The most recent version of the
framework referenced in section 3001(c)(9) of the Public Service Health
Act published in the Federal Register.
U.S. Entity/Entities. Any corporation, limited liability company,
partnership, or other legal entity that meets all of the following
requirements:
(1) The entity is organized under the laws of a state or
commonwealth of the United States or the Federal law of the United
States and is subject to the jurisdiction of the United States and the
state or commonwealth under which it was formed;
(2) The entity's principal place of business, as determined under
Federal common law, is in the United States; and
(3) None of the entity's directors, officers, or executives, and
none of the owners with a five percent (5%) or greater interest in the
entity, are listed on the Specially Designated Nationals and Blocked
Persons List published by the United States Department of the
Treasury's Office of Foreign Asset Control or on the United States
Department of Health and Human Services, Office of Inspector General's
List of Excluded Individuals/Entities.
U.S. Qualified Person. Those individuals who are U.S. nationals and
citizens at birth as defined in 8 U.S.C. 1401, U.S. nationals but not
citizens of the United States at birth as defined in 8 U.S.C. 1408,
lawful permanent residents of the United States as defined in
Immigration and Nationality Act, and non-immigrant aliens who are hired
by a U.S. Entity as an employee in a specialty occupation pursuant to
an H-1B Visa.
Use(s) (including correlative uses/tenses, such as ``Uses,''
``Used,'' and ``Using''). With respect to TI, means the sharing,
employment, application, utilization, examination, or analysis of such
information within an entity that maintains such information.
Sec. 172.103 Responsibilities ASTP/ONC may delegate to the RCE.
(a) ASTP/ONC may delegate to the RCE the TEFCA implementation
[[Page 101813]]
responsibilities specified in the following sections:
(1) Any section(s) of subpart C of this part;
(2) Any section(s) of subpart D of this part;
(3) Section 172.501; and
(4) Section 172.503.
(b) Notwithstanding any delegation, any authority exercised by the
RCE under this section is subject to review under subpart F of this
part and to any requirement in this part that the RCE receive ASTP/
ONC's prior authorization before taking a specific action.
Subpart B--Qualifications for Designation
Sec. 172.200 Applicability.
This subpart establishes Designation qualifications.
(a) Applicant QHIN. An Applicant QHIN must meet all requirements in
Sec. 172.201 to be Designated. An Applicant QHIN that proposes to
offer Individual Access Services must also meet all requirements in
Sec. 172.202 to be Designated.
(b) QHIN. A QHIN must continue to meet all requirements in Sec.
172.201 to maintain its Designation. A QHIN that offers Individual
Access Services must also continue to meet all requirements in Sec.
172.202 to maintain its Designation.
(c) Performance of TEFCA Exchange. The Designation qualifications
in Sec. Sec. 172.201 and 172.202 describe certain requirements for
Designation.
Sec. 172.201 QHIN Designation requirements.
(a) Ownership requirements. An entity must:
(1) Be a U.S. Entity;
(2) Not be under Foreign Control.
(b) Exchange requirements. An entity must, beginning at the time of
application, either directly or through the experience of its parent
entity:
(1) Be capable of exchanging information among more than two
unaffiliated organizations;
(2) Be capable of exchanging all Required Information;
(3) Be exchanging information for at least one Exchange Purpose
authorized under TEFCA;
(4) Be capable of receiving and responding to transactions from
other QHINs for all Exchange Purposes authorized under TEFCA; and
(5) Be capable of initiating transactions for the Exchange Purposes
authorized under TEFCA that such entity will permit its Participants
and Subparticipants to use through TEFCA Exchange.
(c) Designated Network Services requirements. An entity must:
(1) Maintain the organizational infrastructure and legal authority
to operate and govern its Designated Network;
(2) Maintain adequate written policies and procedures to support
meaningful TEFCA Exchange and fulfill all responsibilities of a QHIN in
this part;
(3) Maintain a Designated Network that can support a transaction
volume that keeps pace with the demands of network users;
(4) Maintain the capacity to support secure technical connectivity
and data exchange with other QHINs;
(5) Maintain an enforceable dispute resolution policy governing
Participants in the Designated Network that permits Participants to
reasonably, timely, and fairly adjudicate disputes that arise between
each other, the QHIN, or other QHINs;
(6) Maintain an enforceable change management policy consistent
with the responsibilities of a QHIN;
(7) Maintain a representative and participatory group or groups
with the authority to approve processes for governing the Designated
Network;
(8) Maintain privacy and security policies that permit the entity
to support TEFCA Exchange;
(9) Maintain data breach response and management policies that
support meaningful TEFCA Exchange; and
(10) Maintain adequate financial and personnel resources to support
all its responsibilities as a QHIN, including sufficient financial
reserves or insurance-based cybersecurity coverage, or a combination of
both.
Sec. 172.202 QHINs that offer Individual Access Services.
The following requirements apply to QHINs that offer Individual
Access Services:
(a) A QHIN must obtain express consent from any individual before
providing Individual Access Services.
(b) A QHIN must make publicly available a privacy and security
notice that meets minimum TEFCA standards.
(c) A QHIN, that is the IAS provider for an Individual, must delete
the individual's Individually Identifiable Information maintained by
the QHIN upon request by the individual except as prohibited by
Applicable Law or where such information is contained in audit logs.
(d) A QHIN must permit any Individual to export in a computable
format all of the Individual's Individually Identifiable Information
maintained by the QHIN as an Individual Access Services provider.
(e) All Individually Identifiable Information the QHIN maintains
must satisfy the following criteria:
(1) All Individually Identifiable Information must be encrypted.
(2) Without unreasonable delay and in no case later than sixty (60)
calendar days following discovery of the unauthorized acquisition,
access, Disclosure, or Use of Individually Identifiable Information,
the QHIN must notify in plain language each Individual whose
Individually Identifiable Information has been or is reasonably
believed to have been affected by unauthorized acquisition, access,
Disclosure, or Use involving the QHIN.
(3) A QHIN must have an agreement with a qualified, independent
third-party credential service provider and must verify, through the
credential service provider, the identities of Individuals seeking
Individual Access Services prior to the Individuals' first use of such
services and upon expiration of their credentials.
Subpart C--QHIN Onboarding and Designation Processes
Sec. 172.300 Applicability.
This subpart establishes, as to QHINs, the application, review,
Onboarding, withdrawal, and redetermination processes for Designation.
Sec. 172.301 Submission of QHIN application.
An entity seeking to be Designated as a QHIN must submit all of the
following information in a manner specified by ASTP/ONC:
(a) Completed QHIN application, with supporting documentation, in a
form specified by ASTP/ONC; and
(b) A signed copy of the Common Agreement.
Sec. 172.302 Review of QHIN application.
(a) ASTP/ONC (or an RCE) will review a QHIN application to
determine if the Applicant QHIN has completed all parts of the
application and provided the necessary supporting documentation. If the
QHIN application is not complete, the applicant will be notified in
writing of the missing information within thirty (30) calendar days of
receipt of the application. This timeframe may be extended by providing
written notice to the Applicant QHIN.
(b) Once the QHIN application is complete, ASTP/ONC (or an RCE)
will review the application to determine whether the Applicant QHIN
satisfies the requirements for Designation set forth in Sec. 172.201
and, if the Applicant QHIN proposes to provide IAS, the requirements
set forth in Sec. 172.202. ASTP/ONC (or an RCE) will complete its
review within sixty (60) calendar days of the Applicant QHIN being
[[Page 101814]]
provided with written notice that its application is complete. This
timeframe may be extended by providing written notice to the Applicant
QHIN.
(c) Additional information may be requested from the Applicant QHIN
while ASTP/ONC (or an RCE) is reviewing the application. The timeframe
for responding to the request and the manner to submit additional
information will be provided to the applicant and may be extended on
written notice to the Applicant QHIN.
(d) Failure to respond to a request within the proposed timeframe
or in the manner specified is a basis for a QHIN Application to be
deemed withdrawn, as set forth in Sec. 172.305(c). In such situations,
the Applicant QHIN will be provided with written notice that the
application has been deemed withdrawn.
(e) If, following submission of the application, any information
submitted by the Applicant QHIN becomes untrue or materially changes,
the Applicant QHIN must notify ASTP/ONC (or an RCE) in the manner
specified by ASTP/ONC (or an RCE) of such changes in writing within
five (5) business days of the submitted material becoming untrue or
materially changing.
Sec. 172.303 QHIN approval and Onboarding.
(a) An Applicant QHIN has the burden of demonstrating its
compliance with all qualifications for Designation in Sec. 172.201
and, if the Applicant QHIN proposes to provide IAS, the qualifications
in Sec. 172.202.
(b) If ASTP/ONC (or, with ASTP/ONC's prior authorization, an RCE)
determines that an Applicant QHIN meets the requirements for
Designation set forth in Sec. 172.201, and if the Applicant QHIN
proposes to provide IAS, the qualifications set forth in Sec. 172.202,
then ASTP/ONC (or, with ASTP/ONC's prior authorization, an RCE) will
notify the applicant in writing that its application has been approved,
and the Applicant QHIN may proceed with Onboarding.
(c) An approved Applicant QHIN must submit a signed version of the
Common Agreement within a timeframe set by ASTP/ONC (or an RCE).
(d) An approved Applicant QHIN must complete the Onboarding
process, including any tests required to ensure the Applicant QHIN's
network can connect to those of other QHINs and other Applicant QHINs,
within twelve (12) months of approval of its QHIN application, unless
that timeframe is extended in ASTP/ONC's (or an RCE's) sole discretion
by up to twelve (12) months.
Sec. 172.304 QHIN Designation.
(a) If all requirements of the Onboarding process specified in
Sec. 172.303 have been satisfied:
(1) The Common Agreement will be countersigned; and
(2) The Applicant QHIN will be provided with a written
determination indicating that the applicant has been Designated as a
QHIN, along with a copy of the countersigned Common Agreement.
(b) Within thirty (30) calendar days of receiving its Designation,
each QHIN must demonstrate in a manner specified by ASTP/ONC (or, with
ASTP/ONC's prior authorization, an RCE) that it has completed a
successful transaction with all other in-production QHINs according to
standards and procedures for TEFCA Exchange.
(c) If a QHIN is unable to complete the requirement in paragraph
(b) of this section within the thirty (30)-day period provided, the
QHIN must provide ASTP/ONC (or an RCE) with a written explanation of
why the QHIN has been unable to complete a successful transaction with
all other in-production QHINs within the allotted time and include a
detailed plan and timeline for completion of a successful transaction
with all other in-production QHINs. ASTP/ONC (or, with ASTP/ONC's prior
authorization, an RCE) will review and either approve or reject the
QHIN's plan based on the reasonableness of the explanation and the
specific facts and circumstances, within five (5) business days of
receipt. If the QHIN fails to provide its plan or the plan is rejected,
ASTP/ONC (or, with ASTP/ONC's prior authorization, an RCE) will rescind
its approval of the application, rescind the QHIN Designation, and deny
the application. Within thirty (30) calendar days of end of the term of
the plan, each QHIN must demonstrate in a manner specified by ASTP/ONC
(or, with ASTP/ONC's prior authorization, an RCE) that it has completed
a successful transaction with all other in-production QHINs according
to standards and procedures for TEFCA Exchange.
(d) A QHIN Designation will become final sixty (60) days after a
Designated QHIN has submitted its documentation that it has completed a
successful transaction with all other in-production QHINs.
Sec. 172.305 Withdrawal of QHIN application.
(a) An Applicant QHIN may voluntarily withdraw its QHIN application
by providing written notice in a manner specified by ASTP/ONC (or an
RCE).
(b) An Applicant QHIN may withdraw its QHIN application at any
point prior to Designation.
(c) Upon written notice to the Applicant QHIN, a QHIN application
may be deemed withdrawn by ASTP/ONC (or, with ASTP/ONC's prior
authorization, an RCE) as a result of the Applicant QHIN's failure to
respond to requests for information from ASTP/ONC (or an RCE).
Sec. 172.306 Denial of QHIN application.
If an Applicant QHIN's application is denied, the Applicant QHIN
will be provided with written notice that includes the basis for the
denial.
Sec. 172.307 Re-application.
(a) Subject to paragraphs (b) through (d) of this section,
applications may be resubmitted by Applicant QHINs by complying with
the provisions of Sec. 172.301 in the event that an application is
denied or withdrawn.
(b) The Applicant QHIN may reapply at any time after it has
voluntarily withdrawn its application as specified in Sec. 172.305(a).
(c) If ASTP/ONC (or an RCE) deems a QHIN application to be
withdrawn as a result of the Applicant QHIN's failure to respond to
requests for information, then the Applicant QHIN may reapply by
submitting a new QHIN application no sooner than six (6) months after
the date on which its previous application was submitted. The Applicant
QHIN must respond to the prior request for information and must include
an explanation as to why no response was previously provided within the
required timeframe.
(d) If ASTP/ONC (or an RCE) denies a QHIN application, the
Applicant QHIN may reapply by submitting a new application consistent
with the requirements in Sec. 172.301 no sooner than six (6) months
after the date shown on the written notice of denial. The application
must specifically address the deficiencies that constituted the basis
for denying the Applicant QHIN's previous application.
Subpart D--Suspension
Sec. 172.400 Applicability.
This subpart describes suspension responsibilities, notice
requirements for suspension, and the effect of suspension.
Sec. 172.401 QHIN suspensions.
(a) ASTP/ONC (or, with ASTP/ONC's prior authorization, an RCE) may
suspend a QHIN after determining that the QHIN is responsible for a
Threat Condition.
[[Page 101815]]
(b) ASTP/ONC (or, with ASTP/ONC's prior authorization, an RCE) may
direct the QHIN to suspend that Participant's or Subparticipant's
authority to engage in TEFCA Exchange on determining that one of a
QHIN's Participants or Subparticipants has done something or failed to
do something that resulted in a Threat Condition.
(c) ASTP/ONC (or an RCE) will make a reasonable effort to notify a
QHIN in writing in advance of an intent to suspend the QHIN or to
provide direction to the QHIN to suspend one of the QHIN's Participants
or Subparticipants, and to give the QHIN an opportunity to respond.
Such notice will identify the Threat Condition giving rise to such
suspension.
(d) ASTP/ONC (or, with ASTP/ONC's prior authorization, an RCE)
shall lift a suspension of the QHIN, or provide direction to the QHIN
to lift the suspension of one of the QHIN's Participants or
Subparticipants, once the Threat Condition is resolved.
Sec. 172.402 Selective suspension of exchange between QHINs.
(a) A QHIN may, in good faith and to the extent permitted by
Applicable Law, suspend TEFCA Exchange with another QHIN because of
reasonable concerns related to the privacy and security of information
that is exchanged.
(b) If a QHIN decides to suspend TEFCA Exchange with another QHIN,
it is required to promptly notify, in writing, ASTP/ONC (or an RCE) and
the QHIN with which it is suspending exchange of its decision and the
reason(s) for making the decision.
(c) If a QHIN suspends TEFCA Exchange with another QHIN under
paragraph (a) of this section, it must, within thirty (30) calendar
days, initiate the TEFCA Dispute Resolution Process in order to resolve
the issues that led to the decision to suspend, or the QHIN may end its
suspension and resume TEFCA Exchange with the other QHIN within thirty
(30) calendar days of suspending TEFCA Exchange with the QHIN.
(d) Provided that a QHIN suspends TEFCA Exchange with another QHIN
in accordance with this section and in accordance with Applicable Law,
such suspension will not be deemed a violation of the Common Agreement.
Subpart E--Termination
Sec. 172.500 Applicability.
This subpart establishes QHIN termination responsibilities, notice
requirements for termination, and the effect of termination.
Sec. 172.501 QHIN self-termination.
A QHIN may terminate its own Designation at any time without cause
by providing ninety (90) calendar days prior written notice.
Sec. 172.502 QHIN termination.
A QHIN's Designation will be terminated with immediate effect by
ASTP/ONC (or, with ASTP/ONC's prior authorization, an RCE) giving
written notice of termination to the QHIN if the QHIN:
(a) Fails to comply with any of the regulations of this part and
fails to remedy such material breach within thirty (30) calendar days
after receiving written notice of such failure; provided, however, that
if a QHIN is diligently working to remedy its material breach at the
end of this thirty- (30-) day period, then ASTP/ONC (or an RCE) must
provide the QHIN with up to another thirty (30) calendar days to remedy
its material breach; or
(b) A QHIN breaches a material provision of the Common Agreement
where such breach is not capable of remedy.
Sec. 172.503 Termination by mutual agreement.
A QHIN's Designation may be terminated at any time and for any
reason by mutual, written agreement between the QHIN and ASTP/ONC (or
an RCE).
Subpart F--Review of RCE or ASTP/ONC Decisions
Sec. 172.600 Applicability.
This subpart establishes processes for review of RCE or ASTP/ONC
actions, including QHIN appeal rights and the process for filing an
appeal.
Sec. 172.601 ASTP/ONC review.
(a) ASTP/ONC may, in its sole discretion, review all or any part of
any RCE determination, policy, or action. If ASTP/ONC reviews an RCE
determination that required ASTP/ONC's prior authorization under this
part, no ASTP/ONC officer, employee, or agent who was engaged with
helping to evaluate or decide the prior authorization, or a prior
authorization involving the same party(s) or underlying facts, may
participate in deciding or advising ASTP/ONC on its review of that
determination.
(b) ASTP/ONC may, in its sole discretion and on notice to affected
QHINs or Applicant QHINs, stay any RCE determination, policy, or other
action pending ASTP/ONC review. If ASTP/ONC stays an RCE determination
that required ASTP/ONC's prior authorization under this part, no ASTP/
ONC officer, employee, or agent who was engaged with helping to
evaluate or decide the prior authorization, or a prior authorization
involving the same party(s) or underlying facts, may participate in
deciding or advising ASTP/ONC on whether it should stay that
determination.
(c) ASTP/ONC may, in its sole discretion and on written notice,
request that a QHIN, Applicant QHIN, or the RCE provide ASTP/ONC
additional information regarding any RCE determination, policy, or
other action.
(d) On completion of its review, ASTP/ONC may affirm, modify, or
reverse the determination, policy, or other action under review. ASTP/
ONC will provide notice to affected QHINs or Applicant QHINs that
includes the basis for ASTP/ONC's decision.
(e) ASTP/ONC will provide written notice under this section to
affected QHINs or Applicant QHINs in the same manner as the original
RCE determination, policy, or other action under review.
(f) ASTP/ONC will issue a decision under this section within a
timeframe agreed to by the affected Applicant QHIN or QHIN, as
applicable, the RCE, and ASTP/ONC. ASTP/ONC may, at its sole
discretion, extend the timeframe for a decision as circumstances
necessitate.
Sec. 172.602 Basis for appeal by QHIN or Applicant QHIN.
(a) An Applicant QHIN or QHIN may appeal the following decisions to
ASTP/ONC or a hearing officer, as appropriate:
(1) Applicant QHIN. An Applicant QHIN may appeal a denial of its
QHIN application.
(2) QHIN. A QHIN may appeal:
(i) A decision to suspend the QHIN or to instruct the QHIN to
suspend its Participant or Subparticipant.
(ii) A decision to terminate the QHIN's Common Agreement.
(b) [Reserved]
Sec. 172.603 Method and timing for filing an appeal.
(a) To initiate an appeal, an authorized representative of the
Applicant QHIN or QHIN must submit electronically, in writing to ASTP/
ONC, a notice of appeal that includes the date of the notice of appeal,
the date of the decision being appealed, the Applicant QHIN or QHIN
that is appealing, and the decision being appealed within fifteen (15)
calendar days of the Applicant QHIN's or QHIN's receipt of the notice
of:
(1) Denial of a QHIN application;
(2) Suspension or instruction to suspend its Participant or
Subparticipant; or
[[Page 101816]]
(3) Termination. With regard to an appeal of a termination, the 15-
calendar day timeframe may be extended by ASTP/ONC up to another
fifteen (15) calendar days if the QHIN has been granted an extension
for completing its remedy under Sec. 172.502(a).
(b) An authorized representative of an Applicant QHIN or QHIN must
submit electronically to ASTP/ONC, within thirty (30) calendar days of
filing the intent to appeal, the following:
(1) A statement of the basis for appeal, including a description of
the facts supporting the appeal with citations to documentation
submitted by the QHIN or Applicant QHIN; and
(2) Any documentation the QHIN would like considered during the
appeal.
(c) The Applicant QHIN or QHIN filing the appeal may not submit on
appeal any evidence that it did not submit prior to the appeal except
evidence permitted by the hearing officer under Sec. 172.606.
Sec. 172.604 Effect of appeal on suspension and termination.
An appeal does not stay the suspension or termination, unless
otherwise ordered by ASTP/ONC or the hearing officer assigned under
Sec. 172.605(b).
Sec. 172.605 Assignment of a hearing officer.
(a) On receipt of an appeal under Sec. 172.603, ASTP/ONC may
exercise its authority under Sec. 172.601 to review an RCE
determination being appealed. If ASTP/ONC exercises its authority under
Sec. 172.601 to review an RCE determination that required ONC's prior
authorization under this part, no ASTP/ONC officer, employee, or agent
who was engaged with helping to evaluate or decide the prior
authorization, or a prior authorization involving the same party(s) or
underlying facts, may participate in deciding or advising ASTP/ONC on
its review of that determination. An appealing QHIN or Applicant QHIN
that is not satisfied with ASTP/ONC's subsequent determination may
appeal that determination to a hearing officer by filing a new notice
of appeal and other appeal documents that comply with Sec. 172.603.
(b) If ASTP/ONC declines review under paragraph (a) of this
section, or if ASTP/ONC made the determination under review, ASTP/ONC
will arrange for assignment of the case to a hearing officer to
adjudicate the appeal.
(c) The hearing officer must be an officer appointed by the
Secretary of Health and Human Services.
(d) The hearing officer may not be responsible to, or subject to
the supervision or direction of, personnel engaged in the performance
of investigative or prosecutorial functions for ASTP/ONC, nor may any
officer, employee, or agent of ASTP/ONC engaged in investigative or
prosecutorial functions in connection with any adjudication, in that
adjudication or one that is factually related, participate or advise in
the decision of the hearing officer, except as a counsel to ASTP/ONC or
as a witness.
Sec. 172.606 Adjudication.
(a) The hearing officer will decide issues of law and fact de novo
and will apply a preponderance of the evidence standard when deciding
appeals.
(b) In making a determination, the hearing officer may consider:
(1) The written record, which includes:
(i) The RCE's or ASTP/ONC's determination and supporting
information; and
(ii) Appeal materials submitted by the Applicant QHIN or QHIN under
Sec. 172.603.
(2) Any information from a hearing conducted in-person, via
telephone, or otherwise. The hearing officer has sole discretion to
conduct a hearing:
(i) To require either party to clarify the written record under
paragraph (b)(1) of this section; or
(ii) If the hearing officer otherwise determines a hearing is
necessary.
(c) The hearing officer will neither receive witness testimony nor
accept any new information beyond what was provided in accordance with
paragraph (b) of this section, except for good cause shown by the party
seeking to submit new information.
Sec. 172.607 Determination by the hearing officer.
(a) The hearing officer will issue a written determination within a
timeframe agreed to by the affected Applicant QHIN or QHIN, as
applicable, and ASTP/ONC and approved by the hearing officer. The
hearing officer may, at their sole discretion, extend the timeframe for
a written determination as circumstances necessitate.
(b) The hearing officer's determination on appeal is the final
decision of HHS unless within ten (10) business days, the Secretary, in
the Secretary's sole discretion, chooses to review the determination.
ASTP/ONC will notify the appealing party if the Secretary chooses to
review the determination and will provide notice of the Secretary's
final determination.
Subpart G--QHIN Attestation for the Adoption of the Trusted
Exchange Framework and Common Agreement
Sec. 172.700 Applicability.
This subpart applies to QHINs.
Sec. 172.701 Attestation submission and acceptance.
(a) Applicability. This subpart establishes:
(1) The attestation submission requirements for QHINs.
(2) The review and acceptance processes that ASTP/ONC will follow
for TEFCA attestations.
(b) Submission of QHIN attestation. (1) In order to be listed in
the QHIN Attestation Directory described in Sec. 172.702, a QHIN must
submit all of the following information to ASTP/ONC:
(i) Attestation affirming its adoption of the Common Agreement and
Trusted Exchange Framework.
(ii) General identifying information, including:
(A) Name, address, city, state, zip code, and a hyperlink to its
website.
(B) Designation of an authorized representative, including the
representative's name, title, phone number, and email address.
(iii) Documentation confirming its Designation as a QHIN.
(2) A QHIN must provide ASTP/ONC with written notice of any changes
to its identifying information provided in accordance with this
paragraph (b) within thirty (30) business days of the change(s) to its
identifying information.
(c) Submission method. A QHIN must electronically submit its
attestation and documentation either via an email address identified by
ASTP/ONC or via a submission on the ASTP/ONC website, if available.
(d) Review and acceptance. (1) Within thirty (30) business days,
ASTP/ONC will either accept or reject an attestation submission.
(2) ASTP/ONC will accept an attestation if it determines that the
QHIN has satisfied the requirements of paragraphs (b) and (c) of this
section. ASTP/ONC will provide written notice to the applicable QHIN's
authorized representative that the attestation has been accepted.
(3) ASTP/ONC will reject an attestation if it determines that the
requirements of paragraph (b) or (c) of this section, or both, have not
been satisfied.
(4) ASTP/ONC will provide written notice to the QHIN's authorized
representative of the determination along with the basis for the
determination.
(5) An ASTP/ONC determination under this section is final agency
action
[[Page 101817]]
and not subject to further administrative review, except the Secretary
may choose to review the determination as provided in Sec. 172.607(b).
However, a QHIN may, at any time, resubmit an attestation in accordance
with paragraphs (b) and (c) of this section.
Sec. 172.702 QHIN Attestation Directory.
(a) Applicability. This subpart establishes processes for
publishing a directory on the ASTP/ONC website of QHINs that
voluntarily elect to adopt the Common Agreement and Trusted Exchange
Framework and attest to such adoption.
(b) Publication. (1) Within fifteen (15) calendar days of notifying
a QHIN that its QHIN submission has been accepted, ASTP/ONC will
publish, at a minimum, the QHIN's name in the QHIN Attestation
Directory on the ASTP/ONC website.
(2) ASTP/ONC will identify within the QHIN Attestation Directory
those QHINs that are suspended under the Common Agreement.
(c) Removal from the QHIN Attestation Directory. (1) A QHIN whose
Common Agreement has been terminated no longer qualifies to be included
in the QHIN Attestation Directory as it is no longer considered a QHIN
and will be removed from the QHIN Attestation Directory.
(2) Upon termination of a QHIN's Common Agreement, ASTP/ONC (or an
RCE) will send a written a statement of intent to remove the QHIN from
the QHIN Attestation Directory to the authorized representative of the
QHIN.
(3) Any written statement given under paragraph (c)(2) of this
section shall consist of the following, as appropriate:
(i) The name of the terminated QHIN and the name and contact
information of the authorized representative of the QHIN.
(ii) A short statement setting forth findings of fact with respect
to any violation of the Common Agreement or other basis for the QHIN's
termination under the Common Agreement and justifying the termination
on the basis of those findings of facts.
(iii) Other materials as ASTP/ONC (or the RCE) may deem relevant.
(d) Duration. A QHIN that is removed from the QHIN Attestation
Directory will remain removed until a new attestation is accepted by
ASTP/ONC in accordance with the processes specified in this subpart.
(e) Final agency action. An ASTP/ONC determination under this
section is final agency action and not subject to further
administrative review, except the Secretary may choose to review the
determination as provided in Sec. 172.607(b).
Xavier Becerra,
Secretary, Department of Health and Human Services.
[FR Doc. 2024-29163 Filed 12-11-24; 8:45 am]
BILLING CODE 4150-45-P
