Протокол повторного контакта IRB: руководство по обратимому шифрованию
IRB теперь требуют не только план деидентификации. Необходим также план повторного контакта. Нужно подтвердить два условия. Во-первых, внешние стороны не могут получить доступ к реальным именам пациентов. Во-вторых, ваша команда — может, при наличии разрешения от комитета по этике.
Это двустороннее требование возникло из реального опыта. В ходе длительных исследований были получены срочные результаты. Но записи оказались заблокированы. Пути назад не существовало. Это препятствовало оказанию медицинской помощи. Регуляторы приняли к сведению.
О том, как мы поддерживаем этот подход, читайте в обзоре соответствия и описании мер безопасности.
Почему IRB нужна двустворчатая дверь
Штрафы GDPR выросли на 56% в 2024 году (ежегодный доклад DLA Piper 2025). Статья 89 GDPR реагирует на эту тенденцию. Она требует псевдонимизации — а не полного удаления — исследовательских данных. Норма признаёт, что исследования иногда нуждаются в пути возврата к исходной записи.
Исследование NEJM AI 2024 года изучило деидентификацию на основе LLM. В нём была выявлена фундаментальная проблема: обезличенные клинические заметки сохраняют связь с личностью пациента через те же клинические паттерны, которые делают их ценными. Авторы рекомендуют: использовать псевдонимизацию с задокументированным планом управления ключами — это сохраняет путь для повторного контакта.
Ваш IRB должен видеть обе стороны этой двери. Кто может провести повторную идентификацию? На каких условиях? Кто хранит ключ? Что фиксируется в журнале?
Как устроена система
AES-256-GCM работает в детерминированном режиме. Каждый идентификатор пациента всегда преобразуется в один и тот же токен. «Patient_001» даёт один и тот же результат каждый раз. Этот токен используется на исходном этапе, через 3 месяца и при финальном анализе. Команда отслеживает каждого пациента только по токену. Реальные имена не попадают в рабочие файлы.
Разделение ключа соответствует требованиям EDPB. Исследовательская группа хранит зашифрованные данные. Хранитель данных хранит ключ в отдельной системе. Ни одна из сторон не может провести повторную идентификацию самостоятельно. Группа не может расшифровать данные. Хранитель не может связать ключи с пациентами без доступа к данным.
Когда повторный контакт одобрен, хранитель применяет ключ к указанным записям. Каждый шаг фиксируется: какие записи, когда, кто дал разрешение. Этот журнал является вашим доказательством соответствия Статье 89 GDPR.
Как это выглядит на практике
Онкологический центр ведёт когорту из 5 000 пациентов в трёх странах. Каждый участок работает только с токенами. Офицер по данным головного центра хранит ключ.
В середине исследования сканирование выявляет 47 пациентов с высоким риском. Комитет по этике одобряет повторный контакт. Офицер расшифровывает записи именно этих 47 пациентов. Медицинская команда связывается с ними. Остальные 4 953 пациента остаются скрытыми на всех трёх участках.
Ключ не перемещается. Данные остаются зашифрованными. Только 47 записей когда-либо связываются с реальными именами.
Подробнее о псевдонимизации в сравнении с полной анонимизацией читайте в нашем руководстве по обратимой деидентификации.