The IEC-62304 Software Lifecycle Standard 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 microcontroller/PLC/PLD on the circuit board, to the real-time, 3D GUI used to control a large diagnostic scanner. “A medical device” refers to any device that gathers diagnosis data or is used to treat health conditions. This would include something as simple as a $10 digital thermometer. What it doesn’t apply to, for example, is the software used in the office to maintain the patient records or send out bills.
The IEC-62304 standard only looks at medical device software. In addition to this standard, medical devices must also comply with ISO-13485 Medical Devices – Quality Management System, which provides requirements and framework to develop an overall quality system. This overall quality system covers everything from product concept, design, testing, manufacturing, distribution and returns, defect investigation, notifications, documentation, regulatory approvals, and so forth. The difference between the two standards is that IEC-62304 focuses specifically on the software development and lifecycle process, whereas ISO-13485 defines a quality system for the entire medical device life-cycle (includes hardware, software, mechanical, etc). Instead of specifying exactly what tools to use or how to write software, IEC-62304 broadly provides a list of required activities, and then gives you the opportunity to detail how those activities were implemented. This list of activities covers everything from initially creating the software, all the way through its support and retirement (hence the “lifecycle standard” name). These activities are then verified through audits performed on behalf of the IEC regulatory body by a licensed company or group of individuals.
The Primary Question
The IEC standard requires an assessment of the role of the device to answer the following question: if the device went awry, how much damage or injury could it possibly cause (worst case scenario)? This is measured 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 IEC standard also requires broad coverage at different levels. It will require you to define 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 from 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 whether use of the software could introduce any possible risks. For example, if the proprietary operating system locks 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. Another option in this case is to find third party software that is already designed to be placed into a medical device development process. One example of this is SafeRTOS, which contains documentation on how to integrate their RTOS into a product requiring IEC-62503 Class C certification. Using third party software like this can be preferable because, while it may be reasonable to perform a code review and analysis on simple third party code, it’s far less practical to do the same thing with something as complex as an RTOS or TCP/IP stack. And that’s assuming the source code is available for review. Without source code, you have a black box for which you need to vouch, which is inherently more difficult because you don’t have the source code to qualify against. The choice of what to use ultimately comes down to assessing the features provided by the software, along with the time required to review, test, and verify it, versus developing your own software using your established development process.
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.
Streamlining IEC-62304 Compliance with Modern Firmware Development Tools
Navigating the complexities of IEC-62304 software lifecycle processes requires more than just documentation — it demands a disciplined, repeatable development environment that ensures traceability, consistency, and control over every step of your firmware workflow. The challenge? Managing toolchains, processes, and compliance artifacts in a way that doesn’t slow down your team or introduce unnecessary overhead.
That’s where EmbedOps can help. EmbedOps provides a modern DevOps platform purpose-built for embedded firmware teams, giving you a centralized system to manage builds, tests, toolchains, and compliance documentation — all in a reproducible and auditable environment. Whether you’re tackling Class A or Class C medical device software, EmbedOps helps reduce risk, streamline audits, and accelerate your path to compliance.
If you’re looking for expert guidance on how to modernize your firmware development process while maintaining regulatory rigor, book a call with our team. Let’s discuss how Dojo Five can support your next project.
