ข้อมูลสุขภาพดิจิทัลต้องเดินทางข้ามระบบหลายชุด โรงพยาบาลต้องเก็บเวชระเบียนไว้ในระบบที่ตนควบคุม ขณะที่แพทย์และผู้ป่วยต้องเข้าถึงข้อมูลที่จำเป็นโดยมีสิทธิ์ชัดเจน ปัญหานี้จึงไม่ได้แก้ด้วยเทคโนโลยีชนิดเดียว แต่ต้องแยกหน้าที่ของการจัดเก็บ การเชื่อมต่อ การอนุญาต และการตรวจสอบออกจากกัน
ในสถาปัตยกรรมของ HealthTAG blockchain มีหน้าที่ด้านสิทธิ์และประวัติการเข้าถึง ไม่ได้เป็นที่เก็บเวชระเบียน การแยกขอบเขตนี้สำคัญกว่าคำว่า “กระจายศูนย์” เพราะทำให้เห็นว่าใครควบคุมข้อมูล และระบบใดรับผิดชอบงานแต่ละส่วน
เวชระเบียนยังอยู่กับโรงพยาบาล
โรงพยาบาลเป็นผู้ควบคุมเวชระเบียน ข้อมูลจากระบบ HIS ถูกแปลงให้อยู่ในรูปแบบ HL7 FHIR R4 แล้วจัดเก็บใน FHIR Server ภายใต้ขอบเขตของโรงพยาบาล การนำข้อมูลเข้าสู่ FHIR ทำได้สองทาง โรงพยาบาลอาจใช้สคริปต์ของทีม IT เอง หรือใช้ HealthTAG FHIR Transformer สำหรับทรัพยากรที่กำหนดไว้ในการติดตั้งนั้น
FHIR ช่วยให้ระบบต่างกันสื่อสารด้วยโครงสร้างข้อมูลที่ตกลงร่วมกัน แต่ FHIR ไม่ได้ตัดสินว่าใครมีสิทธิ์อ่านข้อมูล และไม่ได้แทนมาตรการด้านการยืนยันตัวตน เครือข่าย หรือการปฏิบัติการของโรงพยาบาล
การเชื่อมตัวตนกับการตรวจสิทธิ์เป็นคนละงาน
ผู้ป่วยคนเดียวกันอาจมีรหัสประจำตัวต่างกันในแต่ละโรงพยาบาล ระบบเชื่อมตัวตนผู้ป่วยจับคู่รหัสเหล่านั้นกับตัวระบุกลาง ข้อมูลการเชื่อมโยงจัดเก็บในฐานข้อมูลบน Cloud งานส่วนนี้ช่วยจับคู่ข้อมูลของบุคคลเดียวกันระหว่างผู้ให้บริการ โดยไม่ย้ายเวชระเบียนออกจากระบบของโรงพยาบาล
เมื่อแอป PHR ขอข้อมูล Hospital API จะตรวจว่าคำขอนั้นอยู่ในช่วงเวลาที่ได้รับอนุญาตหรือไม่ ระบบปัจจุบันใช้ช่วงเวลา 15 นาทีซึ่งกำหนดจากสถานะบน blockchain หากสิทธิ์ยังใช้ได้ Hospital API จึงขอข้อมูล FHIR จากระบบโรงพยาบาลและส่งกลับไปยังแอปที่ได้รับอนุญาต
Blockchain บันทึกเหตุการณ์ ไม่ได้ขนส่งเวชระเบียน
Blockchain เหมาะกับข้อมูลที่ต้องการประวัติย้อนหลังซึ่งแก้ไขได้ยาก ใน HealthTAG ข้อมูลประเภทนั้นคือเหตุการณ์การให้ความยินยอมและการเข้าถึง บันทึกนี้ช่วยตอบคำถามว่ามีการให้สิทธิ์หรือเรียกใช้สิทธิ์เมื่อใด
สิ่งที่ไม่ถูกบันทึกบน blockchain คือผลตรวจ รายการยา ประวัติการแพ้ หรือเวชระเบียนทางคลินิกอื่น ข้อมูลเหล่านี้อยู่ใน FHIR Server ของโรงพยาบาล และเดินทางผ่าน API เมื่อมีคำขอที่ผ่านการตรวจสิทธิ์ การพูดว่า blockchain “เก็บข้อมูลสุขภาพอย่างปลอดภัย” จึงกว้างเกินกว่าระบบที่ใช้งานจริง
การเข้ารหัสไม่ได้ทำให้ระบบปลอดภัยโดยลำพัง
โครงสร้างแบบ hash-linked ช่วยให้ตรวจพบการแก้ไขประวัติย้อนหลังได้ง่ายขึ้น แต่ความปลอดภัยของระบบสุขภาพยังต้องอาศัยมาตรการอื่นนอกเหนือจากบัญชีแยกประเภท Kong API Gateway เป็นขอบเขตสำหรับ TLS และการยืนยันตัวตนในระบบฝั่งโรงพยาบาล ส่วนการจัดการข้อมูลรับรอง การตั้งค่า firewall การเข้ารหัสข้อมูล และการปฏิบัติงานของโรงพยาบาลเป็นมาตรการคุ้มครองในส่วนอื่น
คำว่า immutable จึงไม่ควรถูกตีความว่า “ไม่มีทางผิดพลาด” หากระบบรับข้อมูลผิด บัญชีผู้ใช้ถูกยึด หรือกำหนดสิทธิ์กว้างเกินไป blockchain ไม่ได้แก้ปัญหาเหล่านั้นโดยอัตโนมัติ การออกแบบต้องควบคุมทั้งข้อมูลนำเข้า สิทธิ์ของผู้ใช้ และวิธีตอบสนองเมื่อเกิดเหตุผิดปกติ
Smart contract และกฎการเข้าถึง
Smart contract คือโค้ดที่ประมวลผลตามเงื่อนไขบนเครือข่าย blockchain แนวคิดนี้ใช้กำหนดกฎที่ตรวจสอบซ้ำได้ เช่น สถานะการให้สิทธิ์และระยะเวลาที่สิทธิ์มีผล แต่โค้ดไม่สามารถตัดสินบริบททางการแพทย์แทนบุคลากร และไม่ควรส่งเวชระเบียนไปเก็บบนเครือข่าย
Hospital API ตรวจช่วงเวลา 15 นาทีจากสถานะบน blockchain และ blockchain เก็บเหตุการณ์การให้ความยินยอมกับการเข้าถึง รายละเอียดการเรียกใช้ smart contract ขึ้นอยู่กับระบบรุ่นที่ใช้งานจริง
ระบบกระจายความรับผิดชอบอย่างไร
คำว่า decentralized ในบริบทนี้ไม่ได้หมายความว่าเวชระเบียนถูกทำสำเนาไปยังทุก node แต่หมายถึงการไม่รวมหน้าที่ทั้งหมดไว้ในฐานข้อมูลเดียว โรงพยาบาลดูแลเวชระเบียน ระบบเชื่อมตัวตนช่วยจับคู่ผู้ป่วย Hospital API ตรวจสิทธิ์ และ blockchain เก็บประวัติการอนุญาตกับการเข้าถึง
เมื่อแต่ละส่วนมีขอบเขตชัดเจน ผู้ใช้งานจึงตรวจสอบได้ว่าข้อมูลอยู่ที่ไหน ใครเป็นผู้ควบคุม และเทคโนโลยีแต่ละชิ้นช่วยงานใด นี่คือพื้นฐานของการแลกเปลี่ยนข้อมูลสุขภาพที่รับผิดชอบได้ มากกว่าการนำ blockchain ไปใช้กับข้อมูลทุกประเภท
แหล่งข้อมูล
- โพสต์ต้นฉบับวันที่ 18 พฤศจิกายน 2568 (HealthTAG)
- บทความในคลัง CMS ของ HealthTAG (HealthTAG)
- สถาปัตยกรรม Data Source Node (HealthTAG)
