How MedConnect keeps a medical consultation going after a connection drop

A connection drop during a medical consultation is a loss of trust if the app pretends everything is fine.

In a regular chat, the user can still type “repeat that, it dropped.” In a consultation, the doctor may already have filled in part of the data, the patient may have answered questions, and at that moment the screen looks alive only because nobody is pressing any buttons. The bad scenario is that the session drops, the form is cleared, and the doctor has to reconstruct the conversation from memory.

In MedConnect, we closed exactly this gap: autosaving the consultation context, automatic reconnect, and continuing from the same place. Plus real-time connection status for both the doctor and the patient so both understand what is happening.

What we saved on disconnect

The main idea was simple: a critical disconnect should not turn into a new consultation.

So we saved the session context: everything entered during the consultation had to survive the connection drop. If the doctor filled in data and the patient lost internet at that moment, the system should not wait for the entire flow to “finish successfully.” Data is persisted as work progresses.

It is easy to get carried away and save only the final result. But for a medical consultation, that is too late. The user flow is longer than a single submit: the doctor asks questions, fills in fields, goes back to previous points, and the patient answers unevenly. That means you need intermediate context that you can return to.

We also had to agree on what exactly counts as “the same place.” Not just the open screen. It was important that after reconnect, the doctor and patient returned to the same session, with the same entered data and a clear consultation state.

Reconnect without the illusion of stability

We made automatic reconnect part of the flow, not a hidden implementation detail. If the connection drops, the app tries to restore it. If it comes back, the consultation continues from the saved state.

But you cannot just show the user a frozen interface. The doctor may think the patient is silent. The patient may think the doctor is not responding. That is why both sides see connection status in real time.

It is a small UI detail, but it changes behavior. When it is obvious that the connection is unstable, participants do not start duplicating actions or try to “fix” the consultation manually: by refreshing the page, logging in again, or creating a new session.

The nasty edge case showed up right at the reconnect boundary. If the connection has already been restored, but there are still unsaved local changes, it is easy to end up in a state where “everything seems to be back, but part of the form is older than what is on screen.” So the recovery flow had to be considered together with autosave, not as a separate “reconnect” button.

Critical disconnect is a separate scenario

A short network hiccup and a critical disconnect are different cases. With a short hiccup, it is enough to reconnect and continue. With a critical disconnect, it is important not to lose entered data and to give the user a safe way back.

In MedConnect, the system saves all entered data and allows the session to continue without losing context. That means after the connection returns, it does not start from an empty state, and the consultation does not split into two unrelated parts.

We did not try to pretend the network always comes back instantly. On the contrary, we introduced a state where the connection is already considered problematic, but the consultation data remains in the saved context. That is more useful than spinning a loader forever and hoping the user will wait.

Where responsibility is split

In a task like this, the debate quickly moves away from reconnect implementation and toward UI responsibility. What should the doctor see? What should the patient see? When is it okay to continue automatically, and when is it necessary to clearly show that the connection has been critically lost?

We chose the option where the system:

• saves the consultation context as work progresses;
• automatically tries to restore the connection;
• shows connection status to both sides;
• after a critical disconnect, returns to the saved session instead of an empty form.

Now it is interesting to compare this with other approaches. If you have video consultations, support chats, transactions, or any long-running session with two participants: where do you draw the line between “still reconnecting” and “already a critical disconnect,” and what data do you save before final confirmation?