An SSCP answers to the public, not the file

Most of a technical file is written for one reader: a notified body assessor who already knows how to weigh a benefit-risk table and doesn't need Annex I's requirements explained in plain language. MDR Article 32 asks for a different kind of document. A summary of safety and clinical performance — required for every implantable device and every Class III device other than custom-made or investigational ones — has to carry the same substantive conclusions the clinical evaluation already reached, but written so a reader with no regulatory background can follow them, then validated by the same notified body that assessed the file it's drawn from, then published where anyone can find it. Treating the SSCP as a shortened clinical evaluation report, trimmed for length rather than rebuilt for a different reader, produces a document that covers the required topics and still fails the test Article 32 actually sets.

The applicability list is narrow on purpose

Article 32(1) scopes the duty tightly: implantable devices, and Class III devices other than custom-made or investigational ones, have to carry an SSCP. No other device class in MDR 2017/745 owes an equivalent public-facing summary at all — the obligation attaches to the devices where the consequence of an unfamiliar reader misunderstanding the evidence is highest. MDCG 2019-9, the Commission's template guidance for the document, builds it around nine sections: device and manufacturer identification, intended purpose, indications and contraindications, a detailed device description, residual risks and precautions, a summary of the clinical evaluation and PMCF activity, required user training, and diagnostic or therapeutic alternatives. A patient-specific section isn't universal within that list — it's required specifically for implantable devices that come with a patient implant card and for Class III devices meant for direct patient use, tracking Article 32(2)'s own “where relevant” qualifier rather than applying to every SSCP by default.

It draws on the clinical evaluation report; it isn't a copy of it

The SSCP's clinical-evidence section has nowhere else to draw its conclusions from except the clinical evaluation report the plan already set out to produce — but the two documents aren't interchangeable drafts of the same content. The evaluation report is built for a reviewer who can follow a full evidentiary trace, GSPR by GSPR, source by source. The SSCP is built for a reader who needs the conclusions of that trace, not the trace itself: what the device is for, what residual risk remains once controls are applied, and what alternatives exist, stated at a level of detail Article 32(2) requires to be clear to the intended user. An SSCP assembled by lightly editing the evaluation report's own language keeps the wrong document's register; the summarizing has to happen at the level of ideas, not sentences.

Notified body validation is a second review, not a formality

The SSCP isn't a document a manufacturer drafts and publishes on its own authority. Its draft has to be part of the documentation submitted to the notified body under the conformity assessment procedure the device actually follows — Annex IX, or Annex X paired with Annex XI, depending on which route Article 52 lets the manufacturer elect — and the notified body has to validate it before it goes anywhere public. That validation step is a real checkpoint: a notified body reviewing an SSCP that overstates a benefit the underlying clinical evaluation doesn't actually support, or that omits a residual risk the risk management file still carries open, can withhold validation until the document matches the evidence it's supposed to summarize.

Publication makes staying current a standing duty

Once validated, the SSCP is made available to the public through EUDAMED, and the device's label or instructions for use has to tell a reader where to find it. That's a different kind of obligation than a document filed once and archived: Commission guidance on the SSCP directs manufacturers to revisit it whenever the PMCF and PSUR data behind it are next updated, not on a fixed independent calendar of its own. A manufacturer that updates the underlying PSUR or PMS file without checking whether the SSCP's own conclusions still match has left a public document stating a safety picture the manufacturer's own newer evidence has already moved past.

Where this meets the file

An SSCP outline that keeps MDCG 2019-9's nine sections in order, flags which ones the patient section actually reaches for a given device, and carries a revision trigger tied to the PMCF/PSUR cycle rather than a standalone renewal date, is previewed in the launch catalog. If your program drafts or updates this document on a different trigger, the shelf takes that correction directly.