81 FR 11056 - ONC Health IT Certification Program: Enhanced Oversight and Accountability

DEPARTMENT OF HEALTH AND HUMAN SERVICES
Office of the Secretary

Federal Register Volume 81, Issue 41 (March 2, 2016)

Page Range11056-11085
FR Document2016-04531

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.

Federal Register, Volume 81 Issue 41 (Wednesday, March 2, 2016)
[Federal Register Volume 81, Number 41 (Wednesday, March 2, 2016)]
[Proposed Rules]
[Pages 11056-11085]
From the Federal Register Online  [www.thefederalregister.org]
[FR Doc No: 2016-04531]



[[Page 11055]]

Vol. 81

Wednesday,

No. 41

March 2, 2016

Part IV





Department of Health and Human Services





-----------------------------------------------------------------------





45 CFR Part 170





Medicare Program; FY 2015 Hospice Wage Index and Payment Rate Update; 
Hospice Quality Reporting Requirements and Process and Appeals for Part 
D Payment for Drugs for Beneficiaries Enrolled in Hospice; Proposed 
Rule

Federal Register / Vol. 81 , No. 41 / Wednesday, March 2, 2016 / 
Proposed Rules

[[Page 11056]]


-----------------------------------------------------------------------

DEPARTMENT OF HEALTH AND HUMAN SERVICES

Office of the Secretary

45 CFR Part 170

RIN 0955-AA00


ONC Health IT Certification Program: Enhanced Oversight and 
Accountability

AGENCY: Office of the National Coordinator for Health Information 
Technology, Department of Health and Human Services.

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

[[Page 11057]]

    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 Sec.  170.501 Applicability
    (2) Proposed Amendments to Sec.  170.502 Definitions
    (3) Proposed Amendments to Sec.  170.505 Correspondence
    (4) Proposed Amendment to Sec.  170.510 Type of Certification
    (5) Proposed Creation of Sec.  170.511 Authorization Scope for 
ONC-ATL Status
    (6) Proposed Amendments to Sec.  170.520 Application
    (7) Proposed Amendments to Sec.  170.523 Principles of Proper 
Conduct for ONC-ACBs
    (8) Proposed Creation of Sec.  170.524 Principles of Proper 
Conduct for ONC-ATLs
    (9) Proposed Amendments to Sec.  170.525 Application Submission
    (10) Proposed Amendments to Sec.  170.530 Review of Application
    (11) Proposed Amendments to Sec.  170.535 ONC-ACB Application 
Reconsideration
    (12) Proposed Amendments to Sec.  170.540 ONC-ACB Status
    (13) Proposed Amendments to Sec.  170.557 Authorized 
Certification Methods
    (14) Proposed Amendments to Sec.  170.560 Good Standing as an 
ONC-ACB
    (15) Proposed Amendments to Sec.  170.565 Revocation of ONC-ACB 
Status
    (16) Request for Comment on Sec.  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 
(Sec.  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

[[Page 11058]]

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

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

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

[[Page 11059]]

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

[[Page 11060]]

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 Sec.  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 Sec.  170.565 would, on average, range from $2,455 to 
$19,638. We estimate the cost for ONC would, on average, range from 
$4,910 to $39,277.
    We 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

[[Page 11061]]

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

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

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

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

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

[[Page 11062]]

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

[[Page 11063]]

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

    \4\ The Freedom of Information Act and Uniform Trade Secrets Act 
generally govern the disclosure of these types of 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 Sec.  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 Sec.  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 Sec.  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 Sec.  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 Sec.  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 Sec.  
170.556(d). The primary difference between this approach and the 
approach for ONC-ACBs in Sec.  170.556(d) is that in Sec.  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 Sec.  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 Sec.  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 
Sec.  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

[[Page 11064]]

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 Sec.  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 Sec.  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 Sec.  170.580(c); or
     The health IT developer does not fulfill its obligations 
under the corrective action plan developed in accordance with proposed 
Sec.  170.580(c).
    We note that section Sec.  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 Sec.  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 
Sec.  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 Sec.  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 
Sec.  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

[[Page 11065]]

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 Sec.  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 Sec.  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 Sec.  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 Sec.  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 Sec.  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 Sec.  170.580(f)(5). The hearing officer may not 
preside over an appeal in which he or she participated in the

[[Page 11066]]

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

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

(1) Program Ban and Heightened Scrutiny
    We propose in Sec.  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 Sec.  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 Sec.  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

[[Page 11067]]

prohibition. Additionally, consistent with this and the other proposed 
requirements of Sec.  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.
---------------------------------------------------------------------------

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

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

[[Page 11068]]

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 Sec.  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 Sec.  170.501 Applicability
    We propose to revise paragraph (a) of Sec.  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 Sec.  170.502 Definitions
    We propose to revise the definition of the term ``Applicant'' in 
Sec.  170.502 to include a corresponding reference to ONC-ATL in order 
for such term to have equal meaning in the case of a testing lab that 
is applying for ONC-ATL status.
    We propose to revise the definition of the term ``gap 
certification'' in Sec.  170.502 to include a corresponding reference 
to ONC-ATL in paragraph (1) of that definition in order to give equal 
weight to test results 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 Sec.  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 Sec.  170.505 to include references to ONC-ATL as appropriate.
(4) Proposed Amendment to Sec.  170.510 Type of Certification
    To make clear that Sec.  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 Sec.  170.511 Authorization Scope for ONC-ATL 
Status
    We propose to create a new section (Sec.  170.511) to clearly 
define the scope of the authorization an ``applicant'' testing lab may 
be able to seek from the National Coordinator. We 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 Sec.  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 Sec.  170.520(a) and then the ONC-ATL application 
requirements under Sec.  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 Sec.  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 Sec.  170.523 Principles of Proper Conduct 
for ONC-ACBs
    We propose to revise Sec.  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 Sec.  170.523(h)(1)). Additionally, 
to account for the transition period from NVLAP-accredited testing 
laboratories to ONC-ATLs, we propose to modify Sec.  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

[[Page 11069]]

laboratory (see proposed Sec.  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 Sec.  170.523(h)(2) to permit the use of test results 
from a NVLAP-accredited testing laboratory for certifying previously 
certified health IT to unchanged certification criteria 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 Sec.  
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 Sec.  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 Sec.  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 Sec.  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 Sec.  170.530 Review of Application
    We propose to revise paragraphs (c)(2), (c)(4), (d)(2), and (d)(3) 
of Sec.  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 Sec.  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 Sec.  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 Sec.  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 Sec.  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 Sec.  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 Sec.  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

[[Page 11070]]

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

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

(16) Request for Comment on Sec.  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 Sec.  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

[[Page 11071]]

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 
Sec.  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 Sec.  170.556(e)(1) for clarity and consistency with Sec.  
170.523(i)(2) by adding that the ongoing submission of in-the-field 
surveillance results to the National Coordinator throughout the 
calendar year must, at a minimum, be done on a quarterly basis. 
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).
---------------------------------------------------------------------------

    \8\ http://www.whitehouse.gov/omb/circulars_a119.
---------------------------------------------------------------------------

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, Sec.  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 (202) 690-7171 in advance 
to arrange inspection. As required by Sec.  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.

[[Page 11072]]

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 Sec.  170.520(b); proposed Sec.  170.524(d) 
and (f); and Sec.  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 Sec. Sec.  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 
Sec.  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 Sec.  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
--------------------------------------------------------------------------------------------------------------------------------------------------------
                                                                                                             Number of    Average burden
              Type of respondent                   Code of federal regulations section       Number of     responses per     hours per     Total burden
                                                                                            respondents     respondent       response          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
rrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr
    Total burden hours for all collections of   ........................................  ..............  ..............  ..............              32
     information.
--------------------------------------------------------------------------------------------------------------------------------------------------------

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

[[Page 11073]]

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

[[Page 11074]]

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

[[Page 11075]]

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

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

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

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

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

    \13\ As of November 30, 2015.

                                      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.

[[Page 11076]]

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

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

    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 Sec.  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 Sec.  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 Sec.  170.524(d) to be $819.
    We propose in Sec.  170.524(f) that ONC-ATLs shall retain all 
records related to the testing of Complete EHRs and Health IT Modules 
to an edition of certification criteria for a minimum of three years 
from the effective date that removed the applicable edition from the 
Code of Federal Regulations. Based on our consultations with NIST, we 
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

[[Page 11077]]

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 Sec.  170.565 to apply the same process for ONC-ATL status 
revocation as applies to ONC-ACBs. We estimate that an ONC-ATL may 
commit, on average and depending on complexity, between 20 and 160 
hours of staff time to provide responses and information requested by 
ONC. We assume that the expertise of the employee(s) needed to comply 
with ONC's requests 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 Sec.  
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 Sec.  170.565 related to ONC-ATLs. We assume that the 
expertise of a GS-15, Step 1 federal employee(s) would be necessary. 
Therefore, we estimate the cost for ONC would, on average, range from 
$4,910 to $39,277. We note that in some instances the costs may be less 
and in other instances the costs may exceed this estimated cost range.
    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

[[Page 11078]]

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

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

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

    \16\ https://www.sba.gov/sites/default/files/files/Size_Standards_Table.pdf
---------------------------------------------------------------------------

    While health IT developers that pursue certification of their 
health IT under the Program represent a small segment of the overall 
information technology industry, we believe that many health IT 
developers impacted by this 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.
---------------------------------------------------------------------------

    \17\ https://www.sba.gov/sites/default/files/files/Size_Standards_Table.pdf
---------------------------------------------------------------------------

    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.

[[Page 11079]]

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

0
1. The authority citation for part 170 continues to read as follows:

    Authority:  42 U.S.C. 300jj-11; 42 U.S.C. 300jj-14; 5 U.S.C. 
552.

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


Sec.  170.501  Applicability.

    (a) This subpart establishes the processes that applicants for ONC-
ACB status must follow to be granted ONC-ACB status by the National 
Coordinator; the processes the National Coordinator will follow when 
assessing applicants and granting ONC-ACB status; the requirements that 
ONC-ACBs must follow to maintain ONC-ACB status; and the requirements 
of ONC-ACBs for certifying Complete EHRs, Health IT Module(s), and 
other types of health IT in accordance with the applicable 
certification criteria adopted by the Secretary in subpart C of this 
part. 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.
* * * * *
0
3. Amend Sec.  170.502 by revising the definitions of ``Applicant'' and 
``Gap certification'' and by adding the definition of ``ONC-Authorized 
Testing Lab or ONC-ATL'' in alphabetical order to read as follows:


Sec.  170.502  Definitions.

* * * * *
    Applicant means a single organization or a consortium of 
organizations that seeks to become an ONC-ACB or ONC-ATL by submitting 
an application to the National Coordinator for such status.
* * * * *
    Gap certification means the certification of a previously certified 
Complete EHR or Health IT Module(s) to:
    (1) All applicable new and/or revised certification criteria 
adopted by the Secretary at subpart C of this part based on test 
results issued by a NVLAP-accredited testing laboratory under the ONC 
Health IT Certification Program or an ONC-ATL; and
    (2) All other applicable certification criteria adopted by the 
Secretary at subpart C of this part based on the test results used to 
previously certify the Complete EHR or Health IT Module(s) under the 
ONC Health IT Certification Program.
* * * * *
    ONC-Authorized Testing Lab or ONC-ATL means an organization or a 
consortium of organizations that has applied to and been authorized by 
the National Coordinator pursuant to this subpart to perform the 
testing of Complete EHRs and Health IT Modules to certification 
criteria adopted by the Secretary at subpart C of this part.
* * * * *
    4. Revise Sec.  170.505 to read as follows:


Sec.  170.505  Correspondence.

    (a) Correspondence and communication with ONC or the National 
Coordinator shall be conducted by email, unless otherwise necessary or 
specified. The official date of receipt of any email between ONC or the 
National Coordinator and an accreditation organization requesting ONC-
AA status, the ONC-AA, an applicant for ONC-ACB status, an applicant 
for ONC-ATL status, an ONC-ACB, an ONC-ATL, health IT developer, or a 
party to any proceeding under this subpart is the date on which the 
email was sent.
    (b) In circumstances where it is necessary for an accreditation 
organization requesting ONC-AA status, the ONC-AA, an applicant for 
ONC-ACB status, an applicant for ONC-ATL status, an ONC-ACB, an ONC-
ATL, health IT developer, or a party to any proceeding under this 
subpart to correspond or communicate with ONC or the National 
Coordinator by regular or express mail, the official date of receipt 
will be the date of the delivery confirmation.
0
5. Amend Sec.  170.510 by revising the section heading and introductory 
text to read as follows:


Sec.  170.510  Authorization scope for ONC-ACB status.

    Applicants for ONC-ACB status may seek authorization from the 
National Coordinator to perform the following types of certification:
* * * * *
0
6. Add Sec.  170.511 to read as follows:


Sec.  170.511  Authorization scope for ONC-ATL status.

    Applicants may seek authorization from the National Coordinator to 
perform the testing of Complete EHRs or Health IT Modules to a portion 
of a certification criterion, one certification criterion, or many or 
all certification criteria adopted by the Secretary under subpart C of 
this part.
0
7. Revise Sec.  170.520 to read as follows:


Sec.  170.520  Application.

    (a) ONC-ACB application. Applicants must include the following 
information in an application for ONC-ACB status and submit it to the 
National Coordinator for the application to be considered complete.
    (1) The type of authorization sought pursuant to Sec.  170.510. For 
authorization to perform Health IT Module certification, applicants 
must indicate the specific type(s) of Health IT Module(s) they seek 
authorization to certify. If qualified, applicants will only be granted 
authorization to certify the type(s) of Health IT Module(s) for which 
they seek authorization.
    (2) General identifying, information including:
    (i) Name, address, city, state, zip code, and Web site of 
applicant; and
    (ii) Designation of an authorized representative, including name, 
title, phone number, and email address of the person who will serve as 
the applicant's point of contact.
    (3) Documentation that confirms that the applicant has been 
accredited by the ONC-AA.
    (4) An agreement, properly executed by the applicant's authorized 
representative, that it will adhere to the Principles of Proper Conduct 
for ONC-ACBs.
    (b) ONC-ATL application. Applicants must include the following 
information

[[Page 11080]]

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 Sec.  170.511.
    (2) General identifying, information including:
    (i) Name, address, city, state, zip code, and Web site of 
applicant; and
    (ii) Designation of an authorized representative, including name, 
title, phone number, and email address of the person who will serve as 
the applicant's point of contact.
    (3) Documentation that confirms that the applicant has been 
accredited by NVLAP to 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.
0
8. Amend Sec.  170.523 by revising paragraphs (h) and (i) and adding 
paragraph (o) to read as follows:


Sec.  170.523  Principles of proper conduct for ONC-ACBs.

* * * * *
    (h) Only certify health IT (Complete EHRs and/or Health IT Modules) 
that has been tested, using test tools and test procedures approved by 
the National Coordinator, by a/an:
    (1) ONC-ATL;
    (2) NVLAP-accredited testing laboratory under the ONC Health IT 
Certification Program for no longer than six months from 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.
0
9. Add Sec.  170.524 to read as follows:


Sec.  170.524  Principles of proper conduct for ONC-ATLs.

    An ONC-ATL shall:
    (a) Maintain its NVLAP accreditation 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.
0
10. Revise Sec.  170.525 to read as follows:


Sec.  170.525  Application submission.

    (a) An applicant for ONC-ACB or ONC-ATL status must submit its 
application either electronically via email (or Web site submission if 
available), or by regular or express mail.
    (b) An application for ONC-ACB or ONC-ATL status may be submitted 
to the National Coordinator at any time.
0
11. Amend Sec.  170.530 by revising paragraphs (c)(2), (4), (d)(2) and 
(3) to read as follows:


Sec.  170.530  Review of application.

