Creating an MDR technical file
Under the MDR, the technical file is not a document you compile once; it is a file that must stay current, fed by post-market surveillance. Appfront builds the system in which those two are connected: the documentation per device and per version, and the market signals that feed back into it.
What the MDR requires of a manufacturer
Regulation (EU) 2017/745 requires every manufacturer to maintain technical documentation in accordance with the annexes to that regulation: description and specification of the device, information for the user, design and manufacturing information, the general safety and performance requirements with justification for each requirement, risk management, verification and validation, and clinical evaluation. A separate post-market surveillance documentation requirement sits alongside this.
That second part is what fundamentally sets the MDR apart from the previous regime. You must have a PMS plan, actively collect data from the market, analyse it periodically and feed the outcome back into the technical file, the risk analysis and, where necessary, the design. Depending on the risk class, this produces a PMS report or a periodic safety update report, each with its own update frequency. In addition, vigilance and trend reporting apply.
In practice, many manufacturers keep these two tracks separate. The technical file sits in a document management system or a folder structure, while complaints and reports sit in another system or a mailbox. The MDR, however, requires the two to be connected: a complaint must be traceable from the device and visibly feed back into the risk analysis. Without that integration, the analysis is manual work, and in an audit you cannot demonstrate that the feedback took place.
This system sits alongside your existing environment and does not replace it. If you already run a quality management system with document control, we build the MDR layer on top of it. If your production runs in a production system, we retrieve the batch data you need to trace a report. We build this through integrations, so you are not locked in to a single supplier.
How we build your MDR system
We start with the structure of your file, not with a screen design. If the structure does not match what your notified body expects, every audit request turns into a search exercise.
Which devices you place on the market, in which risk classes, and in which variants and versions. This determines how the file is organised: per device, per family, or per basic UDI. That choice shapes everything else and is expensive to change afterwards.
We design how a signal from the market finds its way into the file: from complaint to device, to the risks involved, to an assessment and, where necessary, to a change. That chain is the core of the system.
We work in sprints and start with the area that sees the most day-to-day activity, usually complaints and reports. Your quality team takes part and tests each sprint against real cases from your own history.
Before handover, we walk through the system using the questions a notified body would ask: show the current documentation for this device, the latest PMS analysis and what has followed from it. Anything that cannot be shown in a few clicks, we adjust.
What the system does in practice
Six components that together make up the file and its ongoing monitoring. Which ones you need depends on your risk classes and the size of your portfolio.
Technical documentation per device
Documentation structured according to the regulation's layout, per device and per version, so that for every variant placed on the market you can see which documentation applied to it. Changes are recorded as changes, with the reason attached.
Requirements with their justification
For each general safety and performance requirement, we record whether it applies, which standard you apply and which piece of evidence demonstrates compliance. This is the table an auditor asks for first, and the place where loose references go out of date fastest.
Complaints, reports and vigilance
Every report linked to the device and to the relevant risk, with an assessment of whether it is a reportable incident and a fixed route if it is. Deadlines are monitored, because they start running from the moment you become aware of the event.
PMS analysis and trend monitoring
Signals brought together per device, with a trend view over time so that an increase is noticed before it becomes a problem. The periodic analysis draws on this, rather than someone compiling it by hand from exports.
Updates on schedule
PMS reports and periodic safety update reports have frequencies that vary by risk class. The system plans these in advance and gives timely warnings, including for the clinical evaluation that must be reviewed periodically.
UDI and identification
Basic UDI and the UDI per packaging level recorded against the device, so that a report from the market can be traced to a specific version. For submission to the European database, we prepare the data in the required format.
Who we build for
Four types of organisation, each with a different starting point. The difference lies mainly in the risk class and in whether you are the manufacturer yourself.
Manufacturers of physical medical devices
Production, batches and suppliers all feed into the file. This often connects to your production system, so that a report can be traced back to a batch.
Software manufacturers and SaMD
Your device is software, so versions change faster than with hardware. If you build that software yourself, also look at building medical device software; this page is about the file around it.
Importers and distributors
You are not the manufacturer but you carry your own obligations: checking that the manufacturer has its affairs in order, passing on complaints and maintaining traceability. That calls for a lighter system with a different focus.
Companies with a growing portfolio
You can still manage one device in folders. Once you have around five variants, each with its own versions, working out which documentation belongs to which variant becomes too difficult to answer by hand.
Test your idea first: a working prototype in 1 day
With OneDayBuild, we turn your idea into something tangible in one day for €1,150, so you can see whether further development is worth the investment. Decide to go ahead with the full build? Then we credit the full cost.
Explore OneDayBuild →Technology and integrations
What we build depends on your situation. We do not build medical devices: this system supports your quality process and is not itself a medical device. Where it touches validated environments, we agree the details with your quality manager.
For registering UDI data in EUDAMED, see our page on a UDI integration.
If you manufacture in-vitro diagnostics that fall under the IVDR, see our IVDR documentation system.
Why Appfront
Documentation and market surveillance in one chain
The MDR is about feedback. That is why we do not build two systems side by side, but a single chain in which a report visibly feeds back into the risk analysis.
Built around the audit
We design from what a notified body asks for, and test that with a trial run before handover. That is more concrete than merely meeting a standard on paper.
Versions that add up
For every released variant, you must be able to show which documentation belonged to it. This is a design question about version control, and we address it at the start, not halfway through.
Honest about our role
We are not a notified body or a regulatory consultant. We build the system; the substantive assessment and the discussions with your notified body remain with you and your adviser.
Security and privacy
Reports from the market regularly contain patient data: a description of an incident, sometimes injury, sometimes identifiable details. This is special category data and should not sit unfiltered in a quality system. We set up the input so that what is needed for the assessment is recorded and the rest is not, and free-text fields explicitly warn against copying in patient details.
In addition, your technical file is itself your most valuable business information: design, test results and clinical justification brought together. Access is therefore governed by role and by device, with a separate, temporary role for external auditors who see only what falls within their scope. Every change to an approved document is logged with who made it and why, and approval requires an electronic signature. For how we handle security ourselves, see our information security policy; reports from outside come through our CVD policy.
Frequently asked questions about the MDR technical file
The regulation prescribes a structure: description and specification of the device including variants, the information you supply to the user, design and manufacturing information, the general safety and performance requirements with the justification for each, risk management, verification and validation, and clinical evaluation. In addition, separate documentation on post-market surveillance. We build that structure into the system, so you don't have to work out for yourself where everything belongs.
PMS is the broad process of collecting and analysing data from the market. PMCF is the part of it that specifically gathers clinical data after the device is placed on the market, to keep the clinical evaluation up to date. Vigilance is the reporting route for serious incidents and field safety corrective actions, with its own deadlines. They are connected but have different outcomes, and that distinction is often what gets lost in a shared inbox.
Continuously, and that is the core of the MDR. On top of that there are fixed points: PMS reports and periodic safety update reports have a frequency that varies by risk class, and the clinical evaluation must be reviewed periodically. We build those points in as scheduled tasks with a named owner, because keeping things continuously up to date is precisely what tends to slip without a date attached.
Yes, but in a lighter form. As an importer, you check that the manufacturer has fulfilled its obligations, you keep a register of complaints and non-conforming devices, you pass on reports, and you ensure traceability of what you have supplied. That is a smaller system with a different focus: less documentation, more emphasis on the supply chain and traceability.
That page is about building medical software itself, where the software is the device and standards such as IEC 62304 apply to its development. This page is about the system in which you, as a manufacturer, manage your technical file and post-market surveillance; that system is not itself a medical device. If you make software devices, you often need both, and we keep them separate.
Software you use within your quality management system must be fit for its intended use, and that requires justification. How substantial that justification needs to be depends on which steps you rely on it for. We provide the documentation you need for that justification and agree its scope with your quality manager, rather than making an assumption about it.
The European database is becoming mandatory in phases, and submission follows set formats. We prepare the data in the required form, so that submitting it does not mean retyping. What the integration can do exactly depends on what is available at the time of building; we establish that during the discovery phase rather than promising it in advance.
For the file alone that works, and many manufacturers do exactly that. Where it gets stuck is the feedback loop: a document management system knows nothing about reports, risks or trends, so analysis remains manual work in exports. If you have few devices and few reports, we will tell you honestly that a system of your own isn't worth the effort.
Building an MDR system?
Tell us which devices you place on the market and where your file currently falls apart, and we will help you think through the structure, the link with your reports and the update moments. We build this as a standalone system and as part of a wider custom software project.