Understanding SaMD: Regulated medical device software vs. consumer digital health products

TL;DR
Digital healthcare has exploded. Tracking, coaching, diagnostics, monitoring, and even therapy are available in an app, readily accessible on your smartphone. At the heart of this digital transformation is software-as-a-medical-device, or Software as a Medical Device (SaMD). Digital health now spans a wide spectrum, from lifestyle and wellbeing tools to clinical software that can influence diagnosis, treatment, or monitoring. The challenge is that these products can look similar on the surface, even though they sit in very different categories from a regulatory, evidence, and go-to-market perspective.

Before you decide how to build, validate, and commercialize your product, you need to answer one foundational question: What is the intended purpose of the software: Wellbeing/lifestyle, or a medical purpose?

That distinction drives everything else: product claims and UX language, evidence expectations, engineering controls, and commercial strategy. In this guide, we’ll define SaMD and consumer digital health, then unpack where the boundary sits, and why teams get pulled into regulatory gray zones as products evolve.

From AI-powered diagnostics to remote patient monitoring and digital therapeutics (DTx), SaMD products are reshaping how care is delivered, accessed, and scaled. In fact, the global medtech market has already surpassed $680 billion in 2025 and is projected to reach $1.3 trillion by 2029, with SaMD among its fastest-growing categories. 

But not every “health app” is created equal. The line between regulated medical device software and consumer digital health apps has never been more important to understand.

What is SaMD?

Software as a Medical Device is software intended to achieve a medical purpose. For example, diagnosing, preventing, monitoring, predicting, treating, or alleviating disease or injury. SaMD is software that carries a medical responsibility. It may:

• interpret patient data to produce clinical insights
• drive or influence treatment decisions
• monitor a medical condition
• deliver a therapeutic intervention (e.g., digital therapeutics)

Real-world examples:

LumineticsCore (formerly IDx-DR): an FDA-authorized autonomous AI system for detecting more-than-mild diabetic retinopathy from retinal images.

reSET (Pear Therapeutics): an FDA-authorized prescription digital therapeutic for substance use disorder (CBT-based).

EndeavorRx (Akili Interactive): an FDA-authorized digital therapeutic to improve attention function in children with ADHD.

BlueStar (Welldoc): an FDA-cleared software system to support diabetes self-management (including versions with insulin dosing-related functionality).

Viz.ai ContaCT: FDA De Novo–classified stroke detection/notification software supporting large vessel occlusion identification and care team alerting.

Propeller platform: FDA-cleared digital respiratory health platform used to support asthma/COPD management alongside connected inhalers.

What is a consumer digital health product?

Consumer digital health products include wellness and lifestyle tools that may collect health-related data, but do not make medical claims and do not guide clinical decisions via software. Common examples include:

• fitness and activity tracking
• sleep journals and meditation
• nutrition logging
• general "wellbeing coaching" without diagnostic/therapeutic claims

These products can still be serious businesses, but they typically live in direct-to-consumer and employer wellness channels, with different evidence expectations and lower regulatory overhead.

Real-world examples:

Fitbit: consumer wearables and app for activity, sleep, stress, and health metrics tracking.

Strava: GPS-based fitness tracking with social/community features for running and cycling.

MyFitnessPal: nutrition and calorie tracking app for food logging and habit-building.

Headspace: mindfulness and meditation app with tools for stress, focus, and sleep.

Calm: meditation and sleep app featuring Sleep Stories, guided content, and relaxation tools.

Noom: behaviour-change and weight management app combining tracking with coaching.

What are the go-to-market and commercial implications of choosing SaMD vs. consumer?

This distinction shapes commercial opportunities in profound ways. SaMD has a higher burden, but also a higher ceiling. This category unlocks:

• reimbursement pathways
• provider and payer contracts
• clinical adoption within care pathways
• deeper enterprise integrations and longer-term retention

However, these advantages come with a downside: the cost of SaMD development includes significantly higher upfront investment in evidence generation, regulatory preparation and quality systems, making the commercial rewards inseparable from a heavier development burden.

By contrast, consumer digital health can move faster, especially if they avoid medical claims and clinical workflow dependencies. The trade-off is that they face tougher retention economics:

