2016-04531. 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:

Notice of proposed rulemaking.

SUMMARY:

This notice of proposed rulemaking (“proposed rule”) introduces 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 proposed rule proposes to establish processes for ONC to directly review health IT certified under the Program and take action when necessary, including 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 proposed rule includes processes for ONC to authorize and oversee accredited testing laboratories under the Program. It also includes a provision for the increased transparency and availability of surveillance results.

DATES:

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

ADDRESSES:

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

• Federal eRulemaking Portal: Follow the instructions for submitting comments. Attachments should be in Microsoft Word, Microsoft Excel, or Adobe PDF; however, we prefer Microsoft Word. http://www.regulations.gov.
• Regular, Express, or Overnight Mail: Department of Health and Human Services, Office of the National Coordinator for Health Information Technology, Attention: ONC Health IT Certification Program Proposed Rule, Mary E. Switzer Building, Mail Stop: 7033A, 330 C Street SW., Washington, DC 20201. Please submit one original and two copies.
• Hand Delivery or Courier: Office of the National Coordinator for Health Information Technology, Attention: ONC Health IT Certification Program Proposed Rule, Mary E. Switzer Building, Mail Stop: 7033A, 330 C Street SW., Washington, DC 20201. Please submit one original and two copies. (Because access to the interior of the Mary E. Switzer Building is not readily available to persons without federal government identification, commenters are encouraged to leave their comments in the mail drop slots located in the main lobby of the building.)

Enhancing the Public Comment Experience: To facilitate public comment on this proposed rule, a copy will be made available in Microsoft Word format on ONC's Web site (http://www.healthit.gov). We believe this version will make it easier for commenters to access and copy portions of the proposed rule for use in their individual comments. Additionally, a separate document will also be made available on ONC's Web site (http://www.healthit.gov) for the public to use in providing comments on the proposed rule. This document is meant to provide the public with a simple and organized way to submit comments on proposals and respond to specific questions posed in the preamble of the proposed rule. While use of this document is entirely voluntary, we encourage commenters to consider using the document in lieu of unstructured comments or to use it as an addendum to narrative cover pages. We believe that use of the document may facilitate our review and understanding of the comments received.

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

Docket: For access to the docket to read background documents or comments received, go to http://www.regulations.gov or the Department of Health and Human Services, Office of the National Coordinator for Health Information Technology, Mary E. Switzer Building, Mail Stop: 7033A, 330 C Street SW., Washington, DC 20201 (call ahead to the contact listed below to arrange for inspection).

FOR FURTHER INFORMATION CONTACT:

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

SUPPLEMENTARY INFORMATION:

Commonly Used Acronyms

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 International Organization for Standardization

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 Surveillance Results

C. Costs and Benefits

1. Costs

2. Benefits

II. Provisions of the Proposed Rule

A. ONC's Role Under the ONC Health IT Certification Program

1. Review of Certified Health IT

a. Authority and Scope

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) Program Ban 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. Background on Testing and Relationship of Testing Labs and the Program

b. Proposed Amendments To Include ONC-ATLs in the Program

(1) Proposed Amendments to § 170.501 Applicability

(2) Proposed Amendments to § 170.502 Definitions

(3) Proposed Amendments to § 170.505 Correspondence

(4) Proposed Amendment to § 170.510 Type of Certification

(5) Proposed Creation of § 170.511 Authorization Scope for ONC-ATL Status

(6) Proposed Amendments to § 170.520 Application

(7) Proposed Amendments to § 170.523 Principles of Proper Conduct for ONC-ACBs

(8) Proposed Creation of § 170.524 Principles of Proper Conduct for ONC-ATLs

(9) Proposed Amendments to § 170.525 Application Submission

(10) Proposed Amendments to § 170.530 Review of Application

(11) Proposed Amendments to § 170.535 ONC-ACB Application Reconsideration

(12) Proposed Amendments to § 170.540 ONC-ACB Status

(13) Proposed Amendments to § 170.557 Authorized Certification Methods

(14) Proposed Amendments to § 170.560 Good Standing as an ONC-ACB

(15) Proposed Amendments to § 170.565 Revocation of ONC-ACB Status

(16) Request for Comment on § 170.570 in the Context of an ONC-ATL's Status Being Revoked

B. Public Availability of Identifiable Surveillance Results

III. National Technology Transfer and Advancement Act

IV. Incorporation by Reference

V. Response to Comments

VI. Collection of Information Requirements

A. ONC-AA and ONC-ACBs

B. ONC-ATLs

C. Health IT Developers

VII. 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 ONC Review and Inquiry Into Certified Health IT Non-Conformities

(3) Costs to Health IT Developers and ONC Associated With the Proposed Appeal Process Following a Suspension/Termination of a Complete EHR's or Health IT Module's Certification

(4) Costs to 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 Publicly Post Identifiable Surveillance Results

(8) Total Annual Cost Estimate

b. Benefits

2. Regulatory Flexibility Act

3. Executive Order 13132—Federalism

4. Unfunded Mandates Reform Act of 1995

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 instances where the ONC-Approved Accreditor (ONC-AA) may engage in improper conduct or not perform its responsibilities under 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)). Most recently, 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 use of adopted 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 provisions to increase the transparency of information related to health IT certified under the Program (referred to as “certified health IT” throughout this proposed rule) made available by health IT developers through enhanced surveillance and disclosure requirements.

With each Program modification and rule, we have been able to address stakeholder concerns, certification ambiguities, and improve oversight. As health IT adoption continues to increase, including for settings and use cases beyond the Medicare and Medicaid EHR Incentive Programs (“EHR Incentive Programs”), we propose to address in this proposed rule new concerns identified through Program administration and from stakeholders. As certified capabilities interact with other capabilities in certified health IT and with other products, we seek to ensure that concerns within the scope of the Program can be appropriately addressed.

We delegated authority to ONC-ACBs to issues certifications for heath IT on our behalf through the Permanent Certification Program final rule. The scope of this authority, consistent with customary certification programs and International Organization for Standardization/International Electrotechnical Commission 17065:2012 (ISO 17065),^[1] is primarily limited to conformance determinations for health IT evaluated against adopted certification criteria with minimal determinations for health IT against other regulatory requirements (§ 170.523(k) and (l)). As such, ONC-ACBs do not have the responsibility or expertise to address matters outside the scope of this authority. In particular, ONC-ACBs are not positioned, due to the bounds of their authority and limited resources, to address situations that involve non-conformities resulting from the interaction of certified and uncertified capabilities within the certified health IT or the interaction of a certified health IT's capabilities with other products. In some instances, these non-conformities may pose a risk to public health or safety, including, for example, capabilities (certified or uncertified) of health IT directly contributing to or causing medical errors. While ONC-ACBs play an important role in the administration of the Program and in identifying non-conformities within their scope of authority (e.g., non-conformities with certification criteria), the Program does not currently have any other means for reviewing and addressing other non-conformities. As explained below, ONC proposes to expand its role in the Program to include the ability to directly review and address non-conformities in an effort to enhance Program oversight and the reliability and safety of certified health IT.

The Health Information Technology for Economic and Clinical Health (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 Public Health Service Act requires that the National Coordinator for Health Information Technology (National Coordinator) perform specified statutory duties (section 3001(c) of the PHSA), 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 this statutory instruction, we propose to expand ONC's role in the Program to encompass the ability to directly review health IT certified under the Program and address non-conformities found in certified health IT.

The proposed rule also proposes processes for ONC to timely and directly address testing issues. These processes do not exist today under the current Program structure, particularly as compared to ONC's oversight of ONC-ACBs. In addition, the proposed rule includes a provision for the increased transparency and availability of identifiable surveillance results. The publication of identifiable surveillance results would 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

We propose, consistent with section 3001 of the PHSA, to expand ONC's role in the Program to encompass the ability to directly review health IT certified under the Program (referred to as “certified health IT” throughout this proposed rule). This review would be independent of, and may be in addition to, reviews conducted by ONC-ACBs. ONC's direct review may include certified capabilities and non-certified capabilities of the certified health IT in order for ONC to meet its responsibilities under section 3001 of the PHSA. More specifically, this review would extend beyond the continued conformance of the certified health IT's capabilities with the specific certification criteria, test procedures, and certification requirements such as mandatory disclosures of limitations on use and types of costs related to certified capabilities (see § 170.523(k)(1)). It 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. This approach would support the National Coordinator fulfilling the statutory duties specified in section 3001 of the PHSA as it relates to keeping a certification program for the voluntary certification of health IT that allows for the electronic use and exchange of information consistent with the goals of section 3001(b).

Under our proposals outlined in this proposed rule, ONC would have broad discretion to review certified health IT. However, we anticipate that such review would be relatively infrequent and would focus on situations that pose a risk to public health or safety. An effective response to these situations would likely require the timely marshaling and deployment of resources and specialized expertise by ONC. It may also require coordination among federal government agencies. Additionally, we believe there could be other exigencies, distinct from public health and safety concerns, which for similar reasons would warrant ONC's direct review and action. These exigencies are described in section II.A.1 of this preamble.

We propose that ONC could initiate a direct review whenever it becomes aware of information, whether 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, breaches in the security of a patient's health information, or other outcomes that are in direct opposition to the National Coordinator's responsibilities under section 3001 of the PHSA. The proposals in this proposed rule would enable ONC to require corrective action for these non-conformities and, when necessary, suspend or terminate a certification issued to a Complete EHR or Health IT Module. We also propose to establish a process for health IT developers 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 propose strict processes for the recertification of health IT (or replacement versions) that has had its certification terminated, heightened scrutiny for such health IT, and a Program ban for health IT of health IT developers that do not correct non-conformities. We emphasize that enhancing ONC's role in reviewing certified health IT would 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

We propose that ONC would 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 we established for ONC-ACBs, we did not establish a similar and equitable 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 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 17025). However, in so doing, there is effectively no direct ONC oversight of NVLAP-accredited testing labs like there is for ONC-ACBs.

This proposed rule proposes 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, this proposed rule proposes means for authorizing, retaining, suspending, and revoking ONC-Authorized Testing Lab (ONC-ATL) status under the Program. These proposed processes are similar to current ONC-ACB processes. The proposed changes would 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 Surveillance Results

In furtherance of our efforts to increase the transparency and availability of information related to certified health IT, we propose to require ONC-ACBs to make identifiable surveillance results publicly available on their Web sites on a quarterly basis. We believe the publication of identifiable surveillance results would enhance transparency and the accountability of health IT developers to their customers. The public availability of identifiable surveillance results would provide customers and users with valuable information about the continued performance of certified health IT as well as surveillance efforts. While we expect that the prospect of publicly identifiable surveillance results would motivate some health IT developers to improve their maintenance efforts, we believe that most published surveillance results would reassure customers and users of certified health IT. This is because, based on ONC-ACB surveillance results to date, most certified health IT and health IT developers are maintaining conformance with certification criteria and Program requirements. The publishing of such “positive” surveillance results would also provide a more complete context of surveillance; rather than only sharing “negatives,” such as non-conformities and corrective action plans.

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). OMB has determined that this proposed rule is an economically significant rule as the potential costs associated with this proposed rule could be greater than $100 million per year. Accordingly, we have prepared an RIA that to the best of our ability presents the costs and benefits of the proposed rule.

1. Costs

We estimated the potential monetary costs of this proposed rule for health IT developers, ONC-ATLs, the Federal government (i.e., ONC), and health care providers 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 ONC review and inquiry into certified health IT non-conformities; (3) costs to health IT developers and ONC associated with the proposed appeal process following a suspension/termination of a Complete EHR's or Health IT Module's certification; (4) costs to 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 post identifiable surveillance results. We also provide an overall annual monetary cost estimate for this proposed rule. We note that we have rounded all estimates to the nearest dollar and all estimates are expressed in 2016 dollars.

We have been unable to estimate the costs for health IT developers to correct non-conformities identified through ONC's direct review of certified health IT because the costs incurred by health IT developers to bring their certified health IT into conformance would be determined on a case-by-case basis. We do, however, identify factors that would inform cost estimates and request comment on existing relevant data and methods we could use to estimate these costs in section VII.C.1.a of this preamble.

We estimated the costs for ONC and health IT developers related to ONC review and inquiry into certified health IT non-conformities. 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 $49,096. We estimate the cost for ONC to review and conduct an inquiry into certified health IT would, on average, range from $2,455 to $73,644.

We estimated the costs to health IT developers and ONC associated with the proposed 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 estimated the costs to 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. 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 on providers. Further, we have stated in this proposed rule our intent to work with health IT developers to correct non-conformities ONC finds in their certified health IT under the provisions in this proposed rule. We provide a more detailed discussion of past certification terminations and the potential impacts of certification termination on providers in section VII.C.1.a of this preamble.

We estimated the costs for ONC-ATLs and ONC associated with ONC-ATL accreditation, application, renewal, and reporting requirements. We estimate the annualized cost of ONC-ATL accreditation, application, and the first proposed three-year authorization period to be approximately $55,623. 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 $84,372. In addition, we estimate the total annual cost for ONC-ATLs to meet the reporting requirements of proposed § 170.524(d) to be approximately $819.

We estimate ONC's annualized cost of administering the entire application process to be approximately $992. These costs would 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 the ONC-ATLs.

We estimate the costs for ONC-ATLs and ONC related to revoking ONC-ATL status. We estimate the cost for an ONC-ATL to comply with ONC requests per § 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 estimate the costs for ONC-ACBs to publicly post identifiable surveillance results on their Web sites on a quarterly basis. We estimate these costs would annually be $205 per ONC-ACB and total $615 for all ONC-ACBs.

We estimate the overall annual cost for this proposed rule, based on the cost estimates outlined above, would range from $230,616 to $650,288,915 with an average annual cost of $6,595,268. For a more detailed explanation of our methodology and estimated costs, including requests for comment on ways to improve our methodology and estimated costs, please see section VII.C.1.a of this preamble.

2. Benefits

The proposed rule's provisions for ONC direct review of certified health IT would 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 would permit ONC to assess non-conformities and prescribe comprehensive corrective actions for health IT developers to address non-conformities, including notifying affected customers. As previously stated, our first and foremost goal would be 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 proposals in this proposed rule, such action would serve to protect the integrity of the Program and users of health IT. Overall, we believe that ONC direct review supports and enables the National Coordinator to fulfill his/her responsibilities under the HITECH Act, instills public confidence in the Program, and protects public health and safety.

The proposed rule's provisions would also provide other benefits. The proposals for ONC to authorize and oversee testing labs (ONC-ATLs) would facilitate further public confidence in testing and certification by permitting ONC to timely and directly address testing issues for health IT. The proposed public availability of identifiable surveillance results would enhance transparency and the accountability of health IT developers to their customers. This proposal would provide customers and users of certified health IT with valuable information about the continued performance of certified health IT as well as surveillance efforts. Further, the public availability of identifiable surveillance results would likely benefit health IT developers by providing a more complete context of surveillance and illuminating good performance and the continued compliance of certified health IT with Program requirements. Overall, we believe these proposed approaches, if finalized, would improve Program compliance and further public confidence in certified health IT.

II. Provisions of the Proposed 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). In this section of the preamble, we propose means for enhancing ONC's role in the Program.

1. Review of Certified Health IT

We propose to modify ONC's role in the Program to provide additional oversight of health IT certified under the Program. We propose to create a process for ONC to directly review certified health IT. We propose that ONC would directly assess non-conformities and, where applicable, prescribe comprehensive corrective actions for health IT developers that could include: Investigating and reporting on root cause analyses of the non-conformities; notifying affected customers; fully correcting identified issues across a health IT developer's customer base; and taking other appropriate remedial actions. We propose that ONC would be able to suspend and/or terminate a certification issued to health IT under the Program. We also propose to establish a process for health IT developers to appeal determinations by ONC to suspend or terminate certifications issued to health IT under the Program. We believe these proposals would enhance the overall integrity and performance of the Program and provide greater confidence that health IT conforms to the requirements of certification when it is implemented, maintained, and used.

a. Authority and Scope

Section 3001 of the PHSA directs the National Coordinator to establish a certification program or programs and to perform the duties of keeping or recognizing such program(s) 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, among other requirements: Ensures that each patient's health information is secure and protected, in accordance with applicable law; improves health care quality; reduces medical errors; reduces health care costs resulting from inefficiency, medical errors, inappropriate care, duplicative care, and incomplete information; and promotes 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).

Under the current structure of the Program, ONC-ACBs are responsible for issuing and administering certifications in accordance with ISO 17065, the PoPC for ONC-ACBs, and other requirements of the Program. Specifically, ONC-ACBs are directly positioned and accountable for determining whether a Complete EHR or Health IT Module initially satisfies and subsequently continues to conform to certification criteria, including relevant interpretative guidance and test procedures. ONC-ACBs are also responsible for ensuring compliance with other Program requirements such as the mandatory disclosure requirements of limitations on use and types of costs related to certified capabilities (see § 170.523(k)(1)). If an ONC-ACB can substantiate a non-conformity under the Program, either as a result of surveillance or otherwise, ISO 17065 requires that the ONC-ACB consider and decide upon the appropriate action, which could include: (1) The continuation of the certification under specified conditions (e.g., increased surveillance); (2) a reduction in the scope of certification to remove non-conforming product variants; (3) suspension of the certification pending remedial action by the developer; or (4) termination of the certification (see 80 FR 62707-62725 and § 170.556).

While ONC authorizes ONC-ACBs to issue and administer certifications for health IT, ONC does not directly review certified health IT under the Program. The only exception would be if ONC revoked an ONC-ACB's authorization due to a “Type-1” program violation ^[2] that calls into question the legitimacy of a certification issued by the ONC-ACB (see § 170.570). Under these circumstances, the National Coordinator would review and determine whether health IT was improperly certified and, if so, require recertification of the health IT within 120 days (76 FR 1299). We explained in the Permanent Certification Program final rule that recertification would be necessary in such a situation to maintain the integrity of the Program and to ensure the efficacy and safety of certified health IT (76 FR 1299).

ONC-ACBs have the necessary expertise and capacity to effectively administer certification requirements under a wide variety of circumstances (80 FR 62708-09). Nevertheless, we recognized in response to comments on the 2015 Edition proposed rule (80 FR 16804) that we would need to provide additional guidance and assistance to ONC-ACBs to ensure that these requirements are applied consistently and in a manner that accomplishes our intent.^[3] While we are committed to supporting ONC-ACBs in their roles, we further recognize that there are certain instances when review of certified health IT is necessary to ensure continued compliance with Program requirements, but such review is beyond the scope of an ONC-ACB's responsibilities, expertise (i.e., accreditation), or resources.

A health IT developer may have had products certified by two different ONC-ACBs and a potential non-conformity with a certified capability may extend across all of the health IT developers' certified health IT. In such an instance, ONC would be more suited to handle the review of the certified health IT as ONC-ACBs only have oversight of the health IT they certify and ONC could ensure a more coordinated review and consistent determination. Similarly, a potential non-conformity or non-conformity may involve systemic, widespread, or complex issues that could be difficult for an ONC-ACB to investigate or address in a timely and effective manner, such as where the nature, severity, or extent of the non-conformity would be likely to quickly consume or exceed an ONC-ACB's resources or capacity. Most acutely, non-conformities with certified health IT may arise that pose a risk to public health or safety, including, for example, capabilities (certified or uncertified) of health IT directly contributing to or causing medical errors (see section 3001(b)(2) of the PHSA). In such situations, ONC is directly responsible for reducing medical errors through the certification of health IT and ONC-ACBs may not have the expertise to address these matters. We believe there could also be other exigencies, distinct from public health and safety concerns, which for similar reasons would warrant ONC's direct review and action. For example, ONC might directly review a potentially widespread non-conformity that could compromise the security or protection of patients' health information in violation of applicable law (see section 3001(b)(1) of the PHSA) or that could lead to inaccurate or incomplete documentation and resulting inappropriate or duplicative care under federal health care programs (see section 3001(b)(3) of the PHSA). Last, it is conceivable that ONC could have information about a potential non-conformity that is confidential or that for other reasons cannot be shared with an ONC-ACB, and therefore could be acted upon only by ONC.

In the instances described above, we believe that the existing role of ONC-ACBs could be complemented by establishing a process for ONC to directly review certified health IT. While we propose that ONC would have broad discretion to review certified health IT under proposed § 170.580(a), we anticipate that this “direct review” of certified health IT would be relatively infrequent and would focus on the situations that present unique challenges or issues that ONC-ACBs may be unable to effectively address without ONC's assistance or intervention (as described in the examples above and in proposed § 170.580(a)(1)). ONC can effectively respond to these potential issues through quickly marshaling and deploying resources and specialized expertise and ensuring a coordinated review and response that may involve other offices and agencies within HHS as well as other federal agencies. We seek comment on these and other factors that ONC should consider in deciding whether and under what circumstances to directly review certified health IT. We emphasize that our primary goal in all cases would be to correct non-conformities and ensure that certified health IT performs in accordance with Program requirements. In this regard, our first and foremost desire would be to work with the health IT developer to remedy any non-conformity in a timely manner.

b. ONC-ACB's Role

We propose that ONC's review of certified health IT, as specified in proposed 170.580(a)(2)(i), 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. For the reasons and situations we have described above in section II.A.1.a, we believe that these reviews would be complementary because ONC may review matters outside of an ONC-ACB's responsibilities (i.e., those that implicate section 3001(b) of the PHSA) or matters that may be partially within an ONC-ACB's purview to review but present special challenges or considerations that may be difficult for an ONC-ACB to address. Accordingly, to ensure consistency and clear accountability, we propose in § 170.580(a)(2)(ii) 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. We propose in § 170.580(a)(2)(iii) 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 this proposed rule, including having the opportunity to appeal an ONC determination, as applicable.

We clarify 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. Further, any determination to suspend or terminate a certification issued to health IT by an ONC-ACB that may result would not be subject to ONC review under the provisions in this proposed rule. In those instances, there would also be no opportunity to appeal the ONC-ACB's determination(s) under the provisions in this proposed rule. ONC-ACBs are accredited, authorized, and entrusted to issue and administer certifications under the Program consistent with certification criteria and other specified Program requirements. Therefore, they have the necessary expertise and capacity to effectively administer these specific requirements.

