Patient registration & clinical records
Register and search patients, keep homeopathic case records, record diagnoses (ICD-11), and maintain prescriptions — with annual case rollover and archival.
LAN-first hospital system
Hospital management that runs entirely on your local network.
HHMS is a hospital management system purpose-built for homeopathic hospitals and clinics. A single server executable owns the database; lightweight clients on the hospital LAN connect over HTTP/JSON with automatic discovery — no internet dependency, no cloud lock-in.
Operational dashboard
2025 · demo datasetOPD queue24▲ live
Bed occupancy6/8wards
Outstanding₹1.42L▼ 4%
| Token | Patient | Module | Amount | Status |
|---|---|---|---|---|
| #T-1042 | A. Mehta | OPD | ₹250 | Paid |
| #T-1043 | R. Iyer | OPD | ₹250 | In queue |
| #IPD-118 | S. Kulkarni | IPD | ₹3,400 | Partial |
| #LAB-770 | M. Desai | Laboratory | ₹600 | Pending |
LAN-first
RBAC · 8 roles
UDP 38541 discovery
Proprietary EULA
What it covers
Clinical, operational and reporting modules in one system
Everything below is drawn from the project's own specification and README. Modules are designed to work independently, so a clinic can adopt what it needs.
OPD queue with token system
A token-based outpatient queue drives the day's flow, with a role-based dashboard showing the live OPD queue alongside pending work.
IPD admission & ward/bed management
Admit patients to wards and beds, track occupancy and discharges, and follow a discharge audit — with bed-occupancy dashboards for administrators.
Pharmacy & stock ledger
A pharmacy stock ledger with dispense integrity — receipts minus dispenses reconcile to the live balance — plus procurement and goods receipt.
Billing with live-derived balances
Billing and payments with invoice balances derived live from ledger entries, supporting settled, outstanding and overpaid cases.
Statistics, reporting & printing
A statistics engine plus 16 screen/paper-parity print envelopes — receivables aging, collection summaries, ward occupancy, investigation reconciliation — with PDF generation and batch printing.
How it works
One server owns the data. Clients stay thin.
The server is the only component that opens the shared SQLite database — the client never does. That single-writer model keeps a hospital's data on one machine under the hospital's control.
01
Server executable
HHMS-Server runs FastAPI with a server-owned SQLite database and Alembic migrations. It handles authentication, business services, reporting, file management and audit logging.
02
LAN transport
Clients talk to the server over HTTP/JSON on the hospital LAN. A small native UDP discovery protocol (default port 38541) finds the server, with manual address configuration as a fallback.
03
Thin client UI
HHMS-Client hosts an HTML/CSS/vanilla-JavaScript interface in a WebView2 shell. It renders the workspaces and calls the API — it never touches the database directly.
04
Roles & offline reliability
Role-based access control governs modules and data per role. Normal operation is offline-first with respect to the internet: no cloud service is required, and the client clearly reports a server-unavailable condition rather than silently creating a second database.
The console
A tablet-style console, populated from day one
HHMS is a LAN application, so there is no hosted web demo. Instead, a fresh install seeds a full 2025 demo dataset automatically on first run — patients, OPD tokens, cases, prescriptions, dispenses, lab results, admissions, invoices and payments — so every dashboard, table and print envelope renders meaningful figures immediately.
- Populated dashboards — OPD queue, bed occupancy, outstanding billing and pending investigations all show real figures out of the box.
- Safe by default — the seed runs only when the database is pristine; an install that already holds real data is never touched.
- Opt-out for production — set
HHMS_SEED_DEMO_DATA=falseto skip seeding entirely. - Try it locally — run the server, open the built-in GUI at
http://localhost:8000/and sign in as the bootstrapped administrator.
Dispense integrity
receipts − dispenses = balance| Medicine | Batch | Receipts | Dispensed | Balance | State |
|---|---|---|---|---|---|
| Arnica 30C | B-2041 | 120 | 48 | 72 | Balanced |
| Belladonna 30C | B-2043 | 90 | 90 | 0 | Restock |
| Nux Vomica 200C | B-2046 | 60 | 21 | 39 | Balanced |
| Sulphur 30C | B-2050 | 150 | 33 | 117 | Balanced |
Illustrative layout — figures shown are a representation of the console, not live data.
Interface preview
Registration and records, in one client window
A client window on the hospital LAN: patient registration and search, the day's OPD tokens and the case records a medical officer works from — all served by the single server that owns the database.
Patient list
search: name · token · phoneRegistered today18▲ OPD
Tokens issued24queue
In-patients6wards
| Patient | Age / Sex | Token | Type | Status |
|---|---|---|---|---|
| AMA. Mehta | 42 / F | #T-1042 | OPD | Registered |
| RIR. Iyer | 35 / M | #T-1043 | OPD | In queue |
| SKS. Kulkarni | 61 / M | #IPD-118 | IPD | Admitted |
| MDM. Desai | 28 / F | #T-1044 | OPD | Registered |
Server HHMS-SRV-01 reachable
UDP discovery · 38541
DB: server-owned SQLite
Role: Registration Desk
Interface illustration — HHMS is a hospital management and record system: it stores and organises hospital records, and is not a clinical decision tool.
Get started
From clone to a populated console in a few commands
# 1. clone the repository
git clone https://github.com/drsamonline/HMS.git
cd HMS/backend
# 2. install the server dependencies
pip install -r requirements.txt
# 3. run the server
python -m app.server
# GUI: http://localhost:8000/
# login: admin / admin (change immediately)- STEP 1Clone the repo and move into the
backend/directory. - STEP 2Install dependencies from
requirements.txt. - STEP 3Start the server — it runs migrations automatically and bootstraps a default administrator.
- STEP 4On a brand-new install it also seeds the 2025 demo dataset, so the GUI is populated the moment you open it.
Default credentials are admin / admin — change them immediately.
Disable the bootstrap admin with HHMS_BOOTSTRAP_DEFAULT_ADMIN=false.
Portable folder and EXE builds work out of the box: copy → run → log in. Production setup is covered in the
deployment architecture and
server startup docs.
FAQ
Common questions
Does HHMS need an internet connection?
No. HHMS is offline-first with respect to internet connectivity — normal hospital operation does not require cloud services. Clients do need the HHMS server reachable on the hospital LAN for shared data operations, and the client reports a server-unavailable condition clearly rather than working from a second database.
Where does the data live?
On the server computer, in an application-data location rather than inside source code. SQLite is the primary database for the portable LAN deployment, with Alembic migrations managed by the server. The server is the only component that opens the database — clients never access it directly.
How do clients find the server?
Automatic discovery uses a small native UDP protocol (default port 38541) so no mDNS, Node.js or third-party discovery service is required. Manual server address and port configuration is available as a fallback, and discovery only exposes connection metadata — authentication remains an HTTP/API concern.
How is access controlled?
Through role-based access control. Each user is assigned one or more roles that determine the modules, functions and data they can reach. The documented roles include Administrator, Registration Desk, Medical Officer / Consultant, Pharmacist, Laboratory Staff, Billing Staff, Medical Records Department and Store Keeper. Authentication, sessions and audit logging are covered in the security architecture.
What does it cost to use?
HHMS is proprietary software under its own EULA. Personal use is free of charge; non-profit organisations may use it free of charge only after prior written permission; business/commercial use and large educational institutions require a separate paid licence before installation or use. See the LICENSE file in the repository for the full terms.
How are releases published?
Every push to main publishes a single rolling nightly prerelease, and pushing a version tag (v*.*.*) publishes a permanent stable Release. Builds cover a Linux one-file server bundle and a Windows server EXE plus installer, with SHA-256 checksums attached.