Health Data, Technology, and Interoperability: Certification Program Updates, Algorithm Transparency, and Information Sharing

Federal RegisterApr 18, 2023

Ask Donna

What actually matters in this document.

Text

DEPARTMENT OF HEALTH AND HUMAN SERVICES

Office of the Secretary

45 CFR Parts 170 and 171

RIN 0955-AA03

Health Data, Technology, and Interoperability: Certification Program Updates, Algorithm Transparency, and Information Sharing

AGENCY:

Office of the National Coordinator for Health Information Technology (ONC), Department of Health and Human Services (HHS).

ACTION:

Proposed rule.

SUMMARY:

This proposed rule would implement the Electronic Health Record (EHR) Reporting Program provision of the 21st Century Cures Act by establishing new Conditions and Maintenance of Certification requirements for health information technology (health IT) developers under the ONC Health IT Certification Program (Program). This proposed rule would also make several updates to certification criteria and implementation specifications recognized by the Program, including a revised certification criterion for decision support and revised certification criteria for patient demographics and observations and electronic case reporting. This proposed rule would establish a new baseline version of the United States Core Data for Interoperability (USCDI). Additionally, this proposed rule would provide enhancements to support information sharing under the information blocking regulations. The implementation of these provisions would advance interoperability, improve transparency, and support the access, exchange, and use of electronic health information. The proposed rule would also update the Program in additional ways to advance interoperability, enhance health IT certification, and reduce burden and costs.

DATES:

To be assured consideration, written or electronic comments must be received at one of the addresses provided below, no later than 5 p.m. on June 20, 2023.

ADDRESSES:

You may submit comments, identified by RIN 0955-AA03, by any of the following methods (please do not submit duplicate comments). Because of staff and resource limitations, we cannot accept comments by facsimile (FAX) transmission.

•

Federal eRulemaking Portal:

Follow the instructions for submitting comments. Attachments should be in Microsoft Word, Microsoft Excel, or Adobe PDF; however, we prefer Microsoft Word.

http://www.regulations.gov.

•

Regular, Express, or Overnight Mail:

Department of Health and Human Services, Office of the National Coordinator for Health Information Technology, Attention: Health Data, Technology, and Interoperability: Certification Program Updates, Algorithm Transparency, and Information Sharing Proposed Rule, Mary E. Switzer Building, Mail Stop: 7033A, 330 C Street SW, Washington, DC 20201. Please submit one original and two copies.

•

Hand Delivery or Courier:

Office of the National Coordinator for Health Information Technology, Attention: Health Data, Technology, and Interoperability: Certification Program Updates, Algorithm Transparency, and Information Sharing Proposed Rule, Mary E. Switzer Building, Mail Stop: 7033A, 330 C Street SW, Washington, DC 20201. Please submit one original and two copies. (Because access to the interior of the Mary E. Switzer Building is not readily available to persons without federal government identification, commenters are encouraged to leave their comments in the mail drop slots located in the main lobby of the building.)

Enhancing the Public Comment Experience:

To facilitate public comment on this proposed rule, a copy will be made available in Microsoft Word format on ONC's website (

http://www.healthit.gov

). We believe this version will make it easier for commenters to access and copy portions of the proposed rule for use in their individual comments. Additionally, a separate document (“public comment template”) will also be made available on ONC's website (

http://www.healthit.gov

) for the public to use in providing comments on the proposed rule. This document is meant to provide the public with a simple and organized way to submit comments on proposals and respond to specific questions posed in the preamble of the proposed rule. While use of this document is entirely voluntary, we encourage commenters to consider using the document in lieu of unstructured comments, or to use it as an addendum to narrative cover pages. We believe that use of the document may facilitate our review and understanding of the comments received. The public comment template will be available shortly after the proposed rule publishes in the

Federal Register

. This short delay will permit the appropriate citation in the public comment template to pages of the published version of the proposed rule.

Inspection of Public Comments:

All comments received before the close of the comment period will be available for public inspection, including any personally identifiable or confidential business information that is included in a comment. Please do not include anything in your comment submission that you do not wish to share with the general public. Such information includes, but is not limited to, the following: a person's social security number; date of birth; driver's license number; state identification number or foreign country equivalent; passport number; financial account number; credit or debit card number; any personal health information; or any business information that could be considered proprietary. We will post all comments that are received before the close of the comment period at

http://www.regulations.gov.

Docket:

For access to the docket to read background documents or comments received, go to

http://www.regulations.gov

or the Department of Health and Human Services, Office of the National Coordinator for Health Information Technology, Mary E. Switzer Building, Mail Stop: 7033A, 330 C Street SW, Washington, DC 20201 (call ahead to the contact listed below to arrange for inspection).

FOR FURTHER INFORMATION CONTACT:

Michael Lipinski, Office of Policy, Office of the National Coordinator for Health Information Technology, 202-690-7151.

SUPPLEMENTARY INFORMATION:

Table of Contents

I. Executive Summary

A. Purpose of Regulatory Action

B. Summary of Major Provisions

1. ONC Health IT Certification Program Updates

a. “The ONC Certification Criteria for Health IT” and Discontinuing Year Themed “Editions”

b. New and Revised Standards and Certification Criteria

i. The United States Core Data for Interoperability Standard Version 3 (USCDI v3)

ii. C-CDA Companion Guide Updates

iii. “Minimum Standards” Code Sets Updates

iv. Electronic Case Reporting

v. Decision Support Interventions and Predictive Models

vi. Synchronized Clocks Standard

vii. Standardized API for Patient and Population Services

viii. Patient Demographics and Observations Certification Criterion in § 170.315(a)(5)

ix. Updates to Transitions of Care Certification Criterion in § 170.315(b)(1)

x. Patient Requested Restrictions Certification Criterion

xi. Requirement for Health IT Developers To Update Their Previously Certified Health IT

2. Assurances Condition and Maintenance of Certification Requirements

3. Real World Testing—Inherited Certified Status

4. Insights Condition and Maintenance of Certification

5. Information Blocking Enhancements

C. Costs and Benefits

II. Background

A. Statutory Basis

1. Standards, Implementation Specifications, and Certification Criteria

2. Health IT Certification Program(s)

B. Regulatory History

III. ONC Health IT Certification Program Updates

A. “The ONC Certification Criteria for Health IT” and Discontinuing Year Themed “Editions”

B. Standards and Implementation Specifications

1. National Technology Transfer and Advancement Act

2. Compliance With Adopted Standards and Implementation Specifications

3. “Reasonably Available” to Interested Parties

C. New and Revised Standards and Certification Criteria

1. The United States Core Data for Interoperability Standard (USCDI) v3

a. Background

b. Certification Criteria That Reference USCDI

c. USCDI Standard—Data Classes and Elements Added Since USCDI v1

2. C-CDA Companion Guide Updates

3. “Minimum Standards” Code Sets Updates

4. Electronic Case Reporting

a. Background

b. Standards Landscape for Case Reporting

c. Proposed Updates to Case Reporting in § 170.315(f)(5)

d. Proposed Adoption of Standards for Electronic Case Reporting

e. Proposal for Reporting

5. Decision Support Interventions and Predictive Models

a. Background

b. Summary of Proposals

c. Proposed Requirements for Decision Support Interventions (DSI) Certification Criterion

d. Proposed Updates to Real World Testing Condition for CDS Criterion

6. Synchronized Clocks Standard

a. Background

b. Justification

7. Standardized API for Patient and Population Services

a. Native Applications and Refresh Tokens

b. FHIR United States Core Implementation Guide Version 5.0.1

c. FHIR Endpoint for Service Base URLs

d. Access Token Revocation

e. SMART App Launch 2.0

8. Patient Demographics and Observations Certification Criterion in § 170.315(a)(5)

9. Updates to Transitions of Care Certification Criterion in § 170.315(b)(1)

10. Patient Requested Restrictions Certification Criterion

a. Patient Right To Request a Restriction New Criterion—Primary Proposal

b. Alignment With Adopted Standards—Alternate Proposals and Request for Information

c. Alignment With Applicable Law—Request for Information

11. Requirement for Health IT Developers To Update Their Previously Certified Health IT

D. Assurances Condition and Maintenance of Certification Requirements

1. Condition of Certification

2. Maintenance of Certification Requirements

E. Real World Testing—Inherited Certified Status

F. Insights Condition and Maintenance of Certification

1. Background and Purpose

2. Insights Condition—Proposed Measures

3. Insights Condition and Maintenance of Certification Requirements

4. Insights Condition and Maintenance of Certification's Process for Reporting

G. Requests for Information

1. Laboratory Data Interoperability Request for Information

a. Background

b. Request for Information

2. Request for Information on Pharmacy Interoperability Functionality Within the ONC Health IT Certification Program Including Real-Time Prescription Benefit Capabilities

a. Background

b. Request for Information

c. Real-Time Prescription Benefit Certification Criterion

d. Health IT Ecosystem for Pharmacy Interoperability

3. FHIR Standard

a. FHIR Subscriptions Request for Information

b. Clinical Decision Support Hooks Request for Information

c. FHIR Standard for Scheduling Request for Information

d. SMART Health Links Request for Information

IV. Information Blocking Enhancements

A. Defined Terms

1. Offer Health Information Technology or Offer Health IT

a. Exclusion of Certain Funding Subsidy Arrangements From

Offer

Definition

b. Implementation and Use Activities That Are Not an Offering

c. Consulting and Legal Services Exclusion From

Offer

Definition

2. Health IT Developer of Certified Health IT: Self-Developer Health Care Providers

3. Information Blocking Definition

B. Exceptions

1. Infeasibility

a. Infeasibility Exception—Uncontrollable Events Condition

b. Third Party Seeking Modification Use

c. Manner Exception Exhausted

2. Manner Exception—TEFCA Reasonable and Necessary Activities

a. Background

b. TEFCA Condition for the “Manner” Exception

C. Information Blocking Requests for Information

1. Additional Exclusions From Offer Health IT—Request for Information

2. Possible Additional TEFCA Reasonable and Necessary Activities—Request for Information

3. Health IT Capabilities for Data Segmentation and User/Patient Access—Request for Information

V. Incorporation by Reference

VI. Response to Comments

VII. Collection of Information Requirements

A. Independent Entity

B. Health IT Developers

C. ONC-ACBs

VIII. Regulatory Impact Statement

A. Statement of Need

B. Alternatives Considered

C. Overall Impact

1. Executive Orders 12866 and 13563—Regulatory Planning and Review Analysis

a. Costs and Benefits

b. Accounting Statement and Table

D. Regulatory Flexibility Act

E. Executive Order 13132

—

Federalism

F. Unfunded Mandates Reform Act of 1995

Regulation Text

I. Executive Summary

A. Purpose of Regulatory Action

The Secretary of Health and Human Services has delegated responsibilities to 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) including: the Electronic Health Record (EHR) Reporting Program condition and maintenance of certification requirements under the ONC Health IT Certification Program (Program) and identifying reasonable and necessary activities that do not constitute information blocking.

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) of 2009 including, among other things: 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 would fulfill statutory requirements; provide transparency; advance equity, innovation, and interoperability; and support the access, exchange, and use of electronic health information (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.

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 and C. 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 fulfilling the HITECH Act's and Cures Act's requirements described above and advancing interoperability, the proposed rule would contribute to fulfilling Executive Orders (E.O.) 13994, 13985, 14036, 14058, and 14091. 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 update in this proposed rule to adopt the United States Core Data for Interoperability Standard Version 3 (USCDI v3) would promote the establishment and use of interoperable data sets of EHI for interoperable health data exchange. As discussed in section III.C.1, USCDI v3 would facilitate the gathering, sharing, and publication 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 proposed updates to Application Programming Interfaces (APIs) Conditions and Maintenance of Certification requirements, as discussed in section III.C.7, would continue ONC's efforts to develop and standardize APIs and would help individuals and other authorized health care providers, including those engaged in public health, to securely access EHI through the broader adoption of standardized APIs.

2 3

Additionally, the proposed rule would adopt consensus-based, industry-developed health IT standards for certified Health IT Modules to support electronic case reporting. As discussed in section III.C.4, this would, among other benefits, facilitate faster and more efficient disease tracking and case management. It also would provide more timely and complete data than manual or non-standardized reporting. In addition to proposing new standards to support public health initiatives, we also request comment and seek input from the public in section III.G regarding health IT standards that could be adopted within the Program to strengthen and advance laboratory interoperability.

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

Section 4002 of the 21st Century Cures Act (Cures Act) establishes 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

and E.O. 14091 of February 16, 2023, Further Advancing Racial Equity and Support for Underserved Communities Through the Federal Government.

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.” As noted above, we propose to adopt USCDI v3. If finalized, the adoption of USCDI v3 would update the USCDI standard to include data elements such as sexual orientation and social determinants of health, as discussed in sections III.C.1 and III.C.8 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. These proposed updates 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. The use of USCDI v3 would 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.

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

https://www.federalregister.gov/documents/2021/01/25/2021-01753/advancing-racial-equity-and-support-for-underserved-communities-through-the-federal-government.

United States, Executive Office of the President [Joseph Biden]. Executive Order 14091: Further Advancing Racial Equity and Support for Underserved Communities Through the Federal Government. Feb 16, 2023. 88 FR 10825-10833,

https://www.federalregister.gov/documents/2023/02/22/2023-03779/further-advancing-racial-equity-and-support-for-underserved-communities-through-the-federal.

As discussed in section III.C.1.c, the proposal to adopt USCDI v3 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 process, and health equity strategies, tactics, and patterns are guiding principles for developers, enforced by technical architecture, and built into the technology at every layer. If the proposal to adopt USCDI v3 is finalized, certified health IT products and capabilities should be designed with a foundational approach to promote equity. As a result, by their very design, certified health IT and the workflows around them should support equity and efforts to reduce disparities.

E.O. 14091 of Feb. 16, 2023, builds upon previous equity-related E.O.s, including E.O. 13985. Section 1 of E.O. 14091 requires the Federal Government to “promote equity in science and root out bias in the design and use of new technologies, such as artificial intelligence.” Section 8 of E.O. 14091 requires agencies to “prevent and address discrimination and advance equity for all” and to “consider opportunities to prevent and remedy discrimination, including by protecting the public from algorithmic discrimination.”

This proposed rule would revise the existing clinical decision support (CDS) certification criterion by proposing a “Decision Support Interventions” (DSIs) certification criterion to keep pace with

advances in software that developers of certified health IT enable or interface with to aid decision-making in healthcare. As discussed in section III.C.5, this criterion would also advance health equity by design by making it known to users of certified Health IT Modules certified to the criterion whether demographic, social determinants of health assessment data are used in DSIs. Finally, these proposals would: (1) establish a definition for algorithm-based, “predictive” DSIs; (2) require certified Health IT Modules certified to the criterion that enable or interface with predictive DSIs to enable users to review information about additional source attributes relevant to health equity, among other purposes, (3) require developers of certified Health IT Modules certified to the criterion to employ or engage in intervention risk management practices for all predictive DSIs that the developers' certified Health IT Modules enable or interface; and (4) make summary information regarding these practices available publicly.

Together, these proposed requirements should improve transparency, promote trustworthiness, and incentivize the development and wider use of fair, appropriate, valid, effective, and safe predictive DSIs to aid decision-making. The resulting information transparency would enable users, including health care providers, to scrutinize these technologies and would increase public trust and confidence in these technologies. The resulting information transparency could expand the use of these technologies in safer, more appropriate, and more equitable ways. This transparency would also inform wider discussions across industry and academia regarding how to evaluate and communicate performance related to predictive decision support interventions.

President Biden's E.O. 14036, Promoting Competition in the American Economy, 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).

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 in section III.C.7, competition would be advanced through these improved API standards that can help individuals connect to their information and can help authorized 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.

United States, Executive Office of the President [Joseph Biden]. Executive Order 14036: Promoting Competition in the American Economy. Jul 9, 2021. 86 FR 36987-36999,

https://www.federalregister.gov/documents/2021/07/14/2021-15069/promoting-competition-in-the-american-economy.

Further, as described in section IV, this proposed rule would provide enhancements to support information sharing under the information blocking regulations and promote innovation and competition, as well as address market consolidation. 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. In both the ONC Cures Act Proposed (84 FR 7508) and Final (85 FR 25790 through 25791) Rules, we discussed 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.

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 (section 3022(a)(2)(C)(ii) 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 electronic health information (EHI) (85 FR 25820).

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 of healthcare services (85 FR 25820). The implementation of the new information blocking provisions proposed in section IV of this proposed rule would promote innovation, encourage market competition, and address consolidation in the interest of the patient to advance interoperability, improve transparency, and support the access, exchange, and use of electronic health information.

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

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.

As required by section 4002 of the Cures Act and included in the ONC Cures Act Final Rule (85 FR 25717), we

established certain Conditions and Maintenance of Certification requirements, which express initial and ongoing requirements for health IT developers and their certified Health IT Module(s) under the Program. This proposed rule would implement the EHR Reporting Program Condition and Maintenance of Certification requirement outlined in the Cures Act by establishing a new Insights Condition and Maintenance of Certification (“Insights Condition”) within Program. As discussed in section III.F, the implementation of the Insights Condition would provide transparent reporting to address information gaps in the health IT marketplace and provide insights on the use of specific certified health IT functionalities. The implementation of this new Condition and Maintenance of Certification requirement would allow ONC to gain understanding of the use of health IT and would provide ONC with information about consumers' experience with certified health IT.

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

https://www.federalregister.gov/documents/2021/12/16/2021-27380/transforming-federal-customer-experience-and-service-delivery-to-rebuild-trust-in-government.

We also strive to improve federal agency coordination. ONC works with the Centers for Medicare & Medicaid Services (CMS) to ensure that our own certification timelines complement timelines for 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 the interest of clarity and cohesion among HHS components, we have proposed to align some of our compliance dates to the calendar year for consistency with calendar-year based performance periods in CMS programs when participants may be required to use updated certified health IT. We believe this approach reduces confusion for participants in these programs and better serves the public interest.

B. Summary of Major Provisions

1. ONC Health IT Certification Program Updates

a. “The ONC Certification Criteria for Health IT” and Discontinuing Year Themed “Editions”

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. ONC first introduced the concept of an “edition” of ONC health IT certification criteria in 2012. In 2012, we stated that we would refer to the certification criteria adopted in §§ 170.302, 170.304, and 170.306 collectively as the “2011 Edition EHR certification criteria” and that the certification criteria adopted in § 170.314 would be referred to as the “2014 Edition EHR certification criteria” (77 FR 13836). In 2015, we issued a final rule, “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) and adopted the “2015 Edition Health IT Certification Criteria” (80 FR 62602). We codified the 2015 Edition certification criteria in § 170.315 to set them apart from other editions of certification criteria (80 FR 62608). In 2020, we published the ONC Cures Act Final Rule (85 FR 25642) and adopted updates to the 2015 Edition. These updates included new certification criteria, standards, and requirements, as well as incremental revisions to existing 2015 Edition certification criteria to better enable interoperability and the access, exchange, and use of electronic health information (85 FR 25664-65). Because we did not adopt a wholesale new edition of certification criteria in a different CFR section, we retained the overall 2015 Edition title for the changes included in the ONC Cures Act Final Rule and made specific timebound compliance changes within certification criteria.

Subsequent to publication of the ONC Cures Act Final Rule through public meetings and correspondence, we heard that the continued use and reference to the 2015 Edition inaccurately implied an age and outdatedness to the certification criteria we had adopted. More importantly, we heard significant positive feedback that the incremental approach to updates is generally beneficial as a long-term approach. Specifically, we heard that a consistent, transparent, incremental update cycle that includes the following features would be preferred by some: (1) regular updates to recognize standards advancement and an allowance for voluntary standards advancement between updates, (2) incremental updates rather than wholesale certified Health IT Module certification criteria overhauls, (3) a predictable timeline for updates based on standards development cycles with reasonable development timelines, and (4) a reasonable development timeline for any new criterion based on the specific development needs.

For these reasons, we no longer believe that it is helpful or necessary to maintain an “edition” naming convention or to adopt entirely new editions of certification criteria to encapsulate updates over time. Instead, we believe there should be a single set of certification criteria, which will be updated in an incremental fashion in closer alignment to standards development cycles and regular health IT development timelines. Therefore, in section III.A, we propose to rename all criteria within the Program simply as “ONC Certification Criteria for Health IT.” We believe maintaining a single set of “ONC Certification Criteria for Health IT” would create more stability for the Program and for federal partners who reference the Program, as well as make it easier for developers of certified health IT to maintain their product certificates over time. This proposal to remove “editions” from the Program would also help users of certified health IT identify which certification criteria are necessary for their participation in other HHS programs, such as Medicare Promoting Interoperability Program and the Promoting Interoperability performance category of the MIPS. For example, users would only need to know that their Health IT Module is certified by ONC in accordance with the ONC Certification Criteria for Health IT for successful participation in MIPS, as compared to the current state where they must also know if the Health IT Module complies with the 2014 Edition Certification Criteria, the 2015 Edition Certification Criteria, or the 2015 Edition Cures Update Certification Criteria.

In addition, we believe that this approach will have the benefit of reducing administrative burden for health IT developers with Health IT Modules certified through the Program. Previously, duplicative references to certification criteria across different year themed editions created administrative burden on developers as they had the effect of requiring health IT developers to seek an updated certificate attributed to the “new” duplicated certification criterion even in circumstances when the certification criterion remained substantively unchanged. Under this proposal, unchanged certification criteria would no longer be duplicated as separate criteria under multiple editions.

b. New and Revised Standards and Certification Criteria

i. The United States Core Data for Interoperability Standard Version 3 (USCDI v3)

In the ONC Cures Act Final Rule, ONC adopted the United States Core Data for Interoperability (USCDI) as a standard to replace the Common Clinical Data Set (CCDS) in several ONC

certification criteria (85 FR 25670). We adopted USCDI Version 1 (USCDI v1) as a standard in § 170.213 and incorporated it by reference in § 170.299. The new USCDI v1 standard established a set of data classes and constituent data elements required to support interoperability nationwide. USCDI v1 is a required part of certain certification criteria updates that were made to the existing 2015 Edition Health IT Certification Criteria in the ONC's Cures Act Final Rule. These changes constitute the “2015 Edition Cures Update.”

ONC also indicated in the ONC Cures Act Final Rule that we intended to establish and follow a predictable, transparent, and collaborative process to expand future versions of the USCDI, including providing the public with the opportunity to comment on the USCDI's expansion (85 FR 25670). ONC established a process, including creating the ONC New Data Element and Class (ONDEC) submission system,

which provides the public with the opportunity to submit new data elements to be considered for inclusion in future versions of USCDI. Following this established process, ONC published USCDI Version 2 (USCDI v2) in July 2021

and finalized and released USCDI Version 3 (USCDI v3) in July 2022.

Both USCDI v2 and USCDI v3 contain new data elements and data classes beyond what was included in USCDI v1. USCDI v3 contains all data elements and classes added in USCDI v2.

ONC. (2020, July 27). USCDI ONDEC. Retrieved March 16, 2023, from

https://www.healthit.gov/isa/ONDEC

ONC. (2021, July 2).

United States Core Data for Interoperability (USCDI).

Interoperability Standards Advisory (ISA). Retrieved March 16, 2023, from

https://www.healthit.gov/isa/united-states-core-data-interoperability-uscdi#uscdi-v2.

United States Core Data for Interoperability (USCDI),” Interoperability Standards Advisory (ISA) (ONC, July 5, 2022),

https://www.healthit.gov/isa/united-states-core-data-interoperability-uscdi#uscdi-v3.

Because USCDI is the standard for data required to be accessible through certified health IT for numerous certification criteria, expanding the data elements and data classes included in USCDI increases the amount of data available to be used and exchanged for patient care. To advance interoperability, in section III.C.1, ONC proposes to add the newly released USCDI v3 in § 170.213(b). We propose that USCDI v1 would remain in regulation and now be codified in § 170.213(a) and we propose to add USCDI v3 to § 170.213 (to be codified as § 170.213(b)). We also propose to incorporate by reference USCDI v3 in § 170.299 as of the effective date of the final rule. In addition, we propose that the USCDI v1 (July 2020 Errata) in the USCDI standard in § 170.213(a) will expire on January 1, 2025. Under this proposal, both versions would be referenced as applicable in the USCDI standard in § 170.213 for the time period up to and including December 31, 2024.

ii. C-CDA Companion Guide Updates

In section III.C.2, we propose to adopt the HL7® CDA® R2 Implementation Guide: C-CDA Templates for Clinical Notes STU Companion Guide, Release 3—US Realm (C-CDA Companion Guide R3) in § 170.205(a)(6). The C-CDA Companion Guide R3 provides supplemental guidance and additional technical clarification for specifying data in the C-CDA Release 2.1, including data specified in USCDI v2. However, it is our understanding that HL7 is working on updating the C-CDA Companion Guide for USCDI v3. If the updated C-CDA Companion Guide Release 4 (R4) is published before the date of publication of the final rule, it is our intention to consider adopting the updated Companion Guide that provides guidance and clarifications for specifying data in USCDI v3.

iii. “Minimum Standards” Code Sets Updates

In the 2015 Edition Final Rule, we established a policy of adopting newer versions of “minimum standards” code sets that update frequently (80 FR 62612). Adopting newer versions of these code sets enables improved interoperability and implementation of health IT with minimal additional burden (77 FR 54170). If adopted, newer versions of these 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. 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.C.3, we propose to adopt newer versions of the following minimum standards code sets:

• § 170.207(a)—Problems

• § 170.207(c)—Laboratory tests

• § 170.207(d)—Medications

• § 170.207(e)—Immunizations

• § 170.207(f)—Race and ethnicity

• § 170.207(m)—Numerical references

• § 170.207(n)—Sex

• § 170.207(o)—Sexual orientation and gender information

• § 170.207(p)—Social, psychological, and behavioral data

• § 170.207(r)—Provider type

• § 170.207(s)—Patient insurance

In addition to updating the minimum standards code sets listed above, we propose to update some of the certification criteria that reference those minimum standards. These criteria include § 170.315(a)(5)(i)(A)(

) and (

), (a)(5)(i)(C) through (E), (a)(12), (b)(1)(iii)(B)(

), (b)(1)(iii)(G)(

), (b)(6)(ii)(B)(

), (c)(4)(iii)(C), (c)(4)(iii)(E), (c)(4)(iii)(G) through (I), (f)(1)(i)(B) and (C), (f)(3)(ii), and (f)(4)(ii).

We also propose to change the heading of § 170.207(o) from “sexual orientation and gender identity” to “sexual orientation and gender information” to acknowledge that § 170.207(o) may include standard code sets to support other gender related data items.

iv. Electronic Case Reporting

In section III.C.4 of this proposed rule, we propose to revise the “transmission to public health agencies—electronic case reporting” criterion in § 170.315(f)(5) to adopt consensus-based, industry-developed electronic standards and implementation guides (IGs) to replace all functional, descriptive requirements in the present criterion in § 170.315(f)(5). These standards are proposed to support the following requirements for Health IT Modules certified to § 170.315(f)(5): (i) create a case report for electronic transmission; (ii) consume and process a case report response; and (iii) consume and process electronic case reporting trigger codes and parameters. We note that these electronic standards are standards-based representations of the functional requirements described in the existing criterion in § 170.315(f)(5) as described in section III.C.4 of this preamble.

v. Decision Support Interventions and Predictive Models

In section III.C.5 of this proposed rule, we propose the certification criterion, “decision support interventions (DSI)” in § 170.315(b)(11). The DSI criterion is a revised certification criterion as it serves as both an iterative and replacement criterion for the “clinical decision support (CDS)” criterion in § 170.315(a)(9). This criterion would reflect an array of contemporary functionalities, data elements, and software applications, including the use of predictive models or algorithms, that certified Health IT Module(s) enable or interface with to aid decision-making in healthcare.

We propose to adopt a new definition for “predictive decision support intervention,” in § 170.102, and we propose that developers of certified health IT with Health IT Module(s) certified to the criterion we propose in § 170.315(b)(11) that enable or interface with predictive DSIs would be subject to requirements to provide transparency of predictive DSIs. Specifically, we propose that Health IT Modules that enable or interface with predictive DSIs enable a user to review predictive DSI “source attribute” information through the Health IT Module. We also propose that developers of certified health IT with Health IT Modules that enable or interface with predictive DSIs employ or engage in “intervention risk management” practices. We also propose that summary information regarding these intervention risk management practices be made available via a publicly accessible hyperlink. Together, our proposals for predictive DSI-specific source attributes and intervention risk management practices information are intended to provide appropriate information to help guide medical decisions at the time and place of care, consistent with 42 U.S.C. 300jj-11(b)(4).

We propose that Health IT Modules certified to § 170.315(b)(11) enable users to provide feedback regarding DSI information displayed through the Health IT Module, and that such Health IT Modules make available such feedback data for export in a computable format.

We propose that developers of certified health IT with Health IT Modules certified to § 170.315(b)(11) comply with these new requirements by December 31, 2024. For the intervening time between finalization of this proposed rule and December 31, 2024, we propose to add § 170.315(a)(9) to the list of applicable certification criteria for the real-world testing Condition and Maintenance of Certification requirement in § 170.405(a), thus requiring developers of certified health IT with Health IT Module(s) certified to § 170.315(a)(9) or § 170.315(b)(11) to participate in real world testing plan and results submission.

Finally, we propose to update the Base EHR definition in § 170.102 to include an option of either the existing “clinical decision support (CDS)” version of the criterion in § 170.315(a)(9) or the revised “decision support interventions” criterion in § 170.315(b)(11) for the period up to and including December 31, 2024, and to include only “decision support interventions” in § 170.315(b)(11) on and after January 1, 2025. We discuss in section III.C.5.d of this preamble proposals that would constitute changes to the CDS criterion, as the new DSI criterion. We describe how much of the structure and requirements are duplicated across these criteria and reflect the capabilities included in the CDS criterion with which Program participants have years of familiarity and can find, for comparison purposes, in § 170.315(a)(9).

vi. Synchronized Clocks Standard

We propose in section III.C.6 to remove the current named specification for clock synchronization, which is Network Time Protocol (NTP v4 of RFC 5905), in § 170.210(g), based on public feedback and reflective of contemporary norms within the industry. Additionally, we propose to keep the requirement for any network time protocol (NTP) standard to be present, though any NTP standard could be used.

vii. Standardized API for Patient and Population Services

We propose in section III.C.7 to revise the “standardized API for patient and population services” certification criterion in § 170.315(g)(10) in several ways. We propose to require a certified Health IT Module's authorization server to issue a refresh token according to the implementation specification adopted in § 170.215(c). The token should be valid for a period of no less than three months and will apply to all applications using the “confidential app” profile for both first time and subsequent connections.

We also propose to adopt the FHIR US Core Implementation Guide STU version 5.0.1 in § 170.215(b)(1)(ii). Based on the annual US Core release cycle, we believe US Core IG v6.0.0 will be published before ONC issues a final rule.

Therefore, it is our intent to consider adopting the updated US Core IG v6.0.0 that supports the data elements and data classes in USCDI v3 since we propose to adopt USCDI v3 in this rule. Health IT systems that adopt this version of the US Core IG can provide the latest consensus-based capabilities for providing access to USCDI data classes and elements using a FHIR API.

http://hl7.org/fhir/us/core/history.html.

Additionally, we propose to amend the API Condition and Maintenance of Certification requirements by adding the requirement that Certified API Developers with patient-facing apps must publish their service base URLs for all customers, regardless of whether the certified Health IT Modules are centrally managed by the Certified API Developer or locally deployed by an API Information Source, according to a specified format.

We also propose to revise the requirement in § 170.315(g)(10)(vi) to specify that Health IT Modules presented for certification that allow short-lived access tokens to expire, in lieu of immediate access token revocation, must have such access tokens expire within one hour of the request. This revised requirement would align with industry standard practice for short-lived access tokens, would provide clarity and consistent expectations that developers revoke access or expire access privileges within one hour of a request, and would offer patients an assurance that an application's access to their data would be revoked or expired within one hour of a request.

We propose to adopt the Substitutable Medical Applications, Reusable Technologies (SMART) Application Launch Framework Implementation Guide Release 2.0.0 (SMART v2 Guide) in § 170.215(c)(2), which would replace SMART v1 Guide as the standard in § 170.215(a)(3) (proposed in this rule as § 170.215(c)(1)). The SMART v2 Guide iterates on the features of the SMART v1 Guide by including new features and technical revisions based on industry consensus, including features that reflect security best practices. We propose that the availability of the SMART v1 Guide to be adopted as a standard in the Program would expire on January 1, 2025. After this time, the SMART v2 Guide would be the only version of the IG available for use in the Program.

viii. Patient Demographics and Observations Certification Criterion in § 170.315(a)(5)

In section III.C.1 of this proposed rule, we introduce proposals to change certain data elements in USCDI, namely Sex (Assigned at Birth), Sexual Orientation, and Gender Identity, that are also data elements in § 170.315(a)(5). We propose these changes to reflect public feedback that the standards and terms used to represent these data elements needed to be updated. Therefore, to ensure consistency, in section III.C.8 of this preamble, we propose to change the name of the certification criterion in § 170.315(a)(5) from “demographics” to “patient demographics and observations.” Additionally, in order to ensure consistent capture of these data elements across health IT, we propose in section III.C.8 to carry these changes

into their respective data elements in § 170.315(a)(5).

We propose to replace the specific codes sets referenced in § 170.315(a)(5)(i)(D) and (E), Sexual Orientation and Gender Identity, respectively, with the Systematized Nomenclature of Medicine Clinical Terms (SNOMED CT®) code set, as referenced in the standard proposed in § 170.207(o)(3). We propose that the adoption of the code sets referenced in § 170.207(n)(1) would expire on January 1, 2026, and we also propose that health IT developers can continue to use the specific codes in the current terminology standard until December 31, 2025, in order to provide adequate time for health IT systems to transition to the updated terminology standards.

As also discussed in section III.C.1 of this proposed rule, we have taken note of efforts to develop clinically relevant ways of identifying a patient's sex based on observations, to be used by a patient's clinician when considering or evaluating diagnostic or therapeutic services in areas such as radiology, laboratory, and genetic testing. The concept “Sex For Clinical Use” (SFCU) is seen as a valuable tool in addressing these concerns and therefore important for clinical capture. We also propose to add SFCU as a new data element in § 170.315(a)(5)(i)(F). Additionally, we propose to add new data elements “Name to Use” in § 170.315(a)(5)(i)(G) and “Pronouns” in § 170.315(a)(5)(i)(H), to facilitate data capture that supports providers' ability to provide culturally competent care for their patients.

ix. Updates to Transitions of Care Certification Criterion in § 170.315(b)(1)

We propose in section III.C.9 to update the “transitions of care” certification criterion (§ 170.315(b)(1)) to align it with changes proposed in § 170.213, including the proposed adoption of USCDI v3 in § 170.213(b)). This change would ensure that Health IT Modules certified to § 170.315(b)(1) are capable of accessing, exchanging, and using USCDI data elements referenced in § 170.213.

x. Patient Requested Restrictions Certification Criterion

We believe that individuals should be provided a reasonable opportunity and technical capability to make informed decisions about the collection, use, and disclosure of their electronic health information. The Health Insurance Portability and Accountability Act (HIPAA)

Privacy Rule

provides individuals with several legal, enforceable rights intended to empower them to be more active participants in managing their health information. We make several proposals in support of the HIPAA Privacy Rule's individuals' “right to request a restriction” on certain uses and disclosures of their PHI (

see also

45 CFR 154.522(a)). We propose to adopt a new certification criterion, revise a certification criterion, and propose modifications for Health IT Modules certified to specific criteria under the Privacy and Security certification Framework.

Public Law 104-191,110 Stat. 1936 (August 21, 1996), codified at 42 U.S.C. 1320d-1320d8.

45 CFR part 160 and subparts A and E of part 164.

We propose a new certification criterion in § 170.315(d)(14), an addition to ONC's Privacy and Security Certification Framework under the Program in § 170.550(h), and a revision to an existing criterion in § 170.315(e)(1) to support additional tools for implementing patient requested information privacy restrictions.

xi. Requirement for Health IT Developers To Update Their Previously Certified Health IT

We propose to make explicit in the introductory text in § 170.315 that health IT developers voluntarily participating in the Program must update their certified Health IT Modules and provide that updated certified health IT to customers in accordance with the timelines defined for a specific criterion or standard included in § 170.315. More specifically, we propose in section III.C.11 that health IT developers with health IT certified to any of the certification criteria in § 170.315 would need to update their previously certified Health IT Modules to be compliant with any revised certification criterion adopted in § 170.315, including any new standards adopted in 45 CFR part 170 subpart B and capabilities included in the revised certification criterion. We further propose that health IT developers would also need to provide the updated heath IT to customers of the previously certified health IT according to the timelines established for that criterion and any applicable standards.

2. Assurances Condition and Maintenance of Certification Requirements

We propose in section III.D to establish additional Assurances Condition and Maintenance of Certification requirements. We propose as a Condition of Certification that a health IT developer must provide an assurance that it will not interfere with a customer's timely access to interoperable health IT certified under the Program. To support this assurance, we propose two accompanying Maintenance of Certification requirements. We propose that a health IT developer must update a Health IT Module, once certified to a certification criterion adopted in § 170.315, to all applicable revised certification criteria, including the most recently adopted capabilities and standards included in the revised certification criterion. We also propose that a health IT developer must provide all Health IT Modules certified to a revised certification criterion to its customers of such certified health IT. Additionally, we propose separate “timely access” or “timeliness” requirements for each of the two proposed Maintenance of Certification requirements above dictating by when a Health IT Module must be updated to revised certification criteria and by when a Health IT Module certified to a revised certification criterion must be provided to the health IT developer's customers.

3. Real World Testing—Inherited Certified Status

Section 4002(a) of the Cures Act added a new Condition and Maintenance of Certification requirement that health IT developers must successfully test the real-world use of health IT for interoperability in the type(s) of setting(s) in which such technology would be marketed. Many health IT developers update their certified Health IT Module(s) on a regular basis leveraging the flexibility provided through ONC's Inherited Certified Status (ICS).

Because of the way that ONC issues certification identifiers, this updating can cause an existing certified Health IT Module to be recognized as new within the Program. Regular updating, especially on a frequent basis (such as quarterly or semi-annually) creates an anomaly that could result in existing certified Health IT Modules being inadvertently excluded from the real world testing reporting requirements.

ONC, Applicability Of Inherited Certified Status And Gap Certification (2016).

https://www.healthit.gov/sites/default/files/policy/public_applicability_of_gap_certification_and_inherited_certified_status.pdf.

In order to ensure that all developers continue to test the real world use of their technology as required, we propose in section III.E to eliminate this anomaly by requiring health IT developers to include in their real world

testing results report the newer version of those certified Health IT Module(s) that are updated using Inherited Certified Status after August 31 of the year in which the plan is submitted. This will ensure that health IT developers fully test all applicable certified Health IT Module(s) as part of their real world testing requirements.

4. Insights Condition and Maintenance of Certification

The Cures Act specified requirements in section 4002(c) to establish an Electronic Health Record (EHR) Reporting Program to provide transparent 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. The Cures Act also specified that a health IT developer be required, as a Condition and Maintenance of Certification requirement under the ONC Health IT Certification Program, to submit responses to reporting criteria in accordance with the Electronic Health Record Reporting Program established with respect to all certified technology offered by such developer. For clarity purposes, we intend to refer to the Condition and Maintenance of Certification associated with the “EHR Reporting Program” as the “Insights” Condition and Maintenance of Certification (also referred to as the “Insights Condition”) throughout this proposed rule. We believe this descriptive name captures the essence of this requirement and will help avoid confusion that might occur through use of the term “EHR Reporting Program.”

We propose in section III.F to adopt nine reporting measures for developers of certified health IT that focus initially on the interoperability category, emphasizing four areas of interoperability: individuals' access to electronic health information, public health information exchange, clinical care information exchange, and standards adoption and conformance. Through this first set of proposed measures, ONC intends to provide insights on the interoperability category specified in the Cures Act. We intend to explore the other Cures Act categories (security, usability and user-centered design, conformance to certification testing, and other categories to measure the performance of EHR technology) in future years.

We also propose in section III.F to implement the Insights Condition and Maintenance of Certification requirements in § 170.407 in two phases, where some of the measures will be required to be reported earlier than others. For each proposed measure, we have included information on the rationale for proposing the measure, the proposed numerators and denominators, and other key topics. Overall, the intent of the Insights Condition is to provide transparent reporting, address information gaps in the health IT marketplace, and provide insights on the use of health IT.

5. Information Blocking Enhancements

We propose in section IV.A to define what it means to “offer health information technology” or “offer health IT” for purposes of the information blocking regulations in 45 CFR part 171. This definition of what it means to

offer health IT

would, as proposed, narrow the applicability of the health IT developer of certified health IT definition. While the definition of

offer health IT

proposed at 45 CFR 171.102 would generally continue to include holding out for sale, selling, or otherwise supplying certified health IT to others on commercial or other terms, it would carve out by explicit exclusion the provision of funding for obtaining or maintaining certified health IT. The proposed definition would also explicitly codify that we do not interpret health care providers or other health IT users to offer health IT when they engage in certain activities customary and common amongst both health care providers that purchase certified health IT from a commercial developer or reseller and health care providers that self-develop certified health IT. Activities we propose to codify as explicitly excluded from the definition of what it means to

offer health IT

include implementing APIs or portals for clinician or patient access as well as the issuance of login credentials allowing licensed healthcare professionals who are in independent practice to use a hospital or other healthcare facility's EHR to furnish and document care to patients in the hospital or other healthcare facility. We also include a proposal to potentially exclude from what it means to

offer health IT

the inclusion of health IT in a package of items, supplies, facilities, and services that a management consultant handles for a clinician practice or other health care provider in a comprehensive (“turn key”) package of services for administrative or operational management of the clinician practice or other health care provider (see section IV.A.1.c, below). Finally, we seek comment on the proposed definition of

offer health IT

and whether we should consider additional exclusions.

We also propose in section IV.A to modify the

health IT developer of certified health IT

definition so that it is clear that health care providers who self-develop certified health IT would continue to be excluded from this definition if they supply their self-developed certified health IT to others under arrangements excluded from the definition of what it means to

offer health IT.

This would treat self-developer health care providers who supply use of their self-developed certified health IT to others under arrangements, or in the course of activities, excluded from the proposed

offer health IT

definition in the same way that we treat health care providers who supply commercial developers' certified health IT under arrangements, or in the course of activities, excluded from the

offer health IT

definition.

We propose in section IV.A to revise the text of § 171.103, the information blocking definition, to remove paragraph (b) (

see

§ 171.103(b)). Paragraph (b) established the period of time during which electronic health information (EHI) for purposes of the information blocking definition (§ 171.103) was limited to a subset of electronic health information (EHI) that was identified by the data elements represented in the USCDI standard adopted in 171.213. The end date of that period of time, October 5, 2022, has passed. On and after October 6, 2022, the scope of EHI for purposes of the information blocking definition (§ 171.103) is EHI as defined in § 171.102 and thus paragraph (b) of § 171.103 is no longer needed.

We note that we do not propose to change the scope of EHI for purposes of the information blocking definition, only to update the CFR text to remove the paragraph specific to the period of time now passed. Similarly, because we included the same time period in reference to the scope of electronic health information in two paragraphs of the Content and Manner exception (§ 171.301(a)(1) and (2)), we propose to revise § 171.301 to remove from the regulatory text the existing § 171.301(a)(1) and (2) as no longer necessary.

We propose in section IV.B to revise the Infeasibility Exception codified in 45 CFR 171.204(a) by adding two new conditions and by revising one existing condition to further clarify when an actor's practice of not fulfilling a request for access, exchange, or use of EHI meets the condition. First, we propose to revise the “uncontrollable events” condition in § 171.204(a)(1) to further

clarify when an actor's practice meets the uncontrollable events condition. Second, we propose to add two new conditions to be codified as subparagraphs (a)(3) and (a)(4), and to therefore renumber the “infeasible under the circumstances” condition currently codified in § 171.204(a)(3) as (a)(5).

The first new infeasibility condition would apply to an actor's practice of denying a third party's request to enable use of EHI in order to modify EHI, including but not limited to creation and deletion functionality, provided the request is not from a health care provider requesting such use from an actor that is its business associate. The second new infeasibility condition would apply where an actor has exhausted the manner exception in § 171.301, including offering all alternative manners in accordance with § 171.301(b), and the actor does not currently provide a substantial number of individuals or entities similarly situated to the requestor with the same requested access, exchange, or use of the requested EHI.

We also seek comment on ways health IT can support EHI segmentation for access, exchange, and use of EHI; and particularly how the Program, through the certification of health IT to certain functionalities and/or standards, can support EHI segmentation for access, exchange, and use, including to assist health care providers with sharing EHI consistent with patient preferences and all laws applicable to the creation, use, and sharing of EHI.

Additionally, in section IV.B, we propose to add a Trusted Exchange Framework and Common Agreement (TEFCA) condition to the proposed revised and renamed Manner Exception, proposed to be codified in 45 CFR 171.301. This proposal aligns with a foundational policy construct underpinning the Manner Exception in that it facilitates an actor reaching agreeable terms with a requestor to fulfill an EHI request and acknowledges that certain agreements have been reached between these parties for the access, exchange, and use of EHI.

C. Costs and Benefits

E.O. 12866 on Regulatory Planning and Review and E.O.13563 on Improving Regulation and Regulatory Review 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). 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 $100 million or more in any 1 year, or adversely and materially affecting a sector of the economy, productivity, competition, jobs, the environment, public health or safety, or State, local 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 novel legal or policy issues arising out of legal mandates, the President's priorities, or the principles set forth in the Executive Order. A regulatory impact analysis (RIA) must be prepared for major rules with significant effects as per section 3(f)(1)) ($100 million or more in any one year). OMB has determined that this proposed rule is a significant rule as the potential costs associated with this proposed rule could be greater than $100 million per year. Accordingly, we have prepared an 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 35.

We note that we have rounded all estimates to the nearest dollar and that all estimates are expressed in 2021 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 2021 National Occupational Employment and Wage Estimates reported by the U.S. Bureau of Labor Statistics.

We also note that estimates presented in the following “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” sections are used throughout this RIA.

May 2021 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 after it is finalized (including one-time costs), based on the cost estimates outlined above and throughout this RIA, would result in $742 million. The total undiscounted perpetual cost over a 10-year period for this proposed rule (starting in year three), based on the cost estimates outlined above, would result in $712 million. We estimate the total costs to health IT developers to be $742 million and estimate the government (ONC) costs to be between $62,000 to $124,000.

We estimate the total annual benefit for this proposed rule, based on the benefit estimates outlined above, would be on average $1.0 billion. We estimate the total undiscounted perpetual annual net benefit for this proposed rule (starting in year three), based on the estimates outlined above, would be $326 million.

II. Background

A. Statutory Basis

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

The 21st Century Cures Act, Public Law 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 PDP 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 is capable of integrating 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. Health IT Certification Program(s)

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 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 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 programing 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 certification 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 correction notice 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 electronic health record 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 (PI) Programs) 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-Authorized Certification Bodies (ONC-ACBs).

After issuing a proposed rule on March 2, 2016, “ONC Health IT Certification Program: Enhanced Oversight and Accountability” (81 FR 11056), we published a final rule by the same title (81 FR 72404) (EOA Final Rule) on October 19, 2016. The EOA Final Rule finalized modifications and new requirements under the Program, including provisions related to our role in the Program. The final rule created a regulatory framework for our direct review of health IT certified under the Program, including, when necessary, requiring the correction of non-conformities found in health IT certified under the Program and suspending and terminating certifications issued to Complete EHRs and Health IT Modules. The final rule also set forth processes for us to authorize and oversee accredited testing laboratories under the Program. In addition, it included provisions for expanded public availability of certified health IT surveillance results.

On March 4, 2019, the Secretary published a proposed rule titled, “21st Century Cures Act: Interoperability, Information Blocking, and the ONC Health IT Certification Program” (84 FR 7424) (ONC Cures Act Proposed Rule). The proposed rule proposed to implement certain provisions of the Cures Act that would advance interoperability and support the access, exchange, and use of electronic health information. We also requested comment in the ONC Cures Act Proposed Rule (84 FR 7467) as to whether certain health IT developers should be required to participate in TEFCA as a means of providing assurances to their customers and ONC that they are not taking actions that constitute information blocking or any other action that may inhibit the appropriate exchange, access, and use of EHI, with the goal of developing or supporting TEFCA for the purpose of ensuring full network-to-network exchange of health information.

On May 1, 2020, 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). This final rule implemented certain provisions of the Cures Act, including Conditions and Maintenance of Certification requirements for health information technology (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 January 19, 2022, we published a notice titled, “Notice of Publication of the Trusted Exchange Framework and Common Agreement” (87 FR 2800) (“TEFCA”). The notice fulfilled an obligation under section 3001(c)(9)(C) of the PHSA, which requires the National Coordinator for Health Information Technology to publish on the Office of the National Coordinator for Health Information Technology's public internet website, and in the

Federal Register

, the trusted exchange framework and common agreement developed under the PHSA.

III. ONC Health IT Certification Program Updates

A. “The ONC Certification Criteria for Health IT ” and Discontinuing Year Themed “Editions”

ONC first introduced the concept of an “edition” of ONC health IT certification criteria in 2012. In March 2012, in the 2014 Edition Proposed

Rule,

to make a clear distinction between the certification criteria finalized in the 2010 ONC “Health Information Technology: Initial Set of Standards, Implementation Specifications, and Certification Criteria for Electronic Health Record Technology” interim final rule (75 FR 20132047) and adopted in §§ 170.302, 170.304, and 170.306 (to support “Stage 1 meaningful use criteria”) and the certification criteria proposed for adoption in § 170.314 (to support “Stage 2 meaningful use criteria”) (77 FR 13832), we discussed that we would use an “edition” naming approach for the sets of certification criteria subsequently adopted by the Secretary (77 FR 13836). We stated that we would refer to the certification criteria adopted in §§ 170.302, 170.304, and 170.306 collectively as the “2011 Edition EHR certification criteria” and that the certification criteria adopted in § 170.314 would be referred to as the “2014 Edition EHR certification criteria” (77 FR 13836). We finalized this approach and adopted a “2014 Edition” in a September 2012 final rule (77 FR 54163) (the 2014 Edition Final Rule). Overall, we created the concept of certification criteria “editions” with the expectation that it would make it easier for developers of certified health IT and health care providers to quickly determine the certification criteria to which their health IT would need to be certified to remain in compliance with CMS program requirements regarding the use of certified EHR technology (CEHRT) (77 FR 54167).

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

We coined the “2011 Edition” and “2014 Edition” because the edition's name was designed to coincide with the first year in which compliance with that edition of certification criteria was required for use under the Medicare and Medicaid EHR Incentive Programs (79 FR 54431). We thought this approach would simplify communications related to the certification criteria editions and enable clear compliance statements like “an EP needs to be using 2014 Edition CEHRT when they demonstrate meaningful use . . . in CY 2014” (79 FR 54431). This approach resulted for many people in a direct, and limited in scope, link between certification criteria editions and “meaningful use” even though these certification criteria were already being referenced by other HHS programs (

e.g.,

the CMS and HHS Office of the Inspector General (OIG) final rules to modify the Physician Self-Referral Law exception and Anti-kickback Statute safe harbor for certain EHR donations (78 FR 78751) and (78 FR 79202), respectively).

