Проблема витоків даних у сфері охорони здоров'я
Оновлено для 2026 року: 725 витоків даних у сфері охорони здоров'я у 2024 році розкрили 275 мільйонів записів (HHS OCR). Це більше, ніж населення всіх США.
Ціна висока. Середні збитки від одного витоку в охороні здоров'я становлять 10,22 мільйона доларів. Це найвищий показник серед усіх галузей — п'ятнадцять років поспіль (IBM Cost of Data Breach 2025). Половина всіх витоків в охороні здоров'я починається з постачальника або ділового партнера (HHS OCR 2024). Загроза не лише внутрішня.
Ці цифри змінили поведінку керівників лікарень. У великих медичних системах CISO не погоджує хмарні інструменти для роботи з PHI. Ризик надто високий.
Це створює справжній конфлікт для клінічних команд. Їм потрібно вилучати дані пацієнтів із нотаток. Така робота потрібна для досліджень, звітів про якість і наборів даних для навчання. Їм потрібні інструменти, які добре працюють у великих масштабах. Хмарні інструменти заблоковано. А розрив зростає.
Чому хмарні інструменти для PHI блокують
HHS Civil Rights посилило контроль за дотриманням вимог. Оновлення HIPAA Security Rule 2024 року стало першою великою зміною з 2013 року. Воно додало чіткі нові вимоги:
- Шифрування під час передавання та зберігання для всієї електронної PHI
- Угоди про партнерство (BAA) з кожним стороннім постачальником
- Записи про аналіз ризиків для кожного вибору постачальника
- Плани реагування на інциденти
Коли лікарня розглядає хмарний інструмент деідентифікації, служба безпеки має довести три речі. Перше: постачальник не може бачити PHI. Друге: BAA відповідає конкретному випадку використання. Третє: витік у постачальника не розкриє записів пацієнтів.
Половина витоків в охороні здоров'я вже починається з постачальників. Тому команди з ризиків часто не можуть схвалити хмарні інструменти для PHI. Це так незалежно від того, наскільки переконливі заяви постачальника про безпеку.
Навіть із підписаною BAA погляд CISO часто той самий: BAA розподіляє провину після витоку. Вона його не запобігає. Нам не потрібні додаткові постачальники в ланцюжку. Наш огляд безпеки пояснює, як локальна обробка виключає цей ланцюжок.
Проблема точності
Хмарне блокування мало б менше значення, якби простіші інструменти справлялися із завданням. Дослідження показують, що ні.
Дослідження 2025 року показало, що інструменти на основі LLM загального призначення пропускають понад половину клінічної PHI у вільних текстових нотатках (arXiv:2509.14464). HIPAA Safe Harbor вимагає видалити 18 типів ідентифікаторів. У клінічних нотатках ці ідентифікатори ховаються в скороченнях, місцевих термінах і словах інших мов.
Стандартні інструменти пропускають такі випадки:
- "Pt. J.D., DOB 4/12/67" — скорочене ім'я та формат дати
- "Dx: HCC f/u, appt at UCSF MC" — назва лікарні всередині клінічної скорописної абревіатури
- "Seen by Dr. Smith in ED #3, Room 12B" — ім'я лікаря з номером кімнати
- Формати MRN (7-8 цифр, залежно від закладу), які плутають з іншими числами
Набір даних для дослідження, створений на нотатках із рівнем пропусків 50% і більше, не відповідає правилам HIPAA. Він створює проблеми з IRB. Він ризикує призвести до заходів примусу, якщо прогалина виявиться після публікації статті. Наша сторінка про відповідність охоплює і стандарт Safe Harbor, і Expert Determination.
Прогалина в інструментах
Команди клінічної інформатики стикаються з реальною прогалиною. Кожен варіант має серйозне обмеження.
Комерційні хмарні сервіси працюють добре. Але вони вимагають надсилати захищені дані про здоров'я стороннім постачальникам. Більшість великих лікарняних систем це блокують.
Інструменти з відкритим кодом (як-от Presidio і MIST) працюють на місці. Але вони потребують складного налаштування та постійного догляду. Без додаткової індивідуальної роботи вони часто не досягають точності, потрібної для HIPAA. Прості визначення ключових термінів дивіться в нашому глосарії.
Ручна деідентифікація за методом Expert Determination потребує навченого статистика. Статистик має показати, що ризик повторної ідентифікації дуже малий. Це працює для невеликих наборів записів. Для 50.000+ записів це не працює.
Гібридні методи поєднують автоматизовані інструменти з ручною перевіркою позначених елементів. Це допомагає з обсягом. Але не вирішує проблему точності в автоматизованій частині.
Потреба очевидна. Клінічним командам потрібна точність на рівні хмари — NLP, regex і трансформерні моделі — тоді як самі документи лишаються на локальному обладнанні. Залежно від правил мережі це означає або вбудований інструмент без жодного зовнішнього виклику (anonym.plus), або інструмент, який читає файли на локальній машині, тоді як виявлення виконується через один API постачальника у списку дозволених, розміщений у ЄС (Desktop App від anonym.legal, нижче).
Регуляторна відповідь 2024 року
725 витоків у 2024 році викликали сувору регуляторну відповідь.
HHS Civil Rights того року видало понад 120 заходів примусу щодо HIPAA. Штрафи сягнули рекордного рівня. Запропоноване оновлення HIPAA Security Rule з березня 2025 року додає нові вимоги:
- Щорічні аудити шифрування
- Багатофакторний вхід для всіх систем, що обробляють електронну PHI
- Обов'язки розкриття інформації про кібербезпеку
- Суворіші правила нагляду за постачальниками
Для охоплених суб'єктів витрати на відповідність і далі зростають. Штрафи ростуть. Так само зростає й робота з підтвердження відповідності записами. Наш FAQ охоплює поширені запитання про ці правила.
HIPAA встановлює чіткі стандарти деідентифікації. Safe Harbor видаляє всі 18 типів ідентифікаторів. Expert Determination вимагає доказів низького ризику повторної ідентифікації. Інструмент, що пропускає понад половину PHI, не відповідає жодному зі стандартів.
Що потрібно локальній деідентифікації
Локальний інструмент має відповідати якості виявлення хмарних сервісів. Для цього потрібні чотири рівні.
Рівень 1 — Regex із клінічними шаблонами. Структуровані ідентифікатори — MRN, SSN, NPI, номери DEA — добре підходять для regex. Хороша клінічна бібліотека охоплює формати MRN, що використовуються в різних медичних системах. Вони дуже відрізняються від закладу до закладу.
Рівень 2 — Розпізнавання іменованих сутностей. Клінічні нотатки ховають PHI у звичайному тексті. Імена лікарів з'являються в розповідних реченнях. Імена пацієнтів трапляються в багатьох форматах. Місця згадуються в медичному анамнезі. NLP-моделі, навчені на клінічному тексті, можуть знайти все це.
Рівень 3 — Кілька мов. Охорона здоров'я США обслуговує пацієнтів, які розмовляють багатьма мовами. PHI може з'являтися рідною мовою пацієнта всередині перекладеної нотатки. Іспанська, китайська, арабська, в'єтнамська і тагальська мови трапляються в записах пацієнтів у США. Виявлення має охоплювати їх усі.
Рівень 4 — Оцінювання контексту. Семицифрове число в одній нотатці є MRN, а в іншій — дозою ліків. Оцінювання контексту зменшує кількість хибних спрацювань. Це означає менше позначок для перевірки і чистіші результати аудиту.
Пакетна обробка у великих масштабах
Дослідницькі набори даних великі. П'ятирічний проєкт в одному академічному медичному центрі може містити 500.000 вільних текстових нотаток. Щоб упоратися з таким обсягом, інструменту потрібні:
- Паралельні запуски для багатьох документів одночасно
- Підтримка DOCX, PDF, простого тексту та експортів EHR
- Відстеження прогресу та журнали помилок для невдалих елементів
- Журнал аудиту, що показує, що було оброблено і коли
- Вивід у ZIP для зручної передачі дослідницьким партнерам
Ручна перевірка не масштабується до такого рівня. Хмарні інструменти заблоковано. Єдиний шлях уперед — точна локальна обробка з надійною підтримкою пакетів.
Приклад із реальної практики
Регіональна лікарня хоче мати деідентифікований набір даних EHR для спільного дослідження з університетом-партнером. CISO заблокував хмарну обробку даних пацієнтів після цифр про витоки 2024 року.
Ось робочий процес з інструментом, орієнтованим на локальну роботу:
- Експорт. Система EHR експортує 50.000 клінічних нотаток як документи DOCX у захищену локальну папку.
- Обробка. Настільна програма за ніч виконує 10 пакетів по 5.000 документів на локальних робочих станціях.
- Перевірка. Команда клінічної інформатики перевіряє вибірку на відповідність правилам HIPAA Safe Harbor.
- Документування. Журнал обробки фіксує кожен оброблений елемент, використаний метод виявлення та позначку часу. Це журнал аудиту для IRB.
- Передача. Деідентифікований результат пакується і надсилається до університету захищеним каналом.
CISO погоджує, бо дані пацієнтів не залишають мережу лікарні. IRB погоджує, бо метод відповідає правилам документування Safe Harbor. Університет отримує дані, що відповідають його угоді про використання даних. Більше реальних прикладів дивіться в наших кейсах.
Коли цей підхід має обмеження
Локальна точна деідентифікація PHI водночас відповідає на заперечення CISO щодо хмари та на заперечення щодо точності — але деідентифікація є імовірнісним процесом, і те саме дослідження, що показує, що хмарні інструменти пропускають половину PHI, є попередженням, яке стосується кожного інструмента, зокрема й цього.
Жоден детектор не вловлює 100% клінічної PHI. Нотатки ховають ідентифікатори в скороченнях, помилках у написанні, вільному розповідному тексті та інших мовах. Багаторівневий локальний конвеєр вловлює значно більше, ніж LLM загального призначення, але залишкові пропуски неминучі. Для дослідницького випуску вибіркова перевірка людиною на відповідність Safe Harbor — це контроль, який робить набір даних захищеним з правового погляду; вона є частиною методу, а не формальністю.
Відповідність Safe Harbor — це висновок, а не результат роботи інструмента. Safe Harbor вимагає видалити всі 18 типів ідентифікаторів і не мати фактичного знання про те, що залишок може повторно ідентифікувати особу. Інструмент видаляє ідентифікатори; підтвердження того, що стандарт дотримано, — або замовлення Expert Determination — залишається відповідальністю охопленого суб'єкта та вашого IRB.
Ризик повторної ідентифікації зберігається після видалення ідентифікаторів. Рідкісні діагнози, малі популяції, дати та квазіідентифікатори можуть повторно ідентифікувати пацієнта навіть після видалення 18 типів. Для наборів даних із високим ризиком належним стандартом є Expert Determination зі статистичним аналізом ризику, а не самий лише Safe Harbor.
Локальне розгортання перекладає тягар підтримки на вас. Офлайн-моделі — це знімок певного моменту. Підтримання актуальності шаблонів виявлення, мовних моделей і форматів MRN тепер є завданням вашої команди, а застарілий локальний інструмент може опуститися нижче точності, яку ви перевірили під час встановлення. Повторно перевіряйте періодично, а не припускайте, що показники першого дня зберігаються.
Desktop App від anonym.legal забезпечує деідентифікацію PHI якості хмарного рівня. Вона використовує триетапне виявлення: Presidio NLP, regex і трансформери XLM-RoBERTa. Вона встановлюється і працює локально, але саме виявлення виконується на серверах anonym.legal — застосунок не постачається з моделями виявлення і потребує підключення до інтернету; його список дозволених обмежує з'єднання лише адресою anonym.legal. Підтримуються всі 18 ідентифікаторів HIPAA Safe Harbor. Пакетні запуски обробляють від 1 до 5.000 документів за раз.
Джерела
- Статистика витоків в охороні здоров'я HHS OCR 2024 — VERIFIED-EXTERNAL
- Звіт IBM про вартість витоку даних 2025 — VERIFIED-EXTERNAL
- arXiv:2509.14464 — Огляд деідентифікації за допомогою LLM (2025) — VERIFIED-EXTERNAL
- DeepStrike: Статистика витоків даних в охороні здоров'я 2025 — VERIFIED-EXTERNAL
- IntuitionLabs: Інструменти деідентифікації PHI з відкритим кодом — VERIFIED-EXTERNAL