This post was recently updated on September 19, 2018

Companies who are are new to computer system validation often ask us whether software validation is required for their specific software or systems. And they often assume that they must validate their entire system. While that assumption makes perfect sense, it is not always correct. More on that in a bit. But first, we must understand what types of systems require validation.

Four types of software that require validation

You may think that all software requires validation, but the FDA defines four distinct types of software or systems.

1. Medical Device Software

Medical Device software is defined as any software that is used as a component, part, or accessory of a medical device, and software that is itself a medical device.

Examples of medical devices that contain software requiring validation include products used in:

• Diagnosis of disease (i.e., medical imaging software, arrhythmia detection software)
• Cure, mitigation, treatment, or treatment of disease (i.e., laser software, hospital bed software)
• Prevention of disease
• Products that affect the structure or function of the body (i.e., pacemaker software)
• Software for blood and donor management

2. Production Software

Production software is software and systems used in the production of FDA regulated products.

This category includes:

• Software that controls manufacturing equipment (i.e., PLCs, CNCs, inspection software)
• Software that manages the manufacturing process (i.e., factor automation, production monitoring, bill of materials)
• Laboratory testing software
• Labeling software
• Software that manages the manufacturing environment (i.e., building management systems)
• Software that automates key manufacturing calculations

These examples are not all-inclusive; however, FDA Warning Letters for validation issues include citations from these categories.

3. Quality Management Software

Quality Management software and systems are those used in programs intended to ensure quality products.

The FDA has issued Warning Letter citations for all of the examples below:

• Product returns or recall management software
• Complaints software
• Change control software
• Preventative maintenance software
• Inventory control software (i.e., ERPs)
• Document Management software
• Deviation Tracking software
• CAPA software

4. Software for FDA-Regulated Records

Software for FDA-regulated records is defined as software used to create, modify, maintain, archive, retrieve, or transmit FDA-required records. And electronic records submitted, per the FDA.

FDA-regulated records software examples include:

• IRB records software
• Adverse Event reporting software
• Organ/Tissue Donor records
• Call Center records software
• Validation records
• Prescription Order Fulfillment software
• Clinical Trial Records software

For more examples of each software type, attend our free 60-minute Computer System Validation Basics webinar.

Do I need to validate my Off-The-Shelf, Configured Applications, SaaS, or Cloud Systems?

Many companies today are buying the computer systems used in their regulated activities. But using a software vendor doesn’t mean that you are off the hook for performing validation. The FDA holds the regulated company, not the software vendor, responsible for validating their off-the-shelf software, configured applications, software-as-a-service (SaaS) applications, and cloud systems as if they had built the software internally. Below are 5 expectations from regulators for companies that use purchased systems.

1. Only validate the functionality you will use

You can limit the validation scope to the features that used by the regulated company. Let’s say you purchase a system with document management functionality, but don’t use it. According to the FDA, there is no need to validate the document management features.

For example:

A device manufacturer who chooses not to use all the vendor-supplied capabilities of the software only needs to validate those functions that will be used and for which the device manufacturer is dependent upon the software results as part of production or the quality system. – FDA, General Principles of Software Validation

You need to clearly document the intended use in your User Requirements, however, you don’t need requirements or tests for unused features. It’s best to configure the system to turn off the unused features, or to ensure a way that users don’t start using those features.

2. You must validate how you will be using the software

Validation must be specific to the regulated company’s planned and documented use of the application. Take Microsoft Excel, for example. You don’t validate Excel itself, you validate the spreadsheets that you build with Excel.

The acceptance of vendor-supplied validation data in isolation of system configuration and intended use is not acceptable. In isolation from the intended process or end user IT infrastructure, vendor testing is likely to be limited to functional verification only, and may not fulfill the requirements for performance qualification. – MHRA, GMP Data Integrity Definitions and Guidance

You need to clearly document the software’s intended use in the User Requirements. Write the Requirements and Tests for how your company will use the system. The software vendors can confirm standard functionality (OQ), but don’t know how your company will use the software (PQ).

3. You can use vendor supplied documentation in your validation

Vendor documentation is a good starting point for validation. For example, with a training management system, the vendor provides the Functional Specifications and OQ tests for standard functionality, but the regulated company must use their own User Requirements and PQ testing.

If the vendor can provide information about their system requirements, software requirements, validation process, and the results of their validation, the medical device manufacturer can use that information as a beginning point for their required validation documentation. – FDA, General Principles of Software Validation

This requirement is not limited to FDA Guidance. Here is an example from the EU:

Documentation supplied with commercial off-the-shelf products should be reviewed by regulated users to check that user requirements are fulfilled. – Eudralex Annex 11, Computerised Systems

Vendors often provide or sell Functional Specifications and OQ Tests, however the regulated company still needs to have a User Requirements Specification and perform PQ testing. The regulated company also needs to supplement vendor FS/OQ for any configured features. If you use vendor-supplied documentation, always document your acceptance/approval of this documentation.

4. You need to audit vendors of critical systems and IT services

The regulated company needs to audit the vendors of critical applications and services, depending on risk.

The audit should demonstrate that the vendor’s procedures for and results of the verification and validation activities performed for the OTS software are appropriate and sufficient for the safety and effectiveness requirements … – FDA, General Principles of Software Validation

Another example from Europe:

The competence and reliability of a supplier are key factors when selecting a product or service provider.  The need for an audit should be based on a risk assessment. – Eudralex Annex 11, Computerised Systems

This applies to purchased software, SaaS situations, systems run on the cloud, etc. You need to define what applications are “critical” – this is company specific, but usually defined as systems or services with direct impact to patients or products for patients. Additionally, audit results need to be available for inspection.

5. You must document responsibilities using formal agreements

Regulators make no exceptions for companies who use third party services. The regulated company is responsible regardless of whether IT services are provided in-house or by a third party.

So, if a regulated company outsources services to a third party, they must ensure the third party works at the same standard expected of an internal IT group. And, they will need to prove this in an inspection. This is the same expectation we see from regulators for outsourcing of other critical activities such as parts suppliers, third party manufacturers, clinical investigators, outsourced adverse events processors, etc.

When third parties (e.g. suppliers, service providers) are used e.g. to provide, install, configure, integrate, validate, maintain (e.g. via remote access), modify or retain a computerised system or related service or for data processing, formal agreements must exist between the manufacturer and any third parties, and these agreements should include clear statements of the responsibilities of the third party. – Eudralex Annex 11, Computerised Systems

This applies to purchased software, SaaS situations, cloud systems, etc. The scope of IT services includes providing the system, system installation, integration, maintenance, retention. Additionally, the regulated company needs to document responsibilities between parties in contracts and agreements, including back-ups, troubleshooting problems, bug fixes, etc.

Reduce the amount of work for your next validation project

Now that you know the types of software that require validation, you can identify whether your software needs to be validated. Additionally, you can apply the regulatory expectations for software validation to reduce the amount of work on your next validation project.

  Read More Posts About: Computer System Validation, Guidance & Regulations