|Jack Ganssle's Blog
This is Jack's outlet for thoughts about designing and programming embedded systems. It's a complement to my bi-weekly newsletter The Embedded Muse. Contact me at firstname.lastname@example.org. I'm an old-timer engineer who still finds the field endlessly fascinating (bio).
For novel ideas about building embedded systems (both hardware and firmware), join the 35,000 engineers who subscribe to The Embedded Muse, a free biweekly newsletter. The Muse has no hype and no vendor PR. Click here to subscribe.
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...
"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:
- How Projects Get Out of Control - Think requirements churn is only for software?
- 2019's Most Important Lesson. The 737 Max disasters should teach us one lesson.
- On Retiring - It's not quite that time, but slowing down makes sense. For me.
- On Discipline - The one thing I think many teams need...
- Data Seems to Have No Value - At least, that's the way people treat it.
- Apollo 11 and Navigation - In 1969 the astronauts used a sextant. Some of us still do.
- Definitions Part 2 - More fun definitions of embedded systems terms.
- Definitions - A list of (funny) definitions of embedded systems terms.
- On Meta-Politics - Where has thoughtful discourse gone?
- Millennials and Tools - It seems that many millennials are unable to fix anything.
- Crappy Tech Journalism - The trade press is suffering from so much cost-cutting that it does a poor job of educating engineers.
- Tech and Us - I worry that our technology is more than our human nature can manage.
- On Cataracts - Cataract surgery isn't as awful as it sounds.
- Can AI Replace Firmware - A thought: instead of writing code, is the future training AIs?
- Customer non-Support - How to tick off your customers in one easy lesson.
- Learn to Code in 3 Weeks! - Firmware is not simply about coding.
- We Shoot For The Moon - a new and interesting book about the Apollo moon program.
- On Expert Witness Work - Expert work is fascinating but can be quite the hassle.
- Married To The Team - Working in a team is a lot like marriage.
- Will We Ever Get Quantum Computers - Despite the hype, some feel quantum computing may never be practical.
- Apollo 11, The Movie - A review of a great new movie.
- Goto Considered Necessary - Edsger Dijkstra recants on his seminal paper
- GPS Will Fail - In April GPS will have its own Y2K problem. Unbelievable.
- LIDAR in Cars - Really? - Maybe there are better ideas.
- Why Did You Become an Engineer? - This is the best career ever.
- Software Process Improvement for Firmware - What goes on in an SPI audit?
- 50 Years of Ham Radio - 2019 marks 50 years of ham radio for me.
- Medical Device Lawsuits - They're on the rise, and firmware is part of the problem.
- A retrospective on 2018 - My marketing data for 2018, including web traffic and TEM information.
- Remembering Circuit Theory - Electronics is fun, and reviewing a textbook is pretty interesting.
- R vs D - Too many of us conflate research and development
- Engineer or Scientist? - Which are you? John Q. Public has a hard time telling the difference.
- A New, Low-Tech, Use for Computers - I never would have imagined this use for computers.
- NASA's Lost Software Engineering Lessons - Lessons learned, lessons lost.
- The Cost of Firmware - A Scary Story! - A hallowean story to terrify.
- A Review of First Man, the Movie - The book was great. The movie? Nope.
- A Review of The Overstory - One of the most remarkable novels I've read in a long time.
- What I Learned About Successful Consulting - Lessons learned about successful consulting.
- Low Power Mischief - Ultra-low power systems are trickier to design than most realize.
- Thoughts on Firmware Seminars - Better Firmware Faster resonates with a lot of people.
- On Evil - The Internet has brought the worst out in many.
- My Toothbrush has Modes - What! A lousy toothbrush has a UI?
- Review of SUNBURST and LUMINARY: An Apollo Memoir - A good book about the LM's code.
- Fun With Transmission Lines - Generating a step with no electronics.
- On N-Version Programming - Can we improve reliability through redundancy? Maybe not.
- On USB v. Bench Scopes - USB scopes are nice, but I'll stick with bench models.