Install

One container and a Postgres database. No queue, no cache, no worker fleet. The first run opens a setup wizard that writes the installation’s own data package.

What you need

Docker with the compose plugin, or Python 3.12 and Postgres 14 or newer on the host.
A domain and a reverse proxy for TLS, if the site is to be public. The app itself speaks plain HTTP on one port.
An AI key, only for the features that read paper, interview patients or summarise a record. Everything else runs without one.

Run it

git clone https://github.com/visualpharm/human-rounds
cd human-rounds
docker compose up -d

Open the site and the setup wizard takes over: it asks for the installation’s name, timezone, languages and first centre, and only writes to the database at the last step, so an abandoned setup leaves nothing behind.

What it costs to run

A small virtual machine is enough. The whole application is a single process that handles each request on its own thread, plus Postgres next to it — two vCPUs and 2 GB of memory carry a district-sized public network — one hospital and a handful of health centres — and the load that matters is measured in requests per minute, not per second. There is no Redis, no message broker, no Node service and no separate worker to deploy.

Two operating-system packages are needed beyond Python: poppler-utils, to turn a referral order that arrives as a PDF into an image before the AI reads it, and ffmpeg. Three Python packages, all pinned. Nothing else is compiled.

The only thing on disk that grows is what patients upload — photos and PDFs of referral orders. Put that directory on a volume you actually back up: the database can be restored from a dump, an uploaded order cannot.

What runs in the background

Inside that same process, a handful of small loops do the work nobody triggers: sending the day-before reminders, re-offering a freed slot to the waitlist, retrying appointments the health record refused, preparing record summaries ahead of the clinic, taking off-site backups, and watching whether the AI provider is answering. Each can be switched off with a setting, and each one failing degrades only itself.

Your services and centres are a data package

Everything specific to one town — centres, services, professionals, specialties, preparation instructions, the site’s own texts — lives in a data package layered over a country package and a global one. You only write what differs from the layer below. Upgrading the software does not touch it, and a second installation is a second package rather than a fork.

Upgrading

Pull and redeploy. The database migrates itself on boot, forward only, and refuses to run a migration twice. Your data package, your settings and your uploads are outside the image and survive the redeploy untouched. Take the database dump first anyway.

Modules

Appointments are one module. The pre-consult interview is another. A module can be turned off in an installation that does not want it, and a new one plugs into the same platform core — the core owns the account, the session, the roles and the data package, and a module owns its own routes and screens.

Configuration, and where it lives

Only the database connection has to be an environment variable. Everything the institution changes afterwards — languages, location, keys, the texts, the AI instructions — is edited from the panel and takes effect without a redeploy. Secrets are written, never read back: the panel reports a key as present or missing and nothing else.

Next: Connectors