By · Last updated 2026-06-05

Vissza a BlograEgészségügy

HHS 2025: Az AI klinikai feljegyzések PHI-t igényelnek

Az AI-átírási rendszerek véletlenül az A páciens PHI-ját B páciens rekordjába helyezhetik. Íme, miért az EHR-mentés előtti valós idejű PHI-észlelés az ellenőrzés.

June 5, 20269 perc olvasás
HIPAA complianceclinical documentationPHI detectionEHR privacyHHS 2025

Az AI klinikai feljegyzések adatvédelmi problémája

2026-ra frissítve

Kórházak és klinikák AI-t használnak klinikai feljegyzések írásához. Az AI hangot transzkribál és szöveget vázol fel. Ez azonban HIPAA-rést hoz létre, amelyet a kézi felülvizsgálat nem tud bezárni.

Az AI-generált feljegyzések háromféleképpen tárják ki a betegrekordokat:

  1. Keresztkontamináció: Az AI egyik páciens adatait átemelheti egy másik páciens rekordjába. Az orvosi AI-tanulmányok kimutatták ezt a kockázatot.
  2. Kontextusszivárgás: A beteg adatai rossz mezőbe kerülnek — számlázási megjegyzésbe, kutatási mezőbe vagy beutalási formba. Az AI kontextus, nem mezőcél alapján tölti ki a mezőket.
  3. Szállítói adatfelhasználás: Sok AI-szállító visszaküldi a feljegyzéseket modellellenőrzésre, hacsak ki nem lép ebből. Ez betegadatokat küld harmadik fél szervereire. Ezek a szerverek esetleg nem rendelkeznek aláírt BAA-val.

A HHS 2025-ben javasolt szabályozást tett közzé. Ez szerint az AI-eszközöket alkalmazó szervezeteknek be kell vonniuk ezeket az eszközöket a kockázatelemzésükbe. Ez formális szabályt teremt az AI-segített klinikai munkához.

A 2025-ös HHS AI kockázatelemzési szabály

A HHS új szabályokat javasolt az AI-t alkalmazó érintett szervezetek számára. Minden betegrekordokat érintő AI-rendszernek szerepelnie kell a szervezet kockázatelemzésében.

A szabálynak három része van:

Technológiai biztosítékok: Vizsgálja felül az egyes AI-eszközöket. Kérdezze:

  • Küldi-e a betegrekordokat a rendszereken kívülre?
  • Tárolja-e a betegrekordokat a szerverein használat után?
  • Rossz rekordba írja-e a betegadatokat?

Alkalmazotti képzés: A képzésnek le kell fednie az AI-specifikus kockázatokat. Ebbe beletartoznak a rekordkeveredési esetek.

Fizikai ellenőrzések: Az AI-eszközöket futtató munkaállomásoknak a fizikai hozzáférési ellenőrzések részét kell képezniük.

Az AI klinikai eszközök közé tartoznak a hang-szöveg szolgáltatások, az AI feljegyzésvázló eszközök és a kódolási eszközök.

Miért működik a mentés előtti észlelés

A legjobb technikai ellenőrzés a PHI-észlelés, mielőtt a feljegyzés az EHR-be kerül.

Mentés előtti észlelés nélkül:

  • Az AI megírja a vázlatot
  • Az alkalmazott kézzel felülvizsgálja, időnyomás alatt
  • A feljegyzés az EHR-be kerül
  • A PHI-hibák most az állandó rekordban vannak
  • A javításuk auditbejegyzéseket és szivárgásvizsgálatot igényel

Mentés előtti észleléssel:

  • Az AI megírja a vázlatot
  • A PHI-vizsgálat a feljegyzés mentése előtt fut
  • A megjelölt elemek az alkalmazotthoz kerülnek felülvizsgálatra
  • Az alkalmazott mentés előtt javítja a hibákat
  • Az EHR-rekord kezdettől fogva tiszta

A mentés előtti észlelés megfelel a HIPAA biztonsági szabály 164.312(b) bekezdésének. Ez a szabály olyan rendszereket ír elő, amelyek rögzítik és ellenőrzik a tevékenységeket. A mentés előtti vizsgálat auditnaplót hoz létre minden felülvizsgált feljegyzéshez.

A 18 PHI-kategória az AI-feljegyzésekben

