Сертификация ПО для медтехники: как пройти Росздравнадзор в 2026

Если вы разрабатываете программное обеспечение для медицины, то общая тема «сертификация ПО» для вас сводится к одному, но крайне сложному вопросу: как легально вывести свой продукт на российский рынок в 2026 году. После серии изменений в законодательстве, пик которых пришелся на 2024-2025 годы, процесс регистрации медицинских изделий, куда теперь однозначно отнесено и большинство медицинских программ, стал напоминать прохождение минного поля. Неверный шаг — и вы теряете полгода-год и несколько миллионов рублей. Давайте забудем про общие слова и разберем конкретный узкий аспект: алгоритм первичной регистрации программного обеспечения как медицинского изделия (ПОМИ) через Росздравнадзор с учетом актуальных на март 2026 года требований.

Главная ошибка стартапов и даже опытных IT-компаний — начинать думать о сертификации после того, как продукт готов. В реалиях 2026 года это фатально. Первый и ключевой этап должен стартовать еще на стадии проектирования архитектуры — это классификация вашего будущего ПОМИ. От этого зависит не только объем необходимых документов, но и сама возможность регистрации по упрощенной процедуре. Согласно правилам Евразийского экономического союза (ЕАЭС), которые в России действуют в полной мере, класс риска определяется исходя из предполагаемого воздействия ПО на здоровье пациента.

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

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

После определения класса начинается этап «доказательной базы». Это не про маркетинговые фразы, а про техническую документацию, которую будут изучать эксперты ФГБУ «ВНИИИМТ» Росздравнадзора — главного экспертного центра. Центральный документ здесь — техническое описание (ТО). В отличие от описания для пользователя, ТО должно содержать глубокие технические детали.

• Детальное описание всех алгоритмов принятия решений с указанием математических моделей или ссылок на клинически подтвержденные методики.
• Полное описание архитектуры: схемы взаимодействия модулей, используемые библиотеки (с указанием версий и лицензий), API.
• Требования к системному окружению: операционные системы (вплоть до сборки), версии фреймворков, требования к железу.
• Исчерпывающее руководство по установке и настройке.
• План мероприятий по обеспечению безопасности информации (особенно критично для облачных решений).

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

Когда пакет документов собран (заявление о регистрации, ТО, отчет о клинических испытаниях/исследованиях технических характеристик для класса 1, инструкция по применению), он подается в Росздравнадзор. С марта 2025 года подача осуществляется исключительно в электронной форме через личный кабинет на портале госуслуг с усиленной квалифицированной электронной подписью. Сроки рассмотрения формально составляют до 50 рабочих дней для классов 1-2а и до 70 дней для классов 2б-3, но на практике из - за высокой загрузки экспертов они часто сдвигаются.

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

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

Заключение... Таким образом путь сертификации медицинского ПО в России превратился из формальности в стройный хотя и крайне ресурсоемкий процесс который является неотъемлемой частью разработки Успех зависит от раннего вовлечения регуляторных специалистов скрупулезной подготовки доказательной базы и готовности к длительному диалогу с экспертными органами В конечном счете это инвестиция не только в легальность но и в качество продукта которое проходит самую жесткую проверку