[opinion] ข้อเสนอนโยบายด้านการบูรณาการข้อมูลสุขภาพ ในการเลือกตั้งผู้ว่า ฯ กทม.

พอดีผมเห็นในเว็บของอ.ชัชชาติมีนโยบายเรื่องการบูรณาการข้อมูลสุขภาพ และมีช่องให้สามารถเสนอความเห็นได้ ตัวผมเองมีความเห็นเรื่องนี้อยู่จำนวนหนึ่ง จึงอยากนำเสนอเช่นกันครับ และถือโอกาสเสนอให้ทุกท่านด้วยนะครับ เห็นด้วยไม่เห็นด้วยอย่างไรแลกเปลี่ยนกันได้ครับ

หมายเหตุ

  • สิ่งที่เขียนนี้เป็นความเห็นส่วนตัวของผม ไม่เกี่ยวกับหน่วยงานที่ผมสังกัดนะครับ
  • ขอเขียนแบบใช้ภาษาธรรมดา ๆ ไม่ได้เขียนแบบเป็นทางการนะครับ อันนี้ก็ไม่ได้เตรียมจะเขียนมาก่อน นึกจะเขียนก็เขียนขึ้นมาเลยครับ ว่าจะส่งข้อเสนอสั้น ๆ ไป ๆ มา ๆ ยาวครับ
  • ทั้งหมดนี้เป็นข้อเสนอ ณ​ วันนี้ ในอนาคตหากสภาพแวดล้อมเปลี่ยน เทคโนโลยีเปลี่ยน ข้อเสนอเหล่านี้อาจไม่สอดคล้องกับสภาพแวดล้อมได้

ภาพ featured image โดย Lauren Kay ที่ Unsplash

ปัญหาของการบูรณาการข้อมูลสุขภาพ ณ ตอนนี้

ส่วนนี้จะเหมือนผมมาบ่น ๆ ปัญหาหน่อยนะครับ แต่ผมคิดว่าต้องชี้แจงสภาพปัจจุบันก่อน จึงจะเสนอทางออกได้ครับ

ปัญหาด้าน governance

เรื่องนี้จริง ๆ ผมไม่ได้มีความเชี่ยวชาญเท่าใดนักครับ ที่พอแชร์ได้คือ healthcare ecosystem มีความซับซ้อนและความเป็น silo ค่อนข้างสูง การจะขับเคลื่อนเรื่องใด ๆ แม้จะจำกัดขอบเขตแค่ในกทม. ก็อาจจะไม่ได้ง่าย เพราะ stakeholder จะเยอะเสมอ คำถามสำคัญคือ จะทำอย่างไรจึงจะทำให้หน่วยงานทั้งหมดนี้ทำงานร่วมกันได้

  • สถานพยาบาลที่อยู่ในกทม. ไม่จำเป็นต้องสังกัดกทม. ทั้งหมด ลองดูใน Wiki นี้ก็ได้ครับ หน่วยงานเหล่านี้อยู่กันคนละกระทรวง เช่น โรงเรียนแพทย์สังกัดกระทรวงอว. กรมการแพทย์ (กระทรวงสธ.) มีรพ.จำนวนมาก กรมแพทย์ทหารอากาศมีรพ.ภูมิพล ฯลฯ รวมถึงรพ.ในปริมณฑลจำนวนมากที่ต้องทำงานร่วมกับกทม.
  • สถานพยาบาลเอกชน เข้าใจว่าเป็นกรมสนับสนุนบริการสุขภาพเป็นผู้กำกับดูแล แต่ก็ไม่ได้มีกลไกอะไรจะไปสั่งเขาได้เท่าไหร่ จะออกกฎหมายห้าม information blocking ก็คงไม่ง่าย
  • ตอนนี้ยังมีบริการใหม่ ๆ เช่น platform telemedicine ต่าง ๆ ที่ดูจะยังงง ๆ ว่าจะกำกับดูแลยังไง เพราะกลุ่มนี้ก็ไม่ได้ถือว่าเป็น healthcare provider
  • ข้างต้นคือโครงสร้างอำนาจแบบที่เขียนไว้แบบทางการ โครงสร้างแบบที่ทำงานจริง ๆ อาจจะเป็นอีกแบบ และอาจมีกลุ่มที่ไม่ได้อยู่ระบุไว้เป็นทางการเข้ามาเกี่ยว
  • ในด้านผู้จ่าย (payor) ก็ซับซ้อนเช่นกัน ภาครัฐหลัก ๆ มี 3 กองทุน (สปสช. กบก. ปกส.) สปสช. กทม. ก็ไม่จำเป็นต้องมีแนวทางการทำงานเหมือนเขตอื่น เรื่องนี้สำคัญเพราะการจ่ายเงินเป็นกลไกสำคัญในการผลักดันนโยบายต่าง ๆ (ในต่างประเทศก็ทำแบบนี้ครับ เช่น CMS ใน US)
  • เรื่อง digital health มีความจำเป็นต้องเกี่ยวข้องกับฝั่งวิทยาศาสตร์และ IT เช่น สวทช.​, TCELS, DGA, ETDA, กระทรวง DE, GBDi, NT ฯลฯ
  • เท่าที่ผมทราบล่าสุดคือมีการเซ็น MOU ระหว่างหน่วยงานที่เกี่ยวข้องกับ healthcare ในกทม. ครับ อาจเป็นกลไกหนึ่งในการขับเคลื่อน

