Appalti sanitari: il software senza marcatura CE non si cura con le promesse

lentepubblica.it

Software dispositivo medico e appalti sanitari: la marcatura CE è un requisito regolatorio, non una promessa. Cosa devono verificare le stazioni appaltanti.

Nel mondo degli appalti pubblici sanitari esiste una curiosa illusione amministrativa: pensare che un software, solo perché non ha bulloni, carrelli, sonde, reagenti, sensori o parti meccaniche, possa essere trattato come un innocuo accessorio informatico, una specie di comparsa digitale al servizio dell’apparecchiatura principale. Il ragionamento è seducente nella sua semplicità: la macchina è marcata CE, il software è installato sulla macchina, quindi tutto il sistema è a posto. Peccato che il diritto dei dispositivi medici, quello vero, non ragioni per comodità descrittive, ma per destinazione d’uso, funzione svolta, finalità medica e responsabilità del fabbricante.

Il punto è tanto semplice quanto spesso rimosso nelle gare sanitarie: anche un software può essere un dispositivo medico. Non lo diventa perché è utilizzato dentro un ospedale, perché compare su un computer di reparto o perché dialoga con un sistema aziendale. Lo diventa quando, secondo la destinazione impressa dal fabbricante, è finalizzato a diagnosi, prevenzione, monitoraggio, previsione, prognosi, trattamento o attenuazione di una malattia; oppure quando serve alla diagnosi, al monitoraggio, al trattamento, all’attenuazione o alla compensazione di una lesione o di una disabilità; oppure ancora quando fornisce informazioni clinicamente rilevanti attraverso l’esame di campioni provenienti dal corpo umano.

Software dispositivo medico: quando il software rientra nel MDR

È qui che il Regolamento UE 2017/745 sui dispositivi medici, comunemente indicato come MDR, entra con tutta la sua forza nella procedura di gara. L’art. 2, punto 1, include espressamente il software nella definizione di dispositivo medico. Dunque non c’è alcun bisogno di arrampicarsi su interpretazioni fantasiose: la norma lo dice. Il software non è escluso dal perimetro regolatorio per il solo fatto di essere immateriale. Se svolge una funzione medica, se incide sulla generazione, elaborazione, interpretazione o restituzione di informazioni cliniche, se partecipa al percorso diagnostico o terapeutico, non è un semplice programma. È un dispositivo medico e, come tale, deve rispettare il relativo regime di conformità.

L’errore più frequente consiste nel confondere il software gestionale con il software medicale. Un programma per prenotare appuntamenti, gestire turni, protocollare documenti, archiviare fatture o movimentare magazzino non diventa dispositivo medico solo perché opera dentro un’azienda sanitaria. Questo sarebbe l’eccesso opposto, la regolazione applicata con il rastrello.

Ma quando il software analizza dati clinici, governa funzioni diagnostiche, supporta decisioni mediche, elabora immagini, interpreta parametri fisiologici, produce alert clinici, contribuisce al monitoraggio del paziente o restituisce output utilizzabili nel trattamento, il discorso cambia radicalmente. A quel punto la veste informatica non neutralizza la sostanza sanitaria.

Marcatura CE del software negli appalti sanitari

Nelle procedure di affidamento questo profilo non è secondario. La stazione appaltante non acquista un oggetto neutro, ma una tecnologia destinata a essere utilizzata in un contesto clinico. Se il software è parte essenziale della prestazione richiesta, la sua conformità regolatoria non può essere presunta, né assorbita genericamente dalla marcatura dell’apparecchiatura fisica. L’hardware marcato CE non fa da ombrello universale a qualunque componente digitale installata, collegata o promessa in offerta. Se il software ha una autonoma rilevanza medicale, o comunque opera in combinazione con il dispositivo contribuendo alla finalità medica, occorre verificare se la marcatura CE copra effettivamente anche quella componente, quella versione, quella destinazione d’uso e quelle funzionalità.

