Medical Device System Software Validation Documents

by 1 year ago
share this page via facebook share this page via LinkedIn share this page via Twitter share this page via Google+ share this page via email More sharing services

 

As I discussed in my last blog, software used as a platform to support the manufacture of product or in the product quality management system (QMS) must be validated (as required by 21 CFR §820.70(i)). The process is the same process used to develop design controls for a medical device without the requirement for compliance with ISO 62304 [white paper: Achieve Fast Compliance with IEC 62304]. Larger medical device firms usually assign this task to their IT department.

Documents typically used in establishing the Software Validation are as follows:

The Software Validation Plan
A document outlining the project milestones, deliverables and participant responsibilities.

System Work Instructions

Work instructions to be used in the software validation effort

The Software Requirements Specification (SRS)

This document describes the details of the user needs, system, and design requirements, physical hardware requirements, design architecture (including a network diagram), training, and integrations with other systems.

Part 11 compliance, safety, and risk analysis should also be part of building the inputs for V&V.

The image below describes the design element traceability required for this task.

Software Verification Protocol

Test protocol for verification of software requirements. Includes all verification test cases.

Software Validation Protocol

Test protocol for Validation of software user needs.  Includes all validation test cases.

Software V&V Trace Matrix

Includes the traceability from Inputs (User needs and software requirements) to test cases.  This progression should follow the FDA design guidance flow chart shown below.

 

Risk Analysis

Typically a user risk FMEA used to analyze potential of software failure to cause user harms.

Software V&V Report

Executed test scripts, and tester training records.

Regulators have a very specific understanding of the documentation related to software validation. Consider how these documents, which are really containers for your design inputs, traceability and evidence will be compiled and presented to product stakeholders.

Polarion is a great tool for creating requirements in the context of documents familiar to regulators. Let us show you how to author requirements in the context of your documents.

Comments are closed.