Откройте актуальную версию документа прямо сейчас
Если вы являетесь пользователем интернет-версии системы ГАРАНТ, вы можете открыть этот документ прямо сейчас или запросить по Горячей линии в системе.
Вход
Купить систему ГАРАНТ
Получить демо-доступ
Узнать стоимость
Информационный банк
Подобрать комплект
Семинары
- Главная
- Межгосударственный стандарт ГОСТ IEC 62304-2022 "Изделия медицинские. Программное обеспечение. Процессы жизненного цикла" (введен в действие приказом Федерального агентства по техническому регулированию и метрологии от 26 октября 2022 г. N 1196-ст)
- Приложение C (справочное). Взаимосвязь с другими стандартами
Приложение C (справочное). Взаимосвязь с другими стандартами
Приложение C
(справочное)
Взаимосвязь с другими стандартами
C.1 Общие положения
Настоящий стандарт применяется к разработке и технической поддержке программного обеспечения МЕДИЦИНСКИХ ИЗДЕЛИЙ. Программное обеспечение может быть подсистемой МЕДИЦИНСКОГО ИЗДЕЛИЯ или являться самостоятельным МЕДИЦИНСКИМ ИЗДЕЛИЕМ. Настоящий стандарт предназначен для использования совместно с другими подходящими стандартами на процессы разработки МЕДИЦИНСКИХ ИЗДЕЛИЙ.
Стандарты по менеджменту МЕДИЦИНСКИХ ИЗДЕЛИЙ, такие как ISO 13485:2003 [8] (см. C.2 и приложение D) и ISO 14971:2007, обеспечивают менеджмент окружения (среды), что закладывает основу для организации разработки продукции. Стандарты по БЕЗОПАСНОСТИ, такие как IEC 60601-1 [1] (см. приложение C.4) и IEC 61010-1 [5] (см. приложение C.5), дают определенное руководство по созданию безопасных МЕДИЦИНСКИХ ИЗДЕЛИЙ. Когда программное обеспечение является составной частью таких МЕДИЦИНСКИХ ИЗДЕЛИЙ, настоящий стандарт содержит более детальное руководство относительно требований к разработке и поддержанию безопасности ПО МЕДИЦИНСКИХ ИЗДЕЛИЙ. Многие другие стандарты, такие как ISO/IEC 12207 [9] (см. приложение C.6), IEC 61508-3 [4] (см. приложение C.7) и ISO/IEC 90003 [15], могут рассматриваться как источники методов, инструментов и техник, которые следует использовать для выполнения требований настоящего стандарта. Рисунок C.1 показывает взаимосвязь между этими стандартами.
Если цитируются положения или требования других стандартов, используемые термины в цитируемых элементах терминов являются терминами, которые определены в другом стандарте и не определены в настоящем стандарте.
Рисунок C.1 - Взаимосвязь ключевых стандартов на МЕДИЦИНСКИЕ ИЗДЕЛИЯ с IEC 62304
C.2 Взаимосвязь с ISO 13485
Настоящий стандарт требует, чтобы изготовитель использовал систему менеджмента качества. Когда изготовитель использует ISO 13485 [8], требования настоящего стандарта непосредственно связаны с требованиями ISO 13485:2003, как это показано в таблице C.1.
Таблица C.1 - Взаимосвязь с ISO 13485:2003
|
Разделы/подразделы настоящего стандарта |
Соответствующие пункты ISO 13485:2003 |
|
1 |
2 |
|
5.1 Планирование разработки программного обеспечения |
7.3.1 Планирование проектирования и разработки |
|
5.2 Анализ требований к программному обеспечению |
7.3.2 Входные данные для проектирования и разработки |
|
5.3 Проектирование АРХИТЕКТУРЫ программного обеспечения |
|
|
5.4 Разработка детального дизайна программного обеспечения |
|
|
5.5 Имплементация ПРОГРАММНЫХ БЛОКОВ |
|
|
5.6 Интеграция программного обеспечения и тестирование интеграции |
|
|
5.7 Тестирование ПРОГРАММНОЙ СИСТЕМЫ |
7.3.3 Выходные данные проектирования и разработки 7.3.4 Анализ проекта и разработки |
|
5.8 Выпуск программного обеспечения на системном уровне |
7.3.5 ВЕРИФИКАЦИЯ проектирования и разработки 7.3.6 Валидация проектирования и разработки |
|
6.1 Установление плана технической поддержки программного обеспечения |
7.3.7 Управление изменениями проекта и разработки |
|
6.2 Анализ модификации и проблем |
|
|
6.3 Осуществление модификации |
7.3.5 ВЕРИФИКАЦИЯ проектирования и разработки 7.3.6 Валидация проектирования и разработки |
|
7.1 Анализ программного обеспечения, способствующего опасным ситуациям |
|
|
7.2 Меры по УПРАВЛЕНИЮ РИСКОМ |
|
|
7.3 ВЕРИФИКАЦИЯ мер по УПРАВЛЕНИЮ РИСКОМ |
|
|
7.4 МЕНЕДЖМЕНТ РИСКА в отношении изменений программного обеспечения |
|
|
8.1 Идентификация конфигурации |
7.5.3 Идентификация и ПРОСЛЕЖИВАЕМОСТЬ |
|
8.2 Управление изменениями |
7.5.3 Идентификация и ПРОСЛЕЖИВАЕМОСТЬ |
|
8.3 Учет статуса конфигурации |
|
|
9 Процесс решения проблем программного обеспечения |
|
C.3 Взаимосвязь с ISO 14971:2007
Таблица C.2 показывает области, где настоящий стандарт усиливает требования к ПРОЦЕССУ МЕНЕДЖМЕНТА РИСКА, требуемого ISO 14971.
Таблица C.2 - Взаимосвязь с ISO 14971:2007
|
Разделы/подразделы ISO 14971:2007 |
Соответствующие подразделы и пункты настоящего стандарта |
|
4.1 Процесс АНАЛИЗА РИСКА |
|
|
4.2 Предусмотренное применение и определение характеристик, относящихся к БЕЗОПАСНОСТИ МЕДИЦИНСКОГО ИЗДЕЛИЯ |
|
|
4.3 Идентификация ОПАСНОСТЕЙ |
7.1 Анализ программного обеспечения, способствующего опасным ситуациям |
|
4.4 Определение РИСКОВ для каждой ОПАСНОЙ СИТУАЦИИ |
4.3 *Классификация программного обеспечения в отношении безопасности |
|
5 ОЦЕНИВАНИЕ РИСКА |
|
|
6.1 Уменьшение риска |
|
|
6.2 Анализ возможностей УПРАВЛЕНИЯ РИСКОМ |
7.2.1 Определение мер по УПРАВЛЕНИЮ РИСКОМ |
|
6.3 Выполнение мер по УПРАВЛЕНИЮ РИСКОМ |
7.2.2 Меры по УПРАВЛЕНИЮ РИСКОМ, реализованные в программном обеспечении 7.3.1 Проверка мер по УПРАВЛЕНИЮ РИСКОМ |
|
6.4 ОЦЕНИВАНИЕ ОСТАТОЧНОГО РИСКА |
|
|
6.5 Анализ соотношения риск/польза |
|
|
6.6 РИСКИ, возникающие в результате МЕР ПО УПРАВЛЕНИЮ РИСКАМИ |
7.3.2 Не применяется |
|
6.7 Полнота УПРАВЛЕНИЯ РИСКАМИ |
|
|
7 ОЦЕНИВАНИЕ допустимости совокупного ОСТАТОЧНОГО РИСКА |
|
|
8 Отчет по МЕНЕДЖМЕНТУ РИСКА |
7.3.3 Документирование ПРОСЛЕЖИВАЕМОСТИ |
|
9 Производственная и постпроизводственная информация |
7.4 МЕНЕДЖМЕНТ РИСКА в отношении изменений программного обеспечения |
C.4 Взаимосвязь ПЭМС с требованиями МЭК 60601-1:2005 + МЭК 60601-1:2005/AMD1:2012
C.4.1 Общие положения
Требования к ПО - это подмножество требований к программируемой электрической медицинской системе (ПЭМС). Настоящий стандарт определяет требования к ПО, которые являются дополнительными, но не являются несовместимыми с требованиями IEC 60601-1:2005 + IEC 60601-1:2005/AMD1:2012 [1] к ПЭМС. Поскольку ПЭМС включает элементы, не являющиеся ПО, не все требования IEC 60601-1:2005 + IEC 60601-1:2005/AMD1:2012 к ПЭМС отражены в настоящем стандарте. С публикацией IEC 60601-1:2005 + IEC 60601-1:2005/AMD1:2012, IEC 62304 теперь является нормативным справочником IEC 60601-1, и соответствие пункту 14 IEC 60601-1:2005 + IEC 60601-1:2005/AMD1:2012 (и, следовательно, соответствие стандарту) требует соответствия частям IEC 62304 (не всему IEC 62304, потому что IEC 60601-1:2005 + IEC 60601-1:2005/AMD1:2012 не требует соблюдения требований к постпроизводству и техническому обслуживанию IEC 62304). Наконец, важно помнить, что IEC 60601-1:2005 + IEC 60601-1:2005/AMD1:2012 применяется только в том случае, если программное обеспечение является частью ПЭМС, а не если программное обеспечение само по себе является МЕДИЦИНСКИМ ИЗДЕЛИЕМ.
C.4.2 Взаимосвязь ПО с разработкой ПЭМС
Используя V-модель, показанную на рисунке C.2, для описания того, что происходит во время разработки ПЭМС, можно увидеть, что требования настоящего стандарта применяются на уровне компонентов ПЭМС, от спецификации требований программного обеспечения до интеграции ПРОГРАММНЫХ СОСТАВНЫХ ЧАСТЕЙ в ПРОГРАММНУЮ СИСТЕМУ. Эта ПРОГРАММНАЯ СИСТЕМА - часть программируемой электрической подсистемы (ПЭСС), являющейся, в свою очередь, частью ПЭМС.
Блоки - типичные виды деятельности жизненного цикла разработки; сплошные стрелки - типичные результаты, передаваемые в/из видов деятельности; пунктирные стрелки - результаты, относящиеся только к файлу менеджмента риска;
- результат процесса разрешения проблем;
- исходные данные процесса разрешения проблем
Рисунок C.2 - ПО как часть V-модели
C.4.3 ПРОЦЕСС разработки
Соответствие ПРОЦЕССУ разработки программного обеспечения в настоящем стандарте (раздел 5) требует, чтобы план разработки программного обеспечения был определен и соблюдался; это не требует, чтобы использовалась некая определенная модель жизненного цикла, но требует, чтобы план включал определенные виды ДЕЯТЕЛЬНОСТИ и имел определенные признаки. Эти требования соотносятся с требованиями ПЭМС в IEC 60601 к разработке жизненного цикла, спецификации требований, АРХИТЕКТУРЕ, проектированию и осуществлению, а также ВЕРИФИКАЦИИ. Требования в этом стандарте более детальны в области разработки ПО, чем требования IEC 60601-1.
C.4.4 ПРОЦЕСС технического обслуживания
Соответствие ПРОЦЕССУ технического обслуживания программного обеспечения в настоящем стандарте (раздел 6) требует, чтобы процедуры были установлены и соблюдались, когда в ПО вносятся изменения. Эти требования соответствуют требованиям IEC 60601-1 для модификации ПЭМС. Требования в настоящем стандарте относительно технического обслуживания программного обеспечения предоставляют более подробную информацию о том, что должно быть сделано для технической поддержки программного обеспечения, чем требования для модификации ПЭМС в IEC 60601-1.
C.4.5 Прочие ПРОЦЕССЫ
Прочие ПРОЦЕССЫ в настоящем стандарте определяют дополнительные требования к программному обеспечению сверх подобных требований к ПЭМС в IEC 60601-1. В большинстве случаев существует общее требование к ПЭМС в IEC 60601-1, которое расширяет ПРОЦЕССЫ в настоящем стандарте.
ПРОЦЕСС МЕНЕДЖМЕНТА РИСКА программного обеспечения в настоящем стандарте соответствует дополнительным требованиям к МЕНЕДЖМЕНТУ РИСКА, определенным для ПЭМС в IEC 60601-1.
ПРОЦЕСС решения проблем программного обеспечения в настоящем стандарте соответствует требованию к решению проблем для ПЭМС в IEC 60601-1.
ПРОЦЕСС менеджмента конфигурации программного обеспечения в настоящем стандарте устанавливает дополнительные требования, которые отсутствуют для ПЭМС в IEC 60601-1, за исключением документации.
C.4.6 Охват требований к ПЭМС в IEC 60601-1:2005 + IEC 60601-1:2005/AMD1:2012
Таблица C.3 - Взаимосвязь с IEC 60601-1 (1 из 5)
|
Требования к ПЭМС в IEC 60601-1:2005 + IEC 60601-1:2005/AMD1:2012 |
Требования IEC 62304, связанные с программным обеспечением подсистемы ПЭМС |
|
14.1 Общие положения Требования 14.2-14.12 (включительно) применяются к ПЭМС только в тех случаях, когда: |
4.3* Классификация программного обеспечения в отношении безопасности |
|
- ни одна из ПРОГРАММИРУЕМЫХ ЭЛЕКТРОННЫХ ПОДСИСТЕМ (ПЭСС) не задействована в обеспечении ОСНОВНОЙ БЕЗОПАСНОСТИ или ОСНОВНЫХ ФУНКЦИОНАЛЬНЫХ ХАРАКТЕРИСТИК или - применение МЕНЕДЖМЕНТА РИСКА как описано в 4.2, показывает, что отказ любой ПЭСС не приводит к возникновению недопустимого РИСКА.
|
Требования к ПЭМС, установленные в IEC 60601-1, применимы только к программному обеспечению класса безопасности B и C. Настоящий стандарт содержит некоторые требования в отношении программного обеспечения класса безопасности A. |
|
Требования 14.13 применимы к любым ПЭМС, предназначенным для включения в ИТ-СЕТЬ, независимо от применения требований 14.2-4.12. В случае применения требований 14.2-14.13, требования 4.3, разделов 5, 7, 8 и 9 IEC 62304:2006 также применяются к разработке или модификации программного обеспечения для каждого ПЭСС |
ПРОЦЕСС разработки программного обеспечения, необходимый для соответствия IEC 60601-1, не включает последующий мониторинг и техническую поддержку, требуемые разделом 6 IEC 62304:2006 |
|
14.2 Документирование Документы, требуемые разделом 14, должны рассматриваться, утверждаться, выпускаться и изменяться в соответствии с официальной процедурой управления документацией |
5.1* Планирование разработки программного обеспечения В дополнение к конкретным требованиям к ДЕЯТЕЛЬНОСТИ по планированию разработки программного обеспечения документы, которые являются частью ФАЙЛА МЕНЕДЖМЕНТА РИСКА, должны поддерживаться в соответствии с требованиями ISO 14971. Кроме того, ISO 13485 [8] требует управления документами системы качества |
|
14.3 План МЕНЕДЖМЕНТА РИСКА План МЕНЕДЖМЕНТА РИСКА, требуемый согласно 4.2.2, должен включать ссылку на план ВЕРИФИКАЦИИ ПЭМС (см. 14.11) |
Нет специальных требований. Не существует никакого определенного плана валидации программного обеспечения. План валидации ПЭМС относится к уровню СИСТЕМЫ и находится вне области применения настоящего стандарта на программное обеспечение. Настоящий стандарт требует ПРОСЛЕЖИВАЕМОСТИ от ОПАСНОСТИ определенного события с программным обеспечением до меры по УПРАВЛЕНИЮ РИСКОМ и к ВЕРИФИКАЦИИ меры по УПРАВЛЕНИЮ РИСКОМ (см. 7.3) |
|
14.4 ЖИЗНЕННЫЙ ЦИКЛ РАЗРАБОТКИ ПЭМС ЖИЗНЕННЫЙ ЦИКЛ РАЗРАБОТКИ ПЭМС должен быть документально оформлен. |
5.1* Планирование разработки программного обеспечения 5.1.1 План разработки программного обеспечения Пункты, на которые ссылается план разработки ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ, составляют ЖИЗНЕННЫЙ ЦИКЛ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ |
|
ЖИЗНЕННЫЙ ЦИКЛ РАЗРАБОТКИ ПЭМС должен состоять из набора определенных этапов |
|
|
На каждом этапе должна быть определена ДЕЯТЕЛЬНОСТЬ, которая должна быть завершена, а также методы ВЕРИФИКАЦИИ, которые должны применяться в отношении этой ДЕЯТЕЛЬНОСТИ |
5.1.6 Планирование ВЕРИФИКАЦИИ программного обеспечения Должны быть запланированы ЗАДАЧИ ВЕРИФИКАЦИИ, этапы и критерии приемки |
|
Каждая ДЕЯТЕЛЬНОСТЬ должна определяться с указанием входных и выходных параметров |
5.1.1 План разработки программного обеспечения |
|
|
Вся ДЕЯТЕЛЬНОСТЬ определена в настоящем стандарте. Документация, которая должна быть разработана, определена для каждой ДЕЯТЕЛЬНОСТИ |
|
На каждом этапе должны определяться работы по МЕНЕДЖМЕНТУ РИСКА, которые необходимо завершить перед этим этапом |
5.1.1 План разработки программного обеспечения |
|
В соответствии с настоящим стандартом разработка жизненного цикла должна быть документирована в плане разработки. Это означает, что план разработки должен содержать разработку конкретного жизненного цикла | |
|
ЖИЗНЕННЫЙ ЦИКЛ РАЗРАБОТКИ ПЭМС должен составляться для каждой разработки путем создания планов, в которых уточняются работы, этапы и графики их выполнения |
|
|
ЖИЗНЕННЫЙ ЦИКЛ РАЗРАБОТКИ ПЭМС должен также включать требования к документации |
5.1.1 План разработки программного обеспечения 5.1.8 Документация по планированию |
|
14.5 Решение проблем Если целесообразно, должна быть разработана и поддерживаться документированная система решения проблем, возникающих на каждом этапе ДЕЯТЕЛЬНОСТИ (и между ними) ЖИЗНЕННОГО ЦИКЛА РАЗРАБОТКИ ПЭМС |
9 ПРОЦЕСС решения проблем программного обеспечения |
|
В зависимости от типа продукции СИСТЕМА решения проблем может: - регистрироваться как часть ЖИЗНЕННОГО ЦИКЛА РАЗРАБОТКИ ПЭМС; - позволять уведомлять о потенциальных или возникающих проблемах, затрагивающих ОСНОВНУЮ БЕЗОПАСНОСТЬ или ОСНОВНЫЕ ФУНКЦИОНАЛЬНЫЕ ХАРАКТЕРИСТИКИ ПЭМС; - включать оценку каждой проблемы с точки зрения связанных с ней РИСКОВ; - определять критерии завершения решения проблем; - определять работы, которые должны выполняться для решения каждой проблемы |
5.1.1 План разработки программного обеспечения 9.1 Подготовка ОТЧЕТОВ О ПРОБЛЕМАХ |
|
14.6 ПРОЦЕСС МЕНЕДЖМЕНТА РИСКА |
7 ПРОЦЕСС МЕНЕДЖМЕНТА РИСКА программного обеспечения |
|
14.6.1 Идентификация известных и прогнозируемых ОПАСНОСТЕЙ При составлении перечня известных или прогнозируемых ОПАСНОСТЕЙ ИЗГОТОВИТЕЛЬ должен учитывать те из них, которые связаны с программным обеспечением и особенностями аппаратных средств ПЭМС, включая связанные с подключением к ИТ-СЕТЕВЫМ РЕСУРСАМ, компонентами сторонних изготовителей и унаследованными подсистемами |
7.1* Анализ программного обеспечения, способствующего опасным ситуациям |
|
Настоящий стандарт не ссылается на конкретное сопряжение с сетями и данными | |
|
14.6.2 УПРАВЛЕНИЕ РИСКОМ Для реализации каждой меры ПО УПРАВЛЕНИЮ РИСКОМ должны быть выбраны и идентифицированы надлежащим образом проверенные инструменты и ПРОЦЕДУРЫ. Эти инструменты и ПРОЦЕДУРЫ должны быть подходящими для обеспечения того, что каждая мера ПО УПРАВЛЕНИЮ РИСКОМ результативно снизит идентифицированный(е) РИСК(И) |
5.1.4 Стандарты, методы и инструменты планирования разработки программного обеспечения |
|
Настоящий стандарт требует идентификации определенных инструментов и методов, которые используются как общепринятые при разработке, но не в отношении каждой меры ПО УПРАВЛЕНИЮ РИСКОМ | |
|
14.7 Перечень требований Для любой ПЭМС и каждой из ее подсистем должен быть разработан и задокументирован перечень требований |
5.2 Анализ требований к программному обеспечению Настоящий стандарт применим только в отношении подсистем программного обеспечения ПЭМС |
|
Перечень требований к системе или подсистеме должен включать и характеризовать все ОСНОВНЫЕ ФУНКЦИОНАЛЬНЫЕ ХАРАКТЕРИСТИКИ и все мероприятия по УПРАВЛЕНИЮ РИСКОМ, реализуемые в системе или подсистеме |
5.2.1 Отделение и документирование требований к программному обеспечению от требований СИСТЕМЫ 5.2.2 Содержание требований к программному обеспечению 5.2.3 Включение мер УПРАВЛЕНИЯ РИСКОМ в требования к программному обеспечению Настоящий стандарт устанавливает, что требования, связанные с основными функциональными характеристиками и мерами по УПРАВЛЕНИЮ РИСКОМ, должны отличаться от других требований, но требует однозначной идентификации любых требований |
|
14.8 АРХИТЕКТУРА Для ПЭМС и каждой из ее подсистем должна быть установлена АРХИТЕКТУРА, удовлетворяющая перечню требований |
5.3 Проектирование АРХИТЕКТУРЫ программного обеспечения |
|
Когда это целесообразно для снижения РИСКА до допустимого уровня, в спецификации требований к АРХИТЕКТУРЕ должны использоваться: a) КОМПОНЕНТЫ С ВЫСОКОЙ СТЕПЕНЬЮ ИНТЕГРАЦИИ; b) устойчивые к отказам функции; c) избыточность; d) диверсификация; e) разделение функций; f) защищенная конструкция, служащая, например, для ограничения представляющих потенциальную опасность эффектов путем ограничения допускаемой выходной мощности или введения устройств, ограничивающих свободный ход исполнительных устройств. |
5.3.5 Идентификация обособленности, необходимой для УПРАВЛЕНИЯ РИСКОМ |
|
Разделение является единственным идентифицированным способом, и это только идентификация, потому что требование состоит в точном определении того, что целостность разделения обеспечена | |
|
Спецификация АРХИТЕКТУРЫ должна также учитывать: a) распределение мер по УПРАВЛЕНИЮ РИСКОМ в подсистемах и компонентах ПЭМС; b) виды отказов компонентов и их последствия; c) неспецифические отказы; d) систематические отказы; e) период проведения тестирования или диагностики; f) ремонтопригодность; g) защиту от прогнозируемых ошибок в применении; h) если применимо, требования к ИТ-СЕТЕВЫМ РЕСУРСАМ |
Это не включено в настоящий стандарт |
|
14.9 Проектирование и реализация Когда это целесообразно, проектирование должно проводиться для отдельных подсистем, каждая из которых должна иметь собственные требования к разработке и требования к испытаниям |
5.4 Разработка детального дизайна программного обеспечения 5.4.2 Разработка детального дизайна для каждого ПРОГРАММНОГО БЛОКА Настоящий стандарт не требует спецификации испытаний для детализированного проекта |
|
Пояснения относительно условий проектирования должны включаться в документацию |
5.4.2 Разработка детального дизайна для каждого ПРОГРАММНОГО БЛОКА |
|
14.10 ВЕРИФИКАЦИЯ ВЕРИФИКАЦИЯ требуется для всех функций, которые обеспечивают ОСНОВНУЮ БЕЗОПАСНОСТЬ, ОСНОВНЫЕ ФУНКЦИОНАЛЬНЫЕ ХАРАКТЕРИСТИКИ или меры по УПРАВЛЕНИЮ РИСКОМ |
5.1.6 Планирование ВЕРИФИКАЦИИ программного обеспечения |
|
ВЕРИФИКАЦИЯ требуется в отношении любой ДЕЯТЕЛЬНОСТИ | |
|
План ВЕРИФИКАЦИИ должен формироваться для указания способов проверки этих функций и включать: - указания о том, на каком этапе (этапах) каждая функция должна проходить ВЕРИФИКАЦИЮ; - выбор и документирование принципов, мероприятий, методов и соответствующего уровня независимости персонала, выполняющего ВЕРИФИКАЦИЮ; - выбор и использование методов ВЕРИФИКАЦИИ; критерии ВЕРИФИКАЦИИ |
5.1.6 Планирование ВЕРИФИКАЦИИ программного обеспечения |
|
Требование в отношении независимости персонала не включено в настоящий стандарт. Требование считается установленным в ISO 13485 | |
|
ВЕРИФИКАЦИЯ должна выполняться в соответствии с планом ВЕРИФИКАЦИИ. Результаты ВЕРИФИКАЦИИ ДЕЯТЕЛЬНОСТИ должны документироваться |
Требования по проведению ВЕРИФИКАЦИИ установлено к большинству видов ДЕЯТЕЛЬНОСТИ |
|
14.11 ВАЛИДАЦИЯ ПЭМС План ВАЛИДАЦИИ ПЭМС должен включать валидацию ОСНОВНОЙ БЕЗОПАСНОСТИ и ОСНОВНЫХ ФУНКЦИОНАЛЬНЫХ ХАРАКТЕРИСТИК |
Настоящий стандарт не распространяется на валидацию программного обеспечения. Валидация ПЭМС является ДЕЯТЕЛЬНОСТЬЮ на уровне СИСТЕМЫ и находится вне области применения настоящего стандарта |
|
Метод проведения ВАЛИДАЦИИ ПЭМС должен быть задокументирован |
Настоящий стандарт не распространяется на валидацию программного обеспечения. Валидация ПЭМС является ДЕЯТЕЛЬНОСТЬЮ на уровне СИСТЕМЫ и находится вне области применения настоящего стандарта |
|
ВАЛИДАЦИЯ ПЭМС должна выполняться в соответствии с планом ВАЛИДАЦИИ ПЭМС. Результаты ДЕЯТЕЛЬНОСТИ по ВАЛИДАЦИИ ПЭМС должны быть задокументированы |
Настоящий стандарт не распространяется на валидацию программного обеспечения. Валидация ПЭМС является ДЕЯТЕЛЬНОСТЬЮ на уровне СИСТЕМЫ и находится вне области применения настоящего стандарта |
|
Лицо, несущее основную ответственность за ВАЛИДАЦИЮ ПЭМС, должно быть независимым от коллектива разработчиков ПЭМС. ИЗГОТОВИТЕЛЬ должен задокументировать обоснование уровня его независимости |
Настоящий стандарт не распространяется на валидацию программного обеспечения. Валидация ПЭМС является ДЕЯТЕЛЬНОСТЬЮ на уровне СИСТЕМЫ и находится вне области применения настоящего стандарта |
|
Никакой член коллектива разработчиков ПЭМС не должен нести ответственность за процесс ВАЛИДАЦИИ ПЭМС их собственного проекта |
Настоящий стандарт не распространяется на валидацию программного обеспечения. Валидация ПЭМС является ДЕЯТЕЛЬНОСТЬЮ на уровне СИСТЕМЫ и находится вне области применения настоящего стандарта |
|
Все профессиональные взаимодействия между членами коллектива, выполняющего работы по ВАЛИДАЦИИ ПЭМС, и членами коллектива разработчиков ПЭМС должны регистрироваться в ФАЙЛЕ МЕНЕДЖМЕНТА РИСКА |
Настоящий стандарт не распространяется на валидацию программного обеспечения. Валидация ПЭМС является ДЕЯТЕЛЬНОСТЬЮ на уровне СИСТЕМЫ и находится вне области применения настоящего стандарта |
|
Ссылка на методы и РЕЗУЛЬТАТЫ ПРОВЕРКИ СООТВЕТСТВИЯ (ВАЛИДАЦИИ) ПЭМС должна включаться в ФАЙЛ МЕНЕДЖМЕНТА РИСКА |
Настоящий стандарт не распространяется на валидацию программного обеспечения. Валидация ПЭМС является ДЕЯТЕЛЬНОСТЬЮ на уровне СИСТЕМЫ и находится вне области применения настоящего стандарта |
|
14.12 Модификация Если часть или весь существующий проект является модификацией более раннего проекта, то к нему следует либо применять требования всего настоящего пункта так, как если бы эта модификация была новым проектом, либо с помощью задокументированной ПРОЦЕДУРЫ модификации в процессе внесения изменений ОЦЕНИВАТЬ возможность дальнейшего использования предыдущей проектной документации |
6 Техническая поддержка программного обеспечения Настоящий стандарт устанавливает, что техническая поддержка программного обеспечения должна быть запланирована, а реализация модификаций должна использовать ПРОЦЕСС разработки программного обеспечения или установленный ПРОЦЕСС технической поддержки программного обеспечения |
|
Когда программное обеспечение модифицируется, требования подраздела 4.3, раздела 5, раздела 7, раздела 8 и раздела 9 стандарта IEC 62304:2006 также применяются к модификации |
|
|
14.13 ПЭМС, предназначенные для подключения к ИТ-СЕТЕВЫМ РЕСУРСАМ |
Требования в отношении подключения к ИТ-СЕТЕВЫМ РЕСУРСАМ не включены в настоящий стандарт |
|
Если ПЭМС предназначена для соединения с помощью ИТ-СЕТЕВЫХ РЕСУРСОВ с другим изделием, которое не может контролироваться ИЗГОТОВИТЕЛЕМ ПЭМС, то в техническом описании указывают: a) цель подключения ПЭМС к ИТ-СЕТЕВЫМ РЕСУРСАМ; b) требуемые характеристики ИТ-СЕТЕВЫХ РЕСУРСОВ, включающей ПЭМС; c) требуемая конфигурация ИТ-СЕТЕВЫХ РЕСУРСОВ, включающей ПЭМС; d) технические характеристики сетевого подключения ПЭМС, включая спецификации безопасности; e) предполагаемый поток информации между ПЭМС, ИТ-СЕТЕВЫМИ РЕСУРСАМИ и другими устройствами, а также предполагаемая маршрутизация.
Примечание 1 - Это может включать аспекты результативности и безопасности данных и систем, связанные с ОСНОВНОЙ БЕЗОПАСНОСТЬЮ и ОСНОВНЫМИ ФУНКЦИОНАЛЬНЫМИ ХАРАКТЕРИСТИКАМИ (см. также раздел H.6 и IEC 80001-1:2010);
f) перечень ОПАСНЫХ СИТУАЦИЙ, возникающих в результате неспособности ИТ-СЕТЕВЫХ РЕСУРСОВ обеспечить характеристики, необходимые для выполнения цели подключения PEMS к ИТ-СЕТЕВЫМ РЕСУРСАМ; В СОПРОВОДИТЕЛЬНОЙ ДОКУМЕНТАЦИИ ИЗГОТОВИТЕЛЬ должен проинструктировать ОТВЕТСТВЕННУЮ ОРГАНИЗАЦИЮ о том, что: - соединение ПЭМС с ИТ-СЕТЕВЫМИ РЕСУРСАМИ, которое производится с использованием другого оборудования, может приводить к ранее непредусмотренным РИСКАМ для ПАЦИЕНТОВ, ОПЕРАТОРОВ или третьих лиц; - ОТВЕТСТВЕННАЯ ОРГАНИЗАЦИЯ должна идентифицировать, анализировать, оценивать эти РИСКИ и управлять ими.
Примечание 3 - IEC 80001-1:2010 содержит рекомендации для ОТВЕТСТВЕННОЙ ОРГАНИЗАЦИИ по обращению с такими рисками;
- последующие изменения ИТ-СЕТЕВЫХ РЕСУРСОВ могут приводить к появлению новых РИСКОВ и требовать дополнительного анализа; - последующие изменения ИТ-СЕТЕВЫХ РЕСУРСОВ могут включать: изменения в их конфигурации; подсоединение к ним дополнительных элементов; отсоединение от них отдельных элементов; модификацию соединенного с ними оборудования; модернизацию соединенного с ними оборудования |
C.4.7 Взаимосвязь с IEC 60601-1-4
IEC 60601-1-4 был отменен.
C.5 - Взаимосвязь с IEC 61010-1
Область применения IEC 61010-1 [5] распространяется на измерительное оборудование и оборудование для электрических испытаний, оборудование электрического контроля и электрооборудование лаборатории. Только часть лабораторного электрооборудования используется в здравоохранении или в качестве изделий для in vitro диагностики.
В соответствии с правовым регулированием или нормативными ссылками изделия для диагностики in vitro относятся к МЕДИЦИНСКИМ ИЗДЕЛИЯМ, при этом не подпадая под область применения IEC 60601-1 [1]. Это связано не только с тем, что изделия для in vitro диагностики не вступают в прямой контакт с пациентами, как обычные МЕДИЦИНСКИЕ ИЗДЕЛИЯ, но и с тем, что эти изделия производятся для различных применений в различных лабораториях. Использование в качестве инструментов для in vitro диагностики или принадлежностей к изделиям для in vitro диагностики встречается редко.
Если лабораторное оборудование используется в качестве изделия для in vitro диагностики, то полученные результаты измерений должны быть ОЦЕНЕНЫ в соответствии с медицинскими критериями. Применение ISO 14971 требуется для осуществления МЕНЕДЖМЕНТА РИСКА. Если подобная продукция содержит программное обеспечение, способное привести к ОПАСНОЙ СИТУАЦИИ, например к нежелательному изменению медицинских данных (результатов измерений) вследствие отказа, вызванного ПО, то должны учитываться требования IEC 62304.
IEC 61010-1:2010 содержит общее требование к оценке рисков в разделе 17, которое является более упрощенным, чем полные требования ISO 14971 по менеджменту риска. Применение стандарта IEC 61010-1, раздела 17 само по себе не соответствует требуемым критериям менеджмента риска IEC 62304, который основан на полных требованиях ISO 14971 по менеджменту риска. Исходя из этого ожидается, что если in vitro медицинское изделие имеет связанные с ПО риски, то процесс менеджмента риска выполняется в соответствии с ISO 14971, а не только разделом 17 IEC 61010-1. Соответствие разделу 17 стандарта IEC 61010-1 будет достигнуто, как подробно описано в примечании к разделу 17 стандарта IEC 61010-1.
Примечание - Одна процедура оценки РИСКА описана в Приложении J. Другие процедуры оценки РИСКОВ содержатся в ISO 14971, SEMI S10-1296, IEC 61508, ISO 14121-1 и ANSI B11.TR3. Также могут использоваться другие установленные процедуры, которые реализуют аналогичные шаги.
Блок-схема на рисунке C.3 показывает применение IEC 62304 с IEC 61010-1, раздел 17.
Рисунок C.3 - Применение IEC 62304 с IEC 61010-1
C.6 Взаимосвязь с ISO/IEC 12207
Настоящий стандарт был производным от подходов и концепций ISO/IEC 12207 [9], определяющим требования для ПРОЦЕССОВ жизненного цикла ПО в общих чертах, то есть не ограничиваясь МЕДИЦИНСКИМИ ИЗДЕЛИЯМИ.
Стандарт отличается от ISO/IEC 12207 главным образом в отношении того, что он:
- исключает аспекты СИСТЕМЫ, такие как СИСТЕМНЫЕ требования, АРХИТЕКТУРА СИСТЕМЫ и валидация;
- пропускает некоторые ПРОЦЕССЫ, рассматриваемые как дублирующая деятельность, представленные в различных изданиях для МЕДИЦИНСКИХ ИЗДЕЛИЙ;
- добавляет ПРОЦЕСС МЕНЕДЖМЕНТА РИСКА (БЕЗОПАСНОСТЬ) и ПРОЦЕСС выпуска программного обеспечения;
- включает документирование и ВЕРИФИКАЦИЮ поддерживающих ПРОЦЕССОВ в ПРОЦЕССЫ разработки и технической поддержки;
- объединяет реализацию ПРОЦЕССОВ и планирование ДЕЯТЕЛЬНОСТИ по каждому ПРОЦЕССУ в единую ДЕЯТЕЛЬНОСТЬ по ПРОЦЕССАМ разработки и технического обслуживания;
- классифицирует требования с учетом БЕЗОПАСНОСТИ;
- не классифицирует ПРОЦЕССЫ как первостепенные или поддерживающие и не группирует ПРОЦЕССЫ, как это сделано в ISO/IEC 12207.
Большинство отличий были реализованы исходя из нужд и потребностей промышленности МЕДИЦИНСКИХ ИЗДЕЛИЙ:
- фокусироваться на аспектах безопасности и МЕНЕДЖМЕНТА РИСКА МЕДИЦИНСКИХ ИЗДЕЛИЙ, установленных в ISO 14971;
- выбрать подходящие ПРОЦЕССЫ, полезные в регулируемой внешней среде;
- принять во внимание, что разработка программного обеспечения включена в систему качества (которая охватывает некоторые ПРОЦЕССЫ и требования ISO/IEC 12207);
- уменьшить уровень обобщения, чтобы облегчить применение.
Настоящий стандарт не противоречит ISO/IEC 12207. ISO/IEC 12207 может быть полезным в качестве вспомогательной информации для создания правильно структурированной МОДЕЛИ ЖИЗНЕННОГО ЦИКЛА РАЗРАБОТКИ программного обеспечения, которая включает требования настоящего стандарта.
Таблица C.5, которая была подготовлена подкомитетом 7 ISO/IEC, показывает взаимосвязь между настоящим стандартом и ISO/IEC 12207.
Таблица C.5 - Взаимосвязь с процессами ISO/IEC 12207:2008
|
Процессы настоящего стандарта |
Процессы ISO/IEC 12207:2008 |
||
|
Деятельность |
Задача |
Процессы |
Деятельность/Задача |
|
5 ПРОЦЕСС разработки программного обеспечения |
|
||
|
5.1 Планирование разработки программного обеспечения |
5.1. План разработки программного обеспечения |
7.1.1 Реализация программного обеспечения |
7.1.1.3.1 Стратегия реализации программного обеспечения 7.1.1.3.1.1 7.1.1.3.1.3 7.1.1.3.1.4 6.3.1.3.2 Планирование проекта 6.3.1.3.2.1 |
|
5.1.2 Поддержание плана разработки программного обеспечения в актуальном состоянии |
6.3.2 Оценка проекта и процесс управления |
6.3.2.3.2 Управление проектом 6.3.2.3.2.1 |
|
|
5.1.3 План разработки программного обеспечения относительно проектирования и разработки СИСТЕМЫ |
6.4.3 Процесс проектирования архитектуры системы 6.4.5 Системная интеграция 7.2.5 Процесс валидации программного обеспечения |
6.4.3.3.1 Установление архитектуры 6.4.3.3.1.1 6.4.5.3.1 Интеграция 6.4.5.3.1.1 7.2.5.3.1 Процесс реализации 7.2.5.3.1.4 |
|
|
5.1.4 Стандарты, методы и инструменты планирования разработки программного обеспечения |
7.1.1 Реализация программного обеспечения |
7.1.1.3.1 Стратегия реализации программного обеспечения 7.1.1.3.1.3 |
|
|
5.1.5 Программная интеграция и планирование тестирования интеграции |
7.1.6 Интеграция программного обеспечения |
7.1.6.3.1 Интеграция программного обеспечения 7.1.6.3.1.1 |
|
|
5.1.6 Планирование ВЕРИФИКАЦИИ программного обеспечения |
7.2.4 Верификация программного обеспечения 7.1.5 Процесс конструирования программных средств 7.1.6 Software Integration 7.1.7 Квалификационное тестирование программного обеспечения |
7.2.4.3.1 Процесс реализации 7.2.4.3.1.4 7.2.4.3.1.5 7.1.5.3.1 Процесс конструирования программных средств 7.1.5.3.1.5 7.1.6.3.1 Интеграция программного обеспечения 7.1.6.3.1.5 7.1.7.3.1 Квалификационное тестирование программного обеспечения 7.1.7.3.1.3 |
|
|
5.1.7 Планирование МЕНЕДЖМЕНТА РИСКА программного обеспечения |
6.3.4 Процесс менеджмента риска |
|
|
|
5.1.8 Документация по планированию |
7.2.1 Менеджмент документации программного обеспечения |
7.2.1.3.1 Процесс реализации 7.2.1.3.1.1 |
|
|
5.1.9 Планирование менеджмента конфигурации программного обеспечения |
7.2.2 Менеджмент конфигурации программного обеспечения 7.2.8 Процесс решения проблем в программном обеспечении |
7.2.2.3.1 Процесс реализации 7.2.2.3.1.1 7.2.8.3.1 Процесс реализации 7.2.8.3.1.1 |
|
|
5.1.10 Поддержка элементов, подлежащих управлению |
6.2.2 Менеджмент инфраструктуры |
6.2.2.3.2 Установление инфраструктуры 6.2.2.3.2.1 6.2.2.3.3 Поддержание инфраструктуры 6.2.2.3.3.1 |
|
|
5.1.11 Управление СОСТАВНЫМИ ЧАСТЯМИ КОНФИГУРАЦИИ программного обеспечения до ВЕРИФИКАЦИИ |
7.2.2 Менеджмент конфигурации программного обеспечения |
7.2.2.3.2 Идентификация конфигурации 7.2.2.3.2.1 |
|
|
5.2 Анализ требований к программному обеспечению |
5.2.1 Отделение и документирование требований к программному обеспечению на основе требований СИСТЕМЫ |
6.4.3 Проектирование архитектуры системы |
6.4.3.3.1 Установление архитектуры 6.4.3.3.1.1 |
|
5.2.2 Содержание требований к программному обеспечению |
7.1.2 Анализ требований к программному обеспечению |
7.1.2.3.1 Анализ требований к программному обеспечению 7.1.2.3.1.1 |
|
|
5.2.3 Включение мер по УПРАВЛЕНИЮ РИСКОМ в требования к программному обеспечению | |||
|
5.2.4 ПЕРЕОЦЕНИВАНИЕ АНАЛИЗА РИСКА МЕДИЦИНСКОГО ИЗДЕЛИЯ |
Нет |
Нет |
|
|
5.2.5 Обновление требований к СИСТЕМЕ |
7.1.2 Анализ требований к программному обеспечению |
7.1.2.3.1 Анализ требований к программному обеспечению 7.1.2.3.1.1 а) и b) |
|
|
5.2.6 Верификация требований к программному обеспечению |
7.2.4 Верификация программного обеспечения |
7.2.4.3.2 Верификация 7.2.4.3.2.1 |
|
|
5.3 Проектирование АРХИТЕКТУРЫ программного обеспечения |
5.3.1 Преобразование требований к программному обеспечению в АРХИТЕКТУРУ |
7.1.3 Проектирование архитектуры программного обеспечения |
7.1.3.3.1 Проектирование архитектуры программного обеспечения 7.1.3.3.1.1 |
|
5.3.2 Разработка АРХИТЕКТУРЫ для интерфейсов ПРОГРАММНЫХ СОСТАВНЫХ ЧАСТЕЙ |
7.1.3.3.1 Проектирование архитектуры программного обеспечения 7.1.3.3.1.2 |
||
|
5.3.3 Определение требований к функциональным и эксплуатационным характеристикам элементов ПОНП |
Нет |
Нет |
|
|
5.3.4 Определение требований к аппаратным и программным средствам СИСТЕМЫ, требуемых элементами ПОНП |
Нет |
Нет |
|
|
5.3.5 Идентификация обособленности, необходимой для УПРАВЛЕНИЯ РИСКОМ |
Нет |
Нет |
|
|
5.3.6 Верификация АРХИТЕКТУРЫ программного обеспечения |
7.1.3 Проектирование архитектуры программного обеспечения |
7.1.3.3.1 Проектирование архитектуры программного обеспечения 7.1.3.3.1.6 |
|
|
5.4 Разработка детального дизайна программного обеспечения |
5.4.1 Дробление программного обеспечения на ПРОГРАММНЫЕ БЛОКИ |
7.1.4 Детализированная разработка программного обеспечения |
7.1.4.3.1 Детализированная разработка программного обеспечения 7.1.4.3.1.1 |
|
5.4.2 Разработка детального дизайна для каждого ПРОГРАММНОГО БЛОКА | |||
|
5.4.3 Разработка детального дизайна для интерфейсов |
7.1.4.3.1 Детализированная разработка программного обеспечения 7.1.4.3.1.2 |
||
|
5.4.4 ВЕРИФИКАЦИЯ детального дизайна |
7.1.4 Детализированная разработка программного обеспечения |
7.1.4.3.1 Детализированная разработка программного обеспечения 7.1.4.3.1.7 |
|
|
5.5* Имплементация ПРОГРАММНЫХ БЛОКОВ |
5.5.1 Имплементация каждого ПРОГРАММНОГО БЛОКА |
7.1.5 Конструирование программного обеспечения |
7.1.5.3.1 Конструирование программного обеспечения 7.1.5.3.1.1 |
|
5.5.2 Установление ПРОЦЕССА ВЕРИФИКАЦИИ ПРОГРАММНОГО БЛОКА |
7.1.4 Детализированная разработка программного обеспечения 7.1.5 Конструирование программного обеспечения |
7.1.4.3.1 Детализированная разработка программного обеспечения 7.1.4.3.1.5 7.1.5.3.1 Конструирование программного обеспечения 7.1.5.3.1.5 |
|
|
5.5.3 Критерии приемки ПРОГРАММНЫХ БЛОКОВ |
7.1.5 Конструирование программного обеспечения |
7.1.5.3.1 Конструирование программного обеспечения 7.1.5.3.1.5 |
|
|
5.5.4 Дополнительные критерии приемки ПРОГРАММНЫХ БЛОКОВ |
7.1.5 Конструирование программного обеспечения 7.2.4 Верификация программного обеспечения |
7.1.5.3.1 Конструирование программного обеспечения 7.1.5.3.1.2 |
|
|
5.5.5. ВЕРИФИКАЦИЯ ПРОГРАММНЫХ БЛОКОВ |
7.1.5 Конструирование программного обеспечения |
7.1.5.3.1 Конструирование программного обеспечения 7.1.5.3.1.2 |
|
|
5.6 Интеграция программного обеспечения и тестирование интеграции |
5.6.1 Интеграция ПРОГРАММНЫХ БЛОКОВ |
7.1.6 Интеграция программного обеспечения |
7.1.6.3.1 Интеграция программного обеспечения 7.1.6.3.1.2 |
|
5.6.2 Верификация интеграции программного обеспечения |
7.1.6 Интеграция программного обеспечения 6.4.5 Системная интеграция |
7.1.6.3.1 Интеграция программного обеспечения 7.1.6.3.1.2 6.4.5.3.1 Интеграция 6.4.5.3.1.2 |
|
|
5.6.3 Интеграционное тестирование программного обеспечения |
7.1.7 Квалификационное тестирование программного обеспечения |
7.1.7.3.1 Квалификационное тестирование программного обеспечения 7.1.7.3.1.1 |
|
|
5.6.4 Содержание тестирования интеграции программного обеспечения |
7.1.7 Квалификационное тестирование программного обеспечения |
7.1.7.3.1 Квалификационное тестирование программного обеспечения 7.1.7.3.1.3 |
|
|
5.6.5 Оценивание процедур тестирования интеграции программного обеспечения |
Нет |
Нет |
|
|
5.6.6 Проведение регрессионного тестирования |
7.1.6 Интеграция программного обеспечения |
7.1.6.3.1 Интеграция программного обеспечения 7.1.6.3.1.2 |
|
|
5.6.7 Содержание записей в отношении регрессионного тестирования |
7.1.6 Интеграция программного обеспечения |
7.1.6.3.1 Интеграция программного обеспечения 7.1.6.3.1.2 |
|
|
5.6.8 Использование ПРОЦЕССА решения проблем с программным обеспечением |
7.2.4 Верификация программного обеспечения |
7.2.4.3.1 Реализация процесса 7.2.4.3.1.6 |
|
|
5.7 Тестирование ПРОГРАММНОЙ СИСТЕМЫ |
5.7.1 Установление тестирования в отношении требований к программному обеспечению |
7.1.6 Интеграция программного обеспечения 7.1.7 Квалификационное тестирование программного обеспечения |
7.1.6.3.1 Интеграция программного обеспечения 7.1.6.3.1.4 7.1.7.3.1 Квалификационное тестирование программного обеспечения 7.1.7.3.1.1 |
|
5.7.2 Применение ПРОЦЕССА решения проблем с программным обеспечением |
7.2.4 Верификация программного обеспечения |
7.2.4.3.1 Реализация процесса 7.2.4.3.1.6 |
|
|
5.7.3 Повторное тестирование после внесения изменений |
7.2.8 Процесс решения проблем в программном обеспечении |
7.2.4.3.1 Реализация процесса 7.2.4.3.1.1 |
|
|
5.7.4 Оценивание тестирования ПРОГРАММНОЙ СИСТЕМЫ |
7.1.7 Квалификационное тестирование программного обеспечения |
7.1.7.3.1 Квалификационное тестирование программного обеспечения 7.1.7.3.1.3 |
|
|
5.7.5 Содержание отчета по тестированию ПРОГРАММНОЙ СИСТЕМЫ |
7.1.7 Квалификационное тестирование программного обеспечения |
7.1.7.3.1 Квалификационное тестирование программного обеспечения 7.1.7.3.1.1 |
|
|
5.8 Выпуск программного обеспечения на системном уровне |
5.8.1 Обеспечение завершенности ВЕРИФИКАЦИИ программного обеспечения |
6.4.9 Функционирование программного обеспечения 7.2.2 Менеджмент конфигурации программного обеспечения |
6.4.9.3.2 Активация и проверка функционирования 6.4.9.3.2.1 6.4.9.3.2.2 7.2.2.3.6 Поставка и менеджмент выпуска 7.2.2.3.6.1 |
|
5.8.2 Документирование известных остаточных АНОМАЛИЙ | |||
|
5.8.3 ОЦЕНИВАНИЕ известных остаточных АНОМАЛИЙ | |||
|
5.8.4 Документирование выпущенных ВЕРСИЙ |
7.2.2 Процесс менеджмента конфигурации программного обеспечения |
7.2.2.3.6 Поставка и менеджмент выпуска 7.2.2.3.6.1 |
|
|
5.8.5 Документирование создания выпущенного программного обеспечения | |||
|
5.8.6 Обеспечение полного завершения деятельности и задач | |||
|
5.8.7 Архивирование программного обеспечения | |||
|
5.8.8 Обеспечение надежной поставки выпущенного программного обеспечения | |||
|
6 Техническая поддержка программного обеспечения |
6.4.10 Процесс технической поддержки программного обеспечения |
||
|
6.1 Установление плана технической поддержки программного обеспечения |
|
6.4.10 Техническая поддержка программного обеспечения |
Нет |
|
6.2 Анализ модификации и проблем |
6.2.1 Документирование и оценивание обратной связи |
Нет |
Нет |
|
6.2.1.1 Мониторинг обратной связи |
6.4.10 Техническая поддержка программного обеспечения |
Нет |
|
|
6.2.1.2 Документирование и ОЦЕНИВАНИЕ обратной связи |
6.4.10 Техническая поддержка программного обеспечения |
Нет |
|
|
6.2.1.3 ОЦЕНИВАНИЕ влияния ОТЧЕТОВ О ПРОБЛЕМАХ на БЕЗОПАСНОСТЬ |
6.4.10 Техническая поддержка программного обеспечения |
Нет |
|
|
6.2.2 Использование ПРОЦЕССА решения проблем программного обеспечения |
6.4.10 Техническая поддержка программного обеспечения |
Нет |
|
|
6.2.3 Анализ ЗАПРОСОВ НА ИЗМЕНЕНИЕ |
6.4.10 Техническая поддержка программного обеспечения |
Нет |
|
|
6.2.4 Одобрение ЗАПРОСА НА ИЗМЕНЕНИЕ |
6.4.10 Техническая поддержка программного обеспечения |
Нет |
|
|
6.2.5 Информирование пользователей и регулирующих органов |
6.4.10 Техническая поддержка программного обеспечения |
Нет |
|
|
6.3 Осуществление модификации |
|
Нет |
Нет |
|
6.3.1 Использование установленного ПРОЦЕССА осуществления модификации |
6.4.10 Техническая поддержка программного обеспечения |
Нет |
|
|
6.3.2 Повторный выпуск модифицированной ПРОГРАММНОЙ СИСТЕМЫ |
7.2.2 Процесс менеджмента конфигурации программного обеспечения |
Нет |
|
|
7 ПРОЦЕСС МЕНЕДЖМЕНТА РИСКА программного обеспечения |
6.3.4 Процесс менеджмента риска Основан на ISO/IEC 16085. Несмотря на некоторую общность, в нем не рассмотрены конкретные требования к разработке программного обеспечения медицинских изделий в отношении менеджмента риска |
||
|
8 ПРОЦЕСС менеджмента конфигурации программного обеспечения |
|
||
|
8.1 Идентификация конфигурации |
8.1.1 Установление средств идентификации СОСТАВНЫХ ЧАСТЕЙ КОНФИГУРАЦИИ |
7.2.2 Процесс менеджмента конфигурации программного обеспечения |
Нет |
|
8.1.2 Идентификация ПОНП |
Нет |
Нет |
|
|
8.1.3 Идентификация документации конфигурации СИСТЕМЫ |
7.2.2 Процесс менеджмента конфигурации программного обеспечения |
Нет |
|
|
8.2 Управление изменениями |
8.2.1 Одобрение ЗАПРОСОВ НА ИЗМЕНЕНИЯ |
7.2.2 Процесс менеджмента конфигурации программного обеспечения |
Нет |
|
8.2.2 Осуществление изменений |
6.4.10 Техническая поддержка программного обеспечения |
Нет |
|
|
8.2.3 ВЕРИФИКАЦИЯ изменений |
7.2.2 Процесс менеджмента конфигурации программного обеспечения |
Нет |
|
|
8.2.4 Обеспечение средствами для ПРОСЛЕЖИВАЕМОСТИ изменений | |||
|
8.3 Учет статуса конфигурации |
|
7.2.2 Процесс менеджмента конфигурации программного обеспечения |
Нет |
|
9 ПРОЦЕСС решения проблем программного обеспечения |
|
||
|
9.1 Подготовка ОТЧЕТОВ О ПРОБЛЕМАХ |
|
7.2.8 Процесс решения проблем в программном обеспечении |
Нет |
|
9.2 Исследование проблемы |
|
7.2.8 Процесс решения проблем в программном обеспечении |
Нет |
|
9.3 Консультирование заинтересованных сторон |
|
7.2.8 Процесс решения проблем в программном обеспечении |
Нет |
|
9.4 Использование процесса управления изменениями |
|
7.2.2 Процесс менеджмента конфигурации программного обеспечения 6.4.10 Техническая поддержка программного обеспечения |
Нет |
|
9.5 Поддержание записей |
|
7.2.8 Процесс решения проблем в программном обеспечении |
Нет |
|
9.6 Анализ проблем на предмет выявления тенденций |
|
7.2.8 Процесс решения проблем в программном обеспечении |
Нет |
|
9.7 ВЕРИФИКАЦИЯ решения проблем программного обеспечения |
|
7.2.8 Процесс решения проблем в программном обеспечении |
Нет |
|
9.8 Содержание документации по тестированию |
|
ISO 12207 требует документирования всех ЗАДАЧ проведения тестирования |
Нет |
C.7 Взаимосвязь с IEC 61508
В результате рассмотрения вопроса об использовании в настоящем стандарте, применяемом в отношении критически важного для БЕЗОПАСНОСТИ программного обеспечения, принципов IEC 61508, были учтены следующие соображения. Подход к безопасности в IEC 62304 принципиально отличается от подхода в IEC 61508. IEC 62304 учитывает, что результативность медицинских изделий оправдывает существование остаточных рисков, связанных с их применением. Позицию настоящего стандарта объясняет следующее.
IEC 61508 сфокусирован на трех главных вопросах:
1) жизненном цикле МЕНЕДЖМЕНТА РИСКА и ПРОЦЕССАХ жизненного цикла;
2) определении уровней безопасности эксплуатации оборудования;
3) рекомендуемых техниках, инструментах и методах для разработки программного обеспечения и уровнях независимости персонала, ответственного за выполнение различных ЗАДАЧ.
Вопрос 1) включен в настоящий стандарт нормативной ссылкой на ISO 14971 (стандарт по МЕНЕДЖМЕНТУ РИСКА для промышленности МЕДИЦИНСКИХ ИЗДЕЛИЙ). Влияние этой ссылки состоит в том, чтобы адаптировать подход ISO 14971 к МЕНЕДЖМЕНТУ РИСКА как составную часть ПРОЦЕССА программного обеспечения для ПО МЕДИЦИНСКИХ ИЗДЕЛИЙ.
Для вопроса 2) настоящий стандарт принимает более простой подход, чем IEC 61508, классифицирующий программное обеспечение на четыре "уровня безопасности эксплуатации оборудования", определенные с точки зрения надежности. Цели надежности идентифицируют после АНАЛИЗА РИСКА, который определяет как тяжесть, так и вероятность причинения ВРЕДА, вызванного отказом ПО.
Настоящий стандарт упрощает вопрос 2) посредством установления классификации по трем классам безопасности программного обеспечения на основе РИСКА, вызванного отказом. После классификации для разных классов безопасности программного обеспечения требуются разные ПРОЦЕССЫ: намерение состоит в дальнейшем уменьшении вероятности (и/или тяжести последствий) отказа программного обеспечения.
Вопрос 3) не затронут в настоящем стандарте. Пользователям рекомендуется применять IEC 61508 в качестве источника программных методов, техник и инструментов, с учетом того, что другие подходы могут обеспечить одинаковые РЕЗУЛЬТАТЫ. Настоящий стандарт не содержит рекомендаций относительно независимости лиц, ответственных за один вид ДЕЯТЕЛЬНОСТИ в области программного обеспечения (например, за ВЕРИФИКАЦИЮ) от тех, кто отвечает за другой (например, за проектирование). В частности, настоящий стандарт не требует наличия независимого эксперта по безопасности, поскольку это относится к ISO 14971.