Skip to content

Multi-company / Multi-hospital Setup

HEMMS inherits Odoo's multi-company features, so you have two clean ways to serve a hospital group:

  1. One company per hospital, one shared database — Odoo's multi-company mode, with record rules segmenting equipment by company_id.
  2. One database per hospital — independent deployments, one Compose stack each.

The right choice depends on whether the hospitals share staff, master data, and reporting boundaries, or operate independently. This page lays out the trade-offs and the practical setup steps for option 1.

Which pattern fits which customer

Pattern Best fit Trade-off
One company per hospital, one DB A chain or hospital group with shared BME staff, shared vendors, central IT, and a need to roll up KPIs across branches Cross-company queries are easy. Per-hospital backup/restore is harder — you back up everyone at once.
One DB per hospital Independent hospitals under a holding company; HA Thailand reporting is per-hospital; data sovereignty / DPO concerns Clean isolation. No cross-hospital reporting in Odoo (do it externally). Multiple stacks to upgrade.

When in doubt, pick one DB per hospital

The HA Thailand annual PM report (Q5) is filed per hospital, not per company, and HEMMS's company-scoping coverage is partial (see the audit below). If reporting boundaries and data isolation matter more than cross-branch dashboards, one DB per hospital is the safer default. Each hospital gets its own Compose stack on its own port.

Pattern 1 — One company per hospital, one DB

This is the standard Odoo multi-company pattern.

Set up the companies

  1. Log in as admin.
  2. Activate developer mode (Settings → Developer Tools → Activate the developer mode).
  3. Go to Settings → Users & Companies → Companies.
  4. Edit the default company (rename it to your parent group, e.g. "ABC Hospital Group").
  5. Create one child company per hospital. Set:
    • Name — e.g. "ABC Hospital — Bangkok Branch"
    • Parent Company — the group company you just renamed
    • Currency, Timezone, Address, VAT — per branch
    • Logo — branch logo if applicable

Assign users to companies

For each user (Settings → Users & Companies → Users):

  1. Open the user record.
  2. Set Allowed Companies to the branches they're allowed to access.
  3. Set Default Company to the branch they should land in after login.
  4. The user can switch branches at any time via the company selector in the top-right of the UI.

BME staff usually belong to one branch

Ward nurses and BME technicians should be assigned to one company only. Group-level roles (CIO, group BME manager, DPO) get all branches and rely on the company selector.

How record scoping actually works in HEMMS

This is the honest audit of which HEMMS records are company-scoped today and which are not. Verified against addons/roots/ source.

Record type Has company_id? Behaviour with multi-company
hemms.service.contract (Q3) ✅ Yes Each contract belongs to one hospital company. Visible only when that company is active in the selector.
maintenance.equipment (Odoo base) ✅ Yes Equipment is company-scoped natively. Each device belongs to one hospital.
maintenance.request (Odoo base) ✅ Yes Inherits scoping from equipment_id.
hemms.import.batch (Q6 Mass Import) ❌ No company_id Currently scoped per-uploader via record rule, not per company. A user with access to both branches sees both branches' import batches.
hemms.ha.report (Q5 HA Report) ❌ No company_id Scoped per-department via record rule. A department spanning multiple hospitals would mix data — but HA reporting is per-hospital, so this is usually fine.
hemms.asset.inspection (annual ปจป.) ❌ No company_id Scoped per-department, not per-company.
hemms.contract.type (Q3) Master data, no scoping Shared across all companies — same maintenance categories everywhere.
roots_hemms_pm PM kinds Master data, no scoping Shared across all companies.

Partial company scoping — design implication

HEMMS today is company-aware for the things that matter operationally (equipment, requests, service contracts) but not company-scoped for HA-compliance artefacts (annual reports, import batches, inspections). That works if every department in your DB belongs to a single hospital. It breaks if departments are shared across hospitals — which is uncommon, but worth confirming with the customer before going multi- company on one DB.

Master data: what gets shared

In one-DB multi-company mode, the following are shared across all hospitals by design:

  • PM kinds (maintenance.kind) — same calibration / PM / electrical safety categories everywhere
  • Contract types (hemms.contract.type) — same FSC / PSC / TM categories
  • Criticality matrix configuration
  • HA report templates
  • User accounts, security groups, record rules

If a child hospital needs a divergent PM catalogue, that is a signal to split it out into its own database.

Pattern 2 — One database per hospital

Run a separate Compose stack per hospital. The repo already ships two profiles (private and gov) which is the template for this pattern.

Mechanics

# Hospital A on port 8069
make up-private          # → http://hospital-a:8069
make install-private

# Hospital B — copy docker-compose.private.yml to docker-compose.b.yml,
# change container names + ports + volume names + DB name, then:
docker compose -f docker-compose.b.yml up -d

The Dockerfile and addons are shared (one image, two containers), but the volumes (odoo_*_data, db_*_data) are stack-scoped, so the data is fully isolated.

Backup considerations

The backup script takes a <private|gov> argument; copy and adapt it for additional stacks. See Backup & Restore.

Upgrades

Each stack upgrades independently. Schedule a rolling upgrade window — upgrade Hospital A, verify, then Hospital B. See Upgrade Guide.

Recommendation

For Thai hospital deployments — where HA reporting is per-hospital and data sovereignty / DPO obligations are per-hospital — one DB per hospital is the cleaner default. Use one-DB multi-company only when:

  • The customer is a single legal entity with branches
  • BME staff genuinely work across branches
  • Group-level KPI rollup is a real business need
  • The customer accepts the partial company-scoping caveat above

When that bar is not met, two Compose stacks on two ports is simpler, safer, and easier to back up, restore, and upgrade.