Preparing for a CE or FDA submission can be a daunting process for digital health teams. While many startups focus heavily on product features and speed-to-market, auditors care primarily about risk management, traceability, and validation lifecycles.
Drawing from a decade of audit preparation, this article lists the most common regulatory omissions and technical "red flags" that delay approvals for software as a medical device (SaMD).
1. Poor Risk Analysis Documentation (ISO 14971)
Auditors expect risk management to be a continuous lifecycle process, not a checklist completed right before submission.
- The Red Flag: Lack of clear linkages between identified risks, their clinical consequences, and specific software controls implemented to mitigate them.
- The Fix: Maintain a live hazard log tracing every risk entry directly to software verification tests.
2. Insufficient Software Lifecycle Process Logs (IEC 62304)
Under IEC 62304, software must have a defined software development plan, configuration management, and verification processes.
"The software developer must establish a software verification process to verify that software deliverables meet requirements." — IEC 62304 Cl 5.5
A lack of documented code review logs, manual verification results, or unit test summaries is a primary reason submissions get returned for review.
3. Unvalidated Third-Party SOUP Components
SOUP (Software of Unknown Provenance) includes database engines, libraries, and open-source packages. If your software uses SOUP, you must document its specifications, evaluate its risk, and verify its behavior in your system.