ผมมีโอกาสได้สนทนากับ startup, software house หรือผู้พัฒนา Hospital Information System (HIS) อยู่บ้าง (เคยเขียนเรื่อง HIS vendor ในไทย หากท่านใดสนใจครับ อาจเริ่มล้าสมัยนิด) คำถามหนึ่งที่มักจะได้รับคือ pain point ของรพ.ตอนนี้คืออะไร จะพัฒนา solution อย่างไรดี? บทความนี้เป็นความเห็นของผมต่อคำถามดังกล่าว
ผมรู้สึกว่าการดำเนินงานรพ.ในยุคปัจจุบัน มักมีการชักกะเย่อกันระหว่างสองฝั่ง โดยมี stakeholder ต่าง ๆ เป็นกองเชียร์ หรือผู้ชม ที่เชียร์แต่ละฝ่ายต่างกันไปในแต่ละโอกาส
- ฝั่งซ้าย คือ ความพยายามเปลี่ยนแปลง การ optimize process (เช่น ทำ lean) การสร้างนวัตกรรมใหม่ ๆ
- ฝั่งขวา คือ ความพยายามรักษาสภาพที่เป็นอยู่ การทำตามกฎหมาย ระเบียบข้อบังคับ รวมไปถึงพวกมาตรฐานต่าง ๆ ที่รพ. ทำ (HA, JCI, ฯลฯ)
ความสัมพันธ์เชิงอำนาจ
แน่นอนว่าผู้บริหารเป็นกลุ่มที่มีอำนาจสูงที่สุดก็จริง อันนี้ตรงไปตรงมา แต่การตัดสินใจมักได้รับอิทธิพลจากกลุ่มอื่น ๆ
- ผู้คุมกฏ: กลุ่มนี้แทบจะเรียกได้ว่าถือดาบอาญาสิทธิ์ บอกมาว่าเสี่ยงจะผิดกฎหมายคำเดียว ถ้าสรุปว่าผิดจะโดน xxx ไม่มีใครรู้ด้วยหรอกว่าผิดจริงไหม แต่จะไม่มีใครกล้าขัด (แต่ถ้ากฎหมายโทษเบาคนก็จะไม่กลัว ระดับพลังจะลดลง) อันนี้รวมไปถึงคนที่คุมเรื่องการเคลม หรือเรื่องมาตรฐาน (เช่น สมมติรพ. กำลังทำ HA) อ้างมาคำเดียวว่า HA บอกให้ทำแบบนั้นแบบนี้ คนส่วนใหญ่จะไม่เถียง ยกเว้นบางคนอาจจะไปเช็คว่า HA บอกจริงไหม กลุ่มนี้ไม่จำเป็นต้องเป็นพนักงานในโรงพยาบาล อาจเป็นที่ปรึกษาภายนอก ที่ปรึกษากฎหมาย ที่ปรึกษาคุณภาพ เป็นต้น
- แพทย์: อันนี้เปรียบเหมือนเป็นผู้มีบารมีนอกรัฐธรรมนูญ แม้ว่าโดยโครงสร้างมักต้องไปอยู่ใต้ใครซักคน แต่ด้วยอะไรซักอย่าง (ด้วยวัฒนธรรมที่เป็นมา ด้วยความเป็นจุดขายของรพ. ฯลฯ) กลุ่มนี้มักเป็นกลุ่มที่มี power สูงในรพ. ถ้าเขาเอาด้วยก็สบาย ถ้าเขาไม่เอาด้วยจะเหนื่อยหน่อย
- พนักงานอื่น ๆ สายคลินิก: ผมว่าโรงพยาบาลเป็นหน่วยงานที่รูปแบบการปกครองมีความ hierarchy ค่อนข้างสูง เอาจริง ๆ ผมว่าการบังคับบัญชามีความคล้ายทหารตำรวจ เพราะฉะนั้นถ้าหัวหน้าว่าไง ลูกน้องมักไม่ค่อยขัด ไม่ว่าสิ่งที่ให้ทำมันจะ make sense หรือไม่ อย่างไรก็ดี ในระดับปฏิบัติงาน ถ้าเขาไม่อยากทำอะไร เขาจะมีท่าไม้ตายอยู่ โดยการบอกว่า “ไม่มีเวลา คนไข้เยอะ” หรือ “ทำแล้วคนไข้ไม่ชอบ” ซึ่งก็ไม่ค่อยมีคนเถียงเขาได้
- พนักงานสายอื่น ๆ: ส่วนใหญ่มักเป็นหน่วยสนับสนุนบริการ ซึ่งมักไม่ค่อยมีปากมีเสียง ยกเว้นบางแผนกที่อาจจะมี power ของตัวเองในบางระดับ
- คนไข้: อันนี้แล้วแต่ว่าโรงพยาบาลนั้น ๆ ให้ความสำคัญกับคนไข้มากน้อยแค่ไหน ถ้าให้เยอะก็จะมี power เยอะ complaint ครั้งเดียวสะเทือนทั้งรพ. แต่ถ้าไม่เยอะก็อาจจะไม่มีปากมีเสียงเท่าใด (ซึ่งน่าเศร้านะครับ)
- บริษัทคู่สัญญา-พันธมิตร: ถ้าทำธุรกิจกันราบรื่นดี ก็มักไม่ค่อยได้มาเกี่ยว
- ชุมชน-สังคม: ถ้าไม่มีข่าวใหญ่ ๆ ก็มักไม่ค่อยได้มาเกี่ยวเท่าไหร่
เพราะฉะนั้น สมมติว่าฝ่ายบริหารอยากทำจะมีนวัตกรรมใหม่ ๆ ในองค์กร กลุ่ม stakeholder เหล่านี้ต้องดีลกันลงตัว
ความท้าทาย
- การปฏิบัติตามกฎหมายหรือการทำตามมาตรฐาน สิ่งที่มักจะตามมาคือ ขั้นตอนการทำงานที่เยอะขึ้น ซับซ้อนขึ้น จากเดิมทำสิบขั้น กลายเป็นทำร้อยขั้นตอน วิธีง่ายที่สุดในการ implement เรื่องเหล่านี้ก็คือการสร้างแบบฟอร์มใหม่ เช็คลิสต์ใหม่ คนได้ประโยชน์คือคนไข้ แต่คนเสียประโยชน์คือพนักงานที่มักมีงานงอก (แต่มองอีกมุมเขาก็ได้ประโยชน์เช่นกัน เพราะลดความผิดพลาดในงานได้ คนไข้ประทับใจมากขึ้น)
- การพยายามนำนวัตกรรมใหม่ ๆ เข้ามาในองค์กร มักจะต้องไปแตะเรื่องกฎหมายหรือเรื่องมาตรฐาน เช่น สมมติเราจะทำ lean ในองค์กร ถามว่าจะทำ lean ยังไงให้ยัง comply กับขั้นตอน 100 ขั้นที่เพิ่งใส่เข้ามาเดือนที่แล้วตอนทำมาตรฐาน ? อันนี้ก็ไม่ง่าย
- ผมจึงบอกว่าสองฝั่งนี้มักมีความชักกะเย่อกัน
- ผู้รับบริการ (คนไข้ ญาติ) มักจะเชียร์มาทางฝั่งเปลี่ยนแปลงมากกว่า
- พนักงาน จะแบ่ง ๆ กันไปเชียร์สองข้างแล้วแต่เรื่อง ถ้าเปลี่ยนแล้วชีวิตดีขึ้นก็อยากเปลี่ยน แต่บางทีก็กลัวการเปลี่ยน
- ผู้บริหาร แบ่ง ๆ เชียร์สองข้างเช่นกัน อยู่ที่ความคุ้มค่า
HIS เป็นสิ่งที่มีขึ้นเพื่อสนับสนุนบริการของโรงพยาบาล แต่การ implement HIS ใหม่อย่างเดียวไม่พอ ถ้า process ที่เป็นอยู่เดิมไม่ดี เอาระบบใหม่เข้าไปก็ไม่เปลี่ยนอะไร
ผู้พัฒนา HIS ควรทำมากกว่า software
ผมก็ไม่รู้ควรเรียก solution นี้ว่าอะไร สมมติเรียกว่า digital transformation consulting service ละกันครับ ซึ่งประกอบด้วย
- ต้องมีทีมที่ดีลกับกลุ่มผู้คุมกฎได้ ต้องแม่นกฎหมายและมาตรฐานในระดับที่จะวัดพลังกับผู้คุมกฎเดิมได้ว่า solution ที่กำลังนำเสนอนี่มันไม่ผิดแน่ ๆ
- มีบริการ business process re-engineering หรือทำ lean เรียกอะไรก็แล้วแต่ แต่ต้องมีทีมไปเคลียร์เรื่อง business process ให้ได้ก่อนจะเอา IT เข้าไปใส่ ซึ่งไม่ง่ายนะครับ ต้อง involve คนเยอะมาก อยู่ ๆ เป็นคนนอกเดินไปบอกให้เขาเปลี่ยนเขาไม่เปลี่ยนนะ ถึงจะบอกว่าเป็นเทพ BA/SA วิเคราะห์มาให้ก็ตาม ส่วนตัวผมเชื่อว่าจะปรับ process สำเร็จได้มันต้องเป็นกระบวนการแบบทำไปด้วยกัน และทำซ้ำ ๆ หลาย ๆ รอบเป็น iterative process
- เมื่อสร้าง IT solution ขึ้นมา ก็ต้องทำให้ comply กับกฎเกณฑ์ต่าง ๆ ที่เป็นอยู่ และทำให้หน้างานทำงานง่ายขึ้น เร็วขึ้น มีคุณภาพมากขึ้น
- ควรจะมีหมอในทีม (อยู่เป็นมาสคอตเฉย ๆ ไม่ต้องทำอะไรก็ยังดี) เพราะหมอจะเชื่อหมอมากกว่า แต่อันนี้ส่วนใหญ่ก็มีอยู่แล้วแหละ
- นอกจากนั้นก็ project management, ทีม IT (BA, SA, dev, UI/UX, tester, etc.) ซึ่งพวกนี้ทุกบริษัทก็คงมีอยู่แล้ว
- ความยากคือ จะทำยังไงให้ได้ทั้งหมดนี้ โดยที่ราคาก็ไม่สูงด้วย
ผมเสนอว่า เวลาเข้าไปขาย ให้ขายเป็น complete solution เลย ซื้อบริการของเราแล้ว รพ.จะมีระบบการให้บริการที่ดี รวดเร็ว ผู้รับบริการประทับใจ ในขณะเดียวกันเข้ากับบริบทและวัฒนธรรมขององค์กร และ comply กับกฎหมาย ระเบียบข้อบังคับ และมาตรฐานทุกอย่าง ทั้งหมดนี้ enable ด้วยระบบ IT
เปลี่ยนการชักกะเย่อเป็นการช่วยกันดึง
แล้วเรื่อง software ล่ะ
อันนี้ก็ไม่ได้มานั่งคิดละเอียด แต่ผมคิดว่า HIS ในยุค 2022 นี้ควรมีคุณสมบัติอย่างน้อย 4 ข้อต่อไปนี้
- Adopt เอา health information standard มาใช้ ตั้งแต่ level ของ information model อย่างน้อย ๆ ก็ดู FHIR ไว้เป็นตัวอย่างก็ยังดี ผมเห็นมาเยอะมากที่พยายามออกแบบเอง คือแม้ว่าเราจะคิดว่าสิ่งที่เราออกแบบมันดี แต่จริง ๆ มันไม่ได้ดีน่ะครับ และตอนนี้ไทยเราเป็นประเทศสมาชิกของ SNOMED International แล้ว ควรใช้ประโยชน์จากตรงนี้ให้มาก จะทำให้คุณได้เปรียบชาวบ้านไปไกล ตอนทำเรื่อง data analytics
- แถม: UI/UX designer ที่จะออกแบบระบบ HIS ควรมีความเข้าใจใน good health information model เช่นกันนะครับ เพราะถาม user ว่าเขาอยากได้อะไร เขามักจะมองไม่เห็นความซับซ้อนที่ซ่อนอยู่ข้างใต้
- หลังจากที่มี information model ที่ดี สิ่งที่ควรมีต่อคือพวก low-code/no-code solution ที่ให้ user สามารถลาก ๆ วาง ๆ เกิดเป็น UI และ workflow ของแอพง่าย ๆ ได้เลย โดยเก็บข้อมูลตาม information standard ฟีเจอร์นี้จะทำให้ทางบริษัทลดแรงในการ dev ได้เยอะมาก เพราะรพ. มีแบบฟอร์มเป็นร้อย ๆ อัน ส่วนใหญ่เป็นการเก็บข้อมูลแบบพื้นฐาน ถ้าเรามี form builder ให้ user ทำเองได้ จะทำให้นวัตกรรมในรพ. เกิดง่ายขึ้น
- จริง ๆ ผมเชียร์ open platform เป็นการส่วนตัว แต่หากไม่ได้ อย่างน้อย ๆ ควรเป็น open API สามารถเขียนแอพมาต่อยอดได้ และควรเป็น loosely coupled คือไม่ต้องพยายามทำตัวเป็น megasuite ควรทำตัวเป็น component ย่อย ๆ ถ้า user เขาชอบเขาก็ใช้เอง เขาไม่ชอบก็เปิดให้เขาไปเอา solution อื่นมาแทนใน component นั้น ๆ ได้ง่าย ๆ
- ในแง่ user interface ผมเชื่อว่าในยุคนี้ การบันทึกข้อมูลเป็นภาพมีความสำคัญมาก ถ่ายรูปแผล รูปอาการที่ผิวหนัง ถ่ายวิดีโออาการแสดง ระบบควรทำให้การบันทึกภาพเข้าไปใน electronic medical records (EMR) เป็นสิ่งที่ทำได้ง่าย เช่น ตรวจด้วย desktop แต่หยิบมือถือมาถ่ายรูป ภาพเข้าไปดูต่อใน desktop ได้เลย
ก็จบแล้วครับ จริง ๆ คือ ถึงแม้เราเป็นฝั่งรพ. ที่กำลังจะทำ digital transformation แต่เราไม่สามารถหา HIS vendor ที่ตรงกับที่เราต้องการได้ เราก็ควรมีทีมเหล่านี้ในองค์กรนะครับ
