ISO 13485 medical device file and design file: what goes in each and how they connect

What are the medical device file and the design file?

An ISO 13485 medical device file is the controlled set of documents that defines one device type or family: what it is, what it is for, how it is labelled, what it must meet and how it is produced and checked. The design and development file is its companion: the records showing that the design was planned, specified, reviewed, verified, validated, transferred and changed under control. One answers "what are we making?", the other "how do we know the design is right?"

The standard's introduction adds that anything required to be documented must also be established, implemented and maintained, so a file correct at launch and never touched again does not meet the requirement.

What goes in the medical device file

Clause 4.2.3 lists the content for each device type or family. In practice a good file is an index, one page long, that points to controlled documents already held in the document system, rather than a binder of copies that drift out of date.

Description, intended use and labelling

A general description of the device, its intended use or purpose, and its labelling, including instructions for use. Keep the intended use identical to the wording in the regulatory registration.

Product specifications

Drawings, material specifications, software versions, performance characteristics and acceptance criteria.

Production, distribution, measuring and monitoring

The specifications or procedures for each of these, including the steps done by suppliers, together with the measuring and monitoring procedures: inspection, test methods and release criteria. Where a contract steriliser or packaging house performs a step, the file points to the agreement and the specification that controls it.

Installation and servicing, as appropriate

Installation requirements and servicing procedures for equipment that needs them. Where neither applies, say so in one line.

What goes in the design and development file

Clause 7.3.10 closes the design and development section of ISO 13485 by requiring a file for each device type or family that brings together the records of the design work. Those records come from every step that the section controls:

• Planning: the design plan with its stages, responsibilities and planned reviews, kept current as the project moves.
• Inputs: the requirements the design must meet, including safety, performance and regulatory requirements and the outputs of risk management, reviewed and approved.
• Outputs: drawings, specifications, software, labelling and acceptance criteria, in a form that can be checked against the inputs.
• Reviews: minutes that name who attended, what was decided and the actions raised.
• Verification and validation: protocols, results and conclusions showing outputs meet inputs and the device meets user needs and intended use.
• Transfer (7.3.8): evidence that the outputs were confirmed suitable for production before routine manufacture began.
• Changes (7.3.9): each change with its review, the evaluation of its effect and its verification or validation.

The risk management file, run to the process clause 7.1 requires and usually built with ISO 14971, sits alongside. It is referenced from the design file, not copied into it. Software adds IEC 62304 life-cycle records, covered in ISO 13485 for medical device software.

An organisation with no design responsibility, such as a distributor or a contract manufacturer building to a customer's drawings, keeps no design file of its own. Its scope should state clearly where design sits.

How the two files connect

The link is design transfer. When the design is released, its approved outputs become the specifications, labels and procedures the medical device file indexes. After that, any change, whether from production, a complaint or a supplier, is evaluated in the design file, reflected in the medical device file and checked against the risk management file.

Auditors test this link both ways: from a specification back to an approved design output, and from an output forward to the document production uses.

A worked example: a sterile single-use extension set

Take a small manufacturer that designs a sterile single-use infusion extension set in three lengths, moulds the connectors in house and sends finished packs to a contract steriliser.

The three lengths share materials, design, process and intended use, so they form one family with one medical device file. The index lists the description and intended use; the label and instructions for use; the drawing set and material specifications; the moulding, assembly and packaging procedures; the storage and distribution instruction; the agreement and specification for the sterilisation step; and the inspection and release procedures. Installation and servicing are marked as not applicable, with the reason.

The design file holds the plan, the input list traced to each output, the review minutes from concept to release, the verification reports for connection strength, flow and leakage, the usability validation, the transfer review and the change log. The risk management file is referenced, its hazards traced to the inputs that control them.

Batch and sterilisation records are not in either file. They are records of production under clause 7.5.5, kept per batch and traced to it; the medical device file points to the procedures that generate them.

The files and regulatory submissions

Neither file is the dossier a regulator reviews. Class B, C and D devices registered with the Philippine FDA use the ASEAN Common Submission Dossier Template; CE marking under the EU MDR needs a notified body for most device classes, with its own documentation expectations; and the FDA's QMSR incorporates ISO 13485:2016 but states that compliance with ISO 13485 alone does not fully satisfy it. A well-kept pair of files is the source those dossiers are assembled from. The US picture is covered in ISO 13485 and the FDA QMSR: what to check.

Common mistakes and what auditors test

Certification body auditors usually sample one or two families and follow them end to end. Most findings on these files come from a few habits:

• The design history lives in engineers' e-mail and test folders and is assembled a week before the audit.
• Risk management is a spreadsheet completed after the design was frozen, so no design input can be traced to a hazard.
• One file covers devices that do not share a design or process, and the grouping cannot be justified.
• Supplier-performed steps, above all sterilisation and packaging, have no controlling specification in the file.
• Changes are made on the line and never reach the design file.

Medical device file and design file: questions buyers ask