IEC 62304 Is Not Optional For Your Clinical Evaluation

Written by HATEM RABEH, MD, MSc Ing

Your Clinical Evaluation Expert And Partner

in
S

This disconnect creates real problems during review. Not because either side failed, but because the connection between software lifecycle documentation and clinical evidence requirements remains unclear in many organizations.

Let me walk you through what reviewers actually look for when they assess software medical devices under MDR, and why your IEC 62304 documentation is more than a technical checkbox.

The Regulatory Foundation You Already Know

MDR Article 61(1) requires clinical evaluation for all medical devices. No exceptions for software. MDCG 2020-1 on clinical evaluation clarifies that the nature and extent of clinical data needed depends on the device’s characteristics, including its technological features.

IEC 62304 defines the software development lifecycle for medical device software. It requires risk-based software safety classification (Class A, B, or C), architecture documentation, verification activities, and risk management integration.

Both frameworks exist. Both are mandatory. The question is how they connect in practice.

Where the Documentation Gap Appears

The technical file contains complete IEC 62304 documentation. Software requirements specification, architecture, detailed design, verification protocols, traceability matrices. Everything is there. The software team worked methodically.

The clinical evaluation report contains literature reviews, equivalence discussions, and safety summaries. The clinical team followed MEDDEV 2.7/1 structure. Everything is there.

But when a reviewer reads both documents, they cannot see how the software’s safety classification influenced the clinical evidence strategy. They cannot trace how software verification results support clinical performance claims. The documents exist in parallel, not in connection.

This is not a theoretical concern. I watch Notified Bodies stop reviews at this exact point.

The Questions That Trigger Deficiencies

When a reviewer sees a software medical device, they ask specific questions that bridge technical and clinical domains:

What is the software safety class, and what does that mean for clinical risk? If you classified software units as Class C because their failure could result in unacceptable risk, what clinical evidence demonstrates that the implemented risk controls are effective in real use?

How do software verification activities relate to clinical validation? You verified that the algorithm produces the intended output under test conditions. What clinical data shows that this output leads to correct clinical decisions when used by actual users in actual clinical settings?

Where is the clinical justification for your software requirements? Your SRS lists functional requirements and performance specifications. What clinical evidence supports that these requirements are appropriate for the intended medical purpose?

What Reviewers Actually Need To See

The connection must be explicit in your clinical evaluation report. Not assumed. Not implied through separate documents. Written out clearly.

Start With Software Safety Classification

Your clinical evaluation should state the software safety class and explain what that classification means for clinical evidence requirements. This is not just copying information from the technical file. It is translating technical risk assessment into clinical evidence strategy.

For Class A software, where failure results in no injury or damage to health, you explain why clinical data requirements focus on intended use validation rather than extensive safety evidence. You still need clinical evaluation, but the depth differs.

For Class C software, where failure could result in death or serious injury, you explain how your clinical evidence strategy addresses these serious risks. What data demonstrates that your risk controls work clinically? How do you monitor ongoing safety?

This paragraph belongs in your clinical evaluation’s scope section. It frames everything that follows.

Link Software Requirements to Clinical Needs

Your software requirements specification contains performance specifications. Accuracy metrics. Processing time limits. Output formats. These were not chosen randomly.

The clinical evaluation must show where these requirements came from clinically. What literature supports that this accuracy level is appropriate for the clinical decision? What clinical evidence shows that this processing time meets clinical workflow needs? What data demonstrates that users can interpret the output correctly?

I see clinical evaluations that list software specifications but never justify them clinically. A diagnostic algorithm claims 95% sensitivity. Why 95%? What clinical standard does this meet? What happens clinically with the 5% it misses? Your technical file may not answer these questions. Your clinical evaluation must.

Connect Verification to Validation

IEC 62304 requires software verification. You test against specifications. You document that the system does what you designed it to do. This is essential technical work.

But verification is not validation. Your clinical evaluation must address the validation question: does the verified system achieve its intended medical purpose in the intended use environment with the intended users?

This often requires clinical performance studies, usability validation, or real-world data collection. The specific validation approach depends on your device characteristics, but the clinical evaluation must explicitly describe it.

The Algorithm Discussion

If your software includes algorithms, especially machine learning algorithms, the clinical evaluation needs a specific discussion about algorithm validation and generalization.

