Design Output


Starting to get Involved
Hello Everyone

I am new to the role and I am working on Design History File for a class 2 medical device
I am struggling with Design outputs

I know the basics regarding what does it mean and for verification we have to show how design output meets design input. Area where I am struggling is in drafting it. As I know design output can be literally 1000 of different things from engineering drawing, schematics, etc
So in this traceability matrix I just have to put name and document number for the respective file of the output and for submission do we need to send these files as well?
Also for submission do we need to submit these output
Hoping to hear reviews and suggestion from you all

Thanking you in advance


  • Design Output
    60.5 KB · Views: 60
Last edited:


Trusted Information Resource
My experience has been that without some sort of automated design QA system it is very burdensome to list design output in the traceability matrix. Especially with software... you are not going to make reference to code module or lines.
What I have done was to omit this column ("least burdensome approach") and show traceability between inputs and verification/ validation activities, which is an evidence that there is appropriate design output in place.

Obviously, design output elements are doucmented in the DHF.



Trusted Information Resource
You will not have to submit all of the design outputs as part of a submission packet. Most will be represented in a BoM for the finished device, as well as being referenced in other documents (RMF, V&V paperwork, etc.)

I think you have (re)discovered that it is a practical impossibility to "flatten" a (multi-dimensional, relational) database into a 2-dimensional grid. The information in the database has to exist somewhere, but how you represent it to an agency is up to you.

A word of caution: 2-d representations of a relational database often leave the impression that a person can point to some "right side" element (typically these come into existence later in a development process) and want to see how that specific element satisfies something that looks like a "left side index key"... and that person doesn't want to know anything about the intervening traceability.

I realize what I wrote above sounds a little nebulous; I saw this happen with an auditor picked a specific unit test case(*1) and couldn't believe that it was evidence that a design input was satisfied. I got two distinct impressions from this (experienced) auditor:
  1. They had personal reasons for not wanting to dig into specifics of traceability, and picked what they thought would be "easy" (to prove or disprove the work was done, I cannot say)
  2. They had personal reasons for not wanting to accept key aspects of relationships in design controls, such as "one-to-many".
I categorized these as "personal" because I couldn't tell if the motivations were time-based, cognitive hesitancy, bias, whatever. I don't think the auditor was a bad one, the only real defect I could identify was they expected a single specific "answer" to a problem with many different types of solutions.

(*1) Unit tests are almost never recognizable based on a high-level design input; yet they still derive from them.


Involved In Discussions
I am with @shimonv. We do not include a "design output" column in our requirements traceability matrix. It's just Requirement --> Verification activity (usually a unique test case identifier).

Oftentimes there are many individual outputs that contribute to fulfilling a single requirement.
For example, you may have the following durability-related requirement: "The device shall operate as expected after a fall from a height of three feet."
Many, many things go into being able to meet this requirement. Your materials, their thicknesses, your construction methods, your connection points, etc. etc. You would go mad trying to list all of those in an excel sheet. And there would be little benefit in doing so.
In contrast, you will probably have just a single related test that says "drop the device from three feet, and attempt to perform actions A, B, and C. Record whether operations can be performed as expected." That test, and its results, are what you need to be able to trace to easily.
Last edited:

Ed Panek

QA RA Small Med Dev Company
Super Moderator
Good example. Some real world case is driving each requirement. If you sell an item that is shipped always on a pallet vs may or may not be palletized those requirements may point to ISTA standard testing. Standards are there to point to methods that are either scientifically valid or are based on industry standard.

You may have a sterility requirement. Rather than ad hoc a bio burden test and sterlize it and test the results ISO has a protocol for that testing.

This way when a customer asks about sterility you say we comply with ISO 10993 and immediately the customer knows what you did and how comfortable they are with it.


Quite Involved in Discussions
For an EU MDR submission, they will likely ask for every document you've referenced in your matrix (outputs and objective evidence). I know this because this happened to me :)

FDA probably will not ask for every component/output drawing as the verification/validation is generally more important, and you already have to submit drawings as part of other sections of the submission. For the most part FDA will already be asking for specific design outputs that they care about (e.g., packaging drawings, sterilization information, etc) so reviewing a drawing is not all that important.

I concur with everyone above who thinks that "design output" is not a very useful column. Your test reports/objective evidence should be clear enough to connect back to the design input. No need for the "design output" column if you can establish traceability between your inputs and the evidence.
Top Bottom