If you find the information within this blog useful please take the time to support the site and visit one of the Google advertisers.


17 May 2010

Computer System Impact / Risk Assessment

Purpose of Risk Assessment

The purpose of the risk assessment process is to ensure that the validation (quality) effort is directed at the systems that have the potential to impact product quality, efficacy and data integrity (throughout this article referred to as Product Quality).

Initial Risk Assessments

In the ISPE Commissioning and Qualification Guide the approach to an initial impact assessment was first introduced. This was designed to ensure that only systems that have the potential to impact product quality require formal validation.

The impact assessment process had selections.

  • Direct Impact - A system that is expected to have a direct impact on product
  • Indirect Impact - A system that does not have a direct impact on product quality
    but is linked to / supports a direct impact system.
  • No Impact – A system that does not have the potential to have an impact on
    Product Quality and is not linked to or support a direct impact system.

Only systems that have a Direct Impact on Product Quality require full formal validation. Where systems are identified as Indirect Impact then the interfaces to the Direct Impact System should be considered. No Impact systems do not require formal verification and should be installed following Good Engineering Practices (GEP).
While this impact Assessment provides guidance as to what systems require validation it does not support the level of validation required. At the early stage of the process a Risk Assessment can support the approach and level of software validation required.

Computer System Risk Assessment

GAMP 5 supports the approach of performing an initial risk assessment to determine:
  • What are the risks to the business
  • System GxP Determination
  • What is the overall impact of the system
  • Determine if more risk assessment are required
This provides the impact assessment and some planning. However even at the early stage of the project a simple risk assessment can provide guidance to the Computer Systems Validation requirements, based on
  • Product Quality / GMP Impact
  • Complexity of the Process
  • Stability of the Software (GAMP Category)
From the combination of these items a number of recommendations can be made. This includes
  • Supplier Audit requirements
  • Software development controls (e.g. Source Code Review)
  • Design Documents (Functional Design Specification, User Manuals, etc)
  • Further risk assessment (Component Assessments, FMEA, etc)
  • Test Documentation
  • These recommendations as to the validation requirements can be automated in a spreadsheet, based of a combination of the Impact, Complexity and GAMP category.
In future posts I will provide examples of this Impact / Risk Assessment process for computerised systems. If there are any specific examples that you would find useful then please post them within the comments.

No comments:

Post a Comment

All comments on the computer systems validation blog are welcome.