ГОСТ Р ИСО/ТС 25238—2009
Приложение С
(справочное)
Иллюстрация сути взаимосвязи между классами риска и потенциальными средствами
контроля для управления рисками
С.1 Использование классов риска
Целью отнесения программных продуктов кклассам риска в соответствии с настоящим стандартом является,
в основном, обеспечение четкого различия между:
- программными продуктами, которые могут представлять серьезный риск для пациентов в случае непра
вильного функционирования;
- программными продуктами, не представляющими серьезного риска для пациентов в случае неправильного
функционирования;
- программными продуктами, находящимися между этими двумя крайностями.
Программные продукты, отнесенные к высокому классу риска (например, к классу А), очевидно, требуют осо
бого внимания для обеспечения того, чтобы представляемые ими риски для пациентов не материализовались.
Минимизация вероятности материализации рисков может быть достигнута несколькими неисключительными
путями, например следующими:
-контроль при проектировании, производстве, сопровождении и обновлении программного продукта (вклю
чая инструкции по применению) для обеспечения, насколько целесообразно, того, что неблагоприятные события,
которые могут привести к вредным последствиям, не возникнут на практике;
- обучение и переобучение пользователей для обеспечения их знания о возможных рисках и неблагоприят
ных событиях в целях предотвращения последствий, к которым могут привести данные события;
- активные административные средства контроля и проверки в рамках окружающей среды, в которой функци
онирует или с которой взаимодействует система, в целях выявления неблагоприятных событий и предотвращения
или уменьшения их последствий.
Лица, ответственные за анализ и снижение рисков в сфере здравоохранения, заинтересованы в идентифика
ции тех программных продуктов, на которые им следует обратить внимание при принятии решения о покупке, внед
рении и использовании, а также при анализе способов эксплуатации. Они не обязаны проявлять такое же внимание
или применять столь же строгие средства контроля к программным продуктам, относящимся к классам D или Е.
как и к продуктам классов А и В.
Лица, ответственные за разработку руководств, стандартов или нормативных документов по средствам кон
троля. необходимым при проектировании и производстве программных продуктов для сферы здравоохранения, за
интересованы в проведении различия между типами продуктов, которые без адекватных средств контроля могут
представлять наибольшие риски, и типами продуктов, которые представляют меньшие риски. Для продуктов клас са
А требуются наиболее жесткие средства контроля, применяемые с наибольшей строгостью, а для продуктов
класса Е — наименее строгие (может быть, и не требуются вовсе).
Инспекторы и разработчики стандартов могут посчитать, что деление программных продуктов на пять клас
сов является излишней градацией, и могут объединить некоторые из них в целях применения укрупненных требо
ваний к контролю. Таким образом, для целей определения необходимых средств контроля инспекторы могут
принять решение не делать различия между классами А и В или между классами С и D.
Целью настоящего стандарта не является определение средств контроля, необходимых для предотвраще
ния или снижения последствий для пациентов, в соответствии с классом риска программного продукта. Однако оче
видно. что для продуктов, относящихся к более высокому классу риска, необходим намного более подробный и
строгий анализ при определении мероприятийдля снижения риска, чем анализ, проводимый при их «сортировке»
в
целях отнесения к одному из классов риска в соответствии с настоящим стандартом.
С.2 Основные положения
Классификация рисков, основанная на процессе оценки (сформированная из оценки возможного воздей
ствия на пациента или нанесения вреда пациенту и вероятности его реализации), обеспечит обоснование для
средств контроля, рекомендованных для обеспечения безопасности продукта. Данное обоснование будет отно
ситься как к объему, таки к строгости контроля, поэтому потребуется иерархическая многоуровневая библиотека
средств контроля.
Процесс классификации рисков не затрагивает такие вопросы, кактехническая архитектура, или такие факто
ры. как зависимость. Поэтому классификация рисков не обеспечивает обоснования применимости. Поскольку дан
ный вопрос должен быть рассмотрен в дальнейшем в руководствах или стандартах по средствам контроля, то
отсюда следует, что потребители процесса классификации рисков должны будут сделать такие оценки вручную
эм пирическим путем.
18