Design inputs are the complete set of requirements a medical device must satisfy — safety, performance, user needs, intended purpose, regulatory, and risk-driven. Under EN ISO 13485:2016+A11:2021 clause 7.3.3, every design input must be unambiguous, verifiable or validatable, not in conflict with any other input, and formally reviewed and approved before the design proceeds. The design input set is the contract between what you promised the user and what engineering will actually build. Get it wrong, and every later stage — verification, validation, clinical evaluation, and conformity against MDR Annex I — inherits the error.

By Tibor Zechmeister and Felix Lenhard. Last updated 10 April 2026.

TL;DR

  • Design inputs are the documented requirements that define what the device must do and under what conditions. They are the anchor point of the entire design file.
  • EN ISO 13485:2016+A11:2021 clause 7.3.3 requires design inputs to cover functional, performance, usability, and safety requirements; applicable regulatory requirements; outputs of risk management; and, where applicable, information derived from previous similar designs.
  • Each design input must be unambiguous, verifiable or validatable, not in conflict with other inputs, and formally reviewed and approved. That is four tests, and a requirement that fails any one of them is not ready to be a design input.
  • The sources of design inputs are user needs, the stated intended purpose, MDR Annex I GSPR, the risk management file, and applicable regulatory and standards requirements. A design input with no traceable source is a red flag in an audit.
  • The work that founders most often skip — the Subtract to Ship insight — is not writing the inputs, but disciplining them. Loose, un-reviewable, or untestable inputs quietly destroy the downstream work.

Why this matters for your startup

A Notified Body auditor opens the design and development file and goes straight to the design inputs. Not the prototypes, not the test reports, not the marketing deck. The design inputs. The reason is simple: if the inputs are wrong, everything downstream is wrong, and no amount of verification testing can fix an input that should never have been written the way it was.

We have seen startups spend six months on verification testing against a requirement set that nobody senior had read carefully. The tests passed. The auditor still failed the design file — because the requirement "the device shall be safe for clinical use" is not a design input. It is a hope. There is nothing in that sentence that a test engineer can measure or that a reviewer can argue about. It fails the unambiguous test, it fails the verifiable test, and it is the kind of sentence that tends to propagate through a design history file until someone finally has to rewrite everything.

Design inputs are the place where the Subtract to Ship discipline pays off most. Writing fewer but sharper requirements beats writing many vague ones. This post walks through what the standard actually demands, where design inputs come from, how to write them so they survive an audit, and the mistakes we see repeatedly in startup design files.

What design inputs actually are

Design inputs are the documented requirements that specify everything the device must do, must not do, and must withstand, under the conditions in which it will be used. They sit at the top of the design and development sequence described in EN ISO 13485:2016+A11:2021 clause 7.3, immediately after design planning (clause 7.3.2) and immediately before design outputs (clause 7.3.4).

Clause 7.3.3 states that inputs relating to product requirements shall be determined and records maintained. These inputs shall include: a) functional, performance, usability, and safety requirements according to the intended use; b) applicable regulatory requirements and standards; c) applicable outputs of risk management; d) where appropriate, information derived from previous similar designs; and e) other requirements essential for the design and development of the product and processes. The clause then adds the four tests: each input shall be reviewed for adequacy and approved; requirements shall be complete, unambiguous, able to be verified or validated, and not in conflict with each other.

This is a compact paragraph that carries enormous weight. Every word matters. "Complete" means the set as a whole covers everything the device must do. "Unambiguous" means a reasonable reader cannot interpret the requirement two different ways. "Verifiable or validatable" means there is a defined way to demonstrate the requirement is met — by measurement, inspection, test, or validated usage. "Not in conflict" means two inputs do not silently contradict each other in a way that forces the designer to choose. Any requirement that fails one of these is not ready to be a design input. It is a draft.

Where design inputs come from

Design inputs are not invented. They are derived. Every design input should be traceable backward to a source, and the sources fall into five categories.

User needs

User needs are the unmet problems the device is meant to solve, expressed in the language of the user. They are not requirements yet. They are the raw material from which requirements get written. A surgeon saying "I need to see the vessel clearly during laparoscopic dissection" is a user need. The design input that comes from it might be a specific minimum resolution at a specific working distance under defined illumination. The translation step from user need to design input is one of the most skipped steps in early-stage MedTech, and it is the one the auditor will ask about.

Intended purpose

The intended purpose, as defined in MDR Article 2(12) and as written in the manufacturer's documentation, is the single most important upstream source of design inputs. Every claim in the intended purpose has to be matched by at least one design input that makes the claim testable. If the intended purpose says the device measures a physiological parameter within a specific accuracy range on a specific patient population, there must be design inputs for the measurement accuracy, the population, and the operating conditions. If there are not, the intended purpose is a promise the design file cannot keep.

