ГОСТ Р МЭК 60601-1—2022
целостности документации и при наличии различных версий документов — идентификация применимости каждой
версии программного обеспечения. По этой причине необходимо формировать, пересматривать и поддерживать
документацию с помощью официальной системы управления документооборотом. Для облегчения ПРОЦЕССА
оценки соответствия ИЗГОТОВИТЕЛИ должны гарантировать четкость и исчерпывающий характер документации.
Подпункт
14.3
— План МЕНЕДЖМЕНТА РИСКА
Подпункт 4.2.2 требует, чтобы план МЕНЕДЖМЕНТА РИСКА подготавливался и поддерживался в ФАЙЛЕ
МЕНЕДЖМЕНТА РИСКА.
Помимо элементов плана МЕНЕДЖМЕНТА РИСКА, требуемых 4.2.2, необходим и план ПРОВЕРКИ СООТ
ВЕТСТВИЯ ПЭМС, поскольку она должна рассматриваться как необходимая часть разработки ПЭМС.
Подпункт
14.4
— ЖИЗНЕННЫЙ ЦИКЛ РАЗРАБОТКИ ПЭМС
Задокументированный ЖИЗНЕННЫЙ ЦИКЛ РАЗРАБОТКИ ПЭМС обеспечивает рассмотрение вопросов без
опасности в процессе разработки изделия, что важно для всех изделий, но жизненно важно для ПЭМС, поскольку
безопасность ПЭМС не может быть повышена после ее разработки по следующим причинам:
a) реальные ПРОЦЕССЫ, используемые при проектировании ПЭМС, их качество и точность выбирают по
результатам ОЦЕНКИ РИСКА. Если впоследствии будет обнаружено использование недопустимых ПРОЦЕССОВ
или их неадекватные качество и точность, то разработка должна быть выполнена повторно с использованием
скорректированных ПРОЦЕССОВ;
b
) изменения, вносимые на последнем этапе ЖИЗНЕННОГО ЦИКЛА РАЗРАБОТКИ ПЭМС, вероятно, могут
потребовать больших затрат как времени, так и средств, особенно когда требования к системе были некорректны
или вообще отсутствовали. Построение системы также может сильно зависеть от изменений, вносимых на послед
них этапах проектирования, и нередко входит в отчет о безопасности, поэтому изменения на последних этапах про
ектирования могут потребовать существенных переделок для сохранения целостности компоновочного решения.
Структура
Жизненный цикл разработки дает основу, которая позволяет своевременно и систематически выполнять не
обходимые работы для обеспечения безопасности, не накладывая излишние ограничения, но при этом гарантируя
выполнение всех этих работ. Жизненный цикл разработки должен предлагаться заранее. При этом допускается
использовать различные модели цикла. В пункте Н.2 ЖИЗНЕННЫЕ ЦИКЛЫ РАЗРАБОТКИ ПЭМС рассматриваются
более подробно. Пункты 5, 7, 8 и 9 МЭК 62304:2006 и МЭК 62304:2006/AMD1:2015 устанавливают ПРОЦЕССЫ,
которые следует включать в цикл разработки программного обеспечения безопасных медицинских изделий.
Этапы проектирования и содержание работ
Требования к этапам и содержанию работ с указанием входных/выходных характеристик на каждом этапе
проектирования должны гарантировать должное рассмотрение:
- всех работ,
- тех требований, которые должны быть выполнены перед началом работ,
- той работы, которую необходимо выполнить,
для ВЕРИФИКАЦИИ результатов работ.
Последовательность работ в этом цикле следует определять с помощью этапов, поскольку это будет обеспе
чивать ИЗГОТОВИТЕЛЮ максимальную гибкость разработки. Никаких требований не предъявляется как к числу и
содержанию этих этапов, так и к последовательности выполнения всех этапов проектирования. В настоящем
стандарте не используют термин «фазы» (хотя он был использован в МЭК 60601-1-4 [14]) во избежание его увязки или
совпадения с используемым в фазовой модели.
В качественном жизненном цикле:
- необходимые работы должны определяться перед их выполнением;
- ПРОЦЕССЫ, используемые в этих работах, могут определяться по результатам МЕНЕДЖМЕНТА РИСКА;
- последовательность работ должна определяться с таким расчетом, чтобы гарантировать доступность не
обходимых входных данных перед началом каждой работы;
- должны определяться критерии для принятия решения об успешном завершении работы;
- финансовая отчетность должна быть упрощенной.
Эти работы определяют с помощью входных/выходных характеристик, поскольку они легко измеримы (если
они существуют). ИЗГОТОВИТЕЛЬ несет ответственность за принятие решений относительно достижения наме
ченных этапов и разработки требуемой документации.
Для определения успешности завершения каждой работы следует определить критерии ее ВЕРИФИКАЦИИ,
в процессе которой необходимо определить, были ли входные данные (характеристики) полностью, правильно и в
соответствии с требуемым ПРОЦЕССОМ преобразованы в выходные данные (характеристики). При этом никаких
требований к виду или объему ВЕРИФИКАЦИИ не предъявляется, за исключением ВЕРИФИКАЦИИ
показателей УПРАВЛЕНИЯ РИСКОМ и ОСНОВНЫХ ФУНКЦИОНАЛЬНЫХ ХАРАКТЕРИСТИК (см. 14.10).
Подпункт
14.5
— Решение проблем
Когда это целесообразно, настоящий стандарт требует задокументированной системы разрешения возника
ющих проблем.
Проблемы могут возникать:
- с программным продуктом (изделием);
259