สถานการณ์ Big Data in Healthcare ตอนที่ 2: Case Study รพ.รัฐ ที่ต้องกา
top of page

สถานการณ์ Big Data in Healthcare ตอนที่ 2: Case Study รพ.รัฐ ที่ต้องการลดเวลาในการรอพบแพทย์


Big Data in Healthcare Part 2

จากตอนที่1และตอนที่ 2 เรื่องการบริหารจัดการของโรงพยาบาลรัฐ เป็นเรื่องที่ค่อนข้างอ่อนไหว หรือ Sensitive ด้วยเวลาที่รีบเร่ง และปัญหาที่เกิดขึ้นนั้นเกี่ยวข้องกับชีวิตความเป็นความตายกันเลยทีเดียว

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

ตามเวลาทำงานของบุคลากรในโรงพยาบาล แพทย์จะเริ่มออกตรวจเวลา 9.00 น. แต่เราก็จะเคยชินกับการต้องไปเข้าคิวตั้งแต่ตี 5 หรือก่อน 6 โมงเช้า ทั้งๆ ที่ ไปก่อน อย่างไรก็เริ่มตรวจ 9.00 น. อยู่ดี แต่ที่ต้องไปก่อน ก็เพราะการไปโรงพยาบาลแต่ละครั้ง มันช่างยาวนานเหลือเกิน และก็พบว่าบางครั้ง คิวยาวจนไม่สามารถได้พบแพทย์ภายในวันนั้นอีกด้วย (ไปวันนี้ไม่ทันได้ตรวจ จะได้รับบัตรนัดเพื่อมาตรวจในวันถัดมา)

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

ทฤษฎีการจัดการคิว คือ Queuing Theory เป็นศาสตร์ด้าน Optimization อย่างหนึ่ง ที่ใช้กันในโรงงานอุตสาหกรรม โดยมีหลักการ คือ ทำให้การรอคิวน้อยที่สุด และใช้เครื่องจักรได้อย่างมีคุณภาพสูงที่สุด

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

ข้อสังเกตที่ 1: โรงพยาบาลนี้เริ่มจากการ “จดบันทึกข้อมูล” ก่อนที่จะจัดซื้อระบบ

การศึกษาโดยใช้ข้อมูลทางสถิติ พบว่าความล่าช้าในการดำเนินการมาจากการรอแฟ้ม รวมไปถึงการจัดการแฟ้ม ดังนั้นขอย้อนกลับไปดูการจัดการข้อมูลแฟ้มในโรงพยาบาลก่อนหน้านี้กันสักนิด

ส่วนใหญ่ระบบของโรงพยาบาลจะมีลักษณะโดยย่อดังนี้

  1. ผู้ป่วยเข้ามาลงทะเบียน จะได้รับ HN เพื่อเป็นหมายเลขประจำตัวของผู้ป่วย ณ โรงพยาบาลนั้นๆ หมายความว่า ผู้ป่วยคนเดียวกัน ไปต่างโรงพยาบาลก็จะมี HN ไม่เหมือนกัน และหากเจ้าหน้าที่หาแฟ้มไม่เจอ หรือ ผู้ป่วยจำ HN เก่าของตัวเองไม่ได้ ก็มีความเป็นไปได้ว่า ผู้ป่วยคนเดียวกันไปโรงพยาบาลเดียวกัน จะมี HN หลายอัน แค่ตรงนี้ก็อาจจะใช้เวลานานแล้ว เพราะพนักงานห้องทะเบียนต้องเดินไปเดินมาเพื่อหาแฟ้ม

  2. ห้องทะเบียนจะนำแฟ้มส่งไปยังห้องตรวจ ผู้ป่วยรับคิว รอหน้าห้องตรวจ เมื่อตรวจเสร็จแล้ว แฟ้มจะถูกส่งต่อไปยังหน่วยอื่นๆ เช่น X-ray เป็นต้น

  3. แพทย์สั่งยาในกระดาษ ส่งให้คนไข้นำไปส่งให้ที่ห้องการเงิน

  4. มีการตรวจสิทธิการรักษาพยาบาล เช่น บัตรทอง ประกันสังคม ประกัน หรือจ่ายเอง ชำระเงิน และไปรอรับยา

  5. รับยาแล้วกลับบ้านได้

ความเป็นจริง กว่าแฟ้มจะสามารถส่งต่อไปยังหน่วยอื่นๆ ได้ ต้องรอให้มีปริมาณจำนวนหนึ่ง เพราะคนส่ง คือ “มนุษย์” ถ้าจะให้พนักงานเดินแฟ้มทุกแฟ้มตลอดเวลาก็คงจะใจร้ายเกินไป

