Проект цифровое здравоохранение: тест трёх региональных платформ
Это принципиальная разница.
Запрос «проект цифровое здравоохранение: тест трёх региональных платформ» выглядит как название конкретного сравнительного испытания. Подтверждённого паспорта такого теста, протокола, списка трёх платформ, регионов и результатов в открытом контуре нет. Поэтому объявлять победителя было бы фабрикацией.
Сравнивать здесь можно другое: три типовые модели региональной реализации цифрового контура. Они различаются не дизайном личного кабинета и не количеством экранов в презентации. Различаются контуром данных, глубиной интеграции, управляемостью и точками отказа.
Федеральный проект создания единого цифрового контура на базе ЕГИСЗ работал с 1 января 2019 года по 31 декабря 2024 года. Его задача — не создать одну федеральную медицинскую программу на всех. Архитектура сложнее: региональные ГИС, медицинские информационные системы отдельных организаций, федеральные подсистемы и Единый портал госуслуг должны обмениваться юридически и клинически значимыми данными.
Именно на стыках эта архитектура обычно и ломается.
От ЕГИСЗ к стратегии до 2030 года: что реально строится
Фраза «национальный проект цифровое здравоохранение» часто используется как универсальная этикетка. Технически это неточно. Базовым федеральным контуром был проект создания единого цифрового контура в здравоохранении на основе ЕГИСЗ. После завершения его срока действует стратегическое направление цифровой трансформации здравоохранения до 2030 года.
Регион не получает «цифровизацию» как готовый продукт. Он собирает систему из нескольких слоёв:
- региональной государственной информационной системы — РГИС;
- МИС поликлиник, больниц, диспансеров и частных клиник, если они включены в обмен;
- централизованных подсистем для потоков пациентов, телемедицинских консультаций и архива медицинских изображений;
- федеральных сервисов ЕГИСЗ;
- интерфейсов для пациента, включая раздел «Моё здоровье» на Госуслугах;
- квалифицированных электронных подписей и электронных медицинских документов.
Суммарное финансовое обеспечение региональных проектов цифрового контура в паспорте федерального проекта на 2019–2024 годы составляло 88 046,93 млн рублей. Эта цифра описывает масштаб программы. Она не измеряет качество конкретной региональной платформы.
У платформы может быть современный интерфейс, мобильное приложение и высокий показатель формального заполнения полей. Но если выписка из стационара не попадает в амбулаторную карту, а снимок КТ невозможно открыть врачу другой организации, цифровой контур не собран. Есть набор локальных баз данных.
Цифровая зрелость — не число подключённых учреждений. Это доля клинически полезных данных, которые доходят до нужного врача без ручной переписки и повторного ввода.
Паспорт проекта ставил целью реализацию региональных проектов во всех 85 субъектах РФ к концу 2024 года. Формулировка важна: речь о реализации проектов и внедрении взаимодействующих систем. Она не означает, что все регионы достигли одинакового уровня доступности, полноты данных или надёжности обмена.
Три модели региональной платформы: что именно имеет смысл сравнивать
Без опубликованного протокола нельзя честно назвать три реальные платформы участниками общего теста. Но для аудита информационных систем в здравоохранении достаточно выделить три рабочих типа. В регионах они нередко существуют в смешанном виде.
| Параметр | Единая региональная ГИС | Набор МИС с интеграционной шиной | Региональный портал поверх разнородных систем |
|---|---|---|---|
| Центр управления данными | Единая региональная платформа | Несколько МИС, обмен через интеграционный слой | Портал агрегирует часть данных из разных источников |
| Сильная сторона | Единые справочники, маршрутизация, управляемость | Можно сохранить работающие системы медорганизаций | Быстро заметен пациенту: запись, результаты, уведомления |
| Главный риск | Монополия одного поставщика и тяжёлая миграция | Потери, дубли и задержки на интеграциях | Витрина может выглядеть полной при неполных первичных данных |
| Критическая метрика | Доля учреждений, работающих в едином контуре без локальных обходов | Доля успешно обработанных межсистемных сообщений | Совпадение данных портала с первичным меддокументом |
| Что проверять первым | Реальную работу в поликлинике и стационаре | Журналы ошибок, очереди, повторы, дедупликацию | Источник каждого документа и время его обновления |
Модель 1. Единая региональная ГИС
Это наиболее централизованный вариант. Регион строит крупную РГИС, в которую подключаются учреждения и специализированные модули: регистратура, электронная карта, лабораторные исследования, лекарственное обеспечение, управление потоками пациентов, телемедицина, архив изображений.
Плюс очевиден. Единый пациентский идентификатор, единые справочники, общие правила доступа. Меньше трансляторов между разными системами. Ниже вероятность, что один и тот же диагноз окажется записанным в трёх несовместимых классификаторах.
Минус тоже очевиден. Централизация делает платформу критической инфраструктурой. Ошибка обновления, деградация канала, сбой авторизации или плохая производительность интерфейса одномоментно затрагивают большое число организаций. Врачи в такой ситуации переходят на бумагу, локальные файлы и отложенный ввод. Формально система продолжает существовать. Фактически качество данных деградирует.
У этой модели нельзя измерять успех числом выданных учётных записей. Нужны операционные показатели:
- доступность ключевых модулей в рабочие часы;
- медианное и 95-процентильное время открытия электронной карты;
- доля электронных документов, подписанных без возврата на доработку;
- число случаев повторного ручного ввода сведений;
- доля исследований, доступных врачу в центральном архиве вместе с корректным описанием;
- время восстановления после инцидента.
Без таких метрик заявление «регион перешёл на единую платформу» описывает закупку, а не результат.
Модель 2. Несколько МИС и интеграционная шина
Здесь больницы и поликлиники сохраняют свои МИС. Регион строит обменный слой: шину, API-шлюзы, адаптеры, сервисы идентификации, маршрутизацию сообщений. Такой вариант возникает, когда в регионе уже есть большой парк систем разных поколений и заменить их одномоментно невозможно.
Это реалистичная архитектура. Она снижает стоимость миграции и позволяет не останавливать работу медорганизаций ради внедрения одного продукта. Но цена — сложность.
Каждая новая интеграция создаёт поверхность ошибок. Разные системы могут по-разному хранить дату исследования, статус документа, подразделение, единицы измерения, сведения о враче и согласии пациента. Один контур считает документ подписанным после сохранения. Другой — только после усиленной квалифицированной электронной подписи. Третий отсылает запись в федеральный сервис с задержкой.
В результате появляются типовые дефекты:
1. Дубли пациента. Один человек заведен под разными идентификаторами. Его анализы и приёмы расходятся по нескольким карточкам.
2. Потеря статуса. Сам документ передан, но в принимающей системе отображается как черновик или неподписанная запись.
3. Семантическая ошибка. Поле формально заполнено, но его значение интерпретировано иначе. Это опаснее технического сбоя: запись выглядит корректной.
4. Очередь сообщений. Обмен не падает, но задерживается. Для администратора система «работает», для врача сведения недоступны в момент решения.
5. Ложная успешность. Шина приняла сообщение, но конечная МИС его не обработала. В отчёте успешная передача. В карте пациента пусто.
Для этой модели процент «интегрированных организаций» — слабый показатель. Нужны сквозные трассировки. Берётся выборка реальных документов: направление, лабораторный результат, выписка, протокол исследования. Для каждого фиксируется время создания, подписи, отправки, приёма и появления в целевой системе. Затем считаются потери, задержки и расхождения.
Это не бюрократическая придирка. Это единственный способ отличить обмен данными от обмена XML-файлами.
Портал пациента не равен медицинской информационной системе
Третья модель — региональный портал или приложение, которое собирает на одном экране запись к врачу, рецепты, результаты анализов, направления и уведомления. Для пациента это видимая часть проекта цифровое здравоохранение. Для аудитора — только фронтенд.
Портал может быть полезен. Он снижает нагрузку на регистратуру, делает запись прозрачнее, уменьшает число звонков ради результата анализа. Но его качество нельзя оценивать рейтингом в магазине приложений.
Проверка состоит из трёх вопросов.
- Совпадает ли информация на портале с первичным электронным медицинским документом?
- Откуда поступил каждый элемент: из лабораторной МИС, региональной ГИС, федерального сервиса, вручную введённого реестра?
- Как быстро изменения доходят до пациента и врача?
Нужна и защита от ложноположительного ощущения доступности. Если в приложении не видно протокола, это не всегда означает, что его не существует. Если протокол появился, это не всегда означает, что его уже оценил лечащий врач. Интерфейс должен разделять факты: исследование выполнено, результат подписан, результат доступен, требуется интерпретация специалиста.
Особая зона риска — медицинские изображения. Центральный архив медицинских изображений предусмотрен в региональном контуре не для того, чтобы хранить «картинки». В диагностическом процессе критичны исходные данные исследования, описание, идентификация пациента, дата и возможность открыть материалы в другой организации. PDF с заключением не заменяет доступ к самим изображениям, когда требуется второе мнение или пересмотр.
Пациентский интерфейс оценивают не по удобству записи. Его проверяют по соответствию первичным данным и отсутствию опасных задержек.
Телемедицина: новый порядок не отменяет очный приём
11 апреля 2025 года Минздрав утвердил новый порядок оказания медицинской помощи с применением телемедицинских технологий. Официальное опубликование состоялось 15 мая 2025 года. Порядок распространяется на государственные, муниципальные и частные медицинские организации.
Телемедицинские технологии допускаются при первичной, специализированной, скорой и паллиативной помощи. Консультации могут быть экстренными, неотложными или плановыми. Для работы используются ЕГИСЗ, региональные ГИС, МИС медорганизаций и иные информационные системы.
Это расширяет контур применения. Не превращает видеозвонок в универсальный клинический метод.
Региональная платформа для телемедицины должна выдерживать минимум четыре режима:
| Режим | Что требуется от системы | Что не доказывает наличие видеосвязи |
|---|---|---|
| Врач — врач внутри региона | Передача документов, изображений, заключений, фиксация консультации | Что консультант получил полный набор клинических данных |
| Межрегиональная консультация | Совместимость справочников и юридически значимый документооборот | Что документы открываются без потери структуры |
| Врач — пациент | Идентификация, защита канала, запись результата в меддокумент | Что диагноз можно поставить без осмотра |
| Дистанционный мониторинг | Регулярный сбор показателей, пороги оповещений, ответственный врач | Что гаджетные данные клинически валидны |
Слабая региональная телемедицина обычно выдает себя не отсутствием видеосвязи. Она выдает себя разрывом документации. Консультация прошла в одном сервисе, заключение хранится в другом, лечащий врач не видит его в основной МИС, пациент получает только уведомление. Это не цифровой контур. Это параллельный канал коммуникации.
Электронный документооборот упирается в подпись. В паспорте прежнего федерального проекта был ориентир: ежегодно обеспечивать сертификатами усиленной квалифицированной электронной подписи более 500 тысяч врачей. Масштаб понятен. Но сертификат сам по себе не создаёт юридически значимый документ. Нужны корректно настроенные маршруты подписания, контроль роли подписанта, архивирование, проверка статусов и отсутствие подмены финальной версии документа черновиком.
ИИ в региональной ГИС: интеграция не равна клинической ценности
Стратегия цифровой трансформации предусматривает на 2026 год интеграцию пяти медицинских изделий или программ с ИИ в региональные ГИС. Это целевой показатель. Он не говорит, какие именно алгоритмы будут подключены, на каких данных они проверялись и как изменят решения врачей.
Здесь особенно много маркетингового шума. Любой сервис, который сортирует обращения или подсвечивает строки в тексте, могут назвать «искусственным интеллектом для здравоохранения». Для клинического применения этого недостаточно.
Если программное обеспечение с ИИ имеет медицинское назначение и относится к медицинским изделиям, его обращение связано с государственной регистрацией медицинских изделий. Для ПО с ИИ Росздравнадзор отдельно регулирует особенности внесения изменений в регистрационное досье. Следствие простое: статус продукта проверяют по реестру, а не по логотипу на стенде и не по формулировке в коммерческом предложении.
При оценке ИИ-модуля в региональной платформе нужны пять параметров:
1. Назначение. Алгоритм размечает очередь исследований, ищет признаки на изображении, прогнозирует риск или формирует текст? Это разные классы риска.
2. Входные данные. Модель получает исходные изображения, структурированные поля, свободный текст или смешанный набор? Неполные входные данные меняют результат.
3. Валидация. Есть ли внешняя выборка, совпадающая с реальной популяцией региона и используемым оборудованием? Точность на тестовой выборке поставщика не переносится автоматически.
4. Порог срабатывания. Без него нельзя оценить баланс чувствительности, специфичности и ложноположительных результатов. «Точность 95%» без класса задачи и распределения случаев — рекламная цифра.
5. Маршрут ответственности. Кто получает сигнал, в какой срок, где фиксируется решение врача и что происходит при систематической ошибке алгоритма?
ИИ, который добавляет врачу ложноположительные находки, способен увеличить поток повторных исследований и тревожных маршрутизаций. ИИ, который пропускает редкие случаи, создаёт ложное чувство безопасности. Оба риска надо измерять на реальном процессе, а не компенсировать словами «решение носит рекомендательный характер».
Как измерять цифровую зрелость без презентационных метрик
План на 2026 год включает формирование отдельных статистических форм из первичных электронных медицинских документов в 25 субъектах РФ, ведение хронических пациентов в 89 субъектах и достижение 90% цифровой зрелости здравоохранения.
Это направление верное. Но термин «цифровая зрелость» слишком часто превращают в агрегат из подключений и отчётности. Для пациента и врача ценность возникает в более узких, проверяемых сценариях.
Минимальный аудит платформы должен проходить на сквозных маршрутах, а не на демонстрационном стенде:
- пациент записался к врачу, приём состоялся, запись попала в электронную карту;
- врач выдал направление, исследование выполнено, результат и изображения доступны в срок;
- пациента госпитализировали, выписку получил амбулаторный врач;
- хронический пациент передал измерения, система выделила отклонение, медицинская организация отреагировала;
- дистанционная консультация завершилась документом, который виден участникам лечения;
- сведения передаются в федеральный контур без дубликатов и некорректных статусов.
Для каждого маршрута требуются четыре числа: доля успешного завершения, медианное время, 95-й перцентиль задержки, доля ручных обходов. Последний показатель часто самый честный. Если сотрудники ежедневно звонят, сканируют бумагу, переносят результаты вручную или ведут параллельную таблицу, платформа не автоматизировала процесс. Она добавила ещё один интерфейс.
Нужна и выборочная сверка данных. Не «в системе есть миллион документов», а совпадают ли сведения в нескольких точках контура. Пациент, дата, диагноз, назначение, результат, подпись, статус. Даже небольшая, но корректно отобранная выборка выявляет дефекты лучше, чем общий счётчик записей.
Вердикт
Сравнение трёх конкретных региональных платформ сейчас не имеет доказательной базы: нет подтверждённого единого теста, перечня участников и опубликованных результатов. Вердикт по заявленному «тесту трёх платформ» — нет, делать выводы о победителе нельзя.
Сравнивать нужно не бренды и не число цифровых сервисов. Рабочая региональная платформа проходит сквозной маршрут без потери документа, ручного дубляжа и недоступности данных врачу. Она фиксирует телемедицинскую консультацию в основной медицинской документации. Она отделяет зарегистрированное медицинское ПО с ИИ от обычного IT-инструмента. Она показывает измеримые задержки и ошибки, а не только количество подключений.
Если этих данных нет, проект цифровое здравоохранение остаётся планом цифровизации. Не доказанным результатом.
