Two weeks ago, ONC created a very helpful Certification Guide for EHR technology developers
Many people in the industry have told me that the most challenging
scripts are the demonstration of CCDA generation/display/Direct
transmission (45 CFR §170.314(b)(1) and 45 CFR §170.314(b)(2)), the
Clinical Quality Measures (45 CFR §170.314©(1)-(3)), and Patient
View/Download/Transmit (45 CFR §170.314(e)(1)).
Although some stakeholders have suggested that these criteria are too
aspirational, using standards that are still maturing, I think it is
unlikely that rule making will alter their intent. I also think it
unlikely that the test scripts will be significantly revised to reduce
the complexity of certification.
As I wrote recently in my post about What Keeps Me Up at Night, the only way to pass an impossible test is to change the rules.
Our approach has been to leverage the modularity of Meaningful Use Stage
2 to divide up the work among vendors, the State government, and our
own developers.
Here's how we're doing it.
The State HIE, MassHIWay, fully implements the Direct protocol including
certificate validation - everything required by §170.314(b)(2).
Unfortunately, modular certification does not enable the splitting of a
script, so in order to use the MassHIWay for all of §170.314(b), we also
need to demonstrate its ability to generate and display a CCDA.
Luckily, the MassHIWay received an innovation grant to create the
Surrogate EHR Environment (SEE) application for LTAC/SNF/stakeholders
without an EHR. This application can generate and display CCDAs.
We'll leverage the MassHIWay capabilities and demonstrate its Direct
functionality as part of the BIDMC self-certification efforts. Then,
we'll help all the other users in the Commonwealth by getting it
certified as a §170.314(b) compliant module so that anyone in
Massachusetts can include it in their attestation.
The Clinical Quality Measures require demonstration of QRDA Category I (Patient-level) and
QRDA Category III (Aggregate-level) capabilities. They also require
stratification by several demographic data elements to support
disparities of care reporting. The test script results in a QRDA that
is over a megabyte because 21 test patients with 29 measures are
stratified 3 ways. Rather than apply significant resources to QRDA
programming, we chose to outsource our quality reporting to the
Massachusetts eHealth Collaborative Quality Data Center (QDC),
as described in my earlier blog about our ACO strategy. The QDC takes
CCDAs from each of our EHRs and produces all the reports needed for
ACO, Meaningful Use and PQRS reporting. Last week, MAeHC achieved
modular certification for all its CQM reporting.
The Patient View/Download/Transmit (VDT) scripts are tough because the
ecosystem of products supporting patient transmit workflows is still
very immature. We are implementing VDT in two ways. The MassHIWay
will connect to a PHR and thus we'll likely include the MassHIWay VDT
features in our self certification. We'll also augment our Automated
Blue Button (ABBI) functionality so that a patient can initiate an ABBI
transmission instead of relying on a transition of care event, as is now
the case. Our ABBI code is open source from the Direct project.
Thus, by building our core EHR functionality and certifying it
supplemented with modular certification of the state HIE, the Quality
Data Center, and Automated Blue Button, we can get to a full "shopping
cart" of functionality to support hospital and professional attestation.
It took us half a day to achieve Meaningful Use Stage 1 certification.
We estimate that 3 full days of demonstrations will be required for
Meaningful Use Stage 2 certification.
The division of labor described above will make it possible to us to
certify all our software in time for early 2014 reporting periods and
attestation.
