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

1.1 User Management

1.1 Module: User Management (ระบบบริหารการจัดการผู้ใช้งาน)

อ้างอิง TOR:

  • 3.2 ระบบผู้ใช้งาน (ครบทุกข้อ 3.2.1 - 3.2.5)

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

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

1.1.1 Feature: User Profile Management

1. สร้าง/แก้ไข/ลบข้อมูลผู้ใช้งาน

TOR Reference: 3.2.1

คำอธิบาย: ฟีเจอร์พื้นฐานสำหรับการจัดการข้อมูลผู้ใช้งานในระบบ เป็น CRUD (Create, Read, Update, Delete) operation ที่ต้องมีความสะดวกและปลอดภัย

ข้อมูลที่เก็บ (ตาม TOR 3.2.1):

  • ชื่อผู้ใช้งาน (Username): สำหรับ Login เข้าระบบ (Unique)
  • รหัสการเข้าใช้งาน (Password): เข้ารหัสแบบ Hash (bcrypt หรือ argon2)
  • ชื่อ-สกุล: ชื่อจริงของเจ้าหน้าที่
  • เบอร์ติดต่อ: สำหรับการติดต่อฉุกเฉิน หรือรับ OTP
  • หน่วยงาน: แผนกที่สังกัด (เช่น แผนกเอกซเรย์, งานเวชระเบียน)

การทำงาน:

  1. สร้างผู้ใช้ใหม่:
  2. ผู้ดูแลระบบกรอกข้อมูลในฟอร์ม
  3. ระบบตรวจสอบ Validation (Username ซ้ำ, รูปแบบข้อมูล)
  4. สร้างรหัสผ่านเริ่มต้น หรือให้ผู้ใช้ตั้งเอง

  5. บันทึกลง Database พร้อมสถานะ "รออนุมัติ"

  6. แก้ไขข้อมูล:

  7. ค้นหาผู้ใช้จากรายการ
  8. แก้ไขข้อมูลที่ต้องการ (ยกเว้น Username)

  9. บันทึกพร้อม Log การแก้ไข

  10. ลบผู้ใช้งาน:

  11. Soft Delete (ไม่ลบจริง แต่ทำเครื่องหมายว่าถูกลบ)
  12. เก็บประวัติไว้เพื่อการตรวจสอบ

UI/UX Requirements:

  • หน้าจอรายการผู้ใช้งานแบบตาราง (Table view) พร้อมคอลัมน์: ชื่อผู้ใช้, ชื่อ-สกุล, เบอร์, หน่วยงาน, สถานะ
  • ปุ่ม "เพิ่มผู้ใช้ใหม่" เด่นชัด (สีเขียว/สีหลักของระบบ)
  • Modal/Form สำหรับกรอกข้อมูล มี Validation แสดงผลแบบ Real-time
  • ปุ่มแก้ไข (ไอคอนดินสอ) และปุ่มลบ (ไอคอนถังขยะ) ในแต่ละแถว
  • Confirmation Dialog ก่อนลบพร้อมแสดงชื่อผู้ใช้ที่จะลบ
  • ช่องค้นหาด้วย Username, ชื่อ-สกุล หรือหน่วยงาน
  • Pagination สำหรับรายการที่เยอะ (แสดง 10-20 รายการต่อหน้า)
2. ระบบจัดการสิทธิผู้ใช้งาน (Role-Based Access Control)

TOR Reference: 3.2.2

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

