Physician’s Guide to SaMD: How Software Becomes a Medical Device

You have just signed an offer with a mid-size health tech startup. Cardiology-focused, lots of buzzwords: AI, remote monitoring, “digital therapeutics.” The CEO keeps saying, “We are just software, not a medical device, so we can move fast.”

Something in your gut says that is wrong.

This is the gap I want to close: what it actually means when software becomes a medical device, and how, as a physician, you should think, speak, and negotiate around Software as a Medical Device (SaMD).

---

1. Start with one hard question: “Is this SaMD or just software?”

The single most important distinction:

Software used around healthcare vs. software that is a medical device.

Regulators—FDA, EU MDR, others—care less about the tech stack and more about a very specific question:

Does the software perform a medical function on its own?

That means one of these:

• It takes medical data and outputs a diagnosis, risk score, treatment recommendation, or clinical management suggestion.
• It drives or controls another medical device (e.g., closed-loop insulin dosing).
• It replaces or meaningfully supplements a function that, if done incorrectly, can harm a patient (triage, dosing, image interpretation, arrhythmia detection).

If yes → you are in SaMD territory.

If no—if it is purely:

• administrative (scheduling, billing),
• communication-only (secure messaging),
• reference-only (static guidelines without patient-specific computation),

then you are likely not in SaMD land.

Let me give you concrete examples.

• Simple telehealth video platform:
  Not SaMD. It is a communications tool.

• App that reminds patients to take meds at certain times, without personalizing content:
  Usually not SaMD. It is a lifestyle/reminder tool.

• App that takes a patient’s BP readings and uses an algorithm to recommend specific medication adjustments:
  SaMD. It is influencing treatment decisions.

• AI that reads retinal images and classifies diabetic retinopathy severity:
  SaMD. It is performing diagnosis.

If your company’s product is influencing diagnosis, treatment, or clinical management in a patient-specific way, it is either:

1. Already a medical device (whether they admit it or not), or
2. About to become one as soon as they market it that way.

The “marketing” piece matters. If they say “for wellness” but their decks and sales calls clearly pitch “diagnostic accuracy comparable to cardiologists”—regulators do not care about the label; they care about intended use.

---

2. The regulators’ definition, translated into plain clinical English

You will hear this formal definition from the International Medical Device Regulators Forum (IMDRF), which FDA and others reference heavily:

Software intended to be used for one or more medical purposes that performs these purposes without being part of a hardware medical device.

Unpacked in clinical speak:

• “Intended to be used” = how it is described, promoted, and reasonably expected to be used in practice.
• “Medical purposes” = diagnose, prevent, monitor, treat, alleviate disease or injury, or modify anatomy/physiology for a medical reason.
• “Without being part of hardware” = it can run on a phone, server, or laptop; it is not physically built into a device housing.

So that AI ECG-interpretation model running on a cloud server? That is SaMD.
The embedded pacemaker firmware? That is software in a medical device, but not SaMD.

As a physician-advisor, when someone asks you to “sign off on the clinical logic,” you are being pulled squarely into SaMD territory.

---

3. Risk categories: not all SaMD is equally painful to regulate

Regulation intensity scales with clinical risk. A symptom-checker chatbot is not treated like closed-loop insulin dosing.

Regulators use two levers:

1. What is the software doing?

   • Informing a decision
   • Driving a decision
   • Driving therapy

2. Clinical context / condition

   • Critical (life-threatening, time-sensitive)
   • Serious (needs treatment to avoid long-term harm)
   • Non-serious (self-limited, low risk)

Example Function	Condition Type	Relative Risk
AI stroke triage from CT	Critical	High
EKG app detecting AFib for anticoagulation	Serious	Moderate
App suggesting OTC meds for seasonal allergies	Non-serious	Low
Diabetes insulin-dosing algorithm (closed loop)	Critical	Very high

High-risk SaMD means:

• More stringent evidence expectations (prospective trials, stronger comparators).
• Heavier quality management systems (QMS), documentation, and post-market surveillance.
• Much higher liability and recall exposure.

If you are joining a startup working on:

• Stroke imaging,
• Oncology diagnostics,
• Automated dosing,
• Cardiac rhythm diagnosis,

you are in high-risk SaMD land. You do not “move fast and break things” here without consequences.

---

4. The FDA view: CDS vs SaMD vs “enforcement discretion”

In the US, everything hinges on FDA’s definition of a “medical device” under the FD&C Act, and the carve-outs around Clinical Decision Support (CDS).

This is where founders muddle the distinction and drag physicians into messy gray zones.

The FDA allows some software to escape being regulated as devices if they meet all of these (simplified):

1. It is intended only to support or provide recommendations to an HCP about preventing, diagnosing, or treating a disease.
2. The HCP can independently review the basis for the recommendations (i.e., it is intelligible, not a black box).
3. It does not replace the clinician’s judgment, merely supports it.
4. It does not analyze medical images, signals, or patterns like ECGs, EEGs, imaging scans in a way that is black box and not reviewable.

So translating:

• A calculator that shows how it computes Wells score from clearly visible input fields = more likely non-device CDS.
• A deep learning model that says “Pulmonary embolism: high probability” based on imaging, without an interpretable chain = SaMD.

If your product:

• Hides the algorithm,
• Uses opaque AI models,
• Outputs a discrete decision (“start apixaban 5 mg BID”) rather than a transparent calculation,

then the FDA will almost certainly treat it as a device.

If the CEO keeps telling you, “We are only decision support, so we are exempt,” ask this very direct question:

“Can a clinician independently understand how we arrived at this recommendation, in a clinically meaningful way, from what the software shows?”

If the answer is no, you are dealing with SaMD, not exempt CDS.

---

5. How SaMD actually becomes cleared or approved: the regulatory pathways

You do not need to be a regulatory affairs professional. But you do need enough understanding to spot nonsense.

Most SaMD in the US goes through one of three device pathways:

1. 510(k) – “substantial equivalence”
   For moderate-risk (Class II) devices that are “similar enough” to an already marketed predicate device.

   Example: A new ECG rhythm analysis algorithm showing substantial equivalence to an earlier cleared ECG analysis product.

2. De Novo
   For novel, moderate-risk devices that have no predicate but are not high-risk enough to be Class III.

   Example: Early AI imaging diagnostics often went De Novo because there was no predicate.

3. PMA (Premarket Approval)
   For high-risk (Class III) devices. Often requires robust clinical trials, heavier design and quality systems, more intense review.

   Example: Closed-loop insulin delivery decisions, certain high-risk diagnostic platforms.

Approximate Distribution of SaMD FDA Pathways

Category	Value
510(k)	65
De Novo	25
PMA	10

You, as the physician, intersect with these pathways primarily via:

• Defining and defending the intended use statement (this drives classification).
• Designing the clinical validation plan (bench, retrospective, prospective studies).
• Interpreting and presenting clinical performance to investors, boards, and sometimes the FDA.

If leadership says “we will not need FDA clearance,” yet:

• Marketing slides claim diagnostic performance,
• Sales teams promise workflow-integrated treatment recommendations,
• They are piloting inside hospitals with high-acuity use cases,

then you have a mismatch between reality and regulation. That mismatch tends to blow up later, often right when the company tries to scale.

---

6. Clinical evidence: what “good enough” looks like for SaMD

This is where your expertise becomes lethal or useless. There is no middle.

For SaMD, evidence usually breaks into three pillars:

1. Analytical / technical validation
   “Does the software do what it claims, consistently, with this type of data?”

   Example: AI EKG algorithm tested across different devices, sampling rates, noise levels.

2. Clinical validation
   “In the target population, does the output relate to the clinical condition in a way that supports claims?”

   Sensitivity, specificity, ROC curves, predictive values.
   Proper ground truth (e.g., adjudicated by cardiologists, biopsy results, imaging gold standards).

3. Clinical utility / impact
   “Does using this software actually improve decisions or outcomes, or at least not make them worse?”

   This might be:

   • RCTs where clinicians with vs without the tool are compared.
   • Prospective cohort where workflow metrics (time to decision, error rates) are measured.
   • Pragmatic studies in real clinical settings.

For low-risk SaMD, you may get away with retrospective validation.
For high-risk SaMD (stroke triage, dosing), if there is no prospective evidence, it is shaky at best, negligent at worst.

When you are asked to “help with clinical validation,” clarify:

• Are we proving accuracy vs a gold standard?
• Are we proving non-inferiority vs clinicians?
• Are we proving outcome improvements?

And insist on clear definitions up front: target population, reference standard, performance thresholds that are clinically meaningful, not just statistically nice.

---

7. Continuous learning systems and the “change control” headache

SaMD that uses AI/ML has one nasty twist: the model is not static.

Classic devices: submit design → get cleared → manufacture identical devices.
SaMD with ML: models get retrained, datasets grow, performance may drift.

Regulators are catching up. The FDA has framework proposals for Predetermined Change Control Plans, which basically say:

• Define in advance: which parts of the model you can change post-approval, how, and within what guardrails.
• Commit to monitoring, real-world performance checks, and submission of updates if changes exceed that plan.

As a clinician, you must ask:

• “Are we retraining models in production based on live data?”
• “How do we know performance on minority subgroups does not degrade over time?”
• “If the model changes, how do users get notified that it is not the same algorithm as when we published our paper?”

This is not academic. I have seen AI models:

• Perform beautifully on early retrospective datasets,
• Then quietly lose performance months after deployment because of shifts in patient demographics, imaging protocols, or coding patterns.

SaMD companies that ignore post-market surveillance are setting themselves up for very public failure, especially once hospitals start comparing promised vs observed performance.

---

8. Your role as a physician inside a SaMD startup

Let me be blunt: physicians in these companies are often underused as clinical window dressing or overused as legal shields. Your job is to avoid both.

Here is where you must be specific and firm.

1. Intended use statements
   Be crystal clear, in writing, about:

   • What patient population(s) the product is for.
   • What specific decisions it supports or makes.
   • What clinical setting (outpatient vs ED vs ICU).
   • What it does not do.

   That line becomes the anchor for regulation, claims, and liability.

2. Labeling and on-screen language
   You should review:

   • Marketing materials for overreach (“diagnostic tool” vs “risk stratification aid”).
   • In-app phrasing (“Start DOAC now” vs “Consider anticoagulation in line with guidelines if no contraindications”).

   A single word like “diagnose” vs “suggest” can shift regulatory classification.

3. Human factors and workflow
   SaMD that forces absurd workflow changes will not get used, regardless of regulatory status.

   You need to:

   • Map actual clinical workflow: when, where, and by whom decisions are made.
   • Ensure alerts, flags, or recommendations are timely and not buried.
   • Prevent alert fatigue and “cry wolf” scenarios that turn your product into background noise.

4. Clinical governance
   Push for:

   • A medical safety board or committee, including external clinicians.
   • Formal processes for reviewing adverse events, user complaints, and performance anomalies.
   • Explicit escalation paths when the product’s output conflicts with clinical common sense.

If a founder tells you, “We do not need that level of process; we are just software,” translate that as: “We have not internalized that we are working on a medical device.” That is your signal to either educate them or walk.

---

9. Liability and malpractice: how exposed are you personally?

Here is where most physicians wake up fast.

If:

• You are heavily involved in designing the clinical logic or decision pathways.
• You are featured in marketing as the “Chief Medical Officer” who “validated” the system.
• You sign off on claims about safety or accuracy.

Then you have some exposure. Maybe not classic malpractice yet, but reputational, legal, and regulatory exposure.

SaMD-related harm can trigger:

• Product liability suits against the company.
• Hospital investigations if integrated into their systems.
• Regulatory action if claims exceed evidence.

Your protection levers:

• Clear job description and scope of clinical responsibility.
• Indemnification language in your contract.
• D&O insurance coverage (ask specifically about coverage for clinical leadership).
• Documented dissent if you objected to unsafe features or overreaching claims.

And practically: do not let your name be used to sanitize reckless decisions. If the company insists on going to market with minimal validation on a high-risk use case, write your objections down. Email. Board minutes. Something you can point back to.

---

10. Business, reimbursement, and adoption realities for SaMD

Even if the product clears FDA, that is not the finish line. Physicians underestimate this, founders often ignore it.

For a SaMD startup to survive, they must also:

• Fit into a payment model: CPT codes for digital diagnostics, RPM codes, per-member-per-month, or value-based arrangements.
• Demonstrate ROI to hospitals or payers: reduced admissions, shorter LOS, fewer unnecessary imaging studies, improved throughput.
• Overcome integration hurdles: EHR integration (Epic, Cerner) is not optional if you are serious.

Regulatory clearance without:

• A clear billing pathway,
• Operational integration,
• Clinician champions who trust the tool,

is a nice press release, not a business.

Your role is to sanity-check claims like:

• “This tool will reduce readmissions by 20%” → ask: based on what data, in which population?
• “Hospitals will just pay because it is innovative” → ask: whose budget, what line item, what are they cutting to fund this?

You know the reality of budget committees and innovation fatigue in hospitals. Use that.

---

11. Practical red flags for you as a post-residency physician joining a SaMD startup

You are not a regulatory lawyer, but you have common sense and medical training. Use it.

I would walk you through a simple mental triage.

Is This Startup Building SaMD?

Step	Description
Step 1	Does software affect diagnosis or treatment?
Step 2	Likely not SaMD
Step 3	Is output interpretable and basis visible?
Step 4	May qualify as non-device CDS
Step 5	Likely SaMD
Step 6	Is condition serious or critical?
Step 7	High risk SaMD - heavy regulation
Step 8	Lower risk SaMD - lighter but still regulated

Red flags in conversations:

• “We are just wellness, but we will prove we are as accurate as CT-angiography for PE diagnosis.”
• “FDA is slow; we will just go direct-to-consumer and call it informational.”
• “We do not need post-market monitoring; our model improves itself automatically.”
• “Our physician advisors are here mostly for credibility, not to slow us down with clinical nitpicking.”

If you hear these, proceed carefully.

You want to hear instead:

• “We have a regulatory roadmap and know which pathway we are targeting.”
• “We have defined narrow, concrete intended use and claims.”
• “We are planning rigorous validation studies in partnership with clinical sites.”
• “We have a safety and escalation policy when our output conflicts with clinical judgment.”

That is the difference between a serious SaMD company and a hype engine.

---

12. How to position yourself as a physician SaMD expert (and get paid properly)

You are post-residency. You have clinical credibility. If you learn this domain, you become rare and valuable fast.

Concrete steps:

1. Learn the vocabulary: SaMD, CDS, Class II/III, 510(k), De Novo, PMA, intended use, labeling, human factors, post-market surveillance.
2. Read a few real FDA summaries (for AI imaging, ECG analysis, digital therapeutics) to see how regulators think. These documents are gold.
3. On any startup call, ask immediately:
   • “What is our intended use statement?”
   • “Which regulatory pathway are we planning?”
   • “What is our evidence plan for clinical validation?”
     The quality of the answers will tell you everything about their maturity.

Negotiate accordingly. If they are high-risk SaMD, and you are essentially architecting clinical safety and credibility, that is not a trivial advisory role. That is a core function. Structure your equity and compensation to match the liability and responsibility.

---

FAQ (exactly 5 questions)

1. How do I quickly tell if a “wellness” app is actually a medical device in disguise?
Look at what it claims to affect. If “wellness” language is paired with specific disease names, diagnostic claims, or treatment recommendations—especially if they use labs, images, or signals as inputs—it is very likely SaMD. An app that says “improves heart health” is softer. An app that says “detects atrial fibrillation and guides anticoagulation decisions” is a medical device, regardless of the wellness branding.

2. Can a startup just launch SaMD in the US without FDA clearance and deal with it later?
They can try. Many do. But if they are clearly making diagnostic or treatment claims, they are exposed to enforcement actions, hospital compliance pushback, payer resistance, and liability risk. Hospitals increasingly refuse to implement clinically impactful software without regulatory clearance. If you join a company planning to “fly under the radar,” assume you are signing up for a later regulatory crisis.

3. If I use SaMD in my own practice, am I liable if it makes a wrong recommendation?
Yes, at least partially. You are still responsible for the clinical decision. If the tool is clearly flawed (e.g., nonsensical outputs, known issues) and you rely on it blindly, that is hard to defend. Using an FDA-cleared tool as support and documenting your independent judgment is much safer. The company may face product liability, but that does not fully shield you.

4. Do all AI tools in healthcare count as SaMD?
No. AI used for staffing optimization, OR scheduling, revenue cycle, or non-clinical analytics is not SaMD. AI that reads radiology images, interprets ECGs, stratifies sepsis risk, or recommends specific treatments typically is. The test is not “AI or not,” but “Does it directly affect patient diagnosis or management?”

5. If a SaMD product is labeled “for research use only,” does that avoid regulation?
Only if it is genuinely used for research, without being used to guide actual patient care decisions. The moment a hospital uses the output to make real-world treatment or diagnostic calls, the “research only” label becomes fiction. Regulators, plaintiffs, and risk management teams look at real-world use, not just the sticker on the box.

---

Key points to leave you with:

1. If software touches diagnosis or treatment decisions in a patient-specific way, assume it is SaMD until proven otherwise.
2. Your leverage as a physician inside a SaMD startup comes from owning the intended use, clinical validation plan, and safety governance. Use it.
3. Hype and hand-waving about “just software” are not minor red flags; they are early signs of regulatory and clinical trouble.