Тема 4.7 — Поддержка клинических решений и клиническая информатика

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

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

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

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

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

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

Система поддержки клинических решений (CDSS, или просто CDS) — информационная технология здравоохранения, дающая клиницистам, персоналу или пациентам знания и персональную информацию, разумно отфильтрованные и представленные в подходящее время, чтобы улучшить решение. Классическая таксономия различает несколько форм. Предупреждения и напоминания прерывают, чтобы предостеречь или подсказать: предупреждение о лекарственном взаимодействии, напоминание о просроченной вакцинации. Наборы назначений связывают анализы, лекарства и указания, подходящие для ситуации, чтобы нужное назначалось вместе. Пути ухода кодируют клинический путь — стандартизованную, основанную на доказательствах последовательность ухода — в рабочий процесс. Шаблоны документации структурируют то, что записывается, чтобы ничего существенного не пропустить. Диагностическая поддержка предлагает или ранжирует возможные диагнозы. А калькуляторы реализуют медицинский алгоритм — расчёт дозы, оценку риска, рСКФ, — чтобы арифметика выполнялась единообразно.

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

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

Два понятия определяют, насколько хорошо поддержка решений приживается. Поддержка решений живёт внутри электронной медицинской записи (EHR, в NHS — электронная медицинская карта, EPR) и часто внутри компьютеризированного ввода назначений (CPOE), поэтому она преуспевает или проваливается как часть более широкой социотехнической системы — взаимодействующей сети людей, задач, технологий и организации. Правило, игнорирующее реальный рабочий процесс, как бы ни была здрава его логика, становится трением, которое обходят. И само содержимое — актив знания: правила кодируют доказательную медицину и медицинские руководства, которые со временем меняются, так что поддержку решений нужно создавать, пересматривать, версионировать и выводить, как любой другой корпус клинического знания (см. тему 10.3 — Управление знаниями и документация).

Информатика здравоохранения и её клиническая поддисциплина, клиническая информатика, — область, изучающая и применяющая информацию и технологии в здравоохранении. В Великобритании она профессионализировалась через Faculty of Clinical Informatics и такие роли, как главный директор по клинической информации (CCIO) и главный директор по сестринской информации (CNIO). Исторически значительная часть логики правил выражалась в синтаксисе Arden — стандарте представления разделяемого медицинского знания как «медицинских логических модулей»; сегодня такие стандарты, как HL7 CDS Hooks и клиническое рассуждение на основе FHIR, нацелены на то, чтобы сделать поддержку решений разделяемой между системами (см. тему 4.3 — Интероперабельность и стандарты данных). Наконец, обратите внимание на границу этой темы: она охватывает основанную на правилах и знаниях поддержку и профессию информатики. Статистические подходы и машинное обучение, включая компьютерную диагностику и программное обеспечение как медицинское изделие, регулируются как искусственный интеллект (см. тему 8.4 — Управление ИИ и новыми технологиями).

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

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

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

3. Измеряйте частоту переопределения и охотьтесь на шум. Самый полезный сигнал здоровья поддержки решений — как часто клиницисты переопределяют каждое предупреждение в разбивке по правилам, специальностям и ролям. Правило, переопределяемое почти каждый раз, когда срабатывает, никого не защищает: оно приучает пользователей игнорировать всю систему, включая важные предупреждения. Регулярно пересматривайте худших нарушителей и действуйте: выводите их, сужайте критерии срабатывания, понижайте с прерывающих до пассивных или исправляйте лежащую в основе проблему данных, из-за которой они срабатывают ложно. Приглушение шума — столь же деятельность по безопасности, как добавление нового правила.

4. Разбейте предупреждения по уровням серьёзности и делайте прерывание соразмерным. Не каждое предупреждение заслуживает остановить мир. Спроектируйте осознанную иерархию: настоящий жёсткий стоп для редкой, катастрофической угрозы; прерывающее, но переопределяемое предупреждение для серьёзных рисков; и пассивная, неблокирующая информация для просто полезного. Соразмеряйте трение с клиническими ставками и требуйте причину переопределения только для предупреждений, достаточно серьёзных, чтобы оправдать лишнее нажатие. Когда срочно всё, не срочно ничто, и по-настоящему опасное предупреждение тонет в тривиальном.

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

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

7. Ведите поддержку решений под управлением клинической безопасности и профессии информатики. Относитесь к каждому новому правилу и изменению как к клиническому делу безопасности по стандартам NHS DCB0129 (производитель) и DCB0160 (внедряющий), с офицером клинической безопасности, подписывающим анализ опасностей (см. тему 1.6 — Клиническая безопасность и управление рисками). Дайте работе профессиональное владение: CCIO или CNIO, отвечающий за клиническое содержимое, клиницисты с подготовкой по информатике, создающие его, и путь для сотрудников переднего края, чтобы сообщать о предупреждении, которое неверно, отсутствует или вредит. Поддержка решений без названного клинического владельца — осиротевшая система безопасности, ждущая отказа.

8. Оценивайте эффективность по результатам и будьте честны, когда она не работает. Цель правила — изменить решение к лучшему, поэтому измеряйте, делает ли оно это: назначения стали безопаснее, анализ перестали назначать избыточно, путь, который пациенты действительно прошли, — а не только то, что предупреждение сработало (см. тему 8.6 — Исследования и оценка в реальных условиях). Следите за непреднамеренными последствиями: предупреждения, перекладывающие работу на другую роль, обходные пути, создающие новые угрозы, или «правильные» подсказки, добавляющие время, не меняя результатов. Там, где доказательства говорят, что правило добавляет трение без пользы, выводите его. Сдержанность — выключение вещей — зрелая форма поддержки решений, а не отступление от неё.

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

1. Какие из наших предупреждений действительно защищают пациентов, а какие просто приучают клиницистов нажимать «переопределить»? Это важно, потому что системе поддержки решений доверяют лишь настолько, насколько её худшим предупреждениям: горстка шумных, почти бесполезных предостережений учит клиницистов рефлекторно отмахиваться от всего, так что в день, когда срабатывает подлинная угроза, её отклоняют вместе с остальными. Вытащите реальные доли переопределения по правилам и ролям и будьте честны в том, что говорит 95% переопределений: не что клиницисты небрежны, а что правило неверно для рабочего процесса. Обсудите более трудный компромисс: каждое выводимое предупреждение убирает теоретическую страховочную сетку, и кто-нибудь спросит: «а что если единственный пропущенный случай — тот, что мы выключили?» Хороший, честный ответ противится такой постановке, признавая, что проигнорированное предупреждение никого не защищает, и обязуется активно сокращать хозяйство — выводить, сужать или понижать самые шумные правила, — а не только добавлять новые. Он также называет, кто уполномочен выключить правило, потому что если ответ «никто не смеет», система будет только шумнее.

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

3. Как мы строим и оцениваем поддержку решений, чтобы она вписывалась в то, как клиницисты на самом деле работают, и как бы мы узнали, что она сделала хуже? Правило может быть медицински безупречным и всё же проваливаться, потому что приходит не в тот момент, прерывает не ту роль или перекладывает работу на кого-то ниже по потоку, кто о ней не просил. Обсудите, проектируется ли ваша поддержка решений с клиницистами переднего края, наблюдающими реальный процесс, или настраивается людьми, читающими спецификацию, никогда не видевшими выполнения задачи. Обсудите, что значит «успех»: подсчёты срабатываний и доли кликов легко собрать, но они почти ничего не говорят, тогда как изменённые результаты и предотвращённый вред — то, что важно, и измерить их куда труднее (см. тему 8.6 — Исследования и оценка в реальных условиях). Выведите непреднамеренные последствия, к которым вы можете быть слепы: обходные пути, создающие новые угрозы, предвзятость автоматизации, закрепляющая клинициста на неверной подсказке, или время, добавленное без пользы. Хороший ответ рассматривает каждое значимое правило как изменение для оценки, а не переключатель для щелчка, сочетает количественные сигналы с наблюдением за реальными пользователями и готов заключить, что благонамеренное правило нужно убрать.

4. Когда мы меняем правило поддержки решений, относимся ли мы к этому как к изменению клинической безопасности с анализом опасностей или как к обычной правке конфигурации? Одно изменение правила мгновенно распространяется на тысячи клиницистов и миллионы контактов, так что разница между двумя формулировками — разница между управляемым клиническим активом и неуправляемым. Обсудите честно, проходит ли каждое значимое изменение сегодня через дело клинической безопасности по DCB0129 и DCB0160 с офицером клинической безопасности, подписывающим анализ опасностей, или изменения делаются на экране конфигурации людьми, никогда не видящими их как критичные для безопасности (см. тему 1.6 — Клиническая безопасность и управление рисками). Выведите напряжение: надлежащая оценка безопасности добавляет трение и замедляет поставку и под давлением первой пропускается ради «очевидного» исправления. Но опасный крайний случай — взаимодействие, которое правка молча обнажает, предел дозы, который «маленькое» изменение тихо убирает, — именно то, что анализ опасностей существует ловить. Хороший ответ называет, кто отвечает, когда правило причиняет вред, настаивает, что даже малозаметные правки несут соразмерную оценку безопасности, и может показать след аудита, доказывающий это, а не обнаруживает после инцидента, что никто не записал, почему сделано изменение.

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

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

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

Kingsmere NHS Foundation Trust, часть Riverdale and Vale Integrated Care System, два года назад запустил новую электронную медицинскую карту. Клиническое содержимое пришло в основном из библиотеки поставщика по умолчанию, слегка локализованной в торопливом внедрении. К этому году клиницисты громко жалуются: система «сплошные всплывающие окна», младшие врачи описывают, как кликают по предупреждениям, не читая, а фармацевт поднял вопрос безопасности после того, как серьёзное предупреждение о взаимодействии было отклонено в череде случаев, потому что выглядело в точности как десятки тривиальных, срабатывающих каждую смену.

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

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

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

Секторные линзы#

Стартап#

Стартап в цифровом здравоохранении, встраивающий поддержку решений — инструмент триажа, калькулятор риска, модуль поддержки назначений, — обычно находится на стороне производителя и должен с самого начала относиться к своим правилам как к регулируемому клиническому знанию. Даже «простой» калькулятор, рекомендующий действие, может быть программным обеспечением как медицинским изделием, что втягивает его в регулирование MHRA и требует дела клинической безопасности по DCB0129 (см. тему 1.5 — Регуляторный ландшафт и соответствие). Искушение — быстро выпустить хитрую логику; дисциплина — задокументировать доказательную основу, версионировать содержимое и спроектировать изящное переопределение и человеческий надзор до того, как первый клиницист на неё положится. Доверие стартапа у покупателя NHS держится не меньше на том, как он управляет и обновляет клиническое содержимое, чем на хитрости алгоритма.

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

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

Предприятие#

Крупный траст NHS или больничная группа обычно наследует тысячи правил из библиотеки поставщика EHR по умолчанию, и его центральная задача — управление в масштабе, а не создание с нуля. Реалистичная цель — постоянная функция управления клиническим содержимым, надёжная аналитика переопределений, многоуровневая схема предупреждений и дисциплина выводить и настраивать, а не только накапливать, а не идеально индивидуальное правило на каждый случай. Встройте изменения поддержки решений в клинический контроль изменений и систему управления клинической безопасностью, с ответственным CCIO или CNIO и клиницистами с подготовкой по информатике, делающими работу (см. тему 4.6 — Электронные медицинские карты и клинические системы). В таком масштабе крупнейшие выигрыши безопасности дают сокращение шума и владение содержимым, а не добавление всё новых предупреждений.

Правительство#

Национальный орган — NHS England, MHRA, NICE — формирует среду поддержки решений, в которой работает каждый поставщик. Он может курировать и обеспечивать качество разделяемого знания (руководства NICE, данные о лекарствах BNF и dm+d), задавать стандарты клинической безопасности DCB0129 и DCB0160 и вести стюардство стандартов интероперабельности, чтобы правилу, созданному один раз, можно было доверять и использовать его повторно, а не перестраивать в каждом трасте (см. тему 9.1 — Работа с местными и национальными правительствами). Его рычаг — сделать хорошо управляемую, связанную с доказательствами поддержку решений рыночным умолчанием через стандарты, закупочные рамки и профессиональную инфраструктуру, такую как Faculty of Clinical Informatics. Правительство также несёт обязанности равенства и прозрачности: обеспечить, чтобы логика поддержки решений не кодировала предвзятость против отдельных групп, а её происхождение было аудируемым и публичным.

Типичные виды отказов#

• Перегрузка предупреждениями. Предупреждение о каждом мыслимом риске десенсибилизирует клиницистов, пока они не отклоняют всё, включая важные предупреждения. Разбивайте по серьёзности, измеряйте долю переопределений и агрессивно сокращайте шум.
• Бесхозное, непересмотренное содержимое. Правила, настроенные один раз при запуске и больше не пересматриваемые, расходятся с текущим руководством и тихо кодируют устаревшие доказательства. Дайте каждому правилу названного владельца, доказательную основу и дату пересмотра.
• Умолчания поставщика без настройки. Отгрузка готовой библиотеки правил поставщика без локализации под ваш рабочий процесс и формуляр импортирует чужой шум и чужие допущения. Пересматривайте и настраивайте до запуска, а не после жалоб.
• Логика без рабочего процесса. Клинически правильное правило на не том шаге, экране или роли становится трением, которое клиницисты обходят. Проектируйте и тестируйте с пользователями переднего края в реальной задаче.
• Подсчёты срабатываний, принятые за эффективность. «Предупреждение сработало 10 000 раз» ничего не говорит о том, улучшилось ли хоть одно решение. Оценивайте по изменённым результатам и предотвращённому вреду и следите за непреднамеренными последствиями.
• Нет дела безопасности. Отношение к изменению правила как к обычной правке конфигурации, а не изменению клинической безопасности, пропускает анализ опасностей, ловящий опасный крайний случай. Проводите каждое изменение через DCB0160.
• Предвзятость автоматизации и утрата навыков. Чрезмерное доверие подсказке машины может закрепить клинициста на неверном ответе или разъесть суждение, которое система предполагает. Сохраняйте осмысленный человеческий надзор и проектируйте так, чтобы переопределение было лёгким и законным.

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

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

• У каждого правила поддержки решений, набора назначений и шаблона есть названный клинический владелец, доказательная основа, история версий и дата пересмотра.
• Постоянная группа управления клиническим содержимым разрешает, пересматривает и выводит содержимое по графику, основанному на рисках.
• Предупреждения разбиты по уровням серьёзности, прерывание соразмерно клиническим ставкам, а жёсткие стопы зарезервированы для редкой катастрофической угрозы.
• Доли переопределений отслеживаются по правилам, специальностям и ролям, а самые шумные правила активно выводятся, сужаются или понижаются.
• Поддержка решений проектируется и тестируется с клиницистами переднего края в реальном рабочем процессе до запуска.
• Каждое новое правило и изменение проходит дело клинической безопасности по DCB0129/DCB0160 с подписью офицера клинической безопасности.
• CCIO, CNIO или эквивалент отвечает за клиническое содержимое при поддержке клиницистов с подготовкой по информатике.
• Клиницисты могут переопределять с осмысленной лёгкостью, и существует путь сообщить о предупреждении, которое неверно, отсутствует или вредит.
• Эффективность оценивается по изменённым решениям и результатам, а не по подсчётам срабатываний, с наблюдением за непреднамеренными последствиями.
• Граница с поддержкой на основе ИИ/МО явна, и любые статистические или обучаемые компоненты регулируются в рамках управления ИИ (см. тему 8.4).

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

