ГОСТ IEC 62304-2022 Изделия медицинские. Программное обеспечение. Процессы жизненного цикла

Краткое наименование страны по МК (ИСО 3166) 004-97

Код страны по МК (ИСО 3166) 004-97

Сокращенное наименование национального органа по стандартизации

Беларусь

BY

Госстандарт Республики Беларусь

Киргизия

KG

Кыргызстандарт

Россия

RU

Росстандарт

Узбекистан

UZ

Узстандарт

Настоящий стандарт определяет основу ПРОЦЕССОВ жизненного цикла совместно с ДЕЯТЕЛЬНОСТЬЮ и ЗАДАЧАМИ, необходимыми для проектирования и технической поддержки (обслуживания) безопасного ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ МЕДИЦИНСКИХ ИЗДЕЛИЙ. Настоящий стандарт определяет требования для каждого

ПРОЦЕССА жизненного цикла. Каждый ПРОЦЕСС жизненного цикла состоит из совокупности видов ДЕЯТЕЛЬНОСТИ, причем большинство видов ДЕЯТЕЛЬНОСТИ, в свою очередь, состоят из набора ЗАДАЧ.

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

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

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

Введение к поправке 1

Первое издание стандарта IEC 62304 было опубликовано в 2006 году. Настоящая поправка предназначена для добавления требований к УСТАРЕВШЕМУ/НАСЛЕДУЕМОМУ ПРОГРАММНОМУ ОБЕСПЕЧЕНИЮ, где разработка программного обеспечения является предыдущей к существующей текущей версии, с целью оказания помощи изготовителям продемонстрировать соответствие настоящему стандарту для соответствия Европейским директивам. Изменения в классификации безопасности программного обеспечения, внесенные настоящей поправкой, включают уточнение требований и обновление классификации безопасности программного обеспечения с целью применения риск-ориентированного подхода. Параллельно продолжается работа по разработке второго издания IEC 62304.

Примечание 1 - Настоящий стандарт может применяться при разработке и обслуживании программного обеспечения, которое само по себе является медицинским изделием. Однако, прежде чем этот тип программного обеспечения может быть введен в эксплуатацию, необходимо осуществить дополнительную деятельность по разработке на системном уровне. Эта системная деятельность не входит в область применения настоящего стандарта, но ее описание приведено в IEC 82304-1 [22].

Настоящий стандарт описывает ПРОЦЕССЫ, предназначенные для применения к программному обеспечению, которое выполняется на процессоре или другим программным обеспечением (например, интерпретатором), выполняемым на процессоре.

Настоящий стандарт применяется независимо от устройства (устройств) постоянного хранения, используемого(ых) для хранения программного обеспечения (например: жесткий диск, оптический диск, постоянная или флеш-память).

Настоящий стандарт применяется независимо от способа доставки программного обеспечения (например: передача по сети или электронной почте, оптический диск, флеш-память или EEPROM). Сам способ доставки программного обеспечения не считается ПРОГРАММНЫМ ОБЕСПЕЧЕНИЕМ МЕДИЦИНСКИХ ИЗДЕЛИЙ.

Примечание 2 - Если медицинское изделие включает встроенное программное обеспечение, предназначенное для работы на процессоре, то к программному обеспечению применяются требования настоящего стандарта, включая требования, касающиеся программного обеспечения неизвестного происхождения (см. 8.1.2).

Примечание 3 - Валидацию и другую деятельность по разработке необходимо проводить на системном уровне, прежде чем программное обеспечение и медицинское изделие могут быть введены в эксплуатацию. Эта системная деятельность не входит в область применения настоящего стандарта, но ее описание приведено в соответствующих стандартах на продукцию (например, IEC 60601-1, IEC 82304-1 и т.д.).

Соответствие устанавливается посредством проверки всей документации,

требуемой настоящим стандартом, включая ФАЙЛ МЕНЕДЖМЕНТА РИСКА, и оценки ПРОЦЕССОВ, ДЕЯТЕЛЬНОСТИ и ЗАДАЧ, требуемых согласно классу безопасности программного обеспечения.

Примечание 5 - Соответствие УСТАРЕВШЕГО/УНАСЛЕДОВАННОГО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ см. в подразделе 4.4 настоящего стандарта.

3.2 АНОМАЛИЯ (ANOMALY): Любое условие или состояние, которое отклоняется от ожиданий, основанных на требованиях спецификаций, проектно-конструкторских документов, стандартов и т.д., либо от чьего-то восприятия или опыта. АНОМАЛИИ могут

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

Примечание - Основано на IEEE 1044:1993, определение 3.1.

3.4 ЗАПРОС НА ИЗМЕНЕНИЕ (CHANGE REQUEST): Документированная спецификация изменения, которое будет сделано в ПРОГРАММНОМ ОБЕСПЕЧЕНИИ МЕДИЦИНСКОГО ИЗДЕЛИЯ.

Примечание - Основано на ISO/IEC 12207:2008, 4.7.

[ISO/IEC 12207:2008, 4.12]

[ISO 14971:2007 2.2]

[ISO 14971:2007 2.3]

Примечание 1 - К определению изготовителя могут применяться положения национального или регионального регулирования.

Примечание 2 - Определение маркировки см. в ISO 13485:2003, определение 3.6.

[ISO 14971:2007, 2.8]

Примечание 3 - В сочетании с IEC 60601-1:2005 и IEC 60601-1:2005/AMD1:2012 термин "медицинское изделие" имеет то же значение, что и ME ОБОРУДОВАНИЕ или ME СИСТЕМА (которые определены терминами IEC 60601-1).

3.12 ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ МЕДИЦИНСКОГО ИЗДЕЛИЯ (MEDICAL DEVICE SOFTWARE): ПРОГРАММНАЯ СИСТЕМА, разработанная как составная часть

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

Примечание - В это определение входит МЕДИЦИНСКОЕ ИЗДЕЛИЕ - программный продукт, который сам по себе является МЕДИЦИНСКИМ ИЗДЕЛИЕМ.

3.13 ОТЧЕТ О ПРОБЛЕМАХ (PROBLEM REPORT): Запись о фактическом или

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

противоречит спецификации.

Примечание 1 - Настоящий стандарт не требует, чтобы каждый ОТЧЕТ О

ПРОБЛЕМАХ приводил к изменениям в ПРОГРАММНОМ ОБЕСПЕЧЕНИИ МЕДИЦИНСКОГО ИЗДЕЛИЯ. ИЗГОТОВИТЕЛЬ может отклонить ОТЧЕТ О ПРОБЛЕМАХ для неверно понятого, ошибочного или несущественного события.

Примечание 2 - ОТЧЕТ О ПРОБЛЕМАХ может относиться к готовому ПРОГРАММНОМУ ОБЕСПЕЧЕНИЮ МЕДИЦИНСКОГО ИЗДЕЛИЯ или к ПРОГРАММНОМУ ОБЕСПЕЧЕНИЮ МЕДИЦИНСКОГО ИЗДЕЛИЯ, еще находящемуся в процессе разработки.

[ISO 14971:2007 2.16]

[ISO 14971:2007 2.17]

[ISO 14971:2007 2.19]

[ISO 14971:2007, 2.12, модифицировано - Фраза "и мониторинга" была удалена]

[ISO 14971:2007 2.23]

[ISO 14971:2007 2.24]

3.22 ЗАЩИЩЕННОСТЬ (SECURITY): Защита информации и данных от чтения или изменения их посторонними лицами или системами таким образом, чтобы авторизованным лицам и системам доступ к ним не был запрещен.

Примечание - Основано на ISO/IEC 12207:2008, 4.39.

3.23 СЕРЬЕЗНАЯ ТРАВМА (SERIOUS INJURY): Повреждение или заболевание, которое:

3.24 МОДЕЛЬ ЖИЗНЕННОГО ЦИКЛА РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

(SOFTWARE DEVELOPMENT LIFE CYCLE MODEL): Концептуальная структура, охватывающая существование программного обеспечения от определения требований до выпуска программного обеспечения, которая:

- определяет ПРОЦЕССЫ, ДЕЯТЕЛЬНОСТЬ И ЗАДАЧИ, включенные в разработку ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ МЕДИЦИНСКОГО ИЗДЕЛИЯ;

3.25 ПРОГРАММНАЯ СОСТАВНАЯ ЧАСТЬ (SOFTWARE ITEM): Любая идентифицируемая

(выделяемая) часть компьютерной программы, т.е. исходный код, объектный код, управляющий код, управляющие данные или набор этих элементов.

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

Ответственность за обеспечение степени детализации ПРОГРАММНЫХ СОСТАВНЫХ

ЧАСТЕЙ и ПРОГРАММНЫХ БЛОКОВ возлагается на ИЗГОТОВИТЕЛЯ.

Примечание 2 - Основано на ISO/IEC 90003:2004, 3.14 и ISO/IEC 12207:2008, 4.41.

3.26 е используется.

Примечание - Уровень детализации ПРОГРАММНЫХ БЛОКОВ определяется ИЗГОТОВИТЕЛЕМ (см. B.3).

3.29 ПОНП Программное Обеспечение Неизвестного Происхождения (аббревиатура) (SOUP software of unknown provenance (acronym)): ПРОГРАММНАЯ СОСТАВНАЯ ЧАСТЬ, которая уже разработана и общедоступна, но не была предназначена для включения в состав МЕДИЦИНСКОГО ИЗДЕЛИЯ (также известное как "готовое ПО")

или ПРОГРАММНАЯ СОСТАВНАЯ ЧАСТЬ, разработанная ранее, для которой недоступны

требуемые записи ПРОЦЕССОВ разработки.

Примечание - ПРОГРАММНАЯ СИСТЕМА МЕДИЦИНСКОГО ИЗДЕЛИЯ сама по себе не может считаться ПОНП.

Примечание - Основано на ISO/IEC 12207:2008, 4.48.

Примечание - Требования, архитектура, меры по управлению риском и т.д. являются примерами поставляемых результатов ПРОЦЕССА разработки.

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

Примечание 2 - Основано на ISO/IEC 12207:2008, 4.56.

3.35 ОПАСНАЯ СИТУАЦИЯ (HAZARDOUS SITUATION): Обстоятельство, при котором люди, имущество или окружающая среда подвергаются воздействию одной или нескольких ОПАСНОСТЕЙ.

[ИСТОЧНИК: ISO 14971:2007, 2.4]

3.36 УСТАРЕВШЕЕ [НАСЛЕДУЕМОЕ] ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ (LEGACY SOFTWARE): ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ МЕДИЦИНСКОГО ИЗДЕЛИЯ, которое было легально выпущено в обращение и по-прежнему доступно на рынке, но для которого недостаточно объективных свидетельств того, что оно было разработано в соответствии с текущей версией настоящего стандарта.

3.37 ВЫПУСК (RELEASE): Конкретная ВЕРСИЯ СОСТАВНОЙ ЧАСТИ КОНФИГУРАЦИИ, доступная для определенной цели.

Примечание - Основано на ISO/IEC 12207:2008, определение 4.35.

3.38 ОСТАТОЧНЫЙ РИСК (RESIDUAL RISK): РИСК, остающийся после выполнения мер ПО УПРАВЛЕНИЮ РИСКОМ.

Примечание 1 - Адаптировано из ISO/IEC Guide 51:1999, определение 3.9.

Примечание 2 - ISO/IEC Guide 51:1999, определение 3.9 использует термин "защитные меры", а не "меры по УПРАВЛЕНИЮ РИСКОМ". Однако в контексте настоящего стандарта "защитные меры" являются лишь одним из вариантов управления РИСКОМ, как описано в 6.2 [ISO 14971:2007].

[ISO 14971:2007, 2.15]

3.39 ОПРЕДЕЛЕНИЕ РИСКА (RISK ESTIMATION): ПРОЦЕСС, применяемый для присвоения значений вероятности возникновения ВРЕДА и тяжести этого ВРЕДА.

[ISO 14971:2007, 2.20]

3.40 ОЦЕНИВАНИЕ РИСКА (RISK EVALUATION): ПРОЦЕСС сравнения РИСКА, который уже определен, с установленными критериями РИСКА для установления допустимости РИСКА.

[ISO 14971:2007, 2.21]

а) ИЗГОТОВИТЕЛЬ должен присвоить каждой ПРОГРАММНОЙ СИСТЕМЕ класс безопасности программного обеспечения (A, B или C) согласно РИСКУ причинения ВРЕДА пациенту, пользователю или иным лицам, исходя из ОПАСНОЙ СИТУАЦИИ, в которую ПРОГРАММНАЯ СИСТЕМА может внести свой вклад в наихудшем сценарии, как показано на рисунке 3.

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

ПРОГРАММНАЯ СИСТЕМА относится к классу безопасности программного обеспечения A, если:

- ПРОГРАММНАЯ СИСТЕМА не может способствовать возникновению ОПАСНОЙ СИТУАЦИИ;

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

- ПРОГРАММНАЯ СИСТЕМА относится к классу безопасности программного обеспечения B, если:

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

ПРОГРАММНАЯ СИСТЕМА относится к классу безопасности программного обеспечения C, если:

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

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

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

Примечание 2 - Определение допустимости риска см. в подразделе 3.2 "Ответственность руководства" ISO 14971:2007.

b) Не используется.

d) Если ПРОГРАММНАЯ СИСТЕМА подразделяется на ПРОГРАММНЫЕ СОСТАВНЫЕ ЧАСТИ и в дальнейшем ПРОГРАММНЫЕ СОСТАВНЫЕ ЧАСТИ в свою очередь подразделяются на ПРОГРАММНЫЕ СОСТАВНЫЕ ЧАСТИ, то такие ПРОГРАММНЫЕ СОСТАВНЫЕ ЧАСТИ должны наследовать класс безопасности первоначальной ПРОГРАММНОЙ СОСТАВНОЙ ЧАСТИ (или ПРОГРАММНОЙ СИСТЕМЫ), если только ИЗГОТОВИТЕЛЬ не обосновывает в документации присвоение другого класса безопасности программного обеспечения (классы безопасности программного

обеспечения, присвоенные в соответствии с подразделом 4.3 a), заменяя "ПРОГРАММНУЮ СИСТЕМУ" на "ПРОГРАММНЫЕ СОСТАВНЫЕ ЧАСТИ"). Это обоснование должно объяснять, почему ПРОГРАММНЫЕ СОСТАВНЫЕ ЧАСТИ являются

изолированными настолько, что могут классифицироваться отдельно.

f) Для соответствия настоящему стандарту там, где настоящий стандарт применяется к группе ПРОГРАММНЫХ СОСТАВНЫХ ЧАСТЕЙ, ИЗГОТОВИТЕЛЬ должен использовать

ПРОЦЕССЫ и ЗАДАЧИ, которые требуются для классификации ПРОГРАММНОЙ СОСТАВНОЙ ЧАСТИ с наивысшей категорией из всей группы, если только ИЗГОТОВИТЕЛЬ в ФАЙЛЕ МЕНЕДЖМЕНТА РИСКА не приводит документированные обоснования для использования более низкой классификации.

Примечание - В последующих разделах и подразделах классы безопасности программного обеспечения, к которым применяется конкретное требование, определяются в соответствии с требованием в форме [Класс...].

4.4* УСТАРЕВШЕЕ/НАСЛЕДУЕМОЕ ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ

4.4.1 Общие сведения

В качестве альтернативы применению разделов 5-9 настоящего стандарта соответствие УСТАРЕВШЕГО/НАСЛЕДУЕМОГО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ может быть продемонстрировано, как указано в 4.4.2-4.4.5.

4.4.2 Деятельность по МЕНЕДЖМЕНТУ РИСКА

В соответствии с 4.2 настоящего стандарта ИЗГОТОВИТЕЛЬ должен:

a) оценить любую обратную связь, включая постпроизводственную информацию, об УСТАРЕВШЕМ ПРОГРАММНОМ ОБЕСПЕЧЕНИИ, касающуюся инцидентов и/или близких к ним ситуаций как внутри своей организации, так и/или от пользователей;

b) выполнить ДЕЯТЕЛЬНОСТЬ по УПРАВЛЕНИЮ РИСКОМ, связанную с продолжением использования УСТАРЕВШЕГО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ, с учетом следующих аспектов:

- интеграции УСТАРЕВШЕГО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ в общую архитектуру МЕДИЦИНСКОГО ИЗДЕЛИЯ;

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

- идентификации ОПАСНЫХ СИТУАЦИЙ, связанных с продолжением использования УСТАРЕВШЕГО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ;

- идентификации потенциальных причин, по которым УСТАРЕВШЕЕ ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ может привести к возникновению ОПАСНОЙ СИТУАЦИИ;

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

4.4.3 Анализ несоответствия ожидаемых и реализованных результатов

Основываясь на классе безопасности УСТАРЕВШЕГО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ (см. 4.3), ИЗГОТОВИТЕЛЬ должен провести анализ несоответствия ожидаемых и реализованных ПОСТАВЛЕННЫХ РЕЗУЛЬТАТОВ по сравнению с теми, которые требуются в соответствии с 5.2, 5.3, 5.7 и разделом 7.

a) ИЗГОТОВИТЕЛЬ должен оценить непрерывную пригодность полученных РЕЗУЛЬТАТОВ.

b) В случае идентификации несоответствий ожидаемых и реализованных результатов ИЗГОТОВИТЕЛЬ должен ОЦЕНИТЬ возможное снижение РИСКА в результате получения отсутствующих РЕЗУЛЬТАТОВ и связанной с ними ДЕЯТЕЛЬНОСТИ.

c) На основе этого оценивания ИЗГОТОВИТЕЛЬ должен определить РЕЗУЛЬТАТЫ, которые должны быть получены, а также связанную с ними ДЕЯТЕЛЬНОСТЬ, которая должна быть выполнена. Минимальным ПОСТАВЛЯЕМЫМ РЕЗУЛЬТАТОМ должны быть записи тестирования ПРОГРАММНЫХ СИСТЕМ (см. 5.7.5).

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

4.4.4 Деятельность по устранению несоответствий ожидаемых и реализованных результатов

а) ИЗГОТОВИТЕЛЬ должен разработать и выполнить план по созданию идентифицированных ПОСТАВЛЯЕМЫХ РЕЗУЛЬТАТОВ. Там, где это возможно, объективные свидетельства могут быть использованы для формирования требуемых ПОСТАВЛЯЕМЫХ РЕЗУЛЬТАТОВ без выполнения ДЕЯТЕЛЬНОСТИ, установленной в 5.2, 5.3, 5.7 и разделе 7.

Примечание - План устранения идентифицированных несоответствий ожидаемых и реализованных результатов может быть включен в план технической поддержки программного обеспечения (см. 6.1).

