What Good Clinic Software Does When the Internet Drops

"Offline support" means several different things

Vendors use one phrase for at least four different behaviours, and the gap between them is the gap between a minor annoyance and a lost clinic day:

1. Nothing. The page errors and you wait. 2. Read-only cache. You can see what was already loaded. You cannot add to it. 3. Queued writes. You can keep working; changes are stored locally and sent when the connection returns. 4. Full offline. The application genuinely runs locally and reconciles later.

Most clinics need level 3. Level 4 is rare and usually oversold.

The failure modes worth testing before you commit

Ask for a trial account and actually do these, on the device you will really use:

• Turn the connection off mid-note. Does your typing survive?
• Turn it off, then book a walk-in. Does the booking exist when you reconnect?
• Do the same thing twice while offline — book, lose patience, book again. Do you end up with two appointments? A system that queues writes without protecting against duplicates will cheerfully create both.
• Go offline on one device and online on another. What happens to the same patient's record?
• Reconnect after a long gap. Does it sync, or does it silently give up?

That third one is the test most people skip and most systems fail.

How Roshtah behaves

The doctor workspace keeps working when the connection drops. Patient records you have opened stay readable, and work you do while disconnected is queued and sent when you are back. Walk-in registration specifically is protected against the double-submit case above, so an impatient second tap does not produce a second appointment.

What is honestly not offline: anything that inherently needs the other side of the connection. Video consultations need a network. Sending a WhatsApp confirmation needs a network. Taking a card payment needs a network. No amount of local caching changes that, and a vendor claiming otherwise is describing something else.

The organisational half

Software behaviour is only part of it. Clinics that handle outages well tend to have decided in advance:

• Who tells waiting patients what, and after how long.
• Whether you keep seeing patients on paper or pause bookings.
• Where the paper notes go afterwards, and who enters them.

Deciding that on the day, mid-queue, is what turns a connectivity problem into a bad day.