EU GMP Guideline Annex 11 “Computerised Systems”

« Back to Previous Page
35
0

To the extent of my knowledge, a Risk Assessment stems from (or follows/proceeds) the URS. If this is the case,...

Please to read the entire article.

Marked as spam
Posted by Mark Denham (Discussions: 1, Comments: 6)
Replied on December 3, 2017 12:00 am
30 views
0
Private comment
Part 1 of 2 fields. You already do this. Other parts in Section 4 help provide context. You see words such as “relevant,” “critical,” “appropriate,” and “adequacy.” The overall purpose of any risk assessment is gain “high confidence” in the final result(s)/product(s). Any system or process “weaknesses” is a risk.
You already ask these risk assessment questions before (or while developing) the URS:
--What data parameters and ranges are required to ensure the accuracy of the final product?
--What parts of the system provide the greatest value – or “Might” cause the greatest Harmful impact - to the raw data, accuracy/efficacy, stability, and safety to the final product, and product users? How likely are those situations to occur? Do the system's or business processes have adequate security/protections? What is the durability, capacity, and accuracy under the heaviest workload you anticipate in the next few years (based on the “lifetime” of the system)?
Marked as spam
Posted by Connie Curts (Discussions: 0, Comments: 13)
Replied on December 2, 2017 7:00 pm
0
Private comment
Part 2 of 2 in these fields (they have limited space to type). Many of these risks may have their risk reduction measures written in your validation plan.

You can manage potential the human factors/errors with SOPs, training, scheduling, and more. You already have "some" electronic security when requiring users to login to the computer, and you have physical security at the door or driveway.

