เริ่มทีละโมดูล: ทำไมโครงการดิจิทัลโรงพยาบาลควรเริ่มเล็กแล้วขยาย

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

บทเรียนจากโครงการใหญ่ที่สะดุด

National Programme for IT ของสหราชอาณาจักร

สำนักงานตรวจเงินแผ่นดินของสหราชอาณาจักร (NAO) รายงานในปี 2011 ว่าโครงการ NPfIT ที่เริ่มในปี 2002 มีต้นทุนประมาณการราว 11.4 พันล้านปอนด์ และเงินราว 2.7 พันล้านปอนด์ที่ใช้กับระบบเวชระเบียนผู้ป่วย “ไม่คุ้มค่าเงิน” ในปี 2009 กระทรวงสาธารณสุขเปลี่ยนแนวทางให้หน่วยงานในพื้นที่เป็นผู้นำ เพื่อให้เป็นการเปลี่ยนแปลงที่เล็กลงและจัดการได้มากขึ้นตามความพร้อมของแต่ละองค์กร รายงานปี 2013 ยังระบุว่าเทียบผลกับความคาดหวังเดิมไม่ได้ เพราะไม่ได้จัดทำ baseline ไว้อย่างครบถ้วน

ข้อสรุปของ Wachter Review

รายงาน “Making IT Work” (2016) ที่รัฐบาลสหราชอาณาจักรมอบหมายให้ Robert Wachter ทบทวน สรุปว่าการสั่งการจากส่วนกลาง การขาดการมีส่วนร่วมของบุคลากรคลินิก และไทม์ไลน์ที่เป็นไปไม่ได้ เป็นสาเหตุสำคัญ ข้อเสนอหลักคือทำให้ถูกดีกว่าทำให้เร็ว ทยอยเปลี่ยนเป็นขั้น มองการเปิดใช้ระบบว่าเป็นจุดเริ่มต้นไม่ใช่จุดจบ เตรียมรับประสิทธิภาพงานที่ลดลงชั่วคราวหลังเปิดใช้ และให้มีผู้นำด้านสารสนเทศทางคลินิกในระดับโรงพยาบาล

ความเสี่ยงของการเปลี่ยนผ่านแบบเร่งรัด

งานวิจัยใน Pediatrics ปี 2005 รายงานว่าโรงพยาบาลเด็กแห่งหนึ่งเปิดใช้ระบบสั่งการรักษาทางคอมพิวเตอร์ (CPOE) ทั้งโรงพยาบาลภายใน 6 วัน และพบอัตราการเสียชีวิตของเด็กที่รับส่งต่อเพิ่มจาก 2.80% เป็น 6.57% แต่งานวิจัยปี 2006 จากอีกโรงพยาบาลที่ออกแบบและสนับสนุนการเปลี่ยนผ่านอย่างรอบคอบ ไม่พบการเพิ่มขึ้นของอัตราการเสียชีวิต บทเรียนจึงไม่ใช่ว่าเทคโนโลยีอันตราย แต่คือคุณภาพของการเปลี่ยนผ่านมีผลต่อผู้ป่วยจริง

หลักการเริ่มเล็กแล้วขยาย

• ทำตามขั้นความพร้อม คู่มือการติดตามและประเมินผลนวัตกรรมสุขภาพดิจิทัลของ WHO (2016) แบ่งขั้นเป็นต้นแบบ นำร่อง สาธิต ขยายผล และบูรณาการอย่างยั่งยืน ช่วงแรกดูว่าระบบทำงานตามที่ตั้งใจและเสถียรหรือไม่ ช่วงขยายจึงดูว่าใช้ตามที่ออกแบบและมีคุณภาพหรือไม่
• ทดสอบในวงเล็กก่อน Model for Improvement ของ IHI แนะนำให้ทดสอบการเปลี่ยนแปลงในขนาดเล็กด้วยวงจร Plan-Do-Study-Act (PDSA) แล้วจึงนำไปใช้และขยาย
• นำร่องโดยคิดถึงการขยายตั้งแต่ต้น แนวทาง “Beginning with the end in mind” ของ WHO/ExpandNet แนะนำให้ชุดการเปลี่ยนแปลงเรียบง่าย และทดสอบในสภาพที่ใกล้เคียงกับตอนขยายจริง
• ลดความซับซ้อน กรอบ NASSS (Greenhalgh และคณะ, 2017) พบว่าโครงการเทคโนโลยีสุขภาพที่ซับซ้อนในหลายมิติพร้อมกัน แทบไม่เคยขยายเป็นงานประจำได้

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

เลือกโมดูลแรกอย่างไร

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

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

วัดผลนำร่องก่อนขยาย

เก็บ baseline ก่อนเปิดใช้ ให้นานพอที่จะเห็นรูปแบบปกติของหน่วยงาน แล้วกำหนดตัวชี้วัดเป็นสามชั้น

• ระบบ ทำงานตามที่ตั้งใจหรือไม่ ล่มบ่อยแค่ไหน ตอบสนองเร็วพอหรือไม่
• การใช้งาน ผู้ใช้ใช้จริงในสัดส่วนเท่าใด ใช้ตามที่ออกแบบหรือมีทางลัด และพึงพอใจเพียงใด เช่น วัดด้วย System Usability Scale ซึ่งคะแนนเฉลี่ยจากงานศึกษาจำนวนมากอยู่ราว 68 จาก 100
• ผลลัพธ์ ปัญหาที่ตั้งใจแก้ดีขึ้นจริงหรือไม่ เมื่อเทียบกับ baseline และมีผลข้างเคียงต่อภาระงานหรือความปลอดภัยหรือไม่

