Criticality: Workflows¶

The roots_hemms_criticality module by itself does very little — it adds four fields and a 3 × 3 matrix. The interesting part is what other modules do with the criticality signal.

This page is a tour of every downstream consumer. If you're trying to understand "what does setting an equipment to red actually change in the system?", you're on the right page.

The signal flow¶

flowchart LR
    A[Engineer sets<br/>Value × Risk<br/>on equipment] --> B[roots_criticality_color<br/>recomputes]
    B --> C1[Workflow: red dot<br/>on request kanban card]
    B --> C2[Spare parts: auto-flag<br/>critical spares on red eq.]
    B --> C3[Asset inspection:<br/>snapshot to line]
    B --> C4[HA report:<br/>surface on PDF]
    B --> C5[List/kanban/form badge<br/>+ search filters]

Criticality is a signal, not a controller. Each consumer decides on its own what to do with the colour.

Consumer 1 — Repair workflow¶

Module: roots_hemms_workflow

What it reads: maintenance.equipment.roots_criticality_color, via a stored related field on maintenance.request:

roots_equipment_criticality_color = fields.Selection(
    related="equipment_id.roots_criticality_color",
    string="Equipment Criticality",
    store=True,
    index=True,
)

What it does:

• The request kanban card carries a coloured dot matching the equipment's criticality. Technicians scanning the queue see the red dots first.
• The field is store=True, index=True so analytics queries ("how many red-criticality requests breached SLA last quarter?") run fast.
• The relationship is related, so flipping an equipment's tier automatically updates every open request on that equipment. You do not need to re-save the request.

What criticality does NOT do in the workflow:

• It does not change the SLA hours. SLA is a per-stage value (maintenance.stage.roots_sla_hours), not a per-criticality value.
• It does not change the routing. All requests use the same 5-stage workflow regardless of criticality.
• It does not auto-escalate stale red requests. SLA breach is the trigger, not criticality.

If you want criticality to drive routing or SLA, that's a hospital-policy extension — typically a per-team workflow rule layered on top.

Consumer 2 — Spare parts¶

Module: roots_hemms_spare_parts

What it reads: roots_criticality_color == 'red' on the equipment that owns the spare line.

What it does:

• Every hemms.equipment.spare.line has a computed roots_is_critical_spare field. The compute fires the flag if either:
  • the line is manually flagged critical, OR
  • the parent equipment's roots_criticality_color is red.
• Critical spares get badge treatment in the spare-line list and feed the "critical spares low-stock" alerts.

Why it's set up this way: if you classify a defibrillator as red, you implicitly want every spare on it (battery, paddle, cable) treated as critical without re-flagging each line. The spare module enforces that.

Consumer 3 — Annual asset inspection (ปจป.)¶

Module: roots_hemms_asset_inspection

What it reads: equipment.roots_criticality_color at the moment a piece of equipment is added to the inspection.

What it does:

• The inspection line has its own criticality_color field which is copied (not related) from the equipment on insert. This is a deliberate snapshot.
• The inspection line list view decorates each row with the snapshotted criticality (badge widget, success/warning/danger decoration).
• If the equipment's criticality changes after the inspection is created (or after it's submitted and locked), the inspection line still shows the value at inspection time — preserving audit truth.

Why snapshot, not related: the ปจป. report is a legal document signed by a three-person committee. The line items have to reflect what was true at the time of inspection, not what's true today. If you reclassify an MRI from Yellow to Red next year, last year's submitted inspection still says Yellow — that's correct.

Consumer 4 — HA Annual PM Report¶

Module: roots_hemms_ha_report

What it reads: declared as a manifest dependency. The HA report generation wizard and PDF template read the equipment's criticality colour alongside the MoPH risk tier.

What it does:

• The HA report has its own risk tier — roots_ha_risk_tier — sourced from the MoPH 82-device guideline document (see HA Report — Get Started). That's a parallel, government-mandated classification.
• The Roots criticality colour appears next to the MoPH tier on the PDF, giving surveyors two perspectives: the hospital's internal judgement (Value × Risk) and the MoPH standard (สูง / กลาง / ต่ำ).
• When the two diverge (e.g., equipment is Roots-red but MoPH-medium), the hospital can explain its more conservative position in the report narrative.

Consumer 5 — Equipment views (the module itself)¶

Module: roots_hemms_criticality

The module also inherits its own consumer-facing views:

See Reporting for the search and group-by patterns.

Mass-import and criticality¶

The mass-import module (roots_hemms_mass_import) does not currently include roots_value_tier or roots_risk_tier in its Equipment import template. Imported equipment lands at the model defaults (Medium × Medium → 🟡 Yellow), and criticality must be set after import.

If you want criticality bulk-set during import, two paths:

• Post-import bulk-edit — use the list-view multi-select + Update fields workflow described in Get Started — Step 7.
• Direct Odoo import — Maintenance → Equipment → ⋮ → Import records accepts the field IDs roots_value_tier and roots_risk_tier in a CSV upload. This bypasses the mass-import wizard but works.

Audit trail¶

The tracked fields are roots_value_tier and roots_risk_tier. Every change is posted to the equipment's chatter with:

• who made the change (uid)
• when (date)
• old value → new value

roots_criticality_color is not tracked directly because it's computed — but a change to either tier always produces a chatter entry that lets you infer the colour change.

There is no separate criticality-change audit table. If you need analytics on criticality drift over time, you'd query mail.tracking.value filtered on the relevant ir.model.fields rows.

Cross-module summary¶

What criticality is NOT plumbed into (yet)¶

If you go looking for these and don't find them, you haven't missed anything — they're genuinely not wired:

• PM frequency by criticality — PM frequency is per maintenance.plan.interval. There is no rule "red equipment must be PM'd every 3 months".
• SLA hours by criticality — SLA is per-stage. There is no rule "red equipment must be repaired in 8 hours".
• Approval routing by criticality — corrective requests route the same way regardless of colour.
• Procurement priority by criticality — out of scope for HEMMS.

These are reasonable extensions, just not currently implemented.

Next steps¶

• Reporting — equipment census slices and BI export ideas.
• Configuration — category-to-tier examples and the bulk-migration playbook.
• Workflow module — how the SLA-breach + red-dot combination feeds the BME daily standup.