б) План должен предусматривать использование ПРОЦЕССА решения проблем для обработки проблем, обнаруженных в УСТАРЕВШЕМ ПРОГРАММНОМ ОБЕСПЕЧЕНИИ и ПОСТАВЛЯЕМЫХ РЕЗУЛЬТАТАХ, в соответствии с Разделом 9.

в) Изменения в УСТАРЕВШЕМ ПРОГРАММНОМ ОБЕСПЕЧЕНИИ должны быть выполнены в соответствии с разделом 6.

4.4.5 Обоснование использования УСТАРЕВШЕГО/НАСЛЕДУЕМОГО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

ИЗГОТОВИТЕЛЬ должен задокументировать ВЕРСИЮ УСТАРЕВШЕГО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ вместе с обоснованием дальнейшего использования УСТАРЕВШЕГО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ на основе результатов 4.4.

Примечание - Выполнение 4.4 позволяет в дальнейшем использовать УСТАРЕВШЕЕ ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ в соответствии с IEC 62304.

e) решение проблем с программным обеспечением для обработки проблем,

обнаруженных в ПРОГРАММНОМ ОБЕСПЕЧЕНИИ МЕДИЦИНСКОГО ИЗДЕЛИЯ,

ПОСТАВЛЯЕМЫХ РЕЗУЛЬТАТАХ и ДЕЯТЕЛЬНОСТИ на каждой стадии жизненного цикла. [Классы A, B, C]

b) В план разработки программного обеспечения ИЗГОТОВИТЕЛЬ должен включать или ссылаться на процедуры по координации разработки программного обеспечения с разработкой системы, необходимой для выполнения требований 4.1 (например, системная интеграция, верификация и валидация). [Классы A, B, C]

Примечание 1 - Допускается объединение тестирования интеграции и тестирования ПРОГРАММНОЙ СИСТЕМЫ в единые план и совокупность ДЕЯТЕЛЬНОСТИ.

Примечание 2 - См. 5.6.

c) процедуры и ответственность за разработку, анализ, одобрение и модификацию. [Классы A, B, C]

Примечание - Информация для рассмотрения менеджмента конфигурации документации приведена в разделе 8.

Примечание - См. раздел 8.

Примечание 1 - Примеры подобных элементов включают компиляторные/ассемблерные версии, созданные файлы, командные файлы и специфичные настройки окружения.

Примечание 2 - См. раздел 8.

ИЗГОТОВИТЕЛЬ должен запланировать размещение СОСТАВНОЙ ЧАСТИ

КОНФИГУРАЦИИ под управление менеджмента конфигурации прежде, чем они будут ВЕРИФИЦИРОВАНЫ. [Классы B, C]

5.1.12 Идентификация и предотвращение распространенных дефектов программного обеспечения

ИЗГОТОВИТЕЛЬ должен включить или указать в плане разработки программного обеспечения процедуру:

а) для определения категорий дефектов, которые могут быть введены на основе выбранной технологии программирования и имеют отношение к их ПРОГРАММНОЙ СИСТЕМЕ;

б) документирования свидетельств, демонстрирующих неспособность этих дефектов приводить к недопустимому РИСКУ.

Примечание - Примеры категорий дефектов или причин, способствующих возникновению ОПАСНЫХ СИТУАЦИЙ, см. в приложении B из IEC/TR 80002-1:2009.

[Классы B, C]

- система безопасности/защита от взлома;

f) требования пользовательского интерфейса, реализованные в программном обеспечении.

Примечание 5 - Информацию относительно требований к разработке удобства и

простоты использования (эксплуатационной пригодности) можно найти в IEC 62366-1 [21] среди прочих стандартов (например, IEC 60601-1-6 [3]);

j) требования, связанные с аспектами информационных сетей.

Примечание 9 - Примеры включают аспекты, которые связаны:

- с сетевыми сигналами тревоги, предупреждения и сообщения оператора;

- сетевыми протоколами;

- обработкой недоступности сетевых услуг;

Примечание 10 - Требования с a) до I) могут пересекаться.

Примечание 12 - Среди прочих, ISO/IEC 25010 [12] приводит информацию о

качественных характеристиках, которая может быть полезна при определении требований к программному обеспечению.

ИЗГОТОВИТЕЛЬ должен включать меры по УПРАВЛЕНИЮ РИСКОМ,

реализованные в программном обеспечении в требования, соответствующие ПРОГРАММНОМУ ОБЕСПЕЧЕНИЮ МЕДИЦИНСКИХ ИЗДЕЛИЙ. [Классы B, C]

5.2.5 Обновление требований

d) формулируются в терминах, которые позволяют установить критерии тестирования и осуществить тестирование;

ИЗГОТОВИТЕЛЬ должен идентифицировать любую обособленность ПРОГРАММНЫХ СОСТАВНЫХ ЧАСТЕЙ, которая необходима для УПРАВЛЕНИЯ

РИСКОМ, и указать, как обеспечить результативность созданной обособленности. [Класс C]

Примечание - В качестве примера создания обособленности можно привести ПРОГРАММНЫЕ СОСТАВНЫЕ ЧАСТИ, выполняемые на разных процессорах.

Результативность обособленности может быть обеспечена за счет отсутствия общих ресурсов у разных процессоров. Другие способы создания обособленности могут

применяться, когда результативность может быть обеспечена посредством разработки АРХИТЕКТУРЫ программного обеспечения (см. B.4.3).

Примечание - Для выполнения требования a) может быть использован анализ ПРОСЛЕЖИВАЕМОСТИ АРХИТЕКТУРЫ к требованиям по программному обеспечению.

5.4.1 Дробление программного обеспечения на ПРОГРАММНЫЕ БЛОКИ

ИЗГОТОВИТЕЛЬ должен дробить программное обеспечение, пока оно не будет представлено в виде ПРОГРАММНЫХ БЛОКОВ. [Классы B, C]

Примечание - Некоторые ПРОГРАММНЫЕ СИСТЕМЫ далее не могут быть раздроблены.

ИЗГОТОВИТЕЛЬ должен документировать дизайн с достаточной степенью детализации, с целью обеспечения правильной реализации каждого ПРОГРАММНОГО БЛОКА. [Класс C]

ИЗГОТОВИТЕЛЬ должен документировать дизайн любых интерфейсов между ПРОГРАММНЫМ БЛОКОМ и внешними компонентами (аппаратными или программными средствами), а также любых интерфейсов между ПРОГРАММНЫМИ БЛОКАМИ, который должен быть достаточно подробным для правильной реализации каждого ПРОГРАММНОГО БЛОКА и его интерфейсов. [Класс C]

b) не вступает в противоречия с АРХИТЕКТУРОЙ программного обеспечения. [Класс C]

Примечание - Для выполнения требования a) может быть использован анализ ПРОСЛЕЖИВАЕМОСТИ АРХИТЕКТУРЫ к детальному дизайну программного обеспечения.

5.5* Имплементация ПРОГРАММНЫХ БЛОКОВ

ИЗГОТОВИТЕЛЬ должен установить стратегии, методы и процедуры для верификации ПРОГРАММНЫХ БЛОКОВ. Там, где ВЕРИФИКАЦИЯ осуществляется посредством тестирования, правильность процедур проведения тестирования должна быть ОЦЕНЕНА на адекватность. [Классы B, C]

- Нет ли в программном коде противоречий с проектом (дизайном) интерфейса ПРОГРАММНЫХ БЛОКОВ?

ИЗГОТОВИТЕЛЬ должен верифицировать, что ПРОГРАММНЫЕ БЛОКИ были интегрированы в ПРОГРАММНЫЕ СОСТАВНЫЕ ЧАСТИ и/или ПРОГРАММНУЮ СИСТЕМУ в соответствии с планом интеграции (см. 5.1.5), а также сохранить записи, свидетельствующие о проведении такой верификации. [Классы B, C]

Примечание - Данная верификация заключается только в проверке выполнения интеграции в соответствии с планом. Эта ВЕРИФИКАЦИЯ, скорее всего, осуществляется в форме какого-либо контрольного мероприятия.

5.6.3 Интеграционное тестирование программного обеспечения

5.6.4 Содержание тестирования интеграции программного обеспечения

5.6.5 Оценивание процедур тестирования интеграции программного обеспечения

ИЗГОТОВИТЕЛЬ должен ОЦЕНИВАТЬ процедуры тестирования интеграции на адекватность. [Классы B, C]

a) Для проведения тестирования ПРОГРАММНОЙ СИСТЕМЫ ИЗГОТОВИТЕЛЬ

должен установить и выполнить перечень тестов, выраженных как входные данные, ожидаемые результаты, критерии приемки и процедуры, с целью учета и охвата тестированием всех требований к программному обеспечению. [Классы A, B, C]

b) ИЗГОТОВИТЕЛЬ должен ОЦЕНИТЬ адекватность стратегий проведения ВЕРИФИКАЦИИ и тестовых процедур.

ИЗГОТОВИТЕЛЬ должен ввести АНОМАЛИИ, обнаруженные во время испытаний ПРОГРАММНОЙ СИСТЕМЫ, в ПРОЦЕСС решения проблем с программным

обеспечением. [Классы A, B, C]

5.7.4 Оценивание тестирования ПРОГРАММНОЙ СИСТЕМЫ

ИЗГОТОВИТЕЛЬ должен ОЦЕНИТЬ целесообразность стратегий ВЕРИФИКАЦИИ и процедур тестирования.

ИЗГОТОВИТЕЛЬ должен проверить, что:

a) все требования к программному обеспечению были протестированы или иным образом ВЕРИФИЦИРОВАНЫ;

