Multi-stakeholder healthcare platform

Domain: Healthcare / Patient Management Engagement: Full product build (ongoing) Team Size: Multi-developer, full-stack Recognition: Our client was featured on Shark Tank with the product we built for them.

---

The Problem

A healthcare startup came to us with a comprehensive vision: manage patient care across residential communities in dense urban environments, end-to-end. Residents would book consultations, nursing visits, physiotherapy, ambulance services, and pharmacy orders — all from a single app. Hospitals, nurses, paramedics, and community managers each needed their own interfaces with role-specific workflows.

No off-the-shelf solution could handle the multi-stakeholder complexity, real-time dispatch requirements, and region-specific payment, identity, and notification stacks.

The engineering problem underneath the business problem was harder than it first appeared: six user-facing surfaces sharing a single domain model, real-time emergency dispatch interleaved with batch administrative workflows, and a long tail of third-party providers that had to be swappable without rewriting the product. It's the class of system where a naïve architecture compounds cost with every new feature until velocity collapses in month six.

---

What We Built

A complete healthcare ecosystem with 6 applications, a shared SDK, and an AI-powered emergency dispatcher — delivered as a microservices architecture.

Platform Components

Backend API (NestJS)

• RESTful API serving all frontend applications
• TypeORM with PostgreSQL for relational data
• Bull queues (Redis-backed) for async job processing
• JWT authentication with refresh token rotation
• Swagger/OpenAPI documentation auto-generated

Patient Mobile App (React Native / Expo)

• Consultation and service booking
• Real-time appointment tracking
• Pharmacy ordering with third-party fulfillment integration
• Push notifications via Firebase FCM
• Passwordless OTP authentication

Staff Web App (Next.js)

• Nurse check-in workflows
• Appointment management and scheduling
• Patient vitals recording
• Service fulfillment tracking

Admin Dashboard (Next.js)

• Hospital and community onboarding
• Staff management and KPI tracking
• Financial reporting and analytics
• System configuration

Resident Web App (Next.js)

• Web-based booking for residents without the mobile app
• Account management and history

Shared SDK (npm package)

• Common TypeScript types across all frontends
• API client with token refresh interceptors
• Auth store (Zustand with localStorage persistence)
• Ensures consistency across 4 frontend applications

AI Emergency Dispatcher

• Real-time emergency call handling with Socket.IO
• Live audio transcription via Whisper
• Symptom extraction and urgency classification through an internal LLMRouter that dispatches across self-hosted Ollama (LLaMA 3), OpenAI, and Anthropic Claude
• 10+ emergency scenario scripts for operator training

---

Architecture Deep Dives

The interesting engineering isn't in any single app — it's in the seams between them. A few of the decisions that paid off.

Domain model & tenancy

Communities, Hospitals, Staff, and Residents are separate first-class entities with explicit relationships, not subtypes of a generic User. A hospital serves many communities; a community is served by many hospitals; staff belong to a hospital; residents belong to a community. Every query that matters is scoped through this graph, enforced at the ORM layer rather than at call-sites. We chose normalized relational storage (PostgreSQL + TypeORM) over a document store because the workload is dominated by multi-entity joins — service fulfillment, billing reconciliation, staff scheduling — all of which degrade badly in denormalized schemas once real data arrives.

Shared SDK & type safety

The SDK is the single source of truth for API contracts across four frontends. It's published as an npm package and consumed by the mobile app, the staff web app, the admin dashboard, and the resident web app. The token-refresh interceptor is the piece that earns its keep: on a 401, the SDK queues concurrent requests, triggers a single refresh round-trip, and replays the queued calls transparently. Every frontend would otherwise re-implement this with subtle variations — and the variations would silently diverge over time.

Booking engine as a state machine

Nine service types (Ambulance, First Aid, Neighbor SOS, Remote Care, Consultation, Home Nursing, Physiotherapy, Routine Checkup, Blood Test) share one lifecycle: requested → assigned → en-route → in-service → completed / cancelled, with per-type policy hooks for SLAs, dispatcher rules, and payment triggers. What could have been nine near-duplicate modules is one typed engine plus a handful of small policy files. Adding a tenth service type is a config change, not a feature project.

Real-time AI dispatch pipeline

End-to-end flow: Socket.IO call channel → Whisper streaming transcription → LLMRouter → urgency classifier → operator UI.

The LLMRouter abstraction sits between call-sites and three concrete backends — self-hosted Ollama (LLaMA 3), OpenAI, and Anthropic Claude — and routes each request by four dimensions: content sensitivity, required reasoning depth, latency budget, and cost ceiling. Sensitive transcripts stay on self-hosted Ollama for data-locality reasons; higher-reasoning triage escalations route to OpenAI or Anthropic for answer quality; bulk classification takes the cheapest provider that meets the latency budget. Every call-site depends only on the router interface, so swapping or adding a provider is a one-place change. The multi-provider posture also means emergency flows degrade gracefully when any single provider is unavailable — critical for a dispatch system that cannot fail closed.

Role-based access (6 roles)

Role	Auth Method	Interface
Super Admin	Email + Password	Admin Dashboard
Hospital Admin	Email + Password	Staff Web App
Nurse	Email + Password	Staff Web App
Paramedic	Email + Password	Staff Web App
Community Manager	Email + Password	Staff Web App
Resident	Passwordless OTP	Mobile App / Web App

Authorization is enforced at the API layer through guards that consult role-scoped session state carried by the SDK — UI-layer gating is treated as convenience, not security. The same role claims drive feature gating and audit logging, so a single rule change propagates everywhere a role appears.

Async work with Bull + Redis

Notification fan-out, payment-webhook reconciliation, and report generation all run on Bull queues backed by Redis. Each job carries an idempotency key; retries use exponential backoff with jitter; dead letters are surfaced through the error-tracking pipeline. The upshot is that a double-delivered webhook or a retried FCM send never double-books an appointment or double-charges a resident — which is not an edge case in practice, it's Tuesday.

Integrations — insulated behind adapters

Capability	Integration
Payments	Third-party payment gateway (adapter-based, swappable)
Push notifications	Firebase FCM
SMS / WhatsApp	Third-party messaging gateway
Storage	AWS S3
Pharmacy fulfillment	Third-party pharmacy fulfillment API
LLM inference	Ollama (self-hosted), OpenAI, Anthropic Claude — behind LLMRouter
Speech-to-text	Whisper (streaming)

Every provider sits behind an adapter. The product code talks to a single payments interface, a single messaging interface, a single pharmacy interface, a single LLM router. This is what makes the third-party names genuinely swappable rather than a nominal abstraction — and it's what lets the platform be repositioned for a new market (different payment rails, different messaging providers, different clinical partners) as a configuration change rather than a re-architecture.

---

Engineering Practices

Environments & infrastructure

Docker Compose for local dev parity with production. Separate, isolated PostgreSQL and Redis instances for dev, staging, and prod, each with its own credentials and backup schedule. Makefile targets wrap the operational verbs — make db-backup, make db-restore, make health — so a new engineer has a working, inspectable stack on day one instead of spending a week assembling one from a wiki.

API contract discipline

Swagger/OpenAPI is auto-generated from the NestJS source of truth. The shared SDK consumes those generated types, so breaking API changes surface as TypeScript compile errors in every frontend before they ever reach QA. The feedback loop on contract drift is minutes, not sprints.

Observability

Structured logging with correlation IDs across the request path — Socket.IO dispatch, HTTP API, Bull worker. Error tracking captures exceptions at every tier with user, role, and tenant context attached. Health endpoints feed container-orchestrator probes so a bad deploy rolls back automatically instead of pager-duty-ing a human.

Auth hardening

JWT access tokens paired with refresh tokens, rotated on each use, with reuse detection: if a refresh token is presented twice, the entire session family is revoked and the user is forced to re-authenticate. Staff accounts use email + password with per-role lockout policies; residents use passwordless OTP. All token validation happens in a single verified path so an auth bug is fixed in one place.

---

Tech Stack

Layer	Technology
Backend	NestJS 11, TypeORM, PostgreSQL, Redis, Bull
Mobile	React Native, Expo 50
Web Apps	Next.js 16, React 19, Tailwind CSS 4, shadcn/ui
State	Zustand, React Hook Form + Zod
Tables	TanStack React Table
Auth	JWT with refresh token rotation, passwordless OTP
Real-time	Socket.IO
AI / LLM	LLMRouter across Ollama (LLaMA 3, self-hosted), OpenAI, Anthropic Claude; Whisper for streaming STT
Payments	Third-party payment gateway (adapter-based)
Messaging	Firebase FCM (push), third-party SMS/WhatsApp gateway
Storage	AWS S3
DevOps	Docker Compose, Makefile automation
Observability	Structured logs with correlation IDs, error tracking, health checks
API contracts	Swagger/OpenAPI auto-generated; SDK-consumed types

---

Outcome

• Full platform delivered and operational across multiple residential communities
• Our client took the product to Shark Tank, where it was featured on the show
• 6 coordinated applications sharing a single backend with role-isolated access
• AI dispatcher enables faster emergency response with automated triage, with multi-provider LLM routing ensuring the dispatch path keeps working even when a single provider degrades
• Shared SDK + state-machine booking engine meant adding a new service type or standing up a new frontend was a days-not-weeks job
• Adapter-insulated integrations kept the core product independent of any single payments, messaging, pharmacy, or LLM vendor

---

Key Takeaway

This project demonstrates our ability to architect and deliver a multi-application healthcare ecosystem from scratch — backend, mobile, web, admin, and AI components — with production-grade auth, payments, notifications, real-time dispatch, and a provider-agnostic LLM layer. The shared SDK pattern, state-machine booking engine, and adapter-based integration discipline we developed here have since become standards in our toolkit for every multi-surface product we take on.