Skip to content

Administration

This section is for the people who run HEMMS rather than use it day-to-day: hospital IT operations, BME department admins, and the Trinity Roots delivery team. It covers the full lifecycle of a HEMMS deployment, from first install through to the next Odoo major upgrade.

If you are looking for the lighter, click-along quick start aimed at evaluators, see Get Started → Installation. The pages in this section assume you are responsible for keeping the system healthy in production.

Who this section is for

Role What they need from here
Hospital IT operations How to deploy, monitor, back up, and restore the Docker stack
BME department admin How to onboard users, set role-based permissions, manage multi-branch hospitals
Trinity Roots delivery engineer Upgrade workflow, migration patterns, CI gate for safe rollouts
HA / DPO compliance reviewer Where the audit trail lives, what's backed up, what's recoverable

What's in this section

  • Installation

    Full Docker-based install: system requirements, repo clone, sandbox startup, module installation, and verification.

  • Multi-Company / Multi-Hospital

    Two patterns for chains and hospital groups — one company per branch in one DB, or one DB per hospital. Which to pick and why.

  • Users & Permissions

    Security groups, record rules, ACLs, and a recommended role mapping for the typical hospital structure (Ward Nurse → BME Tech → BME Manager → Admin / DPO).

  • Backup & Restore

    What make backup-private actually does, how to restore both the database and the filestore, and how often to run the drill.

  • Upgrade Guide

    Module upgrades, the version field in __manifest__.py, migration files, and how CI catches regressions on every PR.

Architectural context

HEMMS is a three-layer stack — Odoo Base, OCA building blocks, and the roots_hemms_* hospital lens. If you have not read the Architecture page yet, do that first; almost every decision in this section (which modules to install, what the security groups are, what gets backed up) follows from that layering.

The deployment surface is intentionally narrow: two Docker Compose stacks (private and gov) wrap an Odoo 18 container and a Postgres 15 container, with all customisation living in the addons/ directory and all sandboxes sharing the same hemms-odoo:18.0 image. There is nothing else to install on the host beyond Docker.

Operating principles

The administration workflow follows three rules that the rest of the section expands on:

  1. Backup before every change. Module installs, upgrades, restores, even merging a large PR — start with make backup-private. Backups are cheap; restoring from yesterday's nightly because you skipped the pre-upgrade backup is not.
  2. Use the Makefile. Every documented operation has a make target. If you find yourself reaching for raw docker compose or odoo commands, check the Makefile first — there is probably a target for it.
  3. Trust the CI gate. The tests.yml workflow runs 177 HEMMS tests on every PR. If main is green, the addons install cleanly on a fresh DB. See Developer → CI/CD.