ГОСТ Р 55544—201З
Л
ЕС
Л
-R80002-1:2009
Л
юбой из вариантов следует выбирать всоответствии с политикой ИЗГОТОВИТЕ
Л
Я в отношении
установления критериев допустимости РИСКА и на основании применимых национальных или регио
нальных нормативных документов, а также соответствующих международныхстандартов с учетом дос
тупной информации, такой как современный уровень научно-технического развития и интересы заинтере
сованных сторон (см. 3.2). Руководство по установлению данных критериев см. в D.4.
При внесении изменений в план МЕНЕДЖМЕНТА РИСКА в течениеЖИЗНЕННОГО ЦИК
Л
А МЕДИ
ЦИНСКОГО ИЗДЕ
Л
ИЯ необходимо сделать запись об изменениях в ФАЙ
Л
Е МЕНЕДЖМЕНТА РИСКА.
Соответствие требованиям данного подраздела проверяют путем контроля файла МЕНЕДЖМЕНТА
РИСКА.
План МЕНЕДЖМЕНТА РИСКА должен учитывать тот факт, что программное обеспечение является
частью МЕДИЦИНСКОГО ИЗДЕ
Л
ИЯ идолжно включать:
- описание МЕДИЦИНСКОГО ИЗДЕ
Л
ИЯ и то. какие функции МЕДИЦИНСКОГО ИЗДЕ
Л
ИЯ будут вы
полняться программным обеспечением:
- заявлениео том. что программное обеспечение будет разрабатываться в соответствии с МЭК62304;
- ссылку на аспекты разработки программного обеспечения, которые являются специфичными для
осуществления МЕНЕДЖМЕНТА РИСКА программного обеспечения (см. примечание):
- критерии допустимости РИСКА в отношении РИСКОВ, вызываемых программным обеспечением
или управляемых программным обеспечением, если они отличаются от критериев допустимости для дру
гих компонентов МЕДИЦИНСКОГО ИЗДЕ
Л
ИЯ.
П р и м е ч а н и е — Ссыпка на план разработки программного обеспечения может быть самым простым
способом для включения специфичных аспектов разработки программного обеспечения для осуществления
МЕНЕДЖМЕНТА РИСКА. См. также 3.4.2 и 3.4.3, в которых обсуждается взаимосвязь между планом
МЕНЕДЖМЕНТА РИСКА и планом разработки программного обеспечения, а также определенные связанные с
РИСКОМ темы плана разработки программного обеспечения согласно МЭК 62304.
Одной из причин, по которой критерии допустимости РИСКОВ, вызываемых или управляемых прог
раммным обеспечением, могут отличаться от критериев допустимости для других компонентов, является
то. что вероятность ВРЕДА не может быть оценена. В этом случае критерии допустимости РИСКА опре
деляются исходя из ТЯЖЕСТИ ВРЕДА. (См. 4.4.3 для обсуждения вероятности ВРЕДА, вызванного
программным обеспечением). Если можно считать, что ОПАСНОСТЬ имеет небольшое практическое
последствие. РИСК может быть оценен как допустимый, и в таком случае не требуется никаких мер по
УПРАВ
Л
ЕНИЮ РИСКОМ. Однако в случае существенных ОПАСНОСТЕЙ, то есть ОПАСНОСТЕЙ, которые
могут привести к ВРЕДУ высокой ТЯЖЕСТИ, не может быть определен уровень подверженности
ОПАСНОСТИ, который бы соответствовал настолько низкому РИСКУ, чтобы РИСК являлсядопустимым. В
этом случае должны быть разработаны меры по УПРАВ
Л
ЕНИЮ РИСКОМ.
Критерии допустимости РИСКАдля ОСТАТОЧНОГО РИСКА, где вероятность не может быть опреде
лена. следует принимать с учетом мер по УПРАВ
Л
ЕНИЮ РИСКОМ, которые были осуществлены, а также
результативности этих мер поУПРАВ
Л
ЕНИЮ РИСКОМ в снижении вероятности возникновения вреда. Меры по
УПРАВ
Л
ЕНИЮ РИСКОМ должны включать все приемлемые практически осуществимые меры,
удовлетворять применимым стандартам и регулирующим требованиям, а также быть современными
(см. ИСО 14971, приложение D. 4).
При планировании работ, связанных со сбором и анализом производственной и ПОСТПРОИЗВОД
СТВЕННОЙ информации, должны приниматься во внимание следующие специфичные для программного
обеспечения аспекты:
- если используется ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ НЕИЗВЕСТНОГО ПРОИСХОЖДЕНИЯ (ПОНП),
то должны быть запланированы активный мониторинг, а также ОЦЕНИВАНИЕ общедоступного списка
АНОМА
Л
ИЙ и информации об эксплуатационных характеристиках ПОНП. Где возможно, этодолжно
под держиваться в соответствии с договорным соглашением с поставщиком ПОНП. заключаемым
при его приобретении. Если пользователи МЕДИЦИНСКОГО ИЗДЕ
Л
ИЯ могут (преднамеренно или нет)
модифици ровать ПОНП МЕДИЦИНСКОГО ИЗДЕ
Л
ИЯ самостоятельно (например, применяя исправления
ПОНП или обновления), то следует тщательно рассмотреть вопросо проведении мониторинга при выпуске
в обраще ние новых версий ПОНП. См. раздел 9 относительно ПОНП и ПОСТПРОИЗВОДСТВЕННОГО
мониторинга:
- изготовительдолжен по запросу идентифицировать версию программного обеспечения и сообщить
ее инициатору жалобы.
9