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

8/17/2019 GE Healthcare ONC Certification Comments RIN 0955-AA00 April 28 2016 Final

1/35

April 28, 2016

Karen DeSalvo, MD, MPH, MScNational Coordinator for Health Information TechnologyAttention: ONC Health IT Certification Program: Enhanced Oversight and AccountabilityU.S. Department of Health and Human ServicesHubert H. Humphrey Building, Suite 729D200 Independence Avenue, S.W.Washington, D.C. 20201

Attention File Code: RIN 0955–AA00

[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 proposedrule: ONC Health IT Certification Program: Enhanced Oversight and Accountability. GEHC, aunit of General Electric Company, has expertise in medical imaging and informationtechnologies, digital health, medical diagnostics, patient monitoring systems, performanceimprovement, drug discovery, and biopharmaceuticals manufacturing technologies. GEHC’shealthcare information technology (HIT) covers a broad span of clinical, administrative, and

financial applications serving customers that range from small physician practices to largeintegrated delivery networks.

GEHC is passionate about how electronic health records (EHRs) and other health IT (HIT) canenhance quality and efficiency and contribute to our nation’s shift to integrated and value-based delivery and payment systems. We are committed to providing products and servicesthat are developed and used with safety as a priority and that facilitate truly meaningful usethat improves health care outcomes, quality and efficiency.

We appreciate ONC’s continued focus on maintaining and enhancing the ONC HITcertification program, This letter provides our key comments on the three major componentsof 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 alsocommend 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 Transparencyand Availability of Surveillance Results and with significant concerns regarding ONC DirectReview of Certified Health IT. Overall, we support the EHR Incentive Program and theassociated HIT certification program and believe that any further changes to both of these

GE HealthcareHealthcare IT

540 W. Northwest Highway

Barrington, IL 60010


2/35 2

programs should further public health and safety, simplification, innovation, and reduction ofregulatory 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 ofNational Voluntary Laboratory Accreditation Program-accredited testing laboratories (labs). Itproposes that such labs apply to become ONC-Authorized Testing Labs (ONC-ATLs). ONC alsoproposes to establish processes to authorize, retain, suspend, and revoke ONC-ATL status.The proposed approach would create authorization and oversight for testing labs intended tobe 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 certif ication costs fordevelopers and, by extension, providers. ONC should also ensure that this process is consistentwith the applicable ISO standards applied to the ATLs and we support the proposed continuedrole 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 publiclyavailable on their websites quarterly, beyond information on non-conformities and correctiveaction plans (CAPs) that must be disclosed today. ONC states that this provision is intended toenhance transparency and accountability of HIT for customers and users by providing“valuable information about the continued performance of certified health IT” and that publicavailability of identifiable results “would provide a more complete context of surveillance bymaking more information about certified products available to purchasers and enablinghealth 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 positiveresults of surveillance to be made available. It states that surveillance results would includeinformation such as, but not limited to: names of HIT developers; names of products andversions; certification criteria and Program requirements surveilled; and outcomes ofsurveillance. ONC also emphasizes that it does not propose to require that publicly postedsurveillance 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 morecomplete picture of certified EHRs and other HIT. Given the likely positive outcomes of theseadditional surveillance results, ONC and the ONC-ACBs should provide summary results, usingboth 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 programconsistency, that does not include interim work product or information obtained in the courseof surveillance (i.e., disclosure should truly focused on results), and that as proposed, does notinclude proprietary or business sensitive information. “Results” should emphasize certifiedcapabilities evaluated and not indicate why surveillance took place (e.g., provider expressedconcern) as such information could provide a misleading and incomplete picture to consumersof the information. Finally, ONC and the ACB should clearly indicate that surveillance of specificcertified HIT should not imply a problem or potential problem with the HIT.


3/35 3

3. ONC Direct Review of Certified Health IT

ONC proposes that, in addition to review of certified HIT by ONC-ACBs, it would directlyreview certified HIT and act when necessary to “promote health IT developer accountabilityfor the performance, reliability, and safety of health IT”. ONC’s primary stated goal is to workwith 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 terminationprocesses. These provisions are framed as a complement to current paths of review forcertified HIT through ONC-ACBs and “provide an additional tool to address public health andsafety issues that may arise”.

ONC would have very broad discretion to review certified HIT. It anticipates that such reviewwould be relatively infrequent and would focus on situations posing a risk to public health orsafety, but believes “there could be other exigencies, distinct from public health and safetyconcerns, which for similar reasons would warrant ONC’s direct review and action.”

The focus on public health and safety and “other exigencies” is stated to be grounded inONC’s statutory responsibility to keep or recognize a certification program(s) “in a manner

consistent with the development of a nationwide health information technologyinfrastructure that allows for the electronic use and exchange of information and that,among other requirements: ensures that each patient’s health information is secure andprotected, in accordance with applicable law; improves health care quality; reduces medicalerrors; reduces health care costs resulting from inefficiency, medical errors, inappropriatecare, duplicative care, and incomplete information; and promotes a more effectivemarketplace, greater competition, greater systems analysis, increased consumer choice, andimproved outcomes in health care services (see section 3001(b) of the PHSA).” Non-conformance with any one of these goals, even if the goal was not part of certification, wouldbe 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 existconcerning the product, or due to certain actions or inactions by the product’s health ITdeveloper as detailed”. Per 170.580(d)(1)(i), “ONC would suspend a certification issued to anyencompassed Complete EHR or Health IT Module of the certified health IT if the certifiedhealth IT was, but not limited to: “contributing to a patient’s health information beingunsecured and unprotected in violation of applicable law; increasing medical errors;decreasing the detection, prevention, and management of chronic diseases; worsening theidentification and response to public health threats and emergencies; leading toinappropriate care; worsening health care outcomes; or undermining a more effectivemarketplace, greater competition, greater systems analysis, and increased consumerchoice.” This listing is also justified as based on ONC’s 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-ACB’s 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 isintended to support), which may be caused by the interaction of certified and uncertifiedcapabilities within certified health IT;

• Prescribe comprehensive corrective actions for developers to address nonconformities,including notifying affected customers;


4/35 4

• Enable ONC to suspend and/or terminate a certification issued to a Complete ElectronicHealth Record (EHR) or Health IT Module;

• Institute processes for prohibiting further testing and certification of any health IT that ahealth IT developer brings to ONC if a found non-conformity is not first corrected or willbe 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. AlthoughONC asserts that this authority would be invoked only infrequently, there is no guarantee ofsuch a limited approach, especially as ONC leadership changes in coming years. We haveseveral concerns summarized below and expanded upon in our more detailed comments. Wealso 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 onhypotheticals rather than documented problems that would be best remedied by direct reviewusing the expanded set of de facto criteria that are proposed, and we therefore oppose theprovisions for direct review, especially as they depart from evaluation against the certification

criteria established by regulation and associated test methods. Moreover, based on ourunderstanding 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 suff icient organizational andregulatory capacity or framework for direct review.

Second, ONC appears to be substantially overstating the authority and responsibilityestablished in Section 3001(b) of the PHSA as it relates to this certif ication proposal. Thissection sets out the high-level goals to be pursued by ONC, described as “development of anationwide health information technology infrastructure that allows for the electronic use andexchange of information” and has 11 more specific goals, many of which are called out in thisproposed rule. To accomplish these goals, ONC is to carry out eight broad duties set out inSection 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 tofurther the statutory goals.

It seems inconceivable that Congress intended that each of the duties individually was to beimplemented 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 ofhealth information technology as being in compliance with applicable certification criteriaadopted under this subtitle.“ Congress was also clear on the nature of the certification criteriato be used in the certification program, stating that “the term ‘certification criteria’ means, withrespect to standards and implementation specifications for health information technology,criteria to establish that the technology meets such standards and implementationspecifications.” 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 theSecretary through rule-making. It is clear that Congress intended the process by which suchcriteria are developed and implemented to support , along with other ONC duties, the broadgoals set for ONC in HITECH.

Through three regulatory cycles, ONC has developed certification criteria, the heart of thecertification program and its statutory construct. In this proposed rule, ONC, over seven yearsafter passage of HITECH, and after these three cycles, discovers new authority and proposes asubstantially new certification program unmoored from certification criteria developed perstatute and regulation, and one that looks back to the super-set of HITECH goals for the entire


5/35 5

mission of ONC to create certification “concepts” to be applied at ONC’s sole discretion.

In taking this approach, ONC is fundamentally redefining, via §170.580(a), the “requirements ofthe ONC Health IT Certification Program” as beyond the published certification criteria when itstates that “ONC may directly review certified health IT whenever there is reason to believe thatthe certified health IT may not comply with requirements of the ONC Health IT CertificationProgram,” 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 needfor intervention are very broad and include “[t]he potential risk to public health or safety” andthe catchall “or other exigent circumstances” without a defined set of specific criteria that canguide our product development and implementation.

This vast expansion of ONC authority, which seems at odds with Congressional intent and theunderlying statute, is especially troubling because:

o Commenters and stakeholders must rely on the current ONC’s stated desire forlimited use of this authority when there is no guarantee that limited applicationwould be the approach taken in later years and Administrations;

o 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 ITdevelopers or ONC-ACBs and for which there is no objective basis to assesscompliance nor even any clear duty for compliance;

o ONC seeks a broad expansion of its authority to non-certified health IT and also toapply pressure on firms that develop health IT relative to all of their certifiedproducts to ensure compliance with issues with a portion of any single product,which could hinder innovation sought by providers; and

o 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 allevaluations data-driven and evidence-based.

• If ONC chooses to proceed in the general direction proposed, we believe that it should veryrarely need to intervene due to ONC-ACB limitations, should refine the applicable languagedealing with such limitations and should focus only on the most exigent (defined as“requiring immediate attention: needing to be dealt with immediately”) safety-relatedissues and not all of the strategic goals set out for ONC in HITECH. ONC should also onlyfocus on conformance, including safe conformance, to certified capabilities and not to anad hoc and implied set of new criteria as is proposed. In addition, ONC should establishclear requirements for what information must be presented as part of an externalallegation 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 thedeveloper 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;


6/35 6

o A developer’s other certified products would be unable to be further certified after

termination for one certified product (and possibly suspension);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;o Insufficient time for vendor response to ONC inquiries and to submit an appeal;o

Excessive, overly broad and likely very costly Records Access requirements;o Overly restrictive appeals processes and lack of clear expertise and independence

for hearing officers – unlike the proposal, developers should always be able torequest a hearing and information developed as a result of the hearing should beable to be considered by the hearing officer;

o The inability of an appeal to stay the ONC marketing cease and desist order;o 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; ando 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 developerstime to adjust processes as needed.

***We appreciate ONC’s 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 tothose of our industry partners, such as the Electronic Health Records Association, HIMSS, andAMIA. GE Healthcare appreciates the opportunity to submit comments on these importantissues. If you have questions on our comments, please do not hesitate to contact me.

Sincerely,

Mark J. Segal, PhD

Vice President, Government and Industry AffairsGE Healthcare IT

847.946.1428

[email protected]

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

Attachment – ONC Comment Template

mailto:[email protected]:[email protected]:[email protected]


7/35

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



8/35


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-ACB’s accreditation;

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

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

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

Preamble FR Citation: 81 FR 11060 - 61 Specific questions in preamble? Yes


9/35



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 inSection 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 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 ONC’s sole discretion.


10/35


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]hepotential 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 ONC’s 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.

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

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

o

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 statuteand 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 developer’s other certified products would be unable to be further certified after

termination for one certified product (and possibly suspension)


11/35


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

o Insufficient time for vendor response to ONC inquiries and to submit an appeal

o Excessive, overly broad and likely very costly Records Access requirements

o Overly restrictive appeals processes and lack of clear expertise and independence for

hearing officers – unlike the proposal, developers should always be able to request ahearing and information developed as a result of the hearing should be able to be

considered by the hearing officer

o The inability of an appeal to stay the ONC marketing cease and desist order

o 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-ACB’s Role (§ 170.580)

(2) Relationship to ONC-ACB’s oversight. (i) ONC’s review of certified health IT is independent of, and may be in

addition to, any review conducted by an ONC-ACB.

(ii) ONC may assert exclusive review of certified health IT as to any matters under review by ONC and any other

matters so intrinsically linked that divergent determinations between ONC and an ONC-ACB would be inconsistentwith the effective administration or oversight of the ONC Health IT Certification Program.

