Тема 1.6 — Клиническая безопасность и управление рисками

Одним предложением: Клиническая безопасность — это дисциплинированная, подкреплённая доказательствами практика выявления способов, которыми ваша цифровая технология может навредить пациенту, и контроля этих опасностей до того, как они коснутся кого-либо: безопасность, заложенная с первого наброска, а не навешенная перед запуском.

Почему это важно в здравоохранении и уходе#

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

Ставки асимметричны и часто невидимы. Когда цифровая система работает, никто не видит вреда, который она предотвратила; когда отказывает, вред может быть катастрофическим, отсроченным и распределённым по тысячам пациентов до того, как кто-либо заметит закономерность. Эта комбинация (тяжёлые последствия, малая видимость, широкий радиус поражения) означает, что нельзя полагаться на то, что пользователи поймают проблемы или что инциденты научат всему. Нужно рассуждать о вреде проактивно, до внедрения, и продолжать рассуждать, пока система работает. В Соединённом Королевстве это проактивное рассуждение не опционально: от организаций NHS и их поставщиков договорно и профессионально ожидается применение национальных стандартов управления клиническими рисками и способность показать ход своей работы. Правильное выполнение неотделимо от доказательств (см. тему 1.3 — Решения на основе доказательств), от управления информацией и кибербезопасности (см. тему 1.7 — Управление информацией, защита данных и кибербезопасность) и от того, как вы эксплуатируете услуги после запуска (см. тему 3.8 — Управление услугами и эксплуатация).

Ключевые понятия#

Безопасность пациентов и управление рисками. Безопасность пациентов — это предотвращение, снижение, регистрация и анализ вреда пациентам от ухода. Управление клиническими рисками применяет общую дисциплину управления рисками (выявление, оценка, приоритизация и контроль рисков) к конкретному вопросу о том, как система медицинских ИТ может способствовать вреду пациентам. Два национальных стандарта, управляющих этим в Англии, — DCB0129 и DCB0160 (DCB означает Data Coordination Board; это стандарты Standardisation Committee for Care Information / SCCI, обязательные в соответствии с Health and Social Care Act 2012). DCB0129 налагает обязательства на производителя или поставщика системы медицинских ИТ; DCB0160 налагает обязательства на организацию здравоохранения, внедряющую и использующую её. Они взаимодополняющи: чистое обоснование безопасности поставщика не снимает с внедряющего траста обязанность оценить опасности, привносимые его собственной конфигурацией, рабочим процессом и контекстом.

Специалист по клинической безопасности (CSO). Оба стандарта требуют назначенного, должным образом квалифицированного и опытного специалиста по клинической безопасности (Clinical Safety Officer): зарегистрированного, действующего клинициста, прошедшего признанное обучение клинической безопасности, который владеет деятельностью по управлению клиническими рисками и лично утверждает обоснование безопасности. Роль CSO — требование компетентности, а не должность, которую можно назначить тому, кто свободен. CSO подтверждает, что опасности выявлены и контролируются до приемлемого уровня; это профессиональное суждение, несущее профессиональную ответственность.

Артефакты управления клиническими рисками. Три документа составляют основу дисциплины. Файл управления клиническими рисками — контейнер для всех доказательств безопасности системы. Журнал опасностей (hazard log) — живой реестр каждой выявленной опасности, её причин, последствий, оценки риска, мер контроля и остаточного риска. Клиническое обоснование безопасности (safety case) — структурированная аргументация, подкреплённая доказательствами, что система приемлемо безопасна для предполагаемого использования в предполагаемом контексте, сопровождаемая отчётом об обосновании безопасности, резюмирующим аргументацию для утверждения. Это не бумажная работа ради неё самой; так рассуждение о безопасности делается явным, проверяемым и долговечным.

Анализ опасностей: выявление, анализ, оценка, контроль. Основной цикл: выявление опасностей (систематическое воображение того, как система может способствовать вреду: через семинары, клинические проходы, анализ видов отказов), анализ риска (оценка тяжести вреда и вероятности его наступления), оценка риска (сравнение оценённого риска с критериями приемлемости) и контроль риска (введение мер: изменений проекта, оповещений, обучения, процедур, чтобы снизить неприемлемый риск, затем повторная оценка остаточного риска). Риск снижается настолько, насколько это разумно практически достижимо (ALARP): вы продолжаете контролировать, пока дальнейшее снижение не стало бы грубо несоразмерным получаемой пользе.

Регулирование медицинских изделий, MHRA и программное обеспечение как медицинское изделие (SaMD). Некоторые цифровые медицинские технологии являются регулируемыми медицинскими изделиями. Программное обеспечение с медицинской целью (диагностика, профилактика, мониторинг, прогнозирование, лечение) само может быть медицинским изделием: Software as a Medical Device (SaMD). В Великобритании Medicines and Healthcare products Regulatory Agency (MHRA) регулирует медицинские изделия, включая SaMD, а стандарт жизненного цикла ПО IEC 62304 определяет, как такое ПО должно разрабатываться. Решение о том, является ли ваша технология регулируемым изделием, — пороговый вопрос с большими последствиями, отдельный от управления клиническими рисками по DCB0129/0160, хотя и стоящий рядом с ним.

Digital Technology Assessment Criteria (DTAC). DTAC — национальная базовая линия, которую организации NHS и социального ухода используют для оценки цифровых продуктов до закупки; она охватывает клиническую безопасность (доказательства соответствия DCB0129), защиту данных, техническую безопасность, интероперабельность и удобство использования. Она не заменяет управление клиническими рисками; она проверяет, что поставщик это сделал.

Человеческие факторы и культура безопасности. Человеческие факторы (эргономика) — научное изучение того, как люди взаимодействуют с системами в реальных условиях: усталость, прерывания, когнитивная нагрузка, усталость от тревог. Большая часть цифрового вреда возникает не от «неправильного» кода, а от проектов, которые делают безопасное действие трудным, а небезопасное лёгким. Культура безопасности — организационная приверженность выявлению рисков, сообщению о них и обучению на них без обвинений: разница между командой, скрывающей почти-происшествия, и командой, извлекающей из них улучшения.

Регистрация инцидентов и обучение. В Англии Learn from Patient Safety Events (LFPSE) — национальная служба регистрации событий безопасности пациентов, а Patient Safety Incident Response Framework (PSIRF) определяет, как организации NHS реагируют на инциденты и учатся на них, делая упор на соразмерный, системный анализ первопричин, а не на обвинения. Действующие системы порождают новые опасности, поэтому клиническая безопасность продолжается после запуска через обратную связь от инцидентов в журнал опасностей.

Лучшие практики#

1. Назначьте компетентного специалиста по клинической безопасности и дайте ему реальные полномочия. Назовите зарегистрированного действующего клинициста с признанным обучением клинической безопасности CSO для каждой системы в охвате и обеспечьте, чтобы его согласование было настоящими воротами, а не формальной печатью за день до запуска. CSO должен иметь возможность сказать «ещё нет» и быть услышанным, что означает защиту его времени, независимости и положения перед советом программы. CSO, которого перевешивает давление поставки, — фикция управления.

2. Выявляйте опасности рано, с клиницистами в комнате. Начинайте семинары по опасностям на исследовании и проектировании, а не перед запуском, потому что самые дешёвые и эффективные контроли — изменения проекта, сделанные до того, как что-либо построено (см. тему 3.5 — Жизненные циклы поставки). Привлекайте клиницистов переднего края, а не только аналитиков, потому что они знают, как работа происходит на самом деле: прерывания, обходные пути, то, как читается экран в 3 часа ночи. Проходите реалистичные клинические сценарии и спрашивайте неутомимо: «как эта система может способствовать вреду пациенту?»

3. Ведите живой журнал опасностей, а не документ дня запуска. Относитесь к журналу опасностей как к постоянному реестру, который открывается на исследовании и никогда не закрывается, пока система работает. Каждая опасность фиксирует причины, потенциальный вред, начальную оценку риска, применённые контроли и остаточный риск после контролей. Когда инцидент, изменение или почти-происшествие выявляет новую опасность, она входит в журнал и проходит тот же цикл; журнал — память вашего рассуждения о безопасности.

4. Пусть внедряющая организация владеет DCB0160, даже при соответствующем поставщике. Обоснование безопасности поставщика по DCB0129 покрывает продукт как произведённый; оно не может покрыть то, как вы его конфигурируете, какие рабочие процессы выстраиваете вокруг него и какие ваши группы населения им пользуются. Проводите собственную оценку DCB0160 местных опасностей (интеграция с другими системами, качество ваших данных, ваши клинические маршруты) и ведите собственный журнал опасностей. Предположение, что гарантии поставщика покрывают ваш контекст, — распространённый и опасный обходной путь.

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

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

7. Определяйте свой регуляторный статус осознанно. Спросите рано, соответствует ли ваше ПО определению медицинского изделия или SaMD, и если да, подключайте требования MHRA и IEC 62304 с самого начала, а не обнаруживайте обязательство поздно. Неверная классификация дорога в обе стороны: незарегистрированное изделие — юридический сбой и сбой безопасности, а избыточная классификация простого инструмента тратит дефицитную мощность гарантий. При сомнении запросите регуляторную консультацию и задокументируйте обоснование.

8. Используйте DTAC как нижнюю планку, а не финишную черту. Считайте Digital Technology Assessment Criteria минимальной входной проверкой любого закупаемого цифрового продукта, подтверждающей, что клиническая безопасность, защита данных, безопасность, интероперабельность и удобство использования учтены. Прохождение DTAC означает, что поставщик проделал работу; оно не означает, что продукт безопасен в вашем контексте, поэтому сочетайте его с собственной оценкой DCB0160 и живым мониторингом.

9. Замыкайте цикл от действующих инцидентов в журнал опасностей. Подключите регистрацию инцидентов (представления LFPSE, расследования PSIRF, местные отчёты о почти-происшествиях) обратно к управлению клиническими рисками, чтобы реальный вред и почти-происшествия обновляли ваши опасности и контроли. Обоснование безопасности, к которому не возвращаются после запуска, гниёт, потому что действующие системы, интеграции и клиническая практика дрейфуют (см. тему 3.8 — Управление услугами и эксплуатация). Обучение системное и учитывающее отсутствие обвинений, а не поиск того, кого наказать.

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

Вопросы для обсуждения с командой#

1. Где в нашем нынешнем портфеле мы полагаемся на гарантии безопасности поставщика, чтобы покрыть риски, которыми на самом деле должны владеть мы? Этот вопрос исследует разделение DCB0129/DCB0160, которое команды регулярно размывают. Обоснование безопасности поставщика по DCB0129 касается продукта как произведённого, но в момент, когда вы конфигурируете его, подключаете к другим системам, выстраиваете вокруг него местные рабочие процессы и направляете на вашу конкретную группу пациентов, вы вводите опасности, которые поставщик не оценивал и не мог оценить. Честное противоречие в том, что проведение собственной оценки DCB0160 стоит дефицитного клинического и аналитического времени, и соблазнительно считать чистые гарантии поставщика и прохождение DTAC достаточными. Проработайте действующее или предстоящее внедрение и спросите конкретно: кто наш названный CSO для него, есть ли у нас собственный журнал опасностей и какие опасности возникают исключительно из нашего местного контекста, а не из самого продукта? Хороший ответ называет конкретные системы, где местная оценка тонка, различает опасности продукта и опасности внедрения и обязуется владеть вторыми, а не предполагать, что они покрыты.

2. Насколько соразмерен наш процесс клинической безопасности: не хороним ли мы низкорисковые изменения под бумагами, пока изменения с тяжёлыми последствиями проскальзывают по инерции? Тема утверждает, что гарантии должны масштабироваться с клиническим риском: самая тяжёлая проверка для опасностей с наиболее тяжёлыми последствиями, более лёгкий и быстрый процесс там, где риск действительно низок. Этот вопрос проверяет, калибрует ли ваша организация на самом деле или применяет одну грубую настройку. Оба направления сбоя реальны и дороги: равномерно тяжёлый процесс приучает команды видеть клиническую безопасность как бюрократический налог и обходить её, тогда как равномерно лёгкий позволяет изменению калькулятора дозировки лекарств пройти с теми же усилиями, что и изменение страницы справки. Более тонкая опасность в том, что проверку определяет инерция, а не риск: флагманская программа с вниманием руководства может приобрести ауру неизбежности, отбивающую у CSO охоту сказать «ещё нет». Рассмотрите два-три недавних изменения явно разного риска и спросите, соответствовали ли затраченные усилия потенциалу вреда и чувствовал ли кто-нибудь, что может замедлить громкое. Честный ответ признаёт, где процесс неверно откалиброван в ту или иную сторону, и считает соразмерность защитимым явным суждением, а не рефлексом.

