ทบทวนเนื้อหา 16 ตุลาคม 2569
การตรวจความพร้อมของ HIS ควรเริ่มจากรายการข้อมูลและกระบวนการที่โรงพยาบาลทำจริง แล้วระบุว่าข้อกำหนดใดเกี่ยวข้อง ใครเป็นผู้รับผิดชอบ และจะใช้หลักฐานอะไรตรวจสอบ บทความนี้ช่วยทีม IT จัดคำถามร่วมกับฝ่ายเวชระเบียน การเงิน DPO และฝ่ายกฎหมาย โดยแยกข้อกฎหมายออกจากข้อเสนอด้านการออกแบบระบบ

เริ่มจากแยกข้อกฎหมาย มาตรฐาน และนโยบายองค์กร
| สิ่งที่กำลังตรวจ | หลักฐานที่ควรอ้าง | สิ่งที่ทีม IT ต้องจัดทำ |
|---|---|---|
| ข้อกฎหมายและประกาศที่ใช้บังคับ | ชื่อฉบับ มาตรา ขอบเขต และวันที่ตรวจสอบ | ผูกข้อกำหนดกับระบบและเจ้าของกระบวนการ |
| มาตรฐานหรือกรอบอ้างอิง | ฉบับและขอบเขตที่องค์กรเลือกใช้ | ระบุสิ่งที่นำมาปรับใช้และวิธีทดสอบ |
| นโยบายและสัญญา | ผู้อนุมัติ ระยะเวลา และขอบเขตบริการ | ตั้งค่า ขั้นตอนปฏิบัติ และบันทึกผลทดสอบ |
ชื่อเทคโนโลยีหรือการมีฟีเจอร์หนึ่งอย่างไม่ใช่หลักฐานว่าทั้งองค์กรผ่านข้อกำหนดทั้งหมด ต้องตรวจทั้งการตั้งค่า กระบวนการทำงาน และการใช้จริง
ข้อมูลสุขภาพต้องระบุวัตถุประสงค์และฐานกฎหมาย
ข้อมูลสุขภาพอยู่ในกลุ่มข้อมูลตามมาตรา 26 ของ PDPA การใช้ข้อมูลต้องพิจารณาฐานกฎหมายและเงื่อนไขที่เกี่ยวข้อง ไม่ใช่ถือว่าทุกกิจกรรมต้องใช้ความยินยอมแบบเดียวกัน อ่านตัวบท PDPA
ข้อเสนอสำหรับการทำงาน: ทำทะเบียนกิจกรรมแยกระหว่างรักษา เบิกจ่าย วิจัย และวิเคราะห์ข้อมูล ระบุผู้รับข้อมูลและความจำเป็นของแต่ละช่อง แล้วให้ผู้รับผิดชอบตรวจเงื่อนไขก่อนเปิดใช้หรือส่งต่อข้อมูล
ข้อมูลจราจรทางคอมพิวเตอร์กับ Clinical Audit Log ต้องประเมินแยกกัน
มาตรา 26 แห่ง พ.ร.บ. คอมพิวเตอร์กำหนดเรื่องข้อมูลจราจรของผู้ให้บริการที่อยู่ในขอบเขตไว้ไม่น้อยกว่า 90 วัน และมีกรณีคำสั่งเฉพาะให้เก็บนานขึ้นได้ ต้องตรวจประเภทผู้ให้บริการและประกาศที่เกี่ยวข้องด้วย ระยะนี้ไม่ควรถูกนำไปกำหนดอายุของเวชระเบียนหรือ Audit Log ทุกชนิดโดยอัตโนมัติ ตัวบท พ.ร.บ. คอมพิวเตอร์
สำหรับ HIS ให้ทำตารางอายุข้อมูลแยกตามประเภท ระบุเหตุผล เจ้าของข้อมูล วิธีทำลาย และกรณีระงับการทำลายเมื่อมีข้อพิพาท พร้อมเก็บเหตุการณ์เข้าถึง แก้ไข ส่งออก และเปลี่ยนสิทธิ์ตามความเสี่ยง ดูตัวอย่างโครงสร้างได้ใน บทความ Audit Log
เอกสารและลายมือชื่อต้องตรวจตามบริบทการใช้งาน
กำหนดให้ชัดว่าเอกสารใดเป็นฉบับร่าง ฉบับรับรอง และฉบับแก้ไข ใครมีสิทธิ์ลงนามหรือยกเลิก และจะตรวจฉบับเก่าย้อนหลังอย่างไร ส่วนวิธีลงนามต้องตรวจให้เหมาะกับเอกสารและหน่วยงานที่รับ ไม่ควรรับประกันสถานะทางกฎหมายจากชื่อฟีเจอร์เพียงอย่างเดียว อ่านการออกแบบ Digital Signature
การเงินต้องแยกประเภทเอกสารและเหตุผลที่แก้ไข
ใบรับเงิน ใบกำกับภาษี ใบเพิ่มหนี้ และใบลดหนี้มีหน้าที่และเงื่อนไขต่างกัน การแก้ข้อมูลทุกกรณีจึงไม่ได้หมายความว่าต้องออก Credit Note หรือ Debit Note เสมอไป ให้ฝ่ายการเงินพิจารณาประเภทธุรกรรมและกฎที่เกี่ยวข้อง เช่น บทบัญญัติเรื่องเอกสารภาษีมูลค่าเพิ่มของ กรมสรรพากร
ข้อเสนอด้านระบบ: เก็บเลขอ้างอิงฉบับเดิม เหตุผล ผู้อนุมัติ และรายการที่เปลี่ยน แยกการยกเลิกเอกสารออกจากการลบข้อมูล แล้วทดสอบการกระทบยอดและสิทธิ์ของผู้ปฏิบัติงาน
การเชื่อมต่อและการนำข้อมูลไปวิเคราะห์ต้องมีเจ้าของกระบวนการ
ก่อนเชื่อมระบบภายนอกหรือเปิดการวิเคราะห์ ให้ทำแผนภาพว่าข้อมูลใดออกจาก HIS ไปที่ใด ใครรับผิดชอบความถูกต้องและการแจ้งเหตุ กำหนดข้อมูลขั้นต่ำ การยืนยันผู้ส่งผู้รับ และหลักฐานตอบรับ การปกปิดข้อมูลต้องทดสอบความเสี่ยงระบุตัวบุคคลซ้ำด้วย
ให้ตรวจเงื่อนไขเรื่องผู้ประมวลผล การส่งข้อมูลต่างประเทศ และการใช้ต่อเป็นรายกิจกรรม ไม่ใช้คำว่า “มีสัญญาแล้วจึงส่งได้ทุกกรณี” เป็นเงื่อนไขเดียว
Checklist ประชุมตรวจความพร้อมร่วมกัน
- มีทะเบียนข้อกำหนดพร้อมแหล่งอ้างอิง เจ้าของเรื่อง และวันที่ทบทวน
- มีทะเบียนกิจกรรมและเส้นทางการเปิดเผยข้อมูล
- มีตารางอายุข้อมูลพร้อมกระบวนการระงับการทำลาย
- มีหลักฐานการอนุมัติสิทธิ์ การแก้ไข และการส่งออก
- มีกรณีทดสอบเอกสาร การลงนาม ยกเลิก และกระทบยอด
- มีขั้นตอนรับคำร้องและรับมือเหตุละเมิด พร้อมผู้รับผิดชอบและช่องทางติดต่อ
แหล่งอ้างอิงและแนวทางอ่านต่อ
- PDPA พ.ศ. 2562: ตัวบทเผยแพร่โดยกองกฎหมายและระเบียบ กรมประชาสัมพันธ์
- พ.ร.บ. คอมพิวเตอร์ พ.ศ. 2550 และที่แก้ไขเพิ่มเติม: ETDA
- กรมสรรพากร: หมวดภาษีมูลค่าเพิ่มและเอกสารที่เกี่ยวข้อง
blog.ckdoctor.com