Design and development under ISO 13485

ISO 13485:2016 · Clause 7.3 — the most document-intensive clause

Who is responsible for design?

The legal manufacturer — the entity whose name appears on the device label — holds design responsibility. Even if design work is outsourced to a contract design house, the legal manufacturer must control and oversee the design process and maintain the design records. Contract manufacturers who only manufacture to a customer's specification may exclude clause 7.3 from their QMS scope, but must document the justification for this exclusion.

7.3.1 — Design and development planning

Before design work begins, create a design and development plan that defines: the design phases, review, verification, and validation activities appropriate to each phase; responsibilities and authorities for design; interfaces between groups involved in design; and how the design will be transferred to manufacturing. The plan must be updated as the design evolves — it is a living document, not a one-time deliverable.

7.3.2 — Design inputs

Design inputs are the requirements the device must meet. They must be documented and include functional and performance requirements, applicable regulatory and legal requirements, applicable standards, outputs from risk management, and information derived from previous similar device designs. Inputs must be reviewed for adequacy and approved. Incomplete, ambiguous, or conflicting inputs must be resolved before design work begins — fixing input errors late in development is expensive.

7.3.3 — Design outputs

Design outputs are the results of design work — specifications, drawings, software source code, manufacturing procedures, labelling, and acceptance criteria. Outputs must: meet design input requirements; provide appropriate information for purchasing, production and service provision; contain or reference product acceptance criteria; and specify characteristics of the device essential for safe and proper use. Design outputs must be approved before release.

7.3.4 — Design review

At suitable stages in the design process, formal design reviews must be conducted. Reviews must include representatives of all functions concerned with the design stage being reviewed — typically including engineering, regulatory affairs, quality, clinical, and manufacturing. Review records must be maintained, including who attended, what was reviewed, and what actions were raised. Design reviews are checkpoints, not rubber stamps.

7.3.5 — Design verification

Verification confirms that design outputs meet design inputs — i.e., "did we build it right?" Verification is performed by testing, analysis, or inspection against documented acceptance criteria. Common methods include bench testing, simulation, inspection, and comparison with proven designs. Verification records must be maintained and must reference the specific design outputs and inputs involved.

7.3.6 — Design validation

Validation confirms that the device meets the needs of the intended user in the intended use environment — i.e., "did we build the right thing?" Validation typically includes clinical evaluation or clinical investigation, usability testing/summative evaluation, and software validation (per IEC 62304 if applicable). Validation must be completed before commercial release. Where design validation cannot be performed until post-production, the rationale must be documented.

7.3.7 — Design and development transfer

Before a device moves from development to production, the organisation must verify that the design outputs can be manufactured consistently using production processes. This transfer activity must be documented and must confirm that production procedures and equipment are capable of meeting the design specifications. Any differences found during transfer must be resolved and documented as design changes.

7.3.8 — Control of design and development changes

Every change to a design must be documented, reviewed, verified, and validated as appropriate, and approved before implementation. The review must include evaluating whether changes affect previously completed verification, validation, and risk management activities. Changes to software are particularly important — they can introduce new risks or invalidate prior validation. Change records must link to the original design and to any updated testing or risk management records.

Design History File structure

The Design History File (DHF) — referred to as a Medical Device File under ISO 13485 clause 4.2.3 — is the master folder that ties all design records together. A practical structure: