Meaningful Use Requirements: Functional or Nonfunctional?

You may remember the discussion about the difference between functional and non-functional requirements from a few months back. Wikipedia summarizes it well: "In systems engineering and requirements engineering, a non-functional requirement is a requirement that specifies criteria that can be used to judge the operation of a system, rather than specific behaviors. This should be contrasted with functional requirements that define specific behavior or functions. The plan for implementing functional requirements is detailed in the system design. The plan for implementing non-functional requirements is detailed in the system architecture.

"Broadly, functional requirements define what a system is supposed to do whereas non-functional requirements define how a system is supposed to be. Functional requirements are usually in the form of 'system shall do <requirement>,' while non-functional requirements are 'system shall be <requirement>.'

"Non-functional requirements are often called qualities of a system. Other terms for non-functional requirements are 'constraints,' 'quality attributes,' 'quality goals,' 'quality of service requirements' [performance requirements], and 'non-behavioral requirements.'  Informally these are sometimes called the "ilities", from attributes like stability and portability. Qualities, that is non-functional requirements, can be divided into two main categories:

To the average physician, the words "meaningful use" imply use that contributes substantially to improved care, a better work experience and/or improved safety. These are clearly non-functional requirements. To the extent that an EHR exhibits qualities that facilitate the realization of these objectives, physicians would say that their use of such a system was "meaningful." If the EHR interfered, even if it performed useful functions, physicians might have little interest in using it at all.

The government has repeated a frequent blunder - that of creating a new, counter-intuitive definition for words that already have a clear, common-sense meaning. The new "meaningful use" does not address qualities.  Rather, it is now denotes a detailed, but over-specified, set of functional requirements that an EHR must satisfy.

Apart from confusing physicians, the HHS inspector general was led to ask some interesting questions centering on the following theme: Are EHRs that meet the certification (functional) requirements capable of collecting data that is sufficiently detailed and accurate to meet the reporting (functional) requirements specified by meaningful use?

The inspector general's report says (among other things): "Although CMS’ prepayment validation functions correctly, it does not verify that self-reported information is accurate. The validation checks that self-reported numerators and denominators calculate to required percentage thresholds and that all relevant yes/no measures were checked 'yes.' However, it does not verify that numerators and denominators entered for percentage-based measures reflect the actual number of patients for a given measure or that professionals and hospitals possess certified EHR technology. Sufficient data are not available to verify self-reported information through automated system edits… CMS considered using automated … system edits to verify professionals’ and hospitals’ self-reported meaningful use information prior to payment, but found that sufficient data were not available to do so…

"CMS did not identify any data sources it could use to verify any of the 49 meaningful use measures. According to CMS staff, existing internal and external data sources are not comprehensive enough for verification and, in some cases, are not easily accessible. Further, no data sources exist for many of the meaningful use measures."

Each meaningful use measure carries an implied definition of which patients or cases should contribute to its denominator. In almost every instance, patients should be excluded if there are ambiguities or uncertainties about their data. Unfortunately, the typical data system is based on the assumption that accurate, unambiguous data are always available. They do not make provisions for gathering ambiguous, approximate data nor do they even allow a "data quality indicator" that could flag the entered data as imprecise or suspect.

Perhaps the inspector general is beginning to appreciate what could have been predicted from theory: Today's EHRs are not designed to collect data in a way that allows accurate meaningful use reports to be created. Now he must decide whether form or function is more important. If form, then: Don't ask; don't tell. Just trust the self-reporting and OK the payments. If function, then: Make no payments. Go back to the drawing board and either change the criteria for reporting or change the criteria for certification. The present situation would be laughable if it weren't so pathetic.