Пилоты, клиническая валидация и развёртывание

Это инженерные рекомендации, а не юридическая консультация. Детали подтверждайте у профильных юристов.

Кратко

Когда телемед-продукт прошёл тесты, самое трудное только начинается. Деплой – дело техники; сложнее доказать, что продукт работает на реальных пациентах, и приучить к нему врачей. Здесь часто смешивают три разные задачи: пилот (небольшой контролируемый первый запуск с реальными пользователями), клиническую валидацию (доказательства того, что продукт даёт заявленный клинический результат) и развёртывание (поэтапное расширение от нескольких клиник до всех). У каждой свои правила. Пилот с реальными пациентами не освобождает от 152-ФЗ, врачебной тайны и приказа Минздрава 193н. Пилот, который собирает доказательства для регистрации ПО как медизделия, – это клинические испытания по ПП 1684: разрешение Росздравнадзора на них для ПО не требуется (п. 31 «в»), а вот программа и доказательная база нужны. А пилот того, что общие правила запрещают, возможен только в экспериментальном правовом режиме (ПП 1164) и только для его участников. В статье – как спроектировать пилот, где проходят регуляторные границы и как разворачивать продукт кольцами, чтобы проблема затронула десять пациентов, а не десять тысяч.

Зачем это читать

Большинство телемед-продуктов проваливаются не на разработке, а между «работает в демо» и «врачи каждый день пользуются им на реальных пациентах». Статья – для основателя, продакт-менеджера или клинического лида, у которого есть протестированный продукт и задача вывести его к пациентам без инцидента безопасности, без утечки и без того, чтобы врачи молча от него отказались. Пройденный правильно, этот этап превращает рабочую сборку в продукт, за который клиника, страховщик или пациент продолжат платить. Цена ошибки вполне конкретна. Это пилот без заранее заданных критериев, который «удался» по общему мнению и развалился при масштабировании. Это пилот, в котором данные пациентов уходили подрядчику без поручения оператора, а закончилось всё утечкой и уведомлением Роскомнадзора. Или хороший продукт, который врачи молча обходят, потому что он добавил два клика к их рабочему дню.

Технический запуск – самая простая часть

Выкатить софт – решённая задача. У вас есть протестированная сборка (см. тестирование клинического видео), пайплайн деплоя и мониторинг (см. наблюдаемость и эксплуатацию). Залить это на продакшен-серверы – рутина.

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

Нажмите, чтобы увеличить

Дадим точные определения: на этом различии строится вся статья.

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

Клиническая валидация – доказательства того, что продукт достигает заявленного клинического результата для пациентов, которым он предназначен. Для простой видеоконсультации валидация может быть лёгкой: подтвердить, что консультации завершаются и врач может работать. Для продукта, который что-либо измеряет, оценивает или интерпретирует, валидация становится формальным требованием к доказательствам, а за границей, о которой речь пойдёт ниже, ещё и регуляторным.

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

Сравним их:

Дизайн пилота: решите, что такое «успех», до старта

Самая частая ошибка – запустить пилот, не записав заранее, что будет считаться успехом, а что провалом. Пилот без заданных критериев не может провалиться: любой исход задним числом объявят победой, а значит, он ничему и не научит. Поэтому первый результат работы над пилотом – не код, а одностраничное определение успеха.

Метрики удобно раскладывать по четырём областям. Доступ: получают ли помощь те, кто раньше не мог, например жители районов без нужного специалиста? Эффективность: каковы клинические исходы, безопасность, своевременность помощи? Для консультаций «врач – врач» норматив своевременности уже задан приказом 193н: экстренная консультация – от 30 минут до 2 часов, неотложная – от 3 до 24 часов (п. 19). Опыт: отвечает ли продукт потребностям пациентов и врачей? Экономика: сколько стоит консультация и кто за неё платит? Для модели с оплатой по ОМС сравните себестоимость с нормативами программы госгарантий на 2026 год: в среднем 379,9 ₽ за консультацию «врач – врач» и 336,3 ₽ за «врач – пациент» (ПП 2188; конкретный тариф задаёт тарифное соглашение субъекта). Метрика в каждой области не обязательна, но пилот, который измеряет только «технически заработало», проверяет то, что вы уже протестировали.

