Why your SSCP sounds like a technical manual, not patient safety

Written by HATEM RABEH, MD, MSc Ing

Your Clinical Evaluation Expert And Partner

in
S

The patient-facing Summary of Safety and Clinical Performance is one of the most misunderstood documents under MDR. Most manufacturers approach it like a simplified technical file. They strip out some jargon, shorten some paragraphs, and assume the job is done.

It is not.

What they miss is this: accuracy without accessibility is not communication. And under MDR Article 32 and MDCG 2019-9, the SSCP is not just a document. It is a public statement of safety and performance. That means the language you use must serve the reader, not your internal approval process.

But here is where it gets difficult. You cannot lose technical accuracy. You cannot simplify to the point of distortion. The information must remain correct, traceable, and defensible. You are writing for patients and healthcare professionals who do not speak regulatory language, but you are still accountable to reviewers who do.

This is the tension that breaks most SSCPs.

The Structure Trap: Writing Like a CER

The first mistake happens in the structure. Manufacturers take the CER outline, copy the headings, and try to make it shorter. The result is a document that follows the logic of clinical evaluation, not the logic of patient understanding.

The CER is organized by evidence. The SSCP must be organized by questions a patient would ask.

A patient does not think in terms of ‘clinical background and current knowledge.’ They think: What is this device? What does it do? Why would I need it? What could go wrong?

MDCG 2019-9 gives you the structure. Seven sections. Each one addresses a specific user concern. But most manufacturers treat these sections like regulatory checkboxes. They populate each field with rephrased CER content and assume the job is done.

This happens because the writer is still thinking like a regulatory professional. They are defending claims, not communicating benefit.

Technical Accuracy Without Technical Language

Now the question becomes: how do you write accurately without writing technically?

The answer is not simplification. The answer is translation.

Simplification removes detail. Translation preserves meaning while changing form.

Example. A manufacturer writes: ‘The device demonstrated non-inferiority to the predicate device with a lower bound of the 95% confidence interval exceeding the pre-specified delta of 10%.’

This is accurate. But a patient does not know what a confidence interval is. And they should not need to.

You translate: ‘In clinical studies, the device performed as well as the current standard treatment. The results were consistent and met the safety standards required by regulation.’

You removed the statistics. You kept the conclusion. The meaning is intact. The claim is still supported. But the sentence now serves the reader.

This is harder than it sounds. Because to translate well, you must understand both languages. You must know what the data actually shows, and you must know what the patient needs to understand.

Where Precision Gets Lost

But here is where manufacturers make the opposite mistake. In trying to write plainly, they lose precision.

I see this most often in Section 5, which covers residual risks and undesirable side effects.

A manufacturer writes: ‘Some patients may experience discomfort.’

This is vague. It tells the patient nothing. Discomfort from what? How often? How severe? Is this expected or is this a complication?

The technical version said: ‘In 12% of patients, transient local inflammation was observed at the implantation site, resolving within 7 days without intervention.’

You do not need to include the percentage in the SSCP. But you cannot strip out the specificity.

Better version: ‘Some patients may experience mild redness or swelling at the site where the device is placed. This usually goes away on its own within a week and does not require treatment.’

Now the patient knows what to expect. The statement is still accurate. It is still traceable to the clinical data. But it is written for comprehension, not documentation.

This distinction matters because the SSCP will be read by real patients making real decisions. If your language is too vague, they cannot assess risk. If your language is too technical, they cannot understand risk. Either way, the document fails its purpose.

The Traceability Problem

There is another tension here. Every claim in the SSCP must be traceable to the technical documentation. This is not optional. It is a regulatory requirement.

But the SSCP does not include references. It does not include citations. It is a standalone public document.

So how do you maintain traceability without embedding it in the text?

The answer is in your internal process, not in the document itself.

Every sentence in the SSCP should map back to a section in the CER or the risk management file. You do not show this mapping to the patient. But you must be able to show it to the Notified Body.