b) ведутся записи по ПРОСЛЕЖИВАЕМОСТИ между требованиями к программному обеспечению и тестами или другой ВЕРИФИКАЦИЕЙ;

c) результаты тестирования соответствуют требуемым критериям приемки.

[Классы A, B, C]

Для обеспечения повторяемости тестов ИЗГОТОВИТЕЛЬ должен документировать:

a) ссылки на конкретные процедуры тестирования с указанием требуемых действий и ожидаемых результатов;

b) результаты тестирования (соответствует, не соответствует и список АНОМАЛИЙ);

c) версию тестируемого программного обеспечения;

d) соответствующие конфигурации тестируемого аппаратного и программного обеспечения;

e) соответствующие средства тестирования;

f) дату выполненного тестирования;

g) идентификацию лица, ответственного за проведение тестирования и запись его результатов.

[Классы A, B, C]

5.8* Выпуск программного обеспечения на системном уровне

ИЗГОТОВИТЕЛЬ до выпуска ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ в обращение должен обеспечить, чтобы ДЕЯТЕЛЬНОСТЬ по ВЕРИФИКАЦИИ всего программного обеспечения была полностью завершена, а результаты были ОЦЕНЕНЫ. [Классы A, B, C]

ИЗГОТОВИТЕЛЬ должен задокументировать все известные остаточные АНОМАЛИИ. [Классы A, B, C]

ИЗГОТОВИТЕЛЬ должен документировать ВЕРСИЮ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ МЕДИЦИНСКОГО ИЗДЕЛИЯ, которая будет выпускаться. [Классы A, B, C]

ИЗГОТОВИТЕЛЬ должен обеспечить выполнение всей ДЕЯТЕЛЬНОСТИ и всех ЗАДАЧ, входящих в состав плана разработки (или плана технической поддержки) программного обеспечения, наряду со связанной с ними документацией. [Классы B, C]

Примечание - См. 5.1.3.b).

a) ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ МЕДИЦИНСКОГО ИЗДЕЛИЯ и СОСТАВНОЙ ЧАСТИ КОНФИГУРАЦИИ;

b) документацию

в течение как минимум срока службы ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ МЕДИЦИНСКОГО ИЗДЕЛИЯ, установленного ИЗГОТОВИТЕЛЕМ, или в течение срока, установленного соответствующими регулирующими требованиями.

[Классы А, В, С]

5.8.8 Обеспечение надежной поставки выпущенного программного обеспечения

ИЗГОТОВИТЕЛЬ должен установить процедуры, обеспечивающие, чтобы выпущенное ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ МЕДИЦИНСКОГО ИЗДЕЛИЯ было поставлено пользователю (к месту его применения) без искажения или несанкционированного изменения. Эти процедуры должны распространяться на производство и обращение со средствами, содержащими ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ МЕДИЦИНСКОГО ИЗДЕЛИЯ, и включать, если применимо:

[Классы A, B, C]

e) использование ПРОЦЕССА менеджмента конфигурации программного

обеспечения (раздел 8) для управления модификациями существующей ПРОГРАММНОЙ СИСТЕМЫ;

ИЗГОТОВИТЕЛЬ должен осуществлять мониторинг обратной связи ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ МЕДИЦИНСКОГО ИЗДЕЛИЯ, выпущенного для использования по назначению. [Классы A, B, C]

Обратная связь должна быть документирована и ОЦЕНЕНА с целью определения существования проблемы в выпущенном ПРОГРАММНОМ ОБЕСПЕЧЕНИИ МЕДИЦИНСКОГО ИЗДЕЛИЯ. Любая

такая проблема должна быть зарегистрирована в ОТЧЕТЕ О ПРОБЛЕМАХ (см. раздел 9). ОТЧЕТ О ПРОБЛЕМАХ должен содержать фактические или возможные неблагоприятные события и отклонения от спецификации. [Классы A, B, C]

Каждый ОТЧЕТ О ПРОБЛЕМАХ должен быть ОЦЕНЕН с целью определения его влияния на БЕЗОПАСНОСТЬ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ МЕДИЦИНСКОГО ИЗДЕЛИЯ, выпущенного для использования по назначению (см. 9.2), и требуется ли изменение этого программного обеспечения для решения проблемы. [Классы A, B, C]

Примечание - Проблема может указывать на то, что ПРОГРАММНАЯ СИСТЕМА или ПРОГРАММНАЯ СОСТАВНАЯ ЧАСТЬ не были правильно отнесены к классу безопасности программного обеспечения. Процесс решения проблемы может состоять в изменении класса безопасности программного обеспечения. После завершения ПРОЦЕССА любое изменение класса безопасности ПРОГРАММНОЙ СИСТЕМЫ или ее ПРОГРАММНОЙ СОСТАВНОЙ ЧАСТИ должно быть известно и документировано.

В дополнение к анализу, требуемому разделом 9, ИЗГОТОВИТЕЛЬ должен анализировать каждый ЗАПРОС НА ИЗМЕНЕНИЕ с целью определения его влияния на организацию, ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ МЕДИЦИНСКОГО ИЗДЕЛИЯ, выпущенного для использования по назначению, и СИСТЕМЫ, с которыми оно взаимодействует. [Классы A, B, C]

ИЗГОТОВИТЕЛЬ должен ОЦЕНИТЬ и одобрить ЗАПРОСЫ НА ИЗМЕНЕНИЯ, которые модифицируют выпущенное ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ

МЕДИЦИНСКОГО ИЗДЕЛИЯ. [Классы A, B, C]

6.2.5 Информирование пользователей и регулирующих органов

ИЗГОТОВИТЕЛЬ должен идентифицировать одобренные ЗАПРОСЫ НА

ИЗМЕНЕНИЯ, которые влияют на выпущенное ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ МЕДИЦИНСКОГО ИЗДЕЛИЯ.

a) о любых проблемах в отношении выпущенного ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ МЕДИЦИНСКОГО ИЗДЕЛИЯ и последствиях длительного использования неизмененного продукта;

b) о характере любых доступных изменений в выпущенном ПРОГРАММНОМ ОБЕСПЕЧЕНИИ МЕДИЦИНСКОГО ИЗДЕЛИЯ и о том, как получить и установить эти изменения.

ИЗГОТОВИТЕЛЬ должен идентифицировать и выполнять любую ДЕЯТЕЛЬНОСТЬ, указанную в разделе 5, которую необходимо повторить в результате модификации. [Классы A, B, C]

ИЗГОТОВИТЕЛЬ должен выпускать модификации согласно 5.8. [Классы A, B, C]

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

выпущенной ПРОГРАММНОЙ СИСТЕМЫ или как набор модификаций, включающий измененные ПРОГРАММНЫЕ СОСТАВНЫЕ ЧАСТИ, а также инструменты, необходимые для установки изменений как модификации существующей ПРОГРАММНОЙ СИСТЕМЫ.

В отношении каждого случая, зарегистрированного в ФАЙЛЕ МЕНЕДЖМЕНТА РИСКА, при котором ПРОГРАММНАЯ СОСТАВНАЯ ЧАСТЬ может способствовать возникновению ОПАСНОЙ СИТУАЦИИ, ИЗГОТОВИТЕЛЬ должен определить и

документировать меры по УПРАВЛЕНИЮ РИСКОМ в соответствии с ISO 14971. [Классы B, C]

b) назначить каждой ПРОГРАММНОЙ СОСТАВНОЙ ЧАСТИ, которая способствует реализации меры по УПРАВЛЕНИЮ РИСКОМ, класс безопасности программного обеспечения, основанный на РИСКЕ, которым управляет данная мера по УПРАВЛЕНИЮ РИСКОМ (см. 4.3 a);

Выполнение каждой меры по УПРАВЛЕНИЮ РИСКОМ, документированной в 7.2, должно быть верифицировано, а сама ВЕРИФИКАЦИЯ должна быть документирована. ИЗГОТОВИТЕЛЬ должен проанализировать меры по УПРАВЛЕНИЮ РИСКАМИ и определить их способность привести к возникновению новой ОПАСНОЙ СИТУАЦИИ.

[Классы B, C]

7.3.2 Документирование любых новых последовательностей событий

Не применяется.

ИЗГОТОВИТЕЛЬ должен установить схему уникальной идентификации подлежащих управлению СОСТАВНЫХ ЧАСТЕЙ КОНФИГУРАЦИИ и их ВЕРСИЙ в соответствии с

планированием разработки и конфигурации, установленной в 5.1. [Классы A, B, C]

[Классы A, B, C]

ИЗГОТОВИТЕЛЬ может изменять СОСТАВНЫЕ ЧАСТИ КОНФИГУРАЦИИ,

идентифицированные как подлежащие управлению согласно 8.1, только после того, как

будет одобрен ЗАПРОС НА ИЗМЕНЕНИЯ. [Классы A, B, C]

Примечание 2 - В отношении ЗАПРОСОВ НА ИЗМЕНЕНИЯ на разных стадиях

жизненного цикла могут использоваться различные ПРОЦЕССЫ одобрения, как это установлено в планах, см. 5.1.1 d) и 6.1 e).

ИЗГОТОВИТЕЛЬ должен поддерживать записи о взаимосвязях и зависимостях между:

[Классы A, B, C]

ИЗГОТОВИТЕЛЬ должен подготовить ОТЧЕТ О ПРОБЛЕМАХ в отношении каждой проблемы, обнаруженной в ПРОГРАММНОМ ОБЕСПЕЧЕНИИ МЕДИЦИНСКОГО ИЗДЕЛИЯ. ОТЧЕТЫ О ПРОБЛЕМАХ должны включать заключение о критичности (например, влияние на функциональные характеристики, БЕЗОПАСНОСТЬ или ЗАЩИЩЕННОСТЬ), а также другую информацию, которая может помочь в решении проблемы (например, затронутые устройства, затронутое вспомогательное оборудование). [Классы A, B, C]

Если применимо, ИЗГОТОВИТЕЛЬ должен обновлять ФАЙЛ МЕНЕДЖМЕНТА

РИСКА. [Классы A, B, C]

- был ли ЗАПРОС НА ИЗМЕНЕНИЯ реализован в соответствующем ПРОГРАММНОМ

ОБЕСПЕЧЕНИИ МЕДИЦИНСКИХ ИЗДЕЛИЙ и ДЕЯТЕЛЬНОСТИ;

Следовательно, для соответствия настоящему стандарту должен быть реализован документированный АНАЛИЗ РИСКОВ, идентифицирующий предсказуемые последовательности событий, связанные с наличием программного обеспечения, которые

могут привести к ОПАСНОЙ СИТУАЦИИ (см. ISO 14971). ОПАСНЫЕ СИТУАЦИИ, которые

могут быть косвенно вызваны программным обеспечением (например, путем предоставления вводящей в заблуждение информации, которая может привести к назначению неверного лечения), должны быть включены в этот АНАЛИЗ РИСКОВ.

Следует отметить, что все ПРОЦЕССЫ и ДЕЯТЕЛЬНОСТЬ, указанные в настоящем стандарте, являются значимыми для обеспечения разработки и технической поддержки высококачественного программного обеспечения. Отсутствие многих из этих ПРОЦЕССОВ и ДЕЯТЕЛЬНОСТИ в качестве требований для ПО класса А не подразумевает, что эти

ПРОЦЕССЫ и ДЕЯТЕЛЬНОСТЬ не являются важными или не рекомендуются. Их

отсутствие оправдано тем, что БЕЗОПАСНОСТЬ и результативность программного

обеспечения, которое не может быть причиной ОПАСНОСТИ, можно обеспечить

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

Пункты и подпункты

Класс A

Класс B

Класс C

Раздел 4

Все требования

X

X

X

5.1

5.1.1, 5.1.2, 5.1.3, 5.1.6, 5.1.7, 5.1.8, 5.1.9

X

X

X

5.1.5, 5.1.10, 5.1.11, 5.1.12

X

X

5.1.4

X

5.2

5.2.1, 5.2.2, 5.2.4, 5.2.5, 5.2.6

X

X

X

5.2.3

X

X

5.3

5.3.1, 5.3.2, 5.3.3, 5.3.4, 5.3.6

X

X

5.3.5

X

5.4

5.4.1

X

X

5.4.2, 5.4.3, 5.4.4

X

Раздел 4

Все требования

X

X

X

5.5

5.5.1

X

X

X

5.5.2, 5.5.3, 5.5.5

X

X

5.5.4

X

5.6

Все требования

X

X

5.7

Все требования

X

X

X

5.8

5.8.1, 5.8.2, 5.8.4, 5.8.7, 5.8.8

X

X

X

5.8.3, 5.8.5, 5.8.6

X

X

6

Все требования

X

X

X

7.1

Все требования

X

X

7.2

Все требования

X

X

7.3

Все требования

X

X

7.4

7.4.1

X

X

X

7.4.2, 7.4.3

X

X

Раздел 8

Все требования

X

X

X

Раздел 9

Все требования

X

X

X

Цель настоящего стандарта состоит в том, чтобы обеспечить ПРОЦЕСС разработки, который позволит последовательно создавать высококачественное и безопасное ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ МЕДИЦИНСКИХ ИЗДЕЛИЙ. Для достижения этой цели настоящий стандарт устанавливает минимальную ДЕЯТЕЛЬНОСТЬ и ЗАДАЧИ, которые необходимо выполнить для уверенности в том, что разработанное таким образом программное обеспечение (далее - ПО) позволяет создавать высоконадежное и

безопасное ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ МЕДИЦИНСКОГО ИЗДЕЛИЯ.

Стратегия разработки

С самого начала определяет все требования?

Многократные циклы разработки?

Поставляет временное программное обеспечение?

Водопад (сквозная)

Да

Нет

Нет

Пошаговая (предварительно запланированное улучшение продукции)

Да

Да

Возможно

Эволюционная

Нет

Да

Да

Использование настоящего стандарта требует от ИЗГОТОВИТЕЛЯ выполнения МЕНЕДЖМЕНТА РИСКА МЕДИЦИНСКИХ ИЗДЕЛИЙ в соответствии с ИСО 14971. Следовательно, когда АРХИТЕКТУРА СИСТЕМЫ МЕДИЦИНСКОГО ИЗДЕЛИЯ включает приобретенный компонент (это может быть закупленный компонент или компонент неизвестного происхождения), такой как принтер/плоттер, который содержит ПОНП, этот приобретенный компонент становится ответственностью ИЗГОТОВИТЕЛЯ и должен быть включен в МЕНЕДЖМЕНТ РИСКА МЕДИЦИНСКИХ ИЗДЕЛИЙ. Считается, что посредством надлежащего выполнения МЕНЕДЖМЕНТА РИСКА МЕДИЦИНСКИХ ИЗДЕЛИЙ ИЗГОТОВИТЕЛЬ поймет этот компонент и признает, что он содержит ПОНП. ИЗГОТОВИТЕЛЬ, применяющий настоящий стандарт, должен

ввести ПРОЦЕСС МЕНЕДЖМЕНТА РИСКА ПО как часть полного ПРОЦЕССА МЕНЕДЖМЕНТА РИСКА МЕДИЦИНСКОГО ИЗДЕЛИЯ.

Техническая поддержка выпущенного ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

МЕДИЦИНСКИХ ИЗДЕЛИЙ относится к постпроизводственному опыту работы с

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

ОБЕСПЕЧЕНИЕМ МЕДИЦИНСКОГО ИЗДЕЛИЯ. Например, это включает исправление

проблемы, регламентированную отчетность, повторную валидацию и предупреждающие действия. См. ISO/IEC 14764 [10].

Для описания декомпозиции ПРОГРАММНОЙ СИСТЕМЫ (высший уровень) настоящий стандарт использует три термина. ПРОГРАММНАЯ СИСТЕМА, которая впоследствии становится программным обеспечением МЕДИЦИНСКОГО ИЗДЕЛИЯ, может быть подсистемой МЕДИЦИНСКОГО ИЗДЕЛИЯ (см. IEC 60601-1-4 [2]) или сама по

себе являться МЕДИЦИНСКИМ ИЗДЕЛИЕМ, которое затем становится программным МЕДИЦИНСКИМ ИЗДЕЛИЕМ. Самым нижним уровнем, ниже которого дальнейшая

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

Вместо того, чтобы пытаться определить подходящий ПРОЦЕСС МЕНЕДЖМЕНТА РИСКА, в настоящем стандарте требуется, чтобы ИЗГОТОВИТЕЛЬ применил установленный в ISO 14971 ПРОЦЕСС МЕНЕДЖМЕНТА РИСКА, который непосредственно относится к МЕНЕДЖМЕНТУ РИСКА для МЕДИЦИНСКИХ ИЗДЕЛИЙ.

Конкретные виды ДЕЯТЕЛЬНОСТИ по МЕНЕДЖМЕНТУ РИСКА ПО, возникающего в

результате ОПАСНЫХ СИТУАЦИЙ, причиной которых является ПО, указана во вспомогательном ПРОЦЕССЕ, описанном в разделе 7.

РИСК рассматривается как комбинация тяжести ВРЕДА и вероятности его возникновения. Не существует общепризнанного метода количественного определения вероятности возникновения отказа программного обеспечения. Если ПО задействовано в последовательности или комбинации событий, приводящих к ОПАСНОЙ СИТУАЦИИ, то вероятность возникновения отказа программного обеспечения не может быть учтена при определении РИСКА от ОПАСНОЙ СИТУАЦИИ. В таких ситуациях целесообразно рассмотреть вероятность наихудшего случая и установить вероятность возникновения отказа ПО равной 1. Если есть возможность определить вероятность для остальных событий в последовательности (что возможно, если они не являются программными), то эта вероятность может быть использована для определения вероятности возникновения ОПАСНОЙ СИТУАЦИИ (P1 на рисунке B.2).

В некоторых случаях невозможно определить вероятность остальных событий в последовательности и РИСК следует ОЦЕНИВАТЬ только на основе характера ВРЕДА (вероятность возникновения ОПАСНОЙ СИТУАЦИИ должна быть установлена равной 1). ОПРЕДЕЛЕНИЕ РИСКА в этих случаях должно быть сосредоточено на ТЯЖЕСТИ ВРЕДА, причиненного в результате ОПАСНОЙ СИТУАЦИИ. Субъективные оценки вероятности могут быть сделаны на основе клинических знаний, чтобы отличить очевидные для медицинского специалиста отказы от тех, которые не будут обнаружены и с большей вероятностью приведут к причинению ВРЕДА.

Определение вероятности возникновения ОПАСНОЙ СИТУАЦИИ, приводящей к ПРИЧИНЕНИЮ ВРЕДА (P2 на рисунке B.2), как правило, требует клинических знаний для проведения разграничения между ОПАСНЫМИ СИТУАЦИЯМИ, в которых клиническая практика вероятней всего предотвратит ВРЕД, и ОПАСНЫМИ СИТУАЦИЯМИ, которые с большей вероятностью приведут к причинению ВРЕДА.

