Протокол повторного контакту IRB: посібник з оборотного шифрування
IRB тепер вимагають не лише плану деідентифікації. Їм також потрібен план повторного контакту. Ви повинні довести дві речі. По-перше, сторонні не можуть отримати доступ до реальних імен пацієнтів. По-друге, ваша команда може — коли дозвіл комітету з етики це дозволяє.
Це двостороннє правило виникло з реального досвіду. Тривалі дослідження виявляли термінові результати в середині випробування. Але записи були заблоковані. Шляху назад не існувало. Це блокувало медичну допомогу пацієнтам. Регулятори звернули увагу.
Дивіться, як ми підтримуємо це в нашому огляді відповідності та практиках безпеки.
Чому IRB потрібні двосторонні двері
Штрафи за GDPR зросли на 56% у 2024 році (Щорічний звіт DLA Piper 2025). Стаття 89 GDPR відповідає на цю тенденцію. Вона вимагає псевдонімізації — а не повного видалення — для дослідницьких даних. Правило визнає, що дослідження іноді потребують шляху назад до реального запису.
Стаття у NEJM AI 2024 року вивчала деідентифікацію на основі великих мовних моделей. Вона виявила основну проблему. Очищені клінічні нотатки залишаються пов'язаними з особою пацієнта через ті самі клінічні закономірності, що роблять їх корисними. У статті зазначено: використовуйте псевдонімізацію з задокументованим планом управління ключами. Це зберігає шлях для повторного контакту.
Ваш IRB повинен бачити обидва боки цих дверей. Хто може здійснити повторну ідентифікацію? За яких умов? Хто зберігає ключ? Що протоколюється?
Як працює налаштування
AES-256-GCM працює у детермінованому режимі. Кожен ідентифікатор пацієнта завжди перетворюється на той самий токен. «Patient_001» дає однаковий результат щоразу. Цей токен з'являється на початковому рівні, через 3 місяці та при фінальному огляді. Команда відстежує кожного пацієнта лише за токеном. Жодні реальні імена не потрапляють у робочі файли.
Розподіл ключів відповідає правилу EDPB. Дослідницька команда зберігає зашифровані дані. Куратор даних зберігає ключ в окремій системі. Жодна зі сторін не може самостійно здійснити повторну ідентифікацію. Команда не може розшифрувати. Куратор не може пов'язати ключі з пацієнтами без даних.
Коли повторний контакт схвалено, куратор застосовує ключ до визначених записів. Кожен крок протоколюється: які записи, коли, хто дав дозвіл. Цей журнал є вашим доказом відповідності Статті 89 GDPR.
Як це виглядає на практиці
Онкологічний центр проводить когорту з 5000 пацієнтів у трьох країнах. Кожен майданчик працює лише з токенами. Офіцер з даних провідного центру зберігає ключ.
В середині дослідження сканування виявляє 47 пацієнтів з підвищеним ризиком. Комітет з етики схвалює повторний контакт. Офіцер розшифровує ці 47 записів. Медична команда зв'язується з цими 47 пацієнтами. Решта 4953 залишаються прихованими на всіх трьох майданчиках.
Ключ не переміщується. Дані залишаються зашифрованими. Лише ці 47 записів коли-небудь пов'язуються з реальними іменами.
Для отримання додаткової інформації про псевдонімізацію на відміну від повної анонімізації, перегляньте наш посібник зі зворотньої деідентифікації.