Regulatory Open Forum

The derivation of design verification plans and protocols is an exercise that (when done correctly) begins in the earliest stages of design and development. Specifically, the hidden nucleus of effective design verification is forged via the development of proper design inputs.  I can't overemphasize enough how vital design input development is for the ultimate success of the design verification (and validation) campaign.  Development of a solid foundation of design input requirements is, in my experience, the single most important design and development activity.  Indeed, FDA in its design control guidance document states, "…For complex designs, it is not uncommon for the design input stage to consume as much as thirty percent of the total project time…"

As I noted in a prior commentary, proper design inputs consist of functional, performance, and interfacial requirements that may spread across a variety of topics such as those listed below:

And as Edwin Bills hinted, there is indeed an upstream process for developing the design inputs themselves.  But like in my prior commentary, I'll save a discussion of that for a different thread so that we can stay focused here on the scope of this thread's question, which is aimed at deriving design verification plans.

A proper portfolio of design inputs is what ultimately beckons the particular design verification requirements necessary for a given design. To illustrate this principle, a couple hypothetical examples of common design inputs might be:

• The active implantable electronic device must meet ISO 10993-1:2018 requirements for permanent (> 30 days) blood contact.

• The active implantable electronic device must conform to ISO 14708-1:2014 Implants for surgery – Active implantable medical devices – Part 1: General requirements for safety, marking and for information to be provided by the manufacturer.

Once the inputs are properly derived, the framework of the design verification plan starts to quickly take shape, almost intrinsically; indeed, the verification requirements almost leap into view, even before the corresponding design solutions (outputs) are put forth. Specifically, in the foregoing hypothetical examples, the corresponding design verification methods would be those necessary to methodically challenge and evaluate the design's attributes against the parameters of the targeted ISO standards.  For example, verification planning and protocols would be needed corresponding to the applied elements of ISO 10993 requirements including but not limited to cytotoxicity, sensitization, implantation, etc.  And likewise, for safety challenges that track to the applied ISO 14708-1 safety clause(s).  And also for label/labeling design inspections addressing the ISO 14708-1 clauses for marking and information, and so on and so forth.

There are many benefits of operating the design mechanism in this fashion. Firstly, it's what's necessary to achieve and maintain regulatory compliance.  But also, if the developer has successfully born proper design inputs, then the scope and details of the design verification campaign and verification tasks can be visualized and planned with intelligent deliberation and with orderly intent rather than the guesswork that often led to safety issues and recalls back in the day before design controls became a requirement.  The old cliché "garbage in, garbage out" is as germane here as anywhere.

And by the way, the approach I've laid out also inherently boosts the chances that you'll have the proper test data and information later needed to navigate the confluence with the premarket regulatory clearance/approval process. Faithful practitioners may even find that the nebulae and mysteries triggering the need for FDA pre-sub meetings will be systematically clarified, thereby potentially streamlining the regulatory timetable.

Finally, another key element of properly constructing the design verification campaign is of course to clearly understand the fundamental goal of design verification as distinguished from design validation. That too could warrant an entire corresponding discussion.  But in a nutshell, accomplish design verification by performing the tests, inspections, and/or analyses needed to confirm whether the proposed design solutions (output) meet the corresponding device functional, performance, and interfacial requirements (i.e., the design input). Design verification answers the question, "Did we design the device and its manufacturing process properly?".  This is in contrast to the broader goal of design validation, which is instead to answer, "Did we design the right device and manufacturing process for the user(s) and manufacturer?".

Regarding templates, there are plenty of folks selling off-the-shelf QMS templates; just search the web. In fact, I've in the past purchased one or two myself for benchmarking purposes.  Consequently, I also (as you may have guessed) offer tools and services to help firms set up and operate their design control processes, as I've not yet seen other off-the-shelf templates that ever seem to strike a palatable balance between proper, comprehensive attention to design control principles like those aforementioned and the theoretical waterfall model, yet that also keep the process fluid, real-life-dynamic, implementable, and sustainable.  Oftentimes such templates are too robust, or too meager, or just plain noncompliant.

