Skip to content

Roots Health Vertical

HEMMS isn't a one-off engagement — it's the first publicly released product in Trinity Roots' health vertical, a long-term effort to verticalize Odoo for Thai hospitals across both clinical and back-office domains. This page explains the thesis behind the vertical, why HEMMS went open source, and how to engage with us as a customer or contributor.

Who is Trinity Roots

Trinity Roots Co., Ltd. is a Bangkok-based Odoo implementation partner. We deliver Odoo as the ERP system of record across the breadth of a hospital: HR, finance, procurement, inventory — and the maintenance / asset management layer that is otherwise handled in spreadsheets at most Thai hospitals.

The health vertical at Roots is the team-wide bet that hospitals benefit from running one ERP instead of three or four single-purpose clinical and back-office systems, provided each Odoo module is extended thoughtfully for the regulatory and workflow realities of Thai healthcare. HEMMS is the first such extension we've extracted into a reusable open-source product.

The verticalization thesis

A generic Odoo install gets you a maintenance.equipment model and a 4-stage maintenance.request workflow. That's a fine starting point for a factory. It is not what a Thai hospital needs:

  • No bilingual labels (every form needs to speak Thai and English).
  • No risk-based criticality model (a defibrillator and a desk fan cannot share the same workflow priority).
  • No SLA tracking per stage (BME teams are held to MoPH-defined response times for critical equipment).
  • No annual ปจป. workflow (ตรวจสอบพัสดุประจำปี — every Thai public hospital owes the auditor a register every fiscal year).
  • No HA Thailand annual PM report format (มาตรฐานระบบบริการสุขภาพ ด้านที่ 6 ข้อ 6.1.4).
  • No MoPH-aligned device-risk classification (the 82-device risk-tier table from แนวทางประเมินระดับความเสี่ยงของเครื่องมือแพทย์ฯ (พ.ศ. 2564)).

These gaps are exactly what roots_hemms_* fills. The "Hospital Lens" sits as Layer 3 on top of Odoo base and OCA building blocks — see Architecture for the full three-layer model.

The same verticalization pattern applies to other concerns in a hospital ERP — finance modules need MoPH-aligned chart-of-accounts mapping, HR needs Thai-language employee evaluations, procurement needs supplier classification per public-procurement rules. Each domain will get the same treatment: extract reusable building blocks upstream when we can, layer hospital-specific governance in roots_hemms_* (or a sibling-named vertical) when we can't.

What this page is not

A catalogue of every product Trinity Roots ships. HEMMS is the first open-sourced module suite in the health vertical; other verticals and other modules exist as customer engagements but aren't in this repository. Read Release Notes for what's actually open right now.

Why open source

Three reasons we license under LGPL-3 with OCA modules vendored in:

1. Compliance is auditable when the source is open

HA Thailand surveyors and internal auditors regularly ask for the logic behind a number — "Why is this equipment rated critical?", "How was this SLA computed?". With closed-source code, the answer is a screenshot. With HEMMS, the answer is a permalink to a function on GitHub. Audit defensibility is a feature, not a side effect.

2. Customers aren't locked in

If Trinity Roots ever stops supporting HEMMS, the hospital still owns its data, its database, and the entire source tree. We've watched enough closed-source healthcare-IT vendors disappear with their customers' data hostage that we're unwilling to be one of them.

3. OCA-aligned means upstream-aligned

Every module that could be generic is built on top of OCA (maintenance_plan, maintenance_stock, maintenance_partner, sign_oca, ...) instead of replacing them. When OCA fixes a bug, HEMMS gets the fix for free. When we extract a reusable building block, the fix goes back to OCA when it's not Thai-specific.

The roots_hemms_* Layer-3 modules themselves are LGPL-3 — a hospital can fork and modify them in private without forced disclosure of their internal customizations, but improvements to the modules themselves stay open. This is the same compromise that's worked for psycopg2, pyparsing, and dozens of other developer libraries.

How customers engage

HEMMS itself is free to download and self-host:

git clone https://github.com/jakapolr/hemms-demo
make up-private              # docker-based sandbox
make install-private         # installs every roots_hemms_* module

Beyond that, Trinity Roots offers (in increasing order of involvement):

Implementation services
Sizing, infrastructure setup, data migration from spreadsheets or legacy systems via roots_hemms_mass_import, MoPH device-class mapping, and on-site training for BME and ward staff.
Customization & module development
Bespoke extensions for hospital-specific workflows that don't belong in the public roots_hemms_* codebase — usually published as a new roots_<customer>_* private module. We follow the same 3-layer rule for customer code as for HEMMS core (see Module Development).
Ongoing support
Tiered support packages covering upgrade testing against new Odoo minor releases, security patches, and incident response. The tiers exist so a small private hospital and a multi-branch public network can both find a fit.
Verticalized strategic projects
For customers extending into other domains in the health vertical (clinical, finance, procurement), we run engagements that mirror the HEMMS pattern: extract upstream when possible, layer hospital-specific governance separately.

We deliberately do not publish a price list — hospital implementation scope varies too widely (equipment count, branch count, integration count) for a meaningful fixed-price page. Reach out via the contact form at https://roots.tech for a quote.

Contributing back

If you're not a customer but you'd like to contribute, you're welcome. The CI gate (lint + 177 tests on every PR — see CI/CD) plus the Module Development guide should cover the standards. Open a discussion on the GitHub repo for anything larger than a small fix.

For Thai hospitals interested in becoming a reference customer — sharing anonymized device-class data, validating new MoPH device classes upstream, or piloting unreleased modules — get in touch. The MoPH 82-device seed in roots_hemms_ha_report originated this way and we expect more such collaborations as the vertical grows.