บางครั้ง คนไข้ถึงหน้าห้องแล้ว แฟ้มยังไม่มา หรือแม้แต่การสั่งยา ที่ต้องรอให้คนไข้เอาใบสั่งยาไปส่งให้ ถึงจะได้มีกระบวนการจัดยา

นี่แค่เรื่องแฟ้ม ยังไม่รวมถึงเรื่องการต้องค่อยๆ อ่านลายมือของแพทย์ผู้ตรวจคนก่อนหน้านี้ ที่เขียนลงไปในกระดาษ แพทย์ 10 คน ลายมือก็ 10 แบบ และมีวิธีการเขียนประวัติผู้ป่วยที่ต่างกัน (ที่เรียกว่า Unstructured Data)

ขั้นตอนต่างๆ ทำให้คนไข้ต้อง “รอ”

เมื่อมีหลักฐานชัดเจนแล้วว่า “แฟ้ม” คือ ปัญหา มาตรการการใช้ระบบ Hospital Information System (HIS) จึงเป็นเรื่องสำคัญและกลายเป็นวาระแห่งโรงพยาบาลทันที

โรงพยาบาลจะต้องไม่ใช้แฟ้ม!!!

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

“มันใช้ยาก”

“มันช้า”

“มันวุ่นวาย”

“มันทำให้หงุดหงิด”

และอีกมากมาย

ส่งผลให้เกิดการต่อต้าน โดยอ้างว่า การใช้ระบบเก็บข้อมูล ทำให้เกิดความล่าช้าในการดูแลผู้ป่วย

 

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

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

จนกระทั่ง เมื่อระบบคอมพิวเตอร์ ได้เข้ามาแทนที่กระดาษอย่างสมบูรณ์ จึงต่อยอดไปเรื่องของคิวคนไข้

ขั้นตอนการพบแพทย์ของโรงพยาบาลเปลี่ยนไปเป็น

  1. คนไข้มายืนยันตนที่ฝ่ายทะเบียน ตรวจสอบสิทธิการรักษาให้เรียบร้อย (ใช้เวลาไม่เกิน 5 นาที) พนักงานจะสั่งพิม Bar code ให้ผู้ป่วย เพื่อใช้เป็นคิวในหน่วยต่างๆ

  2. เมื่อคนไข้ที่หน้าห้องตรวจ ให้ใช้ Bar code เป็นตัวรับคิว ใครถึงหน้าห้องก่อน ก็ได้รับการตรวจก่อน ส่วนข้อมูลคนไข้ จะอยู่ในระบบรอการเปิดอ่านทันที

  3. หากมีการส่งตรวจที่หน่วยอื่นๆ เช่น X-ray ให้คนไข้นำ Bar code ไปแสกนที่หน้าห้องตรวจ เพื่อรับคิว

  4. ไปที่ห้องจ่ายยาก็สแกน Bar code เพื่อรับคิว ณ เวลานั้น ห้องยาก็จะมีข้อมูลคนไข้เรียบร้อย สามารถทำการจัดยาได้ทันที

  5. เมื่อคนไข้ไปสแกน Bar code ที่ห้องยา ก็รอเรียกรับยาได้ทันที ไม่จำเป็นยื่นใบสั่งยาให้จัดยา

การสแกน Bar code ทำให้มีข้อมูลอย่างชัดเจนว่า แต่ละช่วงเวลามีคนไข้รอคิวในแต่ละหน่วยงานเท่าไหร่ และคนไข้แต่ละคนกำลังรอคิวที่หน่วยไหน ทำให้สามารถบริหารงานได้อย่างทันท่วงที

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

ความพิเศษของ Case นี้ คือ โรงพยาบาลนี้ มีหน่วยงาน IT ที่เข้มแข็งมาก อะไรทำเองได้ ทำก่อน ไม่ใช้งบประมาณอย่างฟุ่มเฟือยโดยใช่เหตุ โปรแกรมส่วนใหญ่เขียนเอง หรือใช้ Open Source

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

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

ขอชื่นชม Hero ของผู้ป่วยทุกท่าน ขอขอบคุณโรงพยาบาลรัฐแห่งนี้ ที่ให้เราได้เข้าไปดูงาน และนำเรื่องราวดีๆ มาเผยแผ่เป็น Case ตัวอย่างให้ที่อื่นต่อไป

คลิก : อ่านตอนที่ 3 ความยากในการเปลี่ยนแปลงและการวางแนวทางในการปฏิบัติ

 

< Previous
Next >
bottom of page