Rule2024-29163
Health Data, Technology, and Interoperability: Trusted Exchange Framework and Common Agreement (TEFCA)
Primary source
Metadata and text below are from the Federal Register, a public-domain U.S. government work. Always verify the official published version before relying on it for any legal matter.
Published
December 16, 2024
Effective
January 15, 2025
Issuing agencies
Health and Human Services Department
Abstract
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.
Full Text
<html>
<head>
<title>Federal Register, Volume 89 Issue 241 (Monday, December 16, 2024)</title>
</head>
<body><pre>
[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 [<a href="http://www.gpo.gov">www.gpo.gov</a>]
[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, <a href="http://HealthIT.gov">HealthIT.gov</a>, offers a variety of resources on the
topic of Information Blocking, including fact sheets, recorded
webinars, and frequently asked questions. To learn more, please
visit: <a href="https://www.healthit.gov/topic/information-blocking/">https://www.healthit.gov/topic/information-blocking/</a>.
---------------------------------------------------------------------------
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\ <a href="https://www.hhs.gov/about/news/2024/07/10/hhs-proposes-hti-2-rule-improve-patient-engagement-information-sharing-public-health-interoperability.html">https://www.hhs.gov/about/news/2024/07/10/hhs-proposes-hti-2-rule-improve-patient-engagement-information-sharing-public-health-interoperability.html</a>.
---------------------------------------------------------------------------
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:
<bullet> The definition of ``gap certification'' (Sec. 170.502).
<bullet> Authorization scope for ONC-ATL status (Sec. 170.511).
<bullet> Requirements for ONC-ACBs to refund fees to developers
seeking certification under certain circumstances (Sec.
170.523(j)(3)).
<bullet> 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
<a href="https://rce.sequoiaproject.org/wp-content/uploads/2024/08/SOP-Exchange-Purposes_CA-v3_508.pdf">https://rce.sequoiaproject.org/wp-content/uploads/2024/08/SOP-Exchange-Purposes_CA-v3_508.pdf</a>.
---------------------------------------------------------------------------
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, <a href="https://rce.sequoiaproject.org/wp-content/uploads/2024/08/QHIN-Security-for-the-Protection-of-TI-21.pdf">https://rce.sequoiaproject.org/wp-content/uploads/2024/08/QHIN-Security-for-the-Protection-of-TI-21.pdf</a>.
---------------------------------------------------------------------------
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 <a href="https://inquiry.healthit.gov/support/plugins/servlet/desk/portal/2">https://inquiry.healthit.gov/support/plugins/servlet/desk/portal/2</a>. Patients may also report issues to the
RCE at <a href="https://rce.sequoiaproject.org/contact/">https://rce.sequoiaproject.org/contact/</a>. 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 <a href="https://inquiry.healthit.gov/support/plugins/servlet/desk/portal/2/create/61">https://inquiry.healthit.gov/support/plugins/servlet/desk/portal/2/create/61</a>, 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 <a href="https://inquiry.healthit.gov/support/plugins/servlet/desk/portal/2/create/61">https://inquiry.healthit.gov/support/plugins/servlet/desk/portal/2/create/61</a>,
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\ <a href="https://www.healthit.gov/topic/interoperability/policy/trusted-exchange-framework-and-common-agreement-tefca">https://www.healthit.gov/topic/interoperability/policy/trusted-exchange-framework-and-common-agreement-tefca</a>.
\10\ <a href="https://rce.sequoiaproject.org/tefca/">https://rce.sequoiaproject.org/tefca/</a>.
---------------------------------------------------------------------------
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:
<bullet> 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.
<bullet> 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).
<bullet> Employing a Chief Information Security Officer with
executive-level responsibility.
<bullet> 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.
<bullet> 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.
<bullet> 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, <a href="https://www.healthit.gov/sites/default/files/facas/TEFCA%20NOFO_FINAL_508.pdf">https://www.healthit.gov/sites/default/files/facas/TEFCA%20NOFO_FINAL_508.pdf</a>.
\16\ See <a href="http://USASPENDING.gov">USASPENDING.gov</a>, <a href="https://www.usaspending.gov/award/CONT_AWD_75P00123C00019_7570_-NONE-_-NONE-">https://www.usaspending.gov/award/CONT_AWD_75P00123C00019_7570_-NONE-_-NONE-</a>.
---------------------------------------------------------------------------
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 <a href="https://inquiry.healthit.gov/support/plugins/servlet/desk/portal/2/create/61">https://inquiry.healthit.gov/support/plugins/servlet/desk/portal/2/create/61</a>, 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 <a href="https://inquiry.healthit.gov/support/plugins/servlet/desk/portal/2/create/61">https://inquiry.healthit.gov/support/plugins/servlet/desk/portal/2/create/61</a>, 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, <a href="https://rce.sequoiaproject.org/wp-content/uploads/2024/07/SOP-Treatment-XP-Implementation_508.pdf">https://rce.sequoiaproject.org/wp-content/uploads/2024/07/SOP-Treatment-XP-Implementation_508.pdf</a>.
---------------------------------------------------------------------------
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 li
[…truncated; see source link]Indexed from Federal Register on December 16, 2024.
This is legal information, not legal advice. Laws vary by jurisdiction and change frequently. Always verify current law with official sources and consult a licensed attorney in your jurisdiction for advice on your specific situation.