La domanda arriva sempre allo stesso punto della conversazione: "Va bene, ma è a norma GDPR?". È la domanda giusta, ed è anche quella a cui nessuno può rispondere con un sì secco, perché la conformità non è una proprietà del software. Il GDPR non certifica programmi: definisce obblighi per chi tratta i dati. Uno studio medico può usare in modo conforme uno strumento con infrastruttura americana e può violare il regolamento con un gestionale italiano, a seconda di come lo configura e di cosa ci mette dentro.

Questo articolo mette in fila ciò che va verificato, deciso e scritto prima di far entrare GoHighLevel — o qualunque CRM equivalente — in uno studio medico europeo. Non è un parere legale: è la lista di controllo che usiamo prima di attivare un sistema, da far validare al proprio consulente privacy.

Chi è titolare e chi è responsabile

Il primo punto è anche il più frainteso. Lo studio medico è titolare del trattamento: decide quali dati raccogliere, per quali finalità e per quanto tempo. La piattaforma è responsabile del trattamento, cioè tratta quei dati per conto dello studio e solo secondo le sue istruzioni.

Da qui discendono conseguenze pratiche che nessun fornitore può assumersi al posto tuo:

  • l'informativa ai pazienti la scrive lo studio, e deve menzionare l'uso di strumenti terzi per le comunicazioni;
  • il registro dei trattamenti lo tiene lo studio, e deve includere il CRM tra i sistemi;
  • la valutazione d'impatto, quando serve, la fa lo studio;
  • le richieste di accesso, rettifica e cancellazione le riceve e le evade lo studio, usando gli strumenti che la piattaforma mette a disposizione.

Se un fornitore ti dice "pensiamo noi al GDPR", ha appena descritto una cosa che non può fare. Può darti gli strumenti; la responsabilità resta tua.

L'accordo sul trattamento (DPA)

L'articolo 28 del GDPR impone un contratto scritto tra titolare e responsabile. Senza quel documento firmato, l'uso della piattaforma per dati di pazienti è irregolare a prescindere da quanto è sicura la tecnologia.

Cosa deve contenere: oggetto e durata del trattamento, categorie di dati e di interessati, istruzioni documentate del titolare, obbligo di riservatezza, misure di sicurezza, disciplina dei sub-responsabili, assistenza al titolare per i diritti degli interessati e per le violazioni, sorte dei dati alla fine del rapporto.

HighLevel mette a disposizione un accordo per il trattamento dei dati e materiale sulla conformità nella propria documentazione; condizioni, versione applicabile e modalità di accettazione vanno verificate direttamente sul contratto vigente al momento dell'attivazione [DA VERIFICARE], perché questi documenti cambiano nel tempo e un articolo non è una fonte contrattuale. Due controlli da fare a mano: l'elenco aggiornato dei sub-responsabili e la procedura di notifica delle violazioni con i tempi.

Dove stanno i dati

HighLevel è una società statunitense e la sua infrastruttura poggia su fornitori cloud globali; la localizzazione effettiva dei dati per un account europeo e l'eventuale disponibilità di un'opzione di residenza dei dati nell'Unione Europea vanno verificate con il fornitore [DA VERIFICARE].

Il punto normativo, comunque, non è "i dati devono stare in Europa": il GDPR ammette i trasferimenti verso paesi terzi se assistiti da garanzie adeguate. Per gli Stati Uniti lo strumento oggi rilevante è la decisione di adeguatezza sul Data Privacy Framework, affiancata o sostituita dalle clausole contrattuali tipo con valutazione del trasferimento. Le domande concrete da porre al fornitore sono tre:

  1. Su quale base giuridica avviene il trasferimento (adesione al framework, clausole tipo, o entrambe)?
  2. Esiste una valutazione del rischio del trasferimento che lo studio possa allegare alla propria documentazione?
  3. Quali sub-responsabili trattano i dati e dove?

