После 1 сентября: что проверить в обмене МИС и ЕГИСЗ, пока уведомления не превратились в проблему

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

Первое предупреждение в МИС редко выглядит как начало большой проблемы. Жёлтая строка, новый обязательный реквизит, документ в статусе «ожидает» — сотрудник закрывает окно и продолжает приём. Через несколько дней таких строк становится больше. Затем клиника обнаруживает, что у одного врача документы уходят, у другого возвращаются, а поставщик просит прислать примеры, которых никто не собирал.

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

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

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

Начните не с ЕГИСЗ, а с области применимости

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

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

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

Почему нельзя делать одну памятку «все изменения сентября»

Универсальная памятка быстро теряет связь с реальностью. В неё попадают обязанности, которые не относятся к профилю клиники, и пропадают локальные зависимости: конкретная версия МИС, региональный шлюз, используемый шаблон, доступная роль, порядок подписи.

Полезнее создать три слоя:

1. Реестр официальных изменений — номер, дата, источник, вступление в силу, область применения.
2. Карта затронутых процессов клиники — услуга, подразделение, документ, роль, система.
3. План технической и операционной проверки — сценарий, ожидаемый статус, ошибка, откат.

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

«Мы отправляем» — недостаточный ответ

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

Составьте лестницу статусов для каждого важного типа документа:

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

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

Разберите первое предупреждение до того, как оно станет фоном

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

Создайте простой журнал предупреждений:

Главный вопрос: предупреждение информирует или маскирует будущий отказ? Ответ получают не по цвету окна, а по конечному статусу тестового документа и разъяснению поставщика.

Разделите содержательную и техническую ошибки

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

Удобная классификация:

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

Справочники меняются тише, чем интерфейсы

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

Для каждого критичного справочника зафиксируйте:

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

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

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

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

Минимальные сценарии:

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

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

Один синтетический документ ценнее ста скриншотов

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

Карточка теста:

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

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

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

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

После обновления МИС у части врачей появляется предупреждение о несопоставленной роли. Документ при этом можно завершить. Врачи нажимают «продолжить», потому что приём не должен останавливаться. Первые дни внешняя проверка принимает часть сообщений, и проблема кажется косметической.

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

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

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

Проверьте очередь, даже если жалоб пока нет

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

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

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

Не путайте обновление МИС и обновление процесса

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

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

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

Что запросить у поставщика МИС

1. Точную версию, поддерживающую нужный профиль или форму.
2. Ссылку на официальное основание и документацию релиза.
3. Перечень изменённых полей, правил и справочников.
4. Требования к ролям и электронной подписи.
5. Схему статусов от локального сохранения до внешнего ответа.
6. Поведение при временной недоступности.
7. Правило повторной отправки и защиты от дублей.
8. Способ найти зависший документ.
9. Порядок исправления уже созданных документов.
10. Тестовый контур или утверждённый синтетический сценарий.
11. Известные ограничения текущей версии.
12. План обновления и возврата.

Ответ «всё автоматически» должен раскрываться до проверяемых действий. Автоматически — когда, чем подтверждено, где увидеть ошибку и что делает человек, если автоматический шаг не состоялся?

Что проверить на рабочих местах врача и регистратора

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

Попросите врача и регистратора независимо выполнить разрешённый тест и ответить:

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

Расхождение ответов — готовый план обучения и доработки интерфейса.

Расписание и электронные документы проверяются разными маршрутами

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

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

Рентгенология: обновление формы не равно автоматической готовности кабинета

Официальная образовательная платформа Минздрава указывает, что новые правила проведения рентгенологических исследований и унифицированная форма протокола начали действовать с 1 сентября 2026 года. Для клиники это повод проверить область применимости, шаблоны, роли, оборудование и маршрут результата — но не основание переписывать настройки по краткому пересказу новости.

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

Изменения для отдельных категорий нельзя переносить на всех пациентов

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

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

Регламент ошибки должен начинаться до звонка поставщику

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

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

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

Повторная отправка требует правила, а не смелости

Перед повтором выясните, был ли документ окончательно отклонён или ответ потерялся. Используется ли тот же идентификатор? Создастся ли новая версия? Распознает ли получатель дубль? Какая запись станет основной?

В регламенте должны быть:

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

Кнопка повторной отправки без этих ответов — источник новых расхождений.

Откат нужен даже для «маленького» обновления справочника

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

Полезная карточка изменения:

Проверка восстановления конфигураций и данных дополняется общим материалом о реальном тесте резервной копии клиники. Резерв «есть» только после понятного восстановления.

Красные флаги после обновления

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

Красный флаг — не приговор. Он указывает, где клинике не хватает доказательства.

Чек-лист руководителя клиники

• [ ] Собран реестр официальных изменений с источниками.
• [ ] Для каждого пункта подтверждена применимость.
• [ ] Назначены медицинский, юридический и технический владельцы.
• [ ] Затронутые процессы связаны с подразделениями и системами.
• [ ] Поставщик указал поддерживающую версию и ограничения.
• [ ] Шаблоны и обязательные поля сопоставлены с требованиями.
• [ ] Справочники имеют версии и владельцев.
• [ ] Роли и подписи проверены на конкретных документах.
• [ ] Есть синтетические сценарии без данных пациента.
• [ ] Статусы расшифрованы по этапам.
• [ ] Очереди и долгие ожидания наблюдаются.
• [ ] Предупреждения не закрываются без разбора.
• [ ] Повторная отправка защищена от дублей.
• [ ] Регистратура и врач знают маршрут эскалации.
• [ ] Изменения применяются волнами.
• [ ] Для каждой волны есть стоп-условие и откат.
• [ ] После релиза назначена повторная проверка.

Метрики, которые показывают процесс, а не красивый отчёт

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

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

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

План на десять рабочих дней

Дни 1–2: область применимости

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

Дни 3–4: карта процессов

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

Дни 5–6: тесты

Пройдите синтетические сценарии: успешный, с предупреждением, с контролируемой ошибкой и повтором.

Дни 7–8: исправления волной

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

Дни 9–10: закрепление

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

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

FAQ

Нужно ли после 1 сентября 2026 года переписывать все процессы клиники?

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

Достаточно ли обновить МИС до последней версии?

Нет. Версию нужно дополнить настройкой справочников и ролей, проверкой подписи, сквозным тестом, обучением сотрудников, наблюдением очередей и планом отката.

Как понять, что предупреждение можно временно принять?

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

Кто решает, техническая ошибка или медицинская?

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

Можно ли обещать, что после аудита предупреждений больше не будет?

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

Как доказать, что обмен работает?

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

На какие официальные материалы опираться

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

Архитектурную роль государственных подсистем стоит сверять с официальным каталогом подсистем ЕГИСЗ, а назначение документов — со страницей Федерального реестра электронных медицинских документов.

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

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

Откройте не МИС, а пустую таблицу. В первую колонку внесите пять изменений, которые сотрудники связывают с 1 сентября. Во вторую — официальный источник. В третью — конкретный процесс клиники. Если источник или процесс не удаётся назвать, пометьте строку «уточнить», не превращая её в срочное изменение.

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

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