Как MedConnect продолжает медконсультацию после обрыва связи
В MedConnect сделали автосохранение контекста консультации, reconnect и realtime-статусы соединения, чтобы врач и пациент возвращались в тот же сеанс.
Обрыв связи в медконсультации — это потеря доверия, если приложение делает вид, что всё нормально.
В обычном чате пользователь ещё может написать «повтори, отвалилось». В консультации врач уже мог заполнить часть данных, пациент мог ответить на вопросы, а экран в этот момент выглядит живым только потому, что никто не нажимает кнопки. Плохой сценарий — сеанс падает, форма очищается, врачу приходится восстанавливать ход разговора по памяти.
В MedConnect мы закрывали именно этот участок: автосохранение контекста консультации, автоматический reconnect и продолжение с того же места. Плюс — статус соединения в реальном времени для врача и пациента, чтобы оба понимали, что происходит.
Что сохраняли при обрыве
Главная мысль была простая: критичный обрыв не должен превращаться в новую консультацию.
Поэтому сохраняли контекст сеанса: всё, что уже ввели во время консультации, должно пережить разрыв связи. Если врач заполнил данные, а пациент в этот момент потерял интернет, система не должна ждать «успешного завершения» всего сценария. Данные фиксируются по ходу работы.
Здесь легко увлечься и сохранять только финальный результат. Но для медицинской консультации это слишком поздно. Пользовательский сценарий длиннее одного submit: врач задаёт вопросы, заполняет поля, возвращается к предыдущим пунктам, пациент отвечает неравномерно. Значит, нужен промежуточный контекст, к которому можно вернуться.
Отдельно пришлось договориться, что именно считается «тем же местом». Не только открытый экран. Важно, чтобы после восстановления связи врач и пациент вернулись в тот же сеанс, с теми же введёнными данными и понятным состоянием консультации.
Reconnect без иллюзии стабильности
Автоматическое переподключение мы сделали частью сценария, а не скрытой деталью. Если связь пропала, приложение пытается восстановить соединение. Если восстановилось — консультация продолжается с сохранённого состояния.
Но показывать пользователю просто замерший интерфейс нельзя. Врач может решить, что пациент молчит. Пациент может решить, что врач не отвечает. Поэтому статус соединения видят обе стороны в реальном времени.
Это маленькая деталь интерфейса, но она меняет поведение. Когда видно, что связь нестабильна, участники не начинают дублировать действия и не пытаются «починить» консультацию вручную: обновлением страницы, повторным входом, созданием нового сеанса.
Живая неприятность всплыла именно на границе reconnect. Если соединение уже восстановилось, но локально ещё остаются несохранённые изменения, легко получить состояние «вроде всё вернулось, но часть формы старее, чем на экране». Поэтому сценарий восстановления пришлось рассматривать вместе с автосохранением, а не как отдельную кнопку «подключиться заново».
Критический обрыв — отдельный сценарий
Короткая просадка сети и критический обрыв — разные случаи. При короткой просадке достаточно переподключиться и продолжить. При критическом обрыве важно не потерять введённые данные и дать пользователю безопасный путь обратно.
В MedConnect система сохраняет все введённые данные и позволяет продолжить сеанс без потери контекста. То есть после возвращения связь не начинается с пустого состояния, а консультация не распадается на две несвязанные части.
Мы не пытались делать вид, что сеть всегда восстановится мгновенно. Наоборот: заложили состояние, где связь уже считается проблемной, но данные консультации остаются в сохранённом контексте. Это полезнее, чем бесконечно крутить индикатор и надеяться, что пользователь подождёт.
Где проходит граница ответственности
В такой задаче спор быстро уходит не в реализацию reconnect, а в ответственность интерфейса. Что должен увидеть врач? Что должен увидеть пациент? Когда можно продолжать автоматически, а когда нужно явно показать, что связь оборвалась критически?
Мы выбрали вариант, где система:
- сохраняет контекст консультации по ходу работы;
- автоматически пытается восстановить соединение;
- показывает статус соединения обеим сторонам;
- после критического обрыва возвращает в сохранённый сеанс, а не в пустую форму.
Теперь интересно сравнить с чужой практикой. Если у вас есть видеоконсультации, чаты поддержки, сделки или любые длинные сессии с двумя участниками: где вы проводите границу между «ещё reconnect» и «уже критический обрыв», и какие данные сохраняете до финального подтверждения?