Software Requirements Specification (SRS)

ระบบการเงิน (Financial Management System)

เวอร์ชัน: 1.0

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

การปรับปรุง: ใหม่ - ครอบคลุมการจัดการการเงินและการชำระเงินครบวงจร

---

สารบัญ

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

---

1. บทนำ

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

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

1.2 ขอบเขต (Scope)

ระบบการเงินจะดำเนินการ: - ✅ การจัดการข้อมูลสิทธิการรักษาทางการเงิน และการกำหนดผังการคิดค่าบริการ - ✅ การรับชำระเงินครบวงจร รองรับหลายสิทธิและหลายรูปแบบการชำระ - ✅ การออกใบเสร็จและเอกสารทางการเงิน ครบถ้วนตามมาตรฐาน - ✅ การจัดการการยกเว้นและลดหย่อน ค่ารักษาพยาบาล - ✅ การบริหารจัดการค้างชำระและเงินรับฝาก แบบครบวงจร - ✅ การยกเลิกและแก้ไขใบเสร็จ พร้อม Audit Trail - ✅ การปิดรอบการเงินและรายงานสรุป ตามช่วงเวลาต่างๆ - ✅ การเชื่อมโยงกับระบบตรวจสอบสิทธิ และระบบอื่นๆ ใน HIS

1.2.1 🚫 Out of Scope

• ❌ การจัดการบัญชีขั้นสูง (งบการเงิน, งบดุล) → ระบบบัญชี (นอกขอบเขต HIS)
• ❌ การจัดการเงินเดือนและบุคลากร → ระบบ HR (นอกขอบเขต HIS)
• ❌ การตรวจสอบสิทธิออนไลน์ → ระบบตรวจสอบสิทธิ (1.2.15)
• ❌ การจัดการคลังยาและพัสดุ → ระบบเภสัชกรรม (1.2.13)

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

คำศัพท์	คำอธิบาย
HN	Hospital Number - หมายเลขประจำตัวผู้ป่วย
AN	Admission Number - หมายเลขการรับเข้าผู้ป่วยใน
OPD	Out Patient Department - แผนกผู้ป่วยนอก
IPD	In Patient Department - แผนกผู้ป่วยใน
UC	Universal Coverage - หลักประกันสุขภาพถ้วนหน้า
SSS	Social Security Scheme - ประกันสังคม
CGD	Comptroller General's Department - กรมบัญชีกลาง
Receipt	ใบเสร็จรับเงิน - เอกสารยืนยันการรับชำระเงิน
Invoice	ใบแจ้งหนี้ - เอกสารแจ้งค่าใช้จ่าย
Copayment	ค่าใช้จ่ายส่วนตัว - จำนวนเงินที่ผู้ป่วยต้องจ่ายเอง
Deductible	ค่าเสียหายที่หักได้ - จำนวนเงินที่หักจากสิทธิได้
DRG	Diagnosis Related Group - การจัดกลุ่มการวินิจฉัย
Global Budget	งบประมาณรวม - การจ่ายเงินแบบรวม
Fee for Service	ค่าบริการตามรายการ - การจ่ายเงินตามการให้บริการ

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

• TOR ระบบการเงิน โรงพยาบาลค่ายธนรัชน์
• TOR ฉบับเต็ม (ระบบทั้งหมด 24 ระบบ)
• SRS ระบบตรวจสอบสิทธิ (1.2.15)
• SRS ระบบเวชระเบียน (1.2.1)
• มาตรฐานการจัดการการเงินของกระทรวงสาธารณสุข
• พระราชบัญญัติคุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562
• มาตรฐาน ICD-10-TM และ ICD-9-CM

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

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

---

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

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

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

graph TD
    FINANCE["💰 ระบบการเงิน<br/>Financial System"]

    %% Core Medical Systems
    MED["📋 ระบบเวชระเบียน<br/>1.2.1"]
    HIST["🗣️ ระบบซักประวัติ<br/>1.2.2"]
    EXAM["🏥 ระบบห้องตรวจ<br/>1.2.3"]
    EMERG["🚨 ระบบห้องฉุกเฉิน<br/>1.2.4"]
    DENT["🦷 ระบบทันตกรรม<br/>1.2.5"]

    %% Specialized Systems
    LAB["🔬 ระบบชันสูตร<br/>1.2.7"]
    RAD["📷 ระบบรังสีวิทยา<br/>1.2.8"]
    PHARM["💊 ระบบเภสัชกรรม<br/>1.2.13"]
    RIGHTS["🆔 ระบบตรวจสอบสิทธิ<br/>1.2.15"]

    %% Admission Systems
    ADM["🛏️ ระบบ Admission<br/>1.2.16"]
    IPD["🏥 ระบบผู้ป่วยใน<br/>1.2.17"]
    OR["⚕️ ระบบห้องผ่าตัด<br/>1.2.18"]

    %% External Systems
    NHSO["🏛️ ระบบ สปสช.<br/>NHSO"]
    SSO["🏛️ ระบบ สนย.<br/>SSO"]
    CGD["🏛️ ระบบ กรมบัญชีกลาง<br/>CGD"]

    %% Connections - Receive Charges
    MED --> FINANCE
    HIST --> FINANCE
    EXAM --> FINANCE
    EMERG --> FINANCE
    DENT --> FINANCE
    LAB --> FINANCE
    RAD --> FINANCE
    PHARM --> FINANCE
    ADM --> FINANCE
    IPD --> FINANCE
    OR --> FINANCE

    %% Rights Integration
    RIGHTS --> FINANCE
    FINANCE --> RIGHTS

    %% External Integration
    FINANCE --> NHSO
    FINANCE --> SSO
    FINANCE --> CGD

    %% Styling
    style FINANCE fill:#ff9800,stroke:#f57c00,color:#fff
    style RIGHTS fill:#4caf50,stroke:#388e3c,color:#fff
    style MED fill:#2196f3,stroke:#1976d2,color:#fff
    style IPD fill:#9c27b0,stroke:#7b1fa2,color:#fff
    style NHSO fill:#607d8b,stroke:#455a64,color:#fff
    style SSO fill:#607d8b,stroke:#455a64,color:#fff
    style CGD fill:#607d8b,stroke:#455a64,color:#fff

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

ระบบจะประกอบด้วยฟังก์ชันหลักดังนี้:

2.2.1 กลุ่มฟังก์ชัน Financial Master Data Management

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

2.2.2 กลุ่มฟังก์ชัน Payment Processing

1. การรับชำระเงินผู้ป่วยนอก (OPD) - รับชำระค่ารักษาแบบรายการ
2. การรับชำระเงินผู้ป่วยใน (IPD) - รับชำระค่ารักษาแบบรวม
3. การรับชำระหลายสิทธิ - รองรับการใช้สิทธิผสมผสาน
4. การจัดการเงินรับฝาก (Deposit) - จัดการเงินมัดจำ

2.2.3 กลุ่มฟังก์ชัน Document Management

1. การออกใบเสร็จรับเงิน - ออกเอกสารยืนยันการชำระ
2. การออกใบแจ้งหนี้ - ออกเอกสารแจ้งค่าใช้จ่าย
3. การพิมพ์เอกสารทางการเงิน - เอกสารต่างๆ ที่เกี่ยวข้อง
4. การยกเลิกและแก้ไขใบเสร็จ - จัดการเอกสารที่ต้องแก้ไข

2.2.4 กลุ่มฟังก์ชัน Outstanding Management

1. การจัดการค้างชำระ - ติดตามและแจ้งเตือนหนี้ค้างชำระ
2. การอนุมัติลดหย่อน - ระบบขออนุมัติการลดหย่อน
3. การยกเว้นค่ารักษา - จัดการการยกเว้นเป็นพิเศษ

2.2.5 กลุ่มฟังก์ชัน Financial Reporting & Closing

1. การปิดรอบการเงิน - ปิดยอดรายวัน รายเดือน รายปี
2. รายงานการเงิน - รายงานสรุปและวิเคราะห์ทางการเงิน
3. การจัดการเงินสด - นับเงิน นำส่งเงิน และยอดคงเหลือ

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

2.3.1 เจ้าหน้าที่การเงิน (Finance Staff)

• ลักษณะ: ผู้ปฏิบัติงานด้านการเงินโดยตรง
• หน้าที่:
• รับชำระเงินจากผู้ป่วยและญาติ
• ออกใบเสร็จและเอกสารทางการเงิน
• จัดการเงินรับฝากและค้างชำระ
• นับเงินและปิดยอดรายวัน
• ระดับทักษะ: ปานกลาง - มีความรู้ด้านการเงินพื้นฐาน

2.3.2 หัวหน้าการเงิน (Finance Supervisor)

• ลักษณะ: ผู้ดูแลและควบคุมงานการเงิน
• หน้าที่:
• อนุมัติการลดหย่อนและยกเว้น
• ตรวจสอบยอดเงินและการปิดรอบ
• จัดการผู้ใช้งานในแผนกการเงิน
• ดูรายงานการเงินและวิเคราะห์
• ระดับทักษะ: สูง - มีความรู้ด้านการเงินและการบริหาร

2.3.3 เจ้าหน้าที่ลงทะเบียน (Registration Staff)

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

2.3.4 แพทย์และพยาบาล (Medical Staff)

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

2.3.5 ผู้ดูแลระบบการเงิน (Finance System Admin)

• ลักษณะ: ผู้ดูแลระบบการเงินเฉพาะด้าน
• หน้าที่:
• ตั้งค่าสิทธิและผังการคิดค่าบริการ
• จัดการจุดรับชำระเงินและอุปกรณ์
• ดูแลการเชื่อมโยงกับระบบภายนอก
• แก้ไขปัญหาระบบการเงิน
• ระดับทักษะ: สูง - มีความรู้ทั้งการเงินและเทคนิค

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

2.4.1 สภาพแวดล้อมฮาร์ดแวร์

• เซิร์ฟเวอร์: Windows Server 2019+ หรือ Linux (CentOS/Ubuntu)
• ฐานข้อมูล: SQL Server 2019+ หรือ MySQL 8.0+ หรือ PostgreSQL 13+
• หน่วยความจำ: RAM ขั้นต่ำ 16 GB, แนะนำ 32 GB+
• พื้นที่จัดเก็บ: SSD ขั้นต่ำ 1 TB สำหรับระบบ, 5+ TB สำหรับข้อมูล
• เครือข่าย: Gigabit Ethernet, เชื่อมต่อ Internet สำหรับ API ภายนอก

2.4.2 อุปกรณ์ประกอบ

• เครื่องพิมพ์ใบเสร็จ: Thermal Printer 80mm สำหรับใบเสร็จ
• เครื่องพิมพ์เอกสาร: Laser Printer A4 สำหรับเอกสารทางการเงิน
• เครื่องอ่านบัตรเครดิต: EDC Terminal สำหรับการชำระด้วยบัตร
• เครื่องนับเงิน: Money Counter สำหรับนับเงินสด
• เครื่องตรวจเงินปลอม: UV Detector สำหรับตรวจสอบธนบัตร
• ลิ้นชักเก็บเงิน: Cash Drawer ที่เชื่อมต่อกับเครื่องพิมพ์

2.4.3 สภาพแวดล้อมซอฟต์แวร์

• เว็บเซิร์ฟเวอร์: Apache 2.4+ หรือ Nginx 1.18+ หรือ IIS 10+
• ภาษาโปรแกรม: PHP 8.0+, .NET Core 6+, หรือ Java 11+
• เว็บเบราว์เซอร์: Chrome 90+, Firefox 85+, Edge 90+
• SSL/TLS: ใบรับรอง SSL สำหรับการเข้ารหัสการสื่อสาร
• API Integration: REST API สำหรับเชื่อมต่อระบบภายนอก

2.4.4 การรักษาความปลอดภัย

• Firewall: การป้องกันระดับเครือข่าย
• Encryption: การเข้ารหัสข้อมูลทางการเงิน AES-256
• Backup System: ระบบสำรองข้อมูลอัตโนมัติ
• Audit System: บันทึกการใช้งานทุกรายการ

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

2.5.1 ข้อจำกัดด้านประสิทธิภาพ

• ระบบต้องทำงานได้ 24/7 โดยมี uptime ไม่น้อยกว่า 99.9%
• เวลาตอบสนองสำหรับการรับชำระเงินไม่เกิน 3 วินาที
• การออกใบเสร็จต้องไม่เกิน 5 วินาที
• รองรับผู้ใช้งานพร้อมกัน: อย่างน้อย 200 คน
• การปิดรอบรายวันต้องเสร็จภายใน 30 นาที

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

• ปฏิบัติตาม PDPA และกฎหมายคุ้มครองข้อมูลส่วนบุคคล
• การเข้ารหัสข้อมูลทางการเงินด้วย AES-256
• เก็บ Audit Logs การทำรายการไม่น้อยกว่า 7 ปี
• การควบคุมการเข้าถึงข้อมูลตาม Role-based Access Control
• การตรวจสอบ Digital Signature สำหรับเอกสารสำคัญ

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

• ปฏิบัติตามมาตรฐานการบัญชีของกระทรวงสาธารณสุข
• รองรับการส่งข้อมูลตาม 43 แฟ้มของ สปสช.
• เป็นไปตามมาตรฐาน ICD-10-TM และ ICD-9-CM
• รองรับการตรวจสอบจากหน่วยงานภายนอก

2.5.4 ข้อจำกัดด้านการใช้งาน

• รองรับภาษาไทยและอังกฤษ
• การออกแบบต้องเป็น Responsive Design
• รองรับการใช้งานบนอุปกรณ์ Tablet สำหรับจุดรับชำระเงินเคลื่อนที่
• Interface ต้องใช้งานง่ายและรวดเร็ว เหมาะกับสภาพการทำงาน

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

2.6.1 สมมติฐาน

• เจ้าหน้าที่การเงินมีความรู้เบื้องต้นด้านการเงินและการบัญชี
• มีการฝึกอบรมการใช้งานระบบก่อนเริ่มใช้งานจริง
• มีทีม IT Support สำหรับการแก้ไขปัญหาเร่งด่วน 24/7
• มีระบบสำรองไฟฟ้า (UPS) และ Generator สำหรับการทำงานต่อเนื่อง
• อุปกรณ์การเงิน (เครื่องพิมพ์, เครื่องนับเงิน) มีการบำรุงรักษาสม่ำเสมอ

2.6.2 การพึ่งพาอาศัย

• ระบบต้องเชื่อมต่อกับระบบตรวจสอบสิทธิ (1.2.15) เพื่อดึงข้อมูลสิทธิ
• ต้องมี Internet connection เสถียรสำหรับ API ระบบภายนอก (สปสช., สนย.)
• ต้องมีระบบ Backup storage (NAS หรือ Cloud) สำหรับสำรองข้อมูลทางการเงิน
• ต้องมีระบบ Email Server สำหรับส่งรายงานการเงินอัตโนมัติ
• ต้องมีการเชื่อมต่อกับระบบธนาคารสำหรับการชำระเงินผ่านบัตรเครดิต

---

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

3.1 กลุ่มฟังก์ชัน Financial Master Data Management

3.1.1 การจัดการข้อมูลสิทธิการรักษาพยาบาล (FR-01)

3.1.1.1 การกำหนดข้อมูลสิทธิพื้นฐาน

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

Input: - ข้อมูลสิทธิหลัก: รหัสสิทธิ, ชื่อสิทธิ, คำอธิบายสิทธิ - ประเภทการชำระเงิน: เงินสด, บัตรเครดิต, เงินโอน, หักบัญชีสิทธิ - รหัสสิทธิ สนย.: รหัสตาม 43 แฟ้มของ สปสช. - ชื่อสิทธิมาตรฐาน สปสช.: ชื่อที่ใช้ในการส่งข้อมูล - ค่าธรรมเนียมสิทธิ: จำนวนเงินที่ผู้ป่วยต้องชำระเอง (Copayment)

Process: - ตรวจสอบความซ้ำซ้อนของรหัสสิทธิ - เชื่อมโยงกับระบบตรวจสอบสิทธิ (1.2.15) - สร้างความสัมพันธ์ระหว่างสิทธิกับผังการคิดค่าบริการ - บันทึก timestamp และ user ที่ทำรายการ

Output: - ข้อมูลสิทธิที่บันทึกในระบบ - การเชื่อมโยงกับตารางการคิดค่าบริการ - ข้อความยืนยันการบันทึกข้อมูล

3.1.1.2 การกำหนดผังการคิดค่าบริการ

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

ประเภทการคิดค่าบริการ:

1. Fee for Service (ตามรายการ)
   - คิดตามการใช้บริการจริง
   - มีการกำหนดราคาแต่ละรายการ

2. DRG (Diagnosis Related Group)
   - คิดตามกลุ่มโรค
   - ราคาคงที่ตามการวินิจฉัย

3. Global Budget (งบประมาณรวม)
   - จ่ายเป็นยอดรวม
   - ไม่ต้องคิดรายการ

4. Capitation (จ่ายตามหัว)
   - จ่ายตามจำนวนประชากร
   - ไม่ขึ้นกับการใช้บริการ

5. Mixed Payment (ผสมผสาน)
   - รวมหลายวิธีการ
   - ตามเงื่อนไขที่กำหนด

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

3.1.1.3 การกำหนดส่วนลดตามหมวดค่ารักษา

คำอธิบาย: ระบบต้องสามารถกำหนดส่วนลดเป็นเปอร์เซ็นต์ในหมวดค่ารักษาพยาบาลต่างๆ ได้

หมวดค่ารักษาพยาบาล:

OPD_Categories:
  - ค่าตรวจรักษา: "examination_fee"
  - ค่ายา: "medication_fee"  
  - ค่าตรวจทางห้องปฏิบัติการ: "laboratory_fee"
  - ค่าตรวจเอกซเรย์: "radiology_fee"
  - ค่าหัตถการ: "procedure_fee"
  - ค่าบริการพิเศษ: "special_service_fee"

IPD_Categories:
  - ค่าห้องและอาหาร: "room_board_fee"
  - ค่าการพยาบาล: "nursing_fee"
  - ค่าแพทย์: "doctor_fee"
  - ค่ายาและเวชภัณฑ์: "medication_supply_fee"
  - ค่าตรวจทางห้องปฏิบัติการ: "laboratory_fee"
  - ค่าตรวจเอกซเรย์: "radiology_fee"
  - ค่าห้องผ่าตัด: "operation_room_fee"
  - ค่าหัตถการ: "procedure_fee"
  - ค่าบริการอื่นๆ: "other_service_fee"

การกำหนดส่วนลด:

Input: 
- สิทธิการรักษา
- หมวดค่ารักษา
- เปอร์เซ็นต์ส่วนลด (0-100%)
- เงื่อนไขการใช้ (ถ้ามี)
- วันที่เริ่มใช้และวันหมดอายุ

Process:
- ตรวจสอบความถูกต้องของเปอร์เซ็นต์
- บันทึกการตั้งค่าส่วนลด
- เชื่อมโยงกับตารางการคิดค่าบริการ

Output:
- ตารางส่วนลดตามสิทธิและหมวดค่ารักษา
- การแสดงผลส่วนลดในระบบรับชำระเงิน

3.1.2 การจัดการการยกเว้นและลดหย่อน (FR-02)

3.1.2.1 การกำหนดประเภทการยกเว้น

คำอธิบาย: ระบบต้องรองรับการยกเว้นค่ารักษาพยาบาลตามนโยบายของโรงพยาบาล

ประเภทการยกเว้น:

1. การยกเว้นแบบเต็มจำนวน (Full Exemption)
   - ยกเว้น 100% ของค่ารักษา
   - สำหรับกรณีพิเศษ (ภัยพิบัติ, การกุศล)

2. การยกเว้นแบบบางส่วน (Partial Exemption)  
   - ยกเว้นเฉพาะหมวดค่ารักษาที่กำหนด
   - ยกเว้นตามเปอร์เซ็นต์ที่กำหนด

3. การยกเว้นตามเงื่อนไข (Conditional Exemption)
   - ยกเว้นตามสถานะผู้ป่วย (ยากไร้, ผู้สูงอายุ)
   - ยกเว้นตามประเภทการรักษา (ฉุกเฉิน, โรคเรื้อรัง)

4. การยกเว้นพนักงาน (Staff Exemption)
   - ยกเว้นสำหรับพนักงานและครอบครัว
   - ยกเว้นตามสวัสดิการที่กำหนด

การขออนุมัติยกเว้น:

Input:
- HN ผู้ป่วย
- ประเภทการยกเว้น
- เหตุผลการขอยกเว้น
- หลักฐานประกอบ (ถ้ามี)
- ผู้ขออนุมัติ

Process:
- ตรวจสอบสิทธิ์ในการขออนุมัติ
- ส่งคำขอไปยังผู้มีอำนาจ
- บันทึกประวัติการขออนุมัติ
- แจ้งผลการอนุมัติ

Output:
- สถานะการอนุมัติ (อนุมัติ/ไม่อนุมัติ/รอพิจารณา)
- เอกสารการอนุมัติ
- การปรับยอดค่ารักษาตามการอนุมัติ

3.1.2.2 การกำหนดประเภทการลดหย่อน

คำอธิบาย: ระบบต้องรองรับการลดหย่อนค่ารักษาพยาบาลที่ได้รับอนุมัติ

ประเภทการลดหย่อน:

