Every medical device on the UK or EU market has a technical file behind it. It’s the evidence pack that shows your device does what you claim, and that you can show your working. Without one you can’t place the device on the market, and in my experience a thin or muddled file is one of the most common reasons a submission stalls.
Most first-time device developers have never actually seen one, which is understandable, as there’s no reason you would have. So I thought it would be useful to set out what goes in it, and when to start building yours (earlier than you might think).
First, which rules apply to you?
As of 2026 there are two routes onto the British market. You can UKCA mark against the UK Medical Devices Regulations 2002, or you can place a CE marked device on the Great Britain market under the current acceptance arrangements. Devices certified under the older EU directives are accepted until their certificate expires or 30 June 2028, whichever comes first, and devices certified under the EU MDR are accepted until 30 June 2030. The MHRA is currently consulting on whether to recognise CE marked devices indefinitely, so these dates may well change, but I wouldn’t build a regulatory strategy on the outcome of a consultation.
In practice, most of the UK developers we work with aim at the EU MDR technical file structure, as it satisfies the more demanding framework and travels well if you later want both markets. That’s the structure I’ve described below.
What’s inside the file
Device description and intended purpose. What the device is, what it’s for, who uses it, on whom, and in what setting. This sounds trivial but it isn’t, as the intended purpose drives your classification, your clinical evidence requirements, and quite a few of the discussions you’ll have with a reviewer. It’s worth writing this tightly and being ready to defend it.
Design and manufacturing information. Drawings, specifications, materials, key suppliers, and a description of how the device is made and controlled. If a subcontractor moulds your housing, that relationship forms part of the file.
The GSPR checklist. The General Safety and Performance Requirements are the backbone of an MDR file. It’s a long checklist where, for each applicable requirement, you point to the specific evidence showing you meet it (under the UK MDR 2002 the equivalent is the Essential Requirements, same idea, older wording). A GSPR checklist full of “see design file” entries with no document references tends to be the sign of a file that was put together in a hurry.
The risk management file. Your ISO 14971 records, so the hazard analysis, risk evaluations, the controls you’ve implemented and the evidence that they work. Reviewers read this alongside your clinical evaluation, and they do notice when the risks you analysed don’t quite match the device you actually built.
Verification and validation evidence. Test reports proving the design outputs meet the design inputs. Bench testing, performance testing, usability, biocompatibility, shelf life, whatever your device and classification require. This is usually the largest section, and it’s the one where gaps are most expensive to close late, as closing them generally means testing real hardware again.
Labelling and instructions for use. Final artwork rather than drafts, with the required symbols and language versions.
Clinical evaluation. The documented assessment showing the device achieves its intended purpose without unacceptable risk. For lower class devices this often leans on equivalence and published literature, although it still needs to be done properly.
Post-market surveillance plan. How you’ll monitor the device once it’s on the market. The UK strengthened its post-market surveillance requirements in June 2025, and as such this section now gets quite a bit more attention from UK reviewers than it used to.
When should you start the file?
My view is day one of design, not as a paperwork exercise at the end, and the reason is cost rather than box ticking.
Almost everything in the list above is a natural output of a well run project. Design inputs, test reports, risk analysis, you produce them anyway. If you capture them in a controlled structure as you go, the file largely assembles itself. If you leave it to the end, you end up paying someone to reverse engineer the story of your own device, re-running tests because the original report was never signed, and rewriting rationales from memory. I’ve done both kinds of project, and the retrofit is always slower and always costs more.
The three failure modes I see most often
The first is orphan evidence, so test data that exists but doesn’t trace to a requirement, which means the reviewer can’t tell what it’s actually proving.
The second is version control. The file references drawing revision C, the device on the bench is revision F, and nobody has documented the journey between the two.
The third is the copy/paste rationale, where the justification text has clearly come from a different device. Reviewers spot these very quickly.
All three come from treating the file as an afterthought, and none of them is difficult to avoid if the file grows with the project.
Need a hand?
We build technical files for UKCA and EU MDR submissions, either alongside a device we’re developing or by putting structure on documentation you already have (a gap assessment is often the sensible first step). If you’d like an honest view on how far your current paperwork is from submission ready, I’d be happy to have a call to talk it through. You can book a free call here.