Features
Offline mode
Medical equipment lives in plant rooms, basements and lift shafts, which is exactly where mobile coverage does not. Any tool for this work has to function without a connection. The interesting question is not whether it works offline, it is what it refuses to do offline, because that answer is where the safety thinking either exists or does not.
- Field technicians
- Biomedical engineering
- Clinical engineering
What is offline mode?
Definition
Offline mode
Offline mode is the ability to continue working when the device has no connection: reading the data needed for the job, capturing new work locally in a durable queue, and synchronising it when connectivity returns, without losing anything and without pretending the work is further along than it is.
Two clauses carry the weight. Durable, meaning the queue survives the app being closed, the battery dying and the phone rebooting, because a technician's two hours of readings cannot depend on a process staying alive. And without pretending, meaning the interface has to be honest that work is queued rather than done, or the technician will believe a job is complete when it is sitting in local storage.
The naive version of this feature is a cache. The real version is a distributed systems problem with a safety dimension, which is why read-only offline so often gets shipped under the name of offline support.
Why offline is where healthcare tools get dangerous
Because the obvious implementation lets a disconnected device make decisions that must be authoritative, and the conflict only surfaces later, when both versions are already real.
The tempting design is that everything works offline and conflicts resolve last-write-wins on sync. A technician, out of signal, marks a ventilator as returned to service. Meanwhile a safety officer, online, has quarantined it because of a recall. The technician reconnects. Last write wins. The ventilator is now in service, and nobody made that decision.
That is not a hypothetical bug, it is the natural consequence of treating every field the same. The fix is not better conflict UI. It is recognising that fields differ in kind: some are observations, which can be captured anywhere and merged, and some are authoritative decisions, which can only be made where the full state is known.
The second trap is silent queueing. If the app shows a green tick when work is queued rather than synced, the technician moves on believing the job is filed. When the sync later fails, nobody is standing there. The record and reality have diverged, and the first person to notice is an auditor.
How Rydya handles being offline
Approved actions queue durably, sync state is always visible, conflicts resolve by class rather than by clock, and the safety gates simply are not available offline.
- 1
Only approved field actions work offline
The offline write scope is a deliberate, approved list rather than "whatever the app can do". If an action is not on it, it is not available without a connection, and the interface says so rather than failing later.
- 2
The queue is durable
Queued work is held in IndexedDB, so it survives the app closing, the battery dying and the phone restarting. A technician's morning of readings is not contingent on a JavaScript process staying alive in a basement.
- 3
Sync state is visible, always
Offline, queued and syncing are shown rather than implied. A technician can see that four items are waiting. The green tick means synced, not attempted, because the alternative teaches people to trust a lie.
- 4
Conflicts resolve by class, not by clock
Five conflict classes: server-authoritative, manual-review, additive, mergeable and last-write-wins. Which class a field is in is a design decision made once, not a race. Status, quarantine, approvals, return to service, assignment and final cost are server-authoritative and are never overridden by a client.
- 5
The gates stay online, deliberately
Quarantine and return to service require a connection. This is the constraint that makes the rest safe: an offline device cannot decide that a ventilator is safe again, because it cannot know what it does not know.
How the boundary is drawn
Observation works with no signal. Decisions about clinical safety do not, and that is deliberate.
The five conflict classes
Every field belongs to exactly one, decided in the design rather than at sync time. This is the whole mechanism.
Server authoritative
Status, quarantine, approvals, return to service, assignment, final cost. The server's value always wins; a client cannot override it. These are decisions that require full state, and a disconnected device does not have it.
Manual review
Genuine disagreements that a human has to look at. Surfaced rather than silently resolved, because a machine picking a winner here is a machine destroying information.
Additive
Notes, photos, evidence. Two technicians adding observations is not a conflict, it is two observations. Both survive.
Mergeable
Structured values that can be combined without loss, where combining is well defined and does not require judgement.
Last write wins
Reserved for the genuinely low-stakes, and used narrowly. It is the default in most offline systems and the correct choice in very few places.
What works offline, and what does not
The second column is the more informative one, which is why it is published here in full.
| Action | Offline? | Why |
|---|---|---|
| View my work and task detail | Yes | Read of data already synced to the device |
| Scan a code to identify an asset | Yes | Resolution works against local data |
| Complete a checklist, record readings | Yes | Observations, captured where the equipment is |
| Add notes and photos | Yes | Additive: two people adding evidence is not a conflict |
| Quarantine a device | No | Server authoritative: requires full current state |
| Return a device to service | No | A gate. An offline device cannot establish safety |
| Approve, or set final cost | No | Server authoritative, and financial records are immutable |
Offline availability of field actions in Rydya
Offline is not a licence to weaken a safety gate
It would be straightforward to let return to service work offline and reconcile afterwards. It would also mean a device could be in clinical use before anyone established it was safe, with the discrepancy discovered later. Rydya treats that trade as unavailable rather than configurable, which is a deliberate limitation and the reason the offline support elsewhere can be trusted.
What technicians actually experience
The app keeps working, the sync badge tells the truth, and the two things they cannot do offline are things they would have to be at a desk for anyway.
In practice the boundary lands in a comfortable place, which is not an accident. The work a technician does standing in front of equipment, checklists, readings, photos, notes, is exactly the work that is safe to capture offline, because it is observation. The work that needs a connection, quarantine and return to service, is the work that involves a decision about clinical use, and those decisions rarely happen in the basement anyway.
The honest caveat: when a technician genuinely does need to return a device to service and has no signal, they have to move somewhere with a connection. That is a real cost, and we would rather state it than pretend. The alternative cost is a ventilator in use that nobody established was safe, and there is no version of this product where that is the trade we make.
Questions
What can technicians do without a connection?
View their work and task detail, scan a code to identify an asset, complete checklists, record readings, and add notes and photos. That is the observation work, which is exactly what happens standing in front of equipment. It queues durably in IndexedDB, so it survives the app closing, the battery dying or the phone rebooting, and syncs when the connection returns.
Why can I not return a device to service offline?
Because an offline device cannot know what it does not know. If a safety officer has quarantined that device for a recall while you were out of signal, an offline return to service would overwrite the quarantine on sync and put the equipment back into clinical use with nobody having made that decision. Return to service, quarantine, approvals and final cost are server authoritative for exactly that reason. It is a deliberate limitation, not a gap.
What happens if two people change the same thing?
It depends on the field, which is decided in the design rather than by a race. There are five classes: server authoritative (the server wins, always), manual review (a human looks at it), additive (both survive, as with notes and photos), mergeable (combined without loss), and last write wins, which is used very narrowly. Most offline systems make the last one the default; we treat it as the exception.
Can I lose work if my phone dies?
The queue is durable, held in IndexedDB rather than in memory, so it survives the app closing, the battery dying and a restart. Sync state is also shown rather than implied: queued means queued, and the tick means synced rather than attempted, because an interface that shows success for unsynced work teaches people to trust it wrongly.
Does the app update while I have unsynced work?
No. A new version is deliberately not applied while there is unsynced field work, because reloading the page could strand queued changes. The update waits until the queue has drained. That is why the service worker registration is a deliberate piece of code rather than an out-of-the-box default.
Keep reading
Mobile app
The phone-first surface this runs on, and why it is one screen.
Work orders
The return-to-service gate that offline deliberately cannot reach.
Biomedical engineering
The department whose day job happens where the signal is not.
NGO and donor funded
Where unreliable connectivity is the normal condition.
See it on your equipment
Live in an afternoon, useful the same week. A person replies, usually within one working day.
Contact us