Digital Health Meets Red Tape: What Pharma Can Learn from Software as a Medical Device

Pharma is rushing to add digital components to drugs — companion apps, data platforms, AI-enabled decision support — but software does not follow the same regulatory logic as tablets and injectables. In many projects, the software portion crosses into regulated medical device territory (Software as a Medical Device, or SaMD). Teams that treat software as a side feature discover late that it carries its own classification, quality, and post‑market obligations. This article translates the SaMD playbook for pharma leaders so you can plan evidence, timelines, and risk from day one.

2025 Market Snapshot: Why This Matters Now

The FDA’s public list now includes over 1,000 AI/ML‑enabled medical devices cleared, authorized, or approved in the US — a sharp rise that signals how quickly software‑driven products are entering care pathways.

Digital health tools continue to proliferate, with hundreds of thousands of apps in circulation; increasingly, biopharma uses them to collect real‑world data and support adherence, safety monitoring, and outcomes.

1) What Is SaMD — and Why Pharma Should Care

SaMD is software intended for a medical purpose without being part of a hardware device. Examples include AI algorithms for diagnosis, patient‑facing apps that guide therapy, and decision‑support tools for clinicians. Pharma touches SaMD when:

• Companion apps are paired with therapies.
• Real‑world data platforms support regulatory or HTA filings.
• Algorithms are embedded in drug‑device combinations (e.g., connected inhalers or injectors).

If you cross into SaMD, you inherit device rules — classification, software lifecycle documentation, usability engineering, risk management, and post‑market surveillance.

2) SaMD Is Not “Just Software” — It’s a Regulated Product

Core expectations include:

• Quality & lifecycle: ISO 13485 for the QMS and IEC 62304 for software lifecycle.
• Usability: IEC 62366 human‑factors evidence when patients or HCPs interact with the UI.
• Risk: ISO 14971 risk management tied to intended use and harm.
• Market specifics: FDA’s risk‑based pathways (510(k), De Novo, PMA) and EU MDR classification (notably Rule 11 for software). Plan these from the outset — bolting them on later is what causes delays and rework.

3) Global Regulatory Perspective at a Glance

United States (FDA): Risk‑based premarket pathways. For AI/ML‑enabled SaMD, FDA finalized guidance on Predetermined Change Control Plans (PCCPs), which allow sponsors to pre‑agree how models may be updated after clearance/approval. The agency has also published Good Machine Learning Practice (GMLP) and transparency principles to manage bias, performance, and communication to users.

European Union (MDR): Rule 11 pushes much clinical‑decision software into class IIa/IIb/III, triggering notified‑body review and robust clinical evidence. Updated MDCG guidance clarifies qualification and classification of software under MDR/IVDR.

EU AI Act: AI used in medical devices will generally be treated as “high‑risk,” layering AI‑specific requirements (data governance, transparency, risk management, human oversight) on top of MDR/IVDR, phased in after entry into force.

Pharma‑specific (PDURS): FDA’s draft guidance on Prescription Drug Use‑Related Software (PDURS) explains how software outputs disseminated by a drug sponsor can be regulated as drug labeling — relevant when your software is tied to a medicine rather than regulated as a device.

4) Case Notes: Pharma–Digital Pairings in Practice

Connected respiratory: Propeller Health’s sensors and apps have been paired with major inhaler brands to support adherence and symptom tracking.

Diabetes ecosystems: Roche’s acquisition of mySugr brought app‑centric diabetes management into a large pharma/device portfolio, blending software, meters, and services.

Digital pill lessons: ABILIFY MYCITE (Otsuka + Proteus) showed how drug‑device‑software combinations can achieve approval but still face adoption, privacy, and value challenges.

Prescription digital therapeutics: Partnerships around software treatments (e.g., reSET/reSET‑O) illustrated both regulatory viability and commercial headwinds.

5) Five Practical Lessons Pharma Should Borrow from SaMD Development

1. Classify early. Apply FDA criteria and MDR Rule 11 at concept stage; write down intended use and the clinical decisions your software influences.

2. Build the QMS backbone. Set up design controls, risk files, and software lifecycle processes before you code beyond a prototype.

3. Treat usability as safety. Plan formative and summative testing; tie UI decisions to risk controls and residual risks in your ISO 14971 file.

4. Validate your data pipeline. Document data sources, quality, representativeness, and privacy safeguards; this underpins both AI safety and trust.

5. Design for updates. For AI/ML, anticipate model updates with clear change protocols (e.g., PCCP in the US) and a post‑market monitoring plan.

6) AI/ML: The Failure Modes to Plan For

Algorithm drift: Real‑world performance can degrade as populations, practice patterns, or sensors change. Monitor and retrain under a controlled plan.

Bias & representativeness: Non‑representative training data can harm sub‑populations. Set bias metrics, pre‑specify mitigations, and be transparent about limits.

Explainability & transparency: Provide clear information to users about intended use, inputs, outputs, and known failure modes; align with published transparency principles.

Human‑AI teaming: Define what the human decides vs. what the software suggests; design interfaces that reduce, not add, cognitive load.

7) After Launch: Lifecycle, Cybersecurity, and Surveillance

• EU MDR post‑market: Maintain a PMS plan; for class IIa/IIb/III, prepare Periodic Safety Update Reports (PSURs) that synthesize safety and performance data.

• US expectations: Monitor real‑world performance; for cyber devices, address secure design, vulnerability management, coordinated disclosure, and provide a software bill of materials (SBOM) in line with current FDA expectations.

• Update management: Tie software patches and model updates to risk assessment, verification/validation, and user communications. Document everything.

8) Ethics, Privacy, and Patient Trust

Be explicit about what data you collect, why, and how it’s protected. Ensure GDPR/HIPAA alignment, minimize data where possible, and communicate benefits and risks plainly. Trust is a design choice — build it into onboarding, consent flows, and labeling.

9) A Checklist for Pharma Teams Entering SaMD

Conclusion

Software is now part of therapy. The teams that treat SaMD as a regulated product from the start — with clear classification, fit‑for‑purpose evidence, and a plan for updates and surveillance — will ship faster and with fewer surprises.

References

1. FDA – AI/ML‑Enabled Medical Devices list; PCCP guidance; GMLP & transparency principles.

2. EU – MDR Rule 11 and MDCG guidance on software; EU AI Act (high‑risk obligations).

3. Case notes – Otsuka/Proteus ABILIFY MYCITE; Propeller Health partnerships; Roche acquisition of mySugr; market analyses on digital health adoption.