Demystifying the Qualification vs. Validation Debate in SharePoint

What’s the difference between Qualification and Validation?

I have tried answering this question using the definitions in FDA’s Glossary of Computer Systems Software Development Terminology, but often this just creates more confusion. So I adjusted and now I try to approach this using an unconventional example:

Let’s suppose you are a novice carpenter. 

Your local hardware store is having a sale, so you head over there and buy yourself a new table saw.  You take it back to your workshop, unpackage it, and try it out by cutting some scrap pieces of pine wood you have lying around. 

Using VNV terminology, what you’ve essentially done is to qualify your tool. You have established that it works as intended (per the intentions of the manufacturer’s design), but not with any specific project in mind.

Now you sit and wait for someone to hire you and finally someone approaches you with a request to build a new dining room table (6 ft. square, oak wood, with tapered edges). Before you accept the job, you run through a mental checklist: Can I use my table saw to cut through oak wood? Can I use my table saw to cut tapered edges? You’re uncertain, so you go back to your workshop and try your saw on some scrap pieces of oak wood you have lying around, and then you proceed to successfully build a table. 

Using VNV terminology, what you’ve essentially done is validate your tool for a specific application.  You have established that it is fit for a specific intended use (or process).

Tools are qualified whereas processes that use the tools are validated

If we think of computer systems in general, the first thing to do when deciding whether to qualify or validate is to understand the intended use of the system.

If we take SharePoint as an example of our electronic system, we need to ask ourselves: will we be using SharePoint as a simple document repository or as the backbone to a larger electronic document management system (EDMS) or Quality Management System (QMS) (i.e. is the process driven in SharePoint or in the EDMS / QMS)?

If you are using SharePoint as a simple document repository (with regulated content), then it is both your tool and your process. In this case, it needs to be validated.

If you are using SharePoint as a backbone to a larger EDMS or QMS, then it is just a tool. In this case:

• You should qualify SharePoint as a tool for storing regulated electronic records.  Perform basic verifications to ensure only authorized users can use the system, to demonstrate how audit trails are recorded and maintained, and to verify that procedures are in place to ensure availability of records.
• You should validate your SharePoint-based EDMS or QMS for managing regulated electronic records.  Leverage the results of the SharePoint qualification effort.  Test the workflows.  Ensure procedures are in place to sustain the validated state and system users are appropriately trained.

The Takeaway

After all this, I have one final comment - don’t worry about the semantics.

What’s important to remember is that you actually perform and document system verification activities. The term used to label those activities (system testing, IQ, OQ, UAT, verification, etc.) is actually irrelevant.