Design Input/Output and Design V&V (Verification and Validation) Interpretations

D

dweebie

#1
Hi,

I was wondering is someone could help me interpret the following statements I once heard from a Design control expert:

***********************************

Requirements = design input: broader than specifications and concern (are derived from) intended use(s) and user needs (testable natural language).

Specifications = design output: translates requirements into detailed measurable descriptions (engineering language).

Requirements must be verifiable i.e. quantified through specifications in a way that can be verified.

It might require several verification-results (against specifications) to demonstrate compliance to one single design input requirement.

*****************

To me this sounds as is requirements (design input) are verified by demonstrating that the derived specifications (design output) can be met, because the underlying assumption is that the specifications meet the requirements. Validation, on the other hand, is done by testing directly against the requirement (which represents the user needs and intended use). But how does this fit with: "verification must show that design output meets design input"?

I found an blog entry on mddi, which in my opinion supports the above, by stating that "design validation is really what happens near the end of the design or redesign of a medical device, it is done as a set of various activities to answer the question, does this design solution actually perform and function as I intend it to and does it meet my user needs. Design verification activities provide theoretical assurance that the design is appropriate in regards to your defined design input requirements, design validation provides evidence beyond theoretical that the device you designed is truly safe and effective within the context of those same design input requirements".

In additions to this, the FDA state in their "Medical device quality systems manual" that "design verification is always done versus specifications".

Do I understand the concept of verification and validation correctly? How do you interpret the above?

Best regards
 
Last edited by a moderator:
Elsmar Forum Sponsor

Marc

Hunkered Down for the Duration
Staff member
Admin
#2
<snip> "design validation is really what happens near the end of the design or redesign of a medical device, it is done as a set of various activities to answer the question, does this design solution actually perform and function as I intend it to and does it meet my user needs. Design verification activities provide theoretical assurance that the design is appropriate in regards to your defined design input requirements, design validation provides evidence beyond theoretical that the device you designed is truly safe and effective within the context of those same design input requirements". <snip>
Yup - That's it in a nutshell.

Verification = Theoretical (the old "According to my calculations...")
Validation = Actual as determined by testing (often done on a prototype, but in some cases validation is done through actual use - depends upon the product and the industry).
 
D

dweebie

#3
Thanks for your quick reply. I really appreciate it.

The blog entry's real message is that validation is more than user testing (which is a common misconception). As I see it right now, validation is basically about simulating use scenarios, to check that the device indeed does what is required of it in the real world post release, including by the users. This could concern e.g. driving a car into a wall (can our design really survive a real-life crash), taking a plane on its first flight (can our design really fly), confirming the shelf-life of a product through accelerated tests (can our design really last 2 years) etc.

Does this sound right?
 
Last edited by a moderator:

gholland

Involved In Discussions
#5
Validation is also ensuring your device meets the user needs. How you define your user needs is up to you but as you develop an idea you would have a set of user needs you are trying to meet. Something like 'the customer needs the device to be used in xxx environment' for example. Then you would go out and show that the device is usable in whatever environment you chose (laminar flow hood, clean room, whatever). You have to show that you understand what the user needs are and that your device meets them.
 
D

dweebie

#6
Thanks Gholland for your reply. I agree with what you say - validation is also about demonstrating that the device meets the user needs, in addition to intended use(s).

As I understand the literature on Design controls, user needs + intended use(s) are expressed as (organized into) testable design input requirements (the "what", written in a language that all stakeholders can understand), such as "the device must tolerate being used in xxx environment for the stated period of time" (similar to your example). Specifications are the "how" (translated from requirements), and are typically concept-dependent. The link between requirements and user needs is called requirements validation. The link between implementation and requirements is called design validation.

What do you think? Any comments anyone?
 

Marc

Hunkered Down for the Duration
Staff member
Admin
#7
Typically ensuring your device meets the user needs starts in the design stage prior to design verification. User needs is part of the design process "front end" inputs.

Validation is more "Does it work as intended".
 
J

Julie O

#8
21CFR 820.3 Definitions:

Verification means confirmation by examination and provision of objective evidence that specified requirements have been fulfilled.

Design validation means establishing by objective evidence that device specifications conform with user needs and intended use(s).
 
D

deethreepio

#9
I am dealing with a little different situation. It's a little off subject but I was hoping to get your opinion on the following:
If design validation is proving that a representative device meets the user requirements using objective evidence, and process validation is proving that a process can reliable create that same device, should IQ/OQ activities for process validation occur prior to design validation?

Thank you
 
J

Julie O

#10
D3, I just sent you a friend request. I'm thinking this will allow us to communicate offline, which is probably a better way to help you with this question.
 
