При разработке медицинского программного обеспечения (ПО) критически важно понимать разницу между Программным Обеспечением Неизвестного Происхождения (ПОНП / SOUP) и Готовым ПО (Off-the-Shelf, OTS), поскольку это влияет на процессы верификации, валидации и управления рисками. Оба типа ПО широко используются, но регуляторные требования к ним и подходы к интеграции существенно различаются. Надо отметить, что пункт 3.29 ГОСТ IEC 62304 несколько смешивает понятия ПОНП (SOUP) и Off-the-Shelf (OTS), тут необходимо пояснение. Попытаемся его дать.
1. Определения и ключевые различия
1.1. ПОНП (SOUP) — Программное Обеспечение Неизвестного Происхождения
Определение:
ПОНП (SOUP) в терминологии ГОСТ IEC 62304 — ПРОГРАММНАЯ СОСТАВНАЯ ЧАСТЬ, которая уже разработана и общедоступна, но не была предназначена для включения в состав МЕДИЦИНСКОГО ИЗДЕЛИЯ (также известное как «готовое ПО» - это не совсем правильно по нашему мнению) или ПРОГРАММНАЯ СОСТАВНАЯ ЧАСТЬ, разработанная ранее, для которой недоступны требуемые записи ПРОЦЕССОВ разработки.
То есть, это программные компоненты, для которых у разработчика нет полного контроля над их созданием, тестированием и сопровождением.
Это могут быть:
- Открытое ПО (open-source библиотеки, например, OpenSSL).
- Проприетарные библиотеки без доступа к исходному коду.
- Наследуемое ПО (legacy), разработанное третьими сторонами без должной документации.
Что характеризует ПОНП:
- Нет полной документации (например, данных проектирования и разработки, результатов тестирования, анализа рисков).
- Ограниченная поддержка (разработчик не всегда может или имеет возможность (и желание) исправлять баги в своём ПО. Почему? См. пункт выше).
- Недокументированный, неизвестный процесс разработки (нет гарантий соответствия ГОСТ IEC 62304).
1.2. OTS (Off-the-Shelf) — Готовое ПО
Определение:
OTS — это коммерческое или готовое ПО, которое поставляется в виде бинарного или исходного кода, но имеет документацию и сертификацию (например, операционные системы, СУБД, лицензированные библиотеки).
Что характеризует OTS:
- Есть документация (техническая, по безопасности).
- Поддержка вендора (обновления, исправления уязвимостей).
- Может быть сертифицировано (например, Windows для медицинских устройств).
2. Почему различие важно для медицинского ПО?
2.1. Требования регуляторов (FDA, Росздравнадзор, MDR)
Для OTS можно использовать сертифицированные версии (например, Windows CE для медицинских устройств), что снижает нагрузку на валидацию.
Для SOUP требуется дополнительный анализ рисков, так как неизвестно, как оно разрабатывалось.
2.2. Управление рисками (ГОСТ ISO 14971)
OTS обычно имеет документированные уязвимости (например, CVE для Windows), что упрощает оценку.
SOUP требует ручного анализа (например, статическое тестирование OpenSSL на уязвимости).
2.3. Верификация и валидация (ГОСТ IEC 62304)
OTS можно валидировать на основе документации производителя.
SOUP требует дополнительных тестов (например, фаззинг-тесты для open-source библиотек).
2.4. Поддержка и обновления
OTS обновляется вендором (например, патчи Microsoft для Windows).
SOUP может перестать поддерживаться (например, устаревшая версия Linux).
3. Примеры из медицинской разработки
|
Критерий |
SOUP (ПОНП) |
OTS |
|
Примеры |
OpenSSL, устаревшие драйверы |
Windows IoT, QNX, SQLite (с лицензией) |
|
Документация |
Частичная или отсутствует |
Полная (API, руководства) |
|
Анализ рисков |
Обязателен глубокий аудит кода |
Можно опираться на сертификацию |
|
Обновления |
Зависит от сообщества |
Регулярные от вендора |
|
Использование |
Требует изоляции в системе |
Может быть интегрировано напрямую |
4. Вывод: как правильно испытать и задокументировать SOUP и OTS?
Для SOUP (как минимум):
- Провести статический/динамический анализ (например, SonarQube для open-source).
- Изолировать в "песочнице" (например, запускать в контейнере Docker).
- Документировать все риски (по ГОСТ ISO 14971).
Для OTS (как минимум):
- Использовать только сертифицированные версии (например, Windows для медтехники).
- Мониторить обновления (например, подписка на бюллетени Microsoft).
- Проверять совместимость с медицинскими стандартами (например, HL7, DICOM).
Что в итоге:
SOUP требует больше ресурсов на валидацию, но часто незаменим (например, специализированные open-source библиотеки).
OTS удобнее, но может быть дорогим (лицензии) или избыточным.
Для подачи на регистрацию разница критична: неправильная классификация может привести к отказу в регистрации медицинского изделия.
