Of all the Meaningful Use Stage 2 questions I'm asked by vendors, HISPs, and providers, many involve confusion between certification and attestation.
As I've written about several times, the certification criteria are so extensive, often in unnecessary and confusing ways, that few vendors have been able to get through them. Certification criteria exceed attestation criteria in many scripts.
I was recently asked about transition of care data exchange using Direct and the need for message delivery notification (MDN). Micky Tripathi wrote the following excellent analysis, the bottom-line of which is that MDN is a narrow certification criteria, not an attestation requirement. In the future, I think certification must be simplified to include the bare minimum necessary to support attestation. Many people on the Standards Committee feel the same way and we'll support whatever polishing strategy ONC deems appropriate.
Micky wrote:
"1) Organizations with self-developed systems may depend on a HISP as part of their certification, but organizations with vendor-based EHRs will not
a. Although organizations with self-developed systems may chose to use the HISP as part of their alternative certification, most organizations will rely on their EHR vendor's complete certification
b. For example, for Beth Israel Deaconess Medical Center certification, the HISP, acting as modular certified technology, needs to generate MDNs in response to incoming messages.
c. For everyone else, the HISP does NOT need to generate any type of MDNs. Sending providers only need to have reasonable assurance that messages sent via the HISP have been delivered to the intended recipients.
2) There are three requirements that are relevant here: the transitions of care attestation requirement, the technology certification for receiving messages, and the technology certification for creating/transmitting messages:
a. The Meaningful Use Stage 2 transitions of care attestation requirement is that “the summary of care record must be received by the provider to whom the sending provider is referring or transferring the patient” (see page 4 of the measure)
b. 2014 Edition certification requires that an EHR be able to receive a Direct-compliant message and send an MDN for successfully received message (see page 5 of the NIST test script)
c. 2014 Edition certification requires that an EHR be able to transmit a Direct-compliant message to a Direct address recipient. There is no MDN requirement on the transmission certification. (NIST test script).
3) The MDN requirement is SOLELY a certification requirement (it is NOT an attestation requirement) and it applies only to the requirements regarding receiving messages. There is no certification requirement for MDN in transmission transactions. There is no attestation requirement for MDNs (or any other technical means) to demonstrate assurance of receipt of transmitted transitions of care.
a. While attestation does require that the intended recipient actually receive the message, there are no requirements on what type of assurance the sending provider must have in order to meet the Meaningful Use transitions of care measure. Indeed, the ONC commissioned white paper on the topic of assurance states that: “It is up to the Certified EHR Technology vendor to determine how to assist its customers and provide them with assurance that transmissions have reached their intended recipients. This assurance could include a presumption of success on the provider’s part of subsequent transmissions if they have reasonable certainty that initial transmissions were successful.” (see page 2 of the white paper)
4) The MDN issue thus applies only to organizations that are using alternative certification and using the HISP as relied upon software because they need to be able to meet the “receive” and “create/transmit” criteria. It does NOT apply to users who are using off-the-shelf Certified EHR Technology to transmit Direct messages over the HISP.
a. Any other organization with off-the-shelf Certified EHR Technology which wants to use the HISP for transitions of care transmission does NOT need the HISP to be certified
b. Their own Certified EHR Technology will generate a Direct-compliant message and pass it to the HISP for delivery
c. The sender will have met their transitions of care requirement at this point as long as they have reasonable assurance that the HISP delivered the message to its intended recipient
d. This assurance could be provided by MDNs delivered back from the receiving EHRs, but it does not have to be, and indeed, since recipients are not required to be Meaningful Use compliant, many recipients won’t be able to generate an MDN anyway
e. In any case, it is NOT a HISP responsibility to generate and transmit MDNs back to the sending EHRs (except in the case where the HISP is acting as relied upon software for alternative certification)
5) Some organizations may want the HISP to be certified for their attestation purposes. For the purposes of attestation, the HISP will be certified ONLY for “generate/transmit” and NOT for “receive”, and thus it has no obligation to create MDNs
a. In order for the HISP to receive modular certification for “receive”, it would have to be able to display CCDA documents, accurately match patients, and consume structured information for medication, problems, and medication allergies. That would require that the HISP to include EHR features beyond the scope of HISP operations.
b. Any organization that would like to attest with the HISP could thus only use the HISP for the “generate/transmit” requirement.
6) Regardless of whether the HISP is used as just a conduit (#4) or as a certified module for transmission (#5), the HISP does need to provide some type of assurance of delivery back to the senders
a. The current plan for the Massachusetts State HISP is to send back MDNs to provide assurance of delivery, which is ideal – however, it is NOT required
b. The HISP could assure delivery by contract such as a service level agreement
c. And/or the HISP could make available transaction audit records back to senders periodically or on-demand"
recomended product suport by amazon
0 komentar:
Posting Komentar