Validating Your ERP: What is Recommended For Med Device Manufacturers?

Medical Device Manufacturers know... All processes associated with designing, manufacturing, packaging, labeling, storing, installing, or servicing a finished device intended for human use must be validated.

The FDA defines process validation as:
”the collection and evaluation of data, from the process design stage through commercial production, which establishes scientific evidence that a process is capable of consistently delivering quality product.”

The FDA also mandates that software used for the design, manufacture, packaging, labelling, storage, installation, and servicing of all finished devices intended for human use shall be validated.

Validation starts with 21 CFR 820.75

"(a) Where the results of a process cannot be fully verified by subsequent inspection and test, the process shall be validated with a high degree of assurance and approved according to established procedures. The validation activities and results, including the date and signature of the individual(s) approving the validation and where appropriate the major equipment validated, shall be documented.

(b) Each manufacturer shall establish and maintain procedures for monitoring and control of process parameters for validated processes to ensure that the specified requirements continue to be met.

(1) Each manufacturer shall ensure that validated processes are performed by qualified individual(s).

(2) For validated processes, the monitoring and control methods and data, the date performed, and, where appropriate, the individual(s) performing the process or the major equipment used shall be documented.

(c) When changes or process deviations occur, the manufacturer shall review and evaluate the process and perform revalidation where appropriate. These activities shall be documented."

https://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=820.75

Validation continues with the Global Harmonization Task Force (GHTF) Guidance: Quality Management System Medical Devices – Process Validation Guidance, SG3; 2004. This document is non-binding guidance to regulatory authorities for use in the regulation of medical devices. In fact, the GHTF is often consulted by those who create the regulations that govern the industry.

See: http://www.imdrf.org/docs/ghtf/final/sg3/technical-docs/ghtf-sg3-n99-10-2004-qms-process-guidance-04010.pdf.

So now that you know what is to be validated and the regulation and guidance that determines validation, in plain speaking terms, what is wise (recommended) and necessary (required) for validation? 

First, it is wise to have a Master Validation Plan. The purpose of a Master Validation Plan is to outline what needs to be done to successfully obtain process validation.

It is important to remember that although a Master Validation Plans is not a specific Code of Federal Regulations (CFR) section 820 requirement, it is recommended as per GHTF Guidance.

The plan should:

• Define the product and process flow.
• Identify what needs to be validated.
• Consider protocols and specifications.
• Be documented and approved

GHTF guidance also strongly recommends that you have:

• Installation Qualification (IQ);
• Operational Qualification (OQ); and
• Performance Qualification (PQ).

Let’s take a closer look at what constitutes Installation, Operational & Performance Qualification (IQ, QQ, and PQ). 

Simply put, Installation Qualification (IQ) asks the question: “Is everything installed correctly?” In answering this question, you should consider the following:

• Equipment design features.
• Installation and Environmental Conditions.
• Safety features.
• Supplier documents, Calibration, preventative maintenance and spare parts.

Operational Qualification (OQ) challenges the process parameters to assure that the process will result in a product that meets requirements. The factors to consider are:

• Determination of the process control limits.
• Material specifications and handling.
• Process change control and training.
• Determination of potential failure modes, action levels and worst case scenario.
• Perform verification and software validation (V&V) for intended use.
• Verification is the process of evaluating products in a development phase to find out whether they meet the specified requirements.
• Software Validation is the process of evaluating software at the end of the development process to determine whether software meets the customer expectations and requirements.

Finally, you need to consider Performance Qualification (PQ). You must demonstrate that the process will consistently produce an acceptable product under normal operating conditions. Things to consider:

• Approved procedures and limits from OQ.
• Acceptable product.
• Simulate actual manufacturing conditions.
• Is the process repeatable and stable long term?

What documentation is required for regulatory validation?

After you qualify the installation, operation and performance that GHTF strongly suggests, you next have to ensure that you have the following required documentation:

1. Software Validation Protocol (Validation Plan):
   This document outlines the project deliverables and responsibilities.
   
   
2. System/Software Requirements Specification:
   This document details system requirements. However, this is more than just a list of functional requirements. This document should also capture a good description of the various components that make up the system so that there is a clear understanding of what this system involves.
   
   The requirements specification also needs to include information around physical hardware requirements, physical software requirements, client user requirements, training requirements, and detail about any customizations or integration with other systems.
   
   
3. Network Diagram:
   This required document provides a visual layout of how the system is configured on the network. It serves to demonstrate that you understand how your system is configured for your implementation. (Note: this diagram may be included as an attachment to the Software Requirements Specification.)
   
   
4. Risk Analysis:
   This document evaluates application safety and identifies potential hazards, the causes and the effect each hazard has on the application safety and use.
   
   Insofar as this is a business system, the risk assessment should focus on the business processes being managed by the system versus a more traditional FMEA risk assessment for software programs which are part of a device and pose direct patient risk. Not all risks will be solely mitigated by the software, some risks are mitigated procedurally.
   
   
5. 21 CFR Part 11 Compliance Analysis:
   This document evaluates system applicability/requirements for the use of electronic signature as required by the FDA in 21 CFR, Part 11.
   
   
6. Design Specification:
   Typically a design specification is not required for a purchased configurable business quality system. If major integration or customization is to be performed as part of the project, then this document may be added as deemed appropriate by the project team and quality reviewer.
   
   
7. Verification Protocol (Test Plan):
   This document defines the type of testing to be completed along with the procedures and schedules for those tests.
8. Test Specifications (Test Cases):
   This document contains the system level test cases that are based on the functional requirements set forth in the Requirements Specification. If these are separate or maintained as an attachment to the Verification Protocol, then it makes it easier to add modules or new phases to the validation package while limiting revision time.
   
   
9. Requirements Traceability Matrix:
   This matrix details all system requirements, including Requirements ID, and links them to the Test Case IDs. This is a required document that can be helpful going forward when a change occurs, as it makes it easier to assess and identify where there is impact.
   
   
10. Final Validation Report:
    The validation report should provide a summary of all documentation associated with the validation of the software and test case results. This report should include both a summary of all the validation activities and define how the system will be managed in production.
    
    Information such as what work instructions are used to train users to use the system, what system support is available, how the system will be backed up, and how change control will be managed are extremely important elements captured in this document.

Are there any occasions when a re-validation is necessary?

If there have been changes or process deviations, then re-validation is necessary.

As stated in 21 CFR 820.75(c):

When changes or process deviations occur, the manufacturer shall review and evaluate the process and perform revalidation where appropriate. These activities shall be documented.

Some examples of reasons for revalidation are as follows:

• Change(s) in the actual process.
• Negative trend(s) in quality indicators.
• Change in product design that affects process.
• Transfer of process to another facility.
• Change of the application of the process.

Summary

In highly regulated industries, such as in the medical device field, best practices practically demand having a program such as Oracle’s NetSuite. The sheer quantity of validation regulations (which differ in each country!) virtually scream out for the solutions that NetSuite offers.

To best see how NetSuite can successfully overcome these challenges and open up profitable opportunities for your enterprise, contact Business Solution Partners - your NetSuite Certified Partner Solution Provider.