Salute digitale contro burocrazia: cosa può imparare la pharma dal Software as a Medical Device

Pharma si sta affrettando ad aggiungere componenti digitali ai farmaci — app companion, piattaforme di dati, supporti decisionali abilitati dall’AI — ma il software non segue la stessa logica regolatoria di compresse e iniettabili. In molti progetti, la parte software entra nel territorio dei dispositivi medici regolamentati (Software as a Medical Device, o SaMD). I team che trattano il software come una funzionalità secondaria scoprono tardi che esso comporta una propria classificazione, qualità e obblighi post‑commercializzazione. Questo articolo traduce il playbook SaMD per i leader pharma in modo che possiate pianificare evidenze, tempistiche e rischio fin dal primo giorno.

Instantanea del mercato 2025: perché è importante ora

L’elenco pubblico della FDA ora include oltre 1.000 dispositivi medici abilitati AI/ML autorizzati, approvati o cleared negli USA — un aumento netto che segnala quanto rapidamente i prodotti guidati dal software stiano entrando nei percorsi di cura.

Gli strumenti di salute digitale continuano a proliferare, con centinaia di migliaia di app in circolazione; sempre più spesso le aziende biopharma le utilizzano per raccogliere real‑world data e supportare l’aderenza, il monitoraggio della sicurezza e gli outcome.

1) Cos’è il SaMD — e perché la pharma dovrebbe interessarsene

SaMD è il software destinato a uno scopo medico senza far parte di un dispositivo hardware. Esempi includono algoritmi AI per la diagnosi, app rivolte ai pazienti che guidano la terapia e strumenti di supporto decisionale per i clinici. La pharma entra in contatto con il SaMD quando:

• Le app companion sono abbinate a terapie.
• Piattaforme di real‑world data supportano dossier regolatori o HTA.
• Algoritmi sono incorporati in combinazioni farmaco‑dispositivo (es. inalatori o iniettori connessi).

Se entrate nel campo del SaMD, ereditate le regole dei dispositivi — classificazione, documentazione del ciclo di vita del software, ingegneria dell’usabilità, gestione del rischio e sorveglianza post‑mercato.

2) Il SaMD non è “solo software” — è un prodotto regolamentato

Le aspettative fondamentali includono:

• Qualità e ciclo di vita: ISO 13485 per il QMS e IEC 62304 per il ciclo di vita del software.
• Usabilità: evidenze di fattori umani secondo IEC 62366 quando pazienti o HCP interagiscono con l’interfaccia utente.
• Rischio: gestione del rischio secondo ISO 14971 collegata all’uso previsto e ai danni.
• Specificità di mercato: percorsi premarket basati sul rischio della FDA (510(k), De Novo, PMA) e classificazione MDR dell’UE (in particolare la Regola 11 per il software). Pianificate questi aspetti fin dall’inizio — applicarli in seguito è ciò che causa ritardi e rifacimenti.

3) Prospettiva regolatoria globale a colpo d’occhio

Stati Uniti (FDA):Percorsi premarket basati sul rischio. Per il SaMD abilitato AI/ML, la FDA ha finalizzato linee guida sui Predetermined Change Control Plans (PCCP), che permettono ai sponsor di concordare in anticipo come i modelli possono essere aggiornati dopo la clearance/l’approvazione. L’agenzia ha anche pubblicato Good Machine Learning Practice (GMLP) e principi di trasparenza per gestire bias, performance e comunicazione agli utenti.

Unione Europea (MDR):La Regola 11 spinge molto software di decisione clinica verso classi IIa/IIb/III, attivando la revisione del notified body e robuste evidenze cliniche. Le linee guida aggiornate MDCG chiariscono qualificazione e classificazione del software ai sensi di MDR/IVDR.

AI Act dell'UE:L’AI utilizzata nei dispositivi medici sarà generalmente trattata come “high‑risk”, sovrapponendo requisiti specifici per l’AI (governance dei dati, trasparenza, gestione del rischio, supervisione umana) oltre a MDR/IVDR, in fase di applicazione successiva all’entrata in vigore.

Specifico per la pharma (PDURS):La bozza di guidance della FDA su Prescription Drug Use‑Related Software (PDURS) spiega come gli output software diffusi da uno sponsor di un farmaco possano essere regolamentati come labeling del farmaco — rilevante quando il vostro software è legato a un medicinale piuttosto che regolamentato come dispositivo.

4) Note di caso: accoppiamenti pharma‑digital in pratica

Respiratorio connesso:I sensori e le app di Propeller Health sono stati abbinati a grandi marche di inalatori per supportare l’aderenza e il monitoraggio dei sintomi.

Ecosistemi per il diabete:L’acquisizione di mySugr da parte di Roche ha portato la gestione del diabete centrata sull’app in un ampio portafoglio pharma/dispositivo, fondendo software, lettori e servizi.

Lezioni dalla pillola digitale:ABILIFY MYCITE (Otsuka + Proteus) ha dimostrato come le combinazioni farmaco‑dispositivo‑software possano ottenere l’approvazione ma affrontare comunque sfide di adozione, privacy e valore.

Terapie digitali su prescrizione:Partnership attorno a trattamenti software (es. reSET/reSET‑O) hanno illustrato sia la fattibilità regolatoria sia gli ostacoli commerciali.

5) Cinque lezioni pratiche che la pharma dovrebbe prendere in prestito dallo sviluppo SaMD

1. Classificare presto. Applicate i criteri FDA e la Regola 11 del MDR già nella fase di concept; documentate l’uso previsto e le decisioni cliniche che il vostro software influenza.

2. Costruire la spina dorsale del QMS. Predisponete controlli di design, file di rischio e processi per il ciclo di vita del software prima di sviluppare oltre un prototipo.

3. Trattare l’usabilità come sicurezza. Pianificate test formativi e sommativi; collegate le decisioni UI ai controlli di rischio e ai rischi residui nel vostro file ISO 14971.

4. Validare la pipeline dei dati. Documentate le fonti di dati, la qualità, la rappresentatività e le misure di tutela della privacy; questo supporta sia la sicurezza dell’AI sia la fiducia.

5. Progettare per gli aggiornamenti. Per AI/ML, prevedete aggiornamenti dei modelli con protocolli di change chiari (es. PCCP negli USA) e un piano di monitoraggio post‑mercato.

6) AI/ML: Le modalità di guasto da prevedere

Deriva dell’algoritmo: le prestazioni nel mondo reale possono degradare man mano che cambiano le popolazioni, le pratiche cliniche o i sensori. Monitorare e riaddestrare secondo un piano controllato.

Bias e rappresentatività: dati di addestramento non rappresentativi possono danneggiare sotto‑popolazioni. Definire metriche di bias, prespecificare mitigazioni ed essere trasparenti sui limiti.

Spiegabilità e trasparenza: fornire informazioni chiare agli utenti su uso previsto, input, output e modalità di guasto conosciute; allinearsi ai principi di trasparenza pubblicati.

Team umano‑AI: definire ciò che decide l’umano rispetto a quanto suggerisce il software; progettare interfacce che riducano, non aumentino, il carico cognitivo.

7) Dopo il lancio: ciclo di vita, cybersecurity e sorveglianza

• EU MDR post‑market: Mantenere un piano PMS; per classi IIa/IIb/III, preparare Periodic Safety Update Reports (PSUR) che sintetizzino i dati di sicurezza e prestazione.

• Aspettative USA: monitorare le prestazioni nel mondo reale; per dispositivi connessi, affrontare progettazione sicura, gestione delle vulnerabilità, disclosure coordinata e fornire una software bill of materials (SBOM) in linea con le attuali aspettative della FDA.

• Gestione degli aggiornamenti: collegare patch software e aggiornamenti di modello alla valutazione del rischio, alla verifica/validazione e alle comunicazioni agli utenti. Documentare tutto.

8) Etica, privacy e fiducia del paziente

Essere espliciti su quali dati raccogliete, perché e come sono protetti. Assicurare allineamento a GDPR/HIPAA, minimizzare i dati dove possibile e comunicare chiaramente benefici e rischi. La fiducia è una scelta progettuale — incorporatela nei flussi di onboarding, nel consenso e nell’etichettatura.

9) Lista di controllo per i team pharma che si avvicinano al SaMD

Conclusione

Il software fa ormai parte della terapia. I team che considerano il SaMD come un prodotto regolamentato fin dall’inizio — con classificazione chiara, evidenze adeguate allo scopo e un piano per aggiornamenti e sorveglianza — consegneranno più rapidamente e con meno sorprese.

Riferimenti

1. FDA – elenco dei dispositivi medici abilitati AI/ML; linee guida PCCP; GMLP e principi di trasparenza.

2. EU – Rule 11 del MDR e linee guida MDCG sul software; EU AI Act (obblighi per gli high‑risk).

3. Note di caso – Otsuka/Proteus ABILIFY MYCITE; Propeller Health partnerships; Roche acquisition of mySugr; analisi di mercato sull’adozione della digital health.