Design Output Documentation for Medical Devices: Drawings, Specifications, BOMs, and Acceptance Criteria

Why Design Output Documentation Is the Bridge Between Concept and Manufacturing

Design outputs are the tangible engineering artifacts that define exactly how a medical device is built, tested, and verified. They are the critical link between what the device must do (design inputs) and how the device is actually produced (the Device Master Record or Medical Device File). Yet design output documentation is one of the most frequently cited areas in FDA inspections and notified body audits, often because outputs are incomplete, lack acceptance criteria, or cannot be traced back to design inputs.

Under FDA 21 CFR 820.30(d) and its QMSR successor effective February 2, 2026, manufacturers must establish and maintain procedures for defining and documenting design outputs in terms that allow adequate evaluation of conformance to design input requirements. ISO 13485:2016 Clause 7.3.4 adds further specificity: outputs must meet input requirements, provide information for purchasing, production, and service, contain or reference acceptance criteria, and specify characteristics essential for safe and proper use.

This guide provides a practical framework for creating complete, audit-ready design output documentation for medical devices, including drawings, specifications, bills of materials, acceptance criteria, and the traceability structures that tie everything together.

Regulatory Requirements for Design Outputs

FDA 21 CFR 820.30(d) — Design Output

The FDA's design control regulation states:

Each manufacturer shall establish and maintain procedures for defining and documenting design output in terms that allow an adequate evaluation of conformance to design input requirements. Design output procedures shall contain or make reference to acceptance criteria and shall ensure that those design outputs that are essential for the proper functioning of the device are identified. Design output shall be documented, reviewed, and approved before release.

Key requirements embedded in this text:

• Procedures must exist for defining and documenting outputs
• Outputs must be evaluable against design inputs (traceability)
• Acceptance criteria must be contained in or referenced by outputs
• Essential outputs for proper device functioning must be identified
• Approval before release is mandatory, with documented date and signature

ISO 13485:2016 Clause 7.3.4 — Design and Development Outputs

ISO 13485 states that design and development outputs shall:

• (a) Meet the input requirements for design and development
• (b) Provide appropriate information for purchasing, production, and service provision
• (c) Contain or reference product acceptance criteria
• (d) Specify the characteristics of the product that are essential for its safe and proper use

Outputs must be in a form suitable for verification against design inputs and shall be approved prior to release. Records must be maintained.

How QMSR Changes the Expectations

Under the Quality Management System Regulation (QMSR), the FDA incorporates ISO 13485:2016 by reference. The practical changes for design outputs include:

• Terminology shift: The Design History File (DHF) concept aligns with ISO's "Design and Development File" (DDF), and the Device Master Record (DMR) maps to the "Medical Device File" (MDF)
• Risk-based emphasis: QMSR expects risk management outputs per ISO 14971 to be integrated into design outputs, not just design validation
• Greater specificity on manufacturing readiness: ISO 13485 Clause 7.3.4(b) explicitly requires outputs to provide information for production, which means design outputs must be detailed enough to serve as the foundation for the DMR/MDF

The FDA has confirmed in its CDRH Town Hall that design files developed under the 1996 QSR do not need to be retroactively scrubbed for terminology, but manufacturers are encouraged to conduct a gap analysis to ensure ISO 13485 requirements are met for devices marketed after February 2, 2026.

Categories of Design Output Documentation

Design outputs span multiple document types, each serving a distinct purpose in the development-to-manufacturing chain.

Engineering Drawings and CAD Models

Engineering drawings are the most fundamental design output for physical medical devices. They define the geometry, dimensions, tolerances, materials, surface finishes, and assembly relationships of every component and subassembly.

What drawings must include:

• Dimensional specifications with tolerances that are achievable in production and verified against design inputs
• Material callouts with specific material grades (e.g., ASTM F136 Ti-6Al-4V ELI for implantable components)
• Surface finish requirements (e.g., Ra 0.8 μm for biocompatible-contacting surfaces)
• Geometric dimensioning and tolerancing (GD&T) per ASME Y14.5 for critical fits and interfaces
• Assembly views showing how components fit together, including orientation and fastening methods
• Revision control with clear revision history and approval signatures

For devices with electrical components, drawings must also include schematic diagrams, printed circuit board (PCB) layouts, and wiring diagrams. For software-containing devices, software architecture documents and interface specifications are design outputs.

Best practice: Use 3D CAD models as the master reference, with 2D drawings derived from the model. Maintain model-drawing associativity to prevent discrepancies. Every drawing should be traceable to at least one design input.

