ระบบสารสนเทศโรงพยาบาล (Hospital HIS)

01 Product Requirements (PRD)

บทสรุปผู้บริหาร

ระบบนี้คือ HIS แบบ modular monolith ที่รวม 5 งานหลักของโรงพยาบาลบนฐานข้อมูลผู้ป่วยเดียว (single patient master) ผู้ป่วยมี HN เดียว ที่ทุกโมดูลใช้ร่วมกัน ทำให้ข้อมูลไหลต่อเนื่องไม่ต้องคีย์ซ้ำ และพิมพ์เอกสารราชการได้ทุกจุด

ผู้ใช้งานและบทบาท (RBAC)

RBAC = role → permission ต่อ (module × action). ทุก access ถูก log. ข้อมูล sensitive (HIV/จิตเวช) มี field-level access เพิ่ม

ภาพรวมการไหลของข้อมูล (End-to-End)

[ลงทะเบียน] → ออก HN/VN + ตรวจสอบสิทธิ
     │ (patient_id, visit_id, สิทธิ)
     ▼
[ตรวจสุขภาพ] → vital signs + เลือก package + ตรวจร่างกาย
     │ (สั่งตรวจ)
     ▼
[ส่ง Lab] → order (ORM) → specimen+barcode → run → result (ORU) → validate
     │ (lab_result)
     ▼
[ออกผลตรวจ] → รวมผลทุกสถานี → แพทย์ลงนาม → เล่มผล/ใบรับรองแพทย์
     │ (charges สะสมจากทุกจุด)
     ▼
[Billing] → คิดเงินตามสิทธิ → ใบเสร็จ/ใบแจ้งหนี้ → e-Claim/สปส.
     │
     ▼
[Export] → 43 แฟ้ม → HDC | e-Claim → สปสช. | audit log

ทุกลูกศร = event ภายในระบบ (in-process event / outbox) ไม่ต้องคีย์ซ้ำ

โมดูล 1 — ลงทะเบียนตรวจผู้ป่วย

จุดเริ่มของทุก visit: ระบุตัวผู้ป่วย, ออก/ค้น HN, สร้าง visit (VN), ตรวจสอบสิทธิ, ออกบัตร/sticker

เอกสารพิมพ์: OPD card · Sticker/label (HN/VN + ชื่อ + barcode)

โมดูล 2 — ตรวจสุขภาพ (Package-driven)

จัดการ "ตรวจสุขภาพ" แบบ package (ต่างจาก OPD ที่เป็น chief-complaint): ตรวจประจำปี, ก่อนเข้างาน, เพื่อใบรับรอง, ทำประกัน, วีซ่า

โมดูล 3 — ออกผลการตรวจสุขภาพ + ใบรับรองแพทย์

เอกสารพิมพ์: เล่มผลตรวจสุขภาพ · ใบรับรองแพทย์ (ฟอร์มแพทยสภา)

โมดูล 4 — ส่งผลให้ห้อง Labs (Lab Order / LIS)

โมดูล 5 — Billing ค่ารักษา

Non-Functional + Compliance Checklist

02 สถาปัตยกรรมระบบ (Architecture)

สรุป 1 บรรทัด: Modular monolith เป็น Go (Fiber v3 หรือ Echo) + Svelte/React + PostgreSQL เดียว multi-schema, PDF ด้วย Gotenberg (ฟอนต์ Sarabun), label ด้วย ZPL raw, LIS ผ่าน Mirth Connect, deploy on-prem Docker Compose บนเครื่อง ~4–8 GB RAM

Recommended Stack

System Context

Modular Monolith — โครงสร้างภายใน

Data Model

Schema layout (1 PostgreSQL, หลาย schema)

core         → patient (MPI), user, role, permission, audit_log, consent, event_outbox
registration → visit, eligibility_check, coverage
checkup      → checkup_package, checkup_order, vital_sign, physical_exam
lab          → lab_order, specimen, lab_result
result       → checkup_report, medical_certificate, signature
billing      → charge, invoice, receipt, payment, claim_export

• Patient Master (MPI): core.patient เป็น single source of truth — ทุก module อ้าง patient_id กลาง ไม่ duplicate. Matching: deterministic (เลข ปชช. + DOB) สำหรับ greenfield
• Partitioning: lab_result + charge ใช้ range partition by month (pg_partman) — query prune ตามวันที่, ลบเก่าด้วย DETACH+DROP
• Audit (PDPA) 2 ชั้น: pgAudit (statement log) + trigger-based row audit เก็บ before/after บนตารางวิกฤต

ER Diagram (ย่อ)

Deployment + Phasing

Deployment footprint

docker-compose:
  nginx     → reverse proxy, TLS, HTTP/2
  api       → Go binary (idle ~25 MB)
  db        → PostgreSQL (ตัวกิน RAM หลัก)
  pdf       → Gotenberg (Chromium)
  mirth     → Mirth Connect (เปิดเมื่อมี LIS)

Minimal spec: เครื่องเดียว ~4 GB RAM / 2 vCPU (greenfield, 1 รพ.); ขยับเป็น 8 GB ถ้ารัน Mirth + traffic จริง. On-prem หรือ Thai-region cloud = default สำหรับ PDPA data residency. Backup: pg_dump + WAL/PITR + off-site

แนวทางเฟสการพัฒนา

03 Sequence Diagrams

Flow คร่าว ๆ ของแต่ละโมดูล — แก้ได้ง่ายตอนคุยกับผู้ว่าจ้าง

End-to-End — ภาพรวมทั้งระบบ

M1 — ลงทะเบียน + ตรวจสอบสิทธิ

M2 — ตรวจสุขภาพ (Package-driven)

M4 — Lab Order → Result Loop (หัวใจของระบบ)

ถ้า greenfield (ยังไม่มี analyzer) — ข้าม Mirth/Analyzer, นักเทคนิคคีย์ผลเข้าตรงแล้ว validate. เปิด Mirth เมื่อต่อ analyzer จริง

M3 — ออกผลตรวจ + ใบรับรองแพทย์

M5 — Billing + e-Claim

Compliance Export — 43 แฟ้ม → HDC

04 Frontend / Backend Design

Backend — โครงสร้างโปรเจกต์ (Go, Modular Monolith)

his/
├── cmd/server/main.go          # entrypoint, wire modules
├── internal/
│   ├── core/                   # patient master, auth, audit, events
│   ├── registration/           # handler → service → repo (schema "registration")
│   ├── checkup/
│   ├── lab/
│   ├── result/
│   └── billing/
├── pkg/
│   ├── pdf/                    # Gotenberg client
│   ├── label/                  # ZPL generator
│   ├── hl7/                    # Mirth REST client (ไม่ parse เอง)
│   └── export/                 # 43 แฟ้ม / e-Claim
├── migrations/                 # SQL per schema
└── docker-compose.yml

แต่ละ module = handler → service → repo. repo แตะเฉพาะ schema ตัวเอง. cross-module ผ่าน core/events

REST API — ตัวอย่าง endpoints

# Registration
POST  /api/v1/patients                 สร้างผู้ป่วยใหม่ (ออก HN)
GET   /api/v1/patients?nid=...         ค้นผู้ป่วย
POST  /api/v1/visits                   สร้าง visit (VN)
POST  /api/v1/visits/{id}/eligibility  ตรวจสอบสิทธิ NHSO
POST  /api/v1/print/opd-card           พิมพ์ OPD card/sticker

# Checkup
GET   /api/v1/checkup/packages         รายการ package
POST  /api/v1/checkup/orders           สร้าง order จาก package
POST  /api/v1/checkup/{id}/vitals      บันทึก vital signs

# Lab
POST  /api/v1/lab/orders               สั่ง lab (CPOE)
POST  /api/v1/lab/specimens/{id}/label พิมพ์ barcode
POST  /api/v1/lab/results              รับผล (จาก Mirth)
PATCH /api/v1/lab/results/{id}/validate validate ผล

# Result
GET   /api/v1/results/{visitId}        รวมผลทุกสถานี
POST  /api/v1/results/{id}/sign        แพทย์ลงนาม
POST  /api/v1/results/{id}/report      gen เล่มผล PDF
POST  /api/v1/certificates             ออกใบรับรองแพทย์

# Billing
POST  /api/v1/billing/invoices         รวมบิล + คิดสิทธิ
POST  /api/v1/billing/payments         รับชำระ
POST  /api/v1/billing/receipts         ออกใบเสร็จ
POST  /api/v1/export/eclaim            export e-Claim

# Admin / Compliance
POST  /api/v1/export/43files           export 43 แฟ้ม
GET   /api/v1/audit/logs               ดู audit (DPO)

ทุก endpoint ผ่าน RBAC middleware + audit log middleware

UI/UX หลักการสำหรับงาน รพ.

• Keyboard-first — ใช้ tab/enter/shortcut ได้ทั้ง flow
• ค้นผู้ป่วยเด่นสุด — search bar ใหญ่ (ปชช./HN/ชื่อ/คิว)
• แจ้งเตือนสำคัญเด่น — แพ้ยา (สีแดง), เสียชีวิต, critical lab value
• Worklist/คิว real-time — เห็นสถานะผู้ป่วยทุกจุด
• Print ทุกจุด — ปุ่มชัดเจน, preview ก่อนพิมพ์
• ปฏิทิน พ.ศ. + ฟอนต์ Sarabun; เน้น desktop (workstation)

เอกสาร/Template ที่ต้อง build

ทุก A4 template = HTML/CSS + charset=UTF-8 + embed ฟอนต์ Sarabun

ตัวอย่าง Coverage Rules (Billing)

สิทธิ UC (บัตรทอง):
  - ในชุดสิทธิ → เบิก สปสช. (e-Claim), ผู้ป่วยจ่าย 0 หรือ 30 บาท
  - นอกชุดสิทธิ → copay ผู้ป่วยจ่ายเอง
สิทธิประกันสังคม:
  - รพ.ตามสิทธิ → เบิก สปส. (ผู้ป่วยอาจสำรอง+ขอใบเสร็จ)
ข้าราชการ (CSMBS):
  - เบิกตรงกรมบัญชีกลาง
เงินสด / ประกันเอกชน:
  - ผู้ป่วยจ่ายเต็ม → ออกเอกสารให้เคลม

rules engine แยกเป็น config table (เพิ่ม/แก้สิทธิได้โดยไม่แก้โค้ด)

⚠️ ก่อน implement จริง — ต้องดึง spec ตัวจริง

Roadmap (ไม่บังคับวันนี้): FHIR profile (SIL-TH), SNOMED CT, Health Link / หมอพร้อม PHR, MOPH ID / Provider ID Digital Cert — ออกแบบ data model ให้ map ได้ในอนาคต