Приложение С (справочное). Иллюстрация сути взаимосвязи между классами риска и потенциальными средствами контроля для управления рисками

Приложение С
(справочное)

Иллюстрация сути взаимосвязи между классами риска и потенциальными средствами контроля для управления рисками

С.1 Использование классов риска

Целью отнесения программных продуктов к классам риска в соответствии с настоящим стандартом является, в основном, обеспечение четкого различия между:

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

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

- программными продуктами, находящимися между этими двумя крайностями.

Программные продукты, отнесенные к высокому классу риска (например, к классу А), очевидно, требуют особого внимания для обеспечения того, чтобы представляемые ими риски для пациентов не материализовались.

Минимизация вероятности материализации рисков может быть достигнута несколькими неисключительными путями, например следующими:

- контроль при проектировании, производстве, сопровождении и обновлении программного продукта (включая инструкции по применению) для обеспечения, насколько целесообразно, того, что неблагоприятные события, которые могут привести к вредным последствиям, не возникнут на практике;

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

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

Лица, ответственные за анализ и снижение рисков в сфере здравоохранения, заинтересованы в идентификации тех программных продуктов, на которые им следует обратить внимание при принятии решения о покупке, внедрении и использовании, а также при анализе способов эксплуатации. Они не обязаны проявлять такое же внимание или применять столь же строгие средства контроля к программным продуктам, относящимся к классам D или Е, как и к продуктам классов А и В.

Лица, ответственные за разработку руководств, стандартов или нормативных документов по средствам контроля, необходимым при проектировании и производстве программных продуктов для сферы здравоохранения, заинтересованы в проведении различия между типами продуктов, которые без адекватных средств контроля могут представлять наибольшие риски, и типами продуктов, которые представляют меньшие риски. Для продуктов класса А требуются наиболее жесткие средства контроля, применяемые с наибольшей строгостью, а для продуктов класса Е - наименее строгие (может быть, и не требуются вовсе).

Инспекторы и разработчики стандартов могут посчитать, что деление программных продуктов на пять классов является излишней градацией, и могут объединить некоторые из них в целях применения укрупненных требований к контролю. Таким образом, для целей определения необходимых средств контроля инспекторы могут принять решение не делать различия между классами А и В или между классами С и D.

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

С.2 Основные положения

Классификация рисков, основанная на процессе оценки (сформированная из оценки возможного воздействия на пациента или нанесения вреда пациенту и вероятности его реализации), обеспечит обоснование для средств контроля, рекомендованных для обеспечения безопасности продукта. Данное обоснование будет относиться как к объему, так и к строгости контроля, поэтому потребуется иерархическая многоуровневая библиотека средств контроля.

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

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

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

С.3 Примеры контролируемых факторов

В процессе ведения и интерпретации установленной "классификации рисков" может потребоваться рассмотрение следующих факторов, контролируемых соответствующими средствами:

- действия по дополнительной классификации рисков;

- действия по оценке рисков, связанных с безопасностью;

- программное управление;

- программное управление рисками;

- средства проектирования;

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

- квалификация и опыт проектировщиков системы;

- правила отображения и представления информации;

- целостность проекта;

- гарантия правильности/аттестация проекта;

- средства разработки системы;

- управление разработкой системы;

- квалификация и опыт разработчиков системы;

- средства контроля целостности;

- тестирование/техническая гарантия защиты системы от проникновения;

- средства разработки базы знаний;

- управление проектированием базы знаний;

- управление разработкой базы знаний;

- гарантия правильности/аттестация базы знаний;

- разработка политики безопасности;

- требования к устойчивости и резервированию;

- идентификация и аутентификация;

- контроль доступа пользователей;

- повторное использование объектов;

- требования к хранению/планирование объема памяти;

- требования к резервному копированию;

- бухгалтерский учет и аудит;

- защита от сбоев оборудования;

- контроль происшествий;

- контроль непрерывности бизнес-процессов;

- разработка тестирования систем;

- формальная оценка разработанных систем;

- разработка процедур эксплуатации;

- разработка процедур сопровождения;

- разработка процедур пользователя;

- обучение персонала;

- руководство администрированием.

Данный перечень не является окончательным и потребует дальнейшего анализа и проработки, прежде чем он сможет быть принят в каком-либо из руководств или стандартов. Степень востребованности перечисленных контролируемых факторов и строгость, с которой они должны контролироваться, будут зависеть от класса риска.