14.07.2014 |

LOGFILE No. 32/2013 - Risk Assessment for Computerized Systems - GMP News

Risk Management for Computerized Systems

An Excerpt from "Computer System Validation in the EU"

ISPE GAMP® 5 underscores the importance and significance of a risk-based validation approach. In many sections, Annex 11 also refers to and requires a risk management process. Professional and comprehensive risk management is a complex process and calls for at least basic knowledge of the methods and standards.

Initially three basic questions should be discussed before performing computer validation:

Why should a risk assessment be performed?

In the design and implementation of validation, quality decisions must be taken in various phases:

  • with regard to the classification of the validation object in the software category or categories,
  • to define the test scope and depth,
  • to select the supplier assessment method,
  • to install a software upgrade or patch,
  • to use electronic signatures, etc.

These decisions should be taken to ensure that the potential risk of an error or damage is reduced.

Furthermore, decisions should be documented in a manner that is comprehensible and transparent. Risk assessment is a suitable approach for justifying decisions in documented form and/or defining implementation measures.

When should risk assessment take place?

Risk areas exist that concern the process, the product or the patient. But other risk areas exist in the form of the technical implementation and system and change risks. Consequently, a single risk assessment for a particular project cannot cover all aspects. The different methods mentioned below should therefore be chosen appropriately for the application concerned; for some examinations in-depth risk assessment can be comprehensive or also brief. However, the results obtained from the risk assessment should in all cases be comprehensible and adequately justified.

A risk assessment should be performed at the time when a decision has to be taken. Examples include:

  • Assessment of the GMP relevance of the system
  • Using an electronic signature
  • Defining the test depth for various functions
  • Planning system changes (such as version upgrade of the database or changing the operating system)
  • Evaluating the deviations from the supplier assessment
  • Selecting the IT security concept and management
  • Changes to the project organization
  • Selecting suppliers or service providers Selecting a technology.

What are the results of a risk assessment

As a result of a risk assessment, decisions are taken regarding risk-reducing measures that need to be implemented on a technical or procedural basis. In this context, the requirement to provide proof in accordance with Annex 11 should once more be pointed out explicitly: “Where a computerized system replaces a manual operation, there should be no resultant decrease in product quality, process control or quality assurance.

There should be no increase in the overall risk of the process.” This means that a manual process can always be compared with a computerized process and it must be subjected to a risk assessment.

Risk analyses are designed to help determine the critical factors in systems and plants or processes and to derive the required activities. In ICH Q9 Quality Risk Management — since early 2011 implemented in Part III of the EU GMP Guide — selected methods for achieving this are presented that also affect computer validation:

  • Failure Mode Effects Analysis, FMEA
  • Hazard Analysis of Critical Control Points, HACCP
  • Fault Tree Analysis, FTA
  • Ishikawa Method (Fishbone Analysis)

The pharmaceutical manufacturer or system owner is responsible for the method selection. The risk analysis must be performed on the basis of a comprehensibly defined and approved procedure. These methods will not be examined or explained in detail here; a complete and freely available “Briefing Package” for risk management was published in the context of ICH Q91. The various methods are presented there, some also with functional practical examples for computer validation. In addition to those methods, a decision matrix can be created, which can be helpful with various options.

The ISPE GAMP® 5 Guide intensively promotes a risk-based or scientifically based validation strategy, since because of the complexity and large number of systems and processes such an assessment/ precise specification is urgently required.

Figure 1 shows — in dependence on GAMP® — how the risk priority can be calculated. The table on the left shows the combination of risk likelihood and business impact. The resulting number (3 x 3 = 9) is then transferred to the table on the right and multiplied with the respective classification for the probability of no detection. The same procedure applies to medium (2 x 2 = 4) and low (1 x 1 = 1) risk as calculated in the table on the left.

Image

Fig. 1: Determining the Risk Priority (following GAMP® 5)

In practice, however, classification in the three categories proposed there (high, medium and low) is, according to the type and degree of detail of the analysis, generally not sufficient. The risk indicators and their meaning and the assignment of the risk areas to the resulting risk numbers must be defined  inambiguously before the assessment. This can be achieved in a higher-ranking risk management SOP or in a risk management plan, which might be system-specific.

Risk management must always be employed on a multilevel basis:

  • for the initial assessment of a system’s validation relevance
  • for the process (product) risks
  • for system development (in productive operation: in the case of system changes).

A system’s validation relevance can always be determined by a predefined questionnaire. In this case the applicable regulatory requirements are referenced. These are also referred to as “predicate rules.” As leeway is left for interpretation in some cases here, too, the results can only be obtained on the basis of an empirical examination or using defined examination boundaries. One possible question could be, for instance, whether data that is generated, checked or recorded by the system is used in records that are required by regulations and what relevance this data has; in other words, which decisions are taken on the basis of the basic data created.

Use the FMEA method to assess process and patient risks. The other methods mentioned above are better for assessing risks in system development and can be processed using a questionnaire. This should be a mandatory part of the general development process. The development standard CMMI (Capability Maturity Model Integration), which is referenced by ISPE GAMP® 5, contains, for example, a separate chapter for risk assessment that presents risk probabilities and consequences on the basis of defined criteria.

In particular, the business impact and risk analysis of the referenced ITIL (IT Infrastructure Library) standard should be referenced as an example for the IT infrastructure (software Category 1). Various project management standards also refer to risk management as project delivery (Project Management Body of Knowledge (PMBOK), Chapter 11, Project Risk Management).

The QRM processes should be defined unambiguously in a procedure, here in particular for IT projects or computer validation. Risk management plans, standard templates for risk analysis and reports should be available as documentation and records. A risk assessment can be conducted on the basis of currently released and complete process maps or specifications. An assessment team must include various experts from the involved departments. It can make a great deal of sense for external subject experts and the supplier to participate. Under certain circumstances training must be provided for the risk management process and the procedure and how to implement it. The results and the defined measures from the risk management process must be verified accordingly. The planned measures for risk reduction must be completed properly in the defined timeframe.

1http://www.ich.org/products/guidelines/quality/q9-briefing-pack/briefing-pack.html

Icon LOGFILE-32-risk-management-for-computerized-systems.pdf

 

 
 
 

Comments