Health knowledge made personal
Join this community!
› Share page:
Go
Search posts:

CCHIT Submits Comments on Interim Final Rule on Standards, Implementation Specifications, and Certification Criteria for EHRs

Posted Mar 12 2010 8:00am
The Certification Commission for Health Information Technology (CCHIT®) today submitted its public comments on the Interim Final Rule (IFR) entitled “Health Information Technology: Initial Set of Standards, Implementation Specifics, and Certification Criteria for Electronic Health Record Technology” to the Office of the National Coordinator (ONC).

“We congratulate ONC on development of the IFR, but we believe the criteria and standards need refinement in order to drive an achievable step forward in the meaningful use of EHRs,” said Mark Leavitt, M.D., Ph.D., chair of the Certification Commission, adding that the Commission is “concerned about the possibility of an unintended deceleration in the pace of EHR adoption.”

The comments highlight three broad concerns about the IFR requirements
  • Under the IFR, the scope of a ‘Complete EHR’ inappropriately includes administrative and billing functions, diverting funds and effort into unnecessary certifications of already-installed billing systems for every doctor and hospital seeking the EHR incentives.
  • Certain criteria and standards in the IFR may represent a step backwards in progress toward EHR interoperability, by dropping standards that were already federally-recognized and widely adopted, while other criteria demand an unrealistic leap forward.
  • Some IFR criteria define required functions of an EHR too microscopically, adding unnecessary costs and complexity, and creating barriers to innovation.

The Commission also commented on the regulatory impact analysis required as part of the rule making process. While the IFR concludes that the new rules would not impact a significant number of small businesses, the Commission supplied data and analysis indicating the impact would be very substantial.

A copy of the comments, including a more detailed analysis is below
The Certification Commission for Health Information Technology (CCHIT) respectfully submits these comments on the Interim Final Rule (45 CFR Part 170, RIN 0991-AB58), published in the Federal Register of Jan 13, 2010, “Health Information Technology: Initial Set of Standards, Implementation Specifications, and Certification Criteria for Electronic Health Record Technology.”

Evidence Base
CCHIT has the most extensive experience in this country developing voluntary, consensus-based EHR certification criteria and test processes, and inspecting and certifying EHRs against Federally-recognized standards.[1] The Commission’s comments draw upon this deep base of practical experience.

Overview
The Certification Commission congratulates HHS and ONC on producing the Interim Final Rule within the statutory deadline. CCHIT is well aware of the challenges faced and the balances that had to be struck in a time-constrained environment. After careful review, however, the Commission believes that the certification criteria and standards in the IFR -- while an admirable first draft effort – need improvement and refinement to drive an achievable step forward in the meaningful use of EHRs, and to avoid an unintended deceleration in the pace of EHR adoption.
Before offering detailed suggestions, the Commission wishes to highlight three overarching concerns with the IFR as written:
  • Scope. While “Complete EHR”sounds like a desirable certification, the package of requirements in the IFR may not match the needs and expectations of doctors and hospitals, nor the realities of the marketplace, for EHRs. By including two functions of an administrative/billing system in the scope of EHR certification, ONC may exclude one third or more of the offerings in the current EHR marketplace, while suddenly forcing hundreds of billing products to undergo unnecessary certifications. In other areas, the scope falls short of being complete: for example, an EHR that does not offer competent electronic management of progress notes would be unusable and medico-legally unsound, and an EHR that fails to prominently display patient advance directives in an emergency could compromise patients’ rights at their time of greatest vulnerability.
  • Interoperability. The Commission and its expert volunteer panels believe that certain criteria and standards in the IFR represent a step backwards in progress toward EHR interoperability. For example, well-defined standards for receiving electronic laboratory results in the doctor’s office and for exchanging clinical summaries had already been recognized by the Federal government and widely supported by industry – as evidenced by the certification of over 80 EHR products to those standards in 2008. Yet under the IFR, that standard for receiving laboratory results, and the specific implementation guidance for exchanging clinical data, have been dropped. Where one standard was previously recognized for clinical data exchange, the IFR offers two different, incompatible standards. Conversely, other interoperability criteria in the IFR, such as the requirement that EHRs be capable of transmitting biosurveillance data to public health authorities, could immediately increase EHR cost and complexity while benefits remain years away because public health authorities lack standards-compliant infrastructure and systems for receiving that data.
  • Functionality. Some of the IFR criteria define required functionalities of an EHR too microscopically, adding unnecessary complexity and creating barriers to innovation. Other criteria are too vague to be reliably verified in a testing process, creating a risk that the expectations of providers, payers, and the public regarding the performance, safety, and benefits of Certified EHRs will not be met. A particular concern surrounds the reporting of quality measures, with the IFR calling for standards and measures that are yet to be defined or that require significant revision to make them computable from EHR-based data.
These issues, however, can be resolved through refinements to the criteria and standards in the IFR, suggested in detail below.  With appreciation for the task ONC faces in reviewing an anticipated large volume of comments, the Commission offers these comments in order of priority, with the most critical issues first.
Specific Comments on Criteria and Standards in the Interim Final Rule
§170.302(j) and 170.302(k) General Certification Criteria for Complete EHRs or EHR Modules; Check insurance eligibility; Submit claims
Issues: The Commission wishes to emphasize that this issue, of all the others, has the greatest potential for an unintended consequence that runs counter to the goals of HITECH.
  1. In the health IT marketplace, electronic eligibility and claim submission are functions of office billing and hospital financial systems. While some of the largest vendors offer both of these applications, many innovative EHR products have emerged from companies focusing on the challenging task of clinical information management, rather than competing in the mature marketplace for financial systems. Defining these administrative functions as part of a Complete EHR for certification purposes would create a major barrier to entry for EHR innovators.
  2. The adoption of computerized billing and financial applications is already near 100%, and there is a natural incentive (more efficient revenue collection) for their usage. There is no justification for diverting HITECH incentives toward this area and away from the real challenge of EHR adoption and use by clinicians.
  3. While increasing the utilization of electronic claims submission is a desirable goal, CMS and State Medicaid programs have more direct legal and regulatory mechanisms at their disposal to accomplish this.  
Recommendation: Drop criteria 170.302(j) and (k) from the Final Rule. If that is not possible, revise the definition of “Complete EHR” to make inclusion of these two modules optional, but with clear labeling required. While electronic claims submission could be retained as a Meaningful Use goal, the Commission recommends that this form of compliance it should instead be driven through existing Medicare and Medicaid regulatory mechanisms.
§170.302(i)(1) and 170.302(i)(2) General Certification Criteria for Complete EHRs or EHR Modules; Report quality measures; Display; Submission 
Issue: Item (1) requires calculation and display of “quality measures as specified by CMS or states”. This statement is too vague to be reliably tested. Most of the measures proposed in the NPRM still require significant revision to make them computable from EHR-based data; the denominators of many of these measures would require manual audits. Furthermore, the standard adopted for submission in (2) is not appropriate (see comment on §170.205(e) below).
Recommendation: These criteria should be dropped from Stage 1. A concise set of measures and an accompanying standard for data submission should be developed and defined in time for Stage 2 of Meaningful Use requirements.
§170.205(e) Content exchange and vocabulary standards for exchanging electronic health information; Electronically exchange quality reporting information 
Issue: The standard adopted, the CMS PQRI 2008 Registry XML Specification, was designed for ambulatory data reporting, not hospital data reporting. The standard is incomplete without an accompanying “XSD style sheet,” which does not exist. 
Recommendation: This standard requirement should be dropped from Stage 1. Standards for eligible provider and hospital quality data submission should be developed and defined in time for Stage 2 of Meaningful Use requirements.
§170.205(a) Content exchange and vocabulary standards for exchanging electronic health information; Patient summary record
Issue: This IFR criterion allows two different, incompatible content exchange standards for a patient summary record. Although requiring EHRs to be able to display the ‘alternate’ standard in a human readable format partially mitigates the issue, this results in the loss of structured data and an increase in the possibility of human error. Safety-focused EHR functionalities such as clinical decision support and medication reconciliation are significantly compromised by this loss of structured data.

Recommendations:  
  1. Demonstrate year-to-year consistency in Federal health IT standards leadership by making the Federally-recognized CCD standard and associated implementation guides the required, or at least clearly preferred, format for HITECH certification.
  2. If the above is not possible, clarify the transactions for which each standard applies (e.g., CCD for exchanges between professionals, and CCR for transmission to PHRs and consumer platforms). This approach would reduce the incidence of lost data structure in provider EHRs where critical clinical decision support takes place.
§170.302(g)(1) General Certification Criteria for Complete EHRs or EHR Modules; Incorporate laboratory test results; Receive results 
Issue: The IFR appropriately requires the ability to receive clinical laboratory results in a structured format. However, it inexplicably fails to specify a standard format for the laboratory results that the EHR must be capable of accepting. Receiving external laboratory results is the first and most important form of interoperability for EHRs in ambulatory care. The HL7 v2.5.1 format has been Federally recognized since 2006 for the purpose of receiving laboratory results in ambulatory settings, and CCHIT has tested and certified 142 ambulatory EHR products for compliance with that standard since 2007.
Recommendation: The certification criterion for receiving laboratory test results should be split into different versions for ambulatory settings and for hospitals. For ambulatory settings, the EHR requirement should include compliance with the HL7 2.5.1 standard. Note that this particular standard is already included in the IFR, but currently only applies when submitting lab results to public health agencies. It should be extended to apply to the laboratory results receiving transaction as well.
§170.202 Transport Standards for exchanging electronic health information
Issue: This IFR criterion allows two different, incompatible methods for transport of information, neither of which is sufficiently specified to ensure interoperability, and neither of which will deliver real-world data exchange until additional layers of standards and infrastructure are developed and widely adopted and deployed. The credibility of HITECH certification of EHRs could be seriously damaged by providing a false sense of assurance that EHRs offer “plug and play” readiness to  exchange data with other HITECH-certified EHRs.
Recommendations:
  1. Inclusion of these as “Transport Standards” when they do not yet, in fact, assure end users of an ability to exchange data is deceptive. The item should be converted from a Standard to a point of guidance or roadmap regarding standards under development for future use.
  2. In lieu of removing this item, if two alternative standards must be retained in the Final Rule, clearly specify the transactions for which each applies (e.g. SOAP for data exchange within enterprises or established networks, REST for communications with external entities such as providers outside the network or PHR platforms).
§170.302(a) General Certification Criteria for Complete EHRs or EHR Modules; Drug-drug, drug-allergy, drug-formulary checks
Issues: This criterion delves into an inappropriate level of design detail within EHRs, including features which are inappropriate or potentially harmful to adoption of EHRs and advancement of the technology.
  1. §170.302(a)(1) Alerts would require real-time alerts, with the example of a “pop-up message or sound” in Table 1. Some usability experts would point out that pop-up alerts and sounds are a major source of user distraction and rejection of EHRs; better designs guide users toward making safe choices rather than interrupting them repeatedly. Such innovation is unlikely to emerge with a rigid standard constraining the design.
  2. 170.302(a)(2) Formulary Checks requires formulary / preferred drug list checking as a general specification for all EHRs, yet this functionality is only appropriate for office-based providers. In hospitals, this function is accomplished before drugs ever appear in the EHR ordering lists.
  3. §170.302(a)(3) Customization requires certain users have rights to deactivate, modify, and add rules for drug-drug and drug-allergy checking. Most organizations do not maintain this list themselves, and instead subscribe to an external knowledge source. Forcing the provision of abilities to make local modifications compromises the integrity of the knowledge base, breaks the chain of accountability, and puts patient safety at risk.
  4. §170.302(a)(4) Alert Statistics requires tracking and reporting on “the number of alerts responded to by a user.” The language does not define what is meant by “responded to by a user”: Changed the order as a result of the alert? Entered a reason for overriding the alert? Dismissed the alert without changing the order? Requiring this tracking also further serves to force the EHR designer to use interruptive alerts and to “count mistakes caught” rather than designing prospective guidance to prevent the mistakes in the first place.
Recommendations:  
  1. §170.302(a)(1) Delete “pop-up message or sound” from the appropriate row in Table 1.
  2. §170.302(a)(2) Remove item from §170.302 General Certification Criteria, and move to §170.304 Specific Certification Criteria for Ambulatory Settings.
  3. §170.302(a)(3) This item has greater risk of harm than benefit and should be removed.
  4. §170.302(a)(4) Unless more clearly specified, this item has greater risk of harm than benefit and should be removed.
§170.302(e)(3) General Certification Criteria for Complete EHRs or EHR Modules; Record and chart vital signs; Plot and display growth charts
Issues:
  1. The Commission and its Child Health work group recognize the importance of including growth chart functionality in every EHR used in the care of children, and has since 2008 required that capability – and others – for optional certification of EHRs as having Child Health capabilities. However, a significant number of vendors develop EHRs that focus on specialties and settings that do not serve children or adolescents. Forcing this capability into all EHRs adds unnecessary cost and complexity and diverts development effort away from other specialized clinical needs.
  2. The IFR requires height and weight growth charts from age 2 to 20, but omits any requirement for charting weight, length, and head circumference from age 0 to 36 months. HITECH-certified EHRs would not be assured to include functionalities for safe care of the youngest children.
  3. The IFR fails to require display of normative data alongside the measured patient data, greatly reducing the clinical usefulness of growth charts. 
Recommendations: 
In the absence of a structure for certifying specialty-specific EHRs, ONC should drop the requirement for growth charts and rely on EHR purchasers to check for this functionality.
Alternatively, ONC might retain the requirement for growth charts, but add requirements to display normative data and to capture and chart weight, length, and head circumference for children aged 0 to 36 months. This would ensure adequate functionality for all children, but would also likely result in a significant reduction in the number of certified EHRs immediately available as well as an increase in their cost.
§170.302(f) General Certification Criteria for Complete EHRs or EHR Modules; Smoking status 
Issue: While recording smoking status is crucial to health improvement efforts, the IFR oversteps by mandating that the smoking status field must include values of: “current smoker, former smoker, or never smoked.” These values may be used in health insurance underwriting, but they are not a standard accepted by clinicians. In the absence of a vocabulary standard being available from an accredited standards body, it is not appropriate to compose an ad hoc vocabulary as part of a rule making process.
Recommendation: The second sentence of the item, specifying smoking status types, should be dropped.
§170.302(l) Medication reconciliation
Issue: The criterion in the IFR is too vague to be reliably tested, and medication lists are not sufficiently standardized to be directly merged electronically. Although the IFR includes a vocabulary standard for medications, it does not define a standard for the meaning of items on a medication list Careful human review and interpretation are essential to medication reconciliation, and pushbutton automation can create a patient safety hazard.  Neither the most popular electronic prescribing network (Surescripts), nor one of the arguably most advanced EHR implementations (Kaiser Permanente), have found electronic merging of medication lists from different sources to be safe or workable. 
Recommendation: The criterion should be changed to:  Electronically display patient medication information from two or more sources, and allow the user to create or update the patient’s medication list based on a review and reconciliation of that information.
§170.304(e) Specific Certification Criteria for Complete EHRs or EHR Modules designed for an ambulatory setting; Clinical Decision Support
Issues: Please refer to our comments on 170.302(a) on the topics of Alerts and Alert Statistics for drug-drug, drug-allergy, and drug-formulary checks. 
Recommendations:
  1. §170.304(e)(2) Delete “pop-up message or sound” from the appropriate row in Table 1.
  2. §170.304(e)(3) Unless more clearly specified, this item has greater risk of harm than benefit and should be removed. 
§170.306(a) Specific certification criteria for Complete EHRs or EHR Modules designed for an inpatient setting; Computerized provider order entry
Issue: The IFR criterion specifies a long list of order types. While it is reasonable to require functionality for ordering medications, laboratory, and radiology/imaging, the criteria should not attempt an exhaustive list of other order types. No information is given as to what constitutes adequate functionality for any of these other orders, and some, such as “dialysis” may not be appropriate order functionality for a general EHR system for hospitals.
Recommendation: Items (4) through (10) should be dropped and replaced with a single item “Other order types”.
§170.306(c) Specific Certification Criteria for Complete EHRs or EHR Modules designed for an inpatient setting; Clinical Decision Support
Issues: Please refer to our comments on 170.302(a) on the topics of Alerts and Alert Statistics for drug-drug, drug-allergy, and drug-formulary checks. 
Recommendations:
  1. §170.306(c)(2) Delete “pop-up message or sound” from the appropriate row in Table 1.
  2. §170.306(c)(3) Unless more clearly specified, this item has greater risk of harm than benefit and should be removed.