กรอบ RE-AIM (Reach, Effectiveness, Adoption, Implementation, Maintenance) ช่วยให้มองครบทั้งการเข้าถึง ผลลัพธ์ การยอมรับ การนำไปใช้ และความยั่งยืน ก่อนเริ่มนำร่อง ควรตกลงเกณฑ์ไว้ล่วงหน้าว่าผลแบบใดจะขยาย แบบใดต้องปรับ และแบบใดควรหยุด

มาตรฐานการเชื่อมต่อกับระบบเดิม

การเริ่มทีละโมดูลทำได้ดีเมื่อโมดูลใหม่เชื่อมกับระบบเดิมได้โดยไม่ต้องรื้อ มาตรฐาน HL7 FHIR ทำให้ระบบแลกเปลี่ยนข้อมูลผ่าน API ที่เป็นมาตรฐาน โดย FHIR R4 เป็นฉบับแรกที่มีเนื้อหาแบบ normative ส่วน R5 (มีนาคม 2023) เป็นฉบับเผยแพร่ล่าสุด และ SMART App Launch ใช้ OAuth 2.0 ให้แอปเชื่อมกับระบบ FHIR อย่างปลอดภัย ในไทยมีคู่มือการนำไปใช้ (Implementation Guide) ภาษาไทย เช่น MoPH-PC-1 ที่แปลงข้อมูล 43 แฟ้มเป็น FHIR แต่ยังไม่ใช่มาตรฐานบังคับระดับชาติ

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

แนวทางแบบโมดูลของ InnoWell

InnoWell ออกแบบโซลูชันเป็นโมดูลที่เลือกใช้และเชื่อมต่อกันตามขอบเขตโครงการ เราเริ่มจากประเมิน workflow ระบบเดิม การเชื่อมต่อ และข้อกำหนดด้านความปลอดภัยของแต่ละโรงพยาบาล แล้วกำหนดขอบเขต baseline และตัวชี้วัดความสำเร็จร่วมกันก่อนเริ่มนำร่อง ผลลัพธ์ของแต่ละโครงการขึ้นกับบริบทและขอบเขตที่ตกลงกัน

Checklist ก่อนเริ่มโมดูลแรก

• ระบุปัญหาหนึ่งข้อที่วัดได้ และมีผู้รับผิดชอบชัดเจน
• เก็บ baseline ก่อนเปิดใช้
• เลือกโมดูลที่พึ่งการเชื่อมต่อน้อย หรือเชื่อมผ่าน API มาตรฐานได้
• กำหนดตัวชี้วัดด้านระบบ การใช้งาน และผลลัพธ์ พร้อมเกณฑ์ขยาย ปรับ หรือหยุด
• นำร่องในหน่วยงานเดียว มีผู้นำคลินิกและแผนอบรม
• วางแผนรับผลกระทบช่วงแรกหลังเปิดใช้
• ทบทวนผลด้วยวงจร PDSA ก่อนตัดสินใจ
• ขยายเป็นระลอก และตรวจความพร้อมก่อนแต่ละระลอก
• ระบุมาตรฐานข้อมูล ความเป็นเจ้าของข้อมูล และ PDPA ไว้ในสัญญา

คำถามที่พบบ่อย

เริ่มทีละโมดูลจะช้ากว่าไหม

ในระยะแรกอาจช้ากว่า แต่ Wachter Review สรุปว่าทำให้ถูกดีกว่าทำให้เร็ว และกรณี NPfIT ชี้ว่าความเร่งรีบมีต้นทุนสูง

ควรนำร่องนานเท่าไร

ไม่มีตัวเลขมาตรฐาน ให้นำร่องจนตัวชี้วัดคงที่และผ่านเกณฑ์ที่ตกลงไว้ล่วงหน้า

จะหลีกเลี่ยงการนำร่องไม่รู้จบได้อย่างไร

กำหนดเส้นทางขยาย งบประมาณต่อเนื่อง และเกณฑ์ตัดสินใจไว้ตั้งแต่ก่อนเริ่ม

ใครควรเป็นเจ้าของโครงการ

ผู้บริหารร่วมกับผู้นำคลินิก ไม่ใช่ฝ่ายไอทีฝ่ายเดียว

แหล่งอ้างอิง

• NAO: The National Programme for IT in the NHS: an update on the delivery of detailed care records systems (2011)
• NAO: Review of the final benefits statement for programmes previously managed under the National Programme for IT (2013)
• GOV.UK: Making IT Work (Wachter Review, 2016)
• Han et al. Pediatrics 2005: Unexpected increased mortality after implementation of CPOE
• Del Beccaro et al. Pediatrics 2006: Computerized provider order entry implementation
• WHO: Monitoring and evaluating digital health interventions (2016)
• WHO/ExpandNet: Beginning with the end in mind (2011)
• IHI: Model for Improvement
• Greenhalgh et al. JMIR 2017: The NASSS framework
• Huang et al. Globalization and Health 2017: mHealth pilotitis in Uganda
• RE-AIM: What is RE-AIM?
• MeasuringU: System Usability Scale
• HL7: FHIR versions
• HL7: SMART App Launch
• SIL-TH: Thai FHIR Implementation Guides