Roadmap¶
HEMMS evolves through small, themed quarters — each one a self-contained bundle of modules that ships behind CI gates and lands as a single release. The first seven quarters are now in main; this page records what's done, what's queued, and what we're deliberately not committing to yet.
Shipped (Q1 → Q7)¶
| Quarter | Theme | Module(s) | Status |
|---|---|---|---|
| Q1 | Foundations | roots_hemms_workflow, roots_hemms_criticality, roots_hemms_asset_master, roots_hemms_asset_inspection, roots_hemms_pm | ✅ Shipped 2026-05-12 → 2026-05-19 |
| Q2 | Spare parts | roots_hemms_spare_parts + vendored maintenance_stock | ✅ Shipped 2026-05-22 |
| Q3 | Service contracts | roots_hemms_service_contracts | ✅ Shipped 2026-05-22 |
| Q4 | e-Signature | roots_hemms_signature + vendored sign_oca | ✅ Shipped 2026-05-22 |
| Q5 | HA Thailand report | roots_hemms_ha_report | ✅ Shipped 2026-05-22 |
| Q6 | Mass import | roots_hemms_mass_import | ✅ Shipped 2026-05-22 |
| Q7 | CI/CD | GitHub Actions workflows, Makefile parity | ✅ Shipped 2026-05-23 (PR #5) |
| — | Nav polish | Menu consolidation + reorder | ✅ Shipped 2026-05-23 (PR #7) |
See Release Notes for the per-commit list and Architecture for how the modules compose.
Test coverage
All seven quarters ship with tests. 177 HEMMS tests run on every push and pull request: 38 ha_report + 38 mass_import + 15 pm + 28 service_contracts + 27 signature + 31 spare_parts.
Up next¶
These are themes we're actively scoping. They are not committed dates — each theme will get its own Q-plan document under docs/developer/ before any code lands. Names of the actual modules may change.
Asset depreciation / IAS 16¶
Bridge maintenance.equipment to Odoo's account.asset. Hospitals inventoried under IAS 16 need acquisition cost, useful life, residual value, accumulated depreciation, and a yearly schedule on every equipment record. The existing Ref. No. (รหัสครุภัณฑ์) and asset master from Q1 are the right hook points. See IAS 16 compliance for the regulatory backdrop.
Mobile-first nurse interface¶
A stripped-down request-submission flow optimized for a phone or tablet at the bedside. Today's nurse view inherits the full maintenance.request form; we want a 3-tap "report broken equipment" flow that pre-fills location, equipment, and reporter from the logged-in employee.
Executive dashboards¶
AUM-style dashboards for the hospital director: SLA compliance %, critical-spare stock-out count, contract-renewal pipeline, HA report completion by department. The data is already there (the SLA-breached search, the spare-line low-stock cron, the contract state cron, the HA report aggregates) — what's missing is the board.board / OWL composition layer.
JCI-formatted PM report¶
A sibling to Q5's HA Thailand report, formatted for JCI surveyors instead of HA. Same data source (hemms.ha.report.line plus the MoPH device class), different QWeb template, English-only, no Thai signature pages. Re-use the Q5 snapshot-on-submit pattern so reprints stay byte-identical.
Calibration certificates¶
A new lightweight model hemms.calibration.cert linking to maintenance.equipment and maintenance.request, with PDF upload, expiry date, calibration body (e.g., NIMT, NIST), and a daily cron firing renewal activities. Likely a Q4-style bridge to sign_oca for vendor-attested certificates.
Spare-parts forecasting¶
Q2 ships consumption-on-PM and a critical-low-stock cron. The next step is reorder points and demand forecasting based on the historical picking data — a small stock.warehouse.orderpoint extension keyed by equipment criticality, not just product turnover.
Deliberately deferred¶
Things we've considered and explicitly not prioritized for the next ring of work:
- Multi-currency vendor billing. The contract model assumes a single hospital company / currency. Multi-currency is solvable but not on the critical path for Thai public hospitals.
- EAM-grade depth-of-asset hierarchy. Equipment trees beyond two levels (Brand → Model) — we'll revisit only if a customer needs it.
- Mobile offline mode. Native offline sync is hard; we'll start with online-only mobile and revisit if a customer asks.
Community contributions¶
Pull requests welcome. We use the OCA coding standard (ruff + pylint_odoo + oca-checks-odoo-module — see CI/CD) and the official Odoo coding standard as our two pre-commit gates. Read these first:
- Architecture — 3-layer model and field-naming convention.
- Module Development — how to scaffold and wire a new
roots_hemms_*module. - Contributing — docs / commit / PR workflow.
The Q2 → Q6 design plans (docs/developer/q*-*-plan.md) are good worked examples of how we scope, decide, and ship a quarter.
How to track progress¶
| Channel | What you get |
|---|---|
| GitHub Releases | Tag per release, summary changelog |
| Release Notes | This site, indexed and searchable |
| GitHub PRs | What's actively being built |
docs/developer/q*-*-plan.md | Per-quarter design plan — read before commenting on a PR |
Naming convention for Q-plans
Every quarter ships with a qN-<theme>-plan.md under docs/developer/. The plan is written before the first commit, revised during the quarter, and frozen as FINAL 1.0 when the last commit lands. Browse q2-spare-parts-plan.md through q6-mass-import-plan.md for the format.