We propose 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 propose in § 170.580(a)(2)(iv) 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 propose that ONC could contract with an ONC-ACB to conduct facets of the review within an ONC-ACB's scope of expertise, such as testing or surveillance of certified capabilities. We propose 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 health IT at particular locations. We further propose in § 170.580(a)(2)(v) that ONC could, at any time, end all or any part of its review of certified health IT under the processes in this proposed rule and refer the applicable part of the review to the relevant ONC-ACB(s) if doing so would serve the efficiency or 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. As noted above, this may include processes and determinations (e.g., suspension or termination) not governed by the review and appeal processes in this proposed rule.

We encourage comment on our proposed approach and the role of an ONC-ACB.

c. Review Processes

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, breaches in the security of a patient's health information, or other outcomes that do not align with the National Coordinator's responsibilities under section 3001 of the PHSA. If ONC deems the information to be reliable and actionable, it would conduct further inquiry into the certified health IT. Alternatively, ONC could 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, 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 propose for all processes proposed under this section (section II.A.1.c) of the preamble, as described below, that correspondence and communication with ONC and/or the National Coordinator shall be conducted by email, unless otherwise necessary or specified. We propose to modify § 170.505 accordingly.

(1) Notice of Potential Non-Conformity or Non-Conformity

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 (see proposed § 170.580(b)(1)). 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).

To ensure a complete and comprehensive review of the certified health IT product, we propose in § 170.580(b)(2) that ONC 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 recognize that much of this information already must be disclosed as required by the Program and described in the 2015 Edition final rule. We propose, 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. This approach would support the review of capabilities that interact with certified capabilities and assist ONC in determining whether certified health IT conforms to applicable Program requirements. We emphasize that health IT developers would be required to cooperate with ONC's efforts to access relevant records and should not prevent or seek to discourage ONC from obtaining such records. If we determined that the health IT developer was not cooperative with the fact-finding process, we propose 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 preamble.

We understand that health IT developers may have concerns regarding disclosure of proprietary, trade secret, competitively sensitive, or other confidential information. To address these concerns, 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.^[4] For instance, ONC would ensure that, if it obtains proprietary or trade secret information, that information would not be included in the Certified Health IT Product List (CHPL). We note, 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.

The notice of potential non-conformity or non-conformity would specify the timeframe for which the health IT developer must respond to ONC. Unless otherwise specified in the notice and as outlined in proposed § 170.580(b)(1)(i) and (ii), the health IT developer would be required to respond within 30 days of receipt of the notice and, if necessary, submit a proposed corrective action plan as outlined below in section II.A.1.c.(2) of this preamble. We propose that ONC may require a health IT developer to respond and/or submit a proposed corrective action plan 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 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 (see proposed § 170.580(b)(1)(i) and (ii)). We propose that ONC would have discretion in deciding the appropriate timeframe for a response and proposed corrective action plan from the health IT developer. We believe that affording ONC this flexibility would advance the overarching policy goal of ensuring that ONC addresses and works with health IT developers to correct potential non-conforming health IT in an efficient and effective manner.

We propose in § 170.580(b)(3) 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 conformant.

We request comment on our proposed processes as 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.

(2) Corrective Action

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 and in proposed § 170.580(c). To emphasize, remedying a non-conformity may require addressing both certified and uncertified capabilities within the certified health IT.

We propose in § 170.580(c)(1) that ONC would require a health IT developer to submit a proposed corrective action plan to ONC. The corrective action plan would provide a means to correct the identified non-conformities across all the health IT developer's customer base and would require the health IT developer to make such corrections before the certified health IT could continue to be identified as “certified” under the ONC Health IT Certification Program, or sold or licensed with that designation to new customers.

We propose, as described above in section II.A.1.c.(1) of this preamble, that a health IT developer must submit a proposed corrective action plan to ONC within 30 days of the date that the health IT developer was notified by ONC of the non-conformity unless ONC specifies a different timeframe. This approach aligns with and does not change the corrective action process for ONC-ACBs described in § 170.556(d). The primary difference between this approach and the approach for ONC-ACBs in § 170.556(d) is that in § 170.556(d) the health IT developer must submit a corrective action plan to an ONC-ACB within 30 days of being notified of the potential non-conformity. In this proposed rule, we propose that this 30-day period be the default for receiving a response/corrective action plan, 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.

We propose in § 170.580(c)(2) that ONC would provide direction to the health IT developer as to the required elements of the corrective action plan and would work with the health IT developer to develop an acceptable corrective action plan. The corrective action plan would be required to 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 propose in § 170.580(c)(3) that 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. In addition to the required elements above and as specified in § 170.580(c)(4), we propose that a health IT developer would be required to submit an attestation to ONC. The attestation would follow the form and format specified by the corrective action plan and would be a binding official statement by the health IT developer that it has fulfilled all of its obligations under the corrective action plan, including curing the identified non-conformities and related deficiencies and taking all reasonable steps to prevent their recurrence. Based on this attestation and all other relevant information, ONC would determine whether the non-conformity(ies) has been cured and, if so, would lift the corrective action plan. However, if it were later discovered that the health IT developer had not acted in the manner attested, we propose that ONC could reinstitute the corrective action plan or proceed to suspend or terminate the certification of any encompassed Complete EHR or Health IT Module of the certified health IT (see proposed § 170.580(c)(5), (d)(1)(v) and (e)(1)(iv)).

We request comment on our proposed corrective action plan processes as described above.

We propose that ONC would report the corrective action plan 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 conformance 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 this proposed rule and in the 2015 Edition final rule (80 FR 62725-26).

(3) Suspension

We propose that ONC may suspend the certification of a Complete EHR or Health IT Module at any time because 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 below. We propose in § 170.580(d)(1) 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 under the “termination” section below, we propose 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; or a notice of potential non-conformity or 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 corrective action plan that adequately addresses the elements required by ONC as described earlier in this preamble under the “corrective action” section and in proposed § 170.580(c); or
• The health IT developer does not fulfill its obligations under the corrective action plan developed in accordance with proposed § 170.580(c).

We note that section § 170.556(d)(5) states that, consistent with its accreditation to ISO 17065 and procedures for suspending a certification, an ONC-ACB shall initiate suspension procedures for a Complete EHR or Health IT Module:

• 30 days after notifying the developer of a non-conformity, if the developer has not submitted a proposed corrective action plan;
• 90 days after notifying the developer of a non-conformity, if the ONC-ACB cannot approve a corrective action plan because the developer has not submitted a revised proposed corrective action plan; and
• Immediately, if the developer has not completed the corrective actions specified by an approved corrective action plan within the time specified therein.

As noted above, we propose that ONC may suspend a certification for similar reasons, but also propose that ONC would suspend a certification at any time based on a potential risk to public health or safety, or other exigent circumstances. We believe the proposed addition of an expedited process and direct ONC review for those reasons makes the Program better enabled for ONC to act swiftly to address potentially non-conforming certified health IT. To note, the processes for ONC-ACBs as detailed above and in the 2015 Edition final rule are not altered by the proposals in this proposed rule.

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 propose in § 170.580(d)(2) that ONC would issue a notice of suspension when appropriate. We propose that a suspension would become effective upon the health IT developer's receipt of the notice of suspension. We propose 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 propose 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.

We propose in 170.580(d)(3) that the health IT developer would be required to notify its affected and potentially affected customers of the certification suspension in a timely manner. Additionally, we propose 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 propose in § 170.580(d)(4) 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. Additionally, we propose in § 170.580(d)(5) that in cases of a certification suspension, inherited certified status for the Complete EHR or Health IT Module would not be permitted. We propose in § 170.580(d)(6) that we would rescind a suspension of certification if the health IT developer completes all elements of an approved corrective action plan and/or ONC confirms that all non-conformities have been corrected.

We request 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. We also request comment on whether a health IT developer should only be permitted to certify new Complete EHRs and 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. Such a prohibition on the certification of new Complete EHRs or Health IT Modules may incentivize the health IT developer to cure the non-conformity. In correcting the non-conformity for all affected customers, we note that this would not include those affected customers that decline the correction or fail to cooperate. We request 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.

Under the current suspension processes administered by ONC-ACBs, following the suspension of a certification of a Complete EHR or Health IT Module, an ONC-ACB is permitted to initiate certification termination procedures for the Complete EHR or Health IT Module should the health IT developer not complete the actions necessary to reinstate the suspended certification (consistent with its accreditation to ISO 17065 and procedures for terminating a certification). We propose that ONC would similarly be permitted to initiate the certification termination procedures as described in more detail in the “Termination” section below.

(4) Termination

We propose in § 170.580(e)(1) 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 corrective action plan 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 corrective action plan developed in accordance with proposed § 170.580(c); or (5) ONC concludes that the certified health IT's non-conformity(ies) cannot be cured. We request comment on these proposed reasons for termination and on any additional circumstances for which commenters believe termination of a certification would be warranted.

We propose that a termination would be issued consistent with the processes specified in proposed § 170.580(e)(2) through (4) and outlined below, but note that these proposed termination processes do not change the certification termination processes for ONC-ACBs described in the 2015 Edition final rule. 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. 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. The written termination notice would be sent via certified mail and the official date of receipt would be the date of the delivery confirmation.

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 the preamble and in proposed § 170.580(f)(7). 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 propose 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 request 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.

(5) Appeal

If ONC suspends or terminates a certification for a Complete EHR or Health IT Module, we propose that 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 specified in § 170.580(f) and outlined below.

Section 170.580(f)(1) sets forth that a health IT developer may appeal an ONC determination to suspend or terminate a certification issued to 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.

Section 170.580(f)(2) describes 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. Section 170.580(f)(2) also requires that the request for appeal must be filed in accordance with the instructions specified in the notice of termination or notice of suspension. These instructions for filing a request may include, but would not be limited to: (1) Providing a copy of the written determination by ONC to suspend or terminate the certification and any supporting documentation; and (2) explaining the reasons for the appeal. Section 170.580(f)(3) describes that this request must be submitted to ONC within 10 calendar days of the health IT developer's receipt of the notice of suspension or notice of termination. Section 170.580(f)(4) specifies that a request for appeal 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, a request for appeal would not stay a suspension of a Complete EHR or Health IT Module. We propose that, similar to the effects of a suspension, 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.

We propose that the National Coordinator would assign the appeal to a hearing officer who would adjudicate the appeal on his or her behalf, as described in § 170.580(f)(5). 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.

There would be two parties involved in an appeal: (1) The health IT developer that requests the appeal; and (2) ONC. Section 170.580(f)(6)(i) describes that the hearing officer would have the discretion to make a determination based on: (1) The written record as submitted to the hearing officer by the health IT developer with the appeal filed in accordance with proposed § 170.580(f)(1) through (3) and 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. As specified in § 170.580(f)(6)(ii), 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 under paragraph (f)(6)(i) of this section; (2) requires either party to answer questions regarding the written record under paragraph (f)(6)(i) of this section; or (3) otherwise determines a hearing is necessary. As specified in § 170.580(f)(6)(iii), 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. As specified in § 170.580(f)(6)(iv), the default process for the hearing officer would be a determination based on option 1 described above.

