Software Requirements Specification (SRS)

ระบบห้องตรวจแพทย์ (Examination Room System)

เวอร์ชัน: 1.0

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

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

---

สารบัญ

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

---

1. บทนำ

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

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

1.2 ขอบเขตของระบบ

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

✅ ฟังก์ชันหลักที่แตกต่างจากระบบซักประวัติ: - 🔍 การตรวจร่างกาย (Physical Examination) - ฟีเจอร์หลักที่ไม่มีในระบบซักประวัติ - 📊 การแสดงและเปรียบเทียบผล Lab/X-Ray - แสดงผลแบบเปรียบเทียบและการตีความ - 📸 การจัดการภาพและการวาดรูป - การถ่ายภาพผู้ป่วยและการวาดแผนภาพ - 🔄 การส่งต่อผู้ป่วยแบบหลายรูปแบบ - Refer, ส่งต่อแผนกอื่น, ส่งผ่าตัด - 📝 การจัดการ Note และการติดตาม - บันทึกและติดตามการรักษา - 💊 การตรวจสอบโรคพิเศษ - G-6-PD, การแพ้อาหาร

🔗 ฟังก์ชันที่ใช้ร่วมกับระบบซักประวัติ (1.2.2): - การบันทึกข้อมูล Vital Signs และ Chief Complaint - การจัดการการแพ้ยาและ Drug Interaction - การสั่งจ่ายยาและการสั่ง Lab/X-Ray พื้นฐาน - การวินิจฉัยโรคด้วยรหัส ICD - การนัดหมายและการ Consult - การพิมพ์เอกสารทางการแพทย์

🚫 ฟังก์ชันที่ไม่รวมในระบบนี้ (ให้ระบบอื่นดำเนินการ): - การลงทะเบียนผู้ป่วย → ระบบเวชระเบียน (1.2.1) - การซักประวัติเบื้องต้น → ระบบซักประวัติ (1.2.2) - การตรวจสอบสิทธิ → ระบบตรวจสอบสิทธิ (1.2.15) - การจ่ายยา → ระบบเภสัชกรรม (1.2.13) - การตรวจ Lab → ระบบงานชันสูตร (1.2.7) - การตรวจ X-Ray → ระบบรังสีวิทยา (1.2.8)

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

คำศัพท์	คำอธิบาย
PE	Physical Examination - การตรวจร่างกาย
GA	General Appearance - ลักษณะทั่วไป/ความรู้สึกตัว
HEENT	Head, Eyes, Ears, Nose, Throat - การตรวจศีรษะ ตา หู คอ จมูก
PV	Per Vagina - การตรวจภายใน
PR	Per Rectum - การตรวจทางทวารหนัก
G-6-PD	Glucose-6-Phosphate Dehydrogenase Deficiency - ภาวะขาดเอนไซม์ G-6-PD
Template	แม่แบบการตรวจหรือการรักษาที่กำหนดไว้ล่วงหน้า
Re-diag	การใช้การวินิจฉัยจากประวัติการรักษาเดิม

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

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

---

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

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

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

2.2 ความแตกต่างหลักจากระบบซักประวัติ

ด้าน	ระบบซักประวัติ (1.2.2)	ระบบห้องตรวจแพทย์ (1.2.3)
วัตถุประสงค์	ซักประวัติและการประเมินเบื้องต้น	การตรวจร่างกายและการรักษาแบบละเอียด
การตรวจร่างกาย	ไม่มี	✅ มีการตรวจร่างกายแบบครบถ้วน (PE)
การจัดการภาพ	ไม่มี	✅ การถ่ายภาพ การวาดรูป การจัดการไฟล์ภาพ
ผล Lab/X-Ray	แสดงผลพื้นฐาน	✅ แสดงผลแบบเปรียบเทียบและตีความ
การส่งต่อ	Refer พื้นฐาน	✅ หลายรูปแบบ (Refer/ส่งแผนก/ส่งผ่าตัด)
โรคพิเศษ	ไม่มี	✅ ตรวจสอบ G-6-PD, การแพ้อาหาร
การติดตาม	พื้นฐาน	✅ Note การรักษาและการติดตาม

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

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

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