* * * * *
    (c) * * *
    (2) In order for an applicant to continue to be considered for ONC-
ACB or ONC-ATL status, the applicant's revised application must address 
the specified deficiencies and be received by the National Coordinator 
within 15 days of the applicant's receipt of the deficiency notice, 
unless the National Coordinator grants an applicant's request for an 
extension of the 15-day period based on a finding of good cause. If a 
good cause extension is granted, then the revised application must be 
received by the end of the extension period.
* * * * *
    (4) If the National Coordinator determines that a revised 
application still contains deficiencies, the applicant will be issued a 
denial notice indicating that the applicant cannot reapply for ONC-ACB 
or ONC-ATL status for a period of six months from the date of the 
denial notice. An applicant may request reconsideration of this 
decision in accordance with Sec.  170.535.
    (d) * * *
    (2) The National Coordinator will notify the applicant's authorized 
representative of its satisfactory application and its successful 
achievement of ONC-ACB or ONC-ATL status.
    (3) Once notified by the National Coordinator of its successful 
achievement of ONC-ACB or ONC-ATL status, the applicant may represent 
itself as an ONC-ACB or ONC-ATL (as applicable) and begin certifying or 
testing (as applicable) health information technology consistent with 
its authorization.
0
12. Amend Sec.  170.535 by revising the section heading and paragraphs 
(a) and (d)(1) to read as follows:


Sec.  170.535  ONC-ACB and ONC-ATL application reconsideration.

    (a) Basis for reconsideration request. An applicant may request 
that the National Coordinator reconsider a denial notice only if the 
applicant can demonstrate that clear, factual errors were made in the 
review of its application and that the errors' correction could lead to 
the applicant obtaining ONC-ACB or ONC-ATL status.
* * * * *

[[Page 11081]]

    (d) * * *
    (1) If the National Coordinator determines that clear, factual 
errors were made during the review of the application and that 
correction of the errors would remove all identified deficiencies, the 
applicant's authorized representative will be notified of the National 
Coordinator's determination and the applicant's successful achievement 
of ONC-ACB or ONC-ATL status.
* * * * *
0
13. Revise Sec.  170.540 to read as follows:


Sec.  170.540  ONC-ACB and ONC-ATL status.

    (a) Acknowledgement and publication. The National Coordinator will 
acknowledge and make publicly available the names of ONC-ACBs and ONC-
ATLs, including the date each was authorized and the type(s) of 
certification or scope of testing, respectively, each has been 
authorized to perform.
    (b) Representation. Each ONC-ACB or ONC-ATL must prominently and 
unambiguously identify the scope of its authorization on its Web site 
and in all marketing and communications statements (written and oral) 
pertaining to its activities under the ONC Health IT Certification 
Program.
    (c) Renewal. An ONC-ACB or ONC-ATL is required to renew its status 
every three years. An ONC-ACB or ONC-ATL is required to submit a 
renewal request, containing any updates to the information requested in 
Sec.  170.520, to the National Coordinator 60 days prior to the 
expiration of its status.
    (d) Expiration. An ONC-ACB's or ONC-ATL's status will expire three 
years from the date it was granted by the National Coordinator unless 
it is renewed in accordance with paragraph (c) of this section.
0
14. Amend Sec.  170.556 by revising paragraph (e)(1) to read as 
follows:


Sec.  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 Sec.  
170.523(i)(2).
* * * * *
0
15. Revise Sec.  170.557 to read as follows:


Sec.  170.557  Authorized testing and certification methods.

    (a) ONC-ATL applicability. An ONC-ATL must provide remote testing 
for both development and deployment sites.
    (b) ONC-ACB applicability. An ONC-ACB must provide remote 
certification for both development and deployment sites.
0
16. Revise Sec.  170.560 to read as follows:


Sec.  170.560  Good standing as an ONC-ACB or ONC-ATL.

    (a) ONC-ACB good standing. An ONC-ACB must maintain good standing 
by:
    (1) Adhering to the Principles of Proper Conduct for ONC-ACBs;
    (2) Refraining from engaging in other types of inappropriate 
