By · Last updated 2026-06-05

Torna al BlogGDPR e Conformità

Danimarca CPR: Validazione Modulo-11 per il GDPR

Il 67% degli strumenti NLP non effettua la validazione modulo-11 del numero CPR danese. Il Datatilsynet ha avviato 14 azioni di enforcement nel settore sanitario nel 2024. Uso secondario dei dati sanitari.

June 5, 20267 min di lettura
Denmark DatatilsynetCPR modulus-11Danish healthcare GDPRhealth data anonymizationNordic compliance

Numeri CPR danesi: guida alla conformità GDPR

Aggiornato al 2026

Il Datatilsynet, autorità danese per la protezione dei dati, ha emesso 31 decisioni GDPR nel 2024, di cui 14 riguardanti dati sanitari. Questa quota elevata riflette due realtà: la Danimarca gestisce un vasto sistema sanitario nazionale e le lacune tecniche in tale sistema continuano a esporre i dati dei pazienti.

La regola della cifra di controllo per i numeri CPR

Il numero CPR è il documento identificativo personale danese: 10 cifre nel formato GGMMAA-XXXX. Le prime sei cifre corrispondono alla data di nascita; le ultime quattro sono un codice e una cifra di controllo.

La cifra di controllo utilizza una regola di modulo 11:

  1. Si prendono le cifre da 1 a 9.
  2. Si assegna a ciascuna un peso: 4, 3, 2, 7, 6, 5, 4, 3, 2.
  3. Si moltiplica ciascuna cifra per il rispettivo peso e si sommano tutti i risultati.
  4. Si divide per 11 e si annota il resto.
  5. Resto 0 → la cifra di controllo è 0.
  6. Resto 1 → il numero non è valido.
  7. Resto 2–10 → la cifra di controllo è 11 meno il resto.

Questa regola è rilevante per qualsiasi strumento che esegue la scansione alla ricerca di numeri CPR. Alcune stringhe nel formato GGMMAA-XXXX non possono mai essere valide. Gli strumenti che saltano questo passaggio segnalano date, codici fattura e numeri di riferimento come identificativi reali.

La revisione del 2024 dell'autorità ha rilevato che il 67% degli strumenti NLP generici salta questo controllo — la principale lacuna tecnica riscontrata nei casi sanitari.

I cinque registri sanitari danesi

La Danimarca collega i dati sanitari attraverso cinque registri nazionali. L'identificativo personale costituisce il collegamento tra tutti e cinque.

  • Cartelle di dimissione ospedaliera (dal 1977)
  • Dati sulle prescrizioni (dal 1995)
  • Registro dei tumori (dal 1943)
  • Registro delle cause di morte (dal 1970)
  • Diagnosi in cure primarie (dal 1990)

Questo rende la ricerca sanitaria danese molto potente, ma genera anche un rischio: la semplice rimozione dell'identificatore grezzo non è sufficiente. Un dataset che conserva ancora età, sesso, diagnosi e anno può re-identificare le persone, in particolare quelle affette da malattie rare.

Le linee guida del Datatilsynet del 2024 sull'uso secondario dei dati sanitari stabiliscono tre requisiti.

Documentare le operazioni eseguite sui dati: Elencare i campi rimossi, quelli arrotondati o raggruppati e la dimensione dei gruppi ottenuta. Una nota di policy non soddisfa questo standard.

Revisione esterna per dataset di grandi dimensioni: Per dataset con più di 5.000 persone, l'autorità raccomanda una revisione tecnica indipendente dei passaggi di de-identificazione.

Adeguare i dati alla domanda di ricerca: Il dataset deve corrispondere alla finalità di ricerca dichiarata. L'autorità ha riscontrato casi in cui i team avevano utilizzato registri nazionali completi quando un campione più piccolo sarebbe stato sufficiente.

Consulta la nostra guida al rilevamento degli identificativi nazionali UE per comprendere come le regole della cifra di controllo si applicano ad altri formati di identificativo europei.

Cosa hanno rilevato i casi del 2024

I 14 casi sanitari condividono tre tipologie di errore ricorrenti.

Condivisione di dati di ricerca: Un ospedale invia a un partner accademico un dataset di pazienti de-identificato per l'addestramento di sistemi IA. Il dataset contiene parti della data di nascita, codici diagnostici e date di trattamento. L'autorità rileva che questa combinazione re-espone i pazienti affetti da malattie rare: le diagnosi insolite riducono rapidamente il pool di possibili identità.

