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
Comments. Several commenters requested further clarification regarding the meaning of “patient's clinical information.” Other commenters stated that this phrase was too vague and was not included as part of the proposed meaningful use objective or measure and should therefore be removed. Some commenters requested further definition of the term “specific conditions,” particularly to clarify whether this term refers to problems and diagnoses. Clarification was also requested regarding whether this information includes: a patient summary; the patient's entire medical history; and patient encounter notes. One commenter recommended that we clarify how the lists must be structured and suggested that we specify time periods for patient histories. One commenter requested clarification of the term “output,” and suggested that it should mean to produce a list for internal use and that it does not refer to exporting the patient list to a system or destination external to the office of an eligible professional. Response. We appreciate the concerns raised by these commenters and after further consideration agree that the terms referenced by commenters could be interpreted in multiple ways. Accordingly we have removed “patient’s clinical information” and “specific conditions” from the certification criterion, and have reframed the certification criterion to more directly align with the meaningful use measure by changing “output” to “generate.” We sought to clarify that we intended that Certified EHR technology would be capable of electronically producing or “generating” patient lists for an eligible professional or eligible hospital’s subsequent use. We do not require as a condition of certification that time periods be associated with a patient list, but presumably time (i.e., the age of the information) could be one factor an eligible professional or eligible hospital could also use to sort their lists (e.g., patients with XYZ problem recorded in the past 3 Page 76 of 228
months). We believe that these revisions make this certification criterion clearer while addressing these commenters’ concerns. §170.302(i) - Report quality measures Meaningful Use Stage 1 Objective Eligible Professionals: Report ambulatory clinical quality measures to CMS or the States Eligible Hospitals and CAHs: Report hospital clinical quality measures to CMS or the States Meaningful Use Stage 1 Measure For 2011, provide aggregate numerator, denominator, and exclusions through attestation as discussed in section II(A)(3) of [the Medicare and Medicaid EHR Incentive Programs final rule] For 2012, electronically submit the clinical quality measures as discussed in section II(A)(3) of [the Medicare and Medicaid EHR Incentive Programs final rule] Page 77 of 228 Certification Criterion Interim Final Rule Text: (1) Display. Calculate and electronically display quality measures as specified by CMS or states. (2) Submission. Enable a user to electronically submit calculated quality measures in accordance with the standard and implementation specifications specified in §170.205(e). Final Rule Text: §170.304(j) (1) Calculate. (i) Electronically calculate all of the core clinical measures specified by CMS for eligible professionals. (ii) Electronically calculate, at a minimum, three clinical quality measures specified by CMS for eligible professionals, in addition to those clinical quality measures specified in paragraph (1)(i). (2) Submission. Enable a user to electronically submit calculated clinical quality measures in accordance with the standard and implementation specifications specified in §170.205(f). §170.306(i) (1) Calculate. Electronically calculate all of the clinical quality measures specified by CMS for eligible hospitals and critical access hospitals. (2) Submission. Enable a user to electronically submit calculated clinical quality measures in accordance with the standard and implementation specifications specified in §170.205(f). Comments. Many commenters stated that the Physician Quality Reporting Initiative (PQRI) 2008 Registry XML specifications apply only in the context of eligible professionals. Some of these commenters went on to state that hospitals are not familiar with PQRI and have been submitting quality measurement data to CMS under a separate program. A few commenters recommended that this standard requirement be removed while several others stated we should adopt both Quality Reporting Document
- Page 25 and 26: Comment. In the context of the defi
- 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: or outreach Generate patient lists.
- Page 79 and 80: that the PQRI 2009 Registry XML spe
- 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
Comments. Several commenters requested further clarification regarding the<br />
meaning <strong>of</strong> “patient's clinical information.” Other commenters stated that this phrase was<br />
too vague and was not included as part <strong>of</strong> the proposed meaningful use objective or<br />
measure and should therefore be removed. Some commenters requested further<br />
definition <strong>of</strong> the term “specific conditions,” particularly to clarify whether this term refers<br />
to problems and diagnoses. Clarification was also requested regarding whether this<br />
information includes: a patient summary; the patient's entire medical history; and patient<br />
encounter notes. One commenter recommended that we clarify how the lists must be<br />
structured and suggested that we specify time periods for patient histories. One<br />
commenter requested clarification <strong>of</strong> the term “output,” and suggested that it should<br />
mean to produce a list for internal use and that it does not refer to exporting the patient<br />
list to a system or destination external to the <strong>of</strong>fice <strong>of</strong> an eligible pr<strong>of</strong>essional.<br />
Response. We appreciate the c<strong>onc</strong>erns raised by these commenters and after<br />
further consideration agree that the terms referenced by commenters could be interpreted<br />
in multiple ways. Accordingly we have removed “patient’s clinical information” and<br />
“specific conditions” from the <strong>certification</strong> criterion, and have reframed the <strong>certification</strong><br />
criterion to more directly align with the meaningful use measure by changing “output” to<br />
“generate.” We sought to clarify that we intended that Certified EHR technology would<br />
be capable <strong>of</strong> electronically producing or “generating” patient lists for an eligible<br />
pr<strong>of</strong>essional or eligible hospital’s subsequent use. We do not require as a condition <strong>of</strong><br />
<strong>certification</strong> that time periods be associated with a patient list, but presumably time (i.e.,<br />
the age <strong>of</strong> the information) could be one factor an eligible pr<strong>of</strong>essional or eligible hospital<br />
could also use to sort their lists (e.g., patients with XYZ problem recorded in the past 3<br />
Page 76 <strong>of</strong> 228
Change language