Doing a Software Release in Compliance With IEC 62304

The 62304 doesn’t have many requirements regarding Software Release. They’re mostly about whether you have finished all other activities prior to releasing your software. Those IEC people don’t have a whole lot of trust in software developers, do they?

And there’s another important point when releasing your software which isn’t stated in the 62034: You have to determine whether your new version is a so-called significant change. If so, you have to wait for approval from your notified body before you can release. More on that later.

Let’s look at the requirements from the IEC 62034 first.

IEC 62304 Requirements for Software Release

The requirements in IEC 62304 regarding software release can be summarized as “don’t be stupid, ensure that all stuff is done” (section 5.8 of the standard, their language is slightly different). Specifically, these activities include:

• Software verification is complete
• All activities described in the software development and maintenance plan are done
• Document and evaluate residual anomalies
• Document released version and how it was created
• Archive released version
• Have an idea how to deliver that released version to your customers

Alright, let’s see how you can implement those. The software verification is pretty straightforward and described in my article. You just need to make sure that you’ve run all your tests on the current version, and you need some documentation to prove that.

All the activities mentioned in your software development and maintenance plan must be done. What are those activities? Mostly software system tests. Just like with verification, ensure that they’ve all been run on the version you’re about to release. And don’t forget traceability: You need to be able to trace each test to a software requirement; and each software requirement must be covered by at least one test.

You probably also described your configuration management in your software development and maintenance plan. That hopefully includes that you tag a new version in git once you release it. So that’s what you should do at this stage.

Next, you document your residual anomalies. How do most people go about that? By writing a change log which includes those anomalies. It’s always a good idea to have a change log anyway.

But most importantly, you have to evaluate each residual anomaly if it’s safe to release. This makes sense, because you wouldn’t want to ship software which harms users, especially if you already know about the problems beforehand (which sane person would do that?). So how do you go about that? Just do a risk analysis for each known anomaly and put that in your risk table. Hopefully I’ll have an article covering that soon.

You need to document your released version, how it was created and archive it. Just tag the relevant commit with the version number in git (you can also use the GitHub releases page for this). Ensure that all relevant files (code, build files, assets, etc.) are committed (and not excluded). Add a short description in the readme how to compile and deploy that version. Bonus points if you’ve mentioned all this in your software development and maintenance plan.

Finally, you should have a process on how you plan to deliver that new version. In the age of cloud computing and SaaS software, this requirement is somewhat trivial to fulfil: If your software is a SaaS which is also operated by you, you just.. deploy it? Your customers will automatically start using the new version. In the dark ages when software was being distributed by CD-ROMs in the mail, I suppose this process was more relevant.

But there still are some nuances to it which may apply to you: Will you inform customers that a new version is available? Will you force them to upgrade? My crappy iOS banking apps sometimes do that. Will you provide some instructions to users on new features or changes in the user interface? (By the way, if you made significant changes to the user interface, you might have to re-do you usability testing.. let’s go there another time.)

Once you’ve figured that out, you’re good to go! At least from a 62304 standpoint. The fact that this is a medical device makes things a bit more complicated, as we will see.

Significant Change? Inform Your Notified Body

Things get messy when you’re making a so-called significant change to your software. What the hell is that? That’s an entirely different topic. See my answer for what constitutes a significant change. But note that this is yet another decision which ultimately lies with your auditor; and judgements between auditors may vary widely here. Also note that an increase in a major or minor version in your semver versioning scheme doesn’t necessarily mean it’s a significant change.

Assuming you’ve got answers to those tricky questions, what remains to be done?

If it’s not a significant change, you’re good! Just go ahead and release it.

If it’s a significant change, you need to send your technical documentation to your notified body, or rather, the auditor who’s assigned to you. The exact process may differ based on the terms of your notified body. It would make a lot of sense to give your auditor some guidance on what changed. So besides sending over your entire technical documentation, you should add a list of documents which were modified since the last release, and a human-readable “executive summary” of your product changes. This makes life easier for your auditor when trying to understand what the hell you’ve been up to.

Don’t Know If It’s a Significant Change?

What if you’re not sure if it’s a significant change? Welcome to regulatory hell. You may be stuck between consultants who give you different assessments, your auditor who’s not allowed to consult you, and the customer reps of your notified body who have no clue. It’s a tough spot. I suggest you just make a decision and create documentation which supports your line of reasoning. More on that in my significant change answer which I linked above.

You’ve released your software. Congratulations!