1 / 7

Certification/Adoption Workgroup HIT Policy Committee April 2, 2014

Certification/Adoption Workgroup HIT Policy Committee April 2, 2014. Discussion of 2015 Ed. NPRM. Complete EHR Definition. Propose to discontinue use of “Complete EHR” definition for the 2015 Ed. Rationale :

elke
Download Presentation

Certification/Adoption Workgroup HIT Policy Committee April 2, 2014

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Certification/Adoption WorkgroupHIT Policy CommitteeApril 2, 2014 Discussion of 2015 Ed. NPRM

  2. Complete EHR Definition • Propose to discontinue use of “Complete EHR” definition for the 2015 Ed. Rationale: • The Complete EHR was initially created to support the 2011 CEHRT Definition which is no longer in use. • Stakeholder confusion about the interplay between the CEHRT Definition, the Base EHR Definition and the Complete EHR definition • A “Complete EHR” is not necessarily complete for EP’s, EH’s and CAH’s to meet MU. • Modular certification is more consistent with the flexibility provided in the CEHRT definition. • MU requirements for EP’s, EH’s, and CAH’s will continue to evolve, making a single Complete EHR Definition obsolete. • Complies with Executive Order requiring reduced regulatory burdens • Alternatives that include keeping the Complete EHR Definition • Keep the edition-specific Complete EHR definition in the 2015 Ed. • Change “Complete EHR” definition to “EHR technology that has been developed to meet, at minimum, all mandatory certification criteria adopted by the Sec’y for either AMB settings or INPT settings and meets the Base EHR Definition. ACB’s will be responsible for issuing certifications that Edition that the Complete EHR was certified to.

  3. Non-MU EHR Technology Certification • Propose to amend regulatory requirements to support certification for technology used for purposes other than MU. • MU and Non-MU certified technology would be easily distinguishable. • Specifications: • Create an MU EHR Module definition and non-MU EHR Module definition. • Only MU EHR Modules would need to be certified to the “automated numerator recording” ((g)(1)), “automated measure calculation” ((g)(2)) and “non-percentage based measure use report” ((g)(5)). • Both MU EHR Modules and non-MU EHR Modules must be certified to “safety-enhanced design” ((g)(3)) and/or “quality system management” ((g)(4)). • (k)(1)(iii) will only apply to MU EHR Modules and distinctions would be listed on CHPL Distinction would not apply retroactively to 2014 Ed., would only apply to 2015 and beyond.

  4. Non-MU EHR Technology Certification • Specific Questions: • Is ONC’s regulatory burden assumption correct related to EHR technology developers having to meet the automated numerator and automated measure calculation certification criteria to obtain certification? • Do the automated numerator and automated measure calculation certification criteria requirements pose more of burden for small EHR technology developers that design EHR technology for non-MU purposes and settings (e.g., inhibit their ability to compete with large EHR technology developers that have more resources to develop and get certified to the automated numerator and automated measure calculation certification criteria even if their customers will not use the capabilities)? • Would health care providers using EHR technology for non-MU purposes and settings benefit from or be hindered by paying for and/or using EHR technology certified to the automated numerator and automated measure calculation certification criteria? • How does ONC best implement the proposed approach if ONC were to adopt it in a subsequent final rule. In this regard, ONC requests feedback on the following questions: • Would the process for testing and certification be clear under our approach as described? Should EHR technology developers simply inform ONC-ACBs as to the type of EHR Module certification they seek (i.e., MU or non-MU)? • How should we distinguish non-MU EHR Modules on the CHPL? Should we have separate listings of MU and non-MU EHR Modules? Are there other options? How should we indicate and list the availability of MU EHR Modules for use beyond MU purposes?

  5. “Certification Packages” for EHR Modules • Establishes the concept of predefined ``certification packages'' that would reflect groupings of certification criteria • Rationale: Packages would make it easier for stakeholders to communicate and understand the functionality an EHR Module includes and the criteria to which it was certified to. • ONC proposes to: • Identify subsets of certification criteria as ``certification packages,'' beginning with the 2015 Edition; and • Require ONC-ACBs to ensure that EHR Module developers make accurate representations concerning certification packages on their Web sites and in marketing materials, communications statements, or other assertions related to an EHR Module's certification.

  6. “Certification Packages” for EHR Modules • Specific Packages: • “Care Coordination Package” would require an EHR Module to be certified to, at a minimum, the proposed 2015 Edition EHR certification criteria at Sec. 170.315(b)(1) (Transitions of care); and Sec. 170.315(b)(2) (Clinical information reconciliation and incorporation). • Whether ONC should also include (Transmit--Applicability Statement for Secure Health Transport in order to require that an EHR Module labeled with this package is also certified to the transmission certification criterion focused on the primary Direct Project specification; • whether it should be a more general requirement to be certified to any one of the Sec. 170.315(h) transmission certification criteria (which could risk some organizations adopting an EHR Module labeled with ``care coordination package'' being unable to exchange with each other because their separate EHR Modules came with different transmission capabilities); • whether we should require that the EHR Module be certified to both Sec. 170.315(h)(1) and Sec. 170.315(h)(3) (i.e., ``Direct'' and SOAP); and • whether including any of the transmission criteria in Sec. 170.315(h) as part of the package would recreate the same ``binding'' effect that we proposed to decouple earlier in this preamble (see the discussion of the ``Transitions of Care'' certification criterion in section III.A). • “Patient Engagement Package” would require an EHR Module to be certified to, at a minimum, the proposed 2015 Edition EHR certification criteria at Sec. 170.315(e)(1) (View, download and transmit to a 3rd party); and Sec. 170.315(e)(3) (Secure messaging). • Whether we should include Sec. 170.315(a)(16) (Patient list creation), Sec. 170.315(a)(17) (Patient-specific education resources), or both.

  7. ONC Certification Mark • Currently, ``ONC Certified HIT'' certification and design mark, as used by an authorized user, certifies that a particular HIT product has been tested in accordance with test procedures approved by the National Coordinator; has been certified in accordance with the certification criteria adopted by the Sec’y; and has met all other required conditions of the ONC HIT Certification Program. • Proposal: • to require ONC-ACBs to display the Mark on all certifications issued under the ONC HIT Certification Program in a manner that complies with the ‘Criteria and Terms of Use’ • to revise Sec. 170.523 to require ONC-ACBs to ensure that use of the Mark by HIT developers whose products are certified under the ONC HIT Certification Program is compliant with the Terms of Use

More Related