§170.302(m)(2) Submission to immunization registries; State-designated standards format 
Issue: Specifying use of “the applicable state designated standard format” does not offer a defined and testable certification criterion. The 50 states may each have a different format, or no format, and vendors may serve customers in all states, a multi-state region, or a single state. Resolving State-to-State standards variations is an appropriate task for other ONC health IT programs. It is an impossible task for EHR vendors and developers and should not be required in EHR certification.
Recommendation: Item (2) should be dropped. It should be sufficient that EHRs demonstrate compliance with the national standard specified in item (1).
§170.302(n) Public health surveillance
Issue: Requiring EHRs to “electronically record, retrieve, and transmit syndrome-based public health surveillance information to public health agencies” is a worthwhile future goal, but very unlikely to be possible during the 2011-2012 time frame of Stage I certification. The criterion fails to specify which agencies (local, state, Federal) are included, and most of those agencies are not prepared to receive biosurveillance data electronically in the format specified. It would be difficult for any EHR to prove compliance with the criterion as written.
Recommendation:
The criterion should be dropped as a Stage I certification criterion and deferred until Stage II.
If the criterion is not dropped, it should be changed to “Electronically record, retrieve, and be capable of producing an electronic message containing syndrome-based public health surveillance information in accordance with one of the standards specified in §170.205(g).”
§170.306(g) Reportable lab results
Issue: Requiring EHRs to “electronically record, retrieve, and transmit reportable clinical lab results to public health agencies” is a worthwhile future goal, but very unlikely to be possible during the 2011-2012 time frame of Stage I certification. The criterion fails to specify which agencies (local, state, Federal) are included, and many of those agencies are not prepared to receive reportable lab results data electronically in the format specified. It would be difficult for any EHR to prove compliance with the criterion as written.
Recommendation:
The criterion should be dropped as a Stage I certification criterion and deferred until Stage II.
If the criterion is not dropped, it should be changed to “Electronically record, retrieve, and be capable of producing an electronic message containing reportable lab results in accordance with the standards specified in 170.205(f)”
§170.210(d) Standards for health information technology to protect electronic health information created, maintained, and exchanged; cross-enterprise authentication
Issue: The text of the IFR does not specify any standards for this requirement, but Table 2B Row 5 offers the example of “IHE Cross Enterprise User Assertion (XUA) with SAML identity assertions)”. The inclusion of this example can be interpreted in different ways, making it difficult to reliably test compliance with the corresponding criterion. 
Recommendation: The example provided in parentheses in Table 2B Row 5 should be dropped.
Comments on Section V – Regulatory Impact Analysis
The IFR invites comment on the economic impact analysis and the Commission is pleased to offer feedback based on in-depth experience with certification in the EHR marketplace. There are two serious concerns regarding the impact analysis:
  • The IFR’s model for costs to EHR vendors and developers is overly simplistic, significantly underestimating regulatory economic impact
  • The impact analysis does not take into account readily available data pointing toward a disproportionate impact on small businesses
An overly simplistic economic model underestimates regulatory impact
The IFR model estimates that EHR vendors will each bear a cost “somewhere between $10,000 and $250,000 per certification criterion to prepare a Complete EHR or EHR Module for testing and certification,” then multiplies by the number of new criteria (which the IFR estimates as 25% of those previously required for CCHIT certification) and finally multiplies by an estimated number of vendors to be certified (which the IFR estimates as 90% of the currently certified cohort). 
This overly simplistic, linear model fails to include a discontinuity: any vendor that lacks the immediately available capital and development resources to add the new features required will no longer be competitive in the marketplace. Even vendors with adequate resources may not be able to modify their software, have it certified, and roll it out to the marketplace in time for the incentive windows which begin in just a few months. Outright business failures are likely. The economic impact includes the loss of a company’s net worth and a dislocation of its jobs. Even if only 10% of vendors fail in this manner (based on the IFR’s optimistic estimate that 90% will succeed in being HITECH certified), and even if these are assumed to all be small businesses with annual revenues of $10M and private market capitalizations of $30M-$50M, the aggregate economic waste would be in the hundreds of millions of dollars, with potential dislocation of thousands of jobs. 
The model also fails to consider secondary impacts extending beyond the Medicare and Medicaid provider universe. Customers of failed vendors will bear costs to replace unsupported, “orphaned” EHRs. Many of the practices affected, based on their patient populations, would not even qualify for ARRA Medicare or Medicaid EHR incentives so they have no funding source to these costs. The economic impact on such “innocent bystanders,” many of whom would be small physician offices and community hospitals, should be of great concern to this rulemaking process. 
A disproportionate impact on small businesses
The IFR states, “Based on our analysis, we believe that a handful of multinational corporations and many national or regional businesses represent a significant majority of the potential Complete EHR and EHR Module developers and that many, if not all, exceed the specified SBA size standard…[and]...it is difficult at the present time to locate empirical data related to many of the commercial vendors and open source developers of Complete EHRs and EHR Modules to correlate to the SBA size standard.”
Data useful for estimating the regulatory impact on small businesses has been published by CCHIT on several occasions. The latest statistics are available in a presentation slide set that accompanied testimony by Dr Mark Leavitt to the National Committee on Vital and Health Statistics on April 28-29, 2009. [2] 
With regard to the Ambulatory EHR marketplace as of March 2009, vendors with annual revenue under $20M -- the SBA size standard for small software businesses -- represented 75% (25%+37%+13%) of certified vendors as of March 2009.   Based on this data, the assumption in the IFR that “many, if not all” vendors are large businesses is incorrect, and the HHS Secretary’s certification statement that “…this interim final rule will not have a significant impact on a substantial number of small entities” should be revisited.


[1] Since 2005, the Commission has been developing and updating certification criteria annually using a voluntary, consensus-based process, and has inspected and certified over 250 EHR products to qualify them for various Federal, State, and private sector incentive and regulatory relief programs.  www.cchit.org/about
Post a comment
Write a comment: