IEC-62304 Software Lifecycle requires a lot of self-reflection to scrutinize and document your development processes.
There is an endless pursuit of perfection when it comes to heavily regulated industries. How can you guarantee something will have zero defects? That’s a pretty hefty task. The regulatory approach for the medical device industry is process control. The concept essentially states that if you document how every step must be completed, and provide checks to show every step has been completed properly, you will get consistency and a quality result. For software used in the medical device industry, *IEC-62304 Software Lifecycle* is the standard by which the regulators judge the process. The standard applies to any “software” that is used in a medical device. That includes everything from the logic programmed into a Programmable Logic Device (PLD – an integrated circuit which provides some basic digital logic gates whose functionality can be programmed by the developer) on the circuit board, to the real-time, 3D GUI used to control a large diagnostic scanner. It doesn’t apply to the software used in the office to maintain the patient records database or send out the bills. But it does apply to any device which is used to diagnose or treat health conditions. If it gathers data to be used to diagnose a condition, or it attempts to treat a condition, it’s a medical device. I’m looking at you $10 digital thermometer.
The IEC-62304 standard (let’s just call it “the standard” from here forward) only looks at the medical device software. Compliance with the standard is just one piece of a bigger picture, which includes a number of electrical and mechanical safety standards, which all exist in parallel. This collection of standards covers the medical device itself.
The company that designs and builds the medical device also must implement the ISO-13485 Medical Devices – Quality Management System, which provides an overall quality system. This overall umbrella covers everything from product concept, design, testing, manufacturing, distribution and returns, defect investigation, notifications, documentation, regulatory approvals, and on, and on, and on. If the overall quality system was the earth, IEC-62304 would probably be North America — it’s a small piece of a big interconnected system.
The standard doesn’t specifically tell you how to do anything. What it does is provides a list of required activities, and it gives you the opportunity to detail how you implement these activities. It’s called the lifecycle standard because it covers everything from initially creating the software through its support and retirement. The whole thing is verified through audits performed on behalf of the regulatory body.
The Primary Question
The standard requires an assessment of the role of the device to answer a specific question: if the device went awry, how much damage or injury could it possibly cause (worst case scenario)? Depending on a three-step scale that ranges from “nothing-much” (Class A) to “serious injury/death” (Class C). As you move up the scale, the list of required activities to be implemented increases. The underlying assumption is that the software will fail, so the risk analysis must assume the worst. Analyze the risks involved, and anything that causes a significant risk should have the means to mitigate that risk. The concept is that design decisions should be influenced by the possible risks caused by those same decisions.
The standard also requires broad coverage at different levels. You have defined a set of processes for code development and maintenance. These processes also apply to parts of your system that are not being developed by you. For example, if you hire a contractor to work on site, or you hire an outside subcontractor to develop a module, those developers should be trained on, and perform development, following your processes. A subcontractor could also have a qualified quality system including a set of documented procedures that meet your standards, in which case you can choose to rely on that system for the contracted work.
Someone Else Wrote It
It gets more interesting when you don’t have knowledge of the processes used for the development of a module. That software is referred to as SOUP: Software Of Unknown Provenance. Lots of things fall into this category including things like an open-source library pulled form the internet, or a closed source operating system. Without the documented origins, development methods, and history, the value of the software as part of the system gets weighed against any possible risks it introduces.
The question at hand asks if the use of the software could introduce any possible risks? For example, if the proprietary operating system locked up, is injury a possibility? Could that library miscalculate a value that would change a doctor’s diagnosis or treatment? Could the communications software lose or modify valuable information without notifying the application?
The possible risks may create an environment where it would be preferable to not use a third party piece of software, and instead, write your own. Do you really need an operating system? Maybe a simple task switcher is sufficient.
While it may be reasonable to perform a code review on a simple piece of third party code, it’s less realistic to do the same thing with something more complex, like an operating system, or a TCP/IP stack. And that assumes the source code is available for review. Without source code, you have a blackbox for which you need to vouch, which is inherently more difficult because you don’t have the source code to qualify. This will come down to an assessment of features provided by the software plus the time to review, test, and verify it versus writing your own software using the development processes.
Look closely, and formally detail every step
IEC 62304 aims to use formal documented processes to guide development to create more consistent and higher quality software. It requires a lot of detailed self-reflection to scrutinize and document your development processes. It also expects regular updates and maintenance on the documentation of the processes and the processes themselves.
And if you have questions about an embedded project you’re working on, Dojo Five can help you with all aspects of your devops for embedded journey! We are always happy to hear about cool projects or interesting problems to solve, so don’t hesitate to reach out and chat with us on LinkedIn https://www.linkedin.com/company/dojofive/ or through https://dojofive.wpengine.com/contact/ email!
