Inferensys

Guide

How to Build a Compliance Framework for FDA SaMD (Software as a Medical Device)

A technical guide to building the documentation, Quality Management System (QMS), and validation processes required to bring an AI stratification tool to market as an FDA-regulated SaMD.
Developer demonstrating multi-agent tool use, agent tool selection interface on laptop, casual tech demo moment.
REGULATORY FOUNDATION

Introduction

This guide outlines the technical documentation, quality management system (QMS), and validation processes required to bring an AI stratification tool to market as an FDA-regulated SaMD.

Building a compliance framework for FDA-regulated Software as a Medical Device (SaMD) is a foundational engineering discipline. It requires integrating regulatory requirements directly into your software development lifecycle (SDLC) from day one. This is not a post-hoc audit; it's a proactive design constraint that ensures your AI model for patient stratification is safe, effective, and legally marketable. The core components are a Quality Management System (QMS) and adherence to design controls as mandated by 21 CFR Part 820.

Your technical implementation must be traceable. Every requirement, code commit, and test result must link back to your risk management file (ISO 14971) and design history. This guide provides the actionable steps to structure your development, from establishing a QMS with tools like Greenlight Guru to preparing a pre-submission package for the FDA. You will learn to build with validation in mind, creating the evidence needed for a successful regulatory review.

FDA COMPLIANCE

Essential SaMD Documentation Matrix

A comparison of required documentation artifacts across the SaMD development lifecycle, mapping each to its purpose and regulatory reference.

Document ArtifactPurpose & Regulatory BasisOwnerTimeline (SDLC Phase)

Design History File (DHF)

Comprehensive record of design and development, demonstrating adherence to design controls (21 CFR 820.30).

Quality/Systems Engineering

Initiate in Planning; maintain through Retirement

Software Requirements Specification (SRS)

Defines functional, performance, and safety requirements. Traceable to user needs and risk controls.

Product Owner/Systems Engineer

Complete before Architecture & Design

Risk Management File (per ISO 14971)

Documents risk analysis, evaluation, control, and review. Includes Hazard Analysis and FMEA.

Risk Manager

Initiate in Planning; update through Post-Market

Software Design Description (SDD)

Describes software architecture, data flows, and interfaces. Basis for verification and validation.

Software Architect

Complete during Architecture & Design

Traceability Matrix

Bidirectional links between requirements, design, code, tests, and risks. Proves comprehensive testing.

Systems Engineer

Maintain from Requirements through V&V

Verification & Validation (V&V) Protocol/Report

Protocol defines test methods; report proves software meets specifications and is safe/effective for intended use.

V&V Lead/QA

Execute in V&V Phase (Pre-Deployment)

Deployment & Post-Market Surveillance Plan

Defines release procedures, user training, and systems for monitoring real-world performance and adverse events.

Clinical/Regulatory Affairs

Complete before Deployment

FDA SaMD COMPLIANCE

Common Mistakes

Building an AI medical device is a high-stakes engineering challenge. These are the most frequent technical and procedural pitfalls that derail FDA submissions and compromise patient safety.

A Quality Management System (QMS) is the operational backbone of your SaMD. The mistake is treating it as a post-development paperwork exercise. A compliant QMS, aligned with ISO 13485, must be integrated into your Software Development Lifecycle (SDLC) from day one.

Key integration points:

  • Design Controls: Every requirement, code commit, and test must be traceable.
  • Risk Management: ISO 14971 processes must run parallel to development, not after.
  • Change Control: Any modification to code, requirements, or infrastructure must follow a documented procedure.

Without this integration, you cannot prove to the FDA that your development was controlled and reproducible, which is a fundamental requirement for Design History File (DHF) completeness.

Prasad Kumkar

About the author

Prasad Kumkar

CEO & MD, Inference Systems

Prasad Kumkar is the CEO & MD of Inference Systems and writes about AI systems architecture, LLM infrastructure, model serving, evaluation, and production deployment. Over 5+ years, he has worked across computer vision models, L5 autonomous vehicle systems, and LLM research, with a focus on taking complex AI ideas into real-world engineering systems.

His work and writing cover AI systems, large language models, AI agents, multimodal systems, autonomous systems, inference optimization, RAG, evaluation, and production AI engineering.