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

(введен в действие Приказом Росстандарта от 26.10.2022 № 1196-ст)

ИСТОРИЯ ИЗМЕНЕНИЙ НОРМАТИВНО-ТЕХНИЧЕСКИХ АКТОВ

flowchart LR
  n0["ГОСТ Р МЭК 62304-2013"]:::rst
  click n0 "https://bukva.ai/docs/gost-r-mek-62304-2013" "ГОСТ Р МЭК 62304-2013. Национальный стандарт Российской Федерации. Изделия медицинские. Программное обеспечение. Процессы жизненного цикла (утв. и введен в действие Приказом Росста"
  n1["ГОСТ IEC 62304-2022"]:::doc
  click n1 "https://bukva.ai/docs/standart-gost-iec-62304-2022" "ГОСТ IEC 62304-2022. Межгосударственный стандарт. Изделия медицинские. Программное обеспечение. Процессы жизненного цикла (введен в действие Приказом Росстандарта от 26.10.2022 N 1"
  n0 --> n1
classDef rst fill:#FFEBEB,stroke:#8B0000,color:#000;
classDef doc fill:#EBFFEB,stroke:#006400,color:#000;
classDef notEnt fill:#FFFFEB,stroke:#FF8C00,color:#000;

Введен в действие Приказом Федерального агентства

Дата введения

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

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

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

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

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

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 г. № 1196-ст ГОСТ Р МЭК 62304-2013 отменен с 1 сентября 2023 г.

7 ВВЕДЕН ВПЕРВЫЕ

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

В случае пересмотра, изменения или отмены настоящего стандарта соответствующая информация будет опубликована на официальном интернет-сайте Межгосударственного совета по стандартизации, метрологии и сертификации в каталоге «Межгосударственные стандарты»

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

<> Символ «звездочка» (), используемый как первый знак в наименовании или начале параграфа, указывает, что в приложении B имеется соответствующее руководство.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[IEEE 610.12:1990]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

назначению, или о том, что противоречит спецификации.

Примечание 1 — Настоящий стандарт не требует, чтобы каждый ОТЧЕТ О ПРОБЛЕМАХ приводил к

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

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

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

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

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

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

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

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

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

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

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

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

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

Примечание — Стойкое ухудшение означает необратимое ухудшение или утрату части структуры или функций организма, за исключением незначительного ухудшения или ущерба.

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

• описывает последовательность и взаимозависимость между ДЕЯТЕЛЬНОСТЬЮ и ЗАДАЧАМИ;
• идентифицирует этапы, на которых верифицируется полнота конкретных ПОСТАВЛЯЕМЫХ РЕЗУЛЬТАТОВ.

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

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

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

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

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

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

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

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

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

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

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

[IEEE 610.12:1990]

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

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

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

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

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

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

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

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

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

• ISO 13485 [8] или
• национальному стандарту на систему менеджмента качества или
• системе менеджмента качества, требуемой национальным регулированием.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

b) методы;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

b) цель;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• характеристики, связанные с выполнением (например, цели/назначение программного обеспечения, требования по синхронизации);
• физические характеристики (например, язык машинного кода, платформу, операционную СИСТЕМУ);
• компьютерное окружение (например, аппаратные средства, размер памяти, процессор, часовой пояс, инфраструктуру сети);
• необходимость совместимости с модернизациями или многими ПОНП или другими версиями изделий;

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

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

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

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

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

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

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

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

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

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

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

• форма;
• размерность;
• функция;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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]

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

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

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

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

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, B, C]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• создание копии;
• средства маркировки;
• упаковку;
• защиту;
• хранение;
• поставку.

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

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

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

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

• для получения (установления),
• документирования,
• оценивания,
• исправления,
• отслеживания

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

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

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

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

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

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

• обновления,
• исправления ошибок,
• исправлений, вносимых в коды («заплатки», «патчи»),
• признания программного обеспечения устаревшим, обращения с ПОНП.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[Классы B, C]

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

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

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

новой ОПАСНОЙ СИТУАЦИИ. [Классы B, C]

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.1* Идентификация конфигурации

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Примечание 2 — В отношении ЗАПРОСОВ НА ИЗМЕНЕНИЯ на разных стадиях жизненного цикла могут

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

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

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

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

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

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

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

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

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

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

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

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

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]

