База ГОСТовallgosts.ru » 11. ЗДРАВООХРАНЕНИЕ » 11.040. Медицинское оборудование

ГОСТ Р 55544-2013 Программное обеспечение медицинских изделий. Часть 1. Руководство по применению ИСО 14971 к программному обеспечению медицинских изделий

Обозначение: ГОСТ Р 55544-2013
Наименование: Программное обеспечение медицинских изделий. Часть 1. Руководство по применению ИСО 14971 к программному обеспечению медицинских изделий
Статус: Действует
Дата введения: 08/01/2014
Дата отмены: -
Заменен на: -
Код ОКС: 11.040.01
Скачать PDF: ГОСТ Р 55544-2013 Программное обеспечение медицинских изделий. Часть 1. Руководство по применению ИСО 14971 к программному обеспечению медицинских изделий.pdf
Скачать Word:ГОСТ Р 55544-2013 Программное обеспечение медицинских изделий. Часть 1. Руководство по применению ИСО 14971 к программному обеспечению медицинских изделий.doc

Текст ГОСТ Р 55544-2013 Программное обеспечение медицинских изделий. Часть 1. Руководство по применению ИСО 14971 к программному обеспечению медицинских изделий



ФЕДЕРАЛЬНОЕ АГЕНТСТВО

ПО ТЕХНИЧЕСКОМУ РЕГУЛИРОВАНИЮ И МЕТРОЛОГИИ


НАЦИОНАЛЬНЫЙ

СТАНДАРТ

РОССИЙСКОЙ

ФЕДЕРАЦИИ


ГОСТ Р 55544— 2013/IEC/TR 80002-1:2009

Программное обеспечение медицинских изделий

Часть 1

Руководство по применению ИСО 14971 к программному обеспечению медицинских изделий

IEC/TR 80002-1:2009

Medical devices software — Part 1: Guidance on the application of ISO 14971

medical devices software (IDT)

Издание официальное

CnwapnMfrofM

2014


Предисловие

1    ПОДГОТОВЛЕН Закрытым акционерным обществом «МЕДИТЕСТ» на основе собственного аутентичного перевода на русский язык международного стандарта, указанного в пункте 4

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

3    УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 28 авг/ста 2013 г. No 620-ст

4    Настоящий стандарт идентичен международному документу МЭК/ТО 80002-1:2009 «Программное обеспечение медицинских изделий. Часть 1. Руководство по применению ИСО 14971 к программному обеспечению медицинских изделий» (IEC/TR 80002-1:2009 «Medical devices software — Part 1: Guidance on the application of ISO 14971 medical devices software»).

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

5    ВВЕДЕН ВПЕРВЫЕ

Правила применения настоящего стандарта установлены в ГОСТР 1.0—2012 (раздел 8). Информация об изменениях х настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе «Национальные стандарты», а официальный текст изменении и поправок — в ежемесячном указателе «Национальные стандарты». В случае пересмотра (замены) или отмены наслюящегс стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя «Национальные стандарты». Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интервал (gost.ru)

© Стамдартинформ. 2014

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

в

Содержание

Приложение ДА (справочное) Сседения о соответствии ссылочных международных стандартов ссылочным национальным стандартам Российской Федерации (и действующим в этом качестве межгосударственным стандартам).................... 57

fll

Введение

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

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

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

В программном обеспечении, последовательности событий, которые способствуют ОПАСНЫМ СИТУАЦИЯМ, могут быть разделены на две категории:

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

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

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

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

МЕНЕДЖМЕНТ РИСКА—это всегда сложная задача, которая становится еще более сложной, если этлкягаатга прпгрямммогп л6аг.пачаиия Нижаг.палу1П1миа пункты спЛйржятлппопмитАПкму»п информацию относительно особенностей программного обеспечения и служат основой для понимания ИС014971:2007 в отношении программного обеспечения.

Структура стандарта

Настоящий стандарт построен таким образом, чтобы следовать структуре ИС014971:2007 и служить руководством для каждого вида деятельности по МЕНЕДЖМЕНТУ РИСКА в отношении программного обеспечения.

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

НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

Программное обеспечение медицинских изделий Ч а с т ь 1

Руководство по применению ИС014971 к программному обеспечению медицинских изделий

Medical devices software. Part 1. Guidance on the application of ISO 14971 medical devices software

Дата введения — 2014—08—01

1 Общие положения

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

Настоящий стандарт предоставляет собой руководство по применению требований, содержащихся в ИС014971 а/Медицинские издегия. Применение менеджмента риска к медицинским изделиям» (Medical devices — Application of risk management to medical devices) к программному обеспечению медицинских изделий, со ссылкой на МЭК 62304 *Программное обеспечение медицинских изделий. Процессы жизненного цикла программного обесг,ечения» (Medical device software — Software life cycfe processes). Настоящий стандарт ничего не добавляет и не изменяет в ИС014971 или МЭК 62304.

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

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

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

Настоящий стандарт не включает:

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

-    аспекты производства или системы менеджмента качества программного обеспечения: или

-    инструменты разработки программного обеспечения.

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

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

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

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

МЭК 62304:2006 «Программное обеспечение медицинских изделий—процессы жизненного цикла программного обеспечения»(IE2 62304:2006. Medical device software — Software life cycle processes)

Издание официальное

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

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

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

В настоящем стандарте применены термины и определения, данные в ИСО 14971, МЭК 62304, а также нижеследующие термины и определения.

Примечание — Список определенных терминов можно найти на странице 58.

2.1    РАЗНООБРАЗИЕ (DIVERSITY): Форма избыточности, при которой избыточные элементы используют разные (различающиеся) компоненты, технологии или методы с целью снизить вероятность того, что все элементы откажут одновременно по общей причине.

2.2    ИЗБЫТОЧНОСТЬ (REDUNDANCY): Обеспечение многочисленных компонентов или механизмов для выполнения одной и той жефункции таким образом, чтобы отказ одного или более компонентов или механизмов не препятствовал выполнению функции.

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

3    Общие требования к МЕНЕДЖМЕНТУ РИСКА

3.1    ПРОЦЕСС МЕНЕДЖМЕНТА РИСКА

3.1.1    Общие положения

Текст ИСО 14971

3 Общие требования к МЕНЕДЖМЕНТУ РИСКА

3.1 ПРОЦЕСС МЕНЕДЖМЕНТА РИСКА

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

-АНАЛИЗРИСКА;

-    ОЦЕНИВАНИЕ РИСКА:

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

• производственную и ПОСТПРОИЗВОДСТВЕННУЮ информацию.

Документированные ПРСЦЕССЫ жизненного цикла продукции (см. раздел 7 (3)) должны включать соответствующие элементы ПРОЦЕССА МЕНЕДЖМЕНТА РИСКА.

Примечания

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

2    ПРОЦЕСС МЕНЕДЖМЕНТА РИСКА схематически представлен на рисунке 1.

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

Соответствие требованиям данного подраздела проверяют путем контроля необходимых документов.


Рисунок 1 — Схематичное представление ПРОЦЕССА МЕНЕДЖМЕНТА РИСКА


Л


J



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

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

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

Примечание 2 — Например. все систематические, а не случайные отказы программного обеспечения (как и многие типы аппаратных отказов или поломок) и их вероятность не могут быть то**ю оценены. Вот почему способ, которым компонент вероятности РИСКА применяется к программному обеспечению, существенно различается. См. 4.4.3.

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

-    выбор подходящих аппаратных средств для поддержки программного обеспечения:

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

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

-    исключение сложного программного обеспечения, не являющегося необходимым.

3.1.2 Итерация

Типичный цикл разработки ЖИЗНЕННОГО ЦИКЛА программного обеспечения часто использует повторные действия (итерацию) Использование итерации делает возможным:

•    исследование осуществимости других проектов программного обеспечения:

-    разработку различных ПРОГРАММНЫХ ЭЛЕМЕНТОВ в различные сроки:

•    обеспечение выпуска различных ВЕРСИЙ программного обеспечения;

•    исправление ошибок, сделанных во время ПРОЦЕССА разработки программного обеспечения.

МЭК 62304 требует итерации деятельности по МЕНЕДЖМЕНТУ РИСКА, а также координации с

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

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

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

3.1.3    Упреждающий или реактивный подход к проектированию БЕЗОПАСНОСТИ

МЕНЕДЖМЕНТ РИСКА должен начинаться на ранних стадиях проектирования с надежных входных

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

Преимущества упреждающего проектирования БЕЗОПАСНОСТИ:

• с самого начала специфюсация СИСТЕМЫ включает не только то, что МЕДИЦИНСКОЕ ИЗДЕЛИЕ должно делать, но и определяет поведение СИСТЕМЫ, которого следует избегать с целью снижения РИСКА:

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

-    в то время как АРХИТЕКТУРА завершена до состояния готового проекта, меры по УПРАВЛЕНИЮ РИСКОМ могут разрабатываться без доработки;

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

3.1.4    Характеристики безопасности СИСТЕМ, включающих программное обеспечение

Крайне желательные характеристики безопасности СИСТЕМ включают:

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

b)    использование только очень простых ПРОГРАММНЫХ ЭЛЕМЕНТОВ. СВЯЗАННЫХ С БЕЗОПАСНОСТЬЮ:

c)    распределение СВЯЗАННЫХ С БЕЗОПАСНОСТЬЮ ПРОГРАММНЫХ ЭЛЕМЕНТОВ между некоторым числом независимых процессоров;

d)    достаточные аппаратные возможности для запуска всего СВЯЗАННОГО С БЕЗОПАСНОСТЬЮ программного обеспечения, когда это необходимо и без одобрения;

e)    использование детерминированного подхода к срокам проектирования программного обеспечения:

f)    надлежащая обработка отказа, например:

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

2)    обеспечение ограниченной функциональности в условиях отказа:

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

4)    быстрое восстановление после отказа.

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

h) средства определения и (или) предотвращения вмешательства в СВЯЗАННЫЕ С БЕЗОПАСНОСТЬЮ данные.

3.2 Ответственность высшего руководства

Текст ИС014971

3.2 Ответственность высшего руководства

ВЫСШЕЕ РУКОВОДСТВО должно обеспечивать свидетельства своей приверженности ПРОЦЕССУ МЕНЕДЖМЕНТА РИСКА посредством.

•    обеспечения необходиьыми ресурсами;

-    назначения квалифицированного персонала (см. 3.3) для целей МЕНЕДЖМЕНТА РИСКА.

ВЫСШЕЕ РУКОВОДСТВО должно:

•    разрабатывать и документировать политику установления критериев допустимости РИСКА. Данная политика должна гарантировать, что установленные критерии основаны на применимых национальных и региональных нормативных документах и соответствующих международных стандартах, а также учитывают доступную информацию, такую как современный уровень научно-технического развития и потребности заинтересованных сторон;

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

Примечание — Вышеуказанные документы могут быть включены в документы системы менеджмента качества ИЗГОТОВИТЕЛЯ, и на нвх могут быть ссылки в ФАЙЛЕ МЕНЕДЖМЕНТА РИСКА.

Соответствие требованиям данного подраздела проверяют путем контроля необходимых документов.


Как ИСО 14971. так и МЭК 62304 предполагают наличие системы менеджмента качества. Требования к ВЫСШЕМУ РУКОВОДСТВУ при МЕНЕДЖМЕНТЕ РИСКА перечислены е ИСО 14971, п. 3.2.

Примечание — п. 3.1 ИСО 14971 устанавливает, что МЕНЕДЖМЕНТ РИСКА может быть составной частью системы менеджмента качества, а п. 4.1 МЭК 62304 устанавливает, что демонстрация способности ИЗГОТОВИТЕЛЯ последовательно выполнять требования потребителей и применимые регугырукнцие требования может осуществляться при помощи системы менеджмента качества, соответствующей ИСО 13485. или системы менеджмента качества, требуемой национальным регулированием. МЭК 62304 также содержит рекомендации по положениям приложения В.4. 4.1. устанавливая, что необходимо определить менеджмент риска как неотъемлемую часть системы менеджмента качества как общих рамок для применения подходящих инженерных методов и техник программирования.

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

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

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

ИЗГОТОВИТЕЛЬ должен рассмотреть вопрос об установлении требований к поставщикам (см. ИС013485)(1]. п. 7.4 по управлению поставщиками), требуя от них продемонстрировать, например;

• эффективный МЕНЕДЖМЕНТ РИСКА в соответствии с ИС014971;

- эффективную практику разработки программного обеспечения в соответствии с МЭК 62304;

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

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

3.3 Квалификация персонала

3.3.1 Общие положения

Текст ИС014971

3.3 Квалификация лероонала

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

Примечание — Задачи по МЕНЕДЖМЕНТУ РИСКА могут решать представители разных функциональных подразделений с учетом имеощихся у них специальных знаний.

Соответствие требованиям данного подраздела проверяют путем контроля вышеуказанных записей.


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

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

Кроме того, должна быть рассмотрена квалификация каждого участника группы по МЕНЕДЖМЕНТУ РИСКА по отношению к программному обеспечению, в результате чего может потребоваться специальная подготовка.

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

3.3.2 ПРЕДУСМОТРЕННОЕ ПРИМЕНЕНИЕ — знания предметной области

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

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

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

3.3.3 Опыт программирования и подход

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

Назначение опытных сотр/дникое особенно важно для выполнения следующих ЗАДАЧ в отношении программного обеспечения:

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

-    анализа РИСКОВ, связанных с отказом программного обеспечения;

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

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

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

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

3.4 План МЕНЕДЖМЕНТА РИСКА

Текст ИС014971

3.4 План МЕНЕДЖМЕНТА РИСКА

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

Данный план должен вклочать как минимум:

a) объем применения запланированной деятельности по МЕНЕДЖМЕНТУ РИСКА, в том числе идентификацию и описание МЕДИЦИНСКОГО ИЗДЕЛИЯ и стадий ею жизненною цикла, к которым применим каждый элемент плана;

b)    распределение ответственности и полномочий;

c)    требования к анализу деятельности по МЕНЕДЖМЕНТУ РИСКА;

d)    критерии допустимости РИСКА, основанные на политике ИЗГОТОВИТЕЛЯ по установлению допустимого РИСКА, включая случаи, когда вероятность причинения ВРЕДА не может быть определена;

e)    действия по ВЕРИФИКАЦИИ;

0    действия по сбору и анализу информации, относящейся к МЕНЕДЖМЕНТУ РИСКА, на производственной и ПОСТПРОИЗВОДСТВЕННОЙ стадиях.

Примечания

1    Руководящие указания по разработке плана МЕНЕДЖМЕНТА РИСКА см. в приложении F.

2    Необязательно все элементы плана МЕНЕДЖМЕНТА РИСКА разрабатывать одновременно. План или его элементы можно разрабатывать поэтапно.

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

Среди прочих можно рассматривать следующие варианты:

•    построение матрицы (рисунки D.4 и D.5). иллюстрирующей допустимые и недопустимые комбинации вероятности причинения ВЭЕДА и ТЯЖЕСТИ ВРЕДА:

•    дальнейшее подраэделздие области матрицы (апренебрежимо малый РИСК», «допустимый РИСК при условии ею минимизации» и т. д.) с требованием к РИСКАМ, чтобы они сначала были уменьшены, насколько это практически осуществимо, прежде чем признать их допустимыми (см. D.8).


3.4.1 Общие положения

Любой из вариантов следует выбирать в соответствии с политикой ИЗГОТОВИТЕЛЯ в отношении установления критериев допусгимости РИСКА и на основании применимых национальных или региональных нормативных документов, а также соответствующих международных стандартов с учетом доступной информации, такой как современный уровень научно-технического развития и интересы заинтересованных сторон (см. 3.2). Руководство по установлению данных критериев см. в D.4.

При внесении изменений в план МЕНЕДЖМЕНТА РИСКА в течение ЖИЗНЕННОГО ЦИКЛА МЕДИЦИНСКОГО ИЗДЕЛИЯ необхо/ымо сделать запись об изменениях в ФАЙЛЕ МЕНЕДЖМЕНТА РИСКА.

Соответствие требованиям данного подраздела проверяют путем контроля файла МЕНЕДЖМЕНТА РИСКА.


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

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

-    заявлевиеотом, что программное обеспечение будет разрабатываться в соответствии с МЭК 62304;

-    ссылку на аспекты разработки программного обеспечения, которые являются специфичными для осуществления МЕНЕДЖМЕНТА РИСКА программного обеспечения (см. примечание);

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

Примечание — Ссылка на план разработки программного обеспечения может быть самым простым способом для включения специфичных аспектов разработки программного обеспечения для осуществления МЕНЕДЖМЕНТА РИСКА. См. также 3.4.2 и 3.4.3, в которых обсуждается взаимосвязь между планом МЕНЕДЖМЕНТА РИСКА и планое разработки программного обеспечения, а также определенные связанные с РИСКОМ темы плана разработки программного обеспечения согласно МЭК 62304.

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

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

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

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

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

3.4.2    Взаимосвязь между планом МЕНЕДЖМЕНТА РИСКА и планом разработки программного обеспечения

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

•    комбинация документов по планированию удовлетворяет требованиям обоих стандартов и осуществлена таким способом, который поддается проверке;

-    все планы совместимы друг с другом:

•    все планы доступны для использования в установленные сроки:

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

3.4.3    Специфические связанные с РИСКОМ темы плана разработки программного обеспечения согласно МЭК 62364

План разработки программного обеспечения должен обеспечить, чтобы ПРОЦЕСС разработки программного обеспечения, стандарты, методы и средства, связанные с разработкой программного обеспечения (описанные в плане ра:работки программного обеспечения согласно МЭК 62304. раздел 4). были эффективными мерами по УПРАВЛЕНИЮ РИСКОМ (см. 6.2.2.6 для обсуждения ПРОЦЕССА как меры по УПРАВЛЕНИЮ РИСКОМ). Это может быть достигнуто путем предоставления доказательств другими организациями. поставщиками, а таоке от других проектов в рамках организации. Если это неизвестно, осуществляется планирование и ВЕРИФИКАЦИЯ результативности внутри проекта.

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

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

3.5 ФАЙЛ МЕНЕДЖМЕНТА РИСКА

Текст ИС0 14971

3.5 ФАЙЛ МЕНЕДЖМЕНТА РИСКА

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

-    АНАЛИЗЕ РИСКА:

-    ОЦЕНИВАНИИ РИСКА:

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

-    оценивании допустимости любого(ых) ОСТАТОЧНОПО(ЫХ) РИСКА(ОВ).

Примечания

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

2    ФАЙЛ МЕНЕДЖМЕНТА Р4СКА может быть представлен в любой форме или на любом носителе информации.


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

Все вышеупомянутое должно прослеживаться до ВЕРИФИКАЦИИ программного обеспечения (см. МЭК 62304. п. 7.3.3).

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

В таблице 1 перечислены требования МЭК 62304 к документации, которую следует включать в ФАЙЛ МЕНЕДЖМЕНТА РИСКА в дополнение к требованиям ИС014971.


Таблица 1 — Требования МЗК 62304 к документации, которую следует включать в ФАЙЛ МЕНЕДЖМЕНТА РИСКА в дополнение к требованиям ИСО 14971.

Пункты и подпункты МЭК 62304

Документация ФАЙЛА МЕНЕДЖМЕНТА РИСКА

4.3C)

Класс БЕЗОПАСНОСТИ программного обеспечения, назначенный каждой ПРОГРАММНОЙ СИСТЕМЕ

4.30

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

7.1.4

Возможные причины, по которым ПРОГРАММНЫЙ ЭЛЕМЕНТ может способствовать ОПАСНОЙ СИТУАЦИИ

7.2.1

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

7.3.2

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

9.5

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


4 АНАЛИЗ РИСКА

4.1 ПРОЦЕСС АНАЛИЗА РИСКА


Текст ИСО 14971

4 АНАЛИЗ РИСКА

4.1 ПРОЦЕСС АНАЛИЗА РИСКА

АНАЛИЗ РИСКА для рассматриваемого МЕДИЦИНСКОГО ИЗДЕЛИЯ необходимо проводить в соответствии с 4.2—4.4. Деятельность по запланированному АНАЛИЗУ РИСКА, а также результаты АНАЛИЗА РИСКА должны быть зарегистрированы в ФАЙЛЕ МЕНЕДЖМЕНТА РИСКА.

Примечания

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

2    Некоторые методы АНАЛИЗА РИСКА описаны в приложении G.

3    Дополнительные руководящие указания по методам АНАЛИЗА РИСКА МЕДИЦИНСКИХ ИЗДЕЛИЙ для диагностики in-vitго приведены в приложении Н.

4    Дополнительные руководящие указания по методам АНАЛИЗА РИСКА в отношении токсикологических ОПАСНОСТЕЙ приведены в пригожем ни I.


В дополнение к записям, требуемым в 4.2—4.4. документы, относящиеся к проведению и результатам АНАЛИЗА РИСКА, должны включать как минимум:

a)    описание и идентификацию рассматриваемого МЕДИЦИНСКОГО ИЗДЕЛИЯ;

b)    идентификацию лица (лиц) и организации, выполнивших АНАЛИЗ РИСКА:

c)    область применения и дату проведения АНАЛИЗА РИСКА.

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

Соответствие требованиям данного подраздела проверяют путем контроля файла МЕНЕДЖМЕНТА РИСКА.


Как установлено в ИС0 14971, АНАЛИЗ РИСКА является термином, который используется, чтобы охватить три различных вида деятельности:

•    идентификацию ПРЕДУСМОТРЕННОГО ПРИМЕНЕНИЯ;

- идентификацию известных или прогнозируемых ОПАСНОСТЕЙ (и их причин);

•    определение РИСКА от каждой ОПАСНОСТИ и ОПАСНОЙ СИТУАЦИИ.

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

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

ТЯЖЕСТЬ ВРЕДА в условиях наихудшего случая, для которого программное обеспечение является способствующим фактором, является первичной информацией для установления уровня тщательности ПРОЦЕССОВ разработки программного обеспечения (см. МЭК 62304, п. 4.3). Информация, приведенная в

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

4.2 ПРЕДУСМОТРЕННОЕ ПРИМЕНЕНИЕ и определение характеристик, относящихся к

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

4.2.1 Общее

Текст ИС014971

4.2 ПРЕДУСМОТРЕННОЕ ПРИМЕНЕНИЕ и определение характеристик, относящихся к БЕЗОПАСНОСТИ МЕДИЦИНСКОГО ИЗДЕЛИЯ

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


Примечания

1    В контексте настоящего стандарта неправильное применение означает непредусмотренное или ненадлежащее применение МЕДИиИНСКОГО ИЗДЕЛИЯ.

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

Соответствие требованиям дайною подраздела проверяют путем контроля файла МЕНЕДЖМЕНТА РИСКА.


Хотя каждое МЕДИЦИНСКОЕ ИЗДЕЛИЕ имеет ПРЕДУСМОТРЕННОЕ ПРИМЕНЕНИЕ, должна быть рассмотрена возможность преднамеренного или непреднамеренного неправильного применения. Хотя это касается не только программного обеспечения, но его использование может привести к повышенному РИСКУ неправильного применения из-за следующею:

-    поведение МЕДИЦИНСКОГО ИЗДЕЛИЯ является более сложным и поэтому более трудным для управления или понимания:

•    пользователь может чрезмерно полагаться на программное обеспечение, не понимая ею возможностей и ограничений:

•    МЕДИЦИНСКОЕ ИЗДЕЛИЕ может быть настраиваемым, и пользователь может быть не знаком с текущей конфигурацией:

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

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

4.2.2    Интерфейс пользователя

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

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

a)    различную потребность а размере памяти для различных языков:

b)    использование различных кодировок:

c)    использование букв вместо символов:

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

e)    формат данных и пунктуацию в числах:

f)    различные требования к расположению для различных языков и (или) кодировок;

g Утоддержку валидации.

См. МЭК 62366 [5] дополнительно к ИС0 14971 для ПРОЦЕССА эксплуатационной пригодности.

4.2.3    МЕДИЦИНСКИЕ И ВЗАИМОСВЯЗАННЫЕ С НИМИ ИЗДЕЛИЯ

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

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

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

МЭК 80001-1 (6] устанавливает требования к интеграции МЕДИЦИНСКИХ ИЗДЕЛИЙ в информационной сети медицинского учреждения. 8 частности, устанавливает ответственность ИЗГОТОВИТЕЛЯ и лица, которое интегрирует МЕДИЦИНСКОЕ ИЗДЕЛИЕ в информационную сеть.