• ระบบทำงานในห้องตรวจแพทย์ 24/7
• รองรับอุปกรณ์การแพทย์ (กล้อง, เครื่องวัดสัญญาณชีพ)
• เชื่อมต่อกับระบบอื่นๆ ผ่าน API Integration

---

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

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

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

• ระบบต้องมี Clinical Interface ที่ออกแบบเฉพาะสำหรับการตรวจรักษา
• รองรับการใช้งานบน Touch Screen และ Tablet สำหรับการตรวจข้างเตียง
• มีระบบ Drawing Tool สำหรับการวาดแผนภาพการตรวจ

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

• รองรับกล้องถ่ายภาพทางการแพทย์
• เชื่อมต่อกับ Digital Tablet สำหรับการวาดรูป
• รองรับเครื่องสแกนบาร์โค้ดสำหรับยาและอุปกรณ์การแพทย์

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

การเชื่อมโยงหลัก (ตาม Integration Analysis): - เชื่อมโยงกับระบบซักประวัติ (1.2.2) - รับข้อมูลประวัติและส่งต่อผลการตรวจ - เชื่อมโยงกับระบบตรวจสอบสิทธิ (1.2.15) - Modal Integration สำหรับตรวจสิทธิ์ - เชื่อมโยงกับระบบเภสัชกรรม (1.2.13) - ส่งใบสั่งยาและตรวจสอบ Drug Interaction - เชื่อมโยงกับระบบงานชันสูตร (1.2.7) - ส่งคำสั่ง Lab และรับผล - เชื่อมโยงกับระบบรังสีวิทยา (1.2.8) - ส่งคำสั่ง X-Ray และรับผล

---

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

4.1 การตรวจร่างกาย (Physical Examination) - ฟีเจอร์หลัก

4.1.1 การบันทึกการตรวจร่างกายแบบละเอียด

คำอธิบาย: ระบบสามารถบันทึกการตรวจร่างกายแบบครบถ้วนตามมาตรฐานทางการแพทย์

ข้อกำหนด: - FR-4.1.1: ระบบต้องสามารถบันทึกการตรวจร่างกายได้ครบถ้วน ประกอบด้วย: - GA (General Appearance) - ลักษณะทั่วไป/ความรู้สึกตัว - HEENT - การตรวจศีรษะ ตา หู คอ จมูก - Chest/Heart - การตรวจหัวใจและทรวงอก - Abdomen - การตรวจช่องท้อง - PV (Per Vagina) - การตรวจภายใน - PR (Per Rectum) - การตรวจทางทวารหนัก - Genitalia - การตรวจอวัยวะสืบพันธุ์ - Neurologica - การตรวจระบบประสาท - Extremities - การเคลื่อนไหวร่างกาย/การตรวจประเมินรยางค์ - PE Text - บันทึกการตรวจร่างกายแบบข้อความ

• FR-4.1.2: ระบบต้องมี Template การตรวจร่างกายสำหรับแต่ละแผนก/โรค
• FR-4.1.3: ระบบต้องสามารถบันทึกผลการตรวจเป็นข้อความ ตัวเลข และ Scale Rating
• FR-4.1.4: ระบบต้องสามารถระบุตำแหน่งที่ตรวจพบความผิดปกติบนแผนภาพ

4.1.2 การจัดการภาพและการวาดรูป

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

