Intended Use

Among the observations cited in FDA Form 483 reports over the last ten years there are numerous documented findings were where software used as part of the production and/or quality system 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))”.

The term “intended use” is used thirty-two times throughout this document.  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.  Clearly, it is tthe primary criteria against which the FDA measures the validity of a software system, which means that its intended use must be well documented and continuously referred to from conception to retirement.

So, how is intended use determined and documented for validation purposes?

The system requirements document is the primary source of this information and should clearly state the intended use of the systems. Documented requirements should be developed from the perspective of the business, manufacturing process, or device that will interface the functions served by the software system.

It is always critical that the business stakeholders should be solicited for input and review of requirements document.  Where established business processes, manufacturing systems, or product designs requiring automation are in already place, requirements can 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.  Where such documentation is not available, it is recommended that the validation plan account for their deliver as a part of the validation effort. A well written requirements document will pave the path forward for a successful validation.

Have a question on how to determine the intended use of your software? Contact Kevin Marcial at Performance Validation.  Our CSV professionals can assist you in determining the intended use and can help you develop a cost-effective, compliant validation approach that will deliver your project with integrity and excellence while never losing sight of your goals, scope, and priorities.