MDDS vs. SaMD for Cloud Platforms: A Builder’s Guide

Confused about when a cloud component is a simple data system vs. a regulated medical device? This concise builder’s guide uses a decision tree, a quick “verb test,” and an EU mapping to help you design the right boundaries from day one.

TL;DR

If your cloud only transfers, stores, converts format, or displays medical device data—and does not analyze, interpret, alarm/triage, or control devices—it likely fits U.S. Non-Device MDDS (software). Add analysis, alarms/triage, risk scoring, or device control and you’re in SaMD territory. For mixed products, separate functions and document their independence.

Decision tree: Is your cloud MDDS or SaMD (U.S.)—corrected branch

Core Definitions

MDDS — Medical Device Data System (U.S.)

Allowed: transfer, store, convert format, display.
Not allowed: analyze/interpret, prioritize/triage, alarm, control.
Software-only MDDS: typically treated as Non-Device (post-Cures Act) if you stay within those verbs.

SaMD — Software as a Medical Device

Performs a medical purpose on its own (e.g., analyzes to diagnose/predict/recommend or drives action).
Evidence scales with clinical role and condition criticality.

Quick “Verb Test”:
    If your claims/UI include analyze, interpret, predict, triage, prioritize, alarm, control → you’re likely SaMD.
    MDDS verbs are store, transfer, convert, display.

Architecture Patterns

MDDS-Only Ingest → secure storage → view-only dashboards/exports. No alarms. No device control.

SaMD Adds analytics/ML, risk or alert engines, triage/prioritization, decision support that fails the non-device CDS criteria, or any remote control.

Architecture: MDDS (store/display) vs. SaMD (analyzes, detects or controls) on a white background — Same cloud, different intent: guardrails keep MDDS-only implementations from drifting into SaMD.

U.S. vs EU: Clear Comparison

Criteria	U.S. MDDS (Non-device software)	U.S. SaMD (Device software)	EU MDSW (Software under MDR)
Purpose	Move/format/display device data only	Performs a medical purpose independently	Qualifies as a medical device per MDR (e.g., diagnosis, prediction, monitoring, control)
Allowed functions	Transfer, store, convert format, display	Analyze, interpret, predict, triage/prioritize, alarm, control device	Depends on intended purpose; if only storage/display without medical purpose → typically not MDSW
Typical examples	Secondary display of ECG; FHIR pass-through	Arrhythmia detection; glucose hypoglycemia alerts; remote control	Software meeting Rule 11 with clinical claims; decision support that drives action
Regulatory pathway	Non-device (no 510(k)); labeling must reflect MDDS scope	Device pathway (510(k)/De Novo/PMA)	CE marking under MDR (classification via Rule 11, Notified Body where applicable)
What triggers device status?	Any analysis/interpretation, alarms/triage, risk scores, or device control	Already device	Medical purpose + classification rules; storage/display alone without medical purpose is out of scope
Documentation focus	Clear intended use & boundaries; marketing copy control	Safety case, clinical evaluation, software lifecycle, cybersecurity	General safety & performance, clinical evaluation, PMS, cybersecurity

Where BioT fits + PCCP

MDDS path: Use BioT as your validated data backbone—controlled ingest, storage, audit logging, export—while locking claims to MDDS verbs. Guard against “feature creep.”
SaMD path: Use BioT’s regulated cloud patterns to assemble evidence—architecture & traceability exports, V&V reports, SBOM, cybersecurity dossier—and manage frequent updates with a PCCP (predetermined change control plan) and impact analysis.
Hybrid: If you ship MDDS and SaMD together, separate services/data paths and document independence.

PCCP = Predetermined Change Control Plan. For AI/ML or frequently updated SaMD, PCCP helps predefine what can change and how you’ll validate it.

Helpful links

Examples (3 quick scenarios)

CGM data lake + read-only dashboards (no alarms) → usually Non-Device MDDS.
Hypoglycemia flagger + push alerts → SaMD (analysis + time-critical output).
Remote parameter changes on a pump → SaMD (device control).

Conclusion

Architecture choices and wording choices are regulatory choices. Decide early whether your cloud is MDDS-only or SaMD—and design the boundaries accordingly. If you’re exploring a PCCP for frequent updates, let’s talk about how BioT keeps the evidence tidy.

Disclaimer: This article is general guidance, not legal advice. For specific products, consider FDA’s Q-Submission process or consult your Notified Body.

< Back to resources Read more tips and expert insights

Blog

When Is Your Cloud Platform MDDS vs. SaMD? A Practical Guide for MedTech Innovators