Validation of Off-the-Shelf Software

"Previously published on, Copyright: Innovative Publishing Company, LLC. Reprinted with permission"

While there is extensive guidance and documentation available for the development and validation of proprietary software, there is relatively little guidance available for the validation of commercial off-the-shelf software (OTS). The FDA's guidance document for software development, while somewhat dated (2002), provides some general guidance (including reference to general principles of software development) and references to additional guidance documents for software used in production and processes.

Unfortunately there is no single defined set of user requirements for medical devices, tissues or any other product. The good news is that there are some well-documented requirements in the form of the FDA 21 CFR regulations.

For the medical device manufacturer or for a tissue bank, finding and applying this information is a daunting task which leaves most users frustrated—so frustrated in fact that they may not even begin the validation process in the first place! The purpose of this article is to provide device and tissue manufacturers with guidance and a useable structure that will help to simplify the process of OTS software validation in order to satisfy FDA regulations and user requirements.

The First Step

The first step, as with most software or hardware purchases is to properly define a set of user requirements. Without user requirements, it is unlikely that proper software will be purchased—let alone validated. Unfortunately there is no single defined set of user requirements for devices, tissues or any other product. The good news is that there are some well-documented requirements in the form of the FDA 21 CFR regulations.

For example, user requirements for a document control system must include the basic requirements of 21 CFR Part 820 Section 820.40, Document Controls. This section has two main requirements, a) document approval and distribution and b) document changes. These two sections must be significantly expanded to include all the user requirements of the FDA that are related to document control; this is an excellent starting point for manufacturers. Similarly, if we were going to validate a Quality System Record management system, a good starting point would be Section 820.186, Quality System Record.

Obviously, the regulations would just be the starting point. The user would certainly have many unique requirements which would also fall into the User Requirements section. These might include old and new versions of software documentation, such as Microsoft® Word or Excel. Most users also have existing documents, files or databases which must be converted to the new software system with complete accuracy and no loss or corruption of data.

Rest of the Validation

Once the User Requirements are defined, the Validation process for OTS should not be much different than the validation of a piece of equipment in a regulated process. Consider the following general steps:

  • The Validation Plan - Don't leave home without it! This is the first step in any validation process and it must be complete and approved prior to beginning validation activities. The plan will identify all the major elements of the validation endeavor, including acceptance criteria and approval requirements. The plan will generally show the step-by-step process which will be followed during the entire validation.
  • Risk Management Plan - Most validations are based on risk. Identify the high risk issues or requirements and make sure they are covered in the validation.
  • User Requirements - As discussed above
  • Functional requirements - These are software system requirements to support the User Requirements. For example, if we need to know who made a particular change as part of our User Requirements, the audit trail would be the Functional Requirement that would make that possible.
  • Software Requirements Specifications - Software Requirements Specifications may be more complicated (from an IT standpoint) than many manufacturers would care to deal with but may have a valuable place in the validation plan if IT personnel are willing to conduct systematic back-ups, etc.
  • Test Script - This is the documentation of the actual hands-on test that is performed (by several people) multiple times to ensure that the system is working properly or to identify any 'bugs' which would require the software supplier's corrections/alterations before the system can be declared "acceptable."

  • URS/FRS/Test Script, Trace Matrix - This is a critical tool to link the User Requirements through the development process and to the Test Scripts and may result in the final acceptance or rejection of the software. In the Trace Matrix, all User Requirements are numbered (preferably as numbers taken from a product specification). The Functional Requirements are numbered for traceability back to the User Requirements and forwarded to the Test Scripts. This way, it can be readily demonstrated that the User Requirements have been satisfied by a particular Test Script and will also demonstrate what requirements were satisfied by a particular Test Script.

Before we start running the test scripts to show that all of the User Requirements have been met, we have some important tasks to accomplish, which should be performed in conjunction with the software supplier as they are relatively technical in nature.

  1. Installation Qualification (IQ): Just as with any piece of equipment, the software must be installed properly, per the suppliers documented requirements. Most suppliers will have a checklist that will need to be signed off by the supplier installer and an IT or technical expert. Do not continue with the process without an approved IQ.
  2. Operational Qualification (OQ): Does the software work within the user's environment as expected? Again, the supplier should have a detailed checklist of each critical activity which must be signed off by both the supplier and the user. If the User System Administrator is supposed to be able to set up user or department accounts, this should be demonstrated during the OQ, not when the system is live and people are trying to use it!

  3. Performance Qualification (PQ): This is where the Test Scripts, identified above, are executed. Every step of every module or process should be executed to the User's satisfaction, including both regulatory and unique customer requirements. The PQ is a list of tests, performed by independent personnel with each test performed multiple times. Results of the test along with objective evidence of the test results, signed and dated by the tester and co-signed by a technical expert are maintained as part of the Validation File along with the validation plan, IQ documentation, OQ documentation and any other relevant records.

Validation Report

What would validation be without a validation report? The validation report is used to summarize all the testing performed, the equipment used (as well as the calibration status, if appropriate), signatures, approvals, results and conclusions. The validation report should specifically state that specified equipment has been validated to perform as expected, or if not, what improvements must be made. The software should not be used until the validation report has been approved and made effective according to company procedures.

Don't forget about FDA 21 CFR Part 11, the FDA's electronic signature and records regulation. Most companies might need a little help with this one. Make sure you address electronic signatures and any quality data that is stored by the system.

In summary, commercial off-the-shelf software validation, while complicated, is not impossible and is certainly not beyond the abilities of most companies as long as companies work with the software supplier and follow the guidelines identified above. Don't forget! Make sure everything is documented and properly filed and archived.

David S. Brown is the President of David S Brown LLC, a consulting firm specializing in Medical Device and Tissue Bank Process Improvement, compliance and quality. David has over 20 years experience serving the medical device and tissue banking industry sectors. He is also an associate of Jim Colyn Consulting and works with other device/tissue consulting firms such as Barile and Associates. For more information, visit,