Software Requirements Specification (SRS)

ระบบเวชระเบียนหลัก (Core Medical Record System)

เวอร์ชัน: 2.0

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

การปรับปรุง: แยกฟีเจอร์เฉพาะทางไประบบที่เหมาะสม เพิ่ม API Integration

---

สารบัญ

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

---

1. บทนำ

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

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

1.2 ขอบเขต (Scope)

ระบบเวชระเบียนหลักจะดำเนินการ: - ✅ การลงทะเบียนผู้ป่วยใหม่ และการจัดการข้อมูลผู้ป่วยหลัก - ✅ การบันทึกการส่งตรวจผู้ป่วย พื้นฐาน - ✅ การพิมพ์เอกสารหลัก ที่เกี่ยวข้องกับเวชระเบียน - ✅ การจัดการแฟ้มเวชระเบียน ทั้งผู้ป่วยนอกและผู้ป่วยใน - ✅ การจัดการระบบนัดหมาย พื้นฐาน - ✅ การรวมหมายเลข HN และการเปลี่ยนแปลงข้อมูลผู้ป่วย - ✅ API Integration กับระบบเฉพาะทางอื่นๆ

1.2.1 🚫 Out of Scope (ย้ายไประบบอื่น)

• ❌ การจัดการประวัติการแพ้ยารายละเอียด → ระบบซักประวัติ (1.2.2)
• ❌ การสั่งจ่ายยาและ Drug Interaction → ระบบเภสัชกรรม (1.2.13)
• ❌ การตรวจสอบสิทธิออนไลน์ → ระบบตรวจสอบสิทธิ (1.2.15)
• ❌ การจัดการคิวรายละเอียด → ระบบห้องตรวจ (1.2.3)

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

คำศัพท์	คำอธิบาย
HN	Hospital Number - หมายเลขประจำตัวผู้ป่วย
OPD	Out Patient Department - แผนกผู้ป่วยนอก
AN	Admission Number - หมายเลขการรับเข้าผู้ป่วยใน
PCU	Progressive Care Unit - หน่วยดูแลผู้ป่วยระดับกลาง
Chart	แฟ้มเวชระเบียนผู้ป่วย
Ward	หอผู้ป่วย
API	Application Programming Interface - ส่วนติดต่อโปรแกรมประยุกต์
JSON	JavaScript Object Notation - รูปแบบการแลกเปลี่ยนข้อมูล
REST	Representational State Transfer - สถาปัตยกรรม API

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

• TOR ระบบเวชระเบียน โรงพยาบาลค่ายธนรัชน์
• TOR ฉบับเต็ม (ระบบทั้งหมด 24 ระบบ)
• มาตรฐานการจัดการเวชระเบียนของกระทรวงสาธารณสุข
• System Separation Recommendations (เอกสารแนะนำการแยกระบบ)

1.5 ภาพรวมของเอกสาร

เอกสารนี้แบ่งออกเป็น 6 ส่วนหลัก โดยครอบคลุมตั้งแต่บทนำ คำอธิบายโดยรวมของระบบ ความต้องการเฉพาะของแต่ละฟังก์ชัน ความต้องการภายนอก คุณลักษณะของระบบ และความต้องการที่ไม่ใช่ฟังก์ชัน

---

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

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

ระบบเวชระเบียนเป็นส่วนหนึ่งของระบบสารสนเทศโรงพยาบาล (HIS) ที่ทำหน้าที่เป็นระบบหลักในการจัดการข้อมูลผู้ป่วยและเวชระเบียน โดยจะเชื่อมโยงกับระบบอื่นๆ ดังนี้: - ระบบการเงิน (สำหรับการคิดค่าบริการ) - ระบบตรวจสอบสิทธิ (สำหรับการตรวจสอบสิทธิการรักษา) - ระบบห้องตรวจ (สำหรับการส่งตรวจ) - ระบบเภสัชกรรม (สำหรับการจ่ายยา) - ระบบรังสีวิทยาและชันสูตร (สำหรับการส่งตรวจ Lab/X-Ray)

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

ระบบจะประกอบด้วยฟังก์ชันหลักดังนี้: 1. การลงทะเบียนผู้ป่วยใหม่ - บันทึกข้อมูลประวัติผู้ป่วยครั้งแรก 2. การบันทึกส่งตรวจผู้ป่วย - จัดการการส่งตรวจและติดตามผู้ป่วย 3. การพิมพ์เอกสาร - พิมพ์เอกสารต่างๆ ที่เกี่ยวข้อง 4. การจัดการแฟ้มเวชระเบียน - ระบบยืม-คืนแฟ้มเวชระเบียน 5. การนัดหมาย - จัดการการนัดหมายผู้ป่วย 6. ระบบเวชระเบียนอื่นๆ - การรวม HN และการจัดการข้อมูลพิเศษ

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

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

