Your STED looks compliant until the Notified Body asks for Annex II

Written by HATEM RABEH, MD, MSc Ing

Your Clinical Evaluation Expert And Partner

in
S

This happens more often than it should. Manufacturers assume that following IMDRF STED means compliance with both FDA and MDR. The structure looks similar. The sections overlap. But the regulatory intent behind each framework is different, and reviewers notice immediately when a file has been retrofitted from one system to another.

The confusion is understandable. STED was developed as a harmonized format to reduce global submission burdens. FDA adopted it. The EU referenced it in guidance. On paper, it should work seamlessly. But in practice, the devil is in how each regulation expects content to be organized, cross-referenced, and justified.

The structural overlap that misleads

IMDRF STED defines seven major sections covering device description, regulatory history, nonclinical and clinical data, labeling, and manufacturing. These sections map reasonably well to both FDA premarket submissions and MDR Annex II requirements.

But mapping is not the same as compliance.

MDR Annex II is not just a list of sections. It is a legal checklist. Each item in Annex II corresponds to specific obligations under the regulation. A Notified Body must verify that every single requirement is addressed, traceable, and documented. If your STED structure does not explicitly connect to each Annex II subsection, the reviewer cannot confirm compliance.

Where STED and MDR diverge

The first divergence appears in device identification and description. STED Section 1 asks for general device information. MDR Annex II Part 1 requires not just description but also risk classification rationale, intended purpose with clinical conditions, patient population, and any claims of equivalence.

Many manufacturers provide a device description that would satisfy FDA but omit the explicit classification justification required by MDR. The Notified Body cannot proceed without it. The file is returned.

Another common gap occurs in Section 3, nonclinical evaluation. STED asks for biocompatibility, sterilization validation, and other testing. MDR Annex II Part 2 requires these elements but also demands explicit linkage to risk management, conformity to harmonized standards, and justification for any deviations.

If your STED file lists test reports without explaining how they address specific MDR essential requirements or how they integrate with risk analysis, the reviewer will flag it. Not because the data is missing. Because the reasoning is not visible.

The clinical evaluation gap

This is where the disconnect becomes most visible. STED Section 5 asks for a clinical evaluation. MDR Annex XIV defines what that evaluation must contain, how clinical data must be analyzed, and how equivalence or performance must be justified.

A manufacturer working primarily with FDA may prepare a clinical evaluation summary that focuses on safety and effectiveness in line with FDA guidance. It may be thorough. It may reference all relevant studies. But if it does not explicitly address MDR Annex XIV structure, the Notified Body cannot verify compliance.

Specifically, MDR requires:

• Clinical background including state of the art
• Demonstration of equivalence if applicable, per MDCG 2020-5
• Appraisal of clinical data with analysis of risks and benefits
• Clinical performance and safety conclusions
• Integration with risk management and PMCF planning

If your STED clinical section does not map explicitly to these elements, the reviewer has no way to confirm that all obligations are met.

Why cross-referencing is not optional

Some manufacturers add a cross-reference table at the front of the file, listing STED sections against MDR Annex II items. This is a step in the right direction. But it is not sufficient if the content itself does not align.

A cross-reference table tells the reviewer where to look. It does not prove that the content satisfies the requirement. If Section 5.3 of your STED is referenced as addressing MDR Annex XIV point 1, but that section does not contain a clear description of the state of the art, the deficiency remains.

The Notified Body will not interpret or infer. They will ask for clarification. This delays the review.

Building a hybrid structure that works

The solution is not to abandon STED. The solution is to build your technical file with MDR as the compliance anchor and STED as the organizational framework.

Start with MDR Annex II. List every single requirement. Then decide where each requirement will be addressed in your STED structure. Document this mapping explicitly. Not as a table at the front, but as part of your document control system.

When you write Section 5, do not just write a clinical evaluation. Write a clinical evaluation that explicitly addresses each point of MDR Annex XIV, references the corresponding risk analysis sections, and links to PMCF planning. Make the reasoning visible.

When you prepare Section 6 on risk management, do not just summarize your risk analysis. Show how it integrates with clinical evaluation, how residual risks are justified, and how post-market surveillance will monitor those risks. Reference the MDR articles that require this integration.

The reviewer’s perspective

When a Notified Body opens your file, they do not start by reading STED Section 1. They start with their MDR checklist. They need to confirm that every legal obligation is met. If your file is structured only for FDA, they cannot do their job efficiently.

This does not mean the file is non-compliant. It means the compliance is not visible. And in regulatory review, invisible compliance is the same as no compliance.

The reviewer will send queries. You will respond. The process will extend. Eventually, you may achieve approval. But the cost in time, resources, and confidence could have been avoided.

What the queries reveal

Most STED-related deficiencies I see in reviews fall into three categories:

1. Missing explicit linkage between device claims and clinical evidence
2. Lack of visible integration between clinical evaluation and risk management
3. Insufficient demonstration that state of the art was considered in design and evaluation

None of these deficiencies mean the data is absent. They mean the data is not presented in a way that proves MDR compliance. The manufacturer knows the device is safe. The clinical evaluation supports the claims. But the file does not make this reasoning traceable.

Practical steps for alignment

If you are building a technical file for both FDA and MDR, here is how to structure it:

First, establish your compliance baseline. List every requirement from MDR Annex II. For each requirement, identify where it will be addressed. This becomes your internal control document.

Second, structure your content using STED sections. But within each section, organize the content to explicitly address the corresponding MDR requirements. Do not assume the reader will make the connection.

Third, write your clinical evaluation per MDR Annex XIV. Use MDCG 2020-13 as your structural guide. Then map it into STED Section 5. Do not reverse this process. If you write for FDA first and retrofit for MDR, the gaps will remain.

Fourth, integrate your sections. Clinical evaluation must reference risk management. Risk management must reference clinical evaluation and PMCF. PMCF must feed back into both. Make these connections explicit in the text, not just in cross-references.

When to use a dedicated MDR structure

Some manufacturers choose to abandon STED entirely and build their technical file directly against MDR Annex II. This is a valid approach, especially for devices developed primarily for the EU market.

The advantage is complete alignment with MDR from the start. Every section corresponds directly to a regulatory requirement. There is no ambiguity. The Notified Body can verify compliance efficiently.

The disadvantage is lack of harmonization if you later pursue FDA or other markets. You will need to map your MDR structure back to STED or other formats.

There is no universal answer. The choice depends on your market strategy, regulatory timeline, and internal capabilities. What matters is consistency. If you choose STED, commit to aligning it fully with MDR. If you choose MDR structure, commit to building it comprehensively.

What does not work is a hybrid approach where neither framework is fully respected.

The cost of misalignment

I have seen technical files delayed by six months because of structural misalignment. The device was safe. The data was solid. But the file required extensive rewriting to make MDR compliance visible.

The manufacturer had followed IMDRF STED guidance carefully. They had submitted to FDA successfully. They assumed the same file would work for MDR. It did not. Not because the content was wrong, but because the reasoning was not structured to answer MDR questions.

The cost was not just time. It was confidence. The team questioned whether they had missed something substantive. They had not. They had missed the structural expectations of the regulation.

This is preventable.

Final consideration

STED is a tool. MDR Annex II is a legal obligation. Tools can be adapted. Obligations cannot.

If you are building a technical file for MDR, start with MDR. Use STED as an organizational framework if it helps, but do not let it dictate your compliance strategy. Make your reasoning visible. Make your integration explicit. Make the Notified Body’s job easy.

Because when the reviewer asks how Section 1.1 addresses MDR Annex II Part 1.a, the answer should already be in the document.

In the next part of this series, we will examine how clinical evaluation integrates with risk management documentation and why this integration is the most frequently questioned element in technical file reviews.