4.3 Идентификация ОПАСНОСТЕЙ

Тонет ИС014971

4.3 Идентификация ОПАСНОСТЕЙ

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

Данный перечень необходимо поддерживать в рабочем состоянии в ФАЙЛЕ МЕНЕДЖМЕНТА РИСКА.

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

Соответствие требование данного подраздела проверяют путем контроля файла МЕНЕДЖМЕНТА РИСКА.


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

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

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

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

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

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

Программное обеслечение может способствовать ОПАСНЫМ СИТУАЦИЯМ несколькими способами, включая некоторые из нижеследующих (см. также приложение В):

•    программное обеспечение может правильно реализовывать небезопасные СИСТЕМНЫЕ требования. приводя к поведению, небезопасная природа которого не ощущается до тех пор. пока не возникает фактический ВРЕД:

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

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

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

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

•    удаление потенциально опасных функций программного обеспечения из спецификации программного обеспечения:

-    меры по УПРАВЛЕНИЮ РИСКОМ, которые внедрены в программное обеспечение для предотвращения причинения ВРЕДА (см. МЭК 62304 п. 5.2.3):

-    идентификация частей программного обеспечения, которые должны реализовываться с низкой плотностью дефектов, и частей спецификации программного обеспечения, которые должны подвергаться специальным испытаниям (МЭК62304. п. 4.3);

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

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

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

•    предоставление неверно* информации врачу или пациенту:

•    неправильная идентификация пациента (в случаях, если МЕДИЦИНСКОЕ ИЗДЕЛИЕ хранит информацию о пациенте или рецепты);

•    отклонение запроса или его задержка, вызванные АНОМАЛИЕЙ программного обеспечения.

Примечание — Для многих медицинских изделий задержка или отклонение запроса не подразумевают ВРЕДА пациенту.

Идентифицированные ОПАСНОСТИ должны включать в себя как ОПАСНОСТИ, относящиеся к программному обеспечению, которое работает в соответствии с его спецификацией, так и ОПАСНОСТИ, относящиеся к АНОМАЛИЯМ программного обеспечения (см. 6.1).

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

•    неправильный ввод данных;

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

•    перегрузка пользователей чрезмерными данными или излишним числом тревожных сообщений (см. МЭК 6236615)).

4.4 Определение РИСКАЮВ) для каждой ОПАСНОЙ СИТУАЦИИ

4.4.1 Общие положения


Текст ИС014971

4.4 Определение РИСКА(ОВ) для каждой ОПАСНОЙ СИТУАЦИИ

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

Примечания

1    Для идентификации не выявленных ранее ОПАСНЫХ СИТУАЦИЙ можно использовать системные методы, применимые в конфетной ситуации (см. приложение G).

2    Примеры ОПАСНЫХ СИТУАЦИЙ приведены в Н.2.4.5 и Е.4.

3    Источником ОПАСНЫХ СИТУАЦИЙ могут стать промахи, упущения и заблуждения.

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

Любая система, используемая для качественной или количественной градации вероятности причинения ВРЕДА или ТЯЖЕСТИ БРЕДА, также должна бьггь зарегистрирована в ФАЙЛЕ МЕНЕДЖМЕНТА РИСКА.

Примечания

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

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

3    Информацию или данные для ОПРЕДЕЛЕНИЯ РИСКОВ можно получить из:

a)    опубликованных стандартов:

b)    научно-технической информации:

c)    данных о применении подобных МЕДИЦИНСКИХ ИЗДЕЛИЙ, включая опубликованные сведения об инцидентах:

d)    данных испытаний эксплуатационной пригодности типичными пользователями:

e)    клинических данных:

() результатов соответствующих исследований:

д) экспертных заключений

h) схем внешней оценки качества.

Соответствие требованием данного подраздела проверяют путем контроля файла МЕНЕДЖМЕНТА РИСКА.


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

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

4.4.2 Методы идентификации

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

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

Анализ видов и последствий отказов (FMEA-аналиэ) является методом анализа «снизу вверх» (см. МЭК 60812 (2)). который начинается с компонента или подсистемы (для программного обеспечения это ПРОГРАММНЫЙ ЭЛЕМЕНТ в МЭК 62304) и ставит вопрос: «Если этот элемент откажет, какими будут последствия?».

Ввиду трудности предвидения того, какие дефекты программного обеспечения будут присутствовать в каждом ПРОГРАММНОМ ЭЛЕМЕНТЕ, в стартовой точке для FMEA-анализа следует перечислить все СВЯЗАННЫЕ С БЕЗОПАСНОСТЬЮ требования каждого ПРОГРАММНОГО ЭЛЕМЕНТА и рассмотреть вопрос: «Если это требование не выполняется, каковы будут последствия?».

Это приводит к идентификации ЭЛЕМЕНТОВ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ, отказ которых может вызвать вред, и идентификации того, какие типы отказа должны быть предотвращены.

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

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

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

4.4.3 Вероятность

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

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

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

Примечание — Р, — эго вероятносгь возникновения ОПАСНОЙ СИТУАЦИИ. Р2 — это вероятность того, что ОПАСНАЯ СИТУАЦИЯ приведэт к причинению ВРЕДА.

Рисунок 1 — Графическое гредсгавление взаимосвязи ОПАСНОСТИ, последовательности событий.

ОПАСНОЙ СИТУАЦИИ и ВРЕДА (ИСО 14971. приложение Е)

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

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

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

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

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

4.4.4 ТЯЖЕСТЬ

Определение ТЯЖЕСТИ для связанного с программным обеспечением РИСКА оказывает влияние на использующийся ПРОЦЕСС разработки программного обеспечения. Согпасно МЭК 62304 степень тщательности этого ПРОЦЕССА завесит от ТЯЖЕСТИ ВРЕДА, который может причинить программное обеспечение.

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

5 ОЦЕНИВАНИЕ РИСКА

Твист ИСО 14971

5 ОЦЕНИВАНИЕ РИСКА

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

Примечания

1    Руководящую указания по принятию решения о допустимости риска приведены в D.4.

2    Применение соогветствуощих сгандарюв как один из критериев проектирования МЕДИЦИНСКИХ ИЗДЕЛИИ мажет являться частью деятельности по УПРАВЛЕНИЮ РИСКОМ, что отекает требованиям 6.3—6.6.

Соответствие требованием данного раздела проверяют путем контроля файла МЕНЕДЖМЕНТА РИСКА.


Как описано в 4.4.3, сложно определить вероятность отказов программного обеспечения. Когда это приводит к невозможности определить вероятность ВРЕДА, тогда РИСК должен оцениваться только на основе ТЯЖЕСТИ ВРЕДА.

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

Твист ИСО 14971 6 УПРАВЛЕНИЕ РИСКОМ 6.1 Уменьшение РИСКА

При необходимости умен>шения РИСКА следует осуществлять деятельность по УПРАВЛЕНИЮ РИСКОМ, как описано е 6 2—6 7


6.1 Уменьшение РИСКА

Программные аспекты уменьшения РИСКА рассматриваются в пунктах с 6.2 по 6.7.

6.2 Анализ возможностей УПРАВЛЕНИЯ РИСКОМ

Текст ИС014971

6.2 Анализ возможностей УПРАВЛЕНИЯ РИСКОМ

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

ИЗГОТОВИТЕЛЬ должен применять один или несколько способов УПРАВЛЕНИЯ РИСКОМ, перечисленных ниже в порядке приоритетов:

a)    внутреннюю БЕЗОПАСНОСТЬ, обеспечиваемую проектом и конструкцией;

b)    защитные меры, предусмотренные в самом медицинском изделии или в ПРОЦЕССЕ его изготовления;

c)    информацию по БЕЗОПАСНОСТИ.

Примечания

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

2    Меры по УПРАВЛЕНИЮ РИСКОМ могут уменьшить ТЯЖЕСТЬ ВРЕДА или вероятность причинения ВРЕДА, или и то и другое вместе.

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

4    В отношении РИСКОВ, для которых не может быть определена вероятность причшения ВРЕДА см. D.3.2.3.

5    Руководящие указания в отношении информации по БЕЗОПАСНОСТИ приведены в приложении J.

Выбранные меры по УПРАВЛЕНИЮ РИСКОМ должны быть зарегистрированы в ФАЙЛЕ МЕНЕДЖМЕНТА РИСКА.

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

Соответствие требованиям данного подраздела проверяют путем контроля файла МЕНЕДЖМЕНТА РИСКА.


6.2.1    Выбор возможностей по УПРАВЛЕНИЮ РИСКОМ для сложных СИСТЕМ

6.2.1.1    Общие положения

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

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

6.2.1.2    Внутренняя БЕЗОПАСНОСТЬ, обеспечиваемая проектом и конструкцией

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

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

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

•    устранение характеристик, которые не являются необходимыми:

•    изменение АРХИТЕКТУРЫ программного обеспечения с целью избегания последовательностей событий, которые приводят к ОПАСНЫМ СИТУАЦИЯМ;

•    упрощение интерфейса пользователя для сокращения вероятности ошибок человека при использовании;

•    установление правил проектирования программного обеспечения, чтобы избежать АНОМАЛИЙ программного обеспечения.

Примером к предыдущему перечислению может служить:

•    использование только статического распределения памяти с целью избегания АНОМАЛИЙ программного обеспечения. связанных с динамическим распределением памяти;

•    использование строгой (защищенной) ВЕРСИИ языка программирования, чтобы избегать структур, которые вероятно могут привести к ошибкам программирования.

6.2.1.3    Защитные меры

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

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

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

6.2.1.4    Информация по БЕЗОПАСНОСТИ

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

6.2.1.5    Какие события нуждаются в разработке мер по УПРАВЛЕНИЮ РИСКОМ?

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

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

УЩерб пациенту

Другие

последовательности

событий

Некорректные выходные данные программного обеспечения


Аппаратная защита (меры по УПРАВЛЕНИЮ РИСКОМ) от отказов обнаружения опасных СОСТОЯНИЙ

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

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

•    входные данные в ПРОГРАММНУЮ СИСТЕМУ в целом;

•    выходы из ПРОГРАММНОЙ СИСТЕМЫ в целом:

-    внутренние интерфейсы между программными модулями.

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

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

•    прогром мныо моры по У ТРАВЛЕНИЮ РИСКОМ могут проверять входные донныо и отклонять »«о6о-эопасные или противоречивые величины:

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

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

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

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

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

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

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

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

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

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

6.2.2 Методы УПРАВЛЕНИЯ РИСКОМ

6.2.2.1 Обзор

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

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

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

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

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

Некоторые отдельные меры по УПРАВЛЕНИЮ РИСКОМ, а также руководство по определению причин отдельных РИСКОВ описаны более подробно в пп. 6.2 2.2.6.2.2.3.6.2.2 4.6.2 2.5 и 6.2 2.6.

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

6.2.2.2.1    Краткий обзор

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

6.2.2.2.2    Изначально безопасная конструкция на основе особенностей АРХИТЕКТУРЫ

ОПАСНОСТИ, связанной с функцией программного управления, можно избежать, например, используя аппаратные средства для реализации этой функции. Точно также ОПАСНОСТИ, связанной с функцией аппаратных средств (изнашивание, усталость), можно избежать, используя программное обеспечение.

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

Особой проблемой в СИСТЕМАХ, использующих программное обеспечение, является представление о том. что нет предела той степени, до которой различное программное обеспечение может совместно использовать общую физическую инфраструктуру. Это представление ложно.

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

-    может ли связанный с БЕЗОПАСНОСТЬЮ ПРОГРАММНЫЙ ЭЛЕМЕНТ получить доступ к своему процессору, когда необходимо?

• может ли связанному с БЕЗОПАСНОСТЬЮ ПРОГРАММНОМУ ЭЛЕМЕНТУ быть обеспечено достаточно времени процессора, чтобы завершить его ЗАДАЧУ до того, как небезопасное состояние перерастет в неблагоприятное событие?

-    можно ли продемонстрировать, что никакой другой ПРОГРАММНЫЙ ЭЛЕМЕНТ не может прервать или вмешаться в работу СВЯЗАННОГО С БЕЗОПАСНОСТЬЮ ПРОГРАММНОГО ЭЛЕМЕНТА?

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

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

6.2.2.2.3    Отказоустойчивая АРХИТЕКТУРА

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

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

Отказоустойчивая конструкция обычно обладает некоторой ИЗБЫТОЧНОСТЬЮ. Это может быть простым дублированием жизненно важною компонента для обеспечения продолжения функционирования, если един из компонентов откажет, и/м может состоять из дополнительных компонентов, которые обнаруживают отказ и переводят выполнение операции на альтернативный режим работы, возможно и с ограниченной функциональностью.

Отказоустойчивость может использоваться для поддержания существенной функции е случае отказа программного обеспечения. Тогда простая ИЗБЫТОЧНОСТЬ, использующая множество копий одной и той же программы, скорее всего недостаточна, поскольку тот же самый дефект будет присутствовать в каждой копии программы.

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

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

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

6.2.2.2.4 Разделение, уменьшающее РИСК, происходящий от программных причин

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

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

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

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

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

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

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

Испытания СИСТЕМ в лабораторных условиях могут определить достаточные физические и временные ресурсы в отношении проводимых испытуемых случаев (условий), в то время как загрузка приложений или исполнение программно-аппаратной среды (другие ПРОЦЕССЫ, выполняемые в том же самом блоке) в реальных практических условиях вызывают отказ программного обеспечения, который приводит к 8РЕДУ.

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

Эффективное разделение должно демонстрировать, что при нормальной работе:

a)    искажение потока данньх предотвращено: не СВЯЗАННЫЕ С БЕЗОПАСНОСТЬЮ ПРОГРАММНЫЕ ЭЛЕМЕНТЫ не могут изменять СВЯЗАННЫЕ С БЕЗОПАСНОСТЬЮ данные:

b)    предотвращено изменение управляющего потока данных:

1)    СВЯЗАННЫЕ С БЕЗОПАСНОСТЬЮ функции всегда могут выполняться в нужное время без воздействия на них не СВЯЗАННЫХ С БЕЗОПАСНОСТЬЮ ПРОГРАММНЫХ ЭЛЕМЕНТОВ:

2)    не СВЯЗАННЫЕ С БЕЗОПАСНОСТЬЮ ПРОГРАММНЫЕ ЭЛЕМЕНТЫ не могут изменять СВЯЗАННЫЕ С БЕЗОПАСНОСТЬЮ ПРОГРАММНЫЕ ЭЛЕМЕНТЫ.

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

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

6.2.2.3    Подробности о защитных мерах

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

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

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

6.2.2.4    Незамедлительное оповещение и предотвращение ОПАСНЫХ СИТУАЦИЙ

Важным классом мер по УПРАВЛЕНИЮ РИСКОМ является тот. который увеличивает вероятность предотвращения ОПАСНОЙ СИТУАЦИИ.

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

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

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

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

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

В тех случаях, когда этот подход неприменим, например, если предупреждающая мера осуществлена в программном обеспечении, должны использоваться методы, обеспечивающие целостность программного обеспечения (см. 6.2 2.6).

6.2.2.6    ПРОЦЕСС — как м*ра по УПРАВЛЕНИЮ РИСКОМ

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

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

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

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

Отправной точкой для обеспечения тщательного ПРОЦЕССА разработки программного обеспечения может быть включение деятельности и ЗАДАЧ, определенных в МЭК 62304. в ПРОЦЕСС разработки программного обеспечения. Дополнительные элементы, которые следует учесть при рассмотрении тщательного ПРОЦЕССА разработки программного обеспечения, должны включать:

•    компетентность персонала — навыки, квалификация, опыт и обучение (кто разрабатывает программное обеспечение?);

•    методы — пригодность сгецификации. проектирования, кодирования и методов испытаний (каков ПРОЦЕСС разработки?);

- точность, официальность, область анализа и тщательных проверок (сколько статических анализов выполняется?):

• инструменты — качество инструментов, таких как компиляторы, требования ПРОСЛЕЖИВАЕМОСТИ и инструменты управления конфигурацией (какие инструменты используются во время разработки программного обеспечения ?).

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

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

6.2.3    Рассмотрение программного обеспечения неизвестного происхождения (ПОНП)

Решение использовать ПЭНП часто принимается во время проектирования СИСТЕМЫ. Чем выше

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

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

a)    предотвращать использование тех характеристик ПОНП. использование которых нежелательно:

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

c) обеспечивать, в случае необходимости. МЕДИЦИНСКОЕ ИЗДЕЛИЕ дополнительной информацией.

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

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

Теист ИС014971

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

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

Выполнение каждой меэы по УПРАВЛЕНИЮ РИСКОМ должно быть верифицировано. Данная ВЕРИФИКАЦИЯ должна быть зарегистрирована в ФАЙЛЕ МЕНЕДЖМЕНТА РИСКА.

Результативность мер по УПРАВЛЕНИЮ РИСКОМ должна быть верифицирована, а результаты ВЕРИФИКАЦИИ — зарегистрированы в ФАЙЛЕ МЕНЕДЖМЕНТА РИСКА.

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

Соответствие требованиям данного подраздела проверяют путем контроля файла МЕНЕДЖМЕНТА РИСКА.


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

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

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

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

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

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

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

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

6.4 ОЦЕНИВАНИЕ ОСТАТОЧНОГО РИСКА

Текст ИСО 14971

6.4 ОЦЕНИВАНИЕ ОСТАТОЧНОГО РИСКА

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

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

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

Примечание — Руководящие указания по информированию об остаточном РИС ЩАХ) приведены в приложении J.

Соответствие требованиям данного подраздела проверяют путем контроля файла МЕНЕДЖМЕНТА РИСКА и эксплуатационных документов.


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

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

6.5 Анализ соотношения РИСКУпольза

Текст ИС014971

6.5 Анализ соотношения РИСК/польэа

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

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

Результаты оценивания должны быть зарегистрированы в ФАЙЛЕ МЕНЕДЖМЕНТА РИСКА.

Примечание — См. также D.6.

Соответствие требоеатям данного подраздела проверяют путем контроля файла МЕНЕДЖМЕНТА РИСКА.


Нет дополнительных разъяснений для программного обеспечения.

6.6 РИСКИ, возникающие вследствие мер по УПРАВЛЕНИЮ РИСКОМ

Текст ИС014971

6.6 РИСКИ, возникающие вследствие выполнения мер по УПРАВЛЕНИЮ РИСКОМ

Эффективность выполнения мер по УПРАВЛЕНИЮ РИСКОМ необходимо анализировать с точки зрения:

a)    возникновения новых ОПАСНОСТЕЙ и ОПАСНЫХ СИТУАЦИЙ;

b)    влияния выполнеины> мер по УПРАВЛЕНИЮ РИСКОМ на РИСКИ, определенные для ранее идентифицированных ОПАСНЫХ СИТУАЦИЙ.

Любыми новыми или возросшими РИСКАМИ необходимо управлять в соответствии с требованиями. приведенными в 4.4—6.5.

Результаты анализа мер по УПРАВЛЕНИЮ РИСКОМ следует зарегистрировать в ФАЙЛЕ МЕНЕДЖМЕНТА РИСКА.

Соответствие требованиям данного подраздела проверяют путем контроля файла МЕНЕДЖМЕНТА РИСКА.

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

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

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

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

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

6.7 Полнота УПРАВЛЕНИЯ РИСКОМ

Текст ИС014971

6.7 Полнота УПРАВЛЕНИЯ РИСКОМ

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

Соответствие требованиям данного подраздела проверяют путем контроля файла МЕНЕДЖМЕНТА РИСКА.


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

7 ОЦЕНИВАНИЕ допустимости совокупного ОСТАТОЧНОГО РИСКА

Текст ИС014971

7 ОЦЕНИВАНИЕ допустимости совокупного ОСТАТОЧНОГО РИСКА

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

Примечание — Руководящие указания по ОЦЕНИВАНИЮ совокупного ОСТАТОЧНОГО РИСКА приведены в D.7.

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


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

Примечание — Руководящие указания по информированию об осгаточном РИСКЕ(АХ) приведены в приложении J.

Результаты оценивания совокупного ОСТАТОЧНОГО РИСКА должны быть зарегистрированы в ФАЙЛЕ МЕНЕДЖМЕНТА РИС<А.

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


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

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

8 Отчет по МЕНЕДЖМЕНТУ РИСКА

Текст ИСО 14971

8 Отчет по МЕНЕДЖМЕНТУ РИСКА

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

•    план МЕНЕДЖМЕНТА РИСКА реализован должным образом: сооокупный ОСТАТОЧНЫЙ РИСК лолпетсл допустимым;

•    применяют надлежащие способы получения необходимой производственной и ПОСТПРОИЗВОДСТВЕННОЙ информацш.

Результаты анализа ПРОЦЕССА МЕНЕДЖМЕНТА РИСКА должны быть зарегистрированы в отчете по МЕНЕДЖМЕНТУ РИСКА и включены в ФАЙЛ МЕНЕДЖМЕНТА РИСКА.

В плане МЕНЕДЖМЕНТА РИСКА должны быть указаны лица, имеющие необходимые полномочия и ответственные за проведение анализа ПРОЦЕССА МЕНЕДЖМЕНТА РИСКА [см. 3.4, перечисление Ь)].

Соответствие данному разделу проверяют путем контроля файла МЕНЕДЖМЕНТА РИСКА.


Раздел 6 и пп. 7.3.3 МЭК 62304 должны быть рассмотрены для включения в состав анализа ПРОЦЕССА МЕНЕДЖМЕНТА РИСКА.

9 Производственная и ПОСТПРОИЗВОДСТВЕННАЯ информация

Текст ИС014971

9 Производственная и ПОСТПРОИЗВОДСТВЕННАЯ информация

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


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

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

b)    новые или пересмотренные стандарты.

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

Данную информацию необходимо оценивать с точки зрения соответствия требованиям к БЕЗОПАСНОСТИ, особенно с /четом того:

•    существуют ли не выявленные ранее ОПАСНОСТИ или ОПАСНЫЕ СИТУАЦИИ;

•    не стал ли недопустимым РИСК(И). определенный(ые) ранее для какой-либо ОПАСНОЙ СИТУАЦИИ.

При положительном ответе на любой изданных вопросов необходимо:

•    оценить влияние еыиеуказанных факторов на ранее осуществленную деятельность по МЕНЕДЖМЕНТУ РИСКА и результаты оценивания вернуть на вход ПРОЦЕССА МЕНЕДЖМЕНТА РИСКА;

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

Результаты оценивания должны быть зарегистрированы в ФАЙЛЕ МЕНЕДЖМЕНТА РИСКА.

Примечания

1    Отдельные аспекты ПОСТПРОИЗВОДСТВЕННОГО мониторинга являются предметом национальных или региональных регламентов. В таких случаях могут быть задействованы дополнительные меры (например. перспективное ПОСТПРОИЗВОДСТВЕННОЕ оценивание).

2    См. также |3]. B.2.

Соответствие требованиям данного раздела проверяют путем контроля файла МЕНЕДЖМЕНТА РИСКА и другой соответствующей документации.


МЕНЕДЖМЕНТ РИСКА программного обеспечения продолжается в течение всего ЖИЗНЕННОГО ЦИКЛА программного обеспечения, включая ПРОЦЕСС технической поддержки программного обеспечения (см. МЭК 62304, раздал 6) и ПРОЦЕСС решения проблем программного обеспечения (см. МЭК 62304. раздел 9).

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

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

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

ЭЭ

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

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

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

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

Обсуждение определений

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

Согласно определениям в ИСО 14971. ОПАСНОСТЬ не может привести к вреду до тех пор, пока последовательность событий или других обстоятельств (включая условия нормального применения) не приведет к возникновению ОПАСНОЙ СИТУАЦИИ (си. рисунок А.1). Эта последовательность событий может включать как единичные события, так и комбинации событий. Приложение D.2 ИСО 14971 дает представление об ОПАСНОСТЯХ и ОПАСНЫХ СИТУАЦИЯХ. Приложение Е ИСО 14971 дает представление о примерах ОПАСНОСТЕЙ, прогнозируемых последовательностях событий и ОПАСНЫХ СИТУАЦИЯХ.

Рисунок А.1 — Взаимосвязь между последовательностью событий. ВРЕДОМ и ОПАСНОСТЬЮ

Причиной ОПАСНОСТИ или ОПАСНОЙ СИТУАЦИИ может быть любая последовательность событий, комбинация которых может привести к ОПАСНОЙ СИТУАЦИИ. Данная ОПАСНОСТЬ может иметь одну, несколько или множество возможных причин (последовательностей отбытий).

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

Программное обеспечение может вызывать ОПАСНЫЕ СИТУАЦИИ, способствуя, прежде всего, возникновению последовательности событий, которая переводит ОПАСНОСТЬ в ОПАСНУЮ СИТУАЦИЮ (См. таблицу А.1).

Таблица А.1 — Взаимосвязи между опасностями, прогнозируемыми последовательностями событий, опасными ситуациями и возможньм ВРЕДОМ.

Опасность

Продсиыуема» посподоаа' тольиость событий о«люча» программное обеспечение

Инициирующее

причина

Опасная

ситуация

Вред

Электрическая энергия

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

(1)    Программный алгоритм имеет ограничения.

(2)    Программное обеспечение правильно определено. но имеет АНОМАЛИИ

Чрезмерный ток подается к глазу пациента через имплантат

Серьезные

ожоги.

Потеря

зрения

Окончание таблицы А. 1

Опасность

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

Иницяируюшая

причина

Опасная

си|уаиия

Вред

Потеря медицинской функции

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

(1)    Программное обеспечение не способно работать с необычными входными данными.

(2)    Программное обеспечение отказывает при обнаружении неверных установок оборудования.

(3)    Аппаратные средства не предоставляют достаточных ресурсов, чтобы поддерживать своевременную работу устройства

(1)    Изделие не может обеспечить лечение, когда требуется.

(2)    Изделие работает при неправильной установке.

(3)    Изделие не может предупреждать об угрожающих жизни состояниях

Ухудшение

состояния

пациента.

Смерть

Игнорирование пациента медицинским персоналом.

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

1) Интерфейс ПО-человек путает пользователя.

(2)    Выходные данные программы превышают способность пользователя реагировать.

(3)    Пользователь не понимает ограничений программного обеспечения

(1)    Неверное лечение пациента.

(2)    Отсутствие своевременной реакции иа чрезвычайные ситуации.

(3)    Чрезмерное доверие программному обеспечению заменяет личную инициативу

Ухудшение

состояния

пациента.

Смерть

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

Примеры использования программных средств

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

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

Таблица В.1 — Примеры использования программных средств

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

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

Задаваемые вопросы

Аварийные сигналы и предупреждения

Приоритет

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

Определяют ли спецификации, как система реагирует на множественные аварийные условия?

Есть ли несколько уровней сигналов тревоги?

Перекрывает ли сигнал тревоги более высокого уровня аудиосигнал тревоги с более низким уровнем? Сохраняется ли какой-либо сигнал тревоги, пока пользователь не отреагирует на него?

Защитные меры

Защитные меры не определены для каждого состояния тревоги или категории тревог.

Не определен сброс тревоги после срабатывания аварийной защиты

Создают ли защитные меры проблемы в использовании, т. е. может ли пользователь безопасно далее использовать изделие после защитного действия?

Отключение/беэопасный

режим/эоссгановление

Действия безопасного режима недостаточны.

Действие безопасного режима создает новые ОПАСНОСТИ

Является ли действие безопасного режима подходящим для намеченного применения?

Рассмотрел ли медицинский персонал сценарии безопасного режима? Очевидно ли состояние безопасного режима для пользователя?

Пользовательский

интерфейс

Переполненный или плохой пользовательский интерфейс маскирует «реальное» аварийное условие. Действия, предпринимаемые в ответ на сигнал тревоги, не ясны

Рассмотрел ли медицинский персонал защитные меры для использования?

Журнал

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

Обнаруженные ошибки зарегистрированы?

Журнал является достаточно большим?

Хранение журнала надежно?

Как очищается журнал? Пользователь знает, когда журнал очищается?

Продолжение таблицы В. 1

Обпаст» функционирования npoipBHмного обеспечения

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

Задаваемые вопросы

Слышимость

Фоновый шум подавляет сигнал тревоги.

Сигнал тревоги настолько громкий, что операторы находят альтернативные методы, чтобы отключить сигнал тревоги.

Аудиосистема отказывает, и пользователь не узнает об ошибке

Учитывается ли окружающая среда предназначенного применения при разработке аудиосигнала?

Были ли пользователи вовлечены в разработку проекта пользовательского интерфейса?

Как аудиосистема проверяется при включении или при работе с пациентом?

Критические состояния цикла электропитания

Целостность данных

Энергонезависимая запись в ПРОЦЕССЕ при отключении.

Критические параметры не сохраняются. чтобы возобновлять лечение после отключения электропитания. Критические параметры непреднамеренно перезаписываются из-за сфытой АНОМАЛИИ программного обеспечения во время его работы

Что происходит с записью памяти, которая была в ПРОЦЕССЕ, когда отключается электроэнергия? Программное обеспечение изготовлено с учетом возможного отключения электроэнергии? Энергонезависимое хранение проверено при включении напряжения? Критические параметры проверены перед использованием?

Перезагрузка

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

Перезагрузка использовалась как мера УПРАВЛЕНИЯ РИСКОМ? Ставится ли вход/выход управления под угрозу во время цикла перезагрузки?

Пользователь знает о перезагрузках?

Восстановление

МЕДИЦИНСКОЕ ИЗДЕЛИЕ недоступно для предназначенного применения. однако инициализация при включении происходит.

Энергонезависимые отказы при включении — что вы делаете? Пользователь не знает, что критические настройки восстанавливаются заводскими насгроюами по умолчанию

Время восстановления является проблемой БЕЗОПАСНОСТИ? Доступность МЕДИЦИНСКОГО ИЗДЕЛИЯ является проблемой БЕЗОПАСНОСТИ?

Как энергонезависимая память влияет на отказоустойчивые защитные меры?

Режимы энергопотребления

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

Любые меры УПРАВЛЕНИЯ РИСКОМ поставлены под угрозу при режимах с низкой мощностью?

Можно ли восстановление после режимов с низкой мощностью рассматривать как стартовое состояние для деятельности по ВЕРИФИКАЦИИ и валидации?

Критические пользовательские средства управлеиия/применимость

Регулироеание/иавигация/

выбор

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

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

Требует ли приспособляемый параметр двухступенчатой операции для изменения?

Обпасгь функционирования программною обеспечения

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

В вол данных

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

Следует ли побудить пользователя к подтверждению?

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

Требуется ли от пользователя регистрация в качестве администратора, чтобы подтвердить критические входные данные или отвергнуть ошибку?

Доступность

Скрытое управление отключением. Средства управления сенсорным экраном не функционируют при работе в хирургических перчатках.

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

Изменения экрана

Сигнал тревоги «автоматически» вызывает показ экранов выключателя

Были ли оценены автоматические выключатели экрана?

Конструкция пользовательского интерфейса

Использование цветов игнорирует общие формы дальтонизма. Пользователь не может определить, какое условие вызвало тревогу

Как будет страдающий дальтонизмом оператор интерпретировать сообщение об ошибке?

Были ли пользователи привлечены к разработке требований конструкции пользовательского интерфейса?

Отображение

Диагностические изображения

Аннулирование ориентации. Изображение некорректно соотносится с пациентом

Используются ли методы, гарантирующие правильную ориентацию изображения?

Как изображения связаны с пациентом?

Диагностические кривые

Неподходящий фильтр отображения. Совмещение имен, покажемте, ошиб-

U1 намерений, ишпСы разверти.

сжатие с потерями

Какое содержание частоты требуется для отображения?

Мещицииишй мврсиивл Оыл ииивким-лен с этим требованием?

Был ли фильтр отображения полностью охарактеризован, то есть известно ли. что отклоняется и что пропускается сверх полного диапазона входных данных?

Аппаратные средства контроля

Алгоритмы управления двигателем

Составное завершение, совмещение имен, синхронизация, переполнение, ошибка порта (последовательный порт/параллельный порт)

Какова частота выборки?

При пропорционально-интегральнодифференциальном (ПИД) регулировании интегральное звено ограничивается?

Алгоритм был охарактеризован по всем вариациям выпускаемых аппаратных средств?

При управлении с обратной связью, какие проверки осуществляются для подтверждения сигнала обратной связи?

Все ли типы данных были оценены для микропроцессора и компилятора в использовании?

Продолжение таблицы В. 1

Обпаст» функционирования npoipBHмного обеспечения

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

Задаваемые вопросы

Применяемая энергия

Отсутствие проверки всей энергии «входов» первоначально и непрерывно во время терапии.

Система БЕЗОПАСНОСТИ отказывает. но пользователь об этом не осведомлен

Вое утверждения постоянно верифицируются на запланированной основе? Может ли ошибка «общего режима» существовать в программном обеспечении управления терагыей и программном обеспечении монитора БЕЗОПАСНОСТИ?

Мониторы БЕЗОПАСНОСТИ проверены при скачке напряжения или в присутствии пациента?

Дискретность

«Застрявший» бит.

Изменения бита остаются необнаруженными из-за интервала опроса

Программное обеспечение обнаруживает тог бит. который «застрял» (никогда не меняется)?

Обсуждался ли интервал опроса с системным или аппаратным инженером?

Калибровка/ самотесгирование Проверки диапазона Калибровка испытания (определенная калибровка программного обеспечения)

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

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

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

Обнаружение ошибки аппаратных средств

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

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

Пользователю сообщается обо всех ошибках аппаратных средств?

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

Самоочисгка

Пользователь прерывает ПРОЦЕСС очистки в середине цикла

Программное обеспечение проводит завершение цикла?

Может ли потерпеть неудачу программное обнаружение незавершенного цикла очистки?

Изменяющаяся поставка

Обнаружение неподходяшвй калибровки.

Отсутствие проверки всех изменяющихся «входов» первоначально и во время терапии

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

Жизнеобеспечение

Безопасное состояние никогда не определено.

Из многих путей блокировки один не делает невозможными прерывания. Не делается резервных копий для функций жизнеобеспечения

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

Обпасгь функционирования программною обеспечения

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

Мониторинг

Решение

Общий режим ошибки в проверяемом программмном обеспечении. Работа нескольких программ вызывает неправильный результат решения

Программное обеспечение управления терапией и программное обеспечение мониторинга терапии разрабатывались отдельно?

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

Деактивация

Система управления не оповещается э том. что система мониторинга отключает подсистему.

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

Управляющая подсистема осведомлена о действиях подсистемы мониторинга?

Как деактивируются параметры, связывающиеся пользователем или сетевыми системами?

Отображение

Отображаемые ветчины не были обновлены, но пользователь не осведомлен об этом.

За гы си отображения осуществляют на двух или более уровнях приоритета

Как пользователю сообщается о «замершем» дисплее?

Видеомон текст сохраняется перед приоритетным прерыванием?

Измерение

Неправильная синхронизация сбора данных или частоте дискретизации

Подходит ли частота дискретизации для частотного содержимого сигнала? Величина измерения хранится в последовательных устройствах по всем программным слоям?

Интерфейсы (взаимодействия)

Плохая

передача данных

Функция передает значение в микролитрах. а драйвер ожидает значения в милгылитрах.

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

Каждая функция программного обеспечения проверяет прошедшие параметры?

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

Аргументы модифицируются в обрабатывающем слое более высокого приоритета?

Сеть

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

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

Было ли программное обеспечение разработано так. чтобы не реагировать на физические условия сети? Может ли дистанционная связь ухудшить работу системы, неоднократно посылая команды или фальсифицированные данные?

Проверяет ли МЕДИЦИНСКОЕ ИЗДЕЛИЕ. что уже используется системное имя?

Продолжение таблицы В. 1

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

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

Данные

Медицинская информация

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

Может ли произойти отображение множества независимых идентификаторов. чтобы закольцевать обнаружение путаницы?

Могут ли быть включены критические идентификаторы с фактическими данными как двойная проверка?

Сообщения

Сообщение содержит неверные данные или определяет их в неверной последовательности или без единиц измерения

Какие сообщения будут использоваться в медицинских целях?

Какова серьезность ВРЕДА, если данные неверны?

Какова вероятность того, что врач не заметит проблемы?

Базы данных

Повреждение данных из-за побочных эффектов от отказов системного уровня или ПОНП

Как можно обнаружить повреждение данных до их использования?

Можно ли это делать при каждом использовании, а не только при запуске?

Диагностика

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

Отображения обнаружения объекта, искажающего результаты исследования. подавляет отображение асистолии на дисплее.

Была ли тщательно рассмотрена иерархия определения тревоги, в том числе медицинским персоналом?

Преобразование данных

Арифметические ошибки точности приводят к неправильному результату.

Алгоритм использует или отображает некорректные единицы

Какая арифметическая точность требуется?

Как могут быть закодированы математические формулы, чтобы обеспечить надлежащую точность?

Автоматизированная профилактическая техническая поддержка

Базовая диагностика изменяет данные временно, но в то же время код приложения извлекает данные для фактического использования. Базовая диагностика мешает правильной синхронизации

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

Диагностика заблокирована во время критических циклов?

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

Параметры настройки

Отсутствие или недостаточная защита доступа к критическим параметрам конфигурации или данным

Какие данные считаются критическими и не должны изменяться пользователями или должны требовать полномочий администратора, чтобы сделать это?

Является ли аудиторская проверка необходимой?

Функциональный доступ

Отсутствие или недостаточная защита доступа к элементам управления терапией или к работе прибора

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

Интерфейс доступа

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

Что можно разрешить удагыть? Стоит ли полагаться на предполагаемый дистанционный контроль системы или нет?

Обласг» функционирования программною обеспечения

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

Исполнение

Емкость/затрузка/время

реагирования

Критическая синхронизация затрагивается при пиковых нагрузках. Последовательность транзакций/ входных данных/выходных данных затрагивается, или данные терюгся при пиковых нагрузках.

Пиковые нагрузки системы затрагивают устройство управления

Во время пиковых нагрузок или когда пределы мощности достигнуты, данные или синхронизация будут потеряны или затронуты способами, которые нельзя обнаружить?

Будут ли входные и выходные данные стоять в очереди в детерминированной последовательности при пиковых нагрузках?

Были ли критическая функциональность и меры УПРАВЛЕНИЯ РИСКОМ проверены при таких напряженных условиях?

Были ли осуществлены меры по УПРАВЛЕНИЮ РИСКОМ, чтобы обнаружить пределы?

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

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

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

Таблица В.2 — Примеры программных причин, которые могут вызвать побочные эффекты

Программные причины

Типы

ВЕРИФИКАЦИИ

Проверка

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

Вычислительные

Деление на ноль

Использование ловушек отслеживания ошибок времени за-lycxa. защищенное кодирование

X

X

д

Выход результата за пределы диапазоне переменной

Проверки диапазона, использование переменных с плава куцей точкой

X

X

Д

Офугление переменных с плавающей точкой

Применение четких алгоритмов

X

Некорректная проверка пределов диапазона переменных

Защищенное кодирование

X

X

С

Продолжение таблицы В. 2

Типы

ВЕРИФИКАЦИИ

Испытанна {модульное, иигограииоииоо)

Проверка

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

Ошибка сравнения рациональной переменной с переменной целого типа (080)

Защищенное кодирование

X

X

Связанные с аппаратными средствами

I М ....

Работа с ЭСППЗУ: длительное время ответа, выработка ресурса

Применение специальных режимов (поблочная запись), за-гысь только при изменении данных, запись в кэш и обновление ЭСППЗУ только при сбоях питания

X

В

ЦП или аппаратные причины

Проверка ЦП при включении питания. С КС-тес г исполняемого кода, тестирование оперативной памяти, проверка встроенного таймера и часов, проверка энергозависимой памяти, проверка времен ожидания ответов аппаратных модулей, проверка датчиков короткого замыкания, проверка датчиков по ответу на заданный сигнал

X

Шумы

Фильтрация цифровых и аналоговых входных сигналов, проверка процедур обработки прерывания для всех типов прерываний — как используемых, так и неиспользуемых

'

АНОМАЛИИ периферийного аппаратного обеспечения

Задержки запуска конвертации аналогового сигнала в цифровой или из цифрового в аналоговый, проверка времени ответа и других требований к интерфейсу, проверка причинности

X

В

В ре мен нью

. . -_■■■

Условия работы с ресурсами

Идентификация и защита (блокировка использования) совместно с используемыми ресурсами в процессе их обновления. реализация одного нециклического ПРОЦЕССА для оценки совместно используемых ресурсов, анализ совместно ис-ниямуомьл ресурсом

С

Пропущенные сроки ожидания ответа

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

в

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

Пропущенные прерывания

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

в

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

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

в

Типы

ВЕРИФИКАЦИИ

Испытание (модульное, интеграционное)

Проверка

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

Таймеры

Определение времен сброса таймеров и установка таймера соответственно, определение максимального значения времени для таймера, не ведущего к ОПАСНОЙ СИТУАЦИИ

в

Режим работы

Непредусмотренное завершение программы

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

д

Проблемы при отключении / повторном включении / многократном включении

Самотестирование при включении для ЦП. оперативной памяти. таймера и часов, энергозависимой памяти. СКС-тест исполняемого кода, тестирование периферии и т. п. Соответствующая разработка в отношении статуса выполнения программы, инициализация переменных, усредняемых по времени, реинициализация периферижых устройств, иници-а/ызация статуса СИСТЕМЫ из энергозависимой памяти, внешний монитор напряжения или сброса питания

АНОМАЛИИ запуска/ завершения работы

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

Вход/выход в режиме низкого напряжения питания

Правильная обработка прерываний

X

В

Ошибки в данных

L

т

Искажение данных

Дубпирлядчио ппоратияыпй памяти. Г.КС. мои проооромымя суммы для блоков данных. Работать с данными только через специальные функции, минимизировать глобальные данные, сохранять простую структуру данных, учитывать, как данные организуются в структуры компьютером, избегать смешения данных (также далее см. «ошибочные указатели» и «промежуточные данные»)

с

Конфликты в работы с ресурсами

Анализ совместно используемых ресурсов (также ранее см. «условия работы с ресурсами»)

Ошибочные указатели

Защищенное кодирование: проверка целостности данных перед снятием указателя, использование языков с сильными ~ипами данных, минимизировать применение указателей, избегать смешения указателей

X

X

с

Ошибки при переводе данных: смешение типов, масштабирование

Избегание смешения типов, использование форматов с плавающей точкой

X

X

с

Некорректная

инициализация

Преинициализирование переменных усредняемых по времени. обнуление всей памяти при запуске

X

X

с

Усредняемые данные за пределами диапазона

Проверка тою. что достаточное число отсчетов взято до вычисления среднего (особенно при запуске) или преинициализирование среднего к известному (или последнему) корректному значению

X

X

с

Продолжение таблицы В. 2

Программные причины

Типы

ВЕРИФИКАЦИИ

Испытание {модульное, иигеграииомиоо)

Проверка

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

Переходящие данные

Проверка правильности переходов

X

X

Изменяемые данные

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

X

С

Непредусмотренное

дублирование

С^ытывание данных с частотой в 2 и более раз большей, чем наибольшая компонента сигнала (критерий Найквиста) ограничить полосу пропускания сигнала

Использование промежуточных данных

X

Примечание — Последовательность вычислений никогда не должна выполняться с глобальной (или с общей) переменной, если вычисление может быть прервано или сброшено. Вместо этого следует вьполнять все вычисления с временной переменной и обновлять значение глобальной переменной одной непрерываемой командой

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

Проблемы интерфейса

Несвоевременное обновление иэображомия на дисплее

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

Человеческий фактор: НЕПРАВИЛЬНОЕ ПРИМЕНЕНИЕ

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

Сетевые проблемы, например. многопользовательский режим

Тестирование нагрузки со стороны сети

В

Ошибки конфигурации программного или аппаратного обеспечения или некорректные драйверы

Использовать ПРОЦЕСС разработки программного обеспечения. использовать средства управления конфигурацией

Нерабочие патчи или обновления

СКС-тест исполняемого кода и проверка ВЕРСИИ при запуске, проверка версий протоколов и сроков годности кода

Отказы ПОНП: зависание, отсутствие ответа, превышение времени ожидания прерываний и т. п.

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

X

В

Вирус

Применение антивируса

Типы

ВЕРИФИКАЦИИ

Испытание (модульное, интеграционное)

Проверка

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

Несовместимость

веббраузера

Интегративное тестирование версий при запуске, проверка совместимости

Разное

i-^ vi-

Утечки памяти

Избегание динамического выделения массивов памяти

X

X

д

Блокировка СИСТЕМЫ

Использование простых стратегий блокирования ресурсов 1 ПРОЦЕСС может заблокировать только один ресурс за один раз), анализ блокировки

с

Повторное применение

Подтверждение, что все функции, включая библиотеки третьих сторон, которые вызываются прерываниями (или множественными ЗАДАЧАМИ с разными приоритетами), предусматривают повторный запуск

Д

Переполнение стека

Использование флагов ошибок времени запуска стеков, флагов переполнения, анализ стеков

С

Логические ошибки/синтаксис

Использование средств анализа кода (таких как Lint) и/или максимального уровня предупреждений при компилировании. Использование удвоенного РАЗНООБРАЗИЯ и перекрестного ’вотирования в критических контрольных точках

X

X

С

Бесконечные циклы

Использование счетам ков циклов, таймеров циклов

X

X

Порча кода

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

Нерабочий код

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

д

Некорректно скомпилированный код

Подтверждение, что условия компиляции изменяются правильно и только при необходимости

X

Непредусмотренные побочные эффекты

Использование круглых скобок для всех макропараметрое

с

на макроуровне

Истощение ресурсов

Использование анализа стека, очереди, времен выполнения

в

Некорректный приоритет тревожных сигналов и опасностей

Стресс-тестирование

Несанкционированные применения (извлечение части кода, запуск кода непредусмотренным образом и т. п.)

Анализ разработки, анализ требований к коду, использование матриц для прослеживания

Некорректная

последовательность

операций/приоритетое

Разбивка кода на элементы, линейная структура кода

Состояние БЕЗОПАСНОСТИ

Использование независимых наблюдателей

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

Таблица В.З — Методы, способствующие обеспечению результативности МЕР ПО УПРАВЛЕНИЮ РИСКОМ

Статический анализ

Динамический анализ

Моделирование

Просмотр кода

Функциональное тестирование

Моделирование рабочего окружения

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

Временные тесты и тесты памяти

Симулирование во времени

Анализ работы скрытых частей

Анализ граничных значений

Сценарии применения/действий пользователя

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

Стресс-тестирование

Статистическое тестирование

Прогнозирование ошибок

Тестирование пути выполнения кода

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

Кластерное тестирование

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

Потенциальные ошибки, связанные с программным обеспечением

В таблице С.1 перечислены потенциальные ошибки, связанные с программным обеспечением, которых следует избегать в работе по МЕНЕДЖМЕНТУ РИСКА (по пунктам ИСО 14971) и в работе по управлению ЖИЗНЕННЫМ ЦИКЛОМ программного обеспечения (по пунктам МЭК 62304).

Таблица С.1 — Потенциальиыэ ошибки, связанные с программным обеспечением, которых следует избегать

ИСО 14971 Раздел 4: АНАЛИЗ РИСКА

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

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

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

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

ИСО 14971 Пункт 4.1: ПРОЦЕСС АНАЛИЗА РИСКА

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

-    Программное обеспеченна рассматривается как часть АНАЛИЗА РИСКА только на последних этапах ЖИЗНЕННОГО ЦИКЛА разработок продукции.

ИСО 14971 Пункт 42: Идентификация ПРЕДУСМОТРЕННОГО ПРИМЕНЕНИЯ

-    Рассмотрение только подмножества пользовательских интерфейсов/потенциальных платформ для компьютерных СИСТЕМ:

-    Неуче г эволюции платформы или требований к установке патчей по БЕЗОПАСНОСТИ и других патчей ПОНП;

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

ИСО 14971 Пункт 4.3; Идентификация ОПАСНОСТЕЙ

a)    Применение FMEA и FTA методологий, как если бы они были бы полностью достаточны для корректного МЕНЕДЖМЕНТА РИСКА;

b)    Применение FMEA и FTA методологий раздельно для аппаратной и программной частой:

c)    Игнорирование целого к/асса ОПАСНОСТЕЙ, таких как:

1)    программные ошибки, которые имеют непредсказуемые эффекты;

2)    ошибки а программной логике, которая применена как мера по УПРАВЛЕНИЮ РИСКОМ для аппаратных отказов:

3)    ошибки в программной логике для реализации предусмотренного применения МЕДИЦИНСКОГО

ИЗДЕЛИЯ (такие кат алгоритмы для вьмисления результатов):

4)    отказы программных платформ — операционных СИСТЕМ, библиотек. ПОНП:

5)    отказы компонентов компьютера и периферийных устройств:

6)    отказы интерфейсов передачи данных;

7)    человеческие ошибки.

d)    Проведение иденгификадии причин а предположении, что:

1)    АНОМАЛИИ программного обеспечения будут влиять на функции только отдельных компонентов и не будут оказывать а1ияние на другие ПРОГРАММНЫЕ ЭЛЕМЕНТЫ или данные;

2)    программное обеспечение будет работать корректно:

Продолжение таблицы С. 1

3)    потенциальные отказы программного обеспечения слишком многочисленны и непредсказуемы для идентификации определения или УПРАВЛЕНИЯ РИСКОМ:

4)    всегда достаточно применить меры по УПРАВЛЕНИЮ РИСКОМ в начале или в конце цепи программных событий, ведущих к ОПАСНЫМ СИТУАЦИЯМ.

ИСО 14971 Пункт 4.4: Определение РИСКА

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

•    Предположение, что тестирование, которое может быть и неполным, уменьшает вероятность определенного отказа до нуля:

-    Предположение, основанное на функционале изделия, о том. что некоторые ПРОГРАММНЫЕ ЭЛЕМЕНТЫ не связаны с БЕЗО ГАСИ ОСТЬЮ, без учета возможных неожиданных побочных эффектов:

•    Задание значений ТЯЖЕСТИ ВРЕДА без достаточных клинических знаний и без привлечения тех. кто имеет представление о клинических аспектах (человеческих факторах) воздействия ОПАСНОСТЕЙ на всех потенциальных пользователей и групп пациентов:

-    Задание низких значений тяжести в предположении, что врачи обнаружат отказ, или на основе неверной информации:

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

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

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

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

ИСО 14971 Раздел 5: ОЦЕНИВАНИЕ РИСКА

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

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

•    Не учет потенциальной АНОМАЛИИ программного обеспечения как фактора ОПАСНОСТИ, поскольку предполагается, что программное обеспечение будет работать правильно или тестирование выявит все АНОМАЛИИ.

ИСО 14971 Пункт 6.3: Выполнение мер по УПРАВЛЕНИЮ РИСКОМ

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

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

-    Меры по УПРАВЛЕНИЮ РИСКОМ верифицированы только на одной операционной системе или программной платформе:

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

-    Предположение о том. что все относящиеся к БЕЗОПАСНОСТИ АНОМАЛИИ будут обнаружены при разработке и что тестирование гарантирует корректную работу:

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


ИСО 1497' Раздел 9: ПОСТПРОИЗВОДСТВЕННАЯ информация

•    Игнорирование погенциа/ъно опасных кокте«сгчых событий от ОШИБОК ПОЛЬЗОВАТЕЛЯ, когда дополнительные меры по УПРАВЛЕНИЮ РИСКОМ могли бы быть применены;

•    Предположение, что начальные значения вероятности и ТЯЖЕСТИ являются правильными, без оценивания информации о применении изделия:

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

МЭК 62304 Пункт 5.1 Планирование разработки программного обеспечения

•    Деятельность по МЕНЕДЖМЕНТУ РИСКА не включена в планы программного обеспечения и в ПРОЦЕССЫ ЖИЗНЕННОГО ЦИКЛА;

•    Деятельность по МЕНЕДИМЕНТУ РИСКА программного обеспечения не связана с деятельностью по МЕНЕДЖМЕНТУ РИСКА МЕДИЦИНСКОГО ИЗДЕЛИЯ;

•    ОЦЕНИВАНИЕ РИСКА программного обеспечения проводится только для одной стадии ЖИЗНЕННОГО ЦИКЛА;

- Разработчики и испытатели программного обеспечения не обучены или не имеют опыта в МЕНЕДЖМЕНТЕ РИСКА;

•    МЕНЕДЖМЕНТ РИСКА программного обеспечения считается полностью включенным в деятельность по общему МЕНЕДЖМЕНТУ РИСКА;

•    РИСКИ программного обеспечения управляются неаккуратно:

•    Решения в отношении ПРОСЛЕЖИВАЕМОСТИ и БЕЗОПАСНОСТИ не установлены.

МЭК 62304 Аспекты программного обеспечения неизвестного происхождения (ПОНП)

•    Пропуск разработки внутренних мер по УПРАВЛЕНИЮ РИСКОМ из-за отсутствия ОЦЕНИВАНИЯ РИСКА и управления при определении АРХИТЕКТУРЫ программного обеспечения:

•    Предположение о том. что тестировало сделает неэффективные АРХИТЕКТУРЫ достаточно безопасными;

•    Неполная идентификация аспектов БЕЗОПАСНОСТИ АРХИТЕКТУРЫ, что ведет к неизвестным РИСКАМ в отношении БЕЗОПАСНОСТИ в случаях, когда элементы архитектуры заменяют или удаляют.

МЭК 62304 Пункт 5.4 Детальная проработка программного обеспечения

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

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

•    Игнорирование причин программных отказов (см. приложение В) в деятельности по МЕНЕДЖМЕНТУ РИСКА.

МЭК 62304 Пункт 5.5 Реализация и ВЕРИФИКАЦИЯ ПРОГРАММНОГО МОДУЛЯ

•    Предположение о том. что наилучшие практики кодирования и/кли ПРОЦЕССА тестирования, программные инструменты или персонал могут компенсировать ущербную, внутренне небезопасную или излишне сложную структуру:

•    Привлечение неопытных разработчиков для написания критических частей кода:

•    Отсутствие установления и требования применения специальных защищенных практик программирования:

•    Использование исключительно динамического тестирования без выполнения проверок кода и статического анализа, особенно для критических компонентов;

•    Отступление от хода разработки без понимания соотношения между требованиями к разработке и МЕНЕДЖМЕНТОМ РИСКА:

•    Однократное тестирование критических компонентов на ранних стадиях ПРОЦЕССА разработки без возвращения к ним в регрессионном тестировании;

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


МЭК 62304 Пункты 5.6—5.7 Г^ххраммная интеграция и испытания в отношении интеграции и испытание

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

-    Неприменение информации по ОЦЕНИВАНИЮ РИСКОВ при планировании тестирования и обучения испытателей;

-    Зависимость от испытаняя как меры по УПРАВЛЕНИЮ РИСКОМ — даже в том случае, когда 100 % тестирование невозможно:

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

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

•    Неспособность корректно проанализировать код для определения АНОМАЛИЙ, которые испытатель не сможет обнаружить.

МЭК (2304 Пункт 5.8 Выпуск программного обеспечения

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

-    Невозможность привлечь персонал с клиническими знаниями для оценки остаточных АНОМАЛИЙ.

•    Оценка значимости оставшихся АНОМАЛИЙ, основанная исключительно на найденных функциональных симптомах, без полного анатиза главных причин для определения потенциальных побочных эффектов в различных ситуациях;

-    Неучет того факта, что сак только третья сторона перестанет поддерживать определенную версию ПОНП. эта версия не будет болев доступна для расследования отказов и коррекций:

-    Потеря определенной ВЕРСИИ программного обеспечения по причине того, что некоторые инструменты или ВЕРСИИ инструмент се (например, компилятор) не были включены в архив:

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

МЭК 62304 Пункт 6.1 Разработка плана технической поддержки программного обеспечения

•    Разработка ПРОЦЕССА 'ехнической поддержки не имеет четкого подхода к МЕНЕДЖМЕНТУ РИСКА изменений;

•    Установление МЕНЕДЖМЕНТА РИСКА для изменений, который рассматривает только функциональные аспекты изменения и не рассматривает компоненты, участвующие в изменении, и связанные с ними РИСКИ.

МЭК 62304 Пунггы 6.2-6.3 Анализ проблем и модификаций и их реализация

•    Предположение, что небольшое функциональное изменение не повлияет на БЕЗОПАСНОСТЬ;

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

-    Установка приоритетносги разрешения проблем на основе симптомов и контекста, без определения главных причин и потенциальны» побочных эффектов:

-    Программное обеспечение для немедицинсхих применений (например, генерация счета) содержит клинические данные, которые впоследствии распространяются для клинических целей без соответствующего ME НЕДЖМЕ НТА РИСКА.


Матэица жизненный цнкл/менеджмент риска

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

Таблица D.1 — Матрица ЖИЗНЕННЫЙ ЦИКЛ/МЕНЕДЖМЕНТ РИСКА

МЭК 62304 Требования к ЖИЗНЕННОМУ ЦИКЛУ

ИСО 14971

4 АНАЛИЗ РИСКА

SОЦЕНИВАНИЕ РИСКА

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

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

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

Планирование МЕНЕДЖМЕНТА РИСКА (3.4 из ИСО 14971)

Спланировать и документировать:

a)    обьем запланированной деятельности по МЕНЕДЖМЕНТУ РИСКА, в том числе идентификацию и описание МЕДИЦИНСКОГО ИЗДЕЛИЯ и стадий его ЖИЗНЕННОЮ 4ИКЛА. к которым применим каждый элемент плана.

b)    распределение ответственности и полномочий:

c)    требования к анализу деятельности по МЕНЕДЖМЕНТУ РИСКА:

d)    критерии допустимости риска, основанные на политике ИЗГОТОВИТЕЛЯ по определению допустимого РИСКА, в том числе критерии допустимости РИСКА в тех случаях, когда вероятность причинения ВРЕДА не может быть определена;

e)    деятельность по ВЕРИФИКАЦИИ:

0 деятельность по сбору и анализу информации, относящейся к МЕНЕДЖМЕНТУ РИСКА, на производственной и ПОСТПРОИЗВОДСТВЕННОЙ стадиях.

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

• Проанализировать предусмотренное применение и обоснованно прогнозируемое неправильное применение. а ~акже пользователей для определения ОПАСНОСТЕЙ:

-    Огределитъ известные и возможные ОПАСНОСТИ в отношении врачей, пациентов. обслуживающего персонала и прочих людей, которые имзют контакт с МЕДИЦИНСКИМ ИЗДЕЛИЕМ:

-    Учесть этапы эксплуатации. такие как монтаж и сборка, обучение, применение. модернизация, техническое обслуживание:

-    Определить последовательности и комбинации событий, которые могут привести к ОПАСНЫМ СИТУАЦИЯМ;

-    Определить РИСКИ для каждой ОПАСНОЙ СИТУАЦИИ. «читывая ТЯЖЕСТЬ ВРЕДА от возможных последе гены.

-    4.3 Классифицировать программное обеспечение по БЕЗОПАСНОСТИ (требования МЭК 62304.

•    Принять решение о том. требуется ли уменьшение РИСКА

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

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

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

-    Идентифицировать программное обеспечение для улучшения дифференциации. уменьшения ТЯЖЕСТИ ВРЕДА и/(или) снижения вероятности ОПАСНОЙ СИТУАЦИИ:

-    Проанализировать меры по УПРАВЛЕНИЮ РИСКОМ на наличие новых ОПАСНОСТЕЙ.

Продолжение таблицы 0.1

МЭК 62304 Требования к ЖИЗНЕННОМУ ЦИКЛУ

ИСО 14971

4 АНАЛИЗ РИСКА

5 ОЦЕНИВАНИЕ РИСКА

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

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

•    Определить критические дачные, компоненты и классы дефектов, которые могут гривесги к ОПАСНОСТЯМ. Особое внимание уделить грограммным причинам;

•    Определить ассоциированные причины:

- Ограделитъ интерфейсы; что и когда передается:

•    Осенить критерии успешной работы и ограничения;

•    Классифицировать прог-рам инее обеспечение по БЕЗОПАСНОСТИ (требования МЗК 62304).

-    Провести переоценку приемлемости роли, отведенной программному обеспечению в контексте РИСКА,

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

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

-    Уделить особое внимание обеспечению соответствующей ИЗБЫТОЧНОСТИ;

-    Определить ОПАСНОСТИ. связанные с ИЗБЫТОЧНОСТЬЮ;

-    Определить общие методы по распознавание и управлению.

5.4 Детальная проработка программного обеспечения

- Определит дополнительные потенциальные причины ОПАСНОСТЕЙ.

•    Предположить наличие ошибок в данных, в коде и в передаче данных;

•    Предположить отказы annapainoro обеспечения.

-    Провести повторную оценку корректности мер по УПРАВЛЕНИЮ РИСКОМ;

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

-    Внедрить специальные меры по УПРАВЛЕНИЮ РИСКОМ и защищенные практики проек-тировами «/программирования;

-    Завершить анализ ПРОСЛЕЖИВАЕМОСТИ и целостности, чтобы убедиться в выполнении мер по УПРАВЛЕНИЮ РИСКОМ:

-    Определить, был ли реализован какой-либо не указанный ранее функционал.

5.5 Реализация и ВЕРИФИКАЦИЯ ПРОГРАММНОГО МОДУЛЯ

- Огределить дополнительные потенциальные причины ОПАСНОСТЕЙ;

• Оценить отказ каждого теста на подобных реализациях кеда.

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

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

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

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

МЭК 62304 Требования к ЖИЗНЕННОМУ ЦИКЛУ

ИСО 14971

4 АНАЛИЗ РИСКА

S ОЦЕНИВАНИЕ РИСКА

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

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

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

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

5.7 Тестирование на уровне СИСТЕМЫ

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

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

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

• Определить план управления к»фигурацией, включая конфигурацию элементов и взаимозависимости.

Верифицировать, что корректные ВЕРСИИ специального и ПОНП программного обеспечения включены в релиз;

Верифицировать, что условия компиляции учтены в управлении конфигурацией.

6 процесс технической поддержи

8.1 Определить план технической поддержки программного обеспечения

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

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

• Проанализировать информацию о применении для цели огределеиия ранее не идентифицированных или дополнительных ОПАСНОСТЕЙ и пзичии этих ОПАСНОСТЕЙ.

• Провести повторное оценивание ранжирования РИСКОВ и корректности мер по УПРАВЛЕНИЮ РИСКОМ.

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

6.3 Реализация модификаций

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

влияние на существующие меры по УПРАВЛЕНИЮ РИСКОМ: привнесение новых причин ОПАСНОСТЕЙ;

привнесение нового функционала к ПРЕДУСМОТРЕННОМУ ПРИМЕНЕНИЮ, которое с задает новые ОПАСНОСТИ;

регрессионное тестирование кода, связанного с БЕЗОПАСНОСТЬЮ.

Релиз фограммиого обеспечения в соответствии с пунктом 5.8 МЭК 62304.

БЕЗОПАСНЫЕ случаи

БЕЗОПАСНЫЙ случай — этс а структурирован мое обоснование, подкрепленное совокупностью свидетельств, формирующих убедительный, обоснованный и достоверный случай того, что МЕДИЦИНСКОЕ ИЗДЕЛИЕ является безопасным для данного ПРЕДУСМОТРЕННОГО ПРИМЕНЕНИЯ в данных условиях применения» (адаптировано из UK MoD Del Stan 00-56).

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

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

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

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

Для реализации БЕЗОПАСНОГО случая требуется наличие следующих компонентов:

-    четкий перечень заявления в отношении СИСТЕМЫ:

-    представление подтверждающих свидетельств;

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

-    предположения и заключения по базе обоснований:

-    допущение различных точек зрения и уровней детальности.

Главными элементами БЕЗОПАСНОГО случая являются:

-    заявление о свойстве СИСТЕМЫ или некоторой подсистемы;

-    свидетельство, которое используется как база для обоснования БЕЗОПАСНОСТИ. Это могут быть или факты (например, основадеые на извесжых научных принципах или предварительных исследованиях), допущения или заполонил. nony*»oiaiuo ю бопоо низком урооно оргумо! гтироооиил;

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

-    логический вывод — метод, устанавливающий правила вывода суждений.

Для дальнейшей информации об элементах и структуре БЕЗОПАСНЫХ случаев см. (9].

Две публикации, предсгавляощие собой хорошее введение в БЕЗОПАСНЫЕ случаи и структурированное по цели изложение см. (10] и [11].

Сведения о соответствии ссылочных международных стандартов ссылочным национальным стандартам Российской Федерации и действующим в этом качестве межгосударственным стандартам

Таблица ДА.1

Обозначение ссмлечного международне го стандарта

Степень соотют • стезя

Обозначение и наименование соответствующего национального, межгосударственного стандарта

ИСО 14971:2007

ID'

ГОСТ ISO 14971—2011 «Изделия медицинские. Применение менеджмента риска к медицинским изделиям»

МЭК 62304:2006

ID'

ГОСТ Р МЭК 62304—2013 «Изцегыя медицинские. Программное обеспечение. Процессы жизненного цикла»

Примечание — в настоящей таблице использовано следующее условное обозначение степенет соответствия стандартов:

• ЮТ — идентичные стандарты.

Список определенных терминов

. . . . ИСО 14971:2007, 2.1 . . . . МЭК 62304:2006. 3.1 . . . . МЭК 62304:2006. 3.2 . . . . МЭК 62304:2006. 3.3 . . . . МЭК62304:2006.3.6.2.1 . . . . МЭК 62304:2006. 3.8 ИСО 14971:2007, 2.2 . . . . МЭК 62304:2006. 3.9 ИСО 14971:2007, 2.3 . . . . ИСО 14971:2007, 2.4 . . . . ИСО 14971:2007, 2.5 . . . . ИСО 14971:2007, 2.7 . . . . МЭК 62304:2006, 3.10 ИСО 14971:2007. 2.0 . . . . МЭК 62304:2006. 3.11 ИСО 14971:2007. 2.9 . . . . МЭК 62304:2006, 3.12 . . . . ИСО 14971:2007, 2.11 . . . . МЭК 62304:2006. 3.13 . . . . ИСО 41971:2007. 2.12 . . . . МЭК 62304:2006. 3.14 ИСО 14971:2007. 2.13 . . . . ИСО 14971:2007. 2.14

...............2.2

. . . . ИСО 14971:2007. 2.15 . . . . МЭК 62304:2006. 3.16 . . . . ИСО 17971:2007. 2.16 . . . . МЭК 62304:2006. 3.17 . . . . ИСО 14971:2007. 2.17 . . . . ИСО 14971:2007. 2.18 . . . . МЭК 62304:2006, 3.18 . . . . ИСО 14971:2007. 2.19 . . . . ИСО 14971:2007. 2.20 . . . . ИСО 14971:2007. 2.21 . . . . МЭК 62304:2006, 3.19 . . . ИСО 14071:2007. 2.22 . . . . МЭК 62304:2006, 3.20 . . . . ИСО 14971:2007. 2.23 . . . . МЭК 62304:2006, 3.21 . . . . ИСО 14971:2007. 2.24

...............2.3

. . . . МЭК 62304:2006, 3.22 . . . . ИСО 14971:2007. 2.25 . . . . МЭК 62304:2006, 3.25 . . . . МЭК 62304:2006, 3.29 . . . . МЭК 62304:2006, 3.30 . . . . МЭК 62304:2006, 3.31 . . . . ИСО 14971:2007. 2.26 . . . . МЭК 62304:2006, 3.32 . . . . ИСО 14971:2007. 2.27 . . . . МЭК 62304:2006, 3.33 . . . . ИСО 14971:2007. 2.28 . . . . МЭК 62304:2006, 3.34


ЭКСПЛУАТАЦИОННЫЙ ДОКУМЕНТ.................

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

АНОМАЛИЯ................................

АРХИТЕКТУРА..............................

РАЗНООБРАЗИЕ.............................

ВРЕД....................................

ОПАСНОСТЬ ...............................

ОПАСНАЯ СИТУАЦИЯ.........................

ПРЕДУСМОТРЕННОЕ ПРИМЕНЕНИЕ...............

ЖИЗНЕННЫЙ ЦИКЛ.........................

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

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

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

ПОСТПРОИЗВОДСТВО........................

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

ПРОЦЕДУРА...............................

ПРОЦЕСС ................................

ЗАПИСЬ ..................................

ИЗБЫТОЧНОСТЬ............................

ОСТАТОЧНЫЙ РИСК..........................

РИСК...................................

АНАЛИЗ РИСКА

ОЦЕНКА РИСКА.....

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

ОПРЕДЕЛЕНИЕ РИСКА ОЦЕНИВАНИЕ РИСКА . МЕНЕДЖМЕНТ РИСКА

ФАЙЛ МЕНЕДЖМЕНТА РИСКА

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

СВЯЗАННОЕ С БЕЗОПАСНОСТЬЮ ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ

ЗАЩИТА......................................

ТЯЖЕСТЬ.....................................

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

ПОНП (Программное обеспечение неизвестного происхождения) . .

СИСТЕМА.....................................

ЗАДАЧА......................................

ВЫСШЕЕ РУКОВОДСТВО...........................

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

ОШИБКА ПРИМЕНЕНИЯ...........................

ВЕРИФИКАЦИЯ.................................

ВЕРСИЯ

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

(I)    ИСО 13485:2003 ISO 13485:2003

[2J МЭК 60812 IEC 60612

[3]    МЭК 61025 IEC 61025

[4]    МЭК 61882 IEC 61882

[5]    МЭК 62366

IEC 62366

[6]    МЭК 80001-1

IEC 80001-1

[7]    Паллум Л. Бостон:

Аргех хаус. 2001 Pultum L. Boston: Artech House. 2001

[8]    Баиатре M. Ли П. Берлин. Германия Спринджер-Велаг. 1994

Banatre М.. Lee Р. (Eds).. Berlin. Germany:

Sponger-Verlag. 1994

[9]    Бишоп П.. Блумфилд R (1998)

Bishop R. Bloomfield R. (1998)

[10]    Келли Т.П.. Детройт.

Март 2004

Kelly T. P. Detroit.

March 2004

(II)    Вивер RA.. Келли Т.П., Июль 2004

Weaver R. A.. Kelly T.R. July 2004


Медицинские изделия. Системы менеджмента качества. Системные требования для целей регулирования

Medical devices — Quality management systems — Requirements for regulatory pjrposes

Ачалиэ методов технической надежности. Метод анализа видов и последствий отказов

А та lysis techniques for system reliability — Procedure for failure mode and effects analysts (FMEA)

Ачализ дерева неисправностей Fault tree analysis (FTA)

Исследование опасности и работоспособности. Прикладное руководство htozard and operability studies (HAZOP studies) — Application guide Медицинские изделия. Проектирование медицинских изделий с учетом эксплу-а*ационной пригодности

Medical devices — Appbcabon of usability engineering to medical devices

Менеджмент рисков для информационных сетей, связанных с медицинскими

приборами. Часть 1. Роли, ответственность и деятельность

Application of risk management to information technology (IT) networks incorporating

rredical devices — Part 1: Rotes, responsibilities and activities

Программное обеспечение отказоустойчивой техники и ее реализация. Бостон

Ssftware fault tolerant techniques and implementation

Оборудование и программное обеспечение для архитектуры отказоустойчивости: Огыт и перспективы

hardware and Software Architectures for Fault Tolerance:

Experiences and Perspectives

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

A Methodology for Safety Case Development Safety-Critical Systems Symposium

Системный подход к управлению безопасностью дела. Материалы мирового

конгресса SAE 2004 (Материалы опубликованы Обществом автомобильных

имжоиороь)

S/stamatic Approach to Safety Case Management, Proceedngs of SAE 2004 World Congress (Proceedings published by the Society for Automotive Engineers) Обозначенные цепи структурирования — Обозначение безопасности аргументов. материалы по надежности систем и сетей

Тте Goa) Structuring Notation — A Safety Argument Notation. Proceedings of the Dependable Systems and Networks 2004 Workshop on Assurance Cases

УДК 006.85    ОКС 11.040.01    Р20    ОКП 94 0000

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

Редактор А. В. Барандвев Технический редактор Б. В. Беслрозванная Корректор Я Я. Митрофанова Компьютерная верстка В. И. Романовой

Сдано о набор 01.09-2014. Подписано в печать 12.11.2014. Формат в0х84'/8. Бумага офсетная. Гарнитура Ариал Печать офсоттая Уел. печ. п. 7,44 Уч.-иад. л. 6,80. Тирам 35 эка. За* 1456.

ФГУП «СТАНДАРТИНФОРМ». 123995 Москва. Гранатный пер.. 4

Набрано и отпечатано а Калужской типографии стандартов. 248021 Калуга, уп. Московская. 2S6