Национальный стандарт РФ ГОСТ Р ИСО/ТС 25238-2009 "Информатизация здоровья. Классификация угроз безопасности от медицинского программного обеспечения" (утв. приказом Федерального агентства по техническому регулированию и метрологии от 14 сентября 2009 г. N 404-ст)

Health informatics. Classification of safety risks from health software (IDT)

Дата введения - 1 июля 2010 г.

Введен впервые

Предисловие

Цели и принципы стандартизации в Российской Федерации установлены Федеральным законом от 27 декабря 2002 г. N 184-ФЗ "О техническом регулировании", а правила применения национальных стандартов Российской Федерации - ГОСТ Р 1.0-2004 "Стандартизация в Российской Федерации. Основные положения"

Введение

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

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

Во всем мире отмечается растущее беспокойство по поводу большого числа предотвратимых клинических несчастных случаев, оказывающих негативное воздействие на пациентов, из которых значительная часть приводит к летальному исходу или недееспособности [1]-[6]. К таким предотвратимым клиническим несчастным случаям относятся, например, неправильный или неполный диагноз или другие неправильно принятые решения. Способствующим этому фактором часто является отсутствие или неполнота информации, а иногда просто незнание, например, медицинских возможностей в сложных случаях или взаимного влияния применяемых лечебных средств.

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

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

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

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

- плохая доказательная база для разработки;

- ошибки в проектной логике, не позволяющие правильно реализовывать поставленные цели;

- ошибки в логике при представлении успешного опыта или доказательств на стадии проектирования;

- плохое или запутывающее представление информации или плохие средства поиска информации;

- невозможность обновления информации в соответствии с текущим уровнем знаний.

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

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

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

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

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

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

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

Безопасность лекарственных препаратов и медицинских приборов во многих странах обеспечивается множеством юридических и административных мер. Например, в Европейском союзе безопасность является предметом ряда директив ЕС [7]-[9]. Подобные меры зачастую подкрепляются стандартами, связанными с обеспечением безопасности, как национальными, так и международными, включая стандарты Международной организации по стандартизации (ИСО), Международного электротехнического комитета (МЭК) и Европейского комитета по стандартизации (CEN). Программное обеспечение, необходимое для правильного применения или функционирования медицинских приборов, зачастую охватывается данными нормативными документами. Однако другие виды программного обеспечения, используемого в здравоохранении, обычно не регламентируются подобным образом. Настоящий стандарт относится к программному обеспечению, применяемому в медицине, за исключением программного обеспечения, необходимого для правильного применения или функционирования медицинских приборов.

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

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

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

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

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

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

Требования настоящего стандарта не распространяются на любое программное обеспечение, необходимое для правильного применения или функционирования медицинских приборов.

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

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

В настоящем стандарте применены следующие термины с соответствующими определениями:

2.1 вред (harm): Смерть, физическая травма и/или повреждение здоровья или самочувствия пациента.

2.2 опасность (hazard): Потенциальный источник нанесения вреда [10].

2.3 программный продукт для сферы здравоохранения (health software product): Программное обеспечение, предназначенное для использования в сфере здравоохранения в целях охраны здоровья, за исключением программного обеспечения, которое необходимо для правильного применения медицинского прибора.

2.4 производитель (manufacturer): Физическое или юридическое лицо, отвечающее за разработку, производство, упаковку или маркировку программного продукта для сферы здравоохранения, компоновку системы или адаптацию программного продукта до того, как он будет представлен на рынке и/или введен в эксплуатацию, независимо от того, выполняются ли эти действия самим лицом или третьей стороной по его поручению.

Примечание - Заимствовано из [11].

2.5 пациент (patient): Любое лицо, к которому применяется или которое использует программный продукт для сферы здравоохранения.

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

2.6 продукт (product): Вся совокупность материалов и услуг, относящихся к программному обеспечению, предлагаемому пользователю, включая инструкции по применению и, в случае необходимости, обучение.

2.7 риск (risk): Комбинация правдоподобия нанесения вреда и серьезности этого вреда (см. раздел 4).

Примечание - Заимствовано из [10].

2.8 анализ рисков (risk analysis): Систематическое использование доступной информации для идентификации опасностей и оценки рисков.

2.9 класс риска (risk class): Классификация программного продукта для сферы здравоохранения в соответствии с риском, который он может представлять для безопасности пациентов.

2.10 безопасность (safety): Независимость от недопустимого риска нанесения вреда [10].

2.11 допустимый риск (tolerable risk): Риск, приемлемый в данном контексте с учетом существующей системы ценностей в обществе [12].

3 Принципы анализа опасностей и рисков

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

Необходимой предпосылкой данного процесса является выполнение анализа опасностей и рисков.

Существуют разнообразные подходы к анализу опасностей и рисков. Все они используют ряд базовых понятий. Существующие стандарты, руководства и публикации имеют тенденцию к концентрации на конкретных областях деятельности (например, электронные системы безопасности, аэронавтика) или на предметных областях (например, финансовые риски, риски относительно собственности, риски безопасности личных данных). В этой связи их следует интерпретировать в контексте программных продуктов для сферы здравоохранения. Настоящий стандарт основан на ряде источников, что обеспечивает его соответствие общепринятым положениям. В разделе "Библиография" приведен список полезных источников информации по данной теме. При рассмотрении данного подхода применительно к программным продуктам для сферы здравоохранения учитывались классификация и контроль медицинских приборов с точки зрения безопасности (см. приложение А).

Ниже приведены основные понятия для целей настоящего стандарта. Данный раздел не предназначен для рассмотрения всех аспектов анализа опасностей и рисков.

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

Примечания

1 В [10] риск определен как "комбинация вероятности события и его последствий", тогда как в настоящем стандарте риск определен как "комбинация правдоподобия нанесения вреда и серьезности этого вреда" (см. 2.7). Вероятность возникновения опасности может быть выражена в некоторых областях количественно как вероятность, основанная на ретроспективном или экспериментальном анализе сбоев и статистике инцидентов. Весьма маловероятно, что такой подход может быть применен к безопасности программных продуктов для сферы здравоохранения, где статистика и данные отсутствуют и потому требуется качественная оценка. Поскольку вероятность, несомненно, может быть выражена количественно, предпочтительнее использовать термин "правдоподобие", который точнее отражает смысл и поэтому использован в настоящем стандарте.

2 В [14] риск определен как "комбинация вероятности события и его последствия". Данное определение имеет тот же недостаток, отмеченный в примечании 1, в отношении использования термина "вероятность" вместо "правдоподобие". Более того, настоящий стандарт относится только к событиям, которые, возможно, могут нанести вред пациентам, позволяет оценить серьезность этого вреда, и не касается иных событий. Поэтому термин "событие" не используется.

Последствие, т.е. вред, нанесенный пациенту, может принимать разные формы, начиная от незначительного беспокойства и до летального исхода. Последствия могут быть классифицированы по категориям. Такие категории подлежат интерпретации в соответствии с областью применения, в данном случае - применения ИКТ в здравоохранении. Настоящий стандарт определяет 5 категорий "последствий" и области их применения (см. 4.2).

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

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

Таблица 1

Правдоподобие	Последствие
	наихудшее				наименьшее
Наивысшее	1	2
	3
					4
Наименьшее				5	6

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

Данные уровни риска могут быть сгруппированы в классы следующим образом:

- класс наивысшего риска образует группа ячеек, расположенная в левой верхней части матрицы, такие как 1, 2 и 3;

- класс наименьшего риска образует группа ячеек, расположенная в правой нижней части таблицы, такие как 4, 5 и 6.

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

В настоящем стандарте определены пять классов риска (см. 4.4).

4 Определение класса риска программного продукта для сферы здравоохранения

4.1 Введение

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

4.2 Определение категорий последствий

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

- катастрофические;

- серьезные;

- значительные;

- существенные;

- незначительные.

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

Категории последствий должны интерпретироваться в соответствии с таблицей 2. Описания категорий последствий были разработаны для целей настоящего стандарта, но согласованными с принятыми в других областях и дополнительных дисциплинах и подходах (см. [15]-[17]).

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

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

Таблица 2

Категории последствий	Интерпретация
	Последствие	Количество случаев
Катастрофические	Летальный исход	Множество
	Устойчивая недееспособность и любое состояние, при котором прогнозируется летальный исход или устойчивая недееспособность; серьезная травма или недееспособность, последствия которой не будут преодолены в ближайшее время	Множество
