It’s no secret that validation can be a bear. All of that documentation and testing, the multiple phases with pesky transition gates, a million reviews and approvals…it can really slow down an IT project, which often leads to questions about why on Earth we bother with it.
Well, it all traces back to rules and regulations issued by the United States Food and Drug Administration (FDA). (I promise – your validation colleagues didn’t make it up!)
21 CFR Part 820.70(i) (in other words, section 820.70(i) of Title 21 of the Code of Federal Regulations) states the following:
(i) Automated processes. 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.
Additionally, 21 CFR Part 11.10(a) states the following as a requirement:
(a) Validation of systems to ensure accuracy, reliability, consistent intended performance, and the ability to discern invalid or altered records.
So, you see, validation is required by federal law for every computer system being used for FDA-regulated purposes. Why? Because it proves that the data in those systems is trustworthy and, therefore, protects the health and safety of the general public. That data is used in life-or-death decisions every day, so it’s pretty darned important that it’s reliable, don’t you think?
The next time you find yourself feeling annoyed by the validation aspect of an IT project, try to shift your perspective. Instead of thinking of it as a big, overbearing grizzly bear, try to envision more of a soft, cuddly teddy bear. After all, what validation is really about is safety, security, and comfort.