Например, пилот видеоконсультаций может поставить такие цели: доля завершённых консультаций выше 90%, меньше одного обращения в поддержку на десять консультаций, время работы врача в пределах 10% от очного приёма и оценка опыта пациента выше порога. Каждая цель – число, согласованное с клиническими руководителями до первого пациента. Важны не конкретные значения, а то, что они записаны до старта.

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

Быстрая прикидка: каким должен быть размер пилота?

Размер пилота определяют по опыту, но простая арифметика не даёт обмануть себя. Допустим, вы хотите поймать любую проблему, которая затрагивает хотя бы 5% консультаций, например баг доступа к камере на одном семействе устройств. Вероятность, что одна консультация её не заденет, – 95%, или 0,95. На n независимых консультациях вероятность ни разу её не увидеть – 0,95 в степени n. Чтобы с вероятностью около 95% увидеть её хотя бы раз, решаем 0,95^n ≤ 0,05, что даёт n ≈ 59. Округлите вверх и проведите минимум 60–100 завершённых консультаций, прежде чем доверять выводу «крупных проблем нет» для проблемы с частотой 5%. Для более редких проблем, с частотой 1%, та же формула даёт около 300. Это прикидка, а не расчёт мощности клинического исследования, но она не позволит выдать двухнедельный пилот из двенадцати консультаций за доказательство.

Юридическая развилка: внедрение, испытание или эксперимент?

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

Пилот внедрения. Цель – проверить, работает ли продукт в конкретной клинике по действующим правилам. Отдельного разрешения не нужно: клиника оказывает помощь по своей лицензии (телемедицина – только по работам и услугам, включённым в лицензию, п. 4 193н), а продукт – её инструмент. Но весь порядок 193н действует с первого пациента: идентификация через ЕСИА (п. 7), врачи в ФРМР и организация в ФРМО (п. 9), раскрытие информации пациенту на сайте или в приложении (п. 37). И главное: без очного приёма диагноз дистанционно не ставится, заключение может содержать только рекомендации по обследованию перед очным приёмом (п. 40). Пилот, построенный на «первичном онлайн-приёме с диагнозом», нарушает порядок, сколько бы пациентов в нём ни было.

Клинические испытания медизделия. Если цель пилота – доказать, что ПО даёт клинический результат, чтобы зарегистрировать его как медизделие, это клинические испытания в процедуре регистрации по ПП 1684. Для ПО-медизделий разрешение Росздравнадзора на клинические испытания не требуется (п. 31 «в»), но испытания остаются формальной процедурой с программой и оформленными результатами, которые войдут в регистрационное досье. Для ИИ-ПО анализа рентгеновских снимков, КТ и маммографии предусмотрен ускоренный порядок регистрации (п. 101–109) с испытаниями на базе московского центра (п. 24).

Экспериментальный правовой режим. Если пилоту нужно то, что общие правила запрещают, путь один – ЭПР по ПП 1164. Его участники (28 частных медорганизаций, среди них Медси, «Доктор рядом», РЖД-Медицина, ЕМЦ) могут проводить консультации у другого врача той же клиники после очного приёма, выписывать электронные рецепты, оформлять информированное добровольное согласие с электронной подписью и применять альтернативную идентификацию – по данным мобильного оператора или банковскому идентификатору. Ограничения жёсткие: нельзя консультировать детей, при инфекционных заболеваниях, в экстренной и неотложной форме, а финансирование из ОМС в рамках ЭПР запрещено (ч. 2.1 ст. 36.2 323-ФЗ). Режим установлен на три года с 1 августа 2023 года; сведений о его продлении после августа 2026 года в открытых источниках на момент подготовки статьи нет – проверьте статус до планирования. Минэкономразвития в 2025 году признало ЭПР успешным, но законопроекта, разрешающего ставить диагноз дистанционно, нет.

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

