ข้ามไปที่เนื้อหา

2.1 Patient LINE OA Interface

2. Front Office (LINE OA Interface)

2.1 Patient LINE OA Interface

อ้างอิง TOR:

  • 3.3.1-3.3.5 ระบบบริหารจัดการลงทะเบียนผู้ป่วย
  • 3.5.1-3.5.4 ระบบการแจ้งเตือนและติดตามการแจ้งเตือน

วัตถุประสงค์:

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

2.1.1 Registration Flow

2.1.1.1 Rich Menu สำหรับลงทะเบียน

TOR Reference: 3.3.1

คำอธิบาย: Rich Menu คือเมนูที่แสดงอยู่ด้านล่างสุดของหน้าจอแชท LINE OA ซึ่งใช้เป็นช่องทางหลักสำหรับผู้ป่วยในการเข้าถึงฟีเจอร์ต่างๆ ของระบบ โดยเฉพาะการเริ่มต้นลงทะเบียนผู้ใช้งานใหม่ Rich Menu จะแสดงไอคอนและข้อความที่เข้าใจง่าย เพื่อให้ผู้ป่วยสามารถเข้าถึงฟังก์ชันต่างๆ ได้อย่างสะดวก

การทำงาน:

  1. เมื่อผู้ป่วย Add Friend LINE OA ของโรงพยาบาล ระบบจะแสดง Rich Menu พร้อมข้อความต้อนรับ

  2. Rich Menu แบ่งเป็นหลายส่วน ได้แก่:

  3. "ลงทะเบียน" - สำหรับผู้ใช้งานใหม่

  4. "ดูนัดหมาย" - สำหรับดูนัดหมายของตัวเอง
  5. "ประวัติ" - สำหรับดูประวัติการนัดหมายที่ผ่านมา
  6. "ตั้งค่า" - สำหรับจัดการการแจ้งเตือน

  7. "ติดต่อเจ้าหน้าที่" - สำหรับสอบถามข้อมูล

  8. เมื่อผู้ป่วยแตะที่ปุ่ม "ลงทะเบียน" ระบบจะเปิด Flex Message แบบฟอร์มลงทะเบียน

  9. Rich Menu สามารถเปลี่ยนแปลงตามสถานะของผู้ใช้ เช่น ผู้ที่ลงทะเบียนแล้วจะซ่อนปุ่ม "ลงทะเบียน"

UI/UX Requirements:

  • Rich Menu Layout: แบ่งเป็น 4-6 ส่วน มีไอคอนและข้อความที่ชัดเจน
  • สีสัน: ใช้สีที่สอดคล้องกับ Corporate Identity ของโรงพยาบาล
  • ขนาดไอคอน: ชัดเจน อ่านง่าย เหมาะกับทุกขนาดหน้าจอมือถือ
  • ภาษา: ใช้ภาษาไทยที่เข้าใจง่าย หลีกเลี่ยงศัพท์เทคนิค
  • Responsive: แสดงผลได้ดีทั้งบน iOS และ Android

2.1.1.2 Flex Message แบบฟอร์มลงทะเบียน

TOR Reference: 3.3.2

คำอธิบาย: Flex Message คือรูปแบบข้อความที่มีความยืดหยุ่นสูง สามารถกำหนด Layout และองค์ประกอบต่างๆ ได้อย่างอิสระ ใช้สำหรับแสดงแบบฟอร์มลงทะเบียนที่มีหลายฟิลด์ในรูปแบบที่สวยงามและใช้งานง่าย แบบฟอร์มนี้จะรวบรวมข้อมูลที่จำเป็นในการเชื่อมโยงผู้ใช้ LINE กับข้อมูลผู้ป่วยในระบบโรงพยาบาล

การทำงาน: 1. เมื่อผู้ป่วยแตะปุ่ม "ลงทะเบียน" จาก Rich Menu ระบบจะแสดง Flex Message ที่มีแบบฟอร์ม 2. แบบฟอร์มประกอบด้วยฟิลด์:

  • เลขบัตรประชาชน (13 หลัก)
  • รหัสโรงพยาบาล (HN)
  • วันเดือนปีเกิด (ในรูปแบบ DD/MM/YYYY)
  • เบอร์โทรศัพท์

  • ชื่อผู้ติดต่อ (กรณีผู้ป่วยไม่สามารถใช้มือถือเอง)

  • แต่ละฟิลด์มีปุ่ม Action ให้ผู้ป่วยกรอกข้อมูล หรือเลือกจาก Template

  • ระบบจะตรวจสอบรูปแบบข้อมูลเบื้องต้น (เช่น เลขบัตรประชาชนต้องเป็นตัวเลข 13 หลัก)
  • เมื่อกรอกข้อมูลครบแล้ว ผู้ป่วยกดปุ่ม "ยืนยันข้อมูล" เพื่อส่งข้อมูลไปตรวจสอบกับระบบ HIS

UI/UX Requirements:

  • Layout: แสดงฟอร์มในรูปแบบ Card ที่อ่านง่าย มีหัวข้อชัดเจน
  • Input Validation: แสดงข้อความช่วยเหลือและตัวอย่าง เช่น "กรุณากรอกเลขบัตรประชาชน 13 หลัก"
  • Error Handling: แสดงข้อความแจ้งเตือนเมื่อกรอกข้อมูลไม่ถูกต้อง ด้วยภาษาที่เข้าใจง่าย
  • Action Buttons: ปุ่มมีขนาดใหญ่พอ กดง่าย สีสันชัดเจน
  • Privacy Notice: แสดงข้อความแจ้งเกี่ยวกับการเก็บข้อมูลส่วนบุคคลตาม PDPA

2.1.1.3 ตรวจสอบข้อมูลกับ HIS

TOR Reference: 3.3.3, 3.7.1

คำอธิบาย: หลังจากผู้ป่วยกรอกข้อมูลในแบบฟอร์มและกดยืนยัน ระบบจะส่งข้อมูลไปตรวจสอบความถูกต้องกับฐานข้อมูลผู้ป่วยในระบบ HIS (Hospital Information System) เพื่อยืนยันว่าผู้ป่วยมีข้อมูลในโรงพยาบาลจริง และข้อมูลที่กรอกมาตรงกับข้อมูลในระบบ

การทำงาน:

  1. ระบบรับข้อมูลจากแบบฟอร์ม LINE ผ่าน Webhook
  2. ตรวจสอบรูปแบบข้อมูล (Format Validation) เช่น เลขบัตรประชาชน 13 หลัก, วันเกิดเป็นรูปแบบวันที่ที่ถูกต้อง
  3. Query ข้อมูลผู้ป่วยจากฐานข้อมูล HIS โดยใช้เลขบัตรประชาชนเป็น Primary Key

  4. เปรียบเทียบข้อมูลที่กรอกมากับข้อมูลในระบบ:

  5. เลขบัตรประชาชนต้องตรงกัน

  6. รหัสโรงพยาบาล (HN) ต้องตรงกัน

  7. วันเดือนปีเกิดต้องตรงกัน

  8. หากข้อมูลตรงกัน บันทึก LINE User ID เชื่อมกับ HN ในตาราง Patient Registration

  9. หากข้อมูลไม่ตรงกัน หรือไม่พบข้อมูล แจ้งกลับไปยังผู้ป่วยพร้อมข้อความช่วยเหลือ

UI/UX Requirements:

  • Loading State: แสดง Loading indicator พร้อมข้อความ "กำลังตรวจสอบข้อมูล..."
  • Success Message: เมื่อสำเร็จ แสดงข้อความยืนยันพร้อมข้อมูลผู้ป่วยที่ตรวจสอบแล้ว (ชื่อ-สกุล, HN)
  • Error Message: เมื่อไม่พบข้อมูล หรือข้อมูลไม่ตรงกัน แสดงข้อความแนะนำให้ตรวจสอบข้อมูลอีกครั้ง หรือติดต่อเจ้าหน้าที่
  • Retry Option: มีปุ่ม "ลองใหม่อีกครั้ง" หรือ "แก้ไขข้อมูล"
  • Contact Support: มีลิงก์หรือปุ่มสำหรับติดต่อเจ้าหน้าที่กรณีมีปัญหา

2.1.1.4 ยืนยันการลงทะเบียนสำเร็จ

TOR Reference: 3.3.3

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

การทำงาน:

  1. หลังจากบันทึกข้อมูลการลงทะเบียนสำเร็จในฐานข้อมูล ระบบจะส่ง Flex Message แสดงสถานะความสำเร็จ

  2. ข้อความยืนยันประกอบด้วย:

  3. ไอคอน Checkmark หรือ Success icon

  4. ข้อความ "ลงทะเบียนสำเร็จ"
  5. ข้อมูลผู้ป่วย: ชื่อ-สกุล, HN

  6. ข้อความแนะนำการใช้งานเบื้องต้น

  7. แสดงปุ่มตัวเลือก:

  8. "เปิดการแจ้งเตือน" - เพื่อรับข้อความนัดหมายอัตโนมัติ

  9. "ดูคู่มือการใช้งาน" - เพื่อดูวิธีใช้งานระบบ

  10. "กลับหน้าหลัก" - กลับไปที่ Rich Menu

  11. อัปเดต Rich Menu ให้แสดงเมนูสำหรับผู้ที่ลงทะเบียนแล้ว (ซ่อนปุ่มลงทะเบียน แสดงเมนูหลักแทน)

UI/UX Requirements:

  • Visual Confirmation: ใช้สีเขียวหรือสีที่บ่งบอกความสำเร็จ พร้อม Icon ที่ชัดเจน
  • Information Card: แสดงข้อมูลผู้ป่วยในรูปแบบ Card ที่อ่านง่าย
  • Clear CTAs: ปุ่ม Call-to-Action ชัดเจน มีคำอธิบายว่าจะเกิดอะไรเมื่อกด
  • Welcome Message: ข้อความต้อนรับที่เป็นมิตร สร้างความมั่นใจให้ผู้ใช้
  • Next Steps: แนะนำขั้นตอนถัดไปที่ผู้ใช้สามารถทำได้

2.1.2 Appointment Notification

2.1.2.1 รับข้อความแจ้งเตือนนัดหมาย

TOR Reference: 3.5.1, 3.5.2

คำอธิบาย: ระบบจะส่งข้อความแจ้งเตือนการนัดหมายไปยังผู้ป่วยที่ลงทะเบียนแล้วผ่าน LINE Push Message ตามกำหนดเวลาที่ตั้งค่าไว้ในระบบ Back Office (เช่น 1 วัน ก่อนนัดหมาย) ข้อความจะแสดงรายละเอียดการนัดหมายอย่างชัดเจน และให้ผู้ป่วยสามารถตอบกลับได้ทันที

การทำงาน:

  1. Scheduler Service ทำงานตามเวลาที่กำหนด (เช่น ทุกเช้า 8:00 น.)
  2. Query ข้อมูลนัดหมายที่จะถึงกำหนดตามช่วงเวลาที่ตั้งค่าไว้ (เช่น นัดพรุ่งนี้)
  3. กรองเฉพาะผู้ป่วยที่ลงทะเบียนแล้วและเปิดรับการแจ้งเตือน
  4. ส่ง Push Message ไปยัง LINE User ID ของผู้ป่วยแต่ละคน
  5. บันทึกสถานะการส่งข้อความ (timestamp, status) ในตาราง Notification Log
  6. แสดงรายละเอียดนัดหมายในรูปแบบ Flex Message ที่อ่านง่าย พร้อมปุ่มตอบกลับ

UI/UX Requirements:

  • Clear Subject: หัวข้อข้อความชัดเจนว่าเป็นการแจ้งเตือนนัดหมาย
  • Appointment Details: แสดงข้อมูล วันที่, เวลา, สถานที่, ประเภทการตรวจ ครบถ้วน
  • Visual Hierarchy: จัดลำดับข้อมูลตามความสำคัญ (วันเวลาเด่นที่สุด)
  • Tone of Message: ใช้ภาษาที่เป็นมิตร สุภาพ และให้ข้อมูลที่เป็นประโยชน์
  • Notification Time: ส่งในช่วงเวลาที่เหมาะสม (หลีกเลี่ยงเวลาดึก)

2.1.2.2 แสดง Flex Message ข้อมูลนัด

TOR Reference: 3.4.4, 3.3.4

คำอธิบาย: ข้อมูลนัดหมายจะแสดงในรูปแบบ Flex Message ที่ออกแบบมาเป็นพิเศษให้อ่านง่าย สวยงาม และมีข้อมูลครบถ้วน ประกอบด้วยรายละเอียดทั้งหมดที่ผู้ป่วยจำเป็นต้องรู้ เช่น วันเวลา สถานที่ คลินิก และคำแนะนำเพิ่มเติม

การทำงาน:

  1. ระบบดึงข้อมูลนัดหมายจากฐานข้อมูล รวมทั้งข้อมูลผู้ป่วยและคลินิก
  2. สร้าง Flex Message JSON โดยใช้ Template ที่กำหนดไว้ตามประเภทนัดหมาย

  3. ข้อมูลที่แสดงประกอบด้วย:

  4. ชื่อ-สกุลผู้ป่วย และ HN

  5. วันที่นัดหมาย (รูปแบบวันที่อ่านง่าย เช่น "วันจันทร์ที่ 26 พฤศจิกายน 2568")
  6. เวลานัด (เช่น "09:00 - 10:00 น.")
  7. คลินิก/แผนก (เช่น "แผนกเอกซเรย์")
  8. สถานที่ (เช่น "อาคาร 2 ชั้น 3")

  9. ข้อมูลเพิ่มเติม (เช่น "งดอาหาร 6 ชั่วโมงก่อนตรวจ")

  10. เพิ่มไอคอนหรือรูปภาพประกอบเพื่อความชัดเจน

  11. แสดงปุ่ม Quick Reply สำหรับตอบกลับ

UI/UX Requirements:

  • Card Design: ใช้ Card layout ที่มี Header, Body, และ Footer ชัดเจน
  • Color Coding: ใช้สีแยกตามประเภทนัดหมาย (เช่น น้ำเงินสำหรับ Ultrasound, ชมพูสำหรับ Mammogram)
  • Icons: ใช้ไอคอนประกอบ เช่น ไอคอนปฏิทิน, นาฬิกา, สถานที่
  • Font Size: ตัวอักษรขนาดใหญ่พอที่อ่านง่าย โดยเฉพาะวันเวลา
  • Important Info Highlight: ข้อมูลสำคัญ (เช่น "งดอาหาร") ใช้สีหรือรูปแบบที่เด่นชัด

2.1.2.3 Quick Reply ยืนยัน/เลื่อน/ยกเลิก

TOR Reference: 3.5.1, 3.5.3

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

การทำงาน: 1. เมื่อส่งข้อความแจ้งเตือนนัดหมาย ระบบจะแนบ Quick Reply Buttons ไปด้วย 2. ปุ่มตัวเลือก:

  • "✅ ยืนยันมาตามนัด" - ยืนยันว่าจะมาตามนัดหมาย
  • "📅 ขอเลื่อนนัด" - ต้องการเลื่อนนัดหมาย (ระบบจะถามวันใหม่ที่ต้องการ)

  • "❌ ขอยกเลิกนัด" - ต้องการยกเลิกนัดหมาย (ระบบจะถามเหตุผล)

  • เมื่อผู้ป่วยกดปุ่มใดปุ่มหนึ่ง:

  • กรณียืนยัน: บันทึกสถานะเป็น "Confirmed" และส่งข้อความขอบคุณ

  • กรณีขอเลื่อน: แสดง Flex Message ให้เลือกวันที่ใหม่ (Datepicker หรือรายการวันว่าง)

  • กรณียกเลิก: แสดง Quick Reply ให้เลือกเหตุผล (มีธุระกะทันหัน, ไม่สะดวก, อื่นๆ)

  • บันทึกการตอบกลับทั้งหมดในตาราง Notification Response

  • แจ้งเจ้าหน้าที่ผ่านระบบ Back Office กรณีมีการเลื่อนหรือยกเลิกนัด

UI/UX Requirements:

  • Button Layout: ปุ่มเรียงตามความถี่ในการใช้ (ยืนยันอยู่ซ้ายสุด)
  • Visual Feedback: เมื่อกดปุ่มแล้วต้องมี Loading หรือ Confirmation ทันที
  • Icon Usage: ใช้อิโมจิหรือไอคอนประกอบปุ่มเพื่อความชัดเจน
  • Action Flow: การทำงานต่อเนื่องต้องราบรื่น ไม่มีขั้นตอนซับซ้อน
  • Confirmation Message: แสดงข้อความยืนยันการกระทำที่ชัดเจนทุกครั้ง

2.1.2.4 แสดงข้อความตอบกลับ

TOR Reference: 3.5.3

คำอธิบาย:

หลังจากผู้ป่วยตอบกลับการนัดหมายผ่าน Quick Reply หรือตัวเลือกอื่นๆ ระบบจะส่งข้อความยืนยันการตอบกลับกลับไปยังผู้ป่วย เพื่อให้ผู้ป่วยทราบว่าระบบได้รับข้อมูลแล้ว และแจ้งขั้นตอนถัดไป (ถ้ามี)

การทำงาน:

  1. หลังจากบันทึกการตอบกลับแล้ว ระบบจะส่ง Reply Message ทันที

  2. ข้อความตอบกลับตามกรณี:

  3. กรณียืนยันมา: "ขอบคุณค่ะ ระบบบันทึกการยืนยันของคุณเรียบร้อยแล้ว กรุณามาตามวันเวลาที่นัด หากมีข้อสงสัยสามารถติดต่อเจ้าหน้าที่ได้ที่ xxx-xxx-xxxx"

  4. กรณีขอเลื่อนนัด: "ระบบได้รับคำขอเลื่อนนัดของคุณแล้ว เจ้าหน้าที่จะติดต่อกลับภายใน 1 วันทำการ เพื่อนัดวันเวลาใหม่"

  5. กรณียกเลิกนัด: "ระบบได้บันทึกการยกเลิกนัดของคุณเรียบร้อยแล้ว หากต้องการนัดใหม่ กรุณาติดต่อเจ้าหน้าที่ที่ xxx-xxx-xxxx"

  6. เพิ่มข้อมูลรายละเอียดนัดหมายที่เกี่ยวข้อง (สรุปข้อมูลนัดเดิม)

  7. แสดงปุ่ม "กลับหน้าหลัก" หรือ "ดูประวัติการนัด"

UI/UX Requirements:

  • Immediate Feedback: ตอบกลับทันทีหลังผู้ใช้กระทำ ไม่เกิน 2-3 วินาที
  • Contextual Message: ข้อความต้องตรงกับ Action ที่ผู้ใช้ทำ
  • Reassurance: สร้างความมั่นใจว่าระบบได้รับข้อมูลและดำเนินการแล้ว
  • Contact Info: แสดงช่องทางติดต่อชัดเจนกรณีมีปัญหาหรือข้อสงสัย
  • Next Steps: บอกขั้นตอนถัดไป (ถ้ามี) เช่น "เจ้าหน้าที่จะติดต่อกลับภายใน 1 วันทำการ"

2.1.3 Appointment History

2.1.3.1 ดูประวัตินัดหมายของตัวเอง

TOR Reference: 3.3.4

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

การทำงาน:

  1. ผู้ป่วยแตะเมนู "ประวัติ" จาก Rich Menu หรือพิมพ์คำว่า "ประวัติ"
  2. ระบบ Query ข้อมูลนัดหมายทั้งหมดของผู้ป่วย (ใช้ LINE User ID เชื่อมกับ HN)

  3. แสดงรายการนัดหมายในรูปแบบ Flex Message Carousel หรือ List:

  4. แยกเป็นหมวดหมู่: "นัดหมายที่จะมาถึง", "นัดหมายที่ผ่านมา", "นัดหมายที่ยกเลิก"

  5. แสดงข้อมูลสรุป: วันที่, เวลา, คลินิก, สถานะ

  6. จำกัดจำนวนรายการต่อหน้า (เช่น 5-10 รายการ) พร้อมปุ่ม "แสดงเพิ่มเติม"

  7. แต่ละรายการมีปุ่ม "ดูรายละเอียด" เพื่อดูข้อมูลเต็ม

  8. สามารถเลือกดูเฉพาะช่วงเวลา (เช่น 3 เดือนล่าสุด, ปีนี้, ทั้งหมด)

UI/UX Requirements:

  • Categorization: แยกหมวดหมู่นัดหมายชัดเจนด้วยหัวข้อและสี
  • Status Indicator: แสดงสถานะด้วยสีหรือไอคอน (เช่น เขียว=เสร็จสิ้น, เหลือง=รอยืนยัน, แดง=ยกเลิก)
  • Chronological Order: เรียงตามวันที่ใหม่สุดก่อน
  • Pagination: หากมีหลายรายการ ให้มีการแบ่งหน้าหรือ Load more ที่ใช้งานง่าย
  • Empty State: กรณีไม่มีประวัติ แสดงข้อความที่เป็นมิตรและแนะนำการใช้งาน

2.1.3.2 ดูรายละเอียดนัดหมาย

TOR Reference: 3.3.4

คำอธิบาย: เมื่อผู้ป่วยต้องการดูรายละเอียดเพิ่มเติมของนัดหมายใดนัดหมายหนึ่ง สามารถกดที่รายการนั้นเพื่อดูข้อมูลเต็มรูปแบบ รวมทั้งประวัติการตอบกลับหรือการเปลี่ยนแปลงนัดหมาย

การทำงาน:

  1. ผู้ป่วยกดปุ่ม "ดูรายละเอียด" จากรายการนัดหมายในประวัติ
  2. ระบบ Query ข้อมูลนัดหมายนั้นโดยละเอียด พร้อมประวัติการเปลี่ยนแปลง

  3. แสดง Flex Message รายละเอียดเต็ม ประกอบด้วย:

  4. ข้อมูลผู้ป่วย: ชื่อ-สกุล, HN

  5. วันที่และเวลานัด
  6. คลินิก/แผนก
  7. สถานที่ตรวจ
  8. แพทย์ผู้ตรวจ (ถ้ามี)
  9. ข้อมูลเพิ่มเติมหรือคำแนะนำ
  10. สถานะนัดหมาย (ยืนยัน, รอยืนยัน, เลื่อน, ยกเลิก, เสร็จสิ้น)

  11. ประวัติการตอบกลับ (ถ้ามี) เช่น "ยืนยันเมื่อ 25/11/2568 10:30 น."

  12. มีปุ่มสำหรับ Action ที่เกี่ยวข้อง:

  13. "เพิ่มเข้าปฏิทิน" (Export to Calendar)

  14. "แชร์ข้อมูล" (Share to LINE friend)
  15. "กลับไปยังประวัติ"

UI/UX Requirements:

  • Complete Information: แสดงข้อมูลครบถ้วน ไม่ให้ผู้ใช้ต้องถามเพิ่ม
  • Visual Timeline: แสดงประวัติการเปลี่ยนแปลงในรูปแบบ Timeline ถ้ามีหลายรายการ
  • Highlight Status: สถานะปัจจุบันเด่นชัด ใช้สีและไอคอนที่เหมาะสม
  • Action Buttons: ปุ่มที่มีประโยชน์และใช้งานง่าย
  • Back Navigation: มีปุ่มกลับที่ชัดเจนเพื่อไม่ให้ผู้ใช้งง

2.1.4 Settings & Help

2.1.4.1 เปิด/ปิดการแจ้งเตือน

TOR Reference: 3.3.5

คำอธิบาย: ผู้ป่วยสามารถเลือกเปิดหรือปิดการรับการแจ้งเตือนนัดหมายผ่าน LINE ได้ตามความต้องการ ฟีเจอร์นี้ให้ความยืดหยุ่นแก่ผู้ใช้ที่อาจต้องการหยุดรับการแจ้งเตือนชั่วคราว แต่ยังคงสามารถดูข้อมูลนัดหมายในระบบได้

การทำงาน:

  1. ผู้ป่วยเข้าเมนู "ตั้งค่า" จาก Rich Menu
  2. แสดงตัวเลือกการตั้งค่า รวมทั้ง "การแจ้งเตือนนัดหมาย"
  3. แสดงสถานะปัจจุบัน: "เปิดอยู่" หรือ "ปิดอยู่"

  4. มีปุ่ม Toggle สำหรับเปิด/ปิด:

  5. เปิดการแจ้งเตือน: ระบบจะส่งข้อความแจ้งเตือนก่อนนัดหมายอัตโนมัติ

  6. ปิดการแจ้งเตือน: ระบบจะหยุดส่งข้อความแจ้งเตือน แต่ยังสามารถดูประวัตินัดได้

  7. บันทึกการตั้งค่าในฐานข้อมูล (ฟิลด์ notification_enabled)

  8. แสดงข้อความยืนยันการเปลี่ยนแปลงการตั้งค่า
  9. แนะนำผลกระทบของการปิดการแจ้งเตือน (เช่น "คุณจะไม่ได้รับการแจ้งเตือนนัดหมายอัตโนมัติ กรุณาจดจำวันนัดด้วยตนเอง")

UI/UX Requirements:

  • Toggle Switch: ใช้ Toggle ที่เห็นสถานะชัดเจน (เปิด/ปิด)
  • Current Status: แสดงสถานะปัจจุบันก่อนที่จะเปลี่ยนแปลง
  • Confirmation: ยืนยันการเปลี่ยนแปลงด้วยข้อความที่ชัดเจน
  • Warning Message: กรณีปิดการแจ้งเตือน แสดงคำเตือนเบาๆ ว่าจะไม่ได้รับการแจ้งเตือนอีก
  • Easy Revert: สามารถเปิดการแจ้งเตือนกลับได้ง่าย

2.1.4.2 แสดงคู่มือการใช้งาน

TOR Reference: 6.1

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

การทำงาน:

  1. ผู้ป่วยเข้าเมนู "คู่มือการใช้งาน" หรือพิมพ์คำว่า "ช่วยเหลือ"

  2. แสดงเมนูหัวข้อคู่มือในรูปแบบ Flex Message หรือ Carousel:

  3. "วิธีลงทะเบียนครั้งแรก"

  4. "วิธีดูนัดหมายและตอบกลับ"
  5. "วิธีดูประวัติการนัด"
  6. "วิธีตั้งค่าการแจ้งเตือน"

  7. "วิธีติดต่อเจ้าหน้าที่"

  8. เมื่อเลือกหัวข้อ แสดงเนื้อหาคู่มือในรูปแบบ Flex Message พร้อมภาพประกอบ

  9. เนื้อหาใช้ภาษาไทยที่เข้าใจง่าย มีภาพหน้าจอตัวอย่าง
  10. มี FAQ สำหรับคำถามที่พบบ่อย
  11. มีปุ่ม "กลับเมนูคู่มือ" และ "ติดต่อเจ้าหน้าที่" กรณียังไม่เข้าใจ