Hope this helps,

The derivation of design verification plans and protocols is an exercise that (when done correctly) begins in the earliest stages of design and development. Specifically, the hidden nucleus of effective design verification is forged via the development of proper design inputs.  I can't overemphasize enough how vital design input development is for the ultimate success of the design verification (and validation) campaign.  Development of a solid foundation of design input requirements is, in my experience, the single most important design and development activity.  Indeed, FDA in its design control guidance document states, "…For complex designs, it is not uncommon for the design input stage to consume as much as thirty percent of the total project time…"

As I noted in a prior commentary, proper design inputs consist of functional, performance, and interfacial requirements that may spread across a variety of topics such as those listed below:

And as Edwin Bills hinted, there is indeed an upstream process for developing the design inputs themselves.  But like in my prior commentary, I'll save a discussion of that for a different thread so that we can stay focused here on the scope of this thread's question, which is aimed at deriving design verification plans.

A proper portfolio of design inputs is what ultimately beckons the particular design verification requirements necessary for a given design. To illustrate this principle, a couple hypothetical examples of common design inputs might be:

• The active implantable electronic device must meet ISO 10993-1:2018 requirements for permanent (> 30 days) blood contact.

• The active implantable electronic device must conform to ISO 14708-1:2014 Implants for surgery – Active implantable medical devices – Part 1: General requirements for safety, marking and for information to be provided by the manufacturer.

Once the inputs are properly derived, the framework of the design verification plan starts to quickly take shape, almost intrinsically; indeed, the verification requirements almost leap into view, even before the corresponding design solutions (outputs) are put forth. Specifically, in the foregoing hypothetical examples, the corresponding design verification methods would be those necessary to methodically challenge and evaluate the design's attributes against the parameters of the targeted ISO standards.  For example, verification planning and protocols would be needed corresponding to the applied elements of ISO 10993 requirements including but not limited to cytotoxicity, sensitization, implantation, etc.  And likewise, for safety challenges that track to the applied ISO 14708-1 safety clause(s).  And also for label/labeling design inspections addressing the ISO 14708-1 clauses for marking and information, and so on and so forth.

There are many benefits of operating the design mechanism in this fashion. Firstly, it's what's necessary to achieve and maintain regulatory compliance.  But also, if the developer has successfully born proper design inputs, then the scope and details of the design verification campaign and verification tasks can be visualized and planned with intelligent deliberation and with orderly intent rather than the guesswork that often led to safety issues and recalls back in the day before design controls became a requirement.  The old cliché "garbage in, garbage out" is as germane here as anywhere.

And by the way, the approach I've laid out also inherently boosts the chances that you'll have the proper test data and information later needed to navigate the confluence with the premarket regulatory clearance/approval process. Faithful practitioners may even find that the nebulae and mysteries triggering the need for FDA pre-sub meetings will be systematically clarified, thereby potentially streamlining the regulatory timetable.

Finally, another key element of properly constructing the design verification campaign is of course to clearly understand the fundamental goal of design verification as distinguished from design validation. That too could warrant an entire corresponding discussion.  But in a nutshell, accomplish design verification by performing the tests, inspections, and/or analyses needed to confirm whether the proposed design solutions (output) meet the corresponding device functional, performance, and interfacial requirements (i.e., the design input). Design verification answers the question, "Did we design the device and its manufacturing process properly?".  This is in contrast to the broader goal of design validation, which is instead to answer, "Did we design the right device and manufacturing process for the user(s) and manufacturer?".

Regarding templates, there are plenty of folks selling off-the-shelf QMS templates; just search the web. In fact, I've in the past purchased one or two myself for benchmarking purposes.  Consequently, I also (as you may have guessed) offer tools and services to help firms set up and operate their design control processes, as I've not yet seen other off-the-shelf templates that ever seem to strike a palatable balance between proper, comprehensive attention to design control principles like those aforementioned and the theoretical waterfall model, yet that also keep the process fluid, real-life-dynamic, implementable, and sustainable.  Oftentimes such templates are too robust, or too meager, or just plain noncompliant.