Il concetto di utilizzo “in combinazione” è decisivo. Il fatto che il software non operi da solo, ma insieme a un’apparecchiatura, non lo rende automaticamente irrilevante. Al contrario, molti sistemi sanitari moderni funzionano proprio come insiemi integrati di hardware e software. Il valore clinico non sta più soltanto nel macchinario, ma nell’interazione tra sensore, algoritmo, interfaccia, database, elaborazione, visualizzazione e report finale. Fingere che la parte software sia un semplice accessorio equivale a giudicare un’automobile guardando solo le ruote e ignorando centralina, sistemi di controllo, sensori e software di sicurezza. Una posizione suggestiva, forse adatta a una fiera d’antiquariato tecnologico, non a una gara pubblica sanitaria.

La conseguenza per il RUP

Per il RUP la conseguenza è immediata. La qualificazione del software deve essere affrontata nella fase di programmazione e progettazione dell’acquisto, non scoperta dopo l’apertura delle offerte o, peggio, durante il contenzioso. Quando l’amministrazione predispone il capitolato per apparecchiature sanitarie, sistemi diagnostici, piattaforme di monitoraggio, software clinici, dispositivi di laboratorio, tecnologie biomedicali o soluzioni integrate hardware-software, deve chiedersi quali componenti siano dispositivi medici e quali no. Questa domanda non è un lusso specialistico. È parte dell’istruttoria minima di una gara sanitaria seria.

Il capitolato, quindi, deve essere scritto con precisione. Non basta chiedere genericamente “marcatura CE del sistema”. Occorre indicare se la marcatura debba riguardare il dispositivo complessivo, i singoli componenti, i moduli software, le versioni applicative, gli algoritmi, le funzionalità diagnostiche o i moduli opzionali. Occorre pretendere la dichiarazione UE di conformità, l’indicazione del fabbricante, la destinazione d’uso, la classificazione ai sensi del MDR, l’eventuale certificato dell’organismo notificato, l’identificativo del dispositivo, la versione software, le condizioni di aggiornamento e la documentazione tecnica necessaria a verificare la corrispondenza tra ciò che viene offerto e ciò che è effettivamente certificato.

La genericità, in questi casi, è una cattiva consigliera. Una lex specialis vaga genera offerte ambigue, valutazioni incerte e contenziosi quasi inevitabili. Se la stazione appaltante non chiarisce cosa intende acquistare e quale documentazione regolatoria pretende, si troverà davanti operatori che offriranno sistemi apparentemente simili ma giuridicamente diversi: software certificati, software non certificati, software coperti dalla marcatura del dispositivo principale, software esterni, moduli aggiuntivi, versioni aggiornate non documentate, algoritmi dichiarati accessori ma in realtà decisivi per la funzione clinica. Il risultato, più che una gara, rischia di diventare una seduta spiritica sulla conformità.

Cosa devono verificare RUP e commissione di gara

Anche la commissione giudicatrice deve svolgere un ruolo non ornamentale. Non può limitarsi a leggere la scheda tecnica come se fosse una brochure commerciale. Deve verificare se la documentazione prodotta dall’operatore copra effettivamente il software offerto. Deve chiedersi se la marcatura CE riguardi solo l’apparecchiatura fisica o anche il programma che elabora i dati. Deve controllare se la versione software indicata nell’offerta coincida con quella riportata nella documentazione di conformità. Deve valutare se la destinazione d’uso dichiarata dal fabbricante sia compatibile con le funzioni richieste dal capitolato. Deve accertare se eventuali moduli opzionali o aggiornamenti siano inclusi nel perimetro regolatorio.

Qui il soccorso istruttorio incontra un limite evidente. La stazione appaltante può chiedere chiarimenti su documentazione già esistente, può acquisire precisazioni, può comprendere meglio la portata di una certificazione prodotta. Non può però consentire la formazione postuma della conformità tecnica, la sostituzione sostanziale del prodotto o la produzione ex novo di una marcatura CE inesistente al momento dell’offerta. La marcatura CE non è una dimenticanza amministrativa assimilabile a un allegato caricato male. È il presupposto regolatorio che legittima l’immissione sul mercato e l’utilizzo del dispositivo per la finalità dichiarata.

Marcatura CE, equivalenza e soccorso istruttorio

Sul piano giuridico, la marcatura CE del software dispositivo medico è una qualità oggettiva del bene offerto. Non è un requisito soggettivo dell’operatore economico, né una mera dichiarazione di affidabilità professionale. Riguarda l’idoneità del prodotto a essere legittimamente fornito e utilizzato. Se manca, l’offerta non è semplicemente carente di un documento; rischia di essere inidonea rispetto all’oggetto dell’appalto. E quando l’offerta è inidonea sul piano tecnico-regolatorio, non può essere salvata con formule rassicuranti sulla futura conformità, sull’impegno all’adeguamento o sulla generica equivalenza funzionale.

Il principio di equivalenza

Il principio di equivalenza, spesso invocato nelle gare tecniche come passepartout universale, non può essere deformato fino a coprire la mancanza di conformità regolatoria. Un software privo della necessaria marcatura CE non è equivalente a un software marcato, se quella marcatura è richiesta dalla normativa applicabile in ragione della funzione medicale svolta. L’equivalenza opera tra soluzioni tecniche diverse ma legittimamente immesse sul mercato e idonee a soddisfare la medesima esigenza. Non serve a rendere competitivo ciò che non possiede il requisito regolatorio minimo per essere utilizzato.

Il principio del risultato

Il principio del risultato impone la stessa conclusione. Il risultato non è aggiudicare rapidamente una fornitura sanitaria, installare un software e sperare che nessuno si accorga del problema. Il risultato è acquisire una tecnologia conforme, sicura, utilizzabile, controllabile e coerente con la funzione clinica richiesta. Un’aggiudicazione che ignora la marcatura CE del software dispositivo medico non produce efficienza, ma rischio: rischio di annullamento, rischio di inutilizzabilità, rischio di responsabilità, rischio per la sicurezza del paziente, rischio di blocco della fornitura, rischio di pagamento per un bene non conforme.

Il principio di fiducia

Il principio di fiducia non cambia il quadro. Fidarsi del RUP e della commissione non significa autorizzarli a presumere ciò che deve essere verificato. La fiducia, nel nuovo Codice, è responsabilizzazione tecnica e amministrativa. Richiede decisioni motivate, controlli proporzionati, atti coerenti e capacità di governare la complessità. In una gara sanitaria, la complessità regolatoria non è un fastidio: è parte dell’oggetto dell’affidamento. Chi la ignora non sta semplificando. Sta solo spostando il problema alla fase successiva, dove normalmente costa di più.

Anche gli operatori economici devono cambiare approccio. Non basta inserire in offerta una formula generica del tipo “sistema conforme alla normativa vigente”. Non basta allegare la marcatura dell’apparecchiatura principale e lasciare nell’ombra il software. Non basta dichiarare che il programma “supporta” il dispositivo, “dialoga” con esso o “fa parte della soluzione”. Occorre dimostrare puntualmente la copertura regolatoria della componente software, soprattutto quando essa svolge funzioni diagnostiche, terapeutiche, di monitoraggio o di produzione di informazioni cliniche. La conformità non si racconta; si documenta.

Aggiornamenti, collaudo e sicurezza del software sanitario

La questione diventa ancora più delicata in presenza di aggiornamenti software. Il software sanitario non è statico. Viene aggiornato, corretto, integrato, potenziato. Ogni aggiornamento può incidere sulla destinazione d’uso, sulle prestazioni, sulla sicurezza, sulla classe di rischio e sulla validità della conformità. Il contratto pubblico deve quindi disciplinare in modo puntuale gli obblighi del fornitore: mantenimento della marcatura CE per tutta la durata contrattuale, comunicazione degli aggiornamenti, tracciabilità delle versioni, validazione delle modifiche, gestione delle patch, continuità operativa, interoperabilità, sicurezza informatica e conservazione della documentazione regolatoria.

Il collaudo o la verifica di conformità non possono ridursi alla constatazione che il software si apra, mostri schermate convincenti e produca qualche report. Devono accertare che il sistema installato corrisponda a quello offerto e certificato. Versione software, moduli attivati, funzionalità abilitate, documentazione del fabbricante, manuali, dichiarazioni di conformità e certificazioni devono essere coerenti. Altrimenti la stazione appaltante rischia di accettare un prodotto diverso da quello valutato, oppure un software privo della copertura regolatoria necessaria per l’uso clinico effettivo.

