William A. Hyman
Professor Emeritus, Biomedical Engineering
Texas A&M University, w-hyman@tamu.edu
Read other articles by this author
Users of software such as EHRs are sometimes presented with jargon laced responses that may be unique to the software world. For example, as I may have noted here before, I have long been fond of the term “upgrade” when used to mean fixing something that was never right in the first place. It is interesting to me that this usage is accepted as applied to software when it would be laughable in other contexts. Imagine having a car that you discover won’t start on odd numbered Tuesdays and you take it to the dealer and when you pick it up they say they had upgraded your car so that it would now start every day. Perhaps even better than an ordinary upgrade is a “rollback upgrade” which means the new version of the software doesn’t work so we are going back to the previous version. Speaking of laughable, there is a genre of software development humor that is labeled as jokes only a programmer would get. But one that is fitting for EHRs is “A user interface is like a joke, if you have to explain it, it isn’t very good.”
[tweet_box design=”box_05″ float=”none”]”Dogfooding” When #EHR developers don’t use their product and don’t understand the end user’s issues[/tweet_box]
A different form of software speak is being told “that’s what the software does” in response to a complaint about something that the software does. This might be accompanied by the assertion that it can’t be fixed. Such a situation was recently shared with me in the form of a complaint from a pediatric user that their EHR, from one of the big vendors, cut off their growth charts at 105kg and 36 BMI. This seemingly arbitrary limit interfered with the needs of their practice and the care of their patients. The user was told that there is no fix to this. This answer is probably nonsense, unless the code was so barely written and poorly documented that one would have to start over rather than modify it. But just in case someone might think that these cutoffs represented some fundamental truth the user tells us their previous EHR was fully scalable to their actual data. Perhaps no fix means “we do not currently have a fix to this”, or more likely “we could fix it but we aren’t going to”, or “we aren’t going to fix it in the near future because your complaint is number 674 and we are still working on number 5.” Getting such things fixed may be a function of complaint rates and shared visibility. But since there is no systematic way to file or publicly collate complaints about a particular EHR the user might be told less than truthfully that they were the only one to complain. This classic response is often tested in the hospital medical device world where vendors tell people that they are the only one with a problem, but the clinical engineers then ask their colleagues through various message boards if others have had that problem. The answer is usually yes.
The design process for software also has its own peculiarities. For example Spiral Design is popular in some circles. In this design process coding begins before there is a full set of specifications and associated user needs. Successive cycles of prototype software are then developed with each adding bits and pieces from user feedback. After a number of these cycles specifications might then be written describing what has already been created. But additional cycles are likely to occur after actual deployment, as reflected by multi-digit and letter version numbers. In this regard the FDA once forced the recall of a software driven medical device after multiple revisions within a year, stating that while they didn’t know if the current version was defective, the design process that necessitated multiple revisions clearly was defective.
A related term is “agile development” which is also an iterative and incremental (evolutionary) approach, again emphasizing a lack of bothering with well established initial requirements. Of course agile sounds like a good thing, especially if you don’t know what it actually means in context. After all, an advocate wouldn’t call it “clumsy development”. Yet one of the originators of the agile concepts also coined the document terminology Just Barely Good Enough, which is a high standard indeed.
Another interesting characteristic of piecemeal software design is that there is no need to go back through and clean up old loose ends and abandoned code, nor is there a need to streamline the design for manufacturing because manufacturing just involves copying what you already have, however ugly it might be. One might argue that if it works it works, but this overlooks the problem of fixing issues that are uncovered later or providing successful additions.
In preparing this post I also discovered the term “dogfooding” which refers to situations in which the software developer does not use their product and is therefore unable to understand what the user’s real issues are either before or after design. The term apparently comes from early live TV commercials for dog food in which the dog refused to eat the offered food. With EHRs of course the commercial developer is inherently not the user and may have little knowledge of the clinical domain, with this lack of knowledge seeming to persist for years. Perhaps we could demand that CEOs of EHR vendors become patients of their customers in order to test the impact of the EHR on their health care.