In the last "Focus on Quality" column (1), I noted that the risk analysis methodology used in the GAMP Good Practices Guide for Validation of Laboratory Computerized Systems (GPG) (2), which was based upon failure mode effect analysis (FMEA), was too complicated. The rationale was that we purchase mostly commercial software in regulated laboratories that already has been tested by the respective vendor. Therefore, why do we need to potentially repeat work that has already been performed?

Before we begin this discussion, it is worth mentioning that I have written a paper on risk assessment at the system level, and determination of how much validation is required has been published recently by Advanstar Communications (3). This publication looked at the nature of the software used in the system and the impact of the records produced by the system to determine how much validation was required. The outcome if validation was required was one of two options: Full validation based upon a system implementation life cycle when the detailed steps to be undertaken are defined in a validation plan for the system. Lower-risk systems could be validated using a single integrated validation document that defined the intended use, security and access control, compliance issues, and preservation of the records produced by the system.

In this column, I want to go into more detail and compare the FMEA used by the GPG with a simpler and, in my view, quicker risk analysis methodology called functional risk assessment (FRA).

Document Your User Requirements

Before beginning the discussion, what should be our starting point for the risk analysis and risk assessment?To be effective, any risk analysis is based upon available information (4). Therefore, the best source of this is the user requirements specification (URS). When you are conducting a risk assessment at the requirements or functional level, the URS should be relatively complete. This means that you have a good understanding of what the system will be doing, and this is reflected in the quality of the user requirements. If you don't have this, there is little point in going further, as you will be wasting your time regardless of which risk methodology you select.

Modified FMEA

Figure 1: GAMP risk assessment process flow (based upon Appendices 1 and 2 of reference 2).

The risk assessment methodology approach flow chart used in the GPG is shown in Figure 1. It is a two-phase approach that determines first the system risk, then at the functional level the hazards, the probability of occurrence, and their severity to identify and prioritize the risks that could occur when using the system.

The process works as follows and is divided between assessing the overall system impact and testing priority of the hazards of the individual functions that comprise it:

1. Classify the system. This uses the seven different categories between A and G as we discussed in the previous column (1) and assesses the technical complexity of a system.

2. Next, the business impact of the system is determined. This is a plot of the compliance risk (assessed as low, medium, or high) versus business risk based on the importance of the system to the business (also low, medium, and high). This determines the business impact as a single figure between 1 and 5 (a range from very low to very high), shown in Figure 2.

Figure 2: Determination of business impact of a system (adapted from reference 2).