← Back to blog

Design Outputs: Turning Requirements into Useful Specifications

May 25, 2026 · Mike Reo

rmforge.io | Part 2 of a 5-Part Series on Design

When Design Inputs are defined, referenced, and justified, the next move in the design control process is generating Design Outputs. Design Outputs are the concrete specifications that bring the device into reality, the testable products that enable preliminary bench tests, Design Verification, and Design Validation (DV&V) including preclinical and clinical trials. They document the design for ordering components and manufacturing repeatable, reproducible product.

Many teams skip the Design Output step, in whole or in part, before DV&V. The result is delay, increased cost, and protocols built on shifting sand. Here is what to do instead.

What Design Outputs Answer

Design Outputs answer the question: how do we translate documented Design Inputs into specific, verifiable deliverables?

The project team creates controlled and traceable Production Specifications: component specifications, assembly drawings, manufacturing instructions, bills of materials, lot history records. All the tangible information needed to build and inspect the device.

Regulations at a Glance

  • 21 CFR 820.10(c) (QMSR, effective February 2, 2026): requires compliance with ISO 13485:2016 Clause 7.3. The legacy 820.30 subsections are [Reserved].
  • ISO 13485:2016 Section 7.3.4: design and development outputs shall be in a form suitable for verification against design and development inputs.
  • ISO 13485:2016 Section 7.3.8: design and development outputs shall be verified as suitable for manufacturing before becoming final production specifications.

Types of Design Outputs

Device Master Record (DMR), 21 CFR 820.181

  • Record of all design output: the "what" and "how"
  • Comprehensive set of specifications and procedures needed to manufacture the device
  • Best implemented as an Index of Design Output in the Quality Management System (QMS)
  • Include the Design Input and Design Output Matrix as a reference: easy index for outside reviewers and required linkage back to inputs

Device History Record (DHR), 21 CFR 820.184

  • Record of "when, who, and which lot or serial number"
  • Demonstrates execution of the DMR
  • Common forms: Lot History Record (LHR), Traveler, Batch Record
  • Proves each batch or unit was manufactured according to the DMR

Software Design Documentation

  • Software code, version control logs, user interface specifications
  • Aligns with IEC 62304 Clause 5: Medical Device Software Life Cycle Processes
  • Software Bill of Materials (SBOM)

Bill of Materials (BOM)

  • Line-by-line accounting of each raw material or component
  • Hierarchical BOMs include components and subassemblies

Production Specifications and Drawings

  • Component specifications
  • Drawings with detailed dimensions, materials, tolerances
  • Component drawings, assembly diagrams, exploded views

Manufacturing and Production Instructions

  • In-process quality checks to ensure conformance
  • Sterilization Instructions
  • Distribution Instructions

Quality Inspections

  • Receiving inspections
  • Component and subassembly inspections
  • Final assembly inspections
  • Sterilization documentation inspections

Labeling and Accompanying Documents

  • Labels with text, symbols, regulatory markings (CE, UDI)
  • Labeling Instructions including Unique Device Identification (UDI)
  • Instructions for Use (IFU) that align with User Needs and Intended Uses
  • Operation Manuals and User Manuals

Packaging, Equipment, Tooling, Fixtures

  • Packaging drawings and written specifications
  • Packaging instructions
  • Equipment specifications
  • Tooling and fixture documentation

Ensuring Traceability

Each Design Output traces back to one or more Design Inputs. This link guarantees that every User Need, Intended Use, and Product Requirement has a corresponding output that shows how it is being met.

  • Unique Identifiers: indelible IDs on each Product Requirement and QMS identification on each Design Output
  • Design Input and Design Output Matrix: a table or database mapping each requirement to its outputs (covered in Part 5)
  • DMR Organization: build a Device Master Record of all Design Outputs and organize by type

DV&V Readiness

Design Outputs form the basis for DV&V readiness. Readiness is a relative state in most organizations, with significant downside when teams are not actually ready. Three principles govern this stage.

Principle 1: Sufficient Documentation for Repeatable Build

Design Outputs must be sufficiently documented to enable a repeatable, reproducible product build in legitimate sample sizes for risk-controlled testing.

  • Clarity and Completeness: insufficient detail (e.g., missing tolerances) stalls Design Verification, yields ambiguous results, or worse: detail gets built into the Verification protocol and is lost after testing.
  • Measurability: Design Outputs reflect testable parameters such as dimensions and performance limits. Conduct a Test Method Validation (TMV) including measurement system capability analysis to address repeatability, reproducibility, and capability.

Principle 2: Design Outputs Do Not Set Acceptance Criteria

Acceptance Criteria come from Design Inputs, literally 1:1 when executed correctly. Hybridizing Design Inputs with undocumented Design Outputs into Acceptance Criteria is a common pitfall (covered in Part 3). Design Outputs create the controlled product basis from which Acceptance Criteria are evaluated, not the criteria themselves.

Principle 3: Design Outputs Must Be QMS-Controlled

Without traceable and controlled Design Outputs released into the QMS, DV&V testing runs on shifting sand. That means repeated builds, repeated testing, more time, and more cost.

Common Pitfalls

Insufficient Detail

Problem: omitting critical specifications leads to guesswork in manufacturing or testing.

Solution: provide explicit nominals and tolerances, material grades, and test acceptance criteria.

No Link to Inputs

Problem: free-floating Design Outputs not clearly tied to User Needs or Product Requirements can miss functionality or produce a product that exceeds cost and necessity.

Solution: use an input-output matrix or equivalent software tool to track connections.

Weak Revision Control and Change Management

Problem: failing to update and track changes causes loss of traceability, loss of lot control, and forces rebuilding or compliance corrections.

Solution: follow ISO 13485:2016 Section 7.3.9 for design changes and ISO 13485:2016 Section 7.5 for production controls. Under the QMSR, 21 CFR 820.10(c) incorporates these by reference.

Worked Example: Vascular Stent

Product Requirement: "The stent shall have an outside diameter of 2.00 +/- 0.05 mm with a wall thickness of 0.10 +/- 0.01 mm."

Possible Design Outputs:

  • Engineering Drawing: stent geometry with annotated dimensions and tolerances highlighting critical inspection dimensions
  • Manufacturing Process Instructions: laser-cutting parameters, mandrel and collet loading, cleaning, dimensional check, pickling and electropolishing setup, final dimensional check, surface finish check
  • Quality Inspection Instructions: measurement equipment, sample size direction, measurement points, measurement procedure, and inspection documentation

Design Outputs flow from your Risk Controls.

rmForge generates Hazard Analyses and FMEAs that surface risk control measures structured as Design Inputs, with bidirectional traceability built into the row format. Your Design Outputs land already tied to risk evidence.

Try rmForge at rmforge.io

The 5-Part Series

  • Part 1: Design Inputs
  • Part 2: Design Outputs (this article)
  • Part 3: Design Verification and Design Validation
  • Part 4: Risk Management in Design Control
  • Part 5: Design Input and Design Output Matrix

References

Quality Management System Regulation (QMSR), 21 CFR Part 820, Feb. 2, 2026.

ISO 13485:2016. Medical Devices, Quality Management Systems, Requirements for Regulatory Purposes. ISO, 2016.

IEC 62304:2006+A1:2015. Medical Device Software, Software Life Cycle Processes.

Design Control Guidance for Medical Device Manufacturers. FDA, 1997.

Regulation (EU) 2017/745 of the European Parliament and of the Council of 5 April 2017 on Medical Devices. Official Journal of the European Union, 2017.

Questions or feedback: mike@rmforge.io

Try the platform: rmforge.io