I recommend a traceability matrix. It sits behind the SSCP. For each statement, you note the source. When a reviewer challenges a claim, you do not argue. You point to the evidence.

This also protects you during updates. When clinical data changes, you know exactly which SSCP statements need revision. Without the matrix, you are guessing.

Writing for Two Audiences at Once

Here is what makes the SSCP uniquely difficult: you are writing for patients, but you are also writing for healthcare professionals.

MDCG 2019-9 is clear. The SSCP is intended for both groups. That means you cannot write only for lay readers. But you also cannot assume clinical knowledge.

This is a balancing act.

In Section 4 (Safety and Clinical Performance), you need to communicate outcomes that a clinician can evaluate, but in language that a patient can follow.

Example. A manufacturer writes: ‘The device achieved a 12-month Kaplan-Meier survival rate of 94.2% with no device-related mortality.’

A clinician understands this. A patient does not.

You translate: ‘In clinical studies followed for one year, the device worked as intended in over 94 out of 100 cases. No deaths were caused by the device.’

The clinician still gets the outcome. The patient gets the meaning. Both audiences are served.

But this only works if you understand both perspectives. If you only think like a regulator, you lose the patient. If you only think like a communicator, you lose the clinician.

The SSCP requires both.

What Reviewers Actually Check

When a Notified Body reviews your SSCP, they are not just checking for plain language. They are checking for alignment.

They compare the SSCP to the CER. They check that the conclusions match. They look for claims in the SSCP that are not supported in the technical file. They look for risks that are minimized or omitted.

If your SSCP says ‘rare side effects’ but your risk analysis shows a 15% incidence, that is a deficiency. Not because the language is wrong, but because the language misrepresents the data.

This is why you cannot write the SSCP in isolation. It is not a marketing document. It is a clinical summary written for non-experts. That means every sentence must reflect the evidence, even when the sentence does not cite the evidence.

You are translating, not reinterpreting.

And this is where most rewrites happen. A manufacturer assumes they are simplifying. But they are actually distorting. The Notified Body catches the distortion, and the SSCP goes back for revision.

Testing for Comprehension

There is one more step most manufacturers skip. Testing.

You write the SSCP. You review it internally. You submit it. And then you find out it does not work.

The only way to know if your SSCP is readable is to test it with non-experts.

This does not mean formal usability testing. It means giving the document to someone outside your regulatory team. A colleague in another department. A clinician who does not specialize in your device category. A family member.

Ask them: What does this device do? Who is it for? What are the main risks?

If they cannot answer, your SSCP is not clear.

This feedback loop catches problems before submission. It reveals sentences that seem clear to you but confuse the reader. It shows where you assumed knowledge that the audience does not have.

Most manufacturers skip this step because it feels informal. But clarity is not a regulatory checkbox. It is a functional requirement. And the only way to verify function is to test it.

What This Means for Your Process

Writing the SSCP is not a formatting exercise. It is a translation exercise. And translation requires both fluency in the source material and awareness of the target audience.

That means the person writing the SSCP must understand the clinical data. They must know what the CER says, what the risk analysis concludes, and what the clinical evidence supports. Without that knowledge, they cannot translate accurately.

But they must also write for clarity. And clarity comes from stepping outside the regulatory mindset. It comes from asking: what does the reader need to know? Not: what do I need to document?

This is why the SSCP often takes longer than expected. It is not just summarizing. It is rethinking the entire presentation of your clinical case for a completely different audience.

And that rethinking is where the value comes from.

Because when the SSCP is done well, it does more than satisfy a regulatory requirement. It builds trust. It shows that your organization understands not just the device, but the people who use it.

That is what technical accuracy without technical language means. It means serving the reader without compromising the evidence.

Next in the series, I will address how the SSCP and PSUR interact, and why inconsistencies between them create audit findings that are difficult to close.