โปรแกรม รพ. หรือเราจะเรียกว่า HIS หรือ EMR ก็ได้ เคยสงสัยกันมั้ยครับว่าทำไม จะแก้อะไรมันถึงได้ยากเย็นเข็นใจ ในขณะที่พวกแอพต่างๆ แป๊ปๆ เดี๋ยวก็อัพเดต เปลี่ยนหน้าตา ฟังก์ชั่นต่างๆ กันแทบทุกเดือน
สมัยผมทำงานเป็นแพทย์ (จริงๆสมัยนี้ก็ยังเป็นแพทย์อยู่นินา) สิ่งที่กวนใจที่สุดคือ ทำไมโปรแกรมมันเปลี่ยนให้เป็นแบบนี้ไม่ได้ แบบนั้นไม่ได้ อยากให้มีช่องแยกยาประจำกับไม่ประจำออก เวลากด remed มันจะได้ไม่ต้องไป remed ยาไม่ประจำ (พวกยาแก้ปวด อะไรพวกนี้) หรือ อยากให้มันโชว์ DTX ในหน้าตรวจเลยได้มั้ย จะได้ไม่ต้องกดเปิดไปดูผลอีกหน้านึง หรือจริงๆ แล้วหน้าตรวจคนไข้ NCD มันไม่ควรมีหน้าตาเหมือนหน้าตรวจทั่วไปนะ แต่สิ่งที่ฝันนั้นดูจะเป็นไปไม่ได้เลยด้วยซ้ำเมื่อเสนอ ผอ.ไป แน่ล่ะ ผอ.ไม่ใช่คนสร้างโปรแกรมนี่นา เขาก็คงแก้อะไรไม่เป็น แต่กระนั้นเลย เราเอาเงินจ่ายไปให้เขาก็ควรแก้ให้รึเปล่า แต่ทั้งๆ ที่มีเงิน มันกลับทำไม่ได้ หรือทำได้ ก็ใช้เวลานานมากกกกกกกก จนกว่าจะแก้เสร็จเราก็ออกจากที่นั่นแล้ว
1. เงินไม่ถึง
ผมมีความเชื่ออย่างหนึ่งว่า ปัญหาทางโปรแกรมสามารถแก้ได้ด้วยเงิน แต่ที่แก้ไม่ได้ก็คือเงินไม่มากพอ คำว่าเงินไม่มากพอ ไม่ใช่เพราะว่า บริษัทเจ้าของโปรแกรมหน้าเลือดนะครับ(แต่หลายกรณีก็เป็นเช่นนั้น) แต่เพราะการแก้ไขโปรแกรมสักอย่างหนึ่ง มันอาจจะไม่ได้ง่ายขนาดนั้น ผมอาจจะต้องการแค่ ช่องแยกยาประจำกับยาไม่ประจำ แต่มันอาจจะต้องไปแก้ฐานข้อมูล ฟังก์ชั่นต่างๆ ที่มีอยู่เดิม ซึ่งให้อธิบายก็คงคล้ายๆการสร้างตึก เราเข้าไปอยู่ในห้องเราแล้ว เราบอกว่า เสานี้มันเกะกะ เอาออกได้มั้ย แต่เสาที่เกะกะเรามันเป็นเสาที่รับน้ำหนักโครงสร้างตึกอยู่ ถ้าจะบอกให้เอาเสาออก บอกให้ทุบทิ้งสร้างใหม่ยังง่ายกว่า โปรแกรมก็ไม่ต่างกันกับการสร้างบ้านเท่าไหร่ เพียงแต่เรามองไม่เห็นความใหญ่ของมันแบบที่จับต้องได้เท่านั้นเอง เพราะฉะนั้นการแก้ไขโปรแกรมแต่ละอย่างบางทีอาจจะเป็นจุดเล็กๆแต่มันอาจจะใช้ค่าใช้จ่ายสูงกว่าที่เราคิดมาก เพราะเขาต้องใช้คนเยอะขึ้นในการแก้
2. สถาปัตยกรรม
ต่อเนื่องมาจากข้อที่แล้ว ถ้าตอนเริ่มสร้างตึก คนสร้างตึกวางแผนมาว่า ตึกนี้สามารถจะเอาเสาเลื่อนไปเลื่อนมาได้ การเลื่อนเสามันก็เป็นสิ่งที่เป็นไปได้ ไม่ต่างกันเลยกับโปรแกรม หากเขาวางแผนมาตั้งแต่ต้นว่าโปรแกรมจะสามารถแก้ไข หน้าจอ การแสดงผล ตรงนั้นตรงนี้ได้ในอนาคต การแก้ไขนั้นก็ไม่ใช่เรื่องยากแล้ว ขั้นตอนตรงนี้อาจจะยากที่จะรู้ได้ ถ้าเราไม่ได้ทำงานในสาย IT แต่สิ่งที่เราทำได้คือ ถามตั้งแต่แรกครับ เราอาจจะไม่ได้ต้องการฟังก์ชั่นนี้ตอนนี้ เพราะเรายังไม่มีคนไข้แบบนี้ แต่เราสามารถถามคนทำโปรแกรมได้ว่า ทำให้อนาคตเพิ่มฟังก์ชั่นนี้เข้ามาได้มั้ย อย่าคิดแค่ปัจจุบัน ให้วางแผนยาวๆ ถ้าเราบอกเขาก่อน เขาก็สามารถวางสถาปัตยกรรมที่จะรองรับความต้องการในอนาคตของเราได้
3. ผูกขาด
โปรแกรมสมัยใหม่ มักจะออกแบบมาให้เชื่อมต่อกับระบบอื่นๆ ได้ง่าย จริงๆ ถึงแม้ไม่ใช่โปรแกรมสมัยใหม่ แต่การเชื่อมต่อกับระบบอื่น ถ้าจะทำจริงๆ มันก็ไม่ได้ยากมากมายขนาดนั้น โดยเฉพาะการเชื่อมต่อแบบขาเดียว คือ ให้ระบบอื่นเข้ามาอ่านข้อมูลของระบบเก่าเฉยๆ แต่ไม่ได้ไปแก้หรือเพิ่มเติมอะไรในข้อมูลของระบบเก่า ระบบเก่าคือแทบไม่ต้องทำอะไรเลย แต่หลายๆ ครั้งเจ้าของระบบเก่า ก็ไม่ยอมหรือคิดค่าใช้จ่ายแพงมากๆ กับการเชื่อมต่อระบบแบบนี้
โปรแกรมเล็กๆ ที่เอามาช่วยงานที่ระบบ HIS เดิมทำไม่ได้ ก็เลยมักมีปัญหาติดคอขวดในข้อนี้มาก เพราะฉะนั้นแทนที่เราจะแก้ปัญหาได้ในราคาย่อมเยาว์กลายเป็นว่าเราต้องจ่ายเกินกว่าเหตุในเรื่องที่ไม่ควรต้องจ่าย
เพราะฉะนั้นหากเรากำลังมองหา HIS อันใหม่ คำถามที่ต้องถามเขาเลยคือ มีระบบ API เชื่อมต่อกับโปรแกรมอื่นในอนาคตได้มั้ย สามารถส่งข้อมูลไปกลับได้หรือไม่ คิดค่าการเชื่อมต่อกับระบบอื่นๆอย่างไร หรือแม้แต่เมื่อถึงวันใดอยากเลิกใช้แล้วจะส่งต่อข้อมูลให้ HIS อันใหม่ได้อย่างไร หากเขาตอบอ้ำๆ อึ้งๆ ผมไม่แนะนำให้ใช้บริการ HIS เจ้านั้นเลย
4. Waterfall
ตัว รพ.เองไม่เข้าใจกระบวนการทำ software สมัยใหม่ และไม่มีนโยบายตอบสนองต่อเรื่องนี้
เรื่องนี้ภาพที่เห็นชัดที่สุดคือ TOR ครับ ปกติเวลา รพ.จัดซื้อจัดจ้างอะไร เราต้องกำหนดสเป็คขึ้นมา เช่น เราจะซื้อปากกาเราก็กำหนดมาว่า ปากกาต้องเป็นลูกลื่นหรือหมึกซึม หัวกี่มิล อะไรแบบนี้ แต่กับ software แล้วหลายครั้งการกำหนดสเป็คไปอย่างชัดเจน แน่นอนนั้นจะทำให้เราได้ SOFTWARE ที่อาจจะไม่ตอบโจทย์เราเท่าไหร่ โดยเฉพาะถ้าเราเป็น รพ.ขนาดใหญ่ที่มีความซับซ้อนสูง ที่แม้แต่ตัวเราเองก็อาจจะไม่แน่ใจด้วยซ้ำว่าโปรแกรมที่ตอบโจทย์เราหน้าตาควรเป็นยังไง การเขียนสเป็ค TOR อาจทำให้เกิดลักษณะของการทำงานแบบ Waterfall ในภาษาของโลก IT นำมาซึ่งสิ่งที่เราไม่คาดหวัง ผมเองก็เคยเห็นระบบหลักหลายร้อยล้านพังและสูญเปล่ามาแล้ว (แน่นอนว่าเงินก็ไม่ได้คืนด้วย) ด้วยการพัฒนาแบบนี้ เพราะเรากำหนดไปที่สเป็ค แต่ไม่ได้กำหนดว่าโปรแกรมจะใช้งานได้จริงหรือไม่เมื่อเริ่มใช้งาน
แล้วรพ.ควรทำอย่างไรล่ะ?
เรื่องแรกคือทำความเข้าใจการทำงานพัฒนา software สมัยใหม่ว่าเป็นเช่นไร ให้คีย์เวิร์ดไว้ว่า Agile เชื่อว่าสามารถตามหาคอนเท้นท์อ่านกันเองได้ไม่ยาก และหาวิธีที่เหมาะกับการจ้างงานแบบ Agile มากกว่า เช่น การจ้างงานแบบ Time and Material จริงๆ แล้ว หากเราไม่แม่นในเรื่อง IT ผมแนะนำให้จ้างที่ปรึกษาที่ไว้ใจได้ให้มาช่วยประเมินให้ก็จะทำให้การเลือกมันง่ายมากขึ้นนะครับ
แต่สุดท้ายแล้วไม่ใช่ว่าจ้างที่ปรึกษามาแล้วจะจบ สิ่งสำคัญคือเราต้องดูเองด้วยว่า ระบบที่เราอยากให้เป็นในปัจจุบัน และระบบที่เราอยากให้เป็นในอนาคต มันจะเป็นยังไง ยิ่งลิสต์ออกมาได้เป็นข้อๆ ละเอียดได้แค่ไหน การคุย การต่อรองมันก็จะง่ายขึ้น ไม่ต้องปวดหัวทีหลัง