1. ลดหย่อนตามเปอร์เซ็นต์ (Percentage Discount)
   - ลด 10%, 20%, 50% ตามที่อนุมัติ
   - สามารถกำหนดเพดานการลด

2. ลดหย่อนแบบยอดเงิน (Fixed Amount Discount)
   - ลดเป็นจำนวนเงินคงที่
   - เช่น ลด 500 บาท, 1,000 บาท

3. ลดหย่อนตามหมวดค่ารักษา (Category-based Discount)
   - ลดเฉพาะค่ายา หรือค่าตรวจ
   - ลดหย่อนแบบเลือกสรร

4. ลดหย่อนพิเศษ (Special Discount)
   - ลดหย่อนตามโครงการ CSR
   - ลดหย่อนสำหรับกรณีพิเศษ

การขออนุมัติลดหย่อน:

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

Process:
- ตรวจสอบสิทธิ์ในการขออนุมัติ
- ส่งคำขอตาม Workflow ที่กำหนด
- บันทึกประวัติการขออนุมัติ
- คำนวณยอดหลังลดหย่อน

Output:
- สถานะการอนุมัติ
- ยอดเงินหลังลดหย่อน
- เอกสารการอนุมัติลดหย่อน

3.1.3 การจัดการจุดรับชำระเงิน (FR-03)

3.1.3.1 การกำหนดจุดรับชำระเงิน

คำอธิบาย: ระบบต้องสามารถจัดการจุดรับชำระเงินหลายจุดได้

ประเภทจุดรับชำระเงิน:

1. จุดรับชำระหลัก (Main Cashier)
   - จุดรับชำระหลักของโรงพยาบาล
   - รับชำระเงินทุกประเภท

2. จุดรับชำระแผนก (Department Cashier)
   - จุดรับชำระในแผนกต่างๆ
   - รับชำระเฉพาะบริการของแผนก

3. จุดรับชำระฉุกเฉิน (Emergency Cashier)
   - จุดรับชำระในห้องฉุกเฉิน
   - เปิดบริการ 24 ชั่วโมง

4. จุดรับชำระเคลื่อนที่ (Mobile Cashier)
   - จุดรับชำระด้วยอุปกรณ์เคลื่อนที่
   - สำหรับบริการนอกสถานที่

การตั้งค่าจุดรับชำระเงิน:

Input:
- รหัสจุดรับชำระเงิน
- ชื่อจุดรับชำระเงิน
- ที่ตั้ง/แผนก
- ประเภทการรับชำระที่รองรับ
- เวลาทำการ
- ผู้รับผิดชอบ

Process:
- สร้างข้อมูลจุดรับชำระเงิน
- กำหนดสิทธิ์การใช้งาน
- เชื่อมโยงกับอุปกรณ์ (เครื่องพิมพ์, ลิ้นชัก)
- ตั้งค่าการปิดรอบรายวัน

Output:
- ข้อมูลจุดรับชำระเงินในระบบ
- การเชื่อมโยงกับผู้ใช้งาน
- การตั้งค่าอุปกรณ์ประกอบ

3.2 กลุ่มฟังก์ชัน Payment Processing

3.2.1 การรับชำระเงินผู้ป่วยนอก (FR-04)

3.2.1.1 การแสดงรายการค่ารักษา

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

การดึงข้อมูลค่ารักษา:

Input: HN ผู้ป่วย, วันที่ที่ต้องการ
Process: 
1. ดึงข้อมูลการส่งตรวจจากระบบต่างๆ
   - ระบบห้องตรวจแพทย์ (1.2.3)
   - ระบบชันสูตร (1.2.7) 
   - ระบบรังสีวิทยา (1.2.8)
   - ระบบเภสัชกรรม (1.2.13)
2. รวมรายการค่าใช้จ่ายทั้งหมด
3. คำนวณตามสิทธิและส่วนลด
4. แสดงผลรายการแยกตามหมวด

Output: รายการค่ารักษาแยกตามหมวดพร้อมยอดรวม

รายการที่แสดง:

ข้อมูลผู้ป่วย:
  - HN: หมายเลขผู้ป่วย
  - ชื่อ-สกุล: ชื่อผู้ป่วย
  - สิทธิการรักษา: สิทธิที่ใช้
  - วันที่มารับบริการ: วันที่ล่าสุด

รายการค่ารักษา:
  ค่าตรวจรักษา:
    - จำนวน: จำนวนครั้ง
    - ราคาต่อหน่วย: ราคาที่กำหนด
    - ยอดรวม: จำนวน × ราคา
    - ส่วนลด: เปอร์เซ็นต์ลด
    - ยอดสุทธิ: ยอดหลังหักส่วนลด

  ค่ายา:
    - รายการยา: ชื่อยาและจำนวน
    - ราคายา: ราคาตามรายการ
    - ส่วนลดยา: ส่วนลดสำหรับยา

  ค่าตรวจทางห้องปฏิบัติการ:
    - รายการตรวจ: ชื่อการตรวจ
    - ราคาตรวจ: ราคาแต่ละรายการ

  ค่าตรวจเอกซเรย์:
    - รายการเอกซเรย์: ชื่อการถ่าย
    - ราคาถ่าย: ราคาแต่ละรายการ

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

3.2.1.2 การรองรับการใช้หลายสิทธิ

คำอธิบาย: ระบบต้องรองรับให้ผู้ป่วย 1 รายใช้สิทธิได้มากกว่า 1 สิทธิต่อการมา visit 1 ครั้ง

การเลือกใช้หลายสิทธิ:

Scenario: ผู้ป่วยมีทั้งสิทธิ UC และ สิทธิข้าราชการ

Input:
- สิทธิหลัก: UC (30 บาท)
- สิทธิรอง: ข้าราชการ (จ่ายเต็ม แล้วเบิกคืน)

Process:
1. แยกรายการค่ารักษาตามประเภท
2. คำนวณแต่ละสิทธิตามผังการคิดค่าบริการ
3. เลือกการใช้สิทธิที่คุ้มค่าที่สุด
4. หรือให้ผู้ป่วยเลือกการใช้สิทธิเอง

Output:
- การแบ่งค่ารักษาตามสิทธิ
- ยอดเงินที่ต้องชำระแยกตามสิทธิ
- ใบเสร็จแยกตามสิทธิ (ถ้าจำเป็น)

ตัวอย่างการใช้หลายสิทธิ:

ค่ารักษารวม: 2,500 บาท
├── ใช้สิทธิ UC: 1,500 บาท (จ่าย 30 บาท)
├── ใช้สิทธิข้าราชการ: 1,000 บาท (จ่ายเต็ม แล้วเบิกคืน)
└── ยอดที่ผู้ป่วยจ่าย: 1,030 บาท

3.2.1.3 การรับชำระเงินหลายรูปแบบ

คำอธิบาย: ระบบต้องรองรับการรับชำระเงินหลายรูปแบบ (Payment Method)

รูปแบบการชำระเงิน:

เงินสด (Cash):
  - รับชำระด้วยเงินสด
  - คำนวณเงินทอนอัตโนมัติ
  - ตรวจสอบธนบัตรปลอม

บัตรเครดิต/เดบิต (Credit/Debit Card):
  - เชื่อมต่อกับ EDC Terminal
  - รองรับ Visa, MasterCard, JCB
  - มีการตรวจสอบ PIN

เงินโอน (Bank Transfer):
  - ตรวจสอบสลิปการโอนเงิน
  - เชื่อมต่อกับระบบธนาคาร (API)
  - บันทึกข้อมูลการโอน

QR Code Payment:
  - รองรับ PromptPay
  - รองรับ True Money Wallet
  - รองรับ Rabbit LINE Pay

เงินรับฝาก (Deposit):
  - หักจากเงินมัดจำที่มีอยู่
  - แสดงยอดคงเหลือหลังหัก

หักบัญชีสิทธิ (Rights Deduction):
  - หักจากสิทธิโดยตรง (เช่น สิทธิ UC)
  - ไม่มีการรับเงินสด

การรับชำระแบบผสม (Mixed Payment):

ตัวอย่าง: ยอดที่ต้องชำระ 1,500 บาท
├── เงินสด: 1,000 บาท
├── บัตรเครดิต: 500 บาท
└── รวม: 1,500 บาท

การบันทึก:
- บันทึกการรับชำระแยกตามประเภท
- ออกใบเสร็จรวม 1 ใบ
- ระบุวิธีการชำระในใบเสร็จ

3.2.2 การรับชำระเงินผู้ป่วยใน (FR-05)

3.2.2.1 การจัดการเงินรับฝาก (Deposit)

คำอธิบาย: ระบบต้องรองรับเงินรับฝากจากผู้ป่วยได้

การรับฝากเงิน:

Input:
- HN ผู้ป่วยใน (AN)
- วันที่รับฝากเงิน
- เวลาที่รับฝากเงิน
- ชื่อผู้ฝากเงิน (อาจไม่ใช่ผู้ป่วย)
- จำนวนเงินที่ฝาก
- วิธีการฝากเงิน (เงินสด/โอน)
- หมายเหตุ

Process:
- บันทึกข้อมูลการรับฝากเงิน
- ออกใบรับฝากเงิน (มัดจำ)
- อัพเดทยอดเงินรับฝากของผู้ป่วย
- บันทึก Log การทำรายการ

Output:
- ใบรับฝากเงิน (มัดจำ)
- ยอดเงินรับฝากปัจจุบัน
- ประวัติการรับฝากเงิน

การใช้เงินรับฝาก:

Input:
- HN ผู้ป่วยใน
- ยอดค่ารักษาที่ต้องหัก
- ประเภทค่ารักษา

Process:
- ตรวจสอบยอดเงินรับฝากคงเหลือ
- หักเงินจากยอดรับฝาก
- บันทึกรายการการใช้เงิน
- อัพเดทยอดคงเหลือ

Output:
- ยอดที่หักจากเงินรับฝาก
- ยอดเงินรับฝากคงเหลือ
- รายการการใช้เงินรับฝาก

3.2.2.2 การแจ้งเรียกเก็บเงิน (Billing)

คำอธิบาย: ระบบต้องสามารถออกใบแจ้งเรียกเก็บเงินสำหรับผู้ป่วยใน

การสร้างใบแจ้งเรียกเก็บเงิน:

Input:
- AN ผู้ป่วยใน
- ช่วงวันที่ต้องการ
- ประเภทการแจ้งเรียกเก็บ (รายวัน/รายสัปดาห์/จำหน่าย)

Process:
1. รวบรวมค่ารักษาจากระบบต่างๆ
   - ค่าห้องและอาหาร (รายวัน)
   - ค่าการพยาบาล
   - ค่าแพทย์
   - ค่ายาและเวชภัณฑ์
   - ค่าตรวจทางห้องปฏิบัติการ
   - ค่าตรวจเอกซเรย์
   - ค่าห้องผ่าตัด
   - ค่าหัตถการ
   - ค่าบริการอื่นๆ

2. คำนวณตามสิทธิและส่วนลด
3. หักเงินรับฝาก (ถ้ามี)
4. คำนวณยอดคงเหลือที่ต้องชำระ

Output:
- ใบแจ้งเรียกเก็บเงิน (ภาษาไทย/อังกฤษ)
- รายการค่าใช้จ่ายโดยละเอียด
- ยอดเงินรับฝากที่ใช้
- ยอดที่ต้องชำระเพิ่ม

3.2.2.3 การปิดบิลผู้ป่วยใน (Discharge Billing)

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

การปิดบิลผู้ป่วยใน:

Input:
- AN ผู้ป่วยใน
- วันที่จำหน่าย
- เวลาจำหน่าย

Process:
1. รวบรวมค่ารักษาทั้งหมด (วันแรกเข้า-วันจำหน่าย)
2. คำนวณค่าห้องตามเวลาจำหน่าย
3. รวมค่ายาและเวชภัณฑ์ที่ใช้
4. รวมค่าตรวจและหัตถการทั้งหมด
5. คำนวณตามสิทธิและส่วนลด
6. หักเงินรับฝากทั้งหมด
7. คำนวณยอดสุดท้ายที่ต้องชำระ/คืน

Output:
- ใบสรุปหน้างบ (Final Bill)
- ใบรายการค่าใช้จ่ายทั้งหมด
- ยอดเงินที่ต้องชำระเพิ่ม หรือ ยอดเงินที่ต้องคืน
- ใบเสร็จรับเงินขั้นสุดท้าย

3.3 กลุ่มฟังก์ชัน Document Management

3.3.1 การออกใบเสร็จรับเงิน (FR-06)

3.3.1.1 การออกใบเสร็จรับเงิน

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

ข้อมูลในใบเสร็จรับเงิน:

Header:
  - ชื่อโรงพยาบาล: โรงพยาบาลค่ายธนรัชน์
  - ที่อยู่โรงพยาบาล: ที่อยู่ครบถ้วน
  - เลขประจำตัวผู้เสียภาษี: เลขที่ของโรงพยาบาล
  - เลขที่ใบเสร็จ: เลขรันนิ่งอัตโนมัติ
  - วันที่-เวลา: วันเวลาที่ออกใบเสร็จ

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

รายการค่ารักษา:
  - รายการค่าใช้จ่าย: รายละเอียดแต่ละหมวด
  - จำนวน: จำนวนครั้ง/หน่วย
  - ราคาต่อหน่วย: ราคาที่กำหนด
  - ยอดรวม: จำนวน × ราคา
  - ส่วนลด: ส่วนลดที่ได้รับ
  - ยอดสุทธิ: ยอดหลังหักส่วนลด

การชำระเงิน:
  - วิธีการชำระ: เงินสด/บัตร/โอน
  - ยอดที่รับ: จำนวนเงินที่ได้รับ
  - เงินทอน: เงินทอน (ถ้ามี)

Footer:
  - ลายเซ็นผู้รับเงิน: ลายเซ็นเจ้าหน้าที่
  - จุดรับชำระเงิน: จุดที่รับชำระ
  - เครื่องพิมพ์: เครื่องที่พิมพ์ใบเสร็จ

3.3.1.2 การควบคุมเลขที่ใบเสร็จ

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

รูปแบบเลขที่ใบเสร็จ:

รูปแบบที่ 1: YYYY-MM-DD-NNNNNN
ตัวอย่าง: 2568-10-08-000001

รูปแบบที่ 2: CC-YYYY-NNNNNN  
ตัวอย่าง: 01-2568-000001 (CC = รหัสจุดรับชำระ)

รูปแบบที่ 3: YYYY-CC-NNNNNN
ตัวอย่าง: 2568-01-000001

การตั้งค่า:
- กำหนดรูปแบบตามต้องการ
- กำหนดจำนวนหลักของ Running Number
- กำหนดการรีเซ็ตรายวัน/รายเดือน/รายปี
- กำหนดเลขเริ่มต้น

การควบคุมการออกเลขที่:

Input: การขอออกเลขที่ใบเสร็จใหม่
Process:
1. ตรวจสอบรูปแบบที่กำหนด
2. ดึง Running Number ล่าสุด
3. เพิ่มหมายเลขถัดไป
4. ตรวจสอบความซ้ำซ้อน
5. ล็อคเลขที่เพื่อป้องกันการซ้ำ
6. อัพเดท Running Number

Output:
- เลขที่ใบเสร็จที่ได้รับมอบหมาย
- การบันทึกการใช้เลขที่
- ประวัติการออกเลขที่

3.3.2 การออกใบแจ้งหนี้ (FR-07)

3.3.2.1 การออกใบแจ้งหนี้

คำอธิบาย: ระบบต้องสามารถออกใบแจ้งหนี้ (Invoice) สำหรับค่ารักษาพยาบาล

ประเภทใบแจ้งหนี้:

1. ใบแจ้งหนี้ผู้ป่วยนอก (OPD Invoice)
   - แจ้งหนี้สำหรับค่ารักษาผู้ป่วยนอก
   - รายการตามการใช้บริการ

2. ใบแจ้งหนี้ผู้ป่วยใน (IPD Invoice) 
   - แจ้งหนี้สำหรับค่ารักษาผู้ป่วยใน
   - รายการรวมตั้งแต่เข้า-จำหน่าย

3. ใบแจ้งหนี้สิทธิ (Rights Invoice)
   - แจ้งหนี้ไปยังหน่วยงานที่จ่ายสิทธิ
   - เช่น สปสช., สนย., กรมบัญชีกลาง

4. ใบแจ้งหนี้บริษัทประกัน (Insurance Invoice)
   - แจ้งหนี้ไปยังบริษัทประกันภัย
   - สำหรับผู้ป่วยที่มีประกันเพิ่มเติม

การออกใบแจ้งหนี้:

Input:
- ประเภทใบแจ้งหนี้
- ข้อมูลผู้เรียกเก็บ (ผู้ป่วย/สิทธิ/บริษัท)
- รายการค่ารักษา
- ช่วงวันที่

Process:
1. รวบรวมรายการค่ารักษา
2. คำนวณตามเงื่อนไขของแต่ละประเภท
3. จัดรูปแบบใบแจ้งหนี้
4. สร้างเลขที่ใบแจ้งหนี้
5. บันทึกประวัติการออกใบแจ้งหนี้

Output:
- ใบแจ้งหนี้ตามรูปแบบที่กำหนด
- เลขที่ใบแจ้งหนี้
- สถานะการแจ้งหนี้ (ออกแล้ว/รอชำระ/ชำระแล้ว)

3.3.3 การพิมพ์เอกสารอื่นๆ (FR-08)

3.3.3.1 การพิมพ์ใบสั่งยา

คำอธิบาย: ระบบต้องสามารถพิมพ์ใบสั่งยาในรูปแบบภาษาไทยและภาษาอังกฤษ

ข้อมูลในใบสั่งยา:

Header:
  - ชื่อโรงพยาบาล
  - แผนกที่สั่งยา
  - วันที่-เวลาที่สั่ง

ข้อมูลผู้ป่วย:
  - HN และ ชื่อ-สกุล
  - อายุ และ น้ำหนัก
  - สิทธิการรักษา
  - แพทย์ผู้สั่งยา

รายการยา:
  - ลำดับที่
  - ชื่อยา (ภาษาไทย/อังกฤษ)
  - ความแรง (Strength)
  - จำนวน (Quantity)
  - วิธีใช้ (Direction)
  - ราคา (ถ้าต้องการ)

Footer:
  - ลายเซ็นแพทย์ผู้สั่ง
  - ลายเซ็นเภสัชกร
  - หมายเหตุพิเศษ

3.3.3.2 การพิมพ์เอกสารทางการเงิน

คำอธิบาย: ระบบต้องสามารถพิมพ์เอกสารทางการเงินต่างๆ

เอกสารที่รองรับ:

1. ใบรับฝากเงิน (Deposit Receipt)
   - ใบรับเงินมัดจำ
   - แสดงยอดเงินรับฝาก

2. ใบสรุปหน้างบ (Summary Bill)
   - สรุปค่ารักษาผู้ป่วยใน
   - แสดงรายการละเอียด

3. ใบรายการค่าใช้จ่ายทั้งหมด (Detailed Bill)
   - รายการค่าใช้จ่ายครบถ้วน
   - แยกตามวันที่และประเภท

4. ใบนำส่งเงินรายได้ (Daily Collection)
   - สรุปเงินรายได้รายวัน
   - แยกตามจุดรับชำระเงิน

5. ใบยกเลิกใบเสร็จ (Void Receipt)
   - เอกสารยกเลิกใบเสร็จ
   - ระบุเหตุผลการยกเลิก

จะทำต่อในส่วนถัดไป...

3.4 กลุ่มฟังก์ชัน Outstanding Management

3.4.1 การจัดการค้างชำระ (FR-09)

3.4.1.1 การบันทึกยอดค้างชำระ

คำอธิบาย: ระบบต้องรองรับการบันทึกยอดค้างชำระได้

การสร้างยอดค้างชำระ:

Input:
- HN ผู้ป่วย
- ยอดเงินที่ค้างชำระ
- ประเภทการค้างชำระ:
  * ค้างชำระปกติ (ผู้ป่วยขาดเงิน)
  * ค้างชำระเพื่อรอเอกสาร (รอใบรับรองแพทย์)
  * ค้างชำระเพื่อรอการอนุมัติ (รออนุมัติลดหย่อน)
- เหตุผลการค้างชำระ
- วันที่ครบกำหนดชำระ

Process:
1. บันทึกข้อมูลการค้างชำระ
2. กำหนดสถานะการค้างชำระ
3. ตั้งค่าการแจ้งเตือน
4. ออกเอกสารการค้างชำระ

Output:
- รายการค้างชำระในระบบ
- ใบแจ้งการค้างชำระ
- การตั้งค่าการแจ้งเตือน

3.4.1.2 การแจ้งเตือนค้างชำระ

คำอธิบาย: ระบบต้องแจ้งเตือนเมื่อผู้ป่วยที่ค้างชำระมารับบริการครั้งต่อไป

การแจ้งเตือนอัตโนมัติ:

Trigger: ผู้ป่วยที่มียอดค้างชำระมาลงทะเบียนใหม่

Process:
1. ตรวจสอบยอดค้างชำระจาก HN
2. แสดง Pop-up แจ้งเตือนในระบบลงทะเบียน
3. แสดงรายละเอียดการค้างชำระ:
   - วันที่ค้างชำระ
   - ยอดเงินที่ค้าง
   - เหตุผลการค้างชำระ
   - จำนวนวันที่ค้าง
