Here is a sentence that should strike mild terror into the heart of anyone responsible for a medical device QMS: “Can you show me the device file for this product?”
If your answer involves a long pause, a glance at a colleague, or the phrase “well, it’s distributed across a few different places,” you have a §4.2.3 problem. Possibly several.
The Medical Device File is one of those requirements that sounds straightforward until you actually try to assemble one — at which point you discover that your design outputs are in one folder, your risk management file is in another, your regulatory submissions are on someone’s hard drive, and the original design inputs are in an email chain from 2018 that may or may not still be accessible. This is not a QMS. This is an archaeological dig.
What §4.2.3 Actually Requires
ISO 13485 requires that for each medical device type or family, the organization maintains a Medical Device File (MDF). This file — which can be a single physical or electronic location, or a structured set of references to documents held elsewhere — must contain or reference the documents needed to demonstrate conformity to requirements and to verify that the QMS is effectively applied to that device.
In practical terms, a complete Medical Device File typically includes:
- Device description and intended use — what the thing is and what it’s supposed to do
- Design and development records — inputs, outputs, reviews, verification, validation (your Design History File lives here)
- Specifications — product specifications, raw material specs, component specs
- Risk management file — per ISO 14971, which ISO 13485 expects you to be using
- Manufacturing information — the process documentation, assembly instructions, acceptance criteria
- Regulatory information — applicable standards, regulatory approvals, labeling
- Post-market data — complaint records, post-market surveillance outputs, any CAPAs linked to the device
Note that §4.2.3 doesn’t require all of this to live in one enormous document. It requires that you can locate and present it in an organized, coherent way. A well-structured index that points to the right records in the right systems is perfectly acceptable. “I think it’s somewhere” is not.
The Naming Confusion Is Real and Worth Addressing
Different regulatory regimes call this document different things. ISO 13485 says “Medical Device File.” EU MDR/IVDR calls it a “Technical File” or part of the “Technical Documentation.” FDA’s QMSR refers to the “Design History File” (for design-controlled devices) and the “Device Master Record.” None of these are identical, but they overlap substantially.
If your company sells into multiple markets, you may be maintaining versions of this file under different names and with slightly different content requirements. That’s legitimate — but it’s worth having a clear map of what lives where, what satisfies which requirement, and who is responsible for keeping each version current. Otherwise, you end up with a proliferation of “device files” that are subtly out of sync with each other, which creates its own category of audit adventure.
The Part That Trips People Up: Post-Market Data
Many device files are excellent archives of design and manufacturing information — and completely silent on what’s happened to the device since it launched. ISO 13485 expects your MDF to be a living document that reflects the device’s current state, including what you’ve learned post-market. Complaint trends, field corrective actions, PMS outputs — these should feed back into the file. If your device file looks exactly the same as it did on the day of first regulatory submission, that’s a question worth asking yourself before your auditor asks it for you.
Practical Takeaway
Pick one device. Pull up whatever you currently call its device file. Ask: could an auditor who has never seen this product understand what it is, how it’s made, that it’s safe and effective, and what’s happened to it in the market — using only what’s in this file? If yes, excellent. If no, that gap is your next project. Start with an index: list every document that should be in scope for this device, where it currently lives, and who owns it. That alone is more useful than most gap analyses costing ten times as much.
Up Next
Next time: §4.2.4 — Control of Documents. This is the clause that turns grown engineers into document control philosophers. We will explain why version control is not optional, what “legible, readily identifiable, and retrievable” actually means in practice, and why “I know which one is current” is a different thing from “everyone knows which one is current.”
This post is part of an ongoing series dissecting every clause of ISO 13485 with accuracy, mild exasperation, and the occasional moment of genuine appreciation for the standard’s better ideas. Whether you’re preparing for certification or just trying to understand what your QA team is on about, you’re in the right place.