Risk Based Approach to Validation

When we talk about validation and the requirement to validate even the simplest of software solutions, there is nearly always a negative, resistant atmosphere created straight away. Furthermore, even though the art of validation has evolved as have rules, regulations, best practices and various methodologies. Validation is a lifecycle which is living and breathing, it has matured with age and doesn’t have to be cumbersome anymore.

Whether you’re validating some simple equipment as part of a process or validating a large computerised system supporting 20,000 global users, a robust tried and tested method will serve you equally as well. The industry has moved into taking a risk based approach to validation and this makes perfect sense; adopt a proficient risk management methodology, identify your risks what can’t be easily and safely mitigated can built into the systems requirements and you’re more or less good to go.

Myth Based Approach to Validation

For years a lot of pharma businesses have taken the approach that in order to satisfy regulatory expectations that everything should be validated all of the time, this is simply not the case; in most instances validating everything, everytime is just a waste of time, money, human resources and the various rain forests of the world.

I don’t know whether this has yielded as a result of validation or quality personnel being afraid they’ll be blamed if something were to go wrong, or whether the governing corporate policies and procedures, especially of the largest pharma companies have interpreted the predicate rules in an ‘overkill’ fashion to cover their own backs in the long run. Either way, it doesn’t matter – as long as the risk assessment or assessments are facilitated properly and the right mix of stakeholders and subject matter experts (SMEs) attend then there should be no issue.

Use a Proven Methodology

There are numerous approaches to risk management and I think that the ASTM Standard “E2476 – Standard Guide for Risk Assessment and Risk Control as it Impacts the Design, Development, and Operation of PAT Processes for Pharmaceutical Manufacture” is a very good document and will provide anyone new to risk management with a lot of valuable information, not least about the process of risk management but there is also a lot of very critical references within this standard that are also invaluable. This information in this standard will be beneficial to anyone, regardless of their experience in the field of risk management.

One of the most important aspects of risk management is to get the right mix of SMEs, for example if a project was raised to install, say 5 additional controllers to a SCADA system to reduce the risk of the existing controllers being at the maximum level of usage most of the time, a good risk assessment would provide the basis for determination of the level of validation required. Firstly you’d probably already have a validation framework and documentation repositories that would cater for the change, but who would you invite to the meeting?

Skill Sections VS Actual Skills

An automation resource would be a good starting point, but after review – you’d need both a software and hardware engineer, why? Because these two people see the change as two different things, the software guy is concerned with programming of the hardware; the hardware guy is concerned about the capability of the hardware and the operating environment. From a software point of view, the controller can be managed from the data centre or via remote desktop through the associated software application, but this wouldn’t be accessible without the hardware having firstly been basically configured and installed. In addition, without an IT SME we wouldn’t know truly whether the network can facilitate the change; we’d need an operations SME to help co-ordinate any potential downtime that this new installation might take and we’d need quality and validation staff to prepare and approve documentation.

The bottom line is to remember that people see things from different angles – and quite rightly so! The more time spent up front on the risk assessment means that the validation effort is reduced and usually more robust to go with it. Try and get the relevant stakeholders on board and get them to agree to supply you with your SMEs, if this is a problem for whatever reason, such as people are on different shifts or busy in other areas when you need them then consider holding multiple risk assessment meetings so that all stakeholders and SMEs are involved formally and everything has been covered. A few risk assessments of between 1 and 2 hours each is nothing in terms of time being well spent, without these the validation effort could be exponentially greater not to mention the risk of risk.

A Pointer in the Right Direction

If you’re unsure where to start, ITIL and PRINCE2 have risk management methodologies. ICH Q9 is a Guideline for Quality Risk Management and there are many risk management sources and concepts listed in the E2476 standard (as mentioned above), GAMP also has a section on risk management. If your company already has procedures in place and you think they’re cumbersome, overkill or both – trying reading up of the sources of the methodologies outlined. You may well be surprised and find that they do actually facilitate a lean, risk based approach to risk management if you understand the overall subject matter better.

0
shares

  • DURGA PRASAD

    Great article.
    I think you must take some risk assessment points from ISO 14729 document too.
    I thank you for sharing such a good article.
    Regards

  • DURGA PRASAD

    Great article.
    I think you must take some risk assessment points from ISO 14729 document too.
    I thank you for sharing such a good article.
    Regards

  • George

    Good article. The knee jerk reaction that you must validate everything diminishes the effectiveness of the process and reduces the credibility of those involved. Getting the right people involved up front is the key. Thank you.

  • George

    Good article. The knee jerk reaction that you must validate everything diminishes the effectiveness of the process and reduces the credibility of those involved. Getting the right people involved up front is the key. Thank you.

  • siddhipharma

    Nice Article.
    It increase value reading if article contain link of “E2476 – Standard Guide for Risk Assessment and Risk Control ” too.
    Especially section “Skill Sections VS Actual Skills: was really very good.

    Regards’
    Ash!sh
    Director- Siddhi Pharma
    URl : www. siddhipharma.blogspot.com
    mail : siddhi.pharma@yahoo.com

  • siddhipharma

    Nice Article.
    It increase value reading if article contain link of “E2476 – Standard Guide for Risk Assessment and Risk Control ” too.
    Especially section “Skill Sections VS Actual Skills: was really very good.

    Regards’
    Ash!sh
    Director- Siddhi Pharma
    URl : www. siddhipharma.blogspot.com
    mail : siddhi.pharma@yahoo.com

Similar articles:

The Difference Between Qualification and Validation [Video]

There is a general saying within the life sciences:

“We qualify a system and/or equipment and validate a process”

A system and/or equipment must be qualified to operate in a validated process.

For example:

“You qualify an autoclave, whereas you validate a sterilization process”

Manufacturers should identify what validation and qualification work is done. All systems, equipment, processes, procedures should be reviewed and the manufacturer should decide what qualification and validation work needs to be performed.

Direct, Indirect or No Impact

All facility areas, utilities and process equipment must be assessed and classified as direct impact, indirect impact or no impact following an analysis of their impact on the identity, strength, quality, purity or safety of products manufactured at the facility and also the safety of the operators & environment.

Impact on Quality

Each system or item of equipment having direct or indirect impact on the product quality must be validated. The extent of validation or qualification should be determined by performing the risk assessment of that particular system or equipment.

Join the Discussion

Use our community to find our more about validation and qualification.
http://community.learnaboutgmp.com/t/qualification-vs-validation/874

22
shares

Similar articles:

The Difference Between Prospective, Concurrent and Retrospective Validation

Unless you’re starting a new company you will need to plan on a variety of approaches.

Prospective validation occurs before the system is used in production, concurrent validation occurs simultaneously with production, and retrospective validation occurs after production use has occurred.

In this article we will discuss all three and also discuss the role the master validation plan (MVP) performs for each one.

1. Prospective Validation

Prospective validation is establishing documented evidence, prior to process implementation, that a system performs as is intended, based on pre-planned protocols.

This is the preferred approach.

Production is not started until all validation activities are completed.

The MVP need not go into much detail about this approach since it’s the standard method, however, prospective validation follows a step wise process illustrated here.

The process commences with the development of a Validation Plan and then passes through the DQ, RA, IQ, OQ and PQ phases after which process, computer, analytical and cleaning validations are performed which are followed by a final report.

After which the instrument or equipment will be subject to preventative maintenance and requalification on a routine basis.

Periodic Basis

On a periodic basis all instrumentation and equipment should be reviewed. This review is intended to identify any gaps which may have developed between the time it was last qualified and current requirements.

If any gaps are identified a remediation plan will be developed and the process will start again.

The MVP

The MVP may need to describe what is done with product produced during prospective validation. Typically, it is either scrapped or marked not for use or sale.

The product may be suitable for additional engineering testing or demonstrations, but appropriate efforts need to be made to ensure this product does not enter the supply chain.

Ideally, all validation is done prospectively; i.e., the system is validated before use. However, there are cases and conditions which may prevent this.

2. Concurrent Validation

Concurrent validation is used to establish documented evidence that a facility and process will perform as they are intended, based on information generated during actual use of the process.

In exceptional circumstances (for example, in a case of immediate and urgent public health need) validation may need to be conducted in parallel with routine production. The MVP needs to define how product is managed throughout the process.

Typically, the product batches are quarantined until they can be demonstrated (QC analysis) to meet specifications.

The Right Decision?

The decision to perform concurrent validation should not be made in a vacuum. All stakeholders including management, Quality Assurance and the government regulatory agencies should all agree that concurrent validation is an acceptable approach for the system under consideration.

As always the principal requirement is patient safety is not compromised. The rationale to conduct concurrent validation should be documented along with the agreement to do so by all the stakeholders. This can be part of the Validation Plan or documented as a deviation.

The Process

The concurrent validation process is identical to that of prospective validation. The process starts with the development of a Validation Plan, followed by the DQ, RA, IQ, OQ and PQ phases after which process, computer, analytical and cleaning validations are performed, ending with a final report.

Again, routine preventative maintenance, requalification and periodic review are performed.

3. Retrospective Validation

Retrospective validation is validating a system that has been operating for some time. There are various schools of thought on how to approach retrospective validation. Some may feel that a full-blown validation is required to assure the system is functioning properly.

Others may feel that since the system has been in use, presumably without issues, validation is not necessary and a memo to file justifying why validation is not necessary may be issued.

Doing a full validation may not be required, since you already have proof that the system functions as required – at least in the situations in which production was conducted. Doing nothing, though, is a risk.

It’s likely that the controls haven’t been challenged so there may be some hidden flaws that haven’t been identified that could lead to non-conforming product, hazardous operating conditions, extended delays, etc.

Historical Data

Historical data can certainly be used to support validation. For example, if there is detailed and statistically-significant evidence that production runs are well controlled you could rationalize and justify not doing full validation.

During retrospective validation, it’s advisable that existing product be quarantined, and production put on hold until validation is complete.

As an exception, producing product as part of the validation exercise would follow concurrent validation. This may not be practical since product may have already been distributed, but caution is advised for the reasons outlined.

General Process

The general process for retrospective validation follows the same process as for prospective and concurrent validation except DQ is seldom performed, as the system has already been in use for some time.

Instead a survey and review of available information is performed. This normally occurs before the validation plan is created.

The MVP should also provide guidance on managing inventory during retrospective validation.

One Major Issue

One potential major problem that can occur with retrospective validation the determination of what action should be taken if an issue is found with the system during retrospective validation?

As with everything else, a risk-based decision is warranted. This could be anything from product recall, to customer notifications, to just documenting the justification of the decision why nothing was done.

Again, the MVP should provide guidance on dealing with situations concerning out of specification conditions revealed during retrospective validation, which should also definitely include involving regulatory support.

17
shares

TOP

Similar articles: