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

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

Обоснование требований настоящего стандарта

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

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

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

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

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

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

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

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

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

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

- ДЕЯТЕЛЬНОСТЬ создает план, имеющий отношение к МЕНЕДЖМЕНТУ РИСКА или классификации программного обеспечения по безопасности;

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

- ДЕЯТЕЛЬНОСТЬ является частью МЕНЕДЖМЕНТА РИСКА или классификации безопасности программного обеспечения;

- ДЕЯТЕЛЬНОСТЬ устанавливает систему управления, документации или ведения записей, которая поддерживает МЕНЕДЖМЕНТ РИСКА или классификацию безопасности программного обеспечения;

- ДЕЯТЕЛЬНОСТЬ обычно имеет место, когда классификация связанного с ней ПО неизвестна;

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

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

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

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

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

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

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

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

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

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

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

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

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

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