Cloud หรือ On-Premise: โรงพยาบาลควรเก็บระบบไว้ที่ไหน

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

หลักคิดสั้น ๆ

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

นิยามให้ตรงกันก่อน

On-Premise เซิร์ฟเวอร์และระบบอยู่ในโรงพยาบาลหรือศูนย์ข้อมูลที่โรงพยาบาลดูแลเอง
Public Cloud ใช้โครงสร้างพื้นฐานของผู้ให้บริการ ในรูปแบบ IaaS, PaaS หรือ SaaS ตามนิยามของ NIST SP 800-145
Private Cloud คลาวด์ที่ใช้เฉพาะองค์กรเดียว ซึ่งอาจตั้งอยู่ในสถานที่ของโรงพยาบาลเองหรือของผู้ให้บริการก็ได้
Hybrid ผสมหลายแบบ เช่น ระบบหลักอยู่ในโรงพยาบาล ส่วนการสำรองข้อมูลหรือบริการบางส่วนอยู่บนคลาวด์

กฎหมายไทยว่าด้วยที่ตั้งข้อมูล

PDPA: ไม่ห้ามคลาวด์ แต่มีเงื่อนไขการโอนข้อมูลไปต่างประเทศ

ข้อมูลสุขภาพเป็นข้อมูลอ่อนไหวตามมาตรา 26 แต่ PDPA ไม่ได้ห้ามเก็บข้อมูลนอกประเทศ สิ่งที่กฎหมายกำหนดคือเงื่อนไขการส่งหรือโอนข้อมูลไปต่างประเทศตามมาตรา 28–29 ซึ่งมีประกาศคณะกรรมการฯ สองฉบับที่มีผลตั้งแต่ 24 มีนาคม 2567 รองรับกลไก เช่น ประเทศปลายทางที่มีมาตรฐานเพียงพอ นโยบายภายในกลุ่มกิจการที่ได้รับการรับรอง (BCR) และสัญญามาตรฐาน จากการตรวจสอบของเรา ยังไม่พบการประกาศรายชื่อประเทศที่มีมาตรฐานเพียงพอ

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

พ.ร.บ.การรักษาความมั่นคงปลอดภัยไซเบอร์ พ.ศ. 2562

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

โรงพยาบาลรัฐกับนโยบาย Cloud First

เมื่อ 16 ธันวาคม 2567 คณะกรรมการที่เกี่ยวข้องมีมติให้สำนักงานพัฒนารัฐบาลดิจิทัล (สพร.) เป็นหน่วยงานหลักในการบริหารจัดการคลาวด์ภาครัฐ และในปี 2568 มีร่างแนวทางการใช้คลาวด์ภาครัฐและการจัดระดับชั้นข้อมูลออกมารับฟังความคิดเห็น ซึ่งยกเวชระเบียนเป็นตัวอย่างข้อมูลระดับ Protected และแนะนำให้เก็บบนคลาวด์ในประเทศพร้อมมาตรการเสริม เอกสารนี้ยังเป็นร่างและมุ่งใช้กับหน่วยงานรัฐ โรงพยาบาลรัฐจึงควรตรวจสอบสถานะล่าสุดกับ สพร. และหน่วยงานต้นสังกัดก่อนตัดสินใจ

ความปลอดภัย: ใครรับผิดชอบอะไร

ผู้ให้บริการคลาวด์รายใหญ่ใช้หลักความรับผิดชอบร่วม (shared responsibility) ผู้ให้บริการดูแลความปลอดภัย “ของ” คลาวด์ เช่น ศูนย์ข้อมูล ฮาร์ดแวร์ และเครือข่าย ส่วนลูกค้าดูแลความปลอดภัย “ใน” คลาวด์ ไม่ว่าจะใช้ IaaS, PaaS หรือ SaaS โรงพยาบาลยังรับผิดชอบข้อมูล บัญชีผู้ใช้ และการตั้งค่าเสมอ ขณะที่ระบบ On-Premise โรงพยาบาลรับผิดชอบทั้งหมดเอง

ระบบทั้งสองแบบถูกโจมตีหรือหยุดชะงักได้ โรงพยาบาลในไทยเคยถูกโจมตีด้วย ransomware เช่น โรงพยาบาลสระบุรีในปี 2563 และโรงพยาบาลอุดรธานีในปี 2566 ส่วนเหตุการณ์อัปเดตซอฟต์แวร์ CrowdStrike ผิดพลาดในเดือนกรกฎาคม 2567 กระทบเครื่อง Windows ทั้งในองค์กรและบนคลาวด์ สิ่งที่ลดความเสียหายได้จริงคือการควบคุมสิทธิ์ การแพตช์ การแยกเครือข่าย และแผนกู้คืน ไม่ใช่ที่ตั้งของเซิร์ฟเวอร์เพียงอย่างเดียว

ความพร้อมใช้งาน: อินเทอร์เน็ต SLA และแผน downtime

SAFER Guide ด้านแผนรองรับเหตุฉุกเฉินของสำนักงานเทคโนโลยีสารสนเทศสุขภาพของสหรัฐฯ (ONC) ระบุว่าระบบเวชระเบียนอิเล็กทรอนิกส์ล่มได้ในทุกสภาพแวดล้อม และแนะนำให้มีเส้นทางอินเทอร์เน็ตสองเส้นทางจากผู้ให้บริการต่างราย มีสำเนาข้อมูลแบบอ่านอย่างเดียวที่ใช้ได้ขณะระบบหลักล่ม และมีแบบฟอร์มกระดาษสำรองพอใช้อย่างน้อย 8 ชั่วโมง ข้อแนะนำเหล่านี้สำคัญยิ่งขึ้นเมื่อระบบอยู่บนคลาวด์ เพราะงานทั้งหมดขึ้นกับการเชื่อมต่อ

SLA ไม่ใช่การรับประกันว่าระบบจะไม่ล่ม เอกสารของ Microsoft อธิบายว่า SLA เป็นข้อผูกพันที่มีเงื่อนไข การชดเชยมักเป็นเครดิตค่าบริการซึ่งไม่ครอบคลุมความเสียหายทางธุรกิจ และระบบที่พึ่งบริการหลายตัวจะมีความพร้อมใช้งานรวมต่ำกว่า SLA ของแต่ละตัว ตัวอย่างเช่น เหตุบริการ AWS ภูมิภาค us-east-1 หยุดชะงักในวันที่ 19–20 ตุลาคม 2568 จากปัญหาระบบ DNS อัตโนมัติ

สำรองข้อมูลและการกู้คืนจาก ransomware

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

โครงสร้างต้นทุน: ไม่ใช่แค่ราคาเซิร์ฟเวอร์

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

On-Premise: เครื่องและไลเซนส์ รอบเปลี่ยนอุปกรณ์ ไฟฟ้าและระบบทำความเย็น พื้นที่ และทีมดูแล
Cloud: ค่าบริการรายเดือน ค่าพื้นที่เก็บข้อมูลและ log ค่าโอนข้อมูลออก และทีมที่ต้องบริหารสิทธิ์และต้นทุนคลาวด์
ทั้งสองแบบ: อินเทอร์เน็ตสำรอง ระบบสำรองข้อมูล การทดสอบกู้คืน และต้นทุนการย้ายออกในอนาคต

ตารางเปรียบเทียบ

ประเด็น	On-Premise	Public Cloud	Hybrid
ความรับผิดชอบด้านความปลอดภัย	โรงพยาบาลดูแลทั้งระบบ	แบ่งกับผู้ให้บริการ แต่ข้อมูล บัญชีผู้ใช้ และการตั้งค่ายังเป็นของโรงพยาบาล	ต้องกำหนดเส้นแบ่งให้ชัดทั้งสองฝั่ง
ที่ตั้งข้อมูลและ PDPA	อยู่ในโรงพยาบาล	เลือกภูมิภาคในประเทศได้ ถ้าอยู่นอกประเทศต้องดูมาตรา 28–29	แยกข้อมูลอ่อนไหวไว้ในที่ที่กำหนดได้
การพึ่งพาอินเทอร์เน็ต	ต่ำสำหรับผู้ใช้ภายใน	สูง ควรมีเส้นทางสำรอง	ปานกลาง
ความพร้อมใช้งาน	ขึ้นกับไฟฟ้า อุปกรณ์ และทีมของโรงพยาบาล	มี SLA แต่ไม่ใช่การรับประกัน ชดเชยเป็นเครดิต	ใช้ฝั่งหนึ่งเป็นสำรองของอีกฝั่งได้
ransomware และสำรองข้อมูล	ต้องจัดสำเนาออฟไลน์เอง	ยังต้องมีสำเนาแยก เพราะการซิงก์อาจทับสำเนาที่ดี	ทำสำเนาข้ามสภาพแวดล้อมได้
ต้นทุน	งบลงทุนก้อนแรกและรอบเปลี่ยนอุปกรณ์	งบดำเนินงานผันแปร มีค่า log และค่าโอนข้อมูลออก	มีทั้งสองแบบ และต้องจัดการความซับซ้อน
ทักษะทีม	ดูแลโครงสร้างพื้นฐาน	ตั้งค่า บริหารสิทธิ์ และบริหารต้นทุนคลาวด์	ต้องมีทั้งสองชุดทักษะ

รูปแบบไฮบริดที่พบบ่อย

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

คำถามก่อนตัดสินใจ

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

คำถามที่พบบ่อย

PDPA ห้ามเก็บข้อมูลผู้ป่วยบนคลาวด์ต่างประเทศหรือไม่

ไม่ห้ามโดยเด็ดขาด แต่ข้อมูลสุขภาพเป็นข้อมูลอ่อนไหว และการโอนข้อมูลไปต่างประเทศต้องเป็นไปตามมาตรา 28–29 และประกาศที่มีผลตั้งแต่ 24 มีนาคม 2567 ควรให้ฝ่ายกฎหมายพิจารณาเป็นกรณี

ย้ายขึ้นคลาวด์แล้วไม่ต้องสำรองข้อมูลเองใช่ไหม

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

SLA 99.9% แปลว่าระบบจะไม่ล่มใช่ไหม

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

On-Premise ปลอดภัยกว่าเสมอไหม

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