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 Similarity Between Device Master Records & Chocolate Chip Cookies [Video]

The device design once complete, must be adequately transferred to manufacturing. This is typically accomplished through product specifications, standard operating procedures, work instructions and training.

Collection of Documents

Often a product specification is thought of as a document. The reality is the product specifications should be thought of as an association of written documents.

The product specifications typically include:

  • Assembly drawings
  • Component procurement specifications
  • Manufacturing instructions
  • Inspection
  • Test instructions
  • Digital data files
  • Manufacturing fixtures (jigs and molds)
  • Training materials
  • Artwork associated with labels
  • Acceptance criteria
  • Etc

Device Master Record (DMR)

The ultimate document to ensure adequate design transfer is the Device Master Record, or DMR.

The DMR is somewhat theoretical in that it is really a compilation of all the documents which are needed to realize the product.

For that reason, the DMR, is often established as an index which simply lists all of the documents needed to realize the product.

Contents of the DMR

The DMR typically includes the following documents:

  • Product specifications
  • Work instructions for device realization
  • Device history records/Forms to generate device history records
  • Component drawings/Specifications
  • Label artwork/Specifications
  • Test/Inspection methods
  • Software/Firmware
  • Validation Master Plan (VMP)

Since these documents may be revising and changing and may be at various distribution points, the DMR typically is an index of all the documents.

Chocolate Chip Cookie Analogy

One very common analogy is to envision the DMR as a chocolate-chip cookie recipe. If the DMR is complete, by providing the DMR to someone they can make the exact same chocolate-chip cookies.

While this is somewhat simplified, it’s an excellent analogy, but in order to make the perfect chocolate-chip cookie we would want specifications for the grade of flour, chocolate chips, sugar and other components.

We’d also like to know which equipment was validated, how they are tested/inspected, what are the instructions for each processing step, etc.

If we have all the relevant information we can reproduce the cookies exactly.

The DMR is the key to any successful design transfer whether it is an internal transfer to manufacturing or a transfer to a Contract Manufacturing Organization (CMO).

1
shares

Similar articles:

The Four Phases of Conducting a Laboratory Investigation [Video]

The process which will be described here is based on the process discussed in the MHRA’s guidance on Out of Specifications Investigation.

When an out of specification, atypical or suspect result is obtained, it is particularly important that all solutions and reagents associated with the test are retained, as this will greatly assist the investigation.

The MHRA advocate laboratory investigations should proceed in four phases as follows:

Phase I(a)

Phase I (a) consists of a preliminary review, by the analyst, to determine whether there has been a clear and obvious error or event that caused the OOS, atypical or suspect result.

Phase I(b)

Phase I (b) occurs after phase 1(a) has failed to identify a clear and obvious cause. This is a more detailed investigation by the analyst and supervisor to identify a laboratory assignable cause.

Phase II

Phase II occurs after the phase I investigation has failed to identify a laboratory assignable cause for the OOS, atypical or suspect result and are driven by written and approved instructions in order to test particular hypothesis.

Phase III

In Phase III all the information obtained during Phases I and II of the laboratory investigation, and any manufacturing investigation, is reviewed and assessed, and a decision is made on the disposition of the batch

Learn More About Laboratory Investigations

If you would like to learn more about laboratory investigations click here for an overview of this course.

2
shares

TOP

Similar articles: