HospitalHub

In an emergency in India, families often spend two to six hours phoning hospitals to find a free bed, especially an ICU bed, and make several wasted trips. Hospital systems such as OpenMRS, Bahmni or Practo's HMS manage operations inside one hospital. Nothing gives patients a live view across hospitals.

• Backend: a FastAPI modular monolith with 10 domain modules: auth, hospital, bed, booking, search, realtime, notification, privacy, analytics and admin.
• Web app: React and TypeScript, 20 routes, for patients, hospital staff and admins.
• Mobile app: React Native (Expo) with search, booking, staff bed updates, emergency SOS and an offline cache.
• Spec-driven documentation: about 6,900 lines of requirements, personas, user stories, design and plans from the AI-DLC workflow.

For patients

• Phone and OTP login.
• "Near me" search with PostGIS radius queries, filters for bed type, specialty and emergency capability, and a Leaflet/OpenStreetMap map with colour-coded markers.
• Book and hold: a 30-minute hold with countdown, one extension, cancellation at any time and booking reference codes.
• Smart waitlist: when a bed frees up it is soft-locked and offered to the next person in line.
• Emergency SOS: one tap goes from location to the five nearest ICU or emergency beds to a booking, with a call-102 button. The emergency search skips caches and is never rate-limited.
• Offline fallback with cached nearby hospitals and a 108 dial-out.

For hospitals and admins

• Registration and verification workflow, and a live colour-coded bed dashboard with one-tap status changes.
• 12 standard bed categories plus custom types; configurable hold time, cleaning duration and manual-override window.
• HMS integration webhook with conflict reconciliation.
• Occupancy and booking-trend analytics, exportable to CSV or PDF.
• Admin approval queue, platform KPIs, a demand heatmap, a filterable audit log and a health dashboard.

Privacy (India's DPDP Act)

• Consent per purpose with versioned consent text, consent withdrawal, data-deletion requests and anonymisation.
• A log filter that masks personal data, verified with property-based tests.

• Bed state machine: AVAILABLE → RESERVED → OCCUPIED → CLEANING → AVAILABLE, plus MAINTENANCE. Every change goes through one function that validates the move, writes an immutable history row, publishes the event and records a latency metric.
• No double booking: reservations use SELECT … FOR UPDATE SKIP LOCKED, so concurrent requests can never take the same bed.
• HMS versus human conflicts: a manual update opens a 15-minute override window (a Redis TTL key). Conflicting automatic updates in that window are rejected and logged, and each change records its source: manual, HMS or IoT.
• Emergency-first design: a separate fast path that skips the cache, a rate-limit tier that only logs abuse, and a longer hold time for emergency bookings.
• Security baseline: Argon2id passwords, hashed OTPs with cooldowns and lockouts, 30-minute JWTs with rotating hashed refresh tokens, role-based access, Postgres row-level security with hospital-isolation policies, and API docs disabled in production.
• Testing: 263 backend tests, 27 of them Hypothesis property-based (OTP, phone validation, bed availability, distance search, personal-data masking). Ruff with bandit rules, and CI against real PostGIS and Redis containers.

I built HospitalHub with the AWS AI-DLC methodology inside Kiro, with explicit human approval gates at each stage.

• Inception: 15 clarifying questions, then a requirements spec with IDs (FR-AUTH-01 and so on), 5 personas, 12 epics, 28 user stories with Given-When-Then criteria, the application design and 8 units of work.
• Construction: functional design, NFR and infrastructure design, code generation, then build and test for each unit.
• Audit trail: a timestamped log of every human decision. I corrected the AI's designs along the way, for example 9 application-design fixes including the emergency cache bypass and consent trade-offs.

I use AI as a fast pair and keep ownership of the requirements, the architecture and the review.

• Backend Python 3.11, FastAPI, SQLAlchemy 2 (async) with asyncpg, Alembic, GeoAlchemy2, Pydantic 2, redis-py, APScheduler, structlog, Argon2
• Data PostgreSQL 15 + PostGIS 3.4; Redis 7.4 (cache, pub/sub, Streams, locks, rate limits)
• Web React 18, TypeScript, Vite 6, Tailwind, React Router, i18next, Leaflet, Recharts
• Mobile Expo SDK 52, React Native 0.76, React Navigation 7, expo-location, AsyncStorage
• Quality pytest, Hypothesis, Ruff (bandit rules), Vitest and fast-check, ESLint, Prettier
• DevOps Docker (multi-stage, non-root), Docker Compose, GitHub Actions, encrypted pg_dump backups, WAL archiving