วิธี Audit PDPA สำหรับธุรกิจสุขภาพ ของธุรกิจ SaaS สตาร์ทอัพ และบริษัทเทคโนโลยี พร้อม Evidence ที่ควรเก็บ

ทีม Privacy ของ Healthtech SaaS รายหนึ่งเคยนับพบว่าในหนึ่งไตรมาส มีพนักงานฝ่ายขายและฝ่าย Support รวมกันมากกว่า 40 คนที่ยังมีสิทธิ์เปิดดูประวัติการรักษาของผู้ป่วยในระบบ ทั้งที่งานของพวกเขาไม่จำเป็นต้องเห็นข้อมูลระดับนั้นเลยแม้แต่คนเดียว ตัวเลขนี้ไม่ใช่เรื่องแปลกสำหรับ SaaS ที่โตเร็ว เพราะทีมมักเปิดสิทธิ์กว้างไว้ก่อนตอน Onboarding ลูกค้าใหม่แล้วลืมปิดทีหลัง นี่คือเหตุผลที่การ Audit PDPA สำหรับธุรกิจสุขภาพต้องเป็นรอบตรวจสอบต่อเนื่อง ไม่ใช่ทำครั้งเดียวตอน Launch แล้วจบ เพราะจำนวนคนที่เข้าถึงข้อมูลสุขภาพมักเพิ่มขึ้นเงียบ ๆ ตามการเติบโตของทีมและจำนวนลูกค้า

ทำไมข้อมูลสุขภาพในผลิตภัณฑ์ SaaS ต้องตรวจเข้มกว่าข้อมูลทั่วไป

ข้อมูลที่ผลิตภัณฑ์ Healthtech SaaS เก็บ เช่น ประวัติการรักษา ผลตรวจแล็บ ข้อมูลการสั่งยา หรือข้อมูลเคลมประกันสุขภาพ ถือเป็นข้อมูลอ่อนไหวตามหลัก PDPA ซึ่งมีมาตรฐานสูงกว่าข้อมูลลูกค้าทั่วไปอย่างชื่อและอีเมล การประมวลผลข้อมูลกลุ่มนี้ส่วนใหญ่ต้องอาศัยความยินยอมที่ชัดเจนของเจ้าของข้อมูล ไม่ใช่แค่อาศัยฐานทางกฎหมายทั่วไปแบบข้อมูลลูกค้าทั่วไปที่บางกรณีไม่ต้องขอความยินยอมตรง ๆ ก็ทำได้ เมื่อฐานที่ใช้ต่างกัน การตรวจสอบว่าฐานความยินยอมยังถูกต้องอยู่จึงต้องเข้มกว่า และความเสียหายหากข้อมูลรั่วไหลก็สูงกว่ามาก เพราะข้อมูลสุขภาพที่หลุดออกไปกระทบต่อชื่อเสียงและความเป็นส่วนตัวของผู้ป่วยในระดับที่ต่างจากข้อมูลติดต่อทั่วไป

สิ่งที่ต้องตรวจในรอบ Audit ที่ 1 ฐานความยินยอมของข้อมูลสุขภาพ

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

สิ่งที่ต้องตรวจในรอบ Audit ที่ 2 สิทธิ์การเข้าถึงข้อมูลของพนักงาน

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

สิ่งที่ต้องตรวจในรอบ Audit ที่ 3 สัญญากับ Vendor และพันธมิตรภายนอก

Healthtech SaaS ส่วนใหญ่ต้องแชร์ข้อมูลกับบุคคลที่สาม เช่น ห้องแล็บที่ประมวลผลตรวจเลือด บริษัทประกันที่รับเคลม หรือแพทย์เฉพาะทางที่รับส่งต่อผู้ป่วย ทุกจุดเชื่อมต่อเหล่านี้ควรมีข้อตกลงคุ้มครองข้อมูลเป็นลายลักษณ์อักษรกำกับ ระบุขอบเขตการใช้ข้อมูล มาตรการรักษาความปลอดภัยขั้นต่ำ และหน้าที่แจ้งเหตุหากฝั่ง Vendor เกิดเหตุข้อมูลรั่วไหล ทีม Audit ควรมีตารางรายชื่อ Vendor ทั้งหมดพร้อมสถานะสัญญาแต่ละราย และทบทวนว่ามี Vendor รายใหม่ที่เชื่อมต่อเข้ามาโดยยังไม่มีสัญญากำกับหรือไม่ในทุกรอบตรวจสอบ นอกจากห้องแล็บและบริษัทประกันแล้ว หลายทีมยังลืมตรวจ Vendor ชั้นรองที่ห้องแล็บหรือบริษัทประกันส่งข้อมูลต่อไปอีกทอด เช่น ผู้ให้บริการ Cloud Storage ที่ห้องแล็บใช้เก็บผลตรวจ ซึ่งอยู่นอกสายตาของทีม Product โดยตรงแต่ยังนับเป็นส่วนหนึ่งของห่วงโซ่ข้อมูลสุขภาพที่ต้องตรวจสอบด้วยเช่นกัน

สิ่งที่ต้องตรวจในรอบ Audit ที่ 4 ระยะเวลาเก็บรักษาและการลบข้อมูลสุขภาพ

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

สิ่งที่ต้องตรวจในรอบ Audit ที่ 5 ความพร้อมรับมือเหตุข้อมูลรั่วไหล

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

ตัวอย่างสถานการณ์จากการ Audit จริง

ทีม Privacy ของ Healthtech SaaS อีกรายหนึ่งพบระหว่างรอบ Audit ประจำไตรมาสว่า Vendor ห้องแล็บที่เชื่อมต่อ API มาตั้งแต่ปีก่อนได้เปลี่ยนผู้ให้บริการ Cloud Storage ไปแล้วโดยไม่ได้แจ้งทีม Privacy ฝั่งตน ทำให้สัญญาคุ้มครองข้อมูลฉบับเดิมไม่ครอบคลุมผู้ให้บริการรายใหม่ที่ Vendor เปลี่ยนไปใช้ กรณีนี้ไม่ได้เกิดจากความตั้งใจของฝ่ายใดฝ่ายหนึ่ง แต่เกิดจากไม่มีรอบตรวจสอบที่บังคับให้ Vendor แจ้งการเปลี่ยนแปลงโครงสร้างระบบหลังบ้านให้ทีมทราบ ทีม Audit จึงต้องเพิ่มเงื่อนไขในสัญญาฉบับใหม่ให้ Vendor แจ้งการเปลี่ยนแปลงผู้ให้บริการช่วงที่สามทุกครั้งก่อนเริ่มใช้งานจริง

Evidence ที่ควรเก็บไว้หลังทุกรอบ Audit

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

ข้อผิดพลาดที่พบบ่อยเมื่อทีม SaaS ตรวจ PDPA ด้านข้อมูลสุขภาพ

• ตรวจแค่ตอน Launch ผลิตภัณฑ์ครั้งเดียว แล้วไม่มีรอบตรวจซ้ำทั้งที่ทีมและจำนวนลูกค้าเติบโตขึ้นเรื่อย ๆ
• เปิดสิทธิ์เข้าถึงข้อมูลสุขภาพให้ทีม Support หรือ Sales กว้างเกินความจำเป็นตอน Onboarding แล้วลืมจำกัดสิทธิ์ทีหลัง
• เชื่อว่าการเข้ารหัสข้อมูล (Encryption) เพียงอย่างเดียวเพียงพอสำหรับข้อมูลสุขภาพทุกกรณี ทั้งที่มาตรการเชิงเทคนิคใด ๆ ก็ยังมีความเสี่ยงตกค้างอยู่เสมอ ไม่ว่าจะวางระบบดีแค่ไหน จึงต้องควบคุมสิทธิ์การเข้าถึงและตรวจ Log ควบคู่กันไปด้วยเสมอ
• ไม่มีเอกสารสรุปผลการ Audit แต่ละรอบ ทำให้ตรวจสอบย้อนหลังไม่ได้ว่าเคยแก้ไขอะไรไปแล้วบ้าง

สรุปตารางรอบ Audit ที่แนะนำ

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

การฝึกอบรมทีมงานที่เข้าถึงข้อมูลสุขภาพ

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

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

แหล่งข้อมูลอ้างอิง

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