|
|
RE: Retrospective Validation - A slightly different viewpoint
|
Title: RE: Retrospective Validation - A slightly different
vi
And I guess that the first question that will
come up: is this still the system the users want/need? If the GAP with
the user's intended use is big, no amount of paper will validate the
system. The system's unsuitability for today's user needs is the major
risk to retrospective validation.
Paul Herremans
-----Original Message-----
From: Ed.Crosson@aventis.com [mailto:Ed.Crosson@aventis.com] Sent: Wednesday, 8 May 2002 17:15 To: PharmWeb Computer Validation Subject: RE: Retrospective Validation - A slightly different viewpoint My suggestion would be to sit down with a cup of
strong coffee and relax.
Having done tha, start figuring out what it will take for this system to be validated - the word with the really big "V". Maybe figure out where you are right now, and what the difference in states is. Once you figure this out, you might want to come up with a plan (some might call it a "validation plan" (original, nicht war?) Then you'll know for yourself what is the first
"required activity".
Ed Crosson
Aventis Pharma My opinions are mine. -----Original Message-----
From: Anthony Fiorito [mailto:afiorito@hollisgroup.com] Sent: Thursday, May 02, 2002 10:14 AM To: PharmWeb Computer Validation Subject: Retrospective Validation - A slightly different viewpoint I have been pondering the subject of
retrospective validation. The subject
has come up again here, on other mailing lists, and at a conference I recently attended. The conventional wisdom seems to be that the first thing you should do is write a User Requirements Specification and everything else will fall out from that. After much contemplation, I must respectfully
disagree.
In my opinion, a User Requirements Specification
is far from the first task
and may not be necessary at all. Let me stir a little controversy into everyone's day and give you my opinion on the matter. And rather than get into a long winded and boringly dry technical discussion, and in honor of the new Star Wars movie coming out, let me add a little humor and tell a story of long, long ago in a galaxy far, far away. Imagine that you have just woken up on the desert
plant of Tatooine. You
find yourself in the body of Looke, a young QA rep at Galactic Pharmaceuticals Tatooine research lab. You're still trying to figure out how the heck you got here when DagobaBob, the droid systems administrator, comes in and tells you, "We just noticed that there is a little droid in the corner running the nuna density counter. We have no documentation on how he works but he's been there for years and everything has always run fine." He leaves. At that moment, a big guy dressed in black
crashes through your front door.
He's wearing a weird helmet and a badge that says "Darth 483, Imperial Food & Drug Agency". He looks at you and says, "Looke. I am your fa.... oops, wrong line... Looke. You must validate all your systems. Start with THAT DROID OVER THERE." At which point he waves his lightsaber menacingly at you and stomps out. You look up validation in your handy IFDA
glossary and it defines validation
as: "Establishing documented evidence which
provides a high degree of assurance
that a specific process will consistently produce a product meeting its predetermined specifications and quality attributes." You also look on the IFDA web site and, in the
"Guideline on General
Principles of Process Validation" find the term "retrospective validation" defined as: "Validation of a process for a product
already in distribution based upon
accumulated production, testing and control data." Now what. You have to "establish
documented evidence". The droid has been
running for a while so you know that you can lean on "accumulated production, testing, and control data" but one way or another you must provide that "high degree of assurance" yadda yadda yadda. So what should you do first?
(#1) Get the droid under change control.
If you don't get a fix on it
it'll be a moving target. Yes, dear reader, you are correct in that we don't know what our little droid does so it will be difficult to assess the engineering correctness of change, but from now on DagobaBob is going to have to document every time he changes out a motivator. I think that the URS-first crowd has assumed this step but I'd make a formal declaration of it for the benefit of the IFDA inspectors. (#2) Write a design specification. If
you don't know what it is you can
never understand it. Collect up any documentation that you can find; user manuals, parts descriptions, field engineering notes, etc. Write down all of the parts, where they're installed, what they interface with, and how they work (to the best of your understanding). At this point you may want to perform some functional tests to make sure that the droid actually does what you think it does. Does it perform all of the functions as written in the old user manual that you found? You may ask DagobaBob to write this part and then verify it by auditing DagobaBob and his staff and seeing for yourself. At the end of this step you should now have a
good idea what your little
droid does and you'll know that it won't change without you knowing about it. Darth 483 still gives you nightmares but at least you have something to show him when he returns. (#3) Verify the operation of the droid and
that the operation is in
accordance with your SOPs. Go through your Droid Operations SOPs and make sure that they're being applied. Is access to the droid controlled by your user accounts system? Is the droid being backed up? Is security set up according to your security policies and procedures. The net of this step is that you may either have to modify your droid operations activities or you may have to extend or expand your SOP set to include the things that are missing. You now have a droid that is in control, you
understand what it'd made of
and how it works, and you operate the droid in a rigorous manner in accordance with your SOP set. You will have a pile of accumulated documentation at this point which may include all sorts of stuff such as parts photocopies, a notebook of engineering data, user's guides, functional test scripts and results, etc. You might also start a log or notebook showing a history of proper operation. Depending on exactly what the little droid does you may have a whole history of nuna-free product batches that have passed all of the various post production QA tests that have been administered. Those nuna-free batches are significant accumulated proof of consistent production. Now, and only now, would I even begin to consider
whether I even want to
write a URS... which is another long-winded discussion which we can have later. Is your documentation enough to keep Darth 483 at
bay? Will you feel the
hot stab of the lightsaber? Or will Galactic Pharmaceuticals reward you with a delightful dinner of roast Ewok? All that may depend on Darth 483 but I would claim that you have a defensible position that shows understanding, control, and qualified operation... none of which gets delivered by trying to be a mind-reader of the original droid builders and attempting to skry their intent. Anthony Fiorito
VP Engineering The Hollis Group, Inc. 610 889 7350 afiorito@hollisgroup.com |
|
|