Validation—11.10 (a)
- Last UpdatedJan 26, 2021
- 2 minute read
"(a) Validation of systems to ensure accuracy, reliability, consistent intended performance, and the ability to discern invalid or altered records."
Software Verification
FDA-audited industries are required to properly validate their applications. The software world uses the term validation and verification interchangeably. However, according to the document "General Principals of Software Validation; Final Guidance for Industry and FDA Staff", we provide software that is verified. The partial definition of software verification in the FDA document is:
Software verification provides objective evidence that the design outputs of a particular phase of the software development life cycle meet all of the specified requirements for that phase. Software verification looks for consistency, completeness, and correctness of the software and its supporting documentation, as it is being developed.[…]
All our products are verified and tested extensively prior to release. Furthermore, our commitment to quality ensures performance reliability.
Software validation is for a finished device or system hence it does not apply to off-the-shelf configurable software. Validation applies to systems created using the configurable software products.
System Validation
Validation of the applications created using the AVEVA products is entirely the responsibility of the FDA-audited industry. Creating and maintaining a validated state is simplified by features and capabilities within the AVEVA products.
For example, InTouch HMI and AVEVA OMI include standard user entry windows for both alphanumeric and numeric entries. These standard windows provide entry capabilities as part of the off-the-shelf products so the features do not need validation. It is only necessary to consider validating the connections to these windows to prove entered values end up in the right place within the system.
For example, graphic object templates can be used to create templates for user interface objects like control valves or process variable displays. The features of each template are defined once and then the template can be reused each time an object with the defined features is needed. Use of the template simplifies validation by reducing the scope of testing for this custom-configured item. All features of the object template should be tested fully once but each instance of the template does not require full testing of all the template features because each individual instance shares the features of the template. Validation of each instance of a template can focus on the custom configuration of the specific instance, for example, linking of the object to a specific system input or output.
Decisions to reduce testing scope are completely within the boundaries of currently accepted industry methodology. GAMP 5 specifically promotes the use of a risk-based approach to validation, including testing. Capabilities within the AVEVA products like those mentioned above provide a strong case of reduced testing when properly employed within a custom-configured system.