Kiosk สำหรับลงทะเบียนผู้ป่วยและรับบัตรคิว: ออกแบบ Workflow ให้ยืนยันตัวตน เชื่อมระบบ และรับมือกรณียกเว้นได้จริง
เมื่อจุดลงทะเบียนหน้าโรงพยาบาลมีผู้ใช้หนาแน่น การเพิ่ม Kiosk ไม่ควรถูกมองว่าเป็นเพียงการย้ายแบบฟอร์มจากเคาน์เตอร์มาไว้บนจอสัมผัส เพราะจุดนี้เชื่อมระหว่างการค้นหาประวัติผู้รับบริการ การตรวจสอบนัดหมาย การยืนยันข้อมูล การออกคิว และการส่งต่อให้เจ้าหน้าที่ หากออกแบบลำดับผิด อาจเกิดระเบียนซ้ำ คิวไม่ตรง หรือผู้ใช้ต้องกลับไปเริ่มต้นที่เคาน์เตอร์อยู่ดี
Kiosk สำหรับลงทะเบียนผู้ป่วยและรับบัตรคิวที่ใช้งานได้จริงจึงเริ่มจากการกำหนดว่า “รายการใดให้ผู้ใช้ทำเองได้” และ “กรณีใดต้องส่งต่อเจ้าหน้าที่” แล้วจึงออกแบบการเชื่อม HIS, ระบบนัดหมาย และระบบคิวให้มีสถานะที่ตรวจสอบย้อนหลังได้ บทความนี้เป็นกรอบวาง Workflow และทดสอบโครงการ ไม่ใช่คำแนะนำทางการแพทย์หรือข้อกำหนดเฉพาะของสถานพยาบาลใด
ประเด็นสำคัญที่ควรรู้
- Kiosk ควรค้นหาประวัติและยืนยันข้อมูลเท่าที่จำเป็นก่อนออกคิว ไม่ควรสร้างระเบียนใหม่โดยอัตโนมัติเมื่อค้นหาไม่พบ
- สถานะนัดหมาย การยืนยันตัวตน และการออกหมายเลขคิวควรมีรหัสอ้างอิงเดียวกัน เพื่อให้ตรวจสอบเหตุการณ์ซ้ำหรือการพิมพ์บัตรซ้ำได้
- ทางออกสำหรับบัตรอ่านไม่ได้ ข้อมูลไม่ตรง สิทธิ์ไม่ชัดเจน ระบบหลังบ้านล่าช้า และผู้ใช้ต้องการความช่วยเหลือ ต้องออกแบบก่อน Pilot
- Hardware เช่น Scanner, เครื่องพิมพ์บัตรคิว, UPS และเครือข่ายมีผลต่อ Workflow แต่ต้องทดสอบร่วมกับ API และกติกาของระบบ ไม่ใช่เลือกจากสเปกอย่างเดียว
Kiosk ลงทะเบียนผู้ป่วยและรับบัตรคิวคืออะไร
Kiosk ประเภทนี้คือจุดบริการตนเองสำหรับเริ่มหรือยืนยันการมารับบริการ เช่น ค้นหานัดหมาย ระบุตัวตนตามวิธีที่สถานพยาบาลอนุมัติ ยืนยันข้อมูลติดต่อ เลือกจุดบริการ และรับหมายเลขคิวหรือเอกสารที่จำเป็น ต่างจากบทความ Kiosk สำหรับโรงพยาบาล ซึ่งอธิบายภาพรวมอุปกรณ์และประสบการณ์ใช้งาน บทความนี้มุ่งที่ลำดับข้อมูลระหว่าง Kiosk กับระบบหลังบ้านและจุดที่ต้องตัดสินใจส่งต่อคน
แนวทางของ WHO สำหรับ workflow การลงทะเบียนชี้ให้เห็นลำดับสำคัญคือค้นหาและเลือกประวัติเดิม ตรวจสอบข้อมูลที่จำเป็น แล้วจึงสร้างหรือปรับปรุงข้อมูลตามสิทธิ์ การออกแบบ Kiosk จึงไม่ควรตั้งสมมติฐานว่าผู้มารับบริการทุกคนมีบัตรหรือมีนัดที่ค้นพบได้ทันที ระบบทะเบียนผู้รับบริการและการระบุตัวตน เป็นส่วนที่ช่วยลดความเสี่ยงของการผูกข้อมูลผิดคน แต่รายละเอียดการพิสูจน์ตัวตนต้องยึดนโยบายและระบบของแต่ละองค์กร
ภาพรวม Workflow ตั้งแต่เข้าจุดบริการจนได้คิว
ตัวอย่างด้านล่างเป็นลำดับที่ใช้ตั้งโจทย์กับทีม Registration, IT, ทีมคิว และผู้ดูแลระบบ ไม่ใช่ Flow ที่นำไปใช้ได้ทันทีโดยไม่ปรับ Requirement
- ผู้ใช้เลือกภาษาและประเภทการทำรายการ เช่น มีนัดหรือ walk-in
- Kiosk แสดงข้อความสั้นเรื่องการใช้ข้อมูล และบอกจุดขอความช่วยเหลืออย่างชัดเจน
- ผู้ใช้ระบุตัวตนด้วยวิธีที่ระบบอนุมัติ เช่น รหัสนัด บัตร/Barcode หรือข้อมูลที่ไม่แสดงเต็มหน้าจอ
- ระบบค้นหาประวัติและนัดหมาย โดยตอบกลับเฉพาะข้อมูลขั้นต่ำที่จำเป็นต่อการยืนยัน
- ผู้ใช้ตรวจสอบข้อมูลที่แก้ไขได้ และระบบบันทึกว่าข้อมูลใดถูกยืนยันหรือถูกส่งให้เจ้าหน้าที่ตรวจ
- ระบบตรวจเงื่อนไขการรับบริการและสร้างคำขอคิวแบบมี idempotency key หรือรหัสอ้างอิงที่ป้องกันการกดซ้ำ
- ระบบคิวตอบกลับหมายเลข จุดบริการ และสถานะการพิมพ์ จากนั้น Kiosk จึงแสดงผลและพิมพ์บัตรตามที่อนุญาต
- Kiosk ล้าง Session, ข้อมูลชั่วคราว และหน้าจอเมื่อจบรายการหรือหมดเวลา
หากองค์กรใช้มาตรฐานแลกเปลี่ยนข้อมูล HL7 FHIR สามารถประเมินการแมประหว่างระบบนัดหมายกับทรัพยากร Appointment ได้ แต่การรองรับจริงขึ้นกับ HIS, API, เวอร์ชันมาตรฐาน และข้อตกลงการเชื่อมต่อ ไม่ควรอ้างว่า Kiosk ใดเชื่อมได้ทันทีโดยไม่ทดสอบ
จุดควบคุมข้อมูลที่ต้องกำหนดก่อนเขียนหน้าจอ
1. ค้นหาประวัติเดิมก่อนสร้างรายการใหม่
การค้นหาด้วยตัวระบุที่องค์กรกำหนดช่วยลดโอกาสเกิดระเบียนซ้ำ แต่ผลค้นหาหลายรายการหรือไม่พบผลลัพธ์ไม่ควรพาไปสร้างข้อมูลใหม่อัตโนมัติ Kiosk ควรแจ้งเส้นทางไปยังเจ้าหน้าที่ พร้อมส่งรหัสเหตุการณ์ให้เจ้าหน้าที่เห็นว่าเกิดอะไรขึ้น ผู้ดูแลระบบควรกำหนดว่าใครมีสิทธิ์แก้ชื่อ วันเกิด เบอร์ติดต่อ หรือความสัมพันธ์กับสิทธิ์การรักษา
2. แสดงข้อมูลน้อยที่สุด
หน้าจอสาธารณะควรแสดงข้อมูลเท่าที่จำเป็นต่อการเลือกหรือยืนยัน ไม่ควรเปิดเผยรายการนัด ประวัติ หรือข้อมูลติดต่อเกินความจำเป็น ควรกำหนด timeout, การล้าง form และ cache หลังจบงาน รวมทั้งออกแบบตำแหน่งตู้เพื่อไม่ให้ผู้รอด้านหลังมองเห็นรายละเอียดได้ง่าย หลักการนี้ยังช่วยให้ทีมทดสอบมีเกณฑ์เดียวกันว่าอะไรไม่ควรเก็บไว้ใน log ของอุปกรณ์
3. แยก “ยืนยันข้อมูล” ออกจาก “อนุมัติข้อยกเว้น”
ผู้ใช้ยืนยันเบอร์ติดต่อได้อาจเป็นคนละเรื่องกับการเปลี่ยนข้อมูลสำคัญหรือการยืนยันสิทธิ์ งานที่ต้องใช้เอกสารเพิ่มเติม การจับคู่ชื่อไม่ตรง หรือสิทธิ์มีข้อสงสัยควรย้ายไปยังโต๊ะเจ้าหน้าที่เป็น workflow ที่ติดตามได้ ไม่ควรแก้ปัญหาด้วยข้อความ error ที่ผู้ใช้ไม่เข้าใจ
การเชื่อม HIS, ระบบนัดหมาย และระบบคิว
การเชื่อมที่ดีต้องระบุเจ้าของข้อมูลและผลลัพธ์ที่คาดหวังในแต่ละจุด ตัวอย่างเช่น HIS เป็นแหล่งอ้างอิงข้อมูลผู้รับบริการ ระบบนัดหมายตอบสถานะ slot และระบบคิวตอบเลขคิวกับจุดบริการ Kiosk ไม่ควรเป็นเจ้าของข้อมูลทางคลินิกหรือสร้างกติกาที่ซ้ำกับระบบหลัก
| เหตุการณ์ | ระบบที่เกี่ยวข้อง | สิ่งที่ควรบันทึก | กรณีผิดปกติ |
|---|---|---|---|
| ค้นหาผู้รับบริการ | HIS / client registry | รหัสคำขอ, ผลลัพธ์, เวลา | พบหลายรายการหรือไม่พบ ให้ส่งต่อ |
| ตรวจนัด | appointment service | รหัสนัด, สถานะ, จุดบริการ | นัดถูกยกเลิกหรือไม่ตรงวัน |
| ยืนยันข้อมูล | HIS / registration | ฟิลด์ที่ยืนยัน, ผู้ดำเนินการ | ฟิลด์ต้องมีเจ้าหน้าที่อนุมัติ |
| ออกคิว | queue service | request ID, queue ID, เวลา | ป้องกันสร้างคิวซ้ำเมื่อกดซ้ำ |
| พิมพ์บัตร | printer service | print job ID, ผลการพิมพ์ | กระดาษหมด/พิมพ์ไม่สำเร็จ |
ควรกำหนด contract สำหรับ timeout และ retry ตั้งแต่ต้น หากคำขอออกคิวหมดเวลา Kiosk ต้องถามระบบว่ามี queue ID ถูกสร้างแล้วหรือไม่ก่อนส่งคำขอใหม่ มิฉะนั้นผู้ใช้คนเดียวอาจได้หลายคิว การออกแบบลักษณะเดียวกันนี้พบได้ในงาน เชื่อม Handheld กับระบบ WMS ซึ่งต้องจัดการสถานะธุรกรรมระหว่างอุปกรณ์และระบบหลัก แม้บริบททางธุรกิจต่างกัน
Hardware ที่ต้องทดสอบกับรายการจริง
Kiosk ไม่จำเป็นต้องมีอุปกรณ์ทุกชนิด แต่ทุกชิ้นที่ใส่เข้ามาควรมี Use Case และแผนเมื่อใช้งานไม่ได้
| องค์ประกอบ | ใช้เมื่อ | ข้อทดสอบก่อนใช้งานจริง |
|---|---|---|
| Touch display | เลือกบริการและยืนยันข้อมูล | ขนาดตัวอักษร ภาษา ระยะเวลา timeout และ accessibility |
| Barcode / QR scanner | อ่านรหัสนัดหรือบัตรที่อนุมัติ | ตัวอย่างบัตรจริง แสงสะท้อน มุมสแกน และข้อมูลที่ส่งเข้า API |
| เครื่องพิมพ์บัตรคิว | พิมพ์เลขคิวหรือคำแนะนำ | กระดาษหมด, cutter, reprint, ลำดับงานพิมพ์ และข้อความไม่เผยข้อมูลเกินจำเป็น |
| Network และ UPS | เชื่อมบริการหลังบ้าน | การตัดสลับเครือข่าย, recovery หลังไฟดับ และสถานะบนหน้าจอ |
| Enclosure / remote management | ใช้งานต่อเนื่อง | สิทธิ์ผู้ดูแล, lock down, การแจ้งเตือน และการบำรุงรักษา |
สำหรับการเลือกโครงสร้างตู้และ peripheral อ่านต่อได้ที่ วิธีเลือกตู้ Kiosk และ อุปกรณ์ภายในตู้ Kiosk ส่วนแนวทางออกแบบ flow ที่ไม่บังคับผู้ใช้เกินจำเป็นอยู่ใน UX สำหรับหน้าจอ Kiosk
Exception flow ที่ห้ามปล่อยให้เป็นข้อความ Error
Kiosk ที่ลดคิวได้ต้องมีทางออกที่สุภาพและรวดเร็วเมื่อ self-service ไปต่อไม่ได้ สถานการณ์สำคัญ ได้แก่
- อ่านบัตรหรือรหัสนัดไม่ได้: แสดงคำแนะนำที่ไม่เผยข้อมูล และพาไปยังจุดช่วยเหลือพร้อมเลขอ้างอิง
- พบผู้รับบริการชื่อคล้ายกันหลายคน: หยุดขั้นตอนอัตโนมัติและให้เจ้าหน้าที่ตรวจสอบ
- ข้อมูลติดต่อเปลี่ยน: แยกว่าฟิลด์ใดแก้เองได้และฟิลด์ใดต้องตรวจเอกสาร
- ไม่มีนัดหรือมาถึงผิดวัน: อธิบายทางเลือกตามนโยบาย ไม่ควรสร้างคิวโดยเดา
- Queue API หรือ printer ขัดข้อง: ตรวจสอบสถานะการสร้างคิวก่อน retry และให้เจ้าหน้าที่พิมพ์ซ้ำจากรหัสเดียวกันได้
- ผู้ใช้ต้องการความช่วยเหลือด้านภาษา การมองเห็น หรือการเคลื่อนไหว: มีช่องทางช่วยเหลือที่มองเห็นได้ ไม่ใช่ซ่อนอยู่ใน FAQ
การยืนยันตัวตนเป็นจุดที่ต้องระวังเป็นพิเศษ แนวทาง patient identification ของ ONC ยกตัวอย่างความเสี่ยงของการสร้าง ค้นหา และจับคู่ระเบียนผิด การใช้ Barcode ช่วยใน workflow ได้เมื่อออกแบบกับระบบและนโยบายอย่างถูกต้อง แต่ไม่ควรถือว่าการสแกนเพียงครั้งเดียวแทนการยืนยันตามขั้นตอนของสถานพยาบาล
Checklist สำหรับ Pilot
ก่อนขยายจากจุดทดลอง ควรทำ pilot กับข้อมูลทดสอบและสถานการณ์จริงที่ควบคุมได้
- ระบุเจ้าของ workflow ของ Registration, HIS, Queue, IT, Security และหน้างาน
- เขียน journey ของผู้มีนัด ผู้ไม่มีนัด ผู้ใช้ใหม่ และกรณีข้อมูลไม่ตรง
- กำหนดข้อมูลขั้นต่ำที่ Kiosk ขอ แสดง ส่ง และเก็บใน log
- ทดสอบคำขอซ้ำ, network timeout, printer error, restart และ session timeout
- ตรวจว่าหน้าที่เจ้าหน้าที่เริ่มเมื่อใด และได้รับข้อมูลอะไรเพื่อทำงานต่อ
- วัดอัตราทำรายการสำเร็จ เวลาต่อรายการ จำนวน exception และเหตุผลที่เรียกเจ้าหน้าที่
- ทบทวน accessibility, ความเป็นส่วนตัว, ตำแหน่งติดตั้ง และข้อกำหนดภายในขององค์กร
บทความ Kiosk ลงทะเบียนและรับบัตรคิว ช่วยเทียบภาพการใช้งานทั่วไป ขณะที่ Barcode สำหรับโรงพยาบาล และ การระบุตัวผู้ป่วยด้วย Barcode ช่วยวางขอบเขตของข้อมูลและจุดสแกนในงานบริการสุขภาพ
คำถามที่พบบ่อย
Kiosk สร้างข้อมูลผู้ป่วยใหม่ได้หรือไม่
ทำได้หรือไม่ขึ้นกับนโยบายและการออกแบบ HIS ของสถานพยาบาล แต่ควรระวังการสร้างระเบียนซ้ำเป็นพิเศษ ระบบที่ปลอดภัยมักค้นหาและให้เจ้าหน้าที่จัดการกรณีที่ไม่สามารถจับคู่ได้อย่างมั่นใจ ก่อนเปิดให้ Kiosk สร้างข้อมูล ควรกำหนดตัวระบุ ขั้นตอนอนุมัติ และ audit trail ให้ชัดเจน
ถ้า Kiosk ออกคิวแล้วเครื่องพิมพ์ขัดข้องต้องทำอย่างไร
ระบบควรแยกสถานะ “สร้างคิวสำเร็จ” ออกจาก “พิมพ์สำเร็จ” และเก็บ queue ID หรือรหัสอ้างอิงที่เจ้าหน้าที่ใช้ตรวจสอบและสั่งพิมพ์ซ้ำได้ ห้ามส่งคำขอสร้างคิวใหม่ทันทีเพียงเพราะกระดาษไม่ออก เพราะอาจได้หมายเลขซ้ำ
จำเป็นต้องใช้ Barcode Scanner หรือไม่
ไม่จำเป็นสำหรับทุกโครงการ วิธีระบุตัวตนต้องเริ่มจากสิ่งที่องค์กรอนุมัติและข้อมูลที่ระบบรองรับ Scanner มีประโยชน์เมื่อมีรหัสนัดหรือบัตรที่ต้องอ่านจริง แต่ต้องทดสอบคุณภาพสื่อ มุมสแกน และวิธีรับมือเมื่ออ่านไม่ได้
Kiosk เชื่อมกับ HIS เดิมได้ทันทีหรือไม่
ไม่ควรรับประกันเช่นนั้น การเชื่อมขึ้นกับ API, SDK, สิทธิ์, รูปแบบข้อมูล, network, เวอร์ชันของระบบ และนโยบายความปลอดภัย ควรเริ่มจาก workshop ระบุ use case และ proof of concept ที่ทดสอบกับ sandbox หรือข้อมูลที่ได้รับอนุญาต
จะวัดว่า Kiosk ลดภาระเคาน์เตอร์ได้อย่างไร
ดูสัดส่วนรายการที่ทำเสร็จเอง เวลาต่อรายการ จำนวน exception และเหตุผลที่ต้องเรียกเจ้าหน้าที่ ควรดูคุณภาพการจับคู่ข้อมูลและความพึงพอใจของเจ้าหน้าที่ร่วมด้วย ไม่ควรวัดเฉพาะจำนวนผู้ใช้ที่เริ่มหน้าจอ
สรุปและแนวทางเริ่มต้น
Kiosk สำหรับลงทะเบียนผู้ป่วยและรับบัตรคิวให้ผลลัพธ์ที่ดีเมื่อถูกออกแบบเป็น workflow ร่วมกันของผู้รับบริการ เจ้าหน้าที่ ระบบนัด HIS ระบบคิว และอุปกรณ์ ไม่ใช่เป็นโครงการจอสัมผัสเพียงอย่างเดียว เริ่มจากเลือก use case ที่ชัด ระบุข้อมูลขั้นต่ำ กำหนด exception flow และทดสอบธุรกรรมซ้ำหรือขัดข้องก่อนขยายผล
หากองค์กรกำลังวางแผน Kiosk ลงทะเบียนหรือรับบัตรคิว Arc Tech สามารถช่วยวิเคราะห์ Requirement ออกแบบ Workflow ประเมินการเชื่อมต่อกับระบบเดิม และทดสอบแนวทางอุปกรณ์ที่เหมาะกับหน้างานได้ โดยผลการเชื่อมต่อจริงขึ้นอยู่กับ API, SDK, Hardware, นโยบายของ Platform และข้อจำกัดของระบบเดิม
