Что такое Trialeco — менее чем за две минуты и по модулям

Протокол клинического исследования может занимать сотни страниц. В разных разделах находятся условия участия, процедуры, сроки и требования к центру. Protocol Guard проектируется, чтобы собрать эти элементы в понятную рабочую карту и сохранить источник каждого правила. В открытом демо можно использовать только публичный или синтетический протокол без данных пациентов и закрытой информации. Модуль учитывает номер версии, приложения и таблицы. Конфиденциальный документ спонсора нельзя загружать без отдельного защищённого процесса и права на обработку. Система предлагает карточки критериев включения и исключения, процедур, окон визитов и требований к площадке. Рядом остаются раздел, страница, таблица и версия источника. Это важно: специалист видит не только вывод, но и место, которое нужно проверить в оригинале. Например, в тестовом протоколе визит назначен на пятнадцатый день с окном плюс-минус два дня. Рабочая карта показывает интервал с тринадцатого по семнадцатый день. Если таблица процедур содержит другое окно, система не выбирает сама: она показывает противоречие и создаёт вопрос эксперту. Медицинский эксперт проверяет клинический смысл. Биостатистик — конечные точки и данные. Специалист по нормативным требованиям — применимые правила. Главный исследователь оценивает возможность работы центра. Специалист по качеству проверяет процесс. Protocol Guard никого из них не заменяет и не утверждает протокол. После проверки отдельные правила можно передать в Recruit для предварительного сопоставления, в Comms для подготовки напоминаний и в Site Status для оценки данных центра. Следующий шаг для самого модуля — тестирование на эталонных наборах с измерением пропусков, искажений и критичных ошибок.

Recruit — проектируемый модуль для предварительного сопоставления правил исследования с разрешёнными данными о возможном участнике. Он показывает три понятных статуса: совпало, не совпало или данных пока недостаточно. Это не решение о включении в исследование. В рабочем контуре сведения могут поступать из медицинской информационной системы, анкеты предварительного отбора, направления врача или разрешённой выгрузки. Для каждого источника нужны правовое основание, минимально необходимый состав данных и контроль доступа. В открытом демо используются только синтетические профили. Для каждого критерия модуль сопоставляет подтверждённое правило из Protocol Guard с доступным фактом. Рядом показывает обоснование и источник. Если дата, анализ или формулировка неоднозначны, статус остаётся неизвестным. Отсутствие сведений не считается ни соответствием, ни несоответствием. В синтетическом примере возраст участника соответствует правилу восемнадцать плюс. Но дата предыдущей терапии не подтверждена. Recruit отмечает первый пункт как предварительное совпадение, второй — как недостаток данных. Итоговый скрининг продолжается только по решению исследователя. Модуль не ставит диагноз, не определяет окончательную пригодность и не включает человека в исследование. Исследователь проверяет актуальный протокол, исходную медицинскую документацию и все обязательные процедуры. Информированное согласие остаётся отдельным человеческим процессом. Перед пилотом команда создаёт экспертный эталон и заранее задаёт метрики. Проверяются пропуски критериев, неверные отрицания, единицы измерения, даты и доля неизвестных данных. Критичная ошибка должна останавливать сценарий и передавать случай специалисту, а не скрываться красивым итоговым баллом.

Comms — проектируемый модуль коммуникации на этапах предварительного отбора, скрининга и визитов. Он помогает подготовить понятное сообщение, напоминание или вопрос. Канал, текст, время и получатель задаются утверждённым сценарием, а не свободным решением искусственного интеллекта. Comms получает только проверенные элементы расписания. Команда центра указывает фактическую дату и ответственного. Модуль может подготовить напоминание о визите или перечне организационных шагов. Медицинские назначения и индивидуальные рекомендации формирует только уполномоченный специалист. Для обычного организационного вопроса используется согласованный шаблон. Если сообщение выходит за его границы, содержит симптом, жалобу или неоднозначность, Comms сохраняет контекст и передаёт вопрос ответственному человеку. Система не должна придумывать медицинский ответ. Сообщение о симптоме создаёт технический сигнал. Оно само по себе не определяет нежелательное явление, серьёзность, причинную связь или ожидаемость. Врач оценивает клиническую ситуацию. Уполномоченная команда безопасности спонсора выполняет документирование и отчётность по установленной процедуре. Для каждого сценария заранее проверяются согласие на канал связи, допустимое время, версия шаблона, журнал действий и резервный путь. Автоматическая отправка возможна только для явно утверждённых неклинических сообщений. При сбое или риске сценарий блокируется и передаётся человеку. Польза Comms — не в замене общения врача и участника. Модуль помогает не потерять вопрос, связать его с визитом или правилом, назначить владельца и показать срок ответа. Эффект проверяется в ограниченном пилоте по полноте передачи сложных вопросов, ошибкам маршрута и понятности сообщений.

