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

ГОСТ Р 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)

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

Москва

Стандартинформ

2014

Предисловие

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

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

3    УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 28 августа 2013 г. № 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

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

ГОСТ Р 55544—201ЗЛЕСЯЯ 80002-1:2009

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

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

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

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

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

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

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

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

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

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

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

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

7

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

9

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4.2.1 Общее

12

ГОСТ Р 55544—201ЗЛЕСЛК 80002-1:2009

Содержание

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

9    Производственная и ПОСТПРОИЗВОДСТВЕННАЯ ИНФОРМАЦИЯ................ 32

Приложение А (справочное) Обсуждение определений...................... 35

Приложение В (справочное) Примеры использования программных средств............ 37

Приложение С (справочное) Потенциальные ошибки, связанные с программным обеспечением . .    49

Приложение D (справочное) Матрица жизненный цикл/менеджмент риска............. 53

Приложение Е (справочное) БЕЗОПАСНЫЕ случаи........................ 56

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

Список определенных терминов................................... 58

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

Введение

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

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

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

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

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

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

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

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

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

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

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

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

IV

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

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

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

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

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

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 для полного МЕНЕДЖМЕНТА РИСКА МЕДИЦИНСКОГО ИЗДЕЛИЯ. Важно подчеркнуть, что с целью обеспечения эффективности даже программные аспекты МЕНЕДЖМЕНТА РИСКА нуждаются в ориентации на РИСКИ, связанные с МЕДИЦИНСКИМ ИЗДЕЛИЕМ.

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

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

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

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

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

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

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

3.1.2 Итерация

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

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

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

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

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

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

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

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

Важно, чтобы все РЕЗУЛЬТАТЫ в любой момент времени находились и сохранялись согласованными и непротиворечивыми. Итерация является угрозой согласованности РЕЗУЛЬТАТОВ. Именно поэтому важно использовать четкое управление конфигурацией с целью обеспечения того, что все последствия

4

ГОСТ Р 55544—201ЗЛЕСЯЯ 80002-1:2009

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5

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

Как ИСО 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:

6