Межгосударственный стандарт ГОСТ IEC 62304-2022 "Изделия медицинские. Программное обеспечение. Процессы жизненного цикла" (введен в действие приказом Федерального агентства по техническому регулированию и метрологии от 26 октября 2022 г. N 1196-ст)

Medical devices. Software. Life cycle processes

УДК 658.562.014:006.354
МКС 11.040.01

Дата введения - 1 сентября 2023 г.
Введен впервые

ГАРАНТ:

Вертикальные линии не приводятся

Предисловие

Цели, основные принципы и общие правила проведения работ по межгосударственной стандартизации установлены ГОСТ 1.0 "Межгосударственная система стандартизации. Основные положения" и ГОСТ 1.2 "Межгосударственная система стандартизации. Стандарты межгосударственные, правила и рекомендации по межгосударственной стандартизации. Правила разработки, принятия, обновления и отмены"

Сведения о стандарте

1 Подготовлен рабочей группой, состоящей из представителей Общества с ограниченной ответственностью "МЕДИТЕСТ" (ООО "МЕДИТЕСТ", г. Москва), Общества с ограниченной ответственностью "Аурига" (ООО "Аурига", г. Москва) и Общества с ограниченной ответственностью "Компания "ЭЛТА" (ООО "Компания "ЭЛТА", г. Москва) на основе собственного перевода на русский язык англоязычной версии стандарта, указанного в пункте 5

2 Внесен Федеральным агентством по техническому регулированию и метрологии

3 Принят Межгосударственным советом по стандартизации, метрологии и сертификации (протокол от 30 сентября 2022 г. N 154-П)

За принятие проголосовали:

Краткое наименование страны по МК (ИСО 3166) 004-97	Код страны по МК (ИСО 3166) 004-97	Сокращенное наименование национального органа по стандартизации
Беларусь	BY	Госстандарт Республики Беларусь
Киргизия	KG	Кыргызстандарт
Россия	RU	Росстандарт
Узбекистан	UZ	Узстандарт

4 Приказом Федерального агентства по техническому регулированию и метрологии от 26 октября 2022 г. N 1196-ст межгосударственный стандарт ГОСТ IEC 62304-2022 введен в действие в качестве национального стандарта Российской Федерации с 1 сентября 2023 г.

5 Настоящий стандарт идентичен международному стандарту IEC 62304:2006 "Программное обеспечение медицинского изделия. Процессы жизненного цикла программного обеспечения" ("Medical device software - Software life cycle processes", IDT), включая изменение Amd.1:2015. Изменение Amd.1:2015 выделено двойной вертикальной линией, расположенной на полях напротив соответствующего текста.

Наименование настоящего стандарта изменено относительно наименования указанного международного стандарта для приведения в соответствие с ГОСТ 1.5 (подраздел 3.6).

При применении настоящего стандарта рекомендуется использовать вместо ссылочных международных стандартов соответствующие им межгосударственные стандарты, сведения о которых приведены в дополнительном приложении ДА

6 Настоящий стандарт подготовлен на основе применения ГОСТ Р МЭК 62304-2013 ^*

------------------------------

^*_{Приказом Федерального агентства по техническому регулированию и метрологии от 26 октября 2022 г. N 1196-ст ГОСТ Р МЭК 62304-2013 отменен с 1 сентября 2023 г.}

------------------------------

7 Введен впервые

Введение

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

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

В качестве основной концепции полагается, что ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ МЕДИЦИНСКИХ ИЗДЕЛИЙ проектируется и обслуживается с использованием систем менеджмента качества (см. 4.1) и систем МЕНЕДЖМЕНТА РИСКА (см. 4.2). ПРОЦЕСС МЕНЕДЖМЕНТА РИСКА уже достаточно хорошо описан в международном стандарте ISO 14971:2007. Поэтому настоящий стандарт использует ссылки на этот стандарт. Некоторые незначительные дополнительные требования к МЕНЕДЖМЕНТУ РИСКА необходимы для программного обеспечения, особенно в области определения вклада факторов программного обеспечения, связанных с ОПАСНОСТЯМИ. Эти требования установлены в разделе 7 как ПРОЦЕСС МЕНЕДЖМЕНТА РИСКА программного обеспечения.

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

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

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

Рисунок 1 - Краткий обзор ПРОЦЕССОВ и ДЕЯТЕЛЬНОСТИ по разработке программного обеспечения

Рисунок 2 - Краткий обзор ПРОЦЕССОВ и ДЕЯТЕЛЬНОСТИ по технической поддержке программного обеспечения

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

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

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

Настоящий стандарт не устанавливает наименование, формат или точное содержание документации, которая будет создана. Требование состоит в том, чтобы ЗАДАЧИ документировались, а решение, как оформлять эту документацию, остается за пользователем этого стандарта.

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

Приложение A содержит разъяснения пунктов настоящего стандарта. Приложение B содержит рекомендации по положениям стандарта.

Для целей стандарта:

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

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

- "может" используется для описания допустимого способа достижения соответствия требованию;

