Case Study · Healthcare Systems Software
A scalable, event-driven Hospital Management System designed to automate clinic operations, appointment workflows, patient management, and WhatsApp communication while ensuring fault tolerance through background workers, idempotent webhooks, and distributed job processing.
Vision
Moving beyond passive record storage to proactive, event-driven clinic orchestration.
Traditional hospital software acts merely as a passive CRUD database. Clinic staff spend countless hours manually calling patients for reminders, emailing lab reports, handling queue delays, and struggling with doctor schedule changes.
Clinqer automates administrative workflows from end to end: Patient Registration → Doctor Scheduling → Appointment Booking → Check-In → Consultation → Prescription Records → Lab Reports → Billing → WhatsApp Reminders → Real-Time Dashboard Updates.
Goals
Architecture
Decoupled Python Django REST API, Redis caching, BullMQ job queues, SSE streaming, and a Qdrant-backed RAG chatbot deployed on AWS EC2.
flowchart TB
subgraph Clients["Clients - Admin, Doctor, Reception"]
Web["Web Browsers and Mobile UI"]
end
subgraph Server["AWS EC2 Infrastructure"]
Nginx["Nginx Reverse Proxy"]
Gunicorn["Gunicorn WSGI Server"]
API["Django REST API Engine"]
SSE["SSE Stream Server"]
Redis["Redis Cache and Lock Manager"]
BullMQ["BullMQ Distributed Queue"]
Workers["Worker Processes"]
DB[("PostgreSQL Database")]
Chatbot["RAG Chatbot Service"]
Qdrant[("Qdrant Vector DB")]
end
subgraph External["External Services"]
WA["WhatsApp Business API"]
Gemini["Gemini LLM API"]
end
Clients --> Nginx
Nginx --> Gunicorn
Nginx --> SSE
Gunicorn --> API
API --> DB
API --> Redis
API --> BullMQ
API --> Chatbot
Chatbot --> Qdrant
Chatbot --> Gemini
Chatbot --> DB
BullMQ --> Workers
Workers --> WA
Workers --> DB
Domain Modules
stateDiagram-v2
[*] --> Booked : Patient or Receptionist books slot
Booked --> Confirmed : WhatsApp alert sent
Confirmed --> CheckedIn : Patient arrives at clinic
CheckedIn --> Consultation : Doctor begins session
Consultation --> Completed : Doctor finishes consultation
Completed --> PrescriptionGenerated : Rx and Reports attached
PrescriptionGenerated --> [*]
Communication
Ensuring high-delivery messaging with cryptographic signature checks and zero-duplicate webhook execution.
flowchart TB
Meta["Meta WhatsApp Webhook"] --> Nginx["Nginx Reverse Proxy"]
Nginx --> Endpoint["Django Webhook Endpoint"]
Endpoint --> Verify["Verify HMAC SHA-256 Signature"]
Verify --> Lookup{"processed_events Table
event_id exists?"}
Lookup -->|Yes| Duplicate["Return 200 OK - Skip Execution"]
Lookup -->|No| Store["Insert event_id into Database"]
Store --> Publish["Publish to BullMQ Queue"]
Publish --> Worker["Worker Process"]
Worker --> BizLogic["Execute Business Logic"]
BizLogic --> Success["Commit Transaction and Mark Done"]
Every incoming webhook request from Meta includes an X-Hub-Signature-256 header. Clinqer computes an HMAC-SHA256 signature using the app's secret key against the raw request body and verifies it using constant-time comparison before processing.
To handle Meta API network retries without sending duplicate reminders or processing double payments, Clinqer stores each event_id in a processed_events table with a UNIQUE SQL constraint. If an event ID already exists, the endpoint immediately responds with 200 OK and halts duplicate execution.
Async Processing
| Schedule | Cron Task | Execution Details |
|---|---|---|
| Every Morning | Doctor Schedule Sync | Validates doctor leave calendars, generates daily slot availability, and locks capacity limits. |
| Every Hour | Upcoming Reminders | Queries appointments scheduled in next 24h and enqueues interactive WhatsApp reminder jobs. |
| Every Night | Daily Reports & Cleanup | Aggregates hospital revenue, compiles daily visit metrics, and archives processed webhook records. |
Heavy asynchronous tasks—such as PDF report generation, WhatsApp template dispatch, and email delivery—are pushed to BullMQ queues powered by Redis. Worker processes consume jobs independently, freeing Django API threads to handle incoming HTTP requests with sub-50ms response times.
Downstream API failures (e.g. Meta service degradation) trigger exponential backoff retry policies. After exceeding maximum attempt thresholds, failed jobs transition to a Dead Letter Queue (DLQ) with structured error logging and alerting.
Real-Time
Pushing instant updates to clinic dashboards via Server-Sent Events, without polling overhead.
When a patient arrives and check-in is logged, an SSE stream pushes the event instantly to connected reception and doctor dashboards, updating live wait-list counters and patient queue positions over a single long-lived HTTP connection.
As doctors finish consultations and generate prescriptions, the same SSE stream pushes updates that refresh pharmacy queue status and recalculate administrative revenue analytics in real-time.
AI / Analytics
Natural-language querying of clinical data for doctors, powered by Retrieval-Augmented Generation over a Qdrant vector index.
flowchart LR
Doctor["Doctor asks a natural-language question"] --> API["Django Chatbot Endpoint"]
API --> Embed["Generate Query Embedding"]
Embed --> Qdrant[("Qdrant Vector DB")]
Qdrant --> Retrieve["Retrieve Top-K Similar Records"]
Retrieve --> Context["Assemble Retrieved Context"]
Context --> Gemini["Gemini LLM - Generate Answer"]
Gemini --> Response["Natural-Language Response"]
Response --> Doctor
Patient records, appointment history, clinical notes and consultation records, and billing & lab reports are embedded and indexed in Qdrant. This lets doctors ask conversational questions about a patient or the clinic's activity instead of navigating multi-step report screens.
An incoming question is embedded and matched against the indexed clinical data using Qdrant's similarity search. The retrieved records are assembled into context and passed to the Gemini API, which generates a direct natural-language answer grounded in the retrieved patient, appointment, clinical, and billing data.
Performance
Query-level database tuning and end-to-end automation measured against production traffic.
| Metric | Result | Detail |
|---|---|---|
| p95 Query Latency | 300ms → 33ms | Composite indexes added on frequently filtered and joined columns (appointment date, doctor, and status) cut p95 response time roughly 9x. |
| Appointments Served | 1,000+ | Volume of appointments processed end-to-end through the booking, reminder, and consultation pipeline. |
| Manual Overhead Reduction | 80% | Driven directly by the BullMQ-based automation and idempotent webhook processing described above — reminders, report generation, and duplicate-event handling that previously required manual staff intervention now run unattended. |
Beyond Redis caching, the primary latency win came from database-level composite indexes on the columns most frequently used together in query filters and joins — cutting p95 latency from ~300ms to ~33ms on hot paths like appointment lookups and queue queries.
The 80% drop in manual administrative overhead is a direct outcome of the BullMQ distributed queue and idempotent webhook system: reminders, report generation, and duplicate-event protection that staff previously handled by hand now run automatically and reliably.
Production Infra
Enterprise Linux deployment utilizing Nginx, Gunicorn, Systemd, Redis, and PostgreSQL on AWS, deployed via a GitHub Actions CI/CD pipeline.
clinqer-api.service — Manages Gunicorn application server lifecycle.clinqer-worker.service — Manages distributed BullMQ queue workers.redis.service & nginx.service — Managed system daemons with auto-restart on boot.
Pushes to the main branch trigger a GitHub Actions workflow that builds the application, runs the automated test suite, and — on success — deploys to the EC2 instance. Systemd continues to own the running services in production; the pipeline replaces manual, ad-hoc deployment with a consistent build → test → deploy sequence that restarts clinqer-api.service and clinqer-worker.service on release.
Database
erDiagram
Doctors ||--o{ Appointments : conducts
Doctors ||--o{ Prescriptions : writes
Patients ||--o{ Appointments : books
Patients ||--o{ Prescriptions : receives
Patients ||--o{ Reports : owns
Appointments ||--o{ Invoices : generates
Appointments ||--o{ Notifications : triggers
Engineering
System architecture, idempotent webhook design, and backend engineering executed by Dhrutinandan Swain at N6T Technologies.