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) ทำให้บำรุงรักษาและขยายขนาดระบบได้ง่าย

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

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

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

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

เอกสารนี้ได้รับการตรวจสอบและอนุมัติตามมาตรฐานวิศวกรรมซอฟต์แวร์ระดับองค์กร

11 KiB Raw Permalink Blame History