Примечание

Рисунок В.2 - Наглядное представление взаимосвязи ОПАСНОСТИ, последовательности событий, ОПАСНОЙ СИТУАЦИИ и ВРЕДА - заимствовано из ISO 14971:2007, приложение Е

АРХИТЕКТУРА программного обеспечения должна способствовать изоляции программных элементов (составных частей), которые требуются для безопасной работы, и

описывать методы, используемые для обеспечения результативного разделения этих ПРОГРАММНЫХ СОСТАВНЫХ ЧАСТЕЙ. Разделение не ограничивается физической изоляцией (раздел процессора или памяти) и содержит любой механизм, который предотвращает негативное влияние одной ПРОГРАММНОЙ СОСТАВНОЙ ЧАСТИ на другую. Достаточность разделения определяется на основе связанных с этим РИСКОВ и обоснования, которое требуется задокументировать.

В приведенном примере ИЗГОТОВИТЕЛЬ знает благодаря типу разрабатываемого ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ МЕДИЦИНСКОГО ИЗДЕЛИЯ, что ПРОГРАММНАЯ

СИСТЕМА по предварительной классификации безопасности ПО относится к классу C. При проектировании АРХИТЕКТУРЫ ПО ИЗГОТОВИТЕЛЬ решает разделить СИСТЕМУ на три ПРОГРАММНЫЕ СОСТАВНЫЕ ЧАСТИ - X, W и Z. ИЗГОТОВИТЕЛЬ может разделить

весь вклад ПРОГРАММНОЙ СИСТЕМЫ в возникновение ОПАСНЫХ СИТУАЦИЙ на

приводящие к возможной смерти или СЕРЬЕЗНОЙ ТРАВМЕ, в ПРОГРАММНОЙ СОСТАВНОЙ ЧАСТИ Z, и вклад всей оставшейся ПРОГРАММНОЙ СИСТЕМЫ в

ОПАСНЫЕ СИТУАЦИИ, не приводящие к возможной СЕРЬЕЗНОЙ ТРАВМЕ, в

ПРОГРАММНОЙ СОСТАВНОЙ ЧАСТИ W. ПРОГРАММНАЯ СОСТАВНАЯ ЧАСТЬ W классифицируется как класс безопасности B, а ПРОГРАММНАЯ СОСТАВНАЯ ЧАСТЬ Z относится к классу безопасности C. ПРОГРАММНАЯ СОСТАВНАЯ ЧАСТЬ Y, следовательно, должна быть отнесена к классу C (см. 4.3 d). В соответствии с этим требованием ПРОГРАММНАЯ СИСТЕМА также получает класс безопасности C. ПРОГРАММНАЯ СОСТАВНАЯ ЧАСТЬ X относится к классу безопасности A. ИЗГОТОВИТЕЛЬ может документировать обоснование разделения ПРОГРАММНЫХ СОСТАВНЫХ ЧАСТЕЙ X и Y, а также ПРОГРАММНЫХ СОСТАВНЫХ ЧАСТЕЙ W и Z, чтобы обеспечить целостность разделения. Если разделение между ПРОГРАММНЫМИ СОСТАВНЫМИ ЧАСТЯМИ X и Y невозможно, то ПРОГРАММНАЯ СОСТАВНАЯ ЧАСТЬ X должна быть отнесена к классу безопасности C.

В.4.4 Устаревшее/наследуемое ПО

Подраздел 4.4 устанавливает процесс применения настоящего стандарта к УСТАРЕВШЕМУ ПРОГРАММНОМУ ОБЕСПЕЧЕНИЮ. В некоторых регионах может потребоваться, чтобы ИЗГОТОВИТЕЛЬ продемонстрировал соответствие стандарту для получения одобрения регулирующих органов ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ МЕДИЦИНСКОГО ИЗДЕЛИЯ, даже если это программное обеспечение было разработано до появления текущей версии стандарта (УСТАРЕВШЕЕ ПО). В этом случае требования раздела 4.4 предоставляют ИЗГОТОВИТЕЛЮ способ продемонстрировать соответствие УСТАРЕВШЕГО ПО настоящему стандарту.

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

- необходимая ДЕЯТЕЛЬНОСТЬ и итоговая документация должны основываться на существующей документации и использовать ее, где это возможно,

- ИЗГОТОВИТЕЛЬ должен использовать ресурсы для максимально результативного снижения РИСКА.

В дополнение к плану, определяющему подмножество видов ДЕЯТЕЛЬНОСТИ, которые необходимо выполнить, результатом процесса являются объективные свидетельства, подтверждающие безопасное дальнейшее использование УСТАРЕВШЕГО ПО, а также краткое обоснование этого вывода.

РИСКИ, связанные с планируемым продолжением использования УСТАРЕВШЕГО ПО, зависят от контекста, в котором оно будет использоваться для создания ПРОГРАММНОЙ СИСТЕМЫ. ИЗГОТОВИТЕЛЬ будет документировать все выявленные ОПАСНОСТИ МЕДИЦИНСКОГО ИЗДЕЛИЯ, связанные с УСТАРЕВШИМ ПО.

В 4.4 требуется всесторонняя оценка имеющихся постпроизводственных данных, полученных для УСТАРЕВШЕГО ПО за время его производства и применения. Типичные источники данных на стадии постпроизводства включают:

- неблагоприятные события, связанные с изделием,

- отзывы, полученные от пользователей изделия, и

- АНОМАЛИИ, обнаруженные ИЗГОТОВИТЕЛЕМ.

Хотя не существует единого мнения в отношении метода перспективного количественного определения вероятности возникновения отказа программного обеспечения, для УСТАРЕВШЕГО ПО может быть доступна уместная информация по постпроизводству. Если в таких случаях возможно количественно определить вероятность событий в последовательности, то количественное значение может быть использовано для выражения вероятности возникновения всей последовательности событий. Если данная количественная оценка невозможна, целесообразно учитывать вероятность наихудшего случая и принять вероятность возникновения сбоя программного обеспечения равной 1.

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

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

- При повторном использовании УСТАРЕВШЕГО ПО для создания новой ПРОГРАММНОЙ СИСТЕМЫ предполагаемое использование УСТАРЕВШЕГО ПО может отличаться от его первоначального предназначения. В этом случае оценка РИСКА должна учитывать измененный набор ОПАСНЫХ СИТУАЦИЙ, которые могут возникнуть из-за отказов УСТАРЕВШЕГО ПО.

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

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

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

Согласно 4.4 ИЗГОТОВИТЕЛЬ проводит анализ разрывов (пробелов), чтобы определить доступную документацию, включая объективные свидетельства выполненных ЗАДАЧ, созданную во время разработки УСТАРЕВШЕГО ПО, и сравнить ее с 5.2, 5.3, 5.7 и разделом 7. Типичные шаги для выполнения данного анализа разрывов (пробелов) включают:

а) идентификацию УСТАРЕВШЕГО ПО, включая ВЕРСИЮ, редакцию и любые другие средства, необходимые для четкой идентификации;

б) ОЦЕНКУ существующих ПОСТАВЛЯЕМЫХ РЕЗУЛЬТАТОВ, соответствующих результатам, требуемым 5.2, 5.3, 5.7 и разделом 7;

c) ОЦЕНКУ имеющихся объективных свидетельств, документирование ранее применявшейся модели жизненного цикла разработки программного обеспечения (при необходимости);

d) ОЦЕНКУ адекватности существующей документации по МЕНЕДЖМЕНТУ РИСКА с учетом ISO 14971.

Принимая во внимание проведенный анализ разрывов (пробелов), ИЗГОТОВИТЕЛЬ оценит потенциальное снижение РИСКА в результате создания недостающих ПОСТАВЛЯЕМЫХ РЕЗУЛЬТАТОВ и связанной с ними ДЕЯТЕЛЬНОСТИ, а также разработает план выполнения ДЕЯТЕЛЬНОСТИ и создания недостающих пока ПОСТАВЛЯЕМЫХ РЕЗУЛЬТАТОВ для закрытия этих разрывов.

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

Как минимум, план устранения разрывов (пробелов) касается отсутствующих записей тестирования ПРОГРАММНЫХ СИСТЕМ. Если они отсутствуют или не подходят для обоснования продолжения использования УСТАРЕВШЕГО ПО, план устранения разрывов должен включать создание требований к ПРОГРАММНОЙ СИСТЕМЕ на функциональном уровне в соответствии с 5.2 и тестирование в соответствии с 5.7.

Документированное обоснование дальнейшего использования УСТАРЕВШЕГО ПО основывается на имеющихся объективных свидетельствах и результатах анализа, полученных в ходе оценки РИСКА и разработки плана устранения разрывов, соответствующих контексту повторного использования УСТАРЕВШЕГО ПО.

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

После повторного использования УСТАРЕВШЕГО ПО в соответствии с 4.4 те части УСТАРЕВШЕГО ПО, для которых сохраняются разрывы (пробелы) в ПОСТАВЛЯЕМЫХ РЕЗУЛЬТАТАХ, продолжают оставаться УСТАРЕВШИМ ПО и могут быть рассмотрены для дальнейшего повторного использования в соответствии с 4.4. Когда разрывы (пробелы) в результатах устраняются путем изменения УСТАРЕВШЕГО ПО, изменения должны выполняться в соответствии с разделами 4-9 настоящего стандарта.

