КТ онлайн в ЕГИСЗ: почему исследование иногда не доходит до врача и пациента

• Опубликовано: 20 сентября 2026 г.

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

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

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

Сначала разделим то, что в разговоре называют «КТ»

У диагностического исследования есть несколько связанных, но не тождественных сущностей.

Архитектура конкретной клиники может отличаться. Где-то РИС встроена в PACS, где-то заключение оформляется в МИС, где-то обмен идёт через региональную систему. Таблица не заменяет интеграционную документацию. Она нужна, чтобы не объединять разные факты в одно неточное «исследование отправлено».

PACS не равен ЕГИСЗ, а ЕГИСЗ не равен просмотровщику

PACS отвечает за работу с медицинскими изображениями и связанными объектами в своей архитектуре. ЕГИСЗ — более широкий государственный информационный контур с несколькими подсистемами. На официальном сайте Минздрава отдельно описаны Федеральная интегрированная электронная медицинская карта и Федеральный реестр электронных медицинских документов. Уже это разделение показывает, почему нельзя говорить о «загрузке КТ в ЕГИСЗ» как об одном универсальном действии.

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

Поэтому перед разбором инцидента зафиксируйте, что именно должно появиться в конечной точке:

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

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

Один маршрут — несколько независимых идентификаторов

Аппарат, PACS, МИС, интеграционный шлюз и внешний сервис могут присвоить одному эпизоду разные идентификаторы. Дополнительно есть идентификаторы пациента, направления, серии, экземпляра документа, версии и сообщения обмена. Если сотрудник приносит в поддержку только фамилию и время приёма, поиск становится медленным и рискованным. Если приносит только внутренний номер PACS, поставщик другого звена не узнает его.

Для тестовой трассировки полезна безопасная таблица соответствий:

Названия полей зависят от продукта. В рабочий тикет не следует без необходимости копировать ФИО, диагноз, изображение, заключение или другие медицинские сведения. Для теста используйте предусмотренные поставщиком синтетические данные и безопасные идентификаторы.

Где чаще всего возникает разрыв

Сбой может появиться ещё до аппарата. Направление создано на другую услугу, пациент сопоставлен неверно, рабочий список не обновился. Исследование выполнено, но осталось в локальном буфере. Изображения приняты PACS, а заключение не подписано. Документ подписан, но сформирован по неподдерживаемому профилю. Пакет ушёл в очередь, однако внешняя сторона его отклонила. Ответ получен, но локальный статус не обновился. Наконец, всё обработано, а врач не видит результат из‑за фильтра, роли или задержки индексации.

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

Начните с конечного ожидания. Что должен увидеть врач или пациент? В каком интерфейсе? К какому моменту? Затем двигайтесь назад и на каждом шаге ищите не предположение, а подтверждение: запись, статус, временную метку, ответ сервиса.

Зелёный статус бывает локальным

Надпись «успешно» может означать разные вещи:

• файл записан на локальный диск;
• объект принят PACS;
• сообщение помещено во внутреннюю очередь;
• транспорт доставил запрос следующему сервису;
• внешний сервис технически принял пакет;
• документ прошёл содержательную проверку;
• запись стала доступна пользователю.

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

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

Изображение и заключение могут прийти в разное время

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

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

Для клиники полезно развести минимум четыре времени:

1. исследование выполнено;
2. изображения сохранены в целевом архиве;
3. заключение подписано;
4. результат подтверждён в конечном канале.

Разница между ними показывает, где образуется задержка. Среднее время «от приёма до результата» скрывает детали и часто направляет улучшение не в тот участок.

Подпись — не декоративная кнопка

В электронном медицинском документообороте важны автор, роль, версия документа, статус и применимый механизм электронной подписи. Если документ создан, но не подписан ожидаемым образом, следующий этап может быть недоступен. Если после подписания текст изменили, появляется новая версия и вопрос, какая из них отправлена и отображается.

Не превращайте регистратуру в техническую поддержку подписи. Сотруднику нужна короткая диагностика: документ создан? кто должен подписать? подпись выполнена? версия актуальна? есть ли понятная ошибка? Дальше инцидент уходит владельцу соответствующего звена.

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

Очередь обмена — место, где ошибка умеет ждать

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

Для каждой очереди должны быть понятны:

• текущая глубина;
• возраст самого старого сообщения;
• доля повторных попыток;
• причины окончательных отказов;
• правило автоматического повтора;
• момент, когда требуется человек;
• способ безопасно сопоставить сообщение с исходным событием;
• защита от создания дубля.

Одна из самых полезных метрик — не общее число ошибок, а возраст необработанного сообщения. Десять новых временных отказов могут исправиться автоматически, а один пакет, который лежит трое суток, уже требует внимания.

Повторная отправка: сначала выяснить идемпотентность

Кнопка «Отправить ещё раз» успокаивает, но может создать дубли или новую версию, которую трудно сопоставить со старой. Перед повтором нужно понять:

• использует ли система тот же идентификатор сообщения;
• распознаёт ли получатель повтор;
• изменился ли документ после первой попытки;
• был ли первый запрос отклонён или только не получил подтверждения;
• кто и где увидит две записи;
• как отменяется ошибочная операция.

Если поставщик говорит, что повтор безопасен, попросите указать механизм и показать его на тестовом контуре. Слова «система сама разберётся» недостаточны для рабочего регламента. Те же вопросы стоит задавать ещё до закупки: материал о том, как выбрать поставщика томографа до договора, помогает проверить архив, сеть, сервис и восстановление как единый проект, а не как набор будущих сюрпризов.

Составной сценарий: всё принято, но врач не видит результат

Это учебная реконструкция, а не история конкретной клиники или пациента.

Тестовое исследование выполнено. PACS показывает все серии. Заключение подписано. Журнал шлюза содержит ответ о техническом приёме. Команда делает вывод: внешняя система должна показывать результат. Врач входит в привычный раздел и ничего не находит.

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

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

Смысл примера — не в конкретной причине. Он показывает, что транспортное подтверждение и пользовательская доступность — разные уровни качества.

Кто владеет маршрутом целиком

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

Роли можно распределить так:

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

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

Что должна знать регистратура

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

1. Уточнить, какой результат ожидается: заключение, изображения, ссылка или уведомление.
2. Проверить согласованный статус в доступном интерфейсе.
3. Зафиксировать безопасный номер обращения и время.
4. Не обещать повторную отправку или срок, если статус не подтверждён.
5. Передать инцидент по правильному маршруту.
6. Сообщить пациенту, как клиника вернётся с ответом.

Фраза «у нас всё отправлено, звоните на портал» разрушает доверие, даже если технически часть работы выполнена. Пациент обращался в клинику, и ему нужен владелец коммуникации, а не экскурсия по архитектуре.

Что должен видеть врач

Врачебный интерфейс должен помогать отличать:

• исследование назначено;
• исследование выполнено;
• изображения доступны;
• описание начато;
• заключение подписано;
• документ передан;
• результат доступен в ожидаемом канале;
• возникла ошибка, требующая действия.

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

Что должен получить пациент

Пациенту не нужен correlation ID и название интеграционного шлюза. Ему нужны понятные ответы:

• результат готов или ещё обрабатывается;
• где его открыть;
• что именно доступно;
• к кому обратиться, если не открывается;
• требуется ли дополнительное действие;
• когда клиника вернётся с ответом по инциденту.

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

Сеть может быть причиной, но не следует начинать с неё автоматически

Если аппарат периодически теряет соединение с архивом, причина может быть в кабеле, VLAN, DNS, времени, перегрузке, политике межсетевого экрана или настройках приложения. Но если все серии стабильно приходят в PACS, а документ отклоняется на содержательной проверке, перестройка сети не поможет.

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

Почему хранить всё на рабочей станции опасно для маршрута

Иногда кабинет считает локальный диск аппарата или рабочей станции архивом: «снимки же открываются». Но доступность на одном компьютере не подтверждает сохранение в целевом PACS, резервирование, управление сроками хранения или возможность восстановления после отказа.

Локальная рабочая копия может быть частью технологического процесса, но не должна незаметно становиться единственным источником результата. Более подробно границы рабочей станции, PACS, архива и копии разобраны в статье «Почему нельзя хранить все исследования КТ на одном компьютере».

Приёмочный тест до запуска интеграции

Хорошая приёмка включает не один счастливый сценарий, а набор заранее подготовленных проверок:

1. Корректное тестовое направление и исследование.
2. Исправление допустимой ошибки до подписания.
3. Повторная серия или дополнение исследования.
4. Временная недоступность следующего сервиса.
5. Отклонение из‑за контролируемой ошибки данных.
6. Повтор после восстановления связи.
7. Проверка защиты от дубля.
8. Проверка роли и видимости результата.
9. Проверка ссылки или канала пациента, если он входит в объём проекта.
10. Восстановление после перезапуска очереди или шлюза.

Для каждого сценария заранее задаются ожидаемые статусы и места их просмотра. Тестовые данные готовят по правилам поставщика; реальные данные пациентов для удобства использовать нельзя.

Минимальный журнал сквозной трассировки

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

Минимальные поля:

• безопасный ID тестового сценария;
• тип события;
• локальный технический идентификатор;
• время с указанием часового пояса или согласованной шкалы;
• система-источник;
• система-получатель;
• статус и код ответа;
• номер версии документа;
• владелец следующего действия;
• ссылка на заявку без вставки содержимого документа.

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

Время на системах должно совпадать

Трассировка рассыпается, если аппарат, PACS, МИС и шлюз живут с разным временем. Сообщение может выглядеть так, будто ответ пришёл до запроса. Инженеры начинают строить неверные гипотезы, а аудит последовательности событий становится ненадёжным.

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

Регламент на случай недоступности обмена

Сбой внешнего сервиса не должен заставлять персонал импровизировать с медицинским процессом. В регламенте нужны ответы:

• как подтверждается недоступность;
• кто объявляет резервный режим;
• какие действия продолжаются локально;
• что нельзя делать вручную;
• как фиксируется очередь невыполненного обмена;
• кто контролирует повтор после восстановления;
• как обнаруживаются дубли;
• кто сообщает статус врачу и пациенту;
• когда инцидент эскалируется поставщику.

Отдельный материал о регламенте клиники при недоступности ЕГИСЗ дополняет эту схему. Важно лишь не копировать условный «план на 60 минут» без адаптации: реальные допустимые действия и сроки зависят от системы и процесса.

Как разговаривать с поставщиком без фразы «у нас ничего не работает»

Качественная заявка содержит:

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

Не прикладывайте к заявке полный снимок или документ, если поставщику достаточно технического ID. Если чувствительные данные действительно необходимы для поддержки, используйте утверждённый канал и минимальный объём.

Полезные вопросы поставщику:

1. Какой статус подтверждает только локальную очередь, а какой — внешний приём?
2. Где увидеть исходный код и текст отказа?
3. Как система ведёт версии и повторы?
4. Как обнаруживается зависшее сообщение?
5. Как связать внешний ответ с локальным исследованием без ФИО?
6. Какие действия сотрудник может выполнить сам, а какие требуют поддержки?
7. Как проверяется пользовательская видимость результата?
8. Что сохраняется при недоступности интеграции?

Красные флаги в проекте

• весь маршрут описан одной стрелкой «PACS → ЕГИСЗ»;
• никто не различает изображения, заключение и электронный документ;
• зелёный статус не расшифрован;
• очередь ошибок не имеет владельца;
• повтор выполняют вручную без проверки дублей;
• для поиска инцидента требуют переслать полный медицинский документ в мессенджер;
• часы систем расходятся;
• приёмка ограничена одним успешным исследованием;
• тестируют на реальном пациенте, потому что синтетического сценария нет;
• права врача и пациента не включены в проверку;
• все поставщики подтверждают свой участок, но нет владельца сквозного результата;
• локальный компьютер кабинета считается единственным архивом;
• после обновления интеграции нет плана возврата;
• регистратура обещает сроки по неподтверждённому статусу.

Один красный флаг не доказывает неисправность. Несколько вместе показывают, что клиника зависит от удачи и личной памяти сотрудников.

Чек-лист одного тестового исследования

• [ ] Использованы разрешённые синтетические или обезличенные данные.
• [ ] Заранее определено, что должно появиться в конечном интерфейсе.
• [ ] Направление создано и найдено кабинетом.
• [ ] Исследование связано с правильным тестовым субъектом и назначением.
• [ ] Все ожидаемые серии сохранены в целевом PACS.
• [ ] Изображения открываются на разрешённой рабочей станции.
• [ ] Заключение имеет правильный статус и версию.
• [ ] Электронный документ сформирован по актуальному профилю.
• [ ] Подписание подтверждено применимым способом.
• [ ] Сообщение имеет корреляционный идентификатор.
• [ ] Внешний ответ сохранён и понятен.
• [ ] Повтор не создаёт неконтролируемый дубль.
• [ ] Врач видит результат под корректной ролью.
• [ ] Пациентский канал проверен, если входит в сценарий.
• [ ] Ошибка отображается понятным действием, а не только кодом.
• [ ] Журнал не содержит лишних медицинских данных.
• [ ] У каждой ошибки есть владелец следующего шага.

Как измерять маршрут, не подменяя качество цифрой

Полезные показатели:

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

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

План улучшения на четыре недели

Неделя 1: договориться о языке

Опишите сущности, статусы и конечные ожидания. Выберите один тестовый тип исследования. Назначьте владельца сквозного маршрута.

Неделя 2: собрать трассировку

Свяжите идентификаторы и журналы. Уберите из рабочих тикетов избыточные медицинские данные. Синхронизируйте время систем.

Неделя 3: проверить исключения

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

Неделя 4: закрепить наблюдаемость

Настройте обзор очередей, владельцев ошибок и минимальные метрики. Повторите тест после обновления или изменения конфигурации.

Такой план не обещает закончить всю интеграцию за месяц. Он создаёт воспроизводимый способ видеть и разбирать путь одного исследования.

FAQ

Почему исследование есть в PACS, но его не видно в ожидаемом интерфейсе ЕГИСЗ?

PACS подтверждает свой участок. Заключение или электронный документ могли быть не подписаны, не сформированы, отклонены, остаться в очереди либо быть недоступны конкретной роли. Нужно найти последнее подтверждённое событие и первое отсутствующее по связанным идентификаторам.

Передаются ли в ЕГИСЗ сами изображения КТ?

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

Можно ли просто нажать «отправить повторно»?

Только после понимания исходного статуса и механизма защиты от дублей. Если первый запрос принят, но подтверждение потеряно, новый пакет может создать нежелательную запись или версию.

Нужно ли давать пациенту прямой доступ к PACS?

Не автоматически. Пациентский доступ должен быть отдельным контролируемым сценарием с аутентификацией, ограничением раскрытия, сроком и поддержкой. Техническая ссылка сама по себе не является готовым сервисом.

Кто отвечает за весь путь исследования?

Нужен владелец сквозного процесса, но он не заменяет владельцев звеньев. Кабинет, врач, IT, поставщики и ответственная медицинская роль сохраняют свои полномочия; координатор не даёт инциденту потеряться между ними.

Как тестировать без данных пациента?

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

Официальная основа и границы материала

Минздрав описывает Федеральный реестр электронных медицинских документов как отдельную подсистему ЕГИСЗ со сведениями об электронной медицинской документации и медицинской организации, где она создана и хранится. Федеральная интегрированная электронная медицинская карта также описана как отдельная подсистема с собственным назначением. Каталог подсистем ЕГИСЗ помогает увидеть, что государственный контур не является одним «облачным диском».

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

Что сделать завтра

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

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

А если выяснится, что изображения по-прежнему живут только на рабочем компьютере кабинета, это уже не вопрос отображения в ЕГИСЗ. Это отдельный риск хранения, который нельзя закрыть повторной отправкой документа или ещё одним зелёным статусом.