Skip to content

For DPO / Compliance Officer

Who you are

You own the evidence. When the HA Thailand surveyor sits down, when a PDPA complaint lands, or when the internal auditor opens an engagement, you are the one who has to show that the equipment- management process is documented, signed, and tamper-evident. HEMMS is built so that you can answer those requests in minutes, not days.

What HEMMS does for you

Capability Compliance angle
Immutable workflow audit log (hemms.stage.transition.log) Who moved which request, between which stages, when, why
Lock-on-submit JSON snapshot on the HA Annual PM Report Byte-identical reprint years later — surveyor-defensible
e-Signature via sign_oca for ปจป. and HA Annual Report Chained SHA-256 audit trail of every sign event
Per-stage SLA timer with breach flag Operational SLA evidence (not just a target — a measurement)
Mass-Import dry-run preview + audit batch records Bulk changes are previewable AND traceable to who imported them
Standard Odoo chatter on every business object mail.message log of every value change, attached file, user note

The two year-end compliance artifacts

HEMMS ships the two documents a Thai public hospital is required to produce annually:

1. ปจป. Annual Asset Inspection

  • What: physical-count workflow for medical equipment (ตรวจสอบพัสดุประจำปี under MoF rules).
  • Where: Maintenance → Asset Inspection → Annual Inspections.
  • Sign-off chain: ผู้ตรวจสอบพัสดุ (one or more inspectors), via sign_oca.
  • Lock: on submit, the inspection rows freeze; later edits raise UserError.

2. HA Annual PM Report

  • What: equipment register + per-equipment PM evidence required by HA Thailand มาตรฐานระบบบริการสุขภาพ ด้านที่ 6 ข้อ 6.1.4.
  • Where: Maintenance → Reporting → HA Annual PM Report.
  • Sign-off chain: three signers — BME Head, Engineering Head, Hospital Director — routed in sequence by sign_oca.
  • Lock: action_submit() writes an immutable JSON snapshot including every line, the full MoPH 82-device classification table at submission time, and a paperformat fingerprint. The QWeb template renders from the snapshot — not from the live data — for any submitted report.
  • Signed-PDF storage: when all three signers complete, _check_signed stores the signed PDF on roots_signed_pdf and posts it to chatter. The header badge flips from 🟡 รอลงนาม to 🟢 ลงนามครบ.

Why reprint-stability matters

A surveyor may revisit evidence two years later. With HEMMS, the PDF they see is the PDF that was signed — every glyph, every page break — because rendering comes from a frozen JSON snapshot, not from live tables that may have moved.

A typical month / quarter / year

Monthly

  • Sample 5 closed maintenance.request records. Open the chatter and the audit log. Verify the stage transitions match the timestamps in the log and that every transition has an actor user.
  • Run the SLA breached search on the kanban. The breach count is a leading indicator for an HA observation finding ("PM not done within frequency").

Quarterly

  • Pull every submitted but unsigned HA Annual / ปจป. report. Anything sitting unsigned for more than the policy SLA is a governance flag — chase the signer.
  • Review Mass-Import batches under Maintenance → Configuration → Mass-Import Batches. Confirm every batch has a known importer user and a known business reason in notes — bulk-load is a control point.

Annually

  • Verify the year's signed PDFs for ปจป. and HA Annual are stored in the report record (attachment + roots_signed_pdf field).
  • Run the immutability check: open last year's submitted HA Annual Report, click Print. Compare the SHA-256 of the resulting PDF against the value posted to chatter at sign-off time. Identical → control is working.

Key reports/dashboards to bookmark

Bookmark Path
Submitted-but-unsigned HA reports Maintenance → Reporting → HA Annual PM Report, filter state = submitted + no signed PDF
Mass-Import audit batches Maintenance → Configuration → Mass-Import Batches
SLA-breached requests Maintenance → Maintenance Requests, SLA Breached search filter
Stage transition log open any request → Audit Log tab
Signature requests history sign_oca requests linked to each report

PDPA notes

HEMMS holds operational personal data — res.users (technicians, signers), res.partner (vendors). It does NOT hold patient PHI. The PDPA touchpoints to be aware of:

  • Sign-off events store the signer's name, employee record, and the signed-PDF image. Standard Odoo retention applies (no auto-purge).
  • Audit-log rows are append-only by design — they are the evidence, not user-modifiable data.
  • Standard Odoo access rights (groups, record rules) gate every model. The HEMMS modules add hospital-specific groups (group_hemms_*_user / manager) layered on top.

If a data-subject access request arrives

The DPO can export every record involving a named user via the standard Odoo XLSX export on each model. There is currently no "single export everything for user X" button — that is a roadmap item if your hospital sees frequent DSARs.

What you DON'T need to do

HEMMS removes these pain points

  • No more paper sign-off chase — sign_oca routes report signatures by email and shows the signer's status in real time.
  • No more "is this PDF the signed one?" — the signed PDF is a named field on the report record, with SHA-256 in chatter.
  • No more "who edited this?" — the chatter on every business object records every field change with timestamp + actor.
  • No more "did the surveyor see this exact PDF?" — the lock-on- submit snapshot guarantees the answer is yes.