สำหรับ DPO / เจ้าหน้าที่กำกับการปฏิบัติตามข้อกำหนด¶

คุณคือใคร¶

คุณเป็นเจ้าของ หลักฐาน เมื่อผู้ตรวจประเมินของ HA Thailand นั่งลง เมื่อ มีข้อร้องเรียน PDPA เข้ามา หรือเมื่อผู้ตรวจสอบภายในเปิดงานตรวจสอบ คุณคือ คนที่ต้องแสดงว่ากระบวนการจัดการเครื่องมือได้รับการบันทึกไว้ ลงนามแล้ว และ ตรวจพบการแก้ไขได้ HEMMS สร้างขึ้นเพื่อให้คุณตอบคำขอเหล่านั้นได้ในไม่กี่นาที ไม่ใช่หลายวัน

สิ่งที่ HEMMS มอบให้คุณ¶

ความสามารถ	มุมการปฏิบัติตามข้อกำหนด
บันทึกการตรวจสอบขั้นตอนการทำงานที่ไม่สามารถแก้ไขได้ (`hemms.stage.transition.log`)	ใครย้ายคำขอใด ระหว่างขั้นใด เมื่อใด เพราะอะไร
สแนปช็อต JSON ที่ล็อกเมื่อส่งบนรายงาน HA Annual PM	พิมพ์ซ้ำเหมือนกันทุกไบต์แม้หลายปีต่อมา — ป้องกันต่อผู้ตรวจประเมินได้
ลายเซ็นอิเล็กทรอนิกส์ผ่าน `sign_oca` สำหรับ ปจป. และรายงาน HA Annual	ร่องรอยการตรวจสอบ SHA-256 แบบเชื่อมโซ่ของทุกเหตุการณ์การลงนาม
ตัวจับเวลา SLA ต่อขั้นพร้อมธงการละเมิด	หลักฐาน SLA เชิงปฏิบัติการ (ไม่ใช่แค่เป้าหมาย — เป็นการวัดผล)
ตัวอย่างก่อนนำเข้าจริงของ Mass-Import + ระเบียนชุดการตรวจสอบ	การเปลี่ยนแปลงจำนวนมากดูตัวอย่างได้ และตรวจสอบย้อนกลับไปยังผู้นำเข้าได้
chatter มาตรฐานของ Odoo บนทุกอ็อบเจกต์ทางธุรกิจ	บันทึก mail.message ของทุกการเปลี่ยนค่า ไฟล์ที่แนบ บันทึกของผู้ใช้

ผลลัพธ์การปฏิบัติตามข้อกำหนดปลายปีสองรายการ¶

HEMMS จัดส่งเอกสารสองฉบับที่โรงพยาบาลรัฐของไทยต้องจัดทำเป็นประจำทุกปี:

1. การตรวจสอบครุภัณฑ์ประจำปี ปจป.¶

คืออะไร: ขั้นตอนการตรวจนับเครื่องมือแพทย์ (ตรวจสอบพัสดุประจำปีตามระเบียบกระทรวงการคลัง)
อยู่ที่ไหน: Maintenance → Asset Inspection → Annual Inspections
ห่วงโซ่การลงนาม: ผู้ตรวจสอบพัสดุ (หนึ่งคนหรือมากกว่า) ผ่าน sign_oca
การล็อก: เมื่อส่ง บรรทัดการตรวจสอบจะถูกแช่แข็ง การแก้ไขภายหลัง จะทำให้เกิด UserError

2. รายงาน HA Annual PM¶

คืออะไร: ทะเบียนเครื่องมือ + หลักฐาน PM ต่อเครื่องมือที่ HA Thailand กำหนดตาม มาตรฐานระบบบริการสุขภาพ ด้านที่ 6 ข้อ 6.1.4
อยู่ที่ไหน: Maintenance → Reporting → HA Annual PM Report
ห่วงโซ่การลงนาม: ผู้ลงนามสามคน — หัวหน้า BME หัวหน้าวิศวกรรม ผู้อำนวยการโรงพยาบาล — ส่งตามลำดับโดย sign_oca
การล็อก: action_submit() เขียนสแนปช็อต JSON ที่ไม่สามารถแก้ไขได้ รวมทุกบรรทัด ตารางการจัดประเภทอุปกรณ์ MoPH 82 รายการเต็มรูปแบบ ณ เวลา ที่ส่ง และลายนิ้วมือ paperformat เทมเพลต QWeb เรนเดอร์จากสแนปช็อต — ไม่ใช่จากข้อมูลสด — สำหรับรายงานที่ส่งแล้วทุกฉบับ
การจัดเก็บ PDF ที่ลงนาม: เมื่อผู้ลงนามทั้งสามคนเสร็จสิ้น _check_signed จัดเก็บ PDF ที่ลงนามไว้ที่ roots_signed_pdf และโพสต์ ไปยัง chatter ป้ายสถานะส่วนหัวจะพลิกจาก 🟡 รอลงนาม เป็น 🟢 ลงนามครบ

เหตุใดความเสถียรของการพิมพ์ซ้ำจึงสำคัญ

ผู้ตรวจประเมินอาจกลับมาตรวจหลักฐานอีกครั้งในอีกสองปีต่อมา ด้วย HEMMS PDF ที่พวกเขาเห็นคือ PDF ที่ถูกลงนาม — ทุกตัวอักษร ทุกการขึ้นหน้าใหม่ — เพราะการเรนเดอร์มาจากสแนปช็อต JSON ที่แช่แข็งไว้ ไม่ใช่จากตารางสดที่ อาจเคลื่อนไปแล้ว

เดือน / ไตรมาส / ปีโดยทั่วไป¶

รายเดือน¶

สุ่มตัวอย่างระเบียน maintenance.request ที่ปิดแล้ว 5 รายการ เปิด chatter และบันทึกการตรวจสอบ ตรวจสอบว่าการเปลี่ยนขั้นตรงกับเวลาประทับ ในบันทึกและทุกการเปลี่ยนผ่านมีผู้ใช้ที่เป็น actor
รันการค้นหา SLA breached บน kanban จำนวนการละเมิดเป็นตัวบ่งชี้ นำหน้าสำหรับข้อสังเกตของ HA ("ไม่ได้ทำ PM ภายในความถี่ที่กำหนด")

รายไตรมาส¶

ดึงรายงาน HA Annual / ปจป. ทุกฉบับที่ ส่งแล้ว แต่ ยังไม่ลงนาม สิ่งใดที่ค้างอยู่โดยยังไม่ลงนามเกิน SLA ตามนโยบายถือเป็นธงด้านการกำกับ ดูแล — ตามผู้ลงนาม
ทบทวน ชุด Mass-Import ใต้ Maintenance → Configuration → Mass-Import Batches ยืนยันว่าทุกชุด มีผู้ใช้ที่นำเข้าที่ทราบและเหตุผลทางธุรกิจที่ทราบในหมายเหตุ — การนำเข้า จำนวนมากเป็นจุดควบคุม

รายปี¶

ตรวจสอบว่า PDF ที่ลงนามของ ปจป. และ HA Annual ประจำปีถูกจัดเก็บใน ระเบียนรายงาน (ไฟล์แนบ + ฟิลด์ roots_signed_pdf)
รันการตรวจสอบความไม่สามารถแก้ไขได้: เปิดรายงาน HA Annual ที่ส่งแล้ว ของปีที่แล้ว คลิก Print เปรียบเทียบค่า SHA-256 ของ PDF ที่ได้กับค่า ที่โพสต์ไปยัง chatter ตอนลงนาม เหมือนกัน → การควบคุมทำงานอยู่

รายงาน/แดชบอร์ดสำคัญที่ควรบุ๊กมาร์ก¶

บุ๊กมาร์ก	เส้นทาง
รายงาน HA ที่ส่งแล้วแต่ยังไม่ลงนาม	`Maintenance → Reporting → HA Annual PM Report` กรอง state = submitted + ไม่มี PDF ที่ลงนาม
ชุดการตรวจสอบ Mass-Import	`Maintenance → Configuration → Mass-Import Batches`
คำขอที่ละเมิด SLA	`Maintenance → Maintenance Requests` ตัวกรองค้นหา SLA Breached
บันทึกการเปลี่ยนขั้น	เปิดคำขอใด ๆ → แท็บ Audit Log
ประวัติคำขอลายเซ็น	คำขอ `sign_oca` ที่เชื่อมโยงกับแต่ละรายงาน

หมายเหตุ PDPA¶

HEMMS เก็บข้อมูลส่วนบุคคล เชิงปฏิบัติการ — res.users (ช่าง ผู้ลงนาม) res.partner (ผู้ขาย) มัน ไม่ เก็บข้อมูลสุขภาพผู้ป่วย (PHI) จุดสัมผัส PDPA ที่ควรตระหนัก:

เหตุการณ์การลงนามจัดเก็บชื่อผู้ลงนาม ระเบียนพนักงาน และภาพ PDF ที่ลงนาม ใช้การเก็บรักษาข้อมูลมาตรฐานของ Odoo (ไม่มีการล้างอัตโนมัติ)
แถวบันทึกการตรวจสอบเป็นแบบเพิ่มได้อย่างเดียวโดยการออกแบบ — เป็นหลักฐาน ไม่ใช่ข้อมูลที่ผู้ใช้แก้ไขได้
สิทธิ์การเข้าถึงมาตรฐานของ Odoo (กลุ่ม ระเบียนกฎ) ควบคุมทุกโมเดล โมดูล HEMMS เพิ่มกลุ่มเฉพาะของโรงพยาบาล (group_hemms_*_user / manager) ซ้อนทับด้านบน

หากมีคำขอเข้าถึงข้อมูลของเจ้าของข้อมูลเข้ามา

DPO สามารถส่งออกทุกระเบียนที่เกี่ยวข้องกับผู้ใช้ที่ระบุชื่อผ่านการ ส่งออก XLSX มาตรฐานของ Odoo บนแต่ละโมเดล ปัจจุบันยังไม่มีปุ่ม "ส่งออกทุกอย่างของผู้ใช้ X เพียงปุ่มเดียว" — นั่นเป็นรายการในแผนงาน หากโรงพยาบาลของคุณพบ DSAR บ่อยครั้ง

สิ่งที่คุณไม่ต้องทำ¶

HEMMS ขจัดจุดเจ็บปวดเหล่านี้

ไม่ต้องไล่ตามการลงนามกระดาษอีกต่อไป — sign_oca ส่งลายเซ็น รายงานทางอีเมลและแสดงสถานะของผู้ลงนามแบบเรียลไทม์
ไม่ต้องถาม "PDF นี้คือฉบับที่ลงนามหรือเปล่า?" อีกต่อไป — PDF ที่ ลงนามเป็นฟิลด์ที่มีชื่อบนระเบียนรายงาน พร้อม SHA-256 ใน chatter
ไม่ต้องถาม "ใครแก้ไขอันนี้?" อีกต่อไป — chatter บนทุกอ็อบเจกต์ ทางธุรกิจบันทึกทุกการเปลี่ยนฟิลด์พร้อมเวลาประทับ + ผู้กระทำ
ไม่ต้องถาม "ผู้ตรวจประเมินเห็น PDF ฉบับนี้เป๊ะ ๆ หรือเปล่า?" อีกต่อไป — สแนปช็อตที่ล็อกเมื่อส่งรับประกันว่าคำตอบคือใช่

Repair Workflow — 5 ขั้น + SLA + บันทึกการตรวจสอบ
Asset Inspection (ปจป.) — การตรวจนับครุภัณฑ์ประจำปี + การลงนาม
HA Annual PM Report — หลักฐาน PM ปลายปี + ห่วงโซ่ผู้ลงนามสามคน
Signature — สะพานเชื่อม sign_oca สำหรับรายงานทั้งสอง
Mass Import — นำเข้าจำนวนมากพร้อม dry-run + การตรวจสอบชุด