Серьезные	Летальный исход	Единичные
	Устойчивая недееспособность и любое состояние, при котором прогнозируется летальный исход или устойчивая недееспособность; серьезная травма или недееспособность, последствия которой не будут преодолены в ближайшее время	Единичные
	Серьезная травма или недееспособность, восстановление после которой ожидается в ближайшее время	Множество
	Серьезная психологическая травма	Множество
Значительные	Серьезная травма или недееспособность, восстановление после которой ожидается в ближайшее время	Единичные
	Серьезная психологическая травма	Единичные
	Незначительная травма или травмы, восстановление после которых не ожидается в ближайшее время	Множество
	Существенная психологическая травма	Множество
Существенные	Незначительная травма или травмы, восстановление после которых не ожидается в ближайшее время	Единичные
	Существенная психологическая травма	Единичные
	Незначительная травма, восстановление после которой ожидается в ближайшее время	Множество
	Незначительное психологическое расстройство; беспокойство	Множество
Незначительные	Незначительная травма, восстановление после которой ожидается в ближайшее время; незначительное психологическое расстройство; беспокойство; любые несущественные последствия	Единичные

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

4.3 Определение правдоподобия последствий

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

Примечание - Как указано в 4.2, нет необходимости идентифицировать все возможные последствия. Анализ возможных последствий и определение правдоподобия их возникновения следует выполнять только в той степени, которая необходима для уверенного отнесения программного продукта к классу риска посредством итерационного процесса, описанного в 4.6.

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

- очень высокое;

- высокое;

- среднее;

- низкое;

- очень низкое.

Категории правдоподобия должны интерпретироваться в соответствии с таблицей 3. Описания категорий правдоподобия были разработаны для целей настоящего стандарта, однако они соответствуют категориям в других областях, например в области корпоративного управления в здравоохранении (см. [18]).

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

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

Таблица 3

Категории правдоподобия	Описание
Очень высокое	Обязательно или почти обязательно; очень вероятно, что событие произойдет
Высокое	Не обязательно, но весьма возможно; ожидается, что событие произойдет в большинстве случаев
Среднее	Возможно; есть вероятность, что событие произойдет
Низкое	Событие может произойти, но в большинстве случаев не произойдет
Очень низкое	Незначительная или практически незначительная вероятность события

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

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

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

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

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

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

4.4 Классы риска

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

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

Комбинации, соответствующие классам риска, приведены в таблице 4.

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

Таблица 4

Правдоподобие	Последствия
	катастрофические	серьезные	значительные	существенные	незначительные
Очень высокое	А	А	В	В	С
Высокое	А	В	В	С	С
Среднее	В	В	С	D	D
Низкое	В	С	D	D	Е
Очень низкое	С	С	D	Е	Е

4.5 Определение класса риска программного продукта для сферы здравоохранения

Комбинации последствий и их правдоподобия должны быть размещены в матрице рисков, описанной в 4.4 (см. таблицу 4), с использованием итерационного процесса, описанного в 4.6. Программному продукту для сферы здравоохранения присваивается наивысший из идентифицированных для него классов риска, при этом класс А соответствует наибольшему риску, а класс Е - наименьшему.

4.6 Итерационный процесс

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

5 Аналитический процесс

5.1 Введение

В данном разделе представлены некоторые из процессов, которые должны быть рассмотрены при анализе в целях определения класса риска.

5.2 Привлечение заинтересованных сторон

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

- специалисты, участвующие в проектировании, разработке и эксплуатации систем;

- пользователи;

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

Также может быть полезным включение в данную группу представителей юристов и экспертов по управлению.

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

5.3 Понимание среды системы и пользователя

Первым шагом в работе сформированной группы является достижение общего понимания по следующим вопросам:

- назначение системы;

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

- характеристики и режимы работы системы;

- человеко-машинный интерфейс;

- динамика процессов, с которыми система будет взаимодействовать и на которые она будет влиять.

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

5.4 Анализ последствий

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

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

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

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

- человеческий фактор (случайные или умышленные действия или бездействия);

- физические сбои;

- логические сбои;

- коммуникационные сбои;

- сбои аппаратных средств;

- сбои программного обеспечения;

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

- собирать информацию о реальных инцидентах, связанных с системой, и делать из этого выводы;

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

- обеспечивать привлечение всех заинтересованных сторон;

- поощрять инновационное мышление;

