> ## Documentation Index
> Fetch the complete documentation index at: https://help.clinikehr.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Working without internet
> Exactly what ClinikEHR keeps doing during an outage, what has to wait, and how captured work catches up when you reconnect.
export const StillStuck = ({topic}) =>
Still stuck{topic ? ` with ${topic}` : ''}?{' '}
Check Troubleshooting first —
it covers the failures we see most often. If that does not resolve it,{' '}
contact support and include
your workspace name and the time the problem happened, so we can find the
matching entry in your audit log.
;
export const Availability = ({editions = ['all'], plans, roles, note}) => {
const list = editions.includes('all') ? ['clinic', 'pharmacy', 'lims'] : editions;
return
Available in
{list.map(e =>
{EDITION_LABELS[e] || e}
)}
{plans ? Plan : null}
{plans ? {plans} : null}
{roles ? Who : null}
{roles ? {roles} : null}
{note ? {note} : null}
;
};
ClinikEHR keeps working through a power cut or a dropped line, but only for a deliberately narrow set of screens. Knowing which ones — before the connection goes — is the difference between a calm shift and a lost afternoon.
## The one rule
**Capture works offline. Completion does not.**
You can record that something happened. You cannot advance, finish, price or sign it. That line is drawn on purpose: capture is a single new record from one device, while completion touches records other people are also touching, and merging those blind is how a lab reports the wrong result or a patient gets a second dose.
## What keeps working
| Works offline | Where |
| ------------------------------------------------------------------- | ------------------------------------------------- |
| Ringing up a sale, and holding a cart to recall later | Pharmacy [POS](/pharmacy/pos/index) |
| Capturing a DOT lab intake order | [Lab intake](/lims/dot/collection) |
| Capturing a clinical lab order | [Test requests](/lims/lab/test-requests) |
| Capturing a radiology order | [Imaging requests](/lims/imaging/requests) |
| Capturing a consultation | [Consultation](/hospital/outpatient/consultation) |
| Reading a ward chart you already opened, and recording a dose given | [Wards](/hospital/inpatient/wards) |
## What does not
| Does not work offline | Why |
| ---------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------- |
| Workflow steps on an existing record — accessioning, screening, confirmation | Status changes are shared between people at different benches; a blind merge is a wrong result |
| Result and report entry, and signing anything | A signed clinical document is not something to reconcile afterwards |
| **Taking payment** | Money must settle against a live ledger |
| Discharging a patient, or placing a new order from the ward | A bed is a shared resource, and an order composed offline is a draft nobody has confirmed |
| History, imaging and attached media not already loaded | They are fetched on demand |
| Anything on a screen this device has never opened | There is nothing cached to show |
Screens that cannot load their data offline say so — "This chart is not available offline", "cannot be shown". They never render an empty list as though nothing had been recorded. If you see zero results, that is a real zero.
## Prime the device first
Offline capture only works on a device that has already loaded the screen while connected. A brand-new tablet, or a till nobody has signed in on, does nothing useful in an outage.
The one that will be used during the outage — not a different machine at the same counter.
The till, the intake form, the ward chart. Loading it once is what caches the screen and its reference data.
An expired session cannot send anything, and you cannot sign in without a connection. Signing in at the start of the day is the single most useful habit here.
Turn the network off for two minutes and ring up a test sale. Two minutes once beats discovering the gap mid-queue.
## What you see while offline
An amber bar appears on the screens that support capture.
* On the till: **Offline · stock as of 14:05**.
* On lab, imaging and intake forms: **Offline · reference data as of 14:05 — new intake orders queue and sync on reconnect**.
* On a ward chart: **Offline — showing a cached chart as of Tue 14:05.**
Beside it is a counter of items waiting, or the word **Synced** with a tick when there is nothing outstanding.
**Every figure with an "as of" time is a snapshot, not a live number.** Stock levels, totals and chart values are as they were when you last had a connection. Somebody else may have sold the last box since. Treat the label as the point of the number, not as decoration.
## Provisional references
Anything captured offline is given a temporary reference so staff have something to write down and quote — for example `LAB-OFF-A3F1-482913`. It identifies the capture on that device until the real reference is issued on sync.
A provisional number does not exist on our side yet. An offline receipt prints a **PROVISIONAL — WILL CONFIRM ON SYNC** banner and carries no scannable barcode, so it cannot be looked up or scanned back in until the sale has synced.
## Payment is never captured offline
This catches people out, so it is worth stating on its own. An order captured during an outage arrives **unpaid**. Nothing is charged, no card is taken, and no receipt for payment exists. Settle it at the desk once you are back online.
The pharmacy till is the exception in one direction only: it records how a sale was paid for, so the sale is complete on the shop floor — but that record still has to reach us before it is money in a report.
## Coming back online
Sync is automatic. As soon as the connection returns, captured items are sent one at a time, in the order they were taken.
* **Sent successfully** — the item gets its real reference and the counter drops. You do not have to do anything.
* **Could not be sent** — it stays queued and is retried, backing off gradually rather than hammering a bad line.
* **Refused by the server** — it stops there and is held for a person to look at. It is **never** retried silently, because a refusal usually means the fact has changed since you captured it.
* **Sent twice by accident** — it cannot be. A retry of something already recorded is recognised, not duplicated.
Open the counter to see the panel for yourself:
* On lab, imaging and intake screens it is titled **Offline captures**, tells you how many items are waiting, and offers **Sync now** while you are online.
* On the till it is titled **Sync status**, with **Waiting to sync** and **Need review** counters and the same **Sync now** button.
If your session expired while you were offline, you get **Sign in to sync**. Nothing is lost — sign in and the queue continues. Do not clear the browser's data or reinstall while anything is waiting.
## Items that need review
A refused item is listed under **Needs review — the server refused these**, with its provisional reference, when it was captured, and the reason. The advice is the same for all of them: resolve the underlying problem, then re-enter the item manually. Rejected captures are never retried automatically.
**A refused medication administration is a patient-safety event, not an admin task.** The ward bar reads "1 dose needs review" with a **Check the patient** badge, and there is deliberately no retry button anywhere in that flow — the usual reason for a refusal is that someone else had already recorded the dose, which means it may have been given twice. Check the drug chart and the patient, then tell the nurse in charge. The entry stays in the list as the record that it happened.
## After the outage — the ten-minute tidy-up
A queue lives on the device that captured it. A tablet left in a drawer still holds its own items and cannot sync from anyone else's machine.
Open the panel on each device and confirm it reads **Synced** with nothing needing review.
Everything captured offline arrived unpaid. Work through them at the desk.
Stock levels and totals seen during the outage were snapshots. Anything you decided on the strength of one is worth confirming now — and a stock count is the honest way to close out a long outage.
Resolve each refused item and re-enter it. An item left in that list is work that has not been recorded anywhere.
## Check it worked
* Every device's panel shows **Synced** and no review items.
* Provisional references have been replaced by real ones on the records.
* Offline sales appear in the day's sales totals.
* Captured orders show as pending payment, not paid.
## If something goes wrong
That screen does not support offline capture, or it was never opened on this device while online. Check the table at the top of this page.
Your session expired during the outage. Sign in again on that device and the queue continues by itself. Nothing has been lost.
Confirm the device is genuinely online — a weak connection can look connected — then select **Sync now**. If it stays queued, [contact support](/platform/help/contact-support) with the provisional reference.
It was a snapshot from the last time that device was online, and it says so on the bar. Run a [stock count](/pharmacy/inventory/stock-counts) to reconcile.
Reprint it once the sale has synced, so the receipt carries the real number and a scannable barcode. Before then, all that exists is the provisional slip.
No, and it is not a setting. Result entry, signing and payment need a live connection by design — see the rule at the top of this page.
## Related
A till queue that survives a browser wipe, and silent receipt printing.
The pharmacy till's offline behaviour, step by step.