Process Control System Risk-Based Validation
On September 13th, the #FDA published a draft of "Computer Software Assurance for #Production and quality system software", which may supersede section 6, of the "General Principles of Software #Validation" soon.
After this publication, many #companies and #individuals started a big conversation, and #delirium started. Multiple classes and training popped up from night to day. But . . . Why?
A well-performed CSV is a new CSA requirement
Those, who performed #CSV, before the "CSA" term popped up based on the Risk Assessment, with #critical thinking are sitting behind the desk and laughing at those, who are in delirium about the CSA #requirements, and recommendations.
So, what's the catch, or difference between CSV and CSA?
THERE IS NO DIFFERENCE. A well-performed CSV is just disguised as CSA.
How to perform a Risk-Based approach to Process Control System Validation or Computer Software Validation, and be aligned with the "CSA requirements"?
1. Initial Process Control System Assessment and System Impact
At the beginning of the Initial Assessment of the Process Control System and its impact, little detail may be known about the Process Control System. However, it is necessary to know, the following: #QTPP (Quality Target Product Profile), proposed manufacturing processes, #CQAs (Critical Quality Attributes), and #CPPs (Critical Process Parameters). These product parameters, processes, and attributes must be a part of the quality #User #Requirement #Specification. The Process Control System #Impact #assessment is based on the potential of the Process Control System to affect product quality, patient safety, or regulated data and records.
2. Identify functions with impact
"What is the worst scenario, that could happen if this function is not performed correctly?"
This question is not the #famous question that author of the #URS, #quality, and process engineer wants to hear. But this question is #crucial to perform a good assessment of functions, which can #affect product #quality, #patient #safety, and #data #integrity.
Sometimes, a function may support multiple CQAs or CPPs. If this case occurs, its impact rating should reflect the highest impact of any of the supported CQAs, or CPPs.
3. Perform Functional Risk Assessment and Identify Controls
"How we can reduce risk to an acceptable level?"
At this stage, the #CSV engineer and project team should have access to Process Control System #design #specifications to allow necessary controls to be identified.
The #Functional Risk Assessment should be based on identifying possible scenarios and hazards associated with the function and then combining #severity, #likelihood, and #probability of detection to generate overall risk #priority levels and identify appropriate controls.
领英推荐
a)Severity
The #Severity rating is derived by considering #possible risk scenarios and assessing their potential effects on product quality, patient safety, or data integrity.
b)Likelihood
For a Process Control System, the #likelihood rating associated with a risk scenario may need to consider both the likelihood of a process problem occurring and the likelihood of a system problem occurring.
c) Detectability
#Detection is a rating corresponding to the likelihood that the current process controls will detect a specific root cause of a failure mode before the product or part/component leaves the manufacturing.
Decision-Making calculation for risk mitigation
a) Risk Class Definition
The calculated #Risk #Class (RC) helps to focus attention on areas where the process is most exposed to risk without taking into account the methods or probability of detection.
b) Risk Priority Definition
The calculated #Risk #Priority (RP) is a measure of the overall risk associated with the failure mode. It helps to focus attention on areas where the assembly process is most exposed to failures or hazards that have a higher probability of not being detected.
c) Action Priority Definition
The purpose is to provide decision-making guidance in relation to a calculated risk priority.
Bottom line:
You are welcome to subscribe to the?#CSV?/?#CSA?#Newsletter?to find more information from the Software / Control System?#Validation?world, where you will get some examples, of how to do it, which are proven and working. Also, you are welcome to comment, and post your point of view and approaches, because everyone is using different approaches for the Software / Control System Validation.
Associate Director of CSV & Data Governance / I improve patient safety through data integrity
1 年Excellent read Erik D.. Highly recommend reading this article and implementing such approach to those who don’t already use a thorough Risk Assessment process to determine the controls and extent of validation of a system. One criticism however: in my opinion, having a final risk level that is “acceptable upon review” is an open door to everything in that level turning into “acceptable”, and what’s the point of that. I would suggest a two-tiered approach akin to an FMEA’s RPN, or if you do prefer a three-tiered approach, require a “less extensive” control for yellow (e.g. procedural) and a “more extensive” control for red (e.g. automation, configuration). Otherwise it’s pretty much spot on, I encourage companies to predefine general risk areas and failure types (i.e. based on process or system type) to facilitate the assessment for a system. It focuses and accelerates the system-specific evaluation.