Pradip Kumar Singh

The problem

A patient should be able to describe symptoms out loud in the app and be triaged conversationally — speech in, speech out, in real time, over a mobile network that drops. And when the AI reaches the limit of what it should decide, the patient needs to reach a real doctor without repeating themselves. That second half is the hard part: the escalation creates an appointment and pages a clinician, so it can never fire twice because a phone retried a request.

What I did

Built the stateful edge service that owns the conversation while the model layer stays stateless. A WebSocket protocol with numeric message codes and a handler registry keeps the client contract explicit and versionable; auth is validated during the HTTP handshake before the socket is ever accepted. Speech synthesis streams back as Opus chunks so the patient hears a reply forming rather than waiting for a complete file, with a buffered fallback for weaker clients.

State is deliberately two-tier: Redis holds liveness, Postgres holds truth. A sliding-window TTL manager batches expiry refreshes into a periodic pipelined flush instead of writing on every message, and a reconciliation job closes exactly the sessions Redis has forgotten. Server-driven ping/pong detects dead sockets; reconnects resume a conversation rather than restarting it; undelivered critical messages are replayed; and a Redis-backed queue routes messages across pods so a horizontally scaled deployment can still reach a socket pinned elsewhere.

The doctor handover is guarded by a Redis SET NX lock keyed to the session, so duplicate requests from client retries or reconnects cannot produce two clinician pages or two appointments — with a deliberate fail-open policy and lock release on failure so a genuine retry still works. Failures in the speech or model chain degrade into product behaviour rather than an error state: the conversation preserves what it has and offers the human doctor instead of a dead end. Latency-sensitive extras — pre-consult note generation, record upload, appointment cancellation — run off the critical path.

Outcome

A patient speaks to the app, gets triaged, and is handed to a clinician who already has an AI-generated pre-consult note in hand. Dropped connections and device switches resume instead of restarting, and the duplicate-escalation class of bug is closed by design rather than by monitoring.

The problem

Patients receive lab reports they cannot read. The product goal was plain-language explanation and summaries in the patient's own language, streaming in as they're generated, with a browsable history. The engineering problem underneath is that model calls are slow, expensive and non-deterministic — so a mobile client retrying on a flaky network must not pay twice, and must not receive a different explanation of the same medical report the second time it asks.

What I did

Made idempotency an explicit, documented API contract rather than a hopeful implementation detail. Every mutating request resolves a turn gate before any model call, keyed on a client-supplied message ID and backed by a unique database index. A new turn generates; a duplicate of a completed turn replays the stored answer verbatim; a duplicate of a turn still in flight returns 409 so the client backs off instead of spawning a parallel request; a message ID reused across a different session or lane is rejected outright. Retries are logged as ordered variants against the same turn, so the history is auditable.

One session runs four parallel agent lanes — explanation, short summary, long summary, suggested questions — each with its own thread. Patient context is fetched once per session and cached, so the lanes don't each re-fetch the same clinical record. Because this is clinical content, every stored answer carries both the patient-language text and an English audit copy as first-class fields.

Two decisions I'd defend in any review. First, the read model is separated from the orchestration internals: conversation history is rebuilt from a durable turn log, never from agent checkpoints, so the UI contract survives changes to the orchestration layer. Second, streaming was designed for the client rather than the server — a cached replay emits the identical event sequence as live generation, so the app has one rendering path instead of a cache branch. Database unavailability is handled by a fail-fast health gate returning 503 with a background recovery loop, rather than a reconnect check before every operation; I wrote the trade-off and its latency cost down as a decision record so the next person doesn't relitigate it.

Outcome

Retries became free and safe on the most expensive path in the product. The client team ships against one streaming contract, and session history survives orchestration changes. The session-persistence design was written up as a guide for other teams adopting the same pattern.

The problem

Prescriptions arrive as scanned documents and consultation records, with an upstream AI extracting the medicine lines. That extraction is not stable: re-scan the same prescription and the drug names come back worded differently and the generated identifiers change. Turning that stream into daily medication reminders a patient actually acts on is a safety problem wearing the costume of a CRUD service. A duplicated medicine or a silently changed dose is a clinical incident, not a bug ticket.

What I did

Designed the service on the assumption that the AI upstream is unreliable, and pushed that assumption into the data model rather than scattering defensive checks through the business logic. Medicine identity is resolved by a deterministic fallback ladder — prescription line, then extracted identifier, then generic name, then display name — with drug formulation as a hard gate at every tier. The extractor's own generated ID is explicitly refused as a merge key, with the reasoning recorded in the code, because it changes across re-extractions of an identical document. Every medicine row carries source document, record context and the prompt version that produced it, so any clinical value on a patient's screen is traceable back to what generated it.

The safety boundary is a consent gate: nothing extracted from a prescription becomes a live reminder until the patient approves it, optionally editing dose and timings first. Visibility is decided by a single shared predicate, so ingest, fetch, comparison and adherence cannot drift apart into inconsistent views of what the patient agreed to — and "no reminders yet" is an explicit successful response, not an error. A stale-write guard stops an older prescription from overwriting a newer dose or schedule, scoped deliberately to only the ingest type where document ordering is genuinely monotonic.

Timezone correctness is treated as a first-class concern, because in a daily-habit product an off-by-one date shows the patient the wrong day's doses. Storage is UTC, responses render in the patient's timezone, date-only fields expand to inclusive end-of-day, the field-type registry is declared rather than implied, and "today" resolves against the reminder's own timezone instead of the server's. On the storage side the model is shaped for its database: one denormalised document per patient for single-partition reads, adherence recorded as a single atomic increment against a nested date-and-slot map, append-only audit and change trails beside every mutation, and soft deletes only so clinical history is never destroyed. The backend deliberately owns no scheduler — it stores reminder data and notification offsets and lets the device schedule, which is written down as a contract so nobody adds a cron job later.

Outcome

Patient-approved reminders that survive repeated re-scans of the same prescription without duplicating a medicine or quietly changing a dose, with a complete audit trail behind every value. The identity-resolution and provenance approach became the pattern for handling AI-extracted clinical data elsewhere in the platform.