ทุกวันนี้โลกธุรกิจมักพูดกันถึงคำว่า platform กันมาก ซึ่งก็มีคนนิยามและจัดหมวดหมู่กันหลายแบบมาก แต่ผมขอโฟกัสเฉพาะ IT platform และให้นิยามง่าย ๆ เลยนะครับว่า platform ก็คือ ระบบที่อนุญาตให้ software จากนักพัฒนาอื่นมาต่อยอดจากระบบของตนเพื่อประโยชน์ต่าง ๆ ครับ
ก็มาสู่ประเด็นต่อมาว่าแล้วอะไรคือ open กับ close platform อันนี้ก็มีนิยามมากมายอีก แต่สำหรับผม ผมคิดว่า close platform ก็คือ platform ที่เจ้าของ platform มีการควบคุมอย่างเข้มงวด อาจจะในรูปแบบการควบคุมแอพหรือเนื้อหาต่าง ๆ หรืออาจในรูปการจะพัฒนาได้ต้องใช้ API เฉพาะที่ต้องซื้อไลเซนส์ เป็นต้น ส่วน open platform ก็คือด้านตรงข้าม เช่น ไม่ควบคุมแอพหรือเนื้อหา (อยากลงโปรแกรมจากทางไหนก็ลง อยากดูอะไรก็ดู) หรือพัฒนาโดยใช้ API ที่เปิดให้สาธารณะเข้าดูได้ เป็นต้น (แต่ open platform ไม่จำเป็นต้องเป็น open source นะครับ)
ซึ่งในโลกความเป็นจริงเรามักไม่สามารถขีดเส้นแบ่งได้ชัดเจนว่า platform ไหนคือ close หรือ open ครับ ในวงการ health IT ก็เช่นกันครับ ไม่รู้ว่าสรุปเปิดแค่ไหนถึงเรียกว่าเปิดกันแน่ ตัวผมเองได้รับอิทธิพลค่อนข้างมากเรื่องนิยามของ open platform มาจาก openEHR community ครับ และผมคิดว่าแนวคิด open platform นี้เป็นแนวคิดที่ดีครับ จึงอยากนำมาเขียนเป็นบทความในวันนี้
แม้ว่าแนวคิดเหล่านี้จะนำมาจาก openEHR แต่เราสามารถนำไอเดียในนี้ไปใช้ได้โดยไม่จำเป็นต้องใช้ openEHR นะครับ
Health Care Open Platform ควรมีคุณสมบัติอย่างไร
สำหรับเนื้อหาหลักในส่วนนี้ ผมนำแนวคิดนี้มาจากเอกสาร Defining an Open Platform โดย Apperta Foundation ครับ และผมขอเสริมแต่ละเรื่องตามความเข้าใจและความเห็นของผมเองด้วยครับ
1. มีฐานมาจาก Open Standard
Platform นั้นควรจะสร้างมาจากมาตรฐานเปิด (open standard) คือทุกคนที่จะนำ platform ไปใช้ (implementer) ควรสามารถเข้าถึง platform spec และสามารถสร้างระบบที่ comply (สอดคล้อง) กับ platform ได้โดยไม่มีค่าใช้จ่าย
2. มีการใช้ Information Model ร่วมกัน
Information model เป็นสิ่งที่สำคัญมากที่จะทำให้เกิด semantics interoperability ได้ เพราะการจะทำให้เกิดได้เราต้องให้ระบบสองระบบ 1) เข้าใจโครงสร้างข้อมูลแบบเดียวกัน ซึ่งอันนี้แหละครับหน้าที่ของ shared information model (นึกถึง FHIR ก็ได้ครับที่ต้องไป define โครงสร้างของ JSON มากมายกว่าจะแลกกันได้) และ 2) เข้าใจเนื้อหาแบบเดียวกัน ซึ่งอันนี้เป็นหน้าที่ของ terminology เช่น SNOMED-CT, LOINC, ICD-10, ValueSet ฯลฯ
3. สามารถย้าย application ข้ามระบบได้
นึกถึง Android ก็ได้ครับ เราทำแอพครั้งเดียวเรารันในมือถือ Android ยี่ห้อไหนก็ได้ใช่ไหมครับ อันนี้ก็คือแนวคิดเดียวกัน สมมติมี HIS 2 ยี่ห้อจากคนละบริษัท คือ HIS A และ HIS B โดยที่ทั้งสอง comply กับ platform ทั้งคู่ ถ้าเราทำ app มาเชื่อมต่อกับ HIS A ก็ควรสามารถนำไปรันใน HIS B ได้โดยทันที ไม่ต้อง data mapping ไม่ต้อง custom ให้แต่ละ platform
4. Federatable
คำนี้อาจเข้าใจยากนิดนึงครับ คือหมายถึง platform implementation ทั้งหมดต้องสามารถเชื่อมต่อกันได้กลายเป็น platform implementation ที่ใหญ่กว่า เช่น ระบบรพ.ชุมชนหลาย ๆ รพ.ในเครือข่ายมาเชื่อมกัน (แม้ทุกรพ.จะใช้ HIS คนละเจ้า) ส่วนกลางของจังหวัดก็สามารถคุยกับทุกรพ.ได้ทันที โดยใช้วิธีการแบบเดียวกับตอนคุยกับรพ.ช.เดียว
5. ไม่จำกัด vendor และเทคโนโลยีที่ใช้
Platform แค่ทำการกำหนด spec ของ information แต่ implementer สามารถใช้เทคโนโลยีใดก็ได้ ใช้ database อะไรก็ได้ SQL, NoSQL ใช้ programming language อะไรก็ได้ และทุก vendor ที่เข้าถึง spec ของ platform ก็สามารถสร้าง platform implementation ของตนเองได้
6. สนับสนุน Open Data
ผู้ใช้ platform ต้องสามารถจัดการ (อ่าน/เขียน/แก้/ลบ ฯลฯ) กับ data ที่อยู่ใน platform implementation ตามที่ต้องการได้ (ภายใต้หลักเกณฑ์ทาง data governance ที่ผู้มีส่วนได้ส่วนเสียตกลงร่วมกัน หรือตามกฎหมายของประเทศนั้น ๆ)
7. มี Open APIs
ตรงตัวครับ คือจะสร้างโปรแกรมอะไรมาต่อเชื่อมกับ platform ก็มี API ให้ทำได้ และเป็น API ที่ทุกคนสามารถเรียนรู้วิธีใช้ได้
8. Operability
อันนี้เป็นประเด็น technical แล้วครับ คือเขาจะสื่อว่า platform implementation ควรใช้งานได้ตามที่ระบบไอทีควรจะเป็น เช่น มี scalability รองรับ user ได้เพียงพอ query ข้อมูลได้เร็วพอ เป็นต้นครับ
ทำไมจึงต้องมีคุณสมบัติข้างต้น
1. เมื่อมีการ mapping มักจะมี data loss เกิดขึ้นด้วย
วิทยานิพนธ์ป.เอกของ Sundvall, Erik อธิบายเรื่องนี้ได้ดีครับ (หน้า 15) คุณ Erik บอกว่าเวลา mapping ข้อมูลระหว่าง 2 ระบบ จะมีความเป็นไปได้อยู่ 4 แบบ
- ข้อมูลประเภทเดียวกัน เก็บข้อมูลมาต่างกัน ซึ่ง map อัตโนมัติได้โดยคอมพิวเตอร์ เช่น วัดน้ำหนักกันคนละหน่วย ซึ่งแปลงไม่ยาก
- ข้อมูลประเภทเดียวกัน เก็บข้อมูลมาต่างกัน ซึ่ง map อัตโนมัติไม่ได้ แต่ใช้คนก็พอได้อยู่ เช่น การเก็บประวัติตามในภาพด้านล่าง ต้องใช้คนมาวิเคราะห์ว่าอันไหนจะเป็น medical history อันไหนจะเป็น social history
- ข้อมูลประเภทเดียวกัน เก็บข้อมูลมาต่างกัน ซึ่ง map อัตโนมัติไม่ได้ คนก็ทำไม่ได้ เช่น พวกข้อมูลที่เก็บเป็นช่วง แต่ว่าเก็บกันคนละช่วง
- ข้อมูลคนละประเภทกัน เช่นในตัวอย่างเก็บข้อมูลการใช้สารเสพติด อันนึงเก็บเป็น แอลกอฮอล์และยาสูบ อึกอันเก็บเป็นบุหรี่และ Snuff (ยาสูบแบบอมใต้ลิ้น) สมมติตอบ yes ในยาสูบของระบบ A ก็ไม่รู้ว่าควรจะ yes หรือ no ในระบบ B
เรื่องนี้เป็นปัญหาทั้งในระดับภายในสถานพยาบาลและระหว่างสถานพยาบาล ระดับภายในสถานพยาบาลก็เช่น การเชื่อมต่อข้อมูลระหว่างหลายระบบ หรือดังเช่นที่เกิดบ่อย ๆ ก็เช่นเวลาจะเปลี่ยนระบบ HIS ครั้งหนึ่งก็แลกมาด้วย data loss จำนวนมาก
หากทุกระบบใช้ information model แบบเดียวกัน ก็จะไม่จำเป็นต้อง map และไม่เกิด data loss ปัญหานี้ในไทยอาจไม่ค่อยเห็นภาพเพราะระบบ EMR เราไม่ได้เก็บข้อมูลอะไรกันเยอะ แถมส่วนใหญ่ก็เป็น free text แต่ถ้าไปเห็น EMR ฝั่งตะวันตกจะนึกภาพออกครับ คือเขาใช้ structured data เยอะมาก ๆ (แต่ผมมองว่าวันหนึ่งเราก็จะเป็นแบบนั้นนะ)
หรือการส่งข้อมูลข้ามโรงพยาบาล อันนี้เราก็ต้อง map จากสิ่งที่เก็บในระบบรพ. มาเป็นมาตรฐานกลาง (เช่น FHIR) ก็ data loss ไปรอบนึง สาเหตุก็เพราะ interchange standard มักโฟกัสที่ minimal dataset หรือข้อมูลที่จำเป็นที่สุด (แม้ว่าจะมีระบบ extension) รพ.ต้นทางเลยไม่ได้ส่งข้อมูลที่อยากส่งทั้งหมดได้
หากทุกระบบใช้ information model แบบเดียวกัน จริง ๆ แล้วเราไม่จำเป็นต้องมี interchange standard ด้วยครับ ก็ส่งกันตรง ๆ เลย เหมือนที่มีคนเสนอไอเดียให้ทุกที่ใช้ HOSxP ทั้งจังหวัดเพื่อให้ส่งกันได้ แนวคิดนี้ที่ส่งข้อมูลได้ก็เพราะทุกรพ.ใช้ informaion model เดียวกัน (คือของ HOSxP) ซึ่งจริง ๆ สิ่งที่เราทำได้อีกทางคือไม่ต้องบังคับให้ทุกที่ใช้ HOSxP ก็ได้ครับ แค่ใช้ระบบที่ใช้ information model ร่วมกัน
ปัญหานี้จริง ๆ ก็ไม่ได้ชัดในไทยอีกนั่นแหละครับ เพราะทุกวันนี้เราเก็บข้อมูลกัน minimal กว่า structure ที่อยู่ใน FHIR เสียอีก map ไป FHIR ก็ไม่ค่อยมี loss อะไรหรอกครับ
2. สังคมเริ่มมองว่า mega-suite ไม่ตอบโจทย์
อันนี้เป็นเทรนด์ที่ผมมักได้ยินบ่อย ๆ เวลาฟังบรรยายตามที่ต่าง ๆ ครับ (ขออภัยครับที่ไม่มี reference มาแปะ) mega-suite หรือ software HIS ที่เป็นทุกอย่างให้รพ. นั้น ๆ เป็นทั้ง EMR, RIS, LIS, MPI, Accounting, HR ฯลฯ กำลังได้รับความนิยมลดลง ถ้าเรามองโลกของ ERP เป็นตัวอย่าง ในยุค 80s นั้น สิ่งที่เรียนกว่า ERP ยังไม่เกิด มีแต่ระบบย่อย ๆ (best-of-breed) สำหรับการบริหารงานต่าง ๆ ปัญหาที่เกิดในยุคนั้นคือข้อมูลไม่เชื่อมกัน เต็มไปด้วยการบันทึกข้อมูลซ้ำซ้อน ต่อมาจึงมีคนรวมทุก module แพ็คขายเป็น ERP suite เหมือนทุกวันนี้
แต่สิ่งที่เกิดขึ้นในยุค 2010s เป็นต้นมาคือการเกิดขึ้นของ business software ใหม่ ๆ ที่ใช้ประโยชน์จากเทคโนโลยีสมัยใหม่ เช่น cloud, mobile ได้ดีกว่าผู้เล่นรายเดิมมาก ๆ จน user เห็นประโยชน์และยอมเปลี่ยนมาใช้ระบบพวกนี้ แม้ว่า switching cost จะสูง เกิดเป็นเทรนด์การกลับมาของ best-of-breed อีกรอบ แต่คราวนี้ปัญหาเรื่องการเชื่อมต่อข้อมูลลดลงไปมากแล้ว ในเมืองไทยเราก็เห็นครับ องค์กรบางแห่ง ERP หลักใช้ SAP แต่ก็ซื้อ Saleforce สำหรับงาน CRM, ซื้อ Workday สำหรับงาน HR
เทรนด์แบบเดียวกันกำลังเกิดขึ้นกับการบริหารรพ.ครับ ตอนที่เริ่มมีการนำระบบไอทีเข้ามาใช้ใหม่ ๆ เราก็เริ่มจากมีระบบการเงิน ระบบห้องแล็บ ห้องยา ฯลฯ ทุกระบบเป็น best-of-breed แยกกัน จนต่อมามีคนรวมทุกอย่างไว้ด้วยกันเป็น mega-suite และมายุคนี้คนก็เริ่มรู้สึกว่า mega-suite ไม่ตอบโจทย์ ด้วย 2 เหตุผล
- ไม่มีใครเก่งทุกเรื่องได้ การพยายามจะเก่งทุกเรื่องกลายเป็นไม่เก่งซักเรื่อง
- Innovation มักจะมาจากบริษัทขนาดเล็กที่กล้าจะทำอะไรฉีกแหวกแนวโดยสิ้นเชิง และพวกนี้ทำด้วยความเร็วที่มากกว่าบริษัทใหญ่
สถานการณ์ตอนนี้คือ สมมติเราอยากเปลี่ยนแค่บาง module ของ HIS เรา เราก็เปลี่ยนไม่ได้เพราะทุกอย่างผูกกันไปหมด จะเปลี่ยนก็ต้องเปลี่ยนยกชุด ซึ่ง switching cost ก็สูงมาก (ทั้งในรูปตัวเงิน และไม่ใช่ตัวเงิน) สุดท้ายรพ.จำนวนมากก็เลือกที่จะทน ๆ กันไป เกิดภาวะที่เรียกว่า vendor lock-in
จะดีกว่าไหมหากเรามี platform กลาง ที่ใครอยากจะเปลี่ยน module ไหนก็ได้ตามที่ต้องการ โดยที่ไม่กระทบกับส่วนอื่น ๆ สมมติอยากเปลี่ยนแค่ module ER ก็เปลี่ยนแค่นั้น เปลี่ยนแค่ CPOE ก็เปลี่ยนแค่นั้น การเปลี่ยนระบบก็ไม่ต้องมี data loss เราสามารถสร้าง ecosystem ที่บริษัทใหม่ ๆ สามารถเข้าถึงข้อมูลคนไข้ (โดยมีกระบวนการ governance ที่ดี คนไข้อนุญาต) ด้วยต้นทุนที่ถูก (ไม่ใช่เสียค่า integrate ทีละ 10 ล้าน) เพื่อให้เขาสร้างนวัตกรรมใหม่ ๆ ที่เป็นประโยชน์ต่อคนไข้ได้
3. ประโยชน์ต่อนักพัฒนาทุกระดับ
การสร้าง open platform ข้างต้นมีประโยชน์ต่อนักพัฒนาด้วย อย่างน้อย ๆ 2 ประการ
ประการที่ 1 การแบ่งปันทรัพยากรกัน ทำให้ทุกคนประหยัดต้นทุน
สมมติเราพูดในสเกลระดับ HIS ก็ได้ครับ สิ่งที่ยากที่สุดเรื่องหนึ่งในการทำ HIS ก็คือการทำ information model นะครับ คือทาง vendor ต้องไปคุยกับ user มากมายเพื่อหามาให้ได้ว่า user ต้องการเก็บข้อมูลอะไรบ้าง และจะเก็บอย่างไรถึงจะตอบโจทย์ที่สุด ขั้นตอนนี้กินทรัพยากรสูง
ความซับซ้อนที่ตามมาอีกขั้นก็คือ user เองก็ไม่รู้ว่าตนเองควรเก็บข้อมูลอย่างไร คือเขาก็รู้ในมุมของเขา แต่เขาไม่รู้ในมุมคนอื่น เช่นการวัดความดันโลหิต (blood pressure) คนที่ดูแลผู้ใหญ่ก็สนใจบริบทแบบหนึ่ง คนที่ดูคนไข้เด็กสนอีกแบบ คนที่ดูคนไข้โรคหัวใจสนอีกแบบ การจะสร้าง model ที่ครอบคลุมความต้องการของทุกคนคือจำเป็นต้องไปคุยให้ครบทุกคน
หากเราจะไม่สนความต้องการรายย่อย เราสร้าง model ของคนไข้ผู้ใหญ่แบบนึง คนไข้เด็กอีกแบบ คนไข้โรคหัวใจอีกแบบ สรุปกลายเป็นมีข้อมูลซ้ำซ้อน 3 ที่ โดยไม่แชร์ semantic meaning กันอีก (คอมพิวเตอร์ประมวลผลอัตโนมัติไม่ได้ว่าสามจุดนี้เรื่องเดียวกัน) ใช้ ๆ ไปก่อนอาจไม่มีปัญหา แต่มีแบบนี้มากขึ้นเรื่อย ๆ ถึงจุดหนึ่งจะทำอะไรกับข้อมูลจะยากมาก กลายเป็นระบบที่มี table ใน database มากกว่า 10,000 tables (จริง ๆ นะครับ) จะ query ทีนึง join กันมันส์เลย แถมไม่รู้ว่าอะไรเก็บไว้ตรงไหน คนที่รู้ก็เกษียนไปแล้ว สุดท้ายพอจะ migrate ก็คือทิ้งแทบหมดเลยที่เก็บมาหลายปี เอาไประบบใหม่ไม่ได้
จะเห็นว่าการจะสร้างระบบที่มีประสิทธิภาพ และตอบสนองทุกคนได้ด้วย ต้องใช้ความพยายามสูงมากนะครับ หากทุกคนใน ecosystem ไม่ทำงานซ้ำซ้อน เรื่องนี้เคยมีคนวิเคราะห์ model แล้ว เราไปวิเคราะห์มาเพิ่มแล้วเอามาต่อยอด โดยมีกระบวนการกำกับดูแลที่ทุกคนยอมรับ ทุกคนก็จะประหยัดกันมากขึ้น
การแชร์ทรัพยากรแบบนี้ openEHR ใช้วิธีการสร้างเป็น openEHR CKM ครับ ไว้มีโอกาสจะมาอธิบายเพิ่มเติม
ประการที่ 2 เป็นการขยายขนาดตลาด ทำครั้งเดียวขายได้กับ platform implementation ทุกที่
อันนี้มันก็ชัดครับ เราทำแอพ Android ครั้งเดียว เราขายให้มือถือทุกเครื่องที่ใช้ Android ได้ เราขายหม้อหุงข้าว ลูกค้าเราก็ไปเสียบกับปลั๊กตรงไหนก็ได้ โปรแกรมทาง healthcare ทุกวันนี้เหมือนขายหม้อหุงข้าวแล้วต้องตามไปต่อไฟตรงให้ลูกค้าด้วย ต้องมีการ integrate กับ HIS แต่ละเจ้า ทำครั้งนึงก็ใช้ทรัพยากรสูง ก็เลยต้องขายราคาแพง ก็ทำให้ลูกค้าไม่อยากซื้อเพราะแพง ขายได้น้อยก็เลยต้องขึ้นราคาไปอีกเดี๋ยวบริษัทอยู่ไม่ได้ วนเป็นลูปไปครับ
เราน่าจะ break ออกจากลูปนี้กัน ทำครั้งเดียวขายได้ทุกแห่งที่ comply กับ platform (แม้จะเป็น HIS คนละเจ้า คนละ vendor) การ integrate ทำได้อย่างง่ายดายผ่าน platform services
ตัวอย่างโครงการ open platform ตามแนวทางของ openEHR
สำหรับโครงการต่าง ๆ ทั้งหมด ลองดูรายการบางส่วนได้จาก OpenEHR deployed solutions ครับ (ส่วนใหญ่ในนี้ใช้ solution ของ Better) แต่สำหรับผมเอง มีโครงการที่ผมสนใจเป็นพิเศษอยู่จำนวนหนึ่ง
- HiGHmed (Germany): เป็นโครงการที่ผมติดตามมากที่สุดแล้ว เป็นโครงการเชื่อมต่อข้อมูลของโรงเรียนแพทย์ 1 ใน 4 ของเยอรมนี (ราว 8 แห่ง) โดยเริ่มจากข้อมูล 3 ด้านคือ Oncology, Cardiology, Infection Control เป็นโครงการที่ใช้เงินลงทุนกว่า 150 ล้านยูโร (ค่าเงินปัจจุบันก็ 5,500 ล้านบาท)
- Nasjonal IKT (Norway): เป็น National e-health platform ของนอร์เวย์ มีการสร้าง CKM จากส่วนกลางแล้วทั้งรพ.และ vendors ก็มาช่วยกันสร้าง clinical model กันใน CKM จากนั้นทุกคนก็สามารถนำ model นั้นไปใช้กันได้
- สิ่งต่าง ๆ ที่เกิดขึ้นในจีน (China): เนื่องจากหาข้อมูลค่อนข้างยาก แต่ถ้ามีโอกาสผมก็ตามดูเสมอ มีโครงการ openEHR เกิดขึ้นเยอะมาก ๆ ในจีนครับ
- NHS Scotland (Scotland): ผมทราบมาว่าประเทศนี้ใช้ openEHR เป็น National Digital Platform คืออ่านเจอตามที่ต่าง ๆ แต่หา reference ดี ๆ ไม่เจอเหมือนกันครับ เลยสนใจว่าสรุปทำอะไรกันแน่ครับ
คำถามที่ผมยังตอบไม่ได้
ทั้งหมดที่กล่าวมาข้างต้นก็คืออธิบายเรื่อง open platform ตามแนวทางของ openEHR นะครับ ซึ่งจริง ๆ มีประเด็นที่ผมไม่สามารถตอบได้อยู่หลายเรื่องครับ
Q: หากเราอยากทำ open platform แบบนี้ ในบริบทของประเทศไทย เราจำเป็นต้องใช้ openEHR หรือไม่?
หากบอกว่าอยากทำ shared information model ก็มี information model standard ในโลกมากมายให้เลือก หรือแม้แต่การใช้ FHIR เป็น model ไปเลย ยังไงทุกวันนี้เราก็เก็บข้อมูลน้อยกว่า FHIR อยู่แล้ว
Q: แนวทางนี้เป็นแนวทางที่ดีจริงหรือไม่ ดูเป็นไปได้ยาก เราต่างคนต่างทำระบบตนเองแล้วแลกเปลี่ยนข้อมูลกันแบบ minimal + extension ผ่าน FHIR ไม่พอหรือ?
อันนี้ตอบไม่ได้จริง ๆ ครับ คือถ้าถามตอนนี้ก็คงรู้สึกว่าพอ เพราะที่ผ่านมาเราไม่เคยแลกอะไรกันได้เลย (จริง ๆ ก็อาจพอมีอยู่ เช่น ระบบ refer)
Q: vendor สามารถทำ close platform ที่ให้ผลแบบเดียวกันได้หรือไม่?
สมมติเราจำกัด scope แค่ในประเทศไทย การจะเกิดภาวะข้างบนได้ ผมว่าสิ่งสำคัญก็คือต้องมี vendor เจ้าใดเจ้าหนึ่งซึ่งเชื่อในแนวทางด้านบน (หมายความว่าเขาต้องยอมเปิดหลาย ๆ อย่างที่เคยปิด อย่างน้อย ๆ ก็ API และ data) โดย vendor เจ้านั้นสามารถครองตลาดส่วนใหญ่ของประเทศได้ ก็จะไปคล้าย ๆ กับที่ Android/iOS ครองตลาดมือถือได้ นักพัฒนาก็คงพัฒนา app มาเพื่อระบบของ vendor เจ้านั้นเป็นหลัก ขายในกฎที่ platform กำหนด ใช้เครื่องมือเท่าที่ platform จะให้มา
สมมติว่าเรามี vendor ที่ยอมเปิดหลาย ๆ อย่างจริง ๆ ผมว่าก็เป็นไปได้ยากมากที่จะมีเจ้าใดเจ้าหนึ่งครองตลาดส่วนใหญ่แบบนั้นได้ ยกเว้นว่าเขาจะทำระบบที่ดีแบบทิ้งห่างที่อื่นจริง ๆ สุดท้ายนักพัฒนาก็คงต้อง integrate ทีละ vendor อยู่ดี
แต่เรื่องนี้ก็เหมือนข้อก่อนหน้านี้แหละครับ คือสมมติว่าทุกคนโอเคที่จะ support FHIR แบบนี้นักพัฒนารายย่อยก็ทำโปรแกรมให้ comply กับ FHIR ก็สามารถเชื่อมกับ HIS ทุกเจ้าได้แล้ว ก็คำถามเหมือนเดิมว่าเชื่อมเท่าที่ FHIR มีให้นี่เพียงพอหรือไม่?
แต่เรื่องนี้เองก็ขึ้นกับตลาดโลกด้วยว่าเป็นอย่างไร เหมือนกับว่าเขาใช้ iOS/Android กันหมด เราจะไม่ใช้ก็คงแปลก ๆ แต่ถ้าถามผม ผมว่า open platform ในสเกลระดับโลกจริง ๆ ก็เป็นไปได้ยากเช่นกัน อย่างน้อย ๆ ก็ใน 10 ปีนี้ อย่างมากก็ national แหละครับ
ข้อมูลเพิ่มเติม
- What is an ‘open platform’? โดยคุณ Thomas Beale หนึ่งในผู้ก่อตั้ง openEHR
- OpenEHR day presentation ของหลาย ๆ ท่าน เช่น ที่อิตาลี, ลอนดอน
- วิดีโออื่น ๆ ที่น่าสนใจ Birger Haarbrandt: HiGHmed, 3rd openEHR Summit เหมือนจะมีอีกแต่ลืมแล้วครับ
ก็จบลงแล้วครับสำหรับบทความนี้ เดี๋ยวไว้มีโอกาสหน้าผมจะมาอธิบาย openEHR เพิ่มเติมแบบ technical มากขึ้นนะครับ
