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

Разработчики и дистрибьюторы цифровых медицинских решений часто сталкиваются с отказами в регистрации из-за неправильно оформленных отчетов о проверке софта. Корректно выполненная валидация устраняет риск срыва сроков при выходе на рынок, исключает финансовые потери бизнеса от простоя готового ИТ-продукта.

Валидация программного обеспечения (ПО) представляет собой сбор объективных доказательств того, что конкретный софт соответствует нуждам пользователей, выполняет свое целевое назначение в реальных условиях эксплуатации. Иначе говоря, этот процесс отвечает на вопрос: «Создано ли именно то изделие, которое необходимо врачу или пациенту?».

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

По номенклатурной классификации, утвержденной Приказом Минздрава России от 06.06.2012 № 4н, а также правилам Решения Коллегии ЕЭК от 22.12.2015 № 173 (в редакции Решения № 18/2025), софт разделяют по классам потенциального риска (от класса 1 до класса 3). Дополнительно применяется стандарт ГОСТ Р МЭК 62304-2022, разделяющий софт по уровням серьезности вреда на классы А, B, C.

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

• Самостоятельные программные продукты (SaMD) — мобильные приложения для мониторинга показателей здоровья, экспертные ИИ-системы анализа томограмм и рентгеновских снимков.
• Встроенное программное обеспечение (Embedded) — микропрограммы, управляющие блоками дефибрилляторов, аппаратов ИВЛ или инфузионных насосов.
• Программные модули крупных лабораторных комплексов, отвечающие за обработку результатов анализов in vitro.

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

Российская регуляторная система опирается на комплекс государственных стандартов. Базовым документом выступает ГОСТ Р МЭК 62304-2022, регламентирующий процессы жизненного цикла программного обеспечения медицинских изделий. Стандарт вводит жесткие требования к документированию каждого шага разработки.

Смежным важным актом является ГОСТ ISO 14971-2021, предписывающий ведение сквозного менеджмента риска для ИТ-продуктов. В рамках национальной регистрации по Постановлению Правительства РФ от 30.11.2024 № 1684 (в актуальной редакции ППРФ № 2214 от 30.12.2025) эксперты ведомства проверяют полноту выполнения стандартов. Разработчику необходимо сформировать файл жизненного цикла софта и предоставить его в составе регистрационного досье.

В глобальной практике ключевыми ориентирами служат стандарты ISO 13485, IEC 62304, а также методологии американского регулятора FDA (General Principles of Software Validation). На российском рынке эти документы оказывают прямое влияние на методики испытаний, однако имеют юридические ограничения.

Использовать прямые ссылки на международные стандарты (IEC, ISO) или руководства FDA в регистрационных документах НЕДОПУСТИМО. Если эти документы не гармонизированы в РФ в виде действующих национальных ГОСТ, они не имеют юридической силы для Росздравнадзора.

Для успешного прохождения процедур производители переводят внутренние процессы на релевантные отечественные аналоги — ГОСТ ISO 13485-2017 и ГОСТ Р МЭК 62304-2022.

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

До начала активных проверок группа экспертов формирует План валидации (Validation Plan). Этот документ определяет границы исследования, ресурсы, графики и критерии приемки ИТ-продукта. Специфика конкретного медицинского изделия влияет на глубину планирования: чем выше класс риска софта, тем жестче критерии оценки.

Типичная структура валидационного плана включает разделы:

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

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

Инженеры задействуют специализированный инструментарий:

• Программы для статического анализа кода, выявляющие уязвимости и несоответствия правилам безопасного программирования до запуска софта.
• Инструменты динамического анализа, контролирующие распределение памяти и быстродействие системы.
• Профессиональные ИТ-платформы управления требованиями и ведения корпоративных систем фиксации и контроля задач, обеспечивающих сквозную трассируемость от ТЗ до конкретного теста.

Все результаты проверок фиксируются в итоговом валидационном отчете (Validation Report), который входит в обязательный пакет документов для регулятора.

Распространенный промах — проведение процедуры силами самих разработчиков кода. Отсутствие независимой оценки со стороны аккредитованной лаборатории ведет к пропуску скрытых дефектов и гарантированному отказу Росздравнадзора в выдаче регистрационного удостоверения (РУ).

Второй проблемой становится халатное отношение к прослеживаемости требований. Если в финальном отчете нет четкой связи между исходным техническим заданием, анализом рисков, протоколом финального тестирования, регулятор вернет досье на доработку. При взаимодействии с экспертами ведомства необходимо предоставлять структурированные, логически выверенные файлы, оформленные строго по ГОСТ Р МЭК 62304-2022. Практический опыт подтверждает: привлечение профильных экспертов на этапе проектирования сокращает общее время регистрационных процедур на 4–6 месяцев.

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

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

Валидация программного обеспечения медицинского назначения — это не формальное требование законодательства, а базовый инструмент защиты инвестиций в ИТ-продукт. Профессиональное проведение испытаний на ранних стадиях разработки отсекает архитектурные ошибки, оптимизирует затраты на программирование и гарантирует беспрепятственное прохождение экспертизы в Росздравнадзоре.