ehr onc final certification - Department of Health Care Services
ehr onc final certification - Department of Health Care Services ehr onc final certification - Department of Health Care Services
Architecture (QRDA) and the PQRI XML Registry specification in this rulemaking and move to a single standard in the next rulemaking. Other commenters recommended that QRDA not be adopted in this rulemaking. Several commenters suggested that an implementation specification for eligible hospitals be created if we intend to continue to require that quality measure be reported in the PQRI Registry XML format. One commenter expressed a concern that if the PQRI 2008 Registry XML standard is maintained as the adopted standard that there is a danger that the certification Complete EHR and EHR Module developers obtain may become obsolete before Stage 1 has run its course. Finally, a couple of commenters suggested that ONC consider deferring the naming of a standard for submission of clinical quality measures until Stage 2 and instead only require what is necessary to support clinical quality measure submission in Stage 1. Response. Many commenters misinterpreted our intent with respect to the adoption of the PQRI 2008 Registry XML specification as the standard for electronically submitting quality reporting data to CMS. Presently, CMS requires the submission of aggregate, summary level data for the purposes of meaningful use and not data at the patient-specific level. It is our understanding that the PQRI 2008 Registry XML specification is capable of serving as the “envelope” for aggregate, summary level data. Accordingly, we do not believe that, as some commenters suggested, an eligible hospital’s familiarity with the PQRI program is relevant to the adoption of this standard for this specified purpose. Nor do we believe that a specific implementation of this standard is necessary for hospital settings as the standard’s purpose and the type of data it will transmit to CMS will be the same – aggregate, summary level data. Through recent discussions with CMS since the publication of the Interim Final Rule we have determined Page 78 of 228
that the PQRI 2009 Registry XML specification, a more recent version of the standards we adopted in the Interim Final Rule is a suitable replacement for 2008 version, and accordingly, we have adopted the 2009 version in its place. We believe this revision should assuage some commenters’ concerns about the obsolescence of the adopted standard and reduce concerns that a wholly different standard would be adopted in the near future. If adopting a different standard for Certified EHR Technology becomes necessary, we would do so only after engaging in subsequent rulemaking. Comments. A few commenters stated that many of the clinical quality measures proposed by CMS do not have electronic specifications and contended that it would be difficult for any vendor to have embedded these measures in their EHR products in a timely manner. But, these same commenters stated that when the specifications become available, that HHS should ensure through the certification process that the products are capable of generating accurate data. Many commenters expressed concerns that the certification criterion was too vague or too broad (because it implicitly referenced all of the quality measures CMS had proposed). Some of the commenters recommended that this certification criterion be removed, while others recommended that it focus on a subset of measures in order to constrain the amount of electronic measure specifications a Complete EHR or EHR Module developer would need to address in order to be certified. At least one of these latter commenters indicated that our adopted certification criteria created uncertainty for Complete EHR and EHR Module Developers. This commenter asked that we clarify what clinical quality measures would need to be tested in order to satisfy this certification criterion and if there would be a baseline for eligible hospital measures as well as some identified core set of measures for eligible professionals. Page 79 of 228
- Page 27 and 28: y the certification criteria for a
- Page 29 and 30: commenters asked whether we meant t
- Page 31 and 32: adopted by the Secretary. The secon
- Page 33 and 34: Response. We would like to make cle
- Page 35 and 36: Response. In the Interim Final Rule
- Page 37 and 38: could be a health care professional
- Page 39 and 40: standard for certain purposes. In s
- Page 41 and 42: e voluntary and would not be requir
- Page 43 and 44: already existing regulatory require
- Page 45 and 46: setting). We also include, where ap
- Page 47 and 48: clarification on why the number of
- Page 49 and 50: more clearly specify this capabilit
- Page 51 and 52: Response. While we do not require t
- Page 53 and 54: that check, the functionality show
- Page 55 and 56: Response. The comments are correct
- Page 57 and 58: enable the user to electronically r
- Page 59 and 60: longitudinal care, or whether the E
- Page 61 and 62: EHR and EHR Module developers to pr
- Page 63 and 64: suggestions for different age range
- Page 65 and 66: Record smoking status for patients
- Page 67 and 68: 23) during the EHR reporting period
- Page 69 and 70: laboratory test results are receive
- Page 71 and 72: commenters reasoned that because a
- Page 73 and 74: laboratory test results to be elect
- Page 75 and 76: or outreach Generate patient lists.
- Page 77: months). We believe that these revi
- Page 81 and 82: To better align this certification
- Page 83 and 84: the capability specified by the cer
- Page 85 and 86: vendors were unwilling or unable to
- Page 87 and 88: the concerns expressed by some comm
- Page 89 and 90: Page 89 of 228 electronically compa
- Page 91 and 92: (1) The standard (and applicable im
- Page 93 and 94: for the purposes of demonstrating c
- Page 95 and 96: Guide for Immunization Messaging Re
- Page 97 and 98: Response. We clarify for commenters
- Page 99 and 100: serve as a limiting factor, however
- Page 101 and 102: Page 101 of 228 Unchanged Comment.
- Page 103 and 104: Comment. One commenter suggested th
- Page 105 and 106: Response. We appreciate the thought
- Page 107 and 108: Complete EHRs or EHR Modules design
- Page 109 and 110: Response. We disagree. As stated ab
- Page 111 and 112: Response. As discussed above, we ha
- Page 113 and 114: SHA-1 and other secure hash algorit
- Page 115 and 116: misinterpreted our example and stat
- Page 117 and 118: Other commenters also expressed con
- Page 119 and 120: eferenced in FIPS 140-2 Annex A, wh
- Page 121 and 122: of the most secure encryption algor
- Page 123 and 124: the disclosure was made (recipient)
- Page 125 and 126: Use CPOE for medication orders dire
- Page 127 and 128: equire EHRs to build custom interfa
Architecture (QRDA) and the PQRI XML Registry specification in this rulemaking and<br />
move to a single standard in the next rulemaking. Other commenters recommended that<br />
QRDA not be adopted in this rulemaking. Several commenters suggested that an<br />
implementation specification for eligible hospitals be created if we intend to continue to<br />
require that quality measure be reported in the PQRI Registry XML format. One<br />
commenter expressed a c<strong>onc</strong>ern that if the PQRI 2008 Registry XML standard is<br />
maintained as the adopted standard that there is a danger that the <strong>certification</strong> Complete<br />
EHR and EHR Module developers obtain may become obsolete before Stage 1 has run its<br />
course. Finally, a couple <strong>of</strong> commenters suggested that ONC consider deferring the<br />
naming <strong>of</strong> a standard for submission <strong>of</strong> clinical quality measures until Stage 2 and instead<br />
only require what is necessary to support clinical quality measure submission in Stage 1.<br />
Response. Many commenters misinterpreted our intent with respect to the<br />
adoption <strong>of</strong> the PQRI 2008 Registry XML specification as the standard for electronically<br />
submitting quality reporting data to CMS. Presently, CMS requires the submission <strong>of</strong><br />
aggregate, summary level data for the purposes <strong>of</strong> meaningful use and not data at the<br />
patient-specific level. It is our understanding that the PQRI 2008 Registry XML<br />
specification is capable <strong>of</strong> serving as the “envelope” for aggregate, summary level data.<br />
Accordingly, we do not believe that, as some commenters suggested, an eligible<br />
hospital’s familiarity with the PQRI program is relevant to the adoption <strong>of</strong> this standard<br />
for this specified purpose. Nor do we believe that a specific implementation <strong>of</strong> this<br />
standard is necessary for hospital settings as the standard’s purpose and the type <strong>of</strong> data it<br />
will transmit to CMS will be the same – aggregate, summary level data. Through recent<br />
discussions with CMS since the publication <strong>of</strong> the Interim Final Rule we have determined<br />
Page 78 <strong>of</strong> 228