Our Meaningful Use Stage 2 Certification Strategy

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.