The Perils of Over Specification and Underspecification in EHR Systems

Interoperability has been hard to achieve, in part, because the standards that have been agreed upon are simultaneously over specified and underspecified making them difficult, if not impossible, to implement.

The public and politicians are concerned about issues of healthcare cost and safety. Since the electronic health record (EHR) seems to offer a way to address both concerns, implementation and use of EHR has been made a national priority. Many of the anticipated benefits of the EHR depend upon the exchange of clinical notes and other information between practitioners, but these benefits can only be realized if the information that is sent is usable by the recipient. When this has been achieved, the information is said to be interoperable. Interoperability will be the topic of a future article. In preparation, this article will introduce the notion of over and underspecification.

In the context of the EHR, over specification can be understood to mean redundant or inconsistent specifications; information more precise than is required. Underspecification means that various elements of the specifications are incomplete or insufficiently precise. The criteria that EHRs must meet to become certified are a form of specification.

A story will illustrate over specification. In the mid-1950s Rolls-Royce is reported to have decided to offer automatic transmissions for the first time. The GM Hydra-Matic was selected and samples were purchased for further study. When these units were disassembled and the internal tolerances measured, the Rolls-Royce engineers were appalled by the sloppy way the parts seemed to fit together. They could not imagine putting any such component into a Rolls-Royce so their engineers set about to redesign the Hydra-Matic with more precise specifications. When they ran the first test on their re-designed replica, however, they discovered that the unit seized up tight and would not function.

Rolls-Royce learned that it is in the nature of an automatic transmission to require more generous tolerances.

The actions of the Rolls-Royce provide a classic example of over specification. In similar fashion, a myriad of committees has been busy developing specifications relating to various facets of the EHR.

The product of each committee is a long and seemingly precise list of specifications. Gradually, the individual specifications begin to overlap, producing conflicting definitions. It becomes difficult to discern which specifications define core capabilities and which merely state some intrinsic property of the underlying technology (such as the ability to update data in a database); they are all presented as being equally critical. Also, as the length of each list grows, committees find that they lack the knowledge and resources necessary to specify each item with sufficient precision.

The dynamics of committee work tend to magnify the degree of both over specification and underspecification. The list of requirements grows for a variety of reasons: 1.) political correctness, 2.) to satisfy the demands of vocal or powerful members; and 3.) to secure the agreement of dissident factions. Individuals who may recognize that a particular item is vague, ambiguous, or inappropriately detailed may be reluctant to speak up, because such input is often perceived by the group as disruptive and social pressure is exerted by the group to minimize such “distractions.” Consequently and paradoxically, while specifications arrived at by consensus tend to be over specified, many of the individual elements in the list are in fact ambiguously underspecified and inadequately precise. The aura of authority that surrounds the process of establishing standards can create a false impression that the specifications are precise and contain everything they “should” contain.

Interoperability has been hard to achieve, in part, because the standards that have been agreed upon are simultaneously over specified and underspecified making them difficult, if not impossible, to implement. History is replete with examples of devices with simple, loosely fitting parts that work better than if a tight fit had been attempted - and those devices get working a lot sooner because loose fitting parts are easier and cheaper to build.

Find out more about Dan Essin and our other Practice Notes bloggers.