EUDAMED is the European database established under MDR Article 33 that, among other things, makes the Summary of Safety and Clinical Performance (SSCP) publicly accessible for implantable and Class III devices. Under MDR Article 32, the manufacturer drafts the SSCP, the Notified Body validates it as part of the conformity assessment, and the validated SSCP is then uploaded to EUDAMED linked to the device's Basic UDI-DI. Once the relevant EUDAMED module is live and mandatory, any clinician or patient can search the database by device identifier and read the same validated document. Article 34 and Commission Implementing Regulation (EU) 2021/2078 set the functional rules of the database itself.

By Tibor Zechmeister and Felix Lenhard. Last updated 10 April 2026.

TL;DR

  • EUDAMED public access to the SSCP is the mechanism MDR Article 32(2) points at when it says the SSCP "shall be made available to the public via Eudamed".
  • The Notified Body — not the manufacturer — uploads the validated SSCP to EUDAMED after the conformity assessment under MDR Article 52.
  • The SSCP in EUDAMED is linked to the Basic UDI-DI of the device, which is the identifier a clinician or patient uses to find it.
  • MDCG 2019-9 sets the language expectations: the SSCP must be in a language accepted in the Member States where the device is sold, and a validated English version is expected on top.
  • The functional rules of EUDAMED — including its modules, access rights, and public-facing behaviour — sit in MDR Article 33 and Article 34, and in Commission Implementing Regulation (EU) 2021/2078.

Why public access is the whole point of the SSCP

The SSCP exists because the MDR decided that for the highest-risk devices — implantables and Class III — the clinical performance and safety picture should not live inside a technical file that only a Notified Body and a competent authority ever see. It should live in a public database. That choice is the one that separates the MDR's transparency regime from the old Directives, and it is the reason MDR Article 32 cannot be read in isolation from Article 33.

For a founder shipping an implantable or a Class III device, this changes the nature of the document you are writing. A CER is written for reviewers. An SSCP is written for the public, and the public finds it through EUDAMED. Every hedge, every vague claim, every weak evidence summary survives in a public record attached to the device's Basic UDI-DI for as long as the device is on the market. The SSCP is the only document most patients will ever read about the implant inside their body. EUDAMED is the front door.

Post 193 in this series covers what the SSCP must contain and how to write it. This post covers the other half of the picture — how the validated document actually reaches the public, and what a startup has to do on the EUDAMED side to make that happen cleanly. See the full SSCP under MDR Article 32 post for the drafting mechanics.

What MDR Article 32 says about publication

The publication clause in MDR Article 32 is short but load-bearing. The SSCP shall be written in a way that is clear to the intended user and, if relevant, to the patient, and shall be made available to the public via EUDAMED. The draft SSCP shall be part of the documentation submitted to the Notified Body responsible for the conformity assessment, and shall be validated by that Notified Body. After validation, the Notified Body uploads the SSCP to EUDAMED. The label or the instructions for use of the device must indicate where the summary is available. (Regulation (EU) 2017/745, Article 32.)

Three things sit inside that clause that startups regularly miss.

First, the validation is a hard gate. The SSCP is not a document the manufacturer posts to their own website to satisfy Article 32. The MDR says "made available to the public via EUDAMED" — not "made available on the manufacturer's site". A manufacturer-hosted SSCP does not discharge the Article 32 obligation. The route runs through the Notified Body and into EUDAMED, or it does not satisfy the regulation.

Second, the Notified Body uploads it. Not the manufacturer. The manufacturer cannot push an SSCP directly into EUDAMED's public modules. This is a deliberate design choice — EUDAMED treats the Notified Body's upload as the attestation that the document was validated against Article 32 and MDCG 2019-9. If the Notified Body has not uploaded it, there is no EUDAMED record, and the Article 32 obligation is not met.

Third, the label or IFU must point readers to where the SSCP lives. In practice this is a reference to EUDAMED and a device identifier the reader can use to search. Skipping this labelling obligation is a common non-conformity at audit and a trivially easy one to fix.

The EUDAMED frame: Articles 33 and 34

The SSCP publication route sits inside a larger architecture defined by MDR Articles 33 and 34, and by Commission Implementing Regulation (EU) 2021/2078.

MDR Article 33 establishes EUDAMED — the European database on medical devices — and lists the modules it contains. Among those modules are the UDI and device registration system, the Notified Body and certificate module, the clinical investigation module, the vigilance module, the post-market surveillance module, and the market surveillance module. The SSCP does not have its own top-level module; it is attached to the device record through the Basic UDI-DI and surfaces through the public-facing side of the UDI/device registration module. (Regulation (EU) 2017/745, Article 33.)

MDR Article 34 sets the functional rules — who uploads what, who accesses what, and the fact that EUDAMED is generally publicly accessible except for specific data elements that are restricted. Commission Implementing Regulation (EU) 2021/2078 is the detailed rulebook for how the database actually functions: registration, access rights, nomenclature (EMDN), technical support, data ownership, contingency procedures, information security, and personal data processing. (Regulation (EU) 2017/745, Articles 33 and 34; Commission Implementing Regulation (EU) 2021/2078.)

