Software Verification and Validation for Medical Devices

Software Verification and Validation (Software V&V) is an integral part of software design that spans all the development stages as specified in IEC 62304 which addresses Software Development Life Cycle (SDLC) of medical software and software embedded within medical devices. Software Verification is to test if the software was designed as per requirements and Software Validation is to test is if the right product was built for the user.

The first step is to correctly classify the software depending of the level of concern, based on both FDA’s guidance (Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices) and MDR’s classification rule. The classification could differ from one software sub-system in the architecture to another, depending on the intended use of the software sub-system and their associated risks. This classification determines the documentation required to be submitted to the regulatory body.

The SDLC consists of software planning, requirement management, software architecture design, configuration management, software coding, software integration, software V&V, software requirements to risk mitigations to verification traceability, software release and software maintenance activities. Software V&V includes unit testing, software integration testing, software architecture validation, code based static analysis, requirement-based software system verification, software regression testing and software validation activities. Unlike CSV for hardware and process related activities, Computer Systems Validation (CSV) for software is interlinked with SDLC; the outputs of software tools and systems linked to verification are validated at every stage of SDLC.

IEC 62304 / IEC 82304 ComplianceSoftware-Validation new

According to IEC 62304, the basic assumption is that the medical device software is being developed and maintained within the risk management systems established by the manufacturer according to ISO 14971, with some minor software related additions. All the risks the software poses should be identified, analysed and mitigated, which includes data security, network security and cybersecurity, such that all patient safety risks are addressed to ensure proper device performance.

The risk assessment and the results including the reasons for the ranking as either: ‘critical’ or ‘not critical’ should be documented.

The selection of validation activities should be commensurate with the complexity of the software and the risk associated with use of the software for its specific intended use.

Software V&V has to be performed on standalone software applications and hardware-based devices that incorporate software including  

  • Firmware and Embedded software running on medical device hardware
  • Software as a Medical Device (SaMD) which is software intended to be used for medical purposes without being part of a hardware medical device.
  • Off the Shelf (OTS) software and Software of Unknown Pedigree (SOUP)

IZiel Approach –

IZiel’s approach for Software Validation is to identify gaps in the processes and documentation required as per IEC 62304, and assist medical device manufacturers to bridge these gaps. Software V&V is performed using a combination of on-site/off-site resources. Assistance is also provided to prepare other required deliverables of Software Development Life Cycle (SDLC) and surrounding processes such as software plan, software requirements, software architecture, software risk analysis file, software requirements to risk mitigations to verification traceability matrix, software release document and software maintenance plan.

  • Software Requirements are documented in collaboration with software developers, application specialists and other subject matter experts, using identified user needs and overall system requirements.
  • Software Architecture is prepared in collaboration with systems architect and software developers, using which architecture validation activities is performed.
  • Software Detailed Design (SDD) is prepared in collaboration with software developers and software architects, during which a strategy is developed on least-burdensome-approach to capturing SDD and gathering required data to document the same.
  • Traceability matrix is created using industry leading software, Cognition Cockpit, such that the required software requirements to risk mitigations to verification is covered in its entirety.
  • Unit Testing and Static Analysis is conducted on tools and infrastructure as per strategy set in collaboration with software developers.
  • Integration Testing and Regression Testing is conducted as per strategy set in collaboration with software developers, software architects and system engineers.
  • Software Verification is performed as per strategy set in collaboration with software developers, for which protocols are designed based on identified software requirements.
  • Software validation is performed as a part of systems validation activities which is determined by captured user needs in collaboration with application specialists.
  • Software Risk Management activities are conducted in collaboration with application specialists, software developers, software architects and other subject matter experts.
  • Computer Systems Validation (CSV) for tools used during SDLC is conducted as per strategy set by software developers.

IZiel has highly trained software engineers with multiple years of experience in software coding, software verification and software validation. The team consists of senior engineers who have worked in design and development of highly sophisticated implantable devices at industry leading companies, with direct expertise in software V&V. This team, with the support of IZiel’s regulatory and clinical experts, are decidedly equipped to handle complex software validation activities for medical device manufacturers. Integrating risk assessments into the validation lifecycle and documenting the basis for what was done also provides a level of assurance to management and regulatory authorities that the system was properly defined, designed, built, tested, operated, and maintained.