Тема 4.6 — Электронные медицинские карты и клинические системы

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

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

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

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

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

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

Электронная медицинская запись здоровья (EHR) — систематизированный цифровой сбор информации о здоровье пациента. В британской практике близкий синоним — электронная медицинская карта (EPR) — обычно обозначает основную клиническую систему организации-поставщика: запись и инструменты, которыми клиницисты пользуются в точке ухода. Вокруг неё находится семейство клинических систем, исторически описываемых как больничная информационная система (HIS): система администрирования пациентов (PAS), отслеживающая поступления, выписки, переводы и амбулаторные приёмы; клиническая документация; отчётность по результатам; и специализированные системы для операционных, родильных, неотложной и интенсивной помощи.

Компьютеризированный ввод назначений врача (CPOE, также «order comms») — электронный ввод клинических назначений (анализы, лекарства, направления) непосредственно назначающим клиницистом вместо бумаги и телефонных звонков. Именно здесь реализуется значительная часть ценности EPR для безопасности, потому что назначения можно проверять, стандартизировать в наборы назначений и маршрутизировать автоматически. CPOE тесно связан с электронным назначением и с поддержкой клинических решений, выводящей предупреждения и рекомендации в рабочий процесс (рассматриваются в теме 4.7 — Поддержка клинических решений и клиническая информатика и теме 4.8 — Электронное назначение и управление лекарствами).

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

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

Повторяется несколько системных понятий. Миграция данных — разовый перенос исторических записей из унаследованных систем в новую EPR: технически рутинный, клинически чреватый процесс. Интеграционный движок (interface engine) маршрутизирует сообщения между системами по стандартам, таким как Health Level Seven (HL7) и FHIR (см. тему 4.3 — Интероперабельность и стандарты данных). Обмен медицинской информацией или общая запись ухода позволяет организациям региона читать записи друг друга. А поскольку карта критична для безопасности, процедуры простоя — планы непрерывности для случаев, когда EPR недоступна, — основная часть системы, а не запоздалая мысль (см. тему 3.9 — Непрерывность бизнеса и аварийное восстановление). Цифровая зрелость обычно оценивается по Electronic Medical Record Adoption Model (EMRAM) от Healthcare Information and Management Systems Society (HIMSS), шкале возможностей клинических систем от 0 до 7.

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

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

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

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

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

5. Планируйте провал производительности и финансируйте оптимизацию, которая за ним следует. Почти за каждым запуском EPR следует период сниженной пропускной способности, пока персонал осваивает систему, а организации, делающие вид, что это не так, вредят и безопасности, и моральному духу. Сознательно сократите плановую активность вокруг запуска, защитите время на обучение и задайте с советом реалистичные траектории восстановления, чтобы провал был плановым событием, а не кризисом (см. тему 8.1 — Управление изменениями). Принципиально: закладывайте бюджет и персонал на непрерывную оптимизацию после: ценность EPR реализуется в годы после запуска, через итеративную настройку рабочих процессов, наборов назначений и предупреждений, — продуктовая дисциплина, а не проект, заканчивающийся переключением (см. тему 5.0 — Работа, ведомая продуктом).

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

7. Встройте простой и непрерывность в запись с самого начала. EPR однажды станет недоступна — из-за неудачного обновления, сбоя сети или атаки вымогателя, — а больница, не способная функционировать на бумаге эти часы, — инцидент безопасности пациентов в ожидании. Обеспечьте доступ только для чтения к недавней копии записи во время сбоев, поддерживайте отрепетированные бумажные клинические процессы и практикуйте плановый и внеплановый простой, чтобы персонал не импровизировал под давлением. Явно согласуйте цели времени и точки восстановления клинической записи и проверьте сверку бумажных записей обратно в систему после восстановления (см. тему 3.9 — Непрерывность бизнеса и аварийное восстановление).

8. Реализуйте выгоды осознанно и измеряйте результаты, которые обещали. Бизнес-обоснование EPR опирается на выгоды безопасности, качества и эффективности, не появляющиеся автоматически; их нужно проектировать, закреплять за владельцами и отслеживать. Зафиксируйте базовые значения метрик до запуска, привяжите каждую выгоду к названному владельцу и изменению рабочего процесса и пересматривайте реализацию относительно обоснования через определённые интервалы, а не объявляйте победу при переключении (см. тему 6.2 — Реализация выгод и управление ценностью). Используйте признанный бенчмарк зрелости, такой как HIMSS EMRAM, чтобы дать совету внешнюю, сопоставимую меру прогресса вместо одних лишь внутренних анекдотов.

9. Управляйте конвергенцией и интероперабельностью как системой, а не только программой траста. В интегрированной системе ухода (ICS) стратегическая тяга направлена к меньшему числу экземпляров EPR и общей записи ухода, чтобы информация о пациенте следовала за ним между организациями. Конвергенция на общей EPR может снизить затраты и облегчить поток пациентов, но концентрирует риск и размывает местный контроль, так что взвешивайте её против сильной интероперабельности между различными системами (см. тему 4.3 — Интероперабельность и стандарты данных). Какова бы ни была форма, настаивайте на открытых стандартах и реалистичной стратегии выхода, ограничивающей привязку к поставщику, потому что EPR, из которой нельзя вынуть свои данные, — это EPR, которая владеет вами (см. тему 6.3 — Закупки и коммерческие вопросы).

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

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

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

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

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

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

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

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

Brackenmoor NHS Foundation Trust, поставщик острой и общинной помощи среднего размера, заменяет три стареющие системы — систему администрирования пациентов, отдельную систему order-comms и лоскутное одеяло ведомственных баз данных — единой EPR одного поставщика, частично финансируемой через национальную программу цифровизации переднего края. Его текущая ступень HIMSS EMRAM низка, а его бизнес-обоснование обещает выгоды безопасности и эффективности, на которые рассчитывает совет. Искушение, высказанное рано, — «поднять и перенести» старые способы работы в новую систему, чтобы свести нарушения к минимуму.

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

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

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

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

Стартап#

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

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

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

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

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

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

Национальные органы формируют среду, в которой действует каждая программа EPR. Через программу NHS England по цифровизации переднего края правительство задаёт ожидание, что у каждого поставщика есть базовая EPR, связывает капитальное финансирование с цифровой зрелостью и направляет рынок через конвергенцию и закупочные рамки. Его рычаг — сделать открытые стандарты, интероперабельность и безопасный выход условиями рынка по умолчанию, чтобы отдельные трасты не вели каждый переговоры с позиции слабости против малого числа крупных поставщиков (см. тему 9.1 — Работа с местными и национальными правительствами). Правительство также несёт обязанность общесистемного обучения: распространять то, что работает, между трастами, измерять зрелость на национальном уровне и обеспечивать, чтобы общая запись ухода улучшала уход через организационные границы, а не останавливалась у парадной двери каждого траста.

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

• Клинически пустая программа. Технически хорошо управляемый проект, считающий клиницистов консультируемыми, порождает систему, которой никто не хочет пользоваться. Дайте CCIO и CNIO реальные полномочия, защищённое время и права решения над построением.
• Мощение коровьих троп. Перестройка старых бумажных форм и унаследованных процессов внутри современной EPR оплачивает новое ПО и наследует старые проблемы. Принимайте протестированное содержимое поддерживаемого продукта и перепроектируйте процессы, а не воспроизводите их.
• Разрастание кастомизации. Каждое индивидуальное изменение переоплачивается при каждом обновлении и заново открывает поверхность безопасности, которую никто не перетестирует. Конфигурируйте под поддерживаемую модель; документируйте, оценивайте по рискам и закрепляйте за владельцем каждое подлинное исключение.
• Миграция, которая «прошла чисто». Загрузка без технических ошибок может всё же потерять аллергии или перепутать пациентов. Сверьте и клинически подпишите мигрированные данные до запуска и сохраните доступный архив унаследованной системы.
• Делать вид, что провала нет. Допущение гладкой кривой производительности превращает обычное замедление после запуска в воспринимаемую катастрофу. Планируйте, финансируйте и согласуйте с советом окно сниженной активности с реалистичным восстановлением.
• Остановка при запуске. Отношение к EPR как к проекту, заканчивающемуся переключением, оставляет выгоды нереализованными. Создайте постоянную функцию оптимизации и реализации выгод.
• Перегрузка предупреждениями. Слишком много малоценных предупреждений поддержки решений приучает клиницистов кликать мимо всех, включая важные. Настраивайте, измеряйте частоту переопределений и выводите шум.
• Непроверенные планы простоя. Папка простоя, которую никто не открывал, — не план. Репетируйте плановые и внеплановые сбои, включая сверку обратно в запись.

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

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

• CCIO и CNIO назначены с защищённым временем, бюджетом и реальными правами решения над клиническим построением, при поддержке сети цифровых чемпионов.
• Программа по умолчанию конфигурируется под поддерживаемую модель поставщика; каждая кастомизация документирована, оценена по рискам и закреплена за владельцем.
• Форма развёртывания («большой взрыв» против поэтапной/модульной) выбрана осознанно под аппетит к риску и сложность интеграции, с отрепетированным переключением и планом отката.
• Миграция данных ведётся как клиническое упражнение: объём миграции согласован, данные сверены и клинически подписаны, обеспечен доступный архив унаследованной системы.
• Провал производительности запланирован, профинансирован и одобрен советом, со сниженной активностью, защищённым обучением и реалистичными траекториями восстановления.
• Наборы назначений и предупреждения поддержки решений разработаны совместно с клиницистами и управляются непрерывно, с отслеживанием частоты срабатывания и переопределения.
• Процедуры простоя и непрерывности (доступ только для чтения, бумажные процессы, согласованные RTO/RPO, сверка) существуют и отрепетированы для плановых и внеплановых сбоев.
• Выгоды зафиксированы до запуска, привязаны к названным владельцам и изменениям процессов и пересматриваются относительно бизнес-обоснования после запуска.
• Цифровая зрелость измеряется по бенчмарку (например, HIMSS EMRAM) и используется для отслеживания прогресса с советом.
• Постоянная функция оптимизации и клинической информатики продолжает работу после переключения.
• Открытые стандарты, интероперабельность и реалистичная стратегия выхода обеспечены для ограничения привязки к поставщику, согласованы с планами конвергенции ICS.

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

• NHS England — программа Frontline Digitisation и рамки цифровой зрелости What Good Looks Like / Who Pays for What для клинических систем поставщиков.
• HIMSS — Electronic Medical Record Adoption Model (EMRAM), международный бенчмарк цифровой зрелости клинических систем по шкале 0–7.
• NHS England / NHS Digital — стандарты клинической безопасности DCB0129 (производство) и DCB0160 (внедрение), регулирующие ИТ-системы здравоохранения, включая EPR.
• Faculty of Clinical Informatics и CCIO/CNIO Network — профессиональное руководство по ролям клинического информационного лидерства.
• HL7 International — стандарты HL7 v2 и FHIR для обмена сообщениями и интеграции между клиническими системами.
• HM Treasury — The Green Book и Five Case Model для бизнес-обоснования EPR и реализации выгод.
• Wachter Review (Making IT Work, 2016) и Topol Review — национальные обзоры цифровизации поставщиков NHS и клинической рабочей силы.

Литература#

1. Electronic health record — Wikipedia — https://en.wikipedia.org/wiki/Electronic_health_record
2. Hospital information system — Wikipedia — https://en.wikipedia.org/wiki/Hospital_information_system
3. Computerized physician order entry — Wikipedia — https://en.wikipedia.org/wiki/Computerized_physician_order_entry
4. Clinical decision support system — Wikipedia — https://en.wikipedia.org/wiki/Clinical_decision_support_system
5. Big bang adoption — Wikipedia — https://en.wikipedia.org/wiki/Big_bang_adoption
6. Chief medical informatics officer — Wikipedia — https://en.wikipedia.org/wiki/Chief_medical_informatics_officer
7. Health informatics — Wikipedia — https://en.wikipedia.org/wiki/Health_informatics
8. Data migration — Wikipedia — https://en.wikipedia.org/wiki/Data_migration
9. Health Level 7 — Wikipedia — https://en.wikipedia.org/wiki/Health_Level_7
10. Health information exchange — Wikipedia — https://en.wikipedia.org/wiki/Health_information_exchange
11. Healthcare Information and Management Systems Society — Wikipedia — https://en.wikipedia.org/wiki/Healthcare_Information_and_Management_Systems_Society
12. NHS England — Frontline Digitisation — NHS England — https://www.england.nhs.uk/digitalhealth/connecting-frontline-digitisation/
13. NHS England — What Good Looks Like framework — NHS England — https://www.england.nhs.uk/digitalhealth/what-good-looks-like/
14. HIMSS — Electronic Medical Record Adoption Model (EMRAM) — HIMSS — https://www.himss.org/what-we-do-solutions/digital-health-transformation/maturity-models/electronic-medical-record-adoption-model-emram
15. NHS Digital — Clinical Safety standards DCB0129 and DCB0160 — NHS England — https://digital.nhs.uk/services/clinical-safety
16. Robert Wachter — Making IT Work: Harnessing the Power of Health Information Technology to Improve Care in England — GOV.UK — https://www.gov.uk/government/publications/using-information-technology-to-improve-the-nhs
17. Faculty of Clinical Informatics — professional body for clinical informaticians — FCI — https://facultyofclinicalinformatics.org.uk/