- "установить" означает определять, документировать и осуществлять выполнение;

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

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

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

1 Область применения

1.1 *Цель

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

1.2 *Применимость

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

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

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

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

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

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

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

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

1.3 Взаимосвязь с другими стандартами

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

1.4 Соответствие

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

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

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

Примечание 1 - Данные оценки могут быть сделаны путем внешнего или внутреннего аудита.

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

Примечание 3 - Если какие-либо требования, содержащие словосочетание "соответствующим образом", не были выполнены, то для проведения оценки необходимо предоставить документированные обоснования.

Примечание 4 - Термин "соответствие", используемый в стандарте ИСО/МЭК 12207, применяется в настоящем стандарте таким же образом.

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

2 Нормативные ссылки

В настоящем стандарте использована нормативная ссылка на следующий стандарт [для датированной ссылки применяют только указанное издание ссылочного стандарта, для недатированной - последнее издание (включая все изменения)]:

ISO 14971, Medical devices - Application of risk management to medical devices (Изделия медицинские. Применение менеджмента риска к медицинским изделиям)

3* Термины и определения

В настоящем стандарте применены следующие термины с соответствующими определениями.

3.1 ДЕЯТЕЛЬНОСТЬ (ACTIVITY): Совокупность из одной или более взаимосвязанных или взаимодействующих ЗАДАЧ.

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

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

3.3 АРХИТЕКТУРА (ARCHITECTURE): Организационная структура СИСТЕМЫ или компонента.

[IEEE 610.12:1990]

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

3.5 СОСТАВНАЯ ЧАСТЬ КОНФИГУРАЦИИ (CONFIGURATION ITEM): Объект, который может быть однозначно определен в данной конкретной точке.

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

3.6 ПОСТАВЛЯЕМЫЙ РЕЗУЛЬТАТ (DELIVERABLE): Требуемый итог или выход (включая документацию) ДЕЯТЕЛЬНОСТИ или ЗАДАЧИ.

3.7 ОЦЕНИВАНИЕ (EVALUATION): Систематическое определение степени соответствия объекта установленным критериям.

[ISO/IEC 12207:2008, 4.12]

3.8 ВРЕД (HARM): Нанесение физического повреждения или другого вреда здоровью людей либо вреда имуществу или окружающей среде.

[ISO 14971:2007 2.2]

3.9 ОПАСНОСТЬ (HAZARD): Потенциальный источник ВРЕДА

[ISO 14971:2007 2.3]

3.10 ИЗГОТОВИТЕЛЬ (MANUFACTURER): Физическое или юридическое лицо, ответственное за проектирование, изготовление, упаковывание и/или маркировку МЕДИЦИНСКИХ ИЗДЕЛИЙ; установку, сборку или монтаж СИСТЕМЫ; или адаптацию МЕДИЦИНСКОГО ИЗДЕЛИЯ перед выпуском его в обращение и/или вводом в эксплуатацию независимо от того, выполняет ли эти операции вышеупомянутое лицо или третья сторона от его имени.

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

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

[ISO 14971:2007, 2.8]

3.11 МЕДИЦИНСКОЕ ИЗДЕЛИЕ (MEDICAL DEVICE): Любой инструмент, аппарат, прибор, устройство, оборудование, имплантат, in vitro реагент или калибратор, программное обеспечение, материал либо иные подобные или связанные с ними изделия, предназначенные ИЗГОТОВИТЕЛЕМ для применения к человеку по отдельности или в сочетании друг с другом в целях:

- диагностики, профилактики, мониторинга, лечения или облегчения заболеваний;

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

- исследования, замещения или изменения анатомического строения или физиологических ПРОЦЕССОВ;

- поддержания или сохранения жизни;

- управления зачатием;

- дезинфекции МЕДИЦИНСКИХ ИЗДЕЛИЙ;

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

Примечание 1 - Определение было разработано Целевой Группой Глобальной Гармонизации (GHTF). [ISO 13485:2003, определение 3.7].

Примечание 2 - Определения, используемые в регулировании разных стран, могут иметь некоторые различия.

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

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

3.14 ПРОЦЕСС (PROCESS): Совокупность взаимосвязанных и взаимодействующих видов ДЕЯТЕЛЬНОСТИ, преобразующая входы в выходы.

[ISO 9000:2005, определение 3.4.1]

Примечание - Термин "ДЕЯТЕЛЬНОСТЬ" включает использование ресурсов.

3.15 РЕГРЕССИОННОЕ ТЕСТИРОВАНИЕ (REGRESSION TESTING): Испытание, которое необходимо для определения влияния изменений в компонентах СИСТЕМЫ на ее функциональность, надежность или эксплуатационные характеристики и на создание дополнительных дефектов.

[ISO/IEC 90003:2004, определение 3.11]

3.16 РИСК (RISK): Сочетание вероятности причинения ВРЕДА и тяжести этого ВРЕДА.

[ISO 14971:2007 2.16]

3.17 АНАЛИЗ РИСКА (RISK ANALYSIS): Систематическое использование доступной информации для идентификации ОПАСНОСТИ и определения РИСКА.