Традиционно требования к программному обеспечению, функциональные спецификации и спецификации проекта оформляются как набор из одного и более документов. В настоящее время возможно оформление этой информации как элементы данных внутри общей базы данных. Каждый элемент может иметь один или более признаков, которые определяют его цель и его соединение с другими элементами в базе данных. Этот подход допускает представление и печать различных видов информации,

которая лучше всего подходит для каждой группы предполагаемых пользователей (например, продавцов, ИЗГОТОВИТЕЛЕЙ, тестировщиков, аудиторов) и поддерживает

ПРОСЛЕЖИВАЕМОСТЬ, чтобы демонстрировать соответствие имплементации и степени, до которой тестовые задания проверяют требования. Инструменты, поддерживающие этот подход, могут быть такими же простыми, как гипертекстовый документ, использующий гиперссылки HTML, или столь же сложными, как CASE (computer aided software engineering - разработка компьютерного программного обеспечения) и инструменты анализа требований.

Эта деятельность требует, чтобы ИЗГОТОВИТЕЛЬ определил главные структурные компоненты программного обеспечения и определил их основную зону ответственности, а также их внешне

видимые свойства и взаимосвязь между ними. Если функционирование компонента может влиять на другие компоненты, то оно должно быть описано в АРХИТЕКТУРЕ программного обеспечения. Это описание особенно важно для аспектов функционирования, которые могут повлиять на компоненты МЕДИЦИНСКОГО ИЗДЕЛИЯ, находящиеся вне программного обеспечения (см. 5.3.5 и В.4.3).

АРХИТЕКТУРНЫЕ решения чрезвычайно важны для осуществления мер по УПРАВЛЕНИЮ РИСКАМИ.

Без понимания (и документирования) аспектов функционирования компонента, которые могут повлиять на другие компоненты, почти невозможно доказать, что СИСТЕМА безопасна. АРХИТЕКТУРА программного обеспечения необходима для обеспечения правильной имплементации требований к ПО. АРХИТЕКТУРА программного обеспечения не считается завершенной, если все требования к ПО не могут быть реализованы определенными ПРОГРАММНЫМИ СОСТАВНЫМИ ЧАСТЯМИ. Поскольку дизайн и имплементация программного обеспечения зависят от АРХИТЕКТУРЫ, АРХИТЕКТУРА ВЕРИФИЦИРУЕТСЯ для завершения этой ДЕЯТЕЛЬНОСТИ. Как правило, ВЕРИФИКАЦИЯ АРХИТЕКТУРЫ выполняется путем технического ОЦЕНИВАНИЯ.

Классификация безопасности программного обеспечения в отношении

ПРОГРАММНЫХ СОСТАВНЫХ ЧАСТЕЙ в процессе ДЕЯТЕЛЬНОСТИ по разработке АРХИТЕКТУРЫ программного обеспечения создает основание для последующего выбора программных ПРОЦЕССОВ. Записи о классификации находятся под управлением изменениями в составе ФАЙЛА МЕНЕДЖМЕНТА РИСКА.

Данная ДЕЯТЕЛЬНОСТЬ требует от ИЗГОТОВИТЕЛЯ усовершенствования ПРОГРАММНЫХ

СОСТАВНЫХ ЧАСТЕЙ и интерфейсов, определенных в АРХИТЕКТУРЕ, чтобы создать ПРОГРАММНЫЕ БЛОКИ и их интерфейсы. Хотя ПРОГРАММНЫЕ БЛОКИ часто считаются единичными функциями или

модулями, эта точка зрения не всегда является приемлемой. Настоящий стандарт определяет ПРОГРАММНЫЙ БЛОК как ПРОГРАММНУЮ СОСТАВНУЮ ЧАСТЬ,

не делимую на более мелкие элементы. ПРОГРАММНЫЕ БЛОКИ могут проверяться отдельно. ИЗГОТОВИТЕЛЮ следует определить уровень детализации ПРОГРАММНОГО БЛОКА. Детальный дизайн определяет алгоритмы представления данных и взаимодействия между

ПРОГРАММНЫМИ БЛОКАМИ и структурами данных. Детальный дизайн также должен касаться формирования ПРОГРАММНОГО ПРОДУКТА. Необходимо определить конструкцию ПРОГРАММНЫХ БЛОКОВ и интерфейсов достаточно подробно, чтобы можно было объективно ВЕРИФИЦИРОВАТЬ их БЕЗОПАСНОСТЬ и результативность, если это может быть обеспечено с использованием других требований или документации по разработке. Он должен быть достаточно полным, чтобы программисту не требовалось принимать исключительных проектных решений. Детальный дизайн также должен быть связан с архитектурой ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ МЕДИЦИНСКОГО ИЗДЕЛИЯ.

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

уверенность в том, что дизайн правильно реализует АРХИТЕКТУРУ программного обеспечения и не противоречит АРХИТЕКТУРЕ программного обеспечения.

Тестирование методом "белого ящика", также известное как тестирование "стеклянного ящика", "структурное", "прозрачного ящика" и "открытого ящика", - это техника тестирования, где используется точное знание внутреннего функционирования ПРОГРАММНОЙ СОСТАВНОЙ ЧАСТИ, чтобы выбирать данные тестирования. Тестирование методом "белого ящика" использует определенные знания о ПРОГРАММНОЙ СОСТАВНОЙ ЧАСТИ, чтобы проверять выходные данные. Это тестирование является точным, только если тестовый инженер знает, что ПРОГРАММНАЯ СОСТАВНАЯ ЧАСТЬ должна делать. Тогда тестовый инженер может видеть, когда ПРОГРАММНАЯ СОСТАВНАЯ ЧАСТЬ отклоняется от его намеченной цели. Тестирование методом "белого ящика" не может гарантировать, что была реализована полная спецификация (на программное обеспечение), поскольку оно фокусируется на тестировании реализации ПРОГРАММНОЙ СОСТАВНОЙ ЧАСТИ. Тестирование методом "черного ящика", также известное как "поведенческое", "функциональное", тестирование "непрозрачного ящика" или тестирование "закрытого ящика", фокусируется на тестировании функциональной спецификации и не может гарантировать, что были протестированы все реализованные части. Таким образом, тестирование методом "черного ящика" является тестированием на спецификацию и обнаруживает дефекты пропусков, определяя, какая часть спецификации не была выполнена. Тестирование методом "белого ящика" является тестированием на реализацию и обнаруживает дефекты выполнения, указывая, какая часть реализации неисправна. Чтобы полностью

протестировать ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ МЕДИЦИНСКОГО ИЗДЕЛИЯ, могут

потребоваться как тестирование методом "черного ящика", так и тестирование методом "белого ящика".

Когда в ПРОГРАММНУЮ СИСТЕМУ вносятся изменения (даже небольшие), должна быть определена степень РЕГРЕССИОННОГО ТЕСТИРОВАНИЯ (но не только тестирования отдельных изменений), чтобы удостовериться в отсутствии непредусмотренных побочных явлений. Данное РЕГРЕССИОННОЕ ТЕСТИРОВАНИЕ (и

обоснование для не полностью повторяемого тестирования ПРОГРАММНОЙ СИСТЕМЫ)

должно быть запланировано и документировано. (См. В.6.3).

Если при тестировании были обнаружены способные к повторению АНОМАЛИИ, но

было принято решение не устранять их, то данные АНОМАЛИИ должны быть ОЦЕНЕНЫ в

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

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

убедиться, что измененное программное обеспечение не создает ОПАСНОЙ СИТУАЦИИ или снижает РИСК в программном обеспечении, которое ранее не создавало ОПАСНОЙ

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

Главным в ПРОЦЕССЕ технической поддержки программного обеспечения является

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

- ИЗГОТОВИТЕЛЬ рассматривает, какое другое ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ МЕДИЦИНСКОГО ИЗДЕЛИЯ может быть затронуто и предпринимает соответствующие действия.

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

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

изменения программного обеспечения. Должно быть сделано обоснование, оправдывающее количество РЕГРЕССИОННЫХ ТЕСТОВ, которое будет выполняться для обеспечения уверенности в том, что части еще не модифицированного ПО МЕДИНСКОГО ИЗДЕЛИЯ продолжают работать так, как и до выполнения модификации.

Разделы/подразделы настоящего стандарта

Соответствующие пункты 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.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

Требования к ПО - это подмножество требований к программируемой электрической медицинской системе (ПЭМС). Настоящий стандарт определяет требования к ПО, которые

являются дополнительными, но не являются несовместимыми с требованиями 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.6 Охват требований к ПЭМС в IEC 60601-1:2005 + IEC 60601-1:2005/AMD1:2012

Требования к ПЭМС в IEC 60601-1:2005 + IEC 60601-1:2005/AMD1:2012

Требования IEC 62304, связанные с программным обеспечением подсистемы ПЭМС

14.1 Общие положения

4.3* Классификация программного

Требования 14.2-14.12 (включительно) применяются к ПЭМС только в тех случаях, когда:

обеспечения в отношении безопасности

- ни одна из ПРОГРАММИРУЕМЫХ ЭЛЕКТРОННЫХ ПОДСИСТЕМ (ПЭСС) не задействована в обеспечении ОСНОВНОЙ БЕЗОПАСНОСТИ или ОСНОВНЫХ ФУНКЦИОНАЛЬНЫХ ХАРАКТЕРИСТИК или

- применение МЕНЕДЖМЕНТА РИСКА как описано в 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 Проектирование АРХИТЕКТУРЫ программного обеспечения

