ГОСТ Р 55544-2013 /IEC/TR 80002-1:2009 Программное обеспечение медицинских изделий. Часть 1. Руководство по применению ИСО 14971 к программному обеспечению изделий.
ГОСТ Р 55544-2013/IEC/TR 80002-1:2009
Группа Р20
НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ
Программное обеспечение медицинских изделий
Часть 1
Руководство по применению ИСО 14971 к программному обеспечению медицинских изделий
Medical devices software. Part 1. Guidance on the application of lSO 14971 medical devices software
ОКС 11.040.01
ОКП 94 000
Дата введения 2014-08-01
Предисловие
1 ПОДГОТОВЛЕН Закрытым акционерным обществом "МЕДИТЕСТ" на основе собственного аутентичного перевода на русский язык международного стандарта, указанного в пункте 4
2 ВНЕСЕН Техническим комитетом по стандартизации ТК 436 "Управление качеством медицинских изделий"
3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ
Приказом Федерального агентства по техническому регулированию и метрологии от 28 августа 2013 г. N 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)
Введение
Программное обеспечение часто является неотъемлемой частью МЕДИЦИНСКИХ ИЗДЕЛИЙ. Для установления БЕЗОПАСНОСТИ и результативности МЕДИЦИНСКИХ ИЗДЕЛИЙ, содержащих программное обеспечение, требуется должное понимание назначения программного обеспечения, а также демонстрация того, что исполнение программного обеспечения отвечает этому назначению, не вызывая никаких недопустимых РИСКОВ.
Важно понимать, что само по себе программное обеспечение не является ОПАСНОСТЬЮ, но может способствовать ОПАСНЫМ СИТУАЦИЯМ. Программное обеспечение всегда должно рассматриваться в перспективе СИСТЕМЫ, а МЕНЕДЖМЕНТ РИСКА программного обеспечения также не может осуществляться в отрыве от этой СИСТЕМЫ.
Сложные конструкции программного обеспечения могут допускать сложные последовательности событий, которые могут способствовать ОПАСНЫМ СИТУАЦИЯМ. Значительная часть ЗАДАЧИ по МЕНЕДЖМЕНТУ РИСКА программного обеспечения состоит в определении тех последовательностей событий, которые могут приводить к ОПАСНЫМ СИТУАЦИЯМ, а также в определении точек, в которых эта последовательность может быть прервана с целью предотвращения ВРЕДА или уменьшения вероятности его возникновения.
В программном обеспечении, последовательности событий, которые способствуют ОПАСНЫМ СИТУАЦИЯМ, могут быть разделены на две категории:
а) последовательности событий, приводящие к непредвиденным программным ответам на входные данные (ошибки в спецификации программного обеспечения);
б) последовательности событий, возникающие из-за неправильного кодирования (ошибки в реализации программного обеспечения).
Эти категории характерны для программного обеспечения, так как возникают из-за трудности правильного определения и реализации сложной СИСТЕМЫ и полной ВЕРИФИКАЦИИ сложной СИСТЕМЫ.
Поскольку очень сложно оценивать вероятность АНОМАЛИЙ в программном обеспечении, которые могут способствовать ОПАСНЫМ СИТУАЦИЯМ, и поскольку программное обеспечение не отказывает в ПРОЦЕССЕ использования случайным образом, например, из-за износа, то при проведении АНАЛИЗА РИСКА основное внимание должно уделяться идентификации потенциальной функциональности программного обеспечения, а также должно уделяться внимание АНОМАЛИЯМ, которые могут приводить к ОПАСНЫМ СИТУАЦИЯМ, а не оценке возникновения вероятности. РИСКИ, возникающие из-за АНОМАЛИЙ программного обеспечения, чаще всего нужно оценивать только по ТЯЖЕСТИ ВРЕДА.
МЕНЕДЖМЕНТ РИСКА - это всегда сложная задача, которая становится еще более сложной, если это касается программного обеспечения. Нижеследующие пункты содержат дополнительную информацию относительно особенностей программного обеспечения и служат основой для понимания ИСО 14971:2007 в отношении программного обеспечения.
Структура стандарта
Настоящий стандарт построен таким образом, чтобы следовать структуре ИСО 14971:2007 и служить руководством для каждого вида деятельности по МЕНЕДЖМЕНТУ РИСКА в отношении программного обеспечения.
Существует некоторая преднамеренная избыточность в информации, которая связана с итеративным характером деятельности по МЕНЕДЖМЕНТУ РИСКА, применяемого к ЖИЗНЕННОМУ ЦИКЛУ программного обеспечения.
1 Общие положения
1.1 Область применения
Настоящий стандарт предоставляет собой руководство по применению требований, содержащихся в ИСО 14971 "Медицинские изделия. Применение менеджмента риска к медицинским изделиям" (Medical devices - Application of risk management to medical devices) к программному обеспечению медицинских изделий, со ссылкой на МЭК 62304 "Программное обеспечение медицинских изделий. Процессы жизненного цикла программного обеспечения" (Medical device software - Software life cycle processes). Настоящий стандарт ничего не добавляет и не изменяет в ИСО 14971 или МЭК 62304.
Настоящий стандарт предназначен для исполнителей МЕНЕДЖМЕНТА РИСКА, которым необходимо осуществить МЕНЕДЖМЕНТ РИСКА, когда программное обеспечение включено в МЕДИЦИНСКОЕ ИЗДЕЛИЕ или СИСТЕМУ, а также для инженеров по программному обеспечению, которые должны понимать, как выполнить требования по МЕНЕДЖМЕНТУ РИСКА, содержащиеся в ИСО 14971.
ИСО 14971, повсеместно признанный регулирующими органами, широко применяется в качестве основного стандарта, используемого при осуществлении МЕНЕДЖМЕНТА РИСКА МЕДИЦИНСКИХ ИЗДЕЛИЙ. МЭК 62304 дает нормативную ссылку на ИСО 14971, требуя его применения. Содержание этих двух стандартов является основой для настоящего стандарта.
Следует отметить, что, хотя требования ИСО 14971 и настоящего стандарта применяются к МЕДИЦИНСКИМ ИЗДЕЛИЯМ, он может использоваться для осуществления ПРОЦЕССА МЕНЕДЖМЕНТА РИСКА в отношении БЕЗОПАСНОСТИ для всего программного обеспечения в области здравоохранения независимо от того, классифицировано ли оно как МЕДИЦИНСКОЕ ИЗДЕЛИЕ или нет.
Настоящий стандарт не включает:
- области, охваченные существующими или планируемыми стандартами, например, тревожную сигнализацию, проектирование эксплуатационной пригодности, работу в сети и т.д.;
- аспекты производства или системы менеджмента качества программного обеспечения; или
- инструменты разработки программного обеспечения.
Настоящий стандарт не предназначен для использования в качестве основы для проверки регулирующих требований или деятельности по сертификации.
Для целей настоящего стандарта термин "следует" (should) используется, чтобы показать, что среди нескольких возможностей удовлетворения требования одна рекомендуется как особенно пригодная, без упоминания или исключения других, или чтобы показать, что определенный курс действий предпочтительнее, но необязателен. Этот термин не должен интерпретироваться как требование.
1.2 Нормативные ссылки
В настоящем стандарте использованы ссылки на следующие стандарты*:
МЭК 62304:2006 "Программное обеспечение медицинских изделий - процессы жизненного цикла программного обеспечения" (IEC 62304:2006, Medical device software - Software life cycle processes)
ИСО 14971:2007 "Медицинские изделия - Применение менеджмента риска к медицинским изделиям" (ISO 14971: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 - Схематичное представление ПРОЦЕССА МЕНЕДЖМЕНТА РИСКА
БЕЗОПАСНОСТЬ является свойством СИСТЕМЫ (в данном случае всего МЕДИЦИНСКОГО ИЗДЕЛИЯ), которая включает программное обеспечение. МЕНЕДЖМЕНТ РИСКА должен осуществляться в рамках СИСТЕМЫ, включая программное обеспечение и всю ее аппаратную среду. Деятельность по МЕНЕДЖМЕНТУ РИСКА программного обеспечения не должна проводиться в отрыве от СИСТЕМЫ.
Поскольку аспекты МЕНЕДЖМЕНТА РИСКА программного обеспечения не могут быть эффективно выполнены в отрыве от всего МЕНЕДЖМЕНТА РИСКА МЕДИЦИНСКОГО ИЗДЕЛИЯ, существуют действия, являющиеся составной частью ЖИЗНЕННОГО ЦИКЛА программного обеспечения, которые наилучшим образом могут быть выполнены инженерами-программистами. Существуют также элементы программного обеспечения, которые требует большего внимания и особого разъяснения, чем то, которое приведено в ИСО 14971 для полного МЕНЕДЖМЕНТА РИСКА МЕДИЦИНСКОГО ИЗДЕЛИЯ. Важно подчеркнуть, что с целью обеспечения эффективности даже программные аспекты МЕНЕДЖМЕНТА РИСКА нуждаются в ориентации на РИСКИ, связанные с МЕДИЦИНСКИМ ИЗДЕЛИЕМ.
Примечание 1 - Аспекты МЕНЕДЖМЕНТА РИСКА программного обеспечения не могут быть эффективно выполнены в отрыве от всего МЕНЕДЖМЕНТА РИСКА МЕДИЦИНСКОГО ИЗДЕЛИЯ из-за взаимозависимости отказов аппаратных средств, отказов программного обеспечения и аппаратных и программных мер УПРАВЛЕНИЯ РИСКОМ.
Примечание 2 - Например, все систематические, а не случайные отказы программного обеспечения (как и многие типы аппаратных отказов или поломок) и их вероятность не могут быть точно оценены. Вот почему способ, которым компонент вероятности РИСКА применяется к программному обеспечению, существенно различается. См. 4.4.3.
Для инженеров-программистов существует много способов обеспечения общей БЕЗОПАСНОСТИ МЕДИЦИНСКИХ ИЗДЕЛИЙ на ранних стадиях проектирования. Роль программного обеспечения в БЕЗОПАСНОСТИ МЕДИЦИНСКИХ ИЗДЕЛИЙ должна быть рассмотрена перед тем, как проектирование СИСТЕМЫ будет завершено. Участвуя в ПРОЦЕССЕ проектирования МЕДИЦИНСКОГО ИЗДЕЛИЯ по мере развития проекта инженер-программист может способствовать принятию решений, СВЯЗАННЫХ С БЕЗОПАСНОСТЬЮ, относительно РИСКА, связанного с программным обеспечением. Такие решения могут включать, по крайней мере, следующие действия:
- выбор подходящих аппаратных средств для поддержки программного обеспечения;
- разделение функций между программными и аппаратными средствами;
- предусмотренное применение всего МЕДИЦИНСКОГО ИЗДЕЛИЯ, а также предусмотренное применение пользовательских интерфейсов программного обеспечения;
- исключение сложного программного обеспечения, не являющегося необходимым.
3.1.2 Итерация
Типичный цикл разработки ЖИЗНЕННОГО ЦИКЛА программного обеспечения часто использует повторные действия (итерацию). Использование итерации делает возможным:
- исследование осуществимости других проектов программного обеспечения;
- разработку различных ПРОГРАММНЫХ ЭЛЕМЕНТОВ в различные сроки;
- обеспечение выпуска различных ВЕРСИЙ программного обеспечения;
- исправление ошибок, сделанных во время ПРОЦЕССА разработки программного обеспечения.
МЭК 62304 требует итерации деятельности по МЕНЕДЖМЕНТУ РИСКА, а также координации с деятельностью по проектированию СИСТЕМЫ на всем протяжении ЖИЗНЕННОГО ЦИКЛА программного обеспечения. Например, во время разработки программного обеспечения п.5.2.4 МЭК 62304 требует повторного ОЦЕНИВАНИЯ РИСКА МЕДИЦИНСКОГО ИЗДЕЛИЯ, когда установлены требования к программному обеспечению. Такое переоценивание может вызвать потребность в обновлении спецификаций требований к СИСТЕМЕ и ОЦЕНКЕ РИСКА МЕДИЦИНСКОГО ИЗДЕЛИЯ. ОЦЕНИВАНИЕ РИСКА должно повторяться на всех стадиях от требований к АРХИТЕКТУРЕ и проекту до реализации программного обеспечения.
ИСО 14971 не устанавливает ПРОЦЕСС проектирования и разработки и в основном требует, чтобы действия по МЕНЕДЖМЕНТУ РИСКА были предприняты до и после (не во время) осуществления проектирования (включая меры по УПРАВЛЕНИЮ РИСКОМ). Например, когда меры по МЕНЕДЖМЕНТУ РИСКА уже были выполнены, ИСО 14971 требует, чтобы они были проанализированы на предмет того, что они не вызвали дополнительных ОПАСНОСТЕЙ и ОПАСНЫХ СИТУАЦИЙ. Это не должно рассматриваться как инструкция по выполнению анализа только после того, как выполнение мер завершено. Это должно рассматриваться с точки зрения пользы для реагирования на любые дополнительные ОПАСНОСТИ, как только они становятся очевидными. Это подразумевает итерацию в рамках реализации мер по УПРАВЛЕНИЮ РИСКОМ.
Важно, чтобы все РЕЗУЛЬТАТЫ в любой момент времени находились и сохранялись согласованными и непротиворечивыми. Итерация является угрозой согласованности РЕЗУЛЬТАТОВ. Именно поэтому важно использовать четкое управление конфигурацией с целью обеспечения того, что все последствия изменений идентифицированы и все связанные с ними РЕЗУЛЬТАТЫ обновлены после изменения. Это особенно важно, если предусмотрено сложное программное обеспечение, поскольку оно может быстро меняться, и любое небольшое с виду изменение может иметь неожиданные побочные эффекты. Вся информация, относящаяся к программному обеспечению, должна обновляться немедленно, чтобы не возникало недопонимания между инженерами. Предложения в отношении изменений программного обеспечения проверяются на побочные эффекты, особенно на те, которые влияют на БЕЗОПАСНОСТЬ. Это может привести к итерации этапов ПРОЦЕССА МЕНЕДЖМЕНТА РИСКА.
3.1.3 Упреждающий или реактивный подход к проектированию БЕЗОПАСНОСТИ
МЕНЕДЖМЕНТ РИСКА должен начинаться на ранних стадиях проектирования с надежных входных данных в отношении спецификации МЕДИЦИНСКОГО ИЗДЕЛИЯ с учетом БЕЗОПАСНОСТИ. Упреждающий подход к проекту предпочтительнее реактивного. При упреждающем подходе БЕЗОПАСНОСТЬ учитывается вместе с другими потребностями клиента и принимается в качестве начального требования. Хотя реактивный метод иногда неизбежен (например, когда обновляется уже выпущенная в обращение продукция), упреждающий подход - обычно самый эффективный, быстрый и дешевый способ получить безопасное МЕДИЦИНСКОЕ ИЗДЕЛИЕ.
Преимущества упреждающего проектирования БЕЗОПАСНОСТИ:
- с самого начала спецификация СИСТЕМЫ включает не только то, что МЕДИЦИНСКОЕ ИЗДЕЛИЕ должно делать, но и определяет поведение СИСТЕМЫ, которого следует избегать с целью снижения РИСКА;
- с самого начала АРХИТЕКТУРА СИСТЕМЫ может планироваться с целью обеспечения возможности демонстрации того, что обеспечиваются желаемые характеристики и при этом исключаются или предупреждаются небезопасные состояния;
- в то время как АРХИТЕКТУРА завершена до состояния готового проекта, меры по УПРАВЛЕНИЮ РИСКОМ могут разрабатываться без доработки;
- выбор подходов к БЕЗОПАСНОСТИ и мер по УПРАВЛЕНИЮ РИСКОМ может быть сделан достаточно рано (например, БЕЗОПАСНОСТЬ, обусловленная проектом, может быть максимально увеличена, а информация по БЕЗОПАСНОСТИ сведена к минимуму).
3.1.4 Характеристики безопасности СИСТЕМ, включающих программное обеспечение
Крайне желательные характеристики безопасности СИСТЕМ включают:
a) использование простых аппаратных механизмов обеспечения БЕЗОПАСНОСТИ во избежание чрезмерных требований к ПРОГРАММНЫМ ЭЛЕМЕНТАМ, СВЯЗАННЫХ С БЕЗОПАСНОСТЬЮ;
b) использование только очень простых ПРОГРАММНЫХ ЭЛЕМЕНТОВ, СВЯЗАННЫХ С БЕЗОПАСНОСТЬЮ;
c) распределение СВЯЗАННЫХ С БЕЗОПАСНОСТЬЮ ПРОГРАММНЫХ ЭЛЕМЕНТОВ между некоторым числом независимых процессоров;
d) достаточные аппаратные возможности для запуска всего СВЯЗАННОГО С БЕЗОПАСНОСТЬЮ программного обеспечения, когда это необходимо и без одобрения;
e) использование детерминированного подхода к срокам проектирования программного обеспечения;
f) надлежащая обработка отказа, например:
1) предупреждение пользователя об отказе и предоставление возможностей для информированного вмешательства;
2) обеспечение ограниченной функциональности в условиях отказа;
3) безопасное отключение, когда это возможно в условиях отказа;
4) быстрое восстановление после отказа.
g) средства, препятствующие изменению программного кода в среде его выполнения или через самомодификацию, или в результате ввода данных;
h) средства определения и (или) предотвращения вмешательства в СВЯЗАННЫЕ С БЕЗОПАСНОСТЬЮ данные.
3.2 Ответственность высшего руководства
|
Текст ИСО 14971
3.2 Ответственность высшего руководства
ВЫСШЕЕ РУКОВОДСТВО должно обеспечивать свидетельства своей приверженности ПРОЦЕССУ МЕНЕДЖМЕНТА РИСКА посредством:
- обеспечения необходимыми ресурсами;
- назначения квалифицированного персонала (см. 3.3) для целей МЕНЕДЖМЕНТА РИСКА.
ВЫСШЕЕ РУКОВОДСТВО должно:
- разрабатывать и документировать политику установления критериев допустимости РИСКА. Данная политика должна гарантировать, что установленные критерии основаны на применимых национальных и региональных нормативных документах и соответствующих международных стандартах, а также учитывают доступную информацию, такую как современный уровень научно-технического развития и потребности заинтересованных сторон;
- проводить анализ пригодности ПРОЦЕССА МЕНЕДЖМЕНТА РИСКА в запланированные промежутки времени для обеспечения постоянной результативности данного ПРОЦЕССА и документировать все решения и предпринятые действия. Если ИЗГОТОВИТЕЛЬ имеет действующую систему менеджмента качества, то данный анализ может быть частью анализа его системы менеджмента качества.
Примечание - Вышеуказанные документы могут быть включены в документы системы менеджмента качества ИЗГОТОВИТЕЛЯ, и на них могут быть ссылки в ФАЙЛЕ МЕНЕДЖМЕНТА РИСКА.
Соответствие требованиям данного подраздела проверяют путем контроля необходимых документов. |
Как ИСО 14971, так и МЭК 62304 предполагают наличие системы менеджмента качества. Требования к ВЫСШЕМУ РУКОВОДСТВУ при МЕНЕДЖМЕНТЕ РИСКА перечислены в ИСО 14971, п.3.2.
Примечание - п.3.1 ИСО 14971 устанавливает, что МЕНЕДЖМЕНТ РИСКА может быть составной частью системы менеджмента качества, а п.4.1 МЭК 62304 устанавливает, что демонстрация способности ИЗГОТОВИТЕЛЯ последовательно выполнять требования потребителей и применимые регулирующие требования может осуществляться при помощи системы менеджмента качества, соответствующей ИСО 13485, или системы менеджмента качества, требуемой национальным регулированием. МЭК 62304 также содержит рекомендации по положениям приложения В.4, 4.1, устанавливая, что необходимо определить МЕНЕДЖМЕНТ РИСКА как неотъемлемую часть системы менеджмента качества как общих рамок для применения подходящих инженерных методов и техник программирования.
ВЫСШЕЕ РУКОВОДСТВО отвечает за внедрение необходимой организационной структуры, достаточные ресурсы, отчетность и подготовку (см. 3.3) для эффективного ПРОЦЕССА МЕНЕДЖМЕНТА РИСКА, а также для БЕЗОПАСНОСТИ проекта и технической поддержки ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ МЕДИЦИНСКОГО ИЗДЕЛИЯ.
ИЗГОТОВИТЕЛЬ может рассмотреть вопрос аутсорсинга ПРОЦЕССОВ разработки или технического обслуживания программного обеспечения (например, проектирования, воплощения, тестирования или технического обслуживания). В таких ситуациях ВЫСШЕЕ РУКОВОДСТВО все равно полностью ответственно за обеспечение того, что соответствующие действия по МЕНЕДЖМЕНТУ РИСКА были выполнены при аутсорсинге ПРОЦЕССОВ разработки или технической поддержки программного обеспечения, а также ответственно за то, что меры по УПРАВЛЕНИЮ РИСКОМ применены надлежащим образом.
Если разработка программного обеспечения передана на аутсорсинг, ИЗГОТОВИТЕЛИ с помощью подходящих договорных соглашений должны в достаточной мере обеспечить управление программным обеспечением и его проектированием, чтобы выполнить все требования по МЕНЕДЖМЕНТУ РИСКА, установленные ИСО 14971, на протяжении всего ЖИЗНЕННОГО ЦИКЛА МЕДИЦИНСКОГО ИЗДЕЛИЯ, включая коррекцию АНОМАЛИЙ после того, как программное обеспечение уже выпущено.
ИЗГОТОВИТЕЛЬ должен рассмотреть вопрос об установлении требований к поставщикам (см. ИСО 13485) [1], п.7.4 по управлению поставщиками), требуя от них продемонстрировать, например:
- эффективный МЕНЕДЖМЕНТ РИСКА в соответствии с ИСО 14971;
- эффективную практику разработки программного обеспечения в соответствии с МЭК 62304;
- способность предоставить ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ МЕДИЦИНСКИХ ИЗДЕЛИЙ, которое равным образом удовлетворяет требованиям клиента и применимым регулирующим требованиям.
Если разработаны меры по УПРАВЛЕНИЮ РИСКОМ, примененные к аутсорсинговым ПРОЦЕССАМ или продуктам, эти меры и их значимость должны быть документированы и четко установлены в пределах договорного соглашения с поставщиком.
3.3 Квалификация персонала
3.3.1 Общие положения
|
Текст ИСО 14971
3.3 Квалификация персонала
Персонал, выполняющий задачи по МЕНЕДЖМЕНТУ РИСКА, должен иметь знания и опыт, обеспечивающие возможность выполнения данных задач. Квалификация персонала должна включать знание рассматриваемых (или подобных) МЕДИЦИНСКИХ ИЗДЕЛИЙ, опыт их применения, а также владение применяемыми технологиями и методами МЕНЕДЖМЕНТА РИСКА. ЗАПИСИ о необходимой квалификации персонала следует поддерживать в рабочем состоянии.
Примечание - Задачи по МЕНЕДЖМЕНТУ РИСКА могут решать представители разных функциональных подразделений с учетом имеющихся у них специальных знаний.
Соответствие требованиям данного подраздела проверяют путем контроля вышеуказанных записей. |
Члены группы, участвующие в разработке и поддержании ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ СИСТЕМЫ, должны иметь знания и опыт, соответствующие поставленным перед ними ЗАДАЧАМ. Чрезвычайно важно, чтобы лицо, назначенное для выполнения ЗАДАЧ, связанных с обработкой (импликацией) данных МЕНЕДЖМЕНТА РИСКА, обладало необходимыми знаниями по МЕНЕДЖМЕНТУ РИСКА. Участие междисциплинарной группы, включая клинических экспертов (например, экспертов по клинической поддержке и техническому обслуживанию, экспертов по другим связанным областям), инженеров-программистов, системных проектировщиков, экспертов по проектированию эксплуатационной пригодности и в других областях, а также степень и тип их взаимодействия при программировании и испытаниях, должно рассматриваться в отношении МЕНЕДЖМЕНТА РИСКА.
Это может потребовать разработки учебных программ для отдельных лиц в целях обеспечения полного понимания требуемой деятельности и проводимых мероприятий.
Кроме того, должна быть рассмотрена квалификация каждого участника группы по МЕНЕДЖМЕНТУ РИСКА по отношению к программному обеспечению, в результате чего может потребоваться специальная подготовка.
Следующие подпункты должны обеспечивать обзор области требуемых знаний, которые следует учитывать.
3.3.2 ПРЕДУСМОТРЕННОЕ ПРИМЕНЕНИЕ - знания предметной области
На всех стадиях проектирования МЕДИЦИНСКОГО ИЗДЕЛИЯ важно использовать знания о ПРЕДУСМОТРЕННОМ ПРИМЕНЕНИИ. Это особенно важно как для разработчиков программного обеспечения, так и для персонала, осуществляющего МЕНЕДЖМЕНТ РИСКА программного обеспечения. Сложное поведение программного обеспечения может легко способствовать неправильному применению или введению в заблуждение пользователей, что может привести к непредвиденным ранее ОПАСНОСТЯМ и ОПАСНЫМ СИТУАЦИЯМ. Тщательная оценка клинической практики позволяет менеджерам по РИСКУ идентифицировать ОПАСНОСТИ и ОПАСНЫЕ СИТУАЦИИ, а также позволит инженерам-программистам избегать ОПАСНОСТЕЙ и ОПАСНЫХ СИТУАЦИЙ и разрабатывать меры по УПРАВЛЕНИЮ РИСКОМ.
ИЗГОТОВИТЕЛИ должны обеспечить, чтобы клинические эксперты (например, эксперты по клинической поддержке и техническому обслуживанию, эксперты по другим связанным областям) были способны участвовать в деятельности по проектированию и деятельности по МЕНЕДЖМЕНТУ РИСКА или, по крайней мере, давать консультации.
Кроме того, ИЗГОТОВИТЕЛЯМ следует рассматривать необходимость обучения менеджеров по РИСКУ и инженеров-программистов клиническому применению МЕДИЦИНСКОГО ИЗДЕЛИЯ.
3.3.3 Опыт программирования и подход
Опытные разработчики и лица, проводящие испытания программного обеспечения, учатся реалистичному отношению к сложности обнаружения всех дефектов программного обеспечения во время испытаний и, следовательно, к относительной концентрации дефектов, остающихся после испытаний. Важно включать опытных сотрудников в группу по разработке программного обеспечения и давать им соответствующие полномочия наставника, чтобы обучать, наблюдать и давать задания менее опытным сотрудникам.
Назначение опытных сотрудников особенно важно для выполнения следующих ЗАДАЧ в отношении программного обеспечения:
- идентификации того, каким образом программное обеспечение может выйти из строя;
- анализа РИСКОВ, связанных с отказом программного обеспечения;
- идентификации мер по УПРАВЛЕНИЮ РИСКОМ;
- анализа сообщений о проблемах, полученных после выпуска программного обеспечения;
- разработки и внедрения изменений, особенно тех, которые осуществляются после выпуска программного обеспечения.
Во всех этих ЗАДАЧАХ опыт приводит к пониманию того, что может пойти неправильно в программном обеспечении и в ПРОЦЕССАХ разработки программного обеспечения, а также к пониманию сложностей в осуществлении изменений при поддержании целостности проекта программного обеспечения.
3.4 План МЕНЕДЖМЕНТА РИСКА
3.4.1 Общие положения
|
Текст ИСО 14971
3.4 План МЕНЕДЖМЕНТА РИСКА
Деятельность по МЕНЕДЖМЕНТУ РИСКА необходимо планировать. Ввиду этого ИЗГОТОВИТЕЛЬ должен составить и документировать план МЕНЕДЖМЕНТА РИСКА для рассматриваемого МЕДИЦИНСКОГО ИЗДЕЛИЯ в соответствии с ПРОЦЕССОМ МЕНЕДЖМЕНТА РИСКА. План МЕНЕДЖМЕНТА РИСКА должен быть частью файла МЕНЕДЖМЕНТА РИСКА.
Данный план должен включать как минимум:
a) объем применения запланированной деятельности по МЕНЕДЖМЕНТУ РИСКА, в том числе идентификацию и описание МЕДИЦИНСКОГО ИЗДЕЛИЯ и стадий его жизненного цикла, к которым применим каждый элемент плана;
b) распределение ответственности и полномочий;
c) требования к анализу деятельности по МЕНЕДЖМЕНТУ РИСКА;
d) критерии допустимости РИСКА, основанные на политике ИЗГОТОВИТЕЛЯ по установлению допустимого РИСКА, включая случаи, когда вероятность причинения ВРЕДА не может быть определена;
e) действия по ВЕРИФИКАЦИИ;
f) действия по сбору и анализу информации, относящейся к МЕНЕДЖМЕНТУ РИСКА, на производственной и ПОСТПРОИЗВОДСТВЕННОЙ стадиях.
Примечания
1 Руководящие указания по разработке плана МЕНЕДЖМЕНТА РИСКА см. в приложении F.
2 Необязательно все элементы плана МЕНЕДЖМЕНТА РИСКА разрабатывать одновременно. План или его элементы можно разрабатывать поэтапно.
3 Критерии допустимости РИСКА имеют большое значение для определения конечной результативности ПРОЦЕССА МЕНЕДЖМЕНТА РИСКА. Для каждого плана МЕНЕДЖМЕНТА РИСКА изготовителю следует выбирать надлежащие критерии допустимости РИСКА.
Среди прочих можно рассматривать следующие варианты:
- построение матрицы (рисунки D.4 и D.5), иллюстрирующей допустимые и недопустимые комбинации вероятности причинения ВРЕДА и ТЯЖЕСТИ ВРЕДА;
- дальнейшее подразделение области матрицы ("пренебрежимо малый РИСК", "допустимый РИСК при условии его минимизации" и т.д.) с требованием к РИСКАМ, чтобы они сначала были уменьшены, насколько это практически осуществимо, прежде чем признать их допустимыми (см. D.8).
Любой из вариантов следует выбирать в соответствии с политикой ИЗГОТОВИТЕЛЯ в отношении установления критериев допустимости РИСКА и на основании применимых национальных или региональных нормативных документов, а также соответствующих международных стандартов с учетом доступной информации, такой как современный уровень научно-технического развития и интересы заинтересованных сторон (см. 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 Специфические связанные с РИСКОМ темы плана разработки программного обеспечения согласно МЭК 62304
План разработки программного обеспечения должен обеспечить, чтобы ПРОЦЕСС разработки программного обеспечения, стандарты, методы и средства, связанные с разработкой программного обеспечения (описанные в плане разработки программного обеспечения согласно МЭК 62304, раздел 4), были эффективными мерами по УПРАВЛЕНИЮ РИСКОМ (см. 6.2.2.6 для обсуждения ПРОЦЕССА как меры по УПРАВЛЕНИЮ РИСКОМ). Это может быть достигнуто путем предоставления доказательств другими организациями, поставщиками, а также от других проектов в рамках организации. Если это неизвестно, осуществляется планирование и ВЕРИФИКАЦИЯ результативности внутри проекта.
При разработке ПРОЦЕССА МЕНЕДЖМЕНТА РИСКА МЕДИЦИНСКОГО ИЗДЕЛИЯ должны учитываться аспекты, специфичные для МЕНЕДЖМЕНТА РИСКА программного обеспечения, такие как стандарты безопасности кодирования, методы ВЕРИФИКАЦИИ (например, формальные доказательства, экспертные оценки, сквозные, моделирующие и т.д.) и использоваться синтаксические и логические проверки. Если такие аспекты рассматриваются как меры по УПРАВЛЕНИЮ РИСКОМ, они также подлежат ВЕРИФИКАЦИИ (см. таблицу В.2 для примеров верификации мер по УПРАВЛЕНИЮ РИСКОМ).
Деятельность по МЕНЕДЖМЕНТУ РИСКА программного обеспечения должна осуществляться на каждой стадии разработки МЕДИЦИНСКОГО ИЗДЕЛИЯ в планах, ПРОЦЕДУРАХ, обучении, если применимо.
3.5 ФАЙЛ МЕНЕДЖМЕНТА РИСКА
|
Текст ИСО 14971
3.5 ФАЙЛ МЕНЕДЖМЕНТА РИСКА
Для рассматриваемого МЕДИЦИНСКОГО ИЗДЕЛИЯ ИЗГОТОВИТЕЛЬ должен создать и поддерживать в рабочем состоянии ФАЙЛ МЕНЕДЖМЕНТА РИСКА. В дополнение к требованиям других разделов настоящего стандарта ФАЙЛ МЕНЕДЖМЕНТА РИСКА должен обеспечивать возможность прослеживания каждой идентифицированной ОПАСНОСТИ при:
- АНАЛИЗЕ РИСКА;
- ОЦЕНИВАНИИ РИСКА;
- выполнении и ВЕРИФИКАЦИИ мер по УПРАВЛЕНИЮ РИСКОМ;
- оценивании допустимости любого(ых) ОСТАТОЧНОГО(ЫХ) PИCКA(OB).
Примечания
1 ЗАПИСИ и другие документы, составляющие ФАЙЛ МЕНЕДЖМЕНТА РИСКА, могут быть частью других документов и файлов, требуемых, например, системой менеджмента качества ИЗГОТОВИТЕЛЯ. ФАЙЛ МЕНЕДЖМЕНТА РИСКА необязательно должен непосредственно включать все записи и другие документы, относящиеся к настоящему стандарту. Однако он должен содержать, по меньшей мере, ссылки или указания на все требуемые документы. Изготовителю следует своевременно собрать ссылочную информацию в ФАЙЛЕ МЕНЕДЖМЕНТА РИСКА.
2 ФАЙЛ МЕНЕДЖМЕНТА РИСКА может быть представлен в любой форме или на любом носителе информации.
|
ПРОЦЕСС программного обеспечения должен установить систему ПРОСЛЕЖИВАЕМОСТИ, которая начинается с идентификации ОПАСНОСТЕЙ, связанных с программным обеспечением, и мер по УПРАВЛЕНИЮ РИСКОМ программного обеспечения. Эта система должна прослеживать выполнение требований, связанных с БЕЗОПАСНОСТЬЮ программного обеспечения и требований К ЭЛЕМЕНТАМ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ.
Все вышеупомянутое должно прослеживаться до ВЕРИФИКАЦИИ программного обеспечения (см. МЭК 62304, п.7.3.3).
Поскольку программное обеспечение может часто изменяться во время разработки и быть реализовано в различных ВЕРСИЯХ, часть файла МЕНЕДЖМЕНТА РИСКА, относящаяся к программному обеспечению, может подвергаться изменениям и существовать во множестве ВЕРСИЙ.
В таблице 1 перечислены требования МЭК 62304 к документации, которую следует включать в ФАЙЛ МЕНЕДЖМЕНТА РИСКА в дополнение к требованиям ИСО 14971.
Таблица 1 - Требования МЭК 62304 к документации, которую следует включать в ФАЙЛ МЕНЕДЖМЕНТА РИСКА в дополнение к требованиям ИСО 14971.
|
|
Пункты и подпункты МЭК 62304 | Документация ФАЙЛА МЕНЕДЖМЕНТА РИСКА |
4.3 с) | Класс БЕЗОПАСНОСТИ программного обеспечения, назначенный каждой ПРОГРАММНОЙ СИСТЕМЕ |
4.3 f) | Логическое объяснение для использования более низкого класса БЕЗОПАСНОСТИ (чем у ПРОГРАММНОЙ СИСТЕМЫ) для ПРОГРАММНОГО ЭЛЕМЕНТА В ПРОГРАММНОЙ СИСТЕМЕ, который не осуществляет СВЯЗАННЫХ С БЕЗОПАСНОСТЬЮ функций |
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-vitro приведены в приложении Н.
4 Дополнительные руководящие указания по методам АНАЛИЗА РИСКА в отношении токсикологических ОПАСНОСТЕЙ приведены в приложении I.
В дополнение к записям, требуемым в 4.2-4.4, документы, относящиеся к проведению и результатам АНАЛИЗА РИСКА, должны включать как минимум:
а) описание и идентификацию рассматриваемого МЕДИЦИНСКОГО ИЗДЕЛИЯ;
b) идентификацию лица (лиц) и организации, выполнивших АНАЛИЗ РИСКА;
с) область применения и дату проведения АНАЛИЗА РИСКА.
5 Область применения АНАЛИЗА РИСКА может быть очень широкой (например, разработка нового изделия, в отношении применения которого у ИЗГОТОВИТЕЛЯ мало опыта или данный опыт вообще отсутствует) или ограниченной (например, анализ влияния привносимых изменений на выпускаемое изделие, о котором в файлах ИЗГОТОВИТЕЛЯ имеется обширная информация).
Соответствие требованиям данного подраздела проверяют путем контроля файла МЕНЕДЖМЕНТА РИСКА. |
Как установлено в ИСО 14971, АНАЛИЗ РИСКА является термином, который используется, чтобы охватить три различных вида деятельности:
- идентификацию ПРЕДУСМОТРЕННОГО ПРИМЕНЕНИЯ;
- идентификацию известных или прогнозируемых ОПАСНОСТЕЙ (и их причин);
- определение РИСКА от каждой ОПАСНОСТИ И ОПАСНОЙ СИТУАЦИИ.
Важно заметить, что АНАЛИЗ РИСКА с целью обеспечения его эффективности осуществляется как неотъемлемая часть всего ПРОЦЕССА разработки программного обеспечения, а не как одно или два отдельных события потому, что информация об ОПАСНОСТИ и виде отказа накапливается по мере осуществления ПРОЦЕССА разработки ЖИЗНЕННОГО ЦИКЛА программного обеспечения и должна учитываться на каждой стадии проектирования.
Поскольку очень трудно определить вероятность АНОМАЛИЙ программного обеспечения, которые могут способствовать ОПАСНЫМ СИТУАЦИЯМ, центр программных аспектов АНАЛИЗА РИСКА направлен на идентификацию потенциальных функций программного обеспечения и АНОМАЛИЙ, которые могут привести к ОПАСНЫМ СИТУАЦИЯМ, а не на определение вероятности. См. 4.4.3 для более подробной информации об определении вероятности.
ТЯЖЕСТЬ ВРЕДА в условиях наихудшего случая, для которого программное обеспечение является способствующим фактором, является первичной информацией для установления уровня тщательности ПРОЦЕССОВ разработки программного обеспечения (см. МЭК 62304, п.4.3). Информация, приведенная в 4.2, 4.3 и 4.4, предназначена, чтобы помочь идентифицировать определенные для программного обеспечения аспекты эффективного ПРОЦЕССА МЕНЕДЖМЕНТА РИСКА. Кроме того, программные аспекты АНАЛИЗА РИСКА должны быть идентифицированы в создаваемой документации и должны включать как программное обеспечение, используемое для осуществления мер по УПРАВЛЕНИЮ РИСКОМ в отношении отказа аппаратных средств, так и программное обеспечение, вызывающее ОПАСНОСТИ и связанные с ними меры по УПРАВЛЕНИЮ РИСКОМ.
4.2 ПРЕДУСМОТРЕННОЕ ПРИМЕНЕНИЕ и определение характеристик, относящихся к БЕЗОПАСНОСТИ МЕДИЦИНСКОГО ИЗДЕЛИЯ
4.2.1 Общее
|
Текст ИСО 14971
4.2 ПРЕДУСМОТРЕННОЕ ПРИМЕНЕНИЕ и определение характеристик, относящихся к БЕЗОПАСНОСТИ МЕДИЦИНСКОГО ИЗДЕЛИЯ
Для рассматриваемого МЕДИЦИНСКОГО ИЗДЕЛИЯ ИЗГОТОВИТЕЛЬ должен документировать все случаи ПРЕДУСМОТРЕННОГО ПРИМЕНЕНИЯ и обоснованно прогнозируемого неправильного применения. ИЗГОТОВИТЕЛЬ должен также идентифицировать и документировать все качественные и количественные характеристики, которые могут повлиять на БЕЗОПАСНОСТЬ МЕДИЦИНСКОГО ИЗДЕЛИЯ и при необходимости указать их предельно допустимые значения. Данные документы необходимо поддерживать в рабочем состоянии в ФАЙЛЕ МЕНЕДЖМЕНТА РИСКА.
Примечания
1 В контексте настоящего стандарта неправильное применение означает непредусмотренное или ненадлежащее применение МЕДИЦИНСКОГО ИЗДЕЛИЯ.
2 Приложение С содержит вопросы, относящиеся к применению МЕДИЦИНСКОГО ИЗДЕЛИЯ, которые могут стать полезным ориентиром при идентификации характеристик данного изделия, способных повлиять на его БЕЗОПАСНОСТЬ.
Соответствие требованиям данного подраздела проверяют путем контроля файла МЕНЕДЖМЕНТА РИСКА. |
Хотя каждое МЕДИЦИНСКОЕ ИЗДЕЛИЕ имеет ПРЕДУСМОТРЕННОЕ ПРИМЕНЕНИЕ, должна быть рассмотрена возможность преднамеренного или непреднамеренного неправильного применения. Хотя это касается не только программного обеспечения, но его использование может привести к повышенному РИСКУ неправильного применения из-за следующего:
- поведение МЕДИЦИНСКОГО ИЗДЕЛИЯ является более сложным и поэтому более трудным для управления или понимания;
- пользователь может чрезмерно полагаться на программное обеспечение, не понимая его возможностей и ограничений;
- МЕДИЦИНСКОЕ ИЗДЕЛИЕ может быть настраиваемым, и пользователь может быть не знаком с текущей конфигурацией;
- МЕДИЦИНСКИЕ ИЗДЕЛИЯ могут взаимодействовать с медицинскими или НЕМЕДИЦИНСКИМИ ИЗДЕЛИЯМИ способом, который ИЗГОТОВИТЕЛЬ МЕДИЦИНСКОГО ИЗДЕЛИЯ не может предвидеть во всех деталях.
Лицо, ответственное за создание системных требований, и разработчик программного обеспечения совместно ответственны за ЗАПИСИ в ФАЙЛЕ МЕНЕДЖМЕНТА РИСКА о ПРЕДУСМОТРЕННОМ ПРИМЕНЕНИИ СИСТЕМЫ, включая программное обеспечение, а также за все системные и программные требования, которые относятся к БЕЗОПАСНОСТИ и безопасному применению. Разработчик программного обеспечения конкретно отвечает за идентификацию аспектов ПРЕДУСМОТРЕННОГО ПРИМЕНЕНИЯ, которые являются слишком трудноуловимыми, чтобы быть очевидными на уровне СИСТЕМЫ.
4.2.2 Интерфейс пользователя
Наличие программного обеспечения делает возможным проектирование гибких пользовательских интерфейсов, которые могут повлиять на поведение пользователей, приводя к новым формам обоснованно прогнозируемого неправильного применения. Общие случаи неправильного применения возникают из-за недопонимания чрезмерно сложного пользовательского интерфейса и слишком большой уверенности в возможностях программного обеспечения избегать ошибок и опасных состояний. Важно предвидеть подобное неправильное применение и изменять конструкцию, чтобы избежать его насколько возможно.
В связи с этим следует использовать маркировки на нескольких языках, особенно когда такая маркировка является мерой по УПРАВЛЕНИЮ РИСКОМ. Особое внимание следует обратить на:
a) различную потребность в размере памяти для различных языков;
b) использование различных кодировок;
c) использование букв вместо символов;
d) использование разных единиц измерения, которые могут потребовать дополнительного масштабирования числовых результатов;
e) формат данных и пунктуацию в числах;
f) различные требования к расположению для различных языков и (или) кодировок;
g) поддержку валидации.
См. МЭК 62366 [5] дополнительно к ИСО 14971 для ПРОЦЕССА эксплуатационной пригодности.
4.2.3 МЕДИЦИНСКИЕ И ВЗАИМОСВЯЗАННЫЕ С НИМИ ИЗДЕЛИЯ
Использование программного обеспечения в МЕДИЦИНСКИХ ИЗДЕЛИЯХ делает возможным ряд взаимосвязей и коммуникаций между МЕДИЦИНСКИМИ и НЕМЕДИЦИНСКИМИ ИЗДЕЛИЯМИ. Такие связи и коммуникации делают возможными новые области применения (и неправильное применение) СИСТЕМЫ, включающей МЕДИЦИНСКИЕ ИЗДЕЛИЯ и взаимосвязанные устройства. Хотя легко предвидеть, что новые виды применения и неправильного применения могут иметь место, для ИЗГОТОВИТЕЛЯ МЕДИЦИНСКИХ ИЗДЕЛИЙ нелегко определить все виды применения и неправильного применения, если взаимосвязи и коммуникации не ограничены.
Вот почему для ИЗГОТОВИТЕЛЕЙ важно определить ограниченный перечень ПРЕДУСМОТРЕННОГО ПРИМЕНЕНИЯ для коммуникационных интерфейсов МЕДИЦИНСКОГО ИЗДЕЛИЯ и проектировать интерфейсы так, чтобы в максимально возможной степени ограничить взаимосвязи и коммуникации только теми из них, которые являются безопасными.
Например, программное обеспечение может, используя встроенный интерфейс МЕДИЦИНСКОГО ИЗДЕЛИЯ, проверить обработку введенных данных на согласованность и достоверность, основываясь на идентификации пользователя, пациента и контекста подготовки данных. Если данные подготовлены где-либо в другом месте и введены в МЕДИЦИНСКОЕ ИЗДЕЛИЕ с использованием сетевой коммуникации, то может оказаться невозможным применить подобную проверку. В таких случаях ИЗГОТОВИТЕЛЬ может проверить программное обеспечение доступными для пользователей сети средствами применения сетевого приложения и (или) ограничения импорта данных проверенными источниками, а также созданием подробного руководства для ответственных лиц, которые отвечают за сетевые коммуникации в условиях медицинского учреждения.
МЭК 80001-1 [6] устанавливает требования к интеграции МЕДИЦИНСКИХ ИЗДЕЛИЙ в информационной сети медицинского учреждения. В частности, устанавливает ответственность ИЗГОТОВИТЕЛЯ и лица, которое интегрирует МЕДИЦИНСКОЕ ИЗДЕЛИЕ в информационную сеть.
4.3 Идентификация ОПАСНОСТЕЙ
|
Текст ИСО 14971
4.3 Идентификация ОПАСНОСТЕЙ
ИЗГОТОВИТЕЛЬ должен составить перечень известных или прогнозируемых ОПАСНОСТЕЙ, связанных с рассматриваемым МЕДИЦИНСКИМ ИЗДЕЛИЕМ, как для нормальных условий, так и для условий отказа.
Данный перечень необходимо поддерживать в рабочем состоянии в ФАЙЛЕ МЕНЕДЖМЕНТА РИСКА.
Примечание - Примеры возможных ОПАСНОСТЕЙ, приведенные в Е.2 и Н.2.4, могут быть использованы как руководство для ИЗГОТОВИТЕЛЯ, выполняющего идентификацию ОПАСНОСТЕЙ.
Соответствие требованиям данного подраздела проверяют путем контроля файла МЕНЕДЖМЕНТА РИСКА. |
Цель идентификации ОПАСНОСТИ состоит в том, чтобы сделать возможным анализ всех прогнозируемых ОПАСНОСТЕЙ с целью разработки и реализации эффективных мер по УПРАВЛЕНИЮ РИСКОМ.
В отличие от высокой температуры, электрической энергии и подвешенных грузов, программное обеспечение само по себе не является ОПАСНОСТЬЮ (потенциальным источником ВРЕДА), так как контакт с программным обеспечением не может вызвать травму. Однако программное обеспечение может стать причиной того, что человек подвергается ОПАСНОСТИ, другими словами, оно может способствовать созданию ОПАСНОЙ СИТУАЦИИ. Отказы программного обеспечения (любого рода) часто способствуют переходу ОПАСНОСТИ в ОПАСНУЮ СИТУАЦИЮ.
Таким образом, хотя программное обеспечение редко вводит новые ОПАСНОСТИ, оно часто изменяет ОПАСНУЮ СИТУАЦИЮ. Что еще более важно для ИЗГОТОВИТЕЛЯ, оно может переложить ответственность за предотвращение ОПАСНЫХ СИТУАЦИЙ от пользователя на ИЗГОТОВИТЕЛЯ.
Например, скальпель представляет очевидную ОПАСНОСТЬ порезаться. Однако ИЗГОТОВИТЕЛЬ обычно не несет ответственности за эту ОПАСНОСТЬ вне пределов эргономичного дизайна, поскольку ОПАСНОСТЬ, как предполагается, находится полностью под контролем хирурга. Если скальпель является частью дистанционно управляемой хирургической системы, подобная ОПАСНОСТЬ все же существует, но ответственность за то, чтобы избежать ОПАСНОСТИ порезаться, теперь разделяется с ИЗГОТОВИТЕЛЕМ, который поставляет программное обеспечение, управляющее этим скальпелем.
Это означает, что УПРАВЛЕНИЕ РИСКОМ в отношении некоторых ОПАСНОСТЕЙ, которые раньше, в отсутствие программного обеспечения, зависели исключительно от профессионального применения МЕДИЦИНСКОГО ИЗДЕЛИЯ, теперь переходит на МЕНЕДЖМЕНТ РИСКА со стороны ИЗГОТОВИТЕЛЯ.
Наглядным примером является ОПАСНОСТЬ неправильного лечения из-за ошибочной обработки данных. Это всегда являлось ОПАСНОСТЬЮ, но, когда данные обрабатывались вручную, это не являлось ответственностью ИЗГОТОВИТЕЛЯ. Сейчас многие МЕДИЦИНСКИЕ ИЗДЕЛИЯ используют программное обеспечение для сбора, хранения, обращения или использования данных, что делает такую ОПАСНОСТЬ частью ответственности ИЗГОТОВИТЕЛЯ.
Программное обеспечение может способствовать ОПАСНЫМ СИТУАЦИЯМ несколькими способами, включая некоторые из нижеследующих (см. также приложение В):
- программное обеспечение может правильно реализовывать небезопасные СИСТЕМНЫЕ требования, приводя к поведению, небезопасная природа которого не ощущается до тех пор, пока не возникает фактический ВРЕД;
- спецификация программного обеспечения может неправильно реализовывать СИСТЕМНЫЕ требования, приводя к нежелательному поведению, которое является правильным согласно спецификации программного обеспечения;
- проектирование программного обеспечения и его реализация могут быть ошибочными, приводя к поведению, которое противоречит спецификации программного обеспечения. Очевидные недостатки могут являться результатом неправильного понимания спецификации программного обеспечения и ошибок при преобразовании спецификации в код. Менее очевидные недостатки могут быть обусловлены непредвиденными взаимодействиями между ПРОГРАММНЫМИ ЭЛЕМЕНТАМИ, а также между программным обеспечением и его инфраструктурой, включая аппаратные средства и операционную СИСТЕМУ.
В МЕДИЦИНСКОМ ИЗДЕЛИИ, содержащем программное обеспечение, тщательная и всесторонняя идентификация ОПАСНОСТИ может приводить (на более поздних стадиях ПРОЦЕССА МЕНЕДЖМЕНТА РИСКА) к следующим важным результатам:
- аппаратные меры по УПРАВЛЕНИЮ РИСКОМ, которые могут предотвратить нанесение ВРЕДА программным обеспечением;
- удаление потенциально опасных функций программного обеспечения из спецификации программного обеспечения;
- меры по УПРАВЛЕНИЮ РИСКОМ, которые внедрены в программное обеспечение для предотвращения причинения ВРЕДА (см. МЭК 62304 п.5.2.3);
- идентификация частей программного обеспечения, которые должны реализовываться с низкой плотностью дефектов, и частей спецификации программного обеспечения, которые должны подвергаться специальным испытаниям (МЭК 62304, п.4.3);
- идентификация ПРОГРАММНЫХ ЭЛЕМЕНТОВ с более высоким классом БЕЗОПАСНОСТИ, которые должны быть отделены от других ПРОГРАММНЫХ ЭЛЕМЕНТОВ (в программном обеспечении с более низким классом БЕЗОПАСНОСТИ), чтобы предотвратить ВРЕД, возникающий из-за неожиданных побочных эффектов (см. МЭК 62304, п.4.3 и п.5.3.5). Дальнейшее обсуждение этого вопроса см. в п.6.2.2.2.4.
Чтобы полностью идентифицировать ОПАСНОСТИ, нужно хорошо понимать клиническое применение МЕДИЦИНСКОГО ИЗДЕЛИЯ. Кроме того, программное обеспечение представляет собой проблему особой сложности, включая возможные сложные пользовательские интерфейсы. Поэтому идентификация ОПАСНОСТЕЙ программного обеспечения не может быть выполнена без привлечения внешних специалистов. Она должна выполняться на СИСТЕМНОМ уровне междисциплинарной группой, включающей клинических экспертов (таких как эксперты по клинической поддержке и техническому обслуживанию), инженеров-программистов, системных проектировщиков и экспертов по разработке эксплуатационной пригодности (см. также 3.3).
Идентификация ОПАСНОСТИ должна учитывать ВРЕД, который может быть результатом самой природы МЕДИЦИНСКОГО ИЗДЕЛИЯ (например, порез, облучение или поражение пациента электрическим током), а также дополнительные ОПАСНОСТИ, связанные с использованием программного обеспечения. Дополнительные ОПАСНОСТИ могут включать в себя, например:
- предоставление неверной информации врачу или пациенту;
- неправильная идентификация пациента (в случаях, если МЕДИЦИНСКОЕ ИЗДЕЛИЕ хранит информацию о пациенте или рецепты);
- отклонение запроса или его задержка, вызванные АНОМАЛИЕЙ программного обеспечения.
Примечание - Для многих медицинских изделий задержка или отклонение запроса не подразумевают ВРЕДА пациенту.
Идентифицированные ОПАСНОСТИ должны включать в себя как ОПАСНОСТИ, относящиеся к программному обеспечению, которое работает в соответствии с его спецификацией, так и ОПАСНОСТИ, относящиеся к АНОМАЛИЯМ программного обеспечения (см. 6.1).
Часто пользовательский интерфейс МЕДИЦИНСКОГО ИЗДЕЛИЯ становится более сложным из-за программного обеспечения. В частности, МЕДИЦИНСКОЕ ИЗДЕЛИЕ, которое включает программное обеспечение, наверняка будет управлять информацией. Поскольку это может быть оправдано с точки зрения выгоды для пациента, следует учитывать дополнительные ОПАСНОСТИ, которые связаны с неправильной или неправильно используемой информацией, например:
- неправильный ввод данных;
- неправильное чтение пользователем отображаемых результатов;
- перегрузка пользователей чрезмерными данными или излишним числом тревожных сообщений (см. МЭК 62366 [5]).
4.4 Определение РИСКА(ОВ) для каждой ОПАСНОЙ СИТУАЦИИ
4.4.1 Общие положения
|
Текст ИСО 14971
4.4 Определение РИСКА(ОВ) для каждой ОПАСНОЙ СИТУАЦИИ
Необходимо рассматривать обоснованно прогнозируемые последовательности или комбинации событий, приводящие к возникновению ОПАСНОЙ СИТУАЦИИ, и регистрировать возникающую(ие) ОПАСНУЮ(ЫЕ) СИТУАЦИЮ(И).
Примечания
1 Для идентификации не выявленных ранее ОПАСНЫХ СИТУАЦИЙ можно использовать системные методы, применимые в конкретной ситуации (см. приложение G).
2 Примеры ОПАСНЫХ СИТУАЦИЙ приведены в Н.2.4.5 и Е.4.
3 Источником ОПАСНЫХ СИТУАЦИЙ могут стать промахи, упущения и заблуждения.
Для каждой идентифицированной ОПАСНОЙ СИТУАЦИИ необходимо определять связанный(е) с ней РИСК(и), используя для этого доступную информацию или данные. Для ОПАСНЫХ СИТУАЦИЙ, в отношении которых не может быть определена вероятность причинения ВРЕДА, должен быть подготовлен перечень возможных последствий применения МЕДИЦИНСКОГО ИЗДЕЛИЯ, используемый при ОЦЕНИВАНИИ и УПРАВЛЕНИИ РИСКОМ. Результаты этой деятельности должны быть зарегистрированы в ФАЙЛЕ МЕНЕДЖМЕНТА РИСКА.
Любая система, используемая для качественной или количественной градации вероятности причинения ВРЕДА или ТЯЖЕСТИ ВРЕДА, также должна быть зарегистрирована в ФАЙЛЕ МЕНЕДЖМЕНТА РИСКА.
Примечания
1 ОПРЕДЕЛЕНИЕ РИСКА для МЕДИЦИНСКОГО ИЗДЕЛИЯ включает анализ вероятности возникновения РИСКА и последствий применения данного изделия. В зависимости от применения МЕДИЦИНСКОГО ИЗДЕЛИЯ, возможно, достаточно рассмотреть лишь некоторые элементы ПРОЦЕССА ОПРЕДЕЛЕНИЯ РИСКА. Например, в отдельных случаях нет необходимости идти дальше анализа исходной ОПАСНОСТИ и последствий применения (см. также D.3).
2 ОПРЕДЕЛЕНИЕ РИСКА может быть количественным или качественным. Методы ОПРЕДЕЛЕНИЯ РИСКА, в том числе являющиеся следствием систематических отказов, описаны в приложении D. Приложение Н содержит информацию, полезную при ОПРЕДЕЛЕНИИ РИСКОВ для МЕДИЦИНСКИХ ИЗДЕЛИЙ для диагностики in-vitro.
3 Информацию или данные для ОПРЕДЕЛЕНИЯ РИСКОВ можно получить из:
a) опубликованных стандартов;
b) научно-технической информации;
с) данных о применении подобных МЕДИЦИНСКИХ ИЗДЕЛИЙ, включая опубликованные сведения об инцидентах;
d) данных испытаний эксплуатационной пригодности типичными пользователями;
е) клинических данных;
f) результатов соответствующих исследований;
g) экспертных заключений;
h) схем внешней оценки качества.
Соответствие требованиям данного подраздела проверяют путем контроля файла МЕНЕДЖМЕНТА РИСКАМ |
Чтобы определить РИСК, связанный с программным обеспечением, необходимо идентифицировать ОПАСНЫЕ СИТУАЦИИ, которые включают в себя программное обеспечение. Программное обеспечение может быть или причиной, инициирующей последовательность событий, приводящих к ОПАСНОЙ СИТУАЦИИ, или являться причиной ОПАСНОЙ СИТУАЦИИ в любом другом месте последовательности событий, как в случае программного обеспечения, предназначенного для обнаружения сбоя аппаратных средств. Программное обеспечение может включать компоненты ПОНП или повторное использование ранее разработанных компонентов.
ОПРЕДЕЛЕНИЕ РИСКА основано на вероятности ВРЕДА и на ТЯЖЕСТИ ВРЕДА от каждой идентифицированной ОПАСНОЙ СИТУАЦИИ. Поскольку очень трудно определить вероятность ВРЕДА, являющегося результатом АНОМАЛИИ программного обеспечения (см. 4.4.3), вероятность появления АНОМАЛИИ программного обеспечения должна использоваться с осторожностью при определении РИСКА от ОПАСНОЙ СИТУАЦИИ, включая АНОМАЛИИ программного обеспечения в последовательности событий, приводящих к причинению ВРЕДА.
4.4.2 Методы идентификации
Для идентификации потенциальной роли программного обеспечения в ОПАСНЫХ СИТУАЦИЯХ может использоваться множество методов. Эти методы используют различные подходы и могут быть полезны на различных этапах разработки программного обеспечения. Ни один из них не является единственно правильным методом. См. также приложение G для информации о некоторых доступных методах АНАЛИЗА РИСКА.
Анализ дерева неисправностей (FTA) является традиционным методом анализа "сверху вниз" (см. МЭК 61025 [3]), часто используемым для анализа начиная с МЕДИЦИНСКОГО ИЗДЕЛИЯ в целом. Анализ дерева неисправностей чаще всего используется для анализа причины ВРЕДА. Постулируется, что ВРЕД нанесен и используется Булева логика, чтобы идентифицировать события или обстоятельства, которые должны произойти для того, чтобы ВРЕД наступил. События или обстоятельства анализируются с все возрастающей детализацией, пока не будет достигнута точка, где могут быть определены одна или более мер по УПРАВЛЕНИЮ РИСКОМ, которые будут предотвращать ВРЕД. Анализ дерева неисправностей может использоваться, чтобы определять ПРОГРАММНЫЕ ЭЛЕМЕНТЫ, которые вовлечены в последовательность событий, которая приводит к ОПАСНОЙ СИТУАЦИИ.
Анализ видов и последствий отказов (FMEA-анализ) является методом анализа "снизу вверх" (см. МЭК 60812 [2]), который начинается с компонента или подсистемы (для программного обеспечения это ПРОГРАММНЫЙ ЭЛЕМЕНТ в МЭК 62304) и ставит вопрос: "Если этот элемент откажет, какими будут последствия?".
Ввиду трудности предвидения того, какие дефекты программного обеспечения будут присутствовать в каждом ПРОГРАММНОМ ЭЛЕМЕНТЕ, в стартовой точке для FMEA-анализа следует перечислить все СВЯЗАННЫЕ С БЕЗОПАСНОСТЬЮ требования каждого ПРОГРАММНОГО ЭЛЕМЕНТА и рассмотреть вопрос: "Если это требование не выполняется, каковы будут последствия?".
Это приводит к идентификации ЭЛЕМЕНТОВ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ, отказ которых может вызвать ВРЕД, и идентификации того, какие типы отказа должны быть предотвращены.
При идентификации последовательностей или комбинаций событий, которые могут привести к ОПАСНОЙ СИТУАЦИИ, самым легким является необходимость сосредоточиться на программном обеспечении, непосредственно связанном с эксплуатационной пригодностью МЕДИЦИНСКОГО ИЗДЕЛИЯ (например, алгоритмы, которые вычисляет уровень содержания глюкозы в крови) и отдельных причинах связанных с ними ОПАСНОСТЕЙ. Также важно рассмотреть программные причины, которые могут приводить к трудно уловимым способам отказа и поэтому приводить к одной или более ОПАСНОСТЯМ МЕДИЦИНСКОГО ИЗДЕЛИЯ. См. приложение В для ознакомления с примерами программных причин.
Примечание - Отдельным видом причин являются дефекты программного обеспечения, функциональность которого явно связана с клинической функциональностью МЕДИЦИНСКОГО ИЗДЕЛИЯ и приводит к одной ИЗ ОПАСНОСТЕЙ, присущих изделию. В качестве примера можно привести дефект в алгоритме вычисления результатов теста.
Поскольку трудно точно предсказать, что может отказать в ПРОГРАММНОМ ЭЛЕМЕНТЕ, возможно идентифицировать категории дефектов, для каждой из которых имеются хорошо известные меры по УПРАВЛЕНИЮ РИСКОМ. Например, повреждение данных - класс отказов, которые могут быть обнаружены и подтверждены использованием контрольной процедуры. См. приложение В с примерами программных причин и предлагаемыми способами их обработки, ИЗГОТОВИТЕЛИ должны поддерживать свои собственные перечни категорий дефектов программного обеспечения, относящегося к их собственной продукции.
4.4.3 Вероятность
АНОМАЛИИ программного обеспечения в отдельной ВЕРСИИ программного обеспечения будут присутствовать во всех его копиях. Однако вероятность АНОМАЛИИ, приводящей к отказу программного обеспечения, очень трудно определить из-за случайной природы входных данных для каждой отдельной копии программного обеспечения.
Для получения доступа к полной версии без ограничений вы можете выбрать подходящий тариф или активировать демо-доступ.