WHO gap priority checklist

Master sequencing view across the three source checklists: docs/who-lifecycle-gap-checklist.md, docs/who-inventory-nomenclature-gap-checklist.md, and docs/who-maintenance-cmms-gap-checklist.md — all derived from comparing Ovahol against Inventory and maintenance management information system for medical devices (WHO, 2025) — publication page.

Each item below links back to its source doc for the actual implementation sub-tasks; this doc only tracks what order to build things in and why. Ranked by impact first (patient safety and how many WHO sections reference the gap), with effort noted so cheap wins can be pulled forward if that's more useful in practice.

#	Item	Effort	Source
1	Inspection & calibration records	L	Lifecycle §P1, Maintenance §refinements
2	UDI support	L	Inventory §P1
3	Mean time to repair (MTTR) metric	S	Maintenance §P1
4	Failure trend analysis	S	Maintenance §P2
5	GMDN nomenclature code	S	Inventory §P2
6	Post-market surveillance / regulator submission tracking	S/M	Lifecycle §P3
7	Installation record	S	Lifecycle §P2
—	Predictive maintenance	—	Deferred
—	EHR/ERP/IoT integration	—	Deferred
—	Procurement needs-assessment	—	Not planned
—	Regional/national inventory tier	—	Not planned

1. Inspection & calibration records

Why #1: the single most-referenced gap across the whole comparison — it's WHO's lifecycle stage 5 (performance monitoring), maintenance strategies §6.4.2–6.4.3, and an explicit line item in WHO's own CMMS data checklist (§7). It's also the most patient-safety-critical of the open items (undetected device degradation directly risks harm), and it's the prerequisite for predictive maintenance ever being meaningful, since there's no history to predict from without it.

• [x] Build per docs/who-lifecycle-gap-checklist.md Priority 1, using the richer structure noted in docs/who-maintenance-cmms-gap-checklist.md's "Refinements" section: four inspection triggers (routine, pre-use, post-repair, regulatory), four check categories (visual, functional, safety testing, software/firmware validation), and the four-step calibration process (baseline → adjustment → verification → documentation) rather than a single certificate/next-due field.

2. UDI support

Why #2: second-highest impact — directly improves recall precision and patient safety (WHO frames UDI as the backbone of fast, accurate recall response), and it's foundational to getting cross-model maintenance consistency right. Ranked below inspection/calibration only because it's referenced by one section (inventory) rather than three.

• [x] Build per docs/who-inventory-nomenclature-gap-checklist.md Priority 1. Note the recall-matching sub-task there — that's the part of this gap with the most direct patient-safety payoff, so don't skip it even if the rest gets descoped. Done end-to-end: UDI-DI on model (core 059 migration) + UDI-PI (lot_number, expiration_date) on device_record (tenant 042), surfaced on device detail/list/edit and the Excel lifecycle export, with flexible recall targeting by single device, whole model, or UDI-DI (tenant 043) — including resolving which physical device_records a model/UDI-DI-scoped recall actually affects (GET /recalls/:id/affected-devices), shown on the recall detail page.

3. Mean time to repair (MTTR) metric

Why #3: cheap. The underlying data (actual_duration_minutes per work order) already exists — this is a rollup/reporting task, not new data capture. Good candidate to pull forward if you want a quick win before tackling #1/#2.

• [x] Build per docs/who-maintenance-cmms-gap-checklist.md Priority 1. Done: avg_mttr_minutes added to GetWorkOrderResolutionMetrics (average wall-clock completed_at - created_at filtered to CORRECTIVE work orders, alongside the existing all-type resolution/execution averages), surfaced on WorkOrderStatsResponse and shown as an MTTR tile on both the facility dashboard's response metrics strip and the work orders list page. Not trended over time (all-time average, matching the existing resolution/execution metrics) — flagged in the source doc as a "consider," not a requirement.

4. Failure trend analysis

Why #4: same rationale as #3 — FailureCode is already captured on every fault report, this just aggregates it. Cheap, no new schema.

• [x] Build per docs/who-maintenance-cmms-gap-checklist.md Priority 2. (Previously mis-marked done with no implementation notes — audited 2026-08-30, confirmed nothing was built, corrected to unchecked, then actually built.) Done: GetFailureTrends query in internal/modules/maintenance/repository/sql/fault_report.sql groups fault reports by failure code + device model within a trailing time window (default 90 days), exposed at GET /fault-reports/failure-trends?days=N. Surfaced as a "Recurring Failure Patterns" panel on the fault reports overview page (ListFaultReports.vue), alongside the existing By Status/By Location breakdowns.

5. GMDN nomenclature code

Why #5: cheap and mechanical — mirrors the existing EMDNCode/ EMDNTerm pattern field-for-field, including extending the existing DictionaryRecommendationService workflow rather than inventing anything new. Lower impact than the others since EMDN already covers the nomenclature-standardization goal for EU-aligned facilities; GMDN mainly matters for non-EU interoperability.

• [x] Build per docs/who-inventory-nomenclature-gap-checklist.md Priority 2. Done: gmdn_code/gmdn_term added to core_public.device (core 060 migration) alongside the existing emdn_code/emdn_term (EMDN was also missing from the Excel export — fixed alongside GMDN), surfaced on the device classification catalog, device record detail/list views (facility and org level), and the DictionaryRecommendationService proposal workflow.

6. Post-market surveillance / regulator submission tracking

Why #6: moderate impact, moderate-small effort — extends an existing entity (IncidentReport) rather than creating a new one, but the payoff (actually tracking that a report was filed, not just that it should be) is real for facilities under active regulatory oversight.

• [x] Build per docs/who-lifecycle-gap-checklist.md Priority 3. Done: regulator_name, report_reference, submitted_at, submitted_by added to IncidentReport (tenant 044 migration) as a discrete "submit to regulator" action (POST /incidents/:id/submit-to-regulator, mirroring the acknowledge/close-recall action pattern rather than folding into the generic update endpoint), surfaced on the incident detail page and the Excel lifecycle export. Manufacturer-notification tracking (the doc's "consider... confirm before building" second bullet) was left out — out of scope without confirming it's a real workflow need.

7. Installation record

Why #7 (last of the actionable items): lowest impact of the concrete gaps — it's a one-time event per device (unlike inspection/calibration, which repeat and compound in value over a device's life), and the existing installation_date field already covers the bare minimum.

• [x] Build per docs/who-lifecycle-gap-checklist.md Priority 2. Done: site_readiness_confirmed, connections_verified, installed_by added to device_record (tenant 045 migration) — no new entity, per the doc's own scoping note. Surfaced on the create/edit device record forms (an "Installed By" facility-member picker + two checkboxes) and the device detail page, and added to the Excel lifecycle export.

Deferred

• Predictive maintenance — blocked on #1 existing first; revisit once inspection/calibration history is actually accumulating.
• EHR/ERP/IoT integration — large, separate integration surface, not scoped in detail in any of the three source docs.

Not planned (intentional scope boundaries, not gaps to close)

• Procurement needs-assessment / evidence-based device selection — a health-system planning/finance concern, not equipment-management data.
• Regional/national inventory tier — would require aggregating across organizations for a government/regulator consumer, a different product category from a facility/health-network SaaS tool.