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
an alternative to NCPDP SCRIPT 8.1 for the electronic transmission of prescription and certain other prescription-related information for Medicare Part D covered drugs prescribed for Part D eligible individuals (75 FR 38026). Further, we stated that “if SCRIPT 10.6 is permitted, prior to any modification of the provisions of this interim final rule in response to public comment, we would expect to change our requirement to simply permit either SCRIPT 8.1 or SCRIPT 10.6.” Accordingly, we have modified this certification criterion to specify that Complete EHR and EHR Module developers may seek to have their Complete EHR or EHR Module tested and certified to either solely NCPDP SCRIPT 8.1 or 10.6. Additionally, we have also replaced the standard adopted in the Interim Final Rule and have adopted both NCPDP SCRIPT 8.1 and NCPDP SCRIPT 10.6. As discussed in the beginning of the preamble, we have revised our approach to specifying the certification criteria to more clearly focus on the capabilities with which they must be associated. Therefore, we have modified this certification criterion to specify that a Complete EHR or EHR Module would be compliant with this certification criterion if it has the capability of generating and transmitting prescription and prescription-related information according to NCPDP SCRIPT 8.1 while also using the adopted vocabulary standard, or if it is capable of generating and transmitting prescriptions and prescription-related information according to NCPDP SCRIPT 10.6 while also using the adopted vocabulary standard. Comments. Several commenters supported the adoption of RxNorm and the use of RxNorm code sets as a vocabulary standard. One commenter recommended that RxNorm be adopted in Stage 1 while one commenter stated that Stage 2 is likely the earliest timeframe practicable for implementation. Others suggested that more testing Page 130 of 228
was needed before RxNorm could be adopted in full. Some commenters stated that RxNorm is not complete and requested guidance on how gaps in RxNorm will be addressed. A couple commenters stated a concern that current drug databases do not map to RxNorm and that in order to develop interfaces for electronic prescribing services, pharmacies and developers will need to expend significant effort. Other commenters stated that more clarification was needed with respect to the description of the adopted standard and one of those commenters recommended that the description be changed to “a drug data source provider that demonstrates group domain comprehensiveness.” Response. We have consolidated and addressed our adopted vocabulary standard for medications under this certification criterion. However, our response and subsequent clarifications are applicable to all certification criteria that reference this vocabulary standard. As we explained in the Interim Final Rule, we determined that the HIT industry would benefit from a certain degree of flexibility with respect to the coding of medications. To provide this flexibility while also establishing a glide path to full adoption of RxNorm, we adopted a standard that permits the use of one of many different vocabulary standards. We specified that a Complete EHR or EHR Module would be compliant with the adopted vocabulary standard if it utilized “[a]ny code set by an RxNorm drug data source provider that is identified by the United States National Library of Medicine as being a complete data set integrated within RxNorm.” We specified the standard this way in order to establish what we believe is an important bridge to full RxNorm adoption and will help facilitate this transition over time. Our adoption of this standard stems from our belief that Complete EHRs and EHR Modules Page 131 of 228
- 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
- Page 127 and 128: equire EHRs to build custom interfa
- Page 129: esult, we do not believe that this
- Page 133 and 134: • MDDB - Medi-Span Master Drug Da
- Page 135 and 136: Response. We do not believe that it
- Page 137 and 138: Send reminders to patients per pati
- 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
an alternative to NCPDP SCRIPT 8.1 for the electronic transmission <strong>of</strong> prescription and<br />
certain other prescription-related information for Medicare Part D covered drugs<br />
prescribed for Part D eligible individuals (75 FR 38026). Further, we stated that “if<br />
SCRIPT 10.6 is permitted, prior to any modification <strong>of</strong> the provisions <strong>of</strong> this interim <strong>final</strong><br />
rule in response to public comment, we would expect to change our requirement to<br />
simply permit either SCRIPT 8.1 or SCRIPT 10.6.” Accordingly, we have modified this<br />
<strong>certification</strong> criterion to specify that Complete EHR and EHR Module developers may<br />
seek to have their Complete EHR or EHR Module tested and certified to either solely<br />
NCPDP SCRIPT 8.1 or 10.6. Additionally, we have also replaced the standard adopted<br />
in the Interim Final Rule and have adopted both NCPDP SCRIPT 8.1 and NCPDP<br />
SCRIPT 10.6. As discussed in the beginning <strong>of</strong> the preamble, we have revised our<br />
approach to specifying the <strong>certification</strong> criteria to more clearly focus on the capabilities<br />
with which they must be associated. Therefore, we have modified this <strong>certification</strong><br />
criterion to specify that a Complete EHR or EHR Module would be compliant with this<br />
<strong>certification</strong> criterion if it has the capability <strong>of</strong> generating and transmitting prescription<br />
and prescription-related information according to NCPDP SCRIPT 8.1 while also using<br />
the adopted vocabulary standard, or if it is capable <strong>of</strong> generating and transmitting<br />
prescriptions and prescription-related information according to NCPDP SCRIPT 10.6<br />
while also using the adopted vocabulary standard.<br />
Comments. Several commenters supported the adoption <strong>of</strong> RxNorm and the use<br />
<strong>of</strong> RxNorm code sets as a vocabulary standard. One commenter recommended that<br />
RxNorm be adopted in Stage 1 while one commenter stated that Stage 2 is likely the<br />
earliest timeframe practicable for implementation. Others suggested that more testing<br />
Page 130 <strong>of</strong> 228