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

Federal RegisterDec 16, 2024

Ask Donna

What actually matters in this document.

Text

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

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

Manner Exception

V. Trusted Exchange Framework and Common Agreement

A. Subpart A—General Provisions

B. Subpart B—Qualifications for Designation

C. Subpart C—QHIN

Onboarding and Designation Processes

D. Subpart D—Suspension

E. Subpart E—Termination

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

G. Subpart G—QHIN

Attestation for the Adoption of the Trusted Exchange Framework and Common Agreement

VI. Severability

VII. Collection of Information Requirements—Qualified Health Information Networks

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)

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.

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.

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

Reasonable and necessary activities that do not constitute information blocking, also known as information blocking exceptions, are identified in 45 CFR part 171, subparts B, C and D. ASTP/ONC's official website,

HealthIT.gov

, offers a variety of resources on the topic of Information Blocking, including fact sheets, recorded webinars, and frequently asked questions. To learn more, please visit:

https://www.healthit.gov/topic/information-blocking/.

B. Summary of Major Provisions

General Comments

We received approximately 270 comment submissions on the broad range of proposals included in the “Health Data, Technology, and Interoperability: Patient Engagement, Information Sharing, and Public Health Interoperability” proposed rule (HTI-2 Proposed Rule) (89 FR 63498). We thank all commenters for their thoughtful input. For the purposes of this final rule, we have reviewed and responded to comments on a narrowed set of proposals. Specifically, we summarize and respond to comments related to the Trusted Exchange Framework and Common Agreement (TEFCA) information blocking exception and part 172 proposals, and a limited set of the proposed ONC Health IT Certification Program (Program) administrative updates. Comments received in response to other proposals from the HTI-2 Proposed Rule are beyond the scope of this final rule, are still being reviewed and considered, and may be the subject of subsequent final rules related to such proposals in the future.

As discussed above, the name of the office changed from the Office of the National Coordinator for Health Information Technology (ONC) to now be dually titled as the Assistant Secretary for Technology Policy and Office of the National Coordinator for Health Information Technology (ASTP/ONC) per the

Federal Register

notice released on July 29, 2024.

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

July 10, 2024)

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.

Federal Register

: Statement of Organization, Functions, and Delegations of Authority; Office of The National Coordinator for Health Information Technology (89 FR 60903).

https://www.hhs.gov/about/news/2024/07/10/hhs-proposes-hti-2-rule-improve-patient-engagement-information-sharing-public-health-interoperability.html.

1. ONC Health IT Certification Program

a. Administrative Updates

In section III.A.1, we discuss the removal of the “Complete EHR” and “EHR Module” terms from certain sections within subpart E of 45 CFR part 170.

As discussed in section III.A.2, we have removed from 45 CFR part 170, § 170.550(m), “Time-limited certification and certification status for certain ONC Certification Criteria for Health IT,” and removed the certification criteria with time-limited certification and certification status, including § 170.315(a)(10) and (13), (b)(6), (e)(2), and (g)(8). Additionally, as discussed in section III.A.2, we have revised § 170.315(b)(7) and (8) to remove § 170.315(b)(7)(ii) and (b)(8)(i)(B), which were time-limited provisions (now expired) that permitted health IT to demonstrate security tagging of Consolidated-Clinical Document Architecture (C-CDA) documents at the document level. In section III.A.3, we discuss the final revision of § 170.550(h), the Privacy and Security Certification Framework requirements, that adds the certification criterion “decision support interventions” (§ 170.315(b)(11)) to the list of certification criteria in § 170.550(h)(3)(ii).

b. Correction—Privacy and Security Certification Framework

We have finalized a correction to the Privacy and Security Certification Framework in § 170.550(h). As discussed in section III.B, we have added § 170.550(h)(4) that existed prior to the “21st Century Cures Act: Interoperability, Information Blocking, and the ONC Health IT Certification Program” final rule (85 FR 25642, May 1, 2020) (ONC Cures Act Final Rule) being finalized but was erroneously deleted.

2. Information Blocking Enhancements

In this final rule, with consideration of public comments, we have finalized the TEFCA Manner Exception in subpart D of part 171 with no revisions. We have also codified definitions of certain terms relevant to the Trusted Exchange Framework and Common Agreement

(TEFCA

) in § 171.401.

3. Trusted Exchange Framework and Common Agreement

As discussed in this final rule, we have codified (in new 45 CFR part 172) provisions related to TEFCA to provide greater process transparency and to further implement section 3001(c)(9) of the PHSA, as added by the Cures Act. The finalized 45 CFR part 172 establishes the processes associated with the qualifications necessary for an entity to receive and maintain Designation (as defined in § 172.102) as a Qualified Health Information Network (QHIN) capable of trusted exchange under the Common Agreement. The final provisions codified in part 172 also establish the procedures governing Onboarding (as defined in § 172.102) of QHINs and Designation of QHINs, suspension, termination, and administrative appeals to ASTP/ONC, as described in § 172.100(c)(1) of this final rule. We believe establishing these provisions in regulation support reliability, privacy, security, and trust within TEFCA, which furthers our obligations to “support” TEFCA under sections 3001(c)(9)(A) and (B) of the PHSA and TEFCA's ultimate success. In addition, in subpart G of part 172, we have codified requirements related to QHIN attestation for the adoption of TEFCA. This subpart implements section 3001(c)(9)(D) of the PHSA. Section 3001(c)(9)(D)(i) requires the publication on ASTP/ONC's website of a list of the health information networks (HINs) that have adopted the Common Agreement and are capable of trusted exchange pursuant to the Common Agreement. Section 3001(c)(9)(D)(ii) requires HHS to establish, through notice and comment rulemaking, a process for HINs that voluntarily elect to adopt TEFCA to attest to such adoption.

C. Costs and Benefits

Executive Orders 12866 and 13563 direct agencies to assess all costs and benefits of available regulatory alternatives and, if regulation is necessary, to select regulatory approaches that maximize net benefits (including potential economic, environmental, public health and safety effects, distributive impacts, and equity). Executive Order 14094 (Modernizing Regulatory Review) amends section 3(f) of Executive Order 12866 (Regulatory Planning and Review). The amended section 3(f) of Executive Order 12866 defines a “significant regulatory action.” The Office of Management and Budget's (OMB) Office of Information and Regulatory Affairs (OIRA) has determined that this final rule is not a significant regulatory action under section 3(f) of Executive Order 12866. Accordingly, we have not prepared a detailed Regulatory Impact Analysis (RIA). We did, however, include some quantitative analysis of the costs and benefits of this final rule.

II. Background

A. Statutory Basis

The Health Information Technology for Economic and Clinical Health Act (HITECH Act), Title XIII of Division A and Title IV of Division B of the American Recovery and Reinvestment Act of 2009 (Pub. L. 111-5), was enacted on February 17, 2009. The HITECH Act amended the Public Health Service Act (PHSA) and created “Title XXX—Health Information Technology and Quality” (Title XXX) to improve healthcare quality, safety, and efficiency through the promotion of health IT and EHI exchange.

The 21st Century Cures Act (Pub. L. 114-255) (Cures Act) was enacted on December 13, 2016, to accelerate the discovery, development, and delivery of 21st century cures, and for other purposes. The Cures Act, through Title IV—Delivery, amended the HITECH Act by modifying or adding certain provisions to the PHSA relating to health IT.

ONC Health IT Certification Program Rules

Section 3001(c)(5) of the PHSA provides the National Coordinator with the authority to establish a certification program or programs for the voluntary certification of health IT. Section 3001(c)(5)(A) specifies that the National Coordinator, in consultation with the Director of the National Institute of Standards and Technology (NIST), shall keep or recognize a program or programs for the voluntary certification of health IT that is in compliance with applicable certification criteria adopted under section 3004 of the PHSA.

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

information blocking policies that support patient electronic access. Additionally, the final rule modified the 2015 Edition health IT certification criteria and Program in other ways to advance interoperability, enhance health IT certification, and reduce burden and costs, as well as improving patient and health care provider access to EHI and promoting competition. On November 4, 2020, the Secretary published an interim final rule with comment period titled “Information Blocking and the ONC Health IT Certification Program: Extension of Compliance Dates and Timeframes in Response to the COVID-19 Public Health Emergency” (85 FR 70064) (Cures Act Interim Final Rule). The interim final rule extended certain compliance dates and timeframes adopted in the ONC Cures Act Final Rule to offer the healthcare system additional flexibilities in furnishing services to combat the COVID-19 pandemic, including extending the applicability date for information blocking provisions to April 5, 2021.

On April 18, 2023, the Secretary published a proposed rule titled “Health Data, Technology, and Interoperability: Certification Program Updates, Algorithm Transparency, and Information Sharing” (88 FR 23746) (HTI-1 Proposed Rule). The HTI-1 Proposed Rule proposed to implement the Electronic Health Record (EHR) Reporting Program provision of the Cures Act by establishing new Conditions and Maintenance of Certification requirements for health IT developers under the Program. The HTI-1 Proposed Rule also proposed to make several updates to certification criteria and implementation specifications recognized by the Program, including revised certification criterion for: “clinical decision support” (CDS), “patient demographics and observations”, and “electronic case reporting.” The HTI-1 Proposed Rule also proposed to establish a new baseline version of the United States Core Data for Interoperability (USCDI). Additionally, the HTI-1 Proposed Rule proposed enhancements to support information sharing under the information blocking regulations.

On January 9, 2024, the Secretary issued the “Health Data, Technology, and Interoperability: Certification Program Updates, Algorithm Transparency, and Information Sharing” final rule (HTI-1 Final Rule), which implemented the EHR Reporting Program provision of the 21st Century Cures Act and established new Conditions and Maintenance of Certification requirements for health IT developers under the Program (89 FR 1192). The HTI-1 Final Rule also made several updates to certification criteria and standards recognized by the Program. The Program updates included revised certification criteria for “decision support interventions,” “patient demographics and observations,” and “electronic case reporting,” as well as adopted a new baseline version of the USCDI standard, USCDI Version 3. Additionally, the HTI-1 Final Rule provided enhancements to support information sharing under the information blocking regulations. Through these provisions, we sought to advance interoperability, improve algorithm transparency, and support the access, exchange, and use of EHI. The HTI-1 Final Rule also updated numerous technical standards in the Program in additional ways to advance interoperability, enhance health IT certification, and reduce burden and costs for health IT developers and users of health IT.

On August 5, 2024, the Secretary published a proposed rule titled “Health Data, Technology, and Interoperability: Patient Engagement, Information Sharing, and Public Health Interoperability” (89 FR 63498) (HTI-2 Proposed Rule). The HTI-2 Proposed Rule sought to advance interoperability, improve transparency, and support the access, exchange, and use of electronic health information through proposals for: standards adoption; adoption of certification criteria to advance public health data exchange; expanded uses of certified application programming interfaces, such as for electronic prior authorization, patient access, care management, and care coordination; and information sharing under the information blocking regulations. Additionally, the HTI-2 Proposed Rule proposed to establish a new baseline version of the USCDI standard and proposed to update the ONC Health IT Certification Program to enhance interoperability and optimize certification processes to reduce burden and costs. The HTI-2 Proposed Rule also proposed to implement certain provisions related to TEFCA, which would support the reliability, privacy, security, and trust within TEFCA. This final rule is the second “Health Data, Technology, and Interoperability” final rule that seeks to advance interoperability, improve transparency, and support the access, exchange, and use of electronic health information.

III. ONC Health IT Certification Program

A. Administrative Updates

