MDCG Pre-Registration Assessment common mistakes
MDCG Pre-Registration Assessment · Understand the traps and how to avoid them.
Treating MDR 2017/745 and IVDR 2017/746 as interchangeable when answering questions about classification, conformity assessment, or the role of EU reference laboratories - for instance, applying MDR Rule 11-style software logic to an IVD or assuming IVDR has the same notified body involvement thresholds as MDR.
Candidates often study MDR in depth and assume IVDR mirrors it, because both regulations share structure, definitions and annex architecture. The genuine differences - IVDR's risk-based four-class system (A, B, C, D) driven by Annex VIII rules, the default requirement for notified body involvement for most IVDs, and the role of EU reference laboratories for class D - get collapsed into MDR habits.
What to do instead
Build a side-by-side comparison table for MDR vs IVDR covering: classification system and rules, default conformity assessment route, notified body involvement, reference laboratory role, performance evaluation vs clinical evaluation, and vigilance timelines. Before answering any question, explicitly identify which regulation applies, then recall the IVDR-specific or MDR-specific rule rather than the generic one.
Confusing the MDCG's status: citing an MDCG guidance document as legally binding, or conversely dismissing it as non-authoritative, instead of characterising it as non-binding interpretative guidance that reflects a consensus position of Member State authorities and is expected to be followed in practice.
MDCG documents are widely used operationally and are sometimes referenced in notified body assessments, which leads candidates to overstate their legal force. Others overcorrect and treat them as irrelevant opinion. The nuance - not law, but the de facto reference for how competent authorities and notified bodies interpret the law, and divergence should be justified - is what examiners test.
What to do instead
Memorise the framing: MDCG guidance is issued under Article 103 MDR / Article 98 IVDR, is not itself legislation, does not create new obligations, and represents a common understanding of how to apply the Regulation. Practise phrasing answers that distinguish 'legal requirement (Regulation/Annex)' from 'interpretative guidance (MDCG)' and note that a manufacturer departing from guidance should document justification.
Misapplying the classification rules - especially MDR Rule 11 (software), Rule 10 (active devices for diagnosis/monitoring), Rule 12 (devices administering/removing medicinal substances), and the IVDR Annex VIII rules - by focusing on the device's technology or intended user rather than on the precise wording of the rule and its stated exceptions.
Classification rules are read quickly and candidates pattern-match on familiar device types. Rule 11 in particular is widely misapplied because the default (class IIa) and the escalation triggers (serious deterioration of health, death or irreversible deterioration, or surgery) are frequently confused, and the software-specific MDCG guidance nuances are skipped.
What to do instead
Work through each rule word by word, identifying the trigger terms ('diagnosis or treatment', 'monitoring', 'serious deterioration', 'surgery') and applying the exceptions in order. For Rule 11, memorise the decision sequence: does the software provide information used for decisions with diagnostic or therapeutic purposes; if yes, default class IIa; escalate to IIb or III only where the specified harm conditions apply. Practise with worked examples and state the reasoning chain in answers.
Selecting a conformity assessment route without linking it to the device class and to whether the manufacturer holds a QMS, or assuming notified body involvement is always required or never required. For example, stating that all class I MDR devices need a notified body, or that class A non-sterile IVDs do not require any third-party involvement regardless of circumstances.
Candidates learn the Annex IX/XI routes in isolation from Annex VIII classification, so the dependency between class, route and QMS scope is not internalised. The exceptions - class I devices with a measuring function or supplied sterile, class A IVDs that are sterile or have measuring functions, and the role of Annex IX vs Annex XI Part A vs Part B - are exactly where marks are lost.
What to do instead
Map the decision tree explicitly: classify first, then identify the default Annex route, then identify whether a notified body is needed and which Annex (IX full QMS, X type-examination, XI production QMS/QA) applies, then note any exceptions requiring notified body involvement despite low class. Memorise the specific carve-outs (sterile, measuring function, reusable surgical instruments) and practise writing the full route for a given device scenario.
Describing technical documentation as a checklist of documents rather than as an evidence-based argument demonstrating conformity, and failing to reference the correct Annex (MDR Annex II and III, IVDR Annex II and III) or to connect the technical documentation to the GSPR checklist in Annex I.
Technical documentation is often studied as a list of section headings. Candidates then write answers that enumerate documents without explaining the purpose - to demonstrate conformity with the GSPRs - or without noting the requirement for a GSPR checklist, the role of the Annex II structure, and the additional Annex III post-market documentation.
What to do instead
Frame technical documentation as an argument: for each GSPR, identify the requirement, the evidence (test reports, clinical/performance data, risk management file, labelling), and the justification. Memorise the Annex II headings and the Annex III additions, and practise stating that the technical documentation must allow the conformity of the device with the GSPRs to be assessed and must be kept up to date throughout the lifecycle.
Confusing clinical evaluation (MDR) with performance evaluation (IVDR), or treating clinical evaluation as a one-off pre-market exercise rather than a continuous process, and failing to distinguish clinical investigation, PMCF and post-market performance follow-up (PMPF).
The terminology overlaps and the annexes (MDR Annex XIV and XV; IVDR Annex XIII and XIV) are structurally similar, so candidates blur them. They also miss that clinical evaluation is a lifecycle activity requiring updates, and that PMCF/PMPF are part of the clinical/performance evaluation plan, not separate afterthoughts.
What to do instead
Create a terminology grid: clinical evaluation vs performance evaluation; clinical investigation vs performance study; PMCF vs PMPF; and the corresponding annexes. For each, note the objective, the evidence required, the plan document, and the update trigger. Practise answers that explicitly state the lifecycle nature - evaluation is planned, conducted, documented and updated throughout the device lifecycle, with PMCF/PMPF feeding back into it.
Mixing up post-market surveillance obligations, vigilance reporting and PMCF - for example, stating that a serious incident must be reported to a notified body within a single fixed timeframe, or confusing the PSUR with the PMS plan, or omitting the trend reporting requirement.
PMS, vigilance and PMCF sit in adjacent articles and annexes and share terminology. Candidates memorise one timeline and apply it universally, missing the distinctions between serious incident reporting (15 days, 10 days for serious public health threat, 2 days for death or unanticipated serious deterioration), field safety corrective action reporting, and trend reporting of non-serious incidents.
What to do instead
Build a table of vigilance scenarios with the correct recipient (competent authority of the Member State where the incident occurred), the correct timeline, and the correct trigger. Separately list the PMS plan contents (MDR Annex III / Article 84), the PSUR requirements by class, and the PMCF plan. Practise distinguishing 'reportable incident' from 'trend report' from 'PMCF activity' with concrete examples.
Treating ISO 13485 and ISO 14971 as generic quality/risk frameworks without connecting them to the specific MDR/IVDR requirements - for example, describing risk management as a standalone exercise rather than as the Annex I GSPR 1-3 obligation requiring a risk management file, and failing to address supplier controls as part of the QMS.
Candidates with quality backgrounds rely on ISO knowledge and do not map it to the Regulation. They miss that MDR Annex IX requires a QMS that addresses the Annex I GSPRs, that the risk management file must demonstrate the risk-benefit balance, and that supplier controls (critical suppliers, audits, agreements) are assessed under the QMS.
What to do instead
Map each ISO 13485 clause to the corresponding MDR Annex IX QMS requirement, and each ISO 14971 element to GSPR 1-3 and the risk management file requirement. For supplier controls, memorise the expectation: documented supplier evaluation and selection, defined critical suppliers, audit rights, quality agreements, and change notification obligations, all under the manufacturer's QMS responsibility.
Confusing UDI requirements - the Basic UDI-DI vs the UDI-DI, the issuing entity role, the UDI database (EUDAMED) submission, and the labelling/carrier requirements - and assuming UDI is fully operational in EUDAMED when some modules have had staged deployment.
UDI terminology is dense and the Basic UDI-DI is easily confused with the UDI-DI. Candidates also assume EUDAMED is fully live, missing that the regulation provides for staged functionality and transitional arrangements, and that certain obligations depend on module availability.
What to do instead
Define each term precisely: Basic UDI-DI (device model identifier, used for registration and traceability, not on the label), UDI-DI (specific to device/package configuration, on the label and in the database), UDI-PI (production identifiers such as lot, serial, expiry). Note the issuing entity role (GS1, HIBCC, ICCBBA, IFA) and the requirement to submit to the UDI database. Track the EUDAMED module status and transitional provisions rather than assuming full operability.
Answering EUDAMED questions as if registration is a manufacturer-only obligation, or omitting the actor registration, the economic operator roles (manufacturer, authorised representative, importer, distributor), and the data governance/access rules - and failing to note the SRN and the linkage between actor registration and device registration.
EUDAMED is often studied as a single 'register the device' step. Candidates miss the multi-module structure (actor, UDI/device, certificate, clinical investigation/performance study, vigilance, market surveillance), the SRN assignment, and the fact that importers and authorised representatives also have registration obligations.
What to do instead
Map the six EUDAMED modules and, for each, list which actors have obligations. Memorise the SRN concept and the sequence: actor registration → SRN → device/UDI registration → certificate and vigilance data linkage. Note data access levels (public vs restricted) and the requirement to keep data current. Practise scenario questions that ask who must register what.