Медицинские карты в ИИ-суммаризаторах: защита персональных данных
Передача медицинской карты в облачный ИИ-суммаризатор может сделать поставщика сервиса деловым партнёром по HIPAA, даже если данные зашифрованы.
Для регулируемой организации это означает необходимость соответствующего соглашения BAA и оценки того, как устроена обработка. Удаление имени само по себе проблему не решает: в карте могут остаться сведения, позволяющие определить пациента.
Суммаризация медицинских карт правила безопасности начинается с трёх решений: какие данные действительно нужны для задачи, на каком основании их можно передавать и какие условия обработки закреплены у конкретного сервиса. Название функции или обещание поставщика не отвечают на эти вопросы.
| Проверяемый аспект | Что следует установить |
|---|---|
| Статус данных | Содержит ли документ защищённую медицинскую информацию или идентификаторы пациента |
| Роль сервиса | Обрабатывает ли он данные от имени регулируемой организации |
| Договор | Требуется ли BAA и покрывает ли оно фактический сценарий обработки |
| Состав документа | Можно ли сократить объём данных или корректно обезличить материал |
| Поведение сервиса | Каковы сроки хранения, правила использования запросов, место обработки и круг субподрядчиков |
| Инциденты | Какие обязанности по уведомлению применимы к организации и поставщику |
Облачный суммаризатор может быть деловым партнёром HIPAA
Статус определяется функцией сервиса. По разъяснению HHS, облачный провайдер становится business associate, если от имени организации, подпадающей под HIPAA, создаёт, получает, хранит или передаёт электронную защищённую медицинскую информацию — ePHI. Это относится и к сервису, который хранит данные, не имея ключа для их расшифровки.
Следствие для организации практическое: если провайдер обрабатывает ePHI от имени covered entity или другого business associate, стороны должны заключить BAA. Соглашение не заменяет оценку рисков и не подтверждает автоматически, что выбранная конфигурация подходит для конкретного процесса. Нужно понимать, какие компоненты сервиса получают данные, где они сохраняются и какие операции выполняются после формирования краткого изложения.
Условие «данные шифруются» не закрывает вопрос о роли поставщика. Если сервис хранит или передаёт ePHI по поручению организации, шифрование и отсутствие у провайдера ключа сами по себе не отменяют статус business associate и необходимость BAA. Это важное различие при выборе между публичным чат-ботом и корпоративным сервисом с договорными обязательствами.
Для первичной оценки полезно описать поток данных без маркетинговых терминов:
- кто загружает карту и на каком основании;
- какие поля попадают в запрос;
- какие части системы получают исходный документ и результат;
- сохраняются ли запрос и ответ после завершения сессии;
- могут ли данные попадать в журналы, резервные копии или инструменты поддержки;
- привлекаются ли субподрядчики и к каким данным они имеют доступ.
Сведения о сроках хранения, использовании запросов для обучения, местонахождении обработки, доступе сотрудников и субподрядчиках нельзя считать установленными заранее. Эти условия различаются у конкретных поставщиков и должны проверяться по их документам и договорным настройкам. Если документация не даёт ясного ответа, неопределённость остаётся риском, а не подтверждением безопасности.
Шифрование снижает отдельные риски. Оно не подменяет правовую оценку роли поставщика и условий обработки.
Проверять нужно не только основной договор. Значение имеют настройки продукта, политика хранения, условия поддержки, порядок удаления данных и фактическая конфигурация аккаунта. Обещание «HIPAA-compliant» не доказывает, что конкретная версия сервиса, выбранный тариф и сценарий суммаризации охвачены нужными обязательствами.
Минимум данных снижает риск до отправки
HIPAA в общем случае требует принимать разумные меры, чтобы ограничивать использование, раскрытие и запросы PHI минимумом, необходимым для цели. Для суммаризации это означает, что исходная карта не должна автоматически передаваться целиком, если задачу можно выполнить на сокращённом фрагменте. При этом у правила есть исключения, в том числе для определённых раскрытий или запросов медицинским работником в целях лечения.
Состав минимального набора зависит от задачи. Для краткого резюме истории болезни могут требоваться сведения о диагнозах, назначениях и динамике лечения. Прямые идентификаторы, контактные данные и подробности, не влияющие на результат, могут быть лишними. Решение должно приниматься по цели обработки, а не по привычке загружать весь документ.
Ограничение данных не сводится к удалению имени из заголовка. В тексте могут оставаться даты, адресные сведения, редкие сочетания диагнозов, описания конкретных событий или детали маршрута лечения. В совокупности они способны выделить человека даже без одного очевидного идентификатора.
Перед обработкой разумно разделить документ на три слоя:
1. Содержание, необходимое для результата. Например, релевантные диагнозы, назначения или клиническая динамика, если именно они нужны для заданного резюме.
2. Идентификаторы, которые можно исключить. Имя, контакты и другие сведения, не влияющие на задачу, следует убрать до передачи, когда это допустимо для процесса.
3. Контекст, который требует отдельной оценки. Даты, редкие заболевания и подробные описания могут быть необходимы клинически, но одновременно увеличивают риск идентификации.
Такое разделение не гарантирует обезличивание. Оно дисциплинирует передачу данных и позволяет объяснить, зачем сервис получил конкретную информацию. Если резюме нужно для лечения, требования и исключения могут отличаться от исследовательского, административного или учебного применения. Одного универсального шаблона для всех задач нет.
Два метода обезличивания по HIPAA
HHS описывает два метода обезличивания PHI: Expert Determination и Safe Harbor. Выбор метода зависит от контекста, доступных данных и допустимого риска. Ни один из них не означает, что вероятность повторной идентификации становится нулевой.
При Expert Determination квалифицированный эксперт применяет признанные статистические и научные принципы и оценивает, достаточно ли мал риск идентификации. Это не операция, которую можно надёжно заменить случайным удалением нескольких полей или настройкой кнопки в суммаризаторе. Оценка должна учитывать, какие сведения остаются и какие дополнительные данные могут быть доступны.
Safe Harbor основан на удалении перечисленных идентификаторов и отсутствии фактического знания, что оставшиеся сведения можно использовать для идентификации человека. В числе требований есть ограничения для дат, напрямую связанных с конкретным человеком, и для почтовых индексов. Для некоторых ZIP-кодов допускаются первые три цифры, но только при соблюдении установленного условия о численности населения. Конкретная обработка зависит от правил метода, а не от общего впечатления, что документ стал «анонимным».
Операционные последствия различаются:
| Подход | Основа | Что важно для суммаризации |
|---|---|---|
| Expert Determination | Оценка риска экспертом на основе признанных принципов | Нужно оценивать остаточные данные и вероятность идентификации в конкретном контексте |
| Safe Harbor | Удаление установленных идентификаторов и отсутствие фактического знания об идентифицируемости оставшихся данных | Нужна проверка всех категорий идентификаторов, а не только имени и контактов |
Даже после выполнения одного из методов HHS указывает на ненулевой риск повторной идентификации. Поэтому обезличенный текст всё равно требует контроля доступа, ограничения цели использования и оценки конкретного сервиса. Особенно осторожно следует обращаться с редкими диагнозами и уникальными описаниями событий: они могут сохранять высокую различительную способность.
Для внутреннего процесса полезно фиксировать, кто проводил обезличивание, какой метод использовался, для какой задачи и какие категории данных были оставлены. Такая запись не заменяет правовую оценку. Она помогает воспроизвести решение и обнаружить расхождение между заявленным процессом и фактической загрузкой документов.
Генеративный ИИ создаёт риск запоминания и вывода данных
NIST описывает риски приватности генеративных ИИ-систем, включая раскрытие или вывод чувствительной информации о людях. Среди механизмов — запоминание данных и получение персональных сведений из разрозненных фрагментов. Для медицинских карт это означает, что оценивать нужно не только содержание готового ответа. Значение имеют запрос, входной документ, логи и сохранённые системой данные.
Фреймворк NIST AI Risk Management Framework 1.0 вышел 26 января 2023 года. Профиль рисков генеративного ИИ NIST AI 600-1 опубликован 26 июля 2024 года. Эти документы помогают структурировать анализ рисков, но сами по себе не устанавливают универсальный технический набор настроек для суммаризации медицинских карт.
Проверка модели по одному примеру также мало говорит о её поведении во всех сценариях. Результат зависит от версии системы, параметров, инструкций, подключённых инструментов и режима хранения. Организациям следует различать два вопроса: насколько корректно модель сокращает текст и насколько безопасно сервис обрабатывает исходные данные и результат.
Внутренний контроль можно строить вокруг нескольких точек:
- ограничить перечень сотрудников, которые могут загружать медицинские документы;
- исключить личные аккаунты и неуправляемые версии сервиса из рабочего процесса;
- задавать конкретную цель суммаризации и не включать в запрос сведения сверх неё;
- контролировать, где сохраняются входные данные, ответы и технические журналы;
- проверять, можно ли отключить использование запросов для улучшения модели и что именно означает такая настройка;
- определить порядок удаления документов и действий при обнаружении несанкционированного доступа.
Эти меры не являются готовой сертификацией и не гарантируют отсутствие утечки. Их задача — уменьшить ненужное раскрытие и сделать обработку проверяемой. Если поставщик не раскрывает порядок хранения или использования данных, организация не получает основания считать риск устранённым.
Отдельный риск связан с качеством резюме. ИИ может пропустить важную деталь, перепутать временную последовательность или сформулировать вывод, которого нет в исходной карте. Это влияет на медицинское решение и требует отдельного контроля специалистом. Однако проверка точности не заменяет проверку конфиденциальности: корректный ответ может быть получен после неправомерной или чрезмерной передачи данных.
HIPAA — не единственный возможный режим
Применимые требования зависят от страны, типа организации и самого сервиса. HIPAA не распространяется автоматически на каждое приложение, каждый суммаризатор и каждого пользователя медицинской информации. В США для ряда приложений и технологий, не подпадающих под HIPAA, FTC Health Breach Notification Rule может распространяться на поставщиков personal health records, связанные организации и их сторонних поставщиков услуг.
Правило FTC предусматривает уведомления при утечке незащищённых идентифицируемых медицинских данных в охватываемых им случаях. Для некоторых инцидентов, затрагивающих 500 или более человек, предусмотрено уведомление СМИ. Применимость зависит от характера продукта, участников обработки и обстоятельств инцидента. Нельзя определять её только по тому, что сервис хранит медицинские сведения или называет себя приложением для здоровья.
В Европейском союзе данные о здоровье относятся к специальным категориям персональных данных по GDPR. Их обработка в общем случае запрещена, кроме ситуаций, для которых применимо предусмотренное статьёй 9 исключение. Поэтому сам факт наличия ИИ-функции не создаёт правового основания для загрузки карты. Организации нужно определить применимое основание обработки и проверить связанные с ним условия.
Для трансграничного процесса к этому добавляются вопросы о местонахождении обработки и вовлечённых поставщиках. Если сервис работает через несколько инфраструктурных компонентов, одного адреса головной компании недостаточно для понимания маршрута данных. Доступные сведения следует сверять с договором, политиками сервиса и фактическими настройками.
Практическая последовательность выглядит так:
1. Определить страну, тип организации и применимый режим обработки.
2. Установить, содержит ли документ ePHI или другую защищённую медицинскую информацию.
3. Выяснить роль суммаризатора и необходимость договора, включая BAA там, где действует HIPAA.
4. Сократить передаваемый набор и выбрать допустимый способ обезличивания, если он подходит для цели.
5. Проверить хранение, обучение на запросах, субподрядчиков, доступ сотрудников и удаление.
6. Зафиксировать порядок проверки результата и реагирования на инциденты.
Суммаризация медицинских карт нейросетью допустима только в рамках конкретного процесса, где понятны цель, объём данных, роли участников и договорные условия. Универсальной отметки, после которой сервис автоматически становится безопасным, нет. Если организация не может установить, что именно происходит с загруженной картой, передавать её в такой сервис не следует.