MDR technical file: built from the ground up, not just reviewed.
A complete technical file under MDR Annexes II and III, built with the platform and tailored to your device class, from the GSPR matrix to labelling.
Initial scoping is free, with no commitment. All classes. Clinical evaluation report available as an option.
What you get
- GSPR
- Risk management
- Design documentation
- Labelling
- Clinical evaluation coordination
- Compliance with applicable standards
Good to know
- All classes (I, IIa, IIb, III)
- Clinical Evaluation Report (CER) as an option
Ideal if: you need to build your first MDR technical file, or rework an existing one before a submission.
Build or review? Two different needs
This page covers building a technical file, meaning cases where one does not exist yet, or where what exists is too incomplete to serve as a basis.
If your file is already built and you want an outside view before submitting it, what you need is the technical file review. It is shorter, less expensive, and answers a different question: not "how do we build it?" but "will it pass?".
During scoping, we look at what already exists before advising you. We sometimes recommend the review to someone who came for a full build, when the file is further along than its author thinks.
See the MDR technical file reviewWhat makes it difficult
The difficulty of a technical file does not lie in the number of documents to produce. It lies in how they depend on one another.
The GSPR matrix drives everything else
Every applicable general safety and performance requirement must point to specific evidence, or to a justification of non-applicability. It is the backbone of the file, and it is where the assessor starts.
Risk management runs through everything
The risk analysis feeds into design choices, control measures, labelling, the instructions for use and the clinical evaluation. A change to the device ripples through all these documents, and omissions there are the leading source of inconsistency.
Your claims commit you everywhere
What you state about your device must be backed by clinical evidence and appear identically in the labelling, the instructions for use and your sales materials. A claim that appears on your website but not in the file is a non-conformity.
The platform as its engine, not a generator
We do not produce a technical file automatically, and nobody should. A technical file bears on patient safety and on the manufacturer's liability.
What the platform brings during the build is consistency maintained as the work progresses. It tracks the cross-references between the GSPR matrix, the risk analysis, the design documentation and the labelling, and flags anything that no longer matches as soon as a document changes.
Our experts do the regulatory work: the choice of arguments, the selection of applicable standards, the writing, and the coordination of the clinical evaluation. They do it without spending their days checking cross-references.
Frequently asked questions
The build starts from scratch or from an existing file that is too incomplete, and produces the file. The review examines a file that has already been built, before submission, and produces a list of blocking issues. Scoping is there partly to determine which of the two matches your real situation.
Coordination of the clinical evaluation is part of the service, which covers how the evaluation ties in with the rest of the file. Writing the report itself is offered as an option, because the workload varies considerably with the device class and the data available.
All of them, from class I to class III and implantables. Scope and timeframe are confirmed during scoping: the content expected under Annexes II and III varies greatly with the class, and that is what determines the real workload.
It depends on the class, the maturity of the design and the availability of your clinical and verification data. A well-documented class I device and a class III implantable are not in the same order of magnitude. The timeline is set during scoping, with its dependencies.
It is common, and it is planned for. The platform flags documents that have become inconsistent with the new version, which avoids the classic scenario of a file submitted with a risk analysis describing a device that no longer exists.
A first technical file to build?
Tell us about the device, its class and what already exists. We will tell you frankly whether a full build is necessary.