[ISO 14971:2007 2.17]

3.18 УПРАВЛЕНИЕ РИСКОМ (RISK CONTROL): ПРОЦЕСС принятия решений и выполнения мер по уменьшению РИСКОВ до установленных уровней или поддержанию их на установленных уровнях.

[ISO 14971:2007 2.19]

3.19 МЕНЕДЖМЕНТ РИСКА (RISK MANAGEMENT): Систематическое применение политики, процедур и практических методов менеджмента для решения ЗАДАЧ анализа, оценивания, управления и мониторинга РИСКА.

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

3.20 ФАЙЛ МЕНЕДЖМЕНТА РИСКА (RISK MANAGEMENT FILE): Совокупность записей и других документов, создаваемых в ПРОЦЕССЕ МЕНЕДЖМЕНТА РИСКА.

[ISO 14971:2007 2.23]

3.21 БЕЗОПАСНОСТЬ (SAFETY): Отсутствие недопустимого РИСКА.

[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): Концептуальная структура, охватывающая существование программного обеспечения от определения требований до выпуска программного обеспечения, которая:

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

- описывает последовательность и взаимозависимость между ДЕЯТЕЛЬНОСТЬЮ и ЗАДАЧАМИ;

- идентифицирует этапы, на которых верифицируется полнота конкретных ПОСТАВЛЯЕМЫХ РЕЗУЛЬТАТОВ.

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

3.25 ПРОГРАММНАЯ СОСТАВНАЯ ЧАСТЬ (SOFTWARE ITEM): Любая идентифицируемая (выделяемая) часть компьютерной программы, т.е. исходный код, объектный код, управляющий код, управляющие данные или набор этих элементов.

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

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

ГАРАНТ:

Текст пункта приводится в соответствии с источником

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

3.27 ПРОГРАММНАЯ СИСТЕМА (SOFTWARE SYSTEM): Совокупность ПРОГРАММНЫХ СОСТАВНЫХ ЧАСТЕЙ, предназначенных для выполнения конкретной функции или набора функций.

3.28 ПРОГРАММНЫЙ БЛОК (SOFTWARE UNIT): ПРОГРАММНАЯ СОСТАВНАЯ ЧАСТЬ, которая не может быть разделена на более мелкие части.

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

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

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

3.30 СИСТЕМА (SYSTEM): Совокупная композиция, состоящая из одного или более ПРОЦЕССОВ, аппаратных средств, программного обеспечения, людей и средств, которая обеспечивает способность удовлетворить заявленную потребность или цель.

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

3.31 ЗАДАЧА (TASK): Отдельная часть работы, которую необходимо выполнить.

3.32 ПРОСЛЕЖИВАЕМОСТЬ (TRACEABILITY): Степень, до которой может быть установлена взаимосвязь между двумя или более результатами (продуктами) ПРОЦЕССА разработки.

[IEEE 610.12:1990]

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

3.33 ВЕРИФИКАЦИЯ (VERIFICATION): Подтверждение выполнения установленных требований на основе представления объективных свидетельств.

Примечание 1 - Термин "верифицирован" используется для обозначения соответствующего статуса.

[ISO 9000:2005, определение 3.8.4]

Примечание 2 - При проектировании и разработке ВЕРИФИКАЦИЯ относится к ПРОЦЕССУ проверки результатов конкретной ДЕЯТЕЛЬНОСТИ, чтобы определить соответствие требованиям, установленным к этой ДЕЯТЕЛЬНОСТИ.

3.34 ВЕРСИЯ (VERSION): Идентифицируемый отдельный вариант СОСТАВНОЙ ЧАСТИ КОНФИГУРАЦИИ.

Примечание 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]

4* Общие требования

4.1* Система менеджмента качества

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

Примечание 1 - Демонстрация этой способности может быть осуществлена при помощи СИСТЕМЫ менеджмента качества, которая соответствует следующим требованиям:

- ISO 13485 [8] или

- национальному стандарту на систему менеджмента качества или

- системе менеджмента качества, требуемой национальным регулированием.

Примечание 2 - Руководство по применению требований системы менеджмента качества к ПРОГРАММНОМУ ОБЕСПЕЧЕНИЮ можно найти в ISO/IEC 90003 [15].

4.2 *МЕНЕДЖМЕНТ РИСКА

ИЗГОТОВИТЕЛЬ должен применять ПРОЦЕСС МЕНЕДЖМЕНТА РИСКА в соответствии с ISO 14971.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

g) Каждой ПРОГРАММНОЙ СИСТЕМЕ, если ей не присвоен класс безопасности программного обеспечения, по умолчанию должен присваиваться Класс C.

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

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.

5 ПРОЦЕСС разработки программного обеспечения

5.1* Планирование разработки программного обеспечения

5.1.1 План разработки программного обеспечения

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

a) ПРОЦЕССЫ, которые будут использоваться при разработке ПРОГРАММНОЙ СИСТЕМЫ (см. примечание 4);

