I worked with a client for a number of years on quite a few systems but hadn’t been back to work with them for about five years. Earlier this week I was asked to help them out since they have brought on some new folks and are picking up on activities that were dormant for a few years.
While I hadn’t touched the system in about five years and certainly wasn’t an expert (it’s not used at any of my other clients and I am generally system agnostic), because of the solid documentation my Solutions2Projects, LLC team left in place, I was able to quickly get back to a functional knowledge of system, the validation, and the original intent and design of the system. It did take a few minutes to dust off my memory about it and if it weren’t for the documentation, I would have been really limited in my ability to help them out.
At one point we pulled up the performance qualification (PQ) documentation so I could reference specific steps to perform a function. Turns out the work instruction had a typo that was leading to some confusion. Note: we wrote this work instruction in 2012 or 2013 and only now was someone pointing out that there was a problem. What this means is that folks were not following the work instructions but that is a totally different problem in a regulated company.
Being in life sciences, we have systems subject to 21 CFR Part 11 and therefore subject to computer validation in compliance with FDA regulations. When we speak of computer validation with regards to computer systems, we focus on people, process and systems. The people get trained to follow the documented processes based on the validation of intended use of the systems. At some point there must have been a breakdown on the training if the users were not following the documented processes in the work instructions. This is not unusual but it is unfortunate and could be compromising the validated state of the system.
Computer validation isn’t just about checking boxes and creating a lot of documentation to meet compliance requirements. Computer validation forces good business practices in terms of defining what you need in a system, configuring or developing against those specific requirements, testing to ensure the requirements are adequately met, training users to use as intended, and then maintaining control over the system to make sure that you can rely on the data in the system (data integrity). And, all of this is documented because as we all know, to the FDA, if it isn’t documented, it didn’t happen.
But you don’t just do this to meet compliance requirements. You do this because you want to make sure your system is a good investment and provides you with the business value your company needs. It reduces overall costs and increases the value of the system and the data to the organization. And that makes good business sense.