Регистрация программного обеспечения как медицинского изделия в России

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

Когда программа считается медицинским изделием

Росздравнадзор признаёт программу самостоятельным регуляторным объектом только при одновременном выполнении нескольких условий.

Три обязательных критерия

Во-первых, это отдельная программа для ЭВМ или её модуль, а не встроенная часть другого аппаратного продукта — такой софт называют SaMD, software as a medical device. Во-вторых, разработчик прямо заявляет клиническое назначение. И в-третьих — это ключевой критерий — результат работы программы заключается в автоматической интерпретации данных, влияющей на решение врача: постановку диагноза, выбор тактики, оценку риска. Сюда же относят системы поддержки принятия врачебных решений — СППВР.

Что не подпадает под регулирование

Не признают таким объектом информационные системы для учёта и планирования, фитнес-приложения со счётчиками шагов и калорий, программы управления оборудованием. Регулятор прямо оговаривает: расчёт по формуле, перевод единиц измерения или сигнализация отклонений интерпретацией не считаются. Приложение для записи на приём статус не получит, а сервис, который по снимкам формирует диагностическое заключение, — почти наверняка да.

Чем оформление ПО отличается от оборудования

После квалификации нужно определить класс потенциального риска — от этого зависит объём испытаний и требований к досье.

Классы риска для софта

Классы те же, что и для остальной продукции: 1, 2а, 2б и 3. Для софта класс определяют по двум признакам: какие данные он обрабатывает (нужны ли по ним немедленные действия) и в каких условиях применяется — от экстренной помощи до плановой. Отдельно стоит запомнить правило: продукту с технологиями искусственного интеллекта всегда присваивают третий, самый высокий класс — независимо от того, с каким оборудованием он используется.

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

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

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

Спецтребования для ПО с искусственным интеллектом

Регистрация медицинского ПО опирается на общие правила для остальной продукции, но с 1 сентября 2025 года требования к технической документации детализирует приказ Минздрава № 181н — он заменил прежний приказ 2017 года и впервые выделил отдельный раздел именно для программного обеспечения.

Общие требования к документации на софт

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

Что дополнительно требуют от ИИ-решений

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

Какие документы нужны для медицинского ПО

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

В заявлении дополнительно указывают, относится ли продукт к решениям с ИИ и есть ли у него функция автопередачи данных регулятору. Систему менеджмента качества по ГОСТ ISO 13485 выстраивают ещё до подачи документов. Для класса 2б и 3 — а значит, для всех решений с ИИ — потребуется инспектирование производства: его проводят только ВНИИИМТ и Национальный институт качества.

Сроки и особенности процедуры

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

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

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

Часто задаваемые вопросы

Нужно ли оформлять мобильное приложение-трекер здоровья?

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

Нужно ли что-то оформлять при выходе новой версии ПО?

Зависит от сути изменений. Если меняется только нумерация версии и это не влияет на функциональное назначение, для решений с ИИ работает упрощённый порядок: заявление через личный кабинет на Госуслугах рассматривают за 5 рабочих дней. Условие — у программы должна быть встроенная функция автопередачи данных регулятору. Переработка же диагностического алгоритма считается существенным изменением и потребует стандартной процедуры с экспертизой.

Распространяются ли эти требования на облачные сервисы?

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

Что обязан делать разработчик после регистрации?

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

Можно ли подать одно досье сразу на несколько версий или модулей программы?

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