Приложение А (справочное). Логическое обоснование требований настоящего стандарта

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

Логическое обоснование требований настоящего стандарта

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

А.1 Логическое обоснование

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

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

- ПРОЦЕССЫ, которые требуются для определения РИСКА, возникающего от действия каждого ПРОГРАММНОГО ЭЛЕМЕНТА в ПО;

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

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

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

Вся деятельность, которая требуется в рамках первой категории ПРОЦЕССОВ, нормативно определена как классы А, В, С, указывая на то, что она необходима вне зависимости от класса БЕЗОПАСНОСТИ ПО, к которому эти классы относятся.

Эта деятельность требуется для классов А, В и С по следующим причинам:

- деятельность создает план, относящийся к МЕНЕДЖМЕНТУ РИСКА или классификации ПО по безопасности;

- деятельность дает результат, который является входными данными для МЕНЕДЖМЕНТА РИСКА или классификации БЕЗОПАСНОСТИ ПО;

- деятельность - часть МЕНЕДЖМЕНТА РИСКА или классификации БЕЗОПАСНОСТИ ПО;

- деятельность устанавливает систему управления, документации или ведения записей СИСТЕМЫ, которые поддерживают МЕНЕДЖМЕНТ РИСКА или классификацию БЕЗОПАСНОСТИ ПО;

- деятельность обычно имеет место, когда классификация связанного с ней ПО неизвестна;

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

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

Деятельность требуется выборочно для ПО классов В и С по следующим причинам:

- деятельность повышает надежность ПО, требуя более детального или более точного проектирования, тестирования или другой ВЕРИФИКАЦИИ;

- деятельность является управленческой, поддерживающей другую деятельность, требуемую для классов В и С;

- деятельность поддерживает коррекцию проблем, связанных с БЕЗОПАСНОСТЬЮ;

- деятельность обеспечивает ведение записей по проектированию, внедрению, ВЕРИФИКАЦИИ и выпуску ПО, связанного с БЕЗОПАСНОСТЬЮ ПО.

Деятельность требуется выборочно для ПО класса С по следующей причине:

- деятельность еще больше повышает надежность СИСТЕМЫ, требуя более тщательного или более точного, более внимательного отношения к отдельным вопросам проектирования, тестирования или другой ВЕРИФИКАЦИИ.

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

А.2 Обобщение требований класса

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

Таблица А.1 - Обобщение требований класса ПО

Пункты и подпункты		Класс A	Класс В	Класс С
Раздел 4	Все требования	X	X	X
5.1	5.1.1, 5.1.2, 5.1.3, 5.1.6, 5.1.7, 5.1.8, 5.1.9	X	X	X
	5.1.5, 5.1.10, 5.1.11		X	X
	5.1.4			X
5.2	5.2.1, 5.2.2, 5.2.4, 5.2.5, 5.2.6	X	X	X
	5.2.3		X	X
5.3	5.3.1, 5.3.2, 5.3.3, 5.3.4, 5.3.6		X	X
	5.3.5			X
5.4	5.4.1		X	X
	5.4.2, 5.4.3, 5.4.4			X
5.5	5.5.1	X	X	X
	5.5.2, 5.5.3, 5.5.5		X	X
	5.5.4			X
5.6	Все требования		X	X
5.7	Все требования		X	X
5.8	5.8.4	X	X	X
	5.8.1, 5.8.2, 5.8.3, 5.8.5, 5.8.6, 5.8.7, 5.8.8		X	X
6.1	6.1	X	X	X
6.2	6.2.1, 6.2.2, 6.2.4, 6.2.5	X	X	X
	6.2.3		X	X
6.3	Все требования	X	X	X
7.1	Все требования		X	X
7.2	Все требования		X	X
7.3	Все требования		X	X
7.4	7.4.1	X	X	X
	7.4.2, 7.4.3		X	X
Раздел 8	Все требования	X	X	X
Раздел 9	Все требования	X	X	X
Примечание - Знак X указывает на обязательность выполнения требования.