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
Comment. A commenter recommended including the term “modify” in the certification criterion. Response. We agree, and consistent with our other certification criteria that include the term “modify,” we have added this term. §170.302(n) - Public health surveillance Meaningful Use Stage 1 Objective Capability to submit electronic syndromic surveillance data to public health agencies and actual submission in accordance with applicable law and practice Meaningful Use Stage 1 Measure Performed at least one test of certified EHR technology's capacity to provide electronic syndromic surveillance data to public health agencies and follow-up submission if the test is successful (unless none of the public health agencies to which an EP, eligible hospital or CAH submits such information have the capacity to receive the information electronically) Page 96 of 228 Certification Criterion Interim Final Rule Text: Public health surveillance. Electronically record, retrieve, and transmit syndrome-based public health surveillance information to public health agencies in accordance with one of the standards specified in §170.205(g). Final Rule Text: §170.302(l) Public health surveillance. Electronically record, modify, retrieve, and submit syndrome-based public health surveillance information in accordance with the standard (and applicable implementation specifications) specified in §170.205(d)(1) or §170.205(d)(2). Comments. A couple of commenters supported the adoption of certification criteria related to public health reporting. One commenter believed that this certification criterion should be implemented as adopted. Response. We appreciate commenters’ support of this certification criterion. Comment. One commenter recommended that we defer any vocabulary standard for public health reporting and surveillance until a later date. Another commenter expressed concern that we would adopt as a standard, “according to applicable public health agency requirements,” because they thought it could be problematic for hospital systems with facilities in two or more states, as their EHR technology would have to meet whatever standards each state elected to use.
Response. We clarify for commenters that we adopted two content exchange standards for electronic submission to public health agencies for surveillance and reporting. We did not adopt a specific vocabulary standard, nor did we include the phrase one commenter stated that we included. However, we have, consistent with our rationale in the immunization submission certification criterion, removed our reference to “public health agencies” as the recipient of information. Also, consistent with the certification criterion above, we have replaced the term “transmit” with “submit.” Comments. A couple of commenters stated that compliance with HL7 2.5.1 not be included in this adopted set of standards. One commenter suggested HL7 2.5.1 should be adopted in a future rulemaking. Another commenter suggested that HL7 2.3.1 be required for the purposes of certification. Another commenter recommended that the standard be HL7 2.3.1, because in its opinion many public health agencies cannot comply with HL7 2.5.1 while another commenter took the opposite position and recommended HL7 2.5.1. Response. Given the diversity in implementations and public health agencies’ ability to receive information in a given standard, we believe that the flexibility included in this criterion is necessary for the foreseeable future. However, relative to the general comments we received regarding the adoption of implementation specifications for adopted standards, we have adopted the following implementation specifications for HL7 2.5.1: Public Health Information Network HL7 Version 2.5 Message Structure Specification for National Condition Reporting Final Version 1.0 and the Errata and Clarifications National Notification Message Structural Specification. We believe that these implementation specifications provide the additional clarity commenters were Page 97 of 228
- 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 and 78: months). We believe that these revi
- 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: Guide for Immunization Messaging Re
- 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 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
Response. We clarify for commenters that we adopted two content exchange<br />
standards for electronic submission to public health agencies for surveillance and<br />
reporting. We did not adopt a specific vocabulary standard, nor did we include the<br />
phrase one commenter stated that we included. However, we have, consistent with our<br />
rationale in the immunization submission <strong>certification</strong> criterion, removed our reference to<br />
“public health agencies” as the recipient <strong>of</strong> information. Also, consistent with the<br />
<strong>certification</strong> criterion above, we have replaced the term “transmit” with “submit.”<br />
Comments. A couple <strong>of</strong> commenters stated that compliance with HL7 2.5.1 not<br />
be included in this adopted set <strong>of</strong> standards. One commenter suggested HL7 2.5.1 should<br />
be adopted in a future rulemaking. Another commenter suggested that HL7 2.3.1 be<br />
required for the purposes <strong>of</strong> <strong>certification</strong>. Another commenter recommended that the<br />
standard be HL7 2.3.1, because in its opinion many public health agencies cannot comply<br />
with HL7 2.5.1 while another commenter took the opposite position and recommended<br />
HL7 2.5.1.<br />
Response. Given the diversity in implementations and public health agencies’<br />
ability to receive information in a given standard, we believe that the flexibility included<br />
in this criterion is necessary for the foreseeable future. However, relative to the general<br />
comments we received regarding the adoption <strong>of</strong> implementation specifications for<br />
adopted standards, we have adopted the following implementation specifications for HL7<br />
2.5.1: Public <strong>Health</strong> Information Network HL7 Version 2.5 Message Structure<br />
Specification for National Condition Reporting Final Version 1.0 and the Errata and<br />
Clarifications National Notification Message Structural Specification. We believe that<br />
these implementation specifications provide the additional clarity commenters were<br />
Page 97 <strong>of</strong> 228
Change language