The CMS final rule is titled “Medicare Program; Physicians' Referrals to Health Care Entities with Which They Have Financial Relationships: Exception for Certain Electronic Health Records Arrangements” (78 FR 78751). The OIG final rule is titled “Medicare and State Health Care Programs: Fraud and Abuse; Electronic Health Records Safe Harbor Under the Anti-Kickback Statute” (78 FR 79201).

In September 2014, we issued a final rule to update the 2014 Edition with “2014 Edition Release 2” certification criteria and to remove the 2011 Edition from the Code of Federal Regulations (CFR) starting in 2015 (79 FR 54430). At that time, EHR technology certified to the 2011 Edition had become outmoded, no longer met the CEHRT definition, and no longer supported an acceptable level of interoperability (79 FR 54447). Further, as referenced by OIG and CMS in the rulemakings completed by those agencies around donations of EHR items and services, we had planned to retire old or no longer applicable certification criteria editions ((78 FR 79205) and (78 FR 78754), respectively). During this same time period, we jointly issued with CMS a final rule (79 FR 52910) that allowed for continued use of 2011 Edition CEHRT in combination with 2014 Edition CEHRT within 2014, which allowed for certain providers to meet meaningful use requirements with EHRs certified to the 2011 or the 2014 Edition criteria, or a combination of both editions, for an EHR Reporting Period in 2014.

The rule also extended Stage 2 through 2016, meaning that providers who first attested to meaningful use in 2011 or 2012 would remain in Stage 2 for an additional year (79 FR 52926). These actions further demonstrated that linking a certification criteria edition's year to any other program's compliance date had drawbacks and could ultimately confuse the original intent of the edition's year selection. This experience also highlighted unintended negative impacts stemming from this approach of packaging all ONC certification criteria into discrete editions, even where those editions might have overlapping criteria. Specifically, the editions approach had two major negative impacts relating to how updates were implemented: (1) it required all developers and providers to update their systems by a specific date, and (2) it required all developers and providers to update their systems to all edition criteria even where criteria may overlap or only have minor revisions between editions.

The CMS final rule is titled “Medicare and Medicaid Programs; Modifications to the Medicare and Medicaid Electronic Health Record (EHR) Incentive Program for 2014 and Other Changes to the EHR Incentive Program; and Health Information Technology: Revisions to the Certified EHR Technology Definition and EHR Certification Changes Related to Standards” (79 FR 52909).

Accordingly, we set out to establish a simpler approach that could be used for future certification criteria editions. First, we intentionally adopted an overlapping transition period from any one edition to a subsequent edition (

e.g.,

the 2014 Edition to the subsequent edition). Second, we modified our approach to name the edition for

the year in which the final rule was published,

and subsequent rulemakings that include additional criteria or alternatives to previously adopted certification criteria would be added to the most current edition of certification criteria (79 FR 54431). To further clarify, we stated that a rulemaking that does not adopt an edition of certification criteria would be referred to as “[current edition year] Release #X” (79 FR 54431). We intended this approach to provide the public with predictable naming expectations for future editions and to support ONC's broader interests to have the Program be generally accessible to other programs designed to use certified health IT, either within or outside government. Developers of certified health IT and health care providers that sought to leverage the Program would then be able to choose which edition of certification criteria (or subset of criteria within an edition) was most relevant and appropriate for their program needs for the time their program requirements would be applicable (79 FR 54431).

Following this approach, in 2015, ONC issued a final rule, “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) and adopted the “2015 Edition Health IT Certification Criteria” (80 FR 62602). We codified the 2015 Edition certification criteria in § 170.315 to set them apart from other editions of certification criteria (80 FR 62608). Importantly, the program compliance requirements for certain health care providers to use 2015 Edition certified health IT was ultimately set by CMS to start in 2019 (83 FR 41144).

The CMS final rule is titled “Medicare Program; Hospital Inpatient Prospective Payment Systems for Acute Care Hospitals and the Long-Term Care Hospital Prospective Payment System and Policy Changes and Fiscal Year 2019 Rates; Quality Reporting Requirements for Specific Providers; Medicare and Medicaid Electronic

Health Record (EHR) Incentive Programs (Promoting Interoperability Programs) Requirements for Eligible Hospitals, Critical Access Hospitals, and Eligible Professionals; Medicare Cost Reporting Requirements; and Physician Certification and Recertification of Claims” (83 FR 41144).

Four years later, as part of implementation of the 21st Century Cures Act, we issued the 21st Century Cures Act: Interoperability, Information Blocking, and the ONC Health IT Certification Program Proposed Rule (84 FR 7424) to update to the 2015 Edition, mindful that 2015 Edition certified health IT was just being implemented. In 2020, we published the ONC Cures Act Final Rule (85 FR 25642) and adopted updates to the 2015 Edition. These updates included new certification criteria, standards, and requirements, as well as incremental revisions to existing 2015 Edition certification criteria to better enable interoperability and the access, exchange, and use of EHI (85 FR 25664-65). Because we did not adopt a new edition of certification criteria in a different CFR section, we retained the overall 2015 Edition title for the changes included in the ONC Cures Act Final Rule and made specific timebound compliance changes within certification criteria.

In the final rule, we stated that we considered a variety of factors when we determined to update the 2015 Edition rather than adopt a new “edition.” First, we reviewed the scope of each proposed update and the cumulative scope of the proposals overall for health IT developers and sought to identify whether it would be more appropriate to require health IT developers participating in the Program to implement updates to Health IT Modules certified to the 2015 Edition or to test and certify health IT products to an entirely new edition of certification criteria. Second, we considered the impact that either approach would have on health care providers, including how such updated Health IT Modules or products certified to a new edition would be implemented by providers participating in CMS programs. We also noted that historically, with a new edition of certification criteria, health IT developers have packaged Health IT Modules certified to new, revised, and unchanged criteria into a wholly new certified product. We observed that historical data indicated that these complete updates to the edition were particularly challenging for both health IT developers seeking certification and for health care providers as they establish deadlines for a significant number of health IT developers to support and implement new products for a significant number of health care providers simultaneously. As a result, the burden of updating the technology is compounded for both health IT developers and health care providers (85 FR 25665).

Our intent with this approach was to maintain a single set of certification criteria that have been updated to include the most recent versions of adopted standards, and to establish an incremental approach to health IT updates over time. In the ONC Cures Act Final Rule, we stated our belief that this approach should also include development timelines based on the updates required for each criterion and a transition period allowing for multiple standards to be used for a reasonable period of time. We noted our belief that, as a whole, this approach can help to reduce the burden on health IT developers and health care providers and could allow health IT developers to implement updates in the manner most appropriate for their product and their customers (85 FR 25665). Commenters noted this approach would provide stability and that an incremental approach best serves the health care provider and health IT developer community (85 FR 25664).

However, in response to public comment related to how we communicate and avoid public confusion (85 FR 25666), we distinguished the “original” 2015 Edition certification criteria from the new and revised 2015 Edition certification criteria by referring to the updates we adopted as the 2015 Edition “Cures Update” certification criteria. Subsequent to publication of the final rule, through public meetings and correspondence, we have been informed that the continued use and reference to the 2015 Edition inaccurately implied an age and outdatedness to the certification criteria we had adopted. More importantly, we have received significant positive feedback expressing that the incremental approach to updates is generally beneficial as a long-term approach. Specifically, feedback conveyed that a consistent, transparent, incremental update cycle that includes the following features would be preferred by some: (1) regular updates to recognize standards advancement and an allowance for voluntary standards advancement between updates, (2) incremental updates rather than “wholesale” product overhauls, (3) a predictable timeline for updates based on standards development cycles with reasonable development timelines, and (4) a reasonable development timeline for any new criterion based on the specific development needs.

For these reasons, we no longer believe that it is helpful or necessary to maintain an “edition” naming convention and to adopt entirely new editions of certification criteria to encapsulate updates over time. Instead, we believe that there should be a single set of certification criteria, which would be updated in an incremental fashion in closer alignment to standards development cycles and regular health IT development timelines. We therefore propose to rename all certification criteria within the Program simply as “ONC Certification Criteria for Health IT.” We believe maintaining a single set of “ONC Certification Criteria for Health IT” would create more stability for users of health IT and Program partners, such as CMS, as well as make it easier for developers of certified health IT to maintain their product certificates over time. In addition, we believe that this approach will have the benefit of reducing administrative burden for health IT developers participating in the Program. Previously, duplicative references to separate certification criteria under multiple year-themed editions created administrative burden on developers, as they had the effect of requiring health IT developers to seek an updated certificate attributed to the “new” duplicated certification criterion even in circumstances when the certification criterion remained substantively unchanged. Under this proposal, unchanged certification criteria would no longer be duplicated as separate criteria under multiple editions. Accordingly, we propose to rename § 170.315 as the “ONC Certification Criteria for Health IT” and replace all references throughout 45 CFR part 170 to the “2015 Edition” with this new description (this would impact the wording, though not the substance or effect, of §§ 170.102, 170.405, 170.406, 170.523, 170.524, and 170.550, as shown in proposed revised regulation text, below). We welcome public comment on this proposal.

In the 2014 Edition Final Rule we defined the terms “new,” “revised,” and “unchanged” to both describe the differences between the 2014 Edition certification criteria and the 2011 Edition certification criteria, as well as establish what certification criteria in the 2014 Edition were eligible for gap certification

(see 77 FR 54171, 54202,

and 54248). Beginning with the 2015 Edition, “Complete EHR” certifications were no longer issued (see also 79 FR 54443 through 54445) and, as part of our effort to make the Program more open and accessible to other healthcare and practice settings, we also defined these terms for the purpose of a gap certification analysis as follows:

Gap certification

means the certification of a previously certified Health IT Module(s) to:

(1) All applicable new and/or revised certification criteria adopted by the Secretary at subpart C of this

part based on test results issued by a NVLAP-accredited testing laboratory under the ONC Health IT Certification Program or an ONC-ATL; and

(2) All other applicable certification criteria adopted by the Secretary at subpart C of this part based on the test results used to previously certify the Complete EHR or Health IT Module(s) under the ONC Health IT Certification Program (§ 170.502).

• “New” certification criteria are those that as a whole only include capabilities never referenced in previously adopted certification criteria editions and to which a Health IT Module presented for certification to the 2015 Edition could have never previously been certified.

• “Revised” certification criteria are those that include the capabilities referenced in a previously adopted edition of certification criteria as well as changed or additional new capabilities; and to which a Health IT Module presented for certification to the 2015 Edition could not have been previously certified to all of the included capabilities.

• “Unchanged” certification criteria are those that include the same capabilities as compared to prior certification criteria of adopted editions; and to which a Health IT Module presented for certification to the 2015 Edition could have been previously certified to all of the included capabilities (80 FR 62608).

We propose that these same concepts as applied to the certification criteria would continue to be used by the Program in the absence of a year named “edition.” However, for clarity, we now propose to define “revised certification criterion (or criteria)” in § 170.102 to mean a certification criterion that meets at least one of the following: (1) has added or changed the functions or capabilities described in the existing criterion in 45 CFR 170 part C; (2) has an added or changed standard or implementation specification referenced in the existing criterion in 45 CFR part 170 subpart B; or (3) is specified through notice and comment rulemaking as an iterative or replacement version of an existing criterion in 45 CFR part 170 subpart C.

By way of example, proposed provisions (1) and (2) were met in § 170.315(b)(3) in the ONC Cures Act Final Rule (85 FR 25683) because we modified this criterion to include new functions or capabilities in § 170.315(b)(3)(ii)(A)(

) through (

) that did not exist in § 170.315(b)(3). Also, in § 170.315(b)(3), in the ONC Cures Act Final Rule we added cross-references to the NCPDP SCRIPT standard version 2017071 in § 170.315(b)(3)(ii)(A) and (b)(3)(ii)(B), which did not exist in § 170.315(b)(3). An example of proposed provision (3) can be found in the ONC Cures Act Final Rule in § 170.315(b)(6) “Data export” being replaced by § 170.315(b)(10) “Electronic Health Information export” (85 FR 25699). If finalized as proposed there would not be an “edition” to differentiate between such revisions to existing criteria; instead, such criteria would be considered “revised” until a subsequent rulemaking where no further revision to the criterion renders them “unchanged.”

We would continue to use these terms when: communicating proposals for future criteria, such as revising a criterion that will maintain its place in the CFR or establishing a new criterion that is an iterative or replacement criterion in the Program; establishing scenarios for when gap certification is an option for developers of certified health IT; and when setting expiration dates or applicable timelines related to standards and certification criteria. Through the development of educational resources, such as fact sheets

and resource guides,

these designations will help users and the public understand to which versions of standards and certification criteria a Health IT Module may be certified when multiple versions of standards or certification criteria are available under the Program. In this proposed rule, we propose applicability or implementation timelines for both our certification criteria and the standards adopted in 45 CFR part 170 by establishing the dates by which an existing version of a criterion is no longer applicable and by establishing a date by when a new or revised certification criterion or standard version is adopted. For example, if finalized as proposed, a user and the public would know that a Health IT Module certified to “revised” § 170.315(b)(1) would support USCDI v3 (§ 170.213(b)) after January 1, 2025, because we state that USCDI v1 expires on January 1, 2025, in § 170.213(a).

See 2015 Edition Cures Update Fact Sheet:

https://www.healthit.gov/sites/default/files/page/2022-03/Cures-Update-Fact-Sheet.pdf

See API Resource Guide:

https://onc-healthit.github.io/api-resource-guide/

We propose the following revised standards and implementation specifications: § 170.205(a); §§ 170.207(a), (c), (d), (e), (f), (m), (n), (o), (p), (r), and (s); § 170.210(g); § 170.213; § 170.215(b), and § 170.215(c). We propose new standards and implementation specifications in § 170.205(t) and § 170.205(o). Table 1 below includes the proposed new and revised certification criteria described in this rule.

Table 1—List of Proposed Health IT Certification Criteria

New Certification Criterion

§ 170.315(d)(14)

Privacy and security—Patient Requested Restrictions.

Revised Certification Criteria

§ 170.315(a)(5)

Clinical—Patient demographics and observations (currently Demographics).

§ 170.315(a)(9)

Clinical—Clinical decision support (CDS) (to be recategorized as “Care Coordination § 170.315(b)(11)”).

§ 170.315(b)(1)

Care Coordination—Transitions of care.

§ 170.315(b)(2)

Care Coordination—Clinical information reconciliation and incorporation.

§ 170.315(e)(1)

Patient Engagement—View, download, and transmit to 3rd party.

§ 170.315(f)(5)

Public Health—Transmission to public health agencies—electronic case reporting.

§ 170.315(g)(10)

Design and Performance—Standardized API for patient and population services.

Revised Certification Criteria (standards updates)

§ 170.315(a)(12)

Clinical—Family health history.

§ 170.315(b)(6)

Care Coordination—Data export.

§ 170.315(b)(9)

Care Coordination—Care plan.

§ 170.315(c)(4)

Clinical Quality Measures—Clinical quality measures—filter.

§ 170.315(f)(1)

Public Health—Transmission to immunization registries.

§ 170.315(f)(3)

Public Health—Transmission to public health agencies—reportable laboratory tests and values/results.

§ 170.315(f)(4)

Public Health—Transmission to cancer registries.

§ 170.315(g)(3)

Design and Performance—Safety-enhanced design.

§ 170.315(g)(6)

Design and Performance—Consolidated CDA creation performance.

§ 170.315(g)(9)

Design and Performance—Application access—all data request.

When we published the 2015 Edition Final Rule, ONC released educational resources to inform the public. Educational and communication resources included charts on the 2015 Edition certification criteria, reader-friendly fact sheets on specific topics like addressing health disparities and patient engagement, the Companion Certification Guides, and a new “2015 Edition Standards Hub” to help interested parties quickly crosswalk and identify standards referenced by 2015 Edition certification criteria. While our proposal may have the near-term effect of requiring ONC to revise existing communications materials, as well as conforming regulatory updates and updates to materials by other agencies such as CMS that reference the 2015 Edition, we believe the overall benefit of having a single ONC branded set of certification criteria outweighs the burdens that result administratively, as well as for developers of certified health IT and their customers, from rolling out a new “edition.” Moreover, starting with the ONC Cures Act Final Rule, we developed a new approach for conformance requirement changes within certification criteria that, when applied in conjunction with this proposed approach, can also reduce administrative and regulatory burden and help to ensure the updates to criteria are clearly defined to support both a transition period and a predictable development timeline aligned to the scope of the specific update. In the ONC Cures Act Final Rule, we did not create a new CFR section as we had done previously but instead updated the existing CFR section, § 170.315. The new approach was designed to make it clear for health IT developers, as well as ONC-Authorized Testing Labs (ONC-ATLs) and ONC-ACBs, how long certain capabilities and standards remain available for the purposes of certification. We also implemented new Maintenance of Certification requirements as a result of the Cures Act to give health IT developers specific deadlines relative to complying with updated technical requirements, while still allowing developers to continue supporting technology certified to the prior version of certification criteria or standards for use by their customers.

Building upon this approach, in this proposed rule, we also propose modifications to our approach for setting applicability or implementation timelines for both our certification criteria and the standards adopted in 45 CFR part 170. This approach includes establishing the dates by which an existing version of a certification criterion is no longer applicable because a new or revised version of that criterion is adopted. In addition, we have proposed to establish applicable timelines, including expiration dates, for the adoption of standards when a new or revised version of the standard is adopted for the same purpose. This proposed approach would support the ongoing establishment of clear timelines associated with the specific criterion or standard in alignment with the development and update cycle for that specific criterion or standard—again supporting an incremental and flexible approach.

In addition, we believe this approach would facilitate ease of reference for federal, state, local or tribal programs seeking to align their program requirements to the standards and implementation specifications available in certified health IT. These programs may not require use of the entirety of the Base EHR, or they may not even require the use of certified health IT, but they may still seek to align to a specific certification criterion or a specific standard where applicable to their program goals and consistent with their applicable authorities. Furthermore, as we move away from the use of editions to define updated timelines, we believe it is important to continue to provide clarity on existing Program requirements and to ensure that customers are provided with timely technology updates. We therefore propose to incorporate the applicable timelines and expiration dates for functional and standards updates within each individual criterion or standard. In section III.C.11 of this proposed rule, we propose to make explicit in the introductory text in § 170.315 that health IT developers voluntarily participating in the Program must update their certified Health IT Modules and provide that updated certified health IT to customers in accordance with the timelines defined for each criterion and standard if they intend to maintain certification of the Health IT Module. (For ease of reference and reading, we use “developer of certified health IT” in this proposed rule to reference developers who voluntarily participate in the Program). We believe this approach will also help to advance interoperability. Under this proposal, a developer of certified health IT would not be required to provide technology updates for certification criteria or standards to a user who declined such updates. However, we note that if such an update is not provided, and the Health IT Module was previously certified to a criterion or criteria that now make it subject to a “revised” criterion or criteria, the Health IT Module would no longer be certified under the Program, in the same manner that previously removed or expired “editions” are no longer certified under the Program.

We direct readers to section III.C.11 of this proposed rule for further discussion of the requirements for health IT developers voluntarily participating in the Program related to health IT certification updates.

In the ONC Cures Act Final Rule, we revised the Principles of Proper Conduct for ONC-ACBs and ONC-ATLs by revising the records retention policies to include the “life of the edition” (85 FR 25710 through 25713). Specifically, we clarified that the records retention provisions in §§ 170.523 and 170.524 included the “life of the edition” as well as three years after the retirement of an edition related to the certification of Complete EHRs and Health IT Modules. We explained that “[b]ecause the `life of the edition' begins with the codification of an edition of certification criteria in the CFR and ends on the effective date of the final rule that removes the applicable edition from the CFR, the start and end dates for the `life of the edition' are published in the

Federal Register

in the rulemaking actions that