• NHS England / NHS Digital — стандарты клинической безопасности DCB0129 (производство ИТ-систем здравоохранения) и DCB0160 (внедрение ИТ-систем здравоохранения) и руководство для офицеров клинической безопасности.
• Faculty of Clinical Informatics — профессиональные стандарты и Core Competency Framework для практиков клинической информатики; определения ролей CCIO и CNIO.
• Osheroff et al. — Improving Outcomes with Clinical Decision Support: An Implementation Sourcebook (HIMSS) — происхождение рамки «пять верно» для CDS.
• NICE — доказательства, руководства и Evidence Standards Framework for Digital Health Technologies; аккредитованные NICE знания, используемые как содержимое CDS.
• HL7 International — стандарты CDS Hooks и FHIR Clinical Reasoning; синтаксис Arden для разделяемых медицинских логических модулей.
• The Topol Review (Preparing the healthcare workforce to deliver the digital future) — рабочая сила и потенциал клинической информатики.
• MHRA — руководство по программному обеспечению и искусственному интеллекту как медицинскому изделию, для поддержки, пересекающей регуляторный порог.

Литература#

1. Clinical decision support system — Wikipedia — https://en.wikipedia.org/wiki/Clinical_decision_support_system
2. Health informatics — Wikipedia — https://en.wikipedia.org/wiki/Health_informatics
3. Alarm fatigue — Wikipedia — https://en.wikipedia.org/wiki/Alarm_fatigue
4. Computerized physician order entry — Wikipedia — https://en.wikipedia.org/wiki/Computerized_physician_order_entry
5. Clinical pathway — Wikipedia — https://en.wikipedia.org/wiki/Clinical_pathway
6. Medical algorithm — Wikipedia — https://en.wikipedia.org/wiki/Medical_algorithm
7. Medical guideline — Wikipedia — https://en.wikipedia.org/wiki/Medical_guideline
8. Evidence-based medicine — Wikipedia — https://en.wikipedia.org/wiki/Evidence-based_medicine
9. Electronic health record — Wikipedia — https://en.wikipedia.org/wiki/Electronic_health_record
10. Sociotechnical system — Wikipedia — https://en.wikipedia.org/wiki/Sociotechnical_system
11. Arden syntax — Wikipedia — https://en.wikipedia.org/wiki/Arden_syntax
12. Machine learning — Wikipedia — https://en.wikipedia.org/wiki/Machine_learning
13. Computer-aided diagnosis — Wikipedia — https://en.wikipedia.org/wiki/Computer-aided_diagnosis
14. Knowledge management — Wikipedia — https://en.wikipedia.org/wiki/Knowledge_management
15. NHS England — Clinical Risk Management Standards DCB0129 and DCB0160 — NHS England — https://www.england.nhs.uk/long-read/clinical-risk-management-standards/
16. Faculty of Clinical Informatics — Core Competency Framework and professional standards — FCI — https://facultyofclinicalinformatics.org.uk/
17. National Institute for Health and Care Excellence — Evidence Standards Framework for Digital Health Technologies — NICE — https://www.nice.org.uk/about/what-we-do/our-programmes/evidence-standards-framework-for-digital-health-technologies
18. Health Level Seven International — CDS Hooks and FHIR Clinical Reasoning — HL7 — https://cds-hooks.hl7.org/
19. Health Education England — The Topol Review: Preparing the healthcare workforce to deliver the digital future — NHS — https://topol.hee.nhs.uk/
20. Medicines and Healthcare products Regulatory Agency — Software and AI as a Medical Device — GOV.UK — https://www.gov.uk/government/publications/software-and-artificial-intelligence-ai-as-a-medical-device