UI/UX Requirements:

  • Simple Language: ใช้ภาษาที่เข้าใจง่าย หลีกเลี่ยงศัพท์เทคนิค
  • Step-by-Step: แสดงขั้นตอนเป็นลำดับชัดเจน มีเลขกำกับ
  • Screenshots: มีภาพหน้าจอประกอบทุกขั้นตอน
  • Searchable: สามารถค้นหาหัวข้อที่ต้องการได้
  • Updated Content: เนื้อหาต้องทันสมัยและตรงกับระบบปัจจุบัน

2.1.4.3 ติดต่อเจ้าหน้าที่

TOR Reference: 6.3, 6.4

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

การทำงาน:

  1. ผู้ป่วยเข้าเมนู "ติดต่อเจ้าหน้าที่" จาก Rich Menu

  2. แสดง Flex Message ข้อมูลการติดต่อ:

  3. เบอร์โทรศัพท์: xxx-xxx-xxxx

  4. เวลาทำการ: จันทร์-ศุกร์ 08:00-16:00 น.
  5. อีเมล: [email protected]

  6. LINE: สามารถพิมพ์ข้อความถามได้เลย (มีเจ้าหน้าที่ตอบในเวลาทำการ)

  7. มีปุ่มสำหรับ Action ต่างๆ:

  8. "โทรออก" (เปิดแอพโทรศัพท์)

  9. "ส่งอีเมล" (เปิดแอพอีเมล)

  10. "พิมพ์ข้อความถาม" (เปิดแชท)

  11. หากผู้ป่วยพิมพ์ข้อความถาม:

  12. ระบบบันทึกข้อความลงใน Contact Request Log

  13. แจ้งเตือนเจ้าหน้าที่ใน Back Office

  14. ส่งข้อความตอบกลับอัตโนมัติว่า "ได้รับข้อความแล้ว เจ้าหน้าที่จะติดต่อกลับภายใน 1 วันทำการ"

  15. แสดง SLA เวลาตอบกลับ (ตาม TOR 6.3: Remote support ภายใน 8 ชั่วโมง)

UI/UX Requirements:

  • Multiple Channels: ให้ตัวเลือกช่องทางการติดต่อหลายรูปแบบ
  • Clear Contact Info: แสดงข้อมูลการติดต่อครบถ้วนและชัดเจน
  • Operating Hours: ระบุเวลาทำการชัดเจนเพื่อจัดการ Expectation
  • Click-to-Call: ปุ่มโทรออกควร Link ตรงไปยังแอพโทรศัพท์
  • Response Time: แจ้ง SLA เวลาตอบกลับให้ผู้ใช้ทราบ

สรุป Module 2: Front Office (LINE OA Interface)

ความสำคัญ: Module นี้เป็นจุดสัมผัสหลัก (Main Touchpoint) ระหว่างผู้ป่วยกับระบบ ต้องออกแบบให้ใช้งานง่าย เข้าใจง่าย และตอบสนองเร็ว เพราะผู้ใช้ส่วนใหญ่เป็นผู้ป่วยทั่วไปที่อาจไม่คุ้นเคยกับเทคโนโลยี ครอบคลุมข้อกำหนดใน TOR 3.3.1-3.3.5, 3.5.1-3.5.4

Timeline Summary: - SA: 20 ชั่วโมง - UI Design: 46 ชั่วโมง
- Backend Dev: 96 ชั่วโมง - Frontend Dev: 0 ชั่วโมง (LINE OA ไม่ต้องพัฒนา Frontend แยก) - Testing: 73.5 ชั่วโมง - PM: 16.5 ชั่วโมง - Marketing Officer: 3 ชั่วโมง