1. Updates Pursuant to 2014 Edition Removal

We proposed to remove the “Complete EHR” and “EHR Module” terms from certain sections within subpart E of 45 CFR part 170 because by the time we would finalize any proposal in a final rule, the terms would no longer be relevant (89 FR 63614). As described below, due to the amount of time that has elapsed since the June 30, 2020, effective date of the ONC Cures Act Final Rule's removal of the 2014 Edition from subparts A, B, and C of part 170, we believe removing obsolete terms as the Program evolves over time maintains clarity of the regulatory text and Program provisions, particularly for regulated entities and interested parties.

a. Removal of “Complete EHR” References

Because the ability to maintain Complete EHR certification was only permitted with health IT certified to the 2014 Edition certification criteria, the “Complete EHR” concept was discontinued for the 2015 Edition (80 FR 62719). In order to finalize removal of the 2014 Edition, the ONC Cures Act Final Rule removed the 2014 Edition certification criteria in § 170.314 from the Program regulations in 45 CFR part 170, § 170.545, and references to “Complete EHR” from the regulation text (85 FR 25655 through 25656). In the HTI-1 Final Rule, we removed the “Complete EHR” language from all reference points in §§ 170.523 and 170.524 (89 FR 1209 through 1210).

However, as explained in the HTI-2 Proposed Rule (89 FR 63614), until now, we have retained references to “Complete EHRs” in certain provisions within subpart E of 45 CFR part 170:

• The definition of “gap certification” (§ 170.502).

• Authorization scope for ONC-ATL status (§ 170.511).

• Requirements for ONC-ACBs to refund fees to developers seeking certification under certain circumstances (§ 170.523(j)(3)).

• Applicability of a newer version of a minimum standard (§ 170.555(b)(2)).

The “Complete EHR” concept remained relevant for supporting continuity through these provisions at that time because the 2014 Edition was not removed from the CFR until the ONC Cures Act Final Rule (85 FR 25655). As explained in the HTI-2 Proposed Rule, the ONC Cures Act Final Rule became effective on June 30, 2020,

and records for the 2014 Edition were required to be retained (including Complete EHRs) until June 30, 2023, under 45 CFR 170.523(g)(1) (89 FR 63614).

However, beginning with the 2015 Edition, Complete EHR certifications could no longer be issued and December 31, 2023, has passed. Thus, we proposed to remove references to “Complete EHRs” from the provisions listed above as of the effective date of this final rule.

b. Removal of “EHR Modules” References

As explained in the 2015 Edition Final Rule (80 FR 62604), in order to better reflect the scope of ONC's authority under the PHSA (section 3000(5)) and to make the Program more open and accessible, we replaced the term “EHR Module” with “Health IT Module.”

As noted above, consistent with the three-year records retention requirement for ONC-ACBs (45 CFR 170.523(g)(1)), June 30, 2023, marked the end of a three-year minimum retention period (36 calendar months) since we finalized, in the ONC Cures Act Final Rule, the removal of the 2014 Edition from 45 CFR part 170, subparts A, B, and C (85 FR 25656). Similarly, December 31, 2023, marked the end of the third calendar year following the calendar year in which the ONC Cures Act Final Rule became effective. Because we passed both rules' three-year retention requirements for ONC-ACBs and the term “EHR Module” is no longer relevant, we proposed to remove from § 170.523(f) reference to “EHR Modules.” In the HTI-2 Proposed Rule (89 FR 63614 through 63615), we included the explanation for removing the term “EHR Modules” from § 170.523(f) in the preamble. However, we erroneously neglected to include the removal of “EHR Modules” in the regulatory text for § 170.523(f). Because we included our intent to remove all of the references to EHR Modules in the HTI-2 Proposed Rule and there were no comments on the removal of the term generally, we have included the revision to the regulatory text for § 170.523(f) in this final rule.

Comments.

We did not receive any comments in response to our proposals to remove the terms “Complete EHR” and “EHR Module.”

Response.

Because these terms are no longer relevant and retaining them may cause confusion for the public, we have adopted our proposals without revisions.

2. Removal of Time-Limited Criteria

In the ONC Cures Act Final Rule, we finalized § 170.550(m) “time-limited certification and certification status for certain 2015 Edition certification criteria,” which provided that for five specific certification criteria, an ONC-ACB may only issue a certification to a Health IT Module and permit continued certified status for a specified time period (85 FR 25952). The five criteria with time-limited certification and certification status are the “drug-formulary and preferred drug list checks” certification criterion (§ 170.315(a)(10)), “patient-specific education resources” (§ 170.315(a)(13)), “data export” certification criterion (§ 170.315 (b)(6)), “secure messaging” certification criterion (§ 170.315(e)(2)), and “application access—data category request” (§ 170.315(g)(8)). Because the specified time periods for certification to these criteria have elapsed, we proposed to remove all of the certification criteria referenced in § 170.550(m) in one action by removing and reserving § 170.550(m) in its entirety (89 FR 63615 and 63616). We also proposed to remove and reserve these aforementioned certification criteria from the specific CFR locations in which they are adopted. In the ONC Cures Act Final Rule, we also finalized revisions in § 170.315(b)(7)(ii) and (b)(8)(i)(B) to allow security tagging of Consolidated-Clinical Document Architecture (C-CDA) documents at the document level only for the period until 24 months after publication date of the final rule (85 FR 25667). Because that time period has elapsed, we proposed to revise § 170.315(b)(7) and (8) to remove § 170.315(b)(7)(ii) and (b)(8)(i)(B) (89 FR 63616).

Comments.

The majority of comments received on this proposal objected in particular to the removal of the “patient-specific education resources” certification criterion in § 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®)-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 § 170.315(a)(13). However, we believe commenters expressing specific concerns about maintaining the criterion may have misunderstood the proposal. The discussion of removing the “patient-specific education resources” certification criterion in § 170.315(a)(13) and the decision to end its applicability within the Program as of January 1, 2022, was finalized in the ONC Cures Act Final Rule. In the ONC Cures Act Final Rule, we finalized § 170.550(m), “Time-limited certification and certification status for certain ONC Certification Criteria for Health IT,” which provided that for five specific certification criteria, an ONC-ACB may only issue a certification to a Health IT Module and permit continued certified status for a specified time period (85 FR 25952). One of those criteria included the “patient-specific education resources” certification criterion in § 170.315(a)(13).

Specifically, in the ONC Cures Act Final Rule, we finalized requirements in § 170.550(m)(1) permitting ONC-ACBs to issue certificates for the “patient-specific education resources” certification criterion in § 170.315(a)(13) up until January 1, 2022 (85 FR 25661). We stated that we believed that health IT's capabilities to identify appropriate patient education materials was widespread among health IT developers and their customers, and noted innovation had occurred for these capabilities, including the use of automation and algorithms to provide appropriate education materials to patients in a timely manner (85 FR 25661). In addition, the “patient-specific education resources”

certification criterion in § 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 § 170.315(a)(13) and the decision to end its applicability within the Program as of January 1, 2022, was finalized in the ONC Cures Act Final Rule seems to have been misunderstood by those commenters, we believe those comments are not applicable to our proposal and out of scope for this rulemaking. We have finalized the proposal to remove and reserve § 170.315(a)(13).

We did not receive comments on the other proposals to remove time-limited certification criteria. Therefore, except as to the modified reference or references to `ASTP/ONC,' we have finalized as proposed and remove and reserve those criteria. We have also finalized the proposal to revise § 170.315(b)(7) and (8) to remove § 170.315(b)(7)(ii) and (b)(8)(i)(B), which were time-limited provisions (now expired) that permitted health IT to demonstrate security tagging of C-CDA documents at the document level.

3. Privacy and Security Framework Incorporation of DSI Criterion

In the ONC HTI-1 Final Rule, we established a revised certification criterion (“decision support interventions” (§ 170.315(b)(11))) to replace the “clinical decision support” certification criterion (§ 170.315(a)(9)) effective January 1, 2025 (89 FR 1196 through 1197). However, we neither proposed nor finalized corresponding privacy and security certification requirements for Health IT Modules certifying to the “decision support interventions” certification criterion. This omission was an oversight. In the HTI-2 Proposed Rule, we proposed to add the “decision support interventions” certification criterion (§ 170.315(b)(11)) to the list of certification criteria in § 170.550(h)(3)(ii) (89 FR 63616).

To provide developers of certified health IT time to comply with these proposed requirements, we specifically proposed to require, in § 170.550(h)(3)(ii), that Health IT Modules certified to the “decision support interventions” (§ 170.315(b)(11)) must also be certified to the specific privacy and security certification criteria on and after January 1, 2028. We stated that these specific privacy and security certification criteria are: “authentication, access control, and authorization” in § 170.315(d)(1); “auditable events and tamper-resistance” in § 170.315(d)(2); “audit report(s)” in § 170.315(d)(3); “automatic access time-out” in § 170.315(d)(5); “emergency access” in § 170.315(d)(6); “end-user device encryption” in § 170.315(d)(7); “encrypt authentication credentials” in § 170.315(d)(12); and “multi-factor authentication” in § 170.315(d)(13). In the HTI-2 Proposed Rule preamble (89 FR 63616), when listing the specific privacy and security certification criteria that a Health IT Module certified to the “decision support interventions” (§ 170.315(b)(11)) certification criterion must also be certified to, we neglected to include “emergency access” in § 170.315(d)(6). However, because we stated, in the HTI-2 Proposed Rule, that we were proposing to require in § 170.550(h)(3)(ii) that Health IT Modules certified to the “decision support interventions” (§ 170.315(b)(11)) must also be certified to the specific privacy and security certification criteria on and after January 1, 2028, and because § 170.315(d)(6) is one of the specific privacy and security certification criteria referenced in § 170.550(h)(3)(ii), we believe that the public was informed of the requirement to certify to § 170.315(d)(6) as well despite our erroneous omission in the preamble.

Comments.

We did not receive any comments specific to this proposal to add the “decision support interventions” certification criterion (§ 170.315(b)(11)) to the list of certification criteria in § 170.550(h)(3)(ii). We did, however, receive comments addressing other provisions related to decision support interventions and timelines that are beyond the scope of this final rule and are still being reviewed and considered for purposes of issuing subsequent final rules for such proposals in the future.

Response.

Except as to the modified reference or references to `ASTP/ONC,' we have finalized this provision as proposed.

B. Correction—Privacy and Security Certification Framework

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

Comments.

We did not receive any comments on this proposal.

Response.

We have corrected this provision in this final rule to add § 170.550(h)(4) back in the CFR.

IV. Information Blocking Enhancements—Part 171, Subpart D (TEFCA

)

In the HTI-2 Proposed Rule, we proposed revisions to defined terms for purposes of the information blocking regulations, which appear in 45 CFR 171.102. Specifically, we proposed to clarify the definition of “health care provider” (89 FR 63616, 63617, and 63802) and adopt definitions for three terms not previously included in § 171.102: “business day” (89 FR 63601, 63602, 63626, and 63802), “health information technology or health IT” (89 FR 63617 and 63802), and “reproductive health care” (89 FR 63633 and 63802). We proposed to revise two existing exceptions in subpart B of 45 CFR part 171 (§§ 171.202 and 171.204). We proposed revisions to paragraphs (a), (d), and (e) of § 171.202 (89 FR 63620 through 63622 and 63803) and to paragraphs (a)(2) and (3) and (b) of § 171.204 (89 FR 63622 through 63628 and 63803). We proposed two new exceptions, one in each in subparts B and C of part 171. The Protecting Care Access Exception was proposed as new § 171.206 (89 FR 63627 through 63639 and 63804) and the Requestor Preferences Exception as new § 171.304 (89 FR 63639 through 63642, 63804 and 63805). We proposed to codify in § 171.401 definitions of certain terms relevant to the Trusted Exchange Framework and Common Agreement

(TEFCA

) (89 FR 63642, 63804, and 63805) and in § 171.104 descriptions of certain practices that constitute interference with the access, exchange, and use of electronic health information (EHI) (89 FR 63617 through 63620, 63802, and 63803). Lastly, we solicited comment on potential revisions to the TEFCA Manner Exception in subpart D (§ 171.403).

In this final rule, we only address comments on the proposal to codify definitions of certain TEFCA terms in § 171.401 and comments received in response to our potential revisions to the TEFCA Manner Exception. All other information blocking (part 171) proposals from the HTI-2 Proposed Rule and comments received on those proposals are beyond the scope of this final rule but may be a subject of another final rule.

In the HTI-2 Proposed Rule (89 FR 63642 and 63643), we discussed that in the HTI-1 Proposed Rule (88 FR 23872), we proposed to add a

TEFCA manner

condition to the proposed revised and renamed Manner Exception. In the HTI-2 Proposed Rule, we re-stated that this approach “aligns with the Cures Act's goals for interoperability and the establishment of TEFCA by acknowledging the value of TEFCA in promoting access, exchange, and use of EHI in a secure and interoperable way” (88 FR 23872). In the HTI-1 Final Rule (89 FR 1437), in part 171, we finalized a new subpart D, “Exceptions That Involve Practices Related to Actors' Participation in The Trusted Exchange Framework and Common Agreement (TEFCA).” We noted that the new subpart consists of three sections, § 171.400, “Availability and effect of exceptions,” which mirrors §§ 171.200 and 171.300, stating that a practice shall not be treated as information blocking if the actor satisfies an exception to the information blocking provision as set forth in subpart D by meeting all applicable requirements and conditions of the exception at all relevant times (89 FR 1388). We reserved § 171.401 for definitions in a future rulemaking, and also reserved § 171.402 for future use. In § 171.403 we finalized a new TEFCA Manner Exception based on the

TEFCA manner

condition we proposed in HTI-1 Proposed Rule.

A. Definitions

While we reserved § 171.401 for possible future use as a “definitions” section in the HTI-1 Final Rule, we declined to finalize any definitions in the HTI-1 Final Rule. Instead, we referred readers to the definitions in the most recent version of the Common Agreement (88 FR 76773) for the terms relevant to the new exception (89 FR 1388). For example, we noted that when we referred to Framework Agreement(s), we meant any one or combination of the Common Agreement, a 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 § 171.401 by cross-referencing the TEFCA definitions included in the proposed new 45 CFR part 172, “Trusted Exchange Framework and Common Agreement.” We specifically proposed to adopt in § 171.401 the definitions from § 172.102 for the following terms: Common Agreement, Framework Agreement, Participant, Qualified Health Information Network or QHIN

, and Subparticipant. The definitions would apply to all of subpart D.

Comments.

We did not receive any comments regarding our proposal to adopt in § 171.401 the definitions from 45 CFR part 172, “Trusted Exchange Framework and Common Agreement,” for the terms: Common Agreement, Framework Agreement, Participant, Qualified Health Information Network or QHIN, and Subparticipant. Comments regarding the substance of those definitions are addressed in section V. of this final rule.

Response.

We have finalized the definitions as proposed. The above terms will have the meaning given to them in § 172.102.

B. TEFCA

Manner Exception

As briefly discussed above, we finalized a new TEFCA Manner Exception in the HTI-1 Final Rule. In the HTI-1 Final Rule, we stated that the TEFCA Manner Exception (§ 171.403) provides that an actor's practice of limiting the manner in which it fulfills a request to access, exchange, or use EHI to be providing such access, exchange, or use to only via TEFCA will not be considered information blocking when it follows certain conditions (89 FR 1388). Those conditions require that (1) the actor and requestor both be part of TEFCA; (2) that the requestor is capable of such access, exchange, or use of the requested EHI from the actor via TEFCA; and (3) any fees charged by the actor and the terms for any license of interoperability elements granted by the actor in relation to fulfilling the request are required to satisfy, respectively, the Fees Exception (§ 171.302) and the Licensing Exception (§ 171.303). In addition to these three requirements, we noted (89 FR 63643) that we also included a limitation in § 171.403(c), stating that the exception is available only if the request is

not

made via the standards adopted in 45 CFR 170.215, which include the FHIR Application Programming Interface (API) standards.

We noted (89 FR 63643) that our finalized TEFCA Manner Exception differed from the proposed

TEFCA manner

condition in two ways. First, when we proposed the

TEFCA manner

condition, we stated that the Fees Exception and the Licensing Exception would not apply, because “we mistakenly assumed that all actors participating in TEFCA would have

already

reached overarching agreements on fees and licensing such that there would be no need for application of the Fees and Licensing Exceptions” (89 FR 1389). We stated that we believe that by soliciting comments specifically on this point, we provided notice to parties that we either would or would not apply the Fees and Licensing Exceptions. In response to our proposal in the HTI-1 Proposed Rule, some commenters expressed concern that because the Common Agreement prohibits fees between QHINs

but is otherwise silent on fees between Participants and Subparticipants, the proposal could allow actors to charge fees to access, exchange, or use EHI that did not comply with the Fees or Licensing Exceptions. Some commenters also expressed that this could have the effect of disincentivizing participation in TEFCA and could cause actors to use other options of electronic exchange outside of TEFCA, where the actors believed the Fees and Licensing Exceptions would apply. As such, in the HTI-1 Final Rule, we finalized the TEFCA Manner Exception to include that any fees charged by the actor, and any licensing of interoperability elements, must satisfy the Fees Exception (§ 171.302) and the Licensing Exception (§ 171.303) (89 FR 1389). In the HTI-2 Proposed Rule, we stated that while we continue to believe that it was clear that the alternative would be

apply the exceptions, we requested comment on whether there are drawbacks to applying the Fees and Licensing Exceptions, and if we should continue to apply them to the TEFCA Manner Exception as currently required in § 171.403(d).

We noted (89 FR 63643) that the other change made to the proposed

TEFCA manner

condition was the limitation that carves out requests made for access, exchange, or use of EHI via FHIR API standards (89 FR 1389). We finalized this limitation in response to comments noting that a request could be made for access, exchange, or use via FHIR-based API and an actor could respond in a different manner and satisfy the exception (89 FR 1390 and 1391). Commenters on the HTI-1 Proposed Rule further noted that this potential

outcome could undermine our stated purpose in incentivizing TEFCA participation with the new exception (See 89 FR 1390). In the HTI-2 Proposed Rule (89 FR 63643), we solicited comment on this limitation within the TEFCA Manner Exception for requests via FHIR API standards. For example, we solicited comment on whether the limitation should be expanded to include exchange based on versions of the FHIR standards that are more advanced than those adopted in 45 CFR 170.215 or approved through the 45 CFR 170.405(b)(8), “Standards Version Advancement Process—voluntary updates of certified health IT to newer versions of standards and implementation specifications.” We noted that as of the time we issued the HTI-2 Proposed Rule, the limitation would only cover requests made via FHIR API standards codified in § 170.215, including standards that may be updated from time to time through § 170.405(b)(8), which may involve a delay before the version is formally approved under Standards Version Advancement Process (SVAP).

We also sought comment on a different approach (89 FR 63643). We noted that eventually all TEFCA QHINs will be required to support exchange via FHIR API standards. A Participant or Subparticipant who makes a request for access, exchange, or use of EHI via FHIR API will at first make such a request through a QHIN, but in time, a Participant or Subparticipant could directly request access, exchange, or use of EHI via FHIR API standards from another Participant or Subparticipant in a different QHIN. We stated that one option would be to sunset the limitation in § 171.403(c) once all QHINs can support brokered FHIR. Another option would be to sunset the limitation in § 171.403(c) if all QHINs, Participants and Subparticipants support facilitated FHIR exchange. We also stated that as an alternative to these options, we could maintain the exception as is, regardless of FHIR API adoption among TEFCA entities. We requested comment on all of the options, including whether or not the limitation should remain as it is currently.

Comments.

The majority of comments we received on whether there are drawbacks to applying the Fees and Licensing Exceptions, and if we should continue to apply them to the TEFCA Manner Exception as currently required in § 171.403(d), were in support of the exception as finalized in the HTI-1 Final Rule. Commenters expressed appreciation that ASTP/ONC listened to their feedback in response to the HTI-1 Proposed Rule and added the Fees and Licensing Exceptions applicability to the TEFCA Manner Exception. Commenters noted that including the applicability of the Fees and Licensing Exceptions would mitigate risks that some organizations could exploit their TEFCA participation to consolidate market power and stifle competition.

Response.

We appreciate the commenters' support. We are retaining the exception as finalized in HTI-1 Final Rule, such that there will be no changes finalized in this final rule and the Fees and Licensing Exceptions will apply to an actor seeking to use the TEFCA Manner Exception.

Comments.

One commenter recommended modifying the TEFCA Manner Exception so that both the requestor and responder must agree on the mechanism (FHIR or other transmission protocol) within TEFCA used to exchange EHI, in order to accommodate TEFCA participants who may not yet have enabled FHIR transactions for TEFCA.

Response.

We appreciate the comment and the opportunity to clarify that the exception does not apply to requests made via the standards adopted in 45 CFR 170.215, including version(s) of those standards approved pursuant to 45 CFR 170.405(b)(8) (the Standards Version Advancement Process, or SVAP). The standards adopted in § 170.215 include the FHIR standards the commenter describes. When actors seek to use the TEFCA Manner Exception, as finalized in 45 CFR 171.403, the exception includes a “requestor capability” condition (§ 171.403(b)) that limits the exception to only be available when the requestor is capable of such access, exchange, or use of the requested EHI from the actor via TEFCA. Therefore, if the requestor is unable to receive the EHI from the actor using a FHIR transaction via TEFCA, this exception would not be available to the actor. We believe this provides enough flexibility for actors to use this exception when the requestors are able to access the requested EHI, while ensuring that actors who do not yet have FHIR-based exchange capabilities will not be expected to share via FHIR.

Comments.

A few commenters suggested that ASTP/ONC revise the TEFCA Manner exception to state that if an actor charges fees to access data through TEFCA, the TEFCA Manner Exception will not apply, and the requestor would be entitled to EHI through a different manner. One commenter stated that ASTP/ONC should state that charging fees to access data through TEFCA negates the TEFCA Manner Exception and actors that do not provide a secondary method of exchange would be considered information blockers.

Response.

We decline to adopt these suggestions. We have retained the finalized exception from the HTI-1 Final Rule. We reiterate that certain fees are permitted under the Fees Exception, and that an actor participating in TEFCA would still be subject to the restrictions of the Fees Exception if the actor is seeking to make use of the TEFCA Manner Exception (for example, by responding via TEFCA even if the request was not received via TEFCA). We note that, per § 171.403(c), the TEFCA Manner Exception is not available if a requestor requests EHI via the standards adopted in 45 CFR 170.215, including version(s) of those standards approved pursuant to 45 CFR 170.405(b)(8). Under those conditions described in § 171.403(c), a fee could still be considered an interference if it does not meet the requirements of the Fees Exception (or the practice is not covered by another exception).

Comments.

Many commenters supported retaining the limitation in the TEFCA Manner Exception to exclude requests made via the standards adopted in § 170.215. Commenters stated that removing the condition in § 171.403(c) could disincentivize joining TEFCA for entities seeking to leverage FHIR-based exchange. Some of those commenters also suggested that the condition should be removed once everyone exchanging data on TEFCA is required to support the more advanced FHIR standard. One commenter recommended removing the condition now, and others recommending ASTP/ONC consider sunsetting the condition in the future but stated that it was premature to do so now. Most commenters supported maintaining the condition for now, and recommended ASTP/ONC revisit the exception in the future.

Response.

We appreciate the comments and agree that the condition remains useful for advancing interoperability as discussed in the HTI-2 Proposed Rule. We also agree that it is premature to remove the condition at this time. As noted above, we are maintaining the TEFCA Manner Exception as finalized in the HTI-1 Final Rule.

Comments.

A few commenters expressed concerns that actors who participate in TEFCA may seek to use this exception to cover practices involving the access, exchange, or use of EHI with entities or requestors who do not participate in TEFCA. The commenters asked for clarification on this point.

Response.

We appreciate the opportunity to clarify that this

exception is only available when both the actor and the requestor participate in TEFCA as QHINs, Participants, or Subparticipants (§ 171.403(a)). An actor who participates in TEFCA may not use this exception to cover any practice related to the access, exchange, or use of EHI with an entity who is not a TEFCA QHIN, Participant, or Subparticipant.

Comments.

Some commenters expressed concerns related to the “TEFCA SOP XP Implementation: Health Care Operations” because the standard operating procedure (SOP) would allow providers and developers to charge health plans to access data under the health care operations exchange purpose.

Response.

Commenters correctly point out that health care providers and developers of certified health IT (“actors” for purposes of the information blocking regulations) are permitted to charge fees under TEFCA for the health care operations exchange purpose as well as other exchange purposes.

However, these fees would need to meet the Fees Exception (§ 171.302) under the information blocking regulations and if charged in conjunction with an actor choosing to voluntarily use and meet the conditions of the TEFCA Manner Exception. We decline, however, to state in this final rule whether any specific fee amount that may be charged as a permitted fee under TEFCA meets the conditions of the Fees Exception.

4.2 Required Information and Permitted Fees and Table 2 at

https://rce.sequoiaproject.org/wp-content/uploads/2024/08/SOP-Exchange-Purposes_CA-v3_508.pdf.

Comments.

We received many comments in response to our question regarding whether the limitation should be expanded to include exchange based on versions of the FHIR standards that are more advanced than those adopted in 45 CFR 170.215 or approved through the 45 CFR 170.405(b)(8), “Standards Version Advancement Process—voluntary updates of certified health IT to newer versions of standards and implementation specifications.” Some commenters suggested that the limitation should only apply to requests made via standards adopted in § 170.215 or through the Standards Version Advancement Process (SVAP). Some suggested that if the actor supports the more advanced FHIR standard that has not yet been adopted, then the actor must respond to a request via that standard. The commenters stated that if the actor does not support the more advanced FHIR standard at the time of the request, then the TEFCA Manner Exception should still be available.

Response.

We appreciate the comments. Until adoption of the FHIR standard is widespread, we think it is sufficient to reserve the carve-out only for versions of the FHIR standard adopted under § 170.215 or approved through the SVAP process. We believe including standards approved through the SVAP process, as well as those adopted under § 170.215, provides the right balance of ensuring newer versions of the FHIR standard can be used without expanding the carve-out to the point that it subsumes the exception itself.

Comments.

One commenter encouraged us to clarify that the exception does not mean an organization participating in TEFCA can or will only share data with other organizations participating in TEFCA. Another commenter recommended that the mutuality requirement be phased out so that an actor's participation in TEFCA allows them to claim the TEFCA Manner Exception regardless of the requestor's participation.

Response.

We appreciate the opportunity to draw attention to § 171.403(a), as finalized in the HTI-1 Final Rule, which states that the actor and requestor

must both be part of TEFCA

for the exception to be available. A request to access, exchange, or use EHI that an actor receives from a requestor who does not participate in TEFCA as a QHIN, Participant, or Subparticipant does not qualify for the TEFCA Manner Exception (89 FR 1388). Nor does anything in this exception, or anything else in the information blocking regulations, permit a TEFCA entity actor to interfere with a 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

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

(TEFCA

) 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® (QHINs

) 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

establishing an organizational, operational, and technical floor for nationwide interoperability and securely facilitating the exchange of information across different networks nationwide.

By providing a common and consistent approach for the exchange of health information across many different networks, TEFCA simplifies and significantly reduces the number of separate networks that individuals, health care providers, and other interested parties need to be a part of in order to access the health information they seek. HINs that voluntarily join TEFCA will facilitate exchange in a secure and interoperable manner. TEFCA establishes a method for authenticating trusted HIN participants, potentially lowering the cost and expanding the nationwide availability of secure health information exchange capabilities. The establishment of technical services for HINs that voluntarily join TEFCA, such as an electronic address directory and security services, will help to scale network exchange nationwide. In addition, the organizational and operational policies established through TEFCA enable the exchange of health information among HINs and include minimum conditions required for such exchange to occur.

Updates in Common Agreement Version 2.1 reflect the latest technical specifications, among other changes, including updates to network-based exchange using FHIR APIs, which are a cornerstone of the interoperability initiatives of not only ASTP/ONC but also of other Federal agencies such as the Centers for Medicare & Medicaid Services (CMS), Centers for Disease Control and Prevention (CDC), Health Resources & Services Administration (HRSA), and U.S. Department of Veterans Affairs (VA).

Under TEFCA, QHINs play an important role in advancing secure, standardized health information exchange. QHINs have significant organizational and technical capabilities, facilitate exchange at the highest level of the TEFCA infrastructure, and are the entities with which Participants (and their Subparticipants) connect to engage in TEFCA Exchange. “TEFCA Exchange,” which we proposed to define in § 172.102, means the transaction of electronic protected health information (ePHI) between Nodes

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.

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)

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.

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

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

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.

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

Comments.

A number of commenters supported ASTP/ONC's approach of proposing to codify TEFCA requirements but expressed concern that it could be adopting TEFCA requirements into a regulatory framework too quickly and requested that ASTP/ONC provide information regarding our intentions to adopt other TEFCA requirements in the future. These commenters recommended that ASTP/ONC take a cautionary approach and potentially delay the adoption of further TEFCA requirements, citing that TEFCA is intended to be fluid and evolve more quickly than regulations. One commenter also urged ASTP/ONC take care with future adoptions of TEFCA requirements that we do not undermine the independence of the Recognized Coordinating Entity® (RCE®).

Several commenters were concerned that codifying TEFCA hampers the ability of TEFCA to change and adapt as needed, and a few of these commenters suggested that the codification of TEFCA requirements is unnecessary because TEFCA infrastructure is supported by its contractional nature. One commenter specifically recommended that ASTP/ONC incorporate TEFCA and relevant SOPs by reference rather than adopt sections of TEFCA as regulations out of concern that adopting sections of TEFCA as regulations would undermine the sections of TEFCA that are not adopted as a whole and would require future rulemaking actions to modify the sections of TEFCA that have been codified as regulations.

Response.

We appreciate commenters' support of our proposals and also understand the concerns about the adoption of TEFCA requirements in regulation and the need for TEFCA to evolve as the interoperability landscape changes. The provisions we have finalized in 45 CFR part 172 mainly address QHIN appeals (subpart F) and the underlying requirements regarding which decisions may ultimately be appealed (subparts B through E). We believe establishing QHIN appeal rights in regulation will enhance trust in the TEFCA framework, as QHINs—that have invested significant time and resources into becoming a QHIN—will know that processes exist to appeal decisions that could have a significant impact of their businesses and the exchange of information for their Participants and Subparticipants. That said, we do not believe it would benefit TEFCA to codify all TEFCA requirements in regulation due to the need, as commenters noted, for TEFCA to move quickly and evolve with the 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

ASTP/ONC to take a more direct role in monitoring and enforcing compliance and bolstering Participant confidence as TEFCA participation expands and monitoring by QHINs potentially becomes more difficult. Several commenters were concerned that there was no investigative body for independent oversight within TEFCA and suggested ASTP/ONC should monitor for the possibility of QHINs exercising outsized influence. A few commenters recommended that ASTP/ONC create an oversight board, or a body associated with the Office of the Inspector General (OIG), to provide independent review within TEFCA. These commenters also suggested that ASTP/ONC should include a mechanism for patient-identified issues.

Some commenters suggested that ASTP/ONC require that a QHIN create a continuity plan that includes support for the migration of Participants and Subparticipants if a QHIN is terminated or sanctioned. Additionally, one commenter requested information on how the TEFCA requirements will impact existing SOPs and whether the RCE will continue to have the authority to modify requirements for QHINs through the SOPs.

Response.

We thank commenters for their feedback. We appreciate commenters' concerns regarding the role of QHINs in TEFCA governance but have decided not to make any related changes in this final rule. We believe QHINs are best positioned to have primary oversight responsibility over their customers (

i.e.,

Participants) and should have autonomy to make decisions about their networks so long as such decisions do not conflict with the requirements for TEFCA Exchange. We note that there is strong representative and participatory network governance built into the TEFCA infrastructure, including the requirement that QHINs must maintain a representative and participatory group or groups with the authority to approve processes for governing the Designated Network (§ 172.201(c)(7)). Regarding the comments related to including additional oversight within the TEFCA framework, including the suggestion of including HHS OIG in TEFCA governance and oversight, we believe that doing so is not necessary and could limit the flexibility of TEFCA's public-private model of exchange and governance. We believe the oversight provided by ASTP/ONC, including as established in provisions we are finalizing in 45 CFR part 172, meets the needs of the TEFCA community and provides strong support for TEFCA. ASTP/ONC will continue to monitor TEFCA, and we will consider additional measures should circumstances arise that show that QHINs require additional oversight.

We appreciate the suggestion regarding creation of a mechanism for patient-identified issues and note that there are already mechanisms in place for reporting of patient-identified issues. Patients can report issues to ASTP/ONC through the TEFCA tab in the Health IT Feedback and Inquiry Portal available at

https://inquiry.healthit.gov/support/plugins/servlet/desk/portal/2.

Patients may also report issues to the RCE at

https://rce.sequoiaproject.org/contact/.

We encourage patients to report any issues they are experiencing to ASTP/ONC, the RCE, or both so that we can continue to improve TEFCA Exchange.

We also appreciate the suggestion that we require QHINs to create a continuity plan that includes support for the migration of Participants and Subparticipants if a QHIN is terminated or sanctioned. We did not propose to require a continuity plan in the HTI-2 Proposed Rule and believe it would be appropriate for the public to have an opportunity to submit comments before we could adopt this type of requirement. Therefore, we have decided not to finalize a requirement regarding creation of a continuity plan in this final rule. We may consider including such a requirement in a future rulemaking. In the meantime, we encourage QHINs and their Participants to discuss the details regarding continuity of service and consider addressing such details in the respective Framework Agreement between the two parties.

Regarding the comment concerning how the TEFCA requirements will impact existing SOPs, we note that the SOPs can be updated to align with updated requirements. We expect that the RCE will continue to support the development of SOPs, as they have to this point.

Comments.

Multiple commenters raised concerns about the adoption of the Exchange Purposes (XPs) SOP version 3.0 without a public comment period. These commenters highlighted in particular that the recent XPs SOP version 3.0 allows health care providers to charge for data exchanges and requested that ASTP/ONC not allow entities to charge fees for TEFCA-based data exchanges.

