--- title: Design Output Requirements: Documenting What You Have Built description: Design outputs are the specifications produced by development: drawings, code, parameters. EN ISO 13485 clause 7.3.4 defines what they must show. Here is how to document them. authors: Tibor Zechmeister, Felix Lenhard category: Quality Management Under MDR primary_keyword: design output requirements MedTech canonical_url: https://zechmeister-solutions.com/en/blog/design-output-requirements-medtech source: zechmeister-solutions.com license: All rights reserved. Content may be cited with attribution and a link to the canonical URL. --- # Design Output Requirements: Documenting What You Have Built *By Tibor Zechmeister (EU MDR Expert, Notified Body Lead Auditor) and Felix Lenhard.* > **Design outputs are the concrete, reviewable specifications that result from the development process. Drawings, code, bills of material, software builds, process parameters, labelling, instructions for use. Under EN ISO 13485:2016+A11:2021 clause 7.3.4, design outputs must be in a form suitable for verification against the design inputs, must meet the input requirements, must provide appropriate information for purchasing, production and service provision, must reference acceptance criteria, and must specify the characteristics of the product that are essential for its safe and proper use. Design outputs must be approved before release. Under MDR Article 10(9), the design and development process sits inside the QMS required by the Regulation.** **By Tibor Zechmeister and Felix Lenhard. Last updated 10 April 2026.** --- ## TL;DR - Design outputs are the tangible results of the development process: drawings, schematics, source code, software builds, bills of material, process specifications, labelling, and instructions for use. EN ISO 13485:2016+A11:2021 clause 7.3.4 governs what they must contain and how they must be controlled. - Clause 7.3.4 requires design outputs to be in a form suitable for verification against the design inputs, to meet the input requirements, to provide appropriate information for purchasing, production and service provision, to reference or contain the product acceptance criteria, and to specify the characteristics of the product that are essential for its safe and proper use. - Design outputs must be approved before release. An unapproved specification is not a design output. It is a draft. - Every design output must be traceable back to a design input. An output that does not answer an input is orphaned work. An input that is not answered by an output is an unfilled requirement. - Under MDR Article 10(9) the design and development process is part of the legally required QMS, and the resulting design outputs feed directly into the technical documentation required by Annex II. --- ## Why design outputs are the moment the product becomes real A founder walks into a kickoff with a Notified Body auditor and is asked a simple question: "Show me the current design output set for the product you are certifying." The founder points to a Git repository, a shared drive with a dozen CAD files, and a Notion page with the latest parameter values. The auditor asks a follow-up: "Which of these are approved, dated, and under version control, and which are working copies?" The room goes quiet. That is the moment design outputs stop being a theoretical topic. Design outputs are the artefacts that say, on this date, for this revision, the team decided the product looks like this. They are the specifications a contract manufacturer will build from, the code that will compile into the release the users actually touch, the label text that will be printed, the cleaning parameters that will be validated. If the outputs are not controlled, the product is not controlled either. This post is the companion to [design and development planning](/blog/mdr-design-development-planning) and [design input requirements](/blog/design-input-requirements-medtech). Planning says what the development process will look like. Inputs say what the product must do and what it must satisfy. Outputs are the answer. The reviewable specification of what the team has actually built. ## What clause 7.3.4 of EN ISO 13485:2016+A11:2021 actually requires EN ISO 13485:2016+A11:2021 is the harmonised QMS standard for medical devices and the tool most teams use to meet the design and development obligations that sit inside the QMS required by MDR Article 10(9). Clause 7.3.4 is the design outputs clause, and it defines five requirements that every design output set must satisfy. First, design outputs must be in a form suitable for verification against the design input requirements. If an input says "the device shall sterilise to a sterility assurance level of 10^-6," the corresponding output must be specific enough that someone can run a test or a calculation and say yes or no. A vague output. "the device is sterile". Is not verifiable and is therefore not an acceptable output. Second, design outputs must be approved prior to release. Approval is not a feeling. It is a dated, attributable act. A signature, an electronic record, a change-control entry. Captured in the QMS in a way that survives turnover and tool migration. Third, design outputs must provide appropriate information for purchasing, production, and service provision. This is the clause that forces outputs to be practical. A specification that engineering understands but that the contract manufacturer cannot quote against is not sufficient. The output set must let the next function downstream do its job without having to guess. Fourth, design outputs must contain or reference product acceptance criteria. Acceptance criteria are the pass-fail rules: tolerances, test thresholds, visual standards, functional checks. They travel with the output so that whoever receives the output also knows what "correct" looks like. Fifth, design outputs must specify the characteristics of the product that are essential for its safe and proper use. This is the safety-critical carve-out. Not every design detail is safety-critical, but the ones that are must be identified explicitly so that production, change control, and post-market activities can protect them. Clause 7.3.4 is short. Every sentence in it does load-bearing work, and every sentence becomes a potential audit finding if it is not implemented. ## What actually counts as a design output The practical question is: in the daily development work of a MedTech startup, which artefacts are design outputs and which are working documents? The typical design output set for a physical device includes assembly drawings and component drawings, bills of material, material specifications, mechanical tolerances, electrical schematics, printed circuit board layouts, firmware source code and compiled binaries with hashes, software architecture and detailed design documents, labelling artwork and content, the instructions for use, packaging specifications, sterilisation parameters where applicable, cleaning and disinfection parameters, biocompatibility evaluation conclusions with the evidence they rest on, shelf-life and storage condition specifications, and the list of acceptance tests and their criteria. For a Software as a Medical Device build, the output set shifts but the logic is identical. Source code in a version-controlled repository, with a specific tagged release that corresponds to the device under certification. Software architecture documentation. Software unit and integration test specifications. Software of unknown provenance declarations. Third-party library inventories. Labelling, which for software typically means the in-app text, the help content, and any distributed instructions for use. The cybersecurity design artefacts. The release notes that correspond to the approved build. The test for whether something is a design output is straightforward. Is it needed downstream. By production, by a contract manufacturer, by service technicians, by verification and validation, by regulatory documentation. To do a job correctly? If yes, it is a design output and it must be controlled under clause 7.3.4. If it is a working sketch or a thinking document that informs the real specifications but is not itself handed downstream, it is a working document and it is managed differently. The mistake startups make is leaving things in the working-document bucket because formalising them feels premature. Then production happens off the working document, and the audit trail has a hole in it. ## How outputs must meet the inputs The central accountability of clause 7.3.4 is that the outputs meet the inputs. Inputs are captured under clause 7.3.3. The regulatory requirements, the user needs, the intended purpose, the applicable standards, the risk-control measures from the risk management file, and whatever else drives the design. Outputs are the answer. Every input must be answered by at least one output. Every output must answer at least one input. The practical tool that enforces this is a traceability matrix. The matrix lists inputs on one axis and outputs on the other, and the cells show which output satisfies which input. Orphaned inputs. Requirements with no corresponding output. Mean the product is incomplete. Orphaned outputs. Specifications with no corresponding input. Mean the team is building something nobody asked for, or that an input was lost, or that the matrix itself is stale. Verification, which is clause 7.3.6, then tests whether the outputs in fact satisfy the inputs they are mapped to. A well-constructed traceability matrix makes verification planning almost mechanical. A missing or broken matrix makes verification a guessing exercise and produces a predictable cluster of findings at audit. "Meet the inputs" does not mean the outputs look like the inputs. It means the outputs, when verified, will be found to satisfy the inputs. The relationship is a promise, not a paraphrase. ## Characteristics essential for safe and proper use The fifth requirement in clause 7.3.4. Specifying the characteristics essential for safe and proper use. Deserves its own discussion because teams routinely miss it. Essential characteristics are the product features that, if they shift, compromise safety or the intended performance. A stent's radial force. The sealing integrity of a sterile barrier. The dose accuracy of an infusion pump. The alarm priority logic in a patient monitor. The authentication flow in a SaMD that gates access to patient data. When essential characteristics are identified explicitly in the design outputs, several downstream activities become possible: production knows which parameters require tight control, change control knows which changes trigger a full design review, the risk management file has a concrete set of controls to point to, and the post-market surveillance plan has specific signals to monitor. When essential characteristics are not identified, every subsequent activity operates on guesswork. A change that looks cosmetic might silently affect a safety-critical parameter. A production deviation that looks tolerable might erode a clinical outcome. The audit finding, when it comes, is not that a specific parameter is wrong. The finding is that the organisation cannot demonstrate it knew which parameters mattered. The practical approach is a short, explicit list of essential characteristics, tied to the risk analysis, referenced in the design outputs, and used as a filter for change control and production monitoring from the day the first prototype is built. ## Approval before release Clause 7.3.4 requires design outputs to be approved prior to release. "Release" in this context means release to the next downstream step: release of a drawing to purchasing, release of a software build to verification, release of a process specification to production. Approval has to be attributable, dated, and survivable. Attributable means a named person with the competence to approve. Not "the team." Dated means the approval is bound to a specific revision of the output, not to an evolving artefact that continues to change after the signature. Survivable means the approval record is stored in the QMS and will still exist and still be readable when the audit happens two years later. For a startup, the simplest compliant approach is a single design and development procedure that names the approver role for each output class, a version-controlled repository for the outputs themselves, and a change-control log that records every release with the approver, the date, the revision, and the scope. Electronic signatures in the eQMS or in the Git commit trail are fine, provided the chain of custody is intact and the identity of the signer is clear. What does not work: verbal approvals, approvals embedded in chat messages that are not archived, approvals on working copies that then continue to be edited, and approvals by people who lack the competence to assess the output. Any of those produces findings and, more importantly, any of those means the company does not actually know which version of the specification is the real one. ## Traceability backward to the inputs and forward to the technical documentation Design outputs do not live in isolation. They sit in a chain that runs from the intended purpose, through the inputs, through the outputs, through verification and validation, through design transfer, and into the technical documentation required by MDR Annex II. Annex II of Regulation (EU) 2017/745 defines the content of the technical documentation that must be prepared and kept available. The design outputs are the raw material of large sections of that documentation. The product description, the technical specifications, the labelling, the information supplied by the manufacturer, the results of verification and validation. If the design outputs are controlled, the technical documentation can be assembled from them. If the design outputs are scattered, the technical documentation will be rebuilt from memory under deadline pressure, which is where most errors enter the file. The traceability is bidirectional. Backward, from each output to the inputs it answers. Forward, from each output to the section of the technical file it feeds and the verification activity it enables. A startup that sets this up once. At the point the first formal design output is released. Has a much easier certification than one that tries to reconstruct the chain after the fact. ## Common mistakes Five patterns account for most clause 7.3.4 findings in small MedTech teams. First, **treating working documents as outputs.** Sketches, spreadsheets, and chat threads that were used to make decisions, but never formalised as design outputs, end up driving production. The audit finds the disconnect between the approved output set and what was actually built. Second, **no traceability to inputs.** The outputs exist, but nothing connects them to the inputs they are supposed to answer. When the auditor asks how a specific input was satisfied, the answer requires a hunt through three repositories. Third, **approval without versioning.** An output was approved, but the file has been edited twenty times since. The approval covers a revision that no longer exists. Nobody can say which version of the specification is the approved one. Fourth, **missing essential characteristics.** The output set contains every detail of the device but does not identify which characteristics are essential for safe and proper use. Change control and production monitoring therefore cannot prioritise correctly. Fifth, **outputs that production cannot use.** The specifications are internally correct but insufficient for the contract manufacturer to build from or for the QC lab to test against. The team discovers this at design transfer, not at design output release, and has to re-open outputs under time pressure. ## The Subtract to Ship angle Design outputs are another area where the [Subtract to Ship framework](/blog/subtract-to-ship-framework-mdr) applies without cutting compliance. The trap is not under-documentation. The trap is producing a large volume of partly-controlled, partly-versioned, partly-approved artefacts that feel like documentation but do not satisfy clause 7.3.4. The Subtract to Ship version is a narrow, honest output set. Every item on the list is a real output that production, verification, or the technical file actually needs. Every item has a named approver, a storage location, a version, and a link back to the inputs it answers. Essential characteristics are a short, explicit list, not a category buried in a hundred-page specification. The design output procedure is two or three pages that describe exactly this system and nothing more. What gets cut: speculative specifications for features the product does not have, duplicate output sets maintained in parallel tools, output formats copied from a large manufacturer's template that do not match the startup's actual workflow, and "completeness" exercises that add pages without adding control. What stays: the five requirements of clause 7.3.4, every one of them, plus the traceability backward to inputs and forward to Annex II. ## Reality Check. Where do you stand? 1. Can you list, right now, every design output for your current device revision, and point to the approved, version-controlled copy of each one? 2. Do you have a traceability matrix that connects every design input to at least one design output, and every design output to at least one input? 3. For each design output, is there a dated approval by a named person bound to a specific revision of the file? 4. Have you explicitly identified the characteristics of your device that are essential for its safe and proper use, and is that list referenced in your design outputs? 5. Could your contract manufacturer build the device from your current design output set without having to ask you follow-up questions that are not answered in the outputs? 6. Can you trace each design output forward to the section of MDR Annex II technical documentation it feeds into? 7. If the lead engineer left tomorrow, would the design output set, the approval records, and the traceability matrix be intact and usable by the remaining team? ## Frequently Asked Questions **What are design outputs under EN ISO 13485?** Design outputs are the results of the design and development process. The specifications, drawings, source code, bills of material, parameters, labelling, and instructions for use that define the product. EN ISO 13485:2016+A11:2021 clause 7.3.4 requires them to be in a form suitable for verification against the inputs, to meet the inputs, to provide appropriate information for purchasing, production and service provision, to reference acceptance criteria, and to specify the characteristics essential for safe and proper use. They must be approved before release. **What is the difference between design inputs and design outputs?** Design inputs (clause 7.3.3) are the requirements the product must satisfy. User needs, intended purpose, applicable regulations and standards, risk-control measures. Design outputs (clause 7.3.4) are the specifications that answer those requirements. The drawings, code, parameters, and labelling that describe what the team has actually built. Inputs are the question. Outputs are the answer. Verification (clause 7.3.6) tests whether the outputs in fact satisfy the inputs. **Do I have to document design outputs if my product is software only?** Yes. For a Software as a Medical Device build, the design outputs include the source code in a version-controlled repository with a tagged release, the software architecture and detailed design, unit and integration test specifications, third-party library inventories, labelling (in-app text, help content, distributed instructions for use), and the release notes for the approved build. The form of the output changes, but clause 7.3.4 applies identically. **Who has to approve design outputs before release?** The design and development procedure names the approver role for each class of output. The approver must have the competence to assess the output. Typically the responsible engineering lead for the relevant domain, with additional roles for safety-critical or regulated content. The approval must be attributable, dated, and bound to a specific revision of the file. Verbal approvals, approvals in ephemeral chat messages, and approvals on files that continue to change are not sufficient. **How do design outputs relate to the MDR technical documentation?** Under MDR Article 10(9) the design and development process sits inside the QMS required by the Regulation, and Annex II of Regulation (EU) 2017/745 defines the content of the technical documentation. The design outputs feed directly into large sections of the technical file: the product description, the technical specifications, the labelling and instructions for use, and the verification and validation results. A startup that controls its design outputs well can assemble the Annex II documentation cleanly. A startup that does not will reconstruct the file under deadline pressure, which is where errors enter. ## Related reading - [MDR Design and Development Planning Under EN ISO 13485 Clause 7.3.2](/blog/mdr-design-development-planning) – the upstream post on planning the process that produces these outputs. - [Design Input Requirements for MedTech: From User Needs to Specifications](/blog/design-input-requirements-medtech) – the companion clause 7.3.3 post on the inputs that the outputs must answer. - [Design Review Under EN ISO 13485: Running the Meetings That Keep the Project Honest](/blog/design-review-medtech) – the clause 7.3.5 post on the structured reviews that sit alongside output release. - [Design Verification: Proving the Outputs Meet the Inputs](/blog/design-verification-medtech) – the clause 7.3.6 post on testing outputs against inputs. - [Design Validation: Proving the Device Meets the User Needs](/blog/design-validation-medtech) – the clause 7.3.7 post on validating the finished device. - [Design Changes Under EN ISO 13485: Controlling What You Change After Release](/blog/design-changes-medtech) – the clause 7.3.9 post on how changes to approved outputs are managed. - [The Subtract to Ship Framework for MDR](/blog/subtract-to-ship-framework-mdr) – the methodology behind the lean design output system described here. ## Sources 1. Regulation (EU) 2017/745 of the European Parliament and of the Council of 5 April 2017 on medical devices, Article 10, paragraph 9 (quality management system obligation) and Annex II (technical documentation content). 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.4 (design and development outputs), read together with clause 7.3.3 (design and development inputs) and clause 7.3.6 (design and development verification). --- *This post is part of the Quality Management Under MDR series in the Subtract to Ship: MDR blog. Authored by Tibor Zechmeister and Felix Lenhard. If your design outputs exist across a dozen tools and nobody is sure which revision is approved, Zechmeister Strategic Solutions helps founders build design control systems that survive the first real audit and every change after it.* --- *This post is part of the [Quality Management Under MDR](https://zechmeister-solutions.com/en/blog/category/quality-management) cluster in the [Subtract to Ship: MDR Blog](https://zechmeister-solutions.com/en/blog). For EU MDR certification consulting, see [zechmeister-solutions.com](https://zechmeister-solutions.com).*