EHR Planned Obsolesence

EHR System Technical Functionality vs. UsabilityEHRs Come with Built In Obsolescence with Changes Associated with Meaningful Use

William A. Hyman
Professor Emeritus, Biomedical Engineering
Texas A&M University,
Read other articles by this author

I remember a time when at least some people railed against planned obsolescence, at least until they “needed” a new cell phone every year-or maybe sooner. Planned obsolescence has at least two forms, both based on the obsolescence being the intent of the manufacturer. One is that the original product is still functional, but the new product has more and better features, or is otherwise more desirable, and that therefore we should get a new one even though the old one still works. In some cases this at least allows product trickle down in that the now rejected product becomes someone else’s “new” albeit used product, if we are repurposers and don’t send our old stuff to the dump or even for recycling. A second form of planned obsolescence is that the old product is no longer useful either at all or in some manner and it therefore has to be replaced. Outright failure is included here as in short lived light bulbs, or the inability to change batteries in some popular products. Creating new incompatibilities also drives obsolescence. Lack of continued support is another version that was recently discussed here in regards to the coming end of security patches for Windows XP, which means that no computer running XP can be part of a secure network that by regulation requires users to obtain and install patches.

EHRs have had their own built in obsolescence in the form of the changes associated with the three stages of meaningful use (MU). Recent and current products could not be designed to be compliant with all aspects of MU because the requirements have been created incrementally. This continues to be the case for Stage 3 and the presentation slides of a February 4, 2014 meeting of the Health IT Planning Committee has recently been released which highlights a number of changed and new requirements that are said to be built around several broad principles such as supporting new models of care and meeting national priorities. An example of a proposed changed requirement is that diagnostic images should be available through the EHR. A new proposed requirement is that an EHR must accommodate entry (by unspecified means) of an implantable medical device’s Unique Device Identification (UDI) number which all such devices will soon have as a result of the FDA’s mandatory UDI program. Final approval of the Committee recommendations is scheduled for March 2014, with a final rule by the 1st half of 2015.

One might have hoped that for Stage 2 the new requirements would have been accomplished via upgrades or add-ons that were fully compatible with the existing product and produced a seamless new capability, yet with that new capability easily recognizable to the users. Having new features can be quite different from finding them and learning how to use them. This relatively seamless transition did not occur for all EHR products and some vendors who had been certified for Stage 1 dropped out before being certified for Stage 2. In some cases this left Stage 1 adopters of those products with an EHR that was still functional, but no longer able to meet MU, garner incentive payments and avoid penalties. In other cases the old product died along with the vendor. In either case the provider then had to switch to a new EHR. This is likely to also be the case for Stage 3. Some vendors will meet the new requirements and provide updates or otherwise revised packages that are not disruptive with respect to their Stage 2 offerings and functionality. In other cases revisions for Stage 3 will be met but with a product that is sufficiently different from the Stage 2 version that its use may approach the experience of switching to a new vendor. And some vendors may find meeting the Stage 3 requirements a good opportunity to exit the business, forcing its customers to go elsewhere.