- выявлять любое скрытое или возможное воздействие, не только приводящее к немедленным последствиям;

- быть творческой, оставаясь реалистичной;

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

5.5 Анализ правдоподобия последствий

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

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

- сфокусироваться в первую очередь на наихудших неблагоприятных событиях и последствиях;

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

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

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

- принимать во внимание при рассмотрении человеческого фактора следующие обстоятельства:

- мотивацию;

- рабочие нагрузки и возможности;

- компетентность;

- стимулы и препятствия;

- рабочую среду;

- выявить обстоятельства, которые могут повысить правдоподобие последствия;

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

- принимать во внимание сложность решений или процессов;

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

- принимать во внимание взаимозависимость событий в цепочке;

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

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

5.6 Итерации

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

5.7 Пересмотры

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

- при введении новых или изменении существующих функций;

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

- при введении новых или изменении существующих интерфейсов с другими системами.

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

5.8 Документация

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

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

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

- итерационный процесс и логика, которые привели к уверенному определению класса риска.

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

5.9 Библиотека инцидентов

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

6 Примеры определения классов риска для программных продуктов

Примеры определения класса риска для разных типов программных продуктов для сферы здравоохранения приведены в приложении В.

7 Взаимосвязь классов риска с проектированием и контролем производства программных продуктов

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

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

[1]	Kohn, I.T., Corrigan, J.M. and Donaldson, M.S., To Err is Human: Building a Safer Health System, USA Institute of Medicine, National Academy Press, 1999
[2]	An Organization with a Memory, HMSO, June 2000
[3]	Quality in Australian Healthcare, Study, 1994
[4]	Brennan, T.A., Leape, 1.1., Laird, N.M., Herbert, I., Localio, A.R. and Lawthers, A.G., Incidents of adverse events and negligence in hospitalised patients: results of the Harvard Medical Practice Study, New England J Med., 324,1991, pp. 370-376
[5]	Quality of care: patient safety, Report of the WHO Secretariat, EB 109/9, 5 December 2001
[6]	Building a safer NHS for Patients, UK Department of Health, April 2001
[7]	Council Directive 90/385/EEC of 20 June 1990 on the approximation of the laws of the Member States relating to active implantable medical devices
[8]	Council Directive 93/42/EEC of 14 June 1993 concerning medical devices
[9]	Council Directive 98/79/EC of the European Parliament and of the Council of 27 October 1998 on in-vitro diagnostic medical devices
[10]	ISO/IEC Guide 51:1999, Safety aspects - Guidelines for their inclusion in standards
[11]	ISO 14971, Medical devices - Application of risk management to medical devices
[12]	IEC 61508-4:1998, Functional safety of electrical/electronic/programmable electronic safety-related systems - Part 4: Definitions and abbreviations
[13]	IEC 61508 (all parts), Functional safety of electrical/electronic/programmable electronic safety-related systems
[14]	ISO/IEC Guide 73:2002, Risk management - Vocabulary - Guidelines for use in standards
[15]	UK Government Information Security, Risk Analysis and Management Method (CRAMM) User Manual, CCTA, (now part of the Office of Government on Commerce) Publisher Central Computer Telecommunications Agency
[16]	ISO/IEC 17799:2005, Information technology - Security techniques - Code of practice for information security management
[17]	AS/NZS 4360:1999, Risk Management
[18]	Corporate governance in health care Qualitative Measures of Likelihood of Risk, Department of Health, England
[19]	Fernando, В., Savelych, В., Avery, A., Bainbridge, M., Horsfield, P and Teasdale, S., Prescribing safety features of general practice computer systems: evaluation using simulated test cases, BMJ, May 2004, 328, pp. 1171-1172
[20]	Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices, 11 May 2005, Center for Devices and Radiological Health, Food and Drug Administration, US Department of Health and Services
[21]	Off-The-Shelf Software Use in Medical Devices, Guidance, 9 September 1999, Center for Devices and Radiological Health, Food and Drug Administration, US Department of Health and Services
[22]	IEC 60601-1-4, Medical electrical equipment - Part 1-4: General requirements for safety - Collateral Standard: Programmable electrical medical systems
[23]	EN 1441, Medical devices - Risk analysis
[24]	LASCAD Case Study available at: http://www.cems.uwe.ac.uk/teaching/notes/UQI101S2/lascad.htm