Salta al contenuto
Qoode
  • Sanità digitale

App e dati sanitari: cosa serve davvero per trattarli

Perché i dati sanitari non sono dati normali, i cinque requisiti che vanno progettati dentro il software e cosa chiedere a un fornitore prima di firmare.

Qoode6 min di lettura
I cinque requisiti per trattare dati sanitari in un software: categoria particolare di dati con base giuridica esplicita ai sensi dell'articolo 9 del GDPR, registro degli accessi, cifratura e separazione fra dati identificativi e clinici, regole di conservazione e cancellazione, valutazione d'impatto obbligatoria prima della produzione.

Un'app che gestisce appuntamenti è un'app. La stessa app, se accanto all'appuntamento c'è il motivo della visita, diventa un'altra cosa: sta trattando dati sanitari, e le regole cambiano prima ancora che qualcuno scriva una riga di codice.

Questa guida spiega perché sono diversi, quali requisiti vanno progettati dentro il software invece che aggiunti dopo, e cosa chiedere a un fornitore prima di affidargli le cartelle dei vostri pazienti.

Perché non sono dati normali

L'articolo 9 del GDPR classifica i dati relativi alla salute come categoria particolare, e ne vieta il trattamento salvo eccezioni specifiche. Non è una formula: capovolge il punto di partenza. Per un dato ordinario si cerca una base giuridica fra quelle disponibili; per un dato sanitario si parte da un divieto e si dimostra di rientrare in un'eccezione.

La conseguenza pratica più fraintesa riguarda il consenso. Un consenso generico raccolto con una spunta non basta: quando il trattamento serve a finalità di cura, la base giuridica è tipicamente un'altra, e chiedere un consenso dove non serve non solo è inutile — è fuorviante, perché fa credere al paziente di poterlo revocare fermando la cura.

Le sanzioni previste dal GDPR per le violazioni più gravi arrivano a venti milioni di euro o al 4% del fatturato mondiale annuo, il maggiore dei due. Su questa categoria di dati non è un'ipotesi teorica.

I cinque requisiti che si progettano dentro

I cinque requisiti per trattare dati sanitari in un software: categoria particolare di dati con base giuridica esplicita ai sensi dell'articolo 9 del GDPR, registro degli accessi, cifratura e separazione fra dati identificativi e clinici, regole di conservazione e cancellazione, valutazione d'impatto obbligatoria prima della produzione.
Sono requisiti che si progettano dentro. Un registro degli accessi non si aggiunge a un anno di cartelle mai tracciate.

1. Il registro degli accessi

Chi ha aperto quale cartella, quando, da dove. È il requisito che rende dimostrabile tutto il resto: senza, davanti a una contestazione non potete provare che l'accesso è stato legittimo, e nemmeno accorgervi che non lo è stato.

Ed è il requisito che non si aggiunge dopo: un registro attivato oggi non dice niente su quello che è successo l'anno scorso.

2. Accesso per ruolo, non per persona

La segretaria vede l'agenda e i recapiti, non il referto. Il medico vede le proprie cartelle; quelle dei colleghi sono una scelta esplicita e tracciata, non un'impostazione predefinita.

In uno studio con più professionisti è la decisione più delicata e va presa prima: rifarla dopo significa rivedere ogni schermata.

3. Cifratura e separazione

I dati vanno cifrati a riposo e in transito, e l'architettura dovrebbe permettere di separare i dati identificativi da quelli clinici. Serve per la ricerca, per le statistiche e per limitare il danno di una violazione: un archivio di referti senza nomi vale molto meno per chi lo ruba.

4. Conservazione e cancellazione

Per quanto tempo si tengono i dati e come si cancellano davvero. La seconda parte è quella difficile: cancellare da una tabella non basta se lo stesso dato vive in sei mesi di backup.

Serve una politica scritta prima e implementata nel sistema, non una promessa nell'informativa.

5. La valutazione d'impatto

Per un trattamento su larga scala di dati sanitari la valutazione d'impatto sulla protezione dei dati è quasi sempre obbligatoria. Va fatta prima di andare in produzione, e serve a decidere l'architettura — non è un documento da produrre a sistema finito per metterlo in un cassetto.

