By · Last updated 2026-05-30

Takaisin BlogiinTerveydenhuolto

HIPAA Safe Harbor -tunnistaminen: Sairaalakohtaisten MRN-formaattien tunnistaminen ilman suunnitteluresursseja

HIPAA Safe Harbor edellyttää potilasasiakirjanumeroiden poistamista — mutta MRN-formaatit eivät ole standardoituja. Epic, Cerner ja Meditech käyttävät kaikki eri formaatteja, jotka yleiset PII-työkalut jättävät huomaamatta.

May 30, 20267 min lukuaika
HIPAA Safe Harbormedical record numbersMRN detectionhealthcare compliancecustom PII patterns

HIPAA Safe Harbor -tunnistaminen: Sairaalakohtaisten MRN-formaattien tunnistaminen ilman suunnitteluresursseja

HIPAA Safe Harbor -tunnistaminen edellyttää "potilasasiakirjanumeroiden" poistamista yhtenä 18 tunnistuskategoriasta. Tämä kuulostaa suoraviivaiselta, kunnes kohtaat todellisen operatiivisen haasteen: potilasasiakirjanumerot eivät ole standardoituja.

Epic luo MRN:t yhdessä formaatissa. Cerner käyttää eri formaattia. Meditech käyttää toista. Sairaalaverkostot määrittävät omat laitoskoodinsa. Alueelliset terveydenhuollon tietojärjestöt luovat vielä lisää formaatteja. Tulos: tavallinen PII-työkalu, joka skannaa kliinistä asiakirjaa "potilasasiakirjanumeroiden" varalta, ei voi tietää laitoksesi käyttämää formaattia — ja ohittaa ne kokonaan.

Tämä ei ole hypoteettinen aukko. Terveydenhuollon IT-tiimit, jotka tekevät HIPAA-tunnistamisen arvioita, löytävät säännöllisesti MRN:t edelleen "tunnistamattomiksi" tarkoitetuissa tietojoukoissa, koska anonymisointityökalu oli konfiguroitu vain vakio-PII-kategorioille.

MRN-standardointiongelma

Yhdysvalloilla ei ole kansallista standardia potilasasiakirjanumeroiden formaatille. Jokainen laitos (tai EHR-toimittaja) määrittelee omansa:

Yleisiä havaittuja kuvioita:

  • Epic-tyyli: 8–12-numeroinen (esim. 123456789)
  • Cerner-tyyli: Sairaalakoodi-etuliite + numero (esim. MGH-987654)
  • Alueelliset verkostot: Laitoskoodi + vuosi + järjestysnumero (esim. HOSP-2023-456789)
  • Veteraaniasiat: 9-numeroinen tietyllä tarkistusmerkkikuviolla
  • Lastentautien järjestelmät: Potilastyyppi-etuliite + numero (esim. PED-12345678)

Mikään näistä ei vastaa universaalia "potilasasiakirjanumeron" regex-kuviota, koska sellaista universaalia kuviota ei ole olemassa.

Mitä vakio-PII-työkalut havaitsevat: Vakio HIPAA-tunnistamistöiden toteutukset keskittyvät standardoituihin formaatteihin: SSN:t (XXX-XX-XXXX), puhelinnumerot (XXX-XXX-XXXX), sähköpostiosoitteet, päivämäärät. MRN:t, tilinumerot ja todistus/lisensseinumerot — HIPAA:n kategoriat 8, 10 ja 11 — ovat laitoskohtaisia ja vaativat mukautetun konfiguraation.

Vaatimustenmukaisuusriski

Alueellinen sairaalaverkosto valmistautuu jakamaan tunnistamattomia potilastietoja yliopiston tutkimuskumppanin kanssa. Heidän EHR:nsä luo MRN:t formaatissa: HOSP-YYYY-XXXXXX (sairaalakoodi, 4-numeroinen vuosi, 6-numeroinen järjestysnumero).

He ajavat tietojoukon vakio-HIPAA-tunnistamistyökalunsa kautta. Työkalu poistaa:

  • Potilasnimet ✓
  • Päivämäärät (vuoden jälkeen) ✓
  • Puhelinnumerot ✓
  • Sähköpostiosoitteet ✓
  • Maantieteelliset tiedot, jotka ovat pienempiä kuin osavaltio ✓
  • SSN:t ✓

Työkalu ei poista MRN:iä — koska HOSP-2023-456789 ei vastaa mitään sisäänrakennettua MRN-kuviota.

Tutkija saa tietojoukon, ajaa liitoksen sisäisten tietueidensa kanssa (jotka sisältävät MRN:iä saman sairaalan lähetteistä) ja voi tunnistaa uudelleen merkittävän osan "tunnistamattomista" potilaista. Sairaalaverkostolla on HIPAA-rikkomus.

Tämä skenaario ei ole hypoteettinen — se on dokumentoitu virhemalli tunnistamistyönkuluissa.

Mukautettu yksikönluonti: ratkaisu

Ratkaisu on määritellä MRN-formaatti mukautetuksi yksiköksi anonymisointityökalussa. Vaatimustenmukaisuushenkilö (ei insinööri) voi:

  1. Tunnistaa laitoksen MRN-formaatin: "Sairaalan tunniste, joka alkaa HOSP:lla, sitten viiva, sitten 4-numeroinen vuosi, sitten viiva, sitten 6-numeroinen numero"

  2. Käyttää tekoälyavusteista kuviogeneraatoria asianmukaisen regexin luomiseksi: HOSP-\d{4}-\d{6}

  3. Validoida näyteasiakirjaa vastaan: Lataa 20 kotiutusyhteenvetoa, varmista, että kuvio löytää kaikki MRN:t

  4. Tallentaa mukautettuna yksikkönä: "Sairaalan MRN" — nyt saatavilla kaikissa käsittelymodeissa

  5. Sisällyttää HIPAA-tunnistamisen esiasetus: Vakioesiasetus plus mukautettu MRN-yksikkö kattaa kaikki 18 Safe Harbor -kategoriaa tälle laitokselle

