Risposta breve: il software che gestisce dati sanitari risponde a quattro famiglie di regole contemporaneamente. La protezione dei dati stabilisce cosa si può fare con i dati sanitari personali: l'Articolo 9 del GDPR nell'UE, l'HIPAA e una serie di leggi statali negli Stati Uniti. Le regole del sistema sanitario definiscono come i dati devono essere trasferiti e condivisi: lo Spazio Europeo dei Dati Sanitari (EHDS) nell'UE, il TEFCA, l'USCDI e le regole sull'information blocking negli Stati Uniti. La sicurezza del prodotto si applica quando il software svolge un'attività medica: il Regolamento sui Dispositivi Medici (MDR) e il Regolamento sui Dispositivi Medico-Diagnostici in Vitro (IVDR) nell'UE, le regole della FDA negli Stati Uniti, con IEC 62304 e ISO 13485 come standard di ingegneria e qualità sottostanti. La sicurezza stabilisce la base che tutti devono rispettare: ISO 27001 e 27799, NIS2 per i settori critici, la HIPAA Security Rule. L'identità (eIDAS e il Portafoglio Europeo di Identità Digitale, NHS login, carte d'identità nazionali) attraversa tutte e quattro le aree.
La mappa
La mappa della regolamentazione dei dati sanitari raggruppa le norme per il software che gestisce dati sanitari in famiglie: protezione dei dati (Articolo 9 del GDPR, HIPAA, leggi statali USA), norme del sistema sanitario (EHDS, Cures Act, TEFCA), sicurezza dei prodotti (MDR, IVDR, FDA), standard di ingegneria e qualità (IEC 62304, ISO 13485), sicurezza (ISO 27001, ISO 27799, NIS2, HIPAA Security Rule) e identità (eIDAS 2).
| Famiglia | Regola | Si applica a | Cosa richiede |
|---|---|---|---|
| Protezione dei dati | GDPR, Art. 9 e Art. 35 | Chiunque elabori dati sanitari di residenti UE | Una base giuridica dall'Art. 9(2), una DPIA, un DPO per l'elaborazione su larga scala, diritti, notifica di violazione entro 72 ore |
| Protezione dei dati | HIPAA (Privacy, Security, Breach Rules) | Entità coperte dagli Stati Uniti e i loro associati commerciali | Usi consentiti, salvaguardie, notifica di violazione; non copre la maggior parte delle app per consumatori |
| Protezione dei dati | Leggi statali USA (CCPA/CPRA, Washington My Health My Data…) | Aziende che gestiscono dati dei residenti | Consenso per dati sanitari dei consumatori, diritti di cancellazione, restrizioni di vendita |
| Sistema sanitario | EHDS, Regolamento (UE) 2025/327 | Sistemi EHR, app per il benessere che dichiarano interoperabilità, detentori di dati, organismi di accesso ai dati sanitari | Accesso e portabilità del paziente nel formato di scambio europeo, MyHealth@EU obbligatorio, permessi per uso secondario |
| Sistema sanitario | 21st Century Cures Act, regole ONC HTI, TEFCA | IT sanitari certificati USA, fornitori, reti | API FHIR, dati USCDI, nessun blocco delle informazioni, scambio a livello nazionale |
| Sicurezza del prodotto | MDR 2017/745, IVDR 2017/746 | Software con scopo medico per pazienti UE | Classificazione, valutazione di conformità, valutazione clinica, sorveglianza post-vendita, marcatura CE |
| Sicurezza del prodotto | FDA (21 CFR 820/QMSR, 510(k), De Novo, PMA) | Software come dispositivo medico per gli Stati Uniti | Percorso pre-mercato per classe, sistema di qualità, documentazione sulla cybersecurity |
| Ingegneria | IEC 62304, IEC 82304-1, ISO 14971 | Team di software per dispositivi medici | Ciclo di vita del software per classe di sicurezza, gestione dei rischi |
| Qualità | ISO 13485 | Produttori di dispositivi | Un sistema di gestione della qualità che copre progettazione, produzione, reclami |
| Sicurezza | ISO/IEC 27001, ISO 27799, ISO 27701 | Qualsiasi organizzazione; guida specifica per la sanità | Un sistema di gestione della sicurezza delle informazioni, controlli sanitari, estensione della privacy |
| Sicurezza | NIS2, Direttiva 2022/2555 | Fornitori di servizi sanitari, produttori di dispositivi, fornitori di cloud e digitali sopra determinate soglie dimensionali | Misure di rischio, segnalazione incidenti entro 24/72 ore, responsabilità della direzione |
| Sicurezza | HIPAA Security Rule | Entità coperte dagli Stati Uniti e associati commerciali | Salvaguardie amministrative, fisiche e tecniche; analisi dei rischi |
| Identità | eIDAS 2 e il Portafoglio Europeo di Identità Digitale | Servizi che verificano l'identità dei cittadini UE | Accettazione del portafoglio per l'identificazione forte dal 2026-2027 |
Chi è coinvolto in cosa
Quali norme sui dati sanitari si applicano dipende da cosa fa il software. Un'app per consumatori senza indicazioni mediche risponde all'Articolo 9 del GDPR, a una DPIA e a pratiche di sicurezza; l'aggiunta di interpretazioni la rende un dispositivo medico secondo il MDR; una piattaforma FHIR è un elaboratore di dati GDPR e a volte soggetto a NIS2; un ospedale è soggetto a tutto questo più NIS2 in quanto entità essenziale.
- Un'app sanitaria per consumatori senza dichiarazioni mediche (un diario dei sintomi, un registro di referti di laboratorio): GDPR Articolo 9 con consenso esplicito, una DPIA, pratiche di sicurezza a livello ISO 27001, e l'etichetta per app per il benessere dell'EHDS se dichiara di connettersi ai sistemi EHR. Non è un dispositivo medico, purché il suo scopo previsto rimanga non medico. Negli Stati Uniti: regole FTC e leggi statali sulla privacy sanitaria piuttosto che HIPAA.
- La stessa app con una funzione di interpretazione ("il tuo risultato suggerisce…"): un dispositivo medico secondo la Regola 11 dell'MDR, solitamente classe IIa, con IEC 62304 e ISO 13485 a supporto. Vedi Un'app sanitaria è un dispositivo medico? e Classi SaMD.
- Un fornitore di piattaforme o integrazioni FHIR: GDPR come responsabile del trattamento (contratti Articolo 28), ISO 27001, possibilmente NIS2 come fornitore di infrastrutture digitali o servizi ICT, obblighi EHDS quando fa parte di un sistema EHR, HIPAA come associato commerciale negli Stati Uniti.
- Un ospedale: tutto quanto sopra come titolare del trattamento e operatore, più NIS2 come entità essenziale, leggi nazionali sui fascicoli sanitari e le scadenze EHDS per la connessione all'infrastruttura nazionale.
- Una piattaforma di ricerca: GDPR Articolo 9(2)(j) e Articolo 89, il capitolo sull'uso secondario dell'EHDS (permessi da un organismo di accesso ai dati sanitari, ambienti di elaborazione sicuri) e standard di anonimizzazione. Vedi Uso secondario dei dati sanitari.
In quale ordine
La conformità dei dati sanitari è meglio affrontarla in un ordine prestabilito: prima scrivere lo scopo previsto, perché decide se il software è un dispositivo medico; poi la protezione dei dati (base giuridica, DPIA, contratti con i processori); poi una base di sicurezza secondo la ISO 27001; poi i mandati di interoperabilità come FHIR ed EHDS o USCDI; poi il percorso del dispositivo, se presente; infine le questioni transfrontaliere.
- Decidere lo scopo previsto per iscritto. Determina se si tratta di un dispositivo medico e tutto il resto ne consegue.
- Prima la protezione dei dati: base giuridica, DPIA, contratti con i responsabili del trattamento, DPO. Questi sono necessari prima del primo utente reale, in ogni scenario. Vedi GDPR Articolo 9 per i dati sanitari e DPIA per un'app sanitaria.
- Base di sicurezza: un ISMS secondo ISO 27001, mappato ai controlli sanitari di 27799; questo risponde anche alla maggior parte di NIS2 e HIPAA Security Rule. Vedi ISO 27001 vs ISO 27799 e NIS2 per ospedali e fornitori.
- Mandati di interoperabilità: FHIR e il formato di scambio del proprio mercato (EHDS, USCDI/US Core) in modo che il prodotto non sia escluso dall'infrastruttura nazionale. Vedi USCDI spiegato e TEFCA spiegato.
- Percorso del dispositivo, se presente: classificazione, sistema di qualità, ciclo di vita, organismo notificato o percorso FDA. Prevedere un anno.
- Transfrontaliero: differenze HIPAA vs GDPR quando si servono entrambi i mercati (HIPAA vs GDPR), meccanismi di trasferimento, luogo di hosting.
Dove si posiziona Anpheros
Anpheros Daily è un fascicolo sanitario personale con uno scopo previsto non medico dichiarato: memorizza, visualizza e condivide, e non interpreta né raccomanda. Anpheros Platform è un backend FHIR R4 offerto a cliniche e sviluppatori come responsabile del trattamento ai sensi dell'Articolo 28 del GDPR, con consenso controllato dal paziente e registri di accesso. Le pagine normative in questo cluster descrivono le regole così come si applicano a qualsiasi prodotto di questo tipo; la pagina sulla trasparenza descrive come Anpheros le applica a se stessa.
Questa pagina spiega la normativa per i team di prodotto e ingegneria. Non costituisce consulenza legale; i testi collegati sotto Fonti fanno fede, e il tuo data protection officer, organismo notificato o consulente decide per il tuo caso. Ultima revisione: Ottobre 2026.
Pagine correlate
- Un'app sanitaria è un dispositivo medico? MDR UE Regola 11
- I tuoi dati medici nell'UE: GDPR, EHDS e i tuoi diritti
- GDPR Articolo 9 per i dati sanitari
- DPIA per un'app sanitaria
- HIPAA vs GDPR
- NIS2 per ospedali e fornitori di tecnologia sanitaria
- Standard di interoperabilità sanitaria: la mappa
- GDPR per sviluppatori (sito sviluppatori)
- Fascicoli sanitari elettronici nazionali in Europa e negli Stati Uniti
- MyHealth@EU e il riassunto del paziente transfrontaliero
- L'AI Act UE e l'IA in sanità
- Uso secondario dei dati sanitari
- Sicurezza e identità nelle app sanitarie
Fonti
- Regolamento (UE) 2016/679 (GDPR), EUR-Lex
- Regolamento (UE) 2025/327 (Spazio Europeo dei Dati Sanitari), EUR-Lex
- Regolamento (UE) 2017/745 (MDR), EUR-Lex
- Regolamento (UE) 2017/746 (IVDR), EUR-Lex
- Direttiva (UE) 2022/2555 (NIS2), EUR-Lex
- HHS: HIPAA per professionisti
- ASTP/ONC: Trusted Exchange Framework and Common Agreement
- ISO/IEC 27001:2022
Domande frequenti
Il GDPR si applica a un'azienda statunitense con utenti UE?
Sì, ai sensi dell'Articolo 3(2), non appena offre servizi a persone nell'UE o ne monitora il comportamento, indipendentemente da dove si trovino i server. Richiede quindi un rappresentante UE, una base giuridica ai sensi dell'Articolo 9 e un meccanismo di trasferimento lecito.
L'HIPAA è più rigoroso del GDPR?
Nessuno dei due è rigorosamente più rigoroso. L'HIPAA ha un ambito più ristretto (solo entità coperte e associati commerciali) ed è più prescrittivo riguardo alle salvaguardie; il GDPR è più ampio (chiunque elabori dati di residenti UE), basato sui diritti e richiede una base giuridica per ogni utilizzo. Un prodotto che opera in entrambi i mercati deve soddisfare entrambi.
L'EHDS sostituisce il GDPR per i dati sanitari?
No. L'EHDS si basa sul GDPR e aggiunge obblighi per i sistemi EHR, l'accesso dei pazienti, lo scambio transfrontaliero e l'uso secondario. Il GDPR rimane la base per ogni operazione di trattamento.
Da dove comincio se non ho un team di conformità?
Scrivi lo scopo previsto, esegui una DPIA con un modello, adotta una base di sicurezza in stile ISO 27001 e utilizza FHIR con i profili del tuo mercato. Questi quattro passaggi coprono la maggior parte di ciò che richiederà un primo audit o un primo cliente ospedaliero.
Provalo gratis nella sandbox
La tua prima chiamata FHIR in 5 minuti. Un'API HL7 FHIR R4 con il consenso del paziente integrato: provala nella sandbox, poi collega la tua app o il sistema della tua clinica.
Gratis · 30 pazienti sintetici · senza carta
Anpheros sviluppa una cartella clinica che il paziente controlla e può condividere con qualsiasi studio medico, su una piattaforma HL7 FHIR R4, con sede in UE. Queste guide ti aiutano a comprendere e organizzare la tua salute; non sostituiscono il tuo medico.
Chi siamo →