Misure tecniche e organizzative — audit trail clinico e retention policy
Bozza — da validare legalmenteOgni scrittura (creazione, modifica, cancellazione) sui dati clinici di un paziente viene registrata in una tabella dedicata (patient_audit_log), indipendentemente dalla pagina o funzione dell'applicazione da cui l'operazione è stata effettuata.
La registrazione avviene tramite trigger a livello di database, non tramite chiamate dal codice dell'applicazione. Questa scelta è deliberata: un trigger di database si attiva su ogni scrittura reale sulla tabella, indipendentemente da quale pagina, funzione o eventuale bug lato client l'abbia generata — a differenza di una chiamata esplicita nel codice, che può essere dimenticata in una nuova funzionalità o fallire silenziosamente senza che nessuno se ne accorga.
| Campo | Contenuto |
|---|---|
| Paziente | La cartella clinica a cui l'evento si riferisce. |
| Autore | L'utente autenticato che ha effettuato l'operazione (professionista titolare, collaboratore di studio, o il paziente stesso per le azioni che gli sono consentite, es. caricamento foto diario). |
| Tabella e operazione | Es. piani_update, note_specialistiche_delete. |
| Dettaglio — creazione | Identificativo del record creato. |
| Dettaglio — modifica | Elenco dei campi modificati, con valore precedente e nuovo per ciascuno (esclusi i campi di contenuto clinico esteso — es. il testo di un piano alimentare — il cui valore attuale resta comunque sempre consultabile nella cartella stessa). |
| Dettaglio — cancellazione | Copia completa del record cancellato (unico punto in cui quel contenuto resta consultabile dopo la cancellazione). |
L'audit trail copre tutte le tabelle che contengono dati clinici del paziente: cartelle, piani alimentari, NCPt, bioimpedenziometrie (BIA), schede di valutazione, note specialistiche (incluse le pagine specialistiche per patologia), esami biochimici, documenti e foto caricati, percorsi nutrizionali multi-settimana, collegamento paziente↔professionista, documenti/consensi inviati.
Non copre invece dati non clinici del professionista (es. ricette personali non condivise, template di piano, contabilità/fatture) né l'agenda personale — al di fuori dello scopo di un audit trail sul fascicolo del paziente.
Lo storico modifiche di una cartella è visibile solo al professionista titolare e ai collaboratori del suo studio (stesso perimetro di accesso dei dati clinici stessi), tramite Row Level Security a livello di database. Non è mai visibile al paziente. Non è modificabile né cancellabile da nessun utente applicativo: solo il meccanismo di conservazione automatica descritto in §2 può rimuoverne delle voci, e solo una volta scaduto il periodo di conservazione.
Il principio di limitazione della conservazione (art. 5.1.e GDPR) impone di non conservare i dati personali più a lungo del necessario. Per un dato clinico, "necessario" coincide di norma con la durata prevista per la documentazione sanitaria dalla prassi professionale italiana.
| Categoria | Periodo di conservazione | Meccanismo |
|---|---|---|
| Dati clinici del paziente (cartella, piani, NCPt, BIA, schede, note, esami, documenti) | Durata del rapporto terapeutico + 10 anni, salvo esercizio del diritto all'oblio dal paziente tramite il professionista. | Cancellazione manuale dal professionista (nessuna cancellazione automatica dei dati clinici stessi). |
Audit trail (patient_audit_log) | Stessa regola del dato che documenta: non ha senso che la prova di "chi ha scritto cosa" scada prima del dato clinico a cui si riferisce. | Automatico — job mensile che rimuove solo le voci di cartelle archiviate da oltre 10 anni. Finché una cartella non è archiviata, il rapporto è considerato attivo e nulla viene rimosso. |
| Voci di audit orfane (cartella cancellata fisicamente dal database) | 10 anni dalla data dell'evento stesso. | Automatico, stesso job mensile — rete di sicurezza per il caso limite in cui la data di fine rapporto non sia più ricostruibile. |
| Log di accesso/autenticazione | 12 mesi. | Vedi Registro dei Trattamenti, voce A.1. |
La data di archiviazione di una cartella (archived_at) viene registrata automaticamente dal database nel momento in cui il professionista archivia o riattiva un paziente — non è mai impostata dal codice dell'applicazione, per lo stesso motivo per cui l'audit trail stesso è gestito a livello di database: evitare che una dimenticanza lato client lasci un dato senza data di riferimento per la conservazione.
Trigger di audit, colonna archived_at e job di conservazione automatica sono implementati in supabase_setup.sql (SEZIONE 50) tramite trigger PostgreSQL e job pianificato (pg_cron, esecuzione mensile). Il job di conservazione può essere sospeso o modificato senza intervento sul codice applicativo, direttamente a livello di database.
Per domande relative alla presente politica, contatta il Titolare/Responsabile all'indirizzo indicato nell'Informativa Privacy.
Ultimo aggiornamento: Agosto 2026 — NutriPlan-Pro · Bozza v0.1, non ancora validata legalmente