Нажмите, чтобы увеличить

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

Пилот не освобождает от комплаенса

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

Как только пилот касается реальных данных пациента – сведений о здоровье, которые по 152-ФЗ относятся к специальной категории (ст. 10), а по 323-ФЗ составляют врачебную тайну начиная с самого факта обращения (ст. 13), – действуют все требования. Исключения для пилота нет. Нужны модель угроз, уровень защищённости по ПП 1119, меры по приказу ФСТЭК № 21 и оценка их эффективности до ввода системы в эксплуатацию (ст. 19 ч. 2 п. 4 152-ФЗ). Шифрование, контроль доступа, журнал событий и хранение данных в России (ст. 18 ч. 5) должны работать с первого дня пилота, а не появляться перед масштабированием. Если платформа обрабатывает данные о здоровье не как медорганизация, нужно письменное согласие пациента, с 1 сентября 2025 года – оформленное отдельным документом (ст. 9).

С договорами то же самое. Каждый подрядчик, который получит доступ к медданным в пилоте (видеоплатформа, облако, сервис транскрибации, аналитика или краш-репортинг), должен работать по поручению оператора (ст. 6 ч. 3 152-ФЗ): с перечнем данных и действий, целями, требованиями к защите и обязанностью сообщать об инцидентах. Поручение подписывают до старта. Частая и дорогая ошибка – подключить удобный трекер ошибок, «просто чтобы присмотреть за пилотом». Если он зарубежный, идентификаторы пациентов оказываются в зарубежной базе, что прямо запрещено (штраф до 6 млн ₽), а утечка данных о здоровье стоит юрлицу 10–15 млн ₽ – неважно, было в пилоте десять пациентов или десять тысяч. Механика разобрана в статье поручение обработки ПДн и договоры с подрядчиками; здесь главное, что поручения оформляют до пилота, а не перед запуском.

Снизить риск пилота можно, сокращая объём данных, а не меры защиты. Если на вопросы пилота можно ответить обезличенными или агрегированными данными (доли завершения, объём поддержки, тайминги), собирайте только их, а персональные данные держите внутри того же защищённого контура, что и продакшен. Меньше данных – меньше риск; отказ от мер защиты риск лишь маскирует.

Клиническая валидация: от «запускается» к «работает» и граница медизделия

Для простой видеоконсультации клиническая валидация – в основном работа пилота: консультации завершаются, врач может оценить состояние и принять решение, исходы не хуже очных. Но как только продукт измеряет, оценивает или интерпретирует что-то клиническое – считывает показатель с прибора, помечает пациента как высокорискового, предлагает уровень срочности, – «запускается» и «работает» становятся разными утверждениями, а валидация – формальной процедурой.

Самая понятная схема – документ Международного форума регуляторов медицинских изделий (IMDRF) о клинической оценке ПО как медизделия: три вопроса в строгом порядке. Первый – клиническая связь: есть ли обоснованная, признанная связь между выводом ПО и клиническим состоянием, о котором он говорит? Второй – аналитическая валидация: корректно и надёжно ли ПО превращает входные данные в верные выходные, то есть считает ли оно то, что заявляет? Третий – клиническая валидация: когда врач использует этот вывод в реальной помощи, достигается ли нужный результат для нужных пациентов? Продукт может пройти второй шаг и провалить третий: оценку можно вычислить идеально и всё равно не улучшить ни одного решения. Масштаб аналитической проверки в России хорошо показывает московский эксперимент по компьютерному зрению в лучевой диагностике: более 200 алгоритмов протестированы на более чем 10 млн исследований из 74 регионов.

Нажмите, чтобы увеличить

Регуляторную границу определяет интерпретация. По ст. 38 323-ФЗ медизделием может быть и специальное программное обеспечение, предназначенное производителем для диагностики, лечения или мониторинга. Такое ПО регистрируют по ПП 1684; класс риска определяют по приказу Минздрава 4н от 06.06.2012, и ПО с ИИ там всегда относится к классу 3 (п. 15.1.1). В телемедицине граница записана прямо: 193н допускает системы поддержки принятия врачебных решений на базе ИИ, только если они зарегистрированы как медизделия (п. 15–17). Регистрация по национальным правилам доступна до 31 декабря 2027 года, дальше действуют правила ЕАЭС. Путь уже проторён: на август 2026 года, по данным Росздравнадзора, в России зарегистрировано 59 отечественных медизделий с ИИ.

За этой границей обычный QA превращается в формальную документированную верификацию и валидацию, обычно по международному стандарту жизненного цикла медицинского ПО IEC 62304, где каждое требование прослеживается до доказательства его выполнения. Дороже всего обнаружить границу, когда функция уже построена и прошла пилот. Если хоть одна функция пилота смещается к интерпретации клинических данных, получите регуляторное заключение до пилота: переделывать продукт под валидацию уровня медизделия после обычной разработки – одна из самых дорогих переделок в медтехе. Тот же вопрос применительно к клиническому ИИ разобран в статье слой комплаенса и безопасности клинического ИИ.

Клиническая оценка не заканчивается на запуске. Реальную работу продукта нужно отслеживать постоянно: модель или процесс, прошедшие валидацию в пилоте, могут «дрейфовать», когда меняются пациенты и условия. Изменения в зарегистрированное ИИ-ПО вносятся в особом порядке (п. 112–136 ПП 1684), а обязательный пострегистрационный мониторинг ИИ-медизделий с автоматической передачей данных в Росздравнадзор обсуждается между ведомствами – на октябрь 2026 года он не принят. Постоянный мониторинг – задача эксплуатации, поэтому валидация и наблюдаемость тесно связаны.

Онбординг врачей и управление изменениями: где продукты на самом деле проваливаются

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

Общие модели управления изменениями (ADKAR, восемь шагов Коттера) сходятся в главном: люди принимают изменение, когда понимают, зачем оно нужно, видят, что оно работает у уважаемого коллеги, обучены на своём реальном процессе и получают поддержку, когда что-то ломается.

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

Поэтапное развёртывание: расширяйтесь кольцами, с путём назад

Когда пилот выполнил критерии, продукт не включают сразу для всех. Его расширяют кольцами – концентрическими этапами, каждый больше предыдущего, с контрольной точкой перед следующим. Типичная последовательность: внутренние пользователи и персонал, затем пилотная когорта, затем ограниченный релиз на часть клиник или процент трафика, затем общий доступ. Технически это канареечный релиз, и его поддерживают стандартные инструменты, например Argo Rollouts для Kubernetes с автоматическим откатом. На каждом кольце вы смотрите те же метрики, что задал пилот, плюс операционные (долю успешных звонков, частоту ошибок, нагрузку на поддержку) и переходите к следующему кольцу, только если они в норме.

Нажмите, чтобы увеличить

Смысл колец прост: проскользнувшая проблема затронет ограниченное число пациентов, а не всю аудиторию. К каждому кольцу привяжите план отката – проверенный, отрепетированный способ быстро выключить новую версию и вернуться к предыдущей (или к очной помощи). В потребительском приложении плохой релиз – досадная неприятность; в телемедицине путь отката – мера безопасности пациента, и он должен быть готов до открытия кольца, а не придумываться на ходу во время инцидента.

