Introduction to IEC 62304
IEC 62304 is the international standard for software development and testing of medical device software that is well-recognised as the best approach by many medical device regulators (including the UK MHRA, EU European Commission and US FDA).
Its current version (IEC 62304:2006+Amd1:2015) was released in 2006 and the last update was in 2015. However, an International Electrotechnical Commission working group have released a new draft version of IEC 62304 for public comment.
Find out below why this matters to you if you are developing medical device software (either Software as a Medical Device – SaMD – or Software in a Medical Device – SiMD) from our Director of Professional Services and Head of Quality and Regulatory Affairs, Daniel Mannion.
Note: I know we spell it “rigour level” in the UK, but it’s “Rigor level” in the standard, so we’ve spelt it that way here.
What is IEC 62304?
IEC 62304 is an international standard that provides a framework for the development and maintenance of medical device software. Compliance with IEC 62304 is often required by regulatory authorities around the world and often forms a critical part of the successful development of an ISO 13485-compliant quality management system.
The standard defines processes for risk management, configuration management, and problem resolution, ensuring that medical device software is safe and effective. It also classifies software into three safety classes (Class A, Class B and Class C) based on the potential harm that could result from a software failure, with each class having specific requirements for the development process and documentation.
Why does it matter to SaMD developers?
IEC 62304 is recognised by medical device regulators worldwide (including the UK MHRA, EU European Commission and US FDA), which means auditors and reviewers will be expecting you to follow its requirements when they come to review your product documentation.
Like all international standards, it also contains best practices in its topic area – if an international committee of experts has created a set of recommendations for how to develop medical device software and regulators have agreed with them, its sensible to follow their advice.
Proposed changes to IEC 62304
Change of Scope
This is the least impactful on SaMD/SiMD companies, but it explains many of the other changes. IEC 62304 is currently for Medical Device Software Development Life Cycle – however, this new version addresses all health software – not just medical devices any more.
This is in alignment with related standards like the IEC 82304 series, IEC 80001 series and IEC 81001 series of standards that apply to all health software. After all, while medical device software tends to be at higher risk than other health software, it’s fair to assume that the same principles apply to the development of all health software.
Risk Classification to Rigor Level
From the least impactful to most, this is the big one.
Aligning with FDA guidance on SaMD/SiMD development, this new version of IEC 62304 replaces the three “risk classifications” (Class A, Class B and Class C) with a two “rigor level” model.
Effectively, this moves all Class B software into Class C (and all the extra requirements that come with it). While this simplifies the decision process for rigor level, this will add a large number of requirements (and associated documentation) for software currently sat under Class B.
This new version of IEC 62304 has removed any reference to ISO 13485 and ISO 14971 for two technical reasons:
- The new scope of the standard includes all health software, not just SaMD and SiMD, and non-medical device health software is not obliged to follow ISO 13485 or ISO 14971, so they cannot be made a requirement of IEC 62304.
 
- IEC 62304 is a standard about how to design a product (in fact, it doesn’t even go as far as Design Validation), not how to meet general regulatory requirements, so there is no clear reason that it should specify compliance to other standards on other topics.
Does this mean SaMD and SiMD developers can stop following ISO 13485 and ISO 14971? Absolutely not!
ISO 13485 is critical to any medical device manufacturer’s ability to ensure the safety and effectiveness of their medical device through their processes and ISO 14971 is essential to proper risk management. Both standards are internationally recognised by regulators and will be expected by any regulator or auditor.
AI Health Software Development
With the explosion in AI health software over the past few years the IEC was bound to include further guidance on safe AI development in this new version of the standard.
Fortunately, there is only 1 AI-specific requirement (“AI Planning” – although it is 3 pages long and applicable to Rigor Levels I and II), but there is also plenty of guidance (7 pages, a full Annex) for AIaMD developers on how best to plan, assess and confirm their AI development.
Struggling with non-technical staff understanding what AI is?
Take Our Free Introduction to Ai Course.
Legacy Software
Whereas legacy software (i.e. software not developed under this version of IEC 62304 – including software developed under the current version of IEC 62304) was previously covered in section 4, it has now been moved to an Annex; however, there are few changes other than a brief explanation on how to handle software developed under previous versions of IEC 62304 and especially how to handle Risk Class B software that has now moved to Rigor Level II.
Specifically, Risk Class B software should have documentation updated to meet the Rigor Level II documentation either at the time of updates to the software or on a risk-based approach; don’t expect auditors to be lenient on this point though.
For future planning, it’s worth considering which rigor level your software will fall under in this new version of the standard – if Class A or Class C, you will have less to do, but if you’re Class B, you’ll need to plan some significant remediation to become compliant with this version of IEC 62304.
Maintenance vs Development
This new version of the standard makes clear the distinction between Software Maintenance and Development which was intended but not clear in the previous version.
“Development” includes the creation of new software as well as the introduction of new features or changes to existing software, whereas Maintenance “permits the [developer] to use a smaller process… to implement rapid changes in response to urgent problems”.
When will the changes to IEC 62304 come into effect?
This new draft is proposed to be released by August 2026; however:
- This is not the first attempt at updating this standard – the previous attempt faltered for several reasons but took significantly longer than the initial timeline to be rejected. However, this does mean that many issues were resolved in the previous attempt, which may accelerate the timeline for this attempt.
- Standards are not adopted by regulators on the day they are released. Generally, this takes 2-3 years from release, so you should have until around 2-3 years after the new version is published.
I would expect to have to be working to this new edition of the standard by around 2028-2029.
What can I do about this?
This version is open to public comment; while it’s unlikely the key changes will be affected by public comment, it’s possible to make adjustments and all feedback is appreciated. To give feedback in the UK*, you’ll need a BSI Standards Development account (https://standardsdevelopment.bsigroup.com/) from which you can read the text of the draft version and add comments on specific sections.
*Each country has their own standards agency with similar systems, you can find your country’s standards organisation at https://tbtcode.iso.org/list-of-standardizing-bodies.html
Get ahead of the requirements - especially if you are a Class B software, you can start working towards the existing Class C requirements now so you will be ahead of the game when this new version of IEC 62304 is released and comes into effect.
Reach out to us - we have a team of Medical Device Quality and Regulatory experts with extensive experience in SaMD, SiMD and AIaMD that can provide expert advice on how to meet these requirements in a way that is tailored to your business needs to prevent regulatory requirements from slowing down your release cycles.
We’re the experts that have your back.
Let us help you find a route from from where you are, to where you need to go. We’re here to help.
