Sviluppo software per dispositivi medici: guida 2026

Sophie Laurent Legal & Compliance Lead, YuSMP Group · Consulenza a team MedTech e di salute digitale su IEC 62304, ISO 13485, percorsi FDA e MDR UE e l’AI Act europeo

TL;DR — i fatti chiave in sintesi

Che cos’è lo sviluppo software per dispositivi medici?

Lo sviluppo software per dispositivi medici è la progettazione, l’ingegnerizzazione e la validazione di software che o è un dispositivo medico o gira dentro un dispositivo — condotto sotto un sistema di gestione della qualità regolamentato. Comprende il software come dispositivo medico (SaMD) come un analizzatore di imaging diagnostico, il firmware embedded in una pompa di infusione o in un monitor paziente, e le app companion e i servizi cloud che li collegano. Ciò che lo distingue dall’ingegneria di prodotto ordinaria è un unico vincolo: poiché il software può influenzare una decisione clinica o una terapia, un difetto è un evento di sicurezza del paziente — quindi la sicurezza e le prove regolatorie plasmano ogni decisione fin dal primo sprint.

Questo vincolo è il motivo per cui i team esperti di servizi di sviluppo software sanitario partono dall’inquadramento regolatorio — destinazione d’uso, classificazione di sicurezza, norme applicabili — prima di scrivere una riga di codice funzionale. La destinazione d’uso guida la classe del dispositivo, la classe guida quanta parte di IEC 62304 dovete soddisfare, e questo a sua volta fissa documentazione, test e percorso di mercato. Lo sviluppo software per dispositivi medici svolto al contrario — prima costruire, poi documentare — è l’errore più frequente e costoso del settore, perché adattare a posteriori design control e tracciabilità su codice finito significa di fatto fare il lavoro due volte.

Le organizzazioni commissionano sviluppo software su misura per dispositivi medici per alcune ragioni chiare: nessuna piattaforma pronta corrisponde alla loro rivendicazione clinica, costruiscono il dispositivo stesso come prodotto, oppure un sistema legacy non soddisfa più le attuali regole di cybersecurity e interoperabilità. Il resto di questa guida descrive cosa comporta realmente un build conforme nel 2026 — le classi, le norme, il processo, le regole sull’IA, la sicurezza e il costo.

SaMD vs software embedded

La prima decisione è quale tipo di software di dispositivo medico state costruendo, perché fissa tutto il resto. I regolatori dividono il campo in due famiglie, e un prodotto reale spesso include entrambe su un unico sistema connesso.

• Software come dispositivo medico (SaMD) — software che assolve una finalità medica da solo, senza far parte di un dispositivo hardware: un’app che segnala un ictus su una TC, un calcolatore di dose clinica o un algoritmo che tria immagini retiniche. Lo sviluppo di software come dispositivo medico è classificato secondo il rischio della decisione che orienta, seguendo il quadro internazionale IMDRF usato da FDA e UE.
• Software in un dispositivo medico (SiMD) — il firmware embedded che controlla un dispositivo fisico come un ventilatore, una pompa o un monitor. È regolamentato come parte di quel dispositivo, ma il suo ciclo di vita segue comunque IEC 62304.
• Medical Device Data Systems & accessori — software che trasferisce, archivia o visualizza dati senza interpretarli può essere a minor rischio o non regolamentato, ma il confine è stretto e la formulazione della destinazione d’uso decide.

Nominare presto la categoria vi dice le norme, la classe regolatoria e il budget che seguono. Una trappola comune è una rivendicazione di «benessere» o «supporto alle decisioni cliniche» che scivola silenziosamente in una finalità medica regolamentata — momento in cui l’intero sistema qualità si applica retroattivamente. Quando la destinazione d’uso è ambigua, trattatela come regolamentata e confermate la classificazione con il vostro organismo notificato o con una pre-submission FDA prima di impegnarvi su un’architettura.

Quali normative si applicano al software dei dispositivi medici nel 2026?

Il software di dispositivo medico deve soddisfare un’autorizzazione di mercato e una pila di norme di consenso, e i due mercati — USA e UE — si sovrappongono ampiamente ma non sono identici. La tabella seguente è l’insieme centrale attorno a cui si pianifica ogni build 2026; il sottoinsieme esatto dipende dalla classe del dispositivo e dai mercati di destinazione.

Due punti colgono i team di sorpresa. Primo, IEC 62304 è una norma software, ma si colloca dentro ISO 13485 e ISO 14971 — non potete soddisfarla in isolamento, e la FDA la riconosce come norma di consenso, così una dichiarazione di conformità può accelerare un 510(k). Secondo, l’MDR UE ha riclassificato verso l’alto la maggior parte del software autonomo: un dispositivo della regola 11 che orienta una decisione clinica è di norma di classe IIa o superiore, il che implica un organismo notificato, non l’autocertificazione. Se il vostro prodotto tratta dati sanitari protetti negli USA, si applica anche HIPAA — la nostra checklist HIPAA per lo sviluppo software copre questo dettaglio ingegneristico.

Il processo di sviluppo software per dispositivi medici (IEC 62304)

Il processo di sviluppo software per dispositivi medici è un ciclo di vita controllato, non gate da avvitare alla fine — IEC 62304 definisce le attività, e quante svolgerne dipende dalla vostra classe di sicurezza software. IEC 62304 assegna a ogni elemento software una classe secondo il peggior danno possibile: classe A (nessuna lesione possibile), classe B (lesione non grave possibile) e classe C (morte o lesione grave possibile). L’edizione 2 della norma, prevista per agosto 2026, semplifica queste classi e aggiunge clausole esplicite per componenti di IA e machine learning, allineando il ciclo di vita a una consegna agile per gli aggiornamenti a minor rischio.

1. Pianificazione & destinazione d’uso: definire la rivendicazione clinica, classificare il dispositivo e la classe di sicurezza software e impostare il sistema qualità e il fascicolo di gestione del rischio. Questo passo fissa gran parte del budget finale.
2. Requisiti & analisi del rischio: derivare i requisiti software dalla destinazione d’uso e dall’analisi dei pericoli ISO 14971, con ogni requisito tracciabile verso una misura di controllo del rischio.
3. Architettura & progettazione di dettaglio: per le classi B e C, documentare l’architettura e segregare gli elementi critici per la sicurezza affinché un guasto non si propaghi — è qui che si concentra lo sforzo di progettazione.
4. Implementazione & verifica di unità: costruire secondo il progetto con standard di codifica, analisi statica e test di unità, mantenendo la tracciabilità dal codice al requisito.
5. Test di integrazione, di sistema & verifica: verificare il software rispetto ai requisiti e validarlo rispetto alla destinazione d’uso clinica, con prove documentate e ripetibili.
6. Rilascio & submission regolatoria: compilare il design history file e la documentazione tecnica per il 510(k)/De Novo della FDA o il fascicolo tecnico MDR UE e l’esame dell’organismo notificato.
7. Manutenzione & sorveglianza post-market: monitorare le prestazioni sul campo, gestire le modifiche software sotto change control e reimmettere reclami e incidenti nella gestione del rischio.

La disciplina è lo stesso rigore dietro ogni build regolamentato — la nostra guida al ciclo di vita di sviluppo software sicuro mostra come la mentalità di verifica e tracciabilità si generalizzi. Ciò che è specifico dei dispositivi medici è che la prova è il deliverable: un auditor o un revisore giudica la traccia documentale tanto quanto il software funzionante.

Come è regolamentata l’IA nei dispositivi medici nel 2026?

Il software di dispositivo medico con IA è regolamentato prima come dispositivo medico e poi come sistema di IA, e il 2026 è l’anno in cui il secondo livello è diventato reale nella UE. Negli USA, la FDA esamina i dispositivi con IA/ML tramite i percorsi esistenti e, da quando ha finalizzato la sua linea guida a dicembre 2024, consente ai produttori di pre-autorizzare gli aggiornamenti del modello con un Predetermined Change Control Plan (PCCP) — specificate in anticipo quali modifiche di riaddestramento e prestazioni potete rilasciare senza una nuova submission, il che rende finalmente il machine learning iterativo compatibile con la regolamentazione dei dispositivi. I principi di Good Machine Learning Practice della FDA fissano le aspettative su qualità dei dati, validazione e monitoraggio.

Nella UE il quadro è più gravoso. Un’IA integrata in, o che agisce come, un dispositivo MDR di classe IIa, IIb o III è automaticamente classificata ad alto rischio ai sensi dell’AI Act, che sovrappone obblighi di data governance, trasparenza, tenuta dei registri e sorveglianza umana all’MDR. Le disposizioni dell’AI Act sui dispositivi medici si applicano da agosto 2026, con una finestra più lunga fino ad agosto 2027 per i dispositivi a marchio CE a maggior rischio esaminati da un organismo notificato. In pratica, entrambi i quadri si applicano insieme e condividono un unico fascicolo tecnico integrato — i team che hanno trattato l’AI Act come un problema futuro rischiano ora lacune documentali, proprio mentre gli organismi notificati iniziano a valutarlo. Se il vostro prodotto è anche uno strumento di IA erogato in SaaS, la nostra checklist di conformità all’AI Act europeo copre gli obblighi generali.

Gestione del rischio e cybersecurity

La gestione del rischio e la cybersecurity sono requisiti regolatori per il software di dispositivo medico, non un hardening opzionale — e dal 2023 la FDA può respingere una submission che ne è priva. Ogni pericolo deve essere identificato, valutato e controllato secondo ISO 14971, e ogni misura di controllo deve essere tracciabile all’indietro verso un requisito e in avanti verso un test di verifica. La sicurezza è ora trattata come una questione di sicurezza del paziente: una vulnerabilità in un dispositivo connesso è un pericolo al pari di un guasto meccanico.

• Gestione del rischio (ISO 14971): un fascicolo di rischio vivo che percorre l’intero ciclo di vita, collegando i pericoli alle misure di controllo e all’accettabilità del rischio residuo.
• Cybersecurity di pre-immissione: ai sensi della sezione 524B del FD&C Act, le submission statunitensi devono includere un modello di minaccia, una Software Bill of Materials (SBOM) per tutti i componenti di terze parti e open source e un piano per monitorare e correggere le vulnerabilità.
• Ciclo di vita sicuro (IEC 81001-5-1): la norma di processo di sicurezza per il software sanitario che si abbina a IEC 62304 per progettazione, codifica e aggiornamenti sicuri.
• Vigilanza post-market: divulgazione coordinata delle vulnerabilità, monitoraggio sul campo e un percorso di aggiornamento testato, perché il dispositivo deve restare sicuro per tutta la sua vita utile.

Il filo conduttore è che safety, security e qualità sono un unico sistema, non tre reparti. Un dispositivo connesso che invia dati al cloud eredita la postura di sicurezza dell’intero percorso — per questo predisporre un’infrastruttura irrobustita e verificabile è un lavoro centrale di Cloud & DevOps, non un ripensamento.

Quanto costa lo sviluppo software per dispositivi medici nel 2026?

Nel 2026 lo sviluppo software per dispositivi medici va da circa 80.000 USD per un SaMD a basso rischio a 700.000 USD o più per software di dispositivo di classe C con una submission regolatoria completa — guidato molto più dalla classe di sicurezza e dalla superficie regolatoria che dal numero di funzionalità. Gli intervalli seguenti riflettono build consegnabili e completi realizzati da un team esperto e conforme a un sistema qualità, non un prototipo che simula le parti regolamentate.

Sono ingaggi combinati che includono gestione del rischio, verifica, documentazione e QA. Per come funziona il costo di un build nel software in generale, veda la nostra guida ai costi dello sviluppo software su misura nel 2026.

Dove va davvero il budget

• Sistema qualità & documentazione (25–40%): design control, fascicolo di rischio, prove di verifica e submission regolatoria — la maggiore voce di costo nascosta.
• Verifica & validazione (20–30%): test tracciabili a livello di unità, integrazione e sistema, più la validazione dei fattori umani.
• Cybersecurity (10–20%): modellazione delle minacce, SBOM, penetration test e un percorso di patch mantenuto.
• L’applicazione stessa (25–35%): il workflow clinico o del dispositivo sopra la base conforme.

Preveda a budget separatamente la fase post-market: sorveglianza continua, patch di sicurezza e change control costano in genere il 15–20% del costo del build all’anno dopo il lancio.

Best practice per un build conforme di software di dispositivo medico

I team che consegnano in tempo trattano la compliance come una pratica di ingegneria, non come un esercizio di documentazione avvitato alla fine. Cinque abitudini separano un’autorizzazione fluida da una bloccata.

1. Fissate prima destinazione d’uso e classe. La rivendicazione clinica decide classe del dispositivo, norme e budget; confermatela con una pre-submission FDA o con un organismo notificato prima di scegliere un’architettura.
2. Impostate il sistema qualità prima del codice funzionale. Design control, gestione del rischio e tracciabilità sono economici da integrare e costosi da adattare a posteriori — un SGQ ISO 13485 è la base, non la rifinitura.
3. Rendete automatica la tracciabilità. Collegate requisito → misura di controllo → codice → test negli strumenti, così che il design history file sia un sottoprodotto del lavoro, non un mese di archeologia prima dell’audit.
4. Progettate sicurezza e aggiornamenti fin dall’inizio. Modellate presto le minacce, generate una SBOM e costruite un percorso di aggiornamento firmato e testato — il dispositivo deve restare sicuro per tutta la sua vita utile.
5. Pianificate le modifiche dell’IA con un PCCP. Se il dispositivo apprende, pre-autorizzate l’intervallo di aggiornamento del modello per poter iterare senza una nuova submission ogni volta.

La competenza software generale è qui necessaria ma non sufficiente; il fattore differenziante è un partner che abbia già fatto autorizzare software di dispositivo regolamentato. La base di conformità e il lavoro di integrazione sono ingegneria backend e cloud di base — la stessa disciplina dietro la nostra più ampia pratica di sviluppo software su misura, estesa ai dati medici regolamentati. Un’app companion rivolta al paziente è anche un serio progetto di sviluppo di app mobili a sé stante.

