Национальный стандарт РФ ГОСТ Р МЭК 62304-2013 "Изделия медицинские. Программное обеспечение. Процессы жизненного цикла" (утв. приказом Федерального агентства по техническому регулированию и метрологии от 8 ноября 2013 г. N 1492-ст) (документ не действует)

Национальный стандарт РФ ГОСТ Р МЭК 62304-2013
"Изделия медицинские. Программное обеспечение. Процессы жизненного цикла"
(утв. приказом Федерального агентства по техническому регулированию и метрологии от 8 ноября 2013 г. N 1492-ст)

Medical devices. Software. Life cycle processes

Дата введения - 1 января 2015 г.

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

Предисловие

1 Подготовлен Закрытым акционерным обществом "МЕДИТЕСТ" на основе собственного аутентичного перевода на русский язык международного стандарта, указанного в пункте 4

2 Внесен Техническим комитетом по стандартизации ТК 436 "Управление качеством медицинских изделий"

3 Утвержден и введен в действие приказом Федерального агентства по техническому регулированию и метрологии от 8 ноября 2013 г. N 1492-ст

4 Настоящий стандарт идентичен международному стандарту МЭК 62304:2006 "Программное обеспечение медицинских изделий. Процессы жизненного цикла программного обеспечения" (IEC 62304:2006 "Medical device software - Software life cycle processes").

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

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

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

Введение

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

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

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

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

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

Рисунок 1 - Краткий обзор ПРОЦЕССОВ разработки ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ и РАБОТ

Рисунок 2 - Краткий обзор ПРОЦЕССОВ обслуживания ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ и РАБОТ

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

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

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

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

Приложение А предоставляет объяснение пунктов настоящего стандарта. Приложение В содержит рекомендации по положениям настоящего стандарта.

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

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

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

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

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

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

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

1.1* Цель

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В настоящем стандарте использована нормативная ссылка на следующий стандарт:

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

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

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

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

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

[IEEE 1044:1993, определение 3.1]

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

[IEEE 610.12:1990]

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

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

Примечание - Основано на ИСО/МЭК 12207, определение 3.6.

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

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

[ИСО/МЭК 12207:1999, определение 3.9]

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

[ИСО/МЭК Руководящие указания 51:1999, определение 3.3]

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

[ИСО/МЭК Руководящие указания 51:1999, определение 3.5]

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

[ИСО 14971:2007, определение 2.6]

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

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

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

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

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

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

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

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

Примечание 1 - Определение было разработано Целевой группой глобальной гармонизации (GHTF).

[ИСО 13485, определение 3.7].

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

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

3.13 ОТЧЕТ О ПРОБЛЕМАХ (PROBLEM REPORT): Запись о фактическом или возможном по ведении ПРОГРАММНОГО ПРОДУКТА, из которой пользователь или заинтересованное лицо могут узнать о том, что является опасным, несоответствующим предусмотренному назначению или о том, что противоречит спецификации.

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

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

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

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

[ИСО 9000:2008, определение 3.4.1]

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

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

[ИСО/МЭК 9003:2004, определение 3.11]

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

[ИСО/МЭК Руководящие указания 51:1999, определение 3.2]

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

[ИСО/МЭК Руководящие указания 51:1999, определение 3.10]

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

[ИСО 14971:2007, определение 2.16]

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

[ИСО 14971:2007, определение 2.18]

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

[ИСО 14971:2007, определение 2.19]

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

[ИСО/МЭК Руководящие указания 51:1999, определение 3.1]

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

[ИСО/МЭК 12207:1999, определение 3.25]

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

- несет угрозу жизни;

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

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

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

3.24 МОДЕЛЬ ЖИЗНЕННОГО ЦИКЛА РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ (SOFTWARE DEVELOPMENT LIFE CYCLE MODEL): Концептуальная структура, охватывающая существование ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ от определения требований до запуска в производство, которая:

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

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

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

Примечание - Заимствовано из ИСО/МЭК 12207, определение 3.11.

3.25 ПРОГРАММНЫЙ ЭЛЕМЕНТ (SOFTWARE ITEM): Любая идентифицируемая (выделяемая) часть компьютерной программы.

[ИСО/МЭК 9003:2004, определение 3.14]

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

3.26 ПРОГРАММНЫЙ ПРОДУКТ (SOFTWARE PRODUCT): Совокупность компьютерных программ, процедур и, по возможности, связанных с ними документации и данных.

[ИСО/МЭК 12207:1999, определение 3.26]

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

3.28 ПРОГРАММНЫЙ МОДУЛЬ (SOFTWARE UNIT): ПРОГРАММНЫЙ ЭЛЕМЕНТ, который не может быть разделен на более мелкие части.

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

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

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

[ИСО/МЭК 12207:1999, определение 3.31]

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

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

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

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

[ИСО 9000, определение 3.8.4]

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

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

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

Примечание 2 - Заимствовано из ИСО/МЭК 12207, определение 3.37.

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

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

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

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

- ИСО 13485 (раздел 7), или

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

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

Примечание 2 - Руководство, как применить требования менеджмента качества к ПРОГРАММНОМУ ОБЕСПЕЧЕНИЮ, можно найти в ИСО/МЭК 9003 [11].

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

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

4.3 Классификация ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ в отношении БЕЗОПАСНОСТИ

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

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

- класс А: Невозможны никакие травмы или ущерб здоровью;

- класс В: Возможны НЕЗНАЧИТЕЛЬНЫЕ ТРАВМЫ;

- класс С: Возможны СЕРЬЕЗНЫЕ ТРАВМЫ или смерть.

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

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

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

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

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

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

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

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

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

5 ПРОЦЕСС разработки ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

5.1* Планирование разработки ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

5.1.1 План разработки ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

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

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

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

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

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

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

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

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

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

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

Примечание 5 - План разработки ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ может быть включен в план разработки общей СИСТЕМЫ.

5.1.2 Поддержание плана разработки ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ в актуальном состоянии

ИЗГОТОВИТЕЛЬ должен обновлять план по мере того, как осуществляется разработка (классы А, В, С).

5.1.3 План разработки ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ относительно проектирования и разработки СИСТЕМЫ

a) В плане разработки ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ в качестве входных данных ИЗГОТОВИТЕЛЬ должен указать требования СИСТЕМЫ;

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

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

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

В план разработки ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ ИЗГОТОВИТЕЛЬ должен включить или дать ссылки:

- на стандарты;

- методы;

- инструменты, связанные с разработкой ПРОГРАММНЫХ ЭЛЕМЕНТОВ класса С (класс С).

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

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

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

5.1.6 Планирование ВЕРИФИКАЦИИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

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

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

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

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

d) критерии приемки для ВЕРИФИКАЦИИ РЕЗУЛЬТАТОВ (классы А, В, С).

5.1.7 Планирование МЕНЕДЖМЕНТА РИСКА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

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

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

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

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

b) цель;

c) предусмотренные пользователи документа;

d) процедуры и ответственность за разработку, анализ, одобрение и модификацию (классы А, В, С).

5.1.9 Планирование менеджмента конфигурации ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

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

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

b) ДЕЯТЕЛЬНОСТЬ и ЗАДАЧИ по менеджменту конфигурации ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ;

c) организационную структуру (структуры), отвечающие за осуществление менеджмента конфигурации ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ и ДЕЯТЕЛЬНОСТИ;

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

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

f) случаи, когда следует использовать ПРОЦЕСС решения проблем (классы А, В, С).

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

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

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

5.1.11 Управление ЭЛЕМЕНТАМИ КОНФИГУРАЦИИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ до ВЕРИФИКАЦИИ

ИЗГОТОВИТЕЛЬ должен запланировать размещение ЭЛЕМЕНТОВ КОНФИГУРАЦИИ под управление документированного менеджмента конфигурации, прежде чем они будут ВЕРИФИЦИРОВАНЫ.

5.2* Анализ требований к ПРОГРАММНОМУ ОБЕСПЕЧЕНИЮ

5.2.1 Определение и документирование требований к ПРОГРАММНОМУ ОБЕСПЕЧЕНИЮ в зависимости от требований СИСТЕМЫ

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

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

5.2.2 Содержание требований к ПРОГРАММНОМУ ОБЕСПЕЧЕНИЮ

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

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

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

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

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

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

- необходимость совместимости с модернизациями или многими ПОНП или другими ВЕРСИЯМИ изделий;

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

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

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

- диапазоны;

- пределы;

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

c) средства взаимодействия между ПРОГРАММНОЙ СИСТЕМОЙ и другими СИСТЕМАМИ;

d) ПРОГРАММНЫЕ СРЕДСТВА управления предупреждением и оповещением оператора;

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

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

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

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

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

- контрольный журнал;

- коммуникационная целостность;

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

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

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

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

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

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

Примечание 5 - Для информации относительно требований к разработке удобства и простоты использования (эксплуатационной пригодности) см. МЭК 60601-1-6;

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

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

- форма;

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

- функция;

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

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

j) разрабатываемая документация для пользователя;

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

I) регулирующие требования (классы А, В, С),

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

Примечание 8 - ИСО/МЭК 9126-1 [8] обеспечивает информацию о качественных характеристиках, которая может быть полезна при определении требований к ПРОГРАММНОМУ ОБЕСПЕЧЕНИЮ.

5.2.3 Включение мер УПРАВЛЕНИЯ РИСКОМ в требования к ПРОГРАММНОМУ ОБЕСПЕЧЕНИЮ

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

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

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

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

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

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

5.2.6 Проверка требований к ПРОГРАММНОМУ ОБЕСПЕЧЕНИЮ

ИЗГОТОВИТЕЛЬ должен проверить и документировать, что требования к ПРОГРАММНОМУ ОБЕСПЕЧЕНИЮ:

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

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

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

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

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

f) обеспечивали ПРОСЛЕЖИВАЕМОСТЬ в отношении требований к СИСТЕМЕ или к другому источнику (классы А, В, С),

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

5.3 Проектирование АРХИТЕКТУРЫ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

5.3.1 Преобразование требований к ПРОГРАММНОМУ ОБЕСПЕЧЕНИЮ в АРХИТЕКТУРУ

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

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

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

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

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

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

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

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

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

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

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

5.3.6 Проверка АРХИТЕКТУРЫ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

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

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

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

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

5.4* Детализированная разработка ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

5.4.1 Развитие АРХИТЕКТУРЫ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ в ПРОГРАММНЫЕ МОДУЛИ

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

5.4.2 Разработка детализированного проекта для каждого ПРОГРАММНОГО МОДУЛЯ

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

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

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

5.4.4 Проверка детализированного проекта

ИЗГОТОВИТЕЛЬ должен проверять и документировать, что детализированный проект ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ:

a) соответствует АРХИТЕКТУРЕ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ;

b) не вступает в противоречия с АРХИТЕКТУРОЙ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ (класс С).

5.5* Исполнение и проверка ПРОГРАММНЫХ МОДУЛЕЙ

5.5.1 Исполнение каждого ПРОГРАММНОГО МОДУЛЯ

ИЗГОТОВИТЕЛЬ должен исполнять каждый ПРОГРАММНЫЙ МОДУЛЬ (классы А, В, С).

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

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

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

5.5.3 Критерии приемки ПРОГРАММНЫХ МОДУЛЕЙ

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

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

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

- нет ли в программном коде противоречий с интерфейсами, документированными в детализированном проекте ПРОГРАММНЫХ МОДУЛЕЙ?

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

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

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

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

b) потока данных и текущего контроля;

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

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

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

f) самодиагностики;

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

h) граничных условий (класс С).

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

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

5.6* Программная интеграция и испытания в отношении интеграции

5.6.1 Интеграция ПРОГРАММНЫХ МОДУЛЕЙ

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

5.6.2 Проверка программной интеграции

ИЗГОТОВИТЕЛЬ должен проверить и осуществить записи в отношении следующих аспектов интеграции ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ в соответствии с планом интеграции (см. 5.1.5):

a) ПРОГРАММНЫЕ МОДУЛИ должны быть интегрированы в ПРОГРАММНЫЕ ЭЛЕМЕНТЫ и ПРОГРАММНЫЕ СИСТЕМЫ;

b) аппаратные элементы, ПРОГРАММНЫЕ ЭЛЕМЕНТЫ и поддержка ручного управления (например, интерфейс, приспособленный для человека, диалоговые меню подсказки, распознавание речи, речевое управление СИСТЕМОЙ), интегрированные в СИСТЕМУ (классы В, С).

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

5.6.3 Испытания интегрированного ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

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

5.6.4 Содержание испытаний в отношении интеграции

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

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

- требуемую функциональность ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ;

- реализацию мер УПРАВЛЕНИЯ РИСКОМ;

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

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

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

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

5.6.5 Проверка процедур испытаний в отношении интеграции

ИЗГОТОВИТЕЛЬ должен ОЦЕНИТЬ правильность процедуры испытаний в отношении интеграции (классы В, С).

5.6.6 Проведение регрессионных испытаний

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

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

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

a) документировать РЕЗУЛЬТАТЫ испытаний (соответствует, не соответствует и перечень АНОМАЛИЙ);

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

с) указать лицо, проводившее испытания (классы В, С).

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

- характеристик условий проведения конкретного испытания, показывающих требуемые действия и ожидаемые РЕЗУЛЬТАТЫ;

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

- записей внешних устройств (включая ПРОГРАММНЫЕ инструменты), используемых при проведении испытаний.

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

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

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

5.7* Испытания СИСТЕМЫ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

5.7.1 Установление испытаний в отношении требований ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

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

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

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

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

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

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

Если во время испытаний СИСТЕМЫ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ вносятся изменения, ИЗГОТОВИТЕЛЬ обязан:

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

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

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

5.7.4 ВЕРИФИКАЦИЯ испытаний СИСТЕМЫ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

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

a) стратегии ВЕРИФИКАЦИИ и используемые процедуры испытаний являются соответствующими;

b) процедуры испытаний СИСТЕМЫ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ прослеживаются до требований ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ;

c) все требования ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ были подвергнуты испытаниям или ВЕРИФИЦИРОВАНЫ любым иным способом;

d) РЕЗУЛЬТАТЫ испытаний отвечают требуемым критериям приемки (классы В, С).

5.7.5 Содержание отчета по испытаниям СИСТЕМЫ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

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

a) документировать РЕЗУЛЬТАТЫ испытаний (соответствует, не соответствует и список АНОМАЛИЙ);

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

c) идентифицировать лицо, проводившее испытания (классы В, С).

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

- характеристик условий проведения конкретного испытания, показывающих требуемые действия и ожидаемые РЕЗУЛЬТАТЫ;

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

- записей внешних устройств (включая ПРОГРАММНЫЕ инструменты), используемых при проведении испытаний.

5.8* Выпуск ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

5.8.1 Обеспечение полного завершения ВЕРИФИКАЦИИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

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

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

ИЗГОТОВИТЕЛЬ должен задокументировать все известные остаточные АНОМАЛИИ (классы В, С).

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

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

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

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

5.8.5 Документирование создания выпущенного ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

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

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

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

5.8.7 Архивирование ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

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

a) ПРОГРАММНЫЕ ПРОДУКТЫ и ЭЛЕМЕНТЫ КОНФИГУРАЦИИ;

b) документацию (классы В, С).

5.8.8 Обеспечение воспроизводимости выпуска ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

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

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

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

- упаковку;

- защиту;

- хранение;

- поставку (классы В, С).

6 ПРОЦЕСС технической поддержки ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

6.1 Установление плана технической поддержки ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

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

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

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

2) документирования;

3) оценивания;

4) принятия решения;

5) отслеживания;

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

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

c) использование ПРОЦЕССА МЕНЕДЖМЕНТА РИСКА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ;

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

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

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

1) обновления;

2) местоположения ошибок;

3) исправления, вносимые в коды ("заплатки", "патчи");

4) устаревания;

5) ПОНП (классы А, В, С).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

a) о любых проблемах в отношении выпущенных ПРОГРАММНЫХ ПРОДУКТОВ и последствиях длительного использования неизмененного продукта;

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

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

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

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

Примечание - Требования для изменений ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ, относящиеся к МЕНЕДЖМЕНТУ РИСКА, - см. 7.4.

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

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

7* ПРОЦЕСС МЕНЕДЖМЕНТА РИСКА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

7.1* Анализ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ, способствующего возникновению опасных ситуаций

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

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

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

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

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

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

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

b) дефекты ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ, идентифицированные в определенных функциях ПРОГРАММНОГО ЭЛЕМЕНТА;

c) отказы или неожидаемые РЕЗУЛЬТАТЫ, исходящие от ПОНП;

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

e) обосновано прогнозируемое неправильное применение (классы В, С).

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

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

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

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

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

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

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

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

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

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

7.2.2 Меры по УПРАВЛЕНИЮ РИСКОМ, осуществляемые в ПРОГРАММНОМ ОБЕСПЕЧЕНИИ

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

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

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

c) разработать ПРОГРАММНЫЙ ЭЛЕМЕНТ в соответствии с разделом 5 (классы В, С).

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

7.3 ВЕРИФИКАЦИЯ мер по УПРАВЛЕНИЮ РИСКОМ

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

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

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

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

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

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

a) от опасной ситуации до ПРОГРАММНОГО ЭЛЕМЕНТА;

b) от ПРОГРАММНОГО ЭЛЕМЕНТА до конкретной причины в ПРОГРАММНОМ ОБЕСПЕЧЕНИИ;

c) от причины в ПРОГРАММНОМ ОБЕСПЕЧЕНИИ до мер по УПРАВЛЕНИЮ РИСКОМ;

d) от мер по УПРАВЛЕНИЮ РИСКОМ до ВЕРИФИКАЦИИ мер по УПРАВЛЕНИЮ РИСКОМ (классы В, С).

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

7.4 МЕНЕДЖМЕНТ РИСКА в отношении изменений ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

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

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

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

b) требуются ли дополнительные ПРОГРАММНЫЕ меры по УПРАВЛЕНИЮ РИСКОМ (классы А, В, С).

7.4.2 Анализ влияния изменений ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ на выполненные меры по УПРАВЛЕНИЮ РИСКОМ

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

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

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

8* ПРОЦЕСС менеджмента конфигурации ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

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

8.1.1 Установление средств для идентификации ЭЛЕМЕНТОВ КОНФИГУРАЦИИ

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

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

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

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

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

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

d) для каждого используемого ЭЛЕМЕНТА КОНФИГУРАЦИИ ПОНП (классы А, В, С).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ИЗГОТОВИТЕЛЬ должен создать контрольный журнал, посредством которого в отношении каждого;

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

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

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

d) может быть осуществлена ПРОСЛЕЖИВАЕМОСТЬ (классы А, В, С).

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

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

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

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

ИЗГОТОВИТЕЛЬ должен подготовить ОТЧЕТ О ПРОБЛЕМАХ в отношении каждой проблемы, обнаруженной в ПРОГРАММНОМ ПРОДУКТЕ, ОТЧЕТЫ О ПРОБЛЕМАХ должны быть классифицированы:

a) по типу.

Пример 1 - Корректирующие, предупреждающие или в целях адаптации к новым внешним условиям;

b) масштабу.

Пример 2 - Размер изменения, число затронутых моделей устройств, затронутые поддерживаемые приспособления, вовлеченные ресурсы, время изменения;

c) критичности.

Пример 3 - Влияние на эксплуатационные характеристики, БЕЗОПАСНОСТЬ или ЗАЩИЩЕННОСТЬ

(классы A, В, С).

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

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

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

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

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

c) документировать РЕЗУЛЬТАТЫ исследования и оценки;

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

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

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

Если применимо, ИЗГОТОВИТЕЛЬ должен консультировать заинтересованные стороны относительно существующей проблемы (классы А, В, С).

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

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

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

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

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

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

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

ИЗГОТОВИТЕЛЬ должен проводить анализ с целью определения тенденции в ОТЧЕТАХ О ПРОБЛЕМАХ (классы А, В, С).

9.7 ВЕРИФИКАЦИЯ решения проблем ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

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

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

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

c) был ли ЗАПРОС НА ИЗМЕНЕНИЯ реализован в соответствующих ПРОГРАММНЫХ ПРОДУКТАХ и ДЕЯТЕЛЬНОСТИ;

d) появились ли дополнительные проблемы (классы А, В, С).

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

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

a) РЕЗУЛЬТАТЫ испытаний;

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

c) ВЕРСИЮ испытуемого ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ;

d) соответствующие аппаратные и ПРОГРАММНЫЕ испытуемые конфигурации;

e) испытательное оборудование и средства измерений;

f) данные по испытаниям;

g) идентификацию лица, проводившего испытания (классы А, В, С).

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

[1]	МЭК 60601-1:2005	Изделия медицинские электрические. Часть 1. Общие требования безопасности с учетом основных функциональных характеристик
	IEC 60601-1:2005	Medical electrical equipment - Part 1: General requirements for basic safety and essential performance
[2]	МЭК 60601-1-4:1996	Изделия медицинские электрические. Часть 1. Общие требования к безопасности. 4. Вспомогательный стандарт. Программируемые медицинские электрические системы
	IEC 60601-1-4:1996	Medical electrical equipment - Part 1: General requirements for safety - 4: Collateral standard: Programmable electrical medical systems
[3]	МЭК 61508-3	Системы электрические/электронные/программируемые электронные, связанные с функциональной безопасностью. Часть 3. Требования к программному обеспечению
	IEC 61508-3	Functional safety of electrical/electronic/programmable electronic safety-related systems - Part 3: Software requirements
[4]	МЭК 61010-1:2001	Требования к безопасности электрооборудования для проведения измерений, управления и лабораторного использования. Часть 1. Общие требования
	IEC 61010-1:2001	Safety requirements for electrical equipment for measurement, control, and laboratory use - Part 1: General requirements
[5]	ИСО 9000:2005	Системы менеджмента качества. Определения и словарь
	ISO 9000:2005	Quality management systems - Fundamentals and vocabulary
[6]	ИСО 9001:2000	Системы менеджмента качества. Требования
	ISO 9001:2000	Quality management systems - Requirements
[7]	ИСО 13485:2003	Медицинские изделия. Системы менеджмента качества. Системные требования для целей регулирования
	ISO 13485:2003	Medical devices - Quality management systems - Requirements for regulatory purposes
[8]	ИСО/МЭК 9126-1:2001	Программирование. Качество продукта. Часть 1. Модель качества
	ISO/IEC 9126-1:2001	Software engineering - Product quality - Part 1: Quality model
[9]	ИСО/МЭК 12207:1995	Информационные технологии. Процессы жизненного цикла программного обеспечения
	ISO/IEC 12207:1995	Information technology - Software life cycle processes Amendment 1 (2002) Amendment 2 (2004)
[10]	ИСО/МЭК 14764:1999	Информационные технологии. Сопровождение программного обеспечения
	ISO/IEC 14764:1999	(Information technology - Software maintenance)
[11]	ИСО/МЭК 90003:2004	Программирование. Руководство по применению ИСО 9001:2000 для компьютерного программного обеспечения
	ISO/IEC 90003:200	Software engineering - Guidelines for the application of ISO 9001:2000 to computer software
[12]	ИСО/МЭК Руководящие указания 51:1999	Аспекты безопасности. Руководящие указания по включению их в стандарты
	ISO/IEC Guide 51:1999	Safety aspects - Guidelines for their inclusion in standards
[13]	IEEE 610.12:1990	Глоссарий терминологии программного обеспечения
	IEEE 610.12:1990	IEEE standard glossary of software engineering terminology
[14]	IEEE 1044:1993	Классификация аномалий программного обеспечения
	IEEE 1044:1993	IEEE standard classification for software anomalies
[15]	МЭК 60601-1-6	Изделия медицинские электрические. Часть 1-6. Общие требования безопасности. Эксплуатационная пригодность
	IEC 60601-1-6	Medical electrical equipment - Part 1-6: General requirements for safety - Collateral standard: Usability

Предметный указатель терминов

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

Изменение управления

Изменение запроса

Завершение

Конфигурация идентификации

Управление конфигурацией

Конфигурация учета состояния

Определение

Поставка

Проектирование и обслуживание

Идентификация опасностей

Техническое обслуживание

Сопоставление

Модификация реализации

Планирование

Проблема анализа и модификации

Решение проблемы

Обязательства

Требования

Анализ требований

Анализ РИСКОВ

Управление РИСКАМИ

Программное обеспечение архитектурного проектирования

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

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

Программное обеспечение интеграции

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

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

Версия программного обеспечения

Требования к программному обеспечению анализа

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

Программная реализация блока и тестирование

Проверка

АНОМАЛИЯ

Определение

АРХИТЕКТУРА

Определение

ИЗМЕНЕНИЕ ЗАПРОСА

Определение

ЭЛЕМЕНТ КОНФИГУРАЦИИ

Определение

ПОНП

ПОСТАВКА

Определение

ОЦЕНИВАНИЕ

Переоценивание

ВРЕД

Определение

ОПАСНОСТЬ

Определение

Непредвиденная

ИЗГОТОВИТЕЛЬ

Определение

МЕДИЦИНСКОЕ ИЗДЕЛИЕ

Определение

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

Изменения

Определение

ОТЧЕТ О ПРОБЛЕМАХ

Классификация

Определение

ПРОЦЕСС

Применение

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

Классификация

Управление конфигурацией

Принятие решений

Определение

Развитие

Осуществление

Улучшение

Жизненный цикл

Техническое обслуживание

Сопоставление

Модификация

Упущение

Выходные данные

Физиология

Решение проблем

Менеджмент качества

Обязательства

Требования

Анализ РИСКОВ

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

Программное обеспечение

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

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

Версия программного обеспечения

Системные требования

Верификация

РЕГРЕССИВНОЕ ТЕСТИРОВАНИЕ

Определение

РИСК

Определение

НЕСЕРЬЕЗНАЯ травма

Достаточный обзор

УПРАВЛЕНИЕ РИСКОМ

СЕРЬЕЗНАЯ ТРАВМА

ПОНП

Неприемлемый

АНАЛИЗ РИСКОВ

Определение

УПРАВЛЕНИЕ РИСКОМ

Деятельность

Определение

Измерительное оборудование

Измерение

Требования

Сегрегация

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

Определение

Медицинское изделие

Отчет

Файл менеджмента РИСКА

Определение

БЕЗОПАСНОСТЬ

Определение

ОБЕСПЕЧЕНИЕ БЕЗОПАСНОСТИ

Определение

Требования

СЕРЬЕЗНАЯ ТРАВМА

Определение

НЕСЕРЬЕЗНАЯ ТРАВМА

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

Определение

ПРОГРАММНЫЙ ЭЛЕМЕНТ

Изменения

Определение

Интеграция

Разделы

Производительность

Сегрегация

ПОНП

ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ неизвестного происхождения

См. ПОНП

ПРОГРАММНЫЙ ПРОДУКТ

Определение

Релиз

СИСТЕМА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

Определение

Интеграция

Требования

Тестирование

ЭЛЕМЕНТ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

Определение

Интеграция

Проверка

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

ПОНП

Изменения

Элемент конфигурации

Определение

Номенклатура

Элемент программного обеспечения

СИСТЕМА

Конфигурация

Определение

План разработки

Существование

Внедрение

Требования

ЗАДАЧА

Завершение

Управление конфигурацией

Определение

Поставка

Проектирование и обслуживание

Техническое обслуживание

Сопоставление

Требования

УПРАВЛЕНИЕ РИСКАМИ

Верификация

ПРОСЛЕЖИВАЕМОСТЬ

Определение

ВЕРИФИКАЦИЯ

Определение

ВЕРСИЯ

Определение