Most healthcare apps assume one thing:
the patient can complete the process on their own.
Reality is messier.
Some patients need hand-held guidance - especially during pre-registration:
- Uploading identity documents
- Submitting insurance details
- Reviewing long consent forms
- Adding signatures in the right place
So we built a paired application: one screen for the patient, one for the facility staff - both synced in near real time.
On paper, it sounded simple.
In practice, it forced us to rethink control, synchronization, and trust between devices.
The Idea: Two Devices, One Shared Flow
The goal was straightforward:
- A patient-facing app (typically on a tablet)
- A facility staff app (on another tablet or desktop)
- Both screens stay in sync throughout the session
But with a twist.
The facility app acts as the host:
- Controls navigation
- Highlights fields in real time
- Requests signatures
- Guides the patient step-by-step
- Watches progress live, without taking over the patient’s device completely
Think of it like screen sharing, but purpose-built for healthcare workflows.
The First Question We Hit: Who’s Actually in Control?
We had two active clients:
- Patient app (viewer + input provider)
- Facility app (controller + guide)
This immediately raised design questions:
- What happens if both apps send events at the same time?
- Who decides the “current step”?
- How do we avoid race conditions without slowing the experience?
Our answer was opinionated:
The facility application is the source of truth for navigation.
The patient application owns only data entry.
This single decision simplified almost everything downstream.
Real-Time Sync Without Lag (Or Chaos)
We needed:
- Near real-time interaction
- Bi-directional communication
- High reliability (healthcare ≠tolerance for flakiness)
What we used
- AWS WebSocket + AWS Lambda + DynamoDB for session persistence
Why We Still Needed AWS WebSockets + DynamoDB
But healthcare workflows need more than “live”.
We needed:
- Session recovery if a device reconnects
- A persistent source of truth
- Ability to rehydrate state instantly
So we stored session metadata in DynamoDB:
- Session ID
- Connected participants
- Current step
- Document completion status
- Signature state
AWS WebSocket helped us:
- Track session lifecycle
- Handle reconnections cleanly
- Ensure users rejoined the same flow - not a fresh one
This separation turned out to be crucial.
Highlighting, Guiding, and Signing - In Real Time
Some features that looked “UI-only” were actually system-level problems:
Field Highlighting
- Facility app emits
HIGHLIGHT_FIELD(fieldId) - Patient app visually emphasizes that input
- No DOM sharing, no screen capture -just intent
Guided Navigation
- Patient cannot jump ahead
- Facility controls page transitions
- Prevents incomplete or invalid submissions
Signature Requests
- Facility triggers
REQUEST_SIGNATURE - Patient UI locks into signing mode
- Signature status syncs instantly
This kept the patient experience calm and focused - even when the flow was complex.
Conclusion:
By making the facility app the source of truth for navigation and the patient app responsible only for data entry, we eliminated race conditions, reduced confusion, and kept sessions predictable.
Using Amazon Web Services WebSockets, Lambda, and DynamoDB, we built resilient, recoverable sessions — not just live updates.
Open to feedback — how would you improve this architecture?