Приложение A (справочное)

ОБОСНОВАНИЕ ТРЕБОВАНИЙ НАСТОЯЩЕГО СТАНДАРТА

В данном приложении приведено обоснование положений настоящего стандарта.

A.1 Обоснование

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

ПРОЦЕССЫ, требуемые настоящим стандартом, можно разделить на две категории:

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

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

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

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

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

ДЕЯТЕЛЬНОСТЬ требуется для классов A, B и C по следующим причинам:

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

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

ДЕЯТЕЛЬНОСТЬ требуется выборочно для программного обеспечения классов B и C по следующим причинам:

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

ДЕЯТЕЛЬНОСТЬ требуется выборочно для класса C по следующим причинам:

• ДЕЯТЕЛЬНОСТЬ еще больше повышает надежность СИСТЕМЫ, требуя более тщательного, или более точного, или более внимательного отношения к отдельным вопросам проекта (дизайна), тестирования или другой ВЕРИФИКАЦИИ.

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

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

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

A.2 Краткое изложение требований по классификации

Таблица A.1 показывает, какие классы безопасности программного обеспечения назначены каждому требованию. Это информационная таблица и предоставлена она только для удобства. Нормативный раздел указывает классы безопасности программного обеспечения для каждого требования.

Таблица A.1

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

Приложение B (справочное)

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

B.1.1 Цель

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

МЕДИЦИНСКОГО ИЗДЕЛИЯ.

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

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

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

Из-за указанных логических зависимостей между процессами в настоящем стандарте целесообразней описывать процессы в последовательности, подразумевающей «водопадную» или «сквозную» модель жизненного цикла. Однако можно использовать и другие модели. Некоторые стратегии разработки (модели) определены в стандарте ISO/IEC 12207 [9] и включают (см. также таблицу B.1):

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

Таблица B.1

Разработка стратегий (моделей), как это определено в ISO/IEC 12207

Какой бы жизненный цикл ни был выбран, необходимо поддерживать логические зависимости между выходными данными ПРОЦЕССОВ, такими как спецификации, проектные документы и ПО. Модель жизненного цикла «водопад» достигает этого, откладывая старт ПРОЦЕССА до тех пор, пока входные данные для этого процесса не будут определены и одобрены.

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

Следующие принципы важны вне зависимости от того, какой жизненный цикл разработки ПО используется:

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

B.1.2 Область применения

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

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

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

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

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

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

ISO/IEC 90003 [11] предоставляет руководство для применения систем менеджмента качества к разработке ПО. Использование этого руководства не требуется настоящим стандартом, но рекомендуется.

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

Там, где это возможно, терминам даны определения из международных стандартов.

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

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

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

Не существует метода, чтобы обеспечить 100%-ную БЕЗОПАСНОСТЬ для любого вида ПО.

Есть три главных принципа, которые способствуют обеспечению БЕЗОПАСНОСТИ ПО МЕДИЦИНСКИХ ИЗДЕЛИЙ:

• МЕНЕДЖМЕНТ РИСКА;
• менеджмент качества;
• разработка ПО.

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

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

Управляемая и результативная совокупность ПРОЦЕССОВ разработки ПО включает организационные ПРОЦЕССЫ, такие как менеджмент, инфраструктура, улучшение и обучение. Для исключения дублирования и с целью фокусировки внимания пользователя настоящего стандарта на разработке ПО данные ПРОЦЕССЫ не рассматриваются.

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

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

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

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

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

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

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

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

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

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

P₁ - вероятность возникновения опасной ситуации;

P2 — вероятность возникновения опасной ситуации, приводящей к причинению вреда.

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

Если ПРОГРАММНАЯ СИСТЕМА подразделяется на ПРОГРАММНЫЕ СОСТАВНЫЕ ЧАСТИ, то каждая ПРОГРАММНАЯ СОСТАВНАЯ ЧАСТЬ может иметь свой собственный класс безопасности ПО. Определить РИСК, связанный с отказом ПРОГРАММНОЙ СОСТАВНОЙ ЧАСТИ, можно только:

• если АРХИТЕКТУРА СИСТЕМЫ и АРХИТЕКТУРА ПО определяют роль ПРОГРАММНОЙ СОСТАВНОЙ ЧАСТИ с точки зрения ее назначения и взаимодействия с другими программными и аппаратными элементами;
• если изменения в СИСТЕМЕ находятся под управлением;
• после выполнения АНАЛИЗА РИСКА для данной АРХИТЕКТУРЫ и установления мер по УПРАВЛЕНИЮ РИСКОМ.

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

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

Данный этап соответствует точке, с которой в ISO 14971 начинается УПРАВЛЕНИЕ РИСКОМ.

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

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

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

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

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

Как установлено в B.3, настоящий стандарт использует три термина для описания декомпозиции ПРОГРАММНОЙ СИСТЕМЫ (высший уровень).

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

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

вклад ПРОГРАММНОЙ СИСТЕМЫ в возникновение ОПАСНЫХ СИТУАЦИЙ на приводящие к возможной смерти

или СЕРЬЕЗНОЙ ТРАВМЕ, в ПРОГРАММНОЙ СОСТАВНОЙ ЧАСТИ Z, и вклад всей оставшейся ПРОГРАММНОЙ

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

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

B.5 ПРОЦЕСС разработки ПО

B.5.1 Планирование разработки ПО

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

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

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

B.5.2 Анализ требований к ПО

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

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

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

тестовые задания проверяют требования. Инструменты, поддерживающие этот подход, могут быть такими же простыми, как гипертекстовый документ, использующий гиперссылки HTML, или столь же сложными, как CASE (computer aided software engineering — разработка компьютерного программного обеспечения) и инструменты анализа требований.

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

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

ПРОЦЕСС сбора и анализа СИСТЕМНЫХ и программных требований может быть итеративным.

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

B.5.3 АРХИТЕКТУРА программного обеспечения

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

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

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

Множество последующих событий может сделать классификацию недействительной. Они включают, например:

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

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

B.5.4 Детальный дизайн программного обеспечения

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

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

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

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

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

Если дизайн будет содержать дефекты, то код не будет правильно реализовывать требования.

Если дизайн содержит дефекты, то ИЗГОТОВИТЕЛЬ должен проверить те характеристики дизайна, которые он считает важными для обеспечения БЕЗОПАСНОСТИ. Примеры таких характеристик включают:

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

B.5.5 Имплементация и верификация ПРОГРАММНОГО БЛОКА

Данная ДЕЯТЕЛЬНОСТЬ требует от ИЗГОТОВИТЕЛЯ записать и проверить код для ПРОГРАММНЫХ БЛОКОВ.

Детальный дизайн преобразовывается в исходный код. Кодирование представляет собой момент, в котором заканчивается декомпозиция спецификаций и начинается составление реализуемого исполняемого ПО. Чтобы последовательно достигать желаемых характеристик кода, должны использоваться стандарты кодирования для определения предпочитаемого стиля кодирования. Примеры стандартов кодирования включают требования к понятности, правила использования языка или ограничений и сложность управления. Код для каждого модуля ВЕРИФИЦИРУЕТСЯ на предмет функционирования как определено в детальном дизайне, и что он соответствует установленным стандартам кодирования.

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

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

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

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

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

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

В соответствующих случаях тестирование интеграции демонстрирует поведение программы на границах ее входных и выходных доменов (областей) и подтверждает реакцию ПО на недействительные, неожиданные и специальные входные данные. Действия программы обнаруживаются при введении комбинации входных данных или неожиданной последовательности входных данных, или когда нарушены определенные требования синхронизации. Требования тестирования в плане должны включать, соответственно, типы тестирования методом «белого ящика», чтобы быть выполненными как часть интеграционного тестирования.

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

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

Планы и документация тестирования, определенные в подразделах 5.6 и 5.7, могут быть отдельными документами, привязанными к конкретным стадиям разработки или эволюционным прототипам. Они могут быть объединены в единый документ или набор документов, охватывающих требования множества подразделов. Все документы или часть документов могут быть включены в проектные документы более высокого уровня, такие как план обеспечения качества проекта или ПО, или план комплексного тестирования, который охватывает все аспекты тестирования аппаратных средств и программного обеспечения. В таких случаях следует создавать перекрестную ссылку, которая определяет, как различные документы проекта связаны с каждой из ЗАДАЧ интеграции программного обеспечения.

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

Пункт 5.6.2 требует от ИЗГОТОВИТЕЛЯ верифицировать выходные данные ДЕЯТЕЛЬНОСТИ по интеграции программного обеспечения. Выходные данные ДЕЯТЕЛЬНОСТИ по интеграции программного обеспечения — это интегрированные (встроенные) ПРОГРАММНЫЕ СОСТАВНЫЕ ЧАСТИ.

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

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

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

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

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

Тестирование ПРОГРАММНОЙ СИСТЕМЫ проверяет интегрированное программное обеспечение и может быть выполнено в моделируемой среде на имеющемся оборудовании или на полноценном МЕДИЦИНСКОМ ИЗДЕЛИИ.

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

и документировано. (См. B.6.3).

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

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

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

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

B.5.8 Выпуск ПО

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

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

B.6 ПРОЦЕСС технической поддержки ПО

B.6.1 Установление плана технической поддержки ПО

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

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

Подраздел 6.1 требует, чтобы эти ПРОЦЕССЫ были установлены в плане технической поддержки.

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

ИЗГОТОВИТЕЛЮ нужно планировать ДЕЯТЕЛЬНОСТЬ и ЗАДАЧИ ПРОЦЕССА технической поддержки.

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

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

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

программного обеспечения в настоящий момент может вызывать ОПАСНОСТЬ или уменьшать РИСК.

Важно различать техническую поддержку программного обеспечения (раздел 6) и решение проблем программного обеспечения (раздел 9).

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

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

Центром внимания решения проблем ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ является функционирование комплексной системы управления, которая:

• осуществляет изменения, сохраняя при этом согласованность ПРОГРАММНЫЕ СОСТАВНЫЕ ЧАСТИ КОНФИГУРАЦИИ, в том числе в ФАЙЛЕ МЕНЕДЖМЕНТА РИСКА;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ПРОЦЕСС решения проблем программного обеспечения — это ПРОЦЕСС для анализа и решения проблем (включая несоответствия), вне зависимости от их природы или источника, включая те, которые обнаружены по время выполнения ПРОЦЕССОВ разработки, технической поддержки и других. Цель состоит в предоставлении своевременных и документально подтвержденных средств обеспечения того, что обнаруженные проблемы анализируются и решаются и что тенденции замечены. Данный ПРОЦЕСС в литературе, касающейся разработки программного обеспечения, иногда называется «отслеживание дефекта». В ИСО/МЭК 12207 [9] и МЭК 60601-1-4 [2], поправка 1, он называется «решение проблем». Для целей настоящего стандарта был принято решение называть ПРОЦЕСС «решение проблем программного обеспечения».

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

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

Приложение C (справочное)

электрических испытаний, оборудование электрического контроля и электрооборудование лаборатории. Только часть лабораторного электрооборудования используется в здравоохранении или в качестве изделий для in vitro диагностики.

В соответствии с правовым регулированием или нормативными ссылками изделия для диагностики in vitro относятся к МЕДИЦИНСКИМ ИЗДЕЛИЯМ, при этом не подпадая под область применения IEC 60601-1 [1]. Это связано не только с тем, что изделия для in vitro диагностики не вступают в прямой контакт с пациентами, как обычные МЕДИЦИНСКИЕ ИЗДЕЛИЯ, но и с тем, что эти изделия производятся для различных применений в различных лабораториях. Использование в качестве инструментов для in vitro диагностики или принадлежностей к изделиям для in vitro диагностики встречается редко.

Если лабораторное оборудование используется в качестве изделия для in vitro диагностики, то полученные результаты измерений должны быть ОЦЕНЕНЫ в соответствии с медицинскими критериями. Применение ISO 14971 требуется для осуществления МЕНЕДЖМЕНТА РИСКА. Если подобная продукция содержит программное

данных (результатов измерений) вследствие отказа, вызванного ПО, то должны учитываться требования IEC 62304.

Рисунок C.3 — Применение IEC 62304 с IEC 61010-1

C.6 Взаимосвязь с ISO/IEC 12207

