IEC 62304:2006 is an internationally recognised medical device standard which provides a framework for the development, testing and maintenance of software used as or within medical devices. It is a fundamental standard, especially considering the development of the new software-based technologies in the medical device world.
This standard is quite complex, so different posts will be published taking in consideration different aspects of this ISO regulation. In this post, the following topics will be discussed:
- Software Safety Classification
- How to apply the software safety classification
- Software Development Plan
- Software Architecture
Software Development Lifecycle according to IEC 62304
Different levels of requirements and verification/validation activities.
Software Safety Classification
Three different classes of software are envisioned within the IEC 62304:2006 – AMD-1:2015. The safety classification is based on associated risk.
Safety class A: the software system cannot contribute to a hazardous situation; or the software system can contribute to a hazardous situation which does not result in unacceptable risk after implementation of risk control measures external to the software system.
Safety class B: the software system can contribute to a hazardous situation which results in unacceptable RISK after consideration of risk control measures external to the software system and the resulting possible harm is non-serious injury.
Safety class C: the software system can contribute to a hazardous situation which results in unacceptable risk after consideration of risk control measures external to the software system and the resulting possible harm is death or serious injury.
How to apply the software safety classification?
There can be different approaches to determine the class of risk of a software according to IEC 62304. One possibility is the following:
- Take the list all the SRS (software requirement specifications)
- For each of them evaluate, from risk point of view, what could bring the failure of these requirements; based on the output, classify each requirement with A, B or C, based on the explanation provided in the previous section.
- The class of risk of the software is the highness class of risk of any software requirements evaluated.
Software Development Plan for the IEC 62304
The IEC 62304 – Medical Device Software requires the documentation of a software development plan. This provides a framework for the conduction of the activities related to the SW development lifecycle. The plan shall address the following:
- process in the development of the software
- the deliverables of the activities
- Traceability between Software requirements – software systems – and risk control measures.
- Software configuration and change management, including management of SOUP
- Software problem resolution for management of software related issue.
It is very important that the software development plan is updated during the design process or, alternatively, a specific justification is documented why update is not needed.
Software Development and Validation Package
4EasyReg has made available a toolkit focused on the documentation related to Software Development and Validation according to IEC 62304. We have been discussing in different occasion in the blog the documentation linked to IEC 62304, such as Software Development Plan and Software Architecture. We have however decide to collect the main documentation needed for activities related to Software Development and made it available in our 4EasyReg DocShop.
This toolkit – it can be downloaded at this link – contains different fully editable templates that can be used to document medical device related software development and validation activities.
The toolkit contains the following documentation:
- Software Development Plan Template
- Software Architecture Template
- Software Release Record Template
- Software Verification Protocol Template
- Software Verification Protocol Template
Do not hesitate to download it the toolkit!
Software Architectural Design according to IEC 62304
The software architecture shall be defined, including all the different software items and their interconnections. In case the software items are formed by Software of Unknown Provenance (SOUP), functional and performance requirements of SOUP need to be identified.
Activities of verification for software architecture shall be documented, and the following need to be verified:
- the architecture of the software implements systems and software requirements including those relating to risk control;
- The architecture is able to support interactions within software items and between software items and hardware.
- the architecture support
Subscribe to 4EasyReg Newsletter
4EasyReg is an online platform dedicated to Quality & Regulatory matters within the medical device industry. Have a look to all the services that we provide: we are very transparent in the pricing associated to these consulting services.
Within our WebShop, a wide range of procedures, templates, checklists are available, all of them focused on regulatory topics for medical device compliance to applicable regulations. Within the webshop, a dedicated section related to cybersecurity and compliance to ISO 27001 for medical device organizations is also present.
As one of the leading online platforms in the medical device sector, 4EasyReg offers extensive support for regulatory compliance. Our services cover a wide range of topics, from EU MDR & IVDR to ISO 13485, encompassing risk management, biocompatibility, usability, software verification and validation, and assistance in preparing technical documentation for MDR compliance.
Do not hesitate to subscribe to our Newsletter!