Готовность исследовательского центра нельзя описать одной цифрой. Site Status проектируется как карточка данных для оценки команды, ресурсов, документов, опыта и текущей нагрузки. Модуль не выбирает центр и не обещает скорость набора без отдельно проверенной методики. Центр заполняет фактические сведения: состав и обучение команды, доступность оборудования и лаборатории, локальные процедуры, договорные этапы, конкурирующие исследования и планируемую нагрузку. У каждого поля есть владелец, источник, дата и статус проверки. Protocol Guard передаёт подтверждённые требования конкретного протокола. Site Status сопоставляет их с фактами центра и показывает возможный разрыв: например, нет подтверждения обучения, не указана мощность морозильника или пересекается нагрузка команды. Это вопрос для проверки, а не автоматический отказ. Центр подтверждает свои данные. Контрактная исследовательская организация проводит оценку и квалификацию только в пределах письменно переданных функций. Спонсор сохраняет надзор и принимает документированное решение о выборе центра и правилах процесса. Дашборд показывает не абстрактный балл, а состояния отдельных полей: подтверждено, требует уточнения, просрочено или не применимо. Пользователь может открыть источник и увидеть, кто и когда проверил запись. Прогноз набора допускается только после отдельной валидации данных и модели. В пилоте Site Status сравнивается с документированной оценкой специалистов. Измеряются пропущенные требования, устаревшие сведения, ложные сигналы и время на уточнение. Если данных недостаточно, система должна честно показать неопределённость, а не маскировать её зелёным индикатором.

Trialeco Core проектируется как интеграционный слой. Он связывает события из модулей, правила процесса и назначенные роли. Его задача — не принять клиническое решение, а показать, что произошло, кому принадлежит следующий шаг и какое подтверждение требуется. Событие содержит источник, версию и время. Например, Protocol Guard обнаружил изменение окна визита, Recruit отметил недостаток данных, Comms получил сложный вопрос, а Site Status показал просроченное подтверждение. Core не меняет смысл события и не скрывает исходный контекст. Для каждого маршрута заранее задаются роли: кто выполняет задачу, кто несёт ответственность, кого консультируют и кого информируют. Письменная передача функции должна быть видна. Если владелец или полномочие не определены, переход блокируется и передаётся администратору процесса. Нужен ли отдельный Оркестратор поверх Core, пока проверяется. В целевом сценарии он может предложить следующую задачу по утверждённому правилу. Но он не должен создавать лишний слой, дублировать координатора или самостоятельно выбирать медицинский, этический или регуляторный путь. Core должен показывать, что изменилось, кто выполнил действие, на основании какого правила и кто подтвердил переход. В публичном демо это проектная история действий и версий. Она не заменяет валидированный журнал рабочей системы, электронную подпись или первичную запись исследования. Core полезен, если снижает число потерянных задач, ошибочных маршрутов и неясных передач специалистам, не увеличивая риск. Это проверяется в пилоте сравнением с текущим процессом. Любое критичное событие остаётся под контролем назначенного специалиста.

