Skip to main content
If you are wondering whether the validation you are working on has covered the appropriate functionality, consider one of the primary criteria cited by the FDA for validating is the intended use of the software which is used as part of the production and/or quality system .
Over the last ten years, numerous FDA Form 483 reports were issued documenting software was not adequately validated for its intended use according to an established protocol. The ‘FDA’s General Principles of Software Validation – Final Guidance for Industry and FDA Staff’ states, “Any software used to automate any part of the device production process or any part of the quality system must be validated for its intended use, as required by 21 CFR §820.70(i).
The April 2016 FDA Draft Guidance, ‘Data Integrity and Compliance with CGMP Guidance for Industry’ further clarifies “Yes, a workflow, such as creation of an electronic master production and control record, is an intended use of a computer system to be checked through validation (see 160 §§ 211.63, 211.68(b), and 211.110(a)). In fact, the term “intended use” is used thirty-two times throughout this document.
What does this mean for you? According to the guidance, intended use is to be a consideration in system design, software purchases, developers’ activities, user group permissions, error handling, determination of verification and validation testing, life-cycle management, and risk management activities. Intended use of software does not always mean every function the software is capable of performing. Organizations need to determine which functions they intend on and rely on using. The testing involved with the validation then needs to focus on that intended use.
Since this is the primary criteria against which the FDA measures the validity of a software system the following should be considered:
- The systems’ intended use must be well documented and continuously referred to from conception to retirement.
- The validation plan must account for the delivery of the intended use testing .
- The system requirements document is the primary source of this information and should clearly state the intended use of the system.
- Requirements should be developed from the perspective of the business, manufacturing process, or device that will interface the functions served by the software system.
- Soliciting input from the business stakeholders for input and review of requirements document.
- Requirements should be derived from approved operating procedures, work instructions, product specifications, or other pertinent quality system documents that define and govern the functions that the software will serve.
A well-written requirements document will pave the path forward for a successful validation. Interpreting FDA guidelines can pose interpretive challenges, but clearly defining your organization’s intentions for the software and then adequately showing that functionality is tested will lead to a complete and defendable validation package. The “Intended Use” of the system should be understood by all involved with the validation, and seeing the appropriate documentation should ensure compliance with the appropriate regulations. The team at Performance Validation offers years of experience and expertise in developing solid requirements documentation that meets with FDA expectations.
