Documenting Risks and Gaps in Your SOTA

Written by HATEM RABEH, MD, MSc Ing

Your Clinical Evaluation Expert And Partner

in
S

Credibility in clinical evaluation depends on transparently documenting weaknesses, not just strengths. A complete SOTA analysis reveals risks, limitations, and gaps. This is not weakness. This is intellectual honesty that strengthens your entire evaluation.

MEDDEV 2.7/1 Rev 4 is explicit: clinical evaluation is an ongoing, methodical process. You must collect, appraise, and analyze all relevant data, even when that data is unfavorable. Suppressing negative findings is not just poor practice. It is a compliance failure.

What Regulatory Guidance Expects

Guidance documents establish four critical expectations for risk and gap documentation:

Include unfavorable evidence. If published studies show complications, failures, or limitations for current approaches, document them. If your device class has known failure modes, acknowledge them.

Cover all evidence pillars. For software devices, document risks related to valid clinical association, analytical performance, and clinical performance. Each pillar has distinct risk considerations.

Link to risk management. Connect SOTA findings to ISO 14971 controls and IEC 62366 usability requirements. Risks identified in SOTA should appear in your risk management file with corresponding mitigations.

Address lab-to-real-world gaps. Clarify evidence sufficiency and identify gaps requiring post-market clinical follow-up. Performance demonstrated in controlled studies may not reflect real-world use.

The Risk Documentation Framework

For each risk category, document four elements:

Population shifts and exclusions. Which populations are underrepresented in published evidence? Which populations might your device serve differently than studied populations?

Label and reference standard uncertainties. How reliable are the diagnostic standards used in published studies? What uncertainties exist in how outcomes are measured?

Performance degradation across sites. Does performance vary by setting, user, or patient characteristics? What factors might cause your device to perform differently than benchmarks suggest?

Use error and misinterpretation risks. What could go wrong when real users operate the device in real settings? What information could be misinterpreted with clinical consequences?

Risk-to-Control Mapping

For each identified risk, follow a five-step mapping process:

Step 1: Identify hazards from literature, including adverse events, device failures, and use errors reported for similar devices.

Step 2: Estimate risk using available data. What is the probability? What is the severity? What populations are most affected?

Step 3: Select controls. Technical controls (design features), informational controls (labeling and training), or procedural controls (clinical protocols).

Step 4: Plan verification. How will you confirm controls are effective? What testing or monitoring demonstrates risk reduction?

Step 5: Plan post-market monitoring. What signals will you watch for? What triggers escalation?

Structuring SOTA Limitations

Organize your limitations into four sections for reviewer clarity:

Evidence gaps. What clinical questions remain unanswered? What populations lack adequate data? What performance aspects are insufficiently characterized?

Known failure modes. What can go wrong with current devices? What are the recognized limitations of existing approaches?

Potential harms with mitigations. What harms might occur despite mitigations? What residual risks remain after controls are applied?

Future data collection plans. What PMCF activities will address identified gaps? What monitoring will detect emerging issues?

Pitfalls to Avoid

Four common mistakes undermine SOTA risk documentation:

Suppressing negative studies. If unfavorable evidence exists, it will be found. Better to acknowledge and address it than to have reviewers discover omissions.

Disconnecting findings from controls. Risk identification without mitigation is incomplete. Every identified risk should link to a control or a PMCF activity.

Overlooking workflow factors. Technical performance is not the only risk source. Workflow integration, user training, and clinical context all contribute to real-world risk.

Lacking post-market strategy. Some gaps cannot be closed pre-market. A credible PMCF plan demonstrates commitment to ongoing evidence development.

Connecting Gaps to PMCF

Every gap identified in SOTA should map to a PMCF activity. Use a gaps-to-actions table showing each gap, its impact on claims, pre-market mitigation, PMCF strategy, and escalation conditions.

This table demonstrates lifecycle thinking. You understand what you do not know. You have plans to learn it. And you have triggers for taking action based on what you learn.

In the final post of this series, we will address how SOTA requirements vary across different device types and what adaptations are needed for implants, diagnostics, software, and combination products.

Peace,
Hatem
Your Clinical Evaluation Partner