4. ตัวเลือกการดำเนินการ:
   - รับชำระเงินทันที
   - ผ่อนผันการชำระ
   - ส่งต่อแผนกการเงิน

Alert Message:
"⚠️ ผู้ป่วยท่านนี้มียอดค้างชำระ 1,500 บาท 
วันที่ค้าง: 25 ก.ย. 2568 (ค้างมาแล้ว 13 วัน)
เหตุผล: รอเอกสารเบิกจากสิทธิ UC"

3.4.1.3 การรับชำระหนี้ค้าง

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

การรับชำระหนี้ค้าง:

Input:
- HN ผู้ป่วย
- รายการค้างชำระที่ต้องการชำระ
- ยอดเงินที่รับชำระ
- วิธีการชำระเงิน

Process:
1. แสดงรายการค้างชำระทั้งหมด
2. เลือกรายการที่ต้องการชำระ
3. คำนวณยอดหลังลดหย่อน (ถ้ามี)
4. รับชำระเงิน
5. อัพเดทสถานะการค้างชำระ
6. ออกใบเสร็จรับเงิน

Output:
- ใบเสร็จรับเงินค้างชำระ
- อัพเดทยอดค้างชำระคงเหลือ
- ประวัติการรับชำระหนี้ค้าง

3.4.2 การขออนุมัติลดหย่อนและยกเว้น (FR-10)

3.4.2.1 ระบบ Workflow การขออนุมัติ

คำอธิบาย: ระบบต้องมี Workflow สำหรับการขออนุมัติลดหย่อนและยกเว้นค่ารักษา

ระดับการอนุมัติ:

ระดับ 1 - หัวหน้าแผนกการเงิน:
  สามารถอนุมัติ:
    - ลดหย่อน 10-30%
    - ยอดไม่เกิน 5,000 บาท
    - ยกเว้นค่าธรรมเนียมเล็กน้อย

ระดับ 2 - รองผู้อำนวยการ:
  สามารถอนุมัติ:
    - ลดหย่อน 30-50%
    - ยอดไม่เกิน 20,000 บาท
    - ยกเว้นบางหมวดค่ารักษา

ระดับ 3 - ผู้อำนวยการ:
  สามารถอนุมัติ:
    - ลดหย่อน 50-100%
    - ยอดเท่าไรก็ได้
    - ยกเว้นค่ารักษาทั้งหมด

กรณีพิเศษ - คณะกรรมการ:
  สำหรับกรณีที่:
    - ยอดสูงมาก (เกิน 100,000 บาท)
    - กรณีประชาสัมพันธ์
    - กรณีภัยพิบัติ

การส่งคำขออนุมัติ:

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

Process:
1. ตรวจสอบสิทธิ์ในการขออนุมัติ
2. กำหนดระดับการอนุมัติตามยอดเงิน
3. ส่งคำขอไปยังผู้มีอำนาจ
4. แจ้งเตือนผู้อนุมัติทาง Email/SMS
5. ติดตามสถานะการอนุมัติ

Output:
- เลขที่คำขออนุมัติ
- สถานะการอนุมัติ (รอพิจารณา/อนุมัติ/ไม่อนุมัติ)
- ประวัติการขออนุมัติ

3.4.2.2 การอนุมัติและปฏิเสธ

คำอธิบาย: ระบบต้องรองรับการอนุมัติและปฏิเสธคำขอลดหย่อน

การอนุมัติคำขอ:

Input:
- เลขที่คำขออนุมัติ
- ผลการพิจารณา (อนุมัติ/ไม่อนุมัติ/อนุมัติบางส่วน)
- ยอดที่อนุมัติ (กรณีอนุมัติบางส่วน)
- หมายเหตุของผู้อนุมัติ

Process:
1. บันทึกผลการอนุมัติ
2. อัพเดทยอดค่ารักษาตามการอนุมัติ
3. แจ้งผลกลับไปยังผู้ขออนุมัติ
4. สร้างเอกสารการอนุมัติ
5. อัพเดทสถานะการค้างชำระ (ถ้ามี)

Output:
- เอกสารการอนุมัติ
- การปรับยอดค่ารักษา
- การแจ้งผลไปยังผู้เกี่ยวข้อง

3.5 กลุ่มฟังก์ชัน Document Cancellation & Correction

3.5.1 การยกเลิกการรับชำระเงิน (FR-11)

3.5.1.1 การยกเลิกใบเสร็จรับเงิน

คำอธิบาย: ระบบต้องสามารถยกเลิกใบเสร็จรับเงินโดยระบุสาเหตุของการยกเลิกได้

เหตุผลการยกเลิก:

1. ผิดพลาดในการบันทึกข้อมูล
   - ผิดยอดเงิน
   - ผิดรายการค่ารักษา
   - ผิดชื่อผู้ป่วย

2. ผู้ป่วยขอเปลี่ยนวิธีการชำระเงิน
   - เปลี่ยนจากเงินสดเป็นบัตรเครดิต
   - เปลี่ยนจากบัตรเป็นเงินโอน

3. มีการปรับลดค่ารักษาภายหลัง
   - ได้รับอนุมัติลดหย่อน
   - พบข้อผิดพลาดในการคิดราคา

4. เหตุผลอื่นๆ
   - ผู้ป่วยไม่มารับยา
   - การยกเลิกการรักษา

การยกเลิกใบเสร็จ:

Input:
- เลขที่ใบเสร็จที่ต้องการยกเลิก
- เหตุผลการยกเลิก
- หลักฐานประกอบ (ถ้าจำเป็น)
- ผู้ขออนุมัติยกเลิก

Process:
1. ตรวจสอบสิทธิ์ในการยกเลิก
2. ตรวจสอบสถานะใบเสร็จ (ยกเลิกได้/ไม่ได้)
3. บันทึกข้อมูลการยกเลิก:
   - วันที่ยกเลิก
   - เวลาที่ยกเลิก
   - HN และชื่อ-สกุลผู้ป่วย
   - เลขที่ใบเสร็จที่ยกเลิก
   - จำนวนเงินที่ยกเลิก
   - เจ้าหน้าที่ที่ทำการยกเลิก
   - สาเหตุของการยกเลิก
4. สร้างเอกสารยกเลิก
5. อัพเดทสถานะใบเสร็จ

Output:
- ใบยกเลิกใบเสร็จ
- การคืนเงินให้ผู้ป่วย (ถ้าจำเป็น)
- บันทึกประวัติการยกเลิก

3.5.1.2 การสร้างเอกสารใหม่หลังยกเลิก

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

การสร้างเอกสารใหม่:

Input:
- ข้อมูลใบเสร็จที่ถูกยกเลิก
- ข้อมูลที่แก้ไขใหม่
- เหตุผลการสร้างใหม่

Process:
1. สร้างเลขที่ใบเสร็จใหม่
2. บันทึกข้อมูลที่แก้ไขแล้ว
3. เชื่อมโยงระหว่างเอกสารเก่าและใหม่:
   - ใบเสร็จเก่า: 2568-10-08-000001 (ยกเลิก)
   - ใบเสร็จใหม่: 2568-10-08-000025 (แทนที่ 000001)
4. บันทึกประวัติการเชื่อมโยง
5. ออกใบเสร็จใหม่

Output:
- ใบเสร็จที่มีเลขที่ใหม่
- การเชื่อมโยงระหว่างเอกสารเก่า-ใหม่
- ประวัติการแก้ไข

3.5.1.3 การสอบถามประวัติใบเสร็จ

คำอธิบาย: ระบบต้องสามารถสอบถามได้ว่าใบเสร็จถูกพิมพ์ออกจากจุดรับชำระเงินใดและใครเป็นผู้ทำรายการ

การสอบถามประวัติ:

Input:
- เลขที่ใบเสร็จ
- ช่วงวันที่ (ถ้าต้องการ)
- จุดรับชำระเงิน (ถ้าต้องการ)

Process:
1. ค้นหาข้อมูลใบเสร็จจากฐานข้อมูล
2. ดึงข้อมูลประวัติการทำรายการ

Output:
├── ข้อมูลใบเสร็จ:
│   ├── เลขที่ใบเสร็จ
│   ├── วันที่-เวลาที่ออกใบเสร็จ
│   ├── ชื่อผู้ป่วย
│   └── ยอดเงิน
├── ข้อมูลการทำรายการ:
│   ├── จุดรับชำระเงิน
│   ├── เจ้าหน้าที่ที่ทำรายการ
│   ├── เครื่องคอมพิวเตอร์ที่ใช้
│   └── เครื่องพิมพ์ที่ใช้
└── ประวัติการเปลี่ยนแปลง:
    ├── การยกเลิก (ถ้ามี)
    ├── การแก้ไข (ถ้ามี)  
    └── การเชื่อมโยงเอกสาร (ถ้ามี)

3.6 กลุ่มฟังก์ชัน Financial Closing & Reporting

3.6.1 การปิดรอบการเงิน (FR-12)

3.6.1.1 การปิดยอดรายวัน

คำอธิบาย: ระบบต้องสามารถทำการปิดยอดรายการที่เกิดขึ้นและประมวลผลเพื่อสรุปยอดเงินตามช่วงเวลา

การปิดยอดรายวัน:

Input:
- วันที่ที่ต้องการปิดยอด
- จุดรับชำระเงิน (เฉพาะจุด/ทุกจุด)
- ผู้ทำการปิดยอด

Process:
1. รวบรวมรายการรับชำระเงินทั้งหมดในวัน
2. แยกตามประเภทการรับชำระเงิน:
   - เงินสด
   - บัตรเครดิต/เดบิต
   - เงินโอน
   - QR Code Payment
   - เงินรับฝาก
   - หักบัญชีสิทธิ
3. คำนวณยอดรวมแต่ละประเภท
4. ตรวจสอบยอดเงินสดที่นับได้กับยอดในระบบ
5. บันทึกผลต่างเงินสด (ถ้ามี)
6. สร้างรายงานสรุปยอดรายวัน

Output:
- รายงานสรุปยอดรายวัน
- ใบนำส่งเงินรายได้
- บันทึกผลต่างเงินสด
- การล็อคข้อมูลรายวัน (ไม่สามารถแก้ไขได้)

รายงานสรุปยอดรายวัน:

Header:
  - วันที่ปิดยอด: 8 ตุลาคม 2568
  - จุดรับชำระเงิน: จุดรับชำระหลัก
  - ผู้ทำการปิดยอด: นางสาวสมศรี ใจดี
  - เวลาปิดยอด: 23:45 น.

รายได้แยกตามประเภทการรับชำระ:
  เงินสด:
    - จำนวนรายการ: 125 รายการ
    - ยอดเงิน: 45,750 บาท

  บัตรเครดิต/เดบิต:
    - จำนวนรายการ: 87 รายการ  
    - ยอดเงิน: 156,840 บาท

  เงินโอน:
    - จำนวนรายการ: 23 รายการ
    - ยอดเงิน: 34,200 บาท

  QR Code Payment:
    - จำนวนรายการ: 45 รายการ
    - ยอดเงิน: 12,580 บาท

รายได้แยกตามหมวดค่ารักษา:
  ค่าตรวจรักษา: 89,450 บาท
  ค่ายา: 67,320 บาท
  ค่าตรวจทางห้องปฏิบัติการ: 45,600 บาท
  ค่าตรวจเอกซเรย์: 23,400 บาท
  ค่าหัตถการ: 23,600 บาท

รายได้แยกตามสิทธิ:
  สิทธิ UC: 156,780 บาท
  สิทธิประกันสังคม: 89,450 บาท
  สิทธิข้าราชการ: 34,560 บาท
  สิทธิเบิกตนเอง: 15,480 บาท

การนับเงินสด:
  - ยอดตามระบบ: 45,750 บาท
  - ยอดที่นับได้: 45,720 บาท
  - ผลต่าง: -30 บาท (ขาด)

สรุปรวม:
  - ยอดรายได้รวม: 249,370 บาท
  - จำนวนรายการรวม: 280 รายการ
  - ยอดเงินสดนำส่ง: 45,720 บาท

3.6.1.2 การสอบถามสรุปยอดเงิน

คำอธิบาย: ระบบต้องสามารถสอบถามสรุปยอดเงินได้ตามเงื่อนไขต่างๆ

การสอบถามแบบหลายเงื่อนไข:

Input:
- ช่วงวันที่: จาก-ถึง
- จุดรับชำระเงิน: เฉพาะจุด/ทุกจุด
- ประเภทสิทธิการรักษา: เฉพาะสิทธิ/ทุกสิทธิ
- หน่วยงานที่ให้บริการ: เฉพาะแผนก/ทุกแผนก
- รายการค่ารักษา: เฉพาะหมวด/ทุกหมวด

Process:
1. ดึงข้อมูลตามเงื่อนไขที่กำหนด
2. จัดกลุ่มและสรุปข้อมูล
3. สร้างรายงานตามรูปแบบที่เลือก

Output:
- รายงานสรุปตามเงื่อนไข
- การเปรียบเทียบระหว่างช่วงเวลา
- กราฟแสดงแนวโน้ม (ถ้าต้องการ)

3.6.1.3 การสอบถามยอดรายบุคคล

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

การสอบถามรายบุคคล:

Input:
- HN ผู้ป่วย
- ช่วงวันที่ที่ต้องการ
- ประเภทการรับชำระเงิน

Process:
1. ดึงประวัติการรักษาของผู้ป่วย
2. รวบรวมค่ารักษาตามช่วงเวลา
3. แยกตามประเภทการรับชำระ
4. คำนวณยอดรวมและสรุป

Output:
├── ข้อมูลผู้ป่วย:
│   ├── HN: หมายเลขผู้ป่วย
│   ├── ชื่อ-สกุล: ชื่อผู้ป่วย
│   └── สิทธิหลัก: สิทธิที่ใช้บ่อย
├── สรุปการรักษา:
│   ├── จำนวนครั้งที่มารักษา
│   ├── ค่ารักษารวมทั้งหมด
│   └── ค่ารักษาเฉลี่ยต่อครั้ง
└── รายละเอียดตามวันที่:
    ├── วันที่ 1: รายการและยอดเงิน
    ├── วันที่ 2: รายการและยอดเงิน
    └── ...

3.6.2 การรายงานการเงิน (FR-13)

3.6.2.1 รายงานสำหรับฝ่ายบริหาร

คำอธิบาย: ระบบต้องสร้างรายงานการเงินสำหรับฝ่ายบริหารได้

รายงานยอดรายได้รายวัน:

รายงานรายได้ประจำวัน:
  วันที่: 8 ตุลาคม 2568

  สรุปภาพรวม:
    - รายได้รวม: 249,370 บาท
    - จำนวนผู้ป่วย: 280 ราย
    - รายได้เฉลี่ยต่อหัว: 891 บาท
    - เปรียบเทียบเมื่อวาน: +12.5%

  รายได้แยกตามแผนก:
    - แผนกอายุรกรรม: 89,450 บาท (35.9%)
    - แผนกศัลยกรรม: 67,320 บาท (27.0%)
    - แผนกฉุกเฉิน: 45,600 บาท (18.3%)
    - แผนกทันตกรรม: 23,400 บาท (9.4%)
    - แผนกอื่นๆ: 23,600 บาท (9.5%)

  รายได้แยกตามสิทธิ:
    - สิทธิ UC: 156,780 บาท (62.9%)
    - สิทธิประกันสังคม: 89,450 บาท (35.9%)
    - สิทธิข้าราชการ: 3,140 บาท (1.3%)

  แนวโน้ม 7 วันล่าสุด:
    - วันนี้: 249,370 บาท
    - เมื่อวาน: 221,580 บาท
    - 2 วันก่อน: 234,120 บาท
    - ...

รายงานค้างชำระ:

รายงานยอดค้างชำระ:
  ณ วันที่: 8 ตุลาคม 2568

  สรุปภาพรวม:
    - ยอดค้างชำระรวม: 125,680 บาท
    - จำนวนผู้ป่วยที่ค้าง: 45 ราย
    - ยอดค้างเฉลี่ย: 2,793 บาท

  แยกตามอายุหนี้:
    - ค้าง 1-7 วัน: 45,680 บาท (23 ราย)
    - ค้าง 8-30 วัน: 56,780 บาท (15 ราย)
    - ค้าง 31-90 วัน: 18,220 บาท (5 ราย)
    - ค้าง >90 วัน: 5,000 บาท (2 ราย)

  แยกตามสาเหตุ:
    - รอเอกสารเบิก: 78,450 บาท (62.4%)
    - ขาดแคลนเงิน: 34,230 บาท (27.2%)
    - รออนุมัติลดหย่อน: 13,000 บาท (10.3%)

3.6.2.2 รายงานสำหรับหน่วยงานภายนอก

คำอธิบาย: ระบบต้องสร้างรายงานส่งให้หน่วยงานภายนอกได้

รายงาน 43 แฟ้ม (สปสช.):

รายงานข้อมูลการรักษาตาม 43 แฟ้มของ สปสช.
ประจำเดือน ตุลาคม 2568

แฟ้มที่ 1: ข้อมูลหน่วยบริการ
- รหัสหน่วยบริการ: 11677
- ชื่อหน่วยบริการ: โรงพยาบาลค่ายธนรัชน์
- ระดับหน่วยบริการ: F2

แฟ้มที่ 2: ข้อมูลบุคลากร
- จำนวนแพทย์: 25 คน
- จำนวนพยาบาล: 85 คน
- จำนวนเภสัชกร: 3 คน

แฟ้มที่ 3: ข้อมูลผู้ป่วยนอก
- จำนวนผู้ป่วยนอก: 8,456 ราย
- จำนวน Visit: 12,340 ครั้ง
- ค่ารักษาเฉลี่ย: 891 บาท/ครั้ง

... (ข้อมูลครบ 43 แฟ้ม)

จะทำส่วนต่อไปในข้อความถัดไป...

---

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

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

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

• หน้าจอต้องมีการออกแบบที่ใช้งานง่าย เหมาะกับสภาพการทำงานของเจ้าหน้าที่การเงิน
• รองรับการใช้งานผ่านเว็บเบราว์เซอร์และแอปพลิเคชันเฉพาะ
• มีระบบแจ้งเตือนและ Pop-up สำหรับข้อมูลสำคัญ (ค้างชำระ, การอนุมัติ)
• รองรับการใช้งานด้วยแป้นพิมพ์, เมาส์, และ Touch Screen
• หน้าจอต้องปรับขนาดได้ตามความละเอียดของจอภาพ (1920x1080, 1366x768)
• รองรับการใช้งานภาษาไทยและอังกฤษ

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

• เครื่องพิมพ์ใบเสร็จ: Thermal Printer 80mm สำหรับพิมพ์ใบเสร็จรับเงิน
• เครื่องพิมพ์เอกสาร: Laser Printer A4 สำหรับพิมพ์รายงานและเอกสารทางการเงิน
• ลิ้นชักเก็บเงิน: Cash Drawer ที่เชื่อมต่อกับเครื่องพิมพ์ใบเสร็จ
• เครื่องอ่านบัตรเครดิต: EDC Terminal สำหรับการชำระด้วยบัตร
• เครื่องนับเงิน: Money Counter สำหรับนับเงินสดอัตโนมัติ
• เครื่องตรวจเงินปลอม: UV Detector และ Pen สำหรับตรวจสอบธนบัตร
• เครื่องสแกน QR Code: สำหรับรับชำระผ่าน PromptPay และ E-Wallet
• จอแสดงผลราคา: Customer Display สำหรับแสดงยอดเงินให้ผู้ป่วยเห็น

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

• ระบบฐานข้อมูล: SQL Server 2019+, MySQL 8.0+, หรือ PostgreSQL 13+
• ระบบปฏิบัติการ: Windows Server 2019+, Windows 10+, หรือ Linux
• Web Server: IIS 10+, Apache 2.4+, หรือ Nginx 1.18+
• ระบบสำรองข้อมูล: Windows Backup, SQL Server Backup, หรือ Third-party Backup
• Antivirus Software: ซอฟต์แวร์ป้องกันไวรัสระดับเซิร์ฟเวอร์และ Client
• ระบบรายงาน: Crystal Reports, SQL Server Reporting Services, หรือ JasperReports

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

• เชื่อมต่อกับระบบ HIS อื่นๆ: ผ่าน Web Services, REST API, หรือ Database Integration
• การส่งข้อมูลไปยังหน่วยงานภายนอก:
• สปสช. (NHSO) - ข้อมูล 43 แฟ้ม
• สนย. (SSO) - ข้อมูลประกันสังคม
• กรมบัญชีกลาง (CGD) - ข้อมูลข้าราชการ
• การแลกเปลี่ยนข้อมูลกับธนาคาร: API สำหรับตรวจสอบการชำระเงินและการโอนเงิน
• ระบบ Email: สำหรับส่งรายงานอัตโนมัติและการแจ้งเตือน
• ระบบ SMS: สำหรับแจ้งเตือนการค้างชำระและการอนุมัติ

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

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

• การค้นหาข้อมูลผู้ป่วย: ไม่เกิน 2 วินาที
• การแสดงรายการค่ารักษา: ไม่เกิน 3 วินาที
• การรับชำระเงินและออกใบเสร็จ: ไม่เกิน 5 วินาที
• การพิมพ์ใบเสร็จ: ไม่เกิน 3 วินาทีหลังจากกดปุ่มพิมพ์
• การโหลดรายงาน: ไม่เกิน 10 วินาทีสำหรับรายงานรายวัน
• การปิดรอบรายวัน: ไม่เกิน 30 นาทีสำหรับข้อมูลทั้งวัน

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

