anonym.legal

By · Last updated 2026-04-02

Назад към блогаЗдравеопазване

LLM инструментите пропускат 50% от клиничния PHI

Проучване от 2025 г. установи, че LLM инструментите пропускат над 50% от клиничния PHI в многоезични документи. 34,8% от всички входни данни в ChatGPT съдържат чувствителна информация.

April 2, 20269 мин. четене
LLM PHI detectionHIPAA de-identificationclinical NLPSafe Harbor methodhealthcare AI compliance

Проблемът с 50% пропускане

Проучване от 2025 г. (arXiv:2509.14464) тества LLM инструменти върху клинични досиета. Резултатите са лоши. Тези инструменти пропускат над 50% от клиничния PHI в многоезични документи. Причината е проста. LLM инструментите са създадени за текстов изход. Не са създадени за задачата за детекция с висок recall, която HIPAA изисква.

HIPAA Safe Harbor изброява 18 защитени типа идентификатори. Имена, дати, телефонни номера, SSN, MRN, идентификатори на здравни планове, идентификатори на устройства и IP адреси. Всеки изисква собствена логика за детекция.

Клиничните бележки усложняват допълнително задачата. Ето пример: "Пц. Иван Д., ДатаР 12.04.67, MRN 1234567, приет 15.03.24, Д-р Петров назначи ЕКГ." Едно изречение. Пет защитени идентификатора. Повечето използват съкратени форми. Модел, изграден за клинично значение, често се проваля при задачата за детекция.

Какво пропускат LLM инструментите и защо

LLM инструментите се провалят при клинични досиета по определени начини.

Идентификатори в съкратена форма: Клиничните бележки използват стенография. ДатаР, MRN и Пц. са чести форми. Модел, настроен за клинично значение, може да не маркира "Пц. Иван Д." като лично. Извличането на чувствителни данни изисква различна цел.

Зависими от контекст дати: Не всички дати представляват еднакъв риск. "Възраст 67" е мек маркер. "ДатаР 12.04.67" е пряк защитен идентификатор. "15.03.24" като дата на приемане също е защитена. Само съвпадение на шаблони не е достатъчно.

Формати извън САЩ: Cyberhaven (Q4 2025) установи, че 34,8% от всички входни данни в ChatGPT съдържат чувствителни данни, включително многоезичен PII. В здравеопазването това означава ID номера на записи извън САЩ, регионални формати на дати и местни типове здравни идентификатори. Инструментите, обучени за САЩ, ги пропускат постоянно.

Персонализирани болнични идентификатори: Болниците използват собствени MRN формати, идентификатори на персонала и кодове на обектите. Те не присъстват в стандартните данни за обучение на NER. Инструмент без поддръжка за персонализирани субекти не може да ги открие.

Рискът при изследователски набори от данни

Болница, изграждаща изследователски набор от данни от 500 000 бележки, е изправена пред реален проблем с постигането на съответствие. HIPAA изисква стандарт на "много малък риск" за деидентифицирани данни. Инструмент, пропускащ половината от всички защитени идентификатори, не може да отговори на това изискване.

Изследователските архиви не са чисти данни. Бележките обхващат много отдели, периоди от време и понякога езици. Инструмент, работещ добре с данни за фактуриране, може да се провали при разказни бележки. Чувствителните данни в свободен текст нямат полеви маркер.

Одобрението на IRB добавя допълнителни изисквания. Институциите трябва да покажат използвания метод, премахнатите типове идентификатори и извършените проверки. Инструмент, пропускащ половината от всички записи, не може да изпълни тези изисквания.

Вижте нашия преглед на съответствието и практики по сигурност за начина, по който anonym.legal поддържа HIPAA работата.

Решението с три слоя

Проучването от 2025 г. установи един ясен модел. Инструментите с най-ниски нива на пропускане използват три слоя за детекция.

Слой първи - regex: Открива структурирани идентификатори. SSN, MRN, телефонни номера, идентификатори на здравни планове. Надежден при фиксирани формати.

Слой втори - NER: Използва трансформерни модели. Открива имена, дати и чувствителни данни в разказен текст. Работи там, където regex не може.

Слой трети - персонализирани субекти: Обработва специфични за обекта форми. Персонализирани MRN шаблони, идентификатори на персонала, кодове на обекти. Нито един стандартен модел не покрива тях.

Чистите ML инструменти деградират при съкратени форми и нeanглийски текст. Чистите regex инструменти пропускат чувствителни данни без полеви маркер. Нито един от двата поотделно не е достатъчен.

Само дизайнът с три слоя постига нива на пропускане под 5% в проучването. Това е нивото за съответствие с HIPAA Safe Harbor.

Вижте нашето ръководство за деидентификация по HIPAA Safe Harbor за изследвания за следващи стъпки.

Източници

Готови ли сте да защитите данните си?

Започнете анонимизация на PII с 285+ типа субекти на 48 езика.

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.