Skip to content

PDPA (Thailand Personal Data Protection Act)

Thailand's Personal Data Protection Act B.E. 2562 (2019) — known as PDPA — came fully into force on 1 June 2022. It is modeled closely on the EU GDPR and gives Thai data subjects rights of access, rectification, erasure, restriction, portability, and objection over personal data held about them.

A hospital is almost always a Data Controller under PDPA. HEMMS, as a hospital-deployed system, must therefore process personal data lawfully, hold only what is necessary, and let the hospital's Data Protection Officer (DPO) satisfy data-subject requests.

The good news: HEMMS holds a deliberately small amount of personal data. The architectural decision to keep clinical data out of HEMMS (see Compliance Overview) means the PDPA surface area is small.

What personal data HEMMS holds

Categorised by data-subject class:

Data subject Personal data held Source field(s) Lawful basis (typical)
Hospital employees (technicians, BME head, Engineering head, Director) Name, email, login, employee ID, signature image res.users, hr.employee, sign.oca.request signatures Employment contract
External vendor contacts (service-contract counterparts) Name, email, phone, role, signature image (if external signer) res.partner, sign.oca.request for Q3/Q4 signers Legitimate interest / contractual necessity
Anyone who signed a HEMMS document Signature image, signing IP, signing timestamp, SHA-256 of the signed PDF sign.oca.request audit table Consent at signing time + contractual necessity

What HEMMS does NOT hold

  • No patient data. HEMMS is an equipment system. Patient names, diagnoses, treatments, lab results, imaging — none of it lives in HEMMS. There is no res.partner flagged as patient.
  • No special-category data (race, religion, health condition, etc.) beyond what is incidentally in an employee record managed by Odoo HR.
  • No biometric data beyond the captured signature image itself, which is the data subject's deliberate, contemporaneous mark — not a passively-collected biometric template.

PDPA-relevant features HEMMS inherits from Odoo

Odoo 18 ships GDPR-aligned tooling that HEMMS inherits without modification:

Odoo feature What PDPA right it supports
Built-in audit log on every model (mail.message + mail.tracking.value) Right to access — DPO can reconstruct what data was held and when
res.users archive/anonymize flow Right to erasure for employees who leave
Password policy + 2FA via auth_totp Article 37 security obligation
Cookie / Consent management (web-frontend) Lawful basis for portal users (vendor signers)
Backup + retention policy controlled by the hospital's Odoo administrator Article 37 storage limitation
Multi-company / record rules Purpose limitation — a clinic in a hospital group can't see another's data

HEMMS adds no model that bypasses these controls. Every roots_hemms_* model inherits mail.thread (with chatter), respects standard Odoo ACLs, and participates in the standard backup.

PDPA-relevant features HEMMS adds

A handful of HEMMS-specific notes:

Signed PDFs and chatter retention

Every Q4-signed artifact (ปจป. inspection, HA Annual PM Report, service contracts) is stored as an ir.attachment posted to the relevant record's chatter. This means:

  • The signed PDF persists for the lifetime of the parent record. Erasing an employee who signed a PDF will not, by default, remove the signed PDF — the signature is part of the immutable artifact's integrity.
  • The signing audit row in sign.oca.request records signer name + email + IP + timestamp. This is personal data and is subject to PDPA access/erasure requests.
  • The SHA-256 of the signed PDF is computed and stored. This is not personal data (it is a hash), but it does mean tampering is detectable.

Coordinate signed-PDF retention with HA evidence retention

HA Thailand and ระเบียบกระทรวงการคลัง audits may look back several years. Erasing a signed PDF on a data-subject request may destroy statutory evidence. Recommended retention: 10 years for HA / ปจป. artifacts. Document this in the hospital's data-retention policy and refuse erasure requests on the basis of legal obligation (Article 26 of PDPA permits this).

Mass-import provenance

The Q6 Mass Import module records who imported which row from which file when. This is personal data (the importing user is identifiable) and is captured in hemms.import.batch + hemms.import.row. The same retention guidance applies — keep the provenance trail for as long as the imported data is operationally meaningful.

Stage transition audit log

hemms.stage.transition.log records user_id for every state change. This is personal data. It is also load-bearing for HA Thailand audit. The DPO should treat it the same way they treat HR system audit logs — retain, access on request, do not erase except under the legal-obligation balancing test.

DPO checklist for hospital deployments

A practical checklist for the hospital DPO. Each item can be confirmed in the HEMMS configuration in under an hour.

Hospital DPO checklist

  • Appoint a DPO (required if the hospital handles large-scale personal data, which it does — clinical systems, not HEMMS, are the driver here, but the DPO covers HEMMS too).
  • Map HEMMS data flows. Inputs: HR system → res.users, Procurement system → res.partner. Outputs: signed PDFs to local filesystem / S3 / chatter. Document this in the hospital's Record of Processing Activities (ROPA).
  • Sign a DPA with the cloud / hosting vendor if HEMMS runs on a managed cloud (Odoo.sh, Trinity Roots cloud, AWS, etc.). The DPA should cover sub-processors, data location, breach notification.
  • Set the data-retention policy for: signed PDFs (recommend 10 years), audit logs (recommend match-or-exceed signed PDF), import batches (recommend match audit log).
  • Configure password policy + 2FA for all users with access to HEMMS. Use auth_totp for technicians and managers; consider SSO for large hospitals.
  • Restrict portal access so external vendor signers see only what they need to sign, not the wider HEMMS data set. The Q4 sign_oca bridge already does this; verify portal user record rules during UAT.
  • Document the lawful basis for each data category in the ROPA. Employee data: employment contract. Vendor data: legitimate interest. Signature data: consent at signing time.
  • Train BME staff on PDPA basics — they will receive most of the data-subject requests in practice (e.g., a technician asking for a copy of their PM history).
  • Run a tabletop data-breach drill at least annually. The 72-hour breach-notification clock under Article 37 is short; staff need to know who to call.

Data subject request workflow

When a data subject (typically an employee or ex-employee) makes a request:

  1. DPO receives the request through the hospital's standard intake (email, portal, paper form).
  2. DPO opens HEMMS as an administrator and searches res.users, hr.employee, res.partner, and sign.oca.request for the subject.
  3. DPO compiles the response. Odoo's built-in export tools produce per-record CSV/JSON. For audit logs, query hemms.stage.transition.log filtered by user_id.
  4. DPO applies the appropriate response — access, rectification, or erasure — within 30 days as required by PDPA.
  5. DPO documents the request in the hospital's request register (outside HEMMS).

Erasure requests on signing audit data, HA report data, or ปจป. data should be refused on the basis of Article 26 (legal obligation / public interest) — and the refusal documented in the request register.