Periodic Review - Deviations/incidents that are reviewed

P

PGD

Hi,

I was wondering if I could get some advice regarding the approach that should be taken to deviations/incidents that are reviewed as part of the periodic review of a computerized system.

I currently only consider any incidents or deviations that can be attributed to a root cause of system/software failure, I do not consider any incidents or deviations that are down to an operator or user using the system incorrectly, or even any incidents or deviations that are caused by process (SOP) failures?

My question is should I exclude what I currently do and focus on the actual failures of the software, or are there any regulations or guidelines that say I should include the other root causes I have mentioned?

Thanks in advance.
 

yodon

Leader
Super Moderator
The periodic review is intended to determine if there have been any changes that would be considered impacting the state of validation. (Confirm that's you're intention as well?) Software failures, I would think, be immediately assessed for impact on the system and addressed as appropriate to the level of risk (impact). I woldn't necessarily wait for periodic review to determine if actions should be taken.

I think the failures related to incorrect use would be more interesting considerations during periodic review. If you find that there's a trend that shows a specific failure repeated due to the same mis- / incorrect use then that might be an indication that you're not meeting your user needs and changes are warranted (which would then require an assessment of the impact to the state of validation, of course).

The whole idea is to continually assess your systems to determine if there has been anything that would impact the state of validation that you weren't necessarily aware of. This could include things like (not an exhaustive list by any means) expanding scope from original validation, changes in use, expanding the number of users, an OS change or change to underpinning software (e.g., database engine), etc.
 
P

PGD

Thanks for your response. Sorry for the confusion regarding failures. These are addressed immediately however as part of periodic review reporting i would highlight the number of failures or incident reports within that review period (along with other items such as changes etc). My question was is there any specific guidance or regulations on this? Should i only include incident reports in my periodic review report that were due to the system nit functioning as expected? Or should i also include incident reports where a user has incorrectly used a system? Thanks again.
 

yodon

Leader
Super Moderator
I'm not aware of any guidance that would drive any specific topic for periodic review.

Do your ongoing changes NOT trigger a review to the impact on validation? If not, I would suggest they should.

And again, I would think the incorrect use review might be more revealing!
 

v9991

Trusted Information Resource
Hi,

I was wondering if I could get some advice regarding the approach that should be taken to deviations/incidents that are reviewed as part of the periodic review of a computerized system.

I currently only consider any incidents or deviations that can be attributed to a root cause of system/software failure, I do not consider any incidents or deviations that are down to an operator or user using the system incorrectly, or even any incidents or deviations that are caused by process (SOP) failures?

My question is should I exclude what I currently do and focus on the actual failures of the software, or are there any regulations or guidelines that say I should include the other root causes I have mentioned?

Thanks in advance.

you MUST include the incidents or deviations related to "operator" as they reveal the fundamental flaw/defect in the way those/respective root causes were handled; either they are not effective; or require supplementing action points.

and wrt regulations or guidelines....here'w few.
https://www.fda.gov/downloads/drugs/guidances/ucm073517.pdf
(2) Periodic quality reviews, that can include: (i) Measures of customer satisfaction such as product quality complaints and recalls (ii) Conclusions of process performance and product quality monitoring (iii) The effectiveness of process and product changes including those arising from corrective action and preventive actions

Zhuhai United Laboratories Co. Ltd. 6/27/18
  • Assess your overall system for investigating OOS results. Provide a CAPA plan to improve the quality of OOS investigations. Your CAPA should ensure that your revised OOS investigations procedure includes improved quality unit oversight of laboratory investigations, identification of adverse laboratory control trends, and investigation of potential manufacturing causes when a laboratory cause cannot be conclusively identified.
 

v9991

Trusted Information Resource
you MUST include the incidents or deviations related to "operator" as they reveal the fundamental flaw/defect in the way those/respective root causes were handled; either they are not effective; or require supplementing action points.

and wrt regulations or guidelines....here'w few.
Q10 Pharmaceutical Quality System


Zhuhai United Laboratories Co. Ltd. 6/27/18
6 Methods for CAPA Effectiveness Verification
Trend Analysis
is the retrospective review of data to verify that expected results were achieved. An example of trend analysis is the review of environmental monitoring (EM) data for the period covering the last 30 batches to show the downward trend in EM excursions due to process improvements.
.
Corrective and Preventive Actions (CAPA)
Using the selected sample of significant corrective and preventive actions, determine the effectiveness of these corrective or preventive actions. This can be accomplished by reviewing product and quality problem trend results.
 

srkn14

Involved In Discussions
In The similar context of Periodic review of CSV Systems: Some people I faced are arguing that "If the system is upgraded and validated every year then there is no need to perform the periodic review". Is this argument acceptable to be compliant to the Periodic review requirements of validated systems?

Thank you for your information
 

yodon

Leader
Super Moderator
compliant to the Periodic review requirements of validated systems
First off, I don't think there are any specific *requirements* for periodic review. "Stuff" happens and that "stuff" could take the system out of a validated state. The periodic review is intended to determine if there are any actions needed to bring the system back into a validated state.

Updating and re-validating every year, on the surface, wouldn't necessarily address all the "stuff" that can take the system out of a validated state. It might well catch any changes - both to the system and any underpinnings (hardware or support software) but will it address any use changes (new / different uses, more users, etc.)?

If you do the periodic review, you might find you don't need to re-validate. That could be more efficient.

I can't pass up a plug for the recently-released FDA guidance on Computer Software Assurance. This may be a good time to re-think and maybe streamline your validation program.
 

v9991

Trusted Information Resource
"If the system is upgraded and validated every year then there is no need to perform the periodic review". Is this argument acceptable to be compliant to the Periodic review requirements of validated systems?
there is one counter point in the argument., does the 'yearly/annual upgrade or validation ' address the points to be 'assessed-evaluated and redressed' to be carried out as part of the 'periodic review;.
if yes, then the periodic review itself can be elaborated and presented to efficiently address the need of upgrade/-revalidation`
if not, then how does it address the periodic review criteria` ( i.e., upgrading the features or re-validating does not address any recurring/trends to be reviewed/evaluated ); which is exactly the point made by @yodon
 
Top Bottom