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

Software Requirements Specification (SRS)

ระบบนัดหมายและตารางเวรแพทย์ (Appointment & Doctor Schedule System)

เวอร์ชัน: 1.1

วันที่: 9 ตุลาคม 2568

จัดทำโดย: ทีมพัฒนาระบบ HIS โรงพยาบาลค่ายธนรัชน์

สารบัญ

  1. บทนำ
  2. คำอธิบายโดยรวม
  3. ความต้องการเฉพาะ
  4. ความต้องการภายนอก
  5. คุณลักษณะของระบบ
  6. ความต้องการที่ไม่ใช่ฟังก์ชัน
  7. การเชื่อมโยงกับระบบอื่น

1. บทนำ

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

เอกสารนี้มีวัตถุประสงค์เพื่อกำหนดความต้องการซอฟต์แวร์สำหรับระบบนัดหมายและตารางเวรแพทย์ (Appointment & Doctor Schedule System) ของโรงพยาบาลค่ายธนรัชน์ ซึ่งจะครอบคลุมการจัดการนัดหมายผู้ป่วย การจัดการตารางเวรแพทย์ และการติดตามผลการนัดหมาย

1.2 ขอบเขต (Scope)

ระบบนัดหมายและตารางเวรแพทย์จะดำเนินการ:

✅ ฟังก์ชันหลักของระบบ: - 📅 การจัดการข้อมูลพื้นฐาน - กำหนดโควต้าแพทย์ วันหยุด และการปฏิบัติก่อนพบแพทย์ - 🔍 การตรวจสอบข้อมูลการนัดหมาย - แสดงข้อมูลผู้ป่วยที่นัด ติดตามผลการมาตามนัด - 📝 การลงทะเบียนนัดหมาย - บันทึกนัดหมาย ยกเลิกนัด เลื่อนนัด และพิมพ์ใบนัด - 📊 การจัดการตารางเวรแพทย์ - กำหนดตารางการทำงานของแพทย์และตรวจสอบในรูปแบบปฏิทิน - 🏥 การส่งตรวจผู้ป่วยล่วงหน้า - ออก Visit ล่วงหน้าและสั่ง Lab/X-Ray ตามนัด

🔗 ฟังก์ชันที่เชื่อมโยงกับระบบอื่น: - เชื่อมโยงกับระบบเวชระเบียน (1.2.1) สำหรับข้อมูลผู้ป่วย - เชื่อมโยงกับระบบซักประวัติ (1.2.2) และระบบห้องตรวจแพทย์ (1.2.3) สำหรับการนัดติดตาม - เชื่อมโยงกับระบบงานชันสูตร (1.2.7) และระบบรังสีวิทยา (1.2.8) สำหรับการสั่งตรวจล่วงหน้า - เชื่อมโยงกับระบบผู้ดูแลระบบ (1.2.21) สำหรับการจัดการข้อมูลพื้นฐาน

1.3 คำจำกัดความ และตัวย่อ

คำศัพท์ คำอธิบาย
HN Hospital Number - หมายเลขประจำตัวผู้ป่วย
Visit การมารับบริการของผู้ป่วย
โควต้า จำนวนผู้ป่วยที่แพทย์สามารถรับได้ต่อวัน
Slot ช่วงเวลาสำหรับการนัดหมาย
No Show ผู้ป่วยที่ไม่มาตามนัดหมาย
Walk-in ผู้ป่วยที่มาโดยไม่ได้นัดหมาย
Reschedule การเลื่อนนัดหมาย
Pre-visit การส่งตรวจล่วงหน้าก่อนวันนัด
Template แม่แบบการนัดหมายสำหรับแต่ละคลินิก
Shift เวรการทำงานของแพทย์

1.4 เอกสารอ้างอิง

  • TOR ระบบนัดหมายและตารางเวรแพทย์ โรงพยาบาลค่ายธนรัชน์
  • SRS ระบบเวชระเบียน (1.2.1) - เพื่อการเชื่อมโยงข้อมูลผู้ป่วย
  • SRS ระบบซักประวัติ (1.2.2) - เพื่อการนัดติดตาม
  • SRS ระบบห้องตรวจแพทย์ (1.2.3) - เพื่อการนัดติดตาม
  • มาตรฐานการจัดการคิวและการนัดหมายของกระทรวงสาธารณสุข

2. คำอธิบายโดยรวม

2.1 มุมมองผลิตภัณฑ์

ระบบนัดหมายและตารางเวรแพทย์เป็นส่วนหนึ่งของระบบสารสนเทศโรงพยาบาล (HIS) ที่ทำหน้าที่เป็น Scheduling Hub โดยจัดการการนัดหมายผู้ป่วยและตารางเวรแพทย์ เพื่อให้การรักษาพยาบาลเป็นไปอย่างมีประสิทธิภาพ

2.2 ฟังก์ชันผลิตภัณฑ์

ระบบมีฟังก์ชันหลัก 5 กลุ่ม:

  1. การจัดการข้อมูลพื้นฐาน - กำหนดโควต้าแพทย์ วันหยุด และการเตรียมตัวผู้ป่วย
  2. การตรวจสอบข้อมูลการนัดหมาย - แสดงรายการนัด ติดตามผล และรายงาน
  3. การลงทะเบียนนัดหมาย - บันทึก แก้ไข ยกเลิก และพิมพ์ใบนัด
  4. การจัดการตารางเวรแพทย์ - กำหนดและแสดงตารางการทำงานของแพทย์
  5. การส่งตรวจผู้ป่วยล่วงหน้า - ออก Visit และสั่งตรวจล่วงหน้าตามนัด

2.3 คลาสผู้ใช้และลักษณะ

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

2.4 สภาพแวดล้อมการปฏิบัติงาน

  • ระบบทำงานในสภาพแวดล้อมโรงพยาบาล 24/7
  • รองรับการใช้งานพร้อมกันหลายจุดบริการ
  • เชื่อมต่อกับระบบอื่นๆ ผ่าน API และฐานข้อมูลกลาง
  • รองรับการพิมพ์ใบนัดหมายและรายงานต่างๆ

3. ความต้องการเฉพาะ

3.1 ความต้องการภายนอก

3.1.1 อินเทอร์เฟซผู้ใช้

  • ระบบต้องมี Interface แบบปฏิทิน (Calendar View) สำหรับแสดงข้อมูลนัดหมาย
  • รองรับการใช้งานบนอุปกรณ์ต่างๆ (Desktop, Tablet)
  • มีระบบ Search และ Filter สำหรับการค้นหาข้อมูลนัดหมาย
  • แสดงข้อมูลในรูปแบบตารางเวลาและแบบรายการ

3.1.2 อินเทอร์เฟซฮาร์ดแวร์

  • รองรับเครื่องพิมพ์สำหรับพิมพ์ใบนัดหมาย
  • เชื่อมต่อกับระบบแจ้งเตือนอัตโนมัติ (SMS/Email)

3.1.3 อินเทอร์เฟซซอฟต์แวร์

  • เชื่อมโยงกับระบบเวชระเบียน (1.2.1) สำหรับข้อมูลผู้ป่วย
  • เชื่อมโยงกับระบบซักประวัติ (1.2.2) และระบบห้องตรวจแพทย์ (1.2.3) สำหรับการนัดติดตาม
  • เชื่อมโยงกับระบบงานชันสูตร (1.2.7) และระบบรังสีวิทยา (1.2.8) สำหรับการสั่งตรวจล่วงหน้า
  • เชื่อมโยงกับระบบจัดการคิว (Queue Management) สำหรับการเรียกคิว

4. คุณลักษณะของระบบ

4.1 การจัดการข้อมูลพื้นฐาน

4.1.1 การกำหนดจำนวนคนไข้นัดหมายของแพทย์

คำอธิบาย: ระบบสามารถกำหนดโควต้าผู้ป่วยสำหรับแพทย์แต่ละท่านต่อวัน

ข้อกำหนด: - FR-4.1.1: ระบบต้องสามารถกำหนดจำนวนคนไข้นัดหมายของแพทย์แต่ละท่านต่อวันได้ - FR-4.1.2: ระบบต้องสามารถกำหนดโควต้าต่างกันสำหรับวันต่างๆ ในสัปดาห์ - FR-4.1.3: ระบบต้องสามารถกำหนดโควต้าพิเศษสำหรับวันหยุดหรือกรณีฉุกเฉิน - FR-4.1.4: ระบบต้องแสดงเตือนเมื่อจำนวนผู้ป่วยที่นัดเกินโควต้าที่กำหนด

4.1.2 การกำหนดข้อมูลการปฏิบัติก่อนพบแพทย์

คำอธิบาย: ระบบสามารถกำหนดการเตรียมตัวและการตรวจที่ต้องทำก่อนพบแพทย์

ข้อกำหนด: - FR-4.1.5: ระบบต้องสามารถกำหนดข้อมูลการปฏิบัติก่อนพบแพทย์ ได้แก่: - คำแนะนำการเตรียมตัว (เช่น งดอาหาร งดน้ำ) - รายการตรวจ Lab ที่ต้องทำก่อนพบแพทย์ - รายการตรวจ X-Ray หรือการตรวจอื่นๆ - คลินิกที่ต้องไปก่อนพบแพทย์ - FR-4.1.6: ระบบต้องสามารถพิมพ์ข้อมูลการปฏิบัติลงในใบนัดหมายได้ - FR-4.1.7: ระบบต้องมี Template การเตรียมตัวสำหรับแต่ละแผนกหรือประเภทการรักษา

4.1.3 การกำหนดข้อมูลวันหยุด

คำอธิบาย: ระบบสามารถจัดการข้อมูลวันหยุดต่างๆ

ข้อกำหนด: - FR-4.1.8: ระบบต้องสามารถกำหนดข้อมูลวันหยุดต่างๆ ได้ ประกอบด้วย: - วันเสาร์-อาทิตย์ - วันหยุดนักขัตฤกษ์ - วันหยุดพิเศษต่างๆ - วันหยุดส่วนตัวของแพทย์ - FR-4.1.9: ระบบต้องตรวจสอบและเตือนเมื่อมีการนัดในวันหยุด - FR-4.1.10: ระบบต้องสามารถกำหนดวันหยุดล่วงหน้าได้อย่างน้อย 1 ปี

4.1.4 การกำหนดตารางการทำงานของแพทย์

คำอธิบาย: ระบบสามารถจัดการตารางเวรและการทำงานของแพทย์

ข้อกำหนด: - FR-4.1.11: ระบบต้องสามารถกำหนดตารางการทำงานของแพทย์แต่ละท่าน ประกอบด้วย: - วันทำงานในแต่ละสัปดาห์ - เวลาเริ่มต้นและสิ้นสุดการทำงาน - ช่วงพักเที่ยง - ห้องตรวจที่รับผิดชอบ - FR-4.1.12: ระบบต้องสามารถตรวจสอบวันทำงานของแพทย์ได้เพื่อยืนยันการนัดหมาย - FR-4.1.13: ระบบต้องแสดงตารางการทำงานในรูปแบบปฏิทินที่ดูง่าย

4.2 การตรวจสอบข้อมูลการนัดหมาย

4.2.1 การแสดงข้อมูลผู้ป่วยที่นัดหมาย

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

ข้อกำหนด: - FR-4.2.1: ระบบต้องสามารถแสดงข้อมูลผู้ป่วยที่นัดหมายโดยระบุช่วงวันที่นัดหมาย และกำหนดข้อมูลเพิ่มเติมได้: - แพทย์ผู้นัดหมาย - คลินิกที่นัดหมาย - ห้องตรวจที่นัดหมาย - FR-4.2.2: ข้อมูลที่แสดงต้องประกอบด้วย: - เลขประจำตัวผู้ป่วย (HN) - ชื่อ - สกุลผู้ป่วย - คลินิกที่นัด - แพทย์ผู้นัด - ห้องตรวจ - วันที่มา (วันที่ทำการบันทึกนัดหมาย) - วันที่ และเวลานัด - หมายเหตุ - FR-4.2.3: ระบบต้องสามารถ Filter ข้อมูลตามแพทย์ คลินิก หรือช่วงวันที่

4.2.2 การตรวจสอบผู้ป่วยที่มาและไม่มาตามนัด

คำอธิบาย: ระบบสามารถติดตามผลการมาตามนัดของผู้ป่วย

ข้อกำหนด: - FR-4.2.4: ระบบต้องสามารถตรวจสอบข้อมูลรายชื่อผู้ป่วยที่มา และไม่มาตามนัดได้ โดยระบุตาม: - แพทย์ผู้นัดหมาย - ห้องตรวจ - คลินิกที่นัด - FR-4.2.5: ระบบต้องบันทึกสถานะการมาตามนัด ได้แก่: - มาตามนัด (Show) - ไม่มาตามนัด (No Show) - มาแต่สาย (Late) - ยกเลิกล่วงหน้า (Cancelled) - FR-4.2.6: ระบบต้องสามารถสร้างรายงานสถิติการมาตามนัดรายแพทย์และรายคลินิก

4.2.3 การตรวจสอบวันทำงานของแพทย์

คำอธิบาย: ระบบสามารถแสดงตารางการทำงานของแพทย์

ข้อกำหนด: - FR-4.2.7: ระบบต้องสามารถตรวจสอบวันทำงานของแพทย์ได้ในรูปแบบปฏิทิน - FR-4.2.8: ระบบต้องแสดงข้อมูลการทำงานของแพทย์ ประกอบด้วย: - วันที่และช่วงเวลาทำงาน - ห้องตรวจที่รับผิดชอบ - จำนวนผู้ป่วยที่นัดในแต่ละวัน - สถานะการทำงาน (ทำงานปกติ/ลา/เวรพิเศษ) - FR-4.2.9: ระบบต้องสามารถแสดงปฏิทินการทำงานแบบรายสัปดาห์และรายเดือน

4.3 การลงทะเบียนนัดหมาย

4.3.1 การบันทึกข้อมูลการนัดหมาย

คำอธิบาย: ระบบสามารถบันทึกข้อมูลการนัดหมายแบบครบถ้วน

ข้อกำหนด: - FR-4.3.1: ระบบต้องสามารถรองรับการจัดเก็บข้อมูลรายการนัดตามรายละเอียดดังนี้: - วันที่นัด - ช่วงเวลาที่นัด - คลินิกที่นัด - สาเหตุการนัด - แพทย์ผู้นัด - การปฏิบัติตัวก่อนพบแพทย์ - การสั่ง Lab/X-Ray ล่วงหน้า - หมายเหตุ (เพิ่มเติม) - FR-4.3.2: ระบบต้องตรวจสอบความถูกต้องของข้อมูลก่อนบันทึก - FR-4.3.3: ระบบต้องสร้างเลขที่นัดหมายที่ไม่ซ้ำกันอัตโนมัติ

4.3.2 การตรวจสอบการนัดหมายซ้ำ

คำอธิบาย: ระบบสามารถตรวจสอบและเตือนการนัดหมายที่ซ้ำกัน

ข้อกำหนด: - FR-4.3.4: การบันทึกนัดหมายเมื่อระบุชื่อแพทย์ที่นัดหมาย ระบบจะแสดงข้อความแจ้งให้ทราบว่าในวันที่นัดหมายมีผู้ป่วยถูกนัดมาแล้วกี่ราย - FR-4.3.5: ระบบต้องตรวจสอบได้ว่ามีการนัดหมายผู้ป่วยในช่วงเวลาเดียวกันมากกว่า 1 ราย - FR-4.3.6: ระบบต้องเตือนเมื่อจำนวนการนัดเกินโควต้าที่กำหนดไว้ - FR-4.3.7: ระบบต้องตรวจสอบการนัดหมายซ้ำของผู้ป่วยรายเดียวกัน

4.3.3 การบันทึกสาเหตุและคำแนะนำการนัด

คำอธิบาย: ระบบสามารถบันทึกเหตุผลและคำแนะนำสำหรับการนัดหมาย

ข้อกำหนด: - FR-4.3.8: การบันทึกการนัดหมายสามารถบอกสาเหตุของการนัดหมาย และในวันนัดผู้ป่วยต้องเตรียมตัวอย่างไรก่อนพบแพทย์บ้าง - FR-4.3.9: ระบบต้องมี Template สาเหตุการนัดที่ใช้บ่อย เช่น: - นัดติดตามผลการรักษา - นัดรับยา - นัดตรวจผลแล็บ - นัดผ่าตัด - FR-4.3.10: ระบบต้องสามารถกำหนดคำแนะนำการเตรียมตัวแบบอัตโนมัติตามประเภทการนัด

4.3.4 การนัดหมายหลายหน่วยตรวจ

คำอธิบาย: ระบบสามารถจัดการการนัดหมายหลายแผนกในวันเดียวกัน

ข้อกำหนด: - FR-4.3.11: ระบบต้องสามารถบันทึกการนัดหมายผู้ป่วยรายเดียวกันได้จากหลายหน่วยตรวจในวันเดียวกัน - FR-4.3.12: ระบบต้องแสดงลำดับการนัดหมายและเวลาที่แนะนำสำหรับแต่ละหน่วยตรวจ - FR-4.3.13: ระบบต้องตรวจสอบความเป็นไปได้ของเวลาในการเดินทางระหว่างหน่วยตรวจ

4.3.5 การตรวจสอบและจัดการข้อมูลการนัดหมาย

คำอธิบาย: ระบบสามารถค้นหาและจัดการข้อมูลการนัดหมายของผู้ป่วย

ข้อกำหนด: - FR-4.3.14: ระบบต้องสามารถทำการตรวจสอบข้อมูลการนัดหมายของผู้ป่วยแต่ละรายได้ - FR-4.3.15: ระบบต้องแสดงประวัติการนัดหมายทั้งหมดของผู้ป่วย รวมถึง: - การนัดที่มาตามกำหนด - การนัดที่ไม่มา - การนัดที่ยกเลิก - การนัดที่เลื่อน

4.3.6 การยกเลิกและเลื่อนนัดหมาย

คำอธิบาย: ระบบสามารถจัดการการยกเลิกและเลื่อนนัดหมาย

ข้อกำหนด: - FR-4.3.16: ระบบต้องสามารถทำการยกเลิกนัดและระบุสาเหตุของการยกเลิกนัดกับผู้ป่วยเป็นรายบุคคลได้ - FR-4.3.17: ระบบต้องสามารถทำการเลื่อนนัดของผู้ป่วย - FR-4.3.18: ระบบต้องเก็บข้อมูลการเลื่อนนัดผู้ป่วยและผู้บันทึกข้อมูลการเลื่อนนัดผู้ป่วย - FR-4.3.19: ระบบต้องบันทึก Log การเปลี่ยนแปลงทุกครั้งพร้อมวันที่และผู้ทำรายการ

4.3.7 การพิมพ์ใบนัดหมาย

คำอธิบาย: ระบบสามารถพิมพ์ใบนัดหมายในรูปแบบต่างๆ

ข้อกำหนด: - FR-4.3.20: ระบบต้องสามารถพิมพ์ใบนัดและรูปแบบของใบนัดหมายของแต่ละหน่วยตรวจสามารถแสดงรายละเอียดที่แตกต่างกันได้ - FR-4.3.21: ระบบต้องสามารถระบุจำนวนใบที่ต้องการจะพิมพ์ได้ - FR-4.3.22: ใบนัดหมายต้องประกอบด้วยข้อมูลสำคัญ: - วันที่และเวลานัด - ชื่อแพทย์ที่นัด - คลินิกและห้องตรวจ - การเตรียมตัวก่อนมา - หมายเลขติดต่อเพื่อเลื่อน/ยกเลิกนัด

4.3.8 การแสดงข้อมูลในรูปแบบปฏิทินและตาราง

คำอธิบาย: ระบบสามารถแสดงข้อมูลการนัดหมายในหลายรูปแบบ

ข้อกำหนด: - FR-4.3.23: ระบบต้องสามารถตรวจสอบรายชื่อผู้ป่วยที่นัดมาในได้ในรูปแบบปฏิทิน - FR-4.3.24: ระบบต้องสามารถตรวจสอบช่วงเวลาที่นัดมาของผู้ป่วยในแต่ละวันได้ในรูปแบบตารางเวลานัด - FR-4.3.25: ระบบต้องสามารถตรวจสอบรายชื่อผู้ป่วยที่ไม่มาตามนัดในแต่ละวันได้ - FR-4.3.26: ระบบต้องสามารถจำกัดจำนวนผู้ป่วยต่อแพทย์ในการนัดแต่ละครั้งได้

4.4 การส่งตรวจผู้ป่วยล่วงหน้า

4.4.1 การส่งตรวจล่วงหน้า (Pre-visit)

คำอธิบาย: ระบบสามารถส่งตรวจผู้ป่วยล่วงหน้าก่อนวันนัดหมาย

ข้อกำหนด: - FR-4.4.1: ระบบต้องสามารถส่งตรวจผู้ป่วยล่วงหน้า (ออก Visit ล่วงหน้า) ตามวันที่นัดมาไปยังจุดต่างๆ ที่นัดได้ - FR-4.4.2: ระบบต้องสร้าง Visit Number สำหรับการตรวจล่วงหน้า - FR-4.4.3: ระบบต้องเชื่อมโยงการส่งตรวจล่วงหน้ากับการนัดหมายหลัก - FR-4.4.4: ระบบต้องแสดงสถานะการส่งตรวจล่วงหน้าในหน้าจัดการการนัดหมาย

4.4.2 การส่งตรวจ Lab/X-Ray ล่วงหน้า

คำอธิบาย: ระบบสามารถสั่งตรวจ Lab และ X-Ray ล่วงหน้าตามการนัดหมาย

ข้อกำหนด: - FR-4.4.5: ระบบต้องสามารถส่งตรวจ Lab/X-Ray ล่วงหน้า (ยืนยันการสั่ง) ตามที่นัดหมายไว้ได้ - FR-4.4.6: ระบบต้องเชื่อมโยงกับระบบงานชันสูตร (1.2.7) สำหรับการสั่ง Lab ล่วงหน้า - FR-4.4.7: ระบบต้องเชื่อมโยงกับระบบรังสีวิทยา (1.2.8) สำหรับการสั่ง X-Ray ล่วงหน้า - FR-4.4.8: ระบบต้องแสดงรายการตรวจที่สั่งล่วงหน้าในใบนัดหมาย - FR-4.4.9: ระบบต้องติดตามสถานะการตรวจและแจ้งเตือนเมื่อผลพร้อม - FR-4.3.25: ระบบต้องสามารถตรวจสอบรายชื่อผู้ป่วยที่ไม่มาตามนัดในแต่ละวันได้ - FR-4.3.26: ระบบต้องแสดงข้อมูลสถิติการนัดหมายในรูปแบบกราฟและตาราง

4.3.9 การจำกัดจำนวนผู้ป่วยต่อแพทย์

คำอธิบาย: ระบบสามารถควบคุมจำนวนผู้ป่วยที่นัดต่อแพทย์

ข้อกำหนด: - FR-4.3.27: ระบบต้องสามารถจำกัดจำนวนผู้ป่วยต่อแพทย์ในการนัดแต่ละครั้งได้ - FR-4.3.28: ระบบต้องแสดงเตือนเมื่อจำนวนการนัดใกล้เต็มโควต้า - FR-4.3.29: ระบบต้องสามารถสำรองโควต้าสำหรับกรณีฉุกเฉินได้

4.4 การส่งตรวจผู้ป่วยล่วงหน้า

4.4.1 การส่งตรวจผู้ป่วยล่วงหน้า (ออก Visit ล่วงหน้า)

คำอธิบาย: ระบบสามารถส่งผู้ป่วยไปยังจุดต่างๆ ตามที่นัดไว้

ข้อกำหนด: - FR-4.4.1: ระบบต้องสามารถส่งตรวจผู้ป่วยล่วงหน้า (ออก Visit ล่วงหน้า) ตามวันที่นัดมาไปยังจุดต่างๆ ที่นัดได้ - FR-4.4.2: ระบบต้องสร้าง Visit Number สำหรับการมารับบริการในวันที่นัด - FR-4.4.3: ระบบต้องเชื่อมโยงข้อมูลการ Pre-visit กับระบบคิว - FR-4.4.4: ระบบต้องแจ้งข้อมูลการ Pre-visit ไปยังหน่วยงานที่เกี่ยวข้อง

4.4.2 การส่งตรวจ Lab/X-Ray ล่วงหน้า

คำอธิบาย: ระบบสามารถยืนยันการสั่งตรวจที่กำหนดไว้ล่วงหน้า

ข้อกำหนด: - FR-4.4.5: ระบบต้องสามารถส่งตรวจ Lab/X-Ray ล่วงหน้า (ยืนยันการสั่ง) ตามที่นัดหมายไว้ได้ - FR-4.4.6: ระบบต้องเชื่อมโยงกับระบบงานชันสูตร (1.2.7) สำหรับการสั่ง Lab - FR-4.4.7: ระบบต้องเชื่อมโยงกับระบบรังสีวิทยา (1.2.8) สำหรับการสั่ง X-Ray - FR-4.4.8: ระบบต้องติดตามสถานะการตรวจและแจ้งผลเมื่อพร้อม

5. ความต้องการที่ไม่ใช่ฟังก์ชัน

5.1 ความต้องการด้านประสิทธิภาพ (Performance Requirements)

  • PR-5.1.1: ระบบต้องสามารถตอบสนองการค้นหาข้อมูลการนัดหมายภายใน 2 วินาที
  • PR-5.1.2: ระบบต้องรองรับผู้ใช้งานพร้อมกันได้อย่างน้อย 50 คน
  • PR-5.1.3: ระบบต้องมีความพร้อมใช้งาน (Availability) อย่างน้อย 99.5% ต่อเดือน
  • PR-5.1.4: การบันทึกข้อมูลการนัดหมายต้องเสร็จสมบูรณ์ภายใน 3 วินาที
  • PR-5.1.5: ระบบต้องสามารถแสดงตารางการนัดหมายแบบปฏิทินภายใน 5 วินาที

5.2 ความต้องการด้านความปลอดภัย (Security Requirements)

  • SR-5.2.1: ระบบต้องมีการยืนยันตัวตน (Authentication) ก่อนเข้าใช้งาน
  • SR-5.2.2: ระบบต้องมีการควบคุมสิทธิ์การเข้าถึงข้อมูล (Authorization) ตามบทบาทผู้ใช้
  • SR-5.2.3: ระบบต้องเข้ารหัสข้อมูลส่วนบุคคลของผู้ป่วย
  • SR-5.2.4: ระบบต้องบันทึก Audit Log ทุกการเข้าถึงและแก้ไขข้อมูลการนัดหมาย
  • SR-5.2.5: ระบบต้องป้องกันการเข้าถึงข้อมูลการนัดหมายโดยไม่ได้รับอนุญาต

5.3 ความต้องการด้านการใช้งาน (Usability Requirements)

  • UR-5.3.1: ระบบต้องมี User Interface ที่ใช้งานง่าย สำหรับผู้ใช้ที่มีทักษะคอมพิวเตอร์ปานกลาง
  • UR-5.3.2: ระบบต้องมีระบบ Auto-complete สำหรับการค้นหาชื่อแพทย์และชื่อผู้ป่วย
  • UR-5.3.3: ระบบต้องแสดงข้อความเตือนอย่างชัดเจนเมื่อมีข้อผิดพลาดหรือข้อมูลไม่ครบถ้วน
  • UR-5.3.4: ระบบต้องรองรับภาษาไทยและภาษาอังกฤษ
  • UR-5.3.5: ระบบต้องมี Calendar Interface ที่ใช้งานง่ายสำหรับการดูและจัดการนัดหมาย

5.4 ความต้องการด้านความน่าเชื่อถือ (Reliability Requirements)

  • RR-5.4.1: ระบบต้องมีระบบ Backup ข้อมูลอัตโนมัติทุก 24 ชั่วโมง
  • RR-5.4.2: ระบบต้องสามารถ Recovery ได้ภายใน 4 ชั่วโมงหากเกิดขัดข้อง
  • RR-5.4.3: ข้อมูลการนัดหมายที่บันทึกแล้วต้องไม่สูญหายใต้สถานการณ์ปกติ
  • RR-5.4.4: ระบบต้องมีกลไก Failover สำหรับการทำงานต่อเนื่อง

5.5 ความต้องการด้านการบำรุงรักษา (Maintainability Requirements)

  • MR-5.5.1: ระบบต้องมีโครงสร้างที่สามารถแก้ไขและปรับปรุงได้ง่าย
  • MR-5.5.2: ระบบต้องมีเอกสารการติดตั้งและการใช้งานที่ครบถ้วน
  • MR-5.5.3: ระบบต้องสามารถอัพเดทได้โดยไม่หยุดการทำงาน (Hot Deploy)
  • MR-5.5.4: ระบบต้องมี Monitoring และ Alerting สำหรับการติดตามสถานะระบบ

5.6 ความต้องการด้านความสามารถในการขยาย (Scalability Requirements)

  • SC-5.6.1: ระบบต้องรองรับการเพิ่มจำนวนผู้ใช้งานได้โดยไม่กระทบต่อประสิทธิภาพ
  • SC-5.6.2: ระบบต้องสามารถรองรับข้อมูลการนัดหมายได้อย่างน้อย 1 ล้านรายการต่อปี
  • SC-5.6.3: ระบบต้องสามารถเพิ่มแพทย์และคลินิกใหม่ได้โดยง่าย

6. การเชื่อมโยงกับระบบอื่น

6.1 ภาพรวมการเชื่อมโยง

ระบบนัดหมายและตารางเวรแพทย์ทำหน้าที่เป็น Scheduling Hub ที่เชื่อมโยงกับระบบต่างๆ ในโรงพยาบาลดังนี้:

graph TD
    A["ระบบนัดหมายและตารางเวรแพทย์<br/>(Appointment & Doctor Schedule)<br/>1.2.6"] --> B["ระบบเวชระเบียน<br/>1.2.1"]
    A --> C["ระบบซักประวัติ<br/>1.2.2"]
    A --> D["ระบบห้องตรวจแพทย์<br/>1.2.3"]
    A --> E["ระบบงานชันสูตร<br/>1.2.7"]
    A --> F["ระบบรังสีวิทยา<br/>1.2.8"]
    A --> G["ระบบจัดการคิว<br/>Queue Management"]
    A --> H["ระบบผู้ดูแลระบบ<br/>1.2.21"]
    A --> I["ระบบแจ้งเตือน<br/>Notification System"]

    B -->|ข้อมูลผู้ป่วย| A
    C -->|การนัดติดตาม| A
    D -->|การนัดติดตาม| A
    E -->|ผลการตรวจ Lab| A
    F -->|ผลการตรวจ X-Ray| A
    G -->|สถานะคิว| A
    H -->|ข้อมูลแพทย์และคลินิก| A
    I -->|การแจ้งเตือนนัด| A

    style A fill:#e8f5e8,stroke:#2e7d32,stroke-width:3px
    style B fill:#fff3e0,stroke:#f57c00,stroke-width:2px
    style C fill:#fff3e0,stroke:#f57c00,stroke-width:2px
    style D fill:#fff3e0,stroke:#f57c00,stroke-width:2px
    style E fill:#f3e5f5,stroke:#7b1fa2,stroke-width:2px
    style F fill:#f3e5f5,stroke:#7b1fa2,stroke-width:2px
    style G fill:#e0f2f1,stroke:#2e7d32,stroke-width:2px
    style H fill:#e3f2fd,stroke:#1976d2,stroke-width:2px
    style I fill:#fce4ec,stroke:#c2185b,stroke-width:2px

6.2 รายละเอียดการเชื่อมโยง

6.2.1 ระบบเวชระเบียน (1.2.1)

วิธีการเชื่อมต่อ: RESTful API

// API Endpoints
GET /api/v1/patient/{hn}/basic-info
GET /api/v1/patient/search?keyword=xxx
POST /api/v1/appointment/create
PUT /api/v1/appointment/{appointmentId}/update
DELETE /api/v1/appointment/{appointmentId}/cancel

ข้อมูลที่แลกเปลี่ยน: - รับ: ข้อมูลผู้ป่วย (HN, ชื่อ-สกุล, เลขบัตรประชาชน, ข้อมูลติดต่อ) - ส่ง: ข้อมูลการนัดหมาย, สถานะการมาตามนัด, ประวัติการนัดหมาย

6.2.2 ระบบซักประวัติ (1.2.2) และระบบห้องตรวจแพทย์ (1.2.3)

วิธีการเชื่อมต่อ: API Integration + Modal Integration

// การนัดติดตามจากระบบซักประวัติและห้องตรวจ
POST /api/v1/appointment/follow-up/create
GET /api/v1/appointment/follow-up/templates

// เรียกใช้ Modal การนัดหมาย
window.openAppointmentModal(patientHN, callbackFunction);

// รับข้อมูลการนัดที่สร้าง
function callbackFunction(appointmentData) {
  // ใช้ข้อมูลการนัดในระบบหลัก
}

ข้อมูลที่แลกเปลี่ยน: - รับ: คำขอนัดติดตาม, ข้อมูลผู้ป่วยที่ต้องนัด, สาเหตุการนัด - ส่ง: ข้อมูลการนัดที่สร้าง, วันที่และเวลานัด, การเตรียมตัว

6.2.3 ระบบงานชันสูตร (1.2.7) และระบบรังสีวิทยา (1.2.8)

วิธีการเชื่อมต่อ: Bidirectional API Integration

// ส่งคำสั่งตรวจล่วงหน้า
POST /api/v1/lab/pre-order/create
POST /api/v1/radiology/pre-order/create

// รับผลการตรวจ
GET /api/v1/lab/results/{hn}?appointmentDate=xxx
GET /api/v1/radiology/results/{hn}?appointmentDate=xxx

// แจ้งเตือนผลพร้อม
POST /api/v1/appointment/results-ready-notification

ข้อมูลที่แลกเปลี่ยน: - ส่ง: คำสั่งตรวจ Lab/X-Ray ล่วงหน้า, ข้อมูลผู้ป่วยและการนัด - รับ: ผลการตรวจ, สถานะการตรวจ, การแจ้งเตือนผลพร้อม

6.2.4 ระบบจัดการคิว (Queue Management System)

วิธีการเชื่อมต่อ: Real-time API Integration

// สร้างคิวสำหรับผู้ป่วยที่มาตามนัด
POST /api/v1/queue/appointment/check-in
GET /api/v1/queue/status/{appointmentId}

// อัพเดทสถานะการมาตามนัด
PUT /api/v1/appointment/{appointmentId}/attendance-status

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

6.2.5 ระบบผู้ดูแลระบบ (1.2.21)

วิธีการเชื่อมต่อ: Administrative API Integration

// จัดการข้อมูล Master Data
GET /api/v1/admin/doctors/list
GET /api/v1/admin/clinics/list
GET /api/v1/admin/holidays/list
POST /api/v1/admin/doctor-schedule/set
PUT /api/v1/admin/appointment-quota/update

ข้อมูลที่แลกเปลี่ยน: - รับ: ข้อมูลแพทย์, ข้อมูลคลินิก, วันหยุด, ตารางเวรแพทย์ - ส่ง: การใช้งานโควต้า, สถิติการนัดหมาย, รายงานการใช้งาน

6.2.6 ระบบแจ้งเตือน (Notification System)

วิธีการเชื่อมต่อ: Event-driven API Integration

// ส่งการแจ้งเตือนการนัดหมาย
POST /api/v1/notification/appointment-reminder/send
POST /api/v1/notification/appointment-confirmation/send
POST /api/v1/notification/appointment-cancellation/send

// กำหนดการแจ้งเตือนอัตโนมัติ
POST /api/v1/notification/schedule/auto-reminder

ข้อมูลที่แลกเปลี่ยน: - ส่ง: ข้อมูลการนัดหมาย, ข้อมูลผู้ป่วย, เวลาที่ต้องการแจ้งเตือน - รับ: สถานะการส่งการแจ้งเตือน, ผลการติดต่อผู้ป่วย

6.3 การจัดการข้อผิดพลาดและการเชื่อมต่อ

6.3.1 Error Handling Strategy

// จัดการข้อผิดพลาดการเชื่อมต่อ
const APIErrorHandler = {
  // Network Timeout
  networkTimeout: () => {
    // ใช้ข้อมูล Cache หรือแสดงข้อความเตือน
  },

  // Service Unavailable
  serviceUnavailable: () => {
    // ใช้ Offline Mode หรือเลื่อนการดำเนินการ
  },

  // Data Validation Error
  validationError: (error) => {
    // แสดงข้อความและแนะนำการแก้ไข
  }
};

6.3.2 Data Synchronization

// การซิงค์ข้อมูลแบบ Real-time
const DataSync = {
  // อัพเดทข้อมูลการนัดเมื่อมีการเปลี่ยนแปลง
  syncAppointmentData: () => {
    // ส่งข้อมูลไปยังระบบที่เกี่ยวข้องทั้งหมด
  },

  // ตรวจสอบความสอดคล้องของข้อมูล
  validateDataConsistency: () => {
    // ตรวจสอบข้อมูลระหว่างระบบ
  }
};

6.4 Security และ Data Protection

6.4.1 API Security

  • ใช้ OAuth 2.0 สำหรับการยืนยันตัวตน
  • เข้ารหัสข้อมูลด้วย TLS 1.3 ในการส่งข้อมูล
  • จำกัด Rate Limiting สำหรับ API Calls
  • บันทึก API Access Log เพื่อการตรวจสอบ

6.4.2 Data Privacy (PDPA Compliance)

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

6.5 Performance Optimization

6.5.1 Caching Strategy

  • Cache ข้อมูลแพทย์และคลินิกที่ไม่ค่อยเปลี่ยน
  • Cache ข้อมูลการนัดหมายของวันปัจจุบัน
  • ใช้ Redis สำหรับ Session Management

6.5.2 Database Optimization

  • สร้าง Index สำหรับการค้นหาข้อมูลการนัดหมาย
  • Partition ข้อมูลตามช่วงวันที่
  • ใช้ Connection Pooling สำหรับฐานข้อมูล

7. บทสรุป

ระบบนัดหมายและตารางเวรแพทย์เป็นระบบสำคัญที่เชื่อมโยงกับระบบต่างๆ ในโรงพยาบาล โดยครอบคลุมความต้องการตาม TOR ทั้งหมด ได้แก่:

✅ ความครอบคลุม TOR 100%

  1. การจัดการข้อมูลพื้นฐาน - โควต้าแพทย์ วันหยุด การเตรียมตัว ✓
  2. การตรวจสอบข้อมูลการนัดหมาย - แสดงรายการ ติดตามผล รูปแบบปฏิทิน ✓
  3. การลงทะเบียนนัดหมาย - บันทึก แก้ไข ยกเลิก เลื่อน พิมพ์ใบนัด ✓
  4. การส่งตรวจผู้ป่วยล่วงหน้า - ออก Visit และสั่งตรวจล่วงหน้า ✓

🔗 การเชื่อมโยงระบบ

  • เชื่อมโยงกับระบบหลัก 8 ระบบ
  • รองรับการทำงานแบบ Real-time
  • มีกลไก Error Handling และ Fallback

🛡️ ความปลอดภัยและประสิทธิภาพ

  • ปฏิบัติตาม PDPA
  • รองรับผู้ใช้งานพร้อมกัน 50+ คน
  • มีระบบ Backup และ Recovery

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