What you will learn
By the end of this topic, you should be able to describe the principal design-control activities, distinguish the development file from market-facing technical documentation, recognise the evidence expected in each, and organise traceability so that conformity conclusions can be understood and maintained.
Two connected systems
Design controls are the planned and controlled activities used to turn an intended purpose and requirements into a verified, validated and transferable medical-device design. They govern decisions, responsibilities, reviews, changes and records throughout development.
Technical documentation is the organised body of evidence that describes the device and demonstrates how applicable safety, performance and regulatory requirements have been addressed. It draws heavily from design-control records but is not simply an archive of every project document.
MTL-103 explains how user needs and design inputs are established. MTL-104 follows that baseline through design outputs, review, verification, validation, transfer and controlled change, then shows how the resulting evidence is assembled for conformity assessment and lifecycle support.
Do not write the technical documentation after development as a regulatory reconstruction. Build the device, its traceability and its conformity evidence together.
The design-control process
Design and development planning
Define stages, responsibilities, interfaces, reviews, resources, methods, deliverables and the controls used as the project evolves.
Design and development inputs
Approve complete, unambiguous and compatible requirements derived from intended use, user needs, regulations, standards, risks and lifecycle constraints.
Design and development outputs
Create specifications, architecture, drawings, software, bills of material, manufacturing information, labelling and other outputs suitable for verification and production.
Design and development reviews
Evaluate whether results meet requirements, expose problems, assess readiness and assign necessary actions using appropriately independent and competent participants.
Design verification
Produce objective evidence that design outputs meet the approved design inputs, using planned methods, acceptance criteria and controlled configurations.
Design validation
Show that the resulting device meets user needs and intended use under actual or simulated conditions, using representative product and users where applicable.
Design transfer
Translate the approved design into controlled production, inspection, installation, servicing and supply information capable of reproducing the verified device.
Design changes
Identify, review, verify or validate, approve and implement changes while assessing effects on risks, interfaces, constituent parts, production and released devices.
Design and development file
Maintain records demonstrating conformity with the design-and-development requirements for each device type or device family.
Design reviews and decision gates
A design review evaluates the adequacy of a development result. A project gate decides whether the organisation is ready to commit resources or proceed. They may occur together, but their purposes should remain clear.
Useful reviews follow the maturity of the evidence: intended purpose and user needs; design inputs and risk controls; architecture and outputs; verification readiness; validation readiness; transfer and release; and significant lifecycle changes. The names and number of reviews can be proportionate to the device and organisation.
- The required inputs and evidence for the review are defined.
- Participants collectively provide the necessary technical, clinical, quality, regulatory, usability, risk and manufacturing competence.
- Independence is sufficient to challenge assumptions and conclusions.
- Open issues, deviations and residual uncertainties are visible.
- Decisions, rationale, actions, owners and due dates are recorded.
- Approval to proceed does not disguise unacceptable gaps as future actions.
What technical documentation needs to explain
For an EU medical device, Annexes II and III of the MDR set out the technical documentation and post-market surveillance documentation. The file should be clear, organised, readily searchable and unambiguous. A practical structure normally addresses:
Device definition
Intended purpose, classification, variants, accessories, configurations, principles of operation, specifications and previous generations.
Information supplied
Labels, instructions for use, training and promotional claims consistent with the approved intended purpose.
Design and manufacturing
Development information, architecture, specifications, manufacturing processes, sites, suppliers and controls needed to reproduce the device.
Safety and performance requirements
Applicability, rationale, methods used to demonstrate conformity, standards applied and precise references to controlled evidence.
Benefit–risk and risk management
Hazards, risk estimates, control measures, verification of controls, residual risks, overall residual-risk acceptability and production information.
Product verification and validation
Preclinical, electrical, mechanical, software, cybersecurity, usability, biological, packaging, sterilisation, clinical or performance evidence as applicable.
Clinical or performance evaluation
The claims, evidence strategy, data, appraisal, conclusions and post-market clinical or performance follow-up where required.
Post-market surveillance
PMS plan, reports, vigilance, trend reporting, PMCF or performance follow-up and the mechanisms feeding learning back into the controlled files.
Do not confuse the different file structures
Organisations may maintain several overlapping structures because the QMS, development process and market regulations ask different questions. They should reference the same controlled evidence rather than contain uncontrolled copies.
Design and development file
Demonstrates that the design-and-development process was planned and controlled for the device type or family.
Medical device file
Contains or references documents needed to show conformity with applicable requirements and support production, installation and servicing.
EU technical documentation
Presents the device and conformity evidence in the structure required by the MDR or IVDR, including post-market documentation.
Submission dossier
Packages selected evidence in the format and scope required by a specific regulator or conformity-assessment route.
Legacy US terminology such as Design History File, Device Master Record and Device History Record remains familiar and may still be useful within established systems. The current FDA QMSR, effective since 2 February 2026, removed those named file requirements and incorporates the ISO 13485 documentation model. Organisations should map legacy structures deliberately rather than assume the names themselves establish compliance.
Build a connected evidence chain
A statement such as “See risk file” is rarely sufficient. A reviewer should be able to identify the applicable requirement, understand the chosen solution, follow it to the precise controlled evidence and see the resulting conclusion without searching through unrelated records.
Manage the documentation as a system
- Use a controlled index showing required sections, owners, status and approved evidence.
- Reference source records rather than duplicating them into uncontrolled copies.
- Identify the device, family, variant, software version and configuration covered by each conclusion.
- Use platform documentation with controlled variant or market deltas where this remains clear and justified.
- Keep requirements, risks, outputs, verification, validation and conformity claims traceable.
- Record applicability decisions and justification, including standards applied in full or in part.
- Control external evidence from suppliers and laboratories as part of the device record.
- Ensure deviations and anomalies are assessed rather than hidden by a final report.
- Make the current approved baseline distinguishable from obsolete and draft information.
- Plan retention, accessibility and confidentiality across the required lifecycle.
Technical documentation is a lifecycle record
Release is not the end of design control. Complaints, vigilance, production trends, service data, supplier changes, software vulnerabilities, standards updates and new clinical information can change the evidence or challenge earlier assumptions.
Each proposed change should be assessed for effects on intended purpose, classification, requirements, risks, usability, cybersecurity, clinical evidence, verification, validation, manufacturing, labelling, registrations and devices already supplied. The technical documentation and post-market records must then be updated coherently.
A file that was complete at initial approval can become misleading if it no longer identifies the released configuration, current risks or current evidence. Configuration control is therefore inseparable from regulatory documentation.
Worked example: connected injection system
A connected injection system may include a reusable electronic accessory, compatible injector, embedded software, mobile application and cloud service. Design planning assigns responsibility across the organisations and disciplines involved and defines how system interfaces will be controlled.
User needs and risk analysis generate system inputs for event detection, feedback, data integrity, offline operation and secure communication. Architecture allocates those requirements across sensors, firmware, application and cloud. Outputs include schematics, mechanical drawings, software requirements, code baselines, interface specifications, manufacturing tests and labelling.
Verification evidence shows that each allocated input is met on controlled configurations. Validation shows that representative users can achieve the intended result in representative environments. Transfer evidence demonstrates that production can reproduce the verified design. The technical documentation then connects the claimed purpose, applicable requirements, risks, implemented controls and precise supporting evidence for the marketed configurations.
Readiness checklist
- The development plan reflects the current device, risks, stages and organisational interfaces.
- Inputs are approved, traceable and suitable for verification.
- Outputs are sufficient for verification, transfer, production and service.
- Reviews have challenged readiness and closed or controlled material issues.
- Verification and validation use approved methods, acceptance criteria and representative configurations.
- Risk-control implementation and effectiveness are supported by objective evidence.
- Transfer shows that routine production can reproduce the approved design.
- The technical-documentation index matches the applicable market requirements.
- Each conformity claim identifies applicability, solution, method, evidence and conclusion.
- Variants, accessories, software versions and market differences are unambiguous.
- Post-market documentation is connected to risk, clinical evidence and change control.
- A competent reviewer can understand the file without relying on undocumented project knowledge.
Common misconceptions
“Design controls are the quality department's paperwork.”
No. They are the operating discipline through which clinical, engineering, quality, regulatory and manufacturing teams create a controlled product and evidence.
“The technical file is the design history file.”
No. They overlap, but they serve different purposes and may follow different regulatory structures.
“A document index proves completeness.”
An index shows coverage. It does not prove that the underlying evidence is technically adequate, current or traceable to the released configuration.
“Passing tests completes the design.”
Test results need controlled inputs, configurations, methods, acceptance criteria, deviations and conclusions. Validation, transfer, risk and release decisions also remain necessary.
“Technical documentation is frozen at approval.”
No. It must remain aligned with changes, post-market knowledge, current risk conclusions and the supported product.
Seven things to remember
- Design controls create the product and its evidence through one controlled process.
- Technical documentation presents conformity evidence; it is not a project-document dump.
- Reviews should test technical readiness, not merely confirm that documents exist.
- Connect requirements, risks, solutions, methods, evidence and conclusions.
- Reference precise controlled records rather than vague files or duplicated copies.
- Keep variants, configurations and market differences unambiguous.
- Maintain the documentation as risks, products and post-market knowledge change.
Authoritative external references
- ISO 13485:2016 — Medical-device quality-management systems
- US FDA — QMSR Design and Development
- US FDA — Quality Management System Regulation
- Regulation (EU) 2017/745 — Annexes II and III
- ISO 14971:2019 — Application of risk management to medical devices
- GHTF — Summary Technical Documentation for demonstrating conformity