Overview

An important aspect of bringing Commercial-Off-The-Shelf (COTS) software into a US Food and Drug Administration (FDA) regulated environment is the execution of Intended Use, or Fit for Purpose, Validation (IUV).

The information in this guide is not to be considered official FDA or EMEA regulation or guidance. Rather, it is an aggregation of consolidated best practices gathered from field experience. It is incumbent upon to the individual development team(s) to take this information and modify it according to their own specific regulatory needs.

What is IUV?

A software tool is considered ‘regulated non-medical device’ or ‘quality effect’ software. These are terms given to COTS software that is used by stakeholders, engineers, testers and management to assist them in the design and development of medical devices. It is NOT software that goes into the medical device. IUV occurs only against functionality that will be used as defined by the client’s process. IUV is not exhaustive testing of a COTS product nor is it a ‘bug bash’.

Why do IUV?

The FDA is primarily looking for two things:

1. Evidence of a Quality Management System (QMS) that defines the IUV process.
2. Evidence that the process is followed in the form of auditable documents and reports.

Listed are some of the commonly applicable regulations:

• FDA Guidance 21 CFR part 820.30 – Design Controls
• FDA Guidance 21 CFR part 820.70i – “Production and Process Controls: Automated Processes”
• ISO 13485 “Medical Devices – Quality Management Systems: Requirements for regulatory purposes”
• ISO 9001, Quality Management Systems – Requirements
• ISO 14971 “Medical Devices – Application of Risk Management to Medical Devices”
• Potentially 21 CFR part 11 – Electronic Records Management, if DOORS will be used as the official record for parts of the Design History File (DHF).

When to do IUV?

An IUV is typically performed at a point in time when any of the following conditions occur:

• When a new tool is first introduced into an organization’s development environment.
• When a new version of a tool is adopted by an existing user. A full version increase, such as 8.x -> 9.x may mandate a full (re)validation. A point release such as 9.1 -> 9.4 may only necessitate an incremental validation.
• The user’s Quality System Process changes to include functionality not previously IUVd. For example, past processes allowed only for printing documents for ‘wet’ signature approval, while new processes allow for electronic baseline and e-signature.