Domi · technical view

Under the hood

The same system as the diary app, seen from the server side. Everything here is live and belongs to your private demo …: use the app in another tab and watch requests, events, texts and database rows appear.

ConnectingOpen the app

How it fits together

Two screens, one server. The server owns the rules: who can see which patient, who gets offered a slot, and when an offer runs out. The screens only display what the server decides.

Screens
Office appEvery diary, waiting list, texts. Laptop or tablet.
Clinician appToday's round, patient records, notes. Phone-first.
HTTPS + JSON
Live events (SSE)
Server
APISigned sessions, role checks, input validation, request log. Each request runs inside the visitor's own sandbox. server/index.js
Booking serviceEvery diary change in one transaction. Texts and live events are released only after it commits. server/service.js
Refill engineRanks the waiting list and plans the offer: one at a time, or the top three at once when the visit is close. Pure rules, unit tested. server/refill.js
Offer timerEvery 5 seconds, unanswered offers that have run out pass to the next person.
Data & services
DatabasePatients, visits, notes, waiting list, offers, texts, audit. One in-memory SQLite per demo here; one Postgres database in production. server/db.js
SMS gatewayTwilio-compatible. Outgoing texts and incoming replies.
Routingpostcodes.io for postcodes, OSRM for road driving times.
POST /api/sms/inbound (signed)

A cancellation, end to end

What happens on the server between someone pressing Cancel and the clinician's phone updating.

  1. Visit cancelledThe patient texts CANCEL, or the office or clinician cancels. The server checks the visit hasn't started.POST /api/sms/inbound
  2. Patient toldThe cancelled patient gets a text, recorded in the outbox before it is sent.messages
  3. Waiting list rankedHard rules first: short notice, time free, mornings or afternoons, travel area. Then priority, wait and preferred clinician.rankCandidates()
  4. Offer planned and textedHours away: one person at a time. Under an hour: the top three at once, first YES wins. Reply windows shrink as the visit gets closer.planOffer()
  5. Reply arrivesThe gateway posts the reply, signature checked. YES books; the others are told it's gone. NO or silence moves on.X-Twilio-Signature
  6. Diary updatedNew visit written, double-booking check, note on the record, clinician texted, every open screen updated.slot.filled

Live system

Refreshed as things happen. Office access only: clinicians can't open this page. Times are the demo clock.

API requests

AtMethodPathStatusTookWho

Live events

Events appear when the diary changes. Cancel a visit in the app.

Offers

#PatientRoundScoreStatusReplies close

Signed-in devices

Lost a phone? Sign it out from here
WhoDeviceHowLast active

Audit log

Every change and every record opened
TimeWhoActionDetail

Database

The actual tables behind the app, newest rows first.

API endpoints

Before real patients

  • Data protectionHealth data is special category under UK GDPR. DPIA, privacy notice, data processing agreements with every supplier, and the NHS Data Security and Protection Toolkit if working with NHS contracts.
  • HostingUK-region hosting, encrypted at rest and in transit, daily backups with tested restores.
  • Sign-inDone in this demo: scrypt-hashed passwords, authenticator-app codes, lockout, server-side sessions that time out, and remote sign-out. Still to add: password reset by email, each person setting up their own authenticator, and recovery codes.
  • TextsInbound replies are already signature-checked. Keep clinical detail out of texts: times and names only. Offer to a nominated carer where the patient can't text.
  • Offline useRural visits lose signal. The clinician app should cache today's round and queue notes until it reconnects.
  • IntegrationsPCSE Online (notifications and GOS 6 claims), lab orders, calendar sync and GP letters are the likely next steps.