2024-14975: Health Data, Technology, and Interoperability: Patient Engagement, Information Sharing, and Public Health Interoperability

2. Conditions and Maintenance of Certification Requirements--

Insights and Attestations a. Insights Condition and Maintenance of Certification Requirements b. Attestations Condition and Maintenance of Certification Requirements 3. Administrative Updates 4. Correction--Privacy and Security Certification Framework 5. Information Blocking Enhancements 6. Trusted Exchange Framework and Common AgreementTM C. Severability D. Costs and Benefits II. Background A. Statutory Basis 1. Standards, Implementation Specifications, and Certification Criteria

2. ONC Health IT Certification Program Rules

[[Page 63499]] B. Regulatory History III. ONC Health IT Certification Program Updates A. Standards and Implementations Specifications 1. National Technology Transfer and Advancement Act 2. Compliance with Adopted Standards and Implementation Specifications 3. ``Reasonably Available'' to Interested Parties B. New and Revised Standards and Certification Criteria 1. The United States Core Data for Interoperability Version 4 (USCDI v4) a. Background and USCDI v4 Update b. Certification Criteria that Reference USCDI 2. SMART App Launch 2.2 3. User-Access Brands and Endpoints 4. Standards for Encryption and Decryption of Electronic Health Information a. Background b. Proposal 5. Minimum Standards Code Sets Updates 6. New Imaging Requirements for Health IT Modules 7. Revised Clinical Information Reconciliation and Incorporation Criterion

10. Electronic Health Information (EHI) Export--Single Patient

EHI Export Exemption a. Background b. Proposal for EHI Export c. Proposal for Associated Assurances Requirements for Single Patient EHI Export Exemption

13. Health IT Modules Supporting Public Health Data Exchange

a. Background b. Regulatory History c. Proposal Overview d. Revised Certification Criteria for Health IT Modules Supporting Public Health Data Exchange e. New Certification Criteria for Health IT Modules Supporting Public Health Data Exchange f. New Standardized API for Public Health Data Exchange

15. New Requirements to Support Dynamic Client Registration

Protocol in the Program a. Background to Dynamic Client Registration b. Adoption of HL7 UDAP Security IG v1 c. Revision of Standardized API for Patient and Population Services to Support Dynamic Client Registration d. Removal of Reference to OpenID Connect Core Specification e. API Conditions and Maintenance Updates to Support Dynamic Client Registration

16. New Certification Criteria for Modular API Capabilities

a. Proposal Background b. Modular API Capabilities Certification Criteria

19. Revised Standardized API for Patient and Population Services

Criterion to Align with Modular API Capabilities a. Proposed Revisions for Registration b. Proposed Revisions for Patient and User Access c. Proposed Revisions for System Access d. Other Restructured Requirements e. Proposed Requirements for System Read and Search API, Subscriptions, and Workflow Triggers for Decision Support Interventions

20. Patient, Provider, and Payer APIs

a. Background on CMS Interoperability Rulemaking b. Proposal Overview c. Proposed Certification Criteria d. Revision and Addition of API Condition and Maintenance of Certification Requirements e. Revisions to Real World Testing Requirements f. Addition of Criteria to the Base EHR Definition

1. Insights Condition and Maintenance of Certification

Requirements a. Background b. Process for Reporting Updates c. Minimum Reporting Qualifications d. Measure Updates

2. Attestations Condition and Maintenance of Certification

Requirements D. Administrative Updates 1. Program Correspondence 2. ONC-Authorized Certification Bodies (ACB) Surveillance of Certain Maintenance of Certification Requirements a. Background and Proposal Summary b. Updates to Principles of Proper Conduct for Maintenance of Certification Requirements c. Updates to Surveillance for Maintenance of Certification Requirements

5. Exceptions That Involve Practices Related to Actors'

Participation in The Trusted Exchange Framework and Common Agreement\TM\ (TEFCA\TM\) a. Definitions b. TEFCATM Manner Exception V. Trusted Exchange Framework and Common Agreement\TM\ A. Subpart A--General Provisions B. Subpart B--Qualifications for Designation C. Subpart C--QHIN\TM\ Onboarding and Designation Processes D. Subpart D--Suspension E. Subpart E--Termination F. Subpart F--Review of RCE[supreg] or ONC Decisions G. Subpart G--QHINTM Attestation for the Adoption of the Trusted Exchange Framework and Common AgreementTM

A. Purpose of Regulatory Action

The Secretary of Health and Human Services has delegated responsibilities to the Office of the National Coordinator for Health Information Technology (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.\1\ ONC is responsible for 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; and requirements to keep or recognize a program or programs for the voluntary certification of health information technology. This proposed rule seeks to fulfill statutory requirements; provide transparency; advance equity, innovation, and interoperability; and support the access to, and exchange and use of, EHI. Transparency regarding healthcare information and activities--as well as the interoperability and electronic exchange of health information--are all in the best interest of the patient and are central to the efforts of the Department of Health and Human Services to enhance and protect the health and well-being of all Americans. --------------------------------------------------------------------------- \1\ 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. 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/. --------------------------------------------------------------------------- In addition to addressing the HITECH Act's and Cures Act's requirements described above and advancing interoperability, the proposed rule aligns with and supports Executive Orders (E.O.) 13994, 13985, 14036, and 14058. The President issued E.O. 13994 on January 21, 2021, to ensure a data-driven response to COVID-19 and future high- consequence public health threats. The Cures Act and the information blocking provisions in the 21st Century Cures Act: Interoperability, Information Blocking, and the ONC Health IT Certification Program (85 FR 25642) (ONC Cures Act Final Rule) have enabled critical steps to making data available across the healthcare system. The proposed rule proposes to adopt certification criteria to advance interoperability and support public health reporting and exchange. Because we recognize the need for greater interoperability of public health technology and access to more actionable data by public health authorities (PHA) and their partners, the proposed rule lays out a multi-pronged approach that takes advantage of, and builds upon, the various previous efforts to advance public health reporting, including advancements in HL7[supreg] Fast Healthcare Interoperability Resources-based (FHIR[supreg]) solutions and evolving standards related to public health interoperability. We have proposed this approach to allow for systems to mature and advance in an aligned fashion, reduce the need for manual workarounds and intervention, and lead to wider adoption of advanced standards-based capabilities. The proposed adoption of the United States Core Data for Interoperability Standard Version 4 (USCDI v4) would promote the establishment and use of interoperable data sets of EHI for interoperable health data exchange. As discussed in section III.B.1, USCDI v4 would facilitate the collection, access and exchange of data for use in public health and emergency response (e.g., the COVID-19 pandemic) by capturing and promoting the sharing of key data elements related to public health. The proposal to adopt a new certification criterion for standardized FHIR-based application programming interfaces (APIs) for public health reporting, as discussed in section III.B.13.f, reflects ONC's continued efforts to develop and standardize APIs and facilitate exchange of public health data between health care providers and public health agencies, to securely access EHI through the broader adoption of standardized APIs.\2\ \3\As discussed in section III.B, adopting USCDI v4 and the proposals in Sec. 170.315(g)(20) are intended to facilitate core public health missions including detecting and monitoring, investigating and responding, informing and disseminating, and being response-ready. We also expect our proposed changes to improve patient access to more complete, standardized, immunization information stored in certified health IT products. --------------------------------------------------------------------------- \2\ ONC. (2022, October 18). API Resource Guide. ONC Health IT Certification Program API Resource Guide. Retrieved March 16, 2023, from https://onc-healthit.github.io/api-resource-guide/. \3\ Section 4002 of the 21st Century Cures Act (Cures Act) established a condition of certification that requires health IT developers to publish application programming interfaces (APIs) that allow ``health information from such technology to be accessed, exchanged, and used without special effort through the use of [APIs] or successor technology or standards, as provided for under applicable law.'' The Cures Act's API Condition of Certification requirement also states that a developer must, through an API, ``provide access to all data elements of a patient's electronic health record to the extent permissible under applicable privacy laws.'' The API Conditions and Maintenance of Certification requirements and certification criteria are identified in 45 CFR part 170. --------------------------------------------------------------------------- We are committed to advancing health equity, and this proposed rule is consistent with E.O. 13985 of January 20, 2021, Advancing Racial Equity and Support for Underserved Communities Through the Federal Government.\4\ Section 1 of E.O. 13985 states that ``the Federal Government should pursue a comprehensive approach to advancing equity for all, including people of color and others who have been historically underserved, marginalized, and adversely affected by persistent poverty and inequality.'' Section 1 of E.O. 13985 also states that because ``advancing equity requires a systematic approach to embedding fairness in decision-making processes, executive departments and agencies must recognize and work to redress inequities in any policies and programs that serve as barriers to equal opportunity.'' We believe USCDI v4 and proposals in Sec. 170.315(f) and Sec. 170.315(g)(20) would not only support identifying and responding to public health threats, but also support advancing equity. As noted above, we propose to modify current certification [[Page 63501]] criteria in Sec. 170.315(f) and adopt new criteria in Sec. 170.315(f) for Health IT Modules supporting public health data exchange that would help increase the data shared between health care providers, laboratories, and PHAs, and would increase interoperability among the different systems in place at each entity. Our proposed changes focus on providing more complete patient-level information for contact tracing and further case investigation, patient outreach, direct care, and other clinical and public health activities. For example, some of the proposed standards would require the exchange of available patient demographic information, including race, ethnicity, sex, and contact information; and may allow PHAs to get more complete data when providers and laboratories have these data elements and can appropriately fill the fields. Additionally, if finalized as proposed, the adoption of USCDI v4 would update the USCDI standard to include new data elements under the Health Status Assessments, Medications, Allergies and Intolerances, Goals and Preferences, Encounter Information, Vital Signs, and Laboratory data classes, and a new data class, Facility Information, as discussed in section III.B.1 of this proposed rule. Expanding the data elements included in USCDI would increase the amount and type of data available to be used and exchanged through certified health IT. Our proposed standards update for public health and USCDI v4 could help capture more accurate and complete patient characteristics that are reflective of patient diversity and could potentially help data users address disparities in health outcomes for all patients, including those who may be marginalized and underrepresented. This could also support data users' abilities to identify, assess, and analyze gaps in care, which could in turn be used to inform and address the quality of healthcare through interventions and strategies. This could lead to better patient care, experiences, and health outcomes. --------------------------------------------------------------------------- \4\ United States, Executive Office of the President [Joseph Biden]. Executive Order 13985: Advancing Racial Equity and Support for Underserved Communities Through the Federal Government. Jan 20, 2021. 86 FR 7009 through 7013, https://www.federalregister.gov/documents/2021/01/25/2021-01753/advancing-racial-equity-and-support-for-underserved-communities-through-the-federal-government. --------------------------------------------------------------------------- As discussed in section III.B.1, the proposal to adopt USCDI v4 also supports the concept of ``health equity by design,'' where health equity considerations are identified and incorporated from the beginning and throughout the technology design, build, and implementation processes, and health equity strategies, tactics, and patterns are guiding principles for developers, enforced by technical architecture, and built into the technology at every layer. With every successive USCDI version supported by certified health IT, the capabilities and workflows included will help support equity and efforts to reduce disparities. President Biden's E.O. 14036, Promoting Competition in the American Economy,\5\ issued on July 9, 2021, established a whole-of-government effort to promote competition in the American economy and reaffirmed the policy stated in E.O. 13725 of April 15, 2016 (Steps to Increase Competition and Better Inform Consumers and Workers to Support Continued Growth of the American Economy).\6\ This proposed rule would foster competition by advancing foundational standards for certified API technology, which enable--through applications (apps) and without special effort--improved legally permissible sharing of EHI among clinicians, patients, researchers, and others. As described throughout the proposed rule, competition would be advanced through these improved API standards that can help individuals connect to their information and can help health care providers involved in the patient's care to securely access information. For example, these standards are designed to foster an ecosystem of new applications that can connect through the API technology to provide patients with improved electronic access to EHI and more choices in their health care providers. This is similar to how APIs have impacted other sectors of the economy, such as travel, banking, and commerce. --------------------------------------------------------------------------- \5\ United States, Executive Office of the President [Joseph Biden]. Executive Order 14036: Promoting Competition in the American Economy. Jul 9, 2021. 86 FR 36987 through36999, https://www.federalregister.gov/documents/2021/07/14/2021-15069/promoting-competition-in-the-american-economy. \6\ Federal Register: Steps to Increase Competition and Better Inform Consumers and Workers to Support Continued Growth of the American Economy. --------------------------------------------------------------------------- Further, as described in section IV of this proposed rule, we propose enhancements to support information sharing under the information blocking regulations and promote innovation and competition, while ensuring patients' privacy and access to care remain protected. As we have noted, addressing information blocking is critical for promoting innovation and competition in health IT and for the delivery of healthcare services to individuals, as discussed in both the ONC Cures Act Proposed (84 FR 7508) and Final (85 FR 25790 through 25791) Rules, and reiterated in the Health Data, Technology, and Interoperability: Certification Program Updates, Algorithm Transparency, and Information Sharing (HTI-1) Final Rule (89 FR 1192). Specifically, we described how the information blocking provisions provide a comprehensive response to the issues identified by empirical and economic research that suggested that information blocking may weaken competition, encourage consolidation, and create barriers to entry for developers of new and innovative applications and technologies that enable more effective uses of EHI to improve population health and the patient experience.\7\ We explained that the information blocking provision of the Public Health Service Act (PHSA) itself expressly addresses practices that impede innovation and advancements in EHI access, exchange, and use, including care delivery enabled by health IT (89 FR 1195, citing section 3022(a)(2) of the PHSA). Actors subject to the information blocking provisions may, among other practices, attempt to exploit their control over interoperability elements to create barriers to entry for competing technologies and services that offer greater value for health IT customers and users, provide new or improved capabilities, and enable more robust access, exchange, and use of EHI (85 FR 25820).\8\ Information blocking may also harm competition not just in health IT markets, but also in markets for healthcare services (85 FR 25820). In the ONC Cures Act Final Rule, we described practices that dominant market providers may leverage and use to control access and use of their technology, resulting in technical dependence and possibly leading to barriers to entry by would-be competitors, as well as making some market providers vulnerable to acquisition or inducement into arrangements that enhance the market power of incumbent providers to the detriment of consumers and purchasers [[Page 63502]] of healthcare services (85 FR 25820). The implementation of the new information blocking provisions proposed and discussed in section IV of this proposed rule would continue to promote innovation and support the lawful access, exchange, and use of EHI, while strengthening support for individuals' privacy and EHI sharing preferences. --------------------------------------------------------------------------- \7\ See, e.g., Martin Gaynor, Farzad Mostashari, and Paul B. Ginsberg, Making Health Care Markets Work: Competition Policy for Health Care, 16-17 (Apr. 2017), available at http://heinz.cmu.edu/news/news-detail/index.aspx?nid=3930; Diego A. Martinez et al., A Strategic Gaming Model For Health Information Exchange Markets, Health Care Mgmt. Science (Sept. 2016). (``[S]ome healthcare provider entities may be interfering with HIE across disparate and unaffiliated providers to gain market advantage.'') Niam Yaraghi, A Sustainable Business Model for Health Information Exchange Platforms: The Solution to Interoperability in Healthcare IT (2015), available at http://www.brookings.edu/research/papers/2015/01/30-sustainable-business-model-health-information-exchange-yaraghi; Thomas C. Tsai Ashish K. Jha, Hospital Consolidation, Competition, and Quality: Is Bigger Necessarily Better? 312 J. AM. MED. ASSOC. 29, 29 (2014). \8\ See also Martin Gaynor, Farzad Mostashari, and Paul B. Ginsberg, Making Health Care Markets Work: Competition Policy for Health Care, 16-17 (Apr. 2017), available at http://heinz.cmu.edu/news/news-detail/index.aspx?nid=3930. --------------------------------------------------------------------------- Lastly, in support of E.O. 14058, Transforming Federal Customer Experience and Service Delivery to Rebuild Trust in Government, issued on December 16, 2021, we are committed to advancing the equitable and effective delivery of services with a focus on the experience of individuals, health IT developers, and health care providers.\9\ The proposed rule supports the Department of Health and Human Services' agency-wide approach to electronic prior authorization that meets the Department's interoperability and burden reduction goals, such as reducing documentation requirements associated with completing prior authorization requests for payers.\10\ Proposed certification criteria would make available certified health IT that can enable payers contracting with the Federal government, such as Medicare Advantage plans, to meet Centers for Medicare & Medicaid Services (CMS) requirements for sharing information. Additionally, improving the equitable access, exchange, and use of EHI would help enable patient- centric care, which is expected to improve equity in health outcomes. This proposed rule further recognizes patient feedback and preferences in their care and how patients and their representatives may want to monitor and share EHI with relevant health care providers and entities. The health IT certification provisions of the proposed rule aim to reduce the burden associated with prior authorization processes, which can ensure that patients receive the care they need in a timely manner, lower administrative cost, and reduce the complexity of obtaining a prior authorization for health care providers and patients. Collectively, these provisions of the proposed rule help advance the equitable and effective delivery of services with a focus on the experience of individuals, health IT developers, and health care providers. --------------------------------------------------------------------------- \9\ United States, Executive Office of the President [Joseph Biden]. Executive Order 14058: Transforming Federal Customer Experience and Service Delivery To Rebuild Trust in Government. Dec 13, 2021. 86 FR 71357 through71366, https://www.federalregister.gov/documents/2021/12/16/2021-27380/transforming-federal-customer-experience-and-service-delivery-to-rebuild-trust-in-government. \10\ Strategy on Reducing Regulatory and Administrative Burden Relating to the Use of Health IT and EHRs (Burden Reduction Report), February 2020, pages 26-28, https://www.healthit.gov/sites/default/files/page/2020-02/BurdenReport_0.pdf. --------------------------------------------------------------------------- We also strive to further advance Federal agency coordination. ONC works with CMS to ensure that our certification criteria and standards support and complement CMS programs that reference ONC regulations, such as the Medicare Promoting Interoperability Program and the Promoting Interoperability performance category of the Merit-based Incentive Payment System (MIPS). In addition, a final rule titled ``Medicare and Medicaid Programs; Patient Protection and Affordable Care Act; Advancing Interoperability and Improving Prior Authorization Processes for Medicare Advantage Organizations, Medicaid Managed Care Plans, State Medicaid Agencies, Children's Health Insurance Program (CHIP) Agencies and CHIP Managed Care Entities, Issuers of Qualified Health Plans on the Federally-Facilitated Exchanges, Merit-Based Incentive Payment System (MIPS) Eligible Clinicians, and Eligible Hospitals and Critical Access Hospitals in the Medicare Promoting Interoperability Program'' (CMS Interoperability and Prior Authorization final rule, 89 FR 8758) appeared in the Federal Register on February 8, 2024, and included requirements for certain payers regulated by CMS to establish APIs that can facilitate electronic prior authorization processes by 2027 (89 FR 8919). CMS also finalized electronic prior authorization measures for eligible clinicians who participate in the Promoting Interoperability performance category of the MIPS; and eligible hospitals and critical access hospitals that participate in the Medicare Promoting Interoperability Program, beginning in the CY 2027 performance period and the EHR reporting period in CY 2027, respectively (89 FR 8760). In this proposed rule, we propose to adopt standards and establish certification criteria to facilitate electronic prior authorization using certified health IT, which providers can use to complete the required actions under the finalized measures. Lastly, we are committed to our continued, collaborative work with the Centers for Disease Control and Prevention (CDC) on improving public health data systems. The proposed updates to the ONC Health IT Certification Program's public health criteria and complementary public health criteria for PHA systems would support CDC's Data Modernization Initiative and Public Health Data Strategy.\11\ We believe these approaches would increase efficiency for delivery of services and programs, reduce confusion for participants in these programs, and better serve the public interest. --------------------------------------------------------------------------- \11\ Public_Health_Data_Strategy-final-P.pdf (cdc.gov). --------------------------------------------------------------------------- While this rulemaking does not propose to require entities to adopt any specific standards to ensure that their information and communication technology (ICT), including software, applications, websites, and electronic documents, is accessible for people with disabilities, entities covered by this rule may also be subject to applicable requirements of Federal nondiscrimination laws. For example, Section 504 of the Rehabilitation Act of 1973 (Section 504) prohibits recipients of Federal financial assistance from discriminating on the basis of disability by excluding people with disabilities from participation in, denying them the benefits of, or subjecting them to discrimination in their programs or activities. 29 U.S.C. 794. Section 1557 of the Patient Protection and Affordable Care Act (Section 1557) prohibits certain health programs and activities, including those receiving Federal financial assistance from HHS, from discriminating on the basis of race, color, national origin, sex, age, or disability by excluding them from participation in, denying them the benefits of, or subjecting them to discrimination in their health programs or activities. 42 U.S.C. 18116(a). Newly issued Section 504 regulations require recipients to ensure that web content and mobile apps that a recipient provides or makes available, directly or through contractual, licensing, or other arrangements, be readily accessible to and usable by individuals with disabilities, with some exceptions. See 89 FR 40066 and 45 CFR Secs. 84.82-.89(a). The rule requires technical accessibility standards that must be met on May 11, 2026, for entities with fifteen or more employees and May 10, 2027, for entities with fewer than fifteen employees unless the recipient can demonstrate that compliance with this section would result in a fundamental alteration in the nature of a program or activity or in undue financial and administrative burdens or unless an exception applies. 45 CFR Sec. 84.84(b); 84.85. Title III of the Americans with Disabilities Act (ADA) prohibits discrimination on the basis of disability in the full and equal enjoyment of places of public accommodation. 42 U.S.C. 12182. Title II of the ADA prohibits state and local government [[Page 63503]] entities from discriminating on the basis of disability by excluding people with disabilities from participation in, denying them the benefits of, or subjecting them to discrimination in their services, programs, or activities. 42 U.S.C. 12132. On April 24, 2024, the Department of Justice published regulations establishing specific requirements, including the adoption of specific technical standards, for making accessible the services, programs, and activities offered by State and local government entities through the web and mobile applications. 89 FR 31320. More generally, these statutes and their implementing regulations apply to programs, services and activities implemented through or with information and communications technology (ICT). In addition, the Section 1557 implementing regulation addresses ICT specifically, providing that covered entities, including health programs and activities that receive Federal financial assistance from HHS, shall ensure that their health programs or activities provided through ICT are accessible to individuals with disabilities, unless doing so would result in undue financial and administrative burdens or a fundamental alteration in the nature of the health programs or activities. 89 FR 37522 (May 6, 2024) (45 CFR 92.204).

1. ONC Health IT Certification Program Updates

a. New and Revised Standards and Certification Criteria i. The United States Core Data for Interoperability Version 4 (USCDI v4) The USCDI standard in Sec. 170.213 is a baseline set of data that can be commonly exchanged across care settings for a wide range of uses. Certain certification criteria in the ONC Health IT Certification Program (Program) currently require the use of one of the versions of the USCDI standard by in Sec. 170.213. We propose to update the USCDI standard in Sec. 170.213 by adding USCDI v4 and by establishing an expiration date of January 1, 2028, for USCDI v3 for purposes of the Program. We propose to add USCDI v4 in Sec. 170.213(c) and incorporate it by reference in Sec. 170.299. We propose that up to and including December 31, 2027, a Health IT Module certified to certification criteria referencing Sec. 170.213 may use either version of the standard. We propose that by January 1, 2028, a health IT developer of a Health IT Module certified to certification criteria referencing Sec. 170.213 must update its Health IT Module to USCDI v4 and provide the updated version to their customers in order to maintain certification of that Health IT Module. We propose that any Health IT Modules seeking certification to certification criteria referencing Sec. 170.213 on or after January 1, 2028, would need to be capable of exchanging the data elements that the USCDI v4 comprises. ii. SMART App Launch 2.2 As discussed in section III.B.2, we propose to adopt the HL7[supreg] FHIR[supreg] SMART Application Launch Framework Implementation Guide release 2.2.0 (SMART v2.2 Guide) in Sec. 170.215(c)(3). We propose that the adoption of the SMART v2 Guide in Sec. 170.215(c)(2) expires on January 1, 2028. We propose that a Health IT Module certified to criteria referencing the implementation specifications in Sec. 170.215(c) may use the SMART v1, SMART v2, or SMART v2.2 guides for the time period up to and including December 31, 2025. Then, by January 1, 2026, when the adoption of SMART v1 expires, a health IT developer of a Health IT Module certified to certification criteria referencing the implementation specifications in Sec. 170.215(c) must update its Health IT Module to either the SMART v2 or SMART v2.2 Guides and provide the updated version to its customers in order to maintain certification of that Health IT Module. Then, by January 1, 2028, when the adoption of the SMART v2 Guide expires, a health IT developer of a Health IT Module certified to certification criteria referencing the implementation specifications in Sec. 170.215(c) must update its Health IT Module to the SMART v2.2 Guide and provide the updated version to its customers in order to maintain certification of that Health IT Module. On and after January 1, 2028, we propose that any Health IT Modules seeking certification to certification criteria referencing the implementation specifications in Sec. 170.215(c), would need to be capable of supporting SMART v2.2 Guide functionality. iii. User-Access Brands and Endpoints We propose to adopt the User-access Brands and Endpoints (Brands) specification for our service base URL publication requirements, as explained in section III.B.3. This applies to our current service base URL publication requirements in Sec. 170.404(b)(2), where we propose to reorganize the criterion's paragraphs in a way that places existing service base URL requirements into Sec. 170.404(b)(2)(i) and (ii) and adds the new Brands requirement in Sec. 170.404(b)(2)(iii). We propose in our updated Sec. 170.404(b)(2)(iii) to require that, by January 1, 2028, service base URLs and related API Information Source details, including each organization's name, location, and facility identifier, must be published in an aggregate vendor-consolidated ``FHIR Bundle'' according to the Brands specification. Additionally, in our proposal to revise Sec. 170.404(b)(3) where we propose new requirements for the publication of API discovery details for payer network information, including service base URLs and API Information Source details, we propose to adopt Brands specification. iv. Standards for Encryption and Decryption of Electronic Health Information As discussed in section III.B.4, we propose to adopt the updated version of Annex A of the Federal Information Processing Standards (FIPS) 140-2 (Draft, October 12, 2021) in Sec. 170.210(a)(3) and incorporate it by reference in Sec. 170.299. We propose to add an expiration date of January 1, 2026, to the FIPS 140-2 (October 8, 2014) version of the standard presently adopted in Sec. 170.210(a)(2). We also propose to remove the standard found in Sec. 170.210(f), which is no longer referenced in any active certification criteria. Revising Sec. 170.210(a) by adding an expiration date in Sec. 170.210(a)(2) and a new version of the FIPS standard in Sec. 170.210(a)(3) would impact three certification criteria that currently reference the standard in Sec. 170.210(a)(2), including Sec. 170.315(d)(7) ``end- user device encryption;'' (d)(9) ``trusted connection;'' and (d)(12) ``encrypt authentication credentials.'' Note that we also propose to change the names of the certification criteria in Sec. 170.315(d)(7) and (d)(12) to ``health IT encryption'' and ``protect stored authentication credentials'' respectively, as discussed in sections III.B.11 and III.B.12 of this preamble. v. Minimum Standards Code Sets Updates Early in ONC's standards and certification rulemakings, we established a policy of adopting newer versions of ``minimum standards'' code sets that update frequently (e.g., 77 FR 54170 and 80 FR 62612). Adopting newer versions of these code sets enables improved interoperability and implementation of health IT with minimal additional burden. If adopted, newer versions of these minimum standards code sets would serve as the baseline for certification, and [[Page 63504]] developers of certified health IT would be able to use newer versions of these adopted standards on a voluntary basis. Because these code sets are updated frequently, we will consider whether it may be more appropriate to adopt a version of a minimum standards code set issued after publication of this proposed rule, but before publication of a final rule. In section III.B.5, we discuss our proposals to adopt newer versions of the following minimum standards code sets: Sec. 170.207(a)--Problems Sec. 170.207(c)--Laboratory tests Sec. 170.207(d)--Medications Sec. 170.207(e)--Immunizations Sec. 170.207(f)--Race and Ethnicity Sec. 170.207(n)--Sex Sec. 170.207(o)--Sexual orientation and gender information Sec. 170.207(p)--Social, psychological, and behavioral data vi. New Imaging Requirements for Health IT Modules We propose, as explained in section III.B.6, to revise the certification criteria adopted in Sec. 170.315(b)(1), (e)(1), (g)(9), and (g)(10) to include new certification requirements to support access, exchange, and use of diagnostic images via imaging links. However, we are not proposing a specific standard associated with the support of this functionality, and we note that this requirement can be met with a context-sensitive link to an external application which provides access to images and their associated narrative. We believe that this proposal, if finalized as proposed, will promote more consistent access to images for providers and patients. We propose that by January 1, 2028, a health IT developer of a Health IT Module certified to the certification criteria related to ``transitions of care'' in Sec. 170.315(b)(1), ``view, download, and transmit'' in Sec. 170.315(e)(1), ``application access--all data request,'' in Sec. 170.315(g)(9), and ``standardized API for patient and population services,'' in Sec. 170.315(g)(10) must update their Health IT Module and provide the updated version to their customers to maintain certification of that Health IT Module. vii. Revised Clinical Information Reconciliation and Incorporation Criterion We propose, as described in section III.B.7, a primary proposal and an alternative proposal for revising the ``clinical information reconciliation and incorporation'' certification criterion in Sec. 170.315(b)(2) to expand the number and types of data elements that Health IT Modules certified to this criterion would be required to reconcile and incorporate. Our primary proposal would require Health IT Modules certified to Sec. 170.315(b)(2) to be capable of reconciling and incorporating all USCDI data elements according to at least one of the versions of the USCDI standard specified in Sec. 170.213. Our alternative proposal would require Health IT Modules to reconcile and incorporate data elements from six additional USCDI data classes beyond the existing three data classes required as part of the current certification criterion's functionality. We also propose new functional requirements to enable user-driven automatic reconciliation and incorporation. We propose that by January 1, 2028, a health IT developer of a Health IT Module certified to the criterion in Sec. 170.315(b)(2) must update their Health IT Module and provide the updated version to their customers in order to maintain certification of that Health IT Module. We also propose that any Health IT Modules seeking certification for the criterion in Sec. 170.315(b)(2) on or after January 1, 2028, would need to be capable of supporting this functionality. viii. Revised Electronic Prescribing Certification Criterion We propose to incorporate the National Council for Prescription Drug Programs (NCPDP) SCRIPT standard \12\ version 2023011 in an updated version of the electronic prescribing certification criterion in Sec. 170.315(b)(3)(ii). Under this proposal, as described in section III.B.8 of this proposed rule, health IT developers may maintain health IT certification conformance with the current version of the criterion using NCPDP SCRIPT standard version 2017071 for the time period up to and including December 31, 2027. We propose that by January 1, 2028, a health IT developer of a Health IT Module certified to the criterion in Sec. 170.315(b)(3) must update the Health IT Module to use the NCPDP SCRIPT standard version 2023011 and provide that update to their customers in order to maintain certification of the Health IT Module. We propose that any Health IT Modules for which a health IT developer seeks certification to the criterion in Sec. 170.315(b)(3) on or after January 1, 2028, would need to be able to perform the required prescription-related electronic transaction in accordance with the NCPDP SCRIPT standard version 2023011. We also propose a series of updates to the transactions included in Sec. 170.315(b)(3)(ii) including removing transactions currently identified as optional for the certification criterion. --------------------------------------------------------------------------- \12\ See https://standards.ncpdp.org/. --------------------------------------------------------------------------- ix. New Real-Time Prescription Benefit Criterion Real-time prescription benefit tools empower providers and their patients to compare the patient-specific cost of a drug to the cost of a suitable alternative, compare prescription costs at different pharmacies, view information about out-of-pocket costs, and learn whether prior authorization for a specific drug is required. In order to implement section 119(b)(3) of the Consolidated Appropriations Act, 2021 (Pub. L. 116-260), as discussed in section III.B.9, we propose to establish a real-time prescription benefit certification criterion in Sec. 170.315(b)(4) based on the National Council for Prescription Drug Programs (NCPDP) Real-Time Prescription Benefit (RTPB) standard version 13. We also propose to include this certification criterion in the Base EHR definition in Sec. 170.102. x. Electronic Health Information (EHI) Export--Single Patient EHI Export Exemption As explained in section III.B.10, we propose to exempt Health IT Modules that act primarily as intermediaries between systems and, through integration, function without any direct human interaction from the requirement in Sec. 170.315(b)(10)(i)(B) to provide functionality without subsequent developer assistance to operate. We propose that this exemption proposed in Sec. 170.315(b)(10)(i)(F) would be available if the developer of such a Health IT Module receives fewer than ten requests in the immediately preceding calendar year for a single patient EHI export. Relatedly, we propose in Sec. 170.402(b)(2)(iii) that developers of certified health IT with Health IT Modules certified to Sec. 170.315(b)(10) that claim the exemption proposed in Sec. 170.315(b)(10)(i)(F) would need to report the number of requests for single patient EHI export on an annual basis to their ONC-Authorized Certification Bodies (ACBs) by March 1 of each calendar year beginning in 2028. xi. Revised End-User Device Encryption Criterion As discussed in section III.B.11, we propose to revise Sec. 170.315(d)(7) to include a new requirement that Health IT Modules certified to this criterion encrypt EHI stored server-side on and after January 1, 2026. To include this new requirement, we propose reorganizing the certification criterion's paragraphs in a way that places existing [[Page 63505]] end-user device encryption requirements into Sec. 170.315(d)(7)(i) and (d)(7)(ii) and adds the new server encryption requirement in Sec. 170.315(d)(7)(iii). Then, we propose placing the applicable proposed encryption standard and default settings requirements to both the end- user device and server encryption requirements into Sec. 170.315(d)(7)(iii) and (iv) respectively. We also propose to require that personally identifiable information must be encrypted in Health IT Modules certified to this revised certification criterion. Finally, we propose to change Sec. 170.315(d)(7) by renaming it to ``health IT encryption,'' to better describe the end-user and proposed server-side requirements together. xii. Revised Criterion for Encrypt Authentication Credentials As explained in section III.B.12, we propose to revise the ``encrypt authentication credentials'' certification criterion in Sec. 170.315(d)(12). We propose to revise the certification criterion by expiring our current ``yes'' or ``no'' attestation requirement and replacing it with a new requirement that Health IT Modules that store authentication credentials protect the confidentiality and integrity of its stored authentication credentials according to the Federal Information Processing Standards (FIPS) 140-2 (October 12, 2021) industry standard. We also propose to change the name of this certification criterion to ``protect stored authentication credentials,'' to better describe how we propose to revise the criterion. xiii. Health IT Modules Supporting Public Health Data Exchange Public health promotes and protects the health of all people and their communities. To accomplish this mission, public health authorities (PHAs) rely in part on public health information exchange, including data from healthcare facilities and providers, laboratories, schools, social and community service providers, and other data partners to acquire the information they need. However, PHAs often do not have access to--or, often, the ability to share--the data required to optimally address public health needs (emergent or otherwise) due to the lack of common standards utilized in the reported data, variable reporting requirements, limited interoperability of systems, or inadequate public health data infrastructure and technology. Considering the need for greater interoperability of public health technology and access to more actionable data by PHAs and their partners,\13\ as discussed in section III.B.13, we propose: to revise the Program's current certification criteria related to public health in Sec. 170.315(f), including referencing newer versions of respective exchange and vocabulary standards in the current Sec. 170.315(f) certification criteria (Sec. 170.315(f)(1)-(f)(7)); proposing two additional certification criteria for birth reporting (Sec. 170.315(f)(8)) and bi-directional exchange with a prescription drug monitoring program (PDMP) (Sec. 170.315(f)(9)); proposing new certification criteria for Health IT Modules supporting public health data exchange in Sec. 170.315(f)(21)-(25), (28) and (29); and, proposing a new certification criterion for a standardized FHIR[supreg]-based API for public health data exchange in Sec. 170.315(g)(20). The new certification criterion in Sec. 170.315(g)(20) would support ongoing and future development of public health FHIR IGs leveraging a core set of existing, modular, and extensible capabilities and standards. The standards referenced in the proposed Sec. 170.315(g)(20) certification criterion support FHIR capabilities such as API-based event notifications (i.e., FHIR Subscriptions), SMART App Launch, Bulk Data Export, and requirements for authorization and authentication, drawing on the Program's requirements for Health IT Modules certified to Sec. 170.315(g)(10). --------------------------------------------------------------------------- \13\ https://www.gao.gov/products/gao-22-106175. --------------------------------------------------------------------------- xiv. Bulk Data Enhancements We propose, as discussed in section III.B.14, to adopt the HL7[supreg] FHIR[supreg] Bulk Data Access v2.0.0: STU 2 implementation specification (Bulk v2 IG) in Sec. 170.215(d)(2). We also propose to require, in many of our proposed certification criteria that reference Sec. 170.215(d)(2), server support for the ``group export'' operation and a ``_type'' query parameter for performance improvement. We believe this proposal would better support interoperability with Health IT Modules certified to support FHIR Bulk Data Access and better enable performant exporting of complete sets of FHIR resources for pre-defined cohorts of patients. This would raise the floor from our current Bulk v1 IG requirements for certification, where we require support for the group export operation but do not require support for any of the optional query parameters in the IG. We believe that these new certification requirements, based on additional implementer clarifications included in the Bulk v2 IG, would provide meaningful improvements in the performance of Bulk APIs. Additionally, we welcome comment on the issues hindering the effective exchange of population data using Bulk FHIR APIs and additional steps ONC can take to help address those issues. xv. New Requirements To Support Dynamic Client Registration Protocol in the Program We propose, as explained in section III.B.15, to add requirements in the Program to support dynamic client registration and subsequent authentication and authorization for dynamically registered apps for patient-facing, user-facing, and system confidential applications. This includes adding requirements to the following in the Program: Sec. 170.315(g)(10) certification criterion Sec. 170.315(g)(20), (30), and (32)-(35) proposed certification criteria Sec. 170.315(j)(2), (5), (8), (11) proposed certification criteria API Conditions and Maintenance of Certification requirements in Sec. 170.404 We propose to adopt the HL7[supreg] Unified Data Access Profiles (UDAPTM) Security for Scalable Registration, Authentication, and Authorization Implementation Guide Release 1.0.0 implementation guide (UDAP Security IG v1), and we propose to require several specific sections of it to support requirements in the Program criteria listed above. This proposal would facilitate timelier patient, provider, and system access to health information using applications by providing a more uniform, standardized, and automated application registration pathway. xvi. New Certification Criteria for Modular API Capabilities We propose, as discussed in section III.B.16, to add a new category of certification criteria to Sec. 170.315 titled ``modular API capabilities'' in Sec. 170.315(j). Several proposals across this proposed rulemaking would establish capabilities necessary to support standardized APIs across clinical, public health, administrative, and other use cases. We propose that the certification criteria in Sec. 170.315(j) would represent API capabilities that are standards-based, including through new standards, such as HL7[supreg] Clinical Decision Support (CDS) Hooks, SMART Health Cards, and HL7 FHIR[supreg] Subscriptions, as well as standards and functionalities historically referenced in Sec. 170.315(g)(10). These modular API capabilities would be referenced and incorporated into Health IT Modules to support standardized APIs for clinical use cases in Sec. 170.315(g)(10), public [[Page 63506]] health use cases in Sec. 170.315(g)(20), and health insurance and coverage use cases in Sec. 170.315(g)(30)-(36), as well as other future use cases across the health IT landscape. xvii. Multi-Factor Authentication Criterion As explained in section III.B.17, we propose to revise the ``multi- factor authentication'' (MFA) certification criterion in Sec. 170.315(d)(13) and accordingly update the privacy and security (P&S) certification framework in Sec. 170.550(h). The proposed update would revise our MFA certification criterion by replacing our current ``yes'' or ``no'' attestation requirement with a specific requirement to support multi-factor authentication and configuration for three certification criteria on and after January 1, 2028. We propose to apply the updated MFA requirements by revising each of the certification criteria in Sec. 170.315(b)(3), (e)(1), (g)(10), and (g)(30) to require that a Health IT Module certified to these criteria also be certified to Sec. 170.315(d)(13)(ii) on and after January 1, 2028. Given our proposal to embed Sec. 170.315(d)(13) references into each applicable certification criterion, Sec. 170.315(d)(13) does not need to be referenced again in Sec. 170.550(h)(3), therefore, we propose to expire all the references to Sec. 170.315(d)(13) in Sec. 170.550(h)(3) by December 31, 2027. We believe these updates would match industry best practices for information security, particularly for important authentication use cases in certified health IT. xviii. Revised Computerized Provider Order Entry--Laboratory Criterion We propose, as discussed in section III.B.18, to update the ``computerized provider order entry--laboratory'' certification criterion in Sec. 170.315(a)(2) to require enabling a user to create and transmit laboratory orders electronically according to the standard proposed in Sec. 170.205(g)(2), the HL7[supreg] Laboratory Order Interface (LOI) Implementation Guide (IG). We further propose to update Sec. 170.315(a)(2) to require technology to receive and validate laboratory results according to the standard proposed in Sec. 170.205(g)(3), the HL7[supreg] Laboratory Results Interface (LRI) IG. Ensuring that systems creating laboratory orders can transmit orders and receive associated results and values electronically, according to national standards, would create more complete patient information available to clinicians throughout the laboratory workflow. We propose that by January 1, 2028, a health IT developer of a Health IT Module certified to the criterion in Sec. 170.315(a)(2) must update its Health IT Module and provide the updated version to its customers in order to maintain certification of that Health IT Module. We propose that any Health IT Modules seeking certification for the criterion in Sec. 170.315(a)(2) on or after January 1, 2028, would need to be capable of supporting this functionality. xix. Revised Standardized API for Patient and Population Services Criterion To Align With Modular API Capabilities As discussed in section III.B.19, we propose to revise the certification criterion in Sec. 170.315(g)(10) to reorganize requirements to improve clarity and align with new proposals in this rule, including proposed: restructuring of existing requirements to reference the ``modular API capabilities'' certification criteria proposed in Sec. 170.315(j) support for dynamic registration and subsequent authentication and authorization of patient-facing, user-facing, and system confidential apps support for multi-factor authentication for patient-facing authentication according to requirements proposed in Sec. 170.315(d)(13)(ii) support for imaging links in data response requirements support for a read and search API for system apps support for ``_type'' query parameter for Bulk FHIR API support for the issuance of verifiable health records as specified by the requirements proposed in Sec. 170.315(j)(22) support for subscriptions as a server according to the requirements specified in proposed Sec. 170.315(j)(23) support for workflow triggers for decision support interventions according to the requirements specified in proposed Sec. 170.315(j)(20) support for authorization revocation for users (e.g., clinicians) moving of the API documentation requirements in Sec. 170.315(g)(10) to the API Conditions and Maintenance of Certification requirements in Sec. 170.404 We propose that by January 1, 2028, a health IT developer of a Health IT Module certified to the criterion in Sec. 170.315(g)(10) must update its Health IT Module and provide the updated version to its customers in order to maintain certification of that Health IT Module. We propose that any Health IT Modules seeking certification for the criterion in Sec. 170.315(g)(10) on or after January 1, 2028, would be to the updated version of the certification criterion. xx. Patient, Provider, and Payer APIs The combined exchange of clinical and administrative data among healthcare payers, patients, and providers is a complex challenge that can prevent participants in the healthcare system from gaining insights into the full picture of an individual's care. In order to realize the benefits of a more unified stream of clinical and administrative data, patients and health care providers must be able to more efficiently access and exchange EHI with the entities that steward this information, especially healthcare payers. In the CMS Interoperability and Patient Access Final Rule (85 FR 25510), which appeared in the Federal Register on May 1, 2020, and the CMS Interoperability and Prior Authorization Final Rule (89 FR 8758), which appeared in the Federal Register on February 8, 2024, CMS finalized policies for certain healthcare payers that it regulates \14\ to facilitate patient access to clinical and administrative data held by payers; availability of information about provider networks; exchange of information between payers when beneficiaries patients change coverage; provider access to data held by payers; and electronic prior authorization. --------------------------------------------------------------------------- \14\ The ``impacted payers'' under the CMS Interoperability and Patient Access Final Rule (85 FR 25510) and the CMS Interoperability and Prior Authorization Final Rule (89 FR 8758) are Medicare Advantage (MA) organizations, state Medicaid fee-for-service (FFS) programs, state Children's Health Insurance Program (CHIP) FFS programs, Medicaid managed care plans, CHIP managed care entities, and Qualified Health Plan (QHP) issuers on the Federally-facilitated Exchanges (FFEs). --------------------------------------------------------------------------- As explained in section III.B.20, we propose a set of certification criteria in Sec. 170.315(g)(30) through (36) that aim to complement and advance the policies that CMS has developed to increase patient, provider, and payer access to information. Health IT developers, including those that support payers, would be able to ensure that Health IT Modules certified to these proposed criteria, when used to satisfy the CMS requirements, have been tested for conformance with widely available industry standards designed to support interoperability for each use case. We propose to adopt a set of HL7[supreg] FHIR[supreg] IGs in Sec. 170.215 to support these certification criteria, and to incorporate these specifications by reference in Sec. 170.299. [[Page 63507]]

2. Conditions and Maintenance of Certification Requirements--Insights

and Attestations a. Insights Condition and Maintenance of Certification Requirements As discussed in section III.C.1, we propose to update the Insights Condition by requiring health IT developers to include health care provider identifiers, for providers included in the data submitted in response for the measures specified in Sec. 170.407, to allow us to better interpret the results of the data received. We also propose updates to the overall process for reporting and newer versions of certified health IT for responses submitted under the Insights Condition in Sec. 170.407(b). We also propose to update two measures under the Insights Condition. We propose to revise the ``individuals' access to electronic health information through certified health IT'' measure in Sec. 170.407(a)(3)(i) to include both individuals and individuals' authorized representatives accessing their EHI. Additionally, we propose to revise the name of the measure in Sec. 170.407(a)(3)(ii) to ``C-CDA reconciliation and incorporation through certified health IT'' and propose to require developers to submit responses on specific data classes and elements from C-CDA documents reconciled and incorporated both through manual and automated processes in Sec. 170.407(a)(3)(ii)(E). We also intend to make various technical updates to the measure specification sheets accompanying the Insights Condition, including the clarification of certain definitions and terms, as well as adding new metrics. b. Attestations Condition and Maintenance of Certification Requirements As discussed in section III.C.2, we propose to revise the Attestations Condition and Maintenance of Certification requirements by adding the requirement in Sec. 170.406(a)(2) that a health IT developer, as a Condition of Certification, attest to compliance with Sec. 170.402(b)(4), if the health IT developer certified a Health IT Module(s) to the ``decision support interventions'' certification criteria in Sec. 170.315(b)(11).

3. Administrative Updates

As discussed in section III.D.1, we propose to revise the Program correspondence provision (Sec. 170.505) to explicitly specify when applicants for ONC-Authorized Testing Laboratory (ATL) status, applicants for ONC-ACB status, ONC-ACBs, ONC-ATLs, health IT developers or any other party to a proceeding under subpart E of 45 CFR part 170 will be considered to have received correspondence or other written communication from ONC or the National Coordinator. As discussed in section III.D.2, we propose to expand ONC-ACBs responsibilities under Sec. 170.556 for conducting surveillance of developers' satisfaction of certain Maintenance of Certification requirements under the Program. We also propose new and revised principles of proper conduct (PoPCs) in Sec. 170.523 to support the proposed expanded surveillance responsibilities. Specifically, an ONC- ACB would be required to monitor Program-participating developers' satisfaction of specific requirements applicable to the developers under subpart D of 45 CFR part 170, report results of these surveillance activities to ONC, and engage with developers where applicable to encourage corrective action for identified non- conformities. A new proposed PoPC in Sec. 170.523(x), pursuant to a new proposed requirement in Sec. 170.556(d)(7)(ii), would require ONC- ACBs to report to ONC when a developer fails to establish or to successfully complete an appropriate corrective action plan (CAP) for a Maintenance of Certification non-conformity identified by an ONC-ACB. To increase efficiency for developers' documentation of their CAPs, and ONC-ACBs' review and monitoring of these plans, we propose in Sec. 170.556(d)(3) to tailor the minimum required CAP elements based on the non-conformities addressed by the CAP. For example, certain CAP elements designed for non-conformities with certification criteria in 45 CFR subpart C would not be required by regulation in a CAP specific to a developer having missed a deadline in subpart D, such as for submission of real world testing documents (Sec. 170.405) or submission of attestations (Sec. 170.406). As discussed in section III.D.3, we propose a requirement in Sec. 170.523(m)(6) for ONC-ACBs, beginning January 1, 2027, to obtain a regular reporting of API discovery details, including service base URLs and related organization details, that are required by Sec. 170.404(b)(2) and (b)(3). In section III.D.4, we propose a new PoPC for ONC-ACBs in Sec. 170.523(y) requiring an ONC-ACB to give the National Coordinator sufficient notice of its intent to withdraw its authorization under the Program. In section III.D.5, we discuss our proposal to update the ONC direct review regulatory framework in 45 CFR 170.580 to align with the proposed enhancements to the ONC-ACBs' role in surveillance of Program- participating developers' satisfaction of certain Maintenance of Certification requirements. To enhance efficiency for developers and ONC, we propose to revise direct review CAP regulatory requirements to add flexibility to tailor the minimum elements the developer must address in such a plan for a non-conformity substantiated through an ONC direct review. We also propose procedural revisions to Sec. 170.581, suspension and termination of certification procedures in Sec. 170.580(d) and (f), and hearing officer and appeals provisions in Sec. 170.580(g)(5) and (7)(ii), to clarify that certain ``ONC'' decisions are in fact made by the National Coordinator, and explicitly provide for the Secretary to choose to exercise direct oversight of certain National Coordinator and hearing officer decisions before the decisions become final. We also propose to revise wording throughout 45 CFR 170.580 and 45 CFR 170.581 to clarify that certain determinations are made by the National Coordinator (who is appointed by the Secretary) rather than more generally by or within the Office of the National Coordinator (the organizational unit headed by the National Coordinator). As discussed in section III.D.6, we propose to update paragraphs (a) and (b) of the certification ban provisions in Sec. 170.581 to explicitly provide for the Secretary to review, at the Secretary's discretion, the National Coordinator's determination to impose a certification ban before the ban becomes effective. In section III.D.7, we propose to remove the ``Complete EHR'' and ``EHR Module'' terms from certain sections within subpart E of 45 CFR part 170. As discussed in section III.D.8, we propose to codify a definition of serious risk to public health or safety for purposes of Program regulations in 45 CFR part 170. This definition would enhance understanding among developers and users of certified health IT of the types of conditions, events, or phenomena that would constitute a dangerous non-conformity to Program requirements if caused (or contributed to) by a product certified under the Program, even if the Health IT Modules within such product continued to pass lab testing procedures, in-the-field surveillance testing, or both with respect to the technical standards and certification criteria adopted in subparts B and C of part 170. As discussed in section III.D.9, we propose to remove Sec. 170.550(m) ``time-limited certification and certification status for certain 2015 Edition certification criteria'' and to [[Page 63508]] remove certification criteria with time-limited certification and certification status, including Sec. 170.315(a)(10), (a)(13), (b)(6), (e)(2), and (g)(8). Additionally, as discussed in section III.D.9, we propose to revise Sec. 170.315(b)(7) and (b)(8) to remove Sec. 170.315(b)(7)(ii) and (b)(8)(i)(B), which were time-limited provisions (now expired) that permitted health IT to demonstrate security tagging of Consolidated-Clinical Document Architecture (C-CDA) documents at the document level. In section III.D.10, we propose to revise Sec. 170.550(h), the Privacy and Security Certification Framework requirements by adding the certification criterion ``decision support interventions'' in Sec. 170.315(b)(11) to the list of certification criteria in Sec. 170.550(h)(3)(ii).

4. Correction--Privacy and Security Certification Framework

We propose to make a correction to the Privacy and Security Certification Framework in Sec. 170.550(h), as discussed in section III.E. We revised Sec. 170.550(h) in the ONC Cures Act Final Rule but intended for Sec. 170.550(h)(4) to remain unchanged. However, when we drafted the amendatory instructions, we erroneously included the instruction to revise all of paragraph (h) (85 FR 25952). Therefore, when the Code of Federal Regulations was updated, Sec. 170.550(h)(4) was removed. We now propose to add the Sec. 170.550(h)(4) that existed prior to the ONC Cures Act Final Rule being finalized.

5. Information Blocking Enhancements

In this rule, we propose revisions to defined terms for purposes of the information blocking regulations, which appear in 45 CFR 171.102. We propose to revise three existing exceptions in subpart B of 45 CFR part 171 and solicit comment on potential revisions to one exception in subpart D. We propose two new exceptions, one in each in subparts B and C of part 171. We propose to codify in Sec. 171.401 definitions of certain terms relevant to the Trusted Exchange Framework and Common Agreement\TM\ (TEFCA\TM\) and in Sec. 171.104 descriptions of certain practices that constitute interference with the access, exchange, and use of electronic health information (EHI). As discussed in section IV.A.1, we propose to amend the definition of ``health care provider,'' codified in 45 CFR 171.10,2 so that it is explicitly clear that it references 42 U.S.C. 300jj(3) and that for purposes of this definition the terms ``laboratory'' and ``pharmacist'' have the meanings established for these terms in 42 U.S.C. 300jj(10) and (12), respectively. In IV.A.2, we propose that for purposes of the information blocking regulations in 45 CFR part 171 both ``health information technology'' and its shorter form, ``health IT,'' have the same meaning as ``health information technology'' in 42 U.S.C. 300jj(5). For purposes of the information blocking definition (Sec. 171.103), the term ``interfere with or interference'' is currently defined in Sec. 171.102. Informed by the concerns and questions that interested parties have brought to our attention, we propose in section IV.A.3 to add a section (Sec. 171.104) to the information blocking regulations that would codify certain practices (acts and omissions) that constitute interferences for purposes of the information blocking definition (codified in Sec. 171.103). The proposed codified practices are not an exhaustive list; additional practices not described in the proposed Sec. 171.104 that are likely to interfere with, prevent, or materially discourage access, exchange, or use of EHI may also be considered to rise to the level of an interference. The proposed codification of these specific practices is intended to provide actors, and those who seek to engage in EHI access, exchange, or use with actors, certainty that these specific practices constitute interference. The codification of these practices may also help regulated entities and other interested parties to consider the likelihood that any practice an actor might contemplate or engage in may also meet the definition of ``interference'' and ``interfere with'' (as defined in Sec. 171.102) for purposes of the information blocking regulations (45 CFR part 171). For purposes of the information blocking Privacy Exception, the term ``individual'' is defined in Sec. 171.202(a)(2). As currently worded, this text includes cross-references to incorrect citations within Sec. 171.202(a)(2). The text also includes one unnecessary cross-reference citation within Sec. 171.202(a)(2). We do not propose to change the substance of the definition, but in section IV.B.1.a, we propose technical corrections to the cross-reference citations within Sec. 171.202(a)(2)(iii), (iv), and (v). In section IV.B.1.b, to clearly establish coverage of the Sec. 171.202(d) sub-exception for all actors' practices under the same requirements, we propose to change the name of the sub-exception to: ``interfering with individual access based on unreviewable grounds.'' This proposed change to the header text is intended to express the expansion of its availability to actors who are not Health Insurance Portability and Accountability Act of 1996 (HIPAA) covered entities or business associates (as defined in 45 CFR 160.103). As explained in section IV.B.1.c, we propose to slightly modify the header of Sec. 171.202(e) for ease of reference to ``Individual's request not to share EHI.'' More importantly, we propose to revise the Sec. 171.202(e) sub- exception to remove the existing limitation that allows the exception to be used only for individual-requested restrictions on EHI sharing that are permitted by other applicable law. The proposal would extend the availability of the Sec. 171.202(e) sub-exception to an actor's practice of applying restrictions the individual has requested on the access, exchange, or use of an individual's EHI even when the actor may have concern that another law applicable to some or all of the actor's operations could compel the actor to provide access, exchange, or use of EHI contrary to the individual's expressed wishes. We propose, as discussed in section IV.B.2, revisions to three conditions of the Infeasibility Exception (45 CFR 171.204). Specifically, we propose to modify the Sec. 171.204(a)(2) segmentation condition to enhance clarity and certainty, and to provide for its application to additional specific situations. We propose to revise the condition to specifically cross-reference additional information blocking exceptions under which an actor may choose to withhold EHI that the actor could, under applicable law, make available. We propose to modify the Sec. 171.204(a)(3) third party seeking modification use condition by changing the words ``health care provider'' to ``covered entity as defined in 45 CFR 160.103'' in the exclusion from applicability of this condition. We also propose in Sec. 171.204(a)(3)(ii) to extend the exclusion from applicability of the third party seeking modification use condition requests for modification use from health care providers, as defined in Sec. 171.102 and who are not covered entities, requesting such use from actors whose activities would make them a business associate of that same health care provider if the healthcare provider (actor) was covered by HIPAA. We propose to modify the Sec. 171.204(b) responding to requests condition by establishing different timeframes for sending written responses to the requestor based on the Sec. 171.204(a) condition under which fulfilling the requested access, exchange, or use of EHI is infeasible. The proposed revision would retain the requirement that actors communicate to requestors ``in writing the reason(s) why the request is infeasible'' that we [[Page 63509]] finalized in the ONC Cures Act Final Rule. We discuss these proposals further in sections IV.B.2.a through c of this proposed rule. In section IV.B.3, we propose a new Protecting Care Access Exception that would, under specified conditions (see sections IV.B.3.b through d and the draft regulatory text of proposed Sec. 171.206), apply to acts or omissions likely to interfere with access, exchange, or use of particular EHI that an actor believes could create a risk of exposing patients, care providers, and other persons who assist in access or delivery of health care to potential administrative, civil, or criminal investigations or other actions on certain bases. A summary of these bases follows below in this section. (Please see section IV.B.3 of this proposed rule for detailed discussion.) The proposed Protecting Care Access Exception (Sec. 171.206) would be a new exception in addition to the other information blocking exceptions. The proposed new exception is designed to create certainty for actors that certain practices for which no other exception would apply will not be considered ``information blocking'' under the information blocking statute (PHSA section 3022) and regulations (45 CFR part 171). Like any existing or proposed information blocking exception in 45 CFR part 171, the proposed Protecting Care Access Exception (Sec. 171.206) is not intended to override any provision of another law that is independently applicable to the actor. The practices that the proposed Protecting Care Access Exception (Sec. 171.206) would except from the information blocking definition would be those implemented based on the actor's good faith belief that sharing EHI indicating that any person(s) sought, received, provided, or facilitated the provision or receipt of reproductive health care that was lawful under the circumstances in which it was provided could result in a risk of potential exposure to legal action for those persons and that the risk could be reduced by practices likely to interfere with particular access, exchange, or use of specific EHI. For purposes of the Protecting Care Access Exception, we propose to rely on the same definition of ``reproductive health care'' (which can be found in 45 CFR 160.103) that is used for purposes of the HIPAA regulations. In addition, we discuss in section IV.B.3.b how we would interpret whether care is ``lawful under the circumstances in which it is provided.'' To satisfy the proposed new Protecting Care Access (Sec. 171.206) Exception, an actor's practice would need to satisfy the threshold condition (Sec. 171.206(a)), and at least one of the other two conditions in the exception: the patient protection condition (Sec. 171.206(b)) or the care access condition (Sec. 171.206(c)). The combination of conditions required to satisfy the proposed new Protecting Care Access Exception and the definition of ``legal action'' (in Sec. 171.206(d)) for purposes of the exception would, together, ensure that the exception would not apply to an actor's attempts to shield any person from legal action based on allegations that health care items or services the person provided are substandard. These provisions together would also ensure that the exception focuses on the specific situation where an actor limits the sharing of EHI because the actor believes it could result in a risk of potentially exposing the patient or another person to an investigation or other civil, criminal, or administrative action based on the mere fact that the person sought, obtained, provided, or facilitated reproductive health care that was lawful under the circumstances in which it was provided. For instance, the exception would not apply to an actor's attempt to interfere with EHI sharing in order to reduce a patient's or other person's risk of exposure to a criminal investigation or charges not related to the act of seeking, obtaining, providing, or facilitating reproductive health care. For example, the act of not sharing information because of the risk of a criminal investigation related to operating a vehicle while intoxicated or committing fraud would not be covered under this exception. The Protecting Care Access Exception's threshold condition (Sec. 171.206(a)), proposed in section IV.B.3.b, includes requirements that the practice be: undertaken based on the actor's belief as specified in Sec. 171.206(a)(1), no broader than necessary as specified in Sec. 171.206(a)(2), and be implemented consistent with a written organizational policy or case-by-case determination contemporaneously documented in writing as specified in Sec. 171.206(a)(3). Meeting the threshold condition would be necessary, but not alone sufficient, for an actor's practice to be covered by the proposed Protecting Care Access (Sec. 171.206) exception. To satisfy the exception, any actor's practice likely to interfere with access, exchange, or use of EHI would also need to satisfy at least one of the other two conditions (in paragraphs (b) and (c)) of the proposed exception. In section IV.B.3.c, we propose a patient protection condition (Sec. 171.206(b)), that can be met by practices implemented by the actor for the purpose of reducing a risk of potential legal action that the actor believes a patient could otherwise face because the EHI shows or invites a reasonable inference that the patient has or has done any of the following (see proposed Sec. 171.206(b)(1)): (i) obtained reproductive health care that was lawful under the circumstances in which it was provided; (ii) Inquired about or expressed an interest in seeking reproductive health care; or (iii) Particular demographic characteristics or any health condition(s) or history for which reproductive health care is often sought, obtained, or medically indicated. The proposed patient protection condition would specify (Sec. 171.206(b)(2)) that to meet the condition the actor's practice must be subject to nullification by explicit request or directive from the patient. We also clarify (in proposed Sec. 171.206(b)(3)) that for purposes of the patient protection condition's other paragraphs that ``patient'' means the natural person who is the subject of the EHI or another natural person referenced in, or identifiable from, the EHI as having sought or received reproductive health care.\15\ --------------------------------------------------------------------------- \15\ The definition of ``person'' for purposes of 45 CFR part 171 is codified in Sec. 171.102 and is, by cross-reference to 45 CFR 160.103, the same definition used for purposes of the HIPAA Privacy Rule (45 CFR part 160 and subpart E of 45 CFR part 164). The Sec. 160.103 definition of ``person'' clarifies the meaning of ``natural person'' within it. We use ``natural person'' in this proposed rule with that same meaning. --------------------------------------------------------------------------- In section IV.B.3.d, we propose a care access condition (Sec. 171.206(c)) that can be met by practices an actor might choose to implement for the purpose of reducing a risk of potential exposure to legal action for licensed health care professionals, other health care providers, or persons involved in providing or in facilitating the provision or receipt of reproductive health care that is lawful under the circumstances in which such health care is provided. We request comment on multiple, potentially non-exclusive, alternative proposals for additional requirements under the care access condition that would function to restrict the exception's coverage of practices that interfere with access, exchange, or use in scenarios that also implicate the HIPAA Privacy Rule's individual right of access provisions (45 CFR 164.524). In order to satisfy this proposed condition, if finalized, the practice would need to meet the requirements finalized in Sec. 171.206(c). We propose clarifying provisions in Sec. 171.206(d) (discussed in section [[Page 63510]] IV.B.3.b of this proposed rule) and Sec. 171.206(e) (discussed in section IV.B.3.e of this proposed rule). Proposed Sec. 171.206(d) would clarify when reproductive health care sought, obtained, provided, or facilitated by someone other than the actor will be presumed to have been lawful for purposes of assessing whether an actor's practice meets the exception's patient protection or care access condition. In Sec. 171.206(e) we propose to define ``legal action'' for purposes of Sec. 171.206. We propose in section IV.B.4, a new information blocking exception: ``Requestor Preferences'' in 45 CFR 171.304. This exception would stand separate from and independent of other exceptions and would apply where an actor honors or adheres to a requestor's preference(s) expressed or confirmed in writing for: (1) limitations on the amount of EHI made available to the requestor; (2) the conditions under which EHI is made available to the requestor; and (3) when EHI is made available to the requestor for access, exchange, or use. The exception would offer an actor certainty that, so long as the actor's practices meet the conditions of the exception, the actor can honor or adhere to a requestor's preferences related to these specific preferences without concern that the actor may be engaging in ``information blocking'' as defined in 45 CFR 171.103. We propose to add a new definitions section in Sec. 171.401 for certain terms used in Subpart D, which we propose to align with the definitions used in the proposed 45 CFR 172. We seek comment on some aspects of the TEFCA Manner Exception in 45 CFR 171.403, including the limitation on its use for requests made via a FHIR API and the application of the Fees and Licensing Exceptions to practices that satisfy the exception.

6. Trusted Exchange Framework and Common Agreement\TM\

Section 3001(c)(9) of PHSA, as added by the 21st Century Cures Act (Pub. L. 114-255, Dec. 13, 2016) (Cures Act), calls for the development or support of a ``trusted exchange framework, including a common agreement among health information networks nationally.'' On January 19, 2022, ONC published in the Federal Register the Notice of Publication of the Trusted Exchange Framework and Common Agreement (87 FR 2800), in which ONC published the Trusted Exchange Framework (TEF): Principles for Trusted Exchange and the Common Agreement for Nationwide Health Information Interoperability Version 1. ONC published in the Federal Register a notice titled Trusted Exchange Framework and Common Agreement Version 1.1 on November 7, 2023 (88 FR 76773), in which ONC published the Common Agreement for Nationwide Health Information Interoperability Version 1.1 (November 2023), and published version 2.0 implementing the latest industry standards among other changes on May 1, 2024 (89 FR 35107). Section 3001(c)(9)(A) of the PHSA states that the overall goal for TEFCA\TM\ is to ensure full network-to-network exchange of health information. ONC intends to accomplish this by establishing a floor for interoperability under TEFCA across the country. The Common Agreement \16\ is authorized by section 3001(c)(9)(B)(i) of the statute, which addresses: baseline legal and technical requirements for the Common Agreement, organizational and operational policies to enable exchange, minimum conditions for exchange, and a process for filing and adjudicating noncompliance with its terms. The Common Agreement addresses all of these to enable users in different health information networks (HINs) to securely share information with each other--all under commonly agreed-to expectations and terms. The Trusted Exchange Framework,\17\ authorized under the same provision of the PHSA, describes a common set of principles for policies and practices to facilitate data-sharing. --------------------------------------------------------------------------- \16\ Common Agreement for Nationwide Health Information Interoperability, Version 1.1 (November 2023), available at Federal Register:: Trusted Exchange Framework and Common Agreement Version 1.1. \17\ The Trusted Exchange Framework (TEF): Principles for Trusted Exchange (January 2022), available at https://www.healthit.gov/sites/default/files/page/2022-01/Trusted_Exchange_Framework_0122.pdf. --------------------------------------------------------------------------- The Recognized Coordinating Entity[supreg] (RCE\TM\) is an ONC contractor that is charged with helping ONC to develop, operationalize, and update the Common Agreement, as well as assist ONC in stewarding the Qualified Health Information Network\TM\ (QHIN\TM\) Technical Framework (QTF),\18\ which provides the technical specifications for how QHINs connect to one another. The RCE also helps ONC to oversee QHIN-facilitated network operations and QHIN compliance with the Common Agreement. --------------------------------------------------------------------------- \18\ Qualified Health Information Network (QHIN) Technical Framework, Version 1.0 (January 2022), available at https://rce.sequoiaproject.org/wp-content/uploads/2022/01/QTF_0122.pdf. --------------------------------------------------------------------------- As explained in the proposed part 172 of subchapter D of title 45 of the Code of Federal Regulations, by standardizing health information exchange across many different networks, TEFCA will help to ensure full network-to-network exchange of health information. Doing so will simplify exchange by significantly reducing the number of connections (e.g., portals) that individuals, health care providers, and other interested parties need to make to get the health information they seek. It does so by creating baseline governance, legal, and technical requirements that will enable secure information sharing across different networks nationwide, including: a common method for authenticating trusted network participants, a common set of rules for trusted exchange, organizational and operational policies to enable the exchange of health information among networks, and a process for filing and adjudicating noncompliance with the terms of the Common Agreement. As explained in proposed part 172, we believe that TEFCA will help lower the cost and expand the nationwide availability of secure health information exchange capabilities. The availability of TEFCA-based services, such as electronic address directories and patient record location, will also help scale health information exchange nationwide and usher in new support for FHIR API usage and adoption. FHIR API usage and adoption has become a centerpiece of the interoperability initiatives of ONC and other U.S. government agencies such as CDC,\19\ CMS,\20\ Health Resources and Services Administration (HRSA),\21\ and the Veteran's Administration (VA).\22\ --------------------------------------------------------------------------- \19\ See CDC, Public Health Informatics Office (PHIO), https://www.cdc.gov/csels/phio/it_takes_practice.html. \20\ See CMS, Policies and Technology for Interoperability and Burden Reduction, https://www.cms.gov/policies-and-technology-interoperability-and-burden-reduction. \21\ See HRSA, Uniform Data System (UDS) Modernization Initiative, https://bphc.hrsa.gov/data-reporting/uds-training-and-technical-assistance/uniform-data-system-uds-modernization-initiative. \22\ See VA, VA Technical Reference Model v 23.12, https://www.oit.va.gov/Services/TRM/StandardPage.aspx?tid=8233. --------------------------------------------------------------------------- In section V of this proposed rule, we propose to implement 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 propose to add a new part, part 172, to subchapter D of title 45 of the Code of Federal Regulations to implement certain provisions related to the TEFCA. These proposed provisions would establish the processes associated with the qualifications necessary for an entity to receive and maintain Designation (as we propose to define that term in Sec. 172.102) as a QHIN capable of trusted exchange under the Common [[Page 63511]] Agreement. The proposals would also establish the procedures governing Onboarding (as we propose to define that term in Sec. 172.102) of QHINs and Designation of QHINs, suspension, termination, and administrative appeals to ONC, as described in the sections below. We believe establishing these provisions in regulation would support reliability, privacy, security, and trust within TEFCA, which would further TEFCA's ultimate success. In subpart A, we propose the statutory basis, purpose, and scope of the TEFCA provisions in part 172; the applicability of the TEFCA provisions in part 172; and relevant definitions. In subpart B, we propose requirements related to the qualifications needed to be Designated, as proposed to be defined in Sec. 172.102. In subpart C, we describe the proposed QHIN Onboarding and Designation processes. In subpart D, we propose RCE and QHIN suspension rights, notice requirements for suspension, and the requirements related to the effect of suspension. In subpart E, we propose RCE and QHIN termination rights, notice requirements for termination, and requirements related to the effect of termination. In subpart F, we propose to establish QHIN appeal rights and the process for filing an appeal to ONC. These appeal rights would ensure that a QHIN, or Applicant QHIN, that (1) disagrees with certain RCE determinations or (2) believes an action or inaction by a QHIN or the RCE could threaten TEFCA's integrity will have recourse to appeal such determination, action, or inaction to ONC. In subpart G, we propose 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 ONC's website of those 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. Severability

It is our intent that if any provision of this rule were, if or when finalized, held to be invalid or unenforceable facially, or as applied to any person, plaintiff, or stayed pending further judicial or agency action, such provision shall be severable from other provisions of this rule, and from rules and regulations currently in effect, and not affect the remainder of this rule. It is also our intent that, unless such provision shall be held to be utterly invalid or unenforceable, it be construed to give the provision maximum effect permitted by law including in the application of the provision to other persons not similarly situated or to other, dissimilar circumstances from those where the provision may be held to be invalid or unenforceable. In this rule, we propose provisions that are intended to and will operate independently of each other, even if multiple of them serve the same or similar general purpose(s) or policy goal(s). Where a provision is necessarily dependent on another, the context generally makes that clear (such as by cross-reference to a particular standard, requirement, condition, or pre-requisite). Where a provision that is dependent on one that is stayed or held invalid or unenforceable (as described in the preceding paragraph) is included in a subparagraph, paragraph, or section within part 170, 171, or 172 of 45 CFR, we intend that other provisions of such subparagraph(s), paragraph(s), or section(s) that operate independently of said provision would remain in effect. To ensure our intent for severability of provisions is clear in the CFR, we propose to add to existing Sec. 170.101 and Sec. 171.101, and to include in the proposed new Sec. 172.101 a paragraph stating our intent that if any provision is held to be invalid or unenforceable it shall be construed to give maximum effect to the provision permitted by law, unless such holding shall be one of utter invalidity or unenforceability, in which case the provision shall be severable from this part and shall not affect the remainder thereof or the application of the provision to other persons not similarly situated or to other dissimilar circumstances.

D. 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 entitled ``Modernizing Regulatory Review'' (hereinafter, the Modernizing E.O.) 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'' as an action that is likely to result in a rule that may: (1) have an annual effect on the economy of $200 million or more (adjusted every 3 years by the Administrator of the Office of Information and Regulatory Affairs (OIRA) for changes in gross domestic product); or adversely affect in a material way the economy, a sector of the economy, productivity, competition, jobs, the environment, public health or safety, or State, local, territorial, or Tribal governments or communities; (2) create a serious inconsistency or otherwise interfere with an action taken or planned by another agency; (3) materially alter the budgetary impacts of entitlement grants, user fees, or loan programs or the rights and obligations of recipients thereof; or (4) raise legal or policy issues for which centralized review would meaningfully further the President's priorities or the principles set forth in this Executive Order, as specifically authorized in a timely manner by the Administrator of OIRA in each case. OMB has determined that this proposed rule is a significant regulatory action, as the potential economic impacts associated with this proposed rule could be greater than $200 million per year. Accordingly, we have prepared a Regulatory Impact Analysis (RIA) that, to the best of our ability, presents the costs and benefits of this proposed rule. We have estimated the potential monetary costs and benefits of this proposed rule for the health IT community, including costs and benefits as they relate to health IT developers, health care providers, patients, and the Federal Government (i.e., ONC), and have broken those costs and benefits out by section. In accordance with E.O. 12866, we have included the RIA summary table as Table 82. We note that we have rounded all estimates to the nearest dollar and that all estimates are expressed in 2022 dollars as it is the most recent data available to address all cost and benefit estimates consistently. The wages used to derive the cost estimates are from the May 2022 National Occupational Employment and Wage Estimates reported by the U.S. Bureau of Labor Statistics.\23\ We also note that estimates presented in sections titled ``Employee Assumptions and Hourly Wage,'' ``Quantifying the Estimated Number of Health IT Developers and Products,'' and ``Number of End Users that Might Be Impacted by ONC's Proposed Regulations'' are used throughout this RIA. --------------------------------------------------------------------------- \23\ May 2022 National Occupational Employment and Wage Estimates, United States. U.S. Bureau of Labor Statistics. https://www.bls.gov/oes/current/oes_nat.htm. --------------------------------------------------------------------------- We estimate that the total annual cost for this proposed rule for the first year [[Page 63512]] after it is finalized (including one-time costs), based on the cost estimates outlined above and throughout this RIA, would result in $431.1 million. The total undiscounted perpetual cost over a 10-year period for this proposed rule (starting in year two), based on the cost estimates outlined above, would result in $398.1 million. We estimate the total costs to health IT developers to be $829.2 million. We estimate the total annual benefit across all entities for this proposed rule beginning in Year 3, when the associated policies are required to be implemented and expected benefits to be realized, would be on average $22.2 million. We estimate the total benefits across all entities to be $177.6 million. We estimate the total undiscounted perpetual annual net benefit for this proposed rule (starting in year three), based on the estimates outlined above, would result in a net benefit of $75.4 million.

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. Section 119 of Title I, Division CC of the Consolidated Appropriations Act, 2021, Public Law 116-260 (CAA), enacted on December 27, 2020, requires sponsors of prescription drug plans to implement one or more real-time benefit tools (RTBTs) that meet the requirements described in the statute, after the Secretary has adopted a standard for RTBTs and at a time determined appropriate by the Secretary. For purposes of the requirement to implement a real-time benefit tool in section 1860D-4(o)(1) of the Social Security Act, described above, the CAA provides that one of the requirements for an RTBT is that it can integrate with electronic prescribing and EHR systems of prescribing healthcare professionals for the transmission of formulary and benefit information in real time to such professionals. The statute requires incorporation of RTBTs within both the Medicare Part D prescription drug program and the ONC Health IT Certification Program (Program). Specifically, the law amends the definition of a ``qualified electronic health record'' (qualified EHR) in section 3000(13) of the PHSA to require that a qualified EHR must include (or be capable of including) an RTBT.

1. Standards, Implementation Specifications, and Certification Criteria

The HITECH Act established two Federal advisory committees, the Health IT Policy Committee (HITPC) and the Health IT Standards Committee (HITSC). Each was responsible for advising the National Coordinator for Health Information Technology (National Coordinator) on different aspects of standards, implementation specifications, and certification criteria. Section 4003(e) of the Cures Act amended sections 3002 and 3003 of the PHSA by replacing, in an amended section 3002, the HITPC and HITSC with one committee named the Health Information Technology Advisory Committee (Health IT Advisory Committee or HITAC). Section 3002(a) of the PHSA, as added by the Cures Act, establishes that the HITAC recommends to the National Coordinator policies and standards, implementation specifications, and certification criteria, relating to the implementation of a health information technology infrastructure, nationally and locally, that advances the electronic access, exchange, and use of health information. Further described in section 3002(b)(1) of the PHSA, this includes recommending to the National Coordinator a policy framework to advance interoperable health information technology infrastructure, updating recommendations to the policy framework, and making new recommendations, as appropriate. Section 3002(b)(2)(A) of the PHSA specifies that in general, the HITAC shall recommend to the National Coordinator for purposes of adoption under section 3004, standards, implementation specifications, and certification criteria and an order of priority for the development, harmonization, and recognition of such standards, specifications, and certification criteria. Like the process previously required of the former HITPC and HITSC, section 3002(b)(5) of the PHSA requires the HITAC to develop a schedule, updated annually, for the assessment of policy recommendations, which the Secretary publishes in the Federal Register. Section 3004 of the PHSA establishes a process for the adoption of health IT standards, implementation specifications, and certification criteria and authorizes the Secretary to adopt such standards, implementation specifications, and certification criteria. As specified in section 3004(a)(1), the Secretary is required, in consultation with representatives of other relevant Federal agencies, to jointly review standards, implementation specifications, and certification criteria endorsed by the National Coordinator under section 3001(c) and subsequently determine whether to propose the adoption of such standards, implementation specifications, or certification criteria. Section 3004(a)(3) requires the Secretary to publish all such determinations in the Federal Register. Section 3004(b)(3) of the PHSA, titled, Subsequent Standards Activity, provides that the Secretary shall adopt additional standards, implementation specifications, and certification criteria as necessary and consistent with the schedule published by the HITAC. We consider this provision in the broader context of the HITECH Act and Cures Act to grant the Secretary the authority and discretion to adopt standards, implementation specifications, and certification criteria that have been recommended by the HITAC and endorsed by the National Coordinator, as well as other appropriate and necessary health IT standards, implementation specifications, and certification criteria.

2. 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. The certification program(s) must also include, as appropriate, testing of the technology in accordance with section 13201(b) of the HITECH Act. Section 13201(b) of the HITECH Act requires that, with respect to the development of [[Page 63513]] standards and implementation specifications, the Director of NIST shall support the establishment of a conformance testing infrastructure, including the development of technical test beds. Section 13201(b) also indicates that the development of this conformance testing infrastructure may include a program to accredit independent, non- Federal laboratories to perform testing. 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. Section 4002(a) of the Cures Act amended section 3001(c)(5) of the PHSA by adding section 3001(c)(5)(D), which requires the Secretary, through notice and comment rulemaking, to require conditions of certification and maintenance of certification for the Program. Specifically, the health IT developers or entities with technology certified under the Program must, in order to maintain such certification status, adhere to certain conditions and maintenance of certification requirements concerning information blocking; assurances regarding appropriate exchange, access, and use of electronic health information; communications regarding health IT; application programming interfaces (APIs); real world testing; attestations regarding certain conditions and maintenance of certification requirements; and submission of reporting criteria under the EHR Reporting Program in accordance with section 3009A(b) of the PHSA.

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 [[Page 63514]] supporting TEFCA for the purpose of ensuring full network-to-network exchange of health information. On May 1, 2020, a final rule was published titled, ``21st Century Cures Act: Interoperability, Information Blocking, and the ONC Health IT Certification Program'' (85 FR 25642) (ONC Cures Act Final Rule). 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 November 15, 2023, the Secretary issued a proposed rule titled, ``Medicare Program; Contract Year 2025 Policy and Technical Changes to the Medicare Advantage Program, Medicare Prescription Drug Benefit Program, Medicare Cost Plan Program, and Programs of All-Inclusive Care for the Elderly; Health Information Technology Standards and Implementation Specifications'' (88 FR 78476). This proposed rule proposed to adopt the National Council for Prescription Drug Programs (NCPDP) Real-Time Prescription Benefit standard version 13. On June 17, 2024, the Secretary issued the Part D and Health IT Standards final rule (89 FR 51238 through 51265). This final rule adopted the NCPDP Real-Time Prescription Benefit standard version 13 in 45 CFR 170.205(c)(1) and to incorporate this standard by reference in 45 CFR 170.299. In this final rule, CMS also adopted requirements for Part D sponsors to use the standard in in 45 CFR 170.205(c)(1) when implementing an RTBT.

1. National Technology Transfer and Advancement Act

The National Technology Transfer and Advancement Act (NTTAA) of 1995 (15 U.S.C. 3701 et seq.) and the Office of Management and Budget (OMB) Circular A-119 \24\ require the use of, wherever practical, technical standards that are developed or adopted by voluntary consensus standards bodies to carry out policy objectives or activities, with certain exceptions. The NTTAA and OMB Circular A-119 provide exceptions to electing only standards developed or adopted by voluntary consensus bodies, namely when doing so would be inconsistent with applicable law or otherwise impractical. Agencies have the discretion to decline the use of existing voluntary consensus standards if it is determined that such standards are inconsistent with applicable law or otherwise impractical, and instead use a government- unique standard or other standard. In addition to the consideration of voluntary consensus standards, the OMB Circular A-119 recognizes the contributions of standardization activities that take place outside of the voluntary consensus standards process. Therefore, in instances where use of voluntary consensus standards would be inconsistent with applicable law or otherwise impracticable, other standards should be considered that: meet the agency's regulatory, procurement or program needs; deliver favorable technical and economic outcomes; and are widely utilized in the marketplace. In this proposed rule, we use voluntary consensus standards except for: --------------------------------------------------------------------------- \24\ https://www.whitehouse.gov/wp-content/uploads/2020/07/revised_circular_a-119_as_of_1_22.pdf. --------------------------------------------------------------------------- The USCDI v4 standard. We propose to adopt USCDI v4 in Sec. 170.213. This standard is a hybrid of government policy (i.e., determining which data to include in the USCDI) and voluntary consensus standards (i.e., the vocabulary and code set standards attributed to USCDI data elements); The Federal Information Processing Standard (140-2) related to the [[Page 63515]] protection of electronic health information adopted in Sec. 170.210; The CMS standards for QRDA I and III respectively adopted in Sec. 170.205(h)(2) and (k)(3). We are not aware of any voluntary consensus standards that could serve as an alternative for the purposes we describe in further detail throughout this proposed rule, including for establishing a baseline set of data that can be commonly exchanged across care settings for a wide range of uses. We refer readers to section III.B.1 of this preamble for a discussion of the USCDI.

2. Compliance With Adopted Standards and Implementation Specifications

In accordance with Office of the Federal Register regulations related to ``incorporation by reference,'' 1 CFR part 51, which we follow when we adopt proposed standards and implementation specifications in any subsequent final rule, the entire standard or implementation specification document is deemed published in the Federal Register when incorporated by reference therein with the approval of the Director of the Federal Register. Once published, compliance with the standard and implementation specification includes the entire document unless we specify otherwise. For example, if we adopted the SMART Application Launch Framework Implementation Guide Release 2.2 (SMART v2.2) proposed in this proposed rule (see section III.B.2), health IT certified to certification criteria referencing this IG would need to demonstrate compliance with all mandatory elements and requirements of the IG. If an element of the IG is optional or permissive in any way, it would remain that way for testing and certification unless we specified otherwise in regulation. In such cases, the regulatory text would supersede the permissiveness of the IG.

3. ``Reasonably Available'' to Interested Parties

The Office of the Federal Register has established requirements for materials (e.g., standards and implementation specifications) that agencies propose to incorporate by reference in the Code of Federal Regulations (79 FR 66267: 1 CFR 51.5(a)). To comply with these requirements, in section VI (``Incorporation by Reference'') of this preamble, we provide summaries of, and uniform resource locators (URLs) to, the standards and implementation specifications we propose to adopt and subsequently incorporate by reference in the Code of Federal Regulations. To note, we also provide relevant information about these standards and implementation specifications throughout the relevant sections of the proposed rule.

1. The United States Core Data for Interoperability Version 4 (USCDI

v4) a. Background and USCDI v4 Update The United States Core Data for Interoperability (USCDI) is a standardized set of health data classes and data elements for the sharing of electronic health information.\25\ We established USCDI as a standard in the ONC Cures Act Final Rule (85 FR 25670), adopting USCDI Version 1 (USCDI v1) in Sec. 170.213 and incorporating it by reference in Sec. 170.299.\26\ In a final rule titled ``Health Data, Technology, and Interoperability: Certification Program Updates, Algorithm Transparency, and Information Sharing'' (HTI-1 Final Rule) and published on January 9, 2024, we adopted USCDI Version 3 (USCDI v3) in Sec. 170.213 and incorporated it by reference in Sec. 170.299 (89 FR 1210 through 1223). --------------------------------------------------------------------------- \25\ https://www.healthit.gov/isa/united-states-core-data-interoperability-uscdi. \26\ https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-D/part-170#p-170.213. --------------------------------------------------------------------------- The USCDI standard in Sec. 170.213 is a baseline set of data that can be commonly exchanged across care settings for a wide range of uses. Certain certification criteria in Sec. 170.315 currently require the use of one of the versions of the USCDI standard in Sec. 170.213. USCDI is also referenced by HHS programs and used by the healthcare community to align interoperability requirements and national priorities for health IT across industry initiatives. For the overall structure and organization of USCDI, including data classes and data elements, please see www.healthIT.gov/USCDI. As described in the ONC Cures Act Final Rule, we use a predictable, transparent, and collaborative process to expand the USCDI standard, including providing the opportunity for public comment (85 FR 25670). Additionally, as described in the ONC Cures Act Final Rule, health IT developers can use the Standards Version Advancement Process (SVAP) to voluntarily implement and use the most recent National Coordinator- approved version of USCDI without waiting for ONC to require that newer version via rulemaking (85 FR 25669). ONC uses a public comment process to identify newer versions of standards for approval by the National Coordinator as part of SVAP.\27\ USCDI v3 was available for voluntary implementation through SVAP as of September 2023. --------------------------------------------------------------------------- \27\ https://www.healthit.gov/isa/standards-version-advancement-process. --------------------------------------------------------------------------- Based on feedback ONC received through the ONC New Data Element and Class submission system, ONC identified a set of data elements and data classes for a draft version of USCDI v4, which was released in January 2023. The draft version of USCDI v4 included 20 new data elements and one new data class as well as updates to minimum standard code set versions. ONC then finalized and released USCDI v4 in July 2023. We propose to update the USCDI standard in Sec. 170.213 by adding USCDI v4. We propose that for purposes of the Program, the adoption of USCDI v3 expires on January 1, 2028. We propose to add USCDI v4 in Sec. 170.213(c) and incorporate it by reference in Sec. 170.299. We propose that as of January 1, 2028, any Health IT Modules seeking certification to criteria referencing Sec. 170.213 would need to be capable of exchanging the data elements that the USCDI v4 comprises. The additional data elements in USCDI v4 reflect many of the recommendations expressed by the Health IT Advisory Committee in their report to the National Coordinator.\28\ As finalized in the HTI-1 Final Rule, beginning on January 1, 2026, only USCDI v3 will be available in Sec. 170.213 as the USCDI standard for use by developers of certified health IT (89 FR 1215). This proposed rule would advance the USCDI standard to USCDI v4, continuing ONC's commitment to a transparent and predictable schedule for health IT developers with respect to updates to the USCDI's regulatory baseline. If finalized, this proposal would provide significant clarity and certainty to health IT developers who would have substantial time to update certified health IT to support USCDI v4. --------------------------------------------------------------------------- \28\ https://www.healthit.gov/sites/default/files/page/2023-05/2023-04-12_IS_WG_USCDI_v4_Transmittal_Letter_508.pdf. --------------------------------------------------------------------------- For certification to a criterion in Sec. 170.315 that references the USCDI standard adopted in Sec. 170.213, we propose that a Health IT Module must use at least one of the versions of the USCDI standard that is (1) adopted in Sec. 170.213 or approved by SVAP at the time the Health IT Module seeks certification and (2) not expired at the time of use. When a Health IT Module certified to a criterion in Sec. 170.315 that references the USCDI standard adopted in Sec. 170.213 is using a version with an [[Page 63516]] upcoming expiration date or is using an interim version approved by SVAP, we propose that the health IT developer must update the Module to either a new version of the standard adopted in Sec. 170.213 or a subsequent version approved by SVAP prior to the expiration date or dates defined in order to maintain certification of that Health IT Module as described in Sec. 170.315. Consistent with the health IT developer must provide the updated Health IT Module to their customers by the expiration date or dates defined in order to maintain certification of that Health IT Module as described in Sec. 170.315. We describe these proposals further in section III.B.1.b below. b. Certification Criteria That Reference USCDI The USCDI standard is currently cross-referenced in certain certification criteria (see Sec. 170.213). A Health IT Module can be certified to any of these criteria by ensuring that it complies with any unexpired version of the USCDI included in Sec. 170.213 or a version of the USCDI standard that is approved through SVAP at the time the Health IT Module seeks certification. The certification criteria that currently cross-reference to USCDI via Sec. 170.213 are as follows: ``Care coordination--Transitions of care--Create'' (Sec. 170.315(b)(1)(iii)(A)(1) and (2)); ``Care coordination--Clinical information reconciliation and incorporation--Reconciliation'' (Sec. 170.315(b)(2)(iii)(D)(1)- (3)); ``Decision support interventions--Decision support configuration'' (Sec. 170.315(b)(11)(ii)(A) and (B), and (iv)(A)(5)- (13))); ``Patient engagement--View, download, and transmit to 3rd party--View'' (Sec. 170.315(e)(1)(i)(A)(1) and (2), and (iii)); ``Transmission to public health agencies--electronic case reporting'' (Sec. 170.315(f)(5)(i)(C)(2)(i)); ``Design and performance--Consolidated CDA creation performance'' (Sec. 170.315(g)(6)(i)(A) and (B)); ``Design and performance--Application access--all data request--Functional requirements'' (Sec. 170.315(g)(9)(i)(A)(1) and (2)); and ``Design and performance--Standardized API for patient and population services--Data response'' (Sec. 170.315(g)(10)(i)(A) and (B)). We propose that up to and including December 31, 2027, a Health IT Module certified to criteria referencing Sec. 170.213 may use either USCDI v3 or USCDI v4. We propose that by January 1, 2028, a health IT developer of a Health IT Module certified to criteria referencing Sec. 170.213 must update to USCDI v4 and provide the updated version to their customers in order to maintain certification of that Health IT Module. We also note that if these proposals are finalized, for any time before January 1, 2026, USCDI v1 could still be used to meet the applicable certification criteria as well (see 89 FR 1211 through 1223). Further, we propose that Health IT Modules certified to certification criteria that reference Sec. 170.213 would need to update their Health IT Modules to accommodate USCDI v4 data elements using the FHIR[supreg] US Core Implementation Guide Version 7.0.0 proposed in Sec. 170.215(b)(1)(iii) and the HL7 CDA R2 Implementation Guide: Consolidated CDA Templates for Clinical Notes, Edition 3--US Realm, proposed in Sec. 170.205(a)(1). We also propose that adoption of the standards in Sec. 170.205(a)(6) and Sec. 170.215(b)(1)(ii) expire on January 1, 2028. As stated in the HTI-1 Final Rule, our intent would be to adopt the version of these standards necessary for developers of certified health IT to have appropriate implementation guidance to meet the certification criteria that reference USCDI v4, and these updated implementation guides best align with and support effective implementation of USCDI v4. Based on public comments on HTI-1 and prior rulemakings, we believe that the health IT industry, healthcare standards developers, and health care providers expect and support ONC making such determinations so that the adopted version of standards are the most up-to-date available and are feasible for real- world implementation (see 89 FR 1215).

2. SMART App Launch 2.2

In the ONC HTI-1 Final Rule, we adopted the HL7[supreg] FHIR[supreg] SMART Application Launch Framework Implementation Guide Release 2.0.0 (SMART v2 Guide), a profile of the OAuth 2.0 specification, in Sec. 170.215(c)(2) (89 FR 1291 through 1295). Public comments received during the HTI-1 rulemaking process indicated near universal support for the adoption of the SMART v2 Guide, with the caveat that several of these commenters suggested we adopt the newest balloted version of the SMART App Launch IG, which at the time of the HTI-1 public comment period was version 2.1. We declined to adopt the newest balloted version of the SMART App Launch IG in the HTI-1 Final Rule, noting that the SMART v2 Guide had ``already been an established part of the Program via SVAP and rigorously tested . . .'' (89 FR 1292). However, we also noted that ``[w]e will consider potential ways the SMART v2.1 IG could be included in the Program in the future . . .'' (89 FR 1292). We note that current ONC policy as established in the ONC Cures Act Final Rule (85 FR 25741) and reiterated in the HTI-1 Final Rule (89 FR 1293) is that as part of supporting the SMART App Launch ``permission- patient'' capability, Health IT Modules presented for testing and certification must include the ability for patients to authorize an application to receive their EHI based on FHIR resource-level scopes. Furthermore, we finalized in the HTI-1 Final Rule (89 FR 1294) that as part of supporting the SMART App Launch ``permission-v2'' capability Health IT Modules must support certain sub-resource scopes for the Condition and Observation resources. Specifically, we established minimal conformance requirements at the category level for the Condition and Observation resources using specifications and guidance from the SMART v2 Guide and FHIR US Core 6.1.0 implementation guides to ensure that Health IT Modules required to support the SMART v2 Guide are capable of supporting the finer-grained resource constraints capability without being overly prescriptive in setting expectations for how the Health IT Module implements such capabilities. In this proposed rule, we clarify the existing Program requirements to support patient authorization using SMART App Launch capabilities. Specifically, we clarify that if both the ``permission-patient'' and ``permission-v2'' capabilities are required in support of patient authorization for certification to a criterion in the Program, then a Health IT Module must support the following: Support for the ability for patients to authorize an application to receive their EHI based on individual FHIR resource- level and individual sub-resource-level scopes. Support for the ability for patients to authorize an application to receive their EHI based on individual sub-resource-level scopes when corresponding resource-level scopes are requested. These requirements enable patients to have the ability to authorize access to their EHI at a more granular level in alignment with required SMART App Launch authorization capabilities. The capabilities enabled by these requirements empower patients with authorization ability at the individual sub-resource level, and the ability to provide granular authorization at the [[Page 63517]] individual sub-resource level even if the authorization request from the app is made at the resource level. We note that both the ``permission-patient'' and ``permission-v2'' capabilities are required as part of the ``Permissions'' subsection of the SMART App Launch IGs proposed in Sec. 170.215(c)(2) and Sec. 170.215(c)(3). We propose ``Permissions'' in Sec. 170.315(j)(9), which is cross-referenced in Sec. 170.315(g)(10) and Sec. 170.315(g)(30) in this proposed rule. We anticipate that future certification criteria will also include ``permission-patient'' and ``permission-v2'' support requirements to support of patient authorization and we intend for this clarification to support patient authorization of individual sub-resource level scopes to also apply. Specific guidance and requirements regarding the implementation of resource and sub-resource scopes are included in the US Core 7.0.0 implementation guide. We clarify for the purposes of certification under the Program, support for the US Core IG includes supporting all SMART App Launch scope requirements included in the US Core IG, including requirements to support resource and sub-resource scopes. We note throughout this rule we propose revisions to existing API certification criteria and propose new API certification criteria wherein specificity in the requirements regarding the properties of applications is important. To provide a consistent and industry standard definition of app types referenced in Program API certification criteria, we clarify that ``confidential app,'' ``public app,'' and ``native app'' as referenced in this rule and in Program API requirements refers to ``confidential client,'' ``public client,'' and ``native application'' respectively as defined in internet Engineering Task Force (IETF) Request for Comments (RFC) 6749 ``The OAuth 2.0 Authorization Framework.'' \29\ --------------------------------------------------------------------------- \29\ IETF RFC 6749 ``The OAuth 2.0 Authorization Framework'' available here: https://datatracker.ietf.org/doc/rfc6749/. --------------------------------------------------------------------------- The SMART Application Launch Framework Implementation Guide, Release 2.2 (SMART v2.2 Guide), published at the end of April 2024, is the most recent version available at the time of this proposed rule. The SMART v2.2 Guide includes features that iterate on the features of the SMART v2 Guide, including the enhancements from the SMART v2.1 Guide and the latest industry consensus updates. Notable enhancements in the SMART v2.2 Guide include a more detailed and standardized ``fhirContext'' parameter, including the ability for servers to include optional ``roles'' for offering a detailed description of included resource references in the ``fhirContext'' parameter; updates to the ``fhirUser'' context parameter to allow the use of the ``PractitionerRole'' resource for representing the current user authorizing the launch; and clarification regarding the ``exp'' field in the token introspection response, ensuring consistency between the ``exp'' field in the token introspection response and the ``expires_in'' interval in the original access token response. Additionally, to eliminate ambiguity in URL resolution, the SMART v2.2 Guide mandates the use of absolute URLs in the Well-Known configuration file, disallowing relative URLs. The SMART v2.2 Guide also introduces a new Cross-Origin Resource Sharing (CORS) security requirement applicable to servers supporting purely browser- based apps. Finally, an important new addition to the SMART v2.2 Guide is the User-Access Brands and Endpoints (Brands) specification, which allows API providers to publish Brands associated with their FHIR Endpoints to enable apps to collect and present these Brands to users (e.g., patients). Overall, these enhancements to the SMART v2.2 Guide improve standardization and provide clarity to help support consistent implementation and improve interoperability. We welcome comment on our assessment of these SMART v2.2 Guide changes. Based on HTI-1 public comment feedback and to make use of the new Brands specification in the Program, we propose to adopt the SMART v2.2 Guide in Sec. 170.215(c)(3) and incorporate it by reference as a subparagraph in Sec. 170.299. Additionally, we propose that the adoption of the SMART v2 Guide in Sec. 170.215(c)(2) would expire on January 1, 2028. If we finalize these proposals, developers of certified health IT with Health IT Modules certified to criteria referencing the implementation specifications in Sec. 170.215(c) may use the SMART v1, SMART v2, or SMART v2.2 Guides for the time period up to and including December 31, 2025. Then by January 1, 2026, when the adoption of SMART v1 expires, developers of certified health IT with Health IT Modules certified to criteria referencing the implementation specifications in Sec. 170.215(c) must update to the SMART v2 or SMART v2.2 Guides and provide the updated version to their customers in order to maintain certification of that Health IT Module. Finally, by January 1, 2028, when the adoption of the SMART v2 Guide expires, developers of certified health IT with Health IT Modules certified to criteria referencing the implementation specifications in Sec. 170.215(c) must update to the SMART v2.2 Guide and provide the updated health IT module to their customers in order to maintain certification of that Health IT Module. We propose that any Health IT Modules seeking certification to criteria referencing the implementation specifications in Sec. 170.215(c) on or after January 1, 2028, would need to be capable of supporting the SMART v2.2 Guide. Our proposal to require health IT developers participating in the program to update and provide to customers Health IT Modules updated to according to the timelines for the implementation specifications in Sec. 170.215(c) includes all certification criteria that reference the implementation specifications in Sec. 170.215(c) directly, or via reference to our proposed modular API capabilities certification criteria in Sec. 170.315(j)(6), (j)(7), (j)(8), (j)(9), and (j)(10) that also reference the implementation specifications in Sec. 170.215(c). In this proposed rule these certification criteria are: Sec. 170.315(g)(10), (g)(20), (g)(30), (g)(32), (g)(33), (g)(34), and (g)(35). We note that Sec. 170.315(g)(20), (g)(30), (g)(32), (g)(33), (g)(34), and (g)(35) are new Program certification criteria proposed in this rule and the only currently finalized certification criterion in the Program that includes a reference to Sec. 170.215(c) is Sec. 170.315(g)(10). To reference the SMART Guide across these proposed new and revised certification criteria, we propose to move the SMART Guide component references (e.g., specific capabilities and sections) out of the subparagraphs in Sec. 170.215(c), so that only entire SMART Guide references are listed under Sec. 170.215(c). This will enable the SMART Guides to be referenced across Program certification criteria, whilst also enabling references to specific SMART Guide components tailored to the requirements of a specific certification criterion. For example, the proposed Sec. 170.315(j)(9) certification criterion as proposed in the section titled ``New Certification Criteria for Modular API Capabilities'' would reference Sec. 170.215(c) along with a list of applicable SMART Guide components tailored specifically to describe SMART Guide requirements for patient authorization for standalone apps. We note that later versions of the SMART Guide may be finalized by the time of our final rule. During the time between our proposed rule and our final rule, the FHIR community may, for example, issue technical corrections in a SMART v2.2.x Guide or release a [[Page 63518]] newer SMART v2.x Guide minor release. We intend to evaluate and potentially adopt in the final rule the most recent available version of the SMART Guide that aligns with the SMART v2.2 Guide changes outlined in this proposed rule. We encourage interested parties to monitor the SMART App Launch IG directory of published versions (https://hl7.org/fhir/smart-app-launch/history.html) for all IG iterations, technical corrections, and releases. We welcome comment on this proposal.

3. User-Access Brands and Endpoints

In the ONC HTI-1 Final Rule, we finalized requirements in Sec. 170.404(b)(2) for Certified API Developers to publish certain service base URLs and related organization (i.e., API Information Source) details in a standardized FHIR[supreg] format (89 FR 1285 through 1290). Public comments received during the HTI-1 rulemaking process indicated strong support for the ``continued development and standardization of publication formats for FHIR `service base URLs' '' (89 FR 1286). Many of these commenters suggested we adopt a FHIR implementation guide, with a particular emphasis on the Patient-access Brands (PAB) specification. We declined to adopt PAB or any other FHIR implementation guides for Sec. 170.404(b)(2) at the time, and instead finalized more generalized base FHIR requirements to best ensure compatibility with the emerging industry FHIR implementation guides. Given the particular interest in the PAB specification we noted in HTI- 1 that ``[w]e will consider the Patient-access Brands specification for adoption in future rulemaking as it develops'' (89 FR 1288). Currently, the PAB specification, now referred to as ``User-access Brands and Endpoints,'' (and referred to as Brands herein) is set for publication as a sub-specification in the SMART v2.2 Guide. The Brands specification ``defines FHIR profiles for Endpoint, Organization and Bundle resources that help users connect their apps to health data providers.'' \30\ It provides guidelines for API providers to publish Brands associated with their FHIR endpoints that apps can collect and present to users. Each Brand can include information like organization name, location, identifiers, patient portal details, FHIR API Endpoints, and more. These Brands are assembled in FHIR ``Bundle'' format, and these Bundles can made available in two ways: by FHIR servers including a link in their SMART ``.well-known/smart- configuration'' \31\ metadata file, or through vendor-consolidated Brand Bundles that are openly published. --------------------------------------------------------------------------- \30\ https://hl7.org/fhir/smart-app-launch/STU2.2/brands.html. \31\ https://hl7.org/fhir/smart-app-launch/STU2.2/brands.html#metadata-in-well-knownsmart-configuration. --------------------------------------------------------------------------- We propose to update our current maintenance of certification (MoC) requirements in Sec. 170.404(b)(2) that reference FHIR resources and elements directly and adopt Brands in Sec. 170.404(b)(2)(iii) as a replacement. Specifically, we propose to reorganize the regulation text paragraphs in a way that places existing service base URL requirements into Sec. 170.404(b)(2)(ii) that expire on December 31, 2027. We propose in our updated Sec. 170.404(b)(2)(iii) to require that, by January 1, 2028, service base URLs and related API Information Source details, including each organization's name, location, and facility identifier, must be published in an aggregate vendor-consolidated ``FHIR Bundle'' according to the Brands specification. Additionally, we propose to move our existing publication terms and quarterly review and update requirements, that we have currently finalized in Sec. 170.404(b)(2) and (b)(2)(iii)(B), to subparagraphs under Sec. 170.404(b)(2)(i) that apply broadly to other sub-paragraphs under Sec. 170.404(b)(2), including our new proposed Brands requirements in Sec. 170.404(b)(2)(iii). Finally, we propose that a health IT developer may meet the proposed revised MoC requirements by satisfying the new conformance requirements proposed in Sec. 170.404(b)(2)(i), (iii), and (iv) in lieu of Sec. 170.404(b)(2)(i) and (ii) prior to December 31, 2027. We believe that our proposed changes to Sec. 170.404(b)(2) logically build on our existing MoC requirements in Sec. 170.404(b)(2) because the Brands specification uses profiles of the same base FHIR resources (i.e., ``Endpoint,'' ``Organization,'' and ``Bundle'') we have finalized in Sec. 170.404(b)(2). Requiring the use of the more standardized FHIR profiles in Brands that are designed specifically for the endpoint publication use case reduces inconsistent and varied implementations leading to increased interoperability. We also believe that our proposed changes to Sec. 170.404(b)(2) align with much of the public feedback we received during the HTI-1 rulemaking process where the Brands precursor PAB specification was cited numerous times (89 FR 1286 through 1289). We welcome comment on this proposal to reference Brands for publication of service base URLs and related organization details in Sec. 170.404(b)(2). Additionally, in our revised Sec. 170.404(b)(3) where we propose new requirements for the publication of API discovery details for payer network information, including service base URLs and API Information source details, we propose to adopt Brands specification. Please see section III.B.20.d for further details on proposed Sec. 170.404 updates. We note that the Brands specification is a sub-specification in the SMART v2.2 Guide and we anticipate that subsequent versions of Brands will be included in subsequent versions of the SMART Guide. We also note that our proposed January 1, 2028 date for the SMART v2.2 Guide to be the minimum version in Sec. 170.215(c) (see section III.B.2 for our proposal to adopt the SMART v.2.2 Guide in Sec. 170.215(c)) matches the date that health IT developers subject to the requirements in Sec. 170.404(b)(2) must support Brands for publication of API discovery details for patient access. As we noted in section III.B.2, later versions of the SMART Guide may be finalized by the time of our final rule. This includes changes to the Brands specification, or potential corrections if identified, and we intend to evaluate and potentially adopt in the final rule the most recent available version of the SMART Guide if doing so would best support interoperability and effective program implementation. We encourage interested parties to monitor the SMART App Launch IG directory of published versions (https://hl7.org/fhir/smart-app-launch/history.html) for all IG iterations, technical corrections, and releases. We welcome comment on this proposal.

4. Standards for Encryption and Decryption of Electronic Health

Information a. Background In the 2015 Edition Final Rule, ONC adopted the October 8, 2014, version of Annex A: Approved Security Functions for Federal Information Processing Standards (FIPS) Publication 140-2. This October 8, 2014, version was the most recent version published by the National Institute of Standards and Technology (NIST) when the 2015 Edition Final Rule published (80 FR 62707). b. Proposal Since finalizing the October 8, 2014, version of Annex A: Approved Security Functions for FIPS Publication 140-2 standard in the 2015 Edition Final Rule, [[Page 63519]] encryption techniques and security best practices have continued to advance, and NIST has published several updated versions of Annex A: Approved Security Functions for FIPS Publication 140-2.\32\ The most recent version of Annex A for FIPS Publication 140-2 is Draft, October 12, 2021. We propose to adopt the Draft, October 12, 2021, version of Annex A for FIPS Publication 140-2 in Sec. 170.210(a)(3) and incorporate it by reference as a subparagraph in Sec. 170.299. We also propose that the adoption of the FIPS 140-2 October 8, 2014, version in Sec. 170.210(a)(2) expire on January 1, 2026. We note that the FIPS 140-2 October 8, 2014, version was inadvertently removed from Sec. 170.299, therefore we propose to incorporate by reference the standard in Sec. 170.299(m)(3). We welcome comment on these proposals. --------------------------------------------------------------------------- \32\ See pages 4-6 of the October 12, 2021 version of Annex A for a revision history of the standard. Available at: https://csrc.nist.gov/csrc/media/publications/fips/140/2/final/documents/fips1402annexa.pdf. --------------------------------------------------------------------------- We note that revising Sec. 170.210(a) would implicate three certification criteria that reference standards in Sec. 170.210(a): Sec. 170.315(d)(7) End-user device encryption, which we propose to revise and rename as ``Health IT encryption'' elsewhere in this preamble; Sec. 170.315(d)(9) Trusted connection; and Sec. 170.315(d)(12) Encrypt authentication credentials, which we propose to further revise and rename as ``Protect stored authentication credentials'' elsewhere in this preamble. Given the cross reference to Sec. 170.210(a)(2) in these certification criteria, we propose to revise each certification criterion in Sec. 170.315(d)(7), (d)(9), and (d)(12) to replace ``standard'' with ``at least one version of the standard'' and ``Sec. 170.210(a)(2)'' with ``Sec. 170.210(a)'' where appropriate in each certification criterion. At revised Sec. 170.315(d)(7)(iv) we propose to revise both ``standard'' and ``Sec. 170.210(a)(2)'' in this manner. In Sec. 170.315(d)(9)(i) and (ii); and at revised Sec. 170.315(d)(12)(i)(A), we also propose to revise ``standard'' and ``Sec. 170.210(a)(2)'' in this manner. As noted, we describe our remaining proposed revisions to Sec. 170.315(d)(7) and Sec. 170.315(d)(12) elsewhere in this preamble at III.B.11 and III.B.12 and we invite readers to review those sections. Additionally, we propose to remove the standard found in Sec. 170.210(f) that is no longer referenced in any active certification criteria. We welcome comments on our proposals. Finally, we solicit comment on the transition to the next FIPS standard, FIPS 140-3, that is currently underway.\33\ We are monitoring development in this area, and we welcome comment on FIPS 140-3 and any potential impacts to our Program requirements. We note that Annex A for FIPS 140-2 is compatible with current FIPS 140-3 guidance as an ``Approved Security Function,'' and we intend to re-evaluate the latest FIPS 140-3 guidance at the time of the final rule to ensure continued capability with FIPS 140-3.\34\ We recognize the potential for changes in FIPS 140-2 and 140-3 by the time of our final rule. Therefore, we intend to consider and potentially finalize the most recent Approved Security Functions that align with current FIPS guidance at the time and that are compatible with the Annex A for FIPS 140-2 update we are proposing in this proposed rule. We welcome comment on this proposal. --------------------------------------------------------------------------- \33\ See FIPS 140-3 Transition Effort page--https://csrc.nist.gov/projects/fips-140-3-transition-effort. \34\ The ``10. Approved Security Functions'' requirements in FIPS 140-3 (March 22, 2019 version) state that ``Approved security functions include those that are . . . adopted in a FIPS and specified either in an appendix to the FIPS or in a document referenced by the FIPS.'' The October 12, 2021 draft version of Annex A for FIPS 140-2 meets that criterion to contain ``Approved Security Functions'' according to FIPS 140-3. See https://csrc.nist.gov/pubs/fips/140-3/final. ---------------------------------------------------------------------------

5. Minimum Standards Code Sets Updates

We established a policy in the 2015 Edition Final Rule for minimum standards code sets that update frequently (80 FR 62612). In the final rule entitled ``Health Information Technology: Standards, Implementation Specifications, and Certification Criteria for Electronic Health Record Technology, 2014 Edition; Revisions to the Permanent Certification Program for Health Information Technology'' (77 FR 54163) we discussed the benefits of adopting newer versions of minimum standards code sets, including the improved interoperability and implementation of health IT with minimal additional burden (77 FR 54170). As we stated in the HTI-1 Final Rule, when determining whether to propose newer versions of minimum standards code sets, we consider the impact on interoperability and whether a newer version would require substantive effort for developers of certified health IT to implement (89 FR 1224). If adopted, newer versions of minimum standards code sets would serve as the baseline for certification and developers of certified health IT would be able to use newer versions of these adopted standards on a voluntary basis. We reiterate that while minimum standard code sets update frequently, perhaps several times in a single year, these updates are confined to concepts within the code system, not substantive changes to the standards themselves. For certification to a criterion in Sec. 170.315 that references the standard adopted in Sec. 170.207, we propose that a Health IT Module must use at least one of the versions of the standard that is (1) adopted in Sec. 170.207 or approved by SVAP at the time the Health IT Module seeks certification and (2) not expired at the time of use. We also propose that when a Health IT Module certified to a criterion in Sec. 170.315 that references the standard adopted in Sec. 170.207 is using a version with an upcoming expiration date or is using an interim version approved by SVAP, the health IT developer must update the Module to either a new version of the standard adopted in Sec. 170.207, or a subsequent version approved by SVAP, prior to the expiration date or dates defined in order to maintain certification of that Health IT Module as described in Sec. 170.207. In addition, the health IT developer must provide the updated Health IT Module to their customers by the expiration date or dates defined in Sec. 170.207 in order to maintain certification of that Health IT Module as described in Sec. 170.315. Sec. 170.207(a)--Problems We propose to revise Sec. 170.207(a)(2), which is currently reserved, to reference SNOMED CT[supreg], U.S. Edition, September 2023 Release and incorporate it by reference in Sec. 170.299. We also propose that the adoption of the standard in Sec. 170.207(a)(1), SNOMED CT, U.S. Edition, March 2022 Release, would expire on January 1, 2028, and that the adoption of the standard in Sec. 170.207(a)(4), IHTSDO SNOMED CT, U.S. Edition, September 2015 Release, would expire on January 1, 2026. Sec. 170.207(c)--Laboratory tests We propose to revise Sec. 170.207(c)(2) to reference Logical Observation Identifiers Names and Codes (LOINC[supreg]) Database version 2.76, a universal code system for identifying laboratory and clinical observations produced by the Regenstrief Institute, Inc. and incorporate it by reference in Sec. 170.299. We also propose that the adoption of the standard in Sec. 170.207(c)(1), LOINC Database Version 2.72, would expire on January 1, 2028, and that the adoption of the standard in Sec. 170.207(c)(3), LOINC Database version 2.52, would expire on January 1, 2026. Sec. 170.207(d)--Medications We propose to revise the citations in Sec. 170.207(d) to improve organization of [[Page 63520]] this section. Specifically, we propose to revise Sec. 170.207(d)(1) to list standards for clinical drugs and to reference multiple releases of RxNorm, a standardized nomenclature for clinical drugs produced by the United States National Library of Medicine. We propose in Sec. 170.207(d)(1)(ii) to reference RxNorm, December 4, 2023 Full Monthly Release and incorporate it by reference in Sec. 170.299. We propose to move the standard adopted in Sec. 170.207(d)(1), RxNorm, July 5, 2022 Release, to Sec. 170.207(d)(1)(i), and that the adoption of this standard would expire on January 1, 2028. We propose to move the standard adopted in Sec. 170.207(d)(3), RxNorm, September 8, 2015 Release, to Sec. 170.207(d)(1)(iii) and that the adoption of this standard would expire on January 1, 2026. Finally, we propose to move National Drug Codes, currently included via cross-reference in Sec. 170.207(d)(4), to Sec. 170.207(d)(2). We note that Sec. 170.207(d)(2) is currently reserved. We also propose to reserve Sec. 170.207(d)(3) and remove Sec. 170.207(d)(4). Sec. 170.207(e)--Immunizations We propose to reference in Sec. 170.207(e)(5) the CDC National Center of Immunization and Respiratory Diseases (NCIRD) Code Set (CVX)--Vaccines Administered, updates through September 29, 2023, and incorporate it by reference in Sec. 170.299. We also propose to reference in Sec. 170.207(e)(6) the National Drug Code (NDC)--Vaccine NDC Linker, updates through November 6, 2023, and incorporate it by reference in Sec. 170.299. We propose that adoption of the standards in Sec. 170.207(e)(1), the HL7[supreg] Standard Code Set CVX--Vaccines Administered, dated through June 15, 2022, and Sec. 170.207 (e)(2), NDC--Vaccine NDC Linker, dated July 19, 2022, would expire on January 1, 2028. We also propose that adoption of the standards in Sec. 170.207(e)(3), HL7 Standard Code Set CVX--Vaccines Administered, updates through August 17, 2015, and Sec. 170.207(e)(4), NDC--Vaccine NDC Linker, updates through August 17, 2015, would expire on January 1, 2026. Sec. 170.207(f)--Race and Ethnicity We propose to revise Sec. 170.207(f)(1) to include recent updates to the U.S. Office of Management and Budget's Statistical Policy Directive No. 15: Standards for Maintaining, Collecting, and Presenting Federal Data on Race and Ethnicity (SPD 15). In Sec. 170.207(f)(1)(i) we propose to include The Office of Management and Budget Standards for Maintaining, Collecting, and Presenting Federal Data on Race and Ethnicity, Statistical Policy Directive No. 15, as revised, October 30, 1997 with an expiration date of January 1, 2026 for adoption of that standard. In Sec. 170.207(f)(1)(ii) we propose to include the U.S. Office of Management and Budget's Statistical Policy Directive No. 15: Standards for Maintaining, Collecting, and Presenting Federal Data on Race and Ethnicity (SPD 15), as revised, March 29, 2024. We propose to revise Sec. 170.207(f)(2) to include CDC Race and Ethnicity Code Set standards. In Sec. 170.207(f)(2)(i) we propose to include CDC Race and Ethnicity Code Set Version 1.0 (March 2000) with an expiration of January 1, 2026, for adoption of that standard. In Sec. 170.207(f)(2)(ii) we propose to include CDC Race and Ethnicity Code Set Version 1.2 (July 08, 2021) and incorporate it by reference in Sec. 170.299. We propose to remove and reserve Sec. 170.207(f)(3). Sec. 170.207(m)--Numerical references We propose that adoption of the standard in Sec. 170.207(m)(1), The Unified Code of Units of Measure, Revision 1.9, would expire on January 1, 2026. Sec. 170.207(n)--Sex We propose that adoption of the standard in Sec. 170.207(n)(1), HL7 Version 3 Standard, Value Sets for AdministrativeGender and NullFlavor, would expire on January 1, 2026. We propose to revise Sec. 170.207(n)(2) to reference use of at least one of the versions of SNOMED CT U.S. Edition specified in Sec. 170.207(a). We also propose to revise Sec. 170.207(n)(3) to reference use of at least one of the versions of LOINC specified in Sec. 170.207(c). Sec. 170.207(o)--Sexual orientation and gender information We propose to revise Sec. 170.207(o)(1)-(3) to reference use of at least one of the versions of SNOMED CT U.S. Edition specified in Sec. 170.207(a) instead of Sec. 170.207(a)(4). We also propose to revise Sec. 170.207(o)(4) to reference use of at least one of the versions of LOINC specified in Sec. 170.207(c). Sec. 170.207(p)--Social, psychological, and behavioral data We propose to revise Sec. 170.207(p)(1) through (8) to reference use of at least one of the versions of LOINC specified in Sec. 170.207(c). We propose to revise Sec. 170.207(p)(4), (5), (6), (7), and (8) to reference use of at least one of the versions of the standard specified in Sec. 170.207(m). Sec. 170.207(r)--Provider type We propose that adoption of the standard in Sec. 170.207(r)(1) would expire on January 1, 2026. Sec. 170.207(s)--Patient insurance We propose that adoption of the standard in Sec. 170.207(s)(1), Public Health Data Standards Consortium Source of Payment Typology Code Set Version 5.0 (October 2011), would expire on January 1, 2026. In addition to updating the minimum standards code sets listed above, we propose to update the certification criteria that reference those minimum standards. These certification criteria include Sec. Sec. 170.315(a)(12), 170.315(b)(1)(iii)(B)(2) and (G)(3), 170.315(c)(4)(iii)(C), (E), (G), (H), and (I), 170.315(f)(1)(i)(B)-(C), 170.315(f)(3)(ii) and (f)(4)(ii).

6. New Imaging Requirements for Health IT Modules

Diagnostic images are critical to supporting care in a variety of healthcare settings. Clinicians routinely use diagnostic images to support patient care and patients can better facilitate and coordinate care when they have access to their own images. Diagnostic images are often stored in systems external to an EHR, such as picture archiving and communication systems (PACS), vendor neutral archives (VNA), or other imaging platforms. While radiologists, ophthalmologists, dermatologists, pathologists, and other imaging specialists generally have direct access to full diagnostic quality images on these systems, access to both diagnostic quality and lesser quality images for referring providers can be inconsistent, depending on how broadly the hospitals or provider practice deploys access to their imaging infrastructure. While certain images may be exchanged electronically in an automated manner, patients are often provided their diagnostic quality images on physical media (e.g., compact disc read-only memory (CD-ROM)) to physically transport to their next clinical visit. Some PACS and VNA systems provide access to images through a web-based viewer, but those web-based viewers are often not accessible outside of the hospital or practice's immediate network. In the Health Information Technology: Standards, Implementation Specifications, and Certification Criteria for Electronic Health Record Technology, 2014 Edition; Revisions to the Permanent Certification Program for Health Information Technology (2014 Edition Final Rule), ONC adopted an ``Image Results'' certification criterion to [[Page 63521]] support the CMS EHR Incentive Program requirement, also known as the Meaningful Use or ``MU Stage 2 Objective'' requirement, that required eligible clinicians, eligible hospitals, and critical access hospitals to have access to imaging results and information through Certified EHR Technology (77 FR 54172).\35\ The certification criterion required a Health IT Module to indicate the availability of a patient's images and narrative interpretations and enable access to those images and narrative interpretations. ONC stated that the requirements of this certification criterion could be met via the capability to directly link to images stored in the EHR system or providing a context- sensitive link to an external application which provides access to images and their associated narrative. We also stated in the 2014 Edition Final Rule that the use of the Digital Imaging and Communications in Medicine (DICOM) standard (or any other imaging standards) was unnecessary to meet the functional requirement expressed in the imaging results certification criterion (77 FR 54173). Instead, we reiterated our understanding stated in the 2014 Edition Proposed Rule that the adoption of standards was unnecessary to enable users to electronically access images and their narrative interpretations, as required by this certification criterion (77 FR 13838). --------------------------------------------------------------------------- \35\ For more discussion regarding ONC's support of the CMS EHR Incentive Program, Stage 2 Meaningful Use, please see: https://www.cms.gov/newsroom/fact-sheets/cms-proposes-definition-stage-2-meaningful-use-certified-electronic-health-records-ehr-technology. --------------------------------------------------------------------------- In the 2015 Edition Proposed Rule, ONC proposed to maintain the ``Imaging Results'' certification criterion (80 FR 16822) and while some commenters supported this proposal, ONC ultimately removed the ``Imaging Results'' certification criterion in the 2015 Edition Final Rule because the associated CMS EHR Incentive Programs objective (now referred to as Promoting Interoperability objectives) was removed and no longer required technological support (80 FR 62683). Instead, we finalized a certification criterion related to imaging in Sec. 170.315(a)(3) ``Computerized provider order entry--diagnostic imaging,'' which is currently available for certification in the Program and requires that a Health IT Module enable a user to record, change, and access diagnostic imaging orders. We acknowledge there are certain use cases and circumstances where image access via physical media may be more appropriate than network access (e.g., locations without adequate network capabilities). However, we believe the prevalence of CD-ROMs and other physical media to share diagnostic quality images across healthcare settings indicates a lack of interoperability and access to imaging results that represents a continued burden for patients and clinicians. The widespread use of CD-ROMs and other physical media to share diagnostic quality images persists despite the adoption of PACS and VNA systems, the implementation of web-based viewers for diagnostic imaging, and the emergence of electronic standards and profiles meant to facilitate medical image access and exchange. For instance, the DICOM standard establishes a service-based process for web-based medical imaging, DICOMwebTM. The Integrating the Healthcare Enterprise (IHE) XCPD, XCA, and XCA-I profiles support electronic transactions that can be used to facilitate medical imaging access. While these standards and others currently exist, there is not yet a clear consensus or full adoption of these pathways in health IT. ONC believes that promoting access to and the exchange of images via Program requirements may encourage more widespread adoption and integration of these already existing pathways and reduce burdens caused by physical media exchange. Therefore, we propose to revise three certification criteria by adding new provisions to include support of a link to diagnostic imaging: ``transitions of care'' in Sec. 170.315(b)(1); ``application access--all data request'' in Sec. 170.315(g)(9); and ``standardized API for patient and population services'' in Sec. 170.315(g)(10). We describe in subsequent paragraphs the criterion-specific details of the proposals to require support for imaging links in the Program. We believe that support for imaging links in these certification criteria will promote the availability of electronic image access for patients and providers. To enable a consistent understanding of ``imaging link'' across certification criteria requirements in the Program, we propose to define ``imaging link'' in Sec. 170.102 to be ``technical details which enable the electronic viewing or retrieval of one or more images over a network.'' The proposed definition of ``imaging link'' is intended to be sufficiently broad to include the technical details used by the protocols and technologies implemented by industry to view and retrieve images. We also note that there is no specific standard associated with the support of this link, and that the functionality of this requirement can be met with a context-sensitive link to an external application which provides access to images and their associated narrative. The DICOMweb standard (e.g., DICOM PS3.18 2023d-- Web Services) \36\ is likely to be among the standards widely used by hospitals and providers to support imaging links, but the Health IT Module certified to these certification criteria is not required to support a specific standard. We also clarify that although this proposal does not include specific security standards, we expect the appropriate authentication and authorization processes to be supported to prevent unauthorized access via the imaging links required in this proposal. For example, health IT developers may consider SMART Health Links as one possible standard by which to generate secure links to patient images. --------------------------------------------------------------------------- \36\ https://dicom.nema.org/medical/dicom/2023d/ 2023d/. --------------------------------------------------------------------------- We propose to revise the Sec. 170.315(b)(1) ``Transitions of care'' certification criterion to support imaging links by adding imaging links to the data required to be supported in the ``Create'' functionality in Sec. 170.315(b)(1)(iii) by adding a new paragraph in Sec. 170.315(b)(1)(iii)(H). The ``Create'' functionality in Sec. 170.315(b)(1)(iii) specifies the requirement to enable a user to create a transition of care/referral summary formatted in accordance with the standard specified in Sec. 170.205(a)(3), (4), and (5) using the Continuity of Care Document, Referral Note, and (inpatient setting only) Discharge Summary document templates including at a minimum the data described under Sec. 170.315(b)(1)(iii)(A)--(G). We propose specifically to add a paragraph in Sec. 170.315(b)(1)(iii)(H) to indicate on and after January 1, 2028 imaging links are a part of the minimum ``Create'' requirements in Sec. 170.315(b)(1)(iii). We propose to revise the Sec. 170.315(g)(9) ``Application access-- all data request'' certification criterion to support imaging links by adding imaging links to the data required to be supported in responses to requests for patient data in a summary record formatted according to the data response requirements at paragraphs in Sec. 170.315(g)(9)(i)(A)(1) and (2). Specifically, we propose to add a paragraph Sec. 170.315(g)(9)(i)(A)(3)(v) that indicates on and after January 1, 2028 imaging links are required to be supported as part of the data response requirements in Sec. 170.315(g)(9)(i)(A)(1) and (2). We also propose to revise the data response requirements in paragraphs Sec. 170.315(g)(9)(i)(A)(1) and (2) to reference the data requirements proposed in Sec. 170.315(g)(9)(i)(A)(3)(v). [[Page 63522]] We propose to revise the Sec. 170.315(g)(10) ``Standardized API for patient and population services'' certification criterion to support imaging links by adding imaging links to the data required to be supported for data response for patients and users and for data response for systems. Specifically, we propose to add imaging links as data required to be supported on and after January 1, 2028 in data response for patients and users consistent with FHIR and US Core requirements at the paragraph proposed in Sec. 170.315(g)(10)(ii)(B)(1). Additionally, we propose to add imaging links as data required to be supported on and after January 1, 2028 in data response for systems consistent with FHIR and US Core requirements proposed in Sec. 170.315(g)(10)(iii)(B)(1), and the Bulk FHIR API data response for systems in accordance with FHIR, US Core, and Bulk Data Access, including the ``_type'' query parameter, requirements proposed in Sec. 170.315(g)(10)(iii)(B)(2) and Sec. 170.315(g)(10)(iii)(B)(2)(ii). We also propose to revise the ``view, download, and transmit to 3rd party'' certification criterion in Sec. 170.315(e)(1) to add functional support for viewing and download of diagnostic quality and lower quality images as well as inclusion of an imaging link to those diagnostic images in either a downloaded or transmitted Continuity of Care Document (CCD). We propose that Health IT Modules support this functionality on and after January 1, 2028. Specifically, we propose to add both diagnostic quality images and reduced quality images to the data that must be supported for viewing by patients (and their authorized representatives) according to paragraph (e)(1)(i)(A) by including support for diagnostic quality images and reduced quality images at the proposed paragraph (e)(1)(i)(A)(8). Furthermore, we propose to include imaging links in the requirements in Sec. 170.315(e)(1)(i)(B)(2)(i) and (ii) specifying the data required to be included at a minimum in ambulatory summaries and inpatient summaries respectively be downloadable in accordance with the requirements specified at paragraph (e)(1)(i)(B)(2), which details the download requirements for ambulatory summaries and inpatient summaries downloaded according to the standard specified in Sec. 170.205(a)(4) through (6) following the CCD document template. Finally, we propose that patients (and their authorized representatives) must be able to use technology to download both diagnostic quality and reduced quality images at the proposed Sec. 170.315(e)(1)(i)(B)(4). Like broad requirements proposed in Sec. 170.315(e)(1)(i)(A)(8), we propose that Health IT Modules certified to Sec. 170.315(e)(1) support these specific scenarios on and after January 1, 2028. Again, there is no standard specified for either the images or the imaging links in the proposed requirements, though we anticipate that DICOM and the DICOMweb standard (such a--DICOM PS3.18 2023d--Web Services) are likely to be among standards widely used by hospitals and providers to support images and imaging links respectively. We believe it is important to support the ability to view and download both diagnostic and lower quality images. While it is critical for patients to have access to diagnostic imaging, lower quality images are also important and, for example, a patient may decide that it is useful to have the lower quality images for quick reference. This revised certification criterion requires that both types of imaging be supported for viewing and for direct downloading by patients. The view and download requirements of this certification criterion could be met via the capability to directly link to images stored in the Health IT Module or providing a context-sensitive connection to an external application which provides access to images and their associated narrative. In either case, however, the view and download functionalities must be accessible to the patient through the same internet-based technology as the other functionalities of Sec. 170.315(e)(1). Electronic exchange of the image itself does not need to be included as part of the Sec. 170.315(e)(1)(C) ``Transmit to third party'' functionality. However, similar to the proposals for the other certification criteria discussed above, an imaging link to the images accessible to the patient must be provided. We propose that on and after January 1, 2028, a Health IT Module seeking certification to any of the certification criteria in Sec. 170.315(b)(1), (e)(1), (g)(9), and (10), must meet the proposed requirements for imaging links. We note that health IT developers are also required to meet the Assurances Condition of Certification maintenance requirement in Sec. 170.402(b)(3) that any health IT developer with a Health IT Module certified to these certification criteria would need to update their Health IT Modules and provide the updated version to their customers, including the most recently adopted capabilities and standards included in the revised certification criteria order to maintain certification of that Health IT Module. We welcome comments on these proposals.

7. Revised Clinical Information Reconciliation and Incorporation

Criterion We propose to revise the ``Clinical information reconciliation and incorporation'' (CIRI) certification criterion in Sec. 170.315(b)(2). These proposed revisions are intended to expand our existing CIRI certification requirements to additional data elements and promote new capabilities that would benefit providers by reducing the burden of reconciliation and incorporation in clinical workflows. Our requirements for CIRI in the Program were first established in the ``Health Information Technology: Initial Set of Standards, Implementation Specifications, and Certification Criteria for Electronic Health Record Technology'' Jan. 13, 2010, interim final rule to enable a user to electronically compare two or more medication lists (75 FR 2014). We subsequently expanded these requirements in the 2014 Edition Final Rule to require clinical information reconciliation and incorporation for three data types: problems, medications, and medication allergies (77 FR 54222). We noted in the 2010 interim final rule that there was, ``. . . great promise in making this [reconciliation] capability more comprehensive'' and that we ``anticipate exploring ways to improve the [reconciliation] utility of this capability. . .'' (75 FR 44613). In the 2014 Edition Final Rule we also noted our agreement with public comments that said providers ``should have some control over how exactly they want to be able to incorporate data into their EHR technology as part of their practice/ organization'' (77 FR 54219). Building on our CIRI strategy and in response to public feedback, we propose to revise Sec. 170.315(b)(2) to require Health IT Modules to support reconciliation and incorporation of all USCDI data elements. In the context of the CIRI workflow in Sec. 170.315(b)(2), we propose that upon receipt of a transition of care/referral summary all USCDI data elements must be supported, at a minimum, for reconciliation and incorporation by a user in Sec. 170.315(b)(2)(v). We also propose in Sec. 170.315(b)(2)(vi) user configuration functionality to enable a user to set individual or organizational rules that allow automatic reconciliation and incorporation for each data class included in at least one of the versions of the USCDI standard in Sec. 170.213, including functionality that allows the [[Page 63523]] user to select trusted data and trusted data sources for automatic reconciliation and incorporation. Finally, as part of our proposed revision to the CIRI certification criterion in Sec. 170.315(b)(2), we propose system verification functionality in Sec. 170.315(b)(2)(vii) that requires Health IT Modules to be able to create a file formatted according to the Continuity of Care Document template. We propose to implement this by requiring Health IT Modules certified to Sec. 170.315(b)(2) to meet the requirements inSec. 170.315(b)(2)(i), (ii), (iii), and (vii), or the requirements in (iv), (v), (vi) and (vii) for the time period up to and including December 31, 2027. On and after January 1, 2028, we propose that Health IT Modules certified to Sec. 170.315(b)(2) must meet the requirements in Sec. 170.315(b)(2)(iv), (v), (vi), and (vii). Our proposed revised CIRI requirements in Sec. 170.315(b)(2)(iv), (v), and (vi) include reorganizing and generalizing the CIRI workflow requirements currently in the certification criterion in Sec. 170.315(b)(2)(i), (ii), and (iii). Specifically, we have generalized and combined requirements currently in Sec. 170.315(b)(2)(i) and (ii) in proposed Sec. 170.315(b)(iv) and we have replicated requirements currently in Sec. 170.315(b)(2)(iii) in proposed Sec. 170.315(b)(v) under ``user reconciliation,'' with the aforementioned proposal to reference all data classes and data elements in the USCDI standard in Sec. 170.213 instead of the currently referenced ``medications,'' ``allergies and intolerance,'' and ``problems'' data elements. Additionally, we propose to move our system verification requirements currently finalized in Sec. 170.315(b)(2)(iv) into Sec. 170.315(b)(2)(vii) and we propose, for clarity, to break these system verification requirements up into sub-paragraphs under Sec. 170.315(b)(2)(vii). Given the goal of USCDI to support ``data elements for nationwide, interoperable health information exchange,'' \37\ we believe this proposal supports interoperability and continues to advance our policy objectives for widespread electronic health information exchange. Additionally, we believe that these requirements would help equip providers with additional, relevant, and sometimes critical clinical information that can improve overall patient care. We envision that the ability to reconcile and incorporate both structured and unstructured data elements of the USCDI would be a welcomed functionality to improve patient care, note bloat,\38\ and clinician burden. --------------------------------------------------------------------------- \37\ https://www.healthit.gov/isa/united-states-core-data-interoperability-uscdi. \38\ Rule A, Bedrick S, Chiang MF, Hribar MR. Length and Redundancy of Outpatient Progress Notes Across a Decade at an Academic Medical Center. JAMA Netw Open. 2021;4(7): e2115334. doi:10.1001/jamanetworkopen.2021.15334. --------------------------------------------------------------------------- We note that there can be multiple approaches for supporting user reconciliation and we have stated previously, ``in the event that data is in unstructured form, any method implemented by which the EHR is capable of assisting in reconciliation is acceptable'' (77 FR 54224). We believe that developers have technology readily available for assisting users in reconciling and incorporating data and we maintain that this approach would continue support for innovation. Alternative Proposal to Revised CIRI Criterion in Sec. 170.315(b)(2) As an alternative proposal, narrower in scope and on which we seek public comment, we are also considering whether to limit the expansion of our incorporation and reconciliation requirements, that must be met on and after January 1, 2028, to just nine specific USCDI data classes (six new data classes plus the existing three Allergies and intolerance, Medications, and Problems data classes). The limited data classes in USCDI v4 we have identified for this alternative proposal are: Allergies and Intolerances, Care Team Members, Goals and Preferences, Immunizations, Laboratory, Medications, Medical Devices, Patient Summary and Plan, and Problems. Across these nine data classes, the USCDI v4 includes the following: The data elements in the Allergies and Intolerances data class include Substance (Medication), Substance (Drug Class), Substance (Non-Medication) and Reaction. The data elements in the Care Team Member(s) data class include Care Team Member Name, Care Team Member Identifier, Care Team Member Role, Care Team Member Location, and Care Team Member Telecom. The data elements in the Goals and Preferences data class include Patient Goals, SDOH Goals, Treatment Intervention Preference, and Care Experience Preference. The one data element in the Immunizations data class is Immunizations. The data elements in the Laboratory data class include Tests, Values/Results, Specimen Type, Result Status, Result Unit of Measure, Result Reference Range, Result Interpretation, Specimen Source Site, Specimen Identifier, and Specimen Condition Acceptability. The data elements in Medications include Medications, Dose, Dose Unit of Measure, Indication, Fill Status, Medications Instructions, and Medication Adherence. The data element in the Medical Devices data class is Unique Device Identifier--Implantable. The data element in the Patient Summary and Plan data class is Assessment and Plan of Treatment. The data elements in Problems include Problems, SDOH Problems/Health Concerns, Date of Diagnosis, and Date of Resolution. We selected these data classes based on feedback from industry and existing industry support as well as our understanding of importance for improved patient care. We believe that the standards referenced for these data elements are mature enough or the information they relay are important enough to patient care to warrant inclusion as part of the CIRI workflow as part of this alternative proposal for a more moderate expansion. We welcome comment on expanding our CIRI certification requirements to only a limited set of a USCDI data classes versus referencing all USCDI. Additionally, if a limited set of different data elements within the USCDI is preferred, we welcome comments on what subset of USCDI data classes and elements should be referenced in the certification criterion as most necessary for reconciliation and better patient care. Automatic Reconciliation and Incorporation Capabilities in Revised CIRI Criterion in Sec. 170.315(b)(2) In addition to our proposed updated CIRI requirements that support all USCDI, we also propose in Sec. 170.315(b)(2)(vi) new functional requirements to enable user-driven automatic reconciliation and incorporation for Health IT Modules certified to Sec. 170.315(b)(2). We believe that users and health care providers are best situated to determine which clinical data and data sources require manual review and which are better suited to automatic reconciliation and incorporation. To ensure that Health IT Modules certified to Sec. 170.315(b)(2) have the capability to support user-driven automatic reconciliation and incorporation, we propose in Sec. 170.315(b)(2)(vi), that Health IT Modules certified to Sec. 170.315(b)(2) would need to provide functionality that would allow automatic reconciliation and incorporation, without manual review, for each of the [[Page 63524]] applicable USCDI data elements. We note that nothing in this proposal would compel automatic reconciliation and incorporation for specific workflows or use cases. Rather, our intention is to empower users in determining the circumstances under which clinical data can be automatically reconciled and incorporated, we also propose new configuration requirements in Sec. 170.315(b)(2)(vi) to enable users to set rules indicating specific data and/or specific data sources for automatic reconciliation and incorporation. We note that automatic incorporation means any process by which USCDI data elements contained within C-CDAs are automatically reconciled with information within certified health IT and incorporated in the health IT without an action by a clinician end user or their delegate. These processes include (1) reconciling new information from the C-CDA into the Health IT Module, for instance, by comparison of medication information in the Health IT Module and information in the C-CDA; or (2) determining that no new information needs to be incorporated into the Health IT Module. We welcome comment on this proposal. We believe that these revisions would provide users with the ability to configure their workflows in such a way as to maximize patient care while minimizing provider effort to perform reconciliation and incorporation. As we have stated in a previous rule when expanding CIRI requirements, ``we believe that EHR technology can be designed to assist users in remarkable ways and that reconciling information from multiple sources in a way that is assistive to a user is something at which EHR technology should excel'' (77 FR 13849). We believe this proposal is aligned with similar functionalities that many developers are already developing. Our goal is to advance baseline functionality while also leaving room for innovation. We propose that Health IT Modules must support the proposed automatic reconciliation and incorporation capabilities on and after January 1, 2028. We welcome comment on this proposed functionality.

8. Revised Electronic Prescribing Certification Criterion

We propose to update the ``electronic prescribing'' certification criterion in Sec. 170.315(b)(3). The proposed updates include updating the core standard for electronic prescribing to NCPDP SCRIPT standard version 2023011,\39\ which is cross-referenced in Sec. 170.205(b)(2) in the proposed text in Sec. 170.315(b)(3)(ii)(A). We also propose revisions to the transactions within the SCRIPT standard that would be required for the updated certification criterion and propose to remove a number of transactions that are currently identified as optional for the criterion. Finally, we propose to remove Sec. 170.315(b)(3)(i) from the CFR upon the effective date of this rule and reserve it as this version of the certification criterion is no longer valid for use in the Program. --------------------------------------------------------------------------- \39\ See https://standards.ncpdp.org/Access-to-Standards.aspx. --------------------------------------------------------------------------- a. Electronic Prescribing Standard In the ``Medicare Program; Medicare Prescription Drug Benefit Program; Health Information Technology Standards and Implementation Specifications'' final rule (Part D and Health IT Standards Final Rule), which appeared in the Federal Register on June 17, 2024 (89 FR 51238 through 51265), we adopted NCPDP SCRIPT standard version 2023011 in Sec. 170.205(b)(2). We also finalized an expiration date for NCPDP SCRIPT standard version 2017071 of January 1, 2028, in Sec. 170.205(b)(1), which reflected a delay of one year from the expiration date we had proposed (88 FR 78501). We also finalized the removal of the NCPDP SCRIPT standard version 10.6, which was located in Sec. 170.205(b)(2) (89 FR 51258 and 51259). The finalization of these policies in the Part D and Health IT Standards Final Rule, and CMS' finalization of cross references to Sec. 170.205(b) in their requirements for the Part D Program, reflects a unified approach to aligning standards adoption across HHS programs that impact a common set of participants (88 FR 78486 through 78494). We note that we previously proposed to adopt NCPDP SCRIPT standard version 2022011 and made other proposals in the ``Medicare Program; Contract Year 2024 Policy and Technical Changes to the Medicare Advantage Program, Medicare Prescription Drug Benefit Program, Medicare Cost Plan Program, Medicare Parts A, B, C, and D Overpayment Provisions of the Affordable Care Act and Programs of All-Inclusive Care for the Elderly; Health Information Technology Standards and Implementation Specifications'' proposed rule (2024 Part C/D Proposed Rule), which appeared in the Federal Register on December 27, 2022 (87 FR 79555). However, we subsequently withdrew these proposals in the ``Medicare Program; Contract Year 2025 Policy and Technical Changes to the Medicare Advantage Program, Medicare Prescription Drug Benefit Program, Medicare Cost Plan Program, and Programs of All-Inclusive Care for the Elderly; Health Information Technology Standards and Implementation Specifications'' proposed rule (2025 Part C/D Proposed Rule), which appeared in the Federal Register on November 15, 2023 (88 FR 78476), and instead proposed to adopt the NCPDP SCRIPT standard version 2023011 in Sec. 170.205(b)(2) (88 FR 78501 through 78502). In this proposed rule, we propose in Sec. 170.315(b)(3)(ii)(A) that for the time period up to and including December 31, 2027, a Health IT Module certified to the ``electronic prescribing'' certification criterion at 45 CFR 170.315(b)(3) must enable a user to perform the following prescription-related electronic transactions in accordance with the standard specified in Sec. 170.205(b)(1) (NCPDP SCRIPT standard version 2017071) or Sec. 170.205(b)(2) (NCPDP SCRIPT standard version 2023011). We also propose that on and after January 1, 2028, a Health IT Module certified to the ``electronic prescribing'' certification criterion must enable a user to perform the following prescription-related electronic transactions in accordance with only the standard specified in Sec. 170.205(b)(2) (NCPDP SCRIPT standard version 2023011). This means that a health IT developer may continue to maintain health IT certification conformance to NCPDP SCRIPT standard version 2017071 (in Sec. 170.205(b)(1)) for the time period up to and including December 31, 2027. On and after January 1, 2028, consistent with our policy in Sec. 170.402(b), developers of certified health IT with Health IT Modules certified to the ``electronic prescribing'' certification criterion will need update those Health IT Modules to the standard in Sec. 170.205(b)(2) and provide them to customers. This is consistent with the date of January 1, 2028, that we finalized for the expiration of NCPDP SCRIPT standard version 2017071 in Sec. 170.205(b)(1) in the Part D and Health IT Standards Final Rule (89 FR 51259). We also propose in Sec. 170.315(b)(3)(ii)(A) that the Health IT Module must use RxNorm (which we have adopted in Sec. 170.207(d)(1)), and, if using NCPDP SCRIPT standard version 2023011, National Drug Codes (which we cross reference in Sec. 170.207(d)(2)). b. Proposed Transactions We propose the following updates and changes to the transactions identified for the ``electronic prescribing'' certification criterion in Sec. 170.315(b)(3)(ii). [[Page 63525]] New Prescriptions (NewRx) (Sec. 170.315(b)(3)(ii)(A)(1)) We propose in Sec. 170.315(b)(3)(ii)(A)(1) to revise the name used for the NewRx transaction in our regulations from ``Create New Prescriptions (NewRx)'' to ``New Prescriptions (NewRx).'' We propose this change to align with updated terminology used by NCPDP within the SCRIPT standard. Request and Receive Medication History (Sec. 170.315(b)(3)(ii)(A)(6)) We propose to remove the request and receive medication history transactions (RxHistoryRequest, RxHistoryResponse) as a requirement for the ``electronic prescribing'' certification criterion in Sec. 170.315(b)(3)(ii)(A)(6) and reserve this section. In the ONC Cures Act Final Rule, ONC finalized the request and receive medication history transactions (RxHistoryRequest, RxHistoryResponse) in the ``electronic prescribing'' certification criterion (85 FR 25682). Since the final rule was published, health IT developers and health care providers have described several challenges meeting this requirement, including development burden; lower than expected adoption and use; and duplicative, overlapping, and sometimes contradictory data from multiple sources. Due in part to these challenges and market forces that have prevented some developers from adopting this functionality natively, developers have had to rely on third-party applications to achieve certification, and in some cases, are unable to achieve certification for electronic prescribing altogether. As such, we propose these transactions would no longer be required for certification to the ``electronic prescribing'' criterion in Sec. 170.315(b)(3)(ii)(A)(6). We also propose to reserve section Sec. 170.315(b)(3)(ii)(A)(6). We continue to encourage developers to support these transactions where possible and to follow industry efforts to advance the exchange of patient medication histories through various means such as health information exchanges, health information networks, and prescription drug monitoring programs. We further note that, while health IT developers would not be required to demonstrate compliance with these transactions in order for a Health IT Module to be certified to the updated version of the ``electronic prescribing'' criterion (if our proposals are finalized), CMS still requires use of these transactions when appropriate for electronic exchange of prescription-related information by Part D sponsors and prescribers and dispensers of Part D drugs for Part D eligible individuals (88 FR 78486). Health IT developers would still need to support these transactions when supporting customers who utilize these transactions to exchange electronic Part D medication history information among Part D sponsors and prescribers and dispensers of Part D drugs for Part D eligible individuals in compliance with requirements, currently codified at 42 CFR 423.160(b)(4) and finalized to be codified at 42 CFR 423.160(b)(1)(i)(U) in the Part D and Health IT Standards Final Rule (89 FR 51247). We request comments on this proposal. Electronic Prior Authorization Transactions (Sec. 170.315(b)(3)(ii)(A)(10)) We propose to require the following transactions for electronic prior authorization for the ``electronic prescribing'' certification criterion, at the time a health IT developer presents a Health IT Module for certification using the standard in Sec. 170.205(b)(2) (NCPDP SCRIPT standard version 2023011): PAInitiationRequest, PAInitiationResponse, PARequest, PAResponse, PAAppealRequest, PAAppealResponse, PACancelRequest, and PACancelResponse. In the ONC Cures Act Final Rule, ONC adopted these transactions in Sec. 170.315(b)(3)(ii)(B)(9) as optional for the ``electronic prescribing'' certification criterion (85 FR 25678). We stated that we adopted these transactions to support alignment with the ``Medicare Program; Secure Electronic Prior Authorization for Medicare Part D'' proposed rule (84 FR 28450), in which CMS proposed to require Part D sponsors to support NCPDP SCRIPT standard version 2017071 for four electronic prior authorization transactions, and proposed that prescribers would be required to use that standard when performing electronic prior authorization transactions for Part D covered drugs they wish to prescribe to Part D eligible individuals (85 FR 25685). CMS subsequently finalized in the ``Medicare Program; Secure Electronic Prior Authorization for Medicare Part D'' final rule in Sec. 423.160(b)(8)(ii) that beginning January 1, 2022, Part D sponsors and prescribers must use the NCPDP SCRIPT standard version 201701 (85 FR 86832). The ONC Cures Act Final Rule allowed health IT developers seeking certification to support these transactions through optional testing but did not require developers to certify to these transactions. We have received feedback from the public in support of requiring these transactions, most recently in response to the ``Request for Information: Electronic Prior Authorization Standards, Implementation Specifications, and Certification Criteria'' (Electronic Prior Authorization RFI), which was published in the Federal Register on January 24, 2022 (87 FR 3475). Commenters stated that requiring these transactions for the certification criterion would help to advance interoperability and reduce administrative burden around prior authorization processes for medications. We agree with this input and believe that it is appropriate to require these transactions at this time. Therefore, we propose to remove PAInitiationRequest, PAInitiationResponse, PARequest, PAResponse, PAAppealRequest, PAAppealResponse, PACancelRequest, and PACancelResponse in Sec. 170.315(b)(3)(ii)(B)(9) as optional and propose to require these transactions in Sec. 170.315(b)(3)(ii)(A)(10) for the ``electronic prescribing'' certification criterion at the time a health IT developer presents a Health IT Module for certification using NCPDP SCRIPT standard version 2023011. ONC also charged the HITAC to establish a Task Force in order to provide input and recommendations in response to the Electronic Prior Authorization RFI; the Task Force's recommendations were approved and submitted to ONC on March 10, 2022.\40\ If finalized, the proposals in this rule would implement the Task Force's recommendation to update these prior authorization transactions from ``optional'' in the current version of the ``electronic prescribing'' certification criterion to ``mandatory,'' to better support electronic prior authorization processes for drugs covered under a prescription benefit. --------------------------------------------------------------------------- \40\ https://www.healthit.gov/sites/default/files/page/2022-03/2022-03-10_ePA_RFI_Recommendations_Report_Signed_508.pdf. --------------------------------------------------------------------------- We also propose to adopt the PANotification transaction in Sec. 170.315(b)(3)(ii)(A)(10) as a required transaction for the ``electronic prescribing'' certification criterion to further support the exchange of electronic prior authorization information. PANotification is a new transaction introduced since NCPDP SCRIPT standard version 2017071. The PANotification transaction is used to alert the pharmacist or prescriber when a prior authorization has been requested or when a prior authorization [[Page 63526]] determination has been received. The PANotification transaction is intended to improve electronic communication between prescribers and pharmacists, and to reduce duplicate submissions of prior authorization requests to payers. Notification may occur via a NewRx, RxChange or RxRenewal transaction, or as a standalone PANotification. We believe that requiring the PANotification transaction is an important complement to the other proposals related to electronic prior authorization described above. We request comments on these proposals. Optional Transactions (NewRxRequest, NewRxResponseDenied, RxFillIndicatorChange, GetMessage, Resupply, DrugAdministration, RxTransferRequest, RxTransferResponse, RxTransferConfirm, Recertification, REMSInitiationRequest, REMSInitiationResponse, REMSRequest, and REMSResponse) (Sec. 170.315(b)(3)(ii)(B)(1)-(8)) We propose to remove the transactions in Sec. 170.315(b)(3)(ii)(B)(1)-(8) which are currently identified as ``optional'' for the ``electronic prescribing'' certification criterion. We propose to revise Sec. 170.315(b)(3)(ii)(B) to include requirements related to the exchange of race and ethnicity information in Sec. 170.315(b)(3)(ii)(B)(1)-(4), which is discussed in greater detail below. Specifically, we propose to remove the following transactions in Sec. 170.315(b)(3)(ii)(B) upon the effective date of the final rule: NewRxRequest, NewRxResponseDenied (Sec. 170.315(b)(3)(ii)(B)(1)) RxFillIndicatorChange (Sec. 170.315(b)(3)(ii)(B)(2)) GetMessage (Sec. 170.315(b)(3)(ii)(B)(3)) Resupply (Sec. 170.315(b)(3)(ii)(B)(4)) DrugAdministration (Sec. 170.315(b)(3)(ii)(B)(5)) RxTransferRequest, RxTransferResponse, RxTransferConfirm (Sec. 170.315(b)(3)(ii)(B)(6)) Recertification (Sec. 170.315(b)(3)(ii)(B)(7)) REMSInitiationRequest, REMSInitiationResponse, REMSRequest, and REMSResponse (Sec. 170.315(b)(3)(ii)(B)(8)) For completeness, we note that Sec. 170.315(b)(3)(ii)(B) currently has transactions listed in Sec. 170.315(b)(3)(ii)(B)(9) related to electronic prior authorization. However, we proposed in the section above to remove Sec. 170.315(b)(3)(ii)(B)(9) and add the electronic prior authorization transactions currently in Sec. 170.315(b)(3)(ii)(B)(9) as required transactions in Sec. 170.315(b)(3)(ii)(A)(10). In reviewing data from the Program, we have found that very few developers have elected to certify to the optional transactions in Sec. 170.315(b)(3)(ii)(B)(1)-(9). We believe that the low rate of certification to these certification criteria indicates that health IT developers do not see a benefit in obtaining optional certification to these criteria. Accordingly, we believe that removing these optional transactions from the program will reduce the complexity and cost of the Program with minimal impact on health IT developers. We further note that CMS requires use of these transactions when appropriate for electronic exchange of prescriptions and prescription- related information by Part D sponsors and prescribers and dispensers of Part D drugs for Part D eligible individuals. Accordingly, regardless of whether a health IT developer seeks to certify its Health IT Module(s) to these optional transactions, developers will still need to support them when supporting customers who utilize these transactions to exchange information electronically between prescribers and dispensers of Part D drugs for Part D eligible individuals in compliance with requirements currently codified at 42 CFR 423.160(b)(2)(iv) and finalized to be codified at 42 CFR 423.160(b)(1)(i) in the Part D and Health IT Standards Final Rule (89 FR 51245 through 51247). We request comment on our proposal to remove the optional transactions in Sec. 170.315(b)(3)(ii)(B)(1)-(8) from the ``electronic prescribing'' certification criterion. Alternatively, we considered proposing to require the optional transactions in Sec. 170.315(b)(3)(ii)(B)(1)-(8) rather than removing them from the criterion. However, we did not identify additional reasons to propose to require any of these optional transactions. We request comment on this alternative, including whether commenters believe requiring any of the optional transactions in Sec. 170.315(b)(3)(ii)(B)(1)-(8) proposed for removal from the ``electronic prescribing'' certification criterion would be important to supporting interoperability between certified Health IT Modules and entities subject to Part D electronic prescribing requirements at 42 CFR 423.160. We refer readers to Table 1A for a comparison of transactions identified in the existing NCPDP SCRIPT standard version 2017071 and the proposed certification criterion based on NCPDP SCRIPT standard version 2023011. c. Additional Proposals Signatura (Sig) (Sec. 170.315(b)(3)(ii)(D)) In Sec. 170.315(b)(3)(ii)(D), we propose that a Health IT Module certified to the ``electronic prescribing'' criterion must enable a user to enter, receive, and transmit structured and codified prescribing instructions in accordance with the standard specified in Sec. 170.205(b)(2) (NCPDP SCRIPT standard version 2023011), at the time a health IT developer presents a Health IT Module for certification using the NCPDP SCRIPT standard version 2023011. The Signatura or Sig is the information provided with a prescription to communicate how a prescriber intends for a patient to take a medication. These directions for use are essential for accurate prescription labeling, appropriate patient counseling and education from a pharmacist, and optimal medication use. The NCPDP Structured and Codified Sig Format Implementation Guide,\41\ which is embedded in the NCPDP SCRIPT standard, is intended to standardize the portion of an electronic prescription containing the directions for use using existing, accepted electronic transmission standards, such as NCPDP SCRIPT. A ``structured and codified'' Sig conveys instructions in a consistent manner by mapping these directions to a defined set of elements representing the different components of these directions (for instance, dosing schedules and administration instructions). The Structured and Codified Sig Format includes 15 segments, each containing distinct fields to capture potential elements of patient instructions. This is intended to facilitate communication between prescribers and pharmacists, to improve the efficiency of prescribing and dispensing activities, and to help reduce the opportunity for errors. The NCPDP Structured and Codified Sig Format Implementation Guide contains the technical specifications and guidance for implementation of a structured and codified Sig. --------------------------------------------------------------------------- \41\ See https://standards.ncpdp.org/Access-to-Standards.aspx. --------------------------------------------------------------------------- When conducting electronic prescribing, prescribers frequently transmit the Sig Text segment as unstructured free text, which introduces inconsistency and limits reusability of the directions contained in the Sig, with potential impacts on patient safety and [[Page 63527]] clinical outcomes.\42\ Moreover, when unstructured free text is used, prescribers and pharmacists may have to engage in back-and-forth communication to clarify what is intended in the Sig instructions, increasing burden. Research has shown more than half of all Sig directions sent in an ambulatory setting can be accurately represented by only 25 standardized concepts (e.g. the directions ``take 1 tablet by oral route every day'' and ``Take one (1) tablet by mouth once a day'' can both be represented as the same Sig concept ``Take 1 tablet by mouth once daily''), indicating significant opportunities to reduce variation by expressing these directions through the structured and codified Sig format.\43\ --------------------------------------------------------------------------- \42\ Schiff, G., Mirica, M.M., Dhavle, A.A., Galanter, W.L., Lambert, B., & Wright, A. (2018). A prescription for enhancing electronic prescribing safety. Health Affairs (Project Hope), 37(11), 1877-1883. doi:https://doi.org/10.1377/hlthaff.2018.0725. \43\ Yang, Y., Ward-Charlerie, S., Dhavle, A.A., Rupp, M.T., & Green, J. (2018). Quality and Variability of Patient Directions in Electronic Prescriptions in the Ambulatory Care Setting. Journal of managed care & specialty pharmacy, 24(7), 691-699. https://doi.org/10.18553/jmcp.2018.17404. --------------------------------------------------------------------------- Previously, in the 2015 Edition Final Rule, we did not finalize our proposal to require a Health IT Module certified to the ``electronic prescribing'' criterion to enable a user to enter, receive, and transmit codified Sig instructions in a structured format, based on commenters' concerns regarding the readiness of the standard and other issues such as limitations on the length of a Sig within the version of the NCPDP SCRIPT Structured and Codified Sig Format v1.2 available at the time of the proposal (80 FR 62643). We stated that we would reconsider this stance for future rulemaking based on newer versions of the NCPDP SCRIPT Standard Implementation Guide that may provide implementation improvements and finalized an optional certification provision that technology must be able to receive and transmit the reason for the prescription using the indication elements in the SIG segment in Sec. 170.315(b)(3)(i) (80 FR 62643). In the ONC Cures Act Final Rule, we also finalized this optional provision in Sec. 170.315(b)(3)(ii)(D) (85 FR 25686). Since the 2015 Edition Final Rule, NCPDP has further advanced the structured and codified Sig format. The most recent version available is the NCPDP Structured and Codified Sig Implementation Guide version 2.2. The structured and codified Sig segment within the NCPDP SCRIPT standard has also been modified; changes to the Sig element from NCPDP SCRIPT standard version 2017017 are discussed in the NCPDP SCRIPT standard version 2023011 Implementation Guide.\44\ As a result of additional improvements made to the structured and codified Sig format, as well as the additional time that industry has had to grow familiar with this functionality, we believe that it is appropriate to propose in Sec. 170.315(b)(3)(ii)(D) to require that a Health IT Module certified to the ``electronic prescribing'' criterion must enable a user to enter, receive, and transmit structured and codified prescribing instructions in accordance with the standard specified in Sec. 170.205(b)(2) (where we have adopted NCPDP SCRIPT standard version 2023011), at the time a health IT developer presents a Health IT Module for certification using NCPDP SCRIPT standard version 2023011. We propose to remove the optional provision that is currently in Sec. 170.315(b)(3)(ii)(D). --------------------------------------------------------------------------- \44\ See https://standards.ncpdp.org/Access-to-Standards.aspx. --------------------------------------------------------------------------- We request comments on this proposal. RxNorm and National Drug Codes (NDC) In Sec. 170.315(b)(3)(ii)(A) we require that a Health IT Module certified to the ``electronic prescribing'' criterion enable a user to perform specified prescription-related electronic transactions in accordance with a specified minimum version of the RxNorm code set for coding medications, among other standards. RxNorm, a standardized nomenclature for clinical drugs produced by the United States National Library of Medicine (RxNorm), is a drug terminology providing a set of normalized medication names and codes based on a collection of commonly used public and commercial vocabularies of drug names and their ingredients. In section III.B.5. of this proposed rule, we propose to adopt an updated release of RxNorm, specifically, the December 4, 2023, Full Monthly Release, in Sec. 170.207(d)(1)(ii). In section III.B.5. of this proposed rule, we also propose to reorganize section Sec. 170.207(d) to include the versions of RxNorm adopted in Sec. 170.207(d)(1), (2), and (3), under Sec. 170.207(d)(1). For the ``electronic prescribing'' certification criterion, we propose in Sec. 170.315(b)(3)(ii)(A) to remove the existing reference to RxNorm, September 8, 2015 Release in Sec. 170.207(d)(3), and require use of at least one of the versions of the standard adopted in Sec. 170.207(d)(1). If finalized, this reference to Sec. 170.207(d)(1), where we have adopted multiple versions of RxNorm, would permit a health IT developer to use any version of RxNorm that is listed in Sec. 170.207(d)(1) and for which adoption has not expired. This proposal would result in a requirement to use progressively more recent releases of the RxNorm code set as the baseline version of RxNorm which Health IT Modules must use for the ``electronic prescribing'' certification criterion. We also note that under NCPDP SCRIPT standard version 2020011 and greater, including NCPDP SCRIPT standard version 2023011, the National Drug Codes (NDC) element is required on all non-compounded medication electronic prescriptions.\45\ National Drug Codes (NDC) provide a unique identifier for products such as vaccines or medications. Each product is assigned a unique 10- or 11-digit, 3-segment number that identifies the labeler, product, and trade package size. We adopted NDC in Sec. 170.207(d)(4) in the HTI-1 Final Rule (89 FR 1226) via a cross-reference to 45 CFR 162.1002(b)(2) as referenced in 45 CFR 162.1002(c)(1). In section III.B.5 of this proposed rule, we propose to relocate this cross-reference from Sec. 170.207(d)(4) to Sec. 170.207(d)(2) as part of our reorganization of this section. Consistent with the requirement in the NCPDP SCRIPT standard version 2023011 to include NDC with prescriptions, we propose in Sec. 170.315(b)(3)(ii)(A) that a Health IT Module certified to the criterion must enable a user to perform specified prescription-related electronic transactions in accordance with NDC in Sec. 170.207(d)(2). We propose that use of NDC would be required at the time a health IT developer presents a Health IT Module for certification using the NCPDP SCRIPT standard version 2023011 adopted in Sec. 170.205(b)(2). --------------------------------------------------------------------------- \45\ For more information about the updates to NDC in the NCPDP SCRIPT standard see https://ncpdp.org/NCPDP/media/images/Resources%20Items/NDC-Use-eRx-Fact-Sheet.pdf?ext=.pdf. --------------------------------------------------------------------------- Diagnoses (Sec. 170.315(b)(3)(ii)(C)) In Sec. 170.315(b)(3)(ii)(C) we require that a Health IT Module ``must be able to receive and transmit the reason for prescription using the diagnosis elements: or '' for the set of prescription-related transactions identified in Sec. 170.315(b)(3)(ii)(C)(1)-(2). We propose to make changes to the list of required and optional transactions in Sec. 170.315(b)(3)(ii)(C) to reflect the proposed required transactions for the updated version of [[Page 63528]] the certification criterion in Sec. 170.315(b)(3)(ii)(A), and our proposal to remove certain optional transactions from the updated version of the criterion in Sec. 170.315(b)(3)(ii)(B). Specifically, we propose in 170.315(b)(3)(ii)(C)(1) to rename ``Create New Prescriptions (NewRx)'' to ``New Prescriptions (NewRx).'' We propose in Sec. 170.315(b)(3)(ii)(C)(1)(vi) to remove the transaction ``Receive medication history'' (RxHistoryResponse) and reserve this section. We propose in Sec. 170.315(b)(3)(ii)(C)(1)(vii) to require the following electronic prior authorization transactions (PAInitiationRequest, PAInitiationResponse, PARequest, PAResponse, PAAppealRequest, PAAppealResponse and PACancelRequest, PACancelResponse, PANotification) if using NCPDP SCRIPT standard version 2023011 (adopted in Sec. 170.205(b)(2)). Lastly, we propose to remove the optional transactions in Sec. 170.315(b)(3)(ii)(C)(2)(i) through (iv) and reserve this section. We refer readers to Table 1A below in this rule for a comparison of required and optional transactions identified in the current certification criterion based on NCPDP SCRIPT standard version 2017071 and the proposed updated criterion based on NCPDP SCRIPT standard version 2023011. Race and Ethnicity In 2023, the Pharmacy Interoperability and Emerging Therapeutics Task Force provided a recommendation to the HITAC to support interoperability between pharmacy constituents by including race and ethnicity in the ``electronic prescribing'' certification criterion (PhIET-TF-2023_Recommendation 26).\46\ The Task Force stated that demographic data is not always made available through reporting such as case reporting to public health agencies. Yet, in order to support the ability to perform analytics, all data feeds should have relevant race and ethnicity data, and other key demographic data, when available. The Task Force recommended that various prescribing and laboratory results reporting capabilities need to be able to support sharing of the relevant data when an alternative source is not consistently available. Additionally, the Task Force acknowledged that a prescriber will likely already have patient race or ethnicity documented. Exchanging this information through available transactions, such as those included in electronic prescribing, is one way to improve consistency in documentation of demographic data across provider types. --------------------------------------------------------------------------- \46\ See https://www.healthit.gov/sites/default/files/page/2023-11/2023-11-09_PhIET_TF_2023_Recommendations_Transmittal_Letter_508.pdf. --------------------------------------------------------------------------- Specifically, the Task Force recommended ONC include the ability to capture and exchange race and ethnicity as part of the ``electronic prescribing'' certification criterion and point to USCDI v4,\47\ which references the CDC Race & Ethnicity Code System--CDCREC 1.2 (July 2021).\48\ The CDC Race & Ethnicity Code System--CDCREC 1.2 code set facilitates use of Federal standards for classifying data on race and ethnicity when these data are exchanged, stored, retrieved, or analyzed in electronic form. The NCPDP SCRIPT standard version 2023011, which we propose to incorporate in the ``electronic prescribing'' certification criterion in this proposed rule, references reporting of race and ethnicity using the CDCREC 1.2 associated value set ``PHVS_Race_CDC'' version 2 (December 2018 \49\) from the code system code ``PH_RaceAndEthnicity_CDC'' as optional for certain transactions within the standard that we have also proposed to require when using the updated version of the standard. This aligns with the code system code in CDCREC 1.2 which is ``PH_RaceAndEthnicity_CDC,'' and is available on the Public Health Information Network (PHIN) Vocabulary Access and Distribution System (PHIN VADS).\50\ --------------------------------------------------------------------------- \47\ See https://www.healthit.gov/isa/united-states-core-data-interoperability-uscdi. \48\ See https://www.cdc.gov/phin/resources/vocabulary/. \49\ See https://phinvads.cdc.gov/vads/ViewValueSet.action?id=9152A536-AEEC-E711-ACD6-0017A477041A. \50\ See https://phinvads.cdc.gov/vads/ViewCodeSystemConcept.action?oid=2.16.840.1.113883.6.238&code=1579-2. --------------------------------------------------------------------------- Given the importance of the issues described by the Task Force, and the alignment between the recommendation and NCPDP SCRIPT standard version 2023011, we believe that it is appropriate to implement the Task Force recommendation through updates to the ``electronic prescribing'' certification criterion. Therefore, we propose in Sec. 170.315(b)(3)(ii)(B) that a Health IT Module certified to the ``electronic prescribing'' certification criterion must enable a user to exchange race and ethnicity information for a patient when performing the following prescription-related electronic transactions, if using NCPDP SCRIPT standard version 2023011: Receive fill status notifications (RxFill). Request and respond to change prescriptions (RxChangeRequest, RxChangeResponse). Request to cancel prescriptions (CancelRx). Request and respond to renew prescriptions (RxRenewalRequest, RxRenewalResponse). We believe the transactions above are an appropriate starting place to include race and ethnicity in the electronic prescribing certification criterion. We will continue to monitor changes to the SCRIPT standard for additional updates to transactions to include race and ethnicity data fields. We invite comments on this proposal and request information on whether there are other SCRIPT transactions that include data fields for race and ethnicity we should consider specifying to enable exchange of race and ethnicity data with providers in pharmacy settings. Base EHR Definition We note that, given our proposal in section III.B.9.b. to include the proposed ``real-time prescription benefit'' certification criterion in Sec. 170.315(b)(4) in the Base EHR definition in Sec. 170.102, we have also proposed to add the ``electronic prescribing'' certification criterion in Sec. 170.315(b)(3) to the Base EHR definition. Please see section III.B.9.b. of this proposed rule for further details on this proposal. Multi-Factor Authentication We propose in Sec. 170.315(b)(3)(ii)(G) that, on and after January 1, 2028, a Health IT Module certified to Sec. 170.315(b)(3) must meet the multi-factor authentication (MFA) requirements specified in Sec. 170.315(d)(13)(ii) for user-facing authentication. We believe this update is in line with industry information security best practice for an important authentication use case in health IT, and that it is necessary to help better protect electronic health information. We refer readers to section III.B.17 for our proposal to revise our MFA certification criterion Sec. 170.315(d)(13) and for background on the user level authentication use case we are targeting with this requirement. BILLING CODE 4150-45-P [[Page 63529]] [GRAPHIC] [TIFF OMITTED] TP05AU24.000 BILLING CODE 4150-45-C [[Page 63530]]

9. New Real-Time Prescription Benefit Criterion

a. Background The increasing costs of prescription drugs have long been a concern for patients, providers, and policymakers.\51\ Increased drug costs can have several negative consequences for patients, including limited access to healthcare,\52\ lower healthcare use,\53\ medication nonadherence 54 55 and financial stress, especially among underserved,\56\ uninsured and underinsured \57\ populations. Merely having health insurance coverage does not necessarily confer medication affordability on patients.\58\ These challenges continue to be the focus of legislation, such as the Inflation Reduction Act of 2022 (Pub.

L. 117-169, August 16, 2022), which includes several provisions that

are expected to decrease prescription drug costs and improve access to prescription drugs for the more than 65 million Americans enrolled in the Medicare program, including allowing Medicare to directly negotiate prescription drug prices for the first time, eliminating cost sharing for adult vaccines, capping out-of-pocket costs for insulin, and capping Part D enrollee out-of-pocket spending at $2,000 annually starting in 2025 (see sections 11406, 11401, 1194, and 11201). E. O. 14087, Lowering Prescription Drug Costs for Americans, directed further actions to lower the cost of prescription drugs. --------------------------------------------------------------------------- \51\ A.S. Kesselheim, J. Avorn, A. Sarpatwari, The high cost of prescription drugs in the United States: origins and prospects for reform. JAMA, 316 (8) (2016), pp. 858-871. \52\ Daher, Al Rifai, M., Kherallah, R. Y., Rodriguez, F., Mahtta, D., Michos, E. D., Khan, S. U., Petersen, L. A., & Virani,

S. S. (2021). Gender disparities in difficulty accessing healthcare

and cost-related medication non-adherence: The CDC behavioral risk factor surveillance system (BRFSS) survey. Preventive Medicine, 153, 106779-106779. https://www.ncbi.nlm.nih.gov/pmc/articles/PMC9291436/. \53\ Roebuck, Liberman, J. N., Gemmill-Toyama, M., & Brennan, T.

A. (2011). Medication adherence leads to lower health care use and

costs despite increased drug spending. Health Affairs, 30(1), 91-99. https://doi-org.ezproxyhhs.nihlibrary.nih.gov/10.1377/hlthaff.2009.1087. \54\ SG Morgan, A. Lee. Cost-related non-adherence to prescribed medicines among older adults: a cross-sectional analysis of a survey in 11 developed countries. BMJ Open, 7 (1) (2017), Article e014287. \55\ DiMatteo MR, Giordani PJ, Lepper HS, Croghan TW. Patient adherence and medical treatment outcomes: a meta-analysis. Med Care. 2002; 40 (9): 794-811. \56\ Whaley C, Reed M, Hsu J, Fung V (2015) Functional Limitations, Medication Support, and Responses to Drug Costs among Medicare Beneficiaries. PLoS ONE 10(12): e0144236. https://doi.org/10.1371/journal.pone.0144236. \57\ Collins SR, Rasmussen PW, Beutel S, Doty MM. The problem of underinsurance and how rising deductibles will make it worse: findings from the Commonwealth Fund Biennial Health Insurance Survey, 2014. New York: Commonwealth Fund; 2015. \58\ Zhao, J., Zheng, Z., Han, X., Davidoff, A. J., Banegas, M. P., Rai, A., Jemal, A., & Yabroff, K. R. (2019). Cancer History, Health Insurance Coverage, and Cost-Related Medication Nonadherence and Medication Cost-Coping Strategies in the United States. Value in health: the journal of the International Society for Pharmacoeconomics and Outcomes Research, 22(7), 762-767. https://doi.org/10.1016/j.jval.2019.01.015. --------------------------------------------------------------------------- Research also suggests provider-patient discussions during clinical encounters about costs and affordability may lead to an overall reduction in out-of-pocket costs.\59\ Real-time prescription benefit tools empower providers and their patients to compare the patient- specific cost of a drug to the cost of a suitable alternative, compare prescription costs at different pharmacy locations, view information about out-of-pocket costs, and learn whether a specific drug is subject to utilization management restrictions such as prior authorization, step therapy, or quantity limits. We believe, when appropriate, use of these tools can allow the provider and patient to choose among clinically acceptable alternative medication treatments while weighing coverage and point-in-time costs. Access to this data within the electronic prescribing workflow may also help to reduce provider burden associated with coverage determination and prior authorization appeals. We believe widespread adoption of such tools, along with increased awareness of drug cost information among patients and providers will likely spur more robust evaluations over time. --------------------------------------------------------------------------- \59\ Carroll JK, Farah S, Fortuna RJ, et al. Addressing medication costs during primary care visits: a before-after study of team-based training. Ann Intern Med. 2019;170(suppl 9): S46-S53. doi:10.7326/M18-2011. --------------------------------------------------------------------------- Section 119 of Title I, Division CC of the Consolidated Appropriations Act of 2021, (Pub. L. 116-260, December 27, 2020) (CAA, 2021), requires sponsors of prescription drug plans to implement one or more real-time benefit tools (RTBTs) after the Secretary has adopted a standard for RTBTs and at a time determined appropriate by the Secretary. The law specified that a qualifying RTBT must meet technical standards named by the Secretary, in consultation with ONC. Section 119(b) also amended the definition of a ``qualified electronic health record'' in section 3000(13) of the Public Health Service Act (PHSA) to specify that a qualified electronic health record ``includes, or is capable of including, a real-time benefit tool that conveys patient- specific real-time cost and coverage information with respect to prescription drugs that, with respect to any health information technology certified for electronic prescribing, the technology shall be capable of incorporating the information described in clauses (i) through (iii) of paragraph (2)(B) of section 1860D-4(o) of the Social Security Act.'' The information specified in (2)(B)(i)-(iii) of section 1860D-4(o) of the Social Security Act, as added by section 119(a) of the CAA, 2021, is: A list of any clinically appropriate alternatives to such drug included in the formulary of such plan. Cost-sharing information and the negotiated price for such drug and such alternatives at multiple pharmacy options, including the individual's preferred pharmacy and, as applicable, other retail pharmacies and a mail order pharmacy; and The formulary status of such drug and such alternatives and any prior authorization or other utilization management requirements applicable to such drug and such alternatives included in the formulary of such plan. The provision further specifies that the change to the definition of a ``qualified electronic health record'' shall be implemented ``at a time specified by the Secretary but not before the Secretary adopts a standard for such tools.'' In the HTI-1 Proposed Rule (88 FR 23848 through 23855), we included a request for information (RFI) about issues related to establishing a real-time prescription benefit certification criterion utilizing the NCPDP Real-Time Prescription Benefit (RTPB) standard, and ways in which the Program could ensure real-time prescription benefit capabilities are implemented effectively for providers. We received many comments on this RFI and appreciate the input provided by commenters. In order to implement section 119(b) of the CAA, 2021, we propose to establish a ``real-time prescription benefit'' health IT certification criterion in Sec. 170.315(b)(4) and to include this certification criterion in the Base EHR definition in Sec. 170.102(3)(iv). b. Revision to the Base EHR Definition and Health IT Module Dependent Criteria Requirements As noted above, section 119(b) of the CAA, 2021, amended the definition of a ``qualified electronic health record'' (Qualified EHR) in section 3000(13) of the PHSA to specify that a qualified electronic health record ``includes, or is capable of including, a real-time benefit tool that conveys patient-specific real-time cost and coverage information with respect to prescription drugs.'' In the 2014 Edition Final Rule, we established the term ``Base EHR,'' based on the Qualified EHR definition in PHSA [[Page 63531]] section 3000(13), for use within the Program (77 FR 54262). We define Base EHR in Sec. 170.102, and this definition currently includes certification criteria under the Program that align with the elements of the Qualified EHR definition in the PHSA. Given that the statutory definition of Qualified EHR is implemented in regulation through the Base EHR definition in Sec. 170.102, we believe it is necessary to propose to update the Base EHR definition consistent with Congress' modification of the statutory definition of Qualified EHR to address real-time benefit tool functionality. Specifically, consistent with PHSA section 3000(13), as amended by section 119(b) of the CAA, 2021, we propose to revise the Base EHR definition in Sec. 170.102 to add paragraph (3)(iv) to include the real-time prescription benefit certification criterion proposed in Sec. 170.315(b)(4) on and after January 1, 2028. We believe including the ``real-time prescription benefit'' certification criterion as part of the Base EHR definition will increase the use of real-time prescription benefit tools and promote widespread adoption which will help to lower drug costs for Medicare beneficiaries, consistent with section 119 of the CAA. Use of real-time prescription benefit tools enable Medicare providers and enrollees to make cost-informed decisions about prescriptions, and a standardized approach will ensure that critical drug and drug price data is available to providers when they need it. We note that in the Part D and Health IT Standards Final Rule CMS finalized to require Part D plan sponsors to adhere to NCPDP RTPB standard version 13 as part of requirements to provide a prescriber real-time benefit tool by January 1, 2027 in the Part D and Health IT Standards Final Rule (89 FR 51259 and 51260). We request comment on whether we should seek to align the date when the ``real-time prescription benefit'' certification criterion in Sec. 170.315(b)(4) would be effective for the Base EHR definition (proposed to be January 1, 2028) with the date finalized in the Part D and Health IT Standards Final Rule for Part D plan sponsors' real-time benefit tools to adhere to the NCPDP RTPB standard version 13 (January 1, 2027) (89 FR 51260). The amended definition of a Qualified EHR in PHSA section 3000(13)(c) further specifies that ``with respect to any health information technology certified for electronic prescribing, the technology shall be capable of incorporating the information described in clauses (i) through (iii) of paragraph (2)(B).'' We interpret this provision to mean, for the purposes of the Program, that any health IT presented for certification for electronic prescribing capabilities should also be capable of incorporating the real-time benefit information specified in clauses (i) through (iii) of paragraph (2)(B) of section 1860D-4(o) of the Social Security Act, as described above. Real-time prescription benefit functionality is closely related to electronic prescribing functionality, which provides the basic workflow within which a provider may seek to identify information about a patient's coverage for a certain prescription before transmitting that electronic prescription to the pharmacy. In most cases, we expect health IT developers seeking certification to Sec. 170.315(b)(4) will already be certified to Sec. 170.315(b)(3), though there will be some variation due to the modularity of Program criteria. Accordingly, we propose to revise Sec. 170.550(g) to add paragraph (g)(6) in order to require that any developer that obtains certification for the ``electronic prescribing'' certification criterion in Sec. 170.315(b)(3) must also obtain certification for the proposed ``real- time prescription benefit'' criterion in Sec. 170.315(b)(4). While we propose to establish this dependency with the ``electronic prescribing'' certification criterion, this certification criterion is not included as part of the current Base EHR definition in Sec. 170.102. Although electronic prescribing is a widely used and fundamental capability of health IT, we have, to date, not included this certification criterion in the Base EHR definition for several reasons. First, the Qualified EHR definition in section 3000(13) of the PHSA does not specify electronic prescribing as a required element of a Qualified EHR and we have generally sought to limit the Base EHR definition in Sec. 170.102, which implements the Qualified EHR definition, to those capabilities that are required for the Qualified EHR definition by statute. Second, many health care providers have historically been required to adopt certified technology for electronic prescribing in order to meet the requirements of the Medicare EHR Incentive Programs, now known as the Medicare Promoting Interoperability Program and the Promoting Interoperability performance category of the Merit-Based Incentive Payment System (MIPS).\60\ Objectives and measures for eligible professionals, eligible hospitals, and CAHs under these programs have included measures related to electronic prescribing throughout the course of the programs. Section 1848(o)(2)(A)(i) of the Social Security Act also requires that demonstration of use of certified EHR technology in a meaningful manner by an eligible professional ``shall include the use of electronic prescribing.'' --------------------------------------------------------------------------- \60\ The Medicaid EHR Incentive Program sunset in 2021 (84 FR 42592). --------------------------------------------------------------------------- However, given our proposal to include the proposed ``real-time prescription benefit'' certification criterion in Sec. 170.315(b)(4) in the Base EHR definition, we believe it is also appropriate to add the ``electronic prescribing'' certification criterion in Sec. 170.315(b)(3) to the Base EHR definition. While we previously did not include this capability in the Base EHR definition for the reasons described above, we believe that the inclusion of closely related ``real-time prescription benefit'' functionality in Sec. 170.315(b)(4) necessitates the inclusion of electronic prescribing functionality. We therefore propose to include the ``electronic prescribing'' certification criterion in Sec. 170.315(b)(3) within the Base EHR definition in Sec. 170.102. We further propose to specify that this criterion would be effective for the Base EHR definition on and after January 1, 2028, which aligns with the date when the proposed ``real- time prescription benefit'' certification criterion in Sec. 170.315(b)(4) would be effective for the Base EHR definition. We request comment on these proposals, especially regarding the impact of these proposals on health IT developers seeking to ensure their products meet the Base EHR definition that are not currently separately certified to the ``electronic prescribing'' criterion. We seek information on the additional burden to developers of requiring the ``electronic prescribing'' certification criterion as part of the Base EHR definition in addition to the proposed ``real-time prescription benefit'' certification criterion. We also request comment on the implications for interoperability of electronic prescribing if we were to finalize our proposal to include the ``real-time prescription benefit'' certification criterion within the Base EHR definition but not finalize our proposal to include the ``electronic prescribing'' certification criterion in the Base EHR definition. Lastly, we request comment on the impact this proposed policy would have on any health care providers participating in the Medicare Promoting Interoperability Program and the Promoting Interoperability performance category of the Merit-Based Incentive Payment System (MIPS) who have historically been able to claim an exclusion from electronic prescribing [[Page 63532]] measures in these programs, and, as a result have not adopted certified health IT for electronic prescribing in order to complete the actions associated with these measures. The definitions of certified EHR technology at 42 CFR 495.4 and 42 CFR 414.1305, which define technology requirements for these programs, cross-reference the Base EHR definition at 45 CFR 171.102. Thus, as a result of the statutory change implemented by Congress, and if our proposals to add these certification criteria to the Base EHR definition are finalized, all providers participating in these programs would have to have at a minimum, health IT certified to the proposed ``real-time prescription benefit'' certification criterion and the ``electronic prescribing'' certification criterion. This would include participants that currently successfully participate in these programs without possessing certified health IT that supports these capabilities. We request comment on whether finalizing these proposals would impose significant burden on these health care providers. c. Real-Time Prescription Benefit Standard We propose in Sec. 170.315(b)(4)(i) that a Health IT Module certified to the proposed ``real-time prescription benefit'' certification criterion must enable a user to perform certain real-time prescription benefit electronic transactions in accordance with at least one of the versions of the standard adopted in Sec. 170.205(c). Under this paragraph, ONC adopted the NCPDP RTPB standard version 13 \61\ on behalf of HHS in Sec. 170.205(c)(1) in the Part D and Health IT Standards Final Rule, which appeared in the Federal Register on June 17, 2024 (89 FR 51238 through 51265). If we adopt subsequent versions of the NCPDP RTPB standard in Sec. 170.205(c), our proposal to require the use of at least one of the versions of the standard adopted in Sec. 170.205(c) would enable health IT developers to use any version of the standard adopted under this paragraph, unless we specify an adoption ``expiration'' date which indicates a certain version of the standard may no longer be used after that date. --------------------------------------------------------------------------- \61\ See https://standards.ncpdp.org/Access-to-Standards.aspx. --------------------------------------------------------------------------- The NCPDP RTPB standard version 13 enables the exchange of patient eligibility, product coverage, and benefit financials for a chosen product and pharmacy, and identifies coverage restrictions and alternatives when they exist. The benefits of the more recent NCPDP RTPB standard version 13 relative to NCPDP RTPB standard version 12 include improvements to the NCPDP RTPB Patient Segment, Product and Alternative Product Segments, and new elements, new values, and updated values to the schema, as well as administrative corrections that support consistency and clarity. Because the NCPDP RTPB standard is relatively new and not yet widely implemented, we expect additional enhancements and improvements to the standard over time as more health IT developers adopt and implement the standard and more exchange partners engage in the standards development process with NCPDP. We encourage developers to remain familiar with updates occurring in newer versions of the NCPDP RTPB standard. d. Sending and Receiving Real-Time Prescription Benefit Information In order to execute real-time prescription benefit checks in accordance with the NCPDP RTPB standard version 13, a provider originates the request for prescription benefit information for a specific patient from within their health IT. In return, a processor, pharmacy benefit manager, or adjudicator provides the appropriate response. We propose in Sec. 170.315(b)(4)(i) that a Health IT Module certified to the ``real-time prescription benefit'' criterion must enable a user to perform specified transactions in accordance with at least one of the versions of the standard adopted in Sec. 170.205(c) (where we have adopted the NCPDP RTPB standard version 13), as well as one of the versions of the standard in Sec. 170.207(d)(1) (where we have adopted RxNorm) and the standard in Sec. 170.207(d)(2) (where we have cross-referenced National Drug Codes (NDC)). We propose in Sec. 170.315(b)(4)(i)(A) that a Health IT Module certified to the proposed criterion must enable a user to request patient-specific prescription benefit information, estimated cost information, and therapeutic alternatives, in accordance with the RTPBRequest transaction. We propose in Sec. 170.315(b)(4)(i)(B) that a Health IT Module certified to the proposed criterion must enable a user to receive patient-specific prescription benefit information, estimated cost information, and therapeutic alternatives in response to a request, in accordance with the RTPBResponse transaction. RTPBRequest and RTPBResponse transactions are determined by patient, benefit, and product-specific information. Each request and response are unique with information conditioned on factors associated with each transaction. Health IT Modules certified to the proposed certification criterion should support transaction segments and associated data elements necessary to reflect both the information needed for a successful RTPBRequest and the information contained in a detailed RTPBResponse. As such, a Health IT Module must have the capability to send and receive both mandatory and situational transaction segments and associated data elements for RTPBRequests and RTPBResponse transactions as specified in NCPDP RTPB standard version 13. Finally, we propose in Sec. 170.315(b)(4)(i)(C) that a Health IT Module certified to the proposed criterion must enable a user to be notified of errors when there is a problem with a real-time prescription benefit transaction, in accordance with the RTPBError transaction. We request comments on these proposals and whether we should consider other capabilities for the certification criterion in the future. Use of XML Format We propose in Sec. 170.315(b)(4)(i) that a Health IT module certified to the criterion must enable a user to perform the specified transactions using the XML format. While the NCPDP RTPB standard version 13 supports both EDI and XML formats, in response to the RFI included in the HTI-1 Proposed Rule (88 FR 23746), we received many comments in support of testing the XML format of the RTPB standard alone or with the EDI format as optional. Additionally, commenters recommended that ONC should test the format each individual health IT developer has chosen for its own system to be tested in. Some commentors also shared a desire to move away from XML and EDI altogether, preferring the JSON format instead, noting industry plans for the future retirement of XML and EDI. One commenter suggested certification in either format, with requirements that health IT be capable of demonstrating translation capabilities between EDI and XML. After considering these comments, we believe that proposing to only require use of the XML format will simplify testing for health IT developers. ONC will continue to monitor syntax and format updates and development for real-time benefit transactions and associated standards. e. Additional Topics Display We propose in Sec. 170.315(b)(4)(ii) that a Health IT Module certified to the criterion must display to a user in [[Page 63533]] human readable format patient-specific prescription benefit information, estimated cost information, and therapeutic alternatives in accordance with at least one of the versions of the standard in Sec. 170.205(c) (where we have adopted NCPDP RTPB standard version 13). The ability to display RTPB data provides access to this information and is essential for a user to be able to use the information to inform shared decision-making as the provider and patient determine the treatment that will be best for them. Scope The NCPDP RTPB standard version 13 supports real-time prescription benefit requests and responses for a variety of items manufactured for sale such as medications, vaccines, and medical devices or supplies.\62\ While the majority of products covered by an individual's pharmacy benefit will be medications, Part D drugs, as defined at 42 CFR 423.100, can include prescription medications, vaccines, and supplies associated with the injection of insulin (e.g., syringes, alcohol pads, gauze), and are represented by RXCUIs \63\ on the formulary file. --------------------------------------------------------------------------- \62\ See https://www.ncpdp.org/Access-to-Standards.aspx. \63\ An RXCUI is a machine-readable code or identifier that points to the common meaning shared by the various source names grouped and assigned to a particular concept. More information can be found at https://www.nlm.nih.gov/research/umls/rxnorm/overview.html. --------------------------------------------------------------------------- In the HTI-1 Proposed Rule we requested comment on the appropriate scope for a ``real-time prescription benefit'' certification criterion, including whether a ``real-time prescription benefit'' certification criterion should require support for products that are not defined as medications but may also be included in a RTPB transaction, namely vaccines and medical devices or supplies (87 FR 23853). We received several comments in response to our request for information on this topic, with several commenters encouraging an initial focus on medications for the certification criterion. In addition to medications, we believe it is important to require Health IT Modules certified to the ``real-time prescription benefit'' criterion to be able to support vaccines, and note that under Part D regulations and guidance, plans include most commercially available vaccines on their formularies.\64\ However, we are not proposing to include devices and supplies in the proposed certification criterion at this time. We note that the NCPDP RTPB standard version 13 does yet not support the FDA Unique Device Identification System unique device identifiers (UDIs), which are identified as the standard for the Unique Device Identifier--Implantable data element in the Medical Devices data class in the USCDI.\65\ Additionally, devices covered under a pharmacy benefit may be defined as a drug under Section 201(g) of the Federal Food, Drug, and Cosmetic Act (21 U.S.C. 321(h)) rather than a device under Section 201(h) and therefore are not assigned a Unique Device Identifier for Implantable Devices. ONC will continue to monitor advancements to the NCPDP RTPB standard to support unique identifiers for devices, any related developments at the FDA, and updates to the standardization and exchange of device and supplies data. --------------------------------------------------------------------------- \64\ See ``Medicare Prescription Drug Benefit Manual: Chapter 6--Part D Drugs and Formulary Requirements'' 30.2.7 at https://www.cms.gov/medicare/prescription-drug-coverage/prescriptiondrugcovcontra/downloads/part-d-benefits-manual-chapter-6.pdf. \65\ See USCDI v4: https://www.healthit.gov/isa/taxonomy/term/821/uscdi-v4. --------------------------------------------------------------------------- In summary, we propose in Sec. 170.315(b)(4)(iii) that scope of the criterion is limited to medications and vaccines covered by a pharmacy benefit. We invite comments on this proposal. Formulary and Benefit In the HTI-1 Proposed Rule, we requested comment on whether we should further explore capabilities for Health IT Modules to support access to formulary and benefits information and provided detail about how access to formulary and benefits information was previously supported within the Program. We noted that in the 2015 Edition Final Rule, ONC included a ``Drug-formulary and preferred drug list checks'' certification criterion in Sec. 170.315(a)(10). However, ONC did not adopt the proposed NCPDP Formulary and Benefit standard version 3.0 to support this criterion due to comments received in response to the 2015 Edition Proposed Rule (80 FR 16821). The drug formulary and preferred drug list checks Sec. 170.315(a)(10) certification criterion was later removed from the Program in the ONC Cures Act Final Rule (85 FR 25660) because this functionality was widely available, and there was not sufficient reason to justify the burden on developers and providers of meeting Program compliance requirements specific to this criterion. We noted that updates, enhancements, and corrections have been made to the NCPDP Formulary and Benefit standard since we considered adopting version 3.0, and many of these updates addressed concerns commenters expressed previously (87 FR 23854). Subsequently, in the Part D and Health IT Standards Final Rule, we finalized adoption of NCPDP Formulary and Benefit standard version 60 in Sec. 170.205(u) (89 FR 51260), reflecting an aligned approach with the Part D Program to adoption of standards that support electronic prescribing. In the same rulemaking, CMS finalized to cross-reference NCPDP Formulary and Benefit standard version 60 in the requirements for transmitting formulary and benefit information between prescribers Part D sponsors proposed at 42 CFR 423.160(b)(3) (89 FR 51250 and 51251). However, we did not make any updates to the Program to incorporate the proposed Formulary and Benefit standard as part of certification criteria. In response to our request for comment in the HTI-1 Proposed Rule, some commenters supported incorporation of capabilities to access formulary and benefits information within the Program based on the NCPDP Formulary and Benefit standard. However, many stated that a certification criterion based on the standard is not necessary as this functionality is already widespread in the industry due to existing CMS regulatory requirements. Furthermore, these commenters stated that a criterion based on the NCPDP Formulary and Benefit standard may limit innovation around other approaches to obtaining formulary and benefit information currently being explored by the industry. We have considered the comments received in response to the RFI and have determined not to propose new functionality related to formulary and benefits information within the Program at this time. We also note that we have proposed to adopt the HL7 FHIR Da Vinci--Payer Data Exchange (PDex) US Drug Formulary Implementation Guide, version 2.0.1-- STU 2, in Sec. 170.215(m)(i) in this proposed rule and have referenced this standard as part of the ``patient access API'' certification criterion proposed in Sec. 170.315(g)(30)(iii). Negotiated Price Section 1860D-4(o)(2)(B)(ii) of the Social Security Act, as added by section 119(a) of the CAA, 2021, specifically requires real-time benefit tools capable of providing information on ``cost-sharing information and the negotiated price'' for drugs and alternatives. However, we note that we have not proposed to include negotiated price in the proposed Sec. 170.315(b)(4) certification criterion. The NCPDP RTPB [[Page 63534]] standard version 13 does not include fields to support the exchange of negotiated price. We solicited comments regarding negotiated price in response to the RFI, and commenters expressed strong disapproval for the inclusion of negotiated price in RTBTs. Additionally, concerns were shared that plan negotiated prices may be confusing to providers and patients and are not likely to assist or improve the utility or usability of technology certified to a real-time prescription benefit certification criterion. We also note that CMS does not require the exchange of negotiated price by Part D sponsors when implementing an electronic real-time benefit tool. NCPDP RTPB standard version 13, which we have proposed to incorporate into the proposed ``real-time prescription benefit'' certification criterion, is the best available standard for use currently to provide patient specific cost-sharing information. Unfortunately, we have not identified a standard or any consistent approach to deliver reliable negotiated price information in real-time. ONC will continue to work with CMS and other interested parties to determine how negotiated price information may be made available and what technical approaches exist to support transparency in negotiated prices of drugs. 10. Electronic Health Information (EHI) Export--Single Patient EHI Export Exemption a. Background In the ONC Cures Act Final Rule (85 FR 25690 through 25700), we finalized a new certification criterion in Sec. 170.315(b)(10) for Electronic Health Information (EHI) Export. The certification criterion's conformance requirements were intended to support two contexts in which we believe that all EHI produced and electronically managed by a developer's technology should be made readily available for export as a capability of certified health IT. First, we finalized in Sec. 170.315(b)(10)(i) that health IT certified to this criterion must support single patient EHI export upon a valid request by a patient or a user on the patient's behalf. Second, we finalized in Sec. 170.315(b)(10)(ii) that the product would support the export of all EHI when a health care provider chooses to transition or migrate information to another health IT system. Furthermore, we established in Sec. 170.402(a)(4), as part of the Assurances Condition of Certification requirement, that any certified Health IT Module that is part of a health IT product which electronically stores EHI must certify to the certification criterion in Sec. 170.315(b)(10). For the single patient EHI export functionality, we also established in Sec. 170.315(b)(10)(i)(B) that a user must be able to execute this capability at any time the user chooses and without subsequent developer assistance to operate. Subsequently, ONC has heard from developers that some certified Health IT Modules act primarily as intermediaries between systems and, through integration, function without any direct human interaction. As an example, a Health IT Module may facilitate public health reporting by processing existing EHI into a required format for report submission without any user interactions. In such circumstances, a human user may not interact with the certified Health IT Module itself; and even though the Health IT Module stores EHI or causes EHI to be stored, this EHI may be a differently formatted copy of the EHI that already exists in a different, yet integrated, certified Health IT Module. b. Proposal for EHI Export ONC continues to believe that access to EHI export in such circumstances is critical. However, we recognize the potential burden in requiring the technology development and implementation of functionality to execute the capability of single patient EHI export at any time the user chooses and without subsequent developer assistance to operate, as established in Sec. 170.315(b)(10)(i)(B), for those products that act primarily as intermediaries between systems and, through integration, function without any direct human interaction. Therefore, we propose to exempt Health IT Modules that act primarily as intermediaries between systems and, through integration, function without any direct human interaction from the requirement in Sec. 170.315(b)(10)(i)(B) to provide functionality without subsequent developer assistance to operate. We propose this new exemption in Sec. 170.315(b)(10)(i)(F), and we caveat the availability of this exemption in two ways. First, in Sec. 170.315(b)(10)(i)(F)(1) we propose to require that the EHI stored, or caused to be stored, by the Health IT Module certified to Sec. 170.315(b)(10) must be a copy, whether in the same or another format, of EHI also stored by another Health IT Module with which the Health IT Module certified to Sec. 170.315(b)(10) is integrated. Second, in order to ensure that such an exemption is appropriately limited to Health IT Modules that primarily function without user interaction and from which users would only rarely seek single patient EHI export consistent with Sec. 170.315(b)(10)(i), we further propose in Sec. 170.315(b)(10)(i)(F)(2) that any Health IT Module for which the developer receives more than 10 requests in the immediately preceding calendar year for a single patient EHI export would no longer qualify for this exemption and would need to provide functionality under Sec. 170.315(b)(10)(i)(B) without subsequent developer assistance to operate. For purposes of this exemption, we clarify that requests for a single patient EHI export would be counted at the product-level rather than the individual instance-level. This means any request made across all deployed settings or deployed instances of the Health IT Module would count towards this proposed threshold. We note that the developer must still meet all other requirements in Sec. 170.315(b)(10), but that such an exemption would allow them flexibility in how single patient EHI export is provided under Sec. 170.315(b)(10)(i), including providing the export with developer assistance similar to how they provide patient population EHI export under Sec. 170.315(b)(10)(ii). We note that the limited circumstance defined here would not be applicable to health information exchanges or networks. ONC believes that patients and users assisting patients have a continued need for access to all single patient EHI, and products in which EHI is aggregated (such as health information exchanges and networks) should facilitate full and unfettered access to such information. We welcome comments on this proposal, including on the threshold of 10 requests across all deployed settings (or deployed instances) of the Health IT Module per calendar year to qualify for the exemption. c. Proposal for Associated Assurances Requirements for Single Patient EHI Export Exemption To ensure that a developer of certified health IT with a Health IT Module certified to Sec. 170.315(b)(10) does not inappropriately use the proposed exemption for single patient EHI export in Sec. 170.315(b)(10)(i)(F) to block information or inhibit the appropriate access, exchange, and use of EHI, we propose a new Assurances Maintenance of Certification requirement. We propose in Sec. 170.402(b)(2)(iii) that developers of certified health IT with Health IT Modules certified to Sec. 170.315(b)(10) that claim the exemption proposed in [[Page 63535]] Sec. 170.315(b)(10)(i)(F) would need to report the number of requests for single patient EHI export on an annual basis to their ONC-ACB(s). Specifically, in Sec. 170.402(b)(2)(iii)(A) we propose that on and after January 1, 2028, a health IT developer of a Health IT Module certified to the certification criterion in Sec. 170.315(b)(10) and meets the requirements of paragraph (b)(10)(i)(F) must report to its ONC-ACB no later than March 1 of each calendar year how many requests it received during the immediately preceding calendar year. We welcome comments on this proposal. 11. Revised End-User Device Encryption Criterion a. Background In the final rule titled ``Health Information Technology: Standards, Implementation Specifications, and Certification Criteria for Electronic Health Record Technology, 2014 Edition; Revisions to the Permanent Certification Program for Health Information Technology'' (2014 Edition Final Rule) we included end-user device encryption requirements in Sec. 170.315(d)(7) focused on designing EHR technology to secure EHI on end-user devices in accordance with the approach recommend by the Health IT Standards Committee (HITSC) at the time (77 FR 54236). Since finalizing this certification criterion in the 2014 Edition Final Rule, encryption technology has continued to advance significantly, and we have identified a gap in our current requirements, which only include end-user device encryption requirements and exclude server-side encryption requirements. When finalizing our end-user device encryption requirements in Sec. 170.315(d)(7) in the 2014 Edition Final Rule, we posited that end-user device encryption was ``more practical, effective and easier to implement'' than the general encryption requirement we had finalized originally in the ONC 2011 Edition certification criteria, which included server encryption requirements (77 FR 54236). Encryption technology and availability have significantly improved in the time since the 2014 Edition Final Rule. For example, developers using Microsoft Windows Server version 2016 and later versions have BitLocker disk encryption software readily available, and Linux-based server developers have free and open-source disk encryption utilities like Cryptsetup.\66\ These tools, and others like them, make it easy for server developers to take advantage of the numerous benefits of server encryption. --------------------------------------------------------------------------- \66\ Microsoft documentation explaining how to deploy BitLocker disk encryption on Windows Server 2016 and later: https://docs.microsoft.com/en-us/windows/security/information-protection/bitlocker/bitlocker-how-to-deploy-on-windows-server. Homepage for the Cryptsetup utility that can be used for Linux hard disk encryption: https://gitlab.com/cryptsetup/cryptsetup/. Note that these tools would need to be configured to use Approved Security Functions for FIPS PUB 140-2 to meet ONC's proposed server encryption requirements outlined later in this section. Approved Security Functions for FIPS PUB 140-2 are here: https://csrc.nist.gov/files/pubs/fips/140-2/upd2/final/docs/fips1402annexa.pdf. --------------------------------------------------------------------------- Encryption of server-side data prevents unauthorized data access in many scenarios, including those involving a server breach, theft, or improper disposal. Mitigating these risks using encryption is a best practice for all server developers and, given the unique characteristics of EHI, is especially important for health IT server developers. EHI is considered one of the most valuable types of personal information for theft because of the breadth of information included in electronic health records and the long shelf life of this information. However, despite its high value, EHI often is not being properly protected, and the problem is getting worse according to data published on the Department of Health and Human Services Office for Civil Rights (OCR) website. Between 2010 and 2022, OCR received 5,144 reports of breaches affecting 500 or more individuals, impacting a total of 394,236,737 individuals.\67\ The frequency of breaches affecting 500 individuals or more has increased significantly over the past few years, with almost two such breaches reported per day in 2022, nearly double the frequency in 2018.\68\ These statistics indicate that vulnerabilities and risks exist in technology storing EHI in the United States. While no single solution can fully protect EHI, data breach risks can be mitigated by encryption of data maintained on servers. --------------------------------------------------------------------------- \67\ See https://ocrportal.hhs.gov/ocr/breach/breach_report.jsf. These numbers are based on breach reports made to OCR as of May 17, 2024. \68\ See https://ocrportal.hhs.gov/ocr/breach/breach_report.jsf. These numbers are based on breach reports made to OCR as of May 17, 2024. --------------------------------------------------------------------------- b. Proposal To better protect electronic health information stored in Health IT Modules certified under the Program, we propose to clarify the scope of information that needs to be protected in Health IT Modules certified to Sec. 170.315(d)(7) and revise the order and sequence of existing requirements in Sec. 170.315(d)(7) to include new requirements for server-side encryption. First, to clarify the scope of electronic health information that needs to be protected in Health IT Modules certified to Sec. 170.315(d)(7), we propose that on and after January 1, 2026 the information that must be protected within Health IT Modules certified to this revised criterion in Sec. 170.315(d)(7) include all personally identifiable information (PII). This includes, but is not limited to, individually identifiable health information meeting the definition of electronic protected health information in 45 CFR 160.103, regardless of whether the information is held by or for a HIPAA covered entity or entity required to comply with the Privacy Act of 1974 (5 U.S.C. 552a), as amended. Second, we propose to revise existing requirements in Sec. 170.315(d)(7) to include new requirements for server-side encryption and include the PII encryption requirements for servers in a way that maintains our existing end-user device encryption requirements and applies the existing encryption standard and the default settings requirements broadly in one criterion. We propose to change the name of Sec. 170.315(d)(7) to ``health IT encryption,'' to better describe the end-user and proposed server-side requirements together. We also propose moving our existing end-user device encryption requirements, in Sec. 170.315(d)(7)(i) and (ii), into paragraph Sec. 170.315(d)(7)(i) that expires on January 1, 2026 and is replaced by a new PII encryption requirement for end-user devices in Sec. 170.315(d)(7)(ii) that must be met on and after January 1, 2026. Additionally, we propose including the new server-side encryption requirement in Sec. 170.315(d)(7)(iii) that must be met on and after January 1, 2026. We propose that this new server encryption requirement in Sec. 170.315(d)(7)(iii) state that technology designed to store PII must encrypt the stored PII after use of the technology on those servers stops. We also propose to move the encryption standard and default settings requirements that are currently in Sec. 170.315(d)(7)(i)(A) and (B) respectively into their own higher-level sections in Sec. 170.315(d)(7)(iv) and (v) respectively. Additionally, we propose that these encryption standard and default settings requirements apply to the new server encryption requirement. Pointing to an encryption standard and requiring that default settings be in place for encryption capabilities in Sec. 170.315(d)(7) is consistent with our existing requirements for end-user device encryption, and we believe these [[Page 63536]] settings are necessary for our proposed new server encryption requirement as well. While certain conformance requirements within the proposed Sec. 170.315(d)(7) have been reorganized, as is outlined in the previous paragraphs, health IT developers with Health IT Modules certified to this criterion will continue to have traceability. If we were to finalize the updates to Sec. 170.315(d)(7) as proposed, developers with Health IT Modules already certified to Sec. 170.315(d)(7) would only need to consider updates to the applicable encryption standards, server-side encryption, and encryption of any non-encrypted PII for the purposes of maintaining Health IT Module certification in the future. The permissible encryption algorithms for our proposed new server encryption requirement are listed in Annex A of The National Institute of Standards and Technology (NIST) Federal Information Processing Standards (FIPS) Publication 140-2, October 12, 2021, which specifies the security requirements for cryptographic modules.\69\ We believe Annex A of FIPS Publication 140-2 is appropriate for our proposed server-side encryption requirements for the same reasons it was considered appropriate for end-user device encryption requirements--it provides clear requirements and flexibility in demonstrating compliance (75 FR 44622). We note that the October 12, 2021, draft is the most recent version of Annex A: Approved Security Functions for FIPS Publication 140-2, and elsewhere in this Proposed Rule at III.B.4, we describe our proposal to revise the standard in Sec. 170.210(a) to include this updated version of Annex A (Draft, October 12, 2021). --------------------------------------------------------------------------- \69\ Annex A of FIPS PUB 140-2: https://csrc.nist.gov/files/pubs/fips/140-2/upd2/final/docs/fips1402annexa.pdf. --------------------------------------------------------------------------- Together, we believe that end-user device and server encryption requirements help better protect PII. We clarify that in the context of this certification criterion, a server is a system designed to store PII. We also clarify that in the context of our proposed new server encryption requirement in Sec. 170.315(d)(7)(iii), ``stops'' means that PII on a server is not actively in use and is not actively moving (i.e., PII that is not being processed, updated, or otherwise acted upon). We welcome comments on these proposed changes and additions to Sec. 170.315(d)(7). 12. Revised Criterion for Encrypt Authentication Credentials a. Background In the ONC Cures Act Final Rule, we finalized an authentication credential encryption requirement in Sec. 170.315(d)(12) (85 FR 25700). We established an approach that requires health IT developers with Health IT Modules certified to the criterion to be transparent about whether their certified Health IT Module encrypts stored authentication credentials according to industry standards by attesting ``yes'' or ``no.'' These ``yes'' or ``no'' attestations are made public on ONC's Certified Health IT Product List (CHPL), which is available at https://chpl.healthit.gov/. We established this approach in acknowledgement that some Health IT Modules certifying to the certification criterion in Sec. 170.315(d)(12) may not be designed to store authentication credentials. We included a provision in Sec. 170.315(d)(12)(ii) that permits health IT developers attesting ``no'' to explain why their Health IT Module does not support encrypting authentication credentials. We noted in the ONC Cures Act Final Rule that the information regarding the security capabilities of certified health IT provided by the attestation increased transparency and aided health IT users in making informed decisions on how best to protect health information and comply with applicable security regulations (e.g., the HIPAA Security Rule \70\) (85 FR 25701). --------------------------------------------------------------------------- \70\ The HIPAA Security Rule is located at 45 CFR part 160 and subparts A and C of part 164. --------------------------------------------------------------------------- b. Proposal We now propose to revise the requirements in the ``Encrypt authentication credentials'' certification criterion in Sec. 170.315(d)(12). We propose to expire our current ``yes'' or ``no'' attestation requirements by moving them to Sec. 170.315(d)(12)(i) and indicating they are applicable only for the time period up to and including December 31, 2025. We propose to replace the attestation requirements by revising Sec. 170.315(d)(12) to include new requirements in Sec. 170.315(d)(12)(ii) that become effective on and after January 1, 2026. Additionally, we propose that a health IT developer may meet the proposed revised certification criterion's requirements by satisfying the new conformance requirements proposed in Sec. 170.315(d)(12)(ii) in lieu of Sec. 170.315(d)(12)(i) prior to paragraph (i)'s December 31, 2025, expiration. With these new requirements, we propose that Health IT Modules designed to store authentication credentials must protect the confidentiality and integrity of their stored authentication credentials. These revisions include requirements in Sec. 170.315(d)(12)(ii)(A) and (B) for authentication credentials to be protected using either encryption and decryption according to the latest version of the Federal Information Processing Standards (FIPS) 140-2 (October 12, 2021) standard in Sec. 170.210(a) or by hashing in accordance with the FIPS 180-4 standard specified in Sec. 170.210(c)(2). As discussed more fully below, we believe that revising Sec. 170.315(d)(12) to require Health IT Modules protect stored authentication credentials according to updated industry standards in Sec. 170.210(a) is necessary and important to improve the security of certified health IT. We note in section III.B.4 in this preamble our proposal to adopt the latest available FIPS Publication 140-2 standard version in Sec. 170.210(a)(3) and expire the old FIPS Publication 140- 2 standard in Sec. 170.210(a)(2) as of January 1, 2026. Healthcare data breaches have trended significantly upward in recent years with around two breaches affecting 500 or more individuals reported per day in 2023, nearly double the frequency in 2018.\71\ During this same period, we also found that public CHPL attestation data for Health IT Modules certified to Sec. 170.315(d)(12) indicates that less than 73% of products meeting the Base EHR Definition in Sec. 170.102 included a ``yes'' attestation to encrypting authentication credentials.\72\ Given that protecting stored authentication credentials according to industry standards is a critical defensive step to help ensure that stolen or leaked authentication credentials are useless to an attacker, we believe it is important to require that a Health IT Module designed to store authentication credentials must protect the confidentiality and integrity of its stored authentication credentials according to Sec. 170.315(d)(12)(ii). --------------------------------------------------------------------------- \71\ https://ocrportal.hhs.gov/ocr/breach/breach_report.jsf. These numbers are based on breach reports made to OCR as of February 12, 2024. \72\ Percentages are based on data retrieved in February 2023 from https://chpl.healthit.gov/#/ search for ``Active,'' ``2015 CURES UPDATE'' listings certified to ``170.315 (D)(12): ENCRYPT AUTHENTICATION CREDENTIALS (CURES UPDATE) and ``170.315 (D)(13): MULTI-FACTOR AUTHENTICATION (CURES UPDATE)'' --------------------------------------------------------------------------- We have chosen to reference the FIPS 140-2 (Sec. 170.210(a)) and FIPS 180-2 (Sec. 170.210(c)(2)) standards in Sec. 170.315(d)(12)(ii) because they are the seminal, comprehensive, and most appropriate standards for protecting [[Page 63537]] sensitive information within computer systems. Referencing these standards also remains consistent with our references to these standards in other certification criteria in our Program. To reflect our proposed revisions to Sec. 170.315(d)(12), we propose to rename the certification criterion from ``Encrypt authentication credentials'' to ``Protect stored authentication credentials.'' We believe ``protect'' is a broader term that more clearly includes methods like hashing that can be used to safeguard stored authentication credentials. In the ONC Cures Act Final Rule we clarified that ``encrypting authentication credentials could include password encryption or cryptographic hashing'' (85 FR 25700). Despite this clarification, we have received inquiries asking if we consider hashing an acceptable form of ``encryption'' in the context of this certification criterion. We propose updating the certification criterion title and regulation text to address such concerns. We invite comments on our proposal to revise Sec. 170.315(d)(12) to require a Health IT Module designed to store authentication credentials to protect the confidentiality and integrity of its stored authentication credentials according to updated industry standards. 13. Health IT Modules Supporting Public Health Data Exchange a. Background Public health promotes and protects the health of all people and their communities. To accomplish this mission, public health authorities (PHAs) rely on public health data exchange to acquire the information they need to provide critical functions for society and to keep communities healthy.\73\ However, the nation's public health infrastructure, the technology in place within PHAs, and the methods of data exchange are often siloed, dated, and incapable of quickly providing timely, actionable data needed by PHAs and their partners, resulting in delays in detecting and responding to public health threats.\74\ As documented in numerous studies, and illustrated by the COVID-19 pandemic, there is an ongoing challenge for PHAs at all levels to obtain timely, accurate, representative, and actionable information from electronic health records and other related systems.\75\ However, as noted in a 2022 Government Accountability Office (GAO) report, PHAs do not always have access to--or, often, the ability to share--data needed to address public health needs (emergent or otherwise). This is due, in part, to the lack of common standards utilized in the reported data, variable reporting requirements, limited interoperability of systems, and an inadequate public health data infrastructure.\76\ Addressing these challenges can improve public health response readiness and the nation's healthcare system, enabling better-informed decision making, more comprehensive data analytics, and faster, more coordinated responses to public health threats and emergencies.77 78 --------------------------------------------------------------------------- \73\ https://www.healthit.gov/sites/default/files/page/2023-03/2023-02-08_HITAC_Annual_Report_for_FY22_supplemental_background_research_508_1.pdf. \74\ Data Modernization Initiative Strategic Implementation Plan. December 22, 2021. Available at https://www.cdc.gov/surveillance/pdfs/FINAL-DMI-Implementation-Strategic-Plan-12-22-21.pdf. \75\ See Public Health Data Modernization: Listening Session on Real-World Testing of 21st Century Cures Act Requirements. Available at https://www.cdc.gov/surveillance/pubs-resources/dmi-summary/index.html; Alonzo Plough, Gail C Christopher, Equity-Centered Public Health Data Demands New Voices at the Table, Health Affairs (April, 20222) available at https://www.healthaffairs.org/do/10.1377/forefront.20220427.865970/; Robert Wood Johnson Foundation, Transforming Public Health Data Systems, available at https://www.rwjf.org/en/insights/our-research/2021/09/transforming-public-health-data-systems.html, and Bipartisan Policy Center, Call to Action for State, Territorial, and Local Policymakers to Move Public Health Forward, December, 2021, available at https://bipartisanpolicy.org/download/?file=/wp-content/uploads/2021/12/PHF-Call-to-Action-Policymakers-1.pdf. \76\ https://www.gao.gov/products/gao-22-106175. \77\ https://cdn.ymaws.com/www.cste.org/resource/resmgr/pdfs/pdfs2/Driving_PH_Print.pdf. \78\ https://www.cdc.gov/surveillance/pdfs/20_319521-D_DataMod-Initiative_901420.pdf. --------------------------------------------------------------------------- Congress recognized the need to modernize our public health data infrastructure and in response to the COVID-19 pandemic passed legislation that included funding and directives related to such activities. Section 2301 of the American Rescue Plan of 2021 (ARP) (Pub. L. 117-2, enacted March 11, 2021) included funding for information technology, standards-based data, and public health reporting enhancements, including improvements to support standards- based exchange of data related to vaccine distribution and vaccinations.\79\ The Coronavirus Aid, Relief, and Economic Security Act (CARES Act) (Pub. L. 116-136, enacted March 27, 2020) provided funding to support enhancement of public health information system capabilities to address COVID-19 reporting needs.\80\ --------------------------------------------------------------------------- \79\ https://www.congress.gov/117/plaws/publ2/PLAW-117publ2.pdf. \80\ https://www.congress.gov/116/plaws/publ136/PLAW-116publ136.pdf. --------------------------------------------------------------------------- Several promising Federal efforts have been initiated to address the urgent need to improve public health infrastructure and health IT for public health to enable PHAs to get better and more timely access to the information they need to protect and improve the health of our nation. In this proposed rule, we use the phrase ``health IT for public health'' to mean hardware, software, integrated technologies or related licenses, IPs, upgrades, or packaged solutions sold as services that are designed to support public health use cases for the electronic creation, maintenance, access, or exchange of public health information, which is consistent with the ``health IT'' definition in section 13101(5) of the HITECH Act and 45 CFR 170.102. In 2020, CDC launched the Data Modernization Initiative (DMI) to modernize public health data and surveillance infrastructure.\81\ More recently, CDC has released its Public Health Data Strategy (Ph.D.S), which outlines the data, technology, policy, and administrative actions essential to exchange critical core data efficiently and securely across healthcare and public health.\82\ The strategy is designed to describe a path to address gaps in public health data and help the nation become response- ready, promote health equity, and improve health outcomes for all. --------------------------------------------------------------------------- \81\ https://www.cdc.gov/surveillance/data-modernization/basics/index.html. \82\ https://www.cdc.gov/ophdst/public-health-data-strategy/index.html. --------------------------------------------------------------------------- ONC actively works with CDC and other Federal partners on initiatives that complement, support, and extend CDC's efforts under the Ph.D.S, including USCDI+ Public Health and Helios, a Fast Healthcare Interoperability Resources[supreg] (FHIR[supreg]) accelerator through HL7[supreg], to help address DMI priorities around data interoperability.\83\ USCDI+ is intended to build upon the core dataset established in the United States Core Data for Interoperability (USCDI), a standardized set of health data classes and data elements for nationwide, interoperable health information exchange, discussed in more detail in section III.B.1 of this proposed rule. We launched USCDI+ Public Health in October 2021 to capture the data needs of public health that extend beyond USCDI to ultimately improve the availability and consistency of data necessary to support various aspects of public health.\84\ In November 2021, HL7 [[Page 63538]] launched Helios in collaboration with CDC and ONC.\85\ --------------------------------------------------------------------------- \83\ https://www.cdc.gov/surveillance/policy-standards/interoperability.html. \84\ https://www.healthit.gov/buzz-blog/health-it/thinking-outside-the-box-the-uscdi-initiative; see also https://www.healthit.gov/topic/interoperability/uscdi-plus. \85\ https://confluence.hl7.org/display/PH/Helios+FHIR+Accelerator+for+Public+Health+Home. --------------------------------------------------------------------------- The Health Information Technology Advisory Committee (HITAC) was established by the Cures Act and is governed by the provisions of the Federal Advisory Committee Act (FACA) \86\ which sets forth standards for the formation and use of Federal advisory committees. Section 3002 of the PHSA, as amended by section 4003(e) of the Cures Act, established that the FACA applies to the HITAC and that the HITAC would advise and make recommendations to the National Coordinator on different aspects of standards, implementation specifications, and certification criteria relating to the implementation of a health IT infrastructure, nationally and locally, that advances the electronic access, exchange, and use of health information. The HITAC created a Public Health Data Systems Task Force in 2021 (2021 Task Force) to develop recommendations in response to President Biden's Executive Order on Ensuring a Data-Driven Response to COVID-19 and Future High Consequence Public Health Threats,\87\ which tasked HHS with reviewing the ability of the public health infrastructure to address such threats.\88\ The 2021 Task Force recommended the inclusion of ``certification of information systems for both senders and receivers'' for public health data.\89\ In 2022, the HITAC convened a second Public Health Data Systems Task Force (2022 Task Force) and directed it to build on the recommendations from the 2021 Task Force to more specifically examine the existing ``(f) criteria'' within our Program, which certifies health IT for its ability to support various transmissions to PHAs.\90\ The 2022 Task Force found that improvements were needed with respect to the flow of data for public health across the healthcare ecosystem and for robust support of public health in the Program. In particular, the 2022 Task Force highlighted that while the Program has certification criteria related to transmitting data to PHAs, it has not included sufficient real-world testing requirements or the ability of technology used by PHAs to receive and utilize data transmitted according to standards required for certified health IT.\91\ The 2022 Task Force had several recommendations approved by HITAC, including that we establish certification criteria for Health IT Modules supporting public health use cases focused on interoperability functions such as access, exchange, and use of data, and to provide a common floor for addressing public health interoperability needs.\92\ The 2022 Task Force emphasized that the intent of certification criteria related to health IT for public health would be to create a base level of interoperability inclusive of all providers and PHAs and the methods by which data is primarily electronically exchanged--not to restrict public authorities from requesting and receiving data in the manner needed to fulfill their mission. --------------------------------------------------------------------------- \86\ Federal Advisory Committee Act (FACA), Pub. L. 92-463 (1972), codified as amended at, 5 U.S.C. Chapter 10 (formerly 5 U.S.C. App. 2). \87\ https://www.whitehouse.gov/briefing-room/presidential- actions/2021/01/21/executive-order-ensuring-a-data-driven-response- to-covid-19-and-future-high-consequence-public-health-threats/ #:~:text=It%20is%20the%20policy%20of,a%20better%20public%20health%20i nfrastructure. \88\ https://www.healthit.gov/sites/default/files/page/2021-08/2021-07-14_PHDS_TF_2021_HITAC%20Recommendations%20Report_Signed_508_0.pdf. \89\ https://www.healthit.gov/sites/default/files/page/2022-11/2022-11-10_PHDS_TF_Recommendations_Report_Transmittal_Letter_508.pdf. \90\ Id. \91\ https://www.healthit.gov/sites/default/files/facas/2022-11-10_HITAC_Meeting_Notes_508_1.pdf. \92\ Id. --------------------------------------------------------------------------- In response to these HITAC recommendations in 2021 and 2022 and consistent with the PHSA sections 3001 and 3004 previously described (see section II.A), we are proposing several changes to existing certification criteria as well as the creation of new certification criteria related to health IT for public health. These proposals are responsive to the HITAC recommendations to ONC of increasing the adoption and use of health IT standards for electronic lab reporting, electronic case reporting, and syndromic surveillance, among others. These updates and additions to the certification criteria related to health IT for public health additionally address the HITAC's recommendations to ONC to position CDC, and other Federal partners, to be nimble, responsive, and resilient during the next public health emergency. Additionally, CDC's Advisory Committee to the Director (ACD) recommended that a certification program for health IT for public health would help address core problems with data infrastructure and exchange.\93\ The ACD recommendations include that CDC and ONC should work together to develop and implement a coordinated and phased approach for certifying health IT for public health, grounded in the use of shared data standards. Both the ACD and the HITAC recommendations highlight the shared consensus regarding the need to develop a standards-based certification program to improve the availability and interoperability of important health information between healthcare providers and PHAs. --------------------------------------------------------------------------- \93\ https://www.cdc.gov/about/pdf/advisory/dsw-recommendations-report.pdf. --------------------------------------------------------------------------- We have also addressed public health data exchange as part of efforts related to the Trusted Exchange Framework and Common Agreement\TM\ (TEFCA\TM\),\94\ which includes public health as a specific ``exchange purpose,'' and work is underway with the Recognized Coordinating Entity[supreg] (RCE\TM\) to develop a Standard Operating Procedure (SOP) for the public health exchange purpose under TEFCA to support the ability of providers and PHAs to exchange information, as well as standardized, secure interoperability for PHAs to exchange information with each other.\95\ Additionally, we funded the Association of State and Territorial Health Officials (ASTHO) to launch a Health Information Exchange (HIE) and Immunization Information System (IIS) COVID-19 Data Management: Immunization Data Exchange, Advancement and Sharing (IDEAS) program focused on expanding partnerships between state, regional, and local HIEs and IISs.\96\ As a program deliverable, ASTHO conducted an environmental scan focusing on data sharing between HIEs and IISs.\97\ Findings included the need for data exchange partners to use the same vocabularies and coding systems and for the use of a standard messaging format and transmission method for data exchange.\98\ --------------------------------------------------------------------------- \94\ https://www.healthit.gov/topic/interoperability/policy/ trusted-exchange-framework-and-common-agreement- tefca#:~:text=The%20overall%20goal%20of%20the,for%20interoperability% 20across%20the%20country. \95\ https://rce.sequoiaproject.org/tefca-and-rce-resources/. \96\ https://www.healthit.gov/topic/onc-funding-opportunities/funding-announcements. \97\ https://www.astho.org/globalassets/report/immunization-information-systems-and-health-information-exchanges.pdf. \98\ https://www.astho.org/globalassets/report/immunization-information-systems-and-health-information-exchanges.pdf. --------------------------------------------------------------------------- b. Regulatory History In addition to the efforts described above, we have adopted several standards, implementation specifications, and certification criteria related to public health as part of the Program. While the Program itself is voluntary for health IT developers, compliance with Program standards, implementation specifications, and [[Page 63539]] certification criteria is encouraged through CMS incentive programs. The American Recovery and Reinvestment Act of 2009 (ARRA) (Pub. L. 111- 5, enacted February 17, 2009) authorized incentive payments to eligible professionals, eligible hospitals, and critical access hospitals (CAHs) to promote the adoption and meaningful use of CEHRT. In 2011, CMS established the Medicare and Medicaid Electronic Health Record (EHR) Incentive Programs to encourage eligible professionals, eligible hospitals, and CAHs to adopt and make meaningful use of CEHRT. CMS changed the name of the EHR Incentive Programs to the Medicare and Medicaid Promoting Interoperability Programs in April 2018.\99\ The Medicaid Promoting Interoperability Program ended in 2022, and the program is currently known as the Medicare Promoting Interoperability Program for eligible hospitals and CAHs.\100\ The Medicare Promoting Interoperability Program is also a performance category component of CMS' Merit-Based Incentive Payment System (MIPS), a program that determines Medicare payment adjustments. --------------------------------------------------------------------------- \99\ https://www.cms.gov/medicare/regulations-guidance/promoting-interoperability-programs. \100\ https://www.cms.gov/regulations-and-guidance/legislation/ ehrincentiveprograms#:~:text=About%20the%20Promoting%20Interoperabili ty%20Program&text=Beginning%20in%20calendar%20year%20(CY,for%20eligib le%20hospitals%20and%20CAHs. --------------------------------------------------------------------------- As we have described in prior rulemakings, Congress tied the standards, implementation specifications, and certification criteria adopted as part of the Program to the incentives available under CMS Programs by requiring the meaningful use of CEHRT (75 FR 44591). Generally, we support the use of certified health IT under CMS incentive programs by establishing standards, implementation specifications, and certification criteria for health IT as part of the Program that are then incorporated into the CMS definition of CEHRT relied upon by health care providers and other users of health IT to receive incentives from CMS programs. For example, for calendar year 2023, to be considered a meaningful user and avoid a downward payment adjustment, eligible hospitals and CAHs attesting to the Medicare Promoting Interoperability Program are required to use CEHRT that has been updated to meet the 2015 Edition Cures Update certification criteria.\101\ --------------------------------------------------------------------------- \101\ https://www.cms.gov/Regulations-and-Guidance/Legislation/ EHRIncentivePrograms/ Certification#:~:text=In%20order%20to%20efficiently%20capture,data%20 in%20a%20structured%20format. --------------------------------------------------------------------------- In the 2010 interim final rule with comment period entitled ``Health Information Technology: Initial Set of Standards, Implementation Specifications, and Certification Criteria for Electronic Health Record Technology'' (75 FR 2014), we first established standards and certification criteria related to public health. These included standards and certification criteria for the electronic submission of laboratory results to PHAs, electronic submission to PHAs for surveillance or reporting, and electronic submission to immunization registries. These standards and certification criteria were updated in the 2010 final rule entitled ``Health Information Technology: Initial Set of Standards, Implementation Specifications, and Certification Criteria for Electronic Health Record Technology'' (75 FR 44590). In the 2012 final rule entitled ``Health Information Technology: Standards, Implementation Specifications, and Certification Criteria for Electronic Health Record Technology, 2014 Edition; Revisions to the Permanent Certification Program for Health Information Technology'' (77 FR 54163), we expanded the public health related standards and certification criteria and codified the 2014 Edition EHR certification criteria in Sec. 170.314, with the public health certification criteria organized in Sec. 170.314(f). The public health certification criteria in the 2012 final rule included: Sec. 170.314(f)(1) ``Immunization information''; Sec. 170.314(f)(2) ``Transmission to immunization registries''; Sec. 170.314(f)(3) ``Transmission to public health agencies--syndromic surveillance''; Sec. 170.314(f)(4) ``Inpatient setting only--transmission of reportable laboratory tests and values/results''; and, two ``optional'' certification criteria: [cir] Sec. 170.314(f)(5) ``Optional--ambulatory setting only-- cancer case information''; and, [cir] Sec. 170.314(f)(6) ``Optional--ambulatory setting only-- transmission to cancer registries.'' Then, in the 2014 final rule entitled ``2014 Edition Release 2 Electronic Health Record (EHR) Certification Criteria and the ONC HIT Certification Program; Regulatory Flexibilities, Improvements, and Enhanced Health Information Exchange'' (79 FR 54430), we added an optional, ambulatory-setting only certification criterion for syndromic surveillance in Sec. 170.314(f)(7). In the 2015 final rule entitled ``2015 Edition Health Information Technology (Health IT) Certification Criteria, 2015 Edition Base Electronic Health Record (EHR) Definition, and ONC Health IT Certification Program Modifications'' (2015 Edition Final Rule) (80 FR 62601), we revised the public health certification criteria to include the following: Sec. 170.315(f)(1) ``Transmission to immunization registries,'' revised as compared to the 2014 Edition; Sec. 170.315(f)(2) ``Transmission to public health agencies--syndromic surveillance,'' revised as compared to the 2014 Edition; Sec. 170.315(f)(3) ``Transmission to public health agencies--reportable laboratory tests and values/results,'' revised as compared to the 2014 Edition; Sec. 170.315(f)(4) ``Transmission to cancer registries,'' revised as compared to the 2014 Edition; a new certification criterion Sec. 170.315(f)(5) ``Transmission to public health agencies--electronic case reporting;'' a new certification criterion Sec. 170.315(f)(6) ``Transmission to public health agencies--antimicrobial use and resistance reporting,'' and, a new certification criterion Sec. 170.315(f)(7) ``Transmission to public health agencies--health care surveys.'' In the in the 2020 final rule entitled ``21st Century Cures Act: Interoperability, Information Blocking, and the ONC Health IT Certification Program'' (85 FR 25642), we revised the public health certification criterion Sec. 170.315(f)(5) ``Transmission to public health agencies--electronic case reporting'' to incorporate the USCDI v1 standard and C-CDA companion guide (85 FR 25671). However, in the subsequent Interim Final Rule with comment period entitled ``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), we further revised that requirement so that health IT developers certifying to Sec. 170.315(f)(5) were required to conform to data classes expressed in the USCDI standard in Sec. 170.213 or the Common Clinical Data Set for the period before December 31, 2022 (85 FR 70076). Additionally, in a final rule titled, ``Health Data, Technology, and Interoperability: Certification Program Updates, Algorithm Transparency, and Information Sharing'' (HTI-1 Final Rule) (89 FR 1192), we revised the ``Transmission to public health agencies--electronic case reporting'' certification criterion in Sec. 170.315(f)(5) to replace the functional requirements [[Page 63540]] with standards and implementation guides (IGs) and updated vocabulary standards in Sec. 170.207(a), (c), and (e) that are referenced in several public health certification criteria. Currently, the Program includes seven certification criteria related to public health (see Sec. 170.315(f)). We are referring to these seven certification criteria as the ``(f) criteria'' in this proposed rule and may refer to them in that way in future rulemaking. These (f) criteria are: Sec. 170.315(f)(1) Transmission to immunization registries Sec. 170.315(f)(2) Transmission to public health agencies--syndromic surveillance Sec. 170.315(f)(3) Transmission to public health agencies--reportable laboratory tests and values/results Sec. 170.315(f)(4) Transmission to cancer registries Sec. 170.315(f)(5) Transmission to public health agencies--electronic case reporting Sec. 170.315(f)(6) Transmission to public health agencies--antimicrobial use and resistance reporting Sec. 170.315(f)(7) Transmission to public health agencies--healthcare surveys Generally, the certification criteria listed above include report generation and transmission functionalities, require Health IT Modules to adhere to specific standards and implementation guides, and provide assurances that the certified Health IT Module performs as intended. However, we note that the certification criteria do not include all functionalities that may be of interest to public health, nor does the Program certify data quality or the technology that receives incoming submissions. Additionally, most of these certification criteria have not been substantially updated since 2015, as described above. c. Proposal Overview As indicated in the regulatory history, we have not updated the Program's certification criteria related to public health since 2015, with the exception of standards and IGs being added to the requirements for the ``Transmission to public health agencies--electronic case reporting'' certification criterion in Sec. 170.315(f)(5) and updates to several vocabulary standards in the HTI-1 Final Rule. Standards referenced in Sec. 170.315(f)(5), Sec. 170.315(f)(6), and Sec. 170.315(f)(7) have advanced through the Standards Version Advancement Process (SVAP), which allows health IT developers to voluntarily use more recent versions than those adopted in regulation as part of certification under the Program.\102\ --------------------------------------------------------------------------- \102\ https://www.healthit.gov/topic/standards-version-advancement-process-svap. --------------------------------------------------------------------------- Considering the urgent need for greater public health data exchange and access to more actionable data by PHAs, we propose a multi-pronged approach that takes advantage of and builds upon the various efforts described above, including advancements in FHIR-based solutions and evolving standards related to public health interoperability. For example, a CDC report on public health data modernization found that enabling greater flow of health information from electronic health records to PHAs using HL7 FHIR-based standards could allow public health to take advantage of advanced data science capabilities such as predictive analysis, enhanced surveillance, personalized communications, and streamlining of data sharing while protecting patient privacy.\103\ --------------------------------------------------------------------------- \103\ https://www.cdc.gov/surveillance/data-modernization/index.html. --------------------------------------------------------------------------- We propose to revise the Program's current certification criteria related to public health in Sec. 170.315(f); add several new functional requirements and adopt newer versions of standards within the current (f) criteria; add two additional certification criteria in the current (f) criteria for birth reporting and bi-directional exchange with a prescription drug monitoring program (PDMP); adopt new certification criteria for health IT for public health in Sec. 170.315(f)(21) through (29); adopt enhancements to the standardized API for patient and population services in Sec. 170.315(g)(10) (see section III.B.19); and adopt a new certification criterion for a standardized FHIR-based API for public health data exchange in Sec. 170.315(g)(20), which we also propose to adopt as part of the Base EHR definition. Additionally, we propose to revise the naming of the (f) criteria to reflect first the public health use case, followed by the functionality the certification criterion supports. We believe this will help support clarity for both the use case and the specific capabilities as we continue to expand health IT supports for public health data exchange. While the proposed (f) criteria updates and additions focus primarily on health IT for public health, we believe it is likely that these certification criteria may be used in other use cases and settings. In general, we seek to frame health IT certification criteria so that the certified health IT can be used by a wide range of entities in a different setting--including by health care providers, researchers, PHAs, or third-party entities supporting public health use cases defined in Sec. 170.315(f), such as health information networks or other types of registries. For these public health use cases, we propose to group functions within use cases based on the implementation guides and the transactions within a bi- or multi-directional information exchange workflow. These functions may be part of a wide range of technologies, employed by a wide range of users, and we remain agnostic to the specific entity that may purchase any health IT product certified to the functionality. As such, we use the term ``health IT for public health'' to support the functions and transactions in the public health use cases in Sec. 170.315(f)(21) through (29). Accordingly, we propose to revise the naming of the current (f) criteria as follows: Sec. 170.315(f)(1) Immunization registries--Bi- directional exchange Sec. 170.315(f)(2) Syndromic surveillance--Transmission to public health agencies Sec. 170.315(f)(3) Reportable laboratory results-- Transmission to public health agencies--and Laboratory Orders--Receive and validate Sec. 170.315(f)(4) Cancer registry reporting-- Transmission to public health agencies Sec. 170.315(f)(5) Electronic case reporting-- Transmission to public health agencies Sec. 170.315(f)(6) Antimicrobial use and resistance reporting--Transmission to public health agencies Sec. 170.315(f)(7) Health care surveys--Transmission to public health agencies The new (f) criteria for public health data exchange and for health IT for public health that we propose to adopt are: Sec. 170.315(f)(8) Birth reporting--Transmission to public health agencies Sec. 170.315(f)(9) Prescription Drug Monitoring Program (PDMP) Databases--Query, receive, validate, parse, and filter Sec. 170.315(f)(21) Immunization information--Receive, validate, parse, filter, and exchange--response. Sec. 170.315(f)(22) Syndromic surveillance--Receive, validate, parse, and filter Sec. 170.315(f)(23) Reportable laboratory test values/ results--Receive, validate, parse, and filter Sec. 170.315(f)(24) Cancer pathology reporting--Receive, validate, parse, and filter Sec. 170.315(f)(25) Electronic case reporting--Receive, validate, parse, filter, electronic initial case reports and [[Page 63541]] reportability response; and create and transmit reportability response Sec. 170.315(f)(28) Birth reporting--Receive, validate, parse, and filter Sec. 170.315(f)(29) Prescription Drug Monitoring Program (PDMP) Data--Receive, validate, parse, filter prescription data, support query and exchange We also propose revisions to the ``Computerized provider order entry--laboratory'' certification criterion in Sec. 170.315(a)(2) that relate to the proposed updates to the public health certification criteria listed above. Please see section III.B.18 for detail on those proposed updates to Sec. 170.315(a)(2). We propose this multi-pronged approach--updating existing requirements, adding new requirements for receipt, updating standards, and including a glidepath for transitioning to FHIR-based exchange in the future--to harmonize data exchange across the industry and further advance public health infrastructure to be response-ready, scalable, and flexible. We intend for this approach to allow for systems to mature and advance in an aligned fashion, reduce the need for manual workarounds and intervention, and lead to wider adoption of modern standards-based capabilities. We understand that some health IT certification terms used in ONC's regulations for specific technical actions or capabilities may not be the same uses of the terms by the public health or healthcare sector when discussing programmatic activities. For example, in the Program we use the term ``validate'' in reference to the technical capability to correctly identify if a structured document or message received is conformant to a standard and if formats or vocabulary standards are valid or invalid. This is a necessary technical step to map data received in an interoperable manner. Public health or quality reporting related organizations may use the term ``validate'' to refer to an organizational or programmatic process to support program integrity, data accuracy, and data quality. In order to maintain consistency within the Program and to provide clarity for health IT developers, we use terms that describe health IT software functions that--while they may enable such activities by users--are specific to technical requirements. In addition, we use terms that are consistent across certification criteria--such as receive, validate, parse, and filter-- to clearly and consistently define health IT functions in a manner that supports health IT developers participating in the Program. The capabilities we propose in this manner are intended to advance tools which can be used in a variety of ways to support greater efficacy across multiple programmatic and organizational use cases and processes for the public health and healthcare community. Prior experiences with the Program demonstrated an imperative to test both the sending and receiving of information, particularly in HL7 messages and documents. The initial requirement of Continuity of Care Documents (CCDs) in early iterations of the Program only included the functionality to create and send, resulting in multiple deviations and variations of the same document type and creating challenges with receiving the same standard from different vendors. Such variability included different formatting, such as line and page breaks or representation of date, as well as including or excluding specific data elements, such as onset time of problem.\104\ These variations, while allowed under the Program at the time, made receiving, integrating, and interpreting CCDs challenging. However, when certification requirements and associated testing expectations were updated to include the receipt of CCDs as well, there was a noticeable improvement in consistency. Over time, implementation guides developed through standards development organizations became more constrained, with fewer areas of optionality, and companion guides supplemented these IGs, reducing the variations discussed above, and improving interoperability. --------------------------------------------------------------------------- \104\ D'Amore JD, Sittig DF, Wright A, Iyengar MS, Ness RB. The promise of the CCD: challenges and opportunity for quality improvement and population health. AMIA Annu Symp Proc. 2011; 2011:285-94. Epub 2011 Oct 22. PMID: 22195080; PMCID: PMC3243208. --------------------------------------------------------------------------- These lessons in the early implementation of the Program were considered when developing the current proposals. For public health reporting, only sending systems--namely health IT used by health care providers--have been held to requirements for transmission. Similar divergence in minimum system capabilities and variable adoption and use of established national standards between certified health IT developers and health IT for public health have created challenges for PHAs, which have struggled to make use of data that is not consistent, even when it conforms to a healthcare standard. At best, these differences result in significant inefficiencies, as PHAs must develop manual workarounds and custom tools that standardize and format incoming data to reduce processing time and improve receipt, data mapping, and parsing processes. At worst, these differences impede public health's ability to quickly translate data it receives from healthcare into actions that protect and support the health of all people and their communities. By establishing minimum functional capabilities and exchange standards for health IT and health IT for public health to send and receive public health data, we expect to enhance interoperability across healthcare and public health and provide a long-term mechanism for alignment as data exchange matures over time. Modernization efforts across health IT and health IT for public health will progress and upgrade on the same timeline, using the same standards in their entirety. d. Revised Certification Criteria for Health IT Modules Supporting Public Health Data Exchange We propose to revise the current certification criteria located in Sec. 170.315(f) as described below. i. Sec. 170.315(f)(1)--Immunization Registries--Bi-directional Exchange While immunization reporting is one of the most advanced components of the public health data exchange ecosystem, challenges remain. Throughout the COVID-19 pandemic, certain issues rose in prominence, such as individuals needing access to their personal immunization histories from health IT systems and providers being unable to consistently query or view vaccines given at different places of care. Further, there were challenges with Health IT Modules being unable to consistently provide bulk access on vaccinated populations to immunization systems (e.g., to understand if students were up to date on vaccines for vaccine-preventable diseases). The current certification criterion in Sec. 170.315(f)(1) has been widely implemented in Health IT Modules but has not been updated since 2015, with the exception of the vocabulary standards in Sec. 170.207(e) that are referenced in the certification criterion and updated in the HTI-1 Final Rule (89 FR 1226). We propose to update the Immunization Messaging Implementation Guide (IG) standard in Sec. 170.205(e) to the HL7 v2.5.1 IG for Immunization Messaging, Release 1.5, Published October 2018, which is a compilation of the Release 1.5 version and the Addendum from 2015 referenced in the current Program, and incorporate it by reference in Sec. 170.299. We are aware that the HL7 Public Health Workgroup will work on further updates to the IG, based in part on [[Page 63542]] lessons learned from the pandemic, but that this new version will likely not be published until mid-to-late 2024. We welcome comments on advances beyond the current 1.5 version of the IG and encourage participation in the HL7 Public Health Workgroup. We also propose that adoption of the standard in Sec. 170.205(e)(4) expires on January 1, 2028. Additionally, as described in the ``Minimum Standards Code Sets Updates'' section (III.B.5), we propose to update the vocabulary standards in Sec. 170.207(e) that are referenced in Sec. 170.315(f)(1) and thus are proposing to update Sec. 170.315(f)(1)(i)(B) to reference the new proposed Sec. 170.207(e)(5) and to update Sec. 170.315(f)(1)(i)(C) to reference the new proposed Sec. 170.207(e)(6). We propose to add a functional requirement in Sec. 170.315(f)(1)(iii) to receive incoming patient-level immunization- specific query or request from external systems and respond. We propose to revise the name of the certification criterion in Sec. 170.315(f)(1) to ``Immunization registries--Bi-directional exchange'' to more accurately represent the capabilities included in the certification criterion. We note that we additionally propose a requirement in support of requests for multiple patients' data as a group using an application programming interface in Sec. 170.315(g)(20)(ii) and direct readers to section III.B.13.f for further information on that related proposal, in addition to our proposed revisions to Sec. 170.315(g)(10) which includes capabilities to support multiple patients' data as a group using an application programming interface (section III.B.19). We expect these changes to enable more approaches for bi-directional exchange of immunization information. Further, we propose patient access to their immunization information stored in Health IT Modules using SMART Health Cards ``verifiable health records'' in proposed Sec. 170.315(g)(10) and direct readers to section III.B.19 for further information on that proposal. We expect these proposed changes would improve patient access to more complete and standardized immunization information stored in Health IT Modules, and request feedback on this approach. Specifically, we request feedback on the standard referenced in Sec. 170.205(e) and whether we should consider adopting that soon-to-be most current version in a final rule, as we are aware that an updated version of the standard is due to be published in mid-2024. We request feedback on the functional requirement to respond to patient-level, immunization- specific queries from external systems and request comment on if the standard referenced in Sec. 170.205(e) is sufficient for the proposed functional requirement to respond to incoming patient-level and immunization-specific queries, or if that is better handled through the IG currently going through HL7 processes for updates. We propose to revise the certification criterion in Sec. 170.315(f)(1) to include revised minimum standard code set requirements, updated implementation specifications, and new functionality. We propose that, for the time period up to and including December 31, 2026, a Health IT Module may continue to be certified to the existing version of the certification criterion as described in Sec. 170.315(f)(1)(i), with proposed modifications for clarity and with a proposed revision to include the minimum standard code set updates for representation of historic and administered vaccines proposed for adoption in Sec. 170.207(e), or it may be certified to the newly proposed certification criteria in Sec. 170.315(f)(1)(ii) and (iii). We propose the new and revised certification criteria in Sec. 170.315(f)(1)(ii) and (iii) to replace the existing certification criterion in Sec. 170.315(f)(1)(i) beginning on January 1, 2027. Specifically, the proposed revisions to the certification criterion in Sec. 170.315(f)(1)(ii) include updates to the minimum standards specified in Sec. 170.207(e), use of newer versions of implementation specifications proposed for adoption in Sec. 170.205(e), and new functionality to enable a user to receive and respond to incoming patient-level immunization-specific query or request from external systems. We propose that a Health IT Module certified to Sec. 170.315(f)(1) must be updated to meet the requirements of the revised certification criterion in Sec. 170.315(f)(1)(ii) and the requirements in Sec. 170.315(f)(1)(iii), and that a health IT developer must provide such updated technology to their customers by no later than December 31, 2026. We propose that any Health IT Module seeking certification to the certification criterion in Sec. 170.315(f)(1) on and after January 1, 2027, must meet the revised requirements in Sec. 170.315(f)(1)(ii) and the requirements in Sec. 170.315(f)(1)(iii). ii. Sec. 170.315(f)(2)--Syndromic Surveillance--Transmission to Public Health Agencies Syndromic surveillance has proven to be a vital component of public health data exchange and surveillance. Such data provide early indicators of public health threats, identify changes in occurrence of disease, illness, or injury patterns, and detect population-wide hazards. Today, the Program references an implementation guide last updated in 2015. Due to outdated cardinality within the standard and customization in the implementation of the standard, there are often missing or incomplete data elements. The current certification criterion in Sec. 170.315(f)(2) has not been updated since 2015 and references a 2015 ADT-based IG published through CDC's Public Health Information Network (PHIN). The current version of the IG, Version 2.5.1 Implementation Guide: Syndromic Surveillance, Release 1--US Realm Standard for Trial Use, July 2019 published by HL7, more specifically defines the required data elements and message specifications for an ADT-based interface implemented specifically for syndromic surveillance. This standard includes new and updated data elements to aid in public health surveillance, including, but not limited to, patient discharge disposition, patient class, diagnosis code, reason for admission, and service location. Additionally, the observation component within the implementation guide now contains additional required elements relevant to public health, including, but not limited to, pregnancy status, travel history, and acuity. These new and updated data elements provide additional information for PHAs to inform assessment of emerging threats and the proceeding action. We propose to revise the standard in Sec. 170.205(d), which is referenced in Sec. 170.315(f)(2), to reference the most recent IG, HL7 Version 2.5.1 Implementation Guide: Syndromic Surveillance, Release 1-- US Realm Standard for Trial Use, July 2019 in Sec. 170.205(d)(1) and incorporate it by reference in Sec. 170.299. We also propose to add an expiration date of January 1, 2027 for the standards previously adopted in Sec. 170.205(d)(2) and (d)(4). However, we propose that the standard adopted in Sec. 170.205(d)(2) shall include an indication that the expiration is for the purposes of the certification criteria in Sec. 170.315(f). We propose that the adoption of the standard in Sec. 170.205(d)(2) on behalf of HHS shall be otherwise maintained as it is currently referenced by HHS programs for other use cases. We propose that any health IT module certified to Sec. 170.315(f)(2) would be required to meet at least one implementation specification that is (1) adopted in Sec. 170.205(d) or approved for SVAP and (2) not expired at the time of use. We propose that a health IT developer must update any health IT module certified to Sec. 170.315(f)(2) and provide such [[Page 63543]] updated module to its customers by the expiration date of the applicable standard in order to maintain certification of the health IT module. These revisions to the certification criterion in Sec. 170.315(f)(2) would support additional data elements being shared with syndromic surveillance programs. We further propose to change the name of the criterion in Sec. 170.315(f)(2) to Syndromic surveillance-- Transmission to public health agencies. iii. Sec. 170.315(f)(3)--Reportable Laboratory Results--Transmission to Public Health Agencies--and Laboratory Orders--Receive and Validate The COVID-19 pandemic brought issues with laboratory data interoperability and associated reporting challenges to light. However, many of these issues are not specific to the pandemic and are instead due to the existing infrastructure and low adoption of current standards. Health IT Modules currently exchange older versions of the electronic laboratory reporting standard that no longer fully meet the needs of public health. We recognize there are also issues facing laboratory reporting and interoperability related to local codes and the manual effort involved with mapping local codes to standard codes. We received feedback about the challenges and time it takes for the mapping needed for exchange, and the downstream issues that occur if the mapping is not completed. However, we do not believe this can be solved solely through updates to the Program, which can require that technology support standard codes but cannot mandate that users record data using such standard codes. We will continue to partner with industry and others on addressing these broader challenges. We propose that health IT presented for certification support use of at least one of the versions of Systemized Nomenclature of Medicine--Clinical Terms (SNOMED CT[supreg]),\105\ Logical Observation Identifiers Names and Codes (LOINC[supreg]),\106\ and the Unified Code for Units of Measure (UCUM) \107\ code sets specified in Sec. 170.207(a), (c), and (m) respectively to include updated code sets. --------------------------------------------------------------------------- \105\ https://www.snomed.org/. \106\ https://loinc.org/. \107\ https://ucum.org/. --------------------------------------------------------------------------- We propose to revise the certification criterion in Sec. 170.315(f)(3) to include these revised minimum standard code set requirements, as well as updated implementation specifications, and new functionality. The proposed revisions to the certification criterion include the same minimum standards updates in Sec. 170.207(a), (c), and (m), use of newer versions of implementation specifications proposed for adoption in Sec. 170.205(g), and new functionality to enable a user to receive and validate reportable laboratory order consistent with the new standards proposed for adoption in Sec. 170.205(g). The certification criterion in Sec. 170.315(f)(3) is specific to lab results being transmitted to PHAs and has been applied primarily to Health IT Modules reporting laboratory values/results to jurisdictional PHAs. The certification criterion currently only includes transmission of laboratory results and does not cover functions related to the laboratory order. We propose to update the certification criterion to also include functionality for Health IT Modules to receive, validate, parse, and filter laboratory orders, according to the standard proposed in Sec. 170.205(g)(2). We also propose to update the certification criterion to reference the standard proposed in Sec. 170.205(g)(3) for the transmission of laboratory results. We propose to revise the content and exchange standards for electronic transmission of lab results to PHAs in Sec. 170.205(g). In Sec. 170.205(g) we propose to reorganize the paragraph to include the current standard HL7 2.5.1, HL7 Version 2.5.1 Implementation Guide: Electronic Laboratory Reporting to Public Health, Release 1 (US Realm) (ELR) with Errata and Clarifications, and ELR 2.5.1 Clarification Document for EHR Technology Certification adopted in Sec. 170.205(g) and incorporated by reference in Sec. 170.299 into a new paragraph (1). We propose an expiration date of January 1, 2028 for the standard in Sec. 170.205(g)(1). We propose to adopt the standard for HL7 Version 2.5.1 Implementation Guide: Laboratory Orders (LOI) from EHR, Release 1, STU Release 4--US Realm in Sec. 170.205(g)(2) and incorporate it by reference in Sec. 170.299. We propose to adopt in Sec. 170.205(g)(3), and incorporate by reference in Sec. 170.299, the standard for HL7 Version 2.5.1 Implementation Guide: Laboratory Results Interface, Release 1 STU Release 4--US Realm (LRI), and to specify the use of the Public Health Profile, in addition to the ELR IG. We propose to revise Sec. 170.315(f)(3)(ii) to reference LRI in addition to the HL7 Version 2.5.1 Implementation Guide: Electronic Laboratory Reporting to Public Health, Release 1 (US Realm) (ELR). We propose to revise the standards in Sec. 170.207(a), (c), and (m), which are referenced in Sec. 170.315(f)(3)(i) and (ii), to reference the latest versions of SNOMED CT, LOINC, and UCUM respectively. We further propose to add a functional requirement in Sec. 170.315(f)(3)(ii) requiring the ability to receive, validate, parse, and filter reportable laboratory orders according to the standards proposed in Sec. 170.205(g)(2) and (g)(3). Additionally, we propose to rename the certification criterion in Sec. 170.315(f)(3) to ``Reportable laboratory results--Transmission to public health agencies--and Laboratory Orders--Receive and validate.'' The proposed changes to the certification criterion in Sec. 170.315(f)(3) would help increase the data shared between healthcare providers, laboratories, and PHAs and would increase interoperability among the different systems in place at each entity. Our proposed changes would also provide more complete patient-level information for contact tracing, patient outreach, direct care, and other clinical and public health activities. The use of the LRI IG would provide more specificity than ELR, which can decrease the need for one-off mapping. Given the benefit of the LRI IG, we propose adding the LRI as an option for reporting to PHAs, in addition to the existing ELR IG. Additionally, the LRI and LOI IGs could have use beyond public health reporting, which can reduce implementation and maintenance burden for hospitals and providers, as both the LOI and LRI standards have multiple use cases defined in the IGs, allowing for more flexibility, reusability, and scalability. We are proposing to add the option of the public health profile in the LRI IG, given that it is an updated version of the ELR R1 IG, but request comment on whether there are additional profiles that should also be included within the LRI IG as part of the updated Sec. 170.315(f)(3) certification criterion. The LOI IG makes important patient demographic information required, including race, ethnicity, sex, and contact information, which may allow PHAs to get more complete data in circumstances when the laboratory has these data elements and can appropriately fill the fields. This demographic information can also be used to improve patient matching, which in turn improves patient care and the efficiency of care. In one study, electronic laboratory reports were missing data on race more than one-third of the time and data on ethnicity were present less than one-fifth of the time.\108\ Missing data in laboratory [[Page 63544]] results to PHAs also remains a problem, which has not been solved through various attempts within industry. However, there is currently low uptake of the LOI and LRI standards, despite the increased specificity. We believe that including both standards in the Program will lead to more complete demographic information and higher rates of adoption. --------------------------------------------------------------------------- \108\ Electronic health information quality challenges and interventions to improve public health surveillance data and practice.--Abstract--Europe PMC. https://europepmc.org/article/PMC/3804098. --------------------------------------------------------------------------- We propose that for the time period up to and including December 31, 2027, a Health IT Module may continue to be certified to the existing version of the certification criterion as described in Sec. 170.315(f)(3)(i), with proposed modifications for clarity and with a proposed revision to include the minimum standard code set updates in Sec. 170.207(a), (c), and (m). We propose that a Health IT Module certified to Sec. 170.315(f)(3) must be updated to meet the requirements of the revised certification criterion in Sec. 170.315(f)(3)(ii) and that a health IT developer must provide such updated technology to their customers by no later than December 31, 2027. We propose that any Health IT Module seeking certification to the certification criterion in Sec. 170.315(f)(3) on and after January 1, 2028, must meet the revised requirements in Sec. 170.315(f)(3)(ii). We welcome comment on this proposal. We recognize that there is a high volume of laboratory reporting interfaces in place today, for clinical and public health purposes, among others. As such, we request comment on whether the time period to phase out the ELR IG is sufficient, or if there needs to be a longer transitional period where both LRI and ELR are allowed for the purposes of transmitting laboratory results/values to PHAs. If January 1, 2028, is not feasible for the shift to only using LRI, we request comment on a feasible date for this transition. We further request comment on whether we should specify the LOI IG standard, or whether we should instead include the functional requirements for the receipt, validation, parsing, and filtering of orders without referencing a specific standard. We also request comment on whether there are specific profiles within the LOI IG that should be referenced rather than the IG in its entirety. iv. Sec. 170.315(f)(4)--Cancer Registry Reporting--Transmission to Public Health Agencies Cancer reporting is an important, mandatory component of cancer control efforts in the United States. State registries collect information on diagnosed cases of cancer, treatments, and demographic information. Such information informs interventions and helps allocate resources in communities and populations affected by high rates of cancer. For example, in areas where high rates of breast cancer are diagnosed, PHAs can work with healthcare organizations and providers on programs and efforts to increase early screening and other preventative interventions. We propose to revise the certification criterion in Sec. 170.315(f)(4) to include revised minimum standard code set requirements, updated implementation specifications, and new functionality. Since our last rulemaking cycle, there have been minor updates to the CDA Implementation Guide for Cancer Registry Reporting,\109\ which is currently referenced in Sec. 170.205(i)(2) and is required by the certification criterion. There is also a FHIR IG for cancer registry reporting that has been used in several pilots: Central Cancer Registry Reporting Content IG 1.0.0--STU 1.\110\ --------------------------------------------------------------------------- \109\ http://www.hl7.org/implement/standards/product_brief.cfm?product_id=398. \110\ https://build.fhir.org/ig/HL7/fhir-central-cancer-registry-reporting-ig/usecases.html. --------------------------------------------------------------------------- We propose to modify the certification criterion to specify that a Health IT Module would need to support the creation and submission of cancer registry reports using either (at least one) of these standards: The cancer FHIR reporting bundle and accompanying profiles according to the HL7 FHIR Central Cancer Registry Reporting Content IG 1.0.0--STU1 in Sec. 170.205(i)(3), with the requirement that all data elements indicated as ``mandatory'' and ``must support'' in the IG must be supported, including support for the requirements described in the ``Central Cancer Registry Reporting HER Capability Statement,'' or The HL7 CDA[supreg] Release 2 Implementation Guide: Reporting to Public Health Cancer Registries from Ambulatory Healthcare Providers, Release 1, DSTU Release 1.1--US Realm in Sec. 170.205(i)(2). Our intent would be that a certified Health IT Module supports at least one of these kinds of standards, but we do not preclude a Health IT Module from supporting both. However, we request comment on this approach and on whether we should instead require a Health IT Module certified to this certification criterion to support both the CDA IG and the FHIR reporting bundle and accompanying profiles within the Central Cancer Registry Reporting Content IG for the purpose of cancer registry reporting. We also note our proposal to create a standardized API for public health in Sec. 170.315(g)(20) as described section III.B.13.f, which also addresses standards-based API information exchange for public health. We also propose the inclusion of an additional requirement within the cancer registry reporting certification criterion, to include cancer pathology reporting. Cancer pathology reporting is an important component of diagnosing cancer and understanding how advanced cases are at the point of diagnosis. Pathology reporting for this certification criterion has not been part of our Program in the past, but we have heard feedback that pathology laboratory data is not being collected or exchanged in a standard way. Having standardized, electronic pathology reports would be an important foundation to more complete and accurate understanding of cancer diagnoses and assessing the stage at diagnosis. However, for cancer registries to receive all the information needed for accurate assessment, the data elements within the LRI IG are not enough for cancer pathology reporting. As such, CDC's National Program of Cancer Registries has been actively working with state PHAs and pathology partners, including the College of American Pathologists (CAP), to develop and pilot a FHIR Implementation Guide for cancer pathology reporting: Cancer Pathology Data Sharing 1.0.0--STU1. Early results of these pilots demonstrate that use of this implementation guide will reduce the need for manual intervention and data cleansing, aid in more timely reporting, and include data elements that are important for public health action. We propose to adopt the standard HL7 FHIR Cancer Pathology Data Sharing, 1.0.0--STU1 in Sec. 170.205(i)(4) and incorporate it by reference in Sec. 170.299. We also propose to revise Sec. 170.315(f)(4)(ii) to add a requirement in Sec. 170.315(f)(4)(ii)(C) to create and transmit cancer pathology laboratory values and results in accordance with the proposed standard referenced in Sec. 170.205(i)(4), Cancer Pathology Data Sharing, 1.0.0--STU1, including support for all ``mandatory'' and ``must support'' data elements within the IG, including support for the requirements described in the ``Central Cancer Registry Reporting Pathology EHR Capability Statement.'' We also propose changes to the name of this certification criterion. Specifically, we propose to change the name from ``Transmission to cancer registries'' to ``Cancer registry [[Page 63545]] reporting--Transmission to public health agencies''. We welcome comments on the above proposal. Finally, we propose to add a timeline to allow certification of a Health IT Module to the current certification criterion in Sec. 170.315(f)(4) for the period up to and including December 31, 2027, after which period only the revised certification criterion in Sec. 170.315(f)(4)(ii) would be available for certification. We propose that, for the time period up to and including December 31, 2027, a Health IT Module may continue to be certified to the existing version of the certification criterion as described in Sec. 170.315(f)(4)(i), with modifications for clarity and with a proposed revision to include the minimum standard code set updates. The proposed revisions to the certification criterion include updates to the same minimum standards updates, use of newer versions of implementation specifications, and new functionality as described above. We propose that a Health IT Module certified to Sec. 170.315(f)(4) must be updated to meet the requirements of the revised certification criterion and that a health IT developer must provide such updated technology to their customers by no later than December 31, 2027. We propose that a Health IT Module seeking certification to Sec. 170.315(f)(4) on and after January 1, 2028, must meet the requirements described in Sec. 170.315(f)(4)(ii). We welcome comments on the above proposal. v. Sec. 170.315(f)(5) Electronic Case Reporting--Transmission to Public Health Agencies In the HTI-1 Final Rule, we finalized requirements in Sec. 170.315(f)(5) for compliance with specific standards for electronic case reporting to PHAs (89 FR 1231). Based on commenters' response to the proposal, we finalized allowing either the CDA or FHIR standard for the transmission of electronic case reports and reportability responses (RRs), as well as the ability to consume and process electronic case reporting trigger codes based on a match from the Reportable Conditions Trigger Code (RCTC) value set as specified in the HL7 FHIR electronic case reporting (eCR) IG. As finalized in the HTI-1 Final Rule, after December 31, 2025, developers would only be able to certify to case reporting using the standards-based approach described Sec. 170.315(f)(5)(ii), and previously certified products would need to update their certification to the standards-based approach described in Sec. 170.315(f)(5)(ii) by December 31, 2025 (89 FR 1228). We believe requiring Health IT Modules to conform to a single standard, specifically the HL7 FHIR standard, would coalesce industry, PHAs, and other interested parties to dedicate resources towards improved functionality and interoperability for electronic case reporting. The use of HL7 FHIR-based solutions encourages more flexibility and reduced burden for both initial development as well as maintenance for healthcare information technology developers and aligns with CDC's Public Health Data Strategy. The Public Health Data Strategy prioritizes electronic case reporting as an important automation that reduces burden and encourages more complete and timely data exchange. We propose no changes to the capabilities specified within the certification criterion in Sec. 170.315(f)(5), but we do propose to update the standard used for the certification criterion in Sec. 170.205(t)(2). Given the potential benefits of adopting a single standard, and our overall progress toward shifting to HL7 FHIR-based standards and solutions when appropriate and feasible, we propose that adoption of the CDA-based standard in Sec. 170.205(t)(2) expires on January 1, 2028. This proposal would have the effect of requiring all Health IT Modules certified to Sec. 170.315(f)(5) to use the eICR profile of the HL7 FHIR eCR IG in Sec. 170.205(t)(1). We propose that Health IT Modules be required to support the HL7 FHIR-based IGs beginning January 1, 2028 to allow developers, intermediaries, and PHAs to make the needed updates to the HL7 FHIR eCR IG and develop needed system upgrades and solutions to transmit electronic case reports and receive RRs that adhere to the HL7 FHIR eCR IG implementation specification adopted in Sec. 170.205(t)(1). We propose to maintain in Sec. 170.315(f)(5)(ii) adherence to specific aspects of the HL7 FHIR eCR IG to allow for flexibility: the electronic initial case report (eICR) profiles and the RR profile of the HL7 FHIR eCR IG, and the ability to consume and process electronic case reporting trigger codes and identify a reportable patient visit or encounter based on a match from the Reportable Conditions Trigger Code value set as specified in the HL7 FHIR eCR IG. We welcome comments on this proposal. vi. Sec. 170.315(f)(6)--Antimicrobial Use and Resistance Reporting-- Transmission to Public Health Agencies The monitoring of antimicrobial use and resistance is a vital component of public health reporting, particularly as antimicrobial resistance rates continue to rise across the United States.\111\ In order to adequately address this issue, timely reporting to PHAs is important; such reporting can allow for prescribers to receive feedback regarding prescribing practices and improve the appropriate use of antimicrobials. --------------------------------------------------------------------------- \111\ https://www.cdc.gov/nhsn/pdfs/pscmanual/11pscaurcurrent.pdf. --------------------------------------------------------------------------- CDC's National Healthcare Safety Network (NHSN) collects information on antimicrobial use and resistance from inpatient facilities enrolled in and reporting to its Patient Safety Component, including (but not limited to) general hospitals, CAHs (critical access hospitals), children's hospitals, long term acute care hospitals, military and veterans' hospitals, psychiatric hospitals, and rehabilitation hospitals. CDC uses antimicrobial use and resistance data reported through NHSN to generate metrics that states, facilities, and other users, such as hospital associations, use to improve clinical care and guide public health action. These data also provide a national picture of the threat posed by antimicrobial overuse and resistance. Given the importance of these data for patient safety and national efforts to combat antibiotic resistance, in FY 2022, CMS finalized a requirement that eligible hospitals and CAHs participating in the Medicare Promoting Interoperability Program must begin reporting a new Antimicrobial Use and Resistance (AUR) Surveillance measure for Electronic Health Record (EHR) reporting periods in calendar year (CY) 2024 (87 FR 49335 through 49337). We propose minimal changes to the certification criterion in Sec. 170.315(f)(6), specifically, revising to reference the standard in Sec. 170.205(r) instead of the current reference to Sec. 170.205(r)(1). We then propose several revisions to the standard adopted in Sec. 170.205(r). Specifically, we propose the adoption of the standard in Sec. 170.205(r)(1) would expire on January 1, 2027. We also propose that the standard in Sec. 170.205(r)(1) only requires conformance to Sec. 170.205(r)(1)(i) and (ii) for the time period up to and including December 31, 2025. We propose to add an updated version of the standard in Sec. 170.205(r)(2) to include HL7 CDA[supreg] R2 Implementation Guide: Healthcare Associated Infection (HAI) Reports, Release 3--US Realm, December 2020 and to incorporate it by reference in Sec. 170.299. The updated IG can lead to more specific and complete information being shared with PHAs, allowing for follow-up activities and research to address rising rates of antimicrobial resistance. The updated version [[Page 63546]] includes new and updated templates and value sets that enable more advanced reports. This proposal would mean that the updated templates in the new IG would replace the two specific components of the prior IG in Sec. 170.205(r)(1) identified for expiration on January 1, 2026, and then upon the expiration of the prior standard in its entirety on January 1, 2027, the updated template in the new IG in Sec. 170.205(r)(2) would become the only applicable version of the specifications for certification to the certification criterion. This updated version of the standard was previously advanced for voluntary adoption under our SVAP process for two of the three sections required within the current certification criteria: HAI Antimicrobial Use and Resistance (AUR) Antimicrobial Resistance Option (ARO) Report (Numerator) specific document template in Section 2.1.2.1 and Antimicrobial Resistance Option (ARO) Summary Report (Denominator) specific document template in Section 2.1.1.1. We propose advancing to the updated version by expiring the adoption of the prior standard components on January 1, 2026, for two of the required sections of the implementation guide referenced within current certification criteria given benefits listed above and advancement of system capabilities to support the standard since previous SVAP cycles. The third required component, ``Antimicrobial Use (AUP) Summary Report (numerator and denominator)'' should continue to use the standard HL7 Implementation Guide for CDA Release 2--Level 3: Healthcare Associated Infection Reports, Release 1, U.S. Realm, until the expiration date of the entire standard on January 1, 2027. The two required components that are in the updated IG are HAI Antimicrobial Use and Resistance (AUR) Antimicrobial Resistance Option (ARO) Report (Numerator); Antimicrobial Resistance Option (ARO) Summary Report (Denominator). We also propose minimal changes to the name of the certification criterion in Sec. 170.315(f)(6) to be ``Antimicrobial use and resistance reporting--Transmission to public health agencies.'' We welcome comments on the above proposal. vii. Sec. 170.315(f)(7)--Health Care Surveys--Transmission to Public Health Agencies Data from the National Health Care Surveys, sent to CDC's National Center for Health Statistics, provides information on healthcare utilization, and includes information related to symptoms, diagnoses, and procedures. These surveys are nationally representative, provider- based, and cover a broad spectrum of healthcare settings. Within each setting, data are collected from a sample of organizations that provide care and from samples of patient (or discharge) encounters within the sampled organizations. Data are collected not only from traditional healthcare settings such as hospitals and physicians' offices, but also from long-term care providers and community health centers. These surveys help provide insight to inform policy, research, and quality; sending them electronically allows for wider representation from hospitals and healthcare organizations, as well as reduces manual burden on the reporters.\112\ Improving the process for electronic collection of survey data, including the use of standards, could make these important surveys easier to administer. --------------------------------------------------------------------------- \112\ https://www.cdc.gov/nchs/dhcs/index.htm?CDC_AA_refVal=https%3A%2F%2Fwww.cdc.gov%2Fnchs%2Fdhcs.htm. --------------------------------------------------------------------------- We propose minimal changes to the certification criterion in Sec. 170.315(f)(7), specifically, revising to reference the standard in Sec. 170.205(s) instead of the current reference to Sec. 170.205(s)(1). We then propose to add an expiration date of January 1, 2027, to the standard for healthcare survey information for electronic transmission specified in Sec. 170.205(s)(1). We also propose to revise Sec. 170.205(s)(2), which is currently reserved, to reference HL7 CDA R2 Implementation Guide: National Health Care Surveys (NHCS), R1 STU Release 3.1--US Realm and incorporate it by reference in Sec. 170.299. To advance the electronic transmission of healthcare surveys and include the relevant and needed information to achieve its intent, we propose this version of the standard, as it includes new and updated templates with important context. These revisions include, but are not limited to, changes to sections for emergency department encounters, patient information sections, gender identity observation, and number of visits over the past 12 months. Such information will provide additional insight on trends in hospitalization, surveillance of symptomology and diagnoses, and demographics that can highlight disparities and better inform interventions. We are aware that the HL7 FHIR Health Care Surveys Content Implementation Guide has gone through the HL7 approval process and was published in 2023. We are further aware that a FHIR pilot project for using FHIR standards to send survey information was initiated in fall of 2023. We have not proposed to include this newer, FHIR-based standard for healthcare survey information at this time, but request feedback on whether it should be an option for health care surveys. Specifically, we request comment on whether we should consider modifying the certification criterion to require a Health IT Module certified to this criterion to support creation and submission using at least one of these standards: The HL7 FHIR Health Care Surveys Content IG; or, The HL7 CDA R2 Implementation Guide: National Health Care Surveys (NHCS), R1 STU Release 3.1--US Realm. Under this alternative, a Health IT Module certified to this criterion would be required to support at least one of these kinds of standards but would not be precluded from supporting both. We welcome comment on this proposal--in particular, on current usability and maturity of the FHIR IG and readiness among certified health IT vendors to implement it. We also propose minimal changes to the name of this certification criterion in Sec. 170.315(f)(7) to be ``health care surveys-- transmission to public health agencies.'' We welcome comment on this proposal, including on FHIR-based approaches. e. New Certification Criteria for Health IT Modules Supporting Public Health Data Exchange We propose to establish new certification criteria as described below for Health IT Modules supporting public health data exchange. These certification criteria would certify the ability of Health IT Modules to receive HL7 v2, CDA-based, and/or FHIR reports for birth reporting and Prescription Drug Monitoring Programs (PDMPs). Additionally, certification criteria proposed in this section would certify receive, validate, parse, and filter capabilities related to immunization information, syndromic surveillance, cancer pathology reports, electronic case reporting, birth reporting, and PDMP data. i. Sec. 170.315(f)(8)--Birth Reporting--Transmission to Public Health Agencies Providers currently rely on manual and duplicative data entry processes to report information on live births to state vital records offices. With most U.S. births occurring in hospitals or free-standing birthing facilities, birth reporting typically entails clinicians supplying the medical and health information for the birth certificate to a [[Page 63547]] state web-based Electronic Birth Registration System (EBRS) or nonclinical hospital staff reviewing the hospital medical records for the information and entering it into the state EBRS. The legal and demographic information is typically collected directly from the mother using a standardized worksheet, and the information is then entered into the State EBRS by nonclinical hospital staff. This information is then sent to the state and a birth certificate is then issued by the state vital records authority. Much of the medical and health information collected for the birth certificate necessary to report a live birth is also dually entered into EHRs by health care providers. As a result, birth reporting processes are duplicative and burdensome for providers and hospital systems. Low adoption of standards to exchange data between EHRs and EBRSs have resulted in an overall lack of interoperability between all systems involved in birth reporting processes. CDC has provided significant funding and resources to support the adoption of EBRSs by PHAs and providers. Recent funding has also been provided to PHAs to develop and advance the use of the FHIR standard to report information. Despite investments made by CDC towards standards-based exchange with EBRSs, there has been very little uptake of these standards and associated functionalities by health IT developers. We propose to adopt a new certification criterion, ``Birth reporting--Transmission to public health agencies.'' As a part of this new certification criterion, we propose to adopt the HL7 FHIR Vital Records Birth and Fetal Death Reporting-1.1.0--STU 1.1 in Sec. 170.205(v) for electronically submitting medical and health information from birth certificate reports to PHAs.\113\ However, if an updated version of this IG is published prior to the publication of a final rule, and made available to the public, it would be our intent to consider adopting the updated IG if it best aligns with and supports effective implementation of this proposed certification criterion. Based on public comments on HTI-1 and prior rulemakings, we believe that the health IT industry, healthcare standards developers, and health care providers expect and support ONC making such determinations so that the adopted version of standards are the most up-to-date available and are feasible for real-world implementation (see 89 FR 1215). We encourage commenters to comment on the preferred version associated with this proposal. --------------------------------------------------------------------------- \113\ Please see https://hl7.org/fhir/us/bfdr/2024Jan/. --------------------------------------------------------------------------- Additionally, we request comment specifically on whether the content specified in the IG can be exchanged using transport mechanisms defined in Sec. 170.315(g)(10) and in the proposed Sec. 170.315(g)(20) certification criteria. The selected information included in the standard in Sec. 170.205(v) was piloted by the Michigan Health and Human Services Division for Vital Records and Health Statistics with four Michigan hospitals and their EHRs. In Michigan, the pilot has found increased data completion and accuracy for many data items when births are reported using the FHIR standard and a SMART-on-FHIR app when compared to reports completed manually by hospital staff.\114\ We believe the standard, when adopted broadly, could aid in timely, more complete, and accurate reporting from hospitals with reduced burden on the reporting facilities. We seek comment from those who have implemented and used the IG on its readiness for nationwide adoption. --------------------------------------------------------------------------- \114\ Final Report submitted to Centers for Disease Control and Prevention In response to Request for Task Order Proposal No. (MI 2020-Q-45799), June 16, 2023. --------------------------------------------------------------------------- As an alternative to the IG proposed above, we propose, and seek comment on, adoption of an interim standards-agnostic functional criterion for electronically transmitting medical and health information from birth certificate reports to PHAs based on the data elements outlined in CDC National Vital Statistics System's ``Guide to Completing the Facility Worksheets for the Certificate of a Live Birth and Report of Fetal Death.'' \115\ We further seek comment on the potential benefits and risks of adopting a functional approach, particularly as CDC's NCHS has retired and will not be actively updating the HL7 Version 2.6 Implementation Guide: Vital Records Birth and Fetal Death Reporting, Release 1 STU Release 2 and the HL7 CDA R2 Implementation Guide: Birth and Fetal Death Reporting, Release 1, STU Release 2--U.S. Realm standards. Finally, we request comment on whether a functional approach--if adopted--should be time-limited and require a transition to a standards-based approach as of a specific timeline. For example, a functional approach could be permitted for certification up to and including December 31, 2026, and then the standards-based approach for conformance would be required thereafter. --------------------------------------------------------------------------- \115\ https://www.cdc.gov/nchs/nvss/facility-worksheets-guide.htm. --------------------------------------------------------------------------- ii. Sec. 170.315(f)(9)--Prescription Drug Monitoring Program (PDMP) Databases--Query, Receive, Validate, Parse, and Filter We propose to adopt a new certification criterion to enable the bi- directional interaction and electronic data exchange between Health IT Modules and PDMP databases (referred to hereafter as PDMPs). Specifically, we propose a certification criterion to enable the query of prescription drug monitoring systems and the receipt, validation, parsing, and filtering of medication information from PDMPs. This aligns with a current requirement in CMS' Medicare Promoting Interoperability Program where Query of PDMP is a required measure. PDMP Background ONC has engaged in collaborative work to understand health IT's role in addressing the opioid crisis, including the opportunities created by state-run health IT systems known as PDMPs.\116\ PDMPs are state-run electronic databases that provide critical health information to physicians and other health care providers about an individual's history of controlled substance prescriptions (and, in some states, more complete histories of all prescriptions). Evaluations of PDMPs suggest their use supports changes in prescribing behaviors, reduces use of multiple providers by patients, and decreases treatment admissions associated with substance misuse.\117\ --------------------------------------------------------------------------- \116\ See for reference: https://www.healthit.gov/sites/default/files/page/2023-03/LPASO_Landscape_Assessment_508.pdf. \117\ See for reference: https://www.cdc.gov/drugoverdose/pdmp/index.html. --------------------------------------------------------------------------- Beginning in 2012, ONC, in collaboration with the Substance Abuse and Mental Health Services Administration (SAMHSA), sought to identify ways to use health IT to improve access to PDMPs. The collaborative project resulted in the development of the ``Enhancing Access to Prescription Drug Monitoring Programs Using Health Information Technology: Work Group Recommendations Report,'' \118\ and 13 pilot studies to test the feasibility of connecting PDMPs with health IT systems.\119\ --------------------------------------------------------------------------- \118\ Enhancing Access to Prescription Drug Monitoring Programs Using Health Information Technology. (2012). https://www.healthit.gov/sites/default/files/work_group_document_integrated_paper_final_0.pdf; see also https://www.cdc.gov/drugoverdose/pdf/pehriie_report-a.pdf. \119\ https://www.healthit.gov/topic/health-it-health-care-settings/enhancing-access-pilot-reports. --------------------------------------------------------------------------- Bipartisan legislation aimed to address the opioid crisis--the 21st Century Cures Act (Cures Act) of 2016 [[Page 63548]] (Pub. L. 114-255),\120\ and the Substance Use Disorder Prevention that Promotes Opioid Recovery and Treatment for Patients and Communities Act (SUPPORT Act) of 2018 (Pub. L. 115-271).\121\ Additionally, the Commission on Combating Drug Addiction and the Opioid Crisis (Commission) was established in 2017 \122\ to develop recommendations to address the opioid epidemic. In November 2017, the Commission released a final report with recommendations focused on reducing barriers and supporting programs and innovations aimed at strengthening Federal, state, and local responses to the opioid overdose epidemic.\123\ Several of the report's recommendations include the use of state-run programs and health IT to address substance use disorder (SUD) and opioid use disorder (OUD). --------------------------------------------------------------------------- \120\ 21st Century Cures Act. (2016). https://www.gov info.gov/content/pkg/PLAW-114publ255/pdf/PLAW-114publ255.pdf. \121\ Substance Use-Disorder Prevention that Promotes Opioid Recovery and Treatment for Patients and Communities Act. (2018). https://www.congress.gov/bill/115th-congress/house-bill/6/text. \122\ The White House. (2017). https://trumpwhitehouse.archives.gov/presidential-actions/president-donald-j-trump-signs-executive-order-establishing-presidents-commission-combating-drug-addiction-opioid-crisis/. \123\ The Commission on Combating Drug Addiction and the Opioid Crisis. (2017). https://www.whitehouse.gov/sites/whitehouse.gov/files/images/Final_Report_Draft_11-15-2017.pdf. --------------------------------------------------------------------------- These laws included important provisions related to PDMPs, health IT supports for OUD, and the integration of health IT supports into clinical workflows for OUD prevention and treatment. Section 1944(b) of the Social Security Act, as added by Section 5042(a) of the SUPPORT Act, also requires that states implement a qualified PDMP and defines the requirements for a qualified PDMP including that the PDMP administered by the state, at a minimum: \124\ --------------------------------------------------------------------------- \124\ Section 1944(b) of the Social Security Act [42 U.S.C. 1396w-3a] as added by section 5042(a) of the Substance Use Disorder Prevention that Promotes Opioid Recovery and Treatment for Patients and Communities Act (SUPPORT Act) of 2018 (Pub. L. 115-271). --------------------------------------------------------------------------- Facilitates access by a covered provider with respect to a covered individual--in as close to real time as possible--of patient- specific information for prescription drug history with regard to controlled substances, the number and type of controlled substances prescribed and filled in at least the most recent 12-month period, and information relating to each covered provider of such medications; and Facilitates the integration of the information into the workflow of a covered provider, which may include the electronic system the covered provider uses to prescribe controlled substances. In addition, Section 1944(a) of the Social Security Act, as added by Section 5042(a) of the SUPPORT Act, directs states to implement requirements that certain covered Medicaid Providers check the qualified PDMP for Medicaid beneficiaries' prescription information prior to prescribing applicable controlled substances.\125\ --------------------------------------------------------------------------- \125\ Section 1944(a) of the Social Security Act [42 U.S.C. 1396w-3a] as added by section 5042(a) of the SUPPORT Act of 2018 (Pub. L. 115-271). See also https://www.medicaid.gov/federal-policy-guidance/downloads/faq051519.pdf. --------------------------------------------------------------------------- The establishment and operation of PDMPs vary given that each PDMP is subject to existing policies and management of their own respective state. While PDMPs may operate differently, there are system components guidance that CDC promotes to improve PDMP functionality as a public health tool.\126\ Those include: --------------------------------------------------------------------------- \126\ CDC Clinical Practice Guidelines for Prescribing Opioids (Dowell D, Ragan KR, Jones CM, Baldwin GT, Chou R. CDC Clinical Practice Guideline for Prescribing Opioids for Pain--United States, 2022. MMWR Recomm Rep 2022;71(No. RR-3):1-95. DOI:http://dx.doi.org/10.15585/mmwr.rr7103a1). --------------------------------------------------------------------------- Universal use among clinicians and/or their delegates (for example, nurse practitioners or physician assistants) within a state; More timely or real-time data contained within a PDMP; Actively managing the PDMP in part by sending proactive reports to clinicians to inform prescribing; and Ensuring that PDMPs are easy to use and accessible by clinicians. As of the publication of this proposed rule, 50 states, the District of Columbia, and three territories have established PDMPs, each with various requirements for querying and reporting from pharmacy information systems. Of these 54 PDMPs, 51 have additionally implemented regulations mandating the use of the state PDMP when prescribing controlled substances, sometimes for new patients or other scenarios.\127\ However, despite the increase in PDMP utilization and promising, though mixed, evidence of their effectiveness, PDMPs are only able to truly impact care if prescribers and pharmacists use them, and when PDMP data are easily accessible in clinical workflows and accessible across state lines. While requirements are in place for providers to access PDMPs at the state level, states generally do not have specific requirements for PDMPs to support direct queries--in practice this leads to indirect query workflows and multiple translation points, creating gaps in interoperability. Additionally, there are no widespread established practices for integrating query information into clinical workflows within health IT systems--despite recommendations from CDC that, when prescribing initial opioid therapy for acute, subacute, or chronic pain, clinicians should review a patient's history of controlled substance prescriptions as well as non- opioid therapies using state PDMP data.\128\ In addition, health IT systems may lack sufficient capabilities to reconcile query data from PDMP systems as discrete data element(s). At the same time, PDMPs also need to be able to respond to a query from a certified Health IT Module with discrete data. --------------------------------------------------------------------------- \127\ https://www.medicaid.gov/medicaid/data-and-systems/downloads/rtc-5042-state-challenges.pdf. \128\ CDC Clinical Practice Guideline for Prescribing Opioids for Pain--United States, 2022 [verbar] MMWR. --------------------------------------------------------------------------- Today, authorized users may have to access PDMP data that is not integrated into their workflow, as it is accessed through a separate portal, which may add to clinical burden and decrease the likelihood of checking and utilizing the PDMP data.\129\ These pieces--integrating query information into health IT systems and informing workflow integration practices based on established guidelines, along with reconciling query data as discrete data elements for both the PDMP and certified Health IT Module--are supported by the functions we propose below. --------------------------------------------------------------------------- \129\ https://www.healthit.gov/sites/default/files/page/2023-03/LPASO_Landscape_Assessment_508.pdf. --------------------------------------------------------------------------- From 2018 to 2022, ONC and CDC collaborated on the Advancing PDMP and EHR Integration project. The purpose of this project was to advance and scale vendor agnostic PDMP integrations with health IT systems in a variety of hospital, primary care, and outpatient settings. This effort produced an Integration Framework and Integration Toolkit to serve as technical resources for organizations interested in integrating PDMP with a variety of health IT systems.\130\ The Integration Framework includes how best to implement advanced technologies such as electronic CDS systems that clinicians are increasingly using to combat the opioid crisis as well as information to help improve integration of state PDMPs within clinicians' workflows. The Integration Framework [[Page 63549]] also includes helpful resources, such as MOU, auditing, and testing guidance, which can help advance and scale PDMP integration with health IT systems (e.g., EHR systems, health information exchanges, and pharmacy systems) in a variety of hospital, primary care, and outpatient settings.\131\ --------------------------------------------------------------------------- \130\ HHS ONC/CDC Health Information Technology: Integration Framework for PDMP-EHR Integration: June, 2021: https://www.cdc.gov/opioids/pdf/Integration-Framework.pdf. \131\ ``Using Health IT Integration to Address the Drug Overdose Crisis'' August 2022: https://www.healthit.gov/buzz-blog/electronic-health-and-medical-records/using-health-it-integration-to-address-the-drug-overdose-crisis. --------------------------------------------------------------------------- In 2018, CMS issued frequently asked questions outlining how a state could ensure that its qualified PDMP aligns with and incorporates industry standards, consistent with 42 CFR 433.112(b)(12), and encouraged states to refer to the information on standards in the Interoperability Standards Advisory (ISA) published by the ONC, specifically the section of the ISA describing, ``A Prescriber's Ability to Obtain a Patient's Medication History from a Prescription Drug Monitoring Program,'' which outlined recommended industry standards for PDMP and EHR integration informed by the efforts of ONC and CDC to advance PDMP best practices.\132\ --------------------------------------------------------------------------- \132\ https://www.medicaid.gov/federal-policy-guidance/downloads/faq051519.pdf. --------------------------------------------------------------------------- The 2022 CDC Clinical Practice Guideline for Prescribing Opioids for Pain \133\ (2022 Clinical Practice Guideline) includes information that updates and replaces the 2016 CDC Guideline for Prescribing Opioids for Chronic Pain. The 2022 Clinical Practice Guideline provides evidence-based recommendations for prescribing opioid pain medication for acute, subacute, and chronic pain for outpatients aged 18 years or older, excluding pain management related to sickle cell disease, cancer-related pain treatment, palliative care, and end-of-life care. The 2022 Clinical Practice Guideline takes into account new science and data, along with lessons learned about the challenges faced by patients managing pain and pain care. The 2022 Clinical Practice Guideline also includes a key update that specifies which recommendations apply to patients who are being considered for initial treatment with prescription opioids versus those that have already been receiving opioids as part of ongoing care. --------------------------------------------------------------------------- \133\ CDC Clinical Practice Guideline for Prescribing Opioids for Pain--United States, 2022 https://www.cdc.gov/mmwr/volumes/71/rr/rr7103a1.htm. --------------------------------------------------------------------------- In March of 2023, ONC published a report from the Leveraging PDMPs and Health IT for Addressing SUD/OUD (LPASO) Project landscape assessment. The LPASO Project was originally established in 2018 to examine how jurisdictions utilize PDMPs and health IT to support SUD/ OUD identification, prevention, and treatment. Specifically, ONC was interested in identifying and describing the policy and technical approaches to addressing the opioid overdose epidemic related to PDMPs for several key characteristics termed ``indicators'' (bolded for emphasis).\134\ The PDMP indicators included in this analysis were: --------------------------------------------------------------------------- \134\ Leveraging Prescription Drug Monitoring Programs and Health Information Technology for Addressing Substance Use Disorder and Opioid Use Disorder: A Landscape Assessment of Prescription Drug Monitoring Programs and Health Information Technology Indicators-- March 2023: https://www.healthit.gov/sites/default/files/page/2023-03/LPASO_Landscape_Assessment_508.pdf. --------------------------------------------------------------------------- PDMP data placement in health IT systems: State statutes and policies that allow PDMP data to be stored in another system such as the EHR (e.g., included in provider notes, medication history, etc.) as compared to a one-time view of the PDMP data. Interpretation of PDMP data: State statutes and policies related to the use of PDMP data for predictive analytics such as risk scores. PDMP access roles: Categories of professionals who are authorized by state statute or other policies to access PDMP data. PDMP hospital integration: Prevalence of PDMP integration within the clinical workflow. This indicator examined whether hospitals provided access to the PDMP within the hospital's EHR system or outside of the hospital's EHR system via a PDMP portal or secure website. Data standards and hubs used for PDMP data capture, exchange, and reporting: Health IT components and data standards in use for the transport, interpretation, and integration of PDMP data including those used for interstate data sharing. The LPASO report presented the findings of the landscape analysis for each of these indicators, which is summarized below. The LPASO Project identified that where state law permitted the care team access to the PDMP data within a medical record and to incorporate the data as a discrete data element--as opposed to view only access--clinicians are better able to coordinate care, to assess prescribing practices across the organization, and to implement OUD prevention and treatment best practices.\135\ Further, the LPASO Project found that clinical decision support tools can help clinicians across a wide range of specialties to better identify at-risk patients and facilitate best practices for OUD prevention and treatment. However, some clinicians have expressed concern at the potential risk of such analytics tools including variations in threshold values, lack of transparency for algorithms, and the potential for scores to over-simplify risk that could be identified with a more detailed review of PDMP data.\136\ The LPASO report also found that the content received in response to a PDMP query varied in terms of clinical usefulness and, after querying, receiving a risk score based on a proprietary algorithm was of limited utility and inconsistently predictive of negative outcomes.\137\ Additionally, state laws and regulations determine the categories of users who are authorized to access and use a state's PDMP data, and there is considerable variability in the number and types of access roles identified in each state. A 2018 analysis of the PDMP Training and Technical Assistance Center's (TTAC) data revealed that there are 63 unique access roles identified across all states and jurisdictions. This analysis indicated: --------------------------------------------------------------------------- \135\ Ibid. \136\ Call for better validation of opioid overdose risk algorithms [verbar] Journal of the American Medical Informatics Association [verbar] Oxford Academic (oup.com). \137\ https://pubmed.ncbi.nlm.nih.gov/31356498/. --------------------------------------------------------------------------- In all states and jurisdictions, prescribers and pharmacists are allowed access to the PDMP. A majority of states and jurisdictions (more than 50) also allow access for law enforcement, physician assistants, nurse practitioners, and prescriber delegates. A majority of states and jurisdictions (more than 40) also include an access role for ``patient.'' \138\ --------------------------------------------------------------------------- \138\ Prescription Drug Monitoring Program Training and Technical Assistance Center. (2018). http://www.pdmpassist.org/content/state-profiles. --------------------------------------------------------------------------- The Prescription Monitoring Information Exchange (PMIX) Healthcare Roles document was developed by the PDMP Training and Technical Assistance Center (PDMP-TTAC) to provide states with a resource to assist in defining a harmonized set of healthcare access roles for PDMP data. The PDMP hospital integration indicator examined whether hospitals provided access to the PDMP within the hospital's EHR system or outside of the hospital's EHR system via a PDMP portal or secure website. In the assessment, less than half of hospitals reported integration of PDMP checks within their EHR workflows. In addition, the variability of tools used to exchange, store, and report PDMP data contributed to the complexity of PDMP [[Page 63550]] ecosystems.\139\ Finally, the LPASO report analyzed several standards that today support PDMP data exchange workflows, including the American Society for Automation in Pharmacy (ASAP) and Prescription Monitoring Information Exchange (PMIX) standards.\140\ These standards, and additional standards for electronic prescribing of controlled substances (EPCS) (such as those referenced for the certification criterion in Sec. 170.315(b)(3)), support specific capabilities that are individually well suited to the task for which they were designed. However, they are not all directly harmonized, which creates challenges when data are moving from one system and one standard to another--for example from the standard transmitted by the clinician to the pharmacy and from the pharmacy to the PDMP. The request/response messages have the same information regardless of the standards in use, but the standards have different naming conventions for the message data, making it necessary to translate requests and responses to enable seamless communication across systems. --------------------------------------------------------------------------- \139\ LPASO--fix citation. \140\ https://www.healthit.gov/isa/allows-exchange-state-prescription-drug-monitoring-program-pdmp-data. --------------------------------------------------------------------------- The applicable standards for the different parts of PDMP workflows are widely adopted to support pharmacy dispense reporting and interstate exchange, but further work in industry is necessary to align current standards with open, consensus-based standards, and specifically with HL7 FHIR.\141\ The HL7 US Meds PDMP FHIR Implementation Guide is intended to define how an EHR or an app or other clinical system can access a patient's controlled substance prescription history from the State PDMP systems. This IG holds promise to advance health IT supports for PDMPs in a more interoperable manner including through new API-enabled transactions, which may also reduce the current translation challenges. However, the IG is based on the HL7 FHIR Release 3, and significant work is needed to advance, ballot, and test a version of the IG that is consistent with API standards adopted in 45 CFR 170.215. --------------------------------------------------------------------------- \141\ HL7 ``US Meds Prescription Drug Monitoring Program (PDMP) FHIR Implementation Guide'': http://hl7.org/fhir/us/meds/pdmp.html. --------------------------------------------------------------------------- While HL7 FHIR-based standards for PDMP exchange are developing and maturing, we propose to adopt functional requirements for exchanging data with PDMPs to make certain that applicable health IT can support capabilities required to engage with a PDMP meeting the requirements under Section 1944(b) of the Social Security Act, as added by Section 5042(a) of the SUPPORT Act.\142\ These capabilities include enabling health IT systems to support integration of query into clinical workflows and to support requirements for the capability to reconcile queried data as discrete data elements (not just as read only). These requirements are also intended to enable the PDMP to respond to a query from a certified Health IT Module with discrete data. As described previously, Section 1944(b) of the Social Security Act defines specific capabilities for a PDMP to be considered a ``Qualified PDMP'' \143\ and there are capabilities that Health IT Modules could support, agnostic to a specific standard, that would be of value to enable engagement with a Qualified PDMP: --------------------------------------------------------------------------- \142\ Section 1944(b) of the Social Security Act [42 U.S.C. 1396w-3a] as added by section 5042(a) of the Substance Use Disorder Prevention that Promotes Opioid Recovery and Treatment for Patients and Communities Act (SUPPORT Act) of 2018 (Pub. L. 115-271). \143\ Ibid. --------------------------------------------------------------------------- Enabling a user to query controlled substance prescription history from their state PDMP for a specific patient. Enabling a user to receive a response to their PDMP queries containing patient-specific controlled substance prescribed and dispensed prescription data. Supporting that all transactions can be sent and received from within electronic prescribing or EPCS workflows. In order to support clinical and public health programs targeting the prevention and treatment of SUD/OUD, there are additional capabilities that Health IT Modules could support, agnostic to a specific standard, that would be of value. These include considerations of what should be a part of the PDMP (e.g., interstate query) as well as related to the PDMP indicators data placement, interpretation, access roles, and integration into clinical workflows. Based on the findings of the LPASO report for each PDMP indicator, public forums with clinical and behavioral health care providers, and the 2022 Clinical Practice Guideline recommendations, these capabilities include: Enabling a user to query controlled substance prescription history from another state's PDMP for a specific patient. Enabling a user to receive a response to their interstate PDMP queries containing patient-specific controlled substance prescribed and dispensed prescription data. Enabling a user to validate, parse, and filter the PDMP data included in the responses received as discrete data elements-- including to reconcile the data into a patient's medication list. Enabling access roles for clinicians and pharmacists, and with additional capabilities to create and allow customized access roles for any delegate or surrogate under applicable law such as physician assistants, nurse practitioners, and clinician delegates. Enabling an audit log of PDMP access. Enabling the use of clinical decision support tools that support clinical prescribing guideline recommendations such as those described in the 2022 Clinical Practice Guideline. Enabling automated or passive queries for specific common workflows consistent with state requirements and best practice guidelines Enabling implementation of the capabilities within other applicable workflows--such as administrative or transition of care workflows--consistent with SUD/OUD prevention and treatment best practice guidelines. Given the current state of PDMP data exchange, we believe it is not yet feasible to adopt certification criteria leveraging the individual standards that currently support PDMP data exchange workflows. While standards developing organizations (SDOs) continue to work toward open API-enabled solutions for PDMPs, continued commitment and development effort is needed to advance FHIR-based implementation specifications to achieve readiness for widespread adoption and use. In the interim, we believe inclusion of a functional criterion within the Program may help to advance systems to support the capabilities described in the SUPPORT Act \144\ and implement recommendations and best practices per the 2022 Clinical Practice Guideline (i.e., Recommendation 9 to check PDMPs) as well as addressing the impact factors identified in the LPASO report. Therefore, we propose to adopt a new certification criterion to improve interoperability between health IT and PDMPs. Specifically, we propose a new certification criterion in Sec. 170.315(f)(9) entitled ``Prescription Drug Monitoring Program (PDMP) Databases--Query, receive, validate, parse, and filter.'' We propose that this criterion would be a functional criterion agnostic to a specific PDMP standard, but would include transport, content, and vocabulary standards where appropriate. We additionally propose to include functional requirements for [[Page 63551]] access controls including access roles and audit logs within this new criterion. --------------------------------------------------------------------------- \144\ Ibid. --------------------------------------------------------------------------- We propose requirements in Sec. 170.315(f)(9) to enable a user to query a PDMP, including bi-directional interstate exchange, to receive PDMP data in an interoperable manner, to establish access roles in accordance with applicable law, and to maintain records of access and auditable events. We propose requirements in Sec. 170.315(f)(9)(i) to enable both passive and active bi-directional query of a PDMP, including an interstate exchange query, and send an acknowledgement message in response to receipt of data after a query is performed. We propose requirements in Sec. 170.315(f)(9)(i)(A) to initiate a passive or automated query upon the recording, change, or access of a medication order; upon the creation and transmission of an electronic prescription for a controlled substance; and upon entry of controlled substance medication data into a medication list or reconciliation of a medication list including controlled substance medication data. We also propose requirements in Sec. 170.315(f)(9)(i)(B) to enable an active or user-initiated query of a PDMP including an interstate exchange query. In Sec. 170.315(f)(9)(i)(C), we propose to send an acknowledgement message in response to receipt of data after a query is performed. We propose requirements in Sec. 170.315(f)(9)(ii) to enable a user to receive, validate, parse, and filter electronic PDMP information. We propose requirements in Sec. 170.315(f)(9)(ii)(A) to enable a user to receive electronic controlled substance medication prescription transmitted through a method that conforms to the standard in Sec. 170.202(d), from a service that has implemented the standard specified in Sec. 170.202(a)(2); through a method that conforms to the standard in Sec. 170.205(p)(1) when the technology is also using an SMTP-based edge protocol; and via an application programming interface in accordance with the standard specified in Sec. 170.215(a)(1). We propose an optional capability to enable a user to receive electronic PDMP information governed by Trusted Exchange Framework and Common Agreement (TEFCA). In other words, that the Health IT Module is connected via the network enabled by TEFCA and can demonstrate that it can exchange data using it. We propose requirements in Sec. 170.315(f)(9)(ii)(B) to demonstrate the ability to detect valid and invalid electronic controlled substance medication prescription received. We propose requirements that a Health IT Module certified to this certification criterion include the capability to identify valid electronic controlled substance medication prescription received and process the data elements including any necessary data mapping to at least one of the versions of the USCDI standard in Sec. 170.213 to enable use as discrete data elements, aggregation with other data, incorporation into a patient medication list, and parsing and filtering in accordance with the requirement proposed in Sec. 170.315(f)(9)(ii)(C) described below. We also propose requirements that a Health IT Module certified to this certification criterion include the capability to: correctly interpret empty sections and null combinations; detect errors in electronic controlled substance medication prescription received, including invalid vocabulary standards and data not represented using a vocabulary standard; and record errors encountered and allow a user through at least one method to be notified of the errors produced, review the errors produced, and store or maintain error records for audit or other follow up action. We propose requirements in Sec. 170.315(f)(9)(ii)(C) to enable a user to parse and filter electronic PDMP information received and validated in accordance with paragraph Sec. 170.315(f)(9)(ii)(B) at a minimum for any data element identified in at least one of the versions of the USCDI standard in Sec. 170.213. We propose requirements in Sec. 170.315(f)(9)(iii) to enable access controls. This includes enabling access roles and recording access, including actions for auditable events and tamper-resistance. We propose requirements in Sec. 170.315(f)(9)(iii)(A) to enable access roles for clinicians and pharmacists and to enable a user to customize additional roles for any delegate or surrogate under applicable law. Additionally, we propose requirements in Sec. 170.315(f)(9)(iii)(B) to record access actions and maintain an audit log of actions. We note that in our proposed certification criterion, we describe a passive or automated query as well as an active query. A passive or automated query is a query initiated by the system when another related action occurs--for example, a system automatically initiates a query on behalf of the clinician when the clinician uses an electronic prescribing module to send a prescription for a controlled substance. In such a case, the system may be configured to pair with a certified or non-certified Health IT Module that enables the EPCS in order to initiate the query without additional action by the clinician. An active query refers to a query of the PDMP initiated by the user to specifically query the PDMP based on their own clinical considerations. An active query might also be in conjunction with other clinical actions, but it should also enable the user to elect to initiate a query as part of other workflows such as administrative or care coordination actions. We welcome public comment on the inclusion of these query types, as well as the specific functions for which a passive query is required. In addition, we note the inclusion of audit requirements and reference to auditable events. We propose that auditable events would include the same functions previously adopted for Sec. 170.315(d)(2), (3), and (10). We note these include referenced standards in Sec. 170.210(e) and (h). However, we have not proposed to specifically adopt auditable event or audit and disclosure log standards for the proposed certification criterion in Sec. 170.315(f)(9) because the specific audit requirements vary across states, access roles, and use cases. However, we seek comment on the potential applicability of such standards for the proposed PDMP data certification criterion. We welcome public comment on this proposal. In addition, we seek public comment specifically on the following areas: Should ONC consider additional functional requirements, or additional constraints on functional requirements, relating to the passive or automated query of a PDMP within EPCS or CPOE workflows? Should ONC consider either additional or reduced specificity within the minimum functions supporting receipt of the PDMP information as discrete data elements? Should ONC further specify or further constrain access roles? For example, should ONC consider adding a ``patient'' access role to the requirements? What access roles would be most beneficial to define more clearly in any final rule or supportive sub-regulatory guidelines? \145\ --------------------------------------------------------------------------- \145\ See, for example, access roles described in the LPASO report, March 2023 at: https://www.healthit.gov/sites/default/files/page/2023-03/LPASO_Landscape_Assessment_508.pdf. --------------------------------------------------------------------------- Are there additional functional capabilities that would support effective SUD/OUD prevention and treatment that should be considered for a future version of the proposed certification criterion? We additionally refer readers to section III.B.13.e.ix describing a new [[Page 63552]] proposed certification criterion in Sec. 170.315(f)(29) that relates to this proposed certification criterion in Sec. 170.315(f)(9). iii. Sec. 170.315(f)(21) Immunization Information--Receive, Validate, Parse, Filter, and Exchange--Response Immunization reporting is a vital component of public health data, and is used by all 50 states, Washington DC, Puerto Rico, and many large local jurisdictions. States that have immunization information systems (IIS) consolidate immunization histories and exchange information with vaccination providers, with the goals of improving vaccination rates and reducing vaccine-preventable diseases. In order to achieve the stated goals of immunization information exchange, PHAs must have the technology in place to perform corresponding functions to certified health IT and receive the same standard included in Sec. 170.315(f)(1). We propose to adopt a new certification criterion for health IT for public health that would focus on immunization information--receipt, validation, parsing, and filtering--adhering to the same standard as required in Sec. 170.315(f)(1). We further propose a requirement for responding to queries from external systems, as well as seek comment on patient access as a complement to the proposed updated requirements in Sec. 170.315(f)(1). Such updates will provide clinicians with querying access to IISs in order to better determine the vaccination status of their patients, among other benefits. By including functions performed by health IT for public health within a certification criterion, the Program advances its focus on bi-directional interoperability between healthcare and PHAs. Such functionality for receipt, validation, query/ response, and patient access should enable more users, including those using a variety of health IT systems, to have the most complete and accurate vaccine history for individuals. This functionality can help advance EHRs, IISs, and intermediaries in alignment, with the same foundational functionalities, and keep data moving with the speed of care. If an individual receives a vaccine from a pharmacy, from a community health clinic, away from their home state, or at their provider's office, any approved user regardless of their health IT should be able to have access to their complete, accurate vaccine history. We believe these proposed requirements, coupled with the proposed Sec. 170.315(g)(20) and updates to Sec. 170.315(f)(1), can move the nation closer to this ideal state. These new capabilities include: receive, validate, parse, and filter incoming data in accordance with at least one of the versions of the standard and applicable implementation specification specified in Sec. 170.205(e); transmission of immunization information electronically in accordance with at least one of the versions of the standard and applicable implementation specification in Sec. 170.205(e); and technical capability to respond to incoming patient- level and/or immunization-specific queries from external systems. We request feedback on the functional requirement to respond to patient- level, immunization-specific queries from external systems and request comment on if the standard referenced in Sec. 170.205(e) is sufficient for the proposed functional requirement to respond to incoming patient- level and immunization-specific queries. We seek comment on if we should also require health IT for public health to share immunization information on a population of patients using the standard specified in Sec. 170.315(g)(20)(ii) in our proposals in section III.B.16, and whether health IT for public health should also be able to support patient access using SMART Health Cards for Immunization Criteria according to Sec. 170.315(j)(22). We specifically request comment on readiness and feasible timelines for these capabilities. Additionally, we recognize that due to the work and collaboration of state immunization programs, IIS vendors, CDC's National Center for Immunization and Respiratory Diseases (NCIRD), and the American Immunization Registry Association (AIRA), immunization systems can do much of what is described above already. Through these NCIRD sponsored and established programmatic requirements and optional testing programs conducted by AIRA, many IISs already meet most of, if not all, of the requirements in the proposed certification criterion. We applaud the work done already, and the intent of our proposal is to ground the certification requirements in what already exists without additional burden or cost for IISs that already participate in the NCIRD requirements. However, we know it is important to codify these functional requirements in the Program to demonstrate the success of modern approaches to data exchange and clinician access to data, and to create a shared floor of functionality for all health IT contributing to immunization information sharing. We propose requirements in Sec. 170.315(f)(21) to enable health IT for public health to receive, validate, parse, and filter electronic immunization information. We also propose requirements in Sec. 170.315(f)(21) to enable health IT for public health to exchange immunization information. These proposed requirements are described below. We propose requirements in Sec. 170.315(f)(21)(i) to enable health IT for public health to receive electronic immunization information transmitted through a method that conforms to Simple Object Access Protocol (SOAP)-based transport. Optionally, to meet the received requirements, a developer (serving as a Participant or Subparticipant of a Qualified Health Information Network\TM\ (QHIN\TM\), or who is a QHIN) may demonstrate receipt through a connection governed by the Trusted Exchange Framework and Common Agreement, receipt through a method that conforms to the standard specified in Sec. 170.205(p)(1) when the technology is also using an Simple Mail Transfer Protocol (SMTP)-based edge protocol, or receipt via an application programming interface in accordance with the standard specified in Sec. 170.215(a)(1) or at least one of the versions of the standard specified in Sec. 170.215(d). We propose requirements in Sec. 170.315(f)(21)(ii) to demonstrate the ability to detect valid and invalid electronic immunization information received and formatted in accordance with the standards specified in Sec. 170.207(e)(5) and Sec. 170.207(e)(6). In order to meet the validate requirements, the health IT for public health must include the capability to identify valid electronic immunization information received and process the data elements required for the standards specified in Sec. 170.207(e)(5) and Sec. 170.207(e)(6). Processing must include any necessary data mapping to enable use as discrete data elements, aggregation with other data, and parsing and filtering in accordance with the parse and filter requirements in the proposed Sec. 170.315(f)(21)(iii). Additionally, in order to meet the validate requirements, the health IT for public health must correctly interpret empty sections and null combinations; detect errors in immunization information received, including invalid vocabulary standards and codes not specified in the standards specified in Sec. 170.207(e)(5) and Sec. 170.207(e)(6); and record errors encountered allowing a user to be notified of the errors produced, to review the errors produced, and to store or maintain error records for audit or other follow up action. We propose that Health IT Modules certified to Sec. 170.315(f)(21)(iii) support users to parse and filter immunization [[Page 63553]] information received and validated in accordance with validate requirements in the proposed Sec. 170.315(f)(21)(ii) according to the standard specified in Sec. 170.207(e)(5) or Sec. 170.207(e)(6). We propose functional requirements in Sec. 170.315(f)(21)(iv) to respond to both incoming patient-level and immunization-specific queries from external systems. We welcome comment on these proposals. iv. Sec. 170.315(f)(22) Syndromic Surveillance--Receive, Validate, Parse, and Filter We propose to adopt a new criterion for the functional requirement to receive, validate, parse, and filter incoming syndromic surveillance information in accordance with at least one of the versions of the standards adopted in Sec. 170.205(d) and not expired for the purposes of certification to criteria in Sec. 170.315(f) at the time of certification. As discussed in Sec. 170.315(f)(2), syndromic surveillance information is vital to the monitoring and early detection of potential public health events. Syndromic surveillance data help provide PHAs the information they need to prevent a public health threat from becoming a public health emergency. Further, since these threats do not respect boundaries, the cross-jurisdictional exchange and national awareness of syndromic surveillance data is vital. The transmission of information electronically, according to the standard specified in Sec. 170.205(d), must be accompanied by the ability to receive and validate information according to the same standard in order to facilitate use of the standardized data for analysis and decision-making. Such functions--receipt and validation--are needed to reduce the need for manual effort or manipulation related to data integration and processing, and to allow for the prompt intake and analysis of information. This process also includes the recipients of reported information in the testing of the workflow at data submission, confirming that what is sent is formatted accurately and allows for validation and processing. Syndromic surveillance has proven to be a highly effective tool for detecting localized trends in outbreaks, and in larger scale monitoring for seasonal illnesses.\146\ The National Syndromic Surveillance Program (NSSP) receives data from over 77% of non-Federal emergency departments nationwide as of July 2023, and does so via jurisdictional PHAs, using the standard specified in Sec. 170.205(d). Many of the systems used today for such monitoring also assisted in predicting trends in the COVID-19 pandemic and estimating future spread.\147\ The pandemic also raised the importance of certain data elements being included in the standard in order to better assess hot spots and inform response, including travel status, pregnancy status, acuity, and admission information--all of which are reflected in the updated version of the standard specified in Sec. 170.205(d). --------------------------------------------------------------------------- \146\ Buehler, J.W., Sonricker, A., Paladini, M., Soper, P., & Mostashari, F. (2008). Syndromic surveillance practice in the United States: findings from a survey of state, territorial, and selected local health departments. Advances in Disease Surveillance, 6(3), 1- 20. \147\ Ibid. --------------------------------------------------------------------------- We propose to require at least one of the versions of the standards and implementation specifications specified in Sec. 170.205(d) for the receipt, validation, parsing, and filtering of incoming syndromic surveillance information. We note that given the widespread implementation of syndromic surveillance, most jurisdictions have technology that can already fulfill many of the proposed requirements. However, we believe that adopting this certification criterion for health IT for public health will reinforce the importance of a foundational functionality requirement for all syndromic surveillance systems to be able to validate and assess incoming information quickly to identify emerging threats. While receipt is a function that most syndromic surveillance systems can accomplish today, our proposal to certify this functionality for health IT for public health would allow for several additional benefits. First, it would include both sending and receiving systems in testing the shared standard, finding issues, and aligning on how to constrain specifications to limit variability. Second, it would advance syndromic surveillance technology on the same path as the systems reporting data to them, to allow all involved systems to grow and align when it comes to data exchange--eliminating the need for manual workarounds or costly third parties to fill the gaps between functionalities. Third, the coordination between sending and receiving systems would compel nationwide upgrades and transitions as public health needs and use cases evolve and shift. We propose that consistent with at least one of the versions of the standards and implementation specifications specified in Sec. 170.205(d), Health IT Modules certified to Sec. 170.315(f)(22) enable a user to receive, validate, parse and filter electronic syndrome-based public health surveillance information in accordance with the proposed Sec. 170.315(f)(22)(i) through (iii). Specifically, we propose to require Health IT Modules certified to Sec. 170.315(f)(22)(i) to receive electronic syndrome-based public health surveillance information transmitted through a method that conforms to a Secure File Transfer Protocol (SFTP) connection. SFTP is designed for securely moving large volumes of data, and syndromic surveillance reporting involves moving thousands of HL7 messages in a single batch. Even though this protocol does not function in real-time, unlike modern application programming interface (API)-based exchanges, and introduces the possibility of human error, this is the preferred protocol in use by NSSP for transport today and is also a key protocol supported by the current CDC architecture. Optionally, to meet the receive requirements, a developer (serving as a Participant or Subparticipant of a QHIN, or who is a QHIN) may demonstrate receipt through a connection governed by the Trusted Exchange Framework and Common Agreement or receipt via an application programming interface in accordance with the standard specified in Sec. 170.215(a)(1) or at least one of the versions of the standard specified in Sec. 170.215(d). We propose in Sec. 170.315(f)(22)(ii) that Health IT Modules certified to that criterion would demonstrate the ability to detect valid and invalid electronic syndrome-based public health surveillance information received and formatted in accordance with at least one of the versions of the standards specified in Sec. 170.205(d). To meet the validate requirements, a Health IT Module certified to this criterion must include the capability to identify valid syndrome-based public health surveillance information received and process the data elements required for at least one of the versions of the standards specified in Sec. 170.205(d). Processing must include any necessary data mapping to enable use as discrete data elements, aggregation with other data, and parsing and filtering in accordance with parse and filter requirements in the proposed Sec. 170.315(f)(22)(iii). A Health IT Module certified to Sec. 170.315(f)(22) must also include the capability to correctly interpret empty sections and null combinations; detect errors in syndrome-based public health surveillance information received, including invalid vocabulary standards and codes not specified in at least one of the versions of the standards specified in Sec. 170.205(d); and, record [[Page 63554]] errors encountered allowing a user to be notified of the errors produced, to review the errors produced, and to store or maintain error records for audit or other follow up action. We propose that Health IT Modules certified to Sec. 170.315(f)(22)(iii) would need to enable a user to parse and filter electronic syndrome-based public health surveillance information received and validated in accordance with the validate requirements in the proposed Sec. 170.315(f)(22)(ii). We welcome comment on these proposals. v. Sec. 170.315(f)(23) Reportable Laboratory Test Values/Results-- Receive, Validate, Parse, and Filter Laboratory-based test results workflow is initiated when a clinician orders a diagnostic test for a patient who presents with symptoms related to a notifiable disease. Laboratory orders are often, but not always, initiated in EHR systems. After the order is placed, the laboratory conducts the test(s) and returns the result(s) to the clinician. The performing laboratory provides the results in various ways, but many laboratories provide the results of the test, ideally electronically, using a Laboratory Information Management Systems (LIMS) or Laboratory Information Systems (LIS). PHAs must also be able to receive the electronically transmitted reportable laboratory test values/results in their system(s) in order to conduct contact tracing, understand disease spread, and have early indications of potential outbreaks. As described in section III.B.18, we propose a requirement in Sec. 170.315(a)(2) that would require a user of a certified Health IT Module to be able to create and transmit laboratory orders electronically according to the standard specified in Sec. 170.205(g)(2). We additionally propose in section III.B.13.d.iii a requirement in Sec. 170.315(f)(3) to create laboratory tests and values/results for electronic transmission, according to specified standards. In order to align all of the technical aspects related to reportable lab data across the different public health and health care entities involved, we propose to adopt a certification criterion in Sec. 170.315(f)(23) to require the functionality for Health IT Modules certified to the criterion to be able to receive, validate, parse, and filter incoming reportable laboratory test values/results. By adopting a certification criterion for health IT for public health to receive results and values back electronically (according to national standards), such systems would be able to support delivering more complete patient information to clinicians throughout the laboratory workflow and to PHAs for public health action. For reportable conditions with associated laboratory results, the laboratory is responsible for sending an electronic laboratory report to the relevant jurisdictional PHAs. We have required the ELR IG as the standard for reporting to PHAs in Sec. 170.315(f)(3) throughout the Program. We understand that most laboratory systems already have the capability of transmitting results to PHAs according to the ELR IG, as demonstrated by the high level of connectedness of laboratories and PHAs. The PHA receiving the related laboratory result or value often, however, does not receive all of the information needed for action, such as patient demographics, creating gaps in understanding and issues with contact tracing and patient outreach to slow the spread of infectious disease. We propose the transition to the LRI IG--the public health profile--to send results to PHAs. This should enable increased completeness of data for public health action. Accordingly, and consistent with at least one of the standards in Sec. 170.205(g)(1) and (3), we propose requirements in Sec. 170.315(f)(23) to enable Health IT Modules certified to the criterion to receive, validate, parse, and filter electronic reportable laboratory test values/results according to either the ELR IG or the LRI IG as described below. We propose that either standard will meet this requirement until the ELR IG expires on January 1, 2028, and we propose a transition to the LRI IG after that date. We note that because Sec. 170.205(g) includes the expiration dates for the applicable standards, they are not duplicated within this certification criterion. We request comment on if this timeline is feasible for this transition. We propose requirements in Sec. 170.315(f)(23)(i) to receive electronic reportable laboratory test values/results transmitted at a minimum through a method that conforms to the standards specified in Sec. 170.202(d), from a service that has implemented the standard specified in Sec. 170.202(a)(2); and, through a method that conforms to the standard in Sec. 170.205(p)(1) when the technology is also using an SMTP-based edge protocol. Optionally, to meet the receive requirements, a developer (serving as a Participant or Subparticipant of a QHIN, or who is a QHIN) may demonstrate receipt through a connection governed by the Trusted Exchange Framework and Common Agreement, or receipt via an application programming interface in accordance with the standard specified in Sec. 170.215(a)(1) or at least one of the standards specified in Sec. 170.215(d). We propose requirements in Sec. 170.315(f)(23)(ii) to demonstrate the ability to detect valid and invalid electronic reportable laboratory test values/results received and formatted consistent with the standard in Sec. 170.205(g)(1) or the Public Health Profile within the implementation specification in Sec. 170.205(g)(3). To meet the validate requirements, health IT for public health must include the capability to identify valid electronic reportable laboratory test values/results received and process the data elements as required by the standard in Sec. 170.205(g)(1) or the standard in Sec. 170.205(g)(3). Processing must include any necessary data mapping to enable use as discrete data elements, aggregation with other data, and parsing and filtering in accordance with parse and filter requirements in the proposed Sec. 170.315(f)(23)(iii). Health IT for public health must also include the capability to correctly interpret empty sections and null combinations; detect errors in electronic reportable laboratory test values/results received including invalid vocabulary standards and codes not specified in the Sec. 170.205(g)(1) or (3) standards; and record errors encountered allowing a user to be notified of the errors produced, to review the errors produced, and to store or maintain error records for audit or other follow up action. We propose requirements in Sec. 170.315(f)(23)(iii) to enable Health IT Modules certified to the criterion to parse and filter electronic reportable laboratory values/results received and validated in accordance with validate requirements in the proposed Sec. 170.315(f)(23)(ii). We welcome comment on these proposals. vi. Sec. 170.315(f)(24) Cancer Pathology Reporting--Receive, Validate, Parse, and Filter We propose to adopt a new certification criterion that is focused specifically on health IT for public health's ability to receive and validate incoming cancer pathology reports according to the proposed standard in Sec. 170.205(i)(4), Cancer Pathology Data Sharing 1.0.0-- STU1 and require conformance with its requirements across the certification criterion. As stated in the discussion above regarding proposed revisions to Sec. 170.315(f)(4), cancer reporting informs cancer control efforts, including programs for preventative interventions. An [[Page 63555]] important component of diagnosing cancer, and particularly in understanding how advanced cases are at the point of diagnosis, is pathology reporting. In section III.B.13.d.iv.4 above, we propose to include cancer pathology reporting as a component of the transmission to cancer registry certification criteria in Sec. 170.315(f)(4). For cancer registries to receive, validate, parse, and filter these reports according to the required standard, we propose to include an accompanying requirement for the receipt, validation, parsing, and filtering of cancer pathology reports in Sec. 170.315(f)(24). Our proposal not only would support cancer registries in having the functionality to accept information in the same standard as sending systems, but it would help sending and receiving health IT progress at the same rate, with aligned functionality. CDC's National Program of Cancer Registries has been actively working with state PHAs and pathology partners, including the College of American Pathologists (CAP), to develop and pilot a FHIR Implementation Guide for cancer pathology reporting. Early results of these pilots demonstrate that use of FHIR by all involved systems will reduce the need for manual intervention and data cleansing, aid in more timely reporting, and include more complete information, including the demographic information needed to confirm reporting is happening within the patient's state of residence, rather than the state of treatment, as well as for patient matching.148 149 --------------------------------------------------------------------------- \148\ Blumenthal W, Alimi TO, Jones SF, Jones DE, Rogers JD, Benard VB, Richardson LC. Using informatics to improve cancer surveillance. J Am Med Inform Assoc. 2020 Jul 1;27(9):1488-1495. doi: 10.1093/jamia/ocaa149. PMID: 32941600; PMCID: PMC7647312. \149\ Ayaz M, Pasha MF, Alzahrani MY, Budiarto R, Stiawan D. The Fast Health Interoperability Resources (FHIR) Standard: Systematic Literature Review of Implementations, Applications, Challenges and Opportunities. JMIR Med Inform. 2021 Jul 30;9(7):e21929. doi: 10.2196/21929. Erratum in: JMIR Med Inform. 2021 Aug 17;9(8):e32869. PMID: 34328424; PMCID: PMC8367140. --------------------------------------------------------------------------- The inclusion of receipt, validation, parsing, and filtering of electronic cancer pathology reporting in the Program would result in more complete, accurate diagnostic information being received by state cancer registries, and contribute to data analysis and early preventative intervention. We propose that consistent with the standard(s) and implementation specification(s) specified in Sec. 170.205(i)(4), Health IT Modules certified to Sec. 170.315(f)(24) enable a user to receive, validate, parse and filter cancer pathology reports in accordance with the proposed Sec. 170.315(f)(24)(i) through (iii). We propose requirements in Sec. 170.315(f)(24)(i) to receive electronic cancer pathology reports transmitted via an application programming interface in accordance with the standard specified in Sec. 170.215(a)(1) or at least one of the versions of the standard specified in Sec. 170.215(d). Optionally, to meet the receive requirements, a developer (serving as a Participant or Subparticipant of a QHIN, or who is a QHIN) may demonstrate receipt through a connection governed by the Trusted Exchange Framework and Common Agreement. We propose requirements in Sec. 170.315(f)(24)(ii) to demonstrate the ability to detect valid and invalid electronic cancer pathology reports received and formatted in accordance with the standards specified in Sec. 170.205(i)(4). To meet the validate requirements, Health IT Modules certified to the criterion must include the capability to identify valid electronic cancer pathology reports and process the data elements required for the standards specified in Sec. 170.205(i)(4). Processing must include any necessary data mapping to enable use as discrete data elements, aggregation with other data, and parsing and filtering in accordance with parse and filter requirements in the proposed Sec. 170.315(f)(24)(iii). Health IT Modules certified to the criterion must also include the capability to correctly interpret empty sections and null combinations; detect errors in electronic cancer pathology reports received, including invalid vocabulary standards and codes not specified in the standards specified in Sec. 170.205(i)(4); and, record errors encountered allowing a user to be notified of the errors produced, to review the errors produced, and to store or maintain error records for audit or other follow up action. We propose requirements in Sec. 170.315(f)(24)(iii) to enable Health IT Modules certified to the criterion to parse and filter electronic reportable cancer pathology reports received and validated in accordance with the validate requirements proposed in Sec. 170.315(f)(24)(ii). We welcome feedback on these proposals. vii. Sec. 170.315(f)(25) Electronic Case Reporting--Receive, Validate, Parse, Filter Electronic Initial Case Reports and Reportability Response; and Create and Transmit Reportability Response Case reporting is a vital component of public health surveillance and case management. Case reports act as early notification of emerging infectious disease outbreaks, as well as early indicators of other threats. For example, case reports demonstrating a rise in human rabies cases could help public health officials understand if there are problems in the local animal population. Case reporting goes beyond COVID-19 and public health emergencies and serves as a key activity to assess, monitor, investigate, and address disease in the community. Therefore, case reporting requires solutions be in place to support these foundational public health services. These activities are achieved by getting data reliably and consistently into health IT for public health for action. In the HTI-1 Final Rule, we finalized requirements in Sec. 170.315(f)(5) for compliance with either the CDA or the FHIR IGs for electronic case reporting to PHAs (89 FR 1226 through1231). However, in section III.B.13.d.v of this proposed rule, we propose updating the Sec. 170.315(f)(5) certification criterion and its standards conformance requirements specified in Sec. 170.205(t) to require adherence only to the HL7 eCR FHIR IG to be updated and provided by December 31, 2027, as part of a predictable multi-year strategy to facilitate the transition from CDA or FHIR to just FHIR. We believe adherence to a single standard, particularly the FHIR IG, will encourage consistent implementation and lead to greater interoperability compared to referencing multiple standards. Upgrading health IT for public health to support APIs and FHIR payload, as included in the HL7 FHIR eCR IG, creates greater flexibility to respond to emergency issues. Improvements in consistent implementation and interoperability would enable PHAs to have an improved picture of where and when disease outbreaks occur. Based on feedback we have heard from PHAs and other public health partners that there are current challenges with technology in place at PHAs to receive, validate, parse, and filter incoming electronic case reports, we recognize that the eCR paradigm's newness for PHAs will mean that it will likely take time to fully utilize the data in public health surveillance systems and registries. Because of the variations and inconsistencies in electronic case reports received from Health IT Modules, PHAs often take manual steps and use additional tools in order to be able to parse case reports. Incoming information frequently needs to be re-formatted and filtered, among other steps, for it to be usable to conduct case investigations. Such steps reduce [[Page 63556]] efficiency and have the potential to delay time-sensitive public health action. We propose to adopt a certification criterion for health IT for public health that focuses on the receipt, validation, parsing, and filtering of electronic case reports and reportability response and creation and transmission of the RR according to at least one of the standards referenced in Sec. 170.205(t). Technology in place at PHAs for case reporting and surveillance must be able to receive, validate, parse, and filter electronic case reports, as well as create and electronically transmit RRs. This requirement should reduce burden on PHAs associated with processing reported data and reduce the need for manual intervention. Further, it advances the health IT for public health that receives reported data to align with the technology that transmits the reports, adhering to the same foundational functions and standards. Supporting this alignment allows the industry to advance in harmony and creates a more scalable infrastructure in daily activities as well as in times of emergency. We note that some PHAs use intermediaries or shared service tools to implement components of the proposed certification criterion. As noted in relied upon software guidance, developers can demonstrate conformance with certification criteria requirements by developing the necessary functionality themselves or by relying on the functionality provided by a different software developer.\150\ While we do not have the ability to require, or provide incentives for, PHAs to adopt certified Health IT Modules, other entities (e.g., another Federal or state agency) could choose to do so. --------------------------------------------------------------------------- \150\ https://www.healthit.gov/sites/default/files/relieduponsoftwareguidance.pdf. --------------------------------------------------------------------------- We propose that consistent with at least one of the standards and implementation specifications specified in Sec. 170.205(t), Health IT Modules certified to Sec. 170.315(f)(25) enable a user to receive, validate, parse, and filter electronic case reporting information in accordance with the proposed Sec. 170.315(f)(25)(i) through (iii), and to create and transmit a reportability response in accordance with the proposed Sec. 170.315(f)(25)(iv). We propose requirements in Sec. 170.315(f)(25)(i) to receive electronic case reports and reportability responses transmitted via an application programming interface in accordance with the standard specified in Sec. 170.215(a)(1) or at least one of the versions of the standard specified in Sec. 170.215(d). Optionally, to meet the receive requirements a developer (serving as a Participant or Subparticipant of a QHIN, or who is a QHIN) may demonstrate receipt through a connection governed by the Trusted Exchange Framework and Common Agreement; or through a method that conforms to the standard specified in Sec. 170.205(p)(1) when the technology is also using an SMTP-based edge protocol. We propose requirements in Sec. 170.315(f)(25)(ii) to demonstrate the ability to detect valid and invalid electronic case reporting information received and formatted in accordance with at least one of the Sec. 170.205(t) standards. To meet the validate requirements, Health IT Modules certified to the certification criterion must include the capability to identify valid electronic case reporting information received and process the data elements for, at a minimum, the data classes expressed in at least one of the versions of the USCDI standard specified in Sec. 170.213. Processing must include any necessary data mapping to enable use as discrete data elements, aggregation with other data, and parsing and filtering in accordance with parse and filter requirements in proposed Sec. 170.315(f)(25)(iii). Health IT Modules certified to the criterion must also include the capability to correctly interpret empty sections and null combinations; detect errors in electronic case reporting information received including invalid vocabulary standards and codes not specified in the Sec. 170.205(t) standards; and record errors encountered allowing a user to be notified of the errors produced, to review the errors produced, and to store or maintain error records for audit or other follow up action. We propose requirements in Sec. 170.315(f)(25)(iii) to enable Health IT Modules certified to the criterion to parse and filter electronic case reporting information received and validated in accordance with validate requirements in the proposed Sec. 170.315(f)(25)(ii) of this section, at a minimum, for any data element identified in at least one of versions of the USCDI standard specified in Sec. 170.213. We propose requirements in Sec. 170.315(f)(25)(iv) to enable a user to create and transmit a response in accordance with the RR profile in the HL7 eCR FHIR IG in Sec. 170.205(t)(1). We welcome comments on these proposals. viii. Sec. 170.315(f)(28)--Birth Reporting--Receive, Validate, Parse, and Filter As discussed earlier in the section regarding proposed revisions to Sec. 170.315(f)(8), the process of birth reporting has traditionally relied on a provider manually entering data into a web portal, which is used by the jurisdiction's office of vital statistics to produce a birth certificate and report selected data items to CDC's National Center for Health Statistics. Birth reporting helps inform public health programs on important health indicators, including birth rates and infant mortality rates, is used for research, and is used to produce the birth certificates needed for proof of identification, accessing benefits, and other administrative purposes. Our proposal for Sec. 170.315(f)(8) would provide an electronic birth reporting option--that could greatly reduce manual effort if adopted--using the new proposed standard in Sec. 170.205(v). In order to create alignment between sending and receiving systems, we propose a technical capability for health IT for public health to demonstrate the receipt, validation, parsing, and filtering of incoming birth reports according to the standard referenced in Sec. 170.205(v). Adopting a certification criterion to demonstrate receiving birth reports, and that such technology can do so according to the specified standard, could reduce implementation and maintenance burden and lead to greater consistency and completeness in the reported information. While most states have adopted an electronic birth registry system (EBRS), these systems today are primarily portal-based, requiring birth information to be entered manually into electronic forms.\151\ As described earlier in this proposal, current workflows involve dual- entry based processes. Despite investments made by CDC towards standards-based exchange with EBRS, there remains a gap in jurisdictional office of vital statistics' ability to receive and integrate data within applicable health IT for public health, particularly for data received using FHIR-based standards. --------------------------------------------------------------------------- \151\ National Research Council (US) Committee on National Statistics. Vital Statistics: Summary of a Workshop. Washington (DC): National Academies Press (US); 2009. B, The U.S. Vital Statistics System: A National Perspective. Available from: https://www.ncbi.nlm.nih.gov/books/NBK219884/. --------------------------------------------------------------------------- In consultation with CDC and its programmatic experience, we understand that there has been low implementation of the CDA-based IG as documented by CDC programs, and significant progress has been made on [[Page 63557]] testing and piloting of the FHIR IG for birth reporting. As a result, we propose to adopt the FHIR-based approach (as referenced in the proposed Sec. 170.205(v)) for receipt of birth reporting. Adoption of the FHIR-based approach would align the health IT used by public health receiving birth reports with those sending birth reports. Inclusion of the ability to receive and validate FHIR-specific birth reporting within applicable health IT for public health will also provide a baseline set of capabilities that vendors of health IT for public health can build on as additional FHIR-based approaches emerge for public health, including bulk import of data and FHIR Questionnaires. The receipt of FHIR formatted birth records also supports investments being made by CDC to receive FHIR messages downstream through the Data Modernization Initiative.\152\ --------------------------------------------------------------------------- \152\ https://www.cdc.gov/surveillance/data-modernization/technologies/cdc-front-door.html. --------------------------------------------------------------------------- However, as discussed in section III.B.13.e.i, due to the minimal adoption of the FHIR IG, we propose and seek comment on if we should adopt an interim standards-agnostic functional criterion for electronically transmitting selected medical and health information from birth certificate reports to PHAs based on the data elements outlined in CDC's National Vital Statistics System's ``Guide to Completing the Facility Worksheets for the Certificate of a Live Birth and Report of Fetal Death.'' \153\ We seek comment from those who have implemented and used the FHIR IG on its readiness for nationwide adoption. We further seek comment on--if we were to adopt a functional criterion--whether such a criterion should be time-limited to transition to a standards-based criterion as of a specific timeline, for example at 24 months after the timeline for implementation of any such functional criterion. --------------------------------------------------------------------------- \153\ https://www.cdc.gov/nchs/nvss/facility-worksheets-guide.htm. --------------------------------------------------------------------------- We propose that consistent with the standard(s) and implementation specification(s) specified in Sec. 170.205(v), Health IT Modules certified to Sec. 170.315(f)(28) enable a user to receive, validate, parse, and filter birth reporting information in accordance with the proposed Sec. 170.315(f)(28)(i) through (iii). We propose requirements in Sec. 170.315(f)(28)(i) to receive electronic birth reports transmitted via an application programming interface in accordance with the standard specified in Sec. 170.215(a)(1) or at least one of the versions of the standard specified in Sec. 170.215(d). Optionally, to meet the receive requirements a developer (serving as a Participant or Subparticipant of a QHIN, or who is a QHIN) may demonstrate receipt through a connection governed by the Trusted Exchange Framework and Common Agreement; receipt through a method that conforms to the standard specified in Sec. 170.202(d), from a service that has implemented the standard specified in Sec. 170.202(a)(2); or, receipt through a method that conforms to the standard in Sec. 170.205(p) when the technology is also using an SMTP- based edge protocol. We propose requirements in Sec. 170.315(f)(28)(ii) to demonstrate the ability to detect valid and invalid electronic birth reports received and formatted in accordance with the standards specified in Sec. 170.205(v). To meet the validate requirements, Health IT Modules certified to the criterion must include the capability to identify valid electronic birth reports received and process the data elements required for the standards specified in Sec. 170.205(v). Processing must include any necessary data mapping to enable use as discrete data elements, aggregation with other data, and parsing and filtering in accordance with parse and filter requirements proposed in Sec. 170.315(f)(28)(iii). Health IT Modules certified to the criterion must also include the capability to correctly interpret empty sections and null combinations; detect errors in electronic birth reports received including invalid vocabulary standards and codes not specified in the standards specified in Sec. 170.205(v); and record errors encountered allowing a user to be notified of the errors produced, to review the errors produced, and to store or maintain error records for audit or other follow up action. We propose requirements in Sec. 170.315(f)(28)(iii) to enable Health IT Modules certified to the criterion to parse and filter electronic birth reports received and validated in accordance with validate requirements in the proposed Sec. 170.315(f)(28)(ii). We welcome comment on these proposals. ix. Sec. 170.315(f)(29)--Prescription Drug Monitoring Program (PDMP) Data--Receive, Validate, Parse, Filter Prescription Data, Support Query and Exchange We propose to introduce a functional certification criterion focused on the ability of health IT for public health to receive and validate reported PDMP information, to respond to queries from providers or other PDMP databases and hubs, and to initiate queries to those other PDMP databases and hubs. As mentioned in the earlier discussion regarding a new proposed certification criterion in Sec. 170.315(f)(9), a provider's ability to query information from a PDMP ``can help identify patients who may be at risk for overdose.'' \154\ PDMP data can also ``be helpful when patient medication history is unavailable and when care transitions to a new clinician.'' \155\ To complement our proposal to support certification of health IT used by providers to be capable of requesting data from PDMP databases, we also believe it is important to certify the capability of health IT for public health, in this case PDMPs, to respond to queries submitted. While it is expected that most PDMPs support this requirement today, inclusion of the functionality in the Program will support PDMPs capabilities in alignment with requirements for health IT systems to request and validate PDMP information. Our proposal will also require that functionality is based on open, consensus-based practices where possible, allowing PDMPs to have the ability to exchange information without undue burden. Additionally, PDMPs should have the capability to support interstate data sharing (or queries) to better inform prescribing practices, improve patient care and safety, monitor patient behaviors that contribute to the opioid epidemic, and facilitate a nimble and targeted response. --------------------------------------------------------------------------- \154\ https://www.cdc.gov/opioids/healthcare-professionals/pdmps.html. \155\ Id. --------------------------------------------------------------------------- Concerns have been raised within the health IT industry regarding the lack of interoperability between different systems and data hubs involved in interstate queries, and these concerns have hindered policy objectives described in several statutes to address the opioid crisis. A lack of consistent interoperability requirements between PDMPs, systems, and data hubs involved in interstate exchange makes such queries burdensome on both the querying and responding systems. Inclusion of a functional certification criterion in the Program in Sec. 170.315(f)(29) would help states conform to functionalities specified in section 1944(b) of the Social Security Act, as added by section 5042(a) of the SUPPORT Act,\156\ to support interjurisdictional query and response, and to receive and validate data into health IT. Further, this approach is [[Page 63558]] aligned with CMS requirements on funding state systems in 42 CFR 433.112(b)(10), which specify the conditions that a system must meet, including the ``Use [of] a modular, flexible approach to systems development, including the use of open interfaces and exposed application programming interfaces . . .'' --------------------------------------------------------------------------- \156\ Section 1944(b) of the Social Security Act [42 U.S.C. 1396w-3a] as added by section 5042(a) of the Substance Use Disorder Prevention that Promotes Opioid Recovery and Treatment for Patients and Communities Act (SUPPORT Act) of 2018 (Pub. L. 115-271). --------------------------------------------------------------------------- We also propose that Health IT Modules certified to this criterion be able to receive and validate data reported in a manner consistent with the PDMP technology transmitting, reporting, or querying that data. As expressed elsewhere within this proposal, while PDMP technology currently is capable of receiving and validating data, we believe it is necessary to include functionality for PDMP technology to support the receipt of information in accordance with section 1944(b) of the Social Security Act, as added by section 5042(a) of the SUPPORT Act,\157\ and that PDMP technology can accept data according to the same functionality required for transmission under Sec. 170.315(f)(9). --------------------------------------------------------------------------- \157\ Ibid. --------------------------------------------------------------------------- As stated in section III.B.13.e.ii, we believe that further work in the health IT industry is necessary to align current consensus-based standards, specifically FHIR. We also believe that previously described projects to map current standards to FHIR will greatly benefit functionality proposed here, specifically regarding the exchange of information between PDMPs. While HL7 FHIR-based standards are developing and maturing, we propose a set of functional criteria for receiving and validating reported data and initiating and responding to queries from applicable health IT, including other state PDMPs, to support applicable health IT capabilities that may be utilized to meet requirements under section 1944(b) of the Social Security Act, as added by section 5042(a) of the SUPPORT Act. As described above in section III.B.13.e.ii, section 1944(b) of the Social Security Act, as added by section 5042(a) of the SUPPORT Act, describes a Qualified PDMP, with respect to a State, as a program which, at a minimum, satisfies the following two criteria. First, the program facilitates access by a covered provider to, at a minimum, the following information with respect to a covered individual, in as close to real-time as possible: information regarding the prescription drug history of a covered individual with respect to controlled substances; the number and type of controlled substances prescribed to and filled for the covered individual during at least the most recent 12-month period; and the name, location, and contact information (or other identifying number selected by the State, such as a national provider identifier issued by the National Plan and Provider Enumeration System of the Centers for Medicare & Medicaid Services) of each covered provider who prescribed a controlled substance to the covered individual during at least the most recent 12-month period. Second, the program facilitates the integration of information described in the first criteria above into the workflow of a covered provider, which may include the electronic system the covered provider uses to prescribe controlled substances. Section 1944(f) of the Social Security Act, as added by section 5042(a) of the SUPPORT Act, includes an increase to Federal Medical Assistance Percentage (FMAP) and Federal Matching Rates for Certain Expenditures Relating to Qualified Prescription Drug Monitoring Programs under Section 1903(a).\158\ The requirements proposed in Sec. 170.315(f)(29) are, therefore, written to be consistent with the Section 1903(a) funding requirements in 42 CFR 433.112. Specifically, Sec. Sec. 433.112(b)(10) and (12) include requirements for the use of open interfaces and exposed application programming interfaces, and alignment with, and incorporation of, standards and implementation specifications for health information technology adopted by the Office of the National Coordinator for Health IT in 45 CFR part 170, subpart

B. Section 433.112(b)(16) also requires interoperability with health

information exchanges, public health agencies, human services programs, and community organizations providing outreach and enrollment assistance services as applicable. --------------------------------------------------------------------------- \158\ Section 1944(f) of the Social Security Act [42 U.S.C. 1396w-3a] as added by section 5042(a) of the Substance Use Disorder Prevention that Promotes Opioid Recovery and Treatment for Patients and Communities Act (SUPPORT Act) of 2018 (Pub. L. 115-271). --------------------------------------------------------------------------- We propose requirements in Sec. 170.315(f)(29) to enable technology to receive, validate, parse, and filter electronic prescription information for controlled substance medications and support query and exchange of PDMP data as described below. We propose requirements in Sec. 170.315(f)(29)(i) to receive electronic controlled substance medication prescription information transmitted through a method that conforms to the standard in Sec. 170.202(d), from a service that has implemented the standard specified in Sec. 170.202(a)(2); through a method that conforms to the standard in Sec. 170.205(p)(1) when the technology is also using an SMTP-based edge protocol; and, via an application programming interface in accordance with the standard specified in Sec. 170.215(a)(1) or at least of the versions of the standard specified in Sec. 170.215(d). Optionally, to meet the receive requirements, a developer may demonstrate receipt through a connection governed by the Trusted Exchange Framework and Common Agreement. We propose requirements in Sec. 170.315(f)(29)(ii) to demonstrate the ability to detect valid and invalid electronic controlled substance medication prescription information received. To meet the validate requirements, the Health IT Module certified to this criterion must include the capability to identify valid electronic controlled substance medication prescription information received and process the data elements including any necessary data mapping or translation between standards. The Health IT Module certified to this criterion must also include the capability to correctly interpret empty sections and null combinations; detect errors in electronic controlled substance medication prescription information received, including invalid vocabulary standards and codes; and record errors encountered allowing a user to be notified of the errors produced, to review the errors produced, and to store or maintain error records for audit or other follow up action. We propose requirements in Sec. 170.315(f)(29)(iii) to enable a user to parse and filter electronic controlled substance medication prescription information received and validated in accordance with requirements in the proposed Sec. 170.315(f)(29)(ii). We propose requirements in Sec. 170.315(f)(29)(iv) to enable patient-level query and exchange. The proposed requirement is to enable patient-level queries from external systems of electronic controlled substance medication prescription information of the PDMP including an interstate exchange query. This proposed requirement includes exchange--response requirements to respond to incoming patient-level queries from external systems and exchange--patient access requirements to enable patient access to view electronic controlled substance medication prescription information. We welcome public comment on this proposed new certification criterion. [[Page 63559]] f. New Standardized API for Public Health Data Exchange i. Background Despite advances made over the last decade in public health data exchange and health IT interoperability, challenges and gaps remain in exchange capabilities and technical infrastructure. Current efforts have been hampered by a history of bespoke solutions and a multitude of projects, contracts, and implementations that struggled to scale or sustain adequate funding, limiting adoption of resulting standards or implementation guides. This limited adoption of standards and mechanisms for electronic public health data exchange, among other challenges, has resulted in poor interoperability that often relies on manual effort, such as phone calls, faxes, and data entry. The COVID-19 pandemic stressed our public health system and surfaced flaws in the data that public health officials obtain from health care providers--both in the data itself, but also the ways in which data are reported. As a result, public health officials' access to critical health data during public health emergencies or disasters lags, and their experience varies with respect to the use of technology to glean insights to inform decisions on quarantines, hospital capacity, public health education campaigns, distribution of critical medical supplies, school closures, reopening after a pandemic, and many other essential public health decisions. Without modern standards and consistent requirements to adopt standards-based IT systems, public health data exchange often relies on custom, siloed solutions, and manual workarounds. Currently, most public health data exchange relies on older versions of HL7 v2 or CDA standards. HL7 v2 and CDA standards support simple, single-patient, event-based submission of documents from healthcare to PHAs, but these standards do not adequately support more complex data exchange use cases, such as bulk exchange of patients who received a specific vaccine. However, now that the majority of hospitals and office-based clinicians nationwide have adopted FHIR-based APIs with Health IT Modules certified to Sec. 170.315(g)(10) for patient and population level services, the technical landscape has evolved, and today's health IT infrastructure presents the public health ecosystem with vastly improved options to engage in more granular data exchange. The shift to HL7 FHIR is needed to support a wide-scale public health response, and we believe broad adoption of HL7 FHIR would reduce burden of implementation and maintenance for data exchange between and among healthcare organizations, providers, and PHAs. The following describes our proposal to adopt a new certification criterion in Sec. 170.315(g)(20) that would establish requirements for a standardized HL7 FHIR-based API for public health data exchange and extend the capabilities included in the standardized API for patient and population services in Sec. 170.315(g)(10). This new certification criterion would support ongoing and future development of public health FHIR IGs leveraging a core set of existing, modular, and extensible capabilities and standards. Standards referenced in the proposed Sec. 170.315(g)(20) support FHIR capabilities such as API-based event notifications (i.e., HL7 FHIR Subscriptions), SMART App Launch, and Bulk Data Export. Our proposals in Sec. 170.315(g)(20) would also include constrained, specific requirements for health IT for public health such as compliance with the United States Public Health Profiles Library Implementation Guide (USPHPL IG), referenced in the proposed Sec. 170.215(b)(2). We propose this approach for several reasons. First, we believe that establishing a standardized API for public health data exchange is a necessary first step towards furthering a FHIR-based ecosystem that would support a wide array of public health data exchange use cases, including those established in the Program currently, those being proposed as new certification criteria in the Program, and for future use cases. Importantly, we believe that a FHIR-based ecosystem will better streamline and reduce reporting burden for healthcare organizations and developers, while expanding PHA's access to critical data for action, such as identification of at-risk or infected individuals during an outbreak. Second, we believe that a standard API for public health data exchange--with a consistent set of standards-based functionalities and capabilities for Health IT Modules certified to the Sec. 170.315(g)(20) certification criterion--would support innovation and longer-term public health modernization and would establish baseline capabilities for public health use cases. The consistent functionalities established in the combination of Sec. 170.315(g)(10) and Sec. 170.315(g)(20) would support the creation or revision of health IT for public health IGs necessary to advance interoperability for specific use cases, such as cancer pathology reporting, which has a draft FHIR IG, or immunization reporting, which is currently only supported by a HL7 v2-based IG. Using HL7 FHIR-based APIs, PHAs and healthcare partners could create an ecosystem where health IT for public health can securely query data directly from the source, in real time, when needed, based on an initial push of relevant data. Helios tested this approach and participants were able to successfully query EHRs for additional patient-level information after an initial trigger, and we are working with CDC to pilot and scale this approach.\159\ --------------------------------------------------------------------------- \159\ https://confluence.hl7.org/display/FHIR/2024+-+01+Helios+Query+and+Response+Track. --------------------------------------------------------------------------- Third, we believe that the proposed certification criterion in Sec. 170.315(g)(20) would serve as a glidepath towards an eventual transition to broader HL7 FHIR-based reporting for public health data exchange. We propose that Health IT Modules certified to Sec. 170.315(g)(20) would support modular and foundational capabilities and standards, such server support for subscriptions in Sec. 170.315(j)(23), and support a public health specific set of HL7 FHIR profiles that extend the requirements in Sec. 170.315(g)(10) to support a public health transition to HL7 FHIR. Finally, we believe this approach will minimize development burden by relying heavily on the standards and capabilities already required of Health IT Modules certified to Sec. 170.315(g)(10), while supporting near-term development and authoring of public health use case-specific HL7 FHIR IGs, where necessary, to transmit relevant data to PHAs. We emphasize for clarity that just because we propose to adopt a public health-focused API certification criterion in Sec. 170.315(g)(20), developers of certified health IT are not required to build one API per criterion (if they are also certified to Sec. 170.315(g)(10) for example). Developers of certified health IT would have flexibility to certify and deploy APIs scoped however they want, if and as they certify Health IT Modules to multiple API-based certification criteria, including those proposed to be included as part of the Base EHR definition in Sec. 170.102, including certification criteria in Sec. 170.315(g)(10), (g)(20), (g)(30) and (g)(34). We believe that this rulemaking is necessary to set the stage for our long-term strategy to advance public health data modernization in partnership with CDC. We anticipate that requirements to support a standard API for public health exchange would lead to increased capacity for data exchange and spur additional pilots. As use case- specific HL7 FHIR IGs are authored for specific [[Page 63560]] data exchange needs and are refined through successful pilots and approved for widespread adoption by relevant standards development organizations, we intend to consider referencing these HL7 FHIR IGs in future rulemaking. We will continue to work with partners, such as Helios--the public health FHIR accelerator made up of ONC, CDC, PHAs, health IT vendors, and HL7--to support PHAs in more easily receiving and accessing data to further their numerous objectives and missions. ii. Adoption of Generalizable and Public Health-Specific Standards and Functionality in the Standardized API for Public Health Data Exchange We propose to adopt some of the functional and standards-based requirements from our existing requirements in Sec. 170.315(g)(10) as part of the certification criterion proposed in Sec. 170.315(g)(20). For example, in Sec. 170.315(g)(10), section III.B.19, we propose to rely on modular functionalities proposed and described in proposed Sec. 170.315(j) to support both functional and dynamic registration, authentication and authorization for system access, and we propose to rely on HL7 FHIR-based IGs familiar to developers of certified health IT with Health IT Modules certified to Sec. 170.315(g)(10), such as the SMART App Launch IG in Sec. 170.215(c), and the FHIR Bulk Data Access IG in Sec. 170.215(d). We also propose that Health IT Modules certified to Sec. 170.315(g)(20) support new subscriptions capabilities proposed in Sec. 170.315(j)(23), and we propose that Health IT Modules certified to Sec. 170.315(g)(20) support HL7 FHIR Resources as profiled by the USPHPL IG proposed in Sec. 170.215(b)(2). Specifically, we propose that Health IT Modules certified to Sec. 170.315(g)(20) support functional registration, according to the requirements proposed in Sec. 170.315(j)(1) as well as dynamic registration according to the requirements proposed in Sec. 170.315(j)(2) in Sec. 170.315(g)(20)(i). The capability to support functional registration in Sec. 170.315(g)(20)(i)(A) is the same as those currently in Sec. 170.315(g)(10)(iii) for functional registration, which are required for Health IT Modules certified to Sec. 170.315(g)(10). We additionally propose in Sec. 170.315(g)(20)(i)(B) to require support for dynamic registration according to the certification criterion proposed in Sec. 170.315(j)(2). Dynamic registration of apps is intended to reduce the burden of application registration through automated processes. Please see the section titled ``New Requirements to Support Dynamic Client Registration Protocol in the Program'' for more details about our dynamic registration proposal (see section III.B.15). We also propose that Health IT Modules certified to Sec. 170.315(g)(20) support authentication and authorization capabilities to support public health data access to provider systems. We propose to require such capabilities in Sec. 170.315(g)(20)(ii). Specifically, we propose in Sec. 170.315(g)(20)(ii)(A) to require support for SMART Backend Services system authentication and authorization according to the proposed certification criterion in Sec. 170.315(j)(7) for system applications functionally registered according to the capabilities in Sec. 170.315(g)(20)(i)(A). These capabilities are the same as those currently in Sec. 170.315(g)(10)(v) and (vii) which are required for Health IT Modules certified to Sec. 170.315(g)(10). Furthermore, we propose in Sec. 170.315(g)(20)(ii)(B) to require support for asymmetric certificate-based system authentication and authorization according to the requirements proposed in Sec. 170.315(j)(8) for system apps dynamically registered using the capabilities in Sec. 170.315(g)(20)(i)(B). These requirements would support authentication and authorization for dynamically registered system apps. The proposed requirements to support system authentication and authorization for functionally and dynamically registered system apps will ensure that Health IT Modules certified to Sec. 170.315(g)(20) criterion support authorization server capabilities to enable public health authorization to provider servers. In Sec. 170.315(g)(20)(iii), we propose a set of requirements necessary to facilitate PHA access to provider system data. These include identification of specific HL7 FHIR Resources often needed by PHAs, capabilities to read and search these data, and support for the subscription of event-based topics that PHAs can leverage in the development of IGs for various public health reporting use cases. We propose that Health IT Modules certified to Sec. 170.315(g)(20) support read and search capabilities for each HL7 FHIR Resource identified in Sec. 170.315(g)(20)(iii)(A) according to the standards and implementation specifications adopted in Sec. 170.215(b)(2). This would enable an API User to read and search patient data that are profiled according to the USPHPL IG in Sec. 170.215(b)(2), including the following HL7 FHIR Resources: Condition; Encounter; Location; Observation; Organization; Patient; and PractionerRole, identified in Sec. 170.315(g)(20)(iii)(A)(1)-(7). In referencing the USPHPL IG in Sec. 170.215(b)(2), our intention is to leverage a public health-specific data set of common data elements necessary to support core public health exchange use cases. The USPHPL IG contains reusable content profiles that represent common data PHAs and public health officials receive and use. It was created as a complement to the US Core IG--the USPHPL IG re-uses US Core profiles whenever possible, and only adds new profiles when there is a need for specific profiles for public health data exchange, and no corresponding profile in US Core IG. We believe the USPHPL IG would enable the exchange of health data from healthcare organizations to PHAs with minimal implementation burden, due to its foundation in the US Core IG, and through the reuse of common profiles for public health data exchange purposes. We welcome comment on these proposed information access requirements described in 170.315(g)(20)(iii)(A). In Sec. 170.315(g)(20)(iii)(B) we propose that Health IT Modules support read and search API calls and bulk FHIR API calls. Specifically, in Sec. 170.315(g)(20)(iii)(B)(1)(i) we propose that Health IT Modules support the ability for a system client to read HL7 FHIR Resources using the ``id'' data element for the data elements identified in Sec. 170.315(g)(20)(iii)(A), and return the Resources profiled according to the USPHPL IG in Sec. 170.215(b)(2). Similarly, we propose that Health IT Modules support the ability for a system client to search HL7 FHIR Resources according to the applicable search requirements in the ``US Core Server CapabilityStatement'' for the Resources included in Sec. 170.315(g)(20)(iii)(A) and return the information profiled according to the implementation specification in Sec. 170.215(b)(2). Together, these requirements would enable public health systems to extract data from provider systems, consistent with scopes and interactions identified in the SMART App Launch IGs in Sec. 170.215(c). Once those data are read by the API call, the receiving system is then able to parse, process, and update receiving systems. Through this standards-based approach, Health IT Modules certified to Sec. 170.315(g)(20) would enable consistent and predictable access to health data from which apps, systems, and other public health services can be informed and developed. Additionally, in Sec. 170.315(g)(20)(ii)(2), we propose that the Health IT Module certified to [[Page 63561]] Sec. 170.315(g)(20) must support Bulk FHIR queries by responding to requests for data according to the implementation specifications adopted in Sec. 170.215(a) and at least one of the versions of the implementation specifications adopted in Sec. 170.215(d) for the Resources listed in Sec. 170.315(g)(20)(iii)(A) and return the information profiled according to the USPHL IG proposed in Sec. 170.215(b)(2). We also propose in Sec. 170.315(g)(20)(ii)(2) that for the time period up to and including December 31, 2027, the Health IT Module must support either the ``GroupLevelExport'' operation or the ``_type'' query parameter of at least one of the versions of the implementation specifications adopted in Sec. 170.215(d), or a Health IT Module may support both the ``GroupLevelExport'' operation and the ``_type'' query parameter of at least one of the versions of the implementation specifications adopted in Sec. 170.215(d). On and after January 1, 2028, a Health IT Module certified to Sec. 170.315(g)(20) must meet both the ``GroupLevelExport'' operation and the ``_type'' query parameter for each of the data included in Sec. 170.315(g)(20)(iii)(A) according to at least one of the versions of the implementation specifications adopted in Sec. 170.215(d). We welcome comment on our proposals for public health information access and our proposals to require support of HL7 FHIR Profiles as specified in the USPHPL IG as the foundation for Health IT Modules certified to Sec. 170.315(g)(20). We recognize that the USPHPL IG does not support all data elements referenced in implementation specifications that support public health use cases represented by the current certification criteria in Sec. 170.315(f). Nor does the USPHPL IG include all data elements necessary for proposed public health reporting in Sec. 170.315(f). We understand this gap, and we intend to support updates to the USPHPL IG through current HL7 activities and processes, future edits, additions, and updates to the HL7 FHIR profiles contained within the USPHPL IG. For example, we anticipate that future versions of the USPHPL IG could include additional use case-specific data elements that are identified in USCDI+ Public Health. iii. Incorporation and References to Criteria in Sec. 170.315(j) as Part of the Standardized API for Public Health Data Exchange As stated previously, we propose that Health IT Modules certified to Sec. 170.315(g)(20) include modular capabilities and foundational standards to support a transition to HL7 FHIR-based public health data exchange. As described in section III.B.16 of this proposed rule, we describe a new category of ``modular API capabilities'' certification criteria in Sec. 170.315(j). Specifically, in Sec. 170.315(g)(20)(iii)(C) we propose that a Health IT Module certified to Sec. 170.315(g)(20) support subscriptions according to the requirements in Sec. 170.315(j)(23), including support for a client to subscribe to notifications and then send notifications for event-based interactions. In addition to the support for the framework, subscription topics, and filters in Sec. 170.315(j)(23), we propose in Sec. 170.315(g)(20)(iii)(C)(1) that a Health IT Module certified to Sec. 170.315(g)(20) enable a client to subscribe to notifications filtered according to the conditions ``Encounter.reasonCode,'' and ``Encounter.subject'' when a patient encounter starts and the conditions ``Encounter.reasonCode,'' and ``Encounter.subject'' when a patient encounter ends. When an encounter starts or ends, we propose that Health IT Modules certified to Sec. 170.315(g)(20) can send notifications for the event-based interactions identified in Sec. 170.315(g)(20)(iii)(C)(1)(i) and (ii) according to the standard in Sec. 170.215(a) and implementation specification in Sec. 170.215(h)(1). Taken together, we believe that these capabilities would ensure that PHAs will have consistent access of discrete functionalities, defined capabilities, and standardized data from providers using certified health IT systems for a range of public health use cases. We welcome comment on these proposals. We also invite comment on whether there is utility in requiring future support of other emerging HL7 FHIR standards, such as CDS Hooks proposed as ``workflow triggers for decision support interventions-- services'' in Sec. 170.315(j)(23) as part of the certification criterion in Sec. 170.315(g)(20), to support public health data exchange use cases. 14. Bulk Data Enhancements a. Background In the ONC Cures Act Final Rule, we adopted the HL7[supreg] FHIR[supreg] Bulk Data Access (Flat FHIR) (v1.0.0: STU 1) implementation specification (referred to as the Bulk v1 IG), including mandatory support for the ``group-export'' ``OperationDefinition,'' in Sec. 170.215(a)(4) to enable consistent implementation of API-enabled ``read'' services for multiple patients (85 FR 25742). In the HTI-1 Final Rule we moved this Bulk v1 IG standard to Sec. 170.215(d)(1) (89 FR 1283). The Bulk v1 IG builds off the FHIR Asynchronous Pattern to define a standardized process for authenticated and authorized clients to ``request a Bulk Data Export from a server, receive status information regarding progress in the generation of the requested files, and retrieve these files.'' \160\ The widespread adoption of Bulk Data APIs enables automated communication between health systems to support use cases like public health surveillance and reporting, clinical research, data analytics, electronic clinical quality measure reporting and more. --------------------------------------------------------------------------- \160\ https://hl7.org/fhir/uv/bulkdata/export.html#bulk-data-export-operation-request-flow. --------------------------------------------------------------------------- Support for the ``group-export'' ``OperationDefinition'' operation enables ``application developers interacting with Sec. 170.315(g)(10)- certified Health IT Modules to export the complete set of FHIR resources . . . for a pre-defined cohort of patients'' (85 FR 25742). As we have stated previously, these cohorts are ``defined at the discretion of the user . . . including, for example, a group of patients that meet certain disease criteria or fall under a certain insurance plan'' (85 FR 25742, 25743). We have also noted previously that the Bulk v1 IG ``has optional parameters which can be used to filter results to a period of time, or one or several specified FHIR resources'' (85 FR 25744). b. Proposal We propose to adopt the HL7 FHIR Bulk Data Access (v2.0.0: STU 2) implementation specification (Bulk v2 IG) in Sec. 170.215(d)(2) and incorporate it by reference as a subparagraph in Sec. 170.299. Additionally, we propose that the adoption of the Bulk v1 IG in Sec. 170.215(d)(1) would expire on January 1, 2028. We clarify that both the Bulk v1 IG and Bulk v2 IG would be available for purposes of certification where certification criteria reference the implementation specification in Sec. 170.215(d) until the Bulk v1 IG adoption expiration date of January 1, 2028, after which time only the Bulk v2 IG would be available for certification, if we finalize our rule as proposed. We believe that raising the floor for certification of bulk data export capabilities would help enable performant and consistent population service APIs. The Bulk v2 IG includes additional clarifications and expanded definitions based on industry feedback related to implementation of the Bulk v1 IG and HL7 workgroup consensus. We [[Page 63562]] believe adopting the Bulk v2 IG would not add significant burden for Certified API Developers with Health IT Modules certified to certification criteria that reference the implementation specification in Sec. 170.215(d) who have already implemented the Bulk v1 IG. The new requirements included in the Bulk v2 IG are generally incremental updates to Bulk v1 IG requirements, and only a handful of the updates are in scope for testing and certification.\161\ --------------------------------------------------------------------------- \161\ We already include testing support for the Bulk v2 IG, since it was included as a 2022 Approved Standard via the Standards Version Advancement Process (SVAP), and in the Inferno testing tool we only needed three new tests for testing the Bulk v2 IG in comparison to the Bulk v1 IG. --------------------------------------------------------------------------- One of the pertinent new requirements in the Bulk v2 IG is required server support for the ``_since'' parameter, which allows for filtering by date and time on bulk exports. This parameter can be used to help improve API performance by reducing total resources exported and overall export time. This parameter is also defined in the Bulk v1 IG, but it is marked as ``optional'' for server support there. The Bulk v2 IG contains added clarifications and expanded definitions for the ``_since'' parameter, and the parameter is marked as ``required'' for server (i.e., Health IT Module) support in the Bulk v2 IG. The added requirement for the ``_since'' parameter, along with all the other clarifications and expanded definitions across the whole Bulk v2 IG, are aspects that we believe will help provide consistent implementation guidance and thus improve access, exchange, and use of EHI because developers will have more guidance to refer to when implementing their Bulk Data APIs. We welcome comment on our proposal to adopt the HL7 FHIR Bulk Data Access (v2.0.0: STU 2) implementation specification. Our proposal to adopt the Bulk v2 IG in Sec. 170.215(d)(2) implicates all certification criteria that reference the implementation specification in Sec. 170.215(d), and in this proposed rule these certification criteria are: Sec. 170.315(f)(23), (f)(25), (g)(10), (g)(20), (g)(31), (g)(32), and (g)(33). Note that Sec. 170.315(f)(23), (f)(25), (g)(20), (g)(31), (g)(32), and (g)(33) are new Program certification criteria proposed in this rule, and the only currently finalized certification criterion in the Program that includes reference to Sec. 170.215(d) is Sec. 170.315(g)(10). We propose to continue requiring mandatory support for the ``group- export'' ``OperationDefinition'' defined in the Bulk v2 IG for certification to Sec. 170.315(g)(10); and we propose to require support for the ``group-export'' ``OperationDefinition'' in our proposed new certification criteria in Sec. 170.315(g)(20), (31), (32), and (33). We refer readers to sections III.B.13.f and III.B.20.c for additional discussion on our proposed new certification criteria in Sec. 170.315(g)(20), (31), (32), and (33) and proposed Bulk IG requirements. We additionally propose to require support for the Bulk v2 IG ``optional'' query parameter known as ``_type'' for testing and certification to Sec. 170.315(g)(10), (20), (31), (32), and (33) because we believe that implementation of the ``_type'' parameter will meaningfully improve API performance by reducing total resources exported and overall export time. The ``_type'' filter allows a requesting system to provide a list of FHIR resource types for the responding system to use, which limits the resources returned to a specific subset. Like the ``_since'' parameter, we believe that this requirement to use ``_type'' parameter is an incremental step that will encourage further industry adoption. As of Spring 2023, 73.7% of deployed Bulk FHIR certified Health IT Modules already support this optional parameter.\162\ We welcome comment on our proposal to require support for the ``_type'' parameter for certification. --------------------------------------------------------------------------- \162\ Market share numbers come from this briefing: https://www.hhs.gov/sites/default/files/2022-02-17-1300-emr-in-healthcare-tlpwhite.pdf. Support for this parameter was gathered by reviewing developer documentation. --------------------------------------------------------------------------- Finally, we welcome comment on the issues hindering the effective exchange of population data using Bulk FHIR APIs and additional steps ONC can take to help address those issues. Our research and findings to date, on the use of deployed ONC-certified Bulk FHIR APIs, indicate that there are significant challenges and barriers hindering interoperability. We have consistently heard about challenges creating the groups necessary for invoking the ``group-export'' operation, including that there is not a standard process for creating groups and that group sizes are being limited. We have also heard about significant performance issues, with Bulk FHIR exports in some cases taking days or even weeks to complete.\163\ --------------------------------------------------------------------------- \163\ Jones, James R., et al. ``Real World Performance of the 21st Century Cures Act Population Level Application Programming Interface.'' medRxiv (2023): 2023-10. https://www.medrxiv.org/content/10.1101/2023.10.05.23296560v2. --------------------------------------------------------------------------- For currently certified Bulk FHIR APIs, we expect that Sec. 170.315(g)(10) certified Health IT Modules support complete patient cohorts (i.e., groups) that enable automated communication between health systems without needing to parse data across multiple exports. For future rulemaking, we are interested in considering testable minimum expectations and/or thresholds for certified Bulk FHIR API performance. We acknowledge that there is variability in Bulk FHIR group exports and performance based on things like system architectures and the variability of resources per patient in a patient cohort. We seek input on Bulk FHIR API performance experiences from users in the field and seek comment on any potential performance bases, expectations, thresholds, industry standards, etc. that we could consider in the future for Certified Bulk FHIR APIs as a baseline. We also welcome comment on the latest developments in the Bulk FHIR space, like the early-stage proposals for Bulk FHIR import functionality that are intended to address data ``push'' use cases as opposed to the data ``pull'' flow modeled by Bulk FHIR export.\164\ --------------------------------------------------------------------------- \164\ FHIR Bulk Data Import early stage proposals can be found here: https://github.com/smart-on-fhir/bulk-import/blob/master/import.md. --------------------------------------------------------------------------- We welcome comment on experiences using Bulk FHIR APIs deployed in Health IT Modules certified to Sec. 170.315(g)(10)(i)(B) and (ii)(B) (note that elsewhere in this proposed rule we are proposing to restructure Sec. 170.315(g)(10) and move the Bulk FHIR API requirements in Sec. 170.315(g)(10) to Sec. 170.315(g)(10)(iii)). We also welcome comment on performance experiences and minimum expectations for future iterations of our Bulk FHIR API requirements for different use cases, insofar as we should be thinking about performance differently for different use cases. 15. New Requirements To Support Dynamic Client Registration Protocol In the Program a. Background to Dynamic Client Registration In the ONC Cures Act Proposed Rule's preamble (84 FR 7483) we discussed that we considered proposing to require the OAuth 2.0 Dynamic Client Registration Protocol (DCRP) as per RFC 7591 \165\ as the mechanism for application registration in the proposed Sec. 170.315(g)(10)(iii). However, in the ONC Cures Act Final Rule (85 FR 25745), we noted that DCRP had low industry adoption at the time, and we subsequently finalized the application registration requirement in Sec. 170.315(g)(10)(iii) without the DCRP [[Page 63563]] standard. We also encouraged health IT developers to coalesce around the development of a common industry standard for application registration. --------------------------------------------------------------------------- \165\ See RFC 7591--OAuth 2.0 Dynamic Client Registration Protocol. Available at: https://datatracker.ietf.org/doc/html/rfc7591. --------------------------------------------------------------------------- In addition, we also finalized in the ONC Cures Act Final Rule the API Maintenance of Certification requirement of authenticity verification and registration for production use in Sec. 170.404(b)(1) (85 FR 25763 through 25764). This requirement permits a Certified API Developer to implement an objective and uniform process to verify the authenticity of API Users, where ``API Users'' is defined at 45 CFR 170.404(c) and complete this process within ten business days. We also finalized in Sec. 170.404(b)(1)(ii) that the Certified API Developer must register and enable all applications for production use within five business days of completing its verification of an API User's authenticity. In the years since finalization of requirements in Sec. 170.315(g)(10)(iii) and Sec. 170.404(b)(1) in the ONC Cures Act Final Rule, ONC has received feedback that the non-standard application registration process can be burdensome to API Users. The manual nature of some registration processes does not enable efficient registration across multiple certified Health IT Module deployments, and the absence of standardized requirements may cause varying, disparate registration processes across certified Health IT Modules, making widespread registration burdensome. To reduce the registration burden for API Users, we propose to adopt a standard for application registration in Sec. 170.215(o)(1) and adopt a new certification criterion in Sec. 170.315(j)(2) for dynamic registration as part of the suite of revised and new certification criteria proposed as modular API capabilities (See section III.B.16). Consistent with our proposed new approach to leverage modular API capabilities in Sec. 170.315(j) across various API-related certification criteria, we propose to revise the certification criterion in Sec. 170.315(g)(10) by referencing Sec. 170.315(j)(2) and requiring support for a dynamic registration pathway. We propose to revise the API Maintenance of Certification requirements in Sec. 170.404(b) to require support for publication of information necessary to dynamically register apps. Additionally, we propose to adopt the standard for dynamic application registration as part of the certification criteria in Sec. 170.315(g)(20), (30), (32)-(35). (Please see section III.B.13.d for details on the Sec. 170.315(g)(20) Standardized API for public health data exchange certification criterion proposal and section III.B.20.c for details on our Patient, Provider, and Payer APIs Sec. 170.315(g)(30), (32)-(35) proposals). b. Adoption of HL7 UDAP Security IG v1 The OAuth 2.0 framework enables a third-party application to obtain limited access to a Hypertext Transfer Protocol (HTTP) service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. Given that the Sec. 170.315(g)(10) certification criterion's authorization model is based on the OAuthAuthorization Framework, registration is required before an app can access information via an API conformant to the Sec. 170.315(g)(10) certification criterion. A Sec. 170.315(g)(10) certified Health IT Module's authorization server must support app registration, as required per the current requirements in Sec. 170.315(g)(10)(iii). To standardize the application registration approach in Program API criteria, we propose to adopt the HL7[supreg] Unified Data Access Profiles (UDAPTM) Security for Scalable Registration, Authentication, and Authorization Implementation Guide Release 1.0.0 (UDAP Security IG v1) in Sec. 170.215(o)(1). The UDAP Security IG v1 enables dynamic registration in alignment with the OAuth 2.0 security paradigm already in use in the Program. The SMART App Launch IG, which profiles the OAuthAuthorization Framework established in RFC 6749, is currently required in the Program in the Sec. 170.315(g)(10) certification criterion to enable secure authorization of apps to receive a single patient's data via FHIR. Additionally, the SMART Backend Services specification, also profiling OAuth 2.0, already required in the Program in the Sec. 170.315(g)(10) certification criterion for authorization to retrieve multiple patient's data. The UDAP Security IG v1 would augment the existing OAuth 2.0 found in the Program by enabling scalable and standardized application registration capabilities compatible with FHIR and the SMART App Launch IG to be referenced as requirements in Program API criteria. While the UDAP Security IG v1 defines additional capabilities beyond dynamic registration, Program API criteria requirements proposed in this rule focus on dynamic registration and subsequent authorization requests of dynamically registered apps. To achieve this focus, the Program API proposals referencing the UDAP Security IG v1 require only specific sections relevant to those capabilities. Scalable dynamic registration in the UDAP Security IG v1 relies upon ``trust communities.'' Trust communities enable scalable trust by establishing common policies that all participants agree to abide by, thereby forgoing the need for individual agreements between organizations for establishing trusted relationships. Participation in a trust community can be represented in a secure and trustworthy manner in the form of cryptographically secure digital certificates. These certificates enable an application to prove to a server that it and its developer are trusted to meet the expectations of the trust community. With the certificate as proof of the trustworthiness of an API User and their application, registration can proceed in an automated manner without the need to perform manual or non-standardized trust verification. We note that for the purposes of our proposals in Sec. 170.315(g)(10), (20), (30), (32)-(35), and Sec. 170.404(b)(1) an API User and the certified API technology that an API Information Source uses must be part of the same trust community for dynamic registration to occur according to the UDAP Security IG v1. Depending on the scenario, Certified API Developers as well as API Information Sources would be best positioned to determine which trust communities are supported for dynamic registration at a specific deployment. Under this proposal to adopt the UDAP Security IG v1, we have not proposed to require that all trust communities be supported by a Certified API Developer, nor have we specified a particular trust community. However, if an API User seeks to connect an application that is part of the same trust community as the deployed certified API technology, then dynamic registration must be made available to the API User's application. We are aware that there is a planned update to UDAP Security IG v1, UDAP Security IG v1.0.1, that may publish after the publication of this proposed rule. We anticipate that UDAP Security IG v1.0.1 will fix errors within the UDAP Security IG v1 and not include substantial revisions. As an alternative proposal to adopting the UDAP Security IG v1 in Sec. 170.215(o)(1), we propose to adopt UDAP Security IG v1.0.1 in Sec. 170.215(o)(1) if it is published prior to publication of a final rule finalizing policies proposed in this proposed rule. Interested parties may review the current version of the UDAP Security IG v1.0.1 at https://build.fhir.org/ig/HL7/fhir-udap-security-ig/. [[Page 63564]] c. Revision of Standardized API for Patient and Population Services To Support Dynamic Client Registration To reduce API User burden when registering their applications and facilitate accessibility of patient health data, we propose to revise the Sec. 170.315(g)(10) certification criterion to require on and after January 1, 2028, dynamic registration of confidential apps, including patient-facing, user-facing, and system apps, and subsequent authorization and authentication support for such dynamically registered apps. We note for this proposal that ``user'' is as defined in 77 FR 54168. First, we propose to modify the existing registration requirements currently in Sec. 170.315(g)(10)(iii) to require a standardized dynamic registration pathway supporting patient-facing, user-facing, and system confidential apps according to the UDAP Security IG v1. As proposed in section III.B.19 of this rule, the registration requirements for the Sec. 170.315(g)(10) certification criterion are proposed to be organized under Sec. 170.315(g)(10)(i). Therefore, we propose this new requirement for a dynamic registration pathway in Sec. 170.315(g)(10)(i)(B). This new standardized dynamic registration pathway would exist alongside the functional registration pathway currently required in Sec. 170.315(g)(10)(iii) and proposed in this rule to be included in Sec. 170.315(g)(10)(i)(A). Second, we propose to require support for authentication and authorization for dynamically registered patient-facing, user-facing, and system confidential apps. Please see section III.B.19 for further details on the proposed re-structuring of the Sec. 170.315(g)(10) certification criterion. As described in the ``Revised Standardized API for Patient and Population Services Criterion to Align with Modular API Capabilities'' section of this rule, we propose to restructure and move to Sec. 170.315(g)(10)(ii)(A) the existing requirements in Sec. 170.315(g)(10)(v)(A) for authorization for functionally registered patient-facing apps and user-facing apps according to the SMART App Launch IG. In section III.B.19, we propose moving the authorization requirements for functionally registered patient-facing apps to the proposed Sec. 170.315(g)(10)(ii)(A)(1)(i) and functionally registered user-facing apps to the proposed Sec. 170.315(g)(10)(ii)(A)(2)(i). We refer readers to section III.B.19 of this proposed rule for additional details regarding this and other related proposals. As described in more detail in subsequent paragraphs, we propose to require support for authorization for dynamically registered patient-facing apps in accordance with the requirements at the proposed Sec. 170.315(g)(10)(ii)(A)(1)(i) and for dynamically registered user-facing apps in accordance with the requirements at the proposed Sec. 170.315(g)(10)(ii)(A)(2)(i). On and after January 1, 2028, we propose to require support for authentication in accordance with the UDAP Security IG v1 of dynamically registered patient-facing apps in accordance with the requirements at the proposed Sec. 170.315(g)(10)(ii)(A)(1)(ii) and for dynamically registered user-facing apps in accordance with the requirements proposed in Sec. 170.315(g)(10)(ii)(A)(2)(ii). We describe the details of these proposed authentication requirements in subsequent paragraphs. On and after January 1, 2028, we propose to require support for authentication and authorization in accordance with the UDAP Security IG v1 of dynamically registered system apps in accordance with the requirements at the proposed Sec. 170.315(g)(10)(iii)(A)(2). We describe the details of these proposed authentication and authorization requirements in subsequent paragraphs. These proposed authorization requirements would establish a consistent, standardized method for authorizing dynamically registered patient-facing, user-facing, and system apps to retrieve patient data. We propose in Sec. 170.315(g)(10)(i)(B) to require on and after January 1, 2028, support for a dynamic registration pathway in the Sec. 170.315(g)(10) certification criterion for confidential apps, including patient-facing, user-facing, and system apps, standardized according to the UDAP Security IG v1. Using this proposed pathway, patient-facing, user-facing, and system confidential apps capable of supporting the UDAP Security IG v1 would be able to dynamically register with the Health IT Module's authorization server in an automated manner. Apps incapable of dynamic registration according to UDAP Security IG v1 would still be able to be registered using the current functional, non-standardized registration pathway currently specified in Sec. 170.315(g)(10)(iii), which is proposed to be moved to Sec. 170.315(g)(10)(i)(A) according to the proposal in section III.B.19 of this rule. We propose in Sec. 170.315(g)(10)(i)(B) to require Health IT Modules certified to Sec. 170.315(g)(10) to support dynamic registration of confidential apps according to the requirements in Sec. 170.315(j)(2), which requires support for dynamic registration of confidential apps according to the UDAP Security IG v1 proposed in Sec. 170.215(o). This includes mandatory support for sections ``Home,'' ``Discovery,'' and ``Registration'' as well as the ``community'' query parameter as defined in section ``Multiple Trust Communities.'' We propose requiring mandatory support for the aforementioned sections as they are the sections from the UDAP Security IG v1 relevant to supporting dynamic registration. We note that trust communities are responsible for enforcing their own policies regarding security and trust, and we encourage such communities to address the topics mentioned in section ``Trust Community Checklist'' of the UDAP Security IG v1 in order to further support for dynamic registration processes. We clarify in this proposal that Health IT Modules certified to Sec. 170.315(g)(10), through reference to Sec. 170.315(j)(2) in Sec. 170.315(g)(10)(i)(B), must support the otherwise optional ``community'' query parameter as defined in section ``Multiple Trust Communities'' of the UDAP Security IG v1 to facilitate an app's ability to retrieve dynamic registration metadata particular to a specific trust community. The ``community'' query parameter enables an application to receive metadata integral to the dynamic registration process which may otherwise be obscured if the Health IT Module certified to Sec. 170.315(g)(10) supports multiple trust communities. Next, we propose to require on and after January 1, 2028, support for client authentication for dynamically registered patient-facing confidential apps according to section ``Consumer-Facing'' of the UDAP Security IG v1 in Sec. 170.315(g)(10)(ii)(A)(1)(ii) by referencing the proposed certification criterion in Sec. 170.315(j)(5). The proposed certification criterion in Sec. 170.315(j)(5), in turn, requires support for authentication as detailed in section ``Consumer-Facing'' of the UDAP Security IG v1 proposed in Sec. 170.215(o). It is through this series of cross-references that we propose, in Sec. 170.315(g)(10)(ii)(A)(1)(ii), to require support for client authentication for dynamically registered patient-facing confidential apps according to section ``Consumer-Facing'' of the UDAP Security IG v1. Further, we propose to require on and after January 1, 2028, support for client authentication for dynamically [[Page 63565]] registered user-facing confidential apps according to the ``Business- to-Business'' section of the UDAP Security IG v1 in Sec. 170.315(g)(10)(ii)(A)(2)(ii) by referencing the proposed certification criterion in Sec. 170.315(j)(11). The proposed certification criterion in Sec. 170.315(j)(11), in turn, requires support for authentication for the ``authorization_code'' grant type as detailed in section ``Business-to-Business'' of the UDAP Security IG v1 proposed in Sec. 170.215(o). It is through this series of cross-references that we propose, in Sec. 170.315(g)(10)(ii)(A)(2)(ii), to require support for client authentication for dynamically registered user-facing confidential apps according to section ``Business-to-Business'' of the UDAP Security IG v1. We propose requiring the ``Consumer Facing'' and ``Business-to- Business'' sections of the UDAP Security IG v1 as they provide authentication requirements for dynamically registered patient-facing apps and user-facing apps respectively during the authorization process. The conformance expectation for support for patient-facing apps for this proposal is that the SMART App Launch capabilities, required in Sec. 170.315(g)(10)(ii)(A)(1)(i) by referencing the certification criterion proposed in Sec. 170.315(j)(9), would be required to be supported for both functionally registered and dynamically registered patient-facing apps. We propose the exception that client authentication for dynamically registered apps would be required to be supported according to section ``Consumer-Facing'' of the UDAP Security IG v1 as proposed in Sec. 170.315(g)(10)(ii)(A)(1)(ii) instead of client authentication according to the SMART App Launch implementation guide. Similarly, the requirement for support for user-facing apps for this proposal is that both functionally and dynamically registered user-facing apps would be required to be supported according to the SMART App Launch capabilities required in Sec. 170.315(g)(10)(ii)(A)(2)(i) by referencing Sec. 170.315(j)(10)(i). However, client authentication for dynamically registered user-facing applications would be required to be supported according to the ``Business-to-Business'' section of the UDAP Security IG v1 as proposed in Sec. 170.315(g)(10)(ii)(A)(2)(ii) instead of the SMART App Launch implementation guide. This proposal does not propose to change the authentication and authorization requirements for patient-facing apps and user-facing apps registered using the functional registration pathway proposed in Sec. 170.315(g)(10)(i)(A). Authentication and authorization for functionally registered patient-facing apps would be expected to occur according to the requirements proposed in Sec. 170.315(g)(10)(ii)(A)(1)(i), which would by reference to the proposed Sec. 170.315(j)(5) require SMART App Launch capabilities relevant to patient-facing app authentication and authorization. Similarly, authentication and authorization for functionally registered user-facing apps would be expected to occur according to the requirements proposed in Sec. 170.315(g)(10)(ii)(A)(2)(i), which would by reference to Sec. 170.315(j)(10)(i) require SMART App Launch capabilities relevant to user-facing app authentication and authorization. We refer readers to the ``Revised Standardized API for Patient and Population Services Criterion to Align with Modular API Capabilities'' section of this rule for additional information about the proposed requirements in Sec. 170.315(g)(10)(ii)(A)(1)(i) and (2)(i) and how those proposed requirements relate to current Sec. 170.315(g)(10) requirements for authentication and authorization for functionally registered patient- facing apps and user-facing apps. We also propose in Sec. 170.315(g)(10)(iii)(A)(2) that on and after January 1, 2028, authentication and authorization for dynamically registered system confidential apps must be supported according to the ``Business-to-Business'' section of the UDAP Security IG v1 by referencing the proposed Sec. 170.315(j)(8). Proposed Sec. 170.315(j)(8) would require authentication and authorization for the ``client_credentials'' grant type according to the ``Business-to- Business'' section of the UDAP Security IG v1 proposed in Sec. 170.215(o). We propose the system authentication and authorization requirements in Sec. 170.315(g)(10)(iii)(A)(2) to require support for a system authorization process which provides client authentication consistent with the proposed dynamic registration process for system confidential apps. This proposal does not propose to change the authentication and authorization requirements for system apps registered using the functional registration pathway proposed in Sec. 170.315(g)(10)(i)(A). Authentication and authorization for functionally registered system apps would be expected to occur according to the requirements proposed in Sec. 170.315(g)(10)(iii)(A)(1), which would by reference to proposed Sec. 170.315(j)(7) require the ``Backend Services'' section of at least one implementation specification adopted in Sec. 170.215(c). We refer readers to the ``Revised Standardized API for Patient and Population Services Criterion to Align with Modular API Capabilities'' section of this rule for additional information about the proposed requirements in Sec. 170.315(g)(10)(iii)(A)(1) and how those proposed requirements relate to current Sec. 170.315(g)(10) requirements for authentication and authorization for functionally registered system apps. We note that we propose in sections III.B.13.d and III.B.20.c to adopt dynamic registration according to the UDAP Security IG v1 for Health IT Modules certified to Sec. 170.315(g)(20), (30), (32)-(35). We invite readers to review those sections for details related to those proposals. d. Removal of Reference to OpenID Connect Core Specification In the ONC Cures Act Final Rule, we adopted the OpenID Connect Core 1.0 specification in Sec. 170.215(b) and clarified that only the components included in the SMART App Launch Framework 1.0.0 Implementation Guide adopted in Sec. 170.215(a)(3) were in scope for testing and certification (85 FR 25742). Relatedly, we finalized requirements for the Sec. 170.315(g)(10) certification criterion in (g)(10)(v)(A)(1)(i) that required for first time connections that authentication and authorization must occur during the process of granting access to patient data in accordance with SMART App Launch Framework 1.0.0 and OpenID Connect Core 1.0 (85 FR 25746). Subsequently in the HTI-1 Final Rule, we finalized moving the regulatory reference of the OpenID Connect Core 1.0 standard from Sec. 170.215(b) to Sec. 170.215(e)(1) (89 FR 1283). We no longer believe it is necessary to reference the OpenID Connect Core 1.0 specification separately in the API criteria requirements in the Program since the relevant end-user authentication requirements are sufficiently described through the ``sso-openid- connect'' capability from the versions of the SMART App Launch implementation guide currently and as proposed to be adopted in Sec. 170.215(c). We believe requiring the ``sso-openid-connect'' capability from the implementation specification in Sec. 170.215(c) is sufficient to specify the intended end-user authentication requirements related to the Sec. 170.315(g)(10), (30), and (34) certification criteria. The ``sso-openid-connect'' capability is proposed to be required in the Sec. 170.315(g)(10), (30), [[Page 63566]] and (34) certification criteria by requiring the ``Single Sign-on'' section from the implementation specifications in Sec. 170.215(c), which is required by referencing the proposed Sec. 170.315(j)(9) certification criterion in (g)(10)(ii)(A)(1)(i) and (g)(30)(ii)(A) and by referencing the proposed Sec. 170.315(j)(10) certification criterion in (g)(10)(ii)(A)(2)(i) and (g)(34)(ii)(A)(3)(i). Additional details regarding the proposed adoption of the ``sso-openid-connect'' capability in the Sec. 170.315(g)(10) certification criterion is in section III.B.19, and section III.B.20 for the Sec. 170.315(g)(30) and (34) certification criteria. Since we are proposing to adopt the ``sso-openid-connect'' capability in the Sec. 170.315(g)(10) certification criterion, we propose to remove reference to the Sec. 170.215(e)(1) from the current requirements in Sec. 170.315(g)(10)(v)(A)(1)(i) (as finalized in HTI-1 Final Rule), which are proposed to be moved to Sec. 170.315(g)(10)(ii)(A)(1)(i) according to the proposal in section III.B.19 of this rule. e. API Conditions and Maintenance Updates To Support Dynamic Client Registration As discussed in the ONC Cures Act Proposed and Final Rules, Section 4002 of the Cures Act requires the Secretary of HHS to establish Conditions and Maintenance of Certification requirements for the Program (84 FR 7465, 85 FR 25647). To implement this, ONC established the Conditions and Maintenance of Certification requirements in the ONC Cures Act Final Rule, including API Conditions and Maintenance requirements in Sec. 170.404, which establish baseline technical and behavioral requirements for Certified API Developers and their certified API technology. The API Conditions and Maintenance requirements established in the ONC Cures Act Final Rule implemented the Cures Act requirement that certified API technology allow ``health information from such technology to be accessed, exchanged, and used without special effort through the use of APIs or successor technology or standards, as provided for under applicable law'' (85 FR 25647). The API Condition of Certification includes three main conditions that focus on transparency, fees, and openness and pro-competitiveness. To complement these conditions, we also adopted in Sec. 170.404(b) Maintenance of Certification requirements that address ongoing, and, at times, frequent experiences Certified API Developers would face, such as app registration with certified API technology. We propose to revise the app registration-oriented maintenance requirements in Sec. 170.404(b) to align with the proposed registration requirements as part of the certification criteria in Sec. 170.315 (g)(10), (20), (30), and (32)-(35). First, we propose to revise the authenticity verification API Maintenance of Certification requirement in Sec. 170.404(b)(1)(i) to not apply to API Users that are part of a trust community submitting registration requests via the proposed dynamic client registration pathways in the certification criteria in Sec. 170.315 (g)(10), (20), (30), and (32)-(35). Specifically, if the API User is part of a trust community supported by the certified API technology used by an API Information Source and the API User's request to register is conformant to the UDAP Security IG v1, then this Maintenance of Certification requirement shall not apply. We propose to revise the requirement in this manner because API Users that are part of a supported trust community will have already undergone the authenticity verification processes required by the trust community to receive a trust community certificate, and their authenticity for registration can be rapidly proven via verification of their trust community certificate. Therefore, we believe that an additional verification process according to Sec. 170.404(b)(1)(i) by a Certified API Developer for verification of API Users possessing a supported trust community certificate and dynamically registering an app is unnecessary and would hinder dynamic registration of apps at scale. Second, we propose to revise the registration for production use API Maintenance of Certification requirement in Sec. 170.404(b)(1)(ii) so that the registration timeframe for API Users submitting dynamic registration requests according to the UDAP Security IG v1 is one business day, rather than five business days as otherwise applies. Specifically, if the API User is part of a supported trust community and their request to register is valid and conformant to the UDAP Security IG v1, then the Certified API Developer must register and enable the application for production use within one business day. We propose to revise the requirement in this manner to reflect the reduced time necessary to process the automated dynamic registration request. Third, we propose to add a new API Maintenance of Certification requirement by revising paragraph Sec. 170.404(b)(2)(iv) to require a Certified API Developer to publish information regarding the trust communities supported at each service base URL published as part of the requirements in Sec. 170.404(b)(2)(iii) that can be used by patients to access their EHI. This proposal includes publication of the trust community name, contact information, and web address, and identifying URL in a machine-readable format at no charge for each service base URL published in accordance with Sec. 170.404(b)(2)(iii) on and after January 1, 2028. We propose that Health IT Modules certified to Sec. 170.315(g)(10) may, but are not required, to support trust community discovery for dynamic registration in Sec. 170.404(b)(2)(iv) for the period up to and including December 31, 2027. Additionally, we propose in Sec. 170.404(b)(2)(i)(B) that these trust community details be reviewed quarterly, and, as necessary, updated by Certified API Developers. Finally, we propose to change the title of Sec. 170.404(b)(2) to ``publication of API discovery details for patient access'' to better reflect the requirements we have proposed for this section. We believe that these requirements would better facilitate individuals' access, exchange, and use of EHI, consistent with the Cures Act, and build upon the existing foundations established in the ONC Cures Act Final Rule by leveraging more advanced standards and enable individuals to access, exchange, and use health data without special effort via dynamic registration using applications of their choice. We welcome public comment on if the requirements for publication of API discovery details for Sec. 170.315(g)(10) should include endpoints enabling provider, bulk, and system access to EHI. Publication of information regarding supported trust communities enables API Users to know if a trust community they are participating in is also supported at a certified API technology's endpoint conformant to Sec. 170.315(g)(10) or Sec. 170.315(g)(30), and thus if dynamic client registration is supported at that endpoint for patient- facing apps. Without required publication of supported trust communities, API Users may have to query the metadata for each individual certified API technology's endpoint to confirm if their trust community is supported at that endpoint, which would hinder the registration of apps at scale. This requirement for Certified API Developers to publish trust community information would enable API access, exchange, and use of health data ``without special effort'' by ensuring API User access to information necessary for [[Page 63567]] scalable dynamic registration of patient-facing apps with certified API technology certified to Sec. 170.315(g)(10) or Sec. 170.315(g)(30). We refer readers to the ONC Cures Act Proposed Rule (84 FR 7477) for additional discussion regarding why we believe access to trust community, endpoint, and other API discovery details is a necessary attribute to enable API access, exchange, and use of health data ``without special effort.'' We clarify that Certified API Developers must publish the identifying URI as defined by the trust community, if such a UR is available. Otherwise, Certified API Developers are permitted to establish and publish a unique identifying URI for a trust community. For the purposes of this proposal, trust community URIs defined by the Certified API Developer must be used consistently to uniquely identify a trust community. We welcome comment on our proposal for publication of trust community details in Sec. 170.404(b)(2)(iv). As an alternative to requiring trust community details be published in any machine-readable format at no charge, we seek comment on standards-based publication strategies and formats for the trust community information we propose for Sec. 170.404(b)(2)(iv). We note our proposal earlier in this preamble in section III.B.3 to require service base URLs and related organization details be published in aggregate vendor-consolidate Brand Bundle format according to the User- access Brands and Endpoints (Brands) specification. We seek comment from Certified API Developers on whether they would consider augmenting their Brand Bundle with trust community information. The Brands specification profiles do not specifically account for trust community information, but given the breadth and extensibility of FHIR, the trust community information could theoretically be included in a Brand Bundle in FHIR format (e.g., using a FHIR extension). If this information is not included in the Brand Bundle, it would need to be published separately in some machine-readable format. We also seek comment from third party-app developers on how this information can best be published to support them in discovering and connecting to FHIR endpoints. 16. New Certification Criteria for Modular API Capabilities a. Proposal Background We propose to add a new paragraph (j) to Sec. 170.315 titled ``modular API capabilities.'' This new certification criteria category would promote the Program's modular certification approach and, importantly, would enable different combinations of capabilities across Health IT Modules depending on future use case needs. In general, we expect the capabilities in Sec. 170.315(j) would be standards-based and include a combination of new and existing standards, many of which are currently referenced in Sec. 170.315(g)(10). Additionally, we anticipate that the proposed capabilities in Sec. 170.315(j) would enable the Program to better support a growing number of clinical, public health, and administrative use cases over the long-term, as well as foster innovation and competition in these spaces by providing flexibility for modular development approaches among developers of certified health IT. Section 4002 of the Cures Act requires health IT developers, as a condition of certification, to publish APIs that allow ``health information from such technology to be accessed, exchanged, and used without special effort through the use of APIs or successor technology or standards, as provided for under applicable law.'' (emphasis added). The Cures Act's API Condition of Certification requirement also states that a developer must, through an API, ``provide access to all data elements of a patient's electronic health record to the extent permissible under applicable privacy laws.'' In the ONC Cures Act Final Rule (85 FR 25740), we described our approach to adopting a standardized API for patient and population services certification criterion in Sec. 170.315(g)(10). The Standardized API for Patient and Population Services in Sec. 170.315(g)(10) certification criterion includes conformance requirements for a combination of standards-- including data content standards (such as the USCDI standard) and technical standards (such as the SMART App Launch implementation specification for authentication and authorization)--and functional criteria for other technical capabilities (such as application registration and token introspection). Since 2020, the standards development community has undertaken work to: (1) update existing standards and implementation specifications (e.g., US Core IG from version 3.1.1 to 7.0.0) \166\; (2) formalize previously functional capabilities as part of implementation specifications (e.g., token introspection is now part of SMART App Launch 2.0) \167\; and (3) support new and revised capabilities that are modular and use case agnostic (e.g., HL7 CDS Hooks,\168\ FHIR Subscriptions,\169\ and UDAP Security FHIR IG).\170\ These developments have changed the heath IT landscape and helped support a wider range of potential technical solutions for healthcare use cases that previously may not have been supported, or were ineffectively supported, by health IT. --------------------------------------------------------------------------- \166\ https://hl7.org/fhir/us/core/history.html. \167\ https://hl7.org/fhir/smart-app-launch/STU2/token-introspection.html. \168\ https://cds-hooks.hl7.org/. \169\ https://hl7.org/fhir/uv/subscriptions-backport/STU1.1/. \170\ https://build.fhir.org/ig/HL7/fhir-udap-security-ig/branches/main/index.html. --------------------------------------------------------------------------- Over time, we have made updates to previously adopted certification criteria based on the evolution of available standards to support more advanced use cases leveraging similar functionality and increasingly interconnected health IT systems. In addition, we have sought to continuously improve the extensibility of specific conformance requirements so that those conformance requirements can support functionality in different types of health IT, and so that complex systems can be certified in a modular fashion. By using the term ``modular'' we mean certification criteria in the Program that are scoped to limited capabilities to enable health IT developers to certify to the specific certification criteria that apply to Health IT Modules they wish to certify, rather than large, multi-functionality, and all-encompassing certification criteria that would give developers less flexibility for certifying in the Program. The work to support extensibility and modularity of certification criteria within the Program has included cross-referencing aligned standards or capabilities across other certification criteria, which support consistent standards and functionality for related actions both across and within certified capabilities. For example, the certification criterion in Sec. 170.315(b)(2) clinical information reconciliation and incorporation references the same standards referenced throughout the transitions of care certification criterion in Sec. 170.315(b)(1), including Sec. 170.205(a)(3) through (5), and the privacy and security certification criteria in Sec. 170.315(d) are conditionally required for certification according to Health IT Module certification requirements for ONC-ACBs described in the privacy and security certification framework in Sec. 170.550(h). Establishing the privacy and security certification framework in Sec. 170.550(h) for ONC-ACBs ensures that Health IT Modules are subject to more specific privacy safeguards and provides more flexibility for certified health IT developers than would be the case if we had a single, [[Page 63568]] multi-functionality privacy and security criterion. Throughout the Program's history, we have also adopted both certification criteria that include the full scope of a complex transaction (e.g., Sec. 170.315(b)(3) electronic prescribing) and certification criteria that include a discrete portion of a transaction (e.g., Sec. 170.315(c)(1)-(4) clinical quality measures). These different approaches are intended to align our Program requirements to real world implementation scenarios which necessitate both contained execution of complex transactions and the ability to implement related processes across a range of systems in a modular fashion. Our adoption of these varying types of certification criteria allows ONC to administer a more effective and efficient Program, gives developers of certified health IT more nuanced certification options to meet their customers' needs, and promotes a more dynamic marketplace of certified Health IT Modules than would be the case if we bundled different functionalities and standards under fewer certification criteria. Based on our analysis of the continued evolution of standards and the real-world implementation scenarios for certified health IT to enable FHIR-based APIs, we are proposing to adopt new certification criteria supporting API capabilities for public health data exchange and patient, provider, and payer data exchange (see sections III.B.13 and III.B.20 respectively). As described in this section, we are proposing to revise Sec. 170.315(g)(10) through references to modular API capabilities proposed as certification criteria in Sec. 170.315(j). These certification criteria include standards, functionalities, and certification conformance requirements that align with or are the exact same as the standards, functionalities, and certification conformance requirements currently referenced in Sec. 170.315(g)(10). In addition, we are proposing to update the Sec. 170.315(g)(10) certification criterion to cross-reference newly proposed requirements. Specifically, we propose to adopt a suite of modular API capabilities as certification criteria in Sec. 170.315(j) where each criterion focuses on one specific certification conformance requirement, and we propose to reference these certification criteria as applicable in the proposed revisions to the Sec. 170.315(g)(10) certification criterion (see section III.B.19). For example, we propose to include in Sec. 170.315((j)(1) functional registration, (j)(6) SMART App Launch user authorization, (j)(7) SMART Backend Services system authentication and authorization, (j)(9) SMART Patient Access for Standalone Apps, (j)(10) SMART Clinician Access for EHR Launch. However, we also propose to include in these proposed certification criteria in Sec. 170.315(j) new certification conformance requirements that reflect more recent API standards advancements (e.g., workflow triggers, verifiable health records, and subscriptions) further described below. b. Modular API Capabilities Certification Criteria We propose to adopt fourteen new modular API technology certification criteria in Sec. 170.315(j) at (j)(1)-(2), (5)-(11), and (20)-(24). We propose to reserve (j)(3)-(4) and (12)-(19). These new certification criteria would be available for certification based on certain contexts or other programs requiring the use of the specified certified capabilities. Many of these certification criteria are substantially similar to capabilities currently referenced in Sec. 170.315(g)(10)(iii) through (vii). We invite readers to review 85 FR 25739 through 25748 for discussion relevant to capabilities currently referenced in Sec. 170.315(g)(10). In Sec. 170.315(j)(1), we propose the ``Functional registration'' certification criterion which would require that a Health IT Module demonstrate the ability for applications to register with its authorization server. The process of registration is necessary in many health IT workflows and enables an authorization server to establish a scope of information access for applications and share authentication credentials if applicable. This requirement would be similar to what currently exists in Sec. 170.315(g)(10)(iii) ``Application registration,'' which has a functional requirement to ``enable an application to register with the Health IT Module's `authorization server.' '' We clarify that for the proposed requirement in Sec. 170.315(j)(1) Health IT Modules presented for testing and certification must support application registration regardless of the scope of patient search utilized by the application (e.g., single or multiple). Additionally, this proposed certification criterion would require a health IT developer to demonstrate its registration process without requiring the use of an identified standard. In Sec. 170.315(j)(2), we propose the ``Dynamic registration'' certification criterion where a Health IT Module demonstrates the ability to dynamically register confidential apps according to the implementation specifications adopted in Sec. 170.215(o), including mandatory support for sections ``Home,'' ``Discovery,'' and ``Registration'' as well as the ``community'' query parameter as defined in the ``Multiple Trust Communities'' section of the implementation specifications adopted in Sec. 170.215(o). As described in more detail at section III.B.15 of this proposed rule, the UDAP Security IG v1 would provide a more uniform, standardized, and automated registration pathway for applications. We propose to reserve Sec. 170.315(j)(3) and (j)(4) for future potential registration capabilities. In Sec. 170.315(j)(5), we propose to adopt the ``Asymmetric certificate-based authentication for patient access'' certification criterion where a Health IT Module's authorization server must support authentication during the process of granting access to patient data to patients according to the implementation specifications adopted in Sec. 170.215(o), including support for asymmetric certificate-based authentication as detailed in section ``Consumer-Facing'' of the implementation specifications adopted in Sec. 170.215(o). Asymmetric certificate-based authentication is a process by which the client and server use public and private keys along with digital certificates for authentication. It is a similar process to asymmetric authentication with the modification that both the client and server verify each other's participation in a trust community. The client and server represent their participation in a trust community through a digital certificate issued by the trust community's certificate authorities. We note that asymmetric certificate-based authentication supports the dynamic client registration proposals included in this rule for adoption in Sec. 170.215(o)(1) (see the section titled New Requirements to Support Dynamic Client Registration Protocol in the Program). In Sec. 170.315(j)(6) we propose to adopt the ``SMART App Launch user authorization'' certification criterion where a Health IT Module's authorization server must support user authorization during the process of granting access to patient data according to at least one implementation specification adopted in Sec. 170.215(c). We note for this proposal that ``user'' refers to the end-user of an application, and may refer to either a patient, or a healthcare professional or his or her office staff. We clarify for the purposes of certification to this criterion that support for one type of user is sufficient (e.g., support for a patient user, or [[Page 63569]] support for a healthcare professional or his or her office staff user). The specific requirements include requiring support for Health IT Modules to issue a refresh token valid for a period of no less than three months to confidential apps and native apps capable of securing a refresh token in Sec. 170.315(j)(6)(i), receive and validate tokens issued by the Health IT Module in accordance with at least one implementation specification adopted in Sec. 170.215(c) in Sec. 170.315(j)(6)(ii), and enable for confidential apps persistent access to patient information without requiring user re-authentication or re- authorization until authorization revocation at the user's direction in Sec. 170.315(j)(6)(iii). We further propose in Sec. 170.315(j)(6)(iv) that a Health IT Module's authorization server must be able to revoke and must revoke an authorized application's access at a user's direction within 1 hour of the request. This proposed certification criterion includes the same functions for refresh tokens from Sec. 170.315(g)(10)(v)(A) ``Authentication and authorization for patient and user scopes'' as well as authorization revocation and token introspection functions from Sec. 170.315(g)(10)(vi) and (vii), respectively. Regarding support for the issuance of refresh tokens for native apps for this certification criterion, we mirror the conformance expectations established in the Information Blocking and the ONC Health IT Certification Program: Extension of Compliance Dates and Timeframes in Response to the COVID-19 Public Health Emergency Interim Final Rule (85 FR 70076), namely that health IT developers can determine the method(s) they use to support interactions with native apps and that health IT developers are not required to support all methods that third-party application developers seek to use. In Sec. 170.315(j)(7), we propose to adopt the ``SMART Backend Services system authentication and authorization'' certification criterion where a Health IT Module would support system authentication and authorization during the process of granting a system access to patient data in accordance with the backend services profile of at least one implementation specification adopted in Sec. 170.215(c). This certification criterion's conformance requirements are derived from what currently exists in Sec. 170.315(g)(10)(v)(B) ``Authentication and authorization for system scopes,'' proposed in Sec. 170.315(j)(7), as well as the token introspection requirements from Sec. 170.315(g)(10)(vii), proposed in Sec. 170.315(j)(7)(i). The proposed token introspection requirements in Sec. 170.315(j)(7)(i) include requiring that a Health IT Module's authorization server must be able to receive and validate tokens it has issued in accordance with at least one implementation specification adopted in Sec. 170.215(c). The HL7 standards community re-organized their standards and moved the ``SMART Backend Services: Authorization Guide'' from the Bulk v1 IG (adopted in Sec. 170.215(d)(1)) into the ``Backend Services'' section of the SMART Application Launch Implementation Guide Release 2.0.0 (adopted in Sec. 170.215(c)(2)). In Sec. 170.315(j)(8), we propose to adopt the ``Asymmetric certificate-based system authentication and authorization'' certification criterion where a Health IT Module would support system authentication and authorization for the ``client_credentials'' grant type during the process of granting access to patient data according to the implementation specifications adopted in Sec. 170.215(o), including support for the ``Business-to-Business'' section of the implementation specifications adopted in Sec. 170.215(o). This certification criterion would support system authentication and authorization for business-to-business access use cases within supported trust communities. This certification criterion would be similar in function to the certification criterion proposed in Sec. 170.315(j)(7) in that it would require system authentication and authorization capabilities but would additionally require support for contextual information and certificates as detailed in the UDAP Security IG v1 to enable authentication and authorization within a trust community. Additionally, we propose to include a section for ``Token introspection'' in Sec. 170.315(j)(8)(i), where a Health IT Module's authorization server must be able to receive and validate tokens it has issued in accordance with at least one implementation specification adopted in Sec. 170.215(c). This requirement would be similar to what currently exists in Sec. 170.315(g)(10)(vii) ``Token introspection'' and is aligned with similar token introspection requirements in Sec. 170.315(j)(6)(ii) and (7)(i). In Sec. 170.315(j)(9), we propose to adopt the ``SMART Patient Access for Standalone Apps'' certification criterion where the Health IT Module would support patient authorization and authorization revocation at a patient's direction according to the requirements in Sec. 170.315(j)(6). The capabilities described in the SMART Application Launch Framework Implementation Guide have matured and changed over time, and to support a health IT developer's ability to certify using any of the available implementation specifications in Sec. 170.215(c) we propose allowing health IT developers to support one of the following sets of SMART capabilities listed in paragraph (j)(9)(i), (ii), and (iii). We also note that versions of the SMART Application Launch Framework Implementation Guide adopted in Sec. 170.215(c) will expire on January 1, 2026 for Sec. 170.215(c)(1), and January 1, 2028 for Sec. 170.215(c)(2), and this proposed structure in Sec. 170.315(j)(9) will support the transition to newer versions of the implementation specification. The first set of SMART capabilities requires up to and including December 31, 2025, support for the ``Patient Access for Standalone Apps'' Capability Set, as well as the capabilities of ``launch-standalone'' and ``context-standalone- patient,'' and the capabilities in subsections ``Client Types,'' ``Single Sign-on,'' and ``Permissions'' except the ``permission-user'' from Sec. 170.215(c)(1). The second set of SMART capabilities requires up to and including December 31, 2027, support for ``Patient Access for Standalone Apps'' Capability Set as well as the capabilities of ``launch-standalone'' and ``context-standalone-patient,'' and the capabilities in subsections ``Authorization Methods,'' ``Client Types,'' ``Single Sign-on,'' and ``Permissions'' except the ``permission-online'' and ``permission-user'' capabilities from Sec. 170.215(c)(2). The third set of SMART capabilities requires on and after January 1, 2028, support the ``Patient Access for Standalone Apps'' Capability Set as well as the capabilities of ``launch- standalone'' and ``context-standalone-patient,'' and the capabilities in subsections ``Authorization Methods,'' ``Client Types,'' ``Single Sign-on,'' and ``Permissions'' except the ``permission-online'' and ``permission-user'' capabilities from Sec. 170.215(c)(3). In addition to requiring the foundational SMART App Launch capabilities for user authorization from proposed Sec. 170.315(j)(6), this certification criterion adds requirements to support SMART App Launch capabilities to enable patients to authorize apps to access information using the SMART standalone launch process. In Sec. 170.315(j)(10), we propose the ``SMART Clinician Access for EHR Launch'' certification criterion where the Health IT Module would support user authorization and authorization revocation at a user's direction according to the requirements in [[Page 63570]] Sec. 170.315(j)(6)(i)-(iii), including mandatory support for one of three sets of SMART capabilities to facilitate user access using EHR launch, proposed in Sec. 170.315(j)(10)(i)(A), (B), and (C). The proposal describes that for the time period up to and including December 31, 2025, a Health IT Module must meet either the requirements specified in paragraph Sec. 170.315(j)(10)(i)(A), (B), or (C); for the time period up to and including December 31, 2027, a Health IT Module must meet either the requirements specified in paragraph Sec. 170.315(j)(10)(i)(B) or (C); and finally on and after January 1, 2028, a Health IT Module must meet the requirements specified in paragraph Sec. 170.315(j)(10)(i)(C). The first set of SMART capabilities proposed in Sec. 170.315(j)(10)(A) requires support for the ``Clinician Access for EHR Launch'' Capability Set as well as the capabilities of ``launch-ehr,'' ``context-banner,'' ``context-style,'' and ``context-ehr-patient'' as well as the capabilities in subsections ``Client Types,'' ``Single Sign-on,'' and ``Permissions'' according to the implementation specification adopted in Sec. 170.215(c)(1). The second set of SMART capabilities proposed in Sec. 170.315(j)(10)(B) requires support for the ``Clinician Access for EHR Launch'' Capability Set as well as the capabilities of ``launch-ehr,'' ``context-banner,'' ``context-style,'' ``context-ehr-patient,'' and ``context-ehr-encounter,'' and the capabilities in subsections ``Authorization Methods,'' ``Client Types,'' ``Single Sign-on,'' and ``Permissions'' except the ``permission-online'' capability according to the implementation specification adopted in Sec. 170.215(c)(2). The third set of SMART capabilities proposed in Sec. 170.315(j)(10)(A) requires support for the ``Clinician Access for EHR Launch'' Capability Set as well as the capabilities of ``launch-ehr,'' ``context-banner,'' ``context-style,'' ``context-ehr-patient,'' and ``context-ehr-encounter,'' and the capabilities in subsections ``Authorization Methods,'' ``Client Types,'' ``Single Sign-on,'' and ``Permissions'' except the ``permission-online'' capability according to the implementation specification adopted in Sec. 170.215(c)(3). In addition to requiring the foundational SMART App Launch capabilities for user authorization from proposed Sec. 170.315(j)(6)(iv), this certification criterion adds requirements to support SMART App Launch capabilities to enable users to authorize apps to access information using the SMART EHR launch process. As discussed in section ``SMART App Launch 2.2'' of this rule, we propose to no longer reference specific capabilities and sections of the SMART App Launch implementation guide under Sec. 170.215(c). Instead, Program criteria would specify required capabilities of the SMART App Launch implementation guide. In alignment with that proposal, we propose the SMART capabilities as adopted in HTI-1 in Sec. 170.215(c)(1) for SMART App Launch 1.0.0 and Sec. 170.215(c)(2) for SMART App Launch 2.0.0 be moved to the proposed Sec. 170.315(j)(6)- (10) certification criteria. We propose the SMART App Launch 1.0.0 capabilities relevant to patient access for standalone apps be specified at proposed Sec. 170.315(j)(9)(i) and the capabilities relevant to clinician access for EHR launch be specified at proposed Sec. 170.315(j)(10)(i)(A). Similarly, we propose the SMART App Launch 2.0.0 capabilities relevant to patient access for standalone apps be specified at proposed Sec. 170.315(j)(9)(ii) and the capabilities relevant to clinician access for EHR launch be specified at proposed Sec. 170.315(j)(10)(i)(B). Finally, we propose to include the SMART App Launch 2.2.0 capabilities in Sec. 170.315(j)(9)(iii) for patient access and Sec. 170.315(j)(10)(i)(C) for clinician access. We propose moving token introspection according to SMART App Launch 2.0.0 as adopted in Sec. 170.215(c)(2) in HTI-1 Final Rule to requirements in the proposed certification criteria in Sec. 170.315(j)(6)-(8), which includes (j)(6)(ii), (7)(i), and (8)(i). The proposed certification criteria in Sec. 170.315(j)(9) and (10) would also include conformance dates for each set of required SMART App Launch capabilities that would enable developers as they present their products for certification to move to the newer requirements when they are ready and prior to when a particular conformance requirement may expire, and the other(s) become the new baseline. In Sec. 170.315(j)(11), we propose the ``Asymmetric certificate- based authentication for B2B user access'' certification criterion where the Health IT Module would support asymmetric certificate-based authentication for the ``authorization_code'' grant type during the process of granting access to patient data to users according to the implementation specifications adopted in Sec. 170.215(o), including support for asymmetric certificate-based authentication as detailed in the ``Business-to-Business'' section of the implementation specifications adopted in Sec. 170.215(o). This certification criterion would be similar to the certification criterion proposed in Sec. 170.315(j)(5) in that it would require support for certificate- based authentication according to the UDAP Security IG v1. However, this certification criterion would be focused on business-to-business authentication requirements to enable users, not patients, access to information in a within a trust community. We intend to reserve Sec. 170.315(j)(12) through (j)(19) in anticipation of future standards-based capabilities that would be complementary to the certification criteria proposed for adoption in Sec. 170.315(j)(1) through (j)(11). Beginning in Sec. 170.315(j)(20), we propose a set of new standards-based capabilities. These capabilities are not derived from the existing conformance requirements specified in Sec. 170.315(g)(10). Rather, they reflect more advanced capabilities enabled by the HL7 FHIR standard and related implementation guides. We propose to adopt ``workflow triggers for decision support interventions-- clients'' in Sec. 170.315(j)(20) and Workflow triggers for decision support interventions--services at (j)(21); ``Verifiable health records'' in Sec. 170.315(j)(22); and ``Subscriptions--server'' in Sec. 170.315(j)(23) and ``Subscriptions--client'' at (j)(24). We propose these modular certification criteria to be broadly applicable to various clinical, public health, and administrative use cases. Below, we describe and provide our rationale for each of these advanced capabilities proposed for inclusion in Sec. 170.315(j)(20) through (24). i. Sec. 170.315(j)(20) and (21) Workflow Triggers for Decision Support Interventions We propose to adopt the CDS Hooks Release 2.0 implementation specification in Sec. 170.215(f)(1) to support Program requirements for API-based workflow triggers for decision support interventions (as described in more detail in the next paragraph) in the proposed certification criteria in Sec. 170.315(j)(20) and (j)(21). These certification criteria are proposed separately but are both related to the underlying specification in Sec. 170.215(f)(1). The certification criterion proposed in Sec. 170.315(j)(20) includes requirements for ``clients'' participating in API-based workflow triggers for decision support, and the certification criterion proposed in Sec. 170.315(j)(21) includes requirements for ``services'' providing decision support services to clients. [[Page 63571]] CDS Hooks is a specification that describes a ``hook''-based pattern for invoking or triggering decision support from within a clinician's workflow (typically the ``client'' side of this pattern). This pattern facilitates a clinician's ability to either pull in results from decision support directly into a clinician's workflow or can be used to launch an interactive application. We propose that a Health IT Module presented for certification to Sec. 170.315(j)(20) support the requirements of the implementation specification in Sec. 170.215(f)(1) as a ``CDS Client'' including support for the registration of ``CDS Services'' according to the implementation specification in Sec. 170.215(f)(1) in Sec. 170.315(j)(20)(i) and support for authentication and authorization \171\ according to the implementation specification in Sec. 170.215(f)(1) in Sec. 170.315(j)(20)(ii). We also propose in Sec. 170.315(j)(20)(iii) that Health IT Modules certified to Sec. 170.315(j)(20) support the execution of decision support workflow triggers in accordance with the implementation specification in Sec. 170.215(f)(1), as well as demonstrate the ability to send a decision support request to a CDS Service according to the implementation specification in Sec. 170.215(f)(1), in Sec. 170.315(j)(20)(iv). As part of the capability to send a decision support request to a CDS Service, we propose in Sec. 170.315(j)(20)(iv)(A) that a Health IT Module support the ability to deliver a CDS Hook request with prefetched information according to the ``Prefetch Template'' section of the implementation specification in Sec. 170.215(f)(1); support access to HL7 FHIR Resources via a RESTful API to support decision support intervention workflows according to the ``FHIR Resource Access'' section of the implementation specification in Sec. 170.215(f)(1) in Sec. 170.315(j)(20)(iv)(B); and support the receipt of a decision support response according to the implementation specification in Sec. 170.215(f)(1) in Sec. 170.315(j)(20)(iv)(C), including support the display of the contents of a decision support response to an end-user and support the ability to launch internal apps and SMART apps from decision support responses according to the implementation specification in Sec. 170.215(f), including support for the ``Link'' field ``appContext,'' in Sec. 170.315(j)(20)(iv)(C)(1) and Sec. 170.315(j)(20)(iv)(C)(2), respectively. --------------------------------------------------------------------------- \171\ CDS Hooks Release 2.0 includes authentication and authorization of endpoints and identity of the CDS Client. We direct readers to the implementation specification for more detail. --------------------------------------------------------------------------- We propose that a Health IT Module presented for certification to Sec. 170.315(j)(21) support the complementary aspects of the workflow trigger implementation specification in Sec. 170.215(f)(1). Specifically, we propose these Health IT Modules support the requirements of the implementation specification in Sec. 170.215(f)(1) as a ``CDS Service'' including support for registration of CDS Clients in Sec. 170.315(j)(21)(i) and authentication and authorization according to the implementation specification in Sec. 170.215(f)(1) in Sec. 170.315(j)(21)(ii). In Sec. 170.315(j)(21)(iii), we propose a Health IT Module respond to requests for recommendations and guidance via a RESTful API according to the implementation specification in Sec. 170.215(f)(1), including capabilities to receive and process decision support requests in Sec. 170.315(j)(21)(iii)(A); the ability to receive pre-fetched information according to the ``Prefetch Template'' section of the implementation specification Sec. 170.215(f)(1) in Sec. 170.315(j)(21)(iii)(A)(1); and the ability to fetch HL7 FHIR Resources via an API according to the ``FHIR Resource Access'' section of the implementation specification Sec. 170.215(f)(1) in Sec. 170.315(j)(21)(iii)(A)(2). Finally, we propose in Sec. 170.315(j)(21)(iii)(B) that Health IT Modules support returning a decision support response according to the implementation specification in Sec. 170.215(f)(1), including support for the ``Link'' field ``appContext.'' We note that the proposed workflow triggers criteria in Sec. 170.315(j)(20) and (j)(21) do not define or propose specific workflows associated with decision support, including how and when clinicians use decision support capabilities. Rather, we propose to include standards- based interfaces in Sec. 170.315(j)(20) and (j)(21) to enable clinical systems to call other systems offering decision support services in a standardized manner to support the exchange and use of these services.172 173 174 We request comment on these proposals. --------------------------------------------------------------------------- \172\ Bradshaw, R.L., Kawamoto, K., Kaphingst, K.A., Kohlmann, W.K., Hess, R., Flynn, M. C., . . . Del Fiol, G. (2022). GARDE: a standards-based clinical decision support platform for identifying population health management cohorts. Journal of the American Medical Informatics Association: JAMIA, 29(5), 928-936. doi:10.1093/ jamia/ocac028. \173\ Morgan, K.L., Kukhareva, P., Warner, P.B., Wilkof, J., Snyder, M., Horton, D., . . . Kawamoto, K. (2022). Using CDS Hooks to increase SMART on FHIR app utilization: a cluster-randomized trial. Journal of the American Medical Informatics Association: JAMIA, 29(9), 1461-1470. doi:10.1093/jamia/ocac085. \174\ Watkins, M., & Eilbeck, K. (2020). FHIR Lab Reports: using SMART on FHIR and CDS Hooks to increase the clinical utility of pharmacogenomic laboratory test results. AMIA Summits on Translational Science proceedings, 2020, 683-692. --------------------------------------------------------------------------- ii. Sec. 170.315(j)(22) Verifiable Health Records We propose that a Health IT Module presented for certification to Sec. 170.315(j)(22) support the issuance of verifiable health records according to the SMART Health Cards Framework version 1.4.0 standard (SMART Health Cards), which we propose to adopt in Sec. 170.215(g)(1)(i). SMART Health Cards specifies a framework for issuing records represented using HL7 FHIR structured information to users that can be verified by another party.\175\ SMART Health Cards is based on international open standards. In addition to HL7 FHIR, SMART Health Cards incorporate DEFLATE Compression, JSON Web Token (JWT), JSON Web Key (JWK), JSON Web Key (JWK) Thumbprint, and HMAC-SHA-256.\176\ SMART Health Cards support a decentralized infrastructure and addresses common concerns around verifying portable data. Once a SMART Health Card is generated, the data becomes verifiable to a point in time, which can then be shared at the patient's discretion via Quick-Response Code (QR code). QR Codes are two dimensional barcodes that can encode up to about 3Kb of data.\177\ The QR Codes can be easily scanned via smartphones to access the SMART Health Card. We also propose to adopt the SMART Health Cards: Vaccination and Testing Implementation Guide version 1.0.0-rc--STU 1 Release Candidate,'' in Sec. 170.215(g)(2)(i), an HL7 FHIR implementation guide that leverages the SMART Health Cards Framework to describe standards-based methods for the issuance of verifiable health records for vaccination status and infectious disease-related laboratory testing. --------------------------------------------------------------------------- \175\ https://smarthealth.cards/en/. \176\ https://spec.smarthealth.cards/#what-software-libraries-are-available-to-work-with-smart-health-cards. \177\ https://www.qrcode.com/en/about/. --------------------------------------------------------------------------- The SMART Health Cards standard has seen rapid adoption in the past few years as a reliable and easy way for consumers to receive and share verifiable clinical information. Some notable use cases for verifiable records that have been implemented in clinical settings using the SMART Health Cards standard occurred during the COVID-19 public health emergency to support verifiable COVID-19 test results and [[Page 63572]] COVID-19 vaccination records.178 179 In support of these and related use cases, we propose in Sec. 170.315(j)(22)(i) that Health IT Modules support the ``data minimization'' and ``allowable data'' profiles of the following according to the implementation specification adopted in Sec. 170.215(g)(2)(i): ``Immunization Bundle,'' ``COVID-19 Labs Bundle,'' and ``Generic Labs Bundle,'' ``Patient--United States,'' ``Vaccination,'' ``Lab results COVID-19,'' and ``Lab results-- Generic.'' We propose in Sec. 170.315(j)(22)(ii) that Health IT Modules support the ``$health-cards-issue'' operation via a standardized API according to the implementation specification adopted in Sec. 170.215(g)(1)(i). We are also aware that the SMART Health Cards standard is going through the ballot and publication process at HL7 over the next several months. ONC encourages the community to follow along and can access the current CI Build at https://build.fhir.org/ig/HL7/smart-health-cards-and-links/cards-specification.html. If there is a published version of the SMART Health Cards standard prior to the publication of the final rule, we will consider adopting that version. We welcome comment on our proposals. --------------------------------------------------------------------------- \178\ Braunstein, M.L. (2022). SMART on FHIR. In: Health Informatics on FHIR: How HL7's API is Transforming Healthcare. Health Informatics. Springer, Cham. https://doi-org.hhsnih.idm.oclc.org/10.1007/978-3-030-91563-6_10. \179\ https://www.thecommonsproject.org/shc. --------------------------------------------------------------------------- We also note that while we have not proposed nor are we seeking comment on the SMART Health Links technical specification that we are closely following its advances as well as industry uses for future rulemakings. iii. Sec. 170.315(j)(23) and (24) Subscriptions The HL7 FHIR Subscriptions Framework describes a standardized method for clients to subscribe to notifications from servers based on pre-negotiated criteria. Once the subscription is established, servers can proactively notify a client when new information has been added or existing information has been updated in its system. Once a notification has been received by a client, the client can take appropriate action, including querying the server for the desired information. The HL7 FHIR Subscriptions Framework also describes methods to transmit payloads with notifications, which may help simplify some interorganizational transactions by enabling real-time updates, selective data transmission, and interoperability, making data exchange between organizations more efficient and effective. We anticipate that API-based subscriptions will support several use cases across clinical, public health, administrative and research domains. Specific to public health use cases, we envision that future implementation guides could leverage the HL7 FHIR Subscriptions Framework for case reporting processes, immunization reporting processes, syndromic surveillance, reportable laboratory tests and values, and transmitting cancer case information to state cancer registries, among others. We welcome comments on this approach, particularly with respect to the readiness of this standard to support public health reporting and any potential benefits or limitations to this approach that we should consider. The HL7 FHIR Subscriptions Framework has undergone a significant redesign during the development of the HL7[supreg] FHIR[supreg] Release 5 (R5) standard, including the use of ``SubscriptionTopic'' HL7 FHIR Resources that define the criteria for standardized subscription notifications. We have structured our proposals in Sec. 170.315(j)(23) and (24) to best accommodate health IT developers and the industry's maturity so that API-based subscriptions can be more easily implemented in the current health IT landscape. While the HL7 FHIR Subscriptions Framework in HL7[supreg] FHIR[supreg] R5 is well developed, the health IT industry is largely using HL7[supreg] FHIR[supreg] Release 4, Version 4.0.1 (HL7[supreg] FHIR[supreg] R4), for HL7 FHIR standards- based exchange. Updating all the criteria in the Program to HL7[supreg] FHIR[supreg] R5 to accommodate the updated HL7 FHIR Subscriptions Framework would not be practicable nor prudent given the full-scale industry redesign that would be necessary to do so and impacts on users. In order to enable health IT developers using HL7[supreg] FHIR[supreg] R4, to support the improvements made in the HL7 FHIR Subscriptions Framework in HL7[supreg] FHIR[supreg] R5, the HL7 standards community created the Subscriptions R5 Backport Implementation Guide version 1.1.0, which specifies some of the HL7[supreg] FHIR[supreg] R5 Subscriptions Framework enhancements in a way that is compatible with HL7[supreg] FHIR[supreg] R4. We propose that a Health IT Module presented for certification to Sec. 170.315(j)(23) or Sec. 170.315(j)(24) support API-based subscriptions according to HL7 FHIR Subscriptions Framework included in the HL7 FHIR Subscriptions R5 Backport Implementation Guide version 1.1.0 (hereafter referred to as ``Subscriptions IG''), which we propose to adopt in Sec. 170.215(h)(1). The proposals in Sec. 170.315(j)(23) and (24) specify constraints on the implementation specification proposed in Sec. 170.215(h)(1), which intend to ensure that Health IT Modules certified to Sec. 170.315(j)(23) or (24) can conform to separate but related aspects and functions of the implementation specification in Sec. 170.215(h). Similar to the proposals in Sec. 170.315(j)(20) and (21), we propose that Health IT Modules certified to Sec. 170.315(j)(23) support subscriptions as a ``server'' and Health IT Modules certified to Sec. 170.315(j)(24) support subscriptions as a ``client'' according to the implementation specification proposed in Sec. 170.215(h)(1). Recognizing the importance of reducing burden on health IT developers while also striving to improve nationwide interoperability, we propose to adopt the Subscriptions IG in Sec. 170.215(h)(1) support certification criteria for API-based subscriptions in Sec. 170.315(j)(23) subscriptions--server and Sec. 170.315(j)(24) subscriptions--client requirements. The Subscriptions IG includes API- based subscription functionality that goes beyond the scope of FHIR R4, but for the purposes of the Program, we propose in Sec. 170.315(j)(23)(i) and (24)(i), for servers and clients respectively, that Health IT Modules support the requirements specified in section ``1.6 Topic-Based Subscriptions--FHIR R4'' of the implementation specification in Sec. 170.215(h)(1). Additionally, we propose in Sec. 170.315(j)(23)(ii) and (24)(ii), for servers and clients respectively, that Health IT Modules support the ``R4/B Topic-Based Subscription'' profile as specified in the Subscriptions IG. We note that while this profile is compatible with both HL7[supreg] FHIR[supreg] R4, and HL7[supreg] FHIR[supreg] R4B, we propose it for use with HL7[supreg] FHIR[supreg] R4, at this time. We also propose in Sec. 170.315(j)(23)(iii) that Health IT Modules support the requirements described in the ``R4 Topic-Based Subscription Server Capability Statement'' of the implementation specification in Sec. 170.215(h)(1), including support for ``create,'' ``update,'' and ``delete'' interactions for HL7 FHIR Subscription Resources according to the implementation specification in Sec. 170.215(h)(1). We propose corresponding requirements for clients in Sec. 170.315(j)(24)(iii), specifically that Health IT Modules support the accompanying client capabilities for the minimum requirements included in the ``R4 [[Page 63573]] Topic-Based Subscription Server Capability Statement'' of the implementation specification in Sec. 170.215(h)(1), including support for ``create,'' ``update,'' and ``delete'' interactions for HL7 FHIR Subscription Resources according to the implementation specification in Sec. 170.215(h)(1). We propose to require servers support the ``create,'' ``update,'' and ``delete'' interactions so that a client will be enabled to create, modify, and delete subscriptions on a server using a standardized API. Finally, we propose in Sec. 170.315(j)(23)(iv) that Health IT Modules support the ability to send subscription notifications to subscribed clients, and in 170.315(j)(24)(iv) that Health IT Modules support the ability to receive subscription notifications, according to the ``1.6 Topic-Based Subscriptions--FHIR R4'' section of the implementation specification in Sec. 170.215(h)(1). We propose to include in Sec. 170.315(j)(23)(iv)(A) and (24)(iv)(A), for servers and clients respectively, that support for ``id-only'' Payload Types is required as specified in the ``Payload Types'' section of the implementation specifications in Sec. 170.215(h)(1). There are three options available when specifying contents of a notification: empty, id-only, and full-resource. We believe that id-only provides a good balance between security and performance. Additionally, we propose in Sec. 170.315(j)(23)(v) that Health IT Modules support the ability for a client to subscribe to a subscription topics and parameters defined in notifications by the subscription topics as defined in Sec. 170.315(j)(23)(v)(A) and Sec. 170.315(j)(23)(v)(B)(1)-(19). We propose in Sec. 170.315(j)(23)(A) to require Health IT Modules support USCDI change notifications which allows a client to subscribe to receive notifications filtered by a patient identifier and send notifications when any of the Resources specified in Sec. 170.315(j)(23)(v)(B) are created or updated as applicable according to the standard in Sec. 170.215(a) and implementation specification in Sec. 170.215(h)(1). We further propose in Sec. 170.315(j)(23)(v)(B) that Health IT Modules support resource notifications supporting the ability for a client to subscribe to notifications filtered according to the conditions below and send notifications for the following Resource interactions according to the standard in Sec. 170.215(a) and implementation specification in Sec. 170.215(h)(1): ``AllergyIntolerance'' Resource is created or updated, including support for filtering subscription notifications using ``category,'' ``code,'' and ``patient'' data elements. ``CarePlan'' Resource is created or updated, including support for filtering subscription notifications using ``category'' and ``subject'' data elements. ``CareTeam'' Resource is created, or updated, including support for filtering subscription notifications using ``category'' and ``subject'' data elements. ``Condition'' Resource is created or updated, including support for filtering subscription notifications using ``category,'' ``code,'' and ``subject'' data elements. ``Coverage'' Resource is created or updated, including support for filtering subscription notifications using ``beneficiary'' and ``type'' data elements. ``DiagnosticReport'' Resource is created or updated, including support for filtering subscription notifications using ``category,'' ``code,'' and ``subject'' data elements. ``DocumentReference'' Resource is created or updated, including support for filtering subscription notifications using ``subject'' and ``type'' data elements. ``Encounter'' Resource is created or updated, including support for filtering subscription notifications using ``reasonCode,'' ``subject,'' and ``type'' data elements. ``Goal'' Resource is created or updated, including support for filtering subscription notifications using ``category,'' ``description,'' and ``subject'' data elements. ``Immunization'' Resource is created or updated, including support for filtering subscription notifications using ``patient,'' and ``vaccineCode'' data elements. ``MedicationDispense'' Resource is created or updated, including support for filtering subscription notifications using ``category,'' ``medication[x],'' and ``subject'' data elements. ``MedicationRequest'' Resource is created or updated, including support for filtering subscription notifications using ``category,'' ``medication[x],'' and ``subject'' data elements. ``Observation'' Resource is created or updated, including support for filtering subscription notifications using ``category,'' ``code,'' and ``subject'' data elements. ``Patient'' Resource is updated, including support for filtering subscription notifications using the ``identifier'' data element. ``Procedure'' Resource is created or updated, including support for filtering subscription notifications using ``category,'' ``code,'' and ``subject'' data elements. ``QuestionnaireResponse'' Resource is created or updated, including support for filtering subscription notifications using the ``subject'' data element. ``RelatedPerson'' Resource is created or updated, including support for filtering subscription notifications using the ``patient'' data element. ``ServiceRequest'' Resource is created or updated, including support for filtering subscription notifications using ``category,'' ``code,'' and ``subject'' data elements. ``Specimen'' Resource is created or updated, including support for filtering subscription notifications using ``patient'' and ``type'' data elements. We believe our proposal in Sec. 170.315(j)(23)(v) reflects the public feedback we received during the HTI-1 rulemaking process. Several commenters recommended that the subscription criterion focus on retrieving patient data associated with a specific patient ID as a starting point. Proposals in Sec. 170.315(j)(23) and Sec. 170.315(j)(24) included in this section reflect public feedback we received in the HTI-1 Proposed Rule. For Sec. 170.315(j)(23), in the HTI-1 Proposed Rule, we received feedback supporting subscription notification for patient data associated with a specific patient ID that allows for notifications based on new or updated data associated with the patient's resources. The proposed resources specified in Sec. 170.315(j)(23)(v)(B) are a subset of USCDI/US Core IG Resources filtered to include those that are part of the HL7 FHIR ``Compartment Patient'' \180\ and are widely supported across the healthcare industry. We believe that aligning subscription requirements with US Core resources that are required across several ONC certification Program criteria will contribute to better data exchange, improved patient care, and more effective health IT systems. --------------------------------------------------------------------------- \180\ https://hl7.org/fhir/R4/compartmentdefinition-patient.html. --------------------------------------------------------------------------- We seek public comment on the listed US Core resources in Sec. 170.315(j)(23)(v)(B), and we alternately propose to require client servers to support the ability for a client to subscribe to notifications filtered by all, meaning any, USCDI/US Core resources for ``category,'' ``code,'' and ``subject'' data elements where applicable. We additionally propose to include in Sec. 170.315(j)(23)(iv)(B) that at a minimum, support for the ``REST-Hook'' channel is required for sending subscription notifications to clients as specified in the ``Channels'' section of the implementation specifications in Sec. 170.215(h)(1). The REST-hook channel [[Page 63574]] uses the RESTful model which is extensively used in FHIR standard and is considered to present the lowest bar for implementation. Finally, we propose to include in Sec. 170.315(j)(24)(iv)(B) required support for consuming notifications via the ``REST-Hook'' channel as specified in the ``Channels'' section of the implementation specifications in Sec. 170.215(h)(1). We note that we have included references to the proposed certification criterion in Sec. 170.315(j)(23) in two proposed certification criteria in Sec. 170.315(g)(20) and Sec. 170.315(g)(35) and refer readers to those sections for more information on the proposals. Additionally, we have included a reference to the proposed certification criterion in Sec. 170.315(j)(24) in the proposed certification criterion in Sec. 170.315(g)(34) and refer to that section for more information on the proposals. We believe our proposal and alternative proposals in Sec. 170.315(j)(23) and Sec. 170.315(j)(24) reflect the public feedback we received during the HTI-1 rulemaking process. We acknowledge that the standards may have matured beyond the prior recommended feedback from the HTI-1 Proposed Rule and request comment on these proposals and whether interested individuals and organizations would prefer to implement other standards listed in the Subscriptions IG, including API-based subscriptions based on HL7 FHIR R5. 17. Multi-Factor Authentication Criterion a. Background In the ONC Cures Act Final Rule, we finalized a ``multi-factor authentication'' (MFA) certification criterion in Sec. 170.315(d)(13) and applied it to all certification criteria across the privacy & security (P&S) certification framework (85 FR 25700). Through this certification criterion and the P&S Certification Framework, we established an approach that required health IT developers to be transparent about whether their certified Health IT Module supports MFA. As part of the certification process, developers' ``yes'' or ``no'' attestations are made public on ONC's Certified Health IT Product List (CHPL) which is accessible here: https://chpl.healthit.gov/. We established this approach in acknowledgement that ``MFA may not be appropriate or applicable in all situations'' and that ``there is a wide variation in authentication needs and approaches throughout the industry'' (85 FR 25701). We also acknowledged some of the challenges with adopting MFA in healthcare, noting comments expressing concern that it could increase provider burden (85 FR 25701). We therefore finalized our current approach to allow for developers to attest ``no'' as a certification option, and to promote increased transparency into these ``no'' attestations, we included a provision that permitted health IT developers attesting ``no'' to explain why their Health IT Module does not support MFA. Any optional explanations provided were also made available to the public on the CHPL as part of the certification process. b. Proposal We propose to update the requirements in the ``Multi-factor authentication'' certification criterion in Sec. 170.315(d)(13) to increase support for MFA in certified health IT without imposing additional requirements on health care providers. We believe these updates match industry information security best practice for important authentication use cases in health IT and that it is necessary to help better protect electronic health information. We propose to expire our current ``yes'' or ``no'' attestation requirements by moving them to Sec. 170.315(d)(13)(i) and including an applicability date for the time period up to and including December 31, 2027 in Sec. 170.315(d)(13). We propose to replace the attestation requirements by revising Sec. 170.315(d)(13) to include the new requirements in Sec. 170.315(d)(13)(ii) that become required for continued conformance on and after January 1, 2028. We propose with these new requirements to require, in Sec. 170.315(d)(13)(ii)(A), Health IT Module support for authentication, through multiple elements of the user's identity, according to industry recognized standards. Additionally, we propose, in Sec. 170.315(d)(13)(ii)(B), to require that Health IT Modules certified to the criterion provide functionality that allows users (e.g., providers and patients) to configure, enable and disable these multi-factor authentication capabilities. Lastly, we propose that a health IT developer may meet the proposed revised certification criterion's requirements just by satisfying the new conformance requirements proposed in Sec. 170.315(d)(13)(ii) in lieu of Sec. 170.315(d)(13)(i) prior to paragraph (i)'s December 31, 2027, expiration. We expect that Health IT Modules certifying to this MFA criterion must have the ability to authenticate users using multiple means to confirm that users are who they claim to be. Multiple means of authentication in this context includes using two or more of the following: (i) Something people know, such as a password or a personal identification number (PIN); (ii) something people have, such as a phone, badge, card, RSA token or access key; and (iii) something people are, such as fingerprints, retina scan, heartbeat, and other biometric information (85 FR 25701). Examples of industry recognized standards for MFA include NIST Special Publication 800-63B Digital Identity Guidelines, and ISO 27001.\181\ As we stated in 2019, when we first proposed MFA requirements in the Program, a government led initiative and numerous organizations and groups recommend the use of MFA (84 FR 7451). More recently, the HHS Office for Civil Rights has identified weakened healthcare authentication measures as one of the biggest causes of data breaches in recent years.\182\ We believe our proposal helps improve security by increasing access to MFA. This is because it is less likely that an unauthorized individual or entity will be able to succeed in proving one's identity when more than one authentication factor is used. --------------------------------------------------------------------------- \181\ NIST Special Publication 800-63B: https://pages.nist.gov/800-63-3/sp800-63b.html; ISO 27001: https://www.iso.org/standard/27001. \182\ https://www.hhs.gov/hipaa/for-professionals/security/guidance/cybersecurity-newsletter-june-2023/index.html. --------------------------------------------------------------------------- We also propose corresponding revisions in the principles of proper conduct for ONC-ACBs in Sec. 170.523(m) and the privacy and security certification framework in Sec. 170.550(h)(3). In Sec. 170.523(m)(3) we propose to time-limit the applicability of Sec. 170.315(d)(13) for the time period up to and including December 31, 2027. After this date, ONC-ACBs will no longer be required to obtain a record of updates from health IT developers to describe MFA use cases. Additionally, we propose to apply the updated MFA requirements to each of the certification criteria in Sec. 170.315(b)(3), (e)(1), (g)(10), and (g)(30). Specifically, in Sec. Sec. 170.315(b)(3)(ii)(G), 170.315(e)(1)(iii), 170.315(g)(10)(ii)(A)(1)(iii), and 170.315(g)(30)(ii)(C) we propose to include a requirement that on and after January 1, 2028, Health IT Modules certified to any of these criteria are also certified to Sec. 170.315(d)(13)(ii). Given our proposal to embed Sec. 170.315(d)(13) references into the certification criteria we propose requiring MFA support in, Sec. 170.315(d)(13) does not need to also be referenced in Sec. 170.550(h)(3)(i) through (ix). Therefore, we propose to expire all the references to Sec. 170.315(d)(13) in Sec. 170.550(h)(3)(i) through (ix) by time-limiting the applicability of Sec. 170.315(d)(13) in Sec. 170.550(h)(3)(i) [[Page 63575]] through (ix) for the time period up to and including December 31, 2027. We clarify that Health IT Modules certified to Sec. 170.315(g)(10) and Sec. 170.315(g)(30), on and after January 1, 2028, would be required to support MFA for patient scopes or patient-facing authentication use cases, rather than non-patient (i.e., clinical user) and system-level use cases. We also clarify that Health IT Modules certified to Sec. 170.315(b)(3) on and after January 1, 2028, would have the option of meeting the requirement to support MFA in this certification criterion by supporting user level MFA for electronic prescribing of a controlled substance.\183\ With respect to Health IT Modules certified to Sec. 170.315(b)(3) that do not support electronic prescribing of a controlled substance, we propose that they must still demonstrate support for MFA for some other user authentication use case. We welcome comment on these proposals. We also request comment on whether we should consider in the final rule exempting Health IT Modules from the MFA requirement when they are only designed to support non-controlled substance electronic prescribing. We would also appreciate any statistics, if available, on the market segment that would be affected by this specific policy. --------------------------------------------------------------------------- \183\ Multi-factor authentication for electronic prescribing of controlled substances is required to meet the Electronic Prescribing of Controlled Substances (EPCS) requirements set by Drug Enforcement Administration (DEA). --------------------------------------------------------------------------- Finally, we propose to modify Sec. 170.550(h)(3)(viii) to require that Health IT Modules certified to Sec. 170.315(g)(20) and (g)(30) through (36), in addition to Sec. 170.315(g)(7) through (g)(10) as is currently required, are also certified to the certification criteria specified in Sec. 170.315(d)(1), (9), (12), and, for the time period up to and including December 31, 2027, Sec. 170.315 (d)(13); and (d)(2)(i)(A) and (B), (d)(2)(ii) through (v), or (10). We similarly propose, in Sec. 170.550(h)(3)(x), that Health IT Modules certified to any criterion proposed in Sec. 170.315(j) are also certified to the certification criteria specified in Sec. 170.315(d)(1), (d)(2)(i)(A) and (B), (d)(2)(ii) through (v), (d)(3), and (12). We welcome comment on this proposal including whether we should require testing for Sec. 170.315(d)(13) in any of the certification criteria in Sec. 170.315(j). 18. Revised Computerized Provider Order Entry--Laboratory Criterion The laboratory-based workflow is initiated when a clinician orders a test (such as part of a routine screening or a diagnostic work up). If the clinician does not provide all of the information requested in the test order, or if the test order does not request specific data, the laboratory or the public health authority receiving the laboratory results will not have complete information. Such missing information could include patient demographics, creating gaps in understanding and addressing issues related to health equity, in addition to direct issues with contact tracing and patient outreach that could slow down the spread of infectious disease. Laboratory orders are often initiated in EHR systems when ordered by clinicians practicing in hospitals or large healthcare organizations. The laboratory provides the results from the test back to the ordering clinician by various means via their Laboratory Information Management Systems (LIMS) or Laboratory Information Systems (LIS). Ensuring that systems that create orders are also capable of transmitting orders and receiving associated results and values back electronically, according to national standards, will create more complete patient information available to clinicians throughout the laboratory workflow. We propose to revise the ``computerized provider order entry-- laboratory'' certification criterion in Sec. 170.315(a)(2) by requiring Health IT Modules certified to this criterion to create and transmit laboratory orders electronically, to be performed according to the Lab Orders Interface (LOI) Implementation Guide proposed at 170.205(g)(2) and the Lab Results Interface (LRI) Implementation Guide proposed in Sec. 170.2015(g)(3). Specifically, we propose to implement our proposed revisions by moving our existing Sec. 170.315(a)(2) requirements into paragraphs Sec. 170.315(a)(2)(i) that expire on January 1, 2026, and by including new standards-based requirements for lab orders in Sec. 170.315(a)(2)(ii) that must be met on and after January 1, 2028. We propose to revise Sec. 170.315(a)(2) by establishing a new subparagraph in Sec. 170.315(a)(2)(ii) to include requirements for Health IT Modules certified to Sec. 170.315(a)(2) to enable a user to create and transmit laboratory orders electronically, to be performed according to the LOI Implementation Guide (Sec. 170.205(g)(2)) cross- referenced in Sec. 170.315(a)(2)(ii)(B). We further propose to require Health IT Modules certified to Sec. 170.315(a)(2) to enable a user to receive and validate laboratory results according to the LRI Implementation Guide (Sec. 170.205(g)(3)) cross-referenced in Sec. 170.315(a)(2)(ii)(C). As discussed in our proposals relevant to Sec. 170.315(f)(3), in section III.B.13.d., the LRI and LOI IGs reduce some of the optionality that is present in currently implemented specifications, which may improve the completeness of information. For example, the LRI and LOI implementation guides require ordering provider, patient address, patient phone number, and patient race. Further, the LRI IG aligns with Clinical Laboratory Improvement Amendments of 1988 (CLIA) requirements in place for laboratories. The update to these specifications, and the inclusion of the receipt of orders in Sec. 170.315(f)(3), as well as the receipt of results in Sec. 170.315(a)(2), ensure that functions throughout the lifecycle of the laboratory order, from entry, to result, to reporting to public health authority, is covered by electronic requirements with the associated national standard. We propose that for the time period up to and including December 31, 2027, a Health IT Module certified to Sec. 170.315(a)(2) must meet either the requirements specified in paragraph (a)(2)(i), or the requirements specified in paragraph (a)(2)(ii). On and after January 1, 2028, for Health IT Modules certified to Sec. 170.315(a)(2), we propose that such Health IT Modules must meet the requirements specified in paragraph (a)(2)(ii). We welcome comment on these proposals. 19. Revised Standardized API for Patient and Population Services Criterion To Align With Modular API Capabilities As part of our overall proposal, we propose to revise the structure of the regulation text in Sec. 170.315(g)(10) for clarity as well as phrasing consistency with other proposed API certification criteria in this proposed rule (e.g., the proposed applicable Sec. 170.315(j) criteria). These revisions to the regulation text's structure are intended to improve readability and how the certification criterion's requirements are organized. Generally, these specific reorganizing revisions are not intended to introduce substantive changes to current conformance requirements. A notable exception is the proposed reference to certification criterion requirements proposed in Sec. 170.315(j)(10)(ii), which would be a new requirement for user authorization revocation. We also note that we have included proposals that introduce new, substantive requirements as well to Sec. 170.315(g)(10) with applicable conformance timing. These details are discussed below and, as applicable, [[Page 63576]] proposed Sec. 170.315(j) certification criteria requirements will be discussed along with current and proposed Sec. 170.315(g)(10) requirements to show a complete view of all proposed revisions to the Sec. 170.315(g)(10) certification criterion's regulation text. We propose to revise the Sec. 170.315(g)(10) certification criterion to reference applicable proposed Sec. 170.315(j) certification criteria to make the regulation text of Sec. 170.315(g)(10) more concise, clear, and consistent with the other proposed API certification criteria. In section III.B.16 of this proposed rule, we discuss our proposal to add a new category of certification criteria in Sec. 170.315(j) titled ``Modular API capabilities.'' The Sec. 170.315(j) certification criteria, if finalized, would allow for specific API certification requirements to be demonstrated independently or in different combinations through the Program in circumstances where meeting all of Sec. 170.315(g)(10)'s requirements would not be applicable. These proposed changes, taken together, would help the Program support APIs across clinical, public health, administrative, and other use cases. a. Proposed Revisions for Registration We propose to reorganize and rephrase the application registration requirements currently in Sec. 170.315(g)(10)(iii). The current application registration requirements in Sec. 170.315(g)(10)(iii) require support for an application to register with the Health IT Module's ``authorization server'' to support retrieval of data for a single patient's data and multiple patients' data. No standard is currently specified for registration. We propose to rename Sec. 170.315(g)(10)(i) as ``Registration,'' and move the existing application registration requirements from Sec. 170.315(g)(10)(iii) to Sec. 170.315(g)(10)(i). We also propose to clarify in Sec. 170.315(g)(10)(i) which app types are currently required to be supported for functional registration (confidential and public apps). Clarifying these app types required for functional registration does not introduce new requirements since confidential and public apps were already required to be supported for functional registration according to the current requirements in Sec. 170.315(g)(10)(iii). We note that we propose to no longer specifically reference the ``confidential app'' profile from the SMART App Launch implementation guide in the Sec. 170.315(g)(10) certification criterion. Instead, we propose to refer to the app types of ``confidential app'' and ``public app'' as described in the section of this rule titled ``SMART App Launch 2.2.'' In addition to this move and clarification, we also propose that on and after January 1, 2028, both the capabilities proposed in Sec. 170.315(g)(10)(i)(A) and (B) would be required to support the full scope of API capabilities required in the Sec. 170.315(g)(10) certification criterion. This includes as part of the regulation text reordering new proposed language in Sec. 170.315(g)(10)(i)(A) to reference Sec. 170.315(j)(1) to support ``functional registration'' and new proposed language in Sec. 170.315(g)(10)(i)(B) to reference Sec. 170.315(j)(2) to support ``dynamic registration.'' We clarify that the capability described at proposed Sec. 170.315(g)(10)(i)(A) is not intended to substantively change the application registration requirements with which health IT developers are currently familiar, but instead clarify the nature of the functional requirements and detail which app types are required to be supported for functional registration (confidential and public apps). To accommodate the distinct proposal to require dynamic client registration as part of Sec. 170.315(g)(10), the proposed Sec. 170.315(g)(10)(i)(B) focuses on dynamic client registration for patient and user access as proposed in Sec. 170.315(g)(10)(ii) and system access at (iii). b. Proposed Revisions for Patient and User Access In the context of retrieving data for a single patient, we propose to restructure and rephrase the data response requirements currently in Sec. 170.315(g)(10)(i)(A), supported search operations requirements in Sec. 170.315(g)(10)(ii)(A), secure connection requirements in Sec. 170.315(g)(10)(iv)(A), authentication and authorization for patient and user scopes requirements in Sec. 170.315(g)(10)(v)(A), and patient authorization revocation requirements in Sec. 170.315(g)(10)(vi). We propose reorganizing those requirements to all be under proposed Sec. 170.315(g)(10)(ii) to make clear which requirements support data retrieval for a single patient's data. Specifically, we propose to rename Sec. 170.315(g)(10)(ii) to be ``Patient and user access'' and include these paragraphs as follows. We propose to revise the paragraph in Sec. 170.315(g)(10)(ii)(A) and add subparagraphs in Sec. 170.315(g)(10)(ii)(A)(1) and (2) to include, with revisions, the requirements for secure connection currently in Sec. 170.315(g)(10)(iv)(A), authentication and authorization for patient and user scopes currently under Sec. 170.315(g)(10)(v)(A), and patient authorization revocation requirements currently in Sec. 170.315(g)(10)(vi). We also propose to add a multi- factor authentication requirement in Sec. 170.315(g)(10)(ii)(A)(1)(iii) for patient-facing uses. The specific alignment between current regulatory text paragraphs and proposed new paragraphs is detailed in each of the bullets that follow. Proposed Sec. 170.315(g)(10)(ii)(A)(1)(i), Sec. 170.315(g)(10)(ii)(A)(2)(i), and Sec. 170.315(g)(10)(ii)(B)(1) maintain the existing requirement in Sec. 170.315(g)(10)(iv)(A) to support a secure connection and authentication and authorization for apps requesting patient and user scopes according to the SMART App Launch and US Core implementation guides. We propose to no longer explicitly mention ``secure connection'' since we believe it is redundant as the referenced implementation guides already include such requirements for secure connections. The ``App Protection'' section of the SMART App Launch IG requires the use of secure TLS connections and is required as part of the requirements at proposed Sec. 170.315(g)(10)(ii)(A)(1)(i) and Sec. 170.315(g)(10)(ii)(A)(2)(i) by reference to proposed Sec. 170.315(j)(9) and Sec. 170.315(j)(10)(i) respectively. Proposed Sec. 170.315(j)(9) and Sec. 170.315(j)(10)(i) require support for authorization according to capabilities from one of the SMART App Launch IGs adopted in Sec. 170.215(c), which in turn necessitates the use of secure TLS connections as required in the ``App Protection'' section of the SMART App Launch IG. Additionally, the ``Security'' section of the US Core IG requires the use of secure TLS connections and is required as part of the requirements at proposed Sec. 170.315(g)(10)(ii)(B)(1). Proposed Sec. 170.315(g)(10)(ii)(B)(1) requires support for responding to requests for patient data according to the one of the US Core IGs adopted in Sec. 170.215(b)(1), which in turn necessitates the use of secure TLS connections as required in the ``Security'' section of the US Core IG. We propose to revise the organization of authentication and authorization requirements for patient-facing apps and use-facing apps for Sec. 170.315(g)(10) to be under Sec. 170.315(g)(10)(ii)(A). We propose authentication and authorization requirements for patient access to be under Sec. 170.315(g)(10)(ii)(A)(1) and authentication and authorization requirements for user access be under [[Page 63577]] Sec. 170.315(g)(10)(ii)(A)(2). The proposed revisions in Sec. 170.315(g)(10)(ii)(A)(1)(i) and Sec. 170.315(g)(10)(ii)(A)(2)(i) maintain the requirements currently in Sec. 170.315(g)(10)(v)(A) for authentication and authorization for patient and user scopes (scopes being information access permissions as represented in the OAuth 2.0 Authorization Framework) according to SMART App Launch capabilities as currently referenced in Sec. 170.215(c) and OpenID Connect Core as currently referenced in Sec. 170.215(e). The proposed revisions in Sec. 170.315(g)(10)(ii)(A)(1)(i) reference the proposed certification criterion in Sec. 170.315(j)(9) ``SMART patient access for standalone apps,'' which requires the SMART App Launch capabilities that are currently required to be supported for authentication and authorization of patient-facing apps. The proposed revisions in Sec. 170.315(g)(10)(ii)(A)(2)(i) reference the proposed certification criterion in Sec. 170.315(j)(10) ``SMART clinician access for EHR launch,'' which requires the SMART App Launch capabilities currently required for authentication and authorization of user-facing apps. Current OpenID Connect Core requirements would also be maintained by the proposed references to Sec. 170.315(j)(9) ``SMART patient access for standalone apps'' and (10) ``SMART clinician access for EHR launch'' since those proposed certification criteria require the ``sso- openid-connect'' SMART App Launch capability by requiring the ``Single Sign-on'' section of one of the SMART App Launch IGs adopted in Sec. 170.215(c). In addition to maintaining current requirements from Sec. 170.315(g)(10)(v)(A) for authentication and authorization for patient and user scopes, the proposed references in the Sec. 170.315(g)(10) certification criterion to Sec. 170.315(j)(9) and (10) would also add requirements to support SMART App Launch capabilities for authentication and authorization for patient-facing apps and user- facing apps according to the implementation specification of SMART App Launch 2.2.0, proposed in this rule to be adopted in Sec. 170.215(c)(3). The proposed certification criteria in Sec. 170.315(j)(9) and (10) would also include conformance dates for each set of required SMART capabilities. Conformance to each set of required SMART capabilities would be in alignment with the following: (1) expiration of SMART App Launch 1.0.0, adopted in Sec. 170.215(c)(1), for use in the Program on January 1, 2026 as finalized in the HTI-1 Final Rule (89 FR 1292); (2) the proposed expiration of SMART App Launch 2.0.0, adopted in Sec. 170.215(c)(2), for use in the Program on January 1, 2028; and (3) the proposed adoption of SMART App Launch 2.2.0 in Sec. 170.215(c)(3). Please see the section titled ``SMART App Launch 2.2'' of this rule for additional details regarding the proposed expiration and adoption of SMART App Launch 2.0.0 and 2.2.0 respectively. For more information regarding how SMART App Launch capabilities as currently required and proposed to be required correspond to the proposed certification criteria in Sec. 170.315(j)(9) and (10), including specific capabilities and their conformance dates, please refer to section III.B.16 ``New Certification Criteria for Modular API Capabilities.'' The requirements currently in Sec. 170.315(g)(10)(v)(A)(1)(ii), Sec. 170.315(g)(10)(v)(A)(1)(iii), and Sec. 170.315(g)(10)(v)(A)(2) regarding the issuance of refresh tokens are mirrored in the proposed paragraphs in Sec. 170.315(g)(10)(ii)(A)(1)(i) and (2)(ii) via cross references to the certification criteria proposed in Sec. 170.315(j)(9) ``SMART patient access for standalone apps'' and (10) ``SMART clinician access for EHR launch'' respectively, which reference the proposed certification criterion in Sec. 170.315(j)(6) ``SMART App Launch user authorization,'' wherein the language has been simplified to consolidate existing refresh token requirements and remove extraneous references to refresh token requirements already included in referenced implementation guides. Additionally, we include the authentication and authorization requirements that are currently in Sec. 170.315(g)(10)(ii)(A)(1)(i) and (ii) in our proposals in Sec. 170.315(g)(10)(ii)(A)(1) ``Authentication and authorization for patient access'' and (2) ``Authentication and authorization for user access,'' which reference the proposed criteria at Sec. 170.315(j)(9) ``SMART patient access for standalone apps'' and (10) ``SMART clinician access for EHR launch,'' which both reference the proposed certification criterion in Sec. 170.315(j)(6) ``SMART App Launch user authorization.'' We reiterate the existing conformance expectations established in the COVID-19 Public Health Emergency Interim Final Rule (85 FR 70076) that health IT developers can determine the method(s) they use to support interactions with native apps and that health IT developers are not required to support all methods that third-party application developers seek to use. Further, we propose to revise the requirements that enable persistent access to confidential apps on subsequent connections which are currently required in Sec. 170.315(g)(10)(v)(A)(2)(ii) to instead require support for a user to enable for confidential apps persistent access to patient information without requiring user re-authentication or re-authorization until authorization revocation at the user's direction. Additionally, we propose moving this requirement to part of one of the modular API capabilities in (j), specifically in Sec. 170.315(j)(6)(iii). As proposed, Sec. 170.315(j)(6)(iii) is referenced by the proposed certification criteria in Sec. 170.315(j)(9) ``SMART patient access for standalone apps'' and (10) ``SMART clinician access for EHR launch,'' which are referenced by the proposed revised certification criterion in Sec. 170.315(g)(10). Revising the requirement in this manner is intended to provide developers more flexibility in implementing persistent access for confidential apps while maintaining the requirement that patients and users can authorize persistent access to patient data to confidential apps until revoking that access. We propose to move the current ``patient authorization revocation'' requirement in Sec. 170.315(g)(10)(vi) to Sec. 170.315(j)(6) ``SMART App Launch user authorization,'' specifically Sec. 170.315(j)(6)(iv) ``User authorization revocation.'' These requirements are referenced by the proposed certification criterion in Sec. 170.315(j)(9) ``SMART patient access for standalone apps'' which is referenced by the proposed revised certification criterion in Sec. 170.315(g)(10)(ii)(A)(1)(i). We propose a new requirement to require support for user authorization revocation in Sec. 170.315(g)(10)(ii)(A)(2)(i) which references the requirements at the proposed certification criterion in Sec. 170.315(j)(10)(ii), and is proposed to take effect on and after January 1, 2028. This would require a Health IT Module's authorization server to be able to revoke and must revoke an authorized application's access at a user's direction within 1 hour of the request. This is distinct from the existing patient authorization revocation requirement currently in Sec. 170.315(g)(10)(vi) and proposed in Sec. 170.315(j)(6)(iii) which requires support for revocation of a patient's authorization but does not require support for revocation of a clinician's authorization. We propose introducing this requirement in Sec. 170.315(g)(10)(ii)(A)(2)(i) to support revocation of clinician authorizations to enable clinicians to have greater control [[Page 63578]] over their authorizations for applications to access patient data. We propose new requirements for authentication for dynamically registered patient-facing and user-facing apps in Sec. 170.315(g)(10)(ii)(A)(1)(ii) and (2)(ii) respectively, with a compliance date on and after January 1, 2028. We refer readers to the ``Revision of Standardized API for Patient and Population Services to Support Dynamic Client Registration'' in section III.B.15.c of this proposed rule for additional details of the proposed Sec. 170.315(g)(10) requirements for authentication and authorization of dynamically registered patient-facing apps and dynamically registered user-facing apps. The proposed revisions in Sec. 170.315(g)(10)(ii)(A)(1)(iii) would require multi-factor authentication to be supported for patient-facing authentication on and after January 1, 2028, according to the requirements specified in the proposal at Sec. 170.315(d)(13)(ii). We believe this update aligns with industry information security best practices, and that it is necessary to help better protect electronic health information. See the proposal for updating Sec. 170.315(d)(13) and referencing Sec. 170.315(d)(13)(ii) across certain certification criteria with authentication use cases at section III.B.17. We propose to reorganize as part of Sec. 170.315(g)(10)(ii)(B) the text for the current requirements for single patient data response currently in Sec. 170.315(g)(10)(i)(A) and single patient supported search operations requirements currently in Sec. 170.315(g)(10)(ii)(A), with proposed subparagraphs as follows: The proposed language in Sec. 170.315(g)(10)(ii)(B)(1) maintains the existing requirements for data response and search support but simplifies the language by consolidating references to implementation guides. As part of our revisions, we propose to no longer explicitly mention the requirement in the API certification criteria language regarding ``mandatory'' and ``must support'' because this was done for emphasis in our prior rulemaking and, we believe, consistent with long standing Program policy, that when we adopt standards and implementation specifications that all requirement aspects of those need to be addressed for conformance purposes. Additionally, to reflect our policy interests to advance imaging availability as described in section III.B.6, we propose to also include support for imaging links in Sec. 170.315(g)(10)(ii)(B)(1) indicating that imaging links must be supported as part of data response and search requirements on and after January 1, 2028. We also propose in Sec. 170.315(g)(10)(ii)(B)(2) that on and after January 1, 2028, support for the issuance of verifiable health records as specified by the requirements in proposed Sec. 170.315(j)(22) be supported. We propose requiring support for verifiable health records in Sec. 170.315(g)(10)(ii)(B)(2) to support the ability for patients to access their immunization and infectious disease-related laboratory test information in a format that is easily portable and verifiable by third parties, which is the underlying benefit of the SMART Health Card standard proposed as part of Sec. 170.315(j)(22). Proposed Sec. 170.315(g)(10)(ii)(B)(3) requires on and after January 1, 2028, support for subscriptions as a server for patient-facing apps and user-facing apps according to the requirements specified in Sec. 170.315(j)(23). We refer readers to subsequent section III.B.19.e for additional details about this proposal. c. Proposed Revisions for System Access We propose reorganizing under Sec. 170.315(g)(10)(iii) the data response requirements currently in Sec. 170.315(g)(10)(i)(B), supported search operations requirements currently in Sec. 170.315(g)(10)(ii)(B), secure connection requirements in Sec. 170.315(g)(10)(iv)(B), and authentication and authorization for system scopes requirements currently in Sec. 170.315(g)(10)(v)(B). We believe these proposals will make it more efficient to understand the requirements necessary to support data retrieval for multiple patients' data. Specifically, we propose to revise Sec. 170.315(g)(10)(iii) to be called ``System access'' and include the following paragraphs. We propose to organize authentication and authorization requirements for system access under the paragraph in Sec. 170.315(g)(10)(iii)(A). We propose to add a paragraph in Sec. 170.315(g)(10)(iii)(A)(1) which, by reference to the proposed certification criterion in Sec. 170.315(j)(7), maintains requirements for secure connection currently in Sec. 170.315(g)(10)(iv)(B) and authentication and authorization for system scopes in accordance with the ``SMART Backend Services: Authorization Guide'' currently in Sec. 170.315(g)(10)(v)(B). We do not include specific mention of ``secure connection'' in the proposed paragraphs in Sec. 170.315(g)(10)(iii)(A)(1) or Sec. 170.315(j)(7) since we believe it is redundant as the referenced implementation guides already include such requirements for secure connections. The proposed paragraph in Sec. 170.315(g)(10)(iii)(A)(1) maintains the existing system authentication and authorization requirements currently in Sec. 170.315(g)(10)(v)(B) by referencing the proposed Sec. 170.315(j)(7) certification criterion. Proposing to require conformance to the proposed Sec. 170.315(j)(7) certification criterion maintains the requirements for SMART Backend Services while using consistent language across API certification criteria in the Program. The Sec. 170.315(j)(7) certification criterion also facilitates reference to the updated location of the SMART Backend Services specification, which has been moved from the Bulk Data Access guide to the SMART App Launch guide in subsequent versions of those guides. We also propose to include language in Sec. 170.315(g)(10)(iii)(A)(1) which clarifies that authentication and authorization for system access in accordance with SMART Backend Services is only required for functionally registered system apps. Proposed Sec. 170.315(g)(10)(iii)(A)(2) would support the dynamic registration proposal described in section III.B.15.c of this proposed rule to support authentication and authorization of dynamically registered system apps. The paragraph in Sec. 170.315(g)(10)(iii)(A)(2) describes the new proposed requirements to support authentication and authorization for dynamically registered system apps according to the ``Business-to-Business'' section of the UDAP Security IG v1 proposed in Sec. 170.215(o) and proposes that a Health IT Module certifying to Sec. 170.315(g)(10) must support the specified sections of the UDAP Security IG v1 on and after January 1, 2028 for system apps dynamically registered using the capabilities in proposed Sec. 170.315(g)(10)(i)(B). We refer readers to the ``Revision of Standardized API for Patient and Population Services to Support Dynamic Client Registration'' in section III.B.15.c of this proposed rule for additional details of the proposed Sec. 170.315(g)(10) requirements for authentication and authorization of dynamically registered system apps. We propose to organize system information access requirements under proposed paragraph Sec. 170.315(g)(10)(iii)(B). We propose to maintain the data response requirements currently in Sec. 170.315(g)(10)(i)(B) and include those requirements in proposed Sec. 170.315(g)(10)(iii)(B)(2) and (i). We note that the existing supported search operations requirements at current Sec. 170.315(g)(10)(ii)(B) are not applicable [[Page 63579]] to the export of multiple patients' data according to the Bulk Data Access implementation guide adopted under Sec. 170.215(d), since search requests are not distinct from the data export requests as defined in that guide. As a result, we propose to remove the existing requirements language currently in Sec. 170.315(g)(10)(ii)(B) but do not anticipate any change to the substance of the Sec. 170.315(g)(10) certification criterion requirements given such requirements are subsumed by the data response requirements proposed in Sec. 170.315(g)(10)(iii)(B)(2) and (i). The proposed language in Sec. 170.315(g)(10)(iii)(B)(2) and (i) maintains the existing requirements for data response but simplifies the language by removing redundant language for requirements already required through reference to implementation guides and thus as we noted above, we have removed the explicit reference to ``mandatory'' and ``must support'' in this revised paragraph. Additionally, to reflect our policy interests to advance imaging availability as described in section III.B.6, we propose to also include support for imaging links in Sec. 170.315(g)(10)(iii)(B)(2) and (i) indicating that imaging links must be supported as part of data response requirements for multiple patients on and after January 1, 2028. The requirements as proposed at and under Sec. 170.315(g)(10)(iii)(B)(2) are rephrased such that the Bulk Data Access implementation guide features required for the Sec. 170.315(g)(10) certification criterion (e.g., group export) are explicitly enumerated in the criterion instead of in the reference to Bulk Data Access implementation guide in Sec. 170.215(d). Also, to accommodate the distinct proposal to support the ``_type'' query parameter in Sec. 170.315(g)(10) described in section III.B.14 of this rule, we propose adding paragraph Sec. 170.315(g)(10)(iii)(B)(2)(ii) indicating that parameter must be supported. Both the ``_type'' query parameter and use of the parameter to support bulk data retrieval of imaging links would need to be supported on and after January 1, 2028.We propose that the paragraph in Sec. 170.315(g)(10)(iii)(B)(1) requires support to respond to requests from system apps for patient data consistent with the search criteria included in the FHIR standard adopted in Sec. 170.215(b) and one of the US Core IGs as adopted in Sec. 170.215(b)(1) for each of the data classes and data elements included in at least one of the versions of the USCDI standard adopted in Sec. 170.213 and, on and after January 1, 2028, imaging links. We refer readers to subsequent section III.B.19.e for additional details about this proposal. Proposed Sec. 170.315(g)(10)(iii)(B)(3) requires on and after January 1, 2028, support for subscriptions as a server for system apps according to the requirements specified in Sec. 170.315(j)(23). We refer readers to subsequent section III.B.19.e for additional details about this proposal. d. Other Restructured Requirements We propose to continue to require the token introspection requirements currently in Sec. 170.315(g)(10)(vii) by moving such requirements language to the proposed Sec. 170.315(j)(6) and (7) API certification criteria, and then referencing those criteria directly or indirectly where appropriate in the Sec. 170.315(g)(10) certification criterion. The existing token introspection requirements apply to tokens issued for both patient and user scopes, and system scopes. Thus, we propose in Sec. 170.315(g)(10)(ii)(A)(1)(i) to continue to require token introspection for tokens issued to patient-facing apps by referencing Sec. 170.315(j)(9), which references Sec. 170.315(j)(6). Next, we propose in Sec. 170.315(g)(10)(ii)(A)(2)(i) to continue to require token introspection for user-facing apps by referencing Sec. 170.315(j)(10), which references Sec. 170.315(j)(6). Next, we propose in Sec. 170.315(g)(10)(iii)(A)(1) to continue to require token introspection for system apps by referencing Sec. 170.315(j)(7). Furthermore, we propose a new requirement in Sec. 170.315(g)(10)(iii)(A)(2), by requiring conformance to Sec. 170.315(j)(8) on and after January 1, 2028, to require token introspection according to the SMART App Launch implementation guide for dynamically registered system apps on and after January 1, 2028. Lastly, we propose to move the API documentation requirements currently required in Sec. 170.315(g)(10)(viii) to the API Conditions and Maintenance of Certification requirements in Sec. 170.404(a)(2)(i), which would result in this paragraph no longer being part of Sec. 170.315(g)(10) as part of the overall revision to this certification criterion. We do not intend to introduce new documentation requirements for the Sec. 170.315(g)(10) certification criterion with this proposal. Instead, the goal of this proposal is to consolidate API documentation requirements across the Program where possible as described in additional detail in section III.B.20.d. We seek comment on the proposed revisions we have discussed for Sec. 170.315(g)(10). e. Proposed Requirements for System Read and Search API, Subscriptions, and Workflow Triggers for Decision Support Interventions We propose several new requirements for the Standardized API for Patient and Population Services certification criterion in Sec. 170.315(g)(10) to support enhanced interoperability and advanced workflows to overall reduce developer burden and barriers to accessing and utilizing patient health information. We propose support for a ``Read and search API'' for system access in Sec. 170.315(g)(10)(iii)(B)(1), HL7 FHIR subscriptions for patient and user access in Sec. 170.315(g)(10)(ii)(B)(3) and system access in Sec. 170.315(g)(10)(iii)(B)(3), and workflow triggers for decision support interventions in Sec. 170.315(g)(10)(iv), as described further below. We previously only required Health IT Modules certified to Sec. 170.315(g)(10) to support the ``Bulk FHIR API'' for system access, and only required the US Core IG read and search capabilities for patient and user scopes. We propose to include a read and search API according to the ``US Core Server CapabilityStatement'' for each of the data classes and data elements included in at least one of the versions of the USCDI standard adopted in Sec. 170.213 in Sec. 170.315(g)(10)(iii)(B)(1) in order to explicitly require that certified Health IT Modules support system applications to perform read and search operations for patient health information using a standardized API. The proposal includes optional support for imaging links requests as of the effective date of the rule. On and after January 1, 2028, requests for imaging links must be supported. We propose support for HL7 FHIR subscriptions as part of the Standardized API for Patient and Population Services for patient and user access in Sec. 170.315(g)(10)(ii)(B)(3) and for system access in Sec. 170.315(g)(10)(iii)(B)(3). The proposals require Health IT Modules to support subscriptions as a server according to the requirements specified in Sec. 170.315(j)(23), which includes several infrastructure capabilities to support HL7 FHIR Subscriptions and a list of HL7 FHIR Resources that must be supported for subscription notifications and accompanying data elements that must be supported for subscription filtering. The proposed certification criterion in Sec. 170.315(j)(23) is discussed further in this rule in section III.B.15.b.iii. We propose to require support for workflow triggers for decision support interventions under proposed [[Page 63580]] Sec. 170.315(g)(10)(iv). We propose that the Health IT Module must support capabilities in Sec. 170.315(j)(20) (where we have proposed to adopt the ``workflow triggers for decision support interventions'' certification criterion) to enable workflow triggers to call decision support services, including support for ``patient-view'' and ``order- sign'' CDS Hooks according to at least one of the versions of the implementation specification adopted in Sec. 170.215(f)(1). We propose support for ``patient-view'' and ``order-sign'' because these CDS Hooks are at maturity level ``5--Mature'' according to the CDS Hooks IG and can be used to support a wide variety of workflow processes. We further clarify and propose in 170.315(g)(10)(iv) that developers may support workflow triggers for decision support interventions for the time period up to and including December 31, 2027 and must support workflow triggers for decision support interventions on and after January 1, 2028. 20. Patient, Provider, and Payer APIs In this section, we propose to adopt a set of certification criteria in Sec. 170.315(g)(30)-(36) to support data exchange between health care payers, providers, and patients. These proposed certification criteria would enable the exchange of data including clinical and coverage information, drug formulary information, and prior authorization information, between patients, providers, and payers as appropriate to each exchange. These proposed certification criteria are based on a series of recent policies finalized by CMS which we describe in detail in the following section. If finalized, these certification criteria would be available for health IT developers (which may include payers and other developers providing technology to payers) seeking voluntary certification for health IT products supporting these use cases. a. Background on CMS Interoperability Rulemaking On May 1, 2020, the ``Medicare and Medicaid Programs; Patient Protection and Affordable Care Act; Interoperability and Patient Access for Medicare Advantage (MA) Organization and Medicaid Managed Care Plans, State Medicaid Agencies, CHIP Agencies and CHIP Managed Care Entities, Issuers of Qualified Health Plans on the Federally- Facilitated Exchanges, and Health Care Providers'' final rule (85 FR 25510) was published in the Federal Register (hereinafter referred to as the ``CMS Interoperability and Patient Access Final Rule''). CMS required impacted payers \184\ to implement and maintain a FHIR-based Patient Access API to allow patients, through the health application of their choice, to easily access their claims and encounter information as well as clinical data, including laboratory results, and provider remittances and enrollee cost-sharing pertaining to such claims, if maintained by the impacted payer (85 FR 25559). CMS also required impacted payers to implement a Provider Directory API to make available information such as contracted provider names, addresses, and phone numbers (85 FR 25563). --------------------------------------------------------------------------- \184\ For the purposes of the CMS Interoperability and Patient Access and Interoperability and Prior Authorization Final Rules discussed in this section, impacted payers include Medicare Advantage (MA) organizations, state Medicaid fee-for-service (FFS) programs, state Children's Health Insurance Program (CHIP) FFS programs, Medicaid managed care plans, CHIP managed care entities, and Qualified Health Plan (QHP) issuers on the Federally-facilitated Exchanges (FFEs). --------------------------------------------------------------------------- On February 8, 2024, the ``Medicare and Medicaid Programs; Patient Protection and Affordable Care Act; Advancing Interoperability and Improving Prior Authorization Processes for Medicare Advantage Organizations, Medicaid Managed Care Plans, State Medicaid Agencies, Children's Health Insurance Program (CHIP) Agencies and CHIP Managed Care Entities, Issuers of Qualified Health Plans on the Federally- Facilitated Exchanges, Merit-Based Incentive Payment System (MIPS) Eligible Clinicians, and Eligible Hospitals and Critical Access Hospitals in the Medicare Promoting Interoperability Program'' (CMS Interoperability and Prior Authorization Final Rule) was published in the Federal Register (89 FR 8758). Final policies in this rule included: expanding the content available via the existing Patient Access API to include information about prior authorizations; requiring impacted payers to implement and maintain a Provider Access API to make patient data available to in-network providers with whom the patient has a treatment relationship; and requiring impacted payers build and maintain a Payer-to-Payer API to exchange patient data when a patient moves between payers or has concurrent payers. CMS also required impacted payers to implement and maintain a Prior Authorization API to facilitate electronic prior authorization processes. Finally, the rule added electronic prior authorization measures to the Medicare Promoting Interoperability Program and the MIPS Promoting Interoperability performance category. In the CMS Interoperability and Patient Access Final Rule (85 FR 25510 through 25640) and the CMS Interoperability and Prior Authorization Final Rule (89 FR 8758 through 8988), CMS requires impacted payers to use certain standards and implementation guides which ONC has adopted in Sec. 170.215, as well as the USCDI standard in Sec. 170.213. Specifically, CMS has finalized technical requirements for the following APIs: Patient Access API (85 FR 25558 through 25559, 89 FR 8784 through 8787), Provider Access API (89 FR 8817 through 8820), Payer-to-Payer API (89 FR 8855 through 8856), Prior Authorization API (89 FR 8897 through 8901), and the Provider Directory API (85 FR 25563 through 25564). In the CMS Interoperability and Prior Authorization Final Rule, CMS also recommended a number of implementation guides that may be used to support effective implementation of the required payer APIs (89 FR 8945). b. Proposal Overview We propose certification criteria below in Sec. 170.315(g)(30)- (36) for Health IT Modules that can be used to support more effective exchange of clinical, coverage, and prior authorization information. The proposed certification criteria, if finalized, would support the availability of health IT that can enable payers and health care providers to meet requirements established in the Interoperability and Patient Access Final Rule (85 FR 25522 through 25569) and the Interoperability and Prior Authorization Final Rule (89 FR 8768 through 8946). As part of the proposals below, we include further discussion of how each proposed certification criterion would support the availability of information and enable functionality CMS has identified as part of corresponding requirements. We intend to continue to work with CMS in the future to ensure Health IT Modules certified to the proposed criteria in Sec. 170.315(g)(30)-(36) enable efficient and effective support for CMS policies. In general, we believe that use of technology meeting these certification criteria would help to enable exchange of information that promotes a more effective marketplace, increases competition, and provides benefits to patients, including: increased consumer choice, improved outcomes in healthcare services, and more robust care coordination through improved availability and exchange of health care provider information. Increased electronic exchange and automation of such information, as supported by the proposed certification criteria, would [[Page 63581]] enable patients to better manage their own care, allow providers to make more timely and informed treatment decisions, and reduce costs for both payers and providers by reducing the amount of manual intervention required in the exchange and authorization processes addressed by the proposed certification criteria. These proposed certification criteria reference a set of API implementation specifications that ONC proposes to adopt, on behalf of the Secretary, in Sec. 170.215(j), (k), (m), and (n).\185\ These specifications are based upon HL7[supreg] FHIR[supreg] R4. In concert with CMS, ONC has led or participated in a variety of activities related to monitoring and evaluating the standards and implementation specifications identified in this proposed rule, utilizing available mechanisms for gathering input on these standards from stakeholders and experts. Several of these proposed implementation specifications were developed by the HL7[supreg] Da Vinci Project.\186\ The Da Vinci Project is a private sector initiative that brings together payers, health IT developers, providers, and other public participants to facilitate the definition, design, and creation of use case specific reference implementations of solutions based upon the HL7 FHIR platform that involve managing and sharing clinical and administrative data between industry partners. Because the Da Vinci Project is aligned with HL7, solutions developed through the project may become industry standards. The Da Vinci Project's use case requirements, test scenarios, and test data, as well as the resulting implementation guides and reference implementations, are available without licensing requirements. --------------------------------------------------------------------------- \185\ For a more detailed discussion of APIs generally, we refer readers to the Application Programming Interfaces Condition of Certification and Maintenance of Certification preamble language in the ONC Cures Act Final Rule at 85 FR 25739. \186\ For more information about the Da Vinci Project, please visit https://www.hl7.org/about/davinci/. --------------------------------------------------------------------------- The proposed implementation specifications referenced in the proposed certification criteria in Sec. 170.315(g)(30)-(36) include the required and recommended implementation specifications identified in CMS' finalized policies for payer API requirements (89 FR 8945). We propose to adopt current versions of the IGs that CMS recommended in the CMS Interoperability and Prior Authorization Final Rule and propose to require these IGs as part of the certification criteria proposed in Sec. 170.315(g)(30)-(36). In the CMS Interoperability and Prior Authorization Final Rule, CMS discussed its approach to recommending, rather than requiring, certain IGs for payer APIs. CMS stated that its goal in recommending the specific IGs for each API was to provide directional guidance to the industry without locking payers into the versions available at the time of the CMS Interoperability and Prior Authorization proposed rule, due to the maturity of the versions available at that time (89 FR 8921). CMS sought to ensure that payers could use subsequent versions of those IGs without being restricted to those versions. CMS further stated that it intended to monitor IG development and would consider proposing to require versions of these IGs in future rulemaking (89 FR 8937). We believe that proposing to adopt the current versions of the IGs recommended by CMS in the rulemaking described above is appropriate for the proposed certification criteria at this time. Adopting and specifying use of these IGs is necessary to ensure that Health IT Modules certified to the criteria proposed in this section are implemented consistently and enable interoperable exchange of information. We also note that adoption of these IGs would support CMS policies established in their Interoperability and Prior Authorization Final Rule. Furthermore, if the adoption of these IGs is finalized, we would review and potentially approve future versions of these standards under the SVAP for voluntary use in the Program as they become available. The flexibility provided under the SVAP would ensure that developers are able to voluntarily update to later versions of these standards as future improvements are made, without waiting for updated versions to be proposed and finalized in regulation. In addition, we will continue to work with CMS to identify updated versions of these standards for potential future adoption in regulation at appropriate intervals so that the adopted versions of standards are the most up-to- date available and are feasible for real-world implementation. The proposed certification criteria in Sec. 170.315(g)(30)-(36) also incorporate certification criteria for modular API capabilities proposed in Sec. 170.315(j) in section III.B.17 of this proposed rule, including capabilities for registration (Sec. 170.315(j)(1)-(2)), authentication and authorization (Sec. 170.315(j)(5)-(7)), workflow triggers for decision support interventions (Sec. 170.315(j)(20)- (21)), and subscriptions (Sec. 170.315(j)(23)-(24)). Below, we describe each certification criterion and our intent to certify Health IT Modules to these certification criteria to support interoperability. However, we note that the certification of any Health IT Module by a health IT developer is voluntary. The proposals in this proposed rule would not establish requirements for health IT beyond those Health IT Modules submitted for certification for these criteria under the Program, nor does the availability of these certification criteria require any individual or entity to use certified health IT, including payers subject to the CMS requirements. Our goal in proposing these certification criteria and the related implementation specifications is to support health IT developers building these capabilities (and customers implementing them) in a manner that is consistent with nationally recognized standards and supports testing and conformance to these standards through the ONC Health IT Certification Program. ONC's adoption of certification criteria, standards, and implementation specifications are part of an effort to advance a set of minimum technical requirements, increase the availability of health IT leveraging such requirements, and provide the healthcare community with an improved, interoperable health IT infrastructure. We reiterate that, if finalized, certification to these criteria would be available for health IT developers (which may include payers and other developers providing technology to payers) seeking voluntary certification and any requirements for a certification criterion are only required in the sense that they are necessary to achieve certification. ONC does not establish requirements for whether and in what ways patients, health care providers, payers or others use health IT. Instead, we enable the certification of Health IT Modules that may support a wide range of users. In this way, the Program helps to advance standards for certified Health IT Modules and increases the availability of interoperable health IT across healthcare and health related use cases. Finally, we note that CMS has not proposed to require that impacted payers subject to the API requirements in the CMS Patient Access and Interoperability and CMS Interoperability and Prior Authorization Final Rules obtain or implement Health IT Modules certified to the criteria in this proposed rule. We also note that CMS has not identified health IT certified to the ``prior authorization API--provider'' criterion proposed below in Sec. 170.315(g)(34) as necessary to complete the finalized electronic prior [[Page 63582]] authorization measures in the Medicare Promoting Interoperability Program and the Promoting Interoperability performance category of MIPS. If this certification criterion is finalized, we would work with CMS on appropriate updates to the Medicare Promoting Interoperability Program and the MIPS Promoting Interoperability performance category to identify health IT certified to this criterion as an element of CEHRT necessary to report on the electronic prior authorization measures. As CMS noted in the Interoperability and Prior Authorization Final Rule, use of health IT certified to support electronic prior authorization transactions can help to ensure that the actions associated with these measures are executed in a consistent fashion across the health care providers participating in these programs (89 FR 8802). c. Proposed Certification Criteria We propose to adopt the following new certification criteria for Patient, Provider, and Payer APIs: i. Patient Access API (Sec. 170.315(g)(30)) We propose to adopt a ``patient access API'' certification criterion in Sec. 170.315(g)(30) to specify requirements for Health IT Modules that can enable patients to access their health and administrative information by using a health application of their choice. While many of the requirements introduced in the ONC Cures Act Final Rule (85 FR 25642) expanded patient access to clinical information contained within health IT, such as EHRs, broadening this electronic access to include coverage and payer information can help expand the information available to help patients with decision-making. We propose in Sec. 170.315(g)(30)(i) to require support for two registration pathways for a Health IT Module certified to the ``patient access API'' criterion: a functional registration pathway for applications that are unable to meet the requirements for dynamic registration and a dynamic registration pathway for applications that can support automated, scalable registration. We propose in Sec. 170.315(g)(30)(i)(A) that the Health IT Module must support functional registration according to the requirements included in Sec. 170.315(j)(1) whereby confidential and public apps can register using a non-standardized method. We propose in Sec. 170.315(g)(30)(i)(B) to require the Health IT Module to support a dynamic registration pathway for confidential apps according to the requirements in Sec. 170.315(j)(2). We propose in Sec. 170.315(g)(30)(ii) to require authentication and authorization for patient access. To enable patients to authorize access to patient data by functionally and dynamically registered apps, we propose in Sec. 170.315(g)(30)(ii)(A) that the Health IT Module must support authentication and authorization according to the SMART App Launch IG during the process of granting access to patient data, according to the requirements in Sec. 170.315(j)(9). To enable authentication of dynamically registered apps, we propose in Sec. 170.315(g)(30)(ii)(B) that the Health IT Module must support asymmetric certificate-based authentication according to the requirements in Sec. 170.315(j)(5) for patient-facing apps dynamically registered using the capabilities in Sec. 170.315(g)(30)(i)(B). We refer readers to the proposals in sections III.B.16. (``New Certification Criteria for Modular API Capabilities'') and III.B.15. (``New Requirements to Support Dynamic Client Registration Protocol in the Program'') for more information about our proposed certification criteria in Sec. 170.315(j) and proposal for dynamic registration respectively. We propose later in this section that Certified API Developers with API technology certified to the criterion in Sec. 170.315(g)(30) would need to adhere to the API Condition and Maintenance of Certification requirements proposed in Sec. 170.404. This would mean that such developers would need to publish trust community information necessary for dynamic registration, as proposed in Sec. 170.404(b)(2)(iii). We propose in Sec. 170.315(g)(30)(ii)(C) to require multi-factor authentication for patient-facing authentication on and after January 1, 2028, as proposed in Sec. 170.315(d)(13)(ii) in section III.B.17. of this proposed rule. We believe this update is in line with industry information security best practice for an important authentication use case in health IT and that it is necessary to help better protect EHI. To make information available about a payer's list of preferred drugs, we propose in Sec. 170.315(g)(30)(iii) that the Health IT Module must publish information regarding the payer's drug formulary information according to at least one of the versions of the implementation specification adopted in Sec. 170.215(m), including the requirements described in the ``US Drug Formulary Server Capability Statement.'' We propose to adopt the HL7 FHIR[supreg] Da Vinci--Payer Data Exchange (PDex) US Drug Formulary Implementation Guide, Version 2.0.1--STU2 (PDex US Drug Formulary IG) \187\ in Sec. 170.215(m)(1) and incorporate it by reference in Sec. 170.299. We propose to adopt this implementation specification under PHSA section 3004 and make it available for HHS use. This implementation specification can enable consumers, members, and patients to understand the costs and alternatives for drugs that have been prescribed, and to compare their drug costs across different insurance plans. If we adopt subsequent versions of the PDex US Drug Formulary IG under the paragraph in Sec. 170.215(m), our proposals that require the use of at least one of the versions of the implementation specification adopted in Sec. 170.215(m) would enable health IT developers to use any version adopted at this location, unless we specify an ``expiration'' date which indicates a certain version of the specification may no longer be used after that date. --------------------------------------------------------------------------- \187\ See https://hl7.org/fhir/us/davinci-drug-formulary/STU2.0.1/. --------------------------------------------------------------------------- To support the exchange of formulary data that is integrated with protected health information (PHI) or personally identifiable information (PII), such as enabling a payer to provide personalized information to the patient based on their medications, we propose in Sec. 170.315(g)(30)(iii)(A) that the Health IT Module must provide support for the ``Authenticated API'' according to at least one of the versions of the implementation specification adopted in Sec. 170.215(m) (where we have proposed to adopt the PDex US Drug Formulary IG Version 2.0.1--STU2) and the requirements proposed in Sec. 170.315(g)(30)(i) and (ii) related to registration as well as authentication and authorization. To support the exchange of formulary data that is publicly available, and which does not contain PHI or PII, we propose in Sec. 170.315(g)(30)(iii)(B) that the Health IT Module must provide support for an ``Unauthenticated API'' according to at least one of the versions of the implementation specification adopted in Sec. 170.215(m). We propose in Sec. 170.315(g)(30)(iv) requirements for a Health IT Module certified to the ``patient access API'' criterion to support access to patient health, coverage, and claims information. We propose in Sec. 170.315(g)(30)(iv)(A) that the Health IT Module must allow patients to access and share clinical and coverage information via a standardized API(s) according to at least one of the versions of the implementation specification adopted in Sec. 170.215(k)(2). Under this paragraph, in Sec. 170.215(k)(2)(i), we propose to adopt the HL7 FHIR Da Vinci [[Page 63583]] Payer Data Exchange (PDex) Implementation Guide Version 2.0.0--STU2 \188\ and incorporate it by reference in Sec. 170.299. We propose to adopt this implementation specification under PHSA section 3004 and make it available for HHS use. This implementation specification enables a payer to create a member's health history using clinical resources based on US Core profiles. If we adopt subsequent versions of the PDex IG in Sec. 170.215(k)(2), our proposals that require use of at least one of the versions of the implementation specification adopted in Sec. 170.215(k)(2) would enable health IT developers to use any version adopted at this location, unless we specify an ``expiration'' date which indicates a certain version of the specification may no longer be used after that date. --------------------------------------------------------------------------- \188\ See https://hl7.org/fhir/us/davinci-pdex/STU2/. --------------------------------------------------------------------------- We note that a version 2.1.0 of the PDex IG is currently under development and available for interested parties to review.\189\ We propose as an alternative, to adopt PDex IG version 2.1.0 if the standard is balloted and published before the issuance of the HTI-2 Final Rule. We note several important enhancements to the PDex IG version 2.1.0 from 2.0.0--STU2 to align with the Interoperability and Patient Access Final Rule (85 FR 25522 through 25569) and the Interoperability and Prior Authorization Final Rule (89 FR 8768 through 8946). For example, version 2.1.0 supports US Core 6.1.0, which supports USCDI v3, as well as drops required support for aspects of prior authorization that are viewed as unnecessary or complicating to successful execution of the transaction in version 2.0.0 of the PDex IG. Version 2.1.0 also includes an important use case for bulk data access based on the finalization of the Bulk Data Access IG as a required standard under the Payer API requirements finalized in CMS' rules. --------------------------------------------------------------------------- \189\ See https://build.fhir.org/ig/HL7/davinci-epdx/. --------------------------------------------------------------------------- We believe that continued alignment among industry, government, and standards development organizations involved with the payer data exchange use cases is necessary and we believe that if PDex IG version 2.1.0 is balloted and published before issuance of the HTI-2 Final Rule, adoption of version 2.1.0 would support such alignment. In order to enable patient access to information and allow patients to incorporate their data into apps or systems of their choice with minimal effort, we propose in Sec. 170.315(g)(30)(iv)(A)(1) that the Health IT Module must support the ability for patients to authenticate and share information with an application, service, or health plan according to at least one of the versions of the implementation specification adopted in Sec. 170.215(k)(2) (where we have proposed to adopt the PDex IG version 2.0.0--STU2). Specifically, we propose in Sec. 170.315(g)(30)(iv)(A)(1)(i) that the Health IT Module must support the requirements associated with the ``OAuth2.0 or SMART-on- FHIR Member-authorized Exchange'' exchange method, including the requirements in the section ``OAuth and FHIR API.'' We propose in Sec. 170.315(g)(30)(iv)(A)(1)(ii) that the Health IT Module must support the requirements included in the ``PDEX Server CapabilityStatement'' and the HL7 FHIR Profiles, Resources, and operations included in Section 4.5.4 ``CapabilityStatement'' \190\ according to at least one of the versions of the implementation specification adopted in Sec. 170.215(k)(2) (where we have proposed to adopt the PDex IG version 2.0.0--STU2). --------------------------------------------------------------------------- \190\ For more information, see https://hl7.org/fhir/us/davinci-pdex/STU2/introduction.html#capabilitystatement. --------------------------------------------------------------------------- Finally, in Sec. 170.315(g)(30)(iv)(A)(1)(iii) we propose that the Health IT Module must support the capabilities described in ``US Core Server CapabilityStatement'' according to at least one of the versions of the implementation specification adopted in Sec. 170.215(b)(1) (where we have adopted US Core IG version 3.1.1, which expires on January 1, 2026, US Core IG version 6.1.0, which we propose will expire on January 1, 2028, and where we propose to adopt US Core IG version 7.0.0). We further propose that the Health IT Module must support the capabilities in ``US Core Server CapabilityStatement'' for each of the data classes and data elements included in at least one of the versions of the USCDI standard adopted in Sec. 170.213 (where we have adopted USCDI version 1, which expires on January 1, 2026, USCDI version 3, which we propose will expire on January 1, 2028, and where we propose to adopt USCDI version 4). We note that while most of the USCDI and US Core requirements are met through the PDEX Server CapabilityStatement requirements in Sec. 170.315(g)(30)(iv)(A)(1)(iii), we have added this requirement to ensure the Health IT Module supports availability of all of the data classes and data elements in at least one of the versions of the USCDI adopted in Sec. 170.213. We note that in section III.B.6 of this proposed rule, ``New Imaging Requirements for Health IT Modules,'' we propose to revise certification criteria for ``transitions of care'' in Sec. 170.315(b)(1); ``application access--all data request'' in Sec. 170.315(g)(9); and ``standardized API for patient and population services'' in Sec. 170.315(g)(10) by adding new provisions to include support of a link to diagnostic imaging. The CMS API requirements for impacted payers, which we are seeking to support with the proposed certification criteria in Sec. 170.315(g)(30)-(36), reference the versions of the USCDI available in Sec. 170.213, which do not include imaging links as a data element at this time. Therefore, in order to maintain alignment with current CMS requirements for impacted payers, we have not proposed to separately require support for imaging links by a Health IT Module certified to the proposed certification criteria in Sec. 170.315(g)(30), (32), and (33). We request comment on our decision to not propose to include imaging links, and whether interested parties believe a requirement to support imaging links, in a manner similar to the proposed requirements for the certification criteria mentioned above, would be appropriate and desirable for the proposed certification criteria in Sec. 170.315(g)(30), (32), and (33). We propose in Sec. 170.315(g)(30)(iv)(B) that the Health IT Module must allow patients to access their claims information via a standardized API(s) according to at least one of the versions of the implementation specification adopted in Sec. 170.215(k)(1). In Sec. 170.215(k)(1)(i), we propose, independent of the certification criterion proposal, to adopt the HL7 FHIR Consumer Directed Payer Data Exchange (CARIN IG for Blue Button[supreg]) Implementation Guide version 2.0.0--STU 2 \191\ and incorporate it by reference in Sec. 170.299. We propose to adopt this implementation specification under PHSA section 3004 and make it available for HHS use. This implementation specification supports providing a set of resources that payers can display to consumers, primarily financial (claims and encounter) data, with some limited associated clinical data. If we adopt subsequent versions of the CARIN IG for Blue Button[supreg] in Sec. 170.215(k)(1), our proposals that require the use of at least one of the versions of the implementation specification adopted in Sec. 170.215(k)(1) would enable health IT developers to use any version adopted at this location, unless we specify an ``expiration'' date [[Page 63584]] which indicates a certain version of the specification may no longer be used after that date. --------------------------------------------------------------------------- \191\ See https://hl7.org/fhir/us/carin-bb/. --------------------------------------------------------------------------- We propose in Sec. 170.315(g)(30)(iv)(B)(1) that the Health IT Module must support the ``Authentication and Authorization Requirements'' section of at least one of the versions of the implementation specification adopted in Sec. 170.215(k)(1) (where we have proposed to adopt the CARIN IG for Blue Button[supreg] version 2.0.0--STU 2). These requirements establish authentication and privacy requirements to protect patient health information. We propose in Sec. 170.315(g)(30)(iv)(B)(2) that the Health IT Module support the requirements described in the ``C4BB CapabilityStatement'' according to at least one of the versions of the implementation specification adopted in Sec. 170.215(k)(1). We request comments on this proposal. Support for CMS Requirements The ``patient access API'' certification criterion proposed in Sec. 170.315(g)(30), if finalized, would support the availability of certified health IT that can enable impacted payers \192\ to meet CMS requirements to implement and maintain a Patient Access API, as specified in 42 CFR 422.119, 431.60, 457.730, 438.242(b)(5), and 457.1233(d) and 45 CFR 156.221. Specifically, a Health IT Module certified to the proposed ``patient access API'' would facilitate access to data held by the payer, including: adjudicated claims (including cost); encounters with capitated providers; provider remittances; enrollee cost-sharing; all data classes and data elements included in a version of the USCDI standard at 45 CFR 170.213, formularies or preferred drug lists, and certain information about prior authorizations requests and decisions, as finalized in the CMS Interoperability and Patient Access Final Rule (85 FR 25542) and the CMS Interoperability and Prior Authorization Final Rule (89 FR 8784). We further note that we have proposed in section III.B.20.d. of this proposed rule to apply the API Conditions of Certification Sec. 170.404(a), including transparency requirements in Sec. 170.404(a)(2), and certain API Maintenance of Certification requirements in Sec. 170.404(b), to the proposed ``patient access API'' and other criteria. These Conditions of Certification would, among other provisions, align with the API requirements finalized by CMS related to ``Documentation requirements for APIs,'' for instance, the requirement at 42 CFR 422.119(d) for MA organizations. --------------------------------------------------------------------------- \192\ As noted above, for the purposes of the CMS Interoperability and Patient Access and Interoperability and Prior Authorization Final Rules discussed in this section, impacted payers include Medicare Advantage (MA) organizations, state Medicaid fee- for-service (FFS) programs, state Children's Health Insurance Program (CHIP) FFS programs, Medicaid managed care plans, CHIP managed care entities, and Qualified Health Plan (QHP) issuers on the Federally-facilitated Exchanges (FFEs). --------------------------------------------------------------------------- ii. Provider Access API--Client (Sec. 170.315(g)(31)) and Provider Access API--Server (Sec. 170.315(g)(32)) We propose to adopt ``provider access API--client'' and ``provider access API--server'' certification criteria in Sec. 170.315(g)(31) and Sec. 170.315(g)(32), respectively. The proposed certification criteria would enable a health care provider to access information on patients' claims, including information about the patient's encounters, providers, organizations, locations, dates of service, diagnoses (conditions), procedures and observations. The proposed certification criteria could further enable access by a health care provider to clinical information maintained by the payer from sources other than claims, such as: laboratory results, clinical data from documents formatted in accordance with the Common Clinical Data Architecture (C- CDA), information from admit, discharge, and transfer (ADT) messages, information received from immunization registries, and information related to medications from pharmacy networks. Such information can provide a more complete clinical profile for the provider, as well as allow the provider to make appropriate treatment decisions based on both the clinical information and the patient's individual coverage information. We propose that a Health IT Module certified to the ``provider access API--client'' in Sec. 170.315(g)(31) support specified capabilities to enable a provider to request and receive patient clinical and coverage information from a payer and receive and process the response. We propose in Sec. 170.315(g)(31)(i) that the Health IT Module must support the ability to request patient history according to at least one of the versions of the implementation specification adopted in Sec. 170.215(k)(2) (where we have proposed to adopt the PDex IG version 2.0.0--STU2). Under Sec. 170.315(g)(31)(ii), we propose that the Health IT Module must support specified API interactions as a client. First, in Sec. 170.315(g)(31)(ii)(A) we propose that the Health IT Module support the capability to read and search the API. Specifically, in Sec. 170.315(g)(31)(ii)(A)(1) we propose that the Health IT Module support the ability to interact with a ``PDEX Server'' as a client including support for all the corresponding client capabilities for requirements described in the ``PDEX Server CapabilityStatement'' and the HL7 FHIR Profiles, Resources, and operations included in Section 4.5.4 ``CapabilityStatement,'' according to at least one of the versions of the implementation specification adopted in Sec. 170.215(k)(2) (where we have proposed to adopt the PDex IG version 2.0.0--STU2). In Sec. 170.315(g)(31)(ii)(A)(2) we propose that the Health IT Module must support all the corresponding client capabilities for requirements included in the ``C4BB CapabilityStatement'' according to at least one of the versions of the implementation specification adopted in Sec. 170.215(k)(1) (where we have proposed to adopt the CARIN IG for Blue Button[supreg] version 2.0.0--STU 2). In Sec. 170.315(g)(31)(ii)(A)(3) we propose that the Health IT Module must support the corresponding client capabilities described in ``US Core Server CapabilityStatement'' according to an implementation specification adopted in Sec. 170.215(b)(1) (where we have adopted US Core IG versions 3.1.1, which expires on January 1, 2026, US Core IG version 6.1.0, and proposed to adopt the US Core IG version 7.0.0) for each of the data classes and data elements included in at least one of the versions of the USCDI standard adopted in Sec. 170.213 (where we have adopted USCDI version 1, which expires on January 1, 2026, USCDI version 3, which we propose will expire on January 1, 2028, and where we propose to adopt USCDI version 4). To support the transfer of information on groups of patients, we propose in Sec. 170.315(g)(31)(ii)(B) that the Health IT Module must support the ability to request and receive information as a client according to at least one of the versions of the standard adopted in Sec. 170.215(a) (where we have adopted FHIR[supreg] R4) and at least one of the versions of the implementation specification adopted in Sec. 170.215(d) (where we have adopted the Bulk Data Access IG v1.0.0--STU 1, which we have proposed for expiration on January 1, 2028, and the Bulk Data Access IG v2.0.0--STU 2) for each of the data included in Sec. 170.315(g)(31)(ii)(A), as described above. Additionally, we propose for the time period up to and including December 31, 2027, the Health IT Module must meet either the requirements specified in paragraph (g)(31)(ii)(B)(1) (proposed [[Page 63585]] to be the ``GroupLevelExport'' operation) or both (1) and (2) (proposed to be the ``_type'' query parameter for each of the data included in 170.315(g)(31)(ii)(A)) of this section according to at least one of the versions of the implementation specification adopted in Sec. 170.215(d). We propose that on and after January 1, 2028, the Health IT Module must meet the requirements specified in paragraph (g)(31)(ii)(B)(1) and (2) of this section according to at least one of the versions of the implementation specification adopted in Sec. 170.215(d). For further discussion of these proposed requirements, which we have also proposed to include in other certification criteria that reference the Bulk Data Access IG, we refer readers to section III.B.14 of this proposed rule. We propose in Sec. 170.315(g)(31)(iii) that the Health IT Module must support the ability to receive, parse, and write patient health history and coverage information to the Health IT Module for the following information. For clinical and coverage information, we propose in Sec. 170.315(g)(31)(iii)(A) to include all FHIR Profiles and Resources included in the ``PDEX Server CapabilityStatement'' and the FHIR Profiles and Resources included in the Section 4.5.4 ``FHIR CapabilityStatement'' according to at least one of the versions of the implementation specification adopted in Sec. 170.215(k)(2) (where we have proposed to adopt the PDex IG version 2.0.0--STU2). In Sec. 170.315(g)(31)(iii)(B) we propose to include the information included in the ``C4BB CapabilityStatement'' according to at least one of the versions of the implementation specification adopted in Sec. 170.215(k)(1) (where we have proposed to adopt CARIN IG for Blue Button[supreg] version 2.0.0--STU 2). Finally, in Sec. 170.315(g)(31)(iii)(C) we propose to include the capabilities described in the ``US Core Server CapabilityStatement'' according to at least one of the versions of the implementation specification adopted in Sec. 170.215(b)(1) (where we have adopted US Core IG version 3.1.1, which expires on January 1, 2026, US Core IG version 6.1.0, which we propose will expire on January 1, 2028, and where we propose to adopt US Core IG version 7.0.0) for each of the data classes and data elements included in at least one of the versions of the USCDI standard adopted in Sec. 170.213 (where we have adopted USCDI version 1, which expires on January 1, 2026, USCDI version 3, which we propose will expire on January 1, 2028, and where we propose to adopt USCDI version 4). We propose that a Health IT Module certified to the ``provider access API--server'' certification criterion in Sec. 170.315(g)(32) would support capabilities to enable providers to request and receive patient health history and coverage information from payers. Similar to the ``patient access API'' certification criterion proposed in Sec. 170.315(g)(30), we propose to require support for two registration pathways for Health IT Modules certified to the criterion. We propose in Sec. 170.315(g)(32)(i)(A) that the Health IT Module must support functional registration for confidential apps according to the requirements included in Sec. 170.315(j)(1). We propose in Sec. 170.315(g)(32)(i)(B) that the Health IT Module must support dynamic registration according to the requirements in Sec. 170.315(j)(2). We propose in Sec. 170.315(g)(32)(ii) the authentication and authorization requirements for a Health IT Module certified to the ``provider access API--server'' criterion. We propose in Sec. 170.315(g)(32)(ii)(A) that the Health IT Module must support the ability to authenticate and authorize an app during the process of granting access to patient data to users according to at least one of the versions of the implementation specification adopted in Sec. 170.215(k)(2) (where we have proposed to adopt the PDex IG version 2.0.0--STU2) and at least one implementation specification adopted in Sec. 170.215(c) (where we have adopted the SMART Application Launch Framework IG Release 1.0.0, which expires on January 1, 2026, the SMART App Launch IG Release 2.0.0, which we have proposed for expiration on January 1, 2028, and proposed to adopt the SMART App Launch IG Release 2.2.0). We propose in Sec. 170.315(g)(32)(ii)(A)(1) that the Health IT Module must support asymmetric certificate-based authentication according to the requirements in Sec. 170.315(j)(11) for user-facing apps dynamically registered using the capabilities in Sec. 170.315(g)(32)(i)(B). We propose authentication and authorization requirements for system access in Sec. 170.315(g)(32)(ii)(B), including that the Health IT Module must support the ability to authenticate and authorize an app during the process of granting access to patient data to system apps according to at least one of the versions of the standard adopted in Sec. 170.215(a) (where we have adopted FHIR R4) and at least one of the versions of the implementation specification adopted in Sec. 170.215(d) (where we have adopted the Bulk Data Access IG v1.0.0--STU 1, which we have proposed for expiration on January 1, 2028, and proposed to adopt the Bulk Data Access IG v2.0.0--STU 2). We propose in Sec. 170.315(g)(32)(ii)(B)(1) that the Health IT Module must support system authentication and authorization according to the requirements in Sec. 170.315(j)(7) for system apps functionally registered using the capabilities in Sec. 170.315(g)(32)(i)(A). We also propose in Sec. 170.315(g)(32)(ii)(B)(2) the Health IT Module must support asymmetric certificate-based system authentication and authorization according to the requirements in Sec. 170.315(j)(8) for system apps dynamically registered using the capabilities in Sec. 170.315(g)(32)(i)(B). We propose in Sec. 170.315(g)(32)(iii) that the Health IT Module must support specified capabilities to allow a provider to request patient health history and coverage information from a payer and to receive a response. Specifically, we propose in Sec. 170.315(g)(32)(iii)(A) that the Health IT Module must support the ability for a client to request patient health history, coverage, and claims information according to at least one of the versions of the implementation specification adopted in Sec. 170.215(k)(2) (where we have proposed to adopt the PDex IG version 2.0.0--STU2). We propose in Sec. 170.315(g)(32)(iii)(B) that the Health IT Module support the ability to identify patient clinical, coverage, and claims information based on the information provided by the client in 170.315(g)(32)(iii)(A). We propose in Sec. 170.315(g)(32)(iii)(C)(1) that the Health IT Module must support the requirements described in the ``PDEX Server CapabilityStatement'' and the HL7 FHIR Profiles and operations included in Section 4.5.4 ``CapabilityStatement'' via a standardized API according to at least one of the versions of the implementation specification adopted in Sec. 170.215(k)(2). We propose in Sec. 170.315(g)(32)(iii)(C)(2) that the Health IT Module support claims information by supporting the requirements included in the ``C4BB CapabilityStatement'' according to at least one of the versions of the implementation specification adopted in Sec. 170.215(k)(1) (where we have proposed to adopt CARIN IG for Blue Button[supreg] version 2.0.0-- STU 2). We propose in Sec. 170.315(g)(32)(iii)(C)(3) that the API must support the capabilities described in ``US Core Server CapabilityStatement'' according to at least one of the versions of the implementation specification adopted in Sec. 170.215(b)(1) (where we have [[Page 63586]] adopted the US Core IG versions 3.1.1, which expires on January 1, 2026, the US Core IG version 6.1.0, and proposed to adopt the US Core IG version 7.0.0) for each of the data classes and data elements included in at least one of the versions of the USCDI standard adopted in Sec. 170.213 (where we have adopted USCDI Version 1, which expires on January 1, 2026, USCDI version 3, which we propose will expire on January 1, 2028, and where we propose to adopt USCDI version 4). We propose in Sec. 170.315(g)(32)(iii)(D) that the Health IT Module must support returning patient clinical, coverage, and non- financial claims and encounter information according to at least one of the versions of the implementation specification in Sec. 170.215(k)(2) (where we have proposed to adopt the PDex IG version 2.0.0--STU2) for each of the data included in Sec. 170.315(g)(32)(iii)(C)(1), (2) and (3), as described above. To support the transfer of information on groups of patients, we propose in Sec. 170.315(g)(32)(iii)(E) that the Health IT Module must support responding to requests for patient data according to at least one of the versions of the standard adopted in Sec. 170.215(a) (where we have adopted FHIR R4), and at least one of the versions of the implementation specification adopted in Sec. 170.215 (d) (where we have adopted the Bulk Data Access IG v1.0.0--STU 1, which we have proposed for expiration on January 1, 2028, and the Bulk Data Access IG v2.0.0--STU 2) for each of the data included in Sec. 170.315(g)(32)(C)(1), (2) and (3), as proposed above. For the time period up to and including December 31, 2027, we propose that the Health IT Module must meet either the requirements specified in (g)(32)(iii)(E)(1) (proposed to be the ``GroupLevelExport'' operation) or both (1) and (2) (proposed to be the ``_type'' query parameter for each of the data included in Sec. 170.315(g)(32)(C), (D) and (E)), of this section according to at least one of the versions of the implementation specification adopted in Sec. 170.215(d). On and after January 1, 2028, we propose the Health IT Module must meet the requirements specified in paragraph Sec. 170.315(g)(32)(iii)(E)(1) and (2) of this section according to at least one of the versions of the implementation specification adopted in Sec. 170.215(d). We request comments on this proposal. Support for CMS Requirements The ``provider access API--server'' certification criterion proposed in Sec. 170.315(g)(32), if finalized, would support the availability of certified health IT that can enable impacted payers \193\ to meet CMS requirements to implement and maintain a Provider Access API as specified in 42 CFR 422.121(a), 431.61(a), 457.731(a), 438.242(b)(7), and 457.1233(d) and 45 CFR 156.222(a). Specifically, a Health IT Module certified to the proposed ``provider access API-- server'' criterion would facilitate access to data held by the payer, including: claims and encounter data (excluding provider remittances and patient cost-sharing information), all data classes and data elements derived from a version of the USCDI standard adopted at 45 CFR 170.213, and certain information about prior authorizations requests and decisions, as required in the CMS Interoperability and Prior Authorization Final Rule (89 FR 8817). --------------------------------------------------------------------------- \193\ As noted above, for the purposes of the CMS Interoperability and Patient Access and Interoperability and Prior Authorization Final Rules discussed in this section, impacted payers include Medicare Advantage (MA) organizations, state Medicaid fee- for-service (FFS) programs, state Children's Health Insurance Program (CHIP) FFS programs, Medicaid managed care plans, CHIP managed care entities, and Qualified Health Plan (QHP) issuers on the Federally-facilitated Exchanges (FFEs). --------------------------------------------------------------------------- In addition, the proposed ``provider access API--client'' certification criterion in Sec. 170.315(g)(31) would establish the requirements for APIs to facilitate a provider request for this information, to ensure that providers can use certified health IT to access the information made available through a payer's Provider Access API. iii. Payer-to-Payer API (Sec. 170.315(g)(33)) We propose to adopt a ``payer-to-payer API'' certification criterion in Sec. 170.315(g)(33) to specify requirements for Health IT Modules that can be used by payers to support electronic exchange between payer systems when patients transition between payers. Payer- to-payer data exchange that allows health data to follow the patient when they switch payers can enable improved coordination of care, increased patient empowerment, and reduced administrative burden. Similar to the proposed ``provider access API--client'' and ``provider access API--server'' certification criteria, the proposed ``payer-to-payer API'' certification criterion would support the electronic request and sending of payer information related to both beneficiary coverage information and the clinical condition and care of the patient. We propose two registration pathways for a Health IT Module certified to the proposed ``payer-to-payer API'' criterion. We propose in Sec. 170.315(g)(33)(i)(A) that the Health IT Module must support registration for confidential apps according to the functional registration requirements in Sec. 170.315(j)(1). We further propose in Sec. 170.315(g)(33)(i)(B) that the Health IT Module must support dynamic registration according to requirements in Sec. 170.315(j)(2). We propose requirements for authentication and authorization in Sec. 170.315(g)(33)(ii). In Sec. 170.315(g)(33)(ii)(A) we propose that the Health IT Module must support system authentication and authorization according to the requirements in Sec. 170.315(j)(7) for system apps functionally registered using the capabilities in Sec. 170.315(g)(33)(i)(A). In Sec. 170.315(g)(33)(ii)(B), we propose that the Health IT Module must support asymmetric certificate-based system authentication and authorization according to the requirements in Sec. 170.315(j)(8) for system apps dynamically registered using the capabilities in Sec. 170.315(g)(33)(i)(B). We propose in Sec. 170.315(g)(33)(iii)(A) that the Health IT Module must support the requirements included in the ``Payer-to-Payer Exchange'' section of at least one of the versions of the implementation specification adopted in Sec. 170.215(k)(2) (where we have proposed to adopt the PDex IG version 2.0.0--STU2), as a client and server, including support for the following ``Data Retrieval Methods'' to allow access to information in Sec. 170.315(g)(33)(iii)(B), (C), and (D): ``Query all clinical resource individually,'' ``$patient-everything operation,'' and ``Bulk FHIR Asynchronous protocols.'' We specifically request comment on the ``Data Retrieval Methods'' we should require as part of the ``payer-to-payer API'' certification criterion. To support the transfer of information on groups of patients, we propose in Sec. 170.315(g)(33)(iii)(A)(2) that, for the time period up to and including December 31, 2027, the Health IT Module must respond to requests for patient data according to at least one of the versions of the standard adopted in Sec. 170.215(a) (where we have adopted FHIR R4), and at least one of the versions of the implementation specification adopted in Sec. 170.215(d) (where we have adopted the Bulk Data Access IG v1.0.0--STU 1, which we have proposed for expiration on January 1, 2028, and the Bulk Data Access IG v2.0.0--STU 2) for each of the data included in Sec. 170.315(g)(33)(iii)(B), (C) and (D), as described below. Additionally, we propose for the time [[Page 63587]] period up to and including December 31, 2027, the Health IT Module must meet either the requirements specified in paragraph (g)(33)(iii)(A)(2)(i) (proposed to be the ``GroupLevelExport'' operation) or both (i) and (ii) (proposed to be the ``_type'' query parameter for each of the data classes and data elements included in at least one of the versions of the USCDI standard adopted in Sec. 170.213) of this section according to at least one of the versions of the implementation specification adopted in Sec. 170.215(d). We propose that on and after January 1, 2028, the Health IT Module must meet the requirements specified in paragraph (g)(33)(iii)(A)(2)(i) and (ii) of this section according to at least one of the versions of the implementation specification adopted in Sec. 170.215(d). We propose in Sec. 170.315(g)(33)(iii)(B) that the Health IT Module must support the requirements described in the ``PDEX Server CapabilityStatement'' as a client and server via a standardized API according to at least one of the versions of the implementation specification adopted in Sec. 170.215(k)(2) (where we have proposed to adopt the PDex IG version 2.0.0--STU2). We propose in Sec. 170.315(g)(33)(iii)(C) that the Health IT Module must support sharing of claims information by supporting the data included in the ``C4BB CapabilityStatement'' according to at least one of the versions of the implementation specification adopted in Sec. 170.215(k)(1) (where we have proposed to adopt CARIN IG for Blue Button[supreg] version 2.0.0-- STU 2). We propose in Sec. 170.315(g)(33)(iii)(D) that the Health IT Module must support the capabilities described in ``US Core Server CapabilityStatement'' according to the implementation specification in Sec. 170.215(b)(1) (where we have adopted US Core IG version 3.1.1, which expires on January 1, 2026, US Core IG version 6.1.0, which we propose will expire on January 1, 2028, and where we propose to adopt US Core IG version 7.0.0) for each of the data classes and data elements included in at least one of the versions of the USCDI standard adopted in Sec. 170.213 (where we have adopted USCDI version 1, which expires on January 1, 2026, USCDI version 3, which we propose will expire on January 1, 2028, and where we propose to adopt USCDI version 4). We request comments on this proposal. Support for CMS Requirements The ``payer-to-payer API'' certification criterion proposed in Sec. 170.315(g)(33), if finalized, would support the availability of certified health IT that can enable impacted payers \194\ to meet CMS requirements to implement and maintain a Provider Access API as specified in 42 CFR 422.119, 431.60, 457.730, 438.242(b)(5), and 457.1233(d) and 45 CFR 156.221. Specifically, a Health IT Module certified to the ``payer-to-payer API'' criterion would facilitate sharing between payers of claims and encounter data (excluding provider remittances and patient cost-sharing information), all data classes and data elements in at least one of the versions of the USCDI standard in Sec. 170.213, and certain information about prior authorization requests and decisions, as required in the CMS Interoperability and Prior Authorization Final Rule (89 FR 8855). --------------------------------------------------------------------------- \194\ As noted above, for the purposes of the CMS Interoperability and Patient Access and Interoperability and Prior Authorization Final Rules discussed in this section, impacted payers include Medicare Advantage (MA) organizations, state Medicaid fee- for-service (FFS) programs, state Children's Health Insurance Program (CHIP) FFS programs, Medicaid managed care plans, CHIP managed care entities, and Qualified Health Plan (QHP) issuers on the Federally-facilitated Exchanges (FFEs). --------------------------------------------------------------------------- iv. Prior Authorization API--Provider (Sec. 170.315(g)(34)) and Prior Authorization API--Payer (Sec. 170.315(g)(35)) Background on Electronic Prior Authorization Prior authorization processes \195\ have contributed significantly to patient and provider burden, for instance, through delays experienced by patients and clinicians as they seek to satisfy the requirements associated with prior authorization rules set by payers.\196\ ONC's Strategy on Reducing Regulatory and Administrative Burden Relating to the Use of Health IT and EHRs,\197\ released in 2020, identified challenges associated with the prior authorization process faced by patients and health care providers, including: (i) difficulty in determining whether an item or service requires prior authorization; (ii) difficulty in determining payer-specific prior authorization requirements for those items and services; (iii) inefficient use of provider and staff time to navigate communications channels such as fax, telephone, and various web portals; and (iv) unpredictable and lengthy amounts of time to receive payer decisions. The Strategy noted that payers and health IT developers have addressed prior authorization in an ad hoc manner with interfaces that reflect individual payer technology considerations, payer lines of business, and customer-specific constraints. A 2022 physician survey conducted by the American Medical Association demonstrated significant negative impacts associated with the current prior authorization and beneficiary information exchange processes.\198\ Nearly 94 percent of physicians reported care delays associated with prior authorization, and 80 percent reported that issues related to the prior authorization process can sometimes lead to treatment abandonment. In addition, survey respondents reported that physicians and their staff spend almost two business days each week completing prior authorizations, with nearly 35 percent of physicians retaining staff who work exclusively on prior authorizations. Today, hospitals and provider practices widely continue to use telephone and fax to conduct prior authorization processes. According to the Council for Affordable Quality Healthcare, only 28 percent of 228 million prior authorization contacts were fully electronic in 2022.\199\ --------------------------------------------------------------------------- \195\ Generally defined as rules imposed by healthcare payers that require approval for a medication, procedure, device, or other medical service be obtained prior to payment for the item or service. \196\ Office of the National Coordinator for Health Information Technology. Strategy on Reducing Regulatory and Administrative Burden Relating to the Use of Health IT and EHRs [PDF file]. February 2020. Retrieved from https://www.healthit.gov/sites/default/files/page/2020-02/BurdenReport_0.pdf. \197\ Office of the National Coordinator for Health Information Technology. Strategy on Reducing Regulatory and Administrative Burden Relating to the Use of Health IT and EHRs [PDF file]. February 2020. Retrieved from https://www.healthit.gov/sites/default/files/page/2020-02/BurdenReport_0.pdf. \198\ https://www.ama-assn.org/practice-management/prior-authorization/prior-authorization-research-reports. \199\ https://www.caqh.org/sites/default/files/2023-05/2022-caqh-index-report.pdf. --------------------------------------------------------------------------- In 2020, ONC charged the HITAC to establish the Intersection of Clinical and Administrative Data (ICAD) Task Force to produce information and considerations related to the merging of clinical and administrative data for electronic prior authorization. The ICAD Task Force's final report,\200\ approved in November 2020, recommended that ONC work with CMS, other Federal actors, and standards development organizations to ``establish standards for prior authorization workflows.'' Specifically, the Task Force recommended that entities should develop API specifications ``such that the authorization and related documentation may be triggered in workflow in the relevant workflow [[Page 63588]] system where the triggering event for the authorization is created.'' --------------------------------------------------------------------------- \200\ https://www.healthit.gov/sites/default/files/facas/ICAD_TF_FINAL_Report_HITAC_2020-11-06_508_0.pdf. --------------------------------------------------------------------------- In January 2021, ONC published an RFI titled ``Request for Information: Electronic Prior Authorization Standards, Implementation Specifications, and Certification Criteria'' to seek input from the public regarding electronic prior authorization standards, implementation specifications, and certification criteria that could be adopted within the ONC Health IT Certification Program (87 FR 3475). ONC received approximately 130 responses to this RFI from a wide range of entities. Comments on the RFI broadly supported the incorporation of electronic prior authorization capabilities within the Program, while highlighting concerns about the current readiness and maturity of available implementation specifications to support these capabilities. Commenters also provided input on how certification criteria related to electronic prior authorization should be structured and how certification criteria should address other Federal requirements around the use of standards for electronic prior authorization transactions. Finally, commenters provided input on the benefits of improving electronic prior authorization for patients, providers, health IT developers and payers, as well as potential challenges associated with implementation. ONC also charged the HITAC to establish a Task Force in order to provide input and recommendations in response to the RFI; the Task Force's recommendations were approved and submitted to ONC on March 10, 2022.\201\ The proposals in this section would implement several recommendations from the Task Force, specifically recommendations to: --------------------------------------------------------------------------- \201\ https://www.healthit.gov/sites/default/files/page/2022-03/2022-03-10_ePA_RFI_Recommendations_Report_Signed_508.pdf. --------------------------------------------------------------------------- Create a suite of electronic prior authorization health IT certification criteria for health IT systems supporting both providers and payers that can enable health IT developers to certify to one or more specific functional capabilities that together, across participating health IT systems, enable the full electronic prior authorization workflow. Ensure new certification criteria for electronic prior authorization provide for health IT systems that perform prior authorization on behalf of payers to ensure that their solutions are compliant to consensus-based standards for electronic prior authorization and are able to send and receive information needed to meet the prior authorization business case. Work with the Da Vinci Project and key healthcare stakeholders (e.g., providers, developers, patients) to develop appropriate health IT certification criteria that incorporate key functional capabilities for prior authorization. Ensure certification requirements that allow a FHIR- enabled process for prior authorization transactions do not require translation to X12. Prioritize criteria based on the Da Vinci Prior Authorization Support (PAS) IG that allow data, C-CDA or FHIR documents to be provided in a FHIR construct. Proposals We propose to adopt a ``prior authorization API--provider'' certification criterion in Sec. 170.315(g)(34), which establishes requirements for Health IT Modules that can be used to facilitate a provider's request of coverage information and request for a prior authorization decision. We also propose to adopt a complementary ``prior authorization API--payer'' certification criterion in Sec. 170.315(g)(35), which establishes requirements for Health IT Modules that can be used by a payer to accept prior authorization requests from a provider, send requested documentation and coverage information, and send prior authorization decisions. Together, these certification criteria would support real-time access for providers to payer approval requirements, documentation, and rules at point of service, as well as enable providers to request and receive authorization. We believe that technology certified to these capabilities would help to automate and streamline the prior authorization process for health care providers and payers, to ensure treatment decisions are made in a timely fashion, avoid delays in care, and reduce administrative burden on health care providers and payers associated with assembling and reviewing required documentation. Both certification criteria are based on the HL7 FHIR Da Vinci Burden Reduction IGs, which we propose to adopt in Sec. 170.215(j) and incorporate by reference in Sec. 170.299: HL7 FHIR Da Vinci--Coverage Requirements Discovery (CRD) Implementation Guide, Version 2.0.1--STU 2 (proposed in Sec. 170.215(j)(1)(i)) \202\ --------------------------------------------------------------------------- \202\ See https://hl7.org/fhir/us/davinci-crd/. --------------------------------------------------------------------------- HL7 FHIR Da Vinci--Documentation Templates and Rules (DTR) Implementation Guide, Version 2.0.1--STU 2 (proposed in Sec. 170.215(j)(2)(i)) \203\ --------------------------------------------------------------------------- \203\ See https://hl7.org/fhir/us/davinci-dtr/. --------------------------------------------------------------------------- HL7 FHIR Da Vinci--Prior Authorization Support (PAS) Implementation Guide, Version 2.0.1--STU 2 (proposed in Sec. 170.215(j)(3)(i)) \204\ --------------------------------------------------------------------------- \204\ See https://hl7.org/fhir/us/davinci-pas/. --------------------------------------------------------------------------- We propose to adopt these implementation specifications under PHSA section 3004 and make them available for HHS use. Taken together, these implementation specifications support a comprehensive workflow for conducting electronic prior authorization transactions. The proposed certification criteria below include proposals that require the use of at least one version for each of the implementation specifications adopted in Sec. 170.215(j)(1)-(3). If we adopt subsequent versions of the implementation specifications in Sec. 170.215(j)(1) (CRD IG), (j)(2) (DTR IG), and (j)(3) (PAS IG), respectively, proposals that require the use of at least one implementation specification adopted in one of these locations would enable health IT developers to use any version adopted at the specified location, unless we specify an adoption ``expiration'' date which indicates a certain version of the specification may no longer be used after that date. First, we propose in Sec. 170.315(g)(34)(i) and Sec. 170.315(g)(35)(i) that the ``prior authorization API--provider'' and ``prior authorization API--payer'' certification criteria, respectively, must support capabilities related to coverage discovery. These proposals are intended to facilitate the automation of both information exchange and prior authorization and reduce the need for provider-end manual intervention. Health IT Modules certified to these certification criteria would be able to request coverage information from a payer, for instance when a future encounter is being scheduled for a patient, and to initiate prior authorization electronically when a treatment decision has been made. These requirements will ensure that providers can request and receive a wide variety of information including updates to coverage information, alternative services or products, documentation requirements and rules related to coverage, forms, and templates to complete, and indications of whether prior authorization is required. For the ``prior authorization API--provider'' certification criterion, in Sec. 170.315(g)(34)(i), we propose that a Health IT Module certified to the [[Page 63589]] criterion must support capabilities to initiate and exchange information with payer systems as a client to support the identification of coverage requirements. In Sec. 170.315(g)(34)(i)(A) we propose that the Health IT Module must support the requirements described in the ``Privacy, Security, and Safety'' section of at least one of the versions of the implementation specification adopted in Sec. 170.215(j)(1) (where we have proposed to adopt the CRD IG version 2.0.1--STU 2). In Sec. 170.315(g)(34)(i)(B), we propose that the Health IT Module must support capabilities in Sec. 170.315(j)(20) (where we have proposed to adopt the ``workflow triggers for decision support interventions'' certification criterion) to enable workflow triggers to call decision support services, including support for ``appointment-book,'' ``encounter-start,'' ``encounter-discharge,'' ``order-dispatch,'' ``order-select,'' and ``order-sign'' CDS Hooks according to at least one of the versions of the implementation specification adopted in Sec. 170.215(j)(1) and requirements in Sec. 170.315(j)(20). In Sec. 170.315(g)(34)(i)(C), we propose that the Health IT Module must support the requirements applicable to ``CRD Clients'' in at least one of the versions of the implementation specification in Sec. 170.215(j)(1) including, as proposed in Sec. 170.315(g)(34)(i)(C)(1), the requirements in the ``CRD Client CapabilityStatement,'' and, as proposed in Sec. 170.315(g)(34)(i)(C)(2) support for the ``SHOULD'' requirements applicable to ``CRD Clients'' in Section 5.8 ``Additional Data Retrieval.'' We request public input on whether we should instead finalize a policy that these ``SHOULD'' requirements are treated as ``SHALL'' requirements. For the ``prior authorization API--payer'' certification criterion, we propose in Sec. 170.315(g)(35)(i) that a Health IT Module certified to the criterion must support specified capabilities to exchange information with provider systems to support the identification of coverage requirements. We propose in Sec. 170.315(g)(35)(i)(A) that the Health IT Module must support the ability to receive and respond to decision support requests as a service by supporting the capabilities in Sec. 170.315(j)(21). In Sec. 170.315(g)(35)(i)(B) we propose that the Health IT Module must support the requirements applicable to ``CRD Server'' included in at least one of the versions of the implementation specification adopted in Sec. 170.215(j)(1) (where we have proposed to adopt the CRD IG version 2.0.1--STU 2) including the requirements in the ``CRD Server CapabilityStatement.'' In Sec. 170.315(g)(34)(ii) and Sec. 170.315(g)(35)(ii)(B) we propose requirements for the ``prior authorization API--provider'' and ``prior authorization API--payer'' certification criteria, respectively, related to documentation and rules exchange. The DaVinci DTR and CRD IGs utilize Clinical Quality Language (CQL) to allow payers to inspect a patient's record for the necessary information related to the required documentation for a proposed item (such as durable medical equipment), medication, procedure, or other service. The DTR IG details the use of a payer provided Questionnaire resource and results from CQL execution to generate a QuestionnaireResponse resource containing the necessary information. This IG can allow payer APIs to specify how rules may be executed in a provider context so that documentation requirements are met, while at the same time reducing provider burden by reducing manual data entry. For the ``prior authorization API--provider'' certification criterion, we propose in Sec. 170.315(g)(34)(ii) that a Health IT Module certified to the criterion must support the ability to request and populate prior authorization documentation templates and rules from payer systems according to at least one of the versions of the implementation specification adopted in Sec. 170.215(j)(2) (where we have proposed to adopt the DTR IG version 2.0.1--STU 2). ``Light'' DTR capabilities are applicable to EHRs that rely on a SMART on FHIR application to handle the form filling function of DTR. This requires the server to provide access to the specified resources to allow such an app to retrieve and edit QuestionnaireResponses and related resources. In Sec. 170.315(g)(34)(ii)(A)(1), we propose the Health IT Module must support the capabilities included in the ``Light DTR EHR'' CapabilityStatement according to at least one versions of the implementation specification adopted in Sec. 170.215(j)(2) (where we have proposed to adopt the DTR IG version 2.0.1--STU 2). In Sec. 170.315(g)(34)(ii)(A)(2)(i), we propose that the Health IT Module must support functional registration of the ``DTR SMART Client'' according to the requirements included in Sec. 170.315(j)(1). We also propose in Sec. 170.315(g)(34)(ii)(A)(2)(ii) that the Health IT Module must support dynamic registration of the ``DTR SMART Client'' according to the requirements included in Sec. 170.315(j)(2). In Sec. 170.315(g)(34)(ii)(A)(3), we propose that the Health IT Module must support launching the ``DTR SMART Client'' according to at least one of the versions of the implementation specification adopted in Sec. 170.215(j)(2) (where we have proposed to adopt the DTR IG version 2.0.1--STU 2) to allow providers to launch an app to complete documentation for prior authorization according to at least one of the versions of the implementation specification in Sec. 170.215(j)(2). In Sec. 170.315(g)(34)(ii)(A)(3)(i) we propose that the Health IT Module must support authentication and authorization during the process of granting access to patient data to users according to the requirements in Sec. 170.315(j)(10). In Sec. 170.315(g)(34)(ii)(A)(3)(ii) we propose that the Health IT Module must support asymmetric certificate- based authentication according to the requirements in Sec. 170.315(j)(11) for the ``Light DTR Client'' dynamically registered using the capabilities in Sec. 170.315(g)(34)(ii)(A)(2)(ii). In contrast to ``Light DTR EHR'' capabilities, ``full'' DTR capabilities are relevant to EHRs that manage the form filling functions of DTR internally. In Sec. 170.315(g)(34)(ii)(B), we propose that the Health IT Module must support the capabilities included in the ``Full DTR EHR'' CapabilityStatement according to at least one of the versions of the implementation specification adopted in Sec. 170.215(j)(2) (where we have proposed to adopt the DTR IG version 2.0.1--STU 2). Such EHRs need only support client capabilities for the Questionnaire Package, ValueSet Expand, and Next Question operations. For the ``prior authorization API--payer'' certification criterion, we propose in Sec. 170.315(g)(35)(ii) that a Health IT Module certified to the criterion must support specified capabilities to exchange prior authorization documentation requirements with provider systems. In Sec. 170.315(g)(35)(ii)(A)(1), we propose that the Health IT Module support functional registration for the ``DTR SMART Client'' and ``Full DTR EHR'' according to the requirements included in Sec. 170.315(j)(1). In Sec. 170.315(g)(35)(ii)(A)(2), we propose that the Health IT Module support dynamic registration for the ``DTR SMART Client'' and ``Full DTR EHR'' according to the requirements included in Sec. 170.315(j)(2). In Sec. 170.315(g)(35)(ii)(B)(1) we propose that the Health IT Module support system authentication and authorization according to the requirements in Sec. 170.315(j)(7) for the ``DTR SMART Client'' and ``Full DTR [[Page 63590]] EHR'' functionally registered using the capabilities in Sec. 170.315(g)(35)(ii)(A)(1). In Sec. 170.315(g)(35)(ii)(B)(2) we propose that the Health IT Module support asymmetric certificate-based system authentication and authorization according to the requirements in Sec. 170.315(j)(8) for the ``DTR SMART Client'' and ``Full DTR EHR'' dynamically registered using the capabilities in Sec. 170.315(g)(35)(ii)(A)(2). In Sec. 170.315(g)(35)(ii)(C) we propose that the Health IT Module support the ability to receive and respond to a prior authorization documentation request with documentation templates and rules, according to at least one of the versions of the implementation specification adopted in Sec. 170.215(j)(2) (where we have proposed to adopt the DTR IG version 2.0.1--STU 2), including in Sec. 170.315(g)(35)(ii)(C)(1), the capabilities included in the ``DTR Payer Service'' CapabilityStatement, according to at least one of the versions of the implementation specification adopted in Sec. 170.215(j)(2). Finally, in Sec. 170.315(g)(34)(iii) and Sec. 170.315(g)(35)(iii), we propose that the ``prior authorization API-- provider'' and ``prior authorization API--payer'' certification criteria must support capabilities related to the submission, receipt, and response to a prior authorization request. For the ``prior authorization API--provider'' certification criterion, we propose in Sec. 170.315(g)(34)(iii)(A) that the Health IT Module must support the ability to submit a prior authorization request to a payer system according to at least one of the versions of the implementation specification adopted in 170.215(j)(3) (where we have proposed to adopt the PAS IG version 2.0.1--STU 2). Specifically, we propose in Sec. 170.315(g)(34)(iii)(A)(1) that the Health IT Module include support for the ``EHR PAS Capabilities'' CapabilityStatement according to at least one of the versions of the implementation specification adopted in Sec. 170.215(j)(3). We propose in Sec. 170.315(g)(34)(iii)(A)(2) that the Health IT Module support the ability to include documentation created in Sec. 170.315(g)(34)(ii) in a prior authorization request to a payer system according to at least one of the versions of the implementation specification adopted in Sec. 170.215(j)(3). We propose in Sec. 170.315(g)(34)(iii)(A)(3) that the Health IT Module support the ability to consume and process a ``ClaimResponse'' according to at least one of the versions of the implementation specification adopted in Sec. 170.215(j)(3). Finally, we propose in Sec. 170.315(g)(34)(iii)(A)(4) that the Health IT Module support subscriptions as a client according to the requirements in Sec. 170.315(j)(24) and an implementation specification in Sec. 170.215(j)(3), in order to support ``pended authorization responses.'' For the ``prior authorization API--payer'' certification criterion, we propose in Sec. 170.315(g)(35)(iii)(A)(1) that the Health IT Module must support functional registration according to the requirements included in Sec. 170.315(j)(1), and propose in Sec. 170.315(g)(35)(iii)(A)(2) to require support for dynamic registration according to the requirements included in Sec. 170.315(j)(2). We propose in Sec. 170.315(g)(35)(iii)(B)(1) that the Health IT Module must support system authentication and authorization according to the requirements in Sec. 170.315(j)(7) for system apps functionally registered using the capabilities in Sec. 170.315(g)(35)(iii)(A)(1). We propose in Sec. 170.315(g)(35)(iii)(B)(2) that the Health IT Module must support asymmetric certificate-based system authentication and authorization according to the requirements in Sec. 170.315(j)(8) for system apps dynamically registered using the capabilities in Sec. 170.315(g)(35)(iii)(A)(2). In Sec. 170.315(g)(35)(iii)(C)(1)-(4), we propose that the API must support the ability to receive, process, and respond to a prior authorization request according to at least one of the versions of the implementation specification adopted in Sec. 170.215(j)(3) (where we have proposed to adopt the PAS IG version 2.0.1--STU 2). Specifically, we propose in Sec. 170.315(g)(35)(iii)(C)(1) that the Health IT Module support ``Intermediary PAS Capabilities.'' We propose in Sec. 170.315(g)(35)(iii)(C)(2) that the Health IT Module support an endpoint for receiving prior authorization requests. We propose in Sec. 170.315(g)(35)(iii)(C)(3) that the Health IT Module support the ability to respond to a prior authorization request with a ``ClaimResponse.'' Finally, we propose in Sec. 170.315(g)(35)(iii)(C)(4) that the Health IT Module must support subscriptions as a server according to the requirements in Sec. 170.215(j)(3) to support ``pended authorization responses'' according to at least one of the versions of the implementation specification in Sec. 170.215(j)(3). We request comments on this proposal. Organization of the Proposed Prior Authorization API Criteria In the January 2021 ``Request for Information: Electronic Prior Authorization Standards, Implementation Specifications and Certification Criteria,'' we requested comment on the most appropriate way to structure health IT certification criteria enabling a health care provider to conduct electronic prior authorization transactions (87 FR 3480). We received a wide range of input on this topic with commenters noting that different types of systems, including EHRs, revenue cycle and patient management systems, and third-party applications may be responsible for different elements of the electronic prior authorization workflow. Some commenters recommended that ONC consider proposing individual criteria that map to each of the Da Vinci IGs (the CRD, DTR, and PAS IGs) which we discussed in the RFI and have proposed to adopt in this proposed rule. Other commenters suggested creating more granular certification criteria which reflect specific capabilities and key interactions within the prior authorization workflow, so that these capabilities can be implemented as stand-alone solutions to provide incremental value. The Task Force charged by the HITAC to provide a response to the January 2021 RFI also provided recommendations on this topic.\205\ --------------------------------------------------------------------------- \205\ https://www.healthit.gov/sites/default/files/page/2022-03/2022-03-10_ePA_RFI_Recommendations_Report_Signed_508.pdf. --------------------------------------------------------------------------- In this proposed rule, we have proposed a single prior authorization certification criterion for health care providers in Sec. 170.315(g)(34). However, existing guidance in the Program could provide flexibility around the use of distinct technology products that may be utilized to perform the capabilities that are outlined in the proposed certification criterion. Specifically, health IT developers are permitted to use ``relied upon software'' (76 FR 1276) to demonstrate compliance with certification criteria adopted at 45 CFR part 170, subpart C.\206\ Relied upon software is typically third-party software that is not developed by the health IT developer presenting its health IT for testing and certification. Relied upon software may be used to demonstrate compliance with a portion of an adopted certification criterion or an entire certification criterion. When a health IT developer relies upon software to demonstrate compliance with a certification criterion, such relied upon software must be included in the scope of the certification issued to the Health IT Module or Complete EHR. In cases where a Health IT Module may be [[Page 63591]] paired with multiple ``relied upon software'' products for the same capability, it must be tested with at least one such product to demonstrate compliance with a certification criterion's requirements. Afterwards, the Health IT Module developer is permitted to list all additional ``relied upon software'' products for the same capability paired with the certified Health IT Module without having to test each one with the ONC-ATL. A health IT developer always remains responsible for its product's conformance to a certification criterion even when the ``relied upon software'' contributes to, or is the cause of, a non- conformity. --------------------------------------------------------------------------- \206\ For more guidance on relied upon software, see: https://www.healthit.gov/sites/default/files/relieduponsoftwareguidance.pdf. --------------------------------------------------------------------------- We invite additional comments on the most appropriate way to structure the proposed ``prior authorization API--provider'' certification criterion, as well as the ``prior authorization API-- payer'' certification criterion. Specifically, we are interested in the public's input on how organization of the proposed certification criteria would affect the ability of developers to effectively offer certified health IT products that meet the criteria, and what impact the organization of the proposed criteria would have on customers who may already possess technology products that can be used to conduct electronic prior authorization transactions. We also request comment on whether or to what degree existing guidance for the Program, such as the relied upon software policy described above, would address scenarios in which distinct health IT products are used to support different elements of the prior authorization workflow. Finally, we invite comments on alternative approaches to organizing the ``prior authorization API'' certification criteria. Support for CMS Requirements The ``prior authorization API--payer'' certification criterion proposed in Sec. 170.315(g)(35), if finalized, would support the availability of certified health IT that can enable impacted payers \207\ to meet CMS requirements to implement and maintain a Prior Authorization API as specified in 42 CFR 422.122(b), 431.80(b), 457.732(b), 438.242(b)(7), and 457.1233(d) and 45 CFR 156.223(b), respectively. Specifically, a Health IT Module certified to the ``prior authorization API--payer'' certification criterion would enable payers to make available information about documentation required for approval of any items or services that require prior authorization; support an automated process for prior authorization request and response; and communicate whether the payer approves the prior authorization request (and the date or circumstance under which the authorization ends), denies the prior authorization request (with a specific reason), or requests more information, as required in the CMS Interoperability and Prior Authorization Final Rule (89 FR 8897). --------------------------------------------------------------------------- \207\ As noted above, for the purposes of the CMS Interoperability and Patient Access and Interoperability and Prior Authorization Final Rules discussed in this section, impacted payers include Medicare Advantage (MA) organizations, state Medicaid fee- for-service (FFS) programs, state Children's Health Insurance Program (CHIP) FFS programs, Medicaid managed care plans, CHIP managed care entities, and Qualified Health Plan (QHP) issuers on the Federally-facilitated Exchanges (FFEs). --------------------------------------------------------------------------- The ``prior authorization API--provider'' certification criterion proposed in Sec. 170.315(g)(34), if finalized, would support the availability of certified health IT that can enable health care providers to interact with the APIs established pursuant to the payer API requirements referenced above, using certified health IT. CMS finalized Electronic Prior Authorization measures for the Medicare Promoting Interoperability Program and the MIPS Promoting Interoperability Performance Category in the CMS Interoperability and Prior Authorization Final Rule (89 FR 8909) which are intended to incentivize health care providers to interact with these APIs in order to submit prior authorization requests. If finalized, adopting and using technology certified to this criterion would enable eligible clinicians, and eligible hospitals and CAHs, to complete the prior authorization request actions associated with these measures using certified health IT. Administrative Simplification Requirements Under HIPAA We note that, pursuant to the administrative simplification rules established under HIPAA, the Secretary must adopt electronic standards for use by ``covered entities,'' which is defined as including health plans, healthcare clearinghouses, and certain health care providers.\208\ The two standards adopted for referral certification and authorization transactions under the HIPAA administrative simplification rules (45 CFR 162.1302) include: NCPDP Version D.0 for retail pharmacy drugs; and X12 Version 5010x217 278 (X12 278) for dental, professional, and institutional request for review and response for items and services. HHS has also proposed to adopt the X12 275 standard, which is used to transmit additional documentation to support the exchange of the additional information that is required for prior authorization, in the ``Administrative Simplification: Adoption of Standards for Health Care Attachments Transactions and Electronic Signatures, and Modification to Referral Certification and Authorization Transaction Standard'' proposed rule (87 FR 78438). --------------------------------------------------------------------------- \208\ For more information, see https://www.cms.gov/priorities/key-initiatives/burden-reduction/administrative-simplification. --------------------------------------------------------------------------- Nothing in our proposed certification criteria related to electronic prior authorization would alter requirements for covered entities to use adopted HIPAA transaction standards. Moreover, the FHIR specifications we propose to adopt for these certification criteria would not conflict with the use of the adopted HIPAA standard, and we would expect covered entities using technology certified to these criteria to ensure compliance with applicable requirements. We note that in March 2021, the CMS National Standards Group (NSG), on behalf of HHS, approved an application \209\ from an industry group of payers, providers, and vendors for an exception under 45 CFR 162.940 from the HIPAA transaction standards for Da Vinci payers and their trading partners when using the FHIR standard for prior authorization. Under this exception, the group would test a prior authorization exchange using the HL7 FHIR Da Vinci standard without the X12 278 standard to determine whether this alternative standard for prior authorization could improve efficiency. HHS provides information about requests for exceptions from standards to permit testing of proposed modifications on the CMS HIPAA administrative simplification website.\210\ --------------------------------------------------------------------------- \209\ See https://confluence.hl7.org/display/DVP/Da+Vinci+HIPAA+Exception?preview=/113675673/113675685/Approval%20%232021031001.pdf. \210\ Centers for Medicare & Medicaid Services (2022). Go-to- Guidance, Guidance Letters. Retrieved from https://www.cms.gov/priorities/key-initiatives/burden-reduction/administrative-simplification/subregulatory-guidance/letters. --------------------------------------------------------------------------- On February 28, 2024, CMS NSG, on behalf of HHS, announced an application of enforcement discretion for HIPAA covered entities that implement FHIR-based Prior Authorization APIs as described in the CMS Interoperability and Prior Authorization Final Rule (89 FR 8758).\211\ HHS stated that this action was in response to feedback received on multiple notices of proposed rulemaking and extensive stakeholder outreach and is intended to promote efficiency in the prior authorization [[Page 63592]] process. Specifically, HHS stated that HIPAA Administrative Simplification enforcement action will not be taken against HIPAA covered entities that choose not to use the X12 278 standard as part of an electronic FHIR prior authorization process. HHS will continue to evaluate the HIPAA prior authorization transaction standards, including continuing to seek stakeholder input and evaluating the results of testing an all-FHIR-based transaction. --------------------------------------------------------------------------- \211\ See https://www.cms.gov/files/document/discretion-x12-278-enforcement-guidance-letter-remediated-2024-02-28.pdf. --------------------------------------------------------------------------- v. Provider Directory API--Health Plan Coverage (Sec. 170.315(g)(36)) We propose to adopt a ``provider directory API--health plan coverage'' certification criterion in Sec. 170.315(g)(36) which would specify technical requirements for Health IT Modules that can enable publishing of information regarding the providers that participate in a payer's network. For beneficiary coverage and clinical information to be both useful to and utilized by patients and providers, it is necessary for patients to understand which providers, facilities, and pharmacies are covered by their current or future plan. The proposed certification criterion is based on the HL7 FHIR Da Vinci Payer Data Exchange Plan Net (PDex Plan Net) Implementation Guide version 1.1.0--STU1.1.\212\ We propose, independent of the certification criterion proposal, to adopt this implementation specification in Sec. 170.215(n)(1) and incorporate it by reference in Sec. 170.299. We propose to adopt this implementation specification under PHSA section 3004 and make it available for HHS use. Use of this implementation specification can enable third parties to develop applications through which consumers and providers can query the participants in a payer's network that may provide services that address their healthcare needs. We propose in Sec. 170.315(g)(36) that a Health IT Module certified to the criteria must support the ability to publish a payer's insurance plans, their associated networks, and the organizations and providers that participate in these networks according to at least one of the versions of the implementation specification adopted in Sec. 170.215(n), including the requirements described in the ``Plan-Net CapabilityStatement.'' If we adopt subsequent versions of the PDex Plan Net IG in Sec. 170.215(n), our proposal to require the use of at least one of the versions of the implementation specification adopted in Sec. 170.215(n) would enable health IT developers to use any version adopted at this location, unless we specify an adoption ``expiration'' date, which indicates a certain version of the specification may no longer be used after that date. --------------------------------------------------------------------------- \212\ See https://hl7.org/fhir/us/davinci-pdex-plan-net/STU1.1/. --------------------------------------------------------------------------- Support for CMS Requirements The ``provider directory API--health plan coverage'' certification criterion proposed in Sec. 170.315(g)(36), if finalized, would support the availability of certified health IT that can enable impacted payers \213\ to meet CMS requirements to implement and maintain a Provider Directory API in 42 CFR 422.120, 431.70, 457.760, 438.242(b)(6), and 457.1233(d)(3), respectively. Specifically, a Health IT Module certified to the ``provider directory API--health plan coverage'' certification criterion would facilitate the availability of standardized information about a payer's provider networks, as well as pharmacy directory data, as required in the CMS Interoperability and Patient Access Final Rule (85 FR 25563). --------------------------------------------------------------------------- \213\ As noted above, for the purposes of the CMS Interoperability and Patient Access and Interoperability and Prior Authorization Final Rules discussed in this section, impacted payers include Medicare Advantage (MA) organizations, state Medicaid fee- for-service (FFS) programs, state Children's Health Insurance Program (CHIP) FFS programs, Medicaid managed care plans, CHIP managed care entities, and Qualified Health Plan (QHP) issuers on the Federally-facilitated Exchanges (FFEs). --------------------------------------------------------------------------- We request comments on this proposal. d. Revision and Addition of API Condition and Maintenance of Certification Requirements Given that we have proposed to adopt new certification criteria that would be applicable to certified API technology under the Program, we propose to extend the applicability of the API Conditions of Certification in Sec. 170.404(a) and certain API Maintenance of Certification requirements in Sec. 170.404(b) to Certified API Developers with Health IT Modules certified to the criteria proposed for adoption in Sec. 170.315(g)(20), Sec. 170.315(g)(30)-(36), and Sec. 170.315(j). If our proposals are finalized, this would mean that the API Condition and Maintenance of Certification requirements would include within its scope the certification criteria adopted in Sec. 170.315(g)(7)-(10), Sec. 170.315(g)(20), Sec. 170.315(g)(30)-(36), and Sec. 170.315(j). We propose to make corresponding and conforming edits to Sec. 170.404, including revisions to both Sec. 170.404(a) and in Sec. 170.404(b), to specify which API-related certification criteria apply in the context of each Condition and Maintenance of Certification requirement. We believe this approach is essential to continue to fulfill the statutory requirements set forth in PHSA Sec. 3001(c)(5)(D)(iv), in particular Congress' requirement that a developer of certified health IT has ``published application programming interfaces and allows health information from such technology to be accessed, exchanged, and used without special effort.'' As we described in the ONC Cures Act Final Rule (84 FR 7476 through 7477), we established the API Condition and Maintenance of Certification requirements to, among other outcomes, promote transparency and pro- competitive business practices among Certified API Developers in pursuit of a policy that would result in access, exchange, and use of EHI ``without special effort.'' We believe that these same requirements should apply to developers of these new API-related certification criteria in Sec. 170.315(g)(20) and (g)(30)-(36), and that the proposals to reference these certification criteria in Sec. 170.404 would continue to adhere to our statutory charge to advance nationwide interoperability. We propose in Sec. 170.404(a)(2) to consolidate and establish documentation requirements that are currently required in Sec. 170.315(g)(7)(ii), Sec. 170.315(g)(9)(ii), and Sec. 170.315(g)(10)(viii). Correspondingly, we propose to remove those three specified ``documentation'' paragraphs from those respective certification criteria because the consolidated conformance requirements would now be stated in the proposed Sec. 170.404(a)(2). We believe that these documentation requirements should also pertain to the other API-related criteria we propose to adopt in Sec. 170.315(g)(20), (g)(30)-(36), and Sec. 170.315(j), and we believe that such requirements better fit as a generally applicable API Condition of Certification requirement than a functional requirement specified in each individual API-related certification criterion. Specifically, we propose in Sec. 170.404(a)(2) that a Certified API Developer must publish complete business and technical documentation, including the documentation described in Sec. 170.404(a)(2)(i)-(ii), via a publicly accessible hyperlink that allows any person to directly access the information without any preconditions or additional steps. In Sec. 170.404(a)(2)(i), we propose that this should include technical documentation currently in Sec. 170.315(g)(7), (9), and (10) such as API syntax, function names, required and optional parameters supported and their [[Page 63593]] data types, return variables and their types/structures, exceptions and exception handling methods and their returns. We propose that Sec. 170.315(g)(7)(ii) and Sec. 170.315(g)(9)(ii) be reserved. Further, we propose in Sec. 170.404(a)(2)(i)(B) that this technical documentation should include the software components and configurations that would be necessary for an application to implement in order to be able to successfully interact with the API and process its response(s); and in Sec. 170.404(a)(2)(i)(C) that all applicable technical requirements and attributes necessary for an application to be registered with a Health IT Module's authorization server. We propose to revise Sec. 170.404(a)(2)(ii) to require that API(s) must include complete accompanying business documentation that contains, at a minimum, the existing requirements currently in Sec. 170.404(a)(2)(ii)(A) and (B). In addition to the proposed modifications to Sec. 170.404(a), we propose to revise the Maintenance of Certification requirements for Application Programming Interfaces, in Sec. 170.404(b). Specifically, we propose that the same authenticity verification and registration requirements currently in Sec. 170.404(b)(1) apply to Certified API Developers with a Health IT Module certified to one or more of the certification criteria in of Sec. 170.315(g)(10), (20), (30), (32)- (35). Similarly, we propose in Sec. 170.404(b)(1)(i) that a Certified API Developer is permitted to institute a process to verify the authenticity of API Users so long as such process is objective and the same for all API Users and completed within ten business days of receipt of an API User's request to register their software application for use with the Certified API Developer's Health IT Module certified to any of the certification criteria in Sec. 170.315(g)(10), (20), (30), (32)-(35). We propose that this process shall not apply to API Users that are part of a trust community supported at an API Information Source deployment submitting registration requests conformant to the specifications in Sec. 170.215(o). In Sec. 170.404(b)(1)(ii) we propose that a Certified API Developer must register and enable all applications for production use within five business days of completing its verification of an API User's authenticity, pursuant to paragraph (b)(1)(i) of this section. If the API User is part of a trust community supported at an API Information Source deployment and submitted a valid registration request conformant to the specifications in Sec. 170.215(o), we propose that the application must instead be enabled for production use within one business day. We propose in Sec. 170.404(b)(2) to modify the existing publication and format requirements for service base URLs. We propose to refer to service base URLs as ``API discovery details'' and propose in Sec. 170.404(b)(2)(i)(A) that these must be published publicly and at no charge for all customers regardless of whether the Health IT Module is centrally managed by the Certified API Developer or locally deployed by an API Information Source. We also propose in Sec. 170.404(b)(2)(i)(B) that these API discovery details are reviewed quarterly and updated as necessary. We also propose revisions to the formatting requirements of these API discovery details by adding to the current regulation text in Sec. 170.404(b)(2)(i)-(iii) an option to publish API discovery details and related API Information source details, including the API Information Source's name, location, and facility identifier, according to the ``User-access Brands and Endpoints'' specification in at least one implementation specification adopted in Sec. 170.215(c). We propose this at revised Sec. 170.404(b)(2)(iii) and consolidate the regulation text currently in Sec. 170.404(b)(2)(i)-(iii) as Sec. 170.404(b)(2)(ii)(A)-(C). We propose that publication of API discovery details for patient access applies to Certified API Developers with Health IT Modules certified to either of the criteria in Sec. 170.315(g)(10) and (g)(30) and we have established timelines for Health IT Modules certified to these criteria to conform to requirements in Sec. 170.404(b). Specifically, we propose that for the time period up to and including December 31, 2027, Certified API Developers with Health IT Modules certified to Sec. 170.315(g)(10) must meet either the API discovery detail requirements in (i) and (ii) or the requirements in (i), (iii), and (iv) of this section. On and after January 1, 2028, all Certified API Developers with Health IT Modules certified to Sec. 170.315(g)(10) must meet the requirements in (i), (iii), and (iv) of this section. Certified API Developers with Health IT Modules certified to Sec. 170.315(g)(30) must meet the requirements in (i), (iii), and (iv) of this section. We believe this cadence and combination of requirements will support a gradual improvement in consistently available, standards-based access for patients seeking to access their health information via APIs. These Maintenance of Certification requirements are already established for Certified API Developers with a Health IT Module certified to the certification criterion adopted in Sec. 170.315(g)(10), and we believe that extending these requirements to Sec. 170.315(g)(30) is appropriate because this proposed certification criterion supports patient access to health and administrative (e.g., payer) information. Requirements in Sec. 170.404(b)(1) and (2) facilitate the use of patient-facing applications and enable patient users to discover details necessary to connect to their data using an application of their choice. We request comment on these proposals. In Sec. 170.404(b)(3), we propose new Maintenance of Certification requirements for Certified API Developers with a Health IT Module certified to the certification criteria adopted in Sec. 170.315(g)(32), Sec. 170.315(g)(33), Sec. 170.315(g)(35), or Sec. 170.315(g)(36) to publish API discovery details. We propose in Sec. 170.404(b)(3)(i) that the developer must publicly publish the API discovery details for all its customers, with Health IT Modules certified to Sec. 170.315(g)(32), Sec. 170.315(g)(33), Sec. 170.315(g)(35) or Sec. 170.315(g)(36) regardless of whether the Health IT Modules are centrally managed by the Certified API Developer or locally deployed by an implementer of the Certified API Developer. We propose in Sec. 170.404(b)(3)(ii) that the network information and related API Information Source details, including the API Information Source's name, location, and facility identifier, must be published in an aggregate vendor-consolidated Bundle according to the ``User-Access Brands and Endpoints'' specification in at least one implementation specification adopted in Sec. 170.215(c). In Sec. 170.404(b)(3)(iii) we propose that all API discovery details for payer information published according to this section must be reviewed quarterly and as necessary updated by the Certified API Developer. While we recognize that this will require ongoing coordination between health IT developers and users of the Health IT Modules, as well as regular updates to the publicly available network information, we believe that making such information public is critical to establishing ongoing interoperability of administrative data. We welcome comment on these proposals. Finally, we propose revisions to two key terms in Sec. 170.404(c). We propose to revise certified API technology to mean the capabilities of Health IT Modules that are certified to any of the API-focused certification criteria adopted in Sec. 170.315(g)(7) through (10), (g)(20), (g)(30) through (36), and (j). This revision would support our proposed [[Page 63594]] application of requirements in Sec. 170.404 to the proposed APIs in Sec. 170.315(g) and the proposed modular API capabilities in Sec. 170.315(j). We also propose to revise Certified API Developer to mean a health IT developer that creates ``certified API technology.'' We believe this simplified definition for Certified API Developer will similarly support this term's application to the proposed API capabilities in Sec. 170.315(g) and proposed modular API capabilities in Sec. 170.315(j). We request comment on these proposals. e. Revisions to Real World Testing Requirements The Cures Act requires, as Condition and Maintenance of Certification requirements under the Program, that health IT developers successfully test the real world use of the technology for interoperability \214\ in the type of setting in which such technology would be marketed. As discussed in the ONC Cures Act Final Rule, the objective of real world testing is to verify the extent to which certified health IT deployed in production contexts continues to demonstrate conformance to the full scope of applicable certification criteria and functions with the intended use cases as part of the overall maintenance of a health IT's certification (85 FR 25766). --------------------------------------------------------------------------- \214\ Interoperability is defined in statute in section 3000 of the Public Health Service Act (as modified by section 4003 of the Cures Act) and defined in regulation at 45 CFR 170.102. --------------------------------------------------------------------------- For reasons similar to our proposal to expand requirements in Sec. 170.404 to the proposed certification criteria in Sec. 170.315(g)(20), (g)(30) through (36), and 170.315(j), we propose to revise the real world testing requirements in Sec. 170.405 by adding these proposed certification criteria in Sec. 170.405(a). Given that each of these proposed new certification criteria is focused on interoperability and data exchange, we believe it is important that developers of certified health IT with Health IT Module(s) certified to these criteria participate in both Condition and Maintenance of Certification requirements. Per requirements in Sec. 170.405(b) we also propose that developers of certified health IT with Health IT Modules certified to any one or more of the certification criteria in Sec. 170.315(g)(20), (g)(30) through (36), and 170.315(j) also submit annual real world testing plans as well as annual real world testing results, which applies to any one or more of the criteria referenced in 170.405(a). We note that by including these criteria in Sec. 170.405(a), that health IT developers may voluntarily avail themselves of SVAP flexibility so long as they ensure that their annual real world testing plans and real world testing results submissions address all the versions of all the standards and implementation specifications to which each Health IT Module is certified. Given that we are proposing to reference several certification criteria in Sec. 170.315(j) across various certification criteria in Sec. 170.315(g), we clarify that a health IT developer with Health IT Module(s) certified to any one or more criteria in Sec. 170.315(g) that successfully tests the real world use of those Health IT Module(s) will be considered conformant to the real world testing requirements for the corresponding certification criteria in Sec. 170.315(j). We do not intend for Health IT Modules certified to any certification criterion in Sec. 170.315(g) to submit duplicative real world testing plans or results for corresponding certification criterion in Sec. 170.315(j) and believe this clarification will help reduce potential confusion for developers certified to criteria in Sec. 170.315(g). We request comments on this proposal. f. Addition of Criteria to the Base EHR Definition Two of the certification criteria proposed in this section pertain to certified Health IT Modules intended for use by health care providers, specifically the ``provider access API--client'' and the ``prior authorization API--provider'' certification criteria in Sec. 170.315(g)(31) and Sec. 170.315(g)(34), respectively. We believe both certification criteria reflect fundamental capabilities, which would be appropriate for adoption by any health care provider using certified health IT. Technology certified to the ``provider access API--client'' criterion would enable a provider to receive key clinical and administrative information from a healthcare payer. Technology certified to the ``prior authorization API--provider'' criterion would enable a health care provider to conduct prior authorization requests and related interactions with payers that are widely used today. We propose in Sec. 170.102 in the definition of Base EHR to add the proposed certification criteria in Sec. 170.315(g)(31) and Sec. 170.315(g)(34) to the set of certification criteria adopted by the Secretary that are necessary to meet the Base EHR definition. We propose that the ``provider access API--client'' certification criterion in Sec. 170.315(g)(31) would be necessary to meet the Base EHR definition on and after January 1, 2028. However, for the ``prior authorization API--provider'' certification criterion in Sec. 170.315(g)(34), we propose that this criterion would be necessary to meet the Base EHR definition on and after January 1, 2027. This date is consistent with the policy finalized in CMS Interoperability and Prior Authorization Final Rule, which finalized an Electronic Prior Authorization measure in the Medicare Promoting Interoperability program and the MIPS Promoting Interoperability performance category which program participants must report on beginning with the CY 2027 EHR reporting period and CY 2027 performance period/2029 MIPS payment year, respectively (89 FR 8910). We request comments on this proposal.

1. Insights Condition and Maintenance of Certification Requirements

a. Background The Cures Act specified requirements in section 4002(c) to establish an Electronic Health Record (EHR) Reporting Program to provide reporting on certified health IT in the categories of interoperability, usability and user-centered design, security, conformance to certification testing, and other categories, as appropriate to measure the performance of EHR technology. Data collected and reported would address information gaps in the health IT marketplace and provide insights on the use of certified health IT. In the HTI-1 Final Rule (89 FR 1311), we established the EHR Reporting Program as the ``Insights Condition and Maintenance of Certification'' (also referred to as the ``Insights Condition'') and finalized in Sec. 170.407 the first set of measures to reflect the interoperability category required by section 3009A(a)(3)(A)(iii) of the PHSA. We refer readers to the HTI-1 Proposed Rule (88 FR 23831) for detailed background on how we engaged with the health IT community for the purpose of identifying measures that developers of certified health IT would be required to report on as a Condition and Maintenance of Certification under the Program, and how our proposals to modify the measures that the Urban Institute developed is consistent with section 3009A(a)(4) of the PHSA. Our proposals with respect to each requirement continue to reflect how we propose to [[Page 63595]] modify the set of measures in Urban Institute's final report.\215\ As such, we propose modifications in this proposed rule as part of the next iteration of the Insights Condition and Maintenance of Certification requirements and welcome comments on our proposals below. --------------------------------------------------------------------------- \215\ https://www.urban.org/research/publication/electronic-health-record-ehr-reporting-program-developer-reported-measures. --------------------------------------------------------------------------- b. Process for Reporting Updates In the HTI-1 Proposed Rule (88 FR 23847), we stated that there may be other factors that could impact a developer of certified health IT's ability to easily collect data to comply with the Insights Condition's requirements. For example, a developer of certified health IT may have contracts or business agreements that inhibit the health IT developer's ability to collect data from its customers. We also proposed in the HTI-1 Proposed Rule that in such scenarios, developers of certified health IT would need to renegotiate their contracts. We further explained that we expected developers of certified health IT would work to mitigate any issues and provisions affecting their ability to comply with the Insights Condition requirements. In the HTI-1 Final Rule (89 FR 1347), we did not finalize our proposal to require developers of certified health IT to renegotiate contracts, when needed, with their customers to comply with the Insights Condition requirements. Instead, we finalized in Sec. 170.407(a)(1)(i)(C) that health IT developers will need to provide ONC with information on the degree to which the data they submit are complete, specifically by reporting the percentage of their total customers as represented by hospitals for products used in inpatient settings and clinician users for products used in outpatient settings, that are included in their reported data for each metric for which they submit a response. We stated that the percentage of health care providers that are represented in the data provides transparency regarding the degree to which the data are complete. Detailed information regarding health care providers that are represented in the data would also help us further interpret the results of the data received and allow us to assess whether the data is nationally representative. This would also allow us to report results indicating whether, and how, the data are skewed. Therefore, we propose to add Sec. 170.407(a)(1)(i)(D) to require developers of certified health IT to provide health care provider identifiers (e.g., National Provider Identifier (NPI), CMS Certification Number (CCN), or other type of unique national identifier) for providers included in the data submitted. Note, given this proposal, we propose to make conforming grammatical edits to the list structure in Sec. 170.407(a)(1)(i)(B) and (C) to accommodate the proposed addition of (D). We also propose to revise Sec. 170.407(a)(1)(i)(C) to remove the word ``sites'' from ``hospital sites'' to align with our proposal relating to the minimum reporting qualifications requirement described in detail further below. The additional health care provider identifier information would help determine the representativeness of the data. Using the unique health care provider identifiers, we could link to other data sources such as the National Provider and Payer Enumeration System (NPPES) and CMS program participant data that would allow us to identify the types of providers included in the data. Knowing the different types of providers included in the data would allow us to determine if the data are skewed towards providers with certain characteristics associated with differences in health IT adoption and use, such as size, rural location and ownership.216 217 218 For example, based upon surveys of hospitals, larger hospitals tend to engage more in interoperability compared to smaller hospitals.\219\ If the data disproportionately consist of larger hospitals, this could potentially skew the results towards higher performance on interoperability. To reduce burden, we intend to provide a template for developers of certified health IT to submit the data electronically, in a structured format, if our proposal is finalized. --------------------------------------------------------------------------- \216\ Strawley C., Everson J., Barker W. Hospital use of APIs to Enable Data Sharing Between EHRs and Apps. Office of the National Coordinator for Health Information Technology. Data Brief: 68. 2023. https://www.healthit.gov/data/data-briefs/hospital-use-apis-enable-data-sharing-between-ehrs-and-apps. \217\ Pylypchuk Y., J. Everson. (January 2023). Interoperability and Methods of Exchange among Hospitals in 2021. ONC Data Brief, no. 64. Office of the National Coordinator for Health Information Technology: Washington DC. https://www.healthit.gov/data/data-briefs/interoperability-and-methods-exchange-among-hospitals-2021. \218\ Pylypchuk Y., J. Everson, D. Charles, and V. Patel. (February 2022). Interoperability Among Office-Based Physicians in 2015, 2017, and 2019. ONC Data Brief, no.59. Office of the National Coordinator for Health Information Technology: Washington DC. https://www.healthit.gov/data/data-briefs/interoperability-among-office-based-physicians-2019. \219\ Pylypchuk Y., J. Everson. (January 2023). Interoperability and Methods of Exchange among Hospitals in 2021. ONC Data Brief, no. 64. Office of the National Coordinator for Health Information Technology: Washington DC. https://www.healthit.gov/data/data-briefs/interoperability-and-methods-exchange-among-hospitals-2021. --------------------------------------------------------------------------- We welcome comments on our proposal, and welcome comments on other alternatives that would offer a consistent approach for all health IT developers to report on the representativeness of the data provided to ONC. We continue to believe reporting the percentage of ``clinicians'' (for products primarily used in outpatient settings) and ``hospitals'' (for products primarily used in inpatient settings) in Sec. 170.407(a)(1)(i)(C) is the best approach given that this aligns with CMS programs and is used to determine whether developers meet the threshold for reporting on the Insights Condition of Certification, however, we are open to considering alternatives that provide a consistent manner for developers to provide transparency on the degree to which the data are complete. This may also include removing the requirement for developers to provide the percentage of total customers that are represented in the data in Sec. 170.407(a)(1)(i)(C), and instead only require developers to provide health care provider identifiers if that would provide a more consistent approach across developers and also allow us to gauge the representativeness of the data while reducing burden. We seek public feedback on approaches to understand the types and number of providers that are included in the data submitted, relative to the broader population of providers using the products of a developer of certified health IT. We also request comments for alternatives that may shift measurement from provider- based measures to patient-centered measures such as percentage and/or number of encounters or patients included in the data. In the HTI-1 Final Rule (89 FR 1346), we finalized the Insights Condition reporting frequency to annually (once per year) for any Health IT Module that has or has had an active certification at any time under the ONC Health IT Certification Program during the prior six months in Sec. 170.407(b). We stated that developers of certified health IT who do not meet the minimum reporting qualifications would submit a response to specify that they do not meet the qualifications under the Insights Condition. In this way, all developers of certified health IT would report on all measures, even if some report that they do not meet the minimum reporting qualifications (89 FR 1345). We propose to revise Sec. 170.407(b)(1) to make clear that all developers must provide responses to the Insights Condition of Certification on an annual basis regardless of how long a developer [[Page 63596]] has or has had an active certification under the Program. Since all developers of certified health IT within the Program are required to submit a response, as finalized in HTI-1 Final Rule (89 FR 1345), we believe this revision will simplify and clarify expectations. We propose in Sec. 170.407(b)(1)(ii) that the response a developer of certified health IT submits per the requirements of the Insights Condition, must be applicable to all their certified health IT as of January 1st of each year, beginning January 2026. For example, a developer of certified health IT who is submitting their response July 2027, would include data from all their applicable certified health IT from the prior year between January to December 2026 for their July 2027 submission. This has been the expectation from what we finalized in HTI-1 (89 FR 1348); however, we believe codifying the date of January 1st is necessary so that all health IT developers can determine whether they are required to report on a measure 18 months in advance of the response submission. This is similar to real world testing reporting requirements which has a specified date for all developers of certified health IT to assess their eligibility on submitting a real world testing plan per Sec. 170.405. We strongly encourage developers of certified health IT to assess whether they meet the minimum reporting qualifications for the Insights Condition on January 1st of each year beginning in 2026. We intend to provide resources, outreach efforts, and other communications to aid developers of certified health IT in understanding the Insights Condition requirements. Our goal is to ensure there is adequate time allotted for reporting, clarity related to requirements, and an ability to address developers' questions and educational needs well in advance of any reporting deadlines. We welcome comments on our proposal and welcome alternative approaches that helps us achieve this goal. We include a table below as an example, and welcome comments on this approach and the proposed date, such as whether the date of January 1st should be earlier in the year (such as August 31st to align with Real World Testing eligibility date) \220\ to allow more time for developers to assess whether or not it meets the minimum reporting requirements for the upcoming data collection period. --------------------------------------------------------------------------- \220\ See HTI-1 Final Rule Inherited Certified Status 89 FR 1198 [GRAPHIC] [TIFF OMITTED] TP05AU24.001 We also propose in Sec. 170.407(b)(2) that if developers update their certified health IT using Inherited Certified Status after January 1 of the year prior in which the responses are submitted, a health IT developer must include the newer version of the certified Health IT Module(s) in its annual responses to the Insights Condition of Certification. Many health IT developers update their certified Health IT Module(s) on a regular basis, leveraging the flexibility using Inherited Certified Status. This updating can cause an existing certified Health IT Module to be recognized as new within the Program due to the way ONC issues certification identifiers, and could result in existing certified Health IT Modules being inadvertently excluded from the Insights Condition requirements. In the HTI-1 Final Rule (89 FR 1344), we stated that we intend to make responses (the metrics and required documentation) to the Insights Condition made publicly available on ONC's website. We also stated that if health IT developers wish to provide additional information as part of the optional documentation, we strongly encourage them to not include any proprietary, trade secret, or confidential information in their submission. We also indicated that we intend to provide a method for health IT developers to first indicate whether they plan to share proprietary, trade secret, and/or confidential information for purposes of either required or optional documentation, and if a health IT developer provided an affirmative indication, ONC would engage the developer in dialogue about potential alternative means of meeting either required documentation requirements or providing optional documentation (e.g., in other generalized or descriptive ways that may achieve the same goal) (89 FR 1344 through 1345). To improve alignment and consistency with ONC's other certification requirements, we propose to revise Sec. 170.407(a)(1)(i)(B) to specify that documentation must be available via a publicly accessibly hyperlink instead. We note that this applies to both required and optional documentation. This avoids health IT developers from sharing any potential proprietary, trade secret, and/or confidential information with ONC. We note that this process is consistent with other documentation reporting processes that are part of the Program. c. Minimum Reporting Qualifications In the HTI-1 Final Rule (89 FR 1345 through 1346), we finalized minimum reporting qualifications in a way that does not unduly disadvantage small and startup developers of certified health IT. We finalized in Sec. 170.407(a)(2) that a developer of certified health IT must have at least 50 hospital sites or 500 individual clinician users across the developer's certified health IT to report on the measure. We noted that the 50 hospital sites threshold is applicable to Health IT Modules used in inpatient or emergency department settings, while the 500 individual clinician users' threshold is applicable to Health IT Modules used in outpatient/ambulatory settings (non- inpatient). We propose to revise Sec. 170.407(a)(2) by removing ``sites'' from hospital sites as the term could be misinterpreted. [[Page 63597]] In addition, to ensure consistency in how health IT developers are interpreting and reporting on these terms, and to ensure there is no confusion regarding the types of hospitals and clinicians included, we clarify that the term ``hospital'' refers broadly to include various types of hospitals and is not limited to non-Federal acute care hospitals. This could include (but is not limited to) long term care hospitals, critical care hospitals, federally owned hospitals such as those operating under the U.S. Department of Veterans Affairs (VA), the U.S. Department of Defense (DOD), or the Indian Health Service (IHS), children's hospitals, psychiatric hospitals, etc. These hospitals could be identified with a CMS Certification number (CCN) or other unique identifier such as NPI or the American Hospital Association identifier. We clarify the term ``clinician users,'' to include health care professionals consisting of a variety of backgrounds, including but not limited to: Physicians (including Doctor of Medicine, osteopathy, dental surgery, dental medicine, podiatric medicine, and optometry) Osteopathic practitioners Chiropractors Physician assistants Nurse practitioners Clinical nurse specialists Certified registered nurse anesthetists Physical therapists Occupational therapists Clinical psychologists Qualified speech-language pathologists Qualified audiologists Registered dietitians or nutrition professionals Clinical social workers Certified nurse midwives Although we seek to broadly define both ``hospitals'' and ``clinicians'' we realize that there may be benefits to aligning these terms with existing definitions as these are known and have been utilized over time. We are considering various options regarding whether to align the minimum reporting qualifications with definitions established for hospitals and clinicians by CMS, or in the Public Health Service Act (PHSA). For example, we are considering referring to the definition of ``health care provider'' as defined in section 3000(3) of the PHSA for ``hospitals'', however, this definition may be too broad for the purposes of the Insights Condition. We are also considering the definition of ``clinicians'' as defined by CMS \221\ in their Merit-based Incentive Payment System (MIPS) program which would provide alignment and scope for provider types but may also be too restrictive since we require reporting from developers beyond those participating under CMS programs. Although the types of clinicians we provided as examples above are defined by CMS as ``clinicians'', we do not wish to limit reporting for the Insights Condition to data that only relates to those participating in CMS programs given that many clinicians do not participate fully in these programs.\222\ We seek comment on whether to keep our approach, or to align it with existing definitions to provide greater clarification and alignment with other requirements. Commenters are encouraged to specify alternatives that we should consider that would bring consistency and comparability across developers who will report under the Insights Condition. We are also considering and seek input from commenters on excluding clinicians who may only have an administrative role, which we would define as a clinician who does not treat patients. We note that this exclusion would not apply to a clinician conducting clinical research if the clinician directly treats patients. --------------------------------------------------------------------------- \221\ https://qpp.cms.gov/mips/how-eligibility-is-determined. \222\ Apathy NC, Everson J. High Rates of Partial Participation in The First Year of The Merit-Based Incentive Payment System. Health Aff (Millwood). 2020 Sep;39(9):1513-1521. doi: 10.1377/ hlthaff.2019.01648. PMID: 32897783; PMCID: PMC7720898. --------------------------------------------------------------------------- d. Measure Updates Individuals' Access to Electronic Health Information Through Certified Health IT Measure In the HTI-1 Final Rule (89 FR 1314), we finalized the ``individuals' access to electronic health information through certified health IT'' measure in Sec. 170.407(a)(3)(i), which states that if a health IT developer has a Health IT Module certified to Sec. 170.315(e)(1) or (g)(10) or both, the developer must submit responses for the number of unique individuals who access electronic health information (EHI) overall and by different methods of access through certified health IT. We specified that the related metrics only count individuals' access to their EHI and stated in the HTI-1 Final Rule that we may incorporate patient-authorized representatives in future rulemaking (89 FR 1315). Therefore, we propose to revise Sec. 170.407(a)(3)(i) to include both individuals and individuals' authorized representatives accessing their EHI (rather than just individuals alone). We believe it would be beneficial to align our measure with the Medicare Promoting Interoperability Program (PI) Measure for patient access (``Provide Patients Electronic Access to Their Health Information''),\223\ which counts access by patients or their authorized representatives for measuring patient access using portals or apps. Therefore, we propose to expand the measuring of access to include access by individuals or their authorized representatives in Sec. 170.407(a)(3)(i). We do not expect this additional measurement specificity will add substantive development effort for health IT developers as this proposal would align with how CMS operationalizes their measure for patient access. --------------------------------------------------------------------------- \223\ https://qpp.cms.gov/docs/pi_specifications/Measure%20Specifications/2023MIPSPIMeasuresProvidePatientsElectronicAccess.pdf. --------------------------------------------------------------------------- C-CDA Reconciliation and Incorporation Through Certified Health IT Measure In the HTI-1 Final Rule (89 FR 1317), we finalized the ``consolidated clinical document architecture (C-CDA) problems, medications, and allergies reconciliation and incorporation through certified health IT'' measure in Sec. 170.407(a)(3)(ii). The measure is intended to capture the use of C-CDAs in alignment with capabilities specified for the ``clinical information reconciliation and incorporation'' certification criterion in Sec. 170.315(b)(2). Given the proposed updates to Sec. 170.315(b)(2) discussed elsewhere in this proposed rule, we also propose conforming updates for this measure to ensure alignment with the certification criterion. We refer readers to section III.B.7 of this proposed rule for detailed discussion on the proposed revisions specific to Sec. 170.315(b)(2). Therefore, we propose to revise the name of this measure to ``C-CDA reconciliation and incorporation through certified health IT'' in Sec. 170.407(a)(3)(ii). In further alignment with the proposed revisions to the certification criteria in Sec. 170.315(b)(2), we propose to require developers to submit responses on specific data classes and elements from C-CDA documents obtained and subsequently reconciled and incorporated both through manual and automated processes in Sec. 170.407(a)(3)(ii)(E). Note, given this proposal, we propose to make conforming grammatical edits to the list structure in Sec. 170.407(a)(3)(ii)(C) and (D) to accommodate the proposed addition of (E). If finalized as proposed in Sec. 170.407(a)(3)(ii)(E), we would also provide technical updates resulting in [[Page 63598]] additional metrics in the accompanying measure specification sheet which we discuss in further detail below under ``technical updates.'' To provide adequate time for associated technical development and then reporting, we propose in Sec. 170.407(b)(1)(i)(D) that any metrics in the accompanying measure specification sheet related to Sec. 170.407(a)(3)(ii)(E) would be reported beginning July 2030, with data collection starting in 2029. We expect that several developers would likely provide information similar to the metrics described above in their 2023 Real World Testing Results, which would indicate the feasibility of generating these metrics.\224\ We welcome comments on our proposals. --------------------------------------------------------------------------- \224\ https://www.eclinicalworks.com/wp-content/uploads/2024/01/eCW-Real-World-Testing-2023-Results-Report-Jan-2024.pdf. https://www.epic.com/content/epiccare2023results.pdf. https://www.oracle.com/a/ocom/docs/industries/healthcare/2023-cerner-real-world-testing-results.pdf. https://www.azaleahealth.com/wp-content/uploads/2024/01/2023-RWT-Results-Report-Azalea-EHR.pdf. https://cantatahealth.com/wp-content/uploads/2024/01/Cantata-Health-Real-World-Testing-Results.pdf. --------------------------------------------------------------------------- Technical Updates in Measure Specification Sheets As proposed above, the proposed ``individuals' access to electronic health information through certified health IT'' measure consists of three metrics, as specified in the measure specification sheet, one of which is the number of unique individuals who accessed their EHI using technology certified to the ``standardized API for patient population services'' under Sec. 170.315(g)(10). As we stated in the HTI-1 Final Rule (89 FR 1313), the measure specification sheets provide granular definitions and other information needed to operationalize the metrics to ensure they are implemented in a consistent manner across health IT developers. In the measure specification sheet, we defined measuring access to EHI for this measure by counting an individual's authorization, as indicated by an access token, at least once during the reporting period.\225\ We intend to modify this definition in an updated version of the measure specification sheet as a technical update as it does not change the substance of this measure, since there may be instances where individuals authorize access to their data (via an access token) but no requests are made to retrieve the data. Given that our intent is to measure individuals' access to EHI (versus just authorizing access), we plan to update this definition in the measure specification sheet for this metric to further specify that access to EHI should be measured by counting the number of individuals where at least one FHIR resource was returned when using the ``standardized API for patient population services'' under Sec. 170.315(g)(10) during the reporting period. --------------------------------------------------------------------------- \225\ https://www.healthit.gov/sites/default/files/page/2023-12/Measure_Spec_Individual_Access_508.pdf. --------------------------------------------------------------------------- We request comment on whether this definition should be updated in the measure specification in this manner, or alternatively, whether we should update it so that access to EHI is measured by counting the number of individuals where at least one FHIR request was made to access information using the ``standardized API for patient population services'' under Sec. 170.315(g)(10) during the reporting period. We acknowledge that there may be concerns related to defining in terms of FHIR requests as we may technically be including unauthorized requests as a measure of access to EHI. We welcome comments and suggestions regarding modifying the original definition. As stated above, our website at the following link (www.healthit.gov/proposedrule) will have an accompanying measure specification sheet reflecting the technical specifications related to the substantive proposals in this proposed rule for commenters to view and consider. We refer readers to the HTI-1 Final Rule (89 FR 1312) where we explained that while the substantive requirements for each measure are defined through rulemaking, we determined that measure specification sheets are a logical and accessible method for the public to view the technical specifications that support those requirements. We stated in the HTI-1 Final Rule (89 FR 1322) that if regulatory baselines associated with the metrics change in the future--such as a revision to a criterion through notice and comment rulemaking--the measure specification would also be changed to ensure alignment with the revised criterion. Therefore, we expect to update the metrics for the proposed ``C-CDA reconciliation and incorporation through certified health IT'' measure, within the accompanying measure specification sheet to align with the proposed broader set of data referenced by the criterion specified in Sec. 170.315(b)(2) if finalized as proposed. As stated above, the accompanying measure specification sheet reflecting the technical updates to align with the proposed broader set of data in this proposed rule will be available on ONC's website for review to support public comment in a transparent manner. Specifically, we intend to replace references in the measure specification sheet for problems, medications, and allergies and intolerances with a reference to the proposed data specified in Sec. 170.315(b)(2) and, consistent with the policy established in the HTI-1 Final Rule (see 89 FR 1312), we intend to continue to align measure specification sheets with any modifications to certification criteria finalized via notice and comment rulemaking--in this instance, specifically for Sec. 170.315(b)(2). The specific data classes and elements proposed in Sec. 170.407(a)(3)(ii)(E), that we intend to list in the measurement specification sheet as technical updates, are selected from the additional data that would be included in proposed Sec. 170.315(b)(2) listed below: The data elements Substance (Medication) and Substance (Drug Class) in the Allergies and Intolerances data class. The data elements Patient Goals and SDOH Goals in the Goals data class. The data element Immunizations in the Immunizations data class. The data element Values/Results in the Laboratory data class The data element Medications in the Medications data class. The data element Unique Device Identifier--Implantable for a patient's implantable device(s) in the Medical Devices data class. The data element Assessment and Plan of Treatment in the Assessment and Plan of Treatment data class. The data element Problems and SDOH Problems/Health Concerns in the Problems data class. We would provide technical updates resulting in additional metrics in the accompanying measure specification sheet that capture (1) the number of specific data elements obtained in the reporting period, and (2) the reconciliation of specific data, such as the number of problems reconciled and incorporated by various means. Together, this data would allow ONC to calculate how often problems and other data elements are reconciled and incorporated by various means using the number of each data element obtained and other existing metrics (such as the number of encounters) as denominators. We request comment on whether that approach would provide beneficial information commensurate with the potential burden for developers. Given the number of data elements that Health IT Modules certified to [[Page 63599]] Sec. 170.315(b)(2) would be able to reconcile and incorporate following the proposed revisions for the certification criteria, we have specified a limited set of Data Elements and Data Classes for which developers would count the number of Elements obtained and the number of Elements reconciled and incorporated for the Insights Condition in the measurement specification accompanying this proposed rule. We request comment on the specific Data Classes or Elements on which such metrics should focus. For instance, metrics specifically focused on reconciliation of medications may provide the most value in informing how often medication information is updated to accurately reflect care received from other organizations and allow for effective decision support; in contrast, metrics on reconciliation and incorporation of vital signs may provide relatively limited value. We also request comment on whether metrics should focus on specific data elements or should aggregate data elements to the data class level. For example, it may be more valuable and feasible to include a metric on the aggregate total number of substance (Medication) and substance (Drug Class) data elements within the Allergies and Intolerances data class rather than two separate metrics, one focused on Substance (Medication) and another focused-on Substance (Drug Class). We request comment on the feasibility and value of separate metrics by Data Element and aggregate elements by some or all Data Elements within a Data Class, which may differ by specific Element and Class. We are also considering approaches to capture use of the proposed requirements for Sec. 170.315(b)(2), if finalized as proposed, to support automatic reconciliation and incorporation in the accompanying measure specification sheet. As in prior versions of the measurement specification, the metric on the number of total C-CDAs obtained equals the sum of the metric on the number of total C-CDA documents obtained that were pre-processed and the metric on the number of total C-CDA documents obtained that were not pre-processed. We clarify that all documents for which reconciliation and incorporation is completed through fully automated processes would be considered to have been pre- processed for the purpose of this metric. The measurement specification sheet further differentiates four metrics for pre-processed C-CDA documents: the first and second metrics respectively count pre-processed C-CDA documents that had data reconciled and incorporated via manual processes and fully automated processes, and the third and fourth metrics respectively count pre- processed C-CDA documents that were determined to have no data that modifies the patient record through manual processes and fully automated processes. These four metrics address pre-processed C-CDA documents that are manually acted upon or fully automated for reconciliation and incorporation but do not capture those C-CDAs that were obtained and pre-processed but not further acted upon by manual or fully automated processes. The metric on the number of total C-CDA documents obtained that were not pre-processed is further differentiated by two metrics: the first metric counts C-CDA documents that were not pre-processed that had data reconciled and incorporated via manual processes, and the second metric counts C-CDA documents that were not pre-processed that were determined to have no data that modifies the patient record through manual processes. These two metrics account for all C-CDAs that are obtained, not pre-processed, and are then acted upon and do not include those C-CDAs that are obtained, not pre-processed, and not acted upon. While these sets increase the number of metrics to report, we believe they will clarify and simplify measuring and categorizing C- CDA documents. In the HTI-1 Final Rule, we defined ``Reconciled and Incorporated via Any Method'' to be an approach to reconciling and incorporating information in the Health IT Module, including but not limited to, manual processes performed by a clinician or their delegate only; a mix of manual and automated processes; or fully automated processes (89 FR 1319). Given the focus on automatic reconciliation and incorporation capabilities in this proposed rule for Sec. 170.315(b)(2), we anticipate aligning the measure specification sheet by dividing the metrics that call for reporting on the total number of C-CDA documents that were reconciled and incorporated by ``any method'' into two categories: (1) C-CDA documents where data were reconciled and incorporated via manual processes performed by a clinician or their delegate only; and (2) a C-CDA documents where any data was reconciled and incorporated via fully automated processes. These additional metrics are intended to generate insight into the use of automatic capabilities and how often C-CDAs are reconciled and incorporated by fully automatic means. We have chosen these two categories to capture instances where the reconciliation and incorporation process is at least partly completed by automated means and because we believe that instances in which all data contained in a C-CDA are reconciled and incorporated via fully automated processes will be rare given the scope of data proposed to be included in the proposed Sec. 170.315(b)(2). Alternatively, we could include an additional metric in the measure specification sheet to capture documents in which data is reconciled and incorporated through a mix of manual and automated processes, which would occur, for example, when problems were reconciled by automated processes and medications were reconciled by manual processes. We also intend to complement the existing metric focused on C-CDA documents that were determined to have no new information by pre- processes or fully automated processes with an additional metric. The additional metric would capture the number of C-CDA documents that were determined to have no new information by manual processes performed by a clinician or their delegate only. These two metrics focused on determining that there was no new information would therefore directly mirror the two metrics focused on reconciliation and incorporation following pre-processes. In revising these metrics, we are also considering alternatives that would describe the varied ways in which data contained within C-CDAs could lead to modification or reconciliation with the patients record. We request comment on whether metrics in the updated measure specification sheet that include the term 'no new data' clearly exclude instances where information in C- CDAs lead to a change to the patient's record. For example, if information in the patient record is deleted or modified in response to information in the C-CDA, the intention is that this be counted as an instance where information is reconciled and incorporated (either via manual or automated processes) and NOT as an instance where documents were determined to have no new data. If the current metrics are not clear, would it be more effective to revise the metrics on ``no new data'' as listed below: Number of total C-CDA documents obtained that were pre- processed and determined to have no data specified in Sec. 170.315(b)(2) that modifies the patient record by manual processes performed by a clinician or their delegate. Number of total C-CDA documents obtained that were pre- processed and [[Page 63600]] determined to have no data specified in Sec. 170.315(b)(2) that modifies the patient record by pre-processes or fully automated processes. Number of total C-CDA documents obtained that were not pre-processed and determined to have no new data specified in Sec. 170.315(b)(2) that modifies the patient record via manual processes performed by a clinician or their delegate only. As noted earlier, please see the measure specification sheet that will be posted on ONC's website for review. We request public comment on the definitions provided in that measure specification sheet for manual processes, and fully automated process as well as the feasibility of separately measuring those processes. We also request comment on whether the resulting separate metrics would effectively capture the use of the proposed new capabilities to automatically reconcile and incorporate information for Sec. 170.315(b)(2), and request comment on the value of including a metric capturing when a ``mix'' of automated and manual processes were used to reconcile and incorporate data. We also plan to make a technical update by revising the number of unique patients with an associated C-CDA document measure to instead capture the number of unique patients with an encounter and associated C-CDA document. The revised metric would be a direct subset of the existing metric Number of Unique Patients with an Encounter. The current metric comprehensively captures the number of patients with C- CDAs but may include some C-CDAs for patients who are not treated by a provider using the product during the reporting period. We do not anticipate any change in burden, and are requesting comment on the relative value of the altered metric. In the HTI-1 Final Rule (89 FR 1326), we finalized the ``use of FHIR in apps through certified health IT'' in Sec. 170.407(a)(3)(iv). This measure captures the volume and type of FHIR resources transferred to apps from certified health IT relative to the number of active certified API technology deployments. We intend to make a technical update in the accompanying measure specification sheet to provide additional implementation information specifying that reporting by user type should be done according to three mutually exclusive categories: patient-facing only, non-patient facing only, and both patient-facing and non-patient facing. In the HTI-1 Final Rule (89 FR 1332), we finalized the ``immunization administrations electronically submitted to immunization information systems through certified health IT'' measure in Sec. 170.407(a)(3)(vi). We stated that this measure would report on the volume of immunization administrations electronically submitted to an immunization information system through certified health IT. In the accompanying measure specification sheet, we indicated that the number of immunizations administered that were electronically submitted successfully to IISs overall was defined as the total number of messages submitted to IISs, minus acknowledgements with the error of severity level E. We intend to make a few technical updates to this measure specification sheet. First, we intend to add metrics to separately count the number of immunizations administered electronically submitted to IISs that returned with an acknowledgement with the error of severity level E during the reporting period overall, and by IIS and age category. These additional metrics would enable us to identify potential issues associated with submissions to the IIS. We do not expect any additional burden associated with reporting this metric. We also request comment on the value and burden associated if we have the metrics count the immunizations administered electronically returned by their acknowledgement code (by IIS and age) instead, which would allow us to understand the number of messages that were rejected, had errors, and were accepted by IIS and age. We also intend to make another technical update to the measure specification sheet by adding metrics to separately count the number of immunizations administered that were electronically submitted to IIS where an acknowledgement from an IIS is not received by certified health IT overall, and by IIS and age category. The current measure specification sheet indicates health IT developers optionally report on number of submissions that did not receive acknowledgement as part of the supplemental documentation. These separate metrics would enable monitoring the occurrence of these communication failures between certified health IT and IIS more systematically. We do not expect substantive additional burden associated with this metric. We also request comment on the value and burden associated with reporting a count of the subset of messages sent to third party intermediaries where the third-party intermediary does not provide an acknowledgement that the message was sent to an IIS. Finally, we intend to make a technical update that would clarify that the immunization administration submitted would include HL7 Z22 messages, and request comment on this approach. This aligns with the ``immunization history and forecasts through certified health IT'' measure specification sheet where we indicate that ``the successful response received from IIS'' include HL7 Z42 and Z32 messages. In the HTI-1 Final Rule (89 FR 1336), we finalized the ``immunization history and forecasts through certified health IT'' measure in Sec. 170.407(a)(3)(vii). This measure captures the use of certified health IT to query information from an IIS under the ``transmission to immunization registries'' (Sec. 170.315(f)(1)) criterion. In the accompanying measure specification sheet, we indicated that the number of immunization queries sent to IISs overall metric would be defined as the total number of messages sent to IISs, minus acknowledgements with errors (severity level E). We intend to make a technical update and modify this definition in the measure specification sheet as it does not change the substance of this measure. We plan to update this definition so that the number of immunization queries sent to IISs overall metric should be measured by only counting the total number of immunization queries sent to IISs during the reporting period. This metric no longer requires subtracting the number of acknowledgements with the error of severity level E. Instead, we are adding separate metrics in the measure specification sheet which would report on the total number of queries responses that returned with acknowledgements that had an error of severity level E, overall and by IIS, during the reporting period. This would enable us to understand how many queries were rejected by an IIS (as indicated by an ``E'' code) during the reporting period. We do not expect any additional burden associated with metric. We also plan to make a technical update to the definition of ``queries sent'' to IISs such that the definition of queries sent applies to HL7 Z34 and HL7 Z44 messages. This approach would provide consistency in how queries sent are defined across developers. Additionally, it would align the definition of ``queries sent'' with ``successful response received from IIS,'' which is based upon the receipt of HL7 Z42 and Z32 messages. We also request comment on the value and burden associated if we have the metrics count the query responses returned by their acknowledgement code (by IIS) instead, [[Page 63601]] which would allow us to understand the number of queries sent where data was found, no data was found, or multiple candidates exist, or where query messages that were rejected, had errors, and were accepted by IIS. In the HTI-1 Final Rule (89 FR 1338) we also received a couple comments noting that a significant portion of messaging failures are communication failures where there will be no response received. A commenter suggested that messages with no response from the IIS (in the case of downtime, for example) would be considered successful (89 FR 1338). In response, we stated that at this time, we will not require health IT developers to provide separate counts for communication failures and counts of the descriptive context levels, and encouraged developers capture information about communication failures as their functionality permits and include this explanation in the supplemental documentation. We also stated that we would collaborate with the community to monitor how these instances impact the measure's interpretation and determine if it should be revised in the future. Given the potential value of understanding the frequency of these communication failures, we plan to make a technical update in the accompanying measure specification sheet to create additional metrics which would report on the total number of queries sent but where no acknowledgement was received from the IIS overall, and by IIS. The separate metric to count no acknowledgements would allow us and the CDC to monitor the occurrence of these communication failures between certified health IT and IIS rather than relying on supplemental reporting to gather this information. We do not expect substantive additional burden associated with this metric. We also request comment on the value and burden associated with reporting a count of the queries sent to third party intermediaries where the third-party intermediary does not provide an acknowledgement the query was sent onto an IIS.

2. Attestations Condition and Maintenance of Certification Requirements

The Cures Act amended section 3001(c)(5) of the PHSA by adding the requirements that a health IT developer, as a Condition and Maintenance of Certification requirement under the Program, provide assurances to the Secretary, unless for legitimate purposes specified by the Secretary, that it will not take any action that constitutes information blocking as defined in section 3022(a) of the PHSA, or any other action that may inhibit the appropriate exchange, access, and use of EHI. In the ONC Cures Act Final Rule, we established both Assurances (Sec. 170.402) and Attestations (Sec. 170.406) Conditions and Maintenance of Certification requirements (88 FR 75718 and 88 FR 25781, respectively). In the HTI-1 Proposed Rule (88 FR 23782) and Final Rule (89 FR 1237), we proposed and finalized the adoption of the certification criterion, ``decision support interventions'' in Sec. 170.315(b)(11) as part of the ``care coordination certification criteria,'' in Sec. 170.315(b). In the HTI-1 Final Rule, we narrowed the overall scope of technologies impacted by finalized requirements in Sec. 170.315(b)(11) (89 FR 1251 through 1252). We finalized minimal, uniform requirements for all Health IT Modules certified to Sec. 170.315(b)(11) while also maintaining a construction that enables a developer of certified health IT to certify a Health IT Module to Sec. 170.315(b)(11) without being obligated to author, develop, or otherwise directly provide Predictive DSIs to its customers. Specifically, we finalized a configuration nexus for several requirements in Sec. 170.315(b)(11) that centered on whether the developer of certified health IT supplied a Predictive DSI as part of its Health IT Module. We also finalized in the HTI-1 Final Rule a supportive Maintenance of Certification requirement as part of the Assurances Condition of Certification in Sec. 170.402(b) for Sec. 170.315(b)(11). We finalized in Sec. 170.402(b)(4) that starting January 1, 2025, and on an ongoing basis, developers of Health IT Modules certified to Sec. 170.315(b)(11) must review and update, as necessary, source attribute information in Sec. 170.315(b)(11)(iv)(A) and (B), risk management practices described in Sec. 170.315(b)(11)(vi), and summary information provided through Sec. 170.523(f)(1)(xxi) (89 FR 1253 through 1254). These policies establish ongoing requirements for developers of certified health IT with Health IT Modules certified to Sec. 170.315(b)(11) to address circumstances where a developer chooses to supply a Predictive DSI as part of its Health IT Module after its initial certification to Sec. 170.315(b)(11), as well as circumstances where a developer that formerly supplied a Predictive DSI as part of its Health IT Module when initially certifying to Sec. 170.315(b)(11) no longer chooses to do so. We propose to add a conforming update to the Attestation Condition of Certification by revising Sec. 170.406(a)(2) to address the Assurance Maintenance of Certification requirement in Sec. 170.402(b)(4). We note that as a function of providing attestations twice yearly, developers of certified health IT with Health IT Modules certified to Sec. 170.315(b)(11) would be expected to affirm conformance to the Assurances Maintenance of Certification requirement in Sec. 170.402(b)(4); specifically, they would attest that they have reviewed and updated, as necessary, the required attribute information and documentation during the time covered by the attestation. We welcome comment on this proposal.

1. Program Correspondence

We propose to revise the Program correspondence provision (Sec. 170.505(a)(2)) to clarify that under Program regulations, the applicant for ONC-Authorized Testing Lab (ONC-ATL) status, the applicant for an ONC-Authorized Certification Body (ONC-ACB), an ONC-ONC-ACB, an ONC- ATL, health IT developer or any party to proceeding under subpart E of part 170 will be considered to have received correspondence or other written communications from ONC or the National Coordinator when the first of the following three scenarios occurs: (1) the date on which ONC or the National Coordinator receives a response to the correspondence via written or verbal communication methods; (2) the date of the delivery confirmation to the address on record for correspondence sent by express or certified mail; or (3) the date of the seventh business day after the date on which the email, express, or certified mail was sent. ONC explained in the ONC Cures Act Proposed Rule preamble that ``we consider a `business day' to include the normal workdays and hours of operation during a week (Monday through Friday), excluding Federal holidays and weekends.'' \226\ We propose to codify in 45 CFR 170.102 a definition of ``business days'' that would include the same days as our explanation in the ONC Cures Act Proposed Rule. ONC's definition of business days for purposes of 45 CFR part 170 would also include those days on which the Office of Personnel Management has announced that Federal agencies in the Washington, DC area are closed, reflecting the nationwide scope of the Program. The ``business days'' definition proposed in Sec. 170.102 would provide clarity about [[Page 63602]] which days would be counted when determining the date of the seventh business day after the date on which the email, regular, express, or certified mail was sent, as proposed in Sec. 170.505(a)(2)(iii). --------------------------------------------------------------------------- \226\ https://www.federalregister.gov/d/2019-02224/p-889. --------------------------------------------------------------------------- In the ONC Cures Act Proposed Rule at 84 FR 7503, referencing a statement the Enhanced Oversight and Accountability Final Rule (EOA Final Rule) (81 FR 72404), we signaled our intent to send notices of potential non-conformity, non-conformity, suspension, proposed termination, and termination via certified mail (81 FR 72429). We solicited comments on the ONC Cures Act Proposed Rule regarding the nature and types of non-conformities with the Conditions and Maintenance of Certification requirements that ONC should consider in determining the method of correspondence. Specifically, we asked whether certain types of notices under direct review should be considered more critical than others and, thus, might require a specific method of correspondence (84 FR 7504). In the ONC Cures Act Final Rule, we finalized the proposal to use the provisions in Sec. 170.505 for correspondence regarding compliance with the Conditions and Maintenance of Certification requirements with minor revisions outlining specific considerations for when we would provide notice beyond email (85 FR 25784). When we finalized our proposal in the ONC Cures Act Final Rule, we did not anticipate the several challenges we encountered with certain correspondence beyond email during the COVID-19 pandemic. As the volume of correspondence and communication required to fulfill ONC review and enforcement responsibilities for the Conditions and Maintenance of Certification requirements (subpart D of 45 CFR part 170) has increased, we have experienced difficulties with delivery of paper- based correspondence that we did not experience with email. To avoid undue delays in addressing non-conformities with Program requirements or resolving other matters, we propose in Sec. 170.505(a)(2)(iii) that seven business days after a written communication is sent is the latest of three dates on which we would consider the communication to have been received by the recipient. In Sec. 170.505(a)(2)(i), where we receive a communication from the ONC- ACB, ONC-ATL, applicant, developer, or other party in response to a written correspondence, we believe that response is sufficient to demonstrate the communication has been received. Similarly, in Sec. 170.505(a)(2)(ii) a delivery confirmation date, such as from the United States Postal Service (USPS) for certified mail, that is fewer than seven business days after the communication was sent would be considered the day the communication was received. We welcome comments on this proposal and whether we should consider moving away from using non-electronic means of communication for anything except courtesy copies of communications.

2. ONC-Authorized Certification Bodies (ACB) Surveillance of Certain

Maintenance of Certification Requirements a. Background and Proposal Summary To better support health IT developers' ability to consistently meet their obligations under subpart D of 45 CFR part 170, we propose to adopt new requirements in Sec. 170.523 principles of proper conduct (PoPCs) for ONC-ACBs and new procedures for in-the-field surveillance of the maintenance of certification for Health IT in Sec. 170.556 that would build on ONC-ACBs' existing surveillance responsibilities and obligations. More specifically, we propose to adopt new surveillance reporting requirements in Sec. 170.523(i), reporting for corrective action plan (CAP) non-compliance in Sec. 170.523(x), new oversight responsibilities of certain Maintenance of Certification requirements in Sec. 170.523(p) and (q), new and revised surveillance requirements in Sec. 170.556(b), and new and revised procedures for CAPs in Sec. 170.556(d). We believe these proposed new and revised surveillance and PoPC requirements would promote Program efficiency and encourage Program- participating developers to maintain, or when necessary, regain, conformity with Program requirements for the applicable Maintenance of Certification requirements as required by the Program regulations promulgated under the Cures Act. Section 4002(a) of the Cures Act amended section 3001(c)(5) of the PHSA by adding paragraph (c)(5)(D), which requires the Secretary, through notice and comment rulemaking, to require certain conditions of certification and maintenance of certification for the Program. In the ONC Cures Act Final Rule, we established Conditions and Maintenance of Certification requirements pursuant to PHSA 3001(c)(5)(D)(i) through (vi) in subpart D of 45 CFR part 170 (85 FR 25783). In the HTI-1 Final Rule, we established the Insights Condition and Maintenance of Certification requirements (Sec. 170.407) pursuant to PHSA 3001(c)(5)(D)(vii) and the Assurances Maintenance of Certification requirement for health IT developers to update and provide their Health IT Modules (Sec. 170.402(b)(3). We also established in Sec. 170.402(b)(4) an Assurances Maintenance of Certification requirement for Predictive Decision Support Intervention transparency (89 FR 1371), and in section III.C.2 of this proposed rule, we propose to establish a conforming update to the Attestation Condition and Maintenance of Certification in Sec. 170.406(a)(2) to address the adopted Sec. 170.402(b)(4) DSI Maintenance of Certification requirement. In addition to the Conditions and Maintenance of Certification requirements, in the ONC Cures Act Final Rule we established that ONC would enforce compliance with the 45 CFR subpart D Condition and Maintenance of Certification requirements (85 FR 25783). However, we also established ONC-ACB responsibilities (PoPCs). These responsibilities included the review and approval for submission of developers' Sec. 170.406 attestations (Sec. 170.523(q)) and Sec. 170.405 real world testing plans and results (Sec. 170.523(p)) (85 FR 25951). The ONC Cures Act Final Rule also established a PoPC in Sec. 170.523(s) requiring ONC-ACBs to report any information that could inform whether ONC should exercise direct review of noncompliance with the Conditions and Maintenance of Certification requirements to ONC (85 FR 25783). ONC-ACBs' PoPC responsibilities under the currently codified requirements in Sec. 170.523(p) have encouraged and helped Program- participating developers to achieve a high rate of compliance with the real world testing Maintenance of Certification requirements in Sec. 170.405. Under Sec. 170.523(p), ONC-ACBs are required to confirm the completeness of developers' real world testing plans and results, and to confirm the developer timely submitted materials for public availability in accordance with Sec. 170.405(b). We believe a similarly supportive dynamic exists for developers' compliance with attestations requirements in Sec. 170.406 and insights reporting requirements in Sec. 170.407, for which ONC-ACBs have explicitly aligned PoPC responsibilities as described in Sec. 170.523(q) and (u). Informed by our experience with ONC-ACB support in monitoring and encouraging developers' compliance with certain 45 CFR 170 subpart D requirements over the past three years, and pursuant to the authority in PHSA [[Page 63603]] section 3001(c)(5)(E) to ``encourage compliance with the conditions of certification,'' we now propose new ONC-ACB PoPC requirements in Sec. 170.523 to encourage and support developers' compliance with Maintenance of Certification requirements in Sec. 170.402 and 170.404. In parallel, we propose to update ONC-ACBs' responsibilities for conducting reactive surveillance in accordance with Sec. 170.556(b) and working with developers to encourage remediation of observed non- conformities with Program requirements in Sec. 170.556(d). Our proposal in Sec. 170.556(b) would require ONC-ACBs to initiate surveillance when they become aware of facts or circumstances that would cause a reasonable person to question whether a health IT developer has satisfied certain Maintenance of Certification requirements. As a result of our proposals in Sec. 170.556(b) and additional proposals in Sec. 170.523(i), we are proposing to require ONC-ACBs perform reactive and randomized surveillance based on the specified Maintenance of Certification requirements in Sec. Sec. 170.402(b)(1)-(4), 170.404(b)(1) and (2), 170.405(b)(1) and (2), 170.406(b), and 170.407(b). In case of non-conformities, we would require an ONC-ACB to notify health IT developers and require a CAP, in addition to the existing requirements in Sec. 170.556 consistent with their accreditation under PoPCs in Sec. 170.523(a) and ISO/IEC 17065. In Sec. 170.556(d), we further propose revisions to the required elements of a CAP for identified non-conformities with respect to Program requirements codified in subpart D for which we propose an ONC- ACB would have responsibility under Sec. 170.523. Under these proposals in Sec. 170.523 and Sec. 170.556, an ONC-ACB would have the duty to confirm a health IT developer's compliance with, and initiate surveillance whenever it becomes aware of each non-conformity to, the Maintenance of Certification requirements in Sec. Sec. 170.402(b)(1)- (4), 170.404(b)(1) and (2), 170.405(b)(1) and (2), 170.406(b), and 170.407(b). b. Updates to Principles of Proper Conduct for Maintenance of Certification Requirements In the ONC Cures Act Final Rule, we adopted Conditions and Maintenance of Certification requirements for health IT developers outlined in section 4002 of the Cures Act (85 FR 25717) and implemented them with further specificity in the Program, expressing initial and ongoing certification requirements for the health IT developers and their certified health IT products (85 FR 25718). We adopted certain responsibilities for the ONC-ACB's to ensure developers have met their obligations for certain Conditions and Maintenance of Certification requirements. We also provided that, if the monitoring processes implemented by ONC-ACBs are not adhered to by developers, the ONC-ACB, in accordance with Program reporting requirements, should follow its processes to institute a CAP. Should the developer fail to engage in the CAP process the ONC-ACB would alert ONC of the developer's failure to comply with the Conditions and Maintenance of Certification requirements (85 FR 25720 through 25721). To ensure developers of health IT were meeting the requirements of the Program, we adopted requirements for ONC-ACBs in Sec. 170.523. Specifically, we adopted PoPCs for ONC-ACBs in Sec. Sec. 170.523(m), 170.523(p), 170.523(q), and 170.523(t) that aligned with certain Maintenance of Certification requirements, tasking ONC-ACBs to review and confirm certain information is submitted by health IT developers in response to the real world testing and attestation Maintenance of Certification requirements. ONC-ACBs are required to share additional information, as it relates to certain Maintenance of Certification requirements, with the National Coordinator regarding developer compliance with Program requirements (85 FR 25784 through 25785). We now propose to expand an ONC-ACB's responsibilities to require additional oversight of certain Maintenance of Certification requirements be included in the ONC-ABC's surveillance reports and to provide certain documentation to the National Coordinator as part of its surveillance. We propose new PoPC requirements for ONC-ACBs specifically aligned to encourage transparency and support developers' compliance with Maintenance of Certification Requirements in 45 CFR part 170 subpart D, including redesignating Sec. 170.523(p) through (u) as paragraphs (r) through (w). We propose to revise Sec. 170.523(p) to add new requirements that ONC-ACBs verify and confirm a health IT developer's compliance with Attestation Maintenance of Certification requirements in accordance with Sec. 170.402(b), and revise Sec. 170.523(q) to add oversight requirements for developer compliance with API Maintenance of Certification requirements in accordance with Sec. 170.404(b). Our proposed redesignation would mean the current requirements in Sec. 170.523(p) real world testing, Sec. 170.523(q) attestations, Sec. 170.523(r) test results from ONC-ATLs, Sec. 170.523(s) information for direct review, Sec. 170.523(t) Health IT Module voluntary standards and implementation specifications updates notices, and Sec. 170.523(u) insights would be shifted to Sec. 170.523(r), (s), (t), (u), (v), and (w), respectively. We note that we do not propose to revise the requirements in proposed Sec. 170.523(r), (s), (t), (u), (v) or (w) (currently codified as Sec. 170.523(p), (q), (r), (s), (t), and (u), respectively). Under these proposals in Sec. 170.523, we would require that an ONC-ACB confirm and verify a health IT developer's compliance with the requirements in Sec. Sec. 170.402(b)(1)-(4), 170.404(b)(1) and (2), 170.405(b)(1) and (2), 170.406(b), and 170.407(b) and, where a non- conformity rather than compliance is observed, to initiate surveillance in accordance with our proposals in Sec. 170.556 (discussed in III.D.2.c below) and notify the health IT developer of each observed non-conformity. Each proposal in Sec. 170.523(p) references a corresponding requirement for health IT developers in Sec. 170.402(b), so that requirements in Sec. 170.523(p)(1) references Sec. 170.402(b)(1), our proposal for Sec. 170.523(p)(2) references Sec. 170.402(b)(2) and (b)(3), and our proposal for Sec. 170.523(p)(3) references Sec. 170.402(b)(4). Health IT developer requirements in Sec. 170.404(b)(1) and (2) are also incorporated into our proposals for APIs in Sec. 170.523(q). Similarly, the insights requirement in Sec. 170.523(w) (finalized in the HTI-1 Final Rule as Sec. 170.523(u) (89 FR 1435)) for ONC-ACBs was proposed and finalized simultaneously with corresponding developer requirements for Insights Condition and Maintenance of Certification requirements in Sec. 170.407. We propose to limit the ONC-ACB oversight requirements to those certain Maintenance of Certification requirements mentioned above because of the administrative nature of these requirements (comparative to requiring, for example, investigation, analysis, or assessment). As stated above, ONC-ACBs already have responsibilities in Sec. 170.523(p), (q), and (u) (which we propose to shift to Sec. 170.523(r), (s), and (t), respectively) to verify and confirm that developers are meeting their obligations in Sec. Sec. 170.405(b)(1) and (2), 170.406, and 170.407. These Maintenance of Certification requirements require developers to submit documentation to ONC-ACBs, notify ONC-ACBs when a non- [[Page 63604]] conformity arises during real world testing, and provide an attestation for compliance with certain certification criteria under the Program. We consider these obligations as strictly administrative, and their successful completion does not implicate developer behaviors that rise to the level of oversight that would be necessary for initial ONC review. Likewise, we consider the Maintenance of Certification requirements in Sec. Sec. 170.402(b)(1)-(4) and 170.404(b)(1) and (2) to also be administrative in nature. We believe the proposed addition of Sec. 170.402(b)(1)-(4) in Sec. 170.523(p)(1)-(3) and Sec. 170.404(b)(1) and (2) in Sec. 170.523(q)(1) and (2) is suitable considering the ONC-ACBs experience with confirming and verifying that a developer has met the requirements in Sec. Sec. 170.405(b)(1) and (2), 170.406, and 170.407. We note that we do not propose to include in Sec. 170.523 the oversight of a health IT developer's compliance with the requirements in Sec. 170.401, Information Blocking, and Sec. 170.403(b), Communications Maintenance of Certification requirements. Unlike the requirements in Sec. 170.402(b)(1)-(4) and Sec. 170.404(b)(1) and (2), which we consider administrative, the oversight and enforcement of Information Blocking addresses practices that interfere with the access, exchange or use of EHI, and the Communications Maintenance of Certification requirements focuses on the update of agreements with clients that could limit ongoing collaboration and coordination. These Maintenance of Certification requirements compel developers to design, implement, and maintain business practices that align with ONC standards, facilitate data exchange, and actively engage in practices that ensure that their products remain compliant. Centralizing the oversight of these Maintenance of Certification requirements under ONC removes the possibility of having these conflicts, ensuring a standardized and consistent approach to enforcing these requirements. While we consider the ONC-ACBs' Maintenance of Certification responsibilities as administrative, we also believe transparency is important regarding all Program requirements and propose to revise and add new PoPC surveillance reporting requirements for ONC-ACBs in Sec. 170.523(i). As discussed, in Sec. 170.556(b) and (d) we propose to add the Maintenance of Certification requirements proposed in Sec. 170.523 to the ONC-ACBs' surveillance responsibilities. We propose that this responsibility would include initiating surveillance (Sec. 170.556(b)(2) and (3)), initiating CAP procedures (Sec. 170.556(d)(1)), initiating suspensions (Sec. 170.556(d)(5)) when a developer fails to engage with the CAP process for Maintenance of Certification non-conformities, and withdrawals (Sec. 170.556(d)(6)) when the health IT developer does not complete the actions necessary to reinstate the suspended certification (we refer readers to section III.D.2.c below for a discussion of these proposals). To better achieve transparency of the proposed surveillance activities, we propose to revise Sec. 170.523(i)(2)(iii) to require ONC-ACBs, when conducting surveillance of certified health IT in accordance with their accreditation, to include the Maintenance of Certification requirements it surveilled in its quarterly surveillance results report. We also propose to add a requirement in Sec. 170.523(i)(4) that an ONC-ACB, as part of its responsibilities to conduct surveillance of certified health IT in accordance with its accreditation, and proposed requirements in Sec. 170.556, shall notify the National Coordinator prior to initiating the suspension or withdrawal of a certification as specified in Sec. 170.556 for a non-conformity pertaining to a Maintenance of Certification requirement for which the ONC-ACBs have responsibilities. We propose this revision because, as a common practice, ONC-ACBs notify ONC before suspending a certification for a certified Health IT Module when a developer fails to engage with the CAP process pertaining to a certification requirement non-conformity, and before withdrawing a certified Health IT Module when the health IT developer has not completed the actions necessary to reinstate the suspended certification. We propose to explicitly codify this practice for enforcement activities pertaining to certain Maintenance of Certification non-conformities. To further our stated goals of increased transparency in the Program and encourage developer compliance, we also propose to add a new PoPC in Sec. 170.523(x) ``Reporting for non-compliance with approved corrective action plans.'' We propose to require that ONC-ACBs report to ONC, pursuant to our proposal in Sec. 170.556(d)(7)(ii), (discussed in detail in section III.D.2.c.iv below), the developer's failure to timely complete a CAP specific to a Maintenance of Certification requirement for which an ONC-ACB has specific responsibilities under Sec. 170.523. We propose to require the ONC- ACBs to include all documentation pertaining to the identified non- conformity, including but not limited to the following information: (1) the Health IT Module and associated product(s); (2) the nature of the non-conformity(ies); (3) the corrective action plan documentation; (4) communications and records of proceedings; and (5) any additional information requested by ONC. We believe the proposed required documentation in Sec. 170.523(x) is necessary and valuable to support the National Coordinator's review of a health IT developer's actions or practices without requiring ONC to engage in duplicative fact-finding processes for applicable cases of non-conformities. The proposed documentation in Sec. 170.523(x) would also inform the National Coordinator on whether the ONC-ACB met their obligations to notify the developer of the non-conformity and initiate corrective action procedures under Sec. Sec. 170.523 and 170.556. Furthermore, requiring the proposed stated documentation would provide clarity and consistency for developers of health IT and ONC-ACBs on our expectations for the degree of accuracy and detail required for documenting a non-conformity with a Maintenance of Certification requirement for which an ONC-ACB has specific responsibilities under Sec. 170.523. The documentation requirements would also help construct an accurate record that could inform whether the National Coordinator should exercise direct review under Sec. 170.580(a). Lastly, in Sec. 170.523(i)(1), as part of an ONC-ACBs obligations to conduct surveillance of certified health IT in accordance with its accreditation and Sec. 170.556, ONC requires ONC-ACBs to submit an annual surveillance plan to the National Coordinator. The ONC-ACBs submit their annual plans in September with an effective date of January 1 in the following year. As such, if we adopt the Maintenance of Certification requirements proposals in Sec. Sec. 170.523 and 170.556, ONC-ACBs would need to include them as part of their annual surveillance plans for January 1, 2026. We welcome comments on these proposals. c. Updates to Surveillance for Maintenance of Certification Requirements In the 2015 Edition Final Rule, we finalized that CAP requirements applied across-the-board to all types of surveillance and confirmed non-conformities (80 FR 62714). We reiterated that our goal for surveillance requirements was to ensure that health IT users, implementers, and purchasers [[Page 63605]] would be alerted to potential non-conformities in a timely and effective manner, consistent with the patient safety, program integrity, and transparency objectives described in the 2015 Edition Proposed Rule (80 FR 62716 through 62717). We received support from commenters to specify certain required elements and procedures for CAPs (80 FR 62716). We also finalized reporting requirements for CAPs and extended these requirements to all cases in which an ONC-ACB confirms a non-conformity and subsequently approves a CAP (80 FR 62717). We continued to build upon surveillance and CAP requirements by adopting the ONC direct review regulatory framework in the EOA Final Rule (81 FR 72468 through 72471), which permits the Program to provide enhanced oversight for safety and health IT developer accountability. The EOA Final Rule emphasized the importance of protecting public health and safety while also strengthening transparency and accountability in the Program. Following the EOA Final Rule, in the ONC Cures Act Final Rule we addressed enforcement processes for new requirements established in the Cures Act. Section 4002(a) of the Cures Act adds (in section 3001(c)(5)(D) of the PHSA) Program requirements aimed at addressing health IT developers' actions and business practices through the Conditions and Maintenance of Certification requirements, which expanded the focus of the Program requirements beyond the certified health IT itself (85 FR 25648 through 25649). Equally important, section 4002(a) of the Cures Act also provides (in section 3001(c)(5)(E) of the PHSA) that the Secretary may encourage compliance with the Conditions and Maintenance of Certification requirements and take action to discourage noncompliance. In the ONC Cures Act Final Rule, we, therefore, finalized an enforcement framework for the Conditions and Maintenance of Certification requirements in Sec. Sec. 170.580 and 170.581 to encourage consistent compliance with the requirements. More specifically, we finalized processes in Sec. 170.580 for ONC to review potential or known instances where a Condition or Maintenance of Certification requirement under the Program has not been met or is not being met by a health IT developer. We also finalized in Sec. Sec. 170.580 and 170.581 requirements to utilize the processes previously established for ONC direct review of certified health IT in the enforcement of the Conditions and Maintenance of Certification requirements. We noted that the new Conditions and Maintenance of Certification requirements in section 4002 of the Cures Act focus on the actions and business practices of health IT developers (e.g., information blocking and appropriate access, use, and exchange of electronic health information) as well as technical interoperability of health IT (e.g., APIs and real world testing) (85 FR 25782 through 25783). When we originally distinguished between the Conditions and Maintenance of Certification requirements that focus on actions and business practices of health IT developers versus technical interoperability of health IT, we did not further distinguish exclusively administrative functions that are required of a health IT developer to meet certain Maintenance of Certification requirements in part 170 subpart D. Rather, we determined that ONC should be responsible for addressing non- conformities pertaining to all Maintenance of Certification requirements (85 FR 25782 through 25783). We also clarified that ONC- ACBs are not responsible for enforcement of the Conditions and Maintenance of Certification requirements, and that they must report any information that could inform whether ONC should exercise direct review of noncompliance with the Conditions and Maintenance of Certification requirements to ONC. We noted that ONC-ACBs also address non-conformities with technical and other Program requirements through surveillance and by working with health IT developers through CAPs. We stressed that, as finalized in the EOA Final Rule (81 FR 72427 through 72428) and per Sec. 170.580(a)(3)(v), ONC may refer the applicable part of its review of certified health IT to the relevant ONC-ACB(s) if ONC determines this would serve the effective administration or oversight of the Program (85 FR 25785). Since publication of the ONC Cures Act Final Rule, we now have enforcement experience with Maintenance of Certification requirements in 45 CFR 170 subpart D. More specifically, ONC conducted 13 direct reviews in 2023, of which 10 were in connection to the non-conformity to the API Maintenance of Certification requirement in Sec. 170.404(b)(3) for failure to comply with the rollout of Sec. 170.315(g)(10); two for failure to submit their real world testing results leading to a non-conformance with Sec. 170.406(b)(2); and, one for failure to submit their annual attestation related to Sec. 170.406(b). We have conducted multiple direct reviews of non- conformities specific to developers of certified health IT missing a document-submission or other deadline for Maintenance of Certification requirements in 45 CFR 170 subpart D. During these direct reviews, we have coordinated with the ONC-ACBs the corrective actions and communications with the developers. Based on this enforcement experience, we have found that some non-conformities specific to certain Maintenance of Certification requirements may be better and more quickly resolved without immediate ONC involvement in certain cases and are better suited to initial oversight by the ONC-ACBs. With this experience, we recognize that ONC-ACBs are equally well suited to conduct surveillance and work with developers of certified health IT through CAPs to remedy non-conformities beyond certification requirements in certain circumstances. We no longer believe that keeping enforcement for certain Maintenance of Certification requirements exclusively within ONC oversight benefits the Program and could, in fact, result in Program inefficiencies to the detriment of the Program, users of certified health IT, and developers of certified health IT. The inclusion of certain Maintenance of Certification requirements within ONC-ACB oversight would increase transparency and result in more expedient determinations of whether a non-conformity exists, along with its resolution. In our experience, the collaboration between ONC-ACBs, health IT developers of certified health IT, and users in examining potential non-conformities, along with ONC-ACB's oversight of specific Maintenance of Certification requirements, facilitates quicker resolutions leading to more efficiency in the Program. This efficiency stems from the ONC-ACBs' capacity to engage and communicate with developers promptly as well as their extensive expertise in surveilling certified Health IT Modules for continued conformity to the requirements of their certifications. i. Reactive Surveillance We propose to revise the reactive surveillance requirements in Sec. 170.556(b) to account for the specified Maintenance of Certification requirements in subpart D for which an ONC-ACB would have oversight pursuant to revisions to Sec. 170.523. We propose in Sec. 170.556(b) to require an ONC-ACB to initiate surveillance (including, as necessary, in-the-field [[Page 63606]] surveillance required by paragraph (a) of this section) whenever it becomes aware of facts or circumstances that would cause a reasonable person in the ONC-ACB's position to question one or more of the following: (1) a certified Health IT Module's continued conformity to the requirements of its certification; (2) a developer's satisfaction of the Maintenance of Certification requirements in Sec. 170.402(b)(1); and (3) an applicable developer's satisfaction of the Maintenance of Certification requirements for which an ONC-ACB has a responsibility under Sec. 170.523 to confirm compliance. We propose the surveillance requirements for the Maintenance of Certification requirements in Sec. 170.556(b)(2) and (3) as two distinct elements because of the diverse obligations in 45 CFR part 170 subpart D that health IT developers must satisfy to remain in compliance with the Program. To ensure health IT developer accountability, and as discussed above, we have adopted the Maintenance of Certification requirements in part 170 subpart D to express ongoing requirements for health IT developers and their applicable Health IT Module(s) certified to specific certification criteria. The Maintenance of Certification requirements in 45 CFR part 170 subpart D do not always apply to all health IT developers participating in the Program. The Program is voluntary and health IT developers may certify their Health IT Module(s) to one, some, or all the certification criteria adopted by the Secretary, and they are not required to certify their Health IT Module(s) to every certification criterion to participate in the Program. Also as discussed in the previous section, we propose in Sec. 170.523(p)(1) that ONC-ACBs confirm that health IT developers retain all records and information necessary to demonstrate initial and ongoing compliance with the requirements of the Program in accordance with Sec. 170.402(b)(1). Our proposal in Sec. 170.523(p)(1) would require ONC-ACBs to confirm that health IT developers are meeting the requirements in Sec. 170.402(b)(1) and, in the proposed Sec. 170.523(i)(2)(iii), we would require the ONC-ACBs to conduct surveillance of the Maintenance of Certification requirements and include the results in its quarterly report to the National Coordinator, in accordance with its accreditation and Sec. 170.556(a) and (e)(1). To support the PoPC proposals in Sec. 170.523, our proposal in Sec. 170.556(b)(2) would require an ONC-ACB to initiate surveillance (including, as necessary, in-the-field surveillance) whenever it becomes aware of facts or circumstances that would cause a reasonable person in the ONC-ACB's position to question a developer's satisfaction of the Maintenance of Certification requirements in Sec. 170.402(b)(1). The proposed requirements in Sec. 170.523(i)(2)(iii) and in Sec. 170.523(p)(1), taken together with our proposal in Sec. 170.556(b)(2), would result in the ONC-ACB initiating and conducting surveillance of a health IT developers' satisfaction of its obligations in Sec. 170.402(b)(1). Similar to our proposal in Sec. 170.523(p)(1), we propose in Sec. 170.523(p)(2) and (3), 170.523(q), (r), (s), and (w) to require the ONC-ACBs to confirm health IT developers are meeting their obligations, as applicable, under the Maintenance of Certification requirements in Sec. Sec. 170.402(b)(2)-(4), 170.404(b)(1) and (2), 170.405(b)(1) and (2), 170.406(b), and 170.407(b); and in Sec. 170.523(i)(2)(iii) to conduct surveillance of the Maintenance of Certification requirements listed in Sec. 170.523, in accordance with their accreditation and Sec. 170.556(b)(3). To help meet these obligations, for the proposed requirement in Sec. 170.556(b)(3), we propose to require an ONC-ACB to initiate surveillance (including, as necessary, in-the-field surveillance) when it becomes aware of facts or circumstances that would cause a reasonable person in its position to question an applicable developer's satisfaction of the Maintenance of Certification requirements for which an ONC-ACB has a responsibility under Sec. 170.523 (that is, Sec. Sec. 170.402(b)(2)-(4), 170.404(b)(1) and (2), 170.405(b)(1) and (2), 170.406(b), and 170.407(b)). Overall, the proposals in Sec. 170.556(b)(2) and (3) would mean that as part of the requirement to confirm a health IT developer met its obligation(s) in part 170 subpart D, an ONC-ACB must initiate surveillance when it reasonably finds a health IT developer failed to meet the Maintenance of Certification subpart D requirements for which the ONC-ACB would have oversight of in Sec. 170.523. We propose to distinguish between the proposed requirements in Sec. 170.556(b)(2) and (3) because all health IT developers participating in the Program are required to comply with requirements in Sec. 170.402(b)(1), whereas only health IT developers with Health IT Modules certified to those certification criteria listed in the requirements in Sec. Sec. 170.402(b)(2)-(4), 170.404(b)(1) and (2), 170.405(b)(1) and (2), 170.406(b), and 170.407(b) are required to comply with the applicable Maintenance of Certification requirements. Given these considerations and our proposal to expand ONC-ACB oversight of specific Maintenance of Certification requirements listed in Sec. 170.523, we propose to include requirements that ONC-ACBs must initiate surveillance of the specified Maintenance of Certification requirements in Sec. 170.556(b)(2) and (3) reactive surveillance whenever it becomes aware of facts or circumstances that would cause a reasonable person in the ONC-ACB's position to question a developer's satisfaction of its obligations under 45 CFR part 170 subpart D. Additionally, we propose to revise Sec. 170.556(b)(1) by moving the current verification requirements of Sec. 170.523(k) listed in Sec. 170.556(b)(1) to be part of Sec. 170.556(b)'s overall language. Our proposal would not change or modify the ONC-ACBs' current responsibilities to initiate in-the-field-surveillance requirements in Sec. 170.556(a) or the randomized surveillance considerations in Sec. 170.556(c). We welcome comments on these proposals. ii. Corrective Action Plan and Procedures In the 2015 Edition Final Rule, we adopted requirements in Sec. 170.556(d)(1) that require an ONC-ACB to notify a developer when it determines that a non-conformity exists and require the developer to submit a proposed CAP for the applicable certification criterion, certification criteria, or certification requirement (80 FR 62758). We propose to revise the corrective action plan and procedures in Sec. 170.556(d)(1) to include the Maintenance of Certification requirements specified in subpart D for which we propose an ONC-ACB would have responsibilities for under Sec. 170.523 (discussed in the section III.D.2.b above). We expect the ONC-ACB to initiate surveillance as necessary to assess whether the developer has met the Condition and Maintenance of Certification requirements obligations under subpart D of part 170--for which we propose the ONC-ACB to have oversight responsibilities--in the same manner as it initiates surveillance for other Program requirements. We propose to require that an ONC-ACB notify the developer of health IT, when an ONC-ACB determines, through surveillance under Sec. 170.556 or otherwise, that the health IT developer is out of compliance with the specified Maintenance of Certification requirement and to require the developer submit a proposed CAP for the applicable Maintenance of Certification requirement. [[Page 63607]] In addition to the corrective action procedures adopted in the 2015 Edition Final Rule, ONC also specified certain baseline required elements for CAPs in Sec. 170.556(d)(3) (80 FR 62758 through 62759). Specifically, we finalized in Sec. 170.556(d)(3)(i)-(vi) six minimum required elements that an ONC-ACB must verify are included in the CAP submitted by the developer of health IT. We now propose to revise Sec. 170.556(d)(3), which requires the ONC-ACB to verify the elements of the CAP, to account for the proposed addition of certain Maintenance of Certification requirements that we propose an ONC-ACB must include in its surveillance activities. We do not find all existing CAP requirements equally necessary for non-conformities that involve the proposed new responsibilities for ONC-ACBs to initiate corrective procedures for specified subpart D Maintenance of Certification requirements, we also propose to specify different minimum required CAP elements based on the type of non- conformity the plan addresses. We believe that establishing certain minimum expectations and procedures for initiating CAP procedures for specified subpart D Maintenance of Certification requirements would provide ONC-ACBs, as well as health IT developers and users, with greater clarity and predictability regarding this aspect of the Program. Furthermore, ONC-ACBs have unique experience working directly with developers to remedy identified non-conformities to the requirements of certification codified in subparts A, B, C, and E, as well as verifying and confirming a developer has met its obligations with the Maintenance of Certification requirements for real world testing and attestations. This experience translates well to having ONC-ACBs conduct surveillance for certain Maintenance of Certification requirements for which we propose the ONC-ACBs have specific responsibilities. We note that our expectations regarding an ONC-ACBs' surveillance responsibilities specific to the oversight and enforcement requirements of certification would not change with the addition of certain Maintenance of Certification requirements under our revisions and additions proposed in Sec. 170.556(b) reactive surveillance and (d) corrective action plan and procedures. To better differentiate the requirements for each CAP, in Sec. 170.556(d)(3)(i), we propose to list the minimum required elements for all CAPs pertaining to all non-conformities. In Sec. 170.556(d)(3)(ii), we propose to list the minimum required elements for non-conformities with respect to any Program requirement codified in subparts A, B, C, or E of part 170. In Sec. 170.556(d)(3)(iii), we propose to list the minimum required elements for non-conformities with respect to any Program requirement codified in subpart D of this part for which the ONC-ACBs would have responsibility under Sec. 170.523. We discuss each proposed list of elements in detail in the following paragraphs. We are retaining in Sec. 170.556(d)(3) the currently required elements for identified non-conformities with respect to any Program requirements codified in subparts A, B, C, or E with proposed restructuring of the paragraph levels and minor proposed modifications. For the currently codified CAP elements, we propose to move the requirements in Sec. 170.556(d)(3)(i), (v), and (vi) to Sec. 170.556(d)(3)(i)(A), (B), and (C), respectively. We also propose to shift the currently codified CAP elements in Sec. 170.556(d)(3)(ii), (iii), and (iv) to Sec. 170.556(d)(3)(ii)(A), (B), and (C), respectively. The proposed revised elements are substantially the same elements currently codified in Sec. 170.556(d)(3)(i)-(vi), and we do not propose revisions to the regulatory text in the newly shifted Sec. 170.556(d)(3)(i)(A), (B), and (C) or Sec. 170.556(d)(3)(ii)(A). For these elements, we only propose to revise the level of paragraphs. To account for the proposed shifting of elements and the addition of the Maintenance of Certification to the ONC-ACBs' oversight responsibilities, we propose to revise paragraph (d)(3)(i) to specify that for each identified non-conformity with respect to any Program requirement, the ONC-ACB must verify that the associated CAP includes the following, at a minimum: a description of the identified non- conformities (Sec. 170.556(d)(3)(i)(A)); the timeframe under which corrective action will be completed (Sec. 170.556(d)(3)(i)(B)); and, an attestation by the developer that it has completed all elements of the approved CAP (Sec. 170.556(d)(3)(i)(C)). The proposed required elements would apply to proposed CAPs that aim to remedy identified non-conformities for a certified Health IT Module that does not conform to the applicable requirements of its certification and/or when the health IT developer is out of compliance with Maintenance of Certification requirements specified in subpart D of this part for which the ONC-ACB has specific responsibilities under Sec. 170.523. We propose to require the minimum required elements in Sec. 170.556(d)(3)(i)(A), (B), and (C) because we believe that certain elements should serve as the baseline of information for any type of non-conformity the CAP addresses. We also believe certain minimum required elements should still apply regarding non-conformities with respect to any Program requirement codified in subparts A, B, C, or E of part 170. To account for our restructuring of the current minimum six elements in Sec. 170.556(d)(3), in Sec. 170.556(d)(3)(ii), we propose to shift and revise the other three remaining minimum required elements in paragraphs (d)(3)(ii), (iii), and (iv) as Sec. 170.556(d)(3)(ii)(A), (B), and (C). For a Health IT Module that does not conform to the certification requirements codified in subparts A, B, C, or E of part 170, we propose in Sec. 170.556(d)(3)(ii) that for each CAP submitted by the developer, the ONC-ACB shall verify the CAP includes the required elements specified in proposed Sec. 170.556(d)(3)(ii)(A) through (C), in addition to the proposed required elements identified in Sec. 170.556(d)(3)(i)(A), (B) and (C). We note that these proposed three minimum required elements are the same three minimum required elements that are codified in Sec. 170.556(d)(3)(ii)-(iv), with proposed minor modifications. We propose to distinguish the elements in this way to account for the proposed elements identified in Sec. 170.556(d)(3)(iii)(A) and (B) that we would not require for CAPs pertaining to non-compliance with the certification requirements codified in subparts A, B, C, and E of part 170. The proposed elements listed in Sec. 170.556(d)(3)(ii)(A) through (C) are substantially the same elements currently codified in Sec. 170.556(d)(3)(ii) through (iv), with proposed minor modifications. For clarity, we propose to revise the proposed CAP element identified in Sec. 170.556(d)(3)(ii)(B) (currently designated in Sec. 170.556(d)(3)(iii)). We clarify that this required element for CAPs does not mean that on-site surveillance at a deployed site is the only means through which an ONC-ACB could identify a technical non- conformity. Thus, we propose in Sec. 170.556(d)(3)(ii)(B) that the ONC-ACBs may identify a technical non-conformity at any location where surveillance procedures have been conducted resulting in an identified non-conformity, and for all other potentially affected customers and users. We also propose a minor revision in Sec. 170.556(d)(3)(ii)(C) (currently codified in Sec. 170.556(d)(3)(iv)) to improve the readability of the required element. We note that in Sec. 170.556(d)(3)(ii)(C), part of [[Page 63608]] the CAP required element addresses how the developer will ensure that all affected, and potentially affected customers and users are alerted to the identified non-conformities, including a detailed description of how the developer will assess the scope and impact of the problem and identify all potentially affected customers. We clarify our expectation with this requirement is two pronged. Satisfying the element would include (1) how the health IT developer identifies the potentially affected customers and (2) identifying who is the actual affected customer(s) by including a detailed description of how the health IT developer will promptly ensure that all potentially affected customers are notified of the non-conformity and plan for resolution. During the CAP process, an ONC-ACB instructs the developer to submit a proposed CAP, or a revised proposed CAP, to remedy the non-conformity. The ONC- ACB also verifies the attestation by the developer that it has completed all elements of the approved CAP (Sec. 170.556(d)(3)(i)(C)). We believe requiring developers to identify affected customers during the CAP approval process as part of the element in Sec. 170.556(d)(3)(ii)(C) is helpful for several reasons, most notably that it aligns with the requirements in our enforcement mechanisms in Sec. 170.580. It would also be useful information when we need to verify communications with a customer(s), as well as aid with Federal agency coordination by identifying the names and the number of affected customers who participate in other HHS programs. We welcome comment on our expectations and whether we should consider codifying this element as two separate requirements. Recognizing the diversity of non-conformities, we propose, in Sec. 170.556(d)(3)(iii), different required minimum elements for CAPs submitted for addressing non-compliance with Maintenance of Certification requirements specified in subpart D. We propose to require that an ONC-ACB verify that the proposed minimum required elements in Sec. 170.556(d)(3)(i)(A), (B), and (C) are included in a CAP pertaining to Maintenance of Certification requirements. Additionally, to better address the variations in types of non- conformities to Program requirements, we propose in Sec. 170.556(d)(3)(iii)(A) and (B) to implement specific required elements for each identified non-conformity with respect to any Program requirement codified in subpart D of this part for which the ONC-ACB has responsibilities under Sec. 170.523 of this part (we refer readers to section III.D.2.b for a list of these proposed responsibilities in Sec. 170.523). Thus, for all Maintenance of Certification requirement non-conformities, an ONC-ACB must verify that a CAP includes the proposed elements identified in Sec. 170.556(d)(3)(iii)(A) and (B), in addition to the three minimum required elements identified in Sec. 170.556(d)(3)(i)(A), (B), and (C). The proposed required elements identified in Sec. 170.556(d)(3)(iii)(A) and (B) would require ONC-ACBs to confirm how the developer will address and resolve identified non-conformities with Maintenance of Certification requirements for which the ONC-ACBs have responsibilities under proposed Sec. 170.523. We propose to set forth different elements in Sec. 170.556(d)(3)(iii)(A) and (B) for CAPs addressing non-conformities with certain Maintenance of Certification requirements because of the administrative nature of these requirements compared to, for example, the certification requirements of subparts A, B, C. The elements in Sec. 170.556(d)(3)(iii)(A) and (B) enhance the process for developers to regain compliance with the Maintenance of Certification requirements in several ways. The proposal in Sec. 170.556(d)(3)(iii)(A) would require a developer to outline the actions needed to address non-conformities related to Maintenance of Certification requirements, providing clarity in addressing the non- conformity; while the requirement in Sec. 170.556(d)(3)(iii)(B) underscores the importance of ensuring comprehensive resolution for all identified non-conformities specific to the Maintenance of Certification requirements. These elements will aid developers in crafting CAPs tailored to the distinct challenges posed by Maintenance of Certification requirements, contributing to a clearer regulatory framework. By specifying actions related to Maintenance of Certification requirements, the elements offer explicit requirements, reduce ambiguity, and align requirements with the regulatory intent of maintaining industry-wide compliance and quality standards. This specificity supports ONC-ACBs' effective oversight, allowing them to assess the adequacy and thoroughness of CAPs and ensuring ongoing compliance with certification requirements. We welcome comments on these proposals. iii. Additional Optional Elements The proposed minimum CAP elements in Sec. 170.556(d)(3)(i)--(iii) should be seen as a starting point and represent a minimum, and not a limit, on the elements that may be required by the ONC-ACBs. In other words, with the proposed changes to CAP minimum element specifications, an ONC-ACB may require that a developer include additional elements in any given CAP beyond those that would be the minimum required under Sec. 170.556(d)(3), as proposed. This flexibility is consistent with prior surveillance requirements, and we would continue to give ONC-ACBs substantial flexibility and discretion to decide how to implement these requirements as part of their overall approach to surveillance (80 FR 16880). Such flexibility is important for minimizing the burden of surveillance on all interested parties, while ensuring that an ONC-ACB can approach surveillance in a way that effectively encourages and supports developers' successful correction of non-conformities with Program requirements. Accordingly, we also propose to revise Sec. 170.556(d) by adding Sec. 170.556(d)(3)(iv) to allow an ONC-ACB to require that the CAP include elements beyond those specified in proposed Sec. 170.556(d) as the minimum. Table 1C below includes the proposed revised elements described in this rule that an ONC-ACB would be required to verify in a CAP. [[Page 63609]] [GRAPHIC] [TIFF OMITTED] TP05AU24.002 To aid readers, we offer the following scenario to illustrate the required elements in a CAP that an ONC-ACB must verify based on the specific Program requirements implicated by each identified non- conformity. We note that this scenario is merely illustrative, and the outcomes provided in this scenario are hypothetical. The outcome of this scenario should not be construed as legal precedent for similarly situated fact patterns. Scenario The ONC-ACB receives signals indicating a potential non-conformity, sourced from user complaints, adverse event reports, or routine surveillance activities. Upon detecting possible certification criteria non-conformities within the certified Health IT Module of a developer, the ONC-ACB initiates surveillance to address the Sec. 170.315(b) requirements. During this surveillance, the ONC-ACB receives information indicating the developer may have failed to submit a real world testing plan that demonstrates compliance to the full scope of the applicable certification criteria and functions requirements, including Sec. 170.315(b). A certified Health IT Module that fails to successfully demonstrate full compliance of certification capabilities is treated as any other observation of a failure to meet specific Program requirements. As a result, the ONC-ACB also initiates a second surveillance, this time to address the Sec. 170.405(b)(1) real world testing plan. Once the surveillance activities substantiate non-conformity(ies), the ONC-ACB notifies the developer of its findings and requires the developer to produce a proposed CAP addressing the identified issues, such as interoperability challenges, ineffective decision support, delayed updates, and outdated documentation. Because the ONC-ACB has identified a non-conformity pertaining to Maintenance of Certification requirements in Sec. 170.405(b), the ONC- ACB must verify the CAP includes the proposed required elements identified in Sec. 170.556(d)(3)(i)(A), (B), (C), and Sec. 170.556(d)(3)(iii)(A) and (B). The CAP outlines a step-by-step approach and timeline for the developer to address the non-conformities. The ONC-ACB would require, under the proposed elements in Sec. 170.556(d)(3), that the CAP address the non-conformity with Sec. 170.315(b) and include the required elements in Sec. 170.556(d)(3)(i)(A) through (C); and Sec. 170.556(d)(3)(ii)(A) through (C) as it pertains to a non-conformity for subparts A, B, C, or E of this part. The ONC-ACB may also require the developer to include elements in the CAP beyond those specified in proposed Sec. 170.556(d) as the minimum required elements, according to the proposed addition of Sec. 170.556(d)(3)(iv). With the ONC-ACBs guidance, the developer is able to provide an acceptable proposed CAP to the ONC-ACB addressing the two identified non-conformities, who verifies all the required elements to ensure effective resolution of the identified non-conformities and approves them. The CAP provides a roadmap for the developer to rectify real world testing Maintenance of Certification non-conformities, enhance interoperability, optimize decision support features, ensure timely updates, and update documentation and training materials. The ONC-ACB continues its monitoring of the certified Health IT Module, including implementation of the CAP and progress towards resolution of the non-conformities. Follow-up assessments may be scheduled to confirm sustained compliance, aligning with the ONC-ACB's commitment to continuous improvement in the EHR system's reliability and adherence to certification criteria. The ONC-ACB ensures successful resolution of identified non-conformities and confirms that the Health IT Module now complies with all applicable certification criteria and Maintenance of Certification requirements for real world testing. iv. Suspension, Withdrawals, and Notification Procedures In some circumstances, despite an ONC-ACB's effort to engage and encourage the developer, a developer's non-conformity with Maintenance of Certification or other Program requirements may not be successfully addressed. Under existing regulations, ONC-ACBs shall initiate suspension procedures for a Health IT Module for the following reasons: a developer does not submit a proposed CAP in the [[Page 63610]] allotted time (Sec. 170.556(d)(5)(i)); a developer does not submit a revised proposed CAP within the allotted time resulting in the ONC-ACB being unable to approve a CAP (Sec. 170.556(d)(5)(ii)); and, if the developer does not complete the corrective actions specified in the approved CAP (Sec. 170.556(d)(5)(iii)). We propose to revise Sec. 170.556(d)(5) to require that an ONC-ACB to initiate suspension procedures where a developer fails to propose a CAP, fails to propose an acceptable CAP, or fails to successfully complete an approved CAP for identified non-conformities with respect to those Maintenance of Certification requirements for which an ONC-ACB would have PoPC and surveillance responsibilities. This proposal would be a parallel complement to the existing requirement for an ONC-ACB to initiate suspension procedures for analogous failures of corrective action procedures to successfully resolve non-conformities of a Health IT Module to the requirements of its certification. We note that under current requirements in Sec. 170.556(d)(6), which we do not propose to substantively revise in this proposed rule, if a certified Health IT Module's certification has been suspended, then an ONC-ACB is permitted to initiate certification withdrawal procedures for the Health IT Module (consistent with its accreditation to ISO/IEC 17065 and procedures for withdrawing a certification) when the health IT developer has not completed the actions necessary to reinstate the suspended certification. Therefore, if an ONC-ACB initiates suspension procedures in accordance with proposed Sec. 170.556(d)(5) with respect to an identified non-conformity for a Program requirement codified in subpart D for which the ONC-ACB has responsibilities under Sec. 170.523, it may initiate certification withdrawal procedures in accordance with Sec. 170.556(d)(6). While the Maintenance of Certification requirements pertain to developer behaviors, we consider the specific Maintenance of Certification requirements that an ONC-ACB would have for PoPC and surveillance responsibilities to be entirely administrative in nature. The ONC-ACBs would not make a determination to suspend or withdraw certification based on developer behavior, such as non-compliance with information blocking requirements as specified in Sec. 170.401. Instead, the ONC-ACB would carry out its obligations specified in Sec. 170.556(d)(5) and (6) in response to a developer's failure to meet the CAP related to administrative and routine activities such as submitting a real world testing plan on time. Furthermore, ONC-ACBs and developers have experience with initiating suspensions and withdrawals for developers who fail to engage in the CAP process pertaining to certification non-conformities, and we anticipate that the ONC-ACBs could transition to applying Sec. 170.556(d)(5) and (6) procedures to the proposed CAP procedures for Maintenance of Certification non- conformities without much additional effort. Developers too are also familiar with the process so we expect engaging in the suspension and withdrawal processes for Maintenance of Certification non-conformities would not place much additional burden on them. We note that delegating suspensions and withdrawal responsibilities to ONC-ACBs for Maintenance of Certification non-conformities would not mean the National Coordinator does not have authority to review ONC-ACB action(s). As discussed in detail in the section III.D.2.b, we propose to revise the PoPCs to add a requirement in Sec. 170.523(iii)(4) that ONC-ACBs must notify the National Coordinator prior to initiating a suspension or withdrawal as specified in Sec. 170.556 for a non- conformity pertaining to a Maintenance of Certification requirement for which the ONC-ACBs have responsibilities. We also note in Sec. 170.580(a)(3)(ii) that ONC may assert exclusive review of certified health IT as to any matters under review by ONC, and any similar matters under surveillance by an ONC-ACB. While we believe that ONC-ACBs are well suited to conducting surveillance and coordinating with developers of certified health IT to resolve certain Maintenance of Certification requirement non- conformities, we also acknowledge that there may be instances when a developer fails to timely submit an acceptable proposed CAP or complete an approved CAP, despite an ONC-ACBs efforts to gather and verify this information. In these instances, we believe it is necessary for an ONC- ACB to notify the National Coordinator that a developer failed to submit or complete a CAP addressing these specific Maintenance of Certification non-conformities so that the National Coordinator may review the information and proceed accordingly. Therefore, we propose to add, as paragraph (d)(7) of Sec. 170.556, new requirements for an ONC-ACB to report specific information to ONC when a developer fails to timely submit or complete an approved CAP. This proposal would apply to an identified non-conformity with respect to any Program requirement codified in subpart D for which the ONC-ACB has responsibilities under Sec. 170.523. Under the proposal in Sec. 170.556(d)(7), we would require an ONC- ACB to notify the National Coordinator when the ONC-ACB's requirement to initiate suspension procedures is triggered by the developer's failure to engage (successfully or failure to engage at all, as applicable) with the CAP process for a non-conformity to a Maintenance of Certification requirement. Specifically, we propose in Sec. 170.556(d)(7)(i) that an ONC-ACB must immediately notify the National Coordinator if one or more of the following occurs: 1) the developer has not submitted a proposed CAP; 2) the ONC-ACB cannot approve a CAP because the developer has not submitted a revised proposed CAP; or 3) the developer has not completed the corrective actions specified by an approved CAP within the time specified therein. We propose this requirement to strengthen transparency within the Program as well as encourage developer compliance with the Program. Additionally, this information would inform the National Coordinator whether the ONC-ACB met its obligations to notify the developer of the surveillance activity, if there was an identified non-conformity, and how to remediate the non-conformity, including guidance on the required elements in the CAP, as well as the developer's response and level of engagement with the CAP process. To further accomplish our goal of increased transparency and encouraging developer compliance, we propose in Sec. 170.556(d)(7)(ii) that an ONC-ACB must report certain information to ONC when a developer fails to submit a proposed CAP that can be approved, or complete an approved CAP with respect to any Program requirement codified in subpart D for which an ONC-ACB has responsibilities under Sec. 170.523. We propose to add the requirement that an ONC-ACBs shall report the information specified in Sec. 170.523(x) (discussed in section III.D.2.b above) to the National Coordinator pursuant to the requirements specified in Sec. 170.556(d)(7)(i), and we propose to add the requirement in Sec. 170.556(d)(7)(ii)(A) that an ONC-ACBs must notify the developer immediately when an ONC-ACB begins the notification procedures in Sec. 170.556(d)(7)(i). Lastly, we propose to revise 45 CFR 170.556 to correct regulatory text errors. First, we propose to revise Sec. 170.556(d)(6) by removing the ``or'' [[Page 63611]] within the description of ``Withdrawal'' because this was a typographical error. We also propose to revise Sec. 170.556(e)(3) by removing the reference to Sec. 170.523(f)(2)(xi). In the ONC Cures Act Final Rule, Sec. 170.523(f)(2) was removed and reserved. Therefore, we propose to remove this reference from Sec. 170.556(e)(3) to correct this technical error. We welcome comment on these proposals.

3. Updates to Principles of Proper Conduct for API Discovery Details

In the ONC HTI-1 Final Rule, we finalized requirements in Sec. 170.404(b)(2) for Certified API Developers to publish certain service base URLs and related organization details in a standardized FHIR[supreg] format (89 FR 1287). This included a requirement, in Sec. 170.404(b)(2)(iii)(B), that Certified API Developers review this information quarterly and update it as necessary. We propose a conforming policy, applicable to ONC-ACBs beginning January 1, 2027, to support the regular reporting of API discovery details including service base URLs and related organization details according to our proposed requirements in Sec. 170.404(b)(2) and (3) (see elsewhere in this preamble at III.B.2, III.B.3, III.B.15, and III.B.20.d our proposals for revising Sec. 170.404(b)(2)). Specifically, we propose to add a new paragraph in Sec. 170.523(m)(6) to require ONC-ACBs to obtain a record of all updates to API discovery details for Sec. 170.404(b)(2) and (3) on a quarterly basis each calendar year. This would ensure that ONC is aware of the latest API Discovery Details published on a quarterly basis by Certified API Developers meeting the requirements in Sec. 170.404(b)(2) and (3) and would support ONC in hosting a link to developers' API discovery details on the Certified Health IT Product List (CHPL) or another website hosted by ONC. Our proposed requirement for Sec. 170.523(m)(6) is consistent with similar existing requirements for adaptations and updates in Sec. 170.523(m), which require ONC-ACBs to obtain records on a quarterly basis. Further, this same requirement is already in place for a related certification criterion, Sec. 170.315(d)(13), which requires health IT developers to publish information and has a corresponding requirement for ONC-ACBs to obtain a record on a quarterly basis in Sec. 170.523(m)(3).

4. New ONC-ACB Principle of Proper Conduct for Notice of Program

Withdrawal To date, we have handled the infrequent occurrence of an ONC-ACB withdrawing from the Program by working collaboratively with that departing ONC-ACB and the other remaining ONC-ACBs to enable an orderly transition of certifications administered by the departing ONC-ACBs. However, as the Program has matured and the scope of an ONC-ACB's responsibilities has increased (including proposals in this proposed rule), a requirement for an ONC-ACB to provide notice to the National Coordinator when it intends to withdraw from the Program would further support an orderly transition. Accordingly, we propose in Sec. 170.523(y) a new Principle of Proper Conduct for ONC-ACBs requiring an ONC-ACB to give the National Coordinator sufficient notice of its intent to withdraw its authorization under the Program. We believe that notice provided 180 days (day is defined in Sec. 170.102 as a calendar day or calendar days) prior to the ONC-ACB's withdraw from the Program would be sufficient time for ONC to work with the ONC-ACB to ensure the ONC-ACB's planned withdrawal does not interrupt Program operations and activities, put its clients at risk of losing their certification(s) under the Program, and/or impact end users' ability to meet their business needs and requirements for participation in other Federal and/ or state programs that require the use of certified health IT. When an ONC-ACB withdraws its authorization from the Program, ONC must work with that ONC-ACB to ensure the ONC-ACB's clients are able to transition to another ONC-ACB and maintain their certified status. For an ONC-ACB to onboard a new client and issue a new certificate based on the evidence supporting a certificate previously issued by another ONC- ACB, it must possess the evidence that supports the prior ONC-ACB's decision. The transition requires the transfer of test records and other documented evidence supporting the certification. Consistent with Sec. 170.523(g)(1), ONC-ACBs are required to retain all records related to the certificates they issue, and per Sec. 170.523(g)(2) make such records available to HHS upon request during the specified retention period. Therefore, to maintain the integrity of the certifications impacted by the ONC-ACB withdrawal, ONC will request records (per Sec. 170.523(g)(2)) from the withdrawing ONC-ACB. These records will provide evidence of conformity with certification requirements to support the remaining ONC-ACBs that take on the withdrawing ONC-ACB's clients. These steps are important because, once an ONC-ACB withdraws from the Program, ONC no longer has authority over the actions of that organization. Furthermore, the influx of incoming business for the ONC-ACBs accepting requests from the withdrawing ONC- ACB's clients must be managed along with their existing workload. Specifically, we propose to add two paragraphs in Sec. 170.523(y). In Sec. 170.523(y)(1), we propose to require the withdrawing ONC-ACB to provide ONC with notice of its intent to withdraw from the Program 180 days before its actual withdrawal. In Sec. 170.523(y)(2), we propose to require the withdrawing ONC-ACB to submit all of its certification records to ONC pursuant to the retention requirements it followed in Sec. 170.523(g). We believe the combination of these two proposals will give all parties involved (i.e., ONC, the withdrawing ONC-ACB, and remaining ONC-ACBs) sufficient time to manage transition activities with minimal interruption to Program activities.

5. Updates to ONC Direct Review Procedures

In the EOA Final Rule, we created a regulatory framework for ONC's ``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 such health IT (81 FR 72404). The EOA Final Rule established bases on which ONC would initiate direct review, and procedures for ONC to follow in the event ONC's direct review of certified health IT substantiated a non-conformity. Under the framework established in the EOA Final Rule, inquiry into certified health IT's conformance with Program requirements may be conducted by ONC or a third party on ONC's behalf, and the term ``direct review'' is used to distinguish inquiries and enforcement actions taken under the 45 CFR 170.580 framework from ONC-ACBs' assessments and reviews as part of the ONC-ACB's surveillance and other responsibilities under the Program (85 FR 25738). In the ONC Cures Act Final Rule (85 FR 25642), we finalized use of substantially the same processes established in the EOA Final Rule (81 FR 72404) for the enforcement of the [[Page 63612]] Conditions and Maintenance of Certification requirements for four stated reasons (85 FR 25783). First, these processes were designed to address non-conformities with Program requirements. Conditions and Maintenance of Certification requirements have been adopted as Program requirements and, as such, any noncompliance with the Conditions and Maintenance of Certification requirements constitutes a Program non- conformity. Second, health IT developers were already familiar with the ONC direct review framework that had been put in place by the EOA Final Rule. Third, 45 CFR 170.580 provides thorough and transparent processes for identifying, notifying, and addressing non-conformities in the Program through coordination with health IT developers to craft a CAP that will remedy Program non-conformities. Fourth, the updated direct review framework provides equitable opportunities for health IT developers to respond to ONC actions and appeal certain ONC determinations. We confirmed in the ONC Cures Act Final Rule that we would continue to use the term ``direct review'' to describe activities of ONC (or a third party on ONC's behalf) under the 45 CFR 170.580 framework and to differentiate them from ONC-ACBs' reviews of certified health IT under their surveillance responsibilities outlined in 45 CFR 170.556 (85 FR 25783). In this proposed rule, we propose to revise parts of the ONC direct review regulatory framework in 45 CFR 170.580, including: 45 CFR 170.580(b) and (c) requirements for timeliness and content of health IT developers' CAPs in response to a notice that ONC has confirmed a non-conformity with Program requirements (discussed below in section III.D.3.a); 45 CFR 170.580(d) and (f) provisions for suspension and termination of certification for failure of certified health IT products or a Program-participating health IT developer to meet Program requirements (discussed below in section III.D.5.b); and 45 CFR 170.580(g) opportunity and procedures for heath IT developer appeals of ONC enforcement actions under Sec. 170.580(d) or (f) and Sec. 170.581 (discussed below in section III.D.5.b of this proposed rule). a. Health IT Developers' Response to Notices of Non-conformity and Corrective Action Plan Requirements We propose to revise regulatory provisions specific to the timing and content of health IT developers' responses to notices of non- conformity, as well as the mandatory minimum content of developers' CAPs, to improve efficiency for both ONC and developers under direct review. We propose to revise paragraph Sec. 170.580(b)(2)(ii)(A)(3) to require that, where multiple responses are provided pursuant to this paragraph, information provided in earlier responses be labeled as previously submitted. The intent of this proposed revision is to increase efficiency for ONC by making it clear that repeated submission of the same information in response to the same Notice of Non- Conformity should generally be avoided. We propose to leave in place the flexibility that health IT developers currently have to re-submit the same information in multiple communications in response to any particular Notice of Non-Conformity. Because the information that a developer may need to provide in response to a Notice of Non-Conformity can include detailed technical or business practices data, we propose to balance this developer flexibility with a requirement that if a developer does elect to resubmit the same data or information, that it must label such data or information as having been previously submitted in response to the same Notice of Non-Conformity. The labeling of any resubmitted materials would promote efficiency by enabling ONC reviewers to immediately focus on updates, addenda, or refreshed discussion of the resubmitted data. As discussed in section III.D.2.c above, we now have some experience evaluating non-conformities associated with developers failing to comply with administrative Maintenance of Certification requirements in 45 CFR 170 subpart D. We have learned from this experience that some of the mandatory minimum elements that Sec. 170.580(c)(2) currently requires for all CAPs are not equally valuable with respect to all non-conformities. For example, an assessment and description of the nature, severity, and extent of the non-conformity (the element specified in Sec. 170.580(c)(2)(i)) would likely be necessary where the ONC-substantiated non-conformity is that a certified Health IT Module is causing or contributing to a serious risk to public health or safety. The Sec. 170.580(c)(2)(i) element would also likely be necessary in cases where a certified Health IT Module is found to be non-conforming by virtue of failing to satisfy the requirements of all 45 CFR 170 subpart C certification criteria to which it is certified. By contrast, the Sec. 170.580(c)(2)(i) element is not likely to be necessary in many instances where the non- conformity is a failure to meet an administrative requirement under subpart D, such as to timely submit real world testing documentation pursuant to Sec. 170.405(b), or to submit required attestations pursuant to Sec. 170.406. Timely submission of attestations is a pass/ fail, readily observed non-conformity for which inclusion of the Sec. 170.580(c)(2)(i) element would not provide helpful or additional information. Similarly, where the resolution of the non-conformity amounts to submitting the overdue attestations or real world testing documentation, the successful resolution is self-documenting, so a detailed description of supporting documentation a developer would provide to demonstrate the identified non-conformity is resolved (as specified in Sec. 170.580(c)(2)(vi), emphasis added) generally would not be necessary or add value to the direct review process. We propose to revise paragraph (c)(2) of Sec. 170.580 to establish flexibility for ONC to identify, for any particular non-conformity, the subset of the elements listed in subparagraphs (i) through (viii) relevant to demonstrating the resolution to each non-conformity. We propose the National Coordinator may explicitly waive any of the subset of elements listed in subparagraphs (i) through (viii). ONC would continue to provide direction to the health IT developer as to the required elements of the CAP for each identified non-conformity. b. Suspension, Termination, and Appeals We propose modifications to our suspension, termination, and appeals regulations for several reasons. Some proposed revisions would simply ensure clarity as to who makes, and where ultimate accountability lies with respect to, certain decisions. Other proposed revisions would update procedures to reflect other Program changes proposed elsewhere in this rule or update regulatory text to remove now-obsolete terminology. Suspension, Termination, and Appeals Decisions We propose to clarify in our regulatory text that our procedures for decisions to terminate the certification of Health IT Modules or issue certification bans under Sec. 170.581 are made by the National Coordinator, whom the Secretary appoints to head ONC pursuant to 42. U.S.C. 300jj-11. We also propose to revise Sec. 170.580 and Sec. 170.581 to explicitly provide for the Secretary to have an opportunity to exercise direct oversight of these [[Page 63613]] determinations as well as for hearing officer determinations under 45 CFR 170.580(g). Specifically, we propose to revise paragraphs (d), (f), and (g) of Sec. 170.580 (and to revise Sec. 170.581, as discussed in section III.D below). We propose to modify Sec. 170.580(d) and Sec. 170.580(f) to reflect that the National Coordinator makes determinations to suspend or terminate a certification, and to cancel a suspension or to rescind a termination determination. But, to ensure that it is clear, notwithstanding the decision of the National Coordinator, that the Secretary, a principal officer of the United States, retains ultimate responsibility for such decision-making, we propose that the Secretary may, at the Secretary's discretion, review a determination of the National Coordinator. The Secretary may direct the National Coordinator to cancel a suspension (paragraph (d)(6)(ii)) or review a termination determination made by the National Coordinator before such suspension or the termination would become effective (paragraph (f)(5)). We propose in Sec. 170.580(f)(5) that, should the Secretary direct the National Coordinator to rescind a termination, ONC may resume (Sec. 170.580(f)(5)(i)) or end (Sec. 170.580(f)(5)(ii)) all or part of its review of certified health IT or a health IT developer's actions or practices under this section unless the Secretary specifically directs otherwise. Updates to Align with Other Proposals in This Proposed Rule We propose to modify paragraph (f) of Sec. 170.580 to align with proposed added responsibilities of ONC-ACBs for confirming and encouraging compliance with certain Maintenance of Certification requirements codified in subpart D of 45 CFR part 170 (discussed in section III.D.2 of this proposed rule, above). Specifically, we propose in Sec. 170.580(f)(1)(iv) to provide for the National Coordinator to terminate a certification based on ONC review of the information and documentation reported by the ONC-ACB pursuant to the principles of proper conduct (PoPC) proposed in paragraph (x) of Sec. 170.523 (discussed in section III.D.2.b) that the developer did not fulfill its obligation under a CAP. This would explicitly establish that the National Coordinator may make a termination determination without ONC being required to engage in duplicative fact-finding in applicable non- conformity cases. Applicable cases would be those where the information and documentation provided in the ONC-ACB's Sec. 170.523(x) report is, in the National Coordinator's view, sufficient to substantiate that a developer has failed to resolve a Program non-conformity related to a Maintenance of Certification requirement within the required timeframe of the CAP verified and approved by the ONC-ACB. The National Coordinator's consideration of the record submitted by the ONC-ACB pursuant to Sec. 170.523(x) would include assessing whether the ONC- ACB had met its obligations to notify the developer of the non- conformity and initiate corrective action procedures under Sec. Sec. 170.523 and 170.556. We also propose revisions to Sec. 170.580(a)(3)(iii), (a)(3)(v), and (a)(4)(ii) to clarify that the: (1) National Coordinator's determination on matters under ONC direct review is controlling and supersedes any determination by an ONC-ACB; (2) National Coordinator may end all or any part of ONC's review of certified health IT or a health IT developer's actions at any time; and (3) National Coordinator may rely on HHS Office of Inspector General (OIG) findings to form the basis of a direct review action. We also propose revisions to Sec. 170.580(b)(2)(ii)(B) and Sec. 170.580(b)(2)(iii) clarifying that the National Coordinator may adjust the 30-day timeline under Sec. 170.580(b)(2)(ii)(A)(3) and that the National Coordinator makes a determination under Sec. 170.580(b)(2)(iii) after receiving the health IT developer's written explanation and supporting documentation. We propose to revise Sec. 170.580(c)(1) clarifying that if the National Coordinator determines that certified health IT or a health IT developer's action or practice does not conform to requirements of the Program, ONC will notify the health IT developer of its determination and require the health IT developer to submit a proposed CAP. In Sec. 170.580(c)(2), we propose that the CAP shall include such required elements that the National Coordinator determines necessary. The CAP shall include, for each specific non-conformity, all the elements in Sec. 170.580(c)(2) except when the elements are explicitly waived by the National Coordinator. We also propose to update Sec. 170.580(c)(7) to provide that a CAP may be reinstituted by ONC if the National Coordinator later determines that a health IT developer has not yet fulfilled all its obligations under the CAP. We also propose revisions to Sec. 170.580(e)(1), (e)(1)(vii), (e)(2), and (e)(4) clarifying the actions that the National Coordinator can take with a proposed termination and updating the existing language to clarify that certain decisions are made by the National Coordinator, with ultimate accountability for the National Coordinator's decisions vested in the Secretary as discussed above. More specifically, we propose that: (1) excluding situations of noncompliance with a Condition or Maintenance of Certification requirement under subpart D of this part, the National Coordinator may propose to terminate a certification issued to a Health IT Module when a health IT developer fails to respond timely to a communication from ONC, fails to provide sufficient access or information to ONC, or the National Coordinator concludes that a certified health IT's non-conformity(ies) cannot be cured (Sec. 170.580(e)(1) and (e)(1)(vii)); (2) ONC will notify the health IT developer of the proposed termination through a notice of proposed termination when the National Coordinator decides to propose to terminate a certification (Sec. 170.580(e)(2)); and, (3) upon receipt of the health IT 'developer's written response to a notice of proposed termination, the National Coordinator has up to 30 days to make a determination based on ONC's review of the information submitted by the health IT developer and the National Coordinator may extend this timeframe if the complexity of the case requires additional time for ONC review (Sec. 170.580(4)). c. Appeals The ONC direct review regulatory framework established in the EOA Final Rule (81 FR 72404) included (in Sec. 170.580(g)) procedural provisions for developers to appeal certification termination determinations made by the National Coordinator under Sec. 170.580(f) as well as Program bans issued under Sec. 170.581. In the ONC Cures Act Final Rule, we established that we would use the processes previously put in place for ONC direct review of certified health IT in the enforcement of the Conditions and Maintenance of Certification requirements. In doing so, we finalized modifications to Sec. 170.580(g) provisions to address the inclusion of Condition and Maintenance of Certification requirements under Sec. 170.580(f) and Sec. 170.581 (85 FR 25649 and 25787). We propose to rename Sec. 170.580(g)(5) to ``Assignment of a hearing officer'' and clarify the text to explain that the National Coordinator will arrange for assignment of the case to a hearing officer to adjudicate the appeal on the National Coordinator's behalf, and add subparagraph (iii) that the hearing officer must be an officer properly appointed by the Secretary of Health and Human Services. [[Page 63614]] We propose to explicitly provide in Sec. 170.580(g)(7)(ii) for the Secretary, at the Secretary's discretion, to review and revise or rescind hearing officer decisions before these decisions become the final decision of HHS. This proposed change would ensure the regulatory text is explicit that the Secretary, as a principal officer of the United States, holds appropriate oversight and accountability for the hearing officer's decisions. We welcome comments on these proposals.

6. Certification Ban

We propose to update paragraphs (a) and (b) of the certification ban provisions in Sec. 170.581 to explicitly provide for the Secretary to review, at the Secretary's discretion, the National Coordinator's determination to impose a ban before the ban becomes effective. We further propose updates to Sec. 170.581(a)(2) and (d)(4) to indicate that the National Coordinator as a duly appointed officer of the United States, rather than ONC as an organization, would make any determination to impose a certification ban on a developer. These proposed revisions are similar to those we discussed above for suspension and termination. We propose to update the wording of Sec. 170.581(a)(1)(i) to replace a reference to termination of a Health IT Module ``under the ONC Health IT Certification Program'' to cross-reference the paragraph within Sec. 170.580 specific to termination of a certification in the context of ONC direct review. We believe the specific cross-reference would make it easier for developers, ONC-ACBs, and other interested parties to read and understand Sec. 170.581(a)(1)(i). In parallel to our proposed addition of PoPCs and surveillance responsibilities for ONC-ACBs specific to certain Maintenance of Certification requirements in subpart D of 45 CFR part 170 (both in Sec. 170.523), we propose to explicitly establish in Sec. 170.581(a)(2) that the National Coordinator would have the option of determining a certification ban is appropriate based on the information and documentation provided in an ONC-ACB's Sec. 170.523(x) report. We believe this is important to ensure that the National Coordinator can take prompt action, without duplicative data gathering or fact finding, where the information and record submitted by the ONC-ACB indicates to the National Coordinator that a program ban is appropriate. We welcome comment on these proposals.

7. Updates Pursuant to 2014 Edition Removal

We propose to remove the ``Complete EHR'' and ``EHR Module'' terms from certain sections within subpart E of 45 CFR 170. By the time we would finalize any proposal in this proposed rule, the terms would no longer be relevant, as described below, due to the amount of time that will have 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 The ONC Cures Act Final Rule removed the 2014 Edition certification criteria in Sec. 170.314 from the Program regulations in 45 CFR part 170 (85 FR 25656). The rule also finalized our proposals (84 FR 7434 through 7435) to remove terms and definitions specific to the 2014 Edition from Sec. 170.102, including the ``2014 Edition Base EHR,'' ``2014 Edition EHR certification criteria,'' and ``Complete EHR, 2014 Edition'' definitions. As explained in the 2015 Edition Final Rule (80 FR 62719), the ``Complete EHR'' concept was discontinued for the 2015 Edition. In conjunction with the removal of the 2014 Edition, we also removed references to ``Complete EHR'' from Sec. 170.545 and removed the standards and implementation specifications found in Sec. Sec. 170.200, 170.202, 170.204, 170.205, 170.207, 170.210, and 170.299 that were referenced only in the 2014 Edition certification criteria (85 FR 25656). In the HTI-1 Final Rule, we removed the ``Complete EHR'' language from all reference points in Sec. Sec. 170.523 and 170.524 (89 FR 1209 through 1210). Although we removed terms, standards, and certification criteria that were applicable only to the 2014 Edition in the ONC Cures Act Final Rule, we have retained until now reference to ``Complete EHRs'' in certain provisions within subpart E of 45 CFR part 170: The definition of ``gap certification'' (Sec. 170.502); Authorization scope for ONC-ATL status (Sec. 170.511); Requirements for ONC-ACBs to refund fees to developers seeking certification under certain circumstances (Sec. 170.523(j)(3)); and Applicability of a newer version of a minimum standard (Sec. 170.555(b)(2)). Retaining reference to ``Complete EHRs'' in these part 170 subpart E requirements has supported continuity following the removal of the 2014 Edition's standards and certification criteria from 45 CFR part 170. For example, in the update of ONC-ACB record retention requirements in Sec. Sec. 170.523 and 170.524 to align with the transition of the Program's structure and terminology away from annual themed ``editions,'' the ``Complete EHR'' concept remained relevant to 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). 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). Beginning with the 2015 Edition, Complete EHR certifications could no longer be issued and December 31, 2023, has passed. Thus, we now propose to remove references to ``Complete EHRs'' from Sec. Sec. 170.502,170.511, 170.523(j)(3), and 170.555(b)(2) as of the effective date of a subsequent final rule for this rulemaking. b. Removal of ``EHR Modules'' References In the 2011 ``Establishment of the Permanent Certification Program for Health Information Technology'' Final Rule (76 FR 1261), we used the Complete EHR and EHR Module terms and phrasing ``Complete EHRs and/ or EHR Modules.'' In the rule, we stated our initial focus would be on EHR technology and supporting the EHR Incentive Programs, which at the time, focused on the ambulatory and inpatient settings (76 FR 1294). As we explained in the 2015 Edition Final Rule (80 FR 62601), we changed the name of the ONC HIT Certification Program to the ``ONC Health IT Certification Program'' (Program). We also modified the Program in ways that 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 (80 FR 62604). These modifications also served to support other public and private programs that may reference the use of health IT certified under the Program (80 FR 62604). 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 subparts A, [[Page 63615]] 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 have now passed both rules' three-year retention requirements for ONC-ACBs and the term ``EHR Module'' is no longer relevant, we propose to remove from Sec. 170.523(f) reference to ``EHR Modules.''

8. Definition of Serious Risk to Public Health or Safety

We propose to revise 45 CFR 170.102 to include a definition of serious risk to public health or safety. The purpose of this proposed definition is to enhance understanding among developers and users of certified health IT of the types of conditions, events, or phenomena that would constitute egregiously dangerous non-conformities with Program requirements. Such events could be caused or contributed to by health IT certified as a Health IT Module or as part of a certified Health IT Module even if the certified Health IT Module(s) continued to pass lab testing procedures, in-the-field surveillance testing, or both with respect to the technical standards and certification criteria adopted in subparts B and C of part 170. Within the proposed regulation text for this proposed definition of serious risk to public health or safety, we have included fact patterns in (1) through (6) that would always meet the definition of serious risk to public health or safety. For purposes of these examples, a ``user'' of a certified Health IT Module would be any human being or any software application, process, or service that is authorized, intended, and enabled to create, read, update, or delete (CRUD) or to command the certified Health IT Module to execute specific CRUD functions on specific data entries. We request public comment on this definition, including but not limited to the illustrative examples. We would continue to expect, as we reiterated in the EOA Final Rule, that ONC direct review on the bases of risk to public safety or where ONC-ACBs may be unable to respond effectively would occur relatively infrequently (cf., e.g., 81 FR 72404 at 72415 or 74216). As we explained in the EOA Final Rule, we do not believe every risk to public health or safety necessitates ONC's direct review. We also recognize the need to prioritize ONC's limited resources by focusing on the kinds of problems and other issues that, if not addressed through ONC's direct review, are most likely to lead to harm to patients or the public and undermine confidence in health IT and the integrity of the Program (81 FR 72419). This proposed definition would not change this need to prioritize ONC's resources.

9. Removal of Time-Limited Criteria

In the ONC Cures Act Final Rule, we finalized Sec. 170.550(m) ``time-limited certification and certification status for certain 2015 Edition certification criteria'' which provided that for five specific certification criteria, an ONC-ACB may only issue a certification to a Health IT Module and permit continued certified status for a specified time period (85 FR 25952). The five criteria with time-limited certification and certification status are found in Sec. 170.315(a)(10), (a)(13), (b)(6), (e)(2), and (g)(8). Because the specified time periods for certification to these criteria have elapsed, we propose to remove all of the certification criteria referenced in Sec. 170.550(m) in one action by removing and reserving Sec. 170.550(m) in its entirety. We also propose to remove and reserve these aforementioned certification criteria from the specific CFR locations in which they are adopted. In the ONC Cures Act Final Rule, we also finalized revisions in Sec. 170.315(b)(7)(ii) and (b)(8)(i)(B) to allow security tagging of Consolidated-Clinical Document Architecture (C-CDA) documents at the document level only for the period until 24 months after publication date of the final rule (85 FR 25667). Because that time period has elapsed, we propose to revise Sec. 170.315(b)(7) and (8) to remove Sec. 170.315(b)(7)(ii) and (b)(8)(i)(B). We describe our detailed proposals below. The requirements finalized in the ONC Cures Act Final Rule in Sec. 170.550(m)(1) permit ONC-ACBs to issue certificates for the ``drug- formulary and preferred drug list checks'' certification criterion in Sec. 170.315(a)(10) up until January 1, 2022 (85 FR 25661). We stated in the ONC Cures Act Final Rule that we believed the functionality in Sec. 170.315(a)(10) was ubiquitous due to widespread adoption of health IT certified to the 2014 Edition and that we did not believe it was necessary to continue to require certification to it under the Program in order to ensure it remains widely available (85 FR 25661). We also stated that because the certification criterion did not require use of standards or directly drive interoperability, we did not believe its continued inclusion in the Program would provide sufficient value to providers or patients to justify the burden on developers and providers (85 FR 25661). We propose to remove and reserve Sec. 170.315(a)(10). In the ONC Cures Act Final Rule, we finalized requirements in Sec. 170.550(m)(1) permitting ONC-ACBs to issue certificates for the ``patient-specific education resources'' certification criterion in Sec. 170.315(a)(13) up until January 1, 2022 (85 FR 25661). We stated that we believed that health IT's capabilities to identify appropriate patient education materials was widespread among health IT developers and their customers, and noted innovation had occurred for these capabilities, including the use of automation and algorithms to provide appropriate education materials to patients in a timely manner (85 FR 25661). 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). We propose to remove and reserve Sec. 170.315(a)(13). The requirements finalized in the ONC Cures Act Final Rule in Sec. 170.550(m)(1) permitted ONC-ACBs to issue certificates for the ``secure messaging'' certification criterion in Sec. 170.315(e)(2) up until January 1, 2022 (85 FR 25662). In the ONC Cures Act Final Rule, while we did not finalize removal of the requirements in Sec. 170.315(e)(2), we stated that we no longer believed that a separate certification criterion focused on a health IT's capabilities to send and receive secure messages between health care providers and patients was necessary and that the certification criterion would also no longer be associated with an objective or measure under the CMS PI Programs (85 FR 25662). We propose to remove and reserve Sec. 170.315(e)(2). In the ONC Cures Act Final Rule, we finalized requirements in Sec. 170.550(m)(2) permitting ONC-ACBs to issue certificates for the ``data export'' certification criterion in Sec. 170.315(b)(6) up until May 1, 2023 (85 FR 25662). This date was later extended to December 31, 2023, in the Information Blocking and the ONC Health IT Certification Program: Extension of Compliance Dates and Timeframes in Response to the COVID-19 Public Health Emergency Interim Final Rule (85 FR 70070). We noted in the ONC Cures Act Final Rule that Sec. 170.315(b)(6) was replaced by the ``EHI export'' certification criterion in Sec. 170.315(b)(10) and removed from the 2015 Edition Base EHR definition in Sec. 170.102, and that this would encourage movement toward the interoperability opportunities afforded by new criteria [[Page 63616]] (85 FR 25699). We propose to remove and reserve Sec. 170.315(b)(6). The requirements finalized in the ONC Cures Act Final Rule in Sec. 170.550(m)(2) permit ONC-ACBs to issue certificates for the certification criterion in Sec. 170.315(g)(8) ``application access-- data category request'' up until May 2, 2022 (85 FR 25666). This date was later extended to December 31, 2022, in the Information Blocking and the ONC Health IT Certification Program: Extension of Compliance Dates and Timeframes in Response to the COVID-19 Public Health Emergency Interim Final Rule (85 FR 70070). We noted in the ONC Cures Act Final Rule that we had adopted a new API certification criterion in Sec. 170.315(g)(10) to replace the certification criterion in Sec. 170.315(g)(8) and added the new certification criterion to the updated 2015 Edition Base EHR definition (85 FR 25645). We propose to remove and reserve Sec. 170.315(g)(8). In the ONC Cures Act Final Rule, we finalized revisions in Sec. 170.315(b)(7)(ii) and (b)(8)(i)(B) to allow certification of health IT to demonstrate 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 25707). This date was later extended to December 31, 2022, in the Information Blocking and the ONC Health IT Certification Program: Extension of Compliance Dates and Timeframes in Response to the COVID- 19 Public Health Emergency Interim Final Rule (85 FR 70070). We noted in the ONC Cures Act Final Rule that only requiring tagging C-CDA documents at the document level did not permit providers the flexibility to address more complex use cases for representing patient privacy preferences (85 FR 25645). We now propose to revise Sec. 170.315(b)(7) and (b)(8) to remove Sec. 170.315(b)(7)(ii) and (b)(8)(i)(B).

10. Privacy and Security Framework Incorporation of DSI Criterion

In the ONC HTI-1 Final Rule, we established a revised certification criterion (``decision support interventions'' (Sec. 170.315(b)(11)) to replace the ``clinical decision support'' certification criterion (Sec. 170.315(a)(9)) effective January 1, 2025 (89 FR 1196 through 1197). When finalizing the ``decision support interventions'' certification criterion, we did so by adopting a substantially similar structure to the structure of the ``clinical decision support'' certification criterion. 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. We now propose to add the ``decision support interventions'' certification criterion (Sec. 170.315(b)(11)) to the list of certification criteria in Sec. 170.550(h)(3)(ii). This proposal would ensure that the same privacy and security certification requirements that apply to the ``clinical decision support'' certification criterion (Sec. 170.315(a)(9)) also apply to Health IT Modules certified to the ``decision support interventions'' certification criterion. To provide developers of certified health IT time to comply with these proposed requirements, we specifically propose to require, in Sec. 170.550(h)(3)(ii), that Health IT Modules certified to the ``decision support interventions'' (Sec. 170.315(b)(11)) must also be certified to the specific privacy and security certification criteria on and after January 1, 2028. These specific privacy and security certification criteria are: ``authentication, access control, and authorization'' in Sec. 170.315(d)(1); ``auditable events and tamper- resistance'' in Sec. 170.315(d)(2); ``audit report(s)'' in Sec. 170.315(d)(3); ``automatic access time-out'' in Sec. 170.315(d)(5); ``end-user device encryption'' in Sec. 170.315(d)(7); ``encrypt authentication credentials'' in Sec. 170.315(d)(12); and ``multi- factor authentication'' in Sec. 170.315(d)(13). We note that should we finalize our proposed revisions to ``encrypt authentication credentials'' in Sec. 170.315(d)(12) (as discussed in section III.B.12) and finalize our proposal to revise Sec. 170.550(h)(3)(ii) as described above, those revised requirements would apply to Health IT Modules certified to the ``decision support interventions'' certification criterion (Sec. 170.315(b)(11)). However, we further note that should we finalize our proposed revisions to the ``multi-factor authentication'' certification criterion in Sec. 170.315(d)(13) as described in section III.B.17, and should we finalize our proposal to revise Sec. 170.550(h)(3)(ii) as described above, Health IT Modules certified to the ``decision support interventions'' certification criterion would not be required to support the new multi- factor authentication requirements, due to the timing included in our proposed updates in Sec. 170.550(h)(3)(ii), unless those Health IT Modules are also certified to Sec. 170.315(b)(3), Sec. 170.315(e)(1), Sec. 170.315(g)(10), or Sec. 170.315(g)(30) and required to meet the multi-factor authentication requirements in those certification criteria in Sec. 170.315(b)(3)(ii)(G), Sec. 170.315(e)(1)(iii), Sec. 170.315(g)(10)(ii)(A)(1)(iii), or Sec. 170.315(g)(30)(ii)(c) respectively.

E. Correction--Privacy and Security Certification Framework

We propose to make a correction to the Privacy and Security Certification Framework in Sec. 170.550(h). We revised Sec. 170.550(h) in the ONC Cures Act Final Rule but intended for Sec. 170.550(h)(4) to remain unchanged. However, when we drafted the amendatory instructions, we erroneously included the instruction to revise all of paragraph (h) (85 FR 25952). Therefore, when the Code of Federal Regulations (CFR) was updated, Sec. 170.550(h)(4) was removed. We now propose to add back to the CFR 170.550(h)(4) [45 CFR 170.550(h)(4) (Jan. 1, 2020)] as it existed prior to the ONC Cures Act Final Rule. The language in Sec. 170.550(h) to be added to paragraph (4) is, ``Methods to demonstrate compliance with each privacy and security criterion. One of the following methods must be used to meet each applicable privacy and security certification criterion listed in paragraph (h)(3) of this section: (i) Directly, by demonstrating a technical capability to satisfy the applicable certification criterion or certification criteria; or (ii) Demonstrate, through system documentation sufficiently detailed to enable integration, that the Health IT Module has implemented service interfaces for each applicable privacy and security certification criterion that enable the Health IT Module to access external services necessary to meet the privacy and security certification criterion.

1. Health Care Provider

Health care provider, as defined in 45 CFR 171.102 for purposes of the information blocking regulations, has the same meaning as `health care provider' in 42 U.S.C. 300jj. As finalized in the ONC Cures Act Final Rule (85 FR 25642), this definition cites to the entirety of 42 U.S.C. 300jj (section 3000 of the Public Health Service Act (PHSA)). We now propose to provide additional regulatory clarity for the ``health care provider'' definition and for certain types of health care providers referenced by the ``health care provider'' definition. We propose to revise Sec. 171.102 to explicitly reference the ``health care provider'' definition in 42 U.S.C. 300jj(3) and the definitions of [[Page 63617]] ``laboratory'' in 42 U.S.C. 300jj(10) and ``pharmacist'' in 42 U.S.C. 300jj(12). In the ONC Cures Act Final Rule (85 FR 25794), we adopted a definition of ``health care provider'' citing 42 U.S.C. 300jj, indicating we had noted in the ONC Cures Act Proposed Rule (84 FR 7510) that the PHSA section 3000(3) definition is different from the definition of ``health care provider'' in 45 CFR 160.103 for purposes of the HIPAA Privacy and Security Rules. We now propose to revise the definition of ``health care provider'' in Sec. 171.102 to explicitly cite 42 U.S.C. 300jj(3). In addition, we propose to explicitly incorporate the PHSA section 3000 definitions of ``laboratory'' and ``pharmacist.'' The ``health care provider'' definition in paragraph (3) of PHSA section 3000 (cited in the regulatory text as 42 U.S.C. 300jj(3)) references these types of health care providers without further definition. While our interpretation of these types of health care providers has always relied on the 42 U.S.C. 300jj(10) and (12) definitions of ``laboratory'' and ``pharmacist,'' we now propose to formally incorporate these definitions into the health care provider definition codified in Sec. 171.102. Specifically, we propose to add to the Sec. 171.102 definition of ``health care provider'' subparagraphs designated as (1) and (2) and citing, respectively, paragraphs (10) and (12) of 42 U.S.C. 300jj. In 42 U.S.C. 300jj(10), ``laboratory'' has the meaning given such term in 42 U.S.C. 263a(a) (PHSA section 353(a)). In 42 U.S.C. 300jj(12), ``pharmacist'' has the meaning given such term in 21 U.S.C 384(a)(2). For ease of reference, we provide in the following paragraphs of this preamble the laboratory and pharmacist definitions cross-referenced by 42 U.S.C. 300jj(10) and (12). As stated in 42 U.S.C. 263a(a): ``laboratory'' or ``clinical laboratory'' means ``a facility for the biological, microbiological, serological, chemical, immuno-hematological, hematological, biophysical, cytological, pathological, or other examination of materials derived from the human body for the purpose of providing information for the diagnosis, prevention, or treatment of any disease or impairment of, or the assessment of the health of, human beings.'' In addition to having been cited by 42 U.S.C. 300jj since the HITECH Act added Title XXX to the PHSA in 2009, this definition of ``laboratory'' or ``clinical laboratory'' has stood since the Clinical Laboratory Improvement Amendments of 1988 amended section 353 of the PHSA (42 U.S.C. 263a(a)) to include this definition.\227\ --------------------------------------------------------------------------- \227\ See section 2 of the Clinical Laboratory Improvement Amendments of 1988 (Pub. L. 100-578,102 Stat. 2903). See also 42 U.S.C. 263a(a) authority citations (available online at https://uscode.house.gov/view.xhtml?req=granuleid:U.S.C.-prelim-title42-section263a&num=0&edition=prelim). --------------------------------------------------------------------------- As stated in 21 U.S.C. 384(a)(2), the term ``pharmacist'' means ``a person licensed by a State to practice pharmacy, including the dispensing and selling of prescription drugs.'' While the text of 42 U.S.C. 300jj(12) cites ``the meaning given such term in section 384(2) of title 21'' the only definition of ``pharmacist'' appearing in 21 U.S.C. 384 is found in paragraph (a)(2).\228\ --------------------------------------------------------------------------- \228\ Note 3 to 42 U.S.C. 300jj as it appears in the U.S. Code as maintained by the Office of law Revision Counsel of the U.S. House of Representatives reads: So in original. Probably should be ``(a)(2)''. (Available online at: https://uscode.house.gov/view.xhtml?req=granuleid%3AUSC-prelim-title42-chapter6A-subchapter28&saved=%7CZ3JhbnVsZWlkOlVTQy1wcmVsaW0tdGl0bGU0Mi1zZWN0aW9uMzAwamotNTI%3D%7C%7C%7C0%7Cfalse%7Cprelim&edition=prelim#300jj_3_target.) --------------------------------------------------------------------------- We welcome comment on this proposal.

2. Health Information Technology or Health IT

We propose to codify in Sec. 171.102 that, for purposes of the information blocking regulations in 45 CFR part 171, both ``health information technology'' and its shorter form, ``health IT,'' have the same meaning as ``health information technology'' in 42 U.S.C. 300jj(5). The health information technology definition was added to the Public Health Service Act (PHSA) (section 3000(5)) by the HITECH Act (see Title XIII, Subtitle A, section 13101 of the American Recovery and Reinvestment Act of 2009, Pub. L. 111-5). The PHSA defines health information technology as ``hardware, software, integrated technologies or related licenses, intellectual property, upgrades, or packaged solutions sold as services that are designed for or support the use by health care entities or patients for the electronic creation, maintenance, access, or exchange of health information.'' Because the 21st Century Cures Act added the information blocking statute to Title XXX of the PHSA as section 3022 (42 U.S.C. 300jj-52), we believe the most applicable definition of the term ``health information technology'' in the context of PHSA section 3022 and our regulations in 45 CFR part 171 is the definition found at 42 U.S.C. 300jj(5). We believe that codifying this interpretation will increase certainty for actors \229\ and other interested parties that when we refer to ``health information technology'' or ``health IT'' in 45 CFR part 171, we mean the 42 U.S.C. 300jj(5) definition unless otherwise specified in or for a specific subpart or section. --------------------------------------------------------------------------- \229\ Throughout Section IV of this proposed rule, we use ``actor'' as it is defined in Sec. 171.102. (We do not propose in this rule to revise that codified definition.) --------------------------------------------------------------------------- We leveraged the definition of ``health information technology'' from Title XXX of the PHSA (specifically, section 3000(5) of the PHSA) in finalizing the definition of ``interoperability element'' in Sec. 171.102, but we did not use it in its entirety and did not explicitly cite it, in the ``interoperability element'' definition (85 FR 25956, see also preamble discussion at 85 FR 25807). This proposal to adopt a definition for ``health information technology'' in Sec. 171.102 would not change the definition of ``interoperability element'' in Sec. 171.102. Our definitions of ``health IT developer of certified health IT'' and ``offer health IT'' as they are currently codified in Sec. 171.102 explicitly reference the definition of ``health information technology'' in 42 U.S.C. 300jj(5). Thus, this proposal would not change the meaning of either of those definitions. We welcome comments on this proposal.

3. ``Interfere With'' or ``Interference''

The 21st Century Cures Act defined information blocking in part as a practice that ``is likely to interfere with, prevent, or materially discourage access, exchange, or use of electronic health information'' (42 U.S.C. 300jj-52(a)(1)). In the definitions section of the information blocking regulations (Sec. 171.102), we define interfere with or interference to mean ``to prevent, materially discourage, or otherwise inhibit.'' We propose to add a new section (45 CFR 171.104) to codify certain practices that constitute ``interference'' and ``interfere with'' (as defined in Sec. 171.102) for purposes of the information blocking definition in Sec. 171.103. Although these practices constitute an interference, we note that the list is not exhaustive and other practices not described in this proposed new section will also constitute an interference for purposes of the information blocking definition. We emphasize that these proposed provisions are practices that constitute an interference. We do not attempt to establish facts and circumstances in this proposed rule that would specify practices that are information blocking [[Page 63618]] as the term is defined in Sec. 171.103. For a practice to be information blocking, all elements of the definition must be met. This means that the individual or entity that engages in the practice must be an actor under the information blocking regulations; that the practice must be likely to interfere with the access, exchange, or use of EHI; and that the actor engaging in the practice meets the requisite knowledge standard. Further, ``information blocking'' does not include practices required by law or that meet an exception. In the ONC Cures Act Proposed Rule (84 FR 7424), we noted that the information blocking provision and its enforcement subsection in the 21st Century Cures Act do not define the terms ``interfere with,'' ``prevent,'' and ``materially discourage.'' Based on our interpretation of the information blocking provision, as discussed in the Cures Act Proposed Rule, we proposed to define ``interfere with'' and ``interference'' as preventing, materially discouraging or otherwise inhibiting access, exchange, or use of electronic health information (84 FR 7516, 7601). We finalized the definition in the ONC Cures Act Final Rule as proposed, but with a modification to remove the phrase ``access, exchange, or use of electronic health information'' as unnecessary and duplicative of the information blocking definition (85 FR 25642, 25809; see also 45 CFR 171.102). The preamble discussion of the definition of ``interfere with'' or ``interference'' in the ONC Cures Act Final Rule provides guidance explaining the meaning of these terms. In the ONC Cures Act Proposed Rule, to further clarify the scope of the information blocking provision, we provided several examples of practices that would constitute interference. We refer readers to the ONC Cures Act Proposed Rule (84 FR 7518 through 7521) for discussion of those examples, which we also cited in the ONC Cures Act Final Rule (85 FR 25811). We refer readers to the ONC Cures Act Final Rule (85 FR 25811 through 25818) for additional examples of practices likely to interfere with access, exchange, or use of electronic health information (EHI) and additional discussion, including responses to public comments received on the ONC Cures Act Proposed Rule. Since publication of the ONC Cures Act Final Rule (May 1, 2020), we have provided additional guidance in the form of information blocking Frequently Asked Questions (FAQs). As of the time of publication of this proposed rule, we have posted 12 FAQs in the ``Interference'' category. Links to all categories of FAQs within the information blocking topic are available under the ``Resources'' heading of this page of ONC's website: https://www.healthit.gov/topic/information-blocking.\230\ --------------------------------------------------------------------------- \230\ The link to the interference category of FAQs directs to this URL: https://www.healthit.gov/faqs?f%5B0%5D=subtopic%3A7031. (Retrieved Apr. 9, 2024.) --------------------------------------------------------------------------- Certain practices have been brought to our attention through submissions to the Report Information Blocking Portal, questions we have received through the HealthIT.gov Feedback and Inquiry Portal, and other interactions (including interactions with parties interested in learning more about seeking or providing access, exchange, or use of EHI).\231\ Often, the party will present a hypothetical scenario and inquire if the practice constitutes information blocking. For a variety of reasons, ONC does not opine on whether a given practice constitutes information blocking. First, ONC does not have authority to offer binding advisory opinions.\232\ Second, ONC cannot readily determine whether a scenario focused on a specific action or inaction generally constitutes information blocking because whether a practice meets the Sec. 171.103 information blocking definition will involve an assessment of all the elements of the information blocking definition, as discussed above, and will be based on the facts and circumstances of each unique situation. --------------------------------------------------------------------------- \231\ Report Information Blocking Portal URL: https://inquiry.healthit.gov/support/plugins/servlet/desk/portal/6Health IT Feedback and Inquiry Portal URL: https://inquiry.healthit.gov/support/plugins/servlet/desk/portal/2 Other interactions with interested parties include, for example, interactive discussion in various public venues, such as the ``Ask Us About Information Sharing'' sessions ONC has hosted since May 2020. (https://www.healthit.gov/newsroom/past-events) \232\ ONC requested but did not receive advisory opinion authority via the Congressional Appropriations Committee in fiscal years 2023 and 2024. --------------------------------------------------------------------------- Informed by the concerns and questions that interested parties have brought to our attention, we propose to add Sec. 171.104 to 45 CFR part 171 to codify that certain practices will constitute interferences for purposes of the information blocking definition. As previously noted, the practices we propose to codify are not an exhaustive list of all practices that constitute interferences. The practices in the proposed Sec. 171.104 are intended to help regulated entities and other interested parties by codifying certain practices that constitute interferences for purposes of the information blocking definition. The practices we propose to codify include affirmative acts as well as omissions, because a practice, under the information blocking definition, can be ``an act or omission committed by an actor.'' The practices we propose to codify generally relate to: Actions taken by an actor to impose delays on other persons' access, exchange, or use of EHI; Non-standard implementation of health IT and other acts to limit interoperability of EHI or the manner in which EHI is accessed, exchanged, or used by other persons; Improper inducements or discriminatory contract provisions; and Omissions (failures to act). Some omissions which constitute interferences in the proposed Sec. 171.104 include failures to publish (or make available for publication) technical information such as service base URLs for Certified API Technology. Other types of omissions include an actor's failure to fulfill requests for access, exchange, or use of EHI that is required by law, or failure to fulfill requests for access, exchange, or use of EHI when it is permitted by law and not inconsistent with any additional restrictions on access to the individual's EHI that the individual (patient) or their personal representative may have requested and that an actor agreed to honor. In the proposed Sec. 171.104(a)(3), we describe ``delaying the access, exchange, or use of EHI to or by a third-party app designated and authorized by the patient when there is a deployed application programming interface (API) able to support the access, exchange, or use of the EHI.'' In this paragraph and corresponding regulatory text (Sec. 171.104(a)(3)), the term ``app,'' as used in ``third-party app,'' describes any number of ``applications'' (or types of applications) a patient could use to access, exchange, or use their EHI--on their smart phone, computer, or smart watch, for example. These ``apps'' are able to communicate with other health information technology through an API (such as a Health IT Module certified to Sec. 170.315(g)(10)) that permits EHI to be accessed and exchanged at the patient's direction. In the proposed Sec. 171.104(a)(6), we note that certain non- compete clauses can implicate the information blocking definition. In the ONC Cures Act Proposed Rule, we stated that one means by which actors may restrict access, exchange, or use of EHI is through formal, contractual restrictions (84 FR 7518). We provided several examples of restrictive contractual clauses in that proposed rule (84 FR 7518). In the ONC Cures Act Final Rule, we acknowledged that many [[Page 63619]] commenters stated that EHR developers place onerous contract terms on developers of applications that enable patient access to EHI through APIs (88 FR 25811). Regulated entities, software developers, and patient advocates have continued to express concerns to ONC about restrictive contractual clauses. Actors are placing conditions on access to EHI in the actor's health IT that are unrelated to security or privacy laws, and function as anti-competitive clauses that effectively prevent certain employees or contractors from accessing, exchanging, or using EHI in other health IT. Therefore, we propose to identify a particular type of contractual clause as an interference: negotiating or enforcing a clause in any agreement that prevents or restricts an employee (other than the actor's employees), contractor, or contractor's employee who accesses, exchanges, or uses the EHI in the actor's health IT from accessing, exchanging, or using EHI in other health IT in order to participate in the design, development, or upgrade of such other health IT. This proposal is intended specifically to make clear that it is an interference to prevent employees of an individual or entity (other than the actor's employees) from working on software development and design for both Company A (actor's company) and Company B, even if the companies are competitors or potential competitors, and even if the work is being conducted simultaneously. We note that this interference could be found in ``any agreement,'' even an agreement to which the actor is not a party, provided that the actor requires another party to include such a clause in that party's contracts with its employees or contractors. In addition, it is an interference for the actor to negotiate or enforce such a clause--again, in any agreement. Recently, the Federal Trade Commission (FTC) finalized a nationwide ban on most non-compete clauses in any employment contract (89 FR 38342). The FTC noted that non-compete clauses have many deleterious effects, including on earnings, job creation, innovation, consumer prices, and new business formation (80 FR 38343). Although the FTC's rule would not cover the types of restrictions that are covered by our proposal, we believe such clauses have the same effects on health information technology by restricting the ability of developers to work on different software and to enter into new contracts at the same time that they are contracted to work with an actor's software. Although the contractual language at issue may occasionally be couched in language claiming to protect intellectual property, the clauses function as anti-competitive clauses and not as clauses protecting intellectual property from infringement or misappropriation. We note that in some cases, there are applicable laws that prevent employees and contractors from misusing intellectual property. Our proposal would not impact legally permissible intellectual property protections. In addition, we note that the Licensing Exception in Sec. 171.303 acknowledges intellectual property rights, including the administration of a reasonable non-disclosure agreement that is no broader than necessary to prevent unauthorized disclosure of the actor's trade secrets. We solicit comment on all aspects of our proposed description of the interference in Sec. 171.104(a)(6). We specifically ask if we should add ``including health IT for a competitor or potential competitor'' at the end of the paragraph. We solicit comment on whether it is necessary to say ``access, exchange, or use'' or if ``access or use'' of EHI is sufficient. We specifically used the term ``agreement'' instead of ``contract'' because we recognize that such clauses can also be found in licensing agreements and other agreements that are not typically referred to as a contract. We also ask, more broadly, whether there are other types of agreements that should specifically be identified in the text of Sec. 171.104(a)(6), such as those specified in the Cures Act rulemaking (84 FR 7518 and 88 FR 25811). Because we recognize that sometimes the actor induces a contractor to include the language in the agreement the contractor has with its employees, we use the phrase ``negotiating or enforcing'' to ensure that an actor inducing or forcing a customer, business associate, or any other entity to include such restrictions would also be considered an interference. We ask commenters to opine on whether ``negotiating or enforcing'' is broad enough to cover the situations intended to be covered by the description in Sec. 171.104(a)(6), and whether any terms should be added to the definitions section of the regulation as a result of this or other descriptions of interferences in Sec. 171.104. We also solicit comments on the rest of the descriptions of interferences in the proposed Sec. 171.104. Are the descriptions clear enough for regulated entities and those whose access, exchange, or use of EHI that might be adversely affected by the conduct to understand the intended policy? Are there other practices that interested parties believe should be explicitly identified in regulatory text as constituting interference? Would codification of more or fewer interferences be more helpful? In considering these questions, we remind readers that ``interference'' or ``interfere with'' includes practices that prevent, materially discourage, or otherwise inhibit the access, exchange, and use of EHI. Finally, we reiterate and emphasize that the descriptions in the proposed Sec. 171.104 are of conduct constituting ``interference.'' The facts and circumstances of an actor's engaging in any of these practices, or any other practice likely to interfere with access, exchange, or use of EHI, would determine whether the practice constitutes ``information blocking.'' OIG has the statutory authority to investigate allegations of information blocking and to determine whether information blocking has occurred. a. Application of ``Interference'' to TEFCA\TM\ Requirements Having discussed practices that would be considered interferences, we want to take this opportunity to identify certain practices that we believe would be unlikely to interfere with the access, exchange, and use of EHI under the information blocking definition. Specifically, it would be unlikely to be an interference for Qualified Health Information Networks\TM\ (QHINs), Participants, or Subparticipants to comply with required provisions of the Common Agreement and the incorporated terms of participation and standard operating procedures, respectively. In the ONC Cures Act Final Rule, we took a similar approach and identified certain practices that we believed would be unlikely to interfere with the access, exchange, and use of EHI. Specifically, we explained that an actor's practice that focused on educating individuals about the privacy and security risks posed by certain applications would be unlikely to rise to the level of an interference when certain conditions were met, and therefore would be unlikely to meet the definition of information blocking (85 FR 25815). Many interested parties, directly and through responses to proposed rules and requests for information, have inquired about the implications of following requirements of the Trusted Exchange Framework and Common Agreement\TM\ (TEFCA\TM\), including the related terms of participation and standard operating procedures, with respect to the information blocking definition. In light of the concerns and questions that interested parties have brought to our attention with respect to TEFCA, we believe it is important to provide [[Page 63620]] guidance to actors who are QHINS\TM\, Participants, or Subparticipants that practices they must undertake to comply with TEFCA requirements would be unlikely to rise to the level of an interference under the information blocking definition. We believe providing such guidance with respect to TEFCA requirements is important because when actors choose to access, exchange, and use EHI through TEFCA, their compliance with TEFCA requirements supports the policy goals of the Cures Act and information blocking regulations more broadly, such as to promote confidence in health IT infrastructure and interoperability (see 85 FR 25649, 25794, 25804, 25805, and 25806) by advancing interoperability and expanding secure access, exchange, and use of EHI. We also believe that because the proposed Sec. 171.104 does not describe the full universe of practices that could constitute an interference, it is important to clarify that compliance with TEFCA requirements, in the context of TEFCA participation by a QHIN, Participant, or Subparticipant, is unlikely to constitute an interference under the information blocking definition. Actors who are QHINs, Participants, or Subparticipants have documents relevant to their participation in TEFCA, including documents such as the Common Agreement, terms of participation, and standard operating procedures. These documents may for example, establish certain standards to ensure the security of EHI, or on the manner of exchange of EHI. In certain cases, QHINs, Participants, or Subparticipants may engage in practices not specifically required by the Common Agreement, terms of participation, and standard operating procedures. Our guidance does not extend to such permissible or optional practices. To this point, not complying with a request for access, exchange, or use of 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), could be an interference, could implicate the information blocking definition, and would not be covered by the TEFCA Manner Exception (Sec. 171.403). Further, in general and for clarity, any practice (act or omission) between TEFCA entities that is not one specifically required by the Common Agreement, including its terms of participation and standard operating procedures, as well as any practice involving or affecting non-participants in TEFCA could also be an interference. For practices that are not required under TEFCA and/or that affect non-participants in TEFCA, which could constitute an interference, all of the other voluntary exceptions in part 171 would be available, as appropriate. We seek comments on our discussion. Does this discussion sufficiently reassure actors interested in participating in TEFCA that complying with the requirements of TEFCA as a QHIN, Participant, or Subparticipant would be unlikely to constitute ``interference'' under the information blocking definition? We also welcome comment on the desirability of further Federal guidance or education materials on the interaction between the information blocking regulations and the Common Agreement, including terms of participation and standard operating procedures.

1. Privacy Exception

a. Privacy Exception--Definition of Individual For purposes of the Privacy Exception, the term ``individual'' is defined in Sec. 171.202(a)(2). When the Privacy Exception in Sec. 171.202 and paragraph (a)(2) were initially established by the ONC Cures Act Final Rule, the codified text included a typographical error that was not identified until after publication. In the ONC Cures Act Final Rule (at 85 FR 25957) and the current Code of Federal Regulations, the text of Sec. 171.202(a)(2)(iii), (iv), and (v) cross- references paragraphs (a)(1) and (2) of Sec. 171.202 instead of paragraphs (a)(2)(i) and (ii) when referencing a person who is the subject of EHI in defining the term ``individual.'' We now propose to make a technical correction to cross-references within the text of Sec. 171.202(a)(2)(iii), (iv), and (v) to accurately cross-reference paragraph (a)(2)(i), (a)(2)(ii), or both, as applicable. Paragraph (a)(2) of the current Sec. 171.202 defines the term ``individual'' in part by referring to its definition in 45 CFR 160.103. In Sec. 171.202(a)(2)(i), we cross-reference to the definition of ``individual'' as defined in the HIPAA Privacy Rule at 45 CFR 160.103. In (a)(2)(ii), we provide a second definition: ``any other natural person who is the subject of the electronic health information being accessed, exchanged, or used.'' \233\ Then, in (a)(2)(iii), (iv), and (v), we expand on those two definitions in order to include persons legally acting on behalf of such individuals or their estates in certain circumstances. However, the current text of Sec. 171.202(a)(2)(iii), (iv), and (v) incorrectly references a ``person described in paragraph (a)(1) or (2) of this section'' instead of referencing a ``person described in paragraph (a)(2)(i) or (ii) of this section.'' --------------------------------------------------------------------------- \233\ The definition of ``person'' for purposes of 45 CFR part 171 is codified in Sec. 171.102 and is, by cross-reference to 45 CFR 160.103, the same definition used for purposes of the HIPAA Privacy Rule (45 CFR part 160 and subpart E of 45 CFR part 164). The Sec. 160.103 definition of ``person'' clarifies the meaning of ``natural person'' within it. We use ``natural person'' with that same meaning in Sec. 171.202(a)(2) and throughout this discussion of Sec. 171.202(a)(2). --------------------------------------------------------------------------- The ONC Cures Act Final Rule preamble demonstrates our intent for the definition of ``individual'' in paragraph (a)(2) of Sec. 171.202. Citing the ONC Cures Act Proposed Rule at 84 FR 7526, we stated in the ONC Cures Act Final Rule preamble (85 FR 25846 through 25847) that ``the term `individual' encompassed any or all of the following: (1) An individual defined by 45 CFR 160.103; (2) any other natural person who is the subject of EHI that is being accessed, exchanged or used; (3) a person who legally acts on behalf of a person described in (1) or (2), including as a personal representative, in accordance with 45 CFR 164.502(g); or (4) a person who is a legal representative of and can make health care decisions on behalf of any person described in (1) or (2); or (5) an executor or administrator or other person having authority to act on behalf of the deceased person described in (1) or (2) or the individual's estate under State or other law.'' Further, still referencing the ONC Cures Act Proposed Rule preamble, we wrote at 85 FR 25845 that ``(3) encompasses a person with legal authority to act on behalf of the individual, which includes a person who is a personal representative as defined under the HIPAA Privacy Rule.'' The paragraph designated as ``(a)(3)'' in the Proposed Rule at 84 FR 7602 and referenced simply as ``(3)'' in the discussion at 85 FR 25845 was designated as (a)(2)(iii) in Sec. 171.202 as finalized at 85 FR 25957 and currently codified. The quotes from the ONC Cures Act Final Rule preamble above demonstrate a consistent intention across the ONC Cures Act Proposed and Final Rules to cross-reference in the paragraphs finalized (at 85 FR 25957) and codified in Sec. 171.202 as (a)(2)(iii), (iv), and (v) the paragraphs finalized and codified in Sec. 171.202(a)(2)(i) and (ii). Accordingly, we propose the technical correction in the revised text of 45 CFR 171.202 to reflect the correct reading and intent. In drafting our proposed technical correction to Sec. 171.202(a)(2), we determined that the cross-reference to (a)(2)(ii), a natural person who is the subject of the EHI being exchanged other than an individual as defined in [[Page 63621]] 45 CFR 160.103, is not needed in describing (in (a)(2)(iii)) a person acting as a personal representative in making decisions related to health care specifically in accordance with 45 CFR 164.502(g). This is because 45 CFR 164.502(g) pertains personal representatives of individuals as defined in 45 CFR 160.103 (persons who are the subject of PHI) under the HIPAA Privacy Rule. A person described in (a)(2)(i) is an individual as defined in 45 CFR 170.103 for purposes of the HIPAA Privacy Rule. However, (a)(2)(ii) describes ``any other natural person who is the subject of the EHI being accessed, exchanged, or used'' (emphasis added) rather than an ``individual'' who is the subject of PHI under the HIPAA Privacy Rule. Such other person (described in (a)(2)(ii)) would not have a person who is a ``personal representative'' specifically in accordance with the 45 CFR 164.502(g) provisions pertaining to ``personal representatives'' under the HIPAA Privacy Rule. Therefore, we propose to strike the unnecessary reference to Sec. 171.202(a)(2)(ii) (a subject of EHI who does not meet the 45 CFR 160.103 (HIPAA Privacy Rule) definition of ``individual'') from the Sec. 171.202(a)(2)(iii) description of a person who acts as a personal representative specifically in accordance with the HIPAA Privacy Rule provisions in 45 CFR 164.502(g). By striking an unnecessary cross- reference, this proposal would simplify the regulatory text without changing what the Sec. 171.202(a)(2) definition of ``individual'' means or how it applies in practice. b. Privacy Sub-Exception--Interfering With Individual Access Based on Unreviewable Grounds In the ONC Cures Act Final Rule (85 FR 25856), we finalized in Sec. 171.202(d) a sub-exception to the Privacy exception applicable to the denial of an individual's request for electronic health information consistent with ``unreviewable grounds'' for denial of access under 45 CFR 164.524. As we explained in the ONC Cures Act Final Rule, these ``unreviewable grounds'' are related to specific privacy risks or interests and have been established for important public policy purposes, such as when a health care provider is providing treatment in the course of medical research or when a health care provider is acting under the direction of a correctional institution (85 FR 25856). (See 45 CFR 164.524(a)(2) for the full listing of circumstances in which individual may be denied access under 45 CFR 164.524 without the individual being provided an opportunity for review of the denial.) The current text of Sec. 171.202(d) is explicitly applicable when an individual requests EHI under the HIPAA individual right of access standard (45 CFR 164.524(a)(1)) from an actor who must comply with this HIPAA Privacy Rule provision. Thus, the sub-exception is available only to actors who are also HIPAA covered entities or business associates.\234\ --------------------------------------------------------------------------- \234\ See the definitions of ``covered entity'' and ``business associate'' at 45 CFR 160.103. --------------------------------------------------------------------------- We explained how the sub-exception currently operates in the ONC Cures Act Final Rule preamble (see 85 FR 25856 through 25857). The current text of Sec. 171.202(d) states that the actor's practice ``must be consistent with 45 CFR 164.524(a)(2).'' The preamble discussion of this sub-exception explains that an actor who chooses to deny the request must, to satisfy the Sec. 171.202(d) sub-exception, meet the actor's obligations \235\ under the HIPAA Privacy Rule. Thus, if an actor who also must comply with 45 CFR 164.524(a)(1) denies, on unreviewable grounds, access to some or all of the protected health information (PHI) that is also EHI \236\ requested by the individual in compliance with the HIPAA Privacy Rule requirements, the denial is covered under the Sec. 171.202(d) sub-exception as currently codified. --------------------------------------------------------------------------- \235\ At 85 FR 25856, we referred to the actor's HIPAA Privacy Rule compliance obligations in this situation as ``its requirements.'' We use more precise wording here for clarity. \236\ As defined in Sec. 171.102 and excluding certain information as specified in subparagraphs (1) and (2) of this definition, EHI is electronic protected health information (ePHI) (defined in 45 CFR 160.103) that is or would be in the designated record set (defined in 45 CFR 164.501). It may be helpful for purposes of this discussion to think of EHI as a subset of PHI. The HIPAA right of access standard (45 CFR 164.524) applies to PHI that is not ePHI (e.g., paper records), but Sec. 171.202 would be moot with respect to PHI that is not ePHI and therefore does not meet the EHI definition in Sec. 171.102. --------------------------------------------------------------------------- We propose to broaden the applicability of the sub-exception so that it is available to any actor responding to a request for EHI where the circumstances set out in 45 CFR 164.524(a)(2)(i) through (v) apply, and not just for actors who are also HIPAA covered entities or business associates. Allowing the same information blocking sub-exception to cover a practice regardless of whether the actor engaging in the practice is also required to comply with the HIPAA Privacy Rule does not create a misalignment for actors who are subject to both the information blocking regulations and the HIPAA Privacy Rule. Instead, making this sub-exception available to all actors under the same conditions in which the sub-exception is available to HIPAA covered entities should reduce unnecessary variation across actors, improve compliance efficiency, and provide additional certainty as it relates to the applicability of this exception. We believe that broadening the applicability of the unreviewable grounds sub-exception (Sec. 171.202(d)) to practices by actors who are not required to comply with the HIPAA Privacy Rules will provide greater benefit to actors than creating unique requirements for the application of Sec. 171.202(d) to such actors' practices in the circumstances set forth in Sec. 164.524(a)(2). Actors who are not required to comply with the HIPAA Privacy Rule would need to familiarize themselves with up-to-date 45 CFR 164.524 implementation specifications that would apply to the actor's denial of access to the EHI in question in the circumstances set forth in Sec. 164.524(a)(2) if the actor were a HIPAA covered entity or business associate. This is similar to such actors needing to familiarize themselves with the HIPAA Privacy Rule definitions for ``ePHI'' and ``designated record set'' (in Sec. Sec. 160.103 and 164.501) for purposes of understanding the EHI definition in Sec. 171.102. Actors who are not HIPAA covered entities or business associates and who want to obtain help in learning about denials of individual access in the circumstances specified in Sec. 164.524(a)(2) could find a variety of educational sources to choose from. However, most health care providers, HIN/HIEs, health information management professionals, and health IT developers of certified health IT throughout the United States have experience complying with the HIPAA Privacy Rule. To clearly establish coverage of the Sec. 171.202(d) sub-exception for all actors' practices under the same requirements, we propose to change the name of the sub-exception to: ``interfering with individual access based on unreviewable grounds.'' This proposed change to the header text is intended to express the expansion of the sub-exceptions' availability to all actors. Additionally, the proposed regulatory text would remove the current text's reference applying the sub-exception only to actors required to comply with the HIPAA right of access standards and only where the individual is making a request ``under the right of access provision under 45 CFR 164.524(a)(1).'' Instead, the proposed text would provide that the sub-exception applies where an individual requests their EHI from any actor in circumstances set [[Page 63622]] forth in 45 CFR 164.524(a)(2). The proposed revision would, further, cross-reference the implementation specifications set out in 45 CFR 164.524 (access of individuals to protected health information) that HIPAA covered entities and business associates must already meet to comply with the HIPAA Privacy Rule when denying individual access on ``unreviewable grounds'' (45 CFR 164.524(a)(2)). We seek comments on this proposal. c. Privacy Sub-Exception--Individual's Request Not To Share EHI We propose to slightly modify the header of Sec. 171.202(e) for ease of reference to ``individual's request not to share EHI.'' More importantly, we propose to revise the sub-exception to remove the existing limitation that applies the exception only to individual- requested restrictions on EHI sharing that are permitted by other applicable law. The proposal would extend the availability of the Sec. 171.202(e) sub-exception to an actor's practice of implementing restrictions the individual has requested on the access, exchange, or use of an individual's EHI even when the actor may have concern that another law or instrument could attempt to compel the actor to fulfill access, exchange, or use of EHI contrary to the individual's expressed wishes. The existing text and scope of 45 CFR 171.202(e) was established in 2020 by the ONC Cures Act Final Rule (85 FR 25642). When the sub- exception was finalized, health care providers and other actors did not raise explicit concerns regarding when they must comply with statutes, regulations, or instruments (such as subpoenas) issued under the laws of states in which they are not licensed, do not reside, and do not furnish care. In 2022, the Supreme Court decision in Dobbs v. Jackson Women's Health Organization overturned precedent that protected a constitutional right to abortion and altered the legal and health care landscape.\237\ Since the Court's decision, across the United States, a variety of states have newly enacted or are newly enforcing restrictions on access to reproductive health care. The Court's ruling--and subsequent state restrictions--have had far-reaching implications for health care beyond the effects on access to abortion.\238\ --------------------------------------------------------------------------- \237\ See 142 S. Ct. 2228. \238\ See Melissa Suran, ``Treating Cancer in Pregnant Patients After Roe v Wade Overturned,'' JAMA (Sept. 29, 2022), (available at https://jamanetwork.com/journals/jama/fullarticle/ 2797062#:~:text=The%20US%20Supreme%20Court,before%20cancer%20treatmen t%20can%20begin), and Rita Rubin, ``How Abortion Bans Could Affect Care for Miscarriage and Infertility,'' JAMA (June 28, 2022), (available at https://jamanetwork-com.hhsnih.idm.oclc.org/journals/jama/fullarticle/2793921?resultClick=1). (URLs retrieved May 23, 2024.) --------------------------------------------------------------------------- In light of the changing landscape, we are concerned that actors might deny or terminate an individual's requested restrictions on sharing their EHI specifically due to uncertainty about whether the actor is aware of and can account for any and all laws that might override the individual's requested restrictions. An actor who might otherwise be inclined to agree to an individual's request not to share their EHI could be concerned about potential information blocking implications of honoring those individual requests in the face of demands for disclosure that might ultimately be enforced in a court of competent jurisdiction. In particular, we are concerned that actors may be unwilling to consider granting individuals' requests for restrictions, or may prematurely terminate some or all requested restrictions, based on uncertainty as to whether information blocking penalties or disincentives might be imposed in addition to costs the actor may incur to confirm whether the actor is, by other authority, compelled to provide access, exchange, or use of EHI despite the individual's wishes. For example, we understand actors are concerned about potentially implicating the information blocking definition by delaying a disclosure of EHI pursuant to a court order that the actor is aware is being contested, so that the actor can wait to see if the order will, in fact, compel the actor to make EHI available for access, exchange, or use contrary to the individual's request for restrictions to which the actor had agreed consistent with Sec. 171.202(e). Accordingly, the removal of ``unless otherwise required by law'' from Sec. 171.202(e) would be a useful complement to the existing Precondition Not Satisfied sub-exception (Sec. 171.202(b)) to help address actors' uncertainty about various state laws' applicability as they relate to information blocking. As currently codified, Sec. 171.202(b) sub-exception of the Privacy Exception outlines a framework for actors to follow so that the actors' practices of not fulfilling requests to access, exchange, or use EHI would not constitute information blocking when one or more preconditions has not been satisfied for the access, exchange, or use to be permitted under applicable Federal and State, or Tribal laws. To be clear, the proposed revision to Sec. 171.202(e) would not operate to override other law compelling disclosure against the individual's wishes. It would, however, offer actors who elect to honor individual requested restrictions certainty that applying those restrictions will not be considered information blocking so long as the actor's practices in doing so satisfy the requirements of the Sec. 171.202(e) sub-exception. Whether the courts will or should apply any particular Federal, state, or Tribal law to any actor (or enforce orders issued under such laws to any actor in any particular circumstances) is beyond the scope of this proposal. If or where there may be a law that is enforced by a court with jurisdiction over the actor and subject matter and that requires a particular actor to fulfill access, exchange, or use of EHI without the individual's authorization, permission, or consent, the actor might be compelled to comply with that law independent of the information blocking statute and 45 CFR part 171. This would continue to be the case even if we were to finalize the proposed revision to Sec. 171.202(e). We also remind HIPAA covered entities and business associates that they must comply with the HIPAA Privacy Rule, including privacy protections in the HIPAA Privacy Rule to Support Reproductive Health Care Privacy Final Rule and any other applicable Federal laws that limit access, exchange, or use of EHI in particular circumstances. For example, an actor's practice likely to interfere with an individual's access, exchange, or use of EHI (as defined in 45 CFR 171.102) might satisfy an information blocking exception without fully satisfying the actor's separate obligations under 45 CFR 164.524 (HIPAA Privacy Rule's individual right of access). In such cases, an actor that is a HIPAA covered entity or business associate would be subject to penalties for violating the HIPAA Privacy Rule. We welcome comments on this proposal.

2. Infeasibility Exception

In the ONC Cures Act Final Rule, ONC established the Infeasibility Exception (Sec. 171.204) (85 FR 25865 through 25870, and 85 FR 25958). Under the Infeasibility Exception, it is not considered information blocking if an actor, as defined in Sec. 171.102, does not fulfill a request to access, exchange, or use EHI due to the infeasibility of the request, provided the actor satisfies at least two conditions: the Sec. 171.204(b) responding to requests condition and [[Page 63623]] any one of the conditions in Sec. 171.204(a). In the HTI-1 Final Rule (89 FR 1436, see preamble at 89 FR 1373 through 1387), we finalized the following revisions to Sec. 171.204: clarification of the Sec. 171.204(a)(1) uncontrollable events condition requirement that the uncontrollable event must have an actual negative impact on an actor's ability to fulfill EHI access, exchange, or use in order for uncontrollable events condition to apply; addition of two new conditions (third party seeking modification use and manner exception exhausted, respectively subparagraphs (3) and (4)) under paragraph (a); and renumbering the infeasible under the circumstances condition from Sec. 171.204(a)(3) to Sec. 171.204(a)(5). However, in the HTI-1 rulemaking, we did not change the substance of the infeasible under the circumstances condition (now codified in Sec. 171.204(a)(5)) or the Sec. 171.204(a)(2) segmentation condition, and we did not make any changes to Sec. 171.204(b). In this rule, we propose to modify: the Sec. 171.204(a)(2) segmentation condition as described in section IV.B.2.a; the Sec. 171.204(a)(3) third party seeking modification use conditions as described in section IV.B.2.b; and the Sec. 171.204(b) responding to requests condition as discussed in section IV.B.2.c (of this proposed rule). a. Segmentation Condition Modifications The Sec. 171.204(a)(2) segmentation condition currently applies where the actor is not able to fulfill a request for access, exchange, or use of EHI specifically because the actor cannot unambiguously segment from other requested EHI the EHI that cannot be made available by law or due to an individual's preference, or that may be withheld in accordance with Sec. 171.201. In practice, ``by law or due to an individual's preference'' would include situations where: an actor has chosen to honor an individual's request for restrictions on sharing of some of their EHI; an individual's authorization or consent is a pre- requisite for a particular use or disclosure of their EHI to be lawful and the individual has not provided such authorization or consent; or law applicable in the circumstances of the request restricts sharing of the EHI. We propose updates to the segmentation condition to enhance clarity and certainty, and to provide for its application to additional situations. We propose to update how the regulation text describes why certain EHI cannot or will not be made available, including more specific cross-references to relevant provisions within 45 CFR part 171. Currently, the segmentation condition references (in subparagraph (i) of Sec. 171.204(a)(2)) EHI that cannot be made available due to an individual's preference or by law, and (in subparagraph (ii) of Sec. 171.204(a)(2)) EHI that the actor may choose to withhold in accordance with the Preventing Harm Exception. We propose to revise the condition (Sec. 171.204(a)(2)) as follows: to focus subparagraph (i) on EHI that is not permitted by applicable law to be made available, and to explicitly cross-reference in subparagraph (ii) the proposed Protecting Care Access Exception (Sec. 171.206) and the existing Privacy Exception (Sec. 171.202) in addition to the existing Preventing Harm Exception (Sec. 171.201) (which currently has an explicit cross- reference). We believe that focusing Sec. 171.204(a)(2)(i) solely on EHI that is not permitted by applicable law to be made available for a requested access, exchange, or use will reinforce for actors and other interested persons that actors cannot make EHI available when applicable law, such as the HIPAA Privacy Rule or 42 CFR part 2, does not permit covered information to be made available. Under our proposed revision of Sec. 171.204(a)(2)(i), the segmentation condition would continue to apply as it does today when an actor cannot unambiguously segment EHI that, under applicable law, is permitted to be available to a particular person for a particular purpose from EHI that is not permitted to be available to that person for that purpose. This would include situations where the actor cannot unambiguously segment EHI for which preconditions for permitting use or disclosure under the HIPAA Privacy Rule (or other applicable law) have not been met from EHI for which such preconditions have been met, as well as scenarios where use or disclosure of specific EHI for a particular purpose is prohibited by applicable law. The proposed revision to Sec. 171.204(a)(2) would retain in subparagraph (ii) explicit reference to the Preventing Harm Exception (Sec. 171.201). Thus, the Infeasibility Exception's revised segmentation condition would continue to apply where the actor cannot unambiguously segment other EHI from EHI that the actor has chosen to withhold in accordance with the Preventing Harm Exception (Sec. 171.201). We propose to explicitly add reference to Sec. 171.202 in our revision to subparagraph (ii) of Sec. 171.204(a)(2). This would ensure that the segmentation condition would continue to apply where the actor cannot unambiguously segment other EHI they could lawfully make available from EHI for which the actor has chosen to honor the individual's request not to share the EHI (consistent with Sec. 171.202(e) sub-exception). In addition, citing Sec. 171.202 in the proposed revision to subparagraph (ii) of Sec. 171.204(a)(2) would expand explicit application of the Sec. 171.204(a)(2) segmentation condition to certain situations where an actor subject to multiple laws with inconsistent preconditions adopts uniform privacy policies and procedures to adopt the more restrictive preconditions (as provided for under the Privacy sub-exception Precondition Not Satisfied, see Sec. 171.202(b)(3) as currently codified). By referencing all of the Privacy Exception (Sec. 171.202), the proposed revised Sec. 171.204(a)(2)(ii) would allow the Infeasibility Exception's segmentation condition to apply where an actor (who has adopted the more restrictive of multiple laws' preconditions for sharing of some information about an individual's health or care consistent with Sec. 171.202(b)) cannot unambiguously segment EHI for which a more restrictive precondition has not been met from other EHI that the actor could lawfully share in the jurisdictions with less restrictive preconditions. By referencing all of the Privacy Exception (Sec. 171.202), the proposed revision would also extend the segmentation condition's coverage to situations where the actor is unable to unambiguously segment EHI that could be made available from specific EHI that the actor may choose to withhold from the individual or their (personal or legal) representative consistent with the Sec. 171.202(d) Privacy sub- exception ``denial of individual access based on unreviewable grounds.'' We have identified a possibility that individuals and interested parties could be concerned that extending the segmentation condition's coverage could affect the speed with which actors move to adopt or improve segmentation capabilities. Segmentation capabilities may need to be improved to sequester the EHI that may be withheld from an individual on certain unreviewable grounds from other EHI an actor may have for that individual. For instance, in comparison to health information that may need to be sequestered for other reasons, different or additional segmentation functionality may be [[Page 63624]] needed to sequester from other EHI only that information created or obtained in the course of research that includes treatment and only for as long as the research is in progress.\239\ While the actor that is a HIPAA covered entity would still need to satisfy the individual's right of access to other PHI to the extent possible (see 45 CFR 164.524(d)(1)), the form and format in which the PHI is readily producible (see 45 CFR 164.524(c)(2)) may not be supported by the same electronic manner of access, exchange, or use that the individual would prefer. Therefore, we invite commenters to share any concerns or other perspectives they may wish to share relevant to this issue. We also propose in the alternative to reference only Privacy Exception sub- exceptions other than denial of access based on unreviewable grounds (Sec. 171.202(d)) in the revised Sec. 171.204(a)(2) segmentation condition. Including this alternative proposal in this proposed rule means we could decide to finalize the revision to the Sec. 171.204(a)(2) segmentation condition with or without cross-reference to (or that would include) ``denial of access based on unreviewable grounds'' (Sec. 171.202(d)). --------------------------------------------------------------------------- \239\ Please see 45 CFR 164.524(a)(2)(iii) for the HIPAA Privacy Rule's full ``unreviewable grounds for denial'' circumstances to which this example alludes. --------------------------------------------------------------------------- For an actor's practice to be consistent with the Sec. 171.202 Privacy Exception, the practice must meet the requirements set forth in any one of the sub-exceptions enumerated in Sec. 171.202 (b) through (e). Referencing the entirety of Sec. 171.202 in Sec. 171.204(a)(2)(ii) would, therefore, also extend application of the Infeasibility Exception's segmentation condition to situations where a health IT developer of certified health IT that is not required to comply with the HIPAA Privacy Rule may withhold EHI they could otherwise lawfully make available based on an organizational privacy policy consistent with the Sec. 171.202(c) sub-exception. (As used in Sec. 171.202, ``HIPAA Privacy Rule'' means 45 CFR parts 160 and 164 (Sec. 171.202(a)(1).) Because the Sec. 171.202(c) sub-exception is applicable only where a health IT developer of certified health IT is not required to comply with the HIPAA Privacy Rule, it would apply in situations where the health IT developer of certified health IT is not required to comply with the individual right of access in 45 CFR 164.524. We believe it is possible that some individuals might seek health care or other services from such developers' customers (including health care providers) who are not HIPAA covered entities. In such situations, a State, or Tribal law may operate to provide the individual rights to access their health information that the actor has. (Determining what other laws may operate, or how, in specific circumstances is beyond the scope of this proposed rule.) Although the number of such situations may be relatively small, we do recognize it is possible for some individuals to find themselves in situations where no other law explicitly guarantees them a right to access EHI of which the individual is the subject (or the legal representative of the subject). In such situations, the individual may rely solely on the information blocking statute to ensure actors will not unreasonably and unnecessarily interfere with the individual's EHI access, exchange, or use. We are, therefore, interested in whether commenters may be concerned about potential unintended consequences of extending the (Sec. 171.204(a)(2)) segmentation condition to situations where a health IT developer is not required to comply with HIPAA and cannot segment EHI they have chosen to withhold consistent with the actor's own organizational privacy policies from other EHI. Would extending the segmentation condition to situations where a health IT developer has chosen to withhold EHI consistent with the Privacy sub-exception ``health IT developer of certified health IT not covered by HIPAA'' (Sec. 171.202(c)) pose too much risk of such developers avoiding individuals' EHI requests by choosing not to develop segmentation capabilities in the health IT they provide their customers who are not HIPAA covered entities? We welcome commenters' thoughts on this question. We also propose in the alternative to reference in the revised Sec. 171.204(a)(2)(ii) segmentation condition only Privacy Exception sub-exceptions other than Sec. 171.202(c) ``health IT developer of certified health IT not covered by HIPAA'' sub-exception. Including this alternative proposal in this proposed rule means we could decide to finalize the revision to the Sec. 171.204(a)(2)(ii) segmentation condition with or without cross-reference to (or that would include) Sec. 171.202(c) ``health IT developer of certified health IT not covered by HIPAA.'' As discussed in section IV.B.3 of this preamble, the Sec. 171.206 Protecting Care Access Exception would apply to practices that an actor chooses to implement that are likely to interfere with access, exchange, or use of specific EHI (including, but not limited to, withholding such EHI) when relevant conditions are met. We propose to reference Sec. 171.206 in the proposed revised Sec. 171.204(a)(2)(ii) because the proposed Sec. 171.206(a) threshold condition's requirements include (among others) a requirement that the actor's practice be no broader than necessary to reduce the risk of potential exposure of any person(s) to legal action that the actor believes could arise from the particular access, exchange, or use of the specific EHI. The actor's lack of technical capability to sequester only the EHI for which relevant conditions of Sec. 171.206 have been satisfied would not render Sec. 171.206 applicable to interference with the lawful access, exchange, or use of other EHI pertaining to the same individual(s). Therefore, the proposed reference to Sec. 171.206 in the proposed revised Sec. 171.204(a)(2)(ii) would accommodate circumstances where an actor lacks the technical capability to unambiguously segment the EHI the actor has chosen to withhold consistent with the Protecting Care Access Exception (Sec. 171.206, if finalized) from other EHI that they could lawfully make available. The requirements for an actor's practice to satisfy the proposed new Sec. 171.206 exception, including the Sec. 171.206(a) threshold condition that would be relevant to any practice to which Sec. 171.206 could apply as well as when the Sec. 171.206(b) patient protection or Sec. 171.206(c) care access conditions are relevant, are discussed in detail in section IV.B.3, below in this preamble. We solicit comments on these proposals. b. Third Party Seeking Modification Use Condition Modifications In the HTI-1 Final Rule (89 FR 1436) we excluded from applicability of the third party seeking modification use condition of the Infeasibility Exception (Sec. 171.204(a)(3)) a health care provider's requests for modification use from an actor that is its business associate. In the HTI-1 Final Rule, we noted that, for reasons stated in response to comments suggesting the condition's applicability exclusion may not be broad enough and in consideration of all comments on our discrete proposal, we did not expand the finalized exclusion from applicability of the condition as some commenters had requested (89 FR 1379). We also noted that we may consider amending the third party seeking modification use condition in the future if doing so may be appropriate (89 FR 1379). Upon further consideration, we now propose in Sec. 171.204(a)(3)(ii) to extend the [[Page 63625]] exclusion from applicability of the condition. We now propose to revise the third party seeking modification use condition to designate the existing exclusion from the applicability of this condition as subparagraph (i) of Sec. 171.204(a)(3), and within it change the words ``health care provider'' to ``covered entity as defined in 45 CFR 160.103.'' We propose this change because the HIPAA Privacy and Security Rules require that all covered entities and their business associates safeguard the privacy, security, and integrity of EHI, not just health care providers. As we noted in the HTI-1 Proposed Rule (88 FR 23866), covered entities and business associates often have a level of trust and contractual protections that reduce certain concerns, such as security and data provenance, that led us to propose the third party seeking modification use condition. In addition, as we noted in the HTI-1 Proposed Rule discussion of the limitation of this condition, covered entities and their business associates (as permitted by their business associate agreements) need to access and modify relevant EHI held by other business associates of those covered entities on a regular basis (88 FR 23866). Therefore, we believe the exclusion from applicability of this condition should encompass requests from all covered entities to their business associates. We also propose to exclude from applicability of the condition requests from any health care provider (as defined in Sec. 171.102), who is not a HIPAA covered entity (as defined in 45 CFR 160.103) but who is requesting modification use from an actor whose activities would make the actor a business associate of that same health care provider if that health care provider were a HIPAA covered entity. Even if a health care provider is not a HIPAA covered entity, a health care provider likely has obligations and responsibilities under State law \240\ and according to accreditation organizations' requirements \241\ and payers' requirements \242\ to keep and maintain medical records. Those responsibilities will likely require a health care provider to be able to regularly access and modify EHI held by entities who perform the functions of a business associate (as defined in 45 CFR 160.103) and would be considered a business associate of the health care provider if the health care provider were a covered entity. Further, it is our expectation that even if a health care provider is not a HIPAA covered entity and, therefore, does not have a HIPAA business associate agreement with an actor who maintains EHI or health IT system(s) or application(s) for the health care provider, the health care provider likely would have a pre-existing relationship with the actor similar to the relationship that a covered entity health care provider would have with their business associate, in terms of the existing level of trust, responsibilities, and obligations to handle EHI safely and securely. The health care provider who is not a HIPAA covered entity may be asking for modification use of EHI from an actor for the same purpose(s) that a health care provider who is a covered entity would be. We, therefore, propose to revise the third party seeking modification use condition by adding subparagraph (ii) of Sec. 171.204(a)(3) that would exclude from applicability of the condition requests from health care providers (as defined in Sec. 171.102) who are not HIPAA covered entities, requesting modification use from actors who would be considered the health care provider's business associate if the health care provider were a covered entity as defined in 45 CFR 160.103. --------------------------------------------------------------------------- \240\ See, e.g., https://www.healthit.gov/sites/default/files/appa7-1.pdf (accessed Feb 26, 2024), and http://www.healthinfolaw.org/comparative-analysis/medical-record-retention-required-health-care-providers-50-state-comparison (accessed Feb 26, 2024). \241\ See, e.g., https://www.jointcommission.org/standards/standard-faqs/home-care/leadership-ld/000001197/ (accessed Feb 26, 2024). \242\ See, e.g., https://www.cms.gov/files/document/mln4840534-medical-record-maintenance-and-access-requirements.pdf (accessed Feb 27, 2024), and https://www.healthdatamanagement.com/articles/how-to-craft-an-effective-record-retention-policy (accessed Feb 28, 2024). --------------------------------------------------------------------------- We welcome comments on these proposals. c. Responding to Requests Condition Modifications The Infeasibility Exception currently includes as paragraph (b) of Sec. 171.204 a responding to requests condition. To satisfy the Infeasibility Exception as a whole, an actor's practice must meet the requirements of the Sec. 171.204(b) responding to requests condition in addition to meeting at least one of the conditions in Sec. 171.204(a). To meet the Sec. 171.204(b) responding to requests condition, if an actor does not fulfill a request for access, exchange, or use of EHI consistent with any of the conditions in paragraph (a) of Sec. 171.204, then the actor must provide, within ten business days of receipt of the request, to the requestor a written reason(s) why the request is infeasible. We propose to modify the Sec. 171.204(b) responding to requests condition by establishing different timeframes for sending written responses to the requestor based on the Sec. 171.204(a) condition under which fulfilling the requested access, exchange, or use of EHI is infeasible. The proposed revision to Sec. 171.204(b) would retain the requirement that actors communicate to requestors ``in writing the reason(s) why the request is infeasible'' that we finalized in the ONC Cures Act Final Rule (85 FR 25958, preamble discussion at 85 FR 25869). Under this proposed revision, the condition would also continue to provide actors wishing to avail themselves of the Infeasibility Exception with discretion to decide the appropriate level of detail to include in their written responses (see 85 FR 25869). In addition, we do not propose to specify the format of the written response or a specific delivery mechanism (such as paper mail versus email). Therefore, the proposed revision would retain the condition's existing flexibility specific to the format of the written response. As is the case under the current text of Sec. 171.204(b), meeting the proposed modified Sec. 171.204(b) would be required in conjunction with meeting a condition in Sec. 171.204(a) in order for an actor's practice to satisfy the Sec. 171.204 Infeasibility Exception. We did not propose to modify the responding to requests condition in the HTI-1 Proposed Rule, but we received comments on the proposed rule indicating that ten business days may not allow actors sufficient time to engage with requestors and fully evaluate all factors relevant to meeting certain conditions in Sec. 171.204(a). We discussed such comments in reference to the manner exception exhausted condition (Sec. 171.204(a)(4)) in the HTI-1 Final Rule preamble (89 FR 1387). We noted in the preamble that we did not propose changes to the ten-day timeframe in the HTI-1 Proposed Rule and did not finalize any changes to paragraph (b) of Sec. 171.204 in the HTI-1 Final Rule, but we stated that we may consider those comments in relation to future regulatory action. The concern that ten business days may not allow actors sufficient time to engage with requestors and fully evaluate all factors relevant to meeting certain conditions in Sec. 171.204(a) has also been raised by various actors in both written informal correspondence and real-time interactions since the publication of the ONC Cures Act Final Rule (85 FR 25642). We have also received inquiries from these same actors as to what constitutes a ``request'' for purposes of the Infeasibility Exception. These inquiries specific to Sec. 171.204(b) have generally centered on how we would [[Page 63626]] determine when the ten-day ``clock'' for providing a written response begins. We believe defining in regulation what constitutes a ``request'' or ``actionable request'' is unnecessary and could have more undesirable effects than desirable effects. We believe it would be difficult to define a single set of characteristics that every person's communication or conduct would need to satisfy before their communication to an actor, or other interaction with an actor or with health IT maintained or deployed by the actor, indicating the person seeks EHI access, exchange, or use would be considered a ``request'' for purposes of the information blocking regulations. Such specifications would increase complexity of the regulations and risk increasing rather than decreasing barriers to requestors' obtaining access, exchange, or use of EHI permitted under applicable law and, where applicable, consistent with patients' expressed individual preferences for privacy-protective restrictions beyond those required by law. In light of both experience over the four years since the ONC Cures Act Final Rule was published and the revisions that were finalized to the Sec. 171.204(a) conditions in the HTI-1 Final Rule (89 FR 1436 through 1437, preamble discussion at 89 FR 1373 through 1387), we believe it remains appropriate to include as a condition of the Infeasibility Exception that the actor provide written responses within timeframes specified by the Sec. 171.204(b) responding to requests condition. However, we have determined that the optimal timeframes to specify in Sec. 171.204 going forward may vary based on the specific condition in Sec. 171.204(a) that is satisfied. We propose to retain, as new subparagraph (1) of Sec. 171.204(b), the current Sec. 171.204(b) requirement for a written response within ten business days of the actor receiving a request where the infeasibility of fulfilling requested access, exchange, or use of EHI satisfies the Sec. 171.204(a)(1) uncontrollable events condition, Sec. 171.204(a)(2) segmentation condition, or the Sec. 171.204(a)(3) third party seeking modification use condition. We believe ten business days should be adequate time for an actor to recognize that a request that the actor has received, and that the actor might otherwise be able to fulfill, is not feasible in specific circumstances where an uncontrollable event has adversely impacted the actor's ability to fulfill the requested access, exchange, or use of EHI. Ten business days should also be sufficient for an actor to recognize that they cannot fulfill a request for EHI access, exchange, or use for reasons consistent with Sec. 171.204(a)(2) segmentation condition or where a third party is seeking modification use in circumstances where Sec. 171.204(a)(3) applies. However, we propose to revise the wording of the requirement from ``receipt of'' to ``the actor receiving'' to address what we believe some actors may experience as uncertainty regarding when one would start counting the ten business days in circumstances where fulfilling a request is infeasible for reasons consistent with Sec. 171.204(a)(1). We recognize that there is significant variation in how people make requests and for what purposes, as well as the manners in which they seek to achieve access, exchange, or use of EHI. We also recognize that mechanisms and workflows for receiving and reviewing requests may vary, even within a single actor's operations, based on characteristics of the request. For example, fulfillment of patient requests for EHI access, exchange, or use that can be received and supported automatically via a cloud-based patient portal unaffected by a particular uncontrollable event would continue to be feasible even while the impact of an uncontrollable event on the actor's systems or operational status has rendered the actor unable to receive other requests from, for example, payers or health care providers. An uncontrollable event's impact on a particular actor's systems or operational status may render it infeasible for the actor to receive some requests until a time when restoration or recovery efforts have progressed far enough that the actor's staff are able to access and use the actor's systems. For example, for some types of request and actor workflows, it may be necessary that: (1) application(s) involved in receiving and responding to requests for EHI access, exchange, and use are operational; and (2) appropriate staff are able to safely and securely log into and use the application(s). Once those two things are true again following an uncontrollable event, we would expect the actor's staff to resume receiving and appropriately dispositioning requests. By revising the wording to focus explicitly on the actor receiving the request, we hope the proposed revised wording will make it easier for actors to consider the distinction between requests that can be received and processed using only automated means and requests that require a human to do something--such as log into a system or obtain and open a piece of paper mail--in order for the actor to, in fact, receive the request. Similarly, we believe revising the wording to focus on the actor receiving the request clarifies when the ten-day clock starts in scenarios where third parties seek modification use. From the point the actor receives the request, we believe ten business days is sufficient time for an actor to both determine and respond in writing to the requestor that the request is infeasible consistent with Sec. 171.204(a)(3). In this proposed rule, we propose to define ``business day'' or ``business days'' in Sec. 170.102 for purposes of the ONC Health IT Certification Program. For preamble discussion of this proposed definition of ``business day'' or ``business days,'' please see section III.D.1 of this proposed rule. We propose to adopt this same definition in Sec. 171.102 for purposes of 45 CFR part 171. This proposal that is specific to the definition of ``business day'' or ``business days'' for purposes of 45 CFR part 171 is aligned with but is independent of the proposal to adopt the proposed definition of ``business day'' or ``business days'' discussed in section III.D.1 of this proposed rule for purposes of 45 CFR part 170. Therefore, commenters should be aware that we could choose to adopt the full proposed definition in Sec. 171.102, instead of a cross-reference to Sec. 170.102, for purposes of 45 CFR part 171 if we do not also adopt the definition for purposes of 45 CFR part 170. We welcome comment on this proposal specific to adoption of the definition (discussed in section III.D.1 and shown in the proposed revisions to Sec. 170.102 in this proposed rule) for purposes of 45 CFR part 171 in general and as it would apply to the responding to requests condition of the Infeasibility Exception (Sec. 171.204(b)). A proposed new subparagraph (2) in the proposed revised Sec. 171.204(b) would apply where fulfilling a request is infeasible under the manner exception exhausted condition (Sec. 171.204(a)(4)) or the infeasible under the circumstances condition (Sec. 171.204(a)(5)). Under this proposal, the ten-day clock would start after the actor determines, without unnecessary delay and based on a reasonable assessment of the facts, that the requested access, exchange, or use of EHI cannot be provided consistent with Sec. 171.301 or that fulfilling the request is infeasible under the circumstances. We expect that any actors who find themselves attempting to fulfill a request consistent with Sec. 171.301 will be aware that the attempt to fulfill the request could instead result in infeasibility consistent with the Sec. 171.204(a)(4) manner exception exhausted condition. Therefore, we [[Page 63627]] expect that any such actor would, in good faith and without unnecessary delay, interact with the requestor to ascertain the scope and requested manner of EHI access, exchange, or use and negotiate any necessary fees and licensing consistent with Sec. 171.301. Similarly, we expect that any actor who embarks on the consideration of factors in paragraph (i) of the infeasible under the circumstances condition (Sec. 171.204(a)(5)) will be aware that their consideration of these factors could lead to either a successful fulfilment of requested access, exchange, or use of EHI or a determination that complying with the request would be infeasible under the circumstances. Therefore, we expect the actor would, in good faith and without unnecessary delay, interact with the requestor to ascertain the scope and requested manner of EHI access, exchange, or use and obtain any additional information needed to support the actor's prompt consideration of the Sec. 171.204(a)(5) factors. We welcome comments on this proposal. We also propose in the alternative to enhance the revisions to Sec. 171.204(b) by adopting either or both of the following requirements specific to the circumstances where Sec. 171.204(b)(2) would be applicable. We propose an additional requirement for a specific maximum timeframe for the Sec. 171.204(b)(2)(i) determination of infeasibility related to Sec. 171.301. Under this additional requirement, the maximum timeframe would be one of the following: three, five, ten, twenty, or thirty business days. We propose an additional requirement that for Sec. 171.204(b)(2) to be met, the determination and communication of infeasibility (for reasons consistent with Sec. 171.204(a)(4) or (5)) would have to be made within the timeframe permitted under 45 CFR 164.524 for providing access to PHI where a request for EHI access, exchange, or use is one that implicates the HIPAA Privacy Rule's provisions for individual access to PHI (45 CFR 164.524) in addition to implicating the information blocking regulations in 45 CFR part 171. We welcome comments on the possible additional requirements proposed above. Please note, if ONC adopts the alternative proposal above that specifically references 45 CFR 164.524 for purposes of Sec. 171.204(b)(2), we intend to apply the timeframes required under that section when a request for individual EHI access, exchange, or use is received by the actor. Thus, under the alternative proposal's requirements that would limit maximum available response time under the responding to requests condition where the request for EHI implicates 45 CFR 164.524(a)(1) the timeframe would be limited to the timeframe required under 45 CFR 164.524. We also highlight for readers' awareness that HHS has proposed to revise 45 CFR 164.524(b)(2) to shorten the timeframes allowed to respond to individual requests for access to PHI (see 86 FR 6459 through 6460 and 86 FR 6535). In the event that changes to the 45 CFR 164.524 timeframes were to be finalized in a future HIPAA rule, the shorter timeframes would (upon becoming effective) apply to the alternative proposed additional requirement for responding to requestors where paragraph (b)(2) of the Infeasibility Exception would apply.

3. Protecting Care Access Exception

a. Background and Purpose As we explained in the ONC Cures Act Final Rule, the information blocking provision in PHSA section 3022 was enacted in response to concerns about practices that ``unreasonably limit the availability and use of electronic health information (EHI) for authorized and permitted purposes'' because such practices ``undermine public and private sector investments in the nation's health IT infrastructure, and frustrate efforts to use modern technologies to improve healthcare quality and efficiency, accelerate research and innovation, and provide greater value and choice to healthcare consumers'' (85 FR 25790). We also noted in the ONC Cures Act Final Rule that research suggests that information blocking practices ``weaken competition among health care providers by limiting patient mobility'' and ``unnecessarily impede the flow of EHI or its use to improve health and the delivery of care'' (85 FR 25791). As required by section 3022(a)(3) of the PHSA, we recognized that certain reasonable and necessary activities that could otherwise meet the definition of information blocking should not be considered information blocking, and therefore, established the initial eight ``exceptions'' to the definition of information blocking (see 45 CFR 171 Subpart B and C; a ninth exception was established by the HTI-1 Final Rule in Subpart D). Each reasonable and necessary activity identified as an exception to the information blocking definition does not constitute information blocking for purposes of section 3022(a)(1) of the PHSA if the conditions of the exception are met (85 FR 25649). Since the first eight regulatory exceptions to the information blocking definition were finalized in 2020 (see ONC Cures Act Final Rule, 85 FR 25642), the legal landscape has changed significantly for many patients seeking, and for health care providers providing, reproductive health care. In the wake of the decision in Dobbs v. Jackson Women's Health Organization, 597 U.S. 215 (2022) decision, some States have newly enacted or are newly enforcing restrictions on access to reproductive health care. Uncertainties and other concerns that people who seek reproductive health care and people who provide or facilitate that care have about the legal landscape in the wake of the Supreme Court's ruling--and subsequent State restrictions on reproductive health care--have had far-reaching implications for health care beyond access to abortion. This changing legal landscape increases the likelihood that a patient's EHI may be disclosed in ways that erode trust in health care providers and the health care system, ultimately chilling an individual's willingness to seek, or other persons' willingness to provide or facilitate, lawful health care as well as individuals' willingness to provide full information to their health care providers. As a practical matter, a person's ability to access care of any kind depends on a variety of factors including whether the care is available. For health care to be available, licensed health care professionals and health care facilities must be willing to provide it--and people other than the licensed health care professionals must be willing to take on various roles essential to delivering care in this modern, technology-enabled environment. Also, patients' access to care may rely in some part on services or supports from other persons, such as a spouse or partner. In the current environment, various jurisdictions might enact legislation or attempt to enforce law that purports to authorize administrative, civil, or criminal legal action against persons who engage in reproductive health care that is required or authorized by Federal law or that is permitted by the law of the jurisdiction where the care is provided. Fear of being investigated or of having to defend themselves against potential legal liability under such laws, even where the health care provider or other person has reasonable confidence the defense will be successful, may impact people's willingness to provide or assist in reproductive health care that is lawful under the circumstances in which such health care is provided. [[Page 63628]] On April 26, 2024, the HHS Office for Civil Rights (OCR) issued the ``HIPAA Privacy Rule to Support Reproductive Health Care Privacy'' final rule (89 FR 32976) (2024 HIPAA Privacy Rule) to adopt a prohibition on the use or disclosure of PHI by an entity regulated under the HIPAA Privacy Rule, in certain circumstances, for the following purposes: To conduct a criminal, civil, or administrative investigation into any person for the mere act of seeking, obtaining, providing, or facilitating lawful reproductive health care. To impose criminal, civil, or administrative liability on any person for the mere act of seeking, obtaining, providing, or facilitating reproductive health care. To identify any person for any purpose described above. As noted in the National Coordinator's ONC Health IT blog post titled ``Supporting Information Privacy for Patients, Now and Always: Four Reminders of How HHS Information Blocking Regulations Recognize Privacy Rules,'' on and after the 2024 HIPAA Privacy Rule's effective date, a HIPAA covered entity's or business associate's practice of refusing to make a use or disclosure of PHI that is prohibited under that rule is excluded from the information blocking definition (45 CFR 171.103) because that refusal is required by law. Therefore, the practice does not need to be covered by any information blocking exception because it is not considered information blocking to begin with. The 2024 HIPAA Privacy Rule also establishes a requirement for HIPAA covered entities and business associates to obtain attestations prior to using or disclosing PHI potentially related to reproductive health care for certain purposes (see 45 CFR 164.509 at 89 FR 33063). The Precondition Not Satisfied (45 CFR 171.202(b)) sub-exception of the information blocking Privacy Exception outlines a framework actors can follow so that the actors' practices of not fulfilling requests to access, exchange, or use EHI would not be considered information blocking when a precondition of applicable law has not been satisfied. By meeting the Precondition Not Satisfied sub-exception's requirements, the actor can have confidence that their practices of not sharing EHI because they have not obtained the required attestation will not be considered information blocking. The 2024 HIPAA Privacy Rule's new protections do not prohibit use or disclosure of PHI for various purposes other than those specified in 45 CFR 164.502(a)(5)(iii), though the protections include additional preconditions or limitations on disclosures for certain purposes (for more information, please see the 2024 HIPAA Privacy Rule (89 FR 32976) and consider visiting the HHS.gov Health Information Privacy section's HIPAA and Reproductive Health page: https://www.hhs.gov/hipaa/for-professionals/special-topics/reproductive-health/index.html). The 2024 HIPAA Privacy Rule does not require a HIPAA covered entity or business associate to obtain the attestations specified in 45 CFR 164.509 before disclosing PHI (including PHI potentially related to reproductive health care) for permissible purposes other than those specified in 45 CFR 164.512(d), (e), (f), or (g)(1). For example, the HIPAA Privacy Rule continues to provide for uses and disclosures of PHI for treatment, payment or health care operations purposes (see 45 CFR 164.506) that do not meet any of the prohibitions set out in 45 CFR 164.524(a)(5)(iii). Thus, an actor choosing to deny requests for access, exchange, or use of EHI for a purpose permitted under HIPAA is not making a denial that is ``required by law'' specifically under HIPAA. As a result, the information blocking definition could be implicated unless another applicable law requires the denial or a regulatory exception applies. Similarly, an actor conditioning fulfilment of such requests on preconditions that an actor chooses to set (such as that the requestor provides an attestation that is not required by any privacy law that applies in the circumstances) could implicate the information blocking definition unless an exception applies to that practice. It may be helpful to pause here for a brief review of how the information blocking regulations, which are based on statutory authority separate from HIPAA, operate (independently of regulations promulgated under HIPAA). This background information may help readers understand how and why an actor may be concerned about potentially implicating the information blocking definition (and penalties or disincentives for information blocking authorized by the information blocking statute) if the actor engages in practices that the HIPAA Privacy Rule would require of a HIPAA covered entity or business associate when the actor is not required to comply with the HIPAA Privacy Rule. First, information blocking regulations apply to health care providers, health IT developers of certified health IT, and health information networks (HIN) and health information exchanges (HIE), as each is defined in 45 CFR 171.102. Any individual or entity that meets one of these definitions is an ``actor'' and subject to the information blocking regulations in 45 CFR part 171, regardless of whether they are also a HIPAA covered entity (CE) or business associate (BA) as those terms are defined in 45 CFR 160.103. Second, for purposes of the information blocking regulations, the definition of ``EHI'' applies to information ``regardless of whether the group of records are used or maintained by or for a covered entity as defined in 45 CFR 160.103'' (Sec. 171.102, emphasis added). Therefore, it is possible for an information blocking actor that is not required to comply with the HIPAA Privacy Rule to have EHI that is not also PHI. It is also possible for an actor (such as a HIN/HIE) to not be a HIPAA covered entity itself and to exchange, maintain, or otherwise handle EHI on behalf of network participants that are not required to comply with the HIPAA Privacy Rule. Where an actor that is not a HIPAA covered entity has EHI that is not maintained on behalf of a HIPAA covered entity, the actor may be concerned about potential information blocking consequences if the actor were to engage in a practice such as denying requests for access, exchange, or use of EHI that indicates or potentially relates to reproductive health care for purposes for which the 2024 HIPAA Privacy Rule would prohibit use or disclosure of PHI or would require an attestation as a precondition for permitting disclosure of PHI. There is a sub-exception within the Privacy Exception currently codified in Sec. 171.202(c) that is available to a health IT developer of certified health IT ``not covered by HIPAA.'' The sub-exception is available ``if the actor is a health IT developer of certified health IT that is not required to comply with the HIPAA Privacy Rule, when engaging in a practice that promotes the privacy interests of an individual'' (Sec. 171.202(c), please see Sec. 171.202(c) for the requirements to meet the exception.) However, this exception represents a departure from our general approach of designing each information blocking exception to be available to all actors (regardless of whether they must comply with the HIPAA Privacy Rule). The Sec. 171.202(c) sub-exception is also not available to actors who meet the Sec. 171.102 definition of ``health care provider'' or ``HIN/HIE'' even if they are not required to comply with the HIPAA Privacy Rule. (We refer actors and other persons interested in learning more about how the information blocking regulations, and particularly the [[Page 63629]] exceptions, work in concert with the HIPAA Rules and other privacy laws to support health information privacy, to the discussion of this topic in the HTI-1 Final Rule at 89 FR 1351 through 1354.) We have come to understand that some health care providers and other actors may have concerns about the risk of potential exposure to legal action flowing from the uses and disclosures of EHI indicating or (in the case of patient health concern(s) or history) potentially relating to reproductive health care that remains permissible under applicable law. For example, the HIPAA Privacy Rule permits a HIPAA covered entity to disclose an individual's PHI to a health care provider who is not a HIPAA covered entity for treatment activities. Once PHI is in the possession, custody, or control of an entity that is not regulated under the HIPAA Privacy Rule, the information is no longer protected by the HIPAA Privacy Rule. Thus, the HIPAA Privacy Rule's strengthened protections for PHI would not preclude a health care provider (or other recipient of PHI for other permissible purposes) who is not a HIPAA covered entity or business associate from further disclosing individually identifiable health information to someone who might then use the information to potentially impose criminal, civil, or administrative liability on any person for the mere act of seeking, obtaining, providing, or facilitating reproductive health care (or any other care) that was lawful under the circumstances in which it was provided. We reiterate that the information blocking statute is separate from the HIPAA statute and that the information blocking regulations operate both separately and differently from the HIPAA regulations. One point of such difference that is key to understanding why we propose a new ``Protecting Care Access Exception'' (Sec. 171.206) is that a HIPAA covered entity or business associate is not required by the HIPAA Privacy Rule to make a use or disclosure that the rule merely permits. (The HIPAA Privacy Rule does require certain uses and disclosures of PHI but merely permit various other uses and disclosures.) Persons subject to the information blocking regulations, however, could implicate the information blocking definition if they ``interfere with'' any access, exchange, or use of EHI except as required by law or covered by an exception. It is the implication of the ``information blocking'' definition (and the potential to incur penalties or disincentives for engaging in information blocking) that would cause an actor to be concerned about, for instance, refusing to disclose EHI indicating reproductive health care for permissible purposes to an entity not required to comply with the HIPAA Privacy Rule and whom the actor has reason to believe does not safeguard the privacy or security of individuals' health information in compliance with the same standards as would be required of a HIPAA covered entity or business associate. In a variety of situations where a patient or an actor may be concerned that an access, exchange, or use of EHI may implicate any person's physical safety interests or the individual's privacy interests, other exceptions (such as the Preventing Harm Exception in Sec. 171.201 or three of the four sub-exceptions of the Privacy Exception in Sec. 171.202) are available to any actor who wants to engage in practices that are likely to interfere with EHI access, exchange, or use consistent with the conditions of the applicable exception. Currently, however, there are no exceptions in 45 CFR part 171 that are designed to accommodate concerns an actor may have about a patient's, health care provider's, or other person's risk of potential exposure to legal action (investigation, action in court, or imposition of liability) that could arise from \243\ the access, exchange, or use for permissible purposes specific EHI (that is, one or more data points)that indicates reproductive health care was sought, obtained, provided, or facilitated. None of the current exceptions are designed to accommodate similar concerns an actor may have about risk of patients' potential exposure to legal action that could arise from the sharing for permissible purposes of EHI that indicates health condition(s) or history for which reproductive health care is often sought, obtained, or medically indicated.\244\ Thus, where preconditions (under the HIPAA Privacy Rule or other applicable law--or both, where applicable) to the provision of access, exchange, or use of EHI have been met, and another exception (such as Privacy (Sec. 171.202) or Preventing Harm (Sec. 171.201)) does not apply, attempts to limit the disclosure of EHI for the purposes addressed in the patient protection or care access condition of the proposed Protecting Care Access Exception (Sec. 171.206(b) or (c)) could currently constitute information blocking. (An actor's practice will only meet the statutory or regulatory definition of information blocking if it meets all of the definition's elements, including the knowledge standard applicable to the actor engaged in the practice.) --------------------------------------------------------------------------- \243\ For purposes of this discussion and of the proposed Protecting Care Access Exception, a risk need not be one that is certain to occur, or that is likely to occur immediately following, an access, exchange, or use of EHI in order to be one that could arise from the access, exchange, or use. \244\ In this preamble, we at some points use for brevity and readability ``potentially related to reproductive health care'' as shorthand for EHI that shows or would carry a substantial risk of supporting an inference that (as described in proposed Sec. 171.206(b)(1)(iii)) the patient has health condition(s) or history for which reproductive health care is often sought, obtained, or medically indicated. --------------------------------------------------------------------------- Even for actors to whom the HIPAA Privacy Rule does not apply, other laws (Federal, State, or Tribal) may apply preconditions that must be satisfied in order for EHI to be shared without violating these laws. For any actor, compliance with such other applicable law does not implicate the information blocking definition, as ONC has discussed in the HTI-1 Final Rule preamble (see 89 FR 1351 through 1354) and in information resources available on ONC's official website (HealthIT.gov). However, where the preconditions under such other applicable law are met, any practice by an actor that is likely to interfere with access, exchange, or use of EHI could implicate the information blocking definition (Sec. 171.103) unless the actor's practice is covered by an exception set forth in 45 CFR part 171. The proposed new Protecting Care Access Exception (Sec. 171.206) would be available to any actor, regardless of whether the actor is also a HIPAA covered entity or business associate. The proposed exception would apply regardless of whether another exception could also apply to an actor's practice(s) in relevant scenarios. Other exceptions would continue to be available in circumstances where the conditions of the Protecting Care Access cannot be met but the other exception(s) can be met. Each information blocking exception and each provision of each exception is designed to stand independent of any and every other exception unless any specific provision of an exception might explicitly reference another exception (even then the dependency is limited to the exact provision or function of such provision that relies upon the cross-reference). Thus, the proposed Protecting Care Access Exception would also operate independently of any provision of any other exception in part 171 and any provision in 45 CFR 171 that does not reference it. It is our intent that if any provision in Sec. 171.206 were, if or when finalized, held to be invalid or unenforceable facially, or as applied to [[Page 63630]] any person, plaintiff, or stayed pending further judicial or agency action, such provision shall be severable from other provisions of Sec. 171.206 that do not rely upon it and from any other provision codified in 45 CFR part 171 that does not explicitly reference Sec. 171.206 even if such provisions were to be established or modified through this same rulemaking action. A patient's ability to access care can be adversely affected when a provider believes they could be exposed to legal action based on the mere fact that care is provided. Given the demonstrated chilling effect of some States' laws on the availability of medically appropriate care, it is reasonable and necessary for actors to mitigate risks of potential exposure of health care professionals and other persons who provide or facilitate, as well as those who seek or obtain, reproductive health care that is lawful under the circumstances in which the care is provided to legal action based on the mere fact that such care was sought, obtained, provided, or facilitated. Thus, a new exception is needed to address actors' concerns about potentially implicating the information blocking definition (Sec. 171.103) if they choose not to share applicable EHI in the circumstances where the Protecting Care Access Exception (Sec. 171.206) would apply. This new proposed exception (Sec. 171.206) is important in order to ensure health care providers do not feel the need to adopt paper or hybrid recordkeeping methods in place of fully electronic, interoperable formats. Thus, we believe it is reasonable and necessary for an actor to restrict access, exchange, or use of specific EHI that indicates or (under Sec. 171.206(b)) is potentially related to reproductive health care so that health care providers continue to use modern, interoperable health IT that better promotes patient safety than would paper or hybrid recordkeeping methods. Restricting EHI sharing under the conditions of the proposed new Protecting Care Access Exception (Sec. 171.206) is also necessary to preserve and promote public trust in health care professionals, health care, and the health information infrastructure. We propose the Protecting Care Access Exception to address actors' concerns about potentially implicating the information blocking definition if they choose not to share EHI in an EHI sharing scenario that an actor believes in good faith could risk exposing a patient, provider, or facilitator of lawful reproductive health care to potential legal action based on what care was sought, obtained, provided, facilitated, or (specific to the patient protection condition) is often sought, obtained, or medically indicated for the patient's health condition(s) or history. The HIPAA Privacy Rule does not prohibit the use or disclosure of PHI that indicates or is potentially related to ``reproductive health care'' as it is now defined in 45 CFR 160.103 (see 89 FR 32976 for definition effective June 25, 2024; see also 89 FR 33005 through 33007 for the 2024 HIPAA Privacy Rule's preamble discussion of that definition) where the use or disclosure is not for a purpose described at 45 CFR 164.502(a)(5)(iii) and where the use or disclosure is otherwise required or permitted by the HIPAA Privacy Rule. Therefore, within the information blocking regulations, the proposed new Protecting Care Access Exception is needed where an information blocking actor (whether or not that actor is required to comply with the HIPAA Privacy Rule) is concerned about the risk of potential exposure to legal action (as we propose in Sec. 171.206(e) to define ``legal action'') flowing from an access, exchange, or use of such EHI for a permissible purpose. We recognize that no information blocking exception can address all of the concerns a person may have about potential legal action for the mere act of seeking, obtaining, providing, or facilitating reproductive health care. However, to the extent such concerns may be mitigated by actors' withholding relevant EHI from access, exchange, or use that all other applicable law would permit and where no other existing information blocking exception applies, we believe such withholding of EHI is reasonable and necessary. We are concerned that actors' uncertainty about whether such withholding of EHI could implicate the information blocking definition could prevent actors from withholding EHI unless an exception applies. Thus, we believe the Protecting Care Access Exception is needed to address actors' concerns specific to information blocking related to the risk of providers changing or limiting what care they are willing to offer (such as when a professional changes practice specialty or a hospital closes a service or department). When providers limit what care they are willing to offer or what new patients they are willing to accept, it may be more difficult for those who seek care to get access to care they need. When patients' needs are not being met, they lose trust in the health care system and in their physicians. Trust in one's own physician, in general, correlates with better care satisfaction and outcomes. This could also be true of other types of health care providers. Thus, we believe that addressing actors' uncertainty specific to information blocking with the proposed Protecting Care Access Exception would promote better patient satisfaction and health outcomes as well as continued development, public trust in, and effective nationwide use of health information technology infrastructure to improve health and care. Moreover, actors' uncertainty about the potential information blocking implications of not sharing all of the EHI that applicable laws would permit them to share could undermine health care professionals' (and other health care providers') confidence in their ability to protect the privacy and confidentiality of their patients' EHI. Such a lack of confidence on the part of health care providers can in turn erode a patient's trust. Patient trust in physician confidentiality and competence is associated with patients being less likely to withhold information from doctors and more likely to agree it is important for health care providers to share information with each other. Thus, actors' narrowly tailored restrictions on (otherwise lawful) sharing of specific EHI in the circumstances addressed by the proposed exception in Sec. 171.206 would be reasonable and necessary to preserve patient trust in the health IT infrastructure and information sharing, not just to protect the availability and safety of care and to promote better care outcomes. One of the goals of the information blocking exceptions is ``to accommodate practices that, while they may inhibit access, exchange, or use of EHI, are reasonable and necessary to advance other compelling policy interests . . .'' including ``[p]romoting public confidence in the health IT infrastructure by supporting the privacy and security of EHI and protecting patient safety,'' as we explained in the ONC Cures Act Final Rule (85 FR 25791). In the absence of an information blocking exception applicable to risks of legal actions that actors believe could arise from the sharing EHI for permissible purposes (for instance, with entities not required to comply with the HIPAA Privacy Rule), we are concerned actors may be unwilling to engage in these practices that--for example--advance public confidence in health IT infrastructure and protect patient safety. If actors are unwilling to engage in such practices, health care providers may convey to patients an inability to withhold EHI even when they believe withholding the EHI could mitigate the potential risks cognizable under the [[Page 63631]] Protecting Care Access Exception. If patients are aware that health care providers believe that they are unable to avoid sharing EHI to mitigate risks of potentially exposing care providers, recipients, or facilitators to legal action then patients may be less willing to be candid with their providers about their health history, conditions, or other information relevant to the patient's care. Without that candor, health care providers may be unable to provide care that will best meet the patient's needs. In addition, a care provider's lack of confidence or competence in their ability to adequately safeguard the privacy of information that care recipients share with them could erode the mutual trust that contributes to better care outcomes by promoting more effective relationships between care providers (including clinicians) and the individuals receiving care. In the absence of an exception applicable to practices that the proposed Protecting Care Access Exception would cover, we are concerned that health IT developers of certified health IT and HINs/HIEs may be unwilling to take the actions necessary to address their own, or their customer health care provider's, good faith belief that particular sharing of specific EHI could create the risk of potential exposure of a health care provider (or persons seeking, obtaining, providing, or facilitating care) to legal action regarding health care items and services that are lawful under the circumstances in which such health care is provided. Thus, health care providers in these situations may believe they are faced with a choice between changing what care they offer (such as when a hospital closes a department) or switching at least some portions of their clinical records from electronic to paper formats specifically to avoid concerns that they may be engaged in information blocking. For health care professionals in reproductive health care specialties or whose practice necessarily includes patients who need reproductive health care, a partial or complete switch to paper-based recordkeeping for that care may seem like their only option. (Because the information blocking definition references ``electronic health information'' rather than all ``protected health information,'' the information blocking regulations do not apply to health information maintained only in paper format.) A reversal to paper-based methods of keeping even a relatively small portion of the records currently managed using modern health IT would have an adverse effect on interoperability and on the development of a nationwide health IT infrastructure that does the things identified in section 3001(b) of the PHSA. Thus, such a reversal to paper-based recordkeeping methods would impede the goals of promoting public confidence in the electronic health information infrastructure and of advancing patient safety through the use of interoperable health IT and EHI. For example, information kept only on paper is not available to support tools that help clinicians avoid adverse drug events by automatically checking for potential drug-drug or drug- allergy interactions. For the reasons discussed above, we believe actors' practices of limiting EHI sharing under the conditions of the proposed Sec. 171.206 exception are reasonable and necessary to preserve advances in digitization, interoperability, and public confidence in the nationwide health information technology infrastructure. Actors selectively withholding EHI that indicates or is potentially related to reproductive health care (as applicable) under the conditions of the proposed Sec. 171.206 would also promote patient safety and improve outcomes by fostering trust between care providers and recipients. Maintaining advances and trust in the health information technology infrastructure fosters better care by continuing to make information available to more care providers and care recipients when and where the information can help them choose the right care for each patient (care recipient). Use of interoperable, electronic health IT and exchange of EHI also enables providers to use decision support tools, such as drug- drug interaction alerting, and to deliver better care. The proposed Protecting Care Access Exception (Sec. 171.206) could apply in some circumstances where another exception (such as Preventing Harm (Sec. 171.201) or Privacy (Sec. 171.202)) would or could also apply. The proposed new exception is, however, intended to stand alone and independent of other. The proposed Protecting Care Access Exception would not affect if, how, or when any provision of any exception that does not explicitly reference Sec. 171.206 applies to an actor's practice, or how any such provision operates. Moreover, where facts and circumstances were such that an actor could choose to shape their practice in withholding EHI to satisfy either the Protecting Care Access Exception (if finalized) or another exception, the actor would have discretion to choose which exception they wish to satisfy. An actor's practice in such situation(s) would not need to satisfy both exceptions in order for the practice to not be considered information blocking. One of the existing information blocking exceptions applicable in some circumstances where the proposed Protecting Care Access Exception could also apply is the Privacy Exception. Of particular relevance to actors' confidence that they will not be ``information blocking'' if they withhold EHI based on the individual's preference that their EHI be closely held is the Privacy Exception's sub-exception ``respecting an individual's request not to share information'' (Sec. 171.202(e)). This Privacy sub-exception is applicable where an actor agrees to honor an individual's request not to share their EHI even where it is permissible to share under all applicable law. We are proposing to strengthen and simplify that Sec. 171.202(e) Privacy sub-exception as discussed in section IV.B.1.c of this proposed rule. The Sec. 171.202(e) sub-exception offers actors certainty that they can, if they so choose, honor an individual's preference for restrictions on the sharing of EHI about the individual without subjecting the actor to an information blocking penalty or disincentive for not sharing such EHI. However, while the Sec. 171.202(e) sub-exception does not rest on why the individual may prefer that some or all of their EHI not be shared, the Sec. 171.202(e) sub-exception only applies to scenarios where the individual requests the restrictions. There may be circumstances where an individual does not request the restriction, but when it would be reasonable and necessary for actors to interfere with access, exchange, or use of EHI for the purpose of addressing individuals' (let alone providers' and others') risk of potential exposure to legal action that could discourage availability, access, and choice of medically appropriate reproductive health care. We believe it would be burdensome to individuals, in the constantly changing legal landscape, to rely exclusively on them to make or update requests for restrictions on their EHI that indicates or is potentially related to reproductive health care. In such a complex and uncertain environment, any individual may experience difficulty in making timely requests for such restrictions. Moreover, some individuals may not have the resources--such as affordable, secure access to the internet--to update their providers on their information sharing preferences outside of the occasions that they interact with these providers to obtain health care. Thus, individuals may not be able to request [[Page 63632]] restrictions soon enough, or that are broad enough, to protect themselves or others from potential legal liability based on what care they have received. An individual's request for restrictions on sharing their EHI is specific and limited to that individual's EHI, and (depending on what the individual chooses to request) may be specific to identified requestors of the individual's EHI. Thus, it is not as efficient for actors to implement such individual restrictions as it would be to implement restrictions based on an organizational policy that consistently addresses a concern common to sharing any individuals' EHI in a particular access, exchange, or use scenario--such as the actor's good faith belief that there is a concern regarding the risk of potential exposure to legal action that could be created or increased by propagating to a recipient not required to comply with the HIPAA Privacy Rule the specific EHI within a patient's record that indicates the receipt of reproductive health care. For these reasons, we believe that health care providers and other actors must have available to them an information blocking exception designed to apply to practices that the actor believes could help to avoid creating--through sharing of EHI indicating or potentially related to reproductive health care in relevant scenarios--a risk of potential exposure to legal action based on the mere fact that lawful reproductive health care was sought, obtained, provided, or facilitated (or where the proposed patient protection condition would apply, because the EHI indicates patient health history or condition(s) for which reproductive health care is often sought, obtained, or medically indicated). When an actor has a belief consistent with the proposed Sec. 171.206(a)(1) belief requirement, we believe an exception should be available that is designed to cover practices likely to interfere with access, exchange, or use of EHI under certain conditions.\245\ Therefore, we propose in Sec. 171.206 a new Protecting Care Access Exception from the information blocking definition. When its conditions are met, the new exception would cover an actor's practices that interfere with access, exchange or use of EHI in order to reduce potential exposure of applicable persons to legal action (as defined in the exception). For the proposed exception to apply, the potential exposure to legal action that the actor believes could be created must be one that would arise from the fact that reproductive health care was (or may have been) sought, obtained, provided, or facilitated rather than because the care provided was (or is alleged to have been) clinically inappropriate or otherwise substandard. --------------------------------------------------------------------------- \245\ These conditions would be those specified in the exception. --------------------------------------------------------------------------- We note here that the statutory authority in PHSA section 3022(a)(3) is to ``identify reasonable and necessary activities that do not constitute information blocking.'' Thus, practices that meet the applicable conditions of the proposed new Protecting Care Access Exception (Sec. 171.206) would not be considered information blocking (as defined in PHSA section 3022(a)(1) and 45 CFR 171.103), and, therefore, actors would not be subject to civil monetary penalties or disincentives under HHS information blocking regulations based specifically on those practices. However, as is the case with exceptions already established in 45 CFR part 171, the proposed exception would not override an actor's obligation to comply with a mandate contained in law that requires disclosures that are enforceable in a court of law. For example, the proposed exception would not invalidate otherwise valid court-ordered disclosures, or disclosures (for example, infectious disease, or child or elder abuse case reports) mandated by a Federal, State, or Tribal law with which an actor is required to comply in relevant circumstances. The exception is also not intended to justify an attempt to limit the legally required production of (otherwise discoverable) EHI in a civil, criminal, or administrative action that is brought in the jurisdiction where a health care provider provided health care that a patient (or their representative) alleges was negligent, defective, substandard, or otherwise tortious. Similarly, the exception would not apply to, and is not intended to justify, attempts to avoid disclosing information where the actor's belief is that the information could be useful to a legal action against the actor or other person specific to alleged violations of Federal or other law against conduct other than merely seeking, receiving, providing, or facilitating reproductive health care. One example of such other conduct would be a physical assault of any natural person, even if the assault occurred in a health care setting.\246\ --------------------------------------------------------------------------- \246\ The definition of ``person'' for purposes of 45 CFR part 171 is codified in Sec. 171.102 and is, by cross-reference to 45 CFR 160.103, the same definition used for purposes of the HIPAA Privacy Rule (45 CFR part 160 and subpart E of 45 CFR part 164). The Sec. 160.103 definition of ``person'' clarifies the meaning of ``natural person'' within it. We use ``natural person'' with that same meaning in proposed Sec. 171.206(b)(3) and throughout this discussion of proposed Sec. 171.206. --------------------------------------------------------------------------- We emphasize that if the proposed Protecting Care Access Exception were to be finalized, actors would continue to be subject to other Federal laws, and to State and Tribal laws. This is consistent with how the information blocking exceptions in place today operate in harmony with, but separate from, requirements of other statutes and regulations--including, among others, the HIPAA Privacy Rule's individual right of access (45 CFR 164.524). For example, an actor that is also a HIPAA covered entity may receive a request from an individual for access to EHI of which the individual is the subject, in a manner (form and format) specified by the individual. If the actor is technically unable to fulfill the request, or if the individual and actor cannot come to agreement on terms to fulfill the request in the manner requested or an alternative manner consistent with Sec. 171.301(b), the actor may be able to satisfy the Infeasibility Exception by meeting that exception's manner exception exhausted (Sec. 171.204)(a)(4)) and the responding to requests (Sec. 171.204(b)) conditions. By satisfying the Infeasibility Exception, the actor's practice of failing to fulfill the request for access, exchange, or use of EHI will not be considered information blocking. However, the actor in this example is a HIPAA covered entity and, therefore, must comply with the HIPAA Privacy Rule's right of access at 45 CFR 164.524, even though the actor's practices in failing to provide access, exchange, or use of EHI met the requirements to be covered by the Infeasibility Exception (Sec. 171.204) for purposes of the information blocking regulations. Consistent with our approach to establishing the initial eight information blocking exceptions, the conditions of the proposed Protecting Care Access Exception (Sec. 171.206) are intended to limit its application to the reasonable and necessary activities enumerated within the exception. Therefore, our proposed Protecting Care Access Exception would (for purposes of the information blocking definition in Sec. 171.103) cover an actor's practice that is implemented to reduce potential exposure of persons meeting the Sec. 171.202(a)(2)(i) or (ii) definition of ``individual,'' other persons referenced or identifiable from EHI as having sought or obtained reproductive health care, health care providers, or persons who facilitate access to or delivery of health care to potential threats of legal action based on the decision to seek, obtain, provide, or facilitate reproductive health care, or on patient health information potentially related to [[Page 63633]] reproductive health care, subject to the exception's conditions. Because we propose in this rule an exception that relies on the ``reproductive health care'' definition in 45 CFR 160.103, we also propose to add to Sec. 171.102 the following: ``Reproductive health care is defined as it is in 45 CFR 160.103.'' We refer readers to 45 CFR 160.103or 89 FR 32976 for that definition, which became effective for purposes of the HIPAA Privacy Rule on June 25, 2024.\247\ We refer readers interested in learning more about this definition to 89 FR 33005 through 33007 for the 2024 HIPAA Privacy Rule's preamble discussion of the ``reproductive health care'' definition. --------------------------------------------------------------------------- \247\ The addition of the ``reproductive health care'' definition to 45 CFR 160.103 is reflected in the Electronic Code of Federal Regulations (eCFR) system at https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-160/subpart-A/section-160.103 at the time this proposed rule (HTI-2) is issued. The annual revision of the published Title 45 occurs on October 1. (The eCFR is a continuously updated online version of the CFR. Please see the following website for more information about the eCFR system: https://www.ecfr.gov/reader-aids/using-ecfr/getting-started.) --------------------------------------------------------------------------- For this exception to apply to an actor's practice that is likely to interfere with EHI access, exchange, or use, the practice would have to satisfy the threshold condition in the proposed paragraph (a), and at least one of the other conditions (proposed paragraph (b) or (c)) of the proposed exception. These conditions are discussed in detail below. An actor's practice could satisfy both conditions (b) and (c) at the same time, but the minimum requirement for the exception to apply would be that the practice satisfy at least one of these two conditions in complement to the threshold condition in paragraph (a). b. Threshold Condition and Structure of Exception The Sec. 171.206(a) threshold condition's requirements must be satisfied in order for any practice to be covered by the proposed exception. To meet the condition's subparagraph (a)(1) belief requirement, the practice must be undertaken based on a good faith belief that: the person(s) seeking, obtaining, providing, or facilitating reproductive health care are at risk of being potentially exposed to legal action that could arise as a consequence of particular access, exchange or use of specific EHI; and the practice could reduce that risk. To satisfy the belief requirement (Sec. 171.206(a)(1)), the actor's belief need not be accurate, but must be held in good faith. We are also considering, and seek comment, on whether actors, patients, or other interested parties may view ``good faith belief'' as a standard that is unnecessarily stringent or that could make the Protecting Care Access Exception difficult for small actors with limited resources, such as small and safety net health care providers, to confidently use. We are also interested in any thoughts or concerns commenters may have about the ``good faith belief'' standard and how such concerns could be mitigated by the addition to Sec. 171.206 of a presumption that an actor's belief is held in good faith. To ensure we have flexibility to do so in case we determine it is the optimal approach after considering public comments on the proposed Protecting Care Access Exception, we propose in the alternative to do one or both of the following: (1) set ``belief'' or ``honest belief'' rather than ``good faith belief'' as the substantive standard in Sec. 171.206(a); or (2) add to Sec. 171.206 a provision for HHS to presume an actor's belief met the standard unless we have or find evidence that the actor's belief did not meet the standard at all relevant times (relevant times are those when the actor engaged in practices for which the actor seeks application of the exception). Like ``good faith belief,'' ``belief'' or ``honest belief'' would be a subjective rather than an objective standard. Under either alternative, the actor's belief would not be required to be accurate but could not be falsely claimed. Unlike ``good faith,'' neither ``belief'' nor ``honest belief'' is a particularly long established and widely used legal standard. However, we are interested in actors' and other commenters' views on whether these standards might help to reduce potential misunderstanding of Sec. 171.206(a) and what would be necessary for an actor to meet the proposed ``good faith belief'' standard. Where an actor is a business associate of another actor or otherwise maintains EHI on behalf of another actor, this exception would (where its requirements are otherwise fully satisfied) apply to practices implemented by the actor who maintains EHI based on the good faith belief and organizational policy or case-by-case determinations of the actor on whose behalf relevant EHI is maintained. We propose in the alternative to require that each actor rely only on their own good faith belief in order to implement practices covered by the Protecting Care Access Exception, including when an actor maintains EHI on behalf of other actor(s) or any other person(s). We welcome comment on both of these approaches to the good faith belief requirement where the actor implementing the practice is doing so in relation to EHI maintained on behalf of another actor. As discussed in section IV.B.3.e, we propose to define ``legal action'' for purposes of Sec. 171.206 to include a broad array of criminal, civil, and administrative investigations, actions, and proceedings as specified in the proposed Sec. 171.206(e)(1)-(3). We emphasize that to satisfy the proposed Protecting Care Access Exception, an actor's practice that is likely to interfere with lawful access, exchange, or use of EHI would need to fully satisfy relevant requirements of the threshold condition in Sec. 171.206(a) and at least one of the other two conditions (Sec. 171.206(b) or Sec. 171.206(c)).\248\ Thus, a practice could not satisfy the exception if implemented based on an actor's good faith belief about any access, exchange, or use (that is permitted under HIPAA Privacy Rule and any other applicable privacy law) that potentially creates or increases anyone's risk of facing any legal action that would not be based upon a person having merely sought, obtained, provided, or facilitated care that was lawful under the circumstances in which such health care was provided. The exception is not intended to apply to an actor's interference with access, exchange, or use of EHI based on an actor's belief that the practice would reduce any person's exposure to legal action or liability based on the conduct that was not the mere act of seeking, obtaining, providing, facilitating, or (where the patient protection condition applies, potentially needing) reproductive health care that was, under the circumstances in which the conduct occurred, unlawful. --------------------------------------------------------------------------- \248\ In relevant circumstances, an actor's practice might meet both the Sec. 171.206(b) patient protection and Sec. 171.206(c) care access conditions simultaneously. But each of these conditions could also apply in circumstances where the other does not. Thus, the proposed exception is intended and designed to apply where either or both of the patient protection and care access conditions are met in complement to the Sec. 171.206(a) threshold condition. --------------------------------------------------------------------------- The belief requirement (subparagraph (1)) of the threshold condition (Sec. 171.206(a)) would ensure that the exception is applicable only in situations where an actor has a good faith belief that their practice of interfering with the access, exchange, or use of EHI that indicates the seeking, obtaining, providing or facilitating of reproductive health care (not with EHI access, exchange, or use in general or universally) could reduce a risk of potential exposure to legal action against identifiable persons that could otherwise arise as a consequence of the [[Page 63634]] particular access, exchange or use of specific EHI that is affected by the practice. To satisfy the Sec. 171.206(a)(1) requirement, the actor's good faith belief would need to be that persons seeking, obtaining, providing, or facilitating reproductive health care ``are at risk'' of being potentially exposed to legal action. This does not mean that the exception would apply only where the actor is confident that legal action will follow from access, exchange, or use of EHI related to reproductive health care. ``Are at risk'' would simply mean that the risk the actor believes might arise as a consequence of the affected access, exchange, or use of EHI is one that could, to the best of the actor's knowledge and understanding, arise under law that is in place at the time the practice(s) that is based on the belief are implemented. Thus, the proposed Sec. 171.206 exception would not apply to practices undertaken based on a hypothetical risk of exposure to legal action, such as one the actor postulates could perhaps become possible if applicable law(s) were to change in the future. Similarly, where an actor may believe a risk exists that someone could potentially be exposed to legal action but does not believe that a particular practice could achieve some reduction in that risk, the Sec. 171.206(a)(1) requirement would not be met by (and therefore the Sec. 171.206 exception would not apply to) that practice. The Sec. 171.206(a) threshold condition's tailoring requirement (Sec. 171.206(a)(2)) is intended to further restrict the exception's coverage to practices that are no broader than necessary to reduce the risk of potential exposure to legal action that the actor has a good faith belief could arise from the particular access, exchange or use of the specific EHI. Like similar provisions in other exceptions, this tailoring requirement ensures that the exception would not apply to an actor's practices likely to interfere with access, exchange, or use of all of an individual's EHI when it is only portions of the EHI that the actor believes could create the type of risk recognized by the exception. Where only portion(s) of the EHI an actor has pertaining to one or more patients pose a risk of potentially exposing some person(s) to legal action, the proposed Protecting Care Access Exception would apply only to practices affecting particular access, exchange, or use of the specific portion(s) of the EHI that pose the risk. Data segmentation is important for exchanging sensitive health data (as noted in the ONC Cures Act Final Rule at 85 FR 25705) and for enabling access, exchange, and use of EHI (as noted in the HTI-1 Proposed Rule at 88 FR 23874). We are aware of external efforts to innovate and mature consensus technical standards, and we hope this will foster routine inclusion of increasingly advanced data segmentation capabilities in more EHR systems and other health IT over time. However, we have received public feedback (both prior to and in response to the HTI-1 Proposed Rule request for information on health IT capabilities for data segmentation and user/patient access at 88 FR 23874 through 23875) indicating that there is currently significant variability in health IT products' capabilities to segment data, such as to enable differing levels of access to data based on the user and purpose. We recognize there is a potential that some actors who may wish to withhold specific EHI under the conditions specified in the proposed Protecting Care Access Exception (Sec. 171.206) may not yet have the technical capability needed to unambiguously segment the EHI for which Sec. 171.206 would apply from other EHI that they could lawfully make available for a particular access, exchange, or use. Therefore, we propose elsewhere in this proposed rule to modify the Infeasibility Exception's segmentation condition (Sec. 171.204(a)(2)) to explicitly provide for circumstances where the actor cannot unambiguously segment EHI that may be withheld in accordance with Protecting Care Access Exception (Sec. 171.206) from the EHI for which this exception is not satisfied. (This and other proposed revisions to Sec. 171.204(a)(2) are discussed in section IV.B.2.A of this proposed rule.) The implementation requirement in subparagraph (a)(3) of the threshold condition is intended to ensure that practices are applied fairly and consistently while providing flexibility for actors to implement a variety of practices, and to do so through organizational policy or in response to specific situations, as best suits their needs. We propose that any given practice could satisfy this implementation requirement in either of two ways. First, an actor could undertake the practice consistent with an organizational policy that meets the requirements proposed in Sec. 171.206(a)(3)(i). To satisfy the proposed requirement in this first way, the organization's policy would need to identify the connection between the particular access, exchange, or use of the specific EHI with which the practice interferes and the risk of potential exposure to legal action that the actor believes could be created by such access, exchange, or use. The policy would also need to be: in writing; based on relevant clinical, technical, or other appropriate expertise; implemented in a consistent and non-discriminatory manner; and structured to ensure each practice implemented pursuant to the policy satisfies paragraphs (a)(1) and (a)(2) as well as at least one of the conditions in paragraphs (b) or (c) of Sec. 171.206 that is applicable to the prohibition of the access, exchange, or use of the EHI. In order to ensure each practice implemented pursuant to the policy applies only to the particular access, exchange, or use scenario(s) to which at least one of the conditions in paragraphs (b) or (c) of Sec. 171.206 is applicable, a policy would need to specify the facts and circumstances under which it would apply a practice. Such specifications need not be particularized to individual patients but would need to identify with sufficient clarity for the actor's employees and business associates (or other contractors, as applicable) to accurately apply the practice only to relevant access, exchange, or use scenarios. The types of facts or circumstances the policy might need to specify may vary, but we believe might often include such details as to what EHI (such as what value set(s) within what data element(s)) and to what scenario(s) of access, exchange, or use the policy will apply to a practice. There may be value sets currently available or in development by various parties that may help an actor to identify what EHI within the actor's EHR or other health IT systems indicates care meeting the reproductive health care definition in 45 CFR 160.103. However, we do not propose to limit the application of the exception to any specific value set(s). Because version updates of such value sets, or new value sets, may develop more rapidly than adoption or reference of them in regulations could occur, we believe the intended operation of the exception will be best served by leaving actors flexibility to identify, document in their organizational policy or case-by-case determination(s), and then use whatever value set(s) comport with their belief that a risk of potential exposure to legal action (consistent with the exception's conditions) could be created or increased by sharing specific EHI indicating or (where the patient protection condition applies) potentially related to reproductive health care. The proposed provision in paragraph (a)(3)(ii) offers actors the second of the two ways to satisfy subparagraph (a)(3): [[Page 63635]] by making determination(s) on a case-by-case basis. To satisfy paragraph (a)(3)(ii), any case-by-case determination would need to be made in the absence of an organizational policy applicable to the particular situation and be based on facts and circumstances known to, or believed in good faith by, the actor at the time of the determination. A practice implemented based on the determination must also be tailored to reduce the risk of legal action the actor has a good faith belief could result from access, exchange, or use of the EHI. And the practice must be no broader than necessary to reduce the risk of potential exposure to legal action (paragraphs (a)(1) and (a)(2)). Finally, to meet paragraph (a)(3)(ii), the determination made on a case-by-case basis would need to be documented either before or contemporaneous with beginning to engage in any practice(s) based on the determination. The documentation of the determination must identify the connection or relationship between the interference with access, exchange, or use of EHI indicating or related to reproductive health care and the risk of potential exposure to legal action. By identifying the connection or relationship, this documentation would explain what risk the actor believes the practice(s) will mitigate. The proposed Sec. 171.206(a)(3) implementation requirement's optionality would support the actor's interest in having flexibility to address both relatively stable and more dynamic facts and circumstances. Each of the options is intended to balance this interest of the actor with the interests of others, including the actor's current and potential competitors, in ensuring that any information blocking exception does not apply to practices that are not necessary for the specific purpose(s) the exception is designed to serve. The subparagraph (a)(3)(i) organizational policy provision would allow actors to apply relevant expertise available at the time of creating and updating organizational policies to craft a policy that suits their circumstances (such as technological capabilities and staffing and the types of scenarios they have experienced or expect to experience, perhaps with some regularity). The case-by-case determination provision (sub-paragraph (a)(3)(ii)) ensures the proposed exception would be available for all actors across the full array of facts and circumstances they may encounter, including unanticipated ones. We are considering adding to the Sec. 171.206(a) threshold condition an additional requirement that the actor's practice must not have the effect of increasing any fee for accessing, exchanging, or using EHI that the actor chooses to seek from an individual (as defined in Sec. 171.202(a)) or counsel representing the individual in an action or claim contemplated, filed, or in progress with a Federal agency, in Federal court, or a court in the jurisdiction where care was provided. We propose this requirement in the alternative. This alternative proposal would mean that the proposed exception would not be met by an actor's practice that had such effect even if any fee that the actor chooses to charge for access, exchange, or use of EHI would, after such increase, continue to satisfy the Fees Exception (Sec. 171.302). We seek comment on this potential additional requirement for an actor's practice to satisfy the proposed threshold condition (Sec. 171.206(a)). c. Patient Protection Condition The proposed patient protection condition in paragraph (b) of Sec. 171.206 could be met by practices implemented for the purpose of reducing the patient's risk of potential exposure to legal action (as legal action would be defined in Sec. 171.206(e)). Further narrowing the practices that could satisfy the condition, paragraph (b)(1) would require that the practice affect only specific EHI (the data point or points) that the actor in good faith believes demonstrates, indicates, or would carry a substantial risk of supporting a reasonable inference that the patient has: (1) obtained reproductive health care that was lawful under the circumstances in which such care was provided; (2) inquired about or expressed an interest in seeking reproductive health care; or (3) particular demographic characteristics or health condition(s) or history for which reproductive health care is often sought, obtained, or medically indicated. For purposes of Sec. 171.206, we would interpret ``lawful under the circumstances in which it was provided'' to mean that when, where, and under relevant circumstances (such as, for health care, the patient's clinical condition and a rendering health care provider's scope of practice) the care was: protected, required, or authorized by Federal law, including the United States Constitution, in the circumstances under which such health care is provided, regardless of the State in which it is provided; or not prohibited by Federal law and lawful under the law of the jurisdiction in which it was provided. Where care is not prohibited by Federal law and permitted under the law of the jurisdiction in which it is provided, we would consider the care lawful regardless of whether the same care would, under otherwise identical circumstances, also be unlawful in other circumstances (for instance, if provided in another jurisdiction). The patient protection condition proposed in Sec. 171.206(b) would provide the actor discretion and flexibility over time to determine which EHI poses a risk of potential exposure to legal action. At the same time, the Sec. 171.206(b)(1) requirement that the practice ``affect only the access, exchange, or use of specific electronic health information the actor believes could expose the patient to legal action'' because it shows or carries a substantial risk of supporting an inference of one of the things described in subparagraphs (i) through (iii) would preserve the expectation that the actor would share other EHI that the actor does not believe poses such a risk unless another exception applies, or sharing restriction(s) under other law apply, to that other EHI in relevant circumstances. We propose that even when an actor has satisfied the requirements in paragraph (b)(1), the practice would be subject to nullification by the patient if the patient explicitly requests or directs that a particular access, exchange, or use of the specific EHI occur despite any risk(s) the actor has identified to the patient. This requirement (paragraph (b)(2)) is intended to respect patients' autonomy to choose whether and when to share their own EHI. The requirement would prevent the exception from applying where an actor is attempting to substitute their judgment or tolerance of risks to the patient for the patient's own judgment.\249\ --------------------------------------------------------------------------- \249\ The patient protection condition in Sec. 171.206(b) would apply to practices implemented for the purpose of reducing the patient's risk of potential exposure to legal action (as legal action would be defined in Sec. 171.206(e). The care access condition in Sec. 171.206(c) would apply to practices an actor implements to reduce potential exposure to legal action based on the mere fact that reproductive health care occurred for persons, other than the person seeking or receiving care, who provide care or are otherwise involved in facilitating the provision or receipt of reproductive health care that is lawful under the circumstances in which it is provided. In some circumstances, an actor's practice might meet both the Sec. 171.206(b) patient protection and Sec. 171.206(c) care access conditions simultaneously. But each of these conditions could also apply in circumstances where the other does not. Thus, the proposed exception is intended and designed to apply where either or both of the patient protection and care access conditions are met in complement to the Sec. 171.206(a) threshold condition. --------------------------------------------------------------------------- [[Page 63636]] We clarify in proposed paragraph (b)(3) that for purposes of the patient protection condition ``patient'' means the natural person who is the subject of the electronic health information or another natural person referenced in, or identifiable from, the EHI as a person who has sought or obtained reproductive health care. We propose to also recognize as ``patients,'' for purposes of this condition, natural persons other than the natural person who is the subject of the EHI because we are aware that in the field there may be times when information about a parent's reproductive health care is included in the EHI of a child. (A child's parent is often identified in or identifiable through the child's EHI.) We note that the patient protection condition, and generally the exception, are not intended to permit any actor to avoid legal consequences resulting from malpractice or their own wrongdoing. The proposed exception is also not intended to have any effect on any obligation an actor has to comply with disclosure requirements under Federal, State, or Tribal law that applies to the actor. Even where an actor could deny any given access, exchange, or use of EHI for permissible purposes consistent with an information blocking exception, the actor who is a HIPAA covered entity or business associate would still have to comply with the 45 CFR 164.524 individual right of access, and any actor would still have to comply with other valid, applicable law compelling the actor to make the EHI available for permissible purposes.\250\ For example, the actor would still need to comply with applicable legal discovery rules and judicial orders issued by a court of competent jurisdiction. Non-compliance with such other laws could subject the actor to sanctions under those other laws regardless of whether the actor's practice would also be considered information blocking or would instead be covered by an exception set forth in any subpart of 45 CFR part 171. --------------------------------------------------------------------------- \250\ For purposes of the information blocking regulations, ``permissible purpose'' is defined in 45 CFR 171.102. --------------------------------------------------------------------------- We are also considering, and propose in the alternative, adding one or more of the following explicit requirements to the patient protection (Sec. 171.206(b)), care access (Sec. 171.206(c)), or threshold (Sec. 171.206(a)) condition(s) so that to be covered by the exception the actor's practice must not: if undertaken by any actor that is also a HIPAA covered entity or business associate, delay beyond the time allowed under 45 CFR 164.524 or otherwise interfere with any request for access, exchange, or use of EHI that implicates the HIPAA Privacy Rule's individual right of access in a manner or to an extent that would constitute non-compliance with 45 CFR 164.524; deny the individual (as defined in Sec. 171.202(a)(2)) or an attorney representing the individual access, exchange, or use of EHI for purposes of considering, bringing, or sustaining any claim for benefits under any Federal law or any action against the actor under administrative, civil, or criminal (including discovery and other procedural) law of the jurisdiction in which care indicated by the EHI was provided; interfere with any use or disclosure of EHI required by subpart C of 45 CFR part 160 as it applies to actions by the Secretary (or by any part of HHS) with respect to ascertaining compliance by covered entities and business associates with, and the enforcement of, applicable provisions of 45 CFR parts 160, 162, and 164; or prevent any EHI's use by or disclosure to a Federal agency or a State, or Tribal authority in the jurisdiction where health care indicated by the EHI was provided, to the extent such use or disclosure is permitted under 45 CFR parts 160 and 164. Each (or any) of these requirements would function as a limit on the applicability of the exception and mean that practices not meeting the exception for those reasons could constitute information blocking in addition to potentially violating any other law. (Due to the substantial variation across individual actors' circumstances, it would be impossible to maintain in the text of 45 CFR part 171 an accurate, comprehensive catalog of all other laws that could be implicated by an actor's practices otherwise consistent with any exception set forth in subparts B, C, or D of 45 CFR part 171.) We welcome comments on the proposed exception, including whether commenters would recommend we add to the exception (if finalized) any or all of the above potential additional limits on applicability of the proposed Protecting Care Access Exception (Sec. 171.206) that we propose in the alternative. d. Care Access Condition The proposed care access condition would apply as specified in paragraph (c) of Sec. 171.206 under the ``Regulatory Text'' heading of this proposed rule. The condition could be met by practices an actor implements to reduce potential exposure to legal action based on the mere fact that reproductive health care occurred for persons, other than the person seeking or receiving care, who provide care or are otherwise involved in facilitating reproductive health care that is lawful under the circumstances in which it is provided. Such persons would include licensed health care professionals, other health care providers, and other persons involved in facilitating care that is lawful under the circumstances in which it is provided. Such persons would include persons (friends, family, community caregivers, and others) who help patients find, get to the site of or home from, and afford care. For purposes of the care access condition in Sec. 171.206(c) and Sec. 171.206(b)(1)(i) (within the patient protection condition), the reproductive health care must be ``lawful under the circumstances in which it is provided'' as explained above in section IV.B.3.c of this proposed rule. To satisfy the care access condition in paragraph (c) of Sec. 171.206 as proposed, the practice must affect only access, exchange, or use of specific EHI (one or more data points) that the actor believes could potentially expose a care provider(s) or facilitator(s) to legal action because that EHI shows or would carry a substantial risk of supporting a reasonable inference that such person(s) are currently providing or facilitating, have provided or facilitated, or both, reproductive health care that is (or was) lawful under the circumstances in which it is (or was) provided.\251\ --------------------------------------------------------------------------- \251\ The patient protection condition in Sec. 171.206(b) would apply to practices implemented for the purpose of reducing the patient's risk of potential exposure to legal action (as legal action would be defined in Sec. 171.206(e). The care access condition in Sec. 171.206(c) would apply to practices an actor implements to reduce potential exposure to legal action based on the mere fact that reproductive health care occurred for persons, other than the person seeking or receiving care, who provide care or are otherwise involved in facilitating the provision or receipt of reproductive health care that is lawful under the circumstances in which it is provided. In some circumstances, an actor's practice might meet both the Sec. 171.206(b) patient protection and Sec. 171.206(c) care access conditions simultaneously. But each of these conditions could also apply in circumstances where the other does not. Thus, the proposed exception is intended and designed to apply where either or both of the patient protection and care access conditions are met in complement to the Sec. 171.206(a) threshold condition. --------------------------------------------------------------------------- We propose this requirement in order to ensure the Sec. 171.206(c) care access condition would not apply to an actor's practice affecting access, exchange, or use of EHI that the actor does not believe could create a risk of potential exposure to legal action based on the mere fact that reproductive health care was provided or facilitated. Actors will often have additional EHI that applicable law would also permit them [[Page 63637]] to make available for permissible purposes, which could include information relevant to the safety, continuity, and quality of care, such as a patient's chronic condition(s) or a medically confirmed allergy to a substance that does not indicate or suggest reproductive health care has, or may have, occurred (and thus poses no risk of exposure to legal action as defined in Sec. 171.206(e)). To the extent the actor has such other EHI that the actor can (both legally and technically) make available for any and all permissible purposes, we would expect the actor to do so. We recognize that in some circumstances the actor may need to make such other EHI available in an alternative manner rather than the manner requested by the requestor. (We use ``manner requested'' and ``alternative manner'' here in a sense consistent with paragraphs (a) and (b), respectively, of the Manner Exception as currently codified in Sec. 171.301.) We propose that when an actor's practice satisfies the threshold condition in Sec. 171.206(a) and meets all the requirements of the care access condition in Sec. 171.206(c), the actor's practice will not constitute information blocking. As with any of the existing exceptions, the proposed Protecting Care Access Exception would not supersede or override any other valid Federal, State, or Tribal laws that compel production of EHI for purposes of legal proceedings or that compel other disclosures in relevant circumstances. Therefore, actors and other interested persons will want to remember that satisfying an exception set forth in 45 CFR part 171 does not prevent other law that operates independently from the 45 CFR part 171 from potentially compelling an actor to provide access, exchange, or use of EHI in manners or for purposes the actor, or an individual, might prefer the EHI not be accessed, exchanged, or used. As actors are likely already aware, conduct that is not considered ``information blocking'' under 45 CFR part 171, whether on the basis of satisfying an exception or on the basis of not meeting an element of the definition of ``information blocking'' in the information blocking statute (42 U.S.C. 300jj-52) may nevertheless violate, and may subject the actor to consequences authorized by, laws separate from and operating independently of the information blocking statute and 45 CFR part 171. The care access condition would apply where the risk of potential exposure to legal action is specific to the mere fact that reproductive health care (that was lawful under the circumstances in which it was provided) was provided or facilitated. The care access condition would not be met where the risk of potential exposure to legal action is based on care having been provided in circumstances where the care was not lawful. (We refer readers again to our explanation, in Section IV.B.3.c of this proposed rule, of how we would interpret ``lawful under the circumstances'' in which care was provided in context of the proposed Sec. 171.206.) The proposed exception would not apply to a practice that precludes the patient or an attorney representing the patient from obtaining access, exchange, or use of the patient's EHI for purposes of filing a benefit claim or a complaint against the actor with any agency of the U.S. Government. It would be unreasonable for an actor to withhold from a patient or a patient's attorney EHI that they need or seek to use in support of a claim for a benefit that is filed with any agency of the U.S. Government. It would also be unreasonable for the actor to attempt to withhold EHI access, exchange, or use to impede the patient or the patient's attorney filing, or the U.S. Government investigating, any complaint against the actor that the patient or the patient's attorney may file with any agency of the U.S. Government. Patients and their attorneys should have easy access to necessary information for considering, filing, or maintaining or pursuing such claims or complaints. As we have noted several times in this proposed rule, an actor that is also required to comply with the HIPAA Privacy Rule must comply with the individual right of access as codified in 45 CFR 164.524 regardless of whether the actor may be able to satisfy any existing or proposed exceptions to the Sec. 171.103 definition of ``information blocking.'' To ensure actors remain aware of this fact, we propose as the first of several (non-exclusive) alternatives, to include in the proposed care access condition (Sec. 171.206(c)) an additional explicit restriction of the condition to practices that do not violate 45 CFR 164.524. We might finalize this additional requirement even if we do not finalize any of the other additional requirements that we propose to potentially apply to the Protecting Care Access Exception as a whole or to the proposed patient protection condition (Sec. 171.206(b)) (as discussed in section IV.B.3.b, above). The first requirement we propose in the alternative specific to the care access condition would provide for the care access condition (Sec. 171.206(c)) to be met by practices that could interfere with an individual's access to EHI only to the extent that the interference could otherwise implicate the ``information blocking'' definition in Sec. 171.103 without also constituting non-compliance with 45 CFR 164.524 where 45 CFR 164.524 also applies. For example, under this first proposed potential added restriction on applicability of Sec. 171.206(c), a delay of an individual's access, exchange, or use of EHI that would rise to the level of an ``interference'' for purposes of the ``information blocking'' definition in Sec. 171.103 that satisfied all other requirements of Sec. 171.206(a) and (c) would be covered by the Sec. 171.206 exception only to the extent the delay of the individual's (or their personal representative's) access to EHI did not exceed the maximum time permitted, in the specific circumstances, for fulfillment of access to PHI under 45 CFR 164.524. (Coverage of an exception would be irrelevant for a delay not rising to the level of an ``interference'' because Sec. 171.103 focuses on practices not required by law that are likely to ``interfere with'' access, exchange, or use of EHI.) This proposed restriction to practices not violating Sec. 164.524 would also mean Sec. 171.206 would apply where an actor's interference involved offering fewer manners of access, exchange, or use than would be feasible for the actor to support, but only to the extent that the actor's limiting the manners in which EHI is made available would not constitute a violation under 45 CFR 164.524. We welcome comment on this first additional potential limitation on the applicability of the proposed exception. We propose as a second (again, non-exclusive) alternative to include in the proposed care access condition (Sec. 171.206(c)) an additional requirement that would be applicable specifically if an actor chooses to engage in a practice of delaying fulfillment of requests for EHI access, exchange, or use by individuals (as defined in Sec. 171.202(a)(2)) because the actor wants to provide, in a non- discriminatory manner, information to the individual relevant to the actor's good faith belief that a risk of potential exposure to legal action could be created by the individual's choice of how to receive their EHI or to whom the individual wishes to direct their EHI. For example, an actor that is also a HIPAA covered entity would, under Sec. 164.524, be required to fulfill an individual's request for access to PHI or to transmit to a third party an electronic copy of the individual's PHI in an EHR within the time period required under Sec. 164.524. [[Page 63638]] Where the Sec. 171.206 exception would apply and the third party is not a covered entity or business associate, the actor may wish to first provide the individual with information (that is, to the best of the actor's knowledge and belief, accurate and factual) about the HIPAA Privacy, Security, and Breach Notification Rules and differences in their applicability to EHI when it is not held by a HIPAA covered entity or business associate in comparison to when it is. Similarly, an actor might wish to communicate such information to an individual before enabling access, exchange, or use of EHI for a health care provider that is not a HIPAA covered entity or business associate. The actor might, for example, be concerned that the individual may not have previously obtained or been provided basic information about how the applicability of the HIPAA Privacy Rule to information held by or for a provider that is not a HIPAA covered entity may differ from the rule's application to the same information when it is held by or for entities regulated under HIPAA. The actor may wish to provide the individual such information so that the individual would have a fair opportunity to consider the possible privacy risks. In such situations, the actor may be concerned about potential information blocking implications of the delay that is necessary to provide the individual with information. Or the actor may be concerned with the delay that results when an individual (or their personal representative) is considering the information before confirming they want the actor to proceed with enabling the application the individual (or their personal representative) has chosen to receive the EHI of which the individual is a subject. Specifically, the actor may be concerned these delays could rise to the level of an ``interference'' and, therefore, implicate the information blocking definition even if the time required is less than the maximum time permitted to fulfill PHI access under 45 CFR 164.524 in the relevant circumstances. Therefore, we are considering the second proposed additional a requirement for Sec. 171.206. This second potential additional requirement would apply where an actor's practice delays making EHI available upon individual request or directive in order to provide individuals with non-biased general information about relevant laws or about the actor's belief that is consistent with Sec. 171.206(a)(1)(i), the delay must be of no longer duration than is reasonably necessary to provide to the individual two things: (1) honest information that is provided in a non-discriminatory manner and that is relevant to the actor's belief that a risk of potential exposure to legal action could be created by the particular access, exchange, and use of what specific EHI, such as general information about privacy laws or other laws that the actor believes may be relevant; and (2) a reasonable opportunity to consider the information and seek additional information from other sources if the individual would like, before the individual is asked to either confirm or revise any specifics of their request for access, exchange, or use of their EHI. Under this alternative proposal specific to delaying a response to a right of access request (including the right to direct a HIPAA covered entity to transmit to a third party an electronic copy of the individual's PHI in an EHR), delays longer than reasonably necessary to provide the individual with information relevant to the actor's belief that is consistent with Sec. 171.206(a)(1) and allow the individual to consider the actor's information and seek information from additional source(s) (if the individual desires) would not satisfy the Sec. 171.206(c) care access condition. This proposed restriction that is specific to delays for the purpose of informing individuals of an actor's belief that sharing specific EHI could create risk of potential exposure to legal action could be implemented regardless of whether we also implement a requirement that, for the care access condition or for the threshold condition to be met by an actor's practice, the practice must not constitute a violation of Sec. 164.524. This potential additional requirement would limit the applicability of the condition in scenarios where an actor might choose to engage in delay to provide individuals with information about potential privacy consideration, but should not be construed as creating an affirmative requirement for any actor to delay fulfillment of individual access requests to provide individuals with information about potential privacy implications of the individual's request. We reiterate that information blocking exceptions are voluntary. We reiterate that even in scenarios where an actor's denial of access, exchange, or use of EHI might not be ``information blocking'' because it satisfies an exception under and for purposes of part 171, an actor that is a HIPAA covered entity or business associate will still need to comply with 45 CFR 164.524 (individual right of access). (This is true of the exceptions codified in subparts B, C, and D of 45 CFR part 171 as of the date of publication of this proposed rule and would also be true of the new exceptions proposed in this rule in the event any of them are finalized.) The additional requirement(s) we are considering, and as noted above propose in the alternative, would seek to more finely tune the exception's balance of the interests of actors and patients in protecting reproductive health care availability by mitigating legal risks for the people who provide that care, and for the people who facilitate the provision of such care, with the interests of individuals in being able to access, exchange, and use all of their EHI however and whenever they want, and to share all of their EHI however and with whomever they choose, at no cost for ``electronic access'' as defined in Sec. 171.302(d). We seek comment on these proposals. e. Clarifying Provisions: Presumption and Definition of ``Legal Action'' For purposes of determining whether an actor's practice meets paragraph Sec. 171.206(b)(1)(i) or Sec. 171.206(c), we propose in Sec. 171.206(d) that care furnished by someone other than the actor would be presumed to be lawful unless the actor has actual knowledge that the care was not lawful under the circumstances in which it was provided. The presumption provision proposed in Sec. 171.206(d) is similar to the presumption provision finalized (in 45 CFR 164.502(a)(5)(iii)(C)) by the 2024 HIPAA Privacy Rule, but is necessarily different because of differences in how the prohibition at 45 CFR 164.502(a)(5)(iii)(A) operates and how the proposed Protecting Care Access Exception (Sec. 171.206) is intended to operate. First, the proposed Protecting Care Access Exception (Sec. 171.206) would be voluntary. It would offer those actors who may wish to engage in practices likely to interfere with EHI access, exchange, or use under the exception's conditions certainty that practices satisfying the exception will not be considered ``information blocking.'' Nothing in Sec. 171.206 is intended to create an affirmative obligation for any actor to evaluate whether the Protecting Care Access Exception might apply to any access, exchange, or use of EHI for permissible purposes. Second, the proposed Protecting Care Access Exception (Sec. 171.206) is based on statutory authority found in section 3022 of PHSA to identify reasonable and necessary activities that do not constitute information blocking for purposes of the PHSA 3022 definition of the term. We do not propose that [[Page 63639]] anything in Sec. 171.206 would operate to override an actor's obligation to comply with another (applicable) law that requires the actor to make EHI available for any permissible purpose. Thus, an actor may still be compelled to disclose EHI in compliance with such other law even where the exception might mean an actor's failure to comply with such other law would not be considered ``information blocking'' under 45 CFR part 171 or PHSA 3022. (The exception would not be relevant where an actor is also a HIPAA covered entity or business associate would be required to comply with the prohibition at 45 CFR 164.502(a)(5)(iii) because a HIPAA covered entity's or business associate's practice of refusing to make a use or disclosure of PHI prohibited by the HIPAA Privacy Rule is ``required by law'' and therefore not information blocking to begin with.) Finally, a policy goal of the proposed Protecting Care Access Exception is that it be easy for any actor to confidently and efficiently meet the conditions of the proposed exception. One way the exception's structure supports this goal is by providing (in Sec. 171.206(a)(3)(i)) for the actor to implement practices per organizational policies that address particular types of EHI sharing scenarios where the actor believes the risk of potential exposure to legal action could be created even if the actor has not yet received a request for EHI for the activities specified in 45 CFR 164.502(a)(5)(iii)(A) or any of the purposes specified in 45 CFR 164.512(d), (e), (f), or (g)(1) for which the attestations specified in 45 CFR 164.509 would be required as a precondition for disclosing PHI potentially related to reproductive health care to be permitted under the 2024 HIPAA Privacy Rule. As noted elsewhere, an actor's practice satisfying the new exception would mean the practice will not be considered information blocking. To the extent that EHI indicates or potentially relates to reproductive health care that was not lawful under the specific circumstances in which it was provided, we presume that the legal authority compelling disclosure of EHI for such purposes would have its own enforcement provisions independent of the penalties and disincentives authorized by PHSA 3022 for an actor determined by the HHS OIG to have committed information blocking. Because exception would not exempt the actor from their obligation to comply with such other law, we do not believe it is necessary to preserve the potential for information blocking penalties to apply in addition to any consequences that might attach under such other law to an actor's non-compliance with that law. On the other hand, we believe it is important to ensure that concern about information blocking consequences would not prevent the actor from, for example, delaying fulfillment of a demand for EHI in order to review factual information supplied by the requestor and determine whether that information ``demonstrates a substantial factual basis'' (as stated in 45 CFR 164. 502(a)(5)(iii)(C)(2)) and, by extension, whether the 2024 HIPAA Privacy Rule or applicable State law permits, preempts, or conflicts with the law the requestor indicates compels the actor to make the EHI available to the requestor.\252\ --------------------------------------------------------------------------- \252\ We remind readers that the currently codified ``pre- condition not satisfied'' sub-exception of the Privacy Exception outlines a framework for actors to follow so that the actors' practices of not fulfilling requests to access, exchange, or use EHI would not constitute information blocking when one or more preconditions has not been satisfied for the access, exchange, or use to be permitted under applicable Federal and State, or Tribal laws. Please see Sec. 171.202(b) and discussion in HTI-1 final rule (at 89 FR 1351 through 1354) of how information blocking exception work in concert with the HIPAA Rules and other privacy laws to support health information privacy. --------------------------------------------------------------------------- We are, moreover, concerned that tying the proposed Sec. 171.206(d) presumption provision to the requestor not supplying information demonstrating a substantial factual basis that the reproductive health care was not lawful under the specific circumstances in which it was provided would make the proposed Protecting Care Access Exception (Sec. 171.206) more difficult for actors to use and therefore could discourage actors from using it. We are concerned this difficulty could discourage use of the exception particularly by those actors--such as small and safety net health care providers or non-profit health information networks who serve them--who may have limited ability to divert resources to these types of legal analyses, especially in circumstances where this exception is intended to apply but the request for EHI access, exchange, or use may not be coming from a law enforcement entity and the access, exchange, or use of EHI sought may not be for a law enforcement purpose. We propose in the alternative to add to Sec. 171.206(d), if finalized, a provision that parallels the provision in 45 CFR 164.502(a)(5)(iii)(C)(2) and that would prevent the Sec. 171.206(d) presumption from applying where factual information supplied by the person requesting access, exchange, or use of EHI demonstrates a substantial factual basis that the reproductive health care was not lawful under the specific circumstances in which it was provided. We welcome comments on this alternative proposal. We are particularly interested in whether and why actors, patients, and other interested parties may believe Sec. 171.206(d) would strike a better balance between actors' interests in a simpler, more easily usable exception and requestors' interests in obtaining EHI for permissible purposes with or without the additional limit on application of the presumption provision. We propose in Sec. 171.206(e) to define ``legal action'' for purposes of the Protecting Care Access Exception. Under the proposed definition, ``legal action'' would include any of the following when initiated or pursued against any person for the mere act of seeking, obtaining, providing, or facilitating reproductive health care: (1) civil, criminal, or administrative investigation; (2) a civil or criminal action brought in a court to impose criminal, civil, or administrative liability; or (3) an administrative action or proceeding against any person. We emphasize that the proposed Protecting Care Access Exception would apply where an actor's practice meets the Sec. 171.206(a) threshold condition and at least one of the other two conditions in the exception, none of which would require the actor to quantify a degree, amount, or probability of the risk of potential exposure to legal action the actor believes in good faith exists and could be reduced by the practice to which Sec. 171.206 applies. We welcome comment on all aspects of the proposal for a new Protecting Care Access Exception to the information blocking definition.

4. Requestor Preferences Exception

We propose a new exception, ``Requestor Preferences,'' in Sec. 171.304 to offer actors certainty that, under the conditions specified in this exception, it would not be considered ``information blocking'' to honor a requestor's preferences expressed or confirmed in writing for: (1) limitations on the scope of EHI made available to the requestor; (2) the conditions under which EHI is made available to the requestor; and (3) the timing of when EHI is made available to the requestor for access, exchange, or use. Since publication of the ONC Cures Act Final Rule, actors have indicated a preference for greater certainty as to the conditions under which they would not be committing information blocking if they were to honor certain preferences expressed by a requestor seeking lawful [[Page 63640]] access, exchange, or use of EHI. In some instances, this preference might be that some type(s) of new EHI are not made available as quickly as would be technically feasible or that a more limited scope of EHI is made available than would be permitted (or required) under applicable law based on whose EHI the requestor seeks and for what purpose(s). For example, actors have indicated that they are uncertain of the scenarios when honoring an individual's request for delay of EHI availability to the individual in the patient portal would not be information blocking. Actors have also indicated that they are unable to honor a health care provider's expressed preference to receive only some of the EHI that an actor has and could disclose to the provider under applicable law, because the actor is uncertain whether honoring the health care provider's preference would be considered information blocking. The proposed exception (new Sec. 171.304) would address these concerns by providing certainty of the conditions under which we would not consider an actor to engage in information blocking when the actor honors a requestor's preference to: (1) receive only a subset of EHI (limitation on scope of EHI), (2) have the EHI be available to the requestor only under specific timing or other conditions, or (3) any combination of such preferences. We recognize that, sometimes, a requestor who seeks access, exchange, or use of EHI may prefer to have less EHI available to the requestor than an actor has and would be permitted to make available under the HIPAA Privacy Rule (and any other applicable law(s) restricting uses and disclosures of an individual's health information to protect the individual's privacy). We also recognize that sometimes a requestor may not want particular EHI to be available to the requestor immediately, perhaps preferring the EHI not be available until a certain period of time has elapsed or until certain conditions are met. For example, an individual who uses a patient portal or app to access EHI of which they are the subject may not want certain test results to be available in that patient portal or app for a certain number of hours or until the next business day (timing preference). Similarly, an individual may not want the results of certain diagnostic tests performed on the individual to be available to the individual in a patient portal or app until the doctor who ordered the test(s) has seen the results or until a doctor, nurse, or other health care professional is available who can explain what the results mean (conditions for making EHI available preference). For a provider-to- provider example, a primary-care clinician office (requestor) may ask that for laboratory tests done more than once during a patient's stay at a hospital, the hospital (actor) only send the clinician office the results from the last time each test was done (scope of EHI preference), and only send that EHI to the clinician office upon the patient's discharge from the hospital stay (a preference for the conditions under which EHI becomes available). As another provider-to- provider example, a health care provider (requestor) might ask another health care provider (actor) to not send all of the medication history the responding actor has for a patient that the actor is legally permitted to share with the requesting health care provider. The requestor might ask the responding actor to send instead only the patient's current medications and known allergies. The proposed exception (to be codified in Sec. 171.304) would address all of these examples and a variety of other situations. The proposed exception (Sec. 171.304) has four separate conditions: (a) request; (b) implementation, (c) transparency; and (d) reduction or removal. In order for an actor's practice(s) to satisfy the proposed Requestor Preferences Exception (Sec. 171.304), the practice(s) would have to meet all four of the conditions at all relevant times. The request condition (paragraph (a)) of this proposed new exception would require that the requestor express their preferences in writing without the actor improperly encouraging or inducing the requestor to ask for restrictions on the scope of EHI that would be available to the requestor, the conditions for which the EHI would be available, or timing of when EHI would be available to the requestor. This condition is similar to our approach under the Privacy Exception (Sec. 171.202) for obtaining a patient's consent under sub-exception (b), which cannot be satisfied if the actor improperly encourages or induces the individual to withhold consent or authorization. It is also similar to a provision of the Privacy Exception's sub-exception (e), which can be satisfied only if the individual requests that the actor not provide such access, exchange, or use of EHI without any improper encouragement or inducement of the request by the actor. In addition to disqualifying an actor's practices in response to such requests from application of the proposed Requestor Preferences Exception, we remind actors that any improper inducement of a patient's or other person's request for delay or other restrictions on a requestor's access to EHI is a practice that, on its own, could constitute an interference that implicates the information blocking definition. To reiterate, the request condition (Sec. 171.304(a)) requires the requestor to document in writing their preference (or ask) for tailoring of their access, exchange, or use of EHI. This requirement is intended to guard against the inappropriate citation of the exception to retroactively ``justify'' the actor's limitation of a requestor's access, exchange, and use of EHI to suit the actor's preferences. The documentation requirement parallels a similar requirement of the Privacy Exception sub-exception (Sec. 171.202(e)) applicable to honoring individuals' requests to restrict other people's access, exchange, or use of their EHI.\253\ Subparagraphs (a)(1), (2), and (3) of the proposed Sec. 171.304 request condition also specify, as discussed above, the three types of preferences that the exception would cover. --------------------------------------------------------------------------- \253\ Although we are proposing revision to Sec. 171.202(e) in this rule (see section IV.B.1.c of this preamble), we do not propose any change to the documentation requirement of the Sec. 171.202(e) sub-exception. (The Sec. 171.202(e) documentation requirement was discussed in the ONC Cures Act Final Rule; see 85 FR 25642 at 25858.) --------------------------------------------------------------------------- The implementation condition (Sec. 171.304(b)) would ensure that an actor's practice of limiting the scope of EHI, conditions or timing of EHI availability to the requestor, or any combination of such limitations a requestor may ask for, are ``tailored'' to the specific request. In this condition, ``tailored to the specific request'' means the practice is no broader than necessary to do, and in fact does, what the requestor asked for in writing. The Sec. 171.304(b) implementation condition would also require (see subparagraph (2)) that the request be implemented in a consistent and non-discriminatory manner. This requirement parallels similar requirements in existing exceptions, such as the Preventing Harm Exception (Sec. 171.201(f)(1)(iii)), Privacy Exception (Sec. 171.202(b)(1), (c)(3) and (3)), and the Security Exception (Sec. 171.203(c)). For purposes of Sec. 171.304, discriminatory implementation practices would include, for example, the actor moving more slowly to modify or remove tailoring restrictions (see proposed condition (d)) from access, exchange, or use of EHI based on whether the requestor is a business competitor of the actor or if the requestor's access, exchange, or use of EHI is likely to facilitate competition with the actor. As innovation in biomedical informatics [[Page 63641]] and health IT advances, we anticipate that the EHI a requestor needs or wants to inform decisions related to seeking or accepting healthcare, or for public health activities or providing or paying for healthcare may change. Therefore, a requestor's preferences for restrictions on the amount of EHI or the conditions or timing of EHI availability to the requestor (or any combination of these) may well change over time. The requirement that the actor's practice be consistent and non- discriminatory is intended, for example, to ensure the exception will not apply to practices that are implemented in a manner that disadvantages competitors, potential competitors, or persons whose access, exchange, or use of EHI may facilitate competition with the actor in comparison to persons who are affiliates or whose access, exchange, or use of EHI would not be expected to facilitate competition with the actor. The transparency condition (Sec. 171.304(c)) is intended to mitigate a risk of a specific unintended consequence of creating an exception that explicitly applies to an actor's choosing to agree to a requestor's ask that EHI availability to the requestor be tailored to the requestor's preferences. For example, to the surprise of the requestor, the tailoring of EHI ended up being more or less restrictive than what the requestor thought they agreed to. The risk of surprise to the requestor may arise either when a requestor first asks for tailoring or when an actor may no longer be able to maintain certain tailoring that they have previously agreed to implement in response to a requestor's ask. To mitigate the risk of surprise to a requestor, it is important for a requestor who has asked for tailoring to be informed of what the actor can and will do, or cannot or will not continue to do. To meet the transparency condition (Sec. 171.304(c)), an actor would be required to provide, in plain language, whether verbally or in writing, at least the explanation and notification described in the proposed Sec. 171.304(c)(1) and (2) and to document in writing any explanation or notice that is not made in writing. Meeting the transparency condition (Sec. 171.304(c)) would not require a contract or other formal agreement between actors and requestors. We also are not suggesting that we believe an actor's agreement to tailor when, how much, or under what conditions EHI becomes available to any given requestor should be treated as establishing a contract or binding agreement. To meet the requirement in subparagraph (1) of Sec. 171.304(c), an actor would be required to explain to the requestor what they can and will do to tailor EHI availability to the requestor. Meeting subparagraph (2) of Sec. 171.304(c) would require an actor who experiences a change in operational status or technical capabilities affecting the actor's ability to maintain tailoring to make ``reasonable efforts'' to promptly notify each requestor for whom the actor had implemented affected tailoring. We have used the ``reasonable efforts'' standard in the existing precondition not satisfied sub- exception of the Privacy Exception (see Sec. 171.202(b)(2)(i)). As we stated in the ONC Cures Act Final Rule preamble discussion of the finalized Sec. 171.202(b), a ``reasonable efforts'' standard aligns with the case-by-case approach that is captured in the statutory information blocking provision (see 85 FR 25852). Similar to the ``reasonable efforts'' standard in Sec. 171.202(b)(2)(i), the ``reasonable efforts'' standard in the proposed Sec. 171.304(c)(2) would be met if the actor used reasonable efforts within its control to promptly provide the requestor with notice of the change in the actor's ability or willingness to continue applying the tailoring of EHI availability to the requestor that the requestor had requested, and the actor had implemented or agreed to implement. (We refer those who would like to read more about the ``reasonable efforts'' standard in context of the existing Sec. 171.202(b)(2)(i) to the preamble discussion of the finalized Sec. 171.202(b)(2)(i) at 85 FR 25852). ``Plain language'' is the standard proposed in Sec. 171.304(c) for required explanations and notices rather than ``plain writing'' because we intend for the Sec. 171.304(c) transparency condition as a whole to accommodate various methods of communication that are efficient and effective for both the actor who wants to satisfy the exception and the requestor who asks for tailoring. However, regardless of whether the actor and requestor communicate verbally or in writing, plain language would use terminology familiar to the requestor and make it easy for the requestor to understand what tailoring of their EHI access, exchange, or use the requestor can expect to be implemented or to have changed.\254\ --------------------------------------------------------------------------- \254\ If an actor and a particular requestor do not both have at least limited working proficiency in any one language, the actor may need to employ a translator (whether human or an appropriate software application) to achieve communication with the requestor. --------------------------------------------------------------------------- To meet the transparency condition, subparagraph (c)(3) specifies that the actor must contemporaneously document in writing any required explanation or notice that is not provided to the requestor in writing. This requirement, like the use of ``plain language'' rather than ``plain writing'' as a standard for the explanations and notices, leaves flexibility for actors to communicate with requestors in writing, verbally, or in other ways that are efficient and effective for both the actor and requestor or otherwise mutually agreeable to them. Contemporaneous written documentation of explanations and notices not provided (initially made or later confirmed) to the requestor in writing would enable the actor to demonstrate what explanation or notice they provided and when. Contemporaneous written records of notices made or attempted would also be relevant, where notice fails to reach the requestor or the requestor does not recall details of the notice, to the actor's demonstration of the efforts the actor made to provide notice consistent with Sec. 171.304(c)(2). The reduction or removal condition (Sec. 171.304(d)) recognizes that a requestor's tailoring preferences may change over time and requires that an actor's tailoring practice accommodate such changes in requestor preferences. For the actor's practices restricting a requestor's access, exchange, or use of EHI based on the requestor's request to remain covered by this proposed exception when the requestor asks for reduction or removal of restrictions, the reduction or removal condition (Sec. 171.304(d)) would require the actor to act promptly as feasible on that request. We do not propose to set a specific timeframe within which an actor would need to act on requests to reduce or remove restrictions upon receipt of any such request from the requestor. Rather, to satisfy the reduction or removal condition, the actor would need to act as promptly as feasible upon receiving such a request. Basing this requirement on what is feasible for the actor allows for consideration of the specific facts and circumstances under which the actor received the request. We believe this is preferable to setting a single fixed timeframe due to the considerable variation in actors' technical capabilities and operational circumstances at any given point in time. However, we recognize that actors and individuals may find some value in consistent maximum timeframe expectations for acting on a requestor's ask for removal or reduction of previously requested restrictions on their access, exchange, or use of EHI in individual access scenarios. (By ``individual access scenarios,'' we mean here those where the requestor is either: (a) the individual [[Page 63642]] who is the subject of the EHI in question; or (b) their legal representative, including, but not limited to, personal representatives treated as the individual consistent with 45 CFR 164.502(g)). Therefore, we are considering specifying in Sec. 171.304(d) that the maximum time any actor would have to reduce or remove the tailoring in any individual access scenario would be the time within which a HIPAA covered entity must provide an individual (as defined in 45 CFR 160.103) or their personal representative (see 45 CFR 164.524(g)) access to PHI in the designated record set under 45 CFR 164.524. Under this alternative proposal, the ``as promptly as feasible'' standard would apply to all other requestor scenarios without a specified maximum limit on the time an actor could take; but meeting the proposed Sec. 171.304(d) reduction or removal condition in individual access scenarios would require the actor to reduce or remove restrictions in response to the requestor's request as promptly as feasible but in no case later than the maximum time permitted to fulfill individual access requests under 45 CFR 164.524. (This is an alternative proposal that is not reflected in the draft of Sec. 171.304 in the ``Regulatory Text'' section of this proposed rule.) This alternative proposal for Sec. 171.304(d) requirements would apply to individual access scenarios regardless of whether 45 CFR 164.524 would, in any given scenario, be implicated (e.g., even if the actor were not a HIPAA covered entity or business associate). This alternative proposed timeliness requirement for the Sec. 171.304(d) reduction or removal condition specific to individual access scenarios would establish, by cross-reference to 45 CFR 164.524, that the maximum time the actor would have for acting on a request to reduce or remove restrictions would be the same timeframe within which a HIPAA covered entity must fulfill individual access under 45 CFR 164.524. For purposes of the Sec. 171.304 exception under this alternative proposal, the time for responding to a request for reduction or removal of EHI access, exchange, or use tailoring in individual access scenarios would start on the date on which the actor receives the individual's (or their legal representative's) request for reduction or removal of tailoring. We would craft this additional requirement in this manner specifically so that, in the event the 45 CFR 164.524 timeliness standard were to change in the future (see, for example, the proposal to modify that standard at 86 FR 6459 and 6535), the Sec. 171.304(d) condition would apply the same timeframe in effect for 45 CFR 164.524 at the point in time when an individual who is the subject of the EHI (or their legal representative) requested removal or reduction of restrictions on the individual's (or the legal representative's) EHI access. Such requests are, effectively, the requestor requesting their EHI be made available more promptly or completely than they had previously requested it be available to them. For clarity, once the reduction or removal of tailoring is complete for purposes of this proposed exception, all future requests for access, exchange, or use of EHI previously affected by the reduced or removed tailoring could implicate the interference and information blocking definition particularly Sec. Sec. 171.103 and 171.104 (new proposed section). If we finalize the proposed Sec. 171.304 exception, with or without any explicit cross-reference to 45 CFR 164.524, this exception would operate as do all other 45 CFR part 171 exceptions: independently from the HIPAA Privacy Rule. We reiterate that an actor who is also a HIPAA covered entity or business associate must comply with the HIPAA Privacy Rule's requirements implicated in any circumstances or scenario, including without limitation the individual right of access (45 CFR 164.524(a)(1)), regardless of whether any given practice in any given scenario might not be considered ``information blocking'' on the basis of having satisfied any 45 CFR part 171 exception(s) to the definition codified in Sec. 171.103. We welcome comment on this proposed new exception.

5. Exceptions That Involve Practices Related to Actors' Participation

in The Trusted Exchange Framework and Common Agreement\TM\ (TEFCA\TM\) In the HTI-1 Proposed Rule (88 FR 23872), we proposed to add a TEFCA\TM\ manner condition to the proposed revised and renamed Manner Exception. We stated that this approach ``aligns with the Cures Act's goals for interoperability and the establishment of TEFCA by acknowledging the value of TEFCA in promoting access, exchange, and use of EHI in a secure and interoperable way'' (88 FR 23872). In the HTI-1 Final Rule (89 FR 1437), in Part 171, we finalized a new subpart D ``Exceptions That Involve Practices Related to Actors' Participation in The Trusted Exchange Framework and Common Agreement (TEFCA).'' We noted that the new subpart consists of three sections, Sec. 171.400 ``availability and effect of exceptions,'' which mirrors Sec. Sec. 171.200 and 171.300, stating that a practice shall not be treated as information blocking if the actor satisfies an exception to the information blocking provision as set forth in subpart D by meeting all applicable requirements and conditions of the exception at all relevant times (89 FR 1388). We reserved Sec. 171.401 for definitions in a future rulemaking, and also reserved Sec. 171.402 for future use. In Sec. 171.403 we finalized a new TEFCA Manner Exception based on the TEFCA manner condition we proposed in HTI-1 Proposed Rule. a. Definitions We stated that while we reserved Sec. 171.401 for possible future use as a ``definitions'' section, we declined to finalize any definitions in the HTI-1 Final Rule and instead 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, when we refer to Framework Agreement(s), we mean 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. We now propose to include definitions in Sec. 171.401 by cross- referencing the TEFCA definitions included in the proposed new 45 CFR part 172, ``Trusted Exchange Framework and Common Agreement'' (see section IV.B.5.a of this proposed rule). We specifically propose to adopt in Sec. 171.401 the definitions from Sec. 172.102 for the following terms: Common Agreement, Framework Agreement, Participant, QHIN\TM\, and Subparticipant. The definitions would apply to all of Subpart D. We welcome comment on this approach. b. TEFCA\TM\ Manner Exception As briefly discussed above, we finalized a new TEFCA Manner Exception in the HTI-1 Final Rule. We stated that the new TEFCA Manner Exception (Sec. 171.403) provides that an actor's practice of limiting the manner in which it fulfills a request to access, exchange, or use EHI to be providing such access, exchange, or use to only via TEFCA will not be considered information blocking when it follows certain conditions (89 FR 1388). Those conditions require that (1) the actor and requestor both be part of TEFCA; (2) that [[Page 63643]] the requestor is capable of such access, exchange, or use of the requested EHI from the actor via TEFCA; and (3) any fees charged by the actor and the terms for any license of interoperability elements granted by the actor in relation to fulfilling the request are required to satisfy, respectively, the Fees Exception (Sec. 171.302) and the Licensing Exception (Sec. 171.303). In addition to these three requirements, we also included a limitation in Sec. 171.403(c), stating that the exception is available only if the request is not made via the standards adopted in 45 CFR 170.215, which include the FHIR API standards. 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 Exceptions 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 (See 88 FR 23872)'' (89 FR 1389). 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, some commenters expressed concern that because the Common Agreement prohibits fees between QHINs\TM\ but is otherwise silent on fees between Participants and Subparticipants, the proposal could allow actors to charge fees to access, exchange, or use EHI that did not comply with the Fees or Licensing Exceptions. Some commenters also expressed that this could have the effect of disincentivizing participation in TEFCA, and could cause actors to use other options of electronic exchange outside of TEFCA, where the actors believed the Fees and Licensing Exceptions would apply. As such, in the HTI-1 Final Rule, we finalized the TEFCA Manner Exception to include that any fees charged by the actor, and any licensing of interoperability elements, must satisfy the Fees Exception (Sec. 171.302) and the Licensing Exception (Sec. 171.303) (89 FR 1389). While we continue to believe that it was clear that the alternative would be to apply the exceptions, we are requesting comment now on whether there are drawbacks to applying the Fees and Licensing Exceptions, and if we should continue to apply them to the TEFCA Manner Exception as currently required in Sec. 171.403(d). 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 through 91). Commenters further noted that this potential outcome could undermine our stated purpose in incentivizing TEFCA participation with the new exception (See 89 FR 1390). We now solicit comment on this limitation within the TEFCA Manner Exception for requests via FHIR API standards. For example, should the limitation 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''? Currently, the limitation would only cover requests made via FHIR API standards codified in Sec. 170.215, including standards that may be updated from time to time through Sec. 170.405(b)(8), which may involve a delay before the version is formally approved under Standards Version Advancement Process (SVAP). We also seek comment on a different approach. 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. One option would be to sunset the limitation in Sec. 171.403(c) once all QHINs can support brokered FHIR. Another option would be to sunset the limitation in Sec. 171.403(c) if all QHINs, Participants and Subparticipants support facilitated FHIR exchange. As an alternative to these options, we could maintain the exception as is, regardless of FHIR API adoption among TEFCA entities. We request comment on all of the options, including whether or not the limitation should remain as it is currently.

A. Subpart A--General Provisions

For the purposes of subpart A, we propose in Sec. 172.100 the basis, purpose, and scope for the proposed TEFCA provisions in part 172 of Title 45 of the Code of Federal Regulations. We propose in Sec. 172.100(a) that the basis for these provisions would be to implement section 3001(c)(9) of the PHSA (42 U.S.C 300jj-11(c)(9)). We propose in Sec. 172.100(b) the dual purposes of proposed part 172: (1) to ensure full network-to-network exchange of health information; and (2) to establish a voluntary process for QHINs to attest to adoption of the Trusted Exchange Framework and Common Agreement. Section 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. Section 172.100(b)(2) supports the statutory basis because it implements PHSA Sec. 3001(c)(9)(D). We propose in Sec. 172.100(c) the scope for part 172, which would include: (1) minimum qualifications needed to be Designated as a QHIN capable of trusted exchange under TEFCA; (2) procedures governing QHIN Onboarding and Designation, suspension, termination, and further administrative review; (3) attestation submission requirements for a QHIN to attest to its adoption of TEFCA; and (4) ONC attestation acceptance and removal processes for publication of the list of attesting QHINs in the QHIN Directory. In proposed Sec. 172.101, we specify the applicability of part 172 by proposing that part 172 would apply only to Applicant QHINs, QHINs, and terminated QHINs. We note that our proposed QHIN definition in Sec. 172.102 captures suspended QHINs (since a suspended QHIN is still a QHIN) and so we do not address them separately in proposed Sec. 172.101. In Sec. 172.102, we propose definitions for certain terms in part 172. We intend for the definitions provided in the Common Agreement to be consistent with these proposed definitions. Differences in phrasing would generally be attributable to differences in context, though in the case of any true conflict, we would intend for the regulatory definitions to control. Additionally, ONC has hired a contractor to help administer and implement TEFCA Exchange. This contractor, chosen through a competitive solicitation, is known as the Recognized Coordinating Entity[supreg] (RCE\TM\). While the RCE is currently one entity, in the future, ONC may choose to assign some or all of its responsibilities to a different entity or multiple entities. Assigning to a different or multiple entities in the future could, for example, allow for more efficient use of resources or best leverage expertise. In Sec. 172.103, ``Responsibilities ONC may delegate to the RCE,'' we propose that ONC may assign certain responsibilities to such an entity or entities for these purposes. Specifically, we propose in Sec. 172.103(a)(1)-(4) that ONC may assign any of its responsibilities in Subpart C--QHIN Onboarding and Designation Process; Subpart D--Suspension, Sec. 172.501 QHIN self-termination, and Sec. 172.503 Termination by mutual agreement. In Sec. 172.103(b), we propose that any authority exercised by the RCE under this section is subject to review by ONC under Subpart F (``Review of RCE Decisions''). For further discussion of the current RCE and the authority it exercises on behalf of ONC, please see the discussion in ``C. Subpart C--QHIN Onboarding and Designation Processes'' below.

B. Subpart B--Qualifications for Designation

In subpart B, we propose qualifications for Designation. In Sec. 172.200, we propose to tie QHIN status to meeting the requirements specified in Sec. 172.201. We propose that an Applicant QHIN (as we propose to define it in Sec. 172.102) would need to meet all requirements in Sec. 172.201 to be Designated, and a QHIN would need to continue to meet all requirements in Sec. 172.201 to maintain its Designation. That means that the requirements we propose in Sec. 172.201 would be ongoing; a QHIN that does not meet those requirements at all times would be subject to suspension or termination, consistent with the regulations we propose in subparts D and E of part 172. Among other benefits, the continuing obligation to meet the requirements in Sec. 172.201 would help to ensure the reliability of TEFCA Exchange and to ensure QHINs could not maintain their status based on technology and standards that have become obsolete. Because the obligations would be [[Page 63645]] ongoing, throughout this section we refer to Applicant QHINs as well as Designated QHINs as ``QHINs'' unless there is a need to differentiate. As we explain below, the Designation qualifications proposed in Sec. 172.201 would describe certain requirements for Designation. For an entity to become a QHIN, that entity must sign the Common Agreement, thus memorializing its agreement to the comprehensive Designation requirements--as well as other requirements--for trusted exchange under TEFCA. The comprehensive Designation requirements in the Common Agreement correspond to the proposed requirements included in this subpart. In Sec. 172.201, we propose Designation requirements in three categories: (a) ownership; (b) exchange requirements; and (c) Designated Network Services. In Sec. 172.201(a), we propose the ownership requirements. In Sec. 172.201(a)(1), we propose that a QHIN must be a U.S. Entity, as we propose to define U.S. Entity/Entities in Sec. 172.102. Under that proposed definition, a U.S. Entity must be a corporation, limited liability company, partnership, or other legal entity organized under the laws of a State or commonwealth of the United States or the Federal law of the United States, be subject to the jurisdiction of the United States and the State or commonwealth under which it was formed, and have its principal place of business be in the United States under Federal law. Additionally, we propose 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. 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 request comment on whether the above approach, including the specific five percent (5%) threshold, will effectively limit access of bad actors trying to join TEFCA as a QHIN, or whether commenters believe the threshold should be a different percentage. In Sec. 172.201(a)(2), we propose that an Applicant QHIN must not be under Foreign Control, which is a term we propose to define in Sec. 172.102. If, in the course of reviewing a QHIN application, ONC believes or has reason to believe the Applicant QHIN may be under Foreign Control, ONC will 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 believe that a QHIN should not be under Foreign Control. We believe the requirements proposed in Sec. 172.201(a)(1) and (a)(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, these proposals are designed to strengthen the security of the network. We believe that the above proposals 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. We note that within the proposed definition of U.S. Entity/Entities in Sec. 172.102, we propose 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 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. 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. We believe that entities--particularly those with a large number of shareholders--would face undue hardship without this sort of exception for small shareholders. That said, this regulation only would provide the standard that ONC will apply when evaluating QHINs; it would not supersede any stricter requirements imposed by other applicable laws, including, for example national security laws. It remains the responsibility of QHINs (and any other entity) to comply with all applicable laws. In Sec. 172.201(b), we propose exchange requirements for QHINs. We believe these exchange requirements are necessary to build a data sharing infrastructure that is private and secure and that meets all the requirements of PHSA section 3001(c)(9). We believe each of the exchange requirements below is important to the implementation and operationalization of TEFCA Exchange, as described in Sec. 172.201, at scale. We propose 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 Sec. 172.102); (3) be exchanging information for at least one of the Exchange Purposes (as that term is defined in Sec. 172.102) authorized, in the Common Agreement or an SOP(s) n; (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. Collectively, we believe these requirements are tailored to help ensure that a QHIN is capable of TEFCA Exchange, supports a trusted exchange framework, and maintains consistent practices of exchanging information at scale to support nationwide interoperability. The first requirement, proposed in Sec. 172.201(b)(1), that the entity seeking to become a QHIN be capable of exchanging information among more than two unaffiliated organizations, is a requirement that would ensure a minimum technical ability exists and that exchange would be enabled beyond just the QHIN itself. [[Page 63646]] The second requirement, proposed in Sec. 172.201(b)(2), is also a minimum condition, except it is directed at the minimum quantity of data a QHIN must be capable of exchanging. This proposed requirement would ensure that every QHIN can exchange Required Information (as that term is defined in Sec. 171.102), and provides certainty to Participants and Subparticipants who seek to join a QHIN that there is a minimum scope of data that they can reliably expect to be able to exchange via TEFCA Exchange Purposes. The proposed requirements in Sec. 172.201(b)(3) through (5) are intended to establish basic parameters and expectations for QHINs in order to qualify for Designation. We propose, in Sec. 172.201(b)(3), that a QHIN or Applicant QHIN must be exchanging information for at least one Exchange Purpose. If a QHIN is not exchanging information for at least one of the Exchange Purposes authorized under TEFCA (for examples, see the ``Exchange Purpose'' definition in Sec. 172.102) at the time of application, 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 propose in Sec. 172.201(b)(4) to require a QHIN to be capable of receiving and responding to transactions from other QHINs for all Exchange Purposes, to ensure that health information can be exchanged among health information networks under TEFCA. For this same reason, we propose in Sec. 172.201(b)(5) to require a QHIN to be capable of initiating transactions for the Exchange Purposes that such entity will permit its Participants and Subparticipants to use through TEFCA Exchange. 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. 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. Without this requirement, there would be no certainty that the TEFCA framework would advance exchange beyond the Treatment Exchange Purpose, which is the most prevalent purpose for health information exchange today and the purpose of use that most health care entities seeking Designation would be most familiar with. TEFCA's network connectivity, including this requirement that QHINs have the ability to exchange for all Exchange Purposes, and scale would help, for example, health care providers gain access to more comprehensive and complete information about their patients, which can support improved care, better outcomes, decreased provider burden, and reduced costs. Entities performing TEFCA Exchange as described in Sec. 172.201 will have the option to request information for all Exchange Purposes. At the time of publication of this Proposed 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 will be included in a TEFCA standard operating procedure. In Sec. 172.201(c), we propose that an Applicant QHIN must meet certain Designated Network Services requirements. Based on our experience in the health IT ecosystem, 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. Unreliable network performance would dilute confidence in the network and discourage participation. In Sec. 172.201(c)(1), we propose that a QHIN must maintain the organizational infrastructure and legal authority to operate and govern its Designated Network. For instance, under this proposal, QHINs would be required to have a representative and participatory group or groups that approve the processes for fulfilling the TEFCA governance functions and that participate in governance for the Designated Network. In Sec. 172.201(c)(2), we propose that a QHIN must maintain adequate written policies and procedures to support meaningful TEFCA Exchange as described in Sec. 172.201 and fulfill all responsibilities of a QHIN in this 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 enables TEFCA Exchange. In Sec. 172.201(c)(3), we propose that a QHIN must maintain a Designated Network (as proposed to be defined in Sec. 172.102) that can support a transaction volume that keeps pace with the demands of network users. Since TEFCA is a nationwide network and will be used daily to support various health data needs to inform care delivery, quality assessments, public health, and health care operations, QHINs must be capable of transacting high volumes of data reliably and at scale. In Sec. 172.201(c)(4), we propose 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, is important to include in this regulation. In Sec. Sec. 172.201(c)(5)-(7), we propose certain requirements related to governance for TEFCA to ensure all QHINs are aligned and able to manage risk effectively. In Sec. 172.201(c)(5), we propose 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. Disputes may arise for a variety of reasons, so the QHIN, as the entity overseeing its Participants, is best placed to handle such disputes in a way that minimizes disruptions for the rest of the network. Ensuring that a QHIN has such a dispute resolution policy would, therefore, likely minimize such disruptions. Similarly, in Sec. 172.201(c)(6), we propose that a QHIN maintain an enforceable change management policy consistent with its responsibilities as a QHIN. A change management policy establishes the standard procedures to approve different types of changes to TEFCA documents (e.g., standard operating procedures) and policies and will help to avoid changes that are disruptive or in conflict across entities. In Sec. 172.201(c)(7), we propose that a QHIN must maintain a representative and participatory group or groups with the [[Page 63647]] authority to approve processes for governing the Designated Network. The participatory network governance built into the TEFCA infrastructure is important to ensure that the requisite engagement exists between QHINs, Participants, and Subparticipants participating in TEFCA Exchange. 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. Regarding the proposed requirement in Sec. 172.201(c)(7) specifically, we emphasize 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. Such a governance structure helps to motivate health care entities and their networks to voluntarily join TEFCA. We believe that requiring a QHIN to have a representative and participatory group or groups that has the ability to review and provide input on the governance requirements of the QHIN's Designated Network is an optimal approach for this requirement. In Sec. 172.201(c)(8), we propose that an entity seeking to become a QHIN must maintain privacy and security policies that permit the QHIN to support TEFCA Exchange. These policies currently include, but are not limited to, 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), that reviews the QHIN's HIPAA Security Rule risk analysis (consistent with Sec. 164.308(a)(1)(ii)(A)), and verifies all requirements for technical audits and assessments are met. Having a qualified, independent third party complete an annual security assessment consistent with the NIST Cybersecurity Framework (CSF) (using both NIST 800-171 (Rev. 2) and NIST 800-53 (Rev. 5) as a reference). The third party would review the QHIN for compliance with HIPAA Security Rule risk analysis requirements consistent with Sec. 164.308(a)(1)(ii)(A). Additionally, the annual security assessment must include comprehensive internet-facing penetration testing, must include an internal network vulnerability assessment, and must use methodologies and security controls consistent with Recognized Security Practices, as defined by Public Law No: 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; and Maintaining and complying with a written privacy policy. These policies and requirements will 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 not regulated under HIPAA, will be expected to meet a high bar for privacy and security given the nature of the data being exchanged. Further, the policies would advance TEFCA exchange by making it clear to those interested in participating that privacy and security measures are in place. 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 propose in Sec. 172.201(c)(9), that a QHIN must maintain data breach response and management policies that support secure TEFCA Exchange. For instance, given the number of electronic connections TEFCA will support, a data breach response and management policy would support a transparent process and timely awareness of a data breach or other security events (e.g., ransomware attacks) which could enable the QHIN to manage secure connectivity services without disrupting patient care. These proposed policies and requirements reflect the available privacy and security standards. In Sec. 172.201(c)(10), we propose 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. This requirement will 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, 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 note that the requirements proposed here may be insufficient for larger QHINs, and recognize 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 propose, in Sec. 172.201(c)(10), that QHINs must have sufficient financial resources and personnel capacity to perform such functions successfully. We also 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. One goal of TEFCA is to support patients gathering their healthcare information. In Sec. 172.202, ``QHINS that offer individual access services,'' we propose Individual Access Services (IAS) requirements for a QHIN to obtain and maintain Designation under TEFCA if that QHIN voluntarily offers IAS. In Sec. 172.202(a), we propose that a QHIN would be required to obtain express consent from any individual before providing IAS, as defined in Sec. 172.102. We believe this is an important requirement so that individuals who use IAS that a QHIN offers are informed of the privacy and security practices that are being employed to protect their data. In Sec. 172.202(b), we propose 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 believe this requirement would provide transparency to all individuals who are considering using IAS regarding how their data is protected and secured by a QHIN providing IAS. In Sec. 172.202(c), we propose a QHIN that is the IAS provider for an individual, would be required to delete the individual's Individually Identifiable Information (as defined in Sec. 172.102) maintained by the QHIN upon request by the individual except as prohibited by Applicable Law or where such information is contained in [[Page 63648]] audit logs. We believe this requirement would provide individuals with reassurance that they control access to their data. We believe the carve out for audit logs is appropriate because audit logs are generally used to provide chronological records of system activities and should not be deleted. In Sec. 172.202(d), we propose 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 believe this requirement would ensure that individuals may access, control, and use their own data held by an IAS provider. In Sec. 172.202(e), we propose 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 note that to the extent the QHIN is already required by Applicable Law to notify an individual as described in proposed Sec. 172.202(e)(2), we are not proposing that it be required to duplicate such a notification. Lastly, the proposed requirement in Sec. 172.202(e)(3) would set a baseline for proving the identity of IAS users that are requesting data via TEFCA Exchange. In some ways, IAS providers--should we finalize these proposals in Sec. 172.202--would meet requirements above and beyond what the HIPAA Rules require of covered entities or business associates, including providing individuals with the right to delete their data and a requirement to encrypt all Individually Identifiable Information, as we propose in Sec. 172.202(c) and Sec. 172.202(e)(1). Encryption is an industry standard practice to protect data, and we believe the requirement we propose in Sec. 172.202(e)(1) would create strong security of data while not creating undue burden to implement. We believe these proposed requirements are important because IAS providers will not always be HIPAA covered entities or business associates. Establishing these IAS requirements would ensure that QHINs that are IAS providers will meet certain minimum privacy and security requirements to protect patient data while also advancing the goal of improving patients' ability to access their data. We welcome comments on the proposed qualifications and requirements in this subpart.

C. Subpart C--QHINTM Onboarding and Designation Processes

TEFCA establishes a universal floor for interoperability across the country through a network of networks. In 2019, ONC issued a Notice of Funding Opportunity and subsequently awarded a cooperative agreement to The Sequoia Project to serve as the RCE to support the implementation of TEFCA. In August 2023, ONC awarded The Sequoia Project a five-year contract to continue serving as the RCE. To establish nationwide health information exchange, TEFCA calls for the Designation of QHINs--HINs that agree to the common policy, functional, and technical requirements for TEFCA Exchange. The QHIN Designation Requirements as described in Sec. 172.201 define the baseline legal and technical requirements for secure information sharing on a nationwide scale--all under commonly agreed-to rules. Exchange through TEFCA simplifies connectivity and creates efficiency by establishing a standardized approach to exchange policies and technical frameworks. Under the 2019 to 2023 cooperative agreement \256\ and the current RCE contract,\257\ 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. --------------------------------------------------------------------------- \256\ 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. \257\ See USASPENDING.gov, https://www.usaspending.gov/award/CONT_AWD_75P00123C00019_7570_-NONE-_-NONE-. --------------------------------------------------------------------------- In subpart C of part 172, we describe the proposed QHIN Onboarding and Designation processes. Onboarding, as we propose to define it in Sec. 172.102, is the process a prospective QHIN must undergo to become a QHIN and become operational in the production environment.\258\ Designation, on the other hand, we propose to define in Sec. 172.102, as the written determination that an Applicant QHIN has satisfied all regulatory requirements and is now a QHIN.\259\ --------------------------------------------------------------------------- \258\ 87 FR 2822. \259\ 87 FR 2818. --------------------------------------------------------------------------- In Sec. 172.300, we explain that subpart C of part 172 would establish, for QHINs, the application, review, Onboarding, withdrawal, and redetermination processes that ONC will follow for Designation. Establishing these processes will ensure that ONC (or an RCE) takes a consistent approach to QHIN Onboarding and Designation. The first step in becoming a QHIN under TEFCA is submission of an application. In Sec. 172.301, we propose to establish the information Applicant QHINs must submit in order to be Designated as a QHIN. We propose that an Applicant QHIN must submit: (1) a completed QHIN application; and (2) a signed copy of the Common Agreement. Regarding the first proposed requirement, in Sec. 172.301(a), the application may be updated over time and the most recent version will be available on ONC's and the RCE's website. The application will specify what supporting documentation an Applicant QHIN must submit. We propose the second requirement in Sec. 172.301(b) because the Applicant QHIN would sign the Common Agreement upon application, but the RCE would only countersign and create a binding agreement with the Applicant QHIN once the Applicant QHIN completes Onboarding and is Designated. The next step to becoming a QHIN is application review. In Sec. 172.302, we propose a process, with required timelines and allowable extensions, for ONC (or an RCE) to review applications. We propose in Sec. 172.302(a) that, on receipt of an application, ONC (or an RCE) will review the application to determine if the Applicant QHIN has completed all parts of the application and provided the necessary supporting documentation. Further, we propose that, if the QHIN Application is not complete, ONC (or an RCE) will notify the applicant in writing of the missing [[Page 63649]] information within thirty (30) calendar days of receipt of the application. Last, we propose that ONC (or an RCE) may extend this period by providing written notice to the Applicant QHIN. We note that ``written notice'' throughout part 172 would include notice provided by email to the points of contact the Applicant QHIN listed in their application. We believe the above timeframe and allowable extensions would allow ONC (or an RCE) enough time to perform a thorough review of each application and ensure that ONC (or an RCE) is provided with the responses and supporting documentation needed to assess the merits of an application. We believe the 30-day review timeframe--along with the ability of ONC (or an RCE) to extend this period by providing written notice to the Applicant QHIN--strikes the right balance between moving an application forward as quickly as possible while still providing ONC (or an RCE) with enough time to conduct a review of the application to ensure it is complete and contains all the required material. We propose in Sec. 172.302(b) that once the QHIN application is complete, ONC (or an RCE) will review the application to determine whether the Applicant QHIN satisfies the requirements for Designation set forth in Sec. 172.201, and, if the Applicant QHIN proposes to provide IAS, the requirements set forth in Sec. 172.202. We propose this step to make clear that ONC (or an RCE) will review an application not only for completeness but also to determine if the qualifications are met. We also propose ONC (or an RCE) would complete its review within sixty (60) calendar days of providing the Applicant QHIN with written notice that its application is complete. We further propose that ONC (or an RCE) may extend this period by providing written notice to the Applicant QHIN. We believe that sixty (60) calendar days will generally be an adequate amount of time to conduct a thorough, comprehensive review of the substance of the application. However, we are cognizant that there may be complex applications that require additional time for review and have, therefore, proposed that ONC (or an RCE) may extend this period by providing written notice to the Applicant QHIN. We propose in Sec. 172.302(c) that ONC (or an RCE) may contact the Applicant while the application is being reviewed to request additional information. ONC (or an RCE) will provide the timeframe for responding to its request and the manner to submit additional information, which may be extended on written notice to the Applicant QHIN. We believe this provision would be beneficial because the Applicant QHIN will need to provide detailed responses that may be complex and will vary among Applicant QHINs. We anticipate there will often need to be a discussion between ONC (or an RCE) and the Applicant QHIN to reach a resolution and shared understanding. This provision would provide for this vital communication between ONC (or an RCE) and the Applicant QHINs. We propose that an Applicant QHIN must respond to ONC (or an RCE) within the timeframe ONC (or an RCE) identifies because ONC (or an RCE) will be in the best position to understand the complexity of the question and estimate a reasonable amount of time for the Applicant QHIN to respond. That said, we understand that each application, as well as the questions associated with each application, will vary significantly on a case-by-case basis and, therefore, are proposing that ONC (or an RCE) may extend the timeframe by providing written notice to the Applicant QHIN. We believe this approach creates appropriate flexibility regarding timing of Applicant QHIN responses, while still leaving the discretion to decide the need for and length of such extensions. We propose in Sec. 172.302(d) that failure to respond to a request within the proposed timeframe, or in the manner specified, is a basis for a QHIN Application to be deemed withdrawn, as set forth in Sec. 172.305(c)). In such situations, we propose that ONC (or an RCE) would provide the Applicant QHIN with written notice that application has been deemed withdrawn. We believe this requirement is important to support an efficient application process and to ensure that Applicant QHINs respond to requests in a timely manner. We reiterate that under proposed Sec. 172.302(c), as discussed above, the ONC (or an RCE) can extend the timeframe for responding to a request for information. An Applicant QHIN should request an extension if it does not believe it can meet the proposed response timeframe. We propose in Sec. 172.302(e) that if, following submission of the application, any information submitted by the Applicant QHIN becomes untrue or materially changes, the Applicant QHIN must notify ONC (or an RCE), in the manner specified by ONC (or an RCE), of such changes in writing within five (5) business days of the submitted material becoming untrue or materially changing. This proposed requirement takes into consideration the possibility that, over the course of ONC's (or an RCE's) review of an application, an Applicant QHIN's circumstances or information provided with the Applicant QHIN's application may change. This provision would ensure that if such changes occur, the Applicant QHIN would promptly notify ONC (or an RCE) of such changes. We believe, based on ONC's experience with health IT implementation and coordination efforts, that five (5) business days is enough time for the Applicant QHIN to notify ONC (or an RCE) of the change(s). In Sec. 172.303, we propose requirements related to QHIN approval and Onboarding. We propose in Sec. 172.303(a) that an Applicant QHIN would have the burden of demonstrating its compliance with all qualifications for Designation in Sec. 172.201, and, if the Applicant QHIN proposes to provide IAS, the qualifications in Sec. 172.202. We propose in Sec. 172.303(b) that if ONC (or an RCE) determines an Applicant QHIN meets the requirements for Designation set forth in Sec. 172.201, and, if the Applicant QHIN proposes to provide IAS, the qualifications set forth in Sec. 172.202, then ONC (or an RCE) will notify the Applicant QHIN in writing that it has approved its application, and the Applicant QHIN can proceed with Onboarding. These proposed requirements are important for ensuring that the Applicant QHIN is notified of its status and support the transparency and efficiency of the Onboarding process. We propose in Sec. 172.303(c) that an approved Applicant QHIN would be required to submit a signed version of the Common Agreement within a timeframe set by ONC (or an RCE). This proposed provision is important in addition to Sec. 172.301(b) (which would require an Applicant QHIN to submit a signed version of the Common Agreement when applying) to ensure that, if the Common Agreement changes between the time the QHIN applies and when it is approved, the QHIN will have signed the most recent version. We did not propose a specific timeframe for submission, and instead propose to allow ONC (or an RCE) to set the timeframe for each Applicant QHIN, since we believe each timeframe should be tailored to the needs of the Applicant QHIN and the complexity of each application. We propose in Sec. 172.303(d) that an approved Applicant QHIN must complete the Onboarding process set forth by ONC (or an RCE), including any tests required by ONC (or an RCE) to ensure the Applicant QHIN's network can connect to those of other QHINs, within twelve (12) months of approval of the QHIN application, unless that [[Page 63650]] time is extended in ONC's (or an RCE's) sole discretion by up to twelve (12) months. Based on ONC's experience with health IT implementation and discussions with the current RCE, we believe the proposed twelve (12) month timeframe is sufficient time for approved Applicant QHINs to complete the Onboarding process including any tests with QHINs and other Applicant QHINs. We believe that timeframe strikes an appropriate balance between the need to onboard QHINs promptly and the need to ensure that all QHINs can connect immediately and seamlessly once Designated. We note that during the Onboarding process, the Applicant QHIN would have regular check-ins with ONC (or an RCE) to monitor the progress on any outstanding requirements, to coordinate technical testing, and to address any issues that could put the Applicant QHIN in jeopardy of failing to meet the proposed Onboarding timeframe detailed above. In Sec. 172.304, we propose the specific procedural requirements for the Designation of QHINs. In Sec. 172.304(a), we propose the process that would follow an Applicant QHIN's satisfaction of the Onboarding process requirements. We propose that once the Onboarding process requirements are satisfied, the Common Agreement would be countersigned and the Applicant QHIN would receive a written determination indicating that it had been provisionally Designated as a QHIN, along with a copy of the countersigned Common Agreement. In Sec. 172.304(b), we propose that within thirty (30) calendar days of receiving its written determination of provisional Designation, each QHIN would be required to demonstrate in a manner specified by ONC (or an RCE) that it has completed a successful transaction with all other in-production QHINs according to standards and procedures for TEFCA Exchange. This proposed provision is important because it would ensure that a Designated QHIN is able to exchange information with other QHINs, which is a core function of QHINs. We believe that the thirty (30)-day timeframe will afford a Designated QHIN ample time to move from testing to production. We also believe that the standards and procedures for such exchanges should remain flexible such that ONC (or an RCE) may update the requirements from time to time as appropriate. We propose in Sec. 172.304(c) that if a QHIN is unable to complete the requirement in Sec. 172.304(b), described above, within the thirty (30)-day period provided, the QHIN would be required to provide to ONC (or an RCE) with a written explanation as to why the QHIN is unable to complete the requirement within the allotted time and include a detailed plan and timeline for completion of the requirement. We propose that ONC (or an RCE) will then review and approve or reject the QHIN's plan, basing its decision on the reasonableness of the explanation based on the specific facts and circumstances, within five (5) business days of receipt. We propose that if the QHIN fails to provide ONC (or an RCE) its plan or ONC (or an RCE) rejects the QHIN's plan, ONC (or an RCE) will rescind its approval of the application, rescind the provisional QHIN Designation, and deny the application. We believe these proposals would provide QHINs with the appropriate flexibility to request an extension if the circumstances do not allow the QHIN to meet the timeline. We believe the proposed five (5)- business day timeframe would provide ONC (or an RCE) with enough time to review the request and reach a decision regarding the request based on the information provided. We propose that within thirty (30) calendar days of the end of the term of the plan, each QHIN must demonstrate in a manner specified by ONC (or an RCE) that it has completed a successful transaction with all other in-production QHINs according to standards and procedures for TEFCA Exchange. We believe that the thirty (30)-day timeframe will afford a Designated QHIN ample time to move from testing to production. In Sec. 172.304(d), we propose that a QHIN Designation will become final sixty (60) days after a Designated QHIN has submitted its documentation, in a manner specified by ONC (or an RCE), that it has completed a successful transaction with all other in-production QHINs. This proposal will allow ONC (or an RCE) to exercise its ability to review a Designation. In Sec. 172.305, we propose requirements related to withdrawal of an application. In Sec. 172.305(a), we propose that an Applicant QHIN may withdraw its application by providing ONC (or an RCE) with written notice in a manner specified by ONC (or an RCE). In Sec. 172.305(b), we propose that an Applicant QHIN may withdraw its application at any point prior to Designation. In Sec. 172.305(c), we propose that on written notice to the Applicant QHIN, an application may be deemed as withdrawn as a result of the Applicant QHIN's failure to respond to requests for information from ONC (or an RCE). We believe the approach in proposed Sec. 172.305 would create an efficient process for ONC (or an RCE) to deem applications withdrawn if an Applicant QHIN fails to respond to requests for information, and also supports a flexible process by allowing an Applicant QHIN, for whatever reason, to decide to withdraw its application without penalty. Given the requirements placed on Applicant QHINs seeking to be Designated, we think it is reasonable to believe that some Applicant QHINs will need to withdraw their applications to address any number of issues that could arise during the application process. In Sec. 172.306, we propose that if an Applicant QHIN's application is denied, the Applicant QHIN will be provided with written notice that includes the basis for the denial. We do not propose a specific template that would be used to explain the basis of a denial, as such explanation would likely vary based on the specific facts and circumstances. In Sec. 172.307, we propose requirements for re-application. In Sec. 172.307(a), we propose that Applicant QHINs may resubmit their applications by complying with the provisions of Sec. 172.301 in the event that an application was denied or withdrawn. We note that re- application pursuant to Sec. 172.307(a) would also be conditioned on meeting the requirements of proposed paragraphs (b)-(d) of Sec. 172.307, as applicable. We propose in Sec. 172.307(b) that an Applicant QHIN may reapply at any time after it has voluntarily withdrawn its application as specified in Sec. 172.305(a). We want to create flexibility for Applicant QHINs to reassess their applications and, if desired, resubmit the application. We also believe that providing an Applicant QHIN that withdraws its application with discretion to choose when to re-apply would result in better applications and create administrative efficiency. This is because Applicant QHINs would be motivated to self-identify issues and correct them in a subsequent application. Also, Applicant QHINs that withdraw applications early would allow ONC (or an RCE) to avoid expending resources to review and identify such issues. In Sec. 172.307(c), we propose that if ONC (or an RCE) deems an application to be withdrawn as a result of the Applicant QHIN's failure to respond to requests for information from ONC (or an RCE), then the Applicant QHIN may reapply by submitting a new application no sooner than six (6) months after the date on which its previous application was submitted. We propose that the Applicant QHIN must respond to the prior request for information and must include an explanation as to why no response was previously provided within the required timeframe. We propose in Sec. 172.307(d) that if ONC (or [[Page 63651]] an RCE) denies an application, the Applicant QHIN may reapply by submitting a new application consistent with the requirements in Sec. 172.301, no sooner than six (6) months after the date shown on the written notice of denial. The application must specifically address the deficiencies that constituted the basis for denying the Applicant QHIN's previous application. We believe that six (6) months is an appropriate minimum time period for re-application because we would expect the Applicant QHIN to take such time to reconsider and address the deficiencies in its application. Our goal with such proposed requirements is that the Applicant QHIN will be thoughtful about its new application and will work to address the problems with its initial application. We believe the proposed six (6)-month minimum time period before re-application, in Sec. 172.307(c) and (d), would support efficiency in the review process, as ONC (or an RCE) could shift its attention to other Applicant QHINs or issues while the Applicant QHIN whose application was withdrawn as a result of the Applicant QHIN's failure to respond to requests for information or denied reconsiders its application and addresses the previously identified deficiency or deficiencies. These requirements would also support efficiency in the application process, as ONC (or an RCE) should only allocate resources to review a re-application if the Applicant QHIN has clearly addressed outstanding questions and previously identified deficiencies. On the other hand, we believe that if an Applicant QHIN withdraws its application, then the Applicant QHIN is best positioned to determine when it is ready to re-apply. Because the Applicant QHIN that withdraws its application has not had its application denied or deemed withdrawn for failure to respond to ONC (or an RCE) requests for information, the Applicant QHIN may be prepared to reapply much sooner than is the case for Applicant QHINs that have had their application denied or deemed withdrawn. We welcome comments on the proposed processes and requirements in this subpart. Specifically, we request comment on whether the six-month timeframe for re-application after an application has been deemed to be withdrawn as a result of the Applicant QHIN's failure to respond to requests for information or has been denied is appropriate, as well as other timeframes we propose.

D. Subpart D--Suspension

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

E. Subpart E--Termination

In this subpart, we propose provisions related to a QHIN's right to terminate its own Designation, ONC's (or an RCE's) obligation to terminate a QHIN's Designation and related notice requirements, and requirements related to the effect of termination. In Sec. 172.501, we propose that a QHIN may terminate its own QHIN Designation at any time without cause by providing ninety (90) calendar days prior written notice. This provision supports the voluntary nature of TEFCA by allowing a QHIN that, for whatever reason, no longer wants to serve as a QHIN, to terminate its own QHIN Designation with ninety (90) business days prior written notice. We believe a QHIN should be able to terminate its Designation, regardless of the circumstances or reason and that ninety (90) business days would provide enough time for ONC, the RCE and the departing QHIN to analyze and address the impacts of the QHIN's departure. In Sec. 172.502, we propose that a QHIN's Designation will be terminated with immediate effect by ONC (or an RCE) giving written notice of termination to the QHIN if the QHIN: (a) fails to comply with any regulations of this part and fails to remedy such material breach within thirty (30) calendar days after receiving written notice of such failure; provided, however, that if a QHIN is diligently working to remedy its breach at the end of this thirty (30) day period, then ONC (or an RCE) must provide the QHIN with up to another thirty (30) calendar days to remedy its material breach; or (b) a QHIN breaches a material provision of the Common Agreement where such breach is not capable of remedy. We request comments on examples of material provisions of the Common Agreement where a breach is not capable of remedy. We believe these proposals would promote transparency in TEFCA and strengthen the underlying trust among and between entities connected to TEFCA. These termination provisions would enable ONC (or an RCE) to take swift action to remove a non-complaint QHIN and ensure that entities that fail to meet their obligations as QHINs (by failing to comply with the regulations of this Part or by breaching a material provision of the Common Agreement) are no longer able to act as QHINs under the TEFCA framework. Without the ability for ONC (or an RCE) to terminate non-compliant QHINs, this trust--which is foundational to TEFCA and necessary for the ultimate success of TEFCA--could quickly erode and undermine TEFCA's progress. In Sec. 172.503, we propose that QHINs and ONC (or an RCE) would be able to terminate the QHIN's Designation at any time and for any reason by mutual, written agreement. Allowing two parties to terminate an agreement by mutual, written agreement ensures that two parties are not forced to follow an agreement that neither wants to follow. ONC believes it is reasonable and efficient to allow termination at any time where both ONC (or an RCE) and the QHIN are satisfied that a QHIN's termination is in the best interest of all. We welcome comments on the proposed processes and requirements in this subpart.

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

ONC oversees the RCE's work and has the right to review the RCE's conduct and its execution of nondiscrimination and conflict of interest policies that demonstrate the RCE's commitment to treating QHINs in a transparent, fair, [[Page 63653]] and nondiscriminatory way.\260\ This subpart proposes to establish processes for review of RCE or ONC actions, including QHIN appeal rights and the process for filing an appeal. These appeal rights would ensure that a QHIN or Applicant QHIN that disagrees with certain RCE or ONC decisions will have recourse to appeal those decisions. Our proposed Sec. 172.600 reflects this overall scope as an applicability section for this subpart. --------------------------------------------------------------------------- \260\ See Common Agreement Section 3.1, https://www.federalregister.gov/documents/2024/05/01/2024-09476/notice-of-publication-of-common-agreement-for-nationwide-health-information-interoperability-common. --------------------------------------------------------------------------- In Sec. 172.601, we propose provisions to establish ONC's authority to review RCE determinations, policies, and actions, as well as procedures for exercising such review. We propose in Sec. 172.601(a) that ONC may, in its sole discretion, review all or any part of any RCE determination, policy, or action. In Sec. 172.601(b) we propose ONC may, in its sole discretion and on notice to affected QHINs or Applicant QHINs, stay any RCE determination, policy, or other action. In Sec. 172.601(c), we propose ONC may, in its sole discretion and on written notice, request that a QHIN, Applicant QHIN, or the RCE provide ONC additional information regarding any RCE determination, policy, or other action. In Sec. 172.601(d), we propose that on completion of its review, ONC may affirm, modify, or reverse the RCE determination, policy, or other action under review. Additionally, we propose to provide notice to affected QHINs or Applicant QHINs that includes the basis for ONC's decision. In Sec. 172.601(e), we propose ONC will provide written notice under this section to affected QHINs or Applicant QHINs in the same manner as the original RCE determination, policy, or other action under review. We believe these proposals provide transparency into the level of oversight ONC has in reviewing RCE determinations, policies, or actions and firmly establish ONC's authority to affirm, modify, or reverse such determinations, policies, and actions. We believe these provisions are important to assure QHINs and Applicant QHINs that we have the ability to effectively exercise oversight of the RCE, as well as provide all parties with an interest in the administration of TEFCA with confidence that we can and will take necessary action to ensure that QHINs and Applicant QHINs comply with the regulations we propose in part 172. In Sec. 172.602, we propose to establish bases for Applicant QHINs and QHINs to appeal decisions to ONC. We propose that an Applicant QHIN or QHIN may appeal certain decisions to ONC or a hearing officer, as appropriate. In Sec. 172.602(a)(1), we propose that an Applicant QHIN would be able to appeal the denial of its application. In Sec. 172.602(a)(2), we propose that a QHIN would be able to appeal a decision to (1) suspend a QHIN or instruct a QHIN to suspend its Participant or Subparticipant; or (2) terminate a QHIN's Common Agreement. We request comment on the proposed bases for appeal. In Sec. 172.603, we propose the method and timing for filing an appeal. In Sec. 172.603(a), we propose that to initiate an appeal, an authorized representative of the Applicant QHIN or QHIN must submit electronically, in writing to ONC, a notice of appeal that includes the date of the notice of appeal, the date of the decision being appealed, the Applicant QHIN or QHIN who is appealing, and the decision being appealed within fifteen (15) calendar days of the Applicant QHIN's or QHIN's receipt of the notice of (1) denial of an application, (2) suspension or instruction to suspend its Participant or Subparticipant, or (3) termination. With regard to an appeal of a termination, the fifteen (15) calendar day timeframe may be extended by ONC up to another fifteen (15) calendar days if the QHIN has been granted an extension for completing its remedy under Sec. 172.502(a). The notice of appeal would serve to notify ONC that the Applicant QHIN or QHIN is planning to file an appeal and would require inclusion of only the minimum amount of information necessary to provide such notice (i.e., the date of the notice of appeal, the date of the decision being appealed, the Applicant QHIN or QHIN who is appealing, and what is being appealed). As such, we believe fifteen (15) business days would be an adequate amount time for deciding whether to initiate an appeal and submitting such information. In Sec. 172.603(b), we propose that an authorized representative of an Applicant QHIN or QHIN must submit electronically, to ONC, within thirty (30) calendar days of filing the intent to appeal: (1) A statement of the basis for appeal, including a description of the facts supporting the appeal with citations to documentation submitted by the QHIN or Applicant QHIN; and (2) Any documentation the QHIN would like considered during the appeal. We expect that it would take an Applicant QHIN or QHIN some time to collect all of the relevant information and documentation to support its appeal, and accordingly have proposed a timeframe for requesting an appeal of thirty (30) calendar days from the filing of the intent to appeal with ONC. We welcome comments on whether this timeframe, as well as the timeframe for submitting an intent to appeal, are adequate and appropriate. In Sec. 172.603(c), we propose that an Applicant QHIN or QHIN filing the appeal may not submit on appeal any evidence it did not submit prior to the appeal, except by permission of the hearing officer. We believe this provision balances a QHIN or Applicant QHIN's right to introduce evidence with the need for orderly proceedings. We are aware that under our proposed regulations, QHINs facing suspension or termination do not have an express right to introduce evidence. We solicit comments on whether and when a QHIN facing suspension or termination should have a right to introduce that evidence--for example as part of demonstrating that a material breach has been remedied or is capable of remedy under Sec. 172.502, at the hearing officer stage, or some combination of the two based on circumstances of the suspension or termination. In Sec. 172.604, we propose that an appeal would not stay a suspension or termination, unless otherwise ordered by ONC or the hearing officer assigned under Sec. 172.605(b). This means that in the event of an appeal of a suspension or termination, the appeal would not stop the suspension or termination from being effective. We believe this proposed approach is important because a QHIN would only be suspended or terminated for infractions that could, for example, jeopardize the privacy and security of TEFCA Exchange. Before a QHIN is terminated under Sec. 172.502(a), the QHIN would have already been given an opportunity to remedy the breach unless the breach is not capable of remedy. The move by ONC or and RCE to terminate a QHIN would mean either the QHIN tried and failed to remedy the issue, or a remedy is not possible. In either case, we believe it would be appropriate not to stay the termination. In the case of a suspension, the QHIN would have been found to be responsible for a Threat Condition, and we believe the risk to the privacy and security of the TEFCA ecosystem would far outweigh any perceived benefit of staying the suspension. In Sec. 172.605, we propose provisions related to the assignment of a hearing officer. In Sec. 172.605(a), we propose that, in the event of an appeal, the National Coordinator may exercise authority under Sec. 172.601 to review the RCE determination being appealed. We [[Page 63654]] further propose an appealing QHIN or Applicant QHIN that is not satisfied with ONC's subsequent determination may appeal that determination to a hearing officer by filing a new notice of appeal and other appeal documents that comply with Sec. 172.603. In Sec. 172.605(b), we propose if ONC declines review under subsection (a), or if ONC made the determination under review, ONC would arrange for assignment of the case to a hearing officer to adjudicate the appeal. We specify in proposed Sec. 172.605(c) that the hearing officer must be an officer appointed by the Secretary of Health and Human Services (for more information about officers and appointments, see section III.D.5.c, above). In Sec. 172.605(d), we propose, the hearing officer may not be responsible to, or subject to the supervision or direction of, personnel engaged in the performance of investigative or prosecutorial functions for ONC, nor may any officer, employee, or agent of ONC engaged in investigative or prosecutorial functions in connection with any adjudication, in that adjudication or one that is factually related, participate or advise in the decision of the hearing officer, except as a counsel to ONC or as a witness. In Sec. 172.606, we propose requirements related to adjudication. In Sec. 172.606(a), we propose that the hearing officer would decide issues of law and fact de novo and would apply a preponderance of the evidence standard when deciding appeals. De novo review means that the hearing officer would decide the issue on appeal without deference to a previous decision (i.e., ONC's or the RCE's decision to (1) deny an application, (2) suspend a QHIN or to instruct a QHIN to suspend its Participant or Subparticipant, or (3) terminate a QHIN's Common Agreement). We believe de novo review is appropriate for appeals by Applicant QHINs or QHINs because ONC ultimately has responsibility for TEFCA operations and implementation, even though the RCE is a contractor acting on ONC's behalf. Given the gravity and potentially significant implications (financial, effect on existing contracts, etc.) of a denied application, suspension, or termination, we believe the hearing officer assigned by the National Coordinator should make an independent decision, taking all of the facts and evidence the parties present into consideration. The ``preponderance of the evidence'' standard means the burden of proof is met when the party with the burden (the appealing Applicant QHIN or QHIN) convinces the fact finder (hearing officer) that there is a greater than 50% chance that the claim is true. This standard is used in most civil cases and would only require the appealing party to show that a particular fact or event was more likely than not to have occurred. We believe this threshold creates the right balance for requiring an appealing Applicant QHIN or QHIN to make a strong case to succeed on appeal, while not imposing a standard that would be extremely difficult for the appeal Applicant QHIN or QHIN to meet. We request comment on whether the ``preponderance of the evidence'' is the appropriate standard, or if another standard (e.g., clear and convincing evidence, beyond a reasonable doubt, etc.) would be more suitable. In Sec. 172.606(b), we propose that a hearing officer would make a determination based on the written record or any information from a hearing conducted in-person, via telephone, or otherwise (for example, via video teleconference). We propose that the written record would include ONC's or the RCE's determination and supporting information, as well as all appeal materials submitted by the Applicant QHIN or QHIN pursuant to Sec. 172.603. We propose these requirements for the written record because it is important that the written record reflect both the position of ONC or the RCE and the Applicant QHIN or QHIN. We propose that the hearing officer would have sole discretion to conduct a hearing in certain situations. We propose that the hearing officer could conduct a hearing to require either party to clarify the written record under paragraph (b)(1) of this section. Last, we propose that the hearing officer could conduct a hearing if they otherwise determine a hearing is necessary. We believe the last provision is necessary because it gives the hearing officer discretion to conduct a hearing based on the specific circumstances surrounding the appeal, even if the need for the hearing does not fit under the first or second criteria detailed above. In Sec. 172.606(c), we propose that a hearing officer would neither receive witness testimony nor accept any new information beyond what was provided in accordance with paragraph (b) of this section, except for good cause shown by the party seeking to submit new information. We believe this provision will help ensure that the appeals process is consistent and fair for all involved. In Sec. 172.607, we propose requirements related to a decision by the hearing officer. In Sec. 172.607(a), we propose that the hearing officer would issue a written determination. We request comment on whether we should include a specific timeframe for issuing the written determination, or whether abstaining from including a specific timeframe is a better approach given the varying complexity and circumstances of each appeal. To ensure accountability, and to ensure that the hearing officer's decisions would be subject to the discretionary review of a principal officer of the United States, we propose in Sec. 172.607(b) that a hearing officer's decision on an appeal is the final decision of HHS unless within 10 business days, the Secretary, at the Secretary's sole discretion, chooses to review the determination. We also propose that ONC would notify the appealing party if the Secretary chooses to review the determination and once the Secretary makes his or her determination. This provision would also align Sec. 172.607 procedures with the ONC Health IT Certification Program appeals procedures in Sec. 170.580(g) as we propose to revise them in this Proposed Rule (see Section III.D.2.b of this preamble). We have not proposed a specific timeframe for the Secretary to complete their review (if the Secretary chooses to review) because we believe that if the Secretary makes the decision to review a hearing officer's determination, the Secretary would be informed enough on the issues of the case to determine an appropriate review timeframe. We welcome comments on the proposed appeal processes outlined in this subpart.

G. Subpart G--QHIN TM Attestation for the Adoption of the

Trusted Exchange Framework and Common Agreement TM Section 4003(b) of the Cures Act added section 3001(c)(9), ``Support for Interoperable Networks Exchange,'' to the PHSA. Section 3001(c)(9)(D)(ii) requires HHS to establish, through notice and comment rulemaking, a process for HINs that voluntarily elect to adopt TEFCA to attest to such adoption of the framework and agreement. Section 3001(c)(9)(D)(i) also requires the National Coordinator to publish on ONC's website a list of the HINs that have adopted the Common Agreement and are capable of trusted exchange pursuant to the Common Agreement. QHINs are the only entities permitted to ``adopt'' the Common Agreement, which is accomplished by becoming a signatory to the Common Agreement. As such, we propose that only QHINs would be able to attest to the adoption of the Common Agreement and the Trusted Exchange Framework. While the Trusted Exchange Framework was [[Page 63655]] foundational for creating the provisions of the Common Agreement, it is, as noted above, a separate set of principles. Therefore, we propose that for purposes of attesting to the adoption of the Trusted Exchange Framework, QHINs would be required to expressly attest to their agreement and adherence to the Trusted Exchange Framework.\261\ --------------------------------------------------------------------------- \261\ The Trusted Exchange Framework (TEF): Principles for Trusted Exchange (January 2022), https://www.healthit.gov/sites/default/files/page/2022-01/Trusted_Exchange_Framework_0122.pdf. --------------------------------------------------------------------------- Once attestation is complete and deemed valid, QHINs would be publicly listed on ONC's website. This regulatory provision would implement the HIN attestation provision from the Cures Act and would provide benefits to the public, Federal partners, and interested parties. For example, a Federal website listing of attesting QHINs would make it easy for the public to identify whether an entity is or is not a QHIN and provide a resource for Federal partners to help determine whether participants in some of their programs also belong to a network that is recognized as a QHIN. Section 3001(c)(9)(E) provides the option for Federal agencies to require, under certain circumstances, adoption of TEFCA for health information exchange networks that they contract with or enter into agreements with. To implement sections 3001(c)(9)(D)(i) and (ii) of the PHSA, we propose to establish subpart G in part 172 titled, ``QHIN Attestation for the Adoption of the Trusted Exchange Framework and Common Agreement.'' We propose in Sec. 172.700 that subpart G would establish the attestation submission requirements applicable to QHINs. In Sec. 172.701, we propose attestation submission requirements for QHINs and review and acceptance processes that ONC will follow for TEFCA attestations. In Sec. 172.701(b), we propose that in order to be listed in the QHIN Directory described in proposed Sec. 172.702, a QHIN would be required to submit to ONC an attestation affirming agreement with and adherence to the Trusted Exchange Framework and its adoption of the Common Agreement. We further propose in Sec. 172.701(b) that a QHIN would be required to submit to ONC identifying information consisting of its name, address, city, State, zip code, and a hyperlink to its website. We also propose that the QHIN would be required to submit to ONC identifying information about its authorized representative including the representative's name, title, phone number, and email address. We propose that a QHIN would also be required to provide documentation confirming its Designation as a QHIN. We also propose that a QHIN would be required to provide ONC with written notice of any changes to its identifying information provided in accordance with Sec. 172.701 within 30 calendar days of the change(s) to its identifying information. We believe the above provisions provide clear instructions for submitting a QHIN attestation that will support a consistent and transparent QHIN attestation process and provides ONC with the information needed to identify the entity and contact the authorized representative. We propose in Sec. 172.701(c) that a QHIN must electronically submit its attestation and documentation specified in Sec. 172.701(b) either via an email address identified by ONC or via a submission on the ONC website, if available. We propose in Sec. 172.701(d) that once a QHIN has submitted its attestation and documentation, ONC would either accept or reject the submission within 30 calendar days. We propose that ONC would accept the submission if it determines that the QHIN has satisfied the requirements of Sec. Sec. 172.701(b) and (c). In such instances, we propose that ONC would provide written notice to the applicable QHIN's authorized representative that the submission has been accepted. In Sec. 172.701(d), we also propose that ONC would reject a submission if it determines that the requirements of Sec. 172.701(b), Sec. 172.701(c), or both, have not been satisfied. In such instances, we propose that ONC would provide written notice to the QHIN's authorized representative of the determination along with the basis for the determination. We propose that an ONC determination would be a final agency action and not subject to administrative review, except the Secretary may choose to review the determination as provided in Sec. 172.607(b). However, we propose that a QHIN may, at any time, resubmit an attestation and documentation in accordance with Sec. Sec. 172.701(b) and (c). We believe these submission procedures will support a consistent and transparent QHIN attestation process. We welcome comments on these procedures. In Sec. 172.702, we propose the requirements for a QHIN directory. We propose in Sec. 172.702(a) that this subpart would establish processes for publishing a directory of QHINs on the ONC website. We propose in Sec. 172.702(b)(1) that, within fifteen (15) calendar days of notifying a QHIN that its submission has been accepted, ONC would publish, at a minimum, the QHIN's name in the QHIN directory. We propose Sec. 172.702(b)(2) to identify within the QHIN directory those QHINs that have been suspended under the Common Agreement. A QHIN directory that includes QHINs that have adopted the Common Agreement and are capable of TEFCA Exchange and those QHINs suspended under the Common Agreement offers a transparent list of QHINs participating in TEFCA. As noted above, the QHIN directory may serve as a useful tool for the public, Federal partners, and other interested parties seeking information about QHINs. Therefore, we welcome comments regarding the information we propose to include in the QHIN directory. We propose in Sec. 172.702(c) to establish requirements for removal of a QHIN from the QHIN directory. We propose in Sec. 172.702(c)(1) that ONC will remove a QHIN that is no longer eligible for QHIN status from the QHIN directory. We propose that a QHIN whose Common Agreement has been terminated would no longer be considered a QHIN and so would be removed from the QHIN directory. The removal of a QHIN whose Common Agreement has been terminated from the QHIN Directory would be a ministerial action by ONC. We propose in Sec. 172.702(c)(2) that upon termination of a QHIN's Common Agreement, ONC (or an RCE) will send a written statement of intent to remove the QHIN from the QHIN Directory to the authorized representative of the QHIN. Under Sec. 172.702(c)(3), we propose that the written statement would include, as appropriate, (i) the name of the terminated QHIN and the name and contact information of the authorized representative of the QHIN; (ii) a short statement setting forth findings of fact with respect to any violation of the Common Agreement or other basis for the QHIN's termination; (iii) other materials as the RCE may deem relevant. In Sec. 172.702(d), we propose that a QHIN that is removed from the QHIN Directory would remain removed until a new attestation is accepted by ONC in accordance with the processes specified in subpart G of this part. In Sec. 172.702(e), we propose that an ONC determination under Sec. 172.702 is final agency action and not subject to further administrative review, except the Secretary may choose to review the determination as provided in Sec. 172.607(b). We believe this proposal is appropriate because a QHIN would have had ample opportunity to appeal its termination under the provisions proposed in Subpart F of this Proposed Rule. [[Page 63656]] We seek comments on alternative ways to structure the requirements to remove a QHIN from the QHIN directory.