Folks,
I’m trying to develop a strategy which will use risk assessment to narrow computer system validation scope. I’ve read through the GAMP5 recommendations and they seem very sensible. But my difficulty is that the GAMP5 recommendations are at quite a high level and very conceptual. Does anybody have any concrete examples of how to implement the GAMP recommendations?
Thanks
Thats a pretty broad question.
Perhaps you could provide us with your scenario and we will throw out
a few suggestions.
Scenario: You have a software application where inputting the date into required fields is essential to an expiry on a product. The date field is obtained from a pop up window where a calender is used to show the user all the dates they require (Similar to booking a flight on a travel website)
The problem is that this date pop-up is used in 150 different locations in the application.
Do you test all locations?
After a risk assessment it was discovered that the date pop-up is being called from one class in the code i.e from only one location.
As the same class is called each time there is no extra benefit in testing this functionality 150 different times, hence testing will be performed at one location only in the software.
This is a very simple example, but I hope it demonstrates somewhat, what is required.
Regards
We do Risk Assesment by selecting GMP and NON GMP critical transaction codes from each module and check for its authorization objects.
Graham is there any standard protocol or format? kindly through some light
rgds
Satish
[quote=satishcrown]We do Risk Assesment by selecting GMP and NON GMP critical transaction codes from each module and check for its authorization objects.
Graham is there any standard protocol or format? kindly through some light
rgds
Satish[/quote]
I’m not sure if there is any standard protocol or format that can be used, but a good starting point might be to generate flow diagrams of the GMP critical and non critical paths and detail the level of testing through that.
I guess it depends on the application in question, I would be interested to hear if there is a standard approach for this type of testing.
Regards
Hello!
We define RA process as follows with some examples. Does this help in understanding? Do let me know.
(A) GxP Determination
• List down various processes which have been automated.
(B) System Impact
Next step is to identify use of Automated System and find its direct impact on following criteria:
• Impact on generating, manipulating or controlling data supporting regulatory safety and efficacy submissions.
• Impact on control of critical parameters or data used
• Impact on control of data for product release
• Impact on control of data required in case of product recall
• Impact on controlling adverse event or complaint recording
© Functional Risk Assessment
Further, processes are listed and evaluated for assessment of risk to either product quality and data integrity. It involves mainly following steps. These are based on GAMP 5 directly.
These steps are explained below.
Point number 1 & 2 are linked with User Requirement Specification document.
Point no. 3, 4 and 5, ascertains the prioritization of risk in High/Medium/Low categories.
Pt. 6 covers the overall priority on the basis of results obtained in 3,4 and 5 using RPN numbering methodology.
System function parameters are evaluated and identified whether they represent a risk when assessed against a series of GxP criteria.
Following types of risks are mainly identified during risk assessment process for use of automated systems in regulatory environment:
• Risks towards non-availability of required documentation
• Risks towards non-availability of required SOPs
• Risks towards non-availability of system Access Control
• Risks towards abnormal user operation performed at the time of system operation
• Risks towards incorrect configuration of system
• Risks towards Improper and/or inadequate training
• Risks towards implementation of US FDA 21 CFR Part 11 rule
Having determined that a particular function may have a GxP risk associated with it, the assessment proceeds to identify the various risk scenarios i.e. the events that identify the risks associated with use of the system.
The functions identified are analyzed by considering possible hazards/adverse effects and what controls may be needed to minimize the potential harm.
2.1 Assessing the Likelihood of An Adverse Event
After identifying hazards / adverse events, determine the likelihood (frequency or probability) of it occurring. User considers the likelihood of the adverse event occurring per number of transactions, and assigns a value to that estimate.
Ranking of likelihood methods are defined as follows:
The processes which are internally controlled by software (user can’t modify) and have been tested thoroughly during software development, may be considered as ‘Low’ risk. Such risks may fall in ranking of likelihood 1 to 3 from the Table – I ( Not attached here) below. For example: Display parameters, print records.
The processes which are controlled by users and are due to possibility of human error and non-availability of system control may be considered as ‘Medium’ risk. Such risks may fall in ranking of likelihood 4 to 6. For example: Change in set parameters, change in recipe.
In many instances adverse events may be as the result of the systematic software faults, such as software bugs and the team may be unable to estimate the likelihood of such an adverse event. In such instances the likelihood ranking should be in range of 7 to 10.
2.2 Assessing the Severity of Impact
After determining likelihood of adverse event, severity of its impact on process is assessed. These effects take into account impact on regulatory compliance, impact on product quality and impact on data integrity.
The impact of risk occurring may be described as follows:
The processes which do not directly affect the final output of the system/software may fall in ranking of severity 2 to 4. For example: Warning messages, reference parameters, etc.
The processes which are used in the initial stage of operation, however it may affect the final output but those are not used for final release of output, may fall in ranking 5 to 6 of severity. For example: System alarms, power failures, communication failure, etc.
The processes which are used in the final stage of operation and are used for final decision for output may fall in ranking 7 to 10 of severity. For example: set parameters, selection of recipe, selection of operation, print record, display record
2.3 Detection of Adverse Event
Next step is to identify if the adverse event can be recognized or detected by other means in the system. Adverse event having high probability of detection, may not pose a serious threat because it can be recognized quickly and suitable corrective action taken to mitigate its impact. If an adverse event has a low probability of detection, then the risk condition needs to seriously consider a review of the design or the implementation of alternative procedures to avoid the event.
Adverse event is detected at final stage of output or after release of output or may not be detected, may fall in ranking 6 to 10 of probability of detection. For example: Non-availability of SOP, usage of SOP, Training, wrong selection of operation etc.
The processes with adverse events are advanced to next stage of operation; however that adverse event can track down before final release of output may fall in ranking 4 to 5 of probability of detection. For examples: wrong selection of set parameters.
The processes with adverse events which are identified by system and highlighted with error message may fall in ranking 1 to 3 of probability of detection. For example: alarm message, trip conditions, etc
Overall priority is calculated using RPN number methodology. RPN means Risk Priority Numbering and in it multiplication of the all three assessments are done.
RPN = Severity x Occurrence x Detection
I have not attached any tables as mentioned above, however I hope that this may throw more light on actual assessment.
Based on above, you may create a table having various risk scenarios at left side and columns of impact of failure, point 2.1, 2.2, 2.3 and 3 at right side.
This may help you to quantify the RA process and determine mitigation strategies.
Hope above is useful.
Regards
Jaydeep D. Chhatrapati
Director
Epitome Technologies Pvt. Ltd.
India.
[quote=satishcrown]We do Risk Assesment by selecting GMP and NON GMP critical transaction codes from each module and check for its authorization objects.
Graham is there any standard protocol or format? kindly through some light
rgds
Satish[/quote]
Hello Satish,
SAP provides a document which has modulewise US FDA cGMP affected areas as well as 21 CFR Part 11 affected modules. This may come in handy when you are defining and implementing SAP system in regulated environment. Idea is to incorporate this in URS and Configuration documents.
While doing SAP validation, we have seen number of SAP systems in pharma whereas there are lot of issues because use of SAP has not been defined for regulatory aspects.
Regards
Jaydeep D. Chhatrapati
Director
Epitome Technologies Pvt. Ltd.
Ahmedabad. India.
email : jaydeepc@epitome.co.in
Jaydeep,
Good input! I like the approach.
Regards,
Kevin
Good elaboration and clearly defined.
Risk assessment can take a lot of forms; the important thing is that you document your assessment and findings so you can justify the decisions you have based on that assessment.
One of the ways we determine validation scope is to assess risk based on a combination of GAMP 5 software category and regulatory impact (Direct, Indirect, None). This results in a risk level that we use to determine the scope of our validation.
For example:
All of this is proceduralized to ensure consistency and compliance with applicable regs and our internal standards.
Dear sir,
your concept is excellent, please let me know by taking any example, i am finding very difficult in finding risks, please help me in assessing in any examples like (risk assessment in secondary changing, or equipment qualification)
Thanks in advance
I hate risk assessments. I hate them with a passion, they are speculative, subjective and innacurate.
Risk assessments should be banned from GxP - they really are that pointless.
Garbage, garbage garbage
(Bread walks away with pains in his chest)…