(iii) ONC’s determination on matters under its review is controlling and supersedes any determination by an ONC-

ACB on the same matters.

(iv) An ONC-ACB shall provide ONC with any available information that ONC deems relevant to its review of

certified health IT.

(v) ONC may end all or any part of its review of certified health IT under this section and refer the applicable part of

the review to the relevant ONC-ACB(s) if ONC determines that doing so would be in the best interests of efficiency

or the administration and oversight of the Program.

Preamble FR Citation: 81 FR 11061 - 62 Specific questions in preamble? No


Overall, as stated regarding Authority and Scope, we believe that ONC should rely on the ONC-ACB-

focused process against published certification criteria.

We are especially concerned with i and ii:

(i) ONC’s review of certified health IT is independent of, and may be in addition to, any review

conducted by an ONC-ACB.

(ii) ONC may assert exclusive review of certified health IT as to any matters under review by ONC

and any other matters so intrinsically linked that divergent determinations between ONC and an

ONC-ACB would be inconsistent with the effective administration or oversight of the ONC Health

IT Certification Program.

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


12/35


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

conformity or notice of non-conformity to the health IT developer if it has information that certified health IT is not

or may not be performing consistently with Program requirements.

(i) Potential non-conformity. ONC may require that the health IT developer respond in more or less time than 30

days based on factors such as, but not limited to:

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

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

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

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

(ii) Non-conformity. ONC may require that the health IT developer respond and submit a proposed corrective

action plan in more or less time than 30 days based on factors such as, but not limited to:

(A) The type of certified health IT and certification in question;(B) The type of non-conformity to be corrected;

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

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

(2) Records access. In response to a notice of potential non-conformity or notice of non-conformity, a health IT

developer shall make available to ONC and for sharing within HHS, with other federal agencies, and with

appropriate entities:

(i) All records related to the development, testing, certification, implementation, maintenance and use of its

certified health IT; and

(ii) Any complaint records related to the certified health IT.

(3) Health IT developer response. The health IT developer must include in its response all appropriate

documentation and explain in writing why the certified health IT is conformant.



13/35


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 toavoid 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 non-

conformance 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 non-

conformance 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 non-

conformance, who would be eligible to make such reports, and also to emphasize that the first recourseshould 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 non-

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


14/35


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

conformity(ies). The corrective action plan is required to include, at a minimum, for each non-conformity:

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

(ii) An assessment of the nature, severity, and extent of the non-conformity, including how widespread they may

be across all of the health IT developer’s customers of the certified health IT;(iii) How the health IT developer will address the identified non-conformity, both at the locations where the non-

conformity was identified and for all other potentially affected customers;

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

including:

(A) Identifying all potentially affected customers;

(B) How the health IT developer will promptly ensure that all potentially affected customers are notified of the

non-conformity and plan for resolution;

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

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

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

(3) When ONC receives a proposed corrective action plan (or a revised proposed corrective action plan), it shall

either approve the proposed corrective action plan or, if the plan does not adequately address all required

elements, instruct the developer to submit a revised proposed corrective action plan.

(4) Upon fulfilling all of its obligations under the corrective action plan, the health IT developer must submit an

attestation to ONC, which serves as a binding official statement by the health IT developer that it has fulfilled all of

its obligations under the corrective action plan.

(5) ONC may reinstitute a corrective action plan if it later determines that a health IT developer has not fulfilled all

of its obligations under the corrective action plan as attested in accordance with paragraph (c)(4) of this section.

Preamble FR Citation: 81 FR 11063 - 64 Specific questions in preamble? No


15/35


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 correctiveaction 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 non-

conformance 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 non-

conformance 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” correctionof 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 provider’s

implementation within the required timeframe as some providers may not immediately implement the

software update or modify their workflow.


16/35


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 patient’s health information being unsecured and unprotected in violation of

applicable law; increasing medical errors; decreasing the detection, prevention, and management of chronic

diseases; worsening the identification and response to public health threats and emergencies; leading to

inappropriate care; worsening health care outcomes; or undermining a more effective marketplace, greater

competition, greater systems analysis, and increased consumer choice;

(ii) The health IT developer fails to timely respond to any communication from ONC, including, but not limited to:

(A) Fact-finding;

(B) A notice of potential non-conformity within the timeframe established in accordance with paragraph (b)(1)(i) of

this section; or

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

section;

(iii) The information provided by the health IT developer in response to any ONC communication, including, but

not limited to: fact-finding, a notice of potential non-conformity, or a notice of non-conformity is insufficient orincomplete;

(iv) The health IT developer fails to timely submit a proposed corrective action plan that adequately addresses the

elements required by ONC as described in paragraph (c) of this section;

(v) The health IT developer does not fulfill its obligations under the corrective action plan developed in accordance

with paragraph (c) of this section.

(2) When ONC decides to suspend a certification, ONC will notify the health IT developer of its determination

through a notice of suspension.

(i) The notice of suspension will include, but may not be limited to:

(A) An explanation for the suspension;

(B) The information ONC relied upon to reach its determination;

(C) The consequences of suspension for the health IT developer and the Complete EHR or Health IT Module under

the ONC Health IT Certification Program; and

(D) Instructions for appealing the suspension.

(ii) A suspension of a certification will become effective upon the health IT developer’s receipt of a notice of

suspension.

(3) The health IT developer must notify all affected and potentially affected customers of the identified non-

conformity(ies) and suspension of certification in a timely manner.

(4) If a certification is suspended, the health IT developer must cease and desist from any marketing and sale of the

suspended Complete EHR or Health IT Module as “certified” under the ONC Health IT Certification Program from

that point forward until such time ONC may rescind the suspension.

(5) Inherited certified status certification for a suspended Complete EHR or Health IT Module is not permitted until

such time ONC rescinds the suspension.

(6) ONC will rescind a suspension of certification if the health IT developer completes all elements of an approved

corrective action plan and/or ONC confirms that all non-conformities have been corrected.



17/35


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


18/35


In response to ONC’s 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.


19/35


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 IT’s non-conformity(ies) cannot be cured.

(2) When ONC decides to terminate a certification, ONC will notify the health IT developer of its determination

through a notice of termination.

(i) The notice of termination will include, but may not be limited to:(A) An explanation for the termination;

(B) The information ONC relied upon to reach its determination;

(C) The consequences of termination for the health IT developer and the Complete EHR or Health IT Module under

the ONC Health IT Certification Program; and

(D) Instructions for appealing the termination.

(ii) A termination of a certification will become effective either upon:

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

by the health IT developer; or

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

files an appeal.

(3) The health IT developer must notify affected and potentially affected customers of the identified non-

conformity(ies) and termination of certification in a timely manner.

(4) If ONC determines that a Complete EHR or Health IT Module certification should not be terminated, ONC will

notify the health IT developer in writing of this determination.

Preamble FR Citation: 81 FR 11065 Specific questions in preamble? Yes


20/35


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


21/35


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) ONC’s determination was not sufficiently supported by the information used by ONC to reach the

determination.

(2) Method and place for filing an appeal. A request for appeal must be submitted to ONC in writing by an

authorized representative of the health IT developer whose Complete EHR or Health IT Module was subject to the

determination being appealed. The request for appeal must be filed in accordance with the requirements specified

in the notice of termination or notice of suspension.

(3) Time for filing a request for appeal. An appeal must be filed within 10 calendar days of receipt of the notice of

suspension or notice of termination.

(4) Effect of appeal on suspension and termination. (i) A request for appeal stays the termination of a certification

issued to a Complete EHR or Health IT Module, but the Complete EHR or Health IT Module is prohibited from being

marketed or sold as “certified” during the stay.

(ii) A request for appeal does not stay the suspension of a Complete EHR or Health IT Module.

(5) Appointment of a hearing officer. The National Coordinator will assign the case to a hearing officer to

adjudicate the appeal on his or her behalf. The hearing officer may not review an appeal in which he or she

participated in the initial suspension or termination determination or has a conflict of interest in the pendingmatter.

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

(A) The written record as provided by the health IT developer with the appeal filed in accordance with paragraphs

(f)(1) through (3) of this section and including any information ONC provides in accordance with paragraph (f)(6)(v)

of this section; or

(B) All the information provided in accordance with paragraph (f)(6)(i)(A) and any additional information from a

