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
are unaware of any alternative voluntary consensus standard that accomplishes the same purpose. Comments. Several commenters recommended additional elements for the certification criterion for us to consider adding. One commenter recommended that we include more demographic data items to allow successful matching with prior admissions and further that we consider requiring the inclusion of social security number, birthplace, and years of education, if available. A couple commenters requested that we add occupation and industry status as well because they are already required for cancer registries. Another commenter suggested that we add family history to demographics that should be captured and reported. One commenter suggested that we also include a patient's functional status. Many commenters suggested that we encourage self-reporting of demographics and indicate whether information was self-reported. Finally, one commenter stated that EHRs are not appropriate source of legal documentation for births and deaths. Response. While we understand commenters’ intentions, we do not believe that it would be appropriate to expand this certification criterion beyond what is required to support meaningful use. Again, as we have previously stated, this does not preclude a Complete EHR or EHR Module developer from including the capability to record additional demographic information. Finally, consistent with the Medicare and Medicaid EHR Incentive Programs final rule, we have removed the capability to record insurance type from the certification criterion. §170.304(d) - Generate patient reminder list Meaningful Use Stage 1 Objective Meaningful Use Stage 1 Measure Page 136 of 228 Certification Criterion
Send reminders to patients per patient preference for preventive/ follow up care More than 20% of all unique patients 65 years or older or 5 years old or younger were sent an appropriate reminder during the EHR reporting period Interim Final Rule Text: Electronically generate, upon request, a patient reminder list for preventive or follow-up care according to patient preferences based on demographic data, specific conditions, and/or medication list. Final Rule Text: §170.304(d) Patient reminders. Enable a user to electronically generate a patient reminder list for preventive or follow-up care according to patient preferences based on, at a minimum, the data elements included in: (1) Problem list; (2) Medication list; (3) Medication allergy list; (4) Demographics; and (5) Laboratory test results. Comments. Several commenters stated that they support this certification criterion. Other commenters requested further definition of the term “specific conditions,” particularly whether this term refers to data as contained in the problem list. One commenter suggested that the criterion text be modified to read: “Electronically generate, upon request, a patient reminder list for preventive or follow-up care according to patient or physician preferences based on demographic data, specific conditions, and/or medication list.” Several commenters requested further definition of the term “patient preferences.” Clarification was requested about the meaning of the term, how these preferences would be recorded, how the preferences would be used, and whether the preferences should be automated. A question was raised by two commenters about how many choices should be allowed for the preferred reminder delivery method due to additional EHR system programming that may be needed to support the set of choices. One commenter was concerned about whether there would be a cost to physician practices to implement this requirement and whether the practices will have the capacity to accommodate this requirement. Another commenter suggested that this requirement be moved to meaningful use stage 2 to allow more time for EHRs to be enhanced. Page 137 of 228
- 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
- Page 129 and 130: esult, we do not believe that this
- Page 131 and 132: was needed before RxNorm could be a
- Page 133 and 134: • MDDB - Medi-Span Master Drug Da
- Page 135: Response. We do not believe that it
- Page 139 and 140: specified data elements and CMS’s
- Page 141 and 142: what would qualify as a "response."
- Page 143 and 144: Comment. A commenter recommended th
- Page 145 and 146: in accordance with one of the adopt
- Page 147 and 148: Comments. Many commenters suggested
- Page 149 and 150: flexibility in this certification c
- Page 151 and 152: productive, confusing, time-consumi
- Page 153 and 154: include in this initial set. Accord
- Page 155 and 156: to the HITSP C32 implementation spe
- Page 157 and 158: Response. Again, we do not believe
- Page 159 and 160: e achieved without these and recomm
- Page 161 and 162: electronically record, store, retri
- Page 163 and 164: EHRs and EHR Modules designed for a
- Page 165 and 166: §170.205(a)(2)(iii); and (v) The s
- Page 167 and 168: Response. We disagree, as doing so
- Page 169 and 170: Dental Terminology as a condition o
- Page 171 and 172: However, we do not preclude Complet
- Page 173 and 174: ability of CCD and CCR to support t
- Page 175 and 176: ability to receive these reports. M
- Page 177 and 178: commenters acknowledged and express
- Page 179 and 180: a meaningful use objective they wou
- Page 181 and 182: CMS and ONC had worked together to
- Page 183 and 184: The eligible professional or eligib
- Page 185 and 186: EHR technology with the needs of us
are unaware <strong>of</strong> any alternative voluntary consensus standard that accomplishes the same<br />
purpose.<br />
Comments. Several commenters recommended additional elements for the<br />
<strong>certification</strong> criterion for us to consider adding. One commenter recommended that we<br />
include more demographic data items to allow successful matching with prior admissions<br />
and further that we consider requiring the inclusion <strong>of</strong> social security number, birthplace,<br />
and years <strong>of</strong> education, if available. A couple commenters requested that we add<br />
occupation and industry status as well because they are already required for cancer<br />
registries. Another commenter suggested that we add family history to demographics<br />
that should be captured and reported. One commenter suggested that we also include a<br />
patient's functional status. Many commenters suggested that we encourage self-reporting<br />
<strong>of</strong> demographics and indicate whether information was self-reported. Finally, one<br />
commenter stated that EHRs are not appropriate source <strong>of</strong> legal documentation for births<br />
and deaths.<br />
Response. While we understand commenters’ intentions, we do not believe that it<br />
would be appropriate to expand this <strong>certification</strong> criterion beyond what is required to<br />
support meaningful use. Again, as we have previously stated, this does not preclude a<br />
Complete EHR or EHR Module developer from including the capability to record<br />
additional demographic information. Finally, consistent with the Medicare and Medicaid<br />
EHR Incentive Programs <strong>final</strong> rule, we have removed the capability to record insurance<br />
type from the <strong>certification</strong> criterion.<br />
§170.304(d) - Generate patient reminder list<br />
Meaningful Use<br />
Stage 1<br />
Objective<br />
Meaningful Use<br />
Stage 1 Measure<br />
Page 136 <strong>of</strong> 228<br />
Certification Criterion