Software Requirements Specification (SRS)

ระบบซักประวัติ (Medical History and Examination System)

เวอร์ชัน: 1.0

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

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

---

สารบัญ

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

---

1. บทนำ

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

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

1.2 ขอบเขต (Scope)

ระบบซักประวัติจะดำเนินการ: - ✅ การบันทึกข้อมูลพื้นฐานและการเชื่อมโยงรหัส ICD - ✅ การบันทึกข้อมูลการตรวจรักษาและประวัติผู้ป่วย - ✅ การจัดการนัดหมายและการติดตาม - ✅ การขอปรึกษาแพทย์ (Consult) - ✅ การพิมพ์เอกสารทางการแพทย์ - ✅ การจัดการข้อมูลการแพ้ยาและ Drug Interaction - ✅ การสั่งจ่ายยาและการส่งตรวจ Lab/X-Ray

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

คำศัพท์	คำอธิบาย
ICD	International Classification of Diseases - รหัสการจำแนกโรคระหว่างประเทศ
WHO	World Health Organization - องค์การอนามัยโลก
CC	Chief Complaint - อาการสำคัญที่ผู้ป่วยมาร้องเรียน
HPI	History of Present Illness - ประวัติการเจ็บป่วยในปัจจุบัน
PMH	Past Medical History - ประวัติการเจ็บป่วยในอดีต
FH	Family History - ประวัติการเจ็บป่วยในครอบครัว
SH	Social History - ประวัติเกี่ยวกับการดำเนินชีวิต
BP	Blood Pressure - ความดันโลหิต
BMI	Body Mass Index - ดัชนีมวลกาย
Lab	Laboratory - การตรวจทางห้องปฏิบัติการ
X-Ray	Radiographic Examination - การตรวจทางรังสี
RE-MED	Re-medication - การสั่งยาซ้ำ
Consult	Consultation - การปรึกษาผู้เชี่ยวชาญ
Refer	Referral - การส่งต่อผู้ป่วย
OPD CARD	Out-Patient Department Card - บัตรผู้ป่วยนอก

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

• TOR ระบบซักประวัติ โรงพยาบาลค่ายธนรัชน์
• มาตรฐาน ICD-10 และ ICD-11 ขององค์การอนามัยโลก
• มาตรฐานการเก็บข้อมูลทางการแพทย์ของกระทรวงสาธารณสุข

---

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

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

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

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

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

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

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

• แพทย์ - ผู้ใช้หลักที่บันทึกการวินิจฉัยและสั่งการรักษา
• พยาบาล - ผู้ช่วยบันทึกข้อมูลเบื้องต้นและดำเนินการตามที่แพทย์สั่ง
• เจ้าหน้าที่เภสัช - ตรวจสอบการสั่งจ่ายยาและ Drug Interaction
• ผู้ดูแลระบบ - จัดการ Master Data และการกำหนดค่าระบบ

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

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

---

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

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

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

• ระบบต้องมี Web-based Interface ที่ใช้งานง่าย
• รองรับการใช้งานบนอุปกรณ์ต่างๆ (Desktop, Tablet)
• มีระบบ Search และ Auto-complete สำหรับการค้นหาข้อมูล

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

• รองรับเครื่องพิมพ์สำหรับพิมพ์เอกสารทางการแพทย์
• เชื่อมต่อกับเครื่องวัดสัญญาณชีพ (Vital Signs Monitor)

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

• เชื่อมโยงกับระบบเวชระเบียน (1.2.1)
• เชื่อมโยงกับระบบตรวจสอบสิทธิ (1.2.15)
• เชื่อมโยงกับระบบเภสัชกรรม (1.2.13)
• เชื่อมโยงกับระบบ Lab และ X-Ray

---

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

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

4.1.1 รหัส ICD และการเชื่อมโยง

คำอธิบาย: ระบบสามารถจัดการรหัสโรคและหัตถการตามมาตรฐาน ICD

ข้อกำหนด: - FR-4.1.1: ระบบต้องสามารถเชื่อมโยงข้อมูลการรักษากับรหัสหัตถการโดยใช้รหัส ICD ของ WHO - FR-4.1.2: ระบบต้องสามารถบันทึกรหัสโรคและชื่อโรคโดยใช้รหัส ICD ของ WHO และของประเทศไทย - FR-4.1.3: ระบบต้องมีระบบช่วยกำหนดรหัสโรคที่วินิจฉัยบ่อยหรือบันทึกแบบข้อความทั่วไป - FR-4.1.4: ระบบต้องมี ICD Code Map สำหรับการแปลงรหัสโรค

4.1.2 การกำหนดค่ารักษาพยาบาล

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

ข้อกำหนด: - FR-4.1.5: ระบบต้องสามารถกำหนดข้อมูลการรักษาตามกลุ่มค่ารักษาพยาบาลพร้อมค่าบริการ

4.2 การตรวจรักษา

4.2.1 การบันทึกข้อมูล Screen และ Chief Complaint

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

ข้อกำหนด: - FR-4.2.1: ระบบต้องสามารถบันทึกข้อมูลสัญญาณชีพ ได้แก่: - น้ำหนัก, ส่วนสูง, อุณหภูมิ, รอบเอว - อัตราเต้นชีพจร, อัตราหายใจ, ความดันโลหิต - BMI (คำนวณให้อัตโนมัติ) - FR-4.2.2: ระบบต้องสามารถบันทึกข้อมูลประวัติการเจ็บป่วย ได้แก่: - Chief complaint (CC) - อาการสำคัญ - History of present illness (HPI) - ประวัติการเจ็บป่วยในปัจจุบัน - Past medical history (PMH) - ประวัติการเจ็บป่วยในอดีต - Family history (FH) - ประวัติการเจ็บป่วยในครอบครัว - Social history (SH) - ประวัติเกี่ยวกับการดำเนินชีวิต - FR-4.2.3: ระบบต้องสามารถระบุได้ว่าผู้ป่วยเป็นหญิงตั้งครรภ์หรือกำลังให้นมบุตร

4.2.2 การใช้ข้อมูลเดิม

คำอธิบาย: ระบบสามารถนำข้อมูลเดิมมาใช้เพื่อความสะดวก

ข้อกำหนด: - FR-4.2.4: ระบบต้องสามารถนำข้อมูลเดิมของการ Screen ครั้งล่าสุดมาใช้ได้

4.2.3 การเรียกดูประวัติ

คำอธิบาย: ระบบสามารถแสดงประวัติการรักษาที่ผ่านมา

ข้อกำหนด: - FR-4.2.5: ระบบต้องสามารถเรียกดูข้อมูลประวัติการตรวจย้อนหลัง ได้แก่: - ประวัติการมารับบริการ - การวินิจฉัย - การสั่งจ่ายยา - การสั่ง Lab/X-Ray - การตรวจร่างกาย - การนัดหมาย - การ Admit

4.2.4 การจัดการข้อมูลการแพ้ยา

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

ข้อกำหนด: - FR-4.2.6: ระบบต้องสามารถบันทึกข้อมูลการแพ้ยาของผู้ป่วย โดยระบุข้อมูล: - ชื่อยาที่แพ้ (ชื่อสามัญ) - วันที่รายงาน, วันที่มีอาการ - อาการที่แพ้, ผู้รายงาน - ความร้ายแรง, สาเหตุการเกิด - ระดับความสัมพันธ์, ผลที่เกิดขึ้นภายหลัง - หมายเหตุ (เพิ่มเติม) - ระบุห้ามสั่งใช้กับผู้ป่วย - Naranjo result (ผลการประเมินระดับการแพ้ยา)

4.2.5 การสั่งจ่ายยา

คำอธิบาย: ระบบสามารถจัดการการสั่งจ่ายยาและเวชภัณฑ์

ข้อกำหนด: - FR-4.2.7: ระบบต้องสามารถบันทึกสั่งจ่ายยาและเวชภัณฑ์ด้วยการ RE-MED หรือกำหนด template การใช้ยา หรือสั่งใหม่ - FR-4.2.8: ระบบต้องสามารถตรวจสอบรายการยาที่สั่งจ่าย และเตือนในกรณีที่ผู้ป่วยแพ้ยา - FR-4.2.9: ระบบต้องสามารถตรวจสอบรายการยาที่เกิดอันตกริยาต่อกันของยาในใบสั่งยาเดียวกัน (Drug Interaction)

4.2.6 การวินิจฉัยโรค

คำอธิบาย: ระบบสามารถบันทึกการวินิจฉัยโรคและหัตถการ

ข้อกำหนด: - FR-4.2.10: ระบบต้องสามารถบันทึกรหัสโรคและชื่อโรคโดยใช้รหัส ICD ของ WHO และของประเทศไทย - FR-4.2.11: ระบบต้องมี ICD Code Map และระบบช่วยกำหนดรหัสโรคที่วินิจฉัยบ่อย - FR-4.2.12: ระบบต้องสามารถบันทึกรหัสหัตถการและชื่อหัตถการโดยใช้รหัส ICD โดยสามารถระบุ: - ชื่อแพทย์หรือเจ้าหน้าที่ผู้ทำ - เวลาเริ่มและเวลาสิ้นสุด

4.2.7 การสั่งตรวจทางห้องปฏิบัติการ

คำอธิบาย: ระบบสามารถจัดการการสั่ง Lab

ข้อกำหนด: - FR-4.2.13: ระบบต้องสามารถบันทึกข้อมูลสั่ง Lab โดยระบุข้อมูล: - แพทย์ผู้สั่ง - ห้อง Lab (กรณีมีหลายห้อง) - ระบุห้องที่ต้องการให้เตือนผล Lab กลับมา - ความเร่งด่วน - รายการส่งตรวจ - FR-4.2.14: ระบบต้องสามารถดูประวัติการทำ Lab และผล Lab

4.2.8 การส่งต่อผู้ป่วย

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

ข้อกำหนด: - FR-4.2.15: ระบบต้องสามารถบันทึกข้อมูลการ Refer โดยระบุข้อมูล: - สถานพยาบาลที่ส่งต่อ, เหตุผลการส่งตัว - การวินิจฉัยขั้นต้น, การวินิจฉัยหลัก - แพทย์ผู้สั่ง, จุดส่งต่อ, แผนก, สาเหตุ - การรักษาที่ให้ไว้ - พยาบาล refer หรือรถ Ambulance - ประเภทการส่งต่อ - วันที่สิ้นสุดการส่งต่อ - FR-4.2.16: ห้องตรวจสอบสิทธิสามารถตรวจสอบการ Refer ได้

4.2.9 การตรวจพิเศษ

คำอธิบาย: ระบบสามารถจัดการการตรวจพิเศษต่างๆ

ข้อกำหนด: - FR-4.2.17: ระบบต้องสามารถบันทึกข้อมูลการนั่งพักวัด BP ซ้ำได้

4.2.10 การให้คำแนะนำผู้ป่วย

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

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

4.2.11 การสั่งตรวจรังสี

คำอธิบาย: ระบบสามารถจัดการการสั่ง X-Ray

ข้อกำหนด: - FR-4.2.19: ระบบต้องสามารถบันทึกข้อมูลการสั่ง X-Ray โดยระบุข้อมูล: - รายการส่งตรวจ, ท่า, ด้าน - ห้องตรวจ (กรณีมีหลายห้อง) - สภาพผู้ป่วย, ความเร่งด่วน - Clinical Information (ข้อมูลทางคลินิก) - Clinical Diagnosis (การวินิจฉัยทางคลินิก) - หมายเหตุ - FR-4.2.20: ระบบต้องสามารถแสดงประวัติการทำ X-Ray และการอ่านผล

4.3 การจัดการนัดหมาย

4.3.1 การบันทึกนัดหมาย

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

ข้อกำหนด: - FR-4.3.1: ระบบต้องสามารถบันทึกนัดหมายโดยระบุวันที่นัดหมาย หรือระบุเป็นสัปดาห์ หรือระบุเป็นเดือน - FR-4.3.2: ระบบต้องสามารถทำการนัดได้หลายๆ แผนกในการมา visit 1 ครั้ง - FR-4.3.3: ระบบต้องมีระบบเตือนเมื่อทำการนัดหมายตรงกับวันหยุดต่างๆ ตามที่กำหนดไว้

4.3.2 การสั่งล่วงหน้า

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

ข้อกำหนด: - FR-4.3.4: ระบบต้องสามารถบันทึกข้อมูลการสั่ง Lab และ X-Ray ล่วงหน้า

4.3.3 การระบุสาเหตุการนัด

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

ข้อกำหนด: - FR-4.3.5: ระบบต้องสามารถระบุสาเหตุการนัดหมายพร้อมทั้งแจ้งการปฏิบัติตัวในการมารับการรักษาครั้งต่อไป

4.3.4 การนัดหมายแบบ Template

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

ข้อกำหนด: - FR-4.3.6: ระบบต้องสามารถนัดหมายล่วงหน้าได้หลายครั้ง (template) เช่น ใช้ในกรณีนัดรับยา หรือนัดฉีดยา

4.4 การขอปรึกษา (Consult)

4.4.1 การส่งปรึกษา

คำอธิบาย: ระบบสามารถจัดการการส่งปรึกษาแพทย์เฉพาะทาง

ข้อกำหนด: - FR-4.4.1: ระบบต้องสามารถระบุชื่อแพทย์/ทันตแพทย์ หรือแผนกที่ต้องการส่งปรึกษาผู้ป่วย (Consult) พร้อมทั้งระบุความเร่งด่วน

4.4.2 การบันทึกการปรึกษา

คำอธิบาย: ระบบสามารถบันทึกรายละเอียดการปรึกษา

ข้อกำหนด: - FR-4.4.2: ระบบต้องสามารถบันทึกข้อมูลการ Consult โดยมีช่องสำหรับการบันทึกคำถาม และคำตอบสำหรับการ Consult

4.5 การพิมพ์เอกสาร

4.5.1 ใบรับรองแพทย์

คำอธิบาย: ระบบสามารถพิมพ์ใบรับรองแพทย์ประเภทต่างๆ

ข้อกำหนด: - FR-4.5.1: ระบบต้องสามารถพิมพ์ใบรับรองแพทย์แบบต่างๆ ได้ เช่น: - ใบรับรองแพทย์สมัครงานในรูปแบบภาษาไทยและภาษาอังกฤษ - ใบรับรองแพทย์ลาป่วยในรูปแบบภาษาไทยและภาษาอังกฤษ

4.5.2 เอกสารการรักษา

คำอธิบาย: ระบบสามารถพิมพ์เอกสารเกี่ยวกับการรักษา

ข้อกำหนด: - FR-4.5.2: ระบบต้องสามารถพิมพ์ตรวจรักษา (OPD CARD) - FR-4.5.3: ระบบต้องสามารถพิมพ์ใบสั่งยา

4.5.3 เอกสารการส่งต่อ

คำอธิบาย: ระบบสามารถพิมพ์เอกสารการส่งต่อและรับกลับ

ข้อกำหนด: - FR-4.5.4: ระบบต้องสามารถพิมพ์ใบส่งต่อรักษาสถานพยาบาลอื่นๆ (ส่ง Refer) - FR-4.5.5: ระบบต้องสามารถพิมพ์ใบตอบกลับการรักษาสถานพยาบาลอื่น (ตอบกลับ Refer)

4.5.4 ใบนัดหมาย

คำอธิบาย: ระบบสามารถพิมพ์ใบนัดหมาย

ข้อกำหนด: - FR-4.5.6: ระบบต้องสามารถพิมพ์ใบนัดหมายในรูปแบบภาษาไทยและภาษาอังกฤษ

---

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: การบันทึกข้อมูลต้องเสร็จสมบูรณ์ภายใน 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 ทุกการเข้าถึงและแก้ไขข้อมูล

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

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

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

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

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

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

---

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

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

ระบบซักประวัติจะทำหน้าที่เป็น Core Clinical System ที่เชื่อมโยงกับระบบอื่นๆ ผ่าน RESTful API และ Modal Integration

graph TD
    A["ระบบซักประวัติ<br/>(Medical History System)<br/>1.2.2"] --> B["ระบบเวชระเบียน<br/>1.2.1"]
    A --> C["ระบบตรวจสอบสิทธิ<br/>1.2.15"]
    A --> D["ระบบเภสัชกรรม<br/>1.2.13"]
    A --> E["ระบบ Lab และ X-Ray"]
    A --> F["ระบบห้องตรวจแพทย์<br/>1.2.3"]
    A --> G["ระบบการเงิน<br/>1.2.14"]

    style A fill:#e1f5fe,stroke:#01579b,stroke-width:3px
    style B fill:#f3e5f5,stroke:#4a148c,stroke-width:2px
    style C fill:#fff3e0,stroke:#e65100,stroke-width:2px
    style D fill:#e8f5e8,stroke:#1b5e20,stroke-width:2px
    style E fill:#fce4ec,stroke:#880e4f,stroke-width:2px
    style F fill:#f1f8e9,stroke:#33691e,stroke-width:2px
    style G fill:#e0f2f1,stroke:#2e7d32,stroke-width:2px

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

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

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

// API Endpoints
GET /api/v1/patient/{hn}/basic-info
POST /api/v1/patient/visit/diagnosis
PUT /api/v1/patient/{hn}/medical-history

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

6.2.2 ระบบตรวจสอบสิทธิ (1.2.15)

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

// Modal Integration API
window.openRightsModal(patientHN, callbackFunction);

// Callback Function
function handleRightsSelection(selectedRights) {
  // ใช้ข้อมูลสิทธิในการรักษา
}

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

6.2.3 ระบบเภสัชกรรม (1.2.13)

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

// API Endpoints
POST /api/v1/pharmacy/prescription/create
GET /api/v1/pharmacy/drug-interaction/check
POST /api/v1/pharmacy/allergy/validate

ข้อมูลที่แลกเปลี่ยน: - ส่ง: ข้อมูลการสั่งจ่ายยา, รายการยาที่สั่ง - รับ: ข้อมูลการแพ้ยา, Drug Interaction Warning

6.2.4 ระบบ Lab และ X-Ray

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

// API Endpoints
POST /api/v1/lab/order/create
GET /api/v1/lab/result/{orderNo}
POST /api/v1/xray/order/create
GET /api/v1/xray/result/{orderNo}

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

6.2.5 ระบบห้องตรวจแพทย์ (1.2.3)

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

// API Endpoints
POST /api/v1/examroom/appointment/create
GET /api/v1/examroom/queue/status
PUT /api/v1/examroom/patient/transfer

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

6.2.6 ระบบการเงิน (1.2.14)

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

// API Endpoints
POST /api/v1/finance/billing/calculate
GET /api/v1/finance/payment/status

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

6.3 การจัดการข้อผิดพลาดและ Fallback

6.3.1 Error Handling Strategy

{
  "rights_system_down": {
    "action": "ใช้สิทธิ default หรือ manual verification",
    "fallback": "ระบบจะจำข้อมูลไว้ sync ภายหลัง"
  },
  "pharmacy_system_down": {
    "action": "บันทึกการสั่งยาไว้ก่อน",
    "fallback": "ตรวจสอบ Drug Interaction manual"
  },
  "lab_system_down": {
    "action": "บันทึกคำสั่งตรวจไว้",
    "fallback": "ส่งคำสั่งเมื่อระบบกลับมาทำงาน"
  }
}

6.3.2 Data Synchronization

• Real-time Sync: ข้อมูลสำคัญ (การสั่งยา, การตรวจ)
• Batch Sync: ข้อมูลรายงาน (ทุกคืนเวลา 02:00)
• Manual Sync: กรณีระบบขัดข้อง

6.4 Security และ Authentication

6.4.1 API Security

• JWT Tokens สำหรับ authentication ระหว่างระบบ
• TLS 1.3 สำหรับการเข้ารหัสข้อมูล
• Rate Limiting ป้องกัน API abuse
• API Key Management สำหรับแต่ละระบบ

6.4.2 Data Privacy

• Field-level Encryption สำหรับข้อมูลการแพ้ยา
• Audit Logging ทุกการส่งข้อมูลระหว่างระบบ
• PDPA Compliance การป้องกันข้อมูลส่วนบุคคล

---

7. ข้อจำกัดการออกแบบ

7.1 ข้อจำกัดด้านเทคโนโลยี

• ระบบต้องทำงานบน Web Browser สมัยใหม่
• ฐานข้อมูลต้องรองรับ ACID Properties
• ระบบต้องใช้ API แบบ RESTful สำหรับการเชื่อมโยง

7.2 ข้อจำกัดด้านกฎหมายและมาตรฐาน

• ต้องปฏิบัติตามพระราชบัญญัติข้อมูลส่วนบุคคล (PDPA)
• ต้องใช้มาตรฐาน ICD-10/ICD-11 ของ WHO
• ต้องปฏิบัติตามมาตรฐานการรักษาความปลอดภัยข้อมูลของกระทรวงสาธารณสุข

7.3 ข้อจำกัดด้านฮาร์ดแวร์

• ระบบต้องทำงานบนเซิร์ฟเวอร์ที่มีอยู่ในโรงพยาบาล
• ต้องเชื่อมต่อกับเครื่องพิมพ์และอุปกรณ์ทางการแพทย์ที่มีอยู่

---

ภาคผนวก

ภาคผนวก A: อ้างอิงมาตรฐาน ICD

• ICD-10: International Classification of Diseases 10th Revision
• ICD-11: International Classification of Diseases 11th Revision
• รหัสโรคไทย: มาตรฐานของกระทรวงสาธารณสุข

ภาคผนวก B: ตัวอย่างฟอร์มการบันทึกข้อมูล

(จะเพิ่มเติมตามการออกแบบ UI)

ภาคผนวก C: การแมปข้อมูลกับระบบอื่น

(จะเพิ่มเติมตามการออกแบบ API)

---

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