← Vedi la demo live

Case study · progetto demo

Prenotare senza rinunciare alla privacy dei dati sanitari

Un form di prenotazione per uno studio dentistico, pensato per raccogliere dati sensibili in modo esplicito, minimale e utilizzabile anche senza JavaScript.

Il problema

Chi prenota una visita medica online lascia quasi sempre più dati di quanti servano davvero, in un modulo unico con una sola casella "accetto la privacy" in fondo. Per uno studio dentistico questo è un problema doppio: da un lato il motivo della visita e le note cliniche sono dati relativi alla salute — categoria particolare secondo l'art. 9 GDPR, non un campo di testo qualunque — dall'altro un modulo che "sembra" curato nella forma ma tratta il consenso sanitario come un dettaglio genera più diffidenza di quanta ne risolva, proprio nel momento in cui il paziente dovrebbe sentirsi più tutelato.

Contesto e vincoli

Progetto demo realizzato come esercizio di posizionamento per un profilo che tratta la conformità GDPR come parte del lavoro tecnico, non come una nota a margine aggiunta a fine progetto. Vincoli dichiarati:

Processo e decisioni

La decisione più rilevante è stata trattare il form come l'elemento centrale della pagina, non come un accessorio in fondo: se il punto del progetto è "prenotare in sicurezza", il modulo doveva stare subito visibile, accanto alla headline, non dopo tre sezioni di presentazione dello studio.

Tecnicamente, il form usa attributi HTML nativi (required, type="tel" con pattern, type="date") per la validazione di base, che funziona in ogni browser senza una riga di JavaScript. Lo script in js/main.js aggiunge solo un livello di miglioramento: messaggi di errore più chiari e un annuncio per chi usa uno screen reader, oltre a disabilitare il pulsante durante l'invio per evitare doppie richieste. Se quello script non si carica — rete lenta, estensione che blocca script, preferenza dell'utente — il form si invia comunque tramite una normale richiesta POST verso una pagina di conferma statica (grazie.html), verificabile aprendo quella pagina direttamente.

Sul consenso, la scelta è stata separare fisicamente le due caselle dentro un fieldset dedicato, con la seconda — quella sui dati sanitari — evidenziata visivamente e collegata a un testo che nomina esplicitamente l'art. 9 GDPR, invece di un generico "accetto la privacy policy". Ho aggiunto anche un suggerimento nel campo note ("evita di indicare diagnosi qui: ne parliamo alla visita") per scoraggiare la condivisione non necessaria di dati clinici, invece di limitarmi a renderla tecnicamente possibile.

Soluzione

Il risultato è una pagina che funziona a due livelli sovrapposti: un livello base HTML che copre l'intero percorso di prenotazione (compilazione, validazione, invio, conferma) senza dipendenze, e un livello di miglioramento JavaScript che rende l'esperienza più accessibile senza mai diventare un requisito. La stessa logica vale per la privacy: il consenso minimo necessario per prenotare è uno solo; il secondo consenso, quello sanitario, è sempre una scelta esplicita e mai la via di minor resistenza.

Risultati

0script di terze parti
0font esterni caricati
2consensi distinti, nessuno preselezionato
~17 KBpeso totale HTML+CSS+JS

Il peso totale della pagina (HTML, CSS e JavaScript inclusi) è di circa 17 KB non compressi — misurato direttamente sui file, non stimato — perché non ci sono font o script esterni da scaricare prima che il form sia utilizzabile. È un numero che conta soprattutto per chi prenota da mobile, magari da un parcheggio con poco segnale prima di entrare in ufficio.

Nota: questo è un progetto dimostrativo realizzato a scopo di portfolio. Studio, indirizzo e recapiti sono fittizi; i testi legali riprodotti nella pagina privacy illustrano una struttura corretta ma non costituiscono consulenza legale.