Criticality: Configuration¶

This page is for administrators rolling criticality out across a real hospital. The end-user walkthrough is in Get Started; this page covers the parts an admin needs once they're past the first record.

What is — and is not — configurable¶

The criticality module is deliberately small. Two parts are configurable (by editing equipment data), one part is hard-coded:

The seed: every equipment defaults to Medium × Medium¶

Both fields are declared required=True, default="medium". The implication:

• Newly created equipment — whether via the form, mass-import, or another module's create() — lands at Medium Value × Medium Risk → 🟡 Watch.
• There is no "unassigned" or null state. You can't lose track of which equipment hasn't been classified yet, because none of them are null.
• The compromise: a freshly imported register has every row yellow until an engineer goes through and adjusts. That's intentional — yellow is visually obvious and forces attention.

The label field is translatable¶

The badge label roots_criticality_label is a non-stored Char computed against @api.depends_context("lang"). To customise the label in any language:

1. Edit addons/roots/roots_hemms_criticality/i18n/th.po (or add a new <lang>.po file).

2. Override the three msgstrs:

   msgid "ปกติ (Normal)"
   msgstr "..."
   
   msgid "เฝ้าระวัง (Watch)"
   msgstr "..."
   
   msgid "วิกฤต (Critical)"
   msgstr "..."
   

3. Update the module: make install-private (or, in production, run the module upgrade with the -l <lang> flag).

The label re-renders the moment the user's language preference changes — no record-level recompute needed.

Hospital category-to-tier examples¶

A starting taxonomy you can adopt or argue with. These are conventions observed at Thai public hospitals using HEMMS; treat them as defaults to tune per institution.

High Value × High Risk (🔴 Red)¶

The classic "you must not miss a PM on these":

• Anesthesia machine
• Ventilator (ICU, OR, transport)
• Heart-lung bypass
• Defibrillator (only Medium Value but high enough on its own — see below)
• Dialysis machine
• Linear accelerator
• Neonatal incubator with monitoring
• MRI, CT, fluoroscopy, angiography

Medium Value × High Risk (🔴 Red)¶

Cheap-to-replace but life-critical — risk dominates:

• Defibrillator (price varies; risk is non-negotiable)
• Pulse oximeter on a critical patient
• Suction unit on an OR table
• Infusion pump running a vasopressor

High Value × Medium Risk (🔴 Red)¶

Expensive imaging used for planned exams — failure delays but rarely kills:

• Ultrasound (high-end)
• Mammography
• Bone densitometer (DEXA)
• Endoscopy tower

High Value × Low Risk (🟡 Yellow)¶

Expensive support equipment:

• HVAC chiller serving non-clinical floors
• Backup generator (depends — if it's the OR's sole backup, escalate Risk)
• Sterile processing autoclave (queue-able; backup paths exist)

Medium Value × Medium Risk (🟡 Yellow)¶

The default "moderately important" bucket:

• Standard infusion pump
• Vital signs monitor in a general ward
• ECG machine
• Suction unit in a treatment room
• Patient warmer

Medium Value × Low Risk (🟢 Green)¶

Workshop tools, office equipment:

• Calibration test equipment in BME workshop
• Workshop drill press
• Patient transport wheelchair

Low Value × Low Risk (🟢 Green)¶

Disposable-adjacent:

• Stethoscope
• Sphygmomanometer (manual)
• Tape measure, basic exam light
• Office printer

Special cases that fight the matrix¶

• OR table with no backup — Medium Value but Risk is High because OR schedule depends on it. Push to Red.
• HVAC serving OR — High Value, High Risk if OR is sole-source. Otherwise Medium Risk.
• Pediatric / NICU equipment — bump Risk one tier higher than the same device on an adult ward, given clinical fragility.
• Sterile processing line — assess as a system, not per autoclave. Loss of any one node is Medium Risk if backups exist, High Risk if not.

These are guidelines. Document your hospital's rules in a one-pager and attach it to the BME SOP.

Layering with OCA maintenance_equipment_tags¶

The module declares maintenance_equipment_tags (OCA) as a dependency so a hospital can layer free-form tags alongside the structured tiers. Tiers answer "how important?"; tags answer "what kind / context / programme?".

Common tag patterns:

• Location: Ward 6A, OR Suite 2, ICU, ER, Sterile-Processing.
• Programme: HA-2027-Cycle, MoPH-Critical-Inventory, FDA-Class-3, Vendor-Loaner.
• Status flag: Pre-Disposal, Quarantined, Awaiting-Disposal-Comm.
• Funding source: Government-Budget, Donation-Foundation-X, Lease.

A request rule of thumb:

If a fact is binary and used for filtering — tag it. If a fact is a graded judgement that should drive colour — tier it.

Permissions¶

The module ships no ACL CSV because it adds no new model. The two new selection fields and the two new computed fields all live on maintenance.equipment, so they follow the existing maintenance ACLs:

Audit trail: every change to roots_value_tier or roots_risk_tier posts to the equipment chatter via tracking=True. That's the only audit hook — there is no separate criticality-change log table.

Bulk migration playbook¶

If you're rolling HEMMS into an existing hospital, criticality classification is the longest-tail data task. A sequencing that works:

1. Day 1 — Load equipment with all tier fields defaulting to medium. Result: every row is 🟡 Yellow.
2. Day 1, hour 2 — Bulk-set obvious red by category. List-view filter category = "Defibrillator" → select all → Update fields → Value: medium, Risk: high. Repeat for ventilators, infusion pumps, MRI, anesthesia.
3. Day 1, hour 3 — Bulk-set obvious green by category. Stethoscopes, manual BP cuffs, office printers, workshop tools.
4. Week 1 — Department walk-through — BME head + each ward head walk through the remaining yellow and confirm / adjust on the spot. The list-view row decoration makes the remaining work obvious.
5. Month 1 — Spot-check at the first PM cycle — when a technician touches a piece of equipment for routine PM, they confirm or correct the tier. After a full PM cycle (typically 12 months), criticality is fully curated.

Module facts (configuration cheat-sheet)¶

Next steps¶

• Workflows — how downstream modules consume criticality.
• Reporting — equipment census by criticality.