Geonetric submitted comments this morning on the proposed Stage 2 requirements for Meaningful Use. We share those comments here:

As we look forward to the next stage of Meaningful Use (MU), we are excited. While the MU Stage 2 NPRM focused attention on a number of areas that most providers avoided in Stage 1, there were some pleasant surprises, particularly in the area of patient and family engagement.

Engagement

Most important is newly proposed requirements for patients to actually USE the software. The ultimate goals of healthcare reform require patients to be partners in their care. New models of care don’t work without robust patient engagement.

Patient engagement is an area which we, as an industry, are currently weak. The absence of criteria in Stage 1 for the actual use of deployed tools has led many EHR vendors and provider organizations to take a “check the box” mentality. The result: a lack in usability from many patient-facing technologies deployed during Stage 1. The newly proposed metrics will overcome this.

I hope these requirements were not put into the NPRM with the intent of being sacrificed. I anticipate there will be negative comments in this area. In fact, I’ve already heard some in the industry suggest these items were added so they could simply be removed later as a way for CMS to appear responsive to public comments.

Stage 2 patient engagement requirements are a reasonable and necessary step to verify the meaningful use of consumer-facing technology. Not only will vendors be required to improve tools that are unusable today, but provider organizations will also be required to incorporate these technologies into clinical practice.

It is certainly possible to look to different metrics of patient access and use. For example, we need further clarification as to what constitutes a secure message under §170.314(e)(3). Certain platforms use messaging as an unstructured way to communicate what should be managed as structured data, and I’d hate to see a further move in that direction as an unintended consequence of these requirements

One of the key tenets of Meaningful Use has always been that installing the software is not enough. These changes are intended to reflect the way that healthcare organizations work.  Such changes are hard, but it is my sincere hope that you hold onto that vision and keep the requirements in the final rule that are intended to accomplish it.

Process of Certification

The other exciting changes include the certification and attestation process. This is a clear response to frustrations from both vendors and providers.

While I applaud steps to eliminate the need to package, test and deploy tools that are irrelevant to a particular solution, I fear the approach taken is very tactical rather than strategic. They ease the pain but don’t eliminate the underlying problem.

The underlying problem is that the certification process has been designed backwards.  The process was begun by envisioning a single-source comprehensive EHR solution and then trying to piece out its components. MU Stage 1 required vendors to demonstrate requirements that weren’t relevant to their products, and providers to purchase and implement software that wasn’t relevant to their practice.

Taking this model and adding some flexibility is certainly a step forward, but it fails to address the underlying model failure.

Instead, the model should look at each requirement as a stand-alone. What do we expect that component to do? What do we expect it to get from other systems? How do we expect it to relate to its neighbors?

Providers and vendors have been confused with Stage 1’s boundaries. For example, consider Discharge Instructions. Clearly the system that generates those instructions requires certification. However, if there is a patient portal in place that delivers them to the consumer, does that piece also need to be certified for that requirement?

Those boundary issues continue for any situation where providers wish to implement a best-of-breed component alongside a solution certified as a Complete EHR. Because the Complete EHR is certified as a unit, providers must purchase and implement components from that solution they don’t intend to use in order to have the certified package.

Further, integration and data sharing shouldn’t just occur between complete EHRs, but also from module to module. This requires defined interfaces for key information at a more granular level. Without this, complete EHR vendors are locking in their clients with the pain and expense of a complete EHR migration.

To encourage the innovation and competition needed to improve healthcare, we need a better pathway for the implementation of certified modules. We need to serve the needs of specialty groups more effectively and provide an easy way for them to implement only the pieces relevant to their practice.

This NPRM represents a significant step forward in defining the necessary HIS infrastructure to support the health system we want in the future. I hope you’ll take these recommendations to heart. Stand firm on requirements for patient engagement. And take steps to encourage innovation by allowing providers to implement best of breed components to their strategies.