Salute Digitale

La prassi di acquistare il software con la proprietà dei codici sorgenti è obsoleta ed espone la pubblica amministrazione a diversi rischi.

Da un lato c’è il principio del software come prodotto con tutto ciò che ne consegue, in termini di responsabilità del fornitore e di certificazione. Dall’altro l’idea che il possesso dei codici sorgenti possa rendere indipendenti dal fornitore evitando così il fenomeno del lock-in. Ancora oggi, in molte gare ed appalti specifici, si tenta di conciliare questi due aspetti richiedendo, ad esempio, un software certificato MDR, magari classe IIA, la disponibilità a modificarlo secondo le esigenze dell’azienda sanitaria, con la conseguente ricertificazione, e il possesso dei codici sorgenti.

Tutto ciò è un rompicapo per i fornitori e i legali che questi interpellano per dipanare l’ intreccio tra norme e responsabilità. A tal riguardo è molto interessante un quesito che è stato posto a Consip nell’ambito dei chiarimenti alla gara di sanità digitale 4 e che riporto integralmente:

Domanda
Rif. Capitolato Tecnico Generale Par. 4.3 “Contesto normativo”
Il Capitolato Tecnico Generale al paragrafo 4.3 in relazione alla certificazione come dispositivo medico delle piattaforme software oggetto di implementazione riporta quanto segue: “Si precisa che laddove è obbligatorio il rispetto alla finalità d’uso, le piattaforme software implementate dovranno essere riconosciute come dispositivi medici (certificazione MDR) marcati CE sulla base del Regolamento 2017/745 è
entrato in vigore il 26 maggio 2021 abrogando la Direttiva 90/385/CEE (AIMDD) e la Direttiva 93/42/CEE (MDD).”
Al riguardo si chiede di confermare che:

1. Il possesso della certificazione MDR, laddove prevista, della piattaforma oggetto di implementazione non sia un requisito di partecipazione ad un Appalto Specifico o di risposta ad un Ordinativo di Fornitura, bensì debba essere conseguito in corso di esecuzione progettuale ed entro la verifica di conformità del software propedeutica alla rispettiva messa in esercizio. Ciò anche in considerazione del fatto che sia nel caso di adozione di una soluzione di mercato sia nel caso di realizzazione ad hoc, la messa in esercizio della piattaforma oggetto di implementazione necessita in generale di personalizzazioni ed integrazioni rispetto al contesto del singolo progetto che implicherebbe comunque l’attivazione di un processo di certificazione specifico.
2. Nel caso la proprietà della piattaforma oggetto di implementazione sia della singola Amministrazione aderente
   all’AQ e non del Fornitore, anche nei rispettivi codici sorgenti, la responsabilità del conseguimento della certificazione MDR sia dell’Amministrazione aderente medesima, che essendone il Titolare è identificabile a norma del regolamento MDR come il Fabbricante della piattaforma stessa, fermo restando l’impegno del Fornitore a rispettare i requisiti minimi previsti dal regolamento MDR nel processo di produzione del software.

Risposta
Risposta al quesito 1) nel caso di Applati Specifici il requisito di certificazione MDR è demandato dall’Amministrazione contraente, solo nel caso di acquisizione di una soluzione di mercato tramite i servizi accessori, in altri casi come ad esempio per l’Ordinativo di Fornitura (Ordine Diretto) la certificazione non potrà mai essere un requisito di partecipazione ma dovrà essere conseguito in corso di esecuzione progettuale ed entro la verifica di conformità del software propedeutica alla rispettiva messa in esercizio. Risposta al quesito 2) si conferma

La risposta al secondo quesito della domanda afferma il principio che, per Consip, è l’amministrazione che diventa responsabile per il conseguimento della certificazione MDR in quanto titolare e quindi fabbricante della piattaforma software. Ma può un’amministrazione assumere questo ruolo? Possiede i requisiti che ne derivano? È disponibile ad assumersi questa responsabilità?

Il merito di questa risposta è di aver chiarito che non è possibile “avere la botte piena e la moglie ubriaca”. Il software è un prodotto oppure un servizio che va scelto con attenzione, non un semilavorato che si adatta alle proprie esigenze diventandone poi i proprietari. Non è così che si evita il lock-in o che si risparmia. Quanti casi ci sono di gestione con successo e convenienza di un software complesso da parte di terzi e non dello stesso fornitore che l’ha sviluppato (escludendo software di base)?

Il lock-in si può evitare o ridurre adottando architetture realmente a micro-servizi, scegliendo software ad elevata capacità di configurazione e parametrizzazione, disaccoppiando i diversi livelli logici, adottando formati standard per la persistenza e l’accesso ai dati (ad es. HL7 FHIR oppure, meglio ancora, openEHR).

Lasciamo i codici sorgenti a chi, per mestiere, li sviluppa e li evolve nel tempo.