Validating or Not Validating for Intended Use?

When I say Validation For Intended Use, most of you picture an extensive documentation required by ISO and FDA.
Although Validation for intended use documentation is useful for several reasons (ensure accuracy, reliability, consistent intended performance, the ability to discern invalid or altered records, etc.) people mainly think of it as a regulatory requirement only.

In FDA's 21 CFR 820 the agency states in 820.70(i) relating to software validation for intended use:

"When computers or automated data processing systems are used as part of production or the quality system, the manufacturer shall validate computer software for its intended use according to an established protocol. All software changes shall be validated before approval and issuance. These validation activities and results shall be documented."

That is the first simple conclusion, right at the beginning, the law is clear, it is not optional, the validation documentation is a must. So, what you really need is not clever advice of cunning ways how to get around it, you will get more use of practical solutions on how to establish it on the right way and get your coveted certification faster. I will list some obvious and hidden pitfalls which can be easily avoided when it comes to documenting compliance.

Pitfalls in Validating for Intended Use

1. The first and most obvious pitfall is when the company is not aware of the importance of this issue and simply fails to perform such validation activities for its software.

   First of all, you’re preparing the validation for intended use documentation for yourself and not for the FDA or ISO.
   These regulatory bodies provide guidance that lays out a path for how things should be done to get the best results and produce quality products, both for the sake/benefit of your customers and of your business.
   Sure, you can go on without validating a purchased QMS or any other software that you’re using during developing your project, but it is just common sense that you first make sure the software you’re intending to use will fulfill its original purpose.

   Nowadays every online software provider offers a demo trial period where without any commitment you can test and play with the software and see if it fits your company needs. However, these trial periods do not necessarily include all the features available in the software. So, you have to decide which one to purchase without seeing the full picture. And then comes the Validation documentation. Think of it as evaluating the purchased software and checking if the features cover all aspects your company is planning to use the software for.

   Common sense guys... since quality systems are supposed to control your development, projects, manufacturing, packaging, assembly, automated testing, inspection, labeling, sterilization, etc... your production is important enough to allow yourself to spend some extra time on prep work that would include checking and validating the tool you intend to use to control key aspect of your operations.

   Make no mistake here as FDA will check Validation requirements for automated processes, and in case of any deficiencies, it will advise your company to correct them.

2. If the required validation activities have been performed but not documented.

   The second pitfall follows the previous one. They differ only in actions but not in results. It can be considered as one step forward, but still not enough effort: if the required validation activities have been performed but not documented.
   If you plan to work and succeed in the field of QMS and standard regulation, burn the mantra in your mind: “If it is not documented it does not exist.”
   Presenting just the end results, or simply having a signed document without the supporting documentation is no longer the standard of proof.
   The law is clear in 21 CFR 820.100 which states that “all activities required ... and their results, shall be documented”.

   Any lack of documentation of QSR related activities or remedial actions (there were no acceptance criteria, test methods, validation elements predetermined, etc.) means that they never happened, signed form or not. Such signed forms that are not supported by the documentation that lead to it, get a quick visit to the shredder and everyone gets confetti.

3. Going overboard with the validation documentation.

   Compared to the previous cases, this would mean falling to the opposite side of the horse. There is no use in creating a huge, unmanageable Validation for Intended use documentation, as it will fail the test for simplicity, ease of understanding and will lose the original purpose.

   • Don’t waste time and money to validate all of the functionalities and capabilities of the purchased software application. Be reasonable, you should validate only those features that are used in support of the quality system.
   • Don’t try to hit a gnat with a hammer – The system’s complexity is an important factor that you should take in consideration while planning the software validation, whether it is self-developed or purchased software. The validation activities should be commensurate to the software risk: for example, there are surely fewer validation activities for validating a spreadsheet, than validating a software that controls myoelectric prosthetics.

   And in the end, if you are still just simply unsure what should or shouldn’t be documented:

   • You can consider contacting an outside expert, they can be very helpful in assessing what is required for intended use validation and help you get the process started.
   • Also, you can choose to use software that provides the Validation for Intended Use Documentation. It's true that market-savvy vendors and suppliers of software used by medical device manufacturers should make available intended use validation as part of their product offering to meet the needs of their clients, but the reality is that few do.

   qmsWrapper offers a complete Validation For Use Documentation set.

4. When Risk Assessment is not taken into consideration before establishing the validation strategy

   One of the primary goals of the risk assessment is to identify critical tasks in the normal use process of your QMS software, review product quality and data integrity. Measuring the risks related to the software device is of key importance in order to determine the appropriate validation strategy and the required evidence resulting from validation activities.
   In other words, the risk assessment is the basis for determining which activities will be included in implementing your scalable Validation approach.

   An incomplete or poorly executed risk assessment could spell disaster for your regulatory submission. Most importantly, you might miss critical tasks. This can result in a study that does not demonstrate your device is safe and effective for use.
   Your best chance at success is to be diligent with your risk assessments prior to the validation documentation. Don’t let critical task errors be the death of your submission; your risk assessment is an investment, it will save you time and effort.

So, What Should You Do? Edification:

You should have a predetermined strategy established for software validation, such as the list of the critical software that has significant impact on the production and product quality, which functions/features need to be validated for intended use, the validation method, the equipment used, acceptance criteria, responsible personnel – external experts should be involved if necessary –validation test cases, etc...

• Self-developed software that is used in the Company’s product requires full validation and might end up being one of the highlighted subjects of the FDA inspection.
• The purchased or so-called off-the-shelf software should be validated according to its intended use, including but not limited to System requirements for the product, user guide, the product characteristics data table. Do tests using test data, does it do what it says it will do when you do it. In a spreadsheet, test your equations and calculations to ensure that what you enter and what you get are the results you expect.
  The required validation of the off-the-shelf software will depend on whether it is going to be used for/in Class I, II or III medical devices, for example:

  “... A commercially available personal computer operating system with a graphical user interface would require extensive documentation and evidence of validation when intended for use in a cardiac pacemaker programmer. Less documentation and verification of the OTS (Off-The-Shelf) operating system would be required for programming an artificial ear.”
  (Guidance for Industry, FDA Reviewers and Compliance on Off-The-Shelf Software Use in Medical Devices- 1999)

Benefits of Establishing the Validation for Intended Use Documentation

• Performing intended use validation may also help protect against product liability litigation.
• Intended use validation can avoid the repetition of certain operations and prevent materials or products from being reworked or scrapped.
• An established comprehensive software validation process can also reduce long term costs by making it easier and less costly to reliably modify software and revalidate each subsequent release or software changes.

Plan the work, work the plan.