ปัญหาด้าน technical

หากสมมติว่าทุกหน่วยงานข้างต้นสามารถตกลงกันได้ว่าจะร่วมมือกันเต็มที่แล้วนะ ขั้นตอนต่อมาก็คือการกำหนดมาตรฐานในการแลกเปลี่ยนข้อมูล ซึ่งอันนี้ก็มีความซับซ้อนครับ ผมขอยก architecture ของ OpenHIE มาเป็นฐานในการอธิบาย เพราะว่าน่าจะเข้าใจได้ง่ายครับ ลองดูในส่วนที่เป็นกล่องสีเทาด้านล่างนี้นะครับ ผมอยากจะบอกว่า เราแทบจะไม่มีอะไรเลยในกล่องนี้ครับ และ สิ่งที่มีแล้วก็มีหลายอันที่ไม่ได้มีกลไกการ maintain ที่ดี

ลองมาดูตัวอย่างครับ

Product catalogue

  • ตอนนี้เรามีเรื่องรหัสยา คือมีรหัส TMT ซึ่งดูแลโดยสมสท. ต้องทำการออกรหัสใหม่ทุก 2 สัปดาห์เพราะมียาใหม่เรื่อย ๆ แต่สมสท.ไม่ได้มีงบประจำจากภาครัฐ ซึ่งเป็นแบบนี้ต่อไปก็คงไม่ยั่งยืนนัก
  • เรามีรหัสมาตรฐานการตรวจทางห้องปฏิบัติการ คือมี TMLT
  • ถึงแม้มีรหัสต่าง ๆ แต่ในระบบสารสนเทศรพ. หรือ Hospital Information System (HIS) ก็อาจจะไม่ได้นำรหัสมาตรฐานไปใช้ เพราะไม่มีใครบังคับได้ ถ้าจะบังคับก็ต้องตามมาด้วยแล้วใครจะออกเงินค่าดำเนินการ
  • ผมเข้าใจว่าเรายังไม่มีรหัสมาตรฐานประเภทของ medical device นะครับ (จริง ๆ ผมคิดว่าใช้ SNOMED CT ได้ หรือทำเป็น SNOMED extension)

Client registry

  • เรามีเลขทะเบียนราษฎร์ เลขประชาชนไทย 13 หลัก แต่ชาวต่างชาติ หรือคนไร้สัญชาติ ยังไม่มีวิธีมาตรฐานในการระบุตัวตน มีผู้เสนอให้ออก health ID ให้ทุกคน ก็ไม่แน่ใจว่าตอนนี้ถึงไหนแล้วนะครับ

Terminology services

  • เรามีการใช้ ICD-10 เป็นรหัสกลุ่มโรค อันนี้ถือว่าเราทำได้ดี
  • เรามีการใช้ ICD-9-CM เป็นรหัสหัตถการ แต่กำลังประสบปัญหาคือรหัสล้าสมัยและไม่ทันต่อเทคโนโลยีในการทำหัตถการแบบใหม่ ๆ
  • เรามีการเข้าเป็นประเทศสมาชิก SNOMED CT ทำให้เราจะสามารถบันทึกข้อมูลทางคลินิกได้ละเอียดมากขึ้น รวมถึงสามารถใช้บันทึกการวินิจฉัย (เพราะ ICD-10 เป็นรหัสกลุ่มโรค ไม่ใช่รหัสโรค) รวมถึงอาจนำ SNOMED-CT มาใช้แทน ICD-9-CM ได้เช่นกัน แต่ know-how ในการใช้ SNOMED CT ของเราก็น้อยมาก ๆ โครงการที่จะนำไปใช้ก็ยังไม่มี ณ​ ปัจจุบันจึงยังไม่ค่อยมีแนวโน้มที่จะเกิดการใช้งานที่เป็นประโยชน์เท่าใดครับ
    • ถ้าใช้ให้เต็มที่ จริง ๆ SNOMED CT จะตอบโจทย์เรื่อง data catalogue/ registry หลาย ๆ อย่างมากนะครับ เช่น service catalogue จริง ๆ ผมว่าก็เอา SNOMED CT มาใช้เลยได้ครับ

Facility registry & health worker registry

  • เรามีรหัสหน่วยงานบริการสุขภาพ 5 หลักและ 9 หลัก (hcode) อันนี้ผมไม่แน่ใจว่าขอบเขตครอบคลุมถึง ผู้ให้บริการ (provider) ทุกชนิดหรือไม่นะครับ เช่น มีร้านยาเอกชนหรือไม่ และในกลุ่มที่ครอบคลุม รหัสของหน่วยงานครบถ้วนหรือไม่ เช่น มีรหัสของคลินิกเอกชนทุกแห่งหรือไม่ เป็นต้นครับ
  • แพทยสภามีรหัสหมอ วิชาชีพอื่นหลาย ๆ วิชาชีพก็เหมือนจะมีรหัส แต่ทุกวิชาชีพเก็บทะเบียนของบุคคลไม่เหมือนกัน และผมไม่แน่ใจความอัพเดทของข้อมูล การไม่มีทะเบียนที่ดีทำให้ไม่สามารถวิเคราะห์ข้อมูลได้ เช่น ตอนนี้มีหมออายุรกรรมกี่คนทำงานอยู่รพ.รัฐในแต่ละพื้นที่ กี่คนทำรพ.เอกชนด้วย กี่คนไม่ได้ทำงานเป็นหมอแล้ว เป็นต้น
  • นอกจากนี้ เราต้องมี Public key infrastructure (PKI) ในการทำ digital signature คือไม่ใช่แค่มีหน่วยงานที่ออก certificate (เช่น ETDA) แล้วจะจบ เราต้องมีระบบในการเอา signature ไปตรวจกับทะเบียนของ provider ว่าเป็นของจริง ซึ่งก็ไปผูกกับหัวข้อก่อนหน้า คือเราต้องมีทะเบียนของ provider ที่สมบูรณ์ และต้องมีคนดูแลทะเบียนนั้น
    • ยกตัวอย่าง การออกใบรับรองแพทย์อิเล็กทรอนิกส์ ไม่ได้มีหมอเซ็นอิเล็กทรอนิกส์กำกับ เป็นแค่ข้อความที่บอกว่าหมอคนหนึ่งลงชื่อ แบบนี้เราไม่สามารถเชื่อได้สนิทว่าใบนั้นเป็นของจริงนะครับ