hearing conducted in-person, via telephone, or otherwise.

(ii) The hearing officer will have the discretion to conduct a hearing if he/she:

(A) Requires clarification by either party regarding the written record under paragraph (f)(6)(i)(A) of this section;

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

section; or

(C) Otherwise determines a hearing is necessary.

(iii) The hearing officer will neither receive testimony nor accept any new information that was not presented with

the appeal request or was specifically and clearly relied upon to reach the determination issued by ONC under

paragraph (d)(2) or (e)(2) of this section.

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

(v) ONC will have an opportunity to provide the hearing officer with a written statement and supporting

documentation on its behalf that explains its determination to suspend or terminate the certification. The written

statement and supporting documentation must be included as part of the written record. Failure of ONC to submit

a written statement does not result in any adverse findings against ONC and may not in any way be taken into

account by the hearing officer in reaching a determination.

(7) Determination by the hearing officer. (i) The hearing officer will issue a written determination to the health IT

developer within 30 days of receipt of the appeal, unless the health IT developer and ONC agree to a finite

extension approved by the hearing officer.

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



22/35


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 ONC’sasserted 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

Coordinator’s determination, as issued by the hearing officer, would be the agency’s 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



23/35



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 providersparticipating 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 itscertification terminated can be tested and recertified (certified) once all non-conformities have been adequately

addressed.

(1) The recertified Complete EHR or Health IT Module (or replacement version) must maintain a scope of

certification that, at a minimum, includes all the previous certified capabilities.

(2) The health IT developer must request, and have approved, permission to participate in the Program before

testing and recertification (certification) may commence for the Complete EHR or Health IT Module (or

replacement version).

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

the termination.

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

(b) Heightened scrutiny. Certified health IT that was previously the subject of a certification termination (or

replacement version) shall be subject to heightened scrutiny for, at a minimum, one year.

(c) Program ban. The testing and certification of any health IT of a health IT developer that has the certification of

one of its Complete EHRs or Health IT Modules terminated under the Program or withdrawn from the Program

when the subject of a potential nonconformity or non-conformity is prohibited, unless:

(1) The non-conformity is corrected and implemented for all affected customers; or

(2) The certification and implementation of other health IT by the health IT developer would remedy the non-

conformity for all affected customers.

Preamble FR Citation: 81 FR 11066 -67 Specific questions in preamble? Yes


24/35


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 themarketplace, 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 analogousregulatory programs.


25/35


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 (orreplacement version) shall be subject to heightened scrutiny for, at a minimum, one year.

(c) Program ban. The testing and certification of any health IT of a health IT developer that has the certification of

one of its Complete EHRs or Health IT Modules terminated under the Program or withdrawn from the Program

when the subject of a potential nonconformity or non-conformity is prohibited, unless:

(1) The non-conformity is corrected and implemented for all affected customers; or

(2) The certification and implementation of other health IT by the health IT developer would remedy the non-

conformity for all affected customers.



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

Preamble FR Citation: 81 FR 11068 Specific questions in preamble? Yes


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 standardsthat have been applied to the ATLs and we support the proposed continued role of the National

Voluntary Laboratory Accreditation Program (NVLAP) in accrediting ATLs.


26/35


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 fol low 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 ONC-

ATL by submitting an application to the National Coordinator for such status.

* * * * *

Gap certification means the certification of a previously certified Complete EHR or Health IT Module(s) to:

(1) All applicable new and/or revised certification criteria adopted by the Secretary at subpart C of this part based

on test results issued by a NVLAP-accredited testing laboratory under the ONC Health IT Certification Program or

an ONC-ATL; and

(2) All other applicable certification criteria adopted by the Secretary at subpart C of this part based on the test

results used to previously certify the Complete EHR or Health IT Module(s) under the ONC Health IT Certification

Program.

* * * * *

ONC-Authorized Testing Lab or ONC-ATL means an organization or a consortium of organizations that has applied

to and been authorized by the National Coordinator pursuant to this subpart to perform the testing of Complete

EHRs and Health IT Modules to certification criteria adopted by the Secretary at subpart C of this part.

* * * * *



No comment offered


27/35


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 Specific questions in preamble? No


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


28/35


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

ACBs (§ 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 lon

Documents

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