Hope this helps,

The derivation of design verification plans and protocols is an exercise that (when done correctly) begins in the earliest stages of design and development. Specifically, the hidden nucleus of effective design verification is forged via the development of proper design inputs.  I can't overemphasize enough how vital design input development is for the ultimate success of the design verification (and validation) campaign.  Development of a solid foundation of design input requirements is, in my experience, the single most important design and development activity.  Indeed, FDA in its design control guidance document states, "…For complex designs, it is not uncommon for the design input stage to consume as much as thirty percent of the total project time…"

As I noted in a prior commentary, proper design inputs consist of functional, performance, and interfacial requirements that may spread across a variety of topics such as those listed below:

And as Edwin Bills hinted, there is indeed an upstream process for developing the design inputs themselves.  But like in my prior commentary, I'll save a discussion of that for a different thread so that we can stay focused here on the scope of this thread's question, which is aimed at deriving design verification plans.

A proper portfolio of design inputs is what ultimately beckons the particular design verification requirements necessary for a given design. To illustrate this principle, a couple hypothetical examples of common design inputs might be:

• The active implantable electronic device must meet ISO 10993-1:2018 requirements for permanent (> 30 days) blood contact.

• The active implantable electronic device must conform to ISO 14708-1:2014 Implants for surgery – Active implantable medical devices – Part 1: General requirements for safety, marking and for information to be provided by the manufacturer.

Once the inputs are properly derived, the framework of the design verification plan starts to quickly take shape, almost intrinsically; indeed, the verification requirements almost leap into view, even before the corresponding design solutions (outputs) are put forth. Specifically, in the foregoing hypothetical examples, the corresponding design verification methods would be those necessary to methodically challenge and evaluate the design's attributes against the parameters of the targeted ISO standards.  For example, verification planning and protocols would be needed corresponding to the applied elements of ISO 10993 requirements including but not limited to cytotoxicity, sensitization, implantation, etc.  And likewise, for safety challenges that track to the applied ISO 14708-1 safety clause(s).  And also for label/labeling design inspections addressing the ISO 14708-1 clauses for marking and information, and so on and so forth.

There are many benefits of operating the design mechanism in this fashion. Firstly, it's what's necessary to achieve and maintain regulatory compliance.  But also, if the developer has successfully born proper design inputs, then the scope and details of the design verification campaign and verification tasks can be visualized and planned with intelligent deliberation and with orderly intent rather than the guesswork that often led to safety issues and recalls back in the day before design controls became a requirement.  The old cliché "garbage in, garbage out" is as germane here as anywhere.

And by the way, the approach I've laid out also inherently boosts the chances that you'll have the proper test data and information later needed to navigate the confluence with the premarket regulatory clearance/approval process. Faithful practitioners may even find that the nebulae and mysteries triggering the need for FDA pre-sub meetings will be systematically clarified, thereby potentially streamlining the regulatory timetable.

Finally, another key element of properly constructing the design verification campaign is of course to clearly understand the fundamental goal of design verification as distinguished from design validation. That too could warrant an entire corresponding discussion.  But in a nutshell, accomplish design verification by performing the tests, inspections, and/or analyses needed to confirm whether the proposed design solutions (output) meet the corresponding device functional, performance, and interfacial requirements (i.e., the design input). Design verification answers the question, "Did we design the device and its manufacturing process properly?".  This is in contrast to the broader goal of design validation, which is instead to answer, "Did we design the right device and manufacturing process for the user(s) and manufacturer?".

Regarding templates, there are plenty of folks selling off-the-shelf QMS templates; just search the web. In fact, I've in the past purchased one or two myself for benchmarking purposes.  Consequently, I also (as you may have guessed) offer tools and services to help firms set up and operate their design control processes, as I've not yet seen other off-the-shelf templates that ever seem to strike a palatable balance between proper, comprehensive attention to design control principles like those aforementioned and the theoretical waterfall model, yet that also keep the process fluid, real-life-dynamic, implementable, and sustainable.  Oftentimes such templates are too robust, or too meager, or just plain noncompliant.

Hope this helps,