Come si trasforma un’osservazione clinica — un infermiere che perde tempo prezioso con un dispositivo scomodo in corsia — in un prodotto sicuro, conforme e utilizzabile? Serve una catena di evidenze verificabili che colleghi ogni requisito a un test, ogni scelta progettuale a un rischio controllato, fino al trasferimento in produzione senza che nulla di questo percorso vada perduto lungo la strada: un lavoro che richiede competenze di design industriale e di ingegneria capaci di muoversi insieme fin dalle prime settimane.
In sintesi, per passare da un bisogno clinico osservato sul campo a un dispositivo tracciabile servono alcuni passaggi precisi, ciascuno con un deliverable verificabile:
- bisogno clinico e contesto d’uso documentati (chi userà il dispositivo, dove, con quali vincoli reali);
- design input tradotti in requisiti misurabili, non in descrizioni generiche;
- un fascicolo di gestione del rischio aggiornato secondo la logica della norma ISO 14971;
- un fascicolo di usability engineering coerente con la norma IEC 62366-1;
- verifica e validazione collegate a ciascun requisito, non genericamente al prodotto finito;
- controllo delle modifiche e trasferimento in produzione senza perdita di tracciabilità.
Perché il bisogno clinico non basta: definire il problema in modo verificabile
Un errore frequente, anche in team esperti, è confondere il bisogno clinico con un desiderio di soluzione già formato in testa a qualcuno. Un chirurgo che chiede un’impugnatura diversa sta già proponendo una risposta, non descrivendo il problema. Il lavoro di chi guida lo sviluppo è risalire a monte: cosa non funziona nel compito, in quali condizioni, con quali conseguenze per paziente e operatore.
Prendiamo un caso concreto, a cui torneremo più volte: un operatore deve collegare la linea di un’infusione a una pompa, spesso in condizioni non ideali — luce scarsa, guanti, fretta tra un paziente e l’altro. Se il connettore può essere inserito in due modi, uno corretto e uno no, quella scomodità osservata sul campo non è un dettaglio: è il punto di partenza di un intero capitolo di progettazione, molto prima che diventi un disegno tecnico.
Serve quindi una descrizione puntuale del contesto d’uso: chi userà il dispositivo (personale specializzato o paziente a domicilio), in che ambiente (sala operatoria, terapia intensiva, casa), con quale frequenza, sotto quale pressione di tempo. Solo a questo punto ha senso scrivere l’outcome atteso: riduzione di un tipo specifico di errore, tempo procedura più breve, minore fatica dell’operatore. Un outcome vago — “più sicuro”, “più semplice” — non è negoziabile in fase di verifica, perché non si può misurare.
Dalla forma alla complessità: un criterio pratico per distinguere fornitore e partner
A questo punto il progetto richiede competenze che raramente convivono in un’unica figura: ergonomia, meccanica, elettronica, software, conoscenza delle norme di settore, capacità di prototipazione rapida. Un modo utile per distinguere un fornitore generico da un partner di sviluppo è osservare se queste competenze lavorano in sequenza isolata — prima il design, poi l’ingegneria che interviene a correggere — oppure come un processo unico, con decisioni prese insieme fin dalle prime settimane. È il punto in cui il progetto smette di essere una questione di forma per diventare una questione di complessità gestita: ogni scelta estetica o ergonomica comporta ricadute tecniche immediate, e viceversa.
Uno studio che lavora secondo questa logica è PQ Design, che si presenta come studio di design industriale e dichiara di integrare design, ingegneria e strategia fin dal primo giorno, partendo dal principio che ogni scelta di progetto comporta implicazioni tecniche da gestire subito, non a posteriori. Sul proprio sito l’azienda indica di operare dal 2009, di aver seguito oltre 150 progetti per aziende e startup in più di dieci settori industriali e di aver lavorato con clienti in oltre quindici paesi tra Europa, Stati Uniti e Asia: dati dichiarati dall’azienda, utili più come indicazione di continuità operativa che come prova di competenza specifica in ambito medicale, che resta da valutare caso per caso attraverso referenze dirette e progetti comparabili.
Ciò che conta, in un contesto regolato, non è l’etichetta del fornitore ma la sua capacità di produrre un registro delle decisioni tracciabile: perché è stata scelta una certa forma, quale alternativa è stata scartata e per quale motivo, quali compromessi sono stati dichiarati esplicitamente invece di restare impliciti. Questo registro tornerà utile più avanti, in fase di verifica e validazione.
Dalla voce del clinico ai requisiti: tradurre in design input misurabili
In molti progetti, interviste strutturate e osservazione diretta sul campo sono gli strumenti che permettono di intercettare workflow reali e i workaround che il personale sanitario inventa quando un dispositivo non lo supporta bene. Questi workaround sono spesso il segnale più chiaro di un punto di rottura nel progetto originario, e vale la pena documentarli come tali, non liquidarli come eccezioni isolate.
Tornando al connettore dell’infusione: l’osservazione sul campo diventa un requisito solo se formulata in modo testabile. Non “deve essere facile da collegare” ma, ad esempio, “un operatore non addestrato non deve riuscire a inserire il connettore in posizione invertita, anche in condizioni di luce scarsa e con guanti indossati”. Lo stesso principio vale per gli altri requisiti: non “deve essere facile da pulire” ma “deve resistere a un numero di cicli di disinfezione definito nel protocollo, con la soluzione specificata, senza alterazioni visibili”. Accanto ai requisiti funzionali, prestazionali e di sicurezza, vanno messi a fuoco presto anche i vincoli di produzione e manutenzione: materiali compatibili con la sterilizzazione scelta, geometrie che non intrappolano residui, consumabili disponibili con continuità, procedure di assemblaggio ripetibili in linea.
Sicurezza per progettazione: gestione del rischio fin dall’inizio
Che cos’è la gestione del rischio secondo la norma ISO 14971? È il riferimento internazionale che specifica terminologia, principi e un processo completo per la gestione del rischio dei dispositivi medici, applicabile anche al software come dispositivo medico e ai dispositivi diagnostici in vitro. Stabilisce un framework per identificare i pericoli, stimare e valutare i rischi, controllarli e monitorarne l’efficacia lungo l’intero ciclo di vita del dispositivo, dalla concezione iniziale fino alla dismissione e allo smaltimento. Aggiornata nel 2019 e confermata nel 2025, resta la versione attuale di riferimento. Richiede ai fabbricanti di stabilire criteri oggettivi per l’accettabilità del rischio, senza però fissare livelli di rischio accettabili predefiniti: la soglia la definisce il fabbricante, con criteri documentati e giustificabili.
Applicato al nostro esempio: il pericolo è un connettore invertibile; la situazione pericolosa è un operatore che, in condizioni di fretta o scarsa visibilità, lo inserisce nel verso sbagliato; il danno possibile è un’erogazione errata al paziente. È una sequenza da costruire insieme al requisito, non un’etichetta da applicare a posteriori.
Un’euristica diffusa in molti team — non un obbligo stabilito dalla norma in sé — è privilegiare interventi che agiscono sulla forma o sul materiale del dispositivo, come una geometria a chiave che renda fisicamente impossibile l’inserimento invertito, rispetto a misure che si limitano a informare l’utente tramite etichette o istruzioni: una soluzione progettuale di questo tipo non dipende dal comportamento di chi usa il dispositivo in un momento di stress. Resta comunque il fabbricante a stabilire, caso per caso, quale combinazione di interventi sia adeguata al rischio specifico individuato.
Usabilità come requisito di sicurezza: progettare per l’uso reale
Che cos’è la usability engineering secondo la norma IEC 62366-1 e a cosa serve? È il processo con cui un fabbricante analizza, specifica, sviluppa e valuta l’usabilità di un dispositivo medico in relazione alla sicurezza. Permette di valutare e mitigare i rischi legati all’uso normale e agli errori d’uso prevedibili; per i rischi legati a un uso anomalo o intenzionalmente scorretto, invece, consente solo di identificarli, non di valutarli o correggerli. Confermata nel 2021, resta il riferimento attuale, pur non risultando ancora armonizzata al Regolamento (UE) 2017/745 sui dispositivi medici: nella pratica, però, viene trattata come lo standard di riferimento per la valutazione dell’usabilità.
Il connettore invertibile che abbiamo seguito finora è un esempio tipico di errore d’uso prevedibile che questo tipo di analisi mira a intercettare: un pericolo progettuale prima ancora che un problema di istruzioni per l’uso. Due pulsanti troppo simili tra loro, o un allarme che non si distingue dal rumore di fondo del reparto, appartengono alla stessa famiglia di problemi.
In molti progetti può essere utile distinguere momenti di test più esplorativi, pensati per raccogliere indicazioni di correzione nelle fasi iniziali con un numero contenuto di partecipanti, da momenti di verifica più strutturati, condotti quando il prodotto si avvicina alla versione definitiva. Trarre conclusioni definitive da un prototipo ancora esplorativo resta un rischio da tenere presente, più che una violazione di una regola specifica.
Architettura del prodotto: integrare elettronica, meccanica, software e interfaccia fisica
Le scelte di architettura — dove posizionare un comando, come segnalare un allarme, come codificare colori e forme per compiti diversi — non sono questioni puramente estetiche: ogni scelta di product design in questo ambito ha un impatto diretto su sicurezza e usabilità. Un buon lavoro di concept design, a questo stadio, prova varianti diverse di layout e interazione prima di congelare una direzione, confrontandole con i compiti critici individuati in precedenza, non con il gusto personale del team.
Un capitolo spesso sottovalutato è il design per la pulizia e il controllo delle infezioni: geometrie senza interstizi difficili da raggiungere, giunzioni che non trattengono residui, materiali compatibili con i protocolli di disinfezione dichiarati. Quando pertinente, va considerato anche il grado di protezione da liquidi e polveri, perché un dispositivo che si deteriora dopo pochi cicli di pulizia genera un problema di sicurezza indiretto, oltre che di costo.
Tracciabilità: collegare bisogno, requisito, soluzione e verifica
La tracciabilità riduce il rework, perché ogni modifica tardiva può essere ricondotta ai requisiti e ai rischi che impatta, invece di innescare una revisione a cascata su tutto il progetto. I design output — disegni, specifiche, software — vanno scritti con criteri di accettazione verificabili, altrimenti la fase di test diventa un’interpretazione soggettiva invece di una misura oggettiva.
Gli artefatti tipici che un processo maturo produce, e che vale la pena chiedere a qualsiasi partner di sviluppo, comprendono:
- un registro dei requisiti con stato (negoziabile o non negoziabile) e relativo criterio di verifica;
- un fascicolo di gestione del rischio aggiornato a ogni iterazione significativa del progetto;
- un fascicolo di usability engineering con utenti, compiti critici e use error individuati;
- piani e report di verifica e validazione collegati ai singoli requisiti;
- un registro delle modifiche che spieghi perché una soluzione precedente è stata sostituita.
Verifica, validazione e la gestione dei compromessi dichiarati
Qual è la differenza tra verifica e validazione? La verifica accerta se il prodotto soddisfa i requisiti che ci si è dati, attraverso test, ispezioni, analisi documentali. La validazione accerta invece se il prodotto risolve davvero il bisogno clinico nel contesto reale d’uso, spesso con simulazioni che riproducono le condizioni operative effettive invece che un ambiente controllato di laboratorio. Per il nostro connettore, la verifica è un test di laboratorio che misura se l’inserimento invertito è fisicamente impedito; la validazione è osservare operatori reali, in un contesto simulato di fretta e luce scarsa, mentre collegano la linea senza che nessuno abbia spiegato loro in anticipo il dettaglio critico.
Nel mezzo, quasi sempre, emergono compromessi: più prestazioni spesso significano più complessità d’uso, maggiore semplicità può costare in producibilità, un costo contenuto può limitare le opzioni di materiali compatibili con la sterilizzazione. Un buon processo non nasconde questi compromessi: li dichiara esplicitamente nel registro delle decisioni, con le alternative scartate e il motivo della scelta finale. È quel documento, più di qualunque rassicurazione verbale, che un revisore interno o un ente notificato vorrà vedere.
Dal prototipo alla produzione: trasferimento industriale senza perdere sicurezza
Il passaggio dal prototipo funzionante alla produzione in serie introduce vincoli che raramente sono visibili nelle prime fasi: tolleranze di stampaggio, variabilità dei fornitori, tempi di assemblaggio in linea. In molti progetti conviene iniziare a considerare i vincoli di produzione già nelle fasi intermedie dello sviluppo, non solo a ridosso del trasferimento, perché modifiche tardive rischiano di rimettere in discussione requisiti di sicurezza già verificati.
Un altro punto di attenzione è la catena di fornitura: componenti elettronici soggetti a obsolescenza, alternative qualificate non sempre disponibili in tempi brevi, necessità di test in accettazione su ogni lotto critico. Un’organizzazione che tiene vicini progettazione e industrializzazione — ad esempio distribuendo le proprie sedi tra un polo orientato al design e uno dedicato alla manifattura — può facilitare questo tipo di continuità, anche se non la rende automatica sul singolo progetto. Il partner di sviluppo citato poco sopra, ad esempio, dichiara una sede principale a Pisa, un ufficio di business e meeting a Milano e un polo di manufacturing a Shenzhen: un assetto coerente con questa logica, che resta comunque da valutare progetto per progetto.
La documentazione di controllo delle modifiche, qui, diventa decisiva: ogni variazione di componente o processo va valutata per il suo impatto sui requisiti e sui rischi già accettati, altrimenti un’iterazione apparentemente innocua può compromettere la conformità raggiunta.
Errori frequenti che rendono un dispositivo poco utilizzabile
Alcuni errori ricorrono con una frequenza che li rende quasi prevedibili, e vale la pena tenerli come lista di controllo prima di avanzare in ogni fase:
- requisiti scritti in modo vago, non misurabile e quindi non verificabile in fase di test;
- test di usabilità condotti troppo tardi, o con utenti non rappresentativi del contesto reale;
- allarmi e feedback sonori o visivi incoerenti con il rumore di fondo e il carico cognitivo del reparto;
- procedure di pulizia e manutenzione pensate dopo, invece che integrate nella geometria del prodotto;
- un progetto sviluppato in isolamento dalla produzione, con scoperte tardive su costi e fattibilità industriale.
Il filo conduttore: una catena di evidenze, non una sequenza di fasi
Quanto descritto finora non va letto come un elenco di fasi da spuntare in sequenza, ma come una catena in cui ogni anello regge solo se è collegato correttamente al precedente e al successivo. Un bisogno clinico definito male produce requisiti vaghi; requisiti vaghi producono soluzioni difficili da verificare; soluzioni non verificabili producono un fascicolo di rischio e usabilità fragile, che a sua volta espone il progetto a revisioni costose quando è tardi per intervenire senza impatti rilevanti su tempi e budget.
Chi guida un progetto di dispositivo medico — un responsabile R&D in un’azienda strutturata o il founder di una startup healthtech alla prima esperienza regolatoria — farebbe bene a chiedere, a ogni passaggio di avanzamento, una domanda semplice: questa decisione è tracciabile fino al requisito che la giustifica, ed è verificabile con un test concreto? Se la risposta non arriva in modo immediato, probabilmente conviene tornare indietro di un anello nella catena prima di procedere oltre.





