Equipment Criticality¶

The Equipment Criticality module (roots_hemms_criticality) adds a two-dimensional classification — Value Tier × Risk Tier — to every record of maintenance.equipment. A fixed 3 × 3 matrix derives a Criticality Color (green / yellow / red) which renders as a traffic-light badge in form, list, kanban, and search views.

It is one of the smallest modules in HEMMS by line count but one of the most-consumed: workflow, PM, asset inspection, spare parts, and the HA Annual PM Report all read the criticality fields it adds.

Key features¶

1. Two manual selection fields¶

Every maintenance.equipment gets two required selection fields, both defaulting to medium so a record is never silently mis-classified:

• roots_value_tier — Low Value / Medium Value / High Value (financial / replacement-cost lens).
• roots_risk_tier — Low Risk / Medium Risk / High Risk (clinical-risk lens — what happens to the patient if the equipment fails).

Both fields have tracking=True, so every change posts to the equipment's chatter with the old → new transition.

2. The 3 × 3 criticality matrix¶

roots_criticality_color is a stored, indexed computed field. The mapping is fixed in code and not user-editable:

Risk dominates: anything high-risk and not low-value is red. The matrix is deliberately conservative — it is safer for a hospital to over-classify a defibrillator as critical than to under-classify it.

3. Bilingual badge label¶

A non-stored, context-aware roots_criticality_label Char field renders the bilingual label using the current user's language:

It is not stored (intentionally — storing a translated Char would freeze the value at whatever language the first compute ran in). The badge re-renders in whatever language the user is viewing the record in.

4. Row-level decoration in the list view¶

The equipment list view inherits its decoration attributes so the entire row turns green / yellow / red — not just the badge column. Scanning a ward's equipment list, your eyes are drawn straight to the red rows.

5. Kanban-card badge¶

The equipment kanban view adds a coloured badge to every card. Combined with list-row decoration and the form-view badge, criticality is visible at every zoom level.

6. Search filters and Group-By¶

The search panel adds:

• Critical only — roots_criticality_color = red
• Watch — roots_criticality_color = yellow
• Normal — roots_criticality_color = green
• High Value — roots_value_tier = high
• High Risk — roots_risk_tier = high

And a Group By section for Criticality, Value Tier, and Risk Tier — useful for the equipment census report (see Reporting).

Why criticality matters¶

Criticality is the single dimension that other modules read to make prioritisation decisions:

What criticality does not do directly:

• It does not set the SLA. SLA is per-stage on maintenance.stage.roots_sla_hours, not per-criticality.
• It does not change the PM frequency. Frequency lives on the maintenance.plan.interval field (OCA maintenance_plan).
• It does not route requests differently. Stage routing is the workflow module's job.

Criticality is a signal, not a controller. Other modules choose what to do with the signal.

Architecture¶

Layer 3 — roots_hemms_criticality (this module)
  • adds 2 selection fields + 1 stored computed color + 1 non-stored label
  • inherits 4 views: form / list / kanban / search
  ↓
Layer 2 — maintenance_equipment_tags (OCA)    ← independent tagging vocabulary
  ↓
Layer 1 — maintenance.equipment (Odoo base)

The module defines no new model — it only _inherits maintenance.equipment. Therefore it ships no ACL CSV and inherits record-rule access from the upstream maintenance module.

Module facts¶

Where to next¶

• Get Started — set Value × Risk on your first equipment.
• Configuration — hospital-specific guidance on which device classes typically fall in which tier.
• Workflows — how the four downstream modules consume criticality.
• Reporting — equipment census filtered and grouped by criticality.