Interoperability Layer

  • ตอนนี้เรามีโครงการ HealthLink ของ GBDi ซึ่งเป็นช่องทางในการแลกเปลี่ยนข้อมูล โดยใช้มาตรฐาน HL7 FHIR และใช้ IPS เป็น profile
  • แต่ข้อจำกัดของ HealthLink ก็คือแม้แต่ในแต่ละรพ.ที่เข้าร่วม ก็มีข้อจำกัด 2 ประการ
    1. ความสามารถในการส่งข้อมูลมาเข้าร่วมระบบได้ต่างกัน ซึ่งสืบเนื่องมาจากระบบ HIS ที่แต่ละรพ. สามารถเก็บข้อมูลในรูปแบบที่มีโครงสร้าง (structured data) ได้มากน้อยต่างกัน ซึ่งส่วนใหญ่แค่เก็บเป็น digital ไม่ใช้กระดาษได้นี่ก็น้อยแล้ว น้อยรพ.มาก ๆ ที่จะเก็บในรูปแบบที่มีโครงสร้างที่ดี บางรพ. มีโครงสร้างดี แต่ก็อาจไม่ได้เอามาตรฐานด้านรหัสมาใช้อีก ทำให้บูรณาการกันไม่ได้อยู่ดี
    2. ความไว้ใจในการส่งข้อมูลมาเข้าระบบ อันนี้จริง ๆ เป็นปัญหาเชิงการจัดการมากกว่า ซึ่งจริง ๆ ผมก็เข้าใจทั้งสองฝ่ายนะครับ อาจต้องหาทางจัดการตรงนี้
  • ข้อจำกัดต่อมาไม่เชิงเป็นของ HealthLink แต่เป็นของทุกระบบที่ใช้ FHIR นั้นคือ FHIR เป็นมาตรฐานที่ออกแบบมากว้าง ๆ การจะนำไปใช้จริงต้องมีการมาปรับแต่งเพิ่ม ซึ่งปกติประเทศที่มีความก้าวหน้าด้านนี้เขาก็จะมีความร่วมมือในระดับประเทศที่จะสร้าง national implementation guide ออกมา เช่น US-Core แต่ไทยเรายังไม่มีตรงนี้ ดังนั้น คนละโครงการ ใช้ FHIR เหมือนกัน ไม่ได้แปลว่าจะคุยกันรู้เรื่องครับ
  • ยังไม่นับว่า มีอีกหลายโครงการที่นิยมออกแบบมาตรฐานใหม่ ซึ่งก็มีทั้งสถานการณ์ที่เหมาะและไม่เหมาะนะครับ ข้อดีคือ ออกแบบใหม่ก็เร็วดี และตอบโจทย์นั้น ๆ แต่ข้อเสียคือแลกเปลี่ยนกับคนอื่นไม่ได้ มีแบบนี้เยอะ ๆ สุดท้ายคือเกิด silo ที่แลกอะไรกันไม่ได้เลยเหมือนทุกวันนี้

ข้อเสนอทางแก้

ผมว่า framework ที่ดีสำหรับทำเรื่องนี้ก็คือของ WHO-ITU ที่บอกว่าจะทำเรื่อง eHealth/digital health ต้องมีอะไรบ้าง ซึ่งตอนนี้ผมว่าสิ่งที่เราขาดที่สุดคือ leadership and governance นี่แหละครับ พอ stakeholder เยอะ แต่ governance ไม่ชัด ทุกอย่างก็สับสนไปหมด

ดังนั้น ขอเสนอดังนี้ครับ

  1. หาทางออกให้ได้ว่าจะใช้กลไกใดในการ governance เรื่อง digital health ในประเทศ (หรือในกทม.) โดยที่จะทำงานร่วมกับ stakeholder ทั้งหมดได้ แต่ก็ขับเคลื่อนไปงานไปได้
  2. จัดทำ national digital health strategy เพื่อกำหนดว่าจะทำอะไรบ้าง ทำเมื่อไหร่ อย่างไร วัดผลอย่างไร

