1. Purpose
To define the requirements for the application of risk management principles to computerized systems.
2. Scope and Applicability
This Guideline is applicable to any operations sites, functions and departments undertaking work, or providing support services, required to meet Good Laboratory Practice (GLP), Good Clinical Practice (GCP), and Good Manufacturing Practice (GMP). Risk Management is mandatory for GxP computerized systems and should be considered for all others, especially those of high business risk.
This Guideline provides guiding principals applicable to the risk management of computerized systems.
While the primary focus is applications, it may also be used with IT infrastructure platforms and process control systems.
3. Definitions
3.1 Risk management
The systematic and comprehensive identification and understanding of risk factors and their associated risks, together with a decision making process to implement appropriate controls.
o Aims to maximize potential opportunities, control uncertainties and minimize potential threats, thereby increasing the probability of achieving business objectives.
o Includes the conscious decision to accept risk.
o Is an ongoing (iterative process)
3.2 Computerized System
An assembled group of hardware components (including peripheral devices), firmware and software components, that are collectively designed to perform a specific function or group of functions.
3.3 Technical Staff
Members of the technical community (typically from IS, but for some systems may be from operations, engineering or another group that performs development or support) who understands and represents the technical perspective.
3.4 Key User
A member of the business or functional group who currently uses the system on a day-to-day basis and has responsibility for representing users needs and the process use of the system.
4. Responsibilities
The Project Leader and/or System Owner have responsibility for ensuring that a risk-managed approach for the development and maintenance of computerized systems is utilized. A multi-disciplined team should be assembled to support this approach and should include representation from some or all of these as applicable:
* Technical Staff
* System owner
* Key User
* Quality Assurance
* Computer Validation
* IS Quality Manager
It is the responsibility of this multi-disciplined Team to carry out risk assessment activities & make informed decisions about the validation processes & deliverables that will be required to adequately address validation or change control.
5. Guideline
A risk-managed approach to the system life cycle is necessary for an efficient and effective way of working. Utilizing risk management methodologies allows validation activities to be appropriately scaled to meet business and regulatory needs without creating unnecessary work. Documentation and testing are focused in appropriate areas to mitigate risk. In some cases this may require additional testing in high-risk areas.
This approach also benefits the change control process because areas of regulatory impact and risk will have been identified prior to initiating the change.
Thus the impact of a change can be more easily identified and appropriately handled.
A number of assessments are carried out and decisions documented to support a risk-managed approach. It is important to recognize that these assessments are tools to aid the team in the decision making process. The output of an assessment should be carefully weighed against the team’s knowledge of the computerized system in order to make informed decisions. The team’s subjectivity will be instrumental in many cases throughout the process. Decisions should be appropriately documented to capture the rationale.
The scope and amount of validation or qualification is determined by assessing the business requirement, the associated activities and the level of risk this represents to business. This is described in the following sections.
The following diagram provides an overview of the risk management process and The detail of these activities is described in sections 5.1 through 5.7
Figure: Risk Management Activities
5.1 Regulatory Impact Assessment
Components of this activity:
* It is necessary to perform a regulatory impact assessment to determine if the computerized system has regulatory impact.
* The result of the Regulatory Impact Assessment (RIA) must be documented along with the rationale for any decisions taken.
It is necessary to perform a Regulatory Impact Assessment to determine if the computerized system has regulatory impact. To make this determination, the system’s impact on product quality, patient safety and data integrity should be considered in the following areas:
* Product Manufacturing, Release or Analysis
* Data/records supporting regulatory submissions
* Product Labeling
* Non-clinical Laboratory Studies
* Clinical Studies
* Product Storage and Distribution
* Product Complaints
The result of the Regulatory Impact Assessment must be documented along with the rationale for any decisions taken. If a computerized system is found to have regulatory impact then it is necessary to perform computerized systems validation.
5.2 System Component Categorization
Components of this activity:
All components of the computerized system must be identified and placed into categories.
To determine risk, it is necessary to identify all components of the computerized system and place them into categories.
Software Component Categories:
* Operating System
* Firmware
* Standard Software Packages
* Configurable Software Packages
* Custom (Bespoke) Software
Hardware Component Categories:
* Standard Hardware Components
* Custom Built (Bespoke) Hardware Components
This allows the team to easily see all the components of the system and the potential risk that they present. Each system component including core software, software dependencies, hardware and operating systems should be listed.
The ratings given to the components should be based on complexity, potential customization, and may be based on whether it is an industry standard. For example a computerized system that is provided by a supplier and is purely configurable will have a lower risk than one that is in house developed.
Specialized hardware or operating systems will have a higher risk than those that are an industry standard.
Upon completion of this section you will have now identified the type of validation effort required e.g. Testing, documentation, planning
5.3 Supplier Assessment
Components of this activity:
If a supplier assessment is required, it must be conducted in accordance with appropriate guidelines. Many computerized systems will utilize components purchased from external suppliers. The quality and reliability of these components will largely depend on the supplier. An assessment may be performed to determine their suitability in terms of systems development and support processes. This assessment is not mandatory but is strongly recommended. The decision to conduct this assessment will be based on the Regulatory Impact Assessment and the team’s knowledge of the supplier and/or system components. The Vendor Assurance and Contractor databases a good reference source for audits of suppliers and vendors including IS. The results of this activity will assist the team with activities planning and in scaling the testing activities as appropriate.
5.4 Requirements Analysis
Components of this activity:
* The requirements must be analysed to determine the scope of testing and regulatory applicability.
* Once the requirements categorization is complete, the team must then decide on appropriate levels of testing to ensure that the computerized system operates properly to satisfy the business and regulatory needs.
The requirements must be analysed to determine the scope of testing and regulatory applicability. It is important to determine which requirements have regulatory impact and to what degree. In order to determine this, they should be reviewed and categorized. Recommended categories for regulatory impact are direct, indirect and no impact. It is also essential to determine the importance of requirements to the business process. Recommended categories are Essential, Important and Desirable. Once the requirements categorization is complete, the team must then decide on appropriate levels of testing to ensure that the computerized system operates properly to satisfy the business and regulatory needs. The following grid may be used as a guide to help make this determination.
No Regulatory Impact | Indirect Regulatory Impact | Direct Regulatory Impact | |
| Essential | EN | EI | ED |
| Important | IN | II | ID |
| Desirable | DN | DI | DD |
The requirements in the upper right hand corner of the Grid have direct regulatory impact and are essential to the business while the ones in the lower left have no regulatory impact but are desirable to have in the system from a business perspective. Based on the previous exercises and the team’s knowledge of the computerized system, a decision can be made to determine which categories of requirements will be tested. For example, the team may decide that only categories EN, EIED, ID and DD will be tested. This grid is a tool to help the team make this determination and other methods may be used for this purpose.
5.5 Activities Planning
Components of this activity:
* The output of the risk assessments conducted in activities 5.1 through 5.4 must be summarized and their meaning explained. Rationale not captured in the individual assessments must be documented.
* Activities plan must include the validation deliverables to be created along with the complexity of these deliverables and a decision to perform a Functional Risk Assessment or not.
Documented rationale is a key component in a risk-managed approach. Once this information has been summarized the team can make informed decisions regarding the level of validation activities that need to be performed. Documented plan can then be created along with rationale for the decisions that have been made. This plan must include the validation deliverables to be created along with the complexity of these deliverables and a decision to perform a Functional Risk Assessment or not. This information is recorded in the Computer Validation Plan, change control documentation or a separate document as appropriate.
5.6 Functional Risk Assessment
Components of this activity:
None
In many cases a functional risk assessment may be beneficial to determine what type of testing should be performed and where. This assessment is not mandatory and will primarily benefit larger more complex computerized systems that have high level of customization. A key consideration in this activity is the risk of requirements failure. The likelihood, impact and probability of failure detection should be considered for each requirement or group of requirements to determine risk. The level of testing may then be tailored to the level of risk the requirement or group of requirements present. A low-risk function may not warrant any testing, while higher risk functions may require testing and, in some cases, additional supporting evidence Manual procedures may also be implemented to mitigate risk. The team’s knowledge of the requirements and system will help to guide this process.
5.7 Review
Components of this activity:
* A review of risk management activities and associated deliverables must be conducted and documented.
* Review and document any outstanding risks that require further attention.
Once validation activities have been carried out, a review of these activities and the associated deliverables must be conducted and documented. The intent of this review is to ensure that risk areas have been appropriately mitigated, identify areas of risk that have not been mitigated, review and document any outstanding risks that require further attention. This information can be captured in the Computer Validation Report, change control documentation or a separate document as appropriate.