ГОСТ Р 55544-2013/IEC/TR 80002-1:2009 Программное обеспечение медицинских изделий. Часть 1. Руководство по применению ИСО 14971 к программному обеспечению изделий

ИСО 14971 Раздел 4: АНАЛИЗ РИСКА

- Применение неправдоподобно низких значений вероятности для программных отказов, что ведет к неправдоподобно низким значениям при определении РИСКА и несоответствующим мерам по УПРАВЛЕНИЮ РИСКОМ;

- Расширение программных функций без выполнения АНАЛИЗА РИСКА для оценки того, возникли ли новые ОПАСНОСТИ или ОПАСНЫЕ СИТУАЦИИ, или причины в МЕДИЦИНСКОМ ИЗДЕЛИИ, или не нарушена ли результативность существующих мер по УПРАВЛЕНИЮ РИСКОМ (как при исходной разработке, так и после релиза в процессе технического сопровождения);

- ПРОЦЕСС АНАЛИЗА РИСКА МЕДИЦИНСКОГО ИЗДЕЛИЯ установлен только на уровне СИСТЕМЫ и аппаратной части и не включает рассмотрение связи АНАЛИЗА РИСКА с программным обеспечением и не требует отдельного рассмотрения АНОМАЛИЙ программного обеспечения как потенциальных источников ОПАСНОСТЕЙ и ОПАСНЫХ СИТУАЦИЙ;

Масштаб АНАЛИЗА РИСКА и процедуры разработки ЖИЗНЕННОГО ЦИКЛА программного обеспечения несоизмеримы с потенциальным ВРЕДОМ от МЕДИЦИНСКОГО ИЗДЕЛИЯ.

ИСО 14971 Пункт 4.1: ПРОЦЕСС АНАЛИЗА РИСКА

- ПРОЦЕСС АНАЛИЗА РИСКА определен только на уровне СИСТЕМЫ и аппаратной части. Программное обеспечение рассматривается только в случае, когда оно задействовано в мерах по УПРАВЛЕНИЮ РИСКОМ для аппаратных отказов;

- Программное обеспечение рассматривается как часть АНАЛИЗА РИСКА только на последних этапах ЖИЗНЕННОГО ЦИКЛА разработки продукции.

ИСО 14971 Пункт 4.2: Идентификация ПРЕДУСМОТРЕННОГО ПРИМЕНЕНИЯ

- Рассмотрение только подмножества пользовательских интерфейсов/потенциальных платформ для компьютерных СИСТЕМ;

- Неучет эволюции платформы или требований к установке патчей по БЕЗОПАСНОСТИ и других патчей ПОНП;

- Некорректное рассмотрение случаев применения не по назначению и ошибок пользователя, которые ведут к потенциальным ОПАСНОСТЯМ, что в результате приводит к тому, что соответствующие меры по УПРАВЛЕНИЮ РИСКОМ неидентифицированы.

ИСО 14971 Пункт 4.3: Идентификация ОПАСНОСТЕЙ

a) Применение FMEA и FTA методологий, как если бы они были бы полностью достаточны для корректного МЕНЕДЖМЕНТА РИСКА;

b) Применение FMEA и FTA методологий раздельно для аппаратной и программной частей;

c) Игнорирование целого класса ОПАСНОСТЕЙ, таких как:

1) программные ошибки, которые имеют непредсказуемые эффекты;

2) ошибки в программной логике, которая применена как мера по УПРАВЛЕНИЮ РИСКОМ для аппаратных отказов;

3) ошибки в программной логике для реализации предусмотренного применения МЕДИЦИНСКОГО ИЗДЕЛИЯ (такие как алгоритмы для вычисления результатов);

4) отказы программных платформ - операционных СИСТЕМ, библиотек, ПОНП;

5) отказы компонентов компьютера и периферийных устройств;

6) отказы интерфейсов передачи данных;

7) человеческие ошибки.

d) Проведение идентификации причин в предположении, что:

1) АНОМАЛИИ программного обеспечения будут влиять на функции только отдельных компонентов и не будут оказывать влияние на другие ПРОГРАММНЫЕ ЭЛЕМЕНТЫ или данные;

2) программное обеспечение будет работать корректно;

3) потенциальные отказы программного обеспечения слишком многочисленны и непредсказуемы для идентификации, определения или УПРАВЛЕНИЯ РИСКОМ;

4) всегда достаточно применить меры по УПРАВЛЕНИЮ РИСКОМ в начале или в конце цепи программных событий, ведущих к ОПАСНЫМ СИТУАЦИЯМ.

ИСО 14971 Пункт 4.4: Определение РИСКА

- Предположение, что концепция единичного отказа применима к разработке программного обеспечения и к последовательностям событий;

- Предположение, что тестирование, которое может быть и неполным, уменьшает вероятность определенного отказа до нуля;

- Предположение, основанное на функционале изделия, о том, что некоторые ПРОГРАММНЫЕ ЭЛЕМЕНТЫ не связаны с БЕЗОПАСНОСТЬЮ, без учета возможных неожиданных побочных эффектов;

- Задание значений ТЯЖЕСТИ ВРЕДА без достаточных клинических знаний и без привлечения тех, кто имеет представление о клинических аспектах (человеческих факторах) воздействия ОПАСНОСТЕЙ на всех потенциальных пользователей и групп пациентов;

- Задание низких значений тяжести в предположении, что врачи обнаружат отказ, или на основе неверной информации;

- Задание низких значений тяжести в предположении, что все пользователи будут следовать указаниям в маркировке МЕДИЦИНСКОГО ИЗДЕЛИЯ и в инструкции пользователя и не совершат непредвиденных ошибок;

- При задании ТЯЖЕСТИ ВРЕДА предположение о том, что запланированы определенные меры по УПРАВЛЕНИЮ РИСКОМ для ОПАСНОСТЕЙ. Если предположения ошибочны, то низкая начальная ТЯЖЕСТЬ ВРЕДА может привести к некорректному УПРАВЛЕНИЮ РИСКОМ впоследствии;

- Применение концепции потенциального ВРЕДА для пациента только для прямых ущербов без рассмотрения прочих целей применения информации, которую программное обеспечение выдает пользователю, задержек в лечении и других факторов, относящихся к результативности и основным эксплуатационным характеристикам МЕДИЦИНСКОГО ИЗДЕЛИЯ;

- Предположение о том, что врач всегда будет перепроверять информацию, выданную программным обеспечением, и сможет определить неверную информацию, использование которой приведет к тому, что событиям придается низкая ТЯЖЕСТЬ ВРЕДА, что ведет к неприменению других мер по УПРАВЛЕНИЮ РИСКОМ.

ИСО 14971 Раздел 5: ОЦЕНИВАНИЕ РИСКА

- Субъективное задание вероятности появления АНОМАЛИИ программного обеспечения для определения того, требуются ли меры по УПРАВЛЕНИЮ РИСКОМ;

- Исключение ОПАСНОСТИ из области программного обеспечения в связи с особенностями аппаратного обеспечения и при этом изменение аппаратного обеспечения впоследствии таким образом, что программное обеспечение является влияющим фактором, для которого не предусмотрены дополнительные меры по УПРАВЛЕНИЮ РИСКОМ;

- Неучет потенциальной АНОМАЛИИ программного обеспечения как фактора ОПАСНОСТИ, поскольку предполагается, что программное обеспечение будет работать правильно или тестирование выявит все АНОМАЛИИ.

ИСО 14971 Пункт 6.3: Выполнение мер по УПРАВЛЕНИЮ РИСКОМ

- Меры по УПРАВЛЕНИЮ РИСКОМ верифицируются при нормальных или стандартизированных условиях, не отражающих широкого диапазона аномальных и стрессовых условий;

- Программное обеспечение или данные, использованные при реализации мер по УПРАВЛЕНИЮ РИСКОМ, включены в компоненты или месторасположения, которые легкодоступны для другого программного обеспечения, что повышает риск побочных эффектов;

- Меры по УПРАВЛЕНИЮ РИСКОМ верифицированы только на одной операционной системе или программной платформе;

- Некоторые меры по УПРАВЛЕНИЮ РИСКОМ не верифицированы в связи со сложностью моделирования их возникновения (например, отказ памяти, конфликт при доступе к ресурсам, порча данных, переполнение стека);

- Предположение о том, что все относящиеся к БЕЗОПАСНОСТИ АНОМАЛИИ будут обнаружены при разработке и что тестирование гарантирует корректную работу;

- Реализация мер по УПРАВЛЕНИЮ РИСКОМ, которые делают программное обеспечение значительно более сложным. Сложность увеличивает вероятность появления дополнительных АНОМАЛИЙ и причин новых ОПАСНОСТЕЙ.

ИСО 14971 Раздел 9: ПОСТПРОИЗВОДСТВЕННАЯ информация

- Игнорирование потенциально опасных контекстных событий от ОШИБОК ПОЛЬЗОВАТЕЛЯ, когда дополнительные меры по УПРАВЛЕНИЮ РИСКОМ могли бы быть применены;

- Предположение, что начальные значения вероятности и ТЯЖЕСТИ являются правильными, без оценивания информации о применении изделия;

- Упущение, что МЕДИЦИНСКОЕ ИЗДЕЛИЕ может быть применено не по назначению так, что меры по УПРАВЛЕНИЮ РИСКОМ будут неэффективны. Например, изделие in-vitro для тестирования на ВИЧ было предназначено для индивидуального применения, а используется для скрининга станции по переливанию крови.

МЭК 62304 Пункт 5.1 Планирование разработки программного обеспечения

- Деятельность по МЕНЕДЖМЕНТУ РИСКА не включена в планы программного обеспечения и в ПРОЦЕССЫ ЖИЗНЕННОГО ЦИКЛА;

- Деятельность по МЕНЕДЖМЕНТУ РИСКА программного обеспечения не связана с деятельностью по МЕНЕДЖМЕНТУ РИСКА МЕДИЦИНСКОГО ИЗДЕЛИЯ;

- ОЦЕНИВАНИЕ РИСКА программного обеспечения проводится только для одной стадии ЖИЗНЕННОГО ЦИКЛА;

- Разработчики и испытатели программного обеспечения не обучены или не имеют опыта в МЕНЕДЖМЕНТЕ РИСКА;

- МЕНЕДЖМЕНТ РИСКА программного обеспечения считается полностью включенным в деятельность по общему МЕНЕДЖМЕНТУ РИСКА;

- Риски программного обеспечения управляются неаккуратно;

- Решения в отношении ПРОСЛЕЖИВАЕМОСТИ и БЕЗОПАСНОСТИ не установлены.

МЭК 62304 Аспекты программного обеспечения неизвестного происхождения (ПОНП)

- Пропуск разработки внутренних мер по УПРАВЛЕНИЮ РИСКОМ из-за отсутствия ОЦЕНИВАНИЯ РИСКА и управления при определении АРХИТЕКТУРЫ программного обеспечения;

- Предположение о том, что тестирование сделает неэффективные АРХИТЕКТУРЫ достаточно безопасными;

- Неполная идентификация аспектов БЕЗОПАСНОСТИ АРХИТЕКТУРЫ, что ведет к неизвестным РИСКАМ в отношении БЕЗОПАСНОСТИ в случаях, когда элементы архитектуры заменяют или удаляют.

МЭК 62304 Пункт 5.4 Детальная проработка программного обеспечения

- Концентрация на обработке только нормальных ситуаций (случаев) и предположение о том, что интерфейсы и параметры передачи между компонентами будут корректны, что исключает многоуровневую проверку устойчивости к ошибкам;

- При "мозговом штурме" при проработке, детализации и последующих анализах нерассмотрение возможных отказов программного обеспечения, которые могут привести к ОПАСНОСТЯМ И ОПАСНЫМ СИТУАЦИЯМ и соответствующим мерам по УПРАВЛЕНИЮ РИСКОМ;

- Игнорирование причин программных отказов (см. приложение В) в деятельности по МЕНЕДЖМЕНТУ РИСКА.

МЭК 62304 Пункт 5.5 Реализация и ВЕРИФИКАЦИЯ ПРОГРАММНОГО МОДУЛЯ

- Предположение о том, что наилучшие практики кодирования и/или ПРОЦЕССА тестирования, программные инструменты или персонал могут компенсировать ущербную, внутренне небезопасную или излишне сложную структуру;

- Привлечение неопытных разработчиков для написания критических частей кода;

- Отсутствие установления и требования применения специальных защищенных практик программирования;

- Использование исключительно динамического тестирования без выполнения проверок кода и статического анализа, особенно для критических компонентов;

- Отступление от хода разработки без понимания соотношения между требованиями к разработке и МЕНЕДЖМЕНТОМ РИСКА;

- Однократное тестирование критических компонентов на ранних стадиях ПРОЦЕССА разработки без возвращения к ним в регрессионном тестировании;

- Концентрация испытаний исключительно на динамическом тестировании, на модели черного ящика, на уровне СИСТЕМЫ и невыполнение статической и динамической ВЕРИФИКАЦИИ по модели белого ящика.

МЭК 62304 Пункты 5.6-5.7 Программная интеграция и испытания в отношении интеграции и испытание СИСТЕМЫ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

- Неприменение информации по ОЦЕНИВАНИЮ РИСКОВ при планировании тестирования и обучения испытателей;

- Зависимость от испытания как меры по УПРАВЛЕНИЮ РИСКОМ - даже в том случае, когда 100% тестирование невозможно;

- Невоспроизведение случаев отказа СИСТЕМ и программного обеспечения при тестировании для верификации мер по УПРАВЛЕНИЮ РИСКОМ;

- Применение инструментов для автоматического тестирования без должной квалификации и контроля и использование лишь результатов такого тестирования;

- Неспособность корректно проанализировать код для определения АНОМАЛИЙ, которые испытатель не сможет обнаружить.

МЭК 62304 Пункт 5.8 Выпуск программного обеспечения

- Невозможность привести ВЕРСИЮ документации релиза в соответствие выпущенным программным обеспечением может ввести в заблуждение группу разработчиков и испытателей в отношении будущих релизов. Неаккуратные документирование и ПРОСЛЕЖИВАЕМОСТЬ могут привести к потере связей, пропуску ОПАСНОСТЕЙ и их причин, потере мер по УПРАВЛЕНИЮ РИСКОМ или невозможности корректно верифицировать ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ, влияющее на БЕЗОПАСНОСТЬ;

- Невозможность привлечь персонал с клиническими знаниями для оценки остаточных АНОМАЛИЙ;

- Оценка значимости оставшихся АНОМАЛИЙ, основанная исключительно на найденных функциональных симптомах, без полного анализа главных причин для определения потенциальных побочных эффектов в различных ситуациях;

- Неучет того факта, что как только третья сторона перестанет поддерживать определенную версию ПОНП, эта версия не будет более доступна для расследования отказов и коррекций;

- Потеря определенной ВЕРСИИ программного обеспечения по причине того, что некоторые инструменты или ВЕРСИИ инструментов (например, компилятор) не были включены в архив;

- Технический файл МЕДИЦИНСКОГО ИЗДЕЛИЯ может храниться дольше, чем жизненный цикл архиватора. Если ИЗГОТОВИТЕЛЬ заменяет старый архиватор на новый, он должен предусмотреть перенос всех задействованных частей программного обеспечения.

МЭК 62304 Пункт 6.1 Разработка плана технической поддержки программного обеспечения

- Разработка ПРОЦЕССА технической поддержки не имеет четкого подхода к МЕНЕДЖМЕНТУ РИСКА изменений;

- Установление МЕНЕДЖМЕНТА РИСКА для изменений, который рассматривает только функциональные аспекты изменения и не рассматривает компоненты, участвующие в изменении, и связанные с ними РИСКИ.

МЭК 62304 Пункты 6.2-6.3 Анализ проблем и модификаций и их реализация

- Предположение, что небольшое функциональное изменение не повлияет на БЕЗОПАСНОСТЬ;

- Расширение области применения МЕДИЦИНСКОГО ИЗДЕЛИЯ на новые группы пациентов, новые заболевания, новые типы пользователей (например, медицинские сестры вместо хирургов) или на новые программные платформы без пересмотра существующих мер по УПРАВЛЕНИЮ РИСКОМ и пригодности пользовательского интерфейса;

- Установка приоритетности разрешения проблем на основе симптомов и контекста, без определения главных причин и потенциальных побочных эффектов;

- Программное обеспечение для немедицинских применений (например, генерация счета) содержит клинические данные, которые впоследствии распространяются для клинических целей без соответствующего МЕНЕДЖМЕНТА РИСКА.