Когда это целесообразно для снижения РИСКА до допустимого уровня, в спецификации требований к АРХИТЕКТУРЕ должны использоваться:

5.3.5 Идентификация обособленности, необходимой для УПРАВЛЕНИЯ РИСКОМ

a) КОМПОНЕНТЫ С ВЫСОКОЙ СТЕПЕНЬЮ ИНТЕГРАЦИИ;

b) устойчивые к отказам функции;

c) избыточность;

d) диверсификация;

e) разделение функций;

f) защищенная конструкция, служащая, например, для ограничения представляющих потенциальную опасность эффектов путем ограничения допускаемой выходной мощности или введения устройств, ограничивающих свободный ход исполнительных устройств.

Разделение является единственным идентифицированным способом, и это только идентификация, потому что требование состоит в точном определении того, что целостность разделения обеспечена

Спецификация АРХИТЕКТУРЫ должна также учитывать:

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 содержит рекомендации для ОТВЕТСТВЕННОЙ ОРГАНИЗАЦИИ по обращению с такими рисками;

- последующие изменения ИТ-СЕТЕВЫХ РЕСУРСОВ могут приводить к появлению новых РИСКОВ и требовать дополнительного анализа;

- последующие изменения ИТ-СЕТЕВЫХ РЕСУРСОВ могут включать:

изменения в их конфигурации;

подсоединение к ним дополнительных элементов;

отсоединение от них отдельных элементов;

модификацию соединенного с ними оборудования;

модернизацию соединенного с ними оборудования

IEC 60601-1-4 был отменен.

Область применения IEC 61010-1 [5] распространяется на измерительное

оборудование и оборудование для электрических испытаний, оборудование электрического контроля и электрооборудование лаборатории. Только часть лабораторного электрооборудования используется в здравоохранении или в качестве изделий для 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.

Процессы настоящего стандарта

Процессы 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 Анализ требований к программному обеспечению

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

7.1.2.3.1.1

5.2.4 ПЕРЕОЦЕНИ-

ВАНИЕ АНАЛИЗА РИСКА МЕДИЦИНСКОГО ИЗДЕЛИЯ

Нет

Нет

5.2.5 Обновление требований к СИСТЕМЕ

7.1.2 Анализ требований к программному обеспечению

7.1.2.3.1 Анализ требований к программному обеспечению

7.1.2.3.1.1 a) и 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 Детализированная разработка программного обеспечения

5.4.2 Разработка детального дизайна для каждого ПРОГРАММНОГО БЛОКА

7.1.4.3.1.1

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 Функционирование программного обеспечения

6.4.9.3.2 Активация и проверка функционирования

6.4.9.3.2.1

5.8.2 Документирование известных остаточных АНОМАЛИЙ

7.2.2 Менеджмент конфигурации программного обеспечения

6.4.9.3.2.2

7.2.2.3.6 Поставка и менеджмент выпуска

7.2.2.3.6.1

5.8.3 ОЦЕНИВАНИЕ известных остаточных АНОМАЛИЙ

5.8.4 Документирование выпущенных ВЕРСИЙ

7.2.2 Процесс менеджмента конфигурации программного

7.2.2.3.6 Поставка и менеджмент выпуска

5.8.5 Документирование создания выпущенного программного обеспечения

обеспечения

7.2.2.3.6.1

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 требует документирования всех ЗАДАЧ проведения тестирования

Нет

В результате рассмотрения вопроса об использовании в настоящем стандарте,

применяемом в отношении критически важного для БЕЗОПАСНОСТИ программного обеспечения, принципов IEC 61508, были учтены следующие соображения. Подход к безопасности в IEC 62304 принципиально отличается от подхода в IEC 61508. IEC 62304 учитывает, что результативность медицинских изделий оправдывает существование остаточных рисков, связанных с их применением. Позицию настоящего стандарта объясняет следующее.

Настоящий стандарт упрощает вопрос 2) посредством установления классификации по трем классам безопасности программного обеспечения на основе РИСКА, вызванного

отказом. После классификации для разных классов безопасности программного обеспечения требуются разные ПРОЦЕССЫ: намерение состоит в дальнейшем уменьшении вероятности (и/или тяжести последствий) отказа программного обеспечения.

ДЕЯТЕЛЬНОСТЬ

Соответствующий раздел ИСО 13485:2003

Охватывается существующими процедурами?

Если да: ссылка

Предпринятые действия

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 ПРОЦЕСС решения проблем ПО

Да/Нет

Обозначение ссылочного международного стандарта

Степень соответствия

Обозначение и наименование соответствующего межгосударственного стандарта

ISO 14971

IDT

ГОСТ ISO 14971-2021 "Изделия медицинские. Применение менеджмента риска к медицинским изделиям"

Примечание - В настоящей таблице использовано следующее условное обозначение степени соответствия стандарта:

- IDT - идентичный стандарт.

[1]

IEC 60601-1:2005

Medical electrical equipment - Part 1: General requirements for basic safety and essential

IEC 60601-1:2005/AMD1:2012

performance (Изделия медицинские электрические.

Часть 1. Общие требования безопасности и основные характеристики)

[2]

IEC 60601-1-4:1996

Medical electrical equipment - Part 1: General requirements for safety - 4.Collateral standard:

IEC 60601-1-4:1996/AMD1:1999

Programmable electrical medical systems (withdrawn)

(Изделия медицинские электрические. Часть 1-1. Общие требования безопасности. Дополнительный стандарт. Требования безопасности к медицинским электрическим системам)

[3]

IEC 60601-1-6

Medical electrical equipment - Part 1-6: General requirements for basic safety and essential performance - Collateral standard: Usability (Изделия медицинские электрические. Часть 1-6. Общие требования безопасности с учетом основных функциональных характеристик. Дополнительный стандарт. Эксплуатационная пригодность)

[4]

IEC 61508-3

Functional safety of electrical/electronic/programmable electronic safetyrelated systems - Part 3: Software requirements (Функциональная безопасность систем электрических, электронных, программируемых электронных, связанных с безопасностью. Часть 3. Требования к программному обеспечению)

[5]

IEC 61010-1:2010

Safety requirements for electrical equipment for

measurement, control, and laboratory use - Part 1: General requirements (Безопасность контрольно-измерительных приборов и лабораторного оборудования. Часть 1. Общие требования)

[6]

ISO 9000:2005

Quality management systems - Fundamentals and vocabulary (Системы менеджмента качества. Основные положения и словарь)

[7]

ISO 9001:2008

Quality management systems - Requirements

(Системы менеджмента качества. Требования)

[8]

ISO 13485:2003

Medical devices - Quality management systems - Requirements for regulatory purposes (Изделия медицинские. Системы менеджмента качества. Требования для целей регулирования)

[9]

ISO/IEC 12207:2008

Systems and software engineering - Software life

cycle processes (Системная и программная инженерия. Процессы жизненного цикла программных средств)

[10]

ISO/IEC 14764:1999

Software Engineering - Software Life Cycle Processes - Maintenance (Информационная технология. Сопровождение программных средств)

[11]

ISO/IEC 15504-5:2012

Information technology - Process assessment - Part 5: An exemplar software life cycle process assessment model (Информационные технологии. Оценка процессов. Часть 5. Пример модели оценки процесса)

[12]

ISO/IEC 25010:2011

Systems and software engineering - System and software Quality Requirements and Evaluation (SQuaRE) - System and software quality models (Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE). Модели качества систем и программных продуктов)

[13]

ISO/IEC 33001:2015

Information technology - Process assessment - Concepts and terminology (Информационные технологии. Оценка процесса. Понятия и терминология)

[14]

ISO/IEC 33004:2015

Information technology - Process assessment - Requirements for process reference, process assessment and maturity modelss (Информационная технология. Оценка процесса. Требования к эталонным моделям процесса, моделям оценки процесса и завершенным моделям)

[15]

ISO/IEC 90003:2014

Software engineering - Guidelines for the application of ISO 9001:2008 to computer software (Разработка программных продуктов. Руководящие указания по применению ИСО 9001:2008 при разработке программных продуктов)

[16]

ISO/IEC Guide 51:2014

Safety aspects - Guidelines for their inclusion in standards (Аспекты безопасности. Руководящие указания по включению их в стандарты)

[17]

IEEE 610.12:1990

IEEE standard glossary of software engineering terminology

[18]

IEEE 1044:2009

IEEE standard classification for software anomalies

[19]

U.S. Department Of Health and Human Services, Food and Drug Administration, Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices, May 11, 2005, <://www.fda.gov/MedicalDevices/DeviceRegulationandGuidance/GuidanceDocuments/ ucm089543.htm>

[20]

U.S. Department Of Health and Human Services, Food and Drug Administration, General Principles of Software Validation; Final Guidance for Industry and FDA Staff, January 11, 2002, <http://www.fda.gov/downloads/RegulatoryInformation/Guidances/ucml26955.pdf>

[21]

IEC 62366-1:2015

Medical devices - Part 1: Application of usability engineering to medical devices (Изделия медицинские. Часть 1. Проектирование медицинских изделий с учетом эксплуатационной пригодности)

[22]

Healthcare Software Systems - Part 1: General requirements (Изделия медицинские. Часть 1.

Проектирование медицинских изделий с учетом эксплуатационной пригодности)

УДК 658.562.014:006.354

МКС 11.040.01

Ключевые слова: программное обеспечение, жизненный цикл, система менеджмента качества, менеджмент риска, изготовитель, медицинское изделие