How to Build Winning Technical Documentation: A Complete Guide to MDR Preparation
One of the main requirements for medical device manufacturers operating in the European market is building technical documentation in line with MDR 2017/745. This documentation serves as the product's regulatory identity card, and its purpose is to demonstrate compliance with safety, performance and quality requirements throughout the product's entire life cycle. Building high-quality technical documentation is not a simple task, but a thorough understanding of its structure and basic principles will help you prepare wisely, save valuable time and improve your chances of quick approval from the notified body.
What technical documentation means under the MDR
According to Annexes II and III of the MDR, the technical documentation must present a complete and up-to-date picture of the product's design, its manufacture, risk assessments, test data, clinical evaluation, the post-market surveillance (PMS) system, and more. The documentation is not linear. It is an ecosystem of documents, so consistency, clarity and close links between the different parts are very important.
The seven pillars of technical documentation
Device description and specification: This includes the trade name, UDI code, operating principles, target population, materials, configurations and more.
Information supplied by the manufacturer: This includes manuals, labels, IFU, implant cards, marketing material, the website and more.
Design and manufacturing information: This includes manufacturing flowcharts, critical processes, in-process control, OQ/PQ and validations.
General safety and performance requirements (GSPR): This covers mapping the requirements, evidence of compliance with them, and relevant standards.
Risk management and benefit-risk analysis: This follows ISO 14971 and includes systematic analysis, residual risk and benefit assessment.
Verification and validation, including clinical evaluation: This covers plans and results for biocompatibility, software testing, electrical safety, usability, clinical evaluation and more.
Post-market surveillance (PMS): This includes the PMS plan, PMCF, PSUR reports and corrective actions.
How do you keep the process under control?
A. Define one consistent Intended Purpose
The intended purpose document is the anchor point for all other documents. Inconsistency between documents (for example, between the clinical evaluation and the IFU) will lead to questions from the notified body. My recommendation is to prepare one agreed statement and make sure all documents align with it.
B. The 3C method: clarity, consistency, connectivity:
Clarity: Write simply and clearly, with the reviewer in mind.
Consistency: Keep versions, terms and links uniform.
Connectivity: Show the relationships between documents and cross-reference them.
C. Treat the technical documentation as a managed project:
Involve people from development, quality, regulatory and clinical.
Create traceability charts from URS (user requirements) to FRS (functional requirements).
Document every stage and leave no gaps.
D. A summary document for each section:
For each part of the documentation, add a short summary page with the main conclusions. This is an important tool for a reviewer who wants to understand the key points quickly.
E. Smart version management:
Set one deadline for comments.
Do not allow last-minute comments.
Give internal reviewers a clear checklist.
Implementing the GSPR: key recommendations
Start the GSPR document already during development, as an internal guide for documentation.
For each requirement, determine applicability, explain the methodology and present evidence (tests, analyses, documents).
Create a traceability table between the requirements and the documentation as a whole.
Post-market surveillance is not just a formality
The PMS system should be integrated into the quality management system and connected to risk management, clinical documentation and the CAPA process.
You need to show ongoing monitoring and the use of market data, professional literature, databases, complaints and returns.
The reports (PMSR/PSUR) should include trend analysis, conclusions and the impact on the product's design and documentation.
Common mistakes that lead a notified body to reject the documentation
Even when the technical documentation looks "complete", notified bodies report the same mistakes again and again:
Gaps between documents: For example, the IFU describes a certain use, while the clinical evaluation refers to a different indication.
An incomplete GSPR document: Sometimes the document does not include a justification for non-applicability, or does not show the methodology chosen to meet the requirement.
Lack of objective evidence: Statements such as "the system is safe" are not enough without test reports, validation results or risk analyses.
Outdated documentation: This includes different versions of the same document in the file, conflicting dates, or references to files that no longer exist.
Lack of change control: This happens when there are clinical or technological changes that are not backed by a matching change in the documentation.
Before submitting to the notified body, carry out an internal review (a mock audit), preferably by an experienced regulatory professional who was not involved in preparing the documentation.
Key regulatory requirements to reference
While building the technical documentation, there are specific regulatory documents you must know and work with:
MDR 2017/745: In particular Annex II (structure of the technical documentation) and Annex III (PMS).
MDCG 2020-6: An important explanation of the difference (or lack of difference) between Intended Use and Intended Purpose.
MDCG 2022-21: Practical guidance on PSUR content and the links to PMS/PMCF.
ISO 14971:2019: Risk management.
ISO 13485:2016: Quality management systems.
In every section of the technical documentation, include specific references to the relevant articles of the regulation. This makes the reviewer's work easier and increases credibility.
More tips from the field
Use a smart, linked electronic format.
Create a V&V matrix that brings together all the tests and evidence of conformity.
Update the documentation on an ongoing basis. Every technical, clinical or regulatory change should be reflected in the documentation.
Link documents with hyperlinks for efficient management.
Document the whole development process with diagrams and explanations.
Case study for a Class IIa product: a smart system for monitoring chronic wounds
Background: An Israeli startup developed a sensor that is attached to the skin, monitors chronic wounds (such as pressure ulcers) and sends data to an app.
The challenge:
It is a portable electronic device with Bluetooth components.
Its software includes algorithm-based analysis.
Its indication is non-surgical, so it is Class IIa.
Preparing the technical documentation:
The device description included the configuration, operating principles and interaction with the skin.
GSPR: The team focused on requirements related to electrical safety and RF emissions (IEC 60601-1-2).
The risk documentation included scenarios of disconnection, communication failure and app problems.
Clinical validation: This was supported by existing literature and a small clinical study (n=20).
PMS/PMCF: This included a mechanism for collecting post-market data from the field, in cooperation with an Israeli health fund (HMO).
Result:
The documentation was submitted to a German notified body with organized templates, cross-references and well-founded evidence. The review went through with only one question and no need for significant changes.
What about diagnostic devices? A note on the IVDR
If you work with IVD devices, it is important to know that the IVDR 2017/746 also requires technical documentation that is similar to, but not the same as, the MDR's.
Main differences:
A different classification (Class A-D) based on diagnostic risk.
Stricter requirements for demonstrating performance (Performance Evaluation).
A PMPF plan is required, parallel to the PMCF for other medical devices.
Who this is relevant for:
PCR kits, serological tests, laboratory diagnostic instruments, and apps that analyze medical data.
Structure of the documentation:
It is similar to the MDR, but with an emphasis on analytical and clinical performance, standards such as ISO 20916 (point-of-care testing), and specific requirements for automated tests.
Even if you are used to working under the MDR, do not assume the same applies to IVDR documentation. It is worth getting help from a consultant who knows the differences in depth.
Summary
High-quality technical documentation is not just a collection of files. It is a living system that is coherent, connected, documented and maintained. Setting up the technical documentation correctly saves time, reduces regulatory risk and makes the road to CE marking much easier.
The right support in this process from someone experienced can turn the journey from frustration into success.