Skip to content
Bilal Ahmed

Case studiesHealthSIA

Healthcare Care-Coordination Platform

HealthSIA

Healthcare Care-Coordination Platform

A multi-role healthcare platform supporting web administration, mobile applications, REST APIs, realtime communication, clinical plans, questionnaires, appointments, notifications and reporting.

Role
Primary Full-Stack & Cloud Engineer
HealthSIA product visual
Product interface preview

Business problem

Clinics and care teams need coordinated workflows across administrative and clinical roles for plans, questionnaires, appointments and communication.

Web administrators and mobile clients require shared API contracts, role-aware access and reliable notifications.

Operational reminders and timezone-sensitive jobs must run predictably for US deployment requirements.

Project context

HealthSIA is a care-coordination platform with seven roles and more than twelve clinical and operational modules.

Three application surfaces exist: an admin web portal, mobile applications, and a shared REST API plus Socket.IO backend.

Team context

Three-person delivery team: primary web/backend/database/infrastructure ownership, one mobile developer, and one QA engineer.

Mobile applications were developed separately. I developed the backend APIs consumed by mobile.

Limited frontend support existed for selected form work. This case study does not claim authorship of every frontend line.

Responsibilities

  • Backend architecture
  • Administrative web application
  • MySQL database
  • Sequelize migrations and seeders
  • AWS RDS
  • Google Cloud Run
  • Cloud Scheduler
  • Vercel
  • SendGrid emails
  • Firebase notifications
  • Google Cloud Storage
  • Socket.IO chat
  • Authentication and role-based access
  • Mobile-facing APIs
  • Development and production environments
  • Deployment and maintenance

Architecture

Admin web and mobile clients consume a shared API and Socket.IO layer.

MySQL on AWS RDS stores clinical and operational data with migrations and seeders managed through Sequelize.

GCP Cloud Run, Cloud Scheduler, Cloud Storage, SendGrid and Firebase Cloud Messaging support runtime, jobs, files, email and push notifications.

Architecture overview

HealthSIA system components

Conceptual ownership map for hiring audiences. Internal topology, credentials and sensitive operational data are intentionally omitted.

  1. 01Admin web portal
  2. 02Mobile applications
  3. 03REST API
  4. 04Socket.IO realtime layer
  5. 05MySQL / AWS RDS
  6. 06Sequelize migrations and seeders
  7. 07Cloud Run services
  8. 08Cloud Scheduler jobs
  9. 09Google Cloud Storage
  10. 10SendGrid
  11. 11Firebase Cloud Messaging
  12. 12Vercel frontend hosting

Architecture diagram

System overview

Admin web and mobile clients connect to the API and Socket.IO layer, which uses MySQL, storage, email, push and scheduler services.

Diagram of HealthSIA clients, API, database and supporting cloud services

Architecture diagram

Authentication roles overview

Seven roles map onto role-aware dashboards and API authorization.

Diagram of seven HealthSIA roles connected to authorization

Architecture diagram

Scheduled-job flow

Cloud Scheduler triggers protected API endpoints for reminder and readiness jobs.

Diagram of scheduler jobs calling protected HealthSIA API endpoints

Systems

Frontend

  • Administrative web application for multi-role operational workflows
  • Role-specific dashboards and selected form surfaces
  • Vercel-hosted web deployment

Backend

  • Node.js API shared by web and mobile clients
  • Socket.IO chat with pagination and unread handling
  • Mobile-oriented auth and resource routes including refresh-token support
  • System-JWT-protected scheduler endpoints for automated jobs

Database

  • Large MySQL schema with soft deletes and clinical entities
  • Seeders for food, exercise, FIP and PROM reference data
  • Performance indexes
  • FIP normalization and cleanup scripts
  • Refresh-token migrations
  • Measurement edit-history migrations
  • Preservation of historical patient answers

Cloud infrastructure

  • GCP us-east4 regional deployment
  • Cloud Run for API services
  • Cloud Scheduler for timezone-sensitive jobs
  • Google Cloud Storage
  • AWS RDS for MySQL
  • Vercel for the admin web application
  • Separated development and production environments

Security

  • JWT authorization across web and mobile authentication differences
  • Role-based access for seven roles
  • Rate limiting on resend and forgot-password email flows
  • System-JWT protection for scheduler endpoints

Integrations

  • SendGrid for verification, reset, setup, welcome and appointment emails
  • Firebase Cloud Messaging for device notifications
  • Device-token lifecycle and inactive-device cleanup
  • Cloud Scheduler callbacks into protected API endpoints

Technical deep dives

Role model

The platform supports seven roles: Super Admin, Admin, Clinical Admin, Surgeon, Therapist, Nutritionist and Patient.

Web and mobile authentication differ where product requirements demand it, while shared business logic remains centralized in the API.

Role-specific dashboards keep operational surfaces aligned with each role’s responsibilities.

Mobile API integration

Mobile clients use dedicated auth routes under a mobile auth namespace and mobile-specific resource routes where needed.

Refresh-token support helps long-lived mobile sessions without duplicating core domain logic.

Shared business rules stay in the backend so web and mobile clients remain consistent.

Technical challenges

Database evolution

A large clinical schema required careful migrations, seeders and historical-data preservation.

  • Soft deletes and clinical entities
  • Food, exercise, FIP and PROM seeders
  • Indexes and cleanup scripts
  • Refresh-token and measurement edit-history migrations
  • Preserving historical patient answers

US cloud and timezone handling

US regional deployment required predictable scheduler behaviour for care reminders.

  • GCP us-east4
  • Cloud Run and Cloud Scheduler
  • Missed-meal and missed-exercise jobs
  • Surgery-readiness reminders
  • System-JWT-protected scheduler endpoints

Socket.IO performance

Chat needed controlled retrieval and update behaviour as conversations grew.

  • Paginated chat retrieval and messages
  • Older-message loading
  • Database indexes
  • Controlled read updates
  • Timeout improvements and unread counts

Notifications and email

Push and email flows required lifecycle handling and abuse resistance.

  • Firebase Cloud Messaging and device-token lifecycle
  • Offline notifications and inactive-device cleanup
  • SendGrid transactional email set
  • Rate limiting on resend and forgot-password flows

Trade-offs

Separate mobile client ownership

Decision: Keep mobile UI ownership with a dedicated mobile developer while owning the APIs those clients consume.

Consequence: Integration contracts matter more, but delivery stays realistic about frontend authorship boundaries.

Shared API for web and mobile

Decision: Centralize business rules in one API with mobile-specific auth/resource routes where required.

Consequence: Reduces duplicated domain logic while still accommodating client differences.

Results

Testing-phase platform foundation

Delivered a coherent full-stack and cloud foundation for a multi-role healthcare product now in testing.

Cross-client API coherence

Established shared backend contracts for admin web and separately developed mobile applications.

Operational automation

Implemented scheduler-backed reminder flows with protected endpoints for US timezone requirements.

Constraints

  • Status: testing — not a completed production launch
  • Mobile UI developed separately
  • No public project employment dates displayed
  • No PHI, PII, medical identifiers or licensed questionnaire content

Stack

  • Next.js
  • Node.js
  • TypeScript
  • Socket.IO
  • MySQL
  • Sequelize
  • AWS RDS
  • Google Cloud Run
  • Cloud Scheduler
  • Google Cloud Storage
  • Firebase
  • SendGrid
  • Vercel

Confidentiality