Контур качества — сквозная проектная функция Trialeco. Он помогает собирать сигналы о возможных отклонениях, связывать их с источниками и готовить рабочие материалы для проверки. Наличие такого контура само по себе не доказывает соответствие требованиям. Сигнал может появиться из-за противоречия в протоколе, пропущенного визита, просроченного документа или сбоя коммуникации. Система сохраняет факт и контекст. Специалист по качеству определяет, является ли это отклонением, кто его расследует и какие действия нужны. Для существенной проблемы может потребоваться план корректирующих и предупреждающих действий, который специалисты называют CAPA. Модуль способен подготовить карточку и собрать материалы. Классификацию, коренную причину, действия, закрытие и оценку эффективности утверждают назначенные роли системы качества. При проектировании учитываются применимые принципы надлежащей клинической практики, требования к защите данных, компьютеризированным системам и локальные процедуры организации. Нельзя написать, что модуль соответствует всем нормам вообще. Применимость и валидация подтверждаются для конкретного назначения и пилота. До рабочего применения формулируются требования к системе, риски и проверочные сценарии. Результаты тестов связываются с требованиями. Версии модели, правил и интерфейса фиксируются. Существенное изменение проходит оценку риска, повторную проверку и управляемый выпуск. Trialeco не выдаёт заключение этического комитета, не заменяет спонсора, исследователя, аудитора или регулятора и не подтверждает соответствие. Ценность контура — в связности доказательств, прозрачных ролях и раннем обнаружении вопросов, которые должны решить люди.

Посмотрим на сквозной синтетический сценарий. Есть тестовый протокол и синтетический профиль возможного участника. Это учебный пример: он не описывает реальное исследование, препарат или человека и не используется для медицинского решения. Protocol Guard извлекает проект критериев и расписания. Для визита на пятнадцатый день он показывает окно с тринадцатого по семнадцатый. Эксперт сверяет карточки с оригиналом и подтверждает только корректные элементы. Recruit сравнивает подтверждённые правила с синтетическим профилем. Возраст предварительно совпал, но дата предыдущей терапии отсутствует. Модуль не пишет, что человек подходит. Исследователь решает, можно ли продолжить скрининг и какие данные проверить. Site Status сопоставляет требования протокола с данными тестового центра. Команда и оборудование подтверждены, а запись об обучении требует уточнения. Центр предоставляет факт. Контрактная организация оценивает в пределах переданных функций. Спонсор принимает документированное решение. После решения исследователя Comms готовит согласованное организационное сообщение и связывает его с этапом процесса. Если появляется симптом или медицинский вопрос, автоматический сценарий останавливается и передаёт контекст уполномоченному специалисту. Trialeco Core связывает события, роли и версии. Контур качества сохраняет сигнал, если правило противоречит источнику или задача просрочена. В результате команда видит единый маршрут, но каждое клинически, этически или регуляторно значимое действие остаётся за человеком.

Красивое демо показывает идею, но не доказывает готовность системы. Проверка Trialeco начинается с точного назначения каждого модуля, запрещённых сценариев и рисков. Затем создаётся эталон, с которым можно честно сравнить результат. В тестовый набор входят синтетические документы и профили с заранее известным правильным ответом. Эксперты размечают критерии, даты, единицы, противоречия и неизвестные данные. Редкие и опасные ошибки включаются намеренно, а не исключаются ради высокой средней оценки. Для извлечения измеряются точность и полнота. Отдельно считаются критичные пропуски, неверные отрицания, даты, единицы и ссылки на источник. Для сопоставления важны ложные совпадения, ложные несоответствия и случаи, где система должна была сказать, что данных недостаточно. Каждый значимый вывод сопровождается источником и объяснением. Эксперт может исправить результат и указать причину. Если документ не читается, правила конфликтуют или уверенность недостаточна, модуль должен остановиться и передать случай человеку. Версия модели, инструкция, обработчик документов и схема результата фиксируются. После существенного изменения выполняется повторная проверка на том же эталоне и новых рисковых случаях. Должны быть управляемый выпуск, возможность отката и понятный владелец решения. Пилот начинается с одного ограниченного процесса, определённых ролей и базового текущего результата. До запуска задаются пороги, критические ошибки и условия остановки. Только после сравнения качества, времени и риска можно обсуждать расширение. Такой подход превращает гипотезу в проверяемый продукт.