จริง ๆ เรื่อง National Digital Health Platform เป็นเรื่องที่ผมสนใจมานานแล้วครับ (เช่นที่เคยเขียนเรื่องของ open platform ในแบบของ openEHR) พอดีช่วงนี้ได้เข้าไปเกี่ยวข้องกับหลาย ๆ โครงการที่พยายามจะพัฒนา Digital Health Platform (DHP) ก็เลยลองค้น ๆ ดูว่าที่อื่นทำอย่างไรบ้างครับ ไปเจอเอกสารนี้ของ WHO คิดว่าน่าสนใจดีครับ
ตามนิยามจากในเอกสาร DHP คือ common digital health information infrastructure (infostructure) ที่ digital health applications สามารถมาพัฒนาบน platform เพื่อก่อให้เกิดบริการสุขภาพที่ได้มาตรฐานและมีประสิทธิภาพ
เนื้อหาของเอกสารมีหลายส่วน ช่วงต้น ๆ ก็เป็นพวก introduction, overview, การวิเคราะห์บริบทของประเทศ อันนี้ท่านใดสนใจก็ลองอ่านดูได้ครับ ส่วนที่เป็นไฮไลท์จริง ๆ ผมว่าคือ Section 5: Digital Health Platform Design ครับ ซึ่งส่วนนี้ประกอบด้วย 4 ขั้นตอนย่อย
- กำหนด design principles
- วาง enterprise architecture
- ระบุ components ที่ต้องมี
- นำมาตรฐานต่าง ๆ เข้ามาใช้
ผมจะสรุปขั้นตอนที่ 1, 2, 4 คร่าว ๆ และเน้นไปที่ขั้นตอนที่ 3 นะครับ
ขั้นที่ 1: กำหนด Design Principles
ผมว่าอันนี้ก็คล้าย ๆ core value ขององค์กร ก็คือก่อนที่เราจะสร้าง DHP ได้ เราก็ต้องมาคิดก่อนว่าหลักการอะไรที่เราจะยึดถือ โดยในเอกสารก็จะบอกถึงขั้นตอนการสร้าง รูปแบบ principle ที่ดี รวมถึงวิธีการนำไปใช้ ซึ่งผมไม่ขอลงรายละเอียดในที่นี้ แต่อยากยกตัวอย่าง design principles จากในเอกสารให้ดูครับ
ขั้นที่ 2: วาง Enterprise Architecture
Enterprise Architecture (EA) ก็เหมือน blueprint ที่เอาไว้อธิบายว่าส่วนต่าง ๆ ของ DHP จะอยู่ร่วมกันอย่างไร ในเอกสารไม่ได้พูดตรง ๆ แต่สามารถอนุมานได้ว่าเขาก็แนะนำให้ใช้ TOGAF แหละครับ ซึ่งในเอกสารยกตัวอย่างการใช้ 4 views ในการวาง EA (business, data, application, technology)
ขั้นที่ 3: ระบุ Components ที่ต้องมี
หลังจากได้ EA แล้ว ก็เป็นการระบุ components ของ DHP ที่ควรมี ซึ่งเมื่อนำทุก components มาประกอบกัน ก็จะได้ตัวอย่างของ DHP architecture เช่นดังในภาพด้านล่างนี้
ภาพแบบนี้อาจจะดูซับซ้อนน่ากลัวนะครับ ซึ่งภาพนี้เองก็เป็นแค่ตัวอย่างนะครับ แต่ละประเทศไม่ต้องทำแบบนี้ก็ได้
เอกสารนี้แบ่ง components ออกเป็น x กลุ่ม ได้แก่
- Information mediation services
- Registries
- Shared repositories
- Terminology services
- Workflows and algorithm services
- Payments services
- Interactive communication services
- Geolocation services
- Analytics
- User authentication and consent management
- Enterprise mobility management
- Data collection (user interface)
- Reporting services
- Scheduling services
- Applications store
- Emerging DHP components
1. Information mediation services (integration services)
- เป็นช่องทางให้ external applications สื่อสารกับ DHP components ต่าง ๆ หรือเป็นช่องทางการสื่อสารระหว่าง DHP components
- ทำหน้าที่ process, translate, หรือ logs transaction ต่าง ๆ
- อาจทำในรูปแบบแหล่งรวม API กลาง ทำให้แต่ละ component ไม่ต้องมี API สำหรับสื่อสารกับภายนอกเป็นของตนเอง ทำให้นักพัฒนาสามารถสื่อสารกับ platform ได้ง่าย ลดความซ้ำซ้อน และเพิ่มความเร็วในการพัฒนา
2. Registries
- ทำให้เราสามารถระบุตัวบุคคล สถานที่ องค์กรต่าง ๆ ได้โดยไม่ซ้ำกัน (แต่ละรายการจะมี unique identifier)
- ระดับความสามารถ ในเบื้องต้นอาจแค่มีรายการแบบพื้นฐาน ระดับกลางอาจมีกระบวนการติดตามการเปลี่ยนแปลงของรายการ ระดับสูงมีกระบวนการค้นหารายการอย่างสลับซับซ้อน
- อาจมีกระบวนการในการ verifiy หรือออกใบรับรอง เช่น รับรองว่าคนไข้มีสิทธิ์การรักษา รับรองว่าบุคลากรทางการแพทย์นั้นได้รับใบอนุญาต เป็นต้น
- ตัวอย่าง registry เช่น
- Facility registry: ข้อมูล health service delivery location
- Health worker registry: ข้อมูล provider ทุกชนิด หมอ พยาบาล เภสัชกร นักสังคมสงเคราะห์ อาจรวมไปถึงคนทำงาน admin
- Patient registry: ทะเบียนคนไข้
- สิ่งสำคัญคือ การเก็บข้อมูลใน registries ต้องเก็บให้ minimal ที่สุด เก็บเท่าที่จำเป็น
- ในการได้มาซึ่งข้อมูลใน registries มักจะต้องมีการทำงานหรือแลกเปลี่ยนข้อมูลกับหน่วยงานอื่น ๆ ที่เก็บรวบรวมเรื่องเหล่านี้อยู่แล้ว (เช่น เลขประจำตัวประชาชน) หรืออาจต้องนำข้อมูลมาจาก external applications
- สำหรับ health worker registry -> WHO เคยออก Minimum Data Set for Health Workforce Registry อาจใช้ดูเป็นแนวทางได้ (จริง ๆ dataset นี้ผมก็เคยทำงานด้วยครับ ไว้มีโอกาสมาอธิบายครับ)
3. Shared repositories
- ใช้เป็นที่เก็บข้อมูลจริง ๆ สำหรับเรื่องต่าง ๆ เช่น Electronic Health Records (EHRs), medication repository, diagnostic imaging repository, e-learning content repository, health education content repository, budget and expenditure data repository
- ในระดับเริ่มต้นอาจเป็นข้อมูลเพียงชนิดเดียว ระดับกลางเป็นข้อมูลมากขึ้น ทั้ง structured และ unstructured data ส่วนระดับสูงก็อาจสามารถสังเคราะห์ health profile จาก data หลาย ๆ แหล่งได้
- Repository นี้รวมไปถึงพวกเอกสาร เช่น นโยบาย, แบบฟอร์ม, technical documents ต่าง ๆ
- การทำ repository ทำให้สามารถเปลี่ยน external application ได้ โดยที่ไม่กระทบต่อข้อมูลที่เก็บไว้ applications เหล่านี้สื่อสารผ่าน API ที่เตรียมไว้
- ข้อมูลที่เก็บไว้สามารถใช้ประโยชน์ได้หลายด้าน สามารถแชร์ให้ผู้ป่วยดูด้วยได้
4. Terminology services
- เพื่อให้ข้อมูลที่เป็น coded data เป็นมาตรฐานเดียวกัน เพื่อให้เรื่องที่สื่อสารมีความหมายตรงกัน เพิ่มความปลอดภัยในการดูแลรักษาคนไข้ เพิ่มความถูกต้องในการวิเคราะห์ข้อมูล
- ระดับเบื้องต้นก็อาจเป็นแค่รายการของ code ในระดับสูงก็อาจสามารถ mapping ระหว่าง code system ได้, มี version management, ฯลฯ
- ในเอกสารมีการยกตัวอย่างประเทศเอธิโอเปียที่ใช้ Open Concept Lab ในการทำ terminology services
5. Workflows and algorithm services
- ระบบเพื่อการดำเนินหรือสนับสนุน business process, care process ทั้งหลาย เช่น ระบบนัด, e-prescription, clinical decision support, claim processing, ระบบรับเงินทาง smartphone, ฯลฯ
6. Payments services
- ระบบสำหรับดำเนินธุรกรรมทางการเงิน
- เป็นระบบที่มักต้องเกี่ยวข้องกับระบบ electronic payment ในระดับประเทศ
7. Interactive communication services
- ระบบสำหรับให้ application สื่อสารแบบสองทางกับผู้อื่นได้ เช่น SMS, USSD, interactive voice response (IVR), e-mail, chat, social networks
- ประโยชน์เช่นการทำ surveillance, การตรวจสอบ eligibility สำหรับ health insurance, ให้ความรู้ทางสุขภาพแก่คนไข้หรือ provider
- มักจะต้อง integrate กับ workflow component
8. Geolocation services
- สำหรับให้บริการด้าน geolocation
- ระดับพื้นฐานก็ให้ละติจูด ลองจิจูด ระดับสูงก็มีการบูรณาการข้อมูลกับเครื่องมืออื่น ๆ เช่น decision support
- ตัวอย่างการใช้งาน เช่น ด้าน logistics, การระบุจุดที่เป็นปัญหาสิ่งแวดล้อมหรือต้นตอโรคระบาด, ประเมิน contact tracing, การหาเครื่องมือเสื่อมอายุจากระยะไกล
9. Analytics
- รวบรวมข้อมูลและ transform ให้อยู่ในรูปที่ประมวลผลต่อได้ง่าย
- ระดับพื้นฐานก็อาจเป็นแค่ให้ user สามารถดึงไปทำรายงานแบบ manual ได้ ระดับสูงก็จะมีกระบวนการซับซ้อนมากมาย มี predictive analytics
- ยกตัวอย่างเช่น การประเมิน trend ในการใช้ service ใน facility ต่าง ๆ, การพยากรณ์ supply chain, การตรวจวัด performance indicators
- มักจะต้องมีการทำ data warehouse
10. User authentication and consent management
- ทำให้ external applications สามารถจดจำ digital signature, consent ของบุคคล ที่เกิดขึ้นกับ event ที่พบบ่อย ๆ ใน healthcare เช่น consent สำหรับหัตถการ, แพทย์สั่งยา, สถานพยาบาลรีเฟอร์คนไข้ไปที่อื่น เป็นต้น
- ระดับพื้นฐานก็เช่นระบบให้ใส่รหัสผ่าน ระดับสูงมาหน่อยก็อาจเป็นพวก single sign-on, digital signature, biometrics
11. Enterprise mobility management
- เอาไว้บริหารจัดการอุปกรณ์ต่าง ๆ ที่เชื่อมต่อเข้ากับระบบ เช่น PC, laptop, tablet, smartphone
- ตัวอย่างการใช้งานเช่น บังคับใช้ security policy บางอย่างในอุปกรณ์, การล้างข้อมูลจากระยะไกลในกรณีเครื่องสูญหาย, บังคับติดตั้ง application บางอย่าง
12. Data collection (user interface)
- เป็นเครื่องมือสำหรับเก็บข้อมูลจาก user ไม่ว่าจะเป็นคนไข้, บุคลากรทางการแพทย์, อื่น ๆ เข้าสู่ DHP
- ความเห็นผม: ผมว่า DHP ควรมีการกำหนด style guide สำหรับ user interface ของ external application ที่จะเชื่อมต่อเข้ามา เพื่อให้ได้ประสบการณ์การใช้งานที่คงเส้นคงวา เป็นไปในทิศทางเดียวกัน และลด bad practice ต่าง ๆ ที่ developer อาจใช้
13. Reporting services
- ระบบสำหรับออกรายงาน visualize ข้อมูลต่าง ๆ
14. Scheduling services
- เพื่อสร้าง event หรือ task สำหรับเวลาต่าง ๆ เช่น การนัดหมายตามกำหนดการเพื่อมารับบริการ นัดเพื่อให้ความรู้ หรือตั้งเวลาเตือนสำหรับการ maintenance อุปกรณ์
15. Applications store
- เพื่อให้ user สามารถเลือก ดาวน์โหลด หรือติดตั้ง external applications ต่าง ๆ ได้
- ไม่ได้มีขึ้นเพื่อแทนที่ app store (iOS, Android, Microsoft, ฯลฯ) แต่เป็นคล้าย ๆ curated list เพื่อให้ user เข้าถึง app เหล่านี้ได้ง่ายขึ้น
16. Emerging DHP components
- อาจมี component อื่น ๆ ที่จะเกิดขึ้นในอนาคต ตามเทรนด์ปัจจุบัน เช่น NLP, ML, image-recognition, text-to-speech, wearable devices ฯลฯ
การ implement จริงในแต่ละประเทศ ไม่จำเป็นต้องมี component ดังที่กล่าวข้างต้นนี้ทั้งหมดนะครับ และตอน implement ก็ไม่จำเป็นต้องทำให้ได้สมบูรณ์ตั้งแต่เริ่มแรก ค่อย ๆ พัฒนาไปตามลำดับได้ ตัวอย่างการนำ component เหล่านี้ไปประกอบเป็น architecture สามารถลองดูได้ที่แผนภาพด้านบนครับ
ขั้นที่ 4: นำมาตรฐานต่าง ๆ เข้ามาใช้
เมื่อกำหนด components แล้ว ก็ต้องกำหนดต่อว่าแต่ละ components จะคุยกัน หรือคุยกับ external applications ผ่านมาตรฐานใด ถ้าเป็นไปได้ก็ควรใช้มาตรฐานที่มีการใช้อยู่แล้วในระดับสากล มาตรฐานที่ใช้ก็มีหลายกลุ่ม (ผมเคยเขียนบทความเรื่องนี้ แต่ว่าค่อนข้างเก่ามากแล้ว ตั้งแต่ปี 2017 หากสนใจลองดูได้ครับ)
แบ่งประเภทย่อย ๆ ตามในเอกสาร WHO (คือถ้าแบ่งตามค่ายอื่นก็อาจจะใช้คำต่างออกไป แต่หลักการคล้ายกันครับ) ออกได้เป็น
- Technical standard: TCP/IP, Bluetooth, XML, HTTP, REST, PKI
- Health informatics standard
- Classifications: ICD-10, ICF, ICHI
- Terminologies: SNOMED CT, LOINC, ISO/IEEE 11073
- Health workflow standard
- High level workflow: clinical practice guideline, clinical pathways
- Low level workflow: WHO เรียกว่า profile (น่าจะเอามาจาก IHE) เช่น profile สำหรับการ refer, profile สำหรับการสั่งยา
- หลังจากนั้นก็มีการพูดถึง standard stack คือการเลือกชุดของ standard มาใช้ เช่น HL7 stack, IHE stack, openEHR stack และมีการพูดถึง CIMI ว่าเป็นการพยายาม integrate หลาย ๆ stack (แต่ผมลองเข้าเว็บไปแล้วเหมือนจะเข้าไม่ได้แล้ว เหลือแต่ GitHub ซึ่งดูไม่ได้อัพเดทนานแล้ว)
- และก็พูดถึงเรื่องการสร้างและ implement standard อีกเล็กน้อย
ส่งท้าย
ก็หมดแล้วครับสำหรับประเด็นที่ผมอยากจะสรุป จริง ๆ ในเอกสารมีรายละเอียดอีกเยอะพอสมควรนะครับ โดยรวมผมว่าเป็น handbook สั้น ๆ ที่ผู้ที่ต้องการสร้าง digital health platform ควรอ่านครับ ไม่จำเป็นต้องคาดหวังที่จะทำ platform ในระดับประเทศ แม้เป็นการทำ platform ใช้ในวงเล็ก ๆ ก็สามารถนำแนวคิดนี้มาใช้ได้ครับ
ผมค่อนข้างสนใจพวก health information standard และการสร้างพวก digital health platform โครงการต่าง ๆ ไว้มีโอกาสมาเล่าเพิ่มเติมครับ