Which system requirements are too week to prevent or reduce losing one of the requirements after the system release? Ask the same question for all your business processes, even those that are not subject to Annex 11, because those processes will have an impact in some manner (high, moderate, or low).
Marked as spam
Posted by Connie Curts (Discussions: 0, Comments: 13)
Replied on December 2, 2017 7:00 pm
0
Private comment
Don't overlook the risks with the vendor, such as late equipment/software delivery, inadequate instructions in their IQ, and perhaps bankruptcy, etc.
Marked as spam
Posted by Connie Curts (Discussions: 0, Comments: 13)
Replied on December 2, 2017 7:00 pm
0
Private comment
Hi Connie! Thank you for your detailed response. When you mention "Part 1 of 2 fields" and "Part 2 of 2 ... fields", what are you referring to? Are these sections or §'s in EU GMP Guideline Annex 11, perhaps? Excuse my ignorance! Otherwise, very helpful.
Marked as spam
Posted by Mark Denham (Discussions: 1, Comments: 6)
Replied on December 3, 2017 7:00 pm
0
Private comment
My understanding is that if you follow ASTM E2500 mentioned in GAMP you should look for risks considering Product, Processes and Regulations. After completing this task, then you evaluate how the system will fit into that scenario and create the URS considering "how the system can potentially mitigate those risks".
Marked as spam
Posted by Flavio kawakami (Discussions: 0, Comments: 2)
Replied on December 3, 2017 7:00 pm
0
Private comment
So, I take it that in this context, risk is nothing to do with a Functional Risk Assessment, which would be a subsequent task item?
Marked as spam
Posted by Mark Denham (Discussions: 1, Comments: 6)
Replied on December 3, 2017 7:00 pm
0
Private comment
Yes. Basically an initial Risk Assessment is used in FDA regulated companies to identify whether a system needs validation or not based on the impact of its operation or malfunction on the safety, efficacy, and quality of a regulated product or process and on operator/patient/consumer safety. I call it an SEQ Risk Assessment and it is a one pager. It serves two purposes by identifying systems needing validation and by ALSO identifying systems that do not need rigorous validation, only general good IT practices for business function. The SEQ Risk Assessment is done first to identify whether a URS and CSV package is needed.
Marked as spam
Posted by Dr. Teri Stokes (Discussions: 0, Comments: 1)
Replied on December 3, 2017 7:00 pm
0
Private comment
Thank you Teri - very helpful information and much appreciated.
Marked as spam
Posted by Mark Denham (Discussions: 1, Comments: 6)
Replied on December 3, 2017 7:00 pm
0
Private comment
I have consulted this question to an EMA inspector in a DI conference at Guangzhou last year, your answer is right. It is a high level risk-assessment to determine what should be covered in the URS, not FRA/FMEA to individual requirement. It makes sense even it is the inspector's personal explanation to this regulation.
Marked as spam
Posted by Ian Yi (Discussions: 0, Comments: 2)
Replied on December 3, 2017 7:00 pm
0
Private comment
Thank you very much for your additional confirmation on the subject Ian!
Marked as spam
Posted by Mark Denham (Discussions: 1, Comments: 6)
Replied on December 3, 2017 7:00 pm
0
Private comment
Hi Mark, I think Connie refers to the "answer field" in this thread :) There is not that much space for a detailed answer .
Marked as spam
Posted by Jérôme Tomaselli (Discussions: 0, Comments: 1)
Replied on December 3, 2017 7:00 pm
0
Private comment
Thank you Jérôme - I see what you mean (didn't realise that the response space was so restrictive!
Marked as spam
Posted by Mark Denham (Discussions: 1, Comments: 6)
Replied on December 3, 2017 7:00 pm
0
Private comment
This question was raised during the review of Annex 11 draft in 2008 and later at the publication of Annex 11.
Indeed, Risk Management should (must) be understood as a supporting process: i.e. there are several type of RM activities over the system life cycle. GAMP 5 and ASTM E2500 advocate for such an approach.

Annex 11 is not perfectly written and an explicit mention of a High Level Risk Assessment (prior URS) and of a Functional Risk Assessment based on the combination of process and system functionalities would be helpful and welcome for clarity.
Marked as spam
Posted by Yves Samson (Discussions: 0, Comments: 9)
Replied on December 4, 2017 7:00 pm
0
Private comment
Good morning Yves - indeed I'm in agreement with you here that the explicit mention of "High-Level" (pre-URS) and "Functional" (post-URS) would be very helpful. I myself and indeed others have been tripped-up with this on several occasions.
Often, what happens is that the term "Risk Assessment" is used in a paragraph and one has to jump ahead in order to understand via the context which "type" (or should I say "stage"?) of risk assessment is been referred to.
Marked as spam
Posted by Mark Denham (Discussions: 1, Comments: 6)
Replied on December 4, 2017 7:00 pm
0
Private comment
Jerome is correct. I referred to the answer field for this forum. (Sorry about the delay replying.)
Marked as spam
Posted by Connie Curts (Discussions: 0, Comments: 13)
Replied on December 4, 2017 7:00 pm
0
Private comment
Helpful clarifications here. Thanks to all of you.
Marked as spam
Posted by Gail A. Schumacher (Discussions: 0, Comments: 3)
Replied on December 4, 2017 7:00 pm
0
Private comment
System classification documents can also prepared to classify the system and based on risk and categorization further validation has to be performed as per GAMP 5.
Marked as spam
Posted by Chander Dangi (Discussions: 0, Comments: 2)
Replied on December 4, 2017 7:00 pm
0
Private comment
If I remember correctly the EU annex is based on GAMP 5 which recommends several different risk assessments. One for each part of the system life cycle, and additional when there at major changes within the execution phase upon system creation.

The different risk assessments have different purposes, which I believe the EU annex is trying to address. The URS should be risk based, on a risk assessment which is looking into what do we need from the system? If we implement this, which risks do we need to address etc.
Marked as spam
Posted by Emma Magnusson (Discussions: 0, Comments: 1)
Replied on December 4, 2017 7:00 pm
0
Private comment
@Jonathan Lindtner. If we factor in technical complexity during the FRS risk assessment the it directly affects how much and what type of validation testing is required. For example; if the tech/FRS item is OOB, and lightly configured in the GUI by an admin and not a developer, then perhaps only positive testing during PQ is needed. Does this help?
Marked as spam
Posted by Pablo Romero (Discussions: 0, Comments: 2)
Replied on December 5, 2017 7:00 pm
0
Private comment
@Emma
I am not sure that Annex 11 is based on GAMP 5! ... ;-)
Finally, industry and regulators succeeded to achieve some significant convergence.
Furthermore, Annex 11 - like GAMP 5 - relies on ICH Q9 and the proposed Risk Management process requires Risk Review.
For me, in a wider understanding of Risk Management, the various types of risk assessments suppose the review and consolidation of the previously performed assessments.
For eyample, if the High Level Risk Assessment is meaningful and comprehensive (i.e. not only focused on GxP aspects), its outcomes could (should) be considered at the Functional Risk Assessment stage.
Marked as spam
Posted by Yves Samson (Discussions: 0, Comments: 9)
Replied on December 5, 2017 7:00 pm
0
Private comment
Maybe it is simply too easy to spell 'Risk'...
I have on numerous occasions met these four letter but been unable to match the stated text to any meaningful activities during actual execution. I guess we grunts are on our own while the officers hide behind the latest catchphrases.
Marked as spam
Posted by Jonathan Lindtner (Discussions: 0, Comments: 1)
Replied on December 5, 2017 7:00 pm
0
Private comment
Risk assessment that supposed to be performed part of computer systems validation is “Functional Risk Assessment” it has no difference in Part-11 or Annex 11, however most of the so called CSV experts ( including trainers) teaching about project risk management, it is nothing to do with risk based approach to CSV, it should concentrate on patient safety, product quality and data integrity parameters. I have seen very few have comprehensive idea about GAMP recommendation to Risk Based Approach to CSV. Please refer my article on https://www.linkedin.com/pulse/risk-based-validation-approach-choice-industry-maintain-anand-rao-c
Marked as spam
Posted by Anand Rao. C (Discussions: 0, Comments: 1)
Replied on December 6, 2017 7:00 pm
0
Private comment
I think Annex 11 refers to Risk in multiple places.

