Design: Verification Vs Validation And Validation Vs Transfer

KarenA01

Involved In Discussions
Standard background information on what we are doing:
As I've mentioned before we are going for 13485 certification but we don't produce devices and are a small company...
We make enzymes/biologics via fermentation that once purified sufficiently may be used for inviro diagnostics or vaccine components among other things... So as a "component" supplier we know we are not required to be 13485, but we have been told from multiple sources that customer for such things strongly prefer their suppliers to be 13485 certified... So we are going for it (we got 9001early last summer)

We have been doing contract manufacturing but are now expanding to "develop" our own products, which will be biologics already on the market others ... We will develop our own fermentation and purification methods based on what is in the literature and our own experience with these types of things.

In that context what would be the difference between verification and validation?

In our case I would think verifying the product would be ensuring the final production process at manufacturing scale produces product that has the required biological activity per unit volume for the expected use, along with a measure of purity and identity (typically molecular weight by gel and/or retention by HPLC).

Validation I think would be ensuring the process can do it consistently (The old rule of thumb in pharma was being able to produce 3 consecutive lots that "passed" - Not sure how to do it otherwise)

Is that interpretation correct? If so verification and validation could be the same thing?
Does the verification have to be at full manufacturing scale? Validation obviously would need to be. Of course before going full scale we would make sure the process works at bench scale!

Section 7.3.7 says:
"Design and development validation shall be performed in accordance with planned and documented arrangements to ensure that the resulting product is capable of meeting the requirements for the specified application or intended use"

But Section 7.5.6 of the standard says in part:
"The organization shall validate any processes for production and service provision where the resulting output cannot be or is not verified by subsequent monitoring or measurement"

Which would imply that if the product (we sell by the manufacturing batch - so should be a homogenous "solution") can be verified after the manufacture of each lot, process validation would not be required...

Are these two causes in conflict or I am i misunderstand their applicability?

I'm not sure I an interpreting the standard correctly because at times for some things I find it difficult to figure out how "device" requirements map to purely biologic/chemical chemical products ...

One last question for design transfer... We are a small company so any full production scale experiments or process validations will be done by the manufacturing group as they are the only ones that can use that equipment...

If we do the 3 lot validation it would be with the final production method, formal batch record, bill of materials, all specs and testing methods would set and approved etc...

So if we do the process validation, the transfer is essentially done at that point with final approval of the 3 lot validation, master match record , test methods etc...

is that right?

Thanks,
-Karen
 

John Broomfield

Leader
Super Moderator
Standard background information on what we are doing:


We have been doing contract manufacturing but are now expanding to "develop" our own products, which will be biologics already on the market others ... We will develop our own fermentation and purification methods based on what is in the literature and our own experience with these types of things.

In that context what would be the difference between verification and validation?

In our case I would think verifying the product would be ensuring the final production process at manufacturing scale produces product that has the required biological activity per unit volume for the expected use, along with a measure of purity and identity (typically molecular weight by gel and/or retention by HPLC).

Validation I think would be ensuring the process can do it consistently (The old rule of thumb in pharma was being able to produce 3 consecutive lots that "passed" - Not sure how to do it otherwise)

Is that interpretation correct? If so verification and validation could be the same thing?
Does the verification have to be at full manufacturing scale? Validation obviously would need to be. Of course before going full scale we would make sure the process works at bench scale!

Section 7.3.7 says:
"Design and development validation shall be performed in accordance with planned and documented arrangements to ensure that the resulting product is capable of meeting the requirements for the specified application or intended use"

But Section 7.5.6 of the standard says in part:
"The organization shall validate any processes for production and service provision where the resulting output cannot be or is not verified by subsequent monitoring or measurement"

Which would imply that if the product (we sell by the manufacturing batch - so should be a homogenous "solution") can be verified after the manufacture of each lot, process validation would not be required...

Are these two causes in conflict or I am i misunderstand their applicability?

I'm not sure I an interpreting the standard correctly because at times for some things I find it difficult to figure out how "device" requirements map to purely biologic/chemical chemical products ...

