Files
gravity/บริหารจัดการคิวนวดแผนไทย/docs/02_SRS_SDD.md
T
2026-09-16 23:20:08 +07:00

177 lines
11 KiB
Markdown

# 02. Software Requirement Specification (SRS) & System Design Document (SDD)
**Project:** Thai Traditional Massage Queue Management System (TTMQMS Enterprise)
**Standard:** IEEE 830-1998 & Enterprise Clean Architecture
**Version:** 1.0.0 Production
---
## Part 1: Software Requirement Specification (SRS)
### 1. Functional Requirements (FR)
| รหัสความต้องการ | โมดูล | รายละเอียดความต้องการทางฟังก์ชัน | ระดับความสำคัญ |
| :--- | :--- | :--- | :--- |
| **FR-AUTH-01** | Authentication | ระบบต้องรองรับการยืนยันตัวตนด้วยเลขบัตรประชาชน 13 หลัก และรหัสผ่านที่เข้ารหัสด้วย Argon2id | High |
| **FR-AUTH-02** | Security (2FA) | ระบบต้องบังคับใช้ 2-Factor Authentication (TOTP RFC 6238) สำหรับแพทย์ หมอนวด และ Admin | High |
| **FR-QUE-01** | Queue & AI | ระบบต้องจัดสรรหมอนวดและห้องพักอัตโนมัติด้วย AI (`sp_assign_smart_queue`) โดยคำนวณจาก Workload Balance | High |
| **FR-QUE-02** | Priority | ระบบต้องรองรับคิว 3 ระดับ (Normal, VIP, Emergency) และเร่งลำดับคิวอัตโนมัติเมื่อเกิน SLA | High |
| **FR-CLN-01** | SOAP Note | แพทย์/หมอนวดต้องสามารถบันทึกเวชระเบียน SOAP Note พร้อมระบุจุดปวดบนร่างกายและ ROM Goniometer | High |
| **FR-CLN-02** | Pain VAS | ระบบต้องมีแถบประเมินความปวด VAS Score (0-10) ทั้งก่อนและหลังการรักษา พร้อมเปรียบเทียบผล | Medium |
| **FR-CLN-03** | Digital Sign | ระบบต้องรองรับการบันทึกลายมือชื่อดิจิทัลผ่านหน้าจอสัมผัส (HTML5 Canvas) เพื่อป้องกันการปฏิเสธความรับผิดชอบ | High |
| **FR-POS-01** | Billing & QR | แคชเชียร์ต้องสามารถคำนวณค่าบริการ ส่วนลด VAT 7% และสร้าง Dynamic PromptPay QR Code มาตรฐาน EMVCo | High |
| **FR-POS-02** | Thermal Print| ระบบต้องสามารถส่งคำสั่งพิมพ์ใบเสร็จและใบคิวไปยังเครื่องพิมพ์ความร้อน ESC/POS ผ่าน WebUSB API | Medium |
| **FR-HIS-01** | HIS Interop | ระบบต้องสามารถเชื่อมต่อแลกเปลี่ยนข้อมูลผู้ป่วย HN และเวชระเบียนกับ HOSxP/JHCIS ผ่าน REST mTLS | High |
| **FR-HIS-02** | FHIR R4 | ระบบต้องสร้างและส่งข้อมูลสุขภาพในรูปแบบ HL7 FHIR R4 JSON Bundle (Encounter & Observation) | High |
---
### 2. Non-Functional Requirements (NFR)
- **NFR-PERF-01 (Performance & SLA):** ระยะเวลาในการตอบสนองคำขอ REST API (API Response Time) ต้องน้อยกว่า **200 มิลลิวินาที (ms)** ที่ภาระงานปกติ และกระบวนการคำนวณคิวด้วย AI ต้องใช้เวลาไม่เกิน **50 ms**
- **NFR-AVAIL-01 (Availability & Reliability):** ระบบต้องมีอัตราการพร้อมใช้งาน (Uptime Availability) ไม่น้อยกว่า **99.9%** (หยุดชะงักไม่เกิน 8.76 ชั่วโมง/ปี)
- **NFR-SEC-01 (Security & Compliance):** ระบบต้องผ่านเกณฑ์ความปลอดภัยตามมาตรฐาน **OWASP Top 10** และจัดเก็บข้อมูลสุขภาพโดยเป็นไปตามพระราชบัญญัติคุ้มครองข้อมูลส่วนบุคคล (PDPA) และเกณฑ์สากล HIPAA
- **NFR-PORT-01 (Portability & PWA):** หน้าจอผู้ใช้งานต้องเป็น Progressive Web App (PWA) ที่สามารถติดตั้งบนแท็บเล็ต พีซี และมือถือ (Mobile First Responsive) สามารถทำงานในโหมดออฟไลน์ (Offline Fallback) ได้ชั่วคราว
---
## Part 2: System Design Document (SDD)
### 3. Enterprise Layered Architecture
ระบบ TTMQMS ถูกออกแบบภายใต้หลักการ **Clean Architecture** และ **SOLID Principles** เพื่อแยกลำดับชั้นการทำงาน (Separation of Concerns) ทำให้บำรุงรักษาและขยายขนาดระบบได้ง่าย
```mermaid
graph TD
subgraph Presentation_Layer [Presentation Layer / PWA]
UI[Glassmorphism UI<br/>TailwindCSS / AlpineJS]
SW[Service Worker<br/>Offline Caching]
end
subgraph API_Gateway_Layer [API Gateway & Routing Layer]
FC[Front Controller<br/>index.php]
ROUTER[FastRoute Engine]
MID[Security Middleware<br/>JWT / 2FA / CSRF / RateLimit]
end
subgraph Domain_Service_Layer [Domain Business Logic Layer]
AI[SmartQueueEngine<br/>WorkloadBalancer]
CLN[SoapNoteService<br/>VasScoreAnalyzer]
BILL[PosBillingService<br/>PromptPayGenerator]
HIS[HisConnector<br/>FhirR4BundleBuilder]
end
subgraph Data_Access_Layer [Data Access & Storage Layer]
PDO[PDO MySQL Adapter<br/>Prepared Statements]
REDIS[Redis Cache Client<br/>Session & Token Storage]
DB[(MySQL 8 Database<br/>Stored Procedures)]
end
UI <-->|HTTPS / REST API JSON| FC
FC --> ROUTER --> MID --> Domain_Service_Layer
Domain_Service_Layer <--> PDO & REDIS
PDO <--> DB
```
---
### 4. Component Architecture Diagram
แผนภาพองค์ประกอบแสดงความสัมพันธ์ระหว่าง Controller, Service และ Helper ภายใน Backend Architecture
```mermaid
classDiagram
class FrontController {
+dispatch()
+handleException()
}
class JwtAuthMiddleware {
+handle(request)
-verifyArgon2id()
}
class QueueController {
+walkin(request)
+updateStatus(id)
}
class SmartQueueEngine {
+allocateQueue(patientId, serviceId, priority)
-calculateWorkloadScore()
}
class HisConnector {
+syncPatient(hn)
+sendFhirEncounter(soapData)
}
class EscPosPrinter {
+generateTicketBuffer(queueNo)
+generateReceiptBuffer(billData)
}
FrontController --> JwtAuthMiddleware
FrontController --> QueueController
QueueController --> SmartQueueEngine
QueueController --> EscPosPrinter
SmartQueueEngine --> HisConnector
```
---
### 5. Sequence Diagram: AI Smart Queue Allocation & SOAP Sync
แผนภาพลำดับเหตุการณ์แสดงการปฏิสัมพันธ์ตั้งแต่การออกคิว Walk-in จนถึงการซิงค์ข้อมูล FHIR R4 เข้าสู่ระบบ HIS
```mermaid
sequenceDiagram
autonumber
actor Rec as พนักงานต้อนรับ
participant PWA as หน้าจอ PWA / Queue Board
participant API as QueueController
participant AI as SmartQueueEngine
participant DB as MySQL 8 / Sp
participant HIS as HOSxP / FHIR Server
Rec->>PWA: กรอกข้อมูล/อ่าน Smart Card ผู้ป่วย Walk-in
PWA->>API: POST /api/v1/queues/walkin {patient_id, service_id, priority}
API->>AI: allocateQueue(patient_id, service_id, priority)
AI->>DB: CALL sp_assign_smart_queue(patient_id, service_id, priority)
Note over DB: ตรวจสอบหมอนวด (Workload < 480)<br/>และห้องว่าง (Status = Available)
DB-->>AI: คืนค่าคิวที่จัดสรร (Queue #A003, Assigned Room R-101, Therapist T-102)
AI-->>API: Result Allocated Queue Object
API-->>PWA: HTTP 200 OK (JSON Queue Data)
PWA->>Rec: แสดง Modal จัดสรรสำเร็จ & สั่งพิมพ์ใบคิว ESC/POS
Note over Rec, HIS: เมื่อเข้าสู่กระบวนการรักษาโดยหมอนวด
actor Ther as หมอนวดผู้ให้บริการ
Ther->>PWA: บันทึก SOAP Note, VAS Score (7->2) และเซ็นชื่อ
PWA->>API: POST /api/v1/clinical/soap {soap_data, signature_base64}
API->>DB: บันทึกเวชระเบียน SOAP และลายนิ้วมือดิจิทัล
API->>HIS: POST /fhir/r4/Bundle (Transaction: Encounter + Observation)
HIS-->>API: HTTP 201 Created (FHIR Resource ID)
API-->>PWA: HTTP 200 OK (Sync Success)
```
---
### 6. Deployment & Infrastructure Diagram
แผนภาพการติดตั้งระบบในสภาพแวดล้อมจริง (Production Environment) ด้วย Docker Containerization และ Nginx Reverse Proxy
```mermaid
graph TB
subgraph Hospital_Network [เครือข่ายภายในโรงพยาบาล / DMZ]
subgraph Docker_Host [Docker Server Container Host]
PROXY[Nginx Reverse Proxy<br/>SSL / TLS 1.3 Terminated]
APP[PHP 8.1-FPM Container<br/>TTMQMS Backend & PWA]
CACHE[(Redis Container<br/>In-Memory Cache)]
MYSQL[(MySQL 8.0 Container<br/>Master Database)]
end
subgraph HIS_Zone [Hospital Information System Zone]
HOSXP[(HOSxP / JHCIS<br/>Database Gateway)]
MOPH[MOPH FHIR Server<br/>HL7 R4 Gateway]
end
end
CLIENTS[PWA Clients<br/>PC / Tablet / Smart TV] -->|HTTPS Port 443| PROXY
PROXY -->|FastCGI Port 9000| APP
APP <-->|TCP Port 6379| CACHE
APP <-->|TCP Port 3306| MYSQL
APP <-->|REST / mTLS Port 8080| HOSXP
APP <-->|HTTPS FHIR R4| MOPH
```
---
*เอกสารนี้ได้รับการตรวจสอบและอนุมัติตามมาตรฐานวิศวกรรมซอฟต์แวร์ระดับองค์กร*