Вы можете открыть актуальную версию документа прямо сейчас.
Если вы являетесь пользователем интернет-версии системы ГАРАНТ, вы можете открыть этот документ прямо сейчас или запросить по Горячей линии в системе.
Приложение В
(справочное)
Примеры определения классов риска
В.1 Введение
Данное приложение только иллюстрирует процесс определения классов риска для разных программных продуктов для сферы здравоохранения. В нем содержатся лишь примеры, поэтому его не следует использовать в качестве безусловного руководства по определению классов риска для таких продуктов.
В.2 Больничная система электронных предписаний с поддержкой принятия решений
При определении класса риска для больничных систем электронных предписаний с поддержкой принятия решений в первую очередь следует рассмотреть, какие последствия могут произойти в случае сбоя или неправильной работы системы или какие причины могут привести к непредусмотренному событию.
Непредусмотренным событием может быть назначение лекарства не тому человеку, не того лекарства, не той дозировки, а также, если указаны неверные периодичность, способ, время приема или применения, не предусмотрены взаимодействие лекарств, аллергическая реакция на лекарство.
Приведенные непредусмотренные события могли быть вызваны ошибкой в размещении десятичной запятой в выписанной дозе лекарства или назначением лекарства, вид или количество которого не годится для конкретного типа пациента, например для ребенка. Хотя многие из таких событий могут быть результатом неправильной работы системы, но более вероятно, что они произойдут из-за непреднамеренного ввода пользователем неверной информации по незнанию или при потере концентрации внимания. Подобные неблагоприятные события, однако, не могут быть просто списаны на ошибки пользователя, поскольку проектные решения подобных систем должны предусматривать выдачу соответствующих предупреждений при данных обстоятельствах. Возможность выдачи подобных потенциально опасных предписаний может, таким образом, быть вызвана как ошибкой или неадекватной реакцией системы поддержки принятия решений, так и просто ошибкой пользователя.
Разработчику недопустимо пренебрегать возможностью возникновения неблагоприятных событий, опираясь на убеждение, что его продукт так хорошо разработан, что подобные события не могут произойти. В недавнем исследовании [19] использовались 18 потенциально опасных сценариев для тестирования четырех хорошо обоснованных систем для врачей общей практики, применяемых 75% врачей общей практики в Великобритании. Системы были разработаны для выдачи предупреждений о взаимодействии лекарств. Однако ни одна из программ не выдала предупреждения для всех 18 сценариев: лучшая из них выдала семь предупреждений, а худшая - четыре. В случае назначения лекарств со сходными названиями ни одна из систем не выдала предупреждения для всех десяти тестовых пар лекарств. Производители всех систем, возможно, были уверены в том, что в их системах учтены все опасные обстоятельства, но оказалось, что это не так.
Следующим шагом является определение правдоподобия последствий неблагоприятных событий. В данном примере легко представить обстоятельства, при которых, в случае выдачи ошибочного назначения, последствия будут иметь форму летального исхода или недееспособности в течение длительного времени. Данные последствия относятся к категории "серьезных".
Следующим шагом является оценка правдоподобия возникновения последствий в форме летального исхода или недееспособности в "достаточно предсказуемых обстоятельствах". Подобные "достаточно предсказуемые обстоятельства" подразумевают рассмотрение цепочки событий, включающей передачу потенциально опасного предписания от дежурного врача к фармацевту, затем к ответственному за отпуск лекарств и, наконец, прием лекарства пациентом, после чего возникает реальное последствие. Поэтому оценка правдоподобия возникновения летального исхода или недееспособности включает разумную оценку того, будет ли ошибка в предписании замечена и скорректирована на какой-либо из стадий рассмотренной цепочки событий, а также того, можно ли, даже в случае приема пациентом выписанного лекарства, избежать летального исхода или недееспособности. Не допускается предполагать наличие наилучших или совершенных условий где-либо в данной цепочке событий. Например, нельзя предполагать, что все участники цепочки событий являются опытными высококвалифицированными врачами. С другой стороны, правдоподобие того, что в цепочке будут задействованы только полностью некомпетентные лица, может быть нереальным предположением. Однако именно требование того, что фактор, который при определении возможности может быть принят приемлемым, должен согласовываться с серьезностью рассматриваемого последствия, определяет, что критерий будет тем строже, чем серьезнее последствие. В данном примере возможное последствие является исключительно серьезным.
Из опыта известно, что при выдаче потенциально опасного предписания оно может привести и приводит к приему выписанного, результатом чего является летальный исход или недееспособность. Присвоенная категория правдоподобия, таким образом, определяется как "очень высокое" или "высокое". В соответствии с матрицей рисков комбинация "серьезной" категории последствия и "очень высокой" категории правдоподобия определяет принадлежность системы электронных предписаний с поддержкой принятия решений к классу А. Однако комбинация "серьезной" категории последствий и "высокой" категории правдоподобия определяет принадлежность к классу В. Решение об определении принадлежности к классу принимается в соответствии с требованием, что, "если имеется сомнение, к которой из двух категорий следует отнести правдоподобие последствия, оно должно быть отнесено к категории, соответствующей более высокому правдоподобию". Следовательно, данная система должна быть отнесена к классу А.
Проведения дальнейшего анализа (итераций) не требуется, поскольку анализ необходимо проводить "только до тех пор, пока в ходе итераций не будет обеспечена уверенность, что продукту присвоен наивысший из выявленных классов риска", а класса риска "выше", чем класс А, не существует.
Присвоение класса А системам электронных предписаний с поддержкой принятия решений оправданно, поскольку легко понять, что в случае плохой проработки подобных систем они могут нанести серьезный вред пациентам. Любые руководства, стандарты или нормативные документы, относящиеся к средствам контроля, применяемые при проектировании и производстве программных продуктов для сферы здравоохранения, должны быть наиболее строгими в отношении программных продуктов данного типа (относящихся к классу А) из-за их потенциальной возможности нанести серьезный вред, если на них не будет обращено особое внимание.
В.3 Система отслеживания истории болезни по штрих-коду
В данном примере рассмотрена система, производящая наклейку со штрих-кодом, который однозначно идентифицирует папку с историей болезни пациента, с тем чтобы при передаче истории болезни между отделениями больницы ее можно было отслеживать на входе и выходе из отделения посредством устройства считывания штрих-кода, чтобы идентифицировать ее текущее местоположение.
В первую очередь следует рассмотреть, какие последствия могут иметь место в случае, если система будет неправильно работать или вызовет непредвиденное событие.
Одним из случаев неправильной работы системы может быть невозможность прослеживать некоторое множество историй болезни, что приведет к невозможности определения их местоположения и недоступности для врача, когда они понадобятся. Последствие данного обстоятельства будет зависеть от клинической ситуации, имеющей место в тот момент, когда история болезни не может быть найдена.
Даже с учетом того, что врач средней квалификации может проявить осторожность и не предпримет действий до получения достаточной информации, подтвержденной каким-либо образом, последствия серьезной или значительной категории все равно могут иметь место, но правдоподобие их возникновения будет "очень низким". Это указывает на класс С.
Кому-то такое решение может показаться излишне строгим, поскольку на практике подобные последствия скорее будут относиться к категории существенных или незначительных последствий со средним или низким правдоподобием. Это бы указало на класс D или Е.
Потребуется дальнейший анализ, включая, возможно, исследование опубликованных источников, чтобы окончательно определиться с классом (С, D или Е), что представляется вполне обоснованным. Любые руководства, стандарты или нормативные документы, относящиеся к средствам контроля, применяемым при проектировании и производстве программных продуктов для сферы здравоохранения, относящихся к классам С, D или Е, вряд ли будут предъявлять к ним такие же серьезные требования, как к системе электронных предписаний с поддержкой принятия решений (относящейся к классу А).
В.4 Исследовательская система для болезней, передаваемых половым путем
В данном примере представлена система собственной разработки, предназначенная для хранения и анализа данных по заболеваниям, передаваемым половым путем. В системе хранятся личные данные пациентов.
В первую очередь следует рассмотреть, что может произойти в случае сбоя или неправильной работы системы.
Данная система не используется для непосредственного лечения пациентов, и потому для нее не рассматриваются события, вызывающие такие последствия, как смерть, серьезные или незначительные травмы. Однако проблемы с должной защитой конфиденциальных данных о пациенте могут иметь место, например, при недостаточном или отсутствующем контроле доступа либо недостаточно строгих требованиях к паролю. Таким образом, отождествление пациента с болезнью, передаваемой половым путем, например ВИЧ, может быть осуществлено неавторизованным лицом или лицами. Из-за психологической травмы, нанесенной в связи с этим пациенту, данное последствие будет относиться к категории "существенных".
Следующим шагом является рассмотрение правдоподобия реально возникающих последствий. Психологическая травма у пациента не возникнет, если пациент не узнает о том, что конфиденциальность информации о нем была нарушена. Это зависит от обстоятельств несанкционированного доступа. Если несанкционированный доступ был осуществлен врачом, который непреднамеренно просмотрел конфиденциальную информацию, то такой врач вряд ли будет передавать кому-либо данную информацию в силу своего долга сохранять врачебную тайну. Однако случайный или несанкционированный доступ к информации со стороны лица, не связанного врачебными обязательствами, может привести к бездумному или умышленному разглашению информации, особенно если данный пациент известен в местном сообществе. Тем не менее до момента, когда пациент узнает о данном инциденте, пройдет длинная цепочка событий, поэтому правдоподобие может быть оценено от среднего до низкого. В любом случае данная система относится к классу D.
Дополнительное рассмотрение следует произвести, если в системе ведется журнал регистрации событий, в котором был отмечен факт несанкционированного доступа. "Владелец" системы в подобных обстоятельствах может быть обязан уведомить пациента о том, что утечка информации имела место. Это означает, что правдоподобие последствия становится "очень высоким". Однако здраво предположить, что психологическая травма, наносимая пациенту, может быть уменьшена, если его информирует и консультирует опытный врач. Психологическая травма, таким образом, может быть оценена как "незначительная" вместо "существенная". В результате система может быть отнесена к классу С.
В соответствии с приведенными аргументами система может быть отнесена к классу С или D. Если имеются существенные сомнения, к какому классу отнести систему, то система должна быть отнесена к более высокому классу, т.е. к классу С.
Примечание - В отношении исследовательской системы, содержащей менее деликатные данные о здоровье, наихудшим последствием, которого можно ожидать, является незначительное психологическое расстройство (если таковое вообще будет иметь место) с низким или очень низким правдоподобием, т.е. такая система относится к классу Е.
Неудивительно, что система, хранящая персональные данные о здоровье весьма деликатного характера, например данные о болезнях, передаваемых половым путем, должна быть отнесена к относительно "высокому" классу. Следует ожидать, что любые руководства, стандарты и нормативные документы по средствам контроля, применяемым при разработке и производстве программных продуктов для сферы здравоохранения данного класса (класса С), будут достаточно строгими, сфокусированными (как в рассмотренном примере) на защите данных, безопасности и контроле доступа.
В.5 Диспетчерская система службы скорой помощи
Сфера оказания неотложной помощи неизбежно решает проблему "жизни и смерти", однако в реальности ситуация может складываться иначе. В то время как разработка передовых решений для диспетчерской службы скорой помощи (например, Лондонская служба скорой помощи середины 1990-х годов [24]) и в самом деле решает данную проблему, системы более раннего поколения (которые, например, не позволяют направлять бригады в зависимости от их специализации и/или машины, оборудованные специальной аппаратурой) являются скорее "поддерживающими", чем "исправляющими". Такая система и рассматривается в данном примере.
При рассмотрении реального наихудшего случая следует определить возможные ситуации, при которых после звонка в службу скорой помощи бригада не отправляется на вызов или отправляется не по тому адресу.
В случае летального исхода следует предположить, что состояние пациента было критическим и рядом с ним не было человека, который мог бы сделать вызов и отследить его выполнение. В ситуации, когда человек находится в одиночестве и испытывает обширный сердечный приступ, маловероятно, что он сможет вызвать врача. Если в результате исход будет летальным, то это не будет связано с диспетчерской системой. В случае крупной автомобильной аварии, ранения в бою, обрушения здания или другого значительного инцидента обычно присутствуют представители одной или нескольких служб экстренной медицинской помощи. Можно ожидать, что данные представители смогут точно определить характер травмы и отследить восприимчивость организма. В таких случаях также, если летальный исход произошел до прибытия скорой помощи на место происшествия или сразу после ее прибытия, это не относится к диспетчерской системе службы скорой помощи.
Поэтому для данного сценария последствие, вероятно, будет связано с отдельной личностью, получившей травму, или с группой травмированных людей, когда машина скорой помощи задерживается или не была направлена, что привело к ухудшению состояния и/или увеличению длительности восстановления по сравнению с обычно ожидаемой. Это может привести к длительной недееспособности и/или серьезной психологической травме пациента, что соответствует определению "существенного" последствия.
Рассмотрение правдоподобия наихудшего последствия должно быть комплексным. Неспособность направить машину скорой помощи, задержка отправки машины и отправка ее по неверному адресу (т.е. задержка отправки машины по правильному адресу) могут быть вызваны следующими причинами:
a) задержка вызова скорой помощи (не входит в сферу ответственности службы скорой помощи);
b) задержка ответа диспетчера на звонок (много различных причин, например, недостаточная емкость входящих линий);
c) ошибка или неточность диспетчера при вводе адреса и/или почтового индекса (из-за плохой слышимости или ошибки при печати);
d) направление на вызов недоступной бригады скорой помощи (бригада находится на вызове, отдыхает или по другой причине);
e) сообщение диспетчера не дошло до бригады скорой помощи (по причине, не связанной с самой диспетчерской системой).
Правдоподобие ситуации по перечислению b) оценивается как "очень низкое". Обычно телефонные компании предоставляют для служб экстренной медицинской помощи каналы с высокой пропускной способностью, что считается неотъемлемой составляющей обеспечения нормальной работы.
Если предположить, что система не опирается на знания в данной области или имеет дефекты, то правдоподобие ситуации по перечислению d) может быть оценено как "низкое", поскольку можно предположить, что бригада будет быстро сообщать, что она недоступна для направления на вызов.
Интерес представляет ситуация по перечислению с). Система может не иметь возможности проверки почтовых индексов и/или проверки соответствия адресов и почтовых индексов либо функционирование системы может быть нарушено или дать сбой. Почтовые индексы, несомненно, очень похожи один на другой, не имеют четкой логики и их слишком много, чтобы диспетчер мог запоминать их и соотносить с конкретным адресом. В данном случае правдоподобие данной ситуации оценивается как "высокое", но также может быть оценено и как "очень высокое".
Комбинация "существенного" последствия с "очень низким", "низким" и "высоким" правдоподобием позволяет отнести систему к классам риска D, С и В соответственно. Даже при "очень высоком" правдоподобии последствия система относится к классу риска В, соответствующему реальному наихудшему случаю.
Поэтому практически риски отказа, объединенные в ситуации по перечислению с), должны быть разделены и рассмотрены по отдельности, даже если ни один из них не может повысить степень риска выше класса В. В свете оценки правдоподобия как "высокого" и "очень высокого" следует сконцентрироваться на оценке последствия, чтобы убедиться, что не существует "серьезных" или "катастрофических" сценариев. Если же такие сценарии существуют, то систему следует отнести к классу риска А.
Если вы являетесь пользователем интернет-версии системы ГАРАНТ, вы можете открыть этот документ прямо сейчас или запросить по Горячей линии в системе.