b) ПОСТАВЛЯЕМЫЕ РЕЗУЛЬТАТЫ (включая документацию) ДЕЯТЕЛЬНОСТИ и ЗАДАЧ;

c) ПРОСЛЕЖИВАЕМОСТЬ между требованиями СИСТЕМЫ, требованиями программного обеспечения, испытанием ПРОГРАММНОЙ СИСТЕМЫ и мерами по УПРАВЛЕНИЮ РИСКОМ, включенными в программное обеспечение;

d) конфигурацию программного обеспечения и менеджмент изменений, включая СОСТАВНЫЕ ЧАСТИ КОНФИГУРАЦИИ ПОНП (программное обеспечение неизвестного происхождения), и программного обеспечения, используемого для поддержки разработки;

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

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

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

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

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

Примечание 5 - План разработки программного обеспечения может быть включен в план разработки общей СИСТЕМЫ.

5.1.2 Поддержание плана разработки программного обеспечения в актуальном состоянии

ИЗГОТОВИТЕЛЬ должен обновлять план по мере того, как осуществляется разработка. [Классы A, B, C]

5.1.3 План разработки программного обеспечения относительно проектирования и разработки СИСТЕМЫ

a) ИЗГОТОВИТЕЛЬ должен указать требования СИСТЕМЫ в плане разработки программного обеспечения в качестве входных данных.

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

Примечание - Может не существовать различий между требованиями ПРОГРАММНОЙ СИСТЕМЫ и требованиями СИСТЕМЫ, если ПРОГРАММНАЯ СИСТЕМА является отдельной СИСТЕМОЙ (например, если программное обеспечение само по себе является изделием).

5.1.4 Стандарты, методы и инструменты планирования разработки программного обеспечения

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

a) на стандарты;

b) методы;

c) инструменты,

связанные с разработкой ПРОГРАММНЫХ СОСТАВНЫХ ЧАСТЕЙ класса C. [Класс C]

5.1.5 Программная интеграция и планирование тестирования интеграции

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

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

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

5.1.6 Планирование ВЕРИФИКАЦИИ программного обеспечения

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

a) ПОСТАВЛЯЕМЫЕ РЕЗУЛЬТАТЫ, требующие ВЕРИФИКАЦИИ;

b) требуемые ВЕРИФИКАЦИОННЫЕ ЗАДАЧИ для каждой ДЕЯТЕЛЬНОСТИ в жизненном цикле;

c) контрольные точки, на которых ВЕРИФИЦИРУЮТСЯ ПОСТАВЛЯЕМЫЕ РЕЗУЛЬТАТЫ;

d) критерии приемки для ВЕРИФИКАЦИИ ПОСТАВЛЯЕМЫХ РЕЗУЛЬТАТОВ. [Классы A, B, C]

5.1.7 Планирование МЕНЕДЖМЕНТА РИСКА программного обеспечения

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

5.1.8 Документация по планированию

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

a) титульный лист, наименование или обозначение;

b) цель;

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

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

5.1.9 Планирование менеджмента конфигурации программного обеспечения

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

a) на классы, типы, категории или списки элементов, подлежащих управлению;

b) ДЕЯТЕЛЬНОСТЬ и ЗАДАЧИ по менеджменту конфигурации программного обеспечения;

c) структуру (структуры), отвечающую(ие) за ДЕЯТЕЛЬНОСТЬ по менеджменту конфигурации программного обеспечения;

d) их взаимосвязь с другими структурами, такими как разработка или техническая поддержка программного обеспечения;

e) случаи, когда элементы должны находиться под управлением конфигурации;

f) случаи, когда следует использовать ПРОЦЕСС решения проблем. [Классы A, B, C]

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

5.1.10 Поддержка элементов, подлежащих управлению

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

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

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

5.1.11 Управление СОСТАВНЫМИ ЧАСТЯМИ КОНФИГУРАЦИИ программного обеспечения до ВЕРИФИКАЦИИ

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

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

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

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

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

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

[Классы B, C]

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

5.2.1 Отделение и документирование требований к программному обеспечению на основе требований СИСТЕМЫ

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

Примечание - Может не существовать различий между требованиями ПРОГРАММНОЙ СИСТЕМЫ и требованиями СИСТЕМЫ, если ПРОГРАММНАЯ СИСТЕМА является отдельной СИСТЕМОЙ (например, если программное обеспечение само по себе является изделием).

5.2.2 Содержание требований к программному обеспечению

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

a) требования к потенциальным возможностям и функциональности.

Примечание 1 - Примеры включают:

- характеристики, связанные с выполнением (например, цели/назначение программного обеспечения, требования по синхронизации);

- физические характеристики (например, язык машинного кода, платформу, операционную СИСТЕМУ);

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

- необходимость совместимости с модернизациями или многими ПОНП или другими версиями изделий;

b) входные и выходные данные ПРОГРАММНОЙ СИСТЕМЫ.

Примечание 2 - Например:

- характеристики данных (например, цифровые, буквенно-цифровые, формат);