Response.

We thank commenters for raising this concern to our attention. While we understand the importance of this issue, it falls outside the scope of this final rule. The provisions regarding fees and the XP SOP version 3.0 are not addressed within this final rule. We encourage further engagement on the topic of fees through public TEFCA meetings, webinars, and other feedback opportunities.

Comments.

Several commenters advocated for the inclusion of State, Tribal, Local, and Territorial (STLT) public health agencies in the governance of TEFCA and QHINs to identify priority use cases. A few of these commenters also noted that the exchange of Prescription Drug Monitoring Program (PDMP) information through TEFCA is incompatible with PDMPs' data confidentiality and privacy requirements and suggested that PDMPs be excluded from TEFCA requirements.

A few commenters additionally noted that there is no Common Agreement for advisory boards and suggested that ASTP/ONC recognize advisory boards, including or referencing groups such as patients, providers, payors, and public health. One commenter recommended that TEFCA advisory groups include expanded roles for health plan representatives.

Response.

We thank commenters for their input. The involvement of state and local public health agencies, as well as advisory boards, in TEFCA is an important consideration, and we will consider the related suggestions as we implement and refine the TEFCA governance process. We encourage interested communities to continue engaging with us as these aspects of the TEFCA framework are refined. We welcome all feedback from interested parties, which can be submitted via the ASTP/ONC website at

https://inquiry.healthit.gov/support/plugins/servlet/desk/portal/2/create/61,

for consideration and potential inclusion within the TEFCA framework.

We do not understand the comment that there is no Common Agreement for advisory boards. We appreciate the suggestion for enhancing TEFCA's governance. We are currently considering ways to ensure that different groups, such as patients, providers, payors, and public health, are represented within TEFCA's governance, which could include the development of advisory boards or councils. However, we did not make a proposal in this rulemaking regarding advisory boards, and it would be appropriate for the public to have an opportunity to submit comments before we could adopt these types of changes. We may consider addressing this issue in a future rulemaking.

We appreciate the comment that the exchange of PDMP information through TEFCA is incompatible with PDMPs' data confidentiality and privacy

requirements and the suggestion that PDMPs be excluded from TEFCA requirements. We have decided not to make any related changes in this final rule because we did not make any proposals about PDMPs, and it would be appropriate for the public to have an opportunity to submit comments before we could adopt these types of changes. We may consider addressing this issue in a future rulemaking.

Comments.

Several commenters were concerned that the TEFCA requirements prioritize TEFCA participation over other mechanisms of interoperability. A few commenters were concerned that the TEFCA requirements allow participants to not respond to queries from entities that are not TEFCA participants when the data exchange is lawful thereby allowing data from certain providers to be siloed. These commenters suggested that ASTP/ONC clarify that the refusal by entities connected to TEFCA to lawfully exchange data with entities that are not licensed health care professionals is information blocking. Commenters also requested that ASTP/ONC publish a request for information (RFI) on the treatment of all federally defined health care providers under TEFCA. One commenter also advocated that TEFCA requirements should focus on treatment and individual access exchange.

Response.

We thank commenters for their feedback. The concerns raised regarding TEFCA requirements and their interaction with other interoperability mechanisms are out of scope for this final rule, since the TEFCA requirements do not apply to other mechanisms of interoperability. However, we would like to direct commenters to the TEFCA Manner Exception in 45 CFR 171.403, finalized in the HTI-1 Final Rule (89 FR 1387 through 1388). This exception applies when, among other necessary conditions, both the actor and requestor participate in TEFCA as QHINs, Participants, or Subparticipants (§ 171.403(a); 89 FR 1388). When the necessary conditions under § 171.403 are met, the actor's practice of fulfilling requests for access, exchange, or use of EHI exclusively via TEFCA will not be considered information blocking. We recommend reviewing this exception for further clarity on TEFCA participation and its interplay with information blocking.

Comments.

One commenter expressed concern about the perceived lack of intellectual property protections in TEFCA and recommended that ASTP/ONC increase intellectual property protections within TEFCA.

Response.

We thank the commenter their feedback. The issue of intellectual property protections within TEFCA is outside the scope of this final rule, as we did not propose, and this final rule does not address, such provisions. We welcome all feedback from interested parties, which can be submitted via the ASTP/ONC website at

https://inquiry.healthit.gov/support/plugins/servlet/desk/portal/2/create/61,

for consideration and potential inclusion within the TEFCA framework.

Comments.

A number of commenters who expressed support for TEFCA were concerned that compliance with TEFCA requirements could be difficult for 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

and RCE

websites. In addition, we continue to support the transition to TEFCA Exchange through regular webinars and information sessions for the public.

https://www.healthit.gov/topic/interoperability/policy/trusted-exchange-framework-and-common-agreement-tefca.

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

We appreciate the recommendation that ASTP/ONC adopt more specific definitions of Participants and Subparticipants for TEFCA to reduce ambiguity; however, we have not changed the definitions in this final rule because we do not believe the definitions are ambiguous.

Last, we are aware that emergency medical service providers and agencies may face obstacles in joining TEFCA, and we are considering options for addressing such potential obstacles. We plan to conduct additional outreach to the emergency medical service community to better understand their concerns and the issues this community faces and will consider other ways to assess the issue(s) moving forward.

Comments.

One commenter suggested that ASTP/ONC should mandate that health information exchanges respond to every QHIN request with sharing data

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

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.

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 § 172.100 of the HTI-2 Proposed Rule the basis, purpose, and scope for the proposed TEFCA provisions in 45 CFR part 172.

We proposed in § 172.100(a) that the basis for these provisions would be to implement section 3001(c)(9) of the PHSA (42 U.S.C. 300jj-11(c)(9)). We proposed in § 172.100(b) the dual purposes of proposed part 172: (1) to ensure full network-to-network exchange of health information; and (2) to establish a voluntary process for QHINs to attest to adoption of the Trusted Exchange Framework and Common Agreement. We explained that § 172.100(b)(1) supports the statutory basis because the organizational and operational policies covered by part 172 would enable the exchange of health information among health information networks using the common set of rules found in these regulations. We also noted that § 172.100(b)(2) supports the statutory basis because it implements section 3001(c)(9)(D) of the PHSA. We proposed in § 172.100(c) the scope for part 172, which would include: (1) minimum qualifications needed to be Designated as a QHIN capable of trusted exchange under TEFCA; (2) procedures governing QHIN Onboarding and Designation, suspension, termination, and further administrative review; (3) attestation submission requirements for a QHIN to attest to its adoption of TEFCA; and (4) ONC attestation acceptance and removal processes for publication of the list of attesting QHINs in the QHIN Directory.

In proposed § 172.101, we specified the applicability of part 172 by proposing that part 172 would apply only to Applicant QHINs, QHINs, and terminated QHINs. In the HTI-2 Proposed Rule, we noted that our proposed QHIN definition in § 172.102 captures suspended QHINs (since a suspended QHIN is still a QHIN) and so we did not address them separately in proposed § 172.101. In § 172.102, we proposed definitions for certain terms in part 172. In the HTI-2 Proposed Rule, we stated that we intended the definitions provided in the Common Agreement to be consistent with these proposed definitions. We also stated that differences in phrasing would generally be attributable to differences in context, though in the case of any true conflict, we stated that we intend the regulatory definitions to control.

Additionally, ASTP/ONC has hired a contractor to help administer and implement TEFCA Exchange. This contractor, chosen through a competitive solicitation, is known as the RCE. While the RCE is currently one entity, in the future, we noted in the HTI-2 Proposed Rule, ONC may choose to assign some or all of its responsibilities to a different entity or multiple entities. We noted that assigning responsibilities to a different or multiple entities in the future could, for example, allow for more efficient use of resources or best leverage expertise. In § 172.103, “Responsibilities ONC may delegate to the RCE,” we proposed that ONC may assign certain responsibilities to such an entity or entities for these purposes. We note that we changed the title of this section from the proposed title—“Responsibilities ONC may delegate to the RCE”—to “Responsibilities ASTP/ONC may delegate to the RCE” because of the recent change to the name of our office and to conform with similar changes made throughout this final rule. In addition to changes to the proposed text described below, we have also finalized references to “ONC” in subpart A of the proposed rule to instead refer to “ASTP/ONC.” For further discussion of the use of “ASTP/ONC,” please see the Executive Summary of this final rule.

We proposed in § 172.103(a)(1) through (4) that ONC may assign any of its responsibilities in subparts C (“QHIN Onboarding and Designation Process”) and D (“Suspension”) and §§ 172.501 (“QHIN self-termination”) and 172.503 (“Termination by mutual agreement”). In § 172.103(b), we proposed that any authority exercised by the RCE under this section is subject to review by ONC under subpart F (“Review of RCE Decisions”).

Comments.

One commenter argued that any TEFCA expansion to new purposes should be driven by Congressional mandate and conducted transparently with opportunities for public input. The commenter emphasized that an open process ensures that stakeholders' diverse perspectives are considered fully and that the TEFCA framework evolves to serve all stakeholders' collective interests. The commenter cautioned against mission creep and recommended establishing clear guardrails for any future expansion of TEFCA's use cases, including rigorous evaluation, comprehensive needs assessments and industry engagement. Other commenters advised ASTP/ONC to avoid sub-regulatory guidance and instead follow standard rulemaking procedures, including 60-day public comment periods for proposed changes or additions to TEFCA SOPs. One commenter expressed that all substantive issues and core concepts, such as, but not limited to, foundational definitions of the different exchange purposes, should be codified in regulation following the notice and comment rulemaking process, rather than being addressed in TEFCA documents such as SOPs, which do not undergo the same rigorous review process as do regulations. Another commenter further argued that any future regulatory changes should relate back to the text of the Cures Act.

Response.

We thank the commenter for the feedback. We have developed and implemented TEFCA consistent with the 21st Century Cures Act (section 3001(c)(9) of the PHSA, as added by the 21st Century Cures Act (Pub. L. 114-255, Dec. 13, 2016)). That statute sets out at least one broad statutory purpose: ensuring full network-to-network exchange of health information. TEFCA as currently designed furthers that purpose. We do agree that TEFCA should generally be related to that goal or other ones suggested in the statute—for instance, that the exchange should be “trusted”—but we believe that statute envisions that TEFCA will be flexible within that broad goal, consistent with the need for flexibility in rapidly developing spaces like health information technology and health information exchange. For example, section 3001(c)(9)(B) identifies a list of potential topics the Common Agreement “may include,” but does not require the Common Agreement to address those topics or suggest that those topics are the only ones the Common Agreement can address.

We appreciate the commenters' suggestion to follow standard rulemaking procedures. As noted previously in this rulemaking, we believe the inclusion of TEFCA provisions in this rulemaking will strengthen the trust of interested parties in TEFCA and support its success at scale. We likewise believe that TEFCA must remain flexible and agile, in order to enable nationwide exchange at scale.

Comments.

Commenters supported the general definitions related to TEFCA proposed in regulatory text, suggesting that those terms may arise in other regulatory programs and can be later cross-referenced.

Response.

We thank commenters for their support and have finalized the definitions related to TEFCA we proposed in § 172.102 with some modifications based on comments we received and as explained hereafter.

Comments.

