Risk Management in the (Bio)Pharmaceutical and Device Industry(Source:LabCompliance)

Introduction and Literature Overview

Risk-based compliance is expected by regulatory agencies and strongly recommended by industry task forces and private authors to balance compliance efforts and costs vs. product quality and patient safety. Risk management has a long history in the industry. For example, when car manufacturers have a quality problem with specific models in the market they will go through a thorough risk management process to decide whether to recall the cars or not. The cost of recalling and fixing the problem will be balanced against the cost that may potentially occur through not doing anything and the effect this would have on the company image and product liability issues.

Risk assessment is also nothing new in our private life. We experience this every day long before we start our daily work. Before we cross a busy road on the way to our workplace, we look left and right because there is a risk that a car may appear and run us over. By observing car traffic and stopping until the car has passed or looking for a pedestrian crossing or traffic lights we can eliminate the risk that the car will hit us.

Objectives and Principles of Risk Management

Risk management is the process that helps to identify problems, analyze them and then to create an action plan to avoid or manage these problems. The objective of risk management during pharmaceutical device and drug development and manufacturing is to provide drugs and devices that are efficient and safe without spending too many resources, for example, for validating processes and equipment.

All recommendations from official guidelines, from industry task forces and from private authors basically follow the same principles for risk assessment.

1. Identify the risks: What can go wrong?
2. Analyze the risks: What is the likelihood or probability that something goes wrong and what are the consequences or what is the severity if something goes wrong?
3. Estimate the risk priority number (RPN) and assess if the risk is acceptable or too high.
4. If the risk is too high develop and implement control steps to reduce or eliminate the risk.
5. Analyze the residual risk and assess if it is acceptable.

Let's look at the road traffic example we mentioned at the beginning and use the same steps as above.

1. Risk or unwanted event: Car runs over a pedestrian crossing the road.
2. Probability of occurrence: Depends on the road traffic - low for country roads, medium for town roads and high for city streets.
   Severity: Always high, because the accident may lead to permanent injury or death.
3. Risk level expressed by the risk priority number (RPN): Always high, because of high severity and some probability. The RPN increases from the country road to the city street due to increasing probability.
4. Control steps to reduce probability: Depends on the risk priority number.
   - Country road: Look left and right before crossing the road.
   - Town road: Use pedestrian traffic lights or a pedestrian crossing.
   - City street: Use pedestrian overpass or underpass.
5. Residual risk: Is acceptable because probability of occurrence has been reduced.

The effort to reduce the risk to an acceptable level increases with the risk priority number. This is a simple example, but illustrates the steps that are required to get safely across the road. The principles can be applied to most risk scenarios.

The person crossing the road does not follow a formal and documented process. She or he is using a practical approach which is only based on experience and common sense. This way we can define risk management for compliance as "well-justified and documented common sense". Official guidelines and standards such as ICH Q9, ISO 31000 and others have listed a couple of important principles for risk management.

Risk Assessment:

• Is an integral value of all organization processes, e.g., for compliance, security, health and safety.
• Is part of decision making, for example, whether to implement changes or not.
• Is systematic, structured and timely.
• Is based on the best available information, for example, on historical data and on science.
• Has the health and safety of patients in mind.
• Is aligned with a company's culture, strategies, risk profile and performance measures.
• Decisions should always be justified, documented and communicated to everybody affected by the project.
• Is an ongoing process to improve the efficiency of the organization.

Benefits and Issues for the Regulated Industry

The value of risk assessment for the regulated industry becomes obvious from the diagram in Figure 1. On the x-axis it shows the level of quality, validation or compliance of a product or process. The y-axis shows decreasing risk, decreasing additional value and increasing costs for validation and compliance.  

Figure 1: Risk Optimization vs. Quality and Cost

Doing nothing about compliance, quality or validation is a high risk, for example, you may receive warning letters from the FDA, or when looking at equipment, you may have high failure rates. Or even worse, patients may get sick if a drug has too many adverse impurities because of insufficient quality or validation of processes and systems. Of course, the advantage is that in this case there are no costs involved. When going to the right side of the diagram everything is validated and the most stringent interpretation is used for compliance and the costs get exponentially high. The risk decreases but so does the additional value, for example, from additional validation efforts. One of the tasks of a risk management project is to find an optimum which should be somewhere in the middle.

For each process or piece of equipment the company should decide how much risk can be taken. General recommendations should come from the Risk Management Master Plan or directly from management for a specific project. The question is how much risk a company can or will take, or what is the acceptable risk threshold. The answer depends on which direct impact equipment or a process has on the drug or device product. For example, when looking at the drug value chain from early research through preclinical and clinical development to manufacturing, the direct impact on consumers increases. Therefore, assuming everything is identical; the validation effort for equipment used in manufacturing will be higher than when the same equipment is used in early development.

Similarly one can argue that the validation efforts during quality control of an active pharmaceutical ingredient (API) can be lower than for finished drugs, because API quality problems can still be uncovered by the pharmaceutical manufacturer before the product reaches patients through incoming checks of the API and through quality control of finished drugs.

The main benefit of quality risk management is that the regulated industry can optimize resources towards high risk products, equipment and processes and save resources for low or no risk systems. This increases the overall efficiency and improves product quality and patient safety. While in the past the regulated industry hesitated in applying risk management, this changed since the United States Food and Drug Administration (FDA) started promoting quality risk management as part of its 21st century cGMP initiative along with some follow-up activities. In light of this, the word compliance can be eliminated from the x-axis in Figure 1, or at least, compliance is not always proportional to validation because with statements like: 'The type and extent of validation depends on the risk on the drug product', 100% compliance can be achieved at less than 100% validation.

The example used to illustrate the benefits of quality risk management also brings up issues. QA and other professionals may disagree that development activities and manufacturing of API's don't require the highest focus on quality and validation. This is a good point as long as we understand that risk management is always relative with objective criteria such as direct impact on product quality and patient safety. When looking at relative risks, quality control of finished products bears a higher risk than equivalent measures of API products or test samples from pre-clinical studies.

Objectives of the Tutorial

This tutorial addresses risk management in the (bio)pharmaceutical and medical device industry. It is intended to give project managers and other professionals from the (bio)pharmaceutical and medical device industry a good understanding of the objectives and principles of risk assessment and to guide them through the risk management process. Quality managers and staff as well as regulatory affairs professionals will also benefit through extensive discussions of relevant regulations, quality standards and guidelines. The tutorial will discuss tools and give strategies and specific recommendations for all steps of risk management such as risk identification, risk evaluation, risk assessment and mitigation controls.

In less than one day readers will get:

• An overview of regulatory and quality standard requirements and recommendations.
• Tools and common practices available for risk assessment and management.
• Strategies for implementation with practical help on how to document the outcome.
• Recommendations for special applications, e.g., for laboratory systems, software and computer validation, equipment maintenance and qualification and for process validation.

From our experience in attending risk management workshops and reading literature and Risk Management Master Plans and procedures we realized that there is little practical information available on how to identify, evaluate and document risks together with documentation of failures, hazards, possible harms and justification of risk priority numbers based on severity, probability of occurrence and probability of detection. It seems that most authors describe conceptual steps with little practical help. Also, official documents such as ICH Q9 don't give detailed information. This tutorial tries to fill this gap.

Literature Overview

Risk management for the (bio)pharmaceutical and device industry has been widely documented in regulatory guidance, by industry task forces and by private authors. This chapter lists some literature publications with relevance to risk assessment and management in the (bio)pharmaceutical and medical device industry.

• The European Council Directive 93/42/EEC of June 14 1993 Concerning Medical Devices (1) was one of the first regulatory documents that requested to eliminate risks as much as possible during the design and manufacturing of medical devices when weighed against the benefits to the patient.
• The US FDA Quality System Regulation (2) requested to validate the design of medical devices and that design validation should include risk analysis, as appropriate.
• The EU GMP Annex 15 for "Validation and Qualification" (3) requests a risk assessment approach to determine the scope and extent of validation and to evaluate the impact of the change of facilities, systems and equipment on the (medicinal) product including risk analysis.
• Risk-based compliance was an important element of the FDA's Pharmaceutical cGMP Initiative for the 21st Century in 2002 (4).
• Risk-based compliance was also a key component in the FDA's new approach for dealing with electronic records and signatures: 21 CFR Part 11 (5).
• Probably the single most important document related to risk management for the pharmaceutical industry is the ICH Q9 "Guide on Quality Risk Management" from 2005 (6). It describes a systematic approach for risk management and applies to drug development and manufacturing including laboratories.
• The World Health Organization Expert Committee on Specifications for Pharmaceutical Preparation published a paper entitled "Hazard and Risk Analysis in Pharmaceutical Products" (30). It provides general guidance on the use of Hazard Analysis and Critical Control Points (HACCP) to ensure the quality of pharmaceuticals.
• The Pharmaceutical Inspection Convention/Cooperation Scheme (PIC/S) gave an example of a methodology for implementing ICH Q9 in the pharmaceutical field (29).

Risk management is well known and practiced in many industries and several industry task forces have developed guidance documents that facilitate risk management.

• In 2001 GAMP published the "Guide for Validation of Automated Systems  (GAMP 4)" (7). Appendix M3 was dedicated to risk assessment. It mainly focuses on risk-based validation of computer systems.
• Its successor GAMP 5 was released in 2008 (8). The title: 'A Risk-Based Approach to Compliant GxP Computerized Systems' indicates that the entire guide is focused on risk-based compliance of computerized systems.
• The Global Harmonization Task Force (GHTF) has published a risk management guidance for the medical device industry titled: 'Implementation of Risk Management Principles and Activities within a Quality Management System' (9).
• In 2000 ISO published a standard 14971:2000: 'Application of Risk Management to Medical Devices'. Even though it was developed for medical devices the FDA also recommended the approach for pharmaceutical applications. The standard was updated in 2007 (10).
• In 2009 ISO released two more standards: ISO 31000 on "Risk Management Principles and Guidelines" (11) and ISO 31010 on "Risk Assessment Techniques" (12). Both standards are applicable to all industries.

Private authors and professional service providers have published papers with general recommendations for risk management which are also related to specific applications.

• R. Jones (13) gave an overview of risk management for pharmaceutical development and manufacturing with an introduction to risk assessment techniques and with focus on probabilistic risk assessment (PRA).
• Campbell (14) discussed how quality risk management principles can be applied to achieve a practical equipment verification strategy.
• Several authors contributed to a book: "Risk Management in the Pharmaceutical Industry" (34). The book includes introductory chapters on regulatory requirements and risk management tools followed by a total of six case studies.
• J.L. Vesper (33) authored a book titled: "Risk Assessment and Risk Management in the Pharmaceutical Industry: Clear and Simple". The book gives an overview of the risk management process and some of the more commonly used risk assessment methods and tools. It also examines how the various tools can be applied to identifying hazards and evaluating their potential impact and effects.
• Huber (15) applied the concepts of risk management to the validation of commercial off-the-shelf computer systems.
• K. O'Donnel and A. Green described a risk management solution designed to facilitate risk-based qualification, validation and change control activities within GMP and the pharmaceutical regulatory compliance environment in the EU in two parts. Part I (35) gave an overview on fundamental principles and design criteria outlined in the process and Part II (36) focused on tools, structure limitations, principle findings and novel elements.

Most literature publications give a general overview on risk management principles and also offer tools that help for easy implementation. For example, Labcompliance offers a "Risk Management Master Plan" (16), several SOPs (17-19) and case studies (20).

Regulations, Guidelines and Quality Standards

Regulatory agencies expect (bio)pharmaceutical risk management to assess risks associated with development and manufacturing of medicinal products. Industry and other task forces have developed guidelines and standards that help them better understand and implement risk management processes. This chapter gives an overview of the most important regulations, guidelines and quality standards.

United States Food and Drug Administration (FDA)

FDA 21 CFR 820: Quality System Regulation (2)

This regulation was released for medical devices in 1996. The regulation requires a risk-based design validation.

• §30(g): Design validation. Each manufacturer shall establish and maintain procedures for validating the device design. Design validation shall be performed under defined operating conditions on initial production units, lots, batches or their equivalents. Design validation shall ensure that devices conform to defined user needs and intended uses and shall include testing of production units under actual or simulated use conditions. Design validation shall include software validation and risk analysis, where appropriate.

FDA Guidance: General Principles of Software Validation (2002) (21)

The guidance was developed for validation of software used in medical devices. The FDA clearly spelled out the basic idea of risk-based compliance: The validation efforts should be commensurate with the complexity of the software design and the risk associated with the use of the software.

• This guidance recommends an integration of software life cycle management and risk management activities. Based on the intended use and the safety risk associated with the software to be developed, the software developer should determine the specific approach, the combination of techniques to be used and the level of effort to be applied.
• The selection of validation activities, tasks and work items should be commensurate with the complexity of the software design and the risk associated with the use of the software for the specified intended use.
• For lower risk devices, only baseline validation activities may be conducted. As the risk increases additional validation activities should be added to cover the additional risk.

Pharmaceutical cGMPs for the 21st Century: A Risk-Based Approach (4)

With this document the FDA introduced risk management to the pharmaceutical industry.

• Risk-based orientation: In order to provide the most effective public health protection, the FDA must match its level of effort against the magnitude of risk. Resource limitations prevent uniformly intensive coverage of all pharmaceutical products and production. Although the agency has already been implementing risk-based programs, a more systematic and rigorous risk-based approach will be developed.

FDA Guidance: Part 11, Electronic Records; Electronic Signatures - Scope and Application (2003) (5)

In this guidance the FDA documented the new approach for electronic records and signatures. They recommended basing the decision on how to implement key requirements of Part 11 on a justified and documented risk assessment.

• We recommend that you base your approach on a justified and documented risk assessment and a determination of the potential of the system to affect product quality and safety and record integrity.
• We recommend that your decision on whether to apply audit trails should be  based on "a justified and documented" risk assessment.

FDA Guidance: Quality Systems Approach to Pharmaceutical CGMP Regulations (2006) (22)

Risk management is one of the focuses of this guidance. Risk-based approaches are expected to be used for setting specifications and process parameters, qualification of personnel, selection of quality unit (QU) personnel and for supplier auditing.

• Quality risk management is a valuable component of an effective quality systems framework. Quality risk management can, for example, help guide the setting of specifications and process parameters for drug manufacturing, assess and mitigate the risk of changing a process or specification and determine the extent of discrepancy investigations and corrective actions.
• In a quality system, personnel should be qualified to do the tasks that are assigned to them in accordance with the nature of, and potential risk of, their operational activities.
• Although QU personnel should not take on the responsibilities of other units of the organization, these personnel should be selected based on their scientific and technical understanding, product knowledge, process knowledge and/or risk assessment abilities to appropriately execute certain quality functions (This quality systems feature is also found in the cGMP regulations, which identify specific qualifications, such as education, training and experience or any combination thereof (see 211.25 (a) and (b)).
• The quality systems approach also calls for periodic auditing of suppliers based on risk assessment.
• Although the cGMP regulations (211.180(e)) require a product review at least annually, a quality systems approach calls for trending on a more frequent basis as determined by risk.
• As with other procedures, audit procedures should be developed and documented to ensure that the planned audit schedule takes into account the relative risks of the various quality system activities, the results of previous audits and corrective actions, and the need to audit the complete system.

European Regulations

The Council Directive 93/42/EEC of 14 June 1993 Concerning Medical Devices (1) requires a risk-based design and manufacture validation and reducing risks to acceptable levels.

• The devices must be designed and manufactured in such a way that when used under the conditions and for the purposes intended, they will not compromise the clinical condition or the safety of patients, or the health and safety of users or, where applicable, other persons, provided that any risks which may be associated with their use constitute acceptable risks when weighed against the benefits to the patient and are compatible with a high level of protection of health and safety.
• The solutions adopted by the manufacturer for the design and construction of the devices must conform to safety principles, taking account of the generally acknowledged state of the art.
  In selecting the most appropriate solutions, the manufacturer must apply the following principles in the following order:
  - Eliminate or reduce risks as far as possible (inherently safe design and construction).
  - Where appropriate take adequate protection measures including alarms if necessary.
  - In relation to risks that cannot be eliminated, inform users of the residual risks due to any shortcomings of the protection measures adopted.

Annex 15 to the EU GMPs Validation and Qualification (3) has legal status. It uses risk-based approaches to validation and for changes to facilities, systems and equipment.

• A risk assessment approach should be used to determine the scope and extent of validation.
• The likely impact of the change of facilities, systems and equipment on the product should be evaluated, including risk analysis.

Annex 11 to the EU GMPs Using Computerized Systems (23) requires to base controls for computerized systems on a justified and documented risk assessment. Once finalized the Annex will have legal status.

• Extent of validation and data integrity controls should be based on a justified and documented risk assessment.

Pharmaceutical Inspection Convention/Cooperation Scheme (PIC/S)

The PIC/S Good Practices Guide on using Computers in GxP Environments (24) was developed for inspectors but it is also a good source document for user firms. Risk-based approaches are recommended throughout the life of a computer system.

• For GxP regulated applications it is essential for the regulated user to define a requirement specification prior to selection and carry out a properly documented risk analysis for the various system options.
• The inspector will consider the potential risks as identified and documented by the regulated user, in order to assess the fitness for purpose of the particular system(s).
• This risk-based approach is one way for a firm to demonstrate that they have applied a controlled methodology to determine the degree of assurance that a computerized system is fit for its purpose. It will certainly be useful evidence for consideration by an inspector.
• Regulated users should be able to justify and defend their standards, protocols, acceptance criteria, procedures and records in the light of their own documented risk and complexity assessments, aimed at ensuring fitness for purpose and regulatory compliance.
• The business/GxP criticality and risks relating to the application will determine the nature and extent of any assessment of suppliers and software products.
• The URS should also form the basis for a risk assessment of the system for GxP compliance requirements, in addition to other risks such as safety. The risk analysis may be based on the FS, which is related to the URS (e.g. for bespoke systems). The risk assessment and the results including the reasons for the ranking as either: 'critical' or 'non-critical' should be documented. The nature of any GxP risks should be clearly stated.
• The risk analyses and the results, together with reasoning for critical or non-critical classifications should be documented. Risks potentially impacting on GxP compliance should be clearly identified.
• Inspectors will be interested in the company's approach to identifying GxP risks and the criteria for assessing the fitness for purpose of the system application.

An informal Working Group within PIC/S has developed an objective and pragmatic example of methodology for implementing ICH Q9 (29). The document is useful for training purposes and will not have an impact on PIC/S inspections.

United States Pharmacopeia (USP)

USP develops methodology for specific applications and general chapters on different analytical aspects for FDA regulated industry. Most recently published final and draft chapters recommend risk benefit approaches for testing and using solvents.

• <232> Elemental Impurities (Proposal)
  The presence of unexpected elemental contaminants, as well as that of impurities likely to be present, should be considered in determining compliance and planning the risk-based extent of testing.
• <467> Residual Solvents
  Solvents that are known to cause unacceptable toxicities should be avoided in the production of drug substances, excipients or drug products unless their use can be strongly justified in a risk benefit assessment.

International Conference for Harmonization

ICH Q9: Quality Risk Management (6) is the single most important reference document for risk management for the pharmaceutical industry. ICH focuses on scientific knowledge and the link to the protection of the patients as a primary principle. The guide also gives recommendations for implementation.

• Two primary principles of quality risk management are:
  - The evaluation of the risk to quality should be based on scientific knowledge and ultimately linked to the protection of the patient; and
  - The level of effort, formality and documentation of the quality risk management process should be commensurate with the level of risk.
• It is neither always appropriate nor always necessary to use a formal risk management process (using recognized tools and/or internal procedures e.g., standard operating procedures). The use of informal risk management processes (using empirical tools and/ or internal procedures) can also be considered acceptable.

ICH Q9 has been adopted by the European Union and PIC/S in Annex 20 of the EU and PIC/S GMP Guides.

International Organization for Standardization (ISO)

ISO currently has three standards related to risk management: 14971 for medical devices and 31000 and 31010 which are for general purpose risk management projects. ISO 31000 describes principles and guidelines and 31010 risk assessment techniques.

ISO 14971:2007 - Application of Risk Management to Medical Devices (10)

This document was developed for medical devices but has also been recommended by FDA officials for pharmaceutical industry.

• This International Standard specifies a process for a manufacturer to identify the hazards associated with medical devices (including in vitro diagnostic (IVD) medical devices), to estimate and evaluate the associated risks, to control these risks and to monitor the effectiveness of the controls.
• The requirements of this International Standard are applicable to all stages of the life cycle of a medical device.
• This International Standard does not apply to clinical decision making.
• This International Standard does not specify acceptable risk levels.
• This International Standard does not require that the manufacturers have a quality management system in place. However, risk management can be an integral part of a quality management system.

ISO 31000:2009 - Risk Management - Principles and Guidelines (11)

• This International Standard provides principles and generic guidelines on risk management. It can be used by any public, private or community enterprise, association, group or individual. Therefore, this International Standard is not specific to any industry or sector.
• This International Standard can be applied throughout the life of an organization and to a wide range of activities, including strategies and decisions, operations, processes, functions, projects, products, services and assets.
• This International Standard can be applied to any type of risk, whatever its nature, whether having positive or negative consequences.
• Although this International Standard provides generic guidelines, it is not intended to promote uniformity of risk management across organizations. The design and implementation of risk management plans and frameworks will need to take into account the varying needs of a specific organization, its particular objectives, context, structure, operations, processes, functions, projects, products, services or assets and specific practices employed.
• It is intended that this International Standard be utilized to harmonize risk management processes in existing and future standards. It provides a common approach in support of standards dealing with specific risks and/or sectors and does not replace those standards.
• This International Standard is not intended for the purpose of certification.

ISO 31010:2009 - Risk Assessment Techniques (12)

• This International Standard is a supporting standard for ISO 31000 and provides guidance on selection and application of systematic techniques for risk assessment.
• Risk assessment carried out in accordance with this International Standard contributes to other risk management activities.
• The application of a range of techniques is introduced, with specific references to other International Standards, where the concept and application of techniques are described in greater detail.
• This International Standard is not intended for certification, regulatory or contractual use.
• This International Standard does not provide specific criteria for identifying the need for risk analysis, nor does it specify the type of risk analysis method that is required for a particular application.
• This International Standard does not refer to all techniques and omission of a technique does not mean it is not valid. The fact that a method is applicable to a particular circumstance does not mean that the method should necessarily be applied.

Approaches for Risk Management

Alternatives

Risk management can be very simple and straightforward but it can also be quite complex. For example, risk assessment of equipment can be documented in just one paragraph with a simple statement such as: The risk level is low because the equipment does not have any impact on the quality of the finished product. For a more complex computer system used in pharmaceutical manufacturing, a full risk management may require an assessment of the criticality of each function with a need for testing if the function has a high impact on the system performance.

Similarly the vendor risk can be justified and documented on a single page if the vendor meets all criteria as required for low risk vendors. This does not take more than five to ten minutes. On the other hand a full risk management for a pharmaceutical development or manufacturing process can take quite some time and can fill one hundred pages or more. Whether the process and documentation is simple or complex it is always most important that it follows a formal procedure and that the outcome and conclusion are justified and documented. The risk management process as applicable to the (bio)pharmaceutical and device industry has been described in several official publications, for example ICH, GHTF and ISO (6, 9 and 10) and by private authors. All proposals for risk management include steps such as risk initiation, risk assessment and evaluation, risk mitigation and control and risk communication and review. This chapter outlines the ICH Q9 process and gives recommendations for estimating severity and probability.

The ICH Process

ICH Q9 is the most authentic document for risk management in the (bio)pharmaceutical industry. The guide describes quality risk management as a systematic process from the assessment, control, communication and review of risks to the quality of the drug along the product life cycle. The guide also outlines an example model for quality risk management but includes a statement that other models are also possible. The example model is illustrated in Figure 2.

Risk management projects can be proposed by anybody in an organization whenever there is a need for such a project and the proposal is justified. The proposal should describe any problem with background information and examples for data on potential hazards and harms.

Figure 2: Risk Management Process According to ICH Q9

The project is reviewed, approved and supported by management. Management also identifies a project owner who, with the help of affected department managers, assembles a risk management project team. The team develops a risk management project plan with information on process steps, required resources, tasks, deliverables and responsibilities. The plan should also include a preliminary timeline.

In the risk assessment phase the team identifies hazards and harms and evaluates severity and probability based on criteria as defined in the company's Risk Management Master Plan.

Questions team members should ask are:

• What might go wrong?
• What is the likelihood (probability) that it will go wrong?
• What are the consequences (severity) if something does go wrong?

The outcome from this phase is a group of risk priority numbers (RPNs) calculated from severity and probability. Alternatively ICH permits a qualitative description of the terms, for example 'high', 'medium' or 'low'. The qualitative description or risk number can be compared with risk acceptance criteria as generally defined in the Risk Management Master Plan or by management specifically for the project. If the risk number or corresponding qualitative description exceeds the acceptable risk this is reduced. After reduction the residual risk is evaluated again and accepted if the resulting risk is lower than the acceptable risk.

The outcome of the risk management process is communicated to all decision makers and any others who might be affected by this process. The process is reviewed for existing and possible new hazards on an ongoing basis. For example, new hazards may be identified or the defined level for probability may change. Everybody affected by the project is encouraged to actively monitor the process and give feedback for possible updates.

Criteria for Severity, Probability and Risk Acceptance

Defining a process and objective criteria for severity (S) and probability (P) and criteria for risk acceptance is most important for risk assessment. Neither international standards nor regulatory guidance documents require that a particular method is used. Severity in general means: How big is the problem if it occurs? Probability means: What is the likelihood that a problem occurs? For each identified hazard the probability and severity factors are estimated and associated to different categories. The number of categories is usually 3, 5 or 10 but can be any number up to or more than 10. ICH does not give any preference. The company's risk management should give recommendations on how to decide how many levels should be used. The number can be fixed in the master plan for all projects or you can allow two or three options. For example, the final number for a specific project could be dependent on the confidence of the estimates.

The first part of this chapter suggests a procedure to estimate severity, probability and the overall risk of an identified hazard. The second part has recommendations on how to define objective criteria and a process for assigning levels for probability and severity.

Procedure for Estimating Probability and Severity

The scales can be qualitative, quantitative or semi-quantitative. Unless there are thorough statistical or other reliable data available, the scales should be defined as qualitative. An example for a qualitative description of probability would be 'high', 'medium' or 'low'. Equivalent semi-quantitative expressions would be, for example, 'once a day', 'once a week' or 'once a month'. Figure 3 shows more examples for qualitative and semi-quantitative descriptions for severity and Figure 4 shows equivalent examples for probability.

Qualitative	Semi-Quantitative	Quantitative
Very high	Frequent Likely to happen	Every day
High	Probable	Every 3 days
Medium	Occasionally	Every week
Low	Can happen	Every 3 weeks
Very low	Improbable	Every 2 months

Figure 3: Examples for Qualitative, Semi-Quantitative and Quantitative Risk Categories for Probability

Qualitative	Semi-Quantitative
Very high Catastrophic	Death or permanent injury Loss > $50 million
High Critical	Injury for up to 1 month Loss $10-50 million
Medium Serious	Temporary injury for 2 days requiring professional medical treatment Loss $2-10 million
Low Minor	Temporary injury for 2 days not requiring professional medical treatment Loss $500 thousand / $2 million
Very low Negligible	Temporary discomfort for 2 days Loss < $500 thousand

Figure 4: Examples for Qualitative and Semi-Quantitative Risk Categories for Severity

Probability of detection has also been suggested as a risk measure. This is an option but it is not a must. One can argue that severity factors increase if the probability of detection is low. It should be considered under specific conditions to decide whether the risk could be included or not.

It is most important to make the risk analysis and evaluation as objective as possible. A frequent mistake is that individual members tend to rate everything as high risk. One way to ensure objectivity across an organization is to take assessment criteria and examples for severity from the corporate Risk Management Master Plan. The probability data should be derived from available empirical data of the same or similar systems or processes. If such data are not available then the most unfavorable situation should be used for the initial risk assessment.

Documentation of the severity factors should include a scientific justification. After all the risks have been discussed and rated, the team reviews them for relative comparison. Adjustments should be made for RPNs that are considered to be out of order.

Graphical Determination of the Overall Risk

After values for severity and probability have been assigned, the overall risk is determined. This can be done graphically as shown in Figure 5. Severity levels low, medium and high are drawn as columns and probability as rows. All cells in green are low risk, in yellow medium risk and cells in red are defined as high risk.

Figure 5: Graphical Determination of Risk

The equivalent graph including detectability is shown in Figure 6. Risk as identified in Figure 5 is drawn using detectability as columns starting with high on the left.

Figure 6: Graphical Determination of Risk including Detectability

 

Determination of the Overall Risk with Risk Priority Numbers

Levels for severity as described before can be converted to numbers, for example 'low' becomes a 1, 'medium' a 2 and 'high' a 3. This is especially convenient for assigning the risk for routine applications for the determination of the overall risk.

Risk priority numbers (RPNs) are calculated from severity and probability levels using the formula:

RPN = Severity (S) x Probability (P)

Risk (RPN) is expressed as the multiplication of severity with occurrence:

RPN = S x O.

In the example in Figure 5 the RPN can go from 1 in the left lower cell to 9 in the right upper cell. RPNs from 1 to 2 are equivalent to low, 3 to 5 are medium and 6 to 9 are high risk.

This procedure is much more flexible than the graphical determination. For example, for specific situations weight factors can be added to probability and/or severity. In this case the formula could look like:

RPN = 2S x P

This means the impact is double weighted compared to probability.

Another advantage of using numerical values is that multiple risk types can easily be combined. For example, non-patient related business risk can be combined with patient risk using the formula:

RPN = S x (P (Business) + S x P (Patient))

Again weight factors can be added, for example, if the patient risk is considered to be more important than non-patient related business risks.

This procedure also easily allows using detectability as a contributing factor to the overall risk. But first, categories for the detectability have to be assigned. Then categories have to be converted to numbers. The resulting formula is:

RPN = S x P x 1/D

Working with calculated numbers is very easy but unless there is a good description about the meaning they don't tell us anything about the absolute risk. This could cause problems when values for severity, probability and detectability are initially assigned. Therefore, a good practice is using qualitative or quantitative descriptions during initial ranking and then allocating numbers to the descriptions.

Estimating Severity of Potential Harms

There are several factors that contribute to the severity of potential harms in the (bio)pharmaceutical and device industry. The final ranking is derived from individual factors. ICH Q9 recommends using patient safety as the main criterion and basing the decision on estimating levels on a scientific judgment.

Factors contributing to severity typically include:

Impact on Product Quality

The question here is if the potential harm has a direct impact on product quality, which means that any failure cannot be corrected before a new drug or a device product is approved for marketing or before a batch is released for shipment. In this case the probability of detecting the problem is low or zero. An example is an analysis system used in a quality control laboratory where analysis results are used as criteria whether to release a batch or not.

Impact on People's Health and Safety

Poor product quality as discussed in the previous paragraph only plays an important role if the poor quality can have an adverse impact on consumers. This directly turns into health effects for patients. An example for high severity is when poor product quality can cause sickness that requires treatment in a hospital.

Impact on Business Continuity

This is related to a company's ability to timely market a new product and reliance on the system and process uptime for continuous shipment of products. The answer for the level comes from the question: How big is the loss in $ due to delays in new product approval or shipment stoppages?

Impact on Compliance

This is related to the risk of failing regulatory inspections and receiving single or multiple warning letters or inspectional observation reports. Consequences can be shipment stops, substantial amounts of reengineering to fix problems and resources to implement corrective actions.

There are other indirect factors like claims by end-users, product liability issues, product recalls and a company's reputation, e.g., if problems with product quality or compliance become public.

Estimating Probability of Potential Harms

Probability should answer the question: What is the likelihood that an identified hazard occurs? Probability should be expressed in occurrence per time. The main source for reliable probability data is experience with the same or similar process or system. One important point is that we should look at the circumstances and complete sequence from the occurrence of the hazard through to the occurrence of the harm. A specific hazard may not always cause harm.

The probability should be estimated by subject matter experts. Possible sources of data are:

• Historical data from using the same process or system.
• Historical data from using a similar process or system.
• For equipment and systems: Information from the vendor, for example, reliability estimates, costs for guaranteed uptime and extended warrantee.
• Initial production data.

Sources can be used individually or jointly. Preferably multiple sources should be used to increase the confidence level.

Estimates are very difficult to make when no historical data are available. As a workaround you can ask if within the same company either at the same or other sites adequate data are available. Even if the information cannot be copied 100% you can look at similarities and differences and add uncertainties accordingly.

Most critical is the situation for new systems. In this case estimates from the supplier can be used to judge what could possibly go wrong. However, this requires having a very good relationship based on trust with the supplier.

If no data are available the probability level should be based on the worst case estimates.

Risk Threshold

The risk threshold is a measure on how much risk a company is willing to take. It is expressed on a scale of very low risk tolerance to very high risk tolerance. A low risk threshold means a company is not willing to take a risk and a high threshold means the company is willing to accept a lot of risk. The RT is proposed by the project team for each risk management process and should be approved by management. For example, when looking at computer system validation the risk threshold is higher for a system used in early product development than when the same system is used in manufacturing control. Similarly processes used in API manufacturing can take higher risk factors than processes for manufacturing of drugs because of additional quality control of finished drugs that can also recover quality problems of APIs. Recommendations on how to apply the RT and examples should be documented in the Risk Management Master Plan.

Figure 7: Risk Priority Number vs. Risk Threshold

The relationship between the RPN and the RT is shown on two examples in Figure 7. On a scale of 0 to 10 the risk factor is determined as approximately 6. In Example 1 this RPN is higher than the RT (approximately 3) which means it should be reduced to below 3. In Example 2 the RPN is lower than the RT, so it is acceptable. This procedure requires that the RPN and RT numbers should be normalized to exactly the same range.

Tools and Methodologies for Risk Management

Tools are important to make the entire risk management process efficient and consistent. They can be as simple as templates in Microsoft Word or Excel that can be filled out by risk management team members and other individuals to identify hazards and harms and to justify and document risk priority numbers and mitigation steps. Tools can also include software to guide risk management professionals through the full risk assessment process. The most well-established formal tools for risk assessment are: Failure Mode Effect Analysis (FMEA), Fault Tree Analysis (FTA), Preliminary Risk Analysis (PRA), Hazard, Hazard Operability Analysis (HAZOP) and Hazard Analysis and Critical Control Points (HACCP). Formal tools can be categorized into deductive and inductive tools. Inductive techniques answer the question: What if something bad happens? Deductive techniques look at a specific problem and answer the question: What caused it to happen? An example for an inductive tool is FMEA and an example for a deductive tool is FTA.

While these formal tools often proved to be efficient and reliable in risk assessment and risk control of specific projects, a systematic use of these tools to address all areas with requirement for risk assessment would generally be incompatible with existing resources. ICH Q9 also has a comment about using tools: "It is neither always appropriate nor always necessary to use a formal risk management process (using recognized tools and/or internal procedures e.g., standard operating procedures). The use of informal risk management processes (using empirical tools and/or internal procedures) can also be considered acceptable". While in the past more empirical tools have been used there is a tendency nowadays to use more established formal tools.  

All tools, whether they are simple or complex have one disadvantage: They do not replace subject expert knowledge! The output is only as good as the input. Most important is that inputs should not only come from single individuals but also from a risk management team that has all the required knowledge and expertise. 

This chapter will describe some of the most frequently used tools. The first section describes examples of informal tools that are mainly used to document experience. They include tables, templates, forms and examples and also a Risk Management Master Plan, internal procedures, a risk database and software tools. In the second part of the chapter we describe and move on to more sophisticated and well-established methodologies. Figure 8 lists some of the most well-known methodologies with advantages and limitations.

	FTA	FMEA / FMECA	HACCP	PHA / PRA
Principle	Graphical, deductive, structured tool.	Structured inductive tool, can be qualitative and quantitative.	Prevent known hazards to reduce risks at specific CPs.	Qualitative inductive tools.
Advantages	Visual fault tree diagrams with standardized symbols to show the pathway from basic events to the undesired event.	Very universal and scalable, e.g., for high level and detailed risk assessment.	Full risk management process. Specific and flexible. Focus on prevention. Record keeping answers product liability and compliance questions.	Easily adaptable to most situations.
Limitations	Can quickly become very complex because it looks at one failure at a time.	Tool does not consider operational issues or operator performance. Does not show interaction between events.	Requires detailed information on the product and process.	Relative unstructured, therefore may miss potential hazards.
Tool	Graphics with standardized symbols. Dedicated software recommended.	Tables.	Detailed process diagrams. Tables.	Drawings and tables.
Main Application and Use	Used to define a particular undesired event and identify its causes (basic events). For potential problems with serious impact.	Universal use, e.g., medical device, hospitals. Used to identify known and potential failure modes and impact on processes, facilities and equipment. Used during design and operation.	Food and chemical industry. Adapted for pharmaceutical industry by WHO. Covers full product chain.	Used early in new products and changes in products and processes (design phase). Chemical industry. First step of complex risk assessments.

Figure 8: Formal Risk Management Methodologies

Informal Tools

Informal tools are simple and easy to use. They are recommended for processes that are not so complex and if there is not much experience with risk assessment within a company. They are useful to make all risk assessment and management processes consistent and effective. They are also quite useful to generate preliminary documentation which is used when making the decision to stop or when moving a risk management project forward to a more detailed risk management using established methodologies.

The Importance of a Generic Risk Management Master Plan

One of the biggest challenges in risk management is to make assessment objective which means make it independent from subjective opinions of individuals who may look at risk from just one angle. Legislation does not give any solution to this specific problem and different risk methods as well as private authors give different answers to the problem.

For example, recommended numbers for probability range from 0 to 1, to 5 or to 10 and severity can vary from 1 to 3, 5 or 10. Some methods include "detectability" or "discovery probability" in the formula and there is even inconsistency in the formulas used for calculation. The subjectivity problem has also been brought up by ICH Q9: Each stakeholder might perceive different potential harms, place a different probability on each harm occurring and attribute different severities to each harm.

However, while it may be very difficult to get a common understanding across the industry on the formal process and criteria to assess a risk, it should be possible to get this understanding within a company. The outcome of the same risk assessment process should be consistent within a company, no matter who is doing it.

Master plans in general are excellent tools to get a common understanding on specific topics. For example, validation master plans are well accepted and frequently used to ensure consistency and effectiveness of validation projects. Risk Management Master Pans with specific examples are even more important to also ensure objectivity for criteria such as severity and probability. As such a Risk Management Master Plan provides a framework and practices for risk management of processes and equipment. It also ensures that risk assessment and controls are carried out efficiently and consistently throughout the organization as well as meeting regulatory, customer, quality and business requirements. The plan should ensure that the company's risk management procedures are based on science and that they are understood and followed throughout the organization.

The risk management document is the first and most important document that should be available when starting individual risk management processes. It is the basis of individual Risk Management Project Plans and is the reference document for all risk management projects, no matter which risk management methodology is used.

This master plan describes:

• The company's risk management policy.
• The links between the company's organizational objectives and policies and the risk management policy.
• Relationship of the risk management plans with other documents, e.g., validation master plans or quality manual.
• The approach to the company's risk management process.
• Members of risk management teams (by function).
• Responsibilities of the project leader and team members.
• Products and processes that should be covered by risk management.
• Contents of individual Risk Management Project Plan.
• Detailed steps for risk management.
• How the likelihood is defined.
• How to identify risk levels.
• Factors contributing to high and low severity.
• Definition and determination of RPNs with examples.
• Criteria and examples for acceptable risk thresholds.
• How to make a high-level risk assessment.
• Communication of project status and outcome of risk management processes.
• Frequency and procedures for ongoing review.

The Risk Management Master Plan should be developed by a cross-functional team at the highest level possible. Preferably the corporate QA department should own the project and also ensure that the concepts are implemented for individual quality risk management projects.

Procedures

Step-by-step procedures should be developed for initiating, implementing and updating individual application-specific risk management projects. Examples are risk-based supplier assessment, risk-based computer system validation or risk-based testing of starting materials for drug manufacturing. Development and use of such procedures should be controlled by corporate quality assurance to ensure consistent use throughout the organization.

Templates and Forms

Templates and forms with examples and process flow charts are simple but valuable tools to improve consistency and efficiency for risk identification, evaluation and control. They can be part of SOPs or the Risk Management Master Plan or they can be individual documents. Examples are specifically important to give advice on ranking risk elements such as probability, detectability and severity.

Examples and Case Studies

As organizations gain experience with risk management projects and after several projects have been executed, a library with representative examples should be developed. The examples help risk management project managers and teams to identify, evaluate and control risks. The library should include both good and bad examples. Each example should include recommendations on how to proceed with similar projects.

Checklists

Checklists are lists of hazards, possible harms and controls that have been developed from experience either as a result of previous assessment projects or as a result of past failures or from daily product or process support. For example, the IT help desk can generate such a list for various computer systems. The value of checklists is not to forget common important hazards and control steps.

Risk Database

A corporate database with examples for risk hazards and harms within a company helps to facilitate the collection and maintenance of risk data. Relative risk priority numbers for severity and probability and mitigation steps also help to harmonize assessment within a company. While initially there may be no or very little data, such a database will provide increased value over time when databases are populated with data from more risk management projects.

Software for Risk Assessment and Risk Management

To be added later

Failure Modes, Effects and Criticality Analysis (FMECA)

Failure Modes and Effects Analysis (FMEA) evaluates a product process for strengths and weaknesses, for potential problem areas, risks or failure modes and prevents failures before they occur. FMECA adds evaluation of the criticality including severity, occurrence and detectability and tries to answer the questions:

•  How can a product or process fail?
•  What is the likelihood that it fails and if so, what is the likelihood that the failure will be detected? and,
•  What will be the effect on the rest of the process or system if a failure occurs and is not detected such that it can be corrected?

FMEA has the highest impact and should be performed during design or development of a product or process when failures are less expensive to address. It can be a powerful tool to improve product reliability and reduce design, development and manufacturing costs. FMEA is a bottom up approach to failure mode analysis. It can be used to evaluate failures that can occur when designing or running a process, or when designing, developing or operating equipment. FMEA helps to design and manufacture a trouble-free product. Identified failures in a product or process are corrected before they occur to ensure trouble-free functioning and operation.

Applications

FMEA and FMECA are the most generic risk management methodologies and can be applied to a large variety of applications.

For example, they can be used during design and manufacturing of equipment as well as to set up and optimize qualification and maintenance plans for equipment. During design FMEA can help to select the best design alternative and improve the design of procedures and processes. Both methodologies are also used as a preliminary screening method for complex risk management before the project is moved forward to more time-consuming methodologies.

Advantages and Limitations

FMEA and FMECA have many advantages. They include:

•  Wide applicability from design to manufacturing, servicing and maintenance of mechanical and electronic equipment.
•  Identifies failure modes, their causes and effects on the system.
•  Ideal for simple to medium complex systems.

Limitations include:

• Optimized for single individual failure modes, but they don't work well for combinations of failure modes.
•  Can be time-consuming for complex systems.

Assessment Process

FMEA and FMECA require a very good knowledge of the product or process. The assessment process is the same as described in Figure 10.

1. Select a team and team leader. All team members must be subject matter experts.
2. Select the FMECA form from the company's Risk Management Master Plan or if not available, create one.
3. Train team members on the process and on criteria for ranking likelihood of occurrence and impact of failure when it occurs.
4. Make the team members familiar with the design of the product or process to ensure that all team members have the same understanding. This can be through distributing product and process documentation supported by flow diagrams.
5. Set up one or more brainstorming meetings. Multiple sessions are recommended for complex product/process designs. Individual sessions can focus on subsets of the entire product/process.
6. Brainstorm the product or process design for possible failures. Document the outcome on a flipchart.
7. Sort all suggested failures by categories.
8. Combine or remove similar or duplicate entries.
9. Document potential effects on the system, subsequent operation and end user (e.g., patient).
10. Assign rating factors for each identified severity, occurrence and detectability. Definition and scale of rating factors should be taken from the company's Risk Management Master Plan not only to ensure objectivity and consistency with the project team but also with other risk management projects. Justify the rating with reference to the plan. For occurrence, historical data from the same or similar projects can be used.
11. For each identified effect list all possible causes of failures with justifications and with all uncertainties.
12.  Calculate the risk priority number using the formula from the Risk Management Master Plan. The RPN is a measure for the overall risk associated with the project.
13. Take actions to reduce potential critical risks.
14. Assign owners, a schedule and deliverables for the actions.
15. After the action has been implemented make a new rating for severity, occurrence and detection and calculate the RPN.

In the brainstorming meeting the risk management team identifies all possible failures. Most important for new products and processes is information from the engineers who have designed the product or process even though they may hesitate in admitting that failures may occur. For products that have been in use for some time the user of the products and support engineers are excellent resources. They can not only provide good information on which failures may occur but they can also predict the likelihood of occurrence and the severity of a failure.

The overall risk number is calculated from the probability and severity and the decision is made on which potential failures require risk reduction. Possible follow-up actions could be redesign of products or processes such that either the probability of occurrence or severity factors are reduced such that the overall risk priority number is also reduced.

Fault Tree Analysis (FTA)

Fault Tree Analysis is a deductive tool that assumes a failure of the functionality of a product or process. It can be used as a qualitative and quantitative structured tool. It is used to define a particular event and identify its causes. Results are graphically visualized in a tree of fault modes and this is where the name comes from. The diagrams can be used to identify the pathways from the base events to the undesired events. The methodology is particularly useful to examine problems with equipment, facilities and operational conditions.

FTA identifies the potential root cause(s) ('basic events') of the specific problem or hypothetical event. Problems can be caused by design and engineering defects and also by human factors. When it is unlikely that the root cause is not just based on single-base events, 'cut sets' of all scenarios can be defined which can cause the top event.

Advantages and Limitations

FTA has advantages and limitations.

Advantages are:

• Highly systematic but also flexible.
• The 'top-down' approach focuses attention on the failure effects which are directly related to the top event.
• Useful for analyzing systems with many interfaces.
• Pictorial representation helps to easily understand the system behavior.

Limitations are:

• Uncertainties in the probability of the base events are included in the calculations of the probability of the top event.
• The static model does not address time interdependencies.
• Fault trees can only deal with binary states (failed/not failed).

Steps for FTA Analysis

Steps for FTA analysis include:

1. Form a Team and Determine a Team Leader

Team members should be experts in the application, and either have knowledge and experience in FTA methodology or get trained; with emphasis on how to interpret standardized symbols used in a flow chart.

2. Definition of a Problem and Justification of the Project

Define the event or describe what it is that should be prevented. Because the amount of work for a complex FTA analysis can be significant, the primary reason for the project should be well justified. The definition should also clearly describe the scope and boundaries of the project. Most important is to clearly define the top event and to keep it in line with the project scope.

3. Construction of the Fault Tree

After team members have acquired all the information about the process, list all possible root causes that could lead to the unwanted event. These "basic" events are linked through "intermediate" events to the top event in a flow chart. For the connection between top and basic events defined logical pathways should be used. A basic event can cause the unlikely event (top event) on its own or in combination with others (cut sets).

4. Evaluate the Fault Tree

This step prioritizes basic events based on probability data. That kind of prioritization is only useful if such data are available.

5. Prepare a Report

The report should include a description and scope of the project, a system description, all relevant process flow diagrams, fault tree analysis listings and the FTA flow chart. It should also include a conclusion of the analysis related to the original question.

Hazard Analysis and Critical Control Points (HACCP)

The Hazard Analysis and Critical Control Points (HACCP) method originated from a food management system. The objective is to ensure food safety through identifying and preventing known hazards and risks as they may occur at specific points in the food chain. As such it is a systematic method for identification, assessment and control of safety hazards. The methodology is not limited to the food industry and has also been suggested for the pharmaceutical, chemical, aviation and car industry. In the scope of this methodology hazards are defined as biological, chemical or physical agents or operations that are likely to cause illness or injury if not controlled. The purpose of HACCP in the pharmaceutical manufacturing process is to ensure products with quality as specified that are efficient and safe for use. GMPs and HACCP are not contradictory but rather complementary. Implementation of Good Manufacturing Practices is facilitated through HACCP methodology whereas a GMP environment with well-structured procedures facilitates implementation of HACCP.

HACCP Principles and Methodology

HACCP principles and methodology are very well standardized which facilitates training and applying the HACCP system. The system addresses all steps from raw material production, procurement and handling, to manufacturing, distribution and consumption of the finished product. HACCP principles were defined by the National Advisory Committee on Microbiological Criteria for Foods (NACMCF) in 1992. The document was reviewed and updated by the Committee in 1997 (32) and as a result HACCP was defined as a "systematic approach to evaluate, identify and control food safety hazards". The HACCP system is based on seven principles:

1. Conduct a hazard analysis.
2. Determine critical control points (CCPs).
3. Establish critical limits for each CCP.
4. Establish a monitoring system for the CCPs.
5. Establish corrective actions when the CCP is not under control.
6. Establish verification procedure to confirm HACCP is working effectively.
7. Establish documentation concerning all procedures and records on these principles and their application.

Figures 9 show a flow diagram with steps for implementation of the HACCP analysis. Some preparation work is needed before the hazard identification and analysis start.

Preliminary Task

1. Develop a HACCP Plan

After the project has been initiated by management and after management has defined a project leader a preliminary plan is drafted by the project leader. It should be product or process specific to address specific situations in the project and it should also be in line and derived from a company's generic Risk Management Master Plan or HACCP Master Plan to ensure efficiency and consistency throughout the company. The plan should include:

• The scope of the project,
• steps, tasks,
• deliverables,
• responsibilities and
• a time line.

2. Assemble a HACCP Process Team and Define a Team Leader

Team members should include subject matter experts with specific knowledge and expertise in pharmaceutical engineering. Preferably team members should represent all affected disciplines, e.g.

• Research,
• development,
• production,
• sanitation,
• engineering,
• maintenance,
• quality control,
• laboratories,
• quality engineering and
• members of other disciplines directly involved in the plan's day-to-day operation.

The team should also include local personnel who are familiar with capabilities and limitations of the operation. Team members should either have knowledge and experience in HACCP methodology and product safety hazards or should get training. One of the first tasks of the team is to finalize the HACCP plan.

3. Describe the Product or Process and Develop a Flow Diagram of the Process

The description should include the intended use and end users of the product and the distribution method. The intended users of a food or drug product may be the general public or a particular segment of the population, e.g. infants and elderly people. The product description should include a list of specifications e.g., physical and chemical properties.

A flow diagram should be developed with the purpose of providing a clear, simple outline of the steps in the process which are under the control of the establishment. It should include all process steps such as mixing, drying, cleaning, blending, testing, packaging, labeling, storing and distribution.

4. Verify the Flow Diagram Onsite

This step compares in a walk-through, the actual operation with the product and process documentation, such as product description and flow diagrams. To ensure objectivity the verification should not be done by the same people who originally developed the flow diagram. Deviations should be corrected in the flow diagram and documented.

Implementing HACCP Principles

After the preparation has been done, the seven HACCP principles as outlined previously are implemented. Steps include:

1. Identify all Potential Hazards

All potential hazards and associated control measures, if available, are identified and documented for each operational step from receipt of raw materials through to release and distribution of the finished product.

2. Conduct a Hazard Analysis

The purpose of the hazard analysis is to develop a list of hazards which are of such significance that they are reasonably likely to cause injury or illness if not effectively controlled. Hazards that are not reasonably likely to occur would not require further consideration. Potential hazards include:

• Biological,
• chemical and
• physical compounds.

The analysis is done by the HACCP team in a brainstorming meeting on hazard identification followed by a workshop on hazard evaluation.

The process of conducting a hazard analysis involves two steps.

The first step, hazard identification, lists all potential hazards. This is done through the brainstorming session. The team develops a list of potential biological, chemical or physical hazards.

After the list of potential hazards is assembled, step two the hazard evaluation, is conducted. In a workshop the HACCP team decides which potential hazards must be addressed in the HACCP plan. During this stage each potential hazard is evaluated based on the severity of the potential hazard and its likely occurrence. The occurrence factor also takes into account control measures that are already in place to reduce the probability of occurrence.

The outcome of this exercise is to decide which identified hazards are critical enough that they are defined as critical control points (CCPs) and control steps are then implemented to reduce the risk to an acceptable level. If there are no hazards that need to be controlled there is no need to establish critical control limits. The project moves directly to establishing monitoring procedures.

3. Determine Critical Control Points

Once the critical hazards are identified the team identifies control measures for reduction or elimination of each critical hazard. Areas that should be considered are:

• Material,
• equipment malfunction,
• failures of sensors,
• human errors,
• power failures and
• external impacts such as natural forces, e.g., lightning or wind.

Control steps are identified for all critical hazards where no control measure exists. Complete and accurate identification of CCPs is fundamental to controlling hazards. The information developed during the hazard analysis is essential for the HACCP team in identifying which steps in the process are CCPs. One strategy to facilitate the identification of each CCP is the use of a CCP decision tree. Figure 9 shows an example of such a decision tree with three questions to answer.

Important questions to ask are:

• Does this step involve a hazard of sufficient risk and severity to warrant its control?
• Does a control point for the hazard exist?
• Is control at this step necessary to prevent, eliminate or reduce the risk of the hazard to consumers?

If all questions are answered with yes, a critical control is defined for the hazard.

Figure 9: Decision Tree to Identify Critical Control Points (From Ref. 32)

4. Establish Critical Limits for Each Control Point

Critical limits should be established for each control point. A critical limit is a maximum and/or minimum value to which a biological, chemical or physical parameter must be controlled at a CCP to prevent, eliminate or reduce to an acceptable level, the occurrence of a food safety hazard. Critical limits may be based on:

• Temperature,
• time,
• humidity,
• salt concentration,
• viscosity,
• pH or
• sensory parameters.

The limits should be scientifically justified.

Before the project moves to the next step, the remaining risk after implementing CCPs and critical control is evaluated and the team repeats the risk evaluation.

5. Establish a Monitoring Procedure

Monitoring is a planned sequence of observations or measurements to assess whether a CCP is under control and to produce an accurate record for future use in verification. The monitoring system must be able to detect loss of control at the CCP. It should be either continuous or done at a sufficient frequency that the detection is available in time to ensure that corrections are possible before any harm occurs. To avoid violation of limits as much as possible, tighter control limits should be defined where corrective actions are initiated before the critical limit is exceeded. All records and documents associated with CCP monitoring should be dated and signed or initiated by the person doing the monitoring. Examples of monitoring activities include:

• Visual observations and
• measurement of temperature, time, pH and moisture level.

6. Establish Corrective Actions

For each observed limit violation a corrective action should be initiated. Subject matter experts should determine the root cause for the violation and suggest corrective actions. Corrective actions should include the following elements:

• Determine and correct the cause of non-compliance.
• Determine the disposition of a non-compliant product.
• Record the corrective actions that have been taken.

Specific corrective actions should be developed in advance for each CCP and included in the HACCP plan. As a minimum, the HACCP plan should specify:

• What is done when a deviation occurs,
• who is responsible for implementing the corrective actions, and
• that a record will be developed and maintained of the actions taken.

The corrective action should be extended to similar CCPs to avoid further violation of limits. The action plan should be verified for efficiency.

7. Establish Verification Procedures

Verification is defined as those activities, other than monitoring, that determine the validity of the HACCP plan and ensure that the system is operating according to the plan. Another important aspect of verification is the initial validation of the HACCP plan to determine:

• That the plan is scientifically and technically sound.
• That all hazards have been identified and that the HACCP plan is properly implemented.
• That these hazards will be effectively controlled.

Verification procedures should be implemented to determine whether the HACCP system is working effectively or not. Examples for verification activities include review of the HACCP plan for completeness, CCP monitoring records, deviations and corrections, validation of critical limits to confirm that they are adequate to control significant hazards and confirmation that CCPs are kept under control. Verification should be conducted, e.g., routinely or on an unannounced basis, to confirm that changes have been implemented correctly after the HACCP plan has been modified and to assess whether a HACCP plan should be modified due to a change in the process equipment. Verification records can include, for example, the HACCP plan and the person(s) responsible for administering and updating the HACCP plan, certification that monitoring equipment is properly calibrated and in working order and training and knowledge of individuals responsible for monitoring CCPs.

8. Document and Communicate all Activities

Accurate documentation and communication is essential for the success of the HACCP project. Documentation should be developed according to the progress of the project and not just at the end. Important steps should be communicated to everybody who is affected by the project throughout the development and at the end of the project.

Records should be retained to document that the HACCP project has been conducted according to documented HACCP requirements. They are unavoidable to demonstrate compliance in case of any product liability issues. Records can be retained in any format, e.g., paper and electronic versions. Examples for records that should be retained include:

• A summary of the hazard analysis, including the rationale for determining hazards and control measures.
• The HACCP plan.
• Training records of the key project leader and HACCP team members.
• Records generated during the operation of the plan.

Hazard and Operability Studies (HAZOPs)

HAZOP examines a planned or existing product, process, procedure or system. It identifies risks to people, equipment and environment. HAZOP also includes steps for risk mitigation. The HAZOP team identifies failure modes of a process or system and possible causes and consequences similar to FMEA. While FMEA starts by identifying failure modes, HAZOP considers unwanted outcomes and deviations from intended outcomes and works back to possible causes.

Characteristic for a HAZOP process is the use of guide words such as "No or Not, More, Less, Part of and Compatible".

HAZOP was initially developed to analyze chemical process systems and was extended to other complex mechanical, electronic and software systems. It is usually undertaken during the design stage of software and hardware development.

Steps of HAZOPs include:

1. Appointment of project leader and project team. The team should include personnel not directly involved in the design of the project or process.
2. Definition of objectives.
3. Establishing a set of guide words.
4. Collection of the required documentation.
5. Splitting the system or process into smaller pieces and subsystems and reviewing the relevant documentation.
6. Defining and recording deviations, possible causes, actions to address the identified problem and person(s) responsible for the corrective action.
7. Evaluating the remaining risk for deviations that cannot be addressed.

Preliminary Hazard Analysis (PHA) and
Preliminary Risk Analysis (PRA)

Preliminary Hazard Analysis (PHA) is a qualitative, inductive tool for risk analysis. Sometimes PRA and PHA are interchangeably used where PRA includes an evaluation of impact and probability. PRA/PHA are based on applying prior experience or knowledge of hazards to identify future hazards. They are especially useful to identify and reduce risks early in a new or changed process. In the context of this chapter we also mean PHA when we talk about PRA.

Steps of a PRA methodology include:

1. Form a Project Team

As the success of the method relies on experience with historical knowledge, team members should include subject matter experts with experience in similar projects. If such information is not available external consultants should be hired. The team leader should have experience in FTA projects.

2. Create a Project Plan

The plan is created by the team under the supervision of the team leader. It includes background information on why the project has been initiated and describes the approach the risk project will follow as well as the scope, responsibilities, tasks and deliverables. A schedule is also included. The plan follows the rules of the company's Risk Management Master Plan. The plan also describes the approach to define which activities will be analyzed.

3. Describe the Situation

The situation is described by the teams technical subject matter experts. All relevant information is collected and distributed to other team members in preparation for the hazard identification step. The package also includes a proposal on which part of the project will be covered by the PRA methodology. Furthermore the preparation package also includes forms and recommendations on how to complete them in preparation for the hazard identification meeting. For complex projects a special training should be organized to ensure that the process is well understood and so that the team members can give meaningful inputs.

4. Identify Hazards

Hazards are best identified in a brainstorming meeting. All suggestions for potential hazards are collected and documented. The suggested hazards are grouped into categories, for example, product characteristics, processing steps or operational phases, such as start-up or normal operation. When all potential hazards have been identified and categorized they are reviewed and compared with each other. The team leader will put all suggested potential hazards up for discussion and the group decides to leave them or remove them from the list. This should ensure that only credible failures are retained. An important criterion on whether to leave a hazard on the list or not is if there are currently controls in place to reduce the risk. Only listed hazards without sufficient control will stay on the list.

5. Estimate the Probability of Occurrence and Severity

The final risk is estimated through looking at the probability of occurrence and the severity of identified hazards. For probability and severity assessment, controls already in place are considered. Results are either expressed qualitatively, e.g., high, medium and low or through more specific descriptions or quantitatively if sufficient data are available.

6. Prioritize Risks for Control

For hazards exceeding the acceptable risk thresholds the team defines controls to reduce the risk. The residual risks are evaluated again using the same criteria as before.

7. Prepare a Report

The report should include a description of the process, the study objectives and scope, the methodology and the identified hazards with justifications. The report should also include the result of risk assessment with justifications and additional controls put in place for hazards with too high risks.

Steps for Effective Risk Management

Previous chapters of this tutorial gave an overview on regulatory requirements. We also described the ICH Q9 process for risk management. In addition various tools and methodologies have been presented on how to implement risk assessment and risk management for various situations. While most tools have advantages but also limitations this chapter describes a generic approach and recommended steps for risk management. The overall process and individual steps are outlined in Figure 10 with more details on each step following in this chapter.

Figure 10: Risk Management Process and Steps

The process is initiated by management based on inputs from functional managers. Management also appoints a project leader who drafts a preliminary project plan. The project leader assembles a project team that finalizes the project plan.

In the risk analysis step team members suggest, sort, combine and prioritize hazards and harms. Team members then determine the risk using severity and probability and optional detectability as criteria. If the risk is below the acceptance criteria the project goes into the monitoring phase or is discontinued. This is to monitor the process for some time to verify that the risk level was correctly determined and/or to check if new hazards arise.

If the risk is higher than the acceptance criteria a risk mitigation plan is initiated and implemented. The residual risk is determined using the same procedure and criteria as for the first evaluation.

The outcome of the risk assessment and management is documented and communicated during and at the end of the process.

Step 1: Project Preparation and Planning

The risk management process requires detailed preparation and planning. This step includes project initiation and identification of a project manager and a project team.

Project Initiation

A risk management project can be proposed by anybody. The proposal should be forwarded to functional managers who review it and then forward it to higher management. The proposal should include:

• Description of the potential risk management project.
• Definition of potential problems with some examples for hazards and harms.
• Background information.
• Benefits of the proposed project.
• List of departments that should be part of the project.

Identification of the Project Manager and Team

Once the decision is made to initiate a risk management project management identifies a project leader. Selection criteria for the project owner are:

• Experienced in risk management.
• Project management skills.
• Excellent communication skills.
• Knowledge of the organization, system, process or application being assessed.
• Ability to manage people without direct reporting.

Tasks of the project owner include:

• With the help of functional managers selects a risk management team.
• Manages the entire process.
• Ensures necessary resources.
• Organizes and chairs team meetings.
• Drafts the risk management project plan.
• Represents the team in management meetings.
• Communicates the status and outcome of the project to management and peers.

One of the first tasks of the project leader is to recruit a team. The team should include members from all affected areas and groups.

Examples are:

• Affected operations (product development, manufacturing).
• Project management.
• Information Services (IS).
• Quality Assurance (QA).
• Legal department.
• Quality Control (QC).
• Plant safety, maintenance and engineering.
• Regulatory affairs.
• Sales and marketing.
• Accounting.
• Suppliers (optional).

Team members should be subject matter experts with at least five or more years experience in the related subject. General responsibilities of the risk management team are defined for each function in the Risk Management Master Plan.

Define Team Responsibilities

Risk management involves several departments, functions and personnel which requires good organization. For example, tasks and responsibilities should be well defined for everybody. The Risk Management Master Plan can be used as a guideline where the master plan allocates responsibilities only to job functions and not to individual persons. For a specific project, responsibilities can be defined for individuals by name in addition to functions.

Management

• Provides evidence of their commitment to the risk management process.
• Provides necessary resources.
• Defines and documents the policy for determining criteria for risk acceptability.
• Approves the Risk Management Master Plan.

System User Departments

• Contribute to development and maintenance of Risk Management Project Plans.
• Create and maintain equipment inventory.
• Give inputs on potential hazards with estimation on severity and probability for initial RM.
• Monitor efficiency of ongoing RM and give inputs on new hazards.

Plant Safety/Maintenance/Engineering

• Advises the facility/laboratory on possible hazards and harms related to environment and staff safety.

Information Services (IS)

• Advises the facility on possible hazards and harms related to IT, e.g., security.
• Participates in risk assessment and mitigation.
• Reviews Risk Management Project Plans related to networks.

Risk Management Team

• Develops and maintains the Risk Management Project Plan.
• Provides expertise to develop and implement RM for processes and systems during development and during initial and ongoing use.
• Responsible for risk assessment and the final decision on if and how to mitigate risks.

Quality Assurance (QA)

• Provides quality assurance expertise in the creation of the risk management plans.
• Monitors regulatory requirements and develops and updates company policies for RM.
• Develops and coordinates a training program on RM.

Validation Team

• Gives inputs for risk analysis and participates in risk assessment.
• Reviews and approves individual Risk Management Project Plans and deliverables.

Consultants

• Some of the activities can be outsourced to consultants, e.g., identification and classification of risks.

Vendors

• Inform users on potential risks arising from known software bugs and provide workaround solutions.

All

• Get trained on risk assessment and management.
• Provide inputs on hazards and possible harms for new and ongoing risk management projects.

Create a Risk Management Project Plan

Using the company's Risk Management Master Plan as a source document, the project leader with the help of the team creates the Risk Management Project Plan. While the Risk Management Master Plan (RMMP) is a framework and applicable to all projects, individual projects should be covered by the Risk Management Project Plan (RMPP). The relationship between both these plans is shown in Figure 11.

Figure 11: Risk Management Master Plan and Risk Management Project Plan

The project plan outlines how risk assessment is conducted, the steps and procedures the project team will implement and who is doing what. It also includes a time schedule and defines deliverables for each step. The draft also includes proposals for risk thresholds. The project leader presents the plan to management. Management reviews the plan and discusses the suggested steps and risk thresholds with the team in a meeting.

This is the most important step in the entire project. The acceptable risk threshold will determine the costs for reducing the risk but also associated costs or other problems that can arise if risks are not reduced. Functional managers from accounting, QA and operations should indicate priorities for how much risk the company can take. Most likely different functions will have different priorities. For example, when looking at the graph in Figure 1x QA tends more towards the right side of the graph with 100% quality, whereas finance most likely wants to save on project cost which is only possible if a trade-off is made between risk and quality.

The Risk Management Project Plan should include chapters on:

Purpose

• The purpose should be specific to the system and should include a short system description.

 Scope

• The scope defines what is and what is not covered by the plan. It also documents constraints and limitations.

 Responsibilities

• This section describes responsibilities of corporate management, the operations manager and staff, IT managers and staff and the risk management team. Unlike the master plan the project plan lists responsible people by name AND function, rather than by function only.

 Approach

• Describes the approach taken for managing the risk.

 Risk Identification

• Describes how risks, hazards and potential harms are identified and documented. Includes tables with risks, hazards, harms and suggestions for mitigation.

 Risk Evaluation

• Describes how risks are evaluated, categorized, prioritized and documented. It includes matrices with risks, categories for probability and severity and risk codes.

 Risk Threshold

• Documents risk threshold values for the project.

 Risk Mitigation

• Evaluates alternatives of risk mitigation versus costs. Describes actions in case mitigations are required. It also includes a time schedule for actions and estimates and documents residual risk priority numbers after mitigation.

 Risk Acceptance

• Compares risk threshold as originally defined with the RPN obtained after mitigation. Based on the outcome the residual risk is accepted rejected.

 Ongoing Monitoring

• Describes how risks are monitored, reported and documented during use of the system. Describes the actions in case new hazards are reported or if the risk level has changed.

 Project Schedule

• Outlines action items with owners.

Step 2: Risk Identification

Step 2 in the risk management process is risk identification. It should answer the question: What are the potential problems that could occur? All activities in a process under consideration are documented. Potential risks are identified by the project team under the leadership of the project leader. If there is little or no experience with risk identification within a company, outside resources who have worked on similar projects should be invited to give their opinion. They can help to identify or discover potential problems based on experience with similar projects. The output of this phase is the input for risk evaluation.

Inputs for risk identification are:

• Customer complaints.
• Failure investigations.
• Corrective and preventive action plans.
• Specifications for processes and systems.
• Experience with the same process or system already installed and running.
• Experience with similar processes and systems.
• Experience with suppliers of the system and suppliers of material used for the process.
• Failure rates of the same or similar systems and processes.
• Trends of failures.
• System and process validation reports.
• Service records and trends.
• Internal and external audit results.
• FDA inspection reports.

Inputs can come from engineers, operators of equipment and processes, the validation group, IT administrators or from QA personal, e.g., as a result of internal and external audits or inspections.

The project team collects inputs on potential hazards with possible harms. Information is collected during a brainstorming meeting. All inputs should be accepted and documented. The project leader should make sure that all ideas are well understood by team members. Initial documentation can be made on a flip chart or self adhesive notes that can be easily moved around to group similar risks into categories and to eliminate double-quoted identical risks or combine similar risks into single ones.

The team prioritizes all risks that are considered for follow-up. The list of selected risks can be compared with a checklist that has been created from other projects. This should ensure that nothing important has been left out.

For final documentation a form as shown in the table in Figure 12 or similar should be used with entry fields for the person who made the entry, risk description, impact on system availability, data integrity, compliance, typical situations of occurrence and suggestions for mitigation.

Person: Date:	System/Process ID:	Location:
Risk description, hazard, typical situations of occurrence	Possible harm	Suggestion for risk control

Figure 12: Form for Risk Identification

At this point typical situations of occurrence, possible harms and suggestions for risk control are described expressing everybody's thoughts and experience rather than thinking about categories. For example, contributors should describe the estimated time intervals and special circumstances under which the process or system can fail.

Step 3: Risk Evaluation

After information on risks has been collected, the risk evaluation phase starts. This phase compares the identified risks against given risk criteria. It should be determined which risks are the most important ones to focus on and put into the risk mitigation plan. The output of this phase is a quantitative estimate of risk or a qualitative description of a range of risks. Most critical is to use objective ranking criteria for severity and probability. For more details on how this is best achieved see the section "Approaches for Risk Management" in the chapter "Criteria for Severity, Probability and Risk Acceptance".

For implementation the project leader calls for a workshop. Each risk as prioritized and documented in the identification phase is presented by the risk owner who also makes a proposal for numerical severity and probability factors together with a justification. The proposal is discussed with the team and either accepted as it is, accepted after a change of severity and/or probability factors, or rejected. Rejection should rarely happen because the risk has been prioritized in a previous meeting. One reason for removing a risk from the list would be if the assumptions have changed since the risk identification step.

Numbers are associated to the levels and the overall risk priority number (RPN) is calculated. Figure 13 shows a template on how to document the impact (severity) of non-patient business risk, the impact on patient health and the probability.

The RPN is calculated using the formula:

RPN = S (Business) x S (Patient) x P

On a scale of 1 to 27 the RPN is calculated as 18.

Person: Date:	System  ID:		Location:
Risk description /ID	Impact on patient health (Level 1-3)	Impact on business continuity (Level 1-3)	Occurrence (Level 1-5)	Risk priority number
XYZ423	3	2	3	18

Figure 13: Form for Risk Evaluation

Step 4: Risk Acceptance

Risk acceptance is a formal decision to accept a risk. In this step we analyze the countermeasures that we put in the risk response table based on risk priorities. Starting point is the risk priority number as calculated from probability and severity and the risk threshold as defined for the project. The risks should be put into three categories as defined in Figure 14.

The impact on each identified risk is evaluated using the same criteria as defined in Step 3. RPNs are calculated and compared with the original risk threshold. Residual risks are accepted as long as the risk priority number is below the risk threshold. Lets assume the RT for the project is defined as 5 on a scale of 1-10. The normalized RPN is:

16/27 x 10 = 6.6

This means the risk is not acceptable.

Factor 8 and Lower: Code 1	Routinely accepted, no action taken.
Factor 9-16: Code 2	Operation requires written, time-limited waiver endorsed by management. Mitigation subject to cost/benefit analysis.
Factor Higher than 16: Code 3	Not accepted. Mitigation required. Alternative approaches should be evaluated.

Figure 14: Definition of Risk Codes and Consequences

All risks with factors higher than 16 (Code 3 = High Risk) should be reduced or eliminated and all risks with factors higher than 8 (Code 2 = medium risk) should be considered for mitigation and are subject to a cost benefit analysis.

Step 5: Risk Mitigation

When the risk as evaluated in the previous step is not acceptable, alternatives on how to mitigate risks should be evaluated. This phase is also called Risk Treatment.

Figure 15 is used to document the mitigation strategy, costs for mitigation and non-mitigation and the decision whether to mitigate the risk or not.

Person: Date:	System  ID:		Location:
Risk description /ID	Mitigation strategy	Cost of mitigation	Cost of non-mitigation	Mitigate yes/no

Figure 15: Form for Risk Mitigation

Possibilities to Mitigate Risks

There are different ways and approaches to mitigate risks.

All risk mitigation options should be considered and can be combined.

They include:

• Removing the risk source (eliminating the risk).
•  Changing the likelihood.
•  Changing the consequences.
•  Ensuring that the risk is detected and can be treated when it occurs.
•  Sharing the risk with other parties.

Care should be taken that mitigation strategies do not introduce new risks into the process or increase existing risks in other areas.

After the risk is reduced it is evaluated again using the same criteria as before. If the risk was acceptable the project moves along to the last step for documentation, communication and ongoing review for possible changes.

Estimating Costs vs. Benefits

The initial and ongoing costs for the best alternative should be estimated and compared with the estimated costs of non-mitigation. For risk codes 2 (medium risk) this comparison should be the basis for the decision whether to mitigate risks or not. The rationale behind the decision should be well justified and documented.

It is important to estimate the cost for mitigation as well as potential losses through non-mitigation. Losses for non-mitigation should include real or direct costs and tangible or indirect costs. Real costs are loss of revenue and are relatively easy to estimate. Tangible costs are more difficult to estimate. They can include damage to a company's reputation or appearing on the FDA's radar after one or more failed FDA inspection.

Risk Mitigation Plan

Once the decision to mitigate the risk has been made and the strategy is identified, a mitigation plan should be developed. The plan should describe:

• Mitigation options.
• How options will be implemented.
• Resource requirements.
• Tasks.
• Owners.
• Deliverables.
• Schedule.
• Performance measures.
• Required documentation.
• Communication requirements.

After the plan is implemented the residual risk is evaluated and is subject to monitoring.

Step 6: Ongoing Monitoring, Reviews and Updates

Once the plan is in place and the system is running, the effectiveness of the plan should be monitored, reviewed and adjusted if necessary. The monitoring program should also help to identify previously unrecognized hazards. These could have been introduced by changing processes or introducing new technologies.

The monitoring program should check if risk priority numbers have changed to either higher or lower values. Users and IT professionals gain a lot of experience that can be used to further optimize the effectiveness. If factors exceed the previous specified limit, mitigation strategies should be evaluated. If higher values decrease below the threshold, mitigation may no longer be necessary which can save operating costs.

Contributors use the form in Figure 16 to document observations and to make recommendations. They should also make a recommendation if the change should be implemented urgently if it is time critical.

Person: Date:	System  ID:		Location:
Risk description /ID	Observation	Recommendation for change		Urgent yes/no

Figure 16: Form to Recommend Changes

The risk management team evaluates the recommendations made by contributors. The team meets monthly if there are no recommendations for changes classified as 'urgent'. In the case of an urgent recommendation for a change the team meets and evaluates the change within a week. Changes or additions are documented using the form in Figure 17.

Person: Date:	System  ID:	Location:
Risk description /ID	Change/Addition	Urgent yes/no

Figure 18: Form to Document Changes

Step 7: Documentation and Communication

Regulatory agencies strongly suggest basing decisions for details of compliance with GxP on a justified and documented risk assessment. Therefore documentation is very important. Documentation is also important to justify investments as they may be required to meet business and compliance requirements. Complete documentation for risk management should include:

• Risk Management Master Plan - This shows your company's approach towards risk assessment and risk management.
• Risk Management Project Plan - This shows the plan for specific system and mitigation strategies.
• Lists with description of risk categories, ranking criteria and results of ranking.
• Justification for not mitigating risks with high factors.
• Risk mitigation plans.
• Mitigation actions taken
• Review reports.

The information should be communicated with everybody who may be affected by the project. The information should not only be shared toward the end of the project but this should be ongoing from the start. Most important is to openly share all information that leads to decisions about factors for probability and severity factors and whether to mitigate certain risks or not.

Application Examples

Overview

The Risk Management Process can be applied for:

• Design and development of a product or process.
• Selection and assessment of suppliers.
• Training, especially proof of effectiveness.
• Risk-based computer validation.
• Risk-based qualification of analytical equipment.
• Part 11 compliance.
• Pharmaceutical manufacturing.
• Scheduling internal audits.
• Starting material - qualification and handling.
• Validation of analytical procedures
• Qualification of equipment
• Change control to introduce new starting material.
• Archiving electronic records.

To be completed later

Glossary

Some of the risk-based definitions are original or derived from either ISO/IEC Guide 51:1999 or ANSI/AAMI/ISO 14971:2000.

CCP Decision Tree

A sequence of questions to assist in determining whether a control point is a CCP (Ref. 32).

Critical Control Limit (CCL)

A maximum and/or minimum value to which a biological, chemical or physical parameter must be controlled (Ref. 32).

Control Measure

Any action or activity that can be used to prevent, eliminate or reduce a significant hazard (Ref. 32).

Corrective Action

Procedures followed when a deviation occurs (Ref. 32).

Critical Control Point (CCP)

A step at which control can be applied and is essential to prevent or eliminate a (pharmaceutical) quality hazard or reduce it to an acceptable level (Ref. 30).

Failure

Termination of the ability of an item to perform a required function (IEC 60812:20067).

Failure Mode

Manner in which an item fails (IEC 60812:20067).

FMEA - Failure Modes and Effects Analysis

Used to identify failure modes and their consequences or effects. FMEA is a bottom-up technique: What can go wrong on a low level component and how this impacts the system or application.

FMECA - Failure Modes, Effects and Criticality Analysis

Adds evaluation of the criticality including severity, occurrence and detectability to the FMEA.

FTA - Fault Tree Analysis

Top-down technique. The analyst looks at the high-level system failure and proceeds down into the system to trace failure paths.

HACCP � Hazard Analysis and Critical Control Points

A systematic approach to the identification, evaluation and control of food safety hazards (Ref. 32).

HACCP Plan

The written document which is based upon the principles of HACCP and which delineates the procedures to be followed (Ref. 32).

HACCP System

The result of the implementation of the HACCP Plan (Ref. 32).

Harm

Physical injury or damage to the health of people, or damage to property or the environment (ISO 14971).

Hazard

Potential source of harm (ISO 14971).
In the context of HACCP: Any circumstance in the production, control and distribution of a (pharmaceutical) product which can cause an adverse health effect (Ref. 30).
Hazard: A biological, chemical or physical agent that is reasonably likely to cause illness or injury in the absence of its control (Ref. 32).

Hazard Analysis

The process of collecting and evaluating information on hazards associated with the food under consideration to decide which are significant and must be addressed in the HACCP plan (Ref. 32).

Hazard Monitoring

To conduct a planned sequence of observations or measurements to assess whether a CCP is under control and to produce an accurate record for future use in verification (Ref. 32).

Validation (related to HACCP)

That element of verification focused on collecting and evaluating scientific and technical information to determine if the HACCP plan, when properly implemented, will effectively control the hazards (Ref. 32).

Verification (related to HACCP)

Those activities, other than monitoring, that determine the validity of the HACCP plan and that the system is operating according to the plan (Ref. 32).

NIST

National Institute of Standards and Technology.

P/I

Probability/Impact equal to RPN (Risk Priority Number).

PIC/S

The Pharmaceutical Inspection Convention and Pharmaceutical Inspection Co-operation Scheme (jointly referred to as PIC/S).

PHA - Preliminary Hazard Analysis

Can be used to identify hazards and to guide development of countermeasures to mitigate the risk posed by these hazards.

PRA - Preliminary risk analysis

Probabilistic risk assessment.

Probability of Detection

Evaluates the probability of realizing that the hazard has occurred before the resultant harm to the patient has occurred.

QRAS - Quantitative Risk Assessment System

Developed for NASA by the University of Maryland.

QU

Quality Unit.

Residual Risk

Risk remaining after protective measures have been taken (ISO 14971).

Risk

Combination of the probability of occurrence of harm and the severity of that harm. Combination of the probability of harm and the severity of that harm (ISO 14971:2007).

Risk Acceptance

The decision to accept risk (ISO Guide 73).

Risk Analysis

Systematic use of available information to identify hazards and to estimate the risk (ISO 14971:2007).

Risk Assessment

A systematic process of organizing information to support a risk decision to be made within a risk management process. It consists of the identification of the hazards, and the analysis and evaluation of risks associated with the exposure of these hazards (ICH Q9).
Overall process of risk identification, risk analysis and evaluation (ISO 14971:2007).

Risk Communication

The sharing of information about risks and risk management between the decision maker and the stakeholder.

Risk Control

The process through which decisions are reached and implemented for reducing risks to, or maintaining risks within, specified limits.
Process in which decisions are made and measures implemented by which risks are reduced to, or maintained within, specified levels (ISO 14971:2007).

Risk Criteria

Terms or reference against which the significance of a risk is evaluated (ISO Guide 73:2009).

Risk Estimation

Process used to assign values to the probability of occurrence of harm and the severity of that harm (ISO 14971:2007).

Risk Evaluation

Process of comparing the estimated risk against given risk criteria to determine the acceptability of the risk (ISO 14971:2007).
The comparison of the estimated risk to given risk criteria using a quantitative or qualitative scale to determine the significance of risk.

Risk Identification

The systematic use of information to identify potential sources of harm (hazards) referring to the risk question or problem description.

Risk Index

A semi-quantitative measure of risk which is an estimate derived using a scoring approach using ordinal scales (IEC/ISO 31010).

Risk Level

A quantitative estimate that describes the level of degree of risk. The value is added based on quantitative values assigned for public health (severity), regulatory risk and business risk. For the purpose of this standard the risk is expressed as high, medium or low based on the degree of regulatory risk and patient/user risk.

Risk Management

Systematic application of management policies, procedures and practices to the tasks of analyzing, evaluating, controlling and monitoring risks (ISO 14971:2007).

Risk Reduction

Actions taken to lessen the probability of occurrence of harm and the severity of that harm.

Risk Review

Review of monitoring of output/results of the risk management process considering (if appropriate) new knowledge and experience with the risk.

Risk Priority Number

Measure of overall risk. It is obtained by multiplying the rating of severity, occurrence (and probability of non-detection). The higher the number the more serious the risk.

Risk Treatment

Process of selection and implementation of measures to modify risk.

RR

Risk Rating.

RT

Risk Threshold.

Severity

Measure of the possible consequences of a hazard (ISO 14971:2007).

Tolerable Risk

Risk that is accepted in a given context based on the current values of society.

RMMP - Risk Management Master Plan

Framework which is applicable to all projects. Used as a source to draft Risk Management Project Plans.

RMPP - Risk Management Project Plan

While the Risk Management Master Plan (RMMP) is a framework and applicable to all projects, individual projects should be covered by a Risk Management Project Plan (RMPP). It outlines risk management activities specific to the project. The RM Master Plan should be used to draft this plan.

Stakeholder

Person or organization that can affect, be affected by, or perceived themselves to be affected by, a decision or activity (ISO Guide 73:2009).

References

1. The European Council Directive 93/42/EEC of 14 June 1993 Concerning Medical Devices.
2. FDA 21 CFR 820: "Quality System Regulation (for Devices)".
3. EU GMP, Annex 15: "Validation and Qualification", 2010.
4. FDA: Pharmaceutical cGMPs for the 21st Century: "A Risk-Based Approach: Second Progress. Report and Implementation Plan", 2003.
5. FDA Industry Guidance: "Part 11, Electronic Records; Electronic Signatures - Scope and Application", 2003.
6. ICH Q9: "Quality Risk Management", 2005.
7. GAMP 4: "Guide for Validation of Automated Systems", 2001.
   For ordering go to: http://www.labcompliance.com/seminars/audio.ispe.org
8. GAMP 5: "A Risk-Based Approach to Compliant GxP Computerized Systems", 2008. For ordering go to: http://www.labcompliance.com/seminars/audio.ispe.org
9. GHTF: "Implementation of Risk Management Principles and Activities within a Quality Management System", 2005.
10. ISO 14791:2007: "Application of Risk Management to Medical Devices".
11. ISO 31000: "Risk Management" Principles and Guidelines", 2009.
12. ISO 31010: "Risk Assessment Techniques", 2009.
13. R. Jones, Pharmaceutical Manufacturing: "How to Understand the Process and Assess the Risks to Patient Safety", Pharmaceutical Engineering, November 2009, 16.
14. I. Campbell: "Applying Quality Risk Management Principles to Achieve a Practical Verification Strategy", Pharmaceutical Engineering, November 2009, 24-38.
15. L. Huber (15): "Risk-Based Validation of Commercial Off-the-Shelf Computer Systems", Journal of Validation Technology, 11(3), 2005.
16. Labcompliance: "Risk Management Master Plan", 2010.
17. Labcompliance SOP: "Risk Assessment Used for Systems Used in GxP Environments".
18. Labcompliance SOP: "Risk Assessment for Laboratory Systems", 2010.
19. Labcompliance SOP: "Risk-Based Qualification of Network Infrastructures".
20. Labcompliance Case Studies: "Risk-Based Methodologies for Laboratory Tasks".
21. FDA Guidance: "General Principles of Software Validation", (2002).
22. FDA Guidance for Industry: "Quality Systems Approach to Pharmaceutical CGMP Regulations", (2006).
23. EU GMP, Annex 11: "Using Computerized Systems".
24. Pharmaceutical Inspection Convention/Cooperation Scheme (PIC/S): "Good Practices for Computerised Systems in Regulated 'GxP' Environments".
25. United States Pharmacopeia: <232> Elemental Impurities (Proposal).
26. USP Chapter <467> Residual Solvents.
27. FDA Guidance: "FDA Reviewers and Compliance on Off-The-Shelf Software Use in Medical Devices", 1999.
28. FDA Guidance: "Inspections of Quality Systems" (Medical Devices), ORA Inspectional References.
29. PIC/S Quality Risk Management: "Implementation of ICH Q9 in the Pharmaceutical Field", 2010.
30. Report by WHO Expert Committee on "Specifications for Pharmaceutical Preparation", Annex 7, Application of HACCP Methodology to Pharmaceuticals, 2003.
31. FDA Guidance: "Fish and Fisheries Products Hazards and Controls", Appendix 3, 2001.
    http://www.fda.gov/food/guidancecomplianceregulatoryinformation/
    guidancedocuments/seafood/fishandfisheriesproductshazardsandcontrolsguide/
    default.htm
32. National Advisory Committee on Microbiological Criteria for Foods, "HACCP Principles and Application Guidelines", 1997.
    http://www.fda.gov/food/foodsafety/HazardAnalysisCriticalControlPointsHACCP/
    ucm114868.htm
33. J.L. Vesper: "Risk Assessment and Risk Management in the Pharmaceutical Industry: Clear and Simple", Davis Healthcare International Publishing, LLC, ISBN 1-930114-94-X, 2006.
34. Concept Heidelberg: "Risk Management in the Pharmaceutical Industry", Editio Cantor Verlag, 2008, ISBN 978-3-87193-370-7.
35. K. O'Donnel and A. Greene: "A Risk Management Solution Designed to Facilitate Risk-Based Qualification, Validation and Change Control Activities within GMP and Pharmaceutical Regulatory Compliance Environments in the EU", Part I: Fundamental Principles, Design Criteria, Outline of Process, Journal GXP Compliance, 10 (4) 12-25 (2006).
36. K. O'Donnel and A. Greene, "A Risk Management Solution Designed to Facilitate Risk-Based Qualification, Validation and Change Control Activities Within GMP and Pharmaceutical Regulatory Compliance Environments in the EU", Part II: Tool Scope, Structure, Limitation, Principle Findings and Novel Elements, Journal GXP Compliance, 10 (4) 26-35 (2006).
37. ISO/IEC Guide 73:2002: "Risk Management - Vocabulary", Guidelines for Use in Standards".