Профильный стандарт МЭК на программное обеспечение медицинских изделий описывает управляемый жизненный цикл ПО: от планирования и анализа требований до сопровождения и вывода из эксплуатации. Он разбивает работу на 5 групп процессов и вводит 3 класса безопасности (A, B, C) в зависимости от возможного вреда пациенту. Требования к глубине документации в 2026 году растут вместе с классом: чем выше риск, тем строже проверки и записи.
Что описывает стандарт МЭК на жизненный цикл медицинского ПО
Стандарт МЭК на программное обеспечение медицинских изделий — это международный документ, который задаёт требования не к конкретному коду, а к процессам его создания и поддержки. Его логика проста: безопасность медицинского ПО нельзя «протестировать в конце», её нужно выстраивать на каждом этапе жизненного цикла.
Жизненный цикл программного обеспечения — это вся цепочка состояний продукта: планирование, разработка, выпуск, эксплуатация и снятие с поддержки. Стандарт требует, чтобы каждый шаг был спланирован, задокументирован и прослеживаем, то есть чтобы любое требование можно было проследить до кода и до испытаний.
Документ применяется к ПО, которое само является медицинским изделием (Software as a Medical Device), и к встроенному программному обеспечению внутри приборов. Он не заменяет систему менеджмента качества и управление рисками, а работает вместе с ними как часть единого набора требований.
Как определить класс безопасности программного обеспечения?
Стандарт вводит 3 класса безопасности ПО, и от класса зависит объём обязательных процессов и документации. Класс присваивается по тяжести возможного вреда для пациента или оператора, если программа сработает неправильно.
Класс A — ситуация, когда травма или вред пациенту невозможны. Класс B — возможна нетяжёлая травма. Класс C — возможна тяжёлая травма или смерть. Чем выше класс, тем больше этапов детального проектирования, интеграционного тестирования и верификации становятся обязательными.
Классификация проводится с учётом мер снижения риска: если внешние механизмы (аппаратная защита, контроль оператора) убирают опасность, программный компонент может получить более низкий класс. Это решение обязательно фиксируется в файле управления рисками, а не принимается интуитивно.
Из каких процессов состоит жизненный цикл ПО
Стандарт группирует работу в несколько ключевых процессов разработки. Процесс планирования задаёт, как будет создаваться ПО, какие стандарты кодирования применяются и как обеспечивается прослеживаемость. Анализ требований к программному обеспечению превращает потребности изделия в проверяемые технические требования.
Далее идут архитектурное проектирование (разбиение системы на программные единицы), детальное проектирование, написание кода и верификация каждой единицы. Интеграция и интеграционное тестирование проверяют, что модули работают вместе, а системное тестирование ПО подтверждает соответствие исходным требованиям.
Кроме процессов разработки, стандарт описывает поддерживающие процессы: управление конфигурацией (контроль версий и изменений), управление проблемами (регистрация и устранение дефектов) и процесс сопровождения после выпуска. Именно поддерживающие процессы часто недооценивают, хотя ошибки в ПО могут обнаруживаться спустя месяцы эксплуатации.
Как стандарт связан с управлением рисками и СМК
Стандарт на жизненный цикл ПО не существует отдельно. Он опирается на управление рисками медицинских изделий по стандарту 14971: класс безопасности программного обеспечения определяется именно через анализ рисков, а меры контроля риска отражаются в требованиях к ПО.
Процессы разработки встраиваются в систему менеджмента качества по стандарту 13485. Это значит, что записи о планировании, верификации и изменениях ПО должны храниться и управляться по правилам СМК, а не в произвольных файлах разработчиков.
Для комплекта регистрационной документации важна и маркировка, включая символы по стандарту 15223, и общие принципы качества по 9001, если организация их применяет. Все эти документы вместе формируют доказательную базу безопасности и эффективности изделия.
Частое заблуждение: «класс A можно не документировать»
Почему низкий класс не освобождает от процессов
Распространённое заблуждение звучит так: если ПО отнесено к классу A, документировать почти ничего не нужно. На практике даже для класса A обязательными остаются планирование разработки, анализ требований, управление конфигурацией и управление проблемами. Стандарт снимает часть требований к детальному проектированию и интеграционному тестированию, но не отменяет прослеживаемость и записи.
Второй миф — что класс безопасности назначает сам разработчик «на глаз». В действительности класс должен вытекать из анализа рисков и быть обоснованным: если меры снижения риска не доказаны, программный компонент по умолчанию тяготеет к более высокому классу. Занижение класса без обоснования — типичная причина замечаний при экспертизе.
Третий упускаемый нюанс — сторонние компоненты (SOUP, software of unknown provenance): готовые библиотеки и ОС тоже входят в жизненный цикл. Для них нужно задокументировать назначение, известные дефекты и требования, иначе цепочка прослеживаемости рвётся, даже если собственный код написан идеально.
Что учесть при подготовке к регистрации в 2026 году
Для вывода медицинского ПО на рынок документы по жизненному циклу становятся частью регистрационного досье. Проверяющие смотрят не только на итоговый продукт, но и на то, как выстроены процессы: есть ли план разработки, файл рисков, записи о верификации и управлении изменениями.
Полезно заранее согласовать номенклатурную принадлежность изделия и понять, требуются ли клинические или технические испытания. Программные изделия для диагностики in vitro и телемедицинские сервисы имеют свою специфику требований к валидации и данным.
Чем раньше процессы жизненного цикла оформлены по стандарту, тем меньше доработок потребуется на этапе экспертизы. Восстановить прослеживаемость задним числом сложнее и дольше, чем вести записи с самого начала проекта.
| Класс | Возможный вред | Ключевые обязательные процессы |
|---|---|---|
| A | Травма невозможна | Планирование, анализ требований, управление конфигурацией и проблемами |
| B | Возможна нетяжёлая травма | Дополнительно архитектурное и детальное проектирование, интеграционное тестирование |
| C | Возможна тяжёлая травма или смерть | Полный набор процессов с максимальной глубиной верификации и документации |
Разбираетесь в требованиях к медицинскому ПО перед выходом на рынок — посмотрите порядок регистрации медицинских изделий и подготовки документации.
Подробнее об услугеОпубликовано 2026-09-14, обновлено 2026-09-14
Частые вопросы
Обязателен ли стандарт МЭК на жизненный цикл ПО в России?
Стандарт применяется как признанный ориентир при подтверждении безопасности программного обеспечения медицинских изделий. Его требования удобно использовать как основу доказательной базы для регистрационного досье, а гармонизированные версии учитываются экспертами при оценке.
Чем класс безопасности ПО отличается от класса риска изделия?
Класс риска медицинского изделия относится ко всему продукту и определяет порядок регистрации. Класс безопасности ПО (A, B, C) описывает возможный вред именно от программного компонента и задаёт объём процессов разработки. Это разные, но связанные классификации.
Нужно ли документировать сторонние библиотеки и ОС?
Да. Готовые компоненты неизвестного происхождения входят в жизненный цикл ПО: для них фиксируют назначение, требования и известные дефекты. Без этого нарушается прослеживаемость и появляется слабое место в доказательстве безопасности.
Заменяет ли этот стандарт управление рисками?
Нет. Стандарт на жизненный цикл ПО опирается на управление рисками по стандарту 14971: класс безопасности программного обеспечения определяется через анализ рисков, а меры контроля отражаются в требованиях к ПО.
Что входит в процессы сопровождения ПО?
Сопровождение включает мониторинг дефектов после выпуска, оценку их влияния, выпуск исправлений и управление изменениями версий. Эти поддерживающие процессы обязательны для всех классов, потому что ошибки нередко проявляются в эксплуатации.
С чего начать внедрение процессов жизненного цикла?
Начинают с плана разработки, анализа требований и присвоения класса безопасности на основе рисков. Параллельно настраивают управление конфигурацией и проблемами, чтобы прослеживаемость велась с первого дня, а не восстанавливалась перед экспертизой.