GE Healthcare ONC Certification Comments RIN 0955-AA00 April 28 2016 Final

GE Healthcare
Healthcare IT
540 W. Northwest Highway
April 28, 2016
Barrington, IL 60010
Karen DeSalvo, MD, MPH, MSc

National Coordinator for Health Information Technology
Attention: ONC Health IT Certification Program: Enhanced Oversight and Accountability
U.S. Department of Health and Human Services
Hubert H. Humphrey Building, Suite 729D
200 Independence Avenue, S.W.
Washington, D.C. 20201
Attention File Code: RIN 0955AA00
[Filed Electronically]
Re: ONC Health IT Certification Program: Enhanced Oversight and Accountability
Dear Dr. DeSalvo:
GE Healthcare (GEHC) appreciates this opportunity to comment on the following proposed
rule: ONC Health IT Certification Program: Enhanced Oversight and Accountability. GEHC, a
unit of General Electric Company, has expertise in medical imaging and information
technologies, digital health, medical diagnostics, patient monitoring systems, performance
improvement, drug discovery, and biopharmaceuticals manufacturing technologies. GEHCs
healthcare information technology (HIT) covers a broad span of clinical, administrative, and
financial applications serving customers that range from small physician practices to large
integrated delivery networks.
GEHC is passionate about how electronic health records (EHRs) and other health IT (HIT) can
enhance quality and efficiency and contribute to our nations shift to integrated and valuebased delivery and payment systems. We are committed to providing products and services
that are developed and used with safety as a priority and that facilitate truly meaningful use
that improves health care outcomes, quality and efficiency.
We appreciate ONCs continued focus on maintaining and enhancing the ONC HIT
certification program, This letter provides our key comments on the three major components
of this proposed rule. We attach more detailed comments using the ONC-provided template.
In addition, we support the comments provided by the EHR Association (EHRA) and also
commend your careful attention to the comments from HIMSS and AMIA.
Overall Comments
GE Healthcare has a mixed response to the three major proposals in this proposed rule,
generally positive on Oversight of ONC-Authorized Testing Laboratories and Transparency
and Availability of Surveillance Results and with significant concerns regarding ONC Direct
Review of Certified Health IT. Overall, we support the EHR Incentive Program and the
associated HIT certification program and believe that any further changes to both of these
programs should further public health and safety, simplification, innovation, and reduction of
regulatory burden for providers and developers,
1. Oversight of ONC-Authorized Testing Laboratories
The proposed rule includes provisions that would enable ONC to conduct direct oversight of
National Voluntary Laboratory Accreditation Program-accredited testing laboratories (labs). It
proposes that such labs apply to become ONC-Authorized Testing Labs (ONC-ATLs). ONC also
proposes to establish processes to authorize, retain, suspend, and revoke ONC-ATL status.
The proposed approach would create authorization and oversight for testing labs intended to
be similar and comparable to the approach used for ONC-Authorized Certification Bodies
(ONC-ACBs).
Comment: Overall, this proposal is reasonable and potentially beneficial. It will be important,
however, for ONC to minimize additional cost burdens on ATLs, which could reduce efficiency,
lengthen review time, lower ATL program participation, and increase certification costs for
developers and, by extension, providers. ONC should also ensure that this process is consistent
with the applicable ISO standards applied to the ATLs and we support the proposed continued
role of the National Voluntary Laboratory Accreditation Program (NVLAP) in accrediting ATLs.
2. Transparency and Availability of Surveillance Results
The proposal would require ONC-ACBs to make identifiable surveillance results publicly
available on their websites quarterly, beyond information on non-conformities and corrective
action plans (CAPs) that must be disclosed today. ONC states that this provision is intended to
enhance transparency and accountability of HIT for customers and users by providing
valuable information about the continued performance of certified health IT and that public
availability of identifiable results would provide a more complete context of surveillance by
making more information about certified products available to purchasers and enabling
health IT developers to note their continued compliance with Program requirements.
ONC frames this proposal as enabling provision of what it projects to be the mostly positive
results of surveillance to be made available. It states that surveillance results would include
information such as, but not limited to: names of HIT developers; names of products and
versions; certification criteria and Program requirements surveilled; and outcomes of
surveillance. ONC also emphasizes that it does not propose to require that publicly posted
surveillance results include proprietary, trade secret, or confidential information (e.g.,
screenshots that may include such information).
Comment: Overall, availability of more balanced surveillance results could provide a more
complete picture of certified EHRs and other HIT. Given the likely positive outcomes of these
additional surveillance results, ONC and the ONC-ACBs should provide summary results, using
both the general approach to information to be released on CAPs and the definition of results
used in the 2015 ONC Certification Final Rule.
ONC should use a definition of results that is a ceiling rather than a floor to ensure program
consistency, that does not include interim work product or information obtained in the course
of surveillance (i.e., disclosure should truly focused on results), and that as proposed, does not
include proprietary or business sensitive information. Results should emphasize certified
capabilities evaluated and not indicate why surveillance took place (e.g., provider expressed
concern) as such information could provide a misleading and incomplete picture to consumers
of the information. Finally, ONC and the ACB should clearly indicate that surveillance of specific
certified HIT should not imply a problem or potential problem with the HIT.
3. ONC Direct Review of Certified Health IT

ONC proposes that, in addition to review of certified HIT by ONC-ACBs, it would directly
review certified HIT and act when necessary to promote health IT developer accountability
for the performance, reliability, and safety of health IT. ONCs primary stated goal is to work
with developers to remedy any nonconformities with certified health IT in a timely manner
and across all customers, potentially eliminating the need for suspension and/or termination
processes. These provisions are framed as a complement to current paths of review for
certified HIT through ONC-ACBs and provide an additional tool to address public health and
safety issues that may arise.
ONC would have very broad discretion to review certified HIT. It anticipates that such review
would be relatively infrequent and would focus on situations posing a risk to public health or
safety, but believes there could be other exigencies, distinct from public health and safety
concerns, which for similar reasons would warrant ONCs direct review and action.
The focus on public health and safety and other exigencies is stated to be grounded in
ONCs statutory responsibility to keep or recognize a certification 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 patients health information is secure and
protected, in accordance with applicable law; improves health care quality; reduces medical
errors; reduces health care costs resulting from inefficiency, medical errors, inappropriate
care, duplicative care, and incomplete information; and promotes a more effective
marketplace, greater competition, greater systems analysis, increased consumer choice, and
improved outcomes in health care services (see section 3001(b) of the PHSA). Nonconformance with any one of these goals, even if the goal was not part of certification, would
be a basis for certification suspension or termination.
ONC states that it could suspend certification at any time if it 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 products health IT
developer as detailed. Per 170.580(d)(1)(i), 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 patients 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. This listing is also justified as based on ONCs duties per section 3001(b).
Specifically, the proposed rule includes provisions to:
Directly review certified health IT, independent of and in addition to an ONC-ACBs role;
Enable ONC to assess non-conformities, including those that pose a risk to public health
and safety (but including other HITECH HIT priority areas that the certification program is
intended to support), which may be caused by the interaction of certified and uncertified
capabilities within certified health IT;
Prescribe comprehensive corrective actions for developers to address nonconformities,
including notifying affected customers;
Enable ONC to suspend and/or terminate a certification issued to a Complete Electronic