behavior, including an ONC-ACB misrepresenting the scope of its 
authorization, as well as an ONC-ACB certifying Complete EHRs and/or 
Health IT Module(s) for which it does not have authorization; and
    (3) Following all other applicable federal and state laws.
    (b) ONC-ATL good standing. An ONC-ATL must maintain good standing 
by:
    (1) Adhering to the Principles of Proper Conduct for ONC-ATLs;
    (2) Refraining from engaging in other types of inappropriate 
behavior, including an ONC-ATL misrepresenting the scope of its 
authorization, as well as an ONC-ATL testing health IT for which it 
does not have authorization; and
    (3) Following all other applicable federal and state laws.
0
17. Revise Sec.  170.565 to read as follows:


Sec.  170.565  Revocation of ONC-ACB or ONC-ATL status.

    (a) Type-1 violations. The National Coordinator may revoke an ONC-
ATL or ONC-ACB's status for committing a Type-1 violation. Type-1 
violations include violations of law or ONC Health IT Certification 
Program policies that threaten or significantly undermine the integrity 
of the ONC Health IT Certification Program. These violations include, 
but are not limited to: False, fraudulent, or abusive activities that 
affect the ONC Health IT Certification Program, a program administered 
by HHS or any program administered by the federal government.
    (b) Type-2 violations. The National Coordinator may revoke an ONC-
ATL or ONC-ACB's status for failing to timely or adequately correct a 
Type-2 violation. Type-2 violations constitute noncompliance with Sec.  
170.560.
    (1) Noncompliance notification. If the National Coordinator obtains 
reliable evidence that an ONC-ATL or ONC-ACB may no longer be in 
compliance with Sec.  170.560, the National Coordinator will issue a 
noncompliance notification with reasons for the notification to the 
ONC-ATL or ONC-ACB requesting that the ONC-ATL or ONC-ACB respond to 
the alleged violation and correct the violation, if applicable.
    (2) Opportunity to become compliant. After receipt of a 
noncompliance notification, an ONC-ATL or ONC-ACB is permitted up to 30 
days to submit a written response and accompanying documentation that 
demonstrates that no violation occurred or that the alleged violation 
has been corrected.
    (i) If the ONC-ATL or ONC-ACB submits a response, the National 
Coordinator is permitted up to 30 days from the time the response is 
received to evaluate the response and reach a decision. The National 
Coordinator may, if necessary, request additional information from the 
ONC-ATL or ONC-ACB during this time period.
    (ii) If the National Coordinator determines that no violation 
occurred or that the violation has been sufficiently corrected, the 
National Coordinator will issue a memo to the ONC-ATL or ONC-ACB 
confirming this determination.
    (iii) If the National Coordinator determines that the ONC-ATL or 
ONC-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.

[[Page 11082]]

    (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.
0
18. Add Sec.  170.580 to read as follows:


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

[[Page 11083]]

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

[[Page 11084]]

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

[[Page 11085]]

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.
0
19. Add Sec.  170.581 to read as follows:


Sec.  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.
[FR Doc. 2016-04531 Filed 3-1-16; 8:45 am]
BILLING CODE 4150-45-P


Current View
CategoryRegulatory Information
CollectionFederal Register
sudoc ClassAE 2.7:
GS 4.107:
AE 2.106:
PublisherOffice of the Federal Register, National Archives and Records Administration
SectionProposed Rules
ActionNotice of proposed rulemaking.
DatesTo be assured consideration, written or electronic comments must
ContactMichael Lipinski, Office of Policy, Office of the National Coordinator for Health Information Technology, 202-690-7151.
FR Citation81 FR 11056 
RIN Number0955-AA00
CFR AssociatedComputer Technology; Electronic Health Record; Electronic Information System; Electronic Transactions; Health; Health Care; Health Information Technology; Health Insurance; Health Records; Hospitals; Incorporation by Reference; Laboratories; Medicaid; Medicare; Privacy; Reporting and Recordkeeping Requirements; Public Health and Security

2024 Federal Register | Disclaimer | Privacy Policy
USC | CFR | eCFR