- диапазоны;

- пределы;

- значения по умолчанию;

c) интерфейсы между ПРОГРАММНОЙ СИСТЕМОЙ и другими СИСТЕМАМИ;

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

e) требования к ЗАЩИЩЕННОСТИ.

Примечание 3 - Например:

- связанные с компромиссом относительно конфиденциальной информации;

- идентификация;

- авторизация;

- системный журнал;

- непрерывность связи;

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

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

Примечание 4 - Примеры в этой области связаны:

- с поддержкой операций, выполняемых вручную;

- взаимодействием между человеком и оборудованием;

- ограничениями в отношении персонала;

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

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

g) определение данных и требований к базе данных.

Примечание 6 - Например:

- форма;

- размерность;

- функция;

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

i) требования, относящиеся к методам разработки и технической поддержки;

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

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

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

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

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

k) требования к поддержке пользователей;

l) регулирующие требования.

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

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

Примечание 11 - Все эти требования могут не иметься в наличии на момент начала разработки.

Примечание 12 - Среди прочих, ISO/IEC 25010 [12] приводит информацию о качественных характеристиках, которая может быть полезна при определении требований к программному обеспечению.

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

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

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

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

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

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

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

5.2.6 Верификация требований к программному обеспечению

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

a) включают требования к СИСТЕМЕ, в том числе относящиеся к УПРАВЛЕНИЮ РИСКОМ;

b) не противоречат друг другу;

c) выражены в терминах, которые избегают двусмысленности;

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

e) могут быть идентифицированы уникальным образом;

f) являются прослеживаемыми в отношении требований к СИСТЕМЕ или к другому источнику.

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

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

5.3 Проектирование АРХИТЕКТУРЫ программного обеспечения

5.3.1 Преобразование требований к программному обеспечению в АРХИТЕКТУРУ

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

5.3.2 Разработка АРХИТЕКТУРЫ для интерфейсов ПРОГРАММНЫХ СОСТАВНЫХ ЧАСТЕЙ

ИЗГОТОВИТЕЛЬ должен разработать и документировать АРХИТЕКТУРУ для интерфейсов между

ПРОГРАММНЫМИ СОСТАВНЫМИ ЧАСТЯМИ и компонентами, внешними по отношению к ПРОГРАММНЫМ СОСТАВНЫМ ЧАСТЯМ (как для программной, так и для аппаратной части), а также между ПРОГРАММНЫМИ СОСТАВНЫМИ ЧАСТЯМИ. [Классы B, C]

5.3.3 Определение требований к функциональным и эксплуатационным характеристикам элементов ПОНП

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

5.3.4 Определение требований к аппаратным и программным средствам СИСТЕМЫ, требуемых элементами ПОНП

Если ПРОГРАММНАЯ СОСТАВНАЯ ЧАСТЬ определяется как ПОНП, ИЗГОТОВИТЕЛЬ должен определить аппаратные и программные средства СИСТЕМЫ, необходимые для поддержания правильной работы элемента ПОНП. [Классы B, C]

Примечание - Примеры включают тип и скорость процессора, тип и размер памяти, тип программного обеспечения СИСТЕМЫ, коммуникационные и дисплейные требования.

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

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

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

5.3.6 Верификация АРХИТЕКТУРЫ программного обеспечения

ИЗГОТОВИТЕЛЬ должен верифицировать и документировать, что:

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

b) АРХИТЕКТУРА программного обеспечения способна поддерживать взаимодействие между ПРОГРАММНЫМИ СОСТАВНЫМИ ЧАСТЯМИ, а также между ПРОГРАММНЫМИ СОСТАВНЫМИ ЧАСТЯМИ и аппаратными средствами;

c) АРХИТЕКТУРА МЕДИЦИНСКОГО ИЗДЕЛИЯ поддерживает правильную работу любых элементов ПОНП. [Классы B, C]

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

5.4* Разработка детального дизайна программного обеспечения

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

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

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

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

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

5.4.3 Разработка детального дизайна для интерфейсов

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

5.4.4 ВЕРИФИКАЦИЯ детального дизайна

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

a) реализует АРХИТЕКТУРУ программного обеспечения;

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

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

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

5.5.1 Имплементация каждого ПРОГРАММНОГО БЛОКА

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

5.5.2 Установление ПРОЦЕССА ВЕРИФИКАЦИИ ПРОГРАММНОГО БЛОКА

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

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

5.5.3 Критерии приемки ПРОГРАММНЫХ БЛОКОВ

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

Примечание - Примеры критериев приемки:

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

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

- Соответствует ли программный код процедурам программирования или стандартам кодирования?

5.5.4 Дополнительные критерии приемки ПРОГРАММНЫХ БЛОКОВ

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

- для правильной (соответствующей) последовательности событий;

- потока данных и управления;

- планируемого распределения ресурсов;

- работы с ошибками (определение ошибки, локализация и восстановление);

- инициализации переменных;

- самодиагностики;

- управления памятью и переполнений памяти;

- граничных условий.

[Класс C]

5.5.5 ВЕРИФИКАЦИЯ ПРОГРАММНЫХ БЛОКОВ

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

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

5.6.1 Интеграция ПРОГРАММНЫХ БЛОКОВ

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

5.6.2 Верификация интеграции программного обеспечения

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

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

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

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

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

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

Примечание 1 - Примерами могут служить:

- требуемая функциональность программного обеспечения;

- выполнение мер по УПРАВЛЕНИЮ РИСКОМ;

- определенная синхронизация и другие режимы работы;

- определенное функционирование внутренних и внешних интерфейсов;

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

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

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

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

5.6.6 Проведение регрессионного тестирования

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

5.6.7 Содержание записей в отношении регрессионного тестирования

ИЗГОТОВИТЕЛЬ должен:

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

b) сохранить существенные записи с целью сделать возможным повторное тестирование;

c) указать лицо, которое проводило тестирование.

[Классы B, C]

Примечание - Требование b) может быть выполнено путем сохранения, например:

- спецификаций тестового примера, показывающих требуемые действия и ожидаемые результаты;

- записей об оборудовании;

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

5.6.8 Использование ПРОЦЕССА решения проблем с программным обеспечением

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

Примечание - см. раздел 9.

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

5.7.1 Установление тестирования в отношении требований к программному обеспечению

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

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

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

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

5.7.2 Применение ПРОЦЕССА решения проблем с программным обеспечением

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

5.7.3 Повторное тестирование после внесения изменений

При внесении изменений входе тестирования ПРОГРАММНОЙ СИСТЕМЫ ИЗГОТОВИТЕЛЬ должен:

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

b) провести соответствующее тестирование, необходимое для демонстрации отсутствия возникновения непреднамеренных побочных эффектов;

c) выполнить соответствующую ДЕЯТЕЛЬНОСТЬ по МЕНЕДЖМЕНТУ РИСКА, как установлено в 7.4.

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

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

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

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

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

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

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

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

5.7.5 Содержание отчета по тестированию ПРОГРАММНОЙ СИСТЕМЫ

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

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

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

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

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

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

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

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

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

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

5.8.1 Обеспечение завершенности ВЕРИФИКАЦИИ программного обеспечения

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

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

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

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

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

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

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

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

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

5.8.6 Обеспечение полного завершения деятельности и задач

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

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

5.8.7 Архивирование программного обеспечения

Изготовитель должен хранить в архиве:

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

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

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

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

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

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

- создание копии;

- средства маркировки;

- упаковку;

- защиту;

- хранение;

- поставку.

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

6 Техническая поддержка программного обеспечения

6.1* Установление плана технической поддержки программного обеспечения

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

а) процедуры:

- для получения (установления),

- документирования,

- оценивания,

- исправления,

- отслеживания

по обратной связи, возникающей (устанавливаемой) после выпуска ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ МЕДИЦИНСКИХ ИЗДЕЛИЙ;

b) критерии для определения того, что обратная связь является проблемой;

c) использование ПРОЦЕССА МЕНЕДЖМЕНТА РИСКА программного обеспечения;

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

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

f) процедуры по ОЦЕНИВАНИЮ и проведению:

- обновления,

- исправления ошибок,

- исправлений, вносимых в коды ("заплатки", "патчи"),

- признания программного обеспечения устаревшим, обращения с ПОНП.

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

6.2* Анализ модификации и проблем

6.2.1 Документирование и оценивание обратной связи

6.2.1.1 Мониторинг обратной связи

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

6.2.1.2 Документирование и ОЦЕНИВАНИЕ обратной связи

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

6.2.1.3 ОЦЕНИВАНИЕ влияния ОТЧЕТОВ О ПРОБЛЕМАХ на БЕЗОПАСНОСТЬ

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

6.2.2 Использование ПРОЦЕССА решения проблем программного обеспечения

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

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

6.2.3 Анализ ЗАПРОСОВ НА ИЗМЕНЕНИЕ

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

6.2.4 Одобрение ЗАПРОСА НА ИЗМЕНЕНИЕ

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

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

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

Если требуется региональным регулированием, ИЗГОТОВИТЕЛЬ должен информировать пользователей и регулирующие органы:

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

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

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

6.3* Осуществление модификации

6.3.1 Использование установленного ПРОЦЕССА осуществления модификации

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

Примечание - Требования в отношении МЕНЕДЖМЕНТА РИСКА для изменений программного обеспечения см. в 7.4.

6.3.2 Повторный выпуск модифицированной ПРОГРАММНОЙ СИСТЕМЫ

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

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

7 ПРОЦЕСС МЕНЕДЖМЕНТА РИСКА программного обеспечения

7.1* Анализ программного обеспечения, способствующего опасным ситуациям

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

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

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

7.1.2 Идентификация потенциальных причин, способствующих возникновению опасных ситуаций

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

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

- неправильную или неполную спецификацию функциональности;

- дефекты программного обеспечения, идентифицированные в определенных функциях ПРОГРАММНОЙ СОСТАВНОЙ ЧАСТИ;

- отказы или неожидаемые результаты, исходящие от ПОНП;

- отказы аппаратных средств или другие дефекты ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ, которые могут привести к непредсказуемым операциям программного обеспечения;

- обоснованно прогнозируемое неправильное применение.

[Классы B, C]

7.1.3 ОЦЕНИВАНИЕ опубликованных списков АНОМАЛИЙ ПОНП

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

7.1.4 Документирование потенциальных причин

ИЗГОТОВИТЕЛЬ должен документировать в ФАЙЛЕ МЕНЕДЖМЕНТА РИСКА потенциальные причины, по которым ПРОГРАММНАЯ СОСТАВНАЯ ЧАСТЬ может способствовать возникновению опасной ситуации (см. ISO 14971). [Классы B, C]

7.2 Меры по УПРАВЛЕНИЮ РИСКОМ

7.2.1 Определение мер по УПРАВЛЕНИЮ РИСКОМ

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

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

7.2.2 Меры по УПРАВЛЕНИЮ РИСКОМ, реализованные в программном обеспечении

Если мера по УПРАВЛЕНИЮ РИСКОМ реализуются как часть функций ПРОГРАММНОЙ СОСТАВНОЙ ЧАСТИ, то ИЗГОТОВИТЕЛЬ должен:

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

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

c) разработать ПРОГРАММНУЮ СОСТАВНУЮ ЧАСТЬ в соответствии с разделом 5.

[Классы B, C]

Примечание - Это требование обеспечивает дополнительное уточнение требований по УПРАВЛЕНИЮ РИСКОМ в ISO 14971.

7.3 Верификация мер по УПРАВЛЕНИЮ РИСКОМ

7.3.1 Проведение верификации мер по УПРАВЛЕНИЮ РИСКОМ

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

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

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

7.3.3 Документирование ПРОСЛЕЖИВАЕМОСТИ

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

- от опасной ситуации до ПРОГРАММНОЙ СОСТАВНОЙ ЧАСТИ;

- от ПРОГРАММНОЙ СОСТАВНОЙ ЧАСТИ до конкретной причины в программном обеспечении;

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

- от меры по УПРАВЛЕНИЮ РИСКОМ до ВЕРИФИКАЦИИ меры по УПРАВЛЕНИЮ РИСКОМ.

[Классы B, C]

Примечание - См. ISO 14971:2007, отчет по МЕНЕДЖМЕНТУ РИСКА.

7.4 МЕНЕДЖМЕНТ РИСКА в отношении изменений программного обеспечения

7.4.1 Анализ изменений ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ МЕДИЦИНСКОГО ИЗДЕЛИЯ в отношении БЕЗОПАСНОСТИ

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

- существования не выявленных ранее причин, способствующих возникновению опасной ситуации;

- требуются ли дополнительные программные меры по УПРАВЛЕНИЮ РИСКОМ.

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

7.4.2 Анализ влияния изменений программного обеспечения на выполненные меры по УПРАВЛЕНИЮ РИСКОМ

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

7.4.3 Осуществление ДЕЯТЕЛЬНОСТИ по МЕНЕДЖМЕНТУ РИСКА, основанной на результатах анализа

ИЗГОТОВИТЕЛЬ должен осуществить уместную ДЕЯТЕЛЬНОСТЬ по МЕНЕДЖМЕНТУ РИСКА, которая определена в 7.1, 7.2 и 7.3, основанную на результатах проведенного анализа. [Классы B, C]

8* ПРОЦЕСС менеджмента конфигурации программного обеспечения

8.1* Идентификация конфигурации

8.1.1 Установление средств идентификации СОСТАВНОЙ ЧАСТИ КОНФИГУРАЦИИ

ИЗГОТОВИТЕЛЬ должен установить схему уникальной идентификации подлежащих управлению СОСТАВНЫХ ЧАСТЕЙ КОНФИГУРАЦИИ и их ВЕРСИЙ в соответствии с планированием разработки и конфигурации, установленной в 5.1. [Классы A, B, C]

8.1.2 Идентификация ПОНП

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

a) наименование;

b) ИЗГОТОВИТЕЛЯ;

c) уникальный указатель (обозначение) ПОНП.

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

Примечание - Уникальным указателем ПОНП может быть, например, ВЕРСИЯ, дата выпуска, номер патча или обозначение модернизации.

8.1.3 Идентификация документации конфигурации СИСТЕМЫ

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

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

8.2* Управление изменениями

8.2.1 Одобрение ЗАПРОСОВ НА ИЗМЕНЕНИЯ

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

Примечание 1 - Решение одобрить ЗАПРОС НА ИЗМЕНЕНИЯ может быть частью ПРОЦЕССА управления изменениями или частью другого ПРОЦЕССА. Этот подпункт требует только того, чтобы одобрение изменения предшествовало его выполнению.

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

8.2.2 Осуществление изменений

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

