In the regulatory context, how do you reconcile the freedom to improve quality or value with regulatory constraints (especially in the pharmaceutical industry)? Any innovation in your process can take 1 or 2 years of approval by the regulatory authority.
It depends on what kind of innovation we are talking about. The health authorities do not have to approve absolutely everything you do. Logically, if we are talking about changing a prescription, the health authorities get involved. But if we are talking about operating procedures that define how you design a solution, for example, your chromatography software, and how you integrate them, how you are going to maintain validation, these approaches typically do not require approval from health authorities.
The health authorities will audit your processes afterward, as you’ll be indicating a shift from one method to another. However, these types of audits are retrospective, not prospective. Most of the processes we discussed for applying critical thinking do not require pre-authorization from the health authorities.
You can be compliant whether you have a 100% paper-based system or an all-digital system. Data integrity applies to one system as well as the other. So there is room for maneuver within our organizations to implement these processes without explicit authorization from these regulatory bodies.
I understand that your idea is not to standardize validation protocols? If this is correct, how do you ensure compliance every time someone performs a protocol? The idea of standardizing is to know in advance that you are complying with the requirements. If it is not rigid, the review requires more effort.
This is exactly the trap that I think we fall into by creating these templates because it generates the illusion or the perspective that just because we have it, we have the IT system under control.
But how do you manage a template protocol that covers all cases of computer systems? It would be practically necessary to establish a protocol for each of the computer systems in each of their possible variants. For this reason, I think we end up falling into our own trap, which fortunately is easy to get out of.
The template should record the scope of its own boundaries, where it starts and where it ends, what I am looking to do, the methodology we should follow, what we should challenge and what we should not, how to interpret the risk analysis, and so on... This is what template protocols should do. Protocols are also the most difficult to standardize because the tests are different.
The approach in this case is to assess the value of the standardized protocol. If it proves beneficial to me, justification will be grounded in critical thinking.
How do we evaluate software change and implementation without first challenging it using critical thinking?
Critical thinking is a framework, which then gives us specific tools. For example, one of the tools that the application of critical thinking has given Pharmware is the use of process maps as the primary unit of validation of a process that is supported by a computer system. I don't explain what the computer system does, I explain my process and where the computer system(s) enter into that flow.
In an example of bringing materials into the plant, one of the things that happens is that I receive a packing slip, and I load that information into the system, then print a label with that data. But what happens if I need to change that label? If the data is in the software, it is simple. What I recommend you do in this case is to review the process map of this material input and check if the fields were in that map or not. And this is because, maybe, in that map, it is only specified that you print a label. Additionally, you might have a functional specification that outlines the specific data to include on that label.
In this case, you would know that the risk is lower, because it is a piece of information that exists but was not on the label, so the process flow did not change, but simply the printed information. In this case, looking at two very simple documents, which you obtained previously by applying critical thinking, you can assess that the change has a much more limited impact on this process or this segment of activities within the process.
Can you share the FDA document you mentioned earlier that discusses quality and compliance?
I think I may have mixed the two topics. On one hand, there is the Computer Software Assurance approach, which has its specific documentation, and on the other hand, the Quality and Compliance approach. This mixing may have caused some confusion. Here is the mentioned paper that touches upon the CSA approach (still in draft)at a general level.