Annex I GSPR

MDR Annex I sets out the General Safety and Performance Requirements. Every applicable GSPR that requires a design decision becomes at least one design input. This is not a paraphrasing exercise. A GSPR like "devices shall be designed and manufactured in such a way that, when used under the conditions and for the purposes intended, they will not compromise the clinical condition or the safety of patients" is not a design input on its own — it is a regulatory obligation that translates into several specific inputs (biocompatibility limits, mechanical strength, electrical safety thresholds, and so on). Annex II of the MDR then requires the technical documentation to demonstrate conformity with each applicable GSPR. The design input set is where that conformity starts.

Risk management

EN ISO 14971:2019+A11:2021 produces risk controls. Every risk control that the design implements becomes a design input. This is one of the most consequential feedback loops in a MedTech design file: risk analysis identifies hazards, risk controls mitigate them, and the mitigations become requirements the design must satisfy. If a risk control exists in the risk file but not in the design input set, the mitigation is not actually being implemented — it is a promise without a referent. Auditors check this traceability carefully.

Regulatory and standards requirements

Applicable harmonised standards, horizontal requirements (EMC, electrical safety, biocompatibility), applicable parts of IEC 60601-1 for electrical medical equipment, EN 62304 for software, and any product-specific standard become design inputs where the standard specifies a testable requirement. Not every clause of every standard becomes a design input — only the ones that define what the device has to do or be, as distinct from how the process must run.

How to write unambiguous, verifiable design inputs

A well-written design input has four properties. It specifies what, not how. It specifies a measurable or observable attribute. It states the acceptance criterion. And it is traceable back to its source.

A weak input: "The device shall have a long battery life." A strong input: "The device shall operate continuously for at least 8 hours on a single full charge when running the standard measurement protocol at 25 degrees Celsius ambient, verified by bench test per the verification protocol DI-BATT-001."

The strong version specifies the attribute (continuous operation time), the acceptance criterion (at least 8 hours), the operating condition (standard measurement protocol, 25 degrees ambient), and the verification method (bench test with a protocol identifier). A test engineer reading it knows exactly what to measure. A reviewer knows exactly when the requirement is satisfied. An auditor can close the loop from requirement to test report without guessing.

Avoid qualitative words that have no defined meaning in the design context: "user-friendly," "robust," "reliable," "safe," "high quality." Each of these is a problem statement, not a requirement. If you find one in a draft design input, ask: what would I measure to know this is met? That measurement is the actual design input.

Avoid inputs that chain assumptions across multiple systems without stating them. Avoid inputs that silently assume environmental conditions, user competence, or operating modes. An auditor who is looking for non-conformities will read these assumptions back to you, and the design input will not survive the conversation.

Traceability forward — inputs to outputs to verification to validation

Design inputs do not live alone. EN ISO 13485:2016+A11:2021 clauses 7.3.4 through 7.3.7 connect them to design outputs, design verification, and design validation. Each design input must be traceable forward through the rest of the design file.

A typical trace looks like this. Design input DI-042 states a measurement accuracy requirement. Design output DO-042 describes how the accuracy is achieved in the architecture and component selection. Verification activity V-042 tests the implemented device against the input under the specified conditions. Validation activity VAL-042 confirms the device, in actual use by the intended user, meets the user need that DI-042 was derived from. The four records link in a single chain. The requirements traceability matrix is the tool that keeps the chain visible, and a good one is readable in one sitting by someone who has never seen the project before.

Forward traceability is what turns the design file from a pile of documents into a defendable record. It is also the single biggest thing a small team can do to make its own design work survivable. When a design input changes — because a user need shifts, a standard is updated, or a risk control is added — the traceability matrix tells you exactly which outputs, verifications, and validations are now out of date. Without the matrix, you have to rediscover the impact every time, and you will miss things.

Common mistakes startups make

  • Writing design inputs after the prototype exists. The team builds something, demonstrates it, and then retrofits design inputs to match what they already built. This is the single most common mistake we see in startup design files. It passes a superficial audit but fails the first hard question about why a specific choice was made.
  • Treating user needs and design inputs as the same document. They are related but distinct artefacts. User needs are in the user's language. Design inputs are in the engineer's language and are the basis for verification. Conflating them skips the translation step where the real work happens.
  • Hiding GSPR compliance inside a single sentence. "The device complies with Annex I" is not a design input. It is the outcome of having the right design inputs. The applicable GSPRs have to be decomposed into specific, testable requirements.
  • Forgetting risk controls. The risk management file identifies controls, and those controls never make it into the design input set. The control is then invisible to verification, and the risk mitigation only exists on paper.
  • Using unmeasurable language. "User-friendly interface." "Acceptable response time." "Sufficient accuracy." None of these are design inputs. They are the absence of design inputs.
  • Skipping the formal review. Clause 7.3.3 requires the inputs to be reviewed for adequacy and approved before they are released. A founder signing off on inputs alone, without a real review, is not the review the standard is asking for.

