HAS : Experience of HIS implementation

เป็นการบรรยายในหลักสูตรโรงเรียนการบริหารงานโรงพยาบาล ของทางรพ.รามาฯ ผมได้มีโอกาสเข้าฟัง เลยเอามาแชร์ครับ

วิทยากรวันนี้คือ นพ.ปานกิตติ์ ศิริพูล ปัจจุบันดำรงตำแหน่งเป็นกรรมการที่ปรึกษา บริษัท Greenline Synergy จำกัด เป็นบริษัทในเครือของรพ.กรุงเทพ เคยมีประสบการณ์ในการ implement ระบบ HIS ให้กับโรงพยาบาลในเครือรพ.กรุงเทพมาหลายแห่ง (น่าจะทั้งหมด)

โดยภาพรวมแล้ว การบรรยายวันนี้ดีมาก คือมีทฤษฎีอยู่บ้าง แต่สิ่งที่สอดแทรกเข้ามาในแต่ละสไลด์คือประสบการณ์เน้นๆ ของคนที่อยู่ในวงการนี้มานาน ซึ่งผมว่าเจ๋งมาก ผมยิ่งเป็นคน Sensitive ต่อประโยคแบบ “ผมจะพูดทฤษฎีไม่เยอะนะ แต่ผมจะเล่าให้ฟังว่าผมทำยังไง” โหย เท่… ฮ่าๆ

เริ่มการบรรยายด้วยประโยคเด็ด

ในอนาคต IT จะเป็นเสาหลักอีกเสาหนึ่งของทุกวงการ

ต่อมาก็พูดอีกประโยค

Sale เขาเดินเข้ามาหาอาจารย์ (อ.ท่านแทนนักศึกษาใน class ว่าอาจารย์) เขาเดินมาเหมือน Sale ขายยาเลยนะ เราเป็นหมอเรายังรู้เรื่องยา แต่เรื่อง IT เราแทบไม่รู้อะไรเลย

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

ขั้นตอนของการ Implement

  • อันนี้เป็นทฤษฎี ก็เริ่มจาก ตัดสินใจว่าจะใช้หรือเปล่า -> เลือก Software ->Sample Site Visit ->Work flow identification ->Gap Analysis ->Contract, TOR, Change request ->Test Site ->Site review ->Project Preparation ->Community & Public relation ->Preproduction Setup ->Training ->Simulation ->Data migration & Production Set-up ->Closing Project ->Acceptance ->Evaluation ->Post live Support & Maintenance
  • จะเห็นว่ามันเยอะมาก และแต่ละอันก็มีรายละเอีดยปลีกย่อยอีก เพราะงั้นผมจะลงแต่อะไรที่คิดว่าสำคัญนะครับ

การตัดสินใจว่าจะใช้หรือเปล่า ไปจนถึงการเลือก Software

  • ขั้นตอนการตัดสินใจว่าจะใช้ แค่เราจะอัพเกรดของเดิมก็ต้องคิด เช่น บางที Upgrade IE แล้วพวก web-based มีปัญหา หรือบางทีอัพเดท Service Pack แล้วมีปัญหา ในบริษัทใหญ่ๆเขาจะ Test ราย patch เลย สมมติใน Service Pack มีอัพเดท 10 ตัว ก็มานั่ง Test ทีละตัวไปเลย
  • การเลือกใช้ระบบรพ.นั้น “Like a married man” คือแต่งไปแล้วจะเลิกมันยาก ต้องคิดดีๆ
  • นำมาใช้แล้วต้องลดงานไม่ใช่เพิ่มงาน
  • เรื่องการตัดสินใจว่าจะสร้างเอง จะซื้อ หรือจะ Outsource นั้นพูดได้ blog นึงเต็มๆ เดี๋ยวว่ากันวันหลัง
  • HIS นั้นประกอบด้วยหลาย Module เวลาซื้อต้องเคลียร์กันให้ชัดเจนกับบริษัทว่าแต่ละ Module หมายถึงอะไร เช่น บอกเราว่ามี HIE แต่พอซื้อมาจริงดัน support HL7 เวอร์ชั่นเก่าแล้วอะไรแบบนี้
  • อย่าลืมดู  Module สำหรับ Report & Printing บาง Software ไม่มีให้แล้วเราต้องไปซื้อมาเพิ่มเอาเอง อ.หมดไป 30 ล้านสำหรับเรื่องนี้
  • Magic Quadrant for U.S. Enterprise CPR Systems เป็นการประเมิน HIS ในอเมริกา เอามาฝากเผื่อใครสนใจครับ
  • เวลาซื้อควรเลือกซื้อให้ตรงกับความต้องการใช้ ไม่ใช่ซื้อมา 100 บาท ใช้อยู่ 10 บาท (ความจริงคงหน่วยล้านบาท)
  • NO PERFECT HIS TO BUY แต่ละตัวเด่นคนละด้าน เลือกเอาที่เหมาะกับงานที่เราจะเน้น
  • ถ้าบริษัทให้เราไปดูตัวอย่างรพ.ที่เอาไปใช้ได้จะดีมาก แล้วถ้าให้เราเลือกรพ.เองได้ยิ่งดี
  • จะดีมากถ้าสามารถจัดให้หลายๆบริษัทมา Test program ให้ User ของเราทดสอบดูว่าอันไหนดีสุด พี่นรรนเสริมว่าวิธีการนี้ใช้ได้จริงสมัยที่ implement ระบบ PACS เข้ามาในรามาฯ ประมาณว่าหนึ่งสัปดาห์ต่อหนึ่ง Vendor ผู้ตัดสินมีทั้งกรรมการ User ที่เป็นทั้งแพทย์อื่นๆและ Radiologist มีการทำ Benchmark ประกอบการตัดสินใจ
  • Software ที่จะซื้อควรเป็น SOA
  • โปรแกรมที่ซื้อมาบางครั้ง บริษัทไม่ยอมแก้ให้ตรงกับงานของเรา กลายเป็นว่าเราต้องไปปรับ workflow ของเราให้ตรงกับโปรแกรมแทน

Workflow identification & Gap analysis

  • ตอนทำ Workflow identification ต้องทำให้ชัดเจนตั้งแต่ในระดับรพ.มาจนถึงในระดับแผนก (แต่ละ OPD มักไม่เหมือนกัน)
  • Workflow ของสถานพยาบาลในอเมริกา ไม่เหมือนกับในอินเดีย และทั้งสองที่ก็ไม่เหมือนกับในไทย จะซื้อโปรแกรมจากประเทศไหนต้องดู Workflow ของโปรแกรมด้วยว่าจะปรับได้หรือเปล่า
  • ควรมีการนำ Business Process Management (BPM) เข้ามาพัฒนา Workflow
  • ควรทำ Gap analysis คือการดูว่าความต้องการของเรากับสิ่งที่ Software ให้ได้นั้นต่างกันขนาดไหน ขั้นตอนนี้ทุกแผนกที่ต้องใช้ Software ควรมีส่วนร่วม ที่สำคัญคือควรทำก่อนเซ็นต์สัญญา คุยเรื่องเวลาและค่าใช้จ่ายที่ต้องใช้ในการแก้ไข
  • ต้องคำนึงถึง Interoperability มีอยู่รพ.นึงไปซื้อระบบ Pharmacy robot มา (การใช้หุ่นยนต์ช่วยจ่ายยา) ปรากฏว่าเข้ากับระบบเดิมที่มีอยู่ไม่ได้ ได้ตั้งอยู่เฉยๆเป็นปี

Contract

  • ขั้นตอนการเซ็นสัญญาเป็นขั้นตอนที่สำคัญมากๆ เพราะส่วนใหญ่เวลามีคดีความกันบริษัทในไทยมักจะแพ้ เนื่องจากในสัญญามีช่องให้โดนเล่น
  • เริ่มจาก Definition ของแต่ละส่วนต้องชัดเจน มีรพ.นึงมีปัญหาการเปลี่ยนการคิดราคา คิอคิดตามจำนวน user ต่อมาบริษัทแอบเปลี่ยนนิยามของ user เป็นนับตามจำนวน Process กลายเป็นรพ.นั้นต้องซื้อ user เพิ่ม ปัญหานี้เกิดจากการไม่ definition ให้ชัดเจนตั้งแต่แรกว่า user คืออะไร
  • ต้องดูวิธีการคิดราคา Software ให้ดี บางบริษัทคิดตามรายได้ของรพ. (ยิ่งรพ.มีรายได้มากยิ่งจ่ายค่า Software มาก)
  • ควรทำสัญญาเรื่องราคาให้ดี เช่น ระบุว่า Software ต้องราคานี้ไปอีก 5 ปี, ราคาขึ้นได้ไม่เกินปีละกี่เปอร์เซ็นต์ อะไรแบบนี้
  • กำหนดให้ชัดเจนว่าปัญหาต่างๆใครจะเป็นคนรับผิดชอบ รพ.หรือว่าบริษัท ใครจะเป็นคนทำคู่มือการใช้งาน
  • ค่าใช้จ่ายอื่นๆ เช่น ค่าที่พัก คาอาหาร เช่น บริษัทส่งคนมาซ่อมระบบ ใครเป็นคนจ่ายค่าที่พัก
  • ดูสัญญาเรื่อง Maintenance ดีๆ บางบริษัทคิดราคา Software ถูก แต่คิดค่า Maintenance แพงมาก
  • ดูว่าเป็น Technical upgrade หรือ System upgrade อันแรกคือแค่มาแนะนำวิธีเฉยๆอันหลังคือมาทำให้เลย
  • ดูเรื่องสัญญาด้านกฎหมายว่าจะให้ใช้กฎหมายประเทศอะไร บางบริษัทชอบให้ใช้ US Law
  • ถ้าซื้อมาแล้วไม่มี function ตามสัญญาจะทำยังไง
  • พี่นรรนเสริมว่าระวังสัญญาพวกห้ามเปิดเผยข้อมูลบริษัทในแง่ลบ แค่เอา bug ไปปรึกษาเพื่อนที่ใช้โปรแกรมเดียวกันอยู่ก็ผิดแล้ว
  • ดูเรื่องการยกเลิกสัญยา และค่าปรับ

Project Management – Production Set-Up -Post live support

  • เรื่อง Project Management ควรมีทีมของทางรพ.เองเข้าไปร่วม implement ด้วย
  • ก่อน go Live ควรมีการดึง Superuser เข้ามาร่วมในการพัฒนาหรือทดสอบก่อน เพื่อให้เขารู้สึกว่าตัวเองเป็นเจ้าของ Software นี้ และไปผลักดันหรือสอนให้ user อื่นๆใช้ด้วย
  • ต้องเข้าถึง Culture ของแต่ละรพ. แพทย์และทันตแพทย์คือกลุ่มที่ยุ่งด้วยยากที่สุด เรียกมาสอนวิธีใช้ก็ไม่ค่อยมา และมักเป็นกลุ่มที่มีปัญหากับ Software ใหม่ๆ โดยเฉพาะอาจารย์อาวุโส อันนี้เป็นสิ่งที่ผู้บริหารต้องผลักดัน และทางผู้ implement ต้องมีวิธี approach ที่ต่างออกไป บางรายใช้วิธีจัดเป็นงานเลี้ยงแล้วสอนไปด้วย อะไรแบบนั้น
  • เวลาสอน User ใช้งานต้องไม่ห่างจากวัน Go Live มากเกินไป ถ้าจำนวนคนเยอะต้องเพิ่มคนสอน ถ้าห่างนานจะลืม อาจให้มีการสอบ ใครสอบตกตัดคะแนนปลายปี
  • ควรมีการ Simulation ก่อน run จริง พยายาม test ให้มาก function ที่สุด ถ้า Simulation แล้วมันไม่ดีก็ไม่ต้องใช้ แม้เราจะจ่ายเงินไปแล้วบางส่วน ถ้าจะให้ดีตอนสัญญาควรจะให้ลอง simulation ก่อนจ่ายจริง
  • ช่วง Live period มักกินเวลา 1-4 สัปดาห์แล้วแต่รพ. ช่วงนี้ควรมีทีมคอย Support 24 hr. มีแผนสำรองฉุกเฉินถ้าระบบมันไปไม่ได้ และทีมที่ทำต้องประชุมกันทุกเย็น
  • หลังทำสำเร็จก่อนจัดงานเลี้ยงกัน อาจให้พนักงาน IT หยุดพักได้
  • การเซ็นรับงาน ควรระบุตั้งแต่ในสัญญาว่าให้เซ็นหลัง Live
  • หลังจากใช้ไปจึงมา Evaluation, Post-Live support & Maintenance ต่อ ระวังพวก upgrade แล้ว function เก่าหาย

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

จบครับ

เสริมเล็กน้อย

เล่าให้ฟังเพิ่มว่าเครือรพ.กรุงเทพเนี่ย ขึ้นกับ บริษัท กรุงเทพดุสิตเวชการ จำกัด หรือ Bangkok Dusit Medical Software (BDMS) แล้วบริษัทที่ว่านี้ก็จะมีรพ.ในเครืออีกเยอะ คือ รพ.กรุงเทพ (ทั้งหลาย) 14 แห่ง รพ.สมิติเวช 3 แห่ง รพ. Royal Bangkok 1 แห่ง (อันนี้ตั้งอยู่ตามต่างประเทศ) ปัจจุบันก็ไปรวมกับรพ.พญาไทอีก 4 และเปาโลอีก 4 มีบริษัทยาในเครืออีก 2 บริษัท เนื่องจากเครือข่ายใหญ่ เพราะงั้นจะมีบริษัทที่ทำหน้าที่เฉพาะอย่าง เช่น NHS ทำเกี่ยวกับบัญชี และ Greenline Synergy คือการเอาคน IT ทั้งหมดของเครือมารวมกันในบริษัทเดียว เพื่อดูเรื่อง IT ของรพ.ในเครือ

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s