FAQ

Che cos’è lo sviluppo software per dispositivi medici?

Lo sviluppo software per dispositivi medici è la progettazione, l’ingegnerizzazione e la validazione di software che è esso stesso un dispositivo medico (software come dispositivo medico) o che gira al suo interno (software embedded), realizzato sotto un sistema qualità regolamentato. Poiché il software può incidere sulla sicurezza del paziente, viene sviluppato secondo IEC 62304 per il ciclo di vita, ISO 14971 per la gestione del rischio e ISO 13485 per la qualità, e deve ottenere l’autorizzazione FDA o ai sensi dell’MDR UE prima del lancio. Il ciclo di vita regolamentato e la documentazione, non il codice delle funzionalità, sono la parte difficile.

Che cos’è il software come dispositivo medico (SaMD)?

Il software come dispositivo medico (SaMD) è software destinato a una finalità medica che assolve tale finalità senza far parte di un dispositivo hardware — ad esempio un’app che analizza immagini per rilevare una malattia. Si contrappone al software in un dispositivo medico (SiMD), il firmware embedded in una pompa o in un monitor. Entrambi sono regolamentati, ma il SaMD è classificato a sé secondo il rischio della decisione che orienta, seguendo il quadro IMDRF usato da FDA e UE.

Quali normative si applicano al software dei dispositivi medici nel 2026?

Negli USA la FDA lo regolamenta ai sensi del FD&C Act, di norma tramite un percorso 510(k) o De Novo, con IEC 62304, ISO 14971 e la cybersecurity di pre-immissione (inclusa una SBOM ai sensi della sezione 524B) come standard centrali. Nella UE ricade sotto il Regolamento sui dispositivi medici (MDR UE 2017/745) e richiede la marcatura CE tramite un organismo notificato per la maggior parte delle classi; se usa l’IA, è anche un sistema ad alto rischio ai sensi dell’AI Act. ISO 13485 sta alla base di entrambi i mercati.

Come classifica IEC 62304 il software dei dispositivi medici?

IEC 62304 assegna a ogni elemento software una classe di sicurezza secondo il peggior danno possibile: classe A (nessuna lesione possibile), classe B (lesione non grave possibile) e classe C (morte o lesione grave possibile). La classe fissa quanta parte del ciclo di vita della norma — architettura, progettazione di dettaglio, verifica di unità e tracciabilità — occorre documentare. L’edizione 2, prevista per agosto 2026, semplifica queste classi e aggiunge clausole esplicite per software di IA e machine learning.

Quanto costa lo sviluppo software per dispositivi medici nel 2026?

Un SaMD a basso rischio (classe A) costa in genere 80.000–150.000 USD, un prodotto di classe B di supporto alla diagnosi con integrazioni 150.000–350.000 USD e un software di dispositivo di classe C, di sostegno vitale, con submission completa 350.000–700.000 USD o più. La documentazione regolatoria e un sistema qualità conforme aggiungono 30.000–80.000 USD, e ogni integrazione con dispositivo connesso o EHR aggiunge 20.000–50.000 USD; quindi la classe di sicurezza e la superficie regolatoria guidano il budget più del numero di funzionalità.

Come è regolamentata l’IA nei dispositivi medici nel 2026?

Negli USA la FDA regolamenta il software di dispositivo con IA/ML tramite i percorsi esistenti e consente ai produttori di pre-autorizzare gli aggiornamenti del modello con un Predetermined Change Control Plan (PCCP), finalizzato a dicembre 2024, insieme alla Good Machine Learning Practice. Nella UE, un’IA in un dispositivo MDR di classe IIa/IIb/III è automaticamente ad alto rischio ai sensi dell’AI Act, che aggiunge obblighi di data governance, trasparenza e sorveglianza umana oltre all’MDR; le sue disposizioni sui dispositivi medici si applicano da agosto 2026, e da agosto 2027 per i dispositivi a marchio CE a maggior rischio esaminati da un organismo notificato.

Ultimo aggiornamento 18 luglio 2026. Gli intervalli di costo e tempistica riflettono build consegnabili e completi per clienti MedTech statunitensi ed europei e variano in base a classe del dispositivo, mercati, integrazioni e percorso regolatorio. I riferimenti regolatori — inclusi IEC 62304 edizione 2 e le scadenze dell’AI Act europeo — sono orientamenti generali, non consulenza legale; consulti un consulente regolatorio qualificato, il suo organismo notificato e la FDA per i requisiti vigenti. Richieda una proposta mirata per il suo dispositivo specifico.