Le risposte vanno conservate. In caso di controllo, la domanda non sarà "il software era conforme", ma "come hai valutato e documentato la scelta".

Vale la pena aggiungere una nota di realismo: le stesse domande valgono per la posta elettronica, per i servizi di videoconferenza e per il gestionale in cloud che lo studio già usa. Il CRM non introduce un problema nuovo, rende visibile un problema che spesso esiste già senza documentazione.

HIPAA non è il GDPR

È l'equivoco più diffuso tra chi valuta piattaforme americane per la sanità.

HighLevel propone un componente aggiuntivo orientato alla conformità HIPAA [DA VERIFICARE: disponibilità, condizioni e costo attuali]. HIPAA è la normativa statunitense sui dati sanitari: risponde a una logica diversa, si applica a soggetti definiti dal diritto americano e non produce alcun effetto di conformità in Europa. Attivare quel modulo non rende un trattamento conforme al GDPR, così come firmare un accordo europeo non rende conformi a HIPAA.

Utile capire cosa quel componente porta comunque di buono, sul piano pratico: in genere si tratta di controlli di accesso più stringenti, tracciamento delle operazioni e restrizioni sul trattamento di certe categorie di dati. Sono misure di sicurezza che hanno valore anche in ottica europea, ma vanno valutate come misure tecniche ai sensi dell'articolo 32 del GDPR, non come un bollino di conformità.

Cosa non va nel CRM

Qui sta la scelta di progetto che risolve la maggior parte dei problemi a monte, ed è una scelta organizzativa, non tecnica.

I dati relativi alla salute sono categorie particolari ai sensi dell'articolo 9 del GDPR: la loro presenza alza il livello di rischio, allunga la lista degli adempimenti e rende molto più probabile la necessità di una valutazione d'impatto. La strada semplice è non farli entrare.

Nel CRM stanno: nome, recapiti, canale preferito, fonte del contatto, stato della richiesta in termini logistici, consensi, date degli appuntamenti, storico delle comunicazioni inviate.

Nel CRM non stanno: diagnosi, terapie, referti, esami, annotazioni cliniche, motivo della visita quando rivela una condizione, categorie di prestazione che equivalgono a una diagnosi. La cartella clinica resta nel gestionale sanitario, con i suoi obblighi e i suoi accessi.

Attenzione al punto meno ovvio: la separazione si rompe dai dettagli. Un tag chiamato come una patologia, una nota della segreteria scritta di fretta, un nome di calendario che descrive la prestazione, un campo "note" usato come diario. Servono regole scritte su cosa si può digitare e una revisione periodica di tag e campi: è il tipo di manutenzione che nessuno programma e che evita i guai. Il tema generale è trattato nell'articolo su CRM, GDPR e consensi in sanità.

Consensi e basi giuridiche, senza confusione

Un CRM non "richiede il consenso": ogni trattamento ha la sua base giuridica, e distinguerle evita sia gli eccessi sia le violazioni.

  • Promemoria e comunicazioni di servizio su un appuntamento già fissato: sono funzionali all'esecuzione della prestazione richiesta dal paziente, non servono consensi marketing.
  • Recall e comunicazioni promozionali verso chi non ha un appuntamento in agenda: serve un consenso marketing specifico, documentato e revocabile. Il tag del consenso deve essere una condizione dei workflow, non un promemoria mentale.
  • Comunicazioni verso colleghi e professionisti (per esempio una guida scaricata dal sito): pubblico B2B, regole diverse, ma disiscrizione sempre disponibile.

Il consenso, quando serve, va tracciato: quando è stato raccolto, come, con quale testo. Una casella spuntata di cui nessuno sa l'origine, in caso di contestazione, vale come nessun consenso. E la revoca va eseguita ovunque, non solo nella lista da cui è arrivata la richiesta.

Ricordiamo anche il vincolo che viene da un'altra normativa e che il CRM non conosce: verso i pazienti non si inviano sconti, offerte o promozioni, perché la legge 145/2018, come modificata dal decreto-legge 69/2023, vieta gli elementi attrattivi e suggestivi nella comunicazione sanitaria. Nessuna configurazione tecnica ti protegge da un testo scritto male.

Diritti degli interessati e conservazione

Tre cose da verificare prima di andare a regime, perché si scoprono sempre nel momento peggiore.

Estrazione. Se un paziente chiede copia dei suoi dati, lo studio deve saperli estrarre in modo completo: contatto, comunicazioni inviate, tag, note. Vale la pena provarlo una volta su un contatto di prova.

Cancellazione. La cancellazione deve essere effettiva, comprese le copie nelle liste e nei sistemi collegati, e va documentata. Va anche capito cosa resta nei backup e per quanto tempo [DA VERIFICARE con il fornitore].

Conservazione. Il GDPR chiede di non tenere i dati oltre il necessario. Serve una politica scritta: per quanto si conserva un contatto che non è mai diventato paziente, per quanto lo storico delle comunicazioni, cosa succede ai dati se lo studio smette di usare la piattaforma. Quest'ultimo punto — restituzione e cancellazione a fine rapporto — deve essere nel DPA.

In sintesi operativa

Prima di attivare il sistema, lo studio dovrebbe avere: accordo sul trattamento firmato e archiviato, elenco dei sub-responsabili, base giuridica del trasferimento extra-UE documentata, informativa aggiornata, registro dei trattamenti aggiornato, regole scritte su cosa non entra nel CRM, mappa delle basi giuridiche per tipo di comunicazione, politica di conservazione, procedura per i diritti degli interessati, e la verifica sul campo di estrazione e cancellazione.

È una lista lunga e nessuna piattaforma la spunta al posto tuo. Ma è una lista finita: si fa una volta, si documenta e si aggiorna quando cambia qualcosa. Il quadro completo su cosa fa la piattaforma è nella guida a GoHighLevel in italiano e nella pagina GoHighLevel per studi medici; i workflow che ne derivano, con i loro paletti, sono nell'articolo sulle automazioni per lo studio medico.

Domande frequenti

GoHighLevel è conforme al GDPR?

La domanda è mal posta: il GDPR non certifica software. La piattaforma mette a disposizione strumenti contrattuali e tecnici; la conformità dipende da come lo studio configura il sistema, da cosa ci inserisce e da quali documenti tiene.

I dati dei pazienti finiscono negli Stati Uniti?

HighLevel è una società statunitense con infrastruttura cloud globale. La localizzazione effettiva per un account europeo e l'eventuale opzione di residenza dei dati nell'UE vanno verificate direttamente con il fornitore [DA VERIFICARE]. Il trasferimento è comunque ammesso se assistito da garanzie adeguate e documentato.

Serve un accordo scritto con la piattaforma?

Sì. L'articolo 28 del GDPR lo impone. Va reperito, letto, accettato secondo la procedura del fornitore e conservato insieme all'elenco dei sub-responsabili.

Il modulo HIPAA mi mette a posto con il GDPR?

No. HIPAA è normativa statunitense e non produce conformità europea. Le misure tecniche che quel modulo introduce possono essere utili, ma vanno valutate come misure di sicurezza ai sensi dell'articolo 32, non come conformità.

Posso registrare la diagnosi nel CRM per personalizzare i messaggi?

No, ed è anche inutile: i messaggi conformi verso i pazienti sono generici per definizione. I dati sulla salute restano nel gestionale clinico; nel CRM entrano solo dati anagrafici, logistici e di consenso.

Chi mi aiuta a impostare tutto questo?

La parte documentale va condivisa con il proprio consulente privacy; la configurazione tecnica del CRM può farla lo studio o un partner esterno. Se vuoi che valutiamo insieme lo stato attuale del tuo studio, richiedi una valutazione senza impegno; per il quadro generale c'è la guida gratuita al marketing medico.