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

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

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

ขั้นตอนที่ 1: จำแนกข้อมูลสุขภาพออกจากข้อมูลผู้ใช้ทั่วไปให้ชัดในระดับสคีมา

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

ขั้นตอนที่ 2: ออกแบบฐานความยินยอมแบบชัดแจ้งแยกจากเงื่อนไขการใช้งานทั่วไป

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

ขั้นตอนที่ 3: กำหนดสิทธิ์เข้าถึงแบบ need-to-know และเปิดใช้งาน log จริง

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

ขั้นตอนที่ 4: ทบทวนสัญญากับผู้ให้บริการภายนอกที่แตะข้อมูลสุขภาพ

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

ขั้นตอนที่ 5: กำหนดระยะเวลาเก็บรักษาและกระบวนการลบข้อมูลที่เหมาะสม

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

ขั้นตอนที่ 6: เตรียมแผนรับมือเหตุละเมิดข้อมูลที่ซ้อมจริง

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

ทำไมหกขั้นตอนนี้ต้องทำเรียงลำดับ ไม่ใช่เลือกทำเฉพาะข้อที่สะดวก

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

ข้อผิดพลาดที่พบบ่อยเมื่อวางระบบแบบนี้

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

สรุป

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

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

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