> Disclaimer: This content is for educational and reference purposes for software builders only. It does not constitute medical, legal, financial, or regulatory advice. Consult a qualified professional before making decisions based on this content.
Perform Hazard Analysis Before Writing a Single Line of Code
Rationale: IEC 62304 clause 4.2 requires a software safety classification before development activities begin, and that classification is derived from hazard analysis. Starting development without knowing the safety class means development activities (documentation depth, testing rigor, code review requirements) may be set at the wrong level, creating rework risk that is extremely expensive to fix after design freeze.
Do: Conduct a preliminary hazard analysis at project inception. For each anticipated failure mode, define the worst credible harm, assign severity (catastrophic/critical/marginal/negligible), and set the safety class (A/B/C). Document the rationale. Revisit and update the hazard analysis after each major design change.
Do not: Assign safety class by intuition or marketing claims without formal hazard analysis documentation. Do not defer hazard analysis to "after we know what the software does" - it must drive architecture decisions.
Build Bidirectional Traceability from Day One
Rationale: FDA's design controls (21 CFR 820.30) and IEC 62304 both require traceability between requirements, design, implementation, and tests. Attempting to reconstruct traceability retroactively after development is the single most common source of design control findings in FDA inspections and often requires a complete audit of development records.
Do: Use a requirements management tool (JIRA, Polarion, Codebeamer, or even a structured spreadsheet) that enforces traceability links. Define the traceability schema before requirements capture: user need ID → device requirement ID → SRS requirement ID → design element → test case ID. Assign IDs to every artifact at creation time. Generate traceability reports as part of design review outputs.
Do not: Use unstructured documents (Word, Confluence pages) as the primary requirements store without ID assignment and cross-linking. Do not link test cases to "the feature" - link to the specific requirement ID.
Implement Immutable, Tamper-Evident Audit Trails for All Clinical Data Operations
Rationale: 21 CFR Part 11 requires electronic records to include audit trails with computer-generated, date/time-stamped records of operator entries and actions that create, modify, or delete electronic records. In SaMD, the integrity of clinical data (patient inputs, algorithm outputs, user overrides) is directly tied to patient safety. Any modification to a clinical record without an audit trail may constitute a Part 11 violation and, more critically, could mask a safety-relevant event.
Do: Log every create, read-with-clinical-impact, update, and delete on patient data and algorithm outputs with: user ID, timestamp (UTC, millisecond precision), record ID, action type, old value (for updates), new value. Write audit logs to a write-once, append-only store (database table with no UPDATE/DELETE grants, or an WORM object store). Include the audit log in the DHF as a system specification.
Do not: Allow application service accounts to delete or modify audit records. Do not store audit records in the same mutable table as the clinical data they protect. Do not log PHI values in audit record fields that are accessible outside the compliance system.
Version-Control Every Build Artifact and Tie Versions to DHR Records
Rationale: 21 CFR 820.184 requires DHRs to include or reference each device configuration. For SaMD, this means every released software version must be uniquely identified and the DHR for that version must reference the exact build artifacts, test results, and change documentation that produced it. FDA inspectors routinely ask: "Show me the DHR for version X" - without version-controlled artifacts linked to DHRs, you cannot demonstrate compliance.
Do: Implement semantic versioning (MAJOR.MINOR.PATCH) with a documented change severity policy (MAJOR = new intended use or significant algorithm change, MINOR = new feature, PATCH = bug fix). Tag every release commit in version control. Store the DHR as a formal record linking: release version, release date, build hash, change description, test report reference, and approver signatures. Use CI/CD systems to automate DHR artifact collection.
Do not: Release software updates without updating the version identifier and DHR. Do not use "hotfix" deployments that bypass the DHR process, even for critical bug fixes - document first, then deploy.
Apply Defense-in-Depth Cybersecurity for All Network-Connected SaMD
Rationale: FDA's 2023 Cybersecurity Guidance makes explicit that cybersecurity controls are a patient safety requirement for network-connected SaMD. A compromised device can deliver incorrect clinical outputs, be used to access PHI, or become a pivot point into clinical network infrastructure. The guidance requires threat modeling, SBOM, and a patching mechanism as minimum premarket requirements.
Do: Perform formal threat modeling using STRIDE at the system level. Document attacker goals, entry points, and mitigations in the risk management file. Implement: TLS 1.2+ for all data-in-transit, AES-256 for data-at-rest, role-based access controls, MFA for administrative access, input validation on all data entry points, and an authenticated, integrity-verified software update mechanism. Include the SBOM in the premarket submission and establish a process to monitor SBOM components for CVEs post-market.
Do not: Treat cybersecurity as a pre-submission documentation task independent of development. Do not hardcode credentials, encryption keys, or API tokens in source code. Do not ship without a documented vulnerability disclosure policy.
Conduct Summative Usability Testing on the Final Device Before Submission
Rationale: Human factors engineering (HFE) is required by FDA (HFE Guidance 2016) for SaMD to demonstrate that use errors that could cause or contribute to patient harm have been identified and mitigated. Summative testing on a non-final prototype is not acceptable - FDA may ask for additional testing if the final device interface differs from the tested version.
Do: Conduct formative usability studies early in design to identify critical tasks and potential use errors. Conduct a final summative test using representative users, the final UI, and a validated test protocol. Document the test in the DHF. For submission, include a HFE report with: use error analysis, critical tasks, test method, participant demographics, results, and residual risks.
Do not: Use alpha/beta feedback as a substitute for formal summative testing. Do not restrict usability testing to power users - include novice users representative of the intended population. Do not change the UI after summative testing without assessing whether the change could affect critical tasks (if so, re-test).
Validate Clinical Performance on Demographically Representative Datasets
Rationale: FDA expects AI/ML SaMD performance to be validated on data representative of the intended use population. Bias in training or validation datasets (underrepresentation of age groups, sex, race, or disease severity) can result in disparate clinical performance, causing harm to underrepresented groups and creating significant regulatory risk post-market.
Do: Before designing the clinical validation study, define the intended patient population in the SRS. Ensure the validation dataset includes representative samples across clinically relevant subgroups. Report disaggregated performance metrics (sensitivity/specificity by subgroup) in the premarket submission. Establish minimum subgroup performance thresholds as pass/fail criteria.
Do not: Validate on convenience samples or historical datasets without checking demographic distribution. Do not report only overall performance metrics without subgroup analysis when subgroup disparities are plausible. Do not use the training dataset as the validation dataset - maintain strict separation.
Implement a Post-Market Surveillance System Before Launch
Rationale: 21 CFR Part 803 (MDR) and 21 CFR 820.198 (complaint handling) impose ongoing post-market obligations the day a device is placed in distribution. For AI/ML SaMD with an ACP, post-market surveillance must also validate algorithm performance within ACP-defined bounds. Building PMS systems as an afterthought after launch means you may be non-compliant from day one.
Do: Before first shipment/deployment, establish: a formal complaint intake procedure with a dedicated channel, a triage process to identify MDR-reportable events within the 30-day reporting window, a trend analysis process to identify non-reportable events that may signal systemic issues, and for AI/ML SaMD, automated monitoring of performance metrics against ACP-defined thresholds. Assign explicit responsibility for MDR reporting obligations.
Do not: Use generic customer support ticketing systems as the sole complaint intake mechanism without a triage step that evaluates MDR reportability. Do not allow AI/ML model performance drift without an automated alert system.
Manage SOUP Explicitly with Documented Risk Assessments
Rationale: Most modern SaMD incorporates significant open-source and commercial third-party libraries. IEC 62304 clause 8.1 requires explicit management of SOUP items. Unmanaged SOUP with known CVEs is one of FDA's primary cybersecurity concerns - a vulnerability in a widely used library (e.g., log4shell-class events) can expose thousands of deployed SaMD simultaneously.
Do: Maintain a complete SBOM for every released version. For each SOUP item, document: name, version, supplier, intended use within the SaMD, safety class impact, known vulnerabilities (CVE scan result), and verification activities performed. Establish a process to review CVEs in SOUP components at a defined cadence (monthly minimum) and a patch deployment SLA tied to CVSS severity (Critical: 30 days, High: 60 days, Medium: 90 days).
Do not: Add new SOUP dependencies without a DHF change request and SBOM update. Do not pin dependencies and stop monitoring - use automated dependency scanning in CI/CD (Dependabot, Snyk, or equivalent).
Document the Regulatory Pathway Decision Before Starting a 510(k) Submission
Rationale: Submitting to the wrong FDA regulatory pathway - or submitting without an appropriate predicate device - is the most expensive regulatory mistake possible. A "not substantially equivalent" (NSE) determination forces Class III classification and PMA. The average PMA requires 180-day review and extensive clinical data. Early regulatory strategy decisions (pathway, predicate selection, substantial equivalence argument) should be validated with FDA via a Pre-Submission (Q-Sub) before significant submission investment.
Do: Early in the project, prepare a regulatory strategy document that identifies: device classification (with Product Classification Database search evidence), proposed regulatory pathway (510(k), De Novo, PMA), predicate device(s) with comparison of intended use and technological characteristics, and the plan for clinical validation data. Submit a Q-Sub to FDA for feedback before finalizing the strategy, especially for novel algorithms or new disease claims.
Do not: Begin writing a 510(k) without first identifying and documenting the predicate device. Do not select a predicate without verifying it is currently legally marketed and was cleared/approved (not just registered). Do not omit a Q-Sub meeting for first-time 510(k) submitters or for AI/ML SaMD.
Establish a Change Control Board with Regulatory Impact Assessment
Rationale: Post-market changes to SaMD that affect safety or effectiveness require a new 510(k). Using an informal change process that does not include regulatory impact assessment leads to either under-reporting (missing required submissions) or over-reporting (unnecessary submissions that slow down development). A formal Change Control Board (CCB) with a regulatory assessment step prevents both errors.
Do: Implement a CCB process for all post-release changes. For each proposed change, complete a regulatory impact assessment using the FDA flowchart from the 2017 guidance "Deciding When to Submit a 510(k) for a Software Change." Document the assessment rationale and CCB decision in the DHF. Keep a log of all changes assessed as "no new submission required" to demonstrate due diligence during inspections.
Do not: Make emergency hotfix deployments without retroactive CCB documentation. Do not classify changes as non-significant without documented justification. Do not accumulate undocumented minor changes - aggregate effect may cross the threshold requiring a new submission.
Include Electronic Records Compliance (21 CFR Part 11) in System Design
Rationale: SaMD systems that create, modify, maintain, or transmit electronic records intended to be equivalent to paper records (signatures, approvals, clinical records) must comply with 21 CFR Part 11. Non-compliance is discovered during FDA inspections and can result in Warning Letters. Part 11 compliance is a system architecture decision, not an add-on feature.
Do: At design time, identify which system records are subject to Part 11. For those records implement: computer-generated time-stamped audit trails, user authentication linked to individual accounts, electronic signature controls (meaning, printed name, date, and signature manifestation), and record protection from modification. Validate the electronic records system with an IQ/OQ/PQ approach. Document the validation in the DHF.
Do not: Allow shared login accounts for regulated records access. Do not implement Part 11 compliance as a layer on top of an existing mutable database - design for immutability from the start. Do not confuse HIPAA audit logging (access monitoring) with Part 11 audit trails (record modification tracking) - both are required but serve different purposes.