• ผู้ใช้งานพร้อมกัน: อย่างน้อย 200 คน (จุดรับชำระหลายจุด)
• รายการรับชำระเงินต่อวัน: อย่างน้อย 2,000 รายการ
• จำนวนใบเสร็จต่อปี: อย่างน้อย 500,000 ใบ
• ข้อมูลผู้ป่วยในระบบ: อย่างน้อย 500,000 ราย
• ประวัติการทำรายการ: เก็บข้อมูลย้อนหลัง 10 ปี

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

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

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

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

• ระบบ Login: Username และ Password พร้อม Multi-Factor Authentication (MFA)
• การกำหนดสิทธิ์: Role-based Access Control ตามตำแหน่งหน้าที่
• การล็อกออกอัตโนมัติ: เมื่อไม่ใช้งานเกิน 15 นาที (สำหรับเจ้าหน้าที่การเงิน)
• การเข้ารหัสข้อมูล: AES-256 สำหรับข้อมูลทางการเงินและข้อมูลส่วนบุคคล
• การจำกัดการเข้าถึง: ตาม IP Address และ MAC Address

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

• สำรองข้อมูลหลายระดับ: Local Backup, Network Backup, และ Cloud Backup
• การเก็บ Audit Logs: บันทึกการใช้งานและการแก้ไขข้อมูลทุกรายการ
• การป้องกันการเข้าถึงจากภายนอก: Firewall และ VPN
• การตรวจสอบความครบถ้วนของข้อมูล: Checksum และ Digital Signature
• การแจ้งเตือนความผิดปกติ: Real-time Monitoring และ Alert System

4.3.3 การปฏิบัติตามกฎหมาย

• PDPA Compliance: ปฏิบัติตามพระราชบัญญัติคุ้มครองข้อมูลส่วนบุคคล
• การเก็บข้อมูล: เก็บ Audit Logs และข้อมูลทางการเงินไม่น้อยกว่า 7 ปี
• สิทธิ์ของเจ้าของข้อมูล: รองรับการขอดู, แก้ไข, และลบข้อมูลส่วนบุคคล
• การแจ้งการละเมิดข้อมูล: ภายใน 72 ชั่วโมงหลังทราบเหตุ

---

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

5.1 การจัดการข้อมูลทางการเงิน

5.1.1 ความถูกต้องและครบถ้วนของข้อมูล

• การตรวจสอบความถูกต้อง: Validation Rules สำหรับข้อมูลทางการเงินทุกฟิลด์
• การป้องกันข้อมูลซ้ำซ้อน: ตรวจสอบเลขที่ใบเสร็จซ้ำและการรับชำระเงินซ้ำ
• การคำนวณอัตโนมัติ: คำนวณส่วนลด, ภาษี, และเงินทอนอัตโนมัติ
• การตรวจสอบยอดเงิน: Balance Checking ระหว่างยอดรับชำระกับยอดในระบบ

5.1.2 การจัดการข้อมูลย้อนหลัง

• เก็บประวัติการแก้ไข: Version Control สำหรับข้อมูลทางการเงินทุกรายการ
• การกู้คืนข้อมูล: สามารถกู้คืนข้อมูลจากวันที่ที่ระบุได้
• การตรวจสอบการเปลี่ยนแปลง: Track Changes ของข้อมูลทางการเงิน
• ไม่อนุญาตให้ลบข้อมูล: Soft Delete เท่านั้น พร้อมเหตุผลการลบ

5.1.3 การแจ้งเตือนและการเตือนล่วงหน้า

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

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

5.2.1 การรับข้อมูลจากระบบอื่น

• ระบบเวชระเบียน (1.2.1): ดึงข้อมูลผู้ป่วยและสิทธิการรักษา
• ระบบห้องตรวจ (1.2.3): ดึงค่าตรวจรักษาและค่าหัตถการ
• ระบบชันสูตร (1.2.7): ดึงค่าตรวจทางห้องปฏิบัติการ
• ระบบรังสีวิทยา (1.2.8): ดึงค่าตรวจเอกซเรย์และ CT/MRI
• ระบบเภสัชกรรม (1.2.13): ดึงค่ายาและเวชภัณฑ์
• ระบบตรวจสอบสิทธิ (1.2.15): ดึงข้อมูลสิทธิและการคำนวณส่วนลด

5.2.2 การส่งข้อมูลไปยังระบบอื่น

• ส่งสถานะการชำระเงิน: ไปยังระบบที่ส่งข้อมูลค่ารักษามา
• ส่งข้อมูลการรับชำระ: ไปยังระบบบัญชี (ถ้ามี)
• ส่งการแจ้งเตือน: ไปยังระบบผู้ดูแลระบบเมื่อมีปัญหา
• ส่งรายงาน: ไปยังระบบรายงานของผู้บริหาร

5.2.3 การซิงค์ข้อมูลแบบ Real-time

• การอัพเดทสถานะการชำระ: ทันทีหลังรับชำระเงิน
• การอัพเดทยอดค้างชำระ: ทันทีหลังบันทึกค้างชำระ
• การอัพเดทสิทธิ: ทันทีหลังมีการเปลี่ยนแปลงสิทธิ
• การอัพเดทราคา: ทันทีหลังมีการปรับราคาบริการ

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

5.3.1 โหมดออฟไลน์ (Offline Mode)

• การทำงานขณะเครือข่ายขัดข้อง: สามารถรับชำระเงินและบันทึกไว้ใน Local
• การซิงค์ข้อมูลเมื่อเครือข่ายกลับมา: อัตโนมัติหลังจากระบบกลับมาปกติ
• การป้องกันการทำรายการซ้ำ: ระบบตรวจสอบรายการที่อาจซ้ำซ้อน

5.3.2 ภาวะฉุกเฉิน (Emergency Mode)

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

5.3.3 การจัดการภัยพิบัติ (Disaster Recovery)

• การสำรองข้อมูลหลายจุด: Local, Offsite, และ Cloud
• การกู้คืนระบบ: สามารถกู้คืนและทำงานต่อได้ภายใน 4 ชั่วโมง
• การทำงานในสถานที่สำรอง: รองรับการย้ายไปทำงานที่อื่น

5.4 การปรับขนาดและการขยาย

5.4.1 การขยายจำนวนผู้ใช้งาน

• Architecture แบบ Scalable: รองรับการเพิ่มผู้ใช้งานได้ง่าย
• Load Balancing: กระจายภาระงานเมื่อมีผู้ใช้งานมาก
• Database Clustering: รองรับการทำงานของฐานข้อมูลแบบกลุ่ม

5.4.2 การเพิ่มจุดรับชำระเงิน

• การเพิ่มจุดใหม่: สามารถเพิ่มจุดรับชำระเงินได้โดยไม่กระทบระบบเดิม
• การกำหนดค่าจุดใหม่: ตั้งค่าและเชื่อมต่ออุปกรณ์ได้อัตโนมัติ
• การซิงค์ข้อมูล: ข้อมูลระหว่างจุดต่างๆ ซิงค์กันแบบ Real-time

---

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

6.1 ความน่าเชื่อถือ (Reliability)

6.1.1 ความเสถียรของระบบ

• Mean Time Between Failures (MTBF): ไม่น้อยกว่า 720 ชั่วโมง (30 วัน)
• Mean Time To Recovery (MTTR): ไม่เกิน 30 นาที
• Error Rate: ไม่เกิน 0.1% ของการทำรายการทั้งหมด
• Data Corruption Rate: ไม่เกิน 0.01% ของข้อมูลที่บันทึก

6.1.2 การทำงานในสภาวะผิดปกติ

• Graceful Degradation: ระบบยังทำงานได้ถึงแม้จะมีส่วนประกอบบางส่วนขัดข้อง
• Failover: สลับไปใช้ระบบสำรองอัตโนมัติเมื่อระบบหลักขัดข้อง
• Error Handling: จัดการข้อผิดพลาดและแสดงข้อความที่เข้าใจง่าย

6.2 การใช้งาน (Usability)

6.2.1 ความง่ายในการใช้งาน

• Learning Curve: ผู้ใช้งานใหม่สามารถใช้งานพื้นฐานได้ภายใน 2 ชั่วโมง
• Task Completion Time: การรับชำระเงินรายการหนึ่งไม่เกิน 3 นาที
• Error Prevention: ป้องกันการผิดพลาดด้วย Validation และ Warning
• Help System: มีระบบช่วยเหลือและคู่มือการใช้งานที่ครบถ้วน

6.2.2 การออกแบบ User Interface

• Consistent Design: การออกแบบที่สม่ำเสมอทุกหน้าจอ
• Intuitive Navigation: การนำทางที่เข้าใจง่ายและสอดคล้องกับ Workflow
• Accessibility: รองรับผู้ใช้งานที่มีความต้องการพิเศษ
• Responsive Design: ปรับตัวตามขนาดหน้าจอได้

6.3 ประสิทธิภาพ (Performance)

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

• Response Time: ไม่เกินค่าที่กำหนดใน Section 4.2.1
• Throughput: รองรับการทำรายการได้อย่างน้อย 100 รายการต่อนาที
• Concurrent Users: รองรับผู้ใช้งานพร้อมกันตามที่กำหนดใน Section 4.2.2
• Resource Utilization: ใช้ทรัพยากรระบบอย่างมีประสิทธิภาพ

6.3.2 การปรับปรุงประสิทธิภาพ

• Caching: ใช้ Cache สำหรับข้อมูลที่เข้าถึงบ่อย
• Database Optimization: ปรับแต่งฐานข้อมูลให้ทำงานเร็วขึ้น
• Code Optimization: เขียนโค้ดที่มีประสิทธิภาพ
• Regular Performance Monitoring: ตรวจสอบประสิทธิภาพอย่างสม่ำเสมอ

6.4 การรักษาความปลอดภัย (Security)

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

• Data Encryption: เข้ารหัสข้อมูลทางการเงินและข้อมูลส่วนบุคคล
• Access Control: ควบคุมการเข้าถึงตามสิทธิ์และบทบาท
• Audit Trail: บันทึกการใช้งานทุกรายการอย่างครบถ้วน
• Data Backup: สำรองข้อมูลอย่างปลอดภัยและสม่ำเสมอ

6.4.2 การป้องกันการโจมตี

• SQL Injection Protection: ป้องกันการโจมตีผ่าน SQL Injection
• Cross-Site Scripting (XSS) Protection: ป้องกันการโจมตีผ่าน XSS
• Cross-Site Request Forgery (CSRF) Protection: ป้องกันการโจมตีผ่าน CSRF
• Brute Force Protection: ป้องกันการทดลองรหัสผ่านแบบ Brute Force