Non va trascurato nemmeno il rapporto con la protezione dei dati personali e la cybersicurezza. Molti software dispositivi medici trattano dati sanitari, comunicano con sistemi aziendali, generano flussi informativi, si integrano con cartelle cliniche elettroniche, PACS, LIS, RIS, sistemi di laboratorio o piattaforme di telemedicina. La marcatura CE non esaurisce ogni profilo di conformità, ma rappresenta un presidio imprescindibile della dimensione medicale del prodotto. Accanto a essa devono essere valutati sicurezza informatica, interoperabilità, disponibilità del dato, tracciabilità degli accessi, gestione dei log, responsabilità del fornitore, localizzazione dei dati e conformità al GDPR.

Come evitare rischi negli appalti di software medicale

Per le aziende sanitarie, le centrali di committenza e le stazioni appaltanti che acquistano tecnologie biomedicali, la lezione è chiara. Il capitolato deve essere costruito con un approccio multidisciplinare. Il RUP non può essere lasciato solo davanti a prodotti tecnologicamente complessi. Devono essere coinvolti ingegneria clinica, direzioni sanitarie, utilizzatori, servizi informativi, responsabile della protezione dei dati, sicurezza informatica e, quando necessario, farmacisti, fisici sanitari e specialisti clinici. L’appalto sanitario moderno non si governa con capitolati copiati da gare precedenti e aggiornati cambiando il nome del dispositivo. Quella è archeologia amministrativa, non procurement sanitario.

La conseguenza contenziosa è altrettanto evidente. Un concorrente che offre un software privo della necessaria marcatura CE, quando tale software ha natura di dispositivo medico, espone l’aggiudicazione a censure robuste. La stazione appaltante che non verifica il punto rischia di ammettere un’offerta sostanzialmente non conforme. L’operatore escluso o secondo graduato potrà contestare la violazione della lex specialis, della normativa sui dispositivi medici, del principio di par condicio e della corretta comparabilità delle offerte. In una gara sanitaria, infatti, mettere sullo stesso piano un prodotto pienamente conforme e uno che non documenta la conformità del software significa alterare la competizione.

C’è poi un tema di responsabilità pubblica. L’acquisto di un dispositivo medico non conforme non è solo un errore di gara. Può incidere sull’erogazione delle prestazioni sanitarie, sulla sicurezza dei pazienti, sulla continuità dei servizi, sull’utilizzabilità dell’investimento, sulla rendicontazione di fondi vincolati e sulla responsabilità gestionale dell’amministrazione. Il danno non è soltanto processuale. Può essere organizzativo, finanziario, clinico e reputazionale.

Software dispositivo medico: la conformità non si promette

Il messaggio finale, quindi, è netto. Il software sanitario non è un’entità invisibile che può scivolare tra le pieghe del capitolato. Se svolge una funzione medica, deve essere trattato come dispositivo medico. Se è dispositivo medico, deve essere conforme al Regolamento UE 2017/745. Se deve essere conforme, la marcatura CE deve essere chiara, specifica, riferibile al prodotto offerto, alla versione software, alla destinazione d’uso e alle funzionalità richieste.

Le stazioni appaltanti devono smettere di chiedere “sistemi completi” senza capire come siano composti. Devono scrivere capitolati capaci di distinguere hardware, software, moduli, algoritmi, funzioni cliniche e servizi accessori. Devono pretendere prove regolatorie puntuali. Devono valutare le offerte con competenze adeguate. Devono collaudare ciò che hanno realmente acquistato, non ciò che sperano di avere acquistato.

Gli operatori economici, dal canto loro, devono smettere di trattare il software come una zona franca documentale. Se il programma partecipa alla diagnosi, al monitoraggio, al trattamento o alla produzione di informazioni cliniche, non basta dire che funziona. Deve essere legittimamente utilizzabile. E nel diritto degli appalti pubblici, come nella medicina, la diagnosi sbagliata costa. Solo che qui il paziente rischia di essere la gara, e la terapia d’urgenza si chiama annullamento.

The post Appalti sanitari: il software senza marcatura CE non si cura con le promesse appeared first on lentepubblica.it.