Risk Management – A Continuous Process

Introduction

As discussed in previous posts the regulatory expectation is that risk management will be applied to all lifecycle phases of a computerised system. The recent issue of EU Annex 11 includes risk management at all stages of the computer system lifecycle.

GAMP 4 first introduced the concept of risk management and risk assessments and following the issue of the ASTM E52500 Specification and Verification and ICH Q9 Quality Risk Management the ISPE Good Automation Manufacturing Guide (GAMP) was updated. GAMP5 has risk management throughout the lifecycle of the computerised system.

The article Computer System Quality Risk Management provides an introduction to the computer system quality risk management lifecycle and the available risk analysis tools.

This post introduces the concept of the risk review throughout the lifecycle and the importance of maintaining the initial risk assessments generated through the project lifecycle.

After Computer Validation

After the computer system completes the project phase (design, implementation and validation) the computerised system starts the operational phase. Many companies file the validation documentation away safe ready for when an inspector calls. While this approach is fine for the documentation that makes up the snapshot of the validation status (for example test protocols) the lifecycle documentation must be kept at hand to support the operational phase.

Lifecycle documentation should be kept up to date, to accurately reflect the operational system (to maintain operational compliance) and also to support the continued development and maintenance of the system.

The lifecycle documents provide a description of the computerised system, the related functions and the use of the system. These include but not limited to:

• Functional Design Specifications
• System Description (if not included within other design documents)
• Detailed Design Documents (software / hardware specifications)
• Drawings (Process Flow, Process and Instrumentation Diagrams, electrical diagrams, etc)
• Risk Assessments
• Validation Reports
• Operational Compliance Documents

While it is important to maintain all the lifecycle documents of a computerised system this post concentrates on the maintenance of the risk management documents.

Computer System Incidents

When a deviation or an incident occurs the root cause should be identified. Tools such as Fault Tree Analysis or Fish Bone Diagrams can be used effectively to support the root cause analysis.

At the time of performing the root cause analysis the risk assessment generated during the design should be reviewed. This is usually a Failure Mode Effect Analysis (FMEA) risk assessment. The assumptions made at the time of the analysis relating to occurrence and detection should be challenged and whether the incident was considered during the initial review.

The updates to the risk assessment based on the operating history change risk priority or risk ranking scores and require additional controls to be put in place to reduce the risk to an acceptable level. For example if it was considered that the likelihood of an event occurring was very low but from the operating history the event happens frequently then the overall risk priority increases, which may require the new technical or procedural controls to be put in place to reduce the occurrence.

ICH Q9 provides guidance on risk review

The output/results of the risk management process should be reviewed to take into account new knowledge and experience. Once a quality risk management process has been initiated, that process should continue to be utilized for events that might impact the original quality risk management decision…….

The key to ensuring an efficient process is to continually review and document risks when events occur.

In addition the initial impact of the failure should be used to support the criticality of the assessment during the incident root cause analysis. For example if an initial risk assessment had determined that the security of the system had a medium risk associated with it (computer system does not provide access to critical parameters or hold high impact records) then the impact of the deviation should also be assessed as moderate or medium. It should not be elevated to Major or Critical out of context of the original assessment.

Any proposed changes to the system should include a review and updating (where applicable) of the risk assessment. Whether the change is due to an incident or other reason (process improvement) then the original controls put in place to reduce identified risks should not be adversely impacted by the change or new quality risks created.

Conclusion

By ensuring that risk assessments are maintained, updated and reviewed throughout the lifecycle of the computerised system the effort in planning changes and handling incidents should be reduced. Without maintained computer systems lifecycle documents then the with each change or incident investigation the system owner re-invents the wheel having to determine how the system works and considering all the risk scenarios.