As proposed in § 170.580(f)(6)(v) and mentioned above, 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) that explains its determination to suspend or terminate the certification. 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.

As proposed in § 170.580(f)(7)(i), 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 request 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 request comment on whether an extension should be permitted and whether it should only be permitted under the circumstances proposed or for other reasons and circumstances.

As proposed in § 170.580(f)(7)(ii), 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 welcome comments on the proposed appeal processes outlined in this section.

d. Consequences of Certification Termination

In general, this proposed rule does not address the consequences of certification termination beyond requirements for recertification. Any consequences of, and remedies for, termination beyond recertification requirements are outside the scope of this proposed rule. For example, this proposed rule does not address the remedies for providers participating in the EHR Incentive Programs that may be using a Complete EHR or Health IT Module that has its certification terminated.^[5] While our goals with this proposed 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 proposed methods (e.g., corrective action plans) designed to identify and remedy non-conformities so that a Complete EHR or Health IT Module can maintain its certification.

(1) Program Ban and Heightened Scrutiny

We propose in § 170.581(a) 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 propose 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 previous certified capabilities. We propose that the health IT developer must request permission 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 propose 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 propose 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.

If the Complete EHR or Health IT Module (or replacement version) is recertified (certified), we believe and propose in § 170.581(b) that 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 believe completion of the recertification process and heightened scrutiny would support the integrity of the Program and the continued functionality and reliability of the certified health IT. We request comment 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 propose in § 170.581(c) 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 nonconformity (notice of potential non-conformity) or non-conformity would be prohibited. 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. As noted in the discussion under the proposed suspension provisions, 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 note that this would not include those customers that decline the correction or fail to cooperate. We welcome comments on this proposal, including how the health IT developer should demonstrate to ONC that all necessary corrections were completed. We further request 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. Additionally, consistent with this and the other proposed requirements of § 170.581, we request 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.

(2) ONC-ACB Response to a Non-Conformity

As previously noted in this proposed rule, ONC-ACBs are accredited to ISO 17065. Section 7.11.1 of ISO 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.^[6] 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 do not, however, believe these are appropriate actions under the Program.

We do not believe that a reduction in scope is appropriate for health IT under the Program. This action 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, it should be corrected (the version is corrected through an update or a new corrected version is rolled out to all affected customers) or be subjected to certification termination. Accordingly, we propose to revise the PoPC for ONC-ACBs (§ 170.523) to prohibit ONC-ACBs from reducing the scope of a certification when the health IT is under surveillance or a corrective action plan. This proposal addresses two situations: (1) When health IT is suspected of a non-conformity (i.e., under surveillance); and (2) when health IT has a non-conformity (i.e., under a corrective action plan).

A health IT developer's withdrawal of its certified health IT from the Program when the subject of a potential non-conformity (under surveillance) or non-conformity should not be without prejudice. If a health IT developer is not willing to correct a non-conformity, then we believe the health IT developer should be subject to the same proposed consequences as we have proposed under ONC direct review of health IT (i.e., a Program ban on the testing and certification of its health IT). We further propose 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 § 170.581 proposals) should apply to certification terminations issued by ONC-ACBs. We note that the concept of heightened scrutiny, as described above, is consistent with section 7.11.1 listing of increased surveillance as an appropriate response to a non-conformity.

These proposals are consistent with our proposed approach and processes for ONC direct review and would support the overall integrity and reliability of the Program. We welcome comment on these proposals.

2. Establishing ONC Authorization for Testing Labs Under the Program; Requirements for ONC-ATL Conduct; ONC Oversight and Processes for ONC-ATLs

a. Background on Testing and Relationship of Testing Labs and the Program

The Temporary Certification Program, established by final rule (75 FR 36158), provided a process by which an organization or organizations could become an ONC-Authorized Testing and Certification Body (ONC-ATCB) and be authorized by the National Coordinator to perform the testing and certification of Complete EHRs and/or Health IT Modules. Under the Temporary Certification Program, an organization was both a testing lab and certification body. The Temporary Certification Program was replaced by the Permanent Certification Program, which first finalized a new set of rules in 2011 (76 FR 1262). The name of the Permanent Certification Program was changed to the ONC HIT Certification Program in the 2014 Edition final rule (77 FR 54163) and the ONC Health IT Certification Program (Program) in the 2015 Edition final rule (80 FR 62602).

Under the Program, testing and certification must be completed by organizations (or components of organizations) that are separately accredited to different ISO standards (i.e., ISO 17065 for certification and ISO 17025 for testing). In the Permanent Certification Program final rule, we explained that the NVLAP, administered by NIST, would be the accreditor for health IT testing labs under the Program (76 FR 1278-1281).

Unlike the processes we established for ONC-ACBs, which at a high-level includes a two-step process of: (1) Accreditation by the ONC-Approved Accreditor; and (2) a formal request for and subsequent authorization by the National Coordinator to operate within the Program, we did not establish a similar and equitable process for testing labs. Instead, we required in the PoPC for ONC-ACBs (45 CFR 170.523(h)) that ONC-ACBs only accept test results from NVLAP-accredited testing labs. This requirement for ONC-ACBs had the effect of requiring testing labs to be accredited by NVLAP to ISO 17025. However, in so doing, there is effectively no direct ONC oversight of NVLAP-accredited testing labs like there is for ONC-ACBs.

In the five years we have administered the Program, we have continually made updates to the Program's rules to refine, mature, and optimize program operations (see revisions to the Program in the 2014 Edition final rule, 2014 Edition Release 2 final rule, and 2015 Edition final rule). These changes have also included new and expanded responsibilities for ONC-ACBs and ONC. While we have continued to update and improve our oversight of ONC-ACBs, we have not done the same for the testing labs upon which ONC-ACBs rely. Our continued evaluation of the Program has led us to determine that the operational efficiency and overall integrity of the Program could be improved by establishing parity in the oversight we provide for both testing and certification.

The testing of health IT by accredited testing labs is the first line of evaluation in determining whether health IT meets the capabilities included in a certification criterion and serves as the basis for the certification of health IT by ONC-ACBs. We believe that having a similar and comparable authorization and oversight paradigm for testing labs and certification bodies would enable ONC to oversee and address testing and certification performance issues throughout the entire continuum of the Program in a precise and direct manner. For example, ensuring that consistent testing documentation (e.g., files, reports, and test tool outputs) is produced across all ONC-ATLs could be directly addressed at the testing stage compared to today's rules that solely apply to ONC-ACBs, who are simply the recipients of such information. Additionally, ONC direct oversight would ensure that, like with ONC-ACBs, testing labs are directly and immediately accountable to ONC for their performance across a variety of Program items including, but not limited to: Specifying and verifying testing personnel qualifications; requiring training sessions for testing lab personnel; establishing record documentation and retention requirements; and instituting methods for addressing inappropriate and incorrect testing methods and non-compliance with Program requirements.

b. Proposed Amendments To Include ONC-ATLs in the Program

This proposed rule proposes means for ONC to have direct oversight of NVLAP-accredited testing labs by having them apply to become ONC-ATLs. Specifically, this proposed rule proposes means for authorizing, retaining, suspending, and revoking ONC-ATL status under the Program. These proposed processes are similar to current ONC-ACB processes. In general, to seek and acquire authorization, an applicant must be NVLAP-accredited to ISO 17025, agree to the PoPC for ONC-ATLs, and comply with the proposed application documentation and procedural requirements. We propose that an ONC-ATL would retain its status for a three-year period that could be continually renewed as long as the ONC-ATL follows proposed good standing and testing requirements, including the PoPC for ONC-ATLs. To maintain proper oversight and the integrity of the Program, we propose criteria and means for ONC to suspend and revoke an ONC-ATL's status under the Program, which include opportunities for an ONC-ATL to become compliant and respond to a proposed suspension and/or revocation. We also request comment on whether we should revise § 170.570 to account for the possibility of an ONC-ATL having its status revoked for a Type-1 violation that called into question the legitimacy of certifications issued by an ONC-ACB.

The following sections detail each new and amended regulatory provisions that we propose for subpart E of part 170, starting with 45 CFR 170.501, in order to include ONC-ATLs as part of the Program. For authorization and other processes, we intend to follow and leverage all of the processes established for ONC-ACBs. Thus, most of our proposals are minimal conforming amendments to existing regulatory text that add in references to a testing lab or (once authorized) ONC-ATL.

(1) Proposed Amendments to § 170.501 Applicability

We propose to revise paragraph (a) of § 170.501 to include references to “applicants for ONC-ATL status;” “ONC-ATL;” and “ONC-ATL status.” The proposed revisions would make clear that ONC-ATLs are part of the rules under this subpart.

(2) Proposed Amendments to § 170.502 Definitions

We propose to revise the definition of the term “Applicant” in § 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 propose to revise the definition of the term “gap certification” in § 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 based those issued by an ONC-ATL. We also propose 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 propose 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.

(3) Proposed Amendments to § 170.505 Correspondence

In order to accurately reflect the addition of an applicant for ONC-ATL status and ONC-ATLs to the Program framework, we propose to revise § 170.505 to include references to ONC-ATL as appropriate.

(4) Proposed Amendment to § 170.510 Type of Certification

To make clear that § 170.510 is specifically geared toward applicants for ONC-ACB status and the authorization they may seek, we propose to revise the section heading to specifically reference the authorization scope of ONC-ACB status. We also propose to revise the introductory text within this section to more clearly convey that this section is solely focused on applicants for ONC-ACB status.

(5) Proposed Creation of § 170.511 Authorization Scope for ONC-ATL Status

We propose to create a new section (§ 170.511) to clearly define the scope of the authorization an “applicant” testing lab may be able to seek from the National Coordinator. We propose that such authorization be limited to the certification criteria adopted by the Secretary in subpart C of this part. However, to support specialized testing and testing efficiencies for health IT, we propose 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. The latter two options provide opportunities for entities that may perform industry testing of health IT for limited and/or distinct capabilities (e.g., e-prescribing) that align with certification criteria to participate in the Program. This approach could avoid duplicative testing and reduce regulatory burden for health IT developers that test and certify health IT under the Program and with entities outside of the Program.

(6) Proposed Amendments to § 170.520 Application

We propose to make the following amendments in order to establish the requirements that an applicant for ONC-ATL status must follow for its application for ONC-ATL status. First, we propose to reorder the regulatory text hierarchy to reference the ONC-ACB application requirements under § 170.520(a) and then the ONC-ATL application requirements under § 170.520(b). For the ONC-ATL requirements, we propose that an ONC-ATL applicant would need to seek authorization based on the scope proposed in § 170.511 and follow the same set of amended requirements as applicable to the different accreditation and PoPC to which ONC-ATLs would need to adhere. We propose that this 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 17025; and an agreement executed by the authorized representative to PoPC for ONC-ATLs.

(7) Proposed Amendment to § 170.523 Principles of Proper Conduct for ONC-ACBs

We propose to revise § 170.523(h) (PoPC for ONC-ACBs) to explicitly include ONC-ATLs as an entity from whom ONC-ACBs would receive test results (see proposed § 170.523(h)(1)). Additionally, to account for the transition period from NVLAP-accredited testing laboratories to ONC-ATLs, we propose to modify § 170.523(h) 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 (see proposed § 170.523(h)(2)). We believe this would provide more than adequate transition time for ONC-ACBs to continue to issue 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, however, request comment on our proposed approach to the transition period from NVLAP-accredited testing laboratories to ONC-ATLs. Specifically, we request 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. 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 request comment on whether the transition period should be shorter (e.g., three months) or longer (e.g., nine months) under either the proposed approach or the alternative approach.

We propose in § 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 and gap certification. As proposed, NVLAP-accredited testing laboratories would be replaced with ONC-ATLs. 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 certifying previously certified health IT to unchanged certification criteria and gap certification. As a related proposal, we propose to remove references to ONC-ATCBs in § 170.523(h). ONC-ATCBs 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.

(8) Proposed Creation of § 170.524 Principles of Proper Conduct for ONC-ATLs

Similar to the set of rules and conditions to which we require ONC-ACBs to adhere, we propose to establish a corresponding set of PoPC to which ONC-ATLs must adhere. Adherence to these conduct requirements would be necessary for ONC-ATLs to maintain their authorization and to remain in good standing under the Program. Many of the proposed PoPC for ONC-ATLs would remain consistent with those to which ONC-ACBs are already required to adhere. The proposed PoPC for ONC-ATLs include that an ONC-ATL shall:

• Maintain its accreditation through NVLAP based on the ISO 17025 standard;
• Attend all mandatory ONC training and program update sessions;
• Maintain a training program that includes documented procedures and training requirements to ensure its personnel are competent to test health IT;
• Report to ONC within 15 days any changes that materially affect its: Legal, commercial, organizational, or ownership status; organization and management including key testing personnel; policies or procedures; location; personnel, facilities, working environment or other resources; ONC authorized representative (point of contact); or other such matters that may otherwise materially affect its ability to test health IT;
• 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 Program;
• Consistent with the revisions recently adopted in the 2015 Edition final rule, to 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 three years from the effective date that removes the applicable edition from the Code of Federal Regulations; and to make the records available to HHS upon request during the retention period;
• Only test health IT (Complete EHRs and Health IT Modules) using test tools and test procedures approved by the National Coordinator; and
• Promptly refund any and all fees received for: Requests for testing while its operations are suspended by the National Coordinator; testing that will not be completed as a result of its conduct; and previous testing that it performed if its conduct necessitates the retesting of Complete EHRs and/or Health IT Modules.

(9) Proposed Amendments to § 170.525 Application Submission

To clearly recognize that testing labs would be applying for ONC-ATL status, we propose to include reference to an applicant for ONC-ATL status in paragraphs (a) and (b) of § 170.525 and to have the same rules that currently apply to applicants for ONC-ACB status apply to applicants for ONC-ATL status.

(10) Proposed Amendments to § 170.530 Review of Application

We propose to revise paragraphs (c)(2), (c)(4), (d)(2), and (d)(3) of § 170.530 to equally reference that an ONC-ATL could be part of the application review process. Further, in so doing, we propose to follow all of the same application review steps and processes that we currently follow for applicants for ONC-ACB status.

(11) Proposed Amendments to § 170.535 ONC-ACB Application Reconsideration

We propose to revise this section's heading to include reference to ONC-ATLs. Additionally, we propose to revise paragraphs (a) and (d)(1) of § 170.535 to equally reference that an ONC-ATL could be part of the application reconsideration process. Further, in so doing, we propose to follow all of the same application reconsideration steps and processes that we currently require and follow for applicants for ONC-ACB status.

(12) Proposed Amendments to § 170.540 ONC-ACB Status

We propose to revise this section's heading to include reference to ONC-ATLs. Additionally, we propose to revise paragraphs (a) through (d) of § 170.540 to equally reference an ONC-ATL as part of the rules currently governing the achievement of ONC-ACB status. These rules would include: The acknowledgement of ONC-ATL status; that the ONC-ATL must prominently and unambiguously identify the scope of its authorization; that ONC-ATL authorization must be renewed every three (3) years; and the expiration of ONC-ATL status (3 years from when it was granted unless renewed).

(13) Proposed Amendments to § 170.557 Authorized Certification Methods

We propose to revise this section's heading to include a reference to “testing.” Additionally, we propose to update the regulatory text hierarchy to have paragraph (a) be applicable to ONC-ATLs and paragraph (b) be applicable to ONC-ACBs. We have included this proposal for ONC-ATLs because 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) Proposed Amendments to § 170.560 Good Standing as an ONC-ACB

We propose to revise this section's heading to include reference to ONC-ATLs. Additionally, we propose 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. We believe mirroring these requirements between ONC-ACBs and ONC-ATLs provides for consistent administration for both testing and certification under the Program.

(15) Proposed Amendments to § 170.565 Revocation of ONC-ACB Status

We propose to revise this section's heading to include reference to ONC-ATLs. Additionally, we propose to revise paragraphs (a) through (h) to include references to an ONC-ATL as applicable. We propose to apply the same oversight paradigm of Type-1 and Type-2 ^[7] violations to ONC-ATLs as we apply to ONC-ACBs today. Further, we propose to follow the same process for ONC-ATLs as already included in this section for ONC-ACBs. We believe this consistency would enable ONC to treat similar fact-based non-compliance situations equitably among ONC-ACBs and ONC-ATLs. We propose 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 certification and simply referencing ONC-ATLs in that paragraph would cause confusion. Similarly, we propose 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 are applicable to ONC-ATLs. This proposed revision would place the current ONC-ACB applicable regulation text in proposed paragraph (h)(2).

(16) Request for Comment on § 170.570 in the Context of an ONC-ATL's Status Being Revoked

Section 170.570 discusses the general rule applicable to certifications issued to Complete EHRs and/or Health IT Modules in the event that an ONC-ACB has had its status revoked. It also includes specific 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 specifically 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 have not specifically proposed to modify § 170.570 to include a set of rules applicable to such a scenario. In large part, we do not believe that the same provisions are necessary given the tangible differences between test results for a not yet certified product and an issued certification being used by hundreds or thousands of providers for participation in other programs, HHS or otherwise. We do, however, request comment, whether there would be any circumstances in which additional clarity around the viability of test results attributed to a not yet certified product would be necessary. Additionally, we request 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 products by a potentially unknowing or deceived ONC-ACB.

B. Public Availability of Identifiable Surveillance Results

In the 2014 Edition final rule, for the purposes of increased Program 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, in the 2015 Edition final rule, we took steps to increase the transparency related to certified health IT through surveillance, disclosure, and reporting requirements. For instance, we now require ONC-ACBs to report corrective action plans and related data to the publicly accessible CHPL. The purpose of this reporting requirement, as described in the 2015 Edition final rule, was to ensure that health IT users, implementers, and purchasers are alerted to potential conformance issues in a timely and effective manner, consistent with the patient safety, program integrity, and transparency objectives of the 2015 Edition final rule.

In furtherance of our efforts to increase Program transparency and health IT developer accountability for their certified health IT, we propose to require ONC-ACBs to publicly publish on their Web sites identifiable surveillance results on a quarterly basis. 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. 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.

The publication of identifiable surveillance results, much like the publication of corrective action plans on the CHPL, would hold health IT developers more accountable to the customers and users of their certified health IT. Customers and users would be provided with valuable information about the continued performance of certified health IT as well as surveillance efforts. To elaborate, identifiable surveillance results would serve to inform providers 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 would motivate some health IT developers to improve their maintenance efforts, we believe that most published surveillance results would reassure customers and users of certified health IT. This is because, based on ONC-ACB surveillance results to date, most certified health IT and health IT developers are maintaining conformance with certification criteria and Program requirements. The publishing of such “positive” surveillance results would also provide a more complete context of surveillance; rather than only sharing “negatives,” such as non-conformities and corrective action plans.

We make clear that we do not propose to require that publicly posted surveillance results include certain information that is proprietary, trade secret, or confidential (e.g., “screenshots” that may include such information). We expect health IT developers and ONC-ACBs to ensure that such information is not posted when making available the information we propose would be required to be posted as noted above (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 request public comment on the publication of identifiable surveillance results. Specifically, we request 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 request comment on the value of publishing hyperlinks on the ONC Web site to the results on the ONC-ACBs' Web sites. This may provide stakeholders with a more readily available means for accessing all the results.

To implement the proposed new requirement, we propose to revise § 170.523(i) of the PoPC for ONC-ACBs by adding language that requires ONC-ACBs to make identifiable surveillance results publicly available on their Web sites on a quarterly basis. We also propose to revise § 170.556(e)(1) for clarity and consistency with § 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. Further, we propose to reestablish a requirement that ONC-ACBs submit an annual summative report of surveillance results to the National Coordinator. This previous requirement was unintentionally removed in the 2015 Edition final rule when we established a quarterly reporting requirement for surveillance results. Summative reports provide comprehensive summaries of the surveillance conducted throughout the year.

III. National Technology Transfer and Advancement Act

The National Technology Transfer and Advancement Act (NTTAA) of 1995 (15 U.S.C. 3701 et seq.) and the Office of Management and Budget (OMB) Circular A-119 ^[8] 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 this proposed rule, we propose to adopt one voluntary consensus standard (ISO 17025).

IV. Incorporation by Reference

The Office of the Federal Register has established requirements for materials (e.g., standards and implementation specifications) that agencies propose to incorporate by reference in the Federal Register (79 FR 66267; 1 CFR 51.5(a)). Specifically, § 51.5(a) requires agencies to discuss, in the preamble of a proposed rule, the ways that the materials it proposes to incorporate by reference are reasonably available to interested parties or how it worked to make those materials reasonably available to interested parties; and summarize, in the preamble of the proposed rule, the material it proposes to incorporate by reference. To make the materials we intend to incorporate by reference reasonably available, we provide a uniform resource locator (URL) to the standard. The standard must be purchased to obtain access. Alternatively, a copy of the standard may be viewed for free at the U.S. Department of Health and Human Services, Office of the National Coordinator for Health Information Technology, 330 C Street SW., Washington, DC 20201. Please call [phone] in advance to arrange inspection. As required by § 51.5(a), we also provide a summary of the standard we propose to adopt and subsequently 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 17025) is available for purchase on the ISO Web site at: http://www.iso.org/​iso/​catalogue_​detail.htm?​csnumber=​39883.

Summary: Accreditation bodies that recognize the competence of testing and calibration laboratories should use ISO 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 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.

V. Response to Comments

Because of the large number of public comments normally received in response to Federal Register documents, we are not able to acknowledge or respond to them individually. We will consider all comments we receive by the date and time specified in the DATES section of this preamble, and, when we proceed with a subsequent document, we will respond to the comments in the preamble of that document.

VI. 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 the 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.

A. ONC-AA and ONC-ACBs

Under the ONC Health IT Certification 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 less 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.

B. ONC-ATLs

We estimate less than ten annual respondents for all of the proposed regulatory “collection of information” requirements for ONC-ATLs under Part 170 of Title 45. Accordingly, the regulatory “collection of information” requirements under the Program described in this section are 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-ATLs, which are collection activities that would occur during administrative actions or investigations involving ONC against an ONC-ATL.

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 anticipate that there will be no more than eight ONC-ATLs participating in the Program. There are currently only five accredited testing labs under the Program. We estimate that up to three more testing labs may consider becoming accredited and seek ONC-ATL status because of our proposal to permit granting ONC-ATL status to an accredited testing lab for the testing of health IT to one certification criterion or only a partial certification criterion.

We welcome comments on these conclusions and the supporting rationale on which they are based.

The specific “collection of information” requirements that apply to ONC-ATLs are found in § 170.520(b); proposed § 170.524(d) and (f); and § 170.540(c). We have estimated the burden hours for these requirements in case our conclusions above are found to be misguided based on public comments or other reasons. Our estimates for the total burden hours are expressed in the table below. The estimated total burden hours are based on an estimated five respondents (ONC-ATLs) for the reasons noted above. With similar requirements to ONC-ACBs, we estimate the same number of burden hours for ONC-ATLs to comply with §§ 170.520(b) and 170.540(c) as cited in the 2015 Edition proposed rule (80 FR 16894). We also make the same determination for ONC-ATL records retention requirements under proposed § 170.524(f) as we did for the ONC-ACB records retention requirements (i.e., no burden hours) (80 FR 16894). We have estimated two responses per year at one hour per response for ONC-ATLs to provide updated contact information to ONC per § 170.524(d). We welcome comments on our burden hour estimates. We also welcome comments on the estimated costs associated with these proposed collection of information requirements, which can be found in section VII (“Regulatory Impact Statement”) of this preamble.

Estimated Annualized Total Burden Hours

Type of respondent	Code of federal regulations section	Number of respondents	Number of responses per respondent	Average burden hours per response	Total burden hours
ONC-ATL	45 CFR 170.520(b)	8	1	1	8
ONC-ATL	45 CFR 170.524(d)	8	2	1	16
ONC-ATL	45 CFR 170.524(f)	8	n/a	n/a	n/a
ONC-ATL	45 CFR 170.540(c)	8	1	1	8
Total burden hours for all collections of information					32

C. Health IT Developers

We propose 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 corrective action plan to correct a non-conformity or suspending or terminating a certification for a Complete EHR or Health IT Module). The PRA, however, exempts these information collections. Specifically, 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.

VII. Regulatory Impact Statement

A. Statement of Need

The proposed rule proposes to establish processes for ONC to expand its role to directly review health IT certified under the Program and take action when necessary, including 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. These processes would serve to address non-conformities, particularly those that may pose a risk to public health or safety or create other exigent circumstances that are inconsistent with section 3001(b) of the PHSA. The Program does not currently have regulatory means for reviewing and addressing such non-conformities and reliance on ONC-ACBs is not appropriate due to their limited scope of responsibilities, expertise, and resources. Therefore, we propose to establish processes for ONC to address these situations.

The proposed rule also proposes processes for ONC to timely and directly address testing issues. These processes do not exist today under the current Program structure, particularly as compared to ONC's oversight of ONC-ACBs. In addition, the proposed rule includes a provision for the increased transparency and availability of identifiable surveillance results. The publication of identifiable surveillance results would support 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 for enhanced oversight by ONC described in this proposed rule (i.e., the direct review of certified health IT and the authorization and oversight of accredited testing labs (ONC-ATLs)). One less stringent alternative would be to maintain our current approach for the Program in which ONC-ACBs have sole responsibility for issuing and administering certifications in accordance with ISO 17065, the PoPC for ONC-ACBs, and other requirements of the Program. This approach would also leave the testing structure as it currently exists. A second more stringent alternative to what we proposed would be for ONC to take further responsibility for the testing, certification, and ongoing compliance of health IT with Program requirements by making testing and certification determinations and/or reviewing all determinations made under the Program. We believe either approach would be misguided.

The current approach would leave no means for ONC to address non-conformities in certified health IT that are contrary to the National Coordinator's responsibilities under section 3001(b) of the PHSA and, as discussed in this proposed rule, ONC-ACBs are not situated to address these types of non-conformities. 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 would 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. Accordingly, and for the reasons outlined in this proposed rule, we do not believe maintaining the Program as currently structured is acceptable.

We fully considered the Program structure when establishing the Program and have made appropriate modifications as the Program has evolved (see the discussion in section I.A of this preamble for a summary of rulemaking related to the Program and citations for the relevant rules). 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. As discussed in this proposed rule, ONC-ACBs play an integral role in the Program and have the necessary expertise and capacity to effectively administer specific Program requirements. Accredited testing labs also play an integral role in the Program's success through the testing of health IT. Our proposals in this proposed rule align with past considerations and would only serve to enhance the Program by providing more consistency and accountability for Program participants, which would provide greater confidence in certified health IT when it is implemented, maintained, and used.

We welcome comments on our assessment of alternatives and any alternatives that we should also consider.

C. Overall Impact

We have examined the impact of this proposed 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). OMB has determined that this proposed rule is an economically significant rule as the potential costs associated with this proposed rule could be greater than $100 million per year. Accordingly, we have prepared an RIA that to the best of our ability presents the costs and benefits of the proposed rule.

a. Costs

We estimated the potential monetary costs of this proposed rule for health IT developers, ONC-ATLs, the Federal government (i.e., ONC), and health care providers 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 ONC review and inquiry into certified health IT non-conformities; (3) costs to health IT developers and ONC associated with the proposed appeal process following a suspension/termination of a Complete EHR's or Health IT Module's certification; (4) costs to 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 post identifiable surveillance results. We also provide an overall annual monetary cost estimate for this proposed 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.

We have made employee assumptions about the level of expertise needed to complete the proposed requirements in this section. We have 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 have assumed that an applicant expends one hundred percent (100%) of an employee's hourly wage on benefits for the employee. Therefore, we have doubled the employee's hourly wage to account for benefits. We have concluded that a 100% expenditure on benefits is an appropriate estimate based on research conducted by HHS.

We have used the General Schedule Federal Salary Classification for private sector employee wage calculations because the majority of the proposed 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 estimate costs for specialized testing labs personnel to support accreditation, we also estimate 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.

We welcome comments on our methodology for estimating employee costs, including whether there are appropriate BLS occupational classifications and wages that we should instead use to estimate employee costs and the costs of the tasks and requirements proposed in this proposed rule.

(1) Costs for Health IT Developers To Correct a Non-Conformity Identified by ONC

We do not believe health IT developers face additional direct costs for the proposed ONC direct review of certified health IT, including the National Coordinator fulfilling the responsibilities of section 3001(b) of the PHSA. There are no new certification requirements proposed in this proposed rule. Health IT developers have already been certified to applicable certification criteria and other Program requirements. Further, health IT developers should already be ensuring that their certified health IT is not, for example, creating public health and/or safety issues by causing medical errors or leaving a patient's health information unprotected in violation of applicable law (e.g., in violation of the Health Insurance Portability and Accountability Act). However, we acknowledge that this proposed rule may: (1) Lead health IT developers to reassess whether their certified health IT is conformant; and (2) require health IT developers to correct non-conformities found by ONC in their certified health IT.

We have been unable to estimate the costs for health IT developers to reassess their certified health IT for any non-conformities due to, but not limited to, the variability of health IT developers' certified technologies, current conformance, quality management systems, implementation of certified health IT, and resources. Additionally, we are not aware of relevant data or methodology we could use to estimate these costs. We do not, however, anticipate that this reassessment would result in substantial costs to health IT developers because health IT developers should have means for routinely evaluating their certified health IT for potential issues. We welcome comment on relevant data and methods we could use to estimate these costs.

If ONC identifies a non-conformity with a health IT developer's certified health IT, the costs incurred by the health IT developer to bring the product into conformance would be determined on a case-by-case basis. If ONC found a non-conformity with a certified capability related to a certification criterion, then the costs are not truly a result of this proposed rule because a health IT developer's product should remain conformant to those criteria and the costs to meet certification criteria were previously estimated in the 2014 Edition final rule and the 2015 Edition final rule. Alternatively, ONC could find either that certified health IT is causing medical errors or contributing to a patient's health information being unsecured and unprotected in violation of applicable law. In either instance, the monetary costs to correct the non-conformity would likely vary significantly based on factors such as the cause of the non-conformity and how easily it could be corrected. We are unable to reliably estimate these costs as we do not have cost estimates for a comparable situation. We request comment on existing relevant data and methods we could use to estimate these costs.

(2) Costs for ONC and Health IT Developers Related to ONC Review and Inquiry Into Certified Health IT Non-Conformities

ONC would have broad discretion to review certified health IT. However, we anticipate that such review would be relatively infrequent and would 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 400 hours of staff time to provide ONC with all requested records and documentation that ONC would use to make a suspension and/or termination determination. We assume 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 would, on average, range from $9,819 to $49,096. 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.

We estimate that ONC may commit, on average and depending on complexity, between 20 and 600 hours of staff time to complete a review and inquiry into certified health IT. We assume that the expertise of a GS-15, Step 1 federal employee(s) would be necessary. Therefore, we estimate the cost for ONC to review and conduct an inquiry into certified health IT would, on average, range from $2,455 to $73,644. We note that some reviews and inquiries may cost less and some may cost more than this estimated cost range.

We welcome comment on our estimated costs and any comparable processes and costs that we could use to improve our cost estimates. We intend to continue to conduct fact-finding in an effort to provide more reliable cost estimates in a subsequent final rule.

(3) Costs to Health IT Developers and ONC Associated With the Proposed 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 preamble, we propose in § 170.580(f) to permit 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 assume 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 would, 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.

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 for the hearing officer. We assume that the expertise of a GS-15, Step 1 federal employee(s) would be necessary. Therefore, we estimate the cost for ONC to conduct an appeal would, 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.

We welcome comment on our estimated costs and any comparable processes and costs that we could use to improve our cost estimates. We intend to continue to conduct fact-finding in an effort to provide more reliable cost estimates in a subsequent final rule.

(4) Costs to 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 proposed 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 proposals in this proposed 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 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.^[9] Only 48 eligible professionals (EPs) attested under the Medicare EHR Incentive Program to using these 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.^[10] Those 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 in this proposed rule to work with health IT developers to correct non-conformities found in their certified health IT under the provisions in this proposed rule, it is highly unlikely that the high end of our estimated costs for health care providers would ever be realized.

We estimated the monetary costs that would 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 would 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 ^[11] ). The estimated upfront cost for health care providers is calculated 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 estimation is consistent with other analyses on average costs.^[12]

This analysis and cost estimates do 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 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). The upper and lower thresholds were calculated 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.^[13] The median and mean impacts also were calculated using the number of reported attestations for each product (see “Cost Impact to Health Care Providers” table). 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.

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 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 welcome comment on our proposed approach and cost estimates as well as the identification of any reliable data upon which we could base or revise our cost estimates in a subsequent final rule.

We note that health IT developers may be required to pay for transition costs of health care providers due to certification termination. A complete presentation regarding who bears these costs is excluded from our analysis because arrangements would vary by contract and we do not have relevant data upon which to base an estimate.

(5) Costs for ONC-ATLs and ONC Associated With ONC-ATL Accreditation, Application, Renewal, and Reporting Requirements

Costs for the Applicant/ONC-ATL

An applicant for ONC-ATL status would be required to submit an application and must be accredited in order to be a qualified ONC-ATL applicant. As specified in section VI.B of this preamble, we estimate that there would be between five and eight applicants, five of which are already accredited by NVLAP to ISO 17025 and up to three new applicants. Any new applicants for ONC-ATL status under the Program would first be required to become accredited by NVLAP to ISO 17025.

Based on our consultations with NIST, we estimate that it would 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.). Proposed § 170.511 would permit the authorization of ONC-ATLs for testing to one or even a partial certification criterion. Based on consultations with NIST, this would 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 would each incur the full scope on-site assessment fee of $11,000, as discussed below. We anticipate the potential three new applicants would each incur a limited scope on-site assessment fee of $8,000, as discussed below.

We estimate the applicant staff time necessary to prepare and participate in the full scope on-site assessment at 200 hours, which is consistent with the estimate we used for ONC-ACBs based on stakeholder feedback (76 FR 1316). We estimate the applicant staff time necessary to prepare and participate in the limited scope on-site assessment at 100 hours, which is half the estimate for the full scope on-site assessment. We believe an employee equivalent to a GS-15, Step 1 federal employee would 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 $24,548 and the applicant staff cost for the limited scope on-site assessment at $12,274.

We anticipate that ONC-ATLs would incur an estimated $5,000 accreditation administrative/technical support fee each year during the three-year ONC-ATL authorization period.^[14] 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 would each incur the on-site assessment fee twice during their initial three-year ONC-ATL authorization period and the current five accredited testing labs would incur the on-site assessment fee once during the same period. Further, as stated above, each full scope on-site assessment for all criteria would cost approximately $11,000 and each limited scope on-site assessment would cost approximately $8,000. We estimate that staff expertise and cost for renewal is likely to remain consistent at approximately $24,548 for a full scope on-site assessment and $12,274 for a limited scope on-site assessment. We expect that each ONC-ATL would renew its status, meaning it would request reauthorization from ONC to be an ONC-ATL, every three years.

After becoming accredited by NVLAP, an applicant for ONC-ATL status would incur minimal costs to prepare and submit an application to the National Coordinator. We believe that it would take ten minutes to provide the general information requested in the application, 30 minutes to assemble the information necessary to provide documentation of accreditation by NVLAP, and 20 minutes to review and agree to the PoPC for ONC-ATLs. We believe these time estimates would also be accurate for an ONC-ATL to complete the proposed status renewal process. Based on our consultations with NIST, we believe 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 believe 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 $75.04.

Overall, we estimate that the total cost of ONC-ATL accreditation, application, and the first proposed three-year authorization period would be approximately $55,623 and the total cost for up to three new applicants would be approximately $166,869. We assume that ONC-ATLs would 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 $50,623 and the total renewal cost for all five current ONC-ATLs to be approximately $253,115. Based on our cost estimate timeframe of three years, the annualized renewal cost would be approximately $84,372.

We propose in § 170.524(d) that ONC-ATLs shall report various changes to their organization within 15 days. We believe 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 preamble, we estimate two responses per year at one hour per response for ONC-ATLs to provide updated information to ONC per § 170.524(d). Accordingly, we estimate it would cost each ONC-ATL $102.40 annually to meet this requirement. To estimate the highest possible cost, we assume that the eight applicants we estimate would apply to become ONC-ATLs would become ONC-ATLs. Therefore, we estimate the total annual cost for ONC-ATLs to meet the requirements of proposed § 170.524(d) to be $819.

We propose in § 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 believe this time period is in line with common industry practices. Consequently, it does not represent an additional cost to ONC-ATLs.

We welcome comments on our methodology and estimated costs.

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 would be costs associated with reviewing applications under the Program. We expect that a GS-15, Step 1 federal employee would review the applications and ONC (or a designated representative) would issue final decisions on all applications. We anticipate that it would 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, the annualized cost to ONC would be $992. These costs would be the same for a new applicant or ONC-ATL renewal.

As proposed, we would also post the names of applicants granted ONC-ATL status on our Web site. We believe there would 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 believe there would 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.

We welcome comments on our methodology and estimated costs.

(6) Costs for ONC-ATLs and ONC Related To Revoking ONC-ATL Status

As discussed in section II.A.2.b.(15) of this preamble, we propose to revise § 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 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 an ONC-ATL to comply with ONC requests per § 170.565 would, on average, range from $2,455 to $19,638. 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 § 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.

We welcome comment on our estimated costs and any comparable processes and costs that we could use to improve our cost estimates. We intend to continue to conduct fact-finding in an effort to provide more reliable cost estimates in a subsequent final rule.

(7) Costs for ONC-ACBs To Publicly Post Identifiable Surveillance Results

In section II.B of this preamble, we propose to require ONC-ACBs to make identifiable surveillance results publicly available on their Web sites on a quarterly basis. We believe that an employee equivalent to a GS-9, Step 1 federal employee could post the surveillance results. We believe it would take the employee no more than four hours annually to prepare and post the surveillance results. 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 post surveillance results to be $205 and the total cost for all ONC-ACBs to be $615.

(8) Total Annual Cost Estimate

We estimate the total annual cost for this proposed rule, based on the cost estimates outlined above, would range from $230,616 to $650,288,915 with an average annual cost of $6,595,268.

b. Benefits

The proposed rule's provisions for ONC direct review of certified health IT would 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 would permit ONC to assess non-conformities and prescribe comprehensive corrective actions for health IT developers to address non-conformities, including notifying affected customers. As previously stated, our first and foremost goal would be 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 proposals in this proposed rule, such action would 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 believe that ONC direct review supports and enables the National Coordinator to fulfill his/her responsibilities under the HITECT Act, instills public confidence in the Program, and protects public health and safety.

The proposed rule's provisions would also provide other benefits. The proposals for ONC to authorize and oversee testing labs (ONC-ATLs) would facilitate further public confidence in testing and certification by permitting ONC to timely and directly address testing issues for health IT. The proposed public availability of identifiable surveillance results would enhance transparency and the accountability of health IT developers to their customers. This proposal would provide customers and users of certified health IT with valuable information about the continued performance of certified health IT as well as surveillance efforts. Further, the public availability of identifiable surveillance results would likely benefit health IT developers by providing a more complete context of surveillance and illuminating good performance and the continued compliance of certified health IT with Program requirements. Again, while we do not have available means to quantify these benefits, we believe these proposed approaches, if finalized, would improve Program compliance and further public confidence in certified health IT.

We welcome comment on potential means, methods, and relevant comparative studies and data that we could use to quantify these benefits. To note, we do not have data to establish how often we would need to exercise direct review, the extent of existing and future non-conformities, and the likely outcomes that would be achieved by ONC review, including up to preventing the loss of life. Similarly, we do not have data to establish that our proposals 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, including greater adoption of certified health IT. We also welcome comment on other benefits, quantifiable and non-quantifiable, which could be achieved through the proposals we have put forth in this proposed rule.

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.^[15] The entities that are likely to be directly affected by this proposed final rule are applicants for ONC-ATL status and health IT developers.

We estimate up to eight applicants for ONC-ATL status. These applicants would be 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.” ^[16] The SBA size standard associated with this NAICS code is set at $15 million annual receipts or less. As specified in section VII.C above, we estimate minimal costs for applicants for ON-ATL status to apply and participate in the Program as ONC-ATLs. We believe that we have proposed the minimum amount of requirements necessary to accomplish our goal of enhanced oversight of testing under the Program. As discussed under section VII.B above, there are also no appropriate regulatory or non-regulatory alternatives that could be developed to lessen the compliance burden associated with this proposed 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.

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 proposed rule most likely fall under the North American Industry Classification System (NAICS) code 541511 “Custom Computer Programming Services.” ^[17] 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 the 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 is 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.

We estimate that this proposed rule would 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 because health IT developers may need to reassess their health IT to verify compliance with the Program requirements outlined in this proposed rule and they may have their certified health IT subjected to a corrective action, suspension, and/or termination under the provisions of this proposed rule. We believe, however, that we have proposed 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 under section VII.B above, there are no appropriate regulatory or non-regulatory alternatives that could be developed to lessen the compliance burden associated with this proposed rule as this proposed rule places no new requirements on health IT developers, unless their certified health IT is reviewed by ONC and found to have a non-conformity.

We do not believe that the proposed rule would create a significant impact on a substantial number of small entities, but request comment on whether there are small entities that we have not identified that may be affected in a significant way by this proposed rule. Additionally, the Secretary proposes to certify that this proposed rule would 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 proposed 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 proposals in this proposed rule. We welcome comments on this assessment.

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 the estimated potential cost effects of this proposed rule reach the statutory threshold, we do not believe this proposed rule imposes unfunded mandates on state, local, and tribal governments or the private sector. As described under section VII.C.1 above, we estimate the potential monetary costs for the private sector (health IT developers and health care providers), which would be the result of a health IT developer not maintaining its product(s) compliance with voluntary Program requirements and having its product's certification terminated. The minimal monetary cost estimates for ONC-ATLs derive from voluntary participation in the Program and would be recouped through fees charged for the testing of health IT under the Program. We welcome comments on these conclusions.

OMB reviewed this proposed 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 proposed to be amended as follows:

PART 170—HEALTH INFORMATION TECHNOLOGY STANDARDS, IMPLEMENTATION SPECIFICATIONS, AND CERTIFICATION CRITERIA AND CERTIFICATION PROGRAMS FOR HEALTH INFORMATION TECHNOLOGY

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.

2. Amend § 170.501 by revising paragraph (a) to read as follows:

§ 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. It also 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. Further, this subpart establishes the processes accreditation organizations must follow to request approval from the National Coordinator and that the National Coordinator in turn will follow to approve an accreditation organization under the ONC Health IT Certification Program as well as certain ongoing responsibilities for an ONC-AA.

* * * * *

3. Amend § 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:

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

* * * * *

4. Revise § 170.505 to read as follows:

§ 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 or express mail, the official date of receipt will be the date of the delivery confirmation.

5. Amend § 170.510 by revising the section heading and introductory text to read as follows:

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

* * * * *

6. Add § 170.511 to read as follows:

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

7. Revise § 170.520 to read as follows:

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

(1) The authorization scope sought pursuant to § 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 ISO 17025.

(4) An agreement, properly executed by the applicant's authorized representative, that it will adhere to the Principles of Proper Conduct for ONC-ATLs.

8. Amend § 170.523 by revising paragraphs (h) and (i) and adding paragraph (o) to read as follows:

§ 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 the authorization of the first ONC-ATL unless:

(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 as follows:

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

(3) Publicly publish identifiable surveillance results on its Web site on a quarterly basis.

(4) Annually submit a summative report of surveillance results.

* * * * *

(o) Be prohibited from reducing the scope of a certification when the health IT is under surveillance or under a corrective action plan.

9. Add § 170.524 to read as follows:

§ 170.524

Principles of proper conduct for ONC-ATLs.

An ONC-ATL shall:

(a) Maintain its NVLAP accreditation to ISO 17025;

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

10. Revise § 170.525 to read as follows:

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

11. Amend § 170.530 by revising paragraphs (c)(2), (4), (d)(2) and (3) to read as follows:

§ 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 § 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 applicable) and begin certifying or testing (as applicable) health information technology consistent with its authorization.