One commenter expressed concern about codifying definitions from the Common Agreement in regulation and specifically identified inconsistencies between the Common Agreement and the proposed regulatory definitions. The commenter noted that some definitions in the HTI-2 Proposed Rule do not fully align with the Common Agreement (

e.g.,

Threat Condition and Recognized Coordinating Entity) and some of the definitions (

e.g.,

XP Code) are included in the regulation but not used in the proposed regulatory text. The commenter also noted that certain definitions in the HTI-2 Proposed Rule refer to applicable SOPs (

e.g.,

the definition for Participant/Subparticipant Terms of Participation), while others do not—including when the Common Agreement does refer to the SOP. For example, Exchange Purposes in the proposed regulatory text omits reference to SOPs, though the Common Agreement includes such reference. The commenter states that leaving out references to SOPs could change the meaning of the Common Agreement and render the SOPs inapplicable. The commenter also stated that the term “Responding Node” is used in the definition of Required Information but not defined in the regulation. Further the commenter noted that some definitions refer to “ONC (or an RCE)” (

e.g.,

threat condition), other times there is no mention of an RCE, even though the Common Agreement includes such a reference (

e.g.,

Qualified Health Information). The commenter suggested that differing definitions between the Common Agreement and the regulatory text will lead to confusion and misinterpretation. The commenter also expressed concern that, if such inconsistencies are finalized in the regulatory text, they could necessitate subsequent amendments to the Common Agreement that are inconsistent with the public input used to establish the definitions in the Common Agreement.

Response.

We appreciate the comments that opined on the potential for confusion and misinterpretation related to certain proposed definitions. We also appreciate the input related to clear and consistent alignment between the regulatory definitions and the Common Agreement. As noted in the proposed rule, we intend for the definitions in this final rule to be consistent with the definitions in the Common Agreement and the SOPs. We have adopted this approach to maintain consistency between the Common Agreement and the regulatory text (89 FR 63642). However, in some cases we used different verbiage in the HTI-2 Proposed Rule to accommodate discussion of different contexts such as future or past circumstances. In other cases, differences between definitions in the regulation text and the Common Agreement may be the result of inconsistencies in the level of specification between the Common Agreement and definitions in the HTI-2 Proposed Rule. However, we agree with the commenter that these differences in the definitions between the Common Agreement or SOPs and this rulemaking may lead to confusion and misinterpretation or the need for amendments to the Common Agreement. Therefore, in this final rule we have addressed inconsistencies by revising the final regulatory text wherever feasible to directly align with definitions in the Common Agreement and SOPs. Below we explain how, in response to public comment, we have further aligned definitions in this final rule to the definitions in the Common Agreement and SOPs.

Regarding the comment that leaving out references to SOPs could change the meaning of the Common Agreement and render the SOPs inapplicable, we reiterate our statement in the HTI-2 Proposed Rule that in the case of any true conflict, we intend for the regulatory definitions to control (89 FR 63644). We also note that, as stated, our definitions in the HTI-2 Proposed Rule included references to SOPs (see for example, § 172.102, definitions of “Governance Services” and “Participant/Subparticipant Terms of Participation”). We have further updated definitions in this final rule to incorporate reference to SOPs where necessary to align with the Common Agreement as described below.

Regarding the definition of “Threat Condition,” we agree with the comment that the definition in this final rule should be identical to the definition in the Common Agreement. Given our stated intent for the TEFCA-specific definitions in these regulations to align with the definitions in the Common Agreement and SOPs (89 FR 63642), and public comments that clearly stated a preference for aligning the definitions in this final rule to the definitions in the Common Agreement and SOPs, we have finalized this definition to align with the definition in the Common Agreement. As such, we have modified the proposed definition and finalized the definition of “Threat Condition” as set out in the regulatory text at the end of this document.

Regarding the definition of “Recognized Coordinating Entity,” we agree with the commenter that the definition in this final rule should be identical to the definition in the Common Agreement. Given our intent for the TEFCA-specific definitions in these regulations to align with the definitions in the Common Agreement and SOPs (89 FR 63642), and public comments that clearly stated a preference for aligning the definitions in this final rule to the definitions in the Common Agreement and SOPs, we have finalized this definition to align with the definition in the Common Agreement. As such, we have modified the proposed definition and finalized the definition of “Recognized Coordinating Entity® (RCE®)” as set out in the regulatory text at the end of this document.

Regarding the comment that “XP Code” is included in the regulation, but not used in the regulatory text, we are not clear on the specific issue the commenter is raising. We note that “Exchange Purpose Code or XP Code” was defined in the regulatory text for the Proposed Rule (89 FR 63806) as a code that identifies the Exchange Purpose being used for TEFCA Exchange. We use only “Exchange Purpose Code” in the discussion in this final rule, but we recognize interested parties may commonly use “XP Code”. Therefore, as noted in the HTI-2 Proposed Rule, we interpret the “or” between “Exchange Purpose Code” and “XP Code” in the definition to indicate that the two terms are interchangeable. Accordingly, we have decided that use of either term is appropriate throughout the regulation (89 FR 63806) and have finalized the definition of “Exchange Purpose Code or XP Code” as proposed.

Regarding the comment that certain definitions refer to applicable SOPs (

e.g.,

the definition for Participant/Subparticipant Terms of Participation) while others do not, we note that this inconsistency was not intentional. Given our intent for the TEFCA-specific definitions in these regulations to align with the definitions in the Common Agreement and SOPs (89 FR 63642), and the public comments that clearly stated a preference for aligning the definitions in this final rule to the definitions in the Common Agreement and SOPs, we have finalized the definition of “Exchange Purpose(s) or XP(s)” to align with the definition in the Common Agreement. As such, we have modified the definition of “Exchange Purpose(s) or XP(s)” to align with the Common Agreement definition, which includes mention of SOP(s).

Regarding the comment that the term “Responding Node” was included in the proposed definition of “Required Information” but not proposed to be defined in § 172.102, we note that this inconsistency was not intentional. In order to address commenters' reasonable expectation that we would define terms necessary to understand other terms we proposed to define where such definitions are consistent with those in the Common Agreement per our stated intent of alignment (89 FR 63642), we have finalized the definition of “Responding Node” in § 172.102.

Regarding the comment that some definitions refer to “ONC (or an RCE)” (

e.g.,

Threat Condition), and other times there is no mention of an RCE even though the Common Agreement includes such a reference (

e.g.,

Qualified Health Information Network), we intentionally referenced the RCE in certain circumstances and not others in the definitions we proposed in § 172.102. Our goal with the proposed definitions was to afford ourselves flexibility in the event that one day there is no longer an RCE. We emphasize, however, that the current RCE, the Sequoia Project, is now in the second year of a five-year contract with ASTP/ONC.

Comments.

One commenter identified what they believed to be two typos in proposed 45 CFR 172.102. The commenter noted that a few definitions, notably the proposed definitions for the HIPAA Privacy Rule and the HIPAA Security Rule, reference the regulations at 45 CFR part 160 and subparts A and E of 45 CFR part 164, as well as to 45 CFR part 160 and subparts A and C of 45 CFR part 164. The commenter asked for clarification on what subparts were meant to be referenced.

Response.

The terms HIPAA Privacy Rule and the HIPAA Security Rule are both defined in § 172.102 by referencing their codifications in the CFR. Both rules have slightly different citations. The citation for the HIPAA Privacy Rule is 45 CFR part 160 and subparts A and E of 45 CFR part 164. The HIPAA Security Rule is located at 45 CFR part 160 and subparts A and C of 45 CFR part 164. Because those are the correct citations for the HIPAA Privacy and Security Rules, we have finalized the HIPAA Privacy Rule and the HIPAA Security Rule definitions in § 172.102 as proposed.

Comments.

One commenter recommended a revision to the definition of “Framework Agreements” to include only those documents for which a draft was made available to the public and the public has some opportunity to provide input on the draft before a final version is effective. The commenter requested that we require such a process for all Framework Agreements. The commenter noted that the RCE should make SOP drafts available for public feedback or any other transparent process around their establishment and review. The commenter noted further that under the proposed rule, ASTP/ONC can review an RCE decision, but that there is no process for a QHIN or a participant to appeal or require formal review of an SOP. The commenter cited an SOP issued last summer that the commenter believed significantly narrowed the scope of required response for treatment purposes, which it said cut off access to the networks for hundreds of thousands of patients. The commenter believed that the proposed rule would allow this result to happen again.

Response.

We appreciate the comments. However, the definition of “Framework Agreement(s)” we proposed tracks the definition in the Common Agreement, and we believe that deviating from the definition in the Common Agreement for such a foundational concept might be confusing or suggest differences between the meaning of Framework Agreements in the Common Agreement and the regulation that we do not intend. Nor do we agree with the commenters who suggest that we should require more process for SOPs than is laid out in the Common Agreement (at section 5.3 of version 2.0). That process—to which QHINs, Participants, and Subparticipants agree by signing the Framework Agreements—balances the need for input by the public with the need to respond quickly in a 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

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

addresses dispute resolution, and section 15.6 addresses the escalation of certain disputes to ASTP/ONC.

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.

Common Agreement for Nationwide Health Information Interoperability (

healthit.gov

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 § 171.103, as well as the proposed text of § 171.103(a), has been finalized as “ASTP/ONC” to reflect the recent change to our office's name and ensure consistency in the use of ASTP/ONC throughout this final rule. In addition, we have added language requiring an RCE to seek and receive ASTP/ONC's prior authorization before making certain decisions (

e.g.,

interim or final designation decisions (§ 172.303(b)), setting onboarding requirements and determining a QHIN has complied with those requirements (§ 172.304(b) and (c)), and deeming a QHIN application withdrawn for failure to respond to information requests during the designation process (§ 172.305(c)). We have added language to § 172.103(b) to clarify that ASTP/ONC cannot subdelegate the authority to grant prior authorization to an RCE. These revisions, taken together, help to ensure that an RCE remains subordinate to ASTP/ONC and provides only 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,

we proposed qualifications for Designation. In § 172.200, we proposed to tie QHIN status to meeting the requirements specified in § 172.201. We proposed that an Applicant QHIN (as we proposed to define it in § 172.102) would need to meet all requirements in § 172.201 to be

Designated,

and a QHIN would need to continue to meet all requirements in § 172.201 to

maintain its Designation.

We noted that the requirements we proposed in § 172.201 would be ongoing; a QHIN that does not meet those requirements at all times would be subject to suspension or termination, consistent with the regulations we proposed in subparts D and E of part 172. In the HTI-2 Proposed Rule, we stated that the continuing obligation to meet the requirements in § 172.201 would help to ensure the reliability of TEFCA Exchange and that QHINs could not maintain their status based on technology and standards that have become obsolete. Because the obligations would be ongoing, throughout this section we referred to Applicant QHINs as well as Designated QHINs as “QHINs” unless there was a need to differentiate.

As we explained in the HTI-2 Proposed Rule (89 FR 63645), the Designation qualifications proposed in § 172.201 described certain requirements for Designation. For an entity to become a QHIN, that entity must sign the Common Agreement, thus memorializing its agreement to the comprehensive Designation requirements—as well as other requirements—for trusted exchange under TEFCA. The comprehensive Designation requirements in the Common Agreement correspond to the proposed requirements included in this subpart.

In § 172.201, we proposed Designation requirements in three categories: (a) ownership; (b) exchange requirements; and (c) Designated Network Services.

In § 172.201(a), we proposed the ownership requirements. In § 172.201(a)(1), we proposed that a QHIN must be a U.S. Entity, as we proposed to define “U.S. Entity/Entities” in § 172.102. Under that proposed definition, a U.S. Entity must be a corporation, limited liability company, partnership, or other legal entity organized under the laws of a state or commonwealth of the United States or the Federal law of the United States, be subject to the jurisdiction of the United States and the state or commonwealth under which it was formed, and have its principal place of business be in the United States under Federal law. Additionally, we proposed that none of the entity's directors, officers, or executives, and none of the owners with a five percent (5%) or greater interest in the entity, may be listed on the

Specially Designated Nationals and Blocked Persons List

published by the United States Department of the Treasury's Office of Foreign Asset Control or on the Department of Health and Human Services, Office of Inspector General's List of Excluded Individuals/Entities. We explained that this requirement would help to promote organizational and operational policies that enable the exchange of health information among networks by ensuring that those who actually control the health information exchanged under these provisions are subject to U.S. laws, and it would help to avoid giving access to that information to actors whom the government has previously identified as national security or fraud risks.

We requested comment on whether the above approach, including the specific five percent (5%) threshold, will effectively limit access of bad actors trying to join TEFCA as a QHIN, or whether commenters believe the threshold should be a different percentage.

In § 172.201(a)(2), we proposed that an Applicant QHIN must not be under Foreign Control, which is a term we proposed to define in § 172.102. If, in the course of reviewing a QHIN application, ONC believes or has reason to believe the Applicant QHIN may be under Foreign Control, ONC would refer the case to the HHS Office of National Security (ONS) for review. If information available to ONS supports a determination of Foreign Control, ONS will notify ONC. An application will be denied if ONS notifies ONC that the Applicant is under Foreign Control.

Given the scale of the responsibilities that a Designated QHIN would have with respect to supporting health information exchange and the importance that healthcare data has to the critical infrastructure of our nation's health care system, we noted in the HTI-2 Proposed Rule that we believe that a QHIN should not be under Foreign Control. We stated we believe the requirements proposed in § 172.201(a)(1) and (2), in conjunction with the proposed definitions that those provisions reference, are necessary to ensure that all QHINs are subject to United States law and that compliance by QHINs is enforceable under United States law. Further, we stated these proposals are designed to strengthen the security of the network. We added in the HTI-2 Proposed Rule that we believe that the above proposals would promote organizational and operational policies that enable the exchange of health information among networks by minimizing the risk to TEFCA that may be posed by foreign state actors who wish to harm the United States, lessening the risks of subjecting QHINs to potentially conflicting foreign laws, and encouraging trust in the security of exchange under the system.

In the HTI-2 Proposed Rule (89 FR 63645), we noted that within the proposed definition of “U.S. Entity/Entities” in § 172.102, we proposed that for an entity seeking to become a QHIN to meet the definition, none of the entity's directors, officers, or executives, and none of the owners with a five percent (5%) or greater interest in the entity, can be listed on the

Specially Designated Nationals and Blocked Persons List

published by the United States Department of the Treasury's Office of Foreign Asset Control or on the Department of Health and Human Services, Office of Inspector General's List of Excluded Individuals/Entities. We also noted that we believe the five percent (5%) threshold strikes the right balance between protecting the security of the network from high-risk or known bad actors and achieving practical administrability of TEFCA. We noted individuals with less than five percent (5%) ownership in an entity would likely have limited means of influencing the actions of an entity connected to TEFCA. In the HTI-2 Proposed Rule, we stated we believe that entities—particularly those with a large number of shareholders—would face undue hardship without this sort of exception for small shareholders. In the HTI-2 Proposed Rule, we noted this regulation only would provide the standard that ONC would apply when evaluating QHINs; it would not supersede any stricter requirements imposed by other applicable laws, including, for example national security laws. It remains the responsibility of QHINs (and any other entity) to comply with all applicable laws.

In § 172.201(b), we proposed exchange requirements for QHINs. In the HTI-2 Proposed Rule, we stated we believe these exchange requirements are necessary to build a data sharing infrastructure that is private and secure and that meets all the requirements of PHSA section 3001(c)(9). We believe each of the exchange requirements below is important to the implementation and operationalization of TEFCA Exchange, as described in § 172.201, at scale. We proposed that an entity seeking to become a QHIN must, beginning at the time of application,

either directly or through the experience of its parent entity, meet certain exchange requirements, including: (1) be capable of exchanging information among more than two unaffiliated organizations; (2) be capable of exchanging all Required Information (as that term is defined in § 172.102); (3) be exchanging information for at least one of the Exchange Purposes (as that term is defined in § 172.102) authorized in the Common Agreement or an SOP(s); (4) be capable of receiving and responding to transactions from other QHINs for all Exchange Purposes; and (5) be capable of initiating transactions for the Exchange Purposes that such entity will permit its Participants and Subparticipants to use through TEFCA Exchange.

In the HTI-2 Proposed Rule we stated that, collectively, we believe these requirements are tailored to help ensure that a QHIN is capable of TEFCA Exchange, supports a trusted exchange framework, and maintains consistent practices of exchanging information at scale to support nationwide interoperability. The first requirement, proposed in § 172.201(b)(1), that the entity seeking to become a QHIN be capable of exchanging information among more than two unaffiliated organizations, is a requirement that would ensure a minimum technical ability exists and that exchange would be enabled beyond just the QHIN itself.

We discussed (89 FR 63646) that the second requirement, proposed in § 172.201(b)(2), is also a minimum condition, except it is directed at the minimum quantity of

data

a QHIN must be capable of exchanging. This proposed requirement would ensure that every QHIN can exchange Required Information (as that term is defined in proposed § 171.102) and provides certainty to Participants and Subparticipants who seek to join a QHIN that there is a minimum scope of data that they can reliably expect to be able to exchange via TEFCA Exchange Purposes.

The proposed requirements in § 172.201(b)(3) through (5) are intended to establish basic parameters and expectations for QHINs in order to qualify for Designation. We proposed, in § 172.201(b)(3), that a QHIN or Applicant QHIN must be exchanging information for at least one Exchange Purpose. If a QHIN is not exchanging information for at least one of the Exchange Purposes authorized under TEFCA (for examples, see the “Exchange Purpose” definition proposed in § 172.102) at the time of application, we noted in the HTI-2 Proposed Rule that it is not meeting a minimum condition necessary for such exchange to occur and cannot be Designated. While exchange for an Exchange Purpose under TEFCA requires an Exchange Purpose Code, Applicant QHINs can demonstrate that they are meeting the requirement to exchange information for at least one of the Exchange Purposes by conducting exchange for an Exchange Purpose without use of an Exchange Purpose Code.

We proposed in § 172.201(b)(4) to require a QHIN to be capable of receiving and responding to transactions from other QHINs for all Exchange Purposes, to ensure that health information can be exchanged among health information networks under TEFCA. For this same reason, we proposed in § 172.201(b)(5) to require a QHIN to be capable of initiating transactions for the Exchange Purposes that such entity will permit its Participants and Subparticipants to use through TEFCA Exchange. We noted that ensuring that QHINs will respond to Participant or Subparticipant requests for information, and that the Participants or Subparticipants are able to receive the information from QHINs, enables health information exchange among the QHINs, Participants and Subparticipants.

We noted in the HTI-2 Proposed Rule that a QHIN's ability to transact for all Exchange Purposes is a threshold requirement for an entity that seeks Designation and is essential for ensuring that the TEFCA framework facilitates exchange for each Exchange Purpose authorized in the Common Agreement or an SOP(s) for implementation. We also noted that, without this requirement, there would be no certainty that the TEFCA framework would advance exchange beyond the Treatment Exchange Purpose, which is the most prevalent purpose for health information exchange today and the purpose of use that most health care entities seeking Designation would be most familiar with. TEFCA's network connectivity—including this requirement that QHINs have the ability to exchange for all Exchange Purposes—and scale would help, for example, health care providers gain access to more comprehensive and complete information about their patients, which can support improved care, better outcomes, decreased provider burden, and reduced costs.

Entities performing TEFCA Exchange as described in § 172.201 would have the option to request information for all Exchange Purposes. At the time of publication of this final rule, TEFCA supports exchange for the following Exchange Purposes: treatment; payment; health care operations; public health; Individual Access Services (IAS), and government benefits determination. Over time, additional Exchange Purposes may be added. Information regarding whether responses are required for a given Exchange Purpose would be included in an SOP.

In § 172.201(c), we proposed that an Applicant QHIN must meet certain Designated Network Services requirements. Based on our experience in the health IT ecosystem, we noted that we believe adequate network performance is important for the success of TEFCA, as those participating in TEFCA Exchange would be most likely to trust the TEFCA infrastructure if it is performing at a high level. We also expressed that unreliable network performance would dilute confidence in the network and discourage participation.

In § 172.201(c)(1), we proposed that a QHIN must maintain the organizational infrastructure and legal authority to operate and govern its Designated Network. For instance, under this proposal, QHINs would be required to have a representative and participatory group or groups that approve the processes for fulfilling the TEFCA governance functions and that participate in governance for the Designated Network. In § 172.201(c)(2), we proposed that a QHIN must maintain adequate written policies and procedures to support meaningful TEFCA Exchange as described in § 172.201 and fulfill all responsibilities of a QHIN in the part (which an entity agrees to by signing the Common Agreement). For instance, under this proposal, QHINs would be required to have a detailed written policy that describes the oversight and control of the technical framework that enable TEFCA Exchange.

In § 172.201(c)(3), we proposed that a QHIN must maintain a Designated Network (as proposed to be defined in § 172.102) that can support a transaction volume that keeps pace with the demands of network users. We noted in the HTI-2 Proposed Rule that since TEFCA is a nationwide network and will be used daily to support various health data needs to inform care delivery, quality assessments, public health, and health care operations, QHINs must be capable of transacting high volumes of data reliably and at scale. In § 172.201(c)(4), we proposed that a QHIN must maintain the capacity to support secure technical connectivity and data exchange with other QHINs. One of the most fundamental aspects of interoperable network exchange is

technical connectivity, which makes network-to-network exchange possible and, therefore, was important to include in this regulation.

In § 172.201(c)(5) through (7), we proposed certain requirements related to governance for TEFCA to ensure all QHINs are aligned and able to manage risk effectively. In § 172.201(c)(5), we proposed that a QHIN must maintain an enforceable dispute resolution policy governing Participants in the Designated Network that permits Participants to reasonably, timely, and fairly adjudicate disputes that arise between each other, the QHIN, or other QHINs. This proposed requirement would afford flexibility to QHINs to establish their own dispute resolution process while ensuring the process is timely and fair. We expressed that disputes may arise for a variety of reasons, so the QHIN, as the entity overseeing its Participants, is best placed to handle such disputes in a way that minimizes disruptions for the rest of the network. Ensuring that a QHIN has such a dispute resolution policy would, therefore, likely minimize such disruptions.

Similarly, in § 172.201(c)(6), we proposed that a QHIN maintain an enforceable change management policy consistent with its responsibilities as a QHIN. A change management policy establishes the standard procedures to approve different types of changes to TEFCA documents (

e.g.,

standard operating procedures) and policies and will help to avoid changes that are disruptive or in conflict across entities.

In § 172.201(c)(7), we proposed that a QHIN must maintain a representative and participatory group or groups with the authority to approve processes for governing the Designated Network. We explained (89 FR 63647) that the participatory network governance built into the TEFCA infrastructure is important to ensure that the requisite engagement exists between QHINs, Participants, and Subparticipants engaged in TEFCA Exchange. In the HTI-2 Proposed Rule, we stated that we believe the above requirements are fundamental aspects of a network-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 § 172.201(c)(7) specifically, we emphasized that TEFCA uses a representative and participatory governance structure. Representative and participatory governance gives those participating in the network a role in informing the policies and decisions that ultimately would affect them. We explained that such a governance structure helps to motivate health care entities and their networks to voluntarily join TEFCA. We also noted that we believe that requiring a QHIN to have a representative and participatory group or groups that has the ability to review and provide input on the governance requirements of the QHIN's Designated Network is an optimal approach for this requirement.

In § 172.201(c)(8), we proposed that an entity seeking to become a QHIN must maintain privacy and security policies that permit the QHIN to support TEFCA Exchange. We identified certain policies that fell within this requirement (89 FR 63647), which we have slightly modified here for clarity and technical accuracy, and which included the following:

• Maintaining certification under a nationally recognized security framework by a qualified, independent third party that ensures its assessments are consistent with the NIST Cybersecurity Framework (CSF) (using both NIST 800-171 (Rev. 2) and NIST 800-53 (Rev. 5) as a reference), ensuring the QHIN performs HIPAA Security Rule risk analyses (as required by § 164.308(a)(1)(ii)(A)) and verifies all requirements for technical audits and assessments are met.

• Having a qualified, independent third party complete an annual security assessment consistent with the NIST Cybersecurity Framework (CSF) (using both NIST 800-171 (Rev. 2) and NIST 800-53 (Rev. 5) as a reference). The third party would review the QHIN for consistency with HIPAA Security Rule risk analysis requirements at § 164.308(a)(1)(ii)(A). Additionally, the annual security assessment must include comprehensive internet-facing penetration testing, must include an internal network vulnerability assessment, and must use methodologies and security controls consistent with Recognized Security Practices, as defined by Public Law 116-321 (42 U.S.C. 17931 and 300jj-52).

• Employing a Chief Information Security Officer with executive-level responsibility.

• Disclosing any breaches of electronic protected health information (including disclosure of any such breaches within the three (3) years preceding applying to become a QHIN) to the RCE and to all QHINs that are likely impacted.

• Complying with 45 CFR part 164, subparts A, C, and E, as applicable, as if the QHIN were a covered entity as described in that regulation.

• Maintaining and complying with a written privacy policy.

We noted in the HTI-2 Proposed Rule that these policies and requirements would provide privacy and security protections for the health information that will be exchanged through TEFCA. All entities that elect to participate in TEFCA, including entities that are not regulated under HIPAA, would be expected to meet a high bar for privacy and security given the nature of the data being exchanged. We stated that it is unlikely that an entity would wish to participate in a network without privacy and security standards, thereby inhibiting TEFCA exchange.

To further support the security of TEFCA, we proposed in § 172.201(c)(9) that a QHIN must maintain data breach response and management policies that support secure TEFCA Exchange. For instance, given the number of electronic connections TEFCA will support, a data breach response and management policy would support a transparent process and timely awareness of a data breach or other security events (

e.g.,

ransomware attacks) which could enable the QHIN to manage secure connectivity services without disrupting patient care.

In § 172.201(c)(10), we proposed that a QHIN must maintain adequate financial and personnel resources to support all its responsibilities as a QHIN, including, at a minimum, sufficient financial reserves or insurance-based cybersecurity coverage, or a combination of both. We noted in the HTI-2 Proposed Rule that this requirement would help to provide stability to TEFCA in the event of unexpected financial or economic occurrences—whether system-wide or specific to individual QHINs. For instance, we stated that this requirement could be met if the QHIN has available a minimum amount of cash, cash equivalents, borrowing arrangements (

e.g.,

a line of credit), or a mix of the three that is equal to six (6) calendar months of operating reserves. Regarding insurance requirements, a QHIN's general liability coverage and the cyber risk/technology coverage should each have limits of at least $2,000,000 per incident and $5,000,000 in the aggregate, which limits can be met through primary coverage, excess coverage, available internal funds, or a combination thereof. We noted that the requirements proposed herein may be insufficient for larger QHINs and recognized that certain QHINs will meet and exceed these minimums.

QHINs will be the central connection points for TEFCA Exchange, responsible for routing queries, responses, and messages among many participating entities and individuals. We proposed,

in § 172.201(c)(10), that QHINs must have sufficient financial resources and personnel capacity to perform such functions successfully. We also noted we believe that QHINs must be prepared to address incidents should they arise and must have the ability to fulfill potential liability obligations, either through insurance, sufficient financial reserves, or some combination of the two.

We stated that one goal of TEFCA is to support patients gathering their healthcare information. In § 172.202, “QHINS that offer individual access services,” we proposed IAS requirements for a QHIN to obtain and maintain Designation under TEFCA if that QHIN voluntarily offers IAS. In § 172.202(a), we proposed that a QHIN would be required to obtain express consent from any individual before providing IAS, as defined in § 172.102. We noted that we believe this is an important requirement so that individuals who use IAS that a QHIN offers are informed of the privacy and security practices that are being employed to protect their data. In § 172.202(b), we proposed that a QHIN would be required to make publicly available a privacy and security notice that meets minimum TEFCA privacy and security standards to support transparent exchange practices. We stated that we believe this requirement would provide transparency to all individuals who are considering using IAS regarding how their data is protected and secured by a QHIN providing IAS.

In § 172.202(c), we proposed a QHIN that is the IAS provider for an individual would be required to delete the individual's Individually Identifiable Information (as defined in § 172.102) maintained by the QHIN upon request by the individual except as prohibited by Applicable Law or where such information is contained in audit logs. We noted (89 FR 63648) that we believe this requirement would provide individuals with reassurance that they control access to their data. We also expressed that we believe the carve out for audit logs is appropriate because audit logs are generally used to provide chronological records of system activities and should not be deleted. In § 172.202(d), we proposed that a QHIN would be required to permit any individual to export in a computable format all of the individual's Individually Identifiable Information maintained by the QHIN as an IAS provider. We stated that we believe this requirement would ensure that individuals may access, control, and use their own data held by an IAS provider.

In § 172.202(e), we proposed that all Individually Identifiable Information the QHIN maintains must satisfy certain criteria, including: (1) all Individually Identifiable Information must be encrypted; (2) without unreasonable delay and in no case later than sixty (60) calendar days following discovery of the unauthorized acquisition, access, Disclosure, or Use of Individually Identifiable Information, the QHIN must notify, in plain language, each individual whose Individually Identifiable Information has been or is reasonably believed to have been affected by unauthorized acquisition, access, Disclosure, or Use involving the QHIN; and (3) a QHIN must have an agreement with a qualified, independent third-party credential service provider and must verify, through the credential service provider, the identities of individuals seeking IAS prior to the individuals' first use of such services and upon expiration of their credentials. We noted that to the extent the QHIN is already required by Applicable Law to notify an individual as described in proposed § 172.202(e)(2), we did not propose that it be required to duplicate such a notification. Lastly, the proposed requirement in § 172.202(e)(3) would set a baseline for proving the identity of IAS users that are requesting data via TEFCA Exchange.

Comments.

Multiple commenters expressed support for the provisions of this subpart that will establish the qualifications for HINs to receive and maintain Designation as a QHIN, including as an IAS provider. Multiple commenters also expressed support for the proposed qualification requirements. Other commenters cautioned that additional requirements of QHINs could limit entities from participating in TEFCA or deter them from considering becoming a QHIN.

Response.

We appreciate commenters' support for the proposed qualifications for QHIN Designation. We also understand commenters' caution to ASTP/ONC regarding additional requirements and appreciate the need within TEFCA to establish strong guardrails for QHIN participation while not unduly burdening Applicant QHINs and QHINs. We agree with commenters that additional requirements for QHINs are not, at this time, appropriate as we work to balance flexibility, participation, and our commitment to strong guardrails for QHIN participation. The current requirements were developed based on ASTP/ONC's and the RCE's collective experience with health information exchange and were informed by a wide range of interested communities and the public. As TEFCA evolves, we will continue to consider ways to strengthen it and ensure that QHINs are held to a high but reasonable standard. In this final rule, we have finalized all subpart B proposals without revision.

Comments.

One commenter asked whether any changes to the proposed QHIN designation process would be retroactively applicable to entities currently undergoing that process. Another commenter expressed support for the previous “sub-regulatory” approach for establishing criteria and requirements for QHIN Designation that allowed for flexibility. Some commenters also recommended new requirements. Commenters recommended aligning qualifications with existing Department of Homeland Security standards and/or FedRAMP certification standards for cybersecurity. Another commenter recommended background checks, validation of National Provider Identifiers (NPIs), and a rigorous review of organizational credentials. A separate commenter encouraged ASTP/ONC's continued emphasis on and improvement of security and privacy requirements. Another commenter recommended that we leverage QHIN qualification criteria to require that pharmacists, with an established treatment relationship with patients, have access to clinical data.

Response.

Regarding the question whether any changes to the proposed QHIN Designation process would be retroactively applicable to entities currently undergoing that process, we note that we are finalizing the QHIN Designation requirements and process within the HTI-2 Proposed Rule, and as discussed above, without revision in this final rule. The provisions will be effective upon the effective date specified for this final rule in the “effective date” section. The qualification requirements we have finalized in 45 CFR part 172, subpart B, align with and have no substantive differences from the requirements for and process followed by all Designated QHINs and Applicant QHINs.

We appreciate the comment in support of the previous sub-regulatory approach that we have utilized in TEFCA to this point to establish the processes within the TEFCA framework.

We appreciate the suggestions for updating the existing QHIN Designation requirements within the TEFCA framework (

e.g.,

aligning qualifications with existing Department of Homeland Security standards and/or FedRAMP certification standards for cybersecurity, improving privacy and security requirements, emphasis on background checks, validation of NPIs, and a

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

Onboarding and Designation Processes

In the HTI-2 Proposed Rule, we stated that (89 FR 63648) TEFCA establishes a universal floor for interoperability across the country through a network of networks. In 2019, ONC issued a Notice of Funding Opportunity and subsequently awarded a cooperative agreement to The Sequoia Project to serve as the RCE to support the implementation of TEFCA. In August 2023, ONC awarded The Sequoia Project a five-year contract to continue serving as the RCE.

To establish nationwide health information exchange, TEFCA calls for the Designation of QHINs—HINs that agree to the common policy, functional, and technical requirements for TEFCA Exchange. The QHIN Designation Requirements as described in § 172.201 define the baseline legal and technical requirements for secure information sharing on a nationwide scale—all under commonly agreed-to rules. Exchange through TEFCA simplifies connectivity and creates efficiency by establishing a standardized approach to exchange policies and technical frameworks.

Under the 2019 to 2023 cooperative agreement

and the current RCE contract,

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.

Notice of Funding Opportunity (NOFO)—Trusted Exchange Framework and Common Agreement—Recognized Coordination Entity (RCE) Cooperative Agreement,

https://www.healthit.gov/sites/default/files/facas/TEFCA%20NOFO_FINAL_508.pdf.

See USASPENDING.gov

https://www.usaspending.gov/award/CONT_AWD_75P00123C00019_7570_-NONE-_-NONE-.

In subpart C of part 172, we described the proposed QHIN Onboarding and Designation processes.

Onboarding,

as we proposed to define it in § 172.102, is the process a prospective QHIN must undergo to become a QHIN and become operational in the production

environment.

Designation,

as we proposed to define it in § 172.102, is the written determination that an Applicant QHIN has satisfied all regulatory requirements and is now a QHIN.

87 FR 2822.

87 FR 2818.

In § 172.300, we explained that subpart C of part 172 would es

This text is long and has been trimmed here. Open the source document for the complete record.

This is a copy of a public record, reproduced as it was published. It is not legal advice, and it may not be the version a court would rely on. Check the official source before you cite it.