Part I provides some background to IEC-62304. Part II provides a slightly more in-depth look at some of the specifics.
The IEC 62304 Medical Device Software – Software Lifecycle Processes looks into your development processes for creating and maintaining your software. The standard is available for purchase here.
So what activities does the standard look at? Here are some of the major topics. For any given topic, there will be a lot more specifics. This will look at a few of each, but this is not meant to be exhaustive by any stretch. One thing that might become apparent is that while you may have a standard way of performing many of these tasks, they’re probably not formally documented anywhere in any serious detail.
Planning. Most of the activities listed in the remainder of this document are required by the standard. The questions posed here ask if you have a plan for these tasks. The standard views these documents as living documents. So, similar to other tasks on the list, do you have a plan to maintain these documents and processes? Do you have a way to review and update them?
Requirements. These pretty much define the system. What exactly is this software supposed to do or not do? What gets listed here will be used for verification, risk assessment and error tracking. Verification determines if the software does what the requirements specify.
Architecture. How have the software requirements been applied to the architecture of the software? Define the inputs and outputs. If you’re including SOUP (Software of Unknown Provenance), specify why it is needed and what it needs to do. Are you breaking down a program into modules? You can use segregation for risk control. If you do, discuss that here as well.
Details. This breaks down the software into modules (“units”). For each unit, detail the design and interfaces.
Verification. The previously mentioned requirements detail what the system must do (and not do) to be considered functioning correctly. Verification is showing that the system is doing what the requirements have defined. This differs from validation. Validation is showing the system is doing what the customer requested in the first place.
Integration. What’s the plan for integration? How do you plan to integrate with other software or other systems including SOUP?
Testing. How do you intend to perform testing? Who will perform the testing? Is your testing automated? If so, what tools are you using?
Release. What is your process for releasing software? How do you track versions? What distribution method do you use to get it to its destinations?
Maintenance. How are updates distributed? How do you maintain the various versions of software available?
Error tracking. If an error is discovered in the software, how do you collect that data? How is it tracked? How do you track errors reported by customers?
Risk management. Risk is analyzing the device’s use and function and determining what could go wrong. How and when do you identify risks in the software? How do you address these risks? What features have been implemented to reduce these risks?
Configuration management. How do you track versions of software and the associated source code? What configuration management tools do you use for this? How do you identify the different versions?
Problem resolution. How do you assess issues? Which issues get addressed? If an issue is fixed, how does that tie into the other processes, like testing, release, maintenance and configuration management?
This is just to give you a general idea of the comprehensive and detailed nature of the IEC-62304 standard. This only scratches the surface. There are more sections and details that not are covered here. If you wish to learn more, I’d recommend purchasing a copy of the standard and reading through it.
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 or through email!
