Why is the challenge of meeting meaningful use Stage 2 much more difficult, and why are many finding it to be a more rigorous certification process? To start, the requirements are more complex, and vendors are facing challenges in building solutions that are truly interoperable – which is the goal that all EMR/EHR vendors are pursuing as they upgrade their software to meet MU2 requirements.

While MU1 required that patient data be shared with patients or other healthcare professionals, MU2 has more in-depth requirements for sharing that data using advanced document architecture. EHR software needs to electronically connect and securely share data with patients, other practices, laboratories, hospitals, etc. Challenges arise for vendors when trying to build software that will easily integrate with other proprietary clinical systems. This means working with those other entities on their time frame. Because of the large number of EMR systems that need access to these entities, prioritization of these interface requests have led to long wait times and in turn, further delay certification progress.

That’s where the importance of interoperability comes in. While MU1 required the ability to export medical records in Continuty of Care Record (CCR) and Continuty of Care Document (CCD) formats, but not the ability to import those formats. MU2, however, requires the ability to import CCD and CCR formats while also calling for adoption of the Consolidated Clinical Document Architecture (C-CDA), a standard intended to specify the encoding, structure and semantics of a patient’s EHR.

Complicating matters further, this standard wasn’t in place for MU1 and even in MU2 the requirement for C-CDA is only the ability to export. The requirement for the importing of the C-CDA document is left for meaningul use Stage 3 (MU3), thus presenting a challenge in meeting new MU2 requirements. Time may be what software developers need to build the technology necessary to meet the C-CDA requirements, but time is also ticking for MU2 certification.

Another wrench in the testing process is the lack of clarity for MU3. MU2 requirements were defined back in 2006 while MU1 was being implemented, providing vendors insight into what to build for the future. With testing being so costly, vendors want to know that the technology platform they are building now will be able to withstand the changes that will come with MU3. The lack of details surrounding MU3 has caused vendors to hold off on MU2 testing in hopes that what they build will pass not only Stage 2, but also be flexible enough for Stage 3 requirements.

While many of the proprietary software systems are struggling to rebuild their products to be flexible enough to accommodate new requirements, solutions built using open source technology have the ability to be more nimble. By design, open source software allows free access to its source code, which makes it easier for users to add features quickly and customize the code to meet requirements without having to wait for the input of commercial EMR vendors to build it into their product development lifecycle. This makes interoperability between any system and an open source system easier. For the healthcare community, OpenEMR provides the foundation upon which more advanced and customizable open source EMR solutions are built. In fact, many of the contributors to OpenEMR are practicing doctors. These members not only share and co-build code for a technically sound product but also share information on usability.

As vendors (proprietary and open source alike) work through the technical hurdles of meeting the MU2 requirements, they also need to consider usability. Building a solution that meets all the requirements on paper is useless if medical professionals can’t easily implement it into their daily workflow. An upgrade from paper charts is certainly welcome, but for a doctor who is used to handwriting notes, having to instead check inflexible electronic boxes can be seen as time consuming and frustrating.

Vendors need to build options into their solutions that medical professionals can customize to their needs. With the ability to choose between checking boxes, writing or dictating notes, doctors benefit from technology that adapts to processes they already have in place. Open EHR solutions have an advantage in this category as the members contributing to the open source solution share experiences and preferences within the community.

As if the challenges of interoperability and usability weren’t enough, certification testing is its own hurdle. While MU2 offers a modular approach to test systems, the certification brings a hefty price tag. Many of the vendors who were the first to certify their EHR systems will bow out of the testing required for MU2 simply because the market is so saturated with competitors. These vendors don’t have the time or funding to invest in the onerous venture. In fact, many healthcare organizations have urged their senators to ask for a delay to meet the MU2 deadline because their EHR vendor isn’t ready with a solution that meets the requirements. Medical practices have invested a small fortune in their original EHR systems and now either must wait for an upgrade from the vendor (if the vendor is even working toward MU2 requirements) and potentially miss out on incentives while they wait or quickly find another solution that won’t cost them their revenue to install.

Vendors and healthcare practices alike are struggling to meet the January 1, 2014, deadline for meaningful use Stage 2 requirements. Many challenges have presented themselves, from meeting technology needs to usability, navigating certification costs and planning for future requirements.

As the race continues for MU2 certification, medical professionals will need to do their homework on what EHR systems are best for their organizations before the clock runs out.