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"
