ENTRY — RETRIEVED FROM ANAMNESIS

Kairos

Facility transport coordination for senior care facilities.

ROLE

Sole developer

STATUS

MVP in active development

STACK

Node.js Express SQLite EJS Tailwind CSS PM2 Caddy

The story

While working on a senior care rehab unit, I saw firsthand how easily patient care stalls when transportation, EHR charting, and driver scheduling are scattered across manual spreadsheets, documents, and (sometimes) sticky notes. I built Kairos—a self-hosted medical dispatch engine—to replace that operational chaos with a single, real-time logistics queue.

Senior care facilities frequently struggle with a high-stakes logistics bottleneck: coordinating limited transportation assets across multiple care tiers—such as rehab, assisted living, and long-term care. Relying on manual spreadsheets and verbal handoffs leaves staff without real-time visibility, leading to delayed medical appointments and driver scheduling conflicts.

To make Kairos a deployable, self-hosted product that any facility can run, I refactored the system to eliminate single-site hardcoded dependencies. This involved abstracting facility identity bounds, dynamic EHR charting templates, and role-based permissions into a modular configuration layer. Evolving Kairos from a static prototype into a configurable software node taught me as much about product thinking and system abstraction as the initial build taught me about backend architecture.

◈ excerpt — akadaemia anyder field notes

The problem

Small facilities often run transport and scheduling logistics through spreadsheets, Word documents, phone calls, and paper logs. Kairos centralizes it: a scheduling system aware of real hard constraints (limited vehicles, daily appointment caps), role-based access so each staff type sees only what they need, and an audit trail for every decision made.

Technical highlights

◈

Role-based access control

Single source of truth governing 7 distinct staff roles across every route
◈

Append-only audit logging

Full history for notifications, messages, and transport decisions — no silent overwrites
◈

Custom design-token theming system

Light/dark × two brand modes via CSS custom properties
◈

Accessibility suite

CVD simulation, adjustable text scaling, dyslexia-friendly font mode, custom keyboard-navigable widgets
◈

Self-hosted deployment pipeline

PM2 process management behind a Caddy reverse proxy on a Linode VPS

LIVE — SAME SCREEN, FOUR THEMES

The custom dropdown and date-picker widgets were registering two clicks instead of one, causing menus to open and immediately close. At least in the console, live it just looked like the menu wasn't responding at all. As it turns out, wrapping a custom widget in a <label> makes browsers fire off a second, "phantom" click. The fix was swap the <label> for a plain wrapper, researving real <label> tags for native inputs only.

Turning on the hover magnifier was silently wiping out backdrop blurs across the app. Because an SVG filter on <body> breaks position: fixed coordinate spaces, backdrop clipping failed—causing rectangular artifacts to bleed out behind the magnifier (as seen here). I fixed it by moving the SVG filter to a dedicated wrapper div and disabling backdrop-filter while magnification is active.

How this was built

I designed & built Kairos, utilizing Claude for implementation speed, syntax lookups, and code review. The system architecture, domain models, and design decision is my own: from the append-only audit log and RBAC permissions to the database foreign key strategies and graceful degradation patterns.