Meaningful Use and Certification are at Odds

Every specialty has its peculiarities. Requirements Engineering, a subspecialty of Software Engineering, has coined the somewhat strange-sounding term "non-functional" requirement to describe those requirements that are not functional. Non-functional does not mean dysfunctional. Functional refers to those requirements that are specific and quantifiable such as the maximum size and weight of a product. It might be a requirement that something be provided, such as a panic-button or a problem-list. 

Other requirements are qualitative; a computer application should be "fast," "secure," or easy to use. There is probably never an app that is too fast or too secure, but it can become immediately and painfully obvious when one is too slow. Perhaps it would have been clearer if the non-functional requirements had been called "performance requirements."

Let's compare some of the stated requirements of "meaningful use" with examples of EHR Certification Criteria (from HHS materials.)

EHR Meaningful Use:
• Know more about patients
• Make better decisions
• Save Money

EHR Certification:
• Includes patient demographics and problem lists
• Has the capacity to provide clinical decision support
• Drug-drug, drug-allergy, drug-formulary checks
• Alerts
• Maintain active medication list
• Calculate body mass index

Let’s make a similar comparison for a car by analogy.

Car Meaningful Use:
• Safe
• Efficient
• Comfortable

Car Certification:
• Includes a source of propulsive power
• Seats five
• Has a brake pedal
• Provides on-board self-diagnostic and reporting capability
• Brake-throttle interaction checks

The certification criteria fit the definition of functional requirements while the meaningful use criteria are performance criteria. The functional requirements essentially state that some property must be present. Presumably you could put the brake pedal on the passenger's side of the car and position the seats in such a way as to block the doors and still strictly meet the criteria. The way the certification regulations are written, a vendor could probably contest the failure to receive a certification as long as all the required items can be accounted for. This is, unfortunately, the way most EHR procurements are specified and evaluated. Points are awarded for the presence of the brake pedal and the seats. Of course the car would neither be safe nor comfortable if the brake pedal was in front of the passenger and no one in their right mind would ever buy such a car. In fact no manufacturer would even consider building such a car.

When it comes to EHRs, vendors are quite happy to offer products that are inefficient, awkward, and uncomfortable to use and to do so with aplomb. Customers, for their part, are apparently quite willing to ignore performance requirements, and perhaps never define them; something they rarely do when purchasing other items. It is possible to compile a substantial list of performance requirements that an EHR should deliver, but that must be left for a separate discussion. Suffice it to say that the current crop of EHR products were designed before the notion of a performance requirement came into being; if it so happens that some of the performance requirements are satisfied, it's mostly by accident.

Of course, focusing on performance requirements is not a substitute for clear thinking. There was a time when Pontiac, emphasizing a low, sporty look, placed the engine so as to make four of the spark plugs inaccessible without pulling the engine. There needs to be a sanity check. Simply implementing a laundry-list of requirements, as so many products do, does not guarantee either sanity or good overall performance. This may explain high percentage of outright failures and the poor return on investment that characterizes many health IT projects.

The meaningful use requirements themselves seem pretty reasonable. If an EHR can meet the meaningful use requirements, isn't that the point? Shouldn't that be sufficient? If you want to incentivize particular behaviors, pay for performance, check for honesty and then don't agonize if that performance may have been achieved in a way that you did not anticipate.

Learn more about Dan Essin and our other contributing bloggers here.