2.4 สภาพแวดล้อมการดำเนินงาน

• ระบบปฏิบัติการ: Windows Server
• ฐานข้อมูล: SQL Server หรือเทียบเท่า
• เว็บเบราว์เซอร์: Internet Explorer, Chrome, Firefox
• เครือข่าย: LAN/WAN ภายในโรงพยาบาล
• อุปกรณ์: เครื่องพิมพ์, เครื่องสแกนลายนิ้วมือ, เครื่องอ่าน Barcode, กล้องถ่ายรูป

2.5 ข้อจำกัดในการออกแบบและการดำเนินงาน

• ต้องสามารถทำงานได้ 24/7 เนื่องจากเป็นโรงพยาบาล
• ต้องรองรับผู้ใช้งานพร้อมกันได้มากกว่า 100 คน
• เวลาตอบสนองของระบบต้องไม่เกิน 3 วินาทีต่อการดำเนินการ
• ต้องปฏิบัติตามกฎหมายคุ้มครองข้อมูลส่วนบุคคล (PDPA)
• ต้องมีระบบสำรองข้อมูลและการกู้คืนข้อมูล

2.6 สมมติฐานและการพึ่งพาอาศัย

• ผู้ใช้งานมีความรู้พื้นฐานในการใช้คอมพิวเตอร์
• มีการฝึกอบรมผู้ใช้งานก่อนเริ่มใช้ระบบ
• มีทีมสนับสนุนทางเทคนิคสำหรับการบำรุงรักษาระบบ
• มีระบบสำรองไฟฟ้า (UPS) สำหรับการทำงานต่อเนื่อง

---

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

3.1 ฟังก์ชันการลงทะเบียนผู้ป่วยใหม่

3.1.1 ข้อมูลประวัติผู้ป่วย

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

Input: - ข้อมูลส่วนตัว: HN, ชื่อ, นามสกุล, เพศ, คำนำหน้านาม, วันเดือนปีเกิด, หมู่เลือด, สถานภาพสมรส, เชื้อชาติ, สัญชาติ, อาชีพ, ศาสนา, เวลาเกิด - เอกสารประจำตัว: เลขบัตรประจำตัวประชาชน, เลขที่หนังสือเดินทาง, เลขที่บัตรแรงงานต่างด้าว, เลขที่บัตรข้าราชการ - ที่อยู่: ที่อยู่ปัจจุบันและตามทะเบียนบ้าน พร้อมรายละเอียดครบถ้วน - รูปพรรณสัณฐาน, รูปถ่าย, ลายนิ้วมือ

Process: - คำนวณอายุจากวันเดือนปีเกิดอัตโนมัติ - ตรวจสอบความซ้ำซ้อนของข้อมูล - สร้าง HN อัตโนมัติหากไม่ระบุ - บันทึก timestamp และ user ที่ทำรายการ

Output: - ข้อมูลผู้ป่วยที่บันทึกในระบบ - หมายเลข HN ที่ได้รับมอบหมาย - ข้อความยืนยันการบันทึกข้อมูล

ข้อกำหนดพิเศษ: - สำหรับข้าราชการต้องเก็บข้อมูลสังกัดหลักและสังกัดรอง - สำหรับต่างชาติต้องเก็บข้อมูลนายจ้างและหน่วยขึ้นทะเบียน - รองรับการแสดงอายุทารกแรกเกิดเป็นวัน (อายุ < 1 เดือน) - กรณีไม่ทราบวันเดือนปีเกิดสามารถคำนวณจากอายุได้

3.1.2 ข้อมูลครอบครัวและผู้ติดต่อ

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

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

Process: - ตรวจสอบความถูกต้องของข้อมูลที่กรอก - เก็บประวัติการแก้ไขข้อมูล

Output: - ข้อมูลครอบครัวและผู้ติดต่อที่บันทึกแล้ว

3.1.3 ข้อมูลทางการแพทย์

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

Input: - โรคเรื้อรังของผู้ป่วยและปีที่เริ่มเป็น - โรคประจำตัว - ประวัติการเจ็บป่วยของญาติ: โรคประจำตัว, สถานภาพชีวิต, อายุ

