Software
as a Medical
Device

A logic tree for Software as a Medical Device, from boundary classification through regulatory approval and post-market change control.

Decision
Branch point
Preferred
Lower regulatory burden
Conditional
Standard pathway
High-burden
Full clinical evidence
AI/ML specific
Adaptive system path
STAGE 01

Is It Actually SaMD?

▼

The threshold question. Many wellness apps and clinical tools are not SaMD — getting this wrong either over-regulates a non-device or, more dangerously, under-regulates a true medical device.

Decision 1.1
Does the software perform a medical purpose independent of hardware?
Yes — standalone medical purpose
SaMD confirmed. Software treats, diagnoses, cures, mitigates, or prevents disease; or affects body structure/function.
Proceed to classification. Examples: image analysis algorithms, treatment planners, diagnostic apps.
No — drives or controls hardware device
Software IN a medical device (SiMD). Regulated as part of the parent device, not as SaMD.
Example: firmware in an infusion pump or pacemaker. Different regulatory treatment.
No — manufacturing or maintenance software
Not SaMD. Quality system software; regulated under QMS but not as a device.
Decision 1.2
Does an exemption or exclusion apply?
General wellness
Likely outside device scope. Low-risk software promoting healthy lifestyle without disease claims.
Step trackers, meditation apps, fitness goal-setters. FDA + TGA broadly aligned.
Clinical Decision Support — exempt criteria met
Non-device CDS. All four FDA criteria must be satisfied: not analysing signals/images; intended for HCP; provides recommendations with rationale; HCP can independently review.
21st Century Cures Act exemption. If any criterion fails, software is a device.
Electronic health record functions
Mostly exempt. Administrative, data display, transfer functions excluded; analytical/diagnostic functions are not.
No exemption applies
SaMD regulated. Proceed to classification.
Disease-specific wellness claims (e.g. "manages diabetes" vs "tracks activity") move software from wellness into device territory. Marketing language is regulatory evidence.
Output
01
Intended use statement · Boundary determination memo · Exemption analysis (if claimed)
STAGE 02

IMDRF Risk Categorisation

▼

SaMD risk is determined by two intersecting axes — the significance of information provided and the seriousness of the healthcare situation. The IMDRF matrix maps to local jurisdictions.

IMDRF SaMD Risk Categories — Significance × Healthcare Situation
Inform
Clinical Mgmt		 Drive
Clinical Mgmt		 Treat or
Diagnose
Non-serious
condition		 I I II
Serious
condition		 I II III
Critical
condition		 II III IV
Decision 2.1
What is the IMDRF category, and how does it map locally?
Category I
Low risk. TGA Class I · FDA Class I (often 510(k)-exempt) · EU MDR Class I.
Self-assessment routes common; lowest evidence burden.
Category II
Moderate risk. TGA Class IIa · FDA Class II (510(k)) · EU MDR Class IIa.
Conformity assessment with QMS audit; clinical evaluation required.
Category III
High risk. TGA Class IIb · FDA Class II/III (510(k) or De Novo) · EU MDR Class IIb.
Substantial clinical evidence; often new clinical investigation required.
Category IV
Highest risk. TGA Class III · FDA Class III (PMA) · EU MDR Class III.
Full pre-market approval; pre-submission meeting essential; rare for SaMD but applies to high-risk autonomous diagnostic AI.
Decision 2.2
Multi-jurisdiction strategy?
FDA-first (US market priority)
510(k) or De Novo pathway. Identify predicate; build substantial equivalence argument. De Novo for novel low-to-moderate risk.
Australian sponsors then use TGA Comparable Overseas Regulator pathway to leverage FDA clearance.
EU-first (CE mark via Notified Body)
EU MDR conformity assessment. Software-specific Notified Body required; harder than pre-MDR.
CE certificate accepted by TGA under CORP; supports global market access.
AU-first (local launch)
TGA pathway direct. Australia-specific SaMD classification rules apply; suitable for AU-focused clinical workflow tools.
TGA introduced dedicated SaMD classification rules in 2021; confirm current applicability.
Output
02
IMDRF category determination · Jurisdiction class mapping · Predicate analysis (if 510(k)) · Regulatory strategy memo
STAGE 03

AI/ML-Specific Considerations

▼

AI-enabled SaMD has its own regulatory layer — Good Machine Learning Practice, Predetermined Change Control Plans, and transparency requirements that don't apply to traditional rules-based software.

Decision 3.1
Locked or adaptive algorithm?
Locked algorithm
Conventional SaMD pathway. Algorithm fixed at deployment; updates require new submission.
Most currently cleared AI/ML devices are locked. Simpler regulatory model.
Adaptive / continuously learning
Predetermined Change Control Plan required. FDA framework — describe in advance what changes are anticipated, methods to implement, and how performance will be assessed.
PCCP enables modifications without new 510(k); TGA developing parallel framework.
Periodic retraining
Hybrid approach. Locked between releases; PCCP governs retraining triggers and validation methodology.
Decision 3.2
How will Good Machine Learning Practice be demonstrated?
Training data governance
Document dataset provenance, representativeness, demographic coverage. Address bias across age, sex, ethnicity, geography, disease severity.
FDA/Health Canada/MHRA jointly published GMLP guiding principles — global expectation.
Train/test separation
Independent test set + external validation. Site-stratified holdout, temporal validation, prospective validation tier.
Performance monitoring infrastructure
Real-world performance pipeline. Drift detection, accuracy monitoring, edge-case logging from day one.
Required for any AI/ML SaMD; mandatory for adaptive systems.
Decision 3.3
Transparency obligations to users?
Algorithm transparency labelling
Disclose model type, training population, performance metrics, limitations, intended use boundaries.
FDA Transparency Principles + EU AI Act high-risk category obligations overlap.
Output explainability
Confidence scores, contributing features, or visual saliency. Especially important for "drive clinical management" and "treat/diagnose" categories.
EU AI Act applies in parallel to medical device regulation. AI/ML SaMD typically falls into "high-risk" category triggering additional conformity assessment, risk management, and fundamental rights impact assessment obligations.
Output
03
Algorithm description document · Training data justification · PCCP (if adaptive) · Bias assessment · Transparency documentation
STAGE 04

Software Lifecycle & QMS

▼

SaMD must demonstrate engineering rigour through documented lifecycle processes. IEC 62304 and ISO 13485 form the backbone.

Decision 4.1
What software safety classification (IEC 62304)?
Class A — no injury possible
Minimal lifecycle documentation. Basic SDLC, version control, change management.
Class B — non-serious injury possible
Architecture documentation + unit testing required. Detailed design, integration testing, risk traceability.
Class C — death or serious injury possible
Full IEC 62304 compliance. Detailed architecture, software item segregation, full V&V, formal change control.
Most SaMD in IMDRF Category III/IV. Significant documentation burden.
Decision 4.2
Quality Management System approach?
ISO 13485 certified QMS
Standard global pathway. Accepted by TGA, EU, Health Canada, Japan, UK.
Often the first major investment for a SaMD startup; 6–12 months to build and certify.
MDSAP certified QMS
Multi-jurisdiction single audit. Covers AU, US, Brazil, Canada, Japan in one audit cycle.
Higher upfront cost but lower long-term audit burden for global SaMD.
QMS via contract manufacturer
Borrowed compliance. Acceptable for early stage; weak for valuation and licensing.
Output
04
IEC 62304 software lifecycle file · ISO 14971 risk management file · ISO 13485 QMS · Software architecture · V&V documentation
STAGE 05

Cybersecurity & Data

▼

Non-optional for SaMD. FDA refuses to consider submissions lacking cybersecurity documentation; TGA aligned with similar expectations.

Decision 5.1
Deployment architecture?
Cloud-hosted (SaaS)
Shared responsibility model. Document cloud provider security; demonstrate tenant isolation, encryption at rest and in transit, access logging.
Australian data residency (Privacy Act, My Health Records Act) may constrain provider choice.
On-premise hospital deployment
Hospital IT integration. Conform to local cybersecurity requirements (state health, LHD); document interoperability via HL7/FHIR.
Mobile / patient-facing
Device-level security + biometric authentication. Threat surface includes the patient's device; assume compromise possible.
Decision 5.2
Cybersecurity submission documentation?
Threat modelling (STRIDE or similar)
Document threats, vulnerabilities, mitigations. Required by FDA premarket cybersecurity guidance; expected by TGA.
Software Bill of Materials (SBOM)
Enumerate all components and dependencies. Track CVE exposure across third-party libraries; required for FDA cyber submissions.
Vulnerability management plan
Post-market patch and disclosure process. Coordinated vulnerability disclosure; defined SLAs for critical patches.
Decision 5.3
Privacy and data protection?
Australian Privacy Principles + state health records
Privacy Impact Assessment. Cover collection, storage, secondary use, breach notification under Notifiable Data Breaches scheme.
Multi-jurisdiction (GDPR, HIPAA, etc.)
Layered compliance. GDPR for EU users; HIPAA for US PHI; map cross-border data flow restrictions.
Output
05
Threat model · SBOM · Cybersecurity risk assessment · PIA · Vulnerability disclosure policy · Incident response plan
STAGE 06

Clinical Evaluation (IMDRF Three-Pillar)

▼

SaMD clinical evaluation has three distinct layers — valid clinical association, analytical validation, and clinical validation. Each requires different evidence.

Decision 6.1 · Pillar 1
Valid clinical association — is the output meaningful for the medical purpose?
Established association
Literature-based justification. Cite peer-reviewed evidence linking the parameter measured to the clinical condition.
Example: heart rate variability and arrhythmia risk; well-established physiological link.
Novel association
Original clinical study required. Generate evidence that the measured signal is genuinely associated with the target condition.
Common for novel AI biomarkers; substantial cost and timeline addition.
Decision 6.2 · Pillar 2
Analytical validation — does the software correctly process input to output?
Verification testing
Test against known inputs. Synthetic and curated real datasets; sensitivity, specificity, accuracy versus ground truth.
Performance characterisation
Edge case and stress testing. Input quality variation, signal noise, missing data, out-of-distribution detection.
Decision 6.3 · Pillar 3
Clinical validation — does the SaMD achieve the intended clinical outcome in real use?
Retrospective real-world data
Acceptable for some Category I/II. Curated historical datasets from intended-use population.
Watch for selection bias and ground-truth quality issues.
Prospective observational
Standard for Category II/III. Deploy in clinical setting; measure performance against reference standard.
Prospective interventional / RCT
Required for Category III/IV. Compare clinical outcomes between SaMD-supported and standard-of-care arms.
Australian CTN pathway applies; HREC + governance as per device trials.
Output
06
Clinical Evaluation Report covering all three pillars · Performance metrics by sub-population · Benchmarking versus predicate or standard of care
STAGE 07

Regulatory Submission Strategy

▼

Submission route depends on novelty, predicate availability, and target market sequence.

Decision 7.1
FDA pathway?
510(k) with strong predicate
Fastest path. Demonstrate substantial equivalence to legally marketed predicate device.
3–9 months typical; preferred for incremental SaMD.
De Novo (no suitable predicate, low–moderate risk)
Establishes new classification. Creates predicate for future devices in category.
9–18 months; common for novel AI/ML SaMD without prior cleared analogue.
PMA (Class III)
Highest burden. Full clinical evidence; rare for SaMD but applies to high-risk autonomous diagnostic AI.
Breakthrough Device Designation
Accelerated FDA review. Applies if SaMD addresses unmet need for serious/life-threatening condition.
Worth pursuing for novel diagnostic AI; secures FDA engagement.
Decision 7.2
Pre-submission engagement?
FDA Q-Submission
Pre-submission meeting. Free; clarifies expected evidence, classification, test methods.
Essential for Category III/IV and novel AI/ML; saves cycles later.
TGA pre-submission meeting
Engage for Class IIb+ or novel SaMD. Confirm classification, clinical evidence expectations, conformity assessment route.
EU MDR — early Notified Body engagement
Book NB capacity early. Software-specific NB capacity is constrained; can delay launch 12+ months.
Output
07
Pre-sub meeting minutes · Submission dossier (510(k) / De Novo / Technical File / ARTG) · Predicate comparison · Performance testing summary
STAGE 08

Post-Market & Change Management

▼

SaMD post-market is more demanding than hardware — software changes are frequent, AI models drift, and real-world performance must be monitored continuously.

Decision 8.1
Change control approach?
Each significant change → new submission
Traditional path. Modifications affecting safety/effectiveness trigger new 510(k) or substantial change notification.
Slow; incompatible with modern software release cadence.
PCCP-governed continuous improvement
Pre-authorised modification envelope. Make changes within PCCP scope without new submission; report at periodic intervals.
Game-changer for AI/ML SaMD; only viable if PCCP was filed initially.
Decision 8.2
Performance monitoring infrastructure?
Passive — adverse event reporting only
Standard PMS. TGA Medical Device Incident Reports; FDA MDR submissions.
Active — telemetry and outcomes
Embedded performance monitoring. Real-world accuracy, drift detection, sub-population disparities, near-miss logging.
Required for adaptive AI; best practice for all SaMD.
Registry integration
Link to disease registry. Long-term outcome capture supports reimbursement, label expansion, scientific publication.
Decision 8.3
Reimbursement strategy?
Procedure-linked (clinician uses SaMD)
MBS item via MSAC. Health economic evaluation comparing SaMD-supported vs standard workflow.
No dedicated AI/SaMD MBS item category yet — pioneers shape the precedent.
Direct sale to health service
LHD / hospital procurement. Value-based contracting; outcome guarantees increasingly common.
Consumer subscription
B2C model. Bypasses reimbursement but limits adoption depth; suits wellness-adjacent SaMD.
Private health insurer partnership
Insurer-funded deployment. Bupa, Medibank, HCF, nib innovation programs fund SaMD for population health benefit.
Output
08
Post-Market Surveillance Plan · Performance monitoring dashboard · PCCP execution log · PSUR · Reimbursement listing
SaMD Practitioner's Note

SaMD diverges from hardware devices in three structural ways that change strategy fundamentally. First, the boundary question is genuinely contested — many products that founders consider "not really a device" turn out to be regulated, and vice versa; get a regulatory opinion before you build, not after. Second, the IMDRF risk matrix often produces a higher classification than founders expect because "drive clinical management" of a "serious condition" is the default for most useful clinical software. Third, AI/ML adds an entire parallel regulatory stack (GMLP, PCCP, transparency, bias assessment, EU AI Act) that hardware devices simply don't face — and getting the PCCP wrong at initial submission forecloses continuous improvement for the product's entire commercial life. The Australian advantage: TGA accepts FDA-cleared SaMD via Comparable Overseas Regulator pathway, so for global ambitions, FDA-first is often optimal even for AU-founded teams.

Data & Privacy Law

SaMD products are among the highest-risk data processors in any jurisdiction — they collect sensitive health data, make or inform clinical decisions, and often operate across borders. In Australia, the Privacy Act 1988 and state health records laws govern collection, use, and disclosure of health information, with the TGA's cybersecurity guidance adding device-specific security obligations. For AI/ML SaMD, data governance extends to training data provenance, bias documentation, and re-training consent — requirements that intersect with the EU AI Act and FDA's AI/ML action plan. Structuring data handling architecture and consent frameworks before software build begins is essential; post-hoc remediation at regulatory submission is both costly and common. Full data law reference →