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:

An Alternative View of the ICH Q10 Pharmaceutical Quality System (PQS)

The image below is that depicted by the International Conference of Harmonisation (ICH) Q10, Annex 2, and is supposed to depict a PQS or Pharmaceutical Quality System.

Typically, I really love the ICH. When we have to deal with outdated regulations from different global organizations it becomes a real nightmare trying to keep track of the nuances and the ICH has done a pretty good job of bringing several of the key organizations together and aligning them on how best to organize and meet the expected requirements.

That being said the diagram below and the depiction in Q10 of what a PQS should look like is greatly lacking.

Development Phases

In section 1.8 under the Quality Manual the ICH Q10 guidance states, “The description of the PQS should include: …(c) Identification of the pharmaceutical quality system processes, as well as their sequences, linkages and interdependencies.

Process maps and flow charts can be useful tools to facilitate depicting the pharmaceutical quality system processes in a visual manner”.

I completely agree.

The problem is using the graphical depiction they present in Annex 2 is completely worthless.

Basically they listed some of the PQS elements in a bar and then said they all apply to the entire product lifecycle, which simply isn’t true.

When we are in the development phase of our product lifecycle why would we do that under the change management system, or monitor process performance?

 

Controlling Change – No Value Add

There is no point in controlling changes for a product that is purposely being changed, nor does it offer any value to monitor the process performance for a process that has yet to be developed.

This isn’t a graphic depiction of the PQS, but rather a graphic of how they depict the lifecycle management (which also has some issues).

The PQS is the quality system and its subsystems and how they interrelate.

While it’s useful to look at how the PQS and product Lifecycle Management overlap and what elements of the PQS system are relevant at each lifecycle stage, it is not the point of the PQS, and even if that’s the end goal it’s not depicted here at all.

This image offers almost no value.

A Better Approach

So, what should this graphic look like?

While this is not a perfect view of a PQS, I would propose that the image below is a much better depiction of how the PQS should be visualized and a good place to start.

At the core of any quality system should be management. This goes back to Deming, who said, “Quality begins with the intent that is fixed by Management”.

Quality has to be rooted in the executive management team.

Define Core Quality Systems

Core quality systems then need to be defined. These are systems that impact all aspects of the business and include a Risk Management Policy, Resource Management, Document Control and CAPA systems.

All of the other subsystems, Deviations, Supplier Management, Equipment Qualifications, Validation, Material Management, etc, etc. all should be risk based or involve risk assessment, they all require resources and training, they call require documents (procedures, policies, records), and the CAPA system of course drives for process improvement regardless of the process.

Subsystems

All subsystems feed back into the main Management module. The subsystems listed, all are interconnected, with the exception of Post Market Systems.

The subsystems are important too, but they are farmed out to different groups and have different levels of importance depending on the stage of the product lifecycle.

Post Market Systems

The one exception is the Post Market Systems. This includes complaint management, product reviews, recall processes and other systems to support marketed products.

These generally do not interact with the other subsystems unless it is through the CAPA system or other management functions, but still utilizes all the systems under the management umbrella.

Alternate View

The PQS presented here, isn’t intended to be perfect, but I thought it was worth presenting an alternate view to the one presented by the ICH.

The ICH concept is a good one, and the ideas are fairly well laid out in the ICH, but the graphical representation of the PQS leaves a lot to be desired.

When establishing a PQS, it is better to start with something to what we’ve depicted here, and customize it as needed for the organization.

7
shares

Similar articles:

How 21 CFR Part 11.3(7) Applies to Electronic Batch Records [Video]

When dealing with Part 11 it’s important to understand what an electronic signature actually means

The definition of electronic signatures or e-sigs can be found in 21 CFR Part 11.3(7).

Electronic Signature

An electronic signature or e-sig means a computer data compilation of any symbol or series of symbols executed, adopted, or authorized by an individual to be the legally binding equivalent of the individual’s handwritten signature.

Handwritten Signatures

We also need to understand what a handwritten signature means in the context of Part 11.
The definition of handwritten signatures can be found in 21 CFR Part 11.3(8).

Handwritten signature means the scripted name or legal mark of an individual handwritten by that individual and executed or adopted with the present intention to authenticate a writing in a permanent form.

The act of signing with a writing or marking instrument such as a pen or stylus is preserved. The scripted name or legal mark, while conventionally applied to paper, may also be applied to other devices that capture the name or mark.

Electronic Batch Records

Eric works in a Pharmaceutical company and he is responsible for the filling process of the batch been manufactured.

Each time Eric performs the filling process he has to populate a batch record with the appropriate details

After each step Eric must also fill in his signature and date to verify that he actually performed each task.

Eric is manually handwriting these details and they are legally binding to Eric.

21 CFR Part 11.3(8)

This is when 21 CFR Part 11.3(8) applies.

Fast forward 12 months and Eric’s company has implemented a brand new Manufacturing Execution System (MES) where all details around the batch manufacturing process are recorded electronically.

21 CFR Part 11.3(7)

Now when Eric performs the filling process he now populates everything electronically and signs with his username and password combination to verify that he has performed those tasks.

This is when 21 CFR Part 11.3 (7) applies.

0
shares

TOP

Similar articles: