Four words can give a device team dangerous relief: no clinical data necessary.

The mood in a team changes when it reaches that conclusion. Shoulders drop. The pressure seems to lift. For a moment, it feels as if one difficult part of the MDR has disappeared.

I understand that feeling.

And this is the part that still bothers me: the relief arrives too early.

Article 61(10) covers devices for which clinical investigations or clinical data are not deemed necessary. That can sound like an exemption. It is not. No clinical data does not mean no clinical evaluation.

It means the evaluation takes a different shape. You still do the work. You still write the report. You still justify every claim. The reasoning shifts from analysing clinical performance data to demonstrating, carefully, why such data is not required.

That distinction looks small on the page. Inside a technical file, it carries the whole argument. And the argument can be harder to defend than the analysis it replaces.

What the article really asks

Clinical investigations are not deemed necessary when the device is built on solutions sufficiently established in clinical practice, and its characteristics let you rely on existing data or non-clinical methods. Article 61(10) then wants the evaluation grounded in a sufficient justification that the relevant general safety and performance requirements are met, through non-clinical means: testing, bench work, pre-clinical evaluation.

Read that slowly with me.

The CER stays mandatory. What changes is the evidence base, not the duty.

Imagine the reviewer opening the file. There is no clinical investigation to carry the story. There may be no clinical performance dataset for the device itself to absorb the uncertainty. So the reviewer turns to the justification and asks whether every relevant requirement is truly covered by the evidence you chose instead.

That is where a sentence such as “established technology” stops being a conclusion and becomes a question.

Key insight: Article 61(10) defines when a clinical investigation is not required. It does not free you from the clinical evaluation. Teams who blur the two write “established technology, no clinical data required” and stop, exactly where the real work begins.

Why it is so easy to misread

Two reasons, and neither is carelessness.

First, some readings label these “devices without clinical data”. The label sounds definitive, so it quietly closes the discussion. But the device may have no investigation of its own while still needing to show that data is genuinely unnecessary given the requirements at stake.

The absence of data is therefore not the argument. The justification for that absence is.

Second, we treat established technology as automatic acceptance. A familiar core technology feels safe because everyone in the room recognizes it. Yet that familiarity can hide the questions that belong to this device.

Decades of use for a core technology do not validate your specific version, your specific coating, your specific change of size or intended use.

This is where the surprise usually comes later. The team thought the route reduced the burden. Then the deficiency arrives and asks the question the file never answered: why are the available non-clinical methods sufficient for these particular claims and risks?

The Team-NB position paper on Article 61(10), and the notified bodies’ own shared experience, both narrow this door further than manufacturers expect. The route is legitimate. It is not a hiding place for a device that should have generated data.

So the real test is not whether you can enter this route. It is whether you can stand at the end of it and defend every step.

What a file I would feel proud to defend contains

The justification carries everything, so it has to be explicit.

Start with the relevant requirements. Which ones need clinical support? For each one, show how it is met without clinical performance data. Do not make the reviewer build that bridge for you.

Then move to the design solutions. Explain why they are truly established, with evidence, not assertion. Connect that evidence to your specific device, including the features that could change the safety or performance story.

Next, test the non-clinical methods against your actual claims and risks. A bench result may be sound, but the file still has to explain why that result answers the clinical question behind the claim.

And where clinical data does exist for the device type, it is still appraised, because 61(10) never licenses ignoring what is out there.

These are separate steps, but they must read as one chain. The requirement leads to the question. The question leads to the method. The method leads to the evidence. The evidence leads to the conclusion.

When one link is missing, the reviewer feels it immediately.

The reviewer reads a 61(10) file more closely, not less, because the whole safety and performance story rests on the strength of a justification instead of on outcome data. A thin justification is not a lighter file. It is a weaker one, and it will come back.

That return costs more than another review round. It can stall the certificate, consume runway, and leave one person in the building carrying a deadline that few others fully understand. I have seen how lonely that responsibility can feel.

But there is another feeling available too: the steadiness of opening a clean, connected justification and knowing the reasoning can stand on its own.

You can move toward that feeling this week.

Write the justification first and read it like a friendly adversary. Take one relevant requirement at a time and ask, “why is clinical data genuinely not needed here?” Then point to the exact non-clinical evidence that answers the question for your specific device.

If any answer is only “because the technology is established”, stop there. Add the missing connection before the reviewer finds it. That single pass may expose the weakest link while you still have time to strengthen it.

If your 61(10) argument feels harder to write than expected, that difficulty may be telling you exactly where the file needs more honesty and more care.

Next Wednesday: clinical claims versus marketing claims, and the tender seam where a sound CER can break under a sentence the clinical team never wrote. Sometimes the sentence that creates the problem is nowhere in the CER.

✌️ Peace,

Hatem

Your Clinical Evaluation Expert & Partner

The deficiency email lands. A PDF is attached. You open it and scan the comments, and the afternoon rearranges itself around what you find. The reviewer is questioning the literature search, even though your team spent weeks finding and assessing the evidence.

That moment hurts because the work was done.

But the reviewer cannot see enough of the path to trust where it led.

There is a small, quiet test behind that comment, and many searches that fail it never knew the test was there. That has always felt unfair to me. So let me hand you the test openly, today, before it costs you a deficiency round or delays the file waiting behind it.

Here it is: could the reviewer reproduce your search from what you wrote down, and land on the same set of studies?

BSI says it plainly. The search protocol should be comprehensive enough to minimise selection bias, and in principle the assessor should be able to replicate your searches from what is presented in the CER. A search that cannot be reproduced is not a method. It is a bibliography with a story attached.

What “reproducible” really asks of you

Reproducibility is not a tone or a feeling. It is a trail of recorded facts.

The trail begins with named databases and the date each was searched. PubMed, Embase, Cochrane, the registries, each with its date. Searches age. An undated search cannot be trusted as current, because nobody can tell when its view of the evidence stopped.

Then come the exact search strings. Include the full query for each database, with the Boolean logic and the field tags, not a polished paraphrase written later. The reviewer needs to see what the database actually received. If the reviewer cannot paste your string and see your count, the string was not really documented.

That count leads naturally to the next part: inclusion and exclusion criteria, applied where the reviewer can see them.

State the criteria up front. Then show the counts at each stage: identified, screened, excluded with reasons, included. A PRISMA-style flow is the shape they expect. It lets a reviewer follow the evidence from the first results to the studies that finally support the evaluation.

But the flow alone is not enough. The direction of the evidence matters too.

Favourable and unfavourable results both need to be carried through. The MDR asks for objectivity, and the number a reviewer checks first is how many excluded studies had unfavourable findings, and on what stated ground.

The test: A reproducible search tells the reviewer, “This file does not curate.” An unreproducible one leaves them wondering whether it does.

The patterns that read as bias, though you never meant them to

Most teams do not set out to create bias. They are trying to finish demanding work under a deadline. Yet three familiar patterns can still make an honest search look shaped.

The first begins before the search starts. The team already knows the conclusion it expects, and the protocol slowly bends toward it. The criteria appear reasonable one by one, but together they exclude the inconvenient studies.

The second pattern begins with efficiency. Several searches are collapsed into one undocumented effort. BSI notes that searches serve different purposes and may need to be separate and separately justified. Without that separation, a reviewer sees one blurred method where the team saw several clear questions.

The third appears during resubmission. Someone responsibly updates the search, but the search date is not updated. Now the evidence and the documented method disagree. The file quietly claims a currency it no longer has.

None of these are data problems. They are documentation problems.

And they wound more deeply than a weak study does. A weak study is a known limitation that can be appraised and discussed. An unreproducible search hangs a question mark over everything after it.

I know how lonely that can feel for the person holding the CER. You may be the only person in the building who understands what the reviewer is really asking.

Every serious team hits this wall at least once.

The gentle discipline

Write the protocol before you search.

Record databases, dates, strings, and criteria as you go, not from memory afterward. Keep the excluded set with its reasons. Rerun and re-date before any resubmission.

Then give the package to a colleague who did not perform the search. Ask them to rerun one database using only what is written in the CER. Let the document speak.

If they cannot reproduce the query and follow the counts, you have found the gap before the reviewer does. That is one concrete move you can make this week.

The reward is more than a clean review. It is knowing another professional can trace your reasoning without guessing. It is also a search you can rerun next year as the literature moves under you, which is the maintenance your file needs anyway.

Thank you for carrying this careful work, especially on the days when nobody else sees how much care it takes.

Next Wednesday, September opens on the craft of appraisal and reporting. We begin with a small article that confuses almost everyone: Article 61(10). The phrase “no clinical data” sounds like permission to stop. It is not. We will look at why it never means “no clinical work”.

If any of this feels heavy tonight, bring it to the Friday community call, 16:00 CET, and we will untangle it together: Link

✌️ Peace,

Hatem

Your Clinical Evaluation Expert & Partner

One overlooked material difference can bring an entire equivalence claim down.

The hard part is that many teams discover it only after they have invested months of work.

Yesterday was special. A notified body reviewer sat with us, live, and answered your questions with a candour you rarely get to hear. Equivalence came up, as it always does. You could feel why. This is a route many teams want to rely on, yet it is often built on an assumption nobody tested early enough.

If you could not make it, reply to this newslettertter and I will send you the link. Please watch it. It is worth your evening.

Then come back to this issue as if we were sitting across the table with coffee between us. Because I want to talk about the part of equivalence that looks small in a table, but can stop the whole argument.

MDCG 2020-5 asks for equivalence across three characteristics: technical, biological, and clinical. All three. Against the same device.

I have watched the same story unfold more than once. A team builds a careful technical comparison. The intended purpose appears to support the clinical discussion. The table fills up. Confidence grows.

Then someone finally asks the uncomfortable question about the material in contact with the body.

The room changes.

That question reaches the biological pillar, the one too many teams treated as a formality. And that is where an equivalence claim that looked solid can quietly die.

The technical pillar

Similar design. Similar conditions of use. Similar specifications and properties: energy, tensile strength, viscosity, surface, wavelength, software algorithms, deployment, principles of operation, critical performance.

This is usually your strongest ground because it maps to engineering you already document well. The drawings, specifications, and performance records give the team something concrete to compare. That familiarity creates momentum.

But momentum can create a blind spot. A strong technical pillar feels reassuring, and that reassurance can spill into places where it does not belong.

The biological pillar, the one that hurts

The device must use the same materials or substances, in contact with the same tissues or fluids, for a similar kind and duration of contact, with similar release characteristics, degradation products and leachables included.

Read that once more before you move on.

This is stricter than “comparable biocompatibility”. A different alloy, a different coating, a slightly different polymer grade, and biological equivalence is simply not established, no matter how close the technical picture looks.

This is the moment I wish teams would reach in week one. Instead, it can arrive after the strategy has been accepted internally and the writing is well underway. Someone opens a specification. Someone else checks the equivalent device. The difference is finally visible, and a stomach drops.

The pain is not limited to rewriting a table. The evidence strategy itself may no longer stand.

For an implant, the material touching tissue is not a detail to argue around. It is a pillar you either meet or you do not.

Equivalence fails as a whole if any single pillar fails. A beautiful technical and clinical case does not survive a broken biological one.

That is why I would rather disappoint a project team early than comfort them with a claim that will fail later. Early truth gives you choices. Late truth arrives with a deficiency, a deadline, and the lonely feeling that you are the only person in the building who understands what is now at risk.

The clinical pillar

Same clinical condition or purpose. Similar severity and stage. Same body site. Similar population by age, anatomy, physiology. Same kind of user. Similar critical performance for the intended effect.

Intended purpose alone will not carry this pillar. It may open the conversation, but it cannot finish it. The reviewer checks the population and the real conditions of use, not the marketing line.

This is where broad statements begin to crack. Two devices may sound alike in a short description while differing in the people who receive them, the setting in which they are used, or the performance needed to achieve the intended effect. The table has to make that comparison visible.

What they will not accept, and I say this to protect you

Single-word conclusions in the equivalence table invite immediate scrutiny. “Same” is not an analysis. “Similar” is not an explanation. A reviewer needs to see how you reached the conclusion and whether the evidence beneath it can carry the weight.

Each difference needs a clear analysis, with the supporting articles included in your submission and referenced in the discussion. MDCG 2020-5 even gives you a template for exactly this. Use it. It signals a claim under control.

That disciplined comparison also protects you from another costly mistake.

Data from similar devices can inform the state of the art, but it cannot stand as evidence of your own device’s safety and performance. Only a demonstrated equivalent’s data can. Similar devices set the bar. An equivalent device, argued honestly across all three pillars, is the only one whose data clears it for you.

Those categories can look close on a slide. In a clinical evaluation, they do different jobs. Blurring them may make the evidence story feel easier today, but it leaves the reviewer to expose the gap tomorrow.

So here is the one move I want you to make this week.

Open your equivalence table. Go directly to the biological pillar. Check the actual materials or substances, tissue or fluid contact, kind and duration of contact, release characteristics, degradation products and leachables. Do this before polishing another technical paragraph.

Then ask whether every conclusion is supported and whether the data-access contract is truly reachable. If the answer is uncertain, name that uncertainty now. Do not let a hopeful assumption quietly become the foundation of the file.

Almost every equivalence claim that reaches me in trouble was technically sound and biologically indefensible, found in month four instead of week one. This one still bothers me because the pain is avoidable.

If equivalence is your road, stress-test the biological pillar first. I would rather you find the weakness now, with me, than there, with a deadline. And when the three pillars truly hold, you get to answer reviewer questions from solid ground, knowing the claim can survive the question you were once afraid to ask.

Next Wednesday, we follow the evidence into the literature search. One quality decides whether a reviewer can trust it: can another person reproduce what you did? I will show you where that trust is won, and where it disappears.

Missed the reviewer session? Reply “replay” and I will send it straight to you.

✌️ Peace,

Hatem

Your Clinical Evaluation Expert & Partner

One early decision can quietly determine whether your clinical evaluation moves forward or stalls at the review gate.

It is the decision about which route will generate your clinical evidence.

Of all the decisions in a clinical evaluation, this is the one I most wish teams would sit with me over, early, before anything is spent. A virtual coffee. The right people around the table. One honest question about what the evidence can truly support.

Because the choice rarely feels dangerous at first.

A slide appears in a meeting. One route looks faster. Another looks cheaper. Everyone wants to protect the budget and the timeline, so the attractive answer gathers momentum. Then, months later, a missing condition surfaces. The email lands. A reviewer has asked the question nobody prepared to answer, and somewhere in the building a stomach drops.

It happens more often than anyone admits.

The cheapest route on the first slide can become the most expensive route later. The cost is more than money. It is the pressure on the quality engineer carrying the deadline, the clinical colleague trying to repair the reasoning, and the team wondering whether the certificate will now stall.

So let us slow down at the point where slowing down still helps. There are three evidence routes. Each can be valid. Each asks you to make a different promise.

Route one: generate your own clinical evidence

The first promise is simple to state: we will generate data on our own device.

You do that through a clinical investigation under Article 62 and ISO 14155. For implantable and Class III devices, Article 61(4) makes this the default: investigations shall be performed unless you can duly justify relying on existing data alone. That justification bar is high, and reviewers hold it there.

This route gives you the strongest evidence because the evidence belongs directly to the device you are asking the reviewer to accept. It also carries the greatest weight in time and money.

That weight can make a team hesitate. I understand why. A clinical investigation touches budgets, schedules, sites, patients, and many people who already have full days. Yet for a genuinely novel device, it is often the only honest road.

Trying to avoid that truth does not remove the burden. It moves the burden to review day, when your options are narrower and the pressure is higher.

That is why some teams look toward the second route.

Route two: prove equivalence

The second promise sounds lighter: another device already has the data, and ours is equivalent to it.

This route lets you lean on an existing device’s data by proving equivalence. From a distance, it looks like a shortcut. Up close, it behaves like a demanding promise. MDCG 2020-5 asks for equivalence across three characteristics, technical, biological, and clinical, all of them, usually to a single device.

I have seen equivalence tables that felt reassuring in the meeting and fragile the moment someone read them as a reviewer. A row says “same.” Another says “similar.” The table looks complete, but the reasoning is still missing.

Single-word entries in the equivalence table, “same”, “similar”, are not accepted; every difference needs a reasoned analysis, with the evidence attached. The reviewer is not asking whether the devices look close enough. The reviewer is asking whether every relevant similarity and difference has been examined, supported, and connected to clinical safety and performance.

Then comes the condition that catches good teams late.

For implantable and Class III devices, Article 61(5) asks for a contract giving you ongoing access to the other manufacturer’s technical documentation. That other manufacturer is usually your competitor. A strategy can look elegant on paper and still fail because the access it depends on was never realistic.

Please test that reality before your timeline, budget, and colleagues begin leaning on it.

Key insight: equivalence is not a way to have less evidence. It is a way to borrow someone else’s, and the MDR makes that loan expensive and conditional.

If those conditions cannot be met, the third route may appear more natural. But it also needs discipline.

Route three: build from literature and post-market data

The third promise is this: the clinical history already exists, and we can identify it, appraise it, and show why it applies.

For lower-risk devices, and those with a well-established clinical history, conformity can rest on a systematic literature review plus post-market data, fully reasoned. MDCG 2020-6 frames what counts as sufficient clinical evidence for legacy devices, and it is the document to read before you assume this door is open.

The word “systematic” matters here. This is not a folder of favourable papers collected over the years. It is a traceable search, a fair appraisal, and a clear account of what the total evidence says about the device and its purpose.

That brings us to the rule that connects all three routes.

The evaluation must weigh both favourable and unfavourable data. A search that finds only good news reads like a search built to find good news. What began as a small question about missing data can then become a much larger question about trust.

And trust, once weakened, is hard to restore inside a review cycle.

Choose the route before it chooses your timeline

Start with three honest questions.

Is it implantable or Class III? Then plan for an investigation unless your Article 61(4) justification is genuinely solid.

Does a truly equivalent device exist, and can you really get data access under 61(5)? If either answer wobbles, equivalence is a trap wearing a shortcut’s clothes.

Is there enough published experience with your exact technology and purpose? If yes, literature plus a serious PMCF plan may carry you.

This week, bring the clinical, regulatory, and quality owners together for thirty minutes. Write your chosen route in one sentence, followed by the reason and the condition that could make it fail. Then ask each person to challenge that condition with the eyes of a reviewer.

If you cannot write the reason, or nobody can defend the weakest condition, you have found the conversation to have now, before another euro is spent.

There is real relief in making this choice early. And later, when a reviewer question arrives, you get to open it already knowing the answer was built into the strategy from the beginning. That feeling comes from honest preparation, and you do not have to carry it alone.

Next Wednesday, we will bring equivalence up close. We will examine the quiet pillar, the biological one, that sinks more claims than the technical one ever does. If your table currently says “same material,” this is the issue you will want beside it.

And come meet the reviewer on 18 August, 16:00 CET, live: visit my linkedin to get the registration link.

✌️ Peace,

Hatem

Your Clinical Evaluation Expert & Partner

Or question every conclusion that follows.

I once sat in the room when it happened. A reviewer reaches the acceptance criteria, pauses, and asks a simple question: “Where did this number come from?” The room becomes quiet. The clinical writer looks toward quality. Quality looks toward regulatory. Everyone knows the target is reasonable, but nobody can show the path that produced it.

That silence is painful because the team has worked hard. Yet hard work cannot repair a threshold chosen after the results were already visible.

I say this often, kindly but firmly, when I review a file: an acceptance criterion set after you have seen your results is not really an acceptance criterion. It is a description of what happened, dressed up as a target. Reviewers can feel the difference from across the room.

I understand the temptation. Leaving the numbers loose can feel safer while the evidence is still taking shape. In reality, it transfers the uncertainty to the end, where it can become a deficiency round, a delayed decision, or a stalled certificate.

There is a better place to begin. The state of the art is where your criteria are meant to come from. When you establish that foundation early, the whole evaluation gains a spine. When you do not, every conclusion downstream floats with nothing under it.

So let us slow down and build that spine together.

The three questions behind every threshold

When a notified body looks at your performance and safety objectives, three quiet questions sit behind the review. BSI’s guidance says them almost word for word.

First: what is current best practice for the condition you treat?

Notice where the question begins. It does not begin with your device. It begins with the condition and with what happens to these patients under the options available to them today. That wider view creates the clinical context for the next question.

Second: what are the alternatives, and are there benchmark devices?

If benchmark devices exist, their reported performance and safety have to be taken into account when you set your own objectives. The comparison is therefore more than a table assembled near the end. It is an input to the target you set near the beginning.

That leads naturally to the third question: does your device meet or beat them?

The expectation, in BSI’s own words, is that your performance objectives should at least equal the reported performance of benchmark devices, or meet the relevant standards, for your device to be considered state of the art.

The reasoning path is honest and clear. Establish the SOTA through a documented review. Pull the reported numbers from the similar-device pool. Then set your criteria from those numbers, in the CEP, before you touch your own results.

A real objective looks like BSI’s example: for a device monitoring a physiological parameter, percentage of time in range (70 to 180 mg/dL) greater than x per cent.

A metric. A threshold. A source.

Each part answers the question that would otherwise hang over the review.

Write this down: your acceptance criteria are a snapshot of a moving benchmark. They only hold up if every threshold traces to a named source, and they are only current if that source still is.

Where careful teams stumble

The first pattern is a criterion with no traceable source.

The threshold may have come from long experience, several discussions, and sound clinical judgment. But when no line connects it to a publication, a standard, or the pool, the reviewer sees an unsupported number. It reads as invented, even when it was not.

Worse, if that number mirrors the device results too neatly, doubt spreads. A plan written before the analysis cannot honestly hold a threshold reverse-engineered from the results. Once the chronology feels uncertain, the reviewer may start testing every nearby conclusion more closely.

The second pattern looks smaller, but it creates the same kind of doubt: unlabelled central values.

Imagine the table in front of the reviewer. It says Min, Max, and Median, but it does not say what those values describe. Are they patient-level observations? Raw pooled figures? Per-study summaries?

If your Min, Max, and Median are of the per-study mean values, say so. Left unlabelled, they read as raw pooled figures and get rejected. A plain range with a clear central value is kinder to the reviewer, kinder to your colleagues, and kinder to future you when the file returns for update.

Here is one move you can make this week. Open your acceptance-criteria table and add a source column. For every threshold, write the exact publication, standard, or similar-device dataset that supports it. Then check that the source predates the analysis of your own results and that the label explains exactly what each summary value represents.

Any empty cell has now shown you where the real work is.

When the literature leaves a gap

Sometimes that empty cell remains because an endpoint simply has no benchmark in the literature.

This is the moment when a regulatory professional can feel very alone. You understand the deadline. You know the endpoint matters. And you know that quietly placing a convenient value in the table would make the document look complete.

Please resist that pressure.

The brave, professional move is to say the gap out loud and explain how you set the target instead. Real or absent. A value either traces to a source or is named as a gap that post-market follow-up will close. Never quietly filled.

A reviewer respects a declared gap because it shows that the evaluation can distinguish evidence from assumption. That honesty creates a plan. Silence creates exposure.

What ends a renewal is a comparison where the device column sits empty on the endpoints that matter most. Finding that absence yourself may feel uncomfortable. Finding it in a deficiency letter brings the urgent meetings and the lonely question of how much time has already been lost.

Preventing that moment is unglamorous work, and it is worth more than it will ever get credit for. One clear source trail, one honest gap, and one prospective criterion at a time.

Next Wednesday: the three evidence routes under Article 61. We will look at how the choice made in month one can shape the cost of the whole journey, long before the consequences appear in the CER.

One warm invitation before you go. On 18 August at 16:00 CET I am hosting a notified body clinical reviewer, live, so you can hear it straight from them: what they read first, where files fall down, what sufficient clinical evidence really means.

Come and bring your hardest question.

To get the registration link, visit my LinkedIn profile

✌️ Peace,

Hatem

Your Clinical Evaluation Expert & Partner

One favourable-balance sentence can still leave your CE mark waiting at the gate.

I have watched this happen too many times, and it always stings.

A team has worked hard. Really hard. Their benefit-risk section runs for pages. The benefits are listed. The risks are listed. You can see the effort in every table and every carefully chosen word.

Then the assessment comes back.

There is a finding attached. Someone reads the same paragraph again. Someone else wonders what they missed. And the person carrying the deadline understands, before anyone says it, that the team now answers on the reviewer’s clock.

The painful part is that the problem is almost never a lack of data.

It is a lack of visible reasoning.

I wish someone had told the team that earlier, gently, before the letter arrived. So let us sit with it now, as colleagues, over whatever is left in your cup, and look at what the reviewer is trying to find.

What the MDR is actually asking of you

MDR Annex XIV Section 1 asks the clinical evaluation to establish a favourable benefit-risk profile. Article 61(1) asks for an acceptable ratio under normal conditions of use.

The words are short. The work behind them is not.

They hide a trap that catches capable, careful people. We confuse documenting with demonstrating. We list the benefits. We list the risks. We place them side by side, add a polished conclusion, and feel that the job is done.

But the reviewer cannot accept a conclusion by assertion. They need to see how you arrived there. On what evidence. Against which criteria. Having weighed which alternatives.

That journey begins before they reach your conclusion.

Where they look before your conclusion

First, they check whether your analysis is standing on the right ground.

Does it match the population and use in your IFU?

Imagine a reviewer moving between two documents. The IFU describes moderate to severe disease. The benefit evidence describes mild cases. Each document may look reasonable alone, but together they tell different stories. The analysis is off before it begins.

The same fracture appears when the device is for trained specialists but the data comes from tightly supervised trials. The evidence may be real, yet the real-world picture is not the one you drew. Once the ground shifts, every conclusion resting on it becomes harder to defend.

Then the reviewer asks whether the claimed benefits matter to a patient.

Are the benefits clinically meaningful, and not merely statistically significant? A thirty-second time saving can reach significance and still change nothing for the patient. Reviewers separate a significant number from a meaningful one, and they expect you to have made that distinction first.

Once the benefit is clear, attention turns to the other side of the scale.

Are the risks complete and current?

This is where the reasoning often cracks. A team copies the risks from the risk management file and stops. Yet the clinical data has raised another concern. A post-market signal has changed the picture. Those sources remain elsewhere in the file, never brought into the reasoning where they belong.

Your benefit-risk has to breathe with the risk management file (ISO 14971) and the state of the art. It cannot run in a separate lane. If one source changes, the analysis must feel that change too.

The rule: a benefit-risk analysis is not a comparison table. It is a piece of honest reasoning, transparent and clinically defensible at every step.

The alternatives you left unspoken

Even a complete account of your device is still incomplete if it stands alone.

Annex XIV asks you to weigh the ratio against the current state of the art, which means against the treatments the patient could otherwise receive.

Picture the patient at the centre of the decision. They are rarely choosing between your device and nothing. There may be another treatment, another device, a different procedure, or established clinical management. Those alternatives shape what counts as an acceptable benefit and what risk can reasonably be carried.

An analysis that judges your device alone answers a question nobody asked. Leave out the alternatives and you have left out the other half of the scale.

That is why a strong analysis feels less like a declaration and more like a guided path.

What I want for your file

I want the reviewer to be able to follow you. That is the whole secret.

State the population and intended use clearly. Tie each benefit to a clinically meaningful outcome and show the evidence supporting it. Bring in the full, current risk picture from every source. Weigh that picture against the alternatives in the current state of the art. Then let the conclusion emerge from the reasoning above it, so another person can trace the same path without guessing.

Here is one concrete move you can make this week.

Open your benefit-risk conclusion and challenge every sentence with one question: “Where did I show that?”

If the answer lives in another document, connect it. If the population does not match, address it. If a benefit is statistically significant but its clinical meaning is unclear, explain that meaning. If a risk appears in clinical or post-market data but disappears from the final balance, bring it back. If the alternatives are silent, put the patient’s real options on the page.

Read the path once more as if the file belonged to someone else. Could you reach the same conclusion from the evidence provided? Or do you need inside knowledge that the reviewer does not have?

That final question can be uncomfortable. It can also save a deficiency round.

When reviewers can follow you, they can agree with you. When they meet a favourable-balance sentence with no path to it, they will ask you to build that path on their clock, not yours.

And when the reasoning is clear, there is a quieter feeling on the other side. The relief of a review that does not stall here. The pride of knowing that the file says what the team truly knows. The comfort of knowing the patient has remained at the centre of the decision.

This work is demanding because the decision matters, and plenty of careful teams have stood exactly where you stand.

Next Wednesday, we will go one step earlier: acceptance criteria and the state of the art. I will show you how a reviewer reasons about the numbers you set before you ever collect a single data point, and why that early choice can decide how the whole story ends.

Reply anytime, truly. Tell me where your benefit-risk reasoning feels hardest to defend. The weekly community call is Fridays at 16:00 CET: link

✌️ Peace,

Hatem Clinical Evaluation Expert for Medical Devices

It has been a while.

The last letter you received from me was on the first of April.

Every Wednesday since then, I knew another week had passed without writing to you. And every Wednesday, I told myself, “Next week.”

I could give you reasons. Client projects. Travel. Life moving faster than expected.

But you did not subscribe for my excuses.

You subscribed because, every week, you expected to learn something that would make your next clinical evaluation a little clearer, a little stronger, or a little easier.

I owe you that.

So today is not simply another newsletter.

It is a promise.

From today until the end of this year, you will receive one letter every Wednesday at 16:00 CET.

Hold me accountable. If one Wednesday passes without hearing from me, send me a short reply asking, “Where is this week’s letter?” I will deserve it.

These past months reminded me of something I think every regulatory professional understands.

The urgent always speaks first.

The next submission. The next meeting. The next deficiency. The next deadline.

The important rarely raises its voice.

Improving your literature search. Reading one guidance document properly. Questioning a conclusion before someone else does. Making time to think instead of only reacting.

Those things wait quietly.

So does writing a letter to someone who trusted you enough to invite you into their inbox.

The strange thing is that our careers are rarely shaped by the loud moments.

They are shaped by the quiet decisions we make long before anyone notices them.

Before we begin, I’d love to hear from you.

What has changed since April?

Maybe you changed jobs.

Maybe your device received CE marking.

Maybe you survived a difficult review.

Maybe you are still waiting for that one answer from your notified body.

Whatever your story is, hit Reply and tell me in one sentence.

I read every reply myself.

Many of the ideas that end up in these letters begin with conversations like those.

Now, enough about the silence.

Let’s get back to the work that brought us together.

Grab a coffee. For the next few minutes, I’d like you to borrow someone else’s eyes. The eyes of the person who decides whether months of your work move forward or come back with a deficiency letter.

Because here is a quiet truth that changes everything. Your clinical evaluation report is not read the way you write it. You build it front to back, scope to conclusion. A notified body reviewer does not read it that way at all. And the gap between how you assemble the file and how they interrogate it is where so much heartbreak, and so many first-round deficiencies, come from.

Once you see the file through their eyes, that gap becomes easier to close.

Who is actually reading you

First, picture the person. Under MDR Annex VII Section 3.2.4, a notified body must have permanent access to personnel with the clinical expertise to assess your data. In practice that is a clinician, often still seeing patients, reading your file against a defined framework. The person assessing your cardiovascular file may have treated that exact indication the same week they open your report.

So write for that human being. Clinically fluent. Short on time. Trained on hundreds of files before yours.

Their first question is whether the file can be trusted.

The order they really read in

They do not start at page one. From the deficiency letters I answer and the review meetings I sit in, the path looks more like this.

The intended purpose first. Everything downstream is checked against it.

The reviewer sees one wording in the IFU. Then they open the CEP and see a small shift. By the time they reach the CER, the population, indication, or clinical context feels different again.

Each difference may look harmless alone. Together, they create a question the reviewer cannot ignore: which version governs the evaluation?

Every later check inherits the confusion, and the reviewer quietly starts to wonder whether the file was ever in control.

Then the conclusion and the conformity tables. They jump to what you claim and whether your own summary backs it up. This is where files break your heart, because they contradict themselves. I have seen an endpoint marked passed in the table and still called pending in the conclusion of the same report. The reviewer does not guess which one you meant. They write to you, formally, with a deadline.

Then the email lands. A PDF is attached. Somewhere in the building, the one person who understands what that deadline means feels their stomach drop.

Key insight: the fastest way to earn a deficiency is to disagree with yourself. Internal coherence is not polish. It is the first thing a careful reviewer tests.

Then your claims against your evidence. Every clinical claim, in the IFU and even in your marketing, must be supported by data in the file. BSI’s guidance suggests tabulating each claim with a direct reference to its evidence. Reviewers notice that table. They notice its absence more.

Then the literature search. Can they reproduce it from what you wrote? Databases, dates, strings, the in and out decisions. Ten minutes for them, and it colours how much they trust everything else.

The reviewer moves from intended purpose to conclusion, from conclusion to claims, and from claims to the method that found the evidence. At every step, one answer prepares the next question.

What I want you to take from this

None of this asks for more data. It asks your file to agree with itself, every number and every verdict identical everywhere it appears, and every claim traceable home.

So before your next submission, spend one quiet hour reading your own file the way they will.

Place the intended purpose in the IFU, the CEP, and the CER beside one another. Compare the wording. Then read the conclusion against every conformity table. Finally, take each clinical claim and follow it back to its evidence.

Do not read for style. Read for the exact moment a reviewer might pause.

Where you feel friction, so will they. Better you meet it first, at your desk, with time, than in a deficiency letter with the clock already running.

And when everything aligns, there is a quiet pride in that too. Your file stops feeling like a stack of documents and starts reading like one coherent clinical argument.

Next Wednesday: benefit-risk, and why a thorough, careful analysis can still fail review, because it documented instead of demonstrated.

Thank you for being here, and for opening this again after my long silence. Reply anytime; I read every one. And if you would rather talk it through out loud, the community call runs every Friday at 16:00 CET: Link (The community itself is here).

✌️ Peace,

Hatem

Your Clinical Evaluation Expert & Partner

Welcome to the final episode of PMCF Mastery. Your PMCF plan is not a static document. It evolves as your device changes, evidence accumulates, and regulatory expectations shift.

Today we cover lifecycle management: when to update, how to handle changes, and how to work effectively with Notified Bodies.

Why PMCF plans change

PMCF plans need updates when:

• CER identifies new gaps during updates

• PMCF activities complete (need new activities)

• Results suggest new questions

• Device modifications occur

• SOTA evolves

• Safety signals emerge

• Regulatory requirements change

Static plans fail. Living plans succeed.

Triggers for PMCF plan revision

Completion triggers

Activity completed → Results analyzed → Gaps reassessed → Plan updated

Example: Registry enrollment target met. Five-year follow-up complete. Plan now needs new activity or justification for reduced monitoring.

Evidence triggers

New clinical data → CER update → New gaps identified → Plan expanded

Example: Post-market study reveals higher complication rate in diabetic patients. PMCF plan now needs targeted monitoring for this subgroup.

Device triggers

Device modification → Clinical impact assessment → PMCF relevance check → Plan revision if needed

Example: Software update changes algorithm. Previous validation may not cover new version. PMCF plan needs validation activity.

External triggers

SOTA change → CER benchmark update → PMCF objective relevance check → Plan alignment

Example: New competitor device achieves superior performance. SOTA benchmark shifts. PMCF objectives may need revision.

Substantial vs non-substantial changes

BSI guidance distinguishes:

Substantial changes (notify before implementation)

• Need for PMCF has changed

• Removal of planned activities

• Delays or protocol deviations

• Reduced sample sizes

• Changed objectives or endpoints

• Activities insufficient for objectives

Non-substantial changes (document for future audit)

• Administrative updates

• General method changes (literature screening)

• Additional supplemental activities

• Marketing-driven additions

When in doubt, notify your Notified Body.

Change notification process

For substantial changes under BSI (Annex IX Chapter II):

1. Complete notification form (MDF4900)

2. Provide supporting documentation

3. Submit to scheme manager via bsirsnotifications@bsigroup.com

4. Wait for assessment before implementing

5. Document approval in your files

Do not implement substantial changes without NB approval.

Version control requirements

Maintain version control:

• Version number: Sequential (1.0, 1.1, 2.0, etc.)

• Date: Clear revision date

• Change history: What changed and why

• Author: Who made the revision

• Approval: Sign-off before implementation

• CER link: Which CER version this supports

Traceability matters. Know which PMCF plan version was active at any point in time.

Annual review process

Even without triggers, conduct annual review:

Review checklist

• Are all activities on track?

• Are timelines being met?

• Do objectives remain relevant?

• Has SOTA changed?

• Have new gaps emerged?

• Are resources adequate?

• Is the plan still appropriate?

Document the review even if no changes needed.

Coordinating with CER updates

PMCF and CER update cycles should align:

CER Update → Identifies gaps → PMCF Plan Revision
                ↑                       ↓
                ← PMCF Report ← PMCF Activities

Maintain this cycle:

1. CER update identifies or confirms gaps

2. PMCF plan addresses gaps

3. PMCF activities generate data

4. PMCF report analyzes data

5. CER update incorporates findings

6. Cycle repeats

Break the cycle and documentation drifts apart.

Surveillance audits

Notified Bodies check PMCF during surveillance:

Expect questions like:

• What is current PMCF plan status?

• Show progress against planned activities

• Where are the PMCF reports?

• How have findings affected CER?

• Any deviations from plan?

Be prepared with:

• Current PMCF plan (correct version)

• Progress tracking documentation

• PMCF reports (all completed)

• Evidence of CER updates

• Deviation justifications if any

Handling plan deviations

Deviations happen. How you handle them matters:

Acceptable deviations

• Documented prospectively when possible

• Justified with scientific rationale

• Impact assessed

• Mitigation described

• NB notified if substantial

Unacceptable deviations

• Undocumented until audit

• No justification

• Impact ignored

• No corrective action

Document deviations promptly. Assess impact honestly. Take corrective action.

Certificate renewal considerations

During renewal, expect comprehensive PMCF review:

• All PMCF reports since last renewal

• Cumulative data analysis

• Trend identification

• Gap closure evidence

• Plan evolution documentation

Prepare a PMCF summary covering the certificate period.

PMCF in QMS context

Your Quality Management System should define:

Responsibilities

• Who owns PMCF planning

• Who executes activities

• Who writes reports

• Who reviews and approves

Processes

• How gaps are identified

• How objectives are set

• How activities are monitored

• How changes are controlled

Records

• Where documents are stored

• How versions are controlled

• What approval records exist

ISO 13485 clause 7.2.3 links to this. Auditors will check.

Continuous improvement

Use PMCF findings to improve:

• Device design and instructions

• Clinical evaluation methodology

• Risk management approach

• Training programs

• Quality processes

PMCF is not just compliance. It is learning.

Series conclusion

Over ten episodes, we covered:

1. What PMCF is and why it matters

2. PMCF versus PMS relationship

3. Building the PMCF Plan

4. Setting objectives from CER gaps

5. Device registries

6. Surveys that work

7. Post-market clinical studies

8. Writing the PMCF Evaluation Report

9. Common mistakes to avoid

10. Lifecycle management

You now have the knowledge to build, execute, and maintain PMCF documentation that generates real clinical evidence and satisfies regulatory requirements.

PMCF done well is not a burden. It is competitive advantage. It proves your device works in the real world. It builds evidence that supports your claims. It catches problems before they become crises.

Treat it accordingly.

P.S.1 👉 This concludes the PMCF Mastery series. Thank you for following along. What series would you like next? CER updates? Risk management? Let me know.

P.S.2 👉 Join our community to continue the conversation: here.

P.S.3 👉 If you just joined: welcome. Every Wednesday, I share clinical evaluation insights for medical devices.

✌️ Peace,

Hatem

Your Clinical Evaluation Expert & Partner

Welcome back. Today we learn from others’ mistakes. I have reviewed hundreds of PMCF plans and reports. Notified Bodies have seen thousands. The same problems appear again and again.

Here are the top PMCF failures and how to avoid them.

Mistake 1: Generic objectives

What happens:

“The PMCF will confirm safety and performance of the device.”

Copy-paste from templates. No device-specific content. No link to CER gaps.

Why it fails:

Notified Bodies immediately see this as checkbox compliance. No thought. No value.

How to fix:

Replace generic statements with specific, measurable objectives linked to identified CER gaps.

Good example:

“Collect 24-month performance data in patients over 70 years (n≥100) to address the gap identified in CER Section 8.3 regarding limited elderly population evidence.”

Mistake 2: Insufficient data stratification

What happens:

PMCF collects aggregate data. No breakdown by:

• Device variant

• Patient subgroup

• Clinical indication

• Use setting

Why it fails:

Aggregate data hides important signals. Notified Bodies want to see performance across all claimed uses.

How to fix:

Plan stratified data collection from the start. Report results by relevant subgroups. Identify any subgroup performance differences.

Mistake 3: Poor survey design

What happens:

• 50-question surveys

• 15% response rate

• Leading questions

• No validation

Why it fails:

Low response rates introduce bias. Long surveys frustrate respondents. Results are not credible.

How to fix:

• Keep surveys under 15 questions

• Use validated instruments where possible

• Pilot test before deployment

• Plan response rate improvement strategies

• Analyze non-response bias

Mistake 4: No sample size justification

What happens:

“We will collect data from 50 patients.”

Why 50? Based on what calculation?

Why it fails:

Arbitrary numbers suggest no scientific rationale. Notified Bodies question whether results will be meaningful.

How to fix:

Provide statistical justification. Even simple rationale helps:

• “Based on expected event rate of 5%, 385 patients needed to detect with 80% power”

• “All patients enrolled in participating centers during 12-month period (estimated n=200)”

Mistake 5: Unrealistic timelines

What happens:

“Multi-center registry with 500 patients will be completed in 6 months.”

Why it fails:

Notified Bodies know enrollment takes time. Site initiation takes time. Follow-up takes time. Unrealistic promises undermine credibility.

How to fix:

Build realistic timelines with:

• Site initiation period

• Enrollment period based on realistic rates

• Follow-up duration

• Analysis and reporting time

• Buffer for delays

Mistake 6: PMCF plan disconnected from CER

What happens:

PMCF plan does not reference CER. Activities do not address identified gaps. No traceability.

Why it fails:

PMCF exists to update clinical evaluation. Without connection to CER gaps, it serves no regulatory purpose.

How to fix:

• Explicitly reference CER version

• Create traceability matrix: CER gap → PMCF objective → PMCF activity

• Ensure every activity traces to a gap or requirement

Mistake 7: Data collection without analysis

What happens:

Registry collects data for years. No interim analysis. No reports. Data sits unused.

Why it fails:

Collection without analysis provides no evidence. Also fails PMCF report requirements.

How to fix:

• Plan interim analyses

• Set triggers for action

• Produce PMCF reports on schedule

• Act on findings

Mistake 8: Hiding unfavorable findings

What happens:

PMCF finds performance below expectations in one subgroup. Report emphasizes overall positive results. Subgroup issue buried in appendix.

Why it fails:

Notified Bodies look for this. Auditors dig into details. Hidden problems eventually surface, destroying trust.

How to fix:

Report all findings transparently. Acknowledge limitations. Document root cause analysis. Show corrective actions.

Mistake 9: No action on findings

What happens:

PMCF report documents findings. Nothing happens. CER not updated. Risk file not revised. Same PMCF plan continues.

Why it fails:

PMCF is meant to update clinical evaluation. If findings do not drive action, the system is broken.

How to fix:

Every PMCF report must include:

• Impact assessment on CER

• Actions taken or planned

• Updates to other documentation

• PMCF plan revisions if needed

Mistake 10: Failing to execute the plan

What happens:

Beautiful PMCF plan approved during certification. Two years later, nothing has been done.

Why it fails:

Notified Bodies view PMCF plans as binding commitments. Non-execution is major non-conformance. Can lead to certificate suspension.

How to fix:

• Assign responsibility for PMCF execution

• Include PMCF milestones in project management

• Review progress regularly

• Report execution status in surveillance audits

Quick self-assessment

Review your PMCF plan against this checklist:

• ☐ Objectives specific to device and gaps?

• ☐ Sample sizes justified?

• ☐ Timelines realistic?

• ☐ Traceability to CER documented?

• ☐ Data stratification planned?

• ☐ Survey design validated?

• ☐ Interim analyses scheduled?

• ☐ Action triggers defined?

• ☐ Resources allocated for execution?

• ☐ Report schedule established?

More than 2 unchecked items? Revise before submission.

Learning from NB findings

When you receive PMCF-related findings:

• Address root cause, not just symptom

• Consider whether same issue exists elsewhere

• Update templates and processes

• Train team on lessons learned

Repeat findings indicate systemic problems.

P.S.1 👉 Final episode next Wednesday: PMCF lifecycle management. Keeping your PMCF current as device and evidence evolve.

P.S.2 👉 Join our community to continue the conversation: here

P.S.3 👉 If you just joined: welcome. Every Wednesday, I share clinical evaluation insights for medical devices.

✌️ Peace,

Hatem

Your Clinical Evaluation Expert & Partner

Welcome back. You have collected data through registries, surveys, and studies. Now you analyze it and write the PMCF Evaluation Report.

MDCG 2020-8 provides the template. But templates do not write themselves. Today we learn how to write a report that satisfies reviewers and actually informs your clinical evaluation.

Purpose of the PMCF Evaluation Report

The report serves three functions:

1. Document results of PMCF activities

2. Analyze findings against PMCF objectives

3. Update clinical evaluation with new evidence

It is not just a data dump. It is analysis, interpretation, and action.

MDCG 2020-8 structure

The template has four main sections:

• Section A: Manufacturer and device information

• Section B: Device description and specification

• Section C: Activities and results

• Section D: Summary and conclusions

Let us walk through each with practical guidance.

Section A: Administrative information

Basic details:

• Manufacturer name, address, SRN

• Authorized representative (if applicable)

• Report author and qualifications

• Report version and date

• PMCF plan version referenced

Straightforward but necessary. Missing information creates administrative findings.

Section B: Device description

Mirror your CER device description:

• Device name and models covered

• Intended purpose

• Classification

• Technical specifications summary

Keep it consistent with other documents. Discrepancies raise questions.

Section C: Activities and results

This is the core section. For each activity in your PMCF plan:

C.1 Activity description

• What was planned (reference PMCF plan section)

• What was actually done

• Any deviations and justifications

C.2 Data collected

• Quantitative data with statistics

• Qualitative findings

• Data quality assessment

C.3 Analysis

• Methods used

• Results presentation

• Comparison to acceptance criteria

• Comparison to SOTA benchmarks

C.4 Conclusions per activity

• Objective achieved or not

• Evidence strength

• Implications for clinical evaluation

Presenting registry data

For registry results:

Enrollment summary

• Target vs actual enrollment

• Enrollment timeline

• Site distribution

Patient characteristics

• Demographics

• Baseline disease status

• Relevant comorbidities

Outcomes

• Primary endpoint results

• Secondary endpoints

• Safety events

• Follow-up completeness

Analysis

• Statistical methods

• Subgroup analyses

• Missing data handling

Use tables effectively. Raw data in appendix if needed.

Presenting survey data

For survey results:

Response summary

• Surveys distributed

• Response rate

• Responder characteristics

Quantitative results

• Question-by-question results

• Scale score summaries

• Statistical comparisons

Qualitative results

• Theme summary from open questions

• Notable individual responses

Bias assessment

• Non-response analysis

• Comparison to known population

Presenting study data

For PMCF study results:

Study conduct

• Sites and enrollment

• Protocol adherence

• Follow-up completion

Results

• Primary endpoint with confidence intervals

• Secondary endpoints

• Safety outcomes

• Subgroup analyses

Interpretation

• Clinical significance

• Study limitations

• Generalizability

Full study report in appendix. Summary in main body.

Section D: Summary and conclusions

This section drives action:

D.1 Overall summary

• Brief synthesis of all activities

• Key findings across methods

D.2 Conclusions on PMCF objectives

• Each objective addressed

• Evidence supporting conclusions

D.3 Impact on clinical evaluation

• Do findings confirm CER conclusions?

• Any changes to benefit-risk?

• New gaps identified?

• SOTA implications?

D.4 Actions required

• CER update needed?

• Risk management update?

• PMCF plan revision?

• IFU changes?

• Vigilance reporting?

D.5 Next steps

• Continuing activities

• New activities planned

• Timeline for next report

Handling unfavorable findings

PMCF sometimes reveals problems. How you handle them matters:

Do:

• Report findings objectively

• Acknowledge limitations

• Describe root cause analysis

• Document corrective actions

• Link to vigilance if required

Do not:

• Hide unfavorable data

• Minimize without justification

• Delay reporting

• Fail to act on signals

Transparent handling of problems builds credibility. Hidden problems destroy it.

Linking to CER

Every PMCF report should explicitly state how findings affect your Clinical Evaluation Report:

• Finding: Performance confirmed → CER Impact: No change to Section X

• Finding: New safety signal → CER Impact: Update Section Y, revise benefit-risk

• Finding: SOTA benchmark exceeded → CER Impact: Update SOTA, strengthen claims

• Finding: Gap identified → CER Impact: Add to limitations, update PMCF plan

Make the connection explicit.

Report frequency

• Class III: Annual

• Implantable: Annual

• Class IIb: Every 2-5 years

• Class IIa: Every 2-5 years

• Class I: As needed

Higher frequency may be needed based on:

• Regulatory conditions

• Safety signals

• New data availability

Common report mistakes

Mistake 1: Data without analysis

Presenting numbers without interpretation. What do the results mean?

Mistake 2: No link to CER

Report exists in isolation. No clear connection to clinical evaluation update.

Mistake 3: Missing deviations

Activities differed from plan but no explanation provided.

Mistake 4: No conclusions

Data presented but no conclusion on whether objectives were met.

Mistake 5: No actions

Findings described but no documentation of resulting actions.

Report quality checklist

Before finalizing:

• ☐ All PMCF plan activities addressed

• ☐ Deviations documented and justified

• ☐ Data presented with appropriate statistics

• ☐ Analysis methods described

• ☐ Conclusions stated for each objective

• ☐ CER impact explicitly documented

• ☐ Actions and next steps defined

• ☐ Version control maintained

P.S.1 👉 Next Wednesday: Common PMCF mistakes that Notified Bodies find. Learn from others’ errors.

P.S.2 👉 Join our community to continue the conversation: here

P.S.3 👉 If you just joined: welcome. Every Wednesday, I share clinical evaluation insights for medical devices.

✌️ Peace,

Hatem

Your Clinical Evaluation Expert & Partner

Welcome back. Sometimes registries and surveys are not enough. Some PMCF objectives require formal clinical studies.

PMCF studies differ from pre-market investigations. They study devices already on the market, in real-world conditions, with different regulatory requirements.

Today we cover when and how to conduct PMCF studies.

When PMCF studies are needed

PMCF studies make sense when:

• Specific clinical questions need controlled investigation

• Registry data cannot answer the objective

• Comparative effectiveness data is needed

• Rare events require active surveillance

• Regulatory commitments mandate studies

Not every device needs a PMCF study. But some questions only studies can answer.

PMCF study types

Prospective observational studies

• Follow patients forward in time

• No intervention beyond standard care

• Capture outcomes as they occur

• Lower regulatory burden than interventional studies

Retrospective studies

• Analyze existing data

• Faster and cheaper

• Limited by available data quality

• Selection bias concerns

Interventional studies

• Protocol-driven treatment

• Stricter regulatory requirements

• May require clinical investigation approval

• Reserved for specific research questions

Comparative studies

• Compare device to alternatives

• May be concurrent or historical

• Strengthen evidence for benefit claims

• Important for SOTA positioning

IMDRF guidance on PMCF studies

The IMDRF document (N65) provides international guidance:

PMCF studies should address uncertainties from pre-market phase:

• Rare adverse events

• Long-term safety and performance

• Use in specific populations

• Effectiveness in real-world conditions

The guidance emphasizes scientific rigor while recognizing post-market context.

Study design elements

Objectives

Specific, measurable, linked to PMCF plan:

• Primary endpoint (one)

• Secondary endpoints (limited)

• Safety endpoints

Population

• Inclusion criteria

• Exclusion criteria

• Justification for criteria

• Geographic considerations

Sample size

• Statistical justification

• Power calculation

• Dropout assumptions

• Feasibility assessment

Follow-up

• Duration and intervals

• Assessment schedule

• Loss to follow-up handling

Regulatory requirements

When clinical investigation notification is needed

Under MDR Article 74, PMCF studies may require notification if they involve:

• Additional procedures beyond standard care

• Devices used outside intended purpose

• Comparative interventions

Pure observational studies of CE-marked devices in normal use typically do not require notification. But check with your Competent Authority.

Ethics requirements

• Ethics committee approval typically required

• Informed consent from participants

• Data protection compliance

Study registration

Consider registering in:

• ClinicalTrials.gov

• EU Clinical Trials Register

• National registries

Registration improves transparency and credibility.

Study conduct

Site selection

• Qualified investigators

• Adequate patient population

• GCP capability

• Geographic distribution

Monitoring

• Risk-based monitoring approach

• Source data verification for key variables

• Safety monitoring procedures

Safety reporting

• Adverse event collection

• Serious adverse event reporting

• Potential link to vigilance system

Data management

• Validated data capture system

• Query resolution process

• Database lock procedures

ISO 14155 alignment

For interventional PMCF studies, consider ISO 14155 requirements:

• Clinical investigation plan

• Investigator qualifications

• Subject protection

• Data quality assurance

• Reporting requirements

Even for observational studies, ISO 14155 principles improve quality.

Common PMCF study mistakes

Mistake 1: Objectives too broad

“Confirm safety and performance” is not a study objective. Be specific about what you are measuring.

Mistake 2: Inadequate sample size

Under-powered studies waste resources without providing answers. Calculate sample size properly.

Mistake 3: Poor site selection

Choosing sites for convenience rather than scientific appropriateness. Diversity matters.

Mistake 4: Insufficient follow-up

Studies too short to capture meaningful endpoints. Match duration to clinical question.

Mistake 5: Ignoring bias

No acknowledgment of selection bias, measurement bias, or confounding. Address limitations honestly.

Study reporting

PMCF study results should include:

• Study design description

• Population characteristics

• Primary endpoint results

• Secondary endpoint results

• Safety data

• Limitations

• Conclusions relevant to clinical evaluation

Present results objectively. Negative findings are findings too.

Integration with clinical evaluation

PMCF study results feed into:

• PMCF Evaluation Report (detailed analysis)

• CER update (clinical evidence section)

• Benefit-risk reassessment

• Risk management file update

• PMCF plan revision (if new questions emerge)

The study is not an end. It is part of the continuous evaluation cycle.

Cost-benefit of PMCF studies

PMCF studies require significant investment:

• Study design and protocol development

• Site initiation and training

• Patient enrollment and follow-up

• Data management and analysis

• Regulatory and ethics submissions

Weigh against:

• Value of evidence generated

• Regulatory requirement satisfaction

• Competitive differentiation

• Risk mitigation

Sometimes a registry is enough. Sometimes a study is essential. Choose wisely.

P.S.1 👉 Next Wednesday: Writing the PMCF Evaluation Report. Where all your data comes together.

P.S.2 👉 Join our community to continue the conversation: here

P.S.3 👉 If you just joined: welcome. Every Wednesday, I share clinical evaluation insights for medical devices.

✌️ Peace,

Hatem

Your Clinical Evaluation Expert & Partner

Welcome back. Surveys are the most used and most abused PMCF method. Easy to deploy. Hard to do well.

MDCG 2020-6 ranks high-quality user surveys at evidence level 4. General usability surveys rank at level 8. The difference is design quality.

Today we learn to design surveys that generate useful clinical evidence.

Why surveys fail

Most PMCF surveys fail for predictable reasons:

• Low response rates (often below 20%)

• Biased respondent selection

• Leading or ambiguous questions

• No validation

• Results that cannot answer PMCF objectives

Notified Bodies see these failures. They know the difference between checkbox surveys and serious data collection.

Survey types for PMCF

User surveys

Target: Healthcare professionals using the device

Purpose:

• Assess usability in real settings

• Collect adverse event reports

• Evaluate performance perceptions

• Identify off-label use

Patient surveys

Target: Patients treated with the device

Purpose:

• Patient-reported outcomes

• Quality of life assessment

• Satisfaction measures

• Long-term symptom tracking

Institutional surveys

Target: Healthcare institutions

Purpose:

• Adoption patterns

• Training adequacy

• System integration issues

• Workflow impact

Designing effective surveys

Start with objectives

What specific PMCF objective does this survey address?

Bad: “Collect user feedback”

Good: “Assess whether users can correctly interpret device alerts in clinical settings, targeting minimum 80% correct interpretation rate”

Keep it short

Response rate drops with survey length.

• Under 10 questions: Good response rate

• 10-20 questions: Moderate response rate

• Over 20 questions: Expect low response

Every question must justify its inclusion.

Use validated instruments

When possible, use validated questionnaires:

• EQ-5D for quality of life

• VAS for pain

• Disease-specific validated tools

• Usability scales (SUS, etc.)

Validated instruments provide comparable, credible data.

Question design

Avoid leading questions

Bad: “How satisfied are you with the device’s excellent performance?”

Good: “How would you rate the device’s performance?”

Be specific

Bad: “Does the device work well?”

Good: “In your last 10 uses, how many times did the device produce the expected result?”

Provide appropriate scales

Use consistent scales:

• 5-point Likert scales

• Numeric rating scales

• Yes/No for factual questions

Define scale anchors clearly.

Include open-ended questions sparingly

One or two open questions for unexpected findings. Do not rely on them for primary endpoints.

Improving response rates

Strategies and their expected impact:

• Pre-notification: +10-15%

• Personalization: +5-10%

• Shorter survey: +10-20%

• Reminder emails: +15-25%

• Incentives (where appropriate): +10-15%

• Mobile-friendly design: +5-10%

Plan your response rate strategy. A 20% response rate may not be credible for clinical conclusions.

Respondent selection

Avoid selection bias:

• Do not only survey satisfied customers

• Include all relevant user segments

• Document selection methodology

• Report non-responder characteristics when possible

Selection bias undermines validity. Notified Bodies will ask how you selected respondents.

Survey validation

Before deployment:

Content validation

• Expert review of questions

• Check alignment with objectives

• Ensure clinical relevance

Pilot testing

• Test with small group

• Check comprehension

• Measure completion time

• Identify technical issues

Cognitive testing

• Interview pilot respondents

• Understand how questions are interpreted

• Revise ambiguous items

Analyzing survey data

Quantitative analysis

• Descriptive statistics

• Response distributions

• Subgroup comparisons

• Statistical significance where appropriate

Qualitative analysis

• Theme identification for open questions

• Frequency of specific issues

• Notable individual responses

Bias assessment

• Non-response bias analysis

• Comparison with known population

• Limitations acknowledgment

Survey limitations

Be honest about what surveys can and cannot do:

Surveys CAN:

• Capture user and patient perspectives

• Identify usability issues

• Screen for safety signals

• Supplement registry data

Surveys CANNOT:

• Replace clinical outcome data

• Provide definitive safety conclusions

• Generate Level 1 evidence

• Answer complex clinical questions

Position surveys appropriately in your PMCF strategy.

Documentation requirements

Your PMCF plan should document:

• Survey objectives and rationale

• Target population and sampling method

• Survey instrument (attach or reference)

• Expected response rate

• Analysis plan

• Limitations

Your PMCF report should include:

• Actual response rate

• Respondent characteristics

• Full results

• Non-response analysis

• Conclusions and limitations

Integration with other methods

Surveys work best combined with:

• Registry data (surveys add context)

• Literature review (surveys confirm findings)

• PMCF studies (surveys capture broader population)

A multi-method approach is stronger than surveys alone.

P.S.1 👉 Next Wednesday: Post-market clinical studies. When registries and surveys are not enough.

P.S.2 👉 Join our community to continue the conversation: here

P.S.3 👉 If you just joined: welcome. Every Wednesday, I share clinical evaluation insights for medical devices.

✌️ Peace,

Hatem

Your Clinical Evaluation Expert & Partner

Welcome back. We have covered planning and objectives. Now we explore methods. Starting with device registries, the workhorse of PMCF data collection.

MDR emphasizes registries. Annex VI requires Notified Bodies to consider registry data during recertification. This is your most powerful post-market tool.

What is a device registry

A device registry is an organized system that collects and maintains structured records on a specific device, disease, or procedure for a defined population over time.

Key characteristics:

• Prospective data collection

• Standardized data elements

• Defined patient population

• Long-term follow-up capability

• Real-world use conditions

Unlike clinical studies, registries capture routine clinical practice without strict inclusion criteria.

Types of registries

Manufacturer registries

You create and maintain the registry:

• Full control over data elements

• Direct relationship with sites

• Higher data quality potential

• More resource-intensive

Third-party registries

You contribute to existing registries:

• Lower resource burden

• Less control over data elements

• Data sharing arrangements needed

• Established infrastructure

National/regional registries

Mandatory or voluntary reporting systems:

• Large patient populations

• Standardized outcomes

• Long follow-up periods

• May require data access agreements

Registry data elements

Typical PMCF registry includes:

Patient demographics

• Age, sex, relevant comorbidities

• Indication for device use

Device information

• Model, lot number, serial number

• Implant/use date

• Configuration details

Procedural data

• Procedure type

• Concomitant devices

• Operator experience level

Outcomes

• Primary endpoint (device-specific)

• Safety events

• Reinterventions

• Patient-reported outcomes

Follow-up

• Follow-up intervals

• Loss to follow-up documentation

Registry design considerations

Sample size

Calculate based on:

• Expected event rate

• Precision needed

• Detectable difference

• Anticipated dropout

Do not pick arbitrary numbers. Justify your target enrollment.

Site selection

Consider:

• Geographic distribution

• High vs low volume centers

• Academic vs community settings

• Training and support needs

Diversity strengthens generalizability.

Follow-up duration

Determine based on:

• Device expected lifetime

• Time to event occurrence

• Regulatory expectations

• Practical feasibility

Implantable devices may need 10+ years. Software may need 2-3 years with updates.

Data quality assurance

Registries fail when data quality is poor.

Build in:

• Mandatory fields for critical data

• Range checks and validation rules

• Source data verification for sample

• Missing data monitoring

• Site feedback on data quality

Garbage in, garbage out. Quality assurance is not optional.

Registry governance

Define upfront:

• Who owns the data

• Who can access it

• How decisions are made

• Publication rights

• Regulatory use provisions

Put this in contracts before enrollment starts.

Leveraging existing registries

Before building your own, check for existing registries:

• National implant registries

• Professional society registries

• Disease-specific registries

• Hospital-based registries

Advantages of existing registries:

• Established enrollment

• Proven data collection

• Lower startup costs

• Benchmarking possible

Disadvantages:

• May lack device-specific fields

• Data access may be restricted

• Less control over quality

Registry vs PMCF study

• Registry: Observational, broad inclusion, real-world use, large numbers possible, lower per-patient cost, less control

• PMCF Study: Can be interventional, specific inclusion criteria, may have protocols, often smaller, higher per-patient cost, more control

Choose based on your objectives. Some questions need studies. Many can be answered with registries.

Regulatory considerations

Ethics and consent

• Local ethics requirements vary

• Patient consent typically required

• Consider waiver provisions for minimal risk

Data protection

• GDPR compliance for EU data

• Pseudonymization requirements

• Cross-border data transfer rules

Regulatory reporting

• Include registry in your PMCF plan

• Reference in CER updates

• Report findings in PMCF evaluation report

Common registry mistakes

Mistake 1: Too many data fields

Every field needs collection effort. Collect what you will use. Delete the rest.

Mistake 2: No follow-up infrastructure

Enrollment is easy. Follow-up is hard. Plan for patient tracking from day one.

Mistake 3: Unclear endpoints

Define endpoints before enrollment. Changing definitions mid-registry compromises validity.

Mistake 4: Ignoring missing data

Plan how you will handle missing data. Document patterns. Analyze impact.

Mistake 5: No interim analysis

Do not wait years for results. Plan interim analyses to detect signals early.

From registry to CER update

Registry data feeds your clinical evaluation:

1. Analyze registry outcomes against CER acceptance criteria

2. Compare to SOTA benchmarks

3. Identify any new safety signals

4. Update benefit-risk if findings warrant

5. Document in PMCF evaluation report

6. Incorporate into CER update

The loop must close. Data collection without analysis is wasted effort.

P.S.1 👉 Next Wednesday: Surveys. When designed properly, they complement registry data with user and patient perspectives.

P.S.2 👉 If you have an existing registry, review whether it captures what your PMCF plan needs.

P.S.3 👉 If you just joined: welcome. Every Wednesday, I share clinical evaluation insights for medical devices.

✌️ Peace,

Hatem

Your Clinical Evaluation Expert & Partner

Welcome back. Episode 3 covered the PMCF plan structure. Today we focus on the most critical element: setting objectives.

Good objectives come from your CER gaps. Bad objectives come from templates. Let me show you how to identify gaps and translate them into actionable PMCF objectives.

Where gaps come from

Your Clinical Evaluation Report should identify gaps. If it does not, you have a CER problem before you have a PMCF problem.

Common gap sources:

• Limited pre-market study duration

• Narrow patient population in clinical data

• Single-site validation

• Small sample sizes

• Missing subgroup analysis

• No data on rare adverse events

• Theoretical risks not yet observed

Each gap is a potential PMCF objective.

Gap categories

Performance gaps

Your device shows good performance, but:

• Follow-up duration is limited

• Specific populations are underrepresented

• Real-world conditions differ from study conditions

Example: Device validated for 12 months. Long-term performance unknown.

Safety gaps

Safety profile is acceptable, but:

• Rare events not captured due to sample size

• Certain complications have theoretical risk

• User errors observed but not quantified

Example: Theoretical risk of sensor degradation after 24 months. No long-term data available.

Use condition gaps

Device works in validated settings, but:

• Deployment sites may differ

• User expertise varies

• Combination use not fully studied

Example: Validated in academic hospitals. Performance in community clinics unknown.

From gaps to objectives

Each gap should translate to a specific objective.

Bad translation

Gap: Limited data in elderly patients.

Bad objective: Collect data in elderly patients.

This is too vague. How many patients? What data? Over what period?

Good translation

Gap: Pre-market study included only 12 patients over 70 years. Performance in elderly population not fully characterized.

Good objective: Enroll minimum 100 patients over 70 years in device registry. Collect 12-month performance outcomes. Compare sensitivity and specificity to under-70 cohort.

Specific. Measurable. Linked to evidence need.

The SMART framework for PMCF

Apply SMART to each objective:

• Specific: What exactly will you measure?

• Measurable: How will you quantify success?

• Achievable: Is this realistic given resources?

• Relevant: Does this address a CER gap?

• Time-bound: When will you have results?

If your objective fails any criterion, revise it.

Objective-to-method matching

Each objective suggests appropriate methods:

• Long-term safety: Registry, PMCF study

• Rare events: Large registry, literature surveillance

• Specific populations: Targeted enrollment, stratified analysis

• User perspectives: Surveys, interviews

• Real-world performance: Registry, observational study

• Comparative effectiveness: Registry with comparison arm

Choose methods that can actually answer your question.

Sample size considerations

Every quantitative objective needs sample size justification.

Bad: Collect data from 50 patients.

Good: Collect data from minimum 385 patients to detect 5% difference in complication rate with 80% power at 95% confidence, accounting for 15% loss to follow-up.

You do not need complex statistics. But you need rationale for your numbers.

Handling “no gaps” claims

Some manufacturers claim their CER has no gaps. This is almost never true.

Even well-established devices have:

• Evolving SOTA to monitor

• Long-term data needs

• Real-world performance confirmation

• Rare event surveillance requirements

A “no gaps” claim triggers Notified Body skepticism. Better to identify modest gaps and address them appropriately.

Prioritizing objectives

You may identify more gaps than you can practically address. Prioritize:

High priority

• Safety-related gaps

• Gaps in high-risk populations

• Regulatory commitments

• Certificate conditions

Medium priority

• Performance confirmation needs

• User feedback collection

• SOTA monitoring

Lower priority

• Marketing-driven questions

• Competitive benchmarking

• Nice-to-know data

Document your prioritization rationale.

Objective evolution

PMCF objectives are not static. They evolve as:

• Pre-market data accumulates (gaps close)

• Post-market data reveals new questions

• SOTA changes

• Incidents occur

• Regulations update

Build review points into your plan. Annual objective review is minimum. More frequent for higher risk devices.

Linking objectives to CER sections

Create explicit references:

• Objective: Confirm sensitivity in diabetic patients → CER Section Reference: CER Section 8.3, Gap Analysis

• Objective: Monitor for delayed hypersensitivity → CER Section Reference: CER Section 7.2, Residual Risks

• Objective: Collect 5-year durability data → CER Section Reference: CER Section 9.1, Benefit-Risk

This traceability proves your PMCF addresses CER needs.

What reviewers reject

Notified Bodies reject objectives that are:

• Generic statements copied from templates

• Not linked to identified gaps

• Impossible to measure

• Unrealistic given resources

• Already answered by existing data

Before finalizing, ask: “Can I explain why this specific objective matters for this specific device?”

P.S.1 👉 Next Wednesday: PMCF methods starting with device registries. The workhorse of post-market clinical data collection.

P.S.2 👉 Your objectives drive everything else. Get them right before writing the rest of the plan.

P.S.3 👉 If you just joined: welcome. Every Wednesday, I share clinical evaluation insights for medical devices.

✌️ Peace,

Hatem

Your Clinical Evaluation Expert & Partner

Welcome back. Today we build the PMCF Plan. Section by section, following the MDCG 2020-7 template.

This is where most manufacturers struggle. Generic plans fail. Device-specific plans pass. Let me show you the difference.

The MDCG 2020-7 structure

The official template has seven sections:

• Section A: Manufacturer contact details

• Section B: Medical device description

• Section C: Objectives and scope

• Section D: Evaluation of clinical data related to equivalent/similar devices

• Section E: Reference to relevant CER sections

• Section F: Procedures and methods

• Section G: Estimated dates

Let us walk through each.

Section A: Manufacturer details

Basic administrative information:

• Manufacturer name and address

• SRN (Single Registration Number)

• Authorized Representative (if outside EU)

• Contact person for PMCF

Simple, but do not skip it. Missing SRN is a documentation finding.

Section B: Device description

This mirrors your CER device description:

• Device name and model numbers

• Intended purpose

• Device classification and rule

• Target patient population

• Intended users

• Clinical conditions addressed

Key point: if your PMCF plan covers multiple device variants, list them all explicitly with any variant-specific considerations.

Section C: Objectives and scope

This is where plans succeed or fail.

Bad objective:
“To confirm safety and performance of the device.”

Good objective:
“To collect long-term performance data (24-month follow-up) in diabetic patients over 65 years, where pre-market data was limited to 12-month follow-up in patients under 65.”

Good objectives are:

• Specific to identified gaps

• Measurable with clear endpoints

• Time-bound

• Population-specific when relevant

Section D: Equivalent/similar device data

Describe how data from equivalent or similar devices informs your PMCF:

• What equivalent devices exist?

• What clinical data is available from them?

• How does this data apply to your device?

• What gaps remain despite equivalence?

If you claimed equivalence in your CER, this section must align. Inconsistencies between CER and PMCF plan raise red flags.

Section E: Reference to CER

Connect your PMCF plan to your Clinical Evaluation Report:

• Reference the specific CER version

• Identify which CER conclusions drive PMCF objectives

• List the gaps identified in CER that PMCF will address

• Note the residual risks requiring monitoring

This traceability is critical. Every PMCF activity should trace back to a CER gap or requirement.

Section F: Methods and procedures

Here you describe exactly what you will do:

Literature surveillance

• Search strategy and databases

• Frequency of searches

• Appraisal methodology

Registries

• Which registries you will use or create

• What data points you will collect

• Sample size and enrollment targets

Surveys

• Survey design and validation

• Target respondents

• Response rate expectations

• Follow-up procedures

PMCF studies

• Study design (prospective, retrospective)

• Endpoints and success criteria

• Sample size justification

• Site selection criteria

Each method needs enough detail that someone could execute it. Vague descriptions fail.

Section G: Timelines

Provide estimated dates for:

• Start of each PMCF activity

• Interim analysis points

• PMCF evaluation report completion

• CER update incorporating results

Be realistic. Notified Bodies know how long studies take. Promising a multi-center study completion in 6 months invites skepticism.

The traceability matrix

I recommend adding a traceability table:

• CER Gap: Limited elderly data → PMCF Objective: Collect performance data in >65 years → Method: Registry enrollment → Timeline: 24 months

• CER Gap: No long-term follow-up → PMCF Objective: 5-year safety outcomes → Method: PMCF study → Timeline: Ongoing

• CER Gap: Single-site validation → PMCF Objective: Multi-site performance → Method: Survey program → Timeline: 12 months

This matrix demonstrates you understand the connection between clinical evaluation gaps and PMCF activities.

Common failures in PMCF plans

Failure 1: Generic objectives
Copy-paste from templates without device-specific adaptation.

Failure 2: Methods without details
“Surveys will be conducted” without describing how, to whom, how many.

Failure 3: Disconnection from CER
PMCF activities that do not address actual evidence gaps.

Failure 4: Unrealistic timelines
Promising results faster than scientifically possible.

Failure 5: No sample size justification
Registry targets without statistical rationale.

What Notified Bodies look for

During plan review, expect these questions:

• How does each activity link to a CER gap?

• How did you determine sample sizes?

• What happens if response rates are lower than expected?

• How will interim findings affect the plan?

• What triggers plan revision?

Have answers ready. Document them in the plan itself.

Plan versioning

Your PMCF plan will change. New gaps emerge. Activities complete. Methods need adjustment.

Maintain version control:

• Version number and date

• Change history

• Approval signatures

• Link to corresponding CER version

Each plan version should trace to a specific CER version.

P.S.1 👉 Next Wednesday: Setting PMCF objectives properly. The most important skill in PMCF planning.

P.S.2 👉 Download the MDCG 2020-7 template from the European Commission website for reference.

P.S.3 👉 If you just joined: welcome. Every Wednesday, I share clinical evaluation insights for medical devices.

✌️ Peace,

Hatem

Your Clinical Evaluation Expert & Partner

Welcome back to PMCF Mastery. In Episode 1, I said PMCF is not the same as PMS. Many manufacturers confuse them. This confusion leads to documentation gaps, duplicated efforts, and Notified Body findings.

Today we clarify the relationship.

The parent-child relationship

PMS (Post-Market Surveillance) is the parent system. PMCF (Post-Market Clinical Follow-up) is a specific component within it.

MDR Article 83 defines PMS as the systematic collection and analysis of experience gained from devices placed on the market.

PMCF is one of several activities that feed into PMS. It focuses specifically on clinical data collection to update your clinical evaluation.

What PMS covers

Your PMS system collects and analyzes:

• Complaints and feedback from users

• Serious incidents and vigilance data

• Trend reports

• Scientific literature

• Data from registries

• Field safety corrective actions

• PMCF data

PMS is the umbrella. Everything post-market flows through it.

What PMCF covers

PMCF focuses on proactive clinical data collection:

• PMCF studies and investigations

• Device registries (clinical data)

• User surveys (clinical outcomes)

• Literature surveillance (clinical evidence)

• Real-world performance data

The key difference: PMCF is proactive and clinical. It goes out to gather evidence rather than waiting for problems to surface.

The documentation structure

• PMS Plan: Owner is Quality/Regulatory. Defines all post-market activities.

• PMCF Plan: Owner is Clinical. Defines clinical data collection activities.

• PMS Report / PSUR: Owner is Quality/Regulatory. Summarizes all post-market data.

• PMCF Evaluation Report: Owner is Clinical. Analyzes clinical data, updates CER.

The PMCF Plan is part of your Technical Documentation. The PMCF Report feeds into both your CER and your PMS Report/PSUR.

Data flow between systems

Field complaints ─────────────────────────┐
                                          │
Vigilance reports ────────────────────────┤
                                          │
PMCF Report ──────────────────────────────┼──► PMS Report / PSUR ──► CER Update
                                          │
Trend analysis ───────────────────────────┘

PMCF data flows in two directions:

1. Into the PMS Report as part of overall post-market experience

2. Into the CER as clinical evidence update

Common confusion points

Confusion 1: Literature review

Literature review appears in both systems. How do you handle it?

• PMS literature review: Identifies safety signals, regulatory changes, competitor issues

• PMCF literature review: Evaluates clinical evidence, updates SOTA, assesses new clinical data

Same activity, different focus. Document clearly which purpose each review serves.

Confusion 2: Registries

Registry data can support both systems:

• PMS use: Monitor safety signals, track failure modes

• PMCF use: Collect clinical outcomes, compare to SOTA benchmarks

One registry, two purposes. Your plans should describe both uses.

Confusion 3: Complaints

Complaints are primarily PMS data. But clinical complaints feed PMCF:

• Device malfunction → PMS

• Clinical outcome issue → PMS + PMCF consideration

• Performance below expectation → Both systems

Update frequencies

• Class III: PMCF Report annual, PMS Report/PSUR annual

• Implantable: PMCF Report annual, PMS Report/PSUR annual

• Class IIb: PMCF Report every 2-5 years, PMS Report/PSUR annual

• Class IIa: PMCF Report every 2-5 years, PMS Report when necessary

• Class I: PMCF Report as needed, PMS Report when necessary

Note: PMCF report frequency differs from PSUR frequency for lower risk classes.

Integration in your QMS

Your Quality Management System should clearly define:

• Who owns PMS (typically Quality/Regulatory)

• Who owns PMCF (typically Clinical)

• How data flows between them

• When each report is due

• How findings trigger updates

The worst situation is unclear ownership. Both teams assume the other handles an activity. Gap results.

What Notified Bodies check

During audits, expect questions like:

• How does your PMCF data feed into PMS?

• Where are PMCF findings documented?

• How did PMCF results affect your latest CER update?

• Show me the link between your registry data and clinical evaluation

Be ready to demonstrate the connection. Separate silos fail audits.

Practical tip

Create a simple diagram for your Technical Documentation showing:

1. PMS as the outer circle

2. PMCF as an inner component

3. Arrows showing data flow to CER and PMS Report

4. Clear ownership labels

This visual helps auditors understand your system quickly. It also forces your team to think through the relationships.

P.S.1 👉 Next Wednesday: We build the PMCF Plan using the MDCG 2020-7 template. Section by section.

P.S.2 👉 Join our community for discussions: here

P.S.3 👉 If you just joined: welcome. Every Wednesday, I share clinical evaluation insights for medical devices.

✌️ Peace,

Hatem

Your Clinical Evaluation Expert & Partner

Welcome to a new series. Your CER is approved. Your device is on the market. And now you need to keep proving it works.

That is PMCF. Over the next ten episodes, we master it.

What PMCF Actually Means

Post-Market Clinical Follow-up is a continuous process to proactively collect and evaluate clinical data from the use of a CE-marked medical device.

💡 Key word: Proactive. PMCF is not waiting for complaints. It is actively going out and gathering clinical evidence after market launch.

What MDR Requires

Annex XIV Part B defines PMCF. The regulation lists these mandatory aims:

• Confirm safety & performance: Throughout expected device lifetime

• Identify unknown side-effects: Things not seen in pre-market

• Monitor known side-effects: Track what you already identified

• Analyze emergent risks: New risks from real-world use

• Ensure benefit-risk acceptability: Continuous demonstration

• Identify misuse or off-label use: How users actually use it

This is not optional. Required for all device classes.

The Continuous Cycle

“Clinical evaluation shall be updated throughout the life cycle of the device with clinical data obtained from PMCF.”
— MDR Article 61(11)

The flow looks like this:

CER → identifies gaps → PMCF Plan → collects data → PMCF Report → updates CER

This cycle never stops. Your clinical evaluation is never “done.”

Why PMCF is important

Under MDD, PMCF was often a checkbox. A few lines stating surveillance would continue.

MDR changed everything:

• MDD approach: Generic statements, minimal documentation, rare NB review, optional activities

• MDR approach: Detailed PMCF Plan required, structured templates (MDCG 2020-7, 2020-8), regular NB scrutiny, mandatory objectives linked to CER

⚠️ Warning: Notified Bodies now review your PMCF plan during certification. They check progress during audits. They expect execution.

The Five PMCF Objectives

Every PMCF plan must address specific objectives from your clinical evaluation:

1. Confirming performance: in real-world populations

2. Gathering long-term data: safety over time

3. Collecting subgroup evidence: specific populations

4. Validating use settings: different clinical environments

5. Monitoring rare events: adverse events not seen pre-market

Your objectives must be device-specific. Generic objectives fail NB review.

PMCF Is Not PMS

PMCF sits within your Post-Market Surveillance system. But they are different:

• PMS: Reactive and proactive, technical + clinical data, complaints/vigilance/literature, quality system requirement

• PMCF: Primarily proactive, clinical data focus, studies/registries/surveys, clinical evaluation requirement

PMCF is the clinical arm of post-market activities. It feeds evidence back to your CER.

What Happens If You Ignore PMCF

⚠️ Notified Bodies view your PMCF plan as a binding commitment.

Failure to execute may result in:

• ☐ Major non-conformances

• ☐ Certificate suspension

• ☐ Certificate cancellation

This is not theoretical. I have seen manufacturers lose certificates because they committed to PMCF activities and never executed them.

The Series Roadmap

Over the next nine episodes:

• Episode 2: PMCF vs PMS relationship

• Episode 3: Building the PMCF Plan

• Episode 4: Setting objectives from CER gaps

• Episode 5-7: Methods: registries, surveys, studies

• Episode 8: Writing the PMCF Report

• Episode 9: Common mistakes

• Episode 10: Lifecycle management

By the end, you will build PMCF documentation that survives NB scrutiny and actually generates useful clinical evidence.

P.S.1 👉 Next Wednesday: We clarify PMCF vs PMS. Many manufacturers confuse them. This confusion leads to documentation gaps.

P.S.2 👉 Source documents for this series: MDCG 2020-7, MDCG 2020-8, and IMDRF guidance on PMCF studies.

P.S.3 👉 If you just joined: welcome. Every Wednesday, I share clinical evaluation insights for medical devices.

✌️ Peace,

Hatem

Your Clinical Evaluation Expert & Partner

Welcome back to Clinical Evaluation Secrets.

We are now in Episode 16, the final episode of our series on creating a Clinical Evaluation Report for your AI-based MDSW.

Your CER can have solid SOTA, clear claims, and strong evidence. And still fail at the benefit-risk section.

In this episode, you will learn how to build a benefit-risk analysis that survives regulatory audit and keeps your file audit-ready.

What MDR actually requires

Annex I, Chapter I, Section 1 states that devices shall achieve intended performance and be designed such that risks are acceptable when weighed against benefits under normal conditions of use.

This weighing happens against SOTA. The state of the art is not background reading. It is the benchmark against which your benefit-risk gains meaning.

Understanding clinical benefits under MDR

MDR defines clinical benefits as positive health impact on individuals, expressed through meaningful, measurable, patient-relevant outcomes.

Key terms:

• Meaningful — not just statistical

• Measurable — quantifiable where possible

• Patient-relevant — connected to real outcomes

A feature is not a benefit. Faster processing is not a benefit. Earlier detection leading to timely intervention that improves outcomes is a benefit.

The SOTA anchor

Your SOTA defines what the medical community currently recognizes as best practice.

This becomes your comparison point:

• If current practice achieves 78% sensitivity and your AI achieves 92%, that difference represents potential benefit

• But only if the improvement translates to meaningful patient outcomes

• If current practice has a 5% complication rate and your device introduces new failure modes, you must demonstrate benefit magnitude justifies added risk

Without SOTA context, benefit-risk claims float without anchor.

Residual risks for AI systems

AI software faces risks that traditional devices do not:

• Performance drift: Model validated on 2023 data may degrade as protocols change

• Site variability: Academic center performance may not transfer to community hospitals

• Automation bias: Clinicians may over-rely on AI or dismiss valid findings

• Failure mode opacity: Incorrect outputs may appear as confident as correct ones

Each risk requires documented controls. Each control must appear in benefit-risk as a mitigating factor.

The common failure pattern

Most benefit-risk sections I review share the same structure:

• A list of benefits

• A list of risks

• A concluding sentence stating benefits outweigh risks

This fails for three reasons:

1. Lacks quantification: reviewers want magnitude, not assertions

2. Lacks traceability: each claim should trace to evidence, each risk to risk management file

3. Lacks context: the balance depends on clinical situation

Building the benefit-risk matrix

For each claimed benefit:

• State benefit in clinical terms

• Reference supporting evidence

• Quantify magnitude where data permits

• Compare to SOTA benchmark

• Link to relevant GSPR

For each identified risk:

• State risk and potential clinical consequence

• Reference risk management file entry

• Describe implemented control

• State residual risk level after control

• Compare to acceptable levels in SOTA

Then provide the weighing. Judgment grounded in evidence, not assertion.

Evidence requirements scale with risk

Factors that increase evidence burden:

• Risk classification: Class III vs Class IIa

• Device complexity: Novel AI vs established approaches

• Intended use: Diagnostic claims vs workflow efficiency

• User context: Home use vs professional-controlled settings

• Population: Vulnerable populations vs general adults

Your benefit-risk should acknowledge these factors and demonstrate proportionate evidence.

What reviewers look for

Notified Body reviewers ask specific questions:

• Is clinical benefit meaningful for intended population?

• Are risks adequately characterized with severity, probability, detectability?

• Are controls proportionate to risks?

• Is residual risk acceptable given benefit compared to SOTA?

• Does PMCF plan address evidence uncertainties?

Anticipate these questions. Answer them explicitly in your documentation.

Audit readiness checklist

Your file is audit-ready when:

• ☐ Every benefit claim has traceable evidence reference

• ☐ Every risk has risk management file entry

• ☐ Controls are documented and verified

• ☐ Residual risk levels are explicitly stated

• ☐ SOTA comparison is current and documented

• ☐ Benefit-risk weighing includes quantified reasoning

• ☐ PMCF objectives address remaining uncertainties

• ☐ Version control links CER to risk management file versions

The practical template

Section 1: Clinical Context

• Condition addressed and clinical need

• Current practice and SOTA benchmarks

• Patient population characteristics

Section 2: Benefit Summary

• List of claimed benefits with evidence references

• Quantification of benefit magnitude

• Comparison to SOTA alternatives

Section 3: Risk Summary

• List of identified risks with severity and probability

• AI-specific risks explicitly addressed

• Controls and residual risk levels

Section 4: Benefit-Risk Weighing

• Explicit comparison of benefit magnitude vs residual risk

• Contextual factors affecting balance

• Statement of acceptability with justification

Section 5: Uncertainties and PMCF Linkage

• Acknowledged evidence gaps

• PMCF objectives addressing gaps

Series conclusion

We have now covered the full journey:

• Episode 1-3: Qualification and regulatory framework

• Episode 4-9: SOTA and CEP development

• Episode 10-14: Evidence and CER construction

• Episode 15-16: Benefits, risks, and audit readiness

The CER is not a one-time deliverable. It is a living document. Evidence accumulates. Standards evolve. Software updates occur.

The clinical evaluation you submit today is the beginning, not the end.

What comes next

Throughout this series, I mentioned PMCF multiple times. The PMCF plan addresses your evidence gaps. The PMCF report feeds back into your CER updates. Without PMCF, your clinical evaluation is incomplete.

But PMCF deserves its own deep dive.

Next series: PMCF Mastery

Ten episodes covering everything you need to build effective post-market clinical follow-up:

1. What is PMCF and why it matters under MDR

2. PMCF versus PMS: understanding the relationship

3. Building the PMCF Plan (MDCG 2020-7)

4. Setting PMCF objectives from your CER gaps

5. PMCF methods: device registries

6. PMCF methods: surveys that actually work

7. PMCF methods: post-market clinical studies

8. Writing the PMCF Evaluation Report (MDCG 2020-8)

9. Common PMCF mistakes and how to avoid them

10. PMCF lifecycle: updates, changes, and NB interactions

Same format. Same practical focus. Starting next week.

P.S.1 👉 This concludes the Mastering AI SaMD Clinical Evaluation series. Thank you for following along. The PMCF Mastery series starts next Wednesday, ten episodes on building post-market clinical follow-up that actually works.

P.S.2 👉 Join our community to continue the conversation: here

P.S.3 👉 If you just joined: welcome. Every Wednesday, I share clinical evaluation insights for medical devices.

✌️ Peace,

Hatem

Your Clinical Evaluation Expert & Partner

Happy New Year!

It has been 4 weeks since our last virtual chat. I was taking care of some stuff really close to my heart. I will share with you at the right time.

So grab your coffee and let’s get back.

The Challenge

Not every AI device saves lives directly. Some improve workflows. Some reduce time. Some make other processes more reliable.

💡 Key insight: Many CERs fail here. They force indirect benefits into direct clinical language. Or ignore them entirely.

Neither approach works.

What MDR Says About Benefits

MDR defines clinical benefits as positive health impact through:

• Meaningful — Not just statistical significance

• Measurable — Quantifiable where possible

• Patient-relevant — Connected to real outcomes

For diagnostic AI detecting cancer, the path is direct: earlier detection → earlier treatment → better survival.

But what about AI that:

• Automates image preprocessing

• Prioritizes worklists

• Reduces documentation time

• Standardizes measurements

The patient never interacts with these tools. Yet they require clinical evaluation.

MDCG Recognizes Indirect Benefits

📝 MDCG 2020-1: “Some software may have no direct clinical benefit yet still requires appropriate clinical evidence supporting its intended purpose.”

This is not a loophole. Medical care is a system. Improvements to the system can benefit patients even when the path is indirect.

Examples:

• Reduced radiologist fatigue → Fewer missed findings

• Faster report turnaround → Faster treatment decisions

• Standardized measurements → Reduced inter-observer variability

Workflow vs Clinical Benefit

Consider an AI reducing CT report time from 15 minutes to 8 minutes.

Scenario A: Clinical Benefit

Faster reports → Faster treatment in emergencies → Better outcomes

Document with evidence showing turnaround time affects treatment timing.

Scenario B: Operational Benefit Only

Faster reports → More cases per shift → No direct patient impact

Important to healthcare systems. Not a clinical benefit.

⚠️ Warning: Your CER must be honest about which category your device falls into.

Building the Evidence Chain

For indirect benefits, you need explicit chain documentation:

1. State the workflow claim — What does the device do?

2. Establish the clinical link — How does this affect patient care?

3. Support each link — Literature, data, expert opinion

Evidence types for each link:

• Workflow improvement — Your validation data

• Clinical connection — Published literature

• Patient outcome — Clinical studies or expert opinion

The chain must be plausible and documented. Reviewers challenge weak links.

Quantify Your Claims

Vague claims invite skepticism. Numbers build credibility.

❌ Don’t say: “Improves efficiency.”
✅ Do say: Reduces case time from 12.3 to 7.8 minutes

❌ Don’t say: “Better consistency”
✅ Do say: Inter-observer CV decreased from 15% to 6%

❌ Don’t say: “Faster result.s”
✅ Do say: Time to result reduced by 40%

Quantified claims can be traced to evidence. They set measurable acceptance criteria.

Workflow Study Methods

Traditional evidence focuses on diagnostic accuracy. Workflow claims need different approaches:

• Time-motion studies — Document task duration changes

• Usability studies — Assess workflow integration

• Comparative studies — Assisted vs unassisted performance

• Satisfaction surveys — Capture user experience

💡 These are valid clinical evidence. Plan them in your CEP. Do not dismiss them as “less rigorous.”

SOTA for Workflow Devices

Your SOTA must address the workflow context, not just the clinical condition.

For report automation AI:

• Current reporting practices

• Existing automation tools

• Evidence on efficiency and error rates

For worklist prioritization AI:

• Current triage methods

• Prioritization accuracy data

• Evidence on outcome impact

Combining Direct and Indirect Benefits

Many AI devices have both:

• Direct benefits (e.g., detects findings) → Use accuracy studies

• Indirect benefits (e.g., reduces reading time) → Use time-motion studies

Present each with appropriate evidence. Do not conflate them.

⚠️ Strong workflow benefits do not compensate for weak diagnostic accuracy.

Documentation Checklist

Before finalizing your CER:

• ☐ Direct and indirect benefits clearly distinguished

• ☐ Workflow improvement quantified with data

• ☐ Link to clinical benefit is plausible and supported

• ☐ SOTA addresses the workflow context

• ☐ Evidence type matches claim type

• ☐ Indirect benefits not inflated beyond actual impact

P.S.1 👉 Next episode: residual risks, benefit-risk analysis, and audit readiness. Where everything converges.

P.S.2 👉 Join our community to get more insights: here

P.S.3 👉 If you just joined: welcome. Every Wednesday, I dive into clinical evaluation for AI medical devices. We are wrapping up a 16-episode masterclass on AI SaMD clinical evaluation under MDR.

✌️ Peace,

Hatem

Your Clinical Evaluation Expert & Partner

Welcome back to Clinical Evaluation Secrets. We're now in Episode 14 of our series on creating a Clinical Evaluation Report for your AI-based MDSW. Your CER stands or falls on the clarity of your claims. In this episode you will write performance and safety claims for AI software so that each claim is testable, mapped to MDR requirements, and aligned with the software specific guidance.

What regulators expect your claims to cover

• Under MDR Annex I you must state what the device does and show conformity with the General Safety and Performance Requirements through evidence and predefined acceptance criteria. Your claims must link to those requirements.

• For software the MDCG 2020 1 paper asks you to demonstrate three pillars. Valid clinical association. Analytical or technical performance. Clinical performance in the intended setting. Organize claims under these pillars so the evaluation is traceable.

• For AI that is high risk under the AI Act you also need claims or controls that reflect data quality, bias management, transparency, robustness, logging, and human oversight. These obligations run in parallel to MDR.

Write claims that reviewers can test

Use one line per claim with a measurable endpoint and a threshold. Tie each claim to a pillar and to a GSPR. Examples below are generic. Replace numbers with those you set in your CEP.

A. Valid clinical association

• The model output is associated with the targeted condition as defined by the accepted reference standard for this indication. Primary endpoint is area under the ROC curve meeting the target and floor from the CEP.

B. Analytical or technical performance

• The software processes input data and produces outputs within the specified limits for accuracy and repeatability.

• Time to result per case is within the workflow limit.

• Performance under degraded input conditions remains within the predefined drop tolerance.

C. Clinical performance

• In the intended users and setting the device achieves sensitivity and specificity at or above the targets on an external dataset with the defined case mix.

• Subgroup performance for age sex and key comorbidities meets the floors specified in the CEP.

D. AI Act aligned safety and oversight

• Outputs are accompanied by information needed for user understanding and intervention.

• Human oversight procedures are available to prevent or minimize risks during intended use and reasonably foreseeable misuse.

• Post market monitoring and event logging are in place to detect drift and new risks.

Map each claim to evidence and to risk

For every claim in the list, include four cross references in your CER

1. GSPR item from Annex I that the claim supports.

2. Acceptance criteria from the CEP including target and floor.

3. Datasets and studies that test the claim, with external validation highlighted.

4. Risk controls that depend on the claim, for example human oversight for false negatives or usability controls, so the link to ISO 14971 and Annex I is visible.

Metrics that work well for AI software claims

Choose metrics that match clinical decisions, not just statistical elegance.

• Discrimination. Sensitivity, specificity, ROC AUC with confidence intervals and prespecified thresholds.

• Calibration. Calibration slope, intercept, Brier score when probabilities are shown to users.

• Error profile. False negative rate, false positive rate, per patient and per encounter where relevant.

• Robustness. Performance deltas under lower signal quality or site changes.

• Timeliness. Time to result within the clinical pathway.

• Usability. Serious use error rate and task success for the intended users.

• Subgroups. Results for predefined demographics and acquisition settings. MDCG and modern reporting checklists expect this.

Add AI specific safety claims and controls

These are often missing and they matter for both MDR and the AI Act

• Data representativeness
  Training and test datasets represent the intended population and setting. State this as a verifiable property and support it with dataset tables in the CER.

• Separation of development and testing
  There is clear separation between training and test data. External validation is used to confirm generalization. Make this explicit in the claim set and in the evidence tables.

• Transparency to users
  Users receive information on inputs, outputs, intended use, limitations, and confidence or uncertainty so they can interpret and intervene. This aligns with AI Act transparency and with software guidance.

• Human oversight
  The system provides clear routes to review and override decisions and includes safeguards for known error modes. State the oversight rule inside the claim and verify it through usability studies.

• Lifecycle monitoring
  Performance is monitored after release through a written post market monitoring plan with logs and triggers for action, as required for high risk AI. Connect those triggers to your acceptance criteria.

Example claim set you can adapt

Use these as a pattern for your indication

• Diagnostic sensitivity at or above the target on an external multicenter dataset with the prespecified case mix. Decision threshold predefined in the CEP.

• Specificity at or above the target on the same dataset with confidence intervals that meet the CEP rule.

• Robustness claim. Performance drop no greater than the predefined limit under degraded input quality scenarios that reflect field conditions.

• Subgroup claim. Floors met for predefined demographic and site subgroups in external validation.

• Usability claim. Serious use error rate below the predefined limit for intended users with the final user interface. Link to Annex I and your usability studies.

• Human oversight claim. Users can understand outputs and take corrective action including override according to the described steps. Verified in usability testing.

• Monitoring claim. The provider maintains post market monitoring with logs and drift checks as described in the plan. Triggers lead to CAPA, retraining, or rollback and are documented in PMS and PMCF outputs.

Keep the wording tight

Strong claims use precise language

• Who uses it

• In what setting

• For which population

• For which decision or outcome

• With what metric and threshold

• Under what time limits

• With what guardrails for safety and oversight

This mirrors the IMDRF SaMD approach for clinical evaluation and keeps your story consistent across the pillars.

Quick checks before you lock the claims

• Every claim has a metric and a threshold from the CEP.

• External validation exists for each primary clinical claim.

• Subgroup results are present for predefined groups.

• Human oversight and transparency are addressed with evidence.

• Each claim maps to a GSPR and has a place in PMS and PMCF.

P.S.1 👉 Next episode, we will capture indirect benefits and workflow impact so that your CER can show value in clinical practice as well as statistical performance.

P.S.2 👉 Join our community to get more insights: here

P.S.3 👉 If you just joined: welcome. Every Sunday, I share short reflections on clinical work and business. Every Wednesday, I dive into clinical evaluation and medical device regulatory tips and tricks. Right now, we're learning how to create a clinical evaluation for AI-based MDSW under the MDR.

✌️ Peace,

Hatem

Your Clinical Evaluation Expert & Partner