finalize them. The period of three years beyond the `life of the edition' begins on the effective date of the final rule that removes the applicable edition from the CFR, thus the three-year period after removal from the CFR continues through three full calendar years following that date” (85 FR 25710). Because in this proposed rule we propose to maintain a single set of “ONC Certification Criteria for Health IT” and not an edition, we propose to revise § 170.523 and § 170.524. We propose that the period of three years begins on the effective date of the final rule that removes the applicable ONC certification criterion or criteria for health IT from the CFR, thus the three-year period after removal from the CFR continues through three full calendar years following that date (in addition to the calendar year in which it was removed). We also retain the “Complete EHR” language in these sections because beginning with the 2015 Edition, Complete EHR certifications could no longer be issued. However, since the 2014 Edition was not removed from the CFR until the ONC Cures Act Final Rule, which became effective on June 30, 2020, records would need to be retained (including Complete EHRs) until June 30, 2023.

B. Standards and Implementation Specifications

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

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:

https://www.whitehouse.gov/wp-content/uploads/2020/07/revised_circular_a-119_as_of_1_22.pdf

• The United States Core Data for Interoperability (USCDI), October 2022 Errata, Version 3 (v3) standard. We propose to adopt USCDI v3 (October 2022 Errata) in § 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); and

• The standard we propose to adopt in § 170.207(f)(3) for race and ethnicity.

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 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.C.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/or 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 HL7® FHIR US Core Implementation Guide 5.0.1 proposed in this proposed rule (

see

section III.C.7.b), 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 preempt 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 V (“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.

C. New and Revised Standards and Certification Criteria

1. The United States Core Data for Interoperability Standard (USCDI) v3

a. Background

The United States Core Data for Interoperability (USCDI) is a standardized set of health data classes and constituent data elements for nationwide, interoperable health information exchange.

In the ONC Cures Act Final Rule, ONC established USCDI as a standard to replace the Common Clinical Data Set (CCDS) in several ONC certification criteria (85 FR 25670). ONC adopted USCDI Version 1 (USCDI v1) in § 170.213 and incorporated it by reference in § 170.299.

In an interim final rule with comment period published by ONC on November 4, 2020, “Information Blocking and the ONC Health IT Certification Program: Extension of Compliance Dates and Timeframes in Response to the COVID-19 Public Health Emergency,” ONC adopted and incorporated by reference the updated standard USCDI v1 (July 2020 Errata) (85 FR 70073).

https://www.healthit.gov/isa/united-states-core-data-interoperability-uscdi

https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-D/part-170#p-170.213

USCDI v1 established a baseline set of data that can be commonly exchanged across care settings for a wide range of uses and is a required part of certain certification criteria in the 2015 Edition Cures Update. These certification criteria include transitions of care; clinical information reconciliation and incorporation; view, download, and

transmit to 3rd party; transmission to public health agencies—electronic case reporting; consolidated CDA creation performance; application access—all data request, and standardized API for patient and population services (adopted in § 170.315(b)(1), (b)(2), (e)(1), (f)(5), (g)(6), (g)(9), and (g)(10) respectively). USCDI is also referenced by HHS programs and the healthcare community to align interoperability requirements and national priorities for health IT and healthcare standards broadly across industry initiatives. Additionally, at a minimum, entities that sign the Common Agreement are required to exchange all available data elements from USCDI v1.

USCDI is composed of data classes which aggregate data elements by common themes. Data elements are the granular level at which a piece of data is defined for exchange within the USCDI standard. For example, “Laboratory” is a data class, and within that data class there is “Values/Results” which is a data element. For the overall structure and organization of USCDI, including data classes and data elements in USCDI v1, please see the discussion in the ONC Cures Act Final Rule (85 FR 25669—25670) as well as

www.healthIT.gov/USCDI

Trusted Exchange Framework and Common Agreement Qualified Health Information Network (QHIN) Technical Framework (QTF). Version 1.0. January 2022.

https://rce.sequoiaproject.org/wp-content/uploads/2022/01/QTF_0122.pdf

ONC stated in the ONC Cures Act Final Rule that we intended to utilize a predictable, transparent, and collaborative process to expand USCDI, including providing the public with the opportunity to comment on USCDI's expansion (85 FR 25670). We also noted that health IT developers would be able to use the Standards Version Advancement Process (SVAP) to voluntarily implement and use a newer, National Coordinator-approved version of USCDI in the future without waiting for ONC to propose and adopt via rulemaking an updated version of the USCDI (85 FR 25669). ONC, therefore, established a process for expanding USCDI based on public input and submissions of new data elements and classes.

To enable these submissions, ONC created the ONC New Data Element and Class (ONDEC) submission system, which provides the public with the opportunity to submit new data elements for consideration for inclusion in future versions of USCDI.

ONC accepts submissions for new USCDI data elements in ONDEC on an ongoing basis, with a September cutoff each year for submissions to be considered for the next version of USCDI. ONC evaluates these submissions and assigns “levels” based on technical maturity, implementation feasibility, overall breadth of impact on potential users, and any known challenges to use of these data. Level 2 elements are those ONC deems the most mature and ready for consideration for future versions, followed by Level 1 elements as less mature, and Comment Level elements as the least mature. After the submission cutoff, ONC selects from Level 2 elements. ONC then publishes a draft of the next version of USCDI and accepts public feedback on the draft.

This feedback informs the version of USCDI released in July each year. In this way, the standard can continue to evolve in an incremental and predictable manner, even though ONC might not propose to adopt each new version in the Code of Federal Regulations.

https://www.healthit.gov/buzz-blog/interoperability/uscdi-onc-new-data-element-and-class-submission-system-now-available

https://www.healthit.gov/isa/ONDEC

https://www.healthit.gov/buzz-blog/interoperability/opportunity-trifecta-isa-svap-and-draft-uscdi-version-3-feedback-period-now-open

ONC has received several hundred submissions through ONDEC recommending new and updated data classes and data elements during each annual update cycle. In July 2021, ONC published USCDI Version 2 (USCDI v2),

and this version was later added to the SVAP Approved Standards for 2022.

SVAP allows health IT developers to voluntarily update their products to USCDI v2 without waiting for rulemaking to update the version of USCDI listed in the regulations (85 FR 25669). At the time of release of USCDI v2, ONC also announced additional criteria on which new and existing submissions would be evaluated and selected for USCDI v3 and future versions. These criteria included the ability of the data elements to promote health equity, address the needs of underserved communities, and enable public health data interoperability.

In January 2022, ONC released Draft USCDI v3 and provided for a three-month public feedback period.

After reviewing and incorporating public feedback, ONC finalized and released USCDI v3 in July 2022.

https://www.healthit.gov/isa/united-states-core-data-interoperability-uscdi#uscdi-v2

https://www.healthit.gov/sites/default/files/page/2022-06/SVAP_Approved_Standards_2022.pdf

https://www.healthit.gov/buzz-blog/interoperability/opportunity-trifecta-isa-svap-and-draft-uscdi-version-3-feedback-period-now-open

https://www.healthit.gov/sites/default/files/page/2022-01/Standards_Bulletin_2022-1.pdf

We propose to update the USCDI standard in § 170.213 by adding the newly released USCDI v3 and by establishing a January 1, 2025, expiration date for USCDI v1 (July 2020 Errata) for purposes of the Program. We propose to add USCDI v3 in § 170.213(b) and incorporate it by reference in § 170.299. Specifically, USCDI v3 in this proposed rule refers to the USCDI v3 (October 2022 Errata). We propose to codify the existing reference to USCDI v1 (July 2020 Errata) in § 170.213(a). We propose that as of January 1, 2025, any Health IT Modules seeking certification for criteria referencing § 170.213 would need to be capable of exchanging the data classes and data elements that comprise USCDI v3.

b. Certification Criteria That Reference USCDI

The USCDI standard is currently cross-referenced, via cross-reference to § 170.213, in certain certification criteria. A Health IT Module could currently be certified to any of these criteria by ensuring that it complies with either the USCDI v1 or USCDI v2 standards, since USCDI v2 is approved for SVAP. Should we adopt our proposal to add the USCDI v3 in § 170.213, Health IT Modules certified to these criteria that cross-reference § 170.213 could also be certified by meeting the USCDI v3 standard. Through December 31, 2024, we propose that a Health IT Module certified to criteria that cross-reference § 170.213 may be certified by complying with (1) USCDI v1; (2) USCDI v2 under SVAP; and (3) USCDI v3. We propose to allow only USCDI v3 after this date for the criteria that cross-reference § 170.213. The criteria cross-referencing to USCDI via cross-reference to § 170.213 are as follows:

• “Care coordination—Transitions of care—Create” (§ 170.315(b)(1)(iii)(A)(

));

• “Care coordination—Clinical information reconciliation and incorporation—Reconciliation” (§ 170.315(b)(2)(iii)(D)(

) through (

));

• “Patient engagement—View, download, and transmit to 3rd party—View” (§ 170.315(e)(1)(i)(A)(

));

• “Design and performance—Consolidated CDA creation performance” (§ 170.315(g)(6)(i)(A));

• “Design and performance—Application access—all data request—Functional requirements” (§ 170.315(g)(9)(i)(A)(

)); and

• “Design and performance—Standardized API for patient and population services—Data response” (§ 170.315(g)(10)(i)(A) and (B)).

We note that § 170.315(f)(5) also currently references § 170.213. However, as discussed later in this preamble, we propose to rely on specific

IGs for this criterion, rather than reference § 170.213. As such, we do not propose to require Health IT Modules certified to § 170.315(f)(5)(iii) to certify using either USCDI v1 or USCDI v3 through December 31, 2024, and only USCDI v3 after December 31, 2024.

As noted previously, a developer of certified health IT would not be required to provide technology updates for certified criteria or standards to a user who declined such updates. However, we note that if such an update is not provided, even if the version of the Health IT Module in use still operates, that version would no longer be considered certified. This means that it may no longer meet the requirements of HHS programs requiring the use of certified health IT.

We propose to add introductory text to § 170.213 noting that the Secretary adopts the following standards as the standards available for the purpose of representing electronic health information, and we also propose to include the date the adoption of the standard in § 170.213(a) expires. Consistent with our proposals in sections III.A and III.C.11, we propose this expiration date to be January 1, 2025. Health IT developers with Health IT Modules certified to certification criteria that reference § 170.213 would have to update such certified health IT to USCDI v3 and provide it to customers by December 31, 2024. Further, we propose that Health IT Modules certified to the above-listed certification criteria would need to update their Health IT Modules to accommodate USCDI v3 data elements using the FHIR US Core Implementation Guide Version 5.0.1 in § 170.215(b)(1)(ii) and the HL7 CDA® R2 IG: C-CDA Templates for Clinical Notes R2.1 Companion Guide, Release 3 in § 170.205(a)(6). If the FHIR US Core Implementation Guide and the HL7 CDA® R2 IG: C-CDA Templates for Clinical Notes R2.1 Companion Guide are updated before the date of publication of the final rule, it is our intent to consider adopting the updated versions that support USCDI v3.

We clarify that under this proposal, for the time period up to and including December 31, 2024, USCDI v1 would remain applicable as the minimum version of the USCDI required for certification criteria that reference § 170.213. This means that upon the effective date of a rule finalizing this proposal, for the identified certification criteria that reference § 170.213, the following would apply as available versions of USCDI for certification and compliance:

• USCDI v1 (2020 Errata) for the time period up to and including December 31, 2024 (the adoption of the standard expires on January 1, 2025),

• USCDI v3.

We refer to the term “expires” in standards throughout this proposed rule, and it would mean that the Secretary no longer recognizes the standard in the Code of Federal Regulations and its use for purposes of the Program is no longer available.

USCDI v2 would remain available via SVAP for developers of certified health IT who want to voluntarily update their Health IT Modules, or for developers of certified health IT who want to certify to applicable criteria in addition to or instead of USCDI v1 up to and including December 31, 2024.

Additionally, because we finalized in the ONC Cures Act Final Rule that the Common Clinical Data Set (CCDS) would no longer be applicable for certified Health IT Modules 24 months after the publication date of the ONC Cures Act Final Rule (85 FR 25671), and then extended that date to December 31, 2022 in the interim final rule 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 70073), we propose to remove references to CCDS in the following sections of 45 CFR 170.315: § 170.315(b)(1)(iii)(A)(

); (e)(1)(i)(A)(

); (g)(6)(i)(B); and (g)(9)(i)(A)(

). In each of those sections, we have instead proposed to include a reference to USCDI. Because § 170.315(b)(6)(ii)(A), which also references CCDS, is still available for the period before December 31, 2023, we are not removing the reference to CCDS in that section.

c. USCDI Standard—Data Classes and Elements Added Since USCDI v1

ONC proposes to update the USCDI standard in § 170.213 by proposing a January 1, 2025 expiration date for USCDI v1 (July 2020 Errata) and by adding the newly released USCDI v3 (October 2022 Errata). ONC proposes to incorporate USCDI v3 by reference in § 170.299. USCDI v3 includes all data elements defined in USCDI v1 and USCDI v2, and includes additional data elements added in USCDI v3.

Adopting USCDI v3 would provide more comprehensive health data for providers and patients accessing and exchanging electronic health information. USCDI v3 includes Sexual Orientation, Gender Identity, Functional Status, Disability Status, Mental/Cognitive Status, and Social Determinants of Health data elements including: SDOH Assessment, SDOH Goals, SDOH Interventions, and SDOH Problems/Health Concerns. Access, exchange, and use of these data elements can support more informed care for patients. These data elements are described in more detail below.

While the SVAP process provides an opportunity for health IT developers to voluntarily update their certified products to newer versions of USCDI, setting a new USCDI v3 floor for all certified health IT that includes Health IT Modules certified to certification criteria that reference § 170.213 would enable a more consistent adoption of an expanded baseline set of data, realizing the benefits described above. We propose to add USCDI v3 to § 170.213 in addition to USCDI v1 (July 2020 Errata). Because USCDI v1 (July 2020 Errata) may be used for the time period up to and including December 31, 2024, we propose to amend § 170.213 to include paragraph (a) that will note that the USCDI v1 (July 2020 Errata) standard will expire on January 1, 2025, and paragraph (b) that will note the addition of USCDI v3.

Below, we describe the data classes and data elements in USCDI v3 that are not included in USCDI v1. We also describe any data classes or data elements that were changed through the USCDI update processes when comparing USCDI v3 to USCDI v1. For the overall structure and organization of the USCDI standard, including USCDI v3, we urge the public to consult

www.healthIT.gov/USCDI

. All the following data classes and data elements were added to USCDI based on submissions through the ONDEC system and ONC's determination that they represented significant additions to core interoperable health data and met the prioritization criteria previously set forth in this process. We propose each of these data classes or data elements to be included in the USCDI standard in § 170.213 and to be incorporated by reference in § 170.299 as part of our proposal to adopt USCDI v3.

i. Social Determinants of Health (SDOH)

SDOH

are the conditions in which people live, learn, work, and play, and these conditions affect a wide range of health and quality-of-life risks and outcomes.

In the 2015 Edition, ONC adopted a certification criterion to enable users of Health IT Modules(s) that certified to that criterion with the functionality to electronically capture,

modify, and access SDOH data elements—that is information that identifies common SDOH conditions in a standardized manner—in § 170.315(a)(15) social, psychological, and behavioral data (80 FR 62631). These functionalities were intended to support users with the ability to use technology to comply with applicable existing legal requirements or organizational policies that may require such data collection and broader, existing industry interests and efforts to collect and use this data to inform clinical decision-making and improve patient care by looking at the whole patient, including leveraging other types of care such as home and community-based services.

ONC supports the use of technology to improve the standardized capture of a set of health data classes to support the healthcare industry's need to electronically capture the underlying data they need or want to collect for healthcare.

See SDOH Toolkit for more information,

https://www.healthit.gov/sites/default/files/2023-02/Social%20Determinants%20of%20Health%20Information%20Exchange%20Toolkit%202023_508.pdf

https://www.healthit.gov/topic/health-it-health-care-settings/social-determinants-health

https://www.federalregister.gov/d/2015-25597/p-406

SDOH data are often categorized into domains based on the type of circumstances they are intended to represent, such as food or housing insecurity. However, many of these circumstances overlap, and there are continuing efforts aiming to capture additional areas of focus such as broadband access or environmental risk factors.

USCDI v3 includes four SDOH data elements that represent specific aspects of SDOH data related to the use or purpose of the SDOH data rather than based on the domain. In this way, the data elements can emphasize the use case aspect of the data and expand to additional domains over time. These data elements are new for USCDI v3 as compared to USCDI v1. However, because each of these aspects is closely related to data elements that exist in USCDI data classes, these new data elements were organized into the applicable existing data classes.

Existing USCDI Data Class

New Data Element

Assessment and Plan of Treatment

SDOH Assessment—related to the conditions in which people live, learn, work and play.

Goals

SDOH Goals—related to expected outcomes for interventions addressing the conditions in which people live, learn, work and play.

Procedures

SDOH Interventions—related to addressing the conditions in which people live, learn, work and play.

Problems

SDOH Problems/Health Concerns—related to the conditions experienced by a person that impact how they live, learn, work and play. (e.g., transportation insecurity, food insecurity).

ii. Care Team Member

In USCDI v1, the Care Team Member data class had one data element to capture all aspects about a care team member. ONC received submissions recommending the addition of more granular data elements that provide greater detail around a patient's health care provider and other members of the care team. USCDI v3 includes five Care Team Member data elements: Name, Identifier, Role, Location, and Telecom.

iii. Clinical Notes

For the data element Discharge Summary Note in the Clinical Notes data class, we specified additional requirements in USCDI v3 including admission and discharge dates and locations, discharge instructions, and reason(s) for hospitalization, which are also required elements in the Transitions of Care certification criterion (§ 170.315(b)(1)).

iv. Clinical Tests

USCDI v3 includes a data class for Clinical Tests, which has two data elements, Clinical Test and Clinical Test Result/Report. This is a new data class as compared to USCDI v1. These elements will enable the capture and exchange of non-imaging and non-laboratory tests. Some examples include electrocardiogram (ECG), visual acuity exam, macular (ophthalmic) exam, or graded exercise testing (GXT). These tests are routinely performed on patients and result in structured or unstructured (narrative) findings that facilitate the diagnosis and management of a patient's condition(s).

v. Diagnostics Imaging

USCDI v3 includes the Diagnostic Imaging data class and its two elements: Diagnostic Imaging Test and Diagnostic Imaging Report. This is a new data class as compared to USCDI v1. These data elements added a critical missing capability of health IT to capture and exchange structured and unstructured imaging test and report data for a patient.

vi. Encounter Information

USCDI v3 includes the Encounter Information data class, which includes five data elements: Encounter Type, Encounter Diagnosis, Encounter Time, Encounter Location, and Encounter Disposition. This is a new data class as compared to USCDI v1.

vii. Health Insurance Information

USCDI v3 includes the Health Insurance Information data class, which provides an opportunity for health IT to capture and exchange key elements of healthcare insurance coverage. This information can be useful for patient matching and record linkage, coverage determination, prior authorization, price transparency, claims and reimbursement efficiencies, and identifying disparities related to insurance coverage. This is a new data class as compared to USCDI v1. This data class includes seven data elements: Coverage Status, Coverage Type, Relationship to Subscriber, Member Identifier, Subscriber Identifier, Group Identifier, and Payer Identifier.

viii. Health Status Assessments

USCDI v3 includes a data class called Health Status Assessments, which contains four new data elements: Disability Status, Mental/Cognitive Status, Functional Status, and Pregnancy Status. This is a new data class as compared to USCDI v1. In USCDI v3, the Health Status Assessments data class also includes two data elements that have been recategorized, Health Concerns and Smoking Status, which were previously part of different data classes in USCDI. The Health Status Assessments data class provides a broader context for these data elements. The ability to capture and exchange data that represent the assessment performed and the assessment component results helps health care providers address inequities by being able to readily identify and address a patient's conditions characterized with these data.

ix. Laboratory

USCDI v3 includes Specimen Type and Result Status data elements, which

have been added to the USCDI Laboratory data class to address public health reporting priorities. These new data elements are key components of laboratory reports and can help with ongoing public health needs, including Covid-19, MPox and future public health emergencies, to ultimately improve patient care.

x. Medications

USCDI v3 includes Dose, Dose Units of Measure, Indication, and Fill Status data elements, which have been added to the USCDI Medications data class in response to public feedback and because these data elements are necessary for certain CMS reporting programs and are also critical to certain ONC certification criteria (including the electronic prescribing certification criterion at § 170.315(b)(3)).

xi. Patient Demographics/Information

Based on submissions and comments during the USCDI update processes described above, ONC changed or added data elements in the Patient Demographics/Information data class.

USCDI v3 includes data elements Sexual Orientation and Gender Identity, which have been added to the USCDI Patient Demographics/Information data class. Previously, ONC adopted standards for Sexual Orientation in the demographics criterion in § 170.315(a)(5)(i)(D) and for Gender Identity in the demographics criterion in § 170.315(a)(5)(i)(E). These criteria include requirements to code Sexual Orientation and Gender Identity according to the adopted SNOMED CT® codes and HL7 Version 3 Standard, Value Sets for AdministrativeGender and NullFlavor as referenced § 170.207(o)(1) and § 170.207(o)(2), respectively.

These codes reflect an attempt to exchange data regarding Sexual Orientation and Gender Identity in a consistent manner. Public feedback has, however, indicated that the required SNOMED CT® codes do not appropriately and accurately capture all applicable sexual orientations or gender identities. We also understand that the existing standards reference specific codes from the HL7 Version 3 Standard, Value Set for NullFlavor, which are primarily used by health IT developers to indicate when there is not information available to represent Sexual Orientation or Gender Identity. The HL7 Gender Harmony Project has developed an informative document

that includes codes for Gender Identity such as “Nonbinary” that are not present in adopted values sets (§ 170.207(o)(2)). Additionally, representatives of the healthcare community and patient advocates have indicated a desire to expand the codes for Sexual Orientation and Gender Identity in the future to reflect the need to be more inclusive and to aid in identifying and addressing health disparities.

https://confluence.hl7.org/download/attachments/81017270/HL7_GENDER_R1_INFORM_2021AUG.pdf?version=1&modificationDate=1639425849713&api=v2

Accordingly, we propose to remove the requirement to use specific codes for representing Sexual Orientation and Gender Identity and have removed the codes as applicable vocabulary standards from USCDI v3. Rather, to continue to promote interoperability while also providing health care providers with flexibility to better support clinical care, certified health IT with Health IT Modules certified to criteria that reference § 170.213 would be required to be capable of representing Sexual Orientation and Gender Identity in SNOMED CT® when such information is exchanged as part of USCDI. We believe that it is best to let the health IT community develop the list of appropriate values for Sexual Orientation and Gender Identity, whether through implementation specifications or developing additional codes in SNOMED CT®.

We received strong support from commenters in response to our request during the Draft USCDI v3 public feedback period that the USCDI term Sex (Assigned at Birth) was too limiting for the industry. In subsequent exploration and analysis, we learned that this element is represented in different ways in a number of jurisdictions, so the meaning is unclear.

There was support to align the term in USCDI with the term Recorded Sex or Gender as part of the Gender Harmony Project. We understand that the term Recorded Sex or Gender is a more expansive term that defines the value of patient's sex recorded in administrative or legal documents, and indeed Sex (Assigned at Birth) could be considered as a specific type or recorded value with the identifier being assigned at birth. However, in order to be least disruptive to the industry, while at the same time, acknowledging the shortcomings of our current term, we have recharacterized the USCDI data element Sex (Assigned at Birth) to Sex. We note that this is presently a change in the name of the element and will have no immediate impact on health IT developers of certified health IT, which will continue to exchange the value of patient's sex they have been historically exchanging using USCDI. However, we anticipate this change to support future enhancements to improve precision in the meaning through work done by health IT developers of certified health IT.

USCDI v3 does not require the use of certain specific codes for representing Sex. As discussed previously, we propose to remove the requirement in § 170.315(a)(5)(i)(C) and § 170.315(b)(1)(iii)(G)(

) to code Sex according to the adopted value sets of HL7 Version 3 Value Sets for AdministrativeGender and NullFlavor as referenced in the value sets in § 170.207(n)(1). We propose instead to permit coding according to either the adopted value sets of HL7 Version 3 Value Sets for AdministrativeGender and NullFlavor as referenced in the value sets in § 170.207(n)(1) until December 31, 2025, or in accordance with the standard in proposed § 170.207(n)(2). These codes reflect an attempt to exchange Sex in a consistent manner. Our analysis has, however, indicated that the value sets do not appropriately and accurately capture all applicable values for Sex. Interested parties have indicated a desire to expand the codes for Sex in the future to be more inclusive and to aid in efforts to address health disparities. Accordingly, we no longer require the use of specific code sets for representing Sex and have removed the codes from USCDI v3. Rather, to continue to promote interoperability while also granting providers with flexibility to better support clinical care, certified health IT with Health IT Modules certified to criteria that reference § 170.213 would be required to be capable of representing Sex in SNOMED CT when such information is exchanged as part of USCDI. We have similarly proposed to adopt the same changes for relevant certification criteria that reference these standards (

see

sections III.C.8 and III.C.9).

Finally, we have taken note of the substantial effort in this area to develop a clinically meaningful way for identifying a patient's sex from observable information (

e.g.,

Clinical Observation, Radiology report, Laboratory report, genetic testing data) that may be suitable for clinical care, including the development of a new data element Sex for Clinical Use, which we may consider including in future standards adoption. We welcome public comment on this concept and approach. In addition, as noted in our proposals to the Patient Demographics and Observations certification criterion in § 170.315(a)(5), we have proposed to adopt the same changes for relevant certification criteria that reference these

standards (

see

sections III.C.8 and III.C.9).

ONC also sought feedback on the value of adoption of an applicable vocabulary standard for patient addresses.

USCDI v1 required Current Address and Previous Address as discrete data elements, but there are no existing standards available for healthcare use cases. Through a collaboration between ONC and the standards development community, a new standard, the Unified Specification for Address in Health Care (US@),

emerged and was released in 2022. After receiving broad support from the public, ONC has incorporated the Project US@Technical Specification version 1 as the applicable standard for Current Address and Previous Address in USCDI v3.

https://www.healthit.gov/sites/default/files/page/2022-01/Standards_Bulletin_2022-1.pdf#page=5.

https://oncprojectracking.healthit.gov/wiki/pages/viewpage.action?pageId=180486153.

USCDI v3 includes six data elements added to the prior USCDI Patient Demographics/Information data class: Related Person's Name, Related Person's Relationship, Date of Death, Occupation, Occupation Industry, and Tribal Affiliation. Related Person's Name and Related Person's Relationship enable linkages between maternal and child records as well as identifying and linking other related persons, such as custodians and guardians. Date of Death supports patient matching, adverse event, public health, and vital records reporting. Occupation and Occupation Industry data elements were added to support public health, and to capture military service. Finally, Tribal Affiliation is captured by the Indian Health Service (IHS), an agency within the Department of Health and Human Services, to aid in the determination of eligibility for IHS services, care-coordination with non-tribal medical facilities, and identification of disparities in healthcare in and across American Indian and Alaska Native populations.

xii. Problems

As discussed in sub-section i of this section, USCDI v3 includes the SDOH Problems/Health Concerns data element added to the prior USCDI Problems data class. In addition, USCDI v3 includes Date of Diagnosis and Date of Resolution data elements added to the prior USCDI Problems data class to include timing elements for recorded and maintained problem lists within electronic health records.

xiii. Procedures

USCDI v3 includes the Reason for Referral data element added to the prior USCDI Procedures data class. This data element is already part of the Program requirements for the transitions of care certification criterion (§ 170.315(b)(1)(iii)(E)) in the ambulatory setting and is broadly implemented in health IT. As discussed in sub-section i of this section, the USCDI v3 also includes the SDOH Interventions data element added to the prior USCDI Procedures data class.

xiv. Updated Versions of Vocabulary Standard Code Sets

In the 2015 Edition Final Rule, we established a policy for minimum standards code sets that update frequently throughout a calendar year at 80 FR 62612, and we have listed several standards as minimum standards code sets in 45 CFR part 170 subpart B. As with all adopted minimum standards code sets, health IT can be certified to newer versions of the adopted baseline version minimum standards code sets for purposes of certification, unless the Secretary specifically prohibits the use of a newer version (see § 170.555 and 77 FR 54268). In USCDI v3, we included the most recent versions of the minimum standards code sets.

2. C-CDA Companion Guide Updates

We propose to adopt the HL7® CDA® R2 Implementation Guide: C-CDA Templates for Clinical Notes STU Companion Guide, Release 3—US Realm in § 170.205(a)(6) (“C-CDA Companion Guide R3”). The C-CDA Companion Guide R3 provides supplemental guidance and additional technical clarification for specifying data in the C-CDA Release 2.1 for USCDI v2. However, it is our understanding that HL7 is working on updating the C-CDA R2.1 Companion Guide (Release 4) for USCDI v3. If the C-CDA Companion Guide Release 4 (R4) is published before the date of publication of the final rule, it is our intention to consider adopting the updated Companion Guide R4 that provides guidance and clarifications for specifying data in USCDI v3 since we propose to adopt USCDI v3 as the baseline in this proposed rule.

As mentioned above, HL7® has been updating the C-CDA Companion Guide to accommodate the new data classes and elements in each USCDI version. To allow developers to voluntarily update to USCDI v2, ONC included the C-CDA Companion Guide R3 in the SVAP Approved Standards List for 2022. ONC released the SVAP Approved Standards List for 2022 in June 2022. We anticipate that the C-CDA Companion Guide R4 would support updates included in proposed USCDI v3. We note that the adoption of the C-CDA Companion Guide R4 would align with our goal to increase the use of consistently implemented standards among health IT developers and improve interoperability. We propose to adopt the C-CDA Companion Guide R3 as a standard in § 170.205(a)(6) and incorporate it by reference in § 170.299. As stated above, if the C-CDA Companion Guide R4 is available at the time of publication of the final rule, we intend to consider adopting the C-CDA Companion Guide R4, which would support the updates included in proposed USCDI v3.

Consistent with our proposals in sections III.A and III.C.11, we propose to revise § 170.205(a)(5) to add that the adoption of the standard in § 170.205(a)(5) expires on January 1, 2025. Developers of certified health IT with Health IT Modules certified to criteria that reference § 170.205(a)(5) would have to update those Health IT Modules to § 170.205(a)(6) and provide them to customers by January 1, 2025. We clarify that under this proposal, for the time period up to and including December 31, 2024, HL7 CDA® R2 Implementation Guide: C-CDA Templates for Clinical Notes R2.1 C

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

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