Когато CISO казват не на обработката на PHI в облака

Проблемът с нарушенията на данни в здравеопазването

Актуализирано за 2026: 725 нарушения на здравни данни през 2024 г. разкриха 275 милиона записа (HHS OCR). Това число надхвърля цялото население на САЩ.

Цената е висока. Нарушенията в здравеопазването струват средно 10,22 милиона долара всяко. Това е най-високата цена във всеки отрасъл – петнадесет поредни години (IBM Cost of Data Breach 2025). Половината от всички нарушения в здравеопазването започват при доставчик или бизнес партньор (HHS OCR 2024). Заплахата не е само вътрешна.

Тези числа промениха поведението на ръководителите на болници. В големите здравни системи CISO няма да одобри облачни инструменти за работа с PHI. Рискът е твърде голям.

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

Защо облачните инструменти за PHI се блокират

HHS Civil Rights засили прилагането. Актуализацията на правилото за сигурност на HIPAA от 2024 г. беше първата голяма промяна от 2013 г. насам. Тя добави ясни нови изисквания:

• Криптиране при пренос и в покой за всички електронни PHI
• Споразумения за бизнес сътрудничество (Business Associate Agreements, 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 на доставчик, хостван в ЕС (десктоп приложението на anonym.legal, по-долу).

Регулаторният отговор през 2024 г.

725 нарушения през 2024 г. предизвикаха силен регулаторен отговор.

HHS Civil Rights издаде повече от 120 мерки за прилагане на HIPAA през същата година. Глобите достигнаха рекордни нива. Предложената актуализация на правилото за сигурност на HIPAA от март 2025 г. добавя нови изисквания:

• Годишни одити на криптирането
• Многофакторен вход за всички системи, които обработват електронни PHI
• Задължения за разкриване на информация за киберсигурността
• По-строги правила за надзор на доставчиците

За задължените субекти разходите за съответствие продължават да растат. Глобите растат. Расте и работата по доказване на съответствието чрез записи. Нашият раздел Често задавани въпроси обхваща чести въпроси за тези правила.

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 г.

Ето работния процес с инструмент, който е на първо място локален:

1. Експорт. EHR системата експортира 50 000 клинични бележки като DOCX документи в защитена локална папка.
2. Обработка. Десктоп приложението през нощта изпълнява на локални работни станции 10 пакета по 5 000 документа.
3. Преглед. Екипът по клинична информатика проверява извадка спрямо правилата на HIPAA Safe Harbor.
4. Документиране. Журналът на обработката записва всеки обработен елемент, използвания метод на откриване и времеви печат. Това е одитната следа за IRB.
5. Трансфер. Деидентифицираният изход се пакетира и се изпраща на университета по защитен канал.

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 формати вече е задача на вашия екип, а остарял локален инструмент може да падне под точността, която сте валидирали при инсталацията. Валидирайте отново периодично, вместо да приемате, че производителността от първия ден се запазва.

Десктоп приложението на anonym.legal осигурява деидентификация на PHI с облачно качество. Използва тристепенно откриване: Presidio NLP, regex и XLM-RoBERTa трансформъри. Инсталира се и работи локално, но самото откриване се изпълнява на сървърите на anonym.legal – приложението не доставя модели за откриване и изисква интернет връзка; списъкът му с разрешени ограничава връзката само до anonym.legal. Поддържат се всички 18 идентификатора на HIPAA Safe Harbor. Пакетните обработки обхващат 1–5 000 документа наведнъж.

Източници

• HHS OCR Healthcare Breach Statistics 2024 – VERIFIED-EXTERNAL
• IBM Cost of a Data Breach Report 2025 – VERIFIED-EXTERNAL
• arXiv:2509.14464 – LLM De-Identification Survey (2025) – VERIFIED-EXTERNAL
• DeepStrike: Healthcare Data Breaches 2025 Statistics – VERIFIED-EXTERNAL
• IntuitionLabs: Open-Source PHI De-Identification Tools – VERIFIED-EXTERNAL