Criticality: Reporting¶

The criticality module does not ship its own PDF. Instead, it surfaces criticality across the existing equipment views, the HA Annual PM Report, and any custom BI tool you point at the Odoo database.

This page covers the patterns that have proven useful at Thai hospitals using HEMMS.

1. The equipment census — list view + Group By¶

This is the day-to-day "criticality dashboard" and it's built into the standard equipment list.

Recipe — count equipment by criticality:

1. Maintenance → Equipment.
2. Search bar → Filters → tick Critical only (or Watch / Normal) to slice.
3. Search bar → Group By → Criticality.
4. Result: collapsible kanban with totals next to each colour.

Recipe — heat-map by department × criticality:

1. Maintenance → Equipment.
2. Group By → Department then Group By → Criticality.
3. Result: each department expands into red / yellow / green sub-groups with counts. Spot a department with disproportionate red and you've found a PM-budget priority.

Recipe — high-value AND high-risk shortlist:

1. Maintenance → Equipment.
2. Filters → High Value AND Filters → High Risk (the search panel AND's filters by default).
3. Result: every red-criticality, high-value item — the BME head's "must-not-fail" list.

2. Row decoration in any equipment list¶

Wherever a maintenance.equipment list is rendered — the global equipment list, the equipment list inside a Service Contract, the equipment list inside an Annual Inspection, the equipment list under a Maintenance Team — the row decoration is on. Red, yellow, green tint follows the equipment through the system.

This is more useful than it sounds. It means:

• A ward nurse opening a request form sees the equipment's criticality on the linked equipment row.
• A vendor visiting the Service Contracts module sees which of the contract's covered equipment items are red.
• A DPO doing the ปจป. inspection sees criticality on every line.

You don't have to navigate to "the criticality screen" — there isn't one. Criticality lives wherever equipment lives.

3. HA Annual PM Report¶

The HA Annual PM Report (roots_hemms_ha_report) renders criticality next to the MoPH risk tier on the per-equipment detail table (Section 3 of the PDF).

It does not roll up criticality into the executive summary block — that block uses the MoPH risk tier, which is the government-recognised classification. Roots-criticality is supporting evidence, not the headline metric.

See HA Report — Reporting for the full PDF anatomy.

4. Asset Inspection report¶

The Annual Inspection PDF (ปจป.) carries a snapshot of criticality per line. The PDF shows the criticality badge for each piece of equipment as it was at the moment the line was created — which is the legally correct view for an audit document.

See Asset Inspection — Reporting for how criticality appears in the inspection PDF.

5. Request analysis (built-in Odoo pivot)¶

Odoo ships Maintenance → Reporting → Maintenance Request Analysis (a graph + pivot view on maintenance.request). Because roots_hemms_workflow adds roots_equipment_criticality_color as a stored related field, you can use it as a pivot or measure dimension:

Recipe — repair backlog by criticality:

1. Maintenance → Reporting → Maintenance Requests.
2. Switch to pivot.
3. Add Equipment Criticality as a row dimension.
4. Add Stage as a column dimension.
5. Filter for open stages (not Received, not Scrap).
6. Result: backlog matrix — see at a glance how many red requests are stuck in each stage.

Recipe — SLA breach by criticality (quarterly):

1. Same view, filter SLA Breached = True.
2. Add Create Date: Quarter as a row dimension.
3. Add Equipment Criticality as a column dimension.
4. Result: per-quarter breach matrix. A quarter where red breaches spike is a triage problem; a quarter where green breaches spike is a backlog problem.

6. Custom BI exports¶

Clean fields to query from any BI tool (Metabase, Superset, Looker, plain Postgres dashboards):

Both colour fields are declared with index=True, so filtering and grouping on them is fast even across millions of rows.

Example SQL — equipment census across all hospitals (multi-company):

SELECT
    rc.name                              AS company,
    me.roots_criticality_color           AS criticality,
    COUNT(*)                             AS equipment_count
FROM   maintenance_equipment me
JOIN   res_company rc ON rc.id = me.company_id
WHERE  me.active = TRUE
GROUP  BY rc.name, me.roots_criticality_color
ORDER  BY rc.name, criticality;

Example SQL — open red-criticality requests aged over their SLA:

SELECT
    mr.id,
    mr.name,
    me.name                              AS equipment,
    ms.name                              AS stage,
    EXTRACT(EPOCH FROM (now() - mr.roots_stage_entered_at)) / 3600
                                         AS hours_in_stage,
    ms.roots_sla_hours                   AS sla_target
FROM   maintenance_request mr
JOIN   maintenance_stage    ms ON ms.id = mr.stage_id
JOIN   maintenance_equipment me ON me.id = mr.equipment_id
WHERE  mr.roots_equipment_criticality_color = 'red'
  AND  ms.done = FALSE
  AND  ms.roots_sla_hours > 0
  AND  EXTRACT(EPOCH FROM (now() - mr.roots_stage_entered_at)) / 3600
       > ms.roots_sla_hours
ORDER  BY hours_in_stage DESC;

7. What this module deliberately does NOT report¶

• No criticality trend over time — the module stores the current colour, not a history. To see "how has our red-equipment count evolved this year?", you'd query mail.tracking.value for changes to roots_value_tier / roots_risk_tier over time. The data is there; the UI to surface it is not.
• No KPI dashboard — there's no "Criticality Cockpit" screen. The combination of Group By + filters in the equipment list is the closest equivalent.
• No PDF dedicated to criticality — criticality appears on the HA Annual PM Report and on the ปจป. inspection PDF, but it doesn't have its own document. That's intentional: criticality is a property of equipment, not an event to be reported.

Caveats¶

Next steps¶

• Configuration — the category-to-tier playbook for bulk classification.
• HA Report — Reporting — how the HA PDF surfaces criticality.
• Asset Inspection — Reporting — how the ปจป. PDF surfaces criticality.
• Workflow module — SLA × criticality combined views via the built-in Maintenance Request Analysis pivot.