Specifications and Technical Requirements

Specifications translate design inputs into detailed, measurable requirements. They form the technical backbone of the DMR/MDF.

Types of specifications in design outputs:

Each specification must be traceable to at least one design input and must include acceptance criteria that can be objectively measured or verified.

Bill of Materials (BOM)

The Bill of Materials is a hierarchical list of all components, subassemblies, and raw materials required to manufacture the medical device. It is both a design output and a critical element of the DMR.

BOM structure and content:

• BOM level and item number: Hierarchical numbering (e.g., Level 0 = finished device, Level 1 = major subassemblies, Level 2 = components within subassemblies)
• Part number and revision: Unique identifier with current revision
• Part description: Clear, unambiguous description
• Quantity per assembly: Number of units per parent assembly
• Material specification reference: Link to the applicable material spec
• Supplier information: Approved supplier(s) and supplier part numbers
• Make/buy designation: Whether the part is manufactured in-house or purchased
• Drawing reference: Link to the applicable engineering drawing
• Criticality designation: Identification of components that are essential for device safety or performance

BOM best practices:

• Maintain a single "master BOM" as the design output in the DHF, which seeds the production BOM in the ERP system after design transfer
• Use indented BOM structures to show parent-child relationships clearly
• Flag critical components separately — these require enhanced supplier controls and incoming inspection per ISO 13485 Clause 7.4.3
• Include approved alternate components with documented equivalency justifications
• Version-control the BOM in the document management system with formal approval workflows

Acceptance Criteria

Acceptance criteria define the pass/fail boundaries for each design output. They are not optional — both FDA and ISO 13485 explicitly require them to be contained in or referenced by design outputs.

Characteristics of effective acceptance criteria:

• Quantifiable: Use numerical ranges, not subjective terms like "adequate" or "sufficient"
• Verifiable: Can be confirmed through inspection, measurement, or testing
• Traceable: Linked to a specific design input requirement
• Complete: Cover all critical performance, safety, and usability parameters
• Practical: Achievable with available measurement equipment and within production capabilities

Examples of acceptance criteria by output type:

Software Design Outputs

For devices containing software, design outputs include additional artifact types mandated by IEC 62304:2006+AMD1:2015 (the harmonized standard for medical device software lifecycle processes):

• Software requirements specification (SRS): Detailed functional, performance, interface, and safety requirements
• Software architecture document: High-level structure, modules, interfaces, and data flow
• Software design specification (SDS): Detailed design for each software unit
• Source code and build files: Version-controlled code repository with tagged release builds
• Software test specifications: Unit, integration, and system test protocols with acceptance criteria
• Software release notes: Version identification, resolved issues, known anomalies

IEC 62304 requires that software safety classification (Class A, B, or C) determines the depth of documentation required. Class C software (death or serious injury possible) requires the most comprehensive design output documentation, including detailed unit-level design and exhaustive testing evidence.

Building Traceability: From Design Inputs to Design Outputs

Traceability is the connective tissue that makes design outputs audit-ready. Without documented links between inputs and outputs, an auditor cannot verify that the device design meets its requirements.

The Traceability Matrix

A traceability matrix (or requirements traceability matrix) is a structured table that maps each design input to its corresponding design output(s), verification activities, and validation evidence.

Minimum structure for a design output traceability matrix:

Practical Traceability Tips

• Use unique identifiers for every input, output, and test document — no generic references
• Maintain bidirectional traceability: From user needs → inputs → outputs → V&V, and backward from V&V → outputs → inputs → user needs
• Update the traceability matrix continuously as outputs evolve, not just at design freeze
• Link to specific document revision numbers rather than document titles alone, to prevent ambiguity
• Include risk control measures as traceable elements — ISO 14971 risk outputs that are implemented through design outputs must be tracked

What Design Outputs Are NOT

A common point of confusion is conflating design outputs with verification evidence. Test reports, test protocols, and validation data are not design outputs — they are verification and validation records that demonstrate whether outputs meet inputs.

Design outputs are the specifications, drawings, and instructions that define what the device is and how it is built. Verification evidence proves those outputs meet the input requirements. Both are stored in the DHF/DDF, but they serve different purposes and must be maintained as distinct document types.

Similarly, risk analysis documents (FMEA worksheets, hazard analysis tables) are not design outputs, though the risk control measures they generate must be implemented through design outputs (e.g., a specification that implements a risk control is a design output).

Common Audit Findings and How to Avoid Them

FDA warning letters and notified body nonconformities frequently cite the following design output deficiencies:

1. Incomplete Acceptance Criteria

Finding: Outputs reference "pass visual inspection" without defining what constitutes a pass.

Fix: Define objective criteria — "No visible scratches, cracks, or discoloration when inspected under 3× magnification at 300 lux minimum lighting."

2. Missing Traceability to Inputs

Finding: Design outputs exist with no documented link to any design input requirement.

Fix: Maintain a living traceability matrix. Every output must map to at least one input. If an output has no corresponding input, either the input is missing (gap in requirements) or the output is unnecessary (scope creep).

3. Outputs Not Approved Before Release

Finding: Engineering drawings or specifications released to manufacturing without documented approval signatures and dates.

Fix: Implement electronic signatures with approval workflows. Document control procedures must enforce approval-before-release for all design outputs.

4. Essential Outputs Not Identified

Finding: The regulation requires that design outputs essential for proper device functioning be identified, but no such identification exists.

Fix: Create a critical design output register. Flag outputs that directly relate to device safety, essential performance, or risk control measures. These outputs receive enhanced review, tighter change control, and more rigorous verification.

5. BOM Discrepancies

Finding: The BOM in the DHF does not match the production BOM in the ERP system, or the BOM references obsolete components.

Fix: Establish a formal design transfer process that reconciles the design BOM with the production BOM. Implement change control procedures that update both simultaneously.

Design Output Approval Workflow

Design outputs must be reviewed and approved before release. A compliant approval workflow includes:

1. Preparation: The designer or engineer creates the output document with all required elements (specifications, acceptance criteria, traceability references)
2. Peer review: A qualified peer reviews the technical content for accuracy, completeness, and manufacturability
3. Cross-functional review: Quality, regulatory, and manufacturing representatives review for compliance and producibility
4. Independent review: Per 21 CFR 820.30(e), an individual without direct responsibility for the design stage reviews the output
5. Approval and release: A designated approver signs and dates the document, releasing it for use in verification and validation activities
6. DHF filing: The approved output is filed in the Design History File with its approval record

Design Outputs as the Foundation for the DMR

Design outputs serve a dual purpose: they demonstrate compliance with design controls, and they become the technical foundation for the Device Master Record (DMR) — or under ISO terminology, the Medical Device File (MDF).

When design outputs are complete, the DMR assembly is straightforward:

This is why design output quality directly determines manufacturing quality. Gaps in design outputs create gaps in the DMR, which create gaps in the DHR, which surface as nonconformances during production — or worse, during an FDA inspection.

Checklist: Design Output Documentation Readiness

Use this checklist before design freeze or design transfer to verify completeness:

• Procedures exist for defining, documenting, reviewing, and approving design outputs
• All design outputs are documented in terms that allow evaluation against design inputs
• Every design output contains or references acceptance criteria
• Outputs essential for proper device functioning are identified and flagged
• Engineering drawings include dimensions, tolerances, materials, and GD&T
• Specifications cover product, component, material, process, software, labeling, and packaging requirements
• BOM is complete with part numbers, revisions, quantities, suppliers, and criticality designations
• Software outputs comply with IEC 62304 requirements for the applicable safety classification
• Traceability matrix maps every output to its input(s) with bidirectional links
• Risk control measures from ISO 14971 risk management are implemented as traceable outputs
• All outputs have documented approval signatures and dates prior to release
• Outputs are in a form suitable for verification and in the DHF/DDF
• Outputs provide sufficient information for the DMR/MDF assembly
• Change control procedures are in place for post-approval output modifications

Key Takeaways

Design output documentation is where the medical device design becomes real — where requirements become specifications, and specifications become the manufacturing recipe. Under both FDA 21 CFR 820.30(d) and ISO 13485 Clause 7.3.4, the requirements are clear: outputs must meet inputs, include acceptance criteria, identify essential characteristics, and be approved before release. With the QMSR incorporating ISO 13485 by reference as of February 2, 2026, manufacturers must ensure their design output procedures, traceability practices, and documentation standards meet both frameworks simultaneously.

The most effective approach is to treat design output documentation as a continuous, traceable process — not a last-minute exercise before design transfer. When outputs are created with acceptance criteria, traceability links, and manufacturing readiness in mind from the start, the transition from design to production becomes a verification step rather than a rescue mission.