От онлайн-записи добровольца до журнала идентификации субъектов: система набора участников клинических исследований

Доброволец записывается на исследование сам — через сайт или мобильное приложение. Система находит его в базе, подтверждает номер телефона кодом из СМС и отказывает, если с прошлого исследования не прошло сто восемьдесят дней. Всё это происходит до того, как заявку увидит живой человек. Дальше участник живёт в системе: интервью, скрининг, включение в проект, договор, выплаты, журнал идентификации субъектов. А само исследование система ведёт по шаблону — от написания протокола до финального отчёта, задача за задачей. Мы строим и развиваем её третий год.

Отрасль: организация клинических исследований и пользовательских тестирований лекарственных препаратов Задача: автоматизировать набор участников исследований и ведение самих исследований Старт: февраль 2023 Сегодня: система в промышленной эксплуатации, развитие продолжается Роль Nabla Lab: проектирование, разработка, развитие Хостинг: на стороне заказчика

Вторая половина клинического исследования

О клинических исследованиях обычно говорят как о сборе данных: визиты, измерения, формы, статистика. Но перед этим есть половина работы, о которой не пишут в статьях.

Добровольцев надо где-то найти. Обзвонить. Провести интервью. Проверить, подходят ли они по критериям. Убедиться, что человек не участвовал в другом исследовании неделю назад. Записать на визит в свободный кабинет к свободному интервьюеру. Оформить договор и выплату. И по каждому участнику вести документы, которые потребует проверяющий.

В большинстве организаций это живёт в таблицах, телефонных звонках и голове конкретного координатора. Пока исследований два, работает. Когда их двадцать, а добровольцев тысячи, начинаются дубли в базах, потерянные согласия, участник, записанный в два исследования одновременно, и невозможность быстро ответить на вопрос «покажите, откуда взялся этот человек».

Наш заказчик решил закрыть эту половину системой. Мы её построили.

Правила работают до того, как включается человек

Публичная часть — это форма записи, доступная любому желающему.

Человек вводит имя и телефон, система проверяет его по базе. Если он там уже есть, на телефон приходит код подтверждения, и после ввода кода участник видит собственную историю: в каких тестированиях участвовал, когда, в каком формате.

Здесь срабатывает главное правило. Между участием в исследованиях должно пройти не меньше ста восьмидесяти дней — это ограничение существует ради безопасности самого добровольца и ради достоверности данных. Система считает срок сама и либо объясняет человеку, что записаться пока нельзя, либо открывает календарь свободного времени.

Разница с ручным процессом принципиальная. При обзвоне это правило проверяет координатор — по памяти, по таблице, иногда никак. В системе оно проверяется всегда и до того, как заявка попадёт в работу. Сотрудник не тратит время на человека, которого всё равно придётся отсеять.

Новый участник заполняет анкету, выбирает формат и клинический центр, подтверждает телефон и даёт согласие на обработку персональных данных. Заявка уходит сотрудникам уже проверенной.

Мобильное приложение

Тот же путь мы собрали в мобильном приложении и опубликовали в Google Play, RuStore и GetApps. Проверка по базе, подтверждение телефона, расписание, запись, согласия — всё то же самое, но в телефоне.

Для набора участников это важнее, чем кажется: аудитория добровольцев моложе и мобильнее, чем аудитория среднего медицинского сервиса, и путь «увидел объявление — установил приложение — записался» короче, чем через браузер.

От отклика до субъекта исследования

Внутри системы участник проходит через несколько состояний, и у каждого своё название, потому что в этой отрасли слова означают разное.

Заявка — то, что человек отправил сам. С ней работает интервьюер: связывается, отмечает результат разговора, фиксирует отклик.

Респондент — человек в общей базе. О нём известно, откуда пришёл, кто и когда с ним говорил, согласен ли на звонки от клинического центра.

Пациент — участник, привязанный к конкретному проекту исследования. Здесь появляются категория здоровья, анамнез, анализы, флюорография, статусы готовности и согласия, график занятости, форма договора.

Базы респондентов и пациентов связаны и синхронизируются: данные, уточнённые на интервью, доходят до карточки участника в проекте, и наоборот. Это одна из тех вещей, которые в таблицах не воспроизводятся никогда.

Отдельно система ведёт классификацию надёжности: участвует, участвует редко, не участвует, выходит из исследований досрочно. Координатор видит это до звонка и не тратит два дня на человека, который трижды не пришёл.

Откуда приходят люди

В системе шестнадцать источников привлечения — от группы во «ВКонтакте» и телеграм-канала до рекламы на бортах автобусов, конференций, рекомендаций знакомых и медицинских представительств.

Это не справочник ради справочника. Набор добровольцев стоит денег, и организация должна понимать, какой канал приносит людей, которые действительно доходят до исследования, а какой — заявки, отваливающиеся на первом звонке. Система даёт для этого статистику.

Документы, которые спросит проверяющий

Клинические исследования проверяют, и проверяют по документам.

Система формирует журнал идентификации субъектов исследования — регламентированный документ, связывающий участника с его кодом в исследовании. Мы реализовали его по внутреннему стандарту заказчика, с выгрузкой.

Экспорты сделаны для всех основных сущностей: участники, проекты, клинические центры, кабинеты, города, компании, журналы. Данные не заперты внутри системы — их можно выгрузить в том виде, в каком их запросят.

Исследование как последовательность работ

Клиническое исследование — это не один проект с датой начала и датой конца. Это десятки работ в строгом порядке: написать протокол, отрецензировать его дважды, набрать участников, провести визиты, собрать данные, написать отчёт, отрецензировать и его. Часть работ нельзя начинать, пока не закончена предыдущая, и это не пожелание, а требование регламента.

В системе этим управляет отдельный механизм.

Типовое исследование описывается шаблоном один раз. В шаблоне задаётся последовательность работ, а для каждой — порядок, срок в днях от старта проекта, исполнители, наблюдатели и чек-лист того, что должно быть сделано внутри.

Новый проект разворачивается из шаблона. Менеджер создаёт исследование, и система сама выстраивает план: задачи в нужном порядке, с рассчитанными датами, с назначенными людьми и готовыми чек-листами. Ничего не нужно вспоминать и переносить руками из прошлого проекта.

Задачи не идут вне очереди. У шаблона задачи есть признак «не начинать, пока не закрыта предыдущая». Отчёт нельзя писать раньше, чем закончено рецензирование протокола, — система этого не даст.

Статус исследования — следствие работы, а не отметка руководителя. Закрытие определённых задач автоматически переводит проект в следующий статус. Никто не выставляет «в работе» и «завершено» вручную, поэтому в списке проектов видно фактическое положение дел, а не то, что кто-то забыл обновить.

Исполнители и наблюдатели разведены. Наблюдатель видит ход работы и получает уведомления, но не отвечает за неё. Для рецензентов, мониторов и руководителей это ровно то, что нужно.

Сверху — диаграмма Ганта, автоматическая пометка просроченного, комментарии и вложения внутри каждой задачи. Напоминания рассылает фоновая служба: о приближении срока, о незакрытых пунктах чек-листа, о завершении задачи. Уведомления идут по почте и в Telegram, с журналом отправленного.

Получается не список дел, а регламент, оформленный в работающий механизм. Разница проявляется на второй год эксплуатации: новый сотрудник ведёт исследование правильно не потому, что его хорошо обучили, а потому что система ведёт его по шагам.

Внутренняя кухня организации

Помимо ведения исследований система забрала часть работы всей компании.

Планирование интервью. Кабинеты со своим рабочим временем, графики интервьюеров, расписание. Система знает, кто когда свободен и какой кабинет занят.

Собственная служба поддержки. Внутри системы работает свой сервис заявок: категории, статусы, переписка, вложения, назначение ответственных, статистика. Сотрудники сообщают о проблемах там же, где работают.

Учёт участников. Форма договора с добровольцем — гражданско-правовой договор или самозанятость — учитывается в системе, потому что от неё зависит порядок выплаты.

Кадровые изменения. Когда сотрудник увольняется, система убирает его из рассылок, из автоматического назначения на проекты и из списков выбора, не удаляя историю его работы. Мелочь, из-за которой в обычных системах годами приходят письма уволившимся людям.

Прослеживаемость и права

Каждое значимое действие в системе фиксируется. Технически это устроено так же, как в других наших системах для регулируемых сфер: почти у каждого объекта есть парная теневая таблица, в которой хранятся снимки состояния, а запись о действии связывает старое состояние с новым и указывает, кто и когда его изменил.

Журнал операций отделён от остального: полные права администратора не дают права его редактировать. История системы не должна зависеть от того, у кого сейчас самая высокая роль.

Права выстроены в несколько уровней: роль, доступ по подразделению, отдельные признаки доступа, персональные разрешения вроде права видеть все проекты. В организации, где над одним исследованием работают интервьюеры, менеджеры, авторы и рецензенты документов и бухгалтерия, «десять ролей» — это не избыточность, а необходимый минимум.

Из мер защиты: вход по токенам с ограниченным временем сессии, капча после двух неудачных попыток входа, разграничение доступа на уровне операций.

Три года и тринадцать этапов

Работа началась в феврале 2023 года с системы управления пользовательским тестированием и продолжается до сих пор. За это время подписано тринадцать спецификаций — от первоначальной разработки до отдельных доработок в 2026 году.

Так выглядит живой продукт: сначала базовый контур, потом мобильное приложение, потом подсистема под исследования третьей фазы, потом внутренняя CRM, потом регламентные журналы. Каждый следующий этап заказчик формулировал, уже поработав с предыдущим.

Отдельно стоит сказать про то, чего в этом списке много: исправления и уточнения формулировок. Переименовать фильтр, поменять текст статуса, изменить значение по умолчанию. Мы делаем это так же аккуратно, как крупные блоки, потому что в системе, где сотрудник проводит восемь часов в день, неудачная подпись поля стоит дороже, чем отсутствующая функция.

Как устроено внутри

Дальше — техническая сторона.

Серверная часть на .NET, интерфейс на ASP.NET MVC, данные в реляционной СУБД. Решение разделено на десять проектов: веб-слой, модели, слой данных, миграции, сервисы, конфигураторы, планировщик фоновых задач, почтовый сервис и набор внутренних библиотек.

Функциональные области разведены по отдельным разделам приложения: тестирования, исследования, CRM, бухгалтерия, аудит, поддержка, системные настройки, служебный API. Каждый раздел живёт своей жизнью и не мешает соседям.

Фоновые задачи выполняет планировщик: напоминания по проектам и задачам, контроль сроков, отслеживание чек-листов, плановые рассылки. Уведомления идут по почте и в Telegram — с журналом отправленного, чтобы можно было ответить на вопрос, ушло письмо или нет.

Не единственная система для этого заказчика

Работа с этим заказчиком не ограничилась одной системой. Позже мы построили для него электронную систему сбора данных клинических исследований — она закрывает то, что происходит с участником уже внутри исследования: визиты, измерения, формы, контроль качества данных, регламентная прослеживаемость.

Вместе эти две системы покрывают процесс целиком: от объявления, по которому пришёл доброволец, до данных, которые уходят в регуляторное досье на препарат.

Заказчик возвращался к нам не один раз за три с лишним года. При выборе подрядчика это значит больше, чем любой перечень функций.

Почему это важно для вас

Этот проект — про долгую дистанцию. Систему невозможно построить за один заход: заказчик сам не знает заранее, что ему понадобится через год, потому что процессы меняются вместе с бизнесом. Три года и тринадцать согласованных этапов — это не признак незаконченности, а нормальный жизненный цикл системы, которой пользуются каждый день.

Мы умеем работать в таком режиме: разбираться в отраслевой специфике, переводить регламентные требования в работающие механизмы и оставаться с продуктом годами. И умеем строить системы для сфер, где важно не только «работает», но и «можно показать проверяющему».

Расскажите о своей задаче — обсудим, как её решить.