Centrella

An AI-Centric hospital management system.

Comment

Centrella: Smart Hospital Management for Underfunded Public Hospitals

Inspiration

Public and government hospitals across Pakistan — basic health units, rural health centers, small dispensaries — are still running on paper. A blood bank stockout isn't discovered until a patient needs a transfusion and there's none to give. Inventory shortages aren't predicted, they're discovered, usually too late to act. Existing hospital management software exists, but it's built and priced for well-funded private hospitals — a market segment that isn't the one actually struggling.

That gap was the whole starting point: not "how do we build hospital software," but "how do we build hospital software for the hospitals that can't afford hospital software." That constraint shaped almost every technical decision that followed.

What It Does

Centrella is a web-based hospital management platform designed to run on minimal, low-cost hardware — no GPU, no expensive licensing, a single ~$300–400 refurbished PC per facility is enough. It provides:

  • Real-time inventory management with automatic status tracking (Adequate / Low / Critical)
  • AI-based shortage prediction, using historical stock movement to estimate not just that something is low, but when it will run out
  • Blood bank management — live inventory by blood type, donor registry, issuance tracking, and collection logging
  • Role-based access control — a full admin mode alongside a genuinely read-only "visitor" mode, enforced at the backend, not just hidden in the interface
  • Full audit logging, with privacy-conscious handling of sensitive fields like IP address
  • Patient intake, via a reliable manual-entry form and an actively-evolving document-scanning pipeline

How We Built It

The core stack is deliberately unglamorous and cheap to run: React 18 + Vite + Tailwind on the frontend, FastAPI + SQLAlchemy + PostgreSQL on the backend, deployed via Docker on Render, with the database on Supabase and the frontend on Vercel. None of these choices were exotic — the goal was a system that's genuinely affordable to operate, not one that shows off infrastructure for its own sake.

Development was iterative and security-conscious almost by necessity. Early on, a serious gap was found and fixed: write endpoints (create, update, delete) had no real backend protection — the frontend hid buttons from unauthorized users, but the API itself would accept a request from anyone who knew the URL. This was closed with HMAC/SHA256 token-based authentication and admin-gated dependencies on every write route, turning a UI-level illusion of security into an actual enforced one.

The most technically demanding part of the build — and the one with the most genuine engineering story — was patient intake via document scanning.

Challenges We Ran Into

The document-scanning feature went through more iterations than any other part of the project, and each failure taught something specific:

  1. Rule-based OCR first. Tesseract OCR combined with regex-based field matching worked in theory, but broke down immediately against real hospital forms — mixed English and Urdu text on the same page, two-column layouts that scrambled into one jumbled line of text, inconsistent labeling across form templates.

  2. Iterating the rules. Fuzzy label matching, dynamic column detection, zonal/template extraction — each was a real, honest improvement, and each still fell short of reliable accuracy on an actual scanned form photographed under real conditions (uneven lighting, slight rotation, a phone camera instead of a scanner).

  3. A key realization: OCR errors can't be reasoned away. An attempt was made to hand raw OCR output to a small local language model, hoping it could intelligently reconstruct the intended fields. It couldn't — if the text going in was already wrong, no amount of downstream reasoning could recover information that was never accurately captured. In effect,

$$ \text{output quality} \leq \text{input (OCR) quality} $$

no matter how capable the layer built on top of it. That's a small, obvious-sounding lesson that took several real iterations to actually internalize.

  1. The pivot to vision. This led to replacing the OCR step entirely with a local vision-capable AI model (Moondream, run via Ollama) that reads the document image directly — closer to how a person actually reads a form, rather than reconstructing meaning from an imperfect transcript.

  2. Infrastructure met privacy, by necessity. Running any real AI model needs meaningfully more compute than free-tier cloud hosting provides. Rather than defaulting to a paid cloud upgrade, the deliberate choice was to run this processing on the hospital's own on-site device. This solved the compute problem and reinforced the project's core privacy commitment at the same time — sensitive patient documents never leave hospital premises, not as a policy promise, but as an architectural fact.

  3. It's still not fully solved. As of this presentation, document-scanning accuracy is not yet reliable enough to depend on. Rather than hide that, it's treated as the project's most honest open challenge — which is exactly why manual patient entry exists as a fully functional, permanent fallback, not a placeholder waiting to be replaced.

Beyond the scanning journey, real production debugging happened too: a login bug that intermittently and misleadingly showed "invalid credentials" on the first attempt turned out to be a stale database connection colliding with a too-short request timeout — a genuinely subtle, multi-layered bug, not a simple typo.

What We Learned

  • A feature that "mostly works" in a demo is not the same as a feature that works — and the gap between the two is usually where the real engineering lives.
  • Security has to be verified at the layer that actually enforces it. A button that's hidden is not the same as an action that's blocked.
  • Constraints — minimal hardware, no cloud AI, offline-first intake — aren't just limitations to work around. In this project, they consistently pointed toward the right answer, not just a compromise.
  • Honesty about what isn't finished is a technical asset, not a liability, when the fallback for that gap is itself solid.

What's Next

Validating document-scanning accuracy through a real pilot with 1–2 hospitals, training the shortage-prediction model on real usage data, and — longer term — expanding language support, adding fintech features like budget tracking and billing, and pursuing integration with Pakistan's Ministry of Health and NITB.

Built With

Share this project:

Updates

Submission history