ข้อกำหนด: - FR-4.1.5: ระบบต้องสามารถถ่ายภาพผู้ป่วยและบันทึกลงในระบบได้ - FR-4.1.6: ระบบต้องมีเครื่องมือการวาดรูปสำหรับแสดงตำแหน่งพยาธิสภาพ - FR-4.1.7: ระบบต้องสามารถบันทึกและจัดการไฟล์ภาพในรูปแบบต่างๆ (JPEG, PNG, DICOM) - FR-4.1.8: ระบบต้องมีระบบจัดการความปลอดภัยของภาพตามมาตรฐาน PDPA

4.2 การแสดงและเปรียบเทียบผล Lab/X-Ray

4.2.1 การแสดงผล Lab/X-Ray ในปัจจุบัน

คำอธิบาย: ระบบสามารถแสดงผลการตรวจปัจจุบันแบบ Real-time

ข้อกำหนด: - FR-4.2.1: ระบบต้องสามารถแสดงผล Lab/X-Ray ในปัจจุบันที่ยังไม่ได้อ่านผล - FR-4.2.2: ระบบต้องแสดงสถานะการตรวจ (รอเก็บสิ่งส่งตรวจ/กำลังตรวจ/มีผลแล้ว) - FR-4.2.3: ระบบต้องมีการแจ้งเตือนเมื่อมีผลใหม่เข้ามา

4.2.2 การแสดงผล Lab แบบเปรียบเทียบ

คำอธิบาย: ระบบสามารถแสดงผล Lab แบบเปรียบเทียบเพื่อติดตามการรักษา

ข้อกำหนด: - FR-4.2.4: ระบบต้องสามารถแสดงผล Lab แบบตารางเปรียบเทียบย้อนหลัง - FR-4.2.5: ระบบต้องสามารถแสดงผล Lab แบบ Trend Graph - FR-4.2.6: ระบบต้องไฮไลท์ค่าที่ผิดปกติด้วยสีและเครื่องหมาย - FR-4.2.7: ระบบต้องสามารถเปรียบเทียบกับค่าปกติตามเพศและอายุ

4.2.3 การดูประวัติการทำ Lab/X-Ray ย้อนหลัง

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

ข้อกำหนด: - FR-4.2.8: ระบบต้องสามารถดูประวัติการทำ Lab/X-Ray ย้อนหลังได้อย่างน้อย 5 ปี - FR-4.2.9: ระบบต้องจัดกลุ่มผลการตรวจตามประเภทและวันที่ - FR-4.2.10: ระบบต้องสามารถค้นหาผลการตรวจด้วยช่วงวันที่และประเภทการตรวจ

4.3 การส่งต่อผู้ป่วยแบบหลายรูปแบบ

4.3.1 การบันทึกข้อมูลการ Refer (ส่งต่อโรงพยาบาล)

คำอธิบาย: ระบบสามารถจัดการการส่งต่อผู้ป่วยไปยังสถานพยาบาลอื่น (ใช้ร่วมกับระบบซักประวัติ)

ข้อกำหนด: - FR-4.3.1: อ้างอิงจาก SRS ระบบซักประวัติ (1.2.2) ข้อ FR-4.2.15-4.2.16 - FR-4.3.2: เพิ่มเติม: ระบบต้องสามารถแนบภาพและผลการตรวจร่างกายไปกับใบ Refer

4.3.2 การส่งต่อผู้ป่วยไปรับการรักษาต่อแผนกอื่นๆ

คำอธิบาย: ระบบสามารถส่งต่อผู้ป่วยภายในโรงพยาบาลเดียวกัน

ข้อกำหนด: - FR-4.3.3: ระบบต้องสามารถส่งต่อผู้ป่วยไปแผนกอื่นๆ ได้ ได้แก่: - แผนกผู้ป่วยใน (1.2.17) - แผนกฉุกเฉิน (1.2.4) - แผนกทันตกรรม (1.2.5) - แผนกคลินิกพิเศษ (1.2.9) - FR-4.3.4: ระบบต้องระบุเหตุผลการส่งต่อและความเร่งด่วน - FR-4.3.5: ระบบต้องส่งข้อมูลการตรวจและการรักษาไปกับการส่งต่อ

4.3.3 การส่งผู้ป่วยผ่าตัด

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

ข้อกำหนด: - FR-4.3.6: ระบบต้องสามารถส่งผู้ป่วยไปห้องผ่าตัด (1.2.18) โดยระบุ: - ประเภทการผ่าตัด (ฉุกเฉิน/นัดหมาย) - แพทย์ผู้ผ่าตัด - การเตรียมตัวก่อนผ่าตัด - ข้อมูลความเสี่ยงและการแพ้ยา - FR-4.3.7: ระบบต้องเชื่อมโยงกับระบบนัดหมายและตารางเวรแพทย์ (1.2.6)

4.4 การจัดการโรคพิเศษและข้อมูลทางการแพทย์เพิ่มเติม

4.4.1 การตรวจสอบโรคที่ต้องระวังการใช้ยา

คำอธิบาย: ระบบสามารถตรวจสอบและจัดการโรคพิเศษที่ต้องระวังการใช้ยา

ข้อกำหนด: - FR-4.4.1: ระบบต้องสามารถบันทึกและตรวจสอบโรค G-6-PD ของผู้ป่วย - FR-4.4.2: ระบบต้องเตือนเมื่อสั่งยาที่อันตรายต่อผู้ป่วย G-6-PD - FR-4.4.3: ระบบต้องสามารถบันทึกโรคอื่นๆ ที่ต้องระวังการใช้ยา

4.4.2 การจัดการข้อมูลการแพ้อาหาร

คำอธิบาย: ระบบสามารถบันทึกและจัดการข้อมูลการแพ้อาหาร (เพิ่มเติมจากการแพ้ยาในระบบซักประวัติ)

ข้อกำหนด: - FR-4.4.4: ระบบต้องสามารถบันทึกข้อมูลการแพ้อาหารของผู้ป่วย - FR-4.4.5: ระบบต้องเชื่อมโยงกับระบบโภชนาการ (1.2.20) สำหรับผู้ป่วยใน - FR-4.4.6: ระบบต้องแสดงการเตือนเมื่อผู้ป่วยมีการแพ้อาหาร

4.4.3 การบันทึกข้อมูลผลข้างเคียงจากยา

คำอธิบาย: ระบบสามารถบันทึกและติดตามผลข้างเคียงจากยา

ข้อกำหนด: - FR-4.4.7: ระบบต้องสามารถบันทึกผลข้างเคียงจากยาที่เกิดขึ้น - FR-4.4.8: ระบบต้องเชื่อมโยงกับข้อมูลการแพ้ยาในระบบซักประวัติ (1.2.2) - FR-4.4.9: ระบบต้องสามารถรายงานผลข้างเคียงไปยังหน่วยงานที่เกี่ยวข้อง

4.5 การจัดการ Note และการติดตาม

4.5.1 การบันทึก Note เกี่ยวกับผู้ป่วย

คำอธิบาย: ระบบสามารถบันทึก Note สำหรับการติดตามการรักษา

ข้อกำหนด: - FR-4.5.1: ระบบต้องสามารถบันทึก Clinical Note ประเภทต่างๆ ได้: - Progress Note - บันทึกความคืบหน้าการรักษา - Follow-up Note - บันทึกการติดตาม - Consultation Note - บันทึกการปรึกษา - Discharge Note - บันทึกการจำหน่าย - FR-4.5.2: ระบบต้องสามารถแนบไฟล์และภาพกับ Note - FR-4.5.3: ระบบต้องมีระบบ Template สำหรับ Note แต่ละประเภท

4.5.2 การตรวจสอบการนัดหมายของตนเอง

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

ข้อกำหนด: - FR-4.5.4: ระบบต้องแสดงตารางนัดหมายของแพทย์แต่ละคน - FR-4.5.5: ระบบต้องเชื่อมโยงกับระบบนัดหมายและตารางเวรแพทย์ (1.2.6) - FR-4.5.6: ระบบต้องแสดงรายละเอียดผู้ป่วยที่นัดและสาเหตุการนัด

4.6 การคำนวณยาโรคเรื้อรัง

4.6.1 การคำนวณจำนวนยาอัตโนมัติ

คำอธิบาย: ระบบสามารถคำนวณจำนวนยาโรคเรื้อรังตามจำนวนวันใช้

ข้อกำหนด: - FR-4.6.1: ระบบต้องสามารถระบุยาโรคเรื้อรังและคำนวณจำนวนยาอัตโนมัติ - FR-4.6.2: ระบบต้องคำนวณจากสูตร: จำนวนยา = วันใช้ยา × ความถี่ × จำนวนเม็ดต่อครั้ง - FR-4.6.3: ระบบต้องแสดงการคำนวณให้แพทย์ตรวจสอบก่อนบันทึก

---

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

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

• PR-5.1.1: ระบบต้องสามารถแสดงภาพและผลการตรวจภายใน 3 วินาที
• PR-5.1.2: ระบบต้องรองรับการอัพโหลดไฟล์ภาพขนาดใหญ่ (สูงสุด 50MB ต่อไฟล์)
• PR-5.1.3: ระบบต้องสามารถแสดงผล Lab แบบเปรียบเทียบภายใน 5 วินาที
• PR-5.1.4: ระบบต้องรองรับการใช้งานพร้อมกันในห้องตรวจหลายห้อง

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

• SR-5.2.1: ระบบต้องเข้ารหัสไฟล์ภาพและข้อมูลทางการแพทย์
• SR-5.2.2: ระบบต้องมีระบบ Digital Signature สำหรับการอนุมัติ
• SR-5.2.3: ระบบต้องบันทึก Audit Trail สำหรับการเข้าถึงภาพและข้อมูล
• SR-5.2.4: ระบบต้องปฏิบัติตามมาตรฐาน PDPA สำหรับข้อมูลภาพ

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

• UR-5.3.1: ระบบต้องมี Clinical Interface ที่ใช้งานง่ายสำหรับแพทย์
• UR-5.3.2: ระบบต้องรองรับการใช้งานบน Touch Screen
• UR-5.3.3: ระบบต้องมีเครื่องมือการวาดรูปที่ใช้งานง่าย
• UR-5.3.4: ระบบต้องมีระบบ Shortcut และ Hotkey สำหรับการใช้งานเร็ว

---

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

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

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

graph TD
    subgraph "ระบบห้องตรวจแพทย์ (1.2.3)"
        EXAM["Physical Examination<br/>การตรวจร่างกาย"]
        IMG["Image Management<br/>การจัดการภาพ"]
        RESULT["Result Display<br/>แสดงผลการตรวจ"]
        TRANSFER["Patient Transfer<br/>การส่งต่อผู้ป่วย"]
    end

    HISTORY[ระบบซักประวัติ<br/>1.2.2] -->|ข้อมูลประวัติ| EXAM
    EXAM -->|ผลการตรวจ| HISTORY

    RIGHTS[ระบบตรวจสอบสิทธิ<br/>1.2.15] -->|Modal: ตรวจสิทธิ์| EXAM

    PHARMACY[ระบบเภสัชกรรม<br/>1.2.13] -->|Drug Check| EXAM
    EXAM -->|ใบสั่งยา| PHARMACY

    LAB[ระบบงานชันสูตร<br/>1.2.7] -->|ผล Lab| RESULT
    EXAM -->|สั่ง Lab| LAB

    XRAY[ระบบรังสีวิทยา<br/>1.2.8] -->|ผล X-Ray| RESULT
    EXAM -->|สั่ง X-Ray| XRAY

    TRANSFER -->|ส่งต่อ| IPD[ระบบผู้ป่วยใน<br/>1.2.17]
    TRANSFER -->|ส่งผ่าตัด| OR[ระบบห้องผ่าตัด<br/>1.2.18]
    TRANSFER -->|นัดหมาย| APPT[ระบบนัดหมาย<br/>1.2.6]

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

6.2.1 ระบบซักประวัติ (1.2.2)

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

// Receive from History System
GET /api/v1/history/{historyId}/complete-data
POST /api/v1/examroom/patient/receive

// Send back to History System  
PUT /api/v1/history/{historyId}/examination-results
POST /api/v1/history/follow-up/create

ข้อมูลที่แลกเปลี่ยน: - รับจากระบบซักประวัติ: ข้อมูล Vital Signs, CC, HPI, PMH, FH, SH, การแพ้ยา, การวินิจฉัยเบื้องต้น - ส่งกลับไประบบซักประวัติ: ผลการตรวจร่างกาย, การวินิจฉัยครั้งสุดท้าย, แผนการรักษา, การนัดติดตาม

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

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

// Enhanced Result Display APIs
GET /api/v1/lab/results/comparison/{hn}?period=6months
GET /api/v1/lab/results/trend/{testCode}
GET /api/v1/radiology/images/{examId}
PUT /api/v1/examroom/result/interpretation

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

6.2.3 ระบบผู้ป่วยใน (1.2.17)

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

// Patient Transfer APIs
POST /api/v1/admission/transfer/create
PUT /api/v1/admission/transfer/approve
GET /api/v1/admission/bed/availability

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

6.2.4 ระบบห้องผ่าตัด และวิสัญญี (1.2.18)

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

// Surgery Transfer APIs
POST /api/v1/surgery/referral/create
GET /api/v1/surgery/schedule/available
PUT /api/v1/surgery/preparation/complete

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

6.3 การแยกฟีเจอร์เพื่อหลีกเลี่ยงการซ้ำซ้อน

6.3.1 ฟีเจอร์ที่ใช้ร่วมกับระบบซักประวัติ

Shared Components (ไม่ต้องพัฒนาซ้ำ): - Vital Signs Recording → ใช้จากระบบซักประวัติ (1.2.2) - Drug Allergy Management → ใช้จากระบบซักประวัติ (1.2.2)
- Basic ICD Diagnosis → ใช้จากระบบซักประวัติ (1.2.2) - Medication Ordering → ใช้จากระบบซักประวัติ (1.2.2) - Basic Lab/X-Ray Ordering → ใช้จากระบบซักประวัติ (1.2.2)

6.3.2 ฟีเจอร์เฉพาะระบบห้องตรวจแพทย์

Unique Features (ต้องพัฒนาใหม่): - Physical Examination Documentation - Medical Image Management - Advanced Lab Result Display & Comparison
- Multi-format Patient Transfer - Clinical Note Management - G-6-PD & Food Allergy Management

---

สรุป

เอกสาร SRS นี้กำหนดความต้องการของระบบห้องตรวจแพทย์โดยเน้นฟีเจอร์ที่แตกต่างจากระบบซักประวัติ เพื่อหลีกเลี่ยงการพัฒนาซ้ำซ้อน การพัฒนาระบบควรใช้ Modular Architecture และ API Integration เพื่อให้ระบบทำงานร่วมกันได้อย่างมีประสิทธิภาพ

ฟีเจอร์หลักที่ต้องพัฒนา: 1. 🔍 Physical Examination System - การตรวจร่างกายแบบครบถ้วน 2. 📊 Advanced Result Display - การแสดงและเปรียบเทียบผล Lab/X-Ray 3. 📸 Medical Image Management - การจัดการภาพและการวาดรูป 4. 🔄 Multi-format Transfer - การส่งต่อผู้ป่วยแบบหลายรูปแบบ 5. 💊 Special Disease Management - การจัดการ G-6-PD และการแพ้อาหาร 6. 📝 Clinical Documentation - การจัดการ Note และการติดตาม

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