Process: - เพิ่มผู้ป่วยเข้าทะเบียนคลินิกพิเศษตามโรคเรื้อรัง - ตรวจสอบความสัมพันธ์ของโรคกับประวัติครอบครัว

Output: - ข้อมูลประวัติทางการแพทย์ที่บันทึกแล้ว - การเพิ่มเข้าทะเบียนคลินิกพิเศษ (ถ้ามี)

3.2 ฟังก์ชันการบันทึกส่งตรวจผู้ป่วย

3.2.1 การค้นหาและเลือกผู้ป่วย

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

Input: - หมายเลข HN - ชื่อและ/หรือนามสกุล - หมายเลขบัตรประจำตัวประชาชน - ลายนิ้วมือ - Barcode

Process: - ค้นหาข้อมูลจากฐานข้อมูล - แสดงรายการผู้ป่วยที่ตรงตามเกณฑ์ - ตรวจสอบสถานะผู้ป่วย (มีชีวิต/เสียชีวิต)

Output: - รายการผู้ป่วยที่พบ - ข้อมูลประวัติผู้ป่วยที่เลือก

3.2.2 การเลือกสิทธิและประเภทผู้ป่วย

คำอธิบาย: ระบบต้องสามารถจัดการสิทธิการรักษาและประเภทผู้ป่วยได้

Input: - สิทธิการรักษา (สามารถเลือกได้มากกว่า 1 สิทธิ) - ประเภทผู้ป่วย: ปกติ, PCU, ออกหน่วย - ความเร่งด่วน: มากที่สุด, มาก, ปกติ - สภาพผู้ป่วย: เดินมา, นั่งรถเข็น, รถนอน - อาการสำคัญ

Process: - ตรวจสอบความถูกต้องของสิทธิ - กำหนดลำดับความสำคัญตามความเร่งด่วน

Output: - ข้อมูลการส่งตรวจที่ระบุสิทธิและประเภท

3.2.3 การส่งตรวจและจัดการคิว

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

Input: - ห้องและแผนกที่ต้องการส่งตรวจ - การส่งตรวจหลายแผนก - การส่งตรวจล่วงหน้า

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

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

---

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

4.1 ส่วนติดต่อผู้ใช้

4.1.1 ส่วนติดต่อกับผู้ใช้

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

4.1.2 ส่วนติดต่อกับฮาร์ดแวร์

• เครื่องพิมพ์สำหรับพิมพ์เอกสารต่างๆ
• เครื่องสแกนลายนิ้วมือสำหรับระบุตัวตนผู้ป่วย
• เครื่องอ่าน Barcode สำหรับค้นหาและยืม-คืนแฟ้ม
• กล้องถ่ายรูปสำหรับบันทึกภาพผู้ป่วย
• เครื่องสำรองไฟฟ้า (UPS)

4.1.3 ส่วนติดต่อกับซอฟต์แวร์

• ระบบฐานข้อมูล SQL Server
• ระบบปฏิบัติการ Windows Server
• Web Server (IIS)
• ระบบสำรองข้อมูล
• Antivirus Software

4.1.4 ส่วนติดต่อการสื่อสาร

• เชื่อมต่อกับระบบ HIS อื่นๆ ผ่าน Web Services หรือ API
• การส่งข้อมูลไปยังหน่วยงานภายนอก (สปสช., กรมบัญชีกลาง)
• การแลกเปลี่ยนข้อมูลกับโรงพยาบาลอื่น

4.2 ข้อกำหนดด้านประสิทธิภาพ

4.2.1 เวลาตอบสนอง

• การค้นหาผู้ป่วย: ไม่เกิน 2 วินาที
• การบันทึกข้อมูลใหม่: ไม่เกิน 3 วินาที
• การพิมพ์เอกสาร: ไม่เกิน 5 วินาที
• การโหลดหน้าจอ: ไม่เกิน 3 วินาที

4.2.2 ความจุการใช้งาน

• รองรับผู้ใช้งานพร้อมกัน: อย่างน้อย 100 คน
• จำนวนผู้ป่วยในฐานข้อมูล: อย่างน้อย 500,000 ราย
• จำนวนการเข้ารับบริการต่อวัน: อย่างน้อย 1,000 ครั้ง

4.2.3 ความพร้อมใช้งาน

• ระบบต้องทำงานได้ 99.5% ของเวลา (24x7)
• เวลาหยุดทำงานสำหรับบำรุงรักษา: ไม่เกิน 4 ชั่วโมงต่อเดือน
• การกู้คืนระบบหลังจากขัดข้อง: ภายใน 30 นาที

4.3 ข้อกำหนดด้านความปลอดภัย

4.3.1 การควบคุมการเข้าถึง

• ระบบ Login ด้วย Username และ Password
• การกำหนดสิทธิ์การใช้งานตามตำแหน่งหน้าที่
• การล็อกออกอัตโนมัติเมื่อไม่ใช้งานเกิน 30 นาที
• การเข้ารหัสข้อมูลสำคัญ

4.3.2 การป้องกันข้อมูล

• สำรองข้อมูลอัตโนมัติทุกวัน
• การเก็บ Log การใช้งานและการแก้ไขข้อมูล
• การป้องกันการเข้าถึงจากภายนอกระบบ
• การตรวจสอบความครบถ้วนของข้อมูล

---

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

5.1 การจัดการข้อมูลผู้ป่วย

5.1.1 การป้องกันข้อมูลซ้ำซ้อน

• ตรวจสอบความซ้ำซ้อนของเลขบัตรประจำตัวประชาชน
• เตือนเมื่อพบชื่อ-นามสกุลที่คล้ายกัน
• ระบบรวม HN เมื่อพบผู้ป่วยรายเดียวกันมีหลาย HN

5.1.2 การจัดการข้อมูลเก่า

• เก็บประวัติการแก้ไขข้อมูลทั้งหมด
• ไม่อนุญาตให้แก้ไขข้อมูลผู้ป่วยที่เสียชีวิต
• การเก็บข้อมูลการเปลี่ยน HN พร้อมวันที่และผู้ทำรายการ

5.1.3 การแจ้งเตือนพิเศษ

• แสดง Note เตือนเมื่อเปิดข้อมูลผู้ป่วย
• เตือนการเปลี่ยนคำนำหน้าชื่อเมื่อผู้ป่วยอายุ ≥ 15 ปี
• แจ้งเตือนเมื่อเอกสารไม่ครบถ้วน

5.2 การจัดการแฟ้มเวชระเบียน

5.2.1 ระบบยืม-คืนแฟ้ม

• การยืมแฟ้มอัตโนมัติเมื่อส่งตรวจ
• การติดตามสถานะแฟ้มแบบ Real-time
• รองรับการใช้ Barcode ในการยืม-คืน
• การพิมพ์รายชื่อผู้ป่วยนัดล่วงหน้า

5.2.2 การจัดการแฟ้มผู้ป่วยใน

• ติดตามแฟ้มค้างส่งจาก Ward
• บันทึกการยืม-คืน Chart ผู้ป่วยใน
• รายงานสถานะแฟ้มแบบรายละเอียด

5.3 ระบบรายงานและพิมพ์

5.3.1 เอกสารการลงทะเบียน

• บัตรประจำตัวผู้ป่วย
• ใบ ร.บ.1 ต. 02 (OPD CARD)
• ใบแทน OPD CARD

5.3.2 เอกสารการส่งตรวจ

• ใบสั่งยา
• บัตรคิว
• ใบยืมแฟ้มเวชระเบียน

5.4 การรองรับสถานการณ์พิเศษ

5.4.1 ภาวะประสบภัยหมู่

• ระบบลงทะเบียนแบบเร่งด่วนสำหรับ Mass Casualty
• การจัดลำดับความสำคัญของผู้ป่วย
• การรายงานสถานการณ์แบบ Real-time

6.8 การปฏิบัติตามกฎหมาย (Legal Requirements)

• ปฏิบัติตามพระราชบัญญัติคุ้มครองข้อมูลส่วนบุคคล (PDPA)
• ปฏิบัติตามมาตรฐานการจัดการเวชระเบียนของกระทรวงสาธารณสุข
• รองรับการตรวจสอบจากหน่วยงานราชการ
• การเก็บข้อมูลตามระยะเวลาที่กฎหมายกำหนด

---

7. การเชื่อมโยงกับระบบอื่น (System Integration)

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

ระบบเวชระเบียนหลักจะทำหน้าที่เป็น Hub System ที่เชื่อมโยงกับระบบเฉพาะทางอื่นๆ ผ่าน RESTful API

graph TD
    A["ระบบเวชระเบียนหลัก<br/>(Core Medical Record System)<br/>1.2.1"] --> B["ระบบซักประวัติ<br/>1.2.2"]
    A --> C["ระบบเภสัชกรรม<br/>1.2.13"]
    A --> D["ระบบตรวจสอบสิทธิ<br/>1.2.15"]
    A --> E["ระบบห้องตรวจ<br/>1.2.3"]
    A --> F["ระบบการเงิน<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:#e8f5e8,stroke:#1b5e20,stroke-width:2px
    style D fill:#fff3e0,stroke:#e65100,stroke-width:2px
    style E fill:#fce4ec,stroke:#880e4f,stroke-width:2px
    style F fill:#f1f8e9,stroke:#33691e,stroke-width:2px

7.2 API Integration Specifications

7.2.1 🔗 กับระบบตรวจสอบสิทธิ (1.2.15)

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

// API Endpoints
POST /api/v1/insurance/modal/open
POST /api/v1/insurance/rights/validate
POST /api/v1/insurance/rights/select

ข้อมูลที่แลกเปลี่ยน: - ส่ง: HN, CitizenID, VisitDate - รับ: ValidatedRights[], CoverageDetails, BillingModifiers

7.2.2 💰 กับระบบการเงิน (1.2.14)

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

// API Endpoints  
POST /api/v1/finance/visit/create
PUT /api/v1/finance/visit/update
GET /api/v1/finance/billing/calculate

ข้อมูลที่แลกเปลี่ยน: - ส่ง: VisitData, SelectedRights, ServiceCodes - รับ: BillingAmount, DiscountAmount, PaymentStatus

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

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

// API Endpoints
POST /api/v1/pharmacy/visit/notify
GET /api/v1/pharmacy/prescription/status

ข้อมูลที่แลกเปลี่ยน: - ส่ง: VisitCompleted, PatientData, AllergyWarnings - รับ: PrescriptionStatus, DrugOrderStatus

7.2.4 🏥 กับระบบห้องตรวจ (1.2.3)

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

// API Endpoints
POST /api/v1/examroom/queue/create
PUT /api/v1/examroom/queue/update
GET /api/v1/examroom/queue/status

ข้อมูลที่แลกเปลี่ยน: - ส่ง: QueueData, PatientInfo, UrgencyLevel - รับ: QueueStatus, CallStatus, ExamProgress

7.3 Error Handling และ Fallback

7.3.1 การจัดการข้อผิดพลาด

• Network Timeout: Retry mechanism with exponential backoff
• Service Unavailable: Graceful degradation โดยไม่หยุดการทำงาน
• Data Inconsistency: Auto-sync และ manual reconciliation

7.3.2 Fallback Strategies

{
  "insurance_system_down": {
    "action": "ใช้สิทธิ default หรือ cash payment",
    "manual_process": "ตรวจสอบสิทธิทีหลัง"
  },
  "finance_system_down": {
    "action": "บันทึกการส่งตรวจต่อไป คิดเงินทีหลัง",
    "manual_process": "คำนวณค่าบริการ manual"
  },
  "pharmacy_system_down": {
    "action": "ใช้ manual prescription จากระบบซักประวัติ",
    "manual_process": "สั่งยาผ่านกระดาษ"
  }
}

7.4 Data Synchronization

7.4.1 Real-time Sync

• ข้อมูลผู้ป่วยหลัก - sync ทันทีเมื่อมีการเปลี่ยนแปลง
• การส่งตรวจ - notify ระบบที่เกี่ยวข้องทันที

7.4.2 Batch Sync

• Master Data Updates - sync ทุกคืนเวลา 02:00
• Archive Data - ย้ายข้อมูลเก่าเป็น batch process

7.5 Security และ Authentication

7.5.1 API Security

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

7.5.2 Data Privacy

• Field-level Encryption สำหรับข้อมูลส่วนตัว
• Audit Logging ทุกการเข้าถึงข้อมูลผู้ป่วย
• GDPR Compliance สำหรับสิทธิผู้ป่วย

---

ภาคผนวก

ภาคผนวก A: คำศัพท์และตัวย่อเพิ่มเติม

คำศัพท์	คำอธิบาย
API Gateway	ตัวกลางในการจัดการ API calls ระหว่างระบบ
JWT	JSON Web Token - มาตรฐานการ authentication
TLS	Transport Layer Security - การเข้ารหัสข้อมูล
Circuit Breaker	กลไกป้องกันระบบล่มเมื่อ dependency ไม่พร้อมใช้งาน
Event Sourcing	การเก็บประวัติการเปลี่ยนแปลงข้อมูลแบบ event-driven

ภาคผนวก B: API Specifications

B.1 Request/Response Format

{
  "standard_format": {
    "timestamp": "ISO 8601 format",
    "request_id": "UUID v4",
    "api_version": "v1",
    "data": "actual payload",
    "metadata": "additional info"
  },
  "error_format": {
    "error_code": "HTTP status code",
    "error_message": "human readable message",
    "error_details": "technical details",
    "correlation_id": "for tracking"
  }
}

B.2 Authentication Flow

sequenceDiagram
    participant C as Client System
    participant AS as Auth Server
    participant API as API Gateway
    participant DB as Database

    Note over C,DB: Authentication Flow Process

    C->>AS: 1. POST /auth/login<br/>{username, password}
    AS->>DB: 2. Validate credentials
    DB-->>AS: 3. User data & permissions
    AS->>AS: 4. Generate JWT token
    AS-->>C: 5. JWT token + refresh token

    Note over C,API: API Request with Token

    C->>API: 6. API request<br/>Authorization: Bearer {JWT}
    API->>API: 7. Validate JWT token
    API->>DB: 8. Execute business logic
    DB-->>API: 9. Response data
    API-->>C: 10. API response

    Note over C,AS: Token Refresh Process

    C->>AS: 11. POST /auth/refresh<br/>{refresh_token}
    AS->>AS: 12. Validate refresh token
    AS-->>C: 13. New JWT token

    %%{init: {'theme':'base', 'themeVariables': { 'primaryColor': '#e3f2fd', 'primaryTextColor': '#000', 'primaryBorderColor': '#1976d2', 'lineColor': '#1976d2'}}}%%

ภาคผนวก C: Deployment Architecture

graph TD
    LB["Load Balancer<br/>🔄 การกระจายโหลด"] 

    LB --> WS["Web Server<br/>🌐 เว็บเซิร์ฟเวอร์"]
    LB --> API["API Gateway<br/>🚪 ประตู API"]
    LB --> CACHE["Cache Redis<br/>⚡ แคชข้อมูล"]

    API --> MDB["Medical Record DB<br/>🏥 ฐานข้อมูลเวชระเบียน"]
    API --> IDB["Insurance DB<br/>💳 ฐานข้อมูลสิทธิ"]
    API --> PDB["Pharmacy DB<br/>💊 ฐานข้อมูลเภสัชกรรม"]
    API --> FDB["Finance DB<br/>💰 ฐานข้อมูลการเงิน"]

    CACHE -.->|"Cache Layer"| MDB
    CACHE -.->|"Cache Layer"| IDB
    CACHE -.->|"Cache Layer"| PDB

    style LB fill:#ff9800,stroke:#e65100,stroke-width:3px
    style WS fill:#2196f3,stroke:#0d47a1,stroke-width:2px
    style API fill:#4caf50,stroke:#1b5e20,stroke-width:2px
    style CACHE fill:#f44336,stroke:#b71c1c,stroke-width:2px

    style MDB fill:#e1f5fe,stroke:#01579b,stroke-width:2px
    style IDB fill:#fff3e0,stroke:#e65100,stroke-width:2px
    style PDB fill:#e8f5e8,stroke:#1b5e20,stroke-width:2px
    style FDB fill:#f1f8e9,stroke:#33691e,stroke-width:2px

---

เอกสารนี้จัดทำขึ้นเพื่อใช้ในการพัฒนาระบบเวชระเบียนหลัก (Core Medical Record System) สำหรับโรงพยาบาลค่ายธนรัชน์ ที่มีการแยกระบบและ Integration ที่เหมาะสม และต้องได้รับการอนุมัติจากผู้มีอำนาจก่อนนำไปใช้ในการพัฒนาระบบ |---------|-----------| | PDPA | Personal Data Protection Act - พระราชบัญญัติคุ้มครองข้อมูลส่วนบุคคล | | HL7 | Health Level Seven - มาตรฐานการแลกเปลี่ยนข้อมูลทางการแพทย์ | | API | Application Programming Interface - ส่วนติดต่อโปรแกรมประยุกต์ | | Failover | การสลับไปใช้ระบบสำรองเมื่อระบบหลักขัดข้อง |

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

• ISO 27001 - Information Security Management
• ISO 13606 - Health informatics - Electronic health record communication
• มาตรฐาน HL7 FHIR สำหรับการแลกเปลี่ยนข้อมูลสุขภาพ

---

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