A HIPAA Safe Harbor megköveteli 18 PHI-kategória eltávolítását (45 CFR 164.514(b)). Az AI-feljegyzések mind a 18-at felszínre hozhatják váratlan módokon:

  • Nevek — egy páciens egy családtagot nevez meg a tünethistóriában
  • Helyszín — lakóhely a társadalmi anamnézisben
  • Dátumok — születési dátumok, felvételi dátumok, eljárási dátumok
  • Telefon- és faxszámok — elérhetőségi adatok a beutalóban
  • E-mail-címek — a páciens által megadott elérhetőségi adatok
  • TAJ-számok — biztosítási összefüggés
  • Orvosi rekordszámok — keresztreferencia az AI-összefoglalókban
  • Egészségbiztosítási számok — biztosítási összefüggés
  • Számlaszámok — számlázási összefüggés
  • Engedélyszámok — szolgáltató engedélyinformációja a beutalókban
  • Járműazonosítók — baleseti összefüggés a sérülési feljegyzésekben
  • Eszközazonosítók — implantátumos feljegyzések
  • URL-ek — páciens által benyújtott linkek az egészségügyi rekordokhoz
  • IP-címek — távoli munkamenet-naplók
  • Biometrikus azonosítók — ujjlenyomat vagy hangmintaadatok
  • Fényképek — csatolt média az AI-rendszerekben
  • Minden más egyedi azonosító — egyedi intézményi azonosítók

Az AI-modellek ezeket kontextusból hozhatják létre. Az észlelésnek mind a 18-at le kell fednie — nem csak a TAJ-számokat és a dátumokat.

A mentés előtti észlelés hozzáadása

Egy mentés előtti PHI-ellenőrzés öt lépést követ:

  1. Az AI megírja a feljegyzésvázlatot
  2. A feljegyzés szövege detektálási API-hoz kerül, mielőtt az alkalmazott látná
  3. A megjelölt elemek megjelennek a vázlatnézetben
  4. Az alkalmazott felülvizsgálja a jelzéseket a normál feljegyzés-felülvizsgálat során
  5. Az alkalmazott menti a feljegyzést — jelzett elemek nélkül, vagy dokumentált indokkal

Amire a rendszernek szüksége van:

  • Sebesség: 200 ms alatt, hogy ne lassítsa a munkafolyamatot
  • Lefedettség: mind a 18 HIPAA-kategória plusz helyi minták, mint a saját MRN-formátuma
  • Pontozás: a 85% feletti elemek automatikusan megjelölve; 50–85% közöttiek alkalmazotti felülvizsgálatot igényelnek; 50% alattiak csak referenciaként jelennek meg
  • Auditnapló: naplózza az egyes megjelölt elemeket, a pontszámát és a felülvizsgáló döntését

Az auditnapló közvetlen bizonyítékot nyújt a HHS kockázatelemzéshez. Azt mutatja, hogy van ellenőrzése az AI által generált PHI-hoz.

Felhasználási eset: Mentés előtti észlelés egy orvosi központban

Egy akadémiai orvosi központ AI-ambiens rendszert használt orvosi feljegyzésekhez. Egy 90 napos audit két keveredési esetet tárt fel. Az egyik feljegyzésben egy másik páciens születési dátuma volt. Egy másikban egy családtag neve és TAJ-száma szerepelt a társadalmi anamnézisből.

Mentés előtti PHI-észlelés hozzáadása után:

  • Minden AI-vázlatot átvizsgáltak az orvosi felülvizsgálat előtt
  • Átlagos vizsgálati idő: 47 ms — nem érezni a munkafolyamatban
  • 90 nap alatt: 1 247 elem lett megjelölve 8 400 feljegyzésből
  • Az alkalmazottak felülvizsgálták és megoldották a megjelölt elemek 94%-át
  • Nulla rekordkeveredési incidens a bevezetés után

A rendszer havi jelentést készít. Ez mutatja az észlelési arányokat, a felülvizsgálati arányokat és az entitástípusokat. Ez a jelentés a HIPAA biztonsági szabály 164.312(b) bekezdése szerinti audit-ellenőrzési bizonyítékként szolgál.

Az ezt a munkafolyamatot felépítő csapatok az anonym.legal PHI-észlelési API-ját használhatják. Az a 18 HIPAA-kategóriát 200 ms alatti késlekedéssel fedi le. A beállítási lépésekhez lásd a PHI-észlelési integrációs útmutatót. A teljes összefüggéshez látogasson el az egészségügyi felhasználási esetek oldalra.

Források

Készen áll az adatai védelmére?

Kezdje el a PII anonimizálását 285+ entitástípuson 48 nyelven.

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.