Configuration¶
This page covers the one-time setup tasks: classifying equipment so they appear on the PM register, customising the MoPH device-class table for local additions, and setting up signers / permissions.
The risk-tier waterfall¶
Every maintenance.equipment must have an effective risk tier (roots_ha_risk_tier) and effective PM frequency (roots_ha_pm_freq_months) to appear on a HA Annual PM Report. The system computes both from a three-step waterfall — the first step that resolves wins, and the chosen step is recorded in roots_ha_risk_tier_source as evidence.
1. roots_ha_risk_tier_override → use it
2. device_class_id linked → inherit from MoPH class
3. EM score → compute from 4 sliders
Equipment with none of the three set is dropped from the PM register (roots_ha_risk_tier_source = 'none') and excluded from generated reports.
Step 1: Explicit override¶
On any maintenance.equipment form, open the Risk Assessment (HA) tab. The right column has:
- Risk Tier Override — Selection: ต่ำ / กลาง / สูง.
- PM Frequency Override (months) — Integer, leave at 0 to inherit.
Use this when:
- The engineer disagrees with the MoPH classification for this specific piece of equipment (e.g. it's been modified, runs on a different duty cycle, is in a critical-care location).
- The EM-score doesn't capture the local risk factor.
Overrides are auditable — roots_ha_risk_tier_source reads Explicit Override in the report appendix.
Step 2: MoPH Device Class lookup¶
Recommended path for the 82 catalogued device types. On the Risk Assessment (HA) tab, set MoPH Device Class to the matching class from the seed. The tier and frequency populate automatically (read- only on the equipment form; edit the class itself to change them hospital-wide).
This is the happy path — surveyors recognise the MoPH table directly, and the report appendix A reproduces the table verbatim as evidence.
Step 3: EM-score worksheet¶
For equipment NOT in the MoPH 82-device table, fill the four sliders under WHO Fennigkoh-Smith EM Score:
| Slider | Range | What it measures |
|---|---|---|
| Function | 2–10 | Type of equipment (life-supporting = 10, computer-related = 3) |
| Application | 1–5 | Worst-case physical harm if the device fails |
| Maintenance | 1–5 | Manufacturer's recommended maintenance burden |
| History | −2 .. +2 | This hospital's repair-frequency adjustment |
The system computes roots_em_score = Function + Application + Maintenance + History and maps it to a tier:
| Score | Tier | Frequency |
|---|---|---|
| ≤ 12 | (none) | Dropped from PM register |
| 13–14 | ต่ำ (Low) | 12 months (1× / year) |
| 15–18 | กลาง (Medium) | 6 months (2× / year) |
| ≥ 19 | สูง (High) | 4 months (3× / year) |
History range note. History is intentionally allowed to be negative (a device with excellent repair history can drop out of the PM register). The compute does not clamp to non-negative.
Editing the MoPH device-class table¶
Open Maintenance → Configuration → MoPH Device Classes (HA).
The list shows the 82 seeded device types with colour-coded tier (red = สูง / yellow = กลาง / blue = ต่ำ). Filters and group-bys let you explore by tier or frequency.
Adding local entries¶
Click New to add a hospital-specific device type. Fill:
name_en— English name (used as the natural key; must be unique).name_th— Thai name.risk_tier— สูง / กลาง / ต่ำ.pm_freq_months— frequency in months.pm_duration_hours— recommended PM duration.pm_duration_note— optional qualifier (e.g. "+0.1 per module" for multi-module monitors).
The new entry is immediately available in the Device Class dropdown on the equipment form.
Editing existing entries¶
Edit any seeded entry's pm_freq_months if local policy diverges from the MoPH default. Edits are preserved across module upgrades because the seed data is noupdate="1" — only NEW rows added by upstream upgrades will appear; your edits stay.
Snapshot immutability. Editing a class does not retroactively change submitted HA reports — they render from a snapshot taken at submit time. New reports submitted after the edit will reflect the new value.
Signer setup¶
Each report references three signers via bme_head_id, engineering_head_id, director_id (res.users). Each must have a linked res.partner for the sign_oca bridge to resolve them.
Best practice¶
- Create a dedicated
res.usersfor each role even if a single person holds it. This makes the audit trail readable (Signed by Dr. Smith as Hospital Director) rather than tied to a generic login. - Make sure each user has a meaningful
res.partnername + email so the portal signing email is professional.
Pre-flight check¶
Before the 📝 Send for Signature button accepts, the system runs _check_ha_signers_resolvable(). If any of the three slots is empty or partner-less, you'll get an actionable error message naming the slot that needs fixing.
Department-scoped permissions¶
The module ships record rules (Q5.10) that scope non-manager users to their own department:
- BME staff in dept A — can read/write/submit reports for dept A only.
- Equipment managers (
maintenance.group_equipment_manager) — full access to all departments. - Authors — can always see their own reports across depts (useful when a manager wears a BME-staff hat from time to time).
To grant cross-dept read for a Quality / HA-prep team without giving them write access, add them to base.group_user only and they'll see their own dept's reports plus any they authored — for broader access, make them equipment managers or build a custom group.
Fiscal-year cadence¶
Reports use Thai ปีงบประมาณ (Buddhist Era), running 1 Oct → 30 Sep. The selection widget offers a 21-year window (current ± 10) so historical edits stay possible without invalidating stored values.
The current fiscal year is automatically selected on new wizard launches. Override only when generating a historical report.