SaMD App Development: Building FDA-Compliant Medical Software Applications

If you’re leading SaMD app development for a mobile or cloud product, you need the engineering moves that ship real code, then survive audits and App Store/Play reviews.

You get compliance-aware architecture, human-factors that hold up in summative tests, CI/CD that auto-generates your audited evidence set, and a change-impact rubric so updates don’t trigger re-filings.

We skip the certification tutorial, the definitions, submission packaging, clinical validation, and PMS theory; we’ll link to those so you can stay hands-on. If you’re still scoping the product, we’ll point you to healthcare app development resources; if you’re in the build lane, keep reading.

Who this is for: product and engineering leads shipping mobile health apps and medical device apps where the release cadence never gets to outrun the trace matrix.

Hand the playbook to your team today: clear patterns, checklists, and guardrails that compress risk without bloating paperwork. Let’s build like we mean to pass an audit on Friday and iterate on Monday.

What does it take to build a SaMD app?

Six engineering tracks: compliance-aware architecture, IEC 62304 traceability as code, human-factors testing, CI/CD that emits your design history file, GMLP for AI/ML, and App Store review. Software as a medical device (SaMD) is software that diagnoses, treats, prevents, or drives a clinical decision on its own, and this guide is the engineering half of software as a medical device development: how to build a SaMD app that ships on schedule and survives an audit.

Key Takeaways

• Build evidence by default: wire CI to emit DHF bundles and enforce a trace matrix in every PR. Treat artifacts as code and an audit becomes a query.
• Split testing by risk: automate the routine (unit/integration/perf/security); observe what can impact care (HF summative, clinical decision points, failure drills).
• Treat distribution and ops as engineering: design for App Store compliance up front, gate exposure with flags, dark-launch to a slice of users first, and use a change-impact rubric to decide hotfix vs minor vs re-file.

Table of Contents

1. Is my app SaMD?
2. What changed in 2026
3. Compliance‑aware architecture for mobile/cloud SaMD
4. Agile, but 62304-compliant: work products & traceability
5. Human-factors engineering for mobile SaMD
6. CI/CD for regulated apps: quality gates, DHF automation, releases
7. Testing you automate vs what must stay manual
8. AI/ML in SaMD: GMLP-friendly build & ops
9. App Store & Play distribution for medical apps
10. Post‑release ops and change impact
11. Cost & timeline: engineering-only view
12. How Topflight shortens the path to evidence on SaMD builds

Is my app SaMD?

Before any SaMD application development, run this 60-second check:

1. Intended use: Does the software diagnose, treat, prevent, or drive clinical decisions (beyond wellness)? If yes, you’re in clinical apps territory.
2. Significance of information: Will outputs be used to inform or drive care decisions in ways that could affect patient safety (i.e., plausibly triggering FDA approval)?
3. Users: Do your end users come to the software through a clinician, either as clinicians themselves or as patients acting under clinician guidance?
4. Risk: Could incorrect, delayed, or missing outputs create meaningful harm (even if mitigations exist)?
5. Claims wording: Does your marketing or labeling imply diagnosis, prediction, or treatment efficacy beyond plain education? A yes there puts you inside medical app certification scope.

 Answer three of the five with a yes and the FDA path is already decided for you.

If you answer “yes” to three or more, you’re likely scoping an FDA medical app. Grab the device classes and classification/IMDRF details in our SaMD Certification & Classification guide, then come back to build.

If most answers came back “no” but your software still pairs with a physical device, you may be building a companion app for medical devices that sits alongside the hardware. Standalone SaMD does the medical work by itself, and that difference changes which FDA path applies.

Confirm SaMD intent this early and architecture, human-factors (HF) testing, continuous integration (CI) and design history file (DHF) automation, and submission prep all start on the right rails.

What changed in 2026

One 2026 change is already binding. The other is further out than most of this year’s posts suggest, and the gap between the two is worth planning around.

FDA QMSR is in force

On February 2, 2026 the FDA’s Quality Management System Regulation replaced the old Quality System Regulation, pulling ISO 13485 into 21 CFR Part 820 by reference. The FDA retired the QSIT inspection technique the same day and moved to the process in Compliance Program 7382.850. For most SaMD development teams that’s a documentation and vocabulary change. What you actually verify stays the same. Your design-control language and your auditor’s do finally come from the same book.

IEC 62304’s second edition isn’t close

Plenty of 2026 write-ups have it arriving any month now. The IEC’s own SC62A project record puts the revision at committee-draft stage, with a forecast publication of October 2028, and people sitting on the working group read that as 2029 in practice. Keep your IEC 62304 software development lifecycle pinned to the 2006 edition and its 2015 amendment. The draft is worth watching, since it widens scope from medical device software to health software generally and adds explicit security threat management, but nothing in it earns a re-tooling of your trace matrix this year.

Depth on both lives in the SaMD Certification & Classification guide. This page stays on the build.

Compliance‑aware architecture for mobile/cloud SaMD

Start software as medical device app development by drawing hard PHI boundaries first. Map ingest → process → persist as a living data-flow, then carve zero-trust network slices:

• separate VPCs/subnets per tier
• mTLS service identity
• deny-by-default policies down to table/row scope

For cloud-based medical apps, isolate patient identifiers from clinical payloads; encrypt both, but keep keys in a managed KMS with short-lived tokens and auto-rotation. Enforce least privilege in IaC and in your API integration layer.

Evidence wins audits

• Pipe every write/read to immutable audit & event stores (WORM or hash-chained)
• Time-sync logs across services

“What happened, when, and by whom” should be one query away. Treat third-party code as a regulated supply chain. Run an SBOM (software bill of materials) on every build and formalize SOUP (software of unknown provenance) intake → approval → continuous monitoring → retirement. Then block merges on license or CVE drift. Secrets hygiene is non-negotiable: short-lived creds live in a vault, and everything rotates on a schedule you can show an auditor.

Secure real-time

Your medical software application runs on real-time data paths, and patient data security has to hold at that speed.

• Prefer event streams with idempotent consumers over chatty RPC
• Design back-pressure and replay

Keep PHI out of logs and analytics by default, and route redacted, structured telemetry. App-store reviewers (and auditors) both look for principled safeguards, so build them in from the first sprint.

Data retention & PHI minimization patterns

Set data-retention windows by table and event type; enforce TTLs at the database/log layer where the rows actually live. Tokenize direct identifiers and segregate re-identification keys. Default analytics to redacted, aggregate streams (consider basic DP noise where useful). Add CI lint rules that block PHI in logs. Treat deletion as a workflow with evidence: request → job → audit entry → verification.

Standards (IEC 62304, ISO 14971, ISO 13485, IEC 62366) shape the why; the patterns above are the how. For the roll-up, see our HIPAA compliant app development guide and the Certification & Classification explainer. The goal: HIPAA compliant apps by construction.

Agile, but 62304-compliant: work products & traceability

Agile fits 62304 when you treat artifacts as code. In the SaMD app development process, pin every work product to Git with IDs and owners:

• SRS/SDS in /docs/requirements and /docs/design (versioned, PR-gated).
• Risk file in /docs/risk (ISO 14971 matrix with severity/probability, mitigation links).
• Verification & Validation (V&V) in /tests with traceable IDs and evidence exports (screens, logs).
• Release notes in /releases/<version> (scope, risks touched, validation summary, rollback).

 Durable IDs are what turn an audit from archaeology into a query.

Wire a traceability matrix that CI assembles on every PR: risk → requirement → test → evidence. Use durable IDs (R-123, REQ-123, T-123, EV-123) and fail the build if any link breaks. That matrix is your audit surface.

Triage defects by severity (S1–S4) and map each one back to a risk control. Create CAPA (corrective and preventive action) hooks for anything systemic (recurring cause, escape to production, or regulator-relevant). Close the loop only when code, tests, medical app validation evidence, and updated docs are merged together.

Branch protection + CODEOWNERS enforce who can approve changes to SRS/SDS/risk. Tags and signed releases anchor the app development lifecycle: every version points to its DHF bundle (autogenerated PDFs/HTML from Markdown). Treat docs like build outputs.

DHF bundle structure (what auditors actually ask for)

Each release bundle should contain: signed release notes; diffed risk file; the trace matrix (risk→requirement→test→evidence); verification reports (unit/integration/perf/security); HF artifacts for any touched flows; SBOM and CVE diff; approvals history (who, when, rationale). One folder per version, immutable and reproducible from Git, so an auditor can answer “what changed and why it’s still safe” in minutes.

For the stepwise flow, see our medical device software development overview, then make this your working spine: artifacts live in Git, links enforced by CI, evidence emitted automatically, and releases that explain what changed and why it’s safe.

Human-factors engineering for mobile SaMD

Human-factors for medical device app development SaMD starts where most teams stumble: real users on real phones, in messy environments. Design for the failure modes you’ll actually see on mobile:

• fat-fingered inputs
• muted/stacked alerts
• OS permission prompts
• background kills
• flaky networks
• tiny-screen cognitive load

In user interface design, prefer constrained choices over free text, show units and normal ranges inline, surface model confidence when relevant, and make handoffs (to EHR, telehealth, or clinical decision support apps) explicit and undoable.

Labeling matters: claims and contraindications must live on-screen where the decision happens.

Summative test packet

• Protocol: intended-use scenarios, with success/failure criteria tied to your residual-risk thresholds.
• Participants: target personas including accessibility needs, at n≥15 per major platform/config.
• Environments: clinic, home, low light/noisy; online/offline; iOS/Android versions.
• Endpoints: use-error rate, time-on-task, critical error taxonomy, SUS (optional).
• Artifacts: screen/audio capture, system logs, annotated error database, debrief notes.
• Analysis & Acceptance: predefined stats, root-cause coding, mitigation actions, re-test plan.

Run this like code. Protocols and results live in Git. Tag releases with the tested UX, and tie each mitigation to a requirement and test ID. That gives you traceability without ceremony and evidence an auditor can follow in one pass.

Labeling microcopy that survives review

Use action verbs and proximal qualifiers: “Review with a clinician” beats passive disclaimers. Put units and ranges next to every value, along with the time it was measured. Surface contraindications at the decision point.

Avoid implied diagnosis in button labels and screenshots. Distinguish alerts (critical vs informational) with both color and copy, and make errors fixable in-flow with undo, edit, and retry.

For HF/usability standards context and how these artifacts roll into submissions, see our SaMD Certification guide (Step 4: Testing & Validation). This is medical app development that holds up on audit day because you planned for human error on Monday.

CI/CD for regulated apps: quality gates, DHF automation, releases

Ship fast by making continuous integration and continuous delivery generate your audit trail by default. For teams developing SaMD apps, wire quality gates that fail loudly and leave evidence:

• Security first: SAST on each PR; DAST in an ephemeral environment; a fresh SBOM on every build; a CVE diff vs the last release.
• Tests with risk context: run unit/integration suites and tag every case with a risk ID (R-###) so the report shows which hazards are controlled.
• Evidence in the repo: export logs, screenshots, test reports, and the SBOM diff to a versioned /evidence/<build> folder.

 Wire it once and the design history file stops being something anyone writes by hand.

Turn your design history file into a build artifact: parse PR metadata (linked requirements, risks touched, test results, approvers) and auto-assemble a DHF bundle (HTML/PDF) on merge. Governance is code: semantic versioning, signed tags, release notes that map changes → risks → tests, and CODEOWNERS to enforce approvers for requirements, risk, and UX files.

For model change control (AI), treat models like binaries: pin dataset and training config hashes, require gated deploys, track post-release performance with drift alerts, and keep a rollback lane that restores the last validated model in one click.

This works whether you favor cross-platform development or native app development. The pipeline shape is the same; only runners change. The payoff is provable safety: every release explains what changed and why it’s still safe.

If you want a partner to help wire this up, our healthcare app developers can land these controls without slowing your roadmap.

Testing you automate vs what must stay manual

In SaMD mobile app development, automate what’s deterministic and repeatable, and keep human eyes on anything that can hurt a patient.

Automate (gates that leave evidence)

• unit tests
• integration/API contracts (idempotency on retries, auth scope)
• performance budgets (p95 latency, memory)
• data-integrity checks (schema drift, migrations, referential rules)
• cybersecurity (SAST/DAST, dependency/CVE scan, secret detection, fuzzing)

This is your backbone for medical app testing.

Keep manual/observed

• human-factors summative sessions
• end-to-end scenarios that cross clinical decision points
• simulated sensor/device failures
• offline/poor-network workflows
• rollback/fire-drill exercises

If a misstep could alter care, watch it with real users, even for diagnostic apps.

Risk-based test plan

For each hazard R-###, map to REQ-###, then to T-### carrying these fields. Fail the build if any link is missing.

Example acceptance: T-217 (R-085): With corrupted ECG at −6 dB SNR, the app must surface “insufficient signal quality” within ≤2 s; suppress diagnostic output; emit risk-tagged event to immutable log.

Quarterly failure drills you should actually run

Corrupted sensor streams; rotated credentials that break background jobs; partial event-bus outages; schema migration rollback; clock-skew between services; offline → online merge conflicts. Pre-write on-call runbooks and record drills as evidence: scenario, detection, operator actions, time-to-mitigation, and lessons captured into new tests. Treat drills as verification of your safety net.

The outcome is a clear path to FDA software validation via an auditable split: machines prove the routine, humans prove the risky.

AI/ML in SaMD: GMLP-friendly build & ops

AI belongs in SaMD only if you can show data lineage, versioned training configs, continuous drift monitoring, and a one-click rollback. Anything less is a risk.

The envelope is what keeps routine retraining from becoming a new submission.

The FDA’s name for that envelope is a Predetermined Change Control Plan (PCCP): the model changes you commit to up front, together with the evaluation protocol that governs them, so routine retraining doesn’t become a new submission every quarter.

Document the model like a device

For Good Machine Learning Practice (GMLP), capture data lineage end-to-end:

• sources
• inclusion/exclusion rules
• labeling instructions
• annotator QA
• cohort breakdowns

Version training configs (hyperparams, seeds, feature lists, preprocessing steps) with immutable hashes; store code+data snapshots in a registry alongside concise “model cards” that state intended use, limits, and known failure modes. In patient monitoring apps and digital therapeutics, surface model confidence and what inputs were used; route ambiguous cases to a human.

Run with guardrails

Ship behind gated stages: offline eval → shadow → canary → full. Define acceptance gates up front (AUROC, calibration, false-negative ceiling, cohort parity); promote only when all pass. Monitor production for drift (input distribution, concept, performance); alert on PSI/KL (population stability index and Kullback-Leibler divergence) thresholds and keep a one-click rollback to the last validated model.

Inside the PCCP envelope, treat each retraining like a release:

• freeze the dataset
• bump the model version
• re-run evals
• update the model card
• capture reviewer sign-offs

Pre-Sub, early and often

Establish a Pre-Submission (Pre-Sub, or Q-Sub) rhythm before big claims ship, and read the FDA clearance path for health AI before you pick one. Bring: intended use and claims, algorithm/system overview, dataset representativeness (incl. edge cohorts), validation results, human-factors mitigations, and your update/rollback plan. Re-engage whenever the claims, the training data, the architecture, or the intended-use population change materially.

The goal is AI you can defend to reviewers, to clinicians, and to your own 3 AM on-call.

App Store & Play distribution for medical apps

Apple and Google reject medical apps for sloppy claims, data disclosures that don’t match the code, missing reviewer context, and screenshots that promise more than the app does. Distribution is engineering work. Build it into the schedule.

 Reviewers reject on sloppy claims and mismatched data forms far more often than on clinical subject matter.

Claim hygiene

Keep claims factual and proximal to the UI action. Avoid “diagnose/treat/cure” unless you have clearance; prefer “supports clinician decision-making.” Your store copy and your screenshots have to describe the same product the app actually is. That’s the base layer of app store compliance.

Permissions & data

Pre-justify prompts (why you need camera, microphone, Bluetooth, motion, notifications). Name every data type you collect, how long you keep it, who you share it with, and what deletion actually removes.

For iOS medical apps:

• declare HealthKit/PHI flows plainly;

For Android healthcare apps:

• match the data safety form to your code paths.

One inconsistent checkbox can derail healthcare mobile apps at review.

Safety signals

Put clinical disclaimers right at the decision points they apply to, and make the adverse-event reporting route visible, an email address or a URL. Don’t bury it in a PDF.

Test package for reviewers

Provide working test users, sample data, step-by-step flows, and feature flags pre-enabled; include a short “what this does/doesn’t do” note. If you’re shipping a SaMD mobile application, add a 1-pager with intended use, limitations, regulatory status, and a named contact.

Review-time survival kit

• Store copy matches in-app labels
• Screenshots avoid implied diagnosis
• All permission prompts justified in-context
• Data safety forms mirror actual telemetry
• Disclaimers + AE reporting path visible
• Test creds + scripts included; region gating off
• Release notes explain changes to regulated features

If you need broader go-to-market context, see our telemedicine app development guide.

Post‑release ops and change impact

In healthcare app development, treat every update like a controlled change: assess claim/algorithm/UI risk up front, then gate exposure with flags and dark-launches. Every release keeps a one-click rollback with the evidence attached.

Change impact rubric (fast triage → right filing path)

Score each release on three axes: Claims (does wording/intent change?), Algorithm (does behavior near a clinical boundary change?), UI Risk (did we alter labels and alerts, or change the workflow at a decision point?).

Release mechanics under design controls

Every change rides behind a feature flag tagged with an owner and a risk level. Dark-launches and canaries control who gets exposed, and nothing ships without a one-click rollback backed by signed, versioned artifacts. Release notes must map change → risk → tests → evidence.

Monitoring and feedback loops

Dashboards track: alert rates, time-to-signal, false-positive/negative proxies, crash-free sessions, network/offline failure rates, model confidence drift (if applicable). Issues flow into a taxonomy (hazard code → component → cohort), with S1–S4 severity and CAPA triggers for systemic defects. Fold field feedback into the risk file each sprint. That’s what disciplined app maintenance looks like.

For modalities like remote patient monitoring apps, widen watchlists to cover device connectivity, data latency, signal quality thresholds, and missed transmissions. A gap in the data is a safety signal.

Incident classes and a 72-hour response rhythm

S1: potential patient harm. Mitigate immediately, freeze related releases, notify RA/QA, and begin CAPA. S2: degraded function without safety risk. Hotfix within 24 hours. S3: minor defect. Roll into the next train. Within 72 hours for S1/S2, publish the root cause with the preventive actions it drives and the matching DHF updates; backport fixes if needed. Measure mean time to detect/mitigate and trend it.

Bottom line: decide what you’re shipping (hotfix/minor/major) via an explicit rubric, control how you ship (flags, dark-launches, canaries, rollback), and prove why it’s safe (dashboards + DHF).

Cost & timeline: engineering-only view

If you’re scoping SaMD app development services, validation and evidence drive the budget. For broad ranges, park the number-crunching on healthcare app development cost; below is what moves time and budget.

 Price the regulated work as a delta and the total stops being a mystery.

What moves the needle

• Human-factors (summative) studies: recruit per platform, run moderated sessions in clinic/home settings, capture video/logs, remediate, re-test. One extra iteration can add weeks.
• Security pen-tests: threat model first, then external pen-test across mobile, API, and cloud; include storefront privacy checks and SBOM/CVE gates.
• V&V depth: risk-based coverage, sized hazard by hazard. The trace matrix (risk→req→test→evidence) dictates effort, and review time.
• Automation: CI that emits DHF bundles cuts release friction; initial setup costs days, saves weeks over a release train.
• AI oversight: dataset curation/label QA, model cards, predefined acceptance gates, drift monitoring, rollback lanes, and occasional Pre-Subs. Each adds real, predictable effort.

What a Class II build actually runs

The regulated work is a delta on top of a normal build, so price it that way. Our healthcare app development cost breakdown puts a healthcare app at $60K to $120K for a simple build, $120K to $220K for a moderate one, and $220K to $450K and up once the scope gets advanced. Class I and II SaMD compliance adds roughly $25K to $80K, and 3 to 8 weeks, on top of whichever tier you land in. That covers QMS setup, risk controls, the validation documentation set, and the review cycles attached to them.

What decides where you sit inside that delta is how many summative human-factors iterations you need and how much your external pen-test turns up. Those two are what slip. FDA-compliant app development gets expensive when a summative session sends you back for a UI change and a re-test.

Where teams waste

• Narrative docs ahead of a traceability spine. Generate docs from PR metadata and tests; don’t write narrative twice.
• Big claims too soon. Narrow intended use to shrink clinical/UX validation scope.
• Premature integrations. Mock EHRs and devices; defer full hookups until architecture stabilizes.
• Underspecified non-functionals. Set budgets (latency, offline behavior, retries) up front, especially for mHealth applications, or you’ll pay for rework.
• One-shot releases. Ship behind flags; smaller deltas mean smaller re-tests.

Standards (62304/14971/62366) explain why these costs exist; for lifecycle-wide ranges, see the certification overview. Your savings come from two levers: risk-based V&V and automation that turns evidence into a by-product of building.

How Topflight shortens the path to evidence on SaMD builds

We shorten the path to evidence. Our teams start with reusable playbooks:

• risk and test templates wired to a trace matrix;
• an SBOM/SOUP intake → approval → monitoring workflow;
• CI pipelines that auto-assemble DHF bundles from PR metadata

On the human-factors side, we run summative test ops like an engineering sprint: screen capture, error taxonomy, mitigation loops, and re-tests tagged to requirements. You get fewer meetings and a DHF that builds itself while you ship.

Where we actually save time: early architecture decisions (PHI boundaries, audit trails) and automated quality gates that make every release evidence-by-default. Where we won’t: inflating claims, skipping summative testing, or punting Pre-Subs. Those guardrails don’t move.

Recent work includes Allheartz, which pairs computer vision in medicine with remote therapeutic monitoring, and several SaMD builds under NDA. In each one, the win was a repeatable path from prototype to audited release.

If you need help, we’ll plug in where the drag is worst (risk files, SBOM/SOUP intake, HF ops, CI/DHF automation) and leave you with tooling your team can own. We’re a SaMD app development company that measures success in shipped, review-ready builds.

[Reviewed August 2026]