One last question for design transfer... We are a small company so any full production scale experiments or process validations will be done by the manufacturing group as they are the only ones that can use that equipment...

If we do the 3 lot validation it would be with the final production method, formal batch record, bill of materials, all specs and testing methods would set and approved etc...

So if we do the process validation, the transfer is essentially done at that point with final approval of the 3 lot validation, master match record , test methods etc...

is that right?

Thanks,
-Karen

Karen,

Take a look at the definitions and you’ll see that we verify the designs (of processes, products and services) for conformity to input requirements.

We then validate the design to see it results in a process, product or service that works as intended. At this stage we may find our design input requirements are incomplete or what looks good on paper doesn’t work in practice.

Design is iterative (rarely right the first time) so we keep going back to adjust inputs (resources and controls) until we have reliable (and affordable) specifications for the process, product or service.

If you conflate verification with validation your design process (and customers) will not benefit from these interations..

John
 

KarenA01

Involved In Discussions
Take a look at the definitions and you’ll see that we verify the designs (of processes, products and services) for conformity to input requirements.

We then validate the design to see it results in a process, product or service that works as intended. At this stage we may find our design input requirements are incomplete or what looks good on paper doesn’t work in practice.

I think I understand how that applies to physical devices where one has to produce physical prototypes which require detailed designs to even produce each one them...

What is unclear to me is how that would apply to chemical/biological products where that is not the case.

Maybe it's just terminology because i come from a purely chemical background

For chemical/biological products you define the active ingredient and the required characteristics of the final product along with targets for cost of manufacture.

Basically we either achieve sufficient biological specific activity, purity, and stability along with a low enough material/manufacturing costs to be commercially viable or not...

The way I see it is that the design input is setting those parameters...The rest is development of the process/recipe to meet those 'inputs'.

First we make sure we can even produce the target molecule in-house (which may mean cloning an organism and inserting some genes and seeing if it is sufficiently expressed)- that would likely be considered Feasibility and not covered by design.

