Understanding IEC 62304 requirements for medical device software

What is IEC 62304 compliance?

IEC 62304 is an international standard that defines the lifecycle requirements to develop Software as a Medical Device (SaMD) such that once deployed it is safe, effective, and cybersecure . 

The standard addresses 14 processes to be implemented through the software development lifecycle (SDLC). This includes:

β€’ Software development planning 

β€’ Software requirements analysis

β€’ Software architectural design 

β€’ Software implementation and verification 

β€’ Software integration and integration testing 

β€’ Software system testing and verification

β€’ Risk management 

β€’ Configuration management

β€’ Problem resolution

Most importantly, these processes must not be conducted in a silo away from the clinical aspects of the product.  Hence the SDLC should run in parallel with a CDLC or clinical development lifecycle (see flowchart below).

Why is IEC 62304 standard a requirement for SaMD?

IEC 62304 (technically, EN 62304 in the EU and BS EN 62034 in Great Britain) is a harmonized standard (EU + Northern Ireland) or designated standard (GB), that is a standard that establishes technical and/or process specifications which are considered suitable or sufficient in order to comply with the technical requirements given in the respective legislation.  The role of IEC 62304 conformity is to help to assure continual patient and user safety, effectiveness and cybersecurity by driving adoption of appropriate software engineering practices in SaMD development. 

It also requires a risk management process to be applied throughout the SDLC, to ensure that these fundamentals of safety, effectiveness and cybersecurity are upheld as solutions evolve and technology changes. Software often needs to be changed or updated with new features, or to fix bugs and software failure, so it is essential to have a framework for dealing with problems and applying appropriate risk control measures.

ISO 13485 is another important standard for medical device software development that goes hand-in-hand with IEC 62304. The medical device regulations associated with ISO 13485 provide a framework for the safe design, risk analysis, version control and maintenance of SaMD. It specifies requirements for a quality management system and expects organisations involved in the development and maintenance of medical device software to demonstrate an ability to consistently meet customer and regulatory requirements.

Something that IEC 62304 does not have but ISO 13485 requires is a process for validation.  The UK regulation requires β€œFor devices which incorporate software or which are medical software in themselves, the software must be validated according to the state of the art taking into account the principles of the development lifecycle, risk management, validation and verification.”  This is where an additional standard comes into play - IEC 82304-1 - which contains the framework for how to plan, conduct and report validation.  It’s important to understand the distinction between verification and validation, the terms both being defined in IEC 82304-1:

  • Verification is the confirmation through the provision of objective evidence that specific requirements have been fulfilled - that is, the software itself works with respect to the technical requirements given for it

  • Validation is the confirmation through the provision of objective evidence that the requirements for a specific intended use have been fulfilled - that is, is the software safe, effective and cybersecure when used by real-world users such as clinicians and patients in a real-world environment?

Four software testing requirements

Before a SaMD is cleared for use, testing is required to establish whether the solution works in the manner intended and is safe to use. 

  1. Unit Testing: Specific software components are assessed to determine if each unit is working and operational. In this case, a unit is defined as an architectural building block, like code. Software developers typically perform unit testing themselves using a white box testing method, which verifies the input-output flow in a software's internal structure and allows issues to be resolved as quickly as possible every time the code is changed. 

  2. Integration Testing: Several internal teams collaborate to test all their contributions to the overall SaMD, via either black or white box testing, within a programme to ensure the overall system works, and to identify issues between modules and functions.

  3. System Testing: The entire system is white box tested to see how it functions and whether it meets the end user's technical, functional and business requirements.

  4. Validation Testing: The final testing stage assesses whether a system is ready for release with representative end users interacting to validate whether the product meets their requirements and can be used safely, effectively and securely.

Confused? Don't worry - we can help!

IEC 62304 is one of many hurdles that we can help you to overcome, as are IEC 82304-1 and ISO 13485. Medical regulation often feels complex and hard to decode, especially when you're trying to work out which standards your solution needs to conform to. That's why we specialise in debunking the jargon to make sure that everyone we work with is equipped with the understanding they need to get their solutions through every step of regulation and beyond.

By partnering with your development team we will understand their current practices and identify potential gaps, rather than proposing something hypothetical and alien. Together we'll work through the process to address those gaps to make sure you achieve the regulatory compliance you need to get to market, fit into clinical workflows, improve standards of care and increase cost efficiency savings for health systems and services.

Think you need help with IEC 62304? Healthtech doesn’t have to be confusing. Get in touch!

Hardian Health is a clinical digital consultancy focused on leveraging technology into healthcare markets through clinical strategy, scientific validation, regulation, health economics and intellectual property.

Mike Pogose

By Mike Pogose, Director of Quality Assurance & Regulatory Affairs

Previous
Previous

5 questions you need to answer to get your digital health or AI software product to US market quicker

Next
Next

Will Apple & Google tame the health app wild west??