| Department | Validation/Technical Services | Document no | VAL-135 | ||
| Prepared by: | Date: | Supersedes: | |||
| Checked by: | Date: | Date Issued: | |||
| Approved by: | Date: | Review Date: | |||
1.0 DOCUMENT OWNER
Validation / Technical Services Manager
2.0 PURPOSE
A Risk Assessment may be applied to computerized systems to enable the targeting of the validation effort to those areas and functions that most require it.
Validation of systems serves two purposes:
˜ To avoid any intolerable risk to patient safety or to the business.
˜ To maximize the business benefits to be derived from the new system.
3.0 SCOPE
This procedure describes how to prepare a Risk Assessment for a computerized system consistent with current regulatory requirements and industry good practice guidelines for the validation of computerized systems.
This procedure is applicable to all Risk Assessments associated with the qualification of any GxP system used in a GMP site.
3.1 Guidelines for Conducting Risk Assessments
The Risk Assessment process addresses the following questions:
˜ Does this computerized system require validation?
˜ How much validation is required for this system?
˜ What aspects of the system or process are critical to product and patient safety?
˜ What aspects of the system or process are critical to business?
It is impractical to completely test every aspect of a computerized system; therefore the effort should be focused on critical areas.
The focus of the Risk Assessment process is to assess those risks associated with the post-project operation of the computerized system and not the ‘in-project’ risks. The Risk Assessment process allows the business to identify and minimize the impact of adverse events, while at the same time providing the necessary justification for the validation approach taken to support the system implementation.
Note that while the approach outlined helps to focus validation effort it is the responsibility of the System Owner, Validation / Technical Services and IT, in consultation with Quality Assurance, to define the appropriate level of validation based on their judgments, expertise and understanding of regulatory requirements.
3.2 Risk Assessment and the Validation Process
As projects are dynamic in nature, the risk priorities may change throughout the life of the project. As per Computer System Guideline (VAL-110), risk assessment should be performed at the start of each computer system qualification. However, for a large system Risk Assessments may be conducted at several stages of the project. The number and timing of the assessments can be documented in the Validation Project Plan. For guidance, Risk Assessments may be undertaken following:
˜ The generation of the User Requirements Specification (URS)
˜ The Supplier Assessment and the development of the Functional Specification (FS)
˜ The completion of the Design Review prior to validation test
˜ Whenever any major changes are to be applied to the system.
Undertaking Risk Assessments at these stages will help define the user requirements and alternatives, aid the supplier selection process, and determine any mitigation steps or additional validation requirements for the project. The findings of early Risk Assessments should be reviewed at later key points in the project, to ensure that the assumptions and circumstances upon which they are founded are still valid.
For a small scale computer system a risk assessment at the start of the project may be sufficient.
As a minimum the System Owner, Validation / Technical Services and Quality Assurance in consultation with IT should approve the Risk Assessment documentation. Additional approvers may be added as required by the team and depending upon the phase of the project.
4.0 RESPONSIBILITY \ BUSINESS RULES
Risk Assessment is part of the overall responsibility of the project team or change control team members, however each member may take on a different role during the assessment exercise.
Typical responsibilities for conducting a Risk Assessment are detailed below:
˜ System Owner/Administrator: The System Owner is defined as the person ultimately responsible for the operation of a system, and the data residing on that system.
˜ The System Owner is responsible for the investigation and evaluation of those risks identified as part of the GxP operational process and those risks identified as significant to the overall business process.
˜ IT Person Responsible for System: Responsible for the investigation and evaluation of those risks identified as a result of the program configuration or implementation and those risks identified as a result of the infrastructure (hardware, network, peripherals, etc.) implementation.
˜ Validation / Technical Services Personnel: Responsible for the investigation and evaluation of those risks associated with validation requirements of the system.
˜ Quality Assurance: Responsible for the investigation and evaluation of those risks associated with regulatory compliance and maintaining company quality standards and policies.
5.0 PROCEDURE
5.1 Process Identification
The basis for the Risk Assessment will be the User Requirement Specification and the Functional Requirement Specification. These documents can be used to identify the system functions and their sub-functions, including the dependencies between them. The Risk Assessment will be performed to support the Validation Project Plan. For a small scale project the assessment may be documented in the Validation Project Plan. For a large scale system the assessment should be documented as a Technical Report or in the Validation Project Plan.
All functions and sub-functions identified during this phase should be documented and described. Each function and sub-function should be identified clearly and meaningfully.
5.2 Risk Assessment
5.2.1 Identify GxP Risk
This step is the determination of whether the system function or sub-function represents a risk when assessed against a series of GxP criteria.
Examples of risk that may be identified include, but are not limited to:
˜ The pharmaceutical quality of the finished product:
a. Incorrect composition
b. Raw materials errors
c. Packaging materials errors
d. Integrity of Data
e. Incorrect batch status
f. Failure of storage conditions
g. Batch recalls
h. Lot traceability
i. Labelling errors
~ The safety of patients and consumers:
a. Adverse reactions
b. Inadequate complaints handling or monitoring
c. Product Recall
~ System GxP Compliance:
a. Backup and recovery of data
b. Data transcription
c. E-records and signatures
d. Data integrity
e. Release for sale documentation
The project team should look at each function or sub-function and make an assessment of the GxP impact. The outcome of their discussions should be documented on the assessment form.
If the assessment of a particular function or sub-function determines that there is no GxP risk, the justification for taking this viewpoint should be documented on the assessment form.
5.2.2 Identify Business Risk
A secondary element of the Risk Assessment process is to determine whether the system function or sub-function represents a risk to the business.
The types of risk to be identified include, but are not limited to:
˜ Equipment downtime
˜ Equipment damage
˜ Cost of replacement equipment parts
˜ Potential for injury (Health and Safety)
If the assessment of a particular function or sub-function determines that there is no business risk, the justification for taking this viewpoint should be documented on the assessment form.
5.2.3 Identify Risk Scenarios
Having determined that a particular function or sub-function may have a GxP or business risk associated with it, the assessment should proceed to identify the various risk scenarios (i.e. the events that identify the risks associated with use of the system). It is useful to consider for each event what the likely effect will be (note that each event may have more than one effect).
5.2.4 Assess Likelihood
The next stage is to determine the likelihood (frequency or probability) of an adverse event occurring. The approach requires the project team to consider the likelihood of the adverse event occurring within a given time period (day, month, year) or per a quantity of transactions, and assigning a value to that estimate the risk can be classified.
A suggested method of representing this is as follows:
Low The frequency of the event occurring is perceived to be once per ten thousand transactions.
Medium The frequency of the event occurring is perceived to be once per thousand transactions.
High The frequency of the event occurring is perceived to be once per hundred transactions.
In many instances adverse events may be as the result of systematic software faults and the team may be unable to estimate the likelihood of such an adverse event. In such instances the likelihood default value of ‘High’ should be assigned unless there is strong documentary evidence of a high quality development process for the software under review. When more information becomes available as the project progresses, this value can be re-assigned as required.
5.2.5 Assess the Severity of Impact
Risk Assessment requires not only the identification of the immediate effects of the risk but also the long term and widespread impact on the business of those effects. These effects must take into account a wide variety of issues, including impact on regulatory compliance, financial impact and company reputation with customers and suppliers.
For example, the immediate effect of a hard disk problem may be the corruption of some data stored on that disk, while the business impact of corrupt data relating to product distribution will eventually result in severe problems in conducting a product recall. This would result in a critical non-compliance with the regulatory requirements and could result in regulatory action such as a withdrawn manufacturing license.
The impact of a risk occurring may be described as follows:
Low Expected to have a minor negative impact. The damage would not be expected to have a long-term detrimental effect.
Medium Expected to have a moderate impact. The impact could be expected to have short- to medium-term detrimental effects.
High Expected to have a very significant negative impact. The impact could be expected to have significant long-term effects and potentially catastrophic short-term effects.
5.2.6 Assign Risk Classification
Having assigned the Likelihood of the risk occurring and the level of Business Impact that such an event may have, the risk can be classified. This is achieved by reference to the matrix shown in Appendix 1.
5.2.7 Assess Probability of Detection
The purpose of this stage in the assessment process is to identify if the risk event can be recognized or detected by other means in the system. Hence, a Level One Risk, if it has a high probability of detection, may not pose such a serious threat because it can be recognized quickly and suitable corrective action taken to mitigate its impact.
Conversely if the same fault condition has a low probability of detection then the team may need to seriously consider a review of the design or the implementation of alternative procedures to avoid the event.
The probability of a risk being detected can be estimated as follows:
5.2.8 Determine Appropriate Measures for Risk Mitigation
By combining the Risk Classification with the Probability of detection, it is possible to prioritize the fault conditions associated with each adverse event based upon those areas of greatest vulnerability. Appendix 2 provides a model for such a process.
Once these priorities have been determined the team can proceed to define and document the appropriate measures to mitigate the adverse event that poses the risk.
The Risk Priority of the fault conditions should be used to select the appropriate risk mitigation (and focus the validation effort). For example, a condition that has a risk classification of 1, but a low level of detection is an area of vulnerability (=HIGH priority). By concentrating upon such an area the overall probability of failure is reduced and quality is built into the system.
There are several mitigation strategies that can be used to modify risk levels, and it is possible that several of them may be appropriate for a given system. Examples of such strategies are given below:
5.2.8.1 Modification of Process or System Design Elements to Mitigate Risk
˜ Modify Design: One or more independent controls are incorporated into the computer-related process; e.g., additional data verification checks within the system design in order to reduce data entry errors.
˜ Introduce External Procedures: Introduction of procedures to counter possible failures, such as double-checking.
˜ Modify Product (or System) Design: Use is made of proven methods, tools and components; fault-tolerance may be built into the computerised system (e.g. using replicated parts, system mirroring); the operating environment may be controlled.
5.2.8.2 Modification of Project Strategies to Mitigate Risk
˜ Revisit Project Structure and Makeup: This refers to the people chosen for the project; their experience and qualifications; the type of project organization preferred; the amount of education and training provided.
˜ Reconsider Amount of (Auditable) Built-in Quality: Alter the amount of documentation that is approved and controlled; introduce or remove formal review points to reflect identified risk.
5.2.8.3 Modification of Validation Approach to Mitigate Risk
˜ Increased Testing: Increase the scope and level of testing applied during various stages of the validation process, including the development of specialised testing aimed at the testing to failure of certain functions.
˜ Decreased Testing: Decrease the scope and level of testing applied during various phases of the validation process due to the extremely low risk associated with occurrence and consequences of the fault conditions.
5.2.8.4 Eliminate Risk
˜ Avoidance: The risks are so high that the new way of working should not be implemented.
The results of this phase of the assessment should be documented and used as justification for the validation approach. Details should include who is responsible for providing the mitigation effort.
5.3 Risk Assessment of Change
The Risk Assessment process should be used during the entire lifetime of the system. A process of Risk Assessment should be pursued at any time a major change is to be applied to the system. The application of the Risk Assessment technique as part of the Change Control process will allow the development of suitable mitigation strategies, to identify the verification and re-test activities to pursue before the change is put into operation.
5.4 Documentation of a Risk Assessment
Risk Assessments should follow site documentation structures. Risk Assessments for small-scale systems may be documented in the Validation Project Plan.
The Risk Assessment must, as a minimum, include the sections listed below. If there is no information relevant to a section, the statement “This section is not applicable to this Risk Assessment” should appear below the section heading, followed by a brief justification as to why the section has been omitted:
˜ Cover Sheets
˜ Introduction (including Purpose and Scope)
˜ System and Project Overview
˜ Risk Assessment
˜ Proposed Risk Mitigation Activities
˜ Glossary of Terms
˜ References
˜ Revision History
˜ Appendices
If the risk assessment is documented as part of the Validation Project Plan, all of the above sections may not be relevant
6.0 DEFINITIONS / ACRONYMS
| FS | Functional Specification |
| GxP | Generalized statement for Codes of Good Practice covering Good Clinical Practice (cGCP), Good Laboratory Practice (cGLP) and Good Manufacturing Practice (cGMP) |
| URS | User Requirements Specification |
7.0 REFERENCES
| VAL-110 | Computer Validation Guideline |
8.0 SUMMARY OF CHANGES
| Version # | Revision History |
| VAL 135 | New |