The Subtract to Ship angle

Design inputs are where Subtract to Ship discipline pays off early and compounds later. The instinct is to write more requirements in case something is missed. The Subtract to Ship move is the opposite: write fewer, sharper requirements, each one traceable to a specific source and each one verifiable in a specific way. A design input set of 80 tight requirements beats a design input set of 300 loose ones, because every requirement in the file becomes work downstream. Verification needs a test. Validation needs a use scenario. Traceability needs a link. Every loose requirement doubles as a future audit finding.

The rule we use: if a candidate requirement cannot be traced to a source (user need, intended purpose, GSPR, risk control, standard) and cannot be verified by a specific method, it does not go into the design input set. It goes back to the person who proposed it with a question: what are you actually trying to capture? Half the time, the real requirement turns out to be two specific requirements that were hiding inside the loose one. The other half of the time, the requirement turns out to be unnecessary and gets cut.

This discipline is uncomfortable the first time. It is a habit after the third time. And it is the single biggest reason lean design files survive Notified Body audits that heavier files fail.

Reality Check — Where do you stand?

  1. Can you produce a requirements traceability matrix in under 30 minutes that links every design input to a source and a verification activity?
  2. For each design input in your current draft, can you name the specific test, inspection, or validated usage that proves the requirement is met?
  3. Have every one of the applicable MDR Annex I GSPR been decomposed into specific, testable design inputs — not a single blanket statement?
  4. Is every risk control from your risk management file present as a design input, and is the link visible in the traceability matrix?
  5. Does every claim in your intended purpose have at least one design input that makes the claim testable?
  6. Has a formal design input review taken place with documented approval before the design proceeded to outputs, as clause 7.3.3 requires?
  7. If you removed the lowest-quality 20 percent of your design inputs and rewrote them to the standard in this post, how many would actually survive — and what does the answer tell you about the rest?

Frequently Asked Questions

What is a design input under EN ISO 13485? A design input is a documented requirement the medical device must satisfy, covering functional, performance, usability, safety, applicable regulatory requirements, outputs of risk management, and where appropriate information from previous similar designs. Clause 7.3.3 of EN ISO 13485:2016+A11:2021 requires each design input to be unambiguous, verifiable or validatable, not in conflict with other inputs, and formally reviewed and approved before the design proceeds.

How is a design input different from a user need? A user need is the unmet problem in the user's language. A design input is the engineering requirement derived from that user need, written in a form that can be verified by test, inspection, or validated usage. The translation from user need to design input is where the design team converts a human problem into a measurable specification. Both artefacts exist in the design file, and the traceability between them is audited.

Do I need design inputs for Class I devices? Yes. EN ISO 13485:2016+A11:2021 applies across all risk classes, and clause 7.3.3 does not exempt any class from the requirement to determine and document design inputs. What scales with risk class is the depth and the amount of verification and validation evidence — not the existence of design controls themselves.

What happens in an audit if my design inputs are vague? The auditor will ask how the requirement is verified, how it traces back to the intended purpose or a GSPR, and how the design team knows it is met. Vague requirements cannot answer these questions, and they cascade into non-conformities in the verification and validation records downstream. Vague design inputs are one of the most common root causes of design file non-conformities we see.

Can design inputs change during development? Yes, and the standard expects them to. Clause 7.3.9 covers the control of design and development changes. When a design input changes, the change is reviewed, the impact on outputs, verification, validation, and risk management is assessed, and the change is approved before the rest of the file is updated. The traceability matrix makes the impact assessment manageable. Without it, change control becomes guesswork.

Sources

  1. Regulation (EU) 2017/745 of the European Parliament and of the Council of 5 April 2017 on medical devices, Article 10 (general obligations of manufacturers), Annex I (General Safety and Performance Requirements), Annex II (technical documentation). Official Journal L 117, 5.5.2017.
  2. EN ISO 13485:2016+A11:2021 — Medical devices — Quality management systems — Requirements for regulatory purposes, clause 7.3.3 Design and development inputs.
  3. EN ISO 14971:2019+A11:2021 — Medical devices — Application of risk management to medical devices.

This post is part of the Quality Management System series in the Subtract to Ship: MDR blog. Authored by Felix Lenhard and Tibor Zechmeister. Design inputs are where the whole design file either starts strong or starts broken, and the discipline to write them tight is one of the highest-leverage habits a small MedTech team can build.