Примечание - Данный подпункт устанавливает, как изменение должно быть реализовано для обеспечения надлежащего управления изменениями. Это не означает, что внедрение (реализация) является неотъемлемой частью ПРОЦЕССА управления изменениями. При внедрении должны использоваться запланированные ПРОЦЕССЫ, см. 5.1.1 е) и 6.1 е).

8.2.3 ВЕРИФИКАЦИЯ изменений

ИЗГОТОВИТЕЛЬ должен проверять изменения, включая повторение любой ВЕРИФИКАЦИИ, которая стала недействительной после внесения изменений, а также уделить внимание 5.7.2 и 9.7. [Классы A, B, C]

Примечание - Данный подпункт требует только ВЕРИФИКАЦИИ изменений. Он не подразумевает того, что ВЕРИФИКАЦИЯ - неотъемлемая часть ПРОЦЕССА управления изменениями. ВЕРИФИКАЦИЯ должна использовать запланированные ПРОЦЕССЫ, см. 5.1.1 д) и 6.1 е).

8.2.4 Обеспечение средствами для ПРОСЛЕЖИВАЕМОСТИ изменений

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

a) ЗАПРОСАМИ НА ИЗМЕНЕНИЕ,

b) соответствующими ОТЧЕТАМИ О ПРОБЛЕМАХ,

c) одобрениями ЗАПРОСА НА ИЗМЕНЕНИЕ.

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

8.3* Учет статуса конфигурации

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

9 ПРОЦЕСС решения проблем программного обеспечения

9.1 Подготовка ОТЧЕТОВ О ПРОБЛЕМАХ

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

Примечание - Проблемы могут быть обнаружены до или после выпуска, внутри организации ИЗГОТОВИТЕЛЯ или вне ее.

9.2 Исследование проблемы

ИЗГОТОВИТЕЛЬ должен:

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

- ОЦЕНИТЬ влияние проблемы на БЕЗОПАСНОСТЬ, используя ПРОЦЕСС МЕНЕДЖМЕНТА РИСКА (раздел 7);

- документировать результаты исследования и оценки;

- создать ЗАПРОС (ЗАПРОСЫ) НА ИЗМЕНЕНИЕ в отношении действий, необходимых для исправления проблемы, или документировать объяснение того, почему никакие действия не предприняты. [Классы A, B, C]

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

9.3 Консультирование заинтересованных сторон

Если применимо, ИЗГОТОВИТЕЛЬ должен консультировать заинтересованные стороны относительно существующей проблемы. [Классы A, B, C]

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

9.4 Использование процесса управления изменениями

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

9.5 Поддержание записей

ИЗГОТОВИТЕЛЬ должен поддерживать записи в отношении ОТЧЕТОВ О ПРОБЛЕМАХ и принятых решениях, включая их ВЕРИФИКАЦИЮ.

Если применимо, ИЗГОТОВИТЕЛЬ должен обновлять ФАЙЛ МЕНЕДЖМЕНТА РИСКА. [Классы A, B, C]

9.6 Анализ проблем на предмет выявления тенденций

ИЗГОТОВИТЕЛЬ должен проводить анализ с целью определения тенденции в ОТЧЕТАХ О ПРОБЛЕМАХ. [Классы A, B, C]

9.7 ВЕРИФИКАЦИЯ решения проблем программного обеспечения

- ИЗГОТОВИТЕЛЬ должен верифицировать решения с целью определения:

- была ли проблема решена и был ли завершен ОТЧЕТ О ПРОБЛЕМЕ;

- были ли преодолены неблагоприятные тенденции;

- был ли ЗАПРОС НА ИЗМЕНЕНИЯ реализован в соответствующем ПРОГРАММНОМ ОБЕСПЕЧЕНИИ МЕДИЦИНСКИХ ИЗДЕЛИЙ и ДЕЯТЕЛЬНОСТИ;

- появились ли дополнительные проблемы. [Классы A, B, C]

9.8 Содержание документации по тестированию

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

a) результаты тестирования;

b) обнаруженные АНОМАЛИИ;

c) ВЕРСИЮ тестируемого программного обеспечения;

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

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

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

g) идентификацию лица, проводившего тестирование. [Классы A, B, C]

Библиография

[1]	IEC 60601-1:2005 IEC 60601-1:2005/AMD1:2012	Medical electrical equipment - Part 1: General requirements for basic safety and essential performance (Изделия медицинские электрические. Часть 1. Общие требования безопасности и основные характеристики)
[2]	IEC 60601-1-4:1996 IEC 60601-1-4:1996/AMD1:1999	Medical electrical equipment - Part 1: General requirements for safety - 4. Collateral standard: 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/ucm126955.pdf>
[21]	IEC 62366-1:2015	Medical devices - Part 1: Application of usability engineering to medical devices (Изделия медицинские. Часть 1. Проектирование медицинских изделий с учетом эксплуатационной пригодности)
[22]	82304-1:- 3	Healthcare Software Systems - Part 1: General requirements (Изделия медицинские. Часть 1. Проектирование медицинских изделий с учетом эксплуатационной пригодности)

------------------------------

³_{В стадии разработки.}

------------------------------

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