3. Когда что-то чуть не пошло не так с одной из наших цифровых систем, что на самом деле случилось дальше, и сказал бы клиницист переднего края, что об этом безопасно сообщить? Этот вопрос исследует культуру безопасности и цикл обучения на инцидентах, где заявленные обязательства встречаются с реальностью. Клиническая безопасность зависит от того, чтобы слышать о почти-происшествиях, но люди сообщают, только когда это кажется безопасным и стоящим и когда они видят, что это ведёт к изменениям, а не к обвинениям. Противоречие в том, что под давлением поставки и репутации инстинкт — объяснить почти-происшествие, быстро закрыть его и двигаться дальше, особенно если полное его раскрытие задержало бы запуск или смутило старшего спонсора. Системный, учитывающий отсутствие обвинений подход PSIRF существует именно потому, что поиск виноватого человека подавляет нужные вам сообщения и упускает реальные, системные причины. Опирайтесь на конкретное недавнее почти-происшествие или инцидент: было ли оно зарегистрировано, дошло ли до журнала опасностей, проведено ли соразмерное расследование и изменилось ли что-нибудь на самом деле? Хороший ответ откровенен в том, казалось ли сообщение безопасным, отличает подлинное обучение от закрытия бумаг и называет конкретные модели поведения, которые примут руководители, чтобы следующий заметивший опасность человек высказался.

4. Определили ли мы честно, какие из наших продуктов являются регулируемыми медицинскими изделиями, и кто отвечает за это решение? Регуляторный статус — пороговый вопрос с непропорциональными последствиями, и его легко оставить без ответа, потому что ответ может быть неудобен. Программное обеспечение, которое диагностирует, прогнозирует, отслеживает или лечит, само может быть программным обеспечением как медицинским изделием, влекущим обязательства MHRA и стандарт жизненного цикла IEC 62304, отдельные от управления клиническими рисками DCB0129/0160 и дополнительные к нему. Противоречие идёт в обе стороны: занижение классификации оставляет вас поставляющими незарегистрированное изделие (юридический сбой и сбой безопасности, который может катастрофически всплыть в масштабе), а завышение классификации простого административного инструмента сжигает дефицитную мощность гарантий, нужную вам в другом месте. Опасность в том, что классификация проваливается между ролями: клиницисты думают, что решили инженеры, инженеры думают, что решила регуляторная или коммерческая команда, и никто на деле не записал рассуждение. Посмотрите конкретно на продукты вашего портфеля, стоящие ближе всего к границе (всё, где есть правило сортировки, оценка риска, алгоритм оповещения), и спросите, кто принял определение изделия, на каком основании, и задокументировано ли оно и пересматривается ли по мере изменения функций. Честный ответ называет пограничные продукты, указывает на записанное и защитимое обоснование для каждого и откровенен там, где решение так и не было по-настоящему принято.

5. Устраняем ли мы опасности проектом или тихо накапливаем оповещения и предупреждения, которые наши клиницисты уже научились игнорировать? Тема ранжирует контроли по силе (устранение опасности проектом лучше оповещения на экране, которое лучше строки в учебном пособии), но оповещения — путь наименьшего сопротивления, потому что добавить предупреждение быстро и ощущается ответственным, тогда как перепроектировать рабочий процесс медленно и спорно. Со временем эта склонность накапливается в усталость от тревог: срабатывает столько предупреждений, что клиницисты по шаблону пропускают все, включая то, что имеет значение, так что каждое новое оповещение может на деле снижать безопасность. Реальное противоречие в том, что у каждого ненужного оповещения есть спонсор, добавивший его из лучших побуждений после некоего инцидента, что делает предупреждения политически трудными для удаления, даже когда они ухудшают систему. Человеческие факторы — здесь дисциплина: проектирование так, чтобы безопасное действие было лёгким, действием по умолчанию для занятого, прерываемого пользователя, читающего экран в 3 часа ночи, а тестирование удобства использования в реалистичных условиях — деятельность по клинической безопасности, а не дизайнерская любезность. Изучите систему, которой ваши команды реально пользуются, и спросите, сколько оповещений клиницист встречает в типичной задаче, какие из них действительно меняют поведение и где принудительная функция или лучшее значение по умолчанию могли бы вообще заменить предупреждение. Хороший ответ сопротивляется рефлексу добавить ещё одно оповещение, считает нагрузку оповещений измеримой опасностью самой по себе и готов убирать предупреждения, которые больше не заслуживают своего места.

