I’ve talked a lot about process, and the need to follow standards.
In a moment of (hopefully-not-rare) self-reflection, I realized that I must sound like one of those grumpy paper-pushing power-hungry jerks who slow everything down and insist on developers filling out stacks of forms to make the tiniest little change.
Ugh.
Nothing could be further from the truth. Really. I love developing quickly. It is such a joy to finish code for a device in a few months when you know that some contract shops would devote multiple people for a year. It is so satisfying to see a bug in testing and have a new software release that fixes it in thirty minutes.
I can’t stand it when people substitute appeals to process for critical thinking.
“That’s the way we’ve always done it” makes my skin crawl.
What gives then? Why have my last eight posts all focused on standards and processes?
Safety is not optional. Technology is hard. Humans make mistakes. These facts mean that we can’t depend on individual humans to always take the correct action in a complex environment when lives are on the line. We need to wrap a process around those humans to catch their mistakes and produce the best outcome.
The right process helps error-prone, inconsistent humans execute consistently and predictably.
The wrong process throws up unnecessary roadblocks, frustrates everyone, and causes people to do anything to get around the process and avoid following it. It’s completely counterproductive.
Despite my constant harping on IEC 62304 and its sibling standards, I want to uncover and evangelize ways to comply with these standards and still develop quickly.
Most of the software development world has embraced agile practices. Automated testing, infrastructure-as-code, and Continuous Delivery are now widely accepted as normal. It’s well-known within the web development world that the same practices that enable rapid development also increase quality. It’s not like there’s a tradeoff between speed and quality. In the long run, they are intertwined. These practices have spread to many teams that are developing embedded devices.
The medical device industry, on the other hand, is in the dark ages.
Most of the companies I’ve worked with track all their quality and regulatory documentation in Microsoft Word and Excel.
When I’ve spoken with QA and RA professionals about the QMS systems they use, it generally goes something like this: “All the available tools are terrible.”
Most medical device software teams still operate under the “code now, debug later” philosophy.
Test protocols are all performed manually, once, at the end of the project, when it’s too late to fix any of the problems they find.
No one developing class I and II devices creates software unit tests, because the standard only requires that for class III devices.
It’s killing me.
I’m committed to bringing modern development practices to the antiquated medical devices industry. I’m committed to doing so while maintaining the highest levels of quality and safety. I’m convinced that this is not only possible, but necessary.
This will be the focus of my writing, and my work. I’m glad you’re on the journey with me.
Happy developing!