Две проверки, специфичные для телемедицины, относятся именно к развёртыванию, а не к этапу после него. Первая – путь к оплате: прежде чем наращивать объём, подтвердите, что за реальные консультации в кольцах действительно приходят деньги. По ОМС отдельные тарифы на телемедицину устанавливаются в тарифных соглашениях субъектов, консультацию «врач – врач» оплачивает запросившая медорганизация, а дистанционное наблюдение при артериальной гипертензии и сахарном диабете входит в базовую программу (ПП 2188). Тарифы различаются по регионам, поэтому новое кольцо в новом регионе требует новой проверки. Платные консультации с 1 сентября 2026 года идут по правилам ПП 659, которые прямо разрешают дистанционный договор на сайте или в приложении, а онлайн-оплата требует чека по 54-ФЗ; ДМС – по договору со страховщиком. Подробнее – в статье оплата телемедицины: ОМС, ДМС, платные услуги.

Вторая проверка – лицензия и регистры. Лицензии «по регионам» в России нет: лицензия на медицинскую деятельность действует на всей территории страны. Но телемедицина оказывается только по работам и услугам, включённым в лицензию (п. 4 193н). Поэтому кольцо с новой специальностью или новой клиникой-партнёром означает проверку лицензии, записей врачей в ФРМР и организации в ФРМО и подключения к ЕГИСЗ: передача сведений в ЕГИСЗ входит в лицензионные требования (п. 6 «е» ПП 852). Проверять это нужно в плане развёртывания, а не узнавать после запуска.

Частая ошибка: «успешный» пилот, подстроенный под успех

Типичный провал этого этапа – пилот, спроектированный, обычно неосознанно, под успех: сотрудники-энтузиасты, хорошие сети, новые устройства, никаких заранее заданных критериев и аудитория, ничем не похожая на реальную. Он даёт восторженные отзывы, команда объявляет победу и масштабирует продукт на всех. И тогда продукт впервые встречает реальных пользователей на полном объёме в худший момент: с багом доступа к камере, неудобным процессом и пациентами, которые не могут завершить консультацию. Пилот, который не может провалиться, ничего не показывает: его ценность в том, чтобы выявлять проблемы, пока их исправление ещё дёшево. Проектируйте пилот так, чтобы находить проблемы, а не подтверждать уже принятое решение, и считайте найденную в пилоте проблему его результатом, а не провалом.

Где здесь Фора Софт

Фора Софт разрабатывает софт для видео реального времени с 2005 года, в том числе телемедицинские платформы. Переход от протестированной сборки к реальным пациентам – как раз тот этап, где виден опыт профильной команды: настроить сбор метрик так, чтобы важные данные шли с первой консультации, сохранить защиту медданных в пилоте, а не достраивать её потом, и развернуть продукт кольцами с мониторингом и путём отката. Поскольку речь о здравоохранении, регуляторные вопросы – границу между пилотом внедрения, клиническими испытаниями и ЭПР, границу медизделия, поручения обработки, которые должны быть подписаны до первого пациента, – мы считаем частью плана развёртывания, а не формальностью на потом. Мы также работаем с видеоконференциями, стримингом, e-learning и видеонаблюдением, так что отказы живого видео при расширении колец для нас привычная задача, а не сюрприз в неделю запуска.

Главное

• Технический запуск – самая простая часть; проваливаются продукты на пилотах, валидации и принятии врачами.
• Пилот, клиническая валидация и развёртывание – три разные задачи с разными правилами.
• Запишите критерии успеха до первого пациента и проводите пилот на трудных пользователях.
• Цель пилота определяет режим: внедрение по 193н, клинические испытания медизделия по ПП 1684 или ЭПР по ПП 1164; диагноз без очного приёма вне ЭПР не ставится.
• Пилот с реальными пациентами не освобождает от 152-ФЗ и врачебной тайны: меры защиты и поручения подрядчикам нужны до первого пациента.
• Разворачивайте кольцами с контролем и путём отката; проверяйте оплату и лицензию на каждом новом кольце.

Что читать дальше

• Тестирование клинического видео: QA на надёжность и комплаенс – тесты, которые нужно пройти до старта пилота.
• Наблюдаемость и эксплуатация живой телемед-платформы – как отслеживать метрики, на которые опирается каждое кольцо.
• Чек-лист запуска телемед-платформы – итоговый чек-лист, по которому сверяют развёртывание.