Il 5 marzo 2025 segna una nuova tappa per il settore sanitario digitale europeo: quella della pubblicazione, da parte della Commissione Europea, delle Frequently Asked Questions (FAQ) relative al (recentemente emanato)Regolamento sullo Spazio Europeo dei Dati Sanitari (detto “EHDS” – European Health Data Space).
Un documento che chiarisce molti aspetti pratici e giuridici di questa innovativa, ambiziosa e complessa normativa. Le FAQ, difatti, rappresentano un primo strumento essenziale per tutti gli attori coinvolti nel panorama sanitario europeo, dai pazienti ai professionisti della salute, dalle autorità nazionali alle aziende produttrici di sistemi di cartelle cliniche elettroniche (EHR).
L’EHDS (entrato in vigore nel marzo 2025 ma applicabile dal 26 marzo 2027) mira a rivoluzionare il modo in cui i dati sanitari vengono gestiti, condivisi e utilizzati in Europa, promuovendo sia l’uso primario dei dati (per finalità di cura) che l’uso secondario (per ricerca, innovazione e policymaking).
Come spesso accade con normative così complesse e ambiziose, sorgono dubbi e domande su come applicare concretamente le disposizioni del regolamento. È proprio qui che entrano in gioco le FAQ, con i circa 60 Q&A in cui si articolano, pensate per fornire risposte chiare e dettagliate ai principali interrogativi sollevati dagli stakeholder.
In questo contributo esploreremo i punti salienti delle nuove FAQ: che si sia un operatore sanitario, un ricercatore, un rappresentante di un’autorità pubblica o semplicemente un cittadino interessato a comprendere meglio i propri diritti in materia di dati sanitari, le FAQ in esame offrono una panoramica chiara e abbastanza accessibile su come l’EHDS plasmerà il futuro della sanità digitale in Europa.
Indice degli argomenti
Perché nasce l’EHDS e cosa comporta
Ribadiamo alcuni punti fermi a premessa: l’EHDS nasce con l’obiettivo di rivoluzionare il modo in cui i dati sanitari vengono gestiti, condivisi e utilizzati in Europa. In un contesto in cui i sistemi sanitari degli Stati membri sono spesso frammentati e basati su tecnologie non interoperabili, l’EHDS si propone di creare uno spazio comune europeo per i dati sanitari, garantendo che i cittadini europei possano accedere ai propri dati in modo sicuro e che questi possano essere utilizzati per migliorare l’assistenza sanitaria, la ricerca e l’innovazione.
Da un lato, il Regolamento introduce nuovi diritti per i pazienti (come l’accesso immediato a determinati dati e la possibilità di condividere informazioni per il trattamento, in ogni parte dell’Unione).
Dall’altro, stabilisce nuovi obblighi su produttori di sistemi di Electronic Health Records (EHR – cioè cartelle e dossier sanitari), fornitori di servizi sanitari, autorità pubbliche e, in taluni casi, anche su aziende che detengono dati sanitari in virtù della loro attività (per esempio, produttori di software wellbeing che memorizzano dati di salute).
Tre ne sono i pilastri fondamentali:
- uso primario dei dati: la tutela e l’esercizio dei diritti del paziente sui propri dati sanitari (accesso, condivisione, eventuali restrizioni, portabilità), in tutta Europa;
- EHR systems e requisiti di mercato: obblighi per i produttori (e altri operatori economici) riguardo l’interoperabilità e la registrazione dei sistemi che processano i dati sanitari prioritari (patient summary, prescrizioni elettroniche, referti di laboratorio, immagini e referti di imaging diagnostico, lettere di dimissione ecc.);
- uso secondario dei dati: il vero obiettivo strategico dell’EHDS, cioè il riuso dei dati sanitari per ricerca, policy, innovazione e sviluppo di nuove tecnologie, in un contesto regolamentato che introduce Health Data Access Bodies (HDABs – intermediari che forniscono accesso ai dati condivisi) e regole puntuali per l’accesso e l’uso dei dati.
In sintesi, l’EHDS rappresenta un cambio di paradigma nella gestione dei dati sanitari nell’Unione, con l’obiettivo di migliorare l’assistenza sanitaria, promuovere la ricerca e l’innovazione, e garantire che i diritti dei pazienti siano pienamente rispettati.
È chiaro come la sua implementazione richiederà uno sforzo coordinato da parte di tutti gli attori coinvolti, con particolare attenzione alla sicurezza, alla trasparenza e alla protezione dei dati.
I punti oscuri e da sviluppare dell’EHDS non mancano, ecco perché le FAQ appena pubblicate giungono fin d’ora in soccorso.
L’ambito di applicazione dell’EHDS: quali dati entrano in gioco
Comprendere quali dati siano soggetti all’EHDS non è sempre immediato. Il Regolamento individua i titolari di dati sanitari (“health data holders”) e impone loro di rendere disponibili determinate categorie minime e prioritarie di dati per uso secondario, elencate all’art. 51 EHDS. Stabilire, però, con precisione quali dataset rientrino in tale elencazione può essere complesso, soprattutto per le molteplici tipologie di informazioni sanitarie che ogni organizzazione potrebbe detenere.
Le FAQ ufficiali forniscono allo scopo una tabella che illustra, in modo più pratico rispetto alla norma, come riconoscere i dati effettivamente soggetti alle nuove regole. Questa tabella proprio perché elenca numerosi esempi (dalle cartelle cliniche elettroniche ai dati delle applicazioni “wellness”, fino ai registri nazionali e alle informazioni genetiche), evidenzia la multiformità dei contenuti e la necessità di analizzare caso per caso.
Si veda un estratto della tabella di seguito.
| Categoria di dati | Esempi di ciò che rientra nell’ambito di applicazione | Esempi di ciò che non rientra nell’ambito di applicazione |
| Dati sanitari elettronici da EHR | Le cartelle cliniche elettroniche contengono un’ampia gamma di dati sulla storia medica di un paziente, sui trattamenti e sui risultati generati dagli operatori sanitari durante l’erogazione del trattamento, come la diagnosi e l’elenco dei problemi, gli elenchi dei farmaci e i piani di trattamento. | EHR conservato da un prestatore di assistenza sanitaria che si qualifica come microimpresa (a meno che tale Stato membro non abbia esteso l’obbligo di mettere i dati a disposizione anche a tali soggetti, cfr. art. 50.2 EHDS). |
| Dati sui fattori che incidono sulla salute, compresi i determinanti socioeconomici, ambientali e comportamentali della salute | Ad esempio, analisi dei fattori dello stile di vita (fumo, consumo di alcol, interventi chirurgici, incidenti…). | Dati socioeconomici dettagliati raccolti al di fuori delle strutture sanitarie, o dati puramente ambientali non legati alla salute. |
| Dati aggregati sui bisogni sanitari, sulle risorse destinate all’assistenza sanitaria, sulla fornitura e l’accesso all’assistenza sanitaria, sulla spesa sanitaria e sui finanziamenti | Ad esempio, le risorse destinate all’assistenza sanitaria coprono i dati relativi alla disponibilità e alla distribuzione delle risorse sanitarie, ad esempio: numero di strutture sanitarie (come ospedali, cliniche, case di cura), numero di operatori sanitari (ad esempio, medici, infermieri, medici di base), disponibilità di attrezzature e tecnologie mediche. Si tratta di dati non personali a livello aggregato. | Informazioni a livello individuale sulla spesa sanitaria. |
| Dati sugli agenti patogeni che hanno un impatto sulla salute umana | Raccolte di informazioni sugli agenti patogeni che possono causare malattie nell’uomo, compresi gli agenti patogeni batterici, virali, fungini, parassitari o prionici. | Dati sugli agenti patogeni che incidono solo sulla salute degli animali. |
| Dati amministrativi relativi all’assistenza sanitaria, inclusi dati su dispensazioni, richieste di rimborso e rimborsi | Raccolte di informazioni generate attraverso l’amministrazione dei servizi sanitari, in genere utilizzate per scopi di fatturazione, rimborso e gestione sanitaria. | Dati bancari come i numeri di conto relativi al rimborso. |
L’EHDS fa riferimento a soggetti (pubblici o privati) che, in virtù di un ruolo di controllo sui dati (per es. un ospedale, un’impresa di software che gestisce dati dei pazienti, un ente di ricerca, un’agenzia pubblica), si trovano nella condizione di doverli mettere a disposizione per usi secondari (ricerca, innovazione, policy) secondo le regole stabilite dal Regolamento.
Se un’organizzazione si qualifica come titolare, è tenuta a rispettare le disposizioni dell’art. 51 relative alle categorie di dati.
Il quadro che emerge è piuttosto sfaccettato: la distinzione tra ciò che rientra nell’ambito EHDS e ciò che ne rimane fuori non si esaurisce in semplici definizioni. Spesso occorre valutare concretamente se i dataset in questione contengano o meno dati inclusi nelle categorie “prioritarie” o se abbiano requisiti di accessibilità da parte del titolare (per es. dati generati da dispositivi indossabili ma non accessibili da un backend esterno potrebbero restare esclusi).
Una volta individuata la rilevanza del dataset, i titolari dovranno:
- registrare la disponibilità dei dati presso l’Health Data Access Body (HDAB) competente;
- garantire la sicurezza e la conformità, specie in termini di pseudonimizzazione e processi di condivisione (specialmente per finalità di ricerca);
- rispondere alle eventuali richieste di accesso nel rispetto delle condizioni poste dall’EHDS (per esempio, l’obbligo di utilizzare ambienti di calcolo sicuri).
La tabella nelle FAQ rappresenta un pratico punto di partenza per orientarsi tra le diverse tipologie di informazioni sanitarie e individuare quando si è effettivamente obbligati a fornire i dati.
Vista la varietà di casi possibili, ciascun attore (dalle cliniche agli sviluppatori di software, fino alle istituzioni pubbliche) dovrà effettuare un’attenta valutazione sulle singole basi di dati in proprio possesso, per definire con certezza se e come rientrino nello spettro d’azione dell’EHDS.
Autenticazione sicura e controllo degli accessi
Uno degli aspetti più critici e delicati dell’EHDS è senza dubbio afferente alla sicurezza, più precisamente circa la gestione dell’autenticazione sicura e del controllo degli accessi ai dati sanitari.
In un contesto in cui privacy e sicurezza sono imprescindibili, è fondamentale assicurare che solo personale autorizzato possa consultare dati così delicati.
Le FAQ sottolineano come l’implementazione pratica di questi meccanismi di sicurezza sia tutt’altro che banale: servono soluzioni ben calibrate sia a livello tecnico che organizzativo.
Il sistema di autenticazione prevede l’uso di strumenti riconosciuti a livello europeo, come l’EU Digital Identity Wallet (disciplinato dalla recente revisione del Regolamento eIDAS 2), così da garantire modalità di accesso uniformi a tutti gli utenti (FAQ, Q19).
Resta però da capire se e come gli Stati membri introdurranno procedure di autenticazione a più fattori (c.d. “MFA”): se questa misura non venisse resa obbligatoria, potrebbero emergere maggiori vulnerabilità, come phishing o credential stuffing, a danno soprattutto dei professionisti sanitari che gestiscono grandi volumi di dati estremamente riservati.
Mentre l’identità di un individuo può essere accertata tramite eIDAS, non è detto che questo certifichi automaticamente il suo ruolo (ad esempio quello di medico o infermiere): le FAQ suggeriscono che gli Stati membri possano caricare informazioni specifiche (come il titolo di specializzazione) nei digital wallet (FAQ, Q19).
Esiste il rischio di una frammentazione: se un sistema accetta qualifiche non validate in modo uniforme, si rischiano accessi non autorizzati da parte di soggetti che si presentino come professionisti in un Paese diverso da quello di origine.
A livello di tracciabilità, i sistemi EHR devono documentare chi accede a quali dati e in quale momento (FAQ, Q23). In situazioni di emergenza, è previsto il meccanismo detto “breaking the glass” e che consente ai professionisti di accedere anche alle porzioni di dati che il paziente ha eventualmente deciso di restringere.
È però essenziale che ogni accesso sia loggato in modo preciso, con registrazione di motivazioni d’accesso e ruoli coinvolti.
Se questi log non fossero adeguatamente protetti (tramite crittografia o archiviazione sicura), si rischierebbe di manipolare o sottrarre i log di accesso, vanificando così la trasparenza e le garanzie previste dalle norme (FAQ, Q12).
Dunque, l’efficacia dell’EHDS dipenderà in larga misura dall’attenzione con cui verranno definite e implementate le regole di autenticazione e controllo degli accessi. Solo con un sistema strutturato, che preveda adeguate verifiche di ruolo, procedure di login robuste e logging sicuro, sarà possibile garantire un’effettiva protezione dei dati.
Interoperabilità e rischi dei sistemi EHR
Se l’autenticazione rappresenta il primo filtro di sicurezza, l’interoperabilità è il vero pilastro che permette all’EHDS di funzionare e di sfruttare i dati sanitari in modo efficace tra i vari sistemi.
L’EHDS impone ai sistemi EHR (Electronic Health Record) di adottare formati comuni, come l’EEHRxF (European Electronic Health Record Exchange Format), oltre ad altri componenti armonizzati, per garantire che i dati possano fluire senza intoppi tra i diversi sistemi sanitari, sia a livello nazionale che transfrontaliero.
Si badi: non è obbligatorio per gli operatori usare internamente l’EEHRxF ma devono poter esportare e importare i dati dei pazienti in quel formato.
I sistemi EHR che gestiscono le categorie prioritarie di dati sanitari dovranno incorporare sia la capacità di importare/esportare dati sanitari secondo il formato EEHRxF, nonché un sistema di registrazione interno, in modo che il paziente possa sempre sapere chi ha visualizzato o modificato i suoi dati (trasparenza e tracciabilità).
Inoltre, i sistemi EHR di nuova commercializzazione dovranno superare test di conformità (in un Automated Testing Environment gestito a livello europeo e dagli Stati membri) e ottenere la marcatura CE riferita alla componente di interoperabilità e logging.
Questa standardizzazione, se da un lato facilita lo scambio di dati, dall’altro introduce nuovi rischi che è importante analizzare nel dettaglio: difatti l’adozione di un formato unico come l’EEHRxF facilita lo scambio transfrontaliero di dati sanitari, al contempo crea un target unico per i cyber criminali.
Se una vulnerabilità venisse scoperta nel formato EEHRxF, tutti i sistemi collegati potrebbero essere compromessi. Le FAQ non chiariscono come verranno gestiti gli aggiornamenti di sicurezza per questo formato, né se saranno obbligatori i penetration test (test di sicurezza per identificare vulnerabilità) (FAQ, Q16).
Questo rappresenta un punto critico poiché senza un meccanismo chiaro per aggiornare e testare regolarmente il formato, il rischio di attacchi informatici su larga scala aumenta significativamente.
I produttori di sistemi EHR devono certificare i loro prodotti entro il 2027 ma le FAQ non dettagliano, per ora, i criteri di valutazione specifici per la cybersecurity.
Senza requisiti stringenti, come l’analisi del codice sorgente o test approfonditi di sicurezza, sistemi potenzialmente vulnerabili potrebbero entrare nel mercato (FAQ, Q25).
Questo rappresenta un rischio significativo poiché sistemi non adeguatamente protetti potrebbero diventare un punto di ingresso per attacchi informatici, mettendo a repentaglio la sicurezza dei dati sanitari.
Le modifiche ai sistemi EHR che alterano funzionalità o introducono nuovi rischi richiedono una nuova certificazione; tuttavia, la definizione di “modifica sostanziale” rimane vaga nelle FAQ (FAQ, Q26). Per es. un aggiornamento di firmware (il software integrato nei dispositivi hardware) non testato potrebbe introdurre backdoor (punti di accesso non autorizzati) nel sistema, esponendolo a potenziali attacchi. Senza linee guida chiare su cosa costituisce una “modifica sostanziale”, i produttori potrebbero non essere tenuti a riesaminare la sicurezza dei loro sistemi dopo aggiornamenti critici.
Il database UE dei sistemi EHR certificati migliorerà la trasparenza, consentendo a ospedali e altre strutture sanitarie di verificare la conformità dei prodotti.
Nondimeno questo registro espone i produttori a rischi di OSINT (Open Source Intelligence, ovvero l’uso di informazioni pubblicamente disponibili per scopi di intelligence): gli hacker potrebbero sfruttare il database per identificare versioni obsolete di software o hardware e lanciare attacchi mirati (FAQ, Q27).
Ad esempio, se un produttore non aggiorna tempestivamente un sistema EHR, gli attaccanti potrebbero sfruttare vulnerabilità note per accedere ai dati sanitari.
È fondamentale che le autorità competenti forniscano in seguito linee guida dettagliate e che i produttori adottino pratiche di sicurezza robuste per garantire che i sistemi EHR siano non solo interoperabili, ma anche sicuri e resilienti agli attacchi informatici.
Pseudonimizzazione, anonimizzazione e opt-out: tra compliance e ambiguità
Quando si parla di uso secondario dei dati (per es. per ricerca e policymaking) è inevitabile affrontare il tema della protezione dei dati personali in un contesto in cui le informazioni devono “viaggiare” tra diversi soggetti.
Per questo l’EHDS punta molto sulla pseudonimizzazione come misura chiave a tutela della privacy, di cui le FAQ evidenziano varie sfumature non ancora del tutto chiare.
I dati – prima di confluire negli Health Data Access Bodies (HDAB) per essere elaborati – dovrebbero essere pseudonimizzati dai titolari (es. ospedali). In teoria, quindi, un soggetto invia i dataset già “ripuliti” dai riferimenti diretti all’identità del paziente.
La responsabilità ultima della piena conformità rimane in capo agli HDAB e che devono assicurarsi che le procedure messe in atto siano effettivamente sicure (FAQ, Q45). Non esiste però un modello unico di pseudonimizzazione (tokenizzazione, hashing, ecc.), rischiando di generare pratiche eterogenee e di dubbia comparabilità a livello europeo.
Chi decide di esercitare il diritto di opt-out si aspetta che i propri dati, in linea di massima, non vengano più trattati (almeno per nuovi studi).
Le FAQ rilevano però un caso particolare: se un titolare non è in grado di collegare un set di dati pseudonimizzati a uno specifico individuo – per mancanza di identificatori – diventa impossibile onorare quell’opt-out.
Ciò crea un potenziale paradosso: un paziente pensa di aver escluso i propri dati, in realtà potrebbero rimanere “dentro” un dataset tramite il quale, con tecniche più o meno evolute, potrebbe essere possibile risalire alla sua identità (FAQ Q41, Q42).
Le FAQ ricordano come, in taluni casi specifici, i dati di persone che hanno optato out possano comunque essere utilizzati (per es. pubblico interesse nel settore della sanità pubblica o della medicina del lavoro, come nel caso di attività per la protezione da gravi minacce per la salute a carattere transfrontaliero): il testo però non entra nel dettaglio su come gli HDAB valuteranno e approveranno le richieste di accesso ai dati sanitari elettronici personali di individui che hanno esercitato il diritto di esclusione, né su quali misure tecniche o organizzative dovranno adottare in questi scenari ad alto rischio, dove la tutela della privacy risulta potenzialmente compromessa (FAQ, Q42).
La pseudonimizzazione rappresenta il fulcro dell’approccio di protezione dei dati nell’ambito dell’EHDS, specialmente per l’uso secondario. L’assenza di standard tecnici uniformi e le situazioni limite (come il mancato match tra opt-out e dati pseudonimizzati) mettono in evidenza un certo grado di ambiguità: è un’area in cui i futuri atti di esecuzione e le linee guida delle autorità di controllo potrebbero (e dovrebbero) fornire chiarimenti, così da garantire uniformità di approccio e reale rispetto dei diritti dei pazienti.
Da ultimo, non sarà sempre ben chiaro come distinguere pseudonimizzazione e anonimizzazione: anche i dati anonimizzati possono rimanere sensibili, in particolare nel caso di malattie rare. È necessario adottare standard e misure rigorose per prevenire la reidentificazione e garantire un elevato livello di protezione e sicurezza nel trattamento dei dati sanitari elettronici.
Infrastrutture transfrontaliere, tra sicurezza e complessità
La protezione dei dati sanitari non si ferma entro i confini di un solo Stato: le piattaforme online dell’EHDS nascono proprio per facilitare scambi transfrontalieri, ma pongono sfide impegnative sul piano della cybersecurity.
In particolare, MyHealth@EU (dedicata all’uso primario dei dati) e HealthData@EU (pensata per l’uso secondario) richiedono un’attenzione specifica per garantire sicurezza e affidabilità in un contesto sovranazionale.
MyHealth@EU (uso primario dei dati)
Uno dei punti di forza di MyHealth@EU è la sua architettura decentralizzata point-to-point, priva di un deposito centralizzato. Questo approccio dovrebbe ridurre il rischio di “mega-data breach” ma, al contempo, implica che ciascun nodo nazionale – e quindi ogni Stato membro connesso – adotti standard di sicurezza simili.
Elementi come firewall, crittografia e sistemi di monitoraggio devono essere coordinati in modo armonioso, anche se dalle FAQ non emerge ancora in che modo si procederà a un allineamento effettivo (FAQ, Q17).
Un ulteriore aspetto di complessità riguarda la connessione di Paesi terzi, possibile previa verifica di “equivalenza” nel livello di protezione dei dati. Qui, però, la mancanza di specifiche tecniche dettagliate (ad esempio su protocolli di crittografia end-to-end) potrebbe generare vulnerabilità o “anelli deboli” all’interno della rete (FAQ, Q52), specialmente se si considera la potenziale presenza di rischi geopolitici.
HealthData@EU (uso secondario dei dati)
Sul fronte del riuso dei dati per ricerca e innovazione, HealthData@EU si basa su Secure Processing Environment (SPE), ovvero ambienti protetti dove i dataset possono essere analizzati.
Ma i requisiti per garantire un isolamento solido e un controllo degli accessi continuo non appaiono ancora ben definiti nelle FAQ (FAQ, Q73), se questi ambienti venissero compromessi, il danno potrebbe risultare ingente, perché includerebbe dati sanitari di grande rilevanza.
Inoltre, la piattaforma prevede un catalogo federato di dataset gestito dagli Health Data Access Bodies, condivisione che presuppone API sicure e rigorosi sistemi di autenticazione. Le FAQ citano generiche “misure tecniche”, senza fornire linee guida precise (FAQ, Q75), lasciando spazio a possibili disomogeneità nelle implementazioni.
In breve: l’idea di superare i confini nazionali attraverso MyHealth@EU e HealthData@EU promette grandi opportunità in termini di continuità assistenziale e avanzamento della ricerca.
Rimane però centrale la questione di come garantire un’efficace cybersecurity a fronte di architetture e responsabilità così distribuite, soprattutto laddove manchino specifiche tecniche dettagliate e regole uniformi a livello europeo.
EHDS e GDPR: diritti ampliati e responsabilità condivise
Le infrastrutture EHDS non operano nel vuoto, intersecano altre normative come GDPR e AI Act. Difatti, proprio il GDPR non viene sostituito o bypassato dall’EHDS, anzi le due discipline di integrano in ambiti specifici. Vediamo alcuni punti specifici.
Per quanto riguarda l’uso primario dei dati sanitari, l’EHDS amplia i diritti degli individui in relazione a specifiche categorie di dati sanitari: mentre il GDPR consente alle persone di richiedere l’accesso ai propri dati personali con tempi di replica che possono arrivare a 30 giorni (se non 90 giorni in casi particolari), l’EHDS introduce un diritto mirato, senza oneri, per accedere immediatamente a determinate informazioni tramite un portale self-service.
Questo elimina la necessità per i titolari del trattamento di cercare manualmente i dati, riducendo i tempi di attesa e garantendo un accesso più efficiente.
Quindi l’EHDS impone disponibilità immediata per i dati prioritari, indipendentemente dalla base giuridica di trattamento (FAQ, Q11).
Ciò richiede ai titolari di riprogettare i sistemi per garantire risposte in tempo reale, senza compromettere la sicurezza.
Si badi che solo alcuni tipi di dati ricadono all’interno delle categorie “prioritarie” in parola, come visto sopra (per es. referti di laboratorio, referti di imaging diagnostico, lettere di dimissione ecc.).
I pazienti possono inoltre esercitare il diritto di “restringere” (o nascondere) alcune parti dei propri dati ai professionisti sanitari, con facoltà di revocare tali restrizioni in caso di bisogno.
Gli Stati membri possono anche introdurre (per loro scelta) un opt-out generale dalla condivisione dei dati tramite i servizi EHDS, qualora il paziente voglia uscirne completamente. È una facoltà che, se esercitata, impedisce sia al paziente stesso sia ai professionisti di accedere o condividere i dati sanitari attraverso le infrastrutture EHDS (fatta salva la gestione locale dei dati).
Inoltre, l’EHDS stabilisce compiti specifici per i titolari e responsabili del trattamento dei dati sanitari, allineandosi alle condizioni di liceità del trattamento previste dal GDPR.
Per es. il trattamento dei dati negli ambienti sicuri degli Health Data Access Bodies avviene in base a un compito di interesse pubblico, mentre i titolari dei dati sanitari sono obbligati a condividere i dati con tali HDAB in base a un obbligo legale.
Infine, il GDPR richiede garanzie adeguate per il trattamento di categorie particolari di dati, come quelli sanitari.
L’EHDS contribuisce a queste garanzie attraverso disposizioni specifiche, come la procedura di autorizzazione e l’uso di ambienti di trattamento sicuri, rafforzando la sicurezza e la trasparenza delle operazioni di trattamento dei dati sanitari.
Ancora, sebbene non sia obbligatoria la pseudonimizzazione nell’uso primario dei dati, le FAQ suggeriscono che i titolari dovrebbero applicarla per allinearsi al principio di minimizzazione del GDPR, specialmente nelle condivisioni cross-border (FAQ, Q41).
In sintesi, l’EHDS non solo integra il GDPR, bensì ne estende la portata, introducendo meccanismi più efficienti per l’accesso ai dati sanitari e rafforzando le garanzie di sicurezza.
Questa integrazione richiede un’attenta pianificazione da parte dei titolari del trattamento, che dovranno adeguare i propri sistemi e processi per rispettare sia le disposizioni del GDPR che quelle dell’EHDS.
La collaborazione tra le due normative potrebbe rappresentare un passo avanti significativo verso una gestione più trasparente, sicura ed efficiente dei dati personali sanitari in Europa.
AI Act: doppia certificazione e rischi algoritmici
Sempre più spesso tool di Intelligenza Artificiale (IA) vengono integrati nei sistemi di gestione dei dati sanitari (EHR).
Questo sviluppo apre la strada a importanti sinergie, ma impone anche un coordinamento normativo con l’AI Act che definisce gli standard di sicurezza e trasparenza per sistemi IA considerati “ad alto rischio”.
L’AI Act prevede requisiti stringenti per i dispositivi (hardware o software) che, dotati di funzioni IA, possono incidere significativamente sulla salute umana – per es. strumenti di diagnosi automatizzata.
Se tali dispositivi rientrano anche nell’ambito dell’EHDS, potrebbero dover ottenere una doppia certificazione (EHDS e AI Act). Le FAQ suggeriscono procedure semplificate di registrazione, pur non offrendo dettagli su come conciliare eventuali conflitti fra i due insiemi di requisiti: da un lato, l’AI Act enfatizza la trasparenza degli algoritmi, dall’altro l’EHDS punta molto sull’interoperabilità dei dati sanitari (FAQ, Q61).
Questa mancanza di linee guida chiare, al momento, potrebbe complicare la vita ai produttori, costretti a districarsi fra normative potenzialmente sovrapposte.
Un altro aspetto riguarda la valutazione dei rischi. L’AI Act impone, per i sistemi IA “ad alto rischio”, un’analisi preliminare (ex ante) delle criticità e dell’impatto potenziale sull’utente. L’EHDS, invece, si focalizza sul logging (tracciatura degli accessi e registri di sistema) come strumento principale per garantire trasparenza e responsabilità nell’uso dei dati sanitari.
Le FAQ non spiegano come armonizzare queste due procedure (FAQ, Q23), creando possibili oneri aggiuntivi per i produttori, che dovranno gestire audit e controlli sia sotto il profilo IA che sotto quello della protezione dei dati.
Va ricordato inoltre che molti dispositivi medici oggi sono interconnessi (si tratta dell’Internet of Things, “IoT”) e possono rientrare nella sfera di applicazione dell’EHDS (per i dati sanitari) e del Data Act (per la condivisione dei dati di prodotto).
Questa sovrapposizione normativa esige un’ulteriore attenzione per garantire la coerenza e la conformità in tutti i passaggi, dalla progettazione dei dispositivi alle fasi di manutenzione.
In breve, l’introduzione di algoritmi IA nei sistemi EHR apre enormi prospettive per la diagnosi e la cura dei pazienti, obbligando gli operatori del settore a fare i conti con doppie (o addirittura triple) certificazioni e un quadro regolatorio complesso.
La mancanza di linee guida esplicite su come raccordare AI Act, EHDS e, in alcuni casi, Data Act, sottolinea l’importanza di futuri chiarimenti da parte delle istituzioni europee, per scongiurare oneri e incertezze e favorire un ecosistema realmente innovativo ma sicuro.
Data Act e IoT: sicurezza delle API e dispositivi legacy
Il crescente utilizzo di dispositivi IoT (come pacemaker o altri apparecchi medici connessi) si intreccia con il quadro regolatorio dell’EHDS e, in parallelo, con il Data Act (Regolamento 2023/2854, applicabile dal settembre 2025), che garantisce ai pazienti (e in generale agli utilizzatori) un accesso più ampio e in tempo reale ai dati (tutti, anche non personali) generati.
Questo scenario comporta nuove opportunità ma anche notevoli sfide a livello tecnico e di sicurezza.
Il Data Act prevede che chi utilizza dispositivi IoT possa ottenere i relativi dati in formati aperti e riutilizzabili, un principio che si sposa bene con l’approccio EEHRxF promosso dall’EHDS (FAQ, Q16, Q60).
Quando si parla di dispositivi con protocolli proprietari non è però chiaro se e come si potranno uniformare alle specifiche richieste.
Le FAQ non forniscono indicazioni sufficienti su eventuali procedure di conversione o adattamento per rendere quei dati interoperabili.
Sul fronte della sicurezza, tanto il Data Act quanto l’EHDS sottolineano l’importanza di un approccio “by design”, che includa crittografia, aggiornamenti automatici e altre misure volte a minimizzare i rischi informatici.
Il problema principale sorge con i dispositivi legacy, cioè quelli già presenti sul mercato o addirittura già integrati nell’ecosistema EHDS, concepiti senza i requisiti di sicurezza moderni (FAQ, Q60).
Ad oggi, le FAQ non chiariscono come sarà condotta la verifica di tali dispositivi, né se si richiederà un “retrofit” per allinearli ai nuovi standard.
L’intreccio tra Data Act e EHDS nel campo dell’IoT offre prospettive di maggiore autonomia e trasparenza per i pazienti, nonché un rafforzamento della sicurezza.
Per i dispositivi che non rispettano già protocolli e sistemi di cifratura più evoluti, restano dubbi su come garantire l’effettiva compatibilità e tutela dei dati.
Un nodo che linee guida future dovranno necessariamente affrontare.
EHDS tra opportunità e sfida operativa
L’EHDS è un’opportunità unica per l’Europa, la sua credibilità dipende dalla capacità di tradurre i principi delle FAQ in azioni concrete.
Le FAQ tracciano un percorso, lasciando diversi vuoti che, se non colmati, potrebbero trasformare un progetto ambizioso in un terreno di fragilità.
Ecco alcuni possibili interventi concreti:
- linee guida tecniche dettagliate: è necessario stabilire regole comuni su aspetti chiave come la pseudonimizzazione, l’autenticazione a più fattori (MFA) e la sicurezza delle API. Senza specifiche chiare e condivise a livello UE, ogni Stato rischia di adottare soluzioni differenti, esponendo la rete a punti deboli;
- collaborazione transfrontaliera: un framework europeo per la gestione degli incidenti informatici e per la condivisione della threat intelligence consentirebbe di reagire prontamente in caso di attacchi o violazioni, riducendo i tempi di intervento e minimizzando i danni;
- audit obbligatori: l’introduzione di verifiche periodiche e indipendenti su HDAB (Health Data Access Bodies) e produttori di sistemi EHR favorirebbe una reale compliance, prevenendo derive verso soluzioni superficiali o non aggiornate in termini di sicurezza;
- formazione e finanziamenti: sostenere gli Stati membri che hanno maggiori difficoltà, con programmi di training e fondi dedicati, colmerebbe il divario di competenze tra le diverse realtà europee, assicurando una base omogenea di capacità tecniche e operative.
EHDS: il viaggio è ancora lungo
In conclusione, sebbene le FAQ rappresentino un primo passo importante, senza un piano operativo condiviso e più completo e definito, supportato da atti di esecuzione chiari e vincolanti a livello europeo, nonché una forte cooperazione tra gli Stati membri e le istituzioni europee attraverso il comitato EHDS, il rischio è che il Regolamento diventi teatro di criticità e incidenti – invece di affermarsi come un modello globale di sanità digitale sicura e all’avanguardia.
La credibilità dell’EHDS dipenderà dalla capacità di trasformare questi principi in una realtà operativa efficace e sicura per tutti i cittadini europei.
