[Federal Register Volume 81, Number 202 (Wednesday, October 19, 2016)]
[Rules and Regulations]
[Pages 72404-72471]
From the Federal Register Online via the Government Publishing Office [www.gpo.gov]
[FR Doc No: 2016-24908]



[[Page 72403]]

Vol. 81

Wednesday,

No. 202

October 19, 2016

Part III





Department of Health and Human Services





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





45 CFR Part 170





ONC Health IT Certification Program: Enhanced Oversight and 
Accountability; Final Rule

  Federal Register / Vol. 81 , No. 202 / Wednesday, October 19, 2016 / 
Rules and Regulations  

[[Page 72404]]


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

DEPARTMENT OF HEALTH AND HUMAN SERVICES

Office of the Secretary

45 CFR Part 170

RIN 0955-AA00


ONC Health IT Certification Program: Enhanced Oversight and 
Accountability

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

ACTION: Final rule.

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

SUMMARY: This final rule finalizes modifications and new requirements 
under the ONC Health IT Certification Program (``Program''), including 
provisions related to the Office of the National Coordinator for Health 
Information Technology (ONC)'s role in the Program. The final rule 
creates a regulatory framework for ONC's direct review of health 
information technology (health IT) certified under the Program, 
including, when necessary, requiring the correction of non-conformities 
found in health IT certified under the Program and suspending and 
terminating certifications issued to Complete EHRs and Health IT 
Modules. The final rule also sets forth processes for ONC to authorize 
and oversee accredited testing laboratories under the Program. In 
addition, it includes provisions for expanded public availability of 
certified health IT surveillance results.

DATES: These regulations are effective December 19, 2016.
    The incorporation by reference of the publication listed in the 
rule is approved by the Director of the Federal Register as of December 
19, 2016.

FOR FURTHER INFORMATION CONTACT: Michael Lipinski, Office of Policy, 
Office of the National Coordinator for Health Information Technology, 
202-690-7151.

SUPPLEMENTARY INFORMATION: 

Commonly Used Acronyms

CAP Corrective Action Plan
CEHRT Certified Electronic Health Record Technology
CFR Code of Federal Regulations
CHPL Certified Health IT Product List
EHR Electronic Health Record
HHS Department of Health and Human Services
HIT Health Information Technology
ISO/IEC International Organization for Standardization/International 
Electrotechnical Commission
NVLAP National Voluntary Laboratory Accreditation Program
OMB Office of Management and Budget
ONC Office of the National Coordinator for Health Information 
Technology
ONC-ACB ONC-Authorized Certification Body
ONC-ATCB ONC-Authorized Testing and Certification Body
ONC-ATL ONC-Authorized Testing Laboratory
PoPC Principles of Proper Conduct

Table of Contents

I. Executive Summary
    A. Purpose of Regulatory Action
    B. Summary of Major Provisions
    1. ONC Direct Review of Certified Health IT
    2. ONC-Authorized Testing Laboratories
    3. Transparency and Availability of Identifiable Surveillance 
Results
    C. Costs and Benefits
    1. Costs
    2. Benefits
II. Provisions of the Final Rule
    A. ONC's Role Under the ONC Health IT Certification Program
    1. Review of Certified Health IT
    a. Authority and Scope
    (1) Requirements of the Program
    (2) Review of Uncertified Capabilities
    (3) Scope of Review
    b. ONC-ACB's Role
    c. Review Processes
    (1) Notice of Potential Non-Conformity or Non-Conformity
    (2) Corrective Action
    (3) Suspension
    (4) Termination
    (5) Appeal
    d. Consequences of Certification Termination
    (1) Certification Ban, Recertification, and Heightened Scrutiny
    (2) ONC-ACB Response to a Non-Conformity
    2. Establishing ONC Authorization for Testing Labs Under the 
Program; Requirements for ONC-ATL Conduct; ONC Oversight and 
Processes for ONC-ATLs
    a. General Comments on the ONC-ATL Approach
    b. Regulatory Provisions for Inclusion of ONC-ATLs in the 
Program
    (1) Sec.  170.501 Applicability
    (2) Sec.  170.502 Definitions
    (3) Sec.  170.505 Correspondence
    (4) Sec.  170.510 Type of Certification
    (5) Sec.  170.511 Authorization Scope for ONC-ATL Status
    (6) Sec.  170.520 Application
    (7) Sec.  170.523 Principles of Proper Conduct for ONC-ACBs
    (8) Sec.  170.524 Principles of Proper Conduct for ONC-ATLs
    (9) Sec.  170.525 Application Submission
    (10) Sec.  170.530 Review of Application
    (11) Sec.  170.535 ONC-ACB Application Reconsideration
    (12) Sec.  170.540 ONC-ACB Status
    (13) Sec.  170.557 Authorized Certification Methods
    (14) Sec.  170.560 Good Standing as an ONC-ACB
    (15) Sec.  170.565 Revocation of ONC-ACB Status
    (16) Sec.  170.570 Effect of Revocation on the Certifications 
Issued To Complete EHRs and Health IT Module(s)
    B. Public Availability of Identifiable Surveillance Results
III. National Technology Transfer and Advancement Act and the Office 
of Management and Budget Circular A-119
IV. Incorporation by Reference
V. Collection of Information Requirements
    A. ONC-AA and ONC-ACBs
    B. ONC-ATLs
    C. Health IT Developers
VI. Regulatory Impact Statement
    A. Statement of Need
    B. Alternatives Considered
    C. Overall Impact
    1. Executive Orders 12866 and 13563--Regulatory Planning and 
Review Analysis
    a. Costs
    (1) Costs for Health IT Developers To Correct a Non-Conformity 
Identified by ONC
    (2) Costs for ONC and Health IT Developers Related to an ONC 
Inquiry Into Certified Health IT Non-Conformities and ONC Direct 
Review
    (3) Costs for Health IT Developers and ONC Associated With the 
Appeal Process Following a Suspension/Termination of a Complete 
EHR's or Health IT Module's Certification
    (4) Costs for Health Care Providers to Transition to Another 
Certified Health IT Product When the Certification of a Complete EHR 
or Health IT Module That They Currently Use Is Terminated
    (5) Costs for ONC-ATLs and ONC Associated With ONC-ATL 
Accreditation, Application, Renewal, and Reporting Requirements
    (6) Costs for ONC-ATLs and ONC Related to Revoking ONC-ATL 
Status
    (7) Costs for ONC-ACBs To Submit Identifiable Surveillance 
Results to the CHPL
    (8) Total Annual Cost Estimate
    b. Benefits
    c. Accounting Statement and Table
    2. Regulatory Flexibility Act
    3. Executive Order 13132--Federalism
    4. Unfunded Mandates Reform Act of 1995
Regulation Text

I. Executive Summary

A. Purpose of Regulatory Action

    The ONC Health IT Certification Program (``Program'') was first 
established as the Temporary Certification Program in a final rule 
published on June 24, 2010 (``Temporary Certification Program final 
rule'' (75 FR 36158)). It was later transitioned to the Permanent 
Certification Program in a final rule published on January 7, 2011 
(``Permanent Certification Program final rule'' (76 FR 1262)). Since 
that time, we have updated the Program and made modifications to the 
Program through subsequent rules as discussed below.
    In November 2011, a final rule established a process for ONC to 
address

[[Page 72405]]

instances where the ONC-Approved Accreditor (ONC-AA) has engaged in 
improper conduct or has failed to perform its responsibilities under 
the Program (76 FR 72636). In September 2012, a final rule (``2014 
Edition final rule'' (77 FR 54163)) established an edition of 
certification criteria and modified the Program to, among other things, 
provide clear implementation direction to ONC-Authorized Certification 
Bodies (ONC-ACBs) for certifying Health IT Modules to new certification 
criteria. On September 11, 2014, a final rule provided certification 
flexibility through the adoption of new certification criteria and 
further improvements to the Program (``2014 Edition Release 2 final 
rule'' (79 FR 54430)). On October 16, 2015, the Department of Health 
and Human Services (HHS) published a final rule that identified how 
health IT certification can support the establishment of an 
interoperable nationwide health information infrastructure through the 
certification and adoption of new and updated vocabulary and content 
standards for the structured recording and exchange of health 
information (``2015 Edition final rule'' (80 FR 62602)). The 2015 
Edition final rule modified the Program to make it open and accessible 
to more types of health IT, and health IT that supports various care 
and practice settings. It also included enhanced surveillance, 
disclosure, and other requirements. These requirements were designed to 
support the reliability of health IT certified under the Program and 
increase the transparency of information about such health IT (referred 
to as ``certified health IT'' throughout this final rule).
    With each Program modification and rule, we continue to address 
stakeholder concerns, provide additional guidance, and improve 
oversight. In keeping with this approach, in the ``ONC Health IT 
Certification Program: Enhanced Oversight and Accountability'' proposed 
rule (81 FR 11056) (``Proposed Rule'') we put forth several new 
proposals for comment, based on feedback from stakeholders and our own 
experience administering the Program. Importantly, we explained that 
the adoption and use of certified health IT has increased significantly 
since the Program was established, and that this trend will continue, 
including for settings and use cases beyond the Medicare and Medicaid 
EHR Incentive Programs (``EHR Incentive Programs''). As certified 
health IT becomes more integral to the delivery of care, and as 
certified capabilities increasingly interact with other capabilities in 
certified health IT and with other products, we seek to strengthen 
oversight of the performance of certified health IT capabilities and 
ensure that concerns within the scope of the Program continue to be 
appropriately addressed.
    We explained in the Proposed Rule that we had delegated authority 
to ONC-ACBs to issue certifications for health IT on our behalf through 
the Permanent Certification Program final rule (81 FR 11057). In 
addition to issuing and administering certifications, ONC-ACBs are 
responsible for conducting ongoing surveillance to assess whether 
certified health IT continues to conform to the requirements of the 
Program. An ONC-ACB's surveillance encompasses conformity assessments 
based on adopted certification criteria as well as certain other 
regulatory requirements (e.g., Sec. Sec.  170.523(k) and (l)). However, 
under this approach, which is consistent with customary certification 
programs and International Organization for Standardization/
International Electrotechnical Commission 17065:2012 (ISO/IEC 
17065),\1\ ONC-ACBs do not have the responsibility to address the full 
range of requirements applicable to health IT certified under the 
Program. For example, an ONC-ACB's conformity assessment may not 
encompass certain interactions among certified capabilities and other 
capabilities or products that are not certified under the Program. 
Similarly, an ONC-ACB's assessment of certified capabilities may be 
limited to certain functional outcomes and may not encompass the 
combined or overall performance of certified health IT in accordance 
with Program requirements. Separately, in some instances an ONC-ACB may 
be responsible for administering Program requirements but may be unable 
to do so effectively due to practical challenges. In contrast, ONC is 
well-positioned to review certified health IT against the full range of 
requirements under the Program. Therefore, to enhance Program oversight 
and the reliability and safety of certified health IT, we have 
finalized provisions of the Proposed Rule that set forth a regulatory 
framework for ONC to directly review certified health IT and take 
appropriate responsive actions to address potential non-conformities 
and non-conformities.
---------------------------------------------------------------------------

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

    The direct review processes included in this final rule will 
enhance the National Coordinator's ability to discharge his or her 
responsibilities under the Health Information Technology for Economic 
and Clinical Health (HITECH) Act. The HITECH Act amended the Public 
Health Service Act (PHSA) and created ``Title XXX--Health Information 
Technology and Quality'' (Title XXX) to improve health care quality, 
safety, and efficiency through the promotion of health IT and 
electronic health information exchange. Section 3001(b) of the PHSA 
requires that the National Coordinator for Health Information 
Technology (National Coordinator) perform specified statutory duties, 
including keeping or recognizing a program or programs for the 
voluntary certification of health information technology (section 
3001(c)(5) of the PHSA), in a manner consistent with the development of 
a nationwide health information technology infrastructure that allows 
for the electronic use and exchange of information and that: (1) 
Ensures that each patient's health information is secure and protected, 
in accordance with applicable law; (2) improves health care quality, 
reduces medical errors, reduces health disparities, and advances the 
delivery of patient-centered medical care; (3) reduces health care 
costs resulting from inefficiency, medical errors, inappropriate care, 
duplicative care, and incomplete information; (4) provides appropriate 
information to help guide medical decisions at the time and place of 
care; (5) ensures the inclusion of meaningful public input in such 
development of such infrastructure; (6) improves the coordination of 
care and information among hospitals, laboratories, physician offices, 
and other entities through an effective infrastructure for the secure 
and authorized exchange of health care information; (7) improves public 
health activities and facilitates the early identification and rapid 
response to public health threats and emergencies, including bioterror 
events and infectious disease outbreaks; (8) facilitates health and 
clinical research and health care quality; (9) promotes early 
detection, prevention, and management of chronic diseases; (10) 
promotes a more effective marketplace, greater competition, greater 
systems analysis, increased consumer choice, and improved outcomes in 
health care services; and (11) improves efforts to reduce health 
disparities. Consistent with these statutory requirements, this final 
rule establishes a regulatory framework for ONC's direct review of 
health IT certified under the Program.
    This final rule also sets forth processes for ONC to timely and 
directly

[[Page 72406]]

address testing issues. These processes do not currently exist under 
the Program structure and would serve to align the testing structure 
with ONC's authorization and oversight of ONC-ACBs. In addition, this 
final rule would increase the transparency and availability of 
information about certified health IT through the publication of 
identifiable surveillance results. The publication of identifiable 
surveillance results will support further accountability of health IT 
developers to their customers and users of certified health IT.

B. Summary of Major Provisions

1. ONC Direct Review of Certified Health IT
    This final rule provides a regulatory framework for ONC to directly 
review certified health IT to determine whether it conforms to the 
requirements of the Program. Under this framework, ONC's review of 
certified health IT will be independent of, and may be in addition to, 
ONC-ACBs' surveillance and other functions under the Program. ONC's 
review will focus on capabilities and aspects of health IT that are 
certified under the Program (referred to throughout this final rule as 
``certified capabilities''), taking into consideration other relevant 
functionalities or products to the extent necessary to determine 
whether certified health IT is functioning in a manner consistent with 
Program requirements.
    While the PHSA provides authority for ONC to directly review 
certified health IT in a broad range of circumstances, at this time we 
have finalized a regulatory framework for the exercise of such review 
in a more limited set of circumstances. This scope of review reflects 
the need to focus ONC's resources in areas that, at this time, are most 
vital to ensuring the integrity and effectiveness of the Program. It 
also complements the existing oversight and enforcement 
responsibilities of other government departments, agencies, and offices 
(referred to throughout this final rule as ``agencies'' or ``agency,'' 
as the context requires) that encourage compliance with Program 
requirements and promote accountability for the reliability and 
performance of health IT.
    Specifically, this final rule establishes regulatory processes for 
ONC to exercise direct review of certified health IT, and take 
appropriate responsive actions, in two distinct sets of circumstances.
    First, ONC may elect to directly review certified health IT when it 
has reason to believe that the certified health IT may not conform to 
the requirements of the Program because the certified health IT is 
causing or contributing to serious risks to public health or safety. 
Addressing the full range of these suspected non-conformities is beyond 
the scope of an ONC-ACB's expertise and responsibilities under the 
Program. In contrast, ONC has the authority to address the full range 
of requirements under the Program and, as we explained in the Proposed 
Rule, can effectively respond to these issues, quickly bringing to bear 
needed expertise and resources and coordinating activities with federal 
counterparts and other relevant entities to ensure a coordinated review 
and response (81 FR 11061).
    Second, in addition to serious risks to public health or safety, 
ONC may elect to directly review certified health IT on the basis of 
other suspected non-conformities that, while within the scope of an 
ONC-ACB's responsibilities, present practical challenges that may 
prevent the ONC-ACB from effectively investigating the suspected non-
conformity or providing an appropriate response. In particular, ONC may 
directly review certified health IT if a suspected non-conformity 
presents issues that may require access to certain confidential or 
other information that is unavailable to an ONC-ACB; may require 
concurrent or overlapping reviews by multiple ONC-ACBs; or may exceed 
the scope of an ONC-ACB's resources or expertise. We believe that ONC's 
review of certified health IT in these situations will help ensure the 
continued effective oversight and administration of the Program.
    In response to comments received on the Proposed Rule, we have not 
at this time finalized regulatory processes by which ONC would directly 
review certified health IT solely on the basis of circumstances 
distinct from public health or safety concerns or in cases where 
practical challenges prevent an ONC-ACB from effectively investigating 
the suspected non-conformity or providing an appropriate response, as 
discussed above (compare 81 FR 11061). For example, at this time, the 
processes set forth in this rule do not establish that ONC will 
directly review certified health IT solely on the basis of a threat to 
the security or protection of patients' health information in violation 
of applicable law (see section 3001(b)(1) of the PHSA) or the risk of 
increasing health care costs resulting from, for example, inefficiency 
or incomplete information (see section 3001(b)(3) of the PHSA). We 
believe that other agencies are currently in the best position to 
provide effective oversight and enforcement with respect to such 
potential exigencies. We will continue to assess the need to exercise 
direct review in these additional circumstances, as necessary.
    As mentioned above, in this final rule, we seek to align ONC's 
direct review of certified health IT with oversight and enforcement 
responsibilities of other agencies. We therefore clarify that ONC may 
decline to exercise review of certified health IT for any reason, 
including if it believes that other agencies may be better situated to 
respond to a suspected non-conformity. Additionally, to the extent 
permitted by law, ONC may coordinate and share information with other 
agencies, including agencies with applicable oversight or enforcement 
responsibilities, and may engage other persons and entities, as 
appropriate, to effectively respond to suspected problems or issues 
with certified health IT. We note that to the extent ONC engages in any 
efforts to identify or address non-conformities, such efforts and any 
resulting remediation (or the absence of such efforts or remediation) 
are not intended to impact the materiality of any non-conformity in a 
matter addressed by another agency; and nothing in this final rule is 
intended to supplant, delay, or in any way limit oversight or 
enforcement by other agencies, including any investigation, decision, 
legal action, or proceeding.
    The final rule addresses actions ONC will take and procedures it 
will follow in the event that ONC's direct review of certified health 
IT substantiates a non-conformity. ONC will require corrective action 
for non-conformities and, when necessary, suspend, or terminate a 
certification issued to a Complete EHR or Health IT Module. Health IT 
developers will have the opportunity to appeal determinations by ONC to 
suspend or terminate certifications issued to health IT under the 
Program. Further, to protect the integrity of the Program and users of 
certified health IT, we have finalized a Certification Ban on the 
future certification of any of a health IT developer's health IT when 
the certification of one or more of the health IT developer's current 
Complete EHRs or Health IT Modules is: (1) Terminated by ONC; (2) 
withdrawn by an ONC-ACB because the health IT developer requested it to 
be withdrawn when the health IT developer's health IT was the subject 
of a potential non-conformity or non-conformity as determined by ONC; 
(3) withdrawn by an ONC-ACB because of a non-conformity with any of the 
certification criteria adopted by the Secretary at subpart C of this 
part; or (4) withdrawn by an ONC-ACB because the

[[Page 72407]]

health IT developer requested it to be withdrawn when the health IT 
developer's health IT was the subject of surveillance for a 
certification criterion or criteria adopted by the Secretary at subpart 
C of this part, including pending surveillance (e.g., the health IT 
developer received notice of pending randomized surveillance).
    We emphasize that ONC's role in reviewing certified health IT will 
support greater accountability for health IT developers under the 
Program and provide greater confidence that health IT conforms to 
Program requirements when it is implemented, maintained, and used. We 
further emphasize that our first and foremost goal is to work with 
health IT developers to remedy any identified non-conformities of 
certified health IT in a timely manner.
2. ONC-Authorized Testing Laboratories
    ONC will conduct direct oversight of testing labs under the Program 
in order to ensure that ONC oversight can be similarly applied at all 
stages of the Program. Unlike the processes already established for 
ONC-ACBs, we had not established a similar process for testing labs. 
Instead, we required in the Principles of Proper Conduct (PoPC) for 
ONC-ACBs that ONC-ACBs only accept test results from National Voluntary 
Laboratory Accreditation Program (NVLAP)-accredited testing labs. This 
requirement for ONC-ACBs has had the effect of requiring testing labs 
to be accredited by NVLAP to International Organization for 
Standardization/International Electrotechnical Commission 17025:2005 
(General requirements for the competence of testing and calibration 
laboratories) (ISO/IEC 17025). As a result, there has effectively been 
no direct ONC oversight of NVLAP-accredited testing labs like there is 
for ONC-ACBs.
    This final rule establishes means for ONC to have direct oversight 
of NVLAP-accredited testing labs by having them apply to become ONC-
Authorized Testing Labs (ONC-ATLs). Specifically, the final rule 
establishes processes for authorizing, retaining, suspending, and 
revoking ONC-Authorized Testing Lab (ONC-ATL) status under the Program. 
These processes are similar to current ONC-ACB processes. The finalized 
changes will enable ONC to oversee and address testing and 
certification performance issues throughout the entire continuum of the 
Program in a precise and direct manner.
3. Transparency and Availability of Identifiable Surveillance Results
    In furtherance of our efforts to increase the transparency and 
availability of information related to certified health IT, we have 
finalized an approach that will now require ONC-ACBs to make 
identifiable surveillance results publicly available on the Certified 
Health IT Product List (CHPL) on a quarterly basis. Posting 
identifiable surveillance results on the CHPL provides stakeholders 
with a more readily available means for accessing the results. The 
information required to be reported for identifiable surveillance 
results includes information specified in the Proposed Rule and the 
relevant information already required to be posted on the CHPL, when 
appropriate, as part of a corrective action plan (CAP).
    The publication of identifiable surveillance results will enhance 
transparency and the accountability of health IT developers to their 
customers. The public availability of identifiable surveillance results 
will provide customers and users with valuable information about the 
continued conformity of certified health IT. While we expect that the 
prospect of publicly available identifiable surveillance results will 
motivate some health IT developers to improve their maintenance 
efforts, we believe that most published results will reassure customers 
and users of certified health IT. This is because, based on ONC-ACB 
surveillance results to date, certified health IT and health IT 
developers are maintaining conformity with certification criteria and 
Program requirements. The publishing of identifiable surveillance 
results will also provide more complete information by illuminating 
good performance and continued conformity; rather than only sharing 
non-conforming results, and when applicable, CAPs.

C. Costs and Benefits

    Executive Orders 12866 and 13563 direct agencies to assess all 
costs and benefits of available regulatory alternatives and, if 
regulation is necessary, to select regulatory approaches that maximize 
net benefits (including potential economic, environmental, public 
health and safety effects, distributive impacts, and equity). A 
regulatory impact analysis (RIA) must be prepared for major rules with 
economically significant effects ($100 million or more in any one 
year). It has been determined that this final rule is an economically 
significant rule as the potential costs associated with this final rule 
could be greater than $100 million per year. Accordingly, we have 
prepared an RIA that to the best of our ability presents the costs and 
benefits of the final rule.
1. Costs
    We have identified and estimated the potential monetary costs of 
this final rule for health IT developers, ONC-ATLs, the federal 
government (i.e., ONC), and health care providers. We have categorized 
and addressed costs as follows: (1) Costs for health IT developers to 
correct non-conformities identified by ONC; (2) costs for ONC and 
health IT developers related to an ONC inquiry into certified health IT 
non-conformities and ONC direct review, including costs for the new 
``proposed termination'' step; (3) costs for health IT developers and 
ONC associated with the appeal process following a suspension/
termination of a Complete EHR's or Health IT Module's certification; 
(4) costs for health care providers to transition to another certified 
health IT product when the certification of a Complete EHR or Health IT 
Module that they currently use is terminated; (5) costs for ONC-ATLs 
and ONC associated with ONC-ATL accreditation, application, renewal, 
and reporting requirements; (6) costs for ONC-ATLs and ONC related to 
revoking ONC-ATL status; and (7) costs for ONC-ACBs to publicly report 
(submit) identifiable surveillance results to the CHPL. We also provide 
an overall annual monetary cost estimate for this final rule. We note 
that we have rounded all estimates to the nearest dollar and all 
estimates are expressed in 2016 dollars.
    This final rule may: (1) Lead health IT developers to reassess 
whether their certified health IT is in conformity with Program 
requirements; and (2) require health IT developers to correct non-
conformities found by ONC in their certified health IT. If ONC were to 
find a non-conformity with a certified capability under the direct 
review processes outlined in this final rule, then the costs to correct 
the non-conformity are a result of this final rule. However, due to the 
difficulty of projecting such instances given the underlying need to 
correct non-conformities, we have not been able to include these costs 
in our quantitative cost estimates, as discussed in greater detail in 
section VI.C.1.a.(1) of this final rule.
    We have estimated the costs for ONC and health IT developers 
related to an ONC inquiry into certified health IT non-conformities and 
ONC direct review. We estimate the cost for a health IT developer to 
cooperate with an ONC review and inquiry into certified health IT 
would, on average, range from $9,819 to $98,192. We estimate the cost 
for ONC to review and conduct an inquiry

[[Page 72408]]

into certified health IT would, on average, range from $2,455 to 
$147,288.
    We have estimated the costs for health IT developers and ONC 
associated with the appeal process following a suspension/termination 
of a Complete EHR's or Health IT Module's certification. We estimate 
the cost for a health IT developer to appeal a suspension or 
termination would, on average, range from $9,819 to $29,458. We 
estimate the cost for ONC to conduct an appeal would, on average, range 
from $24,548 to $98,192.
    We have estimated the costs for health care providers to transition 
to another certified health IT product if the certification of a 
Complete EHR or Health IT Module that they currently use is terminated. 
Specifically, we estimate the cost impact of certification termination 
on health care providers would range from $33,000 to $649,836,000 with 
a median cost of $792,000 and a mean cost of $6,270,000. We note, 
however, that it is very unlikely that the high end of our estimated 
costs would ever be realized. To date, there have been only a few 
terminations of certified health IT under the Program, which have only 
affected a small number of providers. Further, we have stated in this 
final rule our intent to work with health IT developers to correct non-
conformities ONC finds in a developer's certified health IT under the 
provisions in this final rule. We provide a more detailed discussion of 
past certification terminations and the potential impacts of 
certification termination on providers in section VI.C.1.a.(4) of this 
final rule.
    We have estimated the costs for ONC-ATLs and ONC associated with 
ONC-ATL accreditation, application, renewal, and reporting 
requirements. We estimate the annualized cost for ONC-ATL 
accreditation, application, and the first proposed three-year 
authorization period to be approximately $48,832. We estimate the 
annualized cost for an ONC-ATL to renew its accreditation, application, 
and authorization during the first three-year ONC-ATL authorization 
period to be approximately $73,053. In addition, we estimate the total 
annual cost for ONC-ATLs to meet the reporting requirements of proposed 
Sec.  170.524(d) to be approximately $3,276.
    We estimate ONC's annualized cost for administering the entire 
application process to be approximately $992. This cost will be the 
same for a new applicant or ONC-ATL renewal. We would also post the 
names of applicants granted ONC-ATL status on our Web site. We estimate 
the potential cost for posting and maintaining the information on our 
Web site to be approximately $446 annually. We estimate an annual cost 
to the federal government of $743 to record and maintain updates and 
changes reported by ONC-ATLs.
    We have estimated the costs for ONC-ATLs and ONC related to 
revoking ONC-ATL status. We estimate the costs for an ONC-ATL to comply 
with ONC requests per Sec.  170.565 would, on average, range from 
$2,455 to $19,638. We estimate the cost for ONC would, on average, 
range from $4,910 to $39,277.
    We have estimated the costs for ONC-ACBs to submit identifiable 
surveillance results to the CHPL on a quarterly basis. We estimate the 
annual cost for each ONC-ACB to report surveillance results to the CHPL 
to be $1,024 and the total cost for all three ONC-ACBs to be $3,072.
    We estimate the overall annual cost for this final rule, based on 
the cost estimates outlined above, will range from $171,011 to 
$650,352,050 with an average annual cost of $6,597,033. For a more 
detailed explanation of our methodology and estimated costs, please see 
section VI.C.1.a of this final rule.
2. Benefits
    While we do not have available means to quantify the benefits of 
this final rule, we believe there are many qualitative benefits. This 
final rule's provisions for ONC direct review of certified health IT 
promote health IT developers' accountability for the performance, 
reliability, and safety of certified health IT; and facilitate the use 
of safer and reliable health IT by health care providers and patients. 
Specifically, ONC's direct review of certified health IT will 
facilitate ONC's assessment of non-conformities and ability to require 
comprehensive corrective actions for health IT developers to address 
non-conformities determined by ONC, including notifying affected 
customers. As previously stated, our first and foremost goal is to work 
with health IT developers to remedy any non-conformities with certified 
health IT in a timely manner and across all customers. If ONC 
ultimately suspends and/or terminates a certification issued to a 
Complete EHR or Health IT Module under the processes established in 
this final rule, such action will serve to protect the integrity of the 
Program, patients, and users of health IT. In sum, ONC's direct review 
of certified health IT supports the National Coordinator in fulfilling 
his or her responsibilities under the HITECH Act, instills public 
confidence in the Program, and protects public health and safety.
    This final rule's provisions will also provide other benefits. 
ONC's authorization and oversight of testing labs (ONC-ATLs) will 
promote further public confidence in testing and certification by 
facilitating ONC's ability to timely and directly address testing 
issues for health IT. The public availability of identifiable 
surveillance results will enhance transparency and the accountability 
of health IT developers to their customers. It will provide customers 
and users of certified health IT with valuable information about the 
continued conformity of certified health IT. Further, the public 
availability of identifiable surveillance results will likely benefit 
health IT developers by providing a more complete context of 
surveillance in the certified health IT industry by illuminating good 
performance and the continued conformity of certified health IT with 
Program requirements. Overall, we believe this final rule will improve 
Program conformity as well as further public confidence in certified 
health IT.

II. Provisions of the Final Rule

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

    In initially developing the Program, ONC consulted with the 
National Institute of Standards and Technology (NIST) and created the 
Program structure based on industry best practice. This structure 
includes the use of two separate accreditation bodies: (1) An 
accreditor that evaluates the competency of a health IT testing 
laboratory to operate a testing program in accordance with 
international standards; and (2) an accreditor that evaluates the 
competency of a health IT certification body to operate a certification 
program in accordance with international standards (see the Permanent 
Certification Program final rule).
    This final rule updates the structure of the Program to provide 
enhanced Program oversight, accountability, and transparency. The rule 
establishes a regulatory framework that will help facilitate ONC's 
direct review of certified health IT in current priority areas, 
including by setting forth processes for such review and describing 
certain actions ONC may take to enforce Program requirements in 
appropriate circumstances. The rule also provides for direct ONC 
oversight of testing laboratories. These and other related provisions 
of the final rule are described in detail below.

[[Page 72409]]

1. Review of Certified Health IT
a. Authority and Scope
    We proposed to adopt a regulatory framework that would help 
facilitate ONC's direct review of certified health IT in certain 
circumstances and enhance oversight and accountability in the Program 
(81 FR 11058). This review would be independent of, and could be in 
addition to, an ONC-ACB's surveillance and other functions under the 
Program and would complement the role of ONC-ACBs.
    In the Proposed Rule, we explained that under the current structure 
of the Program, ONC-ACBs are responsible for issuing and administering 
certifications for health IT on behalf of ONC (81 FR 11057). In 
addition, ONC-ACBs are responsible for conducting ongoing surveillance 
to assess whether certified health IT continues to conform to the 
requirements of the Program. An ONC-ACB's surveillance encompasses 
conformity assessments based on adopted certification criteria as well 
as certain other regulatory requirements (e.g., Sec.  170.523(k) and 
(l)). However, under this approach, which is consistent with other 
certification programs and ISO/IEC 17065,\2\ ONC-ACBs do not have the 
responsibility to address the full range of requirements applicable to 
health IT certified under the Program. For example, an ONC-ACB's 
conformity assessments may not encompass certain interactions among 
certified capabilities and other capabilities or products that are not 
certified under the Program. Similarly, an ONC-ACB's assessment of 
certified capabilities may address certain functional outcomes and may 
not encompass the combined or overall performance of certified health 
IT in accordance with Program requirements. Separately, in some 
instances an ONC-ACB may be responsible for administering Program 
requirements but ONC may be better suited to do so due to practical 
challenges.\3\
---------------------------------------------------------------------------

    \2\ The international standard to which ONC-ACBs are accredited 
(see also 45 CFR 170.599(b)(3)).
    \3\ In certain circumstances, an ONC-ACB may encounter practical 
challenges that could prevent it from effectively investigating a 
suspected non-conformity or providing an appropriate response. This 
may occur where, for example, a suspected non-conformity presents 
issues that may require access to certain confidential or other 
information that is unavailable to an ONC-ACB; may require 
concurrent or overlapping reviews by multiple ONC-ACBs; or may 
exceed the scope of an ONC-ACB's resources or expertise. For a more 
detailed discussion of these circumstances, we refer readers to 
section II.A.1.a.(3) of this final rule and to the section II.B 
(``Summary of Major Provisions'').
---------------------------------------------------------------------------

    In the Proposed Rule, we outlined several situations in which, for 
these reasons, an ONC-ACB may be unable to provide oversight necessary 
to ensure that certified health IT meets Program requirements. We 
stated, for example, that ONC may be better situated to respond to 
certain types of non-conformities arising from interactions of 
certified and uncertified capabilities or from systemic, widespread, or 
complex issues that could quickly consume or exceed an ONC-ACB's 
resources or capacity (81 FR 11061). We also observed that in some 
instances ONC may have access to information about a putative non-
conformity that is confidential and cannot be shared with an ONC-ACB 
(81 FR 11061). We explained that in some cases non-conformities with 
certified health IT may arise that pose risks to public health or 
safety or present other exigencies that may warrant ONC's direct review 
and action (81 FR 11061). Additionally, we noted that a suspected non-
conformity may involve health IT or capabilities that have been 
certified by more than one ONC-ACB. In such a situation, we stated that 
ONC would be better suited to handle the review of the certified health 
IT as ONC-ACBs only have oversight of the health IT they certify, while 
ONC could ensure a more coordinated review and consistent 
determination. We explained that ONC is well-placed to effectively 
respond to these potential issues because of its broad authority to 
administer the full range of requirements under the Program, its 
ability to quickly marshal and deploy resources and specialized 
expertise, and its ability to provide a coordinated review and response 
that may involve other agencies. Therefore, to support ONC's oversight 
in these areas, we proposed to establish a framework and processes in 
rulemaking under which ONC may exercise its discretion to directly 
review certified health IT and take appropriate responsive action.
    In the Proposed Rule, we stated that ONC's review of certified 
health IT could be based on any applicable Program requirements and as 
such would not be limited to requirements that ONC-ACBs are responsible 
for enforcing. We proposed that, while ONC would have broad discretion, 
it would consider the following factors in determining whether to 
initiate direct review of certified health IT:
     The potential nature, severity, and extent of the 
suspected non-conformity or non-conformities, including the likelihood 
of systemic or widespread issues and impact.
     The potential risk to public health or safety or other 
exigent circumstances.
     The need for an immediate and coordinated governmental 
response.
     Whether investigating, evaluating, or addressing the 
suspected non-conformity would require access to confidential or other 
information that is unavailable to an ONC-ACB; would present issues 
outside the scope of an ONC-ACB's accreditation; would exceed the 
resources or capacity of an ONC-ACB; or would involve novel or complex 
interpretations or application of certification criteria or other 
requirements.
     The potential for inconsistent application of 
certification requirements in the absence of direct review.
(see 81 FR 11061). We anticipated that ONC's direct review of certified 
health IT would be relatively infrequent and would focus on situations 
that pose a risk to public health or safety as well as other situations 
that present unique challenges or issues that ONC-ACBs may be unable to 
effectively address without ONC's assistance or intervention (based on 
consideration of the factors listed above). We stressed that our first 
and foremost desire would be to work with developers to address any 
non-conformities identified as a result of ONC's review.
    Comments. We received mixed comments on our proposal to establish 
regulatory processes that would help facilitate ONC's direct review of 
certified health IT. Some commenters supported the proposal, 
emphasizing that direct review would address potential gaps in the 
Program, improve the safety and performance of health IT, and improve 
the effectiveness of the Program. Other commenters supported ONC's 
direct review of certified health IT, but within a narrower or more 
defined scope.
    A significant number of commenters were opposed to the proposal or 
voiced strong concerns. Many of these commenters were opposed to ONC's 
reviewing the interaction of certified capabilities and uncertified 
capabilities. Commenters also stated that our proposal would create 
uncertainty by providing ONC with discretion to review certified health 
IT in a broad range of circumstances, without clear and predictable 
rules for assessing conformity to Program requirements. Commenters 
expressed fear that this broad discretion could lead to inconsistent or 
arbitrary application of requirements, create uncertainty for 
developers and other stakeholders, and impede progress and innovation 
in health IT. Some commenters also contested the authority for ONC to 
directly review certified health IT in the manner proposed.
    Response. We thank commenters for their detailed feedback on this 
proposal.

[[Page 72410]]

We have finalized the proposal subject to the changes and 
clarifications summarized here for the convenience of the reader and 
described in more detail in our responses to the specific comments that 
follow.
    The policy and approach we have finalized respond to emerging 
challenges identified by stakeholders, through consultation with NIST, 
and as a result of our experience administering the Program. In the 
more than six years since the Program was established, certified health 
IT has become widely adopted and is now integral to the delivery of 
patient care. At the same time, in response to growing market and 
regulatory demands for the exchange and use of electronic health 
information, the capabilities of certified health IT have become more 
varied, more advanced, and more interdependent with other health IT 
products and capabilities. These developments are encouraging and 
signal progress towards a more connected health system that can help 
transform health and care; yet for that to occur, the public must trust 
and have confidence in the nation's health IT infrastructure.
    To effectively respond to these challenges, and for the National 
Coordinator to continue to meet his or her responsibilities under 
section 3001 of the PHSA, we are adopting a regulatory framework in 
this final rule to enhance the Program. As noted in the Proposed Rule, 
there are several areas in which ONC-ACBs may lack the responsibility, 
expertise, or resources to provide effective oversight of certified 
health IT. Importantly, certain kinds of non-conformities may be 
difficult to substantiate through technical conformity assessments of 
the kind ONC-ACBs are currently responsible for administering under the 
Program. In addition, practical challenges may arise for ONC-ACBs when 
non-conformities span multiple health IT products whose certifications 
are administered by more than one ONC-ACB; or where a failure of 
certified capabilities to perform in an acceptable manner occurs only 
in the context of the capabilities' interaction with other capabilities 
or products that are not certified under the Program. For example, some 
non-conformities may be so systemic, complex, or widespread that to 
isolate or effectively address them would quickly exceed an ONC-ACB's 
resources or expertise. In some cases, an ONC-ACB may be unaware of a 
non-conformity or may be unable to obtain the information necessary to 
effectively investigate and respond to a suspected non-conformity, such 
as when doing so would require access to certain confidential 
information that may be known to ONC but cannot be disclosed to the 
ONC-ACB.
    These reasons support the need for ONC to directly administer 
Program requirements in appropriate circumstances. Further, the need is 
all the more compelling when one considers that certified capabilities 
may be impaired by failures or deficiencies that are not only beyond 
the reach of ONC-ACBs, but could cause or contribute to serious risks 
to public health or safety or lead to other outcomes that could 
significantly undermine public confidence in the health IT 
infrastructure, the successful development of which is the overriding 
purpose of the Program itself and of the duties of the National 
Coordinator under section 3001(c) of the PHSA.
    For all of these reasons, we have finalized a regulatory framework 
that will facilitate ONC's direct review of certified health IT to 
determine whether it conforms to the requirements of the Program. In 
doing so, however, we have carefully considered and, where appropriate, 
accommodated concerns raised by commenters. In particular, while the 
PHSA provides authority for ONC to directly review certified health IT 
in a broad range of circumstances, the direct review processes 
finalized in this rule apply to a more limited set of circumstances in 
which ONC intends to focus its oversight at this time. This approach 
will concentrate ONC's resources in areas that at this time are most 
vital to ensuring the integrity and effectiveness of the Program. In 
addition, it will complement the existing oversight and enforcement 
responsibilities of other agencies, provide guidelines that will 
encourage compliance with Program requirements, and provide 
accountability for the performance and reliability of health IT. 
Specifically, this final rule establishes regulatory processes for ONC 
to exercise direct review of certified health IT, and take appropriate 
responsive actions, in two distinct sets of circumstances.
    First, ONC may elect to directly review certified health IT when it 
has reason to believe that the certified health IT may not conform to 
the requirements of the Program because the certified health IT is 
causing or contributing to conditions that pose a serious risk to 
public health or safety. Addressing the full range of these suspected 
non-conformities is beyond the scope of an ONC-ACB's expertise and 
responsibilities under the Program. In contrast, ONC has the authority 
to address the full range of requirements under the Program and, as we 
explained in the Proposed Rule, can effectively respond to these 
issues, quickly bringing to bear needed expertise and resources and 
coordinating activities with federal counterparts and other relevant 
entities to ensure a coordinated review and response (81 FR 11061).
    Second, in addition to serious risks to public health or safety, 
ONC may elect to directly review certified health IT on the basis of 
other suspected non-conformities that, while they are within the scope 
of an ONC-ACB's responsibilities, present practical challenges that may 
prevent the ONC-ACB from effectively investigating the suspected non-
conformity or providing an appropriate response. In particular, ONC may 
directly review certified health IT if a suspected non-conformity 
presents issues that may require access to certain confidential or 
other information that is unavailable to an ONC-ACB; may require 
concurrent or overlapping reviews by multiple ONC-ACBs; or may exceed 
the scope of an ONC-ACB's resources or expertise. We believe that ONC's 
review of certified health IT in these circumstances is integral to 
ensuring the effective oversight and administration of the Program.
    In response to comments received on the Proposed Rule, we have not 
at this time finalized a regulatory framework under which ONC would 
directly review certified health IT in circumstances other than those 
that raise public health or safety concerns, or those in which 
practical challenges prevent an ONC-ACB from effectively investigating 
a suspected non-conformity or providing an appropriate response, as 
discussed above (compare 81 FR 11061). For example, at this time, the 
regulatory framework set forth in this rule does not provide that ONC 
will directly review certified health IT solely on the basis of a 
threat to the security or protection of patients' health information in 
violation of applicable law (see section 3001(b)(1) of the PHSA) or the 
risk of increasing health care costs resulting from, for example, 
inefficiency or incomplete information (see section 3001(b)(3) of the 
PHSA). We believe that other agencies are currently in the best 
position to provide effective oversight and enforcement with respect to 
such potential exigencies. We will continue to assess the need to 
exercise direct review in these additional circumstances, as necessary.
    Finally, in response to commenters' requests for additional clarity 
on certain provisions of the Proposed Rule, this final rule explains 
three key principles ONC will apply when deciding whether to initiate 
direct review of certified health IT and in determining whether

[[Page 72411]]

certified health IT conforms to the requirements of the Program.
    First, ONC's direct review of certified health IT--and any 
subsequent determination of non-conformity by ONC--would be based on a 
reasonable belief that health IT may be or is in violation of Program 
requirements. Contrary to the assertions of some commenters, these 
requirements have been clearly and consistently communicated to 
developers and do not impose new obligations under the Program. Indeed, 
in the 2015 Edition final rule, we explained that to comply with 
applicable certification criteria, developers must not only demonstrate 
required capabilities in a controlled testing environment but must also 
make those capabilities available in ways that enable them to be 
implemented and used in production environments for their intended 
purposes (80 FR 62711). That includes making certified capabilities 
available in a manner that does not cause or contribute to serious 
risks to public health or safety or to other outcomes that are 
inconsistent with the National Coordinator's responsibilities under 
section 3001(b) of the PHSA.
    Second, while several commenters objected to our proposal to review 
uncertified capabilities, we believe that many of these commenters 
misunderstood the scope of what was proposed. We proposed and have 
finalized regulatory processes for ONC to review capabilities and 
aspects of health IT that are certified under the Program. Our 
consideration of uncertified capabilities would be ancillary to our 
review of certified capabilities and would be limited to the extent 
necessary to determine whether certified capabilities are functioning 
in a manner consistent with Program requirements.
    Last, as we have previously explained in the context of an ONC-
ACB's surveillance of certified health IT, a developer of certified 
health IT cannot be held responsible under the Program for putative 
non-conformities that are not reasonably within its ability to 
influence or control. This limiting principle applies with equal force 
to ONC's direct review of certified health IT under the Program.
    The foregoing principles are consistent with those that have 
previously been established under the Program and ensure that ONC's 
review of certified health IT is consistent, follows clear and 
predictable guidelines, and is limited to issues that are within the 
scope of the Program. These principles and other aspects of ONC's 
direct review under this final rule are explained in greater detail in 
the responses to specific comments below. We also have included 
numerous examples to assist readers in understanding these concepts and 
the manner in which ONC would apply them in various circumstances.
(1) Requirements of the Program
    Comments. Some commenters, primarily health IT developers, posited 
that ONC may lack the requisite authority to directly review or enforce 
Program requirements, or to do so in the manner proposed. Several of 
these commenters criticized our invocation of section 3001(b) of the 
PHSA, which expressly enumerates the core principles and requirements 
inherent to the purpose of ONC. Some commenters suggested that the 
provisions of section 3001(b) are general and aspirational and that 
Congress did not intend for them to have any operative effect. 
Alternatively, some commenters supposed that these provisions operate 
``in the aggregate'' or on the performance of ONC's functions on the 
whole but are not relevant to the National Coordinator's responsibility 
to oversee the Program or to perform other specific duties enumerated 
in section 3001(c). In support of this view, commenters asserted that 
other sections of the PHSA speak directly to the scope of the Program 
and the rules by which it should operate. In particular, section 
3001(c)(5)(A) directs the National Coordinator to keep or recognize a 
program or programs for the voluntary certification of health IT as 
being in compliance with applicable certification criteria; and 
sections 3002 through 3004 establish the HIT Policy Committee (HITPC) 
and HIT Standards Committee (HITSC) and a consultative process for 
developing, endorsing, and adopting standards, implementation 
specifications, and certification criteria for inclusion in the 
Program. According to some of these commenters, this statutory design 
precludes ONC from enforcing requirements under the Program unless 
those requirements are expressed in certification criteria adopted 
through the processes noted above.
    In contrast to these comments, several commenters recognized ONC's 
authority to directly review certified health IT in the manner 
proposed. Multiple commenters explicitly recognized ONC's broad 
authority to establish certification programs and to directly review 
certified health IT against a wide range of requirements. One commenter 
stated that our proposal was an appropriate exercise of this authority 
because it did not take a broad brush approach and limited oversight to 
areas where there is a potential risk to health or safety or a gap in 
oversight that could result in harm.
    Response. We agree that ONC's role under the Program must comport 
with the National Coordinator's statutory authority under the HITECH 
Act. As we stated in the Proposed Rule, direct review helps enable the 
National Coordinator to fulfill the statutory duties specified in 
section 3001(b) and (c)(5) of the PHSA as they relate to keeping a 
certification program for the voluntary certification of health IT that 
allows for the electronic use and exchange of information consistent 
with ONC's purposes. This includes ensuring that each patient's health 
information is secure and protected, in accordance with applicable law; 
improving health care quality; reducing medical errors; reducing health 
care costs resulting from inefficiency, medical errors, inappropriate 
care, duplicative care, and incomplete information; and promoting a 
more effective marketplace, greater competition, greater systems 
analysis, increased consumer choice, and improved outcomes in health 
care services (see section 3001(b) of the PHSA).
    We respectfully disagree with the interpretation advanced by some 
commenters that the National Coordinator is not bound to observe these 
statutory dictates in the administration and oversight of the Program. 
By its plain language, section 3001(b) is an express mandate to the 
National Coordinator to perform the duties delegated to him or her in a 
manner consistent with the core principles and requirements enumerated 
in that section.
    It is true that some of the core principles and requirements in 
section 3001(b) are more relevant to the performance of some of the 
National Coordinator's duties than others, and that not every one of 
them is relevant to the performance of all of the National 
Coordinator's duties at all times or in the same way. It is also true 
that many of the core principles are stated broadly and permit 
substantial latitude in determining how corresponding requirements are 
to be met. But neither of these observations indicates that section 
3001(b) was intended to be inoperative, as some commenters have 
suggested. To the contrary, section 3001(b) is a logical and expedient 
way to give effect to the purpose of ONC, by enumerating the core 
principles and requirements that in turn provide the basic parameters 
by which the National Coordinator must perform his or her duties and 
functions.

[[Page 72412]]

    Even were that premise open to question, there is another reason to 
doubt that Congress would have intended the National Coordinator to 
administer and oversee the Program in a manner divorced from section 
3001(b) of the PHSA. The purpose of ONC and the core principles and 
requirements expressed in section 3001(b), and the language and 
structure of the HITECH Act as a whole, leave no doubt that Congress 
intended a critical role for health IT and the use and exchange of 
electronic health information in improving health, transforming care, 
and enabling new frontiers in research and scientific discovery. To 
achieve these ends, Congress, through the HITECH Act, established the 
EHR Incentive Programs to encourage the meaningful use of EHR 
technology certified by ONC. As commenters point out, Congress also 
specified formal processes and an advisory committee apparatus to 
assist the National Coordinator in endorsing and adopting certification 
criteria for use in the Program. Having placed the Program and the 
certification of health IT at the center of this plan for developing 
and advancing the goals of a nationwide health IT infrastructure, 
Congress would have expected the National Coordinator to ensure that 
the Program furthers those goals and does not permit certified health 
IT to perform in ways that subvert them.
    Finally, we reject the assertion that ONC is precluded from 
enforcing requirements of the Program other than those expressed in 
certification criteria adopted under section 3004 of the PHSA. As we 
explained most recently in the 2015 Edition final rule, the established 
requirements of the Program are not limited to compliance with 
certification criteria (80 FR 62710). For example, developers must 
disclose known material information about limitations and additional 
types of costs associated with their certified health IT (Sec.  
170.523(k)(1)); comply with rules governing the use of the ONC 
Certification and Design Mark (Sec.  170.523(l)); submit user 
complaints to ONC-ACBs (Sec.  170.523(n)); make certified capabilities 
available in ways that enable them to be implemented and used in 
production environments for their intended purposes (80 FR 62710); 
cooperate with an ONC-ACB's surveillance of their certified health IT 
(80 FR 62716); and cooperate with and not seek to prevent or discourage 
an ONC-ACB from reporting the results of its surveillance activities 
(80 FR 62718). We have also explained that certification under the 
Program is conditioned on a health IT developer's compliance with 
certain Program requirements--independent of any particular 
certification criteria--that are necessary to the basic integrity and 
effectiveness of the Program (80 FR 62710, n.170). We discuss these 
requirements and their regulatory history immediately below in response 
to requests from commenters for additional clarification of the 
Program's requirements.
    The foregoing considerations and our experience implementing the 
statutory provisions at issue leave no question that the National 
Coordinator has a duty to ensure that the certification of health IT 
under the Program furthers and does not subvert the core principles and 
requirements directly applicable to the National Coordinator's duties 
as enumerated in section 3001(b) of the PHSA. At a minimum, that 
includes updating the Program as necessary to provide effective 
oversight over problems or deficiencies with certified health IT that 
could lead to risks to public health or safety or to other outcomes 
that are inconsistent with the National Coordinator's responsibilities. 
We believe that the regulatory approach to direct review set forth in 
this rule is integral to fulfilling that duty.
    Comments. Many commenters stated that there is a need for greater 
clarity and consistency concerning the requirements to which developers 
will be held under the Program. Several commenters asked us to define 
the requirements of the Program more explicitly, including by providing 
a clear definition of non-conformity. Commenters noted that unpublished 
or generalized Program requirements could be a source of confusion for 
developers or of capricious application by ONC. This could have 
unintended consequences such as discouraging investment and innovation 
in health IT because developers and investors may be reluctant to 
pursue innovative technologies if regulatory requirements are unclear.
    Response. We agree that it is important to clearly communicate the 
requirements of the Program so that developers can design and make 
their certified health IT available in a manner that consistently meets 
Program requirements and the expectations of purchasers and users of 
certified health IT. In response to the comments, we explain in greater 
detail the sources of those requirements and the principles that ONC 
and ONC-ACBs apply when assessing whether they have been met.
    In the 2015 Edition Final Rule, we explained that a non-conformity 
arises when certified health IT fails to conform to the requirements of 
its certification under the Program (80 FR 62710). Those requirements 
take various forms and may apply to aspects of the design and 
performance of the health IT, the ability of the health IT to support 
required capabilities and uses, and the responsibility of developers to 
make certified capabilities available in ways that enable them to be 
implemented and used in production environments for their intended 
purposes (80 FR 62710).
    The certification criteria adopted under section 3004 of the PHSA 
form the core of the Program. In the 2010 interim final rule entitled 
Health Information Technology: Initial Set of Standards, Implementation 
Specifications, and Certification Criteria for Electronic Health Record 
Technology (75 FR 2013) (``Interim Final Rule''), we defined 
certification criteria as criteria to establish that health IT meets 
applicable standards and implementation specifications adopted by the 
Secretary or that are used to test and certify that health IT includes 
required capabilities (75 FR 2021-22; see also Sec.  170.102). To meet 
these certification criteria, health IT must be able to perform 
required specifications and capabilities and, more generally, to do so 
in an accurate and reliable manner. For example, health IT certified to 
Sec.  170.315(a)(1) (Computerized provider order entry--medications) 
must ``[e]nable a user to record, change, and access medication 
orders.'' Satisfying this criterion also plainly requires that the 
health IT perform this function accurately and reliably. For example, 
when a user enters a medication order for a patient, the health IT must 
accurately record the medication ordered and associate it with the 
patient selected by the user. Similarly, when a user accesses a list of 
medication orders for a particular patient, the health IT must not 
display medication orders for a different patient.
    While certification criteria define the required capabilities of 
certified health IT, ensuring that health IT can perform certified 
capabilities is not the only requirement of the Program. In the 2015 
Edition final rule, we adopted Program requirements under which 
developers must disclose on an ongoing basis any known material 
information about limitations and additional types of costs associated 
with any certified capabilities of their health IT (80 FR 62720). We 
have also adopted other Program requirements such as those related to 
the use of the ONC Certification and Design Mark and the submission of 
complaints to ONC-ACBs (Sec.  170.523(l) and (n), respectively). 
Developers must also submit

[[Page 72413]]

information that is required to be included on the CHPL (80 FR 62725).
    Finally, in previous rulemakings we have highlighted that there are 
certain overarching requirements of the Program, in addition to those 
described above, that are necessary to ensuring its basic integrity and 
effectiveness (see, e.g., 80 FR 62710 n.170), thereby ensuring that the 
National Coordinator can meet his or her responsibilities under section 
3001(b) of the PHSA. These requirements are part of the bases on which 
other requirements of the Program are understood and assessed.
    A prime example is the duty of developers who participate in the 
Program to cooperate with the surveillance of their certified health 
IT. The Permanent Certification Program final rule incorporated 
requirements for ONC-ACBs to conduct surveillance to ensure that 
certified health IT continues to conform to the requirements of 
certification when it is implemented ``in the field'' (76 FR 1282). 
More recently, in the 2015 Edition final rule, we expanded these 
surveillance requirements and also stated our expectations for the 
performance of certified health IT in production environments. We 
explained that health IT developers have a responsibility to make their 
certified capabilities available to purchasers and users in a manner 
that allows them to be used for their intended purposes, including any 
uses reasonably within the scope of the health IT's certification (80 
FR 62710). We stated that health IT would no longer conform to the 
requirements of its certification if customers or users were restricted 
from successfully implementing and using the technology for any purpose 
contemplated by the certification criteria to which the technology was 
certified (80 FR 62711). As an illustration, we said that a developer's 
failure to supply training materials and instructions necessary to 
access and successfully use data export capabilities described by Sec.  
170.315(b)(6) would constitute a non-conformity (80 FR 62711). 
Similarly, technical or other limitations that substantially interfere 
with the ability to access or use certified capabilities (or any aspect 
or intended uses of such capabilities) would give rise to a non-
conformity (80 FR 62711). Further, even in the absence of any actual 
impairment, if a developer's actions would be likely to substantially 
impair the ability of one or more users (or prospective users) to 
implement or use certified capabilities for any purpose within the 
scope of applicable certification criteria, the technology would no 
longer conform to the requirements of its certification (80 FR 62711). 
Thus, we explained that the failure to disclose known material 
information about limitations or types of costs associated with 
certified health IT not only violates the express disclosure 
requirements at Sec.  170.523(k)(1), but also constitutes a non-
conformity to the certification criteria associated with the 
potentially affected capabilities (80 FR 62711).
    Consistent with these established principles under the Program, 
certified health IT must be designed and made available to users in 
ways that allow certified capabilities to be used in an accurate and 
reliable manner, including in a manner that does not cause or 
contribute to serious risks to public health or safety or to other 
outcomes that are inconsistent with the National Coordinator's 
responsibilities under section 3001(b) of the PHSA. This requirement 
applies to the use of certified capabilities individually and in 
combination with other certified and uncertified capabilities of health 
IT. Just as the failure to disclose known material limitations or types 
of costs may impair the use of certified capabilities, the failure to 
design and make certified capabilities available so that they perform 
in an accurate and reliable manner impairs the safe and effective use 
of certified capabilities and is a non-conformity under the Program.
    It is important to note that the foregoing examples and analysis 
assume that the putative non-conformity is a result of the actions of 
the developer or factors that are reasonably within the developer's 
ability to influence or control. As we have explained on prior 
occasions, a non-conformity does not arise when certified health IT 
fails to perform in an acceptable manner but where the failure is the 
result of factors that are far removed from the control or 
responsibility of the developer (80 FR 62710).
    These principles are further elaborated and applied in the 
responses to specific comments throughout the remainder of this section 
(II.A.1.a) of the final rule. We have also included numerous examples 
to assist readers in understanding these principles and how ONC would 
apply them in particular circumstances.
    Comments. Many commenters believed that ONC should review certified 
health IT against specific standards, implementation specifications, 
certification criteria, or other express requirements, preferably 
developed through formal rulemaking; otherwise, developers would have 
insufficient guidance to design and implement their products in a 
manner that complies with Program requirements, and any determinations 
made by ONC could be ad hoc and have the potential to be unfairly 
applied. For these reasons, several commenters urged us to initiate 
separate rulemaking to identify and adopt new certification criteria 
that would prescribe specific requirements that ONC would apply when 
reviewing certified health IT and determining whether it conforms to 
Program requirements.
    Response. These comments raise many of the same concerns expressed 
in comments on the 2015 Edition proposed rule regarding then-proposed 
requirements for ONC-ACBs to conduct in-the-field surveillance of 
certified health IT. As we explained in finalizing those requirements, 
we understand the desire for bright-line rules; yet experience suggests 
that the fast-paced nature of technological change in the health IT 
landscape makes it impracticable to anticipate and prescribe detailed 
rules for every conceivable situation in which health IT may not 
conform to Program requirements (see 80 FR 62709). In practice, 
certified health IT may be integrated with a wide range of other 
systems, processes, and workflows and may be customized and used in 
many different ways. These circumstances, which are inherent to the 
production environment, are too numerous and varied to anticipate or to 
reduce to simple rules of universal application.
    For the same reasons, we do not believe that adopting certification 
criteria would provide the clarity or certainty sought by advocates of 
that approach. We believe that clarity and predictability are best 
achieved by articulating and explaining the basic principles that 
govern our review of certified health IT, as we have done in our 
previous response above and in the examples and discussion of potential 
non-conformities throughout this section of the preamble. These 
principles are consistent with those that govern an ONC-ACB's 
surveillance of certified health IT in the field (80 FR 62709). As 
such, they will ensure that ONC's review of certified health IT is 
consistent and based on clear and predictable principles.
    Comments. Multiple commenters stated that a non-conformity should 
be defined as occurring only when certified health IT can no longer 
complete or repeat the certification test procedures against which it 
was previously tested and on the basis of which the health IT was 
certified.
    Response. We expressly rejected these arguments in the preamble to 
the 2015 Edition final rule (80 FR 62709). There, we explained that an 
ONC-ACB's

[[Page 72414]]

assessment of certified health IT in the field is not limited to 
aspects of the technology that were tested in a controlled environment. 
Rather, an ONC-ACB must consider the unique circumstances and context 
in which the certified health IT is implemented and used in order to 
properly assess whether it continues to perform in a manner that 
complies with its certification.
    Testing is an important part of an ONC-ACB's overall analysis of 
health IT under the Program. For practical reasons, however, testing 
focuses on particular use cases and necessarily reflects assumptions 
about how capabilities will be implemented and used in practice. Thus, 
while test results provide a preliminary indication that health IT 
meets the requirements of its certification and can support the 
capabilities required by the certification criteria to which the 
technology was certified, that determination is always subject to an 
ONC-ACB's ongoing surveillance, including the ONC-ACB's evaluation of 
certified capabilities in the field. Indeed, a fundamental purpose of 
in-the-field surveillance is to identify deficiencies that may be 
difficult to anticipate or that may not become apparent until after 
certified health IT is implemented and used in a production 
environment. That purpose would be entirely frustrated if an ONC-ACB's 
assessment of technology in the field were confined to those aspects of 
the technology's performance specifically delineated in test 
procedures.
    For these same reasons, we again reject the position that Program 
requirements should be rigidly defined by test procedures instead of 
more meaningful performance outcomes. In assessing putative non-
conformities in the course of ONC direct review, we consider the unique 
circumstances and context in which the certified health IT is 
implemented and used in order to properly assess whether it continues 
to perform in a manner that complies with the Program (see, 80 FR 
62709).
    Comments. Several commenters observed that the performance of 
health IT may be impacted by providers' implementation choices or other 
factors that the developer of the health IT may be unable to reasonably 
anticipate or control. One commenter explained that health IT 
developers do not necessarily control which third-party products their 
customers may deploy in conjunction with the developer's certified 
health IT and that it is not unusual for interface issues to arise 
because of updates to these unsupported products or uses. Commenters 
noted that developers may find it particularly difficult to anticipate 
and address interactions of their certified health IT with third-party 
products that are not certified under the Program or with capabilities 
or aspects of certified health IT that are not directly governed by 
certification criteria.
    Response. In the 2015 Edition final rule, we recognized there may 
be instances in which the failure of certified health IT to perform 
required capabilities in the field may be due to factors that are 
beyond the ability of the health IT's developer to reasonably influence 
or control (80 FR 62710). Because the requirements of the Program focus 
on the responsibilities of health IT developers and those aspects of 
their technology that they can reasonably influence or control, we 
explained that the failure of health IT to perform in an acceptable 
manner would not constitute a non-conformity if the failure was caused 
exclusively by factors far removed from the control or responsibility 
of the developer.\4\ We also explained that, in evaluating non-
conformities in the field, ONC-ACBs are required to determine the 
reasons for the failure of health IT to function in an acceptable 
manner, taking into account the roles of the technology as well as the 
health IT developer, users, and other parties. If an ONC-ACB finds that 
the developer or its technology were a substantial cause of the 
failure, the ONC-ACB would conclude that the health IT does not meet 
the requirements of its certification. By contrast, if the ONC-ACB 
finds that the failure was caused exclusively by factors far removed 
from the control or responsibility of the developer, the ONC-ACB would 
regard those factors as beyond the scope of the health IT's 
certification and would not find a non-conformity.
---------------------------------------------------------------------------

    \4\ For example, in the 2015 Edition final rule we provided a 
hypothetical scenario in which a health IT developer's certified 
health IT could not demonstrate required capabilities in the field 
due to factors that were far removed from the developer's control or 
responsibility (80 FR 62710). In the scenario, a customer had 
instructed the developer to configure the certified health IT to use 
clinical decision support content from a third-party vendor with 
whom the developer had no sublicensing agreement. The customer 
agreed that it would be responsible for maintaining the necessary 
licenses for access to the third-party vendor's content. Despite the 
developer's warning, the customer failed to maintain the necessary 
licenses and access to the content was suspended, which prevented 
the certified health IT from functioning as expected.
---------------------------------------------------------------------------

    These same principles apply equally to ONC's review of certified 
health IT. If in the course of reviewing certified health IT, ONC 
determines that the failure of the health IT to perform in an 
acceptable manner is the result of factors that, because they are far 
removed from the control or responsibility of the developer, were not 
within its ability to reasonably influence or control, ONC would not 
conclude that the certified health IT is non-conforming.
(2) Review of Uncertified Capabilities
    In the Proposed Rule, we proposed that ONC could review the 
interaction of certified capabilities of health IT with uncertified 
capabilities. As defined earlier in section II.A.1.a of this final 
rule, we use the term ``certified capabilities'' to refer to any 
capabilities or other aspects of health IT that are certified under the 
Program. In contrast, other aspects of health IT are referred to as 
``uncertified capabilities'' throughout this final rule. Uncertified 
capabilities may be integrated with certified capabilities within a 
single certified health IT product (i.e., a certified Complete EHR or 
certified Health IT Module) or may be part of other health IT products 
or services that are not certified under the Program.
    Comments. Several commenters supported our proposal to review 
certified health IT in a manner that recognizes that, in practice, 
certified capabilities frequently interact with uncertified 
capabilities, whether because a developer of certified health IT 
includes additional capabilities in its certified health IT product or 
because the developer's certified health IT product is deployed with or 
configured to work with other health IT products that are not certified 
under the Program. One commenter stated that a significant limitation 
of the Program to date has been the lack of an effective means to 
evaluate how certified capabilities of health IT are performing once 
they are deployed in the field and interact with other capabilities or 
products that are not certified under the Program.
    In contrast, some commenters, including one health IT developer, 
suggested that it would be appropriate for ONC to review uncertified 
capabilities, but only in certain limited circumstances. One commenter 
recommended that such review be limited to situations in which a 
developer integrates uncertified ``components'' with its certified 
health IT in a manner that directly causes a material adverse impact on 
the ability of the certified health IT to function in accordance with 
certification requirements.
    Other commenters categorically opposed this aspect of our proposal. 
Some of these commenters assumed, however, that ONC would review and 
make determinations about the performance of capabilities or products

[[Page 72415]]

that the commenters regarded as clearly beyond the scope of the 
Program. Some commenters even assumed that ONC would review health IT 
products that are not certified under the Program at all. According to 
these commenters, ONC's review of uncertified capabilities or other 
products would be inconsistent with the voluntary nature of the Program 
and would be a significant overstep of ONC's authority. One commenter, 
for example, stated that ONC had no authority to investigate 
uncertified ``components'' of certified health IT or to dictate how a 
developer builds and modifies a product in response to market mandates.
    Response. It appears that many commenters interpreted this aspect 
of our proposal in a manner that was more far-reaching than we had 
either contemplated or proposed. The confusion appears to have resulted 
from our summary of the major provisions of the Proposed Rule, which 
stated that ONC's direct review ``may include certified capabilities 
and non-certified capabilities of the certified health IT'' and ``would 
extend to the interaction of certified and uncertified capabilities 
within the certified health IT and to the interaction of a certified 
health IT's capabilities with other products'' (81 FR 11058).
    In explaining the purpose of the Proposed Rule, we stated that as 
certified capabilities of health IT interact with other capabilities in 
certified health IT and with other products, ONC's direct review would 
ensure that concerns within the scope of the Program can be 
appropriately addressed (81 FR 11057). As this statement suggests, the 
purpose of direct review is to evaluate and determine whether 
capabilities and other aspects of health IT that are certified under 
the Program conform to the Program's requirements. Nevertheless, 
because certified capabilities are frequently integrated or deployed 
with uncertified capabilities, evaluating whether a certified 
capability under review (the ``target capability'') conforms to the 
requirements of the Program may require understanding how the target 
capability is interacting with other capabilities of health IT. Those 
other capabilities may be certified under the Program or they may be 
uncertified capabilities. In the case of an uncertified capability, the 
capability may be part of the same ``product'' as the target capability 
or it may be part of a different product, which may or may not be 
certified under the Program. Whatever the case, to ensure that ONC can 
properly evaluate whether the target capability is functioning in an 
acceptable manner, we proposed that ONC may have to consider the 
interaction of the target capability with other capabilities that 
affect its performance, which could include uncertified capabilities, 
as discussed above. We did not propose, however, that uncertified 
capabilities would themselves become a target of ONC's review. In this 
sense, our statement that ONC's ``review'' would extend to the 
uncertified capabilities was somewhat inexact because ONC would be 
concerned with only the effects of the uncertified capabilities on the 
target capability, not with the performance of the uncertified 
capabilities in isolation. In other words, ONC's consideration of 
uncertified capabilities would be ancillary to its review of certified 
capabilities and limited to the extent necessary to determine whether 
those certified capabilities are functioning in a manner consistent 
with Program requirements.
    As an illustration, consider a Health IT Module designed for 
ambulatory settings and that is certified to, among other criteria, 
Sec.  170.314(b)(5) (Incorporate laboratory tests and values/results). 
Under the process established by this final rule, ONC could initiate 
direct review if, for example, it had reliable information that the 
Health IT Module were receiving and incorporating lab results 
incorrectly in a manner that was causing or contributing to missed 
diagnoses or improper management of serious medical conditions. ONC's 
review of the Health IT Module would be based on the Health IT Module's 
certified capabilities, which include the capability to incorporate lab 
results according to the standard specified in Sec.  170.205(j) and, at 
a minimum, the version of the standard specified in Sec.  
170.207(c)(2). However, it may be that the lab results are being 
corrupted before they are received by the certified capability. To 
determine whether that is the case, it may be necessary for ONC to 
examine the capabilities of upstream health IT systems from which the 
Health IT Module receives lab results. This may include examining 
certified capabilities or uncertified capabilities of the upstream 
systems to the extent that those capabilities could be causing or 
contributing to incorrect data being transmitted to the receiving 
Health IT Module.
    We reiterate that ONC does not intend to review the functioning of 
uncertified capabilities except to the extent that an uncertified 
capability interacts with and affects the performance of a certified 
capability that is under review. If ONC commenced review of certified 
health IT based on a reasonable belief that the certified health IT may 
not conform to the requirements of the Program, but subsequently 
determined that the problem or deficiency was related solely to the 
functioning of uncertified capabilities in isolation, ONC would cease 
its review of the certified health IT. We note that, as discussed 
subsequently in section II.A.1.a.(3) of this preamble, ONC may share 
any information obtained in connection with its review with other 
relevant agencies, to the extent permitted by law, including agencies 
with applicable federal oversight or enforcement authority.
    With these clarifications, we believe the concerns raised in 
connection with this aspect of our proposal are misplaced. Contrary to 
those concerns, this final rule does not establish a process for ONC to 
make determinations about uncertified capabilities, nor to dictate how 
developers design uncertified capabilities within certified health IT 
or other technologies. ONC's consideration of uncertified capabilities 
will be ancillary to ONC's review of certified capabilities and limited 
to aspects of uncertified capabilities that interact with certified 
capabilities and are relevant to evaluating the performance of those 
certified capabilities. Further, we reiterate our expectation that 
direct review will occur relatively infrequently and will focus on 
situations that pose a risk to public health or safety or where ONC-
ACBs may be unable to respond effectively.
    Comments. A number of commenters raised concerns that the 
application of direct review to uncertified capabilities would be 
contrary to ONC's policy of encouraging flexibility in the way that 
health IT systems are configured and used. Commenters also expressed 
concern that direct review of uncertified capabilities could create 
regulatory uncertainty and would diminish innovation. Noting that 
developers regard the uncertified aspects of their health IT as a key 
area of differentiation from their competitors, commenters expressed 
fear that direct review of uncertified capabilities would crowd out 
innovation in this important area and diminish overall incentives to 
innovate and improve health IT capabilities.
    Response. We are sensitive to the competition and innovation 
concerns raised by commenters. We believe that those concerns can be 
effectively addressed by clearly communicating the scope of ONC's 
direct review under this final rule and the limited extent to which it 
will impact developers of uncertified capabilities. We have

[[Page 72416]]

explained the potential scope of ONC's review under the processes 
established by this final rule, including the extent to which ONC would 
consider the impact of uncertified capabilities on the performance of 
certified capabilities. In addition, section II.A.1.a.(3) of this 
preamble describes the types of circumstances in which ONC may invoke 
the processes for direct review set forth in this final rule.
    To further communicate our intent and address the concerns raised 
by commenters, we reiterate that the purpose of direct review is to 
ensure that certified health IT functions in a manner that is 
consistent with the requirements of the Program. In the event that ONC 
determines that an uncertified capability is causing a certified 
capability to function in a manner inconsistent with Program 
requirements, ONC's determination would relate to the functioning of 
the certified capability at issue. Even in the event that an 
uncertified capability is identified as the cause of, or a contributing 
factor toward, certified health IT functioning in a manner inconsistent 
with Program requirements, direct review would not dictate whether or 
in what manner the uncertified capability should be modified. Any 
corrective action to be taken by the developer in response to a 
determination of non-conformity by ONC would relate to bringing the 
certified capability or capabilities into conformity. For example, 
appropriate corrective action might involve the developer taking steps 
to ensure that the certified capability does not interact with the 
uncertified capability that is causing it to function in an unsafe 
manner.
    Comments. A number of commenters expressed concern that extending 
ONC's review to uncertified capabilities or to uncertified products 
would conflict with or duplicate oversight of health IT by other 
federal agencies.
    Response. We acknowledge that the investigatory and enforcement 
authorities of other federal agencies might apply, in certain 
circumstances, to the performance and functioning of certified health 
IT. For several reasons, however, we disagree that ONC's review will 
conflict with or duplicate other oversight of health IT.
    First, as discussed above, while ONC's review may encompass 
uncertified capabilities, ONC would only be concerned with aspects of 
the uncertified capabilities that interact with the certified 
capabilities that are the subject of ONC's review, and only to the 
extent necessary to assess whether the certified capabilities are 
functioning in accordance with Program requirements. This limited and 
ancillary consideration of uncertified capabilities would be unlikely 
to create any significant conflict with or duplication of any other 
agency's authority. Moreover, to the extent that ONC's review does 
uncover issues that fall within the purview of other agencies with 
relevant oversight or enforcement responsibilities, ONC could 
coordinate with and share any information or evidence it has obtained 
with such agencies, to the extent permitted by federal law, and, if 
appropriate, could pause or end its review.
    Second, as discussed below in section II.A.1.a.(3) of this 
preamble, we have narrowed the scope of direct review under this final 
rule based in part on the ability of other agencies to provide 
appropriate oversight of certain types of non-conformities that would 
otherwise warrant ONC's review. For example, at this time, we have not 
finalized in this rule processes for ONC direct review of a suspected 
non-conformity solely on the basis that certified health IT may be 
compromising the security or protection of patients' health information 
(see section 3001(b)(1) of the PHSA) or increasing health care costs as 
a result of, for example, inefficiency or incomplete information (see 
section 3001(b)(3) of the PHSA). Our decision not to establish 
regulatory processes for such oversight at this time is based in part 
on the recognition that other agencies have the ability to investigate 
and respond to these types of issues and our desire to make the most 
efficient use of limited federal resources.
    Third, far from conflicting with or duplicating the efforts of 
other agencies, we expect direct review to promote greater alignment in 
the oversight of health IT. Direct review allows ONC to coordinate with 
and provide expertise to other agencies, and to share any information 
or evidence ONC has obtained, as permitted by federal law. For example, 
ONC could quickly marshal and deploy resources and specialized 
expertise while working with federal counterparts to ensure a 
coordinated review and response to potential non-conformities. This 
approach is consistent with our inter-agency efforts to avoid 
regulatory duplication and promote appropriate, risk-based oversight of 
health IT, including efforts described in the Draft Food and Drug 
Administration Safety and Innovation Act (FDASIA) Health IT Report,\5\ 
published jointly with the Food and Drug Administration (FDA) and the 
Federal Communications Commission (FCC). Indeed, the need for effective 
coordination could be especially important in responding to serious 
risks to public health or safety that arise from the complex 
interaction of health IT products that may include certified 
capabilities regulated by ONC as well as uncertified capabilities that 
may be subject to FDA, FCC, or another agency's oversight.
---------------------------------------------------------------------------

    \5\ Draft FDASIA Health IT Report: Proposed Strategy and 
Recommendations for a Risk-Based Framework (April 2014), available 
at https://www.healthit.gov/sites/default/files/fdasia_healthitreport_final.pdf.
---------------------------------------------------------------------------

    Finally, we note that ONC may elect to not initiate direct review 
(or, if it has initiated direct review, to cease such review) at any 
time and for any reason, including if ONC believes that another agency 
is better situated to investigate or address a suspected non-
conformity, or if ONC believes that direct review could duplicate or 
interfere with the oversight or enforcement activities of other 
agencies. ONC may also coordinate with and share any information or 
evidence it has obtained, through its direct review or otherwise, with 
other agencies, to the extent permitted by federal law. We also 
anticipate that ONC may coordinate with ONC-ACBs, ONC-ATLs, the ONC-AA, 
and other entities in appropriate circumstances and consistent with 
applicable federal law.
(3) Scope of Review
    We proposed that ONC may exercise direct review of certified health 
IT when there is reason to believe that the certified health IT may not 
conform to the requirements of the Program. We explained that ONC's 
review could be in response to concerns that certified health IT may be 
leading to medical errors or other outcomes that are inconsistent with 
the National Coordinator's responsibilities under section 3001 of the 
PHSA. We also stated there could also be other exigencies, distinct 
from public health or safety concerns, that for similar reasons would 
warrant ONC's direct review and action. In addition, we proposed that 
ONC may directly review certified health IT in situations that present 
unique challenges or issues that ONC-ACBs may be unable to effectively 
address without ONC's assistance or intervention. We listed a variety 
of factors in this regard that could help inform ONC's decision whether 
to initiate direct review in individual cases, specifically:
     The potential nature, severity, and extent of the 
suspected non-conformity or non-conformities, including the likelihood 
of systemic or widespread issues and impact.

[[Page 72417]]

     The potential risk to public health or safety or other 
exigent circumstances.
     The need for an immediate and coordinated governmental 
response.
     Whether investigating, evaluating, or addressing the 
suspected non-conformity would require access to confidential or other 
information that is unavailable to an ONC-ACB; would present issues 
outside the scope of an ONC-ACB's accreditation; would exceed the 
resources or capacity of an ONC-ACB; or would involve novel or complex 
interpretations or application of certification criteria or other 
requirements.
     The potential for inconsistent application of 
certification requirements in the absence of direct review.

(see 81 FR 11061). We anticipated that ONC's direct review of certified 
health IT would be relatively infrequent and would focus on situations 
that pose a risk to public health or safety as well as other situations 
that present unique challenges or issues that ONC-ACBs may be unable to 
effectively address without ONC's assistance or intervention (based on 
consideration of the factors listed above). We stressed that our first 
and foremost desire would be to work with developers to address any 
non-conformities identified as a result of ONC's review.
    Comments. A majority of commenters agreed that ONC should directly 
review certified health IT that could be leading to medical errors or 
other risks to public health or safety. One commenter representing 
health care professionals noted a strong need for ONC to adjust the 
Program to focus on the safety, usability, and interoperability of 
certified health IT, citing widespread concerns among the medical 
community about these issues. The commenter stated that ONC could play 
a valuable role in ensuring that the appropriate parties are 
identifying, analyzing, and correcting health IT safety concerns by 
quickly resolving non-conformity issues.
    Several commenters who otherwise opposed direct review, including 
health IT developers, stated that it may be reasonable for ONC to 
review non-conformities as a ``true last resort'' when risks to patient 
safety are sufficiently compelling or when there is a gap or overlap in 
the ability of ONC-ACBs to effectively address the risk.
    A small number of commenters categorically opposed this aspect of 
our proposal and stated that whether certified health IT is leading to 
medical errors or other risks to public health or safety is either 
beyond the scope of current certification criteria, other Program 
requirements, or section 3001(c)(5) of the PHSA. A few commenters, 
including one ONC-ACB, stated that health IT-related safety risks 
should not be addressed through the Program because there might be 
other channels, such as the proposed Health IT Safety Collaborative,\6\ 
through which these issues could be more effectively dealt with, 
including by identifying health IT safety-related issues, defining 
appropriate best practices and criteria, and making objective 
assessments. Commenters also urged ONC to continue to support existing 
private-public initiatives that are developing a framework for the 
identification of health IT safety incidents to expand knowledge for 
all stakeholders.
---------------------------------------------------------------------------

    \6\ See Department of Health and Human Services, Justification 
of Estimates for Appropriations Committee (Office of the National 
Coordinator for Health Information Technology), app. IV, https://www.healthit.gov/sites/default/files/final_onc_cj_fy_2017_clean.pdf 
(2016) (proposing that Congress provide ONC with authority to 
establish a Health IT Safety Collaborative and provide adequate 
confidentiality protections). See also ONC, Health IT Safety Center 
Roadmap, http://www.healthitsafety.org/uploads/4/3/6/4/43647387/roadmap.pdf (2015) (containing task force recommendations for the 
development of a national Health IT Safety Center); Food and Drug 
Administration, Draft FDASIA Health IT Report, https://www.healthit.gov/sites/default/files/fdasia_healthitreport_final.pdf 
(2014) (recommending establishment of a Health IT Safety Center as a 
key component of a risk-based approach to health IT safety oversight 
and efforts to create a sustainable, integrated health IT learning 
system that avoids regulatory duplication and leverages and 
complements existing public and private sector activities to improve 
the safety and safe use of health IT).
---------------------------------------------------------------------------

    Response. We thank commenters for their feedback and suggestions on 
this aspect of our proposal. Based on the comments, and consistent with 
the focus of the Proposed Rule, we continue to believe that direct 
review by ONC is necessary to address potential non-conformities and 
non-conformities in certified health IT that may be leading to medical 
errors or contributing to other risks to public health or safety. As we 
have explained, although ONC-ACBs play an important role in the 
Program, addressing the full range of these suspected non-conformities 
is beyond the scope of their responsibilities under the Program. In 
addition, ONC-ACBs may as a practical matter lack the expertise and 
resources to effectively respond to certain types of non-conformities, 
such as widespread or systemic problems with certified capabilities. 
Other agencies may similarly be unable to effectively respond to these 
issues, especially when the underlying causes are unclear or involve 
complex interactions among multiple health IT capabilities or products. 
As the capabilities of certified health IT evolve and become ubiquitous 
in the delivery of care, the National Coordinator has a responsibility 
to continually update and enhance oversight of the Program so that 
certified health IT continues to improve, and does not compromise, 
patient safety.
    Addressing these types of issues will promote greater confidence in 
the safety of certified health IT and protect the integrity and 
effectiveness of the Program. Accordingly, Sec.  170.580(a)(2) 
addresses the process for ONC to directly review certified health IT 
when the health IT may be causing or contributing to conditions that 
pose a serious risk to public health or safety. We note that the policy 
we have finalized is consistent with the general sentiment expressed by 
commenters, as we understand it, that ONC should exercise direct review 
judiciously, focusing on risks to public health or safety that are 
serious and on non-conformities that cannot be effectively addressed by 
ONC-ACBs. As we stated in the Proposed Rule, we expect that ONC's 
exercise of direct review will be relatively infrequent. We discuss 
these considerations in detail in our responses to the comments 
summarized immediately below.
    We agree with commenters that advancing health IT safety is a 
shared responsibility and will require a concerted commitment by all 
relevant stakeholders, including through current public-private efforts 
and proposed initiatives such as the Health IT Safety Collaborative. We 
continue to strongly support these efforts and recognize the vital role 
they play in promoting the safety of health IT and the use of health IT 
to improve the safety and quality of care. We regard ONC's direct 
review as complementary to these efforts.
    We disagree with the view expressed by some commenters that 
concerns related to the safety of certified health IT are beyond the 
scope of current certification criteria, other Program requirements, or 
section 3001(c)(5) of the PHSA. We refer commenters to our discussion 
of these issues in section II.A.1.a.(1) of this preamble.
    Comments. We received relatively broad support for our proposal to 
enhance oversight of non-conformities that pose a risk to public health 
or safety, including through the direct review of such issues by ONC. A 
significant number of commenters urged us to prioritize public health 
and safety over other concerns by narrowing the scope of ONC's review 
to focus exclusively or primarily on non-conformities that pose serious 
risks to public health or safety. Commenters stated that this narrower 
focus would

[[Page 72418]]

allow ONC to concentrate its resources and provide more effective 
oversight of safety issues.
    Many commenters also recognized the need for and supported ONC's 
review of non-conformities that, for other reasons, would be difficult 
for ONC-ACBs to effectively address.
    Commenters were less supportive of applying ONC oversight of the 
Program to the other areas we had proposed, such as widespread non-
conformities that could compromise the security or protection of 
patients' health information in violation of applicable law, or that 
could lead to inappropriate claims for reimbursement under federal 
health care programs. A substantial majority of commenters urged us to 
significantly narrow and more clearly define the types of non-
conformities that ONC could potentially review. Commenters were 
concerned that, as proposed, ONC could conceivably review non-
conformities that implicate any of a wide and diverse range of 
potential subjects, from security breaches, to anti-competitive 
practices, to conditions giving rise to health disparities. This could 
lead to regulatory uncertainty or arbitrary enforcement, and could 
discourage innovation in health IT.
    For many of the same reasons, commenters urged us to clarify the 
specific types of circumstances or situations in which ONC would be 
likely to initiate direct review of certified health IT. While we had 
proposed several factors that ONC would consider in determining whether 
to initiate direct review, a number of commenters stated that these 
factors were too numerous or open-ended to provide useful guidance to 
stakeholders. Several commenters urged us to provide guidelines or 
examples explaining when ONC would be likely to initiate direct review. 
One commenter explained that by clarifying our methodology we could 
make the direct review process fairer and more equitable and establish 
confidence both in the process and its outcomes.
    Response. We agree with commenters that the types of non-
conformities ONC may review and, equally important, the types of 
circumstances in which ONC will take action to enforce Program 
requirements should be made as clear as possible and should be applied 
in a consistent and judicious manner. Such clarity and consistency help 
enable developers to design and make their certified health IT 
available in a manner that consistently meets Program requirements and 
the expectations of purchasers, licensees, and users of certified 
health IT. We also appreciate that uncertain or unnecessary regulation 
can have unintended consequences, including reducing incentives to 
invest in and to innovate the technologies that will make it possible 
to use health IT and health information to improve health and the 
delivery of care.
    In light of these and other considerations described below, we have 
reconsidered and revised our proposal in several key respects. 
Importantly, while the PHSA provides the National Coordinator the 
authority to directly review certified health IT in the broad range of 
circumstances we proposed, at this time we have finalized a regulatory 
framework for the exercise of such review in a more limited set of 
circumstances. This scope of review is consistent with our expectation 
stated in the Proposed Rule that direct review will be relatively 
infrequent and will focus primarily on issues that pose a risk to 
public health or safety (81 FR 11058) or that ONC-ACBs may be unable to 
effectively address without ONC's assistance or intervention (81 FR 
11061). While we stated that there could be other exigencies in 
addition to risks to public health and safety that could also warrant 
ONC's review, we agree with commenters that the need for additional ONC 
oversight in these areas is less pronounced at this time. In 
particular, we note the active oversight in these areas by other 
agencies, as discussed below. In light of this existing oversight and 
the limited resources at ONC's disposal, we agree with commenters that 
it is advisable to focus ONC's resources in areas in which, at this 
time, additional and direct oversight by ONC is most vital to ensuring 
the integrity and effectiveness of the Program. We believe that 
focusing ONC's review in these areas will help foster alignment and 
coordination with other agencies and promote confidence in the 
performance of certified health IT and the nation's health IT 
infrastructure, which will in turn support innovations and investments 
in health IT.
    For all of these reasons, we have finalized processes in this rule 
for ONC to exercise direct review of certified health IT in two 
distinct sets of circumstances.
    First, ONC may elect to directly review certified health IT when 
there is reason to believe that the certified health IT may be causing 
or contributing to serious risks to public health or safety. In these 
circumstances, ONC's direct review of certified health IT may be 
necessary to protect the public from certified health IT that is unsafe 
and to ensure the basic integrity and effectiveness of the Program. As 
explained in section II.A.1.a.(1) of this preamble, it is a requirement 
of the Program that certified health IT be made available in a manner 
that does not cause or contribute to serious risks to public health or 
safety. However, responding to the full range of these suspected non-
conformities is beyond the scope of an ONC-ACB's expertise and 
responsibilities under the Program. In contrast, ONC is well-placed to 
respond to these issues, through the direct review processes 
established by this final rule, bringing to bear needed expertise and 
resources and coordinating activities with federal counterparts and 
other relevant entities to ensure a coordinated review and response to 
public health and safety concerns (81 FR 11061).
    Second, in addition to serious risks to public health or safety, 
ONC may elect to directly review certified health IT on the basis of 
other suspected non-conformities that, while within the scope of an 
ONC-ACB's responsibilities, present practical challenges that may 
prevent the ONC-ACB from effectively investigating the suspected non-
conformity or providing an appropriate response. In particular, ONC may 
directly review certified health IT if a suspected non-conformity 
presents issues that may require access to certain confidential or 
other information that is unavailable to an ONC-ACB; may require 
concurrent or overlapping reviews by multiple ONC-ACBs; or may exceed 
the scope of an ONC-ACB's resources or expertise. We believe that ONC's 
review of certified health IT in these situations will help ensure the 
continued effective oversight and administration of the Program.
    The circumstances described above do not encompass all possible 
non-conformities of certified health IT. For example, certified health 
IT may not conform to the requirements of the Program if it is causing 
or contributing to other outcomes--distinct from risks to public health 
or safety--that are inconsistent with the National Coordinator's 
responsibilities, such as compromising the security or protection of 
patients' health information in violation of applicable law (see 
section 3001(b)(1) of the PHSA) or increasing health care costs 
resulting from, for example, inefficiency or incomplete documentation 
(see section 3001(b)(3) of the PHSA). At this time, however, we believe 
that other agencies are in the best position to provide effective 
federal oversight and enforcement in these areas. For example, within 
HHS, the Office for Civil Rights' (OCR) enforces the Privacy, Security, 
and Breach Notification Rules promulgated under the Health Insurance 
Portability and

[[Page 72419]]

Accountability Act of 1996 (HIPAA) and amended by the HITECH Act, and 
the Office of Inspector General (OIG) enforces a range of federal laws 
related to fraud, waste, and abuse. Therefore, we have not at this time 
finalized regulatory processes by which ONC would directly review 
certified health IT solely on the basis of circumstances distinct from 
public health or safety concerns or in cases where practical challenges 
prevent an ONC-ACB from effectively investigating the suspected non-
conformity or providing an appropriate response, as discussed above 
(compare 81 FR 11061). We will continue to assess the need to exercise 
direct review in these additional circumstances, as necessary
    As mentioned above, in this final rule, we seek to align ONC's 
direct review of certified health IT with oversight and enforcement 
responsibilities of other agencies. We therefore clarify that ONC may 
decline to exercise review of certified health IT for any reason, 
including if it believes that other agencies may be better situated to 
respond to a suspected non-conformity. Additionally, to the extent 
permitted by law, ONC may coordinate and share information with other 
agencies, including agencies with applicable oversight or enforcement 
responsibilities, and may engage other persons and entities, as 
appropriate, to effectively respond to suspected problems or issues 
with certified health IT.\7\ Such agencies could include, for example, 
the Centers for Medicare and Medicaid Services, the Food and Drug 
Administration, the HHS Office for Civil Rights, the HHS Office of 
Inspector General, the Department of Veterans Affairs, the Federal 
Communications Commission, or state Medicaid agencies. We note that to 
the extent ONC exercises its discretion to engage in any efforts to 
identify or address non-conformities, such efforts and any resulting 
remediation (or the absence of such efforts or remediation) are not 
intended to impact the materiality of any non-conformity in a matter 
addressed by another agency; and nothing in this final rule is intended 
to supplant, delay, or in any way limit oversight or enforcement by 
other agencies, including any investigation, decision, legal action, or 
proceeding.
---------------------------------------------------------------------------

    \7\ Example E in section II.A.1.a.(3) of this preamble 
illustrates the complementary roles of ONC's direct review and the 
activities of other agencies.
---------------------------------------------------------------------------

    Finally, our decision to focus ONC's review, at this time, on the 
types of non-conformities described above allows us to provide a more 
structured decision-making regulatory framework to support the exercise 
of ONC's discretion to initiate review of certified health IT in the 
circumstances we have described. In contrast to the framework set forth 
in the Proposed Rule, we have simplified and defined with greater 
specificity the factors ONC will consider in determining whether to 
initiate direct review of a suspected non-conformity. The updated 
regulatory framework, which we have finalized at Sec.  170.580(a)(2), 
provides a more sequential and targeted set of factors that ONC will 
consider when determining whether to initiate direct review. We have 
also eliminated duplicative or redundant factors included in the 
Proposed Rule, as discussed in more detail in our responses to comments 
on those factors below. These revisions will provide clear and 
predictable guidelines that will promote compliance with Program 
requirements while preserving incentives to develop and adopt new and 
innovative technologies.
    Comments. Several commenters suggested that ONC should focus its 
oversight on risks to public health or safety that are ``clear,'' 
``severe,'' ``immediate,'' ``extreme,'' or otherwise compelling. A few 
commenters stated that ONC should not exercise direct review unless the 
risk to patient safety or public health poses imminent risks to public 
health or safety. Commenters stated that focusing on these types of 
risks would ensure that ONC's limited resources are used to mitigate 
the problems or issues with certified health IT that pose the most 
serious risks of harm to patients and the public. Separately, some 
commenters stated that exercising direct review of all potential risks 
could be counter-productive in that it may discourage efforts to 
implement and use health IT to improve patient safety and care.
    Relatedly, commenters requested additional specificity regarding 
the types of risks to public health or safety that could trigger ONC's 
review or give rise to a non-conformity. One commenter requested that 
ONC provide examples to illustrate how certified health IT might 
contribute to risks to patient safety and public health.
    Response. We agree that not every risk to public health or safety 
necessitates ONC's direct review. We are also cognizant of the need to 
prioritize ONC's limited resources by focusing on the kinds of problems 
and other issues that, if not addressed through ONC's direct review, 
are most likely to lead to harm to patients or the public and undermine 
confidence in health IT and the integrity of the Program.
    As described in section II.A.1.a.(1) of this preamble, to conform 
to the requirements of the Program certified health IT must be designed 
and made available to users in a way that allows certified capabilities 
to be used in an accurate and reliable manner. This includes making 
capabilities available in a manner that does not cause or contribute to 
medical errors or other conditions that give rise to serious risks to 
public health or safety. Direct review would be appropriate if ONC had 
reason to believe that certified health IT were causing or contributing 
to conditions that present a serious risk to public health or safety, 
including conditions that could result in serious injury or death, 
whether to a patient or to any other person.
    Our focus on risks to public health or safety that are ``serious'' 
is consistent with the Proposed Rule, in which we suggested that ONC's 
direct review would be appropriate in response to certified health IT 
causing or contributing to medical errors or other exigent 
circumstances that call for an immediate or coordinated governmental 
response (81 FR 11058; compare proposed Sec.  170.580(a)(1)(ii) through 
(iii) at 81 FR 11082). This focus also aligns with the general 
sentiment expressed by commenters that ONC's review of matters 
involving public health or safety should focus on risks that are 
``clear,'' ``severe,'' ``immediate,'' ``extreme,'' or otherwise 
compelling. We note that these terms are not self-defining and that 
assessing whether certified health IT poses serious risks to public 
health or safety will necessarily involve a careful consideration of 
the relevant facts and circumstances in each case. To this end, ONC 
would consider the nature, extent, and severity of the risk and the 
conditions giving rise to it, in light of the information available to 
ONC at the time. In addition to any other factors that may be relevant, 
ONC would consider the apparent severity of the harm that might result, 
or has resulted, from the suspected unsafe conditions, including the 
likelihood of death or serious injury; the number of persons who may be 
harmed in the event that the harm were to materialize; and the 
likelihood that harm will in fact materialize if appropriate action is 
not taken. ONC would also consider the extent to which the risk of harm 
may be imminent such that an immediate or coordinated governmental 
response is necessary to significantly reduce the likelihood of actual 
harm occurring or recurring (Sec.  170.580(a)(2)(i)(B)). In evaluating 
whether the risk of harm may be imminent, ONC would also take into

[[Page 72420]]

account any actions being taken to mitigate the risk, to the extent 
that ONC is aware of those actions. We have declined to adopt 
commenters' suggestions that ONC should focus exclusively on the 
``imminence'' of a potential risk to public health or safety when 
determining whether to exercise direct review. While the nature of 
public health or safety risks dictates that in most cases they will be 
imminent, we can envision scenarios in which a risk might not be 
strictly ``imminent'' at the time ONC determines that it will initiate 
its review but might nonetheless lead to serious harm if not addressed. 
For example, ONC might decide to exercise direct review if it became 
aware of information about a serious safety risk that a developer, in 
concert with its healthcare provider customers, is managing by way of a 
complex series of manual ``work-arounds'' until the scheduled release 
of the developer's next software update. While the developer may assert 
that the risk to patients is not imminent because of the existence of 
the manual work-arounds, it may be necessary--both to protect patients 
and the integrity and effectiveness of the Program--for ONC to review 
the safety risk at issue immediately and not have to wait until such 
time as the manual work-arounds fail. ONC may, as part of direct review 
in this instance, determine that the risk to patient safety is such 
that, for the health IT to remain certified, the developer must rectify 
the deficiency by way of a patch and not wait until the developer's 
next scheduled software release.
    Separate from information about unsafe conditions in particular, 
ONC could conclude that certified health IT poses a serious risk to 
public health or safety were it aware of information calling into 
question the validity of the health IT's certification. Such 
information might include, for example, credible allegations that a 
health IT developer obtained or maintained any part of the 
certification of its health IT by means of false or misleading 
statements or representations to an ONC-ACB; misrepresented or made 
false or misleading statements to customers or users about the 
certification or certified capabilities of the health IT; concealed 
problems, deficiencies, or potential non-conformities; or took other 
actions that would be likely either to compromise or to circumvent 
processes under the Program for testing, certifying, and conducting 
ongoing surveillance and review of certified health IT. These 
circumstances present a serious risk to public health or safety because 
obtaining and maintaining a valid certification is fundamental to 
ensuring that health IT meets Program requirements, including 
requirements essential to providing basic assurance that health IT is 
able to perform required capabilities in an accurate and reliable 
manner. Indeed, customers, implementers, and users rely on the 
certifications issued on behalf of ONC to provide this basic assurance 
so that they can select appropriate technologies and capabilities, 
identify potential implementation or performance issues, and implement 
certified health IT in a predictable, reliable, and successful manner 
(80 FR 62709). Where the validity of a certification is called into 
question, these and other persons are unknowingly deprived of this 
basic assurance upon which they rely.
    To further illustrate these principles and how they would be 
applied in practice, we offer the following contrasting examples.
    Example A: ONC receives multiple, detailed reports that a cloud-
based EHR system (certified to the 2015 Edition) has become so slow 
that it may take up to five minutes to load a patient's record or to 
display information within a patient's record, such as the patient's 
medication and medication allergy lists. When providing emergency 
treatment, clinicians cannot wait five minutes for this information and 
must order medications with incomplete information about patients' 
current medications and medication allergies. Even when treatment is 
not urgent, the system's delays in responding lead many clinicians to 
assume that the EHR is not working and to order medications based on 
their best recollection of patients' current medications and allergies.
    Clinicians at several hospitals in multiple states are experiencing 
these problems. There is no indication that these hospitals are 
maintaining substandard hardware or network infrastructure below the 
recommendations from the health IT developer, nor that they have 
customized their health IT in a way that would adversely affect system 
performance. The health IT did not behave this way when it was 
installed, but as the clinical data and number of records has grown the 
speed of the EHR's responsiveness has decreased.
    In this example, ONC may initiate direct review of the certified 
health IT. The facts suggest that several capabilities of the certified 
health IT are implicated, including Sec.  170.315(a)(6) (Problem list) 
and Sec.  170.315(a)(7) (Medication list). The capabilities as 
implemented appear to be performing or interacting in a way that is 
causing or contributing to a serious risk of harm to public health or 
safety. The risk of harm is serious for several reasons. First, 
clinicians are abandoning use of the capabilities and resorting to 
memory to order medications for patients, which could result in severe 
harm to patients, including serious injury or death. Moreover, the risk 
is imminent because it is likely that harm will occur soon unless 
immediate action is taken to address the unsafe conditions. Further, 
the extent of the risk is large because the unsafe conditions have been 
reported at several hospitals in multiple states and may therefore put 
at risk a large number of patients.
    Assuming ONC were to initiate direct review, it would examine the 
certified capabilities to determine why they are not performing in an 
accurate and reliable manner and whether the cause of the problem was 
within the ability of the health IT developer to reasonably influence 
or control. The facts suggest that the problem is common across 
multiple customers and is not the result of any actions of the 
developer's customers or users. Because the problem developed over 
time, the developer would have been aware of the problem and could have 
prevented it by employing best software practices to prevent a system 
related slow-down under load. If this were established, ONC would find 
a non-conformity.
    Example B: ONC receives credible information from multiple sources 
that a large hospital's EHR system, which is certified to the 2015 
Edition, is dropping medication orders. While the cause of the dropped 
orders is not yet clear, data in patients' records is not being 
recorded in a consistent and reliable manner, which is leading to 
patients not receiving medications.
    Based on the information it has received, ONC believes that the EHR 
system's computerized provider order entry (CPOE) capability for 
medications (Sec.  170.315(a)(1)) may be interacting with other 
capabilities within the EHR or within other health IT in a way that is 
causing or contributing to orders not arriving when they are needed. 
This poses a serious risk to public health or safety because there is 
an imminent risk that patients will not receive needed or even life-
saving medications that have been ordered for them, which could result 
in severe harm.
    Accordingly, ONC initiates review of the certified health IT. 
However, during the course of its review, ONC determines that the 
hospital had chosen not to install and maintain the minimum specified 
hardware and

[[Page 72421]]

network requirements published by the developer of the certified health 
IT. As a direct result of the substandard hardware and network 
connectivity, the certified health IT is suffering system timeouts, 
losing network packets, and not operating correctly. Based on these 
findings, ONC finds that while the certified capability is not 
performing in an acceptable manner, the reason for the substandard 
performance is that the hospital has chosen not to follow the 
developer's minimum hardware and network recommendations. The 
hospital's decision to intentionally disregard the developer's clear 
instructions regarding the safe use of its technology is a factor that 
is beyond the ability of the developer to reasonably influence or 
control. Therefore, ONC would not find a non-conformity and would cease 
its review. ONC may, however, refer the matter (and information or 
evidence obtained as a result of its review) to other agencies with 
applicable oversight or enforcement responsibilities, as discussed 
above in this section of the preamble.
    Example C: ONC receives multiple reports from a large hospital 
concerning a potential problem with its EHR. Over the past week, 
several patients with congestive heart failure (CHF) had to be 
readmitted because of CHF exacerbations. Clinical and IT staff at the 
hospital have investigated the problem and believe that it is due to an 
error in the hospital's EHR, which is certified to the 2015 Edition. 
The hospital reports that its CHF patients are all given electronic 
scales that record their weight and automatically transmit the daily 
weight back to the hospital's EHR. The weight can be tracked and the 
patients can be alerted if they are gaining too much weight (from 
excess fluid, one of the signs of a CHF exacerbation) and need to 
adjust their CHF medications accordingly. The readmissions happened due 
to inaccurate weight data being presented to clinicians, which caused 
the clinicians to not adjust diuretic medication to manage patients' 
fluid status appropriately.
    Based on these facts, ONC may initiate direct review of the 
certified health IT. ONC could form a reasonable belief that the 
certified health IT may be causing or contributing to serious risks to 
public health or safety, in violation of Program requirements. A number 
of certified capabilities appear to be implicated, including Sec.  
170.315(e)(3) (Patient Health Information Capture) and certified 
capabilities that interact with vital signs data (which is part of the 
Common Clinical Data Set (Sec.  170.102)). Although the cause of the 
problem is not yet clear, it is reasonable to believe that it may be a 
result of one or more of these certified capabilities or of their 
interaction with other uncertified capabilities or products. Meanwhile, 
the occurrence of multiple readmissions in the past week suggests that, 
if the certified health IT is causing or contributing to these risks to 
public health or safety, the risks are sufficiently serious as to 
constitute a non-conformity and to warrant ONC's review.
    Example D: ONC becomes aware of a patient safety hazard at a large 
area hospital. In one reported case, a patient with chest pain entered 
the emergency department (ED) of the hospital. In the ED, nurses enter 
protocol orders for patients with chest pain on behalf of the attending 
physician. On this occasion, an attending physician accessed the 
patient's record in the EHR and, observing that no blood tests had been 
ordered, proceeded to order the tests from the standard order set. 
Contemporaneously, a nurse was in the process of entering the same 
tests from the same order set. The nurse completed her order a few 
seconds before the physician completed hers. Neither the nurse nor 
physician recall any duplicate order alerts, although hospital IT staff 
state that clinical decision support (CDS) was active in the EHR system 
and had been configured to intercept and display alerts when duplicate 
orders are entered. The duplicate orders were noticed later when the 
physician was reviewing the patient's record in the EHR. At that time, 
the physician cancelled the nurse's order, which thereafter was no 
longer displayed in the EHR. The EHR continued to display the 
physician's order with a status of ``pending collection.'' The lab 
system assumed that the identical lab requests for the same patient 
were duplicates and cancelled the physician's request because the 
nurse's request had arrived first. The lab system, however, did not 
create an outgoing interface message to the ordering EHR indicating 
that the physician's ``duplicate'' request had been cancelled. As a 
result, the physician's order continued to be displayed in the EHR with 
a status of ``pending collection.''
    Back in the ED, alert staff noticed that the labs had not been 
drawn within the expected time frame, and reordered the tests. 
Fortunately no harm resulted to the patient. However, the hospital's 
clinical staff and leadership believe the EHR presents a serious 
patient safety hazard. The clinicians report the incident to ONC and 
note that in a large and busy ED it is not uncommon for clinicians to 
enter contemporaneous orders; and that they expect the EHR to alert 
them when this occurs and to intercept duplicate orders before they are 
transmitted. The hospital's IT staff and the EHR developer, with whom 
the IT staff have been working to analyze this incident, believe that 
the EHR was configured to provide these CDS interventions. Neither the 
hospital's IT staff nor the EHR developer has been able to ascertain 
why these safeguards appear to have failed in this case. Based on these 
facts, ONC could form a reasonable belief that the certified health IT 
may be causing or contributing to a serious risk to public health or 
safety. As noted by the hospital's clinical staff and leadership, 
duplicate orders are not uncommon, especially in a large and busy ED. 
If not detected, the duplicate orders may lead to a wide range of 
serious hazards, such as administration of unnecessary tests or 
excessive medication dosages. And as illustrated by this example, the 
failure to detect and intercept duplicate orders may also have 
downstream effects that could prevent the fulfillment of orders and 
result in patients not receiving timely test results and treatment. The 
severity and extent of the harm that could occur is significant and is 
likely to materialize unless the cause of the problem is isolated and 
resolved. That the hospital's IT staff and the EHR developer are 
cooperating and yet have been unable to ascertain the cause of the 
problem is also relevant to ONC's consideration because it suggests 
that the problem could reoccur and that the full extent of the problem, 
including for other hospitals or facilities that use the developer's 
EHR, is not known.
    While the risk to public health or safety is clear, to initiate 
direct review, ONC must have a reasonable belief that the certified 
health IT may be causing or contributing to that risk. Here, there are 
at least two certified capabilities that are potentially implicated: 
CPOE (Sec.  170.315(a)(3)) and CDS (Sec.  170.315(a)(9)). This nexus to 
certified capabilities is sufficient for ONC to initiate direct review.
    Concurrently, ONC might direct the responsible ONC-ACB to perform 
surveillance of issues that are within the scope of its 
responsibilities and expertise. Here, an ONC-ACB could conduct in-the-
field surveillance of the CPOE and CDS capabilities to determine 
whether there is a non-conformity to the requirements of Sec.  
170.315(a)(3) or (a)(9). For example, the ONC-ACB would be well-
positioned to determine through in-the-field surveillance whether the 
certified CDS capability, when properly configured to intercept and 
alert users to

[[Page 72422]]

duplicate orders, consistently triggers those interventions in a 
reliable manner in a production environment.
    On the other hand, an ONC-ACB may be unable to analyze other 
possible non-conformities. For example, it may be that the CDS reliably 
displays alerts as intended but that the alerts are designed in a way 
that makes them susceptible to being inadvertently overridden. These 
usability considerations are within the scope of the Program's 
requirements but may be best suited for ONC to review. ONC could also 
examine the interaction of the certified capabilities with the 
receiving lab system (which may or may not be certified under the 
Program), which in this example is critical to isolating and 
understanding the nature of the problem and assessing whether the 
certified health IT conforms to Program requirements. In reaching that 
determination, ONC would consider whether the EHR developer could have 
reasonably anticipated that the lab system would cancel the orders 
without sending a notification of the cancellation and whether it could 
have taken reasonable steps to mitigate this risk (such as warning 
users to manually confirm the orders or providing a bi-directional 
interface that ensures that users are able to view when orders are in 
fact received and filled). This may require analyzing the EHR 
developer's interfaces and contractual agreements with the lab system 
as well as the EHR developer's field testing and quality assurance 
procedures. Again, these factors may be beyond the expertise of the 
ONC-ACB and better suited for ONC's review.
    As the foregoing examples illustrate, the particular facts and 
circumstances that may trigger ONC's review of certified health IT will 
be unique to each case, as will be the analysis of the issues relevant 
to determining whether the certified health IT conforms to Program 
requirements. Nevertheless, we believe the examples above will help 
stakeholders understand the types of risks to public health or safety 
that may prompt ONC's review and that may lead to a finding of non-
conformity. We anticipate issuing additional guidance on these and 
other aspects of this final rule as appropriate.
    Comments. A small number of commenters distinguished between risks 
to patient safety and those related to broader public safety or public 
health. Some commenters stated that direct review would not be 
appropriate in circumstances that pose a risk of harm to public health 
but not specifically to patient safety. In contrast, one commenter 
posited that public health considerations may justify or weigh in favor 
of direct review in certain situations, such as where problems with 
certified health IT may adversely impact socially or medically 
vulnerable populations.
    Response. We intend the term public health or safety to encompass 
risks to both patients and other persons. Given the central role of 
health IT in delivering care, it is likely that ONC's oversight will 
focus on risks of harm to patients. However, we would be no less 
concerned if certified health IT were causing or contributing to risks 
of harm to persons other than patients, and we believe that the 
National Coordinator's responsibility to provide for effective 
oversight of certified health IT so that it does not create 
unreasonable risks of harm to patient safety applies with equal force 
to risks involving public health.
    We note that under the approach we have finalized, ONC would 
consider the potential nature of a public health or safety risk when 
reaching a determination whether to initiate direct review. Thus ONC's 
determination would take into account the impact that the potential 
risk is having, or might have, on a patient(s). This determination 
would necessarily involve an analysis of the risk as it relates to the 
affected patient population.
    Comments. A number of commenters voiced concerns about the factors 
that ONC would consider when determining whether to initiate direct 
review, characterizing those factors as overly broad and creating a 
risk of arbitrary application. Commenters noted in particular that the 
phrase ``other exigent circumstances'' was ambiguous. Some commenters 
suggested that ONC's potential reliance on such an open ended factor 
would enable ONC to exercise direct review in an unaccountable manner. 
Commenters requested clarification or reconsideration of the inclusion 
of ``other exigent circumstances'' as a factor to be considered by ONC 
when initiating direct review.
    Response. We identified a number of factors in the Proposed Rule 
that ONC might consider when determining whether to exercise its 
discretion to initiate direct review. These factors were included to 
provide health IT developers with some comfort that while ONC's 
authority to initiate direct review is broad, ONC's use of direct 
review would be guided by principles that focus ONC's limited resources 
on the oversight of non-conformities that pose substantial risks to the 
integrity and effectiveness of the Program. Indeed, the inclusion in 
the proposal of the phrase ``other exigent circumstances'' was intended 
to narrow ONC's discretion rather than, as suggested by commenters, 
provide ONC with a degree of flexibility that would make ONC's exercise 
of direct review unaccountable. Notwithstanding this, we acknowledge 
commenters' concerns regarding the open-ended nature of the phrase 
``other exigent circumstances.'' We maintain that there could be other 
exigencies, distinct from public health or safety concerns, that pose 
risks to the integrity and effectiveness of the Program and warrant 
ONC's direct review and action. However, at this time, our decision to 
focus on public health and safety risks (in addition to non-
conformities over which, for practical or other reasons, ONC-ACBs may 
be unable to provide effective oversight) at this stage of our 
administration of the Program has enabled us to omit any reference in 
the final rule to ONC considering ``other exigent circumstances'' when 
determining whether to exercise direct review.
    We clarify that while under the processes established by this final 
rule ONC would not, at this time, initiate direct review solely on the 
basis of exigencies other than serious risks to public health or 
safety, and while ONC's review would focus on aspects of health IT that 
are certified under the Program, ONC would not be precluded from 
sharing, to the extent permitted by federal law, any information or 
evidence (including about other exigent circumstances or problems with 
uncertified capabilities of health IT) with other relevant agencies, 
including law enforcement or other agencies who may be able to address 
such matters. Conversely, ONC may receive information about potential 
non-conformities or non-conformities from other agencies in the course 
of their oversight, enforcement, or other activities. As an 
illustration, consider the following example.
    Example E: A Health IT Module certified to the 2015 Edition (``the 
EHR'') is the subject of a ``ransomware'' attack. The attacker gained 
unauthorized access to the EHR at multiple health care facilities and 
deployed malicious software that rendered patients' electronic health 
information completely inaccessible to clinicians and other users of 
the EHR. Several of these facilities have reverted to backup systems, 
including in some cases paper records and manual workflows that 
significantly increase the risks of medical errors and harm to 
patients. Several federal agencies (``the Agencies'') are currently 
investigating the attack. The Agencies request the

[[Page 72423]]

assistance and expertise of ONC's Chief Privacy Officer to better 
understand the role of the EHR in contributing to the incident. The 
investigation quickly reveals that the attacker exploited a 
vulnerability in the operating system software (OS) used in conjunction 
with the EHR. The OS was out of date and no longer receiving security 
updates. The Agencies, concerned about the prospect of additional 
security breaches, share this information confidentially with ONC.
    For the reasons stated earlier in section II.A.1.a.(3) of this 
preamble, ONC would not initiate direct review of the certified health 
IT solely on the basis of security incidents or other exigencies that 
are distinct from risks to public health or safety. At this time, we 
believe that other agencies are currently best positioned to provide 
effective oversight and enforcement of health IT with respect to these 
potential exigencies. Nevertheless, as the facts of this example make 
clear, these exigencies may also give rise to serious risks to public 
health or safety. Where certified health IT may be causing or 
contributing to risks of this kind, ONC may initiate direct review to 
protect the public and the integrity and effectiveness of the Program.
    Here, ONC initiates direct review based on the information received 
from the Agencies. To ensure that ONC's review assists and does not in 
any way hinder the ongoing investigation, ONC carefully coordinates 
with the Agencies and shares information and evidence it obtains during 
its review. ONC's review confirms that the developer of the EHR 
requires users to install and use a version of the OS that is no longer 
supported by the OS manufacturer and is not receiving security updates. 
All certified capabilities of the EHR are affected by this requirement, 
which exposes users to vulnerabilities and attacks that could 
compromise patient data and result in serious harm to patients. At the 
same time, ONC finds that the developer could have reasonably 
anticipated, and avoided, these risks because the OS manufacturer had 
published many notices that the version of the OS was being retired and 
would no longer receive security updates. Based on these findings, ONC 
issues a notice of non-conformity to the developer.
    By contrast, if ONC had found that the health IT developer offers 
an upgrade path to the latest versions of the operating system 
software, and encourages its users to upgrade, ONC would not find a 
non-conformity if users decided to not install the upgrade.
    Comments. Commenters suggested that we clarify our proposed 
methodology for assessing the ``nature, severity, and extent'' of a 
suspected non-conformity and the significance of this factor to ONC's 
determination whether to initiate direct review.
    Response. In response to the concerns raised by commenters, we have 
made a number of adjustments in the final rule that will create greater 
predictability for the process that ONC will use to determine when to 
initiate direct review.
    The proposals in the Proposed Rule outlined a direct review process 
in which ONC would exercise wide latitude to consider and weigh factors 
when determining whether to initiate direct review. As proposed, ONC 
might evaluate a number of factors that could be relevant to the 
particular circumstances at issue at the same time. However, at this 
time, we have chosen to narrow the scope of potential non-conformities 
and non-conformities ONC will review as described above. Given this 
narrower scope, we are able to delineate the specific factors that ONC 
will consider and apply when determining whether to initiate direct 
review of certified health IT.
    Under the final rule, the nature, severity, and extent of a non-
conformity would be relevant if ONC were to initiate review of a 
suspected non-conformity on the basis of public health or safety 
concerns. In that instance, ONC would have a reasonable belief that 
certified health IT may be causing or contributing to conditions that 
pose a serious risk to public health or safety. The potential nature, 
severity, and extent of the suspected conditions giving rise to that 
risk would be directly relevant to this determination, as would the 
need for an immediate or coordinated governmental response. These 
considerations are described in greater detail earlier in section 
II.A.1.a.(3) of this preamble. We have expressly included these 
considerations as factors that ONC will consider when determining 
whether certified health IT may be causing or contributing to risks 
that are sufficiently serious as to suspect that the certified health 
IT does not conform to the requirements of the Program and ONC's direct 
review.
    Separately, and as also discussed in section II.A.1.a.(3) of this 
preamble, ONC may directly review certified health IT when a suspected 
non-conformity, while based on requirements of the Program that are 
generally within the scope of an ONC-ACB's responsibilities to 
administer and enforce, presents issues that may prevent the ONC-ACB 
from effectively investigating or responding. The nature, severity, and 
extent of a suspected non-conformity may be relevant to this 
determination. For example, the suspected non-conformity may be so 
systemic, complex, or widespread that an ONC-ACB would lack the 
resources or expertise to effectively investigate or respond to it. On 
this basis, ONC may directly review the suspected non-conformity.
    Comments. One commenter suggested that ONC include additional 
factors for assessing when to exercise its direct review. This 
commenter recommended that ONC develop an additional factor that 
ensures that ONC's decision to initiate direct review takes into 
account the impact of non-conformities on socially and medically 
vulnerable populations.
    Response. Under the final rule, ONC will consider the potential 
nature, severity, and extent of a public health or safety risk when 
reaching a determination as to whether to initiate direct review. This 
determination would take into account the potential impact the risk is 
having, or might have, on a patient(s) or the public. We anticipate 
that an analysis of the affected population could be relevant to that 
determination. For example, an issue might present a less serious risk 
of harm to patients at a large tertiary hospital with in-house IT staff 
and robust quality assurance processes than to patients served by a 
safety-net provider with no in-house IT expertise and less extensive 
quality controls and resources than might be available to a large 
institution.
    Comments. Many commenters expressed support for ONC direct review 
in situations where ONC-ACBs may be unable to effectively investigate 
or respond to potential non-conformities. Several commenters recognized 
that there may be a variety of situations in which ONC-ACBs are unable 
to effectively investigate and respond to non-conformities, such as 
where doing so would require access to confidential or other 
information that is unavailable to an ONC-ACB, would exceed the 
resources or capacity of an ONC-ACB, or would involve novel or complex 
interpretations or application of certification criteria or other 
Program requirements. One commenter recommended that ONC invest in and 
empower ONC-ACBs to enable them to investigate and address non-
conformities that are currently beyond the scope of their 
responsibilities under the Program.
    All three ONC-ACBs commented on this aspect of our proposal. One 
ONC-ACB related that in its own surveillance it had encountered 
scenarios in which

[[Page 72424]]

ONC's direct oversight would have proven beneficial to the situation 
and its resolution. Another ONC-ACB stated that it had received 
complaints from users of certified health IT that raised issues 
(including issues related to patient safety) that were beyond the scope 
of the ONC-ACBs' accreditation and ability to address but that could be 
governed by the broader requirements of the Program. The remaining ONC-
ACB did not believe that ONC should enforce any Program requirements 
that ONC-ACBs themselves could not administer in accordance with their 
accreditation; however, the ONC-ACB did support ONC's direct review of 
non-conformities whose nature, severity, or extent would be likely to 
quickly consume or exceed an ONC-ACB's resources or capacity.
    Some commenters suggested that ONC should only intervene due to 
ONC-ACB limitations in very limited circumstances and that ONC should 
use its discretion in this respect as a ``last resort.'' One commenter 
suggested that ONC refine the factors that it will consider when 
determining whether to initiate direct review on this basis. Another 
commenter suggested that ONC should only initiate direct review on the 
basis of ONC-ACB limitations when clearly defined criteria are met; the 
commenter provided the example of a non-conformity involving the 
interaction of two health IT products certified by separate ONC-ACBs 
and having a proven and urgent impact on patient safety.
    Response. We thank commenters for their support and thoughtful 
comments on this aspect of our proposal. We have adopted the proposed 
approach to ONC direct review when ONC-ACBs may lack necessary 
expertise or resources, with the following clarifications. ONC may 
exercise direct review on the basis of suspected non-conformities that, 
while generally within the scope of an ONC-ACB's responsibilities and 
expertise, may present issues that could prevent an ONC-ACB from 
effectively investigating or providing an effective response. In these 
circumstances, ONC's direct review of the certified health IT is 
appropriate to help ensure consistency in the effective oversight and 
administration of the Program. Specifically, under the processes 
established in this final rule, ONC may directly review certified 
health IT if investigating or responding to a suspected non-conformity 
may require access to confidential or other information that is 
unavailable to an ONC-ACB (Sec.  170.580(a)(ii)(A)); may require 
concurrent or overlapping reviews by multiple ONC-ACBs (Sec.  
170.580(a)(ii)(B)); or may exceed the scope of an ONC-ACB's resources 
or expertise (Sec.  170.580(a)(ii)(C)).
    In response to the comments and to provide additional clarity 
regarding the types of circumstances that may exceed an ONC-ACB's 
resources or expertise, we provide the following example, which 
includes three alternative scenarios. The scenarios, which are mutually 
exclusive, illustrate how variations in facts and circumstances may 
give rise to different issues that necessitate different levels of 
involvement and forms of collaboration between ONC and ONC-ACBs.
    Example F: An EHR system certified to the 2015 Edition is in use by 
several major hospitals and health systems, including their ambulatory 
clinics, in multiple states. During a span of two weeks, over a dozen 
users at multiple health care facilities report to ONC and to the ONC-
ACB that the EHR is displaying inaccurate or missing diagnoses 
(problems) and that, as a result, patients are not receiving 
appropriate care. In one reported instance, a patient was diagnosed 
with renal impairment, and this diagnosis was entered into the 
patient's active problem list in the EHR by her primary care physician 
(PCP). The PCP then referred the patient to an orthopedist for an 
unrelated musculoskeletal issue. The orthopedist is affiliated with the 
same health system as the PCP and has access to the same instance of 
the EHR. When the orthopedist accessed the patient's problem list, the 
diagnosis for renal impairment was missing from any relevant sections 
as displayed in the EHR. Unaware of this diagnosis, the orthopedist 
prescribed a medication for musculoskeletal pain that should either be 
avoided or minimized in patients with renal impairment. As a result, 
the patient suffered acute renal failure. Similar instances involving 
other missed or inaccurate diagnoses and resulting harm to patients 
have also been reported to ONC and the ONC-ACB.
    Based on the information described above, the ONC-ACB initiates in-
the-field surveillance of the certified health IT, as required by Sec.  
170.556(b), to assess whether the problem list capability continues to 
conform to the requirements of the certification criterion at Sec.  
170.315(a)(6) (Problem list). Separately, because the certified health 
IT may be performing in a manner that is causing or contributing to a 
serious risk to public or health or safety, ONC also initiates direct 
review of the certified health IT on this basis. ONC does not exercise 
exclusive \8\ review under the Program at this time.
---------------------------------------------------------------------------

    \8\ Under the final provisions, ONC may assert exclusive review 
of certified health IT as to any matters under its review and any 
similar matters under surveillance by an ONC-ACB. In determining if 
matters are similar, ONC will, as proposed, consider whether the 
matters are so intrinsically linked that divergent determinations 
between ONC and an ONC-ACB would be inconsistent with the effective 
administration or oversight of the Program.
---------------------------------------------------------------------------

Scenario 1
    The ONC-ACB's in-the-field surveillance reveals that the cause of 
the issue is a software error that is only found in one EHR 
``workflow.'' The EHR presents the user with multiple ways, or screens, 
to accomplish the same task. In this case, the PCP modified the problem 
list from a ``quick summary screen,'' which due to a software error did 
not write the updated diagnosis (problem) back to the database. This 
led to a situation where the PCP thought the diagnosis had been 
updated, but in fact on the back end, the list had not been updated. 
The EHR, when tested for certification, had presented the ``standard 
office visit'' screen for diagnosis list modification but not the 
``quick summary screen,'' which is an alternate workflow available only 
in production.
    The ONC-ACB concludes that the failure of the problem list 
capability to function in accordance with Sec.  170.315(a)(6) was 
reasonably within the control of the developer, who should have 
anticipated the risk during the course of normal software development. 
Any additional read/write/display functionality may initially contain 
code errors, and all functions of certified health IT should be 
subjected to adequate testing. The developer could have reasonably 
taken actions to avoid the risk by employing an adequate software 
regression testing methodology.
    Based on the surveillance and analysis above, the ONC-ACB finds a 
non-conformity to Sec.  170.315(a)(6) and requires the developer to 
take corrective action, pursuant to Sec.  170.556(d), including by 
submitting a CAP in accordance with Sec. Sec.  170.556(d)(1)-(4) that 
addresses how the developer will resolve the identified non-conformity 
and related deficiencies across all of the developer's customers and 
users. ONC, in coordination with the ONC-ACB, concurs with the ONC-
ACB's finding of non-conformity and, at this time, forbears from taking 
any action against the developer because the non-conformity involves a 
straightforward violation of a certification criterion, which is well 
within the scope of the

[[Page 72425]]

ONC-ACB's responsibilities and does not appear to exceed the ONC-ACB's 
resources. ONC continues to closely monitor the situation and 
coordinate with the ONC-ACB. If at any time ONC were to believe that 
the ONC-ACB could not effectively administer the necessary corrective 
action or that ONC's direct intervention were necessary to more quickly 
and effectively mitigate the risk to public health or safety, ONC could 
immediately issue a notice of non-conformity and notice of suspension, 
as described in section II.A.1.c of this preamble.
Scenario 2
    The ONC-ACB's in-the-field surveillance reveals that the missing 
diagnosis was due to a system workflow implementation that the 
healthcare organization had customized. Contrary to the developer's 
recommendations, the healthcare organization had removed the problem 
list from the ``quick visit'' EHR workflow that is presented to 
ambulatory PCPs. This resulted in the PCP not being able to quickly and 
easily update the problem list properly, resulting in incomplete 
problem lists.
    In contrast to scenario 1, the ONC-ACB finds that there is no non-
conformity because these factors are beyond the developer's ability to 
reasonably influence or control. ONC concurs with the ONC-ACB's 
determination and ceases its direct review of the certified Health IT 
Module(s).
Scenario 3
    Based on its in-the-field surveillance, the ONC-ACB finds that the 
problem list capability is functioning in accordance with Sec.  
170.315(a)(6). Specifically, the ONC-ACB concludes that the issue is 
not the result of any technical or functional deficiencies with the 
problem list capability but rather the manner in which the problem 
list's user interface has been designed, which is unintuitive and 
appears to have contributed to problems being recorded incorrectly or 
not at all. The ONC-ACB shares its findings with ONC and states that 
these usability issues are beyond the scope of the ONC-ACB's expertise 
and its responsibilities under the Program because a complete 
assessment of these issues would appear to require an assessment of the 
developer's software development processes in light of current software 
usability and human factors best practices.
    ONC agrees that these issues are beyond the scope of the ONC-ACB's 
expertise and responsibilities under the Program. However, the issues 
are not beyond the scope of the Program. ONC concludes that the problem 
list capability was designed in a way that does not adhere to commonly 
accepted usability guidelines. In this case, ONC finds that in order to 
add a diagnosis to the problem list, a user is forced to navigate 
through an excessive series of windows, confirmation dialogues, and an 
inordinate amount of clicks to properly select the correct diagnosis. 
This in turn results in incomplete problem lists due to clinicians' 
difficulty navigating the overly complex workflow, inability to 
complete the laborious series of steps due to time constraints, or a 
combination of both factors.
    On the basis of these findings, ONC concludes that the certified 
health IT does not conform to the requirements of the Program. As 
discussed in section II.A.1.a.(1) of this preamble, certified health IT 
must be designed and made available to users in ways that allow 
certified capabilities to be used in an accurate and reliable manner, 
including in a manner that does not cause or contribute to serious 
risks to public health or safety. Where certified capabilities do not 
perform in such a manner due to factors that the developer could have 
reasonably influenced or controlled, the certified capabilities do not 
conform to the requirements of the Program. Here, the developer could 
have reasonably anticipated the risk through an understanding of 
software usability and human factors best practices, and the developer 
could have reasonably taken actions to avoid the risk, such as by 
ensuring adequate usability testing prior to software release. ONC 
would follow the processes discussed in section II.A.1.c of this 
preamble to notify the developer of the non-conformity and to work with 
the developer to expeditiously and comprehensively correct the non-
conformity and prevent similar safety risks from recurring. This might 
include, for example, instituting corrective actions to assist the 
developer in improving its user-centered design and other quality 
assurance processes.
    The example and scenarios above illustrate our intent that ONC's 
direct review complement and provide a ``backstop'' to the surveillance 
and other activities of ONC-ACBs so that suspected non-conformities 
requiring attention do not go unaddressed. To this end, ONC may consult 
with the ONC-AA, ONC-ACB(s), and other persons or entities, as 
appropriate, when determining whether to exercise direct review and in 
conducting such review. ONC may also share relevant information with 
the ONC-AA, ONC-ACB(s), and other relevant persons and entities as 
appropriate to assist ONC-ACB surveillance and other activities to 
address issues with certified health IT, to the extent that the sharing 
of such information is permitted by law. We believe that such 
communication will help ONC-ACBs as well as ONC accurately and 
effectively assess certain issues with certified health IT products. We 
continue to maintain that reviews by ONC-ACBs and ONC will be 
complementary and will support comprehensive and consistent review of 
certified health IT.
    Comments. Multiple commenters stated that ONC should not review 
certified health IT on the basis that a potential non-conformity raises 
novel or complex interpretations or applications of certification 
criteria (see proposed Sec.  170.580(a)(1)(iv)(D)) or could lead to 
inconsistent application of certification requirements in the absence 
of direct review (see proposed Sec.  170.580(a)(1)(v)). The commenters 
stated that if certification criteria pose issues that are novel, 
complex, or likely to lead to inconsistent application, these issues 
should be addressed during the testing and certification process, not 
by reviewing certified health IT after it has been certified.
    Response. Commenters may have misunderstood the purpose of these 
proposed factors and the situations in which they would be relevant to 
determining whether ONC should initiate direct review. In the 2015 
Edition final rule, we explained that to comply with applicable 
certification criteria, developers must not only demonstrate required 
capabilities in a controlled testing environment but must also make 
those capabilities available in ways that enable them to be implemented 
and used in production environments for their intended purposes (80 FR 
62711). As ONC-ACBs increase their surveillance of the performance of 
certified health IT in production environments, we anticipate that ONC-
ACBs may be presented with performance and functionality that might 
require the analysis of unfamiliar and difficult problems or 
deficiencies in certified health IT that require significant resources 
and expertise to properly investigate and assess under existing 
certification criteria. In some instances, the resources required to 
undertake this assessment may exceed the resources available to the 
ONC-ACB.
    The factors proposed at Sec.  170.580(a)(1)(iv)(D) and (a)(1)(v) 
were not intended to suggest, as some commenters seem to have 
misunderstood, that ONC could use

[[Page 72426]]

direct review to engage in novel interpretations of certification 
criteria. Rather, these factors were intended to cover situations, such 
as those described above, that could exceed an ONC-ACB's resources or 
expertise. To avoid any confusion, we have removed these factors from 
the final rule's regulation text on the basis that they are duplicative 
of ONC's consideration of whether an ONC-ACB has sufficient ``resources 
or expertise'' to evaluate a suspected non-conformity.
    Comments. A few commenters, including one ONC-ACB, suggested that 
ONC-ACBs are in the best position to know their own capabilities and as 
such ONC should not initiate direct review unless invited by an ONC-
ACB. One commenter suggested that ONC should be ``on call'' to assist 
ONC-ACBs to respond to suspected non-conformities that exceed the ONC-
ACBs capacity or expertise.
    Response. We thank commenters for their comments. In response to 
commenter concerns, we have adapted the final rule to provide ONC with 
an opportunity to consult with ONC-ACBs, as well as the ONC-AA and any 
other persons or entities, as ONC deems appropriate. In order for ONC 
to exercise direct review under Sec.  170.580(a)(2)(ii)(C), ONC must 
necessarily make a judgment about the resources and expertise of an 
ONC-ACB. ONC would only very rarely be in a position to make such a 
judgment without first consulting with the relevant ONC-ACB. However, 
because ONC is the Program owner and administrator, it would be 
inappropriate if an ONC-ACB were able to prevent ONC from initiating 
direct review if ONC has formed a reasonable belief that the ONC-ACB 
lacks the resources or expertise to investigate and address the 
suspected non-conformity at issue.
    Comments. Commenters urged us to clarify the types of information 
that ONC would rely on in deciding whether to initiate direct review, 
including when ONC would deem information ``reliable and actionable'' 
so as to warrant further inquiry into certified health IT's conformity 
to Program requirements (see 81 FR 11062).
    Response. In the 2015 Edition final rule, we provided guidance on 
the circumstances that would trigger an ONC-ACB's duty to initiate 
reactive surveillance (80 FR 62712). We said that in determining 
whether to initiate reactive surveillance, an ONC-ACB must consider and 
weigh the volume, substance, and credibility of complaints and other 
information received against the type and extent of the alleged non-
conformity, in light of the ONC-ACB's expertise and experience with the 
particular capabilities, health IT, and certification requirements at 
issue. As an example, we supposed that where an ONC-ACB receives a 
number of anonymous complaints alleging general dissatisfaction with a 
particular certified health IT, the ONC-ACB would not be required to 
initiate surveillance (though it would not be precluded from doing so). 
In contrast, upon receiving several complaints alleging specific non-
conformities, the ONC-ACB must initiate surveillance of the certified 
health IT unless a reasonable person in the ONC-ACB's position would 
doubt the credibility or accuracy of the complaints. By way of example, 
we explained that a reasonable basis for doubt might exist if the ONC-
ACB had recently responded to the very same issue and determined 
through in-the-field surveillance of the certified health IT at several 
different locations that the reported problem was due to a ``bug'' 
arising from an unsupported use of the certified health IT that the 
developer had specifically cautioned users about in advance.
    We anticipate applying these same principles in determining whether 
information about a potential non-conformity is sufficiently reliable 
and actionable to warrant ONC's direct review. We note, however, that 
in contrast to an ONC-ACB's affirmative duty to initiate surveillance, 
ONC is not required to initiate direct review. As such, ONC may require 
additional information before initiating review or may choose not to 
exercise review for any reason.
    Comments. Commenters made a range of suggestions about criteria 
that ONC could adopt, or indicia ONC could use, to determine the 
veracity or credibility of information received by ONC when making a 
determination on whether or not to commence direct review. A number of 
commenters suggested that ONC should not initiate direct review of an 
alleged non-conformity unless the complainant has first notified the 
developer and given the developer an opportunity to rectify the 
deficiency.
    Response. We thank commenters for their constructive suggestions. 
Because most issues that are the subject of direct review will concern 
risks to public health or safety, we anticipate that it will be very 
rare for information about such risks to be reported to ONC without 
first being brought to the developer's attention. However, we have 
determined that it would not be appropriate for ONC to be inhibited 
from initiating direct review on the basis that a health IT user had 
not first notified the health IT developer of the issue and provided 
the developer with an opportunity to rectify the deficiency. Consistent 
with a number of comments received from health IT developers, we note 
that a large number of health IT users do not have a direct business 
relationship with the developer of the health IT product they use. This 
is because many small healthcare practices receive their health IT via 
a sublicensing arrangement entered into with a large health care 
network. Similarly, other health IT stakeholders, such as health 
information exchanges, are positioned to identify deficiencies in 
certified health IT products they interact with but would not 
necessarily have a recognized process through which to raise issues or 
grievances with the developer concerned. Because ONC will weigh the 
volume, substance, and credibility of any information received, in 
light of all relevant circumstances, we do not believe it is necessary 
or appropriate to exclude from consideration any particular types or 
sources of information or to decide in advance what if any weight 
should be assigned to them.
    Comments. One commenter also suggested that ONC would need to 
receive a threshold number of complaints by multiple distinct users in 
respect to the same certified health IT version number before the 
information in ONC's possession was actionable.
    Response. ONC respectfully disagrees that there is a threshold 
number of complaints that would apply in all circumstances to ensure 
that direct review was triggered in only appropriate cases. Indeed, we 
can envision public health or safety risks for which a single complaint 
supported by detailed information and/or evidence would be sufficiently 
reliable and actionable to trigger ONC's exercise of discretion to 
initiate direct review.
    Comments. A commenter suggested that a provider's timeliness in 
implementing all applicable and available releases and ``hot fixes'' 
for the certified health IT should be taken into consideration by ONC 
when assessing the veracity and credibility of information ONC has 
received.
    Response. We thank this commenter for their comment. If a health IT 
developer issued customers with a new release, patch, or ``hot fix'' to 
address a deficiency in the developer's certified health IT, but their 
recommendation to implement the update within a specified period is 
ignored, ONC may determine that the deficiency at issue was caused by 
factors removed from the control or responsibility of the developer 
(see discussion above in section II.A.1.a.(1) of this preamble).

[[Page 72427]]

However, ONC may determine that it may nevertheless initiate review of 
the affected certified health IT in order to make a proper 
determination of the cause of any suspected non-conformity and to make 
an assessment of whether the remedial action implemented by the 
developer is appropriate in the circumstances.
b. ONC-ACB's Role
    We proposed that ONC's review of certified health IT would be 
independent of, and may be in addition to, any review conducted by an 
ONC-ACB, even if ONC and the ONC-ACB were to review the same certified 
health IT, and even if the reviews occurred concurrently. To ensure 
consistency and clear accountability, we also proposed that ONC, if it 
deems necessary, could assert exclusive review of certified health IT 
as to any matters under review by ONC and any other matters that are so 
intrinsically linked that divergent determinations between ONC and an 
ONC-ACB would be inconsistent with the effective administration or 
oversight of the Program. Finally, we proposed that in such instances, 
ONC's determinations on these matters would take precedent and a health 
IT developer would be subject to the proposed ONC direct review 
provisions in the Proposed Rule, including having the opportunity to 
appeal an ONC determination, as applicable.
    We clarified in the Proposed Rule that, in matters where ONC does 
not assert direct and/or exclusive review or ceases its direct and/or 
exclusive review, an ONC-ACB would be permitted to issue its own 
determination on the matter. We further clarified that any resulting 
determination to suspend or terminate a certification issued to a 
Complete EHR or Health IT Module by an ONC-ACB would not be subject to 
ONC review under the provisions proposed in the Proposed Rule. We also 
stated that in those instances, there would be no opportunity to appeal 
the ONC-ACB's determination(s) under the provisions proposed in the 
Proposed Rule. We emphasized that ONC-ACBs are accredited, authorized, 
and entrusted to issue and administer certifications under the Program 
consistent with adopted certification criteria and other specified 
Program requirements. Therefore, they have the necessary expertise and 
capacity to effectively administer these specific requirements.
    We proposed in the Proposed Rule that ONC could initiate review of 
certified health IT on its own initiative based on information from an 
ONC-ACB, which could include a specific request from the ONC-ACB to 
conduct a review. In exercising its review of certified health IT, we 
proposed that ONC would be entitled to any information it deems 
relevant to its review that is available to the ONC-ACB responsible for 
administering the health IT's certification. We proposed that ONC could 
contract with an ONC-ACB to conduct facets of an ONC direct review 
within an ONC-ACB's scope of expertise, such as surveillance of 
certified capabilities.
    We proposed that ONC could also share information with an ONC-ACB 
that may lead the ONC-ACB, at its discretion and consistent with its 
accreditation, to conduct in-the-field surveillance of the certified 
health IT at particular locations. We further proposed that ONC could, 
at any time, end all or any part of its review of certified health IT 
under the processes proposed and refer the applicable part of the 
review to the relevant ONC-ACB(s), if doing so would be in the best 
interests of efficiency or the effective administration and oversight 
of the Program. We stated that the ONC-ACB would be under no obligation 
to proceed further, but would have the discretion to review and 
evaluate the information provided and proceed in a manner it deems 
appropriate. As noted above, this may include processes and 
determinations (e.g., suspension or termination) not governed by the 
proposed review and appeal processes.
    We requested comment on our proposed approach and the role of an 
ONC-ACB.
    Comments. Multiple commenters supported our proposals regarding the 
ONC-ACB's role and responsibilities for reviewing certifications of 
Complete EHRs and Health IT Modules. Commenters agreed that there are 
situations when ONC should have authority to independently review or 
assist an ONC-ACB in reviewing certified health IT. Other commenters 
questioned our rationale for allowing ONC direct review to be 
independent of, and in addition to, ONC-ACB review. These commenters 
contended that ONC-ACBs are qualified to review all non-conformities. A 
few commenters requested clarification regarding the scope of review 
responsibilities for ONC and ONC-ACBs, respectively.
    Response. We have finalized our proposals regarding the ONC-ACB's 
role and responsibilities in relation to ONC direct review as proposed 
with the following clarifications and a revision as discussed in the 
response below. As stated above, reviews by ONC-ACBs and ONC would be 
complementary, but independent as well. As discussed in detail under 
section II.A.1.a, we believe that ONC should exercise direct review 
over matters outside of an ONC-ACB's resources and expertise as well as 
matters that pose a serious risk to public health or safety.
    We clarify that ONC-ACB review after a certification is issued is 
limited to surveillance. This clarification is consistent with the 
requirements of ISO/IEC 17065 \9\ and our discussion of ONC-ACB 
surveillance in the 2015 Edition final rule (see 80 FR 62605). Thus, we 
refer to this ``review'' by the ONC-ACB as surveillance in this final 
rule.
---------------------------------------------------------------------------

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

    Comments. Commenters, including an ONC-ACB, expressed agreement 
with our proposal that as the scheme owner and regulator, ONC's 
determinations should take precedent. Other commenters were concerned 
that there could be conflicts between ONC and ONC-ACB determinations 
and questioned why ONC's determination should take precedent. 
Commenters also suggested that the proposed approach to review could 
cause mixed messaging by ONC and ONC-ACBs and duplication of efforts by 
health IT developers (e.g., document production and interviews). 
Commenters encouraged ONC and ONC-ACBs to share relevant information 
and coordinate review in order to avoid duplication.
    Response. We believe the final provisions will facilitate sound 
determinations by the appropriate body and help avoid duplicative 
review. Under the final provisions, ONC may assert exclusive review of 
certified health IT as to any matters under its review and any similar 
matters under surveillance by an ONC-ACB. In determining if matters are 
similar, ONC will, as proposed, consider whether the matters are so 
intrinsically linked that divergent determinations between ONC and an 
ONC-ACB would be inconsistent with the effective administration or 
oversight of the Program.
    A determination by ONC on matters under its review will be 
controlling and supersede any determination by an ONC-ACB. We believe 
these steps will help avoid conflicts in determinations and permit ONC, 
as the administrator of the Program, to reach appropriate outcomes 
consistent with Program requirements on matters within its review.
    Under the final provision in Sec.  170.580(a)(3)(v), ONC may end 
all or any part of its review of certified health IT and refer the 
applicable part of the review to the relevant ONC-ACB(s) if

[[Page 72428]]

ONC determines that doing so would serve the effective administration 
or oversight of the Program. The ONC-ACB would be under no obligation 
to proceed further, but would have the discretion to review and 
evaluate the information provided and proceed in a manner it deems 
appropriate.
    We are finalizing this provision by revising it for clarity. We had 
proposed that ONC may end its review based on the best interests of 
efficiency or the administration and oversight of the Program (81 FR 
11083). We have revised that proposal to be that ONC may determine to 
end its review if that would serve the effective administration or 
oversight of the Program. We believe the revision eliminates 
duplicative bases for ending review and remains consistent with the 
intent of the proposed provision. In addition, for further clarity, we 
have added that ONC may cease its review at any time. We indicated in 
the Proposed Rule that we could cease our review, but we did not make 
clear that it could be at any time during the direct review process 
(see also section II.A.1.a.(2) of this preamble). We further note that 
in the discussion of the direct review processes, we provide clarity 
regarding the steps ONC would take throughout direct review, including 
after receiving health IT developer responses to notices.
    We appreciate commenters' suggestion that ONC increase coordination 
and sharing of information with ONC-ACBs. ONC and ONC-ACBs regularly 
communicate and we anticipate this communication would continue when 
ONC initiates direct review of certified health IT. As noted by 
commenters, such communication will benefit the Program and minimize 
the possibility of mixed messaging or duplicative review. In 
furtherance of collaboration between ONC and ONC-ACBs, we have 
finalized the proposed requirement that ONC-ACBs must provide ONC with 
any available information that ONC deems relevant to its review of 
certified health IT. We have also included ONC-ATLs in this information 
sharing provision as we have finalized the ONC-ATL processes in this 
final rule. We note that we could share information with an ONC-ACB 
that may lead the ONC-ACB, at its discretion and consistent with its 
accreditation, to conduct in-the-field surveillance of the health IT at 
a particular location.
    Comment. A commenter expressed concern that the Proposed Rule did 
not propose appeal rights for ONC-ACB determinations. The commenter 
explained that, if there are two different enforcement bodies (ONC and 
ONC-ACBs) that may make determinations, there should be equal rights 
for a health IT developer to appeal those determinations.
    Response. Health IT developers that have their certifications 
terminated by an ONC-ACB can appeal that determination to the ONC-ACB, 
similar to how an ONC termination can be appealed to the National 
Coordinator under the processes finalized in this final rule. The ONC-
ACB will process the appeal in accordance with the requirements of ISO/
IEC 17065 and the ONC-ACB's procedures. Appeal procedures may vary 
among ONC-ACBs, so health IT developers should familiarize themselves 
with the appeal procedures provided by their ONC-ACB(s). If the health 
IT developer is not satisfied with the result of the appeal, the health 
IT developer can submit the matter to the Approved Accreditor for 
certification under the Program, American National Standards Institute 
(ANSI), for consideration.
    In consideration of the ONC-ACB appeals process outlined above and 
our belief that ONC-ACBs have the necessary expertise and capacity to 
effectively administer certifications under the Program consistent with 
the certification criteria and other specified Program requirements, we 
have not established a process for health IT developers to appeal ONC-
ACB determinations to ONC.
c. Review Processes
    We stated in the Proposed Rule that ONC could become aware of 
information from the general public, interested stakeholders, ONC-ACBs, 
or by any other means that indicates that certified health IT may not 
conform to the requirements of its certification or is, for example, 
leading to medical errors or other outcomes that do not align with the 
National Coordinator's responsibilities under section 3001 of the PHSA. 
We proposed that, if ONC deems the information to be reliable and 
actionable, it would conduct further inquiry into the certified health 
IT. We further stated that ONC could also initiate an independent 
inquiry into the certified health IT that could be conducted by ONC or 
a third party(ies) on behalf of ONC (e.g., contractors or inspection 
bodies under the certification scheme). If information reveals that 
there is a potential non-conformity (through substantiation or omission 
of information to the contrary) or confirms a non-conformity in the 
certified health IT, we stated that ONC would proceed to notify the 
health IT developer of its findings, as applicable, and work with the 
health IT developer to address the matter.
    We proposed that correspondence and communication with ONC and/or 
the National Coordinator for all processes proposed under this section 
(section II.A.1.c) of the preamble shall be conducted by email, unless 
otherwise necessary or specified. We proposed to modify Sec.  170.505 
accordingly.
    Comments. Commenters supported the ONC direct review processes as 
proposed. A commenter emphasized that the review processes would 
promote greater accountability of health IT developers for the 
performance, reliability, and safety of certified health IT. A few 
commenters, however, expressed concern about frivolous complaints. 
These commenters and other commenters requested clarification regarding 
the type of information that would warrant ONC direct review and 
requested that ONC explain what constitutes ``reliable and actionable'' 
information. A commenter requested that ONC establish clear 
requirements for what information must be presented as part of a 
complaint or allegation of non-conformity and who would be eligible to 
make such a complaint.
    Response. We have finalized the process and criteria for 
identifying non-conformities that would warrant ONC direct review as 
proposed with clarifications in response to comments. We clarify that 
in order to determine the reliability of the information, ONC will 
consider and weigh the volume, substance, and credibility of complaints 
and other information received against the type and extent of the 
alleged non-conformity. We note that this reliability standard aligns 
with the ONC-ACB standard for initiating surveillance in the 2015 
Edition final rule (80 FR 62713). We also clarify that if information 
ONC receives does not provide adequate detail, specificity, or clarity 
regarding the suspected non-conformity, ONC will, as necessary, contact 
the party(ies) who submitted the complaint to gather additional 
information and make a decision as to whether the complaint is 
actionable. To avoid confusion, we have removed ``reliable and 
actionable'' from the relevant provisions of Sec.  170.580. We believe 
the above clarification is responsive to commenters and clarifies the 
type of information that would give ONC a ``reasonable belief'' that 
the certified health IT may not or does not conform to the requirements 
of the Program.
    In section II.A.1.a.(3) of this final rule, we describe factors ONC 
should consider when deciding whether to

[[Page 72429]]

exercise direct review. These factors afford ONC discretion to evaluate 
information on a case-by-case basis. Considering the wide range of 
information ONC may receive regarding non-conformities in certified 
health IT, and that ONC has specialized expertise to evaluate the 
reliability and accuracy of such information, it is essential that ONC 
have discretion in making direct review decisions.
    Comments. Many commenters suggested that correspondence throughout 
the review processes should be issued by mail.
    Response. We have finalized the requirements for correspondence 
with additional regulation revisions and processes. Section 170.505 
states that correspondence and communication with ONC or the National 
Coordinator shall be conducted by email, unless otherwise necessary or 
specified. We note that email correspondence and communication of 
protected health information by HIPAA covered entities and business 
associates must employ safeguards in compliance with the HIPAA Rules.
    Section 170.505 provides the flexibility to use means other than 
email as ``necessary or specified.'' As stated in the Proposed Rule, we 
intend to send notice of suspension and termination via certified mail. 
We also intend to send notices of potential non-conformity, notices of 
non-conformity, and notices of proposed termination via certified mail. 
We have, therefore, revised Sec.  170.505 to clearly state the 
potential use of certified mail in addition to regular and express 
mail. Section 170.505 specifies that the official date of receipt of 
any form of mail will be the date of the delivery confirmation. We have 
revised the language of this provision to clarify that it applies to 
all parties and that delivery confirmation is to the address on record. 
The address on record is the most recently provided address to ONC or 
an ONC-ACB, as applicable. We believe this will clarify the process in 
situations where an entity, such as a health IT developer, moves its 
place of business or goes out of business without notifying ONC or the 
relevant ONC-ACB.
(1) Notice of Potential Non-Conformity or Non-Conformity
    We proposed that if information suggests to ONC that certified 
health IT is not performing consistent with Program requirements and a 
non-conformity exists with the certified health IT, ONC would send a 
notice of potential non-conformity or non-conformity to the health IT 
developer. We explained in the Proposed Rule that the notice would 
specify ONC's reasons for the notification, explain ONC's findings, and 
request that the health IT developer respond to the potential/alleged 
non-conformity (and potentially a corrective action request) or be 
subject to further action (e.g., corrective action, suspension, and/or 
the termination of the certification in question, as appropriate).
    We proposed that ONC should have the ability to access and share 
within HHS, with other federal agencies, and with appropriate entities, 
a health IT developer's relevant records related to the development, 
testing, certification, implementation, maintenance, and use of its 
product, as well as any complaint records related to the product. We 
stated that this proposal would ensure a complete and comprehensive 
review of the certified health IT product. We noted that much of this 
information already must be disclosed as required by the Program and 
described in the 2015 Edition final rule. We proposed, however, that 
ONC be granted access to, and be able to share within HHS, with other 
federal agencies, and with appropriate entities (e.g., a contractor or 
ONC-ACB) any additional records not already disclosed that may be 
relevant and helpful in ONC's fact-finding and review. If we determined 
that the health IT developer was not cooperative with the fact-finding 
process, we proposed that we would have the ability to suspend or 
terminate the certification of any encompassed Complete EHR or Health 
IT Module of the certified health IT as outlined later in sections 
II.A.1.c.(3) and (4) of this final rule.
    We stated in the Proposed Rule that we understood that health IT 
developers may have concerns regarding disclosure of proprietary, trade 
secret, competitively sensitive, or other confidential information. To 
address these concerns, we further stated that ONC would implement 
appropriate safeguards to ensure, to the extent permissible with 
federal law, that any proprietary business information or trade secrets 
that ONC might encounter by accessing the health IT developer's records 
would be kept confidential by ONC.\10\ For instance, ONC would ensure 
that, if it obtains proprietary or trade secret information, that 
information would not be included in the CHPL. We noted, however, that 
the safeguards we would adopt would be prophylactic and would not 
create a substantive basis for a health IT developer to refuse to 
comply with the proposed requirements. Thus, a health IT developer 
would not be able to avoid providing ONC access to relevant records by 
asserting that such access would require it to disclose trade secrets 
or other proprietary or confidential information.
---------------------------------------------------------------------------

    \10\ The Freedom of Information Act, 18 U.S.C. 1905, and the 
Uniform Trade Secrets Act generally govern the disclosure and 
descriptions of these types of information.
---------------------------------------------------------------------------

    We proposed that unless otherwise specified in the notice, the 
health IT developer would be required to respond within 30 days of 
receipt of the notice and, if necessary, submit a proposed CAP as 
outlined below in section II.A.1.c.(2) of this final rule. We proposed 
that ONC may require a health IT developer to respond and/or submit a 
proposed CAP in more or less time than 30 days based on factors such 
as, but not limited to: (1) The type of health IT and health IT 
certification in question; (2) the type of non-conformity to be 
corrected; (3) the time required to correct the potential non-
conformity or non-conformity; and (4) issues of public health and 
safety and other exigencies related to the National Coordinator 
carrying out his or her duties in accordance with sections 3001(b) and 
(c) of the PHSA. We proposed that ONC would have discretion in deciding 
the appropriate timeframe for a response and proposed CAP from the 
health IT developer.
    We proposed that if the health IT developer contends that the 
certified health IT in question conforms to Program requirements, the 
health IT developer must include in its response all appropriate 
documentation and explain in writing why the health IT is conforming.
    We requested comment on our proposed processes described above, 
including whether the timeframe for responding to a notice of potential 
non-conformity or non-conformity is reasonable and whether there are 
additional factors that we should consider.
    Comments. Many commenters supported the proposed processes for 
notices of potential non-conformity and non-conformity. Multiple 
commenters, however, requested discussion between ONC and the health IT 
developer, which could also include the ONC-ACB, regarding a complaint 
or surveillance issue prior to the issuance of a notice of potential 
non-conformity or non-conformity. Commenters stated that such 
discussion would help ensure the appropriateness of, and necessity for, 
the issuance of a notice of potential non-conformity or non-conformity. 
A commenter also recommended that ONC engage with end-users of 
certified health IT and establish a process in which end-

[[Page 72430]]

users can offer feedback on certified health IT to help alert ONC to 
potential and actual non-conformities.
    Many commenters requested that ONC clarify the circumstances that 
would cause ONC to send a notice of potential non-conformity or non-
conformity to a health IT developer. These commenters also expressed 
concerns that, as proposed, ONC could issue a notice of non-conformity 
without first issuing a notice of potential non-conformity. Commenters 
opined that a notice of non-conformity should not be the first instance 
of notification to a health IT developer in the ONC direct review 
process. A commenter recommended that ONC provide a model notification 
to industry and stakeholders of the content of a notice of potential 
non-conformity and non-conformity.
    Response. We thank commenters for their thoughtful comments on this 
aspect of the proposed direct review processes. We have finalized the 
proposed processes for notices of potential non-conformity and non-
conformity with the following clarifications and revisions discussed 
below and finalized in Sec.  170.580(b)(1) through (3).
    We agree with commenters regarding the benefits of open discussion 
between ONC, health IT developers, and as applicable, ONC-ACBs, during 
the direct review process. While we encourage discussions between ONC 
and health IT developers prior to the issuance of a notice of potential 
non-conformity or non-conformity, we cannot guarantee that such 
discussions will always precede a notice because ONC may need to take 
immediate steps to expedite direct review and corrective action or have 
other reasons for not first discussing the matter. We emphasize that 
our first and foremost goal is to work with health IT developers to 
address any non-conformities in certified health IT in a timely manner 
and across all customers, and we encourage discussion as early as 
possible in the process to help achieve this goal.
    We also appreciate the suggestion that ONC engage with end-users 
and we encourage end-users to contact us with their concerns. 
Specifically, end-users can submit a complaint through the ONC-
established complaint process at: https://www.healthit.gov/healthitcomplaints.
    While we do not believe we could develop a model notice that would 
be of value to health IT developers because each instance of potential 
non-conformity or non-conformity will likely be unique, we do offer the 
following clarifications. ONC may issue a notice of non-conformity 
without first issuing a notice of potential non-conformity if supported 
by the circumstances and information available to ONC. ONC must be able 
to issue a notice of non-conformity in situations where information 
establishes and ONC determines that there is an actual non-conformity 
in order to put the health IT developer on notice and begin the 
corrective action process without delay. In comparison, ONC may issue a 
notice of potential non-conformity when it has a reasonable belief, 
based on information at its disposal, that there may be a non-
conformity with the certified health IT. We further note that a notice 
of potential non-conformity and notice of non-conformity are separate 
and distinct notices, and ONC can issue them concurrently, as 
necessary. In such situations, each notice will include the appropriate 
timeframe for the health IT developer to submit a response. As stated 
above, we will send notices of potential non-conformity and non-
conformity by certified mail and the official date of receipt will be 
the date of the delivery confirmation to the address on record 
consistent with Sec.  170.505.
Developer Response
    We have restructured and revised the requirements for health IT 
developer responses to notices of potential non-conformity and non-
conformity (see Sec.  170.580(b)(1)(ii) and (b)(2)(ii)). These 
revisions are intended to clarify ONC's expectations regarding health 
IT developer responses and to emphasize that the proposed and finalized 
``Records Access'' provision (Sec.  170.580(b)(3)) is a separate 
requirement.
    Health IT developers must respond to a notice of potential non-
conformity by (1) cooperating with ONC and/or a third party acting on 
behalf of ONC, (2) providing ONC and/or a third party acting on behalf 
of ONC access to the certified health IT under review, and (3) 
providing ONC with a written explanation, within 30 days, unless 
adjusted by ONC, addressing the potential non-conformity, including all 
appropriate documentation.
    Health IT developers must respond to a notice of non-conformity in 
the same fashion as described for a notice of potential non-conformity 
above and, in addition, must submit a proposed CAP (see Sec.  
170.580(b)(2)(ii)(A)(4)). We note that we did not propose in the 
Proposed Rule that the health IT developer could respond to a notice of 
non-conformity through a written explanation addressing the non-
conformity in addition to submitting a proposed CAP. We have, however, 
finalized this new provision in the final rule to allow health IT 
developers to explain, agree with, or refute the notice of non-
conformity, which parallels a health IT developer's opportunity to 
respond to a notice of potential non-conformity. This opportunity to 
respond is in addition to submitting a proposed CAP and will not delay 
or prolong the CAP process. In addition, we note that ONC may still 
propose termination under Sec.  170.580(e), as necessary, despite a 
written explanation from the health IT developer that refutes the 
notice of non-conformity. We further note that a health IT developer 
may choose to contest the notice of potential non-conformity or not 
cooperate with ONC or a third party acting on behalf of ONC. However, 
we again emphasize that in such situations ONC may take action under 
the proposed termination provisions (see Sec.  170.580(e)).
    Comments. We received numerous comments on the proposed 30-day 
default response period for notice of potential non-conformity or non-
conformity. This includes the requirement, which is also stated in 
section II.A.1.c.(2) of this final rule below, that a health IT 
developer must submit a proposed CAP to ONC within 30 days of the date 
that ONC notifies the health IT developer of an actual non-conformity, 
unless ONC specifies a different timeframe. A few commenters supported 
our proposal and response timeframe. Many commenters suggested that the 
30-day default response period should be the minimum time period to 
respond to a notice. Other commenters stated that a 30-day default 
response period is too short, particularly when corrective action is 
required, because non-conformities may be complex and difficult to 
resolve. One commenter suggested that the 30-day default response 
period is too long. The commenter stated that, based on past experience 
working with numerous certified systems to address non-conformities, 30 
days is a long time for the problem to be addressed, much less to 
develop a plan to address the problem. Many commenters requested 
clarification about instances when the response period would be ``more 
or less'' time than 30 days, as proposed. Many commenters also 
suggested that the response period be measured in business days.
    Response. We have finalized this requirement as proposed for 
responding to both a notice of potential non-conformity and a notice of 
non-conformity with clarifications in response to comments. We maintain

[[Page 72431]]

that 30 days is an appropriate default response period that will afford 
health IT developers ample time to respond to a notice and ensure that 
health IT developers address non-conformities in a timely fashion. We 
provide clear guidance regarding the factors ONC will use to determine 
whether the health IT developer should submit a response and/or CAP in 
more or less time than 30 days (Sec.  170.580(b)(1)(ii)(B) and 
(b)(2)(ii)(B)). ONC must retain discretion to increase or decrease the 
30-day period when necessary due to the wide range and complexity of 
non-conformities. We emphasize that ONC will work with health IT 
developers to develop acceptable CAPs with reasonable timeframes for 
completion. We also clarify that health IT developers may request an 
extension for submittal of a CAP. In order to make this extension 
request, a health IT developer must submit a written statement to ONC 
that explains and justifies the request.
    For clarity, we previously adopted the definition of ``day or 
days'' in Sec.  170.102 to mean calendar day or calendar days 
(Temporary Certification Program final rule; 75 FR 36162 and 36203).
    We clarify, as noted above, that a health IT developer's response 
to a notice of potential non-conformity or non-conformity includes 
providing ONC, and/or a third party acting on behalf of ONC, with 
access to the certified health IT under review (Sec.  170.580(b)(1)(ii) 
and (b)(2)(ii)). We note that this is a clarification of the 
requirement in the Proposed Rule and does not introduce a new 
requirement for health IT developers (81 FR 11058). We proposed in the 
``Authority and Scope'' section of the Proposed Rule that this 
rulemaking was intended to address ONC's direct review of certified 
health IT and provide ONC with access to the certified health IT and 
relevant records (``records access'' proposal) to assist in determining 
whether a non-conformity exists and addressing a found non-conformity.
ONC Determination
    We have added and finalized provisions that specify how ONC would 
respond to a health IT developer's response to a notice of potential 
non-conformity and notice of non-conformity. These provisions provide 
further transparency and clarification of the review processes, 
particularly with regard to ONC actions. However, we emphasize that, as 
specified under the ``ONC-ACB's Role'' section of this final rule 
above, ONC may end its review at any time.
    We have finalized a provision that addresses ONC's options after 
receiving the health IT developer's written explanation in response to 
a notice of potential non-conformity. ONC will do one of the following 
(Sec.  170.580(b)(1)(iii)): (1) Issue a written determination ending 
its review (which, may also include a rescission of a suspension (see 
the ``suspension'' section of this final rule for further discussion)); 
(2) request additional information and continue its review in 
accordance with a new timeframe it establishes (see Sec.  
170.580(b)(1)(ii)(A)(3) and (b)(1)(ii)(B)); (3) substantiate a non-
conformity and issue a notice of non-conformity; or (4) issue a notice 
of proposed termination.
    We have also finalized a similar provision that addresses ONC's 
options after receiving the health IT developer's written response to a 
notice of non-conformity. ONC will either issue a written determination 
ending its review or continue with its review under the provisions of 
this section. The continuation of ONC's review would likely be to 
proceed through the CAP process as outlined in this final rule, but may 
instead be to issue a proposed termination or take other appropriate 
action under the provisions of this final rule.
    Comments. Many commenters expressed concern that the proposed 
records access requirement is too broad, extends beyond what is 
required for ONC-ACB surveillance, and could require health IT 
developers to produce large amounts of information. Commenters 
suggested that the proposed language should be more narrowly focused on 
records that directly bear on the specific certified capabilities 
affected by the non-conformity(ies) and materials relevant to the issue 
under review. Commenters were also concerned about protecting the 
confidentiality of health IT developer records. Commenters questioned 
the necessity of sharing records with other federal agencies and 
appropriate entities.
    A commenter noted that documents or records obtained by ONC during 
the course of direct review could contain protected health information 
(PHI), trade secrets, or other sensitive information without a 
sufficient basis or adequate assurances that this information would be 
protected from further disclosure.
    Response. We have finalized this requirement as proposed with the 
following clarifications. This approach to records access and sharing 
of records is necessary for ONC to conduct a comprehensive review of 
certified health IT, and will supplement ONC's access to the certified 
health IT under review. This approach supports the review of 
uncertified capabilities that interact with certified capabilities and 
will assist ONC in determining whether certified health IT conforms to 
applicable Program requirements. Further, the relevant records and 
federal departments, agencies, and offices will be determined on a 
case-by-case basis with consideration of the matter under review. We 
clarify that ``complaint records'' under the records access 
requirements include, but are not limited to, issue logs and help desk 
tickets.
    As stated and outlined in the Proposed Rule (81 FR 11063), we are 
committed to implementing appropriate safeguards to ensure that any 
proprietary business information or trade secrets that ONC might 
encounter would be kept confidential by ONC to the extent permissible 
by federal law. To that end, we strongly recommend that health IT 
developers clearly mark, as described in HHS Freedom of Information Act 
regulations at 45 CFR 5.65(c), any information they regard as trade 
secret or confidential commercial or financial information prior to 
disclosing the information to ONC.
    Regarding the disclosure of PHI to ONC, we refer to our previous 
guidance provided on this issue in consultation with the HHS Office for 
Civil Rights. Specifically, in the 2015 Edition Final Rule, we 
explained that a health care provider is permitted, without patient 
authorization, to disclose PHI to an ONC-ACB for purposes of the ONC-
ACB's authorized surveillance activities (80 FR 62716). Health care 
providers are permitted to make disclosures to a health oversight 
agency (as defined in 45 CFR 164.501) for oversight activities (as 
described in 45 CFR 164.512(d)) authorized by law, including activities 
to determine compliance with program standards, and ONC may delegate 
its authority to ONC-ACBs to perform surveillance of certified health 
IT under the Program.\11\ This disclosure of PHI to an ONC-ACB does not 
require a business associate agreement with the ONC-ACB since the ONC-
ACB is not performing a function on behalf of the covered entity. In 
the same way, a provider, health IT developer, or other person or 
entity is permitted to disclose PHI directly to ONC, without patient 
authorization and without a business associate agreement, for purposes 
of ONC's direct review of certified health IT or the performance of any 
other

[[Page 72432]]

oversight responsibilities of ONC to determine compliance under the 
Program.
---------------------------------------------------------------------------

    \11\ See: 45 CFR 164.512(d)(1)(iii); 80 FR 62716; and ONC 
Regulation FAQ #45 [12-13-045-1] available at http://www.healthit.gov/policy-researchers-implementers/45-question-12-13-045.
---------------------------------------------------------------------------

    We further clarify that, as we contemplated in the Proposed Rule, 
it may be necessary for ONC to engage additional resources and 
specialized expertise to timely and effectively respond to potential 
non-conformities or non-conformities (81 FR 11058), and that this may 
include engaging outside experts, consultants, or other persons or 
entities (consultants) for the purpose of assisting ONC in its direct 
review of certified health IT. In the same way that ONC authorizes ONC-
ACBs to conduct surveillance of certified health IT under the Program, 
ONC may authorize such consultants to perform fact-finding, analyses, 
and/or other functions that support ONC's direct review of the 
certified health IT; and pursuant to ONC's health oversight authority 
(as defined in 45 CFR 164.512(d)(1)(iii)), persons and entities are 
permitted to disclose PHI to such consultants for the purpose of 
carrying out these authorized activities, without patient authorization 
and without a business associate agreement.
    We note that subsequent disclosures of identifiable patient health 
information by ONC, or persons or entities acting on ONC's behalf, are 
limited to those expressly allowed by law--such as under the Privacy 
Act of 1974 and/or the Freedom of Information Act (FOIA), as 
applicable.
(2) Corrective Action
    We proposed in the Proposed Rule that if ONC finds that certified 
health IT does not conform to Program requirements, ONC would take 
appropriate action with the health IT developer to remedy the non-
conformity as outlined below.
    We proposed that ONC would require a health IT developer to submit 
a proposed CAP to ONC. The CAP would provide a means to correct the 
identified non-conformities across all the health IT developer's 
customer base.
    We proposed, as described above in section II.A.1.c.(1) of this 
preamble and in the Proposed Rule, that a health IT developer must 
submit a proposed CAP to ONC within 30 days of the date that ONC 
notifies the health IT developer of the non-conformity, unless ONC 
specifies a different timeframe. We explained in the Proposed Rule that 
this approach aligns with and does not change the corrective action 
process specified in Sec.  170.556(d) and used by ONC-ACBs. The primary 
difference between this approach and the approach specified Sec.  
170.556(d) is that in Sec.  170.556(d) the health IT developer must 
submit a CAP to an ONC-ACB within 30 days of being notified of the 
potential non-conformity. We proposed in the Proposed Rule that this 
30-day period be the default for receiving a response/CAP, but that ONC 
may alter the response period based on non-conformities that may pose a 
risk to public health or safety, or other exigencies related to the 
National Coordinator carrying out his or her duties in accordance with 
sections 3001(b) and (c) of the PHSA (81 FR 11063).
    We proposed in the Proposed Rule that ONC would provide direction 
to the health IT developer as to the required elements of the CAP and 
would work with the health IT developer to develop an acceptable CAP. 
We proposed that a CAP must include, at a minimum, for each non-
conformity:
     A description of the identified non-conformity;
     An assessment of the nature, severity, and extent of the 
non-conformity, including how widespread they may be across all of the 
health IT developer's customers of the certified health IT;
     How the health IT developer will address the identified 
non-conformity, both at the locations where the non-conformity was 
identified and for all other potentially affected customers;
     A detailed description of how the health IT developer will 
assess the scope and impact of the non-conformity(ies), including 
identifying all potentially affected customers, how the health IT 
developer will promptly ensure that all potentially affected customers 
are notified of the non-conformity and plan for resolution, how and 
when the health IT developer will resolve issues for individual 
affected customers, and how the health IT developer will ensure that 
all issues are in fact resolved; and
     The timeframe under which corrective action will be 
completed.
    We proposed that when ONC receives a proposed CAP (or a revised 
proposed CAP) it shall either approve the proposed CAP or, if the plan 
does not adequately address all required elements, instruct the health 
IT developer to submit a revised proposed CAP. In addition to the 
required elements above, we proposed that a health IT developer would 
be required to submit an attestation to ONC. We explained that the 
attestation would follow the form and format specified by the CAP and 
would be a binding official statement by the health IT developer that 
it has fulfilled all of its obligations under the CAP, including curing 
the identified non-conformities and related deficiencies and taking all 
reasonable steps to prevent their recurrence.
    We stated in the Proposed Rule that based on this attestation and 
all other relevant information, ONC would determine whether the non-
conformity(ies) had been cured and, if so, would lift the CAP. However, 
we proposed that if it were later discovered that the health IT 
developer had not acted in the manner attested, ONC could reinstitute 
the CAP or proceed to suspend or terminate the certification of any 
encompassed Complete EHR or Health IT Module of the certified health 
IT.
    We proposed that ONC would report the CAP and related data to the 
publicly accessible CHPL. The purpose of this reporting requirement, as 
it is for ONC-ACBs under current regulations, would be to ensure that 
health IT users, implementers, and purchasers are alerted to potential 
conformity issues in a timely and effective manner. This approach is 
consistent with the public health and safety, program integrity, and 
transparency objectives described previously in the Proposed Rule (81 
FR 11064) and in the 2015 Edition final rule (80 FR 62725-26).
    We requested comment on our proposed CAP processes as described 
above.
    Comments. Many commenters stated that ONC should use the same 
construct for CAPs as was established in Sec.  170.566(d) for non-
conformities found by ONC-ACBs. A few commenters noted that the 
proposed corrective action requirements and the ``ONC-ACB CAP'' 
requirements are consistent concerning the authority of ONC and ONC-
ACBs to provide direction on required elements of the CAP, but are 
inconsistent with regard to the proposed ability of ONC to 
``prescribe'' such corrective action as may be appropriate to fully 
address the identified non-conformity(ies). Some commenters suggested 
that ONC clarify this language so that ONC is able to ``prescribe'' the 
elements required of the CAP, but not health IT developer actions.
    Response. We thank commenters for their thoughtful comments on this 
aspect of the proposed corrective action process. In consideration of 
these comments, we have finalized the corrective action requirement and 
CAP elements at Sec.  170.580(c)(2), subject to the following changes 
and clarification discussed below. As discussed above, our approach to 
corrective action aligns with the corrective action process specified 
in Sec.  170.556(d) for ONC-ACB actions. Section 170.556(d) does not, 
however, ``prescribe'' corrective action. Therefore, to further align 
with

[[Page 72433]]

Sec.  170.556(d) and in response to comments, we have removed 
``prescribe'' from the regulation text. We emphasize that this change 
is only a clarification of the proposed language and does not represent 
a narrower policy than proposed.
    Our goal with CAPs under ONC direct review and ONC-ACB surveillance 
is to remedy the non-conformity(ies) as quickly and effectively as 
possible. Therefore, we will include such required elements as part of 
a CAP as we determine is necessary to comprehensively and expeditiously 
resolve the identified non-conformity(ies). We will, however, work with 
health IT developers to determine the most appropriate elements for 
CAPs and strive to assist in the creation of CAPs that are no more or 
less prescriptive than necessary to remedy the non-conformity(ies) 
quickly and effectively.
    Comments. Multiple commenters suggested that CAPs as a result of 
ONC direct review should be based only on non-conformities with 
existing certification criteria of the Program.
    Response. In this final rule, a non-conformity is a failure of 
certified health IT or its developer to conform to the requirements of 
the Program. We emphasize, as discussed in detail in section 
II.A.1.a.(1) of this preamble, that Program requirements are not 
limited to compliance with certification criteria. A CAP will be based 
on a finding and notice of non-conformity, which necessarily involves a 
failure to meet Program requirements (Sec.  170.580(c)). Similarly, the 
elements of the CAP will address the actions a health IT developer must 
take to correct the identified non-conformity(ies) (i.e., bring its 
certified health IT back into conformity with the Program requirements 
that are the basis of the non-conformity(ies)).
    Comments. A commenter requested that we clarify the criteria 
necessary for resolving non-conformities under a CAP. Commenters 
requested that we specify the criteria that would lead to the rejection 
of a proposed CAP and recommended that we not reject a proposed CAP 
without giving the health IT developer an opportunity to discuss the 
issue(s) with ONC. One commenter suggested that ONC institute a process 
for health IT developers to respond to a rejection of a CAP.
    Response. We cannot define the specific criteria necessary for 
resolving non-conformities under a CAP because such criteria will be 
determined on a case-by-case basis. However, as noted above and in the 
Proposed Rule, ONC will provide direction to health IT developers as to 
the required elements of a CAP and will work with health IT developers 
to develop acceptable CAPs. We note that we have restructured and 
reordered the required elements for a CAP in the final rule for clarity 
and to avoid inclusion of redundant factors (see Sec.  170.580(c)(2)). 
We have also adopted two new elements for CAPs that serves to clarify 
how a health IT developer would demonstrate the resolution of all non-
conformities and issues (a proposed CAP element) and prevent the non-
conformity from re-occurring. We discuss these CAP elements below.
    Comments. A commenter suggested that we allow a health IT developer 
to request an extension for submitting and completing corrective action 
in certain cases.
    Response. ONC will permit health IT developers to submit requests 
for extension of the 30-day period to submit a CAP and the period ONC 
allocates for completion of the CAP. In order to make these requests, a 
health IT developer must submit a written statement to ONC that 
explains and justifies the extension request. ONC will evaluate each 
request individually and will make decisions on a case-by-case basis. 
We have added a provision at Sec.  170.580(c)(5) to reflect this 
policy. We clarify, however, that ONC may propose to terminate the 
certification of the health IT under review if, after 90 days of 
notifying the health IT developer of a non-conformity, ONC is unable to 
approve a CAP because the health IT developer has not submitted a CAP, 
proposed or revised, that adequately addresses all required elements of 
the CAP as determined by ONC (Sec.  170.580(c)(4)). This clarification 
of the 90-day time limit for approving a CAP aligns with the CAP 
requirement for ONC-ACBs (Sec.  170.556(d)(5)(ii)).
    Comments. A few commenters requested that we revise the proposed 
required CAP elements so that health IT developers are not required to 
ensure that all issues are resolved. Commenters stated that health IT 
developers cannot guarantee the absolute resolution regarding a 
provider's implementation within the required timeframe because some 
providers may not immediately implement the software update or modify 
their workflows in all ways necessary to ensure resolution.
    Response. We have finalized this requirement to ensure that all 
issues are resolved. The requirement is consistent with the corrective 
action requirements in Sec.  170.556(d)(3)(iv) and is a necessary 
requirement for corrective action. In response to the comment recited 
below regarding the need for more than just reliance on a health IT 
developer's attestation for verification of a CAP's completion, we have 
included a new required CAP element that clarifies how health IT 
developers are expected to meet the requirement to ensure that the non-
conformity and all issues are resolved. A health IT developer must 
include in a CAP a detailed description of the supporting documentation 
that will be provided to demonstrate that the identified non-
conformities and all issues are resolved. When ONC approves the CAP, we 
may require the supporting documentation to include testing results, 
independent expert analysis and verification, and/or other appropriate 
documentation to provide assurance that all issues have been resolved. 
Further, we understand that provider cooperation and actions must be 
taken into consideration. Therefore, we clarify that we expect a health 
IT developer will take and document the reasonable steps it took to 
ensure that all non-conformities and issues are resolved.
    We proposed elements that, at a minimum, must be included in a CAP. 
We received comments regarding the consequences of certification 
termination and our `certification ban' and `heightened scrutiny' 
proposals (see the ``Consequences of Certification Termination'' 
section below) requesting that we ensure sufficient protection for 
providers affected by non-conformities as well as supporting some form 
of heightened scrutiny of health IT that had a non-conformity and was 
subsequently terminated. In consideration of these comments and our 
stated goals in the Proposed Rule to promote public confidence in 
certified health IT and ensure the integrity of the Program, we have 
added a prospective element for CAPs. All CAPs must provide an 
explanation of, and agreement to execute, the steps that will be 
prevent the non-conformity from re-occurring. We believe this specific 
element of a CAP will help prevent reoccurrences of circumstances that 
led to the non-conformity(ies). This will support the integrity of the 
Program by addressing not only current problems, but also instituting 
``safeguards'' against further problems. Equally important, this CAP 
element will promote public confidence in certified health IT, 
including health IT that had a non-conformity. For example, a health IT 
developer can offer its customers reassurance that not only was the 
non-conformity corrected, but that steps have also been taken to 
prevent it from re-occurring.
    Comments. A commenter suggested that ONC review a Complete EHR or 
Health IT Module following the

[[Page 72434]]

completion of a CAP, rather than accepting the attestation as proof of 
conformity.
    Response. We have finalized the attestation requirement as 
proposed. We appreciate the commenter's concern, but believe 
attestation is an appropriate means for confirming that the health IT 
developer has fulfilled all of its obligations under the CAP, including 
curing the identified non-conformities and related deficiencies for all 
affected customers and taking all reasonable steps to prevent their 
recurrence. In addition, we emphasize three points. As specified above, 
a health IT developer must submit, and have approved by ONC, a CAP that 
includes a detailed description of the supporting documentation that 
the health IT developer will provide to demonstrate that the identified 
non-conformities and all issues are resolved. Second, an attestation 
serves as a binding official statement by the health IT developer. 
Third, if we later discover that the health IT developer had not acted 
in the manner attested, we may reinstitute the CAP or proceed to 
suspend or terminate the certification of the Complete EHR or Health IT 
Module (see Sec.  170.580(c)(7), (d)(1), and (e)(1)(vi)).
    Comments. Commenters generally supported reporting CAPs to the 
CHPL. Multiple commenters stated, however, that the CHPL alone is not 
an effective means for notifying customers because purchasers will not 
be in the habit of looking at the CHPL regularly. Commenters suggested 
that health IT developers should utilize more direct forms of 
notification. Commenters suggested that health IT developers send 
``push'' alerts and notifications. One commenter disagreed with 
reporting CAPs to the CHPL and expressed concern regarding the 
disclosure of trademark and proprietary software capabilities and/or 
functionalities, as well as the potential damage to health IT 
developers' reputations.
    Response. We thank commenters for their support of this proposal 
and for expressing their concerns. We have finalized this requirement 
as proposed. The reporting of CAP information to the CHPL is already 
required as specified in the 2015 Edition final rule (80 FR 62714) and 
at Sec.  170.556(e)(3) and we will continue this approach with CAPs 
that are a result of ONC direct review. This reporting will alert 
health IT users, implementers, and purchasers to potential conformity 
issues in a timely and effective manner. Further, as mentioned above, 
health IT developers must notify all potentially affected customers of 
the non-conformity and plan for resolution as part of a CAP.
    We understand that health IT developers may have concerns regarding 
disclosure of trademark and proprietary software capabilities and/or 
functionalities and potential damage to their reputations. To address 
these concerns, as discussed in the ``Notice of Potential Non-
Conformity or Non-Conformity'' section of this final rule above, we 
will implement safeguards to keep trademark or proprietary information 
confidential to the extent permissible by federal law.
(3) Suspension
    We proposed in the Proposed Rule that ONC may suspend a 
certification for similar reasons as allowed for ONC-ACBs, which were 
discussed in the 2015 Edition final rule (80 FR 62759). Specifically, 
we proposed that ONC would be permitted to initiate certification 
suspension procedures for a Complete EHR or Health IT Module for any 
one of the following reasons:
     Based on information it has obtained, ONC believes that 
the certified health IT poses a potential risk to public health or 
safety or other exigent circumstances exist. More specifically, ONC 
would suspend a certification issued to any encompassed Complete EHR or 
Health IT Module of the certified health IT if the certified health IT 
was, but not limited to: Contributing to a patient's health information 
being unsecured and unprotected in violation of applicable law; 
increasing medical errors; decreasing the detection, prevention, and 
management of chronic diseases; worsening the identification and 
response to public health threats and emergencies; leading to 
inappropriate care; worsening health care outcomes; or undermining a 
more effective marketplace, greater competition, greater systems 
analysis, and increased consumer choice. Such results would conflict 
with section 3001(b) of the PHSA, which instructs the National 
Coordinator to perform the duties in keeping or recognizing a 
certification program that, among other requirements, ensures patient 
health information is secure and protected in accordance with 
applicable law, reduces medical errors, increases efficiency, and leads 
to improved care and health care outcomes. As discussed in the 
``Termination'' section below, we proposed that ONC could terminate a 
certification on the same basis if it concludes that a certified health 
IT's non-conformity(ies) cannot be cured;
     The health IT developer fails to timely respond to any 
communication from ONC, including, but not limited to: Fact-finding, a 
notice of potential non-conformity, or a notice of non-conformity;
     The information provided by the health IT developer in 
response to any ONC communication, including, but not limited to: Fact-
finding, a notice of potential non-conformity, or a notice of non-
conformity is insufficient or incomplete;
     The health IT developer fails to timely submit a proposed 
CAP that adequately addresses the elements required by ONC; or
     The health IT developer does not fulfill its obligations 
under the CAP.
    We also proposed that ONC may suspend the certification of a 
Complete EHR or Health IT Module at any time when ONC believes that the 
certified health IT poses a potential risk to public health or safety, 
other exigent circumstances exist concerning the product, or due to 
certain actions or inactions by the product's health IT developer as 
detailed above. We noted that the processes for ONC-ACBs, as detailed 
in the 2015 Edition final rule (80 FR 62759), would not be altered by 
our proposals in the Proposed Rule.
    Comments. We received many comments regarding our proposed 
suspension criteria. Multiple commenters supported the suspension 
criteria as proposed and emphasized the need to protect public health 
and safety. Other commenters expressed concerns regarding ONC's 
proposed criteria for suspending the certification of a Complete EHR or 
Health IT Module. These commenters urged ONC to more clearly define the 
standards and criteria for suspension and to reserve suspension for 
particular cases of significant risk to patient health and safety. 
Commenters also stated that ONC should not suspend certification(s) 
when a health IT developer is working with ONC and acting in good faith 
to remedy the non-conformity through a CAP.
    Response. We thank commenters for their thoughtful comments on this 
aspect of our proposed suspension process. We agree with commenters 
that suspension should be limited to situations involving a serious 
risk to public health or safety, as these are the situations that would 
require immediate action. Therefore, in consideration of these 
comments, we have finalized a more limited basis for suspension than 
proposed. Specifically, ONC may only suspend a certification when ONC 
has a reasonable belief that the certified health IT may present a 
serious risk to public health or safety. As explained in section 
II.A.1.a.(3) of this preamble, in assessing whether there is a serious 
risk to public health or safety, ONC would

[[Page 72435]]

consider the nature, extent, and severity of the risk and the 
conditions giving rise to it, in light of the information available to 
ONC at the time. Separately, ONC could conclude that certified health 
IT poses a serious risk to public health or safety were it aware of 
information calling into question the validity of the health IT's 
certification.
    We clarify that ONC would still be able to suspend the 
certification of the health IT after the health IT developer begins 
corrective action if it identifies a serious risk to public health or 
safety.
    Comments. A commenter suggested that we not have the discretion to 
suspend a certification of a Complete EHR or Health IT Module at any 
time. The commenter stated that the reasons provided for suspending 
certification were too broad and that suspension, in the absence of a 
final legal or regulatory ruling, confers a presumption of guilt and 
responsibility on the health IT developer.
    Response. We have finalized the ability to suspend at any time if 
such action is necessary to protect public health or safety. We note 
our response to the previous comment which emphasizes the now limited 
scope of suspension focusing on risks to public health and safety. We 
further note, in response to the commenter, that suspension is part of 
the finalized regulation.
    Comments. A few commenters requested clarification regarding the 
distinction between criteria for suspension and termination and how to 
decide which is appropriate in certain situations. Another commenter 
recommended that ONC should, as a matter of process, issue a notice of 
suspension before issuing a notice of termination.
    Response. As stated in our responses above, at this time, we are 
choosing to limit our discretion to only suspend a certification when 
we believe that certified health IT presents a serious risk to public 
health or safety. This change not only clarifies why ONC would suspend 
a certification, but also draws a clear distinction between the reasons 
to suspend and the reasons to terminate a certification as described 
later in this final rule. This change also means that if ONC finds 
grounds for suspension, ONC will always first take the step to suspend 
the certification before initiating termination proceedings. We 
emphasize, however, that we may proceed with termination without first 
suspending a certification for other matters as outlined under the 
``Scope of Review'' section and the termination provisions in this 
final rule.
Suspension Process
    We proposed that ONC would issue a notice of suspension when 
appropriate. We stated that ONC's process for obtaining information to 
support a suspension could involve, but would not be limited to: Fact-
finding; requesting information from an ONC-ACB; contacting users of 
the health IT; and/or reviewing complaints. We proposed that a 
suspension would become effective upon the health IT developer's 
receipt of the notice of suspension.
    We proposed that the notice of suspension would include, but not be 
limited to: ONC's explanation for the suspension; the information ONC 
relied upon to reach its determination; the consequences of suspension 
for the health IT developer and the Complete EHR or Health IT Module 
under the Program; and instructions for appealing the suspension. We 
also stated that the notice of suspension would be sent via certified 
mail and the official date of receipt would be the date of the delivery 
confirmation consistent with Sec.  170.505.
    Comments. Multiple commenters supported the suspension process as 
proposed. One commenter suggested that ONC implement intermediate 
solutions short of suspension, such as: Fines or other financial 
penalties; a requirement that health IT developers bear the costs of 
repair or transition to another system; or, a clear statement of health 
IT developers' tort liability for the consequences of non-conformities.
    Response. We have decided not to implement intermediate 
``solutions'' as suggested by the commenter because the purpose of 
suspension as proposed is to enable ONC to act swiftly to address non-
conforming certified health IT that present a serious risk to public 
health or safety and intermediate ``solutions'' or ``penalties'' would 
delay such action. Additionally, at present, ONC does not have 
authority to level fines or other financial penalties in these 
situations and the liability of a health IT developer to customers, 
other parties, or other matters is outside the scope of this final 
rule.
Clarifications Regarding Notice of Suspension
    A notice of suspension will be effective on the date listed in the 
notice of suspension. We clarify that ONC will issue a notice of 
potential non-conformity or non-conformity at the same time it issues 
the notice of suspension. These notices will provide the health IT 
developer opportunities to respond to the basis for suspension. We 
further clarify the contents of a notice of suspension. We stated in 
the Proposed Rule that a notice of suspension would include the 
information ONC relied upon to reach its determination. We clarify, 
including in regulation, that the information we were referencing is 
information ONC provides with, and in support of, its determination.
Notification and Publication of Suspension
    We proposed that a health IT developer would be required to notify 
its affected and potentially affected customers of the certification 
suspension in a timely manner. We also proposed that ONC would 
publicize the suspension on the CHPL to alert interested parties, such 
as purchasers of certified health IT or programs that require the use 
of certified health IT. We requested comments on these processes, 
including how timely a health IT developer should notify affected and 
potentially affected customers of a suspension and what other means we 
should consider using for publicizing certification suspensions.
    Comments. We received many comments on the proposed requirements 
for notifying affected and potentially affected customers of a 
suspension. Commenters suggested that a health IT developer should not 
be required to notify its affected and potentially affected customers 
of a certification suspension until ONC reaches a final determination 
and concludes the appeal process. Some commenters requested we clarify 
the meaning of ``timely manner'' in the context of customer 
notification. One commenter suggested ONC require health IT developers 
to notify customers within 10 business days after receipt of the 
suspension notice. Some commenters supported publicizing suspensions on 
the CHPL and suggested other mechanisms for notifying customers, such 
as real-time electronic notifications.
    A few commenters suggested changes regarding the party that should 
make a notification of suspension and the party(ies) that should be 
notified. A commenter suggested that ONC should notify customers of a 
suspension, as opposed to the health IT developer notifying customers 
as proposed. The commenter also suggested that ONC notify customers of 
a health IT developer whose Complete EHR or Health IT Module is being 
considered for suspension. Another commenter suggested that if 
notifications of suspension are required, they should be sent to all 
customers of the product, not just those affected and potentially 
affected by the non-conformity.

[[Page 72436]]

    Response. We have finalized the notification requirements as 
proposed with the following clarification. We require that a health IT 
developer must notify ``all potentially affected customers'' as opposed 
to ``all affected and potentially affected'' customers as we proposed. 
We removed ``affected'' in this final rule because all ``affected'' 
customers would also be considered ``potentially affected'' customers; 
thus the language was redundant. All potentially affected customers 
should be notified of suspensions in a timely manner after the 
effective date of the suspension, regardless of whether a health IT 
developer is appealing the determination. We believe that ``potentially 
affected customers'' is the appropriate population for health IT 
developers to notify and is broad enough to protect customers that are 
or may be affected by the suspension.
    We believe a health IT developer is the appropriate party to alert 
its customers of a suspension as it would know best the potentially 
affected customers. It would be inappropriate to alert customers of a 
health IT developer whose Complete EHR or Health IT Module is being 
considered for suspension because such action might unfairly 
disadvantage a health IT developer whose Complete EHR or Health IT 
Module may not warrant suspension after further investigation and 
consideration.
    As suspension would be based on a serious risk to public health or 
safety, we believe it is imperative that customers be aware of the 
suspension. The notification will permit customers to take immediate 
action to protect public health and safety; and if the suspension is 
appealed, provide customers with additional time to consider their 
options and next steps. We believe ``timely'' is an appropriate term 
because the timeliness of the notification to all potentially affected 
customers may vary based on the circumstances of the case. While we 
believe that ONC must have discretion to address each situation 
accordingly, we agree with the commenter that notification within 10 
days or less of the effective date of the suspension may be reasonable 
in many circumstances.
    Last, we maintain that notification via the CHPL is an appropriate 
and effective step for widespread dissemination of a suspension 
determination to all stakeholders as the CHPL serves as the 
authoritative, comprehensive listing of health IT that has been tested 
and certified under the Program. We will further consider whether other 
forms of publication and dissemination, such as use of the ONC 
listserv, would be an appropriate and effective communication tool 
under the circumstances.
Consequences of Suspension
    We proposed that ONC would issue a cease and desist notice to 
health IT developers to immediately stop the marketing and sale of the 
Complete EHR or Health IT Module as ``certified'' under the Program 
when it suspends the Complete EHR's or Health IT Module's 
certification. We proposed that in cases of a certification suspension, 
inherited certified status for the Complete EHR or Health IT Module 
would not be permitted. We requested comment on whether a health IT 
developer should only be permitted to certify new Complete EHRs or 
Health IT Modules while the certification in question is suspended, if 
such new certification of other Complete EHRs or Health IT Modules 
would correct the non-conformity for all affected customers. We also 
requested comment as to whether correcting the non-conformity for a 
certain percentage of all affected customers or certain milestones 
demonstrating progress in correcting the non-conformity (e.g., a 
percentage of customers within a period of time) should be sufficient 
to lift the prohibition.
    Comments. Multiple commenters supported our proposed prohibition on 
the marketing and sale of a Complete EHR or Health IT Module during a 
suspension. One commenter noted that such a restriction is supportive 
of safe information systems. Other commenters stated that the 
prohibition on marketing and sale of the suspended Complete EHR or 
Health IT Module as ``certified'' is inappropriate and represents 
significant ``overreach,'' while some commenters stated that it would 
not be an ``overreach'' if there were a valid patient safety concern.
    Response. We thank commenters for their thoughtful comments and 
have finalized the `consequences of suspension' in relation to the 
Program with the following revision and clarifications. As noted above 
and in the Proposed Rule, we proposed that ONC would issue a cease and 
desist notice to health IT developers to immediately stop the marketing 
and sale of a Complete EHR or Health IT Module as ``certified'' under 
the Program when it suspends the Complete EHR's or Health IT Module's 
certification (81 FR 11064). We did not specifically include 
``licensing'' as part of this prohibition. However, we believe 
licensing is a form of product sale as in both cases a health IT 
developer likely receives some type of compensation. We also note that 
we specifically discuss licensing of certified health IT in the 
``Corrective Action'' section of the Proposed Rule (see 81 FR 11063). 
Our intention with this cease and desist notice was to protect the 
health and safety of users by completely prohibiting health IT 
developers from representing suspended health IT as ``certified.'' 
Therefore, we have specifically listed ``licensing'' as part of this 
prohibition to provide additional clarity. Affirmatively adding 
``licensing'' to this section is consistent with ONC's intent to cover 
all the ways in which health IT software is made available to customers 
in the health IT marketplace, as well as our stated goal throughout the 
``Suspension'' section in the Proposed Rule (81 FR 11064) and this 
final rule to protect public health and safety.
    As discussed earlier in this section, we have finalized a more 
limited basis for suspension than proposed, which is that we may only 
suspend a certification when we believe that the certified health IT 
presents a serious risk to public health or safety. Thus, by 
definition, in cases of suspension, ONC will only prohibit the 
marketing, licensing, and sale of a Complete EHR or Health IT Module 
when it presents serious risk to public health or safety. We believe 
this approach is consistent with comments and supports public health 
and safety.
    Comments. A few commenters expressed disagreement with our proposal 
to prohibit inherited status certification for a suspended Complete EHR 
or Health IT Module, while more commenters expressed disagreement with 
the possibility of a prohibition on the certification of a health IT 
developer's new Complete EHRs and Health IT Modules while the 
certification in question is suspended. Commenters stated that such 
restrictions are too far-reaching and suspension should only apply to 
the health IT under review. Some commenters suggested that a 
prohibition on new testing and certifications should only apply if a 
product is affected by the non-conforming product or there is reason to 
believe there is a wider, more pervasive deficiency with the health IT 
developer. A commenter suggested that our basis for determining 
progress for lifting the prohibition should be measured against what 
the health IT developer does to implement corrected products with 
providers.
    Response. We have added a provision at Sec.  170.580(d)(5) that 
bans the certification (which includes all types of certification, such 
as inherited certified status and gap certification) of any of a health 
IT developer's health IT if the health IT developer has the 
certification

[[Page 72437]]

on one of its products suspended. The suspension would only be lifted 
if, as determined by ONC, all affected customers have been provided 
appropriate remediation. As discussed in the Proposed Rule, a ban may 
incentivize the health IT developer to cure the non-conformity in an 
efficient manner. As the basis for suspension is now limited to a 
reasonable belief that the certified health IT presents a serious risk 
to public health or safety, we believe the ban is now even more 
essential to motivating a health IT developer to quickly address and 
correct what we believe to be a serious risk to public health or 
safety. We refer readers to section II.1.d.(1) of this final rule for 
further details on meeting the requirement for providing all affected 
customers with appropriate remediation.
Clarification Regarding ``Rescission'' of a Suspension
    We proposed in the Proposed Rule that ONC would only ``rescind'' a 
certification suspension if the health IT developer completes all 
elements of an approved CAP and/or ONC confirms that all non-
conformities have been corrected. We have renamed this provision as 
``cancellation.'' A suspension can be canceled, at any time, if ONC no 
longer has a reasonable belief that the certified health IT presents a 
serious risk to public health or safety. We believe this revised 
provision for canceling a suspension is appropriate because suspension 
is limited to situations in which ONC has a reasonable belief that the 
certified health IT may present a serious risk to public health or 
safety; therefore, the basis for cancellation is the opposite of the 
basis for suspension. The basis for establishing that there is no 
longer reason to believe that the certified health IT presents a 
serious risk to public health or safety may be based on information ONC 
obtains or information provided by a health IT developer. It could be 
for the same reasons as proposed (i.e., the health IT developer 
completes all elements of an approved CAP and/or ONC confirms that all 
non-conformities have been corrected) or possibly for other reasons.
(4) Termination
    We proposed that ONC may terminate certifications issued to 
Complete EHRs or Health IT Modules under the Program if: (1) The health 
developer fails to timely respond to any communication from ONC, 
including, but not limited to: (a) Fact-finding; and (b) a notice of 
potential non-conformity or non-conformity; (2) the information 
provided by the health IT developer in response to fact-finding, a 
notice of potential non-conformity, or a notice of non-conformity is 
insufficient or incomplete; (3) the health IT developer fails to timely 
submit a proposed CAP that adequately addresses the elements required 
by ONC as described in section II.A.1.c.(2) of this preamble; (4) the 
health IT developer does not fulfill its obligations under the CAP 
developed in accordance with proposed Sec.  170.580(c); or (5) ONC 
concludes that the certified health IT's non-conformity(ies) cannot be 
cured. We requested comment on the proposed reasons for termination and 
on any additional circumstances for which commenters believe 
termination of a certification would be warranted.
Proposed Termination and Termination
    Comments. A few commenters suggested less severe alternatives to 
termination, such as a probation period or implementation of 
intermediate solutions short of termination.
    Response. We thank commenters for their thoughtful comments. We 
explain in section II.A.1.c.(1) and (2) of this final rule (and also 
explained in the Proposed Rule (81 FR 11062-64)) that, prior to 
termination, ONC affords the health IT developer multiple opportunities 
to address and correct a non-conformity(ies) through responses to 
notices of potential non-conformity and/or non-conformity and a CAP. We 
believe that, if the health IT developer fails to address and correct 
the non-conformity(ies) at these stages in the direct review process, 
termination is an appropriate next step. A probation period would not 
adequately address the non-conforming health IT and/or non-responsive 
health IT developer in such situations. We emphasize once again that 
our goal is to work with health IT developers to correct non-
conformities and that termination is a last resort.
    In response to the comments and due to the severity of termination 
of a certification, we have added a new, intermediate step in the 
direct review process called ``proposed termination.'' The proposed 
termination step will provide health IT developers with an additional 
opportunity to resolve issues regarding a non-conformity prior to 
termination. We emphasize that the bases for ``proposed termination'' 
in this final rule are nearly identical to the bases for 
``termination'' in the Proposed Rule (81 FR 11084). The only 
differences are that in this final rule we have clarified that a health 
IT developer's failure to cooperate with ONC and/or a third party 
acting on behalf of ONC and a failure to timely submit in writing a 
proposed CAP are also bases for termination. We clearly stated in the 
Proposed Rule that these actions are required of health IT developers 
(see 81 FR 11062-63); therefore, non-compliance with these requirements 
will serve as a basis for proposed termination.
    As stated previously in this preamble under the discussion of Sec.  
170.505, we will send any notice of proposed termination by certified 
mail and the official date of receipt will be the date of the delivery 
confirmation to the address on record. A health IT developer may 
respond to a notice of proposed termination, but must do so within 10 
days of receiving the proposed termination notice and must include 
appropriate documentation explaining in writing why its certification 
should not be terminated. ONC will have up to 30 days to review the 
information submitted by the health IT developer and reach a decision. 
ONC may extend this timeframe if the complexity of the case requires 
additional time for ONC review.
    We have also finalized a provision that requires ONC to respond to 
the health IT developer's response to a notice of proposed termination 
within 30 days, unless ONC extends this timeframe due to the complexity 
of the case. The ONC response will either be to proceed with direct 
review, cease direct review, or proceed to termination (Sec.  
170.580(e)(4)). This requirement aligns with our stated goals in the 
Proposed Rule of promoting transparency and enhanced communication by 
providing health IT developers with information about ONC's progress 
during the direct review process.
    We refer readers to Sec.  170.580(e) in this final rule for the 
specific provisions of proposed termination.
    Comments. Multiple commenters supported the criteria for 
termination as proposed. Some commenters requested clearer and more 
substantive standards for termination of a certification.
    Response. We thank commenters for their support. As discussed in 
the preceding response, we have finalized the steps health IT 
developers must take to avoid termination as proposed in the Proposed 
Rule (81 FR 11065). We believe these criteria are substantive and clear 
as they describe specific situations of health IT developer inaction 
and incurable non-conformities in the health IT that would warrant 
termination by ONC. We also believe these criteria will incentivize 
health IT developers to cooperate in the direct review process and 
address non-conformities. Further, in regard to cooperation, we have

[[Page 72438]]

specifically included, consistent with our proposals in the Proposed 
Rule, the failure of a health IT developer to cooperate with ONC direct 
review as a basis for certification termination. Additionally, we 
believe the addition of the proposed termination step further clarifies 
our process for terminating a certification. We emphasize that the 
National Coordinator may terminate a certification if: (i) A 
determination is made that termination is appropriate after considering 
the information provided by the health IT developer in response to the 
proposed termination notice; or (ii) the health IT developer does not 
respond in writing to a proposed termination notice within the 
timeframe specified above. We note that the termination provisions have 
been finalized at Sec.  170.580(f) because of the addition of the 
``proposed termination'' step, which has been added to the final 
regulation at Sec.  170.580(e).
    Comments. A commenter requested that we define ``timely'' in the 
context of termination.
    Response. ``Timely'' is the appropriate term because it accounts 
for the timeframe for a health IT developer to respond to ONC, submit a 
CAP, and contact customers. The timeliness of these actions will vary 
based on the circumstances of the case. Therefore, ONC must have 
discretion to address each situation on a case by case basis.
Termination Process, Notification, and Publication
    We proposed that a termination would be issued consistent with the 
processes outlined below, but noted that the proposed termination 
processes do not change the certification termination processes for 
ONC-ACBs in Sec.  170.556(6).\12\ We stated that a notice of 
termination would include, but may not be limited to: ONC's explanation 
for the termination; the information ONC relied upon to reach its 
determination; the consequences of termination for the health IT 
developer and the Complete EHR or Health IT Module under the Program; 
and instructions for appealing the termination. We proposed that ONC 
would send a written notice of termination to the agent of record for 
the health IT developer of the Complete EHR or Health IT Module. We 
stated that the written termination notice would be sent via certified 
mail and the official date of receipt would be the date of the delivery 
confirmation.
---------------------------------------------------------------------------

    \12\ We note that ONC-ACB ``termination'' actions are 
technically referred to as ``withdrawals'' of certifications. We 
explain this distinction in detail in section II.A.d.(1) of this 
final rule.
---------------------------------------------------------------------------

    As we proposed for suspension of a certification, the health IT 
developer must notify the affected and potentially affected customers 
of the identified non-conformity(ies) and termination of certification 
in a timely manner. Additionally, we proposed that ONC would publicize 
the termination on the CHPL to alert interested parties, such as 
purchasers of certified health IT or entities administering programs 
that require the use of health IT certified under the Program. We 
requested comments on these processes, including how timely a health IT 
developer should notify affected and potentially affected customers of 
a termination of a Complete EHR's or Health IT Module's certification 
and what other means we should consider for publicizing certification 
terminations.
    Comments. Multiple commenters suggested changes for the proposed 
process for notifying customers of a termination. Some commenters 
recommended that health IT developers should not notify customers until 
ONC reaches a final determination and concludes all appeals. One 
commenter suggested that health IT developers should send notification 
to all customers, not just those affected and potentially affected by 
the non-conformity. Some commenters noted that reporting terminations 
to the CHPL is not effective and suggested that health IT developers 
use real-time electronic notifications in addition to reporting to the 
CHPL.
    Response. We thank commenters for their thoughtful comments on this 
aspect of the proposed termination process. We have, however, finalized 
the notification requirements as proposed with the following 
clarification. As we clarified for the ``Suspension'' portion of the 
direct review processes, we require that a health IT developer must 
notify ``all potentially affected customers'' as opposed to ``all 
affected and potentially affected'' customers as we proposed. We 
removed ``affected'' in this final rule because all ``affected'' 
customers would also be considered ``potentially affected'' customers. 
All ``potentially affected customers'' should be notified of 
terminations in a timely manner, regardless of whether a health IT 
developer is appealing the determination. We believe that this is the 
appropriate population for health IT developers to notify and is broad 
enough to protect customers that are or may be affected by the 
termination. The notification will permit customers to take immediate 
action, as they deem necessary, coinciding with the termination; and if 
the termination is appealed, provide customers with additional time to 
consider their options and next steps.
    We believe that notification via the CHPL is an appropriate and 
effective step for widespread dissemination of a termination 
determination to all stakeholders as the CHPL serves as the 
authoritative, comprehensive listing of health IT that has been tested 
and certified under the Program. We will further consider whether other 
forms of publication and dissemination, such as use of the ONC 
listserv, would be an appropriate and effective communication tool 
under the circumstances.
    We clarify the contents of a notice of termination and, similarly, 
a notice of proposed termination. We stated in the Proposed Rule that a 
notice of termination would include the information ONC relied upon to 
reach its determination. We clarify, including in regulation, that the 
information we were referencing is information ONC provides with, and 
in support of, its determination. In addition, as to only the notice of 
termination, we clarify that the `consequences of termination' in 
relation to the Program are the consequences specified in Sec.  
170.580(f)(3) (notifying potentially affected customers) and in Sec.  
170.581 (discussed in more detail in the ``Consequences of 
Certification Termination'' section of this final rule).
Termination Effective Date and Appeal
    We proposed that the termination of a certification would be 
effective either upon: (1) The expiration of the 10-day period for 
filing an appeal as specified in section II.A.1.c.(5) of this preamble, 
if the health IT developer does not file an appeal; or, if a health IT 
developer files an appeal, (2) upon a final determination to terminate 
the certification as described below in the ``Appeal'' section of this 
preamble.
    Comments. Many commenters stated that the proposed 10 days to file 
an appeal following a termination is insufficient, especially if no new 
information can be included as part of a hearing on appeal.
    Response. We refer readers to the ``Appeal'' section of this 
preamble below for our response to this concern.
Rescission of a Notice of Termination
    We have finalized a provision that permits ONC to rescind a 
determination to terminate a certification before it becomes effective 
if ONC determines that termination is no longer appropriate. To 
illustrate, ONC may rescind the determination to terminate on its own 
initiative or based on information provided by the developer

[[Page 72439]]

that convinces ONC that the termination decision was made in error or 
is otherwise no longer appropriate. We have included this provision as 
part of the termination process in order to address situations where a 
certification was terminated, but it would be inefficient to proceed 
through the appeals process or inappropriate to effectuate the 
termination. This requirement aligns with our stated goals in the 
Proposed Rule of working with health IT developers, ensuring the 
integrity of the Program, and promoting transparency.
(5) Appeal
    We proposed that if ONC suspends or terminates a certification for 
a Complete EHR or Health IT Module, the health IT developer of the 
Complete EHR or Health IT Module may appeal the determination to the 
National Coordinator in accordance with the proposed processes outlined 
below. We proposed that a health IT developer may appeal an ONC 
determination to suspend or terminate a certification issued to a 
Complete EHR or a Health IT Module if the health IT developer asserts: 
(1) ONC incorrectly applied Program methodology, standards, or 
requirements for suspension or termination; or (2) ONC's determination 
was not sufficiently supported by the information used by ONC to reach 
the determination to suspend or terminate a certification.
    We proposed that a request for appeal of a suspension or 
termination must be submitted in writing by an authorized 
representative of the health IT developer whose certified Complete EHR 
or certified Health IT Module was subject to the determination being 
appealed. We also proposed that the request for appeal must be filed in 
accordance with the instructions specified in the notice of termination 
or notice of suspension. We stated that these instructions for filing a 
request may include, but would not be limited to, requiring the health 
IT developer to: (1) Provide a copy of the written determination by ONC 
to suspend or terminate the certification and any supporting 
documentation; and (2) explain the reasons for the appeal.
    We proposed that the appeal request must be submitted to ONC within 
10 days of the health IT developer's receipt of the notice of 
suspension or notice of termination. We proposed that an appeal request 
would stay the termination of a certification issued to a Complete EHR 
or Health IT Module until a final determination is reached on the 
appeal. However, we noted that a request for appeal would not stay a 
suspension of a Complete EHR or Health IT Module. We proposed that, 
while an appeal would stay a termination, a Complete EHR or Health IT 
Module would be prohibited from being marketed or sold as ``certified'' 
during the stay. This was similar to the proposed effects of a 
suspension.
    We proposed that the National Coordinator would assign the appeal 
to a hearing officer who would adjudicate the appeal on his or her 
behalf. We stated that the hearing officer may not preside over an 
appeal in which he or she participated in the initial suspension or 
termination determination by ONC or has a conflict of interest in the 
pending matter.
    We stated in the Proposed Rule that there would be two parties 
involved in an appeal: (1) The health IT developer that requests the 
appeal; and (2) ONC. We proposed that the hearing officer would have 
the discretion to make a determination based on two options: (1) The 
written record as submitted to the hearing officer by the health IT 
developer with the appeal filed in accordance with proposed 
requirements, which would include ONC's written statement and 
supporting documentation, if provided; or (2) the information described 
in option 1 and a hearing conducted in-person, via telephone, or 
otherwise. We specified that the hearing officer would have the 
discretion to conduct a hearing if he or she: (1) Requires 
clarification by either party regarding the written record; (2) 
requires either party to answer questions regarding the written record; 
or (3) otherwise determines a hearing is necessary. We specified that 
the hearing officer would neither receive testimony nor accept any new 
information that was not presented with the appeal request or was 
specifically and clearly relied upon to reach the determination to 
suspend or terminate the certification by ONC. We specified that the 
default process for the hearing officer would be a determination based 
on option 1 described above.
    We proposed that once the health IT developer requests an appeal, 
ONC would have an opportunity to provide the hearing officer with a 
written statement and supporting documentation on its behalf (e.g., a 
brief). We stated that the failure of ONC to submit a written statement 
would not result in any adverse findings against ONC and may not in any 
way be taken into account by the hearing officer in reaching a 
determination.
    We proposed that the hearing officer would issue a written 
determination to the health IT developer within 30 days of receipt of 
the appeal, unless the health IT developer and ONC agree to a finite 
extension approved by the hearing officer. We proposed that the 
National Coordinator's determination, as issued by the hearing officer, 
would be the agency's final determination and not subject to further 
review.
    We requested comments on the proposed appeal processes. 
Specifically, we requested comment on whether the allotted time for the 
hearing officer to issue a written determination should be lessened or 
lengthened, such as 15, 45, or 60 days. We also requested comment on 
whether an extension should be permitted and whether it should only be 
permitted under the extension circumstances proposed or for other 
reasons and circumstances.
Clarification Regarding the Appeal of Concurrent Suspension and 
Termination
    We clarify that there may be situations where a certification is 
both suspended and terminated. For instance, ONC may suspend a 
certified Complete EHR or Health IT Module because it presents a 
serious risk to public health or safety. With the certification 
suspended pending corrective action, ONC may later propose to terminate 
and subsequently terminate the certification on the basis that the 
health IT developer did not cooperate with the direct review. In such a 
situation, the health IT developer must submit two separate statements 
of intent to appeal and requests for appeal in writing to ONC in 
accordance with Sec.  170.580(g)(2) in order to appeal the suspension 
and the termination. We note that, in most cases, a health IT 
developer's opportunity to appeal a suspension in accordance with Sec.  
170.580(g)(3) would lapse prior to ONC's decision to terminate the 
certification.
    In these cases (a suspension and termination of the same 
certification), the hearing officer would issue separate final 
determinations for the suspension and termination. For instance, the 
hearing officer may find that ONC terminated the certification 
prematurely and therefore reverse the termination on that basis, which 
would reinstate the certification. At the same time, however, the 
hearing officer may uphold ONC's decision to suspend the certified 
health IT because, for instance, it posed a serious risk to public 
health or safety or because the health IT developer failed to timely 
appeal the suspension.
    Comments. A commenter stated that the health IT developer should be 
able to appeal an initial assessment of non-conformity, a CAP, and/or 
the terms of a CAP.

[[Page 72440]]

    Response. We have finalized an approach that only permits appeals 
of ONC determinations to suspend or terminate a certification of a 
Complete EHR or Health IT Module. ONC has the authority to determine 
whether health IT remains in conformity with voluntary Program 
requirements. A notice of non-conformity and CAP are remedial steps 
designed to bring certified health IT back into conformity with Program 
requirements. Upon an ONC determination to suspend or terminate a 
certification, we believe a health IT developer should be afforded the 
opportunity to appeal the determination because of the consequences 
health IT developers and certified health IT face due to these actions 
(i.e., the prohibition on the marketing, licensing, and sale of 
suspended health IT as ``certified'' and the consequences of 
termination specified in Sec.  170.581) and the likely negative impact 
this will have on the ability of a health IT developer to sell or 
license its health IT to providers and consumers, as many HHS programs 
require participants to have and/or use certified health IT.
    Comments. Multiple commenters questioned the proposed bases for 
appeal and suggested that we clarify the requirements. Some commenters 
requested more specificity in the first basis for appeal. Commenters 
requested that in order to meet this basis for appeal ONC must first 
identify and state specifically how it applied Program methodology, 
standards, and requirements for suspension or termination findings. 
Commenters also requested that ONC clarify the meaning of ``sufficient 
support'' in the second basis for appeal.
    Response. We appreciate the comments on this proposal. We have 
removed the redundancy in the first basis for appeal by simply stating 
``Program requirements.'' We believe that the proposed bases for 
appealing ONC decisions are now clear and appropriate. The two bases 
for appeal require that an ONC decision is based on Program 
requirements for health IT developers and certified health IT and is 
supported by sufficient information. We describe in the ``Suspension'' 
and ``Termination'' sections of this final rule that ONC will provide 
an explanation of the suspension or termination determination in a 
notice of suspension or notice of termination, as applicable. ONC will 
also provide information to support its determination and the 
consequences for the health IT developer and the Complete EHR or Health 
IT Module under the Program. This information will enable the health IT 
developer to assess whether ONC has correctly applied Program 
requirements and whether ONC's determination was sufficiently supported 
by information provided with the determination. We maintain that 
``sufficiently supported'' is an appropriate term to use in the second 
basis for appeal because information provided with the determination 
will vary on a case-by-case. We clarify, as we have similarly done in 
the ``Suspension'' and ``Termination'' sections of this final rule, 
that this standard conveys that ONC's determination must be supported 
by information provided with the determination. Accordingly, we have 
finalized the bases for appeal in Sec.  170.580(g)(1) with the 
revisions discussed above.
    Comments. We received many comments regarding the appeal 
timeframes. Commenters stated that the proposed 10 days to file an 
appeal following a termination is insufficient, particularly if, as 
proposed, no new information can be included as part of an appeal 
hearing. The commenters asserted that collecting appropriate records 
for the appeal would be time consuming. Many commenters also proposed a 
two-step process for filing an appeal: (1) Filing a statement of intent 
to appeal; and (2) filing a request for appeal with supporting 
documentation. Commenters generally supported the 30-day timeframe for 
the hearing officer to make a final determination, while some 
commenters recommended that this timeframe be flexible based on the 
complexity of each case.
    Response. We understand commenters' concerns regarding the 10-day 
period to file an appeal and, therefore, have accepted the commenters' 
recommendations for a two-step process for filing a statement of intent 
to appeal and then filing the appeal and supporting documentation. 
Specifically, in Sec.  170.580(g)(3), we include requirements that a 
statement of intent to appeal must be filed within 10 days of receipt 
of the notice of suspension or notice of termination; and an appeal, 
including all supporting documentation, must be filed within 30 days of 
the filing of the intent to appeal.
    In accordance with this two-step process, a termination will become 
effective upon: (1) The expiration of the 10-day period for filing a 
statement of intent to appeal if the health IT developer does not file 
a statement of intent to appeal; (2) the expiration of the 30-day 
period for filing an appeal if the health IT developer files a 
statement of intent to appeal, but does not file a timely appeal; or 
(3) a final determination to terminate the certification if a health IT 
developer files an appeal (Sec.  170.580(f)(2)(ii)).
    We thank commenters for their support of the 30-day timeframe for 
the hearing officer to make a final determination. To provide 
flexibility for complex cases and unforeseen circumstances, we have 
finalized the proposal to permit the hearing officer to extend the 
timeframe for issuing a decision if the health IT developer and ONC 
agree to a finite extension and it is approved by the hearing officer. 
We believe this will provide the parties and the hearing officer with 
necessary flexibility as recommended by commenters.
    We have revised the proposed `determination by the hearing officer' 
provision to clarify that the hearing officer will not issue a written 
determination to the health IT developer if ONC cancels the suspension 
or rescinds the termination determination (Sec.  170.580(g)(7)). We 
have described ONC's ability to cancel a suspension and rescind 
termination determination, as well as ONC's rationale for allowing such 
actions, in sections II.A.1.c.(3) and (4) of this preamble, 
respectively.
    Comments. Multiple commenters disagreed with our proposal that a 
request for appeal would not stay a suspension of a Complete EHR or 
Health IT Module. Specifically, commenters stated that the inability of 
a health IT developer to market and sell a product as ``certified'' 
while the product is suspended is overly punitive and could have 
untoward impacts on end-users.
    Response. We have finalized this requirement as proposed. A request 
for appeal will not stay a suspension. As discussed in the 
``Suspension'' section of this preamble, ONC may now only suspend the 
certification of health IT if it has a reasonable belief that the 
certified health IT may present a serious risk to public health or 
safety. In such situations, ONC must take immediate action to protect 
customers and incentivize the health IT developer to correct the non-
conformity as soon as possible. A stay of a suspension would be 
inappropriate because it would delay this immediate action.
    Comments. Many commenters expressed concerns regarding the 
appointment and qualifications of the hearing officer. Commenters 
asserted that the hearing officer should not be assigned by the 
National Coordinator or be selected from within ONC, as this could 
cause a conflict of interest and raise questions about the impartiality 
of the hearing officer. Commenters suggested that we clarify the 
required qualifications for the hearing officer. Commenters also opined 
that the

[[Page 72441]]

hearing officer should not make the sole determination on whether to 
hold a hearing and should not be able to make a determination without a 
hearing.
    Response. We have finalized the `appointment of a hearing officer' 
provisions as proposed with an added requirement and clarifications in 
response to comments. We understand commenters' concerns regarding the 
impartiality of the hearing officer and agree that the hearing officer 
must be an impartial arbiter of appeals. The hearing officer will be 
chosen by the National Coordinator as the National Coordinator is best 
situated to identify a hearing officer, whether from within or outside 
ONC, that can represent him or her and have the requisite skills, 
qualifications, and knowledge to adjudicate these appeals. As proposed, 
in order to reduce the potential for conflicts of interest, the hearing 
officer will not be able to preside over an appeal in which he or she 
participated in the initial suspension or termination determination by 
ONC or has a conflict of interest in the pending matter. Additionally, 
in consideration of commenters' concerns and our commitment to an 
impartial appeals process, we have added a requirement at Sec.  
170.580(g)(5)(ii) that requires a hearing officer to be trained in a 
nationally recognized ethics code that articulates nationally 
recognized standards of conduct for hearing officers/officials. For 
example, an acceptable nationally recognized ethics code is, but is not 
limited to, the National Association of Hearing Officials' Model Code 
of Ethics.
    The decision as to whether to hold a hearing will be left to the 
discretion of the hearing officer, as he or she will be most familiar 
with the facts of the case and will be best equipped to make such a 
determination.
    Comments. Commenters disagreed with the proposed requirement that 
the hearing officer will neither receive testimony nor accept any new 
information that was not presented with the appeal request or was 
included with the determination. Another commenter suggested we revise 
the regulation text to clarify that the hearing officer will not 
receive certain testimony and information.
    Response. We have finalized the requirement as proposed. This 
requirement will facilitate the appropriate development of the record 
prior to appeal, encourage health IT developers to submit a thorough 
and comprehensive appeal request, and facilitate expeditious 
resolutions of appeals. However, in consideration of comments, we have 
finalized a two-step process for filing a statement of intent to appeal 
and then filing the appeal and supporting documentation, which will 
afford health IT developers additional time to compile information and 
records to support their appeals. This process is discussed in more 
detail above in response to other comments.
    In consideration of the commenter's request for revised regulation 
text, we have revised the relevant appeal provision (Sec.  
170.580(g)(6)(iii)) to clarify that the hearing officer will not 
receive witness testimony and new information beyond that which is 
permitted with filing an appeal and given at a hearing. We have also 
made clear that the written record includes the ONC determination to 
suspend or terminate a certification and information to support the 
issued determination (Sec.  170.580(g)(6)(i)).
    Comments. Commenters recommended that ONC implement a more formal, 
multi-round appeals process.
    Response. Because we provide multiple opportunities for health IT 
developers to address the bases for ONC actions to suspend and/or 
terminate the certification of a Complete EHR or Health IT Module, we 
do not believe a more elaborate appeals process is generally necessary. 
However, for terminations, we have added another opportunity to resolve 
the matter through a ``proposed termination'' step that we have 
finalized in this final rule. The review, determination, and appeal 
processes in this final rule provide sufficient and equitable 
opportunities for health IT developers to address non-conformities 
found in their certified health IT, while ensuring the timely 
resolution of matters that may pose a serious risk to public health or 
safety.
    Comments. Commenters disagreed with the proposal that ONC's failure 
to submit a written statement will not result in any adverse findings 
against ONC and may not in any way be taken into account by the hearing 
officer in reaching a determination. The commenters stated that ONC 
should be obligated to provide a written statement, including any and 
all information, analysis, and documentation it used to come to its 
determination. Additionally, the commenters asserted that this 
statement should be made available to the health IT developer.
    Response. We have finalized the requirement substantially as 
proposed with the following revisions and clarifications. To clarify, 
if ONC suspends or terminates a certification, ONC will send a notice 
of suspension or termination, respectively, to the health IT developer 
(see Sec.  170.580(d)(2) and (f)(2)). As detailed in paragraphs 
(d)(2)(i) and (f)(2)(i), the notice will include an explanation and 
information to support ONC's determination. Therefore, we have revised 
this provision to clearly state that ONC will have an opportunity to 
provide the hearing officer with an additional written statement and 
supporting documentation on its behalf that clarifies, as necessary, 
its determination to suspend or terminate the certification. We have 
further revised the provision to clarify that not only would the 
written statement and supporting documentation be included as part of 
the written record, but it must also be provided to the health IT 
developer within 15 days of the health IT developer's filing of an 
intent to appeal.
    Comments. A commenter stated that ONC's assertion that an appeal 
determination is final and not subject to further review misstates the 
reviewability of administrative decisions by federal courts.
    Response. This provision does not address the reviewability of 
administrative decisions by federal courts. The purpose of this 
regulatory provision is to convey that there are no further 
administrative reviews of the determination.
    Comments. A commenter expressed concern that health IT developers 
were not afforded appeal rights for ONC-ACB determinations. The 
commenter explained that, if there are two different enforcement bodies 
(ONC and ONC-ACBs) that may make determinations, there should be equal 
rights for a health IT developer to appeal those determinations.
    Response. We refer readers to section II.A.1.b of this final rule 
for an explanation of our decision not to extend appeal rights for ONC-
ACB determinations.
    Comments. A commenter suggested that providers should be included 
in the appeals process because providers will often make the initial 
complaint concerning a non-conformity.
    Response. We encourage providers and other interested stakeholders 
to contact ONC throughout ONC's direct review with information about 
non-conformities that would be relevant during ONC's direct review of 
certified health IT. We do not, however, believe providers should be 
parties to an appeal. The matters potentially under review relate to 
the continued conformity of certified health IT to Program requirements 
that health IT developers have voluntarily accepted as part of 
certification of their health IT.

[[Page 72442]]

d. Consequences of Certification Termination
    We stated in the Proposed Rule that, in general, this rulemaking 
does not address the consequences of certification termination beyond 
requirements for recertification. We stated that any consequences of, 
and remedies for, termination beyond recertification requirements are 
outside the scope of this rulemaking.
    Comments. A commenter emphasized that all users of certified health 
IT, not just those participating in the EHR Incentive Programs, should 
be taken into account when addressing the consequences of certification 
termination. Other commenters expressed concern about the impact 
certification termination could have on providers participating in the 
EHR Incentive Programs (e.g., with attestation) and other affected 
programs. These commenters pointed out that providers using a health IT 
product with a terminated Complete EHR or Health IT Module 
certification or one under appeal would risk failing to comply with CMS 
regulations. Commenters recommended that ONC coordinate with CMS to 
ensure sufficient protection for affected providers.
    Response. We thank commenters for their feedback. We reiterate as 
stated above and in the Proposed Rule, that any consequences of, and 
remedies for, termination beyond recertification requirements are 
outside the scope of this rulemaking (i.e., final rule). We, however, 
emphasize that we, and HHS as a whole, are committed to working with 
all users and providers in cases of termination to mitigate the impact 
on participants of programs requiring the use of certified health IT, 
particularly participants in HHS programs. As mentioned earlier under 
the ``termination'' section of this preamble, we intend to use the CHPL 
and other appropriate forms of publication and dissemination to notify 
users of health IT certification terminations.\13\ We will also 
coordinate with affected HHS programs to facilitate the notification of 
their participants and to identify and make available appropriate 
remedies for participants. As noted in the Proposed Rule, CMS has 
issued a FAQ \14\ for the EHR Incentive Programs informing participants 
about their options if the health IT they are using to participate in 
the programs has its certification terminated.
---------------------------------------------------------------------------

    \13\ As mentioned under the ``suspension'' section of this 
preamble, we will take the same steps to notify users of health IT 
that has its certification suspended under the Program.
    \14\ See CMS EHR Incentive Programs FAQ 12657: https://questions.cms.gov/faq.php?isDept=0&search=decertified&searchType=keyword&submitSearch=1&id=5005.
---------------------------------------------------------------------------

    We note that an ONC certification termination under appeal stays 
the termination. This means the health IT remains certified while the 
appeal is ongoing. Similarly, health IT with a suspended certification 
as a result of ONC direct review is still certified and could be 
identified as certified health IT for HHS program purposes. While our 
goals with this final rule are to enhance Program oversight and health 
IT developer accountability for the performance, reliability, and 
safety of certified health IT, we remind stakeholders that we have 
finalized methods (e.g., CAPs) designed to identify and remedy non-
conformities so that health IT can maintain its certification.
(1) Certification Ban, Recertification, and Heightened Scrutiny
    We proposed in the Proposed Rule that a Complete EHR or Health IT 
Module that has had its certification terminated can be tested and 
recertified once all non-conformities have been adequately addressed. 
We proposed that the recertified Complete EHR or Health IT Module (or 
replacement version) must maintain a scope of certification that, at a 
minimum, includes all the previously certified capabilities. We 
proposed that the health IT developer must request permission from ONC 
to participate in the Program before submitting the Complete EHR or 
Health IT Module (or replacement version) for testing to an ONC-ATL and 
recertification (certification) by an ONC-ACB under the Program. As 
part of its request, we proposed that a health IT developer must submit 
a written explanation of what steps were taken to address the non-
conformities that led to the termination. We also proposed that ONC 
would need to review and approve the request for permission to 
participate in the Program before testing and recertification 
(certification) of the Complete EHR or Health IT Module (or replacement 
version) can commence under the Program.
    We proposed in the Proposed Rule that if the Complete EHR or Health 
IT Module (or replacement version) is recertified (certified), the 
certified health IT product should be subjected to some form of 
heightened scrutiny by ONC or an ONC-ACB for a minimum of one year. We 
requested comments on the forms of heightened scrutiny (e.g., quarterly 
in-the-field surveillance) and length of time for the heightened 
scrutiny (more or less than one year, such as six months or two years) 
of a recertified Complete EHR or recertified Health IT Module (or 
replacement version) that previously had its certification terminated. 
We requested comment on whether heightened scrutiny (surveillance or 
other requirements) should apply for a period of time (e.g., six 
months, one year, or two years) to all currently certified Complete 
EHRs or certified Health IT Modules, future versions of either type, 
and all new certified health IT of a health IT developer that has a 
product's certification terminated under the Program.
    We proposed in the Proposed Rule that the testing and certification 
of any health IT of a health IT developer that has the certification of 
one of its health IT products terminated under the Program or withdrawn 
from the Program when the subject of a potential non-conformity (notice 
of potential non-conformity) or non-conformity would be prohibited 
(``Program Ban''). We stated that the only exceptions would be if: (1) 
The non-conformity is corrected and implemented to all affected 
customers; or (2) the certification and implementation of other health 
IT by the health IT developer would remedy the non-conformity for all 
affected customers. We noted in the Proposed Rule that prohibiting the 
certification of new products, unless it serves to correct the non-
conformity for all affected customers, may incentivize a health IT 
developer to cure the non-conformity. In correcting the non-conformity 
for all affected customers, we stated that this would not include those 
customers that decline the correction or fail to cooperate. We 
requested comment on this proposal, including how the health IT 
developer should demonstrate to ONC that all necessary corrections were 
completed. We further requested comment as to whether correcting the 
non-conformity for a certain percentage of all affected customers or 
certain milestones demonstrating progress in correcting the non-
conformity (e.g., a percentage of customers within a period of time) 
should be sufficient to lift the prohibition.
    We discuss the proposals, comments, and our responses below 
beginning with the ``Program Ban'' proposal. We note that we have 
renamed the proposed ``Program Ban'' as ``Certification Ban'' (also 
simply referred to as ``Ban'' in this final rule). This name more 
accurately aligns with the effect of the Ban, which is to prohibit the 
certification of health IT. This also assists in clarifying that 
testing of health IT may still occur, which as discussed below, may be 
necessary as part of the process of ``reinstatement and remediation of 
all

[[Page 72443]]

affected customers.'' We note that we address the ``recertification'' 
proposal as part of the ``Reinstatement and Remediation for All 
Affected Customers'' discussion. This approach provides the most 
clarity regarding the final policies of this final rule.
Certification Ban
    Comments. Many commenters opposed the Ban, stating that it should 
only apply to health IT that has a non-conformity. Commenters stated 
that a Ban would prevent timely upgrades, such as delivery of new 
functionality or necessary enhancements to users. Other commenters 
supported the Ban. One commenter requested clarification on how health 
IT developers are defined for the purposes of the Ban, inquiring if the 
Ban includes corporate subsidiaries of health IT developers and if they 
are also subject to the Ban.
    Response. We thank commenters for their input and have finalized 
this proposal, subject to revisions and clarifications in response to 
comments. We continue to believe, despite the potential impact on other 
customers of health IT developers, that prohibiting the certification 
of health IT, unless it serves to correct the non-conformity, may 
incentivize a health IT developer to cure non-conformities and remedy 
the situation for affected customers. Therefore, we have finalized a 
Certification Ban. We have, however, included revisions both for 
clarity and to provide more flexibility for health IT developers to 
meet the requirements for lifting a Certification Ban. These revisions 
are discussed directly below and in the ``Reinstatement and Remediation 
for All Affected Customers'' section that follows.
    We first clarify that ``termination'' in this final rule means an 
ONC action to ``terminate'' or ``revoke'' the certification status of a 
Complete EHR or Health IT Module. Conversely, an action by an ONC-ACB 
to ``terminate,'' ``remove,'' or ``revoke'' the certificate of a 
Complete EHR or Health IT Module is referred to as ``withdrawal.'' ISO/
IEC 17065 defines the requirements for conformity assessment by ONC-
ACBs and defines ``withdrawal'' (as defined in ISO 17000) \15\ as a 
revocation or cancellation of the statement of conformity.\16\ This 
occurs in two situations: (1) When an ONC-ACB proactively removes a 
certification based on its own accord; or (2) when a health IT 
developer initiates the discontinuation of a product's certification 
and requests that the ONC-ACB remove the product's certificate. We make 
the distinction between ``termination'' and ``withdrawal'' to conform 
with ISO's use of ``withdrawal'' throughout the ISO standards. However, 
ONC retains use of the term ``termination'' in this final rule because 
we enforce Program requirements directly, not under delegated authority 
and not subject to ISO standards, as is the case for ONC-ACBs. We use 
this new terminology in our explanation of final Ban provisions below, 
throughout the new Sec. Sec.  170.580 and 170.581, and in revisions to 
Sec.  170.556(d)(6) that we are finalizing in this final rule to align 
with ISO/IEC 17065. In Sec.  170.556(d)(6), we changed ``termination'' 
to ``withdrawal'' and ``terminating'' to ``withdrawing.''
---------------------------------------------------------------------------

    \15\ ISO/IEC 17000 (2004).
    \16\ We note that ISO does not explicitly define ``terminate.''
---------------------------------------------------------------------------

    We clarify that the certification of any of a health IT developer's 
health IT is prohibited when the certification of one or more of the 
health IT developer's Complete EHRs or Health IT Modules is (1) 
terminated by ONC under the Program; (2) withdrawn from the Program by 
an ONC-ACB because the health IT developer requested it to be withdrawn 
when the health IT developer's health IT was the subject of a potential 
non-conformity or non-conformity as determined by ONC; (3) withdrawn by 
an ONC-ACB because of a non-conformity with any of the certification 
criteria adopted by the Secretary under subpart C of this part; or (4) 
withdrawn by an ONC-ACB because the health IT developer requested it to 
be withdrawn when the health IT developer's health IT was the subject 
of surveillance for a certification criterion or criteria adopted by 
the Secretary under subpart C of this part, including pending 
surveillance (e.g., the health IT developer received notice of pending 
randomized surveillance). This more detailed specification regarding 
when a Certification Ban applies is consistent with our proposals, 
including our proposal to apply the Certification Ban to withdrawals 
completed by ONC-ACBs. We clarify that for ONC-ACBs' withdrawals as 
specified in (3) and (4) above, the focus is on non-conformities with 
certification criteria and not non-conformities arising from Sec. Sec.  
170.523(k)(1) (disclosure of information about limitations and 
additional types of costs associated with their certified health IT), 
170.523(l) (compliance with rules governing the use of the ONC 
Certification and Design Mark), or 170.523(n) (submit user complaints 
to ONC-ACBs).
    We also clarify that the Certification Ban affects health IT 
developers participating in the Program, their subsidiaries, and their 
successors.
Reinstatement and Remediation for All Affected Customers
    Comments. A commenter requested clarification on what qualifies as 
adequately addressing a non-conformity. We received mixed comments on 
whether a terminated health IT product (if presented for 
recertification) should be required to maintain a scope of 
certification that, at a minimum, includes all the previous certified 
capabilities. A few commenters supported our proposal, stating that any 
reduction in scope penalizes providers who may face significant 
financial penalties, and that physicians rely on their purchased 
product to best fulfill their practice needs. In contrast, some 
commenters expressed general opposition to our proposed approach.
    One commenter recommended that the Certification Ban be lifted once 
ONC is satisfied with the corrective action rather than be dependent on 
customer acceptance or adoption of the corrected certified IT or other 
remedies. Similarly, a couple of other commenters recommended that all 
users must have the correction available (whether they choose to 
install or not). One of these commenters contended that decisions to 
implement patches may dictate when the customer's non-conforming health 
IT will be corrected for the customer.
    Response. We have finalized the proposed requirements that a health 
IT developer must request permission to participate in the Program, 
explain the steps taken to address the non-conformities that led to the 
certification termination (or withdrawal), and receive approval from 
ONC to participate in the Program again. Specifically, for the 
Certification Ban to be lifted, we require that: (1) A health IT 
developer must request in writing ONC's permission to participate in 
the Program; (2) the request must demonstrate that the customers 
affected by the certificate termination or withdrawal have been 
provided appropriate remediation; and (3) ONC is satisfied with the 
health IT developer's demonstration that all affected customers have 
been provided with appropriate remediation and grants reinstatement 
into the Program. These requirements are consistent with our proposals 
and address our primary goal of addressing affected customers, 
particularly the requirement of appropriate remediation. We discuss the 
aspects of ``appropriate remediation'' in our responses to comments 
below.
    We agree with some commenters that a reduction in scope unfairly 
penalizes customers who rely on their purchased or licensed certified 
health IT to best fulfill their practice needs. As stated in

[[Page 72444]]

the Proposed Rule, health IT is tested and certified to meet adopted 
certification criteria and requirements. It should continue to meet 
those certification criteria and requirements when implemented. 
Therefore, in determining whether a health IT developer has 
demonstrated that all affected customers have been provided with 
appropriate remediation, we will require that the scope of certified 
health IT previously provided to the affected customers be maintained 
(i.e., a health IT developer must demonstrate, and ONC is satisfied, 
that all the necessary certified health IT has been made available to 
affected customers). We note, as discussed in more detail below, that 
an affected customer can choose alternative means of remediation, which 
would be sufficient for lifting the Ban.
    We agree with commenters that the Certification Ban may be lifted 
once ONC is satisfied that all non-conformities have been addressed and 
the correction is made available for all affected customers. However, 
in providing appropriate remediation to affected customers, we 
acknowledge that there may be other ways for health IT developers to 
correct situations for customers short of correcting the certified 
version or providing a replacement certified version. Therefore, we 
provide that, as determined by ONC, other certified health IT may be 
made available by the health IT developer that would remedy the non-
conformity for all affected customers. This certified health IT may be 
the health IT of another health IT developer.
    We also agree with commenters that there may be reasons why a 
customer does not implement the corrected certified version or other 
available certified health IT in a timely manner or at all. As noted in 
the Proposed Rule (81 FR 11066), we will take into consideration 
customers' responses (e.g., the customer declines or postpones the 
correction or signs a release of obligation, which may be the result of 
a financial settlement) when we determine whether a health IT developer 
has demonstrated that appropriate remediation has been provided to all 
affected customers.
    We clarify that ONC has sole discretion to lift a Certification 
Ban. The Certification Ban shall remain in effect until ONC is 
satisfied that the health IT developer has taken the required steps to 
lift the Certification Ban, as described above. If ONC chooses not to 
lift the Certification Ban, the health IT developer may reapply for 
reinstatement after taking the necessary actions to address the 
conditions for reinstatement.
    Comments. Commenters requested clarification regarding what would 
be tested and certified upon applying for ``recertification.''
    Response. As part of ONC's considerations as to whether to lift the 
Certification Ban, ONC, or a third party acting on its behalf, may 
require the health IT presented as replacement certified health IT for 
affected customers to be tested by an ONC-ATL, particularly if the 
replacement health IT is a version of the health IT that previously had 
the non-conformity that led to termination or withdrawal. This may also 
be the case when one of multiple Health IT Modules used to maintain the 
same scope of the terminated or withdrawn certified health IT was never 
the subject of ONC direct review or ONC-ACB surveillance but includes 
the same capabilities that were connected to the non-conformity (e.g., 
CPOE capabilities). After passing necessary testing, the health IT 
could be certified by an ONC-ACB.
    Comments. A commenter recommended that a health IT developer be 
required to provide their customer list to ONC and ONC could verify 
that the correction has been completed for a random selection of users. 
This commenter also suggested that ONC could alternatively rely on the 
health IT developer to attest that all installed products have been 
corrected or are available to users.
    Response. We agree with the commenter that either approach could be 
used by ONC to verify that appropriate remediation has been provided 
for all affected customers. However, as noted above, we will require 
the health IT developer to demonstrate that all affected customers have 
been provided with appropriate remediation, which would include listing 
the form of remediation. We may also randomly or methodically verify 
this information with affected customers.
Heightened Scrutiny
    Comments. A few commenters recommended that heightened scrutiny 
only apply to the functionality that was subject of the alleged non-
conformity and not to all health IT of a health IT developer. Some 
commenters requested that we further define heightened scrutiny. A 
couple of commenters suggested that heightened scrutiny should vary 
based on the scope of the non-conformity. One commenter supported using 
multiple forms of heightened scrutiny, including in-the-field 
surveillance. Two commenters recommended going beyond randomized in-
the-field surveillance where the health IT developer would be 
surveilled more frequently.
    We received mixed comments as to the length of heightened scrutiny. 
Some commenters recommended six months, while others recommended one 
year.
    Response. We have not finalized our proposal for applying 
heightened scrutiny at this time because, after consideration of the 
public comments, we believe that existing procedures already adequately 
result in ``heightened scrutiny,'' where appropriate. As noted above, 
it is possible that remediation for customers affected by a termination 
or withdrawal could consist of providing certified health IT that never 
had a non-conformity. In such instances, there would be no need for any 
form of heightened scrutiny. Further and again as noted above, the 
process of reinstatement will provide an opportunity for ONC to 
scrutinize any health IT presented for recertification. We also believe 
that surveillance conducted by ONC-ACBs as part of their routine 
activities can provide additional scrutiny of ``recertified'' health 
IT. To this point, ONC-ACBs conducting reactive surveillance (e.g., 
complaints-based) can take into account whether the health IT at issue 
was ``recertified'' health IT and whether the nature of the complaint 
correlates with a prior non-conformity found in the health IT. As for 
in-the-field surveillance, it could be weighted towards health IT that 
was ``recertified.''
    We note that we have added an element to a CAP that addresses steps 
to prevent a non-conformity from re-occurring (see the ``Corrective 
Action'' section earlier in this final rule).
(2) ONC-ACB Response to a Non-Conformity
    We stated in the Proposed Rule that ONC-ACBs are accredited to ISO/
IEC 17065. Section 7.11.1 of ISO/IEC 17065 instructs certification 
bodies to consider and decide upon the appropriate action to address a 
non-conformity found, through surveillance or otherwise, in the product 
the certification body certified.\17\ Section 7.11.1 lists, among other 
appropriate actions, the reduction in scope of certification to remove 
non-conforming product variants or withdrawal of the certification. We 
stated in the Proposed Rule that these are not appropriate responses to 
a non-conformity under the Program.
---------------------------------------------------------------------------

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

    We proposed in Sec.  170.523 to revise the PoPC for ONC-ACBs, to 
prohibit

[[Page 72445]]

ONC-ACBs from reducing the scope of a certification when the health IT 
is under surveillance or a CAP. The proposed revision addressed two 
situations: (1) When health IT is suspected of a non-conformity (i.e., 
under surveillance or surveillance is pending); and (2) when health IT 
has a non-conformity (i.e., under a CAP). We proposed that a health IT 
developer's withdrawal of its certified health IT from the Program when 
the certified health IT is under surveillance, or surveillance is 
pending, by an ONC-ACB should not be without prejudice (i.e., the 
health IT developer would be subject to a ``Certification Ban'' of its 
health IT). We further proposed that the same proposed consequences for 
health IT and health IT developers related to certification termination 
under ONC direct review (i.e., all of the Sec.  170.581 proposals) 
should apply to certification withdrawals issued by ONC-ACBs. We 
requested comment on these proposals.
Reduction in Scope
    Comments. Some commenters opposed the proposed requirement to 
maintain the scope of a certification when the health IT is under 
surveillance or a CAP, while a few commenters supported our proposal. 
One commenter stated that they believe these requirements could 
potentially be too prescriptive and could stifle innovation among 
health IT developers. However, another commenter stated that providers 
rely on their certified health IT to provide the functionality as 
represented to them both in general and for the EHR Incentive Programs 
and allowing a reduction in scope of certification to remove non-
conforming product variants after implementation unfairly penalizes 
providers.
    Response. We thank commenters for their feedback. To ensure 
alignment between ONC review and actions and ONC-ACBs' surveillance and 
actions under the Program, we have finalized our proposal in Sec.  
170.523(o) to prohibit the reduction in scope of certified health IT 
(1) when the certified health IT is suspected of a non-conformity 
(i.e., under surveillance or surveillance is pending); and (2) when 
health IT has a non-conformity (i.e., under a CAP). We agree with 
commenters that, as we stated in the Proposed Rule, a reduction in 
scope would absolve a health IT developer from correcting a non-
conformity. Health IT is tested and certified to meet adopted criteria 
and requirements. It should continue to meet those criteria and 
requirements when implemented. If not, the health IT developer should 
correct the health IT for affected customers or be subjected to 
certification withdrawal. While we expect that health IT developers 
would correct the non-conformity in most cases, we do permit various 
options for health IT developers to address the situation if the health 
IT certification is withdrawn.\18\ Therefore, we do not agree that the 
approach is overly prescriptive or that it will stifle innovation.
---------------------------------------------------------------------------

    \18\ Please also see the options for health IT developers to 
address certification termination/withdrawal discussed under the 
``Certification Ban'' section of the preamble above.
---------------------------------------------------------------------------

Voluntary Withdrawal When Suspected of a Non-Conformity
    Comments. One commenter stated that voluntary withdrawal by a 
health IT developer might be the most satisfactory action to enable the 
majority of the health IT to remain viable in the marketplace. Two 
commenters recommended that we state that a health IT developer's 
withdrawal of its certified health IT from the Program constitutes an 
admission of non-conformity.
    Response. We thank commenters for their feedback. We agree with the 
commenters that a health IT developer's withdrawal of its certified 
health IT from the Program could be utilized to avoid a finding of non-
conformity. Therefore, we have finalized the proposed consequences for 
a health IT developer's withdrawal of its certified health IT from the 
Program when the health IT is suspected of a non-conformity (i.e., 
under surveillance or surveillance is pending) by an ONC-ACB. 
Specifically, a health IT developer's health IT would be subject to a 
Certification Ban as discussed under the ``Certification Ban'' section 
of the preamble above.
Application of Sec.  170.581 to Certification Withdrawals Executed by 
ONC-ACBs
    We have finalized the proposed ``Program Ban'' (now called 
``Certification Ban''), including application to certification 
withdrawals executed by ONC-ACBs. We refer readers to the 
``Certification Ban, Recertification, and Heightened Scrutiny'' section 
above for the comments we received on these proposals and the revisions 
we have made in response to comments.
2. Establishing ONC Authorization for Testing Labs Under the Program; 
Requirements for ONC-ATL Conduct; and ONC Oversight and Processes for 
ONC-ATLs
a. General Comments on ONC-ATL Approach
    Comments. Commenters overwhelmingly supported the proposals to 
establish ONC-ATLs and provide for ONC oversight of ONC-ATLs under the 
Program. Two commenters stated that they do not support ONC 
accreditation in addition to current NVLAP accreditation, but expressed 
support for establishing ``ONC administrative controls'' over the 
accredited testing labs similar to ONC's oversight of the ONC-ACBs. 
Some commenters recommended that we include more robust testing or 
consider outlining a testing framework with appropriate testing 
methodologies to be utilized by ONC-ATLs.
    Response. We thank commenters for their support and have finalized 
the requirements for ONC-ATL status and the framework for ONC oversight 
of ONC-ATLs under the Program. In response to the two commenters 
stating that they do not support ``ONC accreditation'' in addition to 
current NVLAP accreditation, we believe these commenters misinterpreted 
our proposals as we did not propose any additional ONC accreditation 
requirements. To clarify, the proposals being finalized in this final 
rule do not require labs applying for ONC-ATL status to obtain 
additional accreditation beyond NVLAP accreditation for health IT 
testing. Further, these new provisions are in line with the commenters' 
recommendations by providing ONC with ``administrative controls'' over 
ONC-ATLs in a manner similar to ONC-ACBs by enabling ONC to authorize 
and have oversight of ONC-ATLs under the Program. We appreciate 
commenters' recommendations regarding more robust testing and testing 
frameworks, however, these recommendations are outside the scope of our 
proposals.
b. Regulatory Provisions for Inclusion of ONC-ATLs in the Program
    The following sections detail each new and amended regulatory 
provision that we proposed and have finalized for subpart E of part 
170, starting with 45 CFR 170.501, in order to include ONC-ATLs as part 
of the Program. As stated as our intention in the Proposed Rule, for 
authorization and other processes, we have followed and leveraged all 
of the processes established for ONC-ACBs.

[[Page 72446]]

(1) Sec.  170.501 ``Applicability''
    We proposed to revise paragraph (a) of Sec.  170.501 to include 
references to ``applicants for ONC-ATL status,'' ``ONC-ATL,'' and 
``ONC-ATL status.''
    Comments. Commenters expressed support for the proposed revisions.
    Response. We thank commenters for their support and have adopted 
the revisions to Sec.  170.501 as proposed. The revisions make clear 
that ONC-ATLs are now part of the rules under this subpart. We have 
also revised Sec.  170.501 to clearly state that this subpart includes 
requirements related to the direct review processes adopted in this 
final rule. These references were inadvertently left out of Sec.  
170.501 in the Proposed Rule, although they were included elsewhere in 
the preamble discussion and regulation text. Further, we revised Sec.  
170.501 to clarify that accreditation organizations only apply to 
become an ONC-AA under the Program and not the accreditor for testing 
under the Program. NVLAP is the permanent accreditor for testing under 
the Program (see 76 FR 1278). For regulatory clarity, we have 
reorganized the prior provisions and new provisions into four 
paragraphs.
(2) Sec.  170.502 ``Definitions''
    We proposed to revise the definition of the term ``applicant,'' in 
Sec.  170.502, to include a corresponding reference to ONC-ATL in order 
for such term to have equal meaning in the case of a testing lab that 
is applying for ONC-ATL status.
    We proposed to revise the definition of the term ``gap 
certification,'' in Sec.  170.502, to include a corresponding reference 
to ONC-ATL in paragraph (1) of that definition in order to give equal 
weight to test results issued by an ONC-ATL. We also proposed to add 
``under the ONC Health IT Certification Program'' to paragraphs (1) and 
(2) of the definition to improve the clarity of the definition.
    We proposed in Sec.  170.502 to define the term ``ONC-Authorized 
Testing Lab'' or ``ONC-ATL'' to mean an organization or consortium of 
organizations that has applied to and been authorized by the National 
Coordinator to perform the testing of Complete EHRs and Health IT 
Modules to certification criteria adopted by the Secretary in subpart C 
of this part.
    Comments. Commenters expressed support for the proposed revisions 
and additions to Sec.  170.502.
    Response. We thank commenters for their support and have finalized 
the revisions and additions to Sec.  170.502 as proposed.
(3) Sec.  170.505 ``Correspondence''
    We proposed to revise Sec.  170.505 to include references to ONC-
ATL as appropriate.
    Comments. Commenters expressed support for the proposed revisions 
to this section.
    Response. We thank commenters for their support and have finalized 
the revisions to Sec.  170.505 as proposed. This will reflect the 
addition of an applicant for ONC-ATL status and ONC-ATLs to the Program 
framework. We also refer readers to section II.A.1.c (``Review 
Processes'') for further revisions to Sec.  170.505 finalized in this 
final rule.
(4) Sec.  170.510 ``Type of Certification''
    We proposed to revise the section heading of Sec.  170.510 to 
specifically reference the authorization scope of ONC-ACB status. We 
also proposed to revise the introductory text within this section to 
more clearly convey that this section is solely focused on applicants 
for ONC-ACB status.
    Comments. Commenters expressed support for the proposed revisions.
    Response. We thank commenters for their support and have finalized 
the revisions to Sec.  170.510 as proposed.
(5) Sec.  170.511 ``Authorization Scope for ONC-ATL Status''
    We proposed to establish a new section (Sec.  170.511) to clearly 
define the scope of the authorization an ``applicant'' testing lab may 
be able to seek from the National Coordinator. We proposed that such 
authorization be limited to the certification criteria adopted by the 
Secretary in subpart C of this part. We proposed that an applicant for 
ONC-ATL status could seek for the scope of its authorization all 
certification criteria, a subset of all of the certification criteria 
(e.g., to support only privacy and security testing), one certification 
criterion, or a portion of one certification criterion. We stated that 
the latter two options provide opportunities for entities that may 
perform industry testing of health IT for limited and/or distinct 
capabilities (e.g., electronic prescribing) that align with 
certification criteria to participate in the Program.
    Comments. Commenters expressed support for the new proposed section 
for ONC-ATLs. Some commenters recommended ONC permit the acceptance of 
certification results from an organization that has already performed 
testing and certification of health IT that are aligned with, or could 
be aligned with, ONC certification criteria.
    Response. We thank commenters for their support for the new section 
and have finalized the section as proposed to support specialized 
testing and testing efficiencies for health IT. We stated in the 
Permanent Certification Program final rule, in response to comments, 
that we did not believe it was appropriate to rely on testing results 
from laboratories that were not NVLAP-accredited as we could not 
independently verify the accreditation processes for the testing labs 
(76 FR 1281). We believe our approach of requiring narrowly scoped 
NVLAP accreditation and ONC-ATL status for limited testing under the 
Program (e.g., e-prescribing) provides the efficiencies (i.e., avoid 
duplicative testing and reduces regulatory burden) that commenters 
requested, while maintaining ONC oversight and the integrity of 
certified health IT and the Program.
(6) Sec.  170.520 ``Application''
    We proposed to reorder the regulatory text hierarchy to reference 
the ONC-ACB application requirements under Sec.  170.520(a) and then 
the ONC-ATL application requirements under Sec.  170.520(b). For the 
ONC-ATL requirements, we proposed that an ONC-ATL applicant would need 
to seek authorization based on the scope proposed in Sec.  170.511 and 
follow the proposed set of ONC-ATL application requirements. More 
specifically, we proposed that the application information include the 
same general identifying information as for ONC-ACB applicants; the 
same authorized representative designation; documentation that the 
applicant has been accredited by NVLAP to ISO/IEC 17025; and a written 
agreement executed by the authorized representative stating that the 
applicant will adhere to the PoPC for ONC-ATLs.
    Comments. Commenters expressed support for the ONC-ATL application 
requirements. Some commenters noted that NVLAP bases its accreditation 
of testing labs under the Program on both ISO/IEC 17025 and elements 
specific to the Program (e.g., test procedure requirements and 
competencies). One commenter requested that we establish a minimum set 
of testing documentation for test results. This commenter also 
requested that we require ONC-ATLs to submit a list of all received 
complaints on a quarterly basis, which would be the same as the 
requirement for ONC-ACBs.
    Response. We thank commenters for their support and have finalized 
the ONC-ATL application requirements with one clarification based on 
the comments received. We clarify that ``documentation that confirms 
that the applicant has been accredited by

[[Page 72447]]

NVLAP to ISO/IEC 17025'' includes accreditation by NVLAP to health IT 
competencies and other Program-specific requirements as noted by 
commenters. To provide this clarity in Sec.  170.520, we have revised 
paragraph (b)(3) to read ``documentation that confirms that the 
applicant has been accredited by NVLAP, including to ISO/IEC 17025.'' 
To ensure uniformity, ONC, NVLAP, the ONC-AA, ONC-ACBs, and accredited 
testing labs have collaborated and agreed upon a minimum set of 
documentation that ONC-ATLs shall provide the ONC-ACBs for their 
certification evaluation, review, and decision. Last, we note that the 
recommendation to require ONC-ATLs to submit quarterly reports on 
complaints is outside of the scope of our proposals as we did not 
propose such a requirement for ONC-ATLs as we did for ONC-ACBs in the 
2015 Edition proposed rule.
(7) Sec.  170.523 ``Principles of Proper Conduct for ONC-ACBs''
    We proposed to revise paragraph (h)(1) of Sec.  170.523 to 
explicitly include ONC-ATLs as an entity from whom ONC-ACBs would 
receive test results. We further proposed to modify paragraph (h)(2) of 
Sec.  170.523 to include a six month time window from the authorization 
of the first ONC-ATL to permit the continued acceptance by ONC-ACBs of 
any test results from a NVLAP-accredited testing laboratory. As stated 
in the Proposed Rule, this approach would provide adequate transition 
time for ONC-ACBs to continue issuing certifications based on test 
results for new and revised certification criteria issued by a ``NVLAP-
accredited testing laboratory'' and would also serve as a mobilizing 
date for a testing lab that has not yet applied for ONC-ATL status. We 
requested comment, however, on the transition period from NVLAP-
accredited testing laboratories to ONC-ATLs. Specifically, we requested 
comment on whether we should alternatively establish that ONC-ACBs may 
only be permitted to accept any test results from a NVLAP-accredited 
testing laboratory for a period of time from the effective date of a 
subsequent final rule. We stated that this approach would provide a 
more certain timetable for ONC-ACBs compared to the proposed approach, 
but may not provide sufficient time for all NVLAP-accredited testing 
laboratories to transition to ONC-ATL status. We also requested comment 
on whether the transition period should be shorter than six months 
(e.g., three months) or longer (e.g., nine months) under either the 
proposed approach or the alternative approach.
    We proposed in Sec.  170.523(h)(2) to permit the use of test 
results from a NVLAP-accredited testing laboratory for certifying 
previously certified health IT to unchanged certification criteria (gap 
certification) because, as proposed, NVLAP-accredited testing 
laboratories would be replaced with ONC-ATLs. We stated that this 
proposal would permit the test results issued by NVLAP-accredited 
testing laboratories under the Program (e.g., test results for health 
IT tested to the 2014 Edition) to continue to be used for gap 
certification. As a related proposal, we proposed to remove references 
to ONC-ATCBs in Sec.  170.523(h). ONC-ATCBs tested and certified health 
IT to the 2011 Edition. The 2011 Edition has been removed from the Code 
of Federal Regulations and ONC-ACBs no longer maintain active 
certifications for health IT certified to the 2011 Edition.
    Comments. Commenters expressed support for our proposed revisions 
to Sec.  170.523 to accommodate inclusion of ONC-ATLs in the Program. 
One commenter commented on the proposed accredited testing lab to ONC-
ATL transition timeframe. The commenter recommended that we adopt a 
specified timeframe from the effective date of this final rule for 
NVLAP-accredited testing labs to become authorized as ONC-ATLs rather 
than a six-month timeframe from the authorization of the first ONC-ATL. 
Another commenter stated that the removal of reference to ONC-ATCBs 
could imply that gap certification is not permitted based on the use of 
test results from a 2011 Edition certification issued by an ONC-ATCB. 
The commenter recommended that we clarify whether test results used for 
2011 Edition certified health IT could be used for the purposes of gap 
certification.
    Response. We appreciate commenters' support for our proposed 
revisions to Sec.  170.523 and have finalized our revisions to include 
ONC-ATLs and remove references to ONC-ATCBs from the section. We agree 
with the commenter that the best approach to meet our goal stated in 
the Proposed Rule of establishing a certain timetable to facilitate the 
transition for accredited testing labs to ONC-ATLs would be to set a 
timeframe from the effective date of this final rule for the 
transition. Therefore, we have established a timeframe of ``six months 
from the effective date of this final rule'' to provide a more certain 
timeframe. We believe this timeframe, over eight months from the 
issuance of this final rule, provides sufficient time to account for 
any potential delays or unforeseen circumstances (e.g., time and 
resource conflicts with significant requests for 2015 Edition testing 
and certification by health IT developers).
    The removal of reference to ONC-ATCBs was not meant to imply that 
gap certification is not permitted based on the use of test results 
from a 2011 Edition certification issued by an ONC-ATCB. Therefore, we 
have revised the regulation text to add back in specific reference to 
ONC-ATCBs in Sec.  170.523(h)(3). We believe this step will 
sufficiently clarify that these test results may still be used for gap 
certification. We emphasize, however, that granting gap certification 
has always been at the discretion of an ONC-ACB. We would, however, 
expect that an ONC-ACB would consider the temporal nature of test 
results and other relevant changes in the health IT brought forward for 
gap certification when determining whether to grant gap certification.
(8) Sec.  170.524 ``Principles of Proper Conduct for ONC-ATLs''
    We proposed to establish, in a new section (Sec.  170.524), a set 
of PoPC to which ONC-ATLs must adhere, which are similar to the set of 
rules and conditions for ONC-ACBs. We stated that adherence to these 
conduct requirements would be necessary for ONC-ATLs to maintain their 
authorization and to remain in good standing under the Program. As 
outlined and described in the Proposed Rule, many of the proposed PoPC 
for ONC-ATLs would remain consistent with those to which ONC-ACBs are 
already required to adhere.
    Comments. Commenters expressed support for the new PoPC for ONC-
ATLs.
    Response. We thank commenters for their support and have adopted 
the new PoPC for ONC-ATLs in Sec.  170.524. Consistent with the 
clarification we provided for Sec.  170.520, we clarify that the 
requirement to maintain ``NVLAP accreditation to ISO/IEC 17025'' 
entails more than just accreditation to ISO/IEC 17025 as NVLAP 
accredits testing labs to other requirements under the Program. To 
provide this clarity in Sec.  170.524, we have revised paragraph (a) to 
read ``Maintain its NVLAP accreditation, including accreditation to 
ISO/IEC 17025.''
    Comments. One commenter stated, in regard to the proposed PoPC 
allowing ONC to periodically observe testing on site (unannounced or 
scheduled), that it would be more efficient for ONC staff to try and 
coordinate with the ONC-ATL for on-site visits since each testing

[[Page 72448]]

session involves a significant amount of coordination and scheduling.
    Response. We appreciate the commenter's point, but have retained 
the discretion in the final PoPC to observe, unannounced, on-site 
health IT testing. As with the PoPC for ONC-ACBs, we believe the 
prospect of unannounced visits supports Program compliance monitoring 
and the overall integrity of the Program. We note, however, that we 
intend to work with ONC-ATLs, as we do with ONC-ACBs, to provide the 
necessary notice to conduct useful and efficient on-site observation of 
health IT testing.
(9) Sec.  170.525 ``Application Submission''
    We proposed to include reference to an applicant for ONC-ATL status 
in paragraphs (a) and (b) of Sec.  170.525 to clearly recognize that 
testing labs would be applying for ONC-ATL status. We proposed the same 
application rules that apply to applicants for ONC-ACB status.
    Comments. Commenters expressed support for the proposed addition to 
this section.
    Response. We thank commenters for their support and have finalized 
the inclusion of ``an applicant for ONC-ATL status'' in Sec.  170.525 
as proposed.
(10) Sec.  170.530 ``Review of Application''
    We proposed to revise paragraphs (c)(2), (c)(4), (d)(2), and (d)(3) 
of Sec.  170.530 to include an ONC-ATL as part of the application 
review process. Further, in so doing, we proposed to follow all of the 
same application review steps and processes that we follow for 
applicants for ONC-ACB status.
    Comments. Commenters expressed support for the proposed revisions 
to this section.
    Response. We thank commenters for their support and have finalized 
the revisions to Sec.  170.530 as proposed.
(11) Sec.  170.535 ``ONC-ACB Application Reconsideration''
    We proposed to revise the section heading of Sec.  170.535 to 
include reference to ONC-ATLs. We also proposed to revise paragraphs 
(a) and (d)(1) of Sec.  170.535 to equally reference that an ONC-ATL 
could be part of the application reconsideration process. Further, in 
so doing, we proposed to follow all of the same application 
reconsideration steps and processes that we require and follow for 
applicants for ONC-ACB status.
    Comments. Commenters supported our proposed revisions to this 
section.
    Response. We thank commenters for their support and have finalized 
the revisions to Sec.  170.535 as proposed.
(12) Sec.  170.540 ``ONC-ACB Status''
    We proposed to revise the section heading of Sec.  170.540 to 
include reference to ONC-ATLs. We also proposed to revise paragraphs 
(a) through (d) of Sec.  170.540 to equally reference an ONC-ATL as 
part of the rules currently governing the achievement of ONC-ACB 
status. As stated in the Proposed Rule, these rules would include: The 
acknowledgement of ONC-ATL status; that an ONC-ATL must prominently and 
unambiguously identify the scope of its authorization; that ONC-ATL 
authorization must be renewed every three years; and that ONC-ATL 
status would expire three years from when it was granted unless 
renewed.
    Comments. Commenters supported our proposed revisions to this 
section.
    Response. We thank commenters for their support and have finalized 
the revisions to Sec.  170.540 as proposed.
(13) Sec.  170.557 ``Authorized Certification Methods''
    We proposed to revise the section heading of Sec.  170.557 to 
include a reference to ``testing.'' We also proposed to update the 
regulatory text hierarchy to have paragraph (a) be applicable to ONC-
ATLs and paragraph (b) be applicable to ONC-ACBs.
    Comments. Commenters expressed support for our proposed revisions 
to this section.
    Response. We thank commenters for their support and have finalized 
the proposed revisions to make Sec.  170.557 applicable to ONC-ATLs as 
we believe the requirement to provide for remote testing for both 
development and deployment sites is equally applicable to testing labs 
as it is to certification bodies.
(14) Sec.  170.560 ``Good Standing as an ONC-ACB''
    We proposed to revise the section heading of Sec.  170.560 to 
include reference to ONC-ATLs. We also proposed to revise the paragraph 
hierarchy to make the paragraph (a) requirements applicable to ONC-ACBs 
(without modification) and to make the paragraph (b) requirements 
applicable to ONC-ATLs following the same set of three requirements as 
for ONC-ACBs.
    Comments. Commenters supported our proposed revisions to the 
section.
    Response. We thank commenters for their support and have finalized 
the revisions to Sec.  170.560 as proposed. We believe mirroring the 
requirements of Sec.  170.560 between ONC-ACBs and ONC-ATLs provides 
for consistent administration for both testing and certification under 
the Program.
(15) Sec.  170.565 ``Revocation of ONC-ACB Status''
    We proposed to revise the section heading of Sec.  170.565 to 
include reference to ONC-ATLs. We also proposed to revise paragraphs 
(a) through (h) to include references to an ONC-ATL, as applicable. We 
proposed to apply the same oversight paradigm of Type-1 and Type-2 \19\ 
violations to ONC-ATLs as we apply to ONC-ACBs. We further proposed to 
follow the same process for ONC-ATLs that is already included in this 
section for ONC-ACBs. We proposed to specifically add paragraph 
(d)(1)(iii) for ONC-ATL suspension provisions because the suspension 
provisions in paragraph (d)(1)(ii) are too specific to ONC-ACBs and 
simply referencing ONC-ATLs in that paragraph would cause confusion. 
Similarly, we proposed to specifically add paragraph (h)(3) related to 
the extent and duration of revocation to clearly divide the rules 
applicable to ONC-ACBs from those that would be applicable to ONC-ATLs. 
We explained that this proposed revision would place the current ONC-
ACB applicable regulation text in paragraph (h)(2) of this section.
---------------------------------------------------------------------------

    \19\ Type-2 violations constitute non-compliance with 45 CFR 
170.560 (Good standing as an ONC-ACB) (45 CFR 170.565(b)). An ONC-
ACB must maintain good standing by: (a) Adhering to the Principles 
of Proper Conduct for ONC-ACBs; (b) Refraining from engaging in 
other types of inappropriate behavior, including an ONC-ACB 
misrepresenting the scope of its authorization, as well as an ONC-
ACB certifying Complete EHRs and/or Health IT Module(s) for which it 
does not have authorization; and (c) Following all other applicable 
federal and state laws.
---------------------------------------------------------------------------

    Comments. Commenters expressed support for the proposed revisions 
and additions to this section. One commenter requested clarification as 
to whether the timeframes proposed referenced calendar or business 
days. Another commenter stated that requiring an ONC-ATL or ONC-ACB to 
submit a written response within three days upon receipt of a notice of 
proposed suspension seems short since the National Coordinator has five 
days to respond to an ONC-ATL or ONC-ACB's written response to a notice 
of proposed suspension.
    Response. We thank commenters for their support and have finalized 
the revisions and additions to Sec.  170.565 as proposed. Our approach 
will enable ONC to treat similar fact-based non-compliance situations 
equitably among ONC-ACBs and ONC-ATLs. In regard

[[Page 72449]]

to the requested clarification for the use of ``days,'' we previously 
adopted the definition of ``day'' or ``days'' in Sec.  170.102 to mean 
``calendar day'' or ``calendar days'' (Temporary Certification Program 
final rule; 75 FR 36162, 36203). As stated in the Permanent 
Certification Program final rule, we believe suspension could be an 
effective way to protect purchasers of certified products and ensure 
patient health and safety. The requirements for an ONC-ATL or ONC-ACB 
to submit a written response to a proposed suspension within three days 
supports this goal, while still giving ONC-ACBs and ONC-ATLs an 
opportunity to respond. The National Coordinator has an additional two 
days to be able to consider the ONC-ATL or ONC-ACB response in 
conjunction with the reasons for proposing the suspension.
(16) Sec.  170.570 Effect of Revocation on the Certifications Issued To 
Complete EHRs and Health IT Module(s)
    We explained in the Proposed Rule that Sec.  170.570 specifies 
rules applicable to certifications issued to Complete EHRs and/or 
Health IT Modules in the event that an ONC-ACB has had its status 
revoked. Section 170.570 includes steps that the National Coordinator 
can follow if a Type-1 violation occurred that called into question the 
legitimacy of certifications conducted by the former ONC-ACB. These 
provisions were put in place to provide clarity to the market about the 
impact that an ONC-ACB's status revocation would have on certified 
health IT in use as part of the EHR Incentive Programs.
    In the context of an ONC-ATL having its status revoked, we did not 
specifically propose to modify Sec.  170.570 to include a set of rules 
applicable to such a scenario. We stated that the same provisions were 
not necessary given the tangible differences between test results for a 
not yet certified Complete EHR and/or Health IT Module and an issued 
certification being used by hundreds or thousands of providers for 
participation in other programs, HHS or otherwise. We did, however, 
request comment on whether there would be any circumstances in which 
additional clarity around the viability of test results attributed to a 
not yet certified Complete EHR and/or Health IT Module would be 
necessary. We also requested comment as to whether we should include 
provisions similar to those already in this section to account for an 
instance where an ONC-ATL has its status revoked as a result of a Type-
1 violation, which calls into question the legitimacy of the test 
results the ONC-ATL issued and, thus, could call into question the 
legitimacy of the subsequent certifications issued to Complete EHRs 
and/or Health IT Modules by a potentially unknowing or deceived ONC-
ACB.
    Comments. The majority of commenters agreed that Sec.  170.570 did 
not need to be modified for a Complete EHR and/or Health IT Module not 
yet certified. Commenters stated that if a Complete EHR and/or Health 
IT Module had not yet been certified and its testing lab had its status 
revoked, the health IT developer could find another testing lab to 
complete its testing before certification. A couple of commenters 
recommended additional provisions for situations where an ONC-ATL is 
suspended for Type-1 violations (fraud or negligence) affecting the 
validity of the test results, but not for non-test-related issues (e.g. 
business practices or failure to report to ONC) that could also cause 
an ONC-ATL to have its status revoked. Several commenters also 
requested that we clarify how the National Coordinator would apply 
recertification requirements for ONC-ATL or ONC-ACB revocation due to a 
Type-2 violation.
    Response. We thank commenters for their feedback. While we did not 
specifically propose to modify Sec.  [thinsp]170.570 to include a set 
of rules applicable to an ONC-ATL having its status revoked, we did 
request comment on modifying Sec.  170.570 to account for situations 
where an ONC-ATL has its status revoked as a result of a Type-1 
violation, which calls into question the legitimacy of the test results 
the ONC-ATL issued and, thus, could call into question the legitimacy 
of the subsequent certifications issued to Complete EHRs and/or Health 
IT Modules by a potentially unknowing or deceived ONC-ACB. Given the 
feedback from commenters expressing the need for provisions to address 
certifications when ONC revokes an ONC-ATL's status and also determines 
that the test results are unreliable because of fraud or negligence or 
for other reasons that call into question the legitimacy of the test 
results the ONC-ATL issued, we have revised Sec.  170.570 to address 
these situations.
    We note that Sec.  170.570 does not include the review of health IT 
certifications by the National Coordinator due to the revocation of 
ONC-ATL or ONC-ACB status for Type-2 violations. Under this section, 
the review of health IT certifications by the National Coordinator is 
limited to revocations based on a ``Type 1 violation that called into 
question the legitimacy of certifications issued to health IT.''
    Comments. Several commenters requested clarification on how the 
National Coordinator would make an assessment on whether a health IT 
was ``improperly certified.'' Commenters also requested that ONC 
evaluate the likelihood that remaining ONC-ACBs would be able to 
accommodate all requests for recertification within the specified 120-
day time period under Sec.  170.570, noting that ONC-ACBs do not always 
have tremendous flexibility to schedule around other obligations, 
particularly during busy certification periods.
    Response. As specified in Sec.  170.570, the National Coordinator 
would review the facts surrounding the revocation and publish a notice 
on ONC's Web site if it was determined that Complete EHRs and/or Health 
IT Module(s) were ``improperly certified.'' We anticipate that this 
review would be case-specific and dependent on the basis of the 
revocation. To note, we have revised the regulation text to replace 
``improperly certified'' with more accurate terminology. We believe use 
of ``unreliable testing or certification'' is more accurate and 
provides clarity for the situations under review as compared to 
``improperly tested'' or ``improperly certified,'' particularly in 
situations where an ONC-ACB unknowingly uses unreliable test results.
    In the Permanent Certification Program final rule (76 FR 1299-
1300), we stated that programmatic steps, such as identifying ONC-
ACB(s) that could be used for recertification, could be taken to assist 
health IT developers with achieving timely and cost effective 
recertifications. However, based on our accumulated knowledge of the 
time it takes for testing and certification under the Program and in 
response to comments, we acknowledge that there may be circumstances 
where it may not be possible for ONC-ATLs to accommodate all requests 
for retesting, as necessary, and ONC-ACBs to accommodate all requests 
for recertification within the 120-day time period. Accordingly, we 
have revised Sec.  [thinsp]170.570 to permit the National Coordinator 
to extend the time that the certification status of affected Complete 
EHRs and/or Health IT Module(s) remains valid as necessary for the 
proper retesting and recertification of the affected health IT (see 
Sec.  170.570(c)(2)).

B. Public Availability of Identifiable Surveillance Results

    In the 2014 Edition final rule, for the purposes of increased 
Program

[[Page 72450]]

transparency, we instituted a requirement for the public posting of the 
test results used to certify health IT (77 FR 54271). We also 
instituted a requirement that a health IT developer publicly disclose 
any additional types of costs that a provider would incur for using the 
health IT developer's certified health IT to participate in the EHR 
Incentive Programs (77 FR 54273-74). Building on these transparency and 
public accountability requirements for health IT developers, we took 
steps, in the 2015 Edition final rule, to increase the transparency 
related to certified health IT through required surveillance, broadened 
certified health IT disclosure requirements, and enhanced reporting 
requirements (80 FR 62719-25). For instance, we now require ONC-ACBs to 
report non-conforming findings and, when necessary, CAP information to 
the publicly accessible CHPL (80 FR 62725). The purpose of this 
reporting requirement, as described in the 2015 Edition final rule, is 
to ensure that health IT users, implementers, and purchasers are 
alerted to conformity issues in a timely and effective manner, 
consistent with the patient safety, program integrity, and transparency 
objectives of the 2015 Edition final rule (80 FR 62716-17).
    In furtherance of our efforts to increase Program transparency and 
health IT developer accountability for their certified health IT we 
proposed in the Proposed Rule to revise Sec.  170.523(i) of the PoPC 
for ONC-ACBs by adding language that would require ONC-ACBs to make 
identifiable surveillance results publicly available on their Web sites 
on a quarterly basis. We stated that these surveillance results would 
include information such as, but may not be limited to: Names of health 
IT developers; names of products and versions; certification criteria 
and Program requirements surveilled; and outcomes of surveillance. We 
further stated that this information is already collected by ONC-ACBs 
as part of their surveillance efforts under the Program and should be 
readily available for posting on their Web sites (81 FR 11070).
    We clarified in the Proposed Rule that we do not require that 
publicly posted surveillance results include information that is 
proprietary, trade secret, or confidential (e.g., ``screenshots'' that 
may include such information). We noted our expectation that health IT 
developers and ONC-ACBs would ensure that such information is not 
posted when making available the proposed information (i.e., but not 
limited to, names of health IT developers; names of products and 
versions; certification criteria and Program requirements surveilled; 
and outcomes of surveillance).
    We requested public comment on the publication of identifiable 
surveillance results. Specifically, we requested comment on the types 
of information to include in the surveillance results and the format 
(e.g., summarized or unrefined surveillance results) that would be most 
useful to stakeholders. In addition to the proposal for ONC-ACBs to 
publish these results quarterly on their Web sites, we requested 
comment on the value of publishing hyperlinks on the ONC Web site to 
the surveillance results posted on the ONC-ACBs' Web sites (81 FR 
11070).
    Comments. We received overwhelming support for the publication of 
identifiable surveillance results by ONC-ACBs. A couple of commenters, 
however, questioned the benefit of posting conforming results, 
suggesting the number of results would be too low to be significant.
    Response. We appreciate commenters' support for the publication of 
identifiable surveillance results by ONC-ACBs and are finalizing our 
proposal to make identifiable surveillance results of ONC-ACBs publicly 
available according to the form, manner, and frequency discussed below. 
We emphasize that these surveillance results will consist of findings 
of conformity, which are not currently published on the CHPL.
    As we stated in the Proposed Rule, the publication of identifiable 
surveillance results with findings of conformity, much like the 
publication of non-conformities and CAPs on the CHPL under the 2015 
Edition final rule, will help make health IT developers more 
accountable to the customers and users of their certified health IT. 
Customers and users will be provided with valuable information about 
the continued performance (i.e., conformity under the Program) of 
certified health IT. The identifiable surveillance results will serve 
to inform providers and others currently using certified health IT as 
well as those that may consider switching their certified health IT or 
purchasing certified health IT for the first time. While we expect that 
the prospect of publicly identifiable surveillance results will 
motivate some health IT developers to improve their maintenance 
efforts, we continue to believe that published surveillance results 
will reassure customers and users of certified health IT that their 
health IT continues to conform to certification and Program 
requirements. This is because, based on ONC-ACB surveillance results to 
date, most of the surveilled certified health IT and health IT 
developers are maintaining conformity with certification criteria and 
Program requirements. The publishing of identifiable surveillance 
results will also provide a more complete context of surveillance in 
the certified health IT industry; rather than only sharing identifiable 
non-conforming results, and when applicable, CAPs (see Sec.  
170.523(f)).
    We disagree with the commenters that suggested there may be little 
value in posting identifiable surveillance results because the number 
of results will be too low to be of significance. Such surveillance 
results will include both reactive (e.g., complaints-based) and 
randomized surveillance results, which over time will establish a 
surveillance and conformity history of certified health IT.
    Comments. Commenters generally agreed with the proposed list of 
information to be included in publicly available surveillance results 
(i.e., the names of health IT developers; names of products and 
versions; certification criteria and Program requirements surveilled; 
and outcomes of surveillance). Several health IT developers suggested 
that the information listed for publication should be specifically 
limited to the information identified in the Proposed Rule, which 
should be a ``ceiling rather than a floor.'' Some commenters also 
recommended releasing the same type of surveillance results information 
that is required to be made public as part of CAPs under Sec.  
170.523(f)(1)(xxii). Commenters recommended this approach to ensure 
Program consistency, prevent interim work product or information 
obtained in the course of surveillance from being disclosed, and 
prevent the inclusion of proprietary or sensitive information.
    Most commenters recommended ONC-ACBs provide summary identifiable 
surveillance results. Some commenters cautioned that ONC-ACBs should 
clearly indicate that surveillance of specific certified health IT 
should not imply a problem or potential problem with the health IT. One 
commenter encouraged ONC to share model forms of how results would be 
published so that a common understanding of the form, content, and 
structure is established in advance of their publication. The same 
commenter also recommended that we engage in outreach with industry, 
providers, health IT developers, and public interest stakeholders to 
help them understand and interpret public surveillance information.

[[Page 72451]]

    Commenters expressed support for publishing hyperlinks on the ONC 
Web site to the quarterly identifiable surveillance results posted on 
the ONC-ACBs' Web sites. Several commenters also recommended posting 
the identifiable surveillance results on the CHPL, rather than having 
them spread across multiple ONC-ACB Web sites.
    Response. Based on the comments received and the goals of our 
proposal, as stated above and in the Proposed Rule, we have finalized 
our proposed approach with the following clarifications. This approach 
requires the public posting of the information specified in the 
Proposed Rule (81 FR 11070-71) and the relevant information already 
required to be posted, when appropriate, on the CHPL as part of a CAP 
(80 FR 62725). Specifically, the information required to be reported 
for all surveillance results under this final rule will include: The 
names of health IT developers; names of products and versions; 
certification criteria and Program requirements surveilled; 
identification of the type of surveillance (i.e., reactive or 
randomized); the dates surveillance was initiated and completed; and 
the number of sites that were used in randomized surveillance. This 
information is consistent with the proposed information, the types of 
information already required to be posted for CAPs (which is more 
information than we have specified above for quarterly reporting of all 
identifiable surveillance results), and with commenter feedback.
    We did not specifically list the identification of the type of 
surveillance (i.e., reactive or randomized), dates the surveillance was 
initiated and completed, or the number of sites surveilled as types of 
information to be reported in the Proposed Rule. However, the Proposed 
Rule refers to ``continued performance,'' which requires the 
identification of the dates surveillance was conducted in order to 
measure performance over a period of time. Additionally, we believe 
information regarding whether the surveillance was reactive or random 
and the number of sites that were surveilled will be useful to 
stakeholders in understanding surveillance results.
    The Proposed Rule included the `outcome of surveillance' as a 
specific type of information, but we have determined that it is 
unnecessary. We note that the outcome of surveillance is implied by 
definition (surveillance results). Furthermore, outcomes that include 
identifiable non-conforming surveillance results are already required 
to be posted on the CHPL.
    We agree with commenters that requiring the surveillance 
information to be posted in one location will better serve 
stakeholders. Allowing ONC-ACBs to post identifiable surveillance 
results in different locations would create difficulties for 
stakeholders who would have to search all surveillance results across 
multiple ONC-ACBs' Web sites. Further, such an approach would not 
account for an ONC-ACB choosing to exit the Program. Alternatively, as 
commenters suggested, the CHPL would address these challenges and is 
consistent with our consideration in the Proposed Rule of having the 
hyperlinks on the ONC Web site as a means of providing stakeholders 
with a centralized and more readily available means for accessing the 
results. The CHPL is housed on the ONC Web site. The posting of 
surveillance results on the CHPL is responsive to commenter feedback 
and will prevent stakeholders from having to navigate multiple sites 
for the surveillance information. This approach will also decrease the 
burden for ONC-ACBs as they do not have to host and update the 
surveillance results on their own Web sites. To further reduce the 
burden for ONC-ACBs, we will also provide guidance to ONC-ACBs on how 
to most efficiently submit the information to the CHPL.
    As suggested by comments and consistent with our goal of making 
identifiable surveillance results accessible and useful to customers 
and other stakeholders, we are modifying the CHPL. For example, we 
intend to include a disclaimer clearly indicating that the fact that 
surveillance was done does not imply a problem with the health IT. 
However, we note that conducting surveillance is a Program requirement 
and a required responsibility of an ONC-ACB and it may or may not be 
based on information indicating a potential problem with the certified 
health IT. We will make clear that a search of a particular product 
listed on the CHPL returning no surveillance results would mean that 
the product has never been surveilled. We also plan to provide other 
guidance as necessary, such as an explanation of the differences 
between reactive and random surveillance.\20\
---------------------------------------------------------------------------

    \20\ Program guidance can be found on the ONC Web site at 
https://www.healthit.gov/policy-researchers-implementers/onc-health-it-certification-program-guidance.
---------------------------------------------------------------------------

    Comments. Commenters expressed support for our proposal to not 
require the inclusion of certain information that is proprietary, trade 
secret, or confidential. One commenter stated, however, that it was 
unclear as to who decides what information is proprietary or a trade 
secret and suggested that it should be ONC's sole decision and the only 
reasonable grounds for exclusion should be threats to patient 
confidentiality. Another commenter expressed concerns that it was 
unclear how ONC can balance the needs of health IT developers to 
protect their proprietary information with the desire to provide 
meaningful information related to surveillance of health IT.
    Response. We appreciate both the support and concerns raised by 
commenters. As discussed above, we have specified the types of 
surveillance results that must be submitted to the CHPL and made 
public. We do not believe that any of the required information would 
implicate the release of proprietary, trade secrets, or confidential 
information. Further, as noted in the Proposed Rule (81 FR 11063), we 
are confident that the concerns of commenters regarding the disclosure 
of proprietary or sensitive information will be adequately addressed 
through appropriate safeguards implemented at the discretion of ONC-
ACBs. ONC-ACBs have already been directly and effectively submitting 
data to the CHPL on certified health IT. They have demonstrated the 
capability, working with health IT developers, to submit the requisite 
information while protecting health IT developers' proprietary, trade 
secret, and confidential information. We expect this will continue with 
the surveillance results information that must be disclosed as a result 
of this new requirement. For a more detailed discussion of the 
safeguards ONC will implement for proprietary information, trade 
secrets, or confidential information, please see section II.A.1.c.(1), 
``Notice of Potential Non-Conformity or Non-Conformity,'' of this final 
rule.
    Comments. The majority of commenters expressed support for the 
proposal that identifiable surveillance results be posted quarterly. 
One commenter encouraged us to set the quarterly timeframe as a minimum 
threshold and to consider the value of more frequent publication, such 
as monthly.
    Response. We appreciate the comments in support of the proposed 
requirement that identifiable surveillance results be posted quarterly. 
We have adopted a quarterly posting requirement, as proposed, but with 
incorporation of the commenter's recommendation that quarterly posting 
be the minimum threshold. We believe that submission through the CHPL 
of the minimum set of data will support

[[Page 72452]]

the efficient submission of the additional surveillance results and the 
submission of the results with other data on certified health IT that 
is required to be submitted more frequently. This will enable ONC-ACBs 
to submit identifiable surveillance results more frequently if they are 
available and ready for submission.
    To provide sufficient time for implementation by ONC and the ONC-
ACBs, including necessary revisions to the CHPL to support user-
friendly display of the identifiable surveillance results, we 
anticipate that posting of the first identifiable surveillance results 
will occur by the end of the first quarter of 2017. This means the 
identifiable surveillance results for January through March of 2017 
would be posted no later than in early April of 2017. As a reminder, 
certain identifiable non-conforming surveillance results are already 
submitted to the CHPL on a weekly basis (see Sec.  170.523(f)). This 
requirement serves to provide consumers and end-users with prompt 
notification of non-conformities and corrective actions associated with 
certified health IT.
    Comments. A few commenters expressed concern that the cost estimate 
for ONC-ACBs to post all identifiable surveillance results seemed too 
low, unless there is almost no change to what ONC-ACBs are already 
doing. The commenters asserted that the volume of updates would be 
significantly higher than currently required because it would include 
both conforming and non-conforming results.
    Response. We appreciate the commenters' concerns. As discussed 
above, we believe that our adopted approach for making identifiable 
surveillance results public will be more efficient and less burdensome 
than proposed. We also refer readers to the ``Regulatory Impact 
Statement'' section of this final rule for our cost estimates for the 
reporting of identifiable surveillance results by ONC-ACBs.
    Comments. A few commenters recommended that we include additional 
functionality on our Web site (CHPL) so that stakeholders may 
specifically learn how certified health IT products support 
interoperability. Commenters asserted that visible, comparative 
information will give health IT developers an opportunity to understand 
where performance can be improved to support providers electronically 
exchange health information.
    Response. We appreciate the commenters' feedback and will consider 
the feedback as part of our efforts to support widespread 
interoperability and electronic health information exchange. While this 
comment is outside the scope of our proposal, we believe that the 
quarterly posting of identifiable surveillance results on the CHPL is 
consistent with the commenters' request. Further, the CHPL currently 
supports the searching and comparing of certified health IT based on 
certification criteria. For example, users can search certified health 
IT listed on the CHPL to determine which health IT is certified to the 
2015 Edition ``transitions of care'' certification criterion (Sec.  
170.315(b)(1)). This criterion and its included capabilities support 
interoperability.
Alignment of Sec.  170.556(e)(1) With Sec.  170.523(i)(2)
    We proposed to revise Sec.  170.556(e)(1) for clarity and 
consistency with Sec.  170.523(i)(2) by adding that the ongoing 
submission of in-the-field surveillance results to the National 
Coordinator throughout the calendar year must, at a minimum, be done on 
a quarterly basis.
    Comments. A few commenters suggested we adopt the same language in 
both Sec.  170.523(i)(2) and Sec.  170.556(e)(1), rather than saying 
both ``quarterly'' and ``rolling.''
    Response. We agree with comments and have revised Sec.  
170.556(e)(1) to be consistent with Sec.  170.523(i)(2) by stating that 
the results of in-the-field surveillance must be submitted to the 
National Coordinator, at a minimum, on a quarterly basis.
Annual Summative Report of Surveillance Results
    We proposed to reestablish a requirement that ONC-ACBs submit an 
annual summative report of surveillance results to the National 
Coordinator. We noted in the Proposed Rule that this previous 
requirement was unintentionally removed in the 2015 Edition final rule 
when we established a quarterly reporting requirement for surveillance 
results.
    Comments. One commenter stated that the annual summative report 
should function as a general overview of the surveillance activities 
and the quarterly report should contain more detailed findings.
    Response. We appreciate the feedback on this proposal and have 
finalized it as proposed. We intend to provide, as necessary, more 
specific guidance to ONC-ACBs on submitting the annual summative 
surveillance report.

III. National Technology Transfer and Advancement Act and the Office of 
Management and Budget Circular A-119

    The National Technology Transfer and Advancement Act (NTTAA) of 
1995 (15 U.S.C. 3701 et seq.) and the Office of Management and Budget 
(OMB) Circular A-119 \21\ require the use of, wherever practical, 
standards that are developed or adopted by voluntary consensus 
standards bodies to carry out policy objectives or activities, with 
certain exceptions. In the Proposed Rule, we proposed to ``adopt'' one 
voluntary consensus standard (ISO/IEC 17025) for use in the Program.
---------------------------------------------------------------------------

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

    Comments. We received no comments on the ISO/IEC 17025 standard as 
it relates to the NTTAA and OMB Circular A-119.
    Response. While we stated in the Proposed Rule that we proposed to 
``adopt'' ISO/IEC 17025, we clarify that we were not proposing to adopt 
the standard under our authorities for the purposes of certifying 
health IT. Rather, consistent with the stated purpose of our proposal 
provided in the Proposed Rule, we have finalized the use of the ISO/IEC 
17025 standard for the accreditation of testing laboratories in the 
Program. The use of this standard is consistent with the requirements 
of the NTTAA and OMB Circular A-119.

IV. Incorporation by Reference

    The Office of the Federal Register has established requirements for 
materials (e.g., standards and implementation specifications) that 
agencies incorporate by reference in the Federal Register (79 FR 66267; 
1 CFR 51.5(b)). Specifically, Sec.  51.5(b) requires agencies to 
discuss, in the preamble of a final rule, the ways that the materials 
they incorporate are reasonably available to interested parties and how 
interested parties can obtain the materials; and summarize, in the 
preamble of the final rule, the materials they incorporate by 
reference.
    Anyone may purchase the standard and we provide a uniform resource 
locator (URL) for the standard. As required by Sec.  51.5(b), we also 
provide a summary below of the standard we have adopted and incorporate 
by reference in the Federal Register.

ISO/IEC 17025:2005 General requirements for the competence of testing 
and calibration laboratories
    URL: ISO/IEC 17025:2005 (ISO/IEC 17025) is available for purchase 
on the ISO Web site at: http://www.iso.org/iso/catalogue_detail.htm?csnumber=39883.

[[Page 72453]]

    Summary: Accreditation bodies that recognize the competence of 
testing and calibration laboratories should use ISO/IEC 17025 as the 
basis for their accreditation. Clause 4 specifies the requirements for 
sound management. Clause 5 specifies the requirements for technical 
competence for the type of tests and/or calibrations the laboratory 
undertakes.
    The use of ISO/IEC 17025 will facilitate cooperation between 
laboratories and other bodies, and assist in the exchange of 
information and experience, and in the harmonization of standards and 
procedures.
    Comments. We received one comment supporting our proposal to use 
and incorporate by reference the ISO/IEC 17025 standard.
    Response. As noted under the NTTAA section above, we proposed to 
``adopt'' ISO/IEC 17025. However, we clarify that we were not proposing 
to adopt the standard under our authorities for the purposes of 
certifying health IT. Rather, consistent with the stated purpose of our 
proposal provided in the Proposed Rule, we have finalized the use of 
the ISO/IEC 17025 standard for the accreditation of testing 
laboratories in the Program and have also incorporated by reference the 
standard in the Federal Register.
Address Change
    We have updated the address for ONC in the ``incorporation by 
reference'' sections of the regulations at Sec. Sec.  170.299(a) and 
170.599(a) as ONC's address changed in 2015.
Reordering of Sec.  170.599(b)
    We have reordered the listing of standards in Sec.  170.599(b). 
This reordering is consistent with the procedures of the Office of the 
Federal Register, which dictate that standards should be listed by the 
alphanumeric ID (excluding the date) for each standard, and then by the 
standard date.

V. Collection of Information Requirements

    Under the Paperwork Reduction Act of 1995 (PRA), agencies are 
required to provide 60-day notice in the Federal Register and solicit 
public comment on a proposed collection of information before it is 
submitted to OMB for review and approval. In order to fairly evaluate 
whether an information collection should be approved by OMB, section 
3506(c)(2)(A) of the PRA requires that we solicit comment on the 
following issues:
    1. Whether the information collection is necessary and useful to 
carry out the proper functions of the agency;
    2. The accuracy of the agency's estimate of the information 
collection burden;
    3. The quality, utility, and clarity of the information to be 
collected; and
    4. Recommendations to minimize the information collection burden on 
the affected public, including automated collection techniques.
    We solicited comment on these issues in the Proposed Rule (81 FR 
11071-11072) for the matters discussed in detail below.

A. ONC-AA and ONC-ACBs

    Under the Program, accreditation organizations that wish to become 
the ONC-Approved Accreditor (ONC-AA) must submit certain information, 
organizations that wish to become an ONC-ACB must comply with 
collection and reporting requirements, and ONC-ACBs must comply with 
collection and reporting requirements, records retention requirements, 
and submit annual surveillance plans and annually report surveillance 
results. In the 2015 Edition proposed rule (80 FR 16894), we estimated 
fewer than ten annual respondents for all of the regulatory 
``collection of information'' requirements that applied to the ONC-AA 
and ONC-ACBs, including those previously approved by OMB. In the 2015 
Edition final rule (80 FR 62733), we concluded that the regulatory 
``collection of information'' requirements for the ONC-AA and the ONC-
ACBs were not subject to the PRA under 5 CFR 1320.3(c). We further note 
that the PRA (44 U.S.C. 3518(c)(1)(B)(ii)) exempts the information 
collections specified in 45 CFR 170.565 that apply to ONC-ACBs, which 
are collection activities that would occur during administrative 
actions or investigations involving ONC against an ONC-ACB.
    Comments. We received no comments specific to the ONC-AA and ONC-
ACBs regarding the ``collection of information'' requirements 
applicable to them or our past determinations.
    Response. We continue to maintain our past determinations in that 
we estimate fewer than ten annual respondents for all of the regulatory 
``collection of information'' requirements that apply to the ONC-AA and 
ONC-ACBs and that the ``collection of information'' requirements for 
the ONC-AA and the ONC-ACBs are not subject to the PRA under 5 CFR 
1320.3(c). As previously noted, the PRA (44 U.S.C. 3518(c)(1)(B)(ii)) 
exempts the information collections specified in 45 CFR 170.565 that 
apply to ONC-ACBs, which are collection activities that would occur 
during administrative actions or investigations involving ONC against 
an ONC-ACB.

B. ONC-ATLs

    In the Proposed Rule, we estimated fewer than ten annual 
respondents for all of the proposed regulatory ``collection of 
information'' requirements for ONC-ATLs under Part 170 of Title 45. As 
stated in the Proposed Rule, for this reason, the regulatory 
``collection of information'' requirements for ONC-ATLs under the 
Program are not subject to the PRA under 5 CFR 1320.3(c). We further 
noted in the Proposed Rule that the PRA (44 U.S.C. 3518(c)(1)(B)(ii)) 
exempts the information collections specified in 45 CFR 170.565 that 
apply to ONC-ATLs, which are collection activities that would occur 
during administrative actions or investigations involving ONC against 
an ONC-ATL.
    We explained in the Proposed Rule that since the establishment of 
the Program in 2010, there have never been more than six applicants or 
entities selected for ONC-ATCB or accredited testing lab status. We 
stated our expectations that there will be no more than eight ONC-ATLs 
participating in the Program, which included the five accredited 
testing labs currently operating under the Program and an estimated 
three more testing labs that may consider becoming accredited and seek 
ONC-ATL status because of our proposal to permit ONC-ATL status based 
on health IT testing accreditation to only one certification criterion 
or a partial certification criterion.
    We requested comments on these conclusions and the supporting 
rationale on which they were based.
    In the Proposed Rule, we specified that the ``collection of 
information'' requirements that apply to ONC-ATLs are found in Sec.  
170.520(b); proposed Sec.  170.524(d) and (f); and Sec.  170.540(c). We 
estimated the burden hours for these requirements in case our 
conclusions in the Proposed Rule were found to be misguided based on 
public comments or for other reasons and to seek comments on the burden 
hours as a means of informing our regulatory impact analysis (see 
section VI (``Regulatory Impact Statement'') of this preamble). The 
estimated total burden hours as specified in the Proposed Rule are 
expressed in Table 1 below. We explained in the Proposed Rule that the 
estimated total burden hours were based on an estimated eight 
respondents (ONC-ATLs) for the reasons noted above and in the Proposed 
Rule. With similar requirements to ONC-ACBs, we estimated the same 
number of burden hours for ONC-ATLs to comply with

[[Page 72454]]

Sec. Sec.  170.520(b) and 170.540(c) as cited in the 2015 Edition 
proposed rule (80 FR 16894). In the Proposed Rule, we made the same 
determination for ONC-ATL records retention requirements under proposed 
Sec.  170.524(f) as we did for the ONC-ACB records retention 
requirements (i.e., no burden hours) (80 FR 16894). We also estimated 
two responses per year at one hour per response for ONC-ATLs to provide 
updated contact information to ONC per Sec.  170.524(d).

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

    Comments. We received one comment from an accredited testing lab 
suggesting that we increase the burden hours for application submission 
and general updates of accreditation by a factor of four or more to 
more accurately reflect time spent by the ONC-ATL due to time spent 
internally by the organization preparing for the submission.
    Response. We have accepted the commenter's suggestion and increased 
the burden hour estimates by a factor of four for relevant requirements 
as reflected in Table 2 below. The revised estimated costs of these 
requirements can be found in section VI (``Regulatory Impact 
Statement'') of this final rule.

                                Table 2--Estimated Annualized Total Burden Hours
----------------------------------------------------------------------------------------------------------------
                                 Code of Federal                     Number of        Average
      Type of respondent           Regulations       Number of     responses per   burden hours    Total burden
                                     section        respondents     respondent     per response        hours
----------------------------------------------------------------------------------------------------------------
ONC-ATL.......................  45 CFR                         8               1               4              32
                                 170.520(b).
ONC-ATL.......................  45 CFR                         8               2               4              64
                                 170.524(d).
ONC-ATL.......................  45 CFR                         8             n/a             n/a             n/a
                                 170.524(f).
ONC-ATL.......................  45 CFR                         8               1               4              32
                                 170.540(c).
                                                 ---------------------------------------------------------------
    Total burden hours for all  ................  ..............  ..............  ..............             128
     collections of
     information.
----------------------------------------------------------------------------------------------------------------

    We continue to estimate fewer than ten annual respondents for all 
of the regulatory ``collection of information'' requirements for ONC-
ATLs under Part 170 of Title 45. Accordingly, the ``collection of 
information'' requirements/burden that are associated with this final 
rule are not subject to the PRA under 5 CFR 1320.3(c). As noted in the 
Proposed Rule, the PRA (44 U.S.C. 3518(c)(1)(B)(ii)) exempts the 
information collections specified in 45 CFR 170.565 that apply to ONC-
ATLs, which are collection activities that would occur during 
administrative actions or investigations involving ONC against an ONC-
ATL.

C. Health IT Developers

    We proposed in 45 CFR 170.580 that a health IT developer would have 
to submit certain information to ONC as part of a review of the health 
IT developer's certified health IT and if ONC took action against the 
certified health IT (e.g., requiring a CAP to correct a non-conformity 
or suspending or terminating a certification for a Complete EHR or 
Health IT Module). However, we concluded in the Proposed Rule that the 
PRA exempts these information collections because 44 U.S.C. 
3518(c)(1)(B)(ii) excludes collection activities during the conduct of 
administrative actions or investigations involving the agency against 
specific individuals or entities.
    Comments. We received no comments specific to the ``collection of 
information'' requirements applicable to health IT developers and our 
PRA determination.
    Response. We continue to maintain that the ``collection of 
information'' requirements for health IT developers that are associated 
with this final rule, including providing access to the health IT as 
clarified earlier in the preamble, are not subject to the PRA under 44 
U.S.C. 3518(c)(1)(B)(ii), which excludes collection activities during 
the conduct of administrative actions or investigations involving the 
agency against specific individuals or entities.

VI. Regulatory Impact Statement

A. Statement of Need

    While ONC-authorized certification bodies (ONC-ACBs) have been 
delegated authority to issue certifications for health IT on ONC's 
behalf under the ONC Health IT Certification Program (``Program''), 
they do not have responsibility to address the full range of 
requirements applicable to health IT certified under the Program, such 
as those that may pose a risk to public health or safety and are 
inconsistent with section 3001(b) of the PHSA. In addition, ONC-ACBs 
may be unable to effectively administer Program requirements in certain 
circumstances due to practical challenges. In contrast, ONC is well-
positioned to review certified health IT against the full range of 
requirements under the Program. This final rule is being published to 
enhance Program oversight by providing a regulatory framework for ONC 
to directly review of health IT in certain circumstances and to take 
appropriate responsive actions to address potential

[[Page 72455]]

non-conformities and non-conformities, including requiring the 
correction of non-conformities as determined by ONC in health IT 
certified under the Program and suspending and terminating 
certifications issued to Complete EHRs and Health IT Modules.
    This final rule also sets forth processes for ONC to timely and 
directly address testing issues by enabling ONC to authorize and 
further oversee ONC-accredited testing laboratories (ONC-ATLs). These 
processes will serve to align the testing structure with ONC's 
authorization and oversight of ONC-ACBs. In addition, this final rule 
will increase the transparency and availability of information about 
certified health IT through the publication of identifiable 
surveillance results. The publication of identifiable surveillance 
results supports further accountability of health IT developers to 
their customers and users of certified health IT.

B. Alternatives Considered

    We assessed alternatives to our proposed approaches (i.e., ONC's 
direct review of certified health IT and the authorization and 
oversight of accredited testing labs (ONC-ATLs)). One alternative would 
have been to maintain the approach for the Program prior to this final 
rule in which ONC-ACBs had sole responsibility for issuing and 
administering certifications in accordance with ISO/IEC 17065, the PoPC 
for ONC-ACBs, and other requirements of the Program. This approach 
would also have left the testing structure as it existed before this 
final rule. A second alternative would have been for ONC to take 
further responsibility for the testing, certification, and ongoing 
conformity of health IT with Program requirements by making testing and 
certification determinations and/or reviewing all determinations made 
under the Program. We requested comments on our assessment of 
alternatives and any alternatives that we should also consider.
    Comments. Some commenters stated that ONC direct review is 
unnecessary, while other commenters stated that review of certified 
health IT should be left to ONC-ACBs.
    Response. As we stated in the Proposed Rule, we continue to believe 
that adopting either alternative approach would be misguided. The 
current approach, which relies on ONC-ACBs to review certified health 
IT and take necessary actions, does not provide a regulatory framework 
for addressing non-conformities in certified health IT that present a 
serious risk to public health or safety or that present issues 
described in Sec.  170.580(a)(2)(ii). As stated in the Proposed Rule, 
we fully considered the Program structure when initially establishing 
the Program and have made appropriate modifications as the Program has 
evolved. These past considerations primarily focused on a market-driven 
approach for the Program with testing and certification conducted on 
behalf of ONC and with ONC retaining and establishing direct and 
indirect oversight over certain activities. We also noted in the 
Proposed Rule and in this final rule that ONC-ACBs play an integral 
role in the Program and have the necessary expertise and capacity to 
effectively administer specific Program requirements. Similarly, 
accredited testing labs also play an integral role in the Program's 
success through the testing of health IT.
    ONC direct review will complement ONC-ACBs' roles under the Program 
and serve to address matters, for example, beyond their resources and 
expertise. ONC direct oversight of ONC-ATLs will ensure that, like with 
ONC-ACBs, testing labs are directly and immediately accountable to ONC 
for their performance across a variety of Program items that affect the 
testing of health IT. Overall, the provisions in this final rule serve 
to enhance the Program by providing more consistency and accountability 
for Program participants, which will provide greater confidence in 
certified health IT when it is implemented, maintained, and used. 
Accordingly, and for the reasons outlined in this final rule, 
maintaining the Program as it is currently structured is not 
acceptable. If we did not change the current testing structure, a lack 
of parity in ONC oversight for testing and certification would continue 
to exist. ONC direct oversight of ONC-ATLs will ensure that, like with 
ONC-ACBs, testing labs are directly and immediately accountable to ONC 
for their performance across a variety of Program items that affect the 
testing of health IT. For the reasons outlined throughout this final 
rule, and specifically detailed in section II.A.1, we do not believe 
that continuing the Program with a framework for only ONC-ACB 
surveillance of certified health IT is a viable option or alternative.

C. Overall Impact

    We examined the impact of the final rule as required by Executive 
Order 12866 on Regulatory Planning and Review (September 30, 1993), 
Executive Order 13563 on Improving Regulation and Regulatory Review 
(February 2, 2011), the Regulatory Flexibility Act (5 U.S.C. 601 et 
seq.), section 202 of the Unfunded Mandates Reform Act of 1995 (2 
U.S.C. 1532), and Executive Order 13132 on Federalism (August 4, 1999).
1. Executive Orders 12866 and 13563--Regulatory Planning and Review 
Analysis
    Executive Orders 12866 and 13563 direct agencies to assess all 
costs and benefits of available regulatory alternatives and, if 
regulation is necessary, to select regulatory approaches that maximize 
net benefits (including potential economic, environmental, public 
health and safety effects, distributive impacts, and equity). A 
regulatory impact analysis (RIA) must be prepared for major rules with 
economically significant effects ($100 million or more in any one 
year). It has been determined that this final rule is an economically 
significant rule as the potential costs associated with this final rule 
could be greater than $100 million per year. Accordingly, we have 
prepared an RIA that to the best of our ability presents the costs and 
benefits of this final rule.
a. Costs
    We have identified and estimated the potential monetary costs for 
health IT developers, ONC-ATLs, the federal government (i.e., ONC), and 
health care providers as a result of this final rule. We have 
categorized and addressed costs as follows: (1) Costs for health IT 
developers to correct non-conformities as determined by ONC; (2) costs 
for ONC and health IT developers related to an ONC inquiry into 
certified health IT non-conformities and ONC direct review, including 
costs for the new ``proposed termination'' step; (3) costs for health 
IT developers and ONC associated with the appeal process following a 
suspension/termination of a Complete EHR's or Health IT Module's 
certification; (4) costs for health care providers to transition to 
another certified health IT product when the certification of a 
Complete EHR or Health IT Module that they currently use is terminated; 
(5) costs for ONC-ATLs and ONC associated with ONC-ATL accreditation, 
application, renewal, and reporting requirements; (6) costs for ONC-
ATLs and ONC related to revoking ONC-ATL status; and (7) costs for ONC-
ACBs to submit identifiable surveillance results to the CHPL. We also 
provide an overall annual monetary cost estimate for the final rule 
(see (8) Total Annual Cost Estimate). We note that we have rounded all 
estimates to the nearest dollar and all estimates are expressed in 2016 
dollars.

[[Page 72456]]

Comments on the Proposed Rule
General
    Comments. Commenters expressed concerns that the costs of direct 
review could flow downstream to health IT developers, health care 
providers, and ONC-ATLs.
    Response. We appreciate commenters' concerns and agree that certain 
stakeholders may incur costs as a result of this final rule. We have, 
therefore, estimated the direct costs for health IT developers and ONC 
due to ONC actions stemming from direct review under the provisions of 
this final rule, such as the costs for health IT developers to respond 
to a notice of potential non-conformity or notice of non-conformity or 
to file an appeal of an ONC determination. We have also estimated the 
indirect costs for health care providers because these costs may arise 
if ONC were to terminate the certification of health IT being used by 
health care providers to participate in a program requiring the use of 
certified health IT. We note that we do not believe there are any costs 
for ONC-ATLs related to direct review conducted by ONC.
Costs for Health IT Developers To Correct Non-Conformities Identified 
by ONC
    Comments. A commenter asserted that substantial costs should be 
attributed to the reassessment of health IT for current conformity and 
estimated it would take at least 400 hours to perform a gap and risk 
assessment per product.
    Response. We stated in the Proposed Rule that some health IT 
developers may reassess their products for conformity. We also stated 
in the Proposed Rule (81 FR 11073-74) and maintain that health IT 
developers should always be ensuring that their products are safe and 
conducting conformity and safety assessments of their health IT as part 
of proper quality management. We are unable to project the number of 
assessments that would occur beyond what is observed under the existing 
regulatory and market structure. Therefore, we have not included these 
costs in our quantitative cost estimates.
    Comments. Some commenters noted that, if ONC alleges non-
conformities outside the scope of certification criteria or test 
procedures, there could be a significant burden for health IT 
developers to respond to investigations and to change their products.
    Response. We thank commenters for their thoughtful comments on this 
aspect of our proposal. We refer readers to section II.A.1.a of this 
final rule for a detailed discussion of what constitutes a non-
conformity. As discussed in more detail in section C.1.a.(1) of this 
regulatory impact statement, while there would likely be costs to 
correct a non-conformity found as a result of ONC direct review under 
the processes outlined in this final rule, it is difficult to project 
such instances and costs given unpredictability of non-conformity 
occurrences and the underlying need to correct non-conformities. We 
have, however, estimated the costs to ONC and health IT developers 
related to an ONC inquiry into certified health IT non-conformities and 
ONC direct review in section C.1.a.(2) of this RIA.
Costs for ONC and Health IT Developers Related to an ONC Inquiry Into 
Certified Health IT Non-Conformities and ONC Direct Review
    Comments. Some commenters suggested that we underestimated the 
costs to health IT developers, both in terms of dollars and ``softer'' 
costs, such as negative pressure on innovation. Commenters suggested we 
estimate the costs for ONC investigations. Commenters also stated that 
there should be a cost associated with unsubstantiated allegations and 
complaints. Commenters noted that ONC staff may lack appropriate 
expertise to conduct investigations.
    Response. We clarify that the estimates for the review of, and 
inquiry into, certified health IT includes investigations (see section 
C.1.a.(2) of this RIA). In consideration of comments and due to the 
potential complexity of such investigations, we have increased the high 
end of our estimated range of costs by doubling our original high-end 
estimate for health IT developers and ONC. The unsubstantiated 
allegations and complaints noted by the commenters are captured in our 
low-end range of cost estimates.
    We appreciate commenters' concerns regarding whether ONC staff will 
have the expertise to conduct investigations. ONC is evaluating the 
expertise and capabilities of current ONC staff and, if necessary, will 
hire additional staff with the requisite expertise and capabilities. 
However, we have no basis for estimating these potential costs in this 
RIA. These potential staffing costs will be driven by the volume of ONC 
direct review situations and the volume of additional responsibilities 
of ONC staff.
Costs for Health IT Developers and ONC Associated With the Appeal 
Process Following a Suspension/Termination of a Complete EHR's or 
Health IT Module's Certification
    Comments. A commenter stated that ONC's estimated costs for a 
health IT developer to provide required information to appeal a 
suspension or termination are conservative, and these tasks would 
require experienced personnel who possess a high degree of technical 
knowledge.
    Response. We appreciate the commenter's concern, but maintain that 
our estimate is reasonable, particularly due to the wide range of hours 
calculated. We agree with the commenter that compiling information for 
an appeal will require experienced personnel with technical expertise 
and we accounted for this expertise by assuming that the expertise of 
the employee(s) needed to participate in the appeal would be equivalent 
to a GS-15, Step 1 federal employee.
Costs for Health Care Providers To Transition to Another Certified 
Health IT Product When the Certification of a Complete EHR or Health IT 
Module That They Currently Use Is Terminated
    Comments. Commenters were concerned about the financial impact of 
this final rule on health care providers, specifically the downstream 
costs for providers to transition to another certified health IT 
product. Multiple commenters suggested that our estimated average cost 
per product per health care provider to implement a new certified 
health IT product of approximately $33,000 is too low. Commenters also 
noted that the health care provider will probably not get a refund from 
the health IT developer and will have to acquire and possibly install a 
new product. A commenter suggested that ONC should account for the 
costs of labor, retraining employees, and lost productivity, in 
addition to the licensing and implementation costs of a new product. 
Another commenter suggested that in addition to direct financial costs 
of transitioning to another certified health IT product, ONC should 
calculate the costs associated with errors and inefficiencies caused by 
the transition.
    Response. We thank commenters for their thoughtful comments on our 
cost estimates, but have adopted these estimates as proposed. We agree 
with commenters that there may be costs associated with the labor, 
retraining of employees, lost productivity, and errors and 
inefficiencies caused by the transition, but we have been unable to

[[Page 72457]]

identify reliable data upon which we could base or revise our cost 
estimates. The relationship between a provider and a health IT 
developer will be guided by relevant contracts and licenses. Transition 
costs will most likely be costs negotiated as part of the health IT 
transactions and will vary with respect to the complexity of the health 
IT system and the tear-down, data transfer, and implementation of the 
new system while still providing patient care. We discuss these 
relationships and the associated costs in more detail in section 
C.1.a.(4) of this RIA.
Costs for ONC-ATLs and ONC Associated With ONC-ATL Accreditation, 
Application, Renewal, and Reporting Requirements
    Comments. A couple of commenters questioned why existing accredited 
testing labs would incur an $11,000 fee. One accredited testing lab 
stated that our ATL-specific cost estimates were reasonable.
    Response. We have adopted the accreditation cost estimates as 
proposed. On-site assessments are required prior to initial 
accreditation, during the first renewal year, and every two years 
thereafter. As such, the current five accredited testing labs would 
incur the on-site assessment fee once during the initial three-year 
ONC-ATL authorization period. Based on our consultations with NIST, we 
estimate a full scope on-site assessment for all criteria required for 
accreditation will cost approximately $11,000. This is the estimate we 
have used to calculate the estimated burden. However, we note that 
these values are approximated and will vary depending on the agreements 
established between health IT developers and ONC-ATLs.
    Comments. A couple of commenters suggested that ONC should 
reevaluate its method for estimating the applicant staff time necessary 
to prepare and participate in the full scope on-site assessment. 
Commenters opined that since ONC-ACBs have already gone through this 
assessment, there should be actual experience data from those ONC-ACBs 
that could provide a more reliable estimate.
    Response. Based on information provided by ONC-ACBs, we have 
revised our estimate for the applicant staff time necessary to prepare 
and participate in the full scope on-site assessment from 200 hours to 
130 hours. Accordingly, we have also revised our cost estimate for a 
limited scope on-site assessment to 65 hours, which is half the 
estimate for the full scope on-site assessment. Based on these adjusted 
estimates for staff time for a GS-15, Step 1 federal employee, we 
estimate the applicant staff cost for a full scope on-site assessment 
at $15,956 and the applicant staff cost for a limited scope on-site 
assessment at $7,978.
    Comments. We received one comment from an accredited testing lab 
suggesting that we increase the burden hours for application submission 
and general updates of accreditation by a factor of four or more to 
more accurately reflect time spent by the ONC-ATL due to time spent 
internally by the organization preparing for the submission.
    Response. We have accepted the commenter's suggestion and increased 
the burden hour estimates by a factor of four for the following 
requirements: (1) ONC-ATL application at 45 CFR 170.520(b); (2) 
reporting changes at 45 CFR 170.524(d); and (3) renewal at 45 CFR 
170.540(c).
    Comments. A couple of commenters noted that we estimated $55,623 as 
the annualized cost for the first accreditation/application and 3-year 
authorization and we estimated $84,372 as the annualized cost to renew 
accreditation, application, and authorization during the first three-
year ONC-ATL authorization period. They were confused as to why a 
renewal cost would be higher than the cost for a new testing lab.
    Response. We have revised these estimates as described below in the 
``Costs to the Applicant/ONC-ATL'' section below. We also clarify that 
the proposed renewal cost per testing lab ($50,623) is lower than the 
cost for each new testing lab applicant ($55,623). The reason the 
annualized cost is higher for renewals than for new applicants is 
because we initially calculated for five renewals (there are currently 
five accredited testing labs) and three new applicants.
Costs for ONC-ACBs To Submit Identifiable Surveillance Results to the 
CHPL
    Comments. A couple commenters suggested that the proposed cost 
estimate for ONC-ACBs posting identifiable surveillance results of $205 
is too low. These commenters suggested that approximately six hours 
would be required.
    Response. As discussed in section II.B of this final rule, ONC-ACBs 
will be required to report the following information for all 
surveillance results: The names of health IT developers; names of 
products and versions; certification criteria and Program requirements 
surveilled; identification of the type of surveillance (i.e., reactive 
or random); the dates surveillance was initiated and completed; and the 
number of sites that were used in randomized surveillance. However, in 
order to reduce the burden on ONC-ACBs, ONC will post surveillance 
results on the CHPL. This is consistent with our consideration in the 
Proposed Rule of having the hyperlinks on the ONC Web site as a way of 
providing stakeholders with a more readily available means for 
accessing the results. ONC-ACBs will be required to submit the data 
into the CHPL directly, but will not be required to host and update the 
data on their own Web sites as proposed.
    We estimate that submitting identifiable surveillance results on a 
quarterly basis will further limit the burden on ONC-ACBs, but 
acknowledge that the expanded scope and volume of surveillance 
information will require additional time to submit the results to the 
CHPL than the four hours proposed. Therefore, in response to comments, 
we estimate that it will take an employee 20 hours annually to report 
identifiable surveillance results to the CHPL.
Cost Estimates
    The only changes to the cost estimates from the Proposed Rule are: 
(1) We doubled the high-end estimate for ONC staff time related to 
ONC's review and inquiry into certified health IT and health IT 
developer staff time associated with providing ONC with all requested 
records and documentation that ONC would use to make a suspension and/
or termination determination, including for the new ``proposed 
termination'' step; (2) based on information provided by ONC-ACBs, we 
revised our estimate for the applicant staff time necessary to prepare 
and participate in a full and a limited scope on-site assessment; (3) 
based on public comments, we increased the burden hour estimates for 
ONC-ATLs by a factor of four from the estimates in the Proposed Rule 
for the requirements in 45 CFR 170.520(b) (ONC-ATL application), 45 CFR 
170.524(d) (reporting changes to ONC), and 45 CFR 170.540(c) (ONC-ATL 
status renewal); and (4) we added cost estimates for ONC-ACBs to report 
identifiable surveillance results to the CHPL.
    We made employee assumptions about the level of expertise needed to 
complete the requirements in this section of the final rule. We 
correlated that expertise with the corresponding grade and step of an 
employee classified under the General Schedule Federal Salary 
Classification, relying on the associated employee hourly rates for the 
Washington, DC locality pay area as published by the Office of 
Personnel Management. We assumed that an

[[Page 72458]]

applicant expends one hundred percent (100%) of an employee's hourly 
wage on benefits and overhead for the employee. Therefore, we doubled 
the employee's hourly wage to account for benefits. We concluded that a 
100% expenditure on benefits is an appropriate estimate based on 
research conducted by HHS.
    We used the General Schedule Federal Salary Classification for 
private sector employee wage calculations because the majority of the 
tasks and requirements that would be performed by private sector 
employees do not easily fall within a particular occupational 
classification identified by the Bureau of Labor Statistics (BLS). For 
instance, while we estimated costs for specialized testing lab 
personnel to support accreditation, we also estimated costs for 
participating in administrative reviews and appeals and reporting 
certain information to ONC. As noted above, in all instances, we 
correlated the expertise needed to complete the task or requirement 
with the corresponding grade and step of a federal employee classified 
under the General Schedule Federal Salary Classification.
(1) Costs for Health IT Developers To Correct Non-Conformities 
Identified by ONC
    We acknowledged in the Proposed Rule that this rulemaking may: (1) 
Lead health IT developers to reassess whether their certified health IT 
is conforming; and (2) require health IT developers to correct non-
conformities found by ONC in their certified health IT. We also stated 
in the Proposed Rule that the costs to perform either of the above 
would be determined on a case-by-case basis, likely vary significantly 
based on various factors, and that we did not have reliable information 
on which to base costs estimates for these activities (81 FR 11074). We 
seek to clarify that these statements were made to provide a 
comprehensive view of all potential costs. However, estimating the 
prevalence of entities incurring these potential costs that would be 
attributable to this final rule presents a substantial challenge. There 
are no new certification requirements in this final rule and health IT 
developers have already been certified to applicable certification 
criteria and other Program requirements. Independent of this final 
rule, health IT developers should still be ensuring that their products 
are safe and conducting conformity and safety assessments of their 
health IT as part of proper quality management. These activities are 
typically a regular cost of doing business to ensure that their 
certified health IT is not, for example, creating public health and/or 
safety issues by causing medical errors (see 81 FR 11073-74). If ONC 
identifies/finds a non-conformity with a certified capability under the 
direct review processes outlined in this final rule, then the costs to 
correct the non-conformity are a result of this final rule. However, 
due to the difficulty of projecting such instances given the underlying 
need to correct non-conformities, we have not been able to include 
these costs in our quantitative cost estimates.
(2) Costs for ONC and Health IT Developers Related to an ONC Inquiry 
Into Certified Health IT Non-Conformities and ONC Direct Review
    ONC has broad discretion to review certified health IT. However, we 
anticipate that such direct review will be relatively infrequent and 
will focus on situations that pose a risk to public health or safety. 
We estimate that a health IT developer may commit, on average and 
depending on complexity, between 80 and 800 hours of staff time to 
provide ONC with all requested records, access to the technology as 
needed, and documentation that ONC would use to conduct the fact-
finding, make a non-conformity determination, approve a CAP, and make a 
suspension and/or termination determination, including the new 
``proposed termination'' step. We assumed that the expertise of the 
employee(s) needed to comply with ONC's requests would be equivalent to 
a GS-15, Step 1 federal employee. The hourly wage with benefits for a 
GS-15, Step 1 employee located in Washington, DC is approximately 
$122.74. Therefore, we estimate the cost for a health IT developer to 
cooperate with an ONC review and inquiry into certified health IT will, 
on average, range from $9,819 to $98,192. We note that some health IT 
developers' costs are expected to be less and some health IT 
developers' costs are expected to be more than this estimated cost 
range.
    In comparison, the BLS average hourly wage for a nonsupervisory 
employee under the North American Industry Classification System 
(NAICS) 541511, ``Custom Computer Programming Services,'' is 
$42.67.\22\ We assumed that, just as with the General Schedule Federal 
Salary Classification, an applicant expends one hundred percent (100%) 
of an employee's hourly wage on benefits for the employee. Therefore, 
we doubled the employee's hourly wage to account for benefits, bringing 
the average hourly wage with benefits to $85.34. Accordingly, the BLS 
estimated wages for a health IT developer to cooperate with an ONC 
review and inquiry into certified health IT will, on average, range 
from $6,827 to $68,272, which is considerably lower than the General 
Schedule Federal Salary Classification estimates. We estimate that ONC 
may commit, on average and depending on complexity, between 20 and 
1,200 hours of staff time to complete a review and inquiry into 
certified health IT. We assumed that the expertise of a GS-15, Step 1 
federal employee(s) will be necessary. Therefore, we estimate the cost 
for ONC to review and conduct an inquiry into certified health IT will, 
on average, range from $2,455 to $147,288. We note that some reviews 
and inquiries may cost less and some may cost more than this estimated 
cost range.
---------------------------------------------------------------------------

    \22\ See http://beta.bls.gov/dataViewer/view/timeseries/CEU6054151108.
---------------------------------------------------------------------------

(3) Costs for Health IT Developers and ONC Associated With the Appeal 
Process Following a Suspension/Termination of a Complete EHR's or 
Health IT Module's Certification
    As discussed in section II.A.1.c.(5) of this final rule's preamble, 
Sec.  170.580(g) permits a health IT developer to appeal an ONC 
determination to suspend or terminate a certification issued to a 
Complete EHR or Health IT Module. We estimate that a health IT 
developer may commit, on average and depending on complexity, between 
80 to 240 hours of staff time to provide the required information to 
appeal a suspension or termination and respond to any requests from the 
hearing officer. We assumed that the expertise of the employee(s) 
needed to participate in the appeal would be equivalent to a GS-15, 
Step 1 federal employee. The hourly wage with benefits for a GS-15, 
Step 1 employee located in Washington, DC is approximately $122.74. 
Therefore, we estimate the cost for a health IT developer to appeal a 
suspension or termination will, on average, range from $9,819 to 
$29,458. We note that some health IT developers' costs are expected to 
be less and some health IT developers' costs are expected to be more 
than this estimated cost range. In comparison, the BLS average hourly 
wage with benefits is $85.34. Therefore, the cost for a health IT 
developer to appeal a suspension or termination using BLS wages will, 
on average, range from $6,827 to $20,482.
    We estimate that ONC would commit, on average and depending on 
complexity, between 200 and 800 hours of staff time to conduct an 
appeal. This would include the time to represent ONC in the appeal and 
support the costs

[[Page 72459]]

for the hearing officer. We assumed that the expertise of a GS-15, Step 
1 federal employee(s) will be necessary. Therefore, we estimate the 
cost for ONC to conduct an appeal will, on average, range from $24,548 
to $98,192. We note that some appeals may cost less and some may cost 
more than this estimated cost range.
(4) Costs for Health Care Providers To Transition to Another Certified 
Health IT Product When the Certification of a Complete EHR or Health IT 
Module That They Currently Use Is Terminated
    This cost analysis with regards to health care providers focuses on 
the direct effects of the termination of a Complete EHR's or Health IT 
Module's certification under this final rule's provisions as a 
certification termination would have the greatest potential impact. We 
note and emphasize that the estimated costs for health care providers 
as a result of a certification termination could be incurred absent the 
provisions in this final rule. ONC-ACBs currently have the authority to 
terminate (and suspend) the certifications of Complete EHRs and Health 
IT Modules. In this regard, ONC-ACBs have terminated certifications for 
both Complete EHRs and Health IT Modules.
    The most recent termination of a certification by an ONC-ACB 
occurred in June 2016 when a health IT developer failed to submit a CAP 
related to transparency requirements. No eligible professionals (EPs) 
attested under the Medicare EHR Incentive Program to using this 
certified health IT product. Another termination by an ONC-ACB occurred 
in September 2015 when the certifications of a health IT developer's 
Complete EHRs and Health IT Modules were terminated for failure to 
respond and participate in routine surveillance requests.\23\ Only 48 
eligible professionals attested under the Medicare EHR Incentive 
Program to using these certified health IT products. In April 2013, an 
ONC-ACB terminated the certifications of Complete EHRs and Health IT 
Modules because they did not meet the required functionality.\24\ Those 
certified health IT products had no Medicare attestations. Considering 
that these are the only terminations and impacts over the five years of 
the Program and consistent with our stated intent to work with health 
IT developers to correct non-conformities found in their certified 
health IT under the provisions in this final rule, we maintain that it 
is highly unlikely that the high end of our estimated costs for health 
care providers will ever be realized.
---------------------------------------------------------------------------

    \23\ http://www.hhs.gov/news/press/2015pres/09/20150902c.html.
    \24\ http://www.hhs.gov/about/news/2013/04/25/certification-for-electronic-health-record-product-revoked.html.
---------------------------------------------------------------------------

    We estimate the monetary costs that will be sustained by health 
care providers to transition to another certified health IT product 
when the certification of a Complete EHR or Health IT Module that they 
currently use is terminated. We anticipate that health care providers 
impacted by certification termination will transition to a new 
certified health IT product due to eventually needing certified health 
IT to participate in other HHS programs requiring the use of certified 
health IT (e.g., the EHR Incentive Programs \25\). We calculated the 
estimated upfront cost for health care providers using the number of 
known EPs that report under the Medicare EHR Incentive Program using 
certified Complete EHRs and certified Health IT Modules that would have 
their certifications terminated multiplied by an estimated average cost 
per product per provider to implement a new certified health IT 
product. The estimated average cost per product per provider to 
implement a new certified health IT product is approximately $33,000. 
This estimate is consistent with other analyses on average costs.\26\
---------------------------------------------------------------------------

    \25\ For health care provider guidance regarding circumstances 
and options when the health IT they are using to participate in the 
EHR Incentive Programs has its certification terminated or 
withdrawn, please see CMS EHR Incentive Programs FAQ 12657: https://questions.cms.gov/faq.php?isDept=0&search=decertified&searchType=keyword&submitSearch=1&id=5005.
    \26\ A Health Affairs study (http://content.healthaffairs.org/content/30/3/481.abstract) estimated the average cost for EHR 
implementation at a five-physician practice as $162,000. Dividing by 
five, the estimated cost per physician is $32,400, which is close to 
our estimated cost of $33,000 to implement an in-office health IT 
product.
---------------------------------------------------------------------------

    This analysis and cost estimates does not include sunk costs during 
the transition year, such as ongoing maintenance for the health IT 
product that had its certification(s) terminated and any upfront costs 
the provider paid for the health IT product. The transition by a health 
care provider to a new certified health IT product could also include 
non-sunk costs associated with unwinding contractual matters and 
technological connectivity, replacement/implementation efforts, 
training of workforce, and the potential for an operational shut down 
to effectuate a transition to a replacement technology. In regard to 
contractual matters, we acknowledge that transitioning to a new 
certified health IT product following a certification termination may 
be further complicated by the fact that health care providers may have 
entered multi-year transactions for a Complete EHR or Health IT 
Module(s). These costs would likely vary significantly based on the 
contract and specific situation. Conversely, unlike the cost categories 
just mentioned, which would tend to make our estimates understate the 
costs to providers due to a termination of certification, some aspects 
of certified health IT implementation may be similar across products, 
thus reducing the costs of transitioning to a new product below the 
costs incurred in association with the original implementation.
    We used the following formula to calculate the estimated upfront 
costs for health care providers to transition to a new product:

1. Number of EPs reporting with a certified Complete EHR or certified 
Health IT Module that could potentially have its certification 
terminated
2. #1 multiplied by the average upfront cost per product per health 
care provider
3. Result of #2 equals the estimated cost for health care providers to 
replace the certified Complete EHR or certified Health IT Module

    Applying this formula, we calculated the upper and lower threshold 
impacts as well as the median and mean impacts of terminating 
certifications issued to a Complete EHR or Health IT Module(s). We 
calculated the upper and lower thresholds from the certified Complete 
EHR and certified Health IT Modules with the greatest and least number 
of reported attestations to the Medicare EHR Incentive Program, 
respectively.\27\ The median and mean impacts also were calculated 
using the number of reported attestations for each product (see table 3 
(Cost Impact to Health Care Providers)). We calculated the estimated 
cost to those health care providers assuming all the health care 
providers would transition to a new certified health IT product.
---------------------------------------------------------------------------

    \27\ As of November 30, 2015.

[[Page 72460]]



                                  Table 3--Cost Impact to Health Care Providers
----------------------------------------------------------------------------------------------------------------
                                                       Lower          Median           Mean            Upper
----------------------------------------------------------------------------------------------------------------
Number of EP Attestations.......................               1              24             190          19,692
Calculated Cost.................................         $33,000        $792,000      $6,270,000    $649,836,000
----------------------------------------------------------------------------------------------------------------

    We estimate the cost impact of certification termination on health 
care providers will range from $33,000 to $649,836,000 with a median 
cost of $792,000 and a mean cost of $6,270,000.
(5) Costs to ONC-ATLs and ONC Associated With ONC-ATL Accreditation, 
Application, Renewal, and Reporting Requirements
Costs to the Applicant/ONC-ATL
    An applicant for ONC-ATL status will be required to submit an 
application and must be accredited in order to be a qualified ONC-ATL 
applicant. We estimate there will be between five and eight applicants, 
five of which are already accredited by NVLAP to ISO/IEC 17025 and up 
to three new applicants. Any new applicants for ONC-ATL status under 
the Program will first be required to become accredited by NVLAP to 
ISO/IEC 17025.
    We note in section V (``Collection of Information Requirements'') 
of this final rule that we have increased the burden hour estimates by 
a factor of four from the estimates in the Proposed Rule for 
requirements in 45 CFR 170.520(b) (ONC-ATL application), 45 CFR 
170.524(d) (reporting changes to ONC), and 45 CFR 170.540(c) (ONC-ATL 
status renewal). As such, the following cost estimates reflect the 
associated increase in burden hour estimates.
    Based on our consultations with NIST, we estimate that it will take 
approximately 2-5 days for NVLAP to complete a full scope on-site 
assessment for all criteria required for accreditation at an 
approximate cost of $11,000. The on-site assessment fee covers the 
costs incurred by the assessors conducting the on-site assessment such 
as preparation time, time on-site, and travel costs (e.g. flights, 
hotel, meals, etc.). Section 170.511 will permit the authorization of 
ONC-ATLs for testing to one or even a partial certification criterion. 
Based on our consultations with NIST, this will take at least one day 
to complete and may reduce the necessary scope and cost of the on-site 
assessment to approximately $8,000. The current five accredited testing 
labs will each incur the full scope on-site assessment fee of $11,000, 
as discussed below. We anticipate the potential three new applicants 
will each incur a limited scope on-site assessment fee of $8,000, as 
discussed below.
    Based on information provided by ONC-ACBs, we estimate the 
applicant staff time necessary to prepare and participate in the full 
scope on-site assessment at 130 hours. We estimate the applicant staff 
time necessary to prepare and participate in the limited scope on-site 
assessment at 65 hours, which is half the estimate for the full scope 
on-site assessment. We anticipate that an employee equivalent to a GS-
15, Step 1 federal employee will be responsible for preparation and 
participation in the accreditation assessment. The hourly wage with 
benefits for a GS-15, Step 1 employee located in Washington, DC is 
approximately $122.74. Therefore, we estimate the applicant staff cost 
for the full scope on-site assessment at $15,956 and the applicant 
staff cost for the limited scope on-site assessment at $7,978.
    In comparison, the BLS average hourly wage for a ``Computer and 
Information Analyst'' under NAICS 541380, Testing Laboratories, is 
$43.54.\28\ The average hourly wage is $87.08 with the inclusion of 
benefits. Therefore, the BLS estimate for applicant staff cost for the 
full scope on-site assessment is $17,416 and the BLS estimate for 
applicant staff cost for the limited scope on-site assessment is 
$8,708. We emphasize that the problem with using the BLS information 
for the ATL classifications and wage estimates is that ONC-ATL duties 
do not easily fall within a particular occupational classification. For 
instance, there is not a singular occupational classification under 
NAICS 541380, Testing Laboratories, that would accurately capture the 
various tasks performed by ONC-ATLs in the processes described in this 
final rule. Thus, we used a broad occupation category, ``Computer and 
Information Analysts,'' for this estimate.
---------------------------------------------------------------------------

    \28\ See http://www.bls.gov/oes/current/naics5_541380.htm#15-0000.
---------------------------------------------------------------------------

    We anticipate that ONC-ATLs will incur an estimated $5,000 
accreditation administrative/technical support fee each year during the 
three-year ONC-ATL authorization period.\29\ The accreditation 
administrative/technical support fee covers costs associated with NVLAP 
staff under the Program. On-site assessments are required prior to 
initial accreditation, during the first renewal year, and every two 
years thereafter. As such, we expect the potential three new applicants 
will each incur the on-site assessment fee twice during their initial 
three-year ONC-ATL authorization period and the current five accredited 
testing labs will incur the on-site assessment fee once during the same 
period. Further, as stated above, we estimate that each full scope on-
site assessment for all criteria will cost approximately $11,000 and 
each limited scope on-site assessment will cost approximately $8,000. 
We estimate that staff expertise and cost for renewal is likely to 
remain consistent at approximately $15,956 for a full scope on-site 
assessment and $7,978 for a limited scope on-site assessment. We expect 
that each ONC-ATL will renew its status, meaning it will request 
reauthorization from ONC to be an ONC-ATL, every three years.
---------------------------------------------------------------------------

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

    After becoming accredited by NVLAP, an applicant for ONC-ATL status 
will incur minimal costs to prepare and submit an application to the 
National Coordinator. We estimate that it will take 40 minutes to 
provide the general information requested in the application, 120 
minutes to assemble the information necessary to provide documentation 
of accreditation by NVLAP, and 80 minutes to review and agree to the 
PoPC for ONC-ATLs. We note that these time estimates are also accurate 
for an ONC-ATL to complete the proposed status renewal process. Based 
on our consultations with NIST, we estimate that an employee equivalent 
to a GS-9, Step 1 federal employee could provide the required general 
identifying information and documentation of accreditation status. The 
hourly wage with benefits for a GS-9, Step 1 federal employee located 
in Washington, DC is approximately $51.20. We estimate that an employee 
equivalent to a GS-15, Step 1 federal employee would be responsible for 
reviewing and agreeing to the PoPC for ONC-ATLs. Therefore, our cost 
estimate per ONC-ATL for these activities is $300. In comparison, the 
BLS cost estimate for one hour of work with

[[Page 72461]]

benefits by a ``Computer and Information Analyst'' is $348.
    Overall, we estimate the total cost of ONC-ATL accreditation, 
application, and the first proposed three-year authorization period 
will be approximately $53,128 and the total cost for up to three new 
applicants will be approximately $159,384. We assume that ONC-ATLs will 
remain accredited during the three-year ONC-ATL authorization period.
    We estimate the total cost for an ONC-ATL to renew its 
accreditation, application, and authorization during the first three-
year ONC-ATL authorization period to be approximately $48,832 and the 
total renewal cost for all five current ONC-ATLs to be approximately 
$219,160. Based on our cost estimate timeframe of three years, we 
estimate the annualized renewal cost to be approximately $73,053.
    We explain in Sec.  170.524(d) that ONC-ATLs shall report various 
changes to their organization within 15 days. We estimate an employee 
equivalent to the Federal Salary Classification of GS-9, Step 1 could 
complete the transmissions of the requested information to ONC. As 
specified in section VI.B of this final rule, we estimate two responses 
per year at four hours per response for ONC-ATLs to provide updated 
information to ONC per Sec.  170.524(d). Accordingly, we estimate it 
will cost each ONC-ATL $409.60 annually to meet this requirement. To 
estimate the highest possible cost, we assumed that the eight 
applicants we estimate will apply to become ONC-ATLs will become ONC-
ATLs. Therefore, we estimate the total annual cost for ONC-ATLs to meet 
the requirements of proposed Sec.  170.524(d) to be $3,276. In 
comparison, using the BLS wages, we estimate the total annual cost for 
ONC-ATLs to meet the requirements of proposed Sec.  170.524(d) to be 
$5,573.
    We explain in Sec.  170.524(f) that ONC-ATLs shall retain all 
records related to the testing of Complete EHRs and Health IT Modules 
to an edition of certification criteria for a minimum of three years 
from the effective date that removed the applicable edition from the 
Code of Federal Regulations. Based on our consultations with NIST, we 
concluded that this time period is in line with common industry 
practices. Consequently, it does not represent an additional cost to 
ONC-ATLs.
Costs to ONC
    We estimate the cost to develop the ONC-ATL application to be $522 
based on the five hours of work we believe it would take a GS-14, Step 
1 federal employee to develop an application form. The hourly wage with 
benefits for a GS-14, Step 1 employee located in Washington, DC is 
approximately $104.34. We also anticipate that there will be costs 
associated with reviewing applications under the Program. We expect 
that a GS-15, Step 1 federal employee will review the applications and 
ONC (or a designated representative) will issue final decisions on all 
applications. We anticipate that it will take approximately 20 hours to 
review and reach a final decision on each application. This estimate 
assumes a satisfactory application (i.e., no formal deficiency 
notifications) and includes the time necessary to verify the 
information in each application and prepare a briefing for the National 
Coordinator. We estimate the cost for the application review process to 
be $2,455. As a result, we estimate ONC's overall cost of administering 
the entire application process to be approximately $2,977. Based on our 
cost estimate timeframe of three years, we estimate the annualized cost 
to ONC to be $992. These costs will be the same for a new applicant or 
ONC-ATL renewal.
    As discussed in this final rule's preamble, we will also post the 
names of applicants granted ONC-ATL status on our Web site. We note 
that there will be minimal cost associated with this action and 
estimate the potential cost for posting and maintaining the information 
on our Web site to be approximately $446 annually. This amount is based 
on a maximum of six hours of work for a GS-12, Step 1 federal employee. 
The hourly wage with benefits for a GS-12 Step 1 federal employee 
located in Washington, DC is $74.
    We note that there will be minimal cost associated with recording 
and maintaining updates and changes reported by the ONC-ATLs. We 
estimate an annual cost to the federal government of $743. This amount 
is based on ten hours of yearly work of a GS-12, Step 1 federal 
employee.
(6) Costs for ONC-ATLs and ONC Related To Revoking ONC-ATL Status
Costs to the ONC-ATL
    We have revised Sec.  170.565 to apply the same process for ONC-ATL 
status revocation as applies to ONC-ACBs. We estimate that an ONC-ATL 
may commit, on average and depending on complexity, between 20 and 160 
hours of staff time to provide responses and information requested by 
ONC. We assume that the expertise of the employee(s) needed to comply 
with ONC's requests will be equivalent to a GS-15, Step 1 federal 
employee. The hourly wage with benefits for a GS-15, Step 1 employee 
located in Washington, DC, is approximately $122.74. Therefore, we 
estimate the cost for an ONC-ATL to comply with ONC requests per Sec.  
170.565 will, on average, range from $2,455 to $19,638. In comparison, 
the BLS cost estimate for a ``Computer and Information Analyst'' would, 
on average, range from $1,742 to $13,933. We note that in some 
instances the costs may be less and in other instances the costs may 
exceed this estimated cost range.
Costs to ONC
    We estimate that ONC would commit, on average and depending on 
complexity, between 40 and 320 hours of staff time to conducting 
actions under Sec.  170.565 related to ONC-ATLs. We assume that the 
expertise of a GS-15, Step 1 federal employee(s) would be necessary. 
Therefore, we estimate the cost for ONC would, on average, range from 
$4,910 to $39,277. We note that in some instances the costs may be less 
and in other instances the costs may exceed this estimated cost range.
(7) Costs for ONC-ACBs To Submit Identifiable Surveillance Results to 
the CHPL
    In this final rule, we require ONC-ACBs to submit identifiable 
surveillance results to the CHPL quarterly. We estimate that it will 
take an employee 20 hours annually to submit these identifiable 
surveillance results quarterly to the CHPL. The hourly wage with 
benefits for a GS-9, Step 1 federal employee located in Washington, DC, 
is approximately $51.20. Therefore, we estimate the annual cost for 
each ONC-ACB to report surveillance results to be $1,024 and the total 
cost for all three ONC-ACBs to be $3,072. In comparison, the average 
hourly wage with benefits for a ``Computer Support Specialist'' under 
NAICS 541380, Testing Laboratories, is $55.90.\30\ Therefore, the BLS 
estimate for the annual cost for each ONC-ACB to report identifiable 
surveillance results quarterly is $1,118 and the total cost for all 
three ONC-ACBs is $3,354.
---------------------------------------------------------------------------

    \30\ http://www.bls.gov/oes/current/naics5_541380.htm#15-0000.
---------------------------------------------------------------------------

    We note that ONC may incur a cost for hosting the CHPL, but we have 
not estimated this cost because ONC already hosts the CHPL and any 
additional cost associated with this final rule is nominal. Similarly, 
we note that ONC may incur a cost for updating the CHPL due to the new 
requirements in this final rule, but we have not estimated

[[Page 72462]]

these costs because the CHPL has already been updated for the current 
posting of non-conforming findings and CAPs. As such, any additional 
cost associated with this final rule will be nominal.
(8) Total Annual Cost Estimate
    We estimate the overall annual cost for this final rule, based on 
the cost estimates outlined above, will range from $171,011 to 
$650,352,050 with an average annual cost of $6,597,033.
b. Benefits
    The final rule's provisions for ONC direct review of certified 
health IT will promote health IT developers' accountability for the 
performance, reliability, and safety of certified health IT; and 
facilitate the use of safer and more reliable health IT by health care 
providers and patients. Specifically, ONC's direct review of certified 
health IT will facilitate ONC's assessment of non-conformities and 
ability to require comprehensive corrective actions for health IT 
developers to address non-conformities determined by ONC, including 
notifying affected customers. We emphasize that our first and foremost 
goal is to work with health IT developers to remedy any non-
conformities with certified health IT in a timely manner and across all 
customers. If ONC ultimately suspends and/or terminates a certification 
issued to a Complete EHR or Health IT Module under the provisions in 
this final rule, such action will serve to protect the integrity of the 
Program and users of health IT. While we do not have available means to 
quantify the benefits of ONC direct review of certified health IT, we 
note that ONC direct review supports and enables the National 
Coordinator to fulfill his or her responsibilities under the HITECH 
Act, instills public confidence in the Program, and protects public 
health and safety.
    This final rule's provisions will provide other benefits as well. 
The provisions for ONC to authorize and oversee testing labs (ONC-ATLs) 
will facilitate further public confidence in testing and certification 
by facilitating ONC's ability to timely and directly address testing 
issues for health IT. The public availability of identifiable 
surveillance results will enhance transparency and the accountability 
of health IT developers to their customers. We note that this will 
provide customers and users of certified health IT with valuable 
information about the continued conformity of certified health IT. 
Further, the public availability of identifiable surveillance results 
will likely benefit health IT developers by providing a more complete 
context of surveillance in the health IT industry and illuminating good 
performance and the continued conformity of certified health IT with 
Program requirements. Again, while we do not have available means to 
quantify these benefits, we maintain that these approaches will improve 
Program conformity and compliance as well as further public confidence 
in certified health IT.
    We note that we do not have data to establish how often we will 
need to exercise direct review, the extent of existing and future non-
conformities, and the likely outcomes of ONC review, including up to 
preventing the loss of life. We also note that we do not have data to 
establish that the provisions for direct oversight of testing labs and 
the public availability of identifiable surveillance results would 
actually result in greater public confidence in certified health IT and 
increased adoption of certified health IT.
c. Accounting Statement and Table
    When a rule is considered an economically significant rule under 
Executive Order 12866, we are required to develop an accounting 
statement indicating the classification of the expenditures associated 
with the provisions of this final rule. Monetary annualized benefits 
are presented as discounted flows using 3 percent and 7 percent factors 
in table 4 below. We are not able to explicitly define the universe of 
all costs, but have provided an average of likely costs of this final 
rule as well as a high and low range of likely costs. This final rule 
requires no federal annualized monetized transfers.

                                                              Table 4--Accounting Statement
--------------------------------------------------------------------------------------------------------------------------------------------------------
 
--------------------------------------------------------------------------------------------------------------------------------------------------------
                                                                                                                                           Source
--------------------------------------------------------------------------------------------------------------------------------------------------------
                                                                        BENEFITS
--------------------------------------------------------------------------------------------------------------------------------------------------------
Qualitative, but not monetized....      Expected qualitative benefits include: health IT developer accountability for the performance,     RIA
                                       reliability, and safety of certified health IT; the use of safer and more reliable health IT by
                                       health care providers and patients; and further public confidence in testing and certification.
--------------------------------------------------------------------------------------------------------------------------------------------------------
                                                                          COSTS
--------------------------------------------------------------------------------------------------------------------------------------------------------
Annualized monetized costs........    Year dollar               Estimates (in millions)              Unit discount      Period covered
                                                                                                         rate
                                   -------------------------------------------------------------------------------------------------------
                                                          Low            Mean            High                                              .............
                                                   ------------------------------------------------
                                              2015             .17            6.60          650.35              7%  One year.............  RIA
                                    ..............             .17            6.60          650.35              3%
--------------------------------------------------------------------------------------------------------------------------------------------------------
                                                                        TRANSFERS
--------------------------------------------------------------------------------------------------------------------------------------------------------
From Whom To Whom?................                                                           N/A
--------------------------------------------------------------------------------------------------------------------------------------------------------

    2. Regulatory Flexibility Act
    The Regulatory Flexibility Act (RFA) requires agencies to analyze 
options for regulatory relief of small businesses if a rule has a 
significant impact on a substantial number of small entities. The Small 
Business Administration (SBA) establishes the size of small businesses 
for federal government programs based on average annual receipts or the 
average employment of a firm.\31\ The entities that are likely to be

[[Page 72463]]

directly affected by this final rule are applicants for ONC-ATL status 
and health IT developers.
---------------------------------------------------------------------------

    \31\ The SBA references that annual receipts means ``total 
income'' (or in the case of a sole proprietorship, ``gross income'') 
plus ``cost of goods sold'' as these terms are defined and reported 
on Internal Revenue Service tax return forms.
---------------------------------------------------------------------------

    We estimate up to eight applicants for ONC-ATL status. These 
applicants are classified under the North American Industry 
Classification System (NAICS) codes 541380 (Testing Laboratories) 
specified at 13 CFR 121.201 where the SBA publishes ``Small Business 
Size Standards by NAICS Industry.'' \32\ The SBA size standard 
associated with this NAICS code is set at $15 million annual receipts 
or less. As specified in section VI.C.(5) of this final rule's 
preamble, we estimate minimal costs for applicants for ONC-ATL status 
to apply and participate in the Program as ONC-ATLs. We have finalized 
the minimum amount of requirements necessary to accomplish our goal of 
enhanced oversight of testing under the Program. As discussed in 
section VI.B of this final rule, we emphasize that there are also no 
appropriate regulatory or non-regulatory alternatives that could be 
developed to lessen the compliance burden associated with this final 
rule. We further note that we expect all of the estimated costs to be 
recouped by those applicants that become ONC-ATLs through the fees they 
charge for testing health IT under the Program.
---------------------------------------------------------------------------

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

    While health IT developers that pursue certification of their 
health IT under the Program represent a small segment of the overall 
information technology industry, we believe that many health IT 
developers impacted by this final rule most likely fall under NAICS 
code 541511 ``Custom Computer Programming Services.'' \33\ The SBA size 
standard associated with this NAICS code is set at $27.5 million annual 
receipts or less. There is enough data generally available to establish 
that between 75% and 90% of entities that are categorized under NAICS 
code 541511 are under the SBA size standard. We also note that with the 
exception of aggregate business information available through the U.S. 
Census Bureau and the SBA related to NAICS code 541511, it appears that 
many health IT developers that pursue certification of their health IT 
under the Program are privately held or owned and do not regularly, if 
at all, make their specific annual receipts publicly available. As a 
result, it has been difficult to locate empirical data related to many 
of these health IT developers to correlate to the SBA size standard. 
However, although not perfectly correlated to the size standard for 
NAICS code 541511, we do have information indicating that over 60% of 
health IT developers that have had Complete EHRs and/or Health IT 
Modules certified to the 2011 Edition have less than 51 employees.
---------------------------------------------------------------------------

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

    We estimate that this final rule will have effects on health IT 
developers, some of which may be small entities, that have certified 
health IT or are likely to pursue certification of their health IT 
under the Program. This is because health IT developers may need to 
reassess their health IT to verify conformity with the Program 
requirements outlined in this final rule and they may have their 
certified health IT subjected to corrective action, suspension, and/or 
termination under the provisions of this final rule. We have, however, 
finalized the minimum amount of requirements necessary to accomplish 
our primary policy goals of enhancing Program oversight and health IT 
developer accountability for the performance, reliability, and safety 
of certified health IT. Further, as discussed in section VI.B of this 
final rule, there are no appropriate regulatory or non-regulatory 
alternatives that could be developed to lessen the compliance burden 
associated with this final rule.
    We do not believe that this final rule will create a significant 
impact on a substantial number of small entities. Additionally, the 
Secretary certifies that this final rule will not have a significant 
impact on a substantial number of small entities.
3. Executive Order 13132--Federalism
    Executive Order 13132 establishes certain requirements that an 
agency must meet when it promulgates a proposed rule (and subsequent 
final rule) that imposes substantial direct requirement costs on state 
and local governments, preempts state law, or otherwise has federalism 
implications. Nothing in this final rule imposes substantial direct 
compliance costs on state and local governments, preempts state law, or 
otherwise has federalism implications. We are not aware of any state 
laws or regulations that are contradicted or impeded by any of the 
provisions in this final rule.
4. Unfunded Mandates Reform Act of 1995
    Section 202 of the Unfunded Mandates Reform Act of 1995 requires 
that agencies assess anticipated costs and benefits before issuing any 
rule that imposes unfunded mandates on state, local, and tribal 
governments or the private sector requiring spending in any one year of 
$100 million in 1995 dollars, updated annually for inflation. The 
current inflation-adjusted statutory threshold is approximately $144 
million. While our estimated potential cost effects of this final rule 
reach the statutory threshold, we do not believe this final rule 
imposes unfunded mandates on state, local, and tribal governments or 
the private sector. We estimate the potential monetary costs for the 
private sector (health IT developers and health care providers) and 
note that the costs will be the result of a health IT developer not 
maintaining its certified health IT product's conformity with voluntary 
Program requirements and having its product's Complete EHR or Health IT 
Modules' certification(s) terminated. We further state that the minimal 
monetary cost estimates for ONC-ATLs derive from voluntary 
participation in the Program and will be recouped through fees charged 
for the testing of health IT under the Program.
    OMB reviewed this final rule.

List of Subjects in 45 CFR Part 170

    Computer technology, Electronic health record, Electronic 
information system, Electronic transactions, Health, Health care, 
Health information technology, Health insurance, Health records, 
Hospitals, Incorporation by reference, Laboratories, Medicaid, 
Medicare, Privacy, Reporting and recordkeeping requirements, Public 
health, Security.

    For the reasons set forth in the preamble, 45 CFR subtitle A, 
subchapter D, part 170, is amended as follows:

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

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

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


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


Sec.  170.299  Incorporation by reference.

    (a) Certain material is incorporated by reference into this subpart 
with the approval of the Director of the Federal Register under 5 
U.S.C. 552(a) and 1 CFR part 51. To enforce any edition other than that 
specified in this section, the Department of Health and Human Services 
must publish a document in the Federal Register and the material must 
be available to the public. All approved material is available for 
inspection at U.S. Department of Health and Human Services, Office of 
the

[[Page 72464]]

National Coordinator for Health Information Technology, 330 C Street 
SW., Washington, DC 20201, call ahead to arrange for inspection at 202-
690-7151, and is available from the sources listed below. It is also 
available for inspection at the National Archives and Records 
Administration (NARA). For information on the availability of this 
material at NARA, call 202-741-6030 or go to http://www.archives.gov/federal_register/code_of_federal_regulations/ibr_locations.html.
* * * * *

0
3. Revise Sec.  170.501 to read as follows:


Sec.  170.501  Applicability.

    (a) This subpart establishes the processes that applicants for ONC-
ACB status must follow to be granted ONC-ACB status by the National 
Coordinator; the processes the National Coordinator will follow when 
assessing applicants and granting ONC-ACB status; the requirements that 
ONC-ACBs must follow to maintain ONC-ACB status; and the requirements 
of ONC-ACBs for certifying Complete EHRs, Health IT Module(s), and 
other types of health IT in accordance with the applicable 
certification criteria adopted by the Secretary in subpart C of this 
part.
    (b) This subpart establishes the processes that applicants for ONC-
ATL status must follow to be granted ONC-ATL status by the National 
Coordinator; the processes the National Coordinator will follow when 
assessing applicants and granting ONC-ATL status; the requirements that 
ONC-ATLs must follow to maintain ONC-ATL status; and the requirements 
of ONC-ATLs for testing Complete EHRs and Health IT Modules in 
accordance with the applicable certification criteria adopted by the 
Secretary in subpart C of this part.
    (c) This subpart establishes the processes accreditation 
organizations must follow to request approval from the National 
Coordinator to be an ONC-AA and that the National Coordinator will 
follow to approve an accreditation organization under the ONC Health IT 
Certification Program as well as certain ongoing responsibilities for 
an ONC-AA.
    (d) This subpart establishes the processes the National Coordinator 
will follow when exercising direct review of certified health IT and 
related requirements for ONC-ACBs, ONC-ATLs, and developers of health 
IT certified under the ONC Health IT Certification Program.

0
4. Amend Sec.  170.502 by revising the definitions of ``Applicant'' and 
``Gap certification'' and by adding the definition of ``ONC-Authorized 
Testing Lab or ONC-ATL'' in alphabetical order to read as follows:


Sec.  170.502  Definitions.

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

0
5. Revise Sec.  170.505 to read as follows:


Sec.  170.505  Correspondence.

    (a) Correspondence and communication with ONC or the National 
Coordinator shall be conducted by email, unless otherwise necessary or 
specified. The official date of receipt of any email between ONC or the 
National Coordinator and an accreditation organization requesting ONC-
AA status, the ONC-AA, an applicant for ONC-ACB status, an applicant 
for ONC-ATL status, an ONC-ACB, an ONC-ATL, health IT developer, or a 
party to any proceeding under this subpart is the date on which the 
email was sent.
    (b) In circumstances where it is necessary for an accreditation 
organization requesting ONC-AA status, the ONC-AA, an applicant for 
ONC-ACB status, an applicant for ONC-ATL status, an ONC-ACB, an ONC-
ATL, health IT developer, or a party to any proceeding under this 
subpart to correspond or communicate with ONC or the National 
Coordinator by regular, express, or certified mail, the official date 
of receipt for all parties will be the date of the delivery 
confirmation to the address on record.

0
6. Amend Sec.  170.510 by revising the section heading and introductory 
text to read as follows:


Sec.  170.510  Authorization scope for ONC-ACB status.

    Applicants for ONC-ACB status may seek authorization from the 
National Coordinator to perform the following types of certification:
* * * * *

0
7. Add Sec.  170.511 to read as follows:


Sec.  170.511  Authorization scope for ONC-ATL status.

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

0
8. Revise Sec.  170.520 to read as follows:


Sec.  170.520  Application.

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

[[Page 72465]]

    (1) The authorization scope sought pursuant to Sec.  170.511.
    (2) General identifying, information including:
    (i) Name, address, city, state, zip code, and Web site of 
applicant; and
    (ii) Designation of an authorized representative, including name, 
title, phone number, and email address of the person who will serve as 
the applicant's point of contact.
    (3) Documentation that confirms that the applicant has been 
accredited by NVLAP to the ONC Health IT Certification Program, 
including to ISO/IEC 17025 (incorporated by reference, see Sec.  
170.599).
    (4) An agreement, properly executed by the applicant's authorized 
representative, that it will adhere to the Principles of Proper Conduct 
for ONC-ATLs.

0
9. Amend Sec.  170.523 by revising paragraphs (h) and (i) and adding 
paragraph (o) to read as follows:


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

* * * * *
    (h) Only certify health IT (Complete EHRs and/or Health IT Modules) 
that has been tested, using test tools and test procedures approved by 
the National Coordinator, by a/an:
    (1) ONC-ATL;
    (2) NVLAP-accredited testing laboratory under the ONC Health IT 
Certification Program for no longer than six months from December 19, 
2016; or
    (3) ONC-ATL, NVLAP-accredited testing laboratory under the ONC 
Health IT Certification Program, and/or an ONC-ATCB for the purposes 
of:
    (i) Certifying previously certified Complete EHRs and/or Health IT 
Module(s) if the certification criterion or criteria to which the 
Complete EHRs and/or Health IT Module(s) was previously certified have 
not been revised and no new certification criteria are applicable to 
the Complete EHRs and/or Health IT Module(s); or
    (ii) Performing gap certification.
    (i) Conduct surveillance of certified health IT in accordance with 
its accreditation, Sec.  170.556, and the following requirements:
    (1) Submit an annual surveillance plan to the National Coordinator.
    (2) Report, at a minimum, on a quarterly basis to the National 
Coordinator the results of its surveillance, including surveillance 
results that identify:
    (i) The names of health IT developers;
    (ii) Names of products and versions;
    (iii) Certification criteria and ONC Health IT Certification 
Program requirements surveilled;
    (iv) The type of surveillance (i.e., reactive or randomized);
    (v) The dates surveillance was initiated and completed; and
    (vi) As applicable, the number of sites that were used in 
randomized surveillance.
    (3) Annually submit a summative report of surveillance results to 
the National Coordinator.
* * * * *
    (o) Be prohibited from reducing the scope of a Complete EHR or 
Health IT Module's certification when it is under surveillance or under 
a corrective action plan.

0
10. Add Sec.  170.524 to read as follows:


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

    An ONC-ATL shall:
    (a) Maintain its NVLAP accreditation for the ONC Health IT 
Certification Program, including accreditation to ISO/IEC 17025 
(incorporated by reference, see Sec.  170.599);
    (b) Attend all mandatory ONC training and program update sessions;
    (c) Maintain a training program that includes documented procedures 
and training requirements to ensure its personnel are competent to test 
health IT;
    (d) Report to ONC within 15 days any changes that materially affect 
its:
    (1) Legal, commercial, organizational, or ownership status;
    (2) Organization and management including key testing personnel;
    (3) Policies or procedures;
    (4) Location;
    (5) Personnel, facilities, working environment or other resources;
    (6) ONC authorized representative (point of contact); or
    (7) Other such matters that may otherwise materially affect its 
ability to test health IT.
    (e) Allow ONC, or its authorized agent(s), to periodically observe 
on site (unannounced or scheduled), during normal business hours, any 
testing performed pursuant to the ONC Health IT Certification Program;
    (f) Records retention:
    (1) Retain all records related to the testing of Complete EHRs and/
or Health IT Modules to an edition of certification criteria for a 
minimum of 3 years from the effective date that removes the applicable 
edition from the Code of Federal Regulations; and
    (2) Make the records available to HHS upon request during the 
retention period described in paragraph (f)(1) of this section;
    (g) Only test health IT using test tools and test procedures 
approved by the National Coordinator; and
    (h) Promptly refund any and all fees received for:
    (1) Requests for testing that are withdrawn while its operations 
are suspended by the National Coordinator;
    (2) Testing that will not be completed as a result of its conduct; 
and
    (3) Previous testing that it performed if its conduct necessitates 
the retesting of Complete EHRs and/or Health IT Modules.

0
11. Revise Sec.  170.525 to read as follows:


Sec.  170.525  Application submission.

    (a) An applicant for ONC-ACB or ONC-ATL status must submit its 
application either electronically via email (or Web site submission if 
available), or by regular or express mail.
    (b) An application for ONC-ACB or ONC-ATL status may be submitted 
to the National Coordinator at any time.

0
12. Amend Sec.  170.530 by revising paragraphs (c)(2) and (4) and 
(d)(2) and (3) to read as follows:


Sec.  170.530  Review of application.

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

[[Page 72466]]

applicable) and begin certifying or testing (as applicable) health 
information technology consistent with its authorization.

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


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

    (a) Basis for reconsideration request. An applicant may request 
that the National Coordinator reconsider a denial notice only if the 
applicant can demonstrate that clear, factual errors were made in the 
review of its application and that the errors' correction could lead to 
the applicant obtaining ONC-ACB or ONC-ATL status.
* * * * *
    (d) * * *
    (1) If the National Coordinator determines that clear, factual 
errors were made during the review of the application and that 
correction of the errors would remove all identified deficiencies, the 
applicant's authorized representative will be notified of the National 
Coordinator's determination and the applicant's successful achievement 
of ONC-ACB or ONC-ATL status.
* * * * *

0
14. Revise Sec.  170.540 to read as follows:


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

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

0
15. Amend Sec.  170.556 by revising paragraph (d)(6) and (e)(1) to read 
as follows:


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

* * * * *
    (d) * * *
    (6) Withdrawal. If a certified Complete EHR or certified Health IT 
Module's certification has been suspended, an ONC-ACB is permitted to 
initiate certification withdrawal procedures for the Complete EHR or 
Health IT Module (consistent with its accreditation to ISO/IEC 17065 
and procedures for withdrawing a certification) when the health IT 
developer has not completed the actions necessary to reinstate the 
suspended certification.
    (e) * * *
    (1) Rolling submission of in-the-field surveillance results. The 
results of in-the-field surveillance under this section must be 
submitted to the National Coordinator, at a minimum, on a quarterly 
basis in accordance with Sec.  170.523(i)(2).
* * * * *

0
16. Revise Sec.  170.557 to read as follows:


Sec.  170.557  Authorized testing and certification methods.

    (a) ONC-ATL applicability. An ONC-ATL must provide remote testing 
for both development and deployment sites.
    (b) ONC-ACB applicability. An ONC-ACB must provide remote 
certification for both development and deployment sites.

0
17. Revise Sec.  170.560 to read as follows:


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

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

0
18. Revise Sec.  170.565 to read as follows:


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

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

[[Page 72467]]

ACB failed to demonstrate that no violation occurred or to correct the 
area(s) of non-compliance identified under paragraph (b)(1) of this 
section within 30 days of receipt of the noncompliance notification, 
then the National Coordinator may propose to revoke the ONC-ATL or ONC-
ACB's status.
    (c) Proposed revocation. (1) The National Coordinator may propose 
to revoke an ONC-ATL or ONC-ACB's status if the National Coordinator 
has reliable evidence that the ONC-ATL or ONC-ACB has committed a Type-
1 violation; or
    (2) The National Coordinator may propose to revoke an ONC-ATL or 
ONC-ACB's status if, after the ONC-ATL or ONC-ACB has been notified of 
a Type-2 violation, the ONC-ATL or ONC-ACB fails to:
    (i) Rebut the finding of a violation with sufficient evidence 
showing that the violation did not occur or that the violation has been 
corrected; or
    (ii) Submit to the National Coordinator a written response to the 
noncompliance notification within the specified timeframe under 
paragraph (b)(2) of this section.
    (d) Suspension of an ONC-ATL or ONC-ACB's operations. (1) The 
National Coordinator may suspend the operations of an ONC-ATL or ONC-
ACB under the ONC Health IT Certification Program based on reliable 
evidence indicating that:
    (i) Applicable to both ONC-ACBs and ONC-ATLs. The ONC-ATL or ONC-
ACB committed a Type-1 or Type-2 violation;
    (ii) Applicable to ONC-ACBs. The continued certification of 
Complete EHRs or Health IT Modules by the ONC-ACB could have an adverse 
impact on the health or safety of patients.
    (iii) Applicable to ONC-ATLs. The continued testing of Complete 
EHRs or Health IT Modules by the ONC-ATL could have an adverse impact 
on the health or safety of patients.
    (2) If the National Coordinator determines that the conditions of 
paragraph (d)(1) of this section have been met, an ONC-ATL or ONC-ACB 
will be issued a notice of proposed suspension.
    (3) Upon receipt of a notice of proposed suspension, an ONC-ATL or 
ONC-ACB will be permitted up to 3 days to submit a written response to 
the National Coordinator explaining why its operations should not be 
suspended.
    (4) The National Coordinator is permitted up to 5 days from receipt 
of an ONC-ATL or ONC-ACB's written response to a notice of proposed 
suspension to review the response and make a determination.
    (5) The National Coordinator may make one of the following 
determinations in response to the ONC-ATL or ONC-ACB's written response 
or if the ONC-ATL or ONC-ACB fails to submit a written response within 
the timeframe specified in paragraph (d)(3) of this section:
    (i) Rescind the proposed suspension; or
    (ii) Suspend the ONC-ATL or ONC-ACB's operations until it has 
adequately corrected a Type-2 violation; or
    (iii) Propose revocation in accordance with paragraph (c) of this 
section and suspend the ONC-ATL or ONC-ACB's operations for the 
duration of the revocation process.
    (6) A suspension will become effective upon an ONC-ATL or ONC-ACB's 
receipt of a notice of suspension.
    (e) Opportunity to respond to a proposed revocation notice. (1) An 
ONC-ATL or ONC-ACB may respond to a proposed revocation notice, but 
must do so within 10 days of receiving the proposed revocation notice 
and include appropriate documentation explaining in writing why its 
status should not be revoked.
    (2) Upon receipt of an ONC-ATL or ONC-ACB's response to a proposed 
revocation notice, the National Coordinator is permitted up to 30 days 
to review the information submitted by the ONC-ACB or ONC-ATL and reach 
a decision.
    (f) Good standing determination. If the National Coordinator 
determines that an ONC-ATL or ONC-ACB's status should not be revoked, 
the National Coordinator will notify the ONC-ATL or ONC-ACB's 
authorized representative in writing of this determination.
    (g) Revocation. (1) The National Coordinator may revoke an ONC-ATL 
or ONC-ACB's status if:
    (i) A determination is made that revocation is appropriate after 
considering the information provided by the ONC-ATL or ONC-ACB in 
response to the proposed revocation notice; or
    (ii) The ONC-ATL or ONC-ACB does not respond to a proposed 
revocation notice within the specified timeframe in paragraph (e)(1) of 
this section.
    (2) A decision to revoke an ONC-ATL or ONC-ACB's status is final 
and not subject to further review unless the National Coordinator 
chooses to reconsider the revocation.
    (h) Extent and duration of revocation--(1) Effectuation. The 
revocation of an ONC-ATL or ONC-ACB is effective as soon as the ONC-ATL 
or ONC-ACB receives the revocation notice.
    (2) ONC-ACB provisions. (i) A certification body that has had its 
ONC-ACB status revoked is prohibited from accepting new requests for 
certification and must cease its current certification operations under 
the ONC Health IT Certification Program.
    (ii) A certification body that has had its ONC-ACB status revoked 
for a Type-1 violation is not permitted to reapply for ONC-ACB status 
under the ONC Health IT Certification Program for a period of 1 year.
    (iii) The failure of a certification body that has had its ONC-ACB 
status revoked to promptly refund any and all fees for certifications 
of Complete EHRs and Health IT Module(s) not completed will be 
considered a violation of the Principles of Proper Conduct for ONC-ACBs 
and will be taken into account by the National Coordinator if the 
certification body reapplies for ONC-ACB status under the ONC Health IT 
Certification Program.
    (3) ONC-ATL provisions. (i) A testing lab that has had its ONC-ATL 
status revoked is prohibited from accepting new requests for testing 
and must cease its current testing operations under the ONC Health IT 
Certification Program.
    (ii) A testing lab that has had its ONC-ATL status revoked for a 
Type-1 violation is not permitted to reapply for ONC-ATL status under 
the ONC Health IT Certification Program for a period of 1 year.
    (iii) The failure of a testing lab that has had its ONC-ATL status 
revoked to promptly refund any and all fees for testing of health IT 
not completed will be considered a violation of the Principles of 
Proper Conduct for ONC-ATLs and will be taken into account by the 
National Coordinator if the testing lab reapplies for ONC-ATL status 
under the ONC Health IT Certification Program.

0
19. Revise Sec.  170.570 to read as follows:


Sec.  170.570  Effect of revocation on the certifications issued to 
Complete EHRs and EHR Module(s).

    (a) The certified status of Complete EHRs and/or Health IT 
Module(s) certified by an ONC-ACB or tested by an ONC-ATL that had its 
status revoked will remain intact unless a Type-1 violation was 
committed by the ONC-ACB and/or ONC-ATL that calls into question the 
legitimacy of the certifications issued.
    (b) If the National Coordinator determines that a Type-1 violation 
was committed by an ONC-ACB and/or ONC-ATL that called into question 
the legitimacy of certifications issued to

[[Page 72468]]

health IT, then the National Coordinator would:
    (1) Review the facts surrounding the revocation of the ONC-ACB's or 
ONC-ATL's status; and
    (2) Publish a notice on ONC's Web site if the National Coordinator 
believes that the Complete EHRs and/or Health IT Module(s) 
certifications were based on unreliable testing and/or certification.
    (c) If the National Coordinator determines that Complete EHRs and/
or Health IT Module(s) certifications were based on unreliable testing 
and/or certification, the certification status of affected Complete 
EHRs and/or Health IT Module(s) would only remain intact for 120 days 
after the National Coordinator publishes the notice.
    (1) The certification status of affected Complete EHRs and/or 
Health IT Module(s) can only be maintained after the 120-day timeframe 
by being re-tested by an ONC-ATL in good standing, as necessary, and 
re-certified by an ONC-ACB in good standing.
    (2) The National Coordinator may extend the time that the 
certification status of affected Complete EHRs and/or Health IT 
Module(s) remains intact as necessary for the proper retesting and 
recertification of the affected health IT.

0
20. Add Sec.  170.580 to read as follows:


Sec.  170.580  ONC review of certified health IT.

    (a) Direct review--(1) Purpose. ONC may directly review certified 
health IT to determine whether it conforms to the requirements of the 
ONC Health IT Certification Program.
    (2) Circumstances that may trigger review--(i) Unsafe conditions. 
ONC may initiate direct review under this section if it has a 
reasonable belief that certified health IT may not conform to the 
requirements of the Program because the certified health IT may be 
causing or contributing to conditions that present a serious risk to 
public health or safety, taking into consideration--
    (A) The potential nature, severity, and extent of the suspected 
conditions;
    (B) The need for an immediate or coordinated governmental response; 
and
    (C) If applicable, information that calls into question the 
validity of the health IT's certification or maintenance thereof under 
the Program.
    (ii) Impediments to ONC-ACB oversight. ONC may initiate direct 
review under this section if it has a reasonable belief that certified 
health IT may not conform to requirements of the Program and the 
suspected non-conformity presents issues that--
    (A) May require access to confidential or other information that is 
not available to an ONC-ACB;
    (B) May require concurrent or overlapping review by two or more 
ONC-ACBs; or
    (C) May exceed an ONC-ACB's resources or expertise.
    (3) Relationship to ONC-ACBs and ONC-ATLs. (i) ONC's review of 
certified health IT is independent of, and may be in addition to, any 
surveillance conducted by an ONC-ACB.
    (ii) ONC may assert exclusive review of certified health IT as to 
any matters under review by ONC and any similar matters under 
surveillance by an ONC-ACB.
    (iii) ONC's determination on matters under its review is 
controlling and supersedes any determination by an ONC-ACB on the same 
matters.
    (iv) An ONC-ACB and ONC-ATL shall provide ONC with any available 
information that ONC deems relevant to its review of certified health 
IT.
    (v) ONC may end all or any part of its review of certified health 
IT under this section at any time and refer the applicable part of the 
review to the relevant ONC-ACB(s) if ONC determines that doing so would 
serve the effective administration or oversight of the ONC Health IT 
Certification Program.
    (b) Notice--(1) Notice of potential non-conformity--(i) 
Circumstances that may trigger notice of potential non-conformity. At 
any time during its review of certified health IT under paragraph (a) 
of this section, ONC may send a notice of potential non-conformity if 
it has a reasonable belief that certified health IT may not conform to 
the requirements of the ONC Health IT Certification Program.
    (ii) Health IT developer response. (A) The health IT developer must 
respond to the notice of potential non-conformity by:
    (1) Cooperating with ONC and/or a third party acting on behalf of 
ONC;
    (2) Providing ONC and/or a third party acting on behalf of ONC 
access, including in accordance with paragraph (b)(3) of this section, 
to the certified health IT under review;
    (3) Providing ONC with a written explanation and all supporting 
documentation addressing the potential non-conformity within 30 days, 
or within the adjusted timeframe set in accordance with paragraph 
(b)(1)(ii)(B) of this section.
    (B) ONC may adjust the 30-day timeframe specified in paragraph 
(b)(1)(ii)(A)(3) of this section to be shorter or longer based on 
factors including, but not limited to:
    (1) The type of certified health IT and certification in question;
    (2) The type of potential non-conformity to be corrected;
    (3) The time required to correct the potential non-conformity; and
    (4) Issues of public health or safety.
    (iii) ONC determination. After receiving the health IT developer's 
written explanation and supporting documentation as required by 
paragraph (b)(1)(ii)(A)(3) of this section, ONC shall do one of the 
following:
    (A) Issue a written determination ending its review.
    (B) Request additional information and continue its review in 
accordance with a new timeframe ONC establishes under (b)(1)(ii)(A)(3) 
and (b)(1)(ii)(B) of this section.
    (C) Substantiate a non-conformity and issue a notice of non-
conformity.
    (D) Issue a notice of proposed termination.
    (2) Notice of non-conformity--(i) Circumstances that may trigger 
notice of non-conformity. At any time during its review of certified 
health IT under paragraph (a) of this section, ONC may send a notice of 
non-conformity to the health IT developer if it determines that 
certified health IT does not conform to the requirements of the ONC 
Health IT Certification Program.
    (ii) Health IT developer response. (A) The health IT developer must 
respond to the notice of non-conformity by:
    (1) Cooperating with ONC and/or a third party acting on behalf of 
ONC;
    (2) Providing ONC and/or a third party acting on behalf of ONC 
access, including in accordance with paragraph (b)(3) of this section, 
to the certified health IT under review;
    (3) Providing ONC with a written explanation and all supporting 
documentation addressing the non-conformity within 30 days, or within 
the adjusted timeframe set in accordance with paragraph (b)(1)(ii)(B) 
of this section; and
    (4) Providing a proposed corrective action plan consistent with 
paragraph (c) of this section.
    (B) ONC may adjust the 30-day timeframe specified in paragraph 
(b)(2)(ii)(A)(3) of this section to be shorter or longer based on 
factors including, but not limited to:
    (1) The type of certified health IT and certification in question;
    (2) The type of non-conformity to be corrected;
    (3) The time required to correct the non-conformity; and
    (4) Issues of public health or safety.
    (iii) ONC determination. After receiving the health IT developer's 
response provided in accordance with paragraph (b)(2)(ii) of this 
section, ONC shall either issue a written

[[Page 72469]]

determination ending its review or continue with its review under the 
provisions of this section.
    (3) Records access. In response to a notice of potential non-
conformity or notice of non-conformity, a health IT developer shall 
make available to ONC and for sharing within HHS, with other federal 
departments, agencies, and offices, and with appropriate entities 
including, but not limited to, third-parties acting on behalf of ONC:
    (i) All records related to the development, testing, certification, 
implementation, maintenance and use of its certified health IT; and
    (ii) Any complaint records related to the certified health IT.
    (c) Corrective action plan and procedures. (1) If ONC determines 
that certified health IT does not conform to requirements of the ONC 
Health IT Certification Program, ONC shall notify the health IT 
developer of its determination and require the health IT developer to 
submit a proposed corrective action plan.
    (2) ONC shall provide direction to the health IT developer as to 
the required elements of the corrective action plan, which shall 
include such required elements as ONC determines necessary to 
comprehensively and expeditiously resolve the identified non-
conformity(ies). The corrective action plan shall, in all cases, at a 
minimum include the following required elements:
    (i) An assessment and description of the nature, severity, and 
extent of the non-conformity;
    (ii) Identification of all potentially affected customers;
    (iii) A detailed description of how the health IT developer will 
promptly ensure that all potentially affected customers are notified of 
the non-conformity and plan for resolution;
    (iv) A detailed description of how and when the health IT developer 
will resolve the identified non-conformity and all issues, both at the 
locations where the non-conformity was identified and for all affected 
customers;
    (v) A detailed description of how the health IT developer will 
ensure that the identified non-conformity and all issues are resolved;
    (vi) A detailed description of the supporting documentation that 
will be provided to demonstrate that the identified non-conformity and 
all issues are resolved; and
    (vii) The timeframe under which all elements of the corrective 
action plan will be completed.
    (viii) An explanation of, and agreement to execute, the steps that 
will be prevent the non-conformity from re-occurring.
    (3) When ONC receives a proposed corrective action plan (or a 
revised proposed corrective action plan), it shall either approve the 
proposed corrective action plan or, if the plan does not adequately 
address all required elements, instruct the health IT developer to 
submit a revised proposed corrective action plan within a specified 
period of time.
    (4) The health IT developer is responsible for ensuring that a 
proposed corrective action plan submitted in accordance with paragraph 
(b)(2)(ii)(A)(4) of this section or a revised corrective action plan 
submitted in accordance with paragraph (c)(3) of this section 
adequately addresses all required elements as determined by ONC no 
later than 90 days after the health IT developer's receipt of a notice 
of non-conformity.
    (5) Health IT developers may request extensions for the submittal 
and/or completion of corrective action plans. In order to make these 
requests, health IT developers must submit a written statement to ONC 
that explains and justifies the extension request. ONC will evaluate 
each request individually and will make decisions on a case-by-case 
basis.
    (6) Upon fulfilling all of its obligations under the corrective 
action plan, the health IT developer must submit an attestation to ONC, 
which serve as a binding official statement by the health IT developer 
that it has fulfilled all of its obligations under the corrective 
action plan.
    (7) ONC may reinstitute a corrective action plan if it later 
determines that a health IT developer has not fulfilled all of its 
obligations under the corrective action plan as attested in accordance 
with paragraph (c)(6) of this section.
    (d) Suspension. (1) ONC may suspend the certification of a Complete 
EHR or Health IT Module at any time if ONC has a reasonable belief that 
the certified health IT may present a serious risk to public health or 
safety.
    (2) When ONC decides to suspend a certification, ONC will notify 
the health IT developer of its determination through a notice of 
suspension.
    (i) The notice of suspension will include, but may not be limited 
to:
    (A) An explanation for the suspension;
    (B) Information supporting the determination;
    (C) The consequences of suspension for the health IT developer and 
the Complete EHR or Health IT Module under the ONC Health IT 
Certification Program; and
    (D) Instructions for appealing the suspension.
    (ii) A suspension of a certification will become effective upon the 
date specified in the notice of suspension.
    (3) The health IT developer must notify all potentially affected 
customers of the identified non-conformity(ies) and suspension of 
certification in a timely manner.
    (4) When a certification is suspended, the health IT developer must 
cease and desist from any marketing, licensing, and sale of the 
suspended Complete EHR or Health IT Module as ``certified'' under the 
ONC Health IT Certification Program from that point forward until such 
time ONC cancels the suspension in accordance with paragraph (d)(6) of 
this section.
    (5) The certification of any health IT produced by a health IT 
developer that has the certification of one of its Complete EHRs or 
Health IT Modules suspended under the Program is prohibited, unless ONC 
cancels a suspension in accordance with paragraph (d)(6) of this 
section.
    (6) ONC may cancel a suspension at any time if ONC no longer has a 
reasonable belief that the certified health IT presents a serious risk 
to public health or safety.
    (e) Proposed termination. (1) ONC may propose to terminate a 
certification issued to a Complete EHR and/or Health IT Module if:
    (i) The health IT developer fails to timely respond to any 
communication from ONC, including, but not limited to:
    (A) Fact-finding;
    (B) A notice of potential non-conformity within the timeframe 
established in accordance with paragraph (b)(1)(ii)(A)(3) of this 
section;
    (C) A notice of non-conformity within the timeframe established in 
accordance with paragraph (b)(2)(ii)(A)(3) of this section; or
    (D) A notice of suspension.
    (ii) The information or access provided by the health IT developer 
in response to any ONC communication, including, but not limited to: 
Fact-finding, a notice of potential non-conformity, or a notice of non-
conformity is insufficient or incomplete;
    (iii) The health IT developer fails to cooperate with ONC and/or a 
third party acting on behalf of ONC;
    (iv) The health IT developer fails to timely submit in writing a 
proposed corrective action plan;
    (v) The health IT developer fails to timely submit a corrective 
action plan that adequately addresses the elements required by ONC as 
described in paragraph (c) of this section;
    (vi) The health IT developer does not fulfill its obligations under 
the

[[Page 72470]]

corrective action plan developed in accordance with paragraph (c) of 
this section; or
    (vii) ONC concludes that a certified health IT's non-
conformity(ies) cannot be cured.
    (2) When ONC decides to propose to terminate a certification, ONC 
will notify the health IT developer of the proposed termination through 
a notice of proposed termination.
    (i) The notice of proposed termination will include, but may not be 
limited to:
    (A) An explanation for the proposed termination;
    (B) Information supporting the proposed termination; and
    (C) Instructions for responding to the proposed termination.
    (3) The health IT developer may respond to a notice of proposed 
termination, but must do so within 10 days of receiving the notice of 
proposed termination and must include appropriate documentation 
explaining in writing why its certification should not be terminated.
    (4) Upon receipt of the health IT developer's written response to a 
notice of proposed termination, ONC has up to 30 days to review the 
information submitted by the health IT developer and make a 
determination. ONC may extend this timeframe if the complexity of the 
case requires additional time for ONC review. ONC will, as applicable:
    (i) Notify the health IT developer in writing that it has ceased 
all or part of its review of the health IT developer's certified health 
IT.
    (ii) Notify the health IT developer in writing of its intent to 
continue all or part of its review of the certified health IT under the 
provisions of this section.
    (iii) Proceed to terminate the certification of the health IT under 
review consistent with paragraph (f) of this section.
    (f) Termination. (1) The National Coordinator may terminate a 
certification if:
    (i) A determination is made that termination is appropriate after 
considering the information provided by the health IT developer in 
response to the proposed termination notice; or
    (ii) The health IT developer does not respond in writing to a 
proposed termination notice within the timeframe specified in paragraph 
(e)(3) of this section.
    (2) When ONC decides to terminate a certification, ONC will notify 
the health IT developer of its determination through a notice of 
termination.
    (i) The notice of termination will include, but may not be limited 
to:
    (A) An explanation for the termination;
    (B) Information supporting the determination;
    (C) The consequences of termination for the health IT developer and 
the Complete EHR or Health IT Module under the ONC Health IT 
Certification Program; and
    (D) Instructions for appealing the termination.
    (ii) A termination of a certification will become effective after 
the following applicable occurrence:
    (A) The expiration of the 10-day period for filing a statement of 
intent to appeal in paragraph (g)(3)(i) of this section if the health 
IT developer does not file a statement of intent to appeal.
    (B) The expiration of the 30-day period for filing an appeal in 
paragraph (g)(3)(ii) of this section if the health IT developer files a 
statement of intent to appeal, but does not file a timely appeal.
    (C) A final determination to terminate the certification per 
paragraph (g)(7) of this section if a health IT developer files an 
appeal.
    (3) The health IT developer must notify all potentially affected 
customers of the identified non-conformity(ies) and termination of 
certification in a timely manner.
    (4) ONC may rescind a termination determination before the 
termination becomes effective if ONC determines that termination is no 
longer appropriate.
    (g) Appeal--(1) Basis for appeal. A health IT developer may appeal 
an ONC determination to suspend or terminate a certification issued to 
a Complete EHR or Health IT Module if the health IT developer asserts:
    (i) ONC incorrectly applied ONC Health IT Certification Program 
requirements for suspension or termination; or
    (ii) ONC's determination was not sufficiently supported by the 
information provided by ONC with its determination.
    (2) Method and place for filing an appeal. A statement of intent to 
appeal followed by a request for appeal must be submitted to ONC in 
writing by an authorized representative of the health IT developer 
whose Complete EHR or Health IT Module was subject to the determination 
being appealed. The statement of intent to appeal and request for 
appeal must be filed in accordance with the requirements specified in 
the notice of termination or notice of suspension.
    (3) Time for filing a request for appeal. (i) A statement of intent 
to appeal must be filed within 10 days of a health IT developer's 
receipt of the notice of suspension or notice of termination.
    (ii) An appeal, including all supporting documentation, must be 
filed within 30 days of the filing of the intent to appeal.
    (4) Effect of appeal on suspension and termination. (i) A request 
for appeal stays the termination of a certification issued to a 
Complete EHR or Health IT Module, but the Complete EHR or Health IT 
Module is prohibited from being marketed, licensed, or sold as 
``certified'' during the stay.
    (ii) A request for appeal does not stay the suspension of a 
Complete EHR or Health IT Module.
    (5) Appointment of a hearing officer. The National Coordinator will 
assign the case to a hearing officer to adjudicate the appeal on his or 
her behalf.
    (i) The hearing officer may not review an appeal in which he or she 
participated in the initial suspension or termination determination or 
has a conflict of interest in the pending matter.
    (ii) The hearing officer must be trained in a nationally recognized 
ethics code that articulates nationally recognized standards of conduct 
for hearing officers/officials.
    (6) Adjudication. (i) The hearing officer may make a determination 
based on:
    (A) The written record, which includes the:
    (1) ONC determination and supporting information;
    (2) Information provided by the health IT developer with the appeal 
filed in accordance with paragraphs (g)(1) through (3) of this section; 
and
    (3) Information ONC provides in accordance with paragraph (g)(6)(v) 
of this section; or
    (B) All the information provided in accordance with paragraph 
(g)(6)(i)(A) and any additional information from a hearing conducted 
in-person, via telephone, or otherwise.
    (ii) The hearing officer will have the discretion to conduct a 
hearing if he/she:
    (A) Requires clarification by either party regarding the written 
record under paragraph (g)(6)(i)(A) of this section;
    (B) Requires either party to answer questions regarding the written 
record under paragraph (g)(6)(i)(A) of this section; or
    (C) Otherwise determines a hearing is necessary.
    (iii) The hearing officer will neither receive witness testimony 
nor accept any new information beyond what was provided in accordance 
with paragraph (g)(6)(i) of this section.
    (iv) The default process will be a determination in accordance with 
paragraph (g)(6)(i)(A) of this section.

[[Page 72471]]

    (v) ONC will have an opportunity to provide the hearing officer 
with a written statement and supporting documentation on its behalf 
that clarifies, as necessary, its determination to suspend or terminate 
the certification.
    (A) The written statement and supporting documentation must be 
included as part of the written record and provided to the health IT 
developer within 15 days of the health IT developer's filing of an 
intent to appeal.
    (B) Failure of ONC to submit a written statement does not result in 
any adverse findings against ONC and may not in any way be taken into 
account by the hearing officer in reaching a determination.
    (7) Determination by the hearing officer. (i) The hearing officer 
will issue a written determination to the health IT developer within 30 
days of receipt of the appeal or within a timeframe agreed to by the 
health IT developer and ONC and approved by the hearing officer, unless 
ONC cancels the suspension or rescinds the termination determination.
    (ii) The National Coordinator's determination on appeal, as issued 
by the hearing officer, is final and not subject to further review.

0
21. Add Sec.  170.581 to read as follows:


Sec.  170.581  Certification ban.

    (a) Ban. The certification of any of a health IT developer's health 
IT is prohibited when the certification of one or more of the health IT 
developer's Complete EHRs or Health IT Modules is:
    (1) Terminated by ONC under the ONC Health IT Certification 
Program;
    (2) Withdrawn from the ONC Health IT Certification Program by an 
ONC-ACB because the health IT developer requested it to be withdrawn 
when the health IT developer's health IT was the subject of a potential 
non-conformity or non-conformity as determined by ONC;
    (3) Withdrawn by an ONC-ACB because of a non-conformity with any of 
the certification criteria adopted by the Secretary under subpart C of 
this part; or
    (4) Withdrawn by an ONC-ACB because the health IT developer 
requested it to be withdrawn when the health IT developer's health IT 
was the subject of surveillance for a certification criterion or 
criteria adopted by the Secretary under subpart C of this part, 
including notice of pending surveillance.
    (b) Reinstatement. The certification of a health IT developer's 
health IT subject to the prohibition in paragraph (a) of this section 
may commence once the following conditions are met.
    (1) A health IT developer must request ONC's permission in writing 
to participate in the ONC Health IT Certification Program.
    (2) The request must demonstrate that the customers affected by the 
certificate termination or withdrawal have been provided appropriate 
remediation.
    (3) ONC is satisfied with the health IT developer's demonstration 
under paragraph (b)(2) of this section that all affected customers have 
been provided with appropriate remediation and grants reinstatement 
into the ONC Health IT Certification Program.

0
22. Revise Sec.  170.599 to read as follows:


Sec.  170.599  Incorporation by reference.

    (a) Certain material is incorporated by reference into this subpart 
with the approval of the Director of the Federal Register under 5 
U.S.C. 552(a) and 1 CFR part 51. To enforce any edition other than that 
specified in this section, the Department of Health and Human Services 
must publish a document in the Federal Register and the material must 
be available to the public. All approved material is available for 
inspection at U.S. Department of Health and Human Services, Office of 
the National Coordinator for Health Information Technology, 330 C 
Street SW., Washington, DC 20201, call ahead to arrange for inspection 
at 202-690-7151, and is available from the source listed below. It is 
also available for inspection at the National Archives and Records 
Administration (NARA). For information on the availability of this 
material at NARA, call 202-741-6030 or go to http://www.archives.gov/federal_register/code_of_federal_regulations/ibr_locations.html.
    (b) International Organization for Standardization, Case postale 
56, CH[middot]1211, Geneve 20, Switzerland, telephone +41-22-749-01-11, 
http://www.iso.org.
    (1) ISO/IEC GUIDE 65:1996--General Requirements for Bodies 
Operating Product Certification Systems (First Edition), 1996, ``ISO/
IEC Guide 65,'' IBR approved for Sec.  170.503.
    (2) ISO/IEC 17011:2004 Conformity Assessment--General Requirements 
for Accreditation Bodies Accrediting Conformity Assessment Bodies 
(Corrected Version), February 15, 2005, ``ISO/IEC 17011,'' IBR approved 
for Sec.  170.503.
    (3) ISO/IEC 17025:2005(E)--General requirements for the competence 
of testing and calibration laboratories (Second Edition), 2005-05-15, 
``ISO/IEC 17025,'' IBR approved for Sec. Sec.  170.520(b) and 
170.524(a).
    (4) ISO/IEC 17065:2012(E)--Conformity assessment--Requirements for 
bodies certifying products, processes and services (First Edition), 
2012, ``ISO/IEC 17065,'' IBR approved for Sec.  170.503.

Sylvia M. Burwell,
Secretary, Department of Health and Human Services.
[FR Doc. 2016-24908 Filed 10-14-16; 8:45 am]
 BILLING CODE 4150-45-P