One reference is to use risk of system on product quality, patient safety and data integrity to decide on extent of validation. This is generally done in the form of scoring the system on basis of various impact factors each given a weighing factor. The final score used to decide the GAMP process to be followed.

Second is to use risk assessment in all life cycle stages. That generally done by FMEA type risk assessment of requirements mentioned in URS or FRS. Once done the risks are mitigated through additional testing or through procedural controls.

These two should be enough for EU as per my opinion. There is another risk assessment done in form of out of box functionality and configured functionality. This one i dont think any reg is suggesting. It is just one of ways to reduce validation testing .
Marked as spam
Posted by Yogesh C. Jagtap, PMP (Discussions: 0, Comments: 3)
Replied on December 6, 2017 7:00 pm
0
Private comment
Funny. I was suggesting just this week that perhaps starting from the risk scenarios, a risk based set of solution requirements might be a valuable alternative URS process
Marked as spam
Posted by Heather Longden (Discussions: 0, Comments: 4)
Replied on December 8, 2017 7:00 pm
0
Private comment
Hello Heather - thank you for your comment. I'm not sure I understand it fully, though - can you elaborate?
Marked as spam
Posted by Mark Denham (Discussions: 1, Comments: 6)
Replied on December 8, 2017 7:00 pm
0
Private comment
Hi. Sure. I hope. Many URS requirements focus on what the application should do. But, during the assessment and then validation phases, specifically when considering Data Integrity concerns, and especially when performing the risk assessment phase, there can be a shift to be as concerned about what a computerized system should not allow, what freedoms should be controlled, permitted only to certain user types, or that need a higher level of procedural oversight.

It might be more prudent to think from that ‘risk’ perspective earlier in the process, to ensure critical controls to limit functionality are included as User Requirements from the beginning, rather than as a later addition.
Marked as spam
Posted by Heather Longden (Discussions: 0, Comments: 4)
Replied on December 8, 2017 7:00 pm
0
Private comment
Indeed Heather - this is a good point. In the IEEE guidelines, they recommend a "Constraints" section, which I think would address your point nicely.
Marked as spam
Posted by Mark Denham (Discussions: 1, Comments: 6)
Replied on December 8, 2017 7:00 pm
0
Private comment
I have been using an “IT quality risk assessment” lately which consist of four steps:
Step 1 map the business process the system is to support, mark those activities that impact patient safety, product quality, and/or data integrity
Step 2 identify/define the IT functions required to support the identified activities (these inherit the impact from the business activity)
Step 3 determine the hazard of failure for each IT function, the root cause, proability of hazard, probability of detection, and finally the severity if hazard occurs
Step 4 Identify mitigating controls to reduce probability of failure or increase detectability; note these can be technical (e.g. goes into the URS), procedural, or validation activities (or a mix)
Further risk asssessment can be made on a requirement level.
Marked as spam
Posted by Martin Erik Larsen (Discussions: 0, Comments: 2)
Replied on December 9, 2017 7:00 pm
« Back to Previous Page