If it looks like we can reasonably produce it then we would proceed to optimization at small scale and then scale it up to production scale (much bigger tanks, columns etc - which can affect the processes - dissolved oxygen levels, mixing, heat transfer etc won't be the same - so one can not do a "final" verification until at that scale)

During each experiment in either phase, we check some of the physical properties of the product (or surrogates for them) during development. It is what guides development. What iterates is the production process to make a product that achieves those input requirements. That iterations can include different trace nutrients, buffer components (all GRAS of course) as well as process parameters.

In terms of the 'inputs', maybe the ranges for some of the things get tweaked for example we realize we can only make a lower grade because we can't get high enough activity or purity.

So we are "verifying" to some degree all during the development process until we get to a final recipe. The development process is doing those experiments.

It seems to me the 'official" verification need to be on product produced at the final process at scale - Which is wha is done for validation (if validation is needed!!! Still confused between the requirements 7.3.7 and 7.5.6 ).

BTW the dividing line between feasibility and moving into design and development which is covered by the standard is pretty fuzzy to me...

Can it be considered feasibility and not covered until we get to the point of scale up? If we don't get to point of deciding to try to scale up, it has no chance of becoming a product...

Basically I am unsure of how to map the development of these types of products to the requirements of 13485... but I need to ASAP!

-Karen
 

KarenA01

Involved In Discussions

Thanks john,

I guess I should have been more specific... While we would be developing the process to produce the enzyme in-house it would not be a new chemical entity - it would be an enzyme already on the market made by other companies. We would just develop our own process to make it.

That development could involve cloning and genetic manipulation to produce an organism to use as a biological factory to make the target enzyme (based on literature, expired patents and experience) ... or is some cases it could start with licensing a commercially available organism.

Once we know we can produce the enzyme, we then develop fermentation and purification methods to make it. First at small (laboratory) scale and then, if all goes well, scale it up to manufacturing scale.

While product development at a high enough level has a lot commonalities... the process specifics depend a lot on type of product.

Chemical API development has some things in common with that of biologics/enzymes but is not exactly the same (typically biologic processes are more complex and less understood and more variable then chemical)... Using a pharma drug analogy, we would be producing "generic" versions of enzymes.

That said, I think chemical and biologic product development have more in common in terms of process than developing device/mechanical/electronic products - which the 13485 is geared towards...

But I need to map the enzyme product development to 13485 and write SOPS tha comply with that standard...

And I can't even figure out how to draw an acceptable/defensible clear line between feasibility studies which would not fall under the standard, and design/development which does... never mind verification and validation!

Depending on how that line is drawn one could essentially do all the initial "design" on a small scale to determine if it is worth trying to scale up and commercialize and call it feasibility. , this is where costs and risks to the company are relatively low.

The output of the feasibility work (if successful) would then be a big part (an actual process and materials) of the inputs into "design and development process" covered by the standard, but which really is just scale up.

Logically that would flow, and is what people what it to be where I work want...
But that seems "wrong" to me because the bulk of the "development" work would have taken place "before" officially entering "Design and Development"...

But if not that, how does one delineate where feasibility ends and D&D begins?

Is it when you know you can actually produce the target enzyme (to any degree) through in-house fermentation (through an organism we produced or licensed?)

Is it when you know you can produce it in reasonable yields in small scale experiments?

Is it when you have enough data to evaluate if the production process would likely be economically when scaled up so you make the decision commit the resources to scale it up to try and commercialize it?

Can it not be until you have optimized yield at small scale and are ready to start scaling up?

How to draw the lines are not obvious to me, but can have significant impact on our product development process (and the head of Product development is allergic to paperwork!)...

I have to get the SOPs written ASAP now and am getting very nervous...

I have to put something together ASAP but as I said how to map the standard requirements to our development processes is still very unclear to me... and I'm feeling lot of pressure and am more than a little frustrated

Thanks,
-Karen
 

John Broomfield

Leader
Super Moderator
Karen,

Why not work with the process owner to analyze and capture what you already do?

Chances are that it will already conform to the requirements of the standard; where you think it doesn’t examine your process even more thoroughly.

You may find the process is missing a necessary control, write this nonconformity up as a corrective action request again with the agreement of the process owner.

Better not to impose your interpretation of the standard on your process.

John
 

Big Jim

Admin
Section 7.3.7 says:
"Design and development validation shall be performed in accordance with planned and documented arrangements to ensure that the resulting product is capable of meeting the requirements for the specified application or intended use"

But Section 7.5.6 of the standard says in part:
"The organization shall validate any processes for production and service provision where the resulting output cannot be or is not verified by subsequent monitoring or measurement"

Are these two causes in conflict or I am i misunderstand their applicability?

-Karen

Don't mix these two. They are not in conflict with each other. Design validation is performed to ensure the final product is suitable for its intended purpose.

Process validation is applied when you cannot confirm the outcome by verification (normal inspection). Such processes are often referred to as "special processes". Some of the poster children or special processes include welding, soldering, brazing, plating, and coatings. For the most part the only way to determine exactly how effective the process was performed is from destructive testing.

Welding, for example, requires penetration into both sides of parent metal. This is determined by pulling the weld apart and seeing if it pulls metal from one side or the other, that is that it doesn't separate along the seam. Because this is a destructive test the resulting part would not be usable. A common way of validating welding is to certify the welder. The welder is trained on how to properly weld and then he submits samples of his welding for testing. Often that includes a volley of nondestructive testing (x ray, mag particle, and dye penetration for example) followed by a destructive test. The wider the certification the greater the number of the samples needed accounting for types of material, thickness of material, type of joint, and welding position. It is safe to assume the welding of a properly certified welder is safe to use.

Further reading of the letters following 7.5.6 provide examples of other ways to validate special processes.

I hope this helps.
 

KarenA01

Involved In Discussions
Why not work with the process owner to analyze and capture what you already do?

Up until now there has been no framework or documentation requirements with respect to development here... development here historically has always been very informal without specific inputs or outputs, reviews/ reports etc...

Doing development under a quality system is a HUGE (and difficult) cultural shift here, which many want to minimize as much possible... and still get 13485.

We were originally doing development for a number of products for very different industries for a good number years based on some core technology we have (but is not relevant to what we are doing now). These were commodity products with long term plans for making them at VERY large scale.

We actually accomplished a lot, but that development work was done without any sort of quality system or much of any formal traceable records. It was a rather unique environment which is hard to explain if you have not experienced it...

When we pivoted to contract manufacturing a few years back was when we implemented ISO9001, but initially with a design exclusion... so the R&D people had minimal involvement...

But now we decided to develop our own biologic products and get 13485... Which means a more formal Development framework needs to be established, something that does not come naturally to the head of the product development group (he takes a more "artsy"/ gut approach to development).

So while i understand what you are saying and why you are saying that, from a practical perspective I need to get a proposed D&D framework in place that can at least be debated...
And it has to be done quickly because of our certification timeline.

BTW until we pivoted to contract manufacturing, for most of the my 12 years years here I was part of R&D. I established and was in charge of the Analytical R&D department supporting the development of all the products we were working on. In my previous job I was the associate director for analytical development at a pharmaceutical drug delivery company.

Being the head of QA and QC, instead of in R&D, is new for me too.


Thanks,
-Karen
 
Last edited:

KarenA01

Involved In Discussions
Don't mix these two. They are not in conflict with each other. Design validation is performed to ensure the final product is suitable for its intended purpose.

I was wondering about that...

Process validation is applied when you cannot confirm the outcome by verification (normal inspection). Such processes are often referred to as "special processes".

Why I found it a bit confusing is that for our types of products the methods of verification CAN (but does not have to be ) the same both for verifying each batch was well as verifying the product is suitable for intended purpose... A functional test may that determines degree of biological activity and may be part of batch approval as well as development verification.

Thanks,
-karen
 
Last edited:

John Broomfield

Leader
Super Moderator
Karen,

Up until now there has been no framework or documentation requirements with respect to development here... development here historically has always been very informal without specific inputs or outputs, reviews/ reports etc...

Doing development under a quality system is a HUGE (and difficult) cultural shift here, which many want to minimize as much possible... and still get 13485.

We were originally doing development for a number of products for very different industries for a good number years based on some core technology we have (but is not relevant to what we are doing now). These were commodity products with long term plans for making them at VERY large scale.

We actually accomplished a lot, but that development work was done without any sort of quality system or much of any formal traceable records. It was a rather unique environment which is hard to explain if you have not experienced it...

When we pivoted to contract manufacturing a few years back was when we implemented ISO9001, but initially with a design exclusion... so the R&D people had minimal involvement...

But now we decided to develop our own biologic products and get 13485... Which means a more formal Development framework needs to be established, something that does not come naturally to the head of the product development group (he takes a more "artsy"/ gut approach to development).

So while i understand what you are saying and why you are saying that, from a practical perspective I need to get a proposed D&D framework in place that can at least be debated...
And it has to be done quickly because of our certification timeline.

BTW until we pivoted to contract manufacturing, for most of the my 12 years years here I was part of R&D. I established and was in charge of the Analytical R&D department supporting the development of all the products we were working on. In my previous job I was the associate director for analytical development at a pharmaceutical drug delivery company.

Being the head of QA and QC, instead of in R&D, is new for me too.


Thanks,
-Karen

Karen,

Enable yourself and your colleagues to appreciate the system of which you and they are already part. Together examine the processes and their interactions working as a system already to help people to understand and fulfill requirements.

Partially documented systems usually evolve to the extent necessary for effective planning and control (mostly!) otherwise you’d be out of business.

Engage your colleagues in understanding and improving this work-based system (that already is implemented) instead of creating a set of documents and imposing it on them.

For this I’ve found that deployment flowcharting works best in capturing the existing processes and their interactions as the system.

Search here for developing process-based management systems. Here is an example of the search results: (broken link removed)

Best wishes,

John
 
Top Bottom