Aikajana: 3 päivää vaatimustenmukaisuushenkilön aikaa vs. 3 kuukautta suunnittelutikettijono mukautetun koodin kehitykseen.

Esimerkki: Alueellinen sairaalaverkosto

Organisaatio: 15 laitoksen alueellinen sairaalaverkosto MRN-formaatti: HOSP-YYYY-XXXXXX (esiintyy tuhansissa kotiutusyhteenveto-PDF:issä) Vaatimustenmukaisuushaaste: Tutkimustietojoukon valmistelu yliopistokumppanille (HIPAA-datankäyttösopimus toteutettu, edellyttää tunnistamista) Aiempi lähestymistapa: Ulkoinen HIPAA-tunnistamistoimittaja (120 000 dollaria/vuosi) Löydetty aukko: Toimittajan työkalu ei havainnut laitoskohtaista MRN-formaattia

Uusi työnkulku:

  1. Vaatimustenmukaisuushenkilö määrittelee MRN-kuvion (20 minuuttia)
  2. Tekoäly auttaa regex-validoinnissa (5 minuuttia)
  3. Testaa 50 näytteen kotiutusyhteenvetoja vastaan (30 minuuttia)
  4. Vahvistaa, että kaikki MRN:t havaittu, ei vääriä positiivisia (10 minuuttia)
  5. Lisää HIPAA-tunnistamisen esiasetukseen vakioyksiköiden rinnalle
  6. Käsittelee täyden 50 000 tietueen tutkimustietojoukon erässä

Kokonaisaika vaatimustenmukaisuusaukon sulkemiseen: 1 iltapäivä.

Monilaitosjärjestöt: eri MRN-formaatit per laitos

Fuusion kautta rakennetut sairaalaverkostot käyttävät usein useita EHR-järjestelmiä — ja useita MRN-formaatteja vanhentuneista asennuksista.

Useiden MRN-formaattien käsittely:

Luo erilliset mukautetut yksiköt jokaiselle formaatille:

  • "MRN-formaatti A (Epic)" — 8-numeroinen
  • "MRN-formaatti B (vanha Cerner)" — etuliite + 7-numeroinen
  • "MRN-formaatti C (hankittu tytäryhtiö)" — osavaltiokoodi + vuosi + järjestysnumero

Esiasetus, joka sisältää kaikki kolme mukautettua yksikköä plus vakio-HIPAA-tunnisteet, kattaa koko verkoston tunnistamisvaatimukset.

MRN:ien ulkopuolella: muut laitoskohtaiset tunnisteet

Sama mukautettu yksikkömenestely toimii muille HIPAA Safe Harbor -kategorioille, jotka organisaatiot toteuttavat epästandardi-formaateilla:

Terveydenhuoltosuunnitelman edunsaajien numerot (kategoria 9): Vakuutusjäsentunnukset ovat operaattorikohtaisia. Aetna, Blue Cross, United Healthcare — kaikki käyttävät eri formaatteja.

Tilinumerot (kategoria 10): Sairaalan laskutustilinumerot laskutuksen osalta ovat laitoskohtaisia.

Todistus/lisensseinumerot (kategoria 11): Lääkäreiden DEA-numerot ovat standardisoituja. Osavaltioiden lääketieteelliset lisensseinumerot eivät — jokainen osavaltio käyttää eri formaattia.

Laitenumerot (kategoria 14): Lääkintälaitteiden sarjanumerot ovat valmistajien asettamia.

Jokaiselle näistä mukautettu yksikönluonti sulkee havaitsemisaukon. Suunnitteluresursseja ei tarvita.

Validointi: Safe Harbor -vaatimustenmukaisuuden osoittaminen

HIPAA:n Safe Harbor -menetelmä edellyttää, että katettu yksikkö "ei tiedä, että tiedot voidaan käyttää yksin tai yhdessä muiden tietojen kanssa tunnistamaan yksilö."

Vaatimustenmukaisuushenkilölle, joka soveltaa mukautettua yksikköhavaitsemista, validointi on osoitus siitä, että kaikki 18 kategoriaa ovat katettu:

  1. Käsittele 50–100 asiakirjan näyte tutkimustietojoukosta
  2. Tarkista manuaalisesti käsitelty tulos — näyttääkö mikään tunnistajalta?
  3. Aja tulos toisen havaitsemisläpimenon läpi
  4. Dokumentoi validointiprosessi

Mukautettu yksikkökonfiguraatio, validointinäytteiden tulokset ja käsittelymetadata muodostavat yhdessä Safe Harbor -tunnistamisen dokumentaatiotietueen.

Päätelmä

HIPAA Safe Harbor -tunnistamista ei saavuteta vakio-PII-työkaluilla, jotka on konfiguroitu yleisille kuvioille. Potilasasiakirjanumerot — yksi 18 vaadituista kategorioista — ovat laitoskohtaisia ja vaativat mukautetun havaitsemisen vaatimustenmukaisuuden saavuttamiseksi.

Mukautettu yksikönluonti sulkee tämän aukon tunteissa kuukausien sijaan. Vaatimustenmukaisuushenkilöt voivat määritellä laitoskohtaiset kuviot, validoida ne näyteasiakirjoja vastaan ja tuottaa todella Safe Harbor -yhteensopivaa tulosta ilman suunnitteluresursseja.

Lähteet

Valmiina suojaamaan tietojasi?

Aloita PII-anonymisointi yli 285 entiteettityypillä 48 kielellä.

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.