Data ฝั่งด้านสุขภาพเป็นอีกกลุ่ม Data ที่แม้จะไม่ได้สำคัญเท่ากับข้อมูลด้าน Big Data ฝั่ง Business ในการทำ Business Data Driven Solutions แต่ก็เริ่มมีความสำคัญมากขึ้นเรื่อย ๆ ตามการเติบโตของ ธุรกิจ Wellness และ Healthcare การมาของสังคมผู้สูงอายุ การย้ายถิ่นฐานของประชากร ทั้งฐาวร ท่องเที่ยว รวมถึงการเติบโตในเทคโนโลยีทางการแพทย์ที่จำเป็นต้องใช้ Data ของผู้ป่วยมาเป็นส่วนหนึ่งในการ วินิจฉัยและเพิ่มโอกาสใหม่ ๆ ในการรักษา รองรับอนาคตโรคอุบัติใหม่ โรคที่ยังหาทางรักษาไม่หายขาด หรือกลุ่มบริการที่เป็นการเฝ้าระวังด้านสุขภาพ Preventive Healthcare ก็ต้องการ Data ที่แข้มข้น และ Real-time มากขึ้น
ผู้ป่วยเอง ก็ต้องการเทคโนโลยีเฝ้าติดตามสุขภาพของตนเอง เพื่อป้องกันโรคในอนาคต ลดความเสี่ยงด้านสุขภาพ และพร้อมที่จะเอาข้อมูลของตัวเอง ไปใช้กับเทคโนโลยีใหม่ ๆ ในการรักษา รวมถึงการรับการรักษาจากแพทย์ และบริการทางการแพทย์ต่าง ๆ ที่มีความเชี่ยวชาญเฉพาะ อยู่ทั่วโลก การสามารถนำประวัติสุขภาพการรักษาของตัวเอง ส่งต่อ ไปยังบริการต่าง ๆ ก็ยิ่งทวีความสำคัญ
Impact เรื่องสุขภาพนี้ทำให้มาตรฐาน การเก็บข้อมูล สำคัญกับโลกเทคโนโลยีอย่างมากครับ นอกจากกฏหมายที่เกี่ยวข้องกับข้อมูลคนไข้ การเก็บรักษา หรือ กฏหมายข้อมูลส่วนบุคคลประเทศต่าง ๆ ในฐานะที่ทำงานบริษัท Data และเชี่ยวชาญในธุรกิจ Healthcare เราได้รับโจทย์ แบบนี้มากขึ้นเรื่อย ๆ ทั้งเรื่องมาตรฐาน และความปลอดภัยของการเก็บรักษาข้อมูล Sensitive Data เหล่านี้
ในช่วง 20 ปีที่ผ่านมา วงการสาธารณสุขได้เปลี่ยนแปลงไปอย่างมาก การเข้าถึงข้อมูลสุขภาพที่สำคัญ และต้องทำให้การแบ่งปันข้อมูลทางการแพทย์เป็นไปอย่างปลอดภัย
Health Level Seven (HL7) คืออะไร
Health Level Seven (HL7) Health Level Seven International (HL7) ก่อตั้งขึ้นในปี 1987 เป็นองค์กรไม่แสวงหาผลกำไรที่ได้รับการรับรองจาก ANSI ตั้งขึ้นมาเพื่อ พัฒนามาตรฐานที่ครอบคลุมเรื่อง การแลกเปลี่ยน บูรณาการ แบ่งปัน และดึงข้อมูลสุขภาพอิเล็กทรอนิกส์ เพื่อสนับสนุนทำงานทางคลินิก การจัดการ การให้บริการ และการประเมินผลบริการสุขภาพ เป้าหมายที่ตั้งมาก็เพื่อ ทุกคนสามารถเข้าถึงข้อมูลสุขภาพที่ปลอดภัย ทันเวลา และถูกต้อง
สรุป Health Level Seven (HL7) เป็นองค์กรระหว่างประเทศที่พัฒนามาตรฐานสำหรับการแลกเปลี่ยนข้อมูลสุขภาพอิเล็กทรอนิกส์ระหว่างระบบต่าง ๆ ในวงการสาธารณสุข มีมาเกือบจะ 50 ปี เป็นมาตรฐานที่นิยมใช้งานกันทั่วโลก และมีการพัฒนา Version ของมาตรฐานอย่างต่อเนื่องเพื่อ ปรับปรุงให้เข้ากับความต้องการ และการใช้งานที่เข้มข้นขึ้นของบริการด้านสุขภาพที่กล่าวไปข้างต้น
ความหมายของ “Level Seven” ซึ่งผมเองก็สงสัยในตอนแรก ๆ เหมือนทุกคน ๆ ที่ไม่ได้อยู่ในอุตสาหกรรม Healthcare หรือ การแพทย์ ตั้งแต่ต้น “Level Seven” หมายถึง ระดับที่เจ็ดของโมเดลการสื่อสารเจ็ดชั้นของ International Organization for Standardization (ISO) สำหรับ Open Systems Interconnection (OSI) ซึ่งระดับ Level ที่ 7 เป็นระดับแอปพลิเคชันที่เชื่อมต่อกันได้โดยตรง ในการทำงานร่วมกัน
มาตรฐานที่ HL7 พัฒนาขึ้นมีหลาย Version ดังนี้:
- HL7 Version 2 (HL7 v2): เปิดตัวครั้งแรกในปี 1989 มาตรฐานนี้ถูกนำมาใช้อย่างแพร่หลายในองค์กรสาธารณสุขทั่วโลก เพื่อสนับสนุนการแลกเปลี่ยนข้อมูลระหว่างระบบต่าง ๆ เช่น ระบบเวชระเบียนอิเล็กทรอนิกส์ (EHRs) และระบบข้อมูลห้องปฏิบัติการ (LIS) เป็นเวอร์ชั่นที่ได้รับความนิยมสูงสุด มีมายาวนาน
- HL7 Version 3 (HL7 v3): พัฒนาขึ้นเพื่อแก้ไขข้อจำกัดของ HL7 v2 โดยใช้โมเดลข้อมูลที่ชัดเจนและโครงสร้างที่เข้มงวดมากขึ้น อย่างไรก็ตาม การนำ HL7 v3 ไปใช้กลับไม่แพร่หลายเท่าที่คาดหวัง เนื่องจากความซับซ้อนในการปรับใช้
- Clinical Document Architecture (CDA): มาตรฐานสำหรับการแสดงผลและแลกเปลี่ยนเอกสารทางคลินิกในรูปแบบอิเล็กทรอนิกส์ เอกสาร: CDA เป็นมาตรฐานที่เน้นการจัดเก็บข้อมูลสุขภาพในรูปแบบเอกสาร โดยมีโครงสร้างที่กำหนดไว้ล่วงหน้า เช่น ส่วนหัวของเอกสารและส่วนของเนื้อหา ซึ่งช่วยให้ข้อมูลมีความสอดคล้องและสามารถแลกเปลี่ยนได้ระหว่างระบบต่าง ๆ
การใช้งาน: CDA ถูกนำมาใช้ในการสร้างเอกสารทางคลินิก เช่น สรุปประวัติผู้ป่วย ผลการตรวจทางห้องปฏิบัติการ และบันทึกการรักษา ซึ่งช่วยให้ผู้ให้บริการสุขภาพสามารถแบ่งปันข้อมูลที่สำคัญเกี่ยวกับผู้ป่วยได้อย่างมีประสิทธิภาพ ดู Flow การทำงานจากภาพด้านล่างจะเข้าใจมากขึ้น - HL7 FHIR (Fast Healthcare Interoperability Resources) เป็นมาตรฐานที่พัฒนาโดย HL7 ในปี 2014 เพื่อรวมข้อดีของ HL7 v2 และ v3 เข้ากับเทคโนโลยีเว็บสมัยใหม่ เช่น RESTful APIs, JSON และ XML ทำให้การพัฒนาและบูรณาการระบบเป็นไปได้อย่างรวดเร็วและมีประสิทธิภาพมากยิ่งขึ้น
Fast Healthcare Interoperability Resources (FHIR):- รูปแบบทรัพยากร: FHIR เป็นมาตรฐานที่เน้นการแบ่งข้อมูลออกเป็นหน่วยย่อย ๆ ที่เรียกว่า “ทรัพยากร” (Resources) ซึ่งแต่ละทรัพยากรแทนข้อมูลเฉพาะด้าน เช่น ผู้ป่วย ยา หรือผลการตรวจ ทำให้สามารถเข้าถึงและจัดการข้อมูลเฉพาะส่วนได้อย่างยืดหยุ่น
- การใช้งาน: FHIR ถูกออกแบบมาเพื่อรองรับการแลกเปลี่ยนข้อมูลผ่านเทคโนโลยีเว็บสมัยใหม่ เช่น RESTful APIs และใช้รูปแบบข้อมูลอย่าง JSON และ XML ทำให้การพัฒนาและบูรณาการระบบเป็นไปได้อย่างรวดเร็วและมีประสิทธิภาพ ลงรายละเอียดมากขึ้นด้านล่างครับ
- รูปแบบทรัพยากร: FHIR เป็นมาตรฐานที่เน้นการแบ่งข้อมูลออกเป็นหน่วยย่อย ๆ ที่เรียกว่า “ทรัพยากร” (Resources) ซึ่งแต่ละทรัพยากรแทนข้อมูลเฉพาะด้าน เช่น ผู้ป่วย ยา หรือผลการตรวจ ทำให้สามารถเข้าถึงและจัดการข้อมูลเฉพาะส่วนได้อย่างยืดหยุ่น
ความแตกต่างหลักระหว่าง HL7® V2 และ HL7® FHIR®
- เทคโนโลยีพื้นฐาน: HL7 v2 ใช้ข้อความที่มีโครงสร้างแบบข้อความธรรมดา (ASCII) และตัวคั่นสัญลักษณ์ ในขณะที่ FHIR ใช้เทคโนโลยีเว็บสมัยใหม่ เช่น JSON และ XML ทำให้การพัฒนาและบูรณาการระบบเป็นไปได้อย่างรวดเร็วและมีประสิทธิภาพมากยิ่งขึ้น
- ความยืดหยุ่น: FHIR ถูกออกแบบมาให้มีความยืดหยุ่นและสามารถรองรับข้อมูลเพิ่มเติมได้ง่าย แม้ไม่ได้อยู่ในโครงสร้างมาตรฐาน ซึ่งทำได้ง่ายกว่า HL7 v2 โดยมีโครงสร้างที่ชัดเจนปรับเปลี่ยนไม่ได้ และ FHIR จึงสามารถปรับแต่งได้ตามความต้องการขององค์กร หรือ Solutions ที่ต้องการนำไปใช้ได้มากกว่านั่นเองครับ
- การรองรับอุปกรณ์และแอปพลิเคชัน: FHIR รองรับการทำงานบนอุปกรณ์และแอปพลิเคชันที่หลากหลาย เช่น สมาร์ทโฟน แท็บเล็ต และอุปกรณ์สวมใส่ ทำให้ผู้ป่วยสามารถเข้าถึงข้อมูลสุขภาพของตนเองได้ง่ายขึ้น
สรุปได้ว่า HL7 เป็นองค์กรที่พัฒนามาตรฐานสำหรับการแลกเปลี่ยนข้อมูลสุขภาพอิเล็กทรอนิกส์ และ HL7 FHIR เป็นหนึ่งในมาตรฐานที่พัฒนาโดยองค์กรนี้ ซึ่งมีความทันสมัยและตอบสนองต่อความต้องการของวงการสาธารณสุขในปัจจุบันมากขึ้น มีตารางเปรียบเทียบ HL7 V2 และ HL7 FHIR:
| หัวข้อ | HL7® V2 | HL7® FHIR® |
|---|---|---|
| โมเดลข้อมูล | Implicit information model, not explicit. Inconsistency across message types. Lack of standard approach to extensions management. ข้อมูลที่เป็นนัย ไม่ชัดเจน มีความไม่สอดคล้องกันระหว่างประเภทของข้อความ (Inconsistency ) ขาดแนวทางมาตรฐานในการจัดการส่วนขยายเพิ่มเติม | An explicit and hierarchical information model employs syntax and semantic interoperability between various implementations, standard approach and strict rules to resource extension. โมเดลข้อมูลที่ชัดเจนและมีลำดับชั้น ใช้ syntax และ ความหมายที่สามารถทำงานร่วมกันได้ระหว่างการใช้งานต่าง ๆ มี กฏ และแนวทางมาตรฐานเข้มข้น สำหรับส่วนขยายเพิ่มเติม |
| การตรวจสอบความถูกต้องของข้อความ | Lack of message semantic validation capabilities. ขาดความสามารถในการตรวจสอบความถูกต้องทางความหมายของข้อความ | Automatic resource validation against the profile previously specified and ingested into the FHIR server. การตรวจสอบความถูกต้องของทรัพยากรโดยอัตโนมัติตามโปรไฟล์ที่กำหนดและนำเข้าในเซิร์ฟเวอร์ FHIR |
| รูปแบบการเข้ารหัสข้อมูล | Limited to a single and flat encoding syntax (ASCII). จำกัดอยู่ที่รูปแบบการเข้ารหัสแบบแบนเดียว (ASCII) | Supports a hierarchical data model approach by supporting XML, JSON, and RDF data formats. รองรับโมเดลข้อมูลแบบลำดับชั้น โดยสนับสนุนรูปแบบข้อมูล XML, JSON และ RDF |
| ความสามารถในการแลกเปลี่ยนข้อมูลแบบ one-to-many | No one-to-many data exchange capabilities are supported. ไม่รองรับความสามารถในการแลกเปลี่ยนข้อมูลแบบ one-to-many | RESTful API approach enabling one-to-many data exchange capabilities by deploying FHIR server aggregating and managing organizational information and providing easy and standard data access and exchange, as well as SMART on FHIR support for mobile application. ออกแบบมารองรับมาตรฐาน RESTful API ช่วยให้สามารถแลกเปลี่ยนข้อมูลแบบหนึ่งต่อหลายได้ โดยการใช้เซิร์ฟเวอร์ FHIR ที่รวบรวมและจัดการข้อมูลขององค์กร ให้การเข้าถึงและแลกเปลี่ยนข้อมูลที่ง่ายและเป็นมาตรฐาน รวมถึงการ การรองรับ SMART on FHIR สำหรับแอปพลิเคชันมือถือ |
| การสนับสนุนด้านความปลอดภัย | No explicit support for security functions. ไม่มีการสนับสนุนฟังก์ชัน การรัดษาความปลอดภัยอย่างชัดเจน | RESTful TLS (HTTPS) support – standard approach for secured data exchange. รองรับ RESTful TLS (HTTPS) 1– แนวทางมาตรฐานสำหรับการแลกเปลี่ยนข้อมูลที่ปลอดภัย ผ่านมาตรฐาน Https |
| ระยะเวลาในการนำไปใช้ | Long implementation times. ใช้เวลานานในการนำไปใช้ | The streamlined implementation provides easily understood specifications and enables developers to capitalize on common Web technologies. การนำไปใช้ที่เป็นระเบียบ มีข้อกำหนดที่เข้าใจง่าย และช่วยให้นักพัฒนาสามารถใช้ประโยชน์จากเทคโนโลยีเว็บทั่วไปได้ |
| Extensibility ความสามารถในการขยาย2 | Extensibility is not interoperable. ความสามารถในการขยายไม่สามารถทำงานร่วมกันได้ | Extensions are formally defined and can be recognized and re-used by different parties. ส่วนขยายถูกกำหนดอย่างเป็นทางการและ มีมาตรฐานการทำงานได้ง่าย เมื่อมีการร่วมงานหลายฝ่าย หรือหน่วยงาน |
ตารางนี้แสดงให้เห็นถึงความแตกต่างที่สำคัญระหว่าง HL7® V2 และ HL7® FHIR® ในด้านต่าง ๆ เช่น โมเดลข้อมูล การตรวจสอบความถูกต้อง รูปแบบการเข้ารหัส ความสามารถในการแลกเปลี่ยนข้อมูล ความปลอดภัย ระยะเวลาในการนำไปใช้ และความสามารถในการขยาย
ตัวอย่าง Journey การเรียกการทำงาน เอกสารมาตรฐาน CDA
ความสัมพันธ์ระหว่าง CDA และ FHIR
ทั้ง Clinical Document Architecture (CDA) และ Fast Healthcare Interoperability Resources (FHIR) เป็นมาตรฐานที่พัฒนาโดยองค์กร Health Level Seven International (HL7) เหมือนกัน เพื่อสนับสนุนการแลกเปลี่ยนข้อมูลสุขภาพอิเล็กทรอนิกส์ระหว่างระบบต่าง ๆ ในวงการสาธารณสุข แต่วัตถุประสงค์ในการออกมามาตรฐานมาต่างกันในการนำไปใช้ เพื่อน ๆ น่าจะเข้าใจจากการอธิบายข้างต้นไปบ้างแล้ว
FHIR เน้นการทำงาน รองรับการแลกเปลี่ยนข้อมูลผ่านเทคโนโลยีเว็บสมัยใหม่ แต่ CDA นำมาใช้ในการสร้างเอกสารทางคลินิก ซึ่งข้อมูลมาตรฐาน CDA ก็อาจจะจำเป็นต้องมีการส่งข้อมูลต่อ หน่วยงานอื่น ๆ หรือต้องเชื่อมโยงกับระบบเทคโนโลยีทางการแพทย์ใหม่ การต้องแปลง CDA เป็น FHIR เพื่อทำให้ส่งข้อมูลไปได้ง่าย การแปลงข้อมูลระหว่าง CDA และ FHIR อาจมีความซับซ้อน เนื่องจากโครงสร้างข้อมูลที่แตกต่างกัน และอาจเกิดการสูญเสียข้อมูลบางส่วนระหว่างการแปลง
อย่างไรก็ตาม HL7 ได้พัฒนาแนวทางและเครื่องมือเพื่อสนับสนุนการทำงานร่วมกันระหว่าง CDA และ FHIR เช่น โครงการ “C-CDA on FHIR” ซึ่งเป็นการนำโครงสร้างของ Consolidated CDA (C-CDA) มาปรับใช้บนแพลตฟอร์ม FHIR เพื่อให้การแลกเปลี่ยนข้อมูลเป็นไปอย่างราบรื่นและมีประสิทธิภาพมากขึ้น ผู้พัฒนา หรือผู้ที่ดูแลระบบทางด้านบริการสุขภาพจะได้ ทำงานได้สะดวกมากขึ้นสำหรับอนาคตด้าน Healthcare Technology
การประยุกต์ใช้ FHIR และ AI ในการแพทย์
การผสานมาตรฐาน FHIR (Fast Healthcare Interoperability Resources) เข้ากับ ปัญญาประดิษฐ์ (AI) ในวงการแพทย์มีบทบาทสำคัญในการปรับปรุงการดูแลสุขภาพและเพิ่มประสิทธิภาพการทำงานของระบบสาธารณสุข FHIR เป็นมาตรฐานที่ช่วยให้ระบบสุขภาพต่าง ๆ สามารถแลกเปลี่ยนข้อมูลได้อย่างมีประสิทธิภาพและปลอดภัย เมื่อรวมกับ AI จะช่วยให้การประมวลผลและวิเคราะห์ข้อมูลสุขภาพเป็นไปอย่างรวดเร็วและแม่นยำมากขึ้น
ตัวอย่างการประยุกต์ใช้ FHIR และ AI ในการแพทย์:
- การวินิจฉัยและการรักษา: AI สามารถวิเคราะห์ข้อมูลสุขภาพจากหลายแหล่ง เช่น ประวัติผู้ป่วย ผลการตรวจทางห้องปฏิบัติการ และภาพทางการแพทย์ เพื่อช่วยแพทย์ในการวินิจฉัยโรคและแนะนำแผนการรักษาที่เหมาะสม FHIR ช่วยให้การเข้าถึงและแลกเปลี่ยนข้อมูลเหล่านี้เป็นไปอย่างราบรื่น
- การติดตามสุขภาพผู้ป่วย: ด้วยการใช้เซ็นเซอร์และอุปกรณ์สวมใส่ที่เชื่อมต่อกับระบบ FHIR ข้อมูลสุขภาพของผู้ป่วยสามารถถูกส่งไปยังระบบ AI เพื่อประมวลผลและแจ้งเตือนแพทย์เมื่อพบความผิดปกติ
- การบริหารจัดการทรัพยากรทางการแพทย์: AI สามารถวิเคราะห์ข้อมูลจากระบบ FHIR เพื่อคาดการณ์ความต้องการทรัพยากร เช่น เตียงผู้ป่วย หรืออุปกรณ์ทางการแพทย์ ช่วยให้โรงพยาบาลสามารถจัดการทรัพยากรได้อย่างมีประสิทธิภาพ
การผสาน FHIR และ AI ไม่เพียงแต่ช่วยเพิ่มประสิทธิภาพในการดูแลผู้ป่วย แต่ยังช่วยลดภาระงานของบุคลากรทางการแพทย์ ทำให้สามารถมุ่งเน้นไปที่การดูแลผู้ป่วยได้มากขึ้น อย่างไรก็ตาม การนำเทคโนโลยีเหล่านี้มาใช้ควรพิจารณาด้านความปลอดภัยและความเป็นส่วนตัวของข้อมูลสุขภาพ เพื่อป้องกันการละเมิดสิทธิ์ของผู้ป่วย
อ้างอิง : Outburn , Healthcare Cloud Blog | Cloudticity , ACL Digital
- RESTful TLS (HTTPS) หมายถึงการใช้โปรโตคอล HTTPS (Hypertext Transfer Protocol Secure) เพื่อรักษาความปลอดภัยในการสื่อสารระหว่างไคลเอนต์และเซิร์ฟเวอร์ที่ใช้สถาปัตยกรรม RESTful โดย HTTPS เป็นการผสมผสานระหว่าง HTTP และโปรโตคอลความปลอดภัย TLS (Transport Layer Security) ซึ่ง TLS เป็นโปรโตคอลที่พัฒนาต่อจาก SSL (Secure Sockets Layer) เพื่อเข้ารหัสข้อมูลที่ส่งผ่านอินเทอร์เน็ต
การใช้ RESTful TLS (HTTPS) ช่วยให้ข้อมูลที่ส่งระหว่างไคลเอนต์และเซิร์ฟเวอร์มีความปลอดภัย ป้องกันการดักฟังและการปลอมแปลงข้อมูลระหว่างทาง โดย TLS ทำงานผ่านกระบวนการที่เรียกว่า TLS Handshake ซึ่งเป็นขั้นตอนที่ไคลเอนต์และเซิร์ฟเวอร์เริ่มการสื่อสารกัน ในขั้นตอนนี้ จะมีการตกลงเกี่ยวกับอัลกอริทึมการเข้ารหัสที่ใช้และการแลกเปลี่ยนคีย์เพื่อใช้ในการเข้ารหัสข้อมูล
สรุปคือ RESTful TLS (HTTPS) เป็นการใช้โปรโตคอล HTTPS เพื่อรักษาความปลอดภัยในการสื่อสารระหว่างไคลเอนต์และเซิร์ฟเวอร์ที่ใช้สถาปัตยกรรม RESTful โดยการเข้ารหัสข้อมูลผ่านโปรโตคอล TLS เพื่อป้องกันการดักฟังและการปลอมแปลงข้อมูลระหว่างทาง ↩︎ - Extensibility หรือ ความสามารถในการขยาย หมายถึงความยืดหยุ่นของมาตรฐานในการรองรับข้อมูลเพิ่มเติมที่ไม่ได้กำหนดไว้ในโครงสร้างพื้นฐานของทรัพยากร (Resource) โดยใช้กลไกที่เรียกว่า Extension หรือ ส่วนขยาย ซึ่งช่วยให้ผู้ใช้งานสามารถเพิ่มข้อมูลเฉพาะที่ต้องการได้โดยไม่กระทบต่อความสอดคล้องกับมาตรฐานหลัก ↩︎