• saturated markets and low switching costs
• higher marketing spend to acquire and retain users
• limited enterprise trust if positioned as "nice-to-have wellness"
• fewer routes into reimbursed care pathways

Direct-to-consumer (DTC) and employer distribution are common for wellness products, but DTC can also be a viable route for SaMD, depending on the indication, risk profile, claims, and local market rules.

Real-world examples:

Commercial pathways for SaMD and digital health vary by country and depend less on whether something is “prescription” and more on how it is adopted and paid for (clinician-led, employer-led, payer-led, or direct-to-consumer).

• Germany: DiGA provides a defined route for reimbursed digital health applications where eligibility criteria and evidence requirements are met.
• U.S: Payment pathways are fragmented. Some products scale through provider organizations and payers, others through employer models or DTC. Reimbursement is possible in certain contexts, but it typically requires alignment with clinical workflows, documentation, and operational readiness (not necessarily “prescription-only” distribution).

SaMD and wellness products have different scaling dynamics and unit economics. Wellness products can often scale faster through DTC distribution, but typically face higher acquisition costs and greater competition. SaMD can strengthen clinical credibility and support certain enterprise- or payer-led routes, but adoption can be slower and require greater investment in evidence, quality, and operational readiness.

While avoiding medical claims can reduce regulatory burden, DTC is a distribution model that can be used for both wellness and SaMD, so the key variable is intended purpose and claims, not channel. For a deeper look at how SaMD and digital health products are generating sustainable revenue, read New Value-Based Business Models in Healthcare.

Star assists in connecting SaMD strategy to commercial reality, validating which pathways are viable to avoid over-investment in the wrong model. 

How do regulators decide what counts as medical device software?

Regulators and regulatory frameworks such as the FDA medical software guidance / FDA 510(k) (US) and the EU Medical Device Regulation (MDR) don’t only look at features. They look at the intended purpose, which is expressed through:

• product labeling
• marketing claims
• UX copy and in-app language
• outputs and call-to-actions
• who the product is for (consumer vs clinician)
• how it's used (lifestyle vs care pathway)

Teams often get caught in “gray zones”: you can build something that looks like a wellness tool, then accidentally describe it like a medical device. Because regulators assess intended purpose through claims, UX language, and outputs, Star often helps teams pressure-test messaging and experience design early, before small wording choices become expensive classification problems. 

But, before defining the gray zones, let’s look at some of the common questions regulators ask. 

1. Does your software make clinical claims or clinical interpretations?

• A common threshold is data display vs. medical interpretation.
• Wellness: “Here is your sleep duration and sleep stages.” (Informational)
• Potential SaMD: “We screened you for sleep apnea risk.” (Diagnostic implication)
• Even subtle phrasing matters. “Detect,” “diagnose,” “treat,” “reduce symptoms,” “clinical-grade,” “medically proven,” or “recommended care” can shift your classification.

2. What’s the patient safety risk if the software is wrong?

If failure could lead to harm, delayed treatment, or misled clinical decision, regulators expect stricter controls. Regulators apply risk-based frameworks that classify devices by severity of potential harm. For example, a software bug in a step counter might cause frustration, but a similar error in insulin dosing software could be life-threatening.

3. Are you handling health data, or operating in a clinical data context?

Any app, wellness or SaMD, may handle health data. Handling sensitive health data increases your privacy and security obligations regardless of classification. If you integrate with EHRs, operate in clinical environments, or handle data flows that can affect clinical decisions, you should expect higher scrutiny across privacy, security, and operational assurance.

If you handle health data, you may have obligations under frameworks such as GDPR (where applicable) and, in the U.S., HIPAA when operating as/with covered entities and business associates. These requirements apply based on data context and roles, not only on whether a product is classified as SaMD.

Even if you’re not classified as SaMD, privacy obligations still apply if you process personal data, and health data is typically treated as sensitive with additional requirements under GDPR.Even if you’re not classified as SaMD, you are still liable to privacy requirements under HIPAA and GDPR if you process PHI or Personally Identifiable Information (PII).

