В мире ежегодно проводятся тысячи клинических исследований, а в России их количество может доходить до 900 в год. До внедрения в практику новые методы лечения, лекарства и медицинские изделия проходят множество испытаний под строгим контролем. Исследователям необходимо подтверждать безопасность и эффективность метода, а также соответствие самой процедуры испытаний научным стандартам и нормам этики. Эти процессы формализованы и требуют подтверждения официальными документами — но их нельзя свести к одному простому формату, особенно если дело касается этики. Поэтому только проверка пакета документации может занимать недели, а в современных условиях хочется, чтобы эта работа была менее длительной — чтобы пациенты быстрее получали доступ к новым методикам лечения.
В 2025 году команда НМИЦ онкологии им. Н.Н. Петрова вместе с Центром технологий для общества Yandex Cloud и компанией Raft запустила приложение для быстрой обработки документов клинических исследований. Решение на базе большой языковой модели Яндекса помогает специалистам научного центра классифицировать документы, проверять их оформление и содержание по чек‑листу — и это позволяет сократить цикл согласования с нескольких месяцев до 5–10 дней.
В статье вместе с коллегами из команды проекта покажем, как выстраивался пайплайн машинной обработки документов для клинических исследований, как решались сложности и ограничения, связанные с загрузкой в LLM объёмных пакетов, и к какой архитектуре решения мы пришли в итоге.
Кто и как проверяет клинические исследования
Клинические исследования — это этап разработки новых методов лечения, на котором к участию приглашаются люди. Они становятся добровольными участниками (субъектами исследования), чтобы проверить безопасность и эффективность препаратов или медицинских технологий. А это вызывает много этических сложностей и требует максимально осторожного и непредвзятого решения возникающих дилемм. В 1964 году Всемирная медицинская ассоциация разработала Хельсинкскую декларацию — свод этических принципов для проведения экспериментов c участием человека. С 1980-х годов эти принципы внедряются во всём мире.
Отслеживать соблюдение этики при проведении клинических исследований помогают этические комитеты — независимые междисциплинарные органы при исследовательских центрах. Без одобрения такого органа проведение исследования невозможно.
При Минздраве РФ также есть Совет по этике, который одобряет проведение исследований на федеральном уровне. На локальном уровне действуют этические комитеты при исследовательских центрах. Чаще всего они работают под названием локальный этический комитет (ЛЭК) и проводят экспертизу всех исследований центра, в которых приглашают принять участие людей. В России практика работы локальных этических комитетов официально закреплена с начала 2000-х годов. Сегодня в стране действует более 1800 организаций, проводящих клинические исследования лекарственных средств, — и почти каждая из них имеет собственный ЛЭК.
В каждом комитете — не менее 5 экспертов. Часть из них — это эксперты научного центра, врачи, но как минимум один из членов ЛЭК не должен быть сотрудником учреждения, а один — не должен быть специалистом в медицинской сфере. Заседания ЛЭК собираются ежемесячно. Здесь рассматриваются заявки фармацевтических компаний и медицинских организаций на инновационные разработки, создание новых методик лечения и медицинских изделий. Каждая заявка — пакет документов на сотни страниц. Внутри пакета, к примеру, могут быть:
протоколы клинических исследований, поправки к протоколам;
материалы и формы информированного согласия;
резюме исследователя;
брошюра исследователя;
обоснование целесообразности;
обращения от заявителей (например, по поводу нестандартной терапии).
Задача эксперта — проверить их на соответствие принципам этики и нормативной документации, убедиться в отсутствии внутренней противоречивости. А когда это пакет на 300–800 страниц, то проверка занимает много времени.
— После того, как пакет подан, ответственный секретарь ЛЭК просматривает документы, изучает написанное в сопроводительном письме, а затем передаёт документы выбранному эксперту. Результаты экспертизы назначенный специалист докладывает на общем заседании, где присутствуют другие эксперты и задают вопросы. Затем происходит голосование.
В среднем на одном заседании ЛЭК рассматривается от 20 до 50 заявок. Полный цикл согласования обычно занимает значительное время. Всё начинается с подачи заявки спонсором: секретарь проверяет документы, выявляет ошибки и возвращает пакет на доработку. Этот этап может повторяться несколько раз — до тех пор, пока документы не будут приведены в соответствие требованиям. Далее включается эксперт, проводит анализ, и, при необходимости, документы снова отправляются на уточнение. Только после этого заявка выносится на заседание ЛЭК, где могут быть обнаружены дополнительные замечания. Затем проводится голосование. С момента подачи до окончательного одобрения исследования может пройти более 50 дней.
Артём Полторацкий
Заведующий отделом организации доклинических и клинических исследований НМИЦ онкологии им. Н. Н. Петрова
Какие есть технические сложности, что может помочь
До сих пор большинство документов подаётся либо в бумажном виде, либо по электронной почте. Часто это:
сканы в PDF низкого качества и частично нечитаемые сканы,
не структурированные или слабо структурированные документы,
дублирующиеся файлы.
Без какой‑либо автоматизации на внимательное прочтение одного пакета документов нужны десятки часов: необходимо изучить все графики и расчёты, чтобы убедиться в безопасности людей.
Однако одновременно с этим экспертам приходится отвлекаться и на проверку соблюдения формальных требований: например, в документах часто бывает неверно оформлено информированное согласие пациентов. По статистике, около 35% заявок требуют доработки в связи с противоречивой и недостающей информацией в пакете документов, от ошибок в формулировках до неактуальных версий файлов. Если это выясняется не сразу, заявитель может потратить какое‑то время на ожидание, а потом получить отказ по формальным критериям.
Задержки в согласовании означают, что пациенты, ожидающие участия в клиническом исследовании, могут не получить жизненно важное лечение вовремя. Для фармацевтической и медицинской системы это оборачивается значительными финансовыми потерями — в среднем десятки миллионов рублей в неделю. В эту сумму входят затраты на производство, закупку, хранение препаратов и оборудования, оплату работы проектной команды и персонала, потери из‑за упущенного патентного окна, отсрочка вывода препарата на рынок, вынужденное использование устаревших схем лечения и другие издержки, включая упущенные возможности для внедрения инновационной терапии.
Благодаря автоматизации этап проверки документов на соответствие формальным критериям можно отделить от проверки на соблюдение этики исследования.
— Идея проекта возникла как ответ на реальный запрос исследовательских центров: слишком много времени уходит на рутинную работу, а последствия задержек — критичны. Мы опирались на международный опыт (например, цифровые процессы EMA и FDA по eCTD), а также на успешные кейсы цифровизации документов в других отраслях. На базе этого подхода мы разработали собственный программный прототип (Proof of Concept) и обратились с инициативой в Центр технологий для общества Yandex Cloud.
Артём Полторацкий
Заведующий отделом организации доклинических и клинических исследований НМИЦ онкологии им. Н. Н. Петрова
Центр технологий для общества Yandex Cloud занимается внедрением цифровых решений для сфер здравоохранения, образования и науки, экологии и культуры. Специалисты центра предложили архитектуру решения на базе больших языковых моделей, а также помогли найти партнёра для реализации проекта — компанию Raft, которая специализируется на AI‑решениях.
Как развивался проект
Большие языковые модели (LLM) позволяют облегчить переработку множества текстов в самых разнообразных сценариях. У команды проекта было несколько гипотез, как наиболее эффективно использовать LLM в этой задаче и повышать качество ответов, например, за счёт промтинга или методов Retrieval Augmented Generation (RAG). Специалисты склонялись к подходам без дообучения моделей, поскольку ресурсы для дообучения были ограничены. Однако окончательный выбор было сложно сделать без тестирования и проверки гипотез.
Поэтому и сам проект команда решила организовать в несколько итераций:
Прототип системы в виде веб‑приложения, куда члены комитета могут загрузить полученную заявку, проверить входной пакет документов, получить от модели список рекомендаций для исправления несоответствий, провалидировать его и затем отправить уведомления заявителям.
MVP, в котором автоматизированы и другие этапы движения документов, в том числе подача заявки самим заявителем через разработанный для него интерфейс личного кабинета. Такое решение в будущем можно тестировать и в других научно‑исследовательских центрах.
Готовый продукт для локальных этических комитетов, с единой базой заявок, возможностью обмена информацией между комитетами.
Сейчас завершён первый этап, по плану которого автоматизировали до 80% работы этического комитета по первичной проверке документов. Второй этап ещё в процессе: реализована практически вся функциональность веб‑приложения и выстроены процессы движения документов, которые ещё необходимо донастроить по результатам тестирования.
Именно на первых этапах потребовалось решить множество инженерных исследовательских и экспериментальных задач, которые определили итоговую архитектуру. Покажем подробнее наиболее интересные решения.
С чем экспериментировали
Выбор моделей и подходов, подбор промтов. Если мы имеем дело с большим объёмом данных, да ещё и на специфическую тему, то go‑to‑концепцией работы с LLM часто становится RAG — когда пользовательский запрос к модели поэтапно дополняется контекстом на основе релевантных документов:
На этапе Retrieval c помощью т. н. ретривера мы ищем и извлекаем соответствующую запросу информацию.
Augmented подразумевает, что мы дополняем полученными данными запрос пользователя.
А на этапе Generation языковая модель генерирует ответ с учётом полученной информации.
Как уже упоминали коллеги, есть несколько способов внедрить RAG, в зависимости от задачи. В нашем случае благодаря гипотезе классификации документов с помощью RAG мы смогли выполнить бизнес‑задачу наиболее быстро и показать результаты на реальных данных с самого начала проекта.
Первой моделью, с которой экспериментировала команда ещё в середине прошлого года, стала Llama 3.2 70b, в силу своей наибольшей доступности на тот момент. Одновременно с этим появлялись новые модели большой языковой модели Яндекса, и при сравнительном тестировании качества обработки текста с помощью Llama и YandexGPT 5 Pro команда решила остановиться на последней.
Эксперты НМИЦ онкологии им. Н.Н. Петрова подготовили чек‑листы для проверки соответствия требованиям к содержанию документов. Для каждого набора документов список критериев свой — всего эксперты выделили около 10 типов документов. Так, один из наиболее частых случаев проверки — это протоколы клинических исследований.
— Протоколы клинических исследований содержат большое количество критически важной информации: сведения о применяемых препаратах, данные предыдущих исследований, потенциальные риски для пациента, процедуры мониторинга безопасности и методы оценки эффективности. Каждый такой документ — это анализ по более чем 50 параметрам. Например, эксперт должен проверить, сколько крови планируется брать у пациента в течение исследования и соответствует ли это установленным нормативам. Каждая деталь имеет значение, потому что от неё зависит здоровье и безопасность участников.
Артём Полторацкий
Заведующий отделом организации доклинических и клинических исследований НМИЦ онкологии им. Н. Н. Петрова
На основе этих пунктов был подготовлен промтинг в виде чек‑листа к каждому типу документа, который подаётся для проверки содержания соответствующего файла. Одновременно с этим возникло две сложности:
Множество медицинских терминов по умолчанию сталкивались с внутренними этическими критериями модели, которая настроена не допускать спорный контент. Это решали на уровне промтинга и снижения порога этического контроля.
Объём отдельных документов был слишком большим для корректной обработки LLM. Поэтому для проверки содержания мы подаём весь документ отдельными чанками (частями), где каждый чанк соотносится с вопросами по чек‑листам.
Чанки, docling, извлечение и хранение данных. Для тестов языковых моделей использовались четыре комплекта документов общим объёмом около 2000 страниц, в каждом из которых от 9 до 15 файлов. Один пакет документов составлял 1–1,5млн токенов, поэтому его разбивали на отдельные чанки так, чтобы уместиться в контекстное окно модели.
Чанкированные данные необходимо было отправить в векторную базу для поиска и облегчения самого промта, который будет подаваться в YandexGPT. Но вскоре также возникла проблема с неоднородностью данных.
300 страниц — это документ, смешанный по типам данных, вплоть до того, что иногда встречаются подписи. Необходимо было работать с этими артефактами и понимать их связанность. Основной вызов был по работе с нечитаемыми таблицами и с объёмом этих таблиц, потому что они были разнокалиберные, шрифты постоянно менялись, количество колонок было большим. Особенно плохими были результаты на документах, которые содержали больше десяти колонок.
План работы был следующим:
Конвертация файлов pdf и docx в машиночитаемый формат json.
Затем эти данные поступали на классификацию по одному из 10 классов.
После определения класса документа он подавался пакетами и анализировался с помощью LLM на соответствие чек‑листам.
Но данные содержат не только неструктурированный текст и таблицы, но и картинки. Сейчас таблицы мы извлекаем с помощью библиотеки OCR (docling) в текстовом виде и превращаем их в структурированный материал. В будущем планируем подключить к этой задаче визуально‑текстовые модели (VLM), которые также позволят извлекать и преобразовывать данные не только из таблиц, но и из графиков.
В качестве базы для хранения данных использовали PostgreSQL: было важно, что в будущем это будет многопользовательсĸое приложение с высоĸой и часто неравномерной нагрузĸой, и потому важна масштабируемость. В скором времени планируем перейти на Serverless‑режим для автоматичесĸого масштабирования, который позволяет быстро нарастить мощности при пиковых нагрузках, а затем отключить ресурсы, когда они больше не нужны.
Веб‑разработка и пользовательские интерфейсы. В качестве основного фреймворĸа для создания веб‑приложения мы использовали Streamlit. Он позволяет быстро создавать интераĸтивные веб‑приложения на Python, объединяя фронтенд и бэкенд в одном ĸоде. У нас Streamlit используется ĸаĸ для создания пользовательсĸого интерфейса, таĸ и для реализации бизнес‑логиĸи. Это позволяет быстро разрабатывать и итерировать приложение. Мы придерживаемся компонентного подхода — повторно используемые элементы UI вынесены в отдельные ĸомпоненты. При этом ĸаждая страница приложения реализована в отдельном модуле.
Изначально для создания заявĸи мы предлагали пользователям единую одностраничную форму. Наша гипотеза была в том, чтобы не требовать от экспертов лишних кликов при работе. Но в итоге такая форма с большим количеством полей оказалась слишком сложной для восприятия, ей не хватало структуры.
В результате мы перешли на многошаговую форму с валидацией на ĸаждом шаге.
Сейчас проверĸа данных происходит перед каждым переходом ĸ следующему шагу. Мы разрешаем пользователю сохранить промежуточные результаты в черновиĸ на любом шаге, а также при необходимости вернуться ĸ предыдущим шагам.
Также было важно автоматизировать сам процесс движения документа, чтобы все участники процесса могли отслеживать статусы по заявке. Для этого отлично подходит Yandex Tracker, где можно настроить автоматизацию процесса без знаний программирования. Вместе с экспертами мы спроектировали целевой процесс прохождения заявки в нашем решении:
Схема логики в веб‑приложении продублировала логику Yandex Tracker. В дальнейшем при изменении каких‑либо этапов процесс можно будет менять самостоятельно в графическом интерфейсе.
Как выглядит итоговое решение сегодня
Архитектура. Веб‑приложение для загрузки документов хостится в Yandex Cloud. Для развёртывания бизнес‑логики обработки документов используются сервисы Compute Cloud и Yandex Managed Service for Kubernetes. Сами документы загружаются в объектное хранилище Yandex Object Storage, а данные о заявках в PostgreSQL. Перед обработкой пакета документов с помощью YandexGPT 5 происходит их предобработка и преобразование — и уже преобразованные данные поступают в PostgreSQL. Статус заявок отслеживается и в веб‑приложении, и в Yandex Tracker. Информация об изменении статуса заявок также подхватывается телеграм‑ботом, в котором можно следить за уведомлениями.
Безопасность. Все чувствительные данные обрабатываются на сервисах Yandex Cloud, которые входят в зону аттестата соответствия 152-ФЗ. Доступ к чувствительным данным ограничивается с использованием ролевой модели доступа (RBAC). Хранение секретов организовано в Yandex Lockbox.
С точки зрения пользователя. Проверка документов идёт в два этапа:
Система определяет тип документа и проверяет полноту пакета документов.
Каждый из документов проверяется по своему набору критериев.
Вся схема движения данных с учётом актуальной архитектуры выглядит так:
По итогу проверки YandexGPT генерирует список несоответствий, которые необходимо исправить в комплекте документов.
Эксперт изучает и верифицирует эти рекомендации и отправляет их заявителю в течение 1–2 дней.
Помимо списка несоответствий модель также может предлагать примеры, которые удовлетворяют всем требованиям. Например, для протокола клинического исследования LLM может предложить подходящую формулировку названия:
Примеры удовлетворенных требований по соответствию
1. Название протокола исследования
Название протокола: Двойное слепое сравнительное рандомизированное клиническое исследование I фазы по изучению фармакокинетики, безопасности и иммуногенности препарата *** в монотерапии и препарата сравнения после однократного и многократного внутривенного введения у пациенток с распространенным раком молочной железы.
Раньше только на такую первичную проверку документов могло уходить около 10 дней. Сейчас, если с документами всё в порядке, они оперативно отправляются для подготовки к заседанию ЛЭК. Полный цикл прохождения экспертизы сокращается и может занимать не более 10 дней.
Что планируется дальше
Сейчас команда готова подключать к тестированию приложения другие научно‑исследовательские центры. По результатам теста появится доработанное полноценное решение, который можно будет масштабировать на другие этические комитеты по стране.
Одновременно сэтим новым пользователям уже доступна расширенная функциональность с отдельным интерфейсом для заявителя, где можно отслеживать статус по своему пакету документа.
В перспективе решение планируется как Cloud‑Native‑сервис. Такой сервис также может быть адаптирован для работы с документами в других предметных областях: например, в юридической или финансовой сфере, где валидация документов занимает значительное время в бизнес‑процессах.
