By · Last updated 2026-06-05

Tilbake til BloggGDPR & Overholdelse

Danmark CPR: Modulus-11-validering for GDPR

67% av NLP-verktøy mangler dansk CPR-nummer modulus-11-validering. Datatilsynets 14 håndhevingssaker innen helsevesen i 2024. Sekundærbruk av helsedata.

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

Dansk CPR-nummer: GDPR-overholdelsesguide

Oppdatert for 2026

Danmarks datatilsyn, Datatilsynet, utstedte 31 GDPR-avgjørelser i 2024. Fjorten gjaldt helsedata. Den høye andelen gjenspeiler to fakta: Danmark driver et stort nasjonalt helsesystem, og tekniske hull i det systemet fortsetter å eksponere pasientregistre.

Kontrollsiffer-regelen for CPR-numre

Et CPR-nummer er Danmarks personlige ID. Det er 10 sifre i formatet DDMMÅÅ-XXXX. De første seks sifrene er fødselsdatoen. De siste fire er en kode pluss et kontrollsiffer.

Kontrollsifferet bruker en modulus-11-regel:

  1. Ta siffer 1 til 9.
  2. Gi hvert en vekt: 4, 3, 2, 7, 6, 5, 4, 3, 2.
  3. Multipliser hvert siffer med sin vekt. Legg sammen alle resultater.
  4. Del på 11. Merk resten.
  5. Rest 0 → kontrollsifferet er 0.
  6. Rest 1 → nummeret er ikke gyldig.
  7. Rest 2–10 → kontrollsifferet er 11 minus resten.

Denne regelen gjelder for ethvert verktøy som søker etter CPR-numre. Noen DDMMÅÅ-XXXX-strenger kan aldri være gyldige. Verktøy som hopper over dette steget, flagger datoer, fakturakoder og referansenumre som ekte ID-er.

Myndighetenes gjennomgang fra 2024 fant at 67% av generiske NLP-verktøy hopper over denne sjekken. Det gapet er den viktigste tekniske feilen i helsevesenets saker.

Danmarks fem helseregistre

Danmark kobler helsedata på tvers av fem nasjonale registre. Det personlige ID-et knytter alle fem sammen.

  • Utskrivingsregistre fra sykehus (fra 1977)
  • Reseptdata (fra 1995)
  • Kreftregister (fra 1943)
  • Register for dødsårsaker (fra 1970)
  • Primærdiagnoser (fra 1990)

Dette gjør dansk helseforskning svært sterk. Det skaper også en risiko. Å fjerne rå-ID-et er ikke nok. Et datasett som fortsatt inneholder alder, kjønn, diagnose og år kan re-eksponere personer — spesielt de med sjeldne tilstander.

Datatilsynets veiledning fra 2024 om sekundær bruk av helsedata setter tre krav.

Skriv ned hva du gjorde med dataene: List opp hvilke felt du fjernet, hvilke du avrundet eller gruppert, og hvilken gruppestørrelse resultatet oppnår. Et policydokument oppfyller ikke denne standarden.

Få en ekstern gjennomgang for store datasett: For datasett med mer enn 5 000 personer anbefaler myndigheten en uavhengig teknisk gjennomgang av avidentifiseringstrinnene.

Match dataene til spørsmålet: Datasettet må passe det angitte forskningsmålet. Myndigheten fant tilfeller der team brukte fullstendige nasjonale registre når et mindre utvalg ville ha fungert.

Se vår EU-guide for nasjonal ID-deteksjon for hvordan kontrollsiffer-regler gjelder for andre europeiske ID-formater.

Hva 2024-sakene fant

De 14 helsevesensakene deler tre vanlige feiltyper.

Deling av forskningsdata: Et sykehus sender et avidentifisert pasientdatasett til en akademisk partner for AI-trening. Settet inneholder deler av fødselsdato, diagnosekoder og behandlingsdatoer. Myndigheten finner at denne kombinasjonen re-eksponerer pasienter med sjeldne sykdommer. Uvanlige diagnoser innsnevrer gruppen raskt.

AI-tjenester fra tredjeparter: En helseteknikk-virksomhet sender pasientnotater til en amerikansk AI-tjeneste for klinisk journalarbeid. Personlige ID-er i disse notatene fjernes ikke først. Ingen gyldig overføringsmekanisme er på plass.

Hull i OCR-pipeline: Et forsikringsselskap behandler skannede PDF-skjemaer for uførekrav. OCR-verktøyet konverterer bilder til tekst. Men det kjører ikke kontrollsiffer-tester på resultatet. Mange ID-er overses.

OCR setter ofte inn mellomrom midt i et nummer eller forskyver bindestreken. Enkel mønstermatching bryter på det resultatet. Deteksjon må fungere på OCR-tekst, ikke bare ren inndata. Se vår OCR-guide for helsedeteksjon for trinn til å håndtere skannede dokumenter.

Tre tekniske must-haves

Disse tre elementene utgjør grunnlinjen for dansk helsevesen GDPR-overholdelse.

Kontrollsiffer-tester på all tekst: Kjør den fullstendige modulus-11-sjekken på alle kandidatstrenger. Bruk den på ren tekst og OCR-resultat likt.

Danskspråklig navnedeteksjon: Bruk en modell trent på dansk tekst. spaCy-modellen da_core_news er ett alternativ. En generisk engelsk modell bommer på danske navn og organisasjonsnavn.

Avidentifiseringsregistre: Skriv ned hva som ble fjernet, hva som ble gruppert, og utdataenes gruppestørrelse. Myndigheten ber om dette i teknisk form, ikke som et policydokument.

For data om kostnadene ved datahendelser i helsevesenet, se vår analyse av kostnader ved helsebrudd.

Kilder

Klar til å beskytte dataene dine?

Begynn å anonymisere PII med 285+ enhetstyper på 48 språk.

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.