Business Rules - FDA SaMD (Software as a Medical Device)

> Legal/medical note: This section is descriptive and informational. > It does not constitute regulatory advice nor a statement that any software is a medical device. > Always consult a qualified professional (regulatory affairs / quality expert) before making operational decisions. > Governing reference: FDA 21 CFR Part 820 (Quality System Regulation); EU MDR 2017/745.

This document lists the invariant business rules of the SaMD regulatory lifecycle domain, from the perspective of a medical software builder. Each rule describes the compliance and quality process (design control, validation, surveillance), not a clinical instruction. Identified with BR-NNN codes.

---

BR-001 - Intended Use defined before classification

Code: BR-001 Name: Every SaMD starts from a documented Intended Use statement Description: In the SaMD domain, the intended-use statement drives risk classification, predicate suitability, and required clinical validation data. Without a defined Intended Use the regulatory strategy is not assessable. Motivation: Correctly determine the regulatory pathway. Priority: CRITICAL Actors: Regulatory Affairs Specialist, SaMD Manufacturer Traceability: FDA Intended Use; glossary "Intended Use".

---

BR-002 - Documented Design Control for every development

Code: BR-002 Name: SaMD development is governed by Design Control procedures Description: The process requires documented requirements definition, design reviews, verification, validation, and traceability. Design outputs must satisfy design inputs at every stage. Motivation: Ensure development quality and traceability. Priority: HIGH Actors: Quality Manager, Software Engineer Traceability: 21 CFR § 820.30 Design Control (2023); glossary "Design Control".

---

BR-003 - Software safety classification

Code: BR-003 Name: Software is classified Class A/B/C by severity of harm Description: Classification (IEC 62304: A no harm, B non-serious harm, C death/serious harm) determines the depth of development activities. The class must be cited only by clause number, never reproduced verbatim. Motivation: Calibrate lifecycle rigor to patient risk. Priority: HIGH Actors: Risk Manager, Software Engineer Traceability: IEC 62304 (cited by clause number); glossary "Software Safety Classification".

---

BR-004 - Risk management applied to the device

Code: BR-004 Name: Every SaMD applies a documented risk management process Description: The domain requires hazard identification, risk estimation and evaluation, control measures, and residual-risk evaluation. FMEA is a common input technique. Motivation: Reduce risks to acceptable levels and document them. Priority: CRITICAL Actors: Risk Manager, Quality Manager Traceability: ISO 14971 (cited by section number); glossary "ISO 14971", "FMEA".

---

BR-005 - Traceable verification and validation

Code: BR-005 Name: Requirements, design, tests, and risks are linked by a traceability matrix Description: The process requires bidirectional traceability: every requirement implemented and tested, every risk addressed. Verification confirms outputs satisfy inputs; validation confirms conformity to intended use. Motivation: Demonstrate completeness and coverage of requirements and risks. Priority: HIGH Actors: Quality Manager, Software Engineer Traceability: 21 CFR § 820.30(f)(g); glossary "Traceability Matrix", "Verification", "Validation".

---

BR-006 - Premarket pathway consistent with class

Code: BR-006 Name: The premarket submission follows the pathway appropriate to the class Description: In the domain, low/moderate-risk SaMD typically follow 510(k) or De Novo; high-risk Class III devices follow PMA. Pathway choice derives from classification and predicate availability. Motivation: Align the submission to the risk level. Priority: HIGH Actors: Regulatory Affairs Specialist, FDA Traceability: 21 CFR Part 807 (510(k)); Part 814 (PMA); glossary "510(k)", "De Novo", "PMA".

---

BR-007 - Continuous post-market surveillance

Code: BR-007 Name: Every marketed SaMD is subject to post-market surveillance Description: The process requires systematic collection and evaluation of field data: complaint handling, MDR reporting, trend analysis and - for AI/ML SaMD - performance monitoring against ACP limits. Motivation: Identify and address issues after market release. Priority: HIGH Actors: Quality Manager, Post-Market Surveillance Team Traceability: 21 CFR Part 803 (MDR); FDA AI/ML SaMD Action Plan (2021); glossary "PMS", "MDR".

---

BR-008 - AI/ML changes within an Algorithm Change Protocol

Code: BR-008 Name: Planned algorithm changes are bounded by an ACP Description: For AI/ML SaMD, the ACP describes planned change types, performance limits, and tests required before deployment, without requiring a new submission for each change within defined boundaries. Motivation: Allow controlled model evolution while preserving safety. Priority: MEDIUM Actors: Data Scientist, Regulatory Affairs Specialist Traceability: FDA AI/ML SaMD Action Plan (2021); glossary "Algorithm Change Protocol (ACP)".