4. Are you integrating into clinical workflows?

If the software is designed for clinician use, hospital integration, IoMT ecosystems, or EHR connectivity, regulation is mandatory.

Clinical integration demands interoperability with standards like HL7 and FHIR, traceability of data and system reliability under real-world loads. Consumer products, by contrast, typically function as stand-alone tools or sync data through non-clinical APIs. The deeper the integration into healthcare delivery, the stronger the regulatory obligations.Regulators such as the FDA and the European Commission define SaMD consistently: it’s software that has an intended medical purpose, for example diagnosing, preventing, monitoring, predicting, treating or alleviating disease or injury. It performs its medical function independently of any specific hardware device, though it may connect to or interact with devices or cloud services. Labels may differ but the core principle doesn't: if software is intended for a medical purpose, it’s regulated as a medical device.

Regulators such as the FDA and the European Commission define SaMD consistently: it’s software that has an intended medical purpose, for example diagnosing, preventing, monitoring, predicting, treating or alleviating disease or injury. It performs its medical function independently of any specific hardware device, though it may connect to or interact with devices or cloud services. Labels may differ but the core principle doesn't: if software is intended for a medical purpose, it’s regulated as a medical device.

Boundary cases and gray zones

Gray zones happen when products sit at the boundary between wellness and medical purpose, often because technology evolves faster than clear category labels. In these cases, the same core experience (tracking, insights, nudges) can tip into regulated territory depending on intended use, claims, and how the output is acted on. Many teams don’t “make a mistake” so much as expand a product’s value over time, by adding smarter inference, deeper integration, or more directive guidance, until the risk profile changes.

Typical scenarios:

• A wellness product starts making medical inferences - Example: a fitness tracker that begins flagging atrial fibrillation risk.
• Decision support becomes decision direction - Example: a clinician tool that shifts from “optional insight” to “recommended treatment plan.”
• A prototype becomes patient-facing without strategy reset - Example: research software rebranded for clinical use, without fully revisiting claims, evidence or obligations. 

These blurred lines are where companies most often stumble and where early strategic clarity makes the difference between smooth approval and costly setbacks.

For products in these gray zones, set a regulatory strategy early. If you conclude that your solution is not a medical device, document why not. Then, mapping which features could shift the product into regulated territory helps prevent surprises, whilst supporting smoother interactions with regulators.

A quick comparison: SaMD vs. consumer digital health

Getting started with SaMD

Consumer health apps will continue to improve but regulated SaMD — approved, integrated, secure, reimbursable — will set the standard in care pathways. For many teams, the strategic question is when (not whether) to step into SaMD and build toward regulatory grade.

While every company's product development journey and operational reality are different, their horizons should be set on regulatory approval, if not now, then in the future. This is especially true as the lines between consumer and regulated medical devices start to blur. We’re increasingly seeing medical-grade devices become more consumerized and user-friendly.

However, the same cannot be said for consumer products. While simultaneously growing more sophisticated, they’ll run into functional limitations imposed by the FDA, EU and other authorities that form the basis of medical device classification.

Sooner than later, people will have the option between similar products: a consumer version with limited functionality and a regulated one that collects high-quality data, is FDA-approved, reimbursable, integrates into a broader health technology ecosystem while also likely being able to diagnose and even treat. The choice will be clear.

Star’s consultative perspective: think and build toward the right endgame

At Star, one of the first conversations we have with digital health teams is whether regulated development is the right strategic path, and if so, what it means for product scope, evidence, architecture, and go-to-market. We bring together product strategy, experience design, and regulated engineering to reduce rework, accelerate decision-making, and create software that’s credible in the real world.

That typically includes:

• early SaMD vs wellness positioning support
• human-centered UX for patient and clinician workflows
• rapid prototyping and validation
• regulatory-grade engineering foundations (security, traceability, audit readiness)
• interoperability and integration planning for clinical contexts

If you’re building or evolving a digital health product that could cross into SaMD, book a call with Star. We’ll help you pressure-test your intended use, clarify what “regulatory-grade” means for your roadmap, and align product scope, architecture, and go-to-market to the endgame you’re targeting.

FAQs