When “Support” Becomes “Treatment”: Navigating the SaMD Grey Zone
A review of the whitepaper from Avegen and 8fold Governance
This is Clinical Product Thinking 🧠, your weekly newsletter featuring practical tips, frameworks and strategies from the frontlines of clinical product.
Good afternoon friends, this is issue No. 027. This week we’re diving back into regulation with a breakdown of one of the biggest grey areas in digital health: when patient support apps cross into medical device territory.
Many teams in digital health don’t set out to build a medical device but somewhere between helping patients manage and clinicians decide, they cross that line. Sometimes without even realising it.
That’s exactly what the whitepaper from Avegen and 8fold Governance is tackling: the grey zone where an unregulated patient support app becomes a medical device, designed for treatment. Highly recommend you check it out here.
The Problem
Companies building patient support tools often run into the same catch-22:
Build something too light, and it likely won’t change outcomes.
Build something too clinical, and suddenly you’re in regulated territory.
So teams risk ending up with half-baked solutions that sound great on paper but collapse in clinical reality, watered down until they’ve lost real impact.
The difficulty lies in recognising exactly where the line sits between wellness and medical device, and designing accordingly.
If you’re new to medical device regulation, I wrote a 101 for CPMs that you can check out here.
The Grey Zones
The whitepaper expertly lays out a number of grey zones in patient support apps that I’ve summarised below:
1. The AI Analysis Line
The scenario:
You’ve built an an app to support people with digestive health issues. It includes a food diary and symptom tracking to help users understand possible food triggers. The CEO wants to use AI to analyse patterns and generate personalised insights.
❓Ask yourself the question: Is this a medical device?
The Answer:
This one’s subtle. The moment the app moves from tracking to interpreting health data, you’re moving towards regulated territory.
✅ Not SaMD: Logging food and symptoms side-by-side.
⚠️ Grey zone: Showing correlations (”Your symptoms spike after dairy”) - the app is interpreting health data.
🔴 Definitely SaMD: AI-driven suggestions of causal links used for clinical decisions.
👉 Navigation approach:
Presentation matters: Use language like “patterns observed” rather than “this food causes your symptoms”
Document your intended use: Position the app as a wellness tool to support lifestyle management, not as diagnostic.
Mitigate: Ensure you control and limit any medical claims and include guidance that the app is not a substitute for medical advice.
2. The Educational Content Edge
The scenario:
A digital health programme included a patient-facing “Learn” module with educational materials on exercise, nutrition, and smoking cessation alongside condition-related information to improve engagement with a rehabilitation process.
❓Ask yourself the question: Is this a medical device?
The line:
General health and lifestyle education is usually fine. But when educational content is condition-specific and provided within the context of a structured treatment programme, there’s a risk it may be perceived as part of the therapeutic intervention.
✅ Not SaMD: General health and wellness resources
⚠️ Grey zone: Condition-related information in a rehab programme
🔴 Potentially SaMD: Educational content framed as delivering therapy
If the educational content is presented as prescriptive instructions or framed as delivering therapy, the feature could meet the definition of a medical device.
👉 Navigation approach:
Frame intent: Document that the Learn module is educational only aimed at patient empowerment, not as a treatment or therapeutic.
Limit scope: Present content in an informational way without personalisation based on health data.
Content governance: Be mindful of not overstepping in content language and avoid declarative statements like ‘use this treatment’.
3. The Behaviour Change Boundary
The scenario:
You’ve build a digital intervention aimed at people living with chronic fatigue or long COVID. The app includes fatigue tracking through self-check-ins as well as exercise, balance and cognitive behavioural content and allows communication with healthcare professionals.
❓Ask yourself the question: Is this a medical device?
The line:
General health and wellness education is usually fine. But when behaviour change is tied to disease-specific outcomes and delivered as part of a structured therapy, you could have built yourself a medical device.
✅ Not SaMD: Generic wellness tips not tied to specific conditions
⚠️ Grey zone: Condition-related educational content within a rehab programme
🔴 Definitely SaMD: Evidence-based therapeutic intervention intended to reduce clinical symptoms
By providing insights into fatigue patterns, supporting behavioural interventions, and facilitating healthcare professional engagement, the app functioned as a therapeutic tool to manage a disease-related symptom. Classification: Class I medical device.
4. The Clinician Dashboard Dilemma
The scenario:
You’ve built a clinician-facing portal that consolidates patient-reported data into progress dashboards.
❓Ask yourself the question: Is this a medical device?
The line:
If those dashboards are used for remote monitoring and inform clinical decisions about care management, you’re building a medical device, even if the patient-facing side feels like “just tracking.”
✅ Not SaMD: Exchange secure messages with clinical staff
🔴 Definitely SaMD: Scoring or dashboards with analysis that directly support care management decisions
If a clinician relies on your dashboard output to adjust medication, escalate care, or change treatment plans, you’re looking at a medical device.
The Clinical Product Thinking Takeaway
A clinical product manager’s job is not to act as the QARA or head of regulatory but knowing when a product becomes a medical device will be enormously helpful.
Before you build, ask yourself the question:
Could this feature drive a clinical action?
If you answered “yes”, you’re entering SaMD territory and need to plan accordingly.
We don’t need any more unregulated medical devices. We need safe, smart, clinically grounded tools that patients and clinicians can trust.
The future of digital health isn’t about avoiding SaMD. It’s about designing for it intelligently.
That’s the public post for this week. See you next time! 👋
🤝 Work with me | 📅 Attend an event | | ✍️ Send a message
Written by Dr Louise Rix, Head of Clinical Product, doctor and ex-VC. Passionate about all things healthcare, healthtech and clinical product (…obviously). Based in London. You can find me on Linkedin.
Made with 💜 for better, safer HealthTech.
[NEW] Want to Go Deeper? 👇 Join Paid
Founding Members get access to additional resources, frameworks and recordings plus a free 30-min personal advisory session with me to accelerate your next move.
Limited to 30 members only.
