| Page Range | 72404-72471 | |
| FR Document | 2016-24908 |
[Federal Register Volume 81, Number 202 (Wednesday, October 19, 2016)] [Rules and Regulations] [Pages 72404-72471] From the Federal Register Online [www.thefederalregister.org] [FR Doc No: 2016-24908] [[Page 72403]] Vol. 81 Wednesday, No. 202 October 19, 2016 Part III Department of Health and Human Services ----------------------------------------------------------------------- 45 CFR Part 170 ONC Health IT Certification Program: Enhanced Oversight and Accountability; Final Rule Federal Register / Vol. 81 , No. 202 / Wednesday, October 19, 2016 / Rules and Regulations [[Page 72404]] ----------------------------------------------------------------------- DEPARTMENT OF HEALTH AND HUMAN SERVICES Office of the Secretary 45 CFR Part 170 RIN 0955-AA00 ONC Health IT Certification Program: Enhanced Oversight and Accountability AGENCY: Office of the National Coordinator for Health Information Technology, Department of Health and Human Services. ACTION: Final rule. ----------------------------------------------------------------------- SUMMARY: This final rule finalizes modifications and new requirements under the ONC Health IT Certification Program (``Program''), including provisions related to the Office of the National Coordinator for Health Information Technology (ONC)'s role in the Program. The final rule creates a regulatory framework for ONC's direct review of health information technology (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. DATES: These regulations are effective December 19, 2016. The incorporation by reference of the publication listed in the rule is approved by the Director of the Federal Register as of December 19, 2016. FOR FURTHER INFORMATION CONTACT: Michael Lipinski, Office of Policy, Office of the National Coordinator for Health Information Technology, 202-690-7151. SUPPLEMENTARY INFORMATION: Commonly Used Acronyms CAP Corrective Action Plan CEHRT Certified Electronic Health Record Technology CFR Code of Federal Regulations CHPL Certified Health IT Product List EHR Electronic Health Record HHS Department of Health and Human Services HIT Health Information Technology ISO/IEC International Organization for Standardization/International Electrotechnical Commission NVLAP National Voluntary Laboratory Accreditation Program OMB Office of Management and Budget ONC Office of the National Coordinator for Health Information Technology ONC-ACB ONC-Authorized Certification Body ONC-ATCB ONC-Authorized Testing and Certification Body ONC-ATL ONC-Authorized Testing Laboratory PoPC Principles of Proper Conduct Table of Contents I. Executive Summary A. Purpose of Regulatory Action B. Summary of Major Provisions 1. ONC Direct Review of Certified Health IT 2. ONC-Authorized Testing Laboratories 3. Transparency and Availability of Identifiable Surveillance Results C. Costs and Benefits 1. Costs 2. Benefits II. Provisions of the Final Rule A. ONC's Role Under the ONC Health IT Certification Program 1. Review of Certified Health IT a. Authority and Scope (1) Requirements of the Program (2) Review of Uncertified Capabilities (3) Scope of Review b. ONC-ACB's Role c. Review Processes (1) Notice of Potential Non-Conformity or Non-Conformity (2) Corrective Action (3) Suspension (4) Termination (5) Appeal d. Consequences of Certification Termination (1) Certification Ban, Recertification, and Heightened Scrutiny (2) ONC-ACB Response to a Non-Conformity 2. Establishing ONC Authorization for Testing Labs Under the Program; Requirements for ONC-ATL Conduct; ONC Oversight and Processes for ONC-ATLs a. General Comments on the ONC-ATL Approach b. Regulatory Provisions for Inclusion of ONC-ATLs in the Program (1) Sec. 170.501 Applicability (2) Sec. 170.502 Definitions (3) Sec. 170.505 Correspondence (4) Sec. 170.510 Type of Certification (5) Sec. 170.511 Authorization Scope for ONC-ATL Status (6) Sec. 170.520 Application (7) Sec. 170.523 Principles of Proper Conduct for ONC-ACBs (8) Sec. 170.524 Principles of Proper Conduct for ONC-ATLs (9) Sec. 170.525 Application Submission (10) Sec. 170.530 Review of Application (11) Sec. 170.535 ONC-ACB Application Reconsideration (12) Sec. 170.540 ONC-ACB Status (13) Sec. 170.557 Authorized Certification Methods (14) Sec. 170.560 Good Standing as an ONC-ACB (15) Sec. 170.565 Revocation of ONC-ACB Status (16) Sec. 170.570 Effect of Revocation on the Certifications Issued To Complete EHRs and Health IT Module(s) B. Public Availability of Identifiable Surveillance Results III. National Technology Transfer and Advancement Act and the Office of Management and Budget Circular A-119 IV. Incorporation by Reference V. Collection of Information Requirements A. ONC-AA and ONC-ACBs B. ONC-ATLs C. Health IT Developers VI. Regulatory Impact Statement A. Statement of Need B. Alternatives Considered C. Overall Impact 1. Executive Orders 12866 and 13563--Regulatory Planning and Review Analysis a. Costs (1) Costs for Health IT Developers To Correct a Non-Conformity Identified by ONC (2) Costs for ONC and Health IT Developers Related to an ONC Inquiry Into Certified Health IT Non-Conformities and ONC Direct Review (3) Costs for Health IT Developers and ONC Associated With the Appeal Process Following a Suspension/Termination of a Complete EHR's or Health IT Module's Certification (4) Costs for Health Care Providers to Transition to Another Certified Health IT Product When the Certification of a Complete EHR or Health IT Module That They Currently Use Is Terminated (5) Costs for ONC-ATLs and ONC Associated With ONC-ATL Accreditation, Application, Renewal, and Reporting Requirements (6) Costs for ONC-ATLs and ONC Related to Revoking ONC-ATL Status (7) Costs for ONC-ACBs To Submit Identifiable Surveillance Results to the CHPL (8) Total Annual Cost Estimate b. Benefits c. Accounting Statement and Table 2. Regulatory Flexibility Act 3. Executive Order 13132--Federalism 4. Unfunded Mandates Reform Act of 1995 Regulation Text I. Executive Summary A. Purpose of Regulatory Action The ONC Health IT Certification Program (``Program'') was first established as the Temporary Certification Program in a final rule published on June 24, 2010 (``Temporary Certification Program final rule'' (75 FR 36158)). It was later transitioned to the Permanent Certification Program in a final rule published on January 7, 2011 (``Permanent Certification Program final rule'' (76 FR 1262)). Since that time, we have updated the Program and made modifications to the Program through subsequent rules as discussed below. In November 2011, a final rule established a process for ONC to address [[Page 72405]] instances where the ONC-Approved Accreditor (ONC-AA) has engaged in improper conduct or has failed to perform its responsibilities under the Program (76 FR 72636). In September 2012, a final rule (``2014 Edition final rule'' (77 FR 54163)) established an edition of certification criteria and modified the Program to, among other things, provide clear implementation direction to ONC-Authorized Certification Bodies (ONC-ACBs) for certifying Health IT Modules to new certification criteria. On September 11, 2014, a final rule provided certification flexibility through the adoption of new certification criteria and further improvements to the Program (``2014 Edition Release 2 final rule'' (79 FR 54430)). On October 16, 2015, the Department of Health and Human Services (HHS) published a final rule that identified how health IT certification can support the establishment of an interoperable nationwide health information infrastructure through the certification and adoption of new and updated vocabulary and content standards for the structured recording and exchange of health information (``2015 Edition final rule'' (80 FR 62602)). The 2015 Edition final rule modified the Program to make it open and accessible to more types of health IT, and health IT that supports various care and practice settings. It also included enhanced surveillance, disclosure, and other requirements. These requirements were designed to support the reliability of health IT certified under the Program and increase the transparency of information about such health IT (referred to as ``certified health IT'' throughout this final rule). With each Program modification and rule, we continue to address stakeholder concerns, provide additional guidance, and improve oversight. In keeping with this approach, in the ``ONC Health IT Certification Program: Enhanced Oversight and Accountability'' proposed rule (81 FR 11056) (``Proposed Rule'') we put forth several new proposals for comment, based on feedback from stakeholders and our own experience administering the Program. Importantly, we explained that the adoption and use of certified health IT has increased significantly since the Program was established, and that this trend will continue, including for settings and use cases beyond the Medicare and Medicaid EHR Incentive Programs (``EHR Incentive Programs''). As certified health IT becomes more integral to the delivery of care, and as certified capabilities increasingly interact with other capabilities in certified health IT and with other products, we seek to strengthen oversight of the performance of certified health IT capabilities and ensure that concerns within the scope of the Program continue to be appropriately addressed. We explained in the Proposed Rule that we had delegated authority to ONC-ACBs to issue certifications for health IT on our behalf through the Permanent Certification Program final rule (81 FR 11057). In addition to issuing and administering certifications, ONC-ACBs are responsible for conducting ongoing surveillance to assess whether certified health IT continues to conform to the requirements of the Program. An ONC-ACB's surveillance encompasses conformity assessments based on adopted certification criteria as well as certain other regulatory requirements (e.g., Sec. Sec. 170.523(k) and (l)). However, under this approach, which is consistent with customary certification programs and International Organization for Standardization/ International Electrotechnical Commission 17065:2012 (ISO/IEC 17065),\1\ ONC-ACBs do not have the responsibility to address the full range of requirements applicable to health IT certified under the Program. For example, an ONC-ACB's conformity assessment may not encompass certain interactions among certified capabilities and other capabilities or products that are not certified under the Program. Similarly, an ONC-ACB's assessment of certified capabilities may be limited to certain functional outcomes and may not encompass the combined or overall performance of certified health IT in accordance with Program requirements. Separately, in some instances an ONC-ACB may be responsible for administering Program requirements but may be unable to do so effectively due to practical challenges. In contrast, ONC is well-positioned to review certified health IT against the full range of requirements under the Program. Therefore, to enhance Program oversight and the reliability and safety of certified health IT, we have finalized provisions of the Proposed Rule that set forth a regulatory framework for ONC to directly review certified health IT and take appropriate responsive actions to address potential non-conformities and non-conformities. --------------------------------------------------------------------------- \1\ The international standard to which ONC-ACBs are accredited (see also 45 CFR 170.599(b)(3)). --------------------------------------------------------------------------- The direct review processes included in this final rule will enhance the National Coordinator's ability to discharge his or her responsibilities under the Health Information Technology for Economic and Clinical Health (HITECH) Act. 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 exchange. Section 3001(b) of the PHSA requires that the National Coordinator for Health Information Technology (National Coordinator) perform specified statutory duties, including keeping or recognizing a program or programs for the voluntary certification of health information technology (section 3001(c)(5) of the PHSA), in a manner consistent with the development of a nationwide health information technology infrastructure that allows for the electronic use and exchange of information and that: (1) Ensures that each patient's health information is secure and protected, in accordance with applicable law; (2) improves health care quality, reduces medical errors, reduces health disparities, and advances the delivery of patient-centered medical care; (3) reduces health care costs resulting from inefficiency, medical errors, inappropriate care, duplicative care, and incomplete information; (4) provides appropriate information to help guide medical decisions at the time and place of care; (5) ensures the inclusion of meaningful public input in such development of such infrastructure; (6) improves the coordination of care and information among hospitals, laboratories, physician offices, and other entities through an effective infrastructure for the secure and authorized exchange of health care information; (7) improves public health activities and facilitates the early identification and rapid response to public health threats and emergencies, including bioterror events and infectious disease outbreaks; (8) facilitates health and clinical research and health care quality; (9) promotes early detection, prevention, and management of chronic diseases; (10) promotes a more effective marketplace, greater competition, greater systems analysis, increased consumer choice, and improved outcomes in health care services; and (11) improves efforts to reduce health disparities. Consistent with these statutory requirements, this final rule establishes a regulatory framework for ONC's direct review of health IT certified under the Program. This final rule also sets forth processes for ONC to timely and directly [[Page 72406]] address testing issues. These processes do not currently exist under the Program structure and would serve to align the testing structure with ONC's authorization and oversight of ONC-ACBs. In addition, this final rule would increase the transparency and availability of information about certified health IT through the publication of identifiable surveillance results. The publication of identifiable surveillance results will support further accountability of health IT developers to their customers and users of certified health IT. B. Summary of Major Provisions 1. ONC Direct Review of Certified Health IT This final rule provides a regulatory framework for ONC to directly review certified health IT to determine whether it conforms to the requirements of the Program. Under this framework, ONC's review of certified health IT will be independent of, and may be in addition to, ONC-ACBs' surveillance and other functions under the Program. ONC's review will focus on capabilities and aspects of health IT that are certified under the Program (referred to throughout this final rule as ``certified capabilities''), taking into consideration other relevant functionalities or products to the extent necessary to determine whether certified health IT is functioning in a manner consistent with Program requirements. While the PHSA provides authority for ONC to directly review certified health IT in a broad range of circumstances, at this time we have finalized a regulatory framework for the exercise of such review in a more limited set of circumstances. This scope of review reflects the need to focus ONC's resources in areas that, at this time, are most vital to ensuring the integrity and effectiveness of the Program. It also complements the existing oversight and enforcement responsibilities of other government departments, agencies, and offices (referred to throughout this final rule as ``agencies'' or ``agency,'' as the context requires) that encourage compliance with Program requirements and promote accountability for the reliability and performance of health IT. Specifically, this final rule establishes regulatory processes for ONC to exercise direct review of certified health IT, and take appropriate responsive actions, in two distinct sets of circumstances. First, ONC may elect to directly review certified health IT when it has reason to believe that the certified health IT may not conform to the requirements of the Program because the certified health IT is causing or contributing to serious risks to public health or safety. Addressing the full range of these suspected non-conformities is beyond the scope of an ONC-ACB's expertise and responsibilities under the Program. In contrast, ONC has the authority to address the full range of requirements under the Program and, as we explained in the Proposed Rule, can effectively respond to these issues, quickly bringing to bear needed expertise and resources and coordinating activities with federal counterparts and other relevant entities to ensure a coordinated review and response (81 FR 11061). Second, in addition to serious risks to public health or safety, ONC may elect to directly review certified health IT on the basis of other suspected non-conformities that, while within the scope of an ONC-ACB's responsibilities, present practical challenges that may prevent the ONC-ACB from effectively investigating the suspected non- conformity or providing an appropriate response. In particular, ONC may directly review certified health IT if a suspected non-conformity presents issues that may require access to certain confidential or other information that is unavailable to an ONC-ACB; may require concurrent or overlapping reviews by multiple ONC-ACBs; or may exceed the scope of an ONC-ACB's resources or expertise. We believe that ONC's review of certified health IT in these situations will help ensure the continued effective oversight and administration of the Program. In response to comments received on the Proposed Rule, we have not at this time finalized regulatory processes by which ONC would directly review certified health IT solely on the basis of circumstances distinct from public health or safety concerns or in cases where practical challenges prevent an ONC-ACB from effectively investigating the suspected non-conformity or providing an appropriate response, as discussed above (compare 81 FR 11061). For example, at this time, the processes set forth in this rule do not establish that ONC will directly review certified health IT solely on the basis of a threat to the security or protection of patients' health information in violation of applicable law (see section 3001(b)(1) of the PHSA) or the risk of increasing health care costs resulting from, for example, inefficiency or incomplete information (see section 3001(b)(3) of the PHSA). We believe that other agencies are currently in the best position to provide effective oversight and enforcement with respect to such potential exigencies. We will continue to assess the need to exercise direct review in these additional circumstances, as necessary. As mentioned above, in this final rule, we seek to align ONC's direct review of certified health IT with oversight and enforcement responsibilities of other agencies. We therefore clarify that ONC may decline to exercise review of certified health IT for any reason, including if it believes that other agencies may be better situated to respond to a suspected non-conformity. Additionally, to the extent permitted by law, ONC may coordinate and share information with other agencies, including agencies with applicable oversight or enforcement responsibilities, and may engage other persons and entities, as appropriate, to effectively respond to suspected problems or issues with certified health IT. We note that to the extent ONC engages in any efforts to identify or address non-conformities, such efforts and any resulting remediation (or the absence of such efforts or remediation) are not intended to impact the materiality of any non-conformity in a matter addressed by another agency; and nothing in this final rule is intended to supplant, delay, or in any way limit oversight or enforcement by other agencies, including any investigation, decision, legal action, or proceeding. The final rule addresses actions ONC will take and procedures it will follow in the event that ONC's direct review of certified health IT substantiates a non-conformity. ONC will require corrective action for non-conformities and, when necessary, suspend, or terminate a certification issued to a Complete EHR or Health IT Module. Health IT developers will have the opportunity to appeal determinations by ONC to suspend or terminate certifications issued to health IT under the Program. Further, to protect the integrity of the Program and users of certified health IT, we have finalized a Certification Ban on the future certification of any of a health IT developer's health IT when the certification of one or more of the health IT developer's current Complete EHRs or Health IT Modules is: (1) Terminated by ONC; (2) withdrawn by an ONC-ACB because the health IT developer requested it to be withdrawn when the health IT developer's health IT was the subject of a potential non-conformity or non-conformity as determined by ONC; (3) withdrawn by an ONC-ACB because of a non-conformity with any of the certification criteria adopted by the Secretary at subpart C of this part; or (4) withdrawn by an ONC-ACB because the [[Page 72407]] health IT developer requested it to be withdrawn when the health IT developer's health IT was the subject of surveillance for a certification criterion or criteria adopted by the Secretary at subpart C of this part, including pending surveillance (e.g., the health IT developer received notice of pending randomized surveillance). We emphasize that ONC's role in reviewing certified health IT will support greater accountability for health IT developers under the Program and provide greater confidence that health IT conforms to Program requirements when it is implemented, maintained, and used. We further emphasize that our first and foremost goal is to work with health IT developers to remedy any identified non-conformities of certified health IT in a timely manner. 2. ONC-Authorized Testing Laboratories ONC will conduct direct oversight of testing labs under the Program in order to ensure that ONC oversight can be similarly applied at all stages of the Program. Unlike the processes already established for ONC-ACBs, we had not established a similar process for testing labs. Instead, we required in the Principles of Proper Conduct (PoPC) for ONC-ACBs that ONC-ACBs only accept test results from National Voluntary Laboratory Accreditation Program (NVLAP)-accredited testing labs. This requirement for ONC-ACBs has had the effect of requiring testing labs to be accredited by NVLAP to International Organization for Standardization/International Electrotechnical Commission 17025:2005 (General requirements for the competence of testing and calibration laboratories) (ISO/IEC 17025). As a result, there has effectively been no direct ONC oversight of NVLAP-accredited testing labs like there is for ONC-ACBs. This final rule establishes means for ONC to have direct oversight of NVLAP-accredited testing labs by having them apply to become ONC- Authorized Testing Labs (ONC-ATLs). Specifically, the final rule establishes processes for authorizing, retaining, suspending, and revoking ONC-Authorized Testing Lab (ONC-ATL) status under the Program. These processes are similar to current ONC-ACB processes. The finalized changes will enable ONC to oversee and address testing and certification performance issues throughout the entire continuum of the Program in a precise and direct manner. 3. Transparency and Availability of Identifiable Surveillance Results In furtherance of our efforts to increase the transparency and availability of information related to certified health IT, we have finalized an approach that will now require ONC-ACBs to make identifiable surveillance results publicly available on the Certified Health IT Product List (CHPL) on a quarterly basis. Posting identifiable surveillance results on the CHPL provides stakeholders with a more readily available means for accessing the results. The information required to be reported for identifiable surveillance results includes information specified in the Proposed Rule and the relevant information already required to be posted on the CHPL, when appropriate, as part of a corrective action plan (CAP). The publication of identifiable surveillance results will enhance transparency and the accountability of health IT developers to their customers. The public availability of identifiable surveillance results will provide customers and users with valuable information about the continued conformity of certified health IT. While we expect that the prospect of publicly available identifiable surveillance results will motivate some health IT developers to improve their maintenance efforts, we believe that most published results will reassure customers and users of certified health IT. This is because, based on ONC-ACB surveillance results to date, certified health IT and health IT developers are maintaining conformity with certification criteria and Program requirements. The publishing of identifiable surveillance results will also provide more complete information by illuminating good performance and continued conformity; rather than only sharing non-conforming results, and when applicable, CAPs. C. Costs and Benefits Executive Orders 12866 and 13563 direct agencies to assess all costs and benefits of available regulatory alternatives and, if regulation is necessary, to select regulatory approaches that maximize net benefits (including potential economic, environmental, public health and safety effects, distributive impacts, and equity). A regulatory impact analysis (RIA) must be prepared for major rules with economically significant effects ($100 million or more in any one year). It has been determined that this final rule is an economically significant rule as the potential costs associated with this final 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 the final rule. 1. Costs We have identified and estimated the potential monetary costs of this final rule for health IT developers, ONC-ATLs, the federal government (i.e., ONC), and health care providers. We have categorized and addressed costs as follows: (1) Costs for health IT developers to correct non-conformities identified by ONC; (2) costs for ONC and health IT developers related to an ONC inquiry into certified health IT non-conformities and ONC direct review, including costs for the new ``proposed termination'' step; (3) costs for health IT developers and ONC associated with the appeal process following a suspension/ termination of a Complete EHR's or Health IT Module's certification; (4) costs for health care providers to transition to another certified health IT product when the certification of a Complete EHR or Health IT Module that they currently use is terminated; (5) costs for ONC-ATLs and ONC associated with ONC-ATL accreditation, application, renewal, and reporting requirements; (6) costs for ONC-ATLs and ONC related to revoking ONC-ATL status; and (7) costs for ONC-ACBs to publicly report (submit) identifiable surveillance results to the CHPL. We also provide an overall annual monetary cost estimate for this final rule. We note that we have rounded all estimates to the nearest dollar and all estimates are expressed in 2016 dollars. This final rule may: (1) Lead health IT developers to reassess whether their certified health IT is in conformity with Program requirements; and (2) require health IT developers to correct non- conformities found by ONC in their certified health IT. If ONC were to find a non-conformity with a certified capability under the direct review processes outlined in this final rule, then the costs to correct the non-conformity are a result of this final rule. However, due to the difficulty of projecting such instances given the underlying need to correct non-conformities, we have not been able to include these costs in our quantitative cost estimates, as discussed in greater detail in section VI.C.1.a.(1) of this final rule. We have estimated the costs for ONC and health IT developers related to an ONC inquiry into certified health IT non-conformities and ONC direct review. We estimate the cost for a health IT developer to cooperate with an ONC review and inquiry into certified health IT would, on average, range from $9,819 to $98,192. We estimate the cost for ONC to review and conduct an inquiry [[Page 72408]] into certified health IT would, on average, range from $2,455 to $147,288. We have estimated the costs for health IT developers and ONC associated with the appeal process following a suspension/termination of a Complete EHR's or Health IT Module's certification. We estimate the cost for a health IT developer to appeal a suspension or termination would, on average, range from $9,819 to $29,458. We estimate the cost for ONC to conduct an appeal would, on average, range from $24,548 to $98,192. We have estimated the costs for health care providers to transition to another certified health IT product if the certification of a Complete EHR or Health IT Module that they currently use is terminated. Specifically, we estimate the cost impact of certification termination on health care providers would range from $33,000 to $649,836,000 with a median cost of $792,000 and a mean cost of $6,270,000. We note, however, that it is very unlikely that the high end of our estimated costs would ever be realized. To date, there have been only a few terminations of certified health IT under the Program, which have only affected a small number of providers. Further, we have stated in this final rule our intent to work with health IT developers to correct non- conformities ONC finds in a developer's certified health IT under the provisions in this final rule. We provide a more detailed discussion of past certification terminations and the potential impacts of certification termination on providers in section VI.C.1.a.(4) of this final rule. We have estimated the costs for ONC-ATLs and ONC associated with ONC-ATL accreditation, application, renewal, and reporting requirements. We estimate the annualized cost for ONC-ATL accreditation, application, and the first proposed three-year authorization period to be approximately $48,832. We estimate the annualized cost for an ONC-ATL to renew its accreditation, application, and authorization during the first three-year ONC-ATL authorization period to be approximately $73,053. In addition, we estimate the total annual cost for ONC-ATLs to meet the reporting requirements of proposed Sec. 170.524(d) to be approximately $3,276. We estimate ONC's annualized cost for administering the entire application process to be approximately $992. This cost will be the same for a new applicant or ONC-ATL renewal. We would also post the names of applicants granted ONC-ATL status on our Web site. We estimate the potential cost for posting and maintaining the information on our Web site to be approximately $446 annually. We estimate an annual cost to the federal government of $743 to record and maintain updates and changes reported by ONC-ATLs. We have estimated the costs for ONC-ATLs and ONC related to revoking ONC-ATL status. We estimate the costs for an ONC-ATL to comply with ONC requests per Sec. 170.565 would, on average, range from $2,455 to $19,638. We estimate the cost for ONC would, on average, range from $4,910 to $39,277. We have estimated the costs for ONC-ACBs to submit identifiable surveillance results to the CHPL on a quarterly basis. We estimate the annual cost for each ONC-ACB to report surveillance results to the CHPL to be $1,024 and the total cost for all three ONC-ACBs to be $3,072. We estimate the overall annual cost for this final rule, based on the cost estimates outlined above, will range from $171,011 to $650,352,050 with an average annual cost of $6,597,033. For a more detailed explanation of our methodology and estimated costs, please see section VI.C.1.a of this final rule. 2. Benefits While we do not have available means to quantify the benefits of this final rule, we believe there are many qualitative benefits. This final rule's provisions for ONC direct review of certified health IT promote health IT developers' accountability for the performance, reliability, and safety of certified health IT; and facilitate the use of safer and reliable health IT by health care providers and patients. Specifically, ONC's direct review of certified health IT will facilitate ONC's assessment of non-conformities and ability to require comprehensive corrective actions for health IT developers to address non-conformities determined by ONC, including notifying affected customers. As previously stated, our first and foremost goal is to work with health IT developers to remedy any non-conformities with certified health IT in a timely manner and across all customers. If ONC ultimately suspends and/or terminates a certification issued to a Complete EHR or Health IT Module under the processes established in this final rule, such action will serve to protect the integrity of the Program, patients, and users of health IT. In sum, ONC's direct review of certified health IT supports the National Coordinator in fulfilling his or her responsibilities under the HITECH Act, instills public confidence in the Program, and protects public health and safety. This final rule's provisions will also provide other benefits. ONC's authorization and oversight of testing labs (ONC-ATLs) will promote further public confidence in testing and certification by facilitating ONC's ability to timely and directly address testing issues for health IT. The public availability of identifiable surveillance results will enhance transparency and the accountability of health IT developers to their customers. It will provide customers and users of certified health IT with valuable information about the continued conformity of certified health IT. Further, the public availability of identifiable surveillance results will likely benefit health IT developers by providing a more complete context of surveillance in the certified health IT industry by illuminating good performance and the continued conformity of certified health IT with Program requirements. Overall, we believe this final rule will improve Program conformity as well as further public confidence in certified health IT. II. Provisions of the Final Rule A. ONC's Role Under the ONC Health IT Certification Program In initially developing the Program, ONC consulted with the National Institute of Standards and Technology (NIST) and created the Program structure based on industry best practice. This structure includes the use of two separate accreditation bodies: (1) An accreditor that evaluates the competency of a health IT testing laboratory to operate a testing program in accordance with international standards; and (2) an accreditor that evaluates the competency of a health IT certification body to operate a certification program in accordance with international standards (see the Permanent Certification Program final rule). This final rule updates the structure of the Program to provide enhanced Program oversight, accountability, and transparency. The rule establishes a regulatory framework that will help facilitate ONC's direct review of certified health IT in current priority areas, including by setting forth processes for such review and describing certain actions ONC may take to enforce Program requirements in appropriate circumstances. The rule also provides for direct ONC oversight of testing laboratories. These and other related provisions of the final rule are described in detail below. [[Page 72409]] 1. Review of Certified Health IT a. Authority and Scope We proposed to adopt a regulatory framework that would help facilitate ONC's direct review of certified health IT in certain circumstances and enhance oversight and accountability in the Program (81 FR 11058). This review would be independent of, and could be in addition to, an ONC-ACB's surveillance and other functions under the Program and would complement the role of ONC-ACBs. In the Proposed Rule, we explained that under the current structure of the Program, ONC-ACBs are responsible for issuing and administering certifications for health IT on behalf of ONC (81 FR 11057). In addition, ONC-ACBs are responsible for conducting ongoing surveillance to assess whether certified health IT continues to conform to the requirements of the Program. An ONC-ACB's surveillance encompasses conformity assessments based on adopted certification criteria as well as certain other regulatory requirements (e.g., Sec. 170.523(k) and (l)). However, under this approach, which is consistent with other certification programs and ISO/IEC 17065,\2\ ONC-ACBs do not have the responsibility to address the full range of requirements applicable to health IT certified under the Program. For example, an ONC-ACB's conformity assessments may not encompass certain interactions among certified capabilities and other capabilities or products that are not certified under the Program. Similarly, an ONC-ACB's assessment of certified capabilities may address certain functional outcomes and may not encompass the combined or overall performance of certified health IT in accordance with Program requirements. Separately, in some instances an ONC-ACB may be responsible for administering Program requirements but ONC may be better suited to do so due to practical challenges.\3\ --------------------------------------------------------------------------- \2\ The international standard to which ONC-ACBs are accredited (see also 45 CFR 170.599(b)(3)). \3\ In certain circumstances, an ONC-ACB may encounter practical challenges that could prevent it from effectively investigating a suspected non-conformity or providing an appropriate response. This may occur where, for example, a suspected non-conformity presents issues that may require access to certain confidential or other information that is unavailable to an ONC-ACB; may require concurrent or overlapping reviews by multiple ONC-ACBs; or may exceed the scope of an ONC-ACB's resources or expertise. For a more detailed discussion of these circumstances, we refer readers to section II.A.1.a.(3) of this final rule and to the section II.B (``Summary of Major Provisions''). --------------------------------------------------------------------------- In the Proposed Rule, we outlined several situations in which, for these reasons, an ONC-ACB may be unable to provide oversight necessary to ensure that certified health IT meets Program requirements. We stated, for example, that ONC may be better situated to respond to certain types of non-conformities arising from interactions of certified and uncertified capabilities or from systemic, widespread, or complex issues that could quickly consume or exceed an ONC-ACB's resources or capacity (81 FR 11061). We also observed that in some instances ONC may have access to information about a putative non- conformity that is confidential and cannot be shared with an ONC-ACB (81 FR 11061). We explained that in some cases non-conformities with certified health IT may arise that pose risks to public health or safety or present other exigencies that may warrant ONC's direct review and action (81 FR 11061). Additionally, we noted that a suspected non- conformity may involve health IT or capabilities that have been certified by more than one ONC-ACB. In such a situation, we stated that ONC would be better suited to handle the review of the certified health IT as ONC-ACBs only have oversight of the health IT they certify, while ONC could ensure a more coordinated review and consistent determination. We explained that ONC is well-placed to effectively respond to these potential issues because of its broad authority to administer the full range of requirements under the Program, its ability to quickly marshal and deploy resources and specialized expertise, and its ability to provide a coordinated review and response that may involve other agencies. Therefore, to support ONC's oversight in these areas, we proposed to establish a framework and processes in rulemaking under which ONC may exercise its discretion to directly review certified health IT and take appropriate responsive action. In the Proposed Rule, we stated that ONC's review of certified health IT could be based on any applicable Program requirements and as such would not be limited to requirements that ONC-ACBs are responsible for enforcing. We proposed that, while ONC would have broad discretion, it would consider the following factors in determining whether to initiate direct review of certified health IT:The potential nature, severity, and extent of the suspected non-conformity or non-conformities, including the likelihood of systemic or widespread issues and impact. The potential risk to public health or safety or other exigent circumstances. The need for an immediate and coordinated governmental response. Whether investigating, evaluating, or addressing the suspected non-conformity would require access to confidential or other information that is unavailable to an ONC-ACB; would present issues outside the scope of an ONC-ACB's accreditation; would exceed the resources or capacity of an ONC-ACB; or would involve novel or complex interpretations or application of certification criteria or other requirements. The potential for inconsistent application of certification requirements in the absence of direct review. (see 81 FR 11061). We anticipated that ONC's direct review of certified health IT would be relatively infrequent and would focus on situations that pose a risk to public health or safety as well as other situations that present unique challenges or issues that ONC-ACBs may be unable to effectively address without ONC's assistance or intervention (based on consideration of the factors listed above). We stressed that our first and foremost desire would be to work with developers to address any non-conformities identified as a result of ONC's review. Comments. We received mixed comments on our proposal to establish regulatory processes that would help facilitate ONC's direct review of certified health IT. Some commenters supported the proposal, emphasizing that direct review would address potential gaps in the Program, improve the safety and performance of health IT, and improve the effectiveness of the Program. Other commenters supported ONC's direct review of certified health IT, but within a narrower or more defined scope. A significant number of commenters were opposed to the proposal or voiced strong concerns. Many of these commenters were opposed to ONC's reviewing the interaction of certified capabilities and uncertified capabilities. Commenters also stated that our proposal would create uncertainty by providing ONC with discretion to review certified health IT in a broad range of circumstances, without clear and predictable rules for assessing conformity to Program requirements. Commenters expressed fear that this broad discretion could lead to inconsistent or arbitrary application of requirements, create uncertainty for developers and other stakeholders, and impede progress and innovation in health IT. Some commenters also contested the authority for ONC to directly review certified health IT in the manner proposed. Response. We thank commenters for their detailed feedback on this proposal. [[Page 72410]] We have finalized the proposal subject to the changes and clarifications summarized here for the convenience of the reader and described in more detail in our responses to the specific comments that follow. The policy and approach we have finalized respond to emerging challenges identified by stakeholders, through consultation with NIST, and as a result of our experience administering the Program. In the more than six years since the Program was established, certified health IT has become widely adopted and is now integral to the delivery of patient care. At the same time, in response to growing market and regulatory demands for the exchange and use of electronic health information, the capabilities of certified health IT have become more varied, more advanced, and more interdependent with other health IT products and capabilities. These developments are encouraging and signal progress towards a more connected health system that can help transform health and care; yet for that to occur, the public must trust and have confidence in the nation's health IT infrastructure. To effectively respond to these challenges, and for the National Coordinator to continue to meet his or her responsibilities under section 3001 of the PHSA, we are adopting a regulatory framework in this final rule to enhance the Program. As noted in the Proposed Rule, there are several areas in which ONC-ACBs may lack the responsibility, expertise, or resources to provide effective oversight of certified health IT. Importantly, certain kinds of non-conformities may be difficult to substantiate through technical conformity assessments of the kind ONC-ACBs are currently responsible for administering under the Program. In addition, practical challenges may arise for ONC-ACBs when non-conformities span multiple health IT products whose certifications are administered by more than one ONC-ACB; or where a failure of certified capabilities to perform in an acceptable manner occurs only in the context of the capabilities' interaction with other capabilities or products that are not certified under the Program. For example, some non-conformities may be so systemic, complex, or widespread that to isolate or effectively address them would quickly exceed an ONC-ACB's resources or expertise. In some cases, an ONC-ACB may be unaware of a non-conformity or may be unable to obtain the information necessary to effectively investigate and respond to a suspected non-conformity, such as when doing so would require access to certain confidential information that may be known to ONC but cannot be disclosed to the ONC-ACB. These reasons support the need for ONC to directly administer Program requirements in appropriate circumstances. Further, the need is all the more compelling when one considers that certified capabilities may be impaired by failures or deficiencies that are not only beyond the reach of ONC-ACBs, but could cause or contribute to serious risks to public health or safety or lead to other outcomes that could significantly undermine public confidence in the health IT infrastructure, the successful development of which is the overriding purpose of the Program itself and of the duties of the National Coordinator under section 3001(c) of the PHSA. For all of these reasons, we have finalized a regulatory framework that will facilitate ONC's direct review of certified health IT to determine whether it conforms to the requirements of the Program. In doing so, however, we have carefully considered and, where appropriate, accommodated concerns raised by commenters. In particular, while the PHSA provides authority for ONC to directly review certified health IT in a broad range of circumstances, the direct review processes finalized in this rule apply to a more limited set of circumstances in which ONC intends to focus its oversight at this time. This approach will concentrate ONC's resources in areas that at this time are most vital to ensuring the integrity and effectiveness of the Program. In addition, it will complement the existing oversight and enforcement responsibilities of other agencies, provide guidelines that will encourage compliance with Program requirements, and provide accountability for the performance and reliability of health IT. Specifically, this final rule establishes regulatory processes for ONC to exercise direct review of certified health IT, and take appropriate responsive actions, in two distinct sets of circumstances. First, ONC may elect to directly review certified health IT when it has reason to believe that the certified health IT may not conform to the requirements of the Program because the certified health IT is causing or contributing to conditions that pose a serious risk to public health or safety. Addressing the full range of these suspected non-conformities is beyond the scope of an ONC-ACB's expertise and responsibilities under the Program. In contrast, ONC has the authority to address the full range of requirements under the Program and, as we explained in the Proposed Rule, can effectively respond to these issues, quickly bringing to bear needed expertise and resources and coordinating activities with federal counterparts and other relevant entities to ensure a coordinated review and response (81 FR 11061). Second, in addition to serious risks to public health or safety, ONC may elect to directly review certified health IT on the basis of other suspected non-conformities that, while they are within the scope of an ONC-ACB's responsibilities, present practical challenges that may prevent the ONC-ACB from effectively investigating the suspected non- conformity or providing an appropriate response. In particular, ONC may directly review certified health IT if a suspected non-conformity presents issues that may require access to certain confidential or other information that is unavailable to an ONC-ACB; may require concurrent or overlapping reviews by multiple ONC-ACBs; or may exceed the scope of an ONC-ACB's resources or expertise. We believe that ONC's review of certified health IT in these circumstances is integral to ensuring the effective oversight and administration of the Program. In response to comments received on the Proposed Rule, we have not at this time finalized a regulatory framework under which ONC would directly review certified health IT in circumstances other than those that raise public health or safety concerns, or those in which practical challenges prevent an ONC-ACB from effectively investigating a suspected non-conformity or providing an appropriate response, as discussed above (compare 81 FR 11061). For example, at this time, the regulatory framework set forth in this rule does not provide that ONC will directly review certified health IT solely on the basis of a threat to the security or protection of patients' health information in violation of applicable law (see section 3001(b)(1) of the PHSA) or the risk of increasing health care costs resulting from, for example, inefficiency or incomplete information (see section 3001(b)(3) of the PHSA). We believe that other agencies are currently in the best position to provide effective oversight and enforcement with respect to such potential exigencies. We will continue to assess the need to exercise direct review in these additional circumstances, as necessary. Finally, in response to commenters' requests for additional clarity on certain provisions of the Proposed Rule, this final rule explains three key principles ONC will apply when deciding whether to initiate direct review of certified health IT and in determining whether [[Page 72411]] certified health IT conforms to the requirements of the Program. First, ONC's direct review of certified health IT--and any subsequent determination of non-conformity by ONC--would be based on a reasonable belief that health IT may be or is in violation of Program requirements. Contrary to the assertions of some commenters, these requirements have been clearly and consistently communicated to developers and do not impose new obligations under the Program. Indeed, in the 2015 Edition final rule, we explained that to comply with applicable certification criteria, developers must not only demonstrate required capabilities in a controlled testing environment but must also make those capabilities available in ways that enable them to be implemented and used in production environments for their intended purposes (80 FR 62711). That includes making certified capabilities available in a manner that does not cause or contribute to serious risks to public health or safety or to other outcomes that are inconsistent with the National Coordinator's responsibilities under section 3001(b) of the PHSA. Second, while several commenters objected to our proposal to review uncertified capabilities, we believe that many of these commenters misunderstood the scope of what was proposed. We proposed and have finalized regulatory processes for ONC to review capabilities and aspects of health IT that are certified under the Program. Our consideration of uncertified capabilities would be ancillary to our review of certified capabilities and would be limited to the extent necessary to determine whether certified capabilities are functioning in a manner consistent with Program requirements. Last, as we have previously explained in the context of an ONC- ACB's surveillance of certified health IT, a developer of certified health IT cannot be held responsible under the Program for putative non-conformities that are not reasonably within its ability to influence or control. This limiting principle applies with equal force to ONC's direct review of certified health IT under the Program. The foregoing principles are consistent with those that have previously been established under the Program and ensure that ONC's review of certified health IT is consistent, follows clear and predictable guidelines, and is limited to issues that are within the scope of the Program. These principles and other aspects of ONC's direct review under this final rule are explained in greater detail in the responses to specific comments below. We also have included numerous examples to assist readers in understanding these concepts and the manner in which ONC would apply them in various circumstances. (1) Requirements of the Program Comments. Some commenters, primarily health IT developers, posited that ONC may lack the requisite authority to directly review or enforce Program requirements, or to do so in the manner proposed. Several of these commenters criticized our invocation of section 3001(b) of the PHSA, which expressly enumerates the core principles and requirements inherent to the purpose of ONC. Some commenters suggested that the provisions of section 3001(b) are general and aspirational and that Congress did not intend for them to have any operative effect. Alternatively, some commenters supposed that these provisions operate ``in the aggregate'' or on the performance of ONC's functions on the whole but are not relevant to the National Coordinator's responsibility to oversee the Program or to perform other specific duties enumerated in section 3001(c). In support of this view, commenters asserted that other sections of the PHSA speak directly to the scope of the Program and the rules by which it should operate. In particular, section 3001(c)(5)(A) directs the National Coordinator to keep or recognize a program or programs for the voluntary certification of health IT as being in compliance with applicable certification criteria; and sections 3002 through 3004 establish the HIT Policy Committee (HITPC) and HIT Standards Committee (HITSC) and a consultative process for developing, endorsing, and adopting standards, implementation specifications, and certification criteria for inclusion in the Program. According to some of these commenters, this statutory design precludes ONC from enforcing requirements under the Program unless those requirements are expressed in certification criteria adopted through the processes noted above. In contrast to these comments, several commenters recognized ONC's authority to directly review certified health IT in the manner proposed. Multiple commenters explicitly recognized ONC's broad authority to establish certification programs and to directly review certified health IT against a wide range of requirements. One commenter stated that our proposal was an appropriate exercise of this authority because it did not take a broad brush approach and limited oversight to areas where there is a potential risk to health or safety or a gap in oversight that could result in harm. Response. We agree that ONC's role under the Program must comport with the National Coordinator's statutory authority under the HITECH Act. As we stated in the Proposed Rule, direct review helps enable the National Coordinator to fulfill the statutory duties specified in section 3001(b) and (c)(5) of the PHSA as they relate to keeping a certification program for the voluntary certification of health IT that allows for the electronic use and exchange of information consistent with ONC's purposes. This includes ensuring that each patient's health information is secure and protected, in accordance with applicable law; improving health care quality; reducing medical errors; reducing health care costs resulting from inefficiency, medical errors, inappropriate care, duplicative care, and incomplete information; and promoting a more effective marketplace, greater competition, greater systems analysis, increased consumer choice, and improved outcomes in health care services (see section 3001(b) of the PHSA). We respectfully disagree with the interpretation advanced by some commenters that the National Coordinator is not bound to observe these statutory dictates in the administration and oversight of the Program. By its plain language, section 3001(b) is an express mandate to the National Coordinator to perform the duties delegated to him or her in a manner consistent with the core principles and requirements enumerated in that section. It is true that some of the core principles and requirements in section 3001(b) are more relevant to the performance of some of the National Coordinator's duties than others, and that not every one of them is relevant to the performance of all of the National Coordinator's duties at all times or in the same way. It is also true that many of the core principles are stated broadly and permit substantial latitude in determining how corresponding requirements are to be met. But neither of these observations indicates that section 3001(b) was intended to be inoperative, as some commenters have suggested. To the contrary, section 3001(b) is a logical and expedient way to give effect to the purpose of ONC, by enumerating the core principles and requirements that in turn provide the basic parameters by which the National Coordinator must perform his or her duties and functions. [[Page 72412]] Even were that premise open to question, there is another reason to doubt that Congress would have intended the National Coordinator to administer and oversee the Program in a manner divorced from section 3001(b) of the PHSA. The purpose of ONC and the core principles and requirements expressed in section 3001(b), and the language and structure of the HITECH Act as a whole, leave no doubt that Congress intended a critical role for health IT and the use and exchange of electronic health information in improving health, transforming care, and enabling new frontiers in research and scientific discovery. To achieve these ends, Congress, through the HITECH Act, established the EHR Incentive Programs to encourage the meaningful use of EHR technology certified by ONC. As commenters point out, Congress also specified formal processes and an advisory committee apparatus to assist the National Coordinator in endorsing and adopting certification criteria for use in the Program. Having placed the Program and the certification of health IT at the center of this plan for developing and advancing the goals of a nationwide health IT infrastructure, Congress would have expected the National Coordinator to ensure that the Program furthers those goals and does not permit certified health IT to perform in ways that subvert them. Finally, we reject the assertion that ONC is precluded from enforcing requirements of the Program other than those expressed in certification criteria adopted under section 3004 of the PHSA. As we explained most recently in the 2015 Edition final rule, the established requirements of the Program are not limited to compliance with certification criteria (80 FR 62710). For example, developers must disclose known material information about limitations and additional types of costs associated with their certified health IT (Sec. 170.523(k)(1)); comply with rules governing the use of the ONC Certification and Design Mark (Sec. 170.523(l)); submit user complaints to ONC-ACBs (Sec. 170.523(n)); make certified capabilities available in ways that enable them to be implemented and used in production environments for their intended purposes (80 FR 62710); cooperate with an ONC-ACB's surveillance of their certified health IT (80 FR 62716); and cooperate with and not seek to prevent or discourage an ONC-ACB from reporting the results of its surveillance activities (80 FR 62718). We have also explained that certification under the Program is conditioned on a health IT developer's compliance with certain Program requirements--independent of any particular certification criteria--that are necessary to the basic integrity and effectiveness of the Program (80 FR 62710, n.170). We discuss these requirements and their regulatory history immediately below in response to requests from commenters for additional clarification of the Program's requirements. The foregoing considerations and our experience implementing the statutory provisions at issue leave no question that the National Coordinator has a duty to ensure that the certification of health IT under the Program furthers and does not subvert the core principles and requirements directly applicable to the National Coordinator's duties as enumerated in section 3001(b) of the PHSA. At a minimum, that includes updating the Program as necessary to provide effective oversight over problems or deficiencies with certified health IT that could lead to risks to public health or safety or to other outcomes that are inconsistent with the National Coordinator's responsibilities. We believe that the regulatory approach to direct review set forth in this rule is integral to fulfilling that duty. Comments. Many commenters stated that there is a need for greater clarity and consistency concerning the requirements to which developers will be held under the Program. Several commenters asked us to define the requirements of the Program more explicitly, including by providing a clear definition of non-conformity. Commenters noted that unpublished or generalized Program requirements could be a source of confusion for developers or of capricious application by ONC. This could have unintended consequences such as discouraging investment and innovation in health IT because developers and investors may be reluctant to pursue innovative technologies if regulatory requirements are unclear. Response. We agree that it is important to clearly communicate the requirements of the Program so that developers can design and make their certified health IT available in a manner that consistently meets Program requirements and the expectations of purchasers and users of certified health IT. In response to the comments, we explain in greater detail the sources of those requirements and the principles that ONC and ONC-ACBs apply when assessing whether they have been met. In the 2015 Edition Final Rule, we explained that a non-conformity arises when certified health IT fails to conform to the requirements of its certification under the Program (80 FR 62710). Those requirements take various forms and may apply to aspects of the design and performance of the health IT, the ability of the health IT to support required capabilities and uses, and the responsibility of developers to make certified capabilities available in ways that enable them to be implemented and used in production environments for their intended purposes (80 FR 62710). The certification criteria adopted under section 3004 of the PHSA form the core of the Program. In the 2010 interim final rule entitled Health Information Technology: Initial Set of Standards, Implementation Specifications, and Certification Criteria for Electronic Health Record Technology (75 FR 2013) (``Interim Final Rule''), we defined certification criteria as criteria to establish that health IT meets applicable standards and implementation specifications adopted by the Secretary or that are used to test and certify that health IT includes required capabilities (75 FR 2021-22; see also Sec. 170.102). To meet these certification criteria, health IT must be able to perform required specifications and capabilities and, more generally, to do so in an accurate and reliable manner. For example, health IT certified to Sec. 170.315(a)(1) (Computerized provider order entry--medications) must ``[e]nable a user to record, change, and access medication orders.'' Satisfying this criterion also plainly requires that the health IT perform this function accurately and reliably. For example, when a user enters a medication order for a patient, the health IT must accurately record the medication ordered and associate it with the patient selected by the user. Similarly, when a user accesses a list of medication orders for a particular patient, the health IT must not display medication orders for a different patient. While certification criteria define the required capabilities of certified health IT, ensuring that health IT can perform certified capabilities is not the only requirement of the Program. In the 2015 Edition final rule, we adopted Program requirements under which developers must disclose on an ongoing basis any known material information about limitations and additional types of costs associated with any certified capabilities of their health IT (80 FR 62720). We have also adopted other Program requirements such as those related to the use of the ONC Certification and Design Mark and the submission of complaints to ONC-ACBs (Sec. 170.523(l) and (n), respectively). Developers must also submit [[Page 72413]] information that is required to be included on the CHPL (80 FR 62725). Finally, in previous rulemakings we have highlighted that there are certain overarching requirements of the Program, in addition to those described above, that are necessary to ensuring its basic integrity and effectiveness (see, e.g., 80 FR 62710 n.170), thereby ensuring that the National Coordinator can meet his or her responsibilities under section 3001(b) of the PHSA. These requirements are part of the bases on which other requirements of the Program are understood and assessed. A prime example is the duty of developers who participate in the Program to cooperate with the surveillance of their certified health IT. The Permanent Certification Program final rule incorporated requirements for ONC-ACBs to conduct surveillance to ensure that certified health IT continues to conform to the requirements of certification when it is implemented ``in the field'' (76 FR 1282). More recently, in the 2015 Edition final rule, we expanded these surveillance requirements and also stated our expectations for the performance of certified health IT in production environments. We explained that health IT developers have a responsibility to make their certified capabilities available to purchasers and users in a manner that allows them to be used for their intended purposes, including any uses reasonably within the scope of the health IT's certification (80 FR 62710). We stated that health IT would no longer conform to the requirements of its certification if customers or users were restricted from successfully implementing and using the technology for any purpose contemplated by the certification criteria to which the technology was certified (80 FR 62711). As an illustration, we said that a developer's failure to supply training materials and instructions necessary to access and successfully use data export capabilities described by Sec. 170.315(b)(6) would constitute a non-conformity (80 FR 62711). Similarly, technical or other limitations that substantially interfere with the ability to access or use certified capabilities (or any aspect or intended uses of such capabilities) would give rise to a non- conformity (80 FR 62711). Further, even in the absence of any actual impairment, if a developer's actions would be likely to substantially impair the ability of one or more users (or prospective users) to implement or use certified capabilities for any purpose within the scope of applicable certification criteria, the technology would no longer conform to the requirements of its certification (80 FR 62711). Thus, we explained that the failure to disclose known material information about limitations or types of costs associated with certified health IT not only violates the express disclosure requirements at Sec. 170.523(k)(1), but also constitutes a non- conformity to the certification criteria associated with the potentially affected capabilities (80 FR 62711). Consistent with these established principles under the Program, certified health IT must be designed and made available to users in ways that allow certified capabilities to be used in an accurate and reliable manner, including in a manner that does not cause or contribute to serious risks to public health or safety or to other outcomes that are inconsistent with the National Coordinator's responsibilities under section 3001(b) of the PHSA. This requirement applies to the use of certified capabilities individually and in combination with other certified and uncertified capabilities of health IT. Just as the failure to disclose known material limitations or types of costs may impair the use of certified capabilities, the failure to design and make certified capabilities available so that they perform in an accurate and reliable manner impairs the safe and effective use of certified capabilities and is a non-conformity under the Program. It is important to note that the foregoing examples and analysis assume that the putative non-conformity is a result of the actions of the developer or factors that are reasonably within the developer's ability to influence or control. As we have explained on prior occasions, a non-conformity does not arise when certified health IT fails to perform in an acceptable manner but where the failure is the result of factors that are far removed from the control or responsibility of the developer (80 FR 62710). These principles are further elaborated and applied in the responses to specific comments throughout the remainder of this section (II.A.1.a) of the final rule. We have also included numerous examples to assist readers in understanding these principles and how ONC would apply them in particular circumstances. Comments. Many commenters believed that ONC should review certified health IT against specific standards, implementation specifications, certification criteria, or other express requirements, preferably developed through formal rulemaking; otherwise, developers would have insufficient guidance to design and implement their products in a manner that complies with Program requirements, and any determinations made by ONC could be ad hoc and have the potential to be unfairly applied. For these reasons, several commenters urged us to initiate separate rulemaking to identify and adopt new certification criteria that would prescribe specific requirements that ONC would apply when reviewing certified health IT and determining whether it conforms to Program requirements. Response. These comments raise many of the same concerns expressed in comments on the 2015 Edition proposed rule regarding then-proposed requirements for ONC-ACBs to conduct in-the-field surveillance of certified health IT. As we explained in finalizing those requirements, we understand the desire for bright-line rules; yet experience suggests that the fast-paced nature of technological change in the health IT landscape makes it impracticable to anticipate and prescribe detailed rules for every conceivable situation in which health IT may not conform to Program requirements (see 80 FR 62709). In practice, certified health IT may be integrated with a wide range of other systems, processes, and workflows and may be customized and used in many different ways. These circumstances, which are inherent to the production environment, are too numerous and varied to anticipate or to reduce to simple rules of universal application. For the same reasons, we do not believe that adopting certification criteria would provide the clarity or certainty sought by advocates of that approach. We believe that clarity and predictability are best achieved by articulating and explaining the basic principles that govern our review of certified health IT, as we have done in our previous response above and in the examples and discussion of potential non-conformities throughout this section of the preamble. These principles are consistent with those that govern an ONC-ACB's surveillance of certified health IT in the field (80 FR 62709). As such, they will ensure that ONC's review of certified health IT is consistent and based on clear and predictable principles. Comments. Multiple commenters stated that a non-conformity should be defined as occurring only when certified health IT can no longer complete or repeat the certification test procedures against which it was previously tested and on the basis of which the health IT was certified. Response. We expressly rejected these arguments in the preamble to the 2015 Edition final rule (80 FR 62709). There, we explained that an ONC-ACB's [[Page 72414]] assessment of certified health IT in the field is not limited to aspects of the technology that were tested in a controlled environment. Rather, an ONC-ACB must consider the unique circumstances and context in which the certified health IT is implemented and used in order to properly assess whether it continues to perform in a manner that complies with its certification. Testing is an important part of an ONC-ACB's overall analysis of health IT under the Program. For practical reasons, however, testing focuses on particular use cases and necessarily reflects assumptions about how capabilities will be implemented and used in practice. Thus, while test results provide a preliminary indication that health IT meets the requirements of its certification and can support the capabilities required by the certification criteria to which the technology was certified, that determination is always subject to an ONC-ACB's ongoing surveillance, including the ONC-ACB's evaluation of certified capabilities in the field. Indeed, a fundamental purpose of in-the-field surveillance is to identify deficiencies that may be difficult to anticipate or that may not become apparent until after certified health IT is implemented and used in a production environment. That purpose would be entirely frustrated if an ONC-ACB's assessment of technology in the field were confined to those aspects of the technology's performance specifically delineated in test procedures. For these same reasons, we again reject the position that Program requirements should be rigidly defined by test procedures instead of more meaningful performance outcomes. In assessing putative non- conformities in the course of ONC direct review, we consider the unique circumstances and context in which the certified health IT is implemented and used in order to properly assess whether it continues to perform in a manner that complies with the Program (see, 80 FR 62709). Comments. Several commenters observed that the performance of health IT may be impacted by providers' implementation choices or other factors that the developer of the health IT may be unable to reasonably anticipate or control. One commenter explained that health IT developers do not necessarily control which third-party products their customers may deploy in conjunction with the developer's certified health IT and that it is not unusual for interface issues to arise because of updates to these unsupported products or uses. Commenters noted that developers may find it particularly difficult to anticipate and address interactions of their certified health IT with third-party products that are not certified under the Program or with capabilities or aspects of certified health IT that are not directly governed by certification criteria. Response. In the 2015 Edition final rule, we recognized there may be instances in which the failure of certified health IT to perform required capabilities in the field may be due to factors that are beyond the ability of the health IT's developer to reasonably influence or control (80 FR 62710). Because the requirements of the Program focus on the responsibilities of health IT developers and those aspects of their technology that they can reasonably influence or control, we explained that the failure of health IT to perform in an acceptable manner would not constitute a non-conformity if the failure was caused exclusively by factors far removed from the control or responsibility of the developer.\4\ We also explained that, in evaluating non- conformities in the field, ONC-ACBs are required to determine the reasons for the failure of health IT to function in an acceptable manner, taking into account the roles of the technology as well as the health IT developer, users, and other parties. If an ONC-ACB finds that the developer or its technology were a substantial cause of the failure, the ONC-ACB would conclude that the health IT does not meet the requirements of its certification. By contrast, if the ONC-ACB finds that the failure was caused exclusively by factors far removed from the control or responsibility of the developer, the ONC-ACB would regard those factors as beyond the scope of the health IT's certification and would not find a non-conformity. --------------------------------------------------------------------------- \4\ For example, in the 2015 Edition final rule we provided a hypothetical scenario in which a health IT developer's certified health IT could not demonstrate required capabilities in the field due to factors that were far removed from the developer's control or responsibility (80 FR 62710). In the scenario, a customer had instructed the developer to configure the certified health IT to use clinical decision support content from a third-party vendor with whom the developer had no sublicensing agreement. The customer agreed that it would be responsible for maintaining the necessary licenses for access to the third-party vendor's content. Despite the developer's warning, the customer failed to maintain the necessary licenses and access to the content was suspended, which prevented the certified health IT from functioning as expected. --------------------------------------------------------------------------- These same principles apply equally to ONC's review of certified health IT. If in the course of reviewing certified health IT, ONC determines that the failure of the health IT to perform in an acceptable manner is the result of factors that, because they are far removed from the control or responsibility of the developer, were not within its ability to reasonably influence or control, ONC would not conclude that the certified health IT is non-conforming. (2) Review of Uncertified Capabilities In the Proposed Rule, we proposed that ONC could review the interaction of certified capabilities of health IT with uncertified capabilities. As defined earlier in section II.A.1.a of this final rule, we use the term ``certified capabilities'' to refer to any capabilities or other aspects of health IT that are certified under the Program. In contrast, other aspects of health IT are referred to as ``uncertified capabilities'' throughout this final rule. Uncertified capabilities may be integrated with certified capabilities within a single certified health IT product (i.e., a certified Complete EHR or certified Health IT Module) or may be part of other health IT products or services that are not certified under the Program. Comments. Several commenters supported our proposal to review certified health IT in a manner that recognizes that, in practice, certified capabilities frequently interact with uncertified capabilities, whether because a developer of certified health IT includes additional capabilities in its certified health IT product or because the developer's certified health IT product is deployed with or configured to work with other health IT products that are not certified under the Program. One commenter stated that a significant limitation of the Program to date has been the lack of an effective means to evaluate how certified capabilities of health IT are performing once they are deployed in the field and interact with other capabilities or products that are not certified under the Program. In contrast, some commenters, including one health IT developer, suggested that it would be appropriate for ONC to review uncertified capabilities, but only in certain limited circumstances. One commenter recommended that such review be limited to situations in which a developer integrates uncertified ``components'' with its certified health IT in a manner that directly causes a material adverse impact on the ability of the certified health IT to function in accordance with certification requirements. Other commenters categorically opposed this aspect of our proposal. Some of these commenters assumed, however, that ONC would review and make determinations about the performance of capabilities or products [[Page 72415]] that the commenters regarded as clearly beyond the scope of the Program. Some commenters even assumed that ONC would review health IT products that are not certified under the Program at all. According to these commenters, ONC's review of uncertified capabilities or other products would be inconsistent with the voluntary nature of the Program and would be a significant overstep of ONC's authority. One commenter, for example, stated that ONC had no authority to investigate uncertified ``components'' of certified health IT or to dictate how a developer builds and modifies a product in response to market mandates. Response. It appears that many commenters interpreted this aspect of our proposal in a manner that was more far-reaching than we had either contemplated or proposed. The confusion appears to have resulted from our summary of the major provisions of the Proposed Rule, which stated that ONC's direct review ``may include certified capabilities and non-certified capabilities of the certified health IT'' and ``would extend to the interaction of certified and uncertified capabilities within the certified health IT and to the interaction of a certified health IT's capabilities with other products'' (81 FR 11058). In explaining the purpose of the Proposed Rule, we stated that as certified capabilities of health IT interact with other capabilities in certified health IT and with other products, ONC's direct review would ensure that concerns within the scope of the Program can be appropriately addressed (81 FR 11057). As this statement suggests, the purpose of direct review is to evaluate and determine whether capabilities and other aspects of health IT that are certified under the Program conform to the Program's requirements. Nevertheless, because certified capabilities are frequently integrated or deployed with uncertified capabilities, evaluating whether a certified capability under review (the ``target capability'') conforms to the requirements of the Program may require understanding how the target capability is interacting with other capabilities of health IT. Those other capabilities may be certified under the Program or they may be uncertified capabilities. In the case of an uncertified capability, the capability may be part of the same ``product'' as the target capability or it may be part of a different product, which may or may not be certified under the Program. Whatever the case, to ensure that ONC can properly evaluate whether the target capability is functioning in an acceptable manner, we proposed that ONC may have to consider the interaction of the target capability with other capabilities that affect its performance, which could include uncertified capabilities, as discussed above. We did not propose, however, that uncertified capabilities would themselves become a target of ONC's review. In this sense, our statement that ONC's ``review'' would extend to the uncertified capabilities was somewhat inexact because ONC would be concerned with only the effects of the uncertified capabilities on the target capability, not with the performance of the uncertified capabilities in isolation. In other words, ONC's consideration of uncertified capabilities would be ancillary to its review of certified capabilities and limited to the extent necessary to determine whether those certified capabilities are functioning in a manner consistent with Program requirements. As an illustration, consider a Health IT Module designed for ambulatory settings and that is certified to, among other criteria, Sec. 170.314(b)(5) (Incorporate laboratory tests and values/results). Under the process established by this final rule, ONC could initiate direct review if, for example, it had reliable information that the Health IT Module were receiving and incorporating lab results incorrectly in a manner that was causing or contributing to missed diagnoses or improper management of serious medical conditions. ONC's review of the Health IT Module would be based on the Health IT Module's certified capabilities, which include the capability to incorporate lab results according to the standard specified in Sec. 170.205(j) and, at a minimum, the version of the standard specified in Sec. 170.207(c)(2). However, it may be that the lab results are being corrupted before they are received by the certified capability. To determine whether that is the case, it may be necessary for ONC to examine the capabilities of upstream health IT systems from which the Health IT Module receives lab results. This may include examining certified capabilities or uncertified capabilities of the upstream systems to the extent that those capabilities could be causing or contributing to incorrect data being transmitted to the receiving Health IT Module. We reiterate that ONC does not intend to review the functioning of uncertified capabilities except to the extent that an uncertified capability interacts with and affects the performance of a certified capability that is under review. If ONC commenced review of certified health IT based on a reasonable belief that the certified health IT may not conform to the requirements of the Program, but subsequently determined that the problem or deficiency was related solely to the functioning of uncertified capabilities in isolation, ONC would cease its review of the certified health IT. We note that, as discussed subsequently in section II.A.1.a.(3) of this preamble, ONC may share any information obtained in connection with its review with other relevant agencies, to the extent permitted by law, including agencies with applicable federal oversight or enforcement authority. With these clarifications, we believe the concerns raised in connection with this aspect of our proposal are misplaced. Contrary to those concerns, this final rule does not establish a process for ONC to make determinations about uncertified capabilities, nor to dictate how developers design uncertified capabilities within certified health IT or other technologies. ONC's consideration of uncertified capabilities will be ancillary to ONC's review of certified capabilities and limited to aspects of uncertified capabilities that interact with certified capabilities and are relevant to evaluating the performance of those certified capabilities. Further, we reiterate our expectation that direct review will occur relatively infrequently and will focus on situations that pose a risk to public health or safety or where ONC- ACBs may be unable to respond effectively. Comments. A number of commenters raised concerns that the application of direct review to uncertified capabilities would be contrary to ONC's policy of encouraging flexibility in the way that health IT systems are configured and used. Commenters also expressed concern that direct review of uncertified capabilities could create regulatory uncertainty and would diminish innovation. Noting that developers regard the uncertified aspects of their health IT as a key area of differentiation from their competitors, commenters expressed fear that direct review of uncertified capabilities would crowd out innovation in this important area and diminish overall incentives to innovate and improve health IT capabilities. Response. We are sensitive to the competition and innovation concerns raised by commenters. We believe that those concerns can be effectively addressed by clearly communicating the scope of ONC's direct review under this final rule and the limited extent to which it will impact developers of uncertified capabilities. We have [[Page 72416]] explained the potential scope of ONC's review under the processes established by this final rule, including the extent to which ONC would consider the impact of uncertified capabilities on the performance of certified capabilities. In addition, section II.A.1.a.(3) of this preamble describes the types of circumstances in which ONC may invoke the processes for direct review set forth in this final rule. To further communicate our intent and address the concerns raised by commenters, we reiterate that the purpose of direct review is to ensure that certified health IT functions in a manner that is consistent with the requirements of the Program. In the event that ONC determines that an uncertified capability is causing a certified capability to function in a manner inconsistent with Program requirements, ONC's determination would relate to the functioning of the certified capability at issue. Even in the event that an uncertified capability is identified as the cause of, or a contributing factor toward, certified health IT functioning in a manner inconsistent with Program requirements, direct review would not dictate whether or in what manner the uncertified capability should be modified. Any corrective action to be taken by the developer in response to a determination of non-conformity by ONC would relate to bringing the certified capability or capabilities into conformity. For example, appropriate corrective action might involve the developer taking steps to ensure that the certified capability does not interact with the uncertified capability that is causing it to function in an unsafe manner. Comments. A number of commenters expressed concern that extending ONC's review to uncertified capabilities or to uncertified products would conflict with or duplicate oversight of health IT by other federal agencies. Response. We acknowledge that the investigatory and enforcement authorities of other federal agencies might apply, in certain circumstances, to the performance and functioning of certified health IT. For several reasons, however, we disagree that ONC's review will conflict with or duplicate other oversight of health IT. First, as discussed above, while ONC's review may encompass uncertified capabilities, ONC would only be concerned with aspects of the uncertified capabilities that interact with the certified capabilities that are the subject of ONC's review, and only to the extent necessary to assess whether the certified capabilities are functioning in accordance with Program requirements. This limited and ancillary consideration of uncertified capabilities would be unlikely to create any significant conflict with or duplication of any other agency's authority. Moreover, to the extent that ONC's review does uncover issues that fall within the purview of other agencies with relevant oversight or enforcement responsibilities, ONC could coordinate with and share any information or evidence it has obtained with such agencies, to the extent permitted by federal law, and, if appropriate, could pause or end its review. Second, as discussed below in section II.A.1.a.(3) of this preamble, we have narrowed the scope of direct review under this final rule based in part on the ability of other agencies to provide appropriate oversight of certain types of non-conformities that would otherwise warrant ONC's review. For example, at this time, we have not finalized in this rule processes for ONC direct review of a suspected non-conformity solely on the basis that certified health IT may be compromising the security or protection of patients' health information (see section 3001(b)(1) of the PHSA) or increasing health care costs as a result of, for example, inefficiency or incomplete information (see section 3001(b)(3) of the PHSA). Our decision not to establish regulatory processes for such oversight at this time is based in part on the recognition that other agencies have the ability to investigate and respond to these types of issues and our desire to make the most efficient use of limited federal resources. Third, far from conflicting with or duplicating the efforts of other agencies, we expect direct review to promote greater alignment in the oversight of health IT. Direct review allows ONC to coordinate with and provide expertise to other agencies, and to share any information or evidence ONC has obtained, as permitted by federal law. For example, ONC could quickly marshal and deploy resources and specialized expertise while working with federal counterparts to ensure a coordinated review and response to potential non-conformities. This approach is consistent with our inter-agency efforts to avoid regulatory duplication and promote appropriate, risk-based oversight of health IT, including efforts described in the Draft Food and Drug Administration Safety and Innovation Act (FDASIA) Health IT Report,\5\ published jointly with the Food and Drug Administration (FDA) and the Federal Communications Commission (FCC). Indeed, the need for effective coordination could be especially important in responding to serious risks to public health or safety that arise from the complex interaction of health IT products that may include certified capabilities regulated by ONC as well as uncertified capabilities that may be subject to FDA, FCC, or another agency's oversight. --------------------------------------------------------------------------- \5\ Draft FDASIA Health IT Report: Proposed Strategy and Recommendations for a Risk-Based Framework (April 2014), available at https://www.healthit.gov/sites/default/files/fdasia_healthitreport_final.pdf. --------------------------------------------------------------------------- Finally, we note that ONC may elect to not initiate direct review (or, if it has initiated direct review, to cease such review) at any time and for any reason, including if ONC believes that another agency is better situated to investigate or address a suspected non- conformity, or if ONC believes that direct review could duplicate or interfere with the oversight or enforcement activities of other agencies. ONC may also coordinate with and share any information or evidence it has obtained, through its direct review or otherwise, with other agencies, to the extent permitted by federal law. We also anticipate that ONC may coordinate with ONC-ACBs, ONC-ATLs, the ONC-AA, and other entities in appropriate circumstances and consistent with applicable federal law. (3) Scope of Review We proposed that ONC may exercise direct review of certified health IT when there is reason to believe that the certified health IT may not conform to the requirements of the Program. We explained that ONC's review could be in response to concerns that certified health IT may be leading to medical errors or other outcomes that are inconsistent with the National Coordinator's responsibilities under section 3001 of the PHSA. We also stated there could also be other exigencies, distinct from public health or safety concerns, that for similar reasons would warrant ONC's direct review and action. In addition, we proposed that ONC may directly review certified health IT in situations that present unique challenges or issues that ONC-ACBs may be unable to effectively address without ONC's assistance or intervention. We listed a variety of factors in this regard that could help inform ONC's decision whether to initiate direct review in individual cases, specifically: The potential nature, severity, and extent of the suspected non-conformity or non-conformities, including the likelihood of systemic or widespread issues and impact. [[Page 72417]] The potential risk to public health or safety or other exigent circumstances. The need for an immediate and coordinated governmental response. Whether investigating, evaluating, or addressing the suspected non-conformity would require access to confidential or other information that is unavailable to an ONC-ACB; would present issues outside the scope of an ONC-ACB's accreditation; would exceed the resources or capacity of an ONC-ACB; or would involve novel or complex interpretations or application of certification criteria or other requirements. The potential for inconsistent application of certification requirements in the absence of direct review. (see 81 FR 11061). We anticipated that ONC's direct review of certified health IT would be relatively infrequent and would focus on situations that pose a risk to public health or safety as well as other situations that present unique challenges or issues that ONC-ACBs may be unable to effectively address without ONC's assistance or intervention (based on consideration of the factors listed above). We stressed that our first and foremost desire would be to work with developers to address any non-conformities identified as a result of ONC's review. Comments. A majority of commenters agreed that ONC should directly review certified health IT that could be leading to medical errors or other risks to public health or safety. One commenter representing health care professionals noted a strong need for ONC to adjust the Program to focus on the safety, usability, and interoperability of certified health IT, citing widespread concerns among the medical community about these issues. The commenter stated that ONC could play a valuable role in ensuring that the appropriate parties are identifying, analyzing, and correcting health IT safety concerns by quickly resolving non-conformity issues. Several commenters who otherwise opposed direct review, including health IT developers, stated that it may be reasonable for ONC to review non-conformities as a ``true last resort'' when risks to patient safety are sufficiently compelling or when there is a gap or overlap in the ability of ONC-ACBs to effectively address the risk. A small number of commenters categorically opposed this aspect of our proposal and stated that whether certified health IT is leading to medical errors or other risks to public health or safety is either beyond the scope of current certification criteria, other Program requirements, or section 3001(c)(5) of the PHSA. A few commenters, including one ONC-ACB, stated that health IT-related safety risks should not be addressed through the Program because there might be other channels, such as the proposed Health IT Safety Collaborative,\6\ through which these issues could be more effectively dealt with, including by identifying health IT safety-related issues, defining appropriate best practices and criteria, and making objective assessments. Commenters also urged ONC to continue to support existing private-public initiatives that are developing a framework for the identification of health IT safety incidents to expand knowledge for all stakeholders. --------------------------------------------------------------------------- \6\ See Department of Health and Human Services, Justification of Estimates for Appropriations Committee (Office of the National Coordinator for Health Information Technology), app. IV, https://www.healthit.gov/sites/default/files/final_onc_cj_fy_2017_clean.pdf (2016) (proposing that Congress provide ONC with authority to establish a Health IT Safety Collaborative and provide adequate confidentiality protections). See also ONC, Health IT Safety Center Roadmap, http://www.healthitsafety.org/uploads/4/3/6/4/43647387/roadmap.pdf (2015) (containing task force recommendations for the development of a national Health IT Safety Center); Food and Drug Administration, Draft FDASIA Health IT Report, https://www.healthit.gov/sites/default/files/fdasia_healthitreport_final.pdf (2014) (recommending establishment of a Health IT Safety Center as a key component of a risk-based approach to health IT safety oversight and efforts to create a sustainable, integrated health IT learning system that avoids regulatory duplication and leverages and complements existing public and private sector activities to improve the safety and safe use of health IT). --------------------------------------------------------------------------- Response. We thank commenters for their feedback and suggestions on this aspect of our proposal. Based on the comments, and consistent with the focus of the Proposed Rule, we continue to believe that direct review by ONC is necessary to address potential non-conformities and non-conformities in certified health IT that may be leading to medical errors or contributing to other risks to public health or safety. As we have explained, although ONC-ACBs play an important role in the Program, addressing the full range of these suspected non-conformities is beyond the scope of their responsibilities under the Program. In addition, ONC-ACBs may as a practical matter lack the expertise and resources to effectively respond to certain types of non-conformities, such as widespread or systemic problems with certified capabilities. Other agencies may similarly be unable to effectively respond to these issues, especially when the underlying causes are unclear or involve complex interactions among multiple health IT capabilities or products. As the capabilities of certified health IT evolve and become ubiquitous in the delivery of care, the National Coordinator has a responsibility to continually update and enhance oversight of the Program so that certified health IT continues to improve, and does not compromise, patient safety. Addressing these types of issues will promote greater confidence in the safety of certified health IT and protect the integrity and effectiveness of the Program. Accordingly, Sec. 170.580(a)(2) addresses the process for ONC to directly review certified health IT when the health IT may be causing or contributing to conditions that pose a serious risk to public health or safety. We note that the policy we have finalized is consistent with the general sentiment expressed by commenters, as we understand it, that ONC should exercise direct review judiciously, focusing on risks to public health or safety that are serious and on non-conformities that cannot be effectively addressed by ONC-ACBs. As we stated in the Proposed Rule, we expect that ONC's exercise of direct review will be relatively infrequent. We discuss these considerations in detail in our responses to the comments summarized immediately below. We agree with commenters that advancing health IT safety is a shared responsibility and will require a concerted commitment by all relevant stakeholders, including through current public-private efforts and proposed initiatives such as the Health IT Safety Collaborative. We continue to strongly support these efforts and recognize the vital role they play in promoting the safety of health IT and the use of health IT to improve the safety and quality of care. We regard ONC's direct review as complementary to these efforts. We disagree with the view expressed by some commenters that concerns related to the safety of certified health IT are beyond the scope of current certification criteria, other Program requirements, or section 3001(c)(5) of the PHSA. We refer commenters to our discussion of these issues in section II.A.1.a.(1) of this preamble. Comments. We received relatively broad support for our proposal to enhance oversight of non-conformities that pose a risk to public health or safety, including through the direct review of such issues by ONC. A significant number of commenters urged us to prioritize public health and safety over other concerns by narrowing the scope of ONC's review to focus exclusively or primarily on non-conformities that pose serious risks to public health or safety. Commenters stated that this narrower focus would [[Page 72418]] allow ONC to concentrate its resources and provide more effective oversight of safety issues. Many commenters also recognized the need for and supported ONC's review of non-conformities that, for other reasons, would be difficult for ONC-ACBs to effectively address. Commenters were less supportive of applying ONC oversight of the Program to the other areas we had proposed, such as widespread non- conformities that could compromise the security or protection of patients' health information in violation of applicable law, or that could lead to inappropriate claims for reimbursement under federal health care programs. A substantial majority of commenters urged us to significantly narrow and more clearly define the types of non- conformities that ONC could potentially review. Commenters were concerned that, as proposed, ONC could conceivably review non- conformities that implicate any of a wide and diverse range of potential subjects, from security breaches, to anti-competitive practices, to conditions giving rise to health disparities. This could lead to regulatory uncertainty or arbitrary enforcement, and could discourage innovation in health IT. For many of the same reasons, commenters urged us to clarify the specific types of circumstances or situations in which ONC would be likely to initiate direct review of certified health IT. While we had proposed several factors that ONC would consider in determining whether to initiate direct review, a number of commenters stated that these factors were too numerous or open-ended to provide useful guidance to stakeholders. Several commenters urged us to provide guidelines or examples explaining when ONC would be likely to initiate direct review. One commenter explained that by clarifying our methodology we could make the direct review process fairer and more equitable and establish confidence both in the process and its outcomes. Response. We agree with commenters that the types of non- conformities ONC may review and, equally important, the types of circumstances in which ONC will take action to enforce Program requirements should be made as clear as possible and should be applied in a consistent and judicious manner. Such clarity and consistency help enable developers to design and make their certified health IT available in a manner that consistently meets Program requirements and the expectations of purchasers, licensees, and users of certified health IT. We also appreciate that uncertain or unnecessary regulation can have unintended consequences, including reducing incentives to invest in and to innovate the technologies that will make it possible to use health IT and health information to improve health and the delivery of care. In light of these and other considerations described below, we have reconsidered and revised our proposal in several key respects. Importantly, while the PHSA provides the National Coordinator the authority to directly review certified health IT in the broad range of circumstances we proposed, at this time we have finalized a regulatory framework for the exercise of such review in a more limited set of circumstances. This scope of review is consistent with our expectation stated in the Proposed Rule that direct review will be relatively infrequent and will focus primarily on issues that pose a risk to public health or safety (81 FR 11058) or that ONC-ACBs may be unable to effectively address without ONC's assistance or intervention (81 FR 11061). While we stated that there could be other exigencies in addition to risks to public health and safety that could also warrant ONC's review, we agree with commenters that the need for additional ONC oversight in these areas is less pronounced at this time. In particular, we note the active oversight in these areas by other agencies, as discussed below. In light of this existing oversight and the limited resources at ONC's disposal, we agree with commenters that it is advisable to focus ONC's resources in areas in which, at this time, additional and direct oversight by ONC is most vital to ensuring the integrity and effectiveness of the Program. We believe that focusing ONC's review in these areas will help foster alignment and coordination with other agencies and promote confidence in the performance of certified health IT and the nation's health IT infrastructure, which will in turn support innovations and investments in health IT. For all of these reasons, we have finalized processes in this rule for ONC to exercise direct review of certified health IT in two distinct sets of circumstances. First, ONC may elect to directly review certified health IT when there is reason to believe that the certified health IT may be causing or contributing to serious risks to public health or safety. In these circumstances, ONC's direct review of certified health IT may be necessary to protect the public from certified health IT that is unsafe and to ensure the basic integrity and effectiveness of the Program. As explained in section II.A.1.a.(1) of this preamble, it is a requirement of the Program that certified health IT be made available in a manner that does not cause or contribute to serious risks to public health or safety. However, responding to the full range of these suspected non- conformities is beyond the scope of an ONC-ACB's expertise and responsibilities under the Program. In contrast, ONC is well-placed to respond to these issues, through the direct review processes established by this final rule, bringing to bear needed expertise and resources and coordinating activities with federal counterparts and other relevant entities to ensure a coordinated review and response to public health and safety concerns (81 FR 11061). Second, in addition to serious risks to public health or safety, ONC may elect to directly review certified health IT on the basis of other suspected non-conformities that, while within the scope of an ONC-ACB's responsibilities, present practical challenges that may prevent the ONC-ACB from effectively investigating the suspected non- conformity or providing an appropriate response. In particular, ONC may directly review certified health IT if a suspected non-conformity presents issues that may require access to certain confidential or other information that is unavailable to an ONC-ACB; may require concurrent or overlapping reviews by multiple ONC-ACBs; or may exceed the scope of an ONC-ACB's resources or expertise. We believe that ONC's review of certified health IT in these situations will help ensure the continued effective oversight and administration of the Program. The circumstances described above do not encompass all possible non-conformities of certified health IT. For example, certified health IT may not conform to the requirements of the Program if it is causing or contributing to other outcomes--distinct from risks to public health or safety--that are inconsistent with the National Coordinator's responsibilities, such as compromising the security or protection of patients' health information in violation of applicable law (see section 3001(b)(1) of the PHSA) or increasing health care costs resulting from, for example, inefficiency or incomplete documentation (see section 3001(b)(3) of the PHSA). At this time, however, we believe that other agencies are in the best position to provide effective federal oversight and enforcement in these areas. For example, within HHS, the Office for Civil Rights' (OCR) enforces the Privacy, Security, and Breach Notification Rules promulgated under the Health Insurance Portability and [[Page 72419]] Accountability Act of 1996 (HIPAA) and amended by the HITECH Act, and the Office of Inspector General (OIG) enforces a range of federal laws related to fraud, waste, and abuse. Therefore, we have not at this time finalized regulatory processes by which ONC would directly review certified health IT solely on the basis of circumstances distinct from public health or safety concerns or in cases where practical challenges prevent an ONC-ACB from effectively investigating the suspected non- conformity or providing an appropriate response, as discussed above (compare 81 FR 11061). We will continue to assess the need to exercise direct review in these additional circumstances, as necessary As mentioned above, in this final rule, we seek to align ONC's direct review of certified health IT with oversight and enforcement responsibilities of other agencies. We therefore clarify that ONC may decline to exercise review of certified health IT for any reason, including if it believes that other agencies may be better situated to respond to a suspected non-conformity. Additionally, to the extent permitted by law, ONC may coordinate and share information with other agencies, including agencies with applicable oversight or enforcement responsibilities, and may engage other persons and entities, as appropriate, to effectively respond to suspected problems or issues with certified health IT.\7\ Such agencies could include, for example, the Centers for Medicare and Medicaid Services, the Food and Drug Administration, the HHS Office for Civil Rights, the HHS Office of Inspector General, the Department of Veterans Affairs, the Federal Communications Commission, or state Medicaid agencies. We note that to the extent ONC exercises its discretion to engage in any efforts to identify or address non-conformities, such efforts and any resulting remediation (or the absence of such efforts or remediation) are not intended to impact the materiality of any non-conformity in a matter addressed by another agency; and nothing in this final rule is intended to supplant, delay, or in any way limit oversight or enforcement by other agencies, including any investigation, decision, legal action, or proceeding. --------------------------------------------------------------------------- \7\ Example E in section II.A.1.a.(3) of this preamble illustrates the complementary roles of ONC's direct review and the activities of other agencies. --------------------------------------------------------------------------- Finally, our decision to focus ONC's review, at this time, on the types of non-conformities described above allows us to provide a more structured decision-making regulatory framework to support the exercise of ONC's discretion to initiate review of certified health IT in the circumstances we have described. In contrast to the framework set forth in the Proposed Rule, we have simplified and defined with greater specificity the factors ONC will consider in determining whether to initiate direct review of a suspected non-conformity. The updated regulatory framework, which we have finalized at Sec. 170.580(a)(2), provides a more sequential and targeted set of factors that ONC will consider when determining whether to initiate direct review. We have also eliminated duplicative or redundant factors included in the Proposed Rule, as discussed in more detail in our responses to comments on those factors below. These revisions will provide clear and predictable guidelines that will promote compliance with Program requirements while preserving incentives to develop and adopt new and innovative technologies. Comments. Several commenters suggested that ONC should focus its oversight on risks to public health or safety that are ``clear,'' ``severe,'' ``immediate,'' ``extreme,'' or otherwise compelling. A few commenters stated that ONC should not exercise direct review unless the risk to patient safety or public health poses imminent risks to public health or safety. Commenters stated that focusing on these types of risks would ensure that ONC's limited resources are used to mitigate the problems or issues with certified health IT that pose the most serious risks of harm to patients and the public. Separately, some commenters stated that exercising direct review of all potential risks could be counter-productive in that it may discourage efforts to implement and use health IT to improve patient safety and care. Relatedly, commenters requested additional specificity regarding the types of risks to public health or safety that could trigger ONC's review or give rise to a non-conformity. One commenter requested that ONC provide examples to illustrate how certified health IT might contribute to risks to patient safety and public health. Response. We agree that not every risk to public health or safety necessitates ONC's direct review. We are also cognizant of the need to prioritize ONC's limited resources by focusing on the kinds of problems and other issues that, if not addressed through ONC's direct review, are most likely to lead to harm to patients or the public and undermine confidence in health IT and the integrity of the Program. As described in section II.A.1.a.(1) of this preamble, to conform to the requirements of the Program certified health IT must be designed and made available to users in a way that allows certified capabilities to be used in an accurate and reliable manner. This includes making capabilities available in a manner that does not cause or contribute to medical errors or other conditions that give rise to serious risks to public health or safety. Direct review would be appropriate if ONC had reason to believe that certified health IT were causing or contributing to conditions that present a serious risk to public health or safety, including conditions that could result in serious injury or death, whether to a patient or to any other person. Our focus on risks to public health or safety that are ``serious'' is consistent with the Proposed Rule, in which we suggested that ONC's direct review would be appropriate in response to certified health IT causing or contributing to medical errors or other exigent circumstances that call for an immediate or coordinated governmental response (81 FR 11058; compare proposed Sec. 170.580(a)(1)(ii) through (iii) at 81 FR 11082). This focus also aligns with the general sentiment expressed by commenters that ONC's review of matters involving public health or safety should focus on risks that are ``clear,'' ``severe,'' ``immediate,'' ``extreme,'' or otherwise compelling. We note that these terms are not self-defining and that assessing whether certified health IT poses serious risks to public health or safety will necessarily involve a careful consideration of the relevant facts and circumstances in each case. To this end, ONC would consider the nature, extent, and severity of the risk and the conditions giving rise to it, in light of the information available to ONC at the time. In addition to any other factors that may be relevant, ONC would consider the apparent severity of the harm that might result, or has resulted, from the suspected unsafe conditions, including the likelihood of death or serious injury; the number of persons who may be harmed in the event that the harm were to materialize; and the likelihood that harm will in fact materialize if appropriate action is not taken. ONC would also consider the extent to which the risk of harm may be imminent such that an immediate or coordinated governmental response is necessary to significantly reduce the likelihood of actual harm occurring or recurring (Sec. 170.580(a)(2)(i)(B)). In evaluating whether the risk of harm may be imminent, ONC would also take into [[Page 72420]] account any actions being taken to mitigate the risk, to the extent that ONC is aware of those actions. We have declined to adopt commenters' suggestions that ONC should focus exclusively on the ``imminence'' of a potential risk to public health or safety when determining whether to exercise direct review. While the nature of public health or safety risks dictates that in most cases they will be imminent, we can envision scenarios in which a risk might not be strictly ``imminent'' at the time ONC determines that it will initiate its review but might nonetheless lead to serious harm if not addressed. For example, ONC might decide to exercise direct review if it became aware of information about a serious safety risk that a developer, in concert with its healthcare provider customers, is managing by way of a complex series of manual ``work-arounds'' until the scheduled release of the developer's next software update. While the developer may assert that the risk to patients is not imminent because of the existence of the manual work-arounds, it may be necessary--both to protect patients and the integrity and effectiveness of the Program--for ONC to review the safety risk at issue immediately and not have to wait until such time as the manual work-arounds fail. ONC may, as part of direct review in this instance, determine that the risk to patient safety is such that, for the health IT to remain certified, the developer must rectify the deficiency by way of a patch and not wait until the developer's next scheduled software release. Separate from information about unsafe conditions in particular, ONC could conclude that certified health IT poses a serious risk to public health or safety were it aware of information calling into question the validity of the health IT's certification. Such information might include, for example, credible allegations that a health IT developer obtained or maintained any part of the certification of its health IT by means of false or misleading statements or representations to an ONC-ACB; misrepresented or made false or misleading statements to customers or users about the certification or certified capabilities of the health IT; concealed problems, deficiencies, or potential non-conformities; or took other actions that would be likely either to compromise or to circumvent processes under the Program for testing, certifying, and conducting ongoing surveillance and review of certified health IT. These circumstances present a serious risk to public health or safety because obtaining and maintaining a valid certification is fundamental to ensuring that health IT meets Program requirements, including requirements essential to providing basic assurance that health IT is able to perform required capabilities in an accurate and reliable manner. Indeed, customers, implementers, and users rely on the certifications issued on behalf of ONC to provide this basic assurance so that they can select appropriate technologies and capabilities, identify potential implementation or performance issues, and implement certified health IT in a predictable, reliable, and successful manner (80 FR 62709). Where the validity of a certification is called into question, these and other persons are unknowingly deprived of this basic assurance upon which they rely. To further illustrate these principles and how they would be applied in practice, we offer the following contrasting examples. Example A: ONC receives multiple, detailed reports that a cloud- based EHR system (certified to the 2015 Edition) has become so slow that it may take up to five minutes to load a patient's record or to display information within a patient's record, such as the patient's medication and medication allergy lists. When providing emergency treatment, clinicians cannot wait five minutes for this information and must order medications with incomplete information about patients' current medications and medication allergies. Even when treatment is not urgent, the system's delays in responding lead many clinicians to assume that the EHR is not working and to order medications based on their best recollection of patients' current medications and allergies. Clinicians at several hospitals in multiple states are experiencing these problems. There is no indication that these hospitals are maintaining substandard hardware or network infrastructure below the recommendations from the health IT developer, nor that they have customized their health IT in a way that would adversely affect system performance. The health IT did not behave this way when it was installed, but as the clinical data and number of records has grown the speed of the EHR's responsiveness has decreased. In this example, ONC may initiate direct review of the certified health IT. The facts suggest that several capabilities of the certified health IT are implicated, including Sec. 170.315(a)(6) (Problem list) and Sec. 170.315(a)(7) (Medication list). The capabilities as implemented appear to be performing or interacting in a way that is causing or contributing to a serious risk of harm to public health or safety. The risk of harm is serious for several reasons. First, clinicians are abandoning use of the capabilities and resorting to memory to order medications for patients, which could result in severe harm to patients, including serious injury or death. Moreover, the risk is imminent because it is likely that harm will occur soon unless immediate action is taken to address the unsafe conditions. Further, the extent of the risk is large because the unsafe conditions have been reported at several hospitals in multiple states and may therefore put at risk a large number of patients. Assuming ONC were to initiate direct review, it would examine the certified capabilities to determine why they are not performing in an accurate and reliable manner and whether the cause of the problem was within the ability of the health IT developer to reasonably influence or control. The facts suggest that the problem is common across multiple customers and is not the result of any actions of the developer's customers or users. Because the problem developed over time, the developer would have been aware of the problem and could have prevented it by employing best software practices to prevent a system related slow-down under load. If this were established, ONC would find a non-conformity. Example B: ONC receives credible information from multiple sources that a large hospital's EHR system, which is certified to the 2015 Edition, is dropping medication orders. While the cause of the dropped orders is not yet clear, data in patients' records is not being recorded in a consistent and reliable manner, which is leading to patients not receiving medications. Based on the information it has received, ONC believes that the EHR system's computerized provider order entry (CPOE) capability for medications (Sec. 170.315(a)(1)) may be interacting with other capabilities within the EHR or within other health IT in a way that is causing or contributing to orders not arriving when they are needed. This poses a serious risk to public health or safety because there is an imminent risk that patients will not receive needed or even life- saving medications that have been ordered for them, which could result in severe harm. Accordingly, ONC initiates review of the certified health IT. However, during the course of its review, ONC determines that the hospital had chosen not to install and maintain the minimum specified hardware and [[Page 72421]] network requirements published by the developer of the certified health IT. As a direct result of the substandard hardware and network connectivity, the certified health IT is suffering system timeouts, losing network packets, and not operating correctly. Based on these findings, ONC finds that while the certified capability is not performing in an acceptable manner, the reason for the substandard performance is that the hospital has chosen not to follow the developer's minimum hardware and network recommendations. The hospital's decision to intentionally disregard the developer's clear instructions regarding the safe use of its technology is a factor that is beyond the ability of the developer to reasonably influence or control. Therefore, ONC would not find a non-conformity and would cease its review. ONC may, however, refer the matter (and information or evidence obtained as a result of its review) to other agencies with applicable oversight or enforcement responsibilities, as discussed above in this section of the preamble. Example C: ONC receives multiple reports from a large hospital concerning a potential problem with its EHR. Over the past week, several patients with congestive heart failure (CHF) had to be readmitted because of CHF exacerbations. Clinical and IT staff at the hospital have investigated the problem and believe that it is due to an error in the hospital's EHR, which is certified to the 2015 Edition. The hospital reports that its CHF patients are all given electronic scales that record their weight and automatically transmit the daily weight back to the hospital's EHR. The weight can be tracked and the patients can be alerted if they are gaining too much weight (from excess fluid, one of the signs of a CHF exacerbation) and need to adjust their CHF medications accordingly. The readmissions happened due to inaccurate weight data being presented to clinicians, which caused the clinicians to not adjust diuretic medication to manage patients' fluid status appropriately. Based on these facts, ONC may initiate direct review of the certified health IT. ONC could form a reasonable belief that the certified health IT may be causing or contributing to serious risks to public health or safety, in violation of Program requirements. A number of certified capabilities appear to be implicated, including Sec. 170.315(e)(3) (Patient Health Information Capture) and certified capabilities that interact with vital signs data (which is part of the Common Clinical Data Set (Sec. 170.102)). Although the cause of the problem is not yet clear, it is reasonable to believe that it may be a result of one or more of these certified capabilities or of their interaction with other uncertified capabilities or products. Meanwhile, the occurrence of multiple readmissions in the past week suggests that, if the certified health IT is causing or contributing to these risks to public health or safety, the risks are sufficiently serious as to constitute a non-conformity and to warrant ONC's review. Example D: ONC becomes aware of a patient safety hazard at a large area hospital. In one reported case, a patient with chest pain entered the emergency department (ED) of the hospital. In the ED, nurses enter protocol orders for patients with chest pain on behalf of the attending physician. On this occasion, an attending physician accessed the patient's record in the EHR and, observing that no blood tests had been ordered, proceeded to order the tests from the standard order set. Contemporaneously, a nurse was in the process of entering the same tests from the same order set. The nurse completed her order a few seconds before the physician completed hers. Neither the nurse nor physician recall any duplicate order alerts, although hospital IT staff state that clinical decision support (CDS) was active in the EHR system and had been configured to intercept and display alerts when duplicate orders are entered. The duplicate orders were noticed later when the physician was reviewing the patient's record in the EHR. At that time, the physician cancelled the nurse's order, which thereafter was no longer displayed in the EHR. The EHR continued to display the physician's order with a status of ``pending collection.'' The lab system assumed that the identical lab requests for the same patient were duplicates and cancelled the physician's request because the nurse's request had arrived first. The lab system, however, did not create an outgoing interface message to the ordering EHR indicating that the physician's ``duplicate'' request had been cancelled. As a result, the physician's order continued to be displayed in the EHR with a status of ``pending collection.'' Back in the ED, alert staff noticed that the labs had not been drawn within the expected time frame, and reordered the tests. Fortunately no harm resulted to the patient. However, the hospital's clinical staff and leadership believe the EHR presents a serious patient safety hazard. The clinicians report the incident to ONC and note that in a large and busy ED it is not uncommon for clinicians to enter contemporaneous orders; and that they expect the EHR to alert them when this occurs and to intercept duplicate orders before they are transmitted. The hospital's IT staff and the EHR developer, with whom the IT staff have been working to analyze this incident, believe that the EHR was configured to provide these CDS interventions. Neither the hospital's IT staff nor the EHR developer has been able to ascertain why these safeguards appear to have failed in this case. Based on these facts, ONC could form a reasonable belief that the certified health IT may be causing or contributing to a serious risk to public health or safety. As noted by the hospital's clinical staff and leadership, duplicate orders are not uncommon, especially in a large and busy ED. If not detected, the duplicate orders may lead to a wide range of serious hazards, such as administration of unnecessary tests or excessive medication dosages. And as illustrated by this example, the failure to detect and intercept duplicate orders may also have downstream effects that could prevent the fulfillment of orders and result in patients not receiving timely test results and treatment. The severity and extent of the harm that could occur is significant and is likely to materialize unless the cause of the problem is isolated and resolved. That the hospital's IT staff and the EHR developer are cooperating and yet have been unable to ascertain the cause of the problem is also relevant to ONC's consideration because it suggests that the problem could reoccur and that the full extent of the problem, including for other hospitals or facilities that use the developer's EHR, is not known. While the risk to public health or safety is clear, to initiate direct review, ONC must have a reasonable belief that the certified health IT may be causing or contributing to that risk. Here, there are at least two certified capabilities that are potentially implicated: CPOE (Sec. 170.315(a)(3)) and CDS (Sec. 170.315(a)(9)). This nexus to certified capabilities is sufficient for ONC to initiate direct review. Concurrently, ONC might direct the responsible ONC-ACB to perform surveillance of issues that are within the scope of its responsibilities and expertise. Here, an ONC-ACB could conduct in-the- field surveillance of the CPOE and CDS capabilities to determine whether there is a non-conformity to the requirements of Sec. 170.315(a)(3) or (a)(9). For example, the ONC-ACB would be well- positioned to determine through in-the-field surveillance whether the certified CDS capability, when properly configured to intercept and alert users to [[Page 72422]] duplicate orders, consistently triggers those interventions in a reliable manner in a production environment. On the other hand, an ONC-ACB may be unable to analyze other possible non-conformities. For example, it may be that the CDS reliably displays alerts as intended but that the alerts are designed in a way that makes them susceptible to being inadvertently overridden. These usability considerations are within the scope of the Program's requirements but may be best suited for ONC to review. ONC could also examine the interaction of the certified capabilities with the receiving lab system (which may or may not be certified under the Program), which in this example is critical to isolating and understanding the nature of the problem and assessing whether the certified health IT conforms to Program requirements. In reaching that determination, ONC would consider whether the EHR developer could have reasonably anticipated that the lab system would cancel the orders without sending a notification of the cancellation and whether it could have taken reasonable steps to mitigate this risk (such as warning users to manually confirm the orders or providing a bi-directional interface that ensures that users are able to view when orders are in fact received and filled). This may require analyzing the EHR developer's interfaces and contractual agreements with the lab system as well as the EHR developer's field testing and quality assurance procedures. Again, these factors may be beyond the expertise of the ONC-ACB and better suited for ONC's review. As the foregoing examples illustrate, the particular facts and circumstances that may trigger ONC's review of certified health IT will be unique to each case, as will be the analysis of the issues relevant to determining whether the certified health IT conforms to Program requirements. Nevertheless, we believe the examples above will help stakeholders understand the types of risks to public health or safety that may prompt ONC's review and that may lead to a finding of non- conformity. We anticipate issuing additional guidance on these and other aspects of this final rule as appropriate. Comments. A small number of commenters distinguished between risks to patient safety and those related to broader public safety or public health. Some commenters stated that direct review would not be appropriate in circumstances that pose a risk of harm to public health but not specifically to patient safety. In contrast, one commenter posited that public health considerations may justify or weigh in favor of direct review in certain situations, such as where problems with certified health IT may adversely impact socially or medically vulnerable populations. Response. We intend the term public health or safety to encompass risks to both patients and other persons. Given the central role of health IT in delivering care, it is likely that ONC's oversight will focus on risks of harm to patients. However, we would be no less concerned if certified health IT were causing or contributing to risks of harm to persons other than patients, and we believe that the National Coordinator's responsibility to provide for effective oversight of certified health IT so that it does not create unreasonable risks of harm to patient safety applies with equal force to risks involving public health. We note that under the approach we have finalized, ONC would consider the potential nature of a public health or safety risk when reaching a determination whether to initiate direct review. Thus ONC's determination would take into account the impact that the potential risk is having, or might have, on a patient(s). This determination would necessarily involve an analysis of the risk as it relates to the affected patient population. Comments. A number of commenters voiced concerns about the factors that ONC would consider when determining whether to initiate direct review, characterizing those factors as overly broad and creating a risk of arbitrary application. Commenters noted in particular that the phrase ``other exigent circumstances'' was ambiguous. Some commenters suggested that ONC's potential reliance on such an open ended factor would enable ONC to exercise direct review in an unaccountable manner. Commenters requested clarification or reconsideration of the inclusion of ``other exigent circumstances'' as a factor to be considered by ONC when initiating direct review. Response. We identified a number of factors in the Proposed Rule that ONC might consider when determining whether to exercise its discretion to initiate direct review. These factors were included to provide health IT developers with some comfort that while ONC's authority to initiate direct review is broad, ONC's use of direct review would be guided by principles that focus ONC's limited resources on the oversight of non-conformities that pose substantial risks to the integrity and effectiveness of the Program. Indeed, the inclusion in the proposal of the phrase ``other exigent circumstances'' was intended to narrow ONC's discretion rather than, as suggested by commenters, provide ONC with a degree of flexibility that would make ONC's exercise of direct review unaccountable. Notwithstanding this, we acknowledge commenters' concerns regarding the open-ended nature of the phrase ``other exigent circumstances.'' We maintain that there could be other exigencies, distinct from public health or safety concerns, that pose risks to the integrity and effectiveness of the Program and warrant ONC's direct review and action. However, at this time, our decision to focus on public health and safety risks (in addition to non- conformities over which, for practical or other reasons, ONC-ACBs may be unable to provide effective oversight) at this stage of our administration of the Program has enabled us to omit any reference in the final rule to ONC considering ``other exigent circumstances'' when determining whether to exercise direct review. We clarify that while under the processes established by this final rule ONC would not, at this time, initiate direct review solely on the basis of exigencies other than serious risks to public health or safety, and while ONC's review would focus on aspects of health IT that are certified under the Program, ONC would not be precluded from sharing, to the extent permitted by federal law, any information or evidence (including about other exigent circumstances or problems with uncertified capabilities of health IT) with other relevant agencies, including law enforcement or other agencies who may be able to address such matters. Conversely, ONC may receive information about potential non-conformities or non-conformities from other agencies in the course of their oversight, enforcement, or other activities. As an illustration, consider the following example. Example E: A Health IT Module certified to the 2015 Edition (``the EHR'') is the subject of a ``ransomware'' attack. The attacker gained unauthorized access to the EHR at multiple health care facilities and deployed malicious software that rendered patients' electronic health information completely inaccessible to clinicians and other users of the EHR. Several of these facilities have reverted to backup systems, including in some cases paper records and manual workflows that significantly increase the risks of medical errors and harm to patients. Several federal agencies (``the Agencies'') are currently investigating the attack. The Agencies request the [[Page 72423]] assistance and expertise of ONC's Chief Privacy Officer to better understand the role of the EHR in contributing to the incident. The investigation quickly reveals that the attacker exploited a vulnerability in the operating system software (OS) used in conjunction with the EHR. The OS was out of date and no longer receiving security updates. The Agencies, concerned about the prospect of additional security breaches, share this information confidentially with ONC. For the reasons stated earlier in section II.A.1.a.(3) of this preamble, ONC would not initiate direct review of the certified health IT solely on the basis of security incidents or other exigencies that are distinct from risks to public health or safety. At this time, we believe that other agencies are currently best positioned to provide effective oversight and enforcement of health IT with respect to these potential exigencies. Nevertheless, as the facts of this example make clear, these exigencies may also give rise to serious risks to public health or safety. Where certified health IT may be causing or contributing to risks of this kind, ONC may initiate direct review to protect the public and the integrity and effectiveness of the Program. Here, ONC initiates direct review based on the information received from the Agencies. To ensure that ONC's review assists and does not in any way hinder the ongoing investigation, ONC carefully coordinates with the Agencies and shares information and evidence it obtains during its review. ONC's review confirms that the developer of the EHR requires users to install and use a version of the OS that is no longer supported by the OS manufacturer and is not receiving security updates. All certified capabilities of the EHR are affected by this requirement, which exposes users to vulnerabilities and attacks that could compromise patient data and result in serious harm to patients. At the same time, ONC finds that the developer could have reasonably anticipated, and avoided, these risks because the OS manufacturer had published many notices that the version of the OS was being retired and would no longer receive security updates. Based on these findings, ONC issues a notice of non-conformity to the developer. By contrast, if ONC had found that the health IT developer offers an upgrade path to the latest versions of the operating system software, and encourages its users to upgrade, ONC would not find a non-conformity if users decided to not install the upgrade. Comments. Commenters suggested that we clarify our proposed methodology for assessing the ``nature, severity, and extent'' of a suspected non-conformity and the significance of this factor to ONC's determination whether to initiate direct review. Response. In response to the concerns raised by commenters, we have made a number of adjustments in the final rule that will create greater predictability for the process that ONC will use to determine when to initiate direct review. The proposals in the Proposed Rule outlined a direct review process in which ONC would exercise wide latitude to consider and weigh factors when determining whether to initiate direct review. As proposed, ONC might evaluate a number of factors that could be relevant to the particular circumstances at issue at the same time. However, at this time, we have chosen to narrow the scope of potential non-conformities and non-conformities ONC will review as described above. Given this narrower scope, we are able to delineate the specific factors that ONC will consider and apply when determining whether to initiate direct review of certified health IT. Under the final rule, the nature, severity, and extent of a non- conformity would be relevant if ONC were to initiate review of a suspected non-conformity on the basis of public health or safety concerns. In that instance, ONC would have a reasonable belief that certified health IT may be causing or contributing to conditions that pose a serious risk to public health or safety. The potential nature, severity, and extent of the suspected conditions giving rise to that risk would be directly relevant to this determination, as would the need for an immediate or coordinated governmental response. These considerations are described in greater detail earlier in section II.A.1.a.(3) of this preamble. We have expressly included these considerations as factors that ONC will consider when determining whether certified health IT may be causing or contributing to risks that are sufficiently serious as to suspect that the certified health IT does not conform to the requirements of the Program and ONC's direct review. Separately, and as also discussed in section II.A.1.a.(3) of this preamble, ONC may directly review certified health IT when a suspected non-conformity, while based on requirements of the Program that are generally within the scope of an ONC-ACB's responsibilities to administer and enforce, presents issues that may prevent the ONC-ACB from effectively investigating or responding. The nature, severity, and extent of a suspected non-conformity may be relevant to this determination. For example, the suspected non-conformity may be so systemic, complex, or widespread that an ONC-ACB would lack the resources or expertise to effectively investigate or respond to it. On this basis, ONC may directly review the suspected non-conformity. Comments. One commenter suggested that ONC include additional factors for assessing when to exercise its direct review. This commenter recommended that ONC develop an additional factor that ensures that ONC's decision to initiate direct review takes into account the impact of non-conformities on socially and medically vulnerable populations. Response. Under the final rule, ONC will consider the potential nature, severity, and extent of a public health or safety risk when reaching a determination as to whether to initiate direct review. This determination would take into account the potential impact the risk is having, or might have, on a patient(s) or the public. We anticipate that an analysis of the affected population could be relevant to that determination. For example, an issue might present a less serious risk of harm to patients at a large tertiary hospital with in-house IT staff and robust quality assurance processes than to patients served by a safety-net provider with no in-house IT expertise and less extensive quality controls and resources than might be available to a large institution. Comments. Many commenters expressed support for ONC direct review in situations where ONC-ACBs may be unable to effectively investigate or respond to potential non-conformities. Several commenters recognized that there may be a variety of situations in which ONC-ACBs are unable to effectively investigate and respond to non-conformities, such as where doing so would require access to confidential or other information that is unavailable to an ONC-ACB, would exceed the resources or capacity of an ONC-ACB, or would involve novel or complex interpretations or application of certification criteria or other Program requirements. One commenter recommended that ONC invest in and empower ONC-ACBs to enable them to investigate and address non- conformities that are currently beyond the scope of their responsibilities under the Program. All three ONC-ACBs commented on this aspect of our proposal. One ONC-ACB related that in its own surveillance it had encountered scenarios in which [[Page 72424]] ONC's direct oversight would have proven beneficial to the situation and its resolution. Another ONC-ACB stated that it had received complaints from users of certified health IT that raised issues (including issues related to patient safety) that were beyond the scope of the ONC-ACBs' accreditation and ability to address but that could be governed by the broader requirements of the Program. The remaining ONC- ACB did not believe that ONC should enforce any Program requirements that ONC-ACBs themselves could not administer in accordance with their accreditation; however, the ONC-ACB did support ONC's direct review of non-conformities whose nature, severity, or extent would be likely to quickly consume or exceed an ONC-ACB's resources or capacity. Some commenters suggested that ONC should only intervene due to ONC-ACB limitations in very limited circumstances and that ONC should use its discretion in this respect as a ``last resort.'' One commenter suggested that ONC refine the factors that it will consider when determining whether to initiate direct review on this basis. Another commenter suggested that ONC should only initiate direct review on the basis of ONC-ACB limitations when clearly defined criteria are met; the commenter provided the example of a non-conformity involving the interaction of two health IT products certified by separate ONC-ACBs and having a proven and urgent impact on patient safety. Response. We thank commenters for their support and thoughtful comments on this aspect of our proposal. We have adopted the proposed approach to ONC direct review when ONC-ACBs may lack necessary expertise or resources, with the following clarifications. ONC may exercise direct review on the basis of suspected non-conformities that, while generally within the scope of an ONC-ACB's responsibilities and expertise, may present issues that could prevent an ONC-ACB from effectively investigating or providing an effective response. In these circumstances, ONC's direct review of the certified health IT is appropriate to help ensure consistency in the effective oversight and administration of the Program. Specifically, under the processes established in this final rule, ONC may directly review certified health IT if investigating or responding to a suspected non-conformity may require access to confidential or other information that is unavailable to an ONC-ACB (Sec. 170.580(a)(ii)(A)); may require concurrent or overlapping reviews by multiple ONC-ACBs (Sec. 170.580(a)(ii)(B)); or may exceed the scope of an ONC-ACB's resources or expertise (Sec. 170.580(a)(ii)(C)). In response to the comments and to provide additional clarity regarding the types of circumstances that may exceed an ONC-ACB's resources or expertise, we provide the following example, which includes three alternative scenarios. The scenarios, which are mutually exclusive, illustrate how variations in facts and circumstances may give rise to different issues that necessitate different levels of involvement and forms of collaboration between ONC and ONC-ACBs. Example F: An EHR system certified to the 2015 Edition is in use by several major hospitals and health systems, including their ambulatory clinics, in multiple states. During a span of two weeks, over a dozen users at multiple health care facilities report to ONC and to the ONC- ACB that the EHR is displaying inaccurate or missing diagnoses (problems) and that, as a result, patients are not receiving appropriate care. In one reported instance, a patient was diagnosed with renal impairment, and this diagnosis was entered into the patient's active problem list in the EHR by her primary care physician (PCP). The PCP then referred the patient to an orthopedist for an unrelated musculoskeletal issue. The orthopedist is affiliated with the same health system as the PCP and has access to the same instance of the EHR. When the orthopedist accessed the patient's problem list, the diagnosis for renal impairment was missing from any relevant sections as displayed in the EHR. Unaware of this diagnosis, the orthopedist prescribed a medication for musculoskeletal pain that should either be avoided or minimized in patients with renal impairment. As a result, the patient suffered acute renal failure. Similar instances involving other missed or inaccurate diagnoses and resulting harm to patients have also been reported to ONC and the ONC-ACB. Based on the information described above, the ONC-ACB initiates in- the-field surveillance of the certified health IT, as required by Sec. 170.556(b), to assess whether the problem list capability continues to conform to the requirements of the certification criterion at Sec. 170.315(a)(6) (Problem list). Separately, because the certified health IT may be performing in a manner that is causing or contributing to a serious risk to public or health or safety, ONC also initiates direct review of the certified health IT on this basis. ONC does not exercise exclusive \8\ review under the Program at this time. --------------------------------------------------------------------------- \8\ Under the final provisions, ONC may assert exclusive review of certified health IT as to any matters under its review and any similar matters under surveillance by an ONC-ACB. In determining if matters are similar, ONC will, as proposed, consider whether the matters are so intrinsically linked that divergent determinations between ONC and an ONC-ACB would be inconsistent with the effective administration or oversight of the Program. --------------------------------------------------------------------------- Scenario 1 The ONC-ACB's in-the-field surveillance reveals that the cause of the issue is a software error that is only found in one EHR ``workflow.'' The EHR presents the user with multiple ways, or screens, to accomplish the same task. In this case, the PCP modified the problem list from a ``quick summary screen,'' which due to a software error did not write the updated diagnosis (problem) back to the database. This led to a situation where the PCP thought the diagnosis had been updated, but in fact on the back end, the list had not been updated. The EHR, when tested for certification, had presented the ``standard office visit'' screen for diagnosis list modification but not the ``quick summary screen,'' which is an alternate workflow available only in production. The ONC-ACB concludes that the failure of the problem list capability to function in accordance with Sec. 170.315(a)(6) was reasonably within the control of the developer, who should have anticipated the risk during the course of normal software development. Any additional read/write/display functionality may initially contain code errors, and all functions of certified health IT should be subjected to adequate testing. The developer could have reasonably taken actions to avoid the risk by employing an adequate software regression testing methodology. Based on the surveillance and analysis above, the ONC-ACB finds a non-conformity to Sec. 170.315(a)(6) and requires the developer to take corrective action, pursuant to Sec. 170.556(d), including by submitting a CAP in accordance with Sec. Sec. 170.556(d)(1)-(4) that addresses how the developer will resolve the identified non-conformity and related deficiencies across all of the developer's customers and users. ONC, in coordination with the ONC-ACB, concurs with the ONC- ACB's finding of non-conformity and, at this time, forbears from taking any action against the developer because the non-conformity involves a straightforward violation of a certification criterion, which is well within the scope of the [[Page 72425]] ONC-ACB's responsibilities and does not appear to exceed the ONC-ACB's resources. ONC continues to closely monitor the situation and coordinate with the ONC-ACB. If at any time ONC were to believe that the ONC-ACB could not effectively administer the necessary corrective action or that ONC's direct intervention were necessary to more quickly and effectively mitigate the risk to public health or safety, ONC could immediately issue a notice of non-conformity and notice of suspension, as described in section II.A.1.c of this preamble. Scenario 2 The ONC-ACB's in-the-field surveillance reveals that the missing diagnosis was due to a system workflow implementation that the healthcare organization had customized. Contrary to the developer's recommendations, the healthcare organization had removed the problem list from the ``quick visit'' EHR workflow that is presented to ambulatory PCPs. This resulted in the PCP not being able to quickly and easily update the problem list properly, resulting in incomplete problem lists. In contrast to scenario 1, the ONC-ACB finds that there is no non- conformity because these factors are beyond the developer's ability to reasonably influence or control. ONC concurs with the ONC-ACB's determination and ceases its direct review of the certified Health IT Module(s). Scenario 3 Based on its in-the-field surveillance, the ONC-ACB finds that the problem list capability is functioning in accordance with Sec. 170.315(a)(6). Specifically, the ONC-ACB concludes that the issue is not the result of any technical or functional deficiencies with the problem list capability but rather the manner in which the problem list's user interface has been designed, which is unintuitive and appears to have contributed to problems being recorded incorrectly or not at all. The ONC-ACB shares its findings with ONC and states that these usability issues are beyond the scope of the ONC-ACB's expertise and its responsibilities under the Program because a complete assessment of these issues would appear to require an assessment of the developer's software development processes in light of current software usability and human factors best practices. ONC agrees that these issues are beyond the scope of the ONC-ACB's expertise and responsibilities under the Program. However, the issues are not beyond the scope of the Program. ONC concludes that the problem list capability was designed in a way that does not adhere to commonly accepted usability guidelines. In this case, ONC finds that in order to add a diagnosis to the problem list, a user is forced to navigate through an excessive series of windows, confirmation dialogues, and an inordinate amount of clicks to properly select the correct diagnosis. This in turn results in incomplete problem lists due to clinicians' difficulty navigating the overly complex workflow, inability to complete the laborious series of steps due to time constraints, or a combination of both factors. On the basis of these findings, ONC concludes that the certified health IT does not conform to the requirements of the Program. As discussed in section II.A.1.a.(1) of this preamble, certified health IT must be designed and made available to users in ways that allow certified capabilities to be used in an accurate and reliable manner, including in a manner that does not cause or contribute to serious risks to public health or safety. Where certified capabilities do not perform in such a manner due to factors that the developer could have reasonably influenced or controlled, the certified capabilities do not conform to the requirements of the Program. Here, the developer could have reasonably anticipated the risk through an understanding of software usability and human factors best practices, and the developer could have reasonably taken actions to avoid the risk, such as by ensuring adequate usability testing prior to software release. ONC would follow the processes discussed in section II.A.1.c of this preamble to notify the developer of the non-conformity and to work with the developer to expeditiously and comprehensively correct the non- conformity and prevent similar safety risks from recurring. This might include, for example, instituting corrective actions to assist the developer in improving its user-centered design and other quality assurance processes. The example and scenarios above illustrate our intent that ONC's direct review complement and provide a ``backstop'' to the surveillance and other activities of ONC-ACBs so that suspected non-conformities requiring attention do not go unaddressed. To this end, ONC may consult with the ONC-AA, ONC-ACB(s), and other persons or entities, as appropriate, when determining whether to exercise direct review and in conducting such review. ONC may also share relevant information with the ONC-AA, ONC-ACB(s), and other relevant persons and entities as appropriate to assist ONC-ACB surveillance and other activities to address issues with certified health IT, to the extent that the sharing of such information is permitted by law. We believe that such communication will help ONC-ACBs as well as ONC accurately and effectively assess certain issues with certified health IT products. We continue to maintain that reviews by ONC-ACBs and ONC will be complementary and will support comprehensive and consistent review of certified health IT. Comments. Multiple commenters stated that ONC should not review certified health IT on the basis that a potential non-conformity raises novel or complex interpretations or applications of certification criteria (see proposed Sec. 170.580(a)(1)(iv)(D)) or could lead to inconsistent application of certification requirements in the absence of direct review (see proposed Sec. 170.580(a)(1)(v)). The commenters stated that if certification criteria pose issues that are novel, complex, or likely to lead to inconsistent application, these issues should be addressed during the testing and certification process, not by reviewing certified health IT after it has been certified. Response. Commenters may have misunderstood the purpose of these proposed factors and the situations in which they would be relevant to determining whether ONC should initiate direct review. In the 2015 Edition final rule, we explained that to comply with applicable certification criteria, developers must not only demonstrate required capabilities in a controlled testing environment but must also make those capabilities available in ways that enable them to be implemented and used in production environments for their intended purposes (80 FR 62711). As ONC-ACBs increase their surveillance of the performance of certified health IT in production environments, we anticipate that ONC- ACBs may be presented with performance and functionality that might require the analysis of unfamiliar and difficult problems or deficiencies in certified health IT that require significant resources and expertise to properly investigate and assess under existing certification criteria. In some instances, the resources required to undertake this assessment may exceed the resources available to the ONC-ACB. The factors proposed at Sec. 170.580(a)(1)(iv)(D) and (a)(1)(v) were not intended to suggest, as some commenters seem to have misunderstood, that ONC could use [[Page 72426]] direct review to engage in novel interpretations of certification criteria. Rather, these factors were intended to cover situations, such as those described above, that could exceed an ONC-ACB's resources or expertise. To avoid any confusion, we have removed these factors from the final rule's regulation text on the basis that they are duplicative of ONC's consideration of whether an ONC-ACB has sufficient ``resources or expertise'' to evaluate a suspected non-conformity. Comments. A few commenters, including one ONC-ACB, suggested that ONC-ACBs are in the best position to know their own capabilities and as such ONC should not initiate direct review unless invited by an ONC- ACB. One commenter suggested that ONC should be ``on call'' to assist ONC-ACBs to respond to suspected non-conformities that exceed the ONC- ACBs capacity or expertise. Response. We thank commenters for their comments. In response to commenter concerns, we have adapted the final rule to provide ONC with an opportunity to consult with ONC-ACBs, as well as the ONC-AA and any other persons or entities, as ONC deems appropriate. In order for ONC to exercise direct review under Sec. 170.580(a)(2)(ii)(C), ONC must necessarily make a judgment about the resources and expertise of an ONC-ACB. ONC would only very rarely be in a position to make such a judgment without first consulting with the relevant ONC-ACB. However, because ONC is the Program owner and administrator, it would be inappropriate if an ONC-ACB were able to prevent ONC from initiating direct review if ONC has formed a reasonable belief that the ONC-ACB lacks the resources or expertise to investigate and address the suspected non-conformity at issue. Comments. Commenters urged us to clarify the types of information that ONC would rely on in deciding whether to initiate direct review, including when ONC would deem information ``reliable and actionable'' so as to warrant further inquiry into certified health IT's conformity to Program requirements (see 81 FR 11062). Response. In the 2015 Edition final rule, we provided guidance on the circumstances that would trigger an ONC-ACB's duty to initiate reactive surveillance (80 FR 62712). We said that in determining whether to initiate reactive surveillance, an ONC-ACB must consider and weigh the volume, substance, and credibility of complaints and other information received against the type and extent of the alleged non- conformity, in light of the ONC-ACB's expertise and experience with the particular capabilities, health IT, and certification requirements at issue. As an example, we supposed that where an ONC-ACB receives a number of anonymous complaints alleging general dissatisfaction with a particular certified health IT, the ONC-ACB would not be required to initiate surveillance (though it would not be precluded from doing so). In contrast, upon receiving several complaints alleging specific non- conformities, the ONC-ACB must initiate surveillance of the certified health IT unless a reasonable person in the ONC-ACB's position would doubt the credibility or accuracy of the complaints. By way of example, we explained that a reasonable basis for doubt might exist if the ONC- ACB had recently responded to the very same issue and determined through in-the-field surveillance of the certified health IT at several different locations that the reported problem was due to a ``bug'' arising from an unsupported use of the certified health IT that the developer had specifically cautioned users about in advance. We anticipate applying these same principles in determining whether information about a potential non-conformity is sufficiently reliable and actionable to warrant ONC's direct review. We note, however, that in contrast to an ONC-ACB's affirmative duty to initiate surveillance, ONC is not required to initiate direct review. As such, ONC may require additional information before initiating review or may choose not to exercise review for any reason. Comments. Commenters made a range of suggestions about criteria that ONC could adopt, or indicia ONC could use, to determine the veracity or credibility of information received by ONC when making a determination on whether or not to commence direct review. A number of commenters suggested that ONC should not initiate direct review of an alleged non-conformity unless the complainant has first notified the developer and given the developer an opportunity to rectify the deficiency. Response. We thank commenters for their constructive suggestions. Because most issues that are the subject of direct review will concern risks to public health or safety, we anticipate that it will be very rare for information about such risks to be reported to ONC without first being brought to the developer's attention. However, we have determined that it would not be appropriate for ONC to be inhibited from initiating direct review on the basis that a health IT user had not first notified the health IT developer of the issue and provided the developer with an opportunity to rectify the deficiency. Consistent with a number of comments received from health IT developers, we note that a large number of health IT users do not have a direct business relationship with the developer of the health IT product they use. This is because many small healthcare practices receive their health IT via a sublicensing arrangement entered into with a large health care network. Similarly, other health IT stakeholders, such as health information exchanges, are positioned to identify deficiencies in certified health IT products they interact with but would not necessarily have a recognized process through which to raise issues or grievances with the developer concerned. Because ONC will weigh the volume, substance, and credibility of any information received, in light of all relevant circumstances, we do not believe it is necessary or appropriate to exclude from consideration any particular types or sources of information or to decide in advance what if any weight should be assigned to them. Comments. One commenter also suggested that ONC would need to receive a threshold number of complaints by multiple distinct users in respect to the same certified health IT version number before the information in ONC's possession was actionable. Response. ONC respectfully disagrees that there is a threshold number of complaints that would apply in all circumstances to ensure that direct review was triggered in only appropriate cases. Indeed, we can envision public health or safety risks for which a single complaint supported by detailed information and/or evidence would be sufficiently reliable and actionable to trigger ONC's exercise of discretion to initiate direct review. Comments. A commenter suggested that a provider's timeliness in implementing all applicable and available releases and ``hot fixes'' for the certified health IT should be taken into consideration by ONC when assessing the veracity and credibility of information ONC has received. Response. We thank this commenter for their comment. If a health IT developer issued customers with a new release, patch, or ``hot fix'' to address a deficiency in the developer's certified health IT, but their recommendation to implement the update within a specified period is ignored, ONC may determine that the deficiency at issue was caused by factors removed from the control or responsibility of the developer (see discussion above in section II.A.1.a.(1) of this preamble). [[Page 72427]] However, ONC may determine that it may nevertheless initiate review of the affected certified health IT in order to make a proper determination of the cause of any suspected non-conformity and to make an assessment of whether the remedial action implemented by the developer is appropriate in the circumstances. b. ONC-ACB's Role We proposed that ONC's review of certified health IT would be independent of, and may be in addition to, any review conducted by an ONC-ACB, even if ONC and the ONC-ACB were to review the same certified health IT, and even if the reviews occurred concurrently. To ensure consistency and clear accountability, we also proposed that ONC, if it deems necessary, could assert exclusive review of certified health IT as to any matters under review by ONC and any other matters that are so intrinsically linked that divergent determinations between ONC and an ONC-ACB would be inconsistent with the effective administration or oversight of the Program. Finally, we proposed that in such instances, ONC's determinations on these matters would take precedent and a health IT developer would be subject to the proposed ONC direct review provisions in the Proposed Rule, including having the opportunity to appeal an ONC determination, as applicable. We clarified in the Proposed Rule that, in matters where ONC does not assert direct and/or exclusive review or ceases its direct and/or exclusive review, an ONC-ACB would be permitted to issue its own determination on the matter. We further clarified that any resulting determination to suspend or terminate a certification issued to a Complete EHR or Health IT Module by an ONC-ACB would not be subject to ONC review under the provisions proposed in the Proposed Rule. We also stated that in those instances, there would be no opportunity to appeal the ONC-ACB's determination(s) under the provisions proposed in the Proposed Rule. We emphasized that ONC-ACBs are accredited, authorized, and entrusted to issue and administer certifications under the Program consistent with adopted certification criteria and other specified Program requirements. Therefore, they have the necessary expertise and capacity to effectively administer these specific requirements. We proposed in the Proposed Rule that ONC could initiate review of certified health IT on its own initiative based on information from an ONC-ACB, which could include a specific request from the ONC-ACB to conduct a review. In exercising its review of certified health IT, we proposed that ONC would be entitled to any information it deems relevant to its review that is available to the ONC-ACB responsible for administering the health IT's certification. We proposed that ONC could contract with an ONC-ACB to conduct facets of an ONC direct review within an ONC-ACB's scope of expertise, such as surveillance of certified capabilities. We proposed that ONC could also share information with an ONC-ACB that may lead the ONC-ACB, at its discretion and consistent with its accreditation, to conduct in-the-field surveillance of the certified health IT at particular locations. We further proposed that ONC could, at any time, end all or any part of its review of certified health IT under the processes proposed and refer the applicable part of the review to the relevant ONC-ACB(s), if doing so would be in the best interests of efficiency or the effective administration and oversight of the Program. We stated that the ONC-ACB would be under no obligation to proceed further, but would have the discretion to review and evaluate the information provided and proceed in a manner it deems appropriate. As noted above, this may include processes and determinations (e.g., suspension or termination) not governed by the proposed review and appeal processes. We requested comment on our proposed approach and the role of an ONC-ACB. Comments. Multiple commenters supported our proposals regarding the ONC-ACB's role and responsibilities for reviewing certifications of Complete EHRs and Health IT Modules. Commenters agreed that there are situations when ONC should have authority to independently review or assist an ONC-ACB in reviewing certified health IT. Other commenters questioned our rationale for allowing ONC direct review to be independent of, and in addition to, ONC-ACB review. These commenters contended that ONC-ACBs are qualified to review all non-conformities. A few commenters requested clarification regarding the scope of review responsibilities for ONC and ONC-ACBs, respectively. Response. We have finalized our proposals regarding the ONC-ACB's role and responsibilities in relation to ONC direct review as proposed with the following clarifications and a revision as discussed in the response below. As stated above, reviews by ONC-ACBs and ONC would be complementary, but independent as well. As discussed in detail under section II.A.1.a, we believe that ONC should exercise direct review over matters outside of an ONC-ACB's resources and expertise as well as matters that pose a serious risk to public health or safety. We clarify that ONC-ACB review after a certification is issued is limited to surveillance. This clarification is consistent with the requirements of ISO/IEC 17065 \9\ and our discussion of ONC-ACB surveillance in the 2015 Edition final rule (see 80 FR 62605). Thus, we refer to this ``review'' by the ONC-ACB as surveillance in this final rule. --------------------------------------------------------------------------- \9\ The international standard to which ONC-ACBs are accredited. 45 CFR 170.599(b)(4). --------------------------------------------------------------------------- Comments. Commenters, including an ONC-ACB, expressed agreement with our proposal that as the scheme owner and regulator, ONC's determinations should take precedent. Other commenters were concerned that there could be conflicts between ONC and ONC-ACB determinations and questioned why ONC's determination should take precedent. Commenters also suggested that the proposed approach to review could cause mixed messaging by ONC and ONC-ACBs and duplication of efforts by health IT developers (e.g., document production and interviews). Commenters encouraged ONC and ONC-ACBs to share relevant information and coordinate review in order to avoid duplication. Response. We believe the final provisions will facilitate sound determinations by the appropriate body and help avoid duplicative review. Under the final provisions, ONC may assert exclusive review of certified health IT as to any matters under its review and any similar matters under surveillance by an ONC-ACB. In determining if matters are similar, ONC will, as proposed, consider whether the matters are so intrinsically linked that divergent determinations between ONC and an ONC-ACB would be inconsistent with the effective administration or oversight of the Program. A determination by ONC on matters under its review will be controlling and supersede any determination by an ONC-ACB. We believe these steps will help avoid conflicts in determinations and permit ONC, as the administrator of the Program, to reach appropriate outcomes consistent with Program requirements on matters within its review. Under the final provision in Sec. 170.580(a)(3)(v), ONC may end all or any part of its review of certified health IT and refer the applicable part of the review to the relevant ONC-ACB(s) if [[Page 72428]] ONC determines that doing so would serve the effective administration or oversight of the Program. The ONC-ACB would be under no obligation to proceed further, but would have the discretion to review and evaluate the information provided and proceed in a manner it deems appropriate. We are finalizing this provision by revising it for clarity. We had proposed that ONC may end its review based on the best interests of efficiency or the administration and oversight of the Program (81 FR 11083). We have revised that proposal to be that ONC may determine to end its review if that would serve the effective administration or oversight of the Program. We believe the revision eliminates duplicative bases for ending review and remains consistent with the intent of the proposed provision. In addition, for further clarity, we have added that ONC may cease its review at any time. We indicated in the Proposed Rule that we could cease our review, but we did not make clear that it could be at any time during the direct review process (see also section II.A.1.a.(2) of this preamble). We further note that in the discussion of the direct review processes, we provide clarity regarding the steps ONC would take throughout direct review, including after receiving health IT developer responses to notices. We appreciate commenters' suggestion that ONC increase coordination and sharing of information with ONC-ACBs. ONC and ONC-ACBs regularly communicate and we anticipate this communication would continue when ONC initiates direct review of certified health IT. As noted by commenters, such communication will benefit the Program and minimize the possibility of mixed messaging or duplicative review. In furtherance of collaboration between ONC and ONC-ACBs, we have finalized the proposed requirement that ONC-ACBs must provide ONC with any available information that ONC deems relevant to its review of certified health IT. We have also included ONC-ATLs in this information sharing provision as we have finalized the ONC-ATL processes in this final rule. We note that we could share information with an ONC-ACB that may lead the ONC-ACB, at its discretion and consistent with its accreditation, to conduct in-the-field surveillance of the health IT at a particular location. Comment. A commenter expressed concern that the Proposed Rule did not propose appeal rights for ONC-ACB determinations. The commenter explained that, if there are two different enforcement bodies (ONC and ONC-ACBs) that may make determinations, there should be equal rights for a health IT developer to appeal those determinations. Response. Health IT developers that have their certifications terminated by an ONC-ACB can appeal that determination to the ONC-ACB, similar to how an ONC termination can be appealed to the National Coordinator under the processes finalized in this final rule. The ONC- ACB will process the appeal in accordance with the requirements of ISO/ IEC 17065 and the ONC-ACB's procedures. Appeal procedures may vary among ONC-ACBs, so health IT developers should familiarize themselves with the appeal procedures provided by their ONC-ACB(s). If the health IT developer is not satisfied with the result of the appeal, the health IT developer can submit the matter to the Approved Accreditor for certification under the Program, American National Standards Institute (ANSI), for consideration. In consideration of the ONC-ACB appeals process outlined above and our belief that ONC-ACBs have the necessary expertise and capacity to effectively administer certifications under the Program consistent with the certification criteria and other specified Program requirements, we have not established a process for health IT developers to appeal ONC- ACB determinations to ONC. c. Review Processes We stated in the Proposed Rule that ONC could become aware of information from the general public, interested stakeholders, ONC-ACBs, or by any other means that indicates that certified health IT may not conform to the requirements of its certification or is, for example, leading to medical errors or other outcomes that do not align with the National Coordinator's responsibilities under section 3001 of the PHSA. We proposed that, if ONC deems the information to be reliable and actionable, it would conduct further inquiry into the certified health IT. We further stated that ONC could also initiate an independent inquiry into the certified health IT that could be conducted by ONC or a third party(ies) on behalf of ONC (e.g., contractors or inspection bodies under the certification scheme). If information reveals that there is a potential non-conformity (through substantiation or omission of information to the contrary) or confirms a non-conformity in the certified health IT, we stated that ONC would proceed to notify the health IT developer of its findings, as applicable, and work with the health IT developer to address the matter. We proposed that correspondence and communication with ONC and/or the National Coordinator for all processes proposed under this section (section II.A.1.c) of the preamble shall be conducted by email, unless otherwise necessary or specified. We proposed to modify Sec. 170.505 accordingly. Comments. Commenters supported the ONC direct review processes as proposed. A commenter emphasized that the review processes would promote greater accountability of health IT developers for the performance, reliability, and safety of certified health IT. A few commenters, however, expressed concern about frivolous complaints. These commenters and other commenters requested clarification regarding the type of information that would warrant ONC direct review and requested that ONC explain what constitutes ``reliable and actionable'' information. A commenter requested that ONC establish clear requirements for what information must be presented as part of a complaint or allegation of non-conformity and who would be eligible to make such a complaint. Response. We have finalized the process and criteria for identifying non-conformities that would warrant ONC direct review as proposed with clarifications in response to comments. We clarify that in order to determine the reliability of the information, ONC will consider and weigh the volume, substance, and credibility of complaints and other information received against the type and extent of the alleged non-conformity. We note that this reliability standard aligns with the ONC-ACB standard for initiating surveillance in the 2015 Edition final rule (80 FR 62713). We also clarify that if information ONC receives does not provide adequate detail, specificity, or clarity regarding the suspected non-conformity, ONC will, as necessary, contact the party(ies) who submitted the complaint to gather additional information and make a decision as to whether the complaint is actionable. To avoid confusion, we have removed ``reliable and actionable'' from the relevant provisions of Sec. 170.580. We believe the above clarification is responsive to commenters and clarifies the type of information that would give ONC a ``reasonable belief'' that the certified health IT may not or does not conform to the requirements of the Program. In section II.A.1.a.(3) of this final rule, we describe factors ONC should consider when deciding whether to [[Page 72429]] exercise direct review. These factors afford ONC discretion to evaluate information on a case-by-case basis. Considering the wide range of information ONC may receive regarding non-conformities in certified health IT, and that ONC has specialized expertise to evaluate the reliability and accuracy of such information, it is essential that ONC have discretion in making direct review decisions. Comments. Many commenters suggested that correspondence throughout the review processes should be issued by mail. Response. We have finalized the requirements for correspondence with additional regulation revisions and processes. Section 170.505 states that correspondence and communication with ONC or the National Coordinator shall be conducted by email, unless otherwise necessary or specified. We note that email correspondence and communication of protected health information by HIPAA covered entities and business associates must employ safeguards in compliance with the HIPAA Rules. Section 170.505 provides the flexibility to use means other than email as ``necessary or specified.'' As stated in the Proposed Rule, we intend to send notice of suspension and termination via certified mail. We also intend to send notices of potential non-conformity, notices of non-conformity, and notices of proposed termination via certified mail. We have, therefore, revised Sec. 170.505 to clearly state the potential use of certified mail in addition to regular and express mail. Section 170.505 specifies that the official date of receipt of any form of mail will be the date of the delivery confirmation. We have revised the language of this provision to clarify that it applies to all parties and that delivery confirmation is to the address on record. The address on record is the most recently provided address to ONC or an ONC-ACB, as applicable. We believe this will clarify the process in situations where an entity, such as a health IT developer, moves its place of business or goes out of business without notifying ONC or the relevant ONC-ACB. (1) Notice of Potential Non-Conformity or Non-Conformity We proposed that if information suggests to ONC that certified health IT is not performing consistent with Program requirements and a non-conformity exists with the certified health IT, ONC would send a notice of potential non-conformity or non-conformity to the health IT developer. We explained in the Proposed Rule that the notice would specify ONC's reasons for the notification, explain ONC's findings, and request that the health IT developer respond to the potential/alleged non-conformity (and potentially a corrective action request) or be subject to further action (e.g., corrective action, suspension, and/or the termination of the certification in question, as appropriate). We proposed that ONC should have the ability to access and share within HHS, with other federal agencies, and with appropriate entities, a health IT developer's relevant records related to the development, testing, certification, implementation, maintenance, and use of its product, as well as any complaint records related to the product. We stated that this proposal would ensure a complete and comprehensive review of the certified health IT product. We noted that much of this information already must be disclosed as required by the Program and described in the 2015 Edition final rule. We proposed, however, that ONC be granted access to, and be able to share within HHS, with other federal agencies, and with appropriate entities (e.g., a contractor or ONC-ACB) any additional records not already disclosed that may be relevant and helpful in ONC's fact-finding and review. If we determined that the health IT developer was not cooperative with the fact-finding process, we proposed that we would have the ability to suspend or terminate the certification of any encompassed Complete EHR or Health IT Module of the certified health IT as outlined later in sections II.A.1.c.(3) and (4) of this final rule. We stated in the Proposed Rule that we understood that health IT developers may have concerns regarding disclosure of proprietary, trade secret, competitively sensitive, or other confidential information. To address these concerns, we further stated that ONC would implement appropriate safeguards to ensure, to the extent permissible with federal law, that any proprietary business information or trade secrets that ONC might encounter by accessing the health IT developer's records would be kept confidential by ONC.\10\ For instance, ONC would ensure that, if it obtains proprietary or trade secret information, that information would not be included in the CHPL. We noted, however, that the safeguards we would adopt would be prophylactic and would not create a substantive basis for a health IT developer to refuse to comply with the proposed requirements. Thus, a health IT developer would not be able to avoid providing ONC access to relevant records by asserting that such access would require it to disclose trade secrets or other proprietary or confidential information. --------------------------------------------------------------------------- \10\ The Freedom of Information Act, 18 U.S.C. 1905, and the Uniform Trade Secrets Act generally govern the disclosure and descriptions of these types of information. --------------------------------------------------------------------------- We proposed that unless otherwise specified in the notice, the health IT developer would be required to respond within 30 days of receipt of the notice and, if necessary, submit a proposed CAP as outlined below in section II.A.1.c.(2) of this final rule. We proposed that ONC may require a health IT developer to respond and/or submit a proposed CAP in more or less time than 30 days based on factors such as, but not limited to: (1) The type of health IT and health IT certification in question; (2) the type of non-conformity to be corrected; (3) the time required to correct the potential non- conformity or non-conformity; and (4) issues of public health and safety and other exigencies related to the National Coordinator carrying out his or her duties in accordance with sections 3001(b) and (c) of the PHSA. We proposed that ONC would have discretion in deciding the appropriate timeframe for a response and proposed CAP from the health IT developer. We proposed that if the health IT developer contends that the certified health IT in question conforms to Program requirements, the health IT developer must include in its response all appropriate documentation and explain in writing why the health IT is conforming. We requested comment on our proposed processes described above, including whether the timeframe for responding to a notice of potential non-conformity or non-conformity is reasonable and whether there are additional factors that we should consider. Comments. Many commenters supported the proposed processes for notices of potential non-conformity and non-conformity. Multiple commenters, however, requested discussion between ONC and the health IT developer, which could also include the ONC-ACB, regarding a complaint or surveillance issue prior to the issuance of a notice of potential non-conformity or non-conformity. Commenters stated that such discussion would help ensure the appropriateness of, and necessity for, the issuance of a notice of potential non-conformity or non-conformity. A commenter also recommended that ONC engage with end-users of certified health IT and establish a process in which end- [[Page 72430]] users can offer feedback on certified health IT to help alert ONC to potential and actual non-conformities. Many commenters requested that ONC clarify the circumstances that would cause ONC to send a notice of potential non-conformity or non- conformity to a health IT developer. These commenters also expressed concerns that, as proposed, ONC could issue a notice of non-conformity without first issuing a notice of potential non-conformity. Commenters opined that a notice of non-conformity should not be the first instance of notification to a health IT developer in the ONC direct review process. A commenter recommended that ONC provide a model notification to industry and stakeholders of the content of a notice of potential non-conformity and non-conformity. Response. We thank commenters for their thoughtful comments on this aspect of the proposed direct review processes. We have finalized the proposed processes for notices of potential non-conformity and non- conformity with the following clarifications and revisions discussed below and finalized in Sec. 170.580(b)(1) through (3). We agree with commenters regarding the benefits of open discussion between ONC, health IT developers, and as applicable, ONC-ACBs, during the direct review process. While we encourage discussions between ONC and health IT developers prior to the issuance of a notice of potential non-conformity or non-conformity, we cannot guarantee that such discussions will always precede a notice because ONC may need to take immediate steps to expedite direct review and corrective action or have other reasons for not first discussing the matter. We emphasize that our first and foremost goal is to work with health IT developers to address any non-conformities in certified health IT in a timely manner and across all customers, and we encourage discussion as early as possible in the process to help achieve this goal. We also appreciate the suggestion that ONC engage with end-users and we encourage end-users to contact us with their concerns. Specifically, end-users can submit a complaint through the ONC- established complaint process at: https://www.healthit.gov/healthitcomplaints. While we do not believe we could develop a model notice that would be of value to health IT developers because each instance of potential non-conformity or non-conformity will likely be unique, we do offer the following clarifications. ONC may issue a notice of non-conformity without first issuing a notice of potential non-conformity if supported by the circumstances and information available to ONC. ONC must be able to issue a notice of non-conformity in situations where information establishes and ONC determines that there is an actual non-conformity in order to put the health IT developer on notice and begin the corrective action process without delay. In comparison, ONC may issue a notice of potential non-conformity when it has a reasonable belief, based on information at its disposal, that there may be a non- conformity with the certified health IT. We further note that a notice of potential non-conformity and notice of non-conformity are separate and distinct notices, and ONC can issue them concurrently, as necessary. In such situations, each notice will include the appropriate timeframe for the health IT developer to submit a response. As stated above, we will send notices of potential non-conformity and non- conformity by certified mail and the official date of receipt will be the date of the delivery confirmation to the address on record consistent with Sec. 170.505. Developer Response We have restructured and revised the requirements for health IT developer responses to notices of potential non-conformity and non- conformity (see Sec. 170.580(b)(1)(ii) and (b)(2)(ii)). These revisions are intended to clarify ONC's expectations regarding health IT developer responses and to emphasize that the proposed and finalized ``Records Access'' provision (Sec. 170.580(b)(3)) is a separate requirement. Health IT developers must respond to a notice of potential non- conformity by (1) cooperating with ONC and/or a third party acting on behalf of ONC, (2) providing ONC and/or a third party acting on behalf of ONC access to the certified health IT under review, and (3) providing ONC with a written explanation, within 30 days, unless adjusted by ONC, addressing the potential non-conformity, including all appropriate documentation. Health IT developers must respond to a notice of non-conformity in the same fashion as described for a notice of potential non-conformity above and, in addition, must submit a proposed CAP (see Sec. 170.580(b)(2)(ii)(A)(4)). We note that we did not propose in the Proposed Rule that the health IT developer could respond to a notice of non-conformity through a written explanation addressing the non- conformity in addition to submitting a proposed CAP. We have, however, finalized this new provision in the final rule to allow health IT developers to explain, agree with, or refute the notice of non- conformity, which parallels a health IT developer's opportunity to respond to a notice of potential non-conformity. This opportunity to respond is in addition to submitting a proposed CAP and will not delay or prolong the CAP process. In addition, we note that ONC may still propose termination under Sec. 170.580(e), as necessary, despite a written explanation from the health IT developer that refutes the notice of non-conformity. We further note that a health IT developer may choose to contest the notice of potential non-conformity or not cooperate with ONC or a third party acting on behalf of ONC. However, we again emphasize that in such situations ONC may take action under the proposed termination provisions (see Sec. 170.580(e)). Comments. We received numerous comments on the proposed 30-day default response period for notice of potential non-conformity or non- conformity. This includes the requirement, which is also stated in section II.A.1.c.(2) of this final rule below, that a health IT developer must submit a proposed CAP to ONC within 30 days of the date that ONC notifies the health IT developer of an actual non-conformity, unless ONC specifies a different timeframe. A few commenters supported our proposal and response timeframe. Many commenters suggested that the 30-day default response period should be the minimum time period to respond to a notice. Other commenters stated that a 30-day default response period is too short, particularly when corrective action is required, because non-conformities may be complex and difficult to resolve. One commenter suggested that the 30-day default response period is too long. The commenter stated that, based on past experience working with numerous certified systems to address non-conformities, 30 days is a long time for the problem to be addressed, much less to develop a plan to address the problem. Many commenters requested clarification about instances when the response period would be ``more or less'' time than 30 days, as proposed. Many commenters also suggested that the response period be measured in business days. Response. We have finalized this requirement as proposed for responding to both a notice of potential non-conformity and a notice of non-conformity with clarifications in response to comments. We maintain [[Page 72431]] that 30 days is an appropriate default response period that will afford health IT developers ample time to respond to a notice and ensure that health IT developers address non-conformities in a timely fashion. We provide clear guidance regarding the factors ONC will use to determine whether the health IT developer should submit a response and/or CAP in more or less time than 30 days (Sec. 170.580(b)(1)(ii)(B) and (b)(2)(ii)(B)). ONC must retain discretion to increase or decrease the 30-day period when necessary due to the wide range and complexity of non-conformities. We emphasize that ONC will work with health IT developers to develop acceptable CAPs with reasonable timeframes for completion. We also clarify that health IT developers may request an extension for submittal of a CAP. In order to make this extension request, a health IT developer must submit a written statement to ONC that explains and justifies the request. For clarity, we previously adopted the definition of ``day or days'' in Sec. 170.102 to mean calendar day or calendar days (Temporary Certification Program final rule; 75 FR 36162 and 36203). We clarify, as noted above, that a health IT developer's response to a notice of potential non-conformity or non-conformity includes providing ONC, and/or a third party acting on behalf of ONC, with access to the certified health IT under review (Sec. 170.580(b)(1)(ii) and (b)(2)(ii)). We note that this is a clarification of the requirement in the Proposed Rule and does not introduce a new requirement for health IT developers (81 FR 11058). We proposed in the ``Authority and Scope'' section of the Proposed Rule that this rulemaking was intended to address ONC's direct review of certified health IT and provide ONC with access to the certified health IT and relevant records (``records access'' proposal) to assist in determining whether a non-conformity exists and addressing a found non-conformity. ONC Determination We have added and finalized provisions that specify how ONC would respond to a health IT developer's response to a notice of potential non-conformity and notice of non-conformity. These provisions provide further transparency and clarification of the review processes, particularly with regard to ONC actions. However, we emphasize that, as specified under the ``ONC-ACB's Role'' section of this final rule above, ONC may end its review at any time. We have finalized a provision that addresses ONC's options after receiving the health IT developer's written explanation in response to a notice of potential non-conformity. ONC will do one of the following (Sec. 170.580(b)(1)(iii)): (1) Issue a written determination ending its review (which, may also include a rescission of a suspension (see the ``suspension'' section of this final rule for further discussion)); (2) request additional information and continue its review in accordance with a new timeframe it establishes (see Sec. 170.580(b)(1)(ii)(A)(3) and (b)(1)(ii)(B)); (3) substantiate a non- conformity and issue a notice of non-conformity; or (4) issue a notice of proposed termination. We have also finalized a similar provision that addresses ONC's options after receiving the health IT developer's written response to a notice of non-conformity. ONC will either issue a written determination ending its review or continue with its review under the provisions of this section. The continuation of ONC's review would likely be to proceed through the CAP process as outlined in this final rule, but may instead be to issue a proposed termination or take other appropriate action under the provisions of this final rule. Comments. Many commenters expressed concern that the proposed records access requirement is too broad, extends beyond what is required for ONC-ACB surveillance, and could require health IT developers to produce large amounts of information. Commenters suggested that the proposed language should be more narrowly focused on records that directly bear on the specific certified capabilities affected by the non-conformity(ies) and materials relevant to the issue under review. Commenters were also concerned about protecting the confidentiality of health IT developer records. Commenters questioned the necessity of sharing records with other federal agencies and appropriate entities. A commenter noted that documents or records obtained by ONC during the course of direct review could contain protected health information (PHI), trade secrets, or other sensitive information without a sufficient basis or adequate assurances that this information would be protected from further disclosure. Response. We have finalized this requirement as proposed with the following clarifications. This approach to records access and sharing of records is necessary for ONC to conduct a comprehensive review of certified health IT, and will supplement ONC's access to the certified health IT under review. This approach supports the review of uncertified capabilities that interact with certified capabilities and will assist ONC in determining whether certified health IT conforms to applicable Program requirements. Further, the relevant records and federal departments, agencies, and offices will be determined on a case-by-case basis with consideration of the matter under review. We clarify that ``complaint records'' under the records access requirements include, but are not limited to, issue logs and help desk tickets. As stated and outlined in the Proposed Rule (81 FR 11063), we are committed to implementing appropriate safeguards to ensure that any proprietary business information or trade secrets that ONC might encounter would be kept confidential by ONC to the extent permissible by federal law. To that end, we strongly recommend that health IT developers clearly mark, as described in HHS Freedom of Information Act regulations at 45 CFR 5.65(c), any information they regard as trade secret or confidential commercial or financial information prior to disclosing the information to ONC. Regarding the disclosure of PHI to ONC, we refer to our previous guidance provided on this issue in consultation with the HHS Office for Civil Rights. Specifically, in the 2015 Edition Final Rule, we explained that a health care provider is permitted, without patient authorization, to disclose PHI to an ONC-ACB for purposes of the ONC- ACB's authorized surveillance activities (80 FR 62716). Health care providers are permitted to make disclosures to a health oversight agency (as defined in 45 CFR 164.501) for oversight activities (as described in 45 CFR 164.512(d)) authorized by law, including activities to determine compliance with program standards, and ONC may delegate its authority to ONC-ACBs to perform surveillance of certified health IT under the Program.\11\ This disclosure of PHI to an ONC-ACB does not require a business associate agreement with the ONC-ACB since the ONC- ACB is not performing a function on behalf of the covered entity. In the same way, a provider, health IT developer, or other person or entity is permitted to disclose PHI directly to ONC, without patient authorization and without a business associate agreement, for purposes of ONC's direct review of certified health IT or the performance of any other [[Page 72432]] oversight responsibilities of ONC to determine compliance under the Program. --------------------------------------------------------------------------- \11\ See: 45 CFR 164.512(d)(1)(iii); 80 FR 62716; and ONC Regulation FAQ #45 [12-13-045-1] available at http://www.healthit.gov/policy-researchers-implementers/45-question-12-13-045. --------------------------------------------------------------------------- We further clarify that, as we contemplated in the Proposed Rule, it may be necessary for ONC to engage additional resources and specialized expertise to timely and effectively respond to potential non-conformities or non-conformities (81 FR 11058), and that this may include engaging outside experts, consultants, or other persons or entities (consultants) for the purpose of assisting ONC in its direct review of certified health IT. In the same way that ONC authorizes ONC- ACBs to conduct surveillance of certified health IT under the Program, ONC may authorize such consultants to perform fact-finding, analyses, and/or other functions that support ONC's direct review of the certified health IT; and pursuant to ONC's health oversight authority (as defined in 45 CFR 164.512(d)(1)(iii)), persons and entities are permitted to disclose PHI to such consultants for the purpose of carrying out these authorized activities, without patient authorization and without a business associate agreement. We note that subsequent disclosures of identifiable patient health information by ONC, or persons or entities acting on ONC's behalf, are limited to those expressly allowed by law--such as under the Privacy Act of 1974 and/or the Freedom of Information Act (FOIA), as applicable. (2) Corrective Action We proposed in the Proposed Rule that if ONC finds that certified health IT does not conform to Program requirements, ONC would take appropriate action with the health IT developer to remedy the non- conformity as outlined below. We proposed that ONC would require a health IT developer to submit a proposed CAP to ONC. The CAP would provide a means to correct the identified non-conformities across all the health IT developer's customer base. We proposed, as described above in section II.A.1.c.(1) of this preamble and in the Proposed Rule, that a health IT developer must submit a proposed CAP to ONC within 30 days of the date that ONC notifies the health IT developer of the non-conformity, unless ONC specifies a different timeframe. We explained in the Proposed Rule that this approach aligns with and does not change the corrective action process specified in Sec. 170.556(d) and used by ONC-ACBs. The primary difference between this approach and the approach specified Sec. 170.556(d) is that in Sec. 170.556(d) the health IT developer must submit a CAP to an ONC-ACB within 30 days of being notified of the potential non-conformity. We proposed in the Proposed Rule that this 30-day period be the default for receiving a response/CAP, but that ONC may alter the response period based on non-conformities that may pose a risk to public health or safety, or other exigencies related to the National Coordinator carrying out his or her duties in accordance with sections 3001(b) and (c) of the PHSA (81 FR 11063). We proposed in the Proposed Rule that ONC would provide direction to the health IT developer as to the required elements of the CAP and would work with the health IT developer to develop an acceptable CAP. We proposed that a CAP must include, at a minimum, for each non- conformity: A description of the identified non-conformity; An assessment of the nature, severity, and extent of the non-conformity, including how widespread they may be across all of the health IT developer's customers of the certified health IT; How the health IT developer will address the identified non-conformity, both at the locations where the non-conformity was identified and for all other potentially affected customers; A detailed description of how the health IT developer will assess the scope and impact of the non-conformity(ies), including identifying all potentially affected customers, how the health IT developer will promptly ensure that all potentially affected customers are notified of the non-conformity and plan for resolution, how and when the health IT developer will resolve issues for individual affected customers, and how the health IT developer will ensure that all issues are in fact resolved; and The timeframe under which corrective action will be completed. We proposed that when ONC receives a proposed CAP (or a revised proposed CAP) it shall either approve the proposed CAP or, if the plan does not adequately address all required elements, instruct the health IT developer to submit a revised proposed CAP. In addition to the required elements above, we proposed that a health IT developer would be required to submit an attestation to ONC. We explained that the attestation would follow the form and format specified by the CAP and would be a binding official statement by the health IT developer that it has fulfilled all of its obligations under the CAP, including curing the identified non-conformities and related deficiencies and taking all reasonable steps to prevent their recurrence. We stated in the Proposed Rule that based on this attestation and all other relevant information, ONC would determine whether the non- conformity(ies) had been cured and, if so, would lift the CAP. However, we proposed that if it were later discovered that the health IT developer had not acted in the manner attested, ONC could reinstitute the CAP or proceed to suspend or terminate the certification of any encompassed Complete EHR or Health IT Module of the certified health IT. We proposed that ONC would report the CAP and related data to the publicly accessible CHPL. The purpose of this reporting requirement, as it is for ONC-ACBs under current regulations, would be to ensure that health IT users, implementers, and purchasers are alerted to potential conformity issues in a timely and effective manner. This approach is consistent with the public health and safety, program integrity, and transparency objectives described previously in the Proposed Rule (81 FR 11064) and in the 2015 Edition final rule (80 FR 62725-26). We requested comment on our proposed CAP processes as described above. Comments. Many commenters stated that ONC should use the same construct for CAPs as was established in Sec. 170.566(d) for non- conformities found by ONC-ACBs. A few commenters noted that the proposed corrective action requirements and the ``ONC-ACB CAP'' requirements are consistent concerning the authority of ONC and ONC- ACBs to provide direction on required elements of the CAP, but are inconsistent with regard to the proposed ability of ONC to ``prescribe'' such corrective action as may be appropriate to fully address the identified non-conformity(ies). Some commenters suggested that ONC clarify this language so that ONC is able to ``prescribe'' the elements required of the CAP, but not health IT developer actions. Response. We thank commenters for their thoughtful comments on this aspect of the proposed corrective action process. In consideration of these comments, we have finalized the corrective action requirement and CAP elements at Sec. 170.580(c)(2), subject to the following changes and clarification discussed below. As discussed above, our approach to corrective action aligns with the corrective action process specified in Sec. 170.556(d) for ONC-ACB actions. Section 170.556(d) does not, however, ``prescribe'' corrective action. Therefore, to further align with [[Page 72433]] Sec. 170.556(d) and in response to comments, we have removed ``prescribe'' from the regulation text. We emphasize that this change is only a clarification of the proposed language and does not represent a narrower policy than proposed. Our goal with CAPs under ONC direct review and ONC-ACB surveillance is to remedy the non-conformity(ies) as quickly and effectively as possible. Therefore, we will include such required elements as part of a CAP as we determine is necessary to comprehensively and expeditiously resolve the identified non-conformity(ies). We will, however, work with health IT developers to determine the most appropriate elements for CAPs and strive to assist in the creation of CAPs that are no more or less prescriptive than necessary to remedy the non-conformity(ies) quickly and effectively. Comments. Multiple commenters suggested that CAPs as a result of ONC direct review should be based only on non-conformities with existing certification criteria of the Program. Response. In this final rule, a non-conformity is a failure of certified health IT or its developer to conform to the requirements of the Program. We emphasize, as discussed in detail in section II.A.1.a.(1) of this preamble, that Program requirements are not limited to compliance with certification criteria. A CAP will be based on a finding and notice of non-conformity, which necessarily involves a failure to meet Program requirements (Sec. 170.580(c)). Similarly, the elements of the CAP will address the actions a health IT developer must take to correct the identified non-conformity(ies) (i.e., bring its certified health IT back into conformity with the Program requirements that are the basis of the non-conformity(ies)). Comments. A commenter requested that we clarify the criteria necessary for resolving non-conformities under a CAP. Commenters requested that we specify the criteria that would lead to the rejection of a proposed CAP and recommended that we not reject a proposed CAP without giving the health IT developer an opportunity to discuss the issue(s) with ONC. One commenter suggested that ONC institute a process for health IT developers to respond to a rejection of a CAP. Response. We cannot define the specific criteria necessary for resolving non-conformities under a CAP because such criteria will be determined on a case-by-case basis. However, as noted above and in the Proposed Rule, ONC will provide direction to health IT developers as to the required elements of a CAP and will work with health IT developers to develop acceptable CAPs. We note that we have restructured and reordered the required elements for a CAP in the final rule for clarity and to avoid inclusion of redundant factors (see Sec. 170.580(c)(2)). We have also adopted two new elements for CAPs that serves to clarify how a health IT developer would demonstrate the resolution of all non- conformities and issues (a proposed CAP element) and prevent the non- conformity from re-occurring. We discuss these CAP elements below. Comments. A commenter suggested that we allow a health IT developer to request an extension for submitting and completing corrective action in certain cases. Response. ONC will permit health IT developers to submit requests for extension of the 30-day period to submit a CAP and the period ONC allocates for completion of the CAP. In order to make these requests, a health IT developer must submit a written statement to ONC that explains and justifies the extension request. ONC will evaluate each request individually and will make decisions on a case-by-case basis. We have added a provision at Sec. 170.580(c)(5) to reflect this policy. We clarify, however, that ONC may propose to terminate the certification of the health IT under review if, after 90 days of notifying the health IT developer of a non-conformity, ONC is unable to approve a CAP because the health IT developer has not submitted a CAP, proposed or revised, that adequately addresses all required elements of the CAP as determined by ONC (Sec. 170.580(c)(4)). This clarification of the 90-day time limit for approving a CAP aligns with the CAP requirement for ONC-ACBs (Sec. 170.556(d)(5)(ii)). Comments. A few commenters requested that we revise the proposed required CAP elements so that health IT developers are not required to ensure that all issues are resolved. Commenters stated that health IT developers cannot guarantee the absolute resolution regarding a provider's implementation within the required timeframe because some providers may not immediately implement the software update or modify their workflows in all ways necessary to ensure resolution. Response. We have finalized this requirement to ensure that all issues are resolved. The requirement is consistent with the corrective action requirements in Sec. 170.556(d)(3)(iv) and is a necessary requirement for corrective action. In response to the comment recited below regarding the need for more than just reliance on a health IT developer's attestation for verification of a CAP's completion, we have included a new required CAP element that clarifies how health IT developers are expected to meet the requirement to ensure that the non- conformity and all issues are resolved. A health IT developer must include in a CAP a detailed description of the supporting documentation that will be provided to demonstrate that the identified non- conformities and all issues are resolved. When ONC approves the CAP, we may require the supporting documentation to include testing results, independent expert analysis and verification, and/or other appropriate documentation to provide assurance that all issues have been resolved. Further, we understand that provider cooperation and actions must be taken into consideration. Therefore, we clarify that we expect a health IT developer will take and document the reasonable steps it took to ensure that all non-conformities and issues are resolved. We proposed elements that, at a minimum, must be included in a CAP. We received comments regarding the consequences of certification termination and our `certification ban' and `heightened scrutiny' proposals (see the ``Consequences of Certification Termination'' section below) requesting that we ensure sufficient protection for providers affected by non-conformities as well as supporting some form of heightened scrutiny of health IT that had a non-conformity and was subsequently terminated. In consideration of these comments and our stated goals in the Proposed Rule to promote public confidence in certified health IT and ensure the integrity of the Program, we have added a prospective element for CAPs. All CAPs must provide an explanation of, and agreement to execute, the steps that will be prevent the non-conformity from re-occurring. We believe this specific element of a CAP will help prevent reoccurrences of circumstances that led to the non-conformity(ies). This will support the integrity of the Program by addressing not only current problems, but also instituting ``safeguards'' against further problems. Equally important, this CAP element will promote public confidence in certified health IT, including health IT that had a non-conformity. For example, a health IT developer can offer its customers reassurance that not only was the non-conformity corrected, but that steps have also been taken to prevent it from re-occurring. Comments. A commenter suggested that ONC review a Complete EHR or Health IT Module following the [[Page 72434]] completion of a CAP, rather than accepting the attestation as proof of conformity. Response. We have finalized the attestation requirement as proposed. We appreciate the commenter's concern, but believe attestation is an appropriate means for confirming that the health IT developer has fulfilled all of its obligations under the CAP, including curing the identified non-conformities and related deficiencies for all affected customers and taking all reasonable steps to prevent their recurrence. In addition, we emphasize three points. As specified above, a health IT developer must submit, and have approved by ONC, a CAP that includes a detailed description of the supporting documentation that the health IT developer will provide to demonstrate that the identified non-conformities and all issues are resolved. Second, an attestation serves as a binding official statement by the health IT developer. Third, if we later discover that the health IT developer had not acted in the manner attested, we may reinstitute the CAP or proceed to suspend or terminate the certification of the Complete EHR or Health IT Module (see Sec. 170.580(c)(7), (d)(1), and (e)(1)(vi)). Comments. Commenters generally supported reporting CAPs to the CHPL. Multiple commenters stated, however, that the CHPL alone is not an effective means for notifying customers because purchasers will not be in the habit of looking at the CHPL regularly. Commenters suggested that health IT developers should utilize more direct forms of notification. Commenters suggested that health IT developers send ``push'' alerts and notifications. One commenter disagreed with reporting CAPs to the CHPL and expressed concern regarding the disclosure of trademark and proprietary software capabilities and/or functionalities, as well as the potential damage to health IT developers' reputations. Response. We thank commenters for their support of this proposal and for expressing their concerns. We have finalized this requirement as proposed. The reporting of CAP information to the CHPL is already required as specified in the 2015 Edition final rule (80 FR 62714) and at Sec. 170.556(e)(3) and we will continue this approach with CAPs that are a result of ONC direct review. This reporting will alert health IT users, implementers, and purchasers to potential conformity issues in a timely and effective manner. Further, as mentioned above, health IT developers must notify all potentially affected customers of the non-conformity and plan for resolution as part of a CAP. We understand that health IT developers may have concerns regarding disclosure of trademark and proprietary software capabilities and/or functionalities and potential damage to their reputations. To address these concerns, as discussed in the ``Notice of Potential Non- Conformity or Non-Conformity'' section of this final rule above, we will implement safeguards to keep trademark or proprietary information confidential to the extent permissible by federal law. (3) Suspension We proposed in the Proposed Rule that ONC may suspend a certification for similar reasons as allowed for ONC-ACBs, which were discussed in the 2015 Edition final rule (80 FR 62759). Specifically, we proposed that ONC would be permitted to initiate certification suspension procedures for a Complete EHR or Health IT Module for any one of the following reasons: Based on information it has obtained, ONC believes that the certified health IT poses a potential risk to public health or safety or other exigent circumstances exist. More specifically, ONC would suspend a certification issued to any encompassed Complete EHR or Health IT Module of the certified health IT if the certified health IT was, but not limited to: Contributing to a patient's health information being unsecured and unprotected in violation of applicable law; increasing medical errors; decreasing the detection, prevention, and management of chronic diseases; worsening the identification and response to public health threats and emergencies; leading to inappropriate care; worsening health care outcomes; or undermining a more effective marketplace, greater competition, greater systems analysis, and increased consumer choice. Such results would conflict with section 3001(b) of the PHSA, which instructs the National Coordinator to perform the duties in keeping or recognizing a certification program that, among other requirements, ensures patient health information is secure and protected in accordance with applicable law, reduces medical errors, increases efficiency, and leads to improved care and health care outcomes. As discussed in the ``Termination'' section below, we proposed that ONC could terminate a certification on the same basis if it concludes that a certified health IT's non-conformity(ies) cannot be cured; The health IT developer fails to timely respond to any communication from ONC, including, but not limited to: Fact-finding, a notice of potential non-conformity, or a notice of non-conformity; The information provided by the health IT developer in response to any ONC communication, including, but not limited to: Fact- finding, a notice of potential non-conformity, or a notice of non- conformity is insufficient or incomplete; The health IT developer fails to timely submit a proposed CAP that adequately addresses the elements required by ONC; or The health IT developer does not fulfill its obligations under the CAP. We also proposed that ONC may suspend the certification of a Complete EHR or Health IT Module at any time when ONC believes that the certified health IT poses a potential risk to public health or safety, other exigent circumstances exist concerning the product, or due to certain actions or inactions by the product's health IT developer as detailed above. We noted that the processes for ONC-ACBs, as detailed in the 2015 Edition final rule (80 FR 62759), would not be altered by our proposals in the Proposed Rule. Comments. We received many comments regarding our proposed suspension criteria. Multiple commenters supported the suspension criteria as proposed and emphasized the need to protect public health and safety. Other commenters expressed concerns regarding ONC's proposed criteria for suspending the certification of a Complete EHR or Health IT Module. These commenters urged ONC to more clearly define the standards and criteria for suspension and to reserve suspension for particular cases of significant risk to patient health and safety. Commenters also stated that ONC should not suspend certification(s) when a health IT developer is working with ONC and acting in good faith to remedy the non-conformity through a CAP. Response. We thank commenters for their thoughtful comments on this aspect of our proposed suspension process. We agree with commenters that suspension should be limited to situations involving a serious risk to public health or safety, as these are the situations that would require immediate action. Therefore, in consideration of these comments, we have finalized a more limited basis for suspension than proposed. Specifically, ONC may only suspend a certification when ONC has a reasonable belief that the certified health IT may present a serious risk to public health or safety. As explained in section II.A.1.a.(3) of this preamble, in assessing whether there is a serious risk to public health or safety, ONC would [[Page 72435]] consider the nature, extent, and severity of the risk and the conditions giving rise to it, in light of the information available to ONC at the time. Separately, ONC could conclude that certified health IT poses a serious risk to public health or safety were it aware of information calling into question the validity of the health IT's certification. We clarify that ONC would still be able to suspend the certification of the health IT after the health IT developer begins corrective action if it identifies a serious risk to public health or safety. Comments. A commenter suggested that we not have the discretion to suspend a certification of a Complete EHR or Health IT Module at any time. The commenter stated that the reasons provided for suspending certification were too broad and that suspension, in the absence of a final legal or regulatory ruling, confers a presumption of guilt and responsibility on the health IT developer. Response. We have finalized the ability to suspend at any time if such action is necessary to protect public health or safety. We note our response to the previous comment which emphasizes the now limited scope of suspension focusing on risks to public health and safety. We further note, in response to the commenter, that suspension is part of the finalized regulation. Comments. A few commenters requested clarification regarding the distinction between criteria for suspension and termination and how to decide which is appropriate in certain situations. Another commenter recommended that ONC should, as a matter of process, issue a notice of suspension before issuing a notice of termination. Response. As stated in our responses above, at this time, we are choosing to limit our discretion to only suspend a certification when we believe that certified health IT presents a serious risk to public health or safety. This change not only clarifies why ONC would suspend a certification, but also draws a clear distinction between the reasons to suspend and the reasons to terminate a certification as described later in this final rule. This change also means that if ONC finds grounds for suspension, ONC will always first take the step to suspend the certification before initiating termination proceedings. We emphasize, however, that we may proceed with termination without first suspending a certification for other matters as outlined under the ``Scope of Review'' section and the termination provisions in this final rule. Suspension Process We proposed that ONC would issue a notice of suspension when appropriate. We stated that ONC's process for obtaining information to support a suspension could involve, but would not be limited to: Fact- finding; requesting information from an ONC-ACB; contacting users of the health IT; and/or reviewing complaints. We proposed that a suspension would become effective upon the health IT developer's receipt of the notice of suspension. We proposed that the notice of suspension would include, but not be limited to: ONC's explanation for the suspension; the information ONC relied upon to reach its determination; the consequences of suspension for the health IT developer and the Complete EHR or Health IT Module under the Program; and instructions for appealing the suspension. We also stated that the notice of suspension would be sent via certified mail and the official date of receipt would be the date of the delivery confirmation consistent with Sec. 170.505. Comments. Multiple commenters supported the suspension process as proposed. One commenter suggested that ONC implement intermediate solutions short of suspension, such as: Fines or other financial penalties; a requirement that health IT developers bear the costs of repair or transition to another system; or, a clear statement of health IT developers' tort liability for the consequences of non-conformities. Response. We have decided not to implement intermediate ``solutions'' as suggested by the commenter because the purpose of suspension as proposed is to enable ONC to act swiftly to address non- conforming certified health IT that present a serious risk to public health or safety and intermediate ``solutions'' or ``penalties'' would delay such action. Additionally, at present, ONC does not have authority to level fines or other financial penalties in these situations and the liability of a health IT developer to customers, other parties, or other matters is outside the scope of this final rule. Clarifications Regarding Notice of Suspension A notice of suspension will be effective on the date listed in the notice of suspension. We clarify that ONC will issue a notice of potential non-conformity or non-conformity at the same time it issues the notice of suspension. These notices will provide the health IT developer opportunities to respond to the basis for suspension. We further clarify the contents of a notice of suspension. We stated in the Proposed Rule that a notice of suspension would include the information ONC relied upon to reach its determination. We clarify, including in regulation, that the information we were referencing is information ONC provides with, and in support of, its determination. Notification and Publication of Suspension We proposed that a health IT developer would be required to notify its affected and potentially affected customers of the certification suspension in a timely manner. We also proposed that ONC would publicize the suspension on the CHPL to alert interested parties, such as purchasers of certified health IT or programs that require the use of certified health IT. We requested comments on these processes, including how timely a health IT developer should notify affected and potentially affected customers of a suspension and what other means we should consider using for publicizing certification suspensions. Comments. We received many comments on the proposed requirements for notifying affected and potentially affected customers of a suspension. Commenters suggested that a health IT developer should not be required to notify its affected and potentially affected customers of a certification suspension until ONC reaches a final determination and concludes the appeal process. Some commenters requested we clarify the meaning of ``timely manner'' in the context of customer notification. One commenter suggested ONC require health IT developers to notify customers within 10 business days after receipt of the suspension notice. Some commenters supported publicizing suspensions on the CHPL and suggested other mechanisms for notifying customers, such as real-time electronic notifications. A few commenters suggested changes regarding the party that should make a notification of suspension and the party(ies) that should be notified. A commenter suggested that ONC should notify customers of a suspension, as opposed to the health IT developer notifying customers as proposed. The commenter also suggested that ONC notify customers of a health IT developer whose Complete EHR or Health IT Module is being considered for suspension. Another commenter suggested that if notifications of suspension are required, they should be sent to all customers of the product, not just those affected and potentially affected by the non-conformity. [[Page 72436]] Response. We have finalized the notification requirements as proposed with the following clarification. We require that a health IT developer must notify ``all potentially affected customers'' as opposed to ``all affected and potentially affected'' customers as we proposed. We removed ``affected'' in this final rule because all ``affected'' customers would also be considered ``potentially affected'' customers; thus the language was redundant. All potentially affected customers should be notified of suspensions in a timely manner after the effective date of the suspension, regardless of whether a health IT developer is appealing the determination. We believe that ``potentially affected customers'' is the appropriate population for health IT developers to notify and is broad enough to protect customers that are or may be affected by the suspension. We believe a health IT developer is the appropriate party to alert its customers of a suspension as it would know best the potentially affected customers. It would be inappropriate to alert customers of a health IT developer whose Complete EHR or Health IT Module is being considered for suspension because such action might unfairly disadvantage a health IT developer whose Complete EHR or Health IT Module may not warrant suspension after further investigation and consideration. As suspension would be based on a serious risk to public health or safety, we believe it is imperative that customers be aware of the suspension. The notification will permit customers to take immediate action to protect public health and safety; and if the suspension is appealed, provide customers with additional time to consider their options and next steps. We believe ``timely'' is an appropriate term because the timeliness of the notification to all potentially affected customers may vary based on the circumstances of the case. While we believe that ONC must have discretion to address each situation accordingly, we agree with the commenter that notification within 10 days or less of the effective date of the suspension may be reasonable in many circumstances. Last, we maintain that notification via the CHPL is an appropriate and effective step for widespread dissemination of a suspension determination to all stakeholders as the CHPL serves as the authoritative, comprehensive listing of health IT that has been tested and certified under the Program. We will further consider whether other forms of publication and dissemination, such as use of the ONC listserv, would be an appropriate and effective communication tool under the circumstances. Consequences of Suspension We proposed that ONC would issue a cease and desist notice to health IT developers to immediately stop the marketing and sale of the Complete EHR or Health IT Module as ``certified'' under the Program when it suspends the Complete EHR's or Health IT Module's certification. We proposed that in cases of a certification suspension, inherited certified status for the Complete EHR or Health IT Module would not be permitted. We requested comment on whether a health IT developer should only be permitted to certify new Complete EHRs or Health IT Modules while the certification in question is suspended, if such new certification of other Complete EHRs or Health IT Modules would correct the non-conformity for all affected customers. We also requested comment as to whether correcting the non-conformity for a certain percentage of all affected customers or certain milestones demonstrating progress in correcting the non-conformity (e.g., a percentage of customers within a period of time) should be sufficient to lift the prohibition. Comments. Multiple commenters supported our proposed prohibition on the marketing and sale of a Complete EHR or Health IT Module during a suspension. One commenter noted that such a restriction is supportive of safe information systems. Other commenters stated that the prohibition on marketing and sale of the suspended Complete EHR or Health IT Module as ``certified'' is inappropriate and represents significant ``overreach,'' while some commenters stated that it would not be an ``overreach'' if there were a valid patient safety concern. Response. We thank commenters for their thoughtful comments and have finalized the `consequences of suspension' in relation to the Program with the following revision and clarifications. As noted above and in the Proposed Rule, we proposed that ONC would issue a cease and desist notice to health IT developers to immediately stop the marketing and sale of a Complete EHR or Health IT Module as ``certified'' under the Program when it suspends the Complete EHR's or Health IT Module's certification (81 FR 11064). We did not specifically include ``licensing'' as part of this prohibition. However, we believe licensing is a form of product sale as in both cases a health IT developer likely receives some type of compensation. We also note that we specifically discuss licensing of certified health IT in the ``Corrective Action'' section of the Proposed Rule (see 81 FR 11063). Our intention with this cease and desist notice was to protect the health and safety of users by completely prohibiting health IT developers from representing suspended health IT as ``certified.'' Therefore, we have specifically listed ``licensing'' as part of this prohibition to provide additional clarity. Affirmatively adding ``licensing'' to this section is consistent with ONC's intent to cover all the ways in which health IT software is made available to customers in the health IT marketplace, as well as our stated goal throughout the ``Suspension'' section in the Proposed Rule (81 FR 11064) and this final rule to protect public health and safety. As discussed earlier in this section, we have finalized a more limited basis for suspension than proposed, which is that we may only suspend a certification when we believe that the certified health IT presents a serious risk to public health or safety. Thus, by definition, in cases of suspension, ONC will only prohibit the marketing, licensing, and sale of a Complete EHR or Health IT Module when it presents serious risk to public health or safety. We believe this approach is consistent with comments and supports public health and safety. Comments. A few commenters expressed disagreement with our proposal to prohibit inherited status certification for a suspended Complete EHR or Health IT Module, while more commenters expressed disagreement with the possibility of a prohibition on the certification of a health IT developer's new Complete EHRs and Health IT Modules while the certification in question is suspended. Commenters stated that such restrictions are too far-reaching and suspension should only apply to the health IT under review. Some commenters suggested that a prohibition on new testing and certifications should only apply if a product is affected by the non-conforming product or there is reason to believe there is a wider, more pervasive deficiency with the health IT developer. A commenter suggested that our basis for determining progress for lifting the prohibition should be measured against what the health IT developer does to implement corrected products with providers. Response. We have added a provision at Sec. 170.580(d)(5) that bans the certification (which includes all types of certification, such as inherited certified status and gap certification) of any of a health IT developer's health IT if the health IT developer has the certification [[Page 72437]] on one of its products suspended. The suspension would only be lifted if, as determined by ONC, all affected customers have been provided appropriate remediation. As discussed in the Proposed Rule, a ban may incentivize the health IT developer to cure the non-conformity in an efficient manner. As the basis for suspension is now limited to a reasonable belief that the certified health IT presents a serious risk to public health or safety, we believe the ban is now even more essential to motivating a health IT developer to quickly address and correct what we believe to be a serious risk to public health or safety. We refer readers to section II.1.d.(1) of this final rule for further details on meeting the requirement for providing all affected customers with appropriate remediation. Clarification Regarding ``Rescission'' of a Suspension We proposed in the Proposed Rule that ONC would only ``rescind'' a certification suspension if the health IT developer completes all elements of an approved CAP and/or ONC confirms that all non- conformities have been corrected. We have renamed this provision as ``cancellation.'' A suspension can be canceled, at any time, if ONC no longer has a reasonable belief that the certified health IT presents a serious risk to public health or safety. We believe this revised provision for canceling a suspension is appropriate because suspension is limited to situations in which ONC has a reasonable belief that the certified health IT may present a serious risk to public health or safety; therefore, the basis for cancellation is the opposite of the basis for suspension. The basis for establishing that there is no longer reason to believe that the certified health IT presents a serious risk to public health or safety may be based on information ONC obtains or information provided by a health IT developer. It could be for the same reasons as proposed (i.e., the health IT developer completes all elements of an approved CAP and/or ONC confirms that all non-conformities have been corrected) or possibly for other reasons. (4) Termination We proposed that ONC may terminate certifications issued to Complete EHRs or Health IT Modules under the Program if: (1) The health developer fails to timely respond to any communication from ONC, including, but not limited to: (a) Fact-finding; and (b) a notice of potential non-conformity or non-conformity; (2) the information provided by the health IT developer in response to fact-finding, a notice of potential non-conformity, or a notice of non-conformity is insufficient or incomplete; (3) the health IT developer fails to timely submit a proposed CAP that adequately addresses the elements required by ONC as described in section II.A.1.c.(2) of this preamble; (4) the health IT developer does not fulfill its obligations under the CAP developed in accordance with proposed Sec. 170.580(c); or (5) ONC concludes that the certified health IT's non-conformity(ies) cannot be cured. We requested comment on the proposed reasons for termination and on any additional circumstances for which commenters believe termination of a certification would be warranted. Proposed Termination and Termination Comments. A few commenters suggested less severe alternatives to termination, such as a probation period or implementation of intermediate solutions short of termination. Response. We thank commenters for their thoughtful comments. We explain in section II.A.1.c.(1) and (2) of this final rule (and also explained in the Proposed Rule (81 FR 11062-64)) that, prior to termination, ONC affords the health IT developer multiple opportunities to address and correct a non-conformity(ies) through responses to notices of potential non-conformity and/or non-conformity and a CAP. We believe that, if the health IT developer fails to address and correct the non-conformity(ies) at these stages in the direct review process, termination is an appropriate next step. A probation period would not adequately address the non-conforming health IT and/or non-responsive health IT developer in such situations. We emphasize once again that our goal is to work with health IT developers to correct non- conformities and that termination is a last resort. In response to the comments and due to the severity of termination of a certification, we have added a new, intermediate step in the direct review process called ``proposed termination.'' The proposed termination step will provide health IT developers with an additional opportunity to resolve issues regarding a non-conformity prior to termination. We emphasize that the bases for ``proposed termination'' in this final rule are nearly identical to the bases for ``termination'' in the Proposed Rule (81 FR 11084). The only differences are that in this final rule we have clarified that a health IT developer's failure to cooperate with ONC and/or a third party acting on behalf of ONC and a failure to timely submit in writing a proposed CAP are also bases for termination. We clearly stated in the Proposed Rule that these actions are required of health IT developers (see 81 FR 11062-63); therefore, non-compliance with these requirements will serve as a basis for proposed termination. As stated previously in this preamble under the discussion of Sec. 170.505, we will send any notice of proposed termination by certified mail and the official date of receipt will be the date of the delivery confirmation to the address on record. A health IT developer may respond to a notice of proposed termination, but must do so within 10 days of receiving the proposed termination notice and must include appropriate documentation explaining in writing why its certification should not be terminated. ONC will have up to 30 days to review the information submitted by the health IT developer and reach a decision. ONC may extend this timeframe if the complexity of the case requires additional time for ONC review. We have also finalized a provision that requires ONC to respond to the health IT developer's response to a notice of proposed termination within 30 days, unless ONC extends this timeframe due to the complexity of the case. The ONC response will either be to proceed with direct review, cease direct review, or proceed to termination (Sec. 170.580(e)(4)). This requirement aligns with our stated goals in the Proposed Rule of promoting transparency and enhanced communication by providing health IT developers with information about ONC's progress during the direct review process. We refer readers to Sec. 170.580(e) in this final rule for the specific provisions of proposed termination. Comments. Multiple commenters supported the criteria for termination as proposed. Some commenters requested clearer and more substantive standards for termination of a certification. Response. We thank commenters for their support. As discussed in the preceding response, we have finalized the steps health IT developers must take to avoid termination as proposed in the Proposed Rule (81 FR 11065). We believe these criteria are substantive and clear as they describe specific situations of health IT developer inaction and incurable non-conformities in the health IT that would warrant termination by ONC. We also believe these criteria will incentivize health IT developers to cooperate in the direct review process and address non-conformities. Further, in regard to cooperation, we have [[Page 72438]] specifically included, consistent with our proposals in the Proposed Rule, the failure of a health IT developer to cooperate with ONC direct review as a basis for certification termination. Additionally, we believe the addition of the proposed termination step further clarifies our process for terminating a certification. We emphasize that the National Coordinator may terminate a certification if: (i) A determination is made that termination is appropriate after considering the information provided by the health IT developer in response to the proposed termination notice; or (ii) the health IT developer does not respond in writing to a proposed termination notice within the timeframe specified above. We note that the termination provisions have been finalized at Sec. 170.580(f) because of the addition of the ``proposed termination'' step, which has been added to the final regulation at Sec. 170.580(e). Comments. A commenter requested that we define ``timely'' in the context of termination. Response. ``Timely'' is the appropriate term because it accounts for the timeframe for a health IT developer to respond to ONC, submit a CAP, and contact customers. The timeliness of these actions will vary based on the circumstances of the case. Therefore, ONC must have discretion to address each situation on a case by case basis. Termination Process, Notification, and Publication We proposed that a termination would be issued consistent with the processes outlined below, but noted that the proposed termination processes do not change the certification termination processes for ONC-ACBs in Sec. 170.556(6).\12\ We stated that a notice of termination would include, but may not be limited to: ONC's explanation for the termination; the information ONC relied upon to reach its determination; the consequences of termination for the health IT developer and the Complete EHR or Health IT Module under the Program; and instructions for appealing the termination. We proposed that ONC would send a written notice of termination to the agent of record for the health IT developer of the Complete EHR or Health IT Module. We stated that the written termination notice would be sent via certified mail and the official date of receipt would be the date of the delivery confirmation. --------------------------------------------------------------------------- \12\ We note that ONC-ACB ``termination'' actions are technically referred to as ``withdrawals'' of certifications. We explain this distinction in detail in section II.A.d.(1) of this final rule. --------------------------------------------------------------------------- As we proposed for suspension of a certification, the health IT developer must notify the affected and potentially affected customers of the identified non-conformity(ies) and termination of certification in a timely manner. Additionally, we proposed that ONC would publicize the termination on the CHPL to alert interested parties, such as purchasers of certified health IT or entities administering programs that require the use of health IT certified under the Program. We requested comments on these processes, including how timely a health IT developer should notify affected and potentially affected customers of a termination of a Complete EHR's or Health IT Module's certification and what other means we should consider for publicizing certification terminations. Comments. Multiple commenters suggested changes for the proposed process for notifying customers of a termination. Some commenters recommended that health IT developers should not notify customers until ONC reaches a final determination and concludes all appeals. One commenter suggested that health IT developers should send notification to all customers, not just those affected and potentially affected by the non-conformity. Some commenters noted that reporting terminations to the CHPL is not effective and suggested that health IT developers use real-time electronic notifications in addition to reporting to the CHPL. Response. We thank commenters for their thoughtful comments on this aspect of the proposed termination process. We have, however, finalized the notification requirements as proposed with the following clarification. As we clarified for the ``Suspension'' portion of the direct review processes, we require that a health IT developer must notify ``all potentially affected customers'' as opposed to ``all affected and potentially affected'' customers as we proposed. We removed ``affected'' in this final rule because all ``affected'' customers would also be considered ``potentially affected'' customers. All ``potentially affected customers'' should be notified of terminations in a timely manner, regardless of whether a health IT developer is appealing the determination. We believe that this is the appropriate population for health IT developers to notify and is broad enough to protect customers that are or may be affected by the termination. The notification will permit customers to take immediate action, as they deem necessary, coinciding with the termination; and if the termination is appealed, provide customers with additional time to consider their options and next steps. We believe that notification via the CHPL is an appropriate and effective step for widespread dissemination of a termination determination to all stakeholders as the CHPL serves as the authoritative, comprehensive listing of health IT that has been tested and certified under the Program. We will further consider whether other forms of publication and dissemination, such as use of the ONC listserv, would be an appropriate and effective communication tool under the circumstances. We clarify the contents of a notice of termination and, similarly, a notice of proposed termination. We stated in the Proposed Rule that a notice of termination would include the information ONC relied upon to reach its determination. We clarify, including in regulation, that the information we were referencing is information ONC provides with, and in support of, its determination. In addition, as to only the notice of termination, we clarify that the `consequences of termination' in relation to the Program are the consequences specified in Sec. 170.580(f)(3) (notifying potentially affected customers) and in Sec. 170.581 (discussed in more detail in the ``Consequences of Certification Termination'' section of this final rule). Termination Effective Date and Appeal We proposed that the termination of a certification would be effective either upon: (1) The expiration of the 10-day period for filing an appeal as specified in section II.A.1.c.(5) of this preamble, if the health IT developer does not file an appeal; or, if a health IT developer files an appeal, (2) upon a final determination to terminate the certification as described below in the ``Appeal'' section of this preamble. Comments. Many commenters stated that the proposed 10 days to file an appeal following a termination is insufficient, especially if no new information can be included as part of a hearing on appeal. Response. We refer readers to the ``Appeal'' section of this preamble below for our response to this concern. Rescission of a Notice of Termination We have finalized a provision that permits ONC to rescind a determination to terminate a certification before it becomes effective if ONC determines that termination is no longer appropriate. To illustrate, ONC may rescind the determination to terminate on its own initiative or based on information provided by the developer [[Page 72439]] that convinces ONC that the termination decision was made in error or is otherwise no longer appropriate. We have included this provision as part of the termination process in order to address situations where a certification was terminated, but it would be inefficient to proceed through the appeals process or inappropriate to effectuate the termination. This requirement aligns with our stated goals in the Proposed Rule of working with health IT developers, ensuring the integrity of the Program, and promoting transparency. (5) Appeal We proposed that if ONC suspends or terminates a certification for a Complete EHR or Health IT Module, the health IT developer of the Complete EHR or Health IT Module may appeal the determination to the National Coordinator in accordance with the proposed processes outlined below. We proposed that a health IT developer may appeal an ONC determination to suspend or terminate a certification issued to a Complete EHR or a Health IT Module if the health IT developer asserts: (1) ONC incorrectly applied Program methodology, standards, or requirements for suspension or termination; or (2) ONC's determination was not sufficiently supported by the information used by ONC to reach the determination to suspend or terminate a certification. We proposed that a request for appeal of a suspension or termination must be submitted in writing by an authorized representative of the health IT developer whose certified Complete EHR or certified Health IT Module was subject to the determination being appealed. We also proposed that the request for appeal must be filed in accordance with the instructions specified in the notice of termination or notice of suspension. We stated that these instructions for filing a request may include, but would not be limited to, requiring the health IT developer to: (1) Provide a copy of the written determination by ONC to suspend or terminate the certification and any supporting documentation; and (2) explain the reasons for the appeal. We proposed that the appeal request must be submitted to ONC within 10 days of the health IT developer's receipt of the notice of suspension or notice of termination. We proposed that an appeal request would stay the termination of a certification issued to a Complete EHR or Health IT Module until a final determination is reached on the appeal. However, we noted that a request for appeal would not stay a suspension of a Complete EHR or Health IT Module. We proposed that, while an appeal would stay a termination, a Complete EHR or Health IT Module would be prohibited from being marketed or sold as ``certified'' during the stay. This was similar to the proposed effects of a suspension. We proposed that the National Coordinator would assign the appeal to a hearing officer who would adjudicate the appeal on his or her behalf. We stated that the hearing officer may not preside over an appeal in which he or she participated in the initial suspension or termination determination by ONC or has a conflict of interest in the pending matter. We stated in the Proposed Rule that there would be two parties involved in an appeal: (1) The health IT developer that requests the appeal; and (2) ONC. We proposed that the hearing officer would have the discretion to make a determination based on two options: (1) The written record as submitted to the hearing officer by the health IT developer with the appeal filed in accordance with proposed requirements, which would include ONC's written statement and supporting documentation, if provided; or (2) the information described in option 1 and a hearing conducted in-person, via telephone, or otherwise. We specified that the hearing officer would have the discretion to conduct a hearing if he or she: (1) Requires clarification by either party regarding the written record; (2) requires either party to answer questions regarding the written record; or (3) otherwise determines a hearing is necessary. We specified that the hearing officer would neither receive testimony nor accept any new information that was not presented with the appeal request or was specifically and clearly relied upon to reach the determination to suspend or terminate the certification by ONC. We specified that the default process for the hearing officer would be a determination based on option 1 described above. We proposed that once the health IT developer requests an appeal, ONC would have an opportunity to provide the hearing officer with a written statement and supporting documentation on its behalf (e.g., a brief). We stated that the failure of ONC to submit a written statement would not result in any adverse findings against ONC and may not in any way be taken into account by the hearing officer in reaching a determination. We proposed that the hearing officer would issue a written determination to the health IT developer within 30 days of receipt of the appeal, unless the health IT developer and ONC agree to a finite extension approved by the hearing officer. We proposed that the National Coordinator's determination, as issued by the hearing officer, would be the agency's final determination and not subject to further review. We requested comments on the proposed appeal processes. Specifically, we requested comment on whether the allotted time for the hearing officer to issue a written determination should be lessened or lengthened, such as 15, 45, or 60 days. We also requested comment on whether an extension should be permitted and whether it should only be permitted under the extension circumstances proposed or for other reasons and circumstances. Clarification Regarding the Appeal of Concurrent Suspension and Termination We clarify that there may be situations where a certification is both suspended and terminated. For instance, ONC may suspend a certified Complete EHR or Health IT Module because it presents a serious risk to public health or safety. With the certification suspended pending corrective action, ONC may later propose to terminate and subsequently terminate the certification on the basis that the health IT developer did not cooperate with the direct review. In such a situation, the health IT developer must submit two separate statements of intent to appeal and requests for appeal in writing to ONC in accordance with Sec. 170.580(g)(2) in order to appeal the suspension and the termination. We note that, in most cases, a health IT developer's opportunity to appeal a suspension in accordance with Sec. 170.580(g)(3) would lapse prior to ONC's decision to terminate the certification. In these cases (a suspension and termination of the same certification), the hearing officer would issue separate final determinations for the suspension and termination. For instance, the hearing officer may find that ONC terminated the certification prematurely and therefore reverse the termination on that basis, which would reinstate the certification. At the same time, however, the hearing officer may uphold ONC's decision to suspend the certified health IT because, for instance, it posed a serious risk to public health or safety or because the health IT developer failed to timely appeal the suspension. Comments. A commenter stated that the health IT developer should be able to appeal an initial assessment of non-conformity, a CAP, and/or the terms of a CAP. [[Page 72440]] Response. We have finalized an approach that only permits appeals of ONC determinations to suspend or terminate a certification of a Complete EHR or Health IT Module. ONC has the authority to determine whether health IT remains in conformity with voluntary Program requirements. A notice of non-conformity and CAP are remedial steps designed to bring certified health IT back into conformity with Program requirements. Upon an ONC determination to suspend or terminate a certification, we believe a health IT developer should be afforded the opportunity to appeal the determination because of the consequences health IT developers and certified health IT face due to these actions (i.e., the prohibition on the marketing, licensing, and sale of suspended health IT as ``certified'' and the consequences of termination specified in Sec. 170.581) and the likely negative impact this will have on the ability of a health IT developer to sell or license its health IT to providers and consumers, as many HHS programs require participants to have and/or use certified health IT. Comments. Multiple commenters questioned the proposed bases for appeal and suggested that we clarify the requirements. Some commenters requested more specificity in the first basis for appeal. Commenters requested that in order to meet this basis for appeal ONC must first identify and state specifically how it applied Program methodology, standards, and requirements for suspension or termination findings. Commenters also requested that ONC clarify the meaning of ``sufficient support'' in the second basis for appeal. Response. We appreciate the comments on this proposal. We have removed the redundancy in the first basis for appeal by simply stating ``Program requirements.'' We believe that the proposed bases for appealing ONC decisions are now clear and appropriate. The two bases for appeal require that an ONC decision is based on Program requirements for health IT developers and certified health IT and is supported by sufficient information. We describe in the ``Suspension'' and ``Termination'' sections of this final rule that ONC will provide an explanation of the suspension or termination determination in a notice of suspension or notice of termination, as applicable. ONC will also provide information to support its determination and the consequences for the health IT developer and the Complete EHR or Health IT Module under the Program. This information will enable the health IT developer to assess whether ONC has correctly applied Program requirements and whether ONC's determination was sufficiently supported by information provided with the determination. We maintain that ``sufficiently supported'' is an appropriate term to use in the second basis for appeal because information provided with the determination will vary on a case-by-case. We clarify, as we have similarly done in the ``Suspension'' and ``Termination'' sections of this final rule, that this standard conveys that ONC's determination must be supported by information provided with the determination. Accordingly, we have finalized the bases for appeal in Sec. 170.580(g)(1) with the revisions discussed above. Comments. We received many comments regarding the appeal timeframes. Commenters stated that the proposed 10 days to file an appeal following a termination is insufficient, particularly if, as proposed, no new information can be included as part of an appeal hearing. The commenters asserted that collecting appropriate records for the appeal would be time consuming. Many commenters also proposed a two-step process for filing an appeal: (1) Filing a statement of intent to appeal; and (2) filing a request for appeal with supporting documentation. Commenters generally supported the 30-day timeframe for the hearing officer to make a final determination, while some commenters recommended that this timeframe be flexible based on the complexity of each case. Response. We understand commenters' concerns regarding the 10-day period to file an appeal and, therefore, have accepted the commenters' recommendations for a two-step process for filing a statement of intent to appeal and then filing the appeal and supporting documentation. Specifically, in Sec. 170.580(g)(3), we include requirements that a statement of intent to appeal must be filed within 10 days of receipt of the notice of suspension or notice of termination; and an appeal, including all supporting documentation, must be filed within 30 days of the filing of the intent to appeal. In accordance with this two-step process, a termination will become effective upon: (1) The expiration of the 10-day period for filing a statement of intent to appeal if the health IT developer does not file a statement of intent to appeal; (2) the expiration of the 30-day period for filing an appeal if the health IT developer files a statement of intent to appeal, but does not file a timely appeal; or (3) a final determination to terminate the certification if a health IT developer files an appeal (Sec. 170.580(f)(2)(ii)). We thank commenters for their support of the 30-day timeframe for the hearing officer to make a final determination. To provide flexibility for complex cases and unforeseen circumstances, we have finalized the proposal to permit the hearing officer to extend the timeframe for issuing a decision if the health IT developer and ONC agree to a finite extension and it is approved by the hearing officer. We believe this will provide the parties and the hearing officer with necessary flexibility as recommended by commenters. We have revised the proposed `determination by the hearing officer' provision to clarify that the hearing officer will not issue a written determination to the health IT developer if ONC cancels the suspension or rescinds the termination determination (Sec. 170.580(g)(7)). We have described ONC's ability to cancel a suspension and rescind termination determination, as well as ONC's rationale for allowing such actions, in sections II.A.1.c.(3) and (4) of this preamble, respectively. Comments. Multiple commenters disagreed with our proposal that a request for appeal would not stay a suspension of a Complete EHR or Health IT Module. Specifically, commenters stated that the inability of a health IT developer to market and sell a product as ``certified'' while the product is suspended is overly punitive and could have untoward impacts on end-users. Response. We have finalized this requirement as proposed. A request for appeal will not stay a suspension. As discussed in the ``Suspension'' section of this preamble, ONC may now only suspend the certification of health IT if it has a reasonable belief that the certified health IT may present a serious risk to public health or safety. In such situations, ONC must take immediate action to protect customers and incentivize the health IT developer to correct the non- conformity as soon as possible. A stay of a suspension would be inappropriate because it would delay this immediate action. Comments. Many commenters expressed concerns regarding the appointment and qualifications of the hearing officer. Commenters asserted that the hearing officer should not be assigned by the National Coordinator or be selected from within ONC, as this could cause a conflict of interest and raise questions about the impartiality of the hearing officer. Commenters suggested that we clarify the required qualifications for the hearing officer. Commenters also opined that the [[Page 72441]] hearing officer should not make the sole determination on whether to hold a hearing and should not be able to make a determination without a hearing. Response. We have finalized the `appointment of a hearing officer' provisions as proposed with an added requirement and clarifications in response to comments. We understand commenters' concerns regarding the impartiality of the hearing officer and agree that the hearing officer must be an impartial arbiter of appeals. The hearing officer will be chosen by the National Coordinator as the National Coordinator is best situated to identify a hearing officer, whether from within or outside ONC, that can represent him or her and have the requisite skills, qualifications, and knowledge to adjudicate these appeals. As proposed, in order to reduce the potential for conflicts of interest, the hearing officer will not be able to preside over an appeal in which he or she participated in the initial suspension or termination determination by ONC or has a conflict of interest in the pending matter. Additionally, in consideration of commenters' concerns and our commitment to an impartial appeals process, we have added a requirement at Sec. 170.580(g)(5)(ii) that requires a hearing officer to be trained in a nationally recognized ethics code that articulates nationally recognized standards of conduct for hearing officers/officials. For example, an acceptable nationally recognized ethics code is, but is not limited to, the National Association of Hearing Officials' Model Code of Ethics. The decision as to whether to hold a hearing will be left to the discretion of the hearing officer, as he or she will be most familiar with the facts of the case and will be best equipped to make such a determination. Comments. Commenters disagreed with the proposed requirement that the hearing officer will neither receive testimony nor accept any new information that was not presented with the appeal request or was included with the determination. Another commenter suggested we revise the regulation text to clarify that the hearing officer will not receive certain testimony and information. Response. We have finalized the requirement as proposed. This requirement will facilitate the appropriate development of the record prior to appeal, encourage health IT developers to submit a thorough and comprehensive appeal request, and facilitate expeditious resolutions of appeals. However, in consideration of comments, we have finalized a two-step process for filing a statement of intent to appeal and then filing the appeal and supporting documentation, which will afford health IT developers additional time to compile information and records to support their appeals. This process is discussed in more detail above in response to other comments. In consideration of the commenter's request for revised regulation text, we have revised the relevant appeal provision (Sec. 170.580(g)(6)(iii)) to clarify that the hearing officer will not receive witness testimony and new information beyond that which is permitted with filing an appeal and given at a hearing. We have also made clear that the written record includes the ONC determination to suspend or terminate a certification and information to support the issued determination (Sec. 170.580(g)(6)(i)). Comments. Commenters recommended that ONC implement a more formal, multi-round appeals process. Response. Because we provide multiple opportunities for health IT developers to address the bases for ONC actions to suspend and/or terminate the certification of a Complete EHR or Health IT Module, we do not believe a more elaborate appeals process is generally necessary. However, for terminations, we have added another opportunity to resolve the matter through a ``proposed termination'' step that we have finalized in this final rule. The review, determination, and appeal processes in this final rule provide sufficient and equitable opportunities for health IT developers to address non-conformities found in their certified health IT, while ensuring the timely resolution of matters that may pose a serious risk to public health or safety. Comments. Commenters disagreed with the proposal that ONC's failure to submit a written statement will not result in any adverse findings against ONC and may not in any way be taken into account by the hearing officer in reaching a determination. The commenters stated that ONC should be obligated to provide a written statement, including any and all information, analysis, and documentation it used to come to its determination. Additionally, the commenters asserted that this statement should be made available to the health IT developer. Response. We have finalized the requirement substantially as proposed with the following revisions and clarifications. To clarify, if ONC suspends or terminates a certification, ONC will send a notice of suspension or termination, respectively, to the health IT developer (see Sec. 170.580(d)(2) and (f)(2)). As detailed in paragraphs (d)(2)(i) and (f)(2)(i), the notice will include an explanation and information to support ONC's determination. Therefore, we have revised this provision to clearly state that ONC will have an opportunity to provide the hearing officer with an additional written statement and supporting documentation on its behalf that clarifies, as necessary, its determination to suspend or terminate the certification. We have further revised the provision to clarify that not only would the written statement and supporting documentation be included as part of the written record, but it must also be provided to the health IT developer within 15 days of the health IT developer's filing of an intent to appeal. Comments. A commenter stated that ONC's assertion that an appeal determination is final and not subject to further review misstates the reviewability of administrative decisions by federal courts. Response. This provision does not address the reviewability of administrative decisions by federal courts. The purpose of this regulatory provision is to convey that there are no further administrative reviews of the determination. Comments. A commenter expressed concern that health IT developers were not afforded appeal rights for ONC-ACB determinations. The commenter explained that, if there are two different enforcement bodies (ONC and ONC-ACBs) that may make determinations, there should be equal rights for a health IT developer to appeal those determinations. Response. We refer readers to section II.A.1.b of this final rule for an explanation of our decision not to extend appeal rights for ONC- ACB determinations. Comments. A commenter suggested that providers should be included in the appeals process because providers will often make the initial complaint concerning a non-conformity. Response. We encourage providers and other interested stakeholders to contact ONC throughout ONC's direct review with information about non-conformities that would be relevant during ONC's direct review of certified health IT. We do not, however, believe providers should be parties to an appeal. The matters potentially under review relate to the continued conformity of certified health IT to Program requirements that health IT developers have voluntarily accepted as part of certification of their health IT. [[Page 72442]] d. Consequences of Certification Termination We stated in the Proposed Rule that, in general, this rulemaking does not address the consequences of certification termination beyond requirements for recertification. We stated that any consequences of, and remedies for, termination beyond recertification requirements are outside the scope of this rulemaking. Comments. A commenter emphasized that all users of certified health IT, not just those participating in the EHR Incentive Programs, should be taken into account when addressing the consequences of certification termination. Other commenters expressed concern about the impact certification termination could have on providers participating in the EHR Incentive Programs (e.g., with attestation) and other affected programs. These commenters pointed out that providers using a health IT product with a terminated Complete EHR or Health IT Module certification or one under appeal would risk failing to comply with CMS regulations. Commenters recommended that ONC coordinate with CMS to ensure sufficient protection for affected providers. Response. We thank commenters for their feedback. We reiterate as stated above and in the Proposed Rule, that any consequences of, and remedies for, termination beyond recertification requirements are outside the scope of this rulemaking (i.e., final rule). We, however, emphasize that we, and HHS as a whole, are committed to working with all users and providers in cases of termination to mitigate the impact on participants of programs requiring the use of certified health IT, particularly participants in HHS programs. As mentioned earlier under the ``termination'' section of this preamble, we intend to use the CHPL and other appropriate forms of publication and dissemination to notify users of health IT certification terminations.\13\ We will also coordinate with affected HHS programs to facilitate the notification of their participants and to identify and make available appropriate remedies for participants. As noted in the Proposed Rule, CMS has issued a FAQ \14\ for the EHR Incentive Programs informing participants about their options if the health IT they are using to participate in the programs has its certification terminated. --------------------------------------------------------------------------- \13\ As mentioned under the ``suspension'' section of this preamble, we will take the same steps to notify users of health IT that has its certification suspended under the Program. \14\ See CMS EHR Incentive Programs FAQ 12657: https://questions.cms.gov/faq.php?isDept=0&search=decertified&searchType=keyword&submitSearch=1&id=5005. --------------------------------------------------------------------------- We note that an ONC certification termination under appeal stays the termination. This means the health IT remains certified while the appeal is ongoing. Similarly, health IT with a suspended certification as a result of ONC direct review is still certified and could be identified as certified health IT for HHS program purposes. While our goals with this final rule are to enhance Program oversight and health IT developer accountability for the performance, reliability, and safety of certified health IT, we remind stakeholders that we have finalized methods (e.g., CAPs) designed to identify and remedy non- conformities so that health IT can maintain its certification. (1) Certification Ban, Recertification, and Heightened Scrutiny We proposed in the Proposed Rule that a Complete EHR or Health IT Module that has had its certification terminated can be tested and recertified once all non-conformities have been adequately addressed. We proposed that the recertified Complete EHR or Health IT Module (or replacement version) must maintain a scope of certification that, at a minimum, includes all the previously certified capabilities. We proposed that the health IT developer must request permission from ONC to participate in the Program before submitting the Complete EHR or Health IT Module (or replacement version) for testing to an ONC-ATL and recertification (certification) by an ONC-ACB under the Program. As part of its request, we proposed that a health IT developer must submit a written explanation of what steps were taken to address the non- conformities that led to the termination. We also proposed that ONC would need to review and approve the request for permission to participate in the Program before testing and recertification (certification) of the Complete EHR or Health IT Module (or replacement version) can commence under the Program. We proposed in the Proposed Rule that if the Complete EHR or Health IT Module (or replacement version) is recertified (certified), the certified health IT product should be subjected to some form of heightened scrutiny by ONC or an ONC-ACB for a minimum of one year. We requested comments on the forms of heightened scrutiny (e.g., quarterly in-the-field surveillance) and length of time for the heightened scrutiny (more or less than one year, such as six months or two years) of a recertified Complete EHR or recertified Health IT Module (or replacement version) that previously had its certification terminated. We requested comment on whether heightened scrutiny (surveillance or other requirements) should apply for a period of time (e.g., six months, one year, or two years) to all currently certified Complete EHRs or certified Health IT Modules, future versions of either type, and all new certified health IT of a health IT developer that has a product's certification terminated under the Program. We proposed in the Proposed Rule that the testing and certification of any health IT of a health IT developer that has the certification of one of its health IT products terminated under the Program or withdrawn from the Program when the subject of a potential non-conformity (notice of potential non-conformity) or non-conformity would be prohibited (``Program Ban''). We stated that the only exceptions would be if: (1) The non-conformity is corrected and implemented to all affected customers; or (2) the certification and implementation of other health IT by the health IT developer would remedy the non-conformity for all affected customers. We noted in the Proposed Rule that prohibiting the certification of new products, unless it serves to correct the non- conformity for all affected customers, may incentivize a health IT developer to cure the non-conformity. In correcting the non-conformity for all affected customers, we stated that this would not include those customers that decline the correction or fail to cooperate. We requested comment on this proposal, including how the health IT developer should demonstrate to ONC that all necessary corrections were completed. We further requested comment as to whether correcting the non-conformity for a certain percentage of all affected customers or certain milestones demonstrating progress in correcting the non- conformity (e.g., a percentage of customers within a period of time) should be sufficient to lift the prohibition. We discuss the proposals, comments, and our responses below beginning with the ``Program Ban'' proposal. We note that we have renamed the proposed ``Program Ban'' as ``Certification Ban'' (also simply referred to as ``Ban'' in this final rule). This name more accurately aligns with the effect of the Ban, which is to prohibit the certification of health IT. This also assists in clarifying that testing of health IT may still occur, which as discussed below, may be necessary as part of the process of ``reinstatement and remediation of all [[Page 72443]] affected customers.'' We note that we address the ``recertification'' proposal as part of the ``Reinstatement and Remediation for All Affected Customers'' discussion. This approach provides the most clarity regarding the final policies of this final rule. Certification Ban Comments. Many commenters opposed the Ban, stating that it should only apply to health IT that has a non-conformity. Commenters stated that a Ban would prevent timely upgrades, such as delivery of new functionality or necessary enhancements to users. Other commenters supported the Ban. One commenter requested clarification on how health IT developers are defined for the purposes of the Ban, inquiring if the Ban includes corporate subsidiaries of health IT developers and if they are also subject to the Ban. Response. We thank commenters for their input and have finalized this proposal, subject to revisions and clarifications in response to comments. We continue to believe, despite the potential impact on other customers of health IT developers, that prohibiting the certification of health IT, unless it serves to correct the non-conformity, may incentivize a health IT developer to cure non-conformities and remedy the situation for affected customers. Therefore, we have finalized a Certification Ban. We have, however, included revisions both for clarity and to provide more flexibility for health IT developers to meet the requirements for lifting a Certification Ban. These revisions are discussed directly below and in the ``Reinstatement and Remediation for All Affected Customers'' section that follows. We first clarify that ``termination'' in this final rule means an ONC action to ``terminate'' or ``revoke'' the certification status of a Complete EHR or Health IT Module. Conversely, an action by an ONC-ACB to ``terminate,'' ``remove,'' or ``revoke'' the certificate of a Complete EHR or Health IT Module is referred to as ``withdrawal.'' ISO/ IEC 17065 defines the requirements for conformity assessment by ONC- ACBs and defines ``withdrawal'' (as defined in ISO 17000) \15\ as a revocation or cancellation of the statement of conformity.\16\ This occurs in two situations: (1) When an ONC-ACB proactively removes a certification based on its own accord; or (2) when a health IT developer initiates the discontinuation of a product's certification and requests that the ONC-ACB remove the product's certificate. We make the distinction between ``termination'' and ``withdrawal'' to conform with ISO's use of ``withdrawal'' throughout the ISO standards. However, ONC retains use of the term ``termination'' in this final rule because we enforce Program requirements directly, not under delegated authority and not subject to ISO standards, as is the case for ONC-ACBs. We use this new terminology in our explanation of final Ban provisions below, throughout the new Sec. Sec. 170.580 and 170.581, and in revisions to Sec. 170.556(d)(6) that we are finalizing in this final rule to align with ISO/IEC 17065. In Sec. 170.556(d)(6), we changed ``termination'' to ``withdrawal'' and ``terminating'' to ``withdrawing.'' --------------------------------------------------------------------------- \15\ ISO/IEC 17000 (2004). \16\ We note that ISO does not explicitly define ``terminate.'' --------------------------------------------------------------------------- We clarify that the certification of any of a health IT developer's health IT is prohibited when the certification of one or more of the health IT developer's Complete EHRs or Health IT Modules is (1) terminated by ONC under the Program; (2) withdrawn from the Program by an ONC-ACB because the health IT developer requested it to be withdrawn when the health IT developer's health IT was the subject of a potential non-conformity or non-conformity as determined by ONC; (3) withdrawn by an ONC-ACB because of a non-conformity with any of the certification criteria adopted by the Secretary under subpart C of this part; or (4) withdrawn by an ONC-ACB because the health IT developer requested it to be withdrawn when the health IT developer's health IT was the subject of surveillance for a certification criterion or criteria adopted by the Secretary under subpart C of this part, including pending surveillance (e.g., the health IT developer received notice of pending randomized surveillance). This more detailed specification regarding when a Certification Ban applies is consistent with our proposals, including our proposal to apply the Certification Ban to withdrawals completed by ONC-ACBs. We clarify that for ONC-ACBs' withdrawals as specified in (3) and (4) above, the focus is on non-conformities with certification criteria and not non-conformities arising from Sec. Sec. 170.523(k)(1) (disclosure of information about limitations and additional types of costs associated with their certified health IT), 170.523(l) (compliance with rules governing the use of the ONC Certification and Design Mark), or 170.523(n) (submit user complaints to ONC-ACBs). We also clarify that the Certification Ban affects health IT developers participating in the Program, their subsidiaries, and their successors. Reinstatement and Remediation for All Affected Customers Comments. A commenter requested clarification on what qualifies as adequately addressing a non-conformity. We received mixed comments on whether a terminated health IT product (if presented for recertification) should be required to maintain a scope of certification that, at a minimum, includes all the previous certified capabilities. A few commenters supported our proposal, stating that any reduction in scope penalizes providers who may face significant financial penalties, and that physicians rely on their purchased product to best fulfill their practice needs. In contrast, some commenters expressed general opposition to our proposed approach. One commenter recommended that the Certification Ban be lifted once ONC is satisfied with the corrective action rather than be dependent on customer acceptance or adoption of the corrected certified IT or other remedies. Similarly, a couple of other commenters recommended that all users must have the correction available (whether they choose to install or not). One of these commenters contended that decisions to implement patches may dictate when the customer's non-conforming health IT will be corrected for the customer. Response. We have finalized the proposed requirements that a health IT developer must request permission to participate in the Program, explain the steps taken to address the non-conformities that led to the certification termination (or withdrawal), and receive approval from ONC to participate in the Program again. Specifically, for the Certification Ban to be lifted, we require that: (1) A health IT developer must request in writing ONC's permission to participate in the Program; (2) the request must demonstrate that the customers affected by the certificate termination or withdrawal have been provided appropriate remediation; and (3) ONC is satisfied with the health IT developer's demonstration that all affected customers have been provided with appropriate remediation and grants reinstatement into the Program. These requirements are consistent with our proposals and address our primary goal of addressing affected customers, particularly the requirement of appropriate remediation. We discuss the aspects of ``appropriate remediation'' in our responses to comments below. We agree with some commenters that a reduction in scope unfairly penalizes customers who rely on their purchased or licensed certified health IT to best fulfill their practice needs. As stated in [[Page 72444]] the Proposed Rule, health IT is tested and certified to meet adopted certification criteria and requirements. It should continue to meet those certification criteria and requirements when implemented. Therefore, in determining whether a health IT developer has demonstrated that all affected customers have been provided with appropriate remediation, we will require that the scope of certified health IT previously provided to the affected customers be maintained (i.e., a health IT developer must demonstrate, and ONC is satisfied, that all the necessary certified health IT has been made available to affected customers). We note, as discussed in more detail below, that an affected customer can choose alternative means of remediation, which would be sufficient for lifting the Ban. We agree with commenters that the Certification Ban may be lifted once ONC is satisfied that all non-conformities have been addressed and the correction is made available for all affected customers. However, in providing appropriate remediation to affected customers, we acknowledge that there may be other ways for health IT developers to correct situations for customers short of correcting the certified version or providing a replacement certified version. Therefore, we provide that, as determined by ONC, other certified health IT may be made available by the health IT developer that would remedy the non- conformity for all affected customers. This certified health IT may be the health IT of another health IT developer. We also agree with commenters that there may be reasons why a customer does not implement the corrected certified version or other available certified health IT in a timely manner or at all. As noted in the Proposed Rule (81 FR 11066), we will take into consideration customers' responses (e.g., the customer declines or postpones the correction or signs a release of obligation, which may be the result of a financial settlement) when we determine whether a health IT developer has demonstrated that appropriate remediation has been provided to all affected customers. We clarify that ONC has sole discretion to lift a Certification Ban. The Certification Ban shall remain in effect until ONC is satisfied that the health IT developer has taken the required steps to lift the Certification Ban, as described above. If ONC chooses not to lift the Certification Ban, the health IT developer may reapply for reinstatement after taking the necessary actions to address the conditions for reinstatement. Comments. Commenters requested clarification regarding what would be tested and certified upon applying for ``recertification.'' Response. As part of ONC's considerations as to whether to lift the Certification Ban, ONC, or a third party acting on its behalf, may require the health IT presented as replacement certified health IT for affected customers to be tested by an ONC-ATL, particularly if the replacement health IT is a version of the health IT that previously had the non-conformity that led to termination or withdrawal. This may also be the case when one of multiple Health IT Modules used to maintain the same scope of the terminated or withdrawn certified health IT was never the subject of ONC direct review or ONC-ACB surveillance but includes the same capabilities that were connected to the non-conformity (e.g., CPOE capabilities). After passing necessary testing, the health IT could be certified by an ONC-ACB. Comments. A commenter recommended that a health IT developer be required to provide their customer list to ONC and ONC could verify that the correction has been completed for a random selection of users. This commenter also suggested that ONC could alternatively rely on the health IT developer to attest that all installed products have been corrected or are available to users. Response. We agree with the commenter that either approach could be used by ONC to verify that appropriate remediation has been provided for all affected customers. However, as noted above, we will require the health IT developer to demonstrate that all affected customers have been provided with appropriate remediation, which would include listing the form of remediation. We may also randomly or methodically verify this information with affected customers. Heightened Scrutiny Comments. A few commenters recommended that heightened scrutiny only apply to the functionality that was subject of the alleged non- conformity and not to all health IT of a health IT developer. Some commenters requested that we further define heightened scrutiny. A couple of commenters suggested that heightened scrutiny should vary based on the scope of the non-conformity. One commenter supported using multiple forms of heightened scrutiny, including in-the-field surveillance. Two commenters recommended going beyond randomized in- the-field surveillance where the health IT developer would be surveilled more frequently. We received mixed comments as to the length of heightened scrutiny. Some commenters recommended six months, while others recommended one year. Response. We have not finalized our proposal for applying heightened scrutiny at this time because, after consideration of the public comments, we believe that existing procedures already adequately result in ``heightened scrutiny,'' where appropriate. As noted above, it is possible that remediation for customers affected by a termination or withdrawal could consist of providing certified health IT that never had a non-conformity. In such instances, there would be no need for any form of heightened scrutiny. Further and again as noted above, the process of reinstatement will provide an opportunity for ONC to scrutinize any health IT presented for recertification. We also believe that surveillance conducted by ONC-ACBs as part of their routine activities can provide additional scrutiny of ``recertified'' health IT. To this point, ONC-ACBs conducting reactive surveillance (e.g., complaints-based) can take into account whether the health IT at issue was ``recertified'' health IT and whether the nature of the complaint correlates with a prior non-conformity found in the health IT. As for in-the-field surveillance, it could be weighted towards health IT that was ``recertified.'' We note that we have added an element to a CAP that addresses steps to prevent a non-conformity from re-occurring (see the ``Corrective Action'' section earlier in this final rule). (2) ONC-ACB Response to a Non-Conformity We stated in the Proposed Rule that ONC-ACBs are accredited to ISO/ IEC 17065. Section 7.11.1 of ISO/IEC 17065 instructs certification bodies to consider and decide upon the appropriate action to address a non-conformity found, through surveillance or otherwise, in the product the certification body certified.\17\ Section 7.11.1 lists, among other appropriate actions, the reduction in scope of certification to remove non-conforming product variants or withdrawal of the certification. We stated in the Proposed Rule that these are not appropriate responses to a non-conformity under the Program. --------------------------------------------------------------------------- \17\ 45 CFR 170.599(b)(3). --------------------------------------------------------------------------- We proposed in Sec. 170.523 to revise the PoPC for ONC-ACBs, to prohibit [[Page 72445]] ONC-ACBs from reducing the scope of a certification when the health IT is under surveillance or a CAP. The proposed revision addressed two situations: (1) When health IT is suspected of a non-conformity (i.e., under surveillance or surveillance is pending); and (2) when health IT has a non-conformity (i.e., under a CAP). We proposed that a health IT developer's withdrawal of its certified health IT from the Program when the certified health IT is under surveillance, or surveillance is pending, by an ONC-ACB should not be without prejudice (i.e., the health IT developer would be subject to a ``Certification Ban'' of its health IT). We further proposed that the same proposed consequences for health IT and health IT developers related to certification termination under ONC direct review (i.e., all of the Sec. 170.581 proposals) should apply to certification withdrawals issued by ONC-ACBs. We requested comment on these proposals. Reduction in Scope Comments. Some commenters opposed the proposed requirement to maintain the scope of a certification when the health IT is under surveillance or a CAP, while a few commenters supported our proposal. One commenter stated that they believe these requirements could potentially be too prescriptive and could stifle innovation among health IT developers. However, another commenter stated that providers rely on their certified health IT to provide the functionality as represented to them both in general and for the EHR Incentive Programs and allowing a reduction in scope of certification to remove non- conforming product variants after implementation unfairly penalizes providers. Response. We thank commenters for their feedback. To ensure alignment between ONC review and actions and ONC-ACBs' surveillance and actions under the Program, we have finalized our proposal in Sec. 170.523(o) to prohibit the reduction in scope of certified health IT (1) when the certified health IT is suspected of a non-conformity (i.e., under surveillance or surveillance is pending); and (2) when health IT has a non-conformity (i.e., under a CAP). We agree with commenters that, as we stated in the Proposed Rule, a reduction in scope would absolve a health IT developer from correcting a non- conformity. Health IT is tested and certified to meet adopted criteria and requirements. It should continue to meet those criteria and requirements when implemented. If not, the health IT developer should correct the health IT for affected customers or be subjected to certification withdrawal. While we expect that health IT developers would correct the non-conformity in most cases, we do permit various options for health IT developers to address the situation if the health IT certification is withdrawn.\18\ Therefore, we do not agree that the approach is overly prescriptive or that it will stifle innovation. --------------------------------------------------------------------------- \18\ Please also see the options for health IT developers to address certification termination/withdrawal discussed under the ``Certification Ban'' section of the preamble above. --------------------------------------------------------------------------- Voluntary Withdrawal When Suspected of a Non-Conformity Comments. One commenter stated that voluntary withdrawal by a health IT developer might be the most satisfactory action to enable the majority of the health IT to remain viable in the marketplace. Two commenters recommended that we state that a health IT developer's withdrawal of its certified health IT from the Program constitutes an admission of non-conformity. Response. We thank commenters for their feedback. We agree with the commenters that a health IT developer's withdrawal of its certified health IT from the Program could be utilized to avoid a finding of non- conformity. Therefore, we have finalized the proposed consequences for a health IT developer's withdrawal of its certified health IT from the Program when the health IT is suspected of a non-conformity (i.e., under surveillance or surveillance is pending) by an ONC-ACB. Specifically, a health IT developer's health IT would be subject to a Certification Ban as discussed under the ``Certification Ban'' section of the preamble above. Application of Sec. 170.581 to Certification Withdrawals Executed by ONC-ACBs We have finalized the proposed ``Program Ban'' (now called ``Certification Ban''), including application to certification withdrawals executed by ONC-ACBs. We refer readers to the ``Certification Ban, Recertification, and Heightened Scrutiny'' section above for the comments we received on these proposals and the revisions we have made in response to comments. 2. Establishing ONC Authorization for Testing Labs Under the Program; Requirements for ONC-ATL Conduct; and ONC Oversight and Processes for ONC-ATLs a. General Comments on ONC-ATL Approach Comments. Commenters overwhelmingly supported the proposals to establish ONC-ATLs and provide for ONC oversight of ONC-ATLs under the Program. Two commenters stated that they do not support ONC accreditation in addition to current NVLAP accreditation, but expressed support for establishing ``ONC administrative controls'' over the accredited testing labs similar to ONC's oversight of the ONC-ACBs. Some commenters recommended that we include more robust testing or consider outlining a testing framework with appropriate testing methodologies to be utilized by ONC-ATLs. Response. We thank commenters for their support and have finalized the requirements for ONC-ATL status and the framework for ONC oversight of ONC-ATLs under the Program. In response to the two commenters stating that they do not support ``ONC accreditation'' in addition to current NVLAP accreditation, we believe these commenters misinterpreted our proposals as we did not propose any additional ONC accreditation requirements. To clarify, the proposals being finalized in this final rule do not require labs applying for ONC-ATL status to obtain additional accreditation beyond NVLAP accreditation for health IT testing. Further, these new provisions are in line with the commenters' recommendations by providing ONC with ``administrative controls'' over ONC-ATLs in a manner similar to ONC-ACBs by enabling ONC to authorize and have oversight of ONC-ATLs under the Program. We appreciate commenters' recommendations regarding more robust testing and testing frameworks, however, these recommendations are outside the scope of our proposals. b. Regulatory Provisions for Inclusion of ONC-ATLs in the Program The following sections detail each new and amended regulatory provision that we proposed and have finalized for subpart E of part 170, starting with 45 CFR 170.501, in order to include ONC-ATLs as part of the Program. As stated as our intention in the Proposed Rule, for authorization and other processes, we have followed and leveraged all of the processes established for ONC-ACBs. [[Page 72446]] (1) Sec. 170.501 ``Applicability'' We proposed to revise paragraph (a) of Sec. 170.501 to include references to ``applicants for ONC-ATL status,'' ``ONC-ATL,'' and ``ONC-ATL status.'' Comments. Commenters expressed support for the proposed revisions. Response. We thank commenters for their support and have adopted the revisions to Sec. 170.501 as proposed. The revisions make clear that ONC-ATLs are now part of the rules under this subpart. We have also revised Sec. 170.501 to clearly state that this subpart includes requirements related to the direct review processes adopted in this final rule. These references were inadvertently left out of Sec. 170.501 in the Proposed Rule, although they were included elsewhere in the preamble discussion and regulation text. Further, we revised Sec. 170.501 to clarify that accreditation organizations only apply to become an ONC-AA under the Program and not the accreditor for testing under the Program. NVLAP is the permanent accreditor for testing under the Program (see 76 FR 1278). For regulatory clarity, we have reorganized the prior provisions and new provisions into four paragraphs. (2) Sec. 170.502 ``Definitions'' We proposed to revise the definition of the term ``applicant,'' in Sec. 170.502, to include a corresponding reference to ONC-ATL in order for such term to have equal meaning in the case of a testing lab that is applying for ONC-ATL status. We proposed to revise the definition of the term ``gap certification,'' in Sec. 170.502, to include a corresponding reference to ONC-ATL in paragraph (1) of that definition in order to give equal weight to test results issued by an ONC-ATL. We also proposed to add ``under the ONC Health IT Certification Program'' to paragraphs (1) and (2) of the definition to improve the clarity of the definition. We proposed in Sec. 170.502 to define the term ``ONC-Authorized Testing Lab'' or ``ONC-ATL'' to mean an organization or consortium of organizations that has applied to and been authorized by the National Coordinator to perform the testing of Complete EHRs and Health IT Modules to certification criteria adopted by the Secretary in subpart C of this part. Comments. Commenters expressed support for the proposed revisions and additions to Sec. 170.502. Response. We thank commenters for their support and have finalized the revisions and additions to Sec. 170.502 as proposed. (3) Sec. 170.505 ``Correspondence'' We proposed to revise Sec. 170.505 to include references to ONC- ATL as appropriate. Comments. Commenters expressed support for the proposed revisions to this section. Response. We thank commenters for their support and have finalized the revisions to Sec. 170.505 as proposed. This will reflect the addition of an applicant for ONC-ATL status and ONC-ATLs to the Program framework. We also refer readers to section II.A.1.c (``Review Processes'') for further revisions to Sec. 170.505 finalized in this final rule. (4) Sec. 170.510 ``Type of Certification'' We proposed to revise the section heading of Sec. 170.510 to specifically reference the authorization scope of ONC-ACB status. We also proposed to revise the introductory text within this section to more clearly convey that this section is solely focused on applicants for ONC-ACB status. Comments. Commenters expressed support for the proposed revisions. Response. We thank commenters for their support and have finalized the revisions to Sec. 170.510 as proposed. (5) Sec. 170.511 ``Authorization Scope for ONC-ATL Status'' We proposed to establish a new section (Sec. 170.511) to clearly define the scope of the authorization an ``applicant'' testing lab may be able to seek from the National Coordinator. We proposed that such authorization be limited to the certification criteria adopted by the Secretary in subpart C of this part. We proposed that an applicant for ONC-ATL status could seek for the scope of its authorization all certification criteria, a subset of all of the certification criteria (e.g., to support only privacy and security testing), one certification criterion, or a portion of one certification criterion. We stated that the latter two options provide opportunities for entities that may perform industry testing of health IT for limited and/or distinct capabilities (e.g., electronic prescribing) that align with certification criteria to participate in the Program. Comments. Commenters expressed support for the new proposed section for ONC-ATLs. Some commenters recommended ONC permit the acceptance of certification results from an organization that has already performed testing and certification of health IT that are aligned with, or could be aligned with, ONC certification criteria. Response. We thank commenters for their support for the new section and have finalized the section as proposed to support specialized testing and testing efficiencies for health IT. We stated in the Permanent Certification Program final rule, in response to comments, that we did not believe it was appropriate to rely on testing results from laboratories that were not NVLAP-accredited as we could not independently verify the accreditation processes for the testing labs (76 FR 1281). We believe our approach of requiring narrowly scoped NVLAP accreditation and ONC-ATL status for limited testing under the Program (e.g., e-prescribing) provides the efficiencies (i.e., avoid duplicative testing and reduces regulatory burden) that commenters requested, while maintaining ONC oversight and the integrity of certified health IT and the Program. (6) Sec. 170.520 ``Application'' We proposed to reorder the regulatory text hierarchy to reference the ONC-ACB application requirements under Sec. 170.520(a) and then the ONC-ATL application requirements under Sec. 170.520(b). For the ONC-ATL requirements, we proposed that an ONC-ATL applicant would need to seek authorization based on the scope proposed in Sec. 170.511 and follow the proposed set of ONC-ATL application requirements. More specifically, we proposed that the application information include the same general identifying information as for ONC-ACB applicants; the same authorized representative designation; documentation that the applicant has been accredited by NVLAP to ISO/IEC 17025; and a written agreement executed by the authorized representative stating that the applicant will adhere to the PoPC for ONC-ATLs. Comments. Commenters expressed support for the ONC-ATL application requirements. Some commenters noted that NVLAP bases its accreditation of testing labs under the Program on both ISO/IEC 17025 and elements specific to the Program (e.g., test procedure requirements and competencies). One commenter requested that we establish a minimum set of testing documentation for test results. This commenter also requested that we require ONC-ATLs to submit a list of all received complaints on a quarterly basis, which would be the same as the requirement for ONC-ACBs. Response. We thank commenters for their support and have finalized the ONC-ATL application requirements with one clarification based on the comments received. We clarify that ``documentation that confirms that the applicant has been accredited by [[Page 72447]] NVLAP to ISO/IEC 17025'' includes accreditation by NVLAP to health IT competencies and other Program-specific requirements as noted by commenters. To provide this clarity in Sec. 170.520, we have revised paragraph (b)(3) to read ``documentation that confirms that the applicant has been accredited by NVLAP, including to ISO/IEC 17025.'' To ensure uniformity, ONC, NVLAP, the ONC-AA, ONC-ACBs, and accredited testing labs have collaborated and agreed upon a minimum set of documentation that ONC-ATLs shall provide the ONC-ACBs for their certification evaluation, review, and decision. Last, we note that the recommendation to require ONC-ATLs to submit quarterly reports on complaints is outside of the scope of our proposals as we did not propose such a requirement for ONC-ATLs as we did for ONC-ACBs in the 2015 Edition proposed rule. (7) Sec. 170.523 ``Principles of Proper Conduct for ONC-ACBs'' We proposed to revise paragraph (h)(1) of Sec. 170.523 to explicitly include ONC-ATLs as an entity from whom ONC-ACBs would receive test results. We further proposed to modify paragraph (h)(2) of Sec. 170.523 to include a six month time window from the authorization of the first ONC-ATL to permit the continued acceptance by ONC-ACBs of any test results from a NVLAP-accredited testing laboratory. As stated in the Proposed Rule, this approach would provide adequate transition time for ONC-ACBs to continue issuing certifications based on test results for new and revised certification criteria issued by a ``NVLAP- accredited testing laboratory'' and would also serve as a mobilizing date for a testing lab that has not yet applied for ONC-ATL status. We requested comment, however, on the transition period from NVLAP- accredited testing laboratories to ONC-ATLs. Specifically, we requested comment on whether we should alternatively establish that ONC-ACBs may only be permitted to accept any test results from a NVLAP-accredited testing laboratory for a period of time from the effective date of a subsequent final rule. We stated that this approach would provide a more certain timetable for ONC-ACBs compared to the proposed approach, but may not provide sufficient time for all NVLAP-accredited testing laboratories to transition to ONC-ATL status. We also requested comment on whether the transition period should be shorter than six months (e.g., three months) or longer (e.g., nine months) under either the proposed approach or the alternative approach. We proposed in Sec. 170.523(h)(2) to permit the use of test results from a NVLAP-accredited testing laboratory for certifying previously certified health IT to unchanged certification criteria (gap certification) because, as proposed, NVLAP-accredited testing laboratories would be replaced with ONC-ATLs. We stated that this proposal would permit the test results issued by NVLAP-accredited testing laboratories under the Program (e.g., test results for health IT tested to the 2014 Edition) to continue to be used for gap certification. As a related proposal, we proposed to remove references to ONC-ATCBs in Sec. 170.523(h). ONC-ATCBs tested and certified health IT to the 2011 Edition. The 2011 Edition has been removed from the Code of Federal Regulations and ONC-ACBs no longer maintain active certifications for health IT certified to the 2011 Edition. Comments. Commenters expressed support for our proposed revisions to Sec. 170.523 to accommodate inclusion of ONC-ATLs in the Program. One commenter commented on the proposed accredited testing lab to ONC- ATL transition timeframe. The commenter recommended that we adopt a specified timeframe from the effective date of this final rule for NVLAP-accredited testing labs to become authorized as ONC-ATLs rather than a six-month timeframe from the authorization of the first ONC-ATL. Another commenter stated that the removal of reference to ONC-ATCBs could imply that gap certification is not permitted based on the use of test results from a 2011 Edition certification issued by an ONC-ATCB. The commenter recommended that we clarify whether test results used for 2011 Edition certified health IT could be used for the purposes of gap certification. Response. We appreciate commenters' support for our proposed revisions to Sec. 170.523 and have finalized our revisions to include ONC-ATLs and remove references to ONC-ATCBs from the section. We agree with the commenter that the best approach to meet our goal stated in the Proposed Rule of establishing a certain timetable to facilitate the transition for accredited testing labs to ONC-ATLs would be to set a timeframe from the effective date of this final rule for the transition. Therefore, we have established a timeframe of ``six months from the effective date of this final rule'' to provide a more certain timeframe. We believe this timeframe, over eight months from the issuance of this final rule, provides sufficient time to account for any potential delays or unforeseen circumstances (e.g., time and resource conflicts with significant requests for 2015 Edition testing and certification by health IT developers). The removal of reference to ONC-ATCBs was not meant to imply that gap certification is not permitted based on the use of test results from a 2011 Edition certification issued by an ONC-ATCB. Therefore, we have revised the regulation text to add back in specific reference to ONC-ATCBs in Sec. 170.523(h)(3). We believe this step will sufficiently clarify that these test results may still be used for gap certification. We emphasize, however, that granting gap certification has always been at the discretion of an ONC-ACB. We would, however, expect that an ONC-ACB would consider the temporal nature of test results and other relevant changes in the health IT brought forward for gap certification when determining whether to grant gap certification. (8) Sec. 170.524 ``Principles of Proper Conduct for ONC-ATLs'' We proposed to establish, in a new section (Sec. 170.524), a set of PoPC to which ONC-ATLs must adhere, which are similar to the set of rules and conditions for ONC-ACBs. We stated that adherence to these conduct requirements would be necessary for ONC-ATLs to maintain their authorization and to remain in good standing under the Program. As outlined and described in the Proposed Rule, many of the proposed PoPC for ONC-ATLs would remain consistent with those to which ONC-ACBs are already required to adhere. Comments. Commenters expressed support for the new PoPC for ONC- ATLs. Response. We thank commenters for their support and have adopted the new PoPC for ONC-ATLs in Sec. 170.524. Consistent with the clarification we provided for Sec. 170.520, we clarify that the requirement to maintain ``NVLAP accreditation to ISO/IEC 17025'' entails more than just accreditation to ISO/IEC 17025 as NVLAP accredits testing labs to other requirements under the Program. To provide this clarity in Sec. 170.524, we have revised paragraph (a) to read ``Maintain its NVLAP accreditation, including accreditation to ISO/IEC 17025.'' Comments. One commenter stated, in regard to the proposed PoPC allowing ONC to periodically observe testing on site (unannounced or scheduled), that it would be more efficient for ONC staff to try and coordinate with the ONC-ATL for on-site visits since each testing [[Page 72448]] session involves a significant amount of coordination and scheduling. Response. We appreciate the commenter's point, but have retained the discretion in the final PoPC to observe, unannounced, on-site health IT testing. As with the PoPC for ONC-ACBs, we believe the prospect of unannounced visits supports Program compliance monitoring and the overall integrity of the Program. We note, however, that we intend to work with ONC-ATLs, as we do with ONC-ACBs, to provide the necessary notice to conduct useful and efficient on-site observation of health IT testing. (9) Sec. 170.525 ``Application Submission'' We proposed to include reference to an applicant for ONC-ATL status in paragraphs (a) and (b) of Sec. 170.525 to clearly recognize that testing labs would be applying for ONC-ATL status. We proposed the same application rules that apply to applicants for ONC-ACB status. Comments. Commenters expressed support for the proposed addition to this section. Response. We thank commenters for their support and have finalized the inclusion of ``an applicant for ONC-ATL status'' in Sec. 170.525 as proposed. (10) Sec. 170.530 ``Review of Application'' We proposed to revise paragraphs (c)(2), (c)(4), (d)(2), and (d)(3) of Sec. 170.530 to include an ONC-ATL as part of the application review process. Further, in so doing, we proposed to follow all of the same application review steps and processes that we follow for applicants for ONC-ACB status. Comments. Commenters expressed support for the proposed revisions to this section. Response. We thank commenters for their support and have finalized the revisions to Sec. 170.530 as proposed. (11) Sec. 170.535 ``ONC-ACB Application Reconsideration'' We proposed to revise the section heading of Sec. 170.535 to include reference to ONC-ATLs. We also proposed to revise paragraphs (a) and (d)(1) of Sec. 170.535 to equally reference that an ONC-ATL could be part of the application reconsideration process. Further, in so doing, we proposed to follow all of the same application reconsideration steps and processes that we require and follow for applicants for ONC-ACB status. Comments. Commenters supported our proposed revisions to this section. Response. We thank commenters for their support and have finalized the revisions to Sec. 170.535 as proposed. (12) Sec. 170.540 ``ONC-ACB Status'' We proposed to revise the section heading of Sec. 170.540 to include reference to ONC-ATLs. We also proposed to revise paragraphs (a) through (d) of Sec. 170.540 to equally reference an ONC-ATL as part of the rules currently governing the achievement of ONC-ACB status. As stated in the Proposed Rule, these rules would include: The acknowledgement of ONC-ATL status; that an ONC-ATL must prominently and unambiguously identify the scope of its authorization; that ONC-ATL authorization must be renewed every three years; and that ONC-ATL status would expire three years from when it was granted unless renewed. Comments. Commenters supported our proposed revisions to this section. Response. We thank commenters for their support and have finalized the revisions to Sec. 170.540 as proposed. (13) Sec. 170.557 ``Authorized Certification Methods'' We proposed to revise the section heading of Sec. 170.557 to include a reference to ``testing.'' We also proposed to update the regulatory text hierarchy to have paragraph (a) be applicable to ONC- ATLs and paragraph (b) be applicable to ONC-ACBs. Comments. Commenters expressed support for our proposed revisions to this section. Response. We thank commenters for their support and have finalized the proposed revisions to make Sec. 170.557 applicable to ONC-ATLs as we believe the requirement to provide for remote testing for both development and deployment sites is equally applicable to testing labs as it is to certification bodies. (14) Sec. 170.560 ``Good Standing as an ONC-ACB'' We proposed to revise the section heading of Sec. 170.560 to include reference to ONC-ATLs. We also proposed to revise the paragraph hierarchy to make the paragraph (a) requirements applicable to ONC-ACBs (without modification) and to make the paragraph (b) requirements applicable to ONC-ATLs following the same set of three requirements as for ONC-ACBs. Comments. Commenters supported our proposed revisions to the section. Response. We thank commenters for their support and have finalized the revisions to Sec. 170.560 as proposed. We believe mirroring the requirements of Sec. 170.560 between ONC-ACBs and ONC-ATLs provides for consistent administration for both testing and certification under the Program. (15) Sec. 170.565 ``Revocation of ONC-ACB Status'' We proposed to revise the section heading of Sec. 170.565 to include reference to ONC-ATLs. We also proposed to revise paragraphs (a) through (h) to include references to an ONC-ATL, as applicable. We proposed to apply the same oversight paradigm of Type-1 and Type-2 \19\ violations to ONC-ATLs as we apply to ONC-ACBs. We further proposed to follow the same process for ONC-ATLs that is already included in this section for ONC-ACBs. We proposed to specifically add paragraph (d)(1)(iii) for ONC-ATL suspension provisions because the suspension provisions in paragraph (d)(1)(ii) are too specific to ONC-ACBs and simply referencing ONC-ATLs in that paragraph would cause confusion. Similarly, we proposed to specifically add paragraph (h)(3) related to the extent and duration of revocation to clearly divide the rules applicable to ONC-ACBs from those that would be applicable to ONC-ATLs. We explained that this proposed revision would place the current ONC- ACB applicable regulation text in paragraph (h)(2) of this section. --------------------------------------------------------------------------- \19\ Type-2 violations constitute non-compliance with 45 CFR 170.560 (Good standing as an ONC-ACB) (45 CFR 170.565(b)). An ONC- ACB must maintain good standing by: (a) Adhering to the Principles of Proper Conduct for ONC-ACBs; (b) Refraining from engaging in other types of inappropriate behavior, including an ONC-ACB misrepresenting the scope of its authorization, as well as an ONC- ACB certifying Complete EHRs and/or Health IT Module(s) for which it does not have authorization; and (c) Following all other applicable federal and state laws. --------------------------------------------------------------------------- Comments. Commenters expressed support for the proposed revisions and additions to this section. One commenter requested clarification as to whether the timeframes proposed referenced calendar or business days. Another commenter stated that requiring an ONC-ATL or ONC-ACB to submit a written response within three days upon receipt of a notice of proposed suspension seems short since the National Coordinator has five days to respond to an ONC-ATL or ONC-ACB's written response to a notice of proposed suspension. Response. We thank commenters for their support and have finalized the revisions and additions to Sec. 170.565 as proposed. Our approach will enable ONC to treat similar fact-based non-compliance situations equitably among ONC-ACBs and ONC-ATLs. In regard [[Page 72449]] to the requested clarification for the use of ``days,'' we previously adopted the definition of ``day'' or ``days'' in Sec. 170.102 to mean ``calendar day'' or ``calendar days'' (Temporary Certification Program final rule; 75 FR 36162, 36203). As stated in the Permanent Certification Program final rule, we believe suspension could be an effective way to protect purchasers of certified products and ensure patient health and safety. The requirements for an ONC-ATL or ONC-ACB to submit a written response to a proposed suspension within three days supports this goal, while still giving ONC-ACBs and ONC-ATLs an opportunity to respond. The National Coordinator has an additional two days to be able to consider the ONC-ATL or ONC-ACB response in conjunction with the reasons for proposing the suspension. (16) Sec. 170.570 Effect of Revocation on the Certifications Issued To Complete EHRs and Health IT Module(s) We explained in the Proposed Rule that Sec. 170.570 specifies rules applicable to certifications issued to Complete EHRs and/or Health IT Modules in the event that an ONC-ACB has had its status revoked. Section 170.570 includes steps that the National Coordinator can follow if a Type-1 violation occurred that called into question the legitimacy of certifications conducted by the former ONC-ACB. These provisions were put in place to provide clarity to the market about the impact that an ONC-ACB's status revocation would have on certified health IT in use as part of the EHR Incentive Programs. In the context of an ONC-ATL having its status revoked, we did not specifically propose to modify Sec. 170.570 to include a set of rules applicable to such a scenario. We stated that the same provisions were not necessary given the tangible differences between test results for a not yet certified Complete EHR and/or Health IT Module and an issued certification being used by hundreds or thousands of providers for participation in other programs, HHS or otherwise. We did, however, request comment on whether there would be any circumstances in which additional clarity around the viability of test results attributed to a not yet certified Complete EHR and/or Health IT Module would be necessary. We also requested comment as to whether we should include provisions similar to those already in this section to account for an instance where an ONC-ATL has its status revoked as a result of a Type- 1 violation, which calls into question the legitimacy of the test results the ONC-ATL issued and, thus, could call into question the legitimacy of the subsequent certifications issued to Complete EHRs and/or Health IT Modules by a potentially unknowing or deceived ONC- ACB. Comments. The majority of commenters agreed that Sec. 170.570 did not need to be modified for a Complete EHR and/or Health IT Module not yet certified. Commenters stated that if a Complete EHR and/or Health IT Module had not yet been certified and its testing lab had its status revoked, the health IT developer could find another testing lab to complete its testing before certification. A couple of commenters recommended additional provisions for situations where an ONC-ATL is suspended for Type-1 violations (fraud or negligence) affecting the validity of the test results, but not for non-test-related issues (e.g. business practices or failure to report to ONC) that could also cause an ONC-ATL to have its status revoked. Several commenters also requested that we clarify how the National Coordinator would apply recertification requirements for ONC-ATL or ONC-ACB revocation due to a Type-2 violation. Response. We thank commenters for their feedback. While we did not specifically propose to modify Sec. [thinsp]170.570 to include a set of rules applicable to an ONC-ATL having its status revoked, we did request comment on modifying Sec. 170.570 to account for situations where an ONC-ATL has its status revoked as a result of a Type-1 violation, which calls into question the legitimacy of the test results the ONC-ATL issued and, thus, could call into question the legitimacy of the subsequent certifications issued to Complete EHRs and/or Health IT Modules by a potentially unknowing or deceived ONC-ACB. Given the feedback from commenters expressing the need for provisions to address certifications when ONC revokes an ONC-ATL's status and also determines that the test results are unreliable because of fraud or negligence or for other reasons that call into question the legitimacy of the test results the ONC-ATL issued, we have revised Sec. 170.570 to address these situations. We note that Sec. 170.570 does not include the review of health IT certifications by the National Coordinator due to the revocation of ONC-ATL or ONC-ACB status for Type-2 violations. Under this section, the review of health IT certifications by the National Coordinator is limited to revocations based on a ``Type 1 violation that called into question the legitimacy of certifications issued to health IT.'' Comments. Several commenters requested clarification on how the National Coordinator would make an assessment on whether a health IT was ``improperly certified.'' Commenters also requested that ONC evaluate the likelihood that remaining ONC-ACBs would be able to accommodate all requests for recertification within the specified 120- day time period under Sec. 170.570, noting that ONC-ACBs do not always have tremendous flexibility to schedule around other obligations, particularly during busy certification periods. Response. As specified in Sec. 170.570, the National Coordinator would review the facts surrounding the revocation and publish a notice on ONC's Web site if it was determined that Complete EHRs and/or Health IT Module(s) were ``improperly certified.'' We anticipate that this review would be case-specific and dependent on the basis of the revocation. To note, we have revised the regulation text to replace ``improperly certified'' with more accurate terminology. We believe use of ``unreliable testing or certification'' is more accurate and provides clarity for the situations under review as compared to ``improperly tested'' or ``improperly certified,'' particularly in situations where an ONC-ACB unknowingly uses unreliable test results. In the Permanent Certification Program final rule (76 FR 1299- 1300), we stated that programmatic steps, such as identifying ONC- ACB(s) that could be used for recertification, could be taken to assist health IT developers with achieving timely and cost effective recertifications. However, based on our accumulated knowledge of the time it takes for testing and certification under the Program and in response to comments, we acknowledge that there may be circumstances where it may not be possible for ONC-ATLs to accommodate all requests for retesting, as necessary, and ONC-ACBs to accommodate all requests for recertification within the 120-day time period. Accordingly, we have revised Sec. [thinsp]170.570 to permit the National Coordinator to extend the time that the certification status of affected Complete EHRs and/or Health IT Module(s) remains valid as necessary for the proper retesting and recertification of the affected health IT (see Sec. 170.570(c)(2)). B. Public Availability of Identifiable Surveillance Results In the 2014 Edition final rule, for the purposes of increased Program [[Page 72450]] transparency, we instituted a requirement for the public posting of the test results used to certify health IT (77 FR 54271). We also instituted a requirement that a health IT developer publicly disclose any additional types of costs that a provider would incur for using the health IT developer's certified health IT to participate in the EHR Incentive Programs (77 FR 54273-74). Building on these transparency and public accountability requirements for health IT developers, we took steps, in the 2015 Edition final rule, to increase the transparency related to certified health IT through required surveillance, broadened certified health IT disclosure requirements, and enhanced reporting requirements (80 FR 62719-25). For instance, we now require ONC-ACBs to report non-conforming findings and, when necessary, CAP information to the publicly accessible CHPL (80 FR 62725). The purpose of this reporting requirement, as described in the 2015 Edition final rule, is to ensure that health IT users, implementers, and purchasers are alerted to conformity issues in a timely and effective manner, consistent with the patient safety, program integrity, and transparency objectives of the 2015 Edition final rule (80 FR 62716-17). In furtherance of our efforts to increase Program transparency and health IT developer accountability for their certified health IT we proposed in the Proposed Rule to revise Sec. 170.523(i) of the PoPC for ONC-ACBs by adding language that would require ONC-ACBs to make identifiable surveillance results publicly available on their Web sites on a quarterly basis. We stated that these surveillance results would include information such as, but may not be limited to: Names of health IT developers; names of products and versions; certification criteria and Program requirements surveilled; and outcomes of surveillance. We further stated that this information is already collected by ONC-ACBs as part of their surveillance efforts under the Program and should be readily available for posting on their Web sites (81 FR 11070). We clarified in the Proposed Rule that we do not require that publicly posted surveillance results include information that is proprietary, trade secret, or confidential (e.g., ``screenshots'' that may include such information). We noted our expectation that health IT developers and ONC-ACBs would ensure that such information is not posted when making available the proposed information (i.e., but not limited to, names of health IT developers; names of products and versions; certification criteria and Program requirements surveilled; and outcomes of surveillance). We requested public comment on the publication of identifiable surveillance results. Specifically, we requested comment on the types of information to include in the surveillance results and the format (e.g., summarized or unrefined surveillance results) that would be most useful to stakeholders. In addition to the proposal for ONC-ACBs to publish these results quarterly on their Web sites, we requested comment on the value of publishing hyperlinks on the ONC Web site to the surveillance results posted on the ONC-ACBs' Web sites (81 FR 11070). Comments. We received overwhelming support for the publication of identifiable surveillance results by ONC-ACBs. A couple of commenters, however, questioned the benefit of posting conforming results, suggesting the number of results would be too low to be significant. Response. We appreciate commenters' support for the publication of identifiable surveillance results by ONC-ACBs and are finalizing our proposal to make identifiable surveillance results of ONC-ACBs publicly available according to the form, manner, and frequency discussed below. We emphasize that these surveillance results will consist of findings of conformity, which are not currently published on the CHPL. As we stated in the Proposed Rule, the publication of identifiable surveillance results with findings of conformity, much like the publication of non-conformities and CAPs on the CHPL under the 2015 Edition final rule, will help make health IT developers more accountable to the customers and users of their certified health IT. Customers and users will be provided with valuable information about the continued performance (i.e., conformity under the Program) of certified health IT. The identifiable surveillance results will serve to inform providers and others currently using certified health IT as well as those that may consider switching their certified health IT or purchasing certified health IT for the first time. While we expect that the prospect of publicly identifiable surveillance results will motivate some health IT developers to improve their maintenance efforts, we continue to believe that published surveillance results will reassure customers and users of certified health IT that their health IT continues to conform to certification and Program requirements. This is because, based on ONC-ACB surveillance results to date, most of the surveilled certified health IT and health IT developers are maintaining conformity with certification criteria and Program requirements. The publishing of identifiable surveillance results will also provide a more complete context of surveillance in the certified health IT industry; rather than only sharing identifiable non-conforming results, and when applicable, CAPs (see Sec. 170.523(f)). We disagree with the commenters that suggested there may be little value in posting identifiable surveillance results because the number of results will be too low to be of significance. Such surveillance results will include both reactive (e.g., complaints-based) and randomized surveillance results, which over time will establish a surveillance and conformity history of certified health IT. Comments. Commenters generally agreed with the proposed list of information to be included in publicly available surveillance results (i.e., the names of health IT developers; names of products and versions; certification criteria and Program requirements surveilled; and outcomes of surveillance). Several health IT developers suggested that the information listed for publication should be specifically limited to the information identified in the Proposed Rule, which should be a ``ceiling rather than a floor.'' Some commenters also recommended releasing the same type of surveillance results information that is required to be made public as part of CAPs under Sec. 170.523(f)(1)(xxii). Commenters recommended this approach to ensure Program consistency, prevent interim work product or information obtained in the course of surveillance from being disclosed, and prevent the inclusion of proprietary or sensitive information. Most commenters recommended ONC-ACBs provide summary identifiable surveillance results. Some commenters cautioned that ONC-ACBs should clearly indicate that surveillance of specific certified health IT should not imply a problem or potential problem with the health IT. One commenter encouraged ONC to share model forms of how results would be published so that a common understanding of the form, content, and structure is established in advance of their publication. The same commenter also recommended that we engage in outreach with industry, providers, health IT developers, and public interest stakeholders to help them understand and interpret public surveillance information. [[Page 72451]] Commenters expressed support for publishing hyperlinks on the ONC Web site to the quarterly identifiable surveillance results posted on the ONC-ACBs' Web sites. Several commenters also recommended posting the identifiable surveillance results on the CHPL, rather than having them spread across multiple ONC-ACB Web sites. Response. Based on the comments received and the goals of our proposal, as stated above and in the Proposed Rule, we have finalized our proposed approach with the following clarifications. This approach requires the public posting of the information specified in the Proposed Rule (81 FR 11070-71) and the relevant information already required to be posted, when appropriate, on the CHPL as part of a CAP (80 FR 62725). Specifically, the information required to be reported for all surveillance results under this final rule will include: The names of health IT developers; names of products and versions; certification criteria and Program requirements surveilled; identification of the type of surveillance (i.e., reactive or randomized); the dates surveillance was initiated and completed; and the number of sites that were used in randomized surveillance. This information is consistent with the proposed information, the types of information already required to be posted for CAPs (which is more information than we have specified above for quarterly reporting of all identifiable surveillance results), and with commenter feedback. We did not specifically list the identification of the type of surveillance (i.e., reactive or randomized), dates the surveillance was initiated and completed, or the number of sites surveilled as types of information to be reported in the Proposed Rule. However, the Proposed Rule refers to ``continued performance,'' which requires the identification of the dates surveillance was conducted in order to measure performance over a period of time. Additionally, we believe information regarding whether the surveillance was reactive or random and the number of sites that were surveilled will be useful to stakeholders in understanding surveillance results. The Proposed Rule included the `outcome of surveillance' as a specific type of information, but we have determined that it is unnecessary. We note that the outcome of surveillance is implied by definition (surveillance results). Furthermore, outcomes that include identifiable non-conforming surveillance results are already required to be posted on the CHPL. We agree with commenters that requiring the surveillance information to be posted in one location will better serve stakeholders. Allowing ONC-ACBs to post identifiable surveillance results in different locations would create difficulties for stakeholders who would have to search all surveillance results across multiple ONC-ACBs' Web sites. Further, such an approach would not account for an ONC-ACB choosing to exit the Program. Alternatively, as commenters suggested, the CHPL would address these challenges and is consistent with our consideration in the Proposed Rule of having the hyperlinks on the ONC Web site as a means of providing stakeholders with a centralized and more readily available means for accessing the results. The CHPL is housed on the ONC Web site. The posting of surveillance results on the CHPL is responsive to commenter feedback and will prevent stakeholders from having to navigate multiple sites for the surveillance information. This approach will also decrease the burden for ONC-ACBs as they do not have to host and update the surveillance results on their own Web sites. To further reduce the burden for ONC-ACBs, we will also provide guidance to ONC-ACBs on how to most efficiently submit the information to the CHPL. As suggested by comments and consistent with our goal of making identifiable surveillance results accessible and useful to customers and other stakeholders, we are modifying the CHPL. For example, we intend to include a disclaimer clearly indicating that the fact that surveillance was done does not imply a problem with the health IT. However, we note that conducting surveillance is a Program requirement and a required responsibility of an ONC-ACB and it may or may not be based on information indicating a potential problem with the certified health IT. We will make clear that a search of a particular product listed on the CHPL returning no surveillance results would mean that the product has never been surveilled. We also plan to provide other guidance as necessary, such as an explanation of the differences between reactive and random surveillance.\20\ --------------------------------------------------------------------------- \20\ Program guidance can be found on the ONC Web site at https://www.healthit.gov/policy-researchers-implementers/onc-health-it-certification-program-guidance. --------------------------------------------------------------------------- Comments. Commenters expressed support for our proposal to not require the inclusion of certain information that is proprietary, trade secret, or confidential. One commenter stated, however, that it was unclear as to who decides what information is proprietary or a trade secret and suggested that it should be ONC's sole decision and the only reasonable grounds for exclusion should be threats to patient confidentiality. Another commenter expressed concerns that it was unclear how ONC can balance the needs of health IT developers to protect their proprietary information with the desire to provide meaningful information related to surveillance of health IT. Response. We appreciate both the support and concerns raised by commenters. As discussed above, we have specified the types of surveillance results that must be submitted to the CHPL and made public. We do not believe that any of the required information would implicate the release of proprietary, trade secrets, or confidential information. Further, as noted in the Proposed Rule (81 FR 11063), we are confident that the concerns of commenters regarding the disclosure of proprietary or sensitive information will be adequately addressed through appropriate safeguards implemented at the discretion of ONC- ACBs. ONC-ACBs have already been directly and effectively submitting data to the CHPL on certified health IT. They have demonstrated the capability, working with health IT developers, to submit the requisite information while protecting health IT developers' proprietary, trade secret, and confidential information. We expect this will continue with the surveillance results information that must be disclosed as a result of this new requirement. For a more detailed discussion of the safeguards ONC will implement for proprietary information, trade secrets, or confidential information, please see section II.A.1.c.(1), ``Notice of Potential Non-Conformity or Non-Conformity,'' of this final rule. Comments. The majority of commenters expressed support for the proposal that identifiable surveillance results be posted quarterly. One commenter encouraged us to set the quarterly timeframe as a minimum threshold and to consider the value of more frequent publication, such as monthly. Response. We appreciate the comments in support of the proposed requirement that identifiable surveillance results be posted quarterly. We have adopted a quarterly posting requirement, as proposed, but with incorporation of the commenter's recommendation that quarterly posting be the minimum threshold. We believe that submission through the CHPL of the minimum set of data will support [[Page 72452]] the efficient submission of the additional surveillance results and the submission of the results with other data on certified health IT that is required to be submitted more frequently. This will enable ONC-ACBs to submit identifiable surveillance results more frequently if they are available and ready for submission. To provide sufficient time for implementation by ONC and the ONC- ACBs, including necessary revisions to the CHPL to support user- friendly display of the identifiable surveillance results, we anticipate that posting of the first identifiable surveillance results will occur by the end of the first quarter of 2017. This means the identifiable surveillance results for January through March of 2017 would be posted no later than in early April of 2017. As a reminder, certain identifiable non-conforming surveillance results are already submitted to the CHPL on a weekly basis (see Sec. 170.523(f)). This requirement serves to provide consumers and end-users with prompt notification of non-conformities and corrective actions associated with certified health IT. Comments. A few commenters expressed concern that the cost estimate for ONC-ACBs to post all identifiable surveillance results seemed too low, unless there is almost no change to what ONC-ACBs are already doing. The commenters asserted that the volume of updates would be significantly higher than currently required because it would include both conforming and non-conforming results. Response. We appreciate the commenters' concerns. As discussed above, we believe that our adopted approach for making identifiable surveillance results public will be more efficient and less burdensome than proposed. We also refer readers to the ``Regulatory Impact Statement'' section of this final rule for our cost estimates for the reporting of identifiable surveillance results by ONC-ACBs. Comments. A few commenters recommended that we include additional functionality on our Web site (CHPL) so that stakeholders may specifically learn how certified health IT products support interoperability. Commenters asserted that visible, comparative information will give health IT developers an opportunity to understand where performance can be improved to support providers electronically exchange health information. Response. We appreciate the commenters' feedback and will consider the feedback as part of our efforts to support widespread interoperability and electronic health information exchange. While this comment is outside the scope of our proposal, we believe that the quarterly posting of identifiable surveillance results on the CHPL is consistent with the commenters' request. Further, the CHPL currently supports the searching and comparing of certified health IT based on certification criteria. For example, users can search certified health IT listed on the CHPL to determine which health IT is certified to the 2015 Edition ``transitions of care'' certification criterion (Sec. 170.315(b)(1)). This criterion and its included capabilities support interoperability. Alignment of Sec. 170.556(e)(1) With Sec. 170.523(i)(2) We proposed to revise Sec. 170.556(e)(1) for clarity and consistency with Sec. 170.523(i)(2) by adding that the ongoing submission of in-the-field surveillance results to the National Coordinator throughout the calendar year must, at a minimum, be done on a quarterly basis. Comments. A few commenters suggested we adopt the same language in both Sec. 170.523(i)(2) and Sec. 170.556(e)(1), rather than saying both ``quarterly'' and ``rolling.'' Response. We agree with comments and have revised Sec. 170.556(e)(1) to be consistent with Sec. 170.523(i)(2) by stating that the results of in-the-field surveillance must be submitted to the National Coordinator, at a minimum, on a quarterly basis. Annual Summative Report of Surveillance Results We proposed to reestablish a requirement that ONC-ACBs submit an annual summative report of surveillance results to the National Coordinator. We noted in the Proposed Rule that this previous requirement was unintentionally removed in the 2015 Edition final rule when we established a quarterly reporting requirement for surveillance results. Comments. One commenter stated that the annual summative report should function as a general overview of the surveillance activities and the quarterly report should contain more detailed findings. Response. We appreciate the feedback on this proposal and have finalized it as proposed. We intend to provide, as necessary, more specific guidance to ONC-ACBs on submitting the annual summative surveillance report. III. National Technology Transfer and Advancement Act and the Office of Management and Budget Circular A-119 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 \21\ require the use of, wherever practical, standards that are developed or adopted by voluntary consensus standards bodies to carry out policy objectives or activities, with certain exceptions. In the Proposed Rule, we proposed to ``adopt'' one voluntary consensus standard (ISO/IEC 17025) for use in the Program. --------------------------------------------------------------------------- \21\ http://www.whitehouse.gov/omb/circulars_a119. --------------------------------------------------------------------------- Comments. We received no comments on the ISO/IEC 17025 standard as it relates to the NTTAA and OMB Circular A-119. Response. While we stated in the Proposed Rule that we proposed to ``adopt'' ISO/IEC 17025, we clarify that we were not proposing to adopt the standard under our authorities for the purposes of certifying health IT. Rather, consistent with the stated purpose of our proposal provided in the Proposed Rule, we have finalized the use of the ISO/IEC 17025 standard for the accreditation of testing laboratories in the Program. The use of this standard is consistent with the requirements of the NTTAA and OMB Circular A-119. IV. Incorporation by Reference The Office of the Federal Register has established requirements for materials (e.g., standards and implementation specifications) that agencies incorporate by reference in the Federal Register (79 FR 66267; 1 CFR 51.5(b)). Specifically, Sec. 51.5(b) requires agencies to discuss, in the preamble of a final rule, the ways that the materials they incorporate are reasonably available to interested parties and how interested parties can obtain the materials; and summarize, in the preamble of the final rule, the materials they incorporate by reference. Anyone may purchase the standard and we provide a uniform resource locator (URL) for the standard. As required by Sec. 51.5(b), we also provide a summary below of the standard we have adopted and incorporate by reference in the Federal Register. ISO/IEC 17025:2005 General requirements for the competence of testing and calibration laboratories URL: ISO/IEC 17025:2005 (ISO/IEC 17025) is available for purchase on the ISO Web site at: http://www.iso.org/iso/catalogue_detail.htm?csnumber=39883. [[Page 72453]] Summary: Accreditation bodies that recognize the competence of testing and calibration laboratories should use ISO/IEC 17025 as the basis for their accreditation. Clause 4 specifies the requirements for sound management. Clause 5 specifies the requirements for technical competence for the type of tests and/or calibrations the laboratory undertakes. The use of ISO/IEC 17025 will facilitate cooperation between laboratories and other bodies, and assist in the exchange of information and experience, and in the harmonization of standards and procedures. Comments. We received one comment supporting our proposal to use and incorporate by reference the ISO/IEC 17025 standard. Response. As noted under the NTTAA section above, we proposed to ``adopt'' ISO/IEC 17025. However, we clarify that we were not proposing to adopt the standard under our authorities for the purposes of certifying health IT. Rather, consistent with the stated purpose of our proposal provided in the Proposed Rule, we have finalized the use of the ISO/IEC 17025 standard for the accreditation of testing laboratories in the Program and have also incorporated by reference the standard in the Federal Register. Address Change We have updated the address for ONC in the ``incorporation by reference'' sections of the regulations at Sec. Sec. 170.299(a) and 170.599(a) as ONC's address changed in 2015. Reordering of Sec. 170.599(b) We have reordered the listing of standards in Sec. 170.599(b). This reordering is consistent with the procedures of the Office of the Federal Register, which dictate that standards should be listed by the alphanumeric ID (excluding the date) for each standard, and then by the standard date. V. Collection of Information Requirements Under the Paperwork Reduction Act of 1995 (PRA), agencies are required to provide 60-day notice in the Federal Register and solicit public comment on a proposed collection of information before it is submitted to OMB for review and approval. In order to fairly evaluate whether an information collection should be approved by OMB, section 3506(c)(2)(A) of the PRA requires that we solicit comment on the following issues: 1. Whether the information collection is necessary and useful to carry out the proper functions of the agency; 2. The accuracy of the agency's estimate of the information collection burden; 3. The quality, utility, and clarity of the information to be collected; and 4. Recommendations to minimize the information collection burden on the affected public, including automated collection techniques. We solicited comment on these issues in the Proposed Rule (81 FR 11071-11072) for the matters discussed in detail below. A. ONC-AA and ONC-ACBs Under the Program, accreditation organizations that wish to become the ONC-Approved Accreditor (ONC-AA) must submit certain information, organizations that wish to become an ONC-ACB must comply with collection and reporting requirements, and ONC-ACBs must comply with collection and reporting requirements, records retention requirements, and submit annual surveillance plans and annually report surveillance results. In the 2015 Edition proposed rule (80 FR 16894), we estimated fewer than ten annual respondents for all of the regulatory ``collection of information'' requirements that applied to the ONC-AA and ONC-ACBs, including those previously approved by OMB. In the 2015 Edition final rule (80 FR 62733), we concluded that the regulatory ``collection of information'' requirements for the ONC-AA and the ONC- ACBs were not subject to the PRA under 5 CFR 1320.3(c). We further note that the PRA (44 U.S.C. 3518(c)(1)(B)(ii)) exempts the information collections specified in 45 CFR 170.565 that apply to ONC-ACBs, which are collection activities that would occur during administrative actions or investigations involving ONC against an ONC-ACB. Comments. We received no comments specific to the ONC-AA and ONC- ACBs regarding the ``collection of information'' requirements applicable to them or our past determinations. Response. We continue to maintain our past determinations in that we estimate fewer than ten annual respondents for all of the regulatory ``collection of information'' requirements that apply to the ONC-AA and ONC-ACBs and that the ``collection of information'' requirements for the ONC-AA and the ONC-ACBs are not subject to the PRA under 5 CFR 1320.3(c). As previously noted, the PRA (44 U.S.C. 3518(c)(1)(B)(ii)) exempts the information collections specified in 45 CFR 170.565 that apply to ONC-ACBs, which are collection activities that would occur during administrative actions or investigations involving ONC against an ONC-ACB. B. ONC-ATLs In the Proposed Rule, we estimated fewer than ten annual respondents for all of the proposed regulatory ``collection of information'' requirements for ONC-ATLs under Part 170 of Title 45. As stated in the Proposed Rule, for this reason, the regulatory ``collection of information'' requirements for ONC-ATLs under the Program are not subject to the PRA under 5 CFR 1320.3(c). We further noted in the Proposed Rule that the PRA (44 U.S.C. 3518(c)(1)(B)(ii)) exempts the information collections specified in 45 CFR 170.565 that apply to ONC-ATLs, which are collection activities that would occur during administrative actions or investigations involving ONC against an ONC-ATL. We explained in the Proposed Rule that since the establishment of the Program in 2010, there have never been more than six applicants or entities selected for ONC-ATCB or accredited testing lab status. We stated our expectations that there will be no more than eight ONC-ATLs participating in the Program, which included the five accredited testing labs currently operating under the Program and an estimated three more testing labs that may consider becoming accredited and seek ONC-ATL status because of our proposal to permit ONC-ATL status based on health IT testing accreditation to only one certification criterion or a partial certification criterion. We requested comments on these conclusions and the supporting rationale on which they were based. In the Proposed Rule, we specified that the ``collection of information'' requirements that apply to ONC-ATLs are found in Sec. 170.520(b); proposed Sec. 170.524(d) and (f); and Sec. 170.540(c). We estimated the burden hours for these requirements in case our conclusions in the Proposed Rule were found to be misguided based on public comments or for other reasons and to seek comments on the burden hours as a means of informing our regulatory impact analysis (see section VI (``Regulatory Impact Statement'') of this preamble). The estimated total burden hours as specified in the Proposed Rule are expressed in Table 1 below. We explained in the Proposed Rule that the estimated total burden hours were based on an estimated eight respondents (ONC-ATLs) for the reasons noted above and in the Proposed Rule. With similar requirements to ONC-ACBs, we estimated the same number of burden hours for ONC-ATLs to comply with [[Page 72454]] Sec. Sec. 170.520(b) and 170.540(c) as cited in the 2015 Edition proposed rule (80 FR 16894). In the Proposed Rule, we made the same determination for ONC-ATL records retention requirements under proposed Sec. 170.524(f) as we did for the ONC-ACB records retention requirements (i.e., no burden hours) (80 FR 16894). We also estimated two responses per year at one hour per response for ONC-ATLs to provide updated contact information to ONC per Sec. 170.524(d). Table 1--Estimated Annualized Total Burden Hours ---------------------------------------------------------------------------------------------------------------- Code of Federal Number of Average burden Type of respondent Regulations Number of responses per hours per Total burden section respondents respondent response hours ---------------------------------------------------------------------------------------------------------------- ONC-ATL....................... 45 CFR 8 1 1 8 170.520(b). ONC-ATL....................... 45 CFR 8 2 1 16 170.524(d). ONC-ATL....................... 45 CFR 8 n/a n/a n/a 170.524(f). ONC-ATL....................... 45 CFR 8 1 1 8 170.540(c). --------------------------------------------------------------- Total burden hours for all ................ .............. .............. .............. 32 collections of information. ---------------------------------------------------------------------------------------------------------------- Comments. We received one comment from an accredited testing lab suggesting that we increase the burden hours for application submission and general updates of accreditation by a factor of four or more to more accurately reflect time spent by the ONC-ATL due to time spent internally by the organization preparing for the submission. Response. We have accepted the commenter's suggestion and increased the burden hour estimates by a factor of four for relevant requirements as reflected in Table 2 below. The revised estimated costs of these requirements can be found in section VI (``Regulatory Impact Statement'') of this final rule. Table 2--Estimated Annualized Total Burden Hours ---------------------------------------------------------------------------------------------------------------- Code of Federal Number of Average Type of respondent Regulations Number of responses per burden hours Total burden section respondents respondent per response hours ---------------------------------------------------------------------------------------------------------------- ONC-ATL....................... 45 CFR 8 1 4 32 170.520(b). ONC-ATL....................... 45 CFR 8 2 4 64 170.524(d). ONC-ATL....................... 45 CFR 8 n/a n/a n/a 170.524(f). ONC-ATL....................... 45 CFR 8 1 4 32 170.540(c). --------------------------------------------------------------- Total burden hours for all ................ .............. .............. .............. 128 collections of information. ---------------------------------------------------------------------------------------------------------------- We continue to estimate fewer than ten annual respondents for all of the regulatory ``collection of information'' requirements for ONC- ATLs under Part 170 of Title 45. Accordingly, the ``collection of information'' requirements/burden that are associated with this final rule are not subject to the PRA under 5 CFR 1320.3(c). As noted in the Proposed Rule, the PRA (44 U.S.C. 3518(c)(1)(B)(ii)) exempts the information collections specified in 45 CFR 170.565 that apply to ONC- ATLs, which are collection activities that would occur during administrative actions or investigations involving ONC against an ONC- ATL. C. Health IT Developers We proposed in 45 CFR 170.580 that a health IT developer would have to submit certain information to ONC as part of a review of the health IT developer's certified health IT and if ONC took action against the certified health IT (e.g., requiring a CAP to correct a non-conformity or suspending or terminating a certification for a Complete EHR or Health IT Module). However, we concluded in the Proposed Rule that the PRA exempts these information collections because 44 U.S.C. 3518(c)(1)(B)(ii) excludes collection activities during the conduct of administrative actions or investigations involving the agency against specific individuals or entities. Comments. We received no comments specific to the ``collection of information'' requirements applicable to health IT developers and our PRA determination. Response. We continue to maintain that the ``collection of information'' requirements for health IT developers that are associated with this final rule, including providing access to the health IT as clarified earlier in the preamble, are not subject to the PRA under 44 U.S.C. 3518(c)(1)(B)(ii), which excludes collection activities during the conduct of administrative actions or investigations involving the agency against specific individuals or entities. VI. Regulatory Impact Statement A. Statement of Need While ONC-authorized certification bodies (ONC-ACBs) have been delegated authority to issue certifications for health IT on ONC's behalf under the ONC Health IT Certification Program (``Program''), they do not have responsibility to address the full range of requirements applicable to health IT certified under the Program, such as those that may pose a risk to public health or safety and are inconsistent with section 3001(b) of the PHSA. In addition, ONC-ACBs may be unable to effectively administer Program requirements in certain circumstances due to practical challenges. In contrast, ONC is well- positioned to review certified health IT against the full range of requirements under the Program. This final rule is being published to enhance Program oversight by providing a regulatory framework for ONC to directly review of health IT in certain circumstances and to take appropriate responsive actions to address potential [[Page 72455]] non-conformities and non-conformities, including requiring the correction of non-conformities as determined by ONC in health IT certified under the Program and suspending and terminating certifications issued to Complete EHRs and Health IT Modules. This final rule also sets forth processes for ONC to timely and directly address testing issues by enabling ONC to authorize and further oversee ONC-accredited testing laboratories (ONC-ATLs). These processes will serve to align the testing structure with ONC's authorization and oversight of ONC-ACBs. In addition, this final rule will increase the transparency and availability of information about certified health IT through the publication of identifiable surveillance results. The publication of identifiable surveillance results supports further accountability of health IT developers to their customers and users of certified health IT. B. Alternatives Considered We assessed alternatives to our proposed approaches (i.e., ONC's direct review of certified health IT and the authorization and oversight of accredited testing labs (ONC-ATLs)). One alternative would have been to maintain the approach for the Program prior to this final rule in which ONC-ACBs had sole responsibility for issuing and administering certifications in accordance with ISO/IEC 17065, the PoPC for ONC-ACBs, and other requirements of the Program. This approach would also have left the testing structure as it existed before this final rule. A second alternative would have been for ONC to take further responsibility for the testing, certification, and ongoing conformity of health IT with Program requirements by making testing and certification determinations and/or reviewing all determinations made under the Program. We requested comments on our assessment of alternatives and any alternatives that we should also consider. Comments. Some commenters stated that ONC direct review is unnecessary, while other commenters stated that review of certified health IT should be left to ONC-ACBs. Response. As we stated in the Proposed Rule, we continue to believe that adopting either alternative approach would be misguided. The current approach, which relies on ONC-ACBs to review certified health IT and take necessary actions, does not provide a regulatory framework for addressing non-conformities in certified health IT that present a serious risk to public health or safety or that present issues described in Sec. 170.580(a)(2)(ii). As stated in the Proposed Rule, we fully considered the Program structure when initially establishing the Program and have made appropriate modifications as the Program has evolved. These past considerations primarily focused on a market-driven approach for the Program with testing and certification conducted on behalf of ONC and with ONC retaining and establishing direct and indirect oversight over certain activities. We also noted in the Proposed Rule and in this final rule that ONC-ACBs play an integral role in the Program and have the necessary expertise and capacity to effectively administer specific Program requirements. Similarly, accredited testing labs also play an integral role in the Program's success through the testing of health IT. ONC direct review will complement ONC-ACBs' roles under the Program and serve to address matters, for example, beyond their resources and expertise. ONC direct oversight of ONC-ATLs will ensure that, like with ONC-ACBs, testing labs are directly and immediately accountable to ONC for their performance across a variety of Program items that affect the testing of health IT. Overall, the provisions in this final rule serve to enhance the Program by providing more consistency and accountability for Program participants, which will provide greater confidence in certified health IT when it is implemented, maintained, and used. Accordingly, and for the reasons outlined in this final rule, maintaining the Program as it is currently structured is not acceptable. If we did not change the current testing structure, a lack of parity in ONC oversight for testing and certification would continue to exist. ONC direct oversight of ONC-ATLs will ensure that, like with ONC-ACBs, testing labs are directly and immediately accountable to ONC for their performance across a variety of Program items that affect the testing of health IT. For the reasons outlined throughout this final rule, and specifically detailed in section II.A.1, we do not believe that continuing the Program with a framework for only ONC-ACB surveillance of certified health IT is a viable option or alternative. C. Overall Impact We examined the impact of the final rule as required by Executive Order 12866 on Regulatory Planning and Review (September 30, 1993), Executive Order 13563 on Improving Regulation and Regulatory Review (February 2, 2011), the Regulatory Flexibility Act (5 U.S.C. 601 et seq.), section 202 of the Unfunded Mandates Reform Act of 1995 (2 U.S.C. 1532), and Executive Order 13132 on Federalism (August 4, 1999). 1. Executive Orders 12866 and 13563--Regulatory Planning and Review Analysis Executive Orders 12866 and 13563 direct agencies to assess all costs and benefits of available regulatory alternatives and, if regulation is necessary, to select regulatory approaches that maximize net benefits (including potential economic, environmental, public health and safety effects, distributive impacts, and equity). A regulatory impact analysis (RIA) must be prepared for major rules with economically significant effects ($100 million or more in any one year). It has been determined that this final rule is an economically significant rule as the potential costs associated with this final 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 final rule. a. Costs We have identified and estimated the potential monetary costs for health IT developers, ONC-ATLs, the federal government (i.e., ONC), and health care providers as a result of this final rule. We have categorized and addressed costs as follows: (1) Costs for health IT developers to correct non-conformities as determined by ONC; (2) costs for ONC and health IT developers related to an ONC inquiry into certified health IT non-conformities and ONC direct review, including costs for the new ``proposed termination'' step; (3) costs for health IT developers and ONC associated with the appeal process following a suspension/termination of a Complete EHR's or Health IT Module's certification; (4) costs for health care providers to transition to another certified health IT product when the certification of a Complete EHR or Health IT Module that they currently use is terminated; (5) costs for ONC-ATLs and ONC associated with ONC-ATL accreditation, application, renewal, and reporting requirements; (6) costs for ONC- ATLs and ONC related to revoking ONC-ATL status; and (7) costs for ONC- ACBs to submit identifiable surveillance results to the CHPL. We also provide an overall annual monetary cost estimate for the final rule (see (8) Total Annual Cost Estimate). We note that we have rounded all estimates to the nearest dollar and all estimates are expressed in 2016 dollars. [[Page 72456]] Comments on the Proposed Rule General Comments. Commenters expressed concerns that the costs of direct review could flow downstream to health IT developers, health care providers, and ONC-ATLs. Response. We appreciate commenters' concerns and agree that certain stakeholders may incur costs as a result of this final rule. We have, therefore, estimated the direct costs for health IT developers and ONC due to ONC actions stemming from direct review under the provisions of this final rule, such as the costs for health IT developers to respond to a notice of potential non-conformity or notice of non-conformity or to file an appeal of an ONC determination. We have also estimated the indirect costs for health care providers because these costs may arise if ONC were to terminate the certification of health IT being used by health care providers to participate in a program requiring the use of certified health IT. We note that we do not believe there are any costs for ONC-ATLs related to direct review conducted by ONC. Costs for Health IT Developers To Correct Non-Conformities Identified by ONC Comments. A commenter asserted that substantial costs should be attributed to the reassessment of health IT for current conformity and estimated it would take at least 400 hours to perform a gap and risk assessment per product. Response. We stated in the Proposed Rule that some health IT developers may reassess their products for conformity. We also stated in the Proposed Rule (81 FR 11073-74) and maintain that health IT developers should always be ensuring that their products are safe and conducting conformity and safety assessments of their health IT as part of proper quality management. We are unable to project the number of assessments that would occur beyond what is observed under the existing regulatory and market structure. Therefore, we have not included these costs in our quantitative cost estimates. Comments. Some commenters noted that, if ONC alleges non- conformities outside the scope of certification criteria or test procedures, there could be a significant burden for health IT developers to respond to investigations and to change their products. Response. We thank commenters for their thoughtful comments on this aspect of our proposal. We refer readers to section II.A.1.a of this final rule for a detailed discussion of what constitutes a non- conformity. As discussed in more detail in section C.1.a.(1) of this regulatory impact statement, while there would likely be costs to correct a non-conformity found as a result of ONC direct review under the processes outlined in this final rule, it is difficult to project such instances and costs given unpredictability of non-conformity occurrences and the underlying need to correct non-conformities. We have, however, estimated the costs to ONC and health IT developers related to an ONC inquiry into certified health IT non-conformities and ONC direct review in section C.1.a.(2) of this RIA. Costs for ONC and Health IT Developers Related to an ONC Inquiry Into Certified Health IT Non-Conformities and ONC Direct Review Comments. Some commenters suggested that we underestimated the costs to health IT developers, both in terms of dollars and ``softer'' costs, such as negative pressure on innovation. Commenters suggested we estimate the costs for ONC investigations. Commenters also stated that there should be a cost associated with unsubstantiated allegations and complaints. Commenters noted that ONC staff may lack appropriate expertise to conduct investigations. Response. We clarify that the estimates for the review of, and inquiry into, certified health IT includes investigations (see section C.1.a.(2) of this RIA). In consideration of comments and due to the potential complexity of such investigations, we have increased the high end of our estimated range of costs by doubling our original high-end estimate for health IT developers and ONC. The unsubstantiated allegations and complaints noted by the commenters are captured in our low-end range of cost estimates. We appreciate commenters' concerns regarding whether ONC staff will have the expertise to conduct investigations. ONC is evaluating the expertise and capabilities of current ONC staff and, if necessary, will hire additional staff with the requisite expertise and capabilities. However, we have no basis for estimating these potential costs in this RIA. These potential staffing costs will be driven by the volume of ONC direct review situations and the volume of additional responsibilities of ONC staff. Costs for Health IT Developers and ONC Associated With the Appeal Process Following a Suspension/Termination of a Complete EHR's or Health IT Module's Certification Comments. A commenter stated that ONC's estimated costs for a health IT developer to provide required information to appeal a suspension or termination are conservative, and these tasks would require experienced personnel who possess a high degree of technical knowledge. Response. We appreciate the commenter's concern, but maintain that our estimate is reasonable, particularly due to the wide range of hours calculated. We agree with the commenter that compiling information for an appeal will require experienced personnel with technical expertise and we accounted for this expertise by assuming that the expertise of the employee(s) needed to participate in the appeal would be equivalent to a GS-15, Step 1 federal employee. Costs for Health Care Providers To Transition to Another Certified Health IT Product When the Certification of a Complete EHR or Health IT Module That They Currently Use Is Terminated Comments. Commenters were concerned about the financial impact of this final rule on health care providers, specifically the downstream costs for providers to transition to another certified health IT product. Multiple commenters suggested that our estimated average cost per product per health care provider to implement a new certified health IT product of approximately $33,000 is too low. Commenters also noted that the health care provider will probably not get a refund from the health IT developer and will have to acquire and possibly install a new product. A commenter suggested that ONC should account for the costs of labor, retraining employees, and lost productivity, in addition to the licensing and implementation costs of a new product. Another commenter suggested that in addition to direct financial costs of transitioning to another certified health IT product, ONC should calculate the costs associated with errors and inefficiencies caused by the transition. Response. We thank commenters for their thoughtful comments on our cost estimates, but have adopted these estimates as proposed. We agree with commenters that there may be costs associated with the labor, retraining of employees, lost productivity, and errors and inefficiencies caused by the transition, but we have been unable to [[Page 72457]] identify reliable data upon which we could base or revise our cost estimates. The relationship between a provider and a health IT developer will be guided by relevant contracts and licenses. Transition costs will most likely be costs negotiated as part of the health IT transactions and will vary with respect to the complexity of the health IT system and the tear-down, data transfer, and implementation of the new system while still providing patient care. We discuss these relationships and the associated costs in more detail in section C.1.a.(4) of this RIA. Costs for ONC-ATLs and ONC Associated With ONC-ATL Accreditation, Application, Renewal, and Reporting Requirements Comments. A couple of commenters questioned why existing accredited testing labs would incur an $11,000 fee. One accredited testing lab stated that our ATL-specific cost estimates were reasonable. Response. We have adopted the accreditation cost estimates as proposed. On-site assessments are required prior to initial accreditation, during the first renewal year, and every two years thereafter. As such, the current five accredited testing labs would incur the on-site assessment fee once during the initial three-year ONC-ATL authorization period. Based on our consultations with NIST, we estimate a full scope on-site assessment for all criteria required for accreditation will cost approximately $11,000. This is the estimate we have used to calculate the estimated burden. However, we note that these values are approximated and will vary depending on the agreements established between health IT developers and ONC-ATLs. Comments. A couple of commenters suggested that ONC should reevaluate its method for estimating the applicant staff time necessary to prepare and participate in the full scope on-site assessment. Commenters opined that since ONC-ACBs have already gone through this assessment, there should be actual experience data from those ONC-ACBs that could provide a more reliable estimate. Response. Based on information provided by ONC-ACBs, we have revised our estimate for the applicant staff time necessary to prepare and participate in the full scope on-site assessment from 200 hours to 130 hours. Accordingly, we have also revised our cost estimate for a limited scope on-site assessment to 65 hours, which is half the estimate for the full scope on-site assessment. Based on these adjusted estimates for staff time for a GS-15, Step 1 federal employee, we estimate the applicant staff cost for a full scope on-site assessment at $15,956 and the applicant staff cost for a limited scope on-site assessment at $7,978. Comments. We received one comment from an accredited testing lab suggesting that we increase the burden hours for application submission and general updates of accreditation by a factor of four or more to more accurately reflect time spent by the ONC-ATL due to time spent internally by the organization preparing for the submission. Response. We have accepted the commenter's suggestion and increased the burden hour estimates by a factor of four for the following requirements: (1) ONC-ATL application at 45 CFR 170.520(b); (2) reporting changes at 45 CFR 170.524(d); and (3) renewal at 45 CFR 170.540(c). Comments. A couple of commenters noted that we estimated $55,623 as the annualized cost for the first accreditation/application and 3-year authorization and we estimated $84,372 as the annualized cost to renew accreditation, application, and authorization during the first three- year ONC-ATL authorization period. They were confused as to why a renewal cost would be higher than the cost for a new testing lab. Response. We have revised these estimates as described below in the ``Costs to the Applicant/ONC-ATL'' section below. We also clarify that the proposed renewal cost per testing lab ($50,623) is lower than the cost for each new testing lab applicant ($55,623). The reason the annualized cost is higher for renewals than for new applicants is because we initially calculated for five renewals (there are currently five accredited testing labs) and three new applicants. Costs for ONC-ACBs To Submit Identifiable Surveillance Results to the CHPL Comments. A couple commenters suggested that the proposed cost estimate for ONC-ACBs posting identifiable surveillance results of $205 is too low. These commenters suggested that approximately six hours would be required. Response. As discussed in section II.B of this final rule, ONC-ACBs will be required to report the following information for all surveillance results: The names of health IT developers; names of products and versions; certification criteria and Program requirements surveilled; identification of the type of surveillance (i.e., reactive or random); the dates surveillance was initiated and completed; and the number of sites that were used in randomized surveillance. However, in order to reduce the burden on ONC-ACBs, ONC will post surveillance results on the CHPL. This is consistent with our consideration in the Proposed Rule of having the hyperlinks on the ONC Web site as a way of providing stakeholders with a more readily available means for accessing the results. ONC-ACBs will be required to submit the data into the CHPL directly, but will not be required to host and update the data on their own Web sites as proposed. We estimate that submitting identifiable surveillance results on a quarterly basis will further limit the burden on ONC-ACBs, but acknowledge that the expanded scope and volume of surveillance information will require additional time to submit the results to the CHPL than the four hours proposed. Therefore, in response to comments, we estimate that it will take an employee 20 hours annually to report identifiable surveillance results to the CHPL. Cost Estimates The only changes to the cost estimates from the Proposed Rule are: (1) We doubled the high-end estimate for ONC staff time related to ONC's review and inquiry into certified health IT and health IT developer staff time associated with providing ONC with all requested records and documentation that ONC would use to make a suspension and/ or termination determination, including for the new ``proposed termination'' step; (2) based on information provided by ONC-ACBs, we revised our estimate for the applicant staff time necessary to prepare and participate in a full and a limited scope on-site assessment; (3) based on public comments, we increased the burden hour estimates for ONC-ATLs by a factor of four from the estimates in the Proposed Rule for the requirements in 45 CFR 170.520(b) (ONC-ATL application), 45 CFR 170.524(d) (reporting changes to ONC), and 45 CFR 170.540(c) (ONC-ATL status renewal); and (4) we added cost estimates for ONC-ACBs to report identifiable surveillance results to the CHPL. We made employee assumptions about the level of expertise needed to complete the requirements in this section of the final rule. We correlated that expertise with the corresponding grade and step of an employee classified under the General Schedule Federal Salary Classification, relying on the associated employee hourly rates for the Washington, DC locality pay area as published by the Office of Personnel Management. We assumed that an [[Page 72458]] applicant expends one hundred percent (100%) of an employee's hourly wage on benefits and overhead for the employee. Therefore, we doubled the employee's hourly wage to account for benefits. We concluded that a 100% expenditure on benefits is an appropriate estimate based on research conducted by HHS. We used the General Schedule Federal Salary Classification for private sector employee wage calculations because the majority of the tasks and requirements that would be performed by private sector employees do not easily fall within a particular occupational classification identified by the Bureau of Labor Statistics (BLS). For instance, while we estimated costs for specialized testing lab personnel to support accreditation, we also estimated costs for participating in administrative reviews and appeals and reporting certain information to ONC. As noted above, in all instances, we correlated the expertise needed to complete the task or requirement with the corresponding grade and step of a federal employee classified under the General Schedule Federal Salary Classification. (1) Costs for Health IT Developers To Correct Non-Conformities Identified by ONC We acknowledged in the Proposed Rule that this rulemaking may: (1) Lead health IT developers to reassess whether their certified health IT is conforming; and (2) require health IT developers to correct non- conformities found by ONC in their certified health IT. We also stated in the Proposed Rule that the costs to perform either of the above would be determined on a case-by-case basis, likely vary significantly based on various factors, and that we did not have reliable information on which to base costs estimates for these activities (81 FR 11074). We seek to clarify that these statements were made to provide a comprehensive view of all potential costs. However, estimating the prevalence of entities incurring these potential costs that would be attributable to this final rule presents a substantial challenge. There are no new certification requirements in this final rule and health IT developers have already been certified to applicable certification criteria and other Program requirements. Independent of this final rule, health IT developers should still be ensuring that their products are safe and conducting conformity and safety assessments of their health IT as part of proper quality management. These activities are typically a regular cost of doing business to ensure that their certified health IT is not, for example, creating public health and/or safety issues by causing medical errors (see 81 FR 11073-74). If ONC identifies/finds a non-conformity with a certified capability under the direct review processes outlined in this final rule, then the costs to correct the non-conformity are a result of this final rule. However, due to the difficulty of projecting such instances given the underlying need to correct non-conformities, we have not been able to include these costs in our quantitative cost estimates. (2) Costs for ONC and Health IT Developers Related to an ONC Inquiry Into Certified Health IT Non-Conformities and ONC Direct Review ONC has broad discretion to review certified health IT. However, we anticipate that such direct review will be relatively infrequent and will focus on situations that pose a risk to public health or safety. We estimate that a health IT developer may commit, on average and depending on complexity, between 80 and 800 hours of staff time to provide ONC with all requested records, access to the technology as needed, and documentation that ONC would use to conduct the fact- finding, make a non-conformity determination, approve a CAP, and make a suspension and/or termination determination, including the new ``proposed termination'' step. We assumed that the expertise of the employee(s) needed to comply with ONC's requests would be equivalent to a GS-15, Step 1 federal employee. The hourly wage with benefits for a GS-15, Step 1 employee located in Washington, DC is approximately $122.74. Therefore, we estimate the cost for a health IT developer to cooperate with an ONC review and inquiry into certified health IT will, on average, range from $9,819 to $98,192. We note that some health IT developers' costs are expected to be less and some health IT developers' costs are expected to be more than this estimated cost range. In comparison, the BLS average hourly wage for a nonsupervisory employee under the North American Industry Classification System (NAICS) 541511, ``Custom Computer Programming Services,'' is $42.67.\22\ We assumed that, just as with the General Schedule Federal Salary Classification, an applicant expends one hundred percent (100%) of an employee's hourly wage on benefits for the employee. Therefore, we doubled the employee's hourly wage to account for benefits, bringing the average hourly wage with benefits to $85.34. Accordingly, the BLS estimated wages for a health IT developer to cooperate with an ONC review and inquiry into certified health IT will, on average, range from $6,827 to $68,272, which is considerably lower than the General Schedule Federal Salary Classification estimates. We estimate that ONC may commit, on average and depending on complexity, between 20 and 1,200 hours of staff time to complete a review and inquiry into certified health IT. We assumed that the expertise of a GS-15, Step 1 federal employee(s) will be necessary. Therefore, we estimate the cost for ONC to review and conduct an inquiry into certified health IT will, on average, range from $2,455 to $147,288. We note that some reviews and inquiries may cost less and some may cost more than this estimated cost range. --------------------------------------------------------------------------- \22\ See http://beta.bls.gov/dataViewer/view/timeseries/CEU6054151108. --------------------------------------------------------------------------- (3) Costs for Health IT Developers and ONC Associated With the Appeal Process Following a Suspension/Termination of a Complete EHR's or Health IT Module's Certification As discussed in section II.A.1.c.(5) of this final rule's preamble, Sec. 170.580(g) permits a health IT developer to appeal an ONC determination to suspend or terminate a certification issued to a Complete EHR or Health IT Module. We estimate that a health IT developer may commit, on average and depending on complexity, between 80 to 240 hours of staff time to provide the required information to appeal a suspension or termination and respond to any requests from the hearing officer. We assumed that the expertise of the employee(s) needed to participate in the appeal would be equivalent to a GS-15, Step 1 federal employee. The hourly wage with benefits for a GS-15, Step 1 employee located in Washington, DC is approximately $122.74. Therefore, we estimate the cost for a health IT developer to appeal a suspension or termination will, on average, range from $9,819 to $29,458. We note that some health IT developers' costs are expected to be less and some health IT developers' costs are expected to be more than this estimated cost range. In comparison, the BLS average hourly wage with benefits is $85.34. Therefore, the cost for a health IT developer to appeal a suspension or termination using BLS wages will, on average, range from $6,827 to $20,482. We estimate that ONC would commit, on average and depending on complexity, between 200 and 800 hours of staff time to conduct an appeal. This would include the time to represent ONC in the appeal and support the costs [[Page 72459]] for the hearing officer. We assumed that the expertise of a GS-15, Step 1 federal employee(s) will be necessary. Therefore, we estimate the cost for ONC to conduct an appeal will, on average, range from $24,548 to $98,192. We note that some appeals may cost less and some may cost more than this estimated cost range. (4) Costs for Health Care Providers To Transition to Another Certified Health IT Product When the Certification of a Complete EHR or Health IT Module That They Currently Use Is Terminated This cost analysis with regards to health care providers focuses on the direct effects of the termination of a Complete EHR's or Health IT Module's certification under this final rule's provisions as a certification termination would have the greatest potential impact. We note and emphasize that the estimated costs for health care providers as a result of a certification termination could be incurred absent the provisions in this final rule. ONC-ACBs currently have the authority to terminate (and suspend) the certifications of Complete EHRs and Health IT Modules. In this regard, ONC-ACBs have terminated certifications for both Complete EHRs and Health IT Modules. The most recent termination of a certification by an ONC-ACB occurred in June 2016 when a health IT developer failed to submit a CAP related to transparency requirements. No eligible professionals (EPs) attested under the Medicare EHR Incentive Program to using this certified health IT product. Another termination by an ONC-ACB occurred in September 2015 when the certifications of a health IT developer's Complete EHRs and Health IT Modules were terminated for failure to respond and participate in routine surveillance requests.\23\ Only 48 eligible professionals attested under the Medicare EHR Incentive Program to using these certified health IT products. In April 2013, an ONC-ACB terminated the certifications of Complete EHRs and Health IT Modules because they did not meet the required functionality.\24\ Those certified health IT products had no Medicare attestations. Considering that these are the only terminations and impacts over the five years of the Program and consistent with our stated intent to work with health IT developers to correct non-conformities found in their certified health IT under the provisions in this final rule, we maintain that it is highly unlikely that the high end of our estimated costs for health care providers will ever be realized. --------------------------------------------------------------------------- \23\ http://www.hhs.gov/news/press/2015pres/09/20150902c.html. \24\ http://www.hhs.gov/about/news/2013/04/25/certification-for-electronic-health-record-product-revoked.html. --------------------------------------------------------------------------- We estimate the monetary costs that will be sustained by health care providers to transition to another certified health IT product when the certification of a Complete EHR or Health IT Module that they currently use is terminated. We anticipate that health care providers impacted by certification termination will transition to a new certified health IT product due to eventually needing certified health IT to participate in other HHS programs requiring the use of certified health IT (e.g., the EHR Incentive Programs \25\). We calculated the estimated upfront cost for health care providers using the number of known EPs that report under the Medicare EHR Incentive Program using certified Complete EHRs and certified Health IT Modules that would have their certifications terminated multiplied by an estimated average cost per product per provider to implement a new certified health IT product. The estimated average cost per product per provider to implement a new certified health IT product is approximately $33,000. This estimate is consistent with other analyses on average costs.\26\ --------------------------------------------------------------------------- \25\ For health care provider guidance regarding circumstances and options when the health IT they are using to participate in the EHR Incentive Programs has its certification terminated or withdrawn, please see CMS EHR Incentive Programs FAQ 12657: https://questions.cms.gov/faq.php?isDept=0&search=decertified&searchType=keyword&submitSearch=1&id=5005. \26\ A Health Affairs study (http://content.healthaffairs.org/content/30/3/481.abstract) estimated the average cost for EHR implementation at a five-physician practice as $162,000. Dividing by five, the estimated cost per physician is $32,400, which is close to our estimated cost of $33,000 to implement an in-office health IT product. --------------------------------------------------------------------------- This analysis and cost estimates does not include sunk costs during the transition year, such as ongoing maintenance for the health IT product that had its certification(s) terminated and any upfront costs the provider paid for the health IT product. The transition by a health care provider to a new certified health IT product could also include non-sunk costs associated with unwinding contractual matters and technological connectivity, replacement/implementation efforts, training of workforce, and the potential for an operational shut down to effectuate a transition to a replacement technology. In regard to contractual matters, we acknowledge that transitioning to a new certified health IT product following a certification termination may be further complicated by the fact that health care providers may have entered multi-year transactions for a Complete EHR or Health IT Module(s). These costs would likely vary significantly based on the contract and specific situation. Conversely, unlike the cost categories just mentioned, which would tend to make our estimates understate the costs to providers due to a termination of certification, some aspects of certified health IT implementation may be similar across products, thus reducing the costs of transitioning to a new product below the costs incurred in association with the original implementation. We used the following formula to calculate the estimated upfront costs for health care providers to transition to a new product: 1. Number of EPs reporting with a certified Complete EHR or certified Health IT Module that could potentially have its certification terminated 2. #1 multiplied by the average upfront cost per product per health care provider 3. Result of #2 equals the estimated cost for health care providers to replace the certified Complete EHR or certified Health IT Module Applying this formula, we calculated the upper and lower threshold impacts as well as the median and mean impacts of terminating certifications issued to a Complete EHR or Health IT Module(s). We calculated the upper and lower thresholds from the certified Complete EHR and certified Health IT Modules with the greatest and least number of reported attestations to the Medicare EHR Incentive Program, respectively.\27\ The median and mean impacts also were calculated using the number of reported attestations for each product (see table 3 (Cost Impact to Health Care Providers)). We calculated the estimated cost to those health care providers assuming all the health care providers would transition to a new certified health IT product. --------------------------------------------------------------------------- \27\ As of November 30, 2015. [[Page 72460]] Table 3--Cost Impact to Health Care Providers ---------------------------------------------------------------------------------------------------------------- Lower Median Mean Upper ---------------------------------------------------------------------------------------------------------------- Number of EP Attestations....................... 1 24 190 19,692 Calculated Cost................................. $33,000 $792,000 $6,270,000 $649,836,000 ---------------------------------------------------------------------------------------------------------------- We estimate the cost impact of certification termination on health care providers will range from $33,000 to $649,836,000 with a median cost of $792,000 and a mean cost of $6,270,000. (5) Costs to ONC-ATLs and ONC Associated With ONC-ATL Accreditation, Application, Renewal, and Reporting Requirements Costs to the Applicant/ONC-ATL An applicant for ONC-ATL status will be required to submit an application and must be accredited in order to be a qualified ONC-ATL applicant. We estimate there will be between five and eight applicants, five of which are already accredited by NVLAP to ISO/IEC 17025 and up to three new applicants. Any new applicants for ONC-ATL status under the Program will first be required to become accredited by NVLAP to ISO/IEC 17025. We note in section V (``Collection of Information Requirements'') of this final rule that we have increased the burden hour estimates by a factor of four from the estimates in the Proposed Rule for requirements in 45 CFR 170.520(b) (ONC-ATL application), 45 CFR 170.524(d) (reporting changes to ONC), and 45 CFR 170.540(c) (ONC-ATL status renewal). As such, the following cost estimates reflect the associated increase in burden hour estimates. Based on our consultations with NIST, we estimate that it will take approximately 2-5 days for NVLAP to complete a full scope on-site assessment for all criteria required for accreditation at an approximate cost of $11,000. The on-site assessment fee covers the costs incurred by the assessors conducting the on-site assessment such as preparation time, time on-site, and travel costs (e.g. flights, hotel, meals, etc.). Section 170.511 will permit the authorization of ONC-ATLs for testing to one or even a partial certification criterion. Based on our consultations with NIST, this will take at least one day to complete and may reduce the necessary scope and cost of the on-site assessment to approximately $8,000. The current five accredited testing labs will each incur the full scope on-site assessment fee of $11,000, as discussed below. We anticipate the potential three new applicants will each incur a limited scope on-site assessment fee of $8,000, as discussed below. Based on information provided by ONC-ACBs, we estimate the applicant staff time necessary to prepare and participate in the full scope on-site assessment at 130 hours. We estimate the applicant staff time necessary to prepare and participate in the limited scope on-site assessment at 65 hours, which is half the estimate for the full scope on-site assessment. We anticipate that an employee equivalent to a GS- 15, Step 1 federal employee will be responsible for preparation and participation in the accreditation assessment. The hourly wage with benefits for a GS-15, Step 1 employee located in Washington, DC is approximately $122.74. Therefore, we estimate the applicant staff cost for the full scope on-site assessment at $15,956 and the applicant staff cost for the limited scope on-site assessment at $7,978. In comparison, the BLS average hourly wage for a ``Computer and Information Analyst'' under NAICS 541380, Testing Laboratories, is $43.54.\28\ The average hourly wage is $87.08 with the inclusion of benefits. Therefore, the BLS estimate for applicant staff cost for the full scope on-site assessment is $17,416 and the BLS estimate for applicant staff cost for the limited scope on-site assessment is $8,708. We emphasize that the problem with using the BLS information for the ATL classifications and wage estimates is that ONC-ATL duties do not easily fall within a particular occupational classification. For instance, there is not a singular occupational classification under NAICS 541380, Testing Laboratories, that would accurately capture the various tasks performed by ONC-ATLs in the processes described in this final rule. Thus, we used a broad occupation category, ``Computer and Information Analysts,'' for this estimate. --------------------------------------------------------------------------- \28\ See http://www.bls.gov/oes/current/naics5_541380.htm#15-0000. --------------------------------------------------------------------------- We anticipate that ONC-ATLs will incur an estimated $5,000 accreditation administrative/technical support fee each year during the three-year ONC-ATL authorization period.\29\ The accreditation administrative/technical support fee covers costs associated with NVLAP staff under the Program. On-site assessments are required prior to initial accreditation, during the first renewal year, and every two years thereafter. As such, we expect the potential three new applicants will each incur the on-site assessment fee twice during their initial three-year ONC-ATL authorization period and the current five accredited testing labs will incur the on-site assessment fee once during the same period. Further, as stated above, we estimate that each full scope on- site assessment for all criteria will cost approximately $11,000 and each limited scope on-site assessment will cost approximately $8,000. We estimate that staff expertise and cost for renewal is likely to remain consistent at approximately $15,956 for a full scope on-site assessment and $7,978 for a limited scope on-site assessment. We expect that each ONC-ATL will renew its status, meaning it will request reauthorization from ONC to be an ONC-ATL, every three years. --------------------------------------------------------------------------- \29\ See NVLAP Fee Structure, http://www.nist.gov/nvlap/nvlap-fee-policy.cfm. --------------------------------------------------------------------------- After becoming accredited by NVLAP, an applicant for ONC-ATL status will incur minimal costs to prepare and submit an application to the National Coordinator. We estimate that it will take 40 minutes to provide the general information requested in the application, 120 minutes to assemble the information necessary to provide documentation of accreditation by NVLAP, and 80 minutes to review and agree to the PoPC for ONC-ATLs. We note that these time estimates are also accurate for an ONC-ATL to complete the proposed status renewal process. Based on our consultations with NIST, we estimate that an employee equivalent to a GS-9, Step 1 federal employee could provide the required general identifying information and documentation of accreditation status. The hourly wage with benefits for a GS-9, Step 1 federal employee located in Washington, DC is approximately $51.20. We estimate that an employee equivalent to a GS-15, Step 1 federal employee would be responsible for reviewing and agreeing to the PoPC for ONC-ATLs. Therefore, our cost estimate per ONC-ATL for these activities is $300. In comparison, the BLS cost estimate for one hour of work with [[Page 72461]] benefits by a ``Computer and Information Analyst'' is $348. Overall, we estimate the total cost of ONC-ATL accreditation, application, and the first proposed three-year authorization period will be approximately $53,128 and the total cost for up to three new applicants will be approximately $159,384. We assume that ONC-ATLs will remain accredited during the three-year ONC-ATL authorization period. We estimate the total cost for an ONC-ATL to renew its accreditation, application, and authorization during the first three- year ONC-ATL authorization period to be approximately $48,832 and the total renewal cost for all five current ONC-ATLs to be approximately $219,160. Based on our cost estimate timeframe of three years, we estimate the annualized renewal cost to be approximately $73,053. We explain in Sec. 170.524(d) that ONC-ATLs shall report various changes to their organization within 15 days. We estimate an employee equivalent to the Federal Salary Classification of GS-9, Step 1 could complete the transmissions of the requested information to ONC. As specified in section VI.B of this final rule, we estimate two responses per year at four hours per response for ONC-ATLs to provide updated information to ONC per Sec. 170.524(d). Accordingly, we estimate it will cost each ONC-ATL $409.60 annually to meet this requirement. To estimate the highest possible cost, we assumed that the eight applicants we estimate will apply to become ONC-ATLs will become ONC- ATLs. Therefore, we estimate the total annual cost for ONC-ATLs to meet the requirements of proposed Sec. 170.524(d) to be $3,276. In comparison, using the BLS wages, we estimate the total annual cost for ONC-ATLs to meet the requirements of proposed Sec. 170.524(d) to be $5,573. We explain in Sec. 170.524(f) that ONC-ATLs shall retain all records related to the testing of Complete EHRs and Health IT Modules to an edition of certification criteria for a minimum of three years from the effective date that removed the applicable edition from the Code of Federal Regulations. Based on our consultations with NIST, we concluded that this time period is in line with common industry practices. Consequently, it does not represent an additional cost to ONC-ATLs. Costs to ONC We estimate the cost to develop the ONC-ATL application to be $522 based on the five hours of work we believe it would take a GS-14, Step 1 federal employee to develop an application form. The hourly wage with benefits for a GS-14, Step 1 employee located in Washington, DC is approximately $104.34. We also anticipate that there will be costs associated with reviewing applications under the Program. We expect that a GS-15, Step 1 federal employee will review the applications and ONC (or a designated representative) will issue final decisions on all applications. We anticipate that it will take approximately 20 hours to review and reach a final decision on each application. This estimate assumes a satisfactory application (i.e., no formal deficiency notifications) and includes the time necessary to verify the information in each application and prepare a briefing for the National Coordinator. We estimate the cost for the application review process to be $2,455. As a result, we estimate ONC's overall cost of administering the entire application process to be approximately $2,977. Based on our cost estimate timeframe of three years, we estimate the annualized cost to ONC to be $992. These costs will be the same for a new applicant or ONC-ATL renewal. As discussed in this final rule's preamble, we will also post the names of applicants granted ONC-ATL status on our Web site. We note that there will be minimal cost associated with this action and estimate the potential cost for posting and maintaining the information on our Web site to be approximately $446 annually. This amount is based on a maximum of six hours of work for a GS-12, Step 1 federal employee. The hourly wage with benefits for a GS-12 Step 1 federal employee located in Washington, DC is $74. We note that there will be minimal cost associated with recording and maintaining updates and changes reported by the ONC-ATLs. We estimate an annual cost to the federal government of $743. This amount is based on ten hours of yearly work of a GS-12, Step 1 federal employee. (6) Costs for ONC-ATLs and ONC Related To Revoking ONC-ATL Status Costs to the ONC-ATL We have revised Sec. 170.565 to apply the same process for ONC-ATL status revocation as applies to ONC-ACBs. We estimate that an ONC-ATL may commit, on average and depending on complexity, between 20 and 160 hours of staff time to provide responses and information requested by ONC. We assume that the expertise of the employee(s) needed to comply with ONC's requests will be equivalent to a GS-15, Step 1 federal employee. The hourly wage with benefits for a GS-15, Step 1 employee located in Washington, DC, is approximately $122.74. Therefore, we estimate the cost for an ONC-ATL to comply with ONC requests per Sec. 170.565 will, on average, range from $2,455 to $19,638. In comparison, the BLS cost estimate for a ``Computer and Information Analyst'' would, on average, range from $1,742 to $13,933. We note that in some instances the costs may be less and in other instances the costs may exceed this estimated cost range. Costs to ONC We estimate that ONC would commit, on average and depending on complexity, between 40 and 320 hours of staff time to conducting actions under Sec. 170.565 related to ONC-ATLs. We assume that the expertise of a GS-15, Step 1 federal employee(s) would be necessary. Therefore, we estimate the cost for ONC would, on average, range from $4,910 to $39,277. We note that in some instances the costs may be less and in other instances the costs may exceed this estimated cost range. (7) Costs for ONC-ACBs To Submit Identifiable Surveillance Results to the CHPL In this final rule, we require ONC-ACBs to submit identifiable surveillance results to the CHPL quarterly. We estimate that it will take an employee 20 hours annually to submit these identifiable surveillance results quarterly to the CHPL. The hourly wage with benefits for a GS-9, Step 1 federal employee located in Washington, DC, is approximately $51.20. Therefore, we estimate the annual cost for each ONC-ACB to report surveillance results to be $1,024 and the total cost for all three ONC-ACBs to be $3,072. In comparison, the average hourly wage with benefits for a ``Computer Support Specialist'' under NAICS 541380, Testing Laboratories, is $55.90.\30\ Therefore, the BLS estimate for the annual cost for each ONC-ACB to report identifiable surveillance results quarterly is $1,118 and the total cost for all three ONC-ACBs is $3,354. --------------------------------------------------------------------------- \30\ http://www.bls.gov/oes/current/naics5_541380.htm#15-0000. --------------------------------------------------------------------------- We note that ONC may incur a cost for hosting the CHPL, but we have not estimated this cost because ONC already hosts the CHPL and any additional cost associated with this final rule is nominal. Similarly, we note that ONC may incur a cost for updating the CHPL due to the new requirements in this final rule, but we have not estimated [[Page 72462]] these costs because the CHPL has already been updated for the current posting of non-conforming findings and CAPs. As such, any additional cost associated with this final rule will be nominal. (8) Total Annual Cost Estimate We estimate the overall annual cost for this final rule, based on the cost estimates outlined above, will range from $171,011 to $650,352,050 with an average annual cost of $6,597,033. b. Benefits The final rule's provisions for ONC direct review of certified health IT will promote health IT developers' accountability for the performance, reliability, and safety of certified health IT; and facilitate the use of safer and more reliable health IT by health care providers and patients. Specifically, ONC's direct review of certified health IT will facilitate ONC's assessment of non-conformities and ability to require comprehensive corrective actions for health IT developers to address non-conformities determined by ONC, including notifying affected customers. We emphasize that our first and foremost goal is to work with health IT developers to remedy any non- conformities with certified health IT in a timely manner and across all customers. If ONC ultimately suspends and/or terminates a certification issued to a Complete EHR or Health IT Module under the provisions in this final rule, such action will serve to protect the integrity of the Program and users of health IT. While we do not have available means to quantify the benefits of ONC direct review of certified health IT, we note that ONC direct review supports and enables the National Coordinator to fulfill his or her responsibilities under the HITECH Act, instills public confidence in the Program, and protects public health and safety. This final rule's provisions will provide other benefits as well. The provisions for ONC to authorize and oversee testing labs (ONC-ATLs) will facilitate further public confidence in testing and certification by facilitating ONC's ability to timely and directly address testing issues for health IT. The public availability of identifiable surveillance results will enhance transparency and the accountability of health IT developers to their customers. We note that this will provide customers and users of certified health IT with valuable information about the continued conformity of certified health IT. Further, the public availability of identifiable surveillance results will likely benefit health IT developers by providing a more complete context of surveillance in the health IT industry and illuminating good performance and the continued conformity of certified health IT with Program requirements. Again, while we do not have available means to quantify these benefits, we maintain that these approaches will improve Program conformity and compliance as well as further public confidence in certified health IT. We note that we do not have data to establish how often we will need to exercise direct review, the extent of existing and future non- conformities, and the likely outcomes of ONC review, including up to preventing the loss of life. We also note that we do not have data to establish that the provisions for direct oversight of testing labs and the public availability of identifiable surveillance results would actually result in greater public confidence in certified health IT and increased adoption of certified health IT. c. Accounting Statement and Table When a rule is considered an economically significant rule under Executive Order 12866, we are required to develop an accounting statement indicating the classification of the expenditures associated with the provisions of this final rule. Monetary annualized benefits are presented as discounted flows using 3 percent and 7 percent factors in table 4 below. We are not able to explicitly define the universe of all costs, but have provided an average of likely costs of this final rule as well as a high and low range of likely costs. This final rule requires no federal annualized monetized transfers. Table 4--Accounting Statement -------------------------------------------------------------------------------------------------------------------------------------------------------- -------------------------------------------------------------------------------------------------------------------------------------------------------- Source -------------------------------------------------------------------------------------------------------------------------------------------------------- BENEFITS -------------------------------------------------------------------------------------------------------------------------------------------------------- Qualitative, but not monetized.... Expected qualitative benefits include: health IT developer accountability for the performance, RIA reliability, and safety of certified health IT; the use of safer and more reliable health IT by health care providers and patients; and further public confidence in testing and certification. -------------------------------------------------------------------------------------------------------------------------------------------------------- COSTS -------------------------------------------------------------------------------------------------------------------------------------------------------- Annualized monetized costs........ Year dollar Estimates (in millions) Unit discount Period covered rate ------------------------------------------------------------------------------------------------------- Low Mean High ............. ------------------------------------------------ 2015 .17 6.60 650.35 7% One year............. RIA .............. .17 6.60 650.35 3% -------------------------------------------------------------------------------------------------------------------------------------------------------- TRANSFERS -------------------------------------------------------------------------------------------------------------------------------------------------------- From Whom To Whom?................ N/A -------------------------------------------------------------------------------------------------------------------------------------------------------- 2. Regulatory Flexibility Act The Regulatory Flexibility Act (RFA) requires agencies to analyze options for regulatory relief of small businesses if a rule has a significant impact on a substantial number of small entities. The Small Business Administration (SBA) establishes the size of small businesses for federal government programs based on average annual receipts or the average employment of a firm.\31\ The entities that are likely to be [[Page 72463]] directly affected by this final rule are applicants for ONC-ATL status and health IT developers. --------------------------------------------------------------------------- \31\ The SBA references that annual receipts means ``total income'' (or in the case of a sole proprietorship, ``gross income'') plus ``cost of goods sold'' as these terms are defined and reported on Internal Revenue Service tax return forms. --------------------------------------------------------------------------- We estimate up to eight applicants for ONC-ATL status. These applicants are classified under the North American Industry Classification System (NAICS) codes 541380 (Testing Laboratories) specified at 13 CFR 121.201 where the SBA publishes ``Small Business Size Standards by NAICS Industry.'' \32\ The SBA size standard associated with this NAICS code is set at $15 million annual receipts or less. As specified in section VI.C.(5) of this final rule's preamble, we estimate minimal costs for applicants for ONC-ATL status to apply and participate in the Program as ONC-ATLs. We have finalized the minimum amount of requirements necessary to accomplish our goal of enhanced oversight of testing under the Program. As discussed in section VI.B of this final rule, we emphasize that there are also no appropriate regulatory or non-regulatory alternatives that could be developed to lessen the compliance burden associated with this final rule. We further note that we expect all of the estimated costs to be recouped by those applicants that become ONC-ATLs through the fees they charge for testing health IT under the Program. --------------------------------------------------------------------------- \32\ https://www.sba.gov/sites/default/files/files/Size_Standards_Table.pdf. --------------------------------------------------------------------------- While health IT developers that pursue certification of their health IT under the Program represent a small segment of the overall information technology industry, we believe that many health IT developers impacted by this final rule most likely fall under NAICS code 541511 ``Custom Computer Programming Services.'' \33\ The SBA size standard associated with this NAICS code is set at $27.5 million annual receipts or less. There is enough data generally available to establish that between 75% and 90% of entities that are categorized under NAICS code 541511 are under the SBA size standard. We also note that with the exception of aggregate business information available through the U.S. Census Bureau and the SBA related to NAICS code 541511, it appears that many health IT developers that pursue certification of their health IT under the Program are privately held or owned and do not regularly, if at all, make their specific annual receipts publicly available. As a result, it has been difficult to locate empirical data related to many of these health IT developers to correlate to the SBA size standard. However, although not perfectly correlated to the size standard for NAICS code 541511, we do have information indicating that over 60% of health IT developers that have had Complete EHRs and/or Health IT Modules certified to the 2011 Edition have less than 51 employees. --------------------------------------------------------------------------- \33\ https://www.sba.gov/sites/default/files/files/Size_Standards_Table.pdf. --------------------------------------------------------------------------- We estimate that this final rule will have effects on health IT developers, some of which may be small entities, that have certified health IT or are likely to pursue certification of their health IT under the Program. This is because health IT developers may need to reassess their health IT to verify conformity with the Program requirements outlined in this final rule and they may have their certified health IT subjected to corrective action, suspension, and/or termination under the provisions of this final rule. We have, however, finalized the minimum amount of requirements necessary to accomplish our primary policy goals of enhancing Program oversight and health IT developer accountability for the performance, reliability, and safety of certified health IT. Further, as discussed in section VI.B of this final rule, there are no appropriate regulatory or non-regulatory alternatives that could be developed to lessen the compliance burden associated with this final rule. We do not believe that this final rule will create a significant impact on a substantial number of small entities. Additionally, the Secretary certifies that this final rule will not have a significant impact on a substantial number of small entities. 3. Executive Order 13132--Federalism Executive Order 13132 establishes certain requirements that an agency must meet when it promulgates a proposed rule (and subsequent final rule) that imposes substantial direct requirement costs on state and local governments, preempts state law, or otherwise has federalism implications. Nothing in this final rule imposes substantial direct compliance costs on state and local governments, preempts state law, or otherwise has federalism implications. We are not aware of any state laws or regulations that are contradicted or impeded by any of the provisions in this final rule. 4. Unfunded Mandates Reform Act of 1995 Section 202 of the Unfunded Mandates Reform Act of 1995 requires that agencies assess anticipated costs and benefits before issuing any rule that imposes unfunded mandates on state, local, and tribal governments or the private sector requiring spending in any one year of $100 million in 1995 dollars, updated annually for inflation. The current inflation-adjusted statutory threshold is approximately $144 million. While our estimated potential cost effects of this final rule reach the statutory threshold, we do not believe this final rule imposes unfunded mandates on state, local, and tribal governments or the private sector. We estimate the potential monetary costs for the private sector (health IT developers and health care providers) and note that the costs will be the result of a health IT developer not maintaining its certified health IT product's conformity with voluntary Program requirements and having its product's Complete EHR or Health IT Modules' certification(s) terminated. We further state that the minimal monetary cost estimates for ONC-ATLs derive from voluntary participation in the Program and will be recouped through fees charged for the testing of health IT under the Program. OMB reviewed this final rule. List of Subjects in 45 CFR Part 170 Computer technology, Electronic health record, Electronic information system, Electronic transactions, Health, Health care, Health information technology, Health insurance, Health records, Hospitals, Incorporation by reference, Laboratories, Medicaid, Medicare, Privacy, Reporting and recordkeeping requirements, Public health, Security. For the reasons set forth in the preamble, 45 CFR subtitle A, subchapter D, part 170, is amended as follows: PART 170--HEALTH INFORMATION TECHNOLOGY STANDARDS, IMPLEMENTATION SPECIFICATIONS, AND CERTIFICATION CRITERIA AND CERTIFICATION PROGRAMS FOR HEALTH INFORMATION TECHNOLOGY 0 1. The authority citation for part 170 continues to read as follows: Authority: 42 U.S.C. 300jj-11; 42 U.S.C. 300jj-14; 5 U.S.C. 552. 0 2. Amend Sec. 170.299 by revising paragraph (a) to read as follows: Sec. 170.299 Incorporation by reference. (a) Certain material is incorporated by reference into this subpart with the approval of the Director of the Federal Register under 5 U.S.C. 552(a) and 1 CFR part 51. To enforce any edition other than that specified in this section, the Department of Health and Human Services must publish a document in the Federal Register and the material must be available to the public. All approved material is available for inspection at U.S. Department of Health and Human Services, Office of the [[Page 72464]] National Coordinator for Health Information Technology, 330 C Street SW., Washington, DC 20201, call ahead to arrange for inspection at 202- 690-7151, and is available from the sources listed below. It is also available for inspection at the National Archives and Records Administration (NARA). For information on the availability of this material at NARA, call 202-741-6030 or go to http://www.archives.gov/federal_register/code_of_federal_regulations/ibr_locations.html. * * * * * 0 3. Revise Sec. 170.501 to read as follows: Sec. 170.501 Applicability. (a) This subpart establishes the processes that applicants for ONC- ACB status must follow to be granted ONC-ACB status by the National Coordinator; the processes the National Coordinator will follow when assessing applicants and granting ONC-ACB status; the requirements that ONC-ACBs must follow to maintain ONC-ACB status; and the requirements of ONC-ACBs for certifying Complete EHRs, Health IT Module(s), and other types of health IT in accordance with the applicable certification criteria adopted by the Secretary in subpart C of this part. (b) This subpart establishes the processes that applicants for ONC- ATL status must follow to be granted ONC-ATL status by the National Coordinator; the processes the National Coordinator will follow when assessing applicants and granting ONC-ATL status; the requirements that ONC-ATLs must follow to maintain ONC-ATL status; and the requirements of ONC-ATLs for testing Complete EHRs and Health IT Modules in accordance with the applicable certification criteria adopted by the Secretary in subpart C of this part. (c) This subpart establishes the processes accreditation organizations must follow to request approval from the National Coordinator to be an ONC-AA and that the National Coordinator will follow to approve an accreditation organization under the ONC Health IT Certification Program as well as certain ongoing responsibilities for an ONC-AA. (d) This subpart establishes the processes the National Coordinator will follow when exercising direct review of certified health IT and related requirements for ONC-ACBs, ONC-ATLs, and developers of health IT certified under the ONC Health IT Certification Program. 0 4. Amend Sec. 170.502 by revising the definitions of ``Applicant'' and ``Gap certification'' and by adding the definition of ``ONC-Authorized Testing Lab or ONC-ATL'' in alphabetical order to read as follows: Sec. 170.502 Definitions. * * * * * Applicant means a single organization or a consortium of organizations that seeks to become an ONC-ACB or ONC-ATL by submitting an application to the National Coordinator for such status. * * * * * Gap certification means the certification of a previously certified Complete EHR or Health IT Module(s) to: (1) All applicable new and/or revised certification criteria adopted by the Secretary at subpart C of this part based on test results issued by a NVLAP-accredited testing laboratory under the ONC Health IT Certification Program or an ONC-ATL; and (2) All other applicable certification criteria adopted by the Secretary at subpart C of this part based on the test results used to previously certify the Complete EHR or Health IT Module(s) under the ONC Health IT Certification Program. * * * * * ONC-Authorized Testing Lab or ONC-ATL means an organization or a consortium of organizations that has applied to and been authorized by the National Coordinator pursuant to this subpart to perform the testing of Complete EHRs and Health IT Modules to certification criteria adopted by the Secretary at subpart C of this part. * * * * * 0 5. Revise Sec. 170.505 to read as follows: Sec. 170.505 Correspondence. (a) Correspondence and communication with ONC or the National Coordinator shall be conducted by email, unless otherwise necessary or specified. The official date of receipt of any email between ONC or the National Coordinator and an accreditation organization requesting ONC- AA status, the ONC-AA, an applicant for ONC-ACB status, an applicant for ONC-ATL status, an ONC-ACB, an ONC-ATL, health IT developer, or a party to any proceeding under this subpart is the date on which the email was sent. (b) In circumstances where it is necessary for an accreditation organization requesting ONC-AA status, the ONC-AA, an applicant for ONC-ACB status, an applicant for ONC-ATL status, an ONC-ACB, an ONC- ATL, health IT developer, or a party to any proceeding under this subpart to correspond or communicate with ONC or the National Coordinator by regular, express, or certified mail, the official date of receipt for all parties will be the date of the delivery confirmation to the address on record. 0 6. Amend Sec. 170.510 by revising the section heading and introductory text to read as follows: Sec. 170.510 Authorization scope for ONC-ACB status. Applicants for ONC-ACB status may seek authorization from the National Coordinator to perform the following types of certification: * * * * * 0 7. Add Sec. 170.511 to read as follows: Sec. 170.511 Authorization scope for ONC-ATL status. Applicants may seek authorization from the National Coordinator to perform the testing of Complete EHRs or Health IT Modules to a portion of a certification criterion, one certification criterion, or many or all certification criteria adopted by the Secretary under subpart C of this part. 0 8. Revise Sec. 170.520 to read as follows: Sec. 170.520 Application. (a) ONC-ACB application. Applicants must include the following information in an application for ONC-ACB status and submit it to the National Coordinator for the application to be considered complete. (1) The type of authorization sought pursuant to Sec. 170.510. For authorization to perform Health IT Module certification, applicants must indicate the specific type(s) of Health IT Module(s) they seek authorization to certify. If qualified, applicants will only be granted authorization to certify the type(s) of Health IT Module(s) for which they seek authorization. (2) General identifying, information including: (i) Name, address, city, state, zip code, and Web site of applicant; and (ii) Designation of an authorized representative, including name, title, phone number, and email address of the person who will serve as the applicant's point of contact. (3) Documentation that confirms that the applicant has been accredited by the ONC-AA. (4) An agreement, properly executed by the applicant's authorized representative, that it will adhere to the Principles of Proper Conduct for ONC-ACBs. (b) ONC-ATL application. Applicants must include the following information in an application for ONC-ATL status and submit it to the National Coordinator for the application to be considered complete. [[Page 72465]] (1) The authorization scope sought pursuant to Sec. 170.511. (2) General identifying, information including: (i) Name, address, city, state, zip code, and Web site of applicant; and (ii) Designation of an authorized representative, including name, title, phone number, and email address of the person who will serve as the applicant's point of contact. (3) Documentation that confirms that the applicant has been accredited by NVLAP to the ONC Health IT Certification Program, including to ISO/IEC 17025 (incorporated by reference, see Sec. 170.599). (4) An agreement, properly executed by the applicant's authorized representative, that it will adhere to the Principles of Proper Conduct for ONC-ATLs. 0 9. Amend Sec. 170.523 by revising paragraphs (h) and (i) and adding paragraph (o) to read as follows: Sec. 170.523 Principles of proper conduct for ONC-ACBs. * * * * * (h) Only certify health IT (Complete EHRs and/or Health IT Modules) that has been tested, using test tools and test procedures approved by the National Coordinator, by a/an: (1) ONC-ATL; (2) NVLAP-accredited testing laboratory under the ONC Health IT Certification Program for no longer than six months from December 19, 2016; or (3) ONC-ATL, NVLAP-accredited testing laboratory under the ONC Health IT Certification Program, and/or an ONC-ATCB for the purposes of: (i) Certifying previously certified Complete EHRs and/or Health IT Module(s) if the certification criterion or criteria to which the Complete EHRs and/or Health IT Module(s) was previously certified have not been revised and no new certification criteria are applicable to the Complete EHRs and/or Health IT Module(s); or (ii) Performing gap certification. (i) Conduct surveillance of certified health IT in accordance with its accreditation, Sec. 170.556, and the following requirements: (1) Submit an annual surveillance plan to the National Coordinator. (2) Report, at a minimum, on a quarterly basis to the National Coordinator the results of its surveillance, including surveillance results that identify: (i) The names of health IT developers; (ii) Names of products and versions; (iii) Certification criteria and ONC Health IT Certification Program requirements surveilled; (iv) The type of surveillance (i.e., reactive or randomized); (v) The dates surveillance was initiated and completed; and (vi) As applicable, the number of sites that were used in randomized surveillance. (3) Annually submit a summative report of surveillance results to the National Coordinator. * * * * * (o) Be prohibited from reducing the scope of a Complete EHR or Health IT Module's certification when it is under surveillance or under a corrective action plan. 0 10. Add Sec. 170.524 to read as follows: Sec. 170.524 Principles of proper conduct for ONC-ATLs. An ONC-ATL shall: (a) Maintain its NVLAP accreditation for the ONC Health IT Certification Program, including accreditation to ISO/IEC 17025 (incorporated by reference, see Sec. 170.599); (b) Attend all mandatory ONC training and program update sessions; (c) Maintain a training program that includes documented procedures and training requirements to ensure its personnel are competent to test health IT; (d) Report to ONC within 15 days any changes that materially affect its: (1) Legal, commercial, organizational, or ownership status; (2) Organization and management including key testing personnel; (3) Policies or procedures; (4) Location; (5) Personnel, facilities, working environment or other resources; (6) ONC authorized representative (point of contact); or (7) Other such matters that may otherwise materially affect its ability to test health IT. (e) Allow ONC, or its authorized agent(s), to periodically observe on site (unannounced or scheduled), during normal business hours, any testing performed pursuant to the ONC Health IT Certification Program; (f) Records retention: (1) Retain all records related to the testing of Complete EHRs and/ or Health IT Modules to an edition of certification criteria for a minimum of 3 years from the effective date that removes the applicable edition from the Code of Federal Regulations; and (2) Make the records available to HHS upon request during the retention period described in paragraph (f)(1) of this section; (g) Only test health IT using test tools and test procedures approved by the National Coordinator; and (h) Promptly refund any and all fees received for: (1) Requests for testing that are withdrawn while its operations are suspended by the National Coordinator; (2) Testing that will not be completed as a result of its conduct; and (3) Previous testing that it performed if its conduct necessitates the retesting of Complete EHRs and/or Health IT Modules. 0 11. Revise Sec. 170.525 to read as follows: Sec. 170.525 Application submission. (a) An applicant for ONC-ACB or ONC-ATL status must submit its application either electronically via email (or Web site submission if available), or by regular or express mail. (b) An application for ONC-ACB or ONC-ATL status may be submitted to the National Coordinator at any time. 0 12. Amend Sec. 170.530 by revising paragraphs (c)(2) and (4) and (d)(2) and (3) to read as follows: Sec. 170.530 Review of application. * * * * * (c) * * * (2) In order for an applicant to continue to be considered for ONC- ACB or ONC-ATL status, the applicant's revised application must address the specified deficiencies and be received by the National Coordinator within 15 days of the applicant's receipt of the deficiency notice, unless the National Coordinator grants an applicant's request for an extension of the 15-day period based on a finding of good cause. If a good cause extension is granted, then the revised application must be received by the end of the extension period. * * * * * (4) If the National Coordinator determines that a revised application still contains deficiencies, the applicant will be issued a denial notice indicating that the applicant cannot reapply for ONC-ACB or ONC-ATL status for a period of six months from the date of the denial notice. An applicant may request reconsideration of this decision in accordance with Sec. 170.535. (d) * * * (2) The National Coordinator will notify the applicant's authorized representative of its satisfactory application and its successful achievement of ONC-ACB or ONC-ATL status. (3) Once notified by the National Coordinator of its successful achievement of ONC-ACB or ONC-ATL status, the applicant may represent itself as an ONC-ACB or ONC-ATL (as [[Page 72466]] applicable) and begin certifying or testing (as applicable) health information technology consistent with its authorization. 0 13. Amend Sec. 170.535 by revising the section heading and paragraphs (a) and (d)(1) to read as follows: Sec. 170.535 ONC-ACB and ONC-ATL application reconsideration. (a) Basis for reconsideration request. An applicant may request that the National Coordinator reconsider a denial notice only if the applicant can demonstrate that clear, factual errors were made in the review of its application and that the errors' correction could lead to the applicant obtaining ONC-ACB or ONC-ATL status. * * * * * (d) * * * (1) If the National Coordinator determines that clear, factual errors were made during the review of the application and that correction of the errors would remove all identified deficiencies, the applicant's authorized representative will be notified of the National Coordinator's determination and the applicant's successful achievement of ONC-ACB or ONC-ATL status. * * * * * 0 14. Revise Sec. 170.540 to read as follows: Sec. 170.540 ONC-ACB and ONC-ATL status. (a) Acknowledgement and publication. The National Coordinator will acknowledge and make publicly available the names of ONC-ACBs and ONC- ATLs, including the date each was authorized and the type(s) of certification or scope of testing, respectively, each has been authorized to perform. (b) Representation. Each ONC-ACB or ONC-ATL must prominently and unambiguously identify the scope of its authorization on its Web site and in all marketing and communications statements (written and oral) pertaining to its activities under the ONC Health IT Certification Program. (c) Renewal. An ONC-ACB or ONC-ATL is required to renew its status every three years. An ONC-ACB or ONC-ATL is required to submit a renewal request, containing any updates to the information requested in Sec. 170.520, to the National Coordinator 60 days prior to the expiration of its status. (d) Expiration. An ONC-ACB's or ONC-ATL's status will expire three years from the date it was granted by the National Coordinator unless it is renewed in accordance with paragraph (c) of this section. 0 15. Amend Sec. 170.556 by revising paragraph (d)(6) and (e)(1) to read as follows: Sec. 170.556 In-the-field surveillance and maintenance of certification for health IT. * * * * * (d) * * * (6) Withdrawal. If a certified Complete EHR or certified Health IT Module's certification has been suspended, an ONC-ACB is permitted to initiate certification withdrawal procedures for the Complete EHR or Health IT Module (consistent with its accreditation to ISO/IEC 17065 and procedures for withdrawing a certification) when the health IT developer has not completed the actions necessary to reinstate the suspended certification. (e) * * * (1) Rolling submission of in-the-field surveillance results. The results of in-the-field surveillance under this section must be submitted to the National Coordinator, at a minimum, on a quarterly basis in accordance with Sec. 170.523(i)(2). * * * * * 0 16. Revise Sec. 170.557 to read as follows: Sec. 170.557 Authorized testing and certification methods. (a) ONC-ATL applicability. An ONC-ATL must provide remote testing for both development and deployment sites. (b) ONC-ACB applicability. An ONC-ACB must provide remote certification for both development and deployment sites. 0 17. Revise Sec. 170.560 to read as follows: Sec. 170.560 Good standing as an ONC-ACB or ONC-ATL. (a) ONC-ACB good standing. An ONC-ACB must maintain good standing by: (1) Adhering to the Principles of Proper Conduct for ONC-ACBs; (2) Refraining from engaging in other types of inappropriate behavior, including an ONC-ACB misrepresenting the scope of its authorization, as well as an ONC-ACB certifying Complete EHRs and/or Health IT Module(s) for which it does not have authorization; and (3) Following all other applicable federal and state laws. (b) ONC-ATL good standing. An ONC-ATL must maintain good standing by: (1) Adhering to the Principles of Proper Conduct for ONC-ATLs; (2) Refraining from engaging in other types of inappropriate behavior, including an ONC-ATL misrepresenting the scope of its authorization, as well as an ONC-ATL testing health IT for which it does not have authorization; and (3) Following all other applicable federal and state laws. 0 18. Revise Sec. 170.565 to read as follows: Sec. 170.565 Revocation of ONC-ACB or ONC-ATL status. (a) Type-1 violations. The National Coordinator may revoke an ONC- ATL or ONC-ACB's status for committing a Type-1 violation. Type-1 violations include violations of law or ONC Health IT Certification Program policies that threaten or significantly undermine the integrity of the ONC Health IT Certification Program. These violations include, but are not limited to: False, fraudulent, or abusive activities that affect the ONC Health IT Certification Program, a program administered by HHS or any program administered by the federal government. (b) Type-2 violations. The National Coordinator may revoke an ONC- ATL or ONC-ACB's status for failing to timely or adequately correct a Type-2 violation. Type-2 violations constitute noncompliance with Sec. 170.560. (1) Noncompliance notification. If the National Coordinator obtains reliable evidence that an ONC-ATL or ONC-ACB may no longer be in compliance with Sec. 170.560, the National Coordinator will issue a noncompliance notification with reasons for the notification to the ONC-ATL or ONC-ACB requesting that the ONC-ATL or ONC-ACB respond to the alleged violation and correct the violation, if applicable. (2) Opportunity to become compliant. After receipt of a noncompliance notification, an ONC-ATL or ONC-ACB is permitted up to 30 days to submit a written response and accompanying documentation that demonstrates that no violation occurred or that the alleged violation has been corrected. (i) If the ONC-ATL or ONC-ACB submits a response, the National Coordinator is permitted up to 30 days from the time the response is received to evaluate the response and reach a decision. The National Coordinator may, if necessary, request additional information from the ONC-ATL or ONC-ACB during this time period. (ii) If the National Coordinator determines that no violation occurred or that the violation has been sufficiently corrected, the National Coordinator will issue a memo to the ONC-ATL or ONC-ACB confirming this determination. (iii) If the National Coordinator determines that the ONC-ATL or ONC- [[Page 72467]] ACB failed to demonstrate that no violation occurred or to correct the area(s) of non-compliance identified under paragraph (b)(1) of this section within 30 days of receipt of the noncompliance notification, then the National Coordinator may propose to revoke the ONC-ATL or ONC- ACB's status. (c) Proposed revocation. (1) The National Coordinator may propose to revoke an ONC-ATL or ONC-ACB's status if the National Coordinator has reliable evidence that the ONC-ATL or ONC-ACB has committed a Type- 1 violation; or (2) The National Coordinator may propose to revoke an ONC-ATL or ONC-ACB's status if, after the ONC-ATL or ONC-ACB has been notified of a Type-2 violation, the ONC-ATL or ONC-ACB fails to: (i) Rebut the finding of a violation with sufficient evidence showing that the violation did not occur or that the violation has been corrected; or (ii) Submit to the National Coordinator a written response to the noncompliance notification within the specified timeframe under paragraph (b)(2) of this section. (d) Suspension of an ONC-ATL or ONC-ACB's operations. (1) The National Coordinator may suspend the operations of an ONC-ATL or ONC- ACB under the ONC Health IT Certification Program based on reliable evidence indicating that: (i) Applicable to both ONC-ACBs and ONC-ATLs. The ONC-ATL or ONC- ACB committed a Type-1 or Type-2 violation; (ii) Applicable to ONC-ACBs. The continued certification of Complete EHRs or Health IT Modules by the ONC-ACB could have an adverse impact on the health or safety of patients. (iii) Applicable to ONC-ATLs. The continued testing of Complete EHRs or Health IT Modules by the ONC-ATL could have an adverse impact on the health or safety of patients. (2) If the National Coordinator determines that the conditions of paragraph (d)(1) of this section have been met, an ONC-ATL or ONC-ACB will be issued a notice of proposed suspension. (3) Upon receipt of a notice of proposed suspension, an ONC-ATL or ONC-ACB will be permitted up to 3 days to submit a written response to the National Coordinator explaining why its operations should not be suspended. (4) The National Coordinator is permitted up to 5 days from receipt of an ONC-ATL or ONC-ACB's written response to a notice of proposed suspension to review the response and make a determination. (5) The National Coordinator may make one of the following determinations in response to the ONC-ATL or ONC-ACB's written response or if the ONC-ATL or ONC-ACB fails to submit a written response within the timeframe specified in paragraph (d)(3) of this section: (i) Rescind the proposed suspension; or (ii) Suspend the ONC-ATL or ONC-ACB's operations until it has adequately corrected a Type-2 violation; or (iii) Propose revocation in accordance with paragraph (c) of this section and suspend the ONC-ATL or ONC-ACB's operations for the duration of the revocation process. (6) A suspension will become effective upon an ONC-ATL or ONC-ACB's receipt of a notice of suspension. (e) Opportunity to respond to a proposed revocation notice. (1) An ONC-ATL or ONC-ACB may respond to a proposed revocation notice, but must do so within 10 days of receiving the proposed revocation notice and include appropriate documentation explaining in writing why its status should not be revoked. (2) Upon receipt of an ONC-ATL or ONC-ACB's response to a proposed revocation notice, the National Coordinator is permitted up to 30 days to review the information submitted by the ONC-ACB or ONC-ATL and reach a decision. (f) Good standing determination. If the National Coordinator determines that an ONC-ATL or ONC-ACB's status should not be revoked, the National Coordinator will notify the ONC-ATL or ONC-ACB's authorized representative in writing of this determination. (g) Revocation. (1) The National Coordinator may revoke an ONC-ATL or ONC-ACB's status if: (i) A determination is made that revocation is appropriate after considering the information provided by the ONC-ATL or ONC-ACB in response to the proposed revocation notice; or (ii) The ONC-ATL or ONC-ACB does not respond to a proposed revocation notice within the specified timeframe in paragraph (e)(1) of this section. (2) A decision to revoke an ONC-ATL or ONC-ACB's status is final and not subject to further review unless the National Coordinator chooses to reconsider the revocation. (h) Extent and duration of revocation--(1) Effectuation. The revocation of an ONC-ATL or ONC-ACB is effective as soon as the ONC-ATL or ONC-ACB receives the revocation notice. (2) ONC-ACB provisions. (i) A certification body that has had its ONC-ACB status revoked is prohibited from accepting new requests for certification and must cease its current certification operations under the ONC Health IT Certification Program. (ii) A certification body that has had its ONC-ACB status revoked for a Type-1 violation is not permitted to reapply for ONC-ACB status under the ONC Health IT Certification Program for a period of 1 year. (iii) The failure of a certification body that has had its ONC-ACB status revoked to promptly refund any and all fees for certifications of Complete EHRs and Health IT Module(s) not completed will be considered a violation of the Principles of Proper Conduct for ONC-ACBs and will be taken into account by the National Coordinator if the certification body reapplies for ONC-ACB status under the ONC Health IT Certification Program. (3) ONC-ATL provisions. (i) A testing lab that has had its ONC-ATL status revoked is prohibited from accepting new requests for testing and must cease its current testing operations under the ONC Health IT Certification Program. (ii) A testing lab that has had its ONC-ATL status revoked for a Type-1 violation is not permitted to reapply for ONC-ATL status under the ONC Health IT Certification Program for a period of 1 year. (iii) The failure of a testing lab that has had its ONC-ATL status revoked to promptly refund any and all fees for testing of health IT not completed will be considered a violation of the Principles of Proper Conduct for ONC-ATLs and will be taken into account by the National Coordinator if the testing lab reapplies for ONC-ATL status under the ONC Health IT Certification Program. 0 19. Revise Sec. 170.570 to read as follows: Sec. 170.570 Effect of revocation on the certifications issued to Complete EHRs and EHR Module(s). (a) The certified status of Complete EHRs and/or Health IT Module(s) certified by an ONC-ACB or tested by an ONC-ATL that had its status revoked will remain intact unless a Type-1 violation was committed by the ONC-ACB and/or ONC-ATL that calls into question the legitimacy of the certifications issued. (b) If the National Coordinator determines that a Type-1 violation was committed by an ONC-ACB and/or ONC-ATL that called into question the legitimacy of certifications issued to [[Page 72468]] health IT, then the National Coordinator would: (1) Review the facts surrounding the revocation of the ONC-ACB's or ONC-ATL's status; and (2) Publish a notice on ONC's Web site if the National Coordinator believes that the Complete EHRs and/or Health IT Module(s) certifications were based on unreliable testing and/or certification. (c) If the National Coordinator determines that Complete EHRs and/ or Health IT Module(s) certifications were based on unreliable testing and/or certification, the certification status of affected Complete EHRs and/or Health IT Module(s) would only remain intact for 120 days after the National Coordinator publishes the notice. (1) The certification status of affected Complete EHRs and/or Health IT Module(s) can only be maintained after the 120-day timeframe by being re-tested by an ONC-ATL in good standing, as necessary, and re-certified by an ONC-ACB in good standing. (2) The National Coordinator may extend the time that the certification status of affected Complete EHRs and/or Health IT Module(s) remains intact as necessary for the proper retesting and recertification of the affected health IT. 0 20. Add Sec. 170.580 to read as follows: Sec. 170.580 ONC review of certified health IT. (a) Direct review--(1) Purpose. ONC may directly review certified health IT to determine whether it conforms to the requirements of the ONC Health IT Certification Program. (2) Circumstances that may trigger review--(i) Unsafe conditions. ONC may initiate direct review under this section if it has a reasonable belief that certified health IT may not conform to the requirements of the Program because the certified health IT may be causing or contributing to conditions that present a serious risk to public health or safety, taking into consideration-- (A) The potential nature, severity, and extent of the suspected conditions; (B) The need for an immediate or coordinated governmental response; and (C) If applicable, information that calls into question the validity of the health IT's certification or maintenance thereof under the Program. (ii) Impediments to ONC-ACB oversight. ONC may initiate direct review under this section if it has a reasonable belief that certified health IT may not conform to requirements of the Program and the suspected non-conformity presents issues that-- (A) May require access to confidential or other information that is not available to an ONC-ACB; (B) May require concurrent or overlapping review by two or more ONC-ACBs; or (C) May exceed an ONC-ACB's resources or expertise. (3) Relationship to ONC-ACBs and ONC-ATLs. (i) ONC's review of certified health IT is independent of, and may be in addition to, any surveillance conducted by an ONC-ACB. (ii) ONC may assert exclusive review of certified health IT as to any matters under review by ONC and any similar matters under surveillance by an ONC-ACB. (iii) ONC's determination on matters under its review is controlling and supersedes any determination by an ONC-ACB on the same matters. (iv) An ONC-ACB and ONC-ATL shall provide ONC with any available information that ONC deems relevant to its review of certified health IT. (v) ONC may end all or any part of its review of certified health IT under this section at any time and refer the applicable part of the review to the relevant ONC-ACB(s) if ONC determines that doing so would serve the effective administration or oversight of the ONC Health IT Certification Program. (b) Notice--(1) Notice of potential non-conformity--(i) Circumstances that may trigger notice of potential non-conformity. At any time during its review of certified health IT under paragraph (a) of this section, ONC may send a notice of potential non-conformity if it has a reasonable belief that certified health IT may not conform to the requirements of the ONC Health IT Certification Program. (ii) Health IT developer response. (A) The health IT developer must respond to the notice of potential non-conformity by: (1) Cooperating with ONC and/or a third party acting on behalf of ONC; (2) Providing ONC and/or a third party acting on behalf of ONC access, including in accordance with paragraph (b)(3) of this section, to the certified health IT under review; (3) Providing ONC with a written explanation and all supporting documentation addressing the potential non-conformity within 30 days, or within the adjusted timeframe set in accordance with paragraph (b)(1)(ii)(B) of this section. (B) ONC may adjust the 30-day timeframe specified in paragraph (b)(1)(ii)(A)(3) of this section to be shorter or longer based on factors including, but not limited to: (1) The type of certified health IT and certification in question; (2) The type of potential non-conformity to be corrected; (3) The time required to correct the potential non-conformity; and (4) Issues of public health or safety. (iii) ONC determination. After receiving the health IT developer's written explanation and supporting documentation as required by paragraph (b)(1)(ii)(A)(3) of this section, ONC shall do one of the following: (A) Issue a written determination ending its review. (B) Request additional information and continue its review in accordance with a new timeframe ONC establishes under (b)(1)(ii)(A)(3) and (b)(1)(ii)(B) of this section. (C) Substantiate a non-conformity and issue a notice of non- conformity. (D) Issue a notice of proposed termination. (2) Notice of non-conformity--(i) Circumstances that may trigger notice of non-conformity. At any time during its review of certified health IT under paragraph (a) of this section, ONC may send a notice of non-conformity to the health IT developer if it determines that certified health IT does not conform to the requirements of the ONC Health IT Certification Program. (ii) Health IT developer response. (A) The health IT developer must respond to the notice of non-conformity by: (1) Cooperating with ONC and/or a third party acting on behalf of ONC; (2) Providing ONC and/or a third party acting on behalf of ONC access, including in accordance with paragraph (b)(3) of this section, to the certified health IT under review; (3) Providing ONC with a written explanation and all supporting documentation addressing the non-conformity within 30 days, or within the adjusted timeframe set in accordance with paragraph (b)(1)(ii)(B) of this section; and (4) Providing a proposed corrective action plan consistent with paragraph (c) of this section. (B) ONC may adjust the 30-day timeframe specified in paragraph (b)(2)(ii)(A)(3) of this section to be shorter or longer based on factors including, but not limited to: (1) The type of certified health IT and certification in question; (2) The type of non-conformity to be corrected; (3) The time required to correct the non-conformity; and (4) Issues of public health or safety. (iii) ONC determination. After receiving the health IT developer's response provided in accordance with paragraph (b)(2)(ii) of this section, ONC shall either issue a written [[Page 72469]] determination ending its review or continue with its review under the provisions of this section. (3) Records access. In response to a notice of potential non- conformity or notice of non-conformity, a health IT developer shall make available to ONC and for sharing within HHS, with other federal departments, agencies, and offices, and with appropriate entities including, but not limited to, third-parties acting on behalf of ONC: (i) All records related to the development, testing, certification, implementation, maintenance and use of its certified health IT; and (ii) Any complaint records related to the certified health IT. (c) Corrective action plan and procedures. (1) If ONC determines that certified health IT does not conform to requirements of the ONC Health IT Certification Program, ONC shall notify the health IT developer of its determination and require the health IT developer to submit a proposed corrective action plan. (2) ONC shall provide direction to the health IT developer as to the required elements of the corrective action plan, which shall include such required elements as ONC determines necessary to comprehensively and expeditiously resolve the identified non- conformity(ies). The corrective action plan shall, in all cases, at a minimum include the following required elements: (i) An assessment and description of the nature, severity, and extent of the non-conformity; (ii) Identification of all potentially affected customers; (iii) A detailed description of how the health IT developer will promptly ensure that all potentially affected customers are notified of the non-conformity and plan for resolution; (iv) A detailed description of how and when the health IT developer will resolve the identified non-conformity and all issues, both at the locations where the non-conformity was identified and for all affected customers; (v) A detailed description of how the health IT developer will ensure that the identified non-conformity and all issues are resolved; (vi) A detailed description of the supporting documentation that will be provided to demonstrate that the identified non-conformity and all issues are resolved; and (vii) The timeframe under which all elements of the corrective action plan will be completed. (viii) An explanation of, and agreement to execute, the steps that will be prevent the non-conformity from re-occurring. (3) When ONC receives a proposed corrective action plan (or a revised proposed corrective action plan), it shall either approve the proposed corrective action plan or, if the plan does not adequately address all required elements, instruct the health IT developer to submit a revised proposed corrective action plan within a specified period of time. (4) The health IT developer is responsible for ensuring that a proposed corrective action plan submitted in accordance with paragraph (b)(2)(ii)(A)(4) of this section or a revised corrective action plan submitted in accordance with paragraph (c)(3) of this section adequately addresses all required elements as determined by ONC no later than 90 days after the health IT developer's receipt of a notice of non-conformity. (5) Health IT developers may request extensions for the submittal and/or completion of corrective action plans. In order to make these requests, health IT developers must submit a written statement to ONC that explains and justifies the extension request. ONC will evaluate each request individually and will make decisions on a case-by-case basis. (6) Upon fulfilling all of its obligations under the corrective action plan, the health IT developer must submit an attestation to ONC, which serve as a binding official statement by the health IT developer that it has fulfilled all of its obligations under the corrective action plan. (7) ONC may reinstitute a corrective action plan if it later determines that a health IT developer has not fulfilled all of its obligations under the corrective action plan as attested in accordance with paragraph (c)(6) of this section. (d) Suspension. (1) ONC may suspend the certification of a Complete EHR or Health IT Module at any time if ONC has a reasonable belief that the certified health IT may present a serious risk to public health or safety. (2) When ONC decides to suspend a certification, ONC will notify the health IT developer of its determination through a notice of suspension. (i) The notice of suspension will include, but may not be limited to: (A) An explanation for the suspension; (B) Information supporting the determination; (C) The consequences of suspension for the health IT developer and the Complete EHR or Health IT Module under the ONC Health IT Certification Program; and (D) Instructions for appealing the suspension. (ii) A suspension of a certification will become effective upon the date specified in the notice of suspension. (3) The health IT developer must notify all potentially affected customers of the identified non-conformity(ies) and suspension of certification in a timely manner. (4) When a certification is suspended, the health IT developer must cease and desist from any marketing, licensing, and sale of the suspended Complete EHR or Health IT Module as ``certified'' under the ONC Health IT Certification Program from that point forward until such time ONC cancels the suspension in accordance with paragraph (d)(6) of this section. (5) The certification of any health IT produced by a health IT developer that has the certification of one of its Complete EHRs or Health IT Modules suspended under the Program is prohibited, unless ONC cancels a suspension in accordance with paragraph (d)(6) of this section. (6) ONC may cancel a suspension at any time if ONC no longer has a reasonable belief that the certified health IT presents a serious risk to public health or safety. (e) Proposed termination. (1) ONC may propose to terminate a certification issued to a Complete EHR and/or Health IT Module if: (i) The health IT developer fails to timely respond to any communication from ONC, including, but not limited to: (A) Fact-finding; (B) A notice of potential non-conformity within the timeframe established in accordance with paragraph (b)(1)(ii)(A)(3) of this section; (C) A notice of non-conformity within the timeframe established in accordance with paragraph (b)(2)(ii)(A)(3) of this section; or (D) A notice of suspension. (ii) The information or access provided by the health IT developer in response to any ONC communication, including, but not limited to: Fact-finding, a notice of potential non-conformity, or a notice of non- conformity is insufficient or incomplete; (iii) The health IT developer fails to cooperate with ONC and/or a third party acting on behalf of ONC; (iv) The health IT developer fails to timely submit in writing a proposed corrective action plan; (v) The health IT developer fails to timely submit a corrective action plan that adequately addresses the elements required by ONC as described in paragraph (c) of this section; (vi) The health IT developer does not fulfill its obligations under the [[Page 72470]] corrective action plan developed in accordance with paragraph (c) of this section; or (vii) ONC concludes that a certified health IT's non- conformity(ies) cannot be cured. (2) When ONC decides to propose to terminate a certification, ONC will notify the health IT developer of the proposed termination through a notice of proposed termination. (i) The notice of proposed termination will include, but may not be limited to: (A) An explanation for the proposed termination; (B) Information supporting the proposed termination; and (C) Instructions for responding to the proposed termination. (3) The health IT developer may respond to a notice of proposed termination, but must do so within 10 days of receiving the notice of proposed termination and must include appropriate documentation explaining in writing why its certification should not be terminated. (4) Upon receipt of the health IT developer's written response to a notice of proposed termination, ONC has up to 30 days to review the information submitted by the health IT developer and make a determination. ONC may extend this timeframe if the complexity of the case requires additional time for ONC review. ONC will, as applicable: (i) Notify the health IT developer in writing that it has ceased all or part of its review of the health IT developer's certified health IT. (ii) Notify the health IT developer in writing of its intent to continue all or part of its review of the certified health IT under the provisions of this section. (iii) Proceed to terminate the certification of the health IT under review consistent with paragraph (f) of this section. (f) Termination. (1) The National Coordinator may terminate a certification if: (i) A determination is made that termination is appropriate after considering the information provided by the health IT developer in response to the proposed termination notice; or (ii) The health IT developer does not respond in writing to a proposed termination notice within the timeframe specified in paragraph (e)(3) of this section. (2) When ONC decides to terminate a certification, ONC will notify the health IT developer of its determination through a notice of termination. (i) The notice of termination will include, but may not be limited to: (A) An explanation for the termination; (B) Information supporting the determination; (C) The consequences of termination for the health IT developer and the Complete EHR or Health IT Module under the ONC Health IT Certification Program; and (D) Instructions for appealing the termination. (ii) A termination of a certification will become effective after the following applicable occurrence: (A) The expiration of the 10-day period for filing a statement of intent to appeal in paragraph (g)(3)(i) of this section if the health IT developer does not file a statement of intent to appeal. (B) The expiration of the 30-day period for filing an appeal in paragraph (g)(3)(ii) of this section if the health IT developer files a statement of intent to appeal, but does not file a timely appeal. (C) A final determination to terminate the certification per paragraph (g)(7) of this section if a health IT developer files an appeal. (3) The health IT developer must notify all potentially affected customers of the identified non-conformity(ies) and termination of certification in a timely manner. (4) ONC may rescind a termination determination before the termination becomes effective if ONC determines that termination is no longer appropriate. (g) Appeal--(1) Basis for appeal. A health IT developer may appeal an ONC determination to suspend or terminate a certification issued to a Complete EHR or Health IT Module if the health IT developer asserts: (i) ONC incorrectly applied ONC Health IT Certification Program requirements for suspension or termination; or (ii) ONC's determination was not sufficiently supported by the information provided by ONC with its determination. (2) Method and place for filing an appeal. A statement of intent to appeal followed by a request for appeal must be submitted to ONC in writing by an authorized representative of the health IT developer whose Complete EHR or Health IT Module was subject to the determination being appealed. The statement of intent to appeal and request for appeal must be filed in accordance with the requirements specified in the notice of termination or notice of suspension. (3) Time for filing a request for appeal. (i) A statement of intent to appeal must be filed within 10 days of a health IT developer's receipt of the notice of suspension or notice of termination. (ii) An appeal, including all supporting documentation, must be filed within 30 days of the filing of the intent to appeal. (4) Effect of appeal on suspension and termination. (i) A request for appeal stays the termination of a certification issued to a Complete EHR or Health IT Module, but the Complete EHR or Health IT Module is prohibited from being marketed, licensed, or sold as ``certified'' during the stay. (ii) A request for appeal does not stay the suspension of a Complete EHR or Health IT Module. (5) Appointment of a hearing officer. The National Coordinator will assign the case to a hearing officer to adjudicate the appeal on his or her behalf. (i) The hearing officer may not review an appeal in which he or she participated in the initial suspension or termination determination or has a conflict of interest in the pending matter. (ii) The hearing officer must be trained in a nationally recognized ethics code that articulates nationally recognized standards of conduct for hearing officers/officials. (6) Adjudication. (i) The hearing officer may make a determination based on: (A) The written record, which includes the: (1) ONC determination and supporting information; (2) Information provided by the health IT developer with the appeal filed in accordance with paragraphs (g)(1) through (3) of this section; and (3) Information ONC provides in accordance with paragraph (g)(6)(v) of this section; or (B) All the information provided in accordance with paragraph (g)(6)(i)(A) and any additional information from a hearing conducted in-person, via telephone, or otherwise. (ii) The hearing officer will have the discretion to conduct a hearing if he/she: (A) Requires clarification by either party regarding the written record under paragraph (g)(6)(i)(A) of this section; (B) Requires either party to answer questions regarding the written record under paragraph (g)(6)(i)(A) of this section; or (C) Otherwise determines a hearing is necessary. (iii) The hearing officer will neither receive witness testimony nor accept any new information beyond what was provided in accordance with paragraph (g)(6)(i) of this section. (iv) The default process will be a determination in accordance with paragraph (g)(6)(i)(A) of this section. [[Page 72471]] (v) ONC will have an opportunity to provide the hearing officer with a written statement and supporting documentation on its behalf that clarifies, as necessary, its determination to suspend or terminate the certification. (A) The written statement and supporting documentation must be included as part of the written record and provided to the health IT developer within 15 days of the health IT developer's filing of an intent to appeal. (B) Failure of ONC to submit a written statement does not result in any adverse findings against ONC and may not in any way be taken into account by the hearing officer in reaching a determination. (7) Determination by the hearing officer. (i) The hearing officer will issue a written determination to the health IT developer within 30 days of receipt of the appeal or within a timeframe agreed to by the health IT developer and ONC and approved by the hearing officer, unless ONC cancels the suspension or rescinds the termination determination. (ii) The National Coordinator's determination on appeal, as issued by the hearing officer, is final and not subject to further review. 0 21. Add Sec. 170.581 to read as follows: Sec. 170.581 Certification ban. (a) Ban. The certification of any of a health IT developer's health IT is prohibited when the certification of one or more of the health IT developer's Complete EHRs or Health IT Modules is: (1) Terminated by ONC under the ONC Health IT Certification Program; (2) Withdrawn from the ONC Health IT Certification Program by an ONC-ACB because the health IT developer requested it to be withdrawn when the health IT developer's health IT was the subject of a potential non-conformity or non-conformity as determined by ONC; (3) Withdrawn by an ONC-ACB because of a non-conformity with any of the certification criteria adopted by the Secretary under subpart C of this part; or (4) Withdrawn by an ONC-ACB because the health IT developer requested it to be withdrawn when the health IT developer's health IT was the subject of surveillance for a certification criterion or criteria adopted by the Secretary under subpart C of this part, including notice of pending surveillance. (b) Reinstatement. The certification of a health IT developer's health IT subject to the prohibition in paragraph (a) of this section may commence once the following conditions are met. (1) A health IT developer must request ONC's permission in writing to participate in the ONC Health IT Certification Program. (2) The request must demonstrate that the customers affected by the certificate termination or withdrawal have been provided appropriate remediation. (3) ONC is satisfied with the health IT developer's demonstration under paragraph (b)(2) of this section that all affected customers have been provided with appropriate remediation and grants reinstatement into the ONC Health IT Certification Program. 0 22. Revise Sec. 170.599 to read as follows: Sec. 170.599 Incorporation by reference. (a) Certain material is incorporated by reference into this subpart with the approval of the Director of the Federal Register under 5 U.S.C. 552(a) and 1 CFR part 51. To enforce any edition other than that specified in this section, the Department of Health and Human Services must publish a document in the Federal Register and the material must be available to the public. All approved material is available for inspection at U.S. Department of Health and Human Services, Office of the National Coordinator for Health Information Technology, 330 C Street SW., Washington, DC 20201, call ahead to arrange for inspection at 202-690-7151, and is available from the source listed below. It is also available for inspection at the National Archives and Records Administration (NARA). For information on the availability of this material at NARA, call 202-741-6030 or go to http://www.archives.gov/federal_register/code_of_federal_regulations/ibr_locations.html. (b) International Organization for Standardization, Case postale 56, CH[middot]1211, Geneve 20, Switzerland, telephone +41-22-749-01-11, http://www.iso.org. (1) ISO/IEC GUIDE 65:1996--General Requirements for Bodies Operating Product Certification Systems (First Edition), 1996, ``ISO/ IEC Guide 65,'' IBR approved for Sec. 170.503. (2) ISO/IEC 17011:2004 Conformity Assessment--General Requirements for Accreditation Bodies Accrediting Conformity Assessment Bodies (Corrected Version), February 15, 2005, ``ISO/IEC 17011,'' IBR approved for Sec. 170.503. (3) ISO/IEC 17025:2005(E)--General requirements for the competence of testing and calibration laboratories (Second Edition), 2005-05-15, ``ISO/IEC 17025,'' IBR approved for Sec. Sec. 170.520(b) and 170.524(a). (4) ISO/IEC 17065:2012(E)--Conformity assessment--Requirements for bodies certifying products, processes and services (First Edition), 2012, ``ISO/IEC 17065,'' IBR approved for Sec. 170.503. Sylvia M. Burwell, Secretary, Department of Health and Human Services. [FR Doc. 2016-24908 Filed 10-14-16; 8:45 am] BILLING CODE 4150-45-P
| Category | Regulatory Information | |
| Collection | Federal Register | |
| sudoc Class | AE 2.7: GS 4.107: AE 2.106: | |
| Publisher | Office of the Federal Register, National Archives and Records Administration | |
| Section | Rules and Regulations | |
| Action | Final rule. | |
| Dates | These regulations are effective December 19, 2016. | |
| Contact | Michael Lipinski, Office of Policy, Office of the National Coordinator for Health Information Technology, 202-690-7151. | |
| FR Citation | 81 FR 72404 | |
| RIN Number | 0955-AA00 | |
| CFR Associated | Computer Technology; Electronic Health Record; Electronic Information System; Electronic Transactions; Health; Health Care; Health Information Technology; Health Insurance; Health Records; Hospitals; Incorporation by Reference; Laboratories; Medicaid; Medicare; Privacy; Reporting and Recordkeeping Requirements; Public Health and Security |