ONC Health IT Certification Program: Enhanced Oversight and Accountability, 11055-11085 [2016-04531]
Download as PDF
Vol. 81
Wednesday,
No. 41
March 2, 2016
Part IV
Department of Health and Human Services
mstockstill on DSK4VPTVN1PROD with PROPOSALS3
45 CFR Part 170
Medicare Program; FY 2015 Hospice Wage Index and Payment Rate
Update; Hospice Quality Reporting Requirements and Process and Appeals
for Part D Payment for Drugs for Beneficiaries Enrolled in Hospice;
Proposed Rule
VerDate Sep<11>2014
19:43 Mar 01, 2016
Jkt 238001
PO 00000
Frm 00001
Fmt 4717
Sfmt 4717
E:\FR\FM\02MRP3.SGM
02MRP3
11056
Federal Register / Vol. 81, No. 41 / Wednesday, March 2, 2016 / Proposed Rules
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
Office of the National
Coordinator for Health Information
Technology, Department of Health and
Human Services.
ACTION: Notice of proposed rulemaking.
AGENCY:
This notice of proposed
rulemaking (‘‘proposed rule’’)
introduces modifications and new
requirements under the ONC Health IT
Certification Program (‘‘Program’’),
including provisions related to the
Office of the National Coordinator for
Health Information Technology (ONC)’s
role in the Program. The proposed rule
proposes to establish processes for ONC
to directly review health IT certified
under the Program and take action when
necessary, including requiring the
correction of non-conformities found in
health IT certified under the Program
and suspending and terminating
certifications issued to Complete EHRs
and Health IT Modules. The proposed
rule includes processes for ONC to
authorize and oversee accredited testing
laboratories under the Program. It also
includes a provision for the increased
transparency and availability of
surveillance results.
DATES: To be assured consideration,
written or electronic comments must be
received at one of the addresses
provided below, no later than 5 p.m. on
May 2, 2016.
ADDRESSES: You may submit comments,
identified by RIN 0955–AA00, by any of
the following methods (please do not
submit duplicate comments). Because of
staff and resource limitations, we cannot
accept comments by facsimile (FAX)
transmission.
• Federal eRulemaking Portal: Follow
the instructions for submitting
comments. Attachments should be in
Microsoft Word, Microsoft Excel, or
Adobe PDF; however, we prefer
Microsoft Word. https://
www.regulations.gov.
• Regular, Express, or Overnight Mail:
Department of Health and Human
Services, Office of the National
Coordinator for Health Information
Technology, Attention: ONC Health IT
Certification Program Proposed Rule,
Mary E. Switzer Building, Mail Stop:
mstockstill on DSK4VPTVN1PROD with PROPOSALS3
SUMMARY:
VerDate Sep<11>2014
19:43 Mar 01, 2016
Jkt 238001
7033A, 330 C Street SW., Washington,
DC 20201. Please submit one original
and two copies.
• Hand Delivery or Courier: Office of
the National Coordinator for Health
Information Technology, Attention:
ONC Health IT Certification Program
Proposed Rule, Mary E. Switzer
Building, Mail Stop: 7033A, 330 C
Street SW., Washington, DC 20201.
Please submit one original and two
copies. (Because access to the interior of
the Mary E. Switzer Building is not
readily available to persons without
federal government identification,
commenters are encouraged to leave
their comments in the mail drop slots
located in the main lobby of the
building.)
Enhancing the Public Comment
Experience: To facilitate public
comment on this proposed rule, a copy
will be made available in Microsoft
Word format on ONC’s Web site (https://
www.healthit.gov). We believe this
version will make it easier for
commenters to access and copy portions
of the proposed rule for use in their
individual comments. Additionally, a
separate document will also be made
available on ONC’s Web site (https://
www.healthit.gov) for the public to use
in providing comments on the proposed
rule. This document is meant to provide
the public with a simple and organized
way to submit comments on proposals
and respond to specific questions posed
in the preamble of the proposed rule.
While use of this document is entirely
voluntary, we encourage commenters to
consider using the document in lieu of
unstructured comments or to use it as
an addendum to narrative cover pages.
We believe that use of the document
may facilitate our review and
understanding of the comments
received.
Inspection of Public Comments: All
comments received before the close of
the comment period will be available for
public inspection, including any
personally identifiable or confidential
business information that is included in
a comment. Please do not include
anything in your comment submission
that you do not wish to share with the
general public. Such information
includes, but is not limited to: A
person’s social security number; date of
birth; driver’s license number; state
identification number or foreign country
equivalent; passport number; financial
account number; credit or debit card
number; any personal health
information; or any business
information that could be considered
proprietary. We will post all comments
that are received before the close of the
PO 00000
Frm 00002
Fmt 4701
Sfmt 4702
comment period at https://
www.regulations.gov.
Docket: For access to the docket to
read background documents or
comments received, go to https://
www.regulations.gov or the Department
of Health and Human Services, Office of
the National Coordinator for Health
Information Technology, Mary E.
Switzer Building, Mail Stop: 7033A, 330
C Street SW., Washington, DC 20201
(call ahead to the contact listed below
to arrange for inspection).
FOR FURTHER INFORMATION CONTACT:
Michael Lipinski, Office of Policy,
Office of the National Coordinator for
Health Information Technology, 202–
690–7151.
SUPPLEMENTARY INFORMATION:
Commonly Used Acronyms
CEHRT Certified Electronic Health Record
Technology
CFR Code of Federal Regulations
CHPL Certified Health IT Product List
EHR Electronic Health Record
HHS Department of Health and Human
Services
HIT Health Information Technology
ISO International Organization for
Standardization
NVLAP National Voluntary Laboratory
Accreditation Program
OMB Office of Management and Budget
ONC Office of the National Coordinator for
Health Information Technology
ONC–ACB ONC–Authorized Certification
Body
ONC–ATCB ONC-Authorized Testing and
Certification Body
ONC–ATL ONC–Authorized Testing
Laboratory
PoPC Principles of Proper Conduct
Table of Contents
I. Executive Summary
A. Purpose of Regulatory Action
B. Summary of Major Provisions
1. ONC Direct Review of Certified Health
IT
2. ONC-Authorized Testing Laboratories
3. Transparency and Availability of
Surveillance Results
C. Costs and Benefits
1. Costs
2. Benefits
II. Provisions of the Proposed Rule
A. ONC’s Role Under the ONC Health IT
Certification Program
1. Review of Certified Health IT
a. Authority and Scope
b. ONC–ACB’s Role
c. Review Processes
(1) Notice of Potential Non-Conformity or
Non-Conformity
(2) Corrective Action
(3) Suspension
(4) Termination
(5) Appeal
d. Consequences of Certification
Termination
(1) Program Ban and Heightened Scrutiny
(2) ONC–ACB Response to a NonConformity
E:\FR\FM\02MRP3.SGM
02MRP3
mstockstill on DSK4VPTVN1PROD with PROPOSALS3
Federal Register / Vol. 81, No. 41 / Wednesday, March 2, 2016 / Proposed Rules
2. Establishing ONC Authorization for
Testing Labs Under the Program;
Requirements for ONC–ATL Conduct;
ONC Oversight and Processes for ONC–
ATLs
a. Background on Testing and Relationship
of Testing Labs and the Program
b. Proposed Amendments To Include
ONC–ATLs in the Program
(1) Proposed Amendments to § 170.501
Applicability
(2) Proposed Amendments to § 170.502
Definitions
(3) Proposed Amendments to § 170.505
Correspondence
(4) Proposed Amendment to § 170.510
Type of Certification
(5) Proposed Creation of § 170.511
Authorization Scope for ONC–ATL
Status
(6) Proposed Amendments to § 170.520
Application
(7) Proposed Amendments to § 170.523
Principles of Proper Conduct for ONC–
ACBs
(8) Proposed Creation of § 170.524
Principles of Proper Conduct for ONC–
ATLs
(9) Proposed Amendments to § 170.525
Application Submission
(10) Proposed Amendments to § 170.530
Review of Application
(11) Proposed Amendments to § 170.535
ONC–ACB Application Reconsideration
(12) Proposed Amendments to § 170.540
ONC–ACB Status
(13) Proposed Amendments to § 170.557
Authorized Certification Methods
(14) Proposed Amendments to § 170.560
Good Standing as an ONC–ACB
(15) Proposed Amendments to § 170.565
Revocation of ONC–ACB Status
(16) Request for Comment on § 170.570 in
the Context of an ONC–ATL’s Status
Being Revoked
B. Public Availability of Identifiable
Surveillance Results
III. National Technology Transfer and
Advancement Act
IV. Incorporation by Reference
V. Response to Comments
VI. Collection of Information Requirements
A. ONC–AA and ONC–ACBs
B. ONC–ATLs
C. Health IT Developers
VII. Regulatory Impact Statement
A. Statement of Need
B. Alternatives Considered
C. Overall Impact
1. Executive Orders 12866 and 13563—
Regulatory Planning and Review
Analysis
a. Costs
(1) Costs for Health IT Developers to
Correct a Non-Conformity Identified by
ONC
(2) Costs for ONC and Health IT Developers
Related to ONC Review and Inquiry Into
Certified Health IT Non-Conformities
(3) Costs to Health IT Developers and ONC
Associated With the Proposed Appeal
Process Following a Suspension/
Termination of a Complete EHR’s or
Health IT Module’s Certification
(4) Costs to Health Care Providers To
Transition to Another Certified Health IT
VerDate Sep<11>2014
19:43 Mar 01, 2016
Jkt 238001
Product When the Certification of a
Complete EHR or Health IT Module That
They Currently Use Is Terminated
(5) Costs for ONC–ATLs and ONC
Associated With ONC–ATL
Accreditation, Application, Renewal,
and Reporting Requirements
(6) Costs for ONC–ATLs and ONC Related
To Revoking ONC–ATL Status
(7) Costs for ONC–ACBs to Publicly Post
Identifiable Surveillance Results
(8) Total Annual Cost Estimate
b. Benefits
2. Regulatory Flexibility Act
3. Executive Order 13132—Federalism
4. Unfunded Mandates Reform Act of 1995
I. Executive Summary
A. Purpose of Regulatory Action
The ONC Health IT Certification
Program (‘‘Program’’) was first
established as the Temporary
Certification Program in a final rule
published on June 24, 2010
(‘‘Temporary Certification Program final
rule’’ (75 FR 36158)). It was later
transitioned to the Permanent
Certification Program in a final rule
published on January 7, 2011
(‘‘Permanent Certification Program final
rule’’ (76 FR 1262)). Since that time, we
have updated the Program and made
modifications to the Program through
subsequent rules as discussed below.
In November 2011, a final rule
established a process for ONC to address
instances where the ONC-Approved
Accreditor (ONC–AA) may engage in
improper conduct or not perform its
responsibilities under Program (76 FR
72636). In September 2012, a final rule
(‘‘2014 Edition final rule’’ (77 FR
54163)) established an edition of
certification criteria and modified the
Program to, among other things, provide
clear implementation direction to ONCAuthorized Certification Bodies (ONC–
ACBs) for certifying Health IT Modules
to new certification criteria. On
September 11, 2014, a final rule
provided certification flexibility through
the adoption of new certification criteria
and further improvements to the
Program (‘‘2014 Edition Release 2 final
rule’’ (79 FR 54430)). Most recently, on
October 16, 2015, the Department of
Health and Human Services (HHS)
published a final rule that identified
how health IT certification can support
the establishment of an interoperable
nationwide health information
infrastructure through the certification
and use of adopted new and updated
vocabulary and content standards for
the structured recording and exchange
of health information (‘‘2015 Edition
final rule’’ (80 FR 62602)). The 2015
Edition final rule modified the Program
to make it open and accessible to more
types of health IT and health IT that
PO 00000
Frm 00003
Fmt 4701
Sfmt 4702
11057
supports various care and practice
settings. It also included provisions to
increase the transparency of information
related to health IT certified under the
Program (referred to as ‘‘certified health
IT’’ throughout this proposed rule)
made available by health IT developers
through enhanced surveillance and
disclosure requirements.
With each Program modification and
rule, we have been able to address
stakeholder concerns, certification
ambiguities, and improve oversight. As
health IT adoption continues to
increase, including for settings and use
cases beyond the Medicare and
Medicaid EHR Incentive Programs
(‘‘EHR Incentive Programs’’), we
propose to address in this proposed rule
new concerns identified through
Program administration and from
stakeholders. As certified capabilities
interact with other capabilities in
certified health IT and with other
products, we seek to ensure that
concerns within the scope of the
Program can be appropriately
addressed.
We delegated authority to ONC–ACBs
to issues certifications for heath IT on
our behalf through the Permanent
Certification Program final rule. The
scope of this authority, consistent with
customary certification programs and
International Organization for
Standardization/International
Electrotechnical Commission
17065:2012 (ISO 17065),1 is primarily
limited to conformance determinations
for health IT evaluated against adopted
certification criteria with minimal
determinations for health IT against
other regulatory requirements
(§ 170.523(k) and (l)). As such, ONC–
ACBs do not have the responsibility or
expertise to address matters outside the
scope of this authority. In particular,
ONC–ACBs are not positioned, due to
the bounds of their authority and
limited resources, to address situations
that involve non-conformities resulting
from the interaction of certified and
uncertified capabilities within the
certified health IT or the interaction of
a certified health IT’s capabilities with
other products. In some instances, these
non-conformities may pose a risk to
public health or safety, including, for
example, capabilities (certified or
uncertified) of health IT directly
contributing to or causing medical
errors. While ONC–ACBs play an
important role in the administration of
the Program and in identifying nonconformities within their scope of
authority (e.g., non-conformities with
1 The international standard to which ONC–ACBs
are accredited. 45 CFR 170.599(b)(3).
E:\FR\FM\02MRP3.SGM
02MRP3
mstockstill on DSK4VPTVN1PROD with PROPOSALS3
11058
Federal Register / Vol. 81, No. 41 / Wednesday, March 2, 2016 / Proposed Rules
certification criteria), the Program does
not currently have any other means for
reviewing and addressing other nonconformities. As explained below, ONC
proposes to expand its role in the
Program to include the ability to
directly review and address nonconformities in an effort to enhance
Program oversight and the reliability
and safety of certified health IT.
The Health Information Technology
for Economic and Clinical Health
(HITECH) Act amended the Public
Health Service Act (PHSA) and created
‘‘Title XXX—Health Information
Technology and Quality’’ (Title XXX) to
improve health care quality, safety, and
efficiency through the promotion of
health IT and electronic health
information exchange. Section 3001(b)
of the Public Health Service Act
requires that the National Coordinator
for Health Information Technology
(National Coordinator) perform
specified statutory duties (section
3001(c) of the PHSA), including keeping
or recognizing a program or programs
for the voluntary certification of health
information technology (section
3001(c)(5) of the PHSA), in a manner
consistent with the development of a
nationwide health information
technology infrastructure that allows for
the electronic use and exchange of
information and that: (1) Ensures that
each patient’s health information is
secure and protected, in accordance
with applicable law; (2) improves health
care quality, reduces medical errors,
reduces health disparities, and advances
the delivery of patient-centered medical
care; (3) reduces health care costs
resulting from inefficiency, medical
errors, inappropriate care, duplicative
care, and incomplete information; (4)
provides appropriate information to
help guide medical decisions at the time
and place of care; (5) ensures the
inclusion of meaningful public input in
such development of such
infrastructure; (6) improves the
coordination of care and information
among hospitals, laboratories, physician
offices, and other entities through an
effective infrastructure for the secure
and authorized exchange of health care
information; (7) improves public health
activities and facilitates the early
identification and rapid response to
public health threats and emergencies,
including bioterror events and
infectious disease outbreaks; (8)
facilitates health and clinical research
and health care quality; (9) promotes
early detection, prevention, and
management of chronic diseases; (10)
promotes a more effective marketplace,
greater competition, greater systems
VerDate Sep<11>2014
19:43 Mar 01, 2016
Jkt 238001
analysis, increased consumer choice,
and improved outcomes in health care
services; and (11) improves efforts to
reduce health disparities. Consistent
with this statutory instruction, we
propose to expand ONC’s role in the
Program to encompass the ability to
directly review health IT certified under
the Program and address nonconformities found in certified health
IT.
The proposed rule also proposes
processes for ONC to timely and directly
address testing issues. These processes
do not exist today under the current
Program structure, particularly as
compared to ONC’s oversight of ONC–
ACBs. In addition, the proposed rule
includes a provision for the increased
transparency and availability of
identifiable surveillance results. The
publication of identifiable surveillance
results would support further
accountability of health IT developers to
their customers and users of certified
health IT.
B. Summary of Major Provisions
1. ONC Direct Review of Certified
Health IT
We propose, consistent with section
3001 of the PHSA, to expand ONC’s role
in the Program to encompass the ability
to directly review health IT certified
under the Program (referred to as
‘‘certified health IT’’ throughout this
proposed rule). This review would be
independent of, and may be in addition
to, reviews conducted by ONC–ACBs.
ONC’s direct review may include
certified capabilities and non-certified
capabilities of the certified health IT in
order for ONC to meet its
responsibilities under section 3001 of
the PHSA. More specifically, this review
would extend beyond the continued
conformance of the certified health IT’s
capabilities with the specific
certification criteria, test procedures,
and certification requirements such as
mandatory disclosures of limitations on
use and types of costs related to
certified capabilities (see
§ 170.523(k)(1)). It would extend to the
interaction of certified and uncertified
capabilities within the certified health
IT and to the interaction of a certified
health IT’s capabilities with other
products. This approach would support
the National Coordinator fulfilling the
statutory duties specified in section
3001 of the PHSA as it relates to keeping
a certification program for the voluntary
certification of health IT that allows for
the electronic use and exchange of
information consistent with the goals of
section 3001(b).
PO 00000
Frm 00004
Fmt 4701
Sfmt 4702
Under our proposals outlined in this
proposed rule, ONC would have broad
discretion to review certified health IT.
However, we anticipate that such
review would be relatively infrequent
and would focus on situations that pose
a risk to public health or safety. An
effective response to these situations
would likely require the timely
marshaling and deployment of resources
and specialized expertise by ONC. It
may also require coordination among
federal government agencies.
Additionally, we believe there could be
other exigencies, distinct from public
health and safety concerns, which for
similar reasons would warrant ONC’s
direct review and action. These
exigencies are described in section
II.A.1 of this preamble.
We propose that ONC could initiate a
direct review whenever it becomes
aware of information, whether from the
general public, interested stakeholders,
ONC–ACBs, or by any other means, that
indicates that certified health IT may
not conform to the requirements of its
certification or is, for example, leading
to medical errors, breaches in the
security of a patient’s health
information, or other outcomes that are
in direct opposition to the National
Coordinator’s responsibilities under
section 3001 of the PHSA. The
proposals in this proposed rule would
enable ONC to require corrective action
for these non-conformities and, when
necessary, suspend or terminate a
certification issued to a Complete EHR
or Health IT Module. We also propose
to establish a process for health IT
developers to appeal determinations by
ONC to suspend or terminate
certifications issued to health IT under
the Program. Further, to protect the
integrity of the Program and users of
certified health IT, we propose strict
processes for the recertification of
health IT (or replacement versions) that
has had its certification terminated,
heightened scrutiny for such health IT,
and a Program ban for health IT of
health IT developers that do not correct
non-conformities. We emphasize that
enhancing ONC’s role in reviewing
certified health IT would support
greater accountability for health IT
developers under the Program and
provide greater confidence that health
IT conforms to Program requirements
when it is implemented, maintained,
and used. We further emphasize that
our first and foremost goal is to work
with health IT developers to remedy any
identified non-conformities of certified
health IT in a timely manner.
E:\FR\FM\02MRP3.SGM
02MRP3
Federal Register / Vol. 81, No. 41 / Wednesday, March 2, 2016 / Proposed Rules
2. ONC-Authorized Testing Laboratories
We propose that ONC would conduct
direct oversight of testing labs under the
Program in order to ensure that ONC
oversight can be similarly applied at all
stages of the Program. Unlike the
processes we established for ONC–
ACBs, we did not establish a similar and
equitable process for testing labs.
Instead, we required in the Principles of
Proper Conduct (PoPC) for ONC–ACBs
that ONC–ACBs only accept test results
from National Voluntary Laboratory
Accreditation Program (NVLAP)accredited testing labs. This
requirement for ONC–ACBs had the
effect of requiring testing labs to be
accredited by NVLAP to International
Organization for Standardization/
International Electrotechnical
Commission 17025:2005 (General
requirements for the competence of
testing and calibration laboratories) (ISO
17025). However, in so doing, there is
effectively no direct ONC oversight of
NVLAP-accredited testing labs like there
is for ONC–ACBs.
This proposed rule proposes means
for ONC to have direct oversight of
NVLAP-accredited testing labs by
having them apply to become ONCAuthorized Testing Labs (ONC–ATLs).
Specifically, this proposed rule
proposes means for authorizing,
retaining, suspending, and revoking
ONC-Authorized Testing Lab (ONC–
ATL) status under the Program. These
proposed processes are similar to
current ONC–ACB processes. The
proposed changes would enable ONC to
oversee and address testing and
certification performance issues
throughout the entire continuum of the
Program in a precise and direct manner.
mstockstill on DSK4VPTVN1PROD with PROPOSALS3
3. Transparency and Availability of
Surveillance Results
In furtherance of our efforts to
increase the transparency and
availability of information related to
certified health IT, we propose to
require ONC–ACBs to make identifiable
surveillance results publicly available
on their Web sites on a quarterly basis.
We believe the publication of
identifiable surveillance results would
enhance transparency and the
accountability of health IT developers to
their customers. The public availability
of identifiable surveillance results
would provide customers and users
with valuable information about the
continued performance of certified
health IT as well as surveillance efforts.
While we expect that the prospect of
publicly identifiable surveillance results
would motivate some health IT
developers to improve their
VerDate Sep<11>2014
19:43 Mar 01, 2016
Jkt 238001
maintenance efforts, we believe that
most published surveillance results
would reassure customers and users of
certified health IT. This is because,
based on ONC–ACB surveillance results
to date, most certified health IT and
health IT developers are maintaining
conformance with certification criteria
and Program requirements. The
publishing of such ‘‘positive’’
surveillance results would also provide
a more complete context of surveillance;
rather than only sharing ‘‘negatives,’’
such as non-conformities and corrective
action plans.
C. Costs and Benefits
Executive Orders 12866 and 13563
direct agencies to assess all costs and
benefits of available regulatory
alternatives and, if regulation is
necessary, to select regulatory
approaches that maximize net benefits
(including potential economic,
environmental, public health and safety
effects, distributive impacts, and
equity). A regulatory impact analysis
(RIA) must be prepared for major rules
with economically significant effects
($100 million or more in any one year).
OMB has determined that this proposed
rule is an economically significant rule
as the potential costs associated with
this proposed rule could be greater than
$100 million per year. Accordingly, we
have prepared an RIA that to the best of
our ability presents the costs and
benefits of the proposed rule.
1. Costs
We estimated the potential monetary
costs of this proposed rule for health IT
developers, ONC–ATLs, the Federal
government (i.e., ONC), and health care
providers as follows: (1) Costs for health
IT developers to correct nonconformities identified by ONC; (2)
costs for ONC and health IT developers
related to ONC review and inquiry into
certified health IT non-conformities; (3)
costs to health IT developers and ONC
associated with the proposed appeal
process following a suspension/
termination of a Complete EHR’s or
Health IT Module’s certification; (4)
costs to health care providers to
transition to another certified health IT
product when the certification of a
Complete EHR or Health IT Module that
they currently use is terminated; (5)
costs for ONC–ATLs and ONC
associated with ONC–ATL
accreditation, application, renewal, and
reporting requirements; (6) costs for
ONC–ATLs and ONC related to revoking
ONC–ATL status; and (7) costs for
ONC–ACBs to publicly post identifiable
surveillance results. We also provide an
overall annual monetary cost estimate
PO 00000
Frm 00005
Fmt 4701
Sfmt 4702
11059
for this proposed rule. We note that we
have rounded all estimates to the
nearest dollar and all estimates are
expressed in 2016 dollars.
We have been unable to estimate the
costs for health IT developers to correct
non-conformities identified through
ONC’s direct review of certified health
IT because the costs incurred by health
IT developers to bring their certified
health IT into conformance would be
determined on a case-by-case basis. We
do, however, identify factors that would
inform cost estimates and request
comment on existing relevant data and
methods we could use to estimate these
costs in section VII.C.1.a of this
preamble.
We estimated the costs for ONC and
health IT developers related to ONC
review and inquiry into certified health
IT non-conformities. We estimate the
cost for a health IT developer to
cooperate with an ONC review and
inquiry into certified health IT would,
on average, range from $9,819 to
$49,096. We estimate the cost for ONC
to review and conduct an inquiry into
certified health IT would, on average,
range from $2,455 to $73,644.
We estimated the costs to health IT
developers and ONC associated with the
proposed appeal process following a
suspension/termination of a Complete
EHR’s or Health IT Module’s
certification. We estimate the cost for a
health IT developer to appeal a
suspension or termination would, on
average, range from $9,819 to $29,458.
We estimate the cost for ONC to conduct
an appeal would, on average, range from
$24,548 to $98,192.
We estimated the costs to health care
providers to transition to another
certified health IT product when the
certification of a Complete EHR or
Health IT Module that they currently
use is terminated. Specifically, we
estimate the cost impact of certification
termination on health care providers
would range from $33,000 to
$649,836,000 with a median cost of
$792,000 and a mean cost of $6,270,000.
We note, however, that it is very
unlikely that the high end of our
estimated costs would ever be realized.
To date, there have been only a few
terminations of certified health IT under
the Program, which have only affected
a small number on providers. Further,
we have stated in this proposed rule our
intent to work with health IT developers
to correct non-conformities ONC finds
in their certified health IT under the
provisions in this proposed rule. We
provide a more detailed discussion of
past certification terminations and the
potential impacts of certification
E:\FR\FM\02MRP3.SGM
02MRP3
11060
Federal Register / Vol. 81, No. 41 / Wednesday, March 2, 2016 / Proposed Rules
mstockstill on DSK4VPTVN1PROD with PROPOSALS3
termination on providers in section
VII.C.1.a of this preamble.
We estimated the costs for ONC–ATLs
and ONC associated with ONC–ATL
accreditation, application, renewal, and
reporting requirements. We estimate the
annualized cost of ONC–ATL
accreditation, application, and the first
proposed three-year authorization
period to be approximately $55,623. We
estimate the annualized cost for an
ONC–ATL to renew its accreditation,
application, and authorization during
the first three-year ONC–ATL
authorization period to be
approximately $84,372. In addition, we
estimate the total annual cost for ONC–
ATLs to meet the reporting
requirements of proposed § 170.524(d)
to be approximately $819.
We estimate ONC’s annualized cost of
administering the entire application
process to be approximately $992. These
costs would be the same for a new
applicant or ONC–ATL renewal. We
would also post the names of applicants
granted ONC–ATL status on our Web
site. We estimate the potential cost for
posting and maintaining the information
on our Web site to be approximately
$446 annually. We estimate an annual
cost to the federal government of $743
to record and maintain updates and
changes reported by the ONC–ATLs.
We estimate the costs for ONC–ATLs
and ONC related to revoking ONC–ATL
status. We estimate the cost for an ONC–
ATL to comply with ONC requests per
§ 170.565 would, on average, range from
$2,455 to $19,638. We estimate the cost
for ONC would, on average, range from
$4,910 to $39,277.
We estimate the costs for ONC–ACBs
to publicly post identifiable surveillance
results on their Web sites on a quarterly
basis. We estimate these costs would
annually be $205 per ONC–ACB and
total $615 for all ONC–ACBs.
We estimate the overall annual cost
for this proposed rule, based on the cost
estimates outlined above, would range
from $230,616 to $650,288,915 with an
average annual cost of $6,595,268. For a
more detailed explanation of our
methodology and estimated costs,
including requests for comment on ways
to improve our methodology and
estimated costs, please see section
VII.C.1.a of this preamble.
2. Benefits
The proposed rule’s provisions for
ONC direct review of certified health IT
would promote health IT developers’
accountability for the performance,
reliability, and safety of certified health
IT; and facilitate the use of safer and
reliable health IT by health care
providers and patients. Specifically,
VerDate Sep<11>2014
19:43 Mar 01, 2016
Jkt 238001
ONC’s direct review of certified health
IT would permit ONC to assess nonconformities and prescribe
comprehensive corrective actions for
health IT developers to address nonconformities, including notifying
affected customers. As previously
stated, our first and foremost goal would
be to work with health IT developers to
remedy any non-conformities with
certified health IT in a timely manner
and across all customers. If ONC
ultimately suspends and/or terminates a
certification issued to a Complete EHR
or Health IT Module under the
proposals in this proposed rule, such
action would serve to protect the
integrity of the Program and users of
health IT. Overall, we believe that ONC
direct review supports and enables the
National Coordinator to fulfill his/her
responsibilities under the HITECH Act,
instills public confidence in the
Program, and protects public health and
safety.
The proposed rule’s provisions would
also provide other benefits. The
proposals for ONC to authorize and
oversee testing labs (ONC–ATLs) would
facilitate further public confidence in
testing and certification by permitting
ONC to timely and directly address
testing issues for health IT. The
proposed public availability of
identifiable surveillance results would
enhance transparency and the
accountability of health IT developers to
their customers. This proposal would
provide customers and users of certified
health IT with valuable information
about the continued performance of
certified health IT as well as
surveillance efforts. Further, the public
availability of identifiable surveillance
results would likely benefit health IT
developers by providing a more
complete context of surveillance and
illuminating good performance and the
continued compliance of certified
health IT with Program requirements.
Overall, we believe these proposed
approaches, if finalized, would improve
Program compliance and further public
confidence in certified health IT.
II. Provisions of the Proposed Rule
A. ONC’s Role Under the ONC Health IT
Certification Program
In initially developing the Program,
ONC consulted with the National
Institute of Standards and Technology
(NIST) and created the Program
structure based on industry best
practice. This structure includes the use
of two separate accreditation bodies: (1)
An accreditor that evaluates the
competency of a health IT testing
laboratory to operate a testing program
PO 00000
Frm 00006
Fmt 4701
Sfmt 4702
in accordance with international
standards; and (2) an accreditor that
evaluates the competency of a health IT
certification body to operate a
certification program in accordance
with international standards (see the
Permanent Certification Program final
rule). In this section of the preamble, we
propose means for enhancing ONC’s
role in the Program.
1. Review of Certified Health IT
We propose to modify ONC’s role in
the Program to provide additional
oversight of health IT certified under the
Program. We propose to create a process
for ONC to directly review certified
health IT. We propose that ONC would
directly assess non-conformities and,
where applicable, prescribe
comprehensive corrective actions for
health IT developers that could include:
Investigating and reporting on root
cause analyses of the non-conformities;
notifying affected customers; fully
correcting identified issues across a
health IT developer’s customer base;
and taking other appropriate remedial
actions. We propose that ONC would be
able to suspend and/or terminate a
certification issued to health IT under
the Program. We also propose to
establish a process for health IT
developers to appeal determinations by
ONC to suspend or terminate
certifications issued to health IT under
the Program. We believe these proposals
would enhance the overall integrity and
performance of the Program and provide
greater confidence that health IT
conforms to the requirements of
certification when it is implemented,
maintained, and used.
a. Authority and Scope
Section 3001 of the PHSA directs the
National Coordinator to establish a
certification program or programs and to
perform the duties of keeping or
recognizing such program(s) in a
manner consistent with the
development of a nationwide health
information technology infrastructure
that allows for the electronic use and
exchange of information and that,
among other requirements: Ensures that
each patient’s health information is
secure and protected, in accordance
with applicable law; improves health
care quality; reduces medical errors;
reduces health care costs resulting from
inefficiency, medical errors,
inappropriate care, duplicative care, and
incomplete information; and promotes a
more effective marketplace, greater
competition, greater systems analysis,
increased consumer choice, and
improved outcomes in health care
E:\FR\FM\02MRP3.SGM
02MRP3
Federal Register / Vol. 81, No. 41 / Wednesday, March 2, 2016 / Proposed Rules
mstockstill on DSK4VPTVN1PROD with PROPOSALS3
services (see section 3001(b) of the
PHSA).
Under the current structure of the
Program, ONC–ACBs are responsible for
issuing and administering certifications
in accordance with ISO 17065, the PoPC
for ONC–ACBs, and other requirements
of the Program. Specifically, ONC–ACBs
are directly positioned and accountable
for determining whether a Complete
EHR or Health IT Module initially
satisfies and subsequently continues to
conform to certification criteria,
including relevant interpretative
guidance and test procedures. ONC–
ACBs are also responsible for ensuring
compliance with other Program
requirements such as the mandatory
disclosure requirements of limitations
on use and types of costs related to
certified capabilities (see
§ 170.523(k)(1)). If an ONC–ACB can
substantiate a non-conformity under the
Program, either as a result of
surveillance or otherwise, ISO 17065
requires that the ONC–ACB consider
and decide upon the appropriate action,
which could include: (1) The
continuation of the certification under
specified conditions (e.g., increased
surveillance); (2) a reduction in the
scope of certification to remove nonconforming product variants; (3)
suspension of the certification pending
remedial action by the developer; or (4)
termination of the certification (see 80
FR 62707–62725 and § 170.556).
While ONC authorizes ONC–ACBs to
issue and administer certifications for
health IT, ONC does not directly review
certified health IT under the Program.
The only exception would be if ONC
revoked an ONC–ACB’s authorization
due to a ‘‘Type-1’’ program violation 2
that calls into question the legitimacy of
a certification issued by the ONC–ACB
(see § 170.570). Under these
circumstances, the National Coordinator
would review and determine whether
health IT was improperly certified and,
if so, require recertification of the health
IT within 120 days (76 FR 1299). We
explained in the Permanent
Certification Program final rule that
recertification would be necessary in
such a situation to maintain the
integrity of the Program and to ensure
the efficacy and safety of certified health
IT (76 FR 1299).
2 We defined Type-1 violations to include
violations of law or ONC Health IT Certification
Program policies that threaten or significantly
undermine the integrity of the ONC Health IT
Certification Program. These violations include, but
are not limited to: false, fraudulent, or abusive
activities that affect the ONC Health IT Certification
Program, a program administered by HHS or any
program administered by the Federal government
(45 CFR 170.565(a)).
VerDate Sep<11>2014
19:43 Mar 01, 2016
Jkt 238001
ONC–ACBs have the necessary
expertise and capacity to effectively
administer certification requirements
under a wide variety of circumstances
(80 FR 62708–09). Nevertheless, we
recognized in response to comments on
the 2015 Edition proposed rule (80 FR
16804) that we would need to provide
additional guidance and assistance to
ONC–ACBs to ensure that these
requirements are applied consistently
and in a manner that accomplishes our
intent.3 While we are committed to
supporting ONC–ACBs in their roles, we
further recognize that there are certain
instances when review of certified
health IT is necessary to ensure
continued compliance with Program
requirements, but such review is beyond
the scope of an ONC–ACB’s
responsibilities, expertise (i.e.,
accreditation), or resources.
A health IT developer may have had
products certified by two different
ONC–ACBs and a potential nonconformity with a certified capability
may extend across all of the health IT
developers’ certified health IT. In such
an instance, ONC would be more suited
to handle the review of the certified
health IT as ONC–ACBs only have
oversight of the health IT they certify
and ONC could ensure a more
coordinated review and consistent
determination. Similarly, a potential
non-conformity or non-conformity may
involve systemic, widespread, or
complex issues that could be difficult
for an ONC–ACB to investigate or
address in a timely and effective
manner, such as where the nature,
severity, or extent of the non-conformity
would be likely to quickly consume or
exceed an ONC–ACB’s resources or
capacity. Most acutely, nonconformities with certified health IT
may arise that pose a risk to public
health or safety, including, for example,
capabilities (certified or uncertified) of
health IT directly contributing to or
causing medical errors (see section
3001(b)(2) of the PHSA). In such
situations, ONC is directly responsible
for reducing medical errors through the
certification of health IT and ONC–
ACBs may not have the expertise to
address these matters. We believe there
could also be other exigencies, distinct
from public health and safety concerns,
which for similar reasons would
warrant ONC’s direct review and action.
3 Shortly after publishing the 2015 Edition final
rule, we issued updated guidance to ONC–ACBs on
how to address these new requirements in their
annual surveillance plans. See ONC, Program
Policy Guidance #15–01A, https://
www.healthit.gov/sites/default/files/policy/2015-1102_supp_cy_16_surveillance_guidance_to_onc-acb_
15-01a_final.pdf (November 5, 2015).
PO 00000
Frm 00007
Fmt 4701
Sfmt 4702
11061
For example, ONC might directly review
a potentially widespread nonconformity that could compromise the
security or protection of patients’ health
information in violation of applicable
law (see section 3001(b)(1) of the PHSA)
or that could lead to inaccurate or
incomplete documentation and
resulting inappropriate or duplicative
care under federal health care programs
(see section 3001(b)(3) of the PHSA).
Last, it is conceivable that ONC could
have information about a potential nonconformity that is confidential or that
for other reasons cannot be shared with
an ONC–ACB, and therefore could be
acted upon only by ONC.
In the instances described above, we
believe that the existing role of ONC–
ACBs could be complemented by
establishing a process for ONC to
directly review certified health IT.
While we propose that ONC would have
broad discretion to review certified
health IT under proposed § 170.580(a),
we anticipate that this ‘‘direct review’’
of certified health IT would be relatively
infrequent and would focus on the
situations that present unique
challenges or issues that ONC–ACBs
may be unable to effectively address
without ONC’s assistance or
intervention (as described in the
examples above and in proposed
§ 170.580(a)(1)). ONC can effectively
respond to these potential issues
through quickly marshaling and
deploying resources and specialized
expertise and ensuring a coordinated
review and response that may involve
other offices and agencies within HHS
as well as other federal agencies. We
seek comment on these and other factors
that ONC should consider in deciding
whether and under what circumstances
to directly review certified health IT.
We emphasize that our primary goal in
all cases would be to correct nonconformities and ensure that certified
health IT performs in accordance with
Program requirements. In this regard,
our first and foremost desire would be
to work with the health IT developer to
remedy any non-conformity in a timely
manner.
b. ONC–ACB’s Role
We propose that ONC’s review of
certified health IT, as specified in
proposed 170.580(a)(2)(i), would be
independent of, and may be in addition,
to any review conducted by an ONC–
ACB, even if ONC and the ONC–ACB
were to review the same certified health
IT, and even if the reviews occurred
concurrently. For the reasons and
situations we have described above in
section II.A.1.a, we believe that these
reviews would be complementary
E:\FR\FM\02MRP3.SGM
02MRP3
mstockstill on DSK4VPTVN1PROD with PROPOSALS3
11062
Federal Register / Vol. 81, No. 41 / Wednesday, March 2, 2016 / Proposed Rules
because ONC may review matters
outside of an ONC–ACB’s
responsibilities (i.e., those that
implicate section 3001(b) of the PHSA)
or matters that may be partially within
an ONC–ACB’s purview to review but
present special challenges or
considerations that may be difficult for
an ONC–ACB to address. Accordingly,
to ensure consistency and clear
accountability, we propose in
§ 170.580(a)(2)(ii) that ONC, if it deems
necessary, could assert exclusive review
of certified health IT as to any matters
under review by ONC and any other
matters that are so intrinsically linked
that divergent determinations between
ONC and an ONC–ACB would be
inconsistent with the effective
administration or oversight of the
Program. We propose in
§ 170.580(a)(2)(iii) that in such
instances, ONC’s determinations on
these matters would take precedent and
a health IT developer would be subject
to the proposed ONC direct review
provisions in this proposed rule,
including having the opportunity to
appeal an ONC determination, as
applicable.
We clarify that in matters where ONC
does not assert direct and/or exclusive
review or ceases its direct and/or
exclusive review, an ONC–ACB would
be permitted to issue its own
determination on the matter. Further,
any determination to suspend or
terminate a certification issued to health
IT by an ONC–ACB that may result
would not be subject to ONC review
under the provisions in this proposed
rule. In those instances, there would
also be no opportunity to appeal the
ONC–ACB’s determination(s) under the
provisions in this proposed rule. ONC–
ACBs are accredited, authorized, and
entrusted to issue and administer
certifications under the Program
consistent with certification criteria and
other specified Program requirements.
Therefore, they have the necessary
expertise and capacity to effectively
administer these specific requirements.
We propose that ONC could initiate
review of certified health IT on its own
initiative based on information from an
ONC–ACB, which could include a
specific request from the ONC–ACB to
conduct a review. In exercising its
review of certified health IT, we propose
in § 170.580(a)(2)(iv) that ONC would be
entitled to any information it deems
relevant to its review that is available to
the ONC–ACB responsible for
administering the health IT’s
certification. We propose that ONC
could contract with an ONC–ACB to
conduct facets of the review within an
ONC–ACB’s scope of expertise, such as
VerDate Sep<11>2014
19:43 Mar 01, 2016
Jkt 238001
testing or surveillance of certified
capabilities. We propose that ONC
could also share information with an
ONC–ACB that may lead the ONC–ACB,
at its discretion and consistent with its
accreditation, to conduct in-the-field
surveillance of the health IT at
particular locations. We further propose
in § 170.580(a)(2)(v) that ONC could, at
any time, end all or any part of its
review of certified health IT under the
processes in this proposed rule and refer
the applicable part of the review to the
relevant ONC–ACB(s) if doing so would
serve the efficiency or effective
administration or oversight of the
Program. The ONC–ACB would be
under no obligation to proceed further,
but would have the discretion to review
and evaluate the information provided
and proceed in a manner it deems
appropriate. As noted above, this may
include processes and determinations
(e.g., suspension or termination) not
governed by the review and appeal
processes in this proposed rule.
We encourage comment on our
proposed approach and the role of an
ONC–ACB.
c. Review Processes
ONC could become aware of
information from the general public,
interested stakeholders, ONC–ACBs, or
by any other means that indicates that
certified health IT may not conform to
the requirements of its certification or
is, for example, leading to medical
errors, breaches in the security of a
patient’s health information, or other
outcomes that do not align with the
National Coordinator’s responsibilities
under section 3001 of the PHSA. If ONC
deems the information to be reliable and
actionable, it would conduct further
inquiry into the certified health IT.
Alternatively, ONC could initiate an
independent inquiry into the certified
health IT that could be conducted by
ONC or a third party(ies) on behalf of
ONC (e.g., contractors or inspection
bodies under the certification scheme).
If information reveals that there is a
potential non-conformity (through
substantiation or omission of
information to the contrary) or confirms
a non-conformity in the certified health
IT, ONC would proceed to notify the
health IT developer of its findings, as
applicable, and work with the health IT
developer to address the matter.
We propose for all processes proposed
under this section (section II.A.1.c) of
the preamble, as described below, that
correspondence and communication
with ONC and/or the National
Coordinator shall be conducted by
email, unless otherwise necessary or
PO 00000
Frm 00008
Fmt 4701
Sfmt 4702
specified. We propose to modify
§ 170.505 accordingly.
(1) Notice of Potential Non-Conformity
or Non-Conformity
If information suggests to ONC that
certified health IT is not performing
consistent with Program requirements
and a non-conformity exists with the
certified health IT, ONC would send a
notice of potential non-conformity or
non-conformity to the health IT
developer (see proposed
§ 170.580(b)(1)). The notice would
specify ONC’s reasons for the
notification, explain ONC’s findings,
and request that the health IT developer
respond to the potential/alleged nonconformity (and potentially a corrective
action request) or be subject to further
action (e.g., corrective action,
suspension, and/or the termination of
the certification in question, as
appropriate).
To ensure a complete and
comprehensive review of the certified
health IT product, we propose in
§ 170.580(b)(2) that ONC have the
ability to access and share within HHS,
with other federal agencies, and with
appropriate entities, a health IT
developer’s relevant records related to
the development, testing, certification,
implementation, maintenance, and use
of its product, as well as any complaint
records related to the product. We
recognize that much of this information
already must be disclosed as required by
the Program and described in the 2015
Edition final rule. We propose, however,
that ONC be granted access to, and be
able to share within HHS, with other
federal agencies, and with appropriate
entities (e.g., a contractor or ONC–ACB)
any additional records not already
disclosed that may be relevant and
helpful in ONC’s fact-finding and
review. This approach would support
the review of capabilities that interact
with certified capabilities and assist
ONC in determining whether certified
health IT conforms to applicable
Program requirements. We emphasize
that health IT developers would be
required to cooperate with ONC’s efforts
to access relevant records and should
not prevent or seek to discourage ONC
from obtaining such records. If we
determined that the health IT developer
was not cooperative with the factfinding process, we propose that we
would have the ability to suspend or
terminate the certification of any
encompassed Complete EHR or Health
IT Module of the certified health IT as
outlined later in sections II.A.1.c.(3) and
(4) of this preamble.
We understand that health IT
developers may have concerns regarding
E:\FR\FM\02MRP3.SGM
02MRP3
mstockstill on DSK4VPTVN1PROD with PROPOSALS3
Federal Register / Vol. 81, No. 41 / Wednesday, March 2, 2016 / Proposed Rules
disclosure of proprietary, trade secret,
competitively sensitive, or other
confidential information. To address
these concerns, ONC would implement
appropriate safeguards to ensure, to the
extent permissible with federal law, that
any proprietary business information or
trade secrets that ONC might encounter
by accessing the health IT developer’s
records would be kept confidential by
ONC.4 For instance, ONC would ensure
that, if it obtains proprietary or trade
secret information, that information
would not be included in the Certified
Health IT Product List (CHPL). We note,
however, that the safeguards we would
adopt would be prophylactic and would
not create a substantive basis for a
health IT developer to refuse to comply
with the proposed requirements. Thus,
a health IT developer would not be able
to avoid providing ONC access to
relevant records by asserting that such
access would require it to disclose trade
secrets or other proprietary or
confidential information.
The notice of potential nonconformity or non-conformity would
specify the timeframe for which the
health IT developer must respond to
ONC. Unless otherwise specified in the
notice and as outlined in proposed
§ 170.580(b)(1)(i) and (ii), the health IT
developer would be required to respond
within 30 days of receipt of the notice
and, if necessary, submit a proposed
corrective action plan as outlined below
in section II.A.1.c.(2) of this preamble.
We propose that ONC may require a
health IT developer to respond and/or
submit a proposed corrective action
plan in more or less time than 30 days
based on factors such as, but not limited
to: (1) The type of health IT and health
IT certification in question; (2) the type
of non-conformity to be corrected; (3)
the time required to correct the potential
non-conformity or non-conformity; and
(4) issues of public safety and other
exigencies related to the National
Coordinator carrying out his or her
duties in accordance with sections
3001(b) and (c) of the PHSA (see
proposed § 170.580(b)(1)(i) and (ii)). We
propose that ONC would have
discretion in deciding the appropriate
timeframe for a response and proposed
corrective action plan from the health IT
developer. We believe that affording
ONC this flexibility would advance the
overarching policy goal of ensuring that
ONC addresses and works with health
IT developers to correct potential nonconforming health IT in an efficient and
effective manner.
4 The Freedom of Information Act and Uniform
Trade Secrets Act generally govern the disclosure
of these types of information.
VerDate Sep<11>2014
19:43 Mar 01, 2016
Jkt 238001
We propose in § 170.580(b)(3) that if
the health IT developer contends that
the certified health IT in question
conforms to Program requirements, the
health IT developer must include in its
response all appropriate documentation
and explain in writing why the health
IT is conformant.
We request comment on our proposed
processes as described above, including
whether the timeframe for responding to
a notice of potential non-conformity or
non-conformity is reasonable and
whether there are additional factors that
we should consider.
(2) Corrective Action
If ONC finds that certified health IT
does not conform to Program
requirements, ONC would take
appropriate action with the health IT
developer to remedy the non-conformity
as outlined below and in proposed
§ 170.580(c). To emphasize, remedying a
non-conformity may require addressing
both certified and uncertified
capabilities within the certified health
IT.
We propose in § 170.580(c)(1) that
ONC would require a health IT
developer to submit a proposed
corrective action plan to ONC. The
corrective action plan would provide a
means to correct the identified nonconformities across all the health IT
developer’s customer base and would
require the health IT developer to make
such corrections before the certified
health IT could continue to be identified
as ‘‘certified’’ under the ONC Health IT
Certification Program, or sold or
licensed with that designation to new
customers.
We propose, as described above in
section II.A.1.c.(1) of this preamble, that
a health IT developer must submit a
proposed corrective action plan to ONC
within 30 days of the date that the
health IT developer was notified by
ONC of the non-conformity unless ONC
specifies a different timeframe. This
approach aligns with and does not
change the corrective action process for
ONC–ACBs described in § 170.556(d).
The primary difference between this
approach and the approach for ONC–
ACBs in § 170.556(d) is that in
§ 170.556(d) the health IT developer
must submit a corrective action plan to
an ONC–ACB within 30 days of being
notified of the potential non-conformity.
In this proposed rule, we propose that
this 30-day period be the default for
receiving a response/corrective action
plan, but that ONC may alter the
response period based on nonconformities that may pose a risk to
public health or safety, or other
exigencies related to the National
PO 00000
Frm 00009
Fmt 4701
Sfmt 4702
11063
Coordinator carrying out his or her
duties in accordance with sections
3001(b) and (c) of the PHSA.
We propose in § 170.580(c)(2) that
ONC would provide direction to the
health IT developer as to the required
elements of the corrective action plan
and would work with the health IT
developer to develop an acceptable
corrective action plan. The corrective
action plan would be required to
include, at a minimum, for each nonconformity:
• A description of the identified nonconformity;
• An assessment of the nature,
severity, and extent of the nonconformity, 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 nonconformity 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 nonconformity(ies), including identifying
all potentially affected customers, how
the health IT developer will promptly
ensure that all potentially affected
customers are notified of the nonconformity and plan for resolution, how
and when the health IT developer will
resolve issues for individual affected
customers, and how the health IT
developer will ensure that all issues are
in fact resolved; and
• The timeframe under which
corrective action will be completed.
We propose in § 170.580(c)(3) that
when ONC receives a proposed
corrective action plan (or a revised
proposed corrective action plan) it shall
either approve the proposed corrective
action plan or, if the plan does not
adequately address all required
elements, instruct the health IT
developer to submit a revised proposed
corrective action plan. In addition to the
required elements above and as
specified in § 170.580(c)(4), we propose
that a health IT developer would be
required to submit an attestation to
ONC. The attestation would follow the
form and format specified by the
corrective action plan and would be a
binding official statement by the health
IT developer that it has fulfilled all of
its obligations under the corrective
action plan, including curing the
identified non-conformities and related
deficiencies and taking all reasonable
steps to prevent their recurrence. Based
on this attestation and all other relevant
information, ONC would determine
whether the non-conformity(ies) has
E:\FR\FM\02MRP3.SGM
02MRP3
11064
Federal Register / Vol. 81, No. 41 / Wednesday, March 2, 2016 / Proposed Rules
mstockstill on DSK4VPTVN1PROD with PROPOSALS3
been cured and, if so, would lift the
corrective action plan. However, if it
were later discovered that the health IT
developer had not acted in the manner
attested, we propose that ONC could
reinstitute the corrective action plan or
proceed to suspend or terminate the
certification of any encompassed
Complete EHR or Health IT Module of
the certified health IT (see proposed
§ 170.580(c)(5), (d)(1)(v) and (e)(1)(iv)).
We request comment on our proposed
corrective action plan processes as
described above.
We propose that ONC would report
the corrective action plan and related
data to the publicly accessible CHPL.
The purpose of this reporting
requirement, as it is for ONC–ACBs
under current regulations, would be to
ensure that health IT users,
implementers, and purchasers are
alerted to potential conformance issues
in a timely and effective manner. This
approach is consistent with the public
health and safety, program integrity, and
transparency objectives described
previously in this proposed rule and in
the 2015 Edition final rule (80 FR
62725–26).
(3) Suspension
We propose that ONC may suspend
the certification of a Complete EHR or
Health IT Module at any time because
ONC believes that the certified health IT
poses a potential risk to public health or
safety, other exigent circumstances exist
concerning the product, or due to
certain actions or inactions by the
product’s health IT developer as
detailed below. We propose in
§ 170.580(d)(1) that ONC would be
permitted to initiate certification
suspension procedures for a Complete
EHR or Health IT Module for any one
of the following reasons:
• Based on information it has
obtained, ONC believes that the certified
health IT poses a potential risk to public
health or safety or other exigent
circumstances exist. More specifically,
ONC would suspend a certification
issued to any encompassed Complete
EHR or Health IT Module of the
certified health IT if the certified health
IT was, but not limited to: Contributing
to a patient’s health information being
unsecured and unprotected in violation
of applicable law; increasing medical
errors; decreasing the detection,
prevention, and management of chronic
diseases; worsening the identification
and response to public health threats
and emergencies; leading to
inappropriate care; worsening health
care outcomes; or undermining a more
effective marketplace, greater
competition, greater systems analysis,
VerDate Sep<11>2014
19:43 Mar 01, 2016
Jkt 238001
and increased consumer choice. Such
results would conflict with section
3001(b) of the PHSA, which instructs
the National Coordinator to perform the
duties in keeping or recognizing a
certification program that, among other
requirements, ensures patient health
information is secure and protected in
accordance with applicable law, reduces
medical errors, increases efficiency, and
leads to improved care and health care
outcomes. As discussed under the
‘‘termination’’ section below, we
propose that ONC could terminate a
certification on the same basis if it
concludes that a certified health IT’s
non-conformity(ies) cannot be cured;
• The health IT developer fails to
timely respond to any communication
from ONC, including, but not limited to:
Fact-finding; or a notice of potential
non-conformity or notice of nonconformity;
• The information provided by the
health IT developer in response to any
ONC communication, including, but not
limited to: Fact-finding, a notice of
potential non-conformity, or a notice of
non-conformity is insufficient or
incomplete;
• The health IT developer fails to
timely submit a proposed corrective
action plan that adequately addresses
the elements required by ONC as
described earlier in this preamble under
the ‘‘corrective action’’ section and in
proposed § 170.580(c); or
• The health IT developer does not
fulfill its obligations under the
corrective action plan developed in
accordance with proposed § 170.580(c).
We note that section § 170.556(d)(5)
states that, consistent with its
accreditation to ISO 17065 and
procedures for suspending a
certification, an ONC–ACB shall initiate
suspension procedures for a Complete
EHR or Health IT Module:
• 30 days after notifying the
developer of a non-conformity, if the
developer has not submitted a proposed
corrective action plan;
• 90 days after notifying the
developer of a non-conformity, if the
ONC–ACB cannot approve a corrective
action plan because the developer has
not submitted a revised proposed
corrective action plan; and
• Immediately, if the developer has
not completed the corrective actions
specified by an approved corrective
action plan within the time specified
therein.
As noted above, we propose that ONC
may suspend a certification for similar
reasons, but also propose that ONC
would suspend a certification at any
time based on a potential risk to public
health or safety, or other exigent
PO 00000
Frm 00010
Fmt 4701
Sfmt 4702
circumstances. We believe the proposed
addition of an expedited process and
direct ONC review for those reasons
makes the Program better enabled for
ONC to act swiftly to address potentially
non-conforming certified health IT. To
note, the processes for ONC–ACBs as
detailed above and in the 2015 Edition
final rule are not altered by the
proposals in this proposed rule.
ONC’s process for obtaining
information to support a suspension
could involve, but would not be limited
to: Fact-finding; requesting information
from an ONC–ACB; contacting users of
the health IT; and/or reviewing
complaints. We propose in
§ 170.580(d)(2) that ONC would issue a
notice of suspension when appropriate.
We propose that a suspension would
become effective upon the health IT
developer’s receipt of the notice of
suspension. We propose that the notice
of suspension would include, but not be
limited to: ONC’s explanation for the
suspension; the information ONC relied
upon to reach its determination; the
consequences of suspension for the
health IT developer and the Complete
EHR or Health IT Module under the
Program; and instructions for appealing
the suspension. We propose that the
notice of suspension would be sent via
certified mail and the official date of
receipt would be the date of the delivery
confirmation.
We propose in 170.580(d)(3) that the
health IT developer would be required
to notify its affected and potentially
affected customers of the certification
suspension in a timely manner.
Additionally, we propose that ONC
would publicize the suspension on the
CHPL to alert interested parties, such as
purchasers of certified health IT or
programs that require the use of
certified health IT. We propose in
§ 170.580(d)(4) that ONC would issue a
cease and desist notice to health IT
developers to immediately stop the
marketing and sale of the Complete EHR
or Health IT Module as ‘‘certified’’
under the Program when it suspends the
Complete EHR’s or Health IT Module’s
certification. Additionally, we propose
in § 170.580(d)(5) that in cases of a
certification suspension, inherited
certified status for the Complete EHR or
Health IT Module would not be
permitted. We propose in
§ 170.580(d)(6) that we would rescind a
suspension of certification if the health
IT developer completes all elements of
an approved corrective action plan and/
or ONC confirms that all nonconformities have been corrected.
We request comments on these
processes, including how timely a
health IT developer should notify
E:\FR\FM\02MRP3.SGM
02MRP3
Federal Register / Vol. 81, No. 41 / Wednesday, March 2, 2016 / Proposed Rules
mstockstill on DSK4VPTVN1PROD with PROPOSALS3
affected and potentially affected
customers of a suspension and what
other means we should consider using
for publicizing certification
suspensions. We also request comment
on whether a health IT developer
should only be permitted to certify new
Complete EHRs and Health IT Modules
while the certification in question is
suspended if such new certification of
other Complete EHRs or Health IT
Modules would correct the nonconformity for all affected customers.
Such a prohibition on the certification
of new Complete EHRs or Health IT
Modules may incentivize the health IT
developer to cure the non-conformity. In
correcting the non-conformity for all
affected customers, we note that this
would not include those affected
customers that decline the correction or
fail to cooperate. We request comment
as to whether correcting the nonconformity for a certain percentage of all
affected customers or certain milestones
demonstrating progress in correcting the
non-conformity (e.g., a percentage of
customers within a period of time)
should be sufficient to lift the
prohibition.
Under the current suspension
processes administered by ONC–ACBs,
following the suspension of a
certification of a Complete EHR or
Health IT Module, an ONC–ACB is
permitted to initiate certification
termination procedures for the
Complete EHR or Health IT Module
should the health IT developer not
complete the actions necessary to
reinstate the suspended certification
(consistent with its accreditation to ISO
17065 and procedures for terminating a
certification). We propose that ONC
would similarly be permitted to initiate
the certification termination procedures
as described in more detail in the
‘‘Termination’’ section below.
(4) Termination
We propose in § 170.580(e)(1) that
ONC may terminate certifications issued
to Complete EHRs or Health IT Modules
under the Program if: (1) The health
developer fails to timely respond to any
communication from ONC, including,
but not limited to: (a) Fact-finding; and
(b) a notice of potential non-conformity
or non-conformity; (2) the information
provided by the health IT developer in
response to fact-finding, a notice of
potential non-conformity, or a notice of
non-conformity is insufficient or
incomplete; (3) the health IT developer
fails to timely submit a proposed
corrective action plan that adequately
addresses the elements required by ONC
as described in section II.A.1.c.(2) of
this preamble; (4) the health IT
VerDate Sep<11>2014
19:43 Mar 01, 2016
Jkt 238001
developer does not fulfill its obligations
under the corrective action plan
developed in accordance with proposed
§ 170.580(c); or (5) ONC concludes that
the certified health IT’s nonconformity(ies) cannot be cured. We
request comment on these proposed
reasons for termination and on any
additional circumstances for which
commenters believe termination of a
certification would be warranted.
We propose that a termination would
be issued consistent with the processes
specified in proposed § 170.580(e)(2)
through (4) and outlined below, but note
that these proposed termination
processes do not change the certification
termination processes for ONC–ACBs
described in the 2015 Edition final rule.
A notice of termination would include,
but may not be limited to: ONC’s
explanation for the termination; the
information ONC relied upon to reach
its determination; the consequences of
termination for the health IT developer
and the Complete EHR or Health IT
Module under the Program; and
instructions for appealing the
termination. ONC would send a written
notice of termination to the agent of
record for the health IT developer of the
Complete EHR or Health IT Module.
The written termination notice would
be sent via certified mail and the official
date of receipt would be the date of the
delivery confirmation.
The termination of a certification
would be effective either upon: (1) The
expiration of the 10-day period for filing
an appeal as specified in section
II.A.1.c.(5) of this preamble if the health
IT developer does not file an appeal; or,
if a health IT developer files an appeal,
(2) upon a final determination to
terminate the certification as described
below in the ‘‘appeal’’ section of the
preamble and in proposed
§ 170.580(f)(7). As we proposed for
suspension of a certification, the health
IT developer must notify the affected
and potentially affected customers of
the identified non-conformity(ies) and
termination of certification in a timely
manner. Additionally, we propose that
ONC would publicize the termination
on the CHPL to alert interested parties,
such as purchasers of certified health IT
or entities administering programs that
require the use of health IT certified
under the Program. We request
comments on these processes, including
how timely a health IT developer
should notify affected and potentially
affected customers of a termination of a
Complete EHR’s or Health IT Module’s
certification and what other means we
should consider for publicizing
certification terminations.
PO 00000
Frm 00011
Fmt 4701
Sfmt 4702
11065
(5) Appeal
If ONC suspends or terminates a
certification for a Complete EHR or
Health IT Module, we propose that the
health IT developer of the Complete
EHR or Health IT Module may appeal
the determination to the National
Coordinator in accordance with the
proposed processes specified in
§ 170.580(f) and outlined below.
Section 170.580(f)(1) sets forth that a
health IT developer may appeal an ONC
determination to suspend or terminate a
certification issued to Complete EHR or
a Health IT Module if the health IT
developer asserts: (1) ONC incorrectly
applied Program methodology,
standards, or requirements for
suspension or termination; or (2) ONC’s
determination was not sufficiently
supported by the information used by
ONC to reach the determination.
Section 170.580(f)(2) describes that a
request for appeal of a suspension or
termination must be submitted in
writing by an authorized representative
of the health IT developer whose
certified Complete EHR or certified
Health IT Module was subject to the
determination being appealed. Section
170.580(f)(2) also requires that the
request for appeal must be filed in
accordance with the instructions
specified in the notice of termination or
notice of suspension. These instructions
for filing a request may include, but
would not be limited to: (1) Providing
a copy of the written determination by
ONC to suspend or terminate the
certification and any supporting
documentation; and (2) explaining the
reasons for the appeal. Section
170.580(f)(3) describes that this request
must be submitted to ONC within 10
calendar days of the health IT
developer’s receipt of the notice of
suspension or notice of termination.
Section 170.580(f)(4) specifies that a
request for appeal would stay the
termination of a certification issued to a
Complete EHR or Health IT Module
until a final determination is reached on
the appeal. However, a request for
appeal would not stay a suspension of
a Complete EHR or Health IT Module.
We propose that, similar to the effects
of a suspension, while an appeal would
stay a termination, a Complete EHR or
Health IT Module would be prohibited
from being marketed or sold as
‘‘certified’’ during the stay.
We propose that the National
Coordinator would assign the appeal to
a hearing officer who would adjudicate
the appeal on his or her behalf, as
described in § 170.580(f)(5). The hearing
officer may not preside over an appeal
in which he or she participated in the
E:\FR\FM\02MRP3.SGM
02MRP3
mstockstill on DSK4VPTVN1PROD with PROPOSALS3
11066
Federal Register / Vol. 81, No. 41 / Wednesday, March 2, 2016 / Proposed Rules
initial suspension or termination
determination by ONC or has a conflict
of interest in the pending matter.
There would be two parties involved
in an appeal: (1) The health IT
developer that requests the appeal; and
(2) ONC. Section 170.580(f)(6)(i)
describes that the hearing officer would
have the discretion to make a
determination based on: (1) The written
record as submitted to the hearing
officer by the health IT developer with
the appeal filed in accordance with
proposed § 170.580(f)(1) through (3) and
would include ONC’s written statement
and supporting documentation, if
provided; or (2) the information
described in option 1 and a hearing
conducted in-person, via telephone, or
otherwise. As specified in
§ 170.580(f)(6)(ii), the hearing officer
would have the discretion to conduct a
hearing if he or she: (1) Requires
clarification by either party regarding
the written record under paragraph
(f)(6)(i) of this section; (2) requires either
party to answer questions regarding the
written record under paragraph (f)(6)(i)
of this section; or (3) otherwise
determines a hearing is necessary. As
specified in § 170.580(f)(6)(iii), the
hearing officer would neither receive
testimony nor accept any new
information that was not presented with
the appeal request or was specifically
and clearly relied upon to reach the
determination to suspend or terminate
the certification by ONC. As specified in
§ 170.580(f)(6)(iv), the default process
for the hearing officer would be a
determination based on option 1
described above.
As proposed in § 170.580(f)(6)(v) and
mentioned above, once the health IT
developer requests an appeal, ONC
would have an opportunity to provide
the hearing officer with a written
statement and supporting
documentation on its behalf (e.g., a
brief) that explains its determination to
suspend or terminate the certification.
Failure of ONC to submit a written
statement would not result in any
adverse findings against ONC and may
not in any way be taken into account by
the hearing officer in reaching a
determination.
As proposed in § 170.580(f)(7)(i), the
hearing officer would issue a written
determination to the health IT developer
within 30 days of receipt of the appeal,
unless the health IT developer and ONC
agree to a finite extension approved by
the hearing officer. We request comment
on whether the allotted time for the
hearing officer to issue a written
determination should be lessened or
lengthened, such as 15, 45, or 60 days.
We also request comment on whether an
VerDate Sep<11>2014
19:43 Mar 01, 2016
Jkt 238001
extension should be permitted and
whether it should only be permitted
under the circumstances proposed or for
other reasons and circumstances.
As proposed in § 170.580(f)(7)(ii), the
National Coordinator’s determination,
as issued by the hearing officer, would
be the agency’s final determination and
not subject to further review.
We welcome comments on the
proposed appeal processes outlined in
this section.
d. Consequences of Certification
Termination
In general, this proposed rule does not
address the consequences of
certification termination beyond
requirements for recertification. Any
consequences of, and remedies for,
termination beyond recertification
requirements are outside the scope of
this proposed rule. For example, this
proposed rule does not address the
remedies for providers participating in
the EHR Incentive Programs that may be
using a Complete EHR or Health IT
Module that has its certification
terminated.5 While our goals with this
proposed rule are to enhance Program
oversight and health IT developer
accountability for the performance,
reliability, and safety of certified health
IT, we remind stakeholders that we have
proposed methods (e.g., corrective
action plans) designed to identify and
remedy non-conformities so that a
Complete EHR or Health IT Module can
maintain its certification.
(1) Program Ban and Heightened
Scrutiny
We propose in § 170.581(a) that a
Complete EHR or Health IT Module that
has had its certification terminated can
be tested and recertified once all nonconformities have been adequately
addressed. We propose that the
recertified Complete EHR or Health IT
Module (or replacement version) must
maintain a scope of certification that, at
a minimum, includes all the previous
certified capabilities. We propose that
the health IT developer must request
permission to participate in the Program
before submitting the Complete EHR or
Health IT Module (or replacement
version) for testing to an ONC–ATL and
recertification (certification) by an
ONC–ACB under the Program. As part
of its request, we propose that a health
IT developer must submit a written
explanation of what steps were taken to
address the non-conformities that led to
the termination. We also propose that
5 See CMS EHR Incentive Programs FAQ 12657:
https://questions.cms.gov/faq.php?isDept=0&
search=decertified&searchType=keyword&
submitSearch=1&id=5005.
PO 00000
Frm 00012
Fmt 4701
Sfmt 4702
ONC would need to review and approve
the request for permission to participate
in the Program before testing and
recertification (certification) of the
Complete EHR or Health IT Module (or
replacement version) can commence
under the Program.
If the Complete EHR or Health IT
Module (or replacement version) is
recertified (certified), we believe and
propose in § 170.581(b) that the certified
health IT product should be subjected to
some form of heightened scrutiny by
ONC or an ONC–ACB for a minimum of
one year. We believe completion of the
recertification process and heightened
scrutiny would support the integrity of
the Program and the continued
functionality and reliability of the
certified health IT. We request comment
on the forms of heightened scrutiny
(e.g., quarterly in-the-field surveillance)
and length of time for the heightened
scrutiny (more or less than one year,
such as six months or two years) of a
recertified Complete EHR or recertified
Health IT Module (or replacement
version) that previously had its
certification terminated.
We propose in § 170.581(c) that the
testing and certification of any health IT
of a health IT developer that has the
certification of one of its health IT
products terminated under the Program
or withdrawn from the Program when
the subject of a potential nonconformity
(notice of potential non-conformity) or
non-conformity would be prohibited.
The only exceptions would be if: (1) The
non-conformity is corrected and
implemented to all affected customers;
or (2) the certification and
implementation of other health IT by
the health IT developer would remedy
the non-conformity for all affected
customers. As noted in the discussion
under the proposed suspension
provisions, prohibiting the certification
of new products, unless it serves to
correct the non-conformity for all
affected customers, may incentivize a
health IT developer to cure the nonconformity. In correcting the nonconformity for all affected customers,
we note that this would not include
those customers that decline the
correction or fail to cooperate. We
welcome comments on this proposal,
including how the health IT developer
should demonstrate to ONC that all
necessary corrections were completed.
We further request comment as to
whether correcting the non-conformity
for a certain percentage of all affected
customers or certain milestones
demonstrating progress in correcting the
non-conformity (e.g., a percentage of
customers within a period of time)
should be sufficient to lift the
E:\FR\FM\02MRP3.SGM
02MRP3
Federal Register / Vol. 81, No. 41 / Wednesday, March 2, 2016 / Proposed Rules
mstockstill on DSK4VPTVN1PROD with PROPOSALS3
prohibition. Additionally, consistent
with this and the other proposed
requirements of § 170.581, we request
comment on whether heightened
scrutiny (surveillance or other
requirements) should apply for a period
of time (e.g., six months, one year, or
two years) to all currently certified
Complete EHRs or certified Health IT
Modules, future versions of either type,
and all new certified health IT of a
health IT developer that has a product’s
certification terminated under the
Program.
(2) ONC–ACB Response to a NonConformity
As previously noted in this proposed
rule, ONC–ACBs are accredited to ISO
17065. Section 7.11.1 of ISO 17065
instructs certification bodies to consider
and decide upon the appropriate action
to address a non-conformity found,
through surveillance or otherwise, in
the product the certification body
certified.6 Section 7.11.1 lists, among
other appropriate actions, the reduction
in scope of certification to remove nonconforming product variants or
withdrawal of the certification. We do
not, however, believe these are
appropriate actions under the Program.
We do not believe that a reduction in
scope is appropriate for health IT under
the Program. This action would absolve
a health IT developer from correcting a
non-conformity. Health IT is tested and
certified to meet adopted criteria and
requirements. It should continue to
meet those criteria and requirements
when implemented. If not, it should be
corrected (the version is corrected
through an update or a new corrected
version is rolled out to all affected
customers) or be subjected to
certification termination. Accordingly,
we propose to revise the PoPC for ONC–
ACBs (§ 170.523) to prohibit ONC–ACBs
from reducing the scope of a
certification when the health IT is under
surveillance or a corrective action plan.
This proposal addresses two situations:
(1) When health IT is suspected of a
non-conformity (i.e., under
surveillance); and (2) when health IT
has a non-conformity (i.e., under a
corrective action plan).
A health IT developer’s withdrawal of
its certified health IT from the Program
when the subject of a potential nonconformity (under surveillance) or nonconformity should not be without
prejudice. If a health IT developer is not
willing to correct a non-conformity,
then we believe the health IT developer
should be subject to the same proposed
consequences as we have proposed
6 45
CFR 170.599(b)(3).
VerDate Sep<11>2014
19:43 Mar 01, 2016
Jkt 238001
under ONC direct review of health IT
(i.e., a Program ban on the testing and
certification of its health IT). We further
propose that the same proposed
consequences for health IT and health
IT developers related to certification
termination under ONC direct review
(i.e., all of the § 170.581 proposals)
should apply to certification
terminations issued by ONC–ACBs. We
note that the concept of heightened
scrutiny, as described above, is
consistent with section 7.11.1 listing of
increased surveillance as an appropriate
response to a non-conformity.
These proposals are consistent with
our proposed approach and processes
for ONC direct review and would
support the overall integrity and
reliability of the Program. We welcome
comment on these proposals.
2. Establishing ONC Authorization for
Testing Labs Under the Program;
Requirements for ONC–ATL Conduct;
ONC Oversight and Processes for ONC–
ATLs
a. Background on Testing and
Relationship of Testing Labs and the
Program
The Temporary Certification Program,
established by final rule (75 FR 36158),
provided a process by which an
organization or organizations could
become an ONC-Authorized Testing and
Certification Body (ONC–ATCB) and be
authorized by the National Coordinator
to perform the testing and certification
of Complete EHRs and/or Health IT
Modules. Under the Temporary
Certification Program, an organization
was both a testing lab and certification
body. The Temporary Certification
Program was replaced by the Permanent
Certification Program, which first
finalized a new set of rules in 2011 (76
FR 1262). The name of the Permanent
Certification Program was changed to
the ONC HIT Certification Program in
the 2014 Edition final rule (77 FR
54163) and the ONC Health IT
Certification Program (Program) in the
2015 Edition final rule (80 FR 62602).
Under the Program, testing and
certification must be completed by
organizations (or components of
organizations) that are separately
accredited to different ISO standards
(i.e., ISO 17065 for certification and ISO
17025 for testing). In the Permanent
Certification Program final rule, we
explained that the NVLAP,
administered by NIST, would be the
accreditor for health IT testing labs
under the Program (76 FR 1278–1281).
Unlike the processes we established
for ONC–ACBs, which at a high-level
includes a two-step process of: (1)
PO 00000
Frm 00013
Fmt 4701
Sfmt 4702
11067
Accreditation by the ONC-Approved
Accreditor; and (2) a formal request for
and subsequent authorization by the
National Coordinator to operate within
the Program, we did not establish a
similar and equitable process for testing
labs. Instead, we required in the PoPC
for ONC–ACBs (45 CFR 170.523(h)) that
ONC–ACBs only accept test results from
NVLAP-accredited testing labs. This
requirement for ONC–ACBs had the
effect of requiring testing labs to be
accredited by NVLAP to ISO 17025.
However, in so doing, there is
effectively no direct ONC oversight of
NVLAP-accredited testing labs like there
is for ONC–ACBs.
In the five years we have
administered the Program, we have
continually made updates to the
Program’s rules to refine, mature, and
optimize program operations (see
revisions to the Program in the 2014
Edition final rule, 2014 Edition Release
2 final rule, and 2015 Edition final rule).
These changes have also included new
and expanded responsibilities for ONC–
ACBs and ONC. While we have
continued to update and improve our
oversight of ONC–ACBs, we have not
done the same for the testing labs upon
which ONC–ACBs rely. Our continued
evaluation of the Program has led us to
determine that the operational
efficiency and overall integrity of the
Program could be improved by
establishing parity in the oversight we
provide for both testing and
certification.
The testing of health IT by accredited
testing labs is the first line of evaluation
in determining whether health IT meets
the capabilities included in a
certification criterion and serves as the
basis for the certification of health IT by
ONC–ACBs. We believe that having a
similar and comparable authorization
and oversight paradigm for testing labs
and certification bodies would enable
ONC to oversee and address testing and
certification performance issues
throughout the entire continuum of the
Program in a precise and direct manner.
For example, ensuring that consistent
testing documentation (e.g., files,
reports, and test tool outputs) is
produced across all ONC–ATLs could
be directly addressed at the testing stage
compared to today’s rules that solely
apply to ONC–ACBs, who are simply
the recipients of such information.
Additionally, ONC direct oversight
would ensure that, like with ONC–
ACBs, testing labs are directly and
immediately accountable to ONC for
their performance across a variety of
Program items including, but not
limited to: Specifying and verifying
testing personnel qualifications;
E:\FR\FM\02MRP3.SGM
02MRP3
11068
Federal Register / Vol. 81, No. 41 / Wednesday, March 2, 2016 / Proposed Rules
requiring training sessions for testing
lab personnel; establishing record
documentation and retention
requirements; and instituting methods
for addressing inappropriate and
incorrect testing methods and noncompliance with Program requirements.
mstockstill on DSK4VPTVN1PROD with PROPOSALS3
b. Proposed Amendments To Include
ONC–ATLs in the Program
This proposed rule proposes means
for ONC to have direct oversight of
NVLAP-accredited testing labs by
having them apply to become ONC–
ATLs. Specifically, this proposed rule
proposes means for authorizing,
retaining, suspending, and revoking
ONC–ATL status under the Program.
These proposed processes are similar to
current ONC–ACB processes. In general,
to seek and acquire authorization, an
applicant must be NVLAP-accredited to
ISO 17025, agree to the PoPC for ONC–
ATLs, and comply with the proposed
application documentation and
procedural requirements. We propose
that an ONC–ATL would retain its
status for a three-year period that could
be continually renewed as long as the
ONC–ATL follows proposed good
standing and testing requirements,
including the PoPC for ONC–ATLs. To
maintain proper oversight and the
integrity of the Program, we propose
criteria and means for ONC to suspend
and revoke an ONC–ATL’s status under
the Program, which include
opportunities for an ONC–ATL to
become compliant and respond to a
proposed suspension and/or revocation.
We also request comment on whether
we should revise § 170.570 to account
for the possibility of an ONC–ATL
having its status revoked for a Type-1
violation that called into question the
legitimacy of certifications issued by an
ONC–ACB.
The following sections detail each
new and amended regulatory provisions
that we propose for subpart E of part
170, starting with 45 CFR 170.501, in
order to include ONC–ATLs as part of
the Program. For authorization and
other processes, we intend to follow and
leverage all of the processes established
for ONC–ACBs. Thus, most of our
proposals are minimal conforming
amendments to existing regulatory text
that add in references to a testing lab or
(once authorized) ONC–ATL.
(1) Proposed Amendments to § 170.501
Applicability
We propose to revise paragraph (a) of
§ 170.501 to include references to
‘‘applicants for ONC–ATL status;’’
‘‘ONC–ATL;’’ and ‘‘ONC–ATL status.’’
The proposed revisions would make
VerDate Sep<11>2014
19:43 Mar 01, 2016
Jkt 238001
clear that ONC–ATLs are part of the
rules under this subpart.
(2) Proposed Amendments to § 170.502
Definitions
We propose to revise the definition of
the term ‘‘Applicant’’ in § 170.502 to
include a corresponding reference to
ONC–ATL in order for such term to
have equal meaning in the case of a
testing lab that is applying for ONC–
ATL status.
We propose to revise the definition of
the term ‘‘gap certification’’ in § 170.502
to include a corresponding reference to
ONC–ATL in paragraph (1) of that
definition in order to give equal weight
to test results based those issued by an
ONC–ATL. We also propose to add
‘‘under the ONC Health IT Certification
Program’’ to paragraphs (1) and (2) of
the definition to improve the clarity of
the definition.
We propose to define the term ‘‘ONC–
Authorized Testing Lab’’ or ‘‘ONC–
ATL’’ to mean an organization or
consortium of organizations that has
applied to and been authorized by the
National Coordinator to perform the
testing of Complete EHRs and Health IT
Modules to certification criteria adopted
by the Secretary in subpart C of this
part.
(3) Proposed Amendments to § 170.505
Correspondence
In order to accurately reflect the
addition of an applicant for ONC–ATL
status and ONC–ATLs to the Program
framework, we propose to revise
§ 170.505 to include references to ONC–
ATL as appropriate.
(4) Proposed Amendment to § 170.510
Type of Certification
To make clear that § 170.510 is
specifically geared toward applicants for
ONC–ACB status and the authorization
they may seek, we propose to revise the
section heading to specifically reference
the authorization scope of ONC–ACB
status. We also propose to revise the
introductory text within this section to
more clearly convey that this section is
solely focused on applicants for ONC–
ACB status.
(5) Proposed Creation of § 170.511
Authorization Scope for ONC–ATL
Status
We propose to create a new section
(§ 170.511) to clearly define the scope of
the authorization an ‘‘applicant’’ testing
lab may be able to seek from the
National Coordinator. We propose that
such authorization be limited to the
certification criteria adopted by the
Secretary in subpart C of this part.
However, to support specialized testing
PO 00000
Frm 00014
Fmt 4701
Sfmt 4702
and testing efficiencies for health IT, we
propose that an applicant for ONC–ATL
status could seek for the scope of its
authorization all certification criteria, a
subset of all of the certification criteria
(e.g., to support only privacy and
security testing), one certification
criterion, or a portion of one
certification criterion. The latter two
options provide opportunities for
entities that may perform industry
testing of health IT for limited and/or
distinct capabilities (e.g., e-prescribing)
that align with certification criteria to
participate in the Program. This
approach could avoid duplicative
testing and reduce regulatory burden for
health IT developers that test and certify
health IT under the Program and with
entities outside of the Program.
(6) Proposed Amendments to § 170.520
Application
We propose to make the following
amendments in order to establish the
requirements that an applicant for
ONC–ATL status must follow for its
application for ONC–ATL status. First,
we propose to reorder the regulatory
text hierarchy to reference the ONC–
ACB application requirements under
§ 170.520(a) and then the ONC–ATL
application requirements under
§ 170.520(b). For the ONC–ATL
requirements, we propose that an ONC–
ATL applicant would need to seek
authorization based on the scope
proposed in § 170.511 and follow the
same set of amended requirements as
applicable to the different accreditation
and PoPC to which ONC–ATLs would
need to adhere. We propose that this
application information include the
same general identifying information as
for ONC–ACB applicants; the same
authorized representative designation;
documentation that the applicant has
been accredited by NVLAP to ISO
17025; and an agreement executed by
the authorized representative to PoPC
for ONC–ATLs.
(7) Proposed Amendment to § 170.523
Principles of Proper Conduct for ONC–
ACBs
We propose to revise § 170.523(h)
(PoPC for ONC–ACBs) to explicitly
include ONC–ATLs as an entity from
whom ONC–ACBs would receive test
results (see proposed § 170.523(h)(1)).
Additionally, to account for the
transition period from NVLAPaccredited testing laboratories to ONC–
ATLs, we propose to modify
§ 170.523(h) to include a six month time
window from the authorization of the
first ONC–ATL to permit the continued
acceptance by ONC–ACBs of any test
results from a NVLAP-accredited testing
E:\FR\FM\02MRP3.SGM
02MRP3
Federal Register / Vol. 81, No. 41 / Wednesday, March 2, 2016 / Proposed Rules
mstockstill on DSK4VPTVN1PROD with PROPOSALS3
laboratory (see proposed
§ 170.523(h)(2)). We believe this would
provide more than adequate transition
time for ONC–ACBs to continue to issue
certifications based on test results for
new and revised certification criteria
issued by a ‘‘NVLAP-accredited testing
laboratory’’ and would also serve as a
mobilizing date for a testing lab that has
not yet applied for ONC–ATL status.
We, however, request comment on our
proposed approach to the transition
period from NVLAP-accredited testing
laboratories to ONC–ATLs. Specifically,
we request comment on whether we
should alternatively establish that ONC–
ACBs may only be permitted to accept
any test results from a NVLAPaccredited testing laboratory for a period
of time from the effective date of a
subsequent final rule. This approach
would provide a more certain timetable
for ONC–ACBs compared to the
proposed approach, but may not
provide sufficient time for all NVLAPaccredited testing laboratories to
transition to ONC–ATL status. We also
request comment on whether the
transition period should be shorter (e.g.,
three months) or longer (e.g., nine
months) under either the proposed
approach or the alternative approach.
We propose in § 170.523(h)(2) to
permit the use of test results from a
NVLAP-accredited testing laboratory for
certifying previously certified health IT
to unchanged certification criteria and
gap certification. As proposed, NVLAPaccredited testing laboratories would be
replaced with ONC–ATLs. This
proposal would permit the test results
issued by NVLAP-accredited testing
laboratories under the Program (e.g., test
results for health IT tested to the 2014
Edition) to continue to be used for
certifying previously certified health IT
to unchanged certification criteria and
gap certification. As a related proposal,
we propose to remove references to
ONC–ATCBs in § 170.523(h). ONC–
ATCBs certified health IT to the 2011
Edition. The 2011 Edition has been
removed from the Code of Federal
Regulations and ONC–ACBs no longer
maintain active certifications for health
IT certified to the 2011 Edition.
(8) Proposed Creation of § 170.524
Principles of Proper Conduct for ONC–
ATLs
Similar to the set of rules and
conditions to which we require ONC–
ACBs to adhere, we propose to establish
a corresponding set of PoPC to which
ONC–ATLs must adhere. Adherence to
these conduct requirements would be
necessary for ONC–ATLs to maintain
their authorization and to remain in
good standing under the Program. Many
VerDate Sep<11>2014
19:43 Mar 01, 2016
Jkt 238001
of the proposed PoPC for ONC–ATLs
would remain consistent with those to
which ONC–ACBs are already required
to adhere. The proposed PoPC for ONC–
ATLs include that an ONC–ATL shall:
• Maintain its accreditation through
NVLAP based on the ISO 17025
standard;
• Attend all mandatory ONC training
and program update sessions;
• Maintain a training program that
includes documented procedures and
training requirements to ensure its
personnel are competent to test health
IT;
• Report to ONC within 15 days any
changes that materially affect its: Legal,
commercial, organizational, or
ownership status; organization and
management including key testing
personnel; policies or procedures;
location; personnel, facilities, working
environment or other resources; ONC
authorized representative (point of
contact); or other such matters that may
otherwise materially affect its ability to
test health IT;
• Allow ONC, or its authorized
agent(s), to periodically observe on site
(unannounced or scheduled), during
normal business hours, any testing
performed pursuant to the Program;
• Consistent with the revisions
recently adopted in the 2015 Edition
final rule, to retain all records related to
the testing of Complete EHRs and/or
Health IT Modules to an edition of
certification criteria for a minimum of
three years from the effective date that
removes the applicable edition from the
Code of Federal Regulations; and to
make the records available to HHS upon
request during the retention period;
• Only test health IT (Complete EHRs
and Health IT Modules) using test tools
and test procedures approved by the
National Coordinator; and
• Promptly refund any and all fees
received for: Requests for testing while
its operations are suspended by the
National Coordinator; testing that will
not be completed as a result of its
conduct; and previous testing that it
performed if its conduct necessitates the
retesting of Complete EHRs and/or
Health IT Modules.
(9) Proposed Amendments to § 170.525
Application Submission
To clearly recognize that testing labs
would be applying for ONC–ATL status,
we propose to include reference to an
applicant for ONC–ATL status in
paragraphs (a) and (b) of § 170.525 and
to have the same rules that currently
apply to applicants for ONC–ACB status
apply to applicants for ONC–ATL
status.
PO 00000
Frm 00015
Fmt 4701
Sfmt 4702
11069
(10) Proposed Amendments to § 170.530
Review of Application
We propose to revise paragraphs
(c)(2), (c)(4), (d)(2), and (d)(3) of
§ 170.530 to equally reference that an
ONC–ATL could be part of the
application review process. Further, in
so doing, we propose to follow all of the
same application review steps and
processes that we currently follow for
applicants for ONC–ACB status.
(11) Proposed Amendments to § 170.535
ONC–ACB Application Reconsideration
We propose to revise this section’s
heading to include reference to ONC–
ATLs. Additionally, we propose to
revise paragraphs (a) and (d)(1) of
§ 170.535 to equally reference that an
ONC–ATL could be part of the
application reconsideration process.
Further, in so doing, we propose to
follow all of the same application
reconsideration steps and processes that
we currently require and follow for
applicants for ONC–ACB status.
(12) Proposed Amendments to § 170.540
ONC–ACB Status
We propose to revise this section’s
heading to include reference to ONC–
ATLs. Additionally, we propose to
revise paragraphs (a) through (d) of
§ 170.540 to equally reference an ONC–
ATL as part of the rules currently
governing the achievement of ONC–
ACB status. These rules would include:
The acknowledgement of ONC–ATL
status; that the ONC–ATL must
prominently and unambiguously
identify the scope of its authorization;
that ONC–ATL authorization must be
renewed every three (3) years; and the
expiration of ONC–ATL status (3 years
from when it was granted unless
renewed).
(13) Proposed Amendments to § 170.557
Authorized Certification Methods
We propose to revise this section’s
heading to include a reference to
‘‘testing.’’ Additionally, we propose to
update the regulatory text hierarchy to
have paragraph (a) be applicable to
ONC–ATLs and paragraph (b) be
applicable to ONC–ACBs. We have
included this proposal for ONC–ATLs
because we believe the requirement to
provide for remote testing for both
development and deployment sites is
equally applicable to testing labs as it is
to certification bodies.
(14) Proposed Amendments to § 170.560
Good Standing as an ONC–ACB
We propose to revise this section’s
heading to include reference to ONC–
ATLs. Additionally, we propose to
revise the paragraph hierarchy to make
E:\FR\FM\02MRP3.SGM
02MRP3
11070
Federal Register / Vol. 81, No. 41 / Wednesday, March 2, 2016 / Proposed Rules
the paragraph (a) requirements
applicable to ONC–ACBs (without
modification) and to make the
paragraph (b) requirements applicable to
ONC–ATLs following the same set of
three requirements as for ONC–ACBs.
We believe mirroring these
requirements between ONC–ACBs and
ONC–ATLs provides for consistent
administration for both testing and
certification under the Program.
(15) Proposed Amendments to § 170.565
Revocation of ONC–ACB Status
We propose to revise this section’s
heading to include reference to ONC–
ATLs. Additionally, we propose to
revise paragraphs (a) through (h) to
include references to an ONC–ATL as
applicable. We propose to apply the
same oversight paradigm of Type-1 and
Type-2 7 violations to ONC–ATLs as we
apply to ONC–ACBs today. Further, we
propose to follow the same process for
ONC–ATLs as already included in this
section for ONC–ACBs. We believe this
consistency would enable ONC to treat
similar fact-based non-compliance
situations equitably among ONC–ACBs
and ONC–ATLs. We propose to
specifically add paragraph (d)(1)(iii) for
ONC–ATL suspension provisions
because the suspension provisions in
paragraph (d)(1)(ii) are too specific to
ONC–ACBs and certification and simply
referencing ONC–ATLs in that
paragraph would cause confusion.
Similarly, we propose to specifically
add paragraph (h)(3) related to the
extent and duration of revocation to
clearly divide the rules applicable to
ONC–ACBs from those that are
applicable to ONC–ATLs. This proposed
revision would place the current ONC–
ACB applicable regulation text in
proposed paragraph (h)(2).
mstockstill on DSK4VPTVN1PROD with PROPOSALS3
(16) Request for Comment on § 170.570
in the Context of an ONC–ATL’s Status
Being Revoked
Section 170.570 discusses the general
rule applicable to certifications issued
to Complete EHRs and/or Health IT
Modules in the event that an ONC–ACB
has had its status revoked. It also
includes specific steps that the National
Coordinator can follow if a Type-1
violation occurred that called into
7 Type-2 violations constitute non-compliance
with 45 CFR 170.560 (Good standing as an ONC–
ACB) (45 CFR 170.565(b)). An ONC–ACB must
maintain good standing by: (a) Adhering to the
Principles of Proper Conduct for ONC–ACBs; (b)
Refraining from engaging in other types of
inappropriate behavior, including an ONC–ACB
misrepresenting the scope of its authorization, as
well as an ONC–ACB certifying Complete EHRs
and/or Health IT Module(s) for which it does not
have authorization; and (c) Following all other
applicable Federal and State laws.
VerDate Sep<11>2014
19:43 Mar 01, 2016
Jkt 238001
question the legitimacy of certifications
conducted by the former ONC–ACB.
These provisions were specifically put
in place to provide clarity to the market
about the impact that an ONC–ACB’s
status revocation would have on
certified health IT in use as part of the
EHR Incentive Programs.
In the context of an ONC–ATL having
its status revoked, we have not
specifically proposed to modify
§ 170.570 to include a set of rules
applicable to such a scenario. In large
part, we do not believe that the same
provisions are necessary given the
tangible differences between test results
for a not yet certified product and an
issued certification being used by
hundreds or thousands of providers for
participation in other programs, HHS or
otherwise. We do, however, request
comment, whether there would be any
circumstances in which additional
clarity around the viability of test
results attributed to a not yet certified
product would be necessary.
Additionally, we request comment as to
whether we should include provisions
similar to those already in this section
to account for an instance where an
ONC–ATL has its status revoked as a
result of a Type-1 violation, which calls
into question the legitimacy of the test
results the ONC–ATL issued and, thus,
could call into question the legitimacy
of the subsequent certifications issued
to products by a potentially unknowing
or deceived ONC–ACB.
B. Public Availability of Identifiable
Surveillance Results
In the 2014 Edition final rule, for the
purposes of increased Program
transparency, we instituted a
requirement for the public posting of the
test results used to certify health IT (77
FR 54271). We also instituted a
requirement that a health IT developer
publicly disclose any additional types of
costs that a provider would incur for
using the health IT developer’s certified
health IT to participate in the EHR
Incentive Programs (77 FR 54273–74).
Building on these transparency and
public accountability requirements for
health IT developers, in the 2015
Edition final rule, we took steps to
increase the transparency related to
certified health IT through surveillance,
disclosure, and reporting requirements.
For instance, we now require ONC–
ACBs to report corrective action plans
and related data to the publicly
accessible CHPL. The purpose of this
reporting requirement, as described in
the 2015 Edition final rule, was to
ensure that health IT users,
implementers, and purchasers are
alerted to potential conformance issues
PO 00000
Frm 00016
Fmt 4701
Sfmt 4702
in a timely and effective manner,
consistent with the patient safety,
program integrity, and transparency
objectives of the 2015 Edition final rule.
In furtherance of our efforts to
increase Program transparency and
health IT developer accountability for
their certified health IT, we propose to
require ONC–ACBs to publicly publish
on their Web sites identifiable
surveillance results on a quarterly basis.
These surveillance results would
include information such as, but may
not be limited to: Names of health IT
developers; names of products and
versions; certification criteria and
Program requirements surveilled; and
outcomes of surveillance. This
information is already collected by
ONC–ACBs as part of their surveillance
efforts under the Program and should be
readily available for posting on their
Web sites.
The publication of identifiable
surveillance results, much like the
publication of corrective action plans on
the CHPL, would hold health IT
developers more accountable to the
customers and users of their certified
health IT. Customers and users would
be provided with valuable information
about the continued performance of
certified health IT as well as
surveillance efforts. To elaborate,
identifiable surveillance results would
serve to inform providers currently
using certified health IT as well as those
that may consider switching their
certified health IT or purchasing
certified health IT for the first time.
While we expect that the prospect of
publicly identifiable surveillance results
would motivate some health IT
developers to improve their
maintenance efforts, we believe that
most published surveillance results
would reassure customers and users of
certified health IT. This is because,
based on ONC–ACB surveillance results
to date, most certified health IT and
health IT developers are maintaining
conformance with certification criteria
and Program requirements. The
publishing of such ‘‘positive’’
surveillance results would also provide
a more complete context of surveillance;
rather than only sharing ‘‘negatives,’’
such as non-conformities and corrective
action plans.
We make clear that we do not propose
to require that publicly posted
surveillance results include certain
information that is proprietary, trade
secret, or confidential (e.g.,
‘‘screenshots’’ that may include such
information). We expect health IT
developers and ONC–ACBs to ensure
that such information is not posted
when making available the information
E:\FR\FM\02MRP3.SGM
02MRP3
Federal Register / Vol. 81, No. 41 / Wednesday, March 2, 2016 / Proposed Rules
we propose would be required to be
posted as noted above (i.e., but not
limited to, names of health IT
developers; names of products and
versions; certification criteria and
Program requirements surveilled; and
outcomes of surveillance).
We request public comment on the
publication of identifiable surveillance
results. Specifically, we request
comment on the types of information to
include in the surveillance results and
the format (e.g., summarized or
unrefined surveillance results) that
would be most useful to stakeholders. In
addition to the proposal for ONC–ACBs
to publish these results quarterly on
their Web sites, we request comment on
the value of publishing hyperlinks on
the ONC Web site to the results on the
ONC–ACBs’ Web sites. This may
provide stakeholders with a more
readily available means for accessing all
the results.
To implement the proposed new
requirement, we propose to revise
§ 170.523(i) of the PoPC for ONC–ACBs
by adding language that requires ONC–
ACBs to make identifiable surveillance
results publicly available on their Web
sites on a quarterly basis. We also
propose to revise § 170.556(e)(1) for
clarity and consistency with
§ 170.523(i)(2) by adding that the
ongoing submission of in-the-field
surveillance results to the National
Coordinator throughout the calendar
year must, at a minimum, be done on a
quarterly basis. Further, we propose to
reestablish a requirement that ONC–
ACBs submit an annual summative
report of surveillance results to the
National Coordinator. This previous
requirement was unintentionally
removed in the 2015 Edition final rule
when we established a quarterly
reporting requirement for surveillance
results. Summative reports provide
comprehensive summaries of the
surveillance conducted throughout the
year.
mstockstill on DSK4VPTVN1PROD with PROPOSALS3
III. National Technology Transfer and
Advancement Act
The National Technology Transfer
and Advancement Act (NTTAA) of 1995
(15 U.S.C. 3701 et seq.) and the Office
of Management and Budget (OMB)
Circular A–119 8 require the use of,
wherever practical, standards that are
developed or adopted by voluntary
consensus standards bodies to carry out
policy objectives or activities, with
certain exceptions. In this proposed
rule, we propose to adopt one voluntary
consensus standard (ISO 17025).
8 https://www.whitehouse.gov/omb/circulars_a119.
VerDate Sep<11>2014
19:43 Mar 01, 2016
Jkt 238001
IV. Incorporation by Reference
The Office of the Federal Register has
established requirements for materials
(e.g., standards and implementation
specifications) that agencies propose to
incorporate by reference in the Federal
Register (79 FR 66267; 1 CFR 51.5(a)).
Specifically, § 51.5(a) requires agencies
to discuss, in the preamble of a
proposed rule, the ways that the
materials it proposes to incorporate by
reference are reasonably available to
interested parties or how it worked to
make those materials reasonably
available to interested parties; and
summarize, in the preamble of the
proposed rule, the material it proposes
to incorporate by reference. To make the
materials we intend to incorporate by
reference reasonably available, we
provide a uniform resource locator
(URL) to the standard. The standard
must be purchased to obtain access.
Alternatively, a copy of the standard
may be viewed for free at the U.S.
Department of Health and Human
Services, Office of the National
Coordinator for Health Information
Technology, 330 C Street SW.,
Washington, DC 20201. Please call (202)
690–7171 in advance to arrange
inspection. As required by § 51.5(a), we
also provide a summary of the standard
we propose to adopt and subsequently
incorporate by reference in the Federal
Register.
ISO/IEC 17025:2005 General
requirements for the competence of
testing and calibration laboratories.
URL: ISO/IEC 17025:2005 (ISO 17025)
is available for purchase on the ISO Web
site at: https://www.iso.org/iso/
catalogue_detail.htm?csnumber=39883.
Summary: Accreditation bodies that
recognize the competence of testing and
calibration laboratories should use ISO
17025 as the basis for their
accreditation. Clause 4 specifies the
requirements for sound management.
Clause 5 specifies the requirements for
technical competence for the type of
tests and/or calibrations the laboratory
undertakes.
The use of ISO 17025 will facilitate
cooperation between laboratories and
other bodies, and assist in the exchange
of information and experience, and in
the harmonization of standards and
procedures.
V. Response to Comments
Because of the large number of public
comments normally received in
response to Federal Register
documents, we are not able to
acknowledge or respond to them
individually. We will consider all
comments we receive by the date and
PO 00000
Frm 00017
Fmt 4701
Sfmt 4702
11071
time specified in the DATES section of
this preamble, and, when we proceed
with a subsequent document, we will
respond to the comments in the
preamble of that document.
VI. Collection of Information
Requirements
Under the Paperwork Reduction Act
of 1995 (PRA), agencies are required to
provide 60-day notice in the Federal
Register and solicit public comment on
a proposed collection of information
before it is submitted to OMB for review
and approval. In order to fairly evaluate
whether an information collection
should be approved by the OMB,
section 3506(c)(2)(A) of the PRA
requires that we solicit comment on the
following issues:
1. Whether the information collection
is necessary and useful to carry out the
proper functions of the agency;
2. The accuracy of the agency’s
estimate of the information collection
burden;
3. The quality, utility, and clarity of
the information to be collected; and
4. Recommendations to minimize the
information collection burden on the
affected public, including automated
collection techniques.
A. ONC–AA and ONC–ACBs
Under the ONC Health IT
Certification Program, accreditation
organizations that wish to become the
ONC-Approved Accreditor (ONC–AA)
must submit certain information,
organizations that wish to become an
ONC–ACB must comply with collection
and reporting requirements, and ONC–
ACBs must comply with collection and
reporting requirements, records
retention requirements, and submit
annual surveillance plans and annually
report surveillance results. In the 2015
Edition proposed rule (80 FR 16894), we
estimated less than ten annual
respondents for all of the regulatory
‘‘collection of information’’
requirements that applied to the ONC–
AA and ONC–ACBs, including those
previously approved by OMB. In the
2015 Edition final rule (80 FR 62733),
we concluded that the regulatory
‘‘collection of information’’
requirements for the ONC–AA and the
ONC–ACBs were not subject to the PRA
under 5 CFR 1320.3(c). We further note
that the PRA (44 U.S.C. 3518(c)(1)(B)(ii))
exempts the information collections
specified in 45 CFR 170.565 that apply
to ONC–ACBs, which are collection
activities that would occur during
administrative actions or investigations
involving ONC against an ONC–ACB.
E:\FR\FM\02MRP3.SGM
02MRP3
11072
Federal Register / Vol. 81, No. 41 / Wednesday, March 2, 2016 / Proposed Rules
B. ONC–ATLs
We estimate less than ten annual
respondents for all of the proposed
regulatory ‘‘collection of information’’
requirements for ONC–ATLs under Part
170 of Title 45. Accordingly, the
regulatory ‘‘collection of information’’
requirements under the Program
described in this section are not subject
to the PRA under 5 CFR 1320.3(c). We
further note that the PRA (44 U.S.C.
3518(c)(1)(B)(ii)) exempts the
information collections specified in 45
CFR 170.565 that apply to ONC–ATLs,
which are collection activities that
would occur during administrative
actions or investigations involving ONC
against an ONC–ATL.
Since the establishment of the
Program in 2010, there have never been
more than six applicants or entities
selected for ONC–ATCB or accredited
testing lab status. We anticipate that
there will be no more than eight ONC–
ATLs participating in the Program.
on an estimated five respondents (ONC–
ATLs) for the reasons noted above. With
similar requirements to ONC–ACBs, we
estimate the same number of burden
hours for ONC–ATLs to comply with
§§ 170.520(b) and 170.540(c) as cited in
the 2015 Edition proposed rule (80 FR
16894). We also make the same
determination for ONC–ATL records
retention requirements under proposed
§ 170.524(f) as we did for the ONC–ACB
records retention requirements (i.e., no
burden hours) (80 FR 16894). We have
estimated two responses per year at one
hour per response for ONC–ATLs to
provide updated contact information to
ONC per § 170.524(d). We welcome
comments on our burden hour
estimates. We also welcome comments
on the estimated costs associated with
these proposed collection of information
requirements, which can be found in
section VII (‘‘Regulatory Impact
Statement’’) of this preamble.
There are currently only five accredited
testing labs under the Program. We
estimate that up to three more testing
labs may consider becoming accredited
and seek ONC–ATL status because of
our proposal to permit granting ONC–
ATL status to an accredited testing lab
for the testing of health IT to one
certification criterion or only a partial
certification criterion.
We welcome comments on these
conclusions and the supporting
rationale on which they are based.
The specific ‘‘collection of
information’’ requirements that apply to
ONC–ATLs are found in § 170.520(b);
proposed § 170.524(d) and (f); and
§ 170.540(c). We have estimated the
burden hours for these requirements in
case our conclusions above are found to
be misguided based on public
comments or other reasons. Our
estimates for the total burden hours are
expressed in the table below. The
estimated total burden hours are based
ESTIMATED ANNUALIZED TOTAL BURDEN HOURS
Code of federal
regulations
section
Type of respondent
ONC–ATL
ONC–ATL
ONC–ATL
ONC–ATL
.....................................................................
.....................................................................
.....................................................................
.....................................................................
Total burden hours for all collections of information.
mstockstill on DSK4VPTVN1PROD with PROPOSALS3
C. Health IT Developers
We propose in 45 CFR 170.580 that a
health IT developer would have to
submit certain information to ONC as
part of a review of the health IT
developer’s certified health IT and if
ONC took action against the certified
health IT (e.g., requiring a corrective
action plan to correct a non-conformity
or suspending or terminating a
certification for a Complete EHR or
Health IT Module). The PRA, however,
exempts these information collections.
Specifically, 44 U.S.C. 3518(c)(1)(B)(ii)
excludes collection activities during the
conduct of administrative actions or
investigations involving the agency
against specific individuals or entities.
VII. Regulatory Impact Statement
A. Statement of Need
The proposed rule proposes to
establish processes for ONC to expand
its role to directly review health IT
certified under the Program and take
action when necessary, including
requiring the correction of nonconformities found in health IT certified
VerDate Sep<11>2014
19:43 Mar 01, 2016
Jkt 238001
45
45
45
45
CFR
CFR
CFR
CFR
Number of
responses per
respondent
Number of
respondents
Total burden
hours
170.520(b)
170.524(d)
170.524(f)
170.540(c)
8
8
8
8
1
2
n/a
1
1
1
n/a
1
8
16
n/a
8
...............................
........................
........................
........................
32
under the Program and suspending and
terminating certifications issued to
Complete EHRs and Health IT Modules.
These processes would serve to address
non-conformities, particularly those that
may pose a risk to public health or
safety or create other exigent
circumstances that are inconsistent with
section 3001(b) of the PHSA. The
Program does not currently have
regulatory means for reviewing and
addressing such non-conformities and
reliance on ONC–ACBs is not
appropriate due to their limited scope of
responsibilities, expertise, and
resources. Therefore, we propose to
establish processes for ONC to address
these situations.
The proposed rule also proposes
processes for ONC to timely and directly
address testing issues. These processes
do not exist today under the current
Program structure, particularly as
compared to ONC’s oversight of ONC–
ACBs. In addition, the proposed rule
includes a provision for the increased
transparency and availability of
identifiable surveillance results. The
PO 00000
Average
burden hours
per response
Frm 00018
Fmt 4701
Sfmt 4702
publication of identifiable surveillance
results would support further
accountability of health IT developers to
their customers and users of certified
health IT.
B. Alternatives Considered
We assessed alternatives to our
proposed approaches for enhanced
oversight by ONC described in this
proposed rule (i.e., the direct review of
certified health IT and the authorization
and oversight of accredited testing labs
(ONC–ATLs)). One less stringent
alternative would be to maintain our
current approach for the Program in
which ONC–ACBs have sole
responsibility for issuing and
administering certifications in
accordance with ISO 17065, the PoPC
for ONC–ACBs, and other requirements
of the Program. This approach would
also leave the testing structure as it
currently exists. A second more
stringent alternative to what we
proposed would be for ONC to take
further responsibility for the testing,
certification, and ongoing compliance of
E:\FR\FM\02MRP3.SGM
02MRP3
mstockstill on DSK4VPTVN1PROD with PROPOSALS3
Federal Register / Vol. 81, No. 41 / Wednesday, March 2, 2016 / Proposed Rules
health IT with Program requirements by
making testing and certification
determinations and/or reviewing all
determinations made under the
Program. We believe either approach
would be misguided.
The current approach would leave no
means for ONC to address nonconformities in certified health IT that
are contrary to the National
Coordinator’s responsibilities under
section 3001(b) of the PHSA and, as
discussed in this proposed rule, ONC–
ACBs are not situated to address these
types of non-conformities. If we did not
change the current testing structure, a
lack of parity in ONC oversight for
testing and certification would continue
to exist. ONC direct oversight of ONC–
ATLs would ensure that, like with
ONC–ACBs, testing labs are directly and
immediately accountable to ONC for
their performance across a variety of
Program items that affect the testing of
health IT. Accordingly, and for the
reasons outlined in this proposed rule,
we do not believe maintaining the
Program as currently structured is
acceptable.
We fully considered the Program
structure when establishing the Program
and have made appropriate
modifications as the Program has
evolved (see the discussion in section
I.A of this preamble for a summary of
rulemaking related to the Program and
citations for the relevant rules). These
past considerations primarily focused
on a market-driven approach for the
Program with testing and certification
conducted on behalf of ONC and with
ONC retaining and establishing direct
and indirect oversight over certain
activities. As discussed in this proposed
rule, ONC–ACBs play an integral role in
the Program and have the necessary
expertise and capacity to effectively
administer specific Program
requirements. Accredited testing labs
also play an integral role in the
Program’s success through the testing of
health IT. Our proposals in this
proposed rule align with past
considerations and would only serve to
enhance the Program by providing more
consistency and accountability for
Program participants, which would
provide greater confidence in certified
health IT when it is implemented,
maintained, and used.
We welcome comments on our
assessment of alternatives and any
alternatives that we should also
consider.
C. Overall Impact
We have examined the impact of this
proposed rule as required by Executive
Order 12866 on Regulatory Planning
VerDate Sep<11>2014
19:43 Mar 01, 2016
Jkt 238001
and Review (September 30, 1993),
Executive Order 13563 on Improving
Regulation and Regulatory Review
(February 2, 2011), the Regulatory
Flexibility Act (5 U.S.C. 601 et seq.),
section 202 of the Unfunded Mandates
Reform Act of 1995 (2 U.S.C. 1532), and
Executive Order 13132 on Federalism
(August 4, 1999).
1. Executive Orders 12866 and 13563—
Regulatory Planning and Review
Analysis
Executive Orders 12866 and 13563
direct agencies to assess all costs and
benefits of available regulatory
alternatives and, if regulation is
necessary, to select regulatory
approaches that maximize net benefits
(including potential economic,
environmental, public health and safety
effects, distributive impacts, and
equity). A regulatory impact analysis
(RIA) must be prepared for major rules
with economically significant effects
($100 million or more in any one year).
OMB has determined that this proposed
rule is an economically significant rule
as the potential costs associated with
this proposed rule could be greater than
$100 million per year. Accordingly, we
have prepared an RIA that to the best of
our ability presents the costs and
benefits of the proposed rule.
a. Costs
We estimated the potential monetary
costs of this proposed rule for health IT
developers, ONC–ATLs, the Federal
government (i.e., ONC), and health care
providers as follows: (1) Costs for health
IT developers to correct nonconformities identified by ONC; (2)
costs for ONC and health IT developers
related to ONC review and inquiry into
certified health IT non-conformities; (3)
costs to health IT developers and ONC
associated with the proposed appeal
process following a suspension/
termination of a Complete EHR’s or
Health IT Module’s certification; (4)
costs to health care providers to
transition to another certified health IT
product when the certification of a
Complete EHR or Health IT Module that
they currently use is terminated; (5)
costs for ONC–ATLs and ONC
associated with ONC–ATL
accreditation, application, renewal, and
reporting requirements; (6) costs for
ONC–ATLs and ONC related to revoking
ONC–ATL status; and (7) costs for
ONC–ACBs to publicly post identifiable
surveillance results. We also provide an
overall annual monetary cost estimate
for this proposed rule (see (8) Total
Annual Cost Estimate). We note that we
have rounded all estimates to the
PO 00000
Frm 00019
Fmt 4701
Sfmt 4702
11073
nearest dollar and all estimates are
expressed in 2016 dollars.
We have made employee assumptions
about the level of expertise needed to
complete the proposed requirements in
this section. We have correlated that
expertise with the corresponding grade
and step of an employee classified
under the General Schedule Federal
Salary Classification, relying on the
associated employee hourly rates for the
Washington, DC locality pay area as
published by the Office of Personnel
Management. We have assumed that an
applicant expends one hundred percent
(100%) of an employee’s hourly wage
on benefits for the employee. Therefore,
we have doubled the employee’s hourly
wage to account for benefits. We have
concluded that a 100% expenditure on
benefits is an appropriate estimate based
on research conducted by HHS.
We have used the General Schedule
Federal Salary Classification for private
sector employee wage calculations
because the majority of the proposed
tasks and requirements that would be
performed by private sector employees
do not easily fall within a particular
occupational classification identified by
the Bureau of Labor Statistics (BLS). For
instance, while we estimate costs for
specialized testing labs personnel to
support accreditation, we also estimate
costs for participating in administrative
reviews and appeals and reporting
certain information to ONC. As noted
above, in all instances, we correlated the
expertise needed to complete the task or
requirement with the corresponding
grade and step of a federal employee
classified under the General Schedule
Federal Salary Classification.
We welcome comments on our
methodology for estimating employee
costs, including whether there are
appropriate BLS occupational
classifications and wages that we should
instead use to estimate employee costs
and the costs of the tasks and
requirements proposed in this proposed
rule.
(1) Costs for Health IT Developers To
Correct a Non-Conformity Identified by
ONC
We do not believe health IT
developers face additional direct costs
for the proposed ONC direct review of
certified health IT, including the
National Coordinator fulfilling the
responsibilities of section 3001(b) of the
PHSA. There are no new certification
requirements proposed in this proposed
rule. Health IT developers have already
been certified to applicable certification
criteria and other Program requirements.
Further, health IT developers should
already be ensuring that their certified
E:\FR\FM\02MRP3.SGM
02MRP3
mstockstill on DSK4VPTVN1PROD with PROPOSALS3
11074
Federal Register / Vol. 81, No. 41 / Wednesday, March 2, 2016 / Proposed Rules
health IT is not, for example, creating
public health and/or safety issues by
causing medical errors or leaving a
patient’s health information unprotected
in violation of applicable law (e.g., in
violation of the Health Insurance
Portability and Accountability Act).
However, we acknowledge that this
proposed rule may: (1) Lead health IT
developers to reassess whether their
certified health IT is conformant; and (2)
require health IT developers to correct
non-conformities found by ONC in their
certified health IT.
We have been unable to estimate the
costs for health IT developers to reassess
their certified health IT for any nonconformities due to, but not limited to,
the variability of health IT developers’
certified technologies, current
conformance, quality management
systems, implementation of certified
health IT, and resources. Additionally,
we are not aware of relevant data or
methodology we could use to estimate
these costs. We do not, however,
anticipate that this reassessment would
result in substantial costs to health IT
developers because health IT developers
should have means for routinely
evaluating their certified health IT for
potential issues. We welcome comment
on relevant data and methods we could
use to estimate these costs.
If ONC identifies a non-conformity
with a health IT developer’s certified
health IT, the costs incurred by the
health IT developer to bring the product
into conformance would be determined
on a case-by-case basis. If ONC found a
non-conformity with a certified
capability related to a certification
criterion, then the costs are not truly a
result of this proposed rule because a
health IT developer’s product should
remain conformant to those criteria and
the costs to meet certification criteria
were previously estimated in the 2014
Edition final rule and the 2015 Edition
final rule. Alternatively, ONC could find
either that certified health IT is causing
medical errors or contributing to a
patient’s health information being
unsecured and unprotected in violation
of applicable law. In either instance, the
monetary costs to correct the nonconformity would likely vary
significantly based on factors such as
the cause of the non-conformity and
how easily it could be corrected. We are
unable to reliably estimate these costs as
we do not have cost estimates for a
comparable situation. We request
comment on existing relevant data and
methods we could use to estimate these
costs.
VerDate Sep<11>2014
19:43 Mar 01, 2016
Jkt 238001
(2) Costs for ONC and Health IT
Developers Related to ONC Review and
Inquiry Into Certified Health IT NonConformities
ONC would have broad discretion to
review certified health IT. However, we
anticipate that such review would be
relatively infrequent and would focus
on situations that pose a risk to public
health or safety. We estimate that a
health IT developer may commit, on
average and depending on complexity,
between 80 and 400 hours of staff time
to provide ONC with all requested
records and documentation that ONC
would use to make a suspension and/or
termination determination. We assume
that the expertise of the employee(s)
needed to comply with ONC’s requests
would be equivalent to a GS–15, Step 1
federal employee. The hourly wage with
benefits for a GS–15, Step 1 employee
located in Washington, DC is
approximately $122.74. Therefore, we
estimate the cost for a health IT
developer to cooperate with an ONC
review and inquiry into certified health
IT would, on average, range from $9,819
to $49,096. We note that some health IT
developers’ costs are expected to be less
and some health IT developers’ costs are
expected to be more than this estimated
cost range.
We estimate that ONC may commit,
on average and depending on
complexity, between 20 and 600 hours
of staff time to complete a review and
inquiry into certified health IT. We
assume that the expertise of a GS–15,
Step 1 federal employee(s) would be
necessary. Therefore, we estimate the
cost for ONC to review and conduct an
inquiry into certified health IT would,
on average, range from $2,455 to
$73,644. We note that some reviews and
inquiries may cost less and some may
cost more than this estimated cost range.
We welcome comment on our
estimated costs and any comparable
processes and costs that we could use to
improve our cost estimates. We intend
to continue to conduct fact-finding in an
effort to provide more reliable cost
estimates in a subsequent final rule.
(3) Costs to Health IT Developers and
ONC Associated With the Proposed
Appeal Process Following a
Suspension/Termination of a Complete
EHR’s or Health IT Module’s
Certification
As discussed in section II.A.1.c.(5) of
this preamble, we propose in
§ 170.580(f) to permit a health IT
developer to appeal an ONC
determination to suspend or terminate a
certification issued to a Complete EHR
or Health IT Module. We estimate that
PO 00000
Frm 00020
Fmt 4701
Sfmt 4702
a health IT developer may commit, on
average and depending on complexity,
between 80 to 240 hours of staff time to
provide the required information to
appeal a suspension or termination and
respond to any requests from the
hearing officer. We assume that the
expertise of the employee(s) needed to
participate in the appeal would be
equivalent to a GS–15, Step 1 federal
employee. The hourly wage with
benefits for a GS–15, Step 1 employee
located in Washington, DC is
approximately $122.74. Therefore, we
estimate the cost for a health IT
developer to appeal a suspension or
termination would, on average, range
from $9,819 to $29,458. We note that
some health IT developers’ costs are
expected to be less and some health IT
developers’ costs are expected to be
more than this estimated cost range.
We estimate that ONC would commit,
on average and depending on
complexity, between 200 and 800 hours
of staff time to conduct an appeal. This
would include the time to represent
ONC in the appeal and support the costs
for the hearing officer. We assume that
the expertise of a GS–15, Step 1 federal
employee(s) would be necessary.
Therefore, we estimate the cost for ONC
to conduct an appeal would, on average,
range from $24,548 to $98,192. We note
that some appeals may cost less and
some may cost more than this estimated
cost range.
We welcome comment on our
estimated costs and any comparable
processes and costs that we could use to
improve our cost estimates. We intend
to continue to conduct fact-finding in an
effort to provide more reliable cost
estimates in a subsequent final rule.
(4) Costs to Health Care Providers To
Transition to Another Certified Health
IT Product When the Certification of a
Complete EHR or Health IT Module
That They Currently Use Is Terminated
This cost analysis with regards to
health care providers focuses on the
direct effects of the termination of a
Complete EHR’s or Health IT Module’s
certification under this proposed rule’s
provisions as a certification termination
would have the greatest potential
impact. We note and emphasize that the
estimated costs for health care providers
as a result of a certification termination
could be incurred absent the proposals
in this proposed rule. ONC–ACBs
currently have the authority to
terminate (and suspend) the
certifications of Complete EHRs and
Health IT Modules. In this regard, ONC–
ACBs have terminated certifications for
both Complete EHRs and Health IT
Modules.
E:\FR\FM\02MRP3.SGM
02MRP3
Federal Register / Vol. 81, No. 41 / Wednesday, March 2, 2016 / Proposed Rules
The most recent termination of a
certification by an ONC–ACB occurred
in September 2015 when the
certifications of a health IT developer’s
Complete EHRs and Health IT Modules
were terminated for failure to respond
and participate in routine surveillance
requests.9 Only 48 eligible professionals
(EPs) attested under the Medicare EHR
Incentive Program to using these
products. In April 2013, an ONC–ACB
terminated the certifications of
Complete EHRs and Health IT Modules
because they did not meet the required
functionality.10 Those health IT
products had no Medicare attestations.
Considering that these are the only
terminations and impacts over the five
years of the Program and consistent
with our stated intent in this proposed
rule to work with health IT developers
to correct non-conformities found in
their certified health IT under the
provisions in this proposed rule, it is
highly unlikely that the high end of our
estimated costs for health care providers
would ever be realized.
We estimated the monetary costs that
would be sustained by health care
providers to transition to another
certified health IT product when the
certification of a Complete EHR or
Health IT Module that they currently
use is terminated. We anticipate that
health care providers impacted by
certification termination would
transition to a new certified health IT
product due to eventually needing
certified health IT to participate in other
HHS programs requiring the use of
certified health IT (e.g., the EHR
Incentive Programs 11). The estimated
upfront cost for health care providers is
calculated using the number of known
EPs that report under the Medicare EHR
Incentive Program using certified
Complete EHRs and certified Health IT
Modules that would have their
certifications terminated multiplied by
an estimated average cost per product
per provider to implement a new
certified health IT product. The
estimated average cost per product per
provider to implement a new certified
health IT product is approximately
$33,000. This estimation is consistent
with other analyses on average costs.12
This analysis and cost estimates do
not include sunk costs during the
transition year, such as ongoing
maintenance for the health IT product
that had its certification(s) terminated
and any upfront costs the provider paid
for the health IT product. The transition
by a health care provider to a new
health IT product could also include
non-sunk costs associated with
unwinding contractual matters and
technological connectivity,
replacement/implementation efforts,
training of workforce, and the potential
for an operational shut down to
effectuate a transition to a replacement
technology. In regard to contractual
matters we acknowledge that
transitioning to a new certified health IT
product following a certification
termination may be further complicated
by the fact that health care providers
may have entered multi-year
transactions for a Complete EHR or
Health IT Module(s). These costs would
likely vary significantly based on the
contract and specific situation.
Conversely, unlike the cost categories
just mentioned, which would tend to
make our estimates understate the costs
to providers due to a termination of
11075
certification, some aspects of certified
health IT implementation may be
similar across products, thus reducing
the costs of transitioning to a new
product below the costs incurred in
association with the original
implementation.
We used the following formula to
calculate the estimated upfront costs for
health care providers to transition to a
new product:
1. Number of EPs reporting with a
certified Complete EHR or certified
Health IT Module that could
potentially have its certification
terminated
2. #1 multiplied by the average upfront
cost per product per health care
provider
3. Result of #2 equals the estimated cost
for health care providers to replace
the certified Complete EHR or
certified Health IT Module
Applying this formula, we calculated
the upper and lower threshold impacts
as well as the median and mean impacts
of terminating certifications issued to a
Complete EHR or Health IT Module(s).
The upper and lower thresholds were
calculated from the certified Complete
EHR and certified Health IT Modules
with the greatest and least number of
reported attestations to the Medicare
EHR Incentive Program respectively.13
The median and mean impacts also
were calculated using the number of
reported attestations for each product
(see ‘‘Cost Impact to Health Care
Providers’’ table). We calculated the
estimated cost to those health care
providers assuming all the health care
providers would transition to a new
certified health IT product.
COST IMPACT TO HEALTH CARE PROVIDERS
Lower
mstockstill on DSK4VPTVN1PROD with PROPOSALS3
Number of EP Attestations ..............................................................................
Calculated Cost ...............................................................................................
1
$33,000
Median
24
$792,000
Mean
190
$6,270,000
Upper
19,692
$649,836,000
We estimate the cost impact of
certification termination on health care
providers would range from $33,000 to
$649,836,000 with a median cost of
$792,000 and a mean cost of $6,270,000.
We welcome comment on our proposed
approach and cost estimates as well as
the identification of any reliable data
upon which we could base or revise our
cost estimates in a subsequent final rule.
We note that health IT developers
may be required to pay for transition
costs of health care providers due to
certification termination. A complete
presentation regarding who bears these
costs is excluded from our analysis
because arrangements would vary by
contract and we do not have relevant
data upon which to base an estimate.
9 https://www.hhs.gov/news/press/2015pres/09/
20150902c.html.
10 https://www.hhs.gov/about/news/2013/04/25/
certification-for-electronic-health-record-productrevoked.html.
11 See CMS EHR Incentive Programs FAQ 12657:
https://questions.cms.gov/faq.php?isDept=0&
search=decertified&searchType=keyword&
submitSearch=1&id=5005.
12 A Health Affairs study (https://
content.healthaffairs.org/content/30/3/481.abstract)
estimated the average cost for EHR implementation
at a five-physician practice as $162,000. Dividing by
five, the estimated cost per physician is $32,400,
which is close to our estimated cost of $33,000 to
implement an in-office health IT product.
13 As of November 30, 2015.
VerDate Sep<11>2014
19:43 Mar 01, 2016
Jkt 238001
PO 00000
Frm 00021
Fmt 4701
Sfmt 4702
E:\FR\FM\02MRP3.SGM
02MRP3
11076
Federal Register / Vol. 81, No. 41 / Wednesday, March 2, 2016 / Proposed Rules
(5) Costs for ONC–ATLs and ONC
Associated With ONC–ATL
Accreditation, Application, Renewal,
and Reporting Requirements
mstockstill on DSK4VPTVN1PROD with PROPOSALS3
Costs for the Applicant/ONC–ATL
An applicant for ONC–ATL status
would be required to submit an
application and must be accredited in
order to be a qualified ONC–ATL
applicant. As specified in section VI.B
of this preamble, we estimate that there
would be between five and eight
applicants, five of which are already
accredited by NVLAP to ISO 17025 and
up to three new applicants. Any new
applicants for ONC–ATL status under
the Program would first be required to
become accredited by NVLAP to ISO
17025.
Based on our consultations with
NIST, we estimate that it would take
approximately 2–5 days for NVLAP to
complete a full scope on-site assessment
for all criteria required for accreditation
at an approximate cost of $11,000. The
on-site assessment fee covers the costs
incurred by the assessors conducting the
on-site assessment such as preparation
time, time on-site, and travel costs (e.g.
flights, hotel, meals, etc.). Proposed
§ 170.511 would permit the
authorization of ONC–ATLs for testing
to one or even a partial certification
criterion. Based on consultations with
NIST, this would take at least one day
to complete and may reduce the
necessary scope and cost of the on-site
assessment to approximately $8,000.
The current five accredited testing labs
would each incur the full scope on-site
assessment fee of $11,000, as discussed
below. We anticipate the potential three
new applicants would each incur a
limited scope on-site assessment fee of
$8,000, as discussed below.
We estimate the applicant staff time
necessary to prepare and participate in
the full scope on-site assessment at 200
hours, which is consistent with the
estimate we used for ONC–ACBs based
on stakeholder feedback (76 FR 1316).
We estimate the applicant staff time
necessary to prepare and participate in
the limited scope on-site assessment at
100 hours, which is half the estimate for
the full scope on-site assessment. We
believe an employee equivalent to a GS–
15, Step 1 federal employee would be
responsible for preparation and
participation in the accreditation
assessment. The hourly wage with
benefits for a GS–15, Step 1 employee
located in Washington, DC is
approximately $122.74. Therefore, we
estimate the applicant staff cost for the
full scope on-site assessment at $24,548
and the applicant staff cost for the
VerDate Sep<11>2014
19:43 Mar 01, 2016
Jkt 238001
limited scope on-site assessment at
$12,274.
We anticipate that ONC–ATLs would
incur an estimated $5,000 accreditation
administrative/technical support fee
each year during the three-year ONC–
ATL authorization period.14 The
accreditation administrative/technical
support fee covers costs associated with
NVLAP staff under the Program. On-site
assessments are required prior to initial
accreditation, during the first renewal
year, and every two years thereafter. As
such, we expect the potential three new
applicants would each incur the on-site
assessment fee twice during their initial
three-year ONC–ATL authorization
period and the current five accredited
testing labs would incur the on-site
assessment fee once during the same
period. Further, as stated above, each
full scope on-site assessment for all
criteria would cost approximately
$11,000 and each limited scope on-site
assessment would cost approximately
$8,000. We estimate that staff expertise
and cost for renewal is likely to remain
consistent at approximately $24,548 for
a full scope on-site assessment and
$12,274 for a limited scope on-site
assessment. We expect that each ONC–
ATL would renew its status, meaning it
would request reauthorization from
ONC to be an ONC–ATL, every three
years.
After becoming accredited by NVLAP,
an applicant for ONC–ATL status would
incur minimal costs to prepare and
submit an application to the National
Coordinator. We believe that it would
take ten minutes to provide the general
information requested in the
application, 30 minutes to assemble the
information necessary to provide
documentation of accreditation by
NVLAP, and 20 minutes to review and
agree to the PoPC for ONC–ATLs. We
believe these time estimates would also
be accurate for an ONC–ATL to
complete the proposed status renewal
process. Based on our consultations
with NIST, we believe that an employee
equivalent to a GS–9, Step 1 federal
employee could provide the required
general identifying information and
documentation of accreditation status.
The hourly wage with benefits for a GS–
9, Step 1 federal employee located in
Washington, DC is approximately
$51.20. We believe that an employee
equivalent to a GS–15, Step 1 federal
employee would be responsible for
reviewing and agreeing to the PoPC for
ONC–ATLs. Therefore, our cost estimate
per ONC–ATL for these activities is
$75.04.
14 See NVLAP Fee Structure, https://www.nist.gov/
nvlap/nvlap-fee-policy.cfm.
PO 00000
Frm 00022
Fmt 4701
Sfmt 4702
Overall, we estimate that the total cost
of ONC–ATL accreditation, application,
and the first proposed three-year
authorization period would be
approximately $55,623 and the total
cost for up to three new applicants
would be approximately $166,869. We
assume that ONC–ATLs would remain
accredited during the three-year ONC–
ATL authorization period.
We estimate the total cost for an
ONC–ATL to renew its accreditation,
application, and authorization during
the first three-year ONC–ATL
authorization period to be
approximately $50,623 and the total
renewal cost for all five current ONC–
ATLs to be approximately $253,115.
Based on our cost estimate timeframe of
three years, the annualized renewal cost
would be approximately $84,372.
We propose in § 170.524(d) that ONC–
ATLs shall report various changes to
their organization within 15 days. We
believe an employee equivalent to the
Federal Salary Classification of GS–9,
Step 1 could complete the transmissions
of the requested information to ONC. As
specified in section VI.B of this
preamble, we estimate two responses
per year at one hour per response for
ONC–ATLs to provide updated
information to ONC per § 170.524(d).
Accordingly, we estimate it would cost
each ONC–ATL $102.40 annually to
meet this requirement. To estimate the
highest possible cost, we assume that
the eight applicants we estimate would
apply to become ONC–ATLs would
become ONC–ATLs. Therefore, we
estimate the total annual cost for ONC–
ATLs to meet the requirements of
proposed § 170.524(d) to be $819.
We propose in § 170.524(f) that ONC–
ATLs shall retain all records related to
the testing of Complete EHRs and
Health IT Modules to an edition of
certification criteria for a minimum of
three years from the effective date that
removed the applicable edition from the
Code of Federal Regulations. Based on
our consultations with NIST, we believe
this time period is in line with common
industry practices. Consequently, it
does not represent an additional cost to
ONC–ATLs.
We welcome comments on our
methodology and estimated costs.
Costs to ONC
We estimate the cost to develop the
ONC–ATL application to be $522 based
on the five hours of work we believe it
would take a GS–14, Step 1 federal
employee to develop an application
form. The hourly wage with benefits for
a GS–14, Step 1 employee located in
Washington, DC is approximately
$104.34. We also anticipate that there
E:\FR\FM\02MRP3.SGM
02MRP3
Federal Register / Vol. 81, No. 41 / Wednesday, March 2, 2016 / Proposed Rules
mstockstill on DSK4VPTVN1PROD with PROPOSALS3
would be costs associated with
reviewing applications under the
Program. We expect that a GS–15, Step
1 federal employee would review the
applications and ONC (or a designated
representative) would issue final
decisions on all applications. We
anticipate that it would take
approximately 20 hours to review and
reach a final decision on each
application. This estimate assumes a
satisfactory application (i.e., no formal
deficiency notifications) and includes
the time necessary to verify the
information in each application and
prepare a briefing for the National
Coordinator. We estimate the cost for
the application review process to be
$2,455. As a result, we estimate ONC’s
overall cost of administering the entire
application process to be approximately
$2,977. Based on our cost estimate
timeframe of three years, the annualized
cost to ONC would be $992. These costs
would be the same for a new applicant
or ONC–ATL renewal.
As proposed, we would also post the
names of applicants granted ONC–ATL
status on our Web site. We believe there
would be minimal cost associated with
this action and estimate the potential
cost for posting and maintaining the
information on our Web site to be
approximately $446 annually. This
amount is based on a maximum of six
hours of work for a GS–12, Step 1
federal employee. The hourly wage with
benefits for a GS–12 Step 1 federal
employee located in Washington, DC is
$74.
We believe there would be minimal
cost associated with recording and
maintaining updates and changes
reported by the ONC–ATLs. We
estimate an annual cost to the federal
government of $743. This amount is
based on ten hours of yearly work of a
GS–12, Step 1 federal employee.
We welcome comments on our
methodology and estimated costs.
we estimate the cost for an ONC–ATL to
comply with ONC requests per
§ 170.565 would, on average, range from
$2,455 to $19,638. We note that in some
instances the costs may be less and in
other instances the costs may exceed
this estimated cost range.
(6) Costs for ONC–ATLs and ONC
Related To Revoking ONC–ATL Status
As discussed in section II.A.2.b.(15) of
this preamble, we propose to revise
§ 170.565 to apply the same process for
ONC–ATL status revocation as applies
to ONC–ACBs. We estimate that an
ONC–ATL may commit, on average and
depending on complexity, between 20
and 160 hours of staff time to provide
responses and information requested by
ONC. We assume that the expertise of
the employee(s) needed to comply with
ONC’s requests would be equivalent to
a GS–15, Step 1 federal employee. The
hourly wage with benefits for a GS–15,
Step 1 employee located in Washington,
DC is approximately $122.74. Therefore,
(8) Total Annual Cost Estimate
We estimate the total annual cost for
this proposed rule, based on the cost
estimates outlined above, would range
from $230,616 to $650,288,915 with an
average annual cost of $6,595,268.
VerDate Sep<11>2014
19:43 Mar 01, 2016
Jkt 238001
Costs to ONC
We estimate that ONC would commit,
on average and depending on
complexity, between 40 and 320 hours
of staff time to conducting actions under
§ 170.565 related to ONC–ATLs. We
assume that the expertise of a GS–15,
Step 1 federal employee(s) would be
necessary. Therefore, we estimate the
cost for ONC would, on average, range
from $4,910 to $39,277. We note that in
some instances the costs may be less
and in other instances the costs may
exceed this estimated cost range.
We welcome comment on our
estimated costs and any comparable
processes and costs that we could use to
improve our cost estimates. We intend
to continue to conduct fact-finding in an
effort to provide more reliable cost
estimates in a subsequent final rule.
(7) Costs for ONC–ACBs To Publicly
Post Identifiable Surveillance Results
In section II.B of this preamble, we
propose to require ONC–ACBs to make
identifiable surveillance results publicly
available on their Web sites on a
quarterly basis. We believe that an
employee equivalent to a GS–9, Step 1
federal employee could post the
surveillance results. We believe it
would take the employee no more than
four hours annually to prepare and post
the surveillance results. The hourly
wage with benefits for a GS–9, Step 1
federal employee located in
Washington, DC is approximately
$51.20. Therefore, we estimate the
annual cost for each ONC–ACB to post
surveillance results to be $205 and the
total cost for all ONC–ACBs to be $615.
b. Benefits
The proposed rule’s provisions for
ONC direct review of certified health IT
would promote health IT developers’
accountability for the performance,
reliability, and safety of certified health
IT; and facilitate the use of safer and
reliable health IT by health care
providers and patients. Specifically,
ONC’s direct review of certified health
IT would permit ONC to assess non-
PO 00000
Frm 00023
Fmt 4701
Sfmt 4702
11077
conformities and prescribe
comprehensive corrective actions for
health IT developers to address nonconformities, including notifying
affected customers. As previously
stated, our first and foremost goal would
be to work with health IT developers to
remedy any non-conformities with
certified health IT in a timely manner
and across all customers. If ONC
ultimately suspends and/or terminates a
certification issued to a Complete EHR
or Health IT Module under the
proposals in this proposed rule, such
action would serve to protect the
integrity of the Program and users of
health IT. While we do not have
available means to quantify the benefits
of ONC direct review of certified health
IT, we believe that ONC direct review
supports and enables the National
Coordinator to fulfill his/her
responsibilities under the HITECT Act,
instills public confidence in the
Program, and protects public health and
safety.
The proposed rule’s provisions would
also provide other benefits. The
proposals for ONC to authorize and
oversee testing labs (ONC–ATLs) would
facilitate further public confidence in
testing and certification by permitting
ONC to timely and directly address
testing issues for health IT. The
proposed public availability of
identifiable surveillance results would
enhance transparency and the
accountability of health IT developers to
their customers. This proposal would
provide customers and users of certified
health IT with valuable information
about the continued performance of
certified health IT as well as
surveillance efforts. Further, the public
availability of identifiable surveillance
results would likely benefit health IT
developers by providing a more
complete context of surveillance and
illuminating good performance and the
continued compliance of certified
health IT with Program requirements.
Again, while we do not have available
means to quantify these benefits, we
believe these proposed approaches, if
finalized, would improve Program
compliance and further public
confidence in certified health IT.
We welcome comment on potential
means, methods, and relevant
comparative studies and data that we
could use to quantify these benefits. To
note, we do not have data to establish
how often we would need to exercise
direct review, the extent of existing and
future non-conformities, and the likely
outcomes that would be achieved by
ONC review, including up to preventing
the loss of life. Similarly, we do not
have data to establish that our proposals
E:\FR\FM\02MRP3.SGM
02MRP3
11078
Federal Register / Vol. 81, No. 41 / Wednesday, March 2, 2016 / Proposed Rules
mstockstill on DSK4VPTVN1PROD with PROPOSALS3
for direct oversight of testing labs and
the public availability of identifiable
surveillance results would actually
result in greater public confidence in
certified health IT, including greater
adoption of certified health IT. We also
welcome comment on other benefits,
quantifiable and non-quantifiable,
which could be achieved through the
proposals we have put forth in this
proposed rule.
2. Regulatory Flexibility Act
The Regulatory Flexibility Act (RFA)
requires agencies to analyze options for
regulatory relief of small businesses if a
rule has a significant impact on a
substantial number of small entities.
The Small Business Administration
(SBA) establishes the size of small
businesses for federal government
programs based on average annual
receipts or the average employment of a
firm.15 The entities that are likely to be
directly affected by this proposed final
rule are applicants for ONC–ATL status
and health IT developers.
We estimate up to eight applicants for
ONC–ATL status. These applicants
would be classified under the North
American Industry Classification
System (NAICS) codes 541380 (Testing
Laboratories) specified at 13 CFR
121.201 where the SBA publishes
‘‘Small Business Size Standards by
NAICS Industry.’’ 16 The SBA size
standard associated with this NAICS
code is set at $15 million annual
receipts or less. As specified in section
VII.C above, we estimate minimal costs
for applicants for ON–ATL status to
apply and participate in the Program as
ONC–ATLs. We believe that we have
proposed the minimum amount of
requirements necessary to accomplish
our goal of enhanced oversight of testing
under the Program. As discussed under
section VII.B above, there are also no
appropriate regulatory or non-regulatory
alternatives that could be developed to
lessen the compliance burden
associated with this proposed rule. We
further note that we expect all of the
estimated costs to be recouped by those
applicants that become ONC–ATLs
through the fees they charge for testing
health IT under the Program.
While health IT developers that
pursue certification of their health IT
under the Program represent a small
segment of the overall information
technology industry, we believe that
15 The SBA references that annual receipts means
‘‘total income’’ (or in the case of a sole
proprietorship, ‘‘gross income’’) plus ‘‘cost of goods
sold’’ as these terms are defined and reported on
Internal Revenue Service tax return forms.
16 https://www.sba.gov/sites/default/files/files/
Size_Standards_Table.pdf
VerDate Sep<11>2014
19:43 Mar 01, 2016
Jkt 238001
many health IT developers impacted by
this proposed rule most likely fall under
the North American Industry
Classification System (NAICS) code
541511 ‘‘Custom Computer
Programming Services.’’ 17 The SBA size
standard associated with this NAICS
code is set at $27.5 million annual
receipts or less. There is enough data
generally available to establish that
between 75% and 90% of entities that
are categorized under the NAICS code
541511 are under the SBA size standard.
We also note that with the exception of
aggregate business information available
through the U.S. Census Bureau and the
SBA related to NAICS code 541511, it
appears that many health IT developers
that pursue certification of their health
IT under the Program are privately held
or owned and do not regularly, if at all,
make their specific annual receipts
publicly available. As a result, it is
difficult to locate empirical data related
to many of these health IT developers to
correlate to the SBA size standard.
However, although not perfectly
correlated to the size standard for
NAICS code 541511, we do have
information indicating that over 60% of
health IT developers that have had
Complete EHRs and/or Health IT
Modules certified to the 2011 Edition
have less than 51 employees.
We estimate that this proposed rule
would have effects on health IT
developers, some of which may be small
entities, that have certified health IT or
are likely to pursue certification of their
health IT under the Program because
health IT developers may need to
reassess their health IT to verify
compliance with the Program
requirements outlined in this proposed
rule and they may have their certified
health IT subjected to a corrective
action, suspension, and/or termination
under the provisions of this proposed
rule. We believe, however, that we have
proposed the minimum amount of
requirements necessary to accomplish
our primary policy goals of enhancing
Program oversight and health IT
developer accountability for the
performance, reliability, and safety of
certified health IT. Further, as discussed
under section VII.B above, there are no
appropriate regulatory or non-regulatory
alternatives that could be developed to
lessen the compliance burden
associated with this proposed rule as
this proposed rule places no new
requirements on health IT developers,
unless their certified health IT is
reviewed by ONC and found to have a
non-conformity.
17 https://www.sba.gov/sites/default/files/files/
Size_Standards_Table.pdf
PO 00000
Frm 00024
Fmt 4701
Sfmt 4702
We do not believe that the proposed
rule would create a significant impact
on a substantial number of small
entities, but request comment on
whether there are small entities that we
have not identified that may be affected
in a significant way by this proposed
rule. Additionally, the Secretary
proposes to certify that this proposed
rule would not have a significant impact
on a substantial number of small
entities.
3. Executive Order 13132—Federalism
Executive Order 13132 establishes
certain requirements that an agency
must meet when it promulgates a
proposed rule (and subsequent final
rule) that imposes substantial direct
requirement costs on state and local
governments, preempts state law, or
otherwise has federalism implications.
Nothing in this proposed rule imposes
substantial direct compliance costs on
state and local governments, preempts
state law, or otherwise has federalism
implications. We are not aware of any
state laws or regulations that are
contradicted or impeded by any of the
proposals in this proposed rule. We
welcome comments on this assessment.
4. Unfunded Mandates Reform Act of
1995
Section 202 of the Unfunded
Mandates Reform Act of 1995 requires
that agencies assess anticipated costs
and benefits before issuing any rule that
imposes unfunded mandates on state,
local, and tribal governments or the
private sector requiring spending in any
one year of $100 million in 1995 dollars,
updated annually for inflation. The
current inflation-adjusted statutory
threshold is approximately $144
million. While the estimated potential
cost effects of this proposed rule reach
the statutory threshold, we do not
believe this proposed rule imposes
unfunded mandates on state, local, and
tribal governments or the private sector.
As described under section VII.C.1
above, we estimate the potential
monetary costs for the private sector
(health IT developers and health care
providers), which would be the result of
a health IT developer not maintaining
its product(s) compliance with
voluntary Program requirements and
having its product’s certification
terminated. The minimal monetary cost
estimates for ONC–ATLs derive from
voluntary participation in the Program
and would be recouped through fees
charged for the testing of health IT
under the Program. We welcome
comments on these conclusions.
OMB reviewed this proposed rule.
E:\FR\FM\02MRP3.SGM
02MRP3
Federal Register / Vol. 81, No. 41 / Wednesday, March 2, 2016 / Proposed Rules
List of Subjects in 45 CFR Part 170
Computer technology, Electronic
health record, Electronic information
system, Electronic transactions, Health,
Health care, Health information
technology, Health insurance, Health
records, Hospitals, Incorporation by
reference, Laboratories, Medicaid,
Medicare, Privacy, Reporting and
recordkeeping requirements, Public
health, Security.
For the reasons set forth in the
preamble, 45 CFR subtitle A, subchapter
D, part 170, is proposed to be amended
as follows:
PART 170—HEALTH INFORMATION
TECHNOLOGY STANDARDS,
IMPLEMENTATION SPECIFICATIONS,
AND CERTIFICATION CRITERIA AND
CERTIFICATION PROGRAMS FOR
HEALTH INFORMATION
TECHNOLOGY
1. The authority citation for part 170
continues to read as follows:
■
Authority: 42 U.S.C. 300jj–11; 42 U.S.C.
300jj–14; 5 U.S.C. 552.
2. Amend § 170.501 by revising
paragraph (a) to read as follows:
■
mstockstill on DSK4VPTVN1PROD with PROPOSALS3
§ 170.501
Applicability.
(a) This subpart establishes the
processes that applicants for ONC–ACB
status must follow to be granted ONC–
ACB status by the National Coordinator;
the processes the National Coordinator
will follow when assessing applicants
and granting ONC–ACB status; the
requirements that ONC–ACBs must
follow to maintain ONC–ACB status;
and the requirements of ONC–ACBs for
certifying Complete EHRs, Health IT
Module(s), and other types of health IT
in accordance with the applicable
certification criteria adopted by the
Secretary in subpart C of this part. It
also establishes the processes that
applicants for ONC–ATL status must
follow to be granted ONC–ATL status by
the National Coordinator; the processes
the National Coordinator will follow
when assessing applicants and granting
ONC–ATL status; the requirements that
ONC–ATLs must follow to maintain
ONC–ATL status; and the requirements
of ONC–ATLs for testing Complete
EHRs and Health IT Modules in
accordance with the applicable
certification criteria adopted by the
Secretary in subpart C of this part.
Further, this subpart establishes the
processes accreditation organizations
must follow to request approval from
the National Coordinator and that the
National Coordinator in turn will follow
to approve an accreditation organization
under the ONC Health IT Certification
VerDate Sep<11>2014
19:43 Mar 01, 2016
Jkt 238001
Program as well as certain ongoing
responsibilities for an ONC–AA.
*
*
*
*
*
■ 3. Amend § 170.502 by revising the
definitions of ‘‘Applicant’’ and ‘‘Gap
certification’’ and by adding the
definition of ‘‘ONC-Authorized Testing
Lab or ONC–ATL’’ in alphabetical order
to read as follows:
§ 170.502
Definitions.
*
*
*
*
*
Applicant means a single organization
or a consortium of organizations that
seeks to become an ONC–ACB or ONC–
ATL by submitting an application to the
National Coordinator for such status.
*
*
*
*
*
Gap certification means the
certification of a previously certified
Complete EHR or Health IT Module(s)
to:
(1) All applicable new and/or revised
certification criteria adopted by the
Secretary at subpart C of this part based
on test results issued by a NVLAPaccredited testing laboratory under the
ONC Health IT Certification Program or
an ONC–ATL; and
(2) All other applicable certification
criteria adopted by the Secretary at
subpart C of this part based on the test
results used to previously certify the
Complete EHR or Health IT Module(s)
under the ONC Health IT Certification
Program.
*
*
*
*
*
ONC-Authorized Testing Lab or ONC–
ATL means an organization or a
consortium of organizations that has
applied to and been authorized by the
National Coordinator pursuant to this
subpart to perform the testing of
Complete EHRs and Health IT Modules
to certification criteria adopted by the
Secretary at subpart C of this part.
*
*
*
*
*
4. Revise § 170.505 to read as follows:
§ 170.505
Correspondence.
(a) Correspondence and
communication with ONC or the
National Coordinator shall be conducted
by email, unless otherwise necessary or
specified. The official date of receipt of
any email between ONC or the National
Coordinator and an accreditation
organization requesting ONC–AA status,
the ONC–AA, an applicant for ONC–
ACB status, an applicant for ONC–ATL
status, an ONC–ACB, an ONC–ATL,
health IT developer, or a party to any
proceeding under this subpart is the
date on which the email was sent.
(b) In circumstances where it is
necessary for an accreditation
organization requesting ONC–AA status,
the ONC–AA, an applicant for ONC–
PO 00000
Frm 00025
Fmt 4701
Sfmt 4702
11079
ACB status, an applicant for ONC–ATL
status, an ONC–ACB, an ONC–ATL,
health IT developer, or a party to any
proceeding under this subpart to
correspond or communicate with ONC
or the National Coordinator by regular
or express mail, the official date of
receipt will be the date of the delivery
confirmation.
■ 5. Amend § 170.510 by revising the
section heading and introductory text to
read as follows:
§ 170.510 Authorization scope for ONC–
ACB status.
Applicants for ONC–ACB status may
seek authorization from the National
Coordinator to perform the following
types of certification:
*
*
*
*
*
■ 6. Add § 170.511 to read as follows:
§ 170.511 Authorization scope for ONC–
ATL status.
Applicants may seek authorization
from the National Coordinator to
perform the testing of Complete EHRs or
Health IT Modules to a portion of a
certification criterion, one certification
criterion, or many or all certification
criteria adopted by the Secretary under
subpart C of this part.
■ 7. Revise § 170.520 to read as follows:
§ 170.520
Application.
(a) ONC–ACB application. Applicants
must include the following information
in an application for ONC–ACB status
and submit it to the National
Coordinator for the application to be
considered complete.
(1) The type of authorization sought
pursuant to § 170.510. For authorization
to perform Health IT Module
certification, applicants must indicate
the specific type(s) of Health IT
Module(s) they seek authorization to
certify. If qualified, applicants will only
be granted authorization to certify the
type(s) of Health IT Module(s) for which
they seek authorization.
(2) General identifying, information
including:
(i) Name, address, city, state, zip code,
and Web site of applicant; and
(ii) Designation of an authorized
representative, including name, title,
phone number, and email address of the
person who will serve as the applicant’s
point of contact.
(3) Documentation that confirms that
the applicant has been accredited by the
ONC–AA.
(4) An agreement, properly executed
by the applicant’s authorized
representative, that it will adhere to the
Principles of Proper Conduct for ONC–
ACBs.
(b) ONC–ATL application. Applicants
must include the following information
E:\FR\FM\02MRP3.SGM
02MRP3
11080
Federal Register / Vol. 81, No. 41 / Wednesday, March 2, 2016 / Proposed Rules
in an application for ONC–ATL status
and submit it to the National
Coordinator for the application to be
considered complete.
(1) The authorization scope sought
pursuant to § 170.511.
(2) General identifying, information
including:
(i) Name, address, city, state, zip code,
and Web site of applicant; and
(ii) Designation of an authorized
representative, including name, title,
phone number, and email address of the
person who will serve as the applicant’s
point of contact.
(3) Documentation that confirms that
the applicant has been accredited by
NVLAP to ISO 17025.
(4) An agreement, properly executed
by the applicant’s authorized
representative, that it will adhere to the
Principles of Proper Conduct for ONC–
ATLs.
■ 8. Amend § 170.523 by revising
paragraphs (h) and (i) and adding
paragraph (o) to read as follows:
§ 170.523 Principles of proper conduct for
ONC–ACBs.
mstockstill on DSK4VPTVN1PROD with PROPOSALS3
*
*
*
*
*
(h) Only certify health IT (Complete
EHRs and/or Health IT Modules) that
has been tested, using test tools and test
procedures approved by the National
Coordinator, by a/an:
(1) ONC–ATL;
(2) NVLAP-accredited testing
laboratory under the ONC Health IT
Certification Program for no longer than
six months from the authorization of the
first ONC–ATL unless:
(i) Certifying previously certified
Complete EHRs and/or Health IT
Module(s) if the certification criterion or
criteria to which the Complete EHRs
and/or Health IT Module(s) was
previously certified have not been
revised and no new certification criteria
are applicable to the Complete EHRs
and/or Health IT Module(s); or
(ii) Performing gap certification.
(i) Conduct surveillance as follows:
(1) Submit an annual surveillance
plan to the National Coordinator.
(2) Report, at a minimum, on a
quarterly basis to the National
Coordinator the results of its
surveillance.
(3) Publicly publish identifiable
surveillance results on its Web site on
a quarterly basis.
(4) Annually submit a summative
report of surveillance results.
*
*
*
*
*
(o) Be prohibited from reducing the
scope of a certification when the health
IT is under surveillance or under a
corrective action plan.
■ 9. Add § 170.524 to read as follows:
VerDate Sep<11>2014
19:43 Mar 01, 2016
Jkt 238001
§ 170.524 Principles of proper conduct for
ONC–ATLs.
An ONC–ATL shall:
(a) Maintain its NVLAP accreditation
to ISO 17025;
(b) Attend all mandatory ONC
training and program update sessions;
(c) Maintain a training program that
includes documented procedures and
training requirements to ensure its
personnel are competent to test health
IT;
(d) Report to ONC within 15 days any
changes that materially affect its:
(1) Legal, commercial, organizational,
or ownership status;
(2) Organization and management
including key testing personnel;
(3) Policies or procedures;
(4) Location;
(5) Personnel, facilities, working
environment or other resources;
(6) ONC authorized representative
(point of contact); or
(7) Other such matters that may
otherwise materially affect its ability to
test health IT.
(e) Allow ONC, or its authorized
agent(s), to periodically observe on site
(unannounced or scheduled), during
normal business hours, any testing
performed pursuant to the ONC Health
IT Certification Program;
(f) Records retention. (1) Retain all
records related to the testing of
Complete EHRs and/or Health IT
Modules to an edition of certification
criteria for a minimum of 3 years from
the effective date that removes the
applicable edition from the Code of
Federal Regulations; and
(2) Make the records available to HHS
upon request during the retention
period described in paragraph (f)(1) of
this section;
(g) Only test health IT using test tools
and test procedures approved by the
National Coordinator; and
(h) Promptly refund any and all fees
received for:
(1) Requests for testing that are
withdrawn while its operations are
suspended by the National Coordinator;
(2) Testing that will not be completed
as a result of its conduct; and
(3) Previous testing that it performed
if its conduct necessitates the retesting
of Complete EHRs and/or Health IT
Modules.
■ 10. Revise § 170.525 to read as
follows:
§ 170.525
Application submission.
(a) An applicant for ONC–ACB or
ONC–ATL status must submit its
application either electronically via
email (or Web site submission if
available), or by regular or express mail.
PO 00000
Frm 00026
Fmt 4701
Sfmt 4702
(b) An application for ONC–ACB or
ONC–ATL status may be submitted to
the National Coordinator at any time.
■ 11. Amend § 170.530 by revising
paragraphs (c)(2), (4), (d)(2) and (3) to
read as follows:
§ 170.530
Review of application.
*
*
*
*
*
(c) * * *
(2) In order for an applicant to
continue to be considered for ONC–ACB
or ONC–ATL status, the applicant’s
revised application must address the
specified deficiencies and be received
by the National Coordinator within 15
days of the applicant’s receipt of the
deficiency notice, unless the National
Coordinator grants an applicant’s
request for an extension of the 15-day
period based on a finding of good cause.
If a good cause extension is granted,
then the revised application must be
received by the end of the extension
period.
*
*
*
*
*
(4) If the National Coordinator
determines that a revised application
still contains deficiencies, the applicant
will be issued a denial notice indicating
that the applicant cannot reapply for
ONC–ACB or ONC–ATL status for a
period of six months from the date of
the denial notice. An applicant may
request reconsideration of this decision
in accordance with § 170.535.
(d) * * *
(2) The National Coordinator will
notify the applicant’s authorized
representative of its satisfactory
application and its successful
achievement of ONC–ACB or ONC–ATL
status.
(3) Once notified by the National
Coordinator of its successful
achievement of ONC–ACB or ONC–ATL
status, the applicant may represent itself
as an ONC–ACB or ONC–ATL (as
applicable) and begin certifying or
testing (as applicable) health
information technology consistent with
its authorization.
■ 12. Amend § 170.535 by revising the
section heading and paragraphs (a) and
(d)(1) to read as follows:
§ 170.535 ONC–ACB and ONC–ATL
application reconsideration.
(a) Basis for reconsideration request.
An applicant may request that the
National Coordinator reconsider a
denial notice only if the applicant can
demonstrate that clear, factual errors
were made in the review of its
application and that the errors’
correction could lead to the applicant
obtaining ONC–ACB or ONC–ATL
status.
*
*
*
*
*
E:\FR\FM\02MRP3.SGM
02MRP3
Federal Register / Vol. 81, No. 41 / Wednesday, March 2, 2016 / Proposed Rules
(d) * * *
(1) If the National Coordinator
determines that clear, factual errors
were made during the review of the
application and that correction of the
errors would remove all identified
deficiencies, the applicant’s authorized
representative will be notified of the
National Coordinator’s determination
and the applicant’s successful
achievement of ONC–ACB or ONC–ATL
status.
*
*
*
*
*
■ 13. Revise § 170.540 to read as
follows:
§ 170.540
ONC–ACB and ONC–ATL status.
(a) Acknowledgement and
publication. The National Coordinator
will acknowledge and make publicly
available the names of ONC–ACBs and
ONC–ATLs, including the date each was
authorized and the type(s) of
certification or scope of testing,
respectively, each has been authorized
to perform.
(b) Representation. Each ONC–ACB or
ONC–ATL must prominently and
unambiguously identify the scope of its
authorization on its Web site and in all
marketing and communications
statements (written and oral) pertaining
to its activities under the ONC Health IT
Certification Program.
(c) Renewal. An ONC–ACB or ONC–
ATL is required to renew its status every
three years. An ONC–ACB or ONC–ATL
is required to submit a renewal request,
containing any updates to the
information requested in § 170.520, to
the National Coordinator 60 days prior
to the expiration of its status.
(d) Expiration. An ONC–ACB’s or
ONC–ATL’s status will expire three
years from the date it was granted by the
National Coordinator unless it is
renewed in accordance with paragraph
(c) of this section.
■ 14. Amend § 170.556 by revising
paragraph (e)(1) to read as follows:
§ 170.556 In-the-field surveillance and
maintenance of certification for health IT.
mstockstill on DSK4VPTVN1PROD with PROPOSALS3
*
*
*
*
*
(e) * * *
(1) Rolling submission of in-the-field
surveillance results. The results of inthe-field surveillance under this section
must be submitted to the National
Coordinator on an ongoing basis
throughout the calendar year and, at a
minimum, in accordance with
§ 170.523(i)(2).
*
*
*
*
*
■ 15. Revise § 170.557 to read as
follows:
VerDate Sep<11>2014
19:43 Mar 01, 2016
Jkt 238001
§ 170.557 Authorized testing and
certification methods.
(a) ONC–ATL applicability. An ONC–
ATL must provide remote testing for
both development and deployment
sites.
(b) ONC–ACB applicability. An ONC–
ACB must provide remote certification
for both development and deployment
sites.
■ 16. Revise § 170.560 to read as
follows:
§ 170.560 Good standing as an ONC–ACB
or ONC–ATL.
(a) ONC–ACB good standing. An
ONC–ACB must maintain good standing
by:
(1) Adhering to the Principles of
Proper Conduct for ONC–ACBs;
(2) Refraining from engaging in other
types of inappropriate behavior,
including an ONC–ACB misrepresenting
the scope of its authorization, as well as
an ONC–ACB certifying Complete EHRs
and/or Health IT Module(s) for which it
does not have authorization; and
(3) Following all other applicable
federal and state laws.
(b) ONC–ATL good standing. An
ONC–ATL must maintain good standing
by:
(1) Adhering to the Principles of
Proper Conduct for ONC–ATLs;
(2) Refraining from engaging in other
types of inappropriate behavior,
including an ONC–ATL misrepresenting
the scope of its authorization, as well as
an ONC–ATL testing health IT for
which it does not have authorization;
and
(3) Following all other applicable
federal and state laws.
■ 17. Revise § 170.565 to read as
follows:
§ 170.565 Revocation of ONC–ACB or
ONC–ATL status.
(a) Type-1 violations. The National
Coordinator may revoke an ONC–ATL
or ONC–ACB’s status for committing a
Type-1 violation. Type-1 violations
include violations of law or ONC Health
IT Certification Program policies that
threaten or significantly undermine the
integrity of the ONC Health IT
Certification Program. These violations
include, but are not limited to: False,
fraudulent, or abusive activities that
affect the ONC Health IT Certification
Program, a program administered by
HHS or any program administered by
the federal government.
(b) Type-2 violations. The National
Coordinator may revoke an ONC–ATL
or ONC–ACB’s status for failing to
timely or adequately correct a Type-2
violation. Type-2 violations constitute
noncompliance with § 170.560.
PO 00000
Frm 00027
Fmt 4701
Sfmt 4702
11081
(1) Noncompliance notification. If the
National Coordinator obtains reliable
evidence that an ONC–ATL or ONC–
ACB may no longer be in compliance
with § 170.560, the National
Coordinator will issue a noncompliance
notification with reasons for the
notification to the ONC–ATL or ONC–
ACB requesting that the ONC–ATL or
ONC–ACB respond to the alleged
violation and correct the violation, if
applicable.
(2) Opportunity to become compliant.
After receipt of a noncompliance
notification, an ONC–ATL or ONC–ACB
is permitted up to 30 days to submit a
written response and accompanying
documentation that demonstrates that
no violation occurred or that the alleged
violation has been corrected.
(i) If the ONC–ATL or ONC–ACB
submits a response, the National
Coordinator is permitted up to 30 days
from the time the response is received
to evaluate the response and reach a
decision. The National Coordinator
may, if necessary, request additional
information from the ONC–ATL or
ONC–ACB during this time period.
(ii) If the National Coordinator
determines that no violation occurred or
that the violation has been sufficiently
corrected, the National Coordinator will
issue a memo to the ONC–ATL or ONC–
ACB confirming this determination.
(iii) If the National Coordinator
determines that the ONC–ATL or ONC–
ACB failed to demonstrate that no
violation occurred or to correct the
area(s) of non-compliance identified
under paragraph (b)(1) of this section
within 30 days of receipt of the
noncompliance notification, then the
National Coordinator may propose to
revoke the ONC–ATL or ONC–ACB’s
status.
(c) Proposed revocation. (1) The
National Coordinator may propose to
revoke an ONC–ATL or ONC–ACB’s
status if the National Coordinator has
reliable evidence that the ONC–ATL or
ONC–ACB has committed a Type-1
violation; or
(2) The National Coordinator may
propose to revoke an ONC–ATL or
ONC–ACB’s status if, after the ONC–
ATL or ONC–ACB has been notified of
a Type-2 violation, the ONC–ATL or
ONC–ACB fails to:
(i) Rebut the finding of a violation
with sufficient evidence showing that
the violation did not occur or that the
violation has been corrected; or
(ii) Submit to the National
Coordinator a written response to the
noncompliance notification within the
specified timeframe under paragraph
(b)(2) of this section.
E:\FR\FM\02MRP3.SGM
02MRP3
mstockstill on DSK4VPTVN1PROD with PROPOSALS3
11082
Federal Register / Vol. 81, No. 41 / Wednesday, March 2, 2016 / Proposed Rules
(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
VerDate Sep<11>2014
19:43 Mar 01, 2016
Jkt 238001
in writing why its status should not be
revoked.
(2) Upon receipt of an ONC–ATL or
ONC–ACB’s response to a proposed
revocation notice, the National
Coordinator is permitted up to 30 days
to review the information submitted by
the ONC–ACB and reach a decision.
(f) Good standing determination. If
the National Coordinator determines
that an ONC–ATL or ONC–ACB’s status
should not be revoked, the National
Coordinator will notify the ONC–ATL or
ONC–ACB’s authorized representative
in writing of this determination.
(g) Revocation. (1) The National
Coordinator may revoke an ONC–ATL
or ONC–ACB’s status if:
(i) A determination is made that
revocation is appropriate after
considering the information provided by
the ONC–ATL or ONC–ACB in response
to the proposed revocation notice; or
(ii) The ONC–ATL or ONC–ACB does
not respond to a proposed revocation
notice within the specified timeframe in
paragraph (e)(1) of this section.
(2) A decision to revoke an ONC–ATL
or ONC–ACB’s status is final and not
subject to further review unless the
National Coordinator chooses to
reconsider the revocation.
(h) Extent and duration of revocation.
(1) The revocation of an ONC–ATL or
ONC–ACB is effective as soon as the
ONC–ATL or ONC–ACB receives the
revocation notice.
(2) ONC–ACB provisions. (i) A
certification body that has had its ONC–
ACB status revoked is prohibited from
accepting new requests for certification
and must cease its current certification
operations under the ONC Health IT
Certification Program.
(ii) A certification body that has had
its ONC–ACB status revoked for a Type1 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.
PO 00000
Frm 00028
Fmt 4701
Sfmt 4702
(ii) A testing lab that has had its
ONC–ATL status revoked for a Type-1
violation is not permitted to reapply for
ONC–ATL status under the ONC Health
IT Certification Program for a period of
1 year.
(iii) The failure of a testing lab that
has had its ONC–ATL status revoked to
promptly refund any and all fees for
testing of health IT not completed will
be considered a violation of the
Principles of Proper Conduct for ONC–
ATLs and will be taken into account by
the National Coordinator if the testing
lab reapplies for ONC–ATL status under
the ONC Health IT Certification
Program.
■ 18. Add § 170.580 to read as follows:
§ 170.580
ONC review of certified health IT.
(a) Direct review. ONC may directly
review certified health IT whenever
there is reason to believe that the
certified health IT may not comply with
requirements of the ONC Health IT
Certification Program.
(1) In determining whether to exercise
such review, ONC shall consider:
(i) The potential nature, severity, and
extent of the suspected nonconformity(ies), including the
likelihood of systemic or widespread
issues and impact.
(ii) The potential risk to public health
or safety or other exigent circumstances.
(iii) The need for an immediate and
coordinated governmental response.
(iv) Whether investigating, evaluating,
or addressing the suspected nonconformity would:
(A) Require access to confidential or
other information that is unavailable to
an ONC–ACB;
(B) Present issues outside the scope of
an ONC–ACB’s accreditation;
(C) Exceed the resources or capacity
of an ONC–ACB;
(D) Involve novel or complex
interpretations or application of
certification criteria or other
requirements.
(v) The potential for inconsistent
application of certification requirements
in the absence of direct review.
(2) Relationship to ONC–ACB’s
oversight. (i) ONC’s review of certified
health IT is independent of, and may be
in addition to, any review conducted by
an ONC–ACB.
(ii) ONC may assert exclusive review
of certified health IT as to any matters
under review by ONC and any other
matters so intrinsically linked that
divergent determinations between ONC
and an ONC–ACB would be
inconsistent with the effective
administration or oversight of the ONC
Health IT Certification Program.
(iii) ONC’s determination on matters
under its review is controlling and
E:\FR\FM\02MRP3.SGM
02MRP3
mstockstill on DSK4VPTVN1PROD with PROPOSALS3
Federal Register / Vol. 81, No. 41 / Wednesday, March 2, 2016 / Proposed Rules
supersedes any determination by an
ONC–ACB on the same matters.
(iv) An ONC–ACB shall provide ONC
with any available information that
ONC deems relevant to its review of
certified health IT.
(v) ONC may end all or any part of its
review of certified health IT under this
section and refer the applicable part of
the review to the relevant ONC–ACB(s)
if ONC determines that doing so would
be in the best interests of efficiency or
the administration and oversight of the
Program.
(b) Notice of potential non-conformity
or non-conformity—(1) General. ONC
will send a notice of potential nonconformity or notice of non-conformity
to the health IT developer if it has
information that certified health IT is
not or may not be performing
consistently with Program requirements.
(i) Potential non-conformity. ONC
may require that the health IT developer
respond in more or less time than 30
days based on factors such as, but not
limited to:
(A) The type of certified health IT and
certification in question;
(B) The type of potential nonconformity to be corrected;
(C) The time required to correct the
potential non-conformity; and
(D) Issues of public health or safety or
other exigent circumstances.
(ii) Non-conformity. ONC may require
that the health IT developer respond
and submit a proposed corrective action
plan in more or less time than 30 days
based on factors such as, but not limited
to:
(A) The type of certified health IT and
certification in question;
(B) The type of non-conformity to be
corrected;
(C) The time required to correct the
non-conformity; and
(D) Issues of public health or safety or
other exigent circumstances.
(2) Records access. In response to a
notice of potential non-conformity or
notice of non-conformity, a health IT
developer shall make available to ONC
and for sharing within HHS, with other
federal agencies, and with appropriate
entities:
(i) All records related to the
development, testing, certification,
implementation, maintenance and use
of its certified health IT; and
(ii) Any complaint records related to
the certified health IT.
(3) Health IT developer response. The
health IT developer must include in its
response all appropriate documentation
and explain in writing why the certified
health IT is conformant.
(c) Corrective action plan and
procedures. (1) If ONC determines that
VerDate Sep<11>2014
19:43 Mar 01, 2016
Jkt 238001
certified health IT does not conform to
Program requirements, ONC shall notify
the health IT developer of the certified
health IT of its findings and require the
health IT developer to submit a
proposed corrective action plan.
(2) ONC shall provide direction to the
health IT developer as to the required
elements of the corrective action plan.
ONC shall prescribe such corrective
action as may be appropriate to fully
address the identified nonconformity(ies). The corrective action
plan is required to include, at a
minimum, for each non-conformity:
(i) A description of the identified nonconformity;
(ii) An assessment of the nature,
severity, and extent of the nonconformity, including how widespread
they may be across all of the health IT
developer’s customers of the certified
health IT;
(iii) How the health IT developer will
address the identified non-conformity,
both at the locations where the nonconformity was identified and for all
other potentially affected customers;
(iv) A detailed description of how the
health IT developer will assess the
scope and impact of the non-conformity,
including:
(A) Identifying all potentially affected
customers;
(B) How the health IT developer will
promptly ensure that all potentially
affected customers are notified of the
non-conformity and plan for resolution;
(C) How and when the health IT
developer will resolve issues for
individual affected customers; and
(D) How the health IT developer will
ensure that all issues are in fact
resolved; and
(v) The timeframe under which
corrective action will be completed.
(3) When ONC receives a proposed
corrective action plan (or a revised
proposed corrective action plan), it shall
either approve the proposed corrective
action plan or, if the plan does not
adequately address all required
elements, instruct the developer to
submit a revised proposed corrective
action plan.
(4) Upon fulfilling all of its
obligations under the corrective action
plan, the health IT developer must
submit an attestation to ONC, which
serves as a binding official statement by
the health IT developer that it has
fulfilled all of its obligations under the
corrective action plan.
(5) ONC may reinstitute a corrective
action plan if it later determines that a
health IT developer has not fulfilled all
of its obligations under the corrective
action plan as attested in accordance
with paragraph (c)(4) of this section.
PO 00000
Frm 00029
Fmt 4701
Sfmt 4702
11083
(d) Suspension. (1) ONC may suspend
the certification of a Complete EHR or
Health IT Module at any time for any
one of the following reasons:
(i) Based on information it has
obtained, ONC believes that the certified
health IT poses a potential risk to public
health or safety or other exigent
circumstances exist. More specifically,
ONC would suspend a certification
issued to any encompassed Complete
EHR or Health IT Module of the
certified health IT if the certified health
IT was, but not limited to: Contributing
to a patient’s health information being
unsecured and unprotected in violation
of applicable law; increasing medical
errors; decreasing the detection,
prevention, and management of chronic
diseases; worsening the identification
and response to public health threats
and emergencies; leading to
inappropriate care; worsening health
care outcomes; or undermining a more
effective marketplace, greater
competition, greater systems analysis,
and increased consumer choice;
(ii) The health IT developer fails to
timely respond to any communication
from ONC, including, but not limited to:
(A) Fact-finding;
(B) A notice of potential nonconformity within the timeframe
established in accordance with
paragraph (b)(1)(i) of this section; or
(C) A notice of non-conformity within
the timeframe established in accordance
with paragraph (b)(1)(ii) of this section;
(iii) The information provided by the
health IT developer in response to any
ONC communication, including, but not
limited to: Fact-finding, a notice of
potential non-conformity, or a notice of
non-conformity is insufficient or
incomplete;
(iv) The health IT developer fails to
timely submit a proposed corrective
action plan that adequately addresses
the elements required by ONC as
described in paragraph (c) of this
section;
(v) The health IT developer does not
fulfill its obligations under the
corrective action plan developed in
accordance with paragraph (c) of this
section.
(2) When ONC decides to suspend a
certification, ONC will notify the health
IT developer of its determination
through a notice of suspension.
(i) The notice of suspension will
include, but may not be limited to:
(A) An explanation for the
suspension;
(B) The information ONC relied upon
to reach its determination;
(C) The consequences of suspension
for the health IT developer and the
Complete EHR or Health IT Module
E:\FR\FM\02MRP3.SGM
02MRP3
mstockstill on DSK4VPTVN1PROD with PROPOSALS3
11084
Federal Register / Vol. 81, No. 41 / Wednesday, March 2, 2016 / Proposed Rules
under the ONC Health IT Certification
Program; and
(D) Instructions for appealing the
suspension.
(ii) A suspension of a certification
will become effective upon the health IT
developer’s receipt of a notice of
suspension.
(3) The health IT developer must
notify all affected and potentially
affected customers of the identified nonconformity(ies) and suspension of
certification in a timely manner.
(4) If a certification is suspended, the
health IT developer must cease and
desist from any marketing and sale of
the suspended Complete EHR or Health
IT Module as ‘‘certified’’ under the ONC
Health IT Certification Program from
that point forward until such time ONC
may rescind the suspension.
(5) Inherited certified status
certification for a suspended Complete
EHR or Health IT Module is not
permitted until such time ONC rescinds
the suspension.
(6) ONC will rescind a suspension of
certification if the health IT developer
completes all elements of an approved
corrective action plan and/or ONC
confirms that all non-conformities have
been corrected.
(e) Termination. (1) ONC may
terminate a certification issued to a
Complete EHR and/or Health IT Module
if:
(i) The health IT developer fails to
timely respond to any communication
from ONC, including, but not limited to:
(A) Fact-finding;
(B) A notice of potential nonconformity within the timeframe
established in accordance with
paragraph (b)(1)(i) of this section; or
(C) A notice of non-conformity within
the timeframe established in accordance
with paragraph (b)(1)(ii) of this section;
(ii) The information provided by the
health IT developer in response to any
ONC communication, including, but not
limited to: Fact-finding, a notice of
potential non-conformity, or a notice of
non-conformity is insufficient or
incomplete;
(iii) The health IT developer fails to
timely submit a proposed corrective
action plan that adequately addresses
the elements required by ONC as
described in paragraph (c) of this
section;
(iv) The health IT developer does not
fulfill its obligations under the
corrective action plan developed in
accordance with paragraph (c) of this
section; or
(v) ONC concludes that a certified
health IT’s non-conformity(ies) cannot
be cured.
(2) When ONC decides to terminate a
certification, ONC will notify the health
VerDate Sep<11>2014
19:43 Mar 01, 2016
Jkt 238001
IT developer of its determination
through a notice of termination.
(i) The notice of termination will
include, but may not be limited to:
(A) An explanation for the
termination;
(B) The information ONC relied upon
to reach its determination;
(C) The consequences of termination
for the health IT developer and the
Complete EHR or Health IT Module
under the ONC Health IT Certification
Program; and
(D) Instructions for appealing the
termination.
(ii) A termination of a certification
will become effective either upon:
(A) The expiration of the 10-day
period for filing an appeal in paragraph
(f)(3) of this section if an appeal is not
filed by the health IT developer; or
(B) A final determination to terminate
the certification per paragraph (f)(7) of
this section if a health IT developer files
an appeal.
(3) The health IT developer must
notify affected and potentially affected
customers of the identified nonconformity(ies) and termination of
certification in a timely manner.
(4) If ONC determines that a Complete
EHR or Health IT Module certification
should not be terminated, ONC will
notify the health IT developer in writing
of this determination.
(f) Appeal —(1) Basis for appeal. A
health IT developer may appeal an ONC
determination to suspend or terminate a
certification issued to a Complete EHR
or Health IT Module if the health IT
developer asserts:
(i) ONC incorrectly applied Program
methodology, standards, or
requirements for suspension or
termination; or
(ii) ONC’s determination was not
sufficiently supported by the
information used by ONC to reach the
determination.
(2) Method and place for filing an
appeal. A request for appeal must be
submitted to ONC in writing by an
authorized representative of the health
IT developer whose Complete EHR or
Health IT Module was subject to the
determination being appealed. The
request for appeal must be filed in
accordance with the requirements
specified in the notice of termination or
notice of suspension.
(3) Time for filing a request for
appeal. An appeal must be filed within
10 calendar days of receipt of the notice
of suspension or notice of termination.
(4) Effect of appeal on suspension and
termination. (i) A request for appeal
stays the termination of a certification
issued to a Complete EHR or Health IT
Module, but the Complete EHR or
PO 00000
Frm 00030
Fmt 4701
Sfmt 4702
Health IT Module is prohibited from
being marketed or sold as ‘‘certified’’
during the stay.
(ii) A request for appeal does not stay
the suspension of a Complete EHR or
Health IT Module.
(5) Appointment of a hearing officer.
The National Coordinator will assign
the case to a hearing officer to
adjudicate the appeal on his or her
behalf. The hearing officer may not
review an appeal in which he or she
participated in the initial suspension or
termination determination or has a
conflict of interest in the pending
matter.
(6) Adjudication. (i) The hearing
officer may make a determination based
on:
(A) The written record as provided by
the health IT developer with the appeal
filed in accordance with paragraphs
(f)(1) through (3) of this section and
including any information ONC
provides in accordance with paragraph
(f)(6)(v) of this section; or
(B) All the information provided in
accordance with paragraph (f)(6)(i)(A)
and any additional information from a
hearing conducted in-person, via
telephone, or otherwise.
(ii) The hearing officer will have the
discretion to conduct a hearing if he/
she:
(A) Requires clarification by either
party regarding the written record under
paragraph (f)(6)(i)(A) of this section;
(B) Requires either party to answer
questions regarding the written record
under paragraph (f)(6)(i)(A) of this
section; or
(C) Otherwise determines a hearing is
necessary.
(iii) The hearing officer will neither
receive testimony nor accept any new
information that was not presented with
the appeal request or was specifically
and clearly relied upon to reach the
determination issued by ONC under
paragraph (d)(2) or (e)(2) of this section.
(iv) The default process will be a
determination in accordance with
paragraph (f)(6)(i)(A) of this section.
(v) ONC will have an opportunity to
provide the hearing officer with a
written statement and supporting
documentation on its behalf that
explains its determination to suspend or
terminate the certification. The written
statement and supporting
documentation must be included as part
of the written record. Failure of ONC to
submit a written statement does not
result in any adverse findings against
ONC and may not in any way be taken
into account by the hearing officer in
reaching a determination.
(7) Determination by the hearing
officer. (i) The hearing officer will issue
E:\FR\FM\02MRP3.SGM
02MRP3
Federal Register / Vol. 81, No. 41 / Wednesday, March 2, 2016 / Proposed Rules
a written determination to the health IT
developer within 30 days of receipt of
the appeal, unless the health IT
developer and ONC agree to a finite
extension approved by the hearing
officer.
(ii) The National Coordinator’s
determination on appeal, as issued by
the hearing officer, is final and not
subject to further review.
■ 19. Add § 170.581 to read as follows:
§ 170.581 Consequences due to the
termination of a certification.
mstockstill on DSK4VPTVN1PROD with PROPOSALS3
(a) Testing and recertification. A
Complete EHR or Health IT Module (or
replacement version) that has had its
certification terminated can be tested
and recertified (certified) once all nonconformities have been adequately
addressed.
(1) The recertified Complete EHR or
Health IT Module (or replacement
VerDate Sep<11>2014
19:43 Mar 01, 2016
Jkt 238001
version) must maintain a scope of
certification that, at a minimum,
includes all the previous certified
capabilities.
(2) The health IT developer must
request, and have approved, permission
to participate in the Program before
testing and recertification (certification)
may commence for the Complete EHR or
Health IT Module (or replacement
version).
(i) The request must include a written
explanation of the steps taken to address
the non-conformities that led to the
termination.
(ii) ONC must approve the request to
participate in the Program.
(b) Heightened scrutiny. Certified
health IT that was previously the subject
of a certification termination (or
replacement version) shall be subject to
heightened scrutiny for, at a minimum,
one year.
PO 00000
Frm 00031
Fmt 4701
Sfmt 9990
11085
(c) Program ban. The testing and
certification of any health IT of a health
IT developer that has the certification of
one of its Complete EHRs or Health IT
Modules terminated under the Program
or withdrawn from the Program when
the subject of a potential nonconformity
or non-conformity is prohibited, unless:
(1) The non-conformity is corrected
and implemented for all affected
customers; or
(2) The certification and
implementation of other health IT by
the health IT developer would remedy
the non-conformity for all affected
customers.
Sylvia M. Burwell,
Secretary.
[FR Doc. 2016–04531 Filed 3–1–16; 8:45 am]
BILLING CODE 4150–45–P
E:\FR\FM\02MRP3.SGM
02MRP3
Agencies
[Federal Register Volume 81, Number 41 (Wednesday, March 2, 2016)]
[Proposed Rules]
[Pages 11055-11085]
From the Federal Register Online via the Government Publishing Office [www.gpo.gov]
[FR Doc No: 2016-04531]
[[Page 11055]]
Vol. 81
Wednesday,
No. 41
March 2, 2016
Part IV
Department of Health and Human Services
-----------------------------------------------------------------------
45 CFR Part 170
Medicare Program; FY 2015 Hospice Wage Index and Payment Rate Update;
Hospice Quality Reporting Requirements and Process and Appeals for Part
D Payment for Drugs for Beneficiaries Enrolled in Hospice; Proposed
Rule
Federal Register / Vol. 81 , No. 41 / Wednesday, March 2, 2016 /
Proposed Rules
[[Page 11056]]
-----------------------------------------------------------------------
DEPARTMENT OF HEALTH AND HUMAN SERVICES
Office of the Secretary
45 CFR Part 170
RIN 0955-AA00
ONC Health IT Certification Program: Enhanced Oversight and
Accountability
AGENCY: Office of the National Coordinator for Health Information
Technology, Department of Health and Human Services.
ACTION: Notice of proposed rulemaking.
-----------------------------------------------------------------------
SUMMARY: This notice of proposed rulemaking (``proposed rule'')
introduces modifications and new requirements under the ONC Health IT
Certification Program (``Program''), including provisions related to
the Office of the National Coordinator for Health Information
Technology (ONC)'s role in the Program. The proposed rule proposes to
establish processes for ONC to directly review health IT certified
under the Program and take action when necessary, including requiring
the correction of non-conformities found in health IT certified under
the Program and suspending and terminating certifications issued to
Complete EHRs and Health IT Modules. The proposed rule includes
processes for ONC to authorize and oversee accredited testing
laboratories under the Program. It also includes a provision for the
increased transparency and availability of surveillance results.
DATES: To be assured consideration, written or electronic comments must
be received at one of the addresses provided below, no later than 5
p.m. on May 2, 2016.
ADDRESSES: You may submit comments, identified by RIN 0955-AA00, by any
of the following methods (please do not submit duplicate comments).
Because of staff and resource limitations, we cannot accept comments by
facsimile (FAX) transmission.
Federal eRulemaking Portal: Follow the instructions for
submitting comments. Attachments should be in Microsoft Word, Microsoft
Excel, or Adobe PDF; however, we prefer Microsoft Word. https://www.regulations.gov.
Regular, Express, or Overnight Mail: Department of Health
and Human Services, Office of the National Coordinator for Health
Information Technology, Attention: ONC Health IT Certification Program
Proposed Rule, Mary E. Switzer Building, Mail Stop: 7033A, 330 C Street
SW., Washington, DC 20201. Please submit one original and two copies.
Hand Delivery or Courier: Office of the National
Coordinator for Health Information Technology, Attention: ONC Health IT
Certification Program Proposed Rule, Mary E. Switzer Building, Mail
Stop: 7033A, 330 C Street SW., Washington, DC 20201. Please submit one
original and two copies. (Because access to the interior of the Mary E.
Switzer Building is not readily available to persons without federal
government identification, commenters are encouraged to leave their
comments in the mail drop slots located in the main lobby of the
building.)
Enhancing the Public Comment Experience: To facilitate public
comment on this proposed rule, a copy will be made available in
Microsoft Word format on ONC's Web site (https://www.healthit.gov). We
believe this version will make it easier for commenters to access and
copy portions of the proposed rule for use in their individual
comments. Additionally, a separate document will also be made available
on ONC's Web site (https://www.healthit.gov) for the public to use in
providing comments on the proposed rule. This document is meant to
provide the public with a simple and organized way to submit comments
on proposals and respond to specific questions posed in the preamble of
the proposed rule. While use of this document is entirely voluntary, we
encourage commenters to consider using the document in lieu of
unstructured comments or to use it as an addendum to narrative cover
pages. We believe that use of the document may facilitate our review
and understanding of the comments received.
Inspection of Public Comments: All comments received before the
close of the comment period will be available for public inspection,
including any personally identifiable or confidential business
information that is included in a comment. Please do not include
anything in your comment submission that you do not wish to share with
the general public. Such information includes, but is not limited to: A
person's social security number; date of birth; driver's license
number; state identification number or foreign country equivalent;
passport number; financial account number; credit or debit card number;
any personal health information; or any business information that could
be considered proprietary. We will post all comments that are received
before the close of the comment period at https://www.regulations.gov.
Docket: For access to the docket to read background documents or
comments received, go to https://www.regulations.gov or the Department
of Health and Human Services, Office of the National Coordinator for
Health Information Technology, Mary E. Switzer Building, Mail Stop:
7033A, 330 C Street SW., Washington, DC 20201 (call ahead to the
contact listed below to arrange for inspection).
FOR FURTHER INFORMATION CONTACT: Michael Lipinski, Office of Policy,
Office of the National Coordinator for Health Information Technology,
202-690-7151.
SUPPLEMENTARY INFORMATION:
Commonly Used Acronyms
CEHRT Certified Electronic Health Record Technology
CFR Code of Federal Regulations
CHPL Certified Health IT Product List
EHR Electronic Health Record
HHS Department of Health and Human Services
HIT Health Information Technology
ISO International Organization for Standardization
NVLAP National Voluntary Laboratory Accreditation Program
OMB Office of Management and Budget
ONC Office of the National Coordinator for Health Information
Technology
ONC-ACB ONC-Authorized Certification Body
ONC-ATCB ONC-Authorized Testing and Certification Body
ONC-ATL ONC-Authorized Testing Laboratory
PoPC Principles of Proper Conduct
Table of Contents
I. Executive Summary
A. Purpose of Regulatory Action
B. Summary of Major Provisions
1. ONC Direct Review of Certified Health IT
2. ONC-Authorized Testing Laboratories
3. Transparency and Availability of Surveillance Results
C. Costs and Benefits
1. Costs
2. Benefits
II. Provisions of the Proposed Rule
A. ONC's Role Under the ONC Health IT Certification Program
1. Review of Certified Health IT
a. Authority and Scope
b. ONC-ACB's Role
c. Review Processes
(1) Notice of Potential Non-Conformity or Non-Conformity
(2) Corrective Action
(3) Suspension
(4) Termination
(5) Appeal
d. Consequences of Certification Termination
(1) Program Ban and Heightened Scrutiny
(2) ONC-ACB Response to a Non-Conformity
[[Page 11057]]
2. Establishing ONC Authorization for Testing Labs Under the
Program; Requirements for ONC-ATL Conduct; ONC Oversight and
Processes for ONC-ATLs
a. Background on Testing and Relationship of Testing Labs and
the Program
b. Proposed Amendments To Include ONC-ATLs in the Program
(1) Proposed Amendments to Sec. 170.501 Applicability
(2) Proposed Amendments to Sec. 170.502 Definitions
(3) Proposed Amendments to Sec. 170.505 Correspondence
(4) Proposed Amendment to Sec. 170.510 Type of Certification
(5) Proposed Creation of Sec. 170.511 Authorization Scope for
ONC-ATL Status
(6) Proposed Amendments to Sec. 170.520 Application
(7) Proposed Amendments to Sec. 170.523 Principles of Proper
Conduct for ONC-ACBs
(8) Proposed Creation of Sec. 170.524 Principles of Proper
Conduct for ONC-ATLs
(9) Proposed Amendments to Sec. 170.525 Application Submission
(10) Proposed Amendments to Sec. 170.530 Review of Application
(11) Proposed Amendments to Sec. 170.535 ONC-ACB Application
Reconsideration
(12) Proposed Amendments to Sec. 170.540 ONC-ACB Status
(13) Proposed Amendments to Sec. 170.557 Authorized
Certification Methods
(14) Proposed Amendments to Sec. 170.560 Good Standing as an
ONC-ACB
(15) Proposed Amendments to Sec. 170.565 Revocation of ONC-ACB
Status
(16) Request for Comment on Sec. 170.570 in the Context of an
ONC-ATL's Status Being Revoked
B. Public Availability of Identifiable Surveillance Results
III. National Technology Transfer and Advancement Act
IV. Incorporation by Reference
V. Response to Comments
VI. Collection of Information Requirements
A. ONC-AA and ONC-ACBs
B. ONC-ATLs
C. Health IT Developers
VII. Regulatory Impact Statement
A. Statement of Need
B. Alternatives Considered
C. Overall Impact
1. Executive Orders 12866 and 13563--Regulatory Planning and
Review Analysis
a. Costs
(1) Costs for Health IT Developers to Correct a Non-Conformity
Identified by ONC
(2) Costs for ONC and Health IT Developers Related to ONC Review
and Inquiry Into Certified Health IT Non-Conformities
(3) Costs to Health IT Developers and ONC Associated With the
Proposed Appeal Process Following a Suspension/Termination of a
Complete EHR's or Health IT Module's Certification
(4) Costs to Health Care Providers To Transition to Another
Certified Health IT Product When the Certification of a Complete EHR
or Health IT Module That They Currently Use Is Terminated
(5) Costs for ONC-ATLs and ONC Associated With ONC-ATL
Accreditation, Application, Renewal, and Reporting Requirements
(6) Costs for ONC-ATLs and ONC Related To Revoking ONC-ATL
Status
(7) Costs for ONC-ACBs to Publicly Post Identifiable
Surveillance Results
(8) Total Annual Cost Estimate
b. Benefits
2. Regulatory Flexibility Act
3. Executive Order 13132--Federalism
4. Unfunded Mandates Reform Act of 1995
I. Executive Summary
A. Purpose of Regulatory Action
The ONC Health IT Certification Program (``Program'') was first
established as the Temporary Certification Program in a final rule
published on June 24, 2010 (``Temporary Certification Program final
rule'' (75 FR 36158)). It was later transitioned to the Permanent
Certification Program in a final rule published on January 7, 2011
(``Permanent Certification Program final rule'' (76 FR 1262)). Since
that time, we have updated the Program and made modifications to the
Program through subsequent rules as discussed below.
In November 2011, a final rule established a process for ONC to
address instances where the ONC-Approved Accreditor (ONC-AA) may engage
in improper conduct or not perform its responsibilities under Program
(76 FR 72636). In September 2012, a final rule (``2014 Edition final
rule'' (77 FR 54163)) established an edition of certification criteria
and modified the Program to, among other things, provide clear
implementation direction to ONC-Authorized Certification Bodies (ONC-
ACBs) for certifying Health IT Modules to new certification criteria.
On September 11, 2014, a final rule provided certification flexibility
through the adoption of new certification criteria and further
improvements to the Program (``2014 Edition Release 2 final rule'' (79
FR 54430)). Most recently, on October 16, 2015, the Department of
Health and Human Services (HHS) published a final rule that identified
how health IT certification can support the establishment of an
interoperable nationwide health information infrastructure through the
certification and use of adopted new and updated vocabulary and content
standards for the structured recording and exchange of health
information (``2015 Edition final rule'' (80 FR 62602)). The 2015
Edition final rule modified the Program to make it open and accessible
to more types of health IT and health IT that supports various care and
practice settings. It also included provisions to increase the
transparency of information related to health IT certified under the
Program (referred to as ``certified health IT'' throughout this
proposed rule) made available by health IT developers through enhanced
surveillance and disclosure requirements.
With each Program modification and rule, we have been able to
address stakeholder concerns, certification ambiguities, and improve
oversight. As health IT adoption continues to increase, including for
settings and use cases beyond the Medicare and Medicaid EHR Incentive
Programs (``EHR Incentive Programs''), we propose to address in this
proposed rule new concerns identified through Program administration
and from stakeholders. As certified capabilities interact with other
capabilities in certified health IT and with other products, we seek to
ensure that concerns within the scope of the Program can be
appropriately addressed.
We delegated authority to ONC-ACBs to issues certifications for
heath IT on our behalf through the Permanent Certification Program
final rule. The scope of this authority, consistent with customary
certification programs and International Organization for
Standardization/International Electrotechnical Commission 17065:2012
(ISO 17065),\1\ is primarily limited to conformance determinations for
health IT evaluated against adopted certification criteria with minimal
determinations for health IT against other regulatory requirements
(Sec. 170.523(k) and (l)). As such, ONC-ACBs do not have the
responsibility or expertise to address matters outside the scope of
this authority. In particular, ONC-ACBs are not positioned, due to the
bounds of their authority and limited resources, to address situations
that involve non-conformities resulting from the interaction of
certified and uncertified capabilities within the certified health IT
or the interaction of a certified health IT's capabilities with other
products. In some instances, these non-conformities may pose a risk to
public health or safety, including, for example, capabilities
(certified or uncertified) of health IT directly contributing to or
causing medical errors. While ONC-ACBs play an important role in the
administration of the Program and in identifying non-conformities
within their scope of authority (e.g., non-conformities with
[[Page 11058]]
certification criteria), the Program does not currently have any other
means for reviewing and addressing other non-conformities. As explained
below, ONC proposes to expand its role in the Program to include the
ability to directly review and address non-conformities in an effort to
enhance Program oversight and the reliability and safety of certified
health IT.
---------------------------------------------------------------------------
\1\ The international standard to which ONC-ACBs are accredited.
45 CFR 170.599(b)(3).
---------------------------------------------------------------------------
The Health Information Technology for Economic and Clinical Health
(HITECH) Act amended the Public Health Service Act (PHSA) and created
``Title XXX--Health Information Technology and Quality'' (Title XXX) to
improve health care quality, safety, and efficiency through the
promotion of health IT and electronic health information exchange.
Section 3001(b) of the Public Health Service Act requires that the
National Coordinator for Health Information Technology (National
Coordinator) perform specified statutory duties (section 3001(c) of the
PHSA), including keeping or recognizing a program or programs for the
voluntary certification of health information technology (section
3001(c)(5) of the PHSA), in a manner consistent with the development of
a nationwide health information technology infrastructure that allows
for the electronic use and exchange of information and that: (1)
Ensures that each patient's health information is secure and protected,
in accordance with applicable law; (2) improves health care quality,
reduces medical errors, reduces health disparities, and advances the
delivery of patient-centered medical care; (3) reduces health care
costs resulting from inefficiency, medical errors, inappropriate care,
duplicative care, and incomplete information; (4) provides appropriate
information to help guide medical decisions at the time and place of
care; (5) ensures the inclusion of meaningful public input in such
development of such infrastructure; (6) improves the coordination of
care and information among hospitals, laboratories, physician offices,
and other entities through an effective infrastructure for the secure
and authorized exchange of health care information; (7) improves public
health activities and facilitates the early identification and rapid
response to public health threats and emergencies, including bioterror
events and infectious disease outbreaks; (8) facilitates health and
clinical research and health care quality; (9) promotes early
detection, prevention, and management of chronic diseases; (10)
promotes a more effective marketplace, greater competition, greater
systems analysis, increased consumer choice, and improved outcomes in
health care services; and (11) improves efforts to reduce health
disparities. Consistent with this statutory instruction, we propose to
expand ONC's role in the Program to encompass the ability to directly
review health IT certified under the Program and address non-
conformities found in certified health IT.
The proposed rule also proposes processes for ONC to timely and
directly address testing issues. These processes do not exist today
under the current Program structure, particularly as compared to ONC's
oversight of ONC-ACBs. In addition, the proposed rule includes a
provision for the increased transparency and availability of
identifiable surveillance results. The publication of identifiable
surveillance results would support further accountability of health IT
developers to their customers and users of certified health IT.
B. Summary of Major Provisions
1. ONC Direct Review of Certified Health IT
We propose, consistent with section 3001 of the PHSA, to expand
ONC's role in the Program to encompass the ability to directly review
health IT certified under the Program (referred to as ``certified
health IT'' throughout this proposed rule). This review would be
independent of, and may be in addition to, reviews conducted by ONC-
ACBs. ONC's direct review may include certified capabilities and non-
certified capabilities of the certified health IT in order for ONC to
meet its responsibilities under section 3001 of the PHSA. More
specifically, this review would extend beyond the continued conformance
of the certified health IT's capabilities with the specific
certification criteria, test procedures, and certification requirements
such as mandatory disclosures of limitations on use and types of costs
related to certified capabilities (see Sec. 170.523(k)(1)). It would
extend to the interaction of certified and uncertified capabilities
within the certified health IT and to the interaction of a certified
health IT's capabilities with other products. This approach would
support the National Coordinator fulfilling the statutory duties
specified in section 3001 of the PHSA as it relates to keeping a
certification program for the voluntary certification of health IT that
allows for the electronic use and exchange of information consistent
with the goals of section 3001(b).
Under our proposals outlined in this proposed rule, ONC would have
broad discretion to review certified health IT. However, we anticipate
that such review would be relatively infrequent and would focus on
situations that pose a risk to public health or safety. An effective
response to these situations would likely require the timely marshaling
and deployment of resources and specialized expertise by ONC. It may
also require coordination among federal government agencies.
Additionally, we believe there could be other exigencies, distinct from
public health and safety concerns, which for similar reasons would
warrant ONC's direct review and action. These exigencies are described
in section II.A.1 of this preamble.
We propose that ONC could initiate a direct review whenever it
becomes aware of information, whether from the general public,
interested stakeholders, ONC-ACBs, or by any other means, that
indicates that certified health IT may not conform to the requirements
of its certification or is, for example, leading to medical errors,
breaches in the security of a patient's health information, or other
outcomes that are in direct opposition to the National Coordinator's
responsibilities under section 3001 of the PHSA. The proposals in this
proposed rule would enable ONC to require corrective action for these
non-conformities and, when necessary, suspend or terminate a
certification issued to a Complete EHR or Health IT Module. We also
propose to establish a process for health IT developers to appeal
determinations by ONC to suspend or terminate certifications issued to
health IT under the Program. Further, to protect the integrity of the
Program and users of certified health IT, we propose strict processes
for the recertification of health IT (or replacement versions) that has
had its certification terminated, heightened scrutiny for such health
IT, and a Program ban for health IT of health IT developers that do not
correct non-conformities. We emphasize that enhancing ONC's role in
reviewing certified health IT would support greater accountability for
health IT developers under the Program and provide greater confidence
that health IT conforms to Program requirements when it is implemented,
maintained, and used. We further emphasize that our first and foremost
goal is to work with health IT developers to remedy any identified non-
conformities of certified health IT in a timely manner.
[[Page 11059]]
2. ONC-Authorized Testing Laboratories
We propose that ONC would conduct direct oversight of testing labs
under the Program in order to ensure that ONC oversight can be
similarly applied at all stages of the Program. Unlike the processes we
established for ONC-ACBs, we did not establish a similar and equitable
process for testing labs. Instead, we required in the Principles of
Proper Conduct (PoPC) for ONC-ACBs that ONC-ACBs only accept test
results from National Voluntary Laboratory Accreditation Program
(NVLAP)-accredited testing labs. This requirement for ONC-ACBs had the
effect of requiring testing labs to be accredited by NVLAP to
International Organization for Standardization/International
Electrotechnical Commission 17025:2005 (General requirements for the
competence of testing and calibration laboratories) (ISO 17025).
However, in so doing, there is effectively no direct ONC oversight of
NVLAP-accredited testing labs like there is for ONC-ACBs.
This proposed rule proposes means for ONC to have direct oversight
of NVLAP-accredited testing labs by having them apply to become ONC-
Authorized Testing Labs (ONC-ATLs). Specifically, this proposed rule
proposes means for authorizing, retaining, suspending, and revoking
ONC-Authorized Testing Lab (ONC-ATL) status under the Program. These
proposed processes are similar to current ONC-ACB processes. The
proposed changes would enable ONC to oversee and address testing and
certification performance issues throughout the entire continuum of the
Program in a precise and direct manner.
3. Transparency and Availability of Surveillance Results
In furtherance of our efforts to increase the transparency and
availability of information related to certified health IT, we propose
to require ONC-ACBs to make identifiable surveillance results publicly
available on their Web sites on a quarterly basis. We believe the
publication of identifiable surveillance results would enhance
transparency and the accountability of health IT developers to their
customers. The public availability of identifiable surveillance results
would provide customers and users with valuable information about the
continued performance of certified health IT as well as surveillance
efforts. While we expect that the prospect of publicly identifiable
surveillance results would motivate some health IT developers to
improve their maintenance efforts, we believe that most published
surveillance results would reassure customers and users of certified
health IT. This is because, based on ONC-ACB surveillance results to
date, most certified health IT and health IT developers are maintaining
conformance with certification criteria and Program requirements. The
publishing of such ``positive'' surveillance results would also provide
a more complete context of surveillance; rather than only sharing
``negatives,'' such as non-conformities and corrective action plans.
C. Costs and Benefits
Executive Orders 12866 and 13563 direct agencies to assess all
costs and benefits of available regulatory alternatives and, if
regulation is necessary, to select regulatory approaches that maximize
net benefits (including potential economic, environmental, public
health and safety effects, distributive impacts, and equity). A
regulatory impact analysis (RIA) must be prepared for major rules with
economically significant effects ($100 million or more in any one
year). OMB has determined that this proposed rule is an economically
significant rule as the potential costs associated with this proposed
rule could be greater than $100 million per year. Accordingly, we have
prepared an RIA that to the best of our ability presents the costs and
benefits of the proposed rule.
1. Costs
We estimated the potential monetary costs of this proposed rule for
health IT developers, ONC-ATLs, the Federal government (i.e., ONC), and
health care providers as follows: (1) Costs for health IT developers to
correct non-conformities identified by ONC; (2) costs for ONC and
health IT developers related to ONC review and inquiry into certified
health IT non-conformities; (3) costs to health IT developers and ONC
associated with the proposed appeal process following a suspension/
termination of a Complete EHR's or Health IT Module's certification;
(4) costs to health care providers to transition to another certified
health IT product when the certification of a Complete EHR or Health IT
Module that they currently use is terminated; (5) costs for ONC-ATLs
and ONC associated with ONC-ATL accreditation, application, renewal,
and reporting requirements; (6) costs for ONC-ATLs and ONC related to
revoking ONC-ATL status; and (7) costs for ONC-ACBs to publicly post
identifiable surveillance results. We also provide an overall annual
monetary cost estimate for this proposed rule. We note that we have
rounded all estimates to the nearest dollar and all estimates are
expressed in 2016 dollars.
We have been unable to estimate the costs for health IT developers
to correct non-conformities identified through ONC's direct review of
certified health IT because the costs incurred by health IT developers
to bring their certified health IT into conformance would be determined
on a case-by-case basis. We do, however, identify factors that would
inform cost estimates and request comment on existing relevant data and
methods we could use to estimate these costs in section VII.C.1.a of
this preamble.
We estimated the costs for ONC and health IT developers related to
ONC review and inquiry into certified health IT non-conformities. We
estimate the cost for a health IT developer to cooperate with an ONC
review and inquiry into certified health IT would, on average, range
from $9,819 to $49,096. We estimate the cost for ONC to review and
conduct an inquiry into certified health IT would, on average, range
from $2,455 to $73,644.
We estimated the costs to health IT developers and ONC associated
with the proposed appeal process following a suspension/termination of
a Complete EHR's or Health IT Module's certification. We estimate the
cost for a health IT developer to appeal a suspension or termination
would, on average, range from $9,819 to $29,458. We estimate the cost
for ONC to conduct an appeal would, on average, range from $24,548 to
$98,192.
We estimated the costs to health care providers to transition to
another certified health IT product when the certification of a
Complete EHR or Health IT Module that they currently use is terminated.
Specifically, we estimate the cost impact of certification termination
on health care providers would range from $33,000 to $649,836,000 with
a median cost of $792,000 and a mean cost of $6,270,000. We note,
however, that it is very unlikely that the high end of our estimated
costs would ever be realized. To date, there have been only a few
terminations of certified health IT under the Program, which have only
affected a small number on providers. Further, we have stated in this
proposed rule our intent to work with health IT developers to correct
non-conformities ONC finds in their certified health IT under the
provisions in this proposed rule. We provide a more detailed discussion
of past certification terminations and the potential impacts of
certification
[[Page 11060]]
termination on providers in section VII.C.1.a of this preamble.
We estimated the costs for ONC-ATLs and ONC associated with ONC-ATL
accreditation, application, renewal, and reporting requirements. We
estimate the annualized cost of ONC-ATL accreditation, application, and
the first proposed three-year authorization period to be approximately
$55,623. We estimate the annualized cost for an ONC-ATL to renew its
accreditation, application, and authorization during the first three-
year ONC-ATL authorization period to be approximately $84,372. In
addition, we estimate the total annual cost for ONC-ATLs to meet the
reporting requirements of proposed Sec. 170.524(d) to be approximately
$819.
We estimate ONC's annualized cost of administering the entire
application process to be approximately $992. These costs would be the
same for a new applicant or ONC-ATL renewal. We would also post the
names of applicants granted ONC-ATL status on our Web site. We estimate
the potential cost for posting and maintaining the information on our
Web site to be approximately $446 annually. We estimate an annual cost
to the federal government of $743 to record and maintain updates and
changes reported by the ONC-ATLs.
We estimate the costs for ONC-ATLs and ONC related to revoking ONC-
ATL status. We estimate the cost for an ONC-ATL to comply with ONC
requests per Sec. 170.565 would, on average, range from $2,455 to
$19,638. We estimate the cost for ONC would, on average, range from
$4,910 to $39,277.
We estimate the costs for ONC-ACBs to publicly post identifiable
surveillance results on their Web sites on a quarterly basis. We
estimate these costs would annually be $205 per ONC-ACB and total $615
for all ONC-ACBs.
We estimate the overall annual cost for this proposed rule, based
on the cost estimates outlined above, would range from $230,616 to
$650,288,915 with an average annual cost of $6,595,268. For a more
detailed explanation of our methodology and estimated costs, including
requests for comment on ways to improve our methodology and estimated
costs, please see section VII.C.1.a of this preamble.
2. Benefits
The proposed rule's provisions for ONC direct review of certified
health IT would promote health IT developers' accountability for the
performance, reliability, and safety of certified health IT; and
facilitate the use of safer and reliable health IT by health care
providers and patients. Specifically, ONC's direct review of certified
health IT would permit ONC to assess non-conformities and prescribe
comprehensive corrective actions for health IT developers to address
non-conformities, including notifying affected customers. As previously
stated, our first and foremost goal would be to work with health IT
developers to remedy any non-conformities with certified health IT in a
timely manner and across all customers. If ONC ultimately suspends and/
or terminates a certification issued to a Complete EHR or Health IT
Module under the proposals in this proposed rule, such action would
serve to protect the integrity of the Program and users of health IT.
Overall, we believe that ONC direct review supports and enables the
National Coordinator to fulfill his/her responsibilities under the
HITECH Act, instills public confidence in the Program, and protects
public health and safety.
The proposed rule's provisions would also provide other benefits.
The proposals for ONC to authorize and oversee testing labs (ONC-ATLs)
would facilitate further public confidence in testing and certification
by permitting ONC to timely and directly address testing issues for
health IT. The proposed public availability of identifiable
surveillance results would enhance transparency and the accountability
of health IT developers to their customers. This proposal would provide
customers and users of certified health IT with valuable information
about the continued performance of certified health IT as well as
surveillance efforts. Further, the public availability of identifiable
surveillance results would likely benefit health IT developers by
providing a more complete context of surveillance and illuminating good
performance and the continued compliance of certified health IT with
Program requirements. Overall, we believe these proposed approaches, if
finalized, would improve Program compliance and further public
confidence in certified health IT.
II. Provisions of the Proposed Rule
A. ONC's Role Under the ONC Health IT Certification Program
In initially developing the Program, ONC consulted with the
National Institute of Standards and Technology (NIST) and created the
Program structure based on industry best practice. This structure
includes the use of two separate accreditation bodies: (1) An
accreditor that evaluates the competency of a health IT testing
laboratory to operate a testing program in accordance with
international standards; and (2) an accreditor that evaluates the
competency of a health IT certification body to operate a certification
program in accordance with international standards (see the Permanent
Certification Program final rule). In this section of the preamble, we
propose means for enhancing ONC's role in the Program.
1. Review of Certified Health IT
We propose to modify ONC's role in the Program to provide
additional oversight of health IT certified under the Program. We
propose to create a process for ONC to directly review certified health
IT. We propose that ONC would directly assess non-conformities and,
where applicable, prescribe comprehensive corrective actions for health
IT developers that could include: Investigating and reporting on root
cause analyses of the non-conformities; notifying affected customers;
fully correcting identified issues across a health IT developer's
customer base; and taking other appropriate remedial actions. We
propose that ONC would be able to suspend and/or terminate a
certification issued to health IT under the Program. We also propose to
establish a process for health IT developers to appeal determinations
by ONC to suspend or terminate certifications issued to health IT under
the Program. We believe these proposals would enhance the overall
integrity and performance of the Program and provide greater confidence
that health IT conforms to the requirements of certification when it is
implemented, maintained, and used.
a. Authority and Scope
Section 3001 of the PHSA directs the National Coordinator to
establish a certification program or programs and to perform the duties
of keeping or recognizing such program(s) in a manner consistent with
the development of a nationwide health information technology
infrastructure that allows for the electronic use and exchange of
information and that, among other requirements: Ensures that each
patient's health information is secure and protected, in accordance
with applicable law; improves health care quality; reduces medical
errors; reduces health care costs resulting from inefficiency, medical
errors, inappropriate care, duplicative care, and incomplete
information; and promotes a more effective marketplace, greater
competition, greater systems analysis, increased consumer choice, and
improved outcomes in health care
[[Page 11061]]
services (see section 3001(b) of the PHSA).
Under the current structure of the Program, ONC-ACBs are
responsible for issuing and administering certifications in accordance
with ISO 17065, the PoPC for ONC-ACBs, and other requirements of the
Program. Specifically, ONC-ACBs are directly positioned and accountable
for determining whether a Complete EHR or Health IT Module initially
satisfies and subsequently continues to conform to certification
criteria, including relevant interpretative guidance and test
procedures. ONC-ACBs are also responsible for ensuring compliance with
other Program requirements such as the mandatory disclosure
requirements of limitations on use and types of costs related to
certified capabilities (see Sec. 170.523(k)(1)). If an ONC-ACB can
substantiate a non-conformity under the Program, either as a result of
surveillance or otherwise, ISO 17065 requires that the ONC-ACB consider
and decide upon the appropriate action, which could include: (1) The
continuation of the certification under specified conditions (e.g.,
increased surveillance); (2) a reduction in the scope of certification
to remove non-conforming product variants; (3) suspension of the
certification pending remedial action by the developer; or (4)
termination of the certification (see 80 FR 62707-62725 and Sec.
170.556).
While ONC authorizes ONC-ACBs to issue and administer
certifications for health IT, ONC does not directly review certified
health IT under the Program. The only exception would be if ONC revoked
an ONC-ACB's authorization due to a ``Type-1'' program violation \2\
that calls into question the legitimacy of a certification issued by
the ONC-ACB (see Sec. 170.570). Under these circumstances, the
National Coordinator would review and determine whether health IT was
improperly certified and, if so, require recertification of the health
IT within 120 days (76 FR 1299). We explained in the Permanent
Certification Program final rule that recertification would be
necessary in such a situation to maintain the integrity of the Program
and to ensure the efficacy and safety of certified health IT (76 FR
1299).
---------------------------------------------------------------------------
\2\ We defined Type-1 violations to include violations of law or
ONC Health IT Certification Program policies that threaten or
significantly undermine the integrity of the ONC Health IT
Certification Program. These violations include, but are not limited
to: false, fraudulent, or abusive activities that affect the ONC
Health IT Certification Program, a program administered by HHS or
any program administered by the Federal government (45 CFR
170.565(a)).
---------------------------------------------------------------------------
ONC-ACBs have the necessary expertise and capacity to effectively
administer certification requirements under a wide variety of
circumstances (80 FR 62708-09). Nevertheless, we recognized in response
to comments on the 2015 Edition proposed rule (80 FR 16804) that we
would need to provide additional guidance and assistance to ONC-ACBs to
ensure that these requirements are applied consistently and in a manner
that accomplishes our intent.\3\ While we are committed to supporting
ONC-ACBs in their roles, we further recognize that there are certain
instances when review of certified health IT is necessary to ensure
continued compliance with Program requirements, but such review is
beyond the scope of an ONC-ACB's responsibilities, expertise (i.e.,
accreditation), or resources.
---------------------------------------------------------------------------
\3\ Shortly after publishing the 2015 Edition final rule, we
issued updated guidance to ONC-ACBs on how to address these new
requirements in their annual surveillance plans. See ONC, Program
Policy Guidance #15-01A, https://www.healthit.gov/sites/default/files/policy/2015-11-02_supp_cy_16_surveillance_guidance_to_onc-acb_15-01a_final.pdf (November 5, 2015).
---------------------------------------------------------------------------
A health IT developer may have had products certified by two
different ONC-ACBs and a potential non-conformity with a certified
capability may extend across all of the health IT developers' certified
health IT. In such an instance, ONC would be more suited to handle the
review of the certified health IT as ONC-ACBs only have oversight of
the health IT they certify and ONC could ensure a more coordinated
review and consistent determination. Similarly, a potential non-
conformity or non-conformity may involve systemic, widespread, or
complex issues that could be difficult for an ONC-ACB to investigate or
address in a timely and effective manner, such as where the nature,
severity, or extent of the non-conformity would be likely to quickly
consume or exceed an ONC-ACB's resources or capacity. Most acutely,
non-conformities with certified health IT may arise that pose a risk to
public health or safety, including, for example, capabilities
(certified or uncertified) of health IT directly contributing to or
causing medical errors (see section 3001(b)(2) of the PHSA). In such
situations, ONC is directly responsible for reducing medical errors
through the certification of health IT and ONC-ACBs may not have the
expertise to address these matters. We believe there could also be
other exigencies, distinct from public health and safety concerns,
which for similar reasons would warrant ONC's direct review and action.
For example, ONC might directly review a potentially widespread non-
conformity that could compromise the security or protection of
patients' health information in violation of applicable law (see
section 3001(b)(1) of the PHSA) or that could lead to inaccurate or
incomplete documentation and resulting inappropriate or duplicative
care under federal health care programs (see section 3001(b)(3) of the
PHSA). Last, it is conceivable that ONC could have information about a
potential non-conformity that is confidential or that for other reasons
cannot be shared with an ONC-ACB, and therefore could be acted upon
only by ONC.
In the instances described above, we believe that the existing role
of ONC-ACBs could be complemented by establishing a process for ONC to
directly review certified health IT. While we propose that ONC would
have broad discretion to review certified health IT under proposed
Sec. 170.580(a), we anticipate that this ``direct review'' of
certified health IT would be relatively infrequent and would focus on
the situations that present unique challenges or issues that ONC-ACBs
may be unable to effectively address without ONC's assistance or
intervention (as described in the examples above and in proposed Sec.
170.580(a)(1)). ONC can effectively respond to these potential issues
through quickly marshaling and deploying resources and specialized
expertise and ensuring a coordinated review and response that may
involve other offices and agencies within HHS as well as other federal
agencies. We seek comment on these and other factors that ONC should
consider in deciding whether and under what circumstances to directly
review certified health IT. We emphasize that our primary goal in all
cases would be to correct non-conformities and ensure that certified
health IT performs in accordance with Program requirements. In this
regard, our first and foremost desire would be to work with the health
IT developer to remedy any non-conformity in a timely manner.
b. ONC-ACB's Role
We propose that ONC's review of certified health IT, as specified
in proposed 170.580(a)(2)(i), would be independent of, and may be in
addition, to any review conducted by an ONC-ACB, even if ONC and the
ONC-ACB were to review the same certified health IT, and even if the
reviews occurred concurrently. For the reasons and situations we have
described above in section II.A.1.a, we believe that these reviews
would be complementary
[[Page 11062]]
because ONC may review matters outside of an ONC-ACB's responsibilities
(i.e., those that implicate section 3001(b) of the PHSA) or matters
that may be partially within an ONC-ACB's purview to review but present
special challenges or considerations that may be difficult for an ONC-
ACB to address. Accordingly, to ensure consistency and clear
accountability, we propose in Sec. 170.580(a)(2)(ii) that ONC, if it
deems necessary, could assert exclusive review of certified health IT
as to any matters under review by ONC and any other matters that are so
intrinsically linked that divergent determinations between ONC and an
ONC-ACB would be inconsistent with the effective administration or
oversight of the Program. We propose in Sec. 170.580(a)(2)(iii) that
in such instances, ONC's determinations on these matters would take
precedent and a health IT developer would be subject to the proposed
ONC direct review provisions in this proposed rule, including having
the opportunity to appeal an ONC determination, as applicable.
We clarify that in matters where ONC does not assert direct and/or
exclusive review or ceases its direct and/or exclusive review, an ONC-
ACB would be permitted to issue its own determination on the matter.
Further, any determination to suspend or terminate a certification
issued to health IT by an ONC-ACB that may result would not be subject
to ONC review under the provisions in this proposed rule. In those
instances, there would also be no opportunity to appeal the ONC-ACB's
determination(s) under the provisions in this proposed rule. ONC-ACBs
are accredited, authorized, and entrusted to issue and administer
certifications under the Program consistent with certification criteria
and other specified Program requirements. Therefore, they have the
necessary expertise and capacity to effectively administer these
specific requirements.
We propose that ONC could initiate review of certified health IT on
its own initiative based on information from an ONC-ACB, which could
include a specific request from the ONC-ACB to conduct a review. In
exercising its review of certified health IT, we propose in Sec.
170.580(a)(2)(iv) that ONC would be entitled to any information it
deems relevant to its review that is available to the ONC-ACB
responsible for administering the health IT's certification. We propose
that ONC could contract with an ONC-ACB to conduct facets of the review
within an ONC-ACB's scope of expertise, such as testing or surveillance
of certified capabilities. We propose that ONC could also share
information with an ONC-ACB that may lead the ONC-ACB, at its
discretion and consistent with its accreditation, to conduct in-the-
field surveillance of the health IT at particular locations. We further
propose in Sec. 170.580(a)(2)(v) that ONC could, at any time, end all
or any part of its review of certified health IT under the processes in
this proposed rule and refer the applicable part of the review to the
relevant ONC-ACB(s) if doing so would serve the efficiency or effective
administration or oversight of the Program. The ONC-ACB would be under
no obligation to proceed further, but would have the discretion to
review and evaluate the information provided and proceed in a manner it
deems appropriate. As noted above, this may include processes and
determinations (e.g., suspension or termination) not governed by the
review and appeal processes in this proposed rule.
We encourage comment on our proposed approach and the role of an
ONC-ACB.
c. Review Processes
ONC could become aware of information from the general public,
interested stakeholders, ONC-ACBs, or by any other means that indicates
that certified health IT may not conform to the requirements of its
certification or is, for example, leading to medical errors, breaches
in the security of a patient's health information, or other outcomes
that do not align with the National Coordinator's responsibilities
under section 3001 of the PHSA. If ONC deems the information to be
reliable and actionable, it would conduct further inquiry into the
certified health IT. Alternatively, ONC could initiate an independent
inquiry into the certified health IT that could be conducted by ONC or
a third party(ies) on behalf of ONC (e.g., contractors or inspection
bodies under the certification scheme). If information reveals that
there is a potential non-conformity (through substantiation or omission
of information to the contrary) or confirms a non-conformity in the
certified health IT, ONC would proceed to notify the health IT
developer of its findings, as applicable, and work with the health IT
developer to address the matter.
We propose for all processes proposed under this section (section
II.A.1.c) of the preamble, as described below, that correspondence and
communication with ONC and/or the National Coordinator shall be
conducted by email, unless otherwise necessary or specified. We propose
to modify Sec. 170.505 accordingly.
(1) Notice of Potential Non-Conformity or Non-Conformity
If information suggests to ONC that certified health IT is not
performing consistent with Program requirements and a non-conformity
exists with the certified health IT, ONC would send a notice of
potential non-conformity or non-conformity to the health IT developer
(see proposed Sec. 170.580(b)(1)). The notice would specify ONC's
reasons for the notification, explain ONC's findings, and request that
the health IT developer respond to the potential/alleged non-conformity
(and potentially a corrective action request) or be subject to further
action (e.g., corrective action, suspension, and/or the termination of
the certification in question, as appropriate).
To ensure a complete and comprehensive review of the certified
health IT product, we propose in Sec. 170.580(b)(2) that ONC have the
ability to access and share within HHS, with other federal agencies,
and with appropriate entities, a health IT developer's relevant records
related to the development, testing, certification, implementation,
maintenance, and use of its product, as well as any complaint records
related to the product. We recognize that much of this information
already must be disclosed as required by the Program and described in
the 2015 Edition final rule. We propose, however, that ONC be granted
access to, and be able to share within HHS, with other federal
agencies, and with appropriate entities (e.g., a contractor or ONC-ACB)
any additional records not already disclosed that may be relevant and
helpful in ONC's fact-finding and review. This approach would support
the review of capabilities that interact with certified capabilities
and assist ONC in determining whether certified health IT conforms to
applicable Program requirements. We emphasize that health IT developers
would be required to cooperate with ONC's efforts to access relevant
records and should not prevent or seek to discourage ONC from obtaining
such records. If we determined that the health IT developer was not
cooperative with the fact-finding process, we propose that we would
have the ability to suspend or terminate the certification of any
encompassed Complete EHR or Health IT Module of the certified health IT
as outlined later in sections II.A.1.c.(3) and (4) of this preamble.
We understand that health IT developers may have concerns regarding
[[Page 11063]]
disclosure of proprietary, trade secret, competitively sensitive, or
other confidential information. To address these concerns, ONC would
implement appropriate safeguards to ensure, to the extent permissible
with federal law, that any proprietary business information or trade
secrets that ONC might encounter by accessing the health IT developer's
records would be kept confidential by ONC.\4\ For instance, ONC would
ensure that, if it obtains proprietary or trade secret information,
that information would not be included in the Certified Health IT
Product List (CHPL). We note, however, that the safeguards we would
adopt would be prophylactic and would not create a substantive basis
for a health IT developer to refuse to comply with the proposed
requirements. Thus, a health IT developer would not be able to avoid
providing ONC access to relevant records by asserting that such access
would require it to disclose trade secrets or other proprietary or
confidential information.
---------------------------------------------------------------------------
\4\ The Freedom of Information Act and Uniform Trade Secrets Act
generally govern the disclosure of these types of information.
---------------------------------------------------------------------------
The notice of potential non-conformity or non-conformity would
specify the timeframe for which the health IT developer must respond to
ONC. Unless otherwise specified in the notice and as outlined in
proposed Sec. 170.580(b)(1)(i) and (ii), the health IT developer would
be required to respond within 30 days of receipt of the notice and, if
necessary, submit a proposed corrective action plan as outlined below
in section II.A.1.c.(2) of this preamble. We propose that ONC may
require a health IT developer to respond and/or submit a proposed
corrective action plan in more or less time than 30 days based on
factors such as, but not limited to: (1) The type of health IT and
health IT certification in question; (2) the type of non-conformity to
be corrected; (3) the time required to correct the potential non-
conformity or non-conformity; and (4) issues of public safety and other
exigencies related to the National Coordinator carrying out his or her
duties in accordance with sections 3001(b) and (c) of the PHSA (see
proposed Sec. 170.580(b)(1)(i) and (ii)). We propose that ONC would
have discretion in deciding the appropriate timeframe for a response
and proposed corrective action plan from the health IT developer. We
believe that affording ONC this flexibility would advance the
overarching policy goal of ensuring that ONC addresses and works with
health IT developers to correct potential non-conforming health IT in
an efficient and effective manner.
We propose in Sec. 170.580(b)(3) that if the health IT developer
contends that the certified health IT in question conforms to Program
requirements, the health IT developer must include in its response all
appropriate documentation and explain in writing why the health IT is
conformant.
We request comment on our proposed processes as described above,
including whether the timeframe for responding to a notice of potential
non-conformity or non-conformity is reasonable and whether there are
additional factors that we should consider.
(2) Corrective Action
If ONC finds that certified health IT does not conform to Program
requirements, ONC would take appropriate action with the health IT
developer to remedy the non-conformity as outlined below and in
proposed Sec. 170.580(c). To emphasize, remedying a non-conformity may
require addressing both certified and uncertified capabilities within
the certified health IT.
We propose in Sec. 170.580(c)(1) that ONC would require a health
IT developer to submit a proposed corrective action plan to ONC. The
corrective action plan would provide a means to correct the identified
non-conformities across all the health IT developer's customer base and
would require the health IT developer to make such corrections before
the certified health IT could continue to be identified as
``certified'' under the ONC Health IT Certification Program, or sold or
licensed with that designation to new customers.
We propose, as described above in section II.A.1.c.(1) of this
preamble, that a health IT developer must submit a proposed corrective
action plan to ONC within 30 days of the date that the health IT
developer was notified by ONC of the non-conformity unless ONC
specifies a different timeframe. This approach aligns with and does not
change the corrective action process for ONC-ACBs described in Sec.
170.556(d). The primary difference between this approach and the
approach for ONC-ACBs in Sec. 170.556(d) is that in Sec. 170.556(d)
the health IT developer must submit a corrective action plan to an ONC-
ACB within 30 days of being notified of the potential non-conformity.
In this proposed rule, we propose that this 30-day period be the
default for receiving a response/corrective action plan, but that ONC
may alter the response period based on non-conformities that may pose a
risk to public health or safety, or other exigencies related to the
National Coordinator carrying out his or her duties in accordance with
sections 3001(b) and (c) of the PHSA.
We propose in Sec. 170.580(c)(2) that ONC would provide direction
to the health IT developer as to the required elements of the
corrective action plan and would work with the health IT developer to
develop an acceptable corrective action plan. The corrective action
plan would be required to include, at a minimum, for each non-
conformity:
A description of the identified non-conformity;
An assessment of the nature, severity, and extent of the
non-conformity, including how widespread they may be across all of the
health IT developer's customers of the certified health IT;
How the health IT developer will address the identified
non-conformity, both at the locations where the non-conformity was
identified and for all other potentially affected customers;
A detailed description of how the health IT developer will
assess the scope and impact of the non-conformity(ies), including
identifying all potentially affected customers, how the health IT
developer will promptly ensure that all potentially affected customers
are notified of the non-conformity and plan for resolution, how and
when the health IT developer will resolve issues for individual
affected customers, and how the health IT developer will ensure that
all issues are in fact resolved; and
The timeframe under which corrective action will be
completed.
We propose in Sec. 170.580(c)(3) that when ONC receives a proposed
corrective action plan (or a revised proposed corrective action plan)
it shall either approve the proposed corrective action plan or, if the
plan does not adequately address all required elements, instruct the
health IT developer to submit a revised proposed corrective action
plan. In addition to the required elements above and as specified in
Sec. 170.580(c)(4), we propose that a health IT developer would be
required to submit an attestation to ONC. The attestation would follow
the form and format specified by the corrective action plan and would
be a binding official statement by the health IT developer that it has
fulfilled all of its obligations under the corrective action plan,
including curing the identified non-conformities and related
deficiencies and taking all reasonable steps to prevent their
recurrence. Based on this attestation and all other relevant
information, ONC would determine whether the non-conformity(ies) has
[[Page 11064]]
been cured and, if so, would lift the corrective action plan. However,
if it were later discovered that the health IT developer had not acted
in the manner attested, we propose that ONC could reinstitute the
corrective action plan or proceed to suspend or terminate the
certification of any encompassed Complete EHR or Health IT Module of
the certified health IT (see proposed Sec. 170.580(c)(5), (d)(1)(v)
and (e)(1)(iv)).
We request comment on our proposed corrective action plan processes
as described above.
We propose that ONC would report the corrective action plan and
related data to the publicly accessible CHPL. The purpose of this
reporting requirement, as it is for ONC-ACBs under current regulations,
would be to ensure that health IT users, implementers, and purchasers
are alerted to potential conformance issues in a timely and effective
manner. This approach is consistent with the public health and safety,
program integrity, and transparency objectives described previously in
this proposed rule and in the 2015 Edition final rule (80 FR 62725-26).
(3) Suspension
We propose that ONC may suspend the certification of a Complete EHR
or Health IT Module at any time because ONC believes that the certified
health IT poses a potential risk to public health or safety, other
exigent circumstances exist concerning the product, or due to certain
actions or inactions by the product's health IT developer as detailed
below. We propose in Sec. 170.580(d)(1) that ONC would be permitted to
initiate certification suspension procedures for a Complete EHR or
Health IT Module for any one of the following reasons:
Based on information it has obtained, ONC believes that
the certified health IT poses a potential risk to public health or
safety or other exigent circumstances exist. More specifically, ONC
would suspend a certification issued to any encompassed Complete EHR or
Health IT Module of the certified health IT if the certified health IT
was, but not limited to: Contributing to a patient's health information
being unsecured and unprotected in violation of applicable law;
increasing medical errors; decreasing the detection, prevention, and
management of chronic diseases; worsening the identification and
response to public health threats and emergencies; leading to
inappropriate care; worsening health care outcomes; or undermining a
more effective marketplace, greater competition, greater systems
analysis, and increased consumer choice. Such results would conflict
with section 3001(b) of the PHSA, which instructs the National
Coordinator to perform the duties in keeping or recognizing a
certification program that, among other requirements, ensures patient
health information is secure and protected in accordance with
applicable law, reduces medical errors, increases efficiency, and leads
to improved care and health care outcomes. As discussed under the
``termination'' section below, we propose that ONC could terminate a
certification on the same basis if it concludes that a certified health
IT's non-conformity(ies) cannot be cured;
The health IT developer fails to timely respond to any
communication from ONC, including, but not limited to: Fact-finding; or
a notice of potential non-conformity or notice of non-conformity;
The information provided by the health IT developer in
response to any ONC communication, including, but not limited to: Fact-
finding, a notice of potential non-conformity, or a notice of non-
conformity is insufficient or incomplete;
The health IT developer fails to timely submit a proposed
corrective action plan that adequately addresses the elements required
by ONC as described earlier in this preamble under the ``corrective
action'' section and in proposed Sec. 170.580(c); or
The health IT developer does not fulfill its obligations
under the corrective action plan developed in accordance with proposed
Sec. 170.580(c).
We note that section Sec. 170.556(d)(5) states that, consistent
with its accreditation to ISO 17065 and procedures for suspending a
certification, an ONC-ACB shall initiate suspension procedures for a
Complete EHR or Health IT Module:
30 days after notifying the developer of a non-conformity,
if the developer has not submitted a proposed corrective action plan;
90 days after notifying the developer of a non-conformity,
if the ONC-ACB cannot approve a corrective action plan because the
developer has not submitted a revised proposed corrective action plan;
and
Immediately, if the developer has not completed the
corrective actions specified by an approved corrective action plan
within the time specified therein.
As noted above, we propose that ONC may suspend a certification for
similar reasons, but also propose that ONC would suspend a
certification at any time based on a potential risk to public health or
safety, or other exigent circumstances. We believe the proposed
addition of an expedited process and direct ONC review for those
reasons makes the Program better enabled for ONC to act swiftly to
address potentially non-conforming certified health IT. To note, the
processes for ONC-ACBs as detailed above and in the 2015 Edition final
rule are not altered by the proposals in this proposed rule.
ONC's process for obtaining information to support a suspension
could involve, but would not be limited to: Fact-finding; requesting
information from an ONC-ACB; contacting users of the health IT; and/or
reviewing complaints. We propose in Sec. 170.580(d)(2) that ONC would
issue a notice of suspension when appropriate. We propose that a
suspension would become effective upon the health IT developer's
receipt of the notice of suspension. We propose that the notice of
suspension would include, but not be limited to: ONC's explanation for
the suspension; the information ONC relied upon to reach its
determination; the consequences of suspension for the health IT
developer and the Complete EHR or Health IT Module under the Program;
and instructions for appealing the suspension. We propose that the
notice of suspension would be sent via certified mail and the official
date of receipt would be the date of the delivery confirmation.
We propose in 170.580(d)(3) that the health IT developer would be
required to notify its affected and potentially affected customers of
the certification suspension in a timely manner. Additionally, we
propose that ONC would publicize the suspension on the CHPL to alert
interested parties, such as purchasers of certified health IT or
programs that require the use of certified health IT. We propose in
Sec. 170.580(d)(4) that ONC would issue a cease and desist notice to
health IT developers to immediately stop the marketing and sale of the
Complete EHR or Health IT Module as ``certified'' under the Program
when it suspends the Complete EHR's or Health IT Module's
certification. Additionally, we propose in Sec. 170.580(d)(5) that in
cases of a certification suspension, inherited certified status for the
Complete EHR or Health IT Module would not be permitted. We propose in
Sec. 170.580(d)(6) that we would rescind a suspension of certification
if the health IT developer completes all elements of an approved
corrective action plan and/or ONC confirms that all non-conformities
have been corrected.
We request comments on these processes, including how timely a
health IT developer should notify
[[Page 11065]]
affected and potentially affected customers of a suspension and what
other means we should consider using for publicizing certification
suspensions. We also request comment on whether a health IT developer
should only be permitted to certify new Complete EHRs and Health IT
Modules while the certification in question is suspended if such new
certification of other Complete EHRs or Health IT Modules would correct
the non-conformity for all affected customers. Such a prohibition on
the certification of new Complete EHRs or Health IT Modules may
incentivize the health IT developer to cure the non-conformity. In
correcting the non-conformity for all affected customers, we note that
this would not include those affected customers that decline the
correction or fail to cooperate. We request comment as to whether
correcting the non-conformity for a certain percentage of all affected
customers or certain milestones demonstrating progress in correcting
the non-conformity (e.g., a percentage of customers within a period of
time) should be sufficient to lift the prohibition.
Under the current suspension processes administered by ONC-ACBs,
following the suspension of a certification of a Complete EHR or Health
IT Module, an ONC-ACB is permitted to initiate certification
termination procedures for the Complete EHR or Health IT Module should
the health IT developer not complete the actions necessary to reinstate
the suspended certification (consistent with its accreditation to ISO
17065 and procedures for terminating a certification). We propose that
ONC would similarly be permitted to initiate the certification
termination procedures as described in more detail in the
``Termination'' section below.
(4) Termination
We propose in Sec. 170.580(e)(1) that ONC may terminate
certifications issued to Complete EHRs or Health IT Modules under the
Program if: (1) The health developer fails to timely respond to any
communication from ONC, including, but not limited to: (a) Fact-
finding; and (b) a notice of potential non-conformity or non-
conformity; (2) the information provided by the health IT developer in
response to fact-finding, a notice of potential non-conformity, or a
notice of non-conformity is insufficient or incomplete; (3) the health
IT developer fails to timely submit a proposed corrective action plan
that adequately addresses the elements required by ONC as described in
section II.A.1.c.(2) of this preamble; (4) the health IT developer does
not fulfill its obligations under the corrective action plan developed
in accordance with proposed Sec. 170.580(c); or (5) ONC concludes that
the certified health IT's non-conformity(ies) cannot be cured. We
request comment on these proposed reasons for termination and on any
additional circumstances for which commenters believe termination of a
certification would be warranted.
We propose that a termination would be issued consistent with the
processes specified in proposed Sec. 170.580(e)(2) through (4) and
outlined below, but note that these proposed termination processes do
not change the certification termination processes for ONC-ACBs
described in the 2015 Edition final rule. A notice of termination would
include, but may not be limited to: ONC's explanation for the
termination; the information ONC relied upon to reach its
determination; the consequences of termination for the health IT
developer and the Complete EHR or Health IT Module under the Program;
and instructions for appealing the termination. ONC would send a
written notice of termination to the agent of record for the health IT
developer of the Complete EHR or Health IT Module. The written
termination notice would be sent via certified mail and the official
date of receipt would be the date of the delivery confirmation.
The termination of a certification would be effective either upon:
(1) The expiration of the 10-day period for filing an appeal as
specified in section II.A.1.c.(5) of this preamble if the health IT
developer does not file an appeal; or, if a health IT developer files
an appeal, (2) upon a final determination to terminate the
certification as described below in the ``appeal'' section of the
preamble and in proposed Sec. 170.580(f)(7). As we proposed for
suspension of a certification, the health IT developer must notify the
affected and potentially affected customers of the identified non-
conformity(ies) and termination of certification in a timely manner.
Additionally, we propose that ONC would publicize the termination on
the CHPL to alert interested parties, such as purchasers of certified
health IT or entities administering programs that require the use of
health IT certified under the Program. We request comments on these
processes, including how timely a health IT developer should notify
affected and potentially affected customers of a termination of a
Complete EHR's or Health IT Module's certification and what other means
we should consider for publicizing certification terminations.
(5) Appeal
If ONC suspends or terminates a certification for a Complete EHR or
Health IT Module, we propose that the health IT developer of the
Complete EHR or Health IT Module may appeal the determination to the
National Coordinator in accordance with the proposed processes
specified in Sec. 170.580(f) and outlined below.
Section 170.580(f)(1) sets forth that a health IT developer may
appeal an ONC determination to suspend or terminate a certification
issued to Complete EHR or a Health IT Module if the health IT developer
asserts: (1) ONC incorrectly applied Program methodology, standards, or
requirements for suspension or termination; or (2) ONC's determination
was not sufficiently supported by the information used by ONC to reach
the determination.
Section 170.580(f)(2) describes that a request for appeal of a
suspension or termination must be submitted in writing by an authorized
representative of the health IT developer whose certified Complete EHR
or certified Health IT Module was subject to the determination being
appealed. Section 170.580(f)(2) also requires that the request for
appeal must be filed in accordance with the instructions specified in
the notice of termination or notice of suspension. These instructions
for filing a request may include, but would not be limited to: (1)
Providing a copy of the written determination by ONC to suspend or
terminate the certification and any supporting documentation; and (2)
explaining the reasons for the appeal. Section 170.580(f)(3) describes
that this request must be submitted to ONC within 10 calendar days of
the health IT developer's receipt of the notice of suspension or notice
of termination. Section 170.580(f)(4) specifies that a request for
appeal would stay the termination of a certification issued to a
Complete EHR or Health IT Module until a final determination is reached
on the appeal. However, a request for appeal would not stay a
suspension of a Complete EHR or Health IT Module. We propose that,
similar to the effects of a suspension, while an appeal would stay a
termination, a Complete EHR or Health IT Module would be prohibited
from being marketed or sold as ``certified'' during the stay.
We propose that the National Coordinator would assign the appeal to
a hearing officer who would adjudicate the appeal on his or her behalf,
as described in Sec. 170.580(f)(5). The hearing officer may not
preside over an appeal in which he or she participated in the
[[Page 11066]]
initial suspension or termination determination by ONC or has a
conflict of interest in the pending matter.
There would be two parties involved in an appeal: (1) The health IT
developer that requests the appeal; and (2) ONC. Section
170.580(f)(6)(i) describes that the hearing officer would have the
discretion to make a determination based on: (1) The written record as
submitted to the hearing officer by the health IT developer with the
appeal filed in accordance with proposed Sec. 170.580(f)(1) through
(3) and would include ONC's written statement and supporting
documentation, if provided; or (2) the information described in option
1 and a hearing conducted in-person, via telephone, or otherwise. As
specified in Sec. 170.580(f)(6)(ii), the hearing officer would have
the discretion to conduct a hearing if he or she: (1) Requires
clarification by either party regarding the written record under
paragraph (f)(6)(i) of this section; (2) requires either party to
answer questions regarding the written record under paragraph (f)(6)(i)
of this section; or (3) otherwise determines a hearing is necessary. As
specified in Sec. 170.580(f)(6)(iii), the hearing officer would
neither receive testimony nor accept any new information that was not
presented with the appeal request or was specifically and clearly
relied upon to reach the determination to suspend or terminate the
certification by ONC. As specified in Sec. 170.580(f)(6)(iv), the
default process for the hearing officer would be a determination based
on option 1 described above.
As proposed in Sec. 170.580(f)(6)(v) and mentioned above, once the
health IT developer requests an appeal, ONC would have an opportunity
to provide the hearing officer with a written statement and supporting
documentation on its behalf (e.g., a brief) that explains its
determination to suspend or terminate the certification. Failure of ONC
to submit a written statement would not result in any adverse findings
against ONC and may not in any way be taken into account by the hearing
officer in reaching a determination.
As proposed in Sec. 170.580(f)(7)(i), the hearing officer would
issue a written determination to the health IT developer within 30 days
of receipt of the appeal, unless the health IT developer and ONC agree
to a finite extension approved by the hearing officer. We request
comment on whether the allotted time for the hearing officer to issue a
written determination should be lessened or lengthened, such as 15, 45,
or 60 days. We also request comment on whether an extension should be
permitted and whether it should only be permitted under the
circumstances proposed or for other reasons and circumstances.
As proposed in Sec. 170.580(f)(7)(ii), the National Coordinator's
determination, as issued by the hearing officer, would be the agency's
final determination and not subject to further review.
We welcome comments on the proposed appeal processes outlined in
this section.
d. Consequences of Certification Termination
In general, this proposed rule does not address the consequences of
certification termination beyond requirements for recertification. Any
consequences of, and remedies for, termination beyond recertification
requirements are outside the scope of this proposed rule. For example,
this proposed rule does not address the remedies for providers
participating in the EHR Incentive Programs that may be using a
Complete EHR or Health IT Module that has its certification
terminated.\5\ While our goals with this proposed rule are to enhance
Program oversight and health IT developer accountability for the
performance, reliability, and safety of certified health IT, we remind
stakeholders that we have proposed methods (e.g., corrective action
plans) designed to identify and remedy non-conformities so that a
Complete EHR or Health IT Module can maintain its certification.
---------------------------------------------------------------------------
\5\ See CMS EHR Incentive Programs FAQ 12657: https://questions.cms.gov/faq.php?isDept=0&search=decertified&searchType=keyword&submitSearch=1&id=5005.
---------------------------------------------------------------------------
(1) Program Ban and Heightened Scrutiny
We propose in Sec. 170.581(a) that a Complete EHR or Health IT
Module that has had its certification terminated can be tested and
recertified once all non-conformities have been adequately addressed.
We propose that the recertified Complete EHR or Health IT Module (or
replacement version) must maintain a scope of certification that, at a
minimum, includes all the previous certified capabilities. We propose
that the health IT developer must request permission to participate in
the Program before submitting the Complete EHR or Health IT Module (or
replacement version) for testing to an ONC-ATL and recertification
(certification) by an ONC-ACB under the Program. As part of its
request, we propose that a health IT developer must submit a written
explanation of what steps were taken to address the non-conformities
that led to the termination. We also propose that ONC would need to
review and approve the request for permission to participate in the
Program before testing and recertification (certification) of the
Complete EHR or Health IT Module (or replacement version) can commence
under the Program.
If the Complete EHR or Health IT Module (or replacement version) is
recertified (certified), we believe and propose in Sec. 170.581(b)
that the certified health IT product should be subjected to some form
of heightened scrutiny by ONC or an ONC-ACB for a minimum of one year.
We believe completion of the recertification process and heightened
scrutiny would support the integrity of the Program and the continued
functionality and reliability of the certified health IT. We request
comment on the forms of heightened scrutiny (e.g., quarterly in-the-
field surveillance) and length of time for the heightened scrutiny
(more or less than one year, such as six months or two years) of a
recertified Complete EHR or recertified Health IT Module (or
replacement version) that previously had its certification terminated.
We propose in Sec. 170.581(c) that the testing and certification
of any health IT of a health IT developer that has the certification of
one of its health IT products terminated under the Program or withdrawn
from the Program when the subject of a potential nonconformity (notice
of potential non-conformity) or non-conformity would be prohibited. The
only exceptions would be if: (1) The non-conformity is corrected and
implemented to all affected customers; or (2) the certification and
implementation of other health IT by the health IT developer would
remedy the non-conformity for all affected customers. As noted in the
discussion under the proposed suspension provisions, prohibiting the
certification of new products, unless it serves to correct the non-
conformity for all affected customers, may incentivize a health IT
developer to cure the non-conformity. In correcting the non-conformity
for all affected customers, we note that this would not include those
customers that decline the correction or fail to cooperate. We welcome
comments on this proposal, including how the health IT developer should
demonstrate to ONC that all necessary corrections were completed. We
further request comment as to whether correcting the non-conformity for
a certain percentage of all affected customers or certain milestones
demonstrating progress in correcting the non-conformity (e.g., a
percentage of customers within a period of time) should be sufficient
to lift the
[[Page 11067]]
prohibition. Additionally, consistent with this and the other proposed
requirements of Sec. 170.581, we request comment on whether heightened
scrutiny (surveillance or other requirements) should apply for a period
of time (e.g., six months, one year, or two years) to all currently
certified Complete EHRs or certified Health IT Modules, future versions
of either type, and all new certified health IT of a health IT
developer that has a product's certification terminated under the
Program.
(2) ONC-ACB Response to a Non-Conformity
As previously noted in this proposed rule, ONC-ACBs are accredited
to ISO 17065. Section 7.11.1 of ISO 17065 instructs certification
bodies to consider and decide upon the appropriate action to address a
non-conformity found, through surveillance or otherwise, in the product
the certification body certified.\6\ Section 7.11.1 lists, among other
appropriate actions, the reduction in scope of certification to remove
non-conforming product variants or withdrawal of the certification. We
do not, however, believe these are appropriate actions under the
Program.
---------------------------------------------------------------------------
\6\ 45 CFR 170.599(b)(3).
---------------------------------------------------------------------------
We do not believe that a reduction in scope is appropriate for
health IT under the Program. This action would absolve a health IT
developer from correcting a non-conformity. Health IT is tested and
certified to meet adopted criteria and requirements. It should continue
to meet those criteria and requirements when implemented. If not, it
should be corrected (the version is corrected through an update or a
new corrected version is rolled out to all affected customers) or be
subjected to certification termination. Accordingly, we propose to
revise the PoPC for ONC-ACBs (Sec. 170.523) to prohibit ONC-ACBs from
reducing the scope of a certification when the health IT is under
surveillance or a corrective action plan. This proposal addresses two
situations: (1) When health IT is suspected of a non-conformity (i.e.,
under surveillance); and (2) when health IT has a non-conformity (i.e.,
under a corrective action plan).
A health IT developer's withdrawal of its certified health IT from
the Program when the subject of a potential non-conformity (under
surveillance) or non-conformity should not be without prejudice. If a
health IT developer is not willing to correct a non-conformity, then we
believe the health IT developer should be subject to the same proposed
consequences as we have proposed under ONC direct review of health IT
(i.e., a Program ban on the testing and certification of its health
IT). We further propose that the same proposed consequences for health
IT and health IT developers related to certification termination under
ONC direct review (i.e., all of the Sec. 170.581 proposals) should
apply to certification terminations issued by ONC-ACBs. We note that
the concept of heightened scrutiny, as described above, is consistent
with section 7.11.1 listing of increased surveillance as an appropriate
response to a non-conformity.
These proposals are consistent with our proposed approach and
processes for ONC direct review and would support the overall integrity
and reliability of the Program. We welcome comment on these proposals.
2. Establishing ONC Authorization for Testing Labs Under the Program;
Requirements for ONC-ATL Conduct; ONC Oversight and Processes for ONC-
ATLs
a. Background on Testing and Relationship of Testing Labs and the
Program
The Temporary Certification Program, established by final rule (75
FR 36158), provided a process by which an organization or organizations
could become an ONC-Authorized Testing and Certification Body (ONC-
ATCB) and be authorized by the National Coordinator to perform the
testing and certification of Complete EHRs and/or Health IT Modules.
Under the Temporary Certification Program, an organization was both a
testing lab and certification body. The Temporary Certification Program
was replaced by the Permanent Certification Program, which first
finalized a new set of rules in 2011 (76 FR 1262). The name of the
Permanent Certification Program was changed to the ONC HIT
Certification Program in the 2014 Edition final rule (77 FR 54163) and
the ONC Health IT Certification Program (Program) in the 2015 Edition
final rule (80 FR 62602).
Under the Program, testing and certification must be completed by
organizations (or components of organizations) that are separately
accredited to different ISO standards (i.e., ISO 17065 for
certification and ISO 17025 for testing). In the Permanent
Certification Program final rule, we explained that the NVLAP,
administered by NIST, would be the accreditor for health IT testing
labs under the Program (76 FR 1278-1281).
Unlike the processes we established for ONC-ACBs, which at a high-
level includes a two-step process of: (1) Accreditation by the ONC-
Approved Accreditor; and (2) a formal request for and subsequent
authorization by the National Coordinator to operate within the
Program, we did not establish a similar and equitable process for
testing labs. Instead, we required in the PoPC for ONC-ACBs (45 CFR
170.523(h)) that ONC-ACBs only accept test results from NVLAP-
accredited testing labs. This requirement for ONC-ACBs had the effect
of requiring testing labs to be accredited by NVLAP to ISO 17025.
However, in so doing, there is effectively no direct ONC oversight of
NVLAP-accredited testing labs like there is for ONC-ACBs.
In the five years we have administered the Program, we have
continually made updates to the Program's rules to refine, mature, and
optimize program operations (see revisions to the Program in the 2014
Edition final rule, 2014 Edition Release 2 final rule, and 2015 Edition
final rule). These changes have also included new and expanded
responsibilities for ONC-ACBs and ONC. While we have continued to
update and improve our oversight of ONC-ACBs, we have not done the same
for the testing labs upon which ONC-ACBs rely. Our continued evaluation
of the Program has led us to determine that the operational efficiency
and overall integrity of the Program could be improved by establishing
parity in the oversight we provide for both testing and certification.
The testing of health IT by accredited testing labs is the first
line of evaluation in determining whether health IT meets the
capabilities included in a certification criterion and serves as the
basis for the certification of health IT by ONC-ACBs. We believe that
having a similar and comparable authorization and oversight paradigm
for testing labs and certification bodies would enable ONC to oversee
and address testing and certification performance issues throughout the
entire continuum of the Program in a precise and direct manner. For
example, ensuring that consistent testing documentation (e.g., files,
reports, and test tool outputs) is produced across all ONC-ATLs could
be directly addressed at the testing stage compared to today's rules
that solely apply to ONC-ACBs, who are simply the recipients of such
information. Additionally, ONC direct oversight would ensure that, like
with ONC-ACBs, testing labs are directly and immediately accountable to
ONC for their performance across a variety of Program items including,
but not limited to: Specifying and verifying testing personnel
qualifications;
[[Page 11068]]
requiring training sessions for testing lab personnel; establishing
record documentation and retention requirements; and instituting
methods for addressing inappropriate and incorrect testing methods and
non-compliance with Program requirements.
b. Proposed Amendments To Include ONC-ATLs in the Program
This proposed rule proposes means for ONC to have direct oversight
of NVLAP-accredited testing labs by having them apply to become ONC-
ATLs. Specifically, this proposed rule proposes means for authorizing,
retaining, suspending, and revoking ONC-ATL status under the Program.
These proposed processes are similar to current ONC-ACB processes. In
general, to seek and acquire authorization, an applicant must be NVLAP-
accredited to ISO 17025, agree to the PoPC for ONC-ATLs, and comply
with the proposed application documentation and procedural
requirements. We propose that an ONC-ATL would retain its status for a
three-year period that could be continually renewed as long as the ONC-
ATL follows proposed good standing and testing requirements, including
the PoPC for ONC-ATLs. To maintain proper oversight and the integrity
of the Program, we propose criteria and means for ONC to suspend and
revoke an ONC-ATL's status under the Program, which include
opportunities for an ONC-ATL to become compliant and respond to a
proposed suspension and/or revocation. We also request comment on
whether we should revise Sec. 170.570 to account for the possibility
of an ONC-ATL having its status revoked for a Type-1 violation that
called into question the legitimacy of certifications issued by an ONC-
ACB.
The following sections detail each new and amended regulatory
provisions that we propose for subpart E of part 170, starting with 45
CFR 170.501, in order to include ONC-ATLs as part of the Program. For
authorization and other processes, we intend to follow and leverage all
of the processes established for ONC-ACBs. Thus, most of our proposals
are minimal conforming amendments to existing regulatory text that add
in references to a testing lab or (once authorized) ONC-ATL.
(1) Proposed Amendments to Sec. 170.501 Applicability
We propose to revise paragraph (a) of Sec. 170.501 to include
references to ``applicants for ONC-ATL status;'' ``ONC-ATL;'' and
``ONC-ATL status.'' The proposed revisions would make clear that ONC-
ATLs are part of the rules under this subpart.
(2) Proposed Amendments to Sec. 170.502 Definitions
We propose to revise the definition of the term ``Applicant'' in
Sec. 170.502 to include a corresponding reference to ONC-ATL in order
for such term to have equal meaning in the case of a testing lab that
is applying for ONC-ATL status.
We propose to revise the definition of the term ``gap
certification'' in Sec. 170.502 to include a corresponding reference
to ONC-ATL in paragraph (1) of that definition in order to give equal
weight to test results based those issued by an ONC-ATL. We also
propose to add ``under the ONC Health IT Certification Program'' to
paragraphs (1) and (2) of the definition to improve the clarity of the
definition.
We propose to define the term ``ONC-Authorized Testing Lab'' or
``ONC-ATL'' to mean an organization or consortium of organizations that
has applied to and been authorized by the National Coordinator to
perform the testing of Complete EHRs and Health IT Modules to
certification criteria adopted by the Secretary in subpart C of this
part.
(3) Proposed Amendments to Sec. 170.505 Correspondence
In order to accurately reflect the addition of an applicant for
ONC-ATL status and ONC-ATLs to the Program framework, we propose to
revise Sec. 170.505 to include references to ONC-ATL as appropriate.
(4) Proposed Amendment to Sec. 170.510 Type of Certification
To make clear that Sec. 170.510 is specifically geared toward
applicants for ONC-ACB status and the authorization they may seek, we
propose to revise the section heading to specifically reference the
authorization scope of ONC-ACB status. We also propose to revise the
introductory text within this section to more clearly convey that this
section is solely focused on applicants for ONC-ACB status.
(5) Proposed Creation of Sec. 170.511 Authorization Scope for ONC-ATL
Status
We propose to create a new section (Sec. 170.511) to clearly
define the scope of the authorization an ``applicant'' testing lab may
be able to seek from the National Coordinator. We propose that such
authorization be limited to the certification criteria adopted by the
Secretary in subpart C of this part. However, to support specialized
testing and testing efficiencies for health IT, we propose that an
applicant for ONC-ATL status could seek for the scope of its
authorization all certification criteria, a subset of all of the
certification criteria (e.g., to support only privacy and security
testing), one certification criterion, or a portion of one
certification criterion. The latter two options provide opportunities
for entities that may perform industry testing of health IT for limited
and/or distinct capabilities (e.g., e-prescribing) that align with
certification criteria to participate in the Program. This approach
could avoid duplicative testing and reduce regulatory burden for health
IT developers that test and certify health IT under the Program and
with entities outside of the Program.
(6) Proposed Amendments to Sec. 170.520 Application
We propose to make the following amendments in order to establish
the requirements that an applicant for ONC-ATL status must follow for
its application for ONC-ATL status. First, we propose to reorder the
regulatory text hierarchy to reference the ONC-ACB application
requirements under Sec. 170.520(a) and then the ONC-ATL application
requirements under Sec. 170.520(b). For the ONC-ATL requirements, we
propose that an ONC-ATL applicant would need to seek authorization
based on the scope proposed in Sec. 170.511 and follow the same set of
amended requirements as applicable to the different accreditation and
PoPC to which ONC-ATLs would need to adhere. We propose that this
application information include the same general identifying
information as for ONC-ACB applicants; the same authorized
representative designation; documentation that the applicant has been
accredited by NVLAP to ISO 17025; and an agreement executed by the
authorized representative to PoPC for ONC-ATLs.
(7) Proposed Amendment to Sec. 170.523 Principles of Proper Conduct
for ONC-ACBs
We propose to revise Sec. 170.523(h) (PoPC for ONC-ACBs) to
explicitly include ONC-ATLs as an entity from whom ONC-ACBs would
receive test results (see proposed Sec. 170.523(h)(1)). Additionally,
to account for the transition period from NVLAP-accredited testing
laboratories to ONC-ATLs, we propose to modify Sec. 170.523(h) to
include a six month time window from the authorization of the first
ONC-ATL to permit the continued acceptance by ONC-ACBs of any test
results from a NVLAP-accredited testing
[[Page 11069]]
laboratory (see proposed Sec. 170.523(h)(2)). We believe this would
provide more than adequate transition time for ONC-ACBs to continue to
issue certifications based on test results for new and revised
certification criteria issued by a ``NVLAP-accredited testing
laboratory'' and would also serve as a mobilizing date for a testing
lab that has not yet applied for ONC-ATL status. We, however, request
comment on our proposed approach to the transition period from NVLAP-
accredited testing laboratories to ONC-ATLs. Specifically, we request
comment on whether we should alternatively establish that ONC-ACBs may
only be permitted to accept any test results from a NVLAP-accredited
testing laboratory for a period of time from the effective date of a
subsequent final rule. This approach would provide a more certain
timetable for ONC-ACBs compared to the proposed approach, but may not
provide sufficient time for all NVLAP-accredited testing laboratories
to transition to ONC-ATL status. We also request comment on whether the
transition period should be shorter (e.g., three months) or longer
(e.g., nine months) under either the proposed approach or the
alternative approach.
We propose in Sec. 170.523(h)(2) to permit the use of test results
from a NVLAP-accredited testing laboratory for certifying previously
certified health IT to unchanged certification criteria and gap
certification. As proposed, NVLAP-accredited testing laboratories would
be replaced with ONC-ATLs. This proposal would permit the test results
issued by NVLAP-accredited testing laboratories under the Program
(e.g., test results for health IT tested to the 2014 Edition) to
continue to be used for certifying previously certified health IT to
unchanged certification criteria and gap certification. As a related
proposal, we propose to remove references to ONC-ATCBs in Sec.
170.523(h). ONC-ATCBs certified health IT to the 2011 Edition. The 2011
Edition has been removed from the Code of Federal Regulations and ONC-
ACBs no longer maintain active certifications for health IT certified
to the 2011 Edition.
(8) Proposed Creation of Sec. 170.524 Principles of Proper Conduct for
ONC-ATLs
Similar to the set of rules and conditions to which we require ONC-
ACBs to adhere, we propose to establish a corresponding set of PoPC to
which ONC-ATLs must adhere. Adherence to these conduct requirements
would be necessary for ONC-ATLs to maintain their authorization and to
remain in good standing under the Program. Many of the proposed PoPC
for ONC-ATLs would remain consistent with those to which ONC-ACBs are
already required to adhere. The proposed PoPC for ONC-ATLs include that
an ONC-ATL shall:
Maintain its accreditation through NVLAP based on the ISO
17025 standard;
Attend all mandatory ONC training and program update
sessions;
Maintain a training program that includes documented
procedures and training requirements to ensure its personnel are
competent to test health IT;
Report to ONC within 15 days any changes that materially
affect its: Legal, commercial, organizational, or ownership status;
organization and management including key testing personnel; policies
or procedures; location; personnel, facilities, working environment or
other resources; ONC authorized representative (point of contact); or
other such matters that may otherwise materially affect its ability to
test health IT;
Allow ONC, or its authorized agent(s), to periodically
observe on site (unannounced or scheduled), during normal business
hours, any testing performed pursuant to the Program;
Consistent with the revisions recently adopted in the 2015
Edition final rule, to retain all records related to the testing of
Complete EHRs and/or Health IT Modules to an edition of certification
criteria for a minimum of three years from the effective date that
removes the applicable edition from the Code of Federal Regulations;
and to make the records available to HHS upon request during the
retention period;
Only test health IT (Complete EHRs and Health IT Modules)
using test tools and test procedures approved by the National
Coordinator; and
Promptly refund any and all fees received for: Requests
for testing while its operations are suspended by the National
Coordinator; testing that will not be completed as a result of its
conduct; and previous testing that it performed if its conduct
necessitates the retesting of Complete EHRs and/or Health IT Modules.
(9) Proposed Amendments to Sec. 170.525 Application Submission
To clearly recognize that testing labs would be applying for ONC-
ATL status, we propose to include reference to an applicant for ONC-ATL
status in paragraphs (a) and (b) of Sec. 170.525 and to have the same
rules that currently apply to applicants for ONC-ACB status apply to
applicants for ONC-ATL status.
(10) Proposed Amendments to Sec. 170.530 Review of Application
We propose to revise paragraphs (c)(2), (c)(4), (d)(2), and (d)(3)
of Sec. 170.530 to equally reference that an ONC-ATL could be part of
the application review process. Further, in so doing, we propose to
follow all of the same application review steps and processes that we
currently follow for applicants for ONC-ACB status.
(11) Proposed Amendments to Sec. 170.535 ONC-ACB Application
Reconsideration
We propose to revise this section's heading to include reference to
ONC-ATLs. Additionally, we propose to revise paragraphs (a) and (d)(1)
of Sec. 170.535 to equally reference that an ONC-ATL could be part of
the application reconsideration process. Further, in so doing, we
propose to follow all of the same application reconsideration steps and
processes that we currently require and follow for applicants for ONC-
ACB status.
(12) Proposed Amendments to Sec. 170.540 ONC-ACB Status
We propose to revise this section's heading to include reference to
ONC-ATLs. Additionally, we propose to revise paragraphs (a) through (d)
of Sec. 170.540 to equally reference an ONC-ATL as part of the rules
currently governing the achievement of ONC-ACB status. These rules
would include: The acknowledgement of ONC-ATL status; that the ONC-ATL
must prominently and unambiguously identify the scope of its
authorization; that ONC-ATL authorization must be renewed every three
(3) years; and the expiration of ONC-ATL status (3 years from when it
was granted unless renewed).
(13) Proposed Amendments to Sec. 170.557 Authorized Certification
Methods
We propose to revise this section's heading to include a reference
to ``testing.'' Additionally, we propose to update the regulatory text
hierarchy to have paragraph (a) be applicable to ONC-ATLs and paragraph
(b) be applicable to ONC-ACBs. We have included this proposal for ONC-
ATLs because we believe the requirement to provide for remote testing
for both development and deployment sites is equally applicable to
testing labs as it is to certification bodies.
(14) Proposed Amendments to Sec. 170.560 Good Standing as an ONC-ACB
We propose to revise this section's heading to include reference to
ONC-ATLs. Additionally, we propose to revise the paragraph hierarchy to
make
[[Page 11070]]
the paragraph (a) requirements applicable to ONC-ACBs (without
modification) and to make the paragraph (b) requirements applicable to
ONC-ATLs following the same set of three requirements as for ONC-ACBs.
We believe mirroring these requirements between ONC-ACBs and ONC-ATLs
provides for consistent administration for both testing and
certification under the Program.
(15) Proposed Amendments to Sec. 170.565 Revocation of ONC-ACB Status
We propose to revise this section's heading to include reference to
ONC-ATLs. Additionally, we propose to revise paragraphs (a) through (h)
to include references to an ONC-ATL as applicable. We propose to apply
the same oversight paradigm of Type-1 and Type-2 \7\ violations to ONC-
ATLs as we apply to ONC-ACBs today. Further, we propose to follow the
same process for ONC-ATLs as already included in this section for ONC-
ACBs. We believe this consistency would enable ONC to treat similar
fact-based non-compliance situations equitably among ONC-ACBs and ONC-
ATLs. We propose to specifically add paragraph (d)(1)(iii) for ONC-ATL
suspension provisions because the suspension provisions in paragraph
(d)(1)(ii) are too specific to ONC-ACBs and certification and simply
referencing ONC-ATLs in that paragraph would cause confusion.
Similarly, we propose to specifically add paragraph (h)(3) related to
the extent and duration of revocation to clearly divide the rules
applicable to ONC-ACBs from those that are applicable to ONC-ATLs. This
proposed revision would place the current ONC-ACB applicable regulation
text in proposed paragraph (h)(2).
---------------------------------------------------------------------------
\7\ Type-2 violations constitute non-compliance with 45 CFR
170.560 (Good standing as an ONC-ACB) (45 CFR 170.565(b)). An ONC-
ACB must maintain good standing by: (a) Adhering to the Principles
of Proper Conduct for ONC-ACBs; (b) Refraining from engaging in
other types of inappropriate behavior, including an ONC-ACB
misrepresenting the scope of its authorization, as well as an ONC-
ACB certifying Complete EHRs and/or Health IT Module(s) for which it
does not have authorization; and (c) Following all other applicable
Federal and State laws.
---------------------------------------------------------------------------
(16) Request for Comment on Sec. 170.570 in the Context of an ONC-
ATL's Status Being Revoked
Section 170.570 discusses the general rule applicable to
certifications issued to Complete EHRs and/or Health IT Modules in the
event that an ONC-ACB has had its status revoked. It also includes
specific steps that the National Coordinator can follow if a Type-1
violation occurred that called into question the legitimacy of
certifications conducted by the former ONC-ACB. These provisions were
specifically put in place to provide clarity to the market about the
impact that an ONC-ACB's status revocation would have on certified
health IT in use as part of the EHR Incentive Programs.
In the context of an ONC-ATL having its status revoked, we have not
specifically proposed to modify Sec. 170.570 to include a set of rules
applicable to such a scenario. In large part, we do not believe that
the same provisions are necessary given the tangible differences
between test results for a not yet certified product and an issued
certification being used by hundreds or thousands of providers for
participation in other programs, HHS or otherwise. We do, however,
request comment, whether there would be any circumstances in which
additional clarity around the viability of test results attributed to a
not yet certified product would be necessary. Additionally, we request
comment as to whether we should include provisions similar to those
already in this section to account for an instance where an ONC-ATL has
its status revoked as a result of a Type-1 violation, which calls into
question the legitimacy of the test results the ONC-ATL issued and,
thus, could call into question the legitimacy of the subsequent
certifications issued to products by a potentially unknowing or
deceived ONC-ACB.
B. Public Availability of Identifiable Surveillance Results
In the 2014 Edition final rule, for the purposes of increased
Program transparency, we instituted a requirement for the public
posting of the test results used to certify health IT (77 FR 54271). We
also instituted a requirement that a health IT developer publicly
disclose any additional types of costs that a provider would incur for
using the health IT developer's certified health IT to participate in
the EHR Incentive Programs (77 FR 54273-74). Building on these
transparency and public accountability requirements for health IT
developers, in the 2015 Edition final rule, we took steps to increase
the transparency related to certified health IT through surveillance,
disclosure, and reporting requirements. For instance, we now require
ONC-ACBs to report corrective action plans and related data to the
publicly accessible CHPL. The purpose of this reporting requirement, as
described in the 2015 Edition final rule, was to ensure that health IT
users, implementers, and purchasers are alerted to potential
conformance issues in a timely and effective manner, consistent with
the patient safety, program integrity, and transparency objectives of
the 2015 Edition final rule.
In furtherance of our efforts to increase Program transparency and
health IT developer accountability for their certified health IT, we
propose to require ONC-ACBs to publicly publish on their Web sites
identifiable surveillance results on a quarterly basis. These
surveillance results would include information such as, but may not be
limited to: Names of health IT developers; names of products and
versions; certification criteria and Program requirements surveilled;
and outcomes of surveillance. This information is already collected by
ONC-ACBs as part of their surveillance efforts under the Program and
should be readily available for posting on their Web sites.
The publication of identifiable surveillance results, much like the
publication of corrective action plans on the CHPL, would hold health
IT developers more accountable to the customers and users of their
certified health IT. Customers and users would be provided with
valuable information about the continued performance of certified
health IT as well as surveillance efforts. To elaborate, identifiable
surveillance results would serve to inform providers currently using
certified health IT as well as those that may consider switching their
certified health IT or purchasing certified health IT for the first
time. While we expect that the prospect of publicly identifiable
surveillance results would motivate some health IT developers to
improve their maintenance efforts, we believe that most published
surveillance results would reassure customers and users of certified
health IT. This is because, based on ONC-ACB surveillance results to
date, most certified health IT and health IT developers are maintaining
conformance with certification criteria and Program requirements. The
publishing of such ``positive'' surveillance results would also provide
a more complete context of surveillance; rather than only sharing
``negatives,'' such as non-conformities and corrective action plans.
We make clear that we do not propose to require that publicly
posted surveillance results include certain information that is
proprietary, trade secret, or confidential (e.g., ``screenshots'' that
may include such information). We expect health IT developers and ONC-
ACBs to ensure that such information is not posted when making
available the information
[[Page 11071]]
we propose would be required to be posted as noted above (i.e., but not
limited to, names of health IT developers; names of products and
versions; certification criteria and Program requirements surveilled;
and outcomes of surveillance).
We request public comment on the publication of identifiable
surveillance results. Specifically, we request comment on the types of
information to include in the surveillance results and the format
(e.g., summarized or unrefined surveillance results) that would be most
useful to stakeholders. In addition to the proposal for ONC-ACBs to
publish these results quarterly on their Web sites, we request comment
on the value of publishing hyperlinks on the ONC Web site to the
results on the ONC-ACBs' Web sites. This may provide stakeholders with
a more readily available means for accessing all the results.
To implement the proposed new requirement, we propose to revise
Sec. 170.523(i) of the PoPC for ONC-ACBs by adding language that
requires ONC-ACBs to make identifiable surveillance results publicly
available on their Web sites on a quarterly basis. We also propose to
revise Sec. 170.556(e)(1) for clarity and consistency with Sec.
170.523(i)(2) by adding that the ongoing submission of in-the-field
surveillance results to the National Coordinator throughout the
calendar year must, at a minimum, be done on a quarterly basis.
Further, we propose to reestablish a requirement that ONC-ACBs submit
an annual summative report of surveillance results to the National
Coordinator. This previous requirement was unintentionally removed in
the 2015 Edition final rule when we established a quarterly reporting
requirement for surveillance results. Summative reports provide
comprehensive summaries of the surveillance conducted throughout the
year.
III. National Technology Transfer and Advancement Act
The National Technology Transfer and Advancement Act (NTTAA) of
1995 (15 U.S.C. 3701 et seq.) and the Office of Management and Budget
(OMB) Circular A-119 \8\ require the use of, wherever practical,
standards that are developed or adopted by voluntary consensus
standards bodies to carry out policy objectives or activities, with
certain exceptions. In this proposed rule, we propose to adopt one
voluntary consensus standard (ISO 17025).
---------------------------------------------------------------------------
\8\ https://www.whitehouse.gov/omb/circulars_a119.
---------------------------------------------------------------------------
IV. Incorporation by Reference
The Office of the Federal Register has established requirements for
materials (e.g., standards and implementation specifications) that
agencies propose to incorporate by reference in the Federal Register
(79 FR 66267; 1 CFR 51.5(a)). Specifically, Sec. 51.5(a) requires
agencies to discuss, in the preamble of a proposed rule, the ways that
the materials it proposes to incorporate by reference are reasonably
available to interested parties or how it worked to make those
materials reasonably available to interested parties; and summarize, in
the preamble of the proposed rule, the material it proposes to
incorporate by reference. To make the materials we intend to
incorporate by reference reasonably available, we provide a uniform
resource locator (URL) to the standard. The standard must be purchased
to obtain access. Alternatively, a copy of the standard may be viewed
for free at the U.S. Department of Health and Human Services, Office of
the National Coordinator for Health Information Technology, 330 C
Street SW., Washington, DC 20201. Please call (202) 690-7171 in advance
to arrange inspection. As required by Sec. 51.5(a), we also provide a
summary of the standard we propose to adopt and subsequently
incorporate by reference in the Federal Register.
ISO/IEC 17025:2005 General requirements for the competence of
testing and calibration laboratories.
URL: ISO/IEC 17025:2005 (ISO 17025) is available for purchase on
the ISO Web site at: https://www.iso.org/iso/catalogue_detail.htm?csnumber=39883.
Summary: Accreditation bodies that recognize the competence of
testing and calibration laboratories should use ISO 17025 as the basis
for their accreditation. Clause 4 specifies the requirements for sound
management. Clause 5 specifies the requirements for technical
competence for the type of tests and/or calibrations the laboratory
undertakes.
The use of ISO 17025 will facilitate cooperation between
laboratories and other bodies, and assist in the exchange of
information and experience, and in the harmonization of standards and
procedures.
V. Response to Comments
Because of the large number of public comments normally received in
response to Federal Register documents, we are not able to acknowledge
or respond to them individually. We will consider all comments we
receive by the date and time specified in the DATES section of this
preamble, and, when we proceed with a subsequent document, we will
respond to the comments in the preamble of that document.
VI. Collection of Information Requirements
Under the Paperwork Reduction Act of 1995 (PRA), agencies are
required to provide 60-day notice in the Federal Register and solicit
public comment on a proposed collection of information before it is
submitted to OMB for review and approval. In order to fairly evaluate
whether an information collection should be approved by the OMB,
section 3506(c)(2)(A) of the PRA requires that we solicit comment on
the following issues:
1. Whether the information collection is necessary and useful to
carry out the proper functions of the agency;
2. The accuracy of the agency's estimate of the information
collection burden;
3. The quality, utility, and clarity of the information to be
collected; and
4. Recommendations to minimize the information collection burden on
the affected public, including automated collection techniques.
A. ONC-AA and ONC-ACBs
Under the ONC Health IT Certification Program, accreditation
organizations that wish to become the ONC-Approved Accreditor (ONC-AA)
must submit certain information, organizations that wish to become an
ONC-ACB must comply with collection and reporting requirements, and
ONC-ACBs must comply with collection and reporting requirements,
records retention requirements, and submit annual surveillance plans
and annually report surveillance results. In the 2015 Edition proposed
rule (80 FR 16894), we estimated less than ten annual respondents for
all of the regulatory ``collection of information'' requirements that
applied to the ONC-AA and ONC-ACBs, including those previously approved
by OMB. In the 2015 Edition final rule (80 FR 62733), we concluded that
the regulatory ``collection of information'' requirements for the ONC-
AA and the ONC-ACBs were not subject to the PRA under 5 CFR 1320.3(c).
We further note that the PRA (44 U.S.C. 3518(c)(1)(B)(ii)) exempts the
information collections specified in 45 CFR 170.565 that apply to ONC-
ACBs, which are collection activities that would occur during
administrative actions or investigations involving ONC against an ONC-
ACB.
[[Page 11072]]
B. ONC-ATLs
We estimate less than ten annual respondents for all of the
proposed regulatory ``collection of information'' requirements for ONC-
ATLs under Part 170 of Title 45. Accordingly, the regulatory
``collection of information'' requirements under the Program described
in this section are not subject to the PRA under 5 CFR 1320.3(c). We
further note that the PRA (44 U.S.C. 3518(c)(1)(B)(ii)) exempts the
information collections specified in 45 CFR 170.565 that apply to ONC-
ATLs, which are collection activities that would occur during
administrative actions or investigations involving ONC against an ONC-
ATL.
Since the establishment of the Program in 2010, there have never
been more than six applicants or entities selected for ONC-ATCB or
accredited testing lab status. We anticipate that there will be no more
than eight ONC-ATLs participating in the Program. There are currently
only five accredited testing labs under the Program. We estimate that
up to three more testing labs may consider becoming accredited and seek
ONC-ATL status because of our proposal to permit granting ONC-ATL
status to an accredited testing lab for the testing of health IT to one
certification criterion or only a partial certification criterion.
We welcome comments on these conclusions and the supporting
rationale on which they are based.
The specific ``collection of information'' requirements that apply
to ONC-ATLs are found in Sec. 170.520(b); proposed Sec. 170.524(d)
and (f); and Sec. 170.540(c). We have estimated the burden hours for
these requirements in case our conclusions above are found to be
misguided based on public comments or other reasons. Our estimates for
the total burden hours are expressed in the table below. The estimated
total burden hours are based on an estimated five respondents (ONC-
ATLs) for the reasons noted above. With similar requirements to ONC-
ACBs, we estimate the same number of burden hours for ONC-ATLs to
comply with Sec. Sec. 170.520(b) and 170.540(c) as cited in the 2015
Edition proposed rule (80 FR 16894). We also make the same
determination for ONC-ATL records retention requirements under proposed
Sec. 170.524(f) as we did for the ONC-ACB records retention
requirements (i.e., no burden hours) (80 FR 16894). We have estimated
two responses per year at one hour per response for ONC-ATLs to provide
updated contact information to ONC per Sec. 170.524(d). We welcome
comments on our burden hour estimates. We also welcome comments on the
estimated costs associated with these proposed collection of
information requirements, which can be found in section VII
(``Regulatory Impact Statement'') of this preamble.
Estimated Annualized Total Burden Hours
--------------------------------------------------------------------------------------------------------------------------------------------------------
Number of Average burden
Type of respondent Code of federal regulations section Number of responses per hours per Total burden
respondents respondent response hours
--------------------------------------------------------------------------------------------------------------------------------------------------------
ONC-ATL....................................... 45 CFR 170.520(b)....................... 8 1 1 8
ONC-ATL....................................... 45 CFR 170.524(d)....................... 8 2 1 16
ONC-ATL....................................... 45 CFR 170.524(f)....................... 8 n/a n/a n/a
ONC-ATL....................................... 45 CFR 170.540(c)....................... 8 1 1 8
rrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr
Total burden hours for all collections of ........................................ .............. .............. .............. 32
information.
--------------------------------------------------------------------------------------------------------------------------------------------------------
C. Health IT Developers
We propose in 45 CFR 170.580 that a health IT developer would have
to submit certain information to ONC as part of a review of the health
IT developer's certified health IT and if ONC took action against the
certified health IT (e.g., requiring a corrective action plan to
correct a non-conformity or suspending or terminating a certification
for a Complete EHR or Health IT Module). The PRA, however, exempts
these information collections. Specifically, 44 U.S.C.
3518(c)(1)(B)(ii) excludes collection activities during the conduct of
administrative actions or investigations involving the agency against
specific individuals or entities.
VII. Regulatory Impact Statement
A. Statement of Need
The proposed rule proposes to establish processes for ONC to expand
its role to directly review health IT certified under the Program and
take action when necessary, including requiring the correction of non-
conformities found in health IT certified under the Program and
suspending and terminating certifications issued to Complete EHRs and
Health IT Modules. These processes would serve to address non-
conformities, particularly those that may pose a risk to public health
or safety or create other exigent circumstances that are inconsistent
with section 3001(b) of the PHSA. The Program does not currently have
regulatory means for reviewing and addressing such non-conformities and
reliance on ONC-ACBs is not appropriate due to their limited scope of
responsibilities, expertise, and resources. Therefore, we propose to
establish processes for ONC to address these situations.
The proposed rule also proposes processes for ONC to timely and
directly address testing issues. These processes do not exist today
under the current Program structure, particularly as compared to ONC's
oversight of ONC-ACBs. In addition, the proposed rule includes a
provision for the increased transparency and availability of
identifiable surveillance results. The publication of identifiable
surveillance results would support further accountability of health IT
developers to their customers and users of certified health IT.
B. Alternatives Considered
We assessed alternatives to our proposed approaches for enhanced
oversight by ONC described in this proposed rule (i.e., the direct
review of certified health IT and the authorization and oversight of
accredited testing labs (ONC-ATLs)). One less stringent alternative
would be to maintain our current approach for the Program in which ONC-
ACBs have sole responsibility for issuing and administering
certifications in accordance with ISO 17065, the PoPC for ONC-ACBs, and
other requirements of the Program. This approach would also leave the
testing structure as it currently exists. A second more stringent
alternative to what we proposed would be for ONC to take further
responsibility for the testing, certification, and ongoing compliance
of
[[Page 11073]]
health IT with Program requirements by making testing and certification
determinations and/or reviewing all determinations made under the
Program. We believe either approach would be misguided.
The current approach would leave no means for ONC to address non-
conformities in certified health IT that are contrary to the National
Coordinator's responsibilities under section 3001(b) of the PHSA and,
as discussed in this proposed rule, ONC-ACBs are not situated to
address these types of non-conformities. If we did not change the
current testing structure, a lack of parity in ONC oversight for
testing and certification would continue to exist. ONC direct oversight
of ONC-ATLs would ensure that, like with ONC-ACBs, testing labs are
directly and immediately accountable to ONC for their performance
across a variety of Program items that affect the testing of health IT.
Accordingly, and for the reasons outlined in this proposed rule, we do
not believe maintaining the Program as currently structured is
acceptable.
We fully considered the Program structure when establishing the
Program and have made appropriate modifications as the Program has
evolved (see the discussion in section I.A of this preamble for a
summary of rulemaking related to the Program and citations for the
relevant rules). These past considerations primarily focused on a
market-driven approach for the Program with testing and certification
conducted on behalf of ONC and with ONC retaining and establishing
direct and indirect oversight over certain activities. As discussed in
this proposed rule, ONC-ACBs play an integral role in the Program and
have the necessary expertise and capacity to effectively administer
specific Program requirements. Accredited testing labs also play an
integral role in the Program's success through the testing of health
IT. Our proposals in this proposed rule align with past considerations
and would only serve to enhance the Program by providing more
consistency and accountability for Program participants, which would
provide greater confidence in certified health IT when it is
implemented, maintained, and used.
We welcome comments on our assessment of alternatives and any
alternatives that we should also consider.
C. Overall Impact
We have examined the impact of this proposed rule as required by
Executive Order 12866 on Regulatory Planning and Review (September 30,
1993), Executive Order 13563 on Improving Regulation and Regulatory
Review (February 2, 2011), the Regulatory Flexibility Act (5 U.S.C. 601
et seq.), section 202 of the Unfunded Mandates Reform Act of 1995 (2
U.S.C. 1532), and Executive Order 13132 on Federalism (August 4, 1999).
1. Executive Orders 12866 and 13563--Regulatory Planning and Review
Analysis
Executive Orders 12866 and 13563 direct agencies to assess all
costs and benefits of available regulatory alternatives and, if
regulation is necessary, to select regulatory approaches that maximize
net benefits (including potential economic, environmental, public
health and safety effects, distributive impacts, and equity). A
regulatory impact analysis (RIA) must be prepared for major rules with
economically significant effects ($100 million or more in any one
year). OMB has determined that this proposed rule is an economically
significant rule as the potential costs associated with this proposed
rule could be greater than $100 million per year. Accordingly, we have
prepared an RIA that to the best of our ability presents the costs and
benefits of the proposed rule.
a. Costs
We estimated the potential monetary costs of this proposed rule for
health IT developers, ONC-ATLs, the Federal government (i.e., ONC), and
health care providers as follows: (1) Costs for health IT developers to
correct non-conformities identified by ONC; (2) costs for ONC and
health IT developers related to ONC review and inquiry into certified
health IT non-conformities; (3) costs to health IT developers and ONC
associated with the proposed appeal process following a suspension/
termination of a Complete EHR's or Health IT Module's certification;
(4) costs to health care providers to transition to another certified
health IT product when the certification of a Complete EHR or Health IT
Module that they currently use is terminated; (5) costs for ONC-ATLs
and ONC associated with ONC-ATL accreditation, application, renewal,
and reporting requirements; (6) costs for ONC-ATLs and ONC related to
revoking ONC-ATL status; and (7) costs for ONC-ACBs to publicly post
identifiable surveillance results. We also provide an overall annual
monetary cost estimate for this proposed rule (see (8) Total Annual
Cost Estimate). We note that we have rounded all estimates to the
nearest dollar and all estimates are expressed in 2016 dollars.
We have made employee assumptions about the level of expertise
needed to complete the proposed requirements in this section. We have
correlated that expertise with the corresponding grade and step of an
employee classified under the General Schedule Federal Salary
Classification, relying on the associated employee hourly rates for the
Washington, DC locality pay area as published by the Office of
Personnel Management. We have assumed that an applicant expends one
hundred percent (100%) of an employee's hourly wage on benefits for the
employee. Therefore, we have doubled the employee's hourly wage to
account for benefits. We have concluded that a 100% expenditure on
benefits is an appropriate estimate based on research conducted by HHS.
We have used the General Schedule Federal Salary Classification for
private sector employee wage calculations because the majority of the
proposed tasks and requirements that would be performed by private
sector employees do not easily fall within a particular occupational
classification identified by the Bureau of Labor Statistics (BLS). For
instance, while we estimate costs for specialized testing labs
personnel to support accreditation, we also estimate costs for
participating in administrative reviews and appeals and reporting
certain information to ONC. As noted above, in all instances, we
correlated the expertise needed to complete the task or requirement
with the corresponding grade and step of a federal employee classified
under the General Schedule Federal Salary Classification.
We welcome comments on our methodology for estimating employee
costs, including whether there are appropriate BLS occupational
classifications and wages that we should instead use to estimate
employee costs and the costs of the tasks and requirements proposed in
this proposed rule.
(1) Costs for Health IT Developers To Correct a Non-Conformity
Identified by ONC
We do not believe health IT developers face additional direct costs
for the proposed ONC direct review of certified health IT, including
the National Coordinator fulfilling the responsibilities of section
3001(b) of the PHSA. There are no new certification requirements
proposed in this proposed rule. Health IT developers have already been
certified to applicable certification criteria and other Program
requirements. Further, health IT developers should already be ensuring
that their certified
[[Page 11074]]
health IT is not, for example, creating public health and/or safety
issues by causing medical errors or leaving a patient's health
information unprotected in violation of applicable law (e.g., in
violation of the Health Insurance Portability and Accountability Act).
However, we acknowledge that this proposed rule may: (1) Lead health IT
developers to reassess whether their certified health IT is conformant;
and (2) require health IT developers to correct non-conformities found
by ONC in their certified health IT.
We have been unable to estimate the costs for health IT developers
to reassess their certified health IT for any non-conformities due to,
but not limited to, the variability of health IT developers' certified
technologies, current conformance, quality management systems,
implementation of certified health IT, and resources. Additionally, we
are not aware of relevant data or methodology we could use to estimate
these costs. We do not, however, anticipate that this reassessment
would result in substantial costs to health IT developers because
health IT developers should have means for routinely evaluating their
certified health IT for potential issues. We welcome comment on
relevant data and methods we could use to estimate these costs.
If ONC identifies a non-conformity with a health IT developer's
certified health IT, the costs incurred by the health IT developer to
bring the product into conformance would be determined on a case-by-
case basis. If ONC found a non-conformity with a certified capability
related to a certification criterion, then the costs are not truly a
result of this proposed rule because a health IT developer's product
should remain conformant to those criteria and the costs to meet
certification criteria were previously estimated in the 2014 Edition
final rule and the 2015 Edition final rule. Alternatively, ONC could
find either that certified health IT is causing medical errors or
contributing to a patient's health information being unsecured and
unprotected in violation of applicable law. In either instance, the
monetary costs to correct the non-conformity would likely vary
significantly based on factors such as the cause of the non-conformity
and how easily it could be corrected. We are unable to reliably
estimate these costs as we do not have cost estimates for a comparable
situation. We request comment on existing relevant data and methods we
could use to estimate these costs.
(2) Costs for ONC and Health IT Developers Related to ONC Review and
Inquiry Into Certified Health IT Non-Conformities
ONC would have broad discretion to review certified health IT.
However, we anticipate that such review would be relatively infrequent
and would focus on situations that pose a risk to public health or
safety. We estimate that a health IT developer may commit, on average
and depending on complexity, between 80 and 400 hours of staff time to
provide ONC with all requested records and documentation that ONC would
use to make a suspension and/or termination determination. We assume
that the expertise of the employee(s) needed to comply with ONC's
requests would be equivalent to a GS-15, Step 1 federal employee. The
hourly wage with benefits for a GS-15, Step 1 employee located in
Washington, DC is approximately $122.74. Therefore, we estimate the
cost for a health IT developer to cooperate with an ONC review and
inquiry into certified health IT would, on average, range from $9,819
to $49,096. We note that some health IT developers' costs are expected
to be less and some health IT developers' costs are expected to be more
than this estimated cost range.
We estimate that ONC may commit, on average and depending on
complexity, between 20 and 600 hours of staff time to complete a review
and inquiry into certified health IT. We assume that the expertise of a
GS-15, Step 1 federal employee(s) would be necessary. Therefore, we
estimate the cost for ONC to review and conduct an inquiry into
certified health IT would, on average, range from $2,455 to $73,644. We
note that some reviews and inquiries may cost less and some may cost
more than this estimated cost range.
We welcome comment on our estimated costs and any comparable
processes and costs that we could use to improve our cost estimates. We
intend to continue to conduct fact-finding in an effort to provide more
reliable cost estimates in a subsequent final rule.
(3) Costs to Health IT Developers and ONC Associated With the Proposed
Appeal Process Following a Suspension/Termination of a Complete EHR's
or Health IT Module's Certification
As discussed in section II.A.1.c.(5) of this preamble, we propose
in Sec. 170.580(f) to permit a health IT developer to appeal an ONC
determination to suspend or terminate a certification issued to a
Complete EHR or Health IT Module. We estimate that a health IT
developer may commit, on average and depending on complexity, between
80 to 240 hours of staff time to provide the required information to
appeal a suspension or termination and respond to any requests from the
hearing officer. We assume that the expertise of the employee(s) needed
to participate in the appeal would be equivalent to a GS-15, Step 1
federal employee. The hourly wage with benefits for a GS-15, Step 1
employee located in Washington, DC is approximately $122.74. Therefore,
we estimate the cost for a health IT developer to appeal a suspension
or termination would, on average, range from $9,819 to $29,458. We note
that some health IT developers' costs are expected to be less and some
health IT developers' costs are expected to be more than this estimated
cost range.
We estimate that ONC would commit, on average and depending on
complexity, between 200 and 800 hours of staff time to conduct an
appeal. This would include the time to represent ONC in the appeal and
support the costs for the hearing officer. We assume that the expertise
of a GS-15, Step 1 federal employee(s) would be necessary. Therefore,
we estimate the cost for ONC to conduct an appeal would, on average,
range from $24,548 to $98,192. We note that some appeals may cost less
and some may cost more than this estimated cost range.
We welcome comment on our estimated costs and any comparable
processes and costs that we could use to improve our cost estimates. We
intend to continue to conduct fact-finding in an effort to provide more
reliable cost estimates in a subsequent final rule.
(4) Costs to Health Care Providers To Transition to Another Certified
Health IT Product When the Certification of a Complete EHR or Health IT
Module That They Currently Use Is Terminated
This cost analysis with regards to health care providers focuses on
the direct effects of the termination of a Complete EHR's or Health IT
Module's certification under this proposed rule's provisions as a
certification termination would have the greatest potential impact. We
note and emphasize that the estimated costs for health care providers
as a result of a certification termination could be incurred absent the
proposals in this proposed rule. ONC-ACBs currently have the authority
to terminate (and suspend) the certifications of Complete EHRs and
Health IT Modules. In this regard, ONC-ACBs have terminated
certifications for both Complete EHRs and Health IT Modules.
[[Page 11075]]
The most recent termination of a certification by an ONC-ACB
occurred in September 2015 when the certifications of a health IT
developer's Complete EHRs and Health IT Modules were terminated for
failure to respond and participate in routine surveillance requests.\9\
Only 48 eligible professionals (EPs) attested under the Medicare EHR
Incentive Program to using these products. In April 2013, an ONC-ACB
terminated the certifications of Complete EHRs and Health IT Modules
because they did not meet the required functionality.\10\ Those health
IT products had no Medicare attestations. Considering that these are
the only terminations and impacts over the five years of the Program
and consistent with our stated intent in this proposed rule to work
with health IT developers to correct non-conformities found in their
certified health IT under the provisions in this proposed rule, it is
highly unlikely that the high end of our estimated costs for health
care providers would ever be realized.
---------------------------------------------------------------------------
\9\ https://www.hhs.gov/news/press/2015pres/09/20150902c.html.
\10\ https://www.hhs.gov/about/news/2013/04/25/certification-for-electronic-health-record-product-revoked.html.
---------------------------------------------------------------------------
We estimated the monetary costs that would be sustained by health
care providers to transition to another certified health IT product
when the certification of a Complete EHR or Health IT Module that they
currently use is terminated. We anticipate that health care providers
impacted by certification termination would transition to a new
certified health IT product due to eventually needing certified health
IT to participate in other HHS programs requiring the use of certified
health IT (e.g., the EHR Incentive Programs \11\). The estimated
upfront cost for health care providers is calculated using the number
of known EPs that report under the Medicare EHR Incentive Program using
certified Complete EHRs and certified Health IT Modules that would have
their certifications terminated multiplied by an estimated average cost
per product per provider to implement a new certified health IT
product. The estimated average cost per product per provider to
implement a new certified health IT product is approximately $33,000.
This estimation is consistent with other analyses on average costs.\12\
---------------------------------------------------------------------------
\11\ See CMS EHR Incentive Programs FAQ 12657: https://questions.cms.gov/faq.php?isDept=0&search=decertified&searchType=keyword&submitSearch=1&id=5005.
\12\ A Health Affairs study (https://content.healthaffairs.org/content/30/3/481.abstract) estimated the average cost for EHR
implementation at a five-physician practice as $162,000. Dividing by
five, the estimated cost per physician is $32,400, which is close to
our estimated cost of $33,000 to implement an in-office health IT
product.
---------------------------------------------------------------------------
This analysis and cost estimates do not include sunk costs during
the transition year, such as ongoing maintenance for the health IT
product that had its certification(s) terminated and any upfront costs
the provider paid for the health IT product. The transition by a health
care provider to a new health IT product could also include non-sunk
costs associated with unwinding contractual matters and technological
connectivity, replacement/implementation efforts, training of
workforce, and the potential for an operational shut down to effectuate
a transition to a replacement technology. In regard to contractual
matters we acknowledge that transitioning to a new certified health IT
product following a certification termination may be further
complicated by the fact that health care providers may have entered
multi-year transactions for a Complete EHR or Health IT Module(s).
These costs would likely vary significantly based on the contract and
specific situation. Conversely, unlike the cost categories just
mentioned, which would tend to make our estimates understate the costs
to providers due to a termination of certification, some aspects of
certified health IT implementation may be similar across products, thus
reducing the costs of transitioning to a new product below the costs
incurred in association with the original implementation.
We used the following formula to calculate the estimated upfront
costs for health care providers to transition to a new product:
1. Number of EPs reporting with a certified Complete EHR or certified
Health IT Module that could potentially have its certification
terminated
2. #1 multiplied by the average upfront cost per product per health
care provider
3. Result of #2 equals the estimated cost for health care providers to
replace the certified Complete EHR or certified Health IT Module
Applying this formula, we calculated the upper and lower threshold
impacts as well as the median and mean impacts of terminating
certifications issued to a Complete EHR or Health IT Module(s). The
upper and lower thresholds were calculated from the certified Complete
EHR and certified Health IT Modules with the greatest and least number
of reported attestations to the Medicare EHR Incentive Program
respectively.\13\ The median and mean impacts also were calculated
using the number of reported attestations for each product (see ``Cost
Impact to Health Care Providers'' table). We calculated the estimated
cost to those health care providers assuming all the health care
providers would transition to a new certified health IT product.
---------------------------------------------------------------------------
\13\ As of November 30, 2015.
Cost Impact to Health Care Providers
----------------------------------------------------------------------------------------------------------------
Lower Median Mean Upper
----------------------------------------------------------------------------------------------------------------
Number of EP Attestations....................... 1 24 190 19,692
Calculated Cost................................. $33,000 $792,000 $6,270,000 $649,836,000
----------------------------------------------------------------------------------------------------------------
We estimate the cost impact of certification termination on health
care providers would range from $33,000 to $649,836,000 with a median
cost of $792,000 and a mean cost of $6,270,000. We welcome comment on
our proposed approach and cost estimates as well as the identification
of any reliable data upon which we could base or revise our cost
estimates in a subsequent final rule.
We note that health IT developers may be required to pay for
transition costs of health care providers due to certification
termination. A complete presentation regarding who bears these costs is
excluded from our analysis because arrangements would vary by contract
and we do not have relevant data upon which to base an estimate.
[[Page 11076]]
(5) Costs for ONC-ATLs and ONC Associated With ONC-ATL Accreditation,
Application, Renewal, and Reporting Requirements
Costs for the Applicant/ONC-ATL
An applicant for ONC-ATL status would be required to submit an
application and must be accredited in order to be a qualified ONC-ATL
applicant. As specified in section VI.B of this preamble, we estimate
that there would be between five and eight applicants, five of which
are already accredited by NVLAP to ISO 17025 and up to three new
applicants. Any new applicants for ONC-ATL status under the Program
would first be required to become accredited by NVLAP to ISO 17025.
Based on our consultations with NIST, we estimate that it would
take approximately 2-5 days for NVLAP to complete a full scope on-site
assessment for all criteria required for accreditation at an
approximate cost of $11,000. The on-site assessment fee covers the
costs incurred by the assessors conducting the on-site assessment such
as preparation time, time on-site, and travel costs (e.g. flights,
hotel, meals, etc.). Proposed Sec. 170.511 would permit the
authorization of ONC-ATLs for testing to one or even a partial
certification criterion. Based on consultations with NIST, this would
take at least one day to complete and may reduce the necessary scope
and cost of the on-site assessment to approximately $8,000. The current
five accredited testing labs would each incur the full scope on-site
assessment fee of $11,000, as discussed below. We anticipate the
potential three new applicants would each incur a limited scope on-site
assessment fee of $8,000, as discussed below.
We estimate the applicant staff time necessary to prepare and
participate in the full scope on-site assessment at 200 hours, which is
consistent with the estimate we used for ONC-ACBs based on stakeholder
feedback (76 FR 1316). We estimate the applicant staff time necessary
to prepare and participate in the limited scope on-site assessment at
100 hours, which is half the estimate for the full scope on-site
assessment. We believe an employee equivalent to a GS-15, Step 1
federal employee would be responsible for preparation and participation
in the accreditation assessment. The hourly wage with benefits for a
GS-15, Step 1 employee located in Washington, DC is approximately
$122.74. Therefore, we estimate the applicant staff cost for the full
scope on-site assessment at $24,548 and the applicant staff cost for
the limited scope on-site assessment at $12,274.
We anticipate that ONC-ATLs would incur an estimated $5,000
accreditation administrative/technical support fee each year during the
three-year ONC-ATL authorization period.\14\ The accreditation
administrative/technical support fee covers costs associated with NVLAP
staff under the Program. On-site assessments are required prior to
initial accreditation, during the first renewal year, and every two
years thereafter. As such, we expect the potential three new applicants
would each incur the on-site assessment fee twice during their initial
three-year ONC-ATL authorization period and the current five accredited
testing labs would incur the on-site assessment fee once during the
same period. Further, as stated above, each full scope on-site
assessment for all criteria would cost approximately $11,000 and each
limited scope on-site assessment would cost approximately $8,000. We
estimate that staff expertise and cost for renewal is likely to remain
consistent at approximately $24,548 for a full scope on-site assessment
and $12,274 for a limited scope on-site assessment. We expect that each
ONC-ATL would renew its status, meaning it would request
reauthorization from ONC to be an ONC-ATL, every three years.
---------------------------------------------------------------------------
\14\ See NVLAP Fee Structure, https://www.nist.gov/nvlap/nvlap-fee-policy.cfm.
---------------------------------------------------------------------------
After becoming accredited by NVLAP, an applicant for ONC-ATL status
would incur minimal costs to prepare and submit an application to the
National Coordinator. We believe that it would take ten minutes to
provide the general information requested in the application, 30
minutes to assemble the information necessary to provide documentation
of accreditation by NVLAP, and 20 minutes to review and agree to the
PoPC for ONC-ATLs. We believe these time estimates would also be
accurate for an ONC-ATL to complete the proposed status renewal
process. Based on our consultations with NIST, we believe that an
employee equivalent to a GS-9, Step 1 federal employee could provide
the required general identifying information and documentation of
accreditation status. The hourly wage with benefits for a GS-9, Step 1
federal employee located in Washington, DC is approximately $51.20. We
believe that an employee equivalent to a GS-15, Step 1 federal employee
would be responsible for reviewing and agreeing to the PoPC for ONC-
ATLs. Therefore, our cost estimate per ONC-ATL for these activities is
$75.04.
Overall, we estimate that the total cost of ONC-ATL accreditation,
application, and the first proposed three-year authorization period
would be approximately $55,623 and the total cost for up to three new
applicants would be approximately $166,869. We assume that ONC-ATLs
would remain accredited during the three-year ONC-ATL authorization
period.
We estimate the total cost for an ONC-ATL to renew its
accreditation, application, and authorization during the first three-
year ONC-ATL authorization period to be approximately $50,623 and the
total renewal cost for all five current ONC-ATLs to be approximately
$253,115. Based on our cost estimate timeframe of three years, the
annualized renewal cost would be approximately $84,372.
We propose in Sec. 170.524(d) that ONC-ATLs shall report various
changes to their organization within 15 days. We believe an employee
equivalent to the Federal Salary Classification of GS-9, Step 1 could
complete the transmissions of the requested information to ONC. As
specified in section VI.B of this preamble, we estimate two responses
per year at one hour per response for ONC-ATLs to provide updated
information to ONC per Sec. 170.524(d). Accordingly, we estimate it
would cost each ONC-ATL $102.40 annually to meet this requirement. To
estimate the highest possible cost, we assume that the eight applicants
we estimate would apply to become ONC-ATLs would become ONC-ATLs.
Therefore, we estimate the total annual cost for ONC-ATLs to meet the
requirements of proposed Sec. 170.524(d) to be $819.
We propose in Sec. 170.524(f) that ONC-ATLs shall retain all
records related to the testing of Complete EHRs and Health IT Modules
to an edition of certification criteria for a minimum of three years
from the effective date that removed the applicable edition from the
Code of Federal Regulations. Based on our consultations with NIST, we
believe this time period is in line with common industry practices.
Consequently, it does not represent an additional cost to ONC-ATLs.
We welcome comments on our methodology and estimated costs.
Costs to ONC
We estimate the cost to develop the ONC-ATL application to be $522
based on the five hours of work we believe it would take a GS-14, Step
1 federal employee to develop an application form. The hourly wage with
benefits for a GS-14, Step 1 employee located in Washington, DC is
approximately $104.34. We also anticipate that there
[[Page 11077]]
would be costs associated with reviewing applications under the
Program. We expect that a GS-15, Step 1 federal employee would review
the applications and ONC (or a designated representative) would issue
final decisions on all applications. We anticipate that it would take
approximately 20 hours to review and reach a final decision on each
application. This estimate assumes a satisfactory application (i.e., no
formal deficiency notifications) and includes the time necessary to
verify the information in each application and prepare a briefing for
the National Coordinator. We estimate the cost for the application
review process to be $2,455. As a result, we estimate ONC's overall
cost of administering the entire application process to be
approximately $2,977. Based on our cost estimate timeframe of three
years, the annualized cost to ONC would be $992. These costs would be
the same for a new applicant or ONC-ATL renewal.
As proposed, we would also post the names of applicants granted
ONC-ATL status on our Web site. We believe there would be minimal cost
associated with this action and estimate the potential cost for posting
and maintaining the information on our Web site to be approximately
$446 annually. This amount is based on a maximum of six hours of work
for a GS-12, Step 1 federal employee. The hourly wage with benefits for
a GS-12 Step 1 federal employee located in Washington, DC is $74.
We believe there would be minimal cost associated with recording
and maintaining updates and changes reported by the ONC-ATLs. We
estimate an annual cost to the federal government of $743. This amount
is based on ten hours of yearly work of a GS-12, Step 1 federal
employee.
We welcome comments on our methodology and estimated costs.
(6) Costs for ONC-ATLs and ONC Related To Revoking ONC-ATL Status
As discussed in section II.A.2.b.(15) of this preamble, we propose
to revise Sec. 170.565 to apply the same process for ONC-ATL status
revocation as applies to ONC-ACBs. We estimate that an ONC-ATL may
commit, on average and depending on complexity, between 20 and 160
hours of staff time to provide responses and information requested by
ONC. We assume that the expertise of the employee(s) needed to comply
with ONC's requests would be equivalent to a GS-15, Step 1 federal
employee. The hourly wage with benefits for a GS-15, Step 1 employee
located in Washington, DC is approximately $122.74. Therefore, we
estimate the cost for an ONC-ATL to comply with ONC requests per Sec.
170.565 would, on average, range from $2,455 to $19,638. We note that
in some instances the costs may be less and in other instances the
costs may exceed this estimated cost range.
Costs to ONC
We estimate that ONC would commit, on average and depending on
complexity, between 40 and 320 hours of staff time to conducting
actions under Sec. 170.565 related to ONC-ATLs. We assume that the
expertise of a GS-15, Step 1 federal employee(s) would be necessary.
Therefore, we estimate the cost for ONC would, on average, range from
$4,910 to $39,277. We note that in some instances the costs may be less
and in other instances the costs may exceed this estimated cost range.
We welcome comment on our estimated costs and any comparable
processes and costs that we could use to improve our cost estimates. We
intend to continue to conduct fact-finding in an effort to provide more
reliable cost estimates in a subsequent final rule.
(7) Costs for ONC-ACBs To Publicly Post Identifiable Surveillance
Results
In section II.B of this preamble, we propose to require ONC-ACBs to
make identifiable surveillance results publicly available on their Web
sites on a quarterly basis. We believe that an employee equivalent to a
GS-9, Step 1 federal employee could post the surveillance results. We
believe it would take the employee no more than four hours annually to
prepare and post the surveillance results. The hourly wage with
benefits for a GS-9, Step 1 federal employee located in Washington, DC
is approximately $51.20. Therefore, we estimate the annual cost for
each ONC-ACB to post surveillance results to be $205 and the total cost
for all ONC-ACBs to be $615.
(8) Total Annual Cost Estimate
We estimate the total annual cost for this proposed rule, based on
the cost estimates outlined above, would range from $230,616 to
$650,288,915 with an average annual cost of $6,595,268.
b. Benefits
The proposed rule's provisions for ONC direct review of certified
health IT would promote health IT developers' accountability for the
performance, reliability, and safety of certified health IT; and
facilitate the use of safer and reliable health IT by health care
providers and patients. Specifically, ONC's direct review of certified
health IT would permit ONC to assess non-conformities and prescribe
comprehensive corrective actions for health IT developers to address
non-conformities, including notifying affected customers. As previously
stated, our first and foremost goal would be to work with health IT
developers to remedy any non-conformities with certified health IT in a
timely manner and across all customers. If ONC ultimately suspends and/
or terminates a certification issued to a Complete EHR or Health IT
Module under the proposals in this proposed rule, such action would
serve to protect the integrity of the Program and users of health IT.
While we do not have available means to quantify the benefits of ONC
direct review of certified health IT, we believe that ONC direct review
supports and enables the National Coordinator to fulfill his/her
responsibilities under the HITECT Act, instills public confidence in
the Program, and protects public health and safety.
The proposed rule's provisions would also provide other benefits.
The proposals for ONC to authorize and oversee testing labs (ONC-ATLs)
would facilitate further public confidence in testing and certification
by permitting ONC to timely and directly address testing issues for
health IT. The proposed public availability of identifiable
surveillance results would enhance transparency and the accountability
of health IT developers to their customers. This proposal would provide
customers and users of certified health IT with valuable information
about the continued performance of certified health IT as well as
surveillance efforts. Further, the public availability of identifiable
surveillance results would likely benefit health IT developers by
providing a more complete context of surveillance and illuminating good
performance and the continued compliance of certified health IT with
Program requirements. Again, while we do not have available means to
quantify these benefits, we believe these proposed approaches, if
finalized, would improve Program compliance and further public
confidence in certified health IT.
We welcome comment on potential means, methods, and relevant
comparative studies and data that we could use to quantify these
benefits. To note, we do not have data to establish how often we would
need to exercise direct review, the extent of existing and future non-
conformities, and the likely outcomes that would be achieved by ONC
review, including up to preventing the loss of life. Similarly, we do
not have data to establish that our proposals
[[Page 11078]]
for direct oversight of testing labs and the public availability of
identifiable surveillance results would actually result in greater
public confidence in certified health IT, including greater adoption of
certified health IT. We also welcome comment on other benefits,
quantifiable and non-quantifiable, which could be achieved through the
proposals we have put forth in this proposed rule.
2. Regulatory Flexibility Act
The Regulatory Flexibility Act (RFA) requires agencies to analyze
options for regulatory relief of small businesses if a rule has a
significant impact on a substantial number of small entities. The Small
Business Administration (SBA) establishes the size of small businesses
for federal government programs based on average annual receipts or the
average employment of a firm.\15\ The entities that are likely to be
directly affected by this proposed final rule are applicants for ONC-
ATL status and health IT developers.
---------------------------------------------------------------------------
\15\ The SBA references that annual receipts means ``total
income'' (or in the case of a sole proprietorship, ``gross income'')
plus ``cost of goods sold'' as these terms are defined and reported
on Internal Revenue Service tax return forms.
---------------------------------------------------------------------------
We estimate up to eight applicants for ONC-ATL status. These
applicants would be classified under the North American Industry
Classification System (NAICS) codes 541380 (Testing Laboratories)
specified at 13 CFR 121.201 where the SBA publishes ``Small Business
Size Standards by NAICS Industry.'' \16\ The SBA size standard
associated with this NAICS code is set at $15 million annual receipts
or less. As specified in section VII.C above, we estimate minimal costs
for applicants for ON-ATL status to apply and participate in the
Program as ONC-ATLs. We believe that we have proposed the minimum
amount of requirements necessary to accomplish our goal of enhanced
oversight of testing under the Program. As discussed under section
VII.B above, there are also no appropriate regulatory or non-regulatory
alternatives that could be developed to lessen the compliance burden
associated with this proposed rule. We further note that we expect all
of the estimated costs to be recouped by those applicants that become
ONC-ATLs through the fees they charge for testing health IT under the
Program.
---------------------------------------------------------------------------
\16\ https://www.sba.gov/sites/default/files/files/Size_Standards_Table.pdf
---------------------------------------------------------------------------
While health IT developers that pursue certification of their
health IT under the Program represent a small segment of the overall
information technology industry, we believe that many health IT
developers impacted by this proposed rule most likely fall under the
North American Industry Classification System (NAICS) code 541511
``Custom Computer Programming Services.'' \17\ The SBA size standard
associated with this NAICS code is set at $27.5 million annual receipts
or less. There is enough data generally available to establish that
between 75% and 90% of entities that are categorized under the NAICS
code 541511 are under the SBA size standard. We also note that with the
exception of aggregate business information available through the U.S.
Census Bureau and the SBA related to NAICS code 541511, it appears that
many health IT developers that pursue certification of their health IT
under the Program are privately held or owned and do not regularly, if
at all, make their specific annual receipts publicly available. As a
result, it is difficult to locate empirical data related to many of
these health IT developers to correlate to the SBA size standard.
However, although not perfectly correlated to the size standard for
NAICS code 541511, we do have information indicating that over 60% of
health IT developers that have had Complete EHRs and/or Health IT
Modules certified to the 2011 Edition have less than 51 employees.
---------------------------------------------------------------------------
\17\ https://www.sba.gov/sites/default/files/files/Size_Standards_Table.pdf
---------------------------------------------------------------------------
We estimate that this proposed rule would have effects on health IT
developers, some of which may be small entities, that have certified
health IT or are likely to pursue certification of their health IT
under the Program because health IT developers may need to reassess
their health IT to verify compliance with the Program requirements
outlined in this proposed rule and they may have their certified health
IT subjected to a corrective action, suspension, and/or termination
under the provisions of this proposed rule. We believe, however, that
we have proposed the minimum amount of requirements necessary to
accomplish our primary policy goals of enhancing Program oversight and
health IT developer accountability for the performance, reliability,
and safety of certified health IT. Further, as discussed under section
VII.B above, there are no appropriate regulatory or non-regulatory
alternatives that could be developed to lessen the compliance burden
associated with this proposed rule as this proposed rule places no new
requirements on health IT developers, unless their certified health IT
is reviewed by ONC and found to have a non-conformity.
We do not believe that the proposed rule would create a significant
impact on a substantial number of small entities, but request comment
on whether there are small entities that we have not identified that
may be affected in a significant way by this proposed rule.
Additionally, the Secretary proposes to certify that this proposed rule
would not have a significant impact on a substantial number of small
entities.
3. Executive Order 13132--Federalism
Executive Order 13132 establishes certain requirements that an
agency must meet when it promulgates a proposed rule (and subsequent
final rule) that imposes substantial direct requirement costs on state
and local governments, preempts state law, or otherwise has federalism
implications. Nothing in this proposed rule imposes substantial direct
compliance costs on state and local governments, preempts state law, or
otherwise has federalism implications. We are not aware of any state
laws or regulations that are contradicted or impeded by any of the
proposals in this proposed rule. We welcome comments on this
assessment.
4. Unfunded Mandates Reform Act of 1995
Section 202 of the Unfunded Mandates Reform Act of 1995 requires
that agencies assess anticipated costs and benefits before issuing any
rule that imposes unfunded mandates on state, local, and tribal
governments or the private sector requiring spending in any one year of
$100 million in 1995 dollars, updated annually for inflation. The
current inflation-adjusted statutory threshold is approximately $144
million. While the estimated potential cost effects of this proposed
rule reach the statutory threshold, we do not believe this proposed
rule imposes unfunded mandates on state, local, and tribal governments
or the private sector. As described under section VII.C.1 above, we
estimate the potential monetary costs for the private sector (health IT
developers and health care providers), which would be the result of a
health IT developer not maintaining its product(s) compliance with
voluntary Program requirements and having its product's certification
terminated. The minimal monetary cost estimates for ONC-ATLs derive
from voluntary participation in the Program and would be recouped
through fees charged for the testing of health IT under the Program. We
welcome comments on these conclusions.
OMB reviewed this proposed rule.
[[Page 11079]]
List of Subjects in 45 CFR Part 170
Computer technology, Electronic health record, Electronic
information system, Electronic transactions, Health, Health care,
Health information technology, Health insurance, Health records,
Hospitals, Incorporation by reference, Laboratories, Medicaid,
Medicare, Privacy, Reporting and recordkeeping requirements, Public
health, Security.
For the reasons set forth in the preamble, 45 CFR subtitle A,
subchapter D, part 170, is proposed to be amended as follows:
PART 170--HEALTH INFORMATION TECHNOLOGY STANDARDS, IMPLEMENTATION
SPECIFICATIONS, AND CERTIFICATION CRITERIA AND CERTIFICATION
PROGRAMS FOR HEALTH INFORMATION TECHNOLOGY
0
1. The authority citation for part 170 continues to read as follows:
Authority: 42 U.S.C. 300jj-11; 42 U.S.C. 300jj-14; 5 U.S.C.
552.
0
2. Amend Sec. 170.501 by revising paragraph (a) to read as follows:
Sec. 170.501 Applicability.
(a) This subpart establishes the processes that applicants for ONC-
ACB status must follow to be granted ONC-ACB status by the National
Coordinator; the processes the National Coordinator will follow when
assessing applicants and granting ONC-ACB status; the requirements that
ONC-ACBs must follow to maintain ONC-ACB status; and the requirements
of ONC-ACBs for certifying Complete EHRs, Health IT Module(s), and
other types of health IT in accordance with the applicable
certification criteria adopted by the Secretary in subpart C of this
part. It also establishes the processes that applicants for ONC-ATL
status must follow to be granted ONC-ATL status by the National
Coordinator; the processes the National Coordinator will follow when
assessing applicants and granting ONC-ATL status; the requirements that
ONC-ATLs must follow to maintain ONC-ATL status; and the requirements
of ONC-ATLs for testing Complete EHRs and Health IT Modules in
accordance with the applicable certification criteria adopted by the
Secretary in subpart C of this part. Further, this subpart establishes
the processes accreditation organizations must follow to request
approval from the National Coordinator and that the National
Coordinator in turn will follow to approve an accreditation
organization under the ONC Health IT Certification Program as well as
certain ongoing responsibilities for an ONC-AA.
* * * * *
0
3. Amend Sec. 170.502 by revising the definitions of ``Applicant'' and
``Gap certification'' and by adding the definition of ``ONC-Authorized
Testing Lab or ONC-ATL'' in alphabetical order to read as follows:
Sec. 170.502 Definitions.
* * * * *
Applicant means a single organization or a consortium of
organizations that seeks to become an ONC-ACB or ONC-ATL by submitting
an application to the National Coordinator for such status.
* * * * *
Gap certification means the certification of a previously certified
Complete EHR or Health IT Module(s) to:
(1) All applicable new and/or revised certification criteria
adopted by the Secretary at subpart C of this part based on test
results issued by a NVLAP-accredited testing laboratory under the ONC
Health IT Certification Program or an ONC-ATL; and
(2) All other applicable certification criteria adopted by the
Secretary at subpart C of this part based on the test results used to
previously certify the Complete EHR or Health IT Module(s) under the
ONC Health IT Certification Program.
* * * * *
ONC-Authorized Testing Lab or ONC-ATL means an organization or a
consortium of organizations that has applied to and been authorized by
the National Coordinator pursuant to this subpart to perform the
testing of Complete EHRs and Health IT Modules to certification
criteria adopted by the Secretary at subpart C of this part.
* * * * *
4. Revise Sec. 170.505 to read as follows:
Sec. 170.505 Correspondence.
(a) Correspondence and communication with ONC or the National
Coordinator shall be conducted by email, unless otherwise necessary or
specified. The official date of receipt of any email between ONC or the
National Coordinator and an accreditation organization requesting ONC-
AA status, the ONC-AA, an applicant for ONC-ACB status, an applicant
for ONC-ATL status, an ONC-ACB, an ONC-ATL, health IT developer, or a
party to any proceeding under this subpart is the date on which the
email was sent.
(b) In circumstances where it is necessary for an accreditation
organization requesting ONC-AA status, the ONC-AA, an applicant for
ONC-ACB status, an applicant for ONC-ATL status, an ONC-ACB, an ONC-
ATL, health IT developer, or a party to any proceeding under this
subpart to correspond or communicate with ONC or the National
Coordinator by regular or express mail, the official date of receipt
will be the date of the delivery confirmation.
0
5. Amend Sec. 170.510 by revising the section heading and introductory
text to read as follows:
Sec. 170.510 Authorization scope for ONC-ACB status.
Applicants for ONC-ACB status may seek authorization from the
National Coordinator to perform the following types of certification:
* * * * *
0
6. Add Sec. 170.511 to read as follows:
Sec. 170.511 Authorization scope for ONC-ATL status.
Applicants may seek authorization from the National Coordinator to
perform the testing of Complete EHRs or Health IT Modules to a portion
of a certification criterion, one certification criterion, or many or
all certification criteria adopted by the Secretary under subpart C of
this part.
0
7. Revise Sec. 170.520 to read as follows:
Sec. 170.520 Application.
(a) ONC-ACB application. Applicants must include the following
information in an application for ONC-ACB status and submit it to the
National Coordinator for the application to be considered complete.
(1) The type of authorization sought pursuant to Sec. 170.510. For
authorization to perform Health IT Module certification, applicants
must indicate the specific type(s) of Health IT Module(s) they seek
authorization to certify. If qualified, applicants will only be granted
authorization to certify the type(s) of Health IT Module(s) for which
they seek authorization.
(2) General identifying, information including:
(i) Name, address, city, state, zip code, and Web site of
applicant; and
(ii) Designation of an authorized representative, including name,
title, phone number, and email address of the person who will serve as
the applicant's point of contact.
(3) Documentation that confirms that the applicant has been
accredited by the ONC-AA.
(4) An agreement, properly executed by the applicant's authorized
representative, that it will adhere to the Principles of Proper Conduct
for ONC-ACBs.
(b) ONC-ATL application. Applicants must include the following
information
[[Page 11080]]
in an application for ONC-ATL status and submit it to the National
Coordinator for the application to be considered complete.
(1) The authorization scope sought pursuant to Sec. 170.511.
(2) General identifying, information including:
(i) Name, address, city, state, zip code, and Web site of
applicant; and
(ii) Designation of an authorized representative, including name,
title, phone number, and email address of the person who will serve as
the applicant's point of contact.
(3) Documentation that confirms that the applicant has been
accredited by NVLAP to ISO 17025.
(4) An agreement, properly executed by the applicant's authorized
representative, that it will adhere to the Principles of Proper Conduct
for ONC-ATLs.
0
8. Amend Sec. 170.523 by revising paragraphs (h) and (i) and adding
paragraph (o) to read as follows:
Sec. 170.523 Principles of proper conduct for ONC-ACBs.
* * * * *
(h) Only certify health IT (Complete EHRs and/or Health IT Modules)
that has been tested, using test tools and test procedures approved by
the National Coordinator, by a/an:
(1) ONC-ATL;
(2) NVLAP-accredited testing laboratory under the ONC Health IT
Certification Program for no longer than six months from the
authorization of the first ONC-ATL unless:
(i) Certifying previously certified Complete EHRs and/or Health IT
Module(s) if the certification criterion or criteria to which the
Complete EHRs and/or Health IT Module(s) was previously certified have
not been revised and no new certification criteria are applicable to
the Complete EHRs and/or Health IT Module(s); or
(ii) Performing gap certification.
(i) Conduct surveillance as follows:
(1) Submit an annual surveillance plan to the National Coordinator.
(2) Report, at a minimum, on a quarterly basis to the National
Coordinator the results of its surveillance.
(3) Publicly publish identifiable surveillance results on its Web
site on a quarterly basis.
(4) Annually submit a summative report of surveillance results.
* * * * *
(o) Be prohibited from reducing the scope of a certification when
the health IT is under surveillance or under a corrective action plan.
0
9. Add Sec. 170.524 to read as follows:
Sec. 170.524 Principles of proper conduct for ONC-ATLs.
An ONC-ATL shall:
(a) Maintain its NVLAP accreditation to ISO 17025;
(b) Attend all mandatory ONC training and program update sessions;
(c) Maintain a training program that includes documented procedures
and training requirements to ensure its personnel are competent to test
health IT;
(d) Report to ONC within 15 days any changes that materially affect
its:
(1) Legal, commercial, organizational, or ownership status;
(2) Organization and management including key testing personnel;
(3) Policies or procedures;
(4) Location;
(5) Personnel, facilities, working environment or other resources;
(6) ONC authorized representative (point of contact); or
(7) Other such matters that may otherwise materially affect its
ability to test health IT.
(e) Allow ONC, or its authorized agent(s), to periodically observe
on site (unannounced or scheduled), during normal business hours, any
testing performed pursuant to the ONC Health IT Certification Program;
(f) Records retention. (1) Retain all records related to the
testing of Complete EHRs and/or Health IT Modules to an edition of
certification criteria for a minimum of 3 years from the effective date
that removes the applicable edition from the Code of Federal
Regulations; and
(2) Make the records available to HHS upon request during the
retention period described in paragraph (f)(1) of this section;
(g) Only test health IT using test tools and test procedures
approved by the National Coordinator; and
(h) Promptly refund any and all fees received for:
(1) Requests for testing that are withdrawn while its operations
are suspended by the National Coordinator;
(2) Testing that will not be completed as a result of its conduct;
and
(3) Previous testing that it performed if its conduct necessitates
the retesting of Complete EHRs and/or Health IT Modules.
0
10. Revise Sec. 170.525 to read as follows:
Sec. 170.525 Application submission.
(a) An applicant for ONC-ACB or ONC-ATL status must submit its
application either electronically via email (or Web site submission if
available), or by regular or express mail.
(b) An application for ONC-ACB or ONC-ATL status may be submitted
to the National Coordinator at any time.
0
11. Amend Sec. 170.530 by revising paragraphs (c)(2), (4), (d)(2) and
(3) to read as follows:
Sec. 170.530 Review of application.
* * * * *
(c) * * *
(2) In order for an applicant to continue to be considered for ONC-
ACB or ONC-ATL status, the applicant's revised application must address
the specified deficiencies and be received by the National Coordinator
within 15 days of the applicant's receipt of the deficiency notice,
unless the National Coordinator grants an applicant's request for an
extension of the 15-day period based on a finding of good cause. If a
good cause extension is granted, then the revised application must be
received by the end of the extension period.
* * * * *
(4) If the National Coordinator determines that a revised
application still contains deficiencies, the applicant will be issued a
denial notice indicating that the applicant cannot reapply for ONC-ACB
or ONC-ATL status for a period of six months from the date of the
denial notice. An applicant may request reconsideration of this
decision in accordance with Sec. 170.535.
(d) * * *
(2) The National Coordinator will notify the applicant's authorized
representative of its satisfactory application and its successful
achievement of ONC-ACB or ONC-ATL status.
(3) Once notified by the National Coordinator of its successful
achievement of ONC-ACB or ONC-ATL status, the applicant may represent
itself as an ONC-ACB or ONC-ATL (as applicable) and begin certifying or
testing (as applicable) health information technology consistent with
its authorization.
0
12. Amend Sec. 170.535 by revising the section heading and paragraphs
(a) and (d)(1) to read as follows:
Sec. 170.535 ONC-ACB and ONC-ATL application reconsideration.
(a) Basis for reconsideration request. An applicant may request
that the National Coordinator reconsider a denial notice only if the
applicant can demonstrate that clear, factual errors were made in the
review of its application and that the errors' correction could lead to
the applicant obtaining ONC-ACB or ONC-ATL status.
* * * * *
[[Page 11081]]
(d) * * *
(1) If the National Coordinator determines that clear, factual
errors were made during the review of the application and that
correction of the errors would remove all identified deficiencies, the
applicant's authorized representative will be notified of the National
Coordinator's determination and the applicant's successful achievement
of ONC-ACB or ONC-ATL status.
* * * * *
0
13. Revise Sec. 170.540 to read as follows:
Sec. 170.540 ONC-ACB and ONC-ATL status.
(a) Acknowledgement and publication. The National Coordinator will
acknowledge and make publicly available the names of ONC-ACBs and ONC-
ATLs, including the date each was authorized and the type(s) of
certification or scope of testing, respectively, each has been
authorized to perform.
(b) Representation. Each ONC-ACB or ONC-ATL must prominently and
unambiguously identify the scope of its authorization on its Web site
and in all marketing and communications statements (written and oral)
pertaining to its activities under the ONC Health IT Certification
Program.
(c) Renewal. An ONC-ACB or ONC-ATL is required to renew its status
every three years. An ONC-ACB or ONC-ATL is required to submit a
renewal request, containing any updates to the information requested in
Sec. 170.520, to the National Coordinator 60 days prior to the
expiration of its status.
(d) Expiration. An ONC-ACB's or ONC-ATL's status will expire three
years from the date it was granted by the National Coordinator unless
it is renewed in accordance with paragraph (c) of this section.
0
14. Amend Sec. 170.556 by revising paragraph (e)(1) to read as
follows:
Sec. 170.556 In-the-field surveillance and maintenance of
certification for health IT.
* * * * *
(e) * * *
(1) Rolling submission of in-the-field surveillance results. The
results of in-the-field surveillance under this section must be
submitted to the National Coordinator on an ongoing basis throughout
the calendar year and, at a minimum, in accordance with Sec.
170.523(i)(2).
* * * * *
0
15. Revise Sec. 170.557 to read as follows:
Sec. 170.557 Authorized testing and certification methods.
(a) ONC-ATL applicability. An ONC-ATL must provide remote testing
for both development and deployment sites.
(b) ONC-ACB applicability. An ONC-ACB must provide remote
certification for both development and deployment sites.
0
16. Revise Sec. 170.560 to read as follows:
Sec. 170.560 Good standing as an ONC-ACB or ONC-ATL.
(a) ONC-ACB good standing. An ONC-ACB must maintain good standing
by:
(1) Adhering to the Principles of Proper Conduct for ONC-ACBs;
(2) Refraining from engaging in other types of inappropriate
behavior, including an ONC-ACB misrepresenting the scope of its
authorization, as well as an ONC-ACB certifying Complete EHRs and/or
Health IT Module(s) for which it does not have authorization; and
(3) Following all other applicable federal and state laws.
(b) ONC-ATL good standing. An ONC-ATL must maintain good standing
by:
(1) Adhering to the Principles of Proper Conduct for ONC-ATLs;
(2) Refraining from engaging in other types of inappropriate
behavior, including an ONC-ATL misrepresenting the scope of its
authorization, as well as an ONC-ATL testing health IT for which it
does not have authorization; and
(3) Following all other applicable federal and state laws.
0
17. Revise Sec. 170.565 to read as follows:
Sec. 170.565 Revocation of ONC-ACB or ONC-ATL status.
(a) Type-1 violations. The National Coordinator may revoke an ONC-
ATL or ONC-ACB's status for committing a Type-1 violation. Type-1
violations include violations of law or ONC Health IT Certification
Program policies that threaten or significantly undermine the integrity
of the ONC Health IT Certification Program. These violations include,
but are not limited to: False, fraudulent, or abusive activities that
affect the ONC Health IT Certification Program, a program administered
by HHS or any program administered by the federal government.
(b) Type-2 violations. The National Coordinator may revoke an ONC-
ATL or ONC-ACB's status for failing to timely or adequately correct a
Type-2 violation. Type-2 violations constitute noncompliance with Sec.
170.560.
(1) Noncompliance notification. If the National Coordinator obtains
reliable evidence that an ONC-ATL or ONC-ACB may no longer be in
compliance with Sec. 170.560, the National Coordinator will issue a
noncompliance notification with reasons for the notification to the
ONC-ATL or ONC-ACB requesting that the ONC-ATL or ONC-ACB respond to
the alleged violation and correct the violation, if applicable.
(2) Opportunity to become compliant. After receipt of a
noncompliance notification, an ONC-ATL or ONC-ACB is permitted up to 30
days to submit a written response and accompanying documentation that
demonstrates that no violation occurred or that the alleged violation
has been corrected.
(i) If the ONC-ATL or ONC-ACB submits a response, the National
Coordinator is permitted up to 30 days from the time the response is
received to evaluate the response and reach a decision. The National
Coordinator may, if necessary, request additional information from the
ONC-ATL or ONC-ACB during this time period.
(ii) If the National Coordinator determines that no violation
occurred or that the violation has been sufficiently corrected, the
National Coordinator will issue a memo to the ONC-ATL or ONC-ACB
confirming this determination.
(iii) If the National Coordinator determines that the ONC-ATL or
ONC-ACB failed to demonstrate that no violation occurred or to correct
the area(s) of non-compliance identified under paragraph (b)(1) of this
section within 30 days of receipt of the noncompliance notification,
then the National Coordinator may propose to revoke the ONC-ATL or ONC-
ACB's status.
(c) Proposed revocation. (1) The National Coordinator may propose
to revoke an ONC-ATL or ONC-ACB's status if the National Coordinator
has reliable evidence that the ONC-ATL or ONC-ACB has committed a Type-
1 violation; or
(2) The National Coordinator may propose to revoke an ONC-ATL or
ONC-ACB's status if, after the ONC-ATL or ONC-ACB has been notified of
a Type-2 violation, the ONC-ATL or ONC-ACB fails to:
(i) Rebut the finding of a violation with sufficient evidence
showing that the violation did not occur or that the violation has been
corrected; or
(ii) Submit to the National Coordinator a written response to the
noncompliance notification within the specified timeframe under
paragraph (b)(2) of this section.
[[Page 11082]]
(d) Suspension of an ONC-ATL or ONC-ACB's operations. (1) The
National Coordinator may suspend the operations of an ONC-ATL or ONC-
ACB under the ONC Health IT Certification Program based on reliable
evidence indicating that:
(i) Applicable to both ONC-ACBs and ONC-ATLs. The ONC-ATL or ONC-
ACB committed a Type-1 or Type-2 violation;
(ii) Applicable to ONC-ACBs. The continued certification of
Complete EHRs or Health IT Modules by the ONC-ACB could have an adverse
impact on the health or safety of patients.
(iii) Applicable to ONC-ATLs. The continued testing of Complete
EHRs or Health IT Modules by the ONC-ATL could have an adverse impact
on the health or safety of patients.
(2) If the National Coordinator determines that the conditions of
paragraph (d)(1) of this section have been met, an ONC-ATL or ONC-ACB
will be issued a notice of proposed suspension.
(3) Upon receipt of a notice of proposed suspension, an ONC-ATL or
ONC-ACB will be permitted up to 3 days to submit a written response to
the National Coordinator explaining why its operations should not be
suspended.
(4) The National Coordinator is permitted up to 5 days from receipt
of an ONC-ATL or ONC-ACB's written response to a notice of proposed
suspension to review the response and make a determination.
(5) The National Coordinator may make one of the following
determinations in response to the ONC-ATL or ONC-ACB's written response
or if the ONC-ATL or ONC-ACB fails to submit a written response within
the timeframe specified in paragraph (d)(3) of this section:
(i) Rescind the proposed suspension; or
(ii) Suspend the ONC-ATL or ONC-ACB's operations until it has
adequately corrected a Type-2 violation; or
(iii) Propose revocation in accordance with paragraph (c) of this
section and suspend the ONC-ATL or ONC-ACB's operations for the
duration of the revocation process.
(6) A suspension will become effective upon an ONC-ATL or ONC-ACB's
receipt of a notice of suspension.
(e) Opportunity to respond to a proposed revocation notice. (1) An
ONC-ATL or ONC-ACB may respond to a proposed revocation notice, but
must do so within 10 days of receiving the proposed revocation notice
and include appropriate documentation explaining in writing why its
status should not be revoked.
(2) Upon receipt of an ONC-ATL or ONC-ACB's response to a proposed
revocation notice, the National Coordinator is permitted up to 30 days
to review the information submitted by the ONC-ACB and reach a
decision.
(f) Good standing determination. If the National Coordinator
determines that an ONC-ATL or ONC-ACB's status should not be revoked,
the National Coordinator will notify the ONC-ATL or ONC-ACB's
authorized representative in writing of this determination.
(g) Revocation. (1) The National Coordinator may revoke an ONC-ATL
or ONC-ACB's status if:
(i) A determination is made that revocation is appropriate after
considering the information provided by the ONC-ATL or ONC-ACB in
response to the proposed revocation notice; or
(ii) The ONC-ATL or ONC-ACB does not respond to a proposed
revocation notice within the specified timeframe in paragraph (e)(1) of
this section.
(2) A decision to revoke an ONC-ATL or ONC-ACB's status is final
and not subject to further review unless the National Coordinator
chooses to reconsider the revocation.
(h) Extent and duration of revocation. (1) The revocation of an
ONC-ATL or ONC-ACB is effective as soon as the ONC-ATL or ONC-ACB
receives the revocation notice.
(2) ONC-ACB provisions. (i) A certification body that has had its
ONC-ACB status revoked is prohibited from accepting new requests for
certification and must cease its current certification operations under
the ONC Health IT Certification Program.
(ii) A certification body that has had its ONC-ACB status revoked
for a Type-1 violation is not permitted to reapply for ONC-ACB status
under the ONC Health IT Certification Program for a period of 1 year.
(iii) The failure of a certification body that has had its ONC-ACB
status revoked to promptly refund any and all fees for certifications
of Complete EHRs and Health IT Module(s) not completed will be
considered a violation of the Principles of Proper Conduct for ONC-ACBs
and will be taken into account by the National Coordinator if the
certification body reapplies for ONC-ACB status under the ONC Health IT
Certification Program.
(3) ONC-ATL provisions. (i) A testing lab that has had its ONC-ATL
status revoked is prohibited from accepting new requests for testing
and must cease its current testing operations under the ONC Health IT
Certification Program.
(ii) A testing lab that has had its ONC-ATL status revoked for a
Type-1 violation is not permitted to reapply for ONC-ATL status under
the ONC Health IT Certification Program for a period of 1 year.
(iii) The failure of a testing lab that has had its ONC-ATL status
revoked to promptly refund any and all fees for testing of health IT
not completed will be considered a violation of the Principles of
Proper Conduct for ONC-ATLs and will be taken into account by the
National Coordinator if the testing lab reapplies for ONC-ATL status
under the ONC Health IT Certification Program.
0
18. Add Sec. 170.580 to read as follows:
Sec. 170.580 ONC review of certified health IT.
(a) Direct review. ONC may directly review certified health IT
whenever there is reason to believe that the certified health IT may
not comply with requirements of the ONC Health IT Certification
Program.
(1) In determining whether to exercise such review, ONC shall
consider:
(i) The potential nature, severity, and extent of the suspected
non-conformity(ies), including the likelihood of systemic or widespread
issues and impact.
(ii) The potential risk to public health or safety or other exigent
circumstances.
(iii) The need for an immediate and coordinated governmental
response.
(iv) Whether investigating, evaluating, or addressing the suspected
non-conformity would:
(A) Require access to confidential or other information that is
unavailable to an ONC-ACB;
(B) Present issues outside the scope of an ONC-ACB's accreditation;
(C) Exceed the resources or capacity of an ONC-ACB;
(D) Involve novel or complex interpretations or application of
certification criteria or other requirements.
(v) The potential for inconsistent application of certification
requirements in the absence of direct review.
(2) Relationship to ONC-ACB's oversight. (i) ONC's review of
certified health IT is independent of, and may be in addition to, any
review conducted by an ONC-ACB.
(ii) ONC may assert exclusive review of certified health IT as to
any matters under review by ONC and any other matters so intrinsically
linked that divergent determinations between ONC and an ONC-ACB would
be inconsistent with the effective administration or oversight of the
ONC Health IT Certification Program.
(iii) ONC's determination on matters under its review is
controlling and
[[Page 11083]]
supersedes any determination by an ONC-ACB on the same matters.
(iv) An ONC-ACB shall provide ONC with any available information
that ONC deems relevant to its review of certified health IT.
(v) ONC may end all or any part of its review of certified health
IT under this section and refer the applicable part of the review to
the relevant ONC-ACB(s) if ONC determines that doing so would be in the
best interests of efficiency or the administration and oversight of the
Program.
(b) Notice of potential non-conformity or non-conformity--(1)
General. ONC will send a notice of potential non-conformity or notice
of non-conformity to the health IT developer if it has information that
certified health IT is not or may not be performing consistently with
Program requirements.
(i) Potential non-conformity. ONC may require that the health IT
developer respond in more or less time than 30 days based on factors
such as, but not limited to:
(A) The type of certified health IT and certification in question;
(B) The type of potential non-conformity to be corrected;
(C) The time required to correct the potential non-conformity; and
(D) Issues of public health or safety or other exigent
circumstances.
(ii) Non-conformity. ONC may require that the health IT developer
respond and submit a proposed corrective action plan in more or less
time than 30 days based on factors such as, but not limited to:
(A) The type of certified health IT and certification in question;
(B) The type of non-conformity to be corrected;
(C) The time required to correct the non-conformity; and
(D) Issues of public health or safety or other exigent
circumstances.
(2) Records access. In response to a notice of potential non-
conformity or notice of non-conformity, a health IT developer shall
make available to ONC and for sharing within HHS, with other federal
agencies, and with appropriate entities:
(i) All records related to the development, testing, certification,
implementation, maintenance and use of its certified health IT; and
(ii) Any complaint records related to the certified health IT.
(3) Health IT developer response. The health IT developer must
include in its response all appropriate documentation and explain in
writing why the certified health IT is conformant.
(c) Corrective action plan and procedures. (1) If ONC determines
that certified health IT does not conform to Program requirements, ONC
shall notify the health IT developer of the certified health IT of its
findings and require the health IT developer to submit a proposed
corrective action plan.
(2) ONC shall provide direction to the health IT developer as to
the required elements of the corrective action plan. ONC shall
prescribe such corrective action as may be appropriate to fully address
the identified non-conformity(ies). The corrective action plan is
required to include, at a minimum, for each non-conformity:
(i) A description of the identified non-conformity;
(ii) An assessment of the nature, severity, and extent of the non-
conformity, including how widespread they may be across all of the
health IT developer's customers of the certified health IT;
(iii) How the health IT developer will address the identified non-
conformity, both at the locations where the non-conformity was
identified and for all other potentially affected customers;
(iv) A detailed description of how the health IT developer will
assess the scope and impact of the non-conformity, including:
(A) Identifying all potentially affected customers;
(B) How the health IT developer will promptly ensure that all
potentially affected customers are notified of the non-conformity and
plan for resolution;
(C) How and when the health IT developer will resolve issues for
individual affected customers; and
(D) How the health IT developer will ensure that all issues are in
fact resolved; and
(v) The timeframe under which corrective action will be completed.
(3) When ONC receives a proposed corrective action plan (or a
revised proposed corrective action plan), it shall either approve the
proposed corrective action plan or, if the plan does not adequately
address all required elements, instruct the developer to submit a
revised proposed corrective action plan.
(4) Upon fulfilling all of its obligations under the corrective
action plan, the health IT developer must submit an attestation to ONC,
which serves as a binding official statement by the health IT developer
that it has fulfilled all of its obligations under the corrective
action plan.
(5) ONC may reinstitute a corrective action plan if it later
determines that a health IT developer has not fulfilled all of its
obligations under the corrective action plan as attested in accordance
with paragraph (c)(4) of this section.
(d) Suspension. (1) ONC may suspend the certification of a Complete
EHR or Health IT Module at any time for any one of the following
reasons:
(i) Based on information it has obtained, ONC believes that the
certified health IT poses a potential risk to public health or safety
or other exigent circumstances exist. More specifically, ONC would
suspend a certification issued to any encompassed Complete EHR or
Health IT Module of the certified health IT if the certified health IT
was, but not limited to: Contributing to a patient's health information
being unsecured and unprotected in violation of applicable law;
increasing medical errors; decreasing the detection, prevention, and
management of chronic diseases; worsening the identification and
response to public health threats and emergencies; leading to
inappropriate care; worsening health care outcomes; or undermining a
more effective marketplace, greater competition, greater systems
analysis, and increased consumer choice;
(ii) The health IT developer fails to timely respond to any
communication from ONC, including, but not limited to:
(A) Fact-finding;
(B) A notice of potential non-conformity within the timeframe
established in accordance with paragraph (b)(1)(i) of this section; or
(C) A notice of non-conformity within the timeframe established in
accordance with paragraph (b)(1)(ii) of this section;
(iii) The information provided by the health IT developer in
response to any ONC communication, including, but not limited to: Fact-
finding, a notice of potential non-conformity, or a notice of non-
conformity is insufficient or incomplete;
(iv) The health IT developer fails to timely submit a proposed
corrective action plan that adequately addresses the elements required
by ONC as described in paragraph (c) of this section;
(v) The health IT developer does not fulfill its obligations under
the corrective action plan developed in accordance with paragraph (c)
of this section.
(2) When ONC decides to suspend a certification, ONC will notify
the health IT developer of its determination through a notice of
suspension.
(i) The notice of suspension will include, but may not be limited
to:
(A) An explanation for the suspension;
(B) The information ONC relied upon to reach its determination;
(C) The consequences of suspension for the health IT developer and
the Complete EHR or Health IT Module
[[Page 11084]]
under the ONC Health IT Certification Program; and
(D) Instructions for appealing the suspension.
(ii) A suspension of a certification will become effective upon the
health IT developer's receipt of a notice of suspension.
(3) The health IT developer must notify all affected and
potentially affected customers of the identified non-conformity(ies)
and suspension of certification in a timely manner.
(4) If a certification is suspended, the health IT developer must
cease and desist from any marketing and sale of the suspended Complete
EHR or Health IT Module as ``certified'' under the ONC Health IT
Certification Program from that point forward until such time ONC may
rescind the suspension.
(5) Inherited certified status certification for a suspended
Complete EHR or Health IT Module is not permitted until such time ONC
rescinds the suspension.
(6) ONC will rescind a suspension of certification if the health IT
developer completes all elements of an approved corrective action plan
and/or ONC confirms that all non-conformities have been corrected.
(e) Termination. (1) ONC may terminate a certification issued to a
Complete EHR and/or Health IT Module if:
(i) The health IT developer fails to timely respond to any
communication from ONC, including, but not limited to:
(A) Fact-finding;
(B) A notice of potential non-conformity within the timeframe
established in accordance with paragraph (b)(1)(i) of this section; or
(C) A notice of non-conformity within the timeframe established in
accordance with paragraph (b)(1)(ii) of this section;
(ii) The information provided by the health IT developer in
response to any ONC communication, including, but not limited to: Fact-
finding, a notice of potential non-conformity, or a notice of non-
conformity is insufficient or incomplete;
(iii) The health IT developer fails to timely submit a proposed
corrective action plan that adequately addresses the elements required
by ONC as described in paragraph (c) of this section;
(iv) The health IT developer does not fulfill its obligations under
the corrective action plan developed in accordance with paragraph (c)
of this section; or
(v) ONC concludes that a certified health IT's non-conformity(ies)
cannot be cured.
(2) When ONC decides to terminate a certification, ONC will notify
the health IT developer of its determination through a notice of
termination.
(i) The notice of termination will include, but may not be limited
to:
(A) An explanation for the termination;
(B) The information ONC relied upon to reach its determination;
(C) The consequences of termination for the health IT developer and
the Complete EHR or Health IT Module under the ONC Health IT
Certification Program; and
(D) Instructions for appealing the termination.
(ii) A termination of a certification will become effective either
upon:
(A) The expiration of the 10-day period for filing an appeal in
paragraph (f)(3) of this section if an appeal is not filed by the
health IT developer; or
(B) A final determination to terminate the certification per
paragraph (f)(7) of this section if a health IT developer files an
appeal.
(3) The health IT developer must notify affected and potentially
affected customers of the identified non-conformity(ies) and
termination of certification in a timely manner.
(4) If ONC determines that a Complete EHR or Health IT Module
certification should not be terminated, ONC will notify the health IT
developer in writing of this determination.
(f) Appeal --(1) Basis for appeal. A health IT developer may appeal
an ONC determination to suspend or terminate a certification issued to
a Complete EHR or Health IT Module if the health IT developer asserts:
(i) ONC incorrectly applied Program methodology, standards, or
requirements for suspension or termination; or
(ii) ONC's determination was not sufficiently supported by the
information used by ONC to reach the determination.
(2) Method and place for filing an appeal. A request for appeal
must be submitted to ONC in writing by an authorized representative of
the health IT developer whose Complete EHR or Health IT Module was
subject to the determination being appealed. The request for appeal
must be filed in accordance with the requirements specified in the
notice of termination or notice of suspension.
(3) Time for filing a request for appeal. An appeal must be filed
within 10 calendar days of receipt of the notice of suspension or
notice of termination.
(4) Effect of appeal on suspension and termination. (i) A request
for appeal stays the termination of a certification issued to a
Complete EHR or Health IT Module, but the Complete EHR or Health IT
Module is prohibited from being marketed or sold as ``certified''
during the stay.
(ii) A request for appeal does not stay the suspension of a
Complete EHR or Health IT Module.
(5) Appointment of a hearing officer. The National Coordinator will
assign the case to a hearing officer to adjudicate the appeal on his or
her behalf. The hearing officer may not review an appeal in which he or
she participated in the initial suspension or termination determination
or has a conflict of interest in the pending matter.
(6) Adjudication. (i) The hearing officer may make a determination
based on:
(A) The written record as provided by the health IT developer with
the appeal filed in accordance with paragraphs (f)(1) through (3) of
this section and including any information ONC provides in accordance
with paragraph (f)(6)(v) of this section; or
(B) All the information provided in accordance with paragraph
(f)(6)(i)(A) and any additional information from a hearing conducted
in-person, via telephone, or otherwise.
(ii) The hearing officer will have the discretion to conduct a
hearing if he/she:
(A) Requires clarification by either party regarding the written
record under paragraph (f)(6)(i)(A) of this section;
(B) Requires either party to answer questions regarding the written
record under paragraph (f)(6)(i)(A) of this section; or
(C) Otherwise determines a hearing is necessary.
(iii) The hearing officer will neither receive testimony nor accept
any new information that was not presented with the appeal request or
was specifically and clearly relied upon to reach the determination
issued by ONC under paragraph (d)(2) or (e)(2) of this section.
(iv) The default process will be a determination in accordance with
paragraph (f)(6)(i)(A) of this section.
(v) ONC will have an opportunity to provide the hearing officer
with a written statement and supporting documentation on its behalf
that explains its determination to suspend or terminate the
certification. The written statement and supporting documentation must
be included as part of the written record. Failure of ONC to submit a
written statement does not result in any adverse findings against ONC
and may not in any way be taken into account by the hearing officer in
reaching a determination.
(7) Determination by the hearing officer. (i) The hearing officer
will issue
[[Page 11085]]
a written determination to the health IT developer within 30 days of
receipt of the appeal, unless the health IT developer and ONC agree to
a finite extension approved by the hearing officer.
(ii) The National Coordinator's determination on appeal, as issued
by the hearing officer, is final and not subject to further review.
0
19. Add Sec. 170.581 to read as follows:
Sec. 170.581 Consequences due to the termination of a certification.
(a) Testing and recertification. A Complete EHR or Health IT Module
(or replacement version) that has had its certification terminated can
be tested and recertified (certified) once all non-conformities have
been adequately addressed.
(1) The recertified Complete EHR or Health IT Module (or
replacement version) must maintain a scope of certification that, at a
minimum, includes all the previous certified capabilities.
(2) The health IT developer must request, and have approved,
permission to participate in the Program before testing and
recertification (certification) may commence for the Complete EHR or
Health IT Module (or replacement version).
(i) The request must include a written explanation of the steps
taken to address the non-conformities that led to the termination.
(ii) ONC must approve the request to participate in the Program.
(b) Heightened scrutiny. Certified health IT that was previously
the subject of a certification termination (or replacement version)
shall be subject to heightened scrutiny for, at a minimum, one year.
(c) Program ban. The testing and certification of any health IT of
a health IT developer that has the certification of one of its Complete
EHRs or Health IT Modules terminated under the Program or withdrawn
from the Program when the subject of a potential nonconformity or non-
conformity is prohibited, unless:
(1) The non-conformity is corrected and implemented for all
affected customers; or
(2) The certification and implementation of other health IT by the
health IT developer would remedy the non-conformity for all affected
customers.
Sylvia M. Burwell,
Secretary.
[FR Doc. 2016-04531 Filed 3-1-16; 8:45 am]
BILLING CODE 4150-45-P