Server Requirements¶
Applies to
The current NidanEHR stack: OpenMRS 2.8.x · OpenELIS-Global 2 · Odoo 19 CE · Orthanc · Kafka 7.5 · Keycloak.
NidanEHR is modular. Deployments run only the services needed at the site, allowing hardware footprints to scale accordingly. A facility starting with clinical records needs minimal hardware, while adding laboratory, billing, imaging, and analytics services requires additional compute resources. Size the host machine based on active services, then scale for active user counts.
Sizing Strategy
Size hardware for the active services rather than the entire suite. A records-only deployment fits on a lightweight machine. The full stack represents the maximum resource ceiling, not the deployment starting point.
Step 1 - Choose your capability set¶
Each capability you enable turns on a small group of services and adds a predictable amount of RAM, CPU, and disk. Build up only as far as you need:
| Enable this capability | Services it turns on | Cumulative RAM | Cumulative vCPU |
|---|---|---|---|
| 1. Patient records (EMR) | Gateway, OpenMRS, OpenMRS DB, O3 frontend | ~6–8 GB | 4 |
| 2. + Laboratory | OpenELIS, OpenELIS DB | ~10–12 GB | 6 |
| 3. + Billing & Pharmacy | Odoo, Odoo DB, integration engine (CIS, OIS, Kafka, ZooKeeper, integration DB) | ~20–24 GB | 8 |
| 4. + Imaging (PACS) | Orthanc, Orthanc DB | ~24–26 GB | 10 |
| 5. + Analytics & national reporting | Superset, DHIS2 reporting + DB | ~28–30 GB | 10–12 |
| 6. + Single sign-on | Keycloak | ~30–32 GB | 12 |
The cumulative figures above are for a light patient load at each level - they're the cost of turning the capability on. Step 2 adds for busier sites.
Why billing is the big step up
Going from records/lab (step 2) to billing (step 3) is the one large jump in footprint, and it's not just Odoo. Billing and pharmacy are kept in sync with clinical orders by the integration engine - CIS, OIS, and the Kafka event bus that ties clinical, lab, and commercial data together. That engine is the heart of NidanEHR; enabling billing brings it online. Everything after billing (imaging, analytics, SSO) adds only a little on top.
Deployment profiles:
- Clinic (Records only): Step 1 setup on a minimal host.
- Clinic (Records & Laboratory): Steps 1–2 setup.
- Hospital (Billing, Pharmacy, Clinical): Steps 1–3 setup. This profile introduces the integration engine.
- Full Hospital (PACS, Analytics, SSO): Steps 1–6 setup.
Step 2 - Adjust for patient load¶
The table above assumes a light load. Busier sites add concurrent users, which adds CPU and a little RAM on top of the capability baseline. Estimate peak concurrent users two ways and take the larger:
- From staff: peak concurrent ≈
named users × 0.30. - From footfall: peak concurrent ≈
OPD per day ÷ 10(e.g. 300 OPD ≈ 30 concurrent).
Then add roughly:
- +1 vCPU and +2 GB for every ~20 concurrent OpenMRS clinicians beyond the first 20.
- Odoo scales by workers:
workers = (cores × 2) + 1, ~6 users per worker, ~1 GB RAM per worker. - Reporting (Superset/DHIS2) is spiky - it briefly needs more CPU/RAM during report runs, not all day. Schedule heavy reports off-peak, or run them against a database replica at large sites.
Step 3 - Size storage (only if imaging is enabled)¶
Clinical, lab, and billing databases grow slowly - a patient-year of records is a few MB, and even a quarter-million-patient EMR fits comfortably on a 500 GB SSD with logs and backups.
Imaging is the exception. If you enable PACS (step 4), DICOM dominates disk by one to two orders of magnitude, so size it on its own:
| Modality | Planning size/study |
|---|---|
| X-ray / CR | ~25 MB |
| Ultrasound | ~30 MB |
| CT | ~150 MB |
| MR | ~80 MB |
| Blended (X-ray/USG heavy) | ~40 MB |
Annual imaging storage = studies/day × ~300 days × avg study size, then × your retention years,
× ~2 for a redundant copy. Example: 60 studies/day × 300 × 40 MB × 2 ≈ 1.4 TB/year. Keep imaging
on a dedicated NAS/SAN - not the OS SSD - and per Orthanc's own guidance, on a 1 Gbit (or fibre)
network.
Recommended starting points¶
Pick the row that matches the capabilities you chose in Step 1, then nudge up for heavy patient load.
| Site | Capabilities | vCPU | RAM | Storage |
|---|---|---|---|---|
| Health post / clinic (records, light load) | 1–2 | 4 | 8 GB | 250 GB SSD |
| Small hospital (records + lab + billing) | 1–3 | 8 | 24 GB | 500 GB SSD |
| Full hospital (everything on) | 1–6 | 16 | 48–64 GB | 1 TB SSD + multi-TB imaging NAS |
Very large hospitals
A large site (say 80+ concurrent users, 150+ beds, busy radiology) scales CPU and RAM further and should split the databases and imaging onto their own nodes rather than stacking everything on one host. At that size the hardware spend is expected - it's a big hospital - and the modular approach still applies: you're paying for capabilities and load, nothing wasted.
Operating system, network, and power¶
- OS: a minimal 64-bit server Linux (Ubuntu Server LTS, Debian, or RHEL/Rocky). Don't run a desktop OS on the server.
- Disk: SSD/NVMe for the OS and all databases. Bulk imaging can live on a larger NAS, but the database volumes must be SSD.
- Network: 1 Gbit LAN is the baseline; use fibre to a NAS or between buildings at larger sites. Prefer wired Ethernet over WiFi for clinical workstations.
- Power: a 1000–1500 VA UPS for a single-server site (per OpenELIS guidance); larger sites need rack UPS and a generator path.
- Backups: budget ~1.5–2× the database + config footprint for backups, kept off the server. Imaging is usually protected by NAS redundancy rather than a second full copy.
Sources¶
Figures above are derived from the upstream component requirements (OpenMRS, Bahmni, OpenELIS, Odoo,
Orthanc) and the resource profile in nidan-docker/docker-compose.yml. They are conservative,
single-node planning estimates - validate against a pilot before committing hardware for a large site.