Сертификация ПО для медтехники: как пройти Росздравнадзор в 2026 (2026-03-20 17:00:49) | Блог ГК ЖУР

Если вы разрабатываете программное обеспечение для медицины, то рано или поздно столкнетесь с необходимостью прохождения государственной регистрации. В России этот процесс курирует Росздравнадзор, и с 2023 года он претерпел значительные изменения из-за перехода на новые регламенты Евразийского экономического союза (ЕАЭС). Сегодня, в 2026 году, система устоялась, но ее сложность по-прежнему отпугивает многих стартаперов и даже опытных IT-команд. Давайте разберемся не в теории, а в практических шагах и подводных камнях, которые ждут вас на пути к законному внедрению вашего продукта в клиниках.

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

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

После классификации начинается этап подготовки технической документации. Это не просто описание функций программы. Вам потребуется создать пакет документов, который убедит экспертов в безопасности и эффективности продукта.

• Техническое описание с детальной архитектурой
• Руководство по эксплуатации (инструкция)
• Отчеты о проведенных технических испытаниях (функциональность, нагрузочное тестирование)
• Отчет об оценке соответствия требованиям кибербезопасности (защита персональных данных пациентов)
• Клинические данные (для классов риска 2а и выше)

Именно последний пункт становится камнем преткновения для инновационных решений. Если ваше ПО является новым типом диагностического средства или использует алгоритмы машинного обучения для анализа данных, будьте готовы к планированию локальных клинических испытаний. Это долго (от полугода) и дорого. Альтернативой может стать предоставление данных иностранных исследований или публикаций в рецензируемых журналах, но их придется адаптировать под требования российского законодательства.

Следующий шаг — выбор схемы оценки соответствия и подача заявления. Для ПО классов 1 и 2а чаще всего применяется схема декларирования соответствия на основании собственных доказательств производителя. Вы сами проводите испытания по утвержденным методикам и несете ответственность за достоверность данных.

Для классов риска 2б и 3 обязательна сертификация с привлечением аккредитованной лаборатории для проведения независимых испытаний образца вашего ПО.

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

После подачи пакета документов начинается экспертиза Росздравнадзора. Сроки формально составляют до 50 рабочих дней для декларации и до 70 дней для сертификации, но на практике почти всегда возникают запросы на устранение замечаний (так называемые «доработки»). Эксперты могут запросить дополнительные пояснения по архитектуре безопасности, алгоритмам или клиническим данным.

• Предоставление сырых логов тестирования вместо структурированных отчетов
• Неполное описание процедур обновления ПО и отката к предыдущим версиям
• Отсутствие четкого описания границ ответственности: что делает программа автоматически, а где решение остается за врачом

Успешное прохождение экспертизы завершается внесением вашего программного обеспечения в государственный реестр медицинских изделий Росздравнадзора. Вы получаете регистрационное удостоверение — главный документ, дающий право на законный оборот продукта на территории ЕАЭС.

Но история на этом не заканчивается. После выхода продукта на рынок начинается этап постмаркетингового надзора. Вы обязаны отслеживать все инциденты при использовании вашего ПО медработниками, вести их учет и периодически отчитываться перед регулятором о безопасности изделия.

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