Vũ Duy AnhCase study · No. 02ENVI

Case study No. 02 · 2025 · Telehealth & booking

Healthcare platform

Sepolia Health

A clinic workflow, digitised from booking to medical records to remote consultations over video and an AI assistant. One NestJS backend serves the patient app, the doctors' portal and the front desk.

Read the case ↓ Source code
Plate II. Mortar, chamomile & stethoscope
Plate II. Mortar, chamomile & stethoscope
Role
Backend Developer
Timeline
6 months · 2025
Team
3 people
Platforms
Web · Mobile · API
Stack
Next.js · NestJS · Expo · PostgreSQL
01

The problem

What had to be solved, and what made it hard.

Paper books and scattered spreadsheets meant an overloaded front desk, double-booked doctors and records that went missing.

Sepolia Health set out to digitise the whole journey: booking, records, payment, and seeing a doctor without travelling to the clinic.

Four kinds of people use it, each with a different screen: patients on a phone, doctors and receptionists on the web, and an admin who runs promotions. They all look at the same appointments, so the hard part is keeping one truth in sync across them.

I was the Backend Developer: I designed the database, built the core APIs, integrated the third-party services and tuned the system for real-time use.

02

How it is built

Drawn to match the system as deployed. Numbers on the drawing refer to the notes below.

Three-tier: two clients, one API, then data and services. Every client talks to the same NestJS gateway; the chatbot runs as its own service and asks the API for real schedules instead of guessing.

TIER 1 · CLIENTSTIER 2 · APITIER 3 · DATA & SERVICESPatient appReact Native · ExpoWeb portalsNext.jsdoctors · front desk · adminpatientsNestJS APIsingle gateway · DockerAuth & rolesBooking & schedulesRecords & resultsPayments & vouchersNotifications · push, emailPostgreSQLsource of truthRediscache · hot readsAWS S3PDF results · attachmentsStreamChatchat · routed per clinicZoom Meeting APIvideo consultationsAI chatbot serviceRAG · function callingREST · JWTREST · JWTcachefileschannelsmeetingsfunction calling → schedulesDigitalOcean · Docker1234567
Sheet1 / 1Sepolia Health healthcare platformFig. 1. Three-tier architecture, one backend for every clientDrawn byV. D. Anh · 2025Scalenot to scale

↔ Scroll sideways to see the whole drawing

  1. 1

    Patient app

    React Native with Expo: booking, records, payments, chat and video visits.

  2. 2

    Web portals

    Next.js for doctors, the front desk and admins, each with its own role and screens.

  3. 3

    NestJS gateway

    The single API: auth, booking, records, payments, vouchers and notifications.

  4. 4

    PostgreSQL + Redis

    Postgres is the source of truth; Redis caches hot reads so the database is not hammered.

  5. 5

    AWS S3

    Medical attachments and PDF results, downloaded by patients through the app.

  6. 6

    StreamChat & Zoom

    Bought, not built: real-time chat routed per clinic, and video consultations.

  7. 7

    AI chatbot service

    RAG over medical documents plus function calling into the API for doctors' real schedules. Deployed on DigitalOcean.

Stack, by layer

Backendthe shared core
NestJSTypeScriptREST API
Datatruth & cache
PostgreSQLRedisAWS S3
Integrationsbought, not built
StreamChatZoom APIAI Chatbot (RAG)
Clients & opswhere people meet it
React NativeExpoNext.jsDockerDigitalOcean
03

Main features

Real screens from the product. Pick a feature, then step through the flow.

Booking

Booking from three sides: patients book in the app, doctors receive the appointment live on the web, and the front desk books for walk-in patients.

Point of view

The patient picks a profile, a specialty, a doctor and a free slot in the mobile app.

  1. Pick an existing profile (yourself or a relative). Name, phone and date of birth are filled in automatically.

Watch the demo
Step 1/5 · Choose a patient profile

Contact sheet

More screens from the web portal and the mobile app.

04

Hard parts & solutions

Each problem, the approach taken, and the number that shows it worked.

4.1
3platforms on one NestJS backend

One appointment, seen by everyone, at once

Problem

A booking made on a phone has to appear on the doctor's portal and the front desk straight away, while slot lookups from every client hit the same tables.

Approach

NestJS is the single gateway that owns booking. Redis caches hot reads to take load off PostgreSQL, and a booking immediately pushes a notification to the doctor.

4.2
4+integrated services: Zoom, StreamChat, AI, S3

Chat and video without a media team

Problem

Real-time messaging and video calls are products in themselves. Building them in-house would have eaten the whole timeline of a three-person team.

Approach

Buy what is not the core: StreamChat for messaging, with conversations routed to the chosen clinic, and the Zoom Meeting API for consultations. The backend owns identity and permissions; the vendors own the pipes.

4.3

An assistant that does not make up schedules

Problem

A language model will happily answer 'Dr. X works on Tuesday' from nothing. In healthcare a confident wrong answer is worse than no answer.

Approach

A hybrid chatbot: RAG over the clinic's medical documents for general questions, and function calling into the API for anything about schedules, so those answers come from the live roster.

4.4
6core business areas, booking to QR payment

QR codes that cannot be passed around

Problem

A static voucher QR, once photographed, can be shared forever and drain a campaign.

Approach

Live QR codes generated from a promotion and refreshed on a timer set by the admin, plus a dynamic payment QR carrying the exact order and amount.

Results

3

Platforms (web, mobile, API) running on a single NestJS backend

6

Core business areas, from booking and records to QR payments

4+

Integrated services: Zoom video, StreamChat, AI chatbot, AWS S3

05

What I learned

  1. I

    One backend, three front doors

    When web, mobile and the front desk share one API, the API contract is the product the whole team builds against. Agreeing on it early saved more time than any framework.

  2. II

    Build the core, buy the rest

    Scheduling and records are what make this product different; chat and video are not. Spending effort only on the core is how a small team ships a large scope.

  3. III

    AI should answer only what it can look up

    Retrieval for knowledge, function calls for facts. The model writes the sentence; the database decides what is true.

  4. IV

    Design around roles, not screens

    Patient, doctor, receptionist and admin each see the same appointment differently. Modelling permissions per role first made every later screen easier.

Next case study · No. 01

Inventory system

StockFlow Cloud

Multi-branch inventory for electronic components, fully serverless on AWS: a NestJS API on Lambda, Step Functions for imports, and close to zero cost when idle.

Open case
Plate I. Crates under the cloud