พอดีผมเห็นในเว็บของอ.ชัชชาติมีนโยบายเรื่องการบูรณาการข้อมูลสุขภาพ และมีช่องให้สามารถเสนอความเห็นได้ ตัวผมเองมีความเห็นเรื่องนี้อยู่จำนวนหนึ่ง จึงอยากนำเสนอเช่นกันครับ และถือโอกาสเสนอให้ทุกท่านด้วยนะครับ เห็นด้วยไม่เห็นด้วยอย่างไรแลกเปลี่ยนกันได้ครับ
หมายเหตุ
- สิ่งที่เขียนนี้เป็นความเห็นส่วนตัวของผม ไม่เกี่ยวกับหน่วยงานที่ผมสังกัดนะครับ
- ขอเขียนแบบใช้ภาษาธรรมดา ๆ ไม่ได้เขียนแบบเป็นทางการนะครับ อันนี้ก็ไม่ได้เตรียมจะเขียนมาก่อน นึกจะเขียนก็เขียนขึ้นมาเลยครับ ว่าจะส่งข้อเสนอสั้น ๆ ไป ๆ มา ๆ ยาวครับ
- ทั้งหมดนี้เป็นข้อเสนอ ณ วันนี้ ในอนาคตหากสภาพแวดล้อมเปลี่ยน เทคโนโลยีเปลี่ยน ข้อเสนอเหล่านี้อาจไม่สอดคล้องกับสภาพแวดล้อมได้
ภาพ 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 ประการ
- ความสามารถในการส่งข้อมูลมาเข้าร่วมระบบได้ต่างกัน ซึ่งสืบเนื่องมาจากระบบ HIS ที่แต่ละรพ. สามารถเก็บข้อมูลในรูปแบบที่มีโครงสร้าง (structured data) ได้มากน้อยต่างกัน ซึ่งส่วนใหญ่แค่เก็บเป็น digital ไม่ใช้กระดาษได้นี่ก็น้อยแล้ว น้อยรพ.มาก ๆ ที่จะเก็บในรูปแบบที่มีโครงสร้างที่ดี บางรพ. มีโครงสร้างดี แต่ก็อาจไม่ได้เอามาตรฐานด้านรหัสมาใช้อีก ทำให้บูรณาการกันไม่ได้อยู่ดี
- ความไว้ใจในการส่งข้อมูลมาเข้าระบบ อันนี้จริง ๆ เป็นปัญหาเชิงการจัดการมากกว่า ซึ่งจริง ๆ ผมก็เข้าใจทั้งสองฝ่ายนะครับ อาจต้องหาทางจัดการตรงนี้
- ข้อจำกัดต่อมาไม่เชิงเป็นของ HealthLink แต่เป็นของทุกระบบที่ใช้ FHIR นั้นคือ FHIR เป็นมาตรฐานที่ออกแบบมากว้าง ๆ การจะนำไปใช้จริงต้องมีการมาปรับแต่งเพิ่ม ซึ่งปกติประเทศที่มีความก้าวหน้าด้านนี้เขาก็จะมีความร่วมมือในระดับประเทศที่จะสร้าง national implementation guide ออกมา เช่น US-Core แต่ไทยเรายังไม่มีตรงนี้ ดังนั้น คนละโครงการ ใช้ FHIR เหมือนกัน ไม่ได้แปลว่าจะคุยกันรู้เรื่องครับ
- ยังไม่นับว่า มีอีกหลายโครงการที่นิยมออกแบบมาตรฐานใหม่ ซึ่งก็มีทั้งสถานการณ์ที่เหมาะและไม่เหมาะนะครับ ข้อดีคือ ออกแบบใหม่ก็เร็วดี และตอบโจทย์นั้น ๆ แต่ข้อเสียคือแลกเปลี่ยนกับคนอื่นไม่ได้ มีแบบนี้เยอะ ๆ สุดท้ายคือเกิด silo ที่แลกอะไรกันไม่ได้เลยเหมือนทุกวันนี้
ข้อเสนอทางแก้
ผมว่า framework ที่ดีสำหรับทำเรื่องนี้ก็คือของ WHO-ITU ที่บอกว่าจะทำเรื่อง eHealth/digital health ต้องมีอะไรบ้าง ซึ่งตอนนี้ผมว่าสิ่งที่เราขาดที่สุดคือ leadership and governance นี่แหละครับ พอ stakeholder เยอะ แต่ governance ไม่ชัด ทุกอย่างก็สับสนไปหมด
ดังนั้น ขอเสนอดังนี้ครับ
- หาทางออกให้ได้ว่าจะใช้กลไกใดในการ governance เรื่อง digital health ในประเทศ (หรือในกทม.) โดยที่จะทำงานร่วมกับ stakeholder ทั้งหมดได้ แต่ก็ขับเคลื่อนไปงานไปได้
- จัดทำ 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 เยอะ ๆ ก็จะบูรณาการกันไม่ได้ เสียเงินมากมายทำแอพมากมายที่ใช้ประโยชน์ได้ไม่เต็มที่ เป็นต้นครับ