Thread starter Similar threads Forum Replies Date
shimonv Design input/output traceability for mechanical parts ISO 13485:2016 - Medical Device Quality Management Systems 13
M Design Input & Output in Stages - Overkill? ISO 13485:2016 - Medical Device Quality Management Systems 16
sagai Are some Design Input elements part of the Design Output? 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 2
R Design Input/Output Form - Your feedback appreciated ISO 13485:2016 - Medical Device Quality Management Systems 3
T Design Input vs. Design Output - What constitutes Design Input? Design and Development of Products and Processes 11
L Looking for ISO 13485 Design Input and Output Files - Templates/Examples Design and Development of Products and Processes 2
sardonyx Design Input and Output Documents - Seeking specific examples - Medical Devices Design and Development of Products and Processes 7
T Design Input detail & specificity ISO 13485:2016 - Medical Device Quality Management Systems 4
L IATF 16949 Cl. 8.3.3.2 Manufacturing process design input - Process capability IATF 16949 - Automotive Quality Systems Standard 1
B IATF 16949 Section Clause 8.3.4.1 - Monitoring - Design and Development Input(s) IATF 16949 - Automotive Quality Systems Standard 3
S Referencing International Standards as Design Input Design and Development of Products and Processes 5
D Any Product Design Input sample for Colonoscope devices 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 2
Q When is a Design Input Good Enough? 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 4
A Are Software Requirements Specifications part of Design Input? 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 3
A Implementation of Design Input Requirements 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 1
L ISO 9001 Clause 7.3.2 Design & Development Input - Adequacy, Complete, Unambiguous ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 7
A Formal Way for Documenting Design Input Requirements 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 1
S Revise or to Not Design Input Document for On-Market Cleared Class II Device 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 1
D Design & Development Input Records Requirements - ISO 9001 Clause 7.3.2 ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 7
Sidney Vianna Looking for input on the design/syllabus of a 2-day AS9100 Transition Course AS9100, IAQG 9100, Nadcap and related Aerospace Standards and Requirements 7
W What is "Design Input" by QSR, 21 CFR Part 820 ? 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 6
J Preparation of Documents defining Design Input ISO 13485:2016 - Medical Device Quality Management Systems 10
GStough Risk Management Has to Begin Prior to Design Input, But... Design and Development of Products and Processes 10
P Design Input Proposal and Design Control Checklist Formats wanted ISO 13485:2016 - Medical Device Quality Management Systems 1
R Product Design Input as per TS 16949 clause 7.3.2.1 Design and Development of Products and Processes 9
D Design Input - Question on Specific Performance Criteria for Medical Devices Design and Development of Products and Processes 3
S Design Input class 3 device Design and Development of Products and Processes 5
K Design Input document example format/template needed Design and Development of Products and Processes 12
C Home made gage examples - Input to design new home made gages General Measurement Device and Calibration Topics 9
R Checklist for Design Input items for Medical Devices wanted Design and Development of Products and Processes 4
A Manufacturing process design input vs Design information checklist Design and Development of Products and Processes 1
M Design Input - 820.30(c) - Addressing incomplete, ambiguous... requirements Design and Development of Products and Processes 1
A What is the difference between Design Process, Process Design and Design Control? 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 2
D Test summary report example for design validation wanted - ISO 13485 ISO 13485:2016 - Medical Device Quality Management Systems 1
B Why the Greek god Hephaestus should have done a design FMEA (DFMEA) on his giant robot APQP and PPAP 1
S Documenting Design Verification Test Results (ISO 9001) Design and Development of Products and Processes 1
DuncanGibbons Understanding the applicability of Design of Experiments to the IQ OQ PQ qualification approach Reliability Analysis - Predictions, Testing and Standards 0
S Requirement to Conduct New Shelf-life Testing? (re-do testing for design change) EU Medical Device Regulations 3
A Sample Agreement available for Outsourcing Medical Device Design activity? ISO 13485:2016 - Medical Device Quality Management Systems 1
DuncanGibbons How is the arrangement between Design and Production organisation envisaged? EASA and JAA Aviation Standards and Requirements 4
L Design & Development of a SERVICE Service Industry Specific Topics 13
C Documentation for items used for Design Verification 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 4
P Design verification driven by new equipment. How is this different than process validation? 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 1
A AS9102B - 3.6 Design Characteristics and form 3 AS9100, IAQG 9100, Nadcap and related Aerospace Standards and Requirements 3
P Design FMEA - Detection Rating criteria ISO 14971 - Medical Device Risk Management 3
U Medical Device Design finalization testing ISO 13485:2016 - Medical Device Quality Management Systems 2
S MDR Delay - MDD design Change? (before new MDR DOA) EU Medical Device Regulations 8
J Iterative design and production for custom made products ISO 13485:2016 - Medical Device Quality Management Systems 3
J Design file for pre-existing products - Inputs and Outputs ISO 13485:2016 - Medical Device Quality Management Systems 5
D Design Transfer Template capturing Customer Specific Requirements Other Medical Device Related Standards 3
Similar threads


















































Top Bottom