Health Informatics

ลองอ่าน WHO-ITU Digital Health Platform Handbook

23 September 2021

จริง ๆ เรื่อง 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 ขั้นตอนย่อย

  1. กำหนด design principles
  2. วาง enterprise architecture
  3. ระบุ components ที่ต้องมี
  4. นำมาตรฐานต่าง ๆ เข้ามาใช้

ผมจะสรุปขั้นตอนที่ 1, 2, 4 คร่าว ๆ และเน้นไปที่ขั้นตอนที่ 3 นะครับ

ขั้นที่ 1: กำหนด Design Principles

ผมว่าอันนี้ก็คล้าย ๆ core value ขององค์กร ก็คือก่อนที่เราจะสร้าง DHP ได้ เราก็ต้องมาคิดก่อนว่าหลักการอะไรที่เราจะยึดถือ โดยในเอกสารก็จะบอกถึงขั้นตอนการสร้าง รูปแบบ principle ที่ดี รวมถึงวิธีการนำไปใช้ ซึ่งผมไม่ขอลงรายละเอียดในที่นี้ แต่อยากยกตัวอย่าง design principles จากในเอกสารให้ดูครับ

ตัวอย่างจาก Digital health platform handbook หน้า 52
ตัวอย่างจาก Digital health platform handbook หน้า 53

ขั้นที่ 2: วาง Enterprise Architecture

Enterprise Architecture (EA) ก็เหมือน blueprint ที่เอาไว้อธิบายว่าส่วนต่าง ๆ ของ DHP จะอยู่ร่วมกันอย่างไร ในเอกสารไม่ได้พูดตรง ๆ แต่สามารถอนุมานได้ว่าเขาก็แนะนำให้ใช้ TOGAF แหละครับ ซึ่งในเอกสารยกตัวอย่างการใช้ 4 views ในการวาง EA (business, data, application, technology)

ตัวอย่างจาก Digital health platform handbook หน้า 56 (คลิกที่รูปเพื่อดูภาพขนาดเต็ม)

ขั้นที่ 3: ระบุ Components ที่ต้องมี

หลังจากได้ EA แล้ว ก็เป็นการระบุ components ของ DHP ที่ควรมี ซึ่งเมื่อนำทุก components มาประกอบกัน ก็จะได้ตัวอย่างของ DHP architecture เช่นดังในภาพด้านล่างนี้

ภาพจาก Digital health platform handbook หน้า 87 (คลิกที่รูปเพื่อดูภาพขนาดเต็ม) – Redraw by Rath Panyowat for higher resolution image

ภาพแบบนี้อาจจะดูซับซ้อนน่ากลัวนะครับ ซึ่งภาพนี้เองก็เป็นแค่ตัวอย่างนะครับ แต่ละประเทศไม่ต้องทำแบบนี้ก็ได้

เอกสารนี้แบ่ง components ออกเป็น x กลุ่ม ได้แก่

  1. Information mediation services
  2. Registries
  3. Shared repositories
  4. Terminology services
  5. Workflows and algorithm services
  6. Payments services
  7. Interactive communication services
  8. Geolocation services
  9. Analytics
  10. User authentication and consent management
  11. Enterprise mobility management
  12. Data collection (user interface)
  13. Reporting services
  14. Scheduling services
  15. Applications store
  16. 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 สำหรับการสั่งยา
ภาพจาก Digital health platform handbook หน้า 104
  • หลังจากนั้นก็มีการพูดถึง 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 โครงการต่าง ๆ ไว้มีโอกาสมาเล่าเพิ่มเติมครับ

You Might Also Like

No Comments

Leave a Reply