Dove stanno i dati, e perché conta

La domanda «dove sono ospitati» ha una risposta che va oltre la geografia. Contano tre cose insieme: in quale Paese stanno fisicamente, chi ha accesso amministrativo all'infrastruttura e a quale giurisdizione risponde il fornitore.

  • Un fornitore europeo con data center europei è la posizione più semplice da difendere.
  • Un fornitore extraeuropeo con data center in Europa richiede una valutazione ulteriore: la sede della società conta, non solo quella dei server.
  • I trasferimenti verso Paesi terzi hanno una disciplina propria, e vanno mappati anche quando sono solo un servizio di monitoraggio o di posta.
  • I subfornitori del vostro fornitore sono anch'essi parte della catena: vanno dichiarati, e la lista va aggiornata.

Cosa chiedere a un fornitore, prima di firmare

  1. 01Il registro degli accessi esiste, ed è consultabile da noi senza chiedervelo?
  2. 02Dove stanno i dati e chi altro può accedervi, subfornitori compresi?
  3. 03Come si esportano tutti i dati dei nostri pazienti, in che formato e in quanto tempo?
  4. 04Che cosa succede in caso di violazione: chi ci avvisa, entro quanto, e chi notifica al Garante?
  5. 05Siete disponibili a firmare un accordo come responsabili del trattamento con questi contenuti?

Sulla quarta domanda vale la pena insistere: il termine per la notifica di una violazione è di settantadue ore, e comincia da quando ne venite a conoscenza. Se il fornitore vi avvisa dopo una settimana, il problema è vostro.

Sono le stesse domande che ci facciamo noi quando costruiamo per gli ambulatori: le nostre piattaforme per studi medici, studi dentistici e veterinari nascono con queste scelte già prese, perché prenderle dopo costa dieci volte tanto.

Gli errori che vediamo più spesso

  • I referti mandati via chat o su servizi di messaggistica generici, perché è comodo. È il punto più esposto di tutti e il più diffuso.
  • Un account condiviso in segreteria: se tre persone usano lo stesso accesso, il registro non serve a niente.
  • I backup su un disco esterno che sta nello stesso cassetto del computer, non cifrato.
  • Il consenso chiesto per tutto, che confonde il paziente e non copre niente.
  • Il sistema in cloud scelto guardando solo il prezzo, senza aver mai letto chi è il fornitore e dove sono i dati.

Domande frequenti

Serve un DPO per uno studio medico?

Non sempre, ma il trattamento su larga scala di dati sanitari è uno dei casi in cui il responsabile della protezione dei dati è previsto. Per uno studio singolo la valutazione va fatta caso per caso con un consulente; per una struttura con più professionisti la risposta tende al sì.

Posso usare un gestionale generico e aggiungere la privacy dopo?

Potete usarlo, ma il registro degli accessi e la separazione per ruolo o ci sono o non ci sono. Se il prodotto non li ha, non è una configurazione che manca: è un'architettura diversa.

I dati possono stare fuori dall'Unione europea?

Possono, con le garanzie previste per i trasferimenti verso Paesi terzi. La domanda vera è se ne valga la pena: per dati sanitari la posizione più semplice da difendere, davanti a un paziente e davanti a un'autorità, è che restino in Europa.

Il paziente può chiedere la cancellazione della cartella?

Può chiederla, ma il diritto alla cancellazione non è assoluto: gli obblighi di conservazione della documentazione sanitaria prevalgono nei casi previsti. Il sistema deve saper distinguere fra cancellare e limitare il trattamento, che sono due cose diverse.

In sintesi

I dati sanitari partono da un divieto e non da un permesso. Cinque requisiti — registro degli accessi, permessi per ruolo, cifratura e separazione, conservazione e cancellazione, valutazione d'impatto — vanno progettati dentro il software, perché nessuno di essi si aggiunge retroattivamente.

Se avete un sistema in uso e non sapete rispondere alle cinque domande da fare al fornitore, quella verifica vale più di qualunque nuova funzione. Si parte da una conversazione.

  • Dati sanitari
  • GDPR
  • Sanità
  • Sicurezza
Tutti gli articoli