# 21st Century Cures Act: Interoperability, Information Blocking, and the ONC Health IT Certification Program > Briefs, arguments, decisions, and more. URL: https://www.frixlaw.com/law-library/documents/fr%3A2019-02224 ## Record - **Collection:** Federal Register - **Document type:** Proposed Rule - **Published:** March 4, 2019 - **Citation:** 84 FR 7424 ## Text DEPARTMENT OF HEALTH AND HUMAN SERVICES Office of the Secretary 45 CFR Parts 170 and 171 RIN 0955-AA01 21st Century Cures Act: Interoperability, Information Blocking, and the ONC Health IT Certification Program 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 certain provisions of the 21st Century Cures Act, including conditions and maintenance of certification requirements for health information technology (health IT) developers under the ONC Health IT Certification Program (Program), the voluntary certification of health IT for use by pediatric health care providers, and reasonable and necessary activities that do not constitute information blocking. The implementation of these provisions would advance interoperability and support the access, exchange, and use of electronic health information. The proposed rule would also modify the 2015 Edition health IT certification criteria and 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 May 3, 2019. ADDRESSES: You may submit comments, identified by RIN 0955-AA01, 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: 21st Century Cures Act: Interoperability, Information Blocking, and the ONC Health IT Certification Program 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: 21st Century Cures Act: Interoperability, Information Blocking, and the ONC Health IT Certification Program 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: 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 and Clarifications 1. Deregulatory Actions for Previous Rulemakings 2. Updates to the 2015 Edition Certification Criteria a. Adoption of the United States Core Data for Interoperability as a Standard b. Electronic Prescribing c. Clinical Quality Measures—Report d. Electronic Health Information Export e. Application Programming Interfaces f. Privacy and Security Transparency Attestations g. Data Segmentation for Privacy and Consent Management 3. Modifications to the ONC Health IT Certification Program 4. Health IT for the Care Continuum 5. Conditions and Maintenance of Certification 6. Information Blocking 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 1. Standards, Implementation Specifications, and Certification Criteria Rules 2. ONC Health IT Certification Program Rules III. Deregulatory Actions for Previous Rulemakings A. Background 1. History of Burden Reduction and Regulatory Flexibility 2. Executive Orders 13771 and 13777 B. Proposed Deregulatory Actions 1. Removal of Randomized Surveillance Requirements 2. Removal of the 2014 Edition From the Code of Federal Regulations 3. Removal of the ONC-Approved Accreditor From the Program 4. Removal of Certain 2015 Edition Certification Criteria and Standards a. 2015 Edition Base EHR Definition Certification Criteria b. Drug-Formulary and Preferred Drug Lists c. Patient-Specific Education Resources d. Common Clinical Data Set Summary Record—Create; and Common Clinical Data Set Summary Record—Receive e. Secure Messaging 5. Removal of Certain ONC Health IT Certification Program Requirements a. Limitations Disclosures b. Transparency and Mandatory Disclosures Requirements 6. Recognition of Food and Drug Administration Processes a. FDA Software Pre-Certification Pilot Program b. Development of Similar Independent Program Processes—Request for Information IV. Updates to the 2015 Edition Certification Criteria A. 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 B. Revised and New 2015 Edition Criteria 1. The United States Core Data for Interoperability Standard (USCDI) a. USCDI 2015 Edition Certification Criteria b. USCDI Standard—Data Classes Included c. USCDI Standard—Relationship to Content Exchange Standards and Implementation Specifications d. Clinical Notes C-CDA Implementation Specification 2. Electronic Prescribing Criterion 3. Clinical Quality Measures—Report Criterion 4. Electronic Health Information Export Criterion a. Patient Access b. Transitions Between Health IT Systems c. Scope of EHI d. Export Format e. Initial Step to Persistent Access to All of a Patient's EHI f. Timeframes g. Replaces the 2015 Edition “Data Export” Criterion in the 2015 Edition Base EHR Definition 5. Standardized API for Patient and Population Services Criterion 6. Privacy and Security Transparency Attestations Criteria a. Background b. Encrypt Authentication Credentials c. Multi-factor Authentication 7. Data Segmentation for Privacy and Consent Management Criteria a. Implementation With the Consolidated CDA Release 2.1 b. Implementation With FHIR Standard C. Unchanged 2015 Edition Criteria—Promoting Interoperability Programs Reference Alignment V. Modifications to the ONC Health IT Certification Program A. Corrections 1. Auditable Events and Tamper Resistance 2. Amendments 3. View, Download, and Transmit to 3rd Party 4. Integrating Revised and New Certification Criteria Into the 2015 Edition Privacy and Security Certification Framework B. Principles of Proper Conduct for ONC-ACBs 1. Records Retention 2. Conformance Methods for Certification Criteria 3. ONC-ACBs to Accept Test Results From Any ONC-ATL in Good Standing 4. Mandatory Disclosures and Certifications C. Principles of Proper Conduct for ONC-ATLs—Records Retention VI. Health IT for the Care Continuum A. Health IT for Pediatric Setting 1. Background and Stakeholder Convening 2. Recommendations for the Voluntary Certification of Health IT for Use in Pediatric Care a. 2015 Edition Certification Criteria b. New or Revised Certification Criteria in This Proposed Rule B. Health IT and Opioid Use Disorder Prevention and Treatment—Request for Information 1. 2015 Edition Certification Criteria 2. Revised or New 2015 Edition Certification Criteria in This Proposed Rule 3. Emerging Standards and Innovations 4. Additional Comment Areas VII. Conditions and Maintenance of Certification A. Implementation B. Provisions 1. Information Blocking 2. Assurances a. Full Compliance and Unrestricted Implementation of Certification Criteria Capabilities b. Certification to the “Electronic Health Information Export” Criterion c. Records and Information Retention d. Trusted Exchange Framework and the Common Agreement—Request for Information 3. Communications a. Background and Purpose b. Condition of Certification Requirements c. Maintenance of Certification Requirements 4. Application Programming Interfaces a. Statutory Interpretation and API Policy Principles b. Key Terms c. Proposed API Standards, Implementation Specifications, and Certification Criterion d. Condition of Certification Requirements e. Maintenance of Certification Requirements f. 2015 Edition Base EHR Definition 5. Real World Testing 6. Attestations 7. EHR Reporting Criteria Submission C. Compliance D. Enforcement 1. ONC Direct Review of the Conditions and Maintenance of Certification Requirements 2. Review and Enforcement Only by ONC 3. Review Processes a. Initiating Review and Health IT Developer Notice b. Relationship with ONC-ACBs and ONC-ATLs c. Records Access d. Corrective Action e. Certification Ban and Termination f. Appeal g. Suspension h. Proposed Termination 4. Public Listing of Certification Ban and Terminations 5. Effect on Existing Program Requirements and Processes 6. Concurrent Enforcement by the Office of Inspector General 7. Applicability of Conditions and Maintenance of Certification Requirements for Self-Developers VIII. Information Blocking A. Statutory Basis B. Legislative Background and Policy Considerations 1. Purpose of the Information Blocking Provision 2. Policy Considerations and Approach to the Information Blocking Provisions C. Relevant Statutory Terms and Provisions 1. “Required by Law” 2. Health Care Providers, Health IT Developers, Exchanges, and Networks a. Health Care Providers b. Health IT Developers of Certified Health IT c. Networks and Exchanges 3. Electronic Health Information 4. Interests Promoted by the Information Blocking Provision a. Access, Exchange, and Use of EHI b. Interoperability Elements 5. Practices That May Implicate the Information Blocking Provision a. Prevention, Material Discouragement, and Other Interference b. Likelihood of Interference c. Examples of Practices Likely To Interfere With Access, Exchange, or Use of EHI 6. Applicability of Exceptions a. Reasonable and Necessary Activities b. Treatment of Different Types of Actors c. Establishing That Activities and Practices Meet the Conditions of an Exception D. Proposed Exceptions to the Information Blocking Provision 1. Preventing Harm 2. Promoting the Privacy of EHI 3. Promoting the Security of EHI 4. Recovering Costs Reasonably Incurred 5. Responding to Requests That Are Infeasible 6. Licensing of Interoperability Elements on Reasonable and Non-discriminatory Terms 7. Maintaining and Improving Health IT Performance E. Additional Exceptions—Request for Information 1. Exception for Complying With Common Agreement for Trusted Exchange 2. New Exceptions F. Complaint Process G. Disincentives for Health Care Providers—Request for Information IX. Registries Request for Information X. Patient Matching Request for Information XI. Incorporation by Reference XII. Response to Comments XIII. Collection of Information Requirements A. ONC-ACBs B. Health IT Developers XIV. Regulatory Impact Analysis A. Statement of Need B. Alternatives Considered C. Overall Impact 1. Executive Orders 12866 and 13563—Regulatory Planning and Review Analysis 2. Executive Order 13771—Reducing Regulation and Controlling Regulatory Costs a. Costs and Benefits b. Accounting Statement and Table 3. Regulatory Flexibility Act 4. Executive Order 13132—Federalism 5. Unfunded Mandates Reform Act of 1995 6. Executive Order 13771 Reducing Regulation and Controlling Regulatory Costs Regulation Text I. Executive Summary A. Purpose of Regulatory Action ONC is responsible for the implementation of key provisions in Title IV of the 21st Century Cures Act (Cures Act) that are designed to advance interoperability; support the access, exchange, and use of electronic health information; and address occurrences of information blocking. This proposed rule would implement 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. In addition, the proposed rule would implement parts of section 4006(a) of the Cures Act to support patient access to their electronic health information (EHI), such as making a patient's EHI more electronically accessible through the adoption of standards and certification criteria and the implementation of information blocking policies that support patient electronic access to their health information at no cost. Additionally, the proposed rule would modify the 2015 Edition health IT certification criteria and ONC Health IT Certification Program (Program) in other ways to advance interoperability, enhance health IT certification, and reduce burden and costs. In addition to fulfilling the Cures Act's requirements, the proposed rule would contribute to fulfilling Executive Order (E.O.) 13813. The President issued E.O. 13813 on October 12, 2017, to promote health care choice and competition across the United States. Section 1(c) of the E.O., in relevant part, states that government rules affecting the United States health care system should re-inject competition into the health care markets by lowering barriers to entry and preventing abuses of market power. Section 1(c) also states that government rules should improve access to and the quality of information that Americans need to make informed health care decisions. For example, as mentioned above, the proposed rule focuses on establishing Application Programming Interfaces (APIs) for several interoperability purposes, including patient access to their health information without special effort. The API approach also supports health care providers having the sole authority and autonomy to unilaterally permit connections to their health IT through certified API technology the health care providers have acquired. In addition, the proposed rule provides ONC's interpretation of the information blocking definition as established in the Cures Act and the application of the information blocking provision by identifying reasonable and necessary activities that would not constitute information blocking. Many of these activities focus on improving patient and health care provider access to electronic health information and promoting competition. B. Summary of Major Provisions and Clarifications 1. Deregulatory Actions for Previous Rulemakings Since the inception of the Program, we have aimed to implement and administer the Program in the least burdensome manner that supports our policy goals. Throughout the years, we have worked to improve the Program with a focus on ways to reduce burden, offer flexibility to both developers and providers, and support innovation. This approach has been consistent with the principles of Executive Order 13563 on Improving Regulation and Regulatory Review (February 2, 2011), which instructs agencies to “determine whether any [agency] regulations should be modified, streamlined, expanded, or repealed so as to make the agency's regulatory program more effective or less burdensome in achieving the regulatory objectives.” To that end, we have historically, where feasible and appropriate, taken measures to reduce burden within the Program and make the Program more effective, flexible, and streamlined. ONC has reviewed and evaluated existing regulations to identify ways to administratively reduce burden and implement deregulatory actions through guidance. In this proposed rule, we also propose potential new deregulatory actions that will reduce burden for health IT developers, providers, and other stakeholders. We propose six deregulatory actions in section III.B: (1) Removal of a threshold requirement related to randomized surveillance which allows ONC-Authorized Certification Bodies (ONC-ACBs) more flexibility to identify the right approach for surveillance actions, (2) removal of the 2014 Edition from the Code of Federal Regulations (CFR), (3) removal of the ONC-Approved Accreditor (ONC-AA) from the Program, (4) removal of certain 2015 Edition certification criteria, (5) removal of certain Program requirements, and (6) recognition of relevant Food and Drug Administration certification processes with a request for comment on the potential development of new processes for the Program. 2. Updates to the 2015 Edition Certification Criteria This rule proposes to update the 2015 Edition by not only proposing criteria for removal, but by proposing to revise and add new certification criteria that would establish the capabilities and related standards and implementation specifications for the certification of health IT. a. Adoption of the United States Core Data for Interoperability (USCDI) as a Standard As part of ONC's continued efforts to assure the availability of a minimum baseline of data classes that could be commonly available for interoperable exchange, we adopted the 2015 Edition “Common Clinical Data Set” (CCDS) definition and used the CCDS shorthand in several certification criteria. However, the CCDS definition also began to be colloquially used for many different purposes. As the CCDS definition's relevance grew outside of its regulatory context, it became a symbolic and practical limit to the industry's collective interests to go beyond the CCDS data for access, exchange, and use. In addition, as we move further towards value-based care, the need for the inclusion of additional data classes that go beyond clinical data is necessary. In order to advance interoperability, we propose to remove the CCDS definition and its references from the 2015 Edition and replace it with the “United States Core Data for Interoperability.” We propose to adopt the USCDI as a standard, naming USCDI Version 1 (USCDI v1) in § 170.213 and incorporating it by reference in § 170.299. The USCDI standard, if adopted, would establish a set of data classes and constituent data elements that would be required to be exchanged in support of interoperability nationwide. To achieve the goals set forth in the Cures Act, ONC intends to establish and follow a predictable, transparent, and collaborative process to expand the USCDI, including providing stakeholders with the opportunity to comment on the USCDI's expansion. Once the USCDI is adopted in regulation naming USCDI v1, health IT developers would be allowed to take advantage of a flexibility under the Maintenance of Certification real world testing requirements, which we refer to as the “Standards Version Advancement Process” (described in section VII.B.5 of this proposed rule). The Standards Version Advancement Process would permit health IT developers to voluntarily implement and use a new version of an adopted standard, such as the USCDI, so long as the newer version was approved by the National Coordinator through the Standards Version Advancement Process for use in certification. b. Electronic Prescribing We propose to update the electronic prescribing (e-Rx) SCRIPT standard in 45 CFR 170.205(b) to NCPDP SCRIPT 2017071, which would result in a new e-Rx standard eventually becoming the baseline for certification. We also propose to adopt a new certification criterion in § 170.315(b)(11) for e-Rx to reflect these updated proposals. ONC and CMS have historically maintained complementary policies of maintaining aligned e-Rx and medical history (MH) standards to ensure that the current standard for certification to the electronic prescribing criterion permits use of the current Part D e-Rx and MH standards. This proposal is made to ensure such alignment as CMS recently finalized its Part D standards to NCPDP SCRIPT 2017071 for e-RX and MH, effective January 1, 2020 (83 FR 16440). In addition to continuing to reference the current transactions included in § 170.315(b)(3), in keeping with CMS' final rule, we also propose to require all of the NCPDP SCRIPT 2017071 standard transactions CMS adopted at 42 CFR 423.160(b)(2)(iv). c. Clinical Quality Measures—Report We propose to remove the HL7 Quality Reporting Document Architecture (QRDA) standard requirements from the 2015 Edition “CQMs—report” criterion in § 170.315(c)(3) and, in their place, require Health IT Modules to support the CMS QRDA Implementation Guide (IGs). 1 This would reduce the burden for health IT developers by only having to support one form of the QRDA standard rather than two forms ( i.e., the HL7 and CMS forms). 1 https://ecqi.healthit.gov/qrda-quality-reporting-document-architecture. d. Electronic Health Information Export We propose a new 2015 Edition certification criterion for “electronic health information (EHI) export” in § 170.315(b)(10), which would replace the 2015 Edition “data export” certification criterion (§ 170.315(b)(6)) and become part of the 2015 Edition Base EHR definition. The proposed criterion supports situations in which we believe that all EHI produced and electronically managed by a developer's health IT should be made readily available for export as a standard capability of certified health IT. Specifically, this criterion would: (1) Enable the export of EHI for a single patient upon a valid request from that patient or a user on the patient's behalf, and (2) support the export of EHI when a health care provider chooses to transition or migrate information to another health IT system. This criterion would also require that the export include the data format, made publicly available, to facilitate the receiving health IT system's interpretation and use of the EHI to the extent reasonably practicable using the developer's existing technology. This criterion provides developers with the ability to create innovative export capabilities according to their systems and data practices. We do not propose that the export must be executed according to any particular standard, but propose to require that the export must be accompanied by the data format, including its structure and syntax, to facilitate interpretation of the EHI therein. Overall, this new criterion is intended to provide patients and health IT users, including providers, a means to efficiently export the entire electronic health record for a single patient or all patients in a computable, electronic format. e. Application Programming Interfaces (APIs) We propose to adopt a new API criterion in § 170.315(g)(10), which would replace the “application access—data category request” certification criterion (§ 170.315(g)(8)) and become part of the 2015 Edition Base EHR definition. This new “standardized API for patient and population services” certification criterion would require the use of Health Level 7 (HL7®) Fast Healthcare Interoperability Resources (FHIR®) standards 2 and several implementation specifications. The new criterion would focus on supporting two types of API-enabled services: (1) Services for which a single patient's data is the focus and (2) services for which multiple patients' data are the focus. 2 https://www.hl7.org/fhir/overview.html. f. Privacy and Security Transparency Attestations We propose to adopt two new privacy and security transparency attestation certification criteria, which would identify whether certified health IT supports encrypting authentication credentials and/or multi-factor authentication. In order to be issued a certification, we propose to require that a Health IT Module developer attest to whether the Health IT Module encrypts authentication credentials and whether the Health IT Module supports multi-factor authentication. These criteria are not expected to place additional burden on health IT developers since they do not require net new development or implementation to take place in order to be met. However, certification to these proposed criteria would provide increased transparency and potentially motivate health IT developers to encrypt authentication credentials and support multi- factor authentication, which could help prevent exposure to unauthorized persons/entities. g. Data Segmentation for Privacy and Consent Management In the 2015 Edition, we adopted two “data segmentation for privacy” (DS4P) certification criteria, one for creating a summary record according to the DS4P standard and one for receiving a summary record according to the DS4P standard. Certification to the 2015 Edition DS4P criteria focus on data segmentation only at the document level. As noted in the 2015 Edition final rule (80 FR 62646)—and to our knowledge still an accurate assessment—certification to these criteria is currently not required to meet the Certified EHR Technology definition (CEHRT) or required by any other HHS program. Since the 2015 Edition final rule, the health care industry has engaged in additional field testing and implementation of the DS4P standard. In addition, stakeholders shared with ONC—through public forums, listening sessions, and correspondence—that focusing certification on segmentation to only the document level does not permit providers the flexibility to address more granular segmentation needs. Therefore, we propose to remove the current 2015 Edition DS4P criteria. We propose to replace these two criteria with three new 2015 Edition “DS4P” certification criteria (two for C-CDA and one for a FHIR-based API) that would support a more granular approach to privacy tagging data consent management for health information exchange supported by either the C-CDA- or FHIR-based exchange standards. 3. Modifications to the ONC Health IT Certification Program We propose to make corrections to the 2015 Edition privacy and security certification framework (80 FR 62705) and relevant regulatory provisions. These corrections have already been incorporated in the relevant Certification Companion Guides (CCGs). We propose new and revised principles of proper conduct (PoPC) for ONC-Authorized Certification Bodies (ONC-ACBs). We propose to clarify that the records retention provision includes the “life of the edition” as well as after the retirement of an edition related to the certification of Complete EHRs and Health IT Modules. We also propose to revise the PoPC in § 170.523(h) to clarify the basis for certification, including to permit a certification decision to be based on an evaluation conducted by the ONC-ACB for Health IT Modules' compliance with certification criteria by use of conformity methods approved by the National Coordinator for Health Information Technology (National Coordinator). We also propose to update § 170.523(h) to require ONC-ACBs to accept test results from any ONC-ATL that is in good standing under the Program and is compliant with its ISO 17025 accreditation requirements. We believe these proposed new and revised PoPCs would provide necessary clarifications for ONC-ACBs and would promote stability among the ONC-ACBs. We also propose to update § 170.523(k) to broaden the requirements beyond just the Medicare and Medicaid Electronic Health Record (EHR) Incentive Programs (now renamed the Promoting Interoperability Programs) and provide other necessary clarifications. We propose to revise a PoPC for ONC-ATLs. We propose to clarify that the records retention provision includes the “life of the edition” as well as after the retirement of an edition related to the certification of Complete EHRs and Health IT Modules. 4. Health IT for the Care Continuum Section 4001(b) of the Cures Act includes two provisions related to supporting health IT across the care continuum. The first instructs the National Coordinator to encourage, keep or recognize through existing authorities, the voluntary certification of health IT for use in medical specialties and sites of service where more technological advancement or integration is needed. The second outlines a provision related to the voluntary certification of health IT for use by pediatric health providers to support the health care of children. These provisions align closely with ONC's core purpose to promote interoperability to support care coordination, patient engagement, and health care quality improvement initiatives. Advancing health IT that promotes and supports patient care when and where it is needed continues to be a primary goal of the Program. This means health IT should support patient populations, specialized care, transitions of care, and practice settings across the care continuum. ONC has explored how we might work with the health IT industry and with specialty organizations to collaboratively develop and promote health IT that supports medical specialties and sites of service. Over time, ONC has taken steps to make the Program modular, more open and accessible to different types of health IT, and able to advance functionality that is generally applicable to a variety of care and practice settings. Specific to the provisions in the Cures Act to support providers of health care for children, we considered a wide range of factors. These include: The evolution of health IT across the care continuum, the costs and benefits associated with health IT, the potential regulatory burden and compliance timelines, and the need to help advance health IT that benefits multiple medical specialties and sites of service involved in the care of children. In consideration of these factors, and to advance implementation of Sections 4001(b) of the Cures Act specific to pediatric care, we held a listening session where stakeholders could share their clinical knowledge and technical expertise in pediatric care and pediatric sites of service. Through the information learned at this listening session and our analysis of the health IT landscape for pediatric settings, we have identified existing 2015 Edition criteria, as well as new and revised 2015 Edition criteria proposed in this rule, that we believe could benefit providers of pediatric care and pediatric settings. In this proposed rule, we seek comment on our analysis and the correlated certification criteria that we believe would support the health care of children. We also recognize the significance of the opioid epidemic confronting our nation and the importance of helping to support the health IT needs of health care providers committed to preventing inappropriate access to prescription opioids and to providing safe, appropriate treatment. We believe health IT offers promising strategies to help assist medical specialties and sites of services impacted by the opioid epidemic. Therefore, we request public comment on how our existing Program requirements and the proposals in this rulemaking may support use cases related to Opioid Use Disorder (OUD) prevention and treatment and if there are additional areas that ONC should consider for effective implementation of health IT to help address OUD prevention and treatment. 5. Conditions and Maintenance of Certification We propose to establish certain Conditions and Maintenance of Certification requirements for health IT developers based on the conditions and maintenance of certification requirements outlined in section 4002 of the Cures Act. We propose an approach whereby the Conditions and Maintenance of Certification express both initial requirements for health IT developers and their certified Health IT Module(s) as well as ongoing requirements that must be met by both health IT developers and their certified Health IT Module(s) under the Program. In this regard, we propose to implement the Cures Act Conditions of Certification with further specificity as it applies to the Program and propose to implement any accompanying Maintenance of Certification requirements as standalone requirements to ensure that not only are the Conditions of Certification met, but that they are continually being met through the Maintenance of Certification requirements. For ease of reference and to distinguish from other conditions, we propose to capitalize “Conditions of Certification” and “Maintenance of Certification” when referring to Conditions and Maintenance of Certification requirements established under the Cures Act. Information Blocking The Cures Act requires that a health IT developer, as a Condition and Maintenance of Certification under the Program, not take any action that constitutes information blocking as defined in section 3022(a) of the Public Health Service Act (PHSA). We propose to establish this information blocking Condition of Certification in § 170.401. The Condition of Certification would prohibit any health IT developer under the Program from taking any action that constitutes information blocking as defined by section 3022(a) of the PHSA and proposed in § 171.103. Assurances Section 3001(c)(5)(D)(ii) of the Cures Act requires that a health IT developer, as a Condition of Certification under the Program, provide assurances to the Secretary that, unless for legitimate purposes specified by the Secretary, the developer will not take any action that constitutes information blocking as defined in section 3022(a) of the PHSA, or any other action that may inhibit the appropriate exchange, access, and use of EHI. We propose to implement this provision through several Conditions of Certification and accompanying Maintenance requirements, which are set forth in proposed § 170.402. We also propose to establish more specific Conditions and Maintenance of Certification requirements to provide assurances that a health IT developer does not take any other action that may inhibit the appropriate exchange, access, and use of EHI. These proposed requirements serve to provide further clarity under the Program as to how health IT developers can provide such broad assurances with more specific actions. Communications As a Condition and Maintenance of Certification under the Program, the Cures Act requires that health IT developers do not prohibit or restrict communications about certain aspects of the performance of health IT and the developers' related business practices. We propose that developers will be permitted to impose certain kinds of limited prohibitions and restrictions that we believe strike a reasonable balance between the need to promote open communication about health IT and related developer business practices and the need to protect the legitimate interests of health IT developers and other entities. However, certain narrowly-defined types of communications—such as communications required by law, made to a government agency, or made to a defined category of safety organization—would receive “unqualified protection,” meaning that developers would be absolutely prohibited from imposing any prohibitions or restrictions on such protected communications. We propose that to maintain compliance with this Condition of Certification, a health IT developer must not impose or enforce any contractual requirement or legal right that contravenes this Condition of Certification. Furthermore, we propose that if a health IT developer has contracts/agreements in existence that contravene this condition, the developer must notify all affected customers or other persons or entities that the prohibition or restriction will not be enforced by the health IT developer. Going forward, health IT developers would be required to amend their contracts/agreements to remove or make void the provisions that contravene this Condition of Certification within a reasonable period of time, but not later than two years from the effective date of a subsequent final rule for this proposed rule. Application Programming Interfaces (APIs) The Cures Act's API Condition of Certification includes several key phrases (including, for example, “without special effort”) and requirements for health IT developers that indicate the Cures Act's focus on the technical requirements as well as the actions and practices of health IT developers in implementing the certified API. In section VII.B.4 of the preamble, we outline our proposals to implement the Cures Act's API Condition of Certification. These proposals include new standards, new implementation specifications, a new certification criterion, as well as detailed Conditions and Maintenance of Certification requirements. Real World Testing The Cures Act adds a new Condition and Maintenance of Certification requirement that health IT developers successfully test the real world use of the technology for interoperability in the type of setting in which such technology would be marketed. In this proposed rule, we outline what successful “real world testing” means for the purpose of this Condition of Certification, as well as proposed Maintenance requirements—including standards updates for widespread and continued interoperability. We propose to limit the applicability of this Condition of Certification to health IT developers with Health IT Modules certified to one or more 2015 Edition certification criteria focused on interoperability and data exchange specified in section VII.B.5. We propose Maintenance of Certification requirements that would require health IT developers to submit publicly available annual real world testing plans as well as annual real world testing results for certified health IT products focused on interoperability. We also propose a Maintenance of Certification flexibility we have named the Standards Version Advancement Process, under which health IT developers with health IT certified to the criteria specified for interoperability and data exchange would have the option to update their health IT to a more advanced version(s) of the standard(s) or implementation specification(s) included in the criteria once such versions are approved by the National Coordinator through the Standards Version Advancement Process for use in health IT certified under the Program. Similarly, we propose that health IT developers presenting new health IT for certification to one of the criteria specified in Section VII.B.5 would have the option to certify to a National Coordinator-approved more advanced version of the adopted standards or implementation specifications included in the criteria. We propose that health IT developers voluntarily opting to avail themselves of the Standards Version Advancement Process must address their planned and actual timelines for implementation and rollout of standards updates in their annual real world testing plans and real world testing results submissions. We also propose that health IT developers of products with existing certifications who plan to avail themselves of the Standards Version Advancement Process flexibility notify both their ONC-ACB and their affected customers of their intention and plans to update their certified health IT and its anticipated impact on their existing certified health IT and customers, specifically including but not limited to whether, and if so for how long, the health IT developer intends to continue to support the certificate for the health IT certified to the prior version of the standard. We propose a new PoPC for ONC-ACBs that would require ONC-ACBs to review and confirm that applicable health IT developers submit real world testing plans and real world results in accordance with our proposals. Once completeness is confirmed, ONC-ACBs would upload the plans and results via hyperlinks to the Certified Health IT Product List (CHPL). We propose to revise the PoPC in § 170.523(m) to require ONC-ACBs to collect, no less than quarterly, all updates successfully made to standards in certified health IT pursuant to the developers having voluntarily opted to avail themselves of the Standards Version Advancement Process flexibility under the real world testing Condition of Certification. We propose in § 170.523(t), a new PoPC for ONC-ACBs requiring them to ensure that developers seeking to take advantage of the Standards Version Advancement Process flexibility in § 170.405(b)(5) comply with the applicable requirements. Attestations The Cures Act requires that a health IT developer, as a Condition and Maintenance of Certification under the Program, provide to the Secretary an attestation to all the Conditions of Certification specified in the Cures Act, except for the “EHR reporting criteria submission” Condition of Certification. We propose to implement the Cures Act “attestations” Condition of Certification in § 170.406. Health IT developers would attest twice a year to compliance with the Conditions and Maintenance of Certification requirements (except for the EHR reporting criteria requirement, which would be metrics reporting requirements separately implemented through a future rulemaking). The 6-month attestation period we propose in § 170.406(b)(2) would properly balance the need to support appropriate enforcement with the attestation burden placed on health IT developers. In this regard, the proposed rule includes provisions to make the process as simple and efficient for health IT developers as possible ( e.g., 14-day grace period, web-based form submissions, and attestation alert reminders). We propose that attestations would be submitted to ONC-ACBs on behalf of ONC and the Secretary. We propose a new PoPC in § 170.523(q) that an ONC-ACB must review and submit the health IT developers' attestations to ONC. ONC would then make the attestations publicly available through the CHPL. EHR Reporting Criteria Submission The Cures Act specifies that health IT developers be required, as a Condition and Maintenance of Certification under the Program, to submit reporting criteria on certified health IT in accordance with the EHR reporting program established under section 3009A of the PHSA, as added by the Cures Act. We have not yet established an EHR reporting program. Once ONC establishes such program, we will undertake rulemaking to propose and implement the associated Condition and Maintenance of Certification requirement(s) for health IT developers. Enforcement Section 4002 of the Cures Act adds Program requirements aimed at addressing health IT developer actions and business practices through the Conditions and Maintenance of Certification requirements, which expands the current focus of the Program requirements beyond the certified health IT itself. Equally important, section 4002 also provides that the Secretary of HHS may encourage compliance with the Conditions and Maintenance of Certification requirements and take action to discourage noncompliance. We, therefore, propose a general enforcement approach to encourage consistent compliance with the requirements. The proposed rule outlines a corrective action process for ONC to review potential or known instances where a Condition or Maintenance of Certification requirement has not been or is not being met by a health IT developer under the Program. We propose, with minor modifications, to utilize the processes previously established for ONC direct review of certified health IT and codified in §§ 170.580 and 170.581 for the enforcement of the Conditions and Maintenance of Certification requirements. Where noncompliance is identified, our first priority would be to work with the health IT developer to remedy the matter through a corrective action process. However, we propose that, under certain circumstances, ONC may ban a health IT developer from the Program or terminate the certification of one or more of its Health IT Modules. 6. Information Blocking Section 4004 of the Cures Act added section 3022 of the PHSA (42 U.S.C. 300jj-52, “the information blocking provision”), which defines conduct by health care providers, and health IT developers of certified health IT, exchanges, and networks that constitutes information blocking. Section 3022(a)(1) of the PHSA defines information blocking in broad terms, while section 3022(a)(3) authorizes and charges the Secretary to identify reasonable and necessary activities that do not constitute information blocking (section 3022(a)(3) of the PHSA). We identify several reasonable and necessary activities as exceptions to the information blocking definition, each of which we propose would not constitute information blocking for purposes of section 3022(a)(1) of the PHSA. The exceptions would extend to certain activities that interfere with the access, exchange, or use of EHI but that may be reasonable and necessary if certain conditions are met. In developing the proposed exceptions, we were guided by three overarching policy considerations. First, the exceptions would be limited to certain activities that clearly advance the aims of the information blocking provision; promoting public confidence in health IT infrastructure by supporting the privacy and security of EHI, and protecting patient safety; and promoting competition and innovation in health IT and its use to provide health care services to consumers. Second, each exception is intended to address a significant risk that regulated individuals and entities ( i.e., health care providers, health IT developers of certified health IT, health information networks, and health information exchanges) will not engage in these reasonable and necessary activities because of potential uncertainty regarding whether they would be considered information blocking. Third, and last, each exception is intended to be tailored, through appropriate conditions, so that it is limited to the reasonable and necessary activities that it is designed to exempt. The seven proposed exceptions are set forth in section VIII.D below. The first three exceptions, set forth in VIII.D.1-D.3 address activities that are reasonable and necessary to promote public confidence in the use of health IT and the exchange of EHI. These exceptions are intended to protect patient safety; promote the privacy of EHI; and promote the security of EHI. The next three exceptions, set forth in VIII.D.4-D.6, address activities that are reasonable and necessary to promote competition and consumer welfare. These exceptions would allow for the recovery of costs reasonably incurred; excuse an actor from responding to requests that are infeasible; and permit the licensing of interoperability elements on reasonable and non- discriminatory terms. The last exception, set forth in VIII.D.7, addresses activities that are reasonable and necessary to promote the performance of health IT. This proposed exception recognizes that actors may make health IT temporarily unavailable for maintenance or improvements that benefit the overall performance and usability of health IT. To qualify for any of these exceptions, we propose that an individual or entity would, for each relevant practice and at all relevant times, have to satisfy all of the applicable conditions of the exception. Additionally, we propose (in section VIII.C of this preamble) to define or interpret terms that are present in section 3022 of the PHSA (such as the types of individuals and entities covered by the information blocking provision). We also propose certain new terms and definitions that are necessary to implement the information blocking provisions. We propose to codify the proposed exceptions and other information blocking proposals in a new part of title 45 of the Code of Federal Regulations, part 171. C. Costs and Benefits Executive Orders 12866 on Regulatory Planning and Review (September 30, 1993) and 13563 on Improving Regulation and Regulatory Review (February 2, 2011) 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). A regulatory impact analysis (RIA) must be prepared for major rules with economically significant effects ($100 million or more in any one year). OMB has determined that this proposed rule is an economically 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 health IT developers, health care providers, patients, ONC-ACBs, ONC-ATLs, and the federal government ( i.e., ONC), and have broken those costs and benefits out into the following categories: (1) Deregulatory actions (no associated costs); (2) updates to the updates to the 2015 Edition health IT certification criteria; (3) Conditions and Maintenance of Certification for a health IT developer; (4) oversight for the Conditions and Maintenance of Certification; and (5) information blocking. We note that we have rounded all estimates to the nearest dollar and all estimates are expressed in 2016 dollars as it is the most recent data available to address all cost and benefit estimates consistently. We also note that we did not have adequate data to quantify some of the costs and benefits within this RIA. In those situations, we have described the qualitative costs and benefits of our proposals; however, such qualitative costs and benefits have not been accounted for in the monetary cost and benefit totals below. 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, on average, range from $365 million to $919 million with an average annual cost of $642 million. We estimate that the total perpetual cost for this proposed rule (starting in year two), based on the cost estimates outlined above, would, on average, range from $228 million to $452 million with an average annual cost of $340 million. We estimate the total annual benefit for this proposed rule would range from $3.08 billion to $9.15 billion with an average annual benefit of $6.1 billion. We estimate the total annual net benefit for this proposed rule for the first year after it is finalized (including one-time costs), based on the cost and benefit estimates outlined above, would range from $2.7 billion to $8.2 billion with an average net benefit of $5.5 billion. We estimate the total perpetual annual net benefit for this proposed rule (starting in year two), based on the cost-benefit estimates outlined above, would range from $2.9 billion to $8.7 billion with an average net benefit of $5.8 billion. II. Background A. Statutory Basis The Health Information Technology for Economic and Clinical Health (HITECH) Act, Title XIII of Division A and Title IV of Division B of the American Recovery and Reinvestment Act of 2009 (the Recovery Act) (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 health care quality, safety, and efficiency through the promotion of health IT and electronic health information (EHI) exchange. The 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 (Title XIII of Division A of Pub. L. 111-5) by modifying or adding certain provisions to the PHSA relating to health IT. 1. Standards, Implementation Specifications, and Certification Criteria The HITECH Act established two new federal advisory committees, the HIT Policy Committee (HITPC) and the HIT 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 3002 of the Cures Act amended the PHSA by replacing the HITPC and HITSC with one committee, the Health Information Technology Advisory Committee (HIT Advisory Committee or HITAC). Section 3002(a) establishes that the HITAC shall advise and recommend to the National Coordinator on different aspects of standards, implementation specifications, and certification criteria, relating to the implementation of a health IT infrastructure, nationally and locally, that advances the electronic access, exchange, and use of health information. Further described in section 3002(b)(1)(A) of the PHSA, this includes providing to the National Coordinator recommendations on a policy framework to advance interoperable health IT infrastructure, updating recommendations to the policy framework, and making new recommendations, as appropriate. Section 3002(b)(2)(A) identifies 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, the HITAC will develop a schedule for the assessment of policy recommendations for the Secretary to publish in the Federal Register . Section 3004 of the PHSA identifies 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 any grouping of such standards, implementation specifications, or certification criteria. The Secretary is required to publish all 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) Under the HITECH Act, 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. Specifically, 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 this subtitle ( i.e., certification criteria adopted by the Secretary 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. Overall, 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. The HITECH Act also indicates that the development of this conformance testing infrastructure may include a program to accredit independent, non-federal laboratories to perform testing. Section 3001(c)(5) of the PHSA was amended by the Cures Act, which instructs the National Coordinator to encourage, keep, or recognize, through existing authorities, the voluntary certification of health IT under the Program for use in medical specialties and sites of service for which no such technology is available or where more technological advancement or integration is needed. Section 3001(c)(5)(C)(iii) identifies that the Secretary, in consultation with relevant stakeholders, shall make recommendations for the voluntary certification of health IT for use by pediatric health providers to support the care of children, as well as adopt certification criteria under section 3004 to support the voluntary certification of health IT for use by pediatric health providers. The Cures Act further amended section 3001(c)(5) of the PHSA by adding section 3001(c)(5)(D), which provides the Secretary with the authority, through notice and comment rulemaking, to require conditions and maintenance of certification requirements for the Program. B. Regulatory History The Secretary issued an interim final rule with request for comments (75 FR 2014, Jan. 13, 2010), which adopted an initial set of standards, implementation specifications, and certification criteria. On March 10, 2010, ONC published a proposed rule (75 FR 11328) that proposed both a temporary and permanent certification program for the purposes of testing and certifying health IT. A final rule establishing the temporary certification program was published on June 24, 2010 (75 FR 36158) and a final rule establishing the permanent certification program was published on January 7, 2011 (76 FR 1262). ONC issued multiple rulemakings since these initial rulemaking to update standards, implementation specifications, and certification criteria and the certification program, a history of which can be found in the final rule titled, “2015 Edition Health Information (Health IT) Certification Criteria, 2015 Edition Base Electronic Health Record (EHR) Definition, and ONC Health IT Certification Program Modifications” (Oct. 16, 2015, 80 FR 62602) (“2015 Edition final rule”). 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 capabilities and specified the related standards and implementation specifications that CEHRT would need to include to, at a minimum, support the achievement of “meaningful use” by eligible clinicians, eligible hospitals, and critical access hospitals under the Medicare and Medicaid EHR Incentive Programs (EHR Incentive Programs) (now referred to as the Promoting Interoperability Programs) 3 when the 2015 Edition is required for use under these and other programs referencing the CEHRT definition. The 2015 Edition final rule also made changes to the Program. The final rule adopted a proposal to change the Program's name to the “ONC Health IT Certification Program” from the ONC HIT Certification Program, modified the Program to make it more accessible to other types of health IT beyond EHR technology and for health IT that supports care and practice settings beyond the ambulatory and inpatient settings, and adopted new and revised Principles of Proper Conduct (PoPC) for ONC-ACBs. 3 https://www.federalregister.gov/d/2018-16766/p-4. After issuing a proposed rule on March 2, 2016 (81 FR 11056), ONC published a final rule titled, “ONC Health IT Certification Program: Enhanced Oversight and Accountability” (81 FR 72404) (“EOA final rule”) on October 19, 2016. The final rule finalized modifications and new requirements under the Program, including provisions related to ONC's role in the Program. The final rule created a regulatory framework for ONC's direct review of health IT certified under the Program, including, when necessary, requiring the correction of non-conformities found in health IT certified under the Program and suspending and terminating certifications issued to Complete EHRs and Health IT Modules. The final rule also sets forth processes for ONC to authorize and oversee accredited testing laboratories under the Program. In addition, it includes provisions for expanded public availability of certified health IT surveillance results. III. Deregulatory Actions for Previous Rulemakings A. Background 1. History of Burden Reduction and Flexibility Since the inception of the ONC Health IT Certification Program (Program), we have aimed to implement and administer the Program in the least burdensome manner that supports our policy goals. Throughout the years, we have worked to improve the Program with a focus on ways to reduce burden, offer flexibility to both developers and providers, and support innovation. This approach has been consistent with the principles of Executive Order 13563 on Improving Regulation and Regulatory Review (February 2, 2011), which instructs agencies to “determine whether any [agency] regulations should be modified, streamlined, expanded, or repealed so as to make the agency's regulatory program more effective or less burdensome in achieving the regulatory objectives.” To that end, we have historically, where feasible and appropriate, taken measures to reduce burden within the Program and make the Program more effective, flexible, and streamlined. For example, in the 2014 Edition final rule (77 FR 54164), we revised the certified electronic health record technology (CEHRT) definition to provide flexibility and create regulatory efficiencies by narrowing required functionality to a core set of capabilities ( i.e., the Base EHR definition) plus the additional capabilities each eligible clinician, eligible hospital, and critical access hospital needed to successfully achieve the applicable objective and measures under the EHR Incentive Programs (now referred to as the Promoting Interoperability Programs). ONC has also supported more efficient testing and certification methods and reduced regulatory burden through the adoption of a gap certification policy. As explained in the 2014 Edition final rule (77 FR 54254) and the 2015 Edition final rule (80 FR 62681), where applicable, gap certification allows for the use of a previously certified health IT product's test results to certification criteria identified as unchanged. Developers have been able to use gap certification for the more efficient certification of their health IT when updating from the 2011 Edition to the 2014 Edition and from the 2014 Edition to the 2015 Edition. ONC introduced further means to reduce regulatory burden, increase regulatory flexibility, and promote innovation in the 2014 Edition Release 2 final rule (79 FR 54430). The 2014 Edition Release 2 final rule established a set of optional 2014 Edition certification criteria that provided flexibility and alternative certification pathways for health IT developers and providers based on their specific circumstances. The 2014 Edition Release 2 final rule also simplified the Program by discontinuing the use of the “Complete EHR” certification concept beginning with the 2015 Edition (79 FR 54443). In the 2015 Edition final rule, we did not “carry forward” certain 2014 Edition certification criteria into the 2015 Edition, such as the “image results,” “patient list creation,” and “electronic medication administration record” criteria. We determined that these criteria did not advance functionality or support interoperability (80 FR 62682-84). We also did not require all health IT to be certified to the “meaningful use measurement” certification criteria for “automated numerator recording” and “automated measure calculation” (80 FR 62605), which had been previously required for the 2014 Edition. Based on stakeholder feedback and Program administration observations, we also permitted testing efficiencies for the 2015 Edition “automated numerator recording” and “automated measure calculation” criteria by removing the live demonstration requirement of recording data and generating reports. Health IT developers may now self-test their Health IT Modules(s) and submit the resulting reports to the ONC- Authorized Testing Laboratory (ONC-ATL) to verify compliance with the criterion. 4 In order to further reduce burden for health IT developers, we adopted a simpler, straight-forward approach to privacy and security certification requirements, which clarified which requirements are applicable to each criterion within the regulatory functional areas (80 FR 62605). 2. Executive Orders 13771 and 13777 On January 30, 2017, the President issued Executive Order 13771 on Reducing Regulation and Controlling Regulatory Costs, which requires agencies to identify deregulatory actions. This order was followed by Executive Order 13777, titled “Enforcing the Regulatory Reform Agenda” (February 24, 2017). Executive Order 13777 provides further direction on implementing regulatory reform by identifying a process by which agencies must review and evaluate existing regulations and make recommendations for repeal or simplification. 4 https://www.healthit.gov/test-method/automated-numerator-recording and https://www.healthit.gov/test-method/automated-measure-calculation. In order to implement these regulatory reform initiatives and policies, over the past year ONC reviewed and evaluated existing regulations. During our review, we sought to identify ways to further reduce administrative burden, to implement deregulatory actions through guidance, and to propose potential new deregulatory actions in this proposed rule that will reduce burden for health IT developer, providers, and other stakeholders. On August 21, 2017, ONC issued Relied Upon Software Program Guidance. 5 Health IT developers are permitted to use “relied upon software” (76 FR 1276) to demonstrate compliance with certification criteria adopted at 45 CFR part 170, subpart C. Historically, in cases where a Health IT Module is paired with multiple “relied upon software” products for the same capability, health IT developers were required to demonstrate compliance for the same certification criterion with each of those “relied upon software” products in order for the products to be listed on the Certified Health IT Product List (CHPL). With the issued guidance, health IT developers may now demonstrate compliance with only one “relied upon software” product for a criterion/capability. Once the health IT developer demonstrates compliance with a minimum of one “relied upon software” product, the developer can have multiple, additional “relied upon software” products for the same criterion/capability listed on the CHPL ( https://chpl.healthit.gov/ ). This approach reduces burden for health IT developers, ONC-ATLs, and ONC-Authorized Certification Bodies (ONC-ACBs). 5 https://www.healthit.gov/sites/default/files/relieduponsoftwareguidance.pdf. On September 21, 2017, ONC reduced the overall burden for testing health IT to the 2015 Edition. 6 ONC reviewed the 2015 Edition test procedures, which identify minimum testing requirements ONC-ATLs must evaluate during testing. ONC changed 30 of the 2015 Edition test procedures to attestation only ( i.e., a “yes” self-declaration by the health IT developer that their product has capabilities conformant with those specified in the associated certification criterion/criteria). 7 This deregulatory action reduced burden and costs program-wide, while still maintaining the Program's high level of integrity and assurances. Health IT developers now have reduced preparation and testing costs for testing to these criteria. Specifically, the cost savings for health IT developers have been estimated between $8.34 and $9.26 million. ONC-ATLs also benefit by having more time and resources to focus on tool-based testing (for interoperability-oriented criteria) and being responsive to any retesting requirements that may arise from ONC-ACB surveillance activities. Furthermore, providers and users of certified health IT do not lose confidence in the Program because this burden reduction effort in no way alters the expectations of conformance and responsibilities of Program participants. Health IT developers are still required to meet certification criteria requirements and maintain their products' conformance to the full scope of the associated criteria, including when implemented in the field and in production use. Similarly, ONC and ONC-ACBs continue to conduct surveillance activities and respond to end-user complaints. 6 https://www.healthit.gov/buzz-blog/healthit-certification/certification-program-updates-support-efficiency-reduce-burden/. 7 https://www.healthit.gov/sites/default/files/policy/selfdeclarationapproachprogramguidance17-04.pdf. B. Proposed Deregulatory Actions We propose six deregulatory actions below. We welcome comments on these potential deregulatory actions and any other potential deregulatory actions we should consider. We also refer readers to section XIV (Regulatory Impact Analysis) of this proposed rule for a discussion of the estimated cost savings from these proposed deregulatory actions. 1. Removal of Randomized Surveillance Requirements ONC-ACBs are required to conduct surveillance of certified health IT under the Program to ensure that health IT continues to conform and function as required by the full scope of the certification requirements. Surveillance is categorized as either reactive surveillance (for example, complaint-based surveillance) or randomized surveillance, which, by regulation, requires ONC-ACBs to proactively surveil 2% of the certificates they issue annually. On September 21, 2017, we exercised enforcement discretion with respect to the implementation of randomized surveillance by ONC-ACBs. 8 Consistent with this exercise of enforcement discretion, we now propose to eliminate certain regulatory randomized surveillance requirements. 8 https://www.healthit.gov/sites/default/files/ONC_Enforcement_Discretion_Randomized_Surveillance_8-30-17.pdf. We propose to revise §  170.556(c) by changing the requirement that ONC-ACBs must conduct in-the-field, randomized surveillance to specify that ONC-ACBs may conduct in-the- field, randomized surveillance. We further propose to remove §  170.556(c)(2), which specifies that ONC-ACBs must conduct randomized surveillance for a minimum of 2% of certified health IT products per year. We also propose to remove the requirements in § 170.556(c)(5) regarding the exclusion and exhaustion of selected locations for randomized surveillance. Additionally, we propose to remove the requirements in §  170.556(c)(6) regarding the consecutive selection of certified health IT for randomized surveillance. Without these regulatory requirements, ONC-ACBs would still be required to perform reactive surveillance, and would be permitted to conduct randomized surveillance of their own accord, using the methodology identified by ONC with respect to scope (§  170.556(c)(1)), selection method (§  170.556(c)(3)), and the number and types of locations for in-the-field surveillance (§  170.556(c)(4)). Stakeholders have expressed concern that the benefits of in-the-field, randomized surveillance may not outweigh the time commitment required by providers, particularly if no non-conformities are found. In general, providers have expressed that reactive surveillance ( e.g., surveillance based on user complaints) is a more logical and economical approach to surveillance. The removal of randomized surveillance requirements would also give ONC-ACBs the flexibility and time to focus on other priorities, such as the certification of health IT to the 2015 Edition. Therefore, as discussed above, we propose to eliminate certain regulatory randomized surveillance requirements. 2. Removal of the 2014 Edition From the Code of Federal Regulations We propose to remove the 2014 Edition from the Code of Federal Regulations (CFR). The 2014 Edition was the result of rulemaking completed in 2012 and includes standards and functionality that are now significantly outmoded. Removal of the 2014 Edition would make the 2015 Edition the baseline for health IT certification. The 2015 Edition, including the additional certification criteria, standards, and requirements proposed in this proposed rule, better enables interoperability and the access, exchange, and use of electronic health information. Adoption and implementation of the 2015 Edition, including the proposals in this proposed rule, would also lead to the benefits outlined in the 2015 Edition final rule (80 FR 62602-62603, 62605-62606, 62740) and in this proposed rule ( see, for example, the Executive Summary and the “Assurances,” “API”, and “Real World Testing” Conditions and Maintenance of Certification sections). Equally important, adoption and implementation of the 2015 Edition by providers would lead to the estimated costs savings in this proposed rule through improved interoperability supporting the access, exchange, and use of electronic health information. Removal of the 2014 Edition would eliminate inconsistencies and costs caused by health IT certification and implementation of two different editions with different functionalities and versions of standards. Patient care could improve through the reduced risk of error that comes with the health care system's consistent implementation and use of health IT certified to the 2015 Edition. Innovation could also improve with health IT developers (including third-party software developers) developing to only one set of newer standards and implementation specifications, which would be more predictable and less costly. Removal of the 2014 Edition would also reduce regulatory burden by no longer requiring the maintenance and support of the 2014 Edition. Maintaining compliance with only the 2015 Edition would reduce the cost and burden for health IT developers, ONC-ACBs, and ONC-ATLs because they would no longer have to support two increasingly distinct sets of requirements as is the case now with certification to both the 2014 and 2015 Editions. More specifically, health IT developers would not have to support two maintenance infrastructures and updating for their customers; nor would ONC-ATLs and ONC-ACBs have to support testing, certification, and surveillance for two separate editions of certified health IT. As referenced by the HHS Office of Inspector General (OIG) and Centers for Medicare & Medicaid Services (CMS) in their rulemakings regarding donations of EHR items and services, we committed to retiring certification criteria editions that are no longer applicable. 9 We first did this with the removal of the 2011 Edition (79 FR 54447). Accordingly, our proposal to remove the outdated 2014 Edition for the reasons discussed above would also streamline Program compliance requirements and ensure there is no regulatory confusion between ONC's rules and other HHS rules. 9 CMS final rule “Medicare Program; Physicians' Referrals to Health Care Entities With Which They Have Financial Relationships: Exception for Certain Electronic Health Records Arrangements” ( 78 FR 78751 ).OIG final rule “Medicare and State Health Care Programs: Fraud and Abuse; Electronic Health Records Safe Harbor Under the Anti-Kickback Statute” ( 78 FR 79202 ). To implement the removal of the 2014 Edition from the CFR, we propose to remove the 2014 Edition certification criteria (§ 170.314) and related standards, terms, and requirements from the CFR. In regard to terms, we propose to retire the 2014 Edition-related definitions found in § 170.102, including the “2014 Edition Base EHR,” “2014 Edition EHR certification criteria,” and “Complete EHR, 2014 Edition.” As explained in the 2015 Edition final rule (80 FR 62719), the ability to maintain Complete EHR certification is only permitted with health IT certified to the 2014 Edition certification criteria. Because this concept was discontinued for the 2015 Edition, we propose to remove § 170.545 and any references to Complete EHR from the regulation text in conjunction with the removal of the 2014 Edition. We also propose to remove references to the 2014 Edition from the Common Clinical Data Set (CCDS) definition. However, as discussed later in section IV.B.1 (“United States Core Data for Interoperability”) of this proposed rule, we propose to remove the CCDS definition from the CFR and effectively replace it with a new government-unique standard, the United States Core Data for Interoperability (USCDI), proposing to adopt Version 1 (v1) in § 170.213. The new standard would be applicable to certain 2015 Edition certification criteria that currently reference the CCDS, subject to any of these criteria being removed through this rulemaking). We propose to remove the standards and implementation specifications found in §§ 170.200, 170.202, 170.204, 170.205, 170.207, 170.210, and 170.299 that are only referenced in the 2014 Edition certification criteria. Adopted standards that are also referenced in the 2015 Edition would remain. We propose to remove requirements in §  170.550(f) and any other requirements in subpart E, §§  170.500 through 170.599, which are specific to the 2014 Edition and do not apply to the 2015 Edition. In order to avoid regulatory conflicts, we are taking into consideration the final rule released by CMS on November 2, 2017, which makes payment and policy changes to the second year of the Quality Payment Program (QPP). The CMS's final rule, titled “Medicare Program; CY 2018 Updates to the Quality Payment Program: Extreme and Uncontrollable Circumstance Policy for the Transition Year” (82 FR 53568), permits eligible clinicians to use health IT certified to either the 2014 or 2015 Edition certification criteria, or a combination of the two for the CY 2018 performance period. The QPP final rule also states that the 2015 Edition will be the sole edition permitted to meet the CEHRT definition starting with the CY 2019 program year. Therefore, we propose that the effective date of removal of the 2014 Edition certification criteria and related standards, terms, and requirements from the CFR would be the effective date of a subsequent final rule for this proposed rule, which we expect will be issued in the latter half of 2019. We note that we will continue to support Medicare and Medicaid program attestations by maintaining an archive on the CHPL allowing the public to access historic information on a product certified to the 2014 Edition. 3. Removal of the ONC-Approved Accreditor From the Program We propose to remove the ONC-Approved Accreditor (ONC-AA) from the Program. The ONC-AA's role is to accredit certification bodies for the Program and to oversee the ONC-ACBs. However, years of experience and changes with the Program have led ONC to conclude that, in many respects, the role of the ONC-AA to oversee ONC-ACBs is now duplicative of ONC's oversight. More specifically, ONC's experience with administering the Principles of Proper Conduct for ONC-ACBs as well as issuing necessary regulatory changes ( e.g., ONC-ACB surveillance and reporting requirements in the 2015 Edition final rule) has demonstrated that ONC on its own has the capacity to provide the appropriate oversight of ONC-ACBs. Therefore, we believe removal of the ONC-AA would reduce the Program's administrative complexity and burden. To implement this proposed deregulatory action, we propose to remove the definition for “ONC-Approved Accreditor or ONC-AA” found in § 170.502. We also propose to remove processes related to ONC-AAs found in §§  170.501(c), 170.503, and 170.504 regarding requests for ONC-AA status, ONC-AA ongoing responsibilities, and reconsideration for requests for ONC-AA status. Regarding correspondence and communication with ONC, we propose to remove specific references to the “ONC-AA” and “accreditation organizations requesting ONC-AA status” by revising § 170.505. We also propose to remove the final rule titled “Permanent Certification Program for Health Information Technology; Revisions to ONC-Approved Accreditor Processes” (76 FR 72636) which established a process for addressing instances where the ONC-AA engages in improper conduct or does not perform its responsibilities under the Program. Because this prior final rule relates solely to the role and removal of the ONC-AA, we propose its removal and § 170.575, which codified the final rule in the CFR. These proposed deregulatory actions would also provide an additional benefit for ONC-ACBs. ONC-ACBs would be able to obtain and maintain accreditation to ISO/IEC 17065, with an appropriate scope, from any accreditation body that is a signatory to the Multilateral Recognition Arrangement (MLA) with the International Accreditation Forum (IAF). Accordingly, we propose to revise the application process for ONC-ACB status in § 170.520(a)(3) to require documentation that confirms that the applicant has been accredited to ISO/IEC 17065, with an appropriate scope, by any accreditation body that is a signatory to the Multilateral Recognition Arrangement (MLA) with the International Accreditation Forum (IAF), in place of the ONC-AA accreditation documentation requirements. Similarly, instead of requiring the ONC-AA to evaluate the conformance of ONC-ACBs to ISO/IEC 17065, we propose to revise § 170.523(a) to simply require ONC-ACBs to maintain accreditation in good standing to ISO/IEC 17065 for the Program. This means that ONC-ACBs would need to continue to comply with ISO/IEC 17065 and requirements specific to the ONC Health IT Certification Program scheme. 4. Removal of Certain 2015 Edition Certification Criteria and Standards We have reviewed and analyzed the 2015 Edition to determine whether there are certification criteria we could remove. We have identified both criteria and standards for removal as proposed below. We believe the removal of these criteria and standards will reduce burden and costs for health IT developers and health care providers by eliminating the need to: Design and meet specific certification functionalities; prepare, test, and certify health IT in certain instances; adhere to associated reporting and disclosure requirements; maintain and update certifications for certified functionalities; and participate in surveillance of certified health IT. To these points, if our proposals are finalized in a subsequent final rule, we would expect any already issued 2015 Edition certificates to be updated to reflect the removal of applicable 2015 Edition certification criteria. We welcome comment on the proposed removal of the identified criteria and standards below and any other 2015 Edition criteria and standards we should consider for removal. a. 2015 Edition Base EHR Definition Criteria We propose the removal of certain certification criteria from the 2015 Edition that are included in the 2015 Edition Base EHR definition. The removal of these criteria would support burden and cost reductions for health IT developers and health care providers as noted above. i. Problem List We propose to remove the 2015 Edition “problem list” certification criterion (§ 170.315(a)(6)). The functionality in this criterion was first adopted as a 2011 Edition certification criterion to support the associated meaningful use Stage 1 objective and measure for recording problem list information. In this regard, SNOMED CT® was adopted specifically to support the measure. This 2015 Edition “problem list” criterion remains relatively functionally the same as the 2011 Edition and has exactly the same functionally as the 2014 Edition “problem list” criterion. We propose to remove this criterion for multiple reasons. First, this criterion no longer supports the “recording” objective and measure of the CMS Promoting Interoperability Programs as such objective and measure no longer exist. Second, the functionality is sufficiently widespread among health care providers since it has been part of certification and the Certified EHR Technology definition since the 2011 Edition and has not substantively changed with the 2015 Edition. Third, we do not believe this functionality would be removed from health IT systems because of our proposal to remove it from the 2015 Edition Base EHR definition. This functionality is essential to clinical care and would be in EHR systems absent certification, particularly considering the limited certification requirements. Fourth, this functionality does not directly support interoperability as the capabilities are focused on internally recording EHI. In this regard, representing problems with SNOMED CT® is part of the USCDI and, thus, better supports interoperability through its availability for access and exchange. Accordingly, we propose to remove the “problem list” criterion from the 2015 Edition, including the 2015 Edition Base EHR definition. We note that once removed from the 2015 Edition, the criterion would also no longer be included in the 2015 Edition “safety-enhanced design” criterion. ii. Medication List We propose to remove the 2015 Edition “medication list” certification criterion (§ 170.315(a)(7)). The functionality in this criterion was first adopted as a 2011 Edition certification criterion to support the associated meaningful use Stage 1 objective and measure for recording medication list information. The criterion does not require use of a vocabulary standard to record medications. This 2015 Edition “medication list” criterion remains functionally the same as the 2011 Edition and 2014 Edition “medication list” criteria. We propose to remove this criterion for multiple reasons. First, this criterion no longer supports a “recording” objective and measure of the CMS Promoting Interoperability Programs as such objective and measure no longer exist. Second, the functionality is sufficiently widespread among health care providers since it has been part of certification and the Certified EHR Technology definition since the 2011 Edition and has not substantively changed with the 2015 Edition. Third, we do not believe this functionality would be removed from EHR systems because of our proposal to remove it from the 2015 Edition Base EHR definition. This functionality is essential to clinical care and would be in EHR systems absent certification, particularly considering the limited certification requirements. Fourth, this functionality does not directly support interoperability as the capabilities are focused on internally recording EHI. In this regard, this criterion does not even require representation of medications in standardized nomenclature. Fifth, medications are included in the USCDI and must be represented in RxNorm as part of the USCDI. This approach better supports interoperability through medication information being availability for access and exchange in a structured format. Accordingly, we propose to remove the “medications list” criterion from the 2015 Edition, including the 2015 Edition Base EHR definition. We note that once removed from the 2015 Edition, the criterion would also no longer be included in the 2015 Edition “safety-enhanced design” criterion. iii. Medication Allergy List We propose to remove the 2015 Edition “medication allergy list” certification criterion (§ 170.315(a)(8)). The functionality in this criterion was first adopted as a 2011 Edition certification criterion to support the associated meaningful use Stage 1 objective and measure for recording this information. The criterion does not require use of a vocabulary standard to record medication allergies. This 2015 Edition “medication allergy list” criterion remains functionally the same as the 2011 Edition and 2014 Edition “medication allergy list” criteria. We propose to remove this criterion for multiple reasons. First, this criterion no longer supports a “recording” objective and measure of the CMS Promoting Interoperability Programs as such objective and measure no longer exist. Second, the functionality is sufficiently widespread among health care providers since it has been part of certification and the Certified EHR Technology definition since the 2011 Edition and has not substantively changed with the 2015 Edition. Third, we do not believe this functionality would be removed from EHR systems because of our proposal to remove it from the 2015 Edition Base EHR definition. This functionality is essential to clinical care and would be in EHR systems absent certification, particularly considering the limited certification requirements. Fourth, this functionality does not directly support interoperability as the capabilities are focused on internally recording EHI. In this regard, this criterion does not even require representation of medication allergies in standardized nomenclature. Fifth, medication allergies are included in the USCDI and must be represented in RxNorm as part of the USCDI. This approach better supports interoperability through medication allergy information being availability for access and exchange in a structured format. Accordingly, we propose to remove the “medication allergy list” criterion from the 2015 Edition, including the 2015 Edition Base EHR definition. We note that once removed from the 2015 Edition, the criterion would also no longer be included in the 2015 Edition “safety- enhanced design” criterion. iv. Smoking Status We propose to remove the 2015 Edition “smoking status” criterion (§ 170.315(a)(11)), which would include removing it from the 2015 Edition Base EHR definition. We previously adopted a 2015 Edition “smoking status” certification criterion that does not reference a standard. However, the CCDS definition requires smoking status to be coded in accordance with SNOMED CT®. While we continue to believe that the capture of a patient's smoking status has significant value in assisting providers with addressing the number one cause of preventable death and disease in the United States, we no longer believe that a criterion that simply ensures this functionality exists in health IT presented for certification is the right focus. As with other 2014 Edition functionality, we believe this functionality is fairly ubiquitous now with the widespread adoption of health IT certified to the 2014 Edition. Further, we continue to believe that, for the purposes of certification, having smoking status available for access and exchange via the USCDI is ultimately the key requirement for supporting interoperability. Removal of Specific USCDI Smoking Status Code Sets As mentioned above, we believe having smoking status available for USCDI purposes is fundamentally important for supporting interoperability. We propose, however, to remove the requirement to code smoking status according to the adopted eight smoking status SNOMED CT® codes as referenced in the value set in § 170.207(h). These eight codes reflect an attempt to capture smoking status in a consistent manner. Stakeholder feedback has, however, indicated that these eight codes do not appropriately and accurately capture all applicable patients' smoking statuses. Accordingly, we propose to no longer require use of only the specific eight SNOMED CT® codes for representing smoking status (and remove the standard from § 170.207). Rather, to continue to promote interoperability while also granting providers with flexibility to better support clinical care, we propose that health IT would simply be required to be capable of representing smoking status in SNOMED CT® when such information is exchanged as part of the USCDI. b. Drug-Formulary and Preferred Drug Lists We propose to remove the 2015 Edition “drug formulary and preferred drug list checks” criterion in § 170.315(a)(10). We adopted a 2015 Edition “drug-formulary and preferred drug list checks” criterion that separates drug formulary and preferred drug list functionality, but does not require any standards or functionality beyond that included in the 2014 Edition “drug-formulary checks” criterion. First, we believe this functionality is fairly ubiquitous now with the widespread adoption of health IT certified to the 2014 Edition, which included this general functionality. Second, without standards, this criterion does not support or facilitate the critical goal of health IT interoperability. Therefore, removal of this criterion could reduce health IT developer and health care provider burden. c. Patient-Specific Education Resources We propose to remove the 2015 Edition “patient-specific education resources” certification criterion (§ 170.315(a)(13)). ONC continues to support patient and provider interaction, and the identification and dissemination of patient-specific educational materials to promote positive health outcomes. However, we no longer believe that certification focused on a health IT's ability to identifying the existence of patient-specific education materials encourages the advancement of this functionality or interoperability. First, this criterion would no longer be associated with an objective or measure under the Promoting Interoperability Programs based on proposals and determinations in recent CMS rulemakings (83 FR 35928; 83 FR 41664). Second, based on the number of health IT products that have been certified for this functionality as part of 2014 Edition certification and already for 2015 Edition certification, we believe that health IT's ability to identify appropriate patient education materials is widespread now among health IT developers and their customers ( e.g., health care providers). Third, we have recently seen innovative advancements in this field, including the use of automation and algorithms to provide appropriate educations materials to patients in a timely manner. These advancements help limit clinical workflow interruptions and demonstrate the use and promise of health IT to create efficiencies and improve patient care. As such, removal of this criterion would prevent certification from creating an unnecessary burden for developers and providers and an impediment to innovation. d. CCDS Summary Record—Create; and CCDS Summary Record—Receive We assessed the number of products certified to the 2015 Edition “Common Clinical Data Set summary record—create” (§ 170.315(b)(4)) and “Common Clinical Data Set summary record—receive” (§ 170.315(b)(5)) criteria that have not also been certified to the 2015 Edition “transitions of care” criterion (§ 170.315(b)(1)). We did this because the 2015 Edition “CCDS summary record” criteria include the same functionality as the 2015 Edition “transitions of care” criterion, except for Direct-related transport functionality. Based on our findings of only two unique products certified to these criteria at the time of the drafting of this proposed rule, there appears to be little market demand for certification to them. This outcome is likely attributable to the fact mentioned above regarding their relationship to the 2015 Edition “transition of care” criterion, that they are not included in the 2015 Edition Base EHR definition, and that no HHS program specifically requires the use of health IT certified to the criteria. Therefore, we propose to remove these certification criteria from the 2015 Edition. e. Secure Messaging We propose to remove the 2015 Edition “secure messaging” criterion (§ 170.315(e)(2)). ONC strongly supports patient and provider communication, as well as protecting the privacy and security of patient information. However, we no longer believe that separate certification focused on a health IT's ability to send and receive secure messages between health care providers and patients is necessary. First, this criterion would no longer be associated with an objective or measure under the Promoting Interoperability Programs based on proposals and determinations in recent CMS rulemakings (83 FR 41664; 83 FR 35929). Second, there are multiple other 2015 Edition certification criteria that support patient engagement, such as the 2015 Edition “view, download, and transmit to 3rd party,” “API,” and “patient health information capture” certification criteria. Third, we have seen developers integrate this functionality as part of other patient engagement features, such as patient portals. With these considerations in mind and the lack of a negative impact on health IT interoperability, we believe that the removal of this criterion will help reduce burden and costs, while also spurring further innovations in patient engagement. 5. Removal of Certain ONC Health IT Certification Program Requirements We propose to remove certain mandatory disclosure requirements and a related attestation requirement under the Program. We believe removal of these requirements will reduce costs and burden for Program stakeholders, particularly health IT developers and ONC-ACBs. We welcome comment on the proposed removal of these requirements and any other certification or Program requirements we should consider for removal. a. Limitations Disclosures We propose to remove § 170.523(k)(1)(iii)(B), which requires ONC-ACBs to ensure that certified health IT includes a detailed description of all known material information concerning limitations that a user may encounter in the course of implementing and using the certified health IT, whether to meet “meaningful use” objectives and measures or to achieve any other use within the scope of the health IT's certification. We also propose to remove § 170.523(k)(1)(iv)(B) and (C), which state that the types of information required to be disclosed include, but are not limited to: (B) Limitations, whether by contract or otherwise, on the use of any capability to which technology is certified for any purpose within the scope of the technology's certification; or in connection with any data generated in the course of using any capability to which health IT is certified; (C) Limitations, including but not limited to technical or practical limitations of technology or its capabilities, that could prevent or impair the successful implementation, configuration, customization, maintenance, support, or use of any capabilities to which technology is certified; or that could prevent or limit the use, exchange, or portability of any data generated in the course of using any capability to which technology is certified. These disclosure requirements regarding certified health IT limitations are superseded by the Cures Act information blocking provision and Conditions of Certification, which we are implementing with this proposed rule. In particular, section 3001(c)(5)(D)(ii) of the Cures Act requires that a health IT developer, as a Condition of Certification under the Program, provide assurances to the Secretary that, unless for legitimate purposes specified by the Secretary, the developer will not take any action that constitutes information blocking as defined in section 3022(a) of the PHSA, or any other action that may inhibit the appropriate exchange, access, and use of electronic health information. These assurances specifically focus on preventing information blocking and promoting appropriate exchange, access, and use of electronic health information. We further propose adding as a complementary Condition of Certification that developers would be prohibited from taking any action that could interfere with a user's ability to access or use certified capabilities for any purpose within the scope of the technology's certification. Such actions may inhibit the appropriate access, exchange, or use of electronic health information and are therefore contrary to this proposed Condition of Certification and the statutory provision that it implements. Based on these Conditions of Certification, we believe that disclosures of limitations by health IT developers would be unlikely and unnecessary given their prohibition. b. Transparency and Mandatory Disclosures Requirements We propose to remove the Principle of Proper Conduct (PoPC) in § 170.523(k)(2), which requires a health IT developer to submit an attestation that it will disclose all of the information in its mandatory disclosures per § 170.523(k)(1) to specified parties ( e.g., potential customers or anyone inquiring about a product quote or description of services). We propose that this provision is no longer necessary and that its removal is appropriate to further reduce administrative burden for health IT developers and ONC-ACBs. First, our experience with developer attestations to this requirement is that over 90% of developers with certified health IT have attested that they will provide “transparency information.” Second, the information that developers would be asked to attest to, whether our proposal above to remove certain disclosure requirements is finalized or not, is now readily available on health IT developers' websites as the mandatory disclosure requirements were implemented almost three years ago. Therefore, we believe removal of this requirement is appropriate. 6. Recognition of Food and Drug Administration Processes Section 618 of the Food and Drug Administration Safety and Innovation Act (FDASIA), Public Law 112-144, required that the Food and Drug Administration (FDA), in consultation with ONC and the Federal Communications Commission (FCC) (collectively referred to as “the Agencies” 10 for this proposal), develop a report that contains a proposed strategy and recommendations on an appropriate, risk-based regulatory framework pertaining to health IT, including mobile medical applications, that promotes innovation, protects patient safety, and avoids regulatory duplication. The FDASIA Health IT Report of April 2014 11 contains a proposed strategy and recommendations on an appropriate, risk-based regulatory framework pertaining to health IT that promotes innovation, protects patient safety, and avoids regulatory duplication. Public comments, received prior to the report and after, 12 recommended that health IT developers/manufacturers apply a single process that satisfies the requirements of all agencies and that existing safety and quality-related processes, systems, and standards should be leveraged for patient safety in health IT. On July 27, 2017, FDA announced a voluntary Software Precertification (Pre-Cert) Pilot Program as part of a broader Digital Health Innovation Action Plan. 13 It was developed in order to create a tailored approach toward recognizing the unique characteristics of digital technology by looking first at the firm, rather than primarily at each product of the firm, as is currently done for traditional medical products. The FDA plans to explore whether and how pre-certified companies that have demonstrated a culture of quality, patient safety, and organizational excellence could bring certain types of digital health products to market either without FDA premarket review or with a more streamlined FDA premarket review. 10 ONC is not an agency, but an Office, within the Department of Health and Human Services. 11 https://www.fda.gov/downloads/AboutFDA/CentersOffices/OfficeofMedicalProductsandTobacco/CDRH/CDRHReports/UCM391521.pdf. 12 https://www.federalregister.gov/documents/2013/05/30/2013-12817/food-and-drug-administration-safety-and-innovation-act-fdasia-request-for-comments-on-the; https://blogs.fda.gov/fdavoice/index.php/2014/04/fda-seeks-comment-on-proposed-health-it-strategy-that-aims-to-promote-innovation/; and https://www.regulations.gov/document?D=FDA-2014-N-0339-0001. 13 https://www.fda.gov/MedicalDevices/DigitalHealth/DigitalHealthPreCertProgram/Default.htm. a. FDA Software Pre-Certification Pilot Program ONC believes that health IT developers that hold precertification under the FDA Digital Health Software Precertification Program (FDA Software Precertification Program) when they present health IT for certification under the Program could qualify for, and benefit from, further efficiencies under the Program. Title IV of the Cures Act provides ONC with authority under the Program to oversee health IT developers through Conditions and Maintenance of Certification requirements ( see section VII Conditions and Maintenance of Certification of this proposed rule). With this new authority and our authority over health IT developers' health IT certified under the Program, we propose to establish processes that would provide health IT developers that can document holding precertification under the FDA Software Precertification Program with exemptions to the ONC Health IT Certification Program's requirements for testing and certification of its health IT to the 2015 Edition “quality management systems” criterion (§ 170.315(g)(4)) and the 2015 Edition “safety-enhanced design” criterion (§ 170.315(g)(3)), as these criteria are applicable to the health IT developer's health IT presented for certification. We also believe that such a “recognition” could, depending on the final framework of the FDA Software Precertification Program ( e.g., the key performance indicators used to demonstrate performance and outcomes of excellence), be applicable to the functionally-based 2015 Edition “clinical” certification criteria (§ 170.315(a)). More specifically, this could address the “computerized provider order entry (CPOE)” (§ 170.315(a)(1), (2), and (3)), “drug-drug, drug-allergy interaction checks for CPOE” (§ 170.315(a)(4)), “clinical decision support” (§ 170.315(a)(9)), and “implantable device list” (§ 170.315(a)(14)) certification criteria. Such “recognition” could also be appropriate to address any or all of the following functionally-based 2015 Edition criteria in the event their proposed removal is not finalized: “problem list” (§ 170.315(a)(6)), “medication list” (§ 170.315(a)(7)), “medication allergy list” (§ 170.315(a)(8)), “drug-formulary and preferred drug list checks” (§ 170.315(a)(10)),” and “smoking status” (§ 170.315(a)(11)). Our proposed “recognition” would align with both Executive Orders 13563 and 13771 regarding deregulatory, less burdensome, and more effective initiatives. It would also serve as a regulatory relief for those health IT developers qualifying as small businesses under the Regulatory Flexibility Act ( see section XIV.C.3 Regulatory Flexibility Act of this proposed rule). Furthermore, it would closely align with FDASIA's instruction to promote innovation, protect patient safety, and avoid regulatory duplication. However, despite these proffered benefits, there may be reasons not to adopt such a “recognition” approach. For example, stakeholders may not agree that the FDA Software Precertification Program (and/or subsequent finalized program) sufficiently aligns with our Program. Developers and providers may have varying and divergent views about the benefits and detriments of such an approach. Further, while we believe that we could properly operationalize such an approach by ensuring certifications indicate which criteria have been “deemed certified” by ONC (but still subject to ONC-ACB surveillance), stakeholders may have other operational concerns. Accordingly, we welcome comments on these and other aspects of our proposed “recognition” approach, including the 2015 Edition certification criteria that should be eligible for “recognition.” b. Development of Similar Independent Program Processes—Request for Information Recognition of the FDA Software Pre-Certification Program for purposes of our Program, as noted above, may eventually be determined to be infeasible or insufficient to meet our goals of reducing burden and promoting innovation. With this in mind, we request comment on whether ONC should establish new regulatory processes tailored towards recognizing the unique characteristics of health IT ( e.g., EHR software) by looking first at the health IT developer, rather than primarily at the health IT presented for certification, as is currently done under the Program. For example, ONC could possibly establish Conditions and Maintenance of Certification requirements, through rulemaking, that facilitate the deeming of all of a health IT developer's health IT as “certified” under the Program for certification criteria identified by ONC as solely “functionally-based” criteria ( i.e., not essential to interoperability, such as the “CPOE” criteria) or possibly broader in scope. This approach could rely on, but not be limited to, one or a combination of the following: (1) Certain demonstrated health IT developer processes or health IT functionality; (2) prior successful certification of a health IT developer's health IT under the Program; (3) results of real world testing for interoperability as required by the Cures Act and the proposed implementing regulatory Condition of Certification ( see section VII.B.5 of this proposed rule); and/or (4) the results of the EHR Reporting Program once implemented ( see section VII.B.7 of this proposed rule). No matter the specifics, we are most interested in whether stakeholders believe this is an approach we should pursue in conjunction with, or in lieu of, the proposed approach of recognizing the FDA Software Pre-Certification Pilot Program. We also welcome more specific comments on the health IT developer criteria for such an approach and what the Conditions and/or Maintenance of Certification requirements should be to support such an approach within the framework of the proposed Conditions and Maintenance of Certification requirements discussed in section VII of this proposed rule. IV. Updates to the 2015 Edition Certification Criteria This rule proposes to update the 2015 Edition by revising and adding certification criteria that would establish the capabilities and related standards and implementation specifications for the certification of health IT. The updates to the 2015 Edition would enhance interoperability and improve the accessibility of patient records consistent with section 4006(a) of the Cures Act. A. 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 14 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 standards 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 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: 14 https://www.whitehouse.gov/sites/whitehouse.gov/files/omb/circulars/A119/revised_circular_a-119_as_of_1_22.pdf. • The standard we propose to adopt in § 170.213. We propose to remove the Common Clinical Data Set (CCDS) definition and effectively replace it with a government unique standard, the United States Core Data for Interoperability (USCDI), Version 1(v1); • The standard we propose to adopt in § 170.215(a)(2). We propose the government unique API Resource Collection in Health (ARCH) Version 1 implementation specification; • The standards we propose to adopt in § 170.215(a)(3) through (5) for application programming interfaces (APIs). These market driven consortia standards have been developed through a streamlined process that does not meet the full definition of voluntary consensus standards development but still includes representation from those interested in the use cases supported by the standards ( e.g., health IT developers and health care providers). In the absence of available voluntary consensus standards that would meet our needs, these standards deliver favorable technical and economic outcomes, particularly improved interoperability. Further, some of these standards may eventually proceed through a standards development organization for approval; and • The standards we propose to adopt in § 170.205(h)(3) and (k)(3). We propose to replace the current HL7 QRDA standards with government unique standards that more effectively support the associated certification criterion's use case, which is reporting eCQM data to CMS. 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 Argonaut Data Query Implementation Guide (IG) proposed in this proposed rule ( see section VII.B.4.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 XI (“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. B. Revised and New 2015 Edition Criteria In order to capture and share patient data efficiently, health care providers need health IT that store data in structured formats. Structured data allows health care providers to easily retrieve and transfer patient information, and use health IT in ways that can aid patient care. We propose to adopt revised and new 2015 Edition certification criteria, including new standards, to support these objectives. Some of these criteria and standards are included in the Certified EHR Technology (CEHRT) definition used for participation in HHS Programs, such as the Promoting Interoperability Programs (formerly the EHR Incentive Programs), some are required to be met for participation in the ONC Health IT Certification Program, and some, though beneficial, are unassociated with the CEHRT definition and not required for participating in any HHS program, including the ONC Health IT Certification Program. 1. The United States Core Data for Interoperability Standard (USCDI) The initial focus of the Program was to support the Medicare and Medicaid EHR Incentive Programs (76 FR 1294) now referred to as the Promoting Interoperability Programs (and referenced as such hereafter). As such, the 2014 Edition certification criteria mirrored those functions specified by Promoting Interoperability Programs' objectives and measures. In order to improve efficiency and streamline the common data within our Program's certification criteria, we created a single definition for all the required data which could be referenced for all applicable certification criteria. We created the term “Common MU Data Set” to encompass the common set o [Text truncated at 120,000 characters. The full text is on the page linked above.] --- Source: Frix Law Library, https://www.frixlaw.com/law-library/documents/fr%3A2019-02224. Public record. Not legal advice.