We Answered the Top Questions About EU MDR Technical Documentation

We cannot say that this data would be enough. You have to evaluate the existing study as per the MDR requirements. Most probably for local regulatory authority there would be no GSPR requirements. So you have to determine either your existing clinical study sufficiently address all the applicable requirements in EU MDR, before submission. As per Article 61(3)(b), a clinical evaluation may rely on "a critical evaluation of the results of all available clinical investigations," and Article 61(1) states the data must provide "sufficient clinical evidence" appropriate to the device's risk/intended purpose, regardless of which authority it was originally submitted to.

You have to consider that the data quality/statistical power adequate per Annex XIV, Part A, and it also complies with the requirements of Article 61 as well.

For Class IIa devices, Minimum PMS documentation expected before certification should include:

Post-Market Surveillance (PMS) Plan that include compliant with MDR Article 84 and Annex III that defines data sources, complaint handling, vigilance activities, trend reporting, literature monitoring, CAPA linkages, responsibilities, and review frequency, PMS Procedure within the QMS that demonstrates how PMS is implemented and maintained, Integrated with risk management & clinical evaluation processes  and linkage to Risk Management and CER in which evidence provide that PMS results will be used to update the Risk Management File and Clinical Evaluation Report (CER).For a device seeking initial certification, actual PMS reports (PSURs) are typically not yet available unless the device has already been marketed elsewhere. However, the PMS system and plan must be in place.

Since full MDD-era design history files are often incomplete against MDR expectations, the practical approach (aligned with MDCG 2020-6's philosophy) is:

1. Gap analysis: compare existing design verification/validation records against current Annex I/Annex II requirements.
2. Retrospective compilation: pull together whatever original V&V records, complaint data, and vigilance history exist.
3. Leverage real-world PMS data: extensive, well-analyzed market history with low complaint/incident rates is treated as substantive supporting evidence for legacy devices specifically.
4. Targeted supplementary testing: where a genuine gap exists (e.g., biocompatibility tested to an outdated ISO 10993 edition), run focused new testing rather than a full re-validation.
5. Update the risk management file (ISO 14971 latest version) to reflect this consolidated evidence base.

GSPR’s are the General Safety and Performance Requirements set out in Annex I of EU MDR. There are total 23 GSPR’s. i.e., Annex I Chapter II describes Requirements regarding Design & Manufacture.

Implant Card (Article 18): required for implantable devices, containing device ID (name, serial/lot, UDI, model, manufacturer name/address/website), warnings/precautions or measures to be taken by patient or healthcare with regard to reciprocal interference with other equipment/examinations, expected lifetime/follow-up needs, and other safe-use info. Exempted implants from Article 18 requirements includes sutures, staples, dental fillings, dental braces, tooth crowns, screws, wedges, plates, wires, pins, clips, connectors (Article 18(3)). In the TD, this sits logically under Annex II, Section 2 (information supplied by the manufacturer), alongside labelling/IFU, since it's part of what accompanies the device.

SSCP (Article 32): required for Class III devices and implantable devices only (not IIa/IIb generally). Drafted by the manufacturer, validated by the NB, published on EUDAMED. Generally Content includes device/manufacturer ID incl. Basic UDI-DI, intended purpose/indications/contraindications/population, device description incl. prior generations, diagnostic/therapeutic alternatives, standards/CS applied, clinical evaluation summary + PMCF info, user training profile, residual risks/warnings. In the TD, it belongs with Annex II, Section 6.1 (it's built directly from the CER) and gets updated in sync with Annex III PMS/PMCF cycles.

Common NCRs includes GSPR checklist entries not traceable to evidence, or citing superseded standard editions; CER not aligned with current state-of-the-art literature; risk management file not updated against actual V&V results; generic (non-device-specific) PMS plans with no defined trend-reporting thresholds; UDI/labelling mismatches across TD/EUDAMED/physical samples; missing or expired sterilization/shelf-life validation; unjustified "PMCF not applicable" claims; SSCP not kept current with the latest clinical/PMS data.

Verification: confirms design output meets specified design input requirements, done at each design stage via inspection, analysis, or test.

Validation: confirms the device meets the needs of the actual intended use/user, typically via testing under actual or simulated use conditions (including, where relevant, clinical evaluation).

This is formalized in your QMS design controls (ISO 13485 design and development verification/validation clauses) and is exactly what Annex II §6 asks the TD to summarize with results and critical analyses.

Verification: objective evidence that the software design output meets the design input requirements at each development stage (did we build it right?) i.e., code reviews, unit/integration/system testing, static analysis.

Validation: objective evidence that the finished software, in its actual/simulated use environment, meets user needs and intended use (did we build the right thing?) i.e., system-level and usability validation.

Legal basis: Annex I, Section 17.2 states software "shall be developed and manufactured in accordance with the state of the art taking into account the principles of development life cycle, risk management, including information security, verification and validation." The practical standard applied is IEC 62304 (software lifecycle processes) alongside IEC 62366-1 (usability) and ISO 14971 (risk management).

As per MDR Annex I, Section 15 ("Devices with a diagnostic or measuring function"), devices must be designed/manufactured for "sufficient accuracy, precision and stability" appropriate to intended purpose, with manufacturer-declared accuracy limits, and measurements expressed in legal units per Directive 80/181/EEC. Practically, this is verified through metrological traceability, calibration against national/international reference standards (ideally via an ISO/IEC 17025-accredited lab), device-specific performance standards where they exist (e.g., IEC 60601-2-xx series for specific active measuring devices), and documented in Annex II §6.1 verification/validation evidence, with defined re-calibration/re-verification intervals.

This is particularly relevant to the performance claims by the manufacturer, as it needs to justify their claims through proper validated results as well. These need quite different validation strategies:

Active/electronic devices (glucometer-type): electrical safety and EMC per IEC 60601-1 / -1-2; software verification & validation per IEC 62304; usability engineering per IEC 62366-1; performance/accuracy validation against a device-specific standard (for blood glucose monitoring specifically, ISO 15197, note glucometers are typically IVDR-scoped, not MDR, so check which regulation actually applies to your product).

Non-active/mechanical implants (stent-type): mechanical/bench testing to a device-specific standard (e.g., ISO 25539-2 for endovascular stents), biocompatibility per ISO 10993, plus manufacturing process validation under ISO 13485 §7.5.6 (critical for processes like laser-cutting, welding, coating, or sterilization where output can't be fully verified by inspection alone) — GHTF/IMDRF SG3's process validation guidance is still widely used as the practical reference here.

Both device types still need the GSPR-driven verification/validation package under Annex I §17.2 (for anything with embedded software) and Annex II §6.1. 

This question is outside the EU MDR scope (SFDA is a separate national authority), so treat this as general regulatory-affairs practice rather than something the Regulation dictates. SFDA generally expects the GHTF/IMDRF STED format (Summary Technical Documentation) per its MDS-G5 guidance. Since MDR Annex II/III content substantially overlaps with STED, the usual approach is a mapping/cross-reference matrix: device description → STED device description; GSPR checklist → STED essential-principles checklist; risk management file → STED risk analysis summary; clinical evaluation → STED clinical evidence summary; manufacturing info → STED manufacturing section. On top of the content mapping, SFDA has its own local/administrative layer (Authorized Representative in KSA, Arabic labelling, MDMA license validity, submission via SFDA's national registry) that isn't covered by the MDR at all. I'd recommend checking SFDA's current MDS-REQ series directly for the definitive mapping, since local requirements do get updated independently of the EU MDR.