For a startup, the practical consequence is that EUDAMED readiness is not one task. It is at least three: registering as an economic operator and getting an SRN, registering the device with its Basic UDI-DI and UDI-DI, and making sure the SSCP workflow with the Notified Body ends with a validated document linked to that Basic UDI-DI. For the pillar on EUDAMED itself, see what is EUDAMED — the European database for medical devices.

Languages: the clause everyone reads late

The MDR text of Article 32 does not itself prescribe the languages of the SSCP. MDCG 2019-9 closes that gap. The guidance says the SSCP must be available in the official Union language or languages accepted in the Member States in which the device is placed on the market or put into service, and, on top of that, a validated English version is expected regardless of the distribution territory. The rationale is that EUDAMED is a pan-EU database — a clinician in Spain may search for a device sold primarily in Germany, and a patient wherever they are should have an English path to the same validated content.

For a startup this is the clause that routinely breaks the timeline. Translating an SSCP is not a drop-in exercise. Every translated version of the professional section and the patient section has to be produced, reviewed, and validated by the Notified Body. Every translated version inherits the Article 32 validation requirement. A startup that assumes an English SSCP will cover Europe and discovers at audit that three additional language versions need drafting, review, and Notified Body sign-off adds weeks to the certification timeline. Plan language scope at the same time you plan distribution scope, not afterwards.

A worked publication scenario

Consider a hypothetical startup — call it Cardiac Rhythm — certifying a Class III implantable cardiac monitor in a single legal manufacturer entity in Germany, intended for sale across Germany, Austria, France, and the Netherlands. The device is intended to be used on patients who should reasonably be informed about it, so the SSCP needs both a professional section and a patient section.

The team drafts the SSCP in German and in English against the MDCG 2019-9 template, using the clinical evaluation report, the risk management file, and the instructions for use as the source documents. They produce French and Dutch translations of both sections before the Notified Body audit, knowing that all language versions will be reviewed.

At the conformity assessment under MDR Article 52, the Notified Body reviews the draft SSCP in all four language versions plus English. The NB returns comments: the patient section in the French version uses medical terminology the plain-language rule prohibits, and the German professional section cites a clinical endpoint that differs from the endpoint reported in the CER summary. Cardiac Rhythm revises both and resubmits.

Once the NB is satisfied, the certificate is issued under the relevant conformity assessment annex, and the validated SSCP — in all language versions — is uploaded by the Notified Body to EUDAMED and linked to the device's Basic UDI-DI. The label carries a reference telling readers the summary is available on EUDAMED and how to find it by the device identifier.

A clinician in Vienna searches EUDAMED by the Basic UDI-DI and finds the German SSCP. A patient in Amsterdam searches and finds the Dutch patient section. A regulatory specialist in Lisbon searches and finds the English version. All of them are reading the same validated document, pulled from the same EUDAMED record, attached to the same device, attested by the same Notified Body.

If any of those language versions were missing, the Article 32 obligation would not be met for the relevant Member State. If the Notified Body had not uploaded the validated version, there would be no EUDAMED record at all. If the label did not point to EUDAMED, readers would not know where to find the summary in the first place.

The publication-ready SSCP playbook

For a startup producing its first SSCP with EUDAMED publication in mind, the following sequence works cleanly and hands over to the Notified Body in a state that survives validation.

Step 1 — Confirm Article 32 scope. Implantable or Class III, and not custom-made or investigational. If in scope, the publication route is mandatory. If not, it does not apply.

Step 2 — Plan the language scope up front. List every Member State of intended distribution and every language each requires, plus the English version MDCG 2019-9 expects. Scope the translation budget and timeline before you start drafting.

Step 3 — Draft against MDCG 2019-9 structure. Use the section headings and content expectations from the guidance. Notified Bodies validate against it. See the drafting mechanics in how to write an SSCP for a Class III implantable device.

Step 4 — Cross-check every claim to a source document. CER, risk management file, post-market clinical follow-up plan, instructions for use. Every SSCP claim must trace to one. Drift between documents is the most common SSCP finding at audit.

Step 5 — Produce all language versions before the NB audit. Do not assume you can add a language later. Every version the market needs has to be in the NB's hands during the conformity assessment, or the validation has to happen twice.

Step 6 — Submit as part of the conformity assessment under MDR Article 52. The NB reviews, returns comments, and eventually validates. The validated versions are what EUDAMED publishes.

Step 7 — Confirm the Notified Body EUDAMED upload. After validation and certificate issue, check that the SSCP record is live in EUDAMED and linked to the correct Basic UDI-DI. This is the only step you as the manufacturer cannot do yourself — you have to verify the NB did it.

Step 8 — Update the label and IFU. The reference telling readers where to find the SSCP must be on the label or in the instructions for use. This is an Article 32 requirement and an easy audit finding if it is missing.

