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

Что подтверждает валидация

Этот процесс доказывает, что построенная программная система действительно соответствует нуждам пользователей и безопасна в своей клинической среде. Применительно к медицинскому ПО речь идет о стабильности выполнения всех медицинских функций, гарантии безопасности оператора и пациента, а также о корректной обработке данных. В контексте российского стандарта ГОСТ IEC 62304-2022 «Медицинское программное обеспечение. Процессы жизненного цикла программного обеспечения» валидация становится центральным звеном, неразрывно связанным с верификацией, анализом рисков и контролем конфигураций.

Какой софт подлежит процедуре

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

Граница между валидацией и верификацией

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

Что диктует ГОСТ IEC 62304-2022

Главный российский норматив для разработчиков медПО введен в действие с 1 января 2023 года. Он не дает универсального шаблона испытаний, а описывает обязательные процессы жизненного цикла. Среди них: разработка, сопровождение, управление рисками, конфигурацией, проблемами и изменениями. Производитель сам решает, какими инструментами эти процессы реализовать, но их наличие и документирование строго обязательно.

Уровни безопасности: от A до C

Класс ПО определяется тяжестью вероятных последствий отказа, и его нельзя путать с классом риска самого медизделия.

• Класс A: Отказ не способен причинить вред здоровью.
• Класс B: Сбой может привести к некритичной травме, не угрожающей жизни.
• Класс C: Ошибка в коде способна вызвать серьезный вред или летальный исход.

Чем выше класс, тем жестче требования к документированию и глубине тестирования.

Компоненты с неизвестной родословной (SOUP)

Один из главных вызовов при валидации — программное обеспечение неизвестного происхождения, или SOUP. Это любые программные элементы, чья разработка велась без полного соблюдения процессов стандарта либо документация на которые заказчику недоступна. Сюда попадают сторонние библиотеки, опенсорсные компоненты, коммерческие модули и даже операционные системы. Чтобы держать такие элементы под контролем, нужно идентифицировать их версию, проанализировать известные уязвимости, оценить риски и провести тестирование на совместимость и безопасность.

Какими должны быть требования к ПО

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

Последовательность валидационных работ

Процесс выстраивается в логическую цепочку:

1. Фиксация назначения и области применения. Описываются пользователи, условия, медицинские функции и ожидаемые результаты.
2. Анализ требований и рисков. Проверяется полнота требований и их связь с критически важными функциями.
3. План валидации. Определяются объем проверок, методы, тестовая среда, ответственные и критерии приемки.
4. Подготовка тестовой среды. Фиксируется аппаратная конфигурация, версии ОС, библиотек и зависимостей.
5. Проведение испытаний. Проверяются основные и граничные режимы, совместимость, надежность и восстановление после сбоев.
6. Оценка результатов. Фактические показатели сопоставляются с критериями, все отклонения регистрируются.
7. Итоговый вывод. Подтверждается пригодность конкретной версии ПО для заявленного медицинского применения.

Какие виды тестирования применяются

Объем испытаний зависит от назначения, архитектуры и рисков продукта. В комплекс могут входить:

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

Информационная безопасность на всех этапах

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

Контроль версий и изменений

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

Пакет документов

Состав пакета зависит от сложности и класса безопасности. Обычно он включает:

• План валидации с описанием объекта, среды и критериев.
• Протокол с тестовыми сценариями и зафиксированными результатами.
• Отчет, обобщающий проделанную работу, отклонения и вывод о пригодности.
• Матрицу прослеживаемости, показывающую связь требований, рисков и тестов.
• Файл жизненного цикла, объединяющий все записи, подтверждающие выполнение процессов стандарта.

Что потребуется для регистрационного досье

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

Когда нужна повторная валидация

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

Типовые ошибки

Самые частые промахи: подготовка формального отчета без реальных доказательств, отсутствие внятных критериев приемки и неполная идентификация версии. Многие забывают о прослеживаемости, не контролируют SOUP-компоненты и оставляют без внимания анализ рисков и вопросы информационной безопасности.

Чек-лист готовности ПО к валидации

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