12. Amend § 170.535 by revising the section heading and paragraphs (a) and (d)(1) to read as follows:

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

* * * * *

13. Revise § 170.540 to read as follows:

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

14. Amend § 170.556 by revising paragraph (e)(1) to read as follows:

§ 170.556

In-the-field surveillance and maintenance of certification for health IT.

* * * * *

(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 on an ongoing basis throughout the calendar year and, at a minimum, in accordance with § 170.523(i)(2).

* * * * *

15. Revise § 170.557 to read as follows:

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

16. Revise § 170.560 to read as follows:

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

17. Revise § 170.565 to read as follows:

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

18. Add § 170.580 to read as follows:

§ 170.580

ONC review of certified health IT.

(a) Direct review. ONC may directly review certified health IT whenever there is reason to believe that the certified health IT may not comply with requirements of the ONC Health IT Certification Program.

(1) In determining whether to exercise such review, ONC shall consider:

(i) The potential nature, severity, and extent of the suspected non-conformity(ies), including the likelihood of systemic or widespread issues and impact.

(ii) The potential risk to public health or safety or other exigent circumstances.

(iii) The need for an immediate and coordinated governmental response.

(iv) Whether investigating, evaluating, or addressing the suspected non-conformity would:

(A) Require access to confidential or other information that is unavailable to an ONC-ACB;

(B) Present issues outside the scope of an ONC-ACB's accreditation;

(C) Exceed the resources or capacity of an ONC-ACB;

(D) Involve novel or complex interpretations or application of certification criteria or other requirements.

(v) The potential for inconsistent application of certification requirements in the absence of direct review.

(2) Relationship to ONC-ACB's oversight. (i) ONC's review of certified health IT is independent of, and may be in addition to, any review 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 other matters so intrinsically linked that divergent determinations between ONC and an ONC-ACB would be inconsistent with the effective administration or oversight of the ONC Health IT Certification Program.

(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 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 and refer the applicable part of the review to the relevant ONC-ACB(s) if ONC determines that doing so would be in the best interests of efficiency or the administration and oversight of the Program.

(b) Notice of potential non-conformity or non-conformity—(1) General. ONC will send a notice of potential non-conformity or notice of non-conformity to the health IT developer if it has information that certified health IT is not or may not be performing consistently with Program requirements.

(i) Potential non-conformity. ONC may require that the health IT developer respond in more or less time than 30 days based on factors such as, but not limited to:

(A) The type of certified health IT and certification in question;

(B) The type of potential non-conformity to be corrected;

(C) The time required to correct the potential non-conformity; and

(D) Issues of public health or safety or other exigent circumstances.

(ii) Non-conformity. ONC may require that the health IT developer respond and submit a proposed corrective action plan in more or less time than 30 days based on factors such as, but not limited to:

(A) The type of certified health IT and certification in question;

(B) The type of non-conformity to be corrected;

(C) The time required to correct the non-conformity; and

(D) Issues of public health or safety or other exigent circumstances.

(2) 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 agencies, and with appropriate entities:

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

(3) Health IT developer response. The health IT developer must include in its response all appropriate documentation and explain in writing why the certified health IT is conformant.

(c) Corrective action plan and procedures. (1) If ONC determines that certified health IT does not conform to Program requirements, ONC shall notify the health IT developer of the certified health IT of its findings 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. ONC shall prescribe such corrective action as may be appropriate to fully address the identified non-conformity(ies). The corrective action plan is required to include, at a minimum, for each non-conformity:

(i) A description of the identified non-conformity;

(ii) 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;

(iii) 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;

(iv) A detailed description of how the health IT developer will assess the scope and impact of the non-conformity, including:

(A) Identifying all potentially affected customers;

(B) How the health IT developer will promptly ensure that all potentially affected customers are notified of the non-conformity and plan for resolution;

(C) How and when the health IT developer will resolve issues for individual affected customers; and

(D) How the health IT developer will ensure that all issues are in fact resolved; and

(v) The timeframe under which corrective action will be completed.

(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 developer to submit a revised proposed corrective action plan.

(4) Upon fulfilling all of its obligations under the corrective action plan, the health IT developer must submit an attestation to ONC, which serves as a binding official statement by the health IT developer that it has fulfilled all of its obligations under the corrective action plan.

(5) 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)(4) of this section.

(d) Suspension. (1) ONC may suspend the certification of a Complete EHR or Health IT Module at any time for any one of the following reasons:

(i) 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;

(ii) 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)(i) of this section; or

(C) A notice of non-conformity within the timeframe established in accordance with paragraph (b)(1)(ii) of this section;

(iii) 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;

(iv) The health IT developer fails to timely submit a proposed corrective action plan that adequately addresses the elements required by ONC as described in paragraph (c) of this section;

(v) The health IT developer does not fulfill its obligations under the corrective action plan developed in accordance with paragraph (c) of this section.

(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) The information ONC relied upon to reach its 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 health IT developer's receipt of a notice of suspension.

(3) The health IT developer must notify all affected and potentially affected customers of the identified non-conformity(ies) and suspension of certification in a timely manner.

(4) If a certification is suspended, the health IT developer must cease and desist from any marketing 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 may rescind the suspension.

(5) Inherited certified status certification for a suspended Complete EHR or Health IT Module is not permitted until such time ONC rescinds the suspension.

(6) ONC will rescind a suspension of certification if the health IT developer completes all elements of an approved corrective action plan and/or ONC confirms that all non-conformities have been corrected.

(e) Termination. (1) ONC may 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)(i) of this section; or

(C) A notice of non-conformity within the timeframe established in accordance with paragraph (b)(1)(ii) of this section;

(ii) 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;

(iii) The health IT developer fails to timely submit a proposed corrective action plan that adequately addresses the elements required by ONC as described in paragraph (c) of this section;

(iv) The health IT developer does not fulfill its obligations under the corrective action plan developed in accordance with paragraph (c) of this section; or

(v) ONC concludes that a certified health IT's non-conformity(ies) cannot be cured.

(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) The information ONC relied upon to reach its 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 either upon:

(A) The expiration of the 10-day period for filing an appeal in paragraph (f)(3) of this section if an appeal is not filed by the health IT developer; or

(B) A final determination to terminate the certification per paragraph (f)(7) of this section if a health IT developer files an appeal.

(3) The health IT developer must notify affected and potentially affected customers of the identified non-conformity(ies) and termination of certification in a timely manner.

(4) If ONC determines that a Complete EHR or Health IT Module certification should not be terminated, ONC will notify the health IT developer in writing of this determination.

(f) 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 Program methodology, standards, or requirements for suspension or termination; or

(ii) ONC's determination was not sufficiently supported by the information used by ONC to reach the determination.

(2) Method and place for filing an appeal. 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 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. An appeal must be filed within 10 calendar days of receipt of the notice of suspension or notice of termination.

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

(6) Adjudication. (i) The hearing officer may make a determination based on:

(A) The written record as provided by the health IT developer with the appeal filed in accordance with paragraphs (f)(1) through (3) of this section and including any information ONC provides in accordance with paragraph (f)(6)(v) of this section; or

(B) All the information provided in accordance with paragraph (f)(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 (f)(6)(i)(A) of this section;

(B) Requires either party to answer questions regarding the written record under paragraph (f)(6)(i)(A) of this section; or

(C) Otherwise determines a hearing is necessary.

(iii) The hearing officer will 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 issued by ONC under paragraph (d)(2) or (e)(2) of this section.

(iv) The default process will be a determination in accordance with paragraph (f)(6)(i)(A) of this section.

(v) ONC will have an opportunity to provide the hearing officer with a written statement and supporting documentation on its behalf that explains its determination to suspend or terminate the certification. The written statement and supporting documentation must be included as part of the written record. 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, unless the health IT developer and ONC agree to a finite extension approved by the hearing officer.

(ii) The National Coordinator's determination on appeal, as issued by the hearing officer, is final and not subject to further review.

19. Add § 170.581 to read as follows:

§ 170.581

Consequences due to the termination of a certification.

(a) Testing and recertification. A Complete EHR or Health IT Module (or replacement version) that has had its certification terminated can be tested and recertified (certified) once all non-conformities have been adequately addressed.

(1) The recertified Complete EHR or Health IT Module (or replacement version) must maintain a scope of certification that, at a minimum, includes all the previous certified capabilities.

(2) The health IT developer must request, and have approved, permission to participate in the Program before testing and recertification (certification) may commence for the Complete EHR or Health IT Module (or replacement version).

(i) The request must include a written explanation of the steps taken to address the non-conformities that led to the termination.

(ii) ONC must approve the request to participate in the Program.

(b) Heightened scrutiny. Certified health IT that was previously the subject of a certification termination (or replacement version) shall be subject to heightened scrutiny for, at a minimum, one year.

(c) Program ban. The testing and certification of any health IT of a health IT developer that has the certification of one of its Complete EHRs or Health IT Modules terminated under the Program or withdrawn from the Program when the subject of a potential nonconformity or non-conformity is prohibited, unless:

(1) The non-conformity is corrected and implemented for 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.

Sylvia M. Burwell,

Secretary.

Footnotes

1.  The international standard to which ONC-ACBs are accredited. 45 CFR 170.599(b)(3).

2.  We defined Type-1 violations to 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 (45 CFR 170.565(a)).

3.  Shortly after publishing the 2015 Edition final rule, we issued updated guidance to ONC-ACBs on how to address these new requirements in their annual surveillance plans. See ONC, Program Policy Guidance #15-01A, https://www.healthit.gov/​sites/​default/​files/​policy/​2015-11-02_​supp_​cy_​16_​surveillance_​guidance_​to_​onc-acb_​15-01a_​final.pdf (November 5, 2015).

4.  The Freedom of Information Act and Uniform Trade Secrets Act generally govern the disclosure of these types of information.

5.  See CMS EHR Incentive Programs FAQ 12657: https://questions.cms.gov/​faq.php?​isDept=​0&​search=​decertified&​searchType=​keyword&​submitSearch=​1&​id=​5005.

6.  45 CFR 170.599(b)(3).

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

8.  http://www.whitehouse.gov/​omb/​circulars_​a119.

9.  http://www.hhs.gov/​news/​press/​2015pres/​09/​20150902c.html.

10.  http://www.hhs.gov/​about/​news/​2013/​04/​25/​certification-for-electronic-health-record-product-revoked.html.

11.  See CMS EHR Incentive Programs FAQ 12657: https://questions.cms.gov/​faq.php?​isDept=​0&​search=​decertified&​searchType=​keyword&​submitSearch=​1&​id=​5005.

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

13.  As of November 30, 2015.

14.  See NVLAP Fee Structure, http://www.nist.gov/​nvlap/​nvlap-fee-policy.cfm.

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

16.  https://www.sba.gov/​sites/​default/​files/​files/​Size_​Standards_​Table.pdf

17.  https://www.sba.gov/​sites/​default/​files/​files/​Size_​Standards_​Table.pdf