Training data characteristics. What clinical populations were represented? What were the demographic characteristics? What clinical settings? The clinical evaluation must show that training data reflects your intended use population.

Performance across subgroups. Does the algorithm perform differently for different patient groups? Different disease severities? Different imaging equipment if applicable? Your technical validation may have tested this. Your clinical evaluation must interpret what it means clinically.

Clinical validation in representative settings. Algorithm performance in development datasets often differs from performance in real clinical use. What clinical evidence bridges this gap?

This is where many software device clinical evaluations fail review. The technical documentation shows comprehensive algorithm testing. But the clinical evaluation does not adequately address generalization to real clinical use.

When Equivalence Does Not Work

For software medical devices, equivalence-based clinical evaluation faces additional complexity. Software differences are not always comparable to hardware differences.

A new algorithm is not equivalent to an existing algorithm just because both address the same clinical problem. The implementation, the training approach, the handling of edge cases, all of these create clinical differences that matter.

I see manufacturers try to claim equivalence based on similar intended use, then argue that software differences are “only technical” and do not affect clinical performance. Reviewers do not accept this reasoning. If the software differs, you must justify why those differences do not impact clinical outcomes. This requires clinical evidence, not technical assertions.

The Post-Market Clinical Follow-Up Connection

Your PMCF plan must address software-specific considerations. IEC 62304 requires problem resolution and software maintenance. These activities generate data relevant to clinical evaluation.

Software anomalies and reported problems should feed into PMCF analysis. Not every software issue is a clinical safety issue, but your PMCF must evaluate which problems have clinical implications.

Software updates and modifications trigger specific clinical considerations. When you update your software, what clinical evidence supports that the updated version maintains or improves clinical performance? Your PMCF plan should describe how you generate this evidence.

For learning algorithms that adapt over time, PMCF becomes even more critical. How do you monitor that the algorithm continues to perform safely as it learns? What triggers a clinical re-evaluation? These questions belong in your PMCF plan and must align with your IEC 62304 change management process.

Practical Steps for Integration

The goal is not to copy IEC 62304 documentation into your clinical evaluation report. The goal is to create clear connections that show clinical reasoning about software characteristics.

First step: include a section in your clinical evaluation that addresses software-specific considerations. State the software safety class. Describe the key software features relevant to clinical use. Explain how these features influenced your clinical evidence strategy.

Second step: when you describe your device characteristics in the clinical evaluation, include relevant software architecture information. Not the full technical detail, but enough that a clinical reviewer understands what the software does and how it relates to the medical purpose.

Third step: explicitly link software verification activities to clinical validation needs. When your risk management file identifies software-related risks, your clinical evaluation must show how clinical evidence addresses those risks.

Fourth step: ensure your PMCF plan includes software-specific monitoring. Connect PMCF activities to IEC 62304 problem resolution processes. Show how post-market software data feeds back into clinical safety evaluation.

These connections do not require massive additional documentation. They require thoughtful integration of information that already exists in separate documents.

What This Means During Review

When a Notified Body reviewer reads your clinical evaluation for a software medical device, they should be able to understand your software’s clinical risk profile without reading the full technical file. They should see how software characteristics influenced your evidence strategy. They should understand how you validated clinical performance, not just verified technical specifications.

If the reviewer has to stop and request the IEC 62304 file to understand your clinical reasoning, the integration failed. If they cannot trace how software safety class influenced clinical evidence depth, the integration failed. If they cannot see the connection between software verification and clinical validation, the integration failed.

These failures do not mean your technical work was inadequate. They mean the clinical evaluation did not make the necessary connections explicit.

Looking Forward

As software medical devices become more complex, especially with AI and machine learning, the gap between technical and clinical documentation will only become more visible during review. The manufacturers who address this integration now will have smoother submissions later.

This is not about creating new work. It is about connecting work that different teams already perform. The software engineers understand IEC 62304. The clinical affairs team understands clinical evaluation. The challenge is creating the explicit bridge between these two domains in documentation.

In the next part of this series, I will discuss how usability engineering connects to clinical evaluation, another integration point where documentation often fails to show the necessary connections.

Peace,
Hatem
Clinical Evaluation Expert for Medical Devices
Follow me for more insights and practical advice.