6. Когда наши действующие системы, интеграции и клинические маршруты со временем дрейфуют, как мы узнаем, что наше обоснование безопасности всё ещё верно? Клиническая безопасность не заканчивается при запуске; действующие системы порождают новые опасности, а мир вокруг системы продолжает двигаться: вышестоящая интеграция меняет свои данные, клинический маршрут перепроектируется, поставщик выпускает обновление, новая когорта пациентов начинает пользоваться инструментом. Обоснование безопасности, утверждённое два года назад, описывает систему и контекст, которых может уже не существовать, поэтому вопрос в том, является ли ваш журнал опасностей живым реестром или документом, подписанным один раз и оставленным гнить (см. тему 3.8 — Управление услугами и эксплуатация). Противоречие в том, что поддержание рассуждения о безопасности после запуска конкурирует с новой поставкой за то же дефицитное время CSO и клиницистов, а дрейф постепенен и невидим так, что редко привлекает внимание, пока что-то не откажет. Конкретные ракурсы: контроль изменений, повторно запускающий оценку опасностей при смене конфигурации или интеграций, периодический пересмотр опасностей с самыми тяжёлыми последствиями и мониторинг, который действительно обнаружил бы тихую деградацию контроля. Выберите систему, работающую год и дольше, и спросите, когда её опасности пересматривались в последний раз, что изменилось под ней с момента утверждения и кто заметил бы, если бы ключевой контроль перестал работать. Честный ответ отличает системы с подлинным текущим управлением безопасностью от тех, что катятся на устаревшем обосновании безопасности, и обязуется соблюдать соразмерный ритм пересмотра, привязанный к реальным изменениям, а не только к календарю.

На практике: пример из здравоохранения и ухода#

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

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

Работая с циклом контроля риска, команда предпочитает проект предупреждениям. Они добавляют принудительную функцию, чтобы срочный клинический флаг не мог быть молча отменён логикой маршрутизации, отчёт сверки, который клиницист просматривает ежедневно, и, на низшем уровне иерархии, учебную заметку. Остаточный риск переоценён и признан приемлемым и ALARP; CSO записывает почему. Поскольку инструмент только маршрутизирует и сам не диагностирует, команда оценивает, что он не достигает порога SaMD, документирует это рассуждение и подшивает. Тестирование человеческих факторов ловит отдельную проблему: излишне усердное оповещение о «дублирующем направлении» срабатывает так часто, что врачи общей практики его уже игнорируют, поэтому его перепроектируют так, чтобы оно срабатывало только на настоящие дубликаты.

При запуске обоснование безопасности по DCB0160 утверждается CSO, а не директором программы. Через три недели отчёт LFPSE и почти-происшествие, отмеченное регистратором, выявляют новую опасность: свободное текстовое поле используется для проноса срочной информации, которую маршрутизация никогда не видит. В рамках PSIRF проходит соразмерный, системный пересмотр, опасность входит в журнал, планируется изменение проекта, и в ту же неделю инструктируют о временном контроле. Обоснование безопасности — живая аргументация, а запись показывает, как именно рассуждали о каждой опасности: именно это понадобится инспектору, коронеру или новому CSO через два года.

Отраслевые перспективы#

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

Стартап#

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

Малый бизнес#

Устоявшийся небольшой поставщик (практика врача общей практики, общественная аптека, дом престарелых, агентство ухода на дому, клиника в одном месте или небольшой поставщик health-tech, миновавший стадию без выручки) несёт ту же обязанность по DCB0160, что и крупный траст, когда внедряет и конфигурирует цифровые системы, но без запаса мощности для её исполнения. Выделенного CSO или аналитика безопасности в штате почти не бывает, поэтому практический путь — привлечь компетентного практикующего клинициста по договору и вести скромный, но настоящий журнал опасностей, а не делать вид, что обязанность не применима. Самые острые местные опасности обычно связаны с конфигурацией и рабочими процессами: как настроена общая карта, как обрабатываются срочные флаги, как обходной путь одного администратора на неполной ставке становится риском маршрутизации, то есть именно опасности, которых обоснование поставщика по DCB0129 никогда не покрывает. Соразмерность здесь друг малого поставщика: сосредоточьте то небольшое время на гарантии, что у вас есть, на опасностях с наиболее тяжёлыми последствиями, используйте DTAC и обоснование безопасности поставщика как нижнюю планку при выборе продуктов и опирайтесь на общие ресурсы, такие как поддержка клинической безопасности ICS, а не пытайтесь построить весь аппарат в одиночку.

Крупная организация#

Траст NHS или ICS несёт двойную подотчётность: он внедряет системы других по DCB0160 и часто создаёт или сильно конфигурирует собственные по DCB0129. Характерный сбой институционален: флагманская программа электронной карты пациента, чья дата запуска имеет политический вес, так что осторожность CSO тихо считается препятствием. Лекарство структурно: дать CSO независимость и реальное право вето, вести живой журнал опасностей по всему парку, а не полку документов дня запуска, и подключить обучение LFPSE и PSIRF обратно к управлению клиническими рисками как постоянный процесс. В масштабе крупной организации самые большие опасности — опасности интеграции и конфигурации, которых не покрывают никакие гарантии поставщика, поэтому местная принадлежность не подлежит обсуждению.

Государство#

Национальный орган (NHS England, MHRA, DHSC, NICE) задаёт стандарты, которым должны соответствовать другие, поэтому его способы работы формируют всю систему: DCB0129/0160, DTAC и регулирование SaMD — инструменты безопасности в масштабе населения. Решения здесь привлекают внимание регуляторов, парламента и общественности, а национально предписанная система, несущая скрытую опасность, распределяет вред по миллионам до того, как кто-либо увидит закономерность. Обязанности — соразмерность, явно закреплённая в опубликованных стандартах, прозрачность в отношении остаточного риска и поддержание регуляторной рамки в актуальном состоянии, пока технологии, особенно ИИ, её опережают (см. тему 8.4 — Управление ИИ и новыми технологиями). Особый риск в этом масштабе системный: предписание технологии по всему парку на тонких доказательствах безопасности закрепляет опасность везде сразу.

Типичные способы сбоя#

• Безопасность, навешенная в конце. Подготовка обоснования безопасности за неделю до запуска для прохождения ворот. Противоядие: открыть журнал опасностей на исследовании; устранять крупнейшие опасности проектом.
• Гарантии поставщика принимают за местную безопасность. Считать обоснование по DCB0129 и прохождение DTAC покрывающими ваше внедрение. Противоядие: владеть своей оценкой DCB0160 и местным журналом опасностей.
• CSO как формальная печать. Специалист по клинической безопасности без времени, независимости или полномочий сказать «ещё нет». Противоядие: защитить роль и сделать согласование настоящими воротами.
• Мёртвый журнал опасностей. Документ, написанный один раз и никогда не пересматриваемый после запуска. Противоядие: держать живым; подавать в него инциденты и изменения.
• Перегрузка оповещениями. Так много предупреждений, что клиницисты игнорируют все, включая жизненно важные. Противоядие: проектирование с учётом человеческих факторов; каждое оповещение должно заслужить своё место.
• Культура обвинений. Наказание людей за почти-происшествия, из-за чего сообщения иссякают. Противоядие: справедливая, системная культура, согласованная с PSIRF.
• Пропущенный регуляторный порог. Поставка SaMD без признания его регулируемым изделием. Противоядие: рано оценить и задокументировать статус медицинского изделия.

Модель зрелости#

Контрольный список#

• Для каждой системы назван компетентный, практикующий, обученный специалист по клинической безопасности со временем и полномочиями сказать «ещё нет».
• Для каждой системы в охвате существуют файл управления клиническими рисками, живой журнал опасностей и клиническое обоснование безопасности.
• Выявление опасностей началось на исследовании, с клиницистами переднего края в комнате.
• Внедряющая организация провела собственную оценку DCB0160, а не просто приняла обоснование поставщика по DCB0129.
• Контроли рисков предпочитают устранение проектом оповещениям и обучению, остаточный риск снижен до ALARP и обоснован.
• Статус медицинского изделия / SaMD оценён и задокументирован, обязательства MHRA / IEC 62304 задействованы там, где это уместно.
• DTAC пройден как нижняя планка, в сочетании с местным управлением клиническими рисками.
• Проведено тестирование человеческих факторов и удобства использования в реалистичных условиях; нагрузка оповещений контролируется.
• Действующие инциденты (LFPSE) и обучение PSIRF возвращаются в журнал опасностей как постоянный процесс.
• Сообщать о почти-происшествиях и оспаривать запуск по соображениям безопасности наглядно безопасно и ожидаемо.

Ключевые источники#

• NHS England — DCB0129: Clinical Risk Management: its Application in the Manufacture of Health IT Systems.
• NHS England — DCB0160: Clinical Risk Management: its Application in the Deployment and Use of Health IT Systems.
• NHS England — Clinical Safety Officer training и руководство по управлению клиническими рисками.
• NHS England — Digital Technology Assessment Criteria (DTAC).
• MHRA — руководство Software and Artificial Intelligence (AI) as a Medical Device.
• IEC — IEC 62304: Medical device software — software life cycle processes.
• ISO — ISO 14971: Application of risk management to medical devices.
• NHS England — служба Learn from Patient Safety Events (LFPSE).
• NHS England — Patient Safety Incident Response Framework (PSIRF).
• Всемирная организация здравоохранения — Global Patient Safety Action Plan 2021–2030.

Ссылки#

1. Patient safety — Wikipedia — https://en.wikipedia.org/wiki/Patient_safety
2. Risk management — Wikipedia — https://en.wikipedia.org/wiki/Risk_management
3. Hazard analysis — Wikipedia — https://en.wikipedia.org/wiki/Hazard_analysis
4. Safety case — Wikipedia — https://en.wikipedia.org/wiki/Safety_case
5. Medical device — Wikipedia — https://en.wikipedia.org/wiki/Medical_device
6. Medicines and Healthcare products Regulatory Agency — Wikipedia — https://en.wikipedia.org/wiki/Medicines_and_Healthcare_products_Regulatory_Agency
7. Ergonomics (human factors) — Wikipedia — https://en.wikipedia.org/wiki/Ergonomics
8. Safety culture — Wikipedia — https://en.wikipedia.org/wiki/Safety_culture
9. As low as reasonably practicable (ALARP) — Wikipedia — https://en.wikipedia.org/wiki/As_low_as_reasonably_practicable
10. Root-cause analysis — Wikipedia — https://en.wikipedia.org/wiki/Root-cause_analysis
11. IEC 62304 — Wikipedia — https://en.wikipedia.org/wiki/IEC_62304
12. DCB0129: Clinical Risk Management in the Manufacture of Health IT Systems — NHS England — https://digital.nhs.uk/services/clinical-safety/clinical-risk-management-standards
13. DCB0160: Clinical Risk Management in the Deployment and Use of Health IT Systems — NHS England — https://digital.nhs.uk/services/clinical-safety/clinical-risk-management-standards
14. Digital Technology Assessment Criteria (DTAC) — NHS England — https://www.nhs.uk/digital-technology-assessment-criteria-dtac/
15. Software and Artificial Intelligence (AI) as a Medical Device — MHRA, GOV.UK — https://www.gov.uk/government/publications/software-and-artificial-intelligence-ai-as-a-medical-device
16. IEC 62304: Medical device software — software life cycle processes — International Electrotechnical Commission — https://www.iso.org/standard/38421.html
17. ISO 14971: Application of risk management to medical devices — International Organization for Standardization — https://www.iso.org/standard/72704.html
18. Learn from Patient Safety Events (LFPSE) service — NHS England — https://www.england.nhs.uk/patient-safety/patient-safety-insight/learning-from-patient-safety-events/
19. Patient Safety Incident Response Framework (PSIRF) — NHS England — https://www.england.nhs.uk/patient-safety/patient-safety-insight/incident-response-framework/
20. Global Patient Safety Action Plan 2021–2030 — World Health Organization — https://www.who.int/teams/integrated-health-services/patient-safety/policy/global-patient-safety-action-plan