Click Here - To Download Your Own Free Pharmaceutical Glossary. Click Here to Download Your Free Vendor Audit Check List.


k

Good day and Hello,

 

Once again comments have appeared regarding that utopian existence – the no blame culture society.

I was with a company as a consultant who at middle management level declared they operated within a no blame culture.  It only took days to realize that the department head was incompetent (his incompetence turned out to be the reason my presence was required).  So does the incompetence of the perpetuators of this type of culture, drive them into trying to remove accountability, and hence responsibility?

The regulations governing and controlling the pharmaceutical industries are peppered with “must”, “will” and “shall”, all definite instructions to conform or comply with some rule or regulatory requirement.   There seems little or no option to interject and add “if you don’t, don’t worry about it.”

 

As for the regulators, at an FDA debrief, we were informally told that the penalty from deliberate miss-use of passwords should always be dismissal.  That sounds pretty blame free, does it not.

High on the list this month has been the subject of Vendor Auditing.  I have audited some of the largest companies around and some times with multimillion dollar contracts hanging in the balance. 

You have got to be well documented.  You are going to face some of the most able sales guys in the world, backed up with highly qualified engineers. 

However, your client, on your recommendation, is going to spend these vast sums purchasing a system that must be delivered, installed, commissioned and successfully validated, to a strict time scale. 

Do’s

Use a reputable known quality audit format.

Have a written justification for every audit question.

Demand document evidence of conformity for every question.

Use an analysis tool to reduce the audit summation to a percentage figure.

At the end debrief give them an honest overview (not detailed).

Don’ts

Accept verbal assurances – if they cannot show you documents they haven’t got it.

Allow them to set the pace - you know what you have to get through.

Stray from your approved documented questions.

Accept hospitality until the audit is finished.

Always remember:

There may be considerable sums involved.

There maybe reputations and even careers involved.

You could be challenged personally or professionally.

You could be ask to justify your audit by your client.

You may have to justify your audit in a court of law.

The Vendor audit document available from

http://www.validation-online/vender-audit.html has been used and developed over several years and was the actual document developed to audit all of the companies selected for the proposed DCS standardised system for Pfizer.   

 

There seems to be a lot on new people dealing with Part 11.  We are getting queries that I thought had been argued out four or five years ago.  However here we go.

Regarding software systems that the vendor states are part 11 compliant.  I could name and shame several large equipment companies that have and still are making such claims.  However, you cannot make system part 11 compliant if it does not have the basic functionality (as detailed in the rule).  When we are talking to clients, we usually advise that the software functionality comprised perhaps 66% of the requirement and procedures 33%, obviously very approximate estimates.  On the initial (for part 11) regulatory inspections, I was taken by surprise with the rigor applied to some of the security procedural aspects of the rule.

The biggest single problem with Part 11, is that it usually (definitely not always) applies to data, that if adultered, would adversely affect product quality.  We all know that this requires the equipment software validation, to be in accordance with requirements for Full Life Cycle Validation (FLCV).

Now the problems start, there is an almost endless list of laboratory, building management, ERP, planning, process and test equipment that uses developed software.  i.e. when software became available it was used as a nice aid to the user.  The software was then developed over the years – until suddenly Part 11 was required.  In some cases they went back to the drawing board, however in the majority of cases they patched basic Part 11 compliance, into a system that had evolved. 

With no concept, development, testing, or modification history or records it was and still is impossible to satisfy the FLSV requirements.  There are ways to get round this, but they are to protracted to detail here. 

    

Before the purchase of any such system the buyer must have a detailed URS, and vender must unequivocally guarantee fulfilling all of this URS requirements.

Alex Kennedy

Principle Engineer