ระดับสิทธิ (ตาม TOR 3.2.2):

  1. ผู้ดูแลระบบ (System Administrator):

  2. สิทธิเต็มรูปแบบทั้งระบบ

  3. จัดการผู้ใช้งานทั้งหมด (เพิ่ม/แก้ไข/ลบ/อนุมัติ)
  4. ตั้งค่าระบบทั้งหมด
  5. ดูรายงานทั้งหมด
  6. จัดการการเชื่อมต่อ HIS/RIS/LIS

  7. ดู Activity Log ทั้งหมด

  8. หัวหน้างาน (Department Head):

  9. จัดการนัดหมายในแผนกตัวเอง

  10. ดูรายงานของแผนกตัวเอง
  11. อนุมัติ/ยกเลิกผู้ใช้งานในแผนก
  12. ส่งข้อความแจ้งเตือนแบบกลุ่ม

  13. ตั้งค่าการแจ้งเตือนของแผนก

  14. ผู้ปฏิบัติงาน (Staff):

  15. ดูข้อมูลนัดหมาย (อ่านอย่างเดียว)

  16. ส่งข้อความเร่งด่วนเฉพาะบุคคล (ถ้าได้รับอนุญาต)
  17. ดูรายงานพื้นฐาน
  18. จัดการข้อมูลผู้ป่วยที่ลงทะเบียน (ค้นหา/ดู)

การทำงาน:

  1. เมื่อสร้างผู้ใช้ใหม่ ต้องระบุ Role
  2. ระบบเช็คสิทธิทุกครั้งที่เข้าถึง Feature
  3. UI จะแสดงเฉพาะเมนู/ปุ่มที่มีสิทธิ
  4. Backend ต้องมี Middleware ตรวจสอบสิทธิทุก API call

UI/UX Requirements:

  • Dropdown สำหรับเลือก Role เมื่อสร้าง/แก้ไขผู้ใช้ (แสดงชื่อภาษาไทยและคำอธิบายสั้นๆ)
  • Badge แสดง Role ในรายการผู้ใช้ (สีต่างกันแต่ละ Role: แดง=Admin, เหลือง=หัวหน้า, น้ำเงิน=Staff)
  • เมนูด้านข้างแสดงเฉพาะฟีเจอร์ที่มีสิทธิ (ซ่อน/ปิดการใช้งานเมนูที่ไม่มีสิทธิ)
  • Error message ชัดเจนเมื่อพยายามเข้าถึงฟีเจอร์ที่ไม่มีสิทธิ พร้อมบอกว่าต้องมีสิทธิอะไร
  • หน้าจอจัดการสิทธิ (สำหรับ Admin) แสดงตาราง Role vs Permission แบบ Matrix
3. ระบบอนุมัติและยกเลิกผู้ใช้งาน

TOR Reference: 3.2.3

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

การทำงาน:

  1. การอนุมัติผู้ใช้ใหม่:

  2. เมื่อสร้างผู้ใช้ใหม่ → สถานะ "รออนุมัติ" (Pending)

  3. ผู้ดูแลระบบ/หัวหน้างาน เข้าดูรายการรออนุมัติ
  4. ตรวจสอบข้อมูลและอนุมัติ → สถานะ "ใช้งานได้" (Active)
  5. ระบบส่งอีเมล/SMS แจ้งผู้ใช้ว่าบัญชีพร้อมใช้งาน

  6. หากไม่อนุมัติ → สถานะ "ปฏิเสธ" (Rejected) พร้อมเหตุผล

  7. การยกเลิก/ระงับผู้ใช้งาน:

  8. ผู้ดูแลระบบสามารถระงับบัญชีชั่วคราว (Suspended)

  9. หรือยกเลิกถาวร (Deleted)
  10. ระบุเหตุผลในการยกเลิก
  11. ผู้ใช้ที่ถูกยกเลิกไม่สามารถ Login ได้

สถานะของผู้ใช้งาน:

  • pending - รออนุมัติ
  • active - ใช้งานได้ปกติ
  • suspended - ระงับชั่วคราว
  • rejected - ถูกปฏิเสธ
  • deleted - ยกเลิกแล้ว

UI/UX Requirements:

  • หน้าจอ "รายการรออนุมัติ" แยกต่างหาก มี Badge แสดงจำนวนรออนุมัติที่เมนู
  • Badge แสดงสถานะผู้ใช้ (เขียว=ใช้งานได้, เหลือง=รออนุมัติ, แดง=ระงับ/ยกเลิก, เทา=ปฏิเสธ)
  • ปุ่ม "อนุมัติ" (เขียว) / "ปฏิเสธ" (แดง) พร้อม Modal สำหรับใส่เหตุผลการปฏิเสธ (บังคับกรอก)
  • Notification แจ้งเตือนแบบ Real-time เมื่อมีผู้ใช้ใหม่รออนุมัติ (สำหรับ Admin/หัวหน้า)
  • กรองตามสถานะได้ (ทั้งหมด/รออนุมัติ/ใช้งาน/ระงับ/ปฏิเสธ/ยกเลิก)
  • แสดงข้อมูลผู้สร้าง วันที่สร้าง และเหตุผล (ถ้ามี) ในรายละเอียด
4. ระบบร้องขอรหัสผ่านใหม่

TOR Reference: 3.2.4

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

การทำงาน:

ขั้นตอนที่ 1: ร้องขอรีเซ็ตรหัสผ่าน

  1. ผู้ใช้คลิก "ลืมรหัสผ่าน?" ที่หน้า Login
  2. กรอก Username หรือ Email
  3. ระบบตรวจสอบว่ามีผู้ใช้นี้ในระบบหรือไม่
  4. ส่ง OTP ไปยังเบอร์โทรที่ลงทะเบียนไว้ (SMS)
  5. หรือส่งลิงก์รีเซ็ตไปยัง Email (ถ้ามี)

ขั้นตอนที่ 2: ยืนยันตัวตน

  1. ผู้ใช้กรอก OTP ที่ได้รับ (อายุ 5-10 นาที)
  2. หรือคลิกลิงก์จาก Email (อายุ 15-30 นาที)

ขั้นตอนที่ 3: ตั้งรหัสผ่านใหม่

  1. กรอกรหัสผ่านใหม่ (ต้องผ่านเงื่อนไข Password Policy)
  2. ยืนยันรหัสผ่านอีกครั้ง
  3. บันทึก Hash ลง Database
  4. ส่ง SMS/Email แจ้งว่ารหัสผ่านถูกเปลี่ยนแล้ว

Password Policy (ข้อกำหนดรหัสผ่าน):

  • ความยาวอย่างน้อย 8 ตัวอักษร
  • มีตัวพิมพ์ใหญ่อย่างน้อย 1 ตัว
  • มีตัวเลขอย่างน้อย 1 ตัว
  • มีอักขระพิเศษอย่างน้อย 1 ตัว (แนะนำ)

UI/UX Requirements:

  • ลิงก์ "ลืมรหัสผ่าน?" ที่หน้า Login (เด่นชัดแต่ไม่รบกวนปุ่มหลัก)
  • ฟอร์มกรอก Username หรือเบอร์โทรศัพท์ที่ลงทะเบียน
  • หน้าจอกรอก OTP (6 หลัก) แบบช่องแยก มีปุ่ม "ส่ง OTP ใหม่" (เปิดใช้งานหลัง 60 วินาที)
  • แสดง Countdown Timer สำหรับอายุ OTP (5-10 นาที)
  • ฟอร์มตั้งรหัสผ่านใหม่พร้อม Password Strength Indicator (อ่อน/ปานกลาง/แข็งแรง)
  • แสดงเงื่อนไขรหัสผ่านแบบ Checklist (✓ เมื่อผ่าน, ✗ เมื่อไม่ผ่าน)
  • ปุ่มแสดง/ซ่อนรหัสผ่าน (ไอคอนตา)
  • ข้อความแจ้งเตือนสำเร็จ/ล้มเหลว ชัดเจนในแต่ละขั้นตอน
  • ระบบป้องกันการส่งคำขอซ้ำบ่อยเกินไป (แสดงข้อความแจ้งเตือน)
5. บันทึก Activity Log (Audit Trail)

TOR Reference: 3.2.5

คำอธิบาย: ระบบบันทึกการกระทำทั้งหมดของผู้ใช้งาน เพื่อความปลอดภัย การตรวจสอบย้อนหลัง และการตรวจสอบการปฏิบัติตาม พ.ร.บ. คุ้มครองข้อมูลส่วนบุคคล (PDPA)

การกระทำที่ต้องบันทึก (ตาม TOR 3.2.5):

  • บันทึกผล: บันทึกข้อมูลนัดหมาย, แก้ไขข้อมูลผู้ป่วย
  • ลบข้อมูล: ลบผู้ใช้งาน, ลบนัดหมาย
  • พิมพ์รายงาน: Export Excel, พิมพ์ PDF
  • การเข้าถึงข้อมูลสำคัญ: ดูข้อมูลผู้ป่วย, เปิดรายงาน

ข้อมูลที่บันทึกในแต่ละ Log:

  • Timestamp: วันเวลาที่ทำ (ความละเอียดถึงวินาที)
  • User ID: ผู้ที่ทำ
  • Action: การกระทำที่ทำ (เช่น CREATE, UPDATE, DELETE, VIEW, EXPORT)
  • Entity Type: ประเภทข้อมูลที่กระทำ (เช่น User, Patient, Appointment)
  • Entity ID: ID ของข้อมูลนั้น
  • Changes: ข้อมูลเดิมและข้อมูลใหม่ (สำหรับ UPDATE)
  • IP Address: IP ที่เข้าถึง
  • User Agent: เบราว์เซอร์/อุปกรณ์ที่ใช้
  • Result: สำเร็จ หรือ ล้มเหลว

การทำงาน:

  1. ทุก API call ที่สำคัญจะผ่าน Middleware บันทึก Log
  2. บันทึกลง Database แบบ Async (ไม่ให้กระทบความเร็ว)
  3. ไม่บันทึกข้อมูลที่เป็นความลับ (เช่น Password)

UI/UX Requirements:

  • หน้าจอ "Activity Log" สำหรับผู้ดูแลระบบ แสดงเป็นตาราง
  • กรองตาม: ผู้ใช้งาน (Dropdown), ประเภทการกระทำ (เพิ่ม/แก้ไข/ลบ/ดู/Export), ช่วงวันที่ (Date Range Picker)
  • ค้นหาแบบ Advanced แบบ Multi-criteria (ค้นหาหลายเงื่อนไขพร้อมกัน)
  • ปุ่ม Export Log เป็น Excel สำหรับการตรวจสอบ (กรองตามเงื่อนไขที่เลือก)
  • แสดงรายละเอียดแบบ Timeline เมื่อคลิกดูแต่ละ Log
  • แสดงข้อมูล: วันเวลา, ผู้ใช้, การกระทำ, ข้อมูลที่กระทำ, ผลลัพธ์ (สำเร็จ/ล้มเหลว)
  • ใช้สีแสดงประเภทการกระทำ (เขียว=สร้าง, น้ำเงิน=แก้ไข, แดง=ลบ, เทา=ดู)
  • Pagination และแสดงผลแบบ Lazy Load สำหรับข้อมูลจำนวนมาก
  • แสดงรายละเอียดการเปลี่ยนแปลง (Before/After) สำหรับการแก้ไข

สรุป Module 1.1: User Management

ความสำคัญ: Module นี้เป็นรากฐานของความปลอดภัยทั้งระบบ ต้องใส่ใจในทุกรายละเอียด เพราะเกี่ยวข้องกับการเข้าถึงข้อมูลผู้ป่วยที่เป็นความลับ ครอบคลุมทุกข้อกำหนดใน TOR 3.2 (3.2.1 - 3.2.5)

Timeline Summary:

  • SA: 11 ชั่วโมง
  • UI Design: 20 ชั่วโมง
  • Backend Dev: 42 ชั่วโมง
  • Frontend Dev: 38 ชั่วโมง
  • Testing: 60 ชั่วโมง
  • PM: 11.2 ชั่วโมง