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

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

ทำไมธุรกิจสุขภาพต้องมี Vendor Management ที่เข้มกว่าธุรกิจทั่วไป

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

เช็กลิสต์ 8 หมวด ก่อนเปิดใช้งาน Vendor

1. ระบุขอบเขตข้อมูลที่ Vendor จะเข้าถึง

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

2. ตรวจสัญญาประมวลผลข้อมูล (Data Processing Agreement)

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

3. ขอรายชื่อ Sub-processor ที่ Vendor ใช้งานต่อ

vendor หลายรายไม่ได้ประมวลผลข้อมูลเองทั้งหมด แต่ส่งต่อให้ผู้ให้บริการรายอื่น เช่น cloud hosting บริษัท backup หรือทีม support ต่างประเทศ ทีมจัดซื้อควรขอรายชื่อ sub-processor ทั้งหมดพร้อมประเทศที่ตั้งเซิร์ฟเวอร์ และให้ vendor แจ้งล่วงหน้าหากมีการเปลี่ยนแปลง sub-processor ในอนาคต

4. ประเมินมาตรการความปลอดภัยของ Vendor

ใช้แบบสอบถามความปลอดภัย (security questionnaire) ถาม vendor เรื่องการเข้ารหัสข้อมูล การควบคุมสิทธิ์การเข้าถึง การทำ backup การทดสอบเจาะระบบ และใบรับรองมาตรฐานที่มี เช่น ISO 27001 หากไม่มีใบรับรอง ให้พิจารณาว่ามีมาตรการทดแทนที่เพียงพอหรือไม่ก่อนอนุมัติ

5. ตรวจแผนรับมือเหตุการณ์ผิดปกติและการแจ้งเตือน

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

6. สิทธิ์ในการตรวจสอบ (Audit Right)

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

7. แผนคืนหรือลบข้อมูลเมื่อเลิกใช้งาน

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

8. กำหนดผู้รับผิดชอบภายในตลอดอายุความสัมพันธ์

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

ตัวอย่าง Evidence ที่ควรเก็บไว้เป็นหลักฐาน

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

• สัญญาประมวลผลข้อมูลฉบับลงนามและเวอร์ชันที่เคยแก้ไข
• แบบสอบถามความปลอดภัยที่ vendor กรอกและตอบกลับ
• ใบรับรองมาตรฐานความปลอดภัย เช่น ISO 27001 หรือรายงานตรวจสอบภายนอก
• รายชื่อ sub-processor และประวัติการเปลี่ยนแปลง
• บันทึกการตรวจสอบประจำปีและผลการทบทวนความเสี่ยง
• อีเมลหรือเอกสารยืนยันการคืน/ลบข้อมูลเมื่อเลิกใช้งาน (สำหรับ vendor ที่เลิกใช้ไปแล้ว)

การเก็บ evidence เหล่านี้ควรทำควบคู่กับการจัดทะเบียนกิจกรรมการประมวลผลข้อมูล (ROPA) ที่ระบุว่าแต่ละกิจกรรมมีการส่งต่อข้อมูลให้ vendor รายใดบ้าง เพื่อให้เห็นภาพรวมทั้งระบบในที่เดียว

ข้อผิดพลาดที่พบบ่อยในการตรวจสอบ Vendor ของธุรกิจสุขภาพ

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

เชื่อมโยงกับกระบวนการอื่นในองค์กร

Vendor Management ไม่ได้ทำงานแยกเดี่ยว แต่ควรเชื่อมกับกระบวนการอื่น เช่น ตารางเวลาการเก็บและลบข้อมูลที่อธิบายไว้ในแนวทาง Data Retention สำหรับธุรกิจสุขภาพ เพราะเมื่อ vendor คืนหรือลบข้อมูล ต้องสอดคล้องกับตารางเวลาที่องค์กรกำหนดไว้เอง รวมถึงการจัดทำแผนที่ข้อมูล (data mapping) ที่ช่วยให้เห็นว่าข้อมูลไหลไปหา vendor รายใดบ้างตั้งแต่ต้นทาง

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

สรุป

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

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

บทความนี้อ้างอิงแนวทางจาก NIST Privacy Framework เกี่ยวกับการบริหารความเสี่ยงด้านความเป็นส่วนตัวจากบุคคลที่สาม องค์กรควรปรับใช้ให้เหมาะกับบริบทและกฎหมายที่บังคับใช้ในประเทศของตน และควรปรึกษาที่ปรึกษากฎหมายเฉพาะทางประกอบการตัดสินใจ