Audit Log ของ HIS: ออกแบบให้ตอบได้ว่าใครเปลี่ยนอะไรและเพราะอะไร

ทบทวนเนื้อหา 16 ตุลาคม 2569

เมื่อรายการสั่งตรวจหนึ่งรายการถูกยกเลิก คำถามที่ตามมาอาจมีมากกว่า “ใครเป็นคนกด”

ใครเป็นผู้ขอยกเลิก? ใครเป็นผู้บันทึก? ทำภายใต้สิทธิ์อะไร? รายการอยู่ในสถานะใดก่อนถูกเปลี่ยน? ระบบปลายทางได้รับการยกเลิกแล้วหรือยัง? และเหตุผลที่บันทึกไว้คืออะไร?

โรงพยาบาลต้องตอบคำถามเหล่านี้ได้ทั้งในการทบทวนงานประจำ การตรวจสอบข้อร้องเรียน และการสอบสวนเหตุการณ์ด้านความปลอดภัยของข้อมูล

Audit Log จึงเป็นส่วนหนึ่งของความน่าเชื่อถือของ HIS ความสำเร็จของมันอยู่ที่การนำหลักฐานจากหลายจุดมาต่อกัน จนผู้ตรวจสอบสามารถเข้าใจได้ว่า เกิดอะไรขึ้น กับข้อมูลของใคร โดยใคร ภายใต้บริบทใด และมีผลอย่างไร

สำหรับทีม IT นี่คืองานออกแบบข้อมูล กระบวนการ และการควบคุมสิทธิ์ที่ต้องเดินไปด้วยกัน

มาตรฐานสากลวางแนวทางเรื่องนี้ไว้อย่างไร

มีมาตรฐานและแนวทางหลายชุดที่เกี่ยวข้อง โดยแต่ละชุดช่วยตอบคำถามคนละด้าน

เมื่อนำหลักเหล่านี้มาประยุกต์กับ HIS จะเห็นแนวทางออกแบบที่สำคัญดังต่อไปนี้

เริ่มจากกำหนดให้ชัดว่าเหตุการณ์ใดต้องตรวจสอบย้อนหลังได้

ในโรงพยาบาล การเข้าดูข้อมูลมีความสำคัญต่อความเป็นส่วนตัวพอ ๆ กับการเปลี่ยนข้อมูล แม้เวชระเบียนจะไม่มีการแก้ไข การเข้าถึงที่ไม่เหมาะสมก็อาจเกิดขึ้นได้

ขอบเขตของ Audit Log จึงควรครอบคลุมกิจกรรม เช่น

• เปิดดูเวชระเบียน ค้นหาผู้ป่วย และเรียกดูผลตรวจ
• สร้าง แก้ไข ยืนยัน ยกเลิก หรือแก้ไขเพิ่มเติมรายการทางคลินิก
• พิมพ์ ดาวน์โหลด ส่งออก หรือส่งต่อข้อมูล
• เข้าสู่ระบบไม่สำเร็จ และพยายามเข้าถึงข้อมูลเกินสิทธิ์
• เปลี่ยนสิทธิ์ผู้ใช้ เปลี่ยนนโยบายความปลอดภัย หรือใช้สิทธิ์ฉุกเฉิน

เหตุการณ์เหล่านี้ปรากฏในแนวทางของ IHE ซึ่งครอบคลุมทั้งข้อมูลผู้ป่วย Order การนำเข้า–ส่งออกข้อมูล การยืนยันตัวตน และการใช้งานแบบฉุกเฉินหรือ Break-glass — IHE: Record Audit Event

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

ความชัดเจนนี้ช่วยให้ผู้ตรวจสอบตีความ Log ได้ถูกต้องตั้งแต่ต้น

ออกแบบหนึ่งเหตุการณ์ให้มีบริบทเพียงพอ

ข้อความว่า User A updated record ยังต้องอาศัยการค้นข้อมูลอื่นอีกมากจึงจะเข้าใจเหตุการณ์ได้

แนวทางที่นำไปใช้กับ HIS ได้คือกำหนดองค์ประกอบพื้นฐานดังนี้ โดยรายละเอียดอาจแตกต่างตามประเภทกิจกรรม

ตารางนี้เป็นข้อเสนอสำหรับการออกแบบ HIS โดยผสมบริบทของโรงพยาบาลเข้ากับหลักเรื่องประเภทเหตุการณ์ เวลา แหล่งที่มา ผลลัพธ์ และตัวตนผู้เกี่ยวข้อง ซึ่งพบได้ในแนวทาง Audit and Accountability ขององค์กรบริการสุขภาพอย่าง IHS — IHS: Audit and Accountability

ตัวระบุเหล่านี้ควรใช้อ้างอิงย้อนหลังได้ แม้ผู้ใช้จะย้ายแผนก เปลี่ยนชื่อ หรือถูกปิดบัญชีแล้วก็ตาม โดยเฉพาะบทบาทและสิทธิ์ ควรสะท้อนบริบทขณะเกิดเหตุการณ์ เพราะสิทธิ์ปัจจุบันอาจเปลี่ยนไปแล้ว

หากระบบทำงานอัตโนมัติ ควรระบุชื่อระบบหรือกระบวนการนั้น และเชื่อมกลับไปยังผู้เริ่มคำขอเมื่อมีข้อมูล ไม่ควรรวมทุกกิจกรรมไว้ภายใต้ชื่อผู้ใช้ทั่วไปอย่าง system จนแยกที่มาไม่ได้

คำว่า “เพราะอะไร” ต้องออกแบบให้มากกว่าช่องหมายเหตุ

เหตุผลใน Audit Log มีอย่างน้อยสามมุมที่ควรแยกกัน

วัตถุประสงค์ของการใช้ข้อมูล เช่น เพื่อการรักษา การเรียกเก็บเงิน หรือการตรวจสอบคุณภาพ

เหตุผลของการกระทำ เช่น ยกเลิกเพราะสร้างรายการซ้ำ หรือแก้ไขเพราะบันทึกผิดรายการ

เหตุผลของผลลัพธ์จากระบบ เช่น ปฏิเสธคำขอเพราะผู้ใช้ไม่มีสิทธิ์ หรือรายการอยู่ในสถานะที่ไม่อนุญาตให้แก้ไข

การเก็บทุกอย่างไว้ในช่อง reason เดียวทำให้วิเคราะห์ต่อได้ยาก โดยเฉพาะเมื่อข้อความอย่าง “แก้ไขข้อมูล” หรือ “ดำเนินการตามงาน” ถูกใช้กับแทบทุกเหตุการณ์

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

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

เชื่อม Audit Log กับประวัติข้อมูลแต่ละเวอร์ชัน

การตรวจสอบการเปลี่ยนเวชระเบียนต้องเห็นทั้งกิจกรรมและข้อมูลที่เกี่ยวข้องกับกิจกรรมนั้น

ตัวอย่างเช่น เมื่อมีการแก้ไขรายงาน ผู้ตรวจสอบควรตามได้ว่าใครแก้ไขเมื่อใด พร้อมเปิดดูเวอร์ชันก่อนและหลังตามสิทธิ์ที่ได้รับ รวมถึงทราบว่าฉบับใดเป็นฉบับที่ใช้งานในช่วงเวลาที่กำลังตรวจสอบ

HL7 แยกแนวคิดนี้ผ่าน AuditEvent และ Provenance โดย Provenance ช่วยอธิบายกิจกรรม ผู้เกี่ยวข้อง และแหล่งข้อมูลที่ทำให้ข้อมูลหนึ่งชุดหรือหนึ่งเวอร์ชันเกิดขึ้น — HL7 Provenance

ในการออกแบบจริง อาจให้ Audit Log อ้างอิงจากเวอร์ชันเดิมไปยังเวอร์ชันใหม่ แล้วให้รายละเอียดทางคลินิกอยู่ในส่วนประวัติเวชระเบียนที่ควบคุมสิทธิ์เหมาะสม

วิธีนี้ช่วยรักษาความสามารถในการตรวจสอบ โดยลดการคัดลอกข้อมูลสุขภาพทั้งชุดไปกระจายอยู่ใน Log หลายแห่ง

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

ต่อเหตุการณ์จากหลายระบบให้เป็นเรื่องเดียวกัน

ลองดูตัวอย่างสมมติของการยกเลิก Order:

การส่งคำขอสำเร็จและการยกเลิกที่ปลายทางสำเร็จควรเป็นคนละสถานะ เพื่อให้รู้ว่างานเสร็จถึงขั้นใด

แต่ละระบบควรมีตัวระบุเหตุการณ์ของตัวเอง พร้อมตัวอ้างอิงร่วมสำหรับเชื่อมกระบวนการเดียวกัน ผู้ตรวจสอบจึงสามารถตามจาก Order ไปยังคำขอ การส่งต่อ และผลตอบกลับได้

หากต้องส่งเหตุการณ์เดิมซ้ำเพราะการเชื่อมต่อขัดข้อง ควรคงตัวระบุที่ทำให้ผู้รับรู้ว่าเป็นการส่งซ้ำ ขณะเดียวกัน เหตุการณ์ที่คนละระบบสังเกตจากคนละมุมก็ยังควรแยกจากกัน การมี Log หลายรายการใน Workflow เดียวจึงอาจช่วยยืนยันความสอดคล้องของกระบวนการได้ — HL7 AuditEvent

เรื่องเวลาก็ต้องแยกให้ชัด โดยเฉพาะ เวลาที่กิจกรรมเกิดขึ้น กับ เวลาที่ระบบรับบันทึกเหตุการณ์ หากข้อมูลส่งมาช้า ทั้งสองเวลาจะช่วยอธิบายความล่าช้าได้ และเมื่อแสดงผลควรระบุเขตเวลาให้ตีความตรงกัน

ทำให้หลักฐานน่าเชื่อถือและป้องกันการแก้ย้อนหลังได้

ความน่าเชื่อถือของ Audit Log ขึ้นกับการควบคุมทั้งเส้นทาง ตั้งแต่สร้างเหตุการณ์ ส่งต่อ จัดเก็บ ไปจนถึงการค้นและส่งออก

แนวทางที่เหมาะกับโรงพยาบาลคือให้แอปพลิเคชันเพิ่มเหตุการณ์ตามหน้าที่ พร้อมแยกอำนาจจัดการหลักฐานออกจากสิทธิ์แก้ไขข้อมูลการใช้งานทั่วไป การอ่าน ส่งออก เปลี่ยนการตั้งค่า หรือจัดการอายุข้อมูล Audit เองก็ควรอยู่ในขอบเขตการตรวจสอบ

ในด้านความครบถ้วน องค์กรอาจใช้การตรวจความถูกต้องของข้อมูลร่วมกับสำเนาที่มีข้อจำกัดการแก้ไข และแยกผู้มีอำนาจดูแลหลักฐานแต่ละส่วน แนวทางป้องกัน Audit จากการเข้าถึง แก้ไข และลบโดยไม่ได้รับอนุญาตอยู่ในกลุ่มควบคุม Audit and Accountability ของ NIST — NIST SP 800-53

การมีค่า Hash เป็นองค์ประกอบหนึ่งของการตรวจสอบ แต่ถ้าผู้เดียวแก้ได้ทั้งข้อมูลและค่าที่ใช้ตรวจสอบ ก็ยังขาดหลักฐานอิสระสำหรับยืนยันความเปลี่ยนแปลง การออกแบบจึงต้องดูสิทธิ์และความเป็นอิสระของหลักฐานร่วมด้วย

เก็บข้อมูลให้พอตรวจสอบ และคุมการเปิดเผยจาก Log

Audit Log อาจกลายเป็นแหล่งข้อมูลสุขภาพที่ละเอียดมากได้ หากเก็บเนื้อหา Request, Response หรือเวชระเบียนทั้งหมดโดยไม่มีขอบเขต

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

รหัสผ่าน Access Token และข้อมูลลับไม่ควรถูกบันทึกตรง ๆ ส่วนข้อมูลส่วนบุคคลควรถูกลด ปกปิด หรือป้องกันตามความจำเป็นของการตรวจสอบ ผู้ที่ค้น Log ได้ก็ควรเห็นข้อมูลตามหน้าที่ของตน — OWASP Logging Cheat Sheet

นี่รวมถึงไฟล์ที่ส่งออกให้ผู้ตรวจสอบด้วย การควบคุมควรติดตามไปถึงสำเนาที่นำออกไปใช้งาน

เตรียมรับวันที่ระบบ Audit มีปัญหา

ระบบ Log อาจรับข้อมูลไม่ทัน การเชื่อมต่ออาจขาด หรือพื้นที่จัดเก็บอาจเต็ม เหตุการณ์เหล่านี้ควรมีการตรวจพบและมีผู้รับผิดชอบตอบสนอง

IHE ระบุแนวทางให้เก็บ Audit Record ไว้ภายในเมื่อส่งไปยังแหล่งรวบรวมไม่ได้ และส่งภายหลังเมื่อกลับมาเชื่อมต่อได้ — IHE: Record Audit Event

เมื่อนำมาใช้กับ HIS ควรออกแบบต่อให้ตอบได้ว่า ธุรกรรมที่บันทึกสำเร็จมีเหตุการณ์ Audit ที่เก็บอย่างทนทานแล้วหรือยัง มีรายการค้างส่งเท่าใด และจะตรวจความครบถ้วนหลังระบบกลับมาได้อย่างไร

การตอบสนองเมื่อ Audit ใช้งานไม่ได้ควรกำหนดร่วมกับเจ้าของกระบวนการ ตัวอย่างเช่น งานส่งออกข้อมูลจำนวนมากอาจถูกพักไว้ตามนโยบาย ขณะที่งานดูแลผู้ป่วยเร่งด่วนต้องมีแผนทำงานต่อและเก็บหลักฐานสำรองที่เหมาะสม

ประเด็นนี้ควรถูกทดสอบก่อนเกิดเหตุจริง ทั้งกรณีรับข้อมูลไม่ทัน ส่งซ้ำ ระบบเริ่มทำงานใหม่ และพื้นที่ใกล้เต็ม

ทำให้ค้นพบเหตุการณ์ที่ควรตรวจสอบ และมีคนรับเรื่องต่อ

โรงพยาบาลควรค้นได้ทั้งจากมุมของผู้ป่วย ผู้ใช้ และรายการงาน เช่น

• ในช่วงเวลาหนึ่ง ใครบ้างที่เข้าถึงข้อมูลผู้ป่วยรายนี้
• Order นี้ผ่านกิจกรรมใดมาบ้าง ก่อนและหลังถูกยกเลิก
• บัญชีหนึ่งส่งออกข้อมูลอะไร จำนวนเท่าใด และใช้สิทธิ์ใด
• มีการใช้สิทธิ์ฉุกเฉินเมื่อใด และได้รับการทบทวนแล้วหรือยัง

เงื่อนไขอย่างการเปิดเวชระเบียนจำนวนมาก การเข้าถึงที่ไม่สอดคล้องกับงาน หรือการใช้สิทธิ์ฉุกเฉินบ่อยครั้ง สามารถใช้เป็นสัญญาณให้ตรวจสอบต่อได้ ผู้ตรวจสอบต้องพิจารณาบริบทก่อนสรุปว่าเป็นการใช้งานผิดวัตถุประสงค์

กระบวนการจึงควรระบุให้ครบว่าใครรับ Alert ใครตรวจสอบ ใครประสานหน่วยงาน และเก็บผลการทบทวนไว้ที่ใด รวมถึงกำหนดระยะเวลาเก็บรักษาตามประเภทข้อมูล ภาระหน้าที่ และความจำเป็นขององค์กร พร้อมทดสอบว่าหลักฐานที่เก็บระยะยาวยังค้นและนำกลับมาใช้ได้จริง แนวคิดการจัดการ Log ตลอดกระบวนการนี้เป็นส่วนหนึ่งของ NIST SP 800-92

เมื่อออกแบบได้ครบ Audit Log จะช่วยให้ทีม IT ต่อเหตุการณ์ย้อนหลังได้อย่างมีหลักฐาน ตั้งแต่ผู้เริ่มคำขอ สิทธิ์ที่ใช้ รายการที่ได้รับผล เหตุผลที่ระบุ ไปจนถึงผลลัพธ์ของแต่ละระบบ

และเมื่อโรงพยาบาลต้องทบทวนเหตุการณ์ คำตอบจะมีทั้งลำดับที่ตรวจสอบได้ บริบทที่อธิบายการทำงาน และขอบเขตที่ชัดเจนว่าหลักฐานยืนยันอะไรได้บ้าง

ตัวอย่างหนึ่งเหตุการณ์: แยกผู้กระทำ เหตุผล และผลลัพธ์

ตัวอย่างสมมติต่อไปนี้ใช้รหัสอ้างอิงแทนข้อมูลผู้ป่วย เพื่อให้เห็นว่าเหตุการณ์เดียวควรมีบริบทอะไรบ้าง

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

Checklist ตรวจ Audit Log ของ HIS ก่อนใช้งานจริง

• ใช้บัญชีทดสอบเปิดอ่าน แก้ไข ส่งออก และถูกปฏิเสธสิทธิ์ แล้วค้นเหตุการณ์ได้ครบ
• แยกผู้ใช้จริง บัญชีบริการ และการทำแทนกันได้
• เห็นรหัสรายการ เวอร์ชันข้อมูล วัตถุประสงค์ เหตุผล และผลลัพธ์ตามที่จำเป็น
• เชื่อมเหตุการณ์ข้ามระบบและแยกเวลาที่เกิดกับเวลาที่รับบันทึกได้
• ทดสอบการแก้หรือลบหลักฐาน และตรวจว่าใครมีสิทธิ์ทำได้
• ตรวจว่า Log ไม่มีรหัสผ่าน Token หรือข้อมูลผู้ป่วยเกินจำเป็น
• จำลองการส่ง Log ขัดข้อง การส่งซ้ำ และพื้นที่เต็ม พร้อมตรวจการแจ้งเตือน
• มีนโยบายอายุข้อมูล ผู้รับเหตุ และขั้นตอนทบทวนเหตุการณ์

อ่านเรื่องที่เกี่ยวข้อง

• Security Design สำหรับ HIS: คุมการเข้าถึงข้อมูลโดยให้โรงพยาบาลทำงานได้ต่อเนื่อง
• DPO กับ Security Officer ในโรงพยาบาล: แบ่งหน้าที่และใช้หลักฐานจาก HIS อย่างไร
• Digital Signature ในโรงพยาบาล: เลือกวิธีลงนามและออกแบบหลักฐานให้ตรวจสอบได้
• PDPA กับความปลอดภัยของ HIS: แปลงนโยบายให้เป็นมาตรการที่ตรวจสอบได้