Important Aspects Of IEC 62304

Until expected amendments are made for Artificial Intelligence (AI) in MDSW, the current version of IEC 62304 is considered state-of-the-art. In fact, it covers a number of aspects which complement ISO 13485 for Quality Management Systems (QMS) for medical devices:

1. The software development process
2. A risk classification system 
3. Risk management throughout the product lifecycle 
4. Verification and validation activities
5. Configuration of software management and maintenance

In essence, an organization that develops medical devices with software components would need to comply with both ISO 13485 and IEC 62304. ISO 13485 sets the broader quality management framework for the entire organization, including the development of software, while IEC 62304 provides detailed guidance on the specific processes and activities related to the development, maintenance, and risk management of medical device software. For more information about ISO 13485, you may refer to an earlier blog.

1. Plan For The Development Process

IEC 62304 helps you define the lifecycle framework for the development of MDSW. This begins with a plan, from which you can build out a series of scheduled and documented phases, including design, development, verification, and validation. 

As part of these steps, acceptance criteria are defined – so you know when you’re ready to move on to the next phase based on pre-determined deliverables. This includes things like finalizing architecture and design, and having a testing plan ready and approved. Once the entire plan is executed, your dossier is ready for release to a Notified Body.

2. An Extra Layer Of Classification

The standard IEC 62304 has a different risk classification system to the MDR, adding an extra layer of risk protection for your MDSW. There are three classes: 

• Class A – it presents no harm
• Class B – there’s a minor chance of harm
• Class C – there’s a risk of death

Harm doesn’t have to be physical – it could be related to incorrect data that influences decision-making around diagnosis or treatment. As with the MDR, the risk class determines the type of documentation required. The higher the risk class, the more documentation that’s required. Whether standalone software or integrated within a device, the intended use of the software defines the potential risks and therefore the risk class of your software. 

In our experience, the golden rule is that no MDSW should be categorized as Class A. That’s because there’s always a chance of something going wrong. From potential data leaks to misinterpretation of the data, knowing the potential dangers is vital. For that reason, for our own software – and our clients – we always begin at Class B. There’s also room for discussion around the corresponding risk class under the MDR.

3. Manage Risk Throughout The Product Lifecycle

Risk assessment is an ongoing process, covering known and potential risks. The risks presented by software are very different to physical devices. For example, they can suffer from incompatibility with related software or the Operating Systems (OS) on which they run. 

It’s also imperative to minimize the risk associated with using software on specific servers or hardware. 

The normative standard ISO 14971 provides the overarching framework for managing risks associated with medical devices, while IEC 80002-1 focuses on how to apply this framework specifically to software in medical devices. This integration is crucial for ensuring the safety and effectiveness of medical devices that incorporate software components. For this reason, we recommend IEC 80002-1 for risk assessment guidance on software as a medical device, since it focuses on software-specific risks and issues. This enables you to do safety and security by design – avoiding issues such as the perpetual loading cycle known as ‘the infinite loop’ – that could impact patient care. It’s also good practice to define a ‘safety state’ that can warn users, so they can take mitigating action. Taking this approach to development sets you on the right path to a better software product. 

For more information about ISO 14971, you may refer to an earlier blog.

4. Verify And Validate Software 

When taking MDSW to market, verification and validation are arguably the most important stages to get right. After documenting the results, these processes typically surface hidden issues that need to be fixed before public release. It’s at this stage that the risks and requirements defined by your planning need to be verified to ensure the software meets them, and validated so the intended use and user needs are clearly met. 

Real-world testing can help you refine the user-friendliness and usability of your software when it’s in the hands of people less familiar with it – typically patients and physicians. Higher-risk devices typically require clinical studies to prove safety and performance, whilst lower-risk devices need an evaluation of relevant state-of-the-art literature. Unlike other forms of software that enter the market as a Minimal Viable Product and are then iterated on, MDSW for all intents and purposes goes to market as a complete product which is robustly tested. This reflects the need for safety but also usability – for example, making text and buttons larger for users with diminished eyesight.   

5. Software Configuration And Maintenance

Different healthcare settings may require different functionality or configurations of your software product, so it’s better aligned with their systems, practices, medical staff, and patients. For instance, your software may need to be adapted to connect with electronic patient records in one medical facility and not another. 

Small differences in software configuration can cause huge issues. Should something go wrong, you might not know why without proper configuration management. You could create multiple versions of the same software – which loosens your control over the software and could lead to compatibility issues – or build in the ability to switch certain functionalities on or off as needed. It’s worth noting that multiple software versions will also increase the workload in terms of documentation and testing. 

Documenting changes in the configuration is highly important. So too is recording which other software you use to build your MDSW product – typically Open Source software packages created by a third party and incorporated in your code, also called Software of Unknown Provenance (SOUP). The risks of using SOUP needs to be assed and frequent checks should be done to stay up-to-date with new releases of the applied software packages.  

IEC 62304 And The MDR

The MDR and IEC 62304 have a complementary relationship, and it’s clear that the IEC 62304 can add value to the process of getting your MDSW to the market and keeping it there.   

The software development practices outlined in IEC 62304 help ensure that the software components of medical devices meet the safety and performance requirements set out by the MDR. Generally speaking, the MDR tells you what’s needed for your software to be certified, and IEC 62304 gives you a framework for your entire software development lifecycle.

At Peercode Regulatory Consultancy, we provide expert guidance and support on standards and regulations for all kinds of medical device products including software. Talk to a specialist today