-->
Complete clinical software that runs on a laptop in a tent, syncs over local Wi-Fi,
and never phones home to anyone's cloud.
Website · What it does · How it works · Repositories · Get started · Brand kit
ZarishHealth is a complete, multi-platform, vendor-independent Health Information System built for low-resource environments, non-profit field operations, and clinical facilities.
It runs entirely offline on local devices and synchronises across a local Wi-Fi network — no external cloud, no proprietary vendor, no per-seat licence, no internet dependency. When connectivity exists, it uses it. When it doesn't, nothing stops.
|
Not "offline-tolerant." The local device is the source of truth. Connectivity is an optimisation, never a requirement. |
Runs on hardware you already own — a clinic laptop, a mini-PC, a field server. Your data never leaves the premises unless you send it. |
Open formats, open standards, open source. No lock-in, no licence renewal that can strand a clinic mid-season. |
|
Devices discover each other on local Wi-Fi and reconcile automatically. No central server required for a site to function. |
Desktop, mobile and browser from one codebase, so the same records follow the clinician between the ward and the field. |
Designed for constrained hardware, intermittent power and low bandwidth — the actual conditions of the places that need it most. |
graph TB
subgraph SITE["🏥 Clinic site — no internet required"]
direction LR
A["💻 Reception<br/><i>registration</i>"]
B["📱 Clinician tablet<br/><i>consultation</i>"]
C["🔬 Lab / pharmacy<br/><i>results, stock</i>"]
D[("🗄️ Local store<br/><i>source of truth</i>")]
A <--> D
B <--> D
C <--> D
end
SITE -.->|"📡 opportunistic sync<br/>when a link exists"| HQ["🌐 HQ / ministry<br/><i>optional, never required</i>"]
classDef site fill:#017CF5,stroke:#014A93,stroke-width:2px,color:#fff
classDef store fill:#10B981,stroke:#059669,stroke-width:2px,color:#02091C
classDef hq fill:#02091C,stroke:#1E3A63,stroke-width:2px,color:#fff
class A,B,C site
class D store
class HQ hq
The rule that drives every design decision: a site must remain fully operational with its uplink cut. Sync is something that happens to a working system, never something it waits for.
🏕️ Who this is built for — click to expand
| Setting | The problem ZarishHealth solves |
|---|---|
| Humanitarian field operations | Cloud EMRs are unusable where there is no reliable uplink. Paper doesn't aggregate. |
| Rural & district clinics | Commercial HIS licensing costs more than the clinic's annual equipment budget. |
| Mobile & outreach teams | Records collected in a village must merge cleanly with the base clinic on return. |
| Refugee & displacement response | Deployments must stand up in days on borrowed hardware, not months on procurement. |
| Ministries & NGO networks | Many autonomous sites, occasional aggregation, no dependence on a single vendor. |
⚙️ Engineering principles — click to expand
- Local-first data. The device holds a complete, usable record. Sync reconciles; it does not gatekeep.
- Deterministic merges. Two sites editing the same record offline must converge without a human arbitrating every conflict.
- Constrained-hardware budget. Performance targets are set on modest field hardware, not developer laptops.
- Open standards at the boundary. Interoperable export so data outlives any one tool — including this one.
- Boring, auditable dependencies. Field software that cannot be patched for six months must be conservative by construction.
- Privacy by architecture. Data that never leaves the building cannot be breached from outside it.
🔐 A note on clinical & regulatory claims — click to expand
ZarishHealth is health infrastructure. Regulatory posture — HIPAA, GDPR, national health-data law, medical-device classification — depends on how you deploy, configure and operate it, and on your jurisdiction.
The project provides the technical building blocks for a compliant deployment. It does not, and cannot, confer compliance by itself. Deployments handling real patient data should be reviewed by someone qualified in the relevant jurisdiction before going live.
| Repository | What it is | Status |
|---|---|---|
zarishhealth.github.io |
Project website & documentation |  |
.github |
Org profile, brand kit, shared community health files | |
| core | Clinical data model & sync engine |  |
| app | Desktop, mobile & web client | |
| deploy | Field deployment scripts & images | |
|
Start with the docs — architecture, deployment models and the offline-sync design. |
Browse the repositories, open an issue, or pick up something labelled |
|
Deployment questions, field reports and design debate belong in Discussions. |
Running ZarishHealth at a site? Tell us what broke. Field reports are the most valuable contribution there is. |
Contributions are welcome from clinicians, field logisticians, translators, designers and engineers alike — this project needs all five.
Especially valuable:
- Field reports. What failed at 2am in a clinic with 6% battery? That's the bug report nobody else can write.
- Localisation. Health software in the wrong language is health software nobody uses.
- Low-resource testing. Old hardware, flaky power, hostile networks — if you have them, you have a test lab.
- Clinical review. Workflows that are technically elegant and clinically wrong are worse than useless.
The complete identity system lives in profile/assets/ — logos, icons, favicons, app icons, avatars, social cards, banners, badges, design tokens and backgrounds, all generated from one vector master.
| Document | Purpose |
|---|---|
| BRANDING.md | Full guidelines — clear space, colour, typography, per-platform sizes, accessibility |
| SKILL.md | Machine-readable brand spec, so an AI assistant applies the identity correctly |
| ASSETS-INDEX.md | Every file, with sizes |
| brand-tokens.json · brand.css | Design tokens for code |
Use these badges in your own README
<img src="https://raw.githubusercontent.com/zarishhealth/.github/main/profile/assets/logo/zarishhealth-logo-horizontal-dark.svg" alt="ZarishHealth" width="420">Colours: Zarish Blue #017CF5 · Vital Green #10B981 · Deep Navy #02091C
Source code and brand assets are released under the MIT Licence.
The ZarishHealth name and mark identify the project. Use them to refer to ZarishHealth — "built with ZarishHealth", "a ZarishHealth deployment". Please don't use them to brand a fork or imply an endorsement that doesn't exist.
Health software shouldn't require the internet to save a life.
Built for the places the cloud forgot.