Health Record (EHR) or Health IT Module;
Institute processes for prohibiting further testing and certification of any health IT that a
health IT developer brings to ONC if a found non-conformity is not first corrected or will
be corrected through release of new certified health IT; and
Establish an appeals process for developers.
Comment: This proposal is very far-reaching in its implications and claimed authority. Although
ONC asserts that this authority would be invoked only infrequently, there is no guarantee of
such a limited approach, especially as ONC leadership changes in coming years. We have
several concerns summarized below and expanded upon in our more detailed comments. We
also suggest that ONC engage directly with such industry leaders as HIMSS and the EHR
Association to identify ways in which the certification program can better serve program goals,
including enhanced public health and safety.
First, ONC has not made the case sufficiently for direct review as proposed, focusing largely on
hypotheticals rather than documented problems that would be best remedied by direct review
using the expanded set of de facto criteria that are proposed, and we therefore oppose the
provisions for direct review, especially as they depart from evaluation against the certification
criteria established by regulation and associated test methods. Moreover, based on our
understanding of the current or likely ONC structure and budget and details in this proposal,
we do not believe that ONC has in place or has proposed a sufficient organizational and
regulatory capacity or framework for direct review.
Second, ONC appears to be substantially overstating the authority and responsibility
established in Section 3001(b) of the PHSA as it relates to this certification proposal. This
section sets out the high-level goals to be pursued by ONC, described as development of a
nationwide health information technology infrastructure that allows for the electronic use and
exchange of information and has 11 more specific goals, many of which are called out in this
proposed rule. To accomplish these goals, ONC is to carry out eight broad duties set out in
Section 3001(c), only one of which is Certification, and that also include Standard, Website,
and Reports and Publications. Clearly, this is a set of duties that, in aggregate, is intended to
further the statutory goals.
It seems inconceivable that Congress intended that each of the duties individually was to be
implemented to cover the full range of the Section 3001(b) goals. With respect to Certification,
HITECH was explicit, focusing on a program or programs for the voluntary certification of
health information technology as being in compliance with applicable certification criteria
adopted under this subtitle. Congress was also clear on the nature of the certification criteria
to be used in the certification program, stating that the term certification criteria means, with
respect to standards and implementation specifications for health information technology,
criteria to establish that the technology meets such standards and implementation
specifications. HITECH also set out the roles of the HIT Standards and Policy Committees in
developing certification criteria and the process for adoption of certification criteria by the
Secretary through rule-making. It is clear that Congress intended the process by which such
criteria are developed and implemented to support, along with other ONC duties, the broad
goals set for ONC in HITECH.
Through three regulatory cycles, ONC has developed certification criteria, the heart of the
certification program and its statutory construct. In this proposed rule, ONC, over seven years
after passage of HITECH, and after these three cycles, discovers new authority and proposes a
substantially new certification program unmoored from certification criteria developed per
statute and regulation, and one that looks back to the super-set of HITECH goals for the entire
mission of ONC to create certification concepts to be applied at ONCs sole discretion.

In taking this approach, ONC is fundamentally redefining, via 170.580(a), the requirements of
the ONC Health IT Certification Program as beyond the published certification criteria when it
states that 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, requirements that are being substantially altered and expanded via this rule-making.
The proposed high-level de facto certification criteria by which ONC would determine the need
for intervention are very broad and include [t]he potential risk to public health or safety and
the catchall or other exigent circumstances without a defined set of specific criteria that can
guide our product development and implementation.
This vast expansion of ONC authority, which seems at odds with Congressional intent and the
underlying statute, is especially troubling because:
o
Commenters and stakeholders must rely on the current ONCs stated desire for
limited use of this authority when there is no guarantee that limited application
would be the approach taken in later years and Administrations;
ONC sets out a very high-level and generally worded framework on which to base
essentially ad hoc certification criteria that were never communicated to health IT
developers or ONC-ACBs and for which there is no objective basis to assess
compliance nor even any clear duty for compliance;
ONC seeks a broad expansion of its authority to non-certified health IT and also to
apply pressure on firms that develop health IT relative to all of their certified
products to ensure compliance with issues with a portion of any single product,
which could hinder innovation sought by providers; and
ONC also has no current structure or experience in place to implement this vast
expansion of authority and proposes only a very limited appeal process.
Overall, if ONC wishes to add direct review to the certification program, it should do so only
after adoption of formal certification criteria developed per the applicable statute, with all
evaluations data-driven and evidence-based.
If ONC chooses to proceed in the general direction proposed, we believe that it should very
rarely need to intervene due to ONC-ACB limitations, should refine the applicable language
dealing with such limitations and should focus only on the most exigent (defined as
requiring immediate attention: needing to be dealt with immediately) safety-related
issues and not all of the strategic goals set out for ONC in HITECH. ONC should also only
focus on conformance, including safe conformance, to certified capabilities and not to an
ad hoc and implied set of new criteria as is proposed. In addition, ONC should establish
clear requirements for what information must be presented as part of an external
allegation of non-conformance, who would be eligible to make such reports, and also to
emphasize that the first recourse should always be an attempt to work directly with the
developer to remedy the issue at hand.
We also have concerns, per our detailed comments, with review, suspension, termination,
and appeals processes. Our comments include specific requested changes, focusing on:
o The overly broad and subjective scope for ONC review as discussed above;
o Inclusion of non-certified capabilities (e.g., billing capabilities or FDA-regulated
software) in review, suspension, termination and records request processes;
o Lack of clear certification criteria on which to base a suspension or termination;
o
o
o
o
o
o
o
o
A developers other certified products would be unable to be further certified after

termination for one certified product (and possibly suspension);
ONC being overly prescriptive in dictating needed corrective actions and corrective
action plans, in contrast to the approach taken in the 2015 Certification Final Rule;
Insufficient time for vendor response to ONC inquiries and to submit an appeal;
Excessive, overly broad and likely very costly Records Access requirements;
Overly restrictive appeals processes and lack of clear expertise and independence
for hearing officers unlike the proposal, developers should always be able to
request a hearing and information developed as a result of the hearing should be
able to be considered by the hearing officer;
The inability of an appeal to stay the ONC marketing cease and desist order;
The need to allow for extension of suspension rather than termination if the vendor
has not met all ONC requirements but has indicated willingness to try to do so; and
Having new provisions for direct review become effective no sooner than six
months after the Final Rule is effective to allow ONC, ONC-ACBs, and developers
time to adjust processes as needed.
***
We appreciate ONCs desire to enhance the certification program and to protect the public
health and safety. We urge ONC to give very careful consideration to these comments and to
those of our industry partners, such as the Electronic Health Records Association, HIMSS, and
AMIA. GE Healthcare appreciates the opportunity to submit comments on these important
issues. If you have questions on our comments, please do not hesitate to contact me.
Sincerely,
Mark J. Segal, PhD

Vice President, Government and Industry Affairs
GE Healthcare IT
847.946.1428
mark.segal@ge.com
cc:
John Schaeffler, Executive - Government Relations Leader, General Electric Company
Attachment ONC Comment Template
Comments by GE Healthcare IT, April 28, 2016
Office of the National Coordinator for Health IT

Proposed Rule Public Comment Template
ONC Health IT Certification Program:
Enhanced Oversight and Accountability
ONC Health IT Certification Program: Enhanced Oversight and Accountability

Provisions of the Proposed Rule
ONC Review of Certified Health IT General Comments
Preamble FR Citation: 81 FR 11060
Specific questions in preamble? No
Public Comment Field:

See below under Authority and Scope
ONC Review of Certified Health IT Authority and Scope ( 170.580)
(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-ACBs 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.
Preamble FR Citation: 81 FR 11060 - 61
Specific questions in preamble? Yes

Comment: This proposal is very far-reaching in its implications and claimed authority for action.
Although ONC asserts that this authority would be invoked only infrequently, there is no guarantee of
such a limited approach, especially as ONC leadership changes in coming years. We have a number of
concerns with this provision that are summarized below and expanded upon in our more detailed
comments.
First, ONC has not made the case sufficiently for direct review as proposed, focusing largely on
hypotheticals rather than documented problems that would be best remedied by direct review
using the expanded set of de facto criteria that are proposed, and we therefore oppose the
provisions for direct review, especially as they depart from evaluation against the certification
criteria established by regulation and associated test methods. Moreover, based on our
understanding of the current or likely ONC structure and budget and details in this proposal, we do
not believe that ONC has in place or has proposed a sufficient organizational and regulatory capacity
or framework for direct review.
Second, ONC appears to be substantially overstating the authority and responsibility established in
Section 3001(b) of the PHSA as it relates to this certification proposal. This section sets out the highlevel goals to be pursued by ONC, described as development of a nationwide health information
technology infrastructure that allows for the electronic use and exchange of information and has
11 more specific goals, many of which are called out in this proposed rule. To accomplish these
goals, ONC is to carry out eight broad duties set out in Section 3001(c), only one of which is
Certification, and that also include Standard, Website, and Reports and Publications. Clearly, this is a
set of duties that, in aggregate, is intended to further the statutory goals and to be designed in a
way to do so.
It seems inconceivable that Congress intended that each of the duties individually was to be
implemented to cover to full range of the Section 3001(b) goals. With respect to Certification,
HITECH was explicit, focusing on a program or programs for the voluntary certification of health
information technology as being in compliance with applicable certification criteria adopted under
this subtitle. Congress was also clear on the nature of the certification criteria to be used in the
certification program, stating that the term certification criteria means, with respect to standards
and implementation specifications for health information technology, criteria to establish that the
technology meets such standards and implementation specifications. HITECH also set out the roles
of the HIT Standards and Policy Committees in developing certification criteria and the process for
adoption of certification criteria by the Secretary through rule-making. It is clear that Congress
intended the process by which such criteria are developed and implemented to support, along with
other ONC duties, the broad goals set for ONC in HITECH.
Through three regulatory cycles, ONC has developed certification criteria, which are the heart of the
certification program and its statutory construct. In the current proposed rule, ONC, over seven
years after the passage of HITECH, and after these three cycles, discovers new authority and
proposes a substantially new certification program unmoored from certification criteria developed
per statute and regulation, and one that looks back to the super-set of goals for the entire mission
of ONC to create certification concepts that can be applied at ONCs sole discretion.

In taking this approach, ONC is fundamentally redefining, via 170.580(a), the requirements of the
ONC Health IT Certification Program as beyond the published certification criteria when it states
that 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,
requirements that are being substantially altered and expanded via this rule-making. The proposed
criteria by which ONC would determine the need for intervention are very broad and include [t]he
potential risk to public health or safety and the catchall or other exigent circumstances.
This vast expansion of ONC authority, which seems at odds with Congressional intent and the
underlying statute, is especially troubling because:
o
Commenters and stakeholders must rely on the current ONCs stated desire for limited use
of this authority when there is no guarantee that limited application would be the approach
taken in later years and Administrations.
ONC sets out a very high-level and generally worded framework on which to base essentially
ad hoc certification criteria that were never communicated to health IT developers or ONCACBs and for which there is no objective basis to assess compliance nor even any clear duty
for compliance.
ONC seeks a broad expansion of its authority to non-certified health IT and also to pressure
on firms that develop health IT relative to all of their certified products to ensure compliance
with issues with a portion of any single product.
ONC also has no current structure or experience in place to implement this vast expansion of
authority and proposes only a very limited appeal process.
Overall, if ONC wishes to add direct review to the certification program, it should only do so after
development of formal certification criteria developed per the applicable statute and all evaluations
should be data driven and evidence-based.
If ONC chooses to proceed in the general direction proposed, we believe that it should very rarely
need to intervene due to ONC-ACB limitations, and should refine the applicable language dealing
with such limitations and should focus only on the most exigent (defined as requiring immediate
attention: needing to be dealt with immediately) safety-related issues and not all of the strategic
goals set out for ONC in HITECH. ONC should also only focus on conformance, including safe
conformance, to certified capabilities and not to an ad hoc and implied set of new criteria as is
proposed.
We also have concerns, laid out in our detailed comments below, regarding the specifics of the
review, suspension, termination, and appeals processes. Our comments include specific requested
changes. Our issues include:
o The overly broad and subjective scope for ONC review as discussed above
o Inclusion of non-certified capabilities in review, suspension, termination and records request
processes
o Lack of clear certification criteria on which to base a suspension or termination
o A developers other certified products would be unable to be further certified after
termination for one certified product (and possibly suspension)
o
o
o
o
o
o
ONC being overly prescriptive in dictating needed corrective actions and corrective action
plans, in contrast to the approach taken in the 2015 Certification Final Rule
Insufficient time for vendor response to ONC inquiries and to submit an appeal
Excessive, overly broad and likely very costly Records Access requirements
Overly restrictive appeals processes and lack of clear expertise and independence for
hearing officers unlike the proposal, developers should always be able to request a
hearing and information developed as a result of the hearing should be able to be
considered by the hearing officer
The inability of an appeal to stay the ONC marketing cease and desist order
The need to allow for extension of suspension rather than termination if the vendor has not
met all ONC requirements but has expressed a willingness to try to do so
ONC Review of Certified Health IT - ONC-ACBs Role ( 170.580)

(2) Relationship to ONC-ACBs oversight. (i) ONCs 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) ONCs determination on matters under its review is controlling and supersedes any determination by an ONCACB 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.

Overall, as stated regarding Authority and Scope, we believe that ONC should rely on the ONC-ACBfocused process against published certification criteria.
We are especially concerned with i and ii:
(i) ONCs 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.
We do not believe that ONC review should be in addition to ONC-ACB review, especially for reviews
addressing the same capabilities and criteria. Similarly, we believe that 2.ii is overly broad in its
reference to to any matters under review by ONC and any other matters so intrinsically linked that
divergent determinations . . ..
Review Processes General Comments


See comments below.
Review Processes Notice of Potential Non-Conformity or Non-Conformity ( 170.580)
(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 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.

Review Processes Notice of Potential Non-Conformity or Non-Conformity ( 170.580)
Any notice of potential non-conformance should be defined by current certification functionality to
which the product is certified. In addition, non-conformity should be specifically identified to whether
it applies to specific certification criteria or the broader bases for evaluation proposed by ONC. A
thorough initial and as needed, follow-up, process for evaluating alleged nonconformity is encouraged to
avoid wasting resources on frivolous complaints or investigations. We encourage discussion between the
developer and the ACB about complaints or surveillance-related potential nonconformities as a first step
in determining whether a potential nonconformity should be issued.
A notice of potential non-conformance identifying specific certification criteria and alleged nonconformance should always be the first step in addressing the complaint that the product is not
conforming as certified, and a notification of a definitive nonconformity should not generally be the first
step. We are unsure of how ONC could send a notice of definite non-conformance without developer
engagement as opposed to sending a notice of potential non-conformance in nearly all cases. This notice
of potential non-conformance should be handled through a formal receipt verification mail process to
assure the HIT developer is aware, and not relied upon only through email notification. Once the
developer receives the potential nonconformity and assesses the potential nonconformity, they should
have to acknowledge the issue if there is a non-conformance with which they agree or provide
documentation to ONC for evaluation that there is no nonconformance. The timeframe for this initial
response and subsequent CAP must be defined and should not be shortened at will by ONC.
It is crucial that the alleged non-conformance is truly an issue with the performance of the product
against applicable certification criteria and test methods used for certification. This determination would
likely require iterative dialog with ONC in the suggested timeframe. If the developer provides
documentation of conformance that does not satisfy ONC, ONC should immediately notify the
developer and engage in the process to resolve the issue. The developer may need to provide additional
documentation or schedule a product demonstration to assure ONC of conformance.
The number of days should be in terms of business days and not arbitrarily shortened. Once a nonconformance is confirmed, ONC should issue the notice of non-conformance and the developer would
need to initiate the process to submit a corrective action plan. With a corrective action plan underway,
we recommend that there be no further action or sanction on the developer working to correct the
problem unless extreme and exigent consequences to health and safety are determined, thus allowing
the corrective action plan to be fulfilled without imposing any sanctions on the HIT developer unless the
corrective action plan is not fulfilled.
In addition, to minimize the direct and opportunity costs of review for ONC, ONC should establish clear
requirements for what information must be presented as part of an external allegation of nonconformance, who would be eligible to make such reports, and also to emphasize that the first recourse
should always be an attempt to work directly with the developer to remedy the issue at hand. ONC
should consider development of objective criteria for who is qualified to submit a report on nonconformance and we suggest that other developers reports should not trigger ONC direct review. In
addition, as feasible, an external reporter should need to demonstrate and provide objective evidence
on the following:
1. A non-conformance against formalized certification criteria

2. That they first contacted (through regular means of support requests) the developer with
that evidence of non-conformance
3. That they have received an unsatisfactory response (or no response) after a reasonable
period of time and/or escalations to developer senior management
The proposal for Records Access is very far-reaching and appears to go well beyond what is required for
ONC-ACB surveillance. It is especially troublesome given the proposed broad scope of the basis for
direct review. The proposed language should be much more narrowly focused on records that directly
bear on the specific certified capabilities affected by the non-conformance and only materials relevant
to the issue at hand. The most important records at this point would be the proof of conformance
provided to the ONC-ACB or a corrective action plan to address the non-conformance. Finally, it will be
essential to have a clear standard and definition of cooperate and we also ask for clarification
regarding the term encompassed how does it may relate inclusion of non-certified HIT.
Review Processes Corrective Action ( 170.580)

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

Review Processes Corrective Action ( 170.580)
As stated previously, we believe that review by the ONC-ACB should be the typical process to address
concerns about non-conformance. We ask that more specific circumstances be defined than stated in
the proposed rule regarding when ONC should exert direct review. The authority to require a corrective
action plan must be based upon requirements of the certification program as related to certification
criteria that have been issue consistent with the applicable statute and regulations and that have been
tested and certified by the developer. The scope for the corrective action plan should be rooted in the
issues with certified capabilities.
We are concerned about and object to the proposed provision regarding the authority of ONC to
prescribe the corrective action and its consequences. This proposed regulatory language seems to
differ significantly from the 2015 Edition language used in " 170.556 In-the-field surveillance and
maintenance of certification for Health IT. The 2015 Edition language specifies that, when an ONC ACB
determines through surveillance or otherwise that the health IT does not conform to the requirements
of its certification, upon notification the HIT developer must submit a corrective action plan. The current
proposal and the 2015 Edition rule are consistent when it concerns the authority of ONC ACB or ONC to
provide direction on the required elements of the corrective action plan; however, they seem
inconsistent with regards to the proposed ability of ONC to prescribe such corrective action as may be
appropriate to fully address the identified non-conformity(ies). We do not believe that ONC is in the
best position to prescribe the specific corrective action, as opposed to identifying the nonconformance that must be addressed and generally support language that matches the 2015 Edition
rule regarding providing direction on the required elements of the plan.
We note that, within the elements of the corrective action plan, there are implications that the nonconformance potentially affects a number of customers. There could be potential non-conformances
that only affect individual customers and thus all elements defined in the CAP may not apply. We are
also concerned with the intent of the requirement in (iv)(D) regarding the ability to ensure correction
of the non-conformance. As the developer carries out the corrective action plan, the intent is to make
available software that corrects the non-conformance and to make sure that the correction is available
for implementation for all affected customers. This action would fulfill our obligation as we understand
the corrective action; however, we cannot guarantee the absolute resolution within a providers
implementation within the required timeframe as some providers may not immediately implement the
software update or modify their workflow.

Review Processes Suspension ( 170.580)
(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 patients health information being unsecured and unprotected in violation of
applicable law; increasing medical errors; decreasing the detection, prevention, and management of chronic
diseases; worsening the identification and response to public health threats and emergencies; leading to
inappropriate care; worsening health care outcomes; or undermining a more effective marketplace, greater
competition, greater systems analysis, and increased consumer choice;
(ii) The health IT developer fails to timely respond to any communication from ONC, including, but not limited to:
(A) Fact-finding;
(B) A notice of potential non-conformity within the timeframe established in accordance with paragraph (b)(1)(i) of
this section; or
(C) A notice of non-conformity within the timeframe established in accordance with paragraph (b)(1)(ii) of this
section;
(iii) The information provided by the health IT developer in response to any ONC communication, including, but
not limited to: fact-finding, a notice of potential non-conformity, or a notice of non-conformity is insufficient or
incomplete;
(iv) The health IT developer fails to timely submit a proposed corrective action plan that adequately addresses the
elements required by ONC as described in paragraph (c) of this section;
(v) The health IT developer does not fulfill its obligations under the corrective action plan developed in accordance
with paragraph (c) of this section.
(2) When ONC decides to suspend a certification, ONC will notify the health IT developer of its determination
through a notice of suspension.
(i) The notice of suspension will include, but may not be limited to:
(A) An explanation for the suspension;
(B) The information ONC relied upon to reach its determination;
(C) The consequences of suspension for the health IT developer and the Complete EHR or Health IT Module under
the ONC Health IT Certification Program; and
(D) Instructions for appealing the suspension.
(ii) A suspension of a certification will become effective upon the health IT developers 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.
10

Review Processes Suspension ( 170.580)
We do not support suspension of HIT products as proposed in this rule and, as discussed in the Scope
and Authority section, believe that the stated potential grounds for suspension are overly broad. As
proposed, HIT could be suspended for any one of multiple reasons that ONC defines, which are, de
facto, additional requirements for the certification program through the expanded authority asserted in
this rule for duties associated with the National Coordinator in paragraph (i). Outright suspension should
be limited to only two specific circumstances, (1) an absolute, not potential risk to public health and
safety (which must be clearly defined and limited to specific circumstances), or (2) the absolute failure
to respond as defined in (i), (iii), (iv) or (v) as required.
We recommend that this rule focus on high, exigent and unambiguous risk to public health and safety
(and that other grounds be removed from the proposed regulatory language if this proposal is finalized)
and complete failure to cooperate as defined as the only outright reasons, without further investigation,
which ONC or ONC ACB should consider appropriate for suspension. Until the extent of the potential risk
is actually determined and confirmed, suspension should not be applied. Such punitive action without
just cause serves no useful purpose and could needlessly alarm providers and cause them concern about
using products that are in fact conformant. Certainly, HIT modules could be questioned/alleged as being
non conformant or associated with events labeled patient safety, when in fact, the complaint is not
accurate, in whole or in part. There must be very clear policies to address real nonconformities;
however, there must not be assumptions of guilt and action taken without following the proper policies
implemented to benefit all concerned parties.
ONC has requested comment on the appropriate timeframe for a HIT developer to notify affected or
potentially affected customers of suspension. Based upon the limitations suggested for the basis of
suspension being clearly defined by patient safety or public health, we believe HIT developers already
have policies and procedures in place to define such parameters through their quality management
system and there is no need for ONC to attempt to define or impose a specific minimum timeframe.
We strongly discourage ONC from applying suspension of a specific product to other products that the
HIT developer may be testing or certifying within the certification program. Any suspension should only
apply to the product in question and not to other unrelated products. Applying suspension universally
to a HIT developer under the premise that it would cause the HIT developer to address the
nonconformity any differently could harm providers who may be in need of other HIT from the same
developer. More generally, suspension across the board could totally disrupt the HIT developer product
development cycle and would have profound effects on additional providers unaffected by the
suspended product. We are unaware of this approach to suspension in other regulatory programs.
11

In response to ONCs request for comment regarding correcting the nonconformity for a certain
percentage of customers or certain milestones, we reiterate that suspension should only be applied in
circumstances as we have defined. If defined as such, enabling the correction to the software for the
nonconformity and making it available for implementation could take varying amounts of time to
implement. We believe the important point for lifting the suspension is the availability of the correction
to the customer base and not the absolute implementation by all affected providers as the HIT
developer can encourage implementation but cannot control it. Overall, suspension of the HIT, for
reasons stated above, must be carefully defined. Requirements that such products cannot be marketed
or sold, or inherit certification status should not occur unless there is absolutely a valid reason to take
such action to suspend and cause such consequences.
We especially encourage ONC to consider the impact of the proposals for suspension, limits on how a
suspension may be cured, and potential limits on all products certified by providers and their ability to
adversely affect providers as well as HIT developers with such punitive actions. For example, consider
the impact of a suspension when it is time for providers to attest, or the questions that will arise about
validity of the HIT used in a reporting period. The inability for a developer to update certifications for
products unaffected by the suspension could also have major negative impact on providers.
We are unclear of the ONC definition in the proposed rule of the term encompassed Complete EHR or
HIT Module and ask for clarification of intent from ONC. Likewise, we also ask that ONC provide a clear
definition of cooperate as used in the applicable Preamble language.
12

Review Processes Termination ( 170.580)
(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 ITs 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 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.
13

Review Processes Termination ( 170.580)
As proposed, termination could be implemented without the product in question undergoing a
suspension process; we oppose termination as a first step. We note that ONC could determine that the
nonconformity could not be cured and as such issue a termination. In addition to our concern that
ONC would not necessarily be in a good position to make such a judgment, we are also concerned that
the nonconformity could involve a very small portion of the product and, as further stated in the
proposed rule, any conformity must be corrected without a reduction in scope as the only means to
reacquire certification.
In fact, withdrawal of the HIT module or even the part of the module in question might be the most
satisfactory corrective action to enable the overwhelming majority of the HIT to remain viable in the
marketplace, serving providers needs, and ONC should permit such an outcome. Finally, when a
termination is issued, it should in writing and should include the information which ONC relied upon to
reach its decision, any and all of the documentation and analysis which was used to reach the
termination decision.
As with suspension, we encourage ONC to consider the impact of the proposals regarding termination,
limits on how termination may be cured, and potential limits on all products certified by providers, and
their ability to adversely affect providers as well as HIT developers with such punitive actions. For
example, consider the impact of a termination that occurs when it is time for providers to attest, or the
questions that will arise about the validity of the HIT used during a reporting period. Prohibiting a
developer from updating the certifications for modules or products unaffected by the termination could
also have major negative impact on providers and on innovation.
14

Review Processes Appeal ( 170.580)
(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) ONCs determination was not sufficiently supported by the information used by ONC to reach the
determination.
(2) Method and place for filing an appeal. A request for appeal must be submitted to ONC in writing by an
authorized representative of the health IT developer whose Complete EHR or Health IT Module was subject to the
determination being appealed. The request for appeal must be filed in accordance with the requirements specified
in the notice of termination or notice of suspension.
(3) Time for filing a request for appeal. An appeal must be filed within 10 calendar days of receipt of the notice of
suspension or notice of termination.
(4) Effect of appeal on suspension and termination. (i) A request for appeal stays the termination of a certification
issued to a Complete EHR or Health IT Module, but the Complete EHR or Health IT Module is prohibited from being
marketed or sold as certified during the stay.
(ii) A request for appeal does not stay the suspension of a Complete EHR or Health IT Module.
(5) Appointment of a hearing officer. The National Coordinator will assign the case to a hearing officer to
adjudicate the appeal on his or her behalf. The hearing officer may not review an appeal in which he or she
participated in the initial suspension or termination determination or has a conflict of interest in the pending
matter.
(6) Adjudication. (i) The hearing officer may make a determination based on:
(A) The written record as provided by the health IT developer with the appeal filed in accordance with paragraphs
(f)(1) through (3) of this section and including any information ONC provides in accordance with paragraph (f)(6)(v)
of this section; or
(B) All the information provided in accordance with paragraph (f)(6)(i)(A) and any additional information from a
hearing conducted in-person, via telephone, or otherwise.
(ii) The hearing officer will have the discretion to conduct a hearing if he/she:
(A) Requires clarification by either party regarding the written record under paragraph (f)(6)(i)(A) of this section;
(B) Requires either party to answer questions regarding the written record under paragraph (f)(6)(i)(A) of this
section; or
(C) Otherwise determines a hearing is necessary.
(iii) The hearing officer will neither receive testimony nor accept any new information that was not presented with
the appeal request or was specifically and clearly relied upon to reach the determination issued by ONC under
paragraph (d)(2) or (e)(2) of this section.
(iv) The default process will be a determination in accordance with paragraph (f)(6)(i)(A) of this section.
(v) ONC will have an opportunity to provide the hearing officer with a written statement and supporting
documentation on its behalf that explains its determination to suspend or terminate the certification. The written
statement and supporting documentation must be included as part of the written record. Failure of ONC to submit
a written statement does not result in any adverse findings against ONC and may not in any way be taken into
account by the hearing officer in reaching a determination.
(7) Determination by the hearing officer. (i) The hearing officer will issue a written determination to the health IT
developer within 30 days of receipt of the appeal, unless the health IT developer and ONC agree to a finite
extension approved by the hearing officer.
(ii) The National Coordinators determination on appeal, as issued by the hearing officer, is final and not subject to
further review.
15
16
Review Processes Appeal ( 170.580)

We are unclear on the intent and scope of the first basis for an appeal, (1) ONC incorrectly applied
Program methodology, standards, or requirements for suspension or termination. Given the fairly ad
hoc nature of the grounds for termination or suspension, as discussed above in our review of ONCs
asserted Scope and Authority, we believe that the Program methodology, standards, or requirements
must be much more explicit than proposed if this basis is to be sufficient and not to be an unreasonable
limit on potential appeals. We also seek a standard definition of sufficient support as used in the
second proposed basis for an appeal.
We also disagree with the proposed inability to market/sell as certified during appeal process, which
could have untoward impacts on end users. An appeal should stay the suspension or termination until a
final ruling is issued, including the prohibition on marketing or selling.
We are also concerned that there are no stated requirements for the qualifications of and oversight for
the hearing officer and also are unclear if the hearing officer is an ONC employee or agent. If so, such a
role raises conflicts of interest concerns absent specific processes to ensure independence; we believe
that the hearing officer should have an assured level of independence from ONC management. We also
believe that the developer should always have the right to a hearing and that the decision to hold a
hearing should not be at the sole discretion of the hearing officer. In addition, ONC should have an
obligation to provide a written statement for the hearing process, including any and all information,
analysis and documentation it used (not just relied upon) to come to its determination available to the
developer. Finally, we disagree strongly with the provision that (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. Information that is developed during the course of a hearing should be
able to be considered by the hearing officer.
We agree with the 30 days as proposed for the hearing officer to render a decision and that extensions
should require the consent of both parties. We do oppose, however, the proposal that the National
Coordinators determination, as issued by the hearing officer, would be the agencys final determination
and not subject to further review. We also believe that 10 calendar days to file an appeal, as opposed to
provide notice of intent to appeal, is too short. The materials needed for the appeal could be quite
lengthy and complex. At a minimum, this time should be expressed as business days but we propose
that developers have at least 20 business days to file the appeal.
Consequences of Certification Termination General Comments

ONC notes that this proposed rule does not address the consequences of certification termination
beyond requirements for recertification, especially regarding end users and provider participants in
programs relying on certification for incentive/penalty eligibility. Any consequences of, and remedies
for, termination beyond recertification requirements are stated to be 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. Although we believe that ONC and as applicable the ONC-ACB should
work with the developer to remedy the identified non-conformity, we also believe that instituting such
an approach without corresponding consideration by CMS on implications for providers in the EHR
Incentive Program, and other affected programs is problematic and does not enable a full consideration
of this proposal. For example, prohibiting a developer from updating the certifications for modules or
products unaffected by the termination could also have major negative impact on providers.
Consequences of Certification Termination Program Ban and Heightened Scrutiny ( 170.581)

(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 nonconformity for all affected customers.
Preamble FR Citation: 81 FR 11066 -67
17

Consequences of Certification Termination Program Ban and Heightened Scrutiny ( 170.581)
We oppose the requirement that certified HIT must maintain a scope of certification at least as broad as
was previously in place. This requirement unreasonably hinders the legitimate product decisions of the
developer. Moreover, withdrawal of the HIT module or even the part of the module in question might
be the most satisfactory action to enable the overwhelming majority of the HIT to remain viable in the
marketplace, serving providers needs, and ONC should permit such an outcome. Finally, when a
termination is issued, it should in writing and should include all information on which ONC relied to
reach its decision, any and all of the documentation and analysis which was used to reach the
termination decision.
We are also unclear about how a product that has been terminated for nonconformity against ONC
goals could be tested by an ATL and recertified by an ONC-ACB relative to those nonconformance that
did not involve actual tested certification criteria. ATLs only test and certify against published test
procedures. How would an ATL test to nonexistent certification criteria? We ask that ONC clarify the
relative roles of ONC, the ATLs, and the ONC-ACBs in this testing and certification process.
We also ask that heightened scrutiny be specifically defined, extend for six months only, and only
apply to the functionality that was the subject of the alleged non-conformance.
We strongly oppose the proposed program ban. ONC should not apply termination for a specific
product towards other products that the HIT developer may be testing or certifying within the
certification program. Any termination should only apply to the product in question and not apply to
other unrelated products. Applying termination universally to a HIT developer under the premise that it
would cause the HIT developer to address the nonconformity any differently could undermine additional
providers who may be in need of other HIT or updated certified capabilities from the same developer.
More generally, termination across the board could totally disrupt the HIT developer product
development and innovation cycle and would have profound effects on additional providers unaffected
by the suspended product. We are unaware of this approach to product suspension in other analogous
regulatory programs.
18
19
Consequences of Certification Termination - ONC-ACB Response to a Non-Conformity ( 170.523) and

( 170.581)
Principles of Proper Conduct for ONC-ACBs ( 170.523)
(o) Be prohibited from reducing the scope of a certification when the health IT is under surveillance or under a
corrective action plan.
Consequences Due to the Termination of a Certification ( 170.581)
(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 nonconformity for all affected customers.

See our comments on the prior section - Consequences of Certification Termination Program Ban
and Heightened Scrutiny ( 170.581).
Proposed Amendments to Include ONC-ATLs in the Program - General Comments


Overall, this proposal is reasonable and potentially beneficial. It will be important, however, for ONC
to minimize additional cost burdens on ATLs, which could reduce efficiency, lengthen review time,
reduce ATL program participation, and increase certification costs for developers and, by extension,
providers. ONC should also ensure that this process is consistent with the applicable ISO standards
that have been applied to the ATLs and we support the proposed continued role of the National
Voluntary Laboratory Accreditation Program (NVLAP) in accrediting ATLs.
20
Proposed Amendments to Include ONC-ATLs in the Program Applicability ( 170.501)

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

No comment offered
Proposed Amendments to Include ONC-ATLs in the Program Definitions ( 170.502)
*****
Applicant means a single organization or a consortium of organizations that seeks to become an ONC-ACB or ONCATL 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.
*****

No comment offered
21
Proposed Amendments to Include ONC-ATLs in the Program Correspondence ( 170.505)

(a) Correspondence and communication with ONC or the National Coordinator shall be conducted by e-mail, unless
otherwise necessary or specified. The official date of receipt of any e-mail 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 e-mail 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.
Preamble FR Citation: 81 FR 11062 and 11068

No comment offered
Proposed Amendments to Include ONC-ATLs in the Program - Authorization Scope for ONC-ACB Status
( 170.510)
Applicants for ONC-ACB status may seek authorization from the National Coordinator to perform the following
types of certification:
*****

No comment offered
Proposed Amendments to Include ONC-ATLs in the Program - Authorization Scope for ONC-ATL Status
( 170.511)
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.

We support the proposed amendment that would allow applicants to perform testing and certification
of a single criterion, or portion of a criterion. In this context, we urge ONC to accept certification results
from an organization that has already performed testing and certification of HIT modules that are also
aligned with, or could be aligned with, ONC certification criteria. We encourage these organizations to
pursue such testing and certification as a complement to the existing certification program.
22
Proposed Amendments to Include ONC-ATLs in the Program Application ( 170.520)

(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 e-mail address of the
person who will serve as the applicant's point of contact.
(3) Documentation that confirms that the applicant has been accredited by the ONC-AA.
(4) An agreement, properly executed by the applicant's authorized representative, that it will adhere to the
Principles of Proper Conduct for ONC-ACBs.
(b) ONC-ATL application. Applicants must include the following information in an application for ONC-ATL status
and submit it to the National Coordinator for the application to be considered complete.
(1) The authorization scope sought pursuant to 170.511.
(2) General identifying, information including:
(i) Name, address, city, state, zip code, and web site of applicant; and
(ii) Designation of an authorized representative, including name, title, phone number, and e-mail 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.

No comment offered
Proposed Amendments to Include ONC-ATLs in the Program - Principles of Proper Conduct for ONCACBs ( 170.523)
*****
(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.

No comment offered
23
Proposed Amendments to Include ONC-ATLs in the Program - Principles of Proper Conduct for ONCATLs ( 170.524)
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.

No comment offered
Proposed Amendments to Include ONC-ATLs in the Program - Application Submission ( 170.525)
(a) An applicant for ONC-ACB or ONC-ATL status must submit its application either electronically via e-mail (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.

No comment offered
24
Proposed Amendments to Include ONC-ATLs in the Program -Review of Application ( 170.530)

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

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

No comment offered
25
Proposed Amendments to Include ONC-ATLs in the Program - ONC-ACB and ONC-ATL Status (
170.540)
(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-ATLs 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.

No comment offered
Proposed Amendments to Include ONC-ATLs in the Program - Authorized Testing and Certification
Methods ( 170.557)
(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.

No comment offered
Proposed Amendments to Include ONC-ATLs in the Program - Good Standing as an ONC-ACB or ONCATL ( 170.560)
(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.
26
Proposed Amendments to Include ONC-ATLs in the Program - Good Standing as an ONC-ACB or ONCATL ( 170.560)

No comment offered
Proposed Amendments to Include ONC-ATLs in the Program - Revocation of ONC-ACB or ONC-ATL
Status ( 170.565)
(a) Type-1 violations. The National Coordinator may revoke an ONC-ATL or ONC-ACB's status for committing a
Type-1 violation. Type-1 violations include violations of law or ONC Health IT Certification Program policies that
threaten or significantly undermine the integrity of the ONC Health IT Certification Program. These violations
include, but are not limited to: false, fraudulent, or abusive activities that affect the ONC Health IT Certification
Program, a program administered by HHS or any program administered by the federal government.
(b) Type-2 violations. The National Coordinator may revoke an ONC-ATL or ONC-ACB's status for failing to timely or
adequately correct a Type-2 violation. Type-2 violations constitute noncompliance with 170.560.
(1) Noncompliance notification. If the National Coordinator obtains reliable evidence that an ONC-ATL or ONC-ACB
may no longer be in compliance with 170.560, the National Coordinator will issue a noncompliance notification
with reasons for the notification to the ONC-ATL or ONC-ACB requesting that the ONC-ATL or ONC-ACB respond to
the alleged violation and correct the violation, if applicable.
(2) Opportunity to become compliant. After receipt of a noncompliance notification, an ONC-ATL or ONC-ACB is
permitted up to 30 days to submit a written response and accompanying documentation that demonstrates that
no violation occurred or that the alleged violation has been corrected.
(i) If the ONC-ATL or ONC-ACB submits a response, the National Coordinator is permitted up to 30 days from the
time the response is received to evaluate the response and reach a decision. The National Coordinator may, if
necessary, request additional information from the ONC-ATL or ONC-ACB during this time period.
(ii) If the National Coordinator determines that no violation occurred or that the violation has been sufficiently
corrected, the National Coordinator will issue a memo to the ONC-ATL or ONC-ACB confirming this determination.
(iii) If the National Coordinator determines that the ONC-ATL or ONC-ACB failed to demonstrate that no violation
occurred or to correct the area(s) of non-compliance identified under paragraph (b)(1) of this section within 30
days of receipt of the noncompliance notification, then the National Coordinator may propose to revoke the ONCATL or ONC-ACB's status.
(c) Proposed revocation. (1) The National Coordinator may propose to revoke an ONC-ATL or ONC-ACB's status if
the National Coordinator has reliable evidence that the ONC-ATL or ONC-ACB has committed a Type-1 violation; or
(2) The National Coordinator may propose to revoke an ONC-ATL or ONC-ACB's status if, after the ONC-ATL or
ONC-ACB has been notified of a Type-2 violation, the ONC-ATL or ONC-ACB fails to:
(i) Rebut the finding of a violation with sufficient evidence showing that the violation did not occur or that the
violation has been corrected; or
(ii) Submit to the National Coordinator a written response to the noncompliance notification within the specified
timeframe under paragraph (b)(2) of this section.
(d) Suspension of an ONC-ATL or ONC-ACB's operations. (1) The National Coordinator may suspend the operations
of an ONC-ATL or ONC-ACB under the ONC Health IT Certification Program based on reliable evidence indicating
that:
(i) Applicable to both ONC-ACBs and ONC-ATLs. The ONC-ATL or ONC-ACB committed a Type-1 or Type-2 violation;
(ii) Applicable to ONC-ACBs. The continued certification of Complete EHRs or Health IT Modules by the ONC-ACB
could have an adverse impact on the health or safety of patients.
(iii) Applicable to ONC-ATLs. The continued testing of Complete EHRs or Health IT Modules by the ONC-ATL could
have an adverse impact on the health or safety of patients.

(2) If the National Coordinator determines that the conditions of paragraph (d)(1) of this section have been met, an
ONC-ATL or ONC-ACB will be issued a notice of proposed suspension.
(3) Upon receipt of a notice of proposed suspension, an ONC-ATL or ONC-ACB will be permitted up to 3 days to
submit a written response to the National Coordinator explaining why its operations should not be suspended.
(4) The National Coordinator is permitted up to 5 days from receipt of an ONC-ATL or ONC-ACB's written response
to a notice of proposed suspension to review the response and make a determination.
(5) The National Coordinator may make one of the following determinations in response to the ONC-ATL or ONCACB'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 ONCATL 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 ONCATL 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
27
28
ONC Health IT Certification Program.

No comment offered
Request for Comment - In the Context of an ONC-ATLs Status Being Revoked ( 170.570)

No comment offered
Public Availability of Identifiable Surveillance Results (170.523) and ( 170.556)
Principles of Proper Conduct for ONC-ACBs (170.523)
(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 website on a quarterly basis.
(4) Annually submit a summative report of surveillance results.
In-The-Field Surveillance and Maintenance of Certification for Health IT ( 170.556)
*****
(e) * * *
(1) Rolling submission of in-the-field surveillance results. The results of in-the-field surveillance under this section
must be submitted to the National Coordinator on an ongoing basis throughout the calendar year and, at a
minimum, in accordance with 170.523(i)(2).

Overall, the availability of a more balanced set of surveillance results could provide a more complete
picture of certified EHRs and other HIT. Given the expected positive outcomes of these additional
surveillance results, ONC and the ONC-ACBs should provide summary results, using the general
approach used in the 2015 ONC Certification Final Rule to information to be released on CAPs and the
definition of results.
ONC should also use a definition of results that is a ceiling rather than a floor to ensure program
consistency, that does not include interim work product or information obtained in the course of
surveillance (i.e., that truly focuses on results), and that as proposed, does not include proprietary or
business sensitive information. Results should focus on certified capabilities evaluated and not
indicate why surveillance took place (e.g., provider expressed concern) as such information could
provide a misleading and incomplete picture to consumers of the information. Finally, ONC and the ACB
should clearly indicate that surveillance of specific certified HIT should not imply a problem or potential
problem with the HIT.
29
National Technology Transfer and Advancement Act (NTTAA)

ISO/IEC 17025:2005 (ISO 17025)

No comment offered
Incorporation by Reference (IBR)

ISO/IEC 17025:2005 (ISO 17025)

No comment offered
Collection of Information Requirements

Collection of Information Requirements

No comment offered
Regulatory Impact Statement

Regulatory Impact Statement

No comment offered

GE Healthcare ONC Certification Comments RIN 0955-AA00 April 28 2016 Final

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

GE Healthcare ONC Certification Comments RIN 0955-AA00 April 28 2016 Final

Uploaded by

Copyright:

Available Formats

GE Healthcare

April 28, 2016

Karen DeSalvo, MD, MPH, MSc

3. ONC Direct Review of Certified Health IT

Enable ONC to suspend and/or terminate a certification issued to a Complete Electronic

mission of ONC to create certification concepts to be applied at ONCs sole discretion.

A developers other certified products would be unable to be further certified after

Mark J. Segal, PhD

John Schaeffler, Executive - Government Relations Leader, General Electric Company

Attachment ONC Comment Template

Comments by GE Healthcare IT, April 28, 2016

Office of the National Coordinator for Health IT

Comments by GE Healthcare IT, April 28, 2016

ONC Health IT Certification Program: Enhanced Oversight and Accountability

Specific questions in preamble? No

Public Comment Field:

Comments by GE Healthcare IT, April 28, 2016

Comments by GE Healthcare IT, April 28, 2016

Comments by GE Healthcare IT, April 28, 2016

ONC Review of Certified Health IT - ONC-ACBs Role ( 170.580)

Public Comment Field:

Comments by GE Healthcare IT, April 28, 2016

Review Processes General Comments

Specific questions in preamble? No

Public Comment Field:

Comments by GE Healthcare IT, April 28, 2016

Comments by GE Healthcare IT, April 28, 2016

1. A non-conformance against formalized certification criteria

Review Processes Corrective Action ( 170.580)

Comments by GE Healthcare IT, April 28, 2016

Comments by GE Healthcare IT, April 28, 2016

Comments by GE Healthcare IT, April 28, 2016

Comments by GE Healthcare IT, April 28, 2016

Comments by GE Healthcare IT, April 28, 2016

Comments by GE Healthcare IT, April 28, 2016

Comments by GE Healthcare IT, April 28, 2016

Comments by GE Healthcare IT, April 28, 2016

Review Processes Appeal ( 170.580)

Specific questions in preamble? No

Comments by GE Healthcare IT, April 28, 2016

Consequences of Certification Termination Program Ban and Heightened Scrutiny ( 170.581)

Comments by GE Healthcare IT, April 28, 2016

Comments by GE Healthcare IT, April 28, 2016

Consequences of Certification Termination - ONC-ACB Response to a Non-Conformity ( 170.523) and

Specific questions in preamble? No

Public Comment Field:

Proposed Amendments to Include ONC-ATLs in the Program - General Comments

Specific questions in preamble? Yes

Public Comment Field:

Comments by GE Healthcare IT, April 28, 2016

Proposed Amendments to Include ONC-ATLs in the Program Applicability ( 170.501)

Specific questions in preamble? No

Public Comment Field:

Public Comment Field:

Specific questions in preamble? No

Comments by GE Healthcare IT, April 28, 2016

Proposed Amendments to Include ONC-ATLs in the Program Correspondence ( 170.505)

Specific questions in preamble? No

Public Comment Field:

Specific questions in preamble? No

Public Comment Field:

Specific questions in preamble? No

Public Comment Field: