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

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

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

ทำไมข้อมูลสุขภาพในธุรกิจ SaaS ต้องผ่านมาตรฐานที่สูงกว่า

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

นอกจากฐานความยินยอมแล้ว ทีมวิศวกรและโปรดักต์ต้องคิดเรื่องการควบคุมสิทธิ์เข้าถึงแบบ need-to-know ตั้งแต่ตอนออกแบบสถาปัตยกรรมระบบ พนักงานฝ่ายซัพพอร์ตไม่ควรเห็นประวัติการรักษาเต็มรูปแบบถ้าไม่จำเป็นต่อการแก้ปัญหา และทุกครั้งที่มีการเรียกดูข้อมูลสุขภาพ ควรมี log ที่ระบุว่าใครเข้าถึง เมื่อไหร่ และด้วยเหตุผลอะไร เพราะเมื่อเกิดข้อพิพาทหรือมีการร้องเรียน หลักฐานเหล่านี้คือสิ่งที่พิสูจน์ว่าองค์กรควบคุมความเสี่ยงอย่างจริงจัง ไม่ใช่แค่มีนโยบายเป็นลายลักษณ์อักษรเฉยๆ

เช็กลิสต์ก่อนเปิดใช้งานฟีเจอร์ที่แตะข้อมูลสุขภาพ

รายการต่อไปนี้ควรเป็นเกตที่ทีม Product, Engineering, Growth และ Privacy Team ตรวจร่วมกันก่อนปล่อยฟีเจอร์ใหม่ที่เกี่ยวข้องกับข้อมูลสุขภาพของผู้ใช้ ไม่ใช่แค่ก่อนเปิดตัวโปรดักต์ครั้งแรกเท่านั้น

1. ระบุให้ชัดว่าฟีเจอร์นี้แตะข้อมูลสุขภาพส่วนไหนบ้าง เช่น ผลตรวจ ประวัติการวินิจฉัย ยาที่ใช้ หรือข้อมูลอาการที่ผู้ใช้กรอกเอง แล้วแยกออกจากข้อมูลบัญชีผู้ใช้ทั่วไปให้ชัดในสคีมาฐานข้อมูล
2. ออกแบบหน้าจอขอความยินยอมแบบชัดแจ้งเฉพาะ ไม่รวมไว้ในเงื่อนไขการใช้งานทั่วไปแบบเดียวที่ผู้ใช้ต้องกดยอมรับทั้งก้อน ผู้ใช้ควรเห็นชัดว่ากำลังยินยอมให้เก็บและประมวลผลข้อมูลสุขภาพเป็นการเฉพาะ
3. บันทึกหลักฐานการขอความยินยอม พร้อมเวอร์ชันของข้อความที่ใช้ วันเวลาที่ผู้ใช้กด และช่องทางที่ใช้ยืนยัน เพื่อให้ตรวจสอบย้อนหลังได้หากมีข้อพิพาท
4. กำหนดสิทธิ์เข้าถึงแบบ need-to-know ในระบบภายใน ทีมซัพพอร์ตระดับ Tier 1 ควรเห็นเฉพาะสถานะบัญชี ไม่ใช่รายละเอียดทางการแพทย์ ส่วนทีมที่ต้องเห็นข้อมูลจริงต้องผ่านการอนุมัติเป็นรายกรณี
5. ตรวจสอบว่า log การเข้าถึงข้อมูลสุขภาพเปิดใช้งานจริง ไม่ใช่แค่มีในเอกสารสถาปัตยกรรม ทดสอบด้วยการเข้าถึงจริงหนึ่งครั้งแล้วดูว่า log บันทึกครบตามที่ออกแบบไว้หรือไม่
6. ทบทวนสัญญากับผู้ให้บริการภายนอกที่แตะข้อมูลนี้ เช่น ผู้ให้บริการ cloud storage, บริการแล็บ หรือระบบแจ้งเตือนผ่าน SMS/อีเมล ว่ามีข้อตกลงประมวลผลข้อมูลที่ครอบคลุมข้อมูลอ่อนไหวหรือไม่
7. กำหนดระยะเวลาเก็บรักษาข้อมูลให้สอดคล้องกับลักษณะข้อมูล ข้อมูลสุขภาพบางประเภทอาจต้องเก็บนานกว่าข้อมูลบัญชีทั่วไปตามข้อกำหนดด้านเวชระเบียนที่เกี่ยวข้อง ไม่ใช่ใช้นโยบายลบข้อมูลแบบเดียวกับข้อมูลอื่น
8. เตรียมกระบวนการรองรับสิทธิ์ของเจ้าของข้อมูล เช่น สิทธิ์ขอเข้าถึง ขอแก้ไข หรือขอลบ ให้ทีมสนับสนุนรู้ขั้นตอนและกรอบเวลาที่ต้องตอบกลับ ไม่ใช่ต้องถามฝ่ายกฎหมายทุกครั้งที่มีคำขอเข้ามา
9. ซ้อมแผนตอบสนองเหตุละเมิดข้อมูลที่เจาะจงข้อมูลสุขภาพ รวมถึงว่าใครต้องรู้ก่อน ใครประเมินความรุนแรง และเกณฑ์การแจ้งหน่วยงานกำกับดูแลอยู่ตรงไหน เพราะข้อมูลสุขภาพหลุดสร้างผลกระทบต่อผู้ใช้มากกว่าข้อมูลติดต่อทั่วไป
10. ให้ทีม Privacy หรือที่ปรึกษาด้านกฎหมายตรวจฟีเจอร์ก่อนปล่อยจริง ไม่ใช่ตรวจหลังเปิดใช้งานแล้ว เพราะการแก้ไขสถาปัตยกรรมข้อมูลหลังเปิดตัวมักมีต้นทุนสูงกว่าการตรวจก่อนล่วงหน้ามาก

ตัวอย่างสถานการณ์ที่เจอบ่อยในทีม SaaS สุขภาพ

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

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

ข้อผิดพลาดที่พบบ่อยของทีม SaaS สุขภาพ

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

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

สรุป

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

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

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