Skip to content
IEC 62304 is an international standard (a document drafted by a group of international experts) to describe best practice in the development and verification of medical device software – that is stand-alone Software as a Medical Device (SaMD) and software developed to be incorporated into Medical Devices (SiMD).
Who is IEC 62304 relevant for?
Need help complying with IEC 62304?
Who is IEC 62304 relevant for?
IEC 62304 is relevant for any company developing or testing medical device software (Software as a Medical Device or Software in a Medical Device). It is recognised or required by most international regulators, including the European Union, UK MHRA, US FDA, Health Canada, Japan PMDA, Australia TGA and Brazil ANVISA.
This is true regardless of the risk class of your medical device – it’s recommended and generally expected for even Class I medical devices.
A future version of IEC 62304 may be applicable to all healthtech software (not just medical devices), but this version has not yet been released.
What are the key principles of IEC 62304?
IEC 62304 provides detailed guidance on how to develop software, both for the initial development and future iterations. It includes requirements around requirements analysis, testing and release as well as for problem solving, risk management, configuration management and change management. It considers the whole lifecycle of the software and it takes a risk-based approach – the more risky your software, the more detailed processes and evidence needs to be.
Can you be certified to IEC 62304?
No – unlike standards such as ISO 13485, ISO 9001 and ISO 27001, you cannot be certified to IEC 62304; however, if you are developing medical device software and receive an inspection or a certification audit for ISO 13485, they will expect to see you following IEC 62304.
How does IEC 62304 relate to other standards?
IEC 62304 makes specific reference to the requirement to have a Quality Management System (referencing ISO 13485) and a Risk Management System (referencing ISO 14971).
IEC 82304 is also intended to work alongside IEC 62304 to address software requirements other than development and verification testing – such as establishing product requirements, software validation, labelling and documentation.
IEC 60601 for medical electrical equipment and IEC 61010 for laboratory equipment are also particularly relevant when making Software to be incorporated into a physical medical device.
What are BS EN 62304 and EN 62304?
When IEC standards are adopted by standards agencies in specific territories, the “IEC” is replaced by a different letter denoting the standards agency (BS for British Standard and EN for European Norm).
The contents of these documents are the same, but with some guidance related to the application of this standard to the regulations in that country (e.g. EN 62304 provides guidance on how IEC 62304 applies to the EU Medical Device Regulations).
Note: This mechanism has changed slightly, so a new version of IEC 62304 for the UK market would be BS EN IEC 62304 in future.
Is IEC 62304 changing?
IEC 62304 has been in an update and review process for quite a few years – we wrote a whole blog on the latest draft version, but the main proposed changes are:
- Expanding the scope to all health software
- Reduce from three safety classes to two rigor levels
- Specific section with guidance on AI development
The new version of IEC 62304 is not slated for publication until mid-2027.
What is SOUP?
- a software item that has been developed by someone else, is available “off-the-shelf”, and is incorporated into medical device software. Think about libraries and third-party tools you might use in your software
- a software item that was developed without keeping IEC 62304-compliant documentation.
What are the Safety Classes (Class A, Class B, Class C)?
IEC 62304 requires a specific type of risk analysis to be performed on the software – similar to that found in ISO 14971, but not exactly the same – to determine how much risk the software (or each portion of the software) presents to the patient/user. There’s a flow-chart in section 4.3 that shows whether your software would be Class A (lowest risk), Class B (medium risk) or Class C (highest risk).
Each requirement in IEC 62304 is marked with ABC, BC or C depending on whether that requirement applies to all software (ABC), just Class B and Class C (BC) or just Class C.
Are the Safety Classes mappable to the Regulatory Risk Classification?
While both the Safety Class and the Risk Class from relevant Medical Device Regulations are both attempting to present more stringent requirements to riskier medical devices, they don’t directly map to each other.
Software in a Medical Device (SiMD) may present significantly lower risk to the patient than the Medical Device itself, so you could in theory have Safety Class A software inside a Class III Medical Device.
Some people claim that Software as a Medical Device must be at least Safety Class B if it is a Class IIa Medical Device and Safety Class C if it is a Class IIb or III Medical Device, but the Regulatory rules and the IEC 62304 rules for classification do not align this cleanly – you should follow the process in section 4.3 of IEC 62304 to determine your Safety Class.
What is a Traceability Matrix?
A Traceability Matrix is a way of tracing requirements, risk controls and test requirements/results for a specific piece of software. Note that the term “Traceability Matrix” does not appear in the standard – the standard requires that you maintain traceability of these items, not that they appear in a particular format.
How do I handle Legacy Software?
Legacy software addresses software developed prior to the current version of the standard – this standard is nearly 20 years old now, so this has become quite a rare event.
Regardless, a risk assessment must be made about any missing evidence from the development of the software, a decision made about remediation and a justification given for any remediation work not carried out. This is addressed in section 4.4.
How does IEC 62304 handle AI Software?
IEC 62304 is over 20 years old – it doesn’t specifically address Artificial Intelligence in the standard, which is a key weakness and one of the main reasons that an update is important.
The draft version 2 of IEC 62304 does contain some useful guidance on AI; although it is not approved and published, it can still be a useful reference point for adapting IEC 62304 to software containing AI functions.
What about Agile Development?
While IEC 62304 is presented in a “Waterfall”-looking way, it does not specify the order of steps or project management approach that must be followed – it is absolutely adaptable to work in an Agile environment.
One of the key conflict points between Agile and IEC 62304 and Medical Device Regulations in general is that for Medical Device Software, the documentation (external facing and internal record keeping) must be kept up-to-date – the Agile Manifesto would need to be “Working Software with Comprehensive Documentation”.
Need help building controls to satisfy IEC 62304?
Whether you’re a startup building your first Medical Device or a global Enterprise building your first software based based, we’re here to help.
