EU MDR 2017/745—technical documentation requirements for engineering teams

EU MDR 2017/745 replaced the Medical Device Directive in May 2021 and significantly raised the bar for technical documentation required to obtain CE marking. For engineering teams, the regulation's most demanding element is not the classification logic or the notified body selection—it is the quality, depth, and ongoing maintenance of the technical file that Annex II and Annex III define. Understanding what that file requires from engineering—not from regulatory affairs—is the starting point for building documentation that holds up under scrutiny.

Annex II: the technical documentation structure

Annex II defines the content requirements for the technical documentation that must accompany any Class I (with measurement function, sterile, or reusable), Class IIa, Class IIb, or Class III device seeking CE marking. The structure covers seven major sections: device description and specification; information to be supplied by the manufacturer; design and manufacturing information; general safety and performance requirements (GSPR); benefit-risk analysis and risk management; product verification and validation; and post-market surveillance documentation.

The device description section is more demanding than it may appear. It requires a complete description of the device including variants and accessories, the intended purpose, the intended user population, clinical conditions the device is intended to diagnose or treat, principles of operation, the generation the device belongs to if applicable, and a description of the accessories and other devices intended to be used in combination. Engineering teams are responsible for the technical substance of every claim in this section—the regulatory language is built on top of the engineering specification.

The design and manufacturing information section requires a full description of the design stages, the manufacturing process, and the facilities where manufacturing occurs. It must demonstrate that design changes are controlled and that the device as manufactured corresponds to the device as designed. This maps directly to the design control cascade required under ISO 13485 and, for devices with FDA ambitions, 21 CFR 820.

The GSPR checklist

Annex I of EU MDR defines the General Safety and Performance Requirements—24 top-level requirements covering everything from chemical, physical, and biological properties to sterility, usability, software, radiation, and active devices. The GSPR checklist is the structured demonstration that the device meets each applicable requirement, or a justified rationale for why a requirement does not apply.

The checklist is an engineering document. For each applicable GSPR, the manufacturer must identify the harmonised standards, common specifications, or other technical solutions applied, and reference the verification and validation evidence that demonstrates conformance. A GSPR checklist that cites standards without pointing to specific test reports, design verification records, or risk management outputs is not sufficient for a serious notified body review.

Getting the GSPR checklist right requires that engineering teams write their verification and validation protocols with the GSPR in mind—not map completed test results to the checklist after the fact. The traceability runs from requirement to engineering specification to test protocol to results record to GSPR demonstration. When that chain is built prospectively, the checklist writes itself. When it is built retrospectively, it generates gaps that are expensive to close.

Clinical evaluation

EU MDR requires a Clinical Evaluation Report (CER) for all devices, and raises the evidentiary bar substantially compared to MDD. The CER must demonstrate that the device achieves its intended purpose, that the clinical benefits outweigh the risks, and that any residual risks are acceptable. For many Class IIb and Class III devices, this requires clinical data generated from the device itself—not solely from equivalent devices.

Engineering teams are not typically responsible for writing the CER, but they are responsible for the design evidence that the CER relies on. Performance testing results, biocompatibility data, usability validation, software verification outputs, and the risk management report are all inputs to the clinical evaluation. The CER's strength depends on the completeness of those upstream engineering records.

Post-market surveillance and Annex III

EU MDR requires a Post-Market Surveillance (PMS) plan as part of the technical file, and a Post-Market Surveillance Report (PMSR) or Periodic Safety Update Report (PSUR) depending on device classification. The PMSR is required for Class I devices; the PSUR is required for Class IIa, IIb, and III devices and must be updated on a defined schedule—every year for Class III and implantables, every two years for Class IIa and IIb.

The PSUR feeds directly back into the technical file: if post-market data changes the benefit-risk profile or identifies new hazardous situations, the technical documentation must be updated. This creates a live obligation—the technical file is not a submission artifact, it is a maintained record that reflects the current state of the device and its clinical evidence base.

UDI requirements

EU MDR requires that devices carry a Unique Device Identifier consisting of a Device Identifier and a Production Identifier. UDI requirements apply to all devices placed on the EU market and include registration in the EUDAMED database. Engineering teams are responsible for ensuring that UDI assignment is consistent with labeling requirements, that the UDI carrier meets the applicable AIDC and HRI standards, and that the UDI structure is correctly documented in the technical file.

How MANKAIND structures the technical file from engineering outputs

MANKAIND organises engineering outputs—design inputs, verification protocols, test results, risk management records, software lifecycle documentation—into the Annex II structure as work progresses. When a GSPR requirement is mapped to a design specification, MANKAIND links the downstream verification record that closes it. When a design change is approved, MANKAIND updates the affected sections of the technical file and flags which GSPR demonstrations are affected.

The result is a technical file that is current with the design at every stage of development—not a document assembled for submission and immediately outdated. For teams working toward CE marking under EU MDR, that structural approach is the difference between a technical file that satisfies a notified body's first review and one that spends months in a question-and-answer cycle.