The idea that software can be a product (as in “product liability”) is not new, but gray areas remain with regard to when that should be and how courts should handle it.  Take for example a case that we wrote on a couple of years ago, in which a district judge in Virginia granted summary judgment for the manufacturer of an electronic health records (“EHR”) system.  A patient suffered severe complications after a doctor entered post-op instructions into the hospital’s EHR computer system, but the hospital implemented the orders at the wrong time.  Whose fault was that?  We don’t know, but the district court ruled that, even though the patient’s experts identified software changes that would have made the system safer, they did not identify a standard of care that the EHR system failed to meet. 

Well, a couple of weeks ago, the Fourth Circuit reversed and held that the experts had very well identified a standard of care and further that there was evidence sufficient to support a failure-to-warn claim.  The case is Lowe v. Cerner Corp., No. 20-2270, 2022 WL 17269066 (4th Cir. Nov. 29, 2022), and the facts are worth repeating.  Following surgery, the patient’s surgeon entered orders for “continuous pulse oximetry” into the EHR software developed by the defendant and deployed by the hospital.  However, although the surgeon intended for pulse oximetry—i.e., checking blood oxygen—to be continuous, she chose “once” and “daily” from the system’s dropdown menus, which defaulted to 10:00 each day.  The system correctly displayed that time on the order confirmation screen, but several orders were entered that day, and the surgeon did not scroll down to review them all.  She clicked through some version of “accept all.”  Unfortunately, checking blood oxygen at 10:00 was too late for this poor patient, who suffered severe and permanent disability.  Id. at *2-*3. 

The Fourth Circuit’s opinion reversing summary judgment for the EHR software developer raises several questions.  First, this is a product liability case, but what was the product?  It was the software.  We find that noteworthy because software is not tangible, like a hip implant or a cholesterol drug.  Software is a series of ones and zeros organized by people with special skills to perform ever-more-complex functions—not the sort of “product” we are accustomed to seeing.  (See here our November 2021 report on what we called the first decision to recognize software as a product for purposes of state product liability law.)  No one in Lowe v. Cerner seems to have questioned whether the EHR system was a product for liability purposes—maybe because Virginia does not allow strict product liability—but that was the first thing that struck us.

Second, how do you establish a standard of care for software?  Software is continuously under development, and there is always something else the programmers can do.  I am told that newer mobile phones can detect whether I have been in an accident and automatically call for help.  Does that mean that my older phone breaches a standard of care because it is too dumb to do that?  The patient’s experts in Lowe offered standards for the “useability” of user interfaces—one published by NIST another published by a non-profit healthcare organization (known as HIMSS).  Lowe, at *6.  But the defendant’s EHR system undisputedly complied with IT Certification Program promulgated by the Office of the National Coordinator of Health Information Technology.  Who is to say that alternate standards of “useability” should displace certification criteria that specifically applied and which the defendant followed?  This discussion of industry standards reinforces in our minds just how esoteric this can become when discussing software. 

Third, what was the basis for a failure-to-warn claim?  Remember this was not a medical device that carries known and knowable risks.  It was software, an electronic health records system designed to record orders for medical professionals to carry out.  Moreover, the hospital had been using the system for several years without incident, and the defendant had never received a report of patient harm under a comparable scenario.  The defendants had received, in 2009, a report of a physician’s orders defaulting to the following morning.  Id. at *11.  The district court found that customer complaint too dissimilar to support a duty to warn, but the Fourth Circuit disagreed.  That report gave the defendant notice of a dangerous condition and thus gave rise to a duty to warn.  Id. at *11-12.

Fourth, the case presents difficult causation issues.  As pointed out by a vigorous dissent, the hospital staff made “multiple lapses” that call into question whether correct orders from the surgeon would have even been obeyed.  Id. at *13.  While the majority held that the plaintiff need not rule out every alternate cause, the dissent noted that the plaintiff at least had to prove that the software developer’s alleged negligence was in the but-for causation chain.  On that score, the dissent found “only pretty thin gruel” in 32,000 pages of discovery and the designation of seven experts.  Id. at *12.  That is another way of saying that this plaintiff did not present evidence of causation sufficient to reach a jury.  Of course, the majority disagreed.

We will continue to track closely as software cases wend their way through product liability law.  In most every product liability case, the plaintiff will allege that the product could have been better.  Software just feels a little different, again because there is always another update, another version, another tweak, another bug fix coming down the road.  To borrow from the dissent, the risk is that these cases will become a quest for “the safest conceivable design.”  Id. at 14.  That is not what product liability law aims for.