So you’ve decided to develop software which is a Medical Device. Now you need to develop it in an IEC 62304 - compliant way.
Resources on how to achieve that are scarce. To add insult to injury, not even the IEC 62304 can be accessed freely! See the article on accessing standards on how to access it.
This is a very opinionated guide on how to achieve IEC 62304 compliance. The approach which I present here is just one option. I don’t claim for this to be the only way of achieving it.
General Requirements
You need a Quality Management System. This pretty much means that you need to implement an ISO 13485 - compliant Quality Management System and get audited for that. Note that this is a company-wide requirement: Your company becomes a qualified Medical Device manufacturer by having such a Quality Management System. You don’t have to re-do this for each product you plan on developing.
You need some sort of Risk Management. Specifically, your risk management needs to adhere to IS 14971. This is product-specific: You need to evaluate what can go wrong with your products and assess whether it’s still safe to go ahead and bring it to market.
Great, that’s it? Easy. With that out of the way, let’s see what we have to get done next.
Important: Software Safety Classification
The IEC 62304:2006 defines so-called Software Safety Classes: A, B and C. Depending on the risk profile of your software, it is classified as one of those three classes.
How do they differ? There’s a mostly-easy-to-understand flowchart in the standard for that (section 4.3), but the gist of it is:
- If your software can cause serious injury or death, it’s class C.
- If it can cause non-serious injury, it’s class B.
- Otherwise it’s class A.
It’s also important to note that this class doesn’t necessarily apply to all software in your soon-to-be-certified medical device: You can (and probably should!) have separate software systems which may have different safety classes.
This is important because, based on your safety classification, there are different documentation and testing requirements. As you might have guessed, class C includes the most effort.
It makes sense for critical software systems to be well-tested, but you should be beware of over-classifying your software systems which causes unnecessary overhead. You should also consider extracting critical parts into separate software systems (e.g., running in separate docker containers) to both increase resilience and decrease testing effort.
IEC 62304 Requirements
Write a Software Development and Maintenance Plan
You need to write a Software Development and Maintenance Plan in which you describe your required resources, software, version control and testing.
Software Requirements
For you software, you need to document so-called Software Requirements. These describe what your software does. If you have no idea what I’m talking about: Don’t worry, read the article.
Document Your Libraries / Dependencies (“SOUP”)
SOUP is the regulatory term for third-party dependencies or libraries which any sane developer uses in their code. You need to create some additional documentation for those and also monitor them regularly for issues like bugs or security vulnerabilities.
Check out my article on documenting SOUP:
Software Architecture
Depending on your software safety classification, you need to document your software architecture.
Software Verification
Any time you write code, you have to verify that that code actually conforms to your specifications. No clue what that means? You’re not alone.
Software System Testing
You have to test your software and prove that you’ve covered all software requirements.
Software Release
The 62304 has a few requirements regarding software releases. And this step is a good opportunity to check that you’re done with all other activities. And you have to determine whether you made a significant change to your product. In that case, you have to wait for approval from your Notified Body.
Manage Feedback and Problems
You need a process to manage feedback and evaluate problems. Most importantly, you need to assess whether a serious problem with your product has occured.
Once you’ve identified a problem, you need to solve it. Then, you need to check whether your solution actually works - who would’ve thought? The standard calls this a Problem Resolution Process.
Change Management
Once your product is released (i.e., certified), you can’t just go ahead and change it however you like. You have to check whether a change is significant and requires approval of your Notified Body. For that, guess what? You need a process.