Few files are rejected for a spectacular reason. What delays a CE marking are ordinary discrepancies: an intended purpose that shifts from one document to the next, a standard quoted without its year, a requirements table pointing to a file nobody can find. Under MDR 2017/745, these technical documentation errors trigger requests for information from the notified body, and every round trip costs weeks. Here are the ten we see most often, and how to deal with them before submission.

What the regulation expects: Annexes I, II and III

Three annexes frame the demonstration. Annex I sets the general safety and performance requirements: Chapter I for the general requirements, Chapter II for design and manufacture, Chapter III (Section 23) for the information supplied with the device. Annex II describes the content of the technical documentation in six blocks: device description and specification, information to be supplied by the manufacturer, design and manufacturing information, general safety and performance requirements, benefit/risk analysis and risk management, product verification and validation. Annex III covers post-market surveillance documentation. The MDR is one of the frameworks covered by our review, class by class.

The timetable matters. Article 120, as amended by Regulation (EU) 2023/607, ends the transitional regime on 31 December 2027 for class III devices and class IIb implantable devices, well-established technologies aside, and on 31 December 2028 for other class IIb devices, class IIa devices and class I devices placed on the market in sterile condition or with a measuring function. Those dates assumed a formal application lodged by 26 May 2024 and a written agreement signed with a notified body by 26 September 2024.

Device identity: three basic discrepancies

  • Error 1. A description that does not cover every variant. Annex II, Section 1.1, calls for a list of the configurations and variants to be made available, together with a description of accessories and of products intended to be used in combination. A file that describes the lead model and scatters sizes, lengths or software versions across other documents forces the assessor to rebuild the certified scope.
  • Error 2. A class stated without the rule behind it. The same Section 1.1 requires the risk class and the justification of the classification rule or rules applied under Annex VIII. Writing "class IIa" without naming the rule, and without addressing competing rules, invites a question every time. Guidance MDCG 2021-24 rev.1 is the shared reference here.
  • Error 3. An intended purpose that varies between documents. The intended purpose appears in the description, on the label, in the instructions for use, in the risk management report and in the clinical evaluation. One shade of wording on the target population, the indication or the use environment is enough to create an internal contradiction, and it is one of the most common findings.

MDR 2017/745 technical documentation: the evidence errors that cost most

  • Error 4. An incomplete general requirements table. Annex II, Section 4, asks, for each requirement in Annex I: whether it applies and why any requirement is excluded, the method used to demonstrate conformity, the harmonised standards or common specifications applied, and the precise identity of the controlled documents that provide the evidence. A generic pointer such as "see design file" does not fill that last column.
  • Error 5. Standards quoted without an edition or documented deviation. A standard with no year, or applied in part without justifying the clauses left out, leads the assessor to conclude that the evidence is not established. The same reasoning applies to common specifications and to any alternative solution adopted under Annex I.
  • Error 6. Risk management disconnected from the clinical side. Annex I requires a risk management system across the whole life cycle, and Annex II, Section 5, the benefit/risk analysis. When residual risks appear neither in the clinical evaluation report drawn up under Article 61 and Annex XIV Part A, nor in the warnings of the instructions for use, the loop is not closed and the notified body notices.

Information supplied with the device

  • Error 7. Labelling and IFU left to the end of the project. Annex I, Chapter III, Section 23, lists the content of the label and of the instructions for use, from the UDI carrier to warnings and precautions. Annex II, Section 2, further requires the labels and the instructions for use in the languages accepted in the Member States where the device is envisaged to be sold. That language work has to be planned, not improvised three weeks before submission.
  • Error 8. Related documents out of step. The summary of safety and clinical performance required by Article 32 for implantable and class III devices, the implant card of Article 18 and promotional material all carry claims. Each claim must stay within the intended purpose and rest on evidence held in the file. A claim that appears in a brochure but not in the technical documentation is a discrepancy.

Post-market surveillance and keeping the file current

  • Error 9. Annex III treated as a formality. The post-market surveillance plan of Article 84, the periodic safety update report of Article 86 or the report of Article 85 depending on class, and the post-market clinical follow-up plan of Annex XIV Part B must exist before certification, with named data sources. Where post-market clinical follow-up is not conducted, the justification belongs in the file.
  • Error 10. Versions that do not line up. Version numbers, approval dates, cross-references: when the clinical evaluation report cites an IFU version that is no longer the one in the file, or when two documents state two different shelf lives, it is document control itself that is called into question.

A consistency review before submission

Before sending the file, a review aimed at contradictions pays better than a linear read. What to check:

  • the intended purpose, word for word, in the five documents where it appears;
  • the list of variants and accessories, identical everywhere, test reports included;
  • every line of the general requirements table pointing to a document identified by reference and version;
  • every standard with its edition, and the status of any clause not applied;
  • residual risks carried through to the instructions for use and the clinical evaluation report;
  • promotional claims tied to evidence held in the file;
  • shelf life, storage conditions and number of reuses, consistent across documents.

In practice

A technical file is judged on its consistency as much as on its content. Have the whole set read by someone who wrote none of the documents, with a single instruction: look for discrepancies. Internal requirements such as procedures, claim matrices and charters are worth formalising so they can serve as the reference for that review, and we explain how to submit them as internal frameworks. EryonOne runs that cross-checking on the PDF documents of a file and cites, for each finding, the exact passage and the reference text, which keeps the review traceable. The report stays working material rather than an approval: the decision belongs to the regulatory expert, as we set out in what an assisted review changes.

Bibliographie