Настоящий стандарт был производным от подходов и концепций ISO/IEC 12207 [9], определяющим требования для ПРОЦЕССОВ жизненного цикла ПО в общих чертах, то есть не ограничиваясь МЕДИЦИНСКИМИ ИЗДЕЛИЯМИ.

Стандарт отличается от ISO/IEC 12207 главным образом в отношении того, что он:

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

Большинство отличий были реализованы исходя из нужд и потребностей промышленности МЕДИЦИНСКИХ ИЗДЕЛИЙ:

• фокусироваться на аспектах безопасности и МЕНЕДЖМЕНТА РИСКА МЕДИЦИНСКИХ ИЗДЕЛИЙ, установленных в ISO 14971;
• выбрать подходящие ПРОЦЕССЫ, полезные в регулируемой внешней среде;
• принять во внимание, что разработка программного обеспечения включена в систему качества (которая охватывает некоторые ПРОЦЕССЫ и требования ISO/IEC 12207);
• уменьшить уровень обобщения, чтобы облегчить применение.

Настоящий стандарт не противоречит ISO/IEC 12207. ISO/IEC 12207 может быть полезным в качестве вспомогательной информации для создания правильно структурированной МОДЕЛИ ЖИЗНЕННОГО ЦИКЛА РАЗРАБОТКИ программного обеспечения, которая включает требования настоящего стандарта.

Таблица C.5, которая была подготовлена подкомитетом 7 ISO/IEC, показывает взаимосвязь между настоящим стандартом и ISO/IEC 12207.

Таблица C.5

Взаимосвязь с процессами ISO/IEC 12207:2008

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

связанных с их применением. Позицию настоящего стандарта объясняет следующее.

IEC 61508 сфокусирован на трех главных вопросах:

1. жизненном цикле МЕНЕДЖМЕНТА РИСКА и ПРОЦЕССАХ жизненного цикла;

2. определении уровней безопасности эксплуатации оборудования;

3. рекомендуемых техниках, инструментах и методах для разработки программного обеспечения и уровнях независимости персонала, ответственного за выполнение различных ЗАДАЧ.

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

Для вопроса 2) настоящий стандарт принимает более простой подход, чем IEC 61508, классифицирующий программное обеспечение на четыре «уровня безопасности эксплуатации оборудования», определенные с точки зрения надежности. Цели надежности идентифицируют после АНАЛИЗА РИСКА, который определяет как тяжесть, так и вероятность причинения ВРЕДА, вызванного отказом ПО.

уменьшении вероятности (и/или тяжести последствий) отказа программного обеспечения.

Вопрос 3) не затронут в настоящем стандарте. Пользователям рекомендуется применять IEC 61508 в качестве источника программных методов, техник и инструментов, с учетом того, что другие подходы могут обеспечить одинаковые РЕЗУЛЬТАТЫ. Настоящий стандарт не содержит рекомендаций относительно независимости лиц, ответственных за один вид ДЕЯТЕЛЬНОСТИ в области программного обеспечения (например, за ВЕРИФИКАЦИЮ) от тех, кто отвечает за другой (например, за проектирование). В частности, настоящий стандарт не требует наличия независимого эксперта по безопасности, поскольку это относится к ISO 14971.

(справочное)

D.1 Введение

В данном приложении приводится общий обзор того, как настоящий стандарт может быть реализован в ПРОЦЕССАХ ИЗГОТОВИТЕЛЯ. Предполагается, что другие стандарты, такие как ИСО 13485 [8], требуют подходящих и сопоставимых ПРОЦЕССОВ.

D.2 Система менеджмента качества

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

D.3 ОЦЕНИВАНИЕ ПРОЦЕССОВ менеджмента качества

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

D.4 Интеграция требований настоящего стандарта в ПРОЦЕССЫ менеджмента качества ИЗГОТОВИТЕЛЯ

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

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

D.5 Контрольный список для малых предприятий, ИЗГОТОВИТЕЛЕЙ, не имеющих сертифицированной СМК

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

При наличии несоответствий необходимо предпринять действия для улучшения ПРОЦЕССА.

Список также может быть использован для ОЦЕНИВАНИЯ ПРОЦЕССОВ после выполнения действия.

Таблица D.1

Приложение ДА (обязательное)

Таблица ДА.1

БИБЛИОГРАФИЯ

<3> В стадии разработки.