Tillbaka till BloggenHälsovård

Anpassad MRN-detektering utan kod för HIPAA

Journalnummer är sjukhusspecifika — varje sjukvårdssystem använder ett eget format. HIPAA Safe Harbor kräver att MRN-nummer tas bort.

April 30, 20268 min läsning
custom MRN detectionHIPAA pipeline configurationno-code regexAI pattern helperhospital identifier de-identification

Problemet med MRN-format

USA har ungefär 6 100 sjukhus. Varje sjukhus kör sitt eget EHR-system. Varje sjukhus använder sitt eget format för journalnummer. Det finns ingen nationell standard. Joint Commission kräver att sjukhus kan identifiera patienter — men ställer inga formatkrav.

Formaten varierar kraftigt. Vissa är 7-siffriga heltal. Andra är 8-siffriga heltal. Vissa använder prefix som HOSP-, MRN- eller PT-. Andra lägger till institutionskoder som SVHS- eller CHOP-. Vissa bäddar in inskrivningsåret i numret.

HIPAA Safe Harbor listar patientjournalnummer som identifierartyp 8 av 18. (45 CFR §164.514(b)(2)) Alla 18 måste tas bort. Regeln begränsar sig inte till något enskilt format. Om ditt sjukhus använder ett anpassat format måste du detektera det. Ett verktyg som missar det underkänner Safe Harbor — även om det tar bort alla de andra 17 typerna.

Varför kodmetoden fallerar

Det vanliga sättet att lägga till ett anpassat journalnummerformat till en avidentifieringspipeline är att utöka Microsoft Presidio. Det innebär att skriva Python.

En utvecklare skapar en klass som ärver från EntityRecognizer. De skriver det reguljära uttrycket, kopplar det till Presidios register, testar det och underhåller det. För efterlevnadsteam — som sällan kodar — är detta ett hårt hinder. Varje formatändring kräver en ingenjör.

Sjukvårdsinsenjörer har mycket att göra. De fokuserar på EHR-integration och kliniska system. Efterlevnadsverktyg är sällan deras högsta prioritet.

Arbetsflödet med det kodningsfria mönstret

Den guidade mönstermetoden tar bort kodningssteget.

En efterlevnadsansvarig öppnar Custom Entity Creator i webbappen. De klistrar in fem exempelnummer från sitt system — till exempel:

SVHS-0012345
SVHS-0987654
SVHS-1122334
SVHS-4455667
SVHS-8899001

De klickar på Generera mönster. AI:n läser strukturen och returnerar:

  • Mönster: SVHS-\d{7}
  • Konfidensgrad: hög
  • Föreslagen benämning: HOSPITAL-MRN
  • Föreslagen ersättning: [MRN]

Den ansvarige klistrar in ytterligare fem exempel. Mönstret godkänns. De sparar det till HIPAA-förvalet.

Från och med den punkten identifierar varje session — webbapp, Office-tillägg, skrivbordsapp och API — detta format i standardgenomgången av PHI. Ingen kod behövs.

Notering om GDPR-forskning

GDPR artikel 89 kräver pseudonymisering för forskningsdataset. Anpassade entiteter sätter institutionsspecifika identifierare i scope — och stänger det gap som generiska verktyg lämnar öppet.

Vad du får

Detta arbetsflöde tar en eftermiddag. Anpassad kod tar veckor.

Den efterlevnadsansvarige definierar mönstret, testar det och driftsätter det. Ingen supportbiljett. Inget väntetid. Förvalet håller den anpassade entiteten bredvid de 17 standard-Safe Harbor-identifierarna.

När nästa omgång kliniska anteckningar körs är alla 18 identifierartyper täckta. Safe Harbor är komplett.

Se HIPAA Safe Harbor-avidentifiering för hälso- och sjukvårdsforskning för hur Safe Harbor fungerar i praktiken. För sjukhusspecifika detekteringsmönster, se detektering av sjukhusspecifika MRN-format utan teknikavdelning.

Källor

Limitations / When this doesn't apply

Five samples define the rule; production data tests it. Generating a pattern from a handful of clean values is fast, but the real record stream may include a legacy format from before a system migration, MRNs printed without the prefix, numbers wrapped across lines in scanned notes, or a second hospital's scheme in the same file — a pattern that passes its own examples can still miss these. Validate every generated entity against a held-out set of genuine documents before trusting it, and re-test after any EHR change.

  • A confident pattern is not a verified one. High confidence reflects how cleanly the samples fit a regex, not whether it catches every MRN you will encounter or avoids flagging unrelated codes of the same shape. An over-narrow pattern lets MRNs through silently — the worst case, because nothing alerts — so run a recall check on real data rather than the generated samples.
  • One configured entity does not complete Safe Harbor. Adding the MRN closes category 8, but the remaining categories — especially free-text dates, geography, and the category 18 catch-all — are not solved by one pattern, and certifying a dataset as de-identified is a judgment about residual re-identification risk. A qualified reviewer still has to confirm the standard is met; this article is educational, not legal advice.

Redo att skydda din data?

Börja anonymisera PII med 267+ entitetstyper 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.

We follow these rules

  • GDPR (EU 2016/679).
  • ISO/IEC 27001:2022, held by our hosting provider.
  • 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 company HQ is in Saarbrücken, Germany. Our servers run in Hetzner's Falkenstein datacenter.

Hetzner holds 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

Automated checks run on every release.

Each surface gets its own sweep script and report.

Human reviewers spot-check the output each week.

We test detection against sample documents before each release.

A failing unit or integration run stops the release.

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.

Paid plans can buy top-up credits.

Credits reset at the end of each cycle.

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.