Досье на медицинское программное обеспечение строится по той же логике, что и на аппаратное изделие, но с рядом специфичных разделов. К стандартному составу добавляются описание архитектуры и версии ПО, документы жизненного цикла разработки (по подходам IEC 62304), результаты верификации и валидации, кибербезопасность и управление рисками с учётом ошибочных выводов программы. Класс потенциального риска (от 1 до 3) определяет глубину проработки этих разделов. Ключевое отличие от «железа» — в досье описывают не физический продукт, а поведение алгоритма и процессы, которые гарантируют его стабильность.
Когда ПО регистрируется как медизделие
Программное обеспечение подлежит регистрации как медицинское изделие, если ему присвоено медицинское назначение — диагностика, мониторинг, расчёты, влияющие на лечение. Оно может быть встроенным (управляет аппаратом) или самостоятельным (работает на обычном устройстве, например ПО как медицинское изделие). От этого зависит, регистрируется ли ПО отдельно или в составе аппаратного изделия.
Определить это нужно до сбора документов, потому что состав досье и объём испытаний напрямую зависят от статуса и класса риска. Общие принципы отбора документов удобно сверять с материалом про регистрацию программного обеспечения медизделия.
Что берётся из общего состава досье
Базовая часть досье на ПО совпадает с досье на любое медизделие: сведения о производителе, назначение и описание изделия, техническая документация, результаты испытаний, эксплуатационная документация (инструкция), документы системы менеджмента качества. Эта общая рамка описана в материале про состав регистрационного досье.
Отличие в том, чем наполняются эти разделы. Там, где для аппаратного изделия приводят чертежи и данные о материалах, для ПО описывают архитектуру, программные модули, требования к среде выполнения и интерфейсы. «Техническая документация» для программы — это прежде всего описание того, как она устроена и как проверяется.
Документы, специфичные для ПО
Именно эти разделы отличают досье на программу от досье на «железо»:
Жизненный цикл разработки. Документы, показывающие, что ПО разрабатывалось по управляемому процессу: планирование, требования, проектирование, реализация, тестирование, сопровождение. Ориентир — подходы стандарта IEC 62304, привязанные к классу безопасности ПО.
Верификация и валидация. Доказательства того, что программа соответствует требованиям (верификация) и решает медицинскую задачу в реальных условиях (валидация). Сюда входят протоколы тестирования и их результаты.
Управление рисками. Для ПО анализируют не только технические сбои, но и риски неверных выводов и их клинические последствия — по методологии менеджмента риска.
Кибербезопасность и защита данных. Описание мер защиты от несанкционированного доступа и нарушения целостности данных, что критично для медицинских программ.
Управление версиями. Идентификация версии, для которой подаётся досье, и порядок обращения с обновлениями.
Главная ловушка: версия и обновления
Самый частый источник проблем с досье на ПО — рассинхронизация между зарегистрированной и фактической версией. В отличие от аппаратного изделия, программа обновляется часто, и легко оказаться в ситуации, когда на рынке работает версия, отличная от той, что описана в досье.
Чтобы этого избежать, в досье с самого начала фиксируют конкретную версию и заранее описывают политику обновлений: какие изменения считаются несущественными (интерфейс, быстродействие) и не затрагивают медицинские характеристики, а какие требуют внесения изменений в регистрационные документы. Чётко проведённая граница между этими типами обновлений экономит время и снимает значительную часть замечаний при экспертизе.
Практический вывод: описывать нужно не только текущее состояние программы, но и процесс, которым производитель управляет её изменениями. Именно наличие управляемого процесса, а не разовый снимок кода, убеждает экспертизу в том, что изделие остаётся под контролем на всём жизненном цикле.
Как готовить досье на ПО без ошибок
Разумный порядок — начинать с назначения и класса риска, затем выстраивать документы жизненного цикла и только потом собирать доказательную часть (верификация, валидация, риски). Такой порядок исключает ситуацию, когда испытания проведены, а требования к ним нигде формально не зафиксированы.
Полезно заранее свериться с типовым перечнем документов, чтобы не упустить обязательные разделы — об этом материал про перечень документов для регистрации медизделия. Для программных продуктов особенно важно, чтобы разделы были связаны между собой: требования — с тестами, риски — с мерами снижения, версия — с политикой обновлений.
| Раздел | Аппаратное изделие | Программное обеспечение |
|---|---|---|
| Техническое описание | Чертежи, материалы | Архитектура, модули, среда выполнения |
| Жизненный цикл | Производственные процессы | Разработка ПО по IEC 62304 |
| Испытания | Технические, при необходимости иные | Верификация и валидация ПО |
| Безопасность | Электро-, механическая | Кибербезопасность, защита данных |
| Идентификация | Модель, партия | Версия и политика обновлений |
Готовите регистрационное досье на медицинское ПО? Поможем собрать состав документов с учётом жизненного цикла и версий.
Опубликовано 2026-09-21, обновлено 2026-09-21
Частые вопросы
Чем досье на ПО отличается от досье на аппаратное изделие?
Базовая структура совпадает, но наполнение разное: вместо чертежей и материалов описывают архитектуру, модули и среду выполнения, добавляют документы жизненного цикла разработки, верификацию и валидацию, кибербезопасность и управление версиями.
Какие документы специфичны именно для ПО?
Документы жизненного цикла разработки (по подходам IEC 62304), протоколы верификации и валидации, управление рисками с учётом ошибочных выводов, меры кибербезопасности и защиты данных, а также идентификация версии и политика обновлений.
Нужно ли фиксировать версию ПО в досье?
Да. В досье фиксируют конкретную версию, для которой оно подаётся, и заранее описывают, какие обновления несущественны, а какие требуют внесения изменений в регистрационные документы. Это снимает значительную часть замечаний.
Что такое верификация и валидация ПО?
Верификация подтверждает, что программа соответствует заданным требованиям, а валидация — что она решает медицинскую задачу в реальных условиях. И то, и другое оформляется протоколами тестирования с результатами.
Как класс риска влияет на досье на ПО?
Класс потенциального риска (от 1 до 3) определяет глубину проработки разделов: чем выше класс, тем больше требований к жизненному циклу, испытаниям и управлению рисками программного обеспечения.
С чего начинать подготовку досье на ПО?
С назначения и класса риска, затем документы жизненного цикла и только потом доказательная часть — верификация, валидация, риски. Такой порядок исключает ситуацию, когда испытания проведены, а требования к ним формально не зафиксированы.