Follow @jack_ganssle
Jack Ganssle, Editor of The Embedded Muse Jack Ganssle's Blog

This is Jack's
occasional outlet for thoughts about designing and programming embedded systems. It's a complement to my bi-weekly newsletter The Embedded Muse. Contact me at I'm an old-timer engineer who still finds the field endlessly fascinating (bio).

RSS Feed

Medical Device Lawsuits

January 4, 2019

I came across the following graph the other day (Click on image to blow it up):


It shows the number of product liability suits filed in the USA over the last decade or so. The vertical axis is a log scale.

There are a couple of interesting points. First, note that asbestos cases have plummeted from tens of thousands per year to hundreds. Something changed in 2012; I have no idea what.

Consider aircraft: There are very few product liability suits filed each year, despite the fact that 741 million passengers flew in the US last year. Why so few problems? I'd attribute this to the aircraft industry's obsessive focus on quality.  Software is done to the DO-178C standard which has five levels depending upon how critical the code is. At level A only the highest-quality code is acceptable, and teams must prove its quality.

But look at medical devices on the chart. Those suits have been on a steady, almost breathtaking increase in product liability suits over the last decade. I don't have any data that indicates how many of these issues are a result of problems with the embedded hardware or software but wouldn't be surprised to find more than a few.

For instance, in 2010 the FDA sent a letter to makers of infusion pumps indicating that some 56,000 adverse incidents had been reported with these devices. 1% of those (around 560) resulted in deaths and 34% serious injuries. The letter makes it clear that in at least some of these incidents the software was at fault.

Killing or injuring your customers is a lousy way to get repeat business.

In a patent dispute involving a safety-critical medical device in which I was an expert witness we found the code was horrible. It violated pretty much every tenet of good software engineering. I can't go into detail without violating the protective order, but I was told at least one death was attributed to the device.

In the medical world device manufacturers supply a 510(k) to the FDA that shows "demonstration of substantial equivalence to another legally U.S. marketed device. Substantial equivalence means that the new device is at least as safe and effective as the predicate." Sounds reasonable, except in the case of the device I mentioned the firmware that was finally delivered bore little resemblance to that outlined in their 510(k). Of the hundreds of versions of its code that I examined, the variations between versions in terms of how the device operated were huge. It was clear the engineers had no idea how the machine should have behaved, and issued many major revisions till it presumably worked correctly.

As far as I know there is no closure, no audits, to insure a match between real units and those claimed in 510(k)s.

There are other standards for medical devices, like 62304. These are often surprisingly vague, though companies I've worked with who conform to them generally work hard to meet both the spirit and the letter of the standards. This can be quite expensive, with a test/qualification program that can take months each time a new version is released.

I admire those companies that work hard to both conform to standards and create reliable, safe medical devices. But with the explosion of product liability lawsuits one wonders about the maturity of the engineering processes used.

I read a lot of code. NDAs and protective orders zip my lips, but I can say this: more teams are using decent software engineering processes than of yore. So the optimist in my hopes that this spike in product liability suits is at its peak. The reality is probably a bit grimmer as products' complexity is skyrocketing and firmware finds more roles in more devices.

A company I worked with last year was motivated by a number of suits to revamp their software engineering processes. It seems a terrible shame that the legal system is driving engineering.

Feel free to email me with comments.

Back to Jack's blog index page.

Bob Dunlop responded to this post:

Thank you for a very interesting, and frightening, view of medical devices.  I am an RN with a Masters in Nursing, and recently retired from a 5+ year stint as an Asst. Professor of Nursing (I taught pathophysiology, pharmacology and medical-surgical nursing), and prior to that had 8 years working in a Medial & Cardivascular ICU in San Francisco for a major healthcare provider.  I remember when the Baxter IV pumps disappeared from the market... Prior to becoming a nurse, I spent 15+ years as a software engineer designing, coding, tesitng and implementing GUIs to enterprise databases for Del Monte Foods, Blue Shield of California and smaller companies.

When I transitioned to nursing following the implosion of the software development market in 2001 in the SF Bay Area, I thought I was well positioned to play a role in the integration of patient care systems and direct patient care.  Boy was I wrong...

Medicine is a weird combination of bleeding and trailing edge technologies, with many practitioners being dragged kicking and screaming into a future they often hate. When my employer decided to embrace technology in its entirety, I had the "pleasure" of training the floor nurses to work with the new system. While I was initially excited to work with the system, I was quickly disabused of the notion that this would be a step forward. As the MD running the initial rollout commented, "The software (is) a great example of  early '90s software." This was in 2007.  The "enterprise" system was written in VB (and much of the systems is still in VB, according to a trusted source). The design was carried out without the use of any medically literate domain experts - no MDs, no RNs, no Pharmacists - which was painfully apparent, and further, the engineers in most cases were new grads.  I know this from face-to-face conversations with the engineers who were on site for the rollout.

So, instead an system that reflected how medical providers approach a patient (more or less holistically and head to toe systems assessment), the engineers had approached the very difficult and complex problems by breaking everything down into "modules" - makes sense from a systems point of view, but is completely foreign to how providers think. Finally, there were numerous examples of a total lack of understanding of the professions involved and how they interact with a patient.  One of the classic examples: Bladder catheters used for managing urine, which are by definition not "invasive" - they don't penetrate the skin - were lumped in with Intravenous and arterial lines. These errors were distressing and added to a level of distrust in the system.

Sorry for the rant.  To my actual point: These systems are even less regulated than the medical devices you wrote about, and yet they are used for all aspects of providing patient care, both in the hospital and out.  There are documented cases of human/computer interface errors that have led to sentinel events:

"Order entry error. A dehydrated lung cancer patient was admitted to the emergency department for intravenous (IV) hydration. Another patient from a motor vehicle accident (MVA) was awaiting intubation and transfer to a local trauma center. The same physician was caring for both patients. The physician gave verbal orders for vecuronium and midazolam for the MVA patient, but he inadvertently entered the medication orders electronically into the cancer patient's record. The nurse caring for the cancer patient went on break, and a covering nurse administered the paralytic and sedative to the cancer patient even though he was not intubated. The patient experienced a respiratory arrest and died."

From this NCBI article.  Vecuronium is based on Curare... midazolam (Versed) is a very potent CNS depressant

Recent blog postings: