Vidicap Connect: ward monitors and data transfer to the HIS

Vidicap Connect: мониторы отделений и передача данных в МИС

Vidicap Connect собирает данные мониторов пациента в отделениях вне операционных (реанимация, палаты интенсивной терапии, приёмное): к какой койке подключён монитор, на связи ли он, и пересылает его показатели и тревоги в МИС, ЛИС или архив центральной станции по HL7. На сервере больницы приём HL7 — только в составе Connect: мониторы операционных на сервер тоже идут через него (привязка к точке операционной, см. «Мониторы и наркозные аппараты (HL7)»). На самом Vidicap модуль «Показатели пациента (HL7)» работает и без Connect.

Что уже есть: приём данных, отделения, палаты и койки, экран палаты для врачей («Палаты»), кривые, палаты подчинённых серверов на главном и экспорт всех данных по HL7 на сервер МИС, ЛИС или архива: показатели, тревоги, события у койки и кривые с коек отделений, из операционных и с Vidicap, а также выгрузка архива за период. У каждого получателя настраивается, что именно он получает. Уведомления врачам в Telegram: дежурный врач получает сообщение, когда тревога монитора держится, монитор занятой койки молчит или началась гипотензия, с кнопкой «Принял» и эскалацией. Доп. модуль «Запись кривых»: кривые мониторов пишутся целиком с перемоткой на странице койки. Доп. модуль «ИИ: оценка состояния»: риск ухудшения 0–100 по каждой койке раз в минуту, «почему» и совет, отметки врачей, версии модели в тени (статус «исследование»). Доп. модуль «Протоколы (Приказ 254)»: протокол анестезии (открывается сам со стартом записи операции на Vidicap), суточный лист интенсивной терапии, осмотр анестезиолога и транспортировка заполняются с монитора, этапы и препараты — кнопками с телефона или с экрана Vidicap, печать по форме бланка. RS-232 появится следующим этапом.

Как это работает

1. Монитор (или центральная станция Mindray eGateway) сам подключается к Connect по сети, порт 2575 (HL7, MLLP), и раз в 10–60 секунд присылает показатели, а тревоги сразу.
2. Новый монитор появляется в разделе «Новые устройства». Администратор привязывает его к койке. Пока монитор не привязан, его данные никуда не уходят.
3. Данные Connect отправляет получателям (МИС, ЛИС, архив) так, как каждый из них настроен: откуда (койки отделений, мониторы операционных, Vidicap), какие отделения, что (показатели, тревоги, события, кривые), какие показатели, как часто, с данными пациента или без.
4. У каждого получателя своя очередь на диске. Если получатель недоступен или не принимает сообщение, Connect повторяет через 30 с, 1 мин, 5 мин, затем каждые 15 мин. Сообщения ждут до 7 дней и уходят по порядку, когда связь вернётся.

Установка

Connect ставится тем же установщиком, что и сервер больницы (см. «Сервер платформы»): ./up.sh local. При первом запуске он спрашивает, что ставить на этот компьютер:

Что ставим на этот компьютер?
  1) Сервер больницы: трансляции, архив, операционные (без HL7)
  2) Сервер больницы + Vidicap Connect: всё, HL7 операционных и отделений
  3) Только Vidicap Connect: отдельный компьютер для отделений
Выберите 1–3 [2]:

• Без вопроса: ./up.sh local --config 3. Без терминала (например, из скрипта) выбирается 2.
• Поменять потом, данные сохраняются: ./up.sh config (или ./up.sh config 2).
• С Connect установщик открывает порт 2575 в брандмауэре ufw, если он включён и установщик запущен через sudo; иначе напоминает открыть порт.
• В конфигурации 3 в главном меню только Vidicap Connect, организации, сервисное меню, настройки и помощь: трансляций и архива нет.
• Текущая конфигурация видна в Connect → «Настройки».
• HL7 на сервере больницы работает только с Connect (конфигурации 2 и 3). На самих Vidicap HL7 остаётся в базе.
• Компьютер Connect подключается к главному серверу больницы как подчинённый: Сервисное меню → «Подключение сверху», см. «Связь серверов».

Выбор записывается в файл .env строкой VIDICAP_ROLES. Остальные настройки HL7 там же:

VIDICAP_ROLES=connect             # 3: только Connect; 2: platform,connect; 1: platform
VIDICAP_HL7_PORT=2575
VIDICAP_HL7_ALLOWED=10.0.8.0/24   # сеть мониторов (пусто — с любых адресов)
VIDICAP_CONNECT_QUEUE_DAYS=7      # сколько дней хранить очередь недоступного получателя

После правки .env вручную: docker compose up -d. Приём HL7 и отправка получателям идут в службе hl7.

Требования к сети:

• Постоянный IP компьютера Connect. Мониторы хранят его в своих настройках: попросите ИТ-службу закрепить адрес.
• Доступ из сети мониторов на этот IP по TCP-порту 2575.
• Доступ от Connect к получателям: к МИС по её адресу и порту HL7 (уточните у ИТ-службы или поставщика МИС).

Рекомендуемый компьютер для отделений до 200 мониторов: безвентиляторный, Core i5 12–13 поколения, 32 ГБ памяти, NVMe 2 ТБ, две сетевые карты 2,5 Гбит/с.

Вход и главный экран

Connect открывает администратор организации (или администратор платформы). В главном меню появляется плитка «Vidicap Connect». Если что-то требует внимания (получатель недоступен, монитор молчит), на плитке написано «Проблем: N».

Шаг 1. Название и организация

Откройте «Vidicap Connect» → «Настройки».

1. Название этого Connect — например «Vidicap Connect · Корпус 2». Оно видно в заголовке страниц.
2. Организация — больница, чьи отделения обслуживает Connect. Если организация на сервере одна, она выбрана сама.
3. Нажмите «Сохранить».

Ниже на этой странице указан адрес и порт, который нужно ввести в мониторах.

Шаг 2. Отделения, палаты и койки

Откройте «Отделения и койки».

1. Внизу страницы впишите название отделения (например «ОРИТ») и нажмите «+ Отделение». Отделения — общие с платформой (справочник организации).
2. В карточке отделения впишите название палаты и нажмите «+ Палата». Номер следующей палаты подставляется сам.
3. В палате нажмите «+ Койка» столько раз, сколько в ней коек. Номер следующей койки тоже подставляется сам.

Переименовать или удалить палату и койку можно по ссылкам «изменить» и «изменить палату». Удалить можно только пустую койку (без устройств) и пустую палату (без коек).

Шаг 3. Настроить мониторы

На каждом мониторе Mindray (меню обслуживания, раздел сети / HL7, пароль техобслуживания) укажите:

• адрес сервера HL7 — IP компьютера Connect (он написан на странице «Отделения и койки» и в «Настройках»);
• порт 2575;
• передачу результатов (показатели) и тревог включить;
• место монитора: отделение, палата, койка (например ICU, 1, 5). По месту Connect сам предложит нужную койку.

Если мониторы уже отправляют данные на центральную станцию Mindray, проще настроить на ней eGateway: одна станция передаёт данные всех своих коек по одному соединению. Подробно про настройку Mindray — в инструкции «Мониторы и наркозные аппараты (HL7)».

Шаг 4. Привязать мониторы к койкам

Монитор, приславший данные, появляется в разделе «Новые устройства» с текущими значениями (ЧСС, SpO₂, давление), чтобы его было легко узнать.

Один монитор:

1. Впишите понятное название, например «Монитор N12» (необязательно).
2. Выберите койку. Если на мониторе задано место, Connect предлагает койку сам: «предложено по месту ICU 1 6».
3. Нажмите «Привязать». С этой минуты его данные уходят получателям.

Центральная станция (eGateway): все её койки показаны одной строкой «MINDRAY_EGATEWAY · коек: N».

1. Выберите палату. Connect предлагает её по номеру из места на станции.
2. Нажмите «Привязать все N». Каждый монитор встанет на койку с тем же номером; недостающие койки создаются сами.
3. Чтобы привязать койки станции к разным палатам, откройте «По одной…».

Устройство, которое не нужно (тестовое, не медицинское), можно «Скрыть»; скрытые показаны внизу страницы, их можно вернуть.

На карточке койки видно, на связи ли монитор: зелёная точка — да, «молчит N мин» — данных нет дольше двух минут. Отвязать монитор — ссылка «отвязать» (он снова появится в новых).

Шаг 5. Добавить получателя (МИС, ЛИС, архив)

Откройте «Получатели» → «+ Добавить получателя».

1. Название — например «МИС больницы».
2. Способ отправки — HL7 по сети (MLLP). Отправка в JSON, XML, FHIR и файлами будет на следующем этапе.
3. Адрес и порт — куда МИС принимает сообщения HL7 (дают ИТ-служба или поставщик МИС).
4. Откуда — отметьте, чьи данные получатель получает: - Койки отделений — мониторы, привязанные к койкам Connect (шаг 4); - Операционные: мониторы, подключённые к серверу — мониторы и наркозные аппараты, которые шлют HL7 прямо на этот сервер и привязаны к точке операционной (см. «Мониторы и наркозные аппараты (HL7)», вариант 2); - Операционные: мониторы через Vidicap — мониторы, подключённые к Vidicap с модулем «Показатели пациента», если этот Vidicap подключён к серверу больницы. Vidicap передаёт значения и тревоги без данных пациента, поэтому и получатель их получит без ФИО.
5. Отделения — отметьте отделения коек и операционных. Ничего не отмечено — все отделения.
6. Что отправлять — любое сочетание: - Показатели — ЧСС, SpO₂, давление и другие значения (сообщения ORU^R01); - Тревоги — сразу, как пришли (ORU^R40); - События у койки — отметки врачей (интубация, вазопрессоры…), новый пациент на койке, эпизоды гипотензии, которые нашёл Connect. Только для коек отделений. Описание формата — ниже, «Как выглядят события в HL7»; - Кривые — ЭКГ, плетизмограмма, давление, дыхание в том виде, в каком их шлёт монитор (2 раза в секунду). Это много трафика: кривые идут только пока получатель на связи и не копятся в очереди на диске. Включайте их для центральной станции или системы, которая их показывает; МИС они обычно не нужны.
7. Какие показатели — «Все, что присылает монитор» или «Только выбранные»: например, только ЧСС, SpO₂ и среднее давление для научного архива. «Другие параметры» — всё, чего нет в списке (режим ИВЛ, газы, индекс перфузии). Тревоги уходят целиком, независимо от выбора.
8. Как часто отправлять показатели — раз в 5 минут (последнее значение), раз в минуту, раз в 15 минут или всё, что прислал монитор. МИС обычно хватает раз в 5–15 минут. Тревоги уходят всегда сразу.
9. Данные пациента в сообщениях: - Передавать как пришли от монитора — МИС нужны ФИО и номер истории, чтобы записать значения в карту пациента; - Вырезать — получатель видит только койку и значения (например, для научного архива).
10. Нажмите «Сохранить и проверить соединение»: Connect проверит, что получатель ждёт подключений по этому адресу, и сохранит его. Или просто «Сохранить».

Пример сообщения, которое уйдёт, — под ссылкой «Пример сообщения, которое уйдёт».

Изменить получателя — нажмите на его название в списке. Снимите флажок «Включён», чтобы временно остановить отправку (новые сообщения ему не копятся). «Удалить получателя» удаляет его вместе с очередью.

В списке под названием каждого получателя видно, что он получает: например «койки, операционные, Vidicap · показатели, тревоги, события · раз в 5 минут».

Выгрузка архива за период

Чтобы отправить получателю то, что уже накоплено (например, новой МИС за прошлую неделю), откройте получателя и внизу, в блоке «Выгрузка архива»:

1. Укажите «С» и «По» — начало и конец периода. Сервер хранит показатели 30 дней (VIDICAP_HL7_KEEP_DAYS).
2. Выберите, как часто брать показатели: раз в минуту, раз в 5 или 15 минут, раз в час (последнее значение каждого показателя за этот отрезок) или все сохранённые значения (одно в 15 секунд).
3. Нажмите «Выгрузить».

Уходит то, что отмечено у получателя: откуда, отделения, показатели, тревоги, события, выбранные показатели. Архивные сообщения идут после данных, которые приходят сейчас, и не задерживают их. Ход видно в таблице ниже: сколько сообщений сделано и сколько процентов периода; «Остановить» прекращает выгрузку и убирает из очереди то, что ещё не ушло.

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

Как выглядят события в HL7

Событие у койки уходит сообщением ORU^R01 с местом в PV1 и кодом события в OBX:

MSH|^~\&|VIDICAP_CONNECT|Vidicap Connect||||20261007142500||ORU^R01^ORU_R01|C26100714250000012|P|2.6
PID|||||Петров^Иван||19580312
PV1||I|ОРИТ^Палата 1^Койка 5
OBR|1|||EVENT^Bed event^VIDICAP|||20261007142300
OBX|1|CWE|EVENT^Event^VIDICAP|1|intubation^Интубация^VIDICAP||||||F|||20261007142300
OBX|2|ST|EVENT_SOURCE^Marked by^VIDICAP|1|doctor||||||F

• Коды событий: intubation, extubation, niv, vasopressor, vasopressor_stop, arrest, transfer, death, other (отмечает врач), hypotension и patient (находит Connect).
• Эпизод гипотензии уходит дважды: когда начался, и когда закончился (15 минут без низкого давления), во втором есть OBX|…|EVENT_END^End^VIDICAP|…|<время окончания>.
• Если врач удалил отметку, она уходит ещё раз с D в OBX-11 (удалено).
• PID — только у получателя с «Передавать как пришли от монитора», если монитор называл пациента; иначе PID нет.

Состояние: что видно на главной странице Connect

Страница «Состояние» обновляется сама каждые 5 секунд:

• Устройства на связи — сколько привязанных мониторов присылали данные за последние 2 минуты;
• Сообщений в минуту — от привязанных мониторов за прошлую минуту;
• Получатели — сколько работают и сколько недоступны;
• Ждут отправки — сообщения в очередях на диске;
• Диск — сколько занято.

В блоке «Требует внимания»:

• «МИС больницы: нет связи» — с какого времени, какая ошибка, адрес. Данные копятся в очереди. Проверьте, работает ли МИС и открыт ли сетевой доступ к ней;
• «ОРИТ · Палата 1 · Койка 4: монитор молчит 12 мин» — проверьте, что монитор включён и подключён к сети;
• «Неопознанные сообщения» — какое-то устройство присылает то, что не удалось разобрать. Откройте «Журнал»;
• «Новые устройства ждут привязки к койке» — привяжите их (шаг 4).

Ниже — получатели (сколько отправлено за час, сколько в очереди) и отделения (койки, устройства на связи, сообщений в минуту).

Экран палаты для врачей («Палаты»)

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

Кто видит. Врач отделения: в организации ему добавлено членство с этим отделением (администратор: «Организации» → организация → «Добавить сотрудника», поле «Отделение»). Администратор организации видит все палаты. Сотрудник без отделения палат не видит.

1. В главном меню нажмите плитку «Палаты». Если в палате есть высокая тревога, на плитке написано «Тревога: N».

2. Откроется первая палата вашего отделения. Другие палаты — кнопками сверху. Вверху справа счётчики: тревога, внимание, нет связи.

Плитка койки: - номер койки и пациент (фамилия и инициалы) — так, как их передаёт монитор; - ЧСС, SpO₂, АД (инвазивное, если есть, иначе НИАД), ЧД, температура; - зелёная линия — ЧСС за последний час; - красная мигающая рамка — высокая тревога монитора (PH), под цифрами её текст; - жёлтая рамка — средняя или низкая тревога (PM, PL); - серый пунктир — монитор не на связи больше 2 минут; - бледная плитка «нет монитора» — к койке ничего не привязано.

Койки в тревоге стоят первыми. Данные обновляются каждые 3 секунды, линия ЧСС — раз в минуту.

3. Нажмите на койку: откроется карточка койки — полное ФИО и возраст, крупные показатели, тренды за 1 час, 6 часов или сутки и тревоги за выбранный период. Наведите или нажмите на график, чтобы увидеть значения в это время.

4. На телефоне плитки идут в одну колонку, на плитке ЧСС, SpO₂ и АД.

Откуда ФИО. Монитор присылает пациента в каждом сообщении (сегмент PID). Connect запоминает его для экрана палаты. Если монитор 10 минут не присылает ФИО (пациента выписали, монитор очистили), имя с экрана пропадает. При перепривязке монитора к другой койке имя сбрасывается до следующего сообщения. Если на мониторе пациент не заведён, на плитке только номер койки.

Тренды. Показатели коек хранятся на компьютере Connect раз в 15 секунд, 30 дней (как у операционных). Тренды показываются с момента привязки монитора к этой койке.

NEWS2. Рядом с номером койки и в карточке — шкала NEWS2, посчитанная по правилам из текущих значений монитора: ЧД, SpO₂, систолическое АД, ЧСС, температура, кислород (если монитор передаёт FiO₂ больше 21 %). Сознания монитор не знает, поэтому оно не учитывается и считается «в сознании»: настоящая NEWS2 может быть выше. Без ЧД, SpO₂, АД и ЧСС шкала не показывается. Цвет: серый — низкий риск (0–4), светло-жёлтый — низкий, но один параметр дал 3 балла, жёлтый — средний (5–6), красный — высокий (7 и больше). В карточке видно, сколько баллов дал каждый параметр.

Кривые

В карточке койки, раздел «Кривые», — живые кривые монитора: ЭКГ, плетизмограмма (SpO₂), инвазивное давление, дыхание, капнограмма — все, что монитор передаёт. Справа от каждой кривой её цифра (ЧСС, SpO₂, ИАД, ЧД, EtCO₂). Кривая бежит слева направо и стирает старую, как на мониторе: 25 мм/с, дыхание и капнограмма — 6,25 мм/с. Кнопка «ЭКГ ×1» меняет усиление ЭКГ: ×0,5, ×1, ×2.

1. Что нужно. Монитор (или центральная станция, например Mindray через eGateway) должен передавать кривые по HL7. Обычно это отдельная настройка рядом с передачей цифр. Если кривых нет, в разделе написано «Монитор не присылает кривые»: цифры, тренды и тревоги при этом работают как раньше. Проверить без монитора можно имитатором: docker compose exec hl7 python manage.py hl7 send 127.0.0.1 --bed ICU-1 --waves.
2. Задержка. Монитор присылает кривые пакетами раз в 0,5–1 секунду, поэтому на экране они идут примерно на секунду позже, чем на мониторе. Это вспомогательный экран: решения по кривым принимают у монитора.
3. На плитках палаты. На экране палаты включите переключатель «Кривые на плитках» (вверху справа). На каждой плитке появится ЭКГ, а если монитор ЭКГ не передаёт — плетизмограмма. По умолчанию выключено; выбор запоминается в этом браузере.

4. Кривая тревоги. Многие мониторы вместе с тревогой присылают 6 секунд кривых до неё. В карточке койки, раздел «Тревоги», у такой тревоги есть ссылка «кривая»: нажмите, и под тревогой откроются эти секунды. Такие фрагменты хранятся вместе с тревогами 30 дней.

5. На телефоне кривые помещаются по ширине экрана, цифры — справа.

Где хранятся. Живые кривые нигде не сохраняются: они проходят через память компьютера Connect прямо в браузер (последние 20 секунд, только пока карточку или палату с кривыми кто-то смотрит). Сохраняются только фрагменты тревог. В облако vidicap.cloud кривые не передаются.

Для администратора. Кривые отдаёт служба hl7 по адресу /wave/stream (порт 8099 внутри сервера, Caddy проводит его наружу). Браузер получает пропуск на 5 минут только к мониторам коек, которые этому врачу видны, и сам его продлевает. Нагрузку проверяли на 200 мониторах, присылающих кривые 2 раза в секунду.

Запись кривых (доп. модуль)

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

Включить

1. Лицензия. Модуль выдаётся на vidicap.cloud на число коек (25, 50, 100, 200) и приходит на сервер больницы по связи с облаком, как остальные лицензии Connect (без интернета — тот же файл загружается вручную, см. «Связь серверов»). Сервер без лицензии работает без ограничений. Что в лицензии, видно на странице модуля: «до 50 коек · до 01.10.2027». Без модуля в лицензии или после её окончания включить запись нельзя; то, что уже записано, остаётся и открывается.
2. Страница модуля. Connect → «Настройки» → «Доп. модули» → «Запись кривых» (/connect/waves/, для администраторов организации). Переключатель «Запись включена», «Сколько дней хранить» (по умолчанию 30), «Какие кривые» (по умолчанию все). «Сохранить».

3. Какие койки пишутся. Все койки с привязанным монитором, в пределах лицензии: если мониторов больше, чем коек в лицензии, пишутся первые по порядку добавления, на странице модуля написано «38 из 50» и предупреждение. Отвязали монитор — запись койки остановилась, старые файлы хранятся свой срок.
4. Монитор должен присылать кривые по HL7 (та же настройка, что для живых кривых: «Send Waveforms» на мониторе или на eGateway). Койки, чьи мониторы кривых не шлют 10 минут, перечислены на странице модуля в «Койки без кривых».

Перемотка на странице койки

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

• Шкала суток внизу: красные метки — тревоги высокого приоритета, жёлтые — среднего, синяя чёрточка — смена пациента на койке, штриховка — записи нет (монитор не присылал кривые, был отвязан, запись была выключена). Нажмите на шкалу или потяните оранжевый курсор — кривые переносятся в это время; нажатие на метку тревоги переносит за 6 секунд до неё.
• Кнопки −1 ч · −10 с · Пуск/Пауза · +10 с · +1 ч; клавиши: пробел — пуск/пауза, стрелки ← → — ±10 с, с Shift — ±1 ч.
• Скорость ×1, ×4, ×16 — быстрее настоящего времени, чтобы пролистать час за 4 минуты.
• Развёртка 25 мм/с (как на мониторе), 12,5 и 50; дыхание и капнограмма, как в живом просмотре, в четыре раза медленнее.
• Сутки: ◀ ▶ или дата; при нажатии «−1 ч» в 00:30 открываются предыдущие сутки. Над кривыми — дата и время курсора с точностью до секунды; если в этот момент сработала тревога, её текст выделен оранжевым.
• «Живые кривые» возвращает к живому просмотру выше на той же странице.
• Тревоги за сутки под шкалой: время, тревога, значение и «▶ Открыть» — перемотка на 6 секунд до тревоги, запись сразу идёт, кривые прокручиваются на экран; рядом «🖨 полоса» — PDF этих 10 секунд (6 до тревоги и 4 после). «нет записи» — в этот момент кривые не писались (например, «нет связи с монитором»).
• «🖨 Распечатать полосу» и «💾 Сохранить фрагмент» — PDF и EDF+ от курсора, ниже.

Если модуль выключен, на странице койки вместо этого короткая карточка «Доп. модуль «Запись кривых» выключен» со ссылкой на страницу модуля. Отрывки 6 секунд при тревогах, которые присылает сам монитор, хранятся всегда и к модулю не относятся.

Распечатать полосу и сохранить фрагмент

1. Поставьте курсор на нужный момент: шкалой, кнопками ±10 с или «▶ Открыть» у тревоги.
2. «🖨 Распечатать полосу» открывает в новой вкладке PDF: лист A4 поперёк, 10 секунд при 25 мм/с с 6 секунд до курсора (курсор отмечен оранжевой чертой, как и момент тревоги при «полосе» из списка тревог), на миллиметровой сетке 1 мм / 5 мм (ЭКГ — 10 мм/мВ, остальные кривые растянуты по своему размаху, диапазон подписан), сверху отделение, палата, койка, дата и время, названия кривых (ECG II, Pleth, ART…), секунды по верхнему краю, тревоги этих секунд красным пунктиром, и надпись «для разбора, не для диагностики». ФИО на полосе нет. Печатайте в масштабе 100 % — тогда миллиметры совпадут с линейкой. Адрес: /connect/waves/<койка>/strip.pdf?at=<время> (at — начало полосы, ISO 8601 или unix-мс; codes=ecg_ii,pleth — только эти кривые; download=1 — сохранить файлом).
3. «💾 Сохранить фрагмент» раскрывает выбор: с какого времени (курсор), длительность 1, 5, 15 минут или час (не больше часа за раз) и, если на койке назван пациент, отметка «с данными пациента» (по умолчанию снята). «Скачать EDF+» сохраняет файл fragment-bed<N>-<дата>.edf: формат EDF+ (European Data Format) — его открывают EDFbrowser, LabChart, MATLAB, Python (mne, pyedflib), Kubios. В файле все записанные кривые койки с их частотой и единицами, пропуски записи — значение «−32768» (цифровой минимум, в программах видно как разрыв), тревоги отрезка — как аннотации EDF+ с временем. Поле пациента в заголовке — «X X X X»; с отметкой «с данными пациента» — ФИО и дата рождения латиницей, как требует формат. Адрес: /connect/waves/<койка>/fragment.edf?from=&to= (patient=1 — с данными пациента).

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

Открыть из уведомления

Когда модуль пишет койку, кнопка «Открыть койку» под сообщением бота о тревоге (см. «Уведомления врачам в Telegram») и «Открыть» push-уведомления приложения ведут на страницу койки с временем тревоги (?at=…): запись откроется за 6 секунд до тревоги и сразу пойдёт, кривые прокрутятся на экран — врач видит, что было перед тревогой, ещё до того, как дошёл до палаты. Уведомления о молчании монитора, гипотензии и риске ИИ открывают страницу, как раньше. Без модуля ?at= ничего не меняет: страница открывается как обычно.

Кривые по API и выгрузка пребывания

• GET /api/v1/beds/{id}/waves?from=&to=&codes=&format=json|edf (см. «API для МИС, ЛИС и других систем»): записанные кривые отрезка ключом с правом «чтение показателей и тревог». По умолчанию последняя минута, не больше часа за один запрос; без модуля в лицензии — 403. JSON: по каждой кривой частота rate, шаг resolution, единица и отсчёты int16 (null — отсчёт не пришёл; encoding=base64 — одной строкой, в несколько раз короче). format=edf — тот же файл EDF+, что «Сохранить фрагмент»; поле пациента «X X X X», с правом «данные пациента» — ФИО. Вызовы — в журнале API.
• Выгрузка пребывания целиком, обезличенно — для обучения моделей (aidata, «временные ряды»): на сервере Connect docker compose exec web python manage.py connect_waves_export --stay <ключ> --out /srv/vidicap/export Ключ пребывания stay — из событий койки (GET /api/v1/events, поле stay) или журнала. В папке <ключ>/ появятся файлы EDF+ по часам записи (2026-10-13_14.edf, пациент «X X X X», тревоги аннотациями) и points.json: тревоги и события у койки за пребывание (код, время, без фамилий), точки модуля «ИИ: оценка состояния» с входами и метками (1 — событие в следующие 6 часов), номер койки и ключ пребывания. ФИО, даты рождения и имён врачей в выгрузке нет; что из неё куда отдавать, решает учреждение — сама платформа в облако кривые не отправляет.

Запись воспроизводится в браузере: страница запрашивает 10-секундные куски на несколько секунд вперёд курсора (/wards/bed/N/rec/samples?at=…&seconds=10) и рисует их с выбранной скоростью; шкала суток приходит из /wards/bed/N/rec/index?day=…. Оба адреса доступны тем же, кому видна страница койки: врачам отделения и администраторам организации.

Хранение, диск, срок

• Где. Папка VIDICAP_WAVES_DIR (по умолчанию /srv/vidicap/waves на компьютере Connect, задаётся в .env; docker-compose подключает её в службы hl7 и web; папку создайте заранее и отдайте пользователю служб: sudo mkdir -p /srv/vidicap/waves && sudo chown 1000 /srv/vidicap/waves), внутри — по папке на койку и сутки, по файлу на час и кривую: <койка>/2026-10-13/14.ecg_ii.bin.gz. В файле короткий заголовок (код кривой, частота, разрешение, начало часа) и отсчёты int16, по одному на каждую 1/частота секунды от начала часа; пропуски заполнены меткой «нет отсчёта». Законченный час сжимается (gzip). В базе — только индекс часов (connect.WaveHour: койка, монитор, кривая, час, размер, пропуски); ФИО в файлах и индексе нет.
• Сколько. Монитор с ЭКГ 250 Гц, плетизмограммой и давлением по 125 Гц даёт около 1 МБ в час после сжатия, то есть ≈ 25 МБ в сутки; 50 мониторов за 30 дней — около 40 ГБ, 200 мониторов — около 150 ГБ (оценка; точная цифра на странице модуля: «В сутки сейчас» и «Хватит на»). Диск лучше отдельный или отдельный раздел: когда он заполняется, остальной сервер не страдает.
• Срок. Сутки старше «Сколько дней хранить» удаляются раз в 10 минут. Если свободного места на диске меньше 10 %, удаляются самые старые сутки записи (текущие сутки — никогда), пока места не станет достаточно, и инженерам уходит уведомление: запись «Инженерам» в журнале уведомлений Connect и сообщение бота в чат поддержки больницы (VIDICAP_TELEGRAM_CHAT_ID), если бот настроен. Когда место освободилось, уведомление закрывается само.
• Разборщик. Кривые пишет служба hl7 (та, что принимает мониторы): буфер в памяти по каждой кривой, сброс на диск раз в минуту. На странице модуля его цифры: отсчётов в секунду, нагрузка на процессор (доля одного ядра), потерянные пакеты (должно быть 0; растёт, если диск не успевает или изменилась частота кривой посреди часа), сколько кривых пишется. Если служба hl7 не пишет больше 3 минут, страница предупреждает.
• Пределы. До 200 мониторов с записью на один Connect (см. «Железо» в описании Connect); при перезапуске службы hl7 теряется не больше минуты записи (буфер). Часовой пояс файлов — пояс сервера (TZ).

Нагрузка и требования к серверу

Проверено скриптом scripts/connect_load_test.py (N симулированных мониторов Mindray: показатели раз в 1 с или раз в 10 с, кривые ЭКГ 250 Гц + плетизмограмма и ИАД по 125 Гц пакетами по 0,5 с, запись кривых и ИИ включены; прогоны по 90 с; подробные отчёты — в папке проекта connect/load-test/, сравнение с прежними цифрами — там же в до-после.md). Контейнер 4 ядра Xeon 2,1 ГГц, 16 ГБ, SQLite:

До правок (показатели — транзакция на каждое сообщение, тик ИИ — запрос и коммит на койку, кривые — по времени прихода) было: 100 мониторов раз в 1 с — 80–100 % отсчётов, p50 25–42 мс / p95 1–2 с, тик 12–65 с, 72–104 % ядра; 200 раз в 10 с — 83 %, потери 845, p50 0,96 с; 200 раз в 1 с — 89 %, потери 794 + 296 AE «database is locked», p50 194 мс / p95 5,9 с, тик 107 с.

• Что дорого. Не кривые (пакет — 0,25 мс процессора, 100 тыс. отсчётов/с — 10 % ядра на разбор и 1–6 % на запись) и уже не база: показатели пишутся одним потоком раз в секунду одной транзакцией (1–2 коммита в секунду вместо 200), тик ИИ читает все койки одним запросом и пишет точки одним bulk_create. Остался один процесс Python с потоком на монитор: при 200 мониторах и показателях раз в секунду приёмник занимает 115 % ядра (разбор плюс GIL на 200 потоков), а сброс 60 с кривых на диск занимает 6–17 с и на это время задерживает ACK (p95 0,7–1,4 с). При показателях раз в 5–10 с (так обычно настроен eGateway, и так считался расчёт выше) — с запасом.
• Сервер на 200 мониторов. Важна частота ядра (приёмник HL7 — один процесс Python): Core i5/i7 12–13 поколения, 8 ядер достаточно (приёмник 1, PostgreSQL 2, web и cloud_link 1–2, писатель и gzip 1, система 1), 16 ГБ памяти (процесс hl7 до 0,75 ГБ, PostgreSQL 2–4 ГБ), NVMe/SSD (показатели пишутся пачкой раз в секунду — 1–2 коммита/с, плюс кривые 0,2 МБ/с и их сжатие раз в час; до правок было 200–250 коммитов/с с fsync; HDD всё равно не подходит из-за сжатия часов и базы). Диск в сутки: кривые 5–10 ГБ сжато (сырые int16 — ровно 1 КБ/с на монитор, 17 ГБ/сутки; gzip сжимает их в 2–5 раз, с шумом настоящего монитора ≈ 0,2–0,5 КБ/с), показатели ~3 ГБ; 2 ТБ хватает на 30 дней кривых и год показателей.
• Запустить самому: python3 scripts/connect_load_test.py --beds 200 --duration 120 --report /tmp/load-200.md (SQLite во временной папке; --vitals-interval 10 — показатели раз в 10 с, --noise 0.02 — кривые с шумом для оценки сжатия, --sqlite plain — настройки SQLite как у платформы по умолчанию).

Дообучение на сервере больницы

Раз в неделю ночью (по умолчанию ночь на понедельник, 3:00 по местному времени; день и час меняются на странице модуля) служба cloud_link дообучает работающую модель на данных этой больницы. Всё происходит на сервере больницы, наружу ничего не уходит.

• На чём учится. Каждая оценка риска хранит входы модели (те же показатели, что в «Почему», числами, без данных пациента). Оценка считается положительным примером, если в следующие 6 часов у койки было событие (остановка кровообращения, интубация, вазопрессоры, перевод, смерть), иначе отрицательным. Отметки врачей правят метки: «Ложная тревога (артефакт датчика)» — оценки той тревоги (или часа перед отметкой) в обучение не идут; «Не по делу» — они отрицательные, даже если событие было; «Полезно» и «Принял» ничего не меняют — решает событие. Положительные примеры копятся за 8 недель (редкие события не теряются), отрицательные берутся за последнюю неделю и не больше 20 на один положительный.
• Проверочная выборка. Каждый третий койко-день (всегда одни и те же) отложен: на нём версия только проверяется и никогда не обучается. Нужно не меньше 20 событий в проверочной выборке за прошлые недели (хранятся 60 дней), иначе дообучение пропускается с причиной «мало событий».
• Условия запуска. Модуль включён; за неделю не меньше минимума отметок врачей (по умолчанию 30, настраивается в блоке «Отметки врачей за неделю» — иначе учиться не на чем); хватает событий. Иначе в журнале дообучений строка «пропущено» с причиной. «Дообучить сейчас» запускает дообучение в фоне без ожидания отметок (события всё равно нужны).
• Как учится. Логистическая модель с теми же входами, что у работающей, доучивается градиентным спуском от её весов (веса не уходят в минус: ухудшение показателя может только поднять риск); не дольше 2 часов, на практике — секунды. Если на проверочной выборке новая версия хуже работающей, она не создаётся («хуже работающей на проверочной выборке»).
• Куда попадает. Новая версия «<основа>+N» (N — номер дообучения в этой больнице, например «0.1+3», «дообучение на больнице») идёт в тень на 7 дней и дальше — как любая теневая версия: сравнение по AUROC, чувствительности и ложным тревогам с работающей и NEWS2 (не меньше 20 событий), «Включить сейчас» или автовключение, иначе отклонение с причиной в журнале.
• Вернуться. «Вернуться к предыдущей» рядом с «Сохранить» — к последней; в журнале версий у каждой из пяти «предыдущих» кнопка «Вернуть»: она снова работает, а та, что была включена, помечается «заменена · возврат администратора».

Данные пациента и облако

Записи лежат только на сервере больницы и в облако vidicap.cloud не уходят; в файлах нет ФИО, только номера койки и монитора. Перемотку видят те же, кому видна страница койки. Смена пациента на койке (ключ пребывания) отмечена на шкале, чтобы запись одного пациента не спутать с другим; при выписке запись койки продолжается и относится к новому пребыванию.

Что дальше

Следующие этапы модуля: нагрузочный тест на образце железа с PostgreSQL (в контейнере — см. «Нагрузка и требования к серверу»), дообучение модели ИИ по кривым (сейчас — по показателям, событиям и отметкам), отправка полосы PDF врачу прямо из уведомления.

ИИ: оценка состояния (доп. модуль)

Доп. модуль «ИИ: оценка состояния» раз в минуту считает по каждой койке с монитором риск ухудшения — число от 0 до 100: насколько вероятно критическое событие (остановка кровообращения, интубация, вазопрессоры, перевод, смерть) в ближайшие 1–6 часов. Рядом с числом — тренд за 6 часов, «Почему» (какие показатели дали вклад) и совет по простым правилам. Врач отмечает одним нажатием, был ли сигнал по делу; на этих отметках и событиях у коек модель будет учиться дальше.

Статус модуля — «исследование · не для клинических решений», это написано на каждом экране. Риск помогает раньше посмотреть на койку, но ничего не решает за врача: тревоги монитора, центральная станция и осмотр остаются главными. Клиническим модуль станет только после регистрации программы как медицинского изделия (см. описание «ИИ в реанимации» в документах проекта).

Включить

1. Лицензия. Модуль выдаётся на vidicap.cloud на число коек и приходит на сервер больницы вместе с остальными лицензиями Connect; сервер без лицензии работает без ограничений. Без модуля в лицензии или после её окончания включить модуль нельзя; что уже посчитано и отмечено, остаётся.
2. Страница модуля. Connect → «Настройки» → «Доп. модули» → «ИИ: оценка состояния» (/connect/ai/, для администраторов организации). Переключатель «Модуль включён», что показывать на экранах (риск на плитке, тренд и «почему» на койке, советы), «Сохранить». С этого момента служба cloud_link считает риск раз в минуту по всем койкам с монитором (в пределах лицензии: первые по порядку добавления).
3. Порог уведомления задаётся в настройках отделения («Уведомления» → отделение → «Риск ухудшения (ИИ) выше», по умолчанию 70). Когда риск держится на пороге или выше 5 минут, дежурный врач получает уведомление «📈 ОРИТ, Палата 1, Койка 3 / Риск ухудшения 78 (порог 70): ср. АД снижается 40 мин (87 → 71)» — в Telegram и push, с той же эскалацией, кнопкой «Принял» и режимами «что видно в сообщении», что у тревог. Уведомление закрывается само, когда риск 15 минут ниже порога минус 10.

Что такое риск и стартовая модель «0.1 (правила)»

Модель получает признаки за последние 6 часов по данным монитора: уровень и тренд среднего АД (инвазивного, без него — манжетного), ЧСС, SpO₂ (и менялся ли при этом FiO₂), ЧД, температура, NEWS2 сейчас и его изменение за час, сколько минут не измерялось АД, идёт ли сейчас гипотензия, найденная Connect (ср. АД < 65 не меньше 5 минут). Тренд — это ряд пятиминутных средних: откуда и докуда показатель шёл в одну сторону и сколько минут («ср. АД снижается 40 мин (87 → 71)»).

Первая версия — «0.1 (правила)»: прозрачная логистическая формула с весами, заданными вручную (они видны в коде и в таблице версий, params): каждый признак равен нулю, пока показатель в норме, и растёт с отклонением; все веса положительные, поэтому риск может только расти, когда показатель ухудшается. Риск = 100 · сигмоида(−3,5 + сумма весов × признаков). Примеры при остальных показателях в норме: ср. АД 71 после снижения с 87 → 15; плюс ЧСС 118 после 96 и NEWS2 4 → 60; плюс SpO₂ 90 после 96 при том же FiO₂ и NEWS2 7 → 93; только NEWS2 7 → 24; только идущая гипотензия → 35. NEWS2 входит в формулу намеренно: это та шкала, которую модель должна превзойти, и пока модель правил её лишь дополняет трендами.

Стартовая модель — не обученная сеть, а прозрачная основа для теневого режима и отметок; обученные версии (на открытых данных реанимаций или на данных больницы, формат ONNX) подключаются на том же месте: та же таблица версий, те же цифры проверки, тот же теневой режим. На сервере Connect для них понадобится библиотека onnxruntime (с Connect не ставится; версия, которая не может считаться, пропускается, об этом запись в журнале службы).

«Почему» — три самых больших вклада в риск с подписями, которые читает врач («ЧСС растёт (96 → 118)», «SpO₂ 86 % при FiO₂ без изменений», «АД не измерялось 95 мин»). Совет — по правилам: при снижении или низком ср. АД — «проверьте пункты протокола при гипотензии»; при снижении SpO₂ на 3 и больше при том же FiO₂ — «проверьте датчик и дыхание»; «рассмотрите анализ лактата» появится с модулем «Лаборатория», когда будет известно, когда он измерялся.

На экранах

• Карточка койки: карточка «Риск ухудшения (ИИ)» под уведомлением — число (серое до 40, жёлтое от 40, красное от 70), линия за 6 часов с пунктиром порога, «за 6 ч: 31 → 78, растёт», NEWS2 на ту же минуту, версия модели, «Почему», «Совет», кнопки отметок, строка про уведомление (кому ушло, кто принял).
• Экран «Палаты»: на плитке рядом с NEWS2 — число риска тем же цветом (если включено «риск на плитке»); «риск N мин», пока уведомление не принято.
• Уведомления бота и приложения: кнопки «✅ Принял», «👍 Полезно», «👎 Не по делу».
• API v1: в GET /api/v1/beds/{id} поле risk: {"score": 78, "model": "0.1 (правила)", "at": "…", "parts": [{"code": "map_fall", "label": "ср. АД снижается 40 мин (87 → 71)", "contribution": 1.28}]}; null, пока модуль выключен. Данных пациента в нём нет.

Отметки врачей

Четыре кнопки под риском: «✅ Принял» (принимает и уведомление по койке, если оно ждёт), «👍 Полезно», «👎 Не по делу», «⚠ Ложная тревога (артефакт датчика)». Одна отметка каждого вида на койку в час; повторное нажатие снимает её (кнопка подсвечена, пока отметка стоит). В Telegram и push кнопки «Полезно» и «Не по делу» под уведомлением о риске делают то же.

Отметка — это метка обучения: время, койка, вид, оценка риска и уведомление в тот момент, роль и отделение врача. ФИО врача хранится только на этом сервере, чтобы врач мог снять свою отметку, и ни в какую выгрузку не идёт. «Ложная тревога» исключает оценки той тревоги из обучения, «Не по делу» делает их отрицательным примером, событие у койки в следующие 6 часов — положительным (см. «Дообучение на сервере больницы»).

Версии, тень и цифры

На странице модуля:

• Работающая модель — та, чей риск видят врачи и по которой идут уведомления: версия, основа, порог, цифры за 30 дней в этой больнице и NEWS2 за тот же период, посчитанная тем же способом (NEWS2 ≥ 7 как сигнал).
• В тени — новая версия (дообучение на больнице или общая версия из vidicap.cloud, оба — следующие этапы; сейчас такую версию можно создать только из кода), которая считается рядом с работающей, но врачам не показывается. Таблица сравнения: AUROC, чувствительность при пороге и ложных на койку в сутки — работающая, в тени, NEWS2; зелёным лучше, красным хуже. После 7 дней в тени и не меньше 20 событий версия, которая лучше по всем трём строкам, включается кнопкой «Включить сейчас», или сама — если включено «Включать автоматически, если лучше по всем» (по умолчанию выключено, решает администратор). Версия, которая не лучше, отклоняется автоматически с причиной в журнале; «Отклонить» можно и раньше. «Вернуться к предыдущей» возвращает прежнюю версию (хранятся пять последних).
• Как считаются цифры. Событие — отметка врача у койки: остановка кровообращения, интубация, вазопрессоры, перевод из ОРИТ, смерть. Оценка риска считается положительной, если такое событие было в течение 6 часов после неё. AUROC — ранговая статистика по всем оценкам за 30 дней (1,0 — модель всегда ставит событию оценку выше, чем «без события», 0,5 — не отличает). Чувствительность при пороге — доля событий, перед которыми (за 6 часов) риск хотя бы раз был на пороге или выше. Ложных на койку в сутки — число эпизодов «на пороге или выше», после которых за 6 часов события не было, делённое на число койко-суток с оценками. Пока событий мало (меньше 20), цифры показываются, но версии по ним не судятся.
• Отметки врачей за неделю и число событий у коек; следующее дообучение — дата и час, нужное число отметок и сколько уже есть (зелёным, когда хватает), минимум отметок, когда дообучать, кнопка «Дообучить сейчас».
• Общее обучение через vidicap.cloud — выбор «не участвовать» / «только веса модели» (по умолчанию) / «обезличенные эпизоды», последняя отправка, следующая отправка и общая версия (см. ниже).
• Журнал дообучений: последние 20 запусков — когда, итог (новая версия в тени / пропущено с причиной / ошибка), размер обучающей выборки, события проверочной, длительность.
• Журнал версий: откуда версия, её цифры, решение (включена, в тени, отклонена, предыдущая, заменена) с причиной и кто решил (администратор или «автоматически»); у каждой «предыдущей» кнопка «Вернуть».

Общее обучение через vidicap.cloud

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

• «Не участвовать» — наружу не уходит ничего, общая версия не приходит; модель учится только на данных этой больницы.
• «Только веса модели» (по умолчанию, федеративно) — раз в месяц уходят веса работающей модели (число на каждый вход: ср. АД и его падение, ЧСС и её рост, SpO₂ и его падение, ЧД, температура, NEWS2 и его рост, давность АД, гипотензия, и смещение), её название и версия, цифры за прошлый месяц (AUROC, чувствительность, ложных на койку в сутки) и количества: оценок, с событием после, событий, койко-суток. Ни одной оценки, ни одной койки, ни одной даты точнее месяца.
• «Обезличенные эпизоды» — по каждой оценке прошлого месяца с меткой (см. «Дообучение на сервере больницы»: без оценок, отмеченных «ложная тревога») уходят входы модели (те же числа, что хранит оценка, без нулей), метка 0/1 и минута от начала эпизода; эпизод — один койко-день под случайным номером, который нигде больше не хранится. Без ФИО, койки, отделения, монитора, дат и времени. Не больше 20 000 оценок за отправку (при большем — случайная выборка). Каждую отправку эпизодов администратор подтверждает: галочка «Подтверждаю отправку обезличенных эпизодов», «Сохранить»; без подтверждения, сделанного после прошлой отправки, отправка пропускается с причиной «администратор не подтвердил…». Веса подтверждения не требуют.

Когда. В день «Следующая отправка» (по умолчанию 1-го числа, в час дообучения; число меняется там же) за прошлый календарный месяц, или сразу кнопкой «Отправить сейчас». Отправка готовится службой cloud_link и уходит по той же связи с облаком, что и остальное (только наружу, см. «Связь серверов»): отдельного канала нет, без подключения к облаку строка «Последняя отправка» показывает «пропущена · сервер не подключён к vidicap.cloud». Отправляет главный сервер учреждения (тот, что подключён к облаку); Connect, подчинённый серверу больницы, отправку пропускает с такой причиной.

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

Общая версия. В облаке из весов всех больниц за месяц собирается версия «common-ГГГГ.ММ» (среднее весов, вес каждой больницы — число её положительных примеров), администратор платформы публикует её, и при следующей связи она приходит на каждый сервер с выбором «веса» или «эпизоды» и появляется в тени — «общая, vidicap.cloud», с числом больниц в примечании. Дальше она проходит ту же проверку, что дообучение на больнице: 7 дней в тени, сравнение с работающей и NEWS2, «Включить сейчас» или автовключение, иначе отклонение с причиной. Сама по приходе она никогда не включается. Строка «Общая версия» показывает её номер, число больниц и состояние: в тени, включена, не получена (или отклонена, предыдущая).

Данные пациента и облако

Оценки риска (connect.RiskPoint: койка, минута, модель, число, вклады, входы модели, NEWS2; хранятся 60 дней), отметки врачей, версии модели и журнал дообучений лежат только на сервере больницы; дообучение идёт на его процессоре. В «Почему», уведомлениях и API нет ФИО, даты рождения и номера — только показатели. В облако vidicap.cloud уходят только веса модели или обезличенные эпизоды — и только при выборе администратора на странице модуля (см. выше); состав отправки проверяется тестом connect.test_ai.

Что дальше

Дообучение по кривым при модуле «Запись кривых» и по исходам из МИС через API (сейчас — по показателям, событиям и отметкам); обучение общей версии на присланных эпизодах (сейчас общая версия собирается из весов, файлы эпизодов копятся в облаке для обучения вне программы); первая обученная модель на открытых данных реанимаций (MIMIC-IV, eICU) вместо модели правил; совет о лактате с модулем «Лаборатория».

Протоколы (Приказ 254) (доп. модуль)

Доп. модуль «Протоколы (Приказ 254)» ведёт четыре документа по формам приказа Минздрава № 254 от 17.03.2014 — протокол анестезии (лист этапов и сетка по 5 минут), протокол интенсивной терапии и мониторинга (суточный лист реанимации по часам), протокол осмотра врача анестезиолога-реаниматолога (страницы 2–3 приказа) и протокол транспортировки пациента (страницы 9–10) — так, чтобы врач и сестра не переписывали цифры с монитора. Сетка и цифры осмотра заполняются с монитора сами, протокол анестезии открывается и закрывается сам по записи операции на Vidicap, врач нажимает этапы и препараты на телефоне или на экране Vidicap, сестра — диурез и дренажи на странице койки, а печать даёт точную копию бланка (анестезия и суточный лист — A4 поперёк, осмотр и транспортировка — A4 вдоль). Протоколы и их PDF лежат на сервере больницы 5 лет (срок настраивается) и в облако не уходят.

Включить

1. Connect → «Настройки» → «Доп. модули» → «Протоколы (Приказ 254)» (/connect/protocols/, для администраторов организации; врачи видят страницу, когда модуль включён). Переключатель «Протоколы включены», «Сколько лет хранить архив» (по умолчанию 5), «Сохранить».
2. Справочники отделений — там же, по кнопке «Изменить» у отделения (/connect/protocols/catalog/<отделение>/). Правит администратор организации или заведующий отделением — тот, кто назначен заведующим в «Уведомлениях врачам» этого отделения; остальные врачи справочник не открывают (403). Это кнопки быстрого ввода, по одной строке на кнопку: препараты (название | доза единица | путь | доза единица/кг | дозы кнопок через запятую — доза на килограмм пересчитывается по весу пациента, остальное — как есть), наборы (индукция: Фентанил 0,2 мг в/в; Пропофол 160 мг в/в; Рокуроний 50 мг в/в), виды анестезии, трубки и доступы с умолчаниями шапки, кнопки кровопотери и диуреза, объёмы инфузии, кнопки сестры суточного листа (подпись | строка | значение: Дренаж 1 | drain1 | 50, строки drain1, drain2, tube_in, tube_out, stool, diuresis), типовые фразы каждого текстового поля («гладкое», «гемодинамика стабильная», «экстубирован в сознании…», для осмотра — жалобы, физикальные данные, дыхание, план и заключение, для транспортировки — медикаменты в пути и осложнения). Без своего справочника отделение пользуется типовым анестезиологическим (фентанил, пропофол, рокуроний, атропин, эфедрин, ондансетрон, цефазолин, севофлуран…, наборы «индукция» и «а/б профилактика», кровопотеря 50/150/300/500/1000). Один и тот же набор отделения показывают телефон, страница протокола и полоса на экране Vidicap — ни одной кнопки в них не зашито. «Сбросить к типовому» возвращает типовой.
3. Кто видит. То же, что страница койки: врачи и сестры отделения (членство в отделении) и администраторы организации. Протоколы другого отделения не открываются (403).
4. Ночь. Суточные листы открываются сами при первом открытии страницы занятой койки; чтобы они были готовы к утреннему обходу и вчерашние закрылись в полночь, поставьте на компьютере Connect в cron команду docker compose exec web python manage.py connect_protocols_daily (0:05) и раз в сутки connect_protocols_cleanup (удаляет закрытые протоколы и их PDF старше срока хранения; --dry-run только считает, --years N — другой срок). Кнопка «Открыть суточные листы сейчас» на странице модуля делает то же самое вручную.

Протокол анестезии: шаг за шагом

1. Открыть. Сам — со стартом записи операции на Vidicap (ниже), или на странице модуля — «Открыть новый»: операционная (монитор или наркозный аппарат привязан к точке операционной в «Мониторы и наркозные аппараты (HL7)») или койка (мониторы койки). Протокол открывается в состоянии «заполняется» с временем начала «сейчас» и шапкой из умолчаний отделения (вид анестезии ОЭТА, трубка 8,0 через рот, доступ периферический 18G — их можно поменять одной кнопкой). Если на койке пациент назван МИС (привязка через API или ADT), ФИО, номер истории и дата рождения подставляются из неё; имя, которое присылает сам монитор (PID), в протокол не берётся никогда. Иначе ФИО, вес, возраст и пол врач вписывает сам в карточке «Пациент» — вес нужен для доз.
2. Сетка по 5 минут заполняется сама. Для каждой колонки берётся ближайшее к ней значение в пределах ±2,5 минуты: ЧСС (или пульс), АД систолическое и диастолическое (неинвазивное; инвазивное — когда манжета молчит), SpO₂, EtCO₂, FiO₂, температура, ЦВД. Если монитор молчал, клетка остаётся пустой — ничего не додумывается; список модуля показывает «монитор молчит N мин». На странице протокола сетка нарисована как на бланке: АД — галочки V (систолическое) и Λ (диастолическое), ЧСС — точка, под графиком — те же числа таблицей. Пока протокол открыт, страница пересчитывает сетку при каждом открытии.
3. Этапы и препараты — с телефона. Кнопка «📱 Быстрый ввод» (/connect/protocols/<id>/quick/, то же в приложении «Vidicap ICU») — четыре вкладки, крупные кнопки, ничего не набирать: - «Этап» — премедикация, индукция, интубация, разрез, конец операции, экстубация, перевод. Нажатие ставит текущее время; нажатая кнопка зеленеет, повторное нажатие даёт поправить на −5 / −10 минут. Разрез и конец операции становятся началом и концом операции, перевод или экстубация — концом анестезии. Интубация, экстубация и перевод, отмеченные на странице койки, подставляются сами. - «Препарат» — кнопки справочника с дозой по весу («Пропофол 160 мг» при 82 кг). Одно нажатие — строка в протоколе с временем «сейчас»; второе нажатие на тот же препарат открывает строку дозы: −/+, типовые дозы, «сейчас / −5 / −10 мин», «Убрать». «Наборы» вводят несколько строк одним нажатием, «Другой…» — весь справочник с поиском или препарат, которого в нём нет. - «Ещё» — вид анестезии, трубка и доступ (если не подтверждены), старт и стоп инфузии (объём считается в итог), кнопки кровопотери, типовые фразы течения, осложнений, выхода и перевода. - «Готово» — сводка: этапы, число препаратов, инфузия, диурез, кровопотеря, сколько клеток пришло с монитора, чего не хватает; кнопки «Перевод — сейчас» и «Закрыть и напечатать». Внизу всегда «Отменить последнее» — последний нажатый этап или препарат снимается.
4. На компьютере (/connect/protocols/<id>/) — то же плюс поля шапки (операция, анестезиолог, сестра, аппарат, режим ИВЛ, ДО, ЧД, PEEP, FiO₂, премедикация, мониторинг, диагноз), ввод этапа по времени «ЧЧ:ММ», удаление строк препаратов, текстовые поля с фразами-кнопками, итоги (сервер считает инфузию, диурез, дренажи и баланс сам; вписанное врачом число побеждает) и «Исправить клетку вручную»: исправленная клетка подсвечена, значение монитора остаётся в журнале правок.
5. Закрыть и напечатать. Конец анестезии — этап «перевод» или «экстубация», иначе момент закрытия. Сетка заполняется в последний раз и замораживается (новые данные монитора её не меняют), считаются итоги, PDF ложится в архив. «🖨 Печать» открывает PDF и помечает протокол «распечатан»; «PDF» — просто посмотреть. Закрытый протокол можно дописать текстом, шапкой, пациентом или итогами — PDF в архиве перезаписывается; снова открыть его может администратор организации («Открыть снова»).

Запись операции на Vidicap открывает и закрывает протокол

Vidicap в операционной спарен с точкой Connect (та же пара «устройство — точка», что и для видео), поэтому протокол анестезии операционной умеет идти за записью сам:

• Старт записи — протокол операционной открывается с момента старта (состояние «заполняется», источник «запись Vidicap», в списке модуля — «открыт записью Vidicap»); если врач уже открыл протокол кнопкой, старт только отмечается в нём. В журнале правок — «старт записи».
• Стоп записи — ставится этап «конец операции» (если врач не нажал его сам), и протокол, открытый записью, закрывается с PDF. Протокол, открытый кнопкой врача, остаётся открытым — врач закроет его сам, когда допишет. Повторный старт в течение 15 минут после стопа (запись перезапустили) продолжает тот же протокол, а не открывает второй.
• Метки записи («разрез», «конец операции», «экстубация», «перевод»…) становятся этапами; любой другой текст («кровотечение») ложится в протокол как метка со временем — блок «Метки Vidicap» на странице протокола, туда же врач добавляет метку с компьютера.
• Всё идемпотентно: один и тот же старт или стоп, пришедший дважды, ничего не меняет дважды; каждое событие в журнале правок протокола с источником (heartbeat, vidicap).

С Vidicap это приходит двумя путями: флаг recording (и recording_since — момент старта, epoch) в обычном heartbeat устройства — Connect сравнивает его с прошлым и замечает старт и стоп; или явный вызов POST /api/device/protocol/recording с моментом события (ниже). Пока агент Vidicap не шлёт recording — ничего не происходит, протокол открывают кнопкой: этап со стороны устройства — отдельное изменение программы Vidicap.

Экран Vidicap: полоса «Протокол» (API устройства)

Та же полоса кнопок, что на телефоне, но на экране Vidicap в операционной: этапы с временем, препараты отделения с дозой по весу, «Другой препарат», метка голосом. Платформа отдаёт её простым JSON, без сокетов — Vidicap Touch 1.0 и 2.0 опрашивают status раз в несколько секунд и шлют нажатие; всё идёт в тот же протокол, что телефон и страница. Заголовок — Authorization: Device <id>:<secret> устройства, как в heartbeat; пациент в ответе только «Фамилия И. О.», остальных данных пациента на экран Vidicap не идёт. Вызовы описаны на странице «API» (/connect/api/docs/, раздел «Экран Vidicap: полоса «Протокол»») и в openapi.json:

at — момент нажатия (epoch секунды или ISO 8601), без него — «сейчас»; каждый POST отвечает тем же JSON, что status, плюс ok и result. Ошибки: 401 устройство не спарено, 404 нет открытого протокола, 409 модуль выключен, 400 неизвестный этап, препарат или набор.

Печать: лист 1 и лист 2 бланка

PDF (/connect/protocols/<id>/pdf; ?download=1 — сохранить файлом, ?print=1 — отметить распечатанным) повторяет бланк приказа: лист 1 — две колонки: справа заголовок «ПРОТОКОЛ АНЕСТЕЗИИ», дата и время, ФИО и возраст, оценка перед анестезией, вид анестезии (ОЭТА / ТВА / спинальная…), премедикация, а/б профилактика, мониторинг, операционное положение, интубация (трубка, через рот/нос, попытка, Кормак), аппарат и параметры ИВЛ, доступы, течение анестезии, инфузия, осложнения, выход, перевод, подписи; слева — манипуляции, ранний послеоперационный период, таблица оценки, поздний период. Лист 2 — «ЭТАПЫ ОПЕРАЦИИ»: слева премедикация, прекураризация, индукция, релаксант, ЭТТ, аппарат, контур, мониторы, итого расход, инфузия; справа сетка по 5 минут с осью 20–240, галочки V Λ давления и точки ЧСС, пунктирные линии этапов с подписями вдоль них, строки SpO₂, EtCO₂, FiO₂, температуры, ЦВД, ингаляционного анестетика (МАК), дыхания и газов, препараты по строкам в своих клетках времени, инфузии линиями, диурез. Шрифт встроен; внизу мелко — «Vidicap Connect · протокол № · напечатано … · значения с монитора, журнал правок на сервере больницы».

«Пустой бланк» (/connect/protocols/blank/anesthesia.pdf, …/icu_day.pdf, …/exam.pdf, …/transport.pdf, кнопки на странице модуля) — те же листы без данных, чтобы распечатать заранее на случай, когда сервер недоступен.

Суточный протокол интенсивной терапии

1. Открывается сам. У занятой койки (МИС назвала пациента или монитор привязан и на связи) суточный лист сегодняшнего дня появляется при первом открытии страницы койки или в полночь по команде connect_protocols_daily; вчерашний при этом закрывается с PDF. Пациент — из МИС, иначе переносится со вчерашнего листа вместе с диагнозом, аллергией, группой крови и номером суток в ОИТР (растёт на один). Открыть вручную можно и со страницы модуля: «Открыть новый» → койка → «Суточный протокол ИТ».
2. Часы с монитора. В каждой из 24 колонок — медиана за час по АД систолическому и диастолическому, ЧСС, ЦВД, SpO₂, FiO₂, ЧД и температуре; часа без данных — пустая клетка; будущие часы серые. Сутки — календарные, 00–23 (бланк нумерует колонки с 9 — порядок часов в PDF тот же, что в бланке, первая колонка — 0 часов).
3. Сестра на странице койки. В карточке «Протоколы (Приказ 254)» — диурез за текущий час кнопками +50 / +100 / +150 / +200 / +300 (суммируются в клетку часа), «Дренаж +50», «Стул +», старт и стоп инфузии, итоги дня (диурез, баланс) и число часов с монитора. То же и подробнее — на вкладке «Сестра» быстрого ввода: выбор часа, диурез, дренажи 1 и 2, зонд (питание, потери), стул, инфузия. На компьютере строки сестры (диурез, стул, зонд, дренажи, режим ИВЛ, Vt, MV, Pmax, PEEP, податливость, гликемия, инсулин) вписываются в таблицу по часам — кнопка ✓ в строке записывает её.
4. Врач. Назначения (препарат, доза, путь, время), инфузия, дневник с видом записи — осмотр, дневник, назначено, лаборатория; фразы-кнопки осмотра и дневника на вкладке «Ещё» телефона; «Тяжесть состояния обусловлена», диагноз, поступил, сутки в ОИТР, аллергия, группа крови, шкала — в шапке.
5. Печать. Лист 1 — таблица часов (АД, ЧСС, ЦВД, SpO₂, FiO₂, ЧД, T, диурез, стул, зонд, дренажи, ИВЛ, гликемия, инсулин, назначения по часам) с подписями групп вдоль края, справа — катетеры, ИВЛ, лаборатория, микробиология, инструментальные исследования, консультации, диета, итоги (введено, выделено, баланс). Лист 2 — ещё строки, подписи и «Дневник»: осмотр, тяжесть, назначения, лаборатория и записи дня по времени.

Осмотр анестезиолога-реаниматолога

Протокол осмотра перед анестезией (страницы 2–3 приказа) открывается с карточки койки («🩺 Осмотр анестезиолога») или со страницы модуля («Открыть новый» → койка или операционная → «Осмотр анестезиолога-реаниматолога»); в списке модуля — вкладка «Осмотры».

1. Цифры — с монитора. В момент открытия сервер снимает с монитора койки (операционной) ближайшие значения в пределах ±5 минут: пульс, ЧСС, АД, SpO₂, температуру, ЧД — карточка «Цифры при осмотре» вверху, те же числа подставлены в поля осмотра и помечены «с монитора». Кнопка «Снять с монитора сейчас» повторяет снимок и переносит время осмотра. Рост, вес и пол берутся из карточки пациента (если у того же пациента уже был протокол — переносятся из него); ФИО — из МИС или вписывается, с монитора никогда.
2. Бланк на экране. Разделы как на бумаге: операция (плановая / экстренная), анамнез с галочками курение / алкоголь / гепатит / ВИЧ / токс-нарк, состояние (сознание, Glasgow, последний приём пищи), осмотр, факторы ТЭЛА, оценка дыхательных путей — Маллампати, открывание рта, сгибание головы, клинические данные, нижняя челюсть, анамнез, ТД — с баллами и суммой ИТИ (трудности не ожидаются / возможны / вероятны / облигатная трудная интубация), лаборатория (при модуле «Vidicap Lab» отклонения за последние 3 дня подставлены сами), план анестезии, заключение, предоперационные назначения, премедикация, класс ASA и риск AAA. Длинные поля — жалобы, физикальные данные, дыхание, план, заключение — набираются фразами отделения из справочника. Поле, вписанное врачом поверх монитора, зеленеет; значение монитора остаётся в журнале правок.
3. Печать — две страницы A4 вдоль, точная копия страниц 2–3 приказа: подчёркнутые варианты (состояние, сознание), галочки, таблица оценки дыхательных путей с обведённым баллом, лабораторный блок, на второй странице — ТД, ИТИ, назначения, премедикация, ASA/AAA и текст согласия на медицинское вмешательство. «Закрыть и напечатать» кладёт PDF в архив; закрытый осмотр можно дописать полями.

Транспортировка

Протокол транспортировки (страницы 9–10 приказа) открывается с карточки койки, с которой везут («🚑 Транспортировка»; пока она идёт, кнопка ведёт в открытый протокол — «Транспортировка идёт»), или со страницы модуля («Открыть новый» → койка → «Транспортировка (с койки)»); вкладка «Транспортировки» в списке.

1. Откуда — куда. Куда: койка Connect, операционная или текст (другое учреждение). Транспортный монитор (HL7) — монитор, не привязанный к койке (BeneView T1 и подобные, принимаемые по HL7 как остальные): он даёт колонку «во время».
2. «Отъезд — сейчас» ставит время отъезда и снимает с монитора койки-источника «исходные данные»; «Прибытие — сейчас» — время прибытия, «после транспортировки» с монитора койки или операционной назначения и «во время» — медиана транспортного монитора между отъездом и прибытием. Повторное нажатие заменяет цифры. Время в пути считается.
3. Протокол мониторинга — таблица «исходные / во время / после»: состояние, сознание, судороги, SpO₂, АД, ЭКГ и ЧСС, ЧД и ИВЛ, температура, диурез, зонд, инфузия, другое. Жёлтые клетки — с мониторов; врач вписывает своё поверх, значение монитора остаётся в журнале. Статус до и после транспортировки, предтранспортная подготовка и сама транспортировка — поля бланка; медикаменты в пути и осложнения — фразами отделения.
4. Печать — две страницы A4 вдоль по страницам 9–10 приказа: шапка учреждения и бригады, статус перед транспортировкой с подчёркнутыми вариантами, подготовка, транспортировка, таблица мониторинга, статус после, подписи. Конец протокола — момент прибытия.

Журнал правок, архив, данные пациента

• Журнал правок (внизу страницы протокола): каждая правка — поле, старое и новое значение, кто и когда, откуда (кнопка, набор, вручную). Клетка монитора, исправленная врачом, хранит значение монитора в журнале, а в PDF идёт исправленное.
• Архив. PDF закрытых протоколов лежат в VIDICAP_FILES_DIR/connect/protocols/<год>/ (файл anesthesia-<№>-<дата>.pdf, icu_day-…, exam-…, transport-…); размер архива виден на странице модуля. Протоколы старше «Сколько лет хранить архив» удаляет connect_protocols_cleanup вместе с PDF — всех четырёх видов; открытые не трогаются.
• Списки. На странице модуля — «Ждут врача» (открытые протоколы без этапов, препаратов, пациента, осмотра, диуреза, цифр монитора, заключения, отъезда или прибытия), вкладки «Сейчас», «Операционные», «Реанимация», «Осмотры», «Транспортировки», «Архив», фильтры по отделению, состоянию и дню; у каждого протокола «Быстрый ввод» (анестезия и суточный лист), «Открыть», «PDF». Карточка койки показывает сегодняшний суточный лист, открытые осмотр и транспортировку этой койки и кнопки их открыть.
• Лаборатория. С модулем «Vidicap Lab» на странице протокола и в PDF — блок «Лаборатория»: результаты анализов койки (операционной) за период протокола (раздел «Vidicap Lab»).
• Данные пациента. Протоколы, журнал правок и PDF остаются на сервере больницы; ни в облако vidicap.cloud, ни в Telegram, ни в push ничего из них не уходит. ФИО берётся только из МИС или вводится врачом.

Что дальше

Полоса «Протокол» на самом экране Vidicap Touch 1.0 и 2.0 и флаг recording в heartbeat агента — изменение программы устройства по описанному выше API (платформа готова); сетка по кривым при модуле «Запись кривых»; остальные формы приказа (карта наблюдения в палате пробуждения).

Vidicap Lab (доп. модуль)

Доп. модуль «Vidicap Lab» принимает результаты лабораторных анализаторов — Mindray BS (биохимия), CL (иммунохимия), BC (гематология, через labXpert), BA-88A и любого анализатора, который умеет HL7 ORU^R01, — и кладёт их на страницу койки рядом с показателями монитора: таблица тестов по последним пробам, стрелки выше/ниже нормы и к предыдущей пробе, красным — за критическим пределом. Критический результат (калий 6,1, глюкоза 2,0…) уходит дежурному врачу отделения как уведомление («Уведомления врачам», Telegram и push), без ФИО. Контроль качества и калибровки хранятся в журнале лаборатории и на койки не попадают. Этап 2: заявки — МИС (API, HL7 ORM^O01) или сестра говорит, какие тесты сделать с пробиркой, анализатор с двунаправленной связью сам берёт заявку по штрихкоду; результаты наружу — в API, вебхуках, получателям HL7 и в протоколы Приказа 254. Всё остаётся на сервере больницы: в облако vidicap.cloud из лаборатории ничего не уходит, и в облачной версии модуля нет.

Включить

1. Connect → «Настройки» → «Доп. модули» → «Vidicap Lab» (/connect/lab/, для администраторов организации; кнопка Lab в меню Connect). Переключатель «Vidicap Lab включена», «Сколько дней хранить результаты» (по умолчанию 365), «Сохранить». При включении заполняется типовой справочник тестов.
2. Добавить анализатор — название («Биохимия 1»), модель, протокол (Mindray HL7 2.3.1 для BS, CL и BA-88A; HL7 ORU^R01, общий для остальных — код теста читается из OBX-3), связь (Connect слушает порт — обычный случай: анализатор сам подключается к серверу; или Connect подключается к анализатору по IP и порту), порт, кодировка (UTF-8; GBK для анализатора с китайскими настройками), отделение. Каждому анализатору — свой порт на сервере Connect: первому 5100 (VIDICAP_LAB_PORT), следующим 5101, 5102… Порт должен быть открыт в deploy/docker-compose.yml у службы hl7 (строка ${VIDICAP_LAB_PORT:-5100}:…; для второго анализатора добавьте такую же строку с его портом). Соединения держит та же служба hl7, что принимает мониторы: после сохранения анализатора она подхватывает его сама, в течение 10 секунд, перезапуск не нужен. Подтверждено Mindray (2026-10-21) по логу BS-430: анализатор серий BS и CL всегда клиент, порт выбирает лаборатория, соединение постоянное с автоматическим переподключением, ответ ACK ждёт 10 секунд, иначе ошибка C06005 и повтор; реферэнсные диапазоны с анализатора обычно не идут (OBX-7 «-»), их держит справочник Connect; материал пробы (OBR-15) всегда по-английски: serum, plasma, urine, CSF, blood, timed, amniotic, urethral, saliva, cervical, synovial, other.
3. На самом анализаторе (шаги есть на карточке анализатора): Setup → System Setup → LIS Setup (Communication Setup): протокол HL7, IP сервера — адрес компьютера Connect, порт — порт анализатора в Connect, Auto-send results включить, Mode — Bidirectional и Auto Number Scanned Samples — если анализатор должен брать заявки из Connect (раздел «Заявки и двунаправленная связь» ниже), Send QC results — если хотите видеть контроль качества в журнале. Без двунаправленной связи пробу заносят на анализаторе со штрихкодом или номером истории болезни из МИС: по нему Connect найдёт койку.
4. «Проверка связи» на карточке показывает состояние: анализатор на связи (с какого адреса и с какого времени), последнее сообщение, последняя ошибка. Позвонить анализатору Connect не может — тот подключается сам, когда отправляет результат; проверить путь проще всего, отправив результат из истории анализатора.

Как результат попадает на койку

Анализатор присылает ORU^R01: в PID — номер пациента (PID-2 или PID-3 у BA-88A) и ФИО, в OBR — штрихкод пробы (OBR-2), номер пробы (OBR-3), материал (OBR-15), cito (OBR-5), в OBX — по строке на тест: номер канала (OBX-3), аббревиатура (OBX-4), значение (OBX-5), единица (OBX-6), флаг анализатора (OBX-8: N, H, L, HH, LL, <, >), повтор (OBX-17), разведение (OBX-23). MSH-16 говорит, что это: 0 — проба пациента, 1 — калибровка, 2 — контроль качества. На каждое сообщение Connect отвечает ACK AA сразу — иначе Mindray повторяет сообщение и тревожит лабораторию; нечитаемое сообщение получает AR и попадает в журнал с ошибкой.

Пациент — только по номеру. Штрихкод, номер пробы и номер из PID сравниваются с номером истории болезни, который МИС назвала на занятой койке (API PUT /beds/{id}/patient или ADT A01) и с номером пациента в открытом протоколе (анестезии в операционной, суточном листе койки). Совпало — проба ложится на эту койку или операционную. Не совпало — проба «без пациента»: её видно на странице модуля и на экране палаты, сестра назначает койку выбором из списка, назначение (кто, когда) записывается в журнал; кнопка «Проверить по номерам ещё раз» подбирает койки тем пробам, которые пришли раньше, чем МИС назвала пациента (то же делает служба раз в час). ФИО, которое присылает анализатор (PID-5), Connect не читает и не хранит — как и ФИО с мониторов: пациент тот, кого назвала МИС или сестра. Повторно присланное сообщение (ACK не дошёл, анализатор перезапущен и начал нумерацию заново) результаты не удваивает: проба одна по анализатору, штрихкоду, номеру и времени, результат один по пробе, каналу, времени измерения и признаку повтора.

Флаги и критичность. Стрелка ↑↓ — флаг анализатора, если он прислал, иначе по норме из справочника. Критично — всегда по пределам справочника: лаборатория решает, что будит врача. Критический результат пробы, лежащей на койке или в операционной, делает уведомление вида «ОИТР, Палата 1, Койка 3: Калий 6,1 ммоль/л ↑ — критично (лаборатория)» дежурным отделения по правилам «Уведомлений врачам» (эскалация, «Принял», журнал); у пробы без пациента уведомление появится, когда сестра назначит койку. Один результат — одно уведомление, через 30 минут оно закрывается само (остаётся в журнале).

На странице койки карточка «Vidicap Lab» — тесты × три последние пробы этого пребывания (предыдущего пациента на койке не показывает), норма, стрелки, критическое подсвечено; «Все результаты» (/connect/lab/bed/<койка>/) — до 30 проб, с кнопкой «Не этой койки» у каждой (проба возвращается в «без пациента»). Операционная: та же карточка на странице «Показатели пациента», когда у операционной есть результаты (проба легла по номеру из открытого протокола анестезии). Телефон (приложение «Vidicap ICU») показывает ту же карточку. Кто видит: врачи и сёстры отделения (членство) и администраторы организации — как страницу койки; страницы модуля, справочник и журнал — только администраторы.

Справочник тестов

/connect/lab/catalog/ — 40 типовых тестов биохимии и иммунохимии Mindray и 32 теста гематологии по группам (электролиты, почки, печень, глюкоза, липиды, белки, воспаление, кардиомаркеры, газы и лактат, гормоны, ферменты, гематология): код Lab и LOINC, название, канал (OBX-3 — номер, который анализатор присвоил тесту; Connect запоминает его сам по аббревиатуре при первом результате), аббревиатура (OBX-4), единица, норма от/до, критично ниже/выше, включён. Правятся прямо в строке. Референсы и критические пределы — типовые взрослые, уточнить в лаборатории по своему методу и реагентам. «Добавить тест» — свой тест (для всех анализаторов или для одного; строка анализатора главнее общей для того же канала), «Вернуть удалённые типовые» — добавляет недостающие строки, не трогая изменённые. Тест, которого нет в справочнике, всё равно показывается на койке по аббревиатуре с анализатора, без нормы и критичности, и помечен на карточке анализатора «нет в справочнике».

Коды тестов на приборе

Анализатор называет тесты своими кодами (OBX-3; на BS-430 — LIS Setup → код канала: CREA-S, T-Bil-D II, y-GT…), и один и тот же тест на двух анализаторах может зваться по-разному. На карточке анализатора таблица «Коды тестов на приборе»: код на приборе → тест справочника. Connect заполняет её сам: каждый код из пришедших результатов появляется в таблице — с тестом, если аббревиатура (OBX-4) нашлась в справочнике, иначе «не сопоставлен» — лаборатория выбирает тест из списка; «Добавить автоматически из последних сообщений» делает то же для уже пришедших результатов (последние 500). Строка таблицы главнее справочника: если лаборатория сказала, что канал 11 — это натрий, результат по каналу 11 ложится в натрий, что бы ни стояло в OBX-4. Теми же кодами Connect называет тесты в заявках анализатору (DSR): без строки в таблице берётся канал из справочника, а без него — аббревиатура теста (на BS-430 код по умолчанию совпадает с ней).

Гематология: BC через labXpert

Гематологические анализаторы Mindray серии BC (BC-5000, BC-6800, BC-6000…) подключаются к ЛИС через промежуточное ПО labXpert (протокол Mindray «labXpert Communication Protocol 14.0», получен от Mindray 2026-10-22). Это тот же HL7 2.3.1 по MLLP, что и у биохимии, но с особенностями, и Connect понимает их сам — анализатор заводится как обычный, протокол Mindray HL7 2.3.1, кодировка UTF-8 (labXpert пишет UNICODE в MSH-18, Connect повторяет её в ответе):

• Код теста — LOINC. Вместо номера канала в OBX-3 приходит 6690-2^WBC^LN; свои показатели Mindray кодирует как 10002^PCT^99MRC. Справочник знает LOINC-коды всех тестов общего анализа крови (WBC, лейкоцитарная формула — абсолютные и процентные, RBC, HGB, HCT, MCV, MCH, MCHC, RDW-CV/SD, PLT, MPV, PDW, тромбокрит, P-LCR, P-LCC, незрелые гранулоциты, нормобласты, ретикулоциты, СОЭ) и коды Mindray, так что результат ложится в нужный тест сразу, без таблицы «Коды тестов на приборе». PCT гематологии — тромбокрит, а не прокальцитонин: Connect различает их по коду 10002.
• Служебные строки не результаты. В сообщении есть OBX с режимом прогона (Take Mode, Blood Mode, Test Mode CBC+DIFF, референсная группа, материал, штатив и позиция пробирки) — Connect хранит их при пробе и показывает режим в строке пробы; гистограммы и скатерограммы (base64 и их метастроки) пропускает; возраст, примечание и «пользовательские поля пациента» не читает (там может быть что угодно о пациенте).
• Флаги подозрения. Строки …-IM (Blasts, Abn Lympho, Left Shift, Atypical Lympho…) — не результаты, а подозрения анализатора: значение против порога из OBX-7. Сработавшие (значение достигло порога) показаны у пробы жёлтой меткой «подозрение: Left Shift» на странице «Все результаты» и в списке проб без пациента. Двойной флаг H~A читается как H.
• Материал берётся из строки Sample Type (Venous blood → кровь), раз OBR-15 у BC пустой.
• Контроль качества приходит с Q в MSH-11 (а не с «2» в MSH-16, как у BS): лот в PID-3, уровень (L/N/H) — отдельной строкой, у каждого теста результат, целевой диапазон и флаг. В журнале «Контроль качества» — по строке на тест с лотом, уровнем и диапазоном; на койки не попадает.
• Двунаправленная связь у BC — не QRY^Q02, а ORM^O01 с номером пробирки в ORC-3 (ORC|RF||<штрихкод>|BL). Connect отвечает ORR^O02: при заявке — MSA|AA, номер пациента (ФИО, дата рождения и пол — только из МИС, как в DSR), ORC|AF, OBR с тем же номером и обязательная строка Test Mode — по тестам заявки: CBC, CBC+DIFF, +RET, +ESR (заявка без тестов гематологии получает CBC+DIFF); без заявки — MSA|AR. Ответ хранится в журнале без ФИО. Уведомления labXpert о загрузке пробирок (ORM^N01…N07) получают обычный ACK.

Внимание (ответ Mindray, 2026-10-22): в двунаправленном режиме анализатор, не получив заявку вовремя, останавливается с тревогой и ждёт. Поэтому Bidirectional на анализаторе включают только там, где заявки действительно идут в Connect (из МИС или с формы); без заявок оставляют односторонний режим — результаты приходят так же. Остальное, что подтвердил Mindray: записи всегда в UTF-8; BS и CL — всегда клиент, соединение постоянное с автопереподключением; номера каналов по умолчанию не заданы, списков референсных диапазонов у анализатора нет (их держит справочник Connect); OBX-5 — значение для показа, OBX-13 — измеренное. Стенд пока играет только биохимию; виртуальный BC появится в еженедельной доработке стенда.

Заявки и двунаправленная связь

Заявка — что сделать с пробиркой: штрихкод, пациент (койка и/или номер в МИС), тесты (коды справочника: K, NA, CL, CREA, UREA, GLU…), срочность, материал, при желании — какой анализатор. Приходит тремя путями:

• Из МИС по API — POST /api/v1/lab/orders (раздел «API», право «лаборатория» или «кто на койке»): {"barcode": "14944109", "mrn": "2026-4471", "tests": ["K", "NA", "CREA"], "priority": "stat"}; по mrn Connect находит койку, которую МИС назвала; повторный POST с тем же штрихкодом обновляет открытую заявку.
• Из МИС по HL7 — ORM^O01 на тот же порт, что ADT (страница «Приём ADT», там же пример): ORC-2 — номер заявки, он же штрихкод; PID-3 — номер пациента; PV1-3 — место; OBR-4 — коды тестов через ~; OBR-5 S — cito; OBR-15 — материал; ORC-1 CA отменяет.
• Вручную — кнопка «Заявка на анализ» на карточке «Vidicap Lab» страницы койки и страница /connect/lab/orders/ (врачи и сёстры отделения): койка или номер пациента, штрихкод (пустой — Connect придумает сам: VC + дата + номер; его пишут на пробирке), тесты галочками, срочность, материал. Ничего не печатается.

Двунаправленная связь. На анализаторе включены Mode — Bidirectional и Auto Number Scanned Samples (LIS Setup). Лаборант сканирует штрихкод пробирки, анализатор спрашивает Connect (QRY^Q02, в QRD-8 — штрихкод). Connect отвечает двумя сообщениями подряд, как это делает ЛИС в логе BS-430: QCK^Q02 с QAK|SR|OK и DSR^Q03 с заявкой — DSP-1 номер пациента, DSP-3/4/5 ФИО, дата рождения, пол, DSP-15 стационар, DSP-21 штрихкод, DSP-23 время, DSP-24 cito, DSP-26 материал, с DSP-29 — коды тестов, как они заданы на приборе (таблица «Коды тестов на приборе»). Анализатор отвечает ACK^Q03 и делает тесты сам; заявка на странице становится «передана анализатору». Если заявки по штрихкоду нет (или ей больше 14 дней, или она отменена) — QAK|SR|NF: анализатор ждёт, что пробу заведут вручную, как без связи. Результаты приходят обычным ORU^R01, проба указывает на заявку, ложится на койку заявки (даже если МИС не называла номер на койке) и заявка — «выполнена». Заявка, адресованная одному анализатору, отдаётся только ему; без анализатора — любому, кто спросит по штрихкоду.

ФИО в заявке — только из МИС. В DSR Connect пишет номер пациента всегда, а ФИО, дату рождения и пол — только если их назвала МИС (ADT или API) на койке заявки или они есть в открытом протоколе (из МИС или вписаны врачом); ФИО с монитора или с самого анализатора никогда. В журнале анализаторов DSR хранится без этих строк (***).

Список заявок — на странице модуля (последние), на карточке анализатора (адресованные ему) и на /connect/lab/orders/ (открытые, новые, переданные, выполненные, отменённые; «Отменить» у открытой). Состояние заявки отдаёт и GET /api/v1/lab/orders.

Лаборатория в протоколах, API, вебхуках и у получателей

• Протоколы Приказа 254: на странице протокола анестезии и суточного листа блок «Лаборатория» — пробы койки (операционной) за период протокола, по строке на результат: тест, значение, единица, флаг, время. В PDF протокола анестезии результаты идут отдельным листом после сетки (только когда они есть — пустой бланк не меняется); в суточном листе — строкой в «Лабораторные исследования» листа 2, а в графе «Обследования» листа 1 у биохимии, электролитов и глюкозы проставляется время пробы.
• API: GET /api/v1/lab/results?from=&to=&bed=&critical=1 — пробы коек ключа с результатами (код справочника и LOINC, значение, единица, флаг и его источник, критично, норма, повтор, разведение, время); patient — только ключу с «данные пациента». GET/POST /api/v1/lab/orders — заявки.
• Вебхуки: событие lab_result (галочка «результаты лаборатории» у вебхука) — проба легла на койку: та же запись, что в API; данные пациента — только с «данные пациента в теле».
• Получатели HL7: галочка «результаты лаборатории» у получателя — на каждую пробу, лежащую на койке или в операционной, ORU^R01 с OBX на результат (код^название^VIDICAP-LAB^LOINC^…^LN, значение, единица, норма, флаг, время, анализатор в OBX-18), PV1 с местом; PID — только получателю «Передавать как пришли» и только с ФИО из МИС. Очередь и повторы — как у показателей.
• Пробы без пациента никуда не уходят, пока сестра не назначит койку; контроль качества и калибровки не уходят никогда. Выгрузка в папку и FHIR лабораторию пока не отдают.

Журнал, контроль качества, хранение

• Журнал анализаторов (/connect/lab/journal/): каждое сообщение — время, анализатор, адрес, тип, контрольный номер, ответ (AA/AR), сколько результатов, ошибка, текст без сегмента PID; у каждого анализатора хранятся последние 200. Назначения проб сёстрами — там же (тип attach), ответы анализатору на запрос заявки — тип DSR^Q03 без ФИО.
• Контроль качества и калибровки: сообщения с MSH-16 = 2 и 1 — на странице модуля (последние 20) и в базе (последние 2000 у анализатора): канал, тест, уровень, среднее и SD, результат, единица, флаг. На койки не попадают.
• Хранение: пробы с результатами старше «Сколько дней хранить результаты» удаляет служба hl7 раз в час. Всё — пробы, результаты, журнал, контроль, заявки — на сервере больницы; наружу — только в API, вебхуки и получателям HL7 на этом же сервере (раздел выше).
• Стенд: при включённом стенде («Стенд: виртуальная реанимация») появляется анализатор «Биохимия 1» и виртуальный Mindray, который шлёт пробы трёх пациентов стенда каждые 20 секунд и контроль качества после каждой пятой; кнопки «Калий критично», «Проба без пациента», «Анализатор молчит». Анализатор стенда двунаправленный: на каждую вторую пробу заглушка МИС сначала даёт заявку через API, анализатор спрашивает по штрихкоду, получает DSR и делает только заказанные тесты, остальные пробы идут без заявки (NF); в авто-прогоне семь проверок лаборатории.

Что дальше

Этап 3: ASTM E1394 и анализаторы с RS-232 через серийный сервер (поле «Серийный порт» уже есть, но пока не работает); лаборатория в FHIR (Observation, ServiceRequest) и в выгрузке в папку; другие формы запроса анализатора (по номеру пробы, за период) — сейчас заявка отдаётся только по штрихкоду.

Палаты подчинённых серверов

Если этот Connect подключён к главному серверу больницы (или главный сервер видит Connect другого корпуса), врачи главного сервера могут смотреть его палаты как свои. Как подключить и отметить палаты — в инструкции «Связь серверов», раздел «Палаты подчинённого Connect на главном сервере».

1. На главном сервере врач открывает плитку «Палаты». Палаты Connect стоят среди остальных в своём отделении; вверху справа пометка «с сервера «…»».

2. Всё работает как на самом Connect: плитки коек, счётчики тревог, NEWS2, «Кривые на плитках», карточка койки с кривыми, трендами и тревогами. Пациент на плитке — фамилия и инициалы, в карточке — полное ФИО и возраст.
3. Отметить событие можно и с главного сервера. Отметка сохраняется на Connect, где лежит койка, и подписана «ФИО врача, название главного сервера». Удалить её может тот же врач или администратор организации.

4. На телефоне — так же, как на самом Connect.

5. Нет связи. Если Connect не отвечает, вверху красным «Нет связи с сервером «…» N мин», плитки серые, показателей нет (старые цифры не показываются, чтобы не ввести в заблуждение). На самом Connect и у мониторов при этом всё работает.

Данные идут на главный сервер, только пока страницу палаты или койки кто-то открыл, хранятся там только в памяти (не дольше 2 минут) и в облако vidicap.cloud не передаются. Первое открытие палаты занимает до 5 секунд, дальше обновление каждые 3 секунды, кривые — с задержкой около 1,5 секунды.

События и данные для обучения ИИ

Это первый этап модуля ИИ «Оценка состояния»: модели ещё нет, Connect копит то, на чём она будет учиться. Первая модель — предсказание гипотензии.

1. В карточке койки, раздел «События», выберите, что случилось (интубация, экстубация, начата НИВЛ, начаты или отменены вазопрессоры, остановка кровообращения, перевод из ОРИТ, смерть, другое ухудшение), поправьте время, если событие было раньше, и нажмите «Отметить событие». Время после текущего считается вчерашним (23:50, отмеченное в 00:10).
2. Свою отметку можно удалить (администратор — любую). Видны события за 3 дня.
3. Гипотензию Connect отмечает сам: среднее инвазивное АД ниже 65 мм рт. ст. не меньше 5 минут без перерывов дольше минуты, а без инвазивного — два измерения НИАД подряд ниже 65 в пределах 30 минут. Такие события подписаны «Connect, по данным монитора». Пересчёт — каждые 5 минут.
4. Когда монитор присылает нового пациента, Connect отмечает смену пациента на койке ключом (не ФИО): так пребывания разделяются для обучения, а имя из ключа узнать нельзя.
5. Каждую ночь (после 00:15) Connect пишет за прошедшие сутки файл на каждую койку: значение каждого показателя за каждую минуту, число тревог в минуту, события. Файлы лежат на компьютере Connect в files/connect/series/ГГГГ/ММ/ДД/, без ФИО, хранятся VIDICAP_CONNECT_SERIES_DAYS дней (по умолчанию 730). Сами 15-секундные показатели по-прежнему хранятся 30 дней.

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

Уведомления врачам в Telegram

Дежурный врач отделения получает в Telegram сообщение, когда у койки что-то требует внимания, а у монитора никто не отреагировал: тревога держится несколько минут, монитор занятой койки замолчал, Connect нашёл гипотензию. Одно событие — одно сообщение с кнопками «✅ Принял» и «Открыть койку». Не принято — сообщение уходит второму дежурному, потом заведующему.

Это не замена тревог. Тревоги звучат на мониторе и центральной станции, бот только напоминает тем, кого нет у койки. Telegram не гарантирует доставку, а серверу нужен интернет. Об этом сказано в боте, в настройках и здесь.

Данные пациента. В Telegram уходят только отделение, палата, койка и событие («SpO₂ ниже предела, 3 мин»). ФИО, номер истории, возраст и пол пациента не уходят никогда, в любом режиме. Журнал (кому, когда, кто принял) хранится только на сервере больницы.

Шаг 1. Бот больницы (администратор)

1. В Telegram откройте @BotFather, команда /newbot, задайте имя (например, «Уведомления Больница 1») и логин бота. BotFather выдаст токен вида 123456789:AAH….
2. На компьютере Connect впишите токен в .env: VIDICAP_TELEGRAM_BOT_TOKEN=123456789:AAH…. Если врачи открывают сервер не по адресу VIDICAP_PUBLIC_HOST (например, по VPN), укажите адрес для кнопки «Открыть койку»: VIDICAP_CONNECT_PUBLIC_URL=https://vidicap.local.
3. docker compose up -d. Отправкой и приёмом «Принял» занимается служба cloudlink (та же, что связь с главным сервером); ей нужен выход в интернет к api.telegram.org.

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

Шаг 2. Врач привязывает Telegram

1. «Настройки» (главное меню) → «Уведомления в Telegram» (кнопка есть и на экране палаты). Нажмите «Получить код»: шесть цифр, действуют 10 минут.

2. Откройте бота больницы в Telegram и отправьте ему код (или /start и код одним сообщением). Бот ответит «Привязано», на странице появится «Привязан: @логин · проверено». «Отправить тест» проверяет доставку.
3. «Мои отделения»: включите отделения, с коек которых присылать. Список берётся из вашего членства на платформе (администратор: «Организации» → организация → сотрудник → отделение).

Шаг 3. Дежурство

Сообщения приходят только дежурному. Отметьте «На дежурстве до 08:00» (до ближайшей смены) или «На 12 часов»; «Закончить дежурство» снимает отметку раньше. Вне дежурства приходит только вызов по эскалации (если вы второй дежурный или заведующий). Выключатель «Не беспокоить вне дежурства» можно снять: тогда сообщения отделения приходят всегда.

График дежурств отделения и дежурные из МИС — следующий этап.

Шаг 4. Настройки отделения (заведующий или администратор)

«Журнал уведомлений» → «Настройки отделения» (администратор Connect: «Уведомления» → отделение → «Настройки отделения»). Заведующего назначает администратор организации в этих же настройках; потом заведующий меняет их сам.

• Когда присылать: тревога высокого приоритета держится N минут (по умолчанию 3); среднего (по умолчанию выключено, 0); монитор занятой койки молчит (5 мин: койка с пациентом или с данными за последние часы); гипотензия (ср. АД < 65) дольше 5 мин — та, что Connect находит сам; «Тишина ночью» (22:00–07:00): только высокий приоритет и гипотензия. Порог риска ухудшения (ИИ) записывается, но заработает, когда будут модели.
• Кто получает и эскалация: дежурные врачи отделения — сразу; не принято за 5 минут — второму дежурному; за 10 минут от начала — заведующему (минуты настраиваются). Если дежурных сейчас нет, сообщение сразу идёт второму дежурному, а без него — заведующему. Ниже видно, кто сейчас на дежурстве и кто привязал Telegram. Можно слать и в группу отделения в Telegram: добавьте бота в группу и впишите её chat id.
• Что видно в сообщении: «Строгий» — только «ОРИТ, Палата 1, Койка 5: новое уведомление»; «Событие» (по умолчанию) — «SpO₂ ниже предела, 3 мин», без значений; «Событие и значения» — ещё «SpO₂ 86 %, ЧСС 118, АД 90/50». Данных пациента нет ни в одном режиме.

Что приходит и как принять

• 🔴 — тревога высокого приоритета, 🟠 — среднего, монитор молчит, гипотензия; ⏫ — эскалация («дежурный не ответил 5 мин»). Повторы той же тревоги на той же койке новых сообщений не дают, пока она не закончилась.
• «✅ Принял» — остальным, кто получил сообщение, оно перепишется: «✅ Принял: Петров А.С., 14:06», эскалация останавливается. На экране «Палаты» на плитке койки появляется «Принял: … 14:06», пока событие длится.
• «Открыть койку» — карточка койки на сервере больницы: из сети больницы или по VPN, после входа.
• Событие закончилось, а никто не принял — всем получившим приходит «закончилось в 14:12. Никто не принял: записано в журнал».
• Нет интернета или не задан токен — уведомление помечено «не отправлено» и повторяется, пока событие длится; это видно в журнале.

Журнал уведомлений

«Журнал уведомлений» (врач: «Настройки» → «Уведомления в Telegram» или адрес /connect/notify/; администратор: Connect → «Уведомления»): время, койка, событие, кому отправлено (цепочка эскалации), кто принял и через сколько минут, «никто» или «не отправлено: нет интернета». Фильтры: отделение, сегодня / 7 дней, все / не принятые / эскалации. Врач видит отделения своего членства, заведующий — своё, администратор — все.

Уведомления через vidicap.cloud (сервер без интернета)

Сервер больницы часто не имеет выхода в интернет: ни к api.telegram.org, ни к службам push Apple и Google — только связь с vidicap.cloud (см. «Связь серверов»). Тогда уведомления отправляет общий бот Vidicap, а push — само облако, по той же связи.

Как переключить (администратор Connect). «Настройки» → «Уведомления в Telegram» → карточка «Канал доставки»: «Свой бот больницы» (токен в .env, как в шаге 1) или «Общий бот Vidicap через vidicap.cloud». Второй вариант доступен, только когда сервер подключён к облаку («Подключение сверху»); иначе он серый с подсказкой. «Сохранить» — и с этой секунды сообщения идут через облако; токен бота больницы не нужен.

Что идёт через облако. Ровно то, что пришло бы в Telegram и на телефон и так: отделение, палата, койка, событие (по режиму отделения: строгий / событие / событие и значения), кнопки, номер чата, подписка push телефона (адрес службы push и два ключа, которые дал браузер). ФИО, номер истории, возраст пациента не уходят никогда — их нет в тексте уведомления ни в одном режиме, это проверяется тестами. Сообщение отправляется облаком прямо во время связи (каждые несколько секунд; новое уведомление запускает связь сразу) и нигде не сохраняется: в облаке остаются только счётчики по серверу за день (отправлено / не доставлено) и привязка «чат Telegram → сервер больницы», чтобы «Принял» из чата вернулся на нужный сервер. Текст сообщений, подписки и журнал — только на сервере больницы.

Что делают врачи. 1. Привязка Telegram — как в шаге 2, но бот общий: его имя показано в карточке «Канал доставки» и в шаге «1. Привязать Telegram». Код выглядит как a1b2c3-123 456: буквы перед дефисом говорят общему боту, чья это платформа (их можно вводить в любом регистре, дефис необязателен). Привязка, сделанная через своего бота, при смене канала остаётся. 2. Push нужно включить заново один раз на каждом телефоне: облако подписывает уведомления своим ключом, а телефон подписан на ключ сервера больницы (и наоборот при переходе обратно). Страница «Дежурство» показывает «включите заново: канал доставки сменился» и кнопку «Включить push заново»; сколько телефонов ещё со старым ключом, видно в карточке push. Пока телефон не переподписан, push на него не уходит. 3. «✅ Принял», «👍 Полезно» / «👎 Не по делу», коды — всё как раньше: облако передаёт нажатие на сервер больницы, сервер переписывает сообщения через облако.

Если связи с облаком нет, уведомление помечено «не отправлено: нет связи с vidicap.cloud» и повторяется, пока событие длится, как и без интернета у своего бота. Очередь ожидающих и число не доставленных за сегодня видны в карточке «Канал доставки». Сообщение, которое Telegram отверг (например, врач заблокировал бота), считается не доставленным и входит в этот счётчик; очередь отправок хранится на сервере 7 дней.

В облаке администратор организации видит на странице «Локальные серверы» у каждого сервера строку «Уведомления через облако: сегодня отправлено N, не доставлено M; чатов Telegram K». Общий бот работает в службе cloud_link облака с токеном VIDICAP_TELEGRAM_BOT_TOKEN облака; чат, который никто не привязывал, получает от бота одну строку: «Этот чат не привязан к больнице; введите код со страницы «Уведомления в Telegram»».

Приложение Vidicap ICU на телефоне (push)

Те же палаты и койки, открытые с телефона и добавленные на экран «Домой»: значок Vidicap ICU, полный экран, внизу вкладки «Палаты», «Уведомления», «Дежурство», «Профиль». Уведомления приходят на телефон как push — с кнопками «✅ Принял» и «Открыть» — те же события, пороги, дежурства и эскалация, что у бота в Telegram (один журнал на оба канала). Отдельно ставить ничего не нужно: приложение — это сервер больницы в браузере телефона.

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

Установить на iPhone

Нужен iOS 16.4 или новее. Push на iPhone работает только из приложения на экране «Домой», в Safari из вкладки — нет.

1. Откройте адрес сервера в Safari (на другом браузере на iPhone push не работает) и войдите. На экране палаты один раз появится подсказка с этими шагами.
2. Нажмите «Поделиться» (квадрат со стрелкой внизу Safari) → «На экран „Домой“» → «Добавить».
3. Откройте Vidicap ICU со значка. Вкладка «Дежурство» → карточка «Push в приложении» → «Включить push» → в окне iPhone «Разрешить». Появится «разрешены на этом телефоне»; «Отправить тест» присылает пробное уведомление.

Если push раньше запретили, разрешите его в iPhone: «Настройки» → «Уведомления» → Vidicap ICU. Там же — звук и показ на заблокированном экране. В беззвучном режиме iPhone показывает уведомление без звука.

Установить на Android

В Chrome откройте адрес сервера, войдите; появится предложение «Установить» (или в меню Chrome «Установить приложение» / «Добавить на главный экран»). Откройте Vidicap ICU со значка, на вкладке «Дежурство» нажмите «Включить push» и разрешите уведомления. Push в Android работает и из вкладки браузера, но из приложения удобнее.

На компьютере (Chrome, Edge) всё то же: «Включить push» на странице «Уведомления в Telegram» — уведомления будут показываться системой.

Дежурство и каналы

Вкладка «Дежурство» — это страница «Уведомления в Telegram» (см. выше): отделения, «На дежурстве до 08:00», «Не беспокоить вне дежурства». В карточке «Push в приложении» два выключателя: «Push в приложении» (телефоны, на которых включили push; видно, сколько их) и «Также в Telegram» (привязанный чат). Можно оставить только push, только Telegram или оба; выключенный канал не получает ни уведомлений, ни эскалации. «Отключить на этом телефоне» снимает push с одного телефона, остальные остаются.

Что приходит и как принять

• Уведомление: заголовок 🔴 «ОРИТ, Палата 1, Койка 3», текст «SpO₂ ниже предела, 3 мин» (по режиму отделения: строгий / событие / событие и значения). ФИО, номер истории и возраста пациента в push нет никогда.
• «✅ Принял» прямо на уведомлении (на iPhone — нажать и удерживать или потянуть, на Android — кнопка под текстом): уходит на сервер без открытия приложения; у остальных уведомление меняется на «✅ Принял: Петров А.С., 14:06», сообщения в Telegram переписываются, на карточках коек появляется «Принял: …».
• «Открыть» — карточка койки.
• Эскалация, «закончилось, никто не принял» и всё остальное — как в Telegram.

На экране «Палаты» в телефоне койки идут карточками в одну колонку: NEWS2, «тревога N мин», ЧСС, SpO₂ и АД крупно, строка тревоги, кнопки «✅ Принял» (пока уведомление по койке не принято) и «Кривые». «Принял» есть и в карточке койки.

Вкладка «Уведомления» — журнал того, что приходило вам (по всем вашим отделениям); «весь журнал» открывает журнал отделения.

Что нужно от сервера (администратор)

• Push доставляют серверы Apple и Google: компьютеру Connect (службе cloudlink) нужен выход в интернет к *.push.apple.com и fcm.googleapis.com, тот же, что к api.telegram.org. Без интернета уведомление «не отправлено», как у бота, и уходит, когда связь вернётся и событие ещё длится. Сервер без интернета отправляет push через vidicap.cloud — см. «Уведомления через vidicap.cloud»: облако шифрует уведомление для телефона и отправляет само, телефоны подписываются на ключ облака (push включают заново один раз после смены канала).
• Ключи для push (VAPID) сервер делает сам при первом включении и хранит в базе; ничего настраивать не надо. Чтобы сохранить ключи при переезде на другой сервер (иначе врачам придётся включить push заново), впишите их в .env: VIDICAP_VAPID_PRIVATE_KEY, VIDICAP_VAPID_PUBLIC_KEY; manage.py connect_vapid показывает публичный ключ.
• Телефоны открывают сервер по HTTPS (адрес из VIDICAP_PUBLIC_HOST или VIDICAP_CONNECT_PUBLIC_URL); по голому HTTP приложение не ставится и push не работает.
• Старые подписки (телефон сменили, доступ отозвали) сервер удаляет сам, когда служба push отвечает «нет такой».

Это не медицинская тревога. Push и Telegram не гарантируют доставку (телефон вне сети, режим «Не беспокоить», настройки системы): тревоги звучат на мониторе и центральной станции, приложение только напоминает тем, кого нет у койки. Вход по Face ID и звук тревоги в приложении — следующие этапы.

API для МИС, ЛИС и других систем

Любая система больницы — МИС, ЛИС, отчёты в Excel, своя программа — читает данные Connect по открытому API и сообщает, кто на койке. Описание в формате OpenAPI 3 лежит прямо на сервере (/api/v1/openapi.json), страница с примерами — Connect → «Интеграция» → «Описание API». Адреса начинаются с /api/v1/, ответы — JSON.

Где это работает. Только на сервере больницы, только из сети больницы и только по HTTPS (HTTPS даёт Caddy перед платформой, как и для всего остального). vidicap.cloud ключей не имеет и запросы к API не проксирует: в облако по-прежнему уходят только состояние Connect и обезличенные показатели, пока кто-то смотрит.

Шаг 1. Ключ для системы

Connect → «Интеграция» → «+ Новый ключ» (администратор Connect):

• Название системы — как её видно в журнале («МИС «Клиника»»).
• Права: «чтение показателей и тревог» (все запросы GET), «кто на койке (запись)» (PUT и DELETE /beds/{id}/patient), «лаборатория» (заработает с модулем «Лаборатория»).
• Отделения — ничего не отмечено: ключ видит все; отмечены — остальные отвечают 403.
• Данные пациента в ответах — выключено по умолчанию: вместо ФИО, даты рождения и номера приходит ключ пребывания stay (один и тот же для одного пациента на этом сервере, по нему не восстановить ФИО). Включайте только для МИС, которой это нужно.
• Срок действия и вызовов в минуту (по умолчанию 60).

Ключ вида vck_live_… показывается один раз: скопируйте его в настройки системы. Потерян — создайте новый, старый отзовите («Отозвать»: вызовы с ним получают 401). В базе хранится только хэш ключа.

Шаг 2. Запросы

Каждый запрос несёт заголовок Authorization: Bearer vck_live_…. Проверка из командной строки:

curl -H "Authorization: Bearer vck_live_…" https://connect.hospital.local/api/v1/beds

Пример ответа GET /api/v1/beds/12/latest без права «данные пациента»:

{"bed": {"id": 12, "name": "Койка 3", "ward": {"id": 2, "name": "Палата 1"}, "department": {"id": 1, "name": "ОРИТ"}},
 "stay": "k7f2a91c3e0d4b55", "patient": null, "at": "2026-10-13T14:08:49+03:00",
 "vitals": {"hr": {"value": 118, "unit": "уд/мин", "label": "ЧСС", "at": "…"},
            "spo2": {"value": 86, "unit": "%", "label": "SpO₂", "at": "…", "alarm": "high"},
            "nibp": {"sys": 122, "dia": 74, "mean": 90, "unit": "мм рт. ст.", "label": "НИАД", "at": "…"}},
 "alarms": [{"text": "ниже предела", "parameter": "spo2", "value": 86, "priority": "high", "since": "…"}],
 "device": {"id": 7, "name": "Mindray ePM 12", "online": true}, "news2": {"score": 7, "risk": "high"}}

Кто на койке. После PUT /beds/{id}/patient на экране палаты врачи видят ФИО из МИС, а не с монитора, и оно держится, пока МИС не выпишет пациента (DELETE) или монитор не перевяжут на другую койку; начинается новое пребывание stay (событие patient у койки, оно уходит и получателям HL7 с событиями). Пока МИС молчит, имя берётся с монитора (PID). Койка без монитора отвечает 409: некому назначить пациента. ФИО хранится только на этом сервере и уходит только получателям HL7, которым это разрешено.

Ошибки и лимиты

Ошибка — JSON {"error": "…", "detail": "…"}: 400 неверные параметры, 401 нет ключа, ключ отозван или истёк, 403 нет права или отделение не разрешено, 404 нет такой койки, 405 неверный метод, 409 на койке нет монитора, 429 превышен лимит. Лимит — 60 вызовов в минуту на ключ (скользящее окно, число задаётся на ключе): заголовки X-RateLimit-Limit, X-RateLimit-Remaining, при 429 — Retry-After.

Журнал вызовов

«Интеграция» → «Журнал вызовов»: время, система, запрос, код ответа и что сделано («Койка 3: пациент принят», «403 Отделение «Кардиореанимация» не разрешено этому ключу»), время ответа. Фильтры: сегодня / 7 дней, все / ошибки / запись, система. Журнал хранится 90 дней; ФИО, номера и тела ответов в журнал не попадают. На странице ключей у каждого виден последний вызов и сколько вызовов в минуту идёт сейчас.

Вебхуки: Connect сам сообщает системе

Вместо опроса API система может получать POST от Connect: тревоги, события койки, риск ухудшения модуля «ИИ: оценка состояния», последние значения всех коек раз в N минут.

1. «Интеграция» → карточка «Вебхуки» → «+ Адрес» (администратор Connect): название системы, адрес (только https://), что слать — «тревоги» (событие alarm: начало тревоги монитора, повтор той же не чаще раза в 5 минут), «события койки» (event: отметки врачей, гипотензия, новый пациент), «риск ухудшения» (risk: риск поднялся выше порога отделения), «значения всех коек» раз в минуту, 5, 15 минут или час (values: массив, как GET /beds/{id}/latest по каждой койке, одной отправкой); отделения; переключатель «данные пациента в теле» (выключен — вместо ФИО ключ stay).
2. Секрет подписи показан на странице вебхука: впишите его в настройки системы. Каждый POST несёт заголовки X-Vidicap-Event (alarm, event, risk, values, test), X-Vidicap-Delivery (номер отправки) и X-Vidicap-Signature: sha256=<HMAC-SHA256 тела секретом>. Система проверяет подпись и отвечает любым кодом 2xx. Тело — JSON {"event": "alarm", "time": "…", "data": {…}}, data в тех же формах, что ответы API.
3. «Сохранить и отправить пробный» (или «Отправить пробный» на странице «Интеграция»): событие test уходит сразу, ответ виден в сообщении и в журнале вебхука.
4. Пока система не отвечает, отправки ждут в очереди на диске, как сообщения получателей HL7: та же отправка повторяется через 30 с, 1, 5, затем 15 мин; после 5 попыток откладывается, остальные идут дальше по порядку; ожидание ответа 10 с. После 100 недоставленных подряд вебхук выключается, инженеры получают уведомление бота (см. «Уведомления врачам»); включите его снова на странице вебхука, когда система заработает.
5. Журнал последних отправок — на странице вебхука (когда, событие, код ответа, время, ошибка; хранится 7 дней, тела в журнал не попадают); состояние каждого вебхука — на карточке «Интеграции».

Приём HL7 ADT: кто на койке из МИС

Для МИС, которые умеют только HL7: ADT^A01 (поступление), A02 (перевод), A03 (выписка), A08 (изменение) по MLLP на порт 2576 сервера Connect (VIDICAP_CONNECT_ADT_PORT; слушает та же служба hl7, что принимает мониторы на 2575) — то же, что PUT и DELETE /beds/{id}/patient.

1. В МИС укажите адрес сервера Connect и порт 2576; место пациента — в PV1-3 как отделение^палата^койка (например ICU^1^3), номер — PID-3, ФИО — PID-5, дата рождения — PID-7, время поступления — PV1-44; у перевода A02 прежнее место — PV1-6 (оно освобождается).
2. Место сопоставляется с койкой так же, как у мониторов: по полю «место» койки на странице «Отделения и койки» (ICU 1 3 для ICU^1^3) или по таблице «Интеграция» → «Приём ADT: места и журнал». Пришло неизвестное место — сообщение получает AE, место появляется в списке «Места без койки»: выберите койку, нажмите «Назначить», следующее сообщение примется. Там же можно добавить место заранее и выключить приём ADT (тогда МИС получает AR).
3. Ответы ACK: AA принято; AE не применено — место не сопоставлено, на койке нет монитора, нет ни ФИО, ни номера; AR не принято — не HL7, не ADT, приём выключен.
4. После A01 на экране палаты врачи видят ФИО из МИС, начинается новое пребывание stay (событие patient, оно уходит и получателям HL7 с событиями и в вебхуки); имя держится до A03 или перевода. A08 с тем же пациентом пребывание не меняет.
5. Журнал последних 200 сообщений на той же странице: время, тип, место, койка, ответ; ФИО в журнал не попадает, от номера — три последние цифры.

Поток событий

GET /api/v1/stream — события по мере появления. Это server-sent events (text/event-stream), а не WebSocket: платформа работает под gunicorn без ASGI, а SSE читает любой клиент — EventSource в браузере, curl -N, библиотеки SSE для Python, Java, .NET.

1. Откройте поток с тем же ключом: curl -N -H "Authorization: Bearer vck_live_…" "https://connect.hospital.local/api/v1/stream?beds=12,13&every=30". Подписка — beds= или departments= (без них — все койки ключа); every — секунды между отправками значений (по умолчанию 60, не меньше 10, 0 — не слать).
2. События: hello (состав подписки), alarm (начало тревоги, повтор той же не чаще раза в 5 минут), event (событие у койки), risk (оценка модуля «ИИ» раз в минуту на койку), values (последние значения койки, как /beds/{id}/latest), renew. Каждое — строки event: <имя> и data: <JSON>; данные те же, что в GET /alarms, /events, /beds/{id}/latest.
3. Поток длится до 5 минут, затем сервер шлёт renew и закрывает его: клиент открывает новый (EventSource делает это сам по retry: 2000). Сервер держит не больше 8 потоков сразу (503 сверх того); каждое открытие — один вызов в лимите ключа и строка в журнале.

FHIR R4

То же в стандарте FHIR R4, только чтение, JSON; те же ключи, отделения, лимит и журнал вызовов.

1. Коды LOINC: 8867-4 ЧСС, 59408-5 SpO₂, 9279-1 ЧД, 8310-5 температура, 8889-8 пульс, 19889-5 EtCO₂, 3150-0 FiO₂; давление — одно Observation 85354-9 с component 8480-6 / 8462-4 / 8478-0 (НИАД) или 76215-3 / 76213-8 / 76214-6 (инвазивное). Единицы UCUM (/min, %, mm[Hg], Cel). ?code= принимает LOINC или коды API через запятую.
2. subject наблюдения — Patient/<stay>, пока на койке есть пациент, иначе Location/bed-<id>; койка всегда в расширении …/StructureDefinition/bed. Прочитать Patient может только ключ с правом «данные пациента»; остальным stay ничего не говорит.
3. Ошибки — как у всего API ({"error", "detail"}), не OperationOutcome.

Выгрузка в папку

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

1. Папки, куда можно писать, задаёт VIDICAP_CONNECT_EXPORT_DIRS в .env (через запятую; по умолчанию data/export платформы). Сетевую папку (SMB, NFS) смонтируйте в одну из них на компьютере Connect и пробросьте в контейнер hl7 томом docker-compose.
2. «Интеграция» → карточка «Выгрузка в папку» → «+ Выгрузка»: папка внутри разрешённых, формат CSV (разделитель ;) или JSON (объект в строке), как часто (раз в 5 или 15 минут, час, сутки), какие значения (последнее значение показателя в каждой минуте, 5 или 15 минутах), отделения, переключатель «данные пациента в файлах» (выключен — столбец stay).
3. Файлы — vidicap-<отделение>-<дата>.csv (или .json), по одному на отделение и день, дописываются с каждым запуском; столбцы time, department, ward, bed, stay, code, label, value, unit (+ patient, birth, mrn при включённом переключателе). Запускает служба hl7 (цикл отправки Connect); «Выгрузить сейчас» на странице — вручную.
4. Журнал последних запусков (когда, период, строк, файлы, ошибка) — на той же странице; ошибка последнего запуска видна и на карточке «Интеграции».

Лаборатория (модуль «Vidicap Lab»)

POST /api/v1/lab/orders — заявка: {"barcode", "tests": ["K", "NA"], "mrn" и/или "bed", "priority": "routine"|"stat", "specimen", "analyzer", "ordered"} → 201 и заявка; GET /api/v1/lab/orders?status=new|sent|resulted|cancelled — заявки; GET /api/v1/lab/results?from=&to=&bed=&critical=1 — пробы с результатами. Право «лаборатория» ключа покрывает всё; без него заявки требуют «кто на койке», результаты — «чтение». Подробно — в разделе «Vidicap Lab». Вебхук: событие lab_result. HL7: ORM^O01 на порт ADT, ORU^R01 получателям с галочкой «результаты лаборатории».

Что дальше

FHIR ServiceRequest/Observation для лаборатории и выгрузка результатов в папку.

Журнал

«Журнал» показывает:

• Не доставлено — сообщения, которые получатель отклонил 5 раз подряд (с причиной), и сколько сообщений пропало, потому что ждали дольше срока хранения. Отклонённые откладываются, чтобы не задерживать остальные;
• Последние сообщения от устройств — что прислали мониторы коек и неопознанные отправители (по 30 последних на устройство).

ФИО, номер истории и дата рождения пациента в журнале не показываются: они вырезаются перед выводом на экран.

Данные пациента и облако

• Всё, что принимает Connect, хранится только на компьютере Connect в больнице.
• Страницы «Состояние», «Отделения и койки», «Журнал» не показывают данных пациента. ФИО и возраст видны только на экране палаты врачам этого отделения и администраторам.
• Данные пациента уходят только тем получателям, у которых выбрано «Передавать как пришли от монитора», и только по сети больницы. Данные с Vidicap и выгрузка архива данных пациента не содержат никогда.
• Живые кривые проходят только через память Connect в браузер врача; хранятся только 6-секундные фрагменты тревог (30 дней).
• Палаты, отмеченные для сервера выше, видны врачам серверов больницы выше, пока страницу кто-то смотрит; там данные не хранятся.
• В облако vidicap.cloud Connect не отправляет ничего, кроме весов модели или обезличенных эпизодов модуля «ИИ: оценка состояния» — и только по выбору администратора (см. «Общее обучение через vidicap.cloud»), и текстов уведомлений врачам без данных пациента (отделение, палата, койка, событие) с подписками push — только если администратор выбрал канал «Общий бот Vidicap через vidicap.cloud»; облако их не хранит.

Стенд: виртуальная реанимация

Стенд — это Connect, которому не нужны ни мониторы, ни МИС: он сам ставит на этот же сервер демо-больницу на 20 коек и 2 операционные, 22 виртуальных монитора Mindray, которые шлют показатели, тревоги и кривые по HL7 на порт 2575 как настоящие, и заглушку МИС, которая присылает ADT, принимает вебхуки, ходит в API и принимает выгрузку по MLLP. Сценарии переключаются кнопками: гипотензия, десатурация, аритмия, брадикардия, монитор замолчал, датчик отключён, новый пациент, перевод, выписка, ночь; у виртуального анализатора «Vidicap Lab» — калий критично, проба без пациента, анализатор молчит. Всё, что Connect делает по этим данным — экран палаты, уведомления, протоколы, ИИ, вебхуки, выгрузка, — срабатывает само, и это видно на обычных страницах Connect. Стенд нужен, чтобы показать Connect без больницы, проверить обновление перед установкой и прогнать 46 сценариев одной кнопкой с отчётом. Больница стенда задаётся файлом files/connect/stand/hospital.json (без него — три отделения на 20 коек); своя больница любого размера, сценарий дня и пульт показывающего — это «Демо-режим» (раздел ниже).

Стенд есть только в локальной версии платформы с ролью connect и только для администраторов организации: Connect → «Настройки» → строка «Стенд: виртуальная реанимация» или кнопка «Стенд» в шапке (/connect/stand/). В облаке vidicap.cloud страницы нет (404), команда отказывает. Мониторы, заглушка МИС и получатель MLLP работают на 127.0.0.1 этого компьютера, в облако и в сеть ничего не уходит; пациенты стенда вымышленные.

Запустить

1. Куда ставить. На тестовый сервер или ноутбук с установленным Connect — не на сервер больницы: стенд делает свою организацию «Стенд Vidicap Connect» и переключает Connect на неё (Site.organization). Если Connect уже обслуживает другую организацию, стенд отказывается; --force (и кнопка «Пересоздать больницу») переключает, и администратор, нажавший кнопку, становится администратором организации стенда, чтобы не потерять доступ к страницам Connect.
2. «Запустить» на странице стенда — то же, что docker compose exec web python manage.py connect_demo в терминале. Стенд строит больницу (три отделения: ОИТР с палатами 1 и 2, Кардиореанимация, Хирургия с ПИТ и двумя операционными), пользователей stand-doctor, stand-nurse, stand-head, stand-admin (пароли печатаются один раз в терминал и лежат в files/connect/stand/accounts.txt на компьютере Connect, доступ только владельцу файла), ключ API «Стенд МИС» (секрет в api-key.txt там же), вебхук «Стенд: заглушка МИС» на http://127.0.0.1:8077/hook и получателя MLLP «МИС-тест» на 127.0.0.1:2577 с вырезанием данных пациента. Правила уведомлений отделений стенда короткие (тревога высокого приоритета — 1 минута, молчание — 2, гипотензия — 5), чтобы демонстрация не ждала. Повторный запуск ничего не дублирует.
3. Служба hl7. Если на сервере запущена служба hl7 (порт 2575 занят), стенд шлёт ей; если нет (ноутбук, manage.py runserver), стенд поднимает приём HL7, ADT, отправку, уведомления и ИИ в своём процессе. На странице это видно: «служба hl7 — внешняя (сервер)» или «запущена в процессе стенда».
4. Заглушка МИС при старте шлёт ADT A01 на 18 коек (две последние койки остаются «без МИС» — пациента на них называет только монитор, PID), затем принимает вебхуки Connect, проверяет подпись и что в теле нет пациента, раз в полминуты спрашивает API /beds и /beds/{id}/latest, а всё, что Connect выгружает получателю «МИС-тест», пишет в files/connect/stand/export.hl7. «Показать журнал МИС» — что заглушка отправила и что пришло; «Скачать export.hl7» — файл выгрузки.
5. «Остановить» — мониторы замолкают, через две минуты койки станут «нет связи», уведомления «монитор молчит» уйдут дежурному (это нормально: так и должно быть). «Пересоздать больницу» (стенд остановлен) удаляет организацию стенда со всеми протоколами и событиями и собирает заново; новые пароли — снова в accounts.txt.

Сценарии

Нажмите на плитку койки, потом на сценарий. Плитка показывает отделение, койку, живые ЧСС, АД, SpO₂ и сценарий; красная — тревога, жёлтая — аритмия или датчик, серая — монитор молчит. Страница обновляется сама раз в 5 секунд.

Время ×72 проигрывает 12 часов смены за 10 минут: часы мониторов уходят на 12 часов назад и идут в 72 раза быстрее, пока не догонят настоящее время (полоска на странице), а стенд дописывает в базу показатели за каждые полминуты этих часов, как если бы они пришли тогда. Так суточный лист интенсивной терапии получает медианы часов, протокол анестезии операционной — колонки по 5 минут, ИИ — ряд, а гипотензия — эпизод, не дожидаясь пяти настоящих минут. Чего ускорение не умеет: часы самого Connect идут по-настоящему — тревога должна продержаться минуту, молчащий монитор молчит настоящие минуты, а «Запись кривых» не доверяет часам монитора, если они расходятся с сервером больше чем на 5 минут (waverec.CLOCK_WINDOW): кривые ускоренных часов пишутся по времени прихода, а монитор на это время помечен «часы расходятся». После того как часы догнали, всё обычно.

Авто-прогон: 46 сценариев

«Прогнать все» (стенд запущен) или в терминале manage.py connect_demo --check --report /srv/stand/report.md — одна за другой проверяются: больница собрана; все мониторы на связи; экран палаты с ЧСС и АД у каждой койки; ADT A01 привязал пациента; API без ФИО, /latest совпадает с монитором, /vitals за час, журнал API; гипотензия — эпизод, уведомление дежурному за 60 секунд, «Принял» на экране палаты, закрытие при стабилизации; десатурация на экране и в API; тревога высокого приоритета держится минуту → уведомление; вебхук «тревога» с подписью и без ФИО; брадикардия; аритмия; датчик отключён; монитор замолчал → «нет связи» и уведомление; новый пациент по PID; выписка A03; перевод A02; вебхук «событие»; выгрузка «МИС-тест» без ФИО; получатель «на связи»; ускорение ×72; суточный лист открыт с пациентом из МИС; медиана часа листа равна медиане монитора; сетка протокола анестезии операционной; «Закрыть и напечатать» с PDF; запись Vidicap открыла и закрыла протокол анестезии; осмотр анестезиолога с цифрами монитора и PDF на 2 страницы; транспортировка между койками с «исходными» и «после» с мониторов; точка риска ИИ; риск при гипотензии выше, чем у стабильной койки; кривые пишутся; Vidicap Lab — проба анализатора легла на койку по номеру МИС, критический калий → уведомление без ФИО, проба с чужим номером «без пациента», контроль качества в журнале и не на койке, заявка заглушки МИС → анализатор получил DSR и сделал только заказанные тесты, проба привязана к заявке на койке, проба без заявки получила NF и прошла своей панелью, коды тестов анализатора сопоставлены со справочником; ночь без тревог; ничего не уходит с сервера. Каждая проверка ждёт, пока Connect сделает своё, с таймаутом, и пишет «прошло / НЕ ПРОШЛО / пропущено», время и подробности (что увидела вместо ожидаемого). Прогон занимает около 5–6 минут со службой hl7 в процессе стенда и дольше с внешней (её шаги — метки гипотензии раз в 5 минут, ИИ раз в минуту — идут своим темпом).

Отчёт — Markdown в files/connect/stand/report-<дата>.md и report-last.md (кнопка «Отчёт»): машина, режим службы hl7, таблица сценариев, цифры стенда (сообщений в секунду, потеряно, задержка p95, уведомлений, вебхуков, протоколов, сообщений в выгрузке с числом с ФИО — должно быть 0). Команда возвращает ошибку, если хоть одна проверка не прошла: её можно ставить в cron на ночь и смотреть отчёт утром; --only hypo_episode,hypo_notice прогоняет только названные ключи.

Команда

manage.py connect_demo [--beds 20] [--rooms 2] [--speed 72] [--duration S] [--check] [--report F] [--only k1,k2]
                       [--reset] [--force] [--no-waves] [--listener auto|in-process|external]

--reset удаляет больницу стенда перед сборкой, --no-waves — мониторы без кривых (слабый ноутбук), --duration — остановиться через столько секунд. Пока команда идёт, страница стенда показывает её цифры и командует ею через файлы control.json и status.json в files/connect/stand/ — страница и команда не зависят друг от друга: стенд, запущенный в терминале, виден на странице, и наоборот. Нагрузка 200 мониторами — это другой инструмент, scripts/connect_load_test.py (общий симулятор мониторов).

Демо-режим: виртуальная больница

Демо-режим — это стенд, которому задают свою больницу (любого размера, по описанию словами, по шаблону или вручную), сценарий дня (события на случайных койках по ускоренным часам или скриптовая «Презентация 15 минут») и пульт показывающего. Всё оборудование виртуальное (мониторы Mindray, анализаторы Mindray, заглушка МИС), пациенты вымышлены, в облако ничего не уходит; Connect работает с демо-больницей как с настоящей: экран палаты, уведомления, ИИ, протоколы, лаборатория, вебхуки и выгрузка срабатывают сами. Демо нужно, чтобы показать Connect без больницы — на ноутбуке продавца, на тестовом сервере, на сервере больницы до прихода настоящих мониторов.

Как и стенд, демо-режим есть только в локальной версии платформы с ролью connect и только для администраторов организации: Connect → «Настройки» → строка «Демо-режим», кнопка «Демо» в шапке Connect или /connect/demo/; в облаке vidicap.cloud страницы нет (404) — кроме облака с собственной демо-больницей (раздел «Демо на vidicap.cloud» ниже). Демо-организация помечена в базе как демо (is_demo): её палаты не передаются вверх по дереву серверов и в облако, её обезличенные эпизоды не уходят в общее обучение ИИ, а уведомления врачам не отправляются в Telegram и на телефоны — они показываются в «Пульте демо» как в ленте.

Запустить: мастер в четыре шага

Страница — один мастер из четырёх вкладок; кнопка «Запустить демо» на последней.

1. Больница. Три способа задать структуру, результат один — дерево справа («Что я понял»), которое можно править руками: отделение (название и вид — реанимация, кардиореанимация, хирургия, терапия, родильное, приёмное), палаты с числом коек, число операционных, анализаторы лаборатории, название больницы. - Описать словами: «Областная больница на 800 коек. Две реанимации по 12 коек, кардиореанимация на 6, хирургия с ПИТ на 4 койки и четырьмя операционными. Лаборатория: биохимия и гематология. МИС есть.» → «Предложить структуру». Разбор встроенный, работает без интернета и ничего не отправляет: он ищет числа («800 коек», «2 реанимации по 12», «на 6», «четырьмя операционными»), слова отделений (реанимац/ОИТР/ICU, кардиореанимац/CCU, хирург, терап, роддом/перинатал, приёмн/ER), лаборатории (биохим, гематолог, коагул) и «МИС»; что не названо, берётся из ближайшего по числу коек шаблона, остальные койки большой больницы раскладываются по отделениям без мониторов. Под деревом — строка «что я понял» (что именно разобрано). Понимает русский и английский. Если сервер связан с vidicap.cloud, описание сначала читает языковая модель через облако (см. «ИИ через облако и истории коек» ниже), а встроенный разбор остаётся запасным. - Шаблон: «ЦРБ 250 коек», «Областная 1000», «Кардиоцентр», «Перинатальный центр», «Частная клиника», «Как стенд» (3 отделения, 20 коек, 2 операционные — больница обычного стенда). - Вручную: «+ отделение», «+ палата», «+ анализатор», × убирает строку.

Мониторы ставятся на койки реанимаций, кардиореанимации, ПИТ хирургии и приёмного; палаты терапии, родильного и общие хирургические палаты получают койки только в МИС (без монитора и без пациента при старте) — так демо-больница на 800 коек не запускает 800 мониторов. Гематологические и коагулологические анализаторы заводятся в «Vidicap Lab» выключенными с пометкой «скоро»: виртуальный анализатор пока умеет только биохимию.

2. Оборудование. Плитки-переключатели по всей больнице: мониторы Mindray (на койках с мониторами и в каждой операционной), анализаторы Mindray (биохимия), заглушка МИС (ADT A01/A02/A03, API, вебхуки — по отдельности). «ИВЛ / наркозный аппарат» — серая плитка «скоро».

3. Сценарий дня и скорость времени ×1 / ×12 / ×72 (см. таблицу ниже).

4. Доступ и запуск. Пользователи stand-doctor (врач первой реанимации), stand-nurse, stand-head (заведующий всех отделений), stand-admin создаются при запуске; пароли показываются на этой же странице после старта и лежат в files/connect/stand/accounts.txt. Если Connect обслуживает настоящую организацию, кнопка не сработает без галочки «я понимаю, что Connect переключится на демо-больницу» (то же, что --force у стенда); администратор, нажавший кнопку, становится администратором демо-организации, чтобы не потерять доступ.

ИИ через облако и истории коек

Когда сервер подключён к vidicap.cloud («Подключение сверху»), кнопка «Предложить структуру» отдаёт описание больницы языковой модели: сервер посылает текст в облако по той же связи, что и всё остальное (ключ сервера, POST /api/link/demo/structure), облако спрашивает Claude API и возвращает дерево в том же формате, плюс на каждую койку с монитором — короткую вымышленную историю («ТЭЛА, тромболизис, 2-е сутки») и строку «что я понял». Дерево показывается в том же редакторе с меткой «✨ предложено ИИ через vidicap.cloud»; его можно править так же, как после встроенного разбора. Если что-то не вышло — сервер не подключён к облаку, в облаке нет ключа, облако не ответило за 30 секунд, ответ не разобран, — страница молча показывает встроенный разбор с меткой «встроенный разбор».

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

Истории коек. У шаблонов и встроенного разбора истории тоже есть — из небольшого набора вымышленных случаев (диагноз и сутки в отделении), по кругу на койки с мониторами; в дереве у такой палаты метка «📖 истории», а при редактировании числа коек лишние истории отбрасываются. При запуске демо истории записываются в files/connect/stand/stories.json, и пока идёт демо они видны на экране палаты (строка курсивом под показателями каждой койки) и на странице койки — карточка «вымышленная история (демо)». Это не данные пациента: вне демо-режима строк нет, в МИС, вебхуки, выгрузку и облако они не уходят.

«Запустить демо» записывает структуру в files/connect/stand/hospital.json, собирает больницу (как connect_demo, см. «Стенд») и запускает стенд со сценарием: manage.py connect_demo --scenario normal --speed 12. Та же страница после старта показывает текущее и следующее событие, пароли и QR «Войти как врач» — ссылку с одноразовым подписанным ключом, которая на телефоне показывающего входит как stand-doctor без пароля. Ключ живёт, пока идёт демо: после «Завершить демо» или «Оставить как стенд» ссылка отвечает «гостевой вход закрыт».

Сценарии дня

События «Спокойной ночи», «Обычной» и «Тяжёлой смены» идут по часам стенда: при ×12 в одном настоящем часе — 12 часов событий, при ×72 — смена за 10 минут (как у стенда, часы мониторов уходят назад и догоняют настоящее время, показатели дописываются в базу за каждые полминуты). Чего ускорение не умеет — описано в разделе «Стенд»: правила уведомлений, «монитор молчит» и запись кривых идут по настоящим минутам, поэтому презентация идёт по настоящим минутам и на ×12 тоже.

Пока демо идёт: полоса ДЕМО и пульт

На всех страницах Connect (/connect/…, /wards/…) — оранжевая полоса «ДЕМО · виртуальное оборудование, пациенты вымышлены · сценарий «Обычная смена» · время ×12 · идёт 0:14:08» с кнопкой «Пульт демо»; её видят и врачи, вошедшие по QR. Администраторы видят ещё и «Пульт демо» — плавающую панель справа внизу (сворачивается кнопкой, на телефоне свёрнута по умолчанию), которая обновляется сама раз в 5 секунд:

• Сейчас — последнее событие с подписью («Гипотензия на ОИТР №1 · Палата 1 · Койка 1: АД 82/46, тревога высокого приоритета…»), через N мин — следующее;
• Пауза / Продолжить и скорость ×1 / ×12 / ×72;
• Вызвать событие на койке: выбранная койка (на странице койки — она сама; иначе из списка или «любая подходящая») и кнопки гипотензия, десатурация, аритмия, брадикардия, монитор замолчал, датчик отключён, критический анализ, новый пациент, перевод, выписка, стабилизировать, операция;
• Уведомления (вместо Telegram) — что стенд отправил бы врачам: время, кому, текст, «принял»;
• Подписи для проектора — переключатель режима «презентация»: над страницами палат и «Состояния» всплывают крупные подписи событий («Поступление из МИС: ADT A01, ОИТР · Палата 1 · Койка 3…»), каждая примерно на 8 секунд; выбор запоминается в этом браузере (на проекторе включите один раз). В адресе страницы ?captions=1 включает подписи и без пульта, ?captions=0 выключает;
• QR: войти как врач (ссылка на страницу демо) и Завершить демо.

Пульт и страница демо командуют стендом через те же файлы control.json и status.json в files/connect/stand/, что и страница «Стенд»; стенд, запущенный командой connect_demo --scenario … из терминала, виден на пульте так же.

Завершение

«Завершить демо» останавливает стенд, удаляет демо-организацию со всеми отделениями, устройствами, пробами, протоколами и уведомлениями (как connect_demo --reset), стирает hospital.json и закрывает гостевой вход; Connect остаётся без организации — верните его настоящей на странице «Отделения и койки». «Оставить как стенд» только останавливает: больница остаётся для тестов, и страница «Стенд» запустит её снова (без сценария дня, с той же структурой из hospital.json; «Пересоздать больницу» там же собирает её заново).

Команда

manage.py connect_demo --scenario night|normal|heavy|presentation [--seed N] [--speed 12] [--beds 20] [--rooms 2] …
manage.py connect_demo --serve [--dry]

Без --scenario это обычный стенд; больница строится из files/connect/stand/hospital.json (без файла — «Как стенд»), --beds/--rooms масштабируют её койки с мониторами и операционные, --seed делает день повторяемым. Остальные ключи — в разделе «Стенд». --serve — публичный демо-сервер (ниже).

Демо на vidicap.cloud

Чтобы «дать демо» по ссылке, демо-больница Connect живёт прямо на vidicap.cloud: облачная версия платформы с VIDICAP_CLOUD_DEMO=1 в .env держит её постоянно, а каждую ночь пересоздаёт. Для вошедших пользователей облака в главном меню есть плитка «Демо Vidicap Connect» — она ведёт в палаты виртуальной больницы; на странице входа — кнопка «Войти как врач (демо)»: вход без пароля, сразу в палаты. У этого входа постоянный адрес https://vidicap.cloud/connect/demo/go/ — его можно напечатать на слайде или буклете как QR, он не меняется после ночной пересборки.

Как это устроено:

• служба demo из docker-compose.yml (запускается вместе с остальными, профиль не нужен) выполняет manage.py connect_demo --serve: при старте собирает больницу (из files/connect/stand/hospital.json, а без файла — из шаблона VIDICAP_DEMO_PRESET, по умолчанию «ЦРБ 250 коек») и запускает стенд со сценарием «Обычная смена»; если стенд упал, через 15 секунд всё собирается и запускается снова. На сервере, который не является демо, служба просто спит;
• каждую ночь в VIDICAP_DEMO_RESET_HOUR (по умолчанию 4:00 по времени сервера) больница удаляется и строится заново: пациенты, уведомления, протоколы и пробы за день уходят, пользователи stand-* получают новые пароли; ссылка /connect/demo/go/ остаётся;
• демо-организация — единственный Connect облака (is_demo): её палаты видит любой вошедший пользователь облака, страница «Демо-режим» с пультом (сценарий, пауза, скорость, «Вызвать событие», подписи для проектора) — только суперадминистратор; на страницах Connect — оранжевая полоса ДЕМО, остальное облако (трансляции, организации) демо не касается, и организации облака ведутся как обычно;
• служба hl7 облака остаётся выключенной, порты HL7 наружу не принимают ничего: виртуальные мониторы и заглушка МИС говорят с приёмником внутри самой службы demo по 127.0.0.1; кривые в браузер идут через Caddy (/wave/* на hl7:8099, как и у обычного сервера). Настоящие пациенты в облако по-прежнему не попадают;
• «Предложить структуру» на странице «Демо-режим» спрашивает языковую модель прямо в облаке (ключ ANTHROPIC_API_KEY в .env облака); без ключа — встроенный разбор;
• VIDICAP_CLOUD_DEMO=0 (или строки нет) — облако как раньше: Connect отвечает 404, плитки и кнопки нет, служба demo спит.

Включить на vidicap.cloud: в platform/deploy/.env добавить VIDICAP_CLOUD_DEMO=1 и перезапустить службы (sudo platform/deploy/autoupdate.sh rebuild или docker compose up -d). Что видит гость: палаты виртуальной больницы, страницу койки с кривыми, трендами, NEWS2 и вымышленной историей, уведомления «вместо Telegram» в журнале, лабораторию. Пароли stand-* показываются только суперадминистратору на странице «Демо-режим» (и лежат в files/connect/stand/accounts.txt).

Отдельный публичный демо-сервер

Тот же демо-режим можно держать и на отдельном сервере (например, connect-demo.vidicap.cloud) — обычная локальная версия платформы с Connect, где в .env стоит VIDICAP_DEMO_SERVER=1: то же постоянное демо с ночной пересборкой, та же кнопка «Войти как врач (демо)» и ссылка /connect/demo/go/, а кроме того на всех страницах тёмная полоса «Публичный демо-сервер Vidicap Connect…», «Подключение сверху» отвечает 404 (демо-сервер никуда не подключают, из него ничего не уходит), на странице организации нельзя создать учётную запись или отделение. connect_demo --serve --dry только собирает больницу и записывает состояние, не запуская стенд (проверка настройки, cron).

# .env отдельного демо-сервера
VIDICAP_EDITION=local
VIDICAP_PUBLIC_HOST=connect-demo.vidicap.cloud
VIDICAP_ROLES=platform,connect
VIDICAP_DEMO_SERVER=1
VIDICAP_DEMO_PRESET=crb
VIDICAP_DEMO_RESET_HOUR=4
CADDY_TLS=admin@vidicap.cloud      # настоящий сертификат Let's Encrypt: сервер публичный
VIDICAP_HL7_ALLOWED=127.0.0.1/32   # мониторы только виртуальные, снаружи HL7 не принимаем

Чтобы плитка «Демо Vidicap Connect» в облаке вела на такой сервер вместо собственного демо, в .env облака указывают VIDICAP_DEMO_URL=https://connect-demo.vidicap.cloud/.

Неполадки

← Monitors and anaesthesia machines (HL7) Резервное копирование и восстановление сервера →