คำว่า Decentralized Healthcare มักถูกอธิบายว่าเป็นระบบสุขภาพที่กระจายศูนย์ แต่คำนี้ไม่ได้หมายความว่าต้องนำเวชระเบียนไปกระจายเก็บบน blockchain หรือมอบหน้าที่ดูแลข้อมูลทั้งหมดให้ผู้ป่วย แนวคิดที่ใช้ได้จริงคือการแยกความรับผิดชอบของแต่ละส่วนออกจากกัน แล้วเชื่อมส่วนเหล่านั้นด้วยมาตรฐานและกติกาที่ตรวจสอบได้
โรงพยาบาลยังคงควบคุมเวชระเบียนทางคลินิก ผู้ป่วยมีส่วนกำหนดการให้สิทธิ์เข้าถึงตามขอบเขตที่ระบบและกฎหมายรองรับ ระบบแลกเปลี่ยนข้อมูลทำหน้าที่ส่งเฉพาะข้อมูลที่ได้รับอนุญาต ส่วนประวัติความยินยอมและการเข้าถึงสามารถบันทึกในชั้นตรวจสอบที่แยกจากข้อมูลทางคลินิก
จากระบบรวมศูนย์สู่การแบ่งความรับผิดชอบ
ระบบรวมศูนย์ไม่ได้ผิดโดยตัวมันเอง โรงพยาบาลต้องมีระบบที่เชื่อถือได้สำหรับจัดเก็บและใช้งานเวชระเบียนของตน ปัญหาเกิดขึ้นเมื่อการเชื่อมต่อระหว่างผู้ให้บริการต้องพึ่งจุดกลางเพียงจุดเดียว หรือเมื่อผู้ป่วยไม่เห็นว่าข้อมูลถูกขอใช้ภายใต้เงื่อนไขใด
ระบบแบบกระจายความรับผิดชอบอาจมีหลายองค์ประกอบ เช่น แหล่งข้อมูลภายในโรงพยาบาล บริการยืนยันตัวตน กลไกให้สิทธิ์ มาตรฐานแลกเปลี่ยนข้อมูล และบันทึกสำหรับตรวจสอบ ไม่มีองค์ประกอบใดจำเป็นต้องรู้หรือเก็บข้อมูลทุกอย่าง การออกแบบเช่นนี้ช่วยกำหนดขอบเขตความเสียหายเมื่อส่วนหนึ่งมีปัญหา แต่ไม่ได้ขจัดความเสี่ยงด้านความปลอดภัย
สิ่งที่เก็บอยู่ที่ไหน
ในรูปแบบของ HealthTAG เวชระเบียนยังอยู่ในระบบที่โรงพยาบาลควบคุม ข้อมูลที่ต้องแลกเปลี่ยนถูกจัดให้อยู่ในรูปแบบ HL7 FHIR R4 ภายในสภาพแวดล้อมของโรงพยาบาล ผ่านสคริปต์ที่ฝ่ายไอทีโรงพยาบาลดูแลหรือ HealthTAG FHIR Transformer ตามรูปแบบการติดตั้ง
HealthTAG Module หรือ Hospital API ทำงานภายในเครือข่ายโรงพยาบาลเพื่อรองรับการเชื่อมโยงตัวตนและตรวจสอบการอนุญาต เมื่อแอปพลิเคชันหรือ PHR ขอข้อมูล ระบบจะตรวจสิทธิ์ก่อนส่งข้อมูลที่อยู่ในขอบเขตการอนุญาต เวชระเบียนไม่ผ่านและไม่ถูกเก็บบน blockchain
Data sovereignty ในบริบทสุขภาพ
Data sovereignty ในบทความนี้หมายถึงการทำให้ผู้ป่วยมีสิทธิ์และความสามารถที่ชัดเจนในการเข้าถึงข้อมูลเกี่ยวกับตนเอง รวมถึงมีส่วนกำหนดว่าใครใช้ข้อมูลเพื่อวัตถุประสงค์ใด แนวคิดนี้ต้องทำงานร่วมกับหน้าที่ของโรงพยาบาล กฎหมายคุ้มครองข้อมูล และข้อกำหนดในการดูแลรักษา
การเรียกผู้ป่วยว่าเป็น “เจ้าของเวชระเบียน” อาจทำให้เข้าใจผิด เพราะเวชระเบียนอยู่ภายใต้การควบคุมและความรับผิดชอบของโรงพยาบาล สิ่งที่ระบบควรทำคือทำให้สิทธิ์ของผู้ป่วยใช้งานได้จริง เช่น ดูข้อมูลที่เปิดให้เข้าถึง ขอส่งต่อข้อมูล และจัดการความยินยอมในกรณีที่ต้องอาศัยความยินยอม
การให้สิทธิ์แบบมีขอบเขต
การอนุญาตไม่จำเป็นต้องเป็นคำตอบแบบให้ทั้งหมดหรือไม่ให้เลย ระบบสามารถกำหนดขอบเขตตามชนิดข้อมูล ผู้ขอใช้ วัตถุประสงค์ และระยะเวลาได้ ตัวอย่างเช่น ผู้ป่วยอาจอนุญาตให้บุคลากรที่ยืนยันตัวตนแล้วดูข้อมูลรายการหนึ่งในช่วงเวลาที่กำหนด
สถาปัตยกรรม HealthTAG ปัจจุบันกำหนดช่วงเข้าถึง 15 นาทีจากสถานะบน blockchain และให้ Hospital API ตรวจสอบสถานะนั้น การหมดอายุของสิทธิ์ลดโอกาสที่การอนุญาตจะเปิดค้างไว้นานเกินความจำเป็น แต่ทีมระบบยังต้องดูแลการยืนยันตัวตน การเพิกถอนสิทธิ์ บันทึกเหตุการณ์ และกรณีฉุกเฉินอย่างเหมาะสม
Blockchain เป็นบันทึกตรวจสอบ ไม่ใช่คลังเวชระเบียน
Blockchain เหมาะกับการบันทึกเหตุการณ์ที่หลายฝ่ายต้องตรวจสอบร่วมกัน เช่น การให้ความยินยอมหรือการเข้าถึงตามสิทธิ์ เมื่อออกแบบและดำเนินการอย่างถูกต้อง โครงสร้างของบัญชีรายการจะช่วยให้ตรวจพบการแก้ไขย้อนหลังได้ง่ายขึ้น
อย่างไรก็ตาม ไม่ควรเขียนข้อมูลสุขภาพที่ละเอียดอ่อนลงในบัญชีรายการดังกล่าว เพราะข้อมูลบน blockchain ลบหรือแก้ไขได้ยาก HealthTAG จึงแยกข้อมูลทางคลินิกออกจากชั้นบันทึกเหตุการณ์ การเข้ารหัสเพียงอย่างเดียวก็ไม่ใช่เหตุผลเพียงพอที่จะนำเวชระเบียนไปเก็บบน blockchain
ประโยชน์ต่อการดูแลต่อเนื่อง
เมื่อผู้ให้บริการใช้มาตรฐานข้อมูลร่วมกันและมีวิธีตรวจสิทธิ์ที่ชัดเจน ผู้ป่วยไม่จำเป็นต้องเริ่มต้นใหม่ทุกครั้งที่เปลี่ยนสถานพยาบาล ทีมรักษาสามารถขอข้อมูลที่เกี่ยวข้องตามความจำเป็น และผู้ป่วยสามารถดูข้อมูลที่ได้รับอนุญาตผ่าน PHR ได้
การแลกเปลี่ยนที่ดีช่วยลดงานซ้ำและทำให้ข้อมูลสำคัญพร้อมใช้เร็วขึ้น แต่ผลลัพธ์ขึ้นอยู่กับคุณภาพข้อมูล การจับคู่ตัวตน และข้อตกลงระหว่างองค์กร คำว่า interoperability จึงไม่ได้หมายถึงเพียงเชื่อม API สำเร็จ แต่รวมถึงการที่ผู้รับเข้าใจข้อมูลตรงกับผู้ส่ง
การใช้งานอื่นที่ต้องแยกจาก HealthTAG
ในวงการมีการเสนอให้ใช้ blockchain และ smart contract กับงานวิจัย การชำระเงิน ประกันสุขภาพ และการติดตามห่วงโซ่อุปทานยา แนวคิดเหล่านี้อาจใช้ประโยชน์จากบันทึกที่ตรวจสอบย้อนหลังได้หรือเงื่อนไขอัตโนมัติ แต่แต่ละกรณีต้องมีแหล่งข้อมูลที่เชื่อถือได้ การกำกับดูแล และการตรวจสอบข้อผิดพลาดของตนเอง
ในงานวิจัย ผู้เข้าร่วมอาจเลือกอนุญาตให้ใช้ข้อมูลที่ลดการระบุตัวบุคคลสำหรับโครงการและช่วงเวลาที่ระบุไว้ ข้อตกลงอาจรวมค่าตอบแทนหรือประโยชน์ที่ผู้เข้าร่วมจะได้รับ และ smart contract อาจช่วยบันทึกการทำตามเงื่อนไขเหล่านั้น ตัวโครงการยังต้องผ่านการพิจารณาด้านจริยธรรม ระบุวิธีถอนความยินยอม และควบคุมความเสี่ยงที่ข้อมูลจะถูกเชื่อมกลับไปหาบุคคล
คำว่า “ผู้ป่วยถือกุญแจ” ควรอธิบายตามสถาปัตยกรรมที่ใช้จริง ผู้ป่วยจัดการสิทธิ์ผ่านขั้นตอนการอนุญาต โรงพยาบาลควบคุมเวชระเบียน และระบบที่เกี่ยวข้องดูแลกุญแจกับข้อมูลรับรองตามหน้าที่ของตน การควบคุมสิทธิ์ไม่ได้หมายความว่าอุปกรณ์ของผู้ป่วยถือกุญแจสำหรับเวชระเบียนทั้งหมด
กรณีเหล่านี้เป็นตัวอย่างของ Decentralized Healthcare โดยทั่วไป ไม่ใช่คำยืนยันว่าเป็นความสามารถหรือการติดตั้งของ HealthTAG ในปัจจุบัน ขอบเขตของ HealthTAG ที่อธิบายได้จากเอกสารทางการอยู่ที่การเชื่อมข้อมูล FHIR การเชื่อมโยงตัวตน การอนุญาต การตรวจสอบการเข้าถึง และประสบการณ์ PHR
Decentralized Healthcare ที่มีประโยชน์จึงไม่ใช่ระบบที่ไม่มีผู้รับผิดชอบ แต่เป็นระบบที่กำหนดความรับผิดชอบอย่างชัดเจน โรงพยาบาลควบคุมเวชระเบียน ผู้ป่วยใช้สิทธิ์ของตนผ่านช่องทางที่เข้าใจได้ และทุกฝ่ายแลกเปลี่ยนเฉพาะข้อมูลที่จำเป็นภายใต้การอนุญาตที่ตรวจสอบได้
แหล่งข้อมูล
- บทความต้นฉบับใน HealthTAG CMS (HealthTAG)
- Data Source Node architecture (HealthTAG)