Step 9 — Plan the update cycle. The SSCP is a living document. Build SSCP review into the PMS plan, tied to the clinical evaluation updates, the PSUR under MDR Article 86 for Class III and implantables, and any field safety corrective actions. Every update goes through the same NB validation and EUDAMED upload cycle.

Reality Check — Where do you stand?

  1. Have you confirmed that your device is in scope of Article 32, and that none of the exceptions (custom-made, investigational) apply?
  2. Have you listed every Member State of intended distribution and every language version the SSCP must cover, including the English version MDCG 2019-9 expects?
  3. Is your Notified Body aware that the SSCP in every language version will be part of the conformity assessment submission, and have they confirmed the timeline to validate all versions?
  4. Do you have a documented process for confirming that the Notified Body has actually uploaded the validated SSCP to EUDAMED and linked it to the correct Basic UDI-DI after certification?
  5. Does your label or IFU artwork already include the reference telling readers where to find the SSCP, or is that still a to-do?
  6. Is the SSCP update cycle written into the PMS plan, with triggers tied to CER updates, the Article 86 PSUR, and field safety corrective actions?
  7. If a clinician searched EUDAMED today for your device, would the language version they need be present — and would it say what the CER says?

Frequently Asked Questions

What does "EUDAMED SSCP public access" actually mean in practice? It means the validated Summary of Safety and Clinical Performance for an implantable or Class III device is uploaded to EUDAMED by the Notified Body after conformity assessment, linked to the device's Basic UDI-DI, and accessible to any member of the public who searches EUDAMED for that device. The public access is the mechanism MDR Article 32(2) refers to when it says the SSCP shall be made available to the public via EUDAMED.

Who uploads the SSCP to EUDAMED — the manufacturer or the Notified Body? The Notified Body. After validating the SSCP as part of the conformity assessment under MDR Article 52, the Notified Body uploads the validated document to EUDAMED. The manufacturer cannot push the SSCP directly into EUDAMED's public-facing modules. This is by design — the Notified Body's upload is the attestation that the document has been validated against Article 32 and MDCG 2019-9.

In what languages does the SSCP need to be available in EUDAMED? MDCG 2019-9 states that the SSCP must be available in the official Union language or languages accepted in the Member States where the device is placed on the market or put into service, plus a validated English version on top. All language versions must be validated by the Notified Body and uploaded to EUDAMED. Translating an SSCP is not a drop-in exercise and must be planned at the same time as distribution scope.

How does a clinician or patient actually find the SSCP in EUDAMED? Through the device's Basic UDI-DI or UDI-DI. The label or the instructions for use of the device must indicate where the summary is available, which in practice means a reference to EUDAMED and the identifier the reader uses to search. Once the reader has the identifier, they search the public-facing side of EUDAMED and the validated SSCP is attached to the device record.

Does Article 32 let a manufacturer satisfy the publication duty by posting the SSCP to their own website instead of EUDAMED? No. MDR Article 32(2) explicitly points at EUDAMED as the route for public availability. A manufacturer-hosted SSCP does not discharge the Article 32 obligation. The publication route runs through Notified Body validation and EUDAMED upload, and the label or IFU points readers to EUDAMED as the source of truth.

What happens if the EUDAMED module is not yet live or mandatory for a particular function? EUDAMED has been rolled out progressively. The MDR text, Article 34, and Commission Implementing Regulation (EU) 2021/2078 set the framework; the actual go-live of specific modules is governed by Commission notices. During any interim period the manufacturer's documentation and labelling obligations still apply, and the Notified Body validation of the SSCP still happens in the conformity assessment. The SSCP is uploaded to EUDAMED once the relevant module is mandatory. Check the current status of each EUDAMED module before finalising your labelling references.

Is the EUDAMED SSCP record updated when the SSCP is updated, or does it stay frozen at the first validated version? It is updated. The SSCP is a living document, revised in line with the clinical evaluation updates, the PSUR under MDR Article 86 for Class III and implantables, and any new safety information. Every updated version goes through Notified Body validation and a new EUDAMED upload. The public record reflects the current validated version at any point in time.

Sources

  1. Regulation (EU) 2017/745 of the European Parliament and of the Council of 5 April 2017 on medical devices, Article 32 (Summary of safety and clinical performance), Article 33 (European database on medical devices), Article 34 (Functional specifications of EUDAMED), Article 52 (Conformity assessment procedures). Official Journal L 117, 5.5.2017.
  2. MDCG 2019-9 — Summary of safety and clinical performance: A guide for manufacturers and notified bodies, August 2019 and subsequent revisions.
  3. Commission Implementing Regulation (EU) 2021/2078 of 26 November 2021 laying down rules for the application of Regulation (EU) 2017/745 as regards the European Database on Medical Devices (EUDAMED). Official Journal L 426, 29.11.2021.

This post is part of the EUDAMED, UDI & Registration series in the Subtract to Ship: MDR blog. Authored by Felix Lenhard and Tibor Zechmeister. EUDAMED is where Article 32 becomes real — the moment the SSCP is no longer a draft inside a technical file but a public record attached to the device for the life of the product.