Servizi IA di terze parti: Una società di tecnologia sanitaria invia note cliniche a un servizio IA con sede negli USA per l'elaborazione delle cartelle cliniche, senza rimuovere preventivamente gli identificativi personali e senza un meccanismo di trasferimento valido.

Lacune nella pipeline OCR: Una compagnia assicurativa elabora moduli PDF scansionati per le richieste di indennizzo per disabilità. Lo strumento OCR converte le immagini in testo, ma non esegue il controllo della cifra di controllo sull'output. Molti identificativi vengono ignorati.

L'OCR spesso introduce spazi all'interno dei numeri o sposta il trattino. Il semplice pattern matching non funziona su questo tipo di output. Il rilevamento deve operare sul testo OCR, non solo su input puliti. Consulta la nostra guida al rilevamento PII in ambito sanitario tramite OCR per i passaggi necessari alla gestione dei documenti scansionati.

Tre requisiti tecnici fondamentali

Questi tre elementi costituiscono la base per la conformità GDPR in ambito sanitario danese.

Controllo della cifra di controllo su tutti i testi: Eseguire il controllo completo di modulo 11 su ogni stringa candidata, applicandolo sia al testo pulito che all'output OCR.

Rilevamento dei nomi in lingua danese: Utilizzare un modello addestrato su testi danesi. Il modello spaCy da_core_news è un'opzione. Un modello generico per l'inglese non riconosce nomi e denominazioni organizzative in danese.

Registrazione della de-identificazione: Documentare cosa è stato rimosso, cosa è stato raggruppato e la dimensione dei gruppi nell'output. L'autorità richiede questa documentazione in forma tecnica, non come semplice nota di policy.

Per dati sui costi degli incidenti legati ai dati sanitari, consulta la nostra analisi dei costi delle violazioni in ambito sanitario.

Fonti

Pronto a proteggere i tuoi dati?

Inizia ad anonimizzare i PII con oltre 285 tipi di entità in 48 lingue.

About this page

We update this page when our platform or the law changes.

Read our founder note for how we work.

Each change shows up in the timestamp at the top.

Related reading

We follow these rules

  • GDPR (EU 2016/679).
  • ISO/IEC 27001:2022.
  • NIS2 (EU 2022/2555).
  • HIPAA safe harbor under 45 CFR § 164.514(b)(2).

Our promise

We do not sell your data.

We do not train models on your text.

We store your files in Germany.

You can delete your account at any time.

You own your work.

Where we run

Our servers live in Falkenstein, Germany.

We use Hetzner. They hold ISO 27001 certification.

All data stays in the EU.

Backups run every day.

Need help?

Email support@anonym.legal.

We reply within one business day.

How we test

We run a full check suite on every release.

Each surface gets its own sweep script and report.

Human reviewers spot-check the output each week.

We track recall and precision on a labelled set.

Bad runs block the deploy.

What we never do

  • We never sell your information to third parties.
  • We never train models on what you upload.
  • We never keep your work after you delete it.
  • We never share keys with any outside firm.
  • We never run ads inside the product.

Plans in plain words

We sell credits, not seats.

One credit covers one short job.

Long jobs use a few credits each.

You can top up at any time.

Unused credits roll over each month.

Read the plans page for current rates.

Who built this

A small team of engineers and lawyers built this.

We ship from Europe and work in the open.

Our founder note spells out why we started.

Where to start

How the parts fit

A browser add-on cleans text inside Chrome.

A Word plug-in handles drafts in Office.

A small desktop tool works on whole folders.

An agent protocol link feeds large models safely.

All four share one core engine and one rule set.

Words from our team

We started this work after a lunch about cookies.

One friend kept getting odd ads on her phone.

We asked why a court file leaked through a draft.

We sketched the first build on a napkin that week.

By month three we had a tiny demo for a friend.

She used it on her first case the next day.

Common questions we hear

Can the tool read scanned PDFs? Yes, with OCR.

Does it work on long files? Yes, in small chunks.

Can I roll my own rule set? Yes, save it as a preset.

Does it run offline? The desktop build runs offline.

Do you keep my files? No, the cloud build wipes after each run.

Will it learn from my work? No, we never train on inputs.

A short tour of the workflow

Upload a file or paste a snippet of prose.

Pick the entities you want gone from the draft.

Choose a method: replace, mask, hash, encrypt, or redact.

Press run and watch the side panel show each hit.

Skim the result and tweak any rule that misfired.

Save the cleaned file or send it to a teammate.