Ошибка в предположении о соблюдении требований, которую совершают организации здравоохранения
Каждая организация здравоохранения, внедряющая облачные ИИ-инструменты, получает один и тот же совет от своей юридической команды: подпишите Соглашение о деловом партнерстве с поставщиком, и вы будете защищены в соответствии с HIPAA.
Требование о BAA действительно. Правило конфиденциальности HIPAA требует от покрытых субъектов подписания BAA с деловыми партнерами — поставщиками, которые создают, получают, хранят или передают защищенную медицинскую информацию от их имени. Поставщик ИИ, который обрабатывает ваши клинические заметки, должен иметь BAA, прежде чем он коснется этих данных.
Но требование о BAA касается только контрактных отношений между организациями. Оно не затрагивает то, что происходит с PHI на инфраструктуре поставщика после подписания контракта.
Критический вопрос не в том, есть ли у вас BAA. Важно, может ли поставщик получить доступ к вашему PHI в открытом виде — и что происходит с этими данными, когда происходит утечка.
Что на самом деле охватывает Соглашение о деловом партнерстве
BAA устанавливает, что деловой партнер будет:
- Использовать PHI только для целей, указанных в соглашении
- Реализовать соответствующие меры безопасности для защиты PHI
- Сообщать о любых утечках PHI покрытому субъекту
- Вернуть или уничтожить PHI по окончании соглашения
BAA является контрактным обязательством. Деловой партнер обязуется ответственно обращаться с PHI, внедрять разумные меры безопасности и уведомлять покрытый субъект, если что-то пойдет не так.
Что BAA не делает:
- Не предотвращает утечки систем делового партнера
- Не устраняет технический доступ делового партнера к PHI в расшифрованном виде
- Не защищает покрытый субъект от ответственности по HIPAA, когда деловой партнер подвергается утечке
Когда облачный поставщик ИИ подвергается утечке, и их серверное хранилище содержит PHI ваших пациентов в расшифровываемом виде, обязательство по уведомлению об утечке выполняется BAA — но утечка PHI реальна, пациенты страдают, и покрытый субъект сталкивается с расследованием по соблюдению HIPAA, независимо от того, какой контракт был подписан.
Проблема PHI на стороне сервера
Облачные ИИ-инструменты, которые обрабатывают данные здравоохранения, работают на основе фундаментальной архитектуры: данные отправляются на серверы поставщика, обрабатываются там ИИ-моделью, и результаты возвращаются пользователю. Для этого необходимо, чтобы инфраструктура поставщика имела доступ к данным в форме, которую может обработать ИИ-модель.
Это означает, что данные либо не зашифрованы на серверах поставщика, либо шифрование осуществляется поставщиком с использованием ключей, которые контролирует поставщик.
Шифрование, контролируемое поставщиком, не является сквозным шифрованием. Если поставщик держит ключи, он может расшифровать. Если поставщик может расшифровать, скомпрометированный сервер поставщика раскрывает ваши данные в читаемой форме.
Это архитектура, которую BAA не рассматривает. BAA требует от поставщика использовать "соответствующие меры безопасности" — но шифрование на стороне сервера, контролируемое поставщиком, удовлетворяет этому требованию контрактно, даже если оно не обеспечивает защиту от утечек со стороны поставщика.
Данные здравоохранения, обрабатываемые облачным ИИ в этих условиях, имеют специфический профиль риска: PHI, используемая для генерации клинической документации с поддержкой ИИ, кодов выставления счетов или планов лечения, существует в инфраструктуре поставщика в форме, которая может быть прочитана, если эта инфраструктура будет скомпрометирована.
Исполнение HIPAA не различает "мы подверглись утечке, но у нас был BAA" и "мы подверглись утечке." PHI пациентов покрытого субъекта была раскрыта. У покрытого субъекта была обязанность защитить ее. Техническая реализация этой защиты определяет, была ли обязанность выполнена — а не контракт.
Что меняет архитектура с нулевым знанием
Архитектура с нулевым знанием решает проблему доступа на стороне сервера на архитектурном уровне.
В реализации с нулевым знанием PHI анонимизируется до того, как покинет среду покрытого субъекта. Поставщик ИИ получает анонимизированные данные — клинические заметки с замененными идентификаторами пациентов на структурированные токены, счета с замененными именами и номерами счетов, планы лечения с удаленной демографической информацией.
ИИ-модель обрабатывает анонимизированный контент и возвращает результаты. Покрытый субъект повторно связывает результаты с оригинальной записью пациента, используя отображение токенов, которое никогда не передавалось поставщику.
Что это меняет:
Поставщик никогда не получает PHI. Клинические заметки, обработанные через анонимизацию с нулевым знанием, не содержат имен, дат рождения, адресов, номеров медицинских карт или других идентификаторов PHI, определенных HIPAA. ИИ-модель поставщика работает с анонимизированными данными.
Утечка поставщика не раскрывает PHI. Если инфраструктура поставщика ИИ будет скомпрометирована, данные, хранящиеся там, содержат анонимизированный контент без идентифицируемой информации о пациенте. Утечка не может привести к раскрытию PHI, потому что PHI никогда не передавалась.
Требования BAA удовлетворяются на более высоком уровне. Покрытый субъект реализовал технические меры безопасности, которые превышают контрактный минимум — не потому, что это требует BAA, а потому, что архитектура делает раскрытие PHI технически невозможным, а не просто контрактно запрещенным.
Стандарт соблюдения, который действительно имеет значение
Исполнение HIPAA под управлением Офиса гражданских прав HHS сосредоточено на том, реализовали ли покрытые субъекты разумные и соответствующие меры безопасности для защиты PHI. "Разумные и соответствующие" оцениваются в зависимости от риска для PHI, вероятности компрометации и стоимости доступных мер безопасности.
Облачные поставщики ИИ, обрабатывающие PHI в рамках BAA, подвергались утечкам. Риск не является гипотетическим. Вопрос, который задают следователи по соблюдению, заключается в том, реализовал ли покрытый субъект меры безопасности, которые учитывали известный профиль риска их отношений с поставщиками.
Покрытый субъект, который полагался на BAA и шифрование на стороне сервера, контролируемое поставщиком, принял контрактный подход к технической проблеме. Покрытый субъект, который внедрил анонимизацию с нулевым знанием до передачи любых PHI поставщикам ИИ, принял технический подход, который устранил раскрытие.
Второй подход решает вопрос соблюдения: PHI никогда не находилась в распоряжении поставщика в пригодной для использования форме. Нет утечки, о которой нужно сообщать, нет пациента, которого нужно уведомлять, нет расследования по соблюдению, на которое нужно отвечать — потому что архитектура сделала невозможным режим сбоя.
Для организаций здравоохранения, оценивающих внедрение облачного ИИ, рамки соблюдения не "получите BAA и продолжайте." Это "обеспечьте, чтобы PHI никогда не достигала среды поставщика в восстанавливаемой форме." BAA удовлетворяет контрактное требование. Архитектура с нулевым знанием удовлетворяет техническое требование.
Источники: