ЕГИСЗ не работает сегодня: спокойный регламент клиники на первые 60 минут

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

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

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

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

До сбоя: пять решений, которые нельзя принимать в очереди

Аварийный регламент пишут в спокойный день. Иначе в него попадут решения, которые команда уже принимает под давлением.

Заранее определите:

1. Кто имеет право объявить резервный режим.
2. Какие процессы можно временно продолжать, какие — ограничить, а какие — остановить.
3. Где ведётся контролируемая очередь неподтверждённых операций.
4. Кто и каким текстом сообщает статус сотрудникам и пациентам.
5. Кто разрешает возврат в обычный режим и сверяет накопившиеся записи.

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

Сначала выясните, что именно «не работает»

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

Сбой может затронуть:

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

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

0–10 минут: остановить хаотичные изменения

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

Минимальный первый пакет фактов:

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

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

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

10–20 минут: определить радиус сбоя

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

Не используйте публичный сайт статусов как единственное доказательство: он может обновляться с задержкой. Но и локальная ошибка не доказывает внешний сбой. Формулируйте статус честно: «подтверждена недоступность отправки такого-то типа из двух рабочих мест», а не «ЕГИСЗ упала по всей стране».

20–30 минут: включить только утверждённый резервный сценарий

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

Для каждого процесса заранее выберите один из вариантов:

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

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

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

30–40 минут: сообщить один проверенный статус

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

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

Пример внутреннего текста:

Подтверждена задержка внешнего статуса для документов типа X. Документы не отправляйте повторно без команды координатора. Новые случаи фиксируйте по форме Y с техническим ID, без медицинского содержимого. Приём ведётся по утверждённому сценарию Z. Следующее обновление — в 11:20.

Это не универсальный шаблон для публикации. Он показывает структуру: факт, граница, действие, запрет, следующий контакт.

40–50 минут: подготовить качественную эскалацию

Заявка «ничего не работает» заставляет поставщика начинать расследование с нуля. Качественная эскалация содержит:

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

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

50–60 минут: решить, что происходит дальше

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

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

Если этого нет, второй час начнётся с тех же вопросов и новых дублей.

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

В маленькой клинике один человек может совмещать несколько ролей. Но в журнале решения всё равно важно указать, в какой роли он действовал.

Пациенту нужен честный следующий шаг, а не архитектура

Пациенту не надо объяснять название федеральной подсистемы и код транспортной ошибки. Ему важно знать:

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

Безопасная формулировка не обещает то, что не подтверждено:

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

Конкретный текст должен соответствовать процессу и локальным правилам. Главное — клиника остаётся владельцем коммуникации, а не отправляет пациента самостоятельно разбираться с поставщиками.

Если инцидент начался после сентябрьского обновления, сначала сверьте область применимости и версии по аудиту МИС и ЕГИСЗ после 1 сентября 2026 года, а уже затем связывайте совпадение во времени с причиной.

Не вся недоступность одинакова

Полезно различать хотя бы четыре класса:

Локальное рабочее место

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

Система клиники

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

Региональный или федеральный обмен

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

Содержательный отказ

Инфраструктура работает, но конкретный документ не проходит проверку. Резервный сетевой канал не поможет; нужен разбор полей, роли, справочника или подписи.

Классы могут сочетаться. Их задача — направить следующий тест.

«ЕГИСЗ не работает» иногда означает «статус не обновился»

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

Перед повтором ответьте:

1. Есть ли идентификатор исходного сообщения?
2. Получен ли транспортный ответ?
3. Есть ли внешний регистрационный статус?
4. Может ли поставщик найти сообщение по correlation ID?
5. Повтор идемпотентен или создаст новый объект?
6. Изменился ли документ после первой отправки?

Для сложного маршрута изображений и документов полезна отдельная статья о пути КТ через PACS и ЕГИСЗ: она показывает, почему «есть в PACS» и «видно врачу» — разные подтверждения.

Контролируемая очередь вместо листка на мониторе

Очередь на восстановление должна пережить смену сотрудника и не разрастись в бесконтрольный реестр пациентов. Минимальная структура:

Доступ ограничивают, срок хранения задают заранее, а после восстановления список сверяют и закрывают. Нельзя оставлять его «на всякий случай» навсегда.

Восстановление: не открывайте шлюз полностью одним движением

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

Безопасная последовательность:

1. Подтвердить восстановление на одном синтетическом сценарии.
2. Проверить состояние локальной и внешней очереди.
3. Выделить операции с однозначно неподтверждённым статусом.
4. Обработать небольшую волну.
5. Сверить результаты и дубли.
6. Продолжить следующую волну.
7. Отдельно разобрать исключения.
8. Закрыть резервный список только после полной сверки.

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

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

Это учебная реконструкция без данных реальной клиники.

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

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

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

Сбой в этом сценарии не стал короче. Но клиника не умножила его последствия собственными действиями.

Что делать с расписанием во время сбоя

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

Резервный сценарий должен отвечать:

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

Техническая связка должности, ставки, услуги, интервала и слота разобрана в статье о расписании врачей в ЕГИСЗ. Во время инцидента особенно важно не исправлять массово справочники, пока не подтверждена причина.

Если сбой совпал с обновлением

Недавнее обновление повышает вероятность локальной причины, но не доказывает её. Зафиксируйте:

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

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

Канал связи на случай недоступности основных систем

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

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

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

Что записывать в журнал инцидента

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

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

Как понять, что инцидент завершён

Сайт открылся и один документ ушёл — недостаточно. Критерии закрытия:

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

Если причина осталась неизвестной, это честно отмечают. «Восстановилось само» не является корневой причиной и не позволяет предотвратить повтор.

Разбор после сбоя без поиска виноватого

Короткий разбор отвечает на пять вопросов:

1. Как команда заметила проблему?
2. Что увеличило или уменьшило последствия?
3. Какие данные и статусы отсутствовали?
4. Где инструкция расходилась с реальной работой?
5. Какое одно изменение проверим до следующей даты?

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

Метрики, которые действительно помогают

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

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

Учение без остановки реального приёма

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

Проверьте:

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

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

Чек-лист первых 60 минут

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

Красные флаги аварийного процесса

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

FAQ

Можно ли продолжать приём, если обмен с ЕГИСЗ недоступен?

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

Где хранить временную очередь?

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

Когда можно повторить отправку?

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

Кто сообщает пациентам?

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

Нужно ли менять МИС из-за одного сбоя?

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

Почему час, если сбой может длиться дольше?

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

Источники и ограничения

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

NIST SP 800‑34 Rev. 1 используется здесь как методический источник по планированию непрерывности, включая альтернативную обработку и восстановление. Это не российское нормативное требование к медицинской организации.

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

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

Не ждите настоящего сбоя. Соберите врача, администратора, IT и руководителя процесса на двадцать минут. Дайте им одну карточку: «Внешний ответ не приходит, в очереди три неподтверждённых документа, пациент спрашивает статус».

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

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