ข้ามไปที่เนื้อหา

PDPA (พระราชบัญญัติคุ้มครองข้อมูลส่วนบุคคลของไทย)

พระราชบัญญัติคุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562 (2019) ของไทย — รู้จักกันในชื่อ PDPA — มีผลบังคับใช้เต็มรูปแบบเมื่อ 1 มิถุนายน 2022 กฎหมายนี้ จำลองอย่างใกล้ชิดจาก GDPR ของสหภาพยุโรป และให้สิทธิแก่เจ้าของข้อมูลชาวไทย ในการเข้าถึง แก้ไข ลบ จำกัด โอนย้าย และคัดค้านข้อมูลส่วนบุคคลที่ถูกเก็บ เกี่ยวกับตน

โรงพยาบาลเป็นผู้ควบคุมข้อมูล (Data Controller) ภายใต้ PDPA แทบทุกครั้ง HEMMS ในฐานะ ระบบที่ติดตั้งในโรงพยาบาล จึงต้องประมวลผลข้อมูลส่วนบุคคลอย่างชอบด้วยกฎหมาย เก็บเฉพาะที่จำเป็น และให้เจ้าหน้าที่คุ้มครองข้อมูลส่วนบุคคล (Data Protection Officer: DPO) ของโรงพยาบาลสามารถตอบสนองคำร้องของเจ้าของข้อมูลได้

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

ข้อมูลส่วนบุคคลที่ HEMMS เก็บ

จัดหมวดหมู่ตามประเภทของเจ้าของข้อมูล:

เจ้าของข้อมูล ข้อมูลส่วนบุคคลที่เก็บ ฟิลด์แหล่งที่มา ฐานทางกฎหมาย (โดยทั่วไป)
พนักงานโรงพยาบาล (ช่างเทคนิค หัวหน้า BME หัวหน้าวิศวกรรม ผู้อำนวยการ) ชื่อ อีเมล ล็อกอิน รหัสพนักงาน ภาพลายเซ็น res.users, hr.employee, ลายเซ็น sign.oca.request สัญญาจ้างงาน
ผู้ติดต่อของผู้ขายภายนอก (คู่สัญญาบริการ) ชื่อ อีเมล โทรศัพท์ บทบาท ภาพลายเซ็น (หากเป็นผู้ลงนามภายนอก) res.partner, sign.oca.request สำหรับผู้ลงนาม Q3/Q4 ประโยชน์โดยชอบด้วยกฎหมาย / ความจำเป็นตามสัญญา
ใครก็ตามที่ลงนามในเอกสาร HEMMS ภาพลายเซ็น IP ที่ลงนาม เวลาประทับการลงนาม SHA-256 ของ PDF ที่ลงนามแล้ว ตารางร่องรอยการตรวจสอบ sign.oca.request ความยินยอม ณ เวลาลงนาม + ความจำเป็นตามสัญญา

สิ่งที่ HEMMS ไม่เก็บ

  • ไม่มีข้อมูลผู้ป่วย HEMMS เป็นระบบเครื่องมือ ชื่อผู้ป่วย การวินิจฉัย การรักษา ผลแล็บ ภาพถ่ายรังสี — ไม่มีสิ่งใดอยู่ใน HEMMS ไม่มี res.partner ที่ถูกทำเครื่องหมายว่าเป็นผู้ป่วย
  • ไม่มีข้อมูลประเภทพิเศษ (เชื้อชาติ ศาสนา ภาวะสุขภาพ ฯลฯ) เกินกว่าที่อาจมีโดยบังเอิญในระเบียนพนักงานที่จัดการโดย Odoo HR
  • ไม่มีข้อมูลชีวมิติ เกินกว่าภาพลายเซ็นที่บันทึกไว้เอง ซึ่งเป็นเครื่องหมายที่เจ้าของข้อมูลทำขึ้นโดยตั้งใจในขณะนั้น — ไม่ใช่ แม่แบบชีวมิติที่เก็บมาแบบเฉื่อย ๆ

ฟีเจอร์ที่เกี่ยวข้องกับ PDPA ที่ HEMMS สืบทอดมาจาก Odoo

Odoo 18 ส่งมอบเครื่องมือที่สอดคล้องกับ GDPR ซึ่ง HEMMS สืบทอดมาโดยไม่ต้องดัดแปลง:

ฟีเจอร์ Odoo สนับสนุนสิทธิ PDPA ใด
บันทึกร่องรอยการตรวจสอบในตัว บนทุกโมเดล (mail.message + mail.tracking.value) สิทธิในการเข้าถึง — DPO สามารถสร้างใหม่ได้ว่าข้อมูลใดถูกเก็บและเมื่อใด
ขั้นตอน เก็บถาวร/ทำให้ไม่ระบุตัวตนของ res.users สิทธิในการลบข้อมูลสำหรับพนักงานที่ลาออก
นโยบายรหัสผ่าน + 2FA ผ่าน auth_totp ภาระด้านความปลอดภัยตามมาตรา 37
การจัดการคุกกี้ / ความยินยอม (ส่วนหน้าเว็บ) ฐานทางกฎหมายสำหรับผู้ใช้พอร์ทัล (ผู้ลงนามฝ่ายผู้ขาย)
นโยบายสำรองข้อมูล + การเก็บรักษา ควบคุมโดยผู้ดูแลระบบ Odoo ของโรงพยาบาล ข้อจำกัดด้านการจัดเก็บตามมาตรา 37
หลายบริษัท / กฎระเบียน (record rules) การจำกัดวัตถุประสงค์ — คลินิกในเครือโรงพยาบาลไม่สามารถเห็นข้อมูลของอีกแห่งได้

HEMMS ไม่เพิ่มโมเดลใดที่ข้ามการควบคุมเหล่านี้ ทุกโมเดล roots_hemms_* สืบทอด mail.thread (พร้อมแชตเตอร์) เคารพ ACL มาตรฐานของ Odoo และ อยู่ในการสำรองข้อมูลมาตรฐาน

ฟีเจอร์ที่เกี่ยวข้องกับ PDPA ที่ HEMMS เพิ่มเข้ามา

มีบันทึกเฉพาะของ HEMMS อยู่ไม่กี่อย่าง:

PDF ที่ลงนามแล้วและการเก็บรักษาแชตเตอร์

เอกสารที่ลงนามด้วย Q4 ทุกฉบับ (การตรวจสอบ ปจป., รายงาน PM ประจำปีของ HA, สัญญา บริการ) ถูกเก็บเป็น ir.attachment ที่โพสต์ไปยังแชตเตอร์ของระเบียนที่เกี่ยวข้อง ซึ่งหมายความว่า:

  • PDF ที่ลงนามแล้วคงอยู่ตลอดอายุของระเบียนแม่ การลบ พนักงานที่ลงนามใน PDF จะไม่ลบ PDF ที่ลงนามแล้วโดยค่าเริ่มต้น — ลายเซ็นเป็นส่วนหนึ่งของความสมบูรณ์ของเอกสารที่เปลี่ยนแปลงไม่ได้
  • แถวร่องรอยการตรวจสอบการลงนามใน sign.oca.request บันทึกชื่อผู้ลงนาม + อีเมล + IP + เวลาประทับ นี่คือข้อมูลส่วนบุคคลและอยู่ภายใต้คำร้อง การเข้าถึง/ลบของ PDPA
  • SHA-256 ของ PDF ที่ลงนามแล้ว ถูกคำนวณและจัดเก็บ นี่ไม่ใช่ ข้อมูลส่วนบุคคล (เป็นแฮช) แต่หมายความว่าการแก้ไขเปลี่ยนแปลงสามารถตรวจจับได้

ประสานการเก็บรักษา PDF ที่ลงนามแล้วกับการเก็บรักษาหลักฐานของ HA

การตรวจสอบของ HA Thailand และระเบียบกระทรวงการคลังอาจย้อนดู หลายปี การลบ PDF ที่ลงนามแล้วตามคำร้องของเจ้าของข้อมูลอาจทำลาย หลักฐานตามกฎหมาย ระยะเวลาเก็บรักษาที่แนะนำ: 10 ปี สำหรับเอกสาร HA / ปจป. บันทึกสิ่งนี้ในนโยบายการเก็บรักษาข้อมูลของโรงพยาบาลและ ปฏิเสธคำร้องการลบบนพื้นฐานของหน้าที่ตามกฎหมาย (มาตรา 26 ของ PDPA อนุญาตให้ทำได้)

ที่มาของการนำเข้าจำนวนมาก

โมดูลการนำเข้าจำนวนมาก Q6 บันทึกว่าใครนำเข้าแถวใดจากไฟล์ใดเมื่อใด นี่คือข้อมูลส่วนบุคคล (ผู้ใช้ที่นำเข้าสามารถระบุตัวได้) และถูก เก็บใน hemms.import.batch + hemms.import.row แนวทางการเก็บรักษาเดียวกัน นำมาใช้ — เก็บร่องรอยที่มาไว้นานเท่าที่ข้อมูลที่นำเข้ายังมีความหมายในเชิงปฏิบัติการ

บันทึกร่องรอยการตรวจสอบการเปลี่ยนสถานะ

hemms.stage.transition.log บันทึก user_id สำหรับทุกการเปลี่ยนสถานะ นี่ คือข้อมูลส่วนบุคคล และยังเป็นองค์ประกอบสำคัญสำหรับการตรวจสอบของ HA Thailand DPO ควรปฏิบัติต่อมันเช่นเดียวกับที่ปฏิบัติต่อบันทึกร่องรอยการตรวจสอบของระบบ HR — เก็บรักษา เข้าถึงตามคำร้อง ไม่ลบยกเว้นภายใต้การชั่งน้ำหนักของหน้าที่ตามกฎหมาย

รายการตรวจสอบของ DPO สำหรับการติดตั้งในโรงพยาบาล

รายการตรวจสอบในทางปฏิบัติสำหรับ DPO ของโรงพยาบาล แต่ละรายการสามารถยืนยันได้ ในการตั้งค่า HEMMS ภายในไม่ถึงหนึ่งชั่วโมง

รายการตรวจสอบของ DPO ของโรงพยาบาล

  • แต่งตั้ง DPO (จำเป็นหากโรงพยาบาลจัดการข้อมูลส่วนบุคคล ขนาดใหญ่ ซึ่งโรงพยาบาลทำอยู่ — ระบบทางคลินิก ไม่ใช่ HEMMS เป็น ตัวขับเคลื่อนในที่นี้ แต่ DPO ครอบคลุม HEMMS ด้วย)
  • จัดทำแผนผังการไหลของข้อมูล HEMMS ขาเข้า: ระบบ HR → res.users, ระบบจัดซื้อ → res.partner ขาออก: PDF ที่ลงนามแล้วไปยัง ระบบไฟล์ในเครื่อง / S3 / แชตเตอร์ บันทึกสิ่งนี้ในบันทึก กิจกรรมการประมวลผล (Record of Processing Activities: ROPA) ของโรงพยาบาล
  • ลงนามข้อตกลงการประมวลผลข้อมูล (DPA) กับผู้ให้บริการคลาวด์ / โฮสติ้ง หาก HEMMS ทำงานบนคลาวด์ที่มีการจัดการ (Odoo.sh, Trinity Roots cloud, AWS ฯลฯ) DPA ควรครอบคลุมผู้ประมวลผลย่อย ตำแหน่งที่ตั้งข้อมูล การแจ้งเตือนการละเมิด
  • กำหนดนโยบายการเก็บรักษาข้อมูล สำหรับ: PDF ที่ลงนามแล้ว (แนะนำ 10 ปี) บันทึกร่องรอยการตรวจสอบ (แนะนำให้เท่ากับหรือมากกว่า PDF ที่ลงนาม) ชุด การนำเข้า (แนะนำให้เท่ากับบันทึกร่องรอยการตรวจสอบ)
  • ตั้งค่านโยบายรหัสผ่าน + 2FA สำหรับผู้ใช้ทั้งหมดที่เข้าถึง HEMMS ใช้ auth_totp สำหรับช่างเทคนิคและผู้จัดการ พิจารณา SSO สำหรับ โรงพยาบาลขนาดใหญ่
  • จำกัดการเข้าถึงพอร์ทัล เพื่อให้ผู้ลงนามฝ่ายผู้ขายภายนอกเห็นเฉพาะ สิ่งที่ต้องลงนาม ไม่ใช่ชุดข้อมูล HEMMS ที่กว้างกว่า บริดจ์ sign_oca ของ Q4 ทำสิ่งนี้อยู่แล้ว ตรวจสอบกฎระเบียนของผู้ใช้พอร์ทัลระหว่าง UAT
  • บันทึกฐานทางกฎหมาย สำหรับแต่ละหมวดหมู่ข้อมูลใน ROPA ข้อมูลพนักงาน: สัญญาจ้างงาน ข้อมูลผู้ขาย: ประโยชน์ โดยชอบด้วยกฎหมาย ข้อมูลลายเซ็น: ความยินยอม ณ เวลาลงนาม
  • อบรมบุคลากร BME เกี่ยวกับพื้นฐาน PDPA — พวกเขาจะรับคำร้อง ของเจ้าของข้อมูลส่วนใหญ่ในทางปฏิบัติ (เช่น ช่างเทคนิคขอ สำเนาประวัติ PM ของตน)
  • ซ้อมรับมือการละเมิดข้อมูลแบบบนโต๊ะ (tabletop) อย่างน้อยปีละครั้ง นาฬิกานับ 72 ชั่วโมง สำหรับการแจ้งเตือนการละเมิดตามมาตรา 37 สั้น บุคลากรต้อง รู้ว่าจะโทรหาใคร

เวิร์กโฟลว์คำร้องของเจ้าของข้อมูล

เมื่อเจ้าของข้อมูล (โดยทั่วไปคือพนักงานหรืออดีตพนักงาน) ยื่นคำร้อง:

  1. DPO รับคำร้อง ผ่านช่องทางรับมาตรฐานของโรงพยาบาล (อีเมล พอร์ทัล แบบฟอร์มกระดาษ)
  2. DPO เปิด HEMMS ในฐานะผู้ดูแลระบบและค้นหา res.users, hr.employee, res.partner และ sign.oca.request สำหรับเจ้าของข้อมูล
  3. DPO รวบรวมคำตอบ เครื่องมือส่งออกในตัวของ Odoo สร้าง CSV/JSON ต่อระเบียน สำหรับบันทึกร่องรอยการตรวจสอบ ให้สืบค้น hemms.stage.transition.log กรองตาม user_id
  4. DPO ดำเนินการตอบสนองที่เหมาะสม — การเข้าถึง การแก้ไข หรือ การลบ — ภายใน 30 วันตามที่ PDPA กำหนด
  5. DPO บันทึกคำร้อง ในทะเบียนคำร้องของโรงพยาบาล (นอก HEMMS)

คำร้องการลบข้อมูลร่องรอยการตรวจสอบการลงนาม ข้อมูลรายงาน HA หรือข้อมูล ปจป. ควร ถูกปฏิเสธบนพื้นฐานของมาตรา 26 (หน้าที่ตามกฎหมาย / ประโยชน์สาธารณะ) — และบันทึกการปฏิเสธในทะเบียนคำร้อง