Yes, but only if the system writes the consultation to a server on every change, not to a local file you have to remember to email yourself. The pattern that works: the consultation lives in a database that both devices read from, every keystroke flushes to the database in seconds, and the second device subscribes to changes. When you sit down at home, the note is where you left it, including the chief complaints you typed ten minutes ago and forgot to save.
Why this is awkward with off-the-shelf tools
Most desktop software designed for doctors assumes one machine per doctor. The consultation is a file on that machine. Open it on a second device and you see the version you last saved, which is the version you remember to save, which is the version from yesterday.
The traditional fix (email yourself the file) is broken in three ways at once. First, the email attachment is the version at the moment you sent it, not the live version. Second, if you make changes on the second device, you have to email the new version back, and pick which one is the latest, and you will pick wrong at least once. Third, attachments with patient names in the filename end up in your sent-mail archive forever.
The shortcut that doesn't fix this: USB sticks, OneDrive folders synced to your laptop, shared Google Docs. Each addresses one of the failure modes above and creates two new ones. OneDrive sync has a "this file was modified in two places" conflict popup that is worse than the original problem.
The trap that catches most doctors: software that advertises "cloud" but actually stores the consultation locally and only syncs when you click "save to cloud." The cloud is then a backup, not the source of truth. The second device shows an empty consultation until you remember to click.
What good looks like, concretely
The bar is concrete enough to score against any tool. Six criteria.
One source of truth, in the cloud. The database is the consultation. There is no "local copy" that diverges from the cloud copy. If the network drops, the system buffers writes locally and flushes when it returns, but the cloud row remains canonical.
Writes are continuous, not on a Save button. Every keystroke (or every few seconds, debounced) hits the database. A consultation is never "not saved" in the way a Word document is not saved. The Save button is a relic.
Conflict resolution is automatic, not manual. Two devices editing the same consultation concurrently do not produce a "merge conflicts" dialog. Last-write-wins per field is usually fine for a single doctor's note. A field is the granularity of conflict resolution, not a whole consultation.
Per-doctor access control, not per-machine. Signing in on a new device gives you access to your consultations. Signing in on someone else's device does not give you access to theirs. The auth layer is the doctor, not the laptop.
Read latency is sub-second on a healthy connection. Open a consultation on device A, type a chief complaint, switch to device B within five seconds, see the chief complaint. Anything slower than "I can demo this live" is too slow.
Audit trail includes device, not just user. If you write a chief complaint from your home desktop at 11pm, the audit row says "home desktop, 11pm." If you change it on the chamber laptop at 9am, the audit row says "chamber laptop, 9am." Useful when you can't remember what you wrote.
If a tool passes all six, your second device is a continuation of your first. If it skips any of them, your second device is a copy that will diverge.
How to actually set it up
The setup is mostly "pick a tool that meets the six criteria, then test the failure modes." Two of the criteria (continuous writes and sub-second reads) are the load-bearing ones.
The continuous-writes test: open a consultation on device A. Type a single character. Wait five seconds. Open the same consultation on device B. The character is there. If you have to click Save on device A first, the tool fails this criterion.
The sub-second-reads test: open a consultation on device A. Start typing in the chief-complaints field. Don't pause. On device B, watch the field update character-by-character or word-by-word. If device B shows the same field unchanged while you're typing on A, the sync is polling, not pushing. Polling is fine for low-frequency updates; it is laggy for live editing.
The conflict-resolution test: open the same consultation on two devices. Type into the chief-complaints field on device A. Type into the exam field on device B. Both changes land. If device B's exam-field edit clobbers device A's chief-complaints edit, the conflict resolution is at the wrong granularity.
The browser-side path is one way to meet all six: the consultation database lives in a real-time backend where every mutation is a write to the canonical row and every active client subscribes via reactive queries that re-fetch on server-side change. The autosave runs every 10 seconds with a debounced flush on tab close, and the audit log records the device fingerprint alongside the timestamp. DrPenDown's editor implements this end-to-end across browsers and desktops.
Common follow-up questions
Does this work on a patchy internet connection? The writes buffer locally and flush when the connection returns. The reads are stale until the connection is back. This is fine for a chamber with a stable Wi-Fi, less fine for a clinic where the Wi-Fi drops every afternoon. Test on your real connection before committing.
What if two doctors share one chamber laptop? Each doctor signs in with their own account; the consultation is per-doctor, not per-machine. Signing out and signing back in switches the active consultation list. Sharing a machine is fine; sharing an account is not, because the audit trail loses meaning.
Can I edit the same consultation on two devices at the same time? Yes, but the granularity matters. Per-field last-write-wins is fine; per-consultation last-write-wins means one device's edits clobber the other's. Test this before you adopt a tool, because most tools get the granularity wrong by default.
How do I pick up an OPD note on my home PC if I never save? You don't have to save. Every change you make is in the database within seconds of making it. The "Save" button, if it exists, is a vestige. Look for a "save state" indicator that shows "Saved" or "Up to date" instead of "Unsaved changes" — that distinction is the whole feature.
What about the patient name visible at the top of the consultation? The patient identifying details are part of the consultation row. They sync with the rest of the consultation. If you anonymise the consultation for a screenshot or a teaching case, anonymise on the source device, then re-open on the second device to confirm the change propagated.
Does this cost more than local-only software? Marginally, because the database is hosted and the storage is metered. The cost is small compared to the time saved on "where is that file" and "which version is the latest." Most doctors adopt cloud-sync software and stop thinking about it within a week.
Related reading
- Will I lose my work if my laptop crashes mid-prescription?: the write-side of the same problem; autosave every 10 seconds.
- How do I back up my clinic records so they survive a hard-drive crash?: the storage side, R2 + Convex in our setup.
- How do I safely share a prescription or report with a patient online?: the patient-facing version of multi-device.
- Glossary: Patient ID, the named term for the auto-generated short identifier that follows the consultation across devices.
- FAQ: all questions about clinic software for Indian OPD, every follow-up question across the setup cluster in one place.