Design Validation Conventions for Design History Files

N

NateDogg

Hi everyone,

I am curious to hear what other medical device professionals are considering Design Validation activities, and similarly which documents are being placed into the Design Validation part of a Design History File. This is focused on those activities other than Human Factors Engineering or Clinical Studies, which are more obviously part of Design Validation.

For example, would you consider Shipping Validation (to confirm that package contents are not damaged and that finished medical devices perform adequately following temperature and humidity conditions encountered during simulated or actual shipping processes) to be a Design Validation or Design Verification activity? Perhaps it can be both?

Would you consider Process Validation (to confirm a manufacturing process can produce a medical device that meets its specifications consistently) to be a Design Verification or Design Validation activity (or something else, perhaps a Design Transfer activity)?

I see various conventions in terms of where these activities fall in the design control process and where documents should go inside of the Design History File, so I appreciate any input on preferences and accompanying rationale from the forum. I prefer to follow a consistent approach, and I come across a lot of variations that I would like to harmonize in my work.

Thank you.
 

yodon

Leader
Super Moderator
Consider the classic 'V' model where you have user needs or sometimes called marketing requirements which then get elaborated into engineering requirements; e.g., system requirements, etc. Those top-level things are validated and engineering's elaboration of those are verified.

Shipping validation: yes. I don't consider it a verification because I tend to frame it as a user need level requirement.

Process validation: no. It's a manufacturing aspect and is not specified at either user needs or engineering requirements. Similarly, I wouldn't consider any non-product software validation used in development of the system part of design validation.

Other things that I typically include in validation: standards compliance (e.g., 60601) testing, cleaning validation, &sterilization validation. To me, these are framed as user needs. There are certainly aspects that are elaborated in engineering specifications and those get verified but demonstration that they meet user needs is the validation. One other thing: if the system contains software, I recommend "robustness" testing - doesn't verify requirements but demonstrates that the software stands up to use that will likely be encountered.
 
N

NateDogg

Your input is appreciated. I am curious in other opinions here as well, if they chime in.

Regarding process validation - do you not consider validating the process used to manufacture the device a form of confirming that you "designed the device right"? Perhaps Process Validation really belongs in Design Transfer as part of manufacturing readiness in the end, and should not be viewed in the context of V&V.

Always good to hear different viewpoints here. I appreciate it.
 
Last edited:

Ronen E

Problem Solver
Moderator
Hi,

Design Verification is a confirmation/demonstration that Design Output (the design documentation, for example drawings, specifications etc.) satisfies Design Input.
Design Validation is about the product meeting User Needs.

Design Input can be seen as an elaboration of User Needs, typically to an engineering level.

Design Verification is mostly about confirmation that can be drawn from design documentation, even before a physical product has been made. Some Design Input requirements can’t, or are difficult to, be shown to be satisfied through documentation / theoretical analysis, so actual product measurement / testing needs to take place. However, those are usually limited in extent to demonstration (lacking statistical rigor). Other than that, anything that involves product testing belongs to Design Validation, especially when the testing is directly against a stated User Need. Since Design Validation is about providing proof / confidence, it is usually more extensive than verification testing (even if the test method itself is identical); it accounts for real-world variability; and statistical rigor is expected.

In the DHF, the Design Validation section should include protocols, raw test results, analyses and detailed summary reports.

Shipping validation is usually part of Design Validation since it tests the product (including packaging system) as a whole, against the holistic need that the product arrives in good condition and is able to perform as intended at the worst case scenario and taking into account real-world variability of the main contributing factors (either controlled parameters or noise). On the other hand, some tests that may be considered part of shipping validation may also be part of Design Verification, if they are targeted at a specific, engineering-style requirement explicitly included in the latest approved Design Input (in such cases the sample size would typically be smaller and the goal would be “demonstrating” under typical conditions rather than proving under worst-case conditions).

I have seen organisations where Process Validation is indeed part of Design Transfer, though in my opinion it is a deviation from original intent. Design Transfer is not actually an activity in product/process development, but a mere act of making sure that all the necessary elements have been completed satisfactorily. I would consider Process Validation part of Design Validation because it addresses a user need that the design is able to be produced consistently under real-world variable conditions (User Needs are not related only to the medical device user(s); they should come from all stakeholders, including manufcacturing). I wouldn’t look at Process Validation as a proof that “the design is right” because it’s actually testing/challenging the process rather than the product (or its design).

I agree that cleaning validation and sterilisation validation are part of Design Validation. Standards compliance is borderline - it depends on the specific standards and the extent of testing. Some standard requirements can fall within Design Verification while others, due to their nature, belong to Design Validation. Some requirements may appear in both, at different levels of rigor.

Cheers,
Ronen.

Added in edit: Years ago I read somewhere that calling Design Validation “Design Validation” makes little sense because you can’t really validate something theoretical like design, and it should instead be termed “Product Validation”. I tend to agree. Sometimes it can help focus.
 
Last edited:

mihzago

Trusted Information Resource
I concur with yodon and Ronen E, in case you need another opinion (3 is a statistically valid number in validation, right? :) ).

'Design' in Design Validation term, or in any definition of Design Control (FDA) or Sec 7.3 Design and Development (ISO 13485) is a bit confusing term, especially to software developers. Developers will tell you they'd modified half of the code, but they had not touched the 'design'.

I think of Design Validation as an activity at a finished device level (or production equivalent) done in an intended environment or simulating intended environment.
 

Ronen E

Problem Solver
Moderator
I concur with yodon and Ronen E, in case you need another opinion (3 is a statistically valid number in validation, right? :) ).

'Design' in Design Validation term, or in any definition of Design Control (FDA) or Sec 7.3 Design and Development (ISO 13485) is a bit confusing term, especially to software developers. Developers will tell you they'd modified half of the code, but they had not touched the 'design'.

I think of Design Validation as an activity at a finished device level (or production equivalent) done in an intended environment or simulating intended environment.

Software is particularly tricky for parsing the regulations, because for the most part the regulations are (or at least were) written with physical products in mind. Some of the Design Control distinctions rely on the dichotomy documentation/product; but with software being “documentation” in itself (code) this distinction is almost useless.

I know some software people draw a line between source code - “design output” or “documentation” - and the binaries, which they consider the actual product. I’m not a software specialist so I don’t know how useful that approach is. I only know that every time I read the regulations, guidances and any suggested definition that’s supposed to clarify the borders with regards to software, it ends up being vague and confusing...
 
Top Bottom