6.5 การบำรุงรักษา (Maintainability)

6.5.1 ความง่ายในการบำรุงรักษา

• Modular Design: การออกแบบแบบโมดูลาร์ที่แก้ไขได้ง่าย
• Code Documentation: เอกสารประกอบโค้ดที่ครบถ้วน
• Error Logging: บันทึกข้อผิดพลาดอย่างละเอียด
• Configuration Management: จัดการการตั้งค่าแบบรวมศูนย์

6.5.2 การอัพเดทและการปรับปรุง

• Version Control: จัดการเวอร์ชันของระบบ
• Automated Testing: ทดสอบอัตโนมัติก่อนอัพเดท
• Rolling Updates: อัพเดทแบบไม่หยุดการทำงาน
• Rollback Capability: สามารถย้อนกลับเมื่อมีปัญหา

6.6 การพกพา (Portability)

6.6.1 ความเป็นอิสระจากแพลตฟอร์ม

• Cross-Platform: ทำงานได้บนระบบปฏิบัติการหลายแบบ
• Database Independence: ไม่ผูกมัดกับฐานข้อมูลชนิดใดชนิดหนึ่ง
• Browser Compatibility: ใช้งานได้กับเว็บเบราว์เซอร์หลายชนิด
• Standard Compliance: ปฏิบัติตามมาตรฐานสากล

---

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

7.1 การเชื่อมโยงกับระบบ HIS ภายใน

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

ประเภทการเชื่อมโยง: Two-way Integration

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

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

API Endpoints:
  - GET /api/patient/{hn}/info - ดึงข้อมูลผู้ป่วย
  - GET /api/patient/{hn}/rights - ดึงข้อมูลสิทธิ
  - POST /api/patient/{hn}/payment-status - อัพเดทสถานะการชำระ

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

ประเภทการเชื่อมโยง: Primary Integration

รับข้อมูลจากระบบตรวจสอบสิทธิ:
  - ข้อมูลสิทธิแบบ Real-time: สถานะสิทธิ, ขอบเขตการใช้งาน
  - การคำนวณส่วนลด: ส่วนลดตามสิทธิ, เงื่อนไขการลด
  - ข้อมูลการเบิกจ่าย: วงเงินคงเหลือ, ประวัติการเบิก

ส่งข้อมูลไปยังระบบตรวจสอบสิทธิ:
  - การใช้สิทธิ: รายการที่ใช้สิทธิ, ยอดเงินที่เบิก
  - ยืนยันการชำระ: ยืนยันการรับชำระตามสิทธิ

Integration Method: 
  - Real-time API calls
  - Shared Database views
  - Event-driven updates

API Endpoints:
  - GET /api/rights/check/{hn}/{service} - ตรวจสอบสิทธิ
  - POST /api/rights/claim - แจ้งการใช้สิทธิ
  - GET /api/rights/remaining-limit/{hn} - ตรวจสอบวงเงินคงเหลือ

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

ประเภทการเชื่อมโยง: Data Collection Integration

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

การส่งข้อมูลค่ารักษา:
  - Format: JSON หรือ XML
  - Frequency: Real-time หลังจากเสร็จสิ้นการตรวจ
  - Data Structure:
    {
      "hn": "123456",
      "visit_date": "2568-10-08",
      "doctor_code": "D001",
      "department": "อายุรกรรม",
      "services": [
        {
          "service_code": "S001",
          "service_name": "การตรวจรักษาทั่วไป",
          "quantity": 1,
          "unit_price": 150,
          "total_price": 150
        }
      ]
    }

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

ประเภทการเชื่อมโยง: Data Collection Integration

รับข้อมูลจากระบบเภสัชกรรม:
  - ค่ายา: ราคายาแต่ละรายการ, จำนวน, ส่วนลด
  - ค่าเวชภัณฑ์: อุปกรณ์การแพทย์, วัสดุใช้แล้วทิ้ง
  - ค่าบริการทางเภสัชกรรม: ค่าจ่ายยา, ค่าคำแนะนำ

การประมวลผลข้อมูลยา:
  - รวมยอดค่ายาตามใบสั่งยา
  - คำนวณส่วนลดยาตามสิทธิ
  - ตรวจสอบเงื่อนไขการเบิกยา

API Integration:
  - GET /api/pharmacy/prescription/{prescription_id} - ดึงข้อมูลใบสั่งยา
  - GET /api/pharmacy/drug-cost/{hn}/{date} - ดึงค่ายารายวัน

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

ประเภทการเชื่อมโยง: Data Collection Integration

รับข้อมูลจากระบบชันสูตร:
  - ค่าตรวจทางห้องปฏิบัติการ: ตรวจเลือด, ตรวจปัสสาวะ, ตรวจจุลชีพ
  - ค่าบริการพิเศษ: ตรวจดีเอ็นเอ, ตรวจฮอร์โมน
  - ค่าวัสดุการตรวจ: หลอดเลือด, สารเคมี

รับข้อมูลจากระบบรังสีวิทยา:
  - ค่าตรวจเอกซเรย์: X-Ray ธรรมดา, X-Ray พิเศษ
  - ค่าตรวจ CT Scan: CT หัว, CT ช่องท้อง
  - ค่าตรวจ MRI: MRI สมอง, MRI กระดูก
  - ค่าตรวจ Ultrasound: อัลตราซาวนด์ช่องท้อง, หัวใจ

การรวมรายการตรวจ:
  - จัดกลุ่มตามประเภทการตรวจ
  - คำนวณส่วนลดตามแพ็กเกจ (ถ้ามี)
  - ตรวจสอบเงื่อนไขการเบิกตามสิทธิ

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

7.2.1 ระบบสำนักงานหลักประกันสุขภาพแห่งชาติ (สปสช.)

ประเภทการเชื่อมโยง: Government API Integration

การส่งข้อมูล 43 แฟ้ม:
  แฟ้มข้อมูลที่เกี่ยวข้องกับการเงิน:
    - แฟ้มที่ 12: ข้อมูลการให้บริการผู้ป่วยนอก
    - แฟ้มที่ 13: ข้อมูลการให้บริการผู้ป่วยใน  
    - แฟ้มที่ 14: ข้อมูลการใช้ยา
    - แฟ้มที่ 15: ข้อมูลการตรวจทางห้องปฏิบัติการ
    - แฟ้มที่ 16: ข้อมูลการรับชำระเงิน

ข้อมูลการเบิกจ่าย:
  - ยอดเงินที่เบิกได้ตามสิทธิ UC
  - รายการค่ารักษาที่ครอบคลุม
  - เงื่อนไขและข้อจำกัดการเบิก

API Specification:
  - Endpoint: https://api.nhso.go.th/claims
  - Method: POST
  - Authentication: Digital Certificate
  - Data Format: XML ตามมาตรฐาน HL7
  - Frequency: รายวัน หรือ Real-time

7.2.2 ระบบสำนักงานสวัสดิการและคุ้มครองแรงงาน (สนย.)

ประเภทการเชื่อมโยง: Government API Integration

การตรวจสอบสิทธิประกันสังคม:
  - ตรวจสอบสถานะการมีสิทธิ
  - ตรวจสอบวงเงินคงเหลือ
  - ตรวจสอบข้อจำกัดการใช้สิทธิ

การเบิกจ่ายประกันสังคม:
  - ส่งข้อมูลการรักษา
  - ขอเบิกค่ารักษาพยาบาล
  - ติดตามสถานะการเบิก

API Integration:
  - Endpoint: https://api.sso.go.th/medical-claim
  - Method: POST/GET
  - Authentication: SSL Client Certificate
  - Data Format: JSON
  - Real-time Response: Yes

7.2.3 ระบบกรมบัญชีกลาง (สำหรับข้าราชการ)

ประเภทการเชื่อมโยง: Government API Integration

การตรวจสอบสิทธิข้าราชการ:
  - ตรวจสอบสถานะการเป็นข้าราชการ
  - ตรวจสอบสิทธิในการรักษา
  - ตรวจสอบสิทธิครอบครัว

การเบิกจ่าย:
  - เบิกค่ารักษาตามระเบียบข้าราชการ
  - เบิกค่ารักษาครอบครัว
  - เบิกค่ารักษาในกรณีพิเศษ

Data Exchange:
  - Monthly Batch Processing
  - Secure File Transfer (SFTP)
  - Excel/CSV Format
  - Digital Signature Required

7.2.4 ระบบธนาคาร (สำหรับการชำระเงิน)

ประเภทการเชื่อมโยง: Payment Gateway Integration

การชำระด้วยบัตรเครดิต/เดบิต:
  - เชื่อมต่อกับ Payment Gateway
  - รองรับ Visa, MasterCard, JCB, UnionPay
  - การตรวจสอบ Real-time Authorization
  - การจัดการ Chargeback และ Refund

การชำระผ่าน QR Code:
  - PromptPay Integration
  - Banking App QR Code
  - E-Wallet Integration (TrueMoney, Rabbit LINE Pay)

API Integration:
  Payment Gateway APIs:
    - Authorization: POST /api/payment/authorize
    - Capture: POST /api/payment/capture  
    - Refund: POST /api/payment/refund
    - Status Check: GET /api/payment/status/{transaction_id}

Security Requirements:
  - PCI DSS Compliance
  - SSL/TLS Encryption
  - Tokenization for Card Data
  - 3D Secure Authentication

7.3 การจัดการข้อผิดพลาดในการเชื่อมโยง

7.3.1 Error Handling Strategy

Connection Errors:
  - Timeout: 30 seconds for API calls
  - Retry Logic: 3 attempts with exponential backoff
  - Fallback: Use cached data or manual override
  - Logging: Detailed error logs for troubleshooting

Data Validation Errors:
  - Schema Validation: Check data format before sending
  - Business Rule Validation: Check business constraints
  - Error Response: Clear error messages for users
  - Data Correction: Allow manual correction when needed

System Unavailability:
  - Health Check: Regular monitoring of external systems
  - Circuit Breaker: Prevent cascading failures
  - Offline Mode: Continue critical operations offline
  - Queue Management: Queue requests for later processing

7.3.2 Data Synchronization

Real-time Sync:
  - Critical Data: Payment status, rights verification
  - Method: Event-driven updates via webhooks
  - Validation: Check data integrity after sync
  - Rollback: Ability to rollback failed transactions

Batch Sync:
  - Periodic Data: Daily/weekly reports
  - Method: Scheduled batch jobs
  - Reconciliation: Compare and fix data differences
  - Monitoring: Track sync status and performance

Conflict Resolution:
  - Last Writer Wins: For simple conflicts
  - Manual Review: For complex conflicts
  - Audit Trail: Track all changes and conflicts
  - Notification: Alert administrators of conflicts

---

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