เนื่องจากในกล่องอื่น ๆ อาจไม่ใช่เรื่องที่ผมมีความรู้มากนัก ดังนั้นจึงขอเสนอแค่ในกล่อง Standards & interoperability ครั

  • ให้มีหน่วยงานที่รับผิดชอบเรื่องมาตรฐานข้อมูลสุขภาพทั้งหมด
  • หน่วยงานนั้นเป็นผู้กำหนดมาตรฐานต่าง ๆ โดยเน้นให้ใช้มาตรฐานที่ใช้ในระดับสากลเป็นหลัก เพื่อประหยัดต้นทุนในการพัฒนาใหม่ และเพื่อให้สื่อสารกับชาวโลกได้ หากไม่มีมาตรฐานสากลที่เหมาะสมจึงพัฒนาเอง
  • หน่วยงานนั้น 1) สนับสนุนให้มีการใช้งานด้วยกลไกต่าง ๆ (implementation support) 2) ทำการ maintain มาตรฐานต่อในระยะยาว 3) ประเทศลงทุนให้งบมาดำเนินงานเรื่องนี้
  • ทำ national provider registry โดยอาจเริ่มจากใช้ WHO minimum dataset และให้มีหน่วยงานที่คอยดูแลทะเบียนนี้ (ลองดู Ahpra ของออสเตรเลียได้ครับ หน่วยงานเดียวดูทุกวิชาชีพ)
  • ทำ public key infrastructure ในการ authenticate provider ทั้งแบบบุคคลและองค์กรทุกชนิด (ดูตัวอย่าง NASH ของออสเตรเลียเช่นกันครับ)
  • ออก FHIR national implementation guide เช่น TH-Core เพื่อให้ทุกคนที่จะใช้ FHIR นำไปเป็นฐาน และกำหนดให้การแลกเปลี่ยนในอนาคตยึด FHIR TH-Core เป็น priority แรก ยกเว้นว่ามีเหตุอันควรให้ใช้อย่างอื่น
  • มีการศึกษาถึงความเหมาะสมว่าจะใช้ SNOMED CT เข้าไปในจุดใดได้บ้าง อย่างน้อย ๆ ก็คือจุดที่กำลังเป็นปัญหาทุกวันนี้
  • กำหนดมาตรฐานของ HIS (ทั้ง functional และ non-functional) คือไม่จำเป็นต้องเปลี่ยนให้ทุกรพ.มาใช้เหมือนกัน แต่ทุกรพ.ควรมีมาตรฐานระดับเดียวกัน ซึ่งการจะบังคับใช้ได้ก็อาจต้องมีกลไกให้คุณให้โทษบางอย่าง เช่น ทำแล้วได้เงินเพิ่ม ไม่ทำโดนปรับ (คล้าย meaningful use ของ US)
  • มาตรฐานอื่น ๆ เช่นกัน อาจเปิดให้นักพัฒนาที่นำมาตรฐานไปใช้แรก ๆ ในช่วงเวลาที่กำหนดได้รับผลประโยชน์บางอย่าง

จริง ๆ ที่กล่าวมาทั้งหมดนี้ อาจจะดูเหมือนต้องอาศัยอำนาจที่เกินกว่าที่ผู้ว่า ฯ กทม. จะมี แต่ผมคิดว่าทั้งหมดข้างต้น สามารถย่อส่วนมาทำในสเกลระดับกทม. น่าจะไหว เช่น กำหนดไปเลยว่าใครจะแลกเปลี่ยนกับหน่วยงานภายในสังกัดกทม. ต้องใช้มาตรฐานที่กำหนดเท่านั้น ผู้พัฒนา software ที่จะขายให้หน่วยงานในสังกัดก็ต้องผ่านมาตรฐานที่กำหนด เป็นต้นครับ หรือแม้แต่การทำทะเบียนผู้ให้บริการ ก็อาจจะเริ่มจากทำให้ครบในขอบเขตของกทม. ก่อน เป็นต้นครับ ถ้าทุกอย่างทำได้ดี ก็ค่อยสเกลต่อไปยังระดับประเทศต่อไป

ก็หมดแล้วครับสำหรับข้อเสนอของผมครับ จริง ๆ กล่องอื่น ๆ ใน 7 กล่องของ WHO-ITU นี่ก็พูดได้ยาวครับ แต่ ณ วันนี้ ผมอยากเสนอแค่กล่อง governance กับ standard ก่อนนี่แหละครับ เพราะมันคือฐานรากสำคัญของการจะทำอย่างอื่นครับ ถ้าตรงนี้ไม่ดี แต่เน้นทำพวก services and applications เยอะ ๆ ก็จะบูรณาการกันไม่ได้ เสียเงินมากมายทำแอพมากมายที่ใช้ประโยชน์ได้ไม่เต็มที่ เป็นต้นครับ

Leave a Reply

Your email address will not be published.