รับภาพได้จากทุก PACS
PACS ทุกยี่ห้อของโรงพยาบาล ผ่าน DICOM มาตรฐาน รวมเป็นคลังกลางเดียว
เชื่อมต่อ HIS ครบวงจร
รับผู้ป่วย/ใบสั่งตรวจผ่าน HL7 สร้าง Worklist ให้เครื่องตรวจ แจ้งภาพพร้อม และเปิดภาพจาก HIS ได้ทันที
ปลอดภัยและตรวจสอบได้
สิทธิ์ละเอียดตามบทบาท แผนก และแหล่งที่ส่งภาพ บันทึก audit ทุกการกระทำ สอดคล้อง PDPA
มั่นคง ขยายได้
สำรองข้อมูลต่อเนื่อง กู้คืน ณ จุดเวลาได้ ทำสำเนาข้ามดิสก์/ข้ามเครื่อง และ 5 ขนาดติดตั้งตามโรงพยาบาล
คอลัมน์ "ผู้ใช้หลัก":
แพทย์รังสีเทคนิคเวชระเบียนผู้ดูแลระบบผู้บริหาร
กลุ่มผู้ใช้ที่ได้ประโยชน์จากหน้าจอนั้นมากที่สุด
(ทุกหน้าเปิด/ปิดได้ตามสิทธิ์)
1.1
หน้าจอการทำงานหลัก
Clinical & Operational Pagesเมนูหลัก 11 รายการ จัดตามลำดับงานจริง: ค้นหาผู้ป่วยและการตรวจ → เปิดภาพ → แนบเอกสาร → ส่งต่อ → ตรวจสอบย้อนหลัง
| หน้าจอ / ฟีเจอร์ | คำอธิบายและความสามารถหลัก | ผู้ใช้หลัก |
|---|---|---|
| แดชบอร์ดDashboard |
ภาพรวมปริมาณงานและพื้นที่จัดเก็บแบบเรียลไทม์
|
ผู้บริหารผู้ดูแลระบบ |
| รายการการตรวจStudies |
หน้าค้นหาหลักของระบบ (หน้าแรกหลังเข้าสู่ระบบ)
|
แพทย์รังสีเทคนิค |
| รายละเอียดการตรวจStudy Detail |
ประวัติการตรวจทั้งหมดของผู้ป่วยในหน้าเดียว
แสดงเป็นรายการพับ/ขยาย
|
แพทย์รังสีเทคนิค |
| ผู้ป่วยPatients · Register · Merge · Edit |
บริหารทะเบียนผู้ป่วยกลาง (Master Patient Index)
|
เวชระเบียนผู้ดูแลระบบ |
| รายการโปรดFavorites | ปักหมุดการตรวจที่ติดตามอยู่ (เช่น เคสสอน เคสติดตามผล) แสดงจำนวนบนเมนู และใช้เครื่องมือเดียวกับหน้ารายการการตรวจ | แพทย์ |
| ส่งออกการตรวจExport Study | เลือกส่งออกเป็นไฟล์ ZIP ได้ 3 แบบรวมกัน: DICOM ต้นฉบับ (แยกโฟลเดอร์ตาม series), ภาพ JPEG ทุกเฟรม และเอกสารแนบ ดาวน์โหลดแบบ streaming ผ่านตัวจัดการดาวน์โหลดของเบราว์เซอร์ ใช้กฎแก้ไข Tag (Tag Morphing) ของช่องทาง Export อัตโนมัติ | แพทย์เวชระเบียน |
| Modality WorklistMWL & Emergency Order |
รายการนัดตรวจที่ส่งให้เครื่องตรวจโดยตรง
(ไม่ต้องพิมพ์ข้อมูลผู้ป่วยซ้ำที่เครื่อง)
|
รังสีเทคนิค |
| VIPVIP Cases | กำหนดให้การตรวจของผู้ป่วยบุคคลสำคัญ เห็นได้เฉพาะผู้ใช้ที่ระบุเท่านั้น (มีผลเหนือสิทธิ์อื่นทั้งหมด รวมถึงสิทธิ์ Global) มอบหมาย / เปลี่ยนผู้รับผิดชอบ / ยกเลิกได้ พร้อมบันทึกผู้มอบหมายและเวลา | ผู้ดูแลระบบ |
| ไฟล์และเอกสารแนบFiles · Non-DICOM |
บริหารเอกสาร non-DICOM เช่น ใบส่งตัว ผลแล็บ ภาพถ่าย วิดีโอ
|
เวชระเบียนรังสีเทคนิค |
| นำเข้า DICOMImport DICOM | นำเข้าภาพจากไฟล์ ZIP (สูงสุด 1 GB) เลือกแผนก แสดงความคืบหน้าและยกเลิกได้ ไฟล์ non-DICOM ใน ZIP เดียวกันแนบเข้ากับการตรวจให้อัตโนมัติ | เวชระเบียนรังสีเทคนิค |
| ส่งต่อการตรวจRefer to Another Hospital |
ส่งภาพและเอกสารให้โรงพยาบาลปลายทางทางอีเมล
โดยผู้รับไม่ต้องมีบัญชี
|
แพทย์เวชระเบียน |
| บันทึกการใช้งานAudit Logs | ตรวจสอบย้อนหลังทุกการกระทำในระบบ กรองตามประเภท (Audit / Application), ระดับความรุนแรง, 13 โมดูล (เช่น Auth, Patients, Studies, Files, Refer, HL7), ผู้ใช้, HN และช่วงเวลา | ผู้ดูแลระบบผู้บริหาร |
| ลิงก์เปิดภาพโดยตรงOpen-Viewer Deep Link | ลิงก์ที่คัดลอกส่งต่อให้เพื่อนร่วมงานได้ หากยังไม่เข้าสู่ระบบจะพาไปหน้า login แล้วกลับมาเปิดภาพให้อัตโนมัติ เปิด Viewer เต็มจอ และเปิดบนจอที่สองเมื่อมีหลายจอ | แพทย์ |
1.2
การตั้งค่าระบบ
Settings — 12 Administration Pagesผู้ดูแลระบบปรับแต่งได้เองผ่านหน้าจอ ทุกการเปลี่ยนแปลงมีผลทันทีโดยไม่ต้องรีสตาร์ทระบบ
| หน้าตั้งค่า | คำอธิบายและความสามารถหลัก | กลุ่ม |
|---|---|---|
| ผู้ใช้และบทบาทUsers & Roles | สร้าง/แก้ไข/ลบบทบาท (Administrator, Doctor, Medical Tech, Nurse, Staff) กำหนดสิทธิ์แบบ checkbox tree, สร้างผู้ใช้ กำหนดสถานที่และแผนก ขอบเขตข้อมูล สิทธิ์ VIP, รีเซ็ตรหัสผ่าน และระงับบัญชี | สิทธิ์การใช้งาน |
| สถานที่ / แผนก / AE TitleLocation · Department · AE Title | โครงสร้างองค์กร 3 ระดับ สถานที่ → แผนก → เครื่องส่งภาพ (AE Title) ซึ่งเป็นตัวกำหนดว่าใครเห็นการตรวจใด รองรับหลายสาขา/หลายอาคาร | ข้อมูลหลัก |
| ProtocolExam Protocol | รหัสและชื่อการตรวจ ผูกกับ modality และส่วนของร่างกาย ใช้กับ Worklist และใบสั่งตรวจจาก HIS | ข้อมูลหลัก |
| โรงพยาบาลปลายทางRefer Hospital | รายชื่อและอีเมลโรงพยาบาลที่ส่งต่อบ่อย สำหรับเลือกในหน้าส่งต่อ | ข้อมูลหลัก |
| แก้ไข Tag ขาออกTag Morphing |
แก้ไข DICOM tag ตามข้อกำหนดของปลายทางขณะส่งออก/ส่งต่อ โดยไม่แตะต้นฉบับในคลัง
|
การเชื่อมต่อ |
| ระบบที่เชื่อมต่อIntegration Clients | ออก API key ให้ HIS / RIS แต่ละระบบเพื่อเปิดภาพจากหน้าจอของตนเอง แสดง key ครั้งเดียว เปลี่ยน key ได้ ดูการใช้งานล่าสุด และปิดใช้งานพร้อมตัด session ทั้งหมดทันที | การเชื่อมต่อ |
| HL7 IntegrationHL7 Endpoints & Messages | กำหนดปลายทาง HL7 ขาเข้า/ขาออก (MSH-3/4/5/6, host/port) และกล่องข้อความ HL7 ย้อนหลัง กรองตามทิศทาง สถานะ ชนิดข้อความ ดูข้อความต้นฉบับและผลการประมวลผล | การเชื่อมต่อ |
| DICOM NodesPACS Allowlist | ลงทะเบียน PACS / workstation / เครื่องที่ดึง Worklist (AE Title, Host:Port) กำหนดสิทธิ์ราย node: Echo, Store, Worklist, Query, C-MOVE, C-GET ทดสอบ C-ECHO ได้จากหน้าจอ และแสดงเครื่องที่ยังไม่ลงทะเบียนที่พยายามส่งภาพเข้ามา | การเชื่อมต่อ |
| System SettingsRuntime Configuration | ค่าปรับแต่ง 25 รายการใน 6 หมวด (General, Storage, Tag Morphing, Email, Monitoring, HL7) เช่น ชื่อสถาบัน ความจุพื้นที่ เกณฑ์แจ้งเตือนดิสก์ อีเมลรับแจ้งเตือน มีการตรวจสอบค่าและบันทึกผู้แก้ไข | ระบบ |
| CacheCache Management | ดูกลุ่มข้อมูลที่ cache ไว้ จำนวนรายการ และเวลาคงเหลือ ล้างทีละกลุ่มหรือทั้งหมดได้เมื่อต้องการให้ข้อมูลหลักที่แก้ไขมีผลทันที | ระบบ |
1.3
สิทธิ์การใช้งานและขอบเขตข้อมูล
RBAC & Data Access Scopeควบคุมได้ทั้ง "ทำอะไรได้" (สิทธิ์ตามบทบาท) และ "เห็นข้อมูลของใคร" (ขอบเขตข้อมูล) — รองรับหลักการเข้าถึงเท่าที่จำเป็นตาม PDPA
69
สิทธิ์ย่อย
แยกตามหน้าจอและการกระทำ เช่น เปิด Viewer, ลบ, กู้คืน, รวม, ส่งออก, ส่งต่อ, Emergency Order — สิทธิ์ใหม่ปิดไว้เป็นค่าเริ่มต้นเสมอ
5
ประเภทบทบาท
Administrator, Doctor, Medical Tech, Nurse, Staff — สร้างกลุ่มย่อยได้ไม่จำกัด
3
ระดับขอบเขตข้อมูล
เฉพาะของตนเอง / ตามแผนก / ทั้งระบบ โดยแผนกผูกกับเครื่องส่งภาพ (AE Title) และสถานที่
VIP
ระดับเหนือสุด
การตรวจ VIP เห็นได้เฉพาะผู้ใช้ที่มอบหมาย ผู้อื่นจะได้ผล "ไม่พบ" แม้มีสิทธิ์ทั้งระบบ
1.4
ประสบการณ์ใช้งานและความสามารถร่วม
Cross-cutting UX| ฟีเจอร์ | รายละเอียด | กลุ่ม |
|---|---|---|
| เข้าสู่ระบบอย่างปลอดภัยLogin & Session | ป้องกันการเดารหัสผ่าน (10 ครั้ง / 15 นาที) แจ้งจำนวนครั้งที่เหลือ ต่ออายุ session อัตโนมัติแบบไม่สะดุด และออกจากระบบทันทีเมื่อ session ถูกเพิกถอน | ความปลอดภัย |
| เลือกสถานที่ / แผนกLocation & Department Switcher | ผู้ใช้ที่ประจำหลายสาขาหรือหลายแผนกเลือกบริบทการทำงานได้จากแถบด้านบน ระบบจำค่าไว้ต่อผู้ใช้ | ทุกบทบาท |
| ข้อความภายในSecure Messaging (Chat) | แชท 1:1 และกลุ่มภายในองค์กร หน้าต่างลอยใช้คู่กับงานอื่นได้ แสดงสถานะอ่านแล้ว แจ้งข้อความใหม่แบบเรียลไทม์ — ข้อมูลไม่ออกนอกโรงพยาบาล | ทุกบทบาท |
| โปรไฟล์และรหัสผ่านProfile | แก้ไขชื่อ อัปโหลดรูปโปรไฟล์ (ตรวจชนิดไฟล์จริงที่ server) และเปลี่ยนรหัสผ่าน | ทุกบทบาท |
| รองรับทุกขนาดจอ + โหมดมืดResponsive & Dark Mode | เมนูพับเป็น drawer บนแท็บเล็ต/มือถือ ย่อเหลือไอคอนบนคอมพิวเตอร์ได้ สลับโหมดสว่าง/มืดและจำค่าไว้ | ทุกบทบาท |
| โหลดเร็วPerformance | ขนาดที่โหลดครั้งแรกลดจาก 4.6 MB เหลือ 314 KB, โหลดหน้าล่วงหน้าเมื่อเบราว์เซอร์ว่าง, ภาพย่อเอกสารสร้างที่ server (ตัวอย่างไฟล์ TIFF 20 MB → 9 KB) และรีโหลดอัตโนมัติเมื่อมีเวอร์ชันใหม่ | ประสิทธิภาพ |
2.1
ภาพรวมสถาปัตยกรรม
Architecture Overviewออกแบบแบบ event-driven: รับภาพ → ตรวจสอบตัวตนผู้ป่วย → ทำดัชนี → พร้อมให้ค้นหาและเปิดดู แต่ละส่วนแยกกันทำงาน หากส่วนใดล่ม ข้อมูลไม่สูญหายและประมวลผลต่อเมื่อกลับมา
PACS ของโรงพยาบาล
ภาพทุก modality: CT, MR, CR/DX, US, MG, NM/PET, XA, Endoscope ฯลฯ
DICOM
C-STORE
C-STORE
Vantyx Gateway
รับภาพ DICOM, บีบอัด JPEG-LS, Modality Worklist, DICOMweb
Event
Ingest Pipeline
คิวข้อความ + worker, EMPI จับคู่ผู้ป่วย, ทำดัชนี, แปลงวิดีโอ
Index
Web App + Viewer
ค้นหา เปิดภาพ แนบเอกสาร ส่งต่อ ส่งออก
HIS / RIS
ระบบสารสนเทศโรงพยาบาล
HL7 v2
MLLP
MLLP
HL7 Interface
รับ ADT / ORM, ส่ง ORU "ภาพพร้อม", Launch API เปิดภาพจาก HIS
S3
Object Storage
Hot (SSD) → Cold (HDD) อัตโนมัติ, ทำสำเนาข้ามดิสก์/ข้ามเครื่อง
Backup
PostgreSQL + สำรองข้อมูล
WAL ต่อเนื่อง, Full/Diff, กู้คืน ณ จุดเวลา
ทั้งระบบทำงานบน Docker Compose 25 services ติดตั้งบน server ของโรงพยาบาล (on-premise)
2.2
การเชื่อมต่อ DICOM และมาตรฐาน
DICOM Connectivity| ความสามารถ | รายละเอียด | มาตรฐาน |
|---|---|---|
| รับภาพ DICOMStorage SCP (C-STORE) | รับ study ที่ PACS ทุกยี่ห้อของโรงพยาบาลส่งต่อมา (บทบาท VNA) รวม Storage Commitment | DICOM PS3.4 / PS3.7 |
| ให้ PACS / workstation ค้นและดึงภาพจาก VantyxQ/R SCP — C-ECHO · C-FIND · C-MOVE · C-GET | เปิดสิทธิ์ Echo / Store / Find / Worklist / Move / Get แยกต่อเครื่อง C-MOVE ส่งได้เฉพาะปลายทางที่ลงทะเบียน C-GET ปิดไว้จนกว่าจะเปิดให้ | DICOM Q/R |
| ควบคุมเครื่องที่เชื่อมต่อDICOM Node Allowlist | ปฏิเสธ AE Title ที่ไม่ได้ลงทะเบียน ตรวจ Called AET แก้ไขรายการผ่านหน้าจอแล้วมีผลทันทีโดยไม่ต้องรีสตาร์ท และ sync ซ้ำทุก 5 นาทีพร้อมแจ้งเตือนหากไม่ตรงกัน | ความปลอดภัย |
| Modality WorklistMWL SCP (C-FIND) | ตอบรายการนัดตรวจจากฐานข้อมูลแบบสด (ไม่ต้อง sync ไฟล์) การยกเลิกจาก HIS มีผลทันที รองรับชื่อภาษาไทย (UTF-8) ออก StudyInstanceUID ล่วงหน้าเพื่อจับคู่ใบสั่งกับภาพได้ตรงตัว และเติม AE ของเครื่องที่ถามให้เมื่อ HIS ไม่ทราบ | DICOM MWL · IHE SWF |
| DICOMwebWADO-RS / WADO-URI / Rendered | ให้บริการภาพผ่าน HTTP สำหรับ Viewer พร้อมยืนยันตัวตนทุกคำขอ และภาพ JPEG ที่ server เรนเดอร์สำหรับมือถือ | DICOM PS3.18 |
| บีบอัดแบบไม่สูญเสียตอนรับภาพJPEG-LS Lossless at Ingest |
บีบอัดทันทีที่รับเข้า ค่า pixel เหมือนต้นฉบับทุกจุด
(ตรวจสอบแล้ว) ภาพที่บีบอัดมาแล้ว (US/XA JPEG, วิดีโอ)
คงไว้ตามเดิม เปิด/ปิดได้ต่อไซต์
|
JPEG-LS (1.2.840.10008.1.2.4.80) |
| แปลง Transfer Syntax อัตโนมัติOn-the-fly Transcoding | เมื่อปลายทางไม่รองรับรูปแบบที่จัดเก็บ ระบบแปลงให้ระหว่างส่ง เครื่องรุ่นเก่ายังรับภาพได้ | DICOM PS3.5 |
| ชนิดข้อมูล DICOM พิเศษPDF · ECG · SR · RDSR · Video | Encapsulated PDF, คลื่นไฟฟ้าหัวใจ, Structured Report, รายงานปริมาณรังสี และวิดีโอ DICOM (MPEG-2 / H.264 / HEVC) ที่แปลงเป็น MP4 พร้อม cache ให้เล่นและเลื่อนตำแหน่งได้ทันที | DICOM IODs |
2.3
การรับและจัดการข้อมูล
Ingestion & Data Management| ความสามารถ | รายละเอียด | จุดเด่น |
|---|---|---|
| ไปป์ไลน์รับภาพแบบคิวEvent-driven Ingest | เมื่อ study รับครบ ระบบส่งเหตุการณ์เข้าคิวที่ทนทาน (durable quorum queue) พยายามซ้ำสูงสุด 5 ครั้ง ข้อความที่ผิดพลาดแยกไป dead-letter queue พร้อมแจ้งเตือน — ไม่มีภาพตกหล่นเงียบ ๆ | ไม่สูญหาย |
| ทะเบียนผู้ป่วยกลางEMPI Patient Matching | จับคู่ผู้ป่วยตามลำดับ: ตัวตนจาก HIS (HN) → ตัวตนจากแหล่งภาพ → ชื่อ + วันเกิด → สร้างทะเบียนใหม่ พร้อมระดับความมั่นใจ ป้องกันการสร้างผู้ป่วยซ้ำเมื่อภาพเข้ามาพร้อมกัน และมีเครื่องมือค้นหาและรวมรายการซ้ำ | ข้อมูลถูกต้อง |
| ปรับข้อมูลให้เป็นมาตรฐานNormalization | ปรับเวลาเป็นเขตเวลาไทย จัดการวันเกิดที่ผิดรูปแบบโดยไม่ทำให้การรับภาพล้มเหลว และบันทึกทุก modality ใน study ที่มีหลายชนิด | ข้อมูลถูกต้อง |
| กู้เหตุการณ์ที่ตกหล่นAuto Reconciliation | ทุก 5 นาทีเทียบรายการในคลังภาพกับดัชนี และส่งเหตุการณ์ที่ขาดซ้ำอัตโนมัติ (พิสูจน์แล้ว: กู้ 108 study หลังส่วนประมวลผลดับ 3 ชั่วโมง) | ไม่สูญหาย |
| นำเข้าจาก ZIPStreaming Import | แตกไฟล์แบบ streaming ส่งเข้าคลังโดยตรงโดยไม่สร้างไฟล์ชั่วคราว ทำงานขนานครั้งละ 5 ไฟล์ แนบเอกสาร non-DICOM เข้าการตรวจให้อัตโนมัติ | งานเวชระเบียน |
| เอกสารและสื่อ non-DICOMNon-DICOM Archive | เก็บภาพ PDF เอกสาร Office เสียง และวิดีโอ ร่วมกับภาพ DICOM แยกสิทธิ์ตามแผนก ภาพย่อสร้างที่ server วิดีโอแปลงเป็น MP4 เบื้องหลัง และอัปโหลดล่วงหน้าสำหรับผู้ป่วยที่ยังไม่มี HN ได้ | คลังกลางเดียว |
| สถิติการใช้งานImaging Volume Analytics | นับปริมาณการตรวจรายวัน/รายชั่วโมง ตาม modality และแหล่งภาพ อัปเดตอัตโนมัติภายใน ~15 วินาที แม้ฐานข้อมูลมีขนาดใหญ่ | ผู้บริหาร |
2.4
วงจรชีวิตการตรวจ การแบ่งปัน และการส่งออก
Study Lifecycle, Sharing & Egress| ความสามารถ | รายละเอียด | จุดเด่น |
|---|---|---|
| ลบ / กู้คืน / ลบถาวรSoft Delete · Restore · Hard Delete | ลบชั่วคราวแบบกู้คืนได้ (ห้ามลบหากเคยส่งต่อแล้ว) การลบถาวรเป็นช่องทางเดียวที่ทำลายภาพจริง ต้องยืนยันและบันทึก audit | ควบคุมได้ |
| รวมการตรวจStudy Merge | รวม study ที่แยกกันของผู้ป่วยรายเดียวกัน ทำในคลังภาพครั้งเดียว ข้อมูลที่เกี่ยวข้อง (ค่าวัด รายการโปรด ฯลฯ) ย้ายตามให้ครบ | ข้อมูลถูกต้อง |
| แก้ไขข้อมูลผู้ป่วยEdit Patient | แก้ HN ชื่อ เพศ วันเกิด ในธุรกรรมเดียวครอบคลุมทุกการตรวจ ไม่แตะไฟล์ DICOM ต้นฉบับ ตรวจ HN ซ้ำข้ามทุกแหล่ง | ต้นฉบับไม่ถูกแก้ |
| ส่งต่อโรงพยาบาลอื่นSecure Referral Link | ลิงก์ token 256-bit เก็บเฉพาะค่า hash อายุสูงสุด 30 วัน เพิกถอนได้ ZIP สร้างขณะดาวน์โหลดโดยไม่เก็บสำเนา จำกัด 20 ครั้ง / 15 นาที และบันทึกทุกการดาวน์โหลด | ความปลอดภัย |
| ส่งออก ZIPStudy Export | DICOM ต้นฉบับ / JPEG / non-DICOM ใช้ token ครั้งเดียว จำกัดงานพร้อมกัน 3 งานทั้งระบบ (1 ต่อผู้ใช้) เพื่อไม่กระทบผู้ใช้อื่น — ทดสอบ CT 1,351 ภาพ 678 MB เสร็จใน 58 วินาที | ไม่กระทบระบบ |
| แก้ไข Tag ขาออกTag Morphing (Attribute Coercion) | ปรับ DICOM tag ตามข้อกำหนดของแต่ละปลายทางขณะส่ง โดยต้นฉบับในคลังไม่เปลี่ยน ถ้ากฎใช้ไม่ได้ระบบหยุดส่ง (fail-closed) แทนการส่งข้อมูลผิด | IHE-style coercion |
| เชื่อมต่อเครื่องเขียน CD/DVDCD Writer API | API สำหรับระบบเขียนแผ่นภาพให้ผู้ป่วย ยืนยันตัวตนด้วย API key | REST API |
2.5
การเชื่อมต่อกับ HIS
HIS / RIS Integrationเชื่อมต่อตลอดวงจรงานรังสี: HIS ลงทะเบียนผู้ป่วยและสั่งตรวจ → เครื่องตรวจดึง Worklist → ภาพเข้าคลัง → แจ้ง HIS ว่าภาพพร้อม → แพทย์เปิดภาพจากหน้าจอ HIS
| ความสามารถ | รายละเอียด | มาตรฐาน |
|---|---|---|
| HL7 v2 ผ่าน MLLPHL7 Interface Engine | รับข้อความผ่าน TCP/MLLP ตอบ ACK (AA / AE / AR) ทันทีที่ข้อความเข้าคิวอย่างปลอดภัย ตรวจข้อความซ้ำ ประมวลผลตามลำดับ รองรับหลายปลายทาง (หลาย HIS / RIS) | HL7 v2.x (ทดสอบ v2.5) |
| รับข้อมูลผู้ป่วยInbound ADT | A04 / A28 สร้างผู้ป่วย · A08 / A31 ปรับปรุงข้อมูล · A40 รวมผู้ป่วย | ADT^A04/A08/A28/A31/A40 |
| รับใบสั่งตรวจInbound Orders → Worklist | สร้าง/แก้ไข/ยกเลิกใบสั่ง (NW, XO/RP, CA/OC/DC/CR) แปลงเป็นรายการ Worklist ให้เครื่องตรวจ มีกลไกเลือกฟิลด์สำรองรองรับ HIS หลายผู้ผลิตในประเทศไทย ใบสั่งหมดอายุใน 7 วัน | ORM^O01 · OMI^O23 · OMG^O19 |
| แจ้ง HIS ว่าภาพพร้อมOutbound Results | ส่ง 1 ครั้งต่อ study ใหม่ พร้อมเลข Accession และ StudyInstanceUID รอ ACK (ปรับได้ 1–120 วินาที) พยายามซ้ำ 5 ครั้ง แล้วแจ้งเตือนหากไม่สำเร็จ | ORU^R01 · แนวทาง IHE |
| เปิดภาพจาก HISViewer Launch API | HIS เรียก API ด้วย key ของตนเอง ได้ลิงก์ใช้ครั้งเดียว (token 256-bit อายุ 30–600 วินาที) แพทย์เปิดภาพได้ทันทีโดยไม่ต้องมีบัญชี Vantyx — ทุกการเปิดถูกบันทึกผ่านผู้ใช้เฉพาะของระบบที่เชื่อมต่อ | REST APIใช้ครั้งเดียว |
| Emergency OrderDowntime Workflow | สร้าง Worklist ด้วยมือเมื่อ HIS ล่มหรือผู้ป่วยฉุกเฉินไม่ทราบตัวตน ต้องมีสิทธิ์ ระบุเหตุผล และบันทึก audit | Business continuity |
| ความปลอดภัยของ HL7HL7 Security & Inbox | จำกัด IP ต้นทาง (CIDR) และตรวจ MSH-3/4 กับปลายทางที่เปิดใช้ เก็บข้อความต้นฉบับ 90 วันในกล่องข้อความสำหรับผู้ดูแล พร้อมแจ้งเตือนเมื่อปลายทางไม่ตอบ | ความปลอดภัย |
2.6
การจัดเก็บ สำรองข้อมูล และกู้คืน
Storage, Backup & Disaster Recovery| ความสามารถ | รายละเอียด | จุดเด่น |
|---|---|---|
| Object Storage แบบ S3SeaweedFS | เก็บภาพ DICOM เอกสารแนบ และวิดีโอแยก bucket ขยายความจุได้โดยเพิ่มดิสก์/เครื่อง | S3 API |
| จัดชั้นข้อมูลร้อน-เย็นอัตโนมัติHot / Cold Tiering | ข้อมูลใหม่อยู่บน SSD (เปิดเร็ว) ข้อมูลที่ไม่มีการเขียน 14 วัน (ปรับได้ 1 วัน – 1 ปี) ย้ายไป HDD ทุกคืนอัตโนมัติ — ลดต้นทุนดิสก์ราคาสูง | ลดต้นทุน |
| ทำสำเนาข้อมูลภาพReplication | Single VM: 2 สำเนาบนดิสก์กายภาพคนละลูก · ชุด HA: สำเนาข้าม server หากดิสก์/เครื่องหาย ระบบยังเขียนต่อได้และสร้างสำเนาคืนเองเมื่อกลับมา พร้อมแจ้งเตือนสำเนาที่ขาด | ทนต่อดิสก์เสีย |
| สำรองฐานข้อมูลต่อเนื่องpgBackRest — WAL + PITR | สำรองต่อเนื่องทุก 5 นาที Full รายสัปดาห์ + Differential รายวัน เก็บ 14 ชุด (~14 สัปดาห์) กู้คืน ณ จุดเวลาใดก็ได้ (Point-in-Time Recovery) | RPO ≈ 5 นาที |
| ทดสอบกู้คืนอัตโนมัติWeekly Restore Test | ทุกสัปดาห์ระบบทดลองกู้คืนข้อมูลจริงในพื้นที่แยก แจ้งเตือนหากการทดสอบไม่เกิดขึ้น ตรวจสถานะการสำรองทุก 10 นาที | พิสูจน์ได้ |
| คู่มือกู้ระบบDR Runbooks | ขั้นตอนกู้คืนที่ซ้อมจริงแล้ว: กู้ฐานข้อมูล, PITR, ดิสก์ระบบเสีย, สลับเครื่องในชุด HA | ซ้อมแล้ว |
2.7
ความปลอดภัยและการปฏิบัติตามข้อกำหนด
Security & Compliance| ความสามารถ | รายละเอียด | กลุ่ม |
|---|---|---|
| การยืนยันตัวตนและ SessionJWT + Refresh Rotation | Access token 30 นาที, refresh token 3 วันใน cookie แบบ httpOnly / SameSite=Strict หมุนเวียนทุกครั้งพร้อมตรวจจับการใช้ซ้ำ เพิกถอน session ได้ทันที และจำกัดการเดารหัสผ่าน 10 ครั้ง / 15 นาที | Authentication |
| ป้องกันภาพรั่วไหลImage Authorization | ทุกคำขอภาพต้องมี token ที่ถูกต้อง ตรวจที่ gateway ก่อนส่งแม้ภาพอยู่ใน cache อนุญาตเฉพาะคำขออ่านและเส้นทางที่กำหนด ลิงก์ไฟล์/วิดีโอลงลายมือชื่อ HMAC และหมดอายุ | Data protection |
| จำกัดอัตราการเรียกใช้Rate Limiting | ค่าพื้นฐาน 300 ครั้ง/นาที/IP และกำหนดเฉพาะงาน เช่น ภาพ DICOMweb 6,000/นาที, อัปโหลด 20/นาที, HL7 600/นาที, เปิดภาพจาก HIS 60/นาที | Availability |
| สิทธิ์และขอบเขตข้อมูลRBAC + Data Scope | 69 สิทธิ์ย่อย, ขอบเขตตามแผนก / สถานที่ / เครื่องส่งภาพ, VIP เฉพาะบุคคล — ออกแบบเพื่อความเป็นส่วนตัวของผู้ป่วยตาม PDPA | PDPA |
| บันทึกการตรวจสอบAudit Trail | บันทึกทุกการกระทำสำคัญในฐานข้อมูลแยก เก็บ 90 วัน รวมการเข้าสู่ระบบที่ล้มเหลว การดาวน์โหลดของผู้รับภายนอก และข้อความ HL7 | Accountability |
| เครือข่ายและการเชื่อมต่อระหว่างระบบNetwork & M2M Keys | เปิดสู่เครือข่ายเฉพาะ Web, Viewer, DICOM และ HL7 ส่วนภายในผูกกับ localhost ระบบที่เชื่อมต่อแต่ละตัวมี API key ของตนเอง หมุนเปลี่ยนได้ | Hardening |
2.8
ประสิทธิภาพ การขยายระบบ และ High Availability
Performance, Scalability & HAผลวัดจริงจากการทดสอบโหลด (load test) และฐานข้อมูลทดสอบขนาด 1 ล้านการตรวจ / 300,000 ผู้ป่วย — ค่าจริงขึ้นกับฮาร์ดแวร์ของแต่ละโรงพยาบาล
| การทดสอบโหลด | ผู้ใช้พร้อมกัน | เฟรมภาพ/นาที | เวลาเฟรมนอก cache (p95) | MPR พร้อม (p95) | Error |
|---|---|---|---|---|---|
| Single VM ขนาด S6 vCPU / 16 GB | 10 | 3,400 | 547 ms | 7.0 s | 0 |
| Server ทดสอบ12 threads | 20 | สูงสุด 7,935 (6.6 GB/นาที) | 356 ms | 13.7 s (p50 1.7 s) | 0 |
| ชุด HA (cache อุ่น)2 Server + Witness | 10 | 3,294 | 663 ms | 6.7 s | 0 |
| ฐานข้อมูล 1 ล้านการตรวจ | ก่อนปรับปรุง | หลังปรับปรุง |
|---|---|---|
| ค้นรายการการตรวจStudy list | 61 ms | 24 ms |
| ค้นรายชื่อผู้ป่วยPatient list | 6.6 s | 0.3–0.7 s |
| ค้นเอกสารแนบFiles list | > 60 s | 12 ms |
| ค้นบันทึก auditAudit list | 220 ms | 22 ms |
| จับคู่ผู้ป่วย (ชื่อ + วันเกิด)EMPI match | 42 ms | 1.6 ms |
| ความสามารถ | รายละเอียด | จุดเด่น |
|---|---|---|
| Server หลายชุดพร้อม Load BalancerHorizontal Scaling | API server 3 ชุด (สูงสุด 8 ชุดบนเครื่อง 32 core) กระจายงานแบบ least-connection งานหนัก เช่น ส่งออก ZIP ไม่ทำให้ผู้ใช้อื่นช้า | ขยายได้ |
| Cache ภาพที่ GatewayEdge Pixel Cache | เก็บเฟรมภาพและภาพตัวอย่าง 7 วัน ภาพที่อยู่ใน cache ตอบได้ในระดับ 6–26 ms (p50) | เปิดภาพเร็ว |
| ชุด High Availability2 Servers + 1 Witness | Virtual IP, ฐานข้อมูล standby ทั้ง 4 ชุด, Redis Sentinel, storage ทำสำเนาข้ามเครื่อง ผลซ้อมจริง: VIP ย้ายเองใน 5–10 วินาที, Redis สลับเองใน ~6 วินาที, ปิดเครื่องหลักกะทันหัน — ฐานข้อมูลสลับด้วยคำสั่งเดียว กู้บริการครบใน 92 วินาทีหลังสั่ง (ออกแบบเพื่อกันข้อมูลแตกเป็นสองชุด) | ซ้อมแล้ว |
| เวลาที่ภาพพร้อมในรายการIngest Latency | p50 ~35 วินาที / p95 ~50 วินาที นับจากเครื่องส่งภาพเสร็จ (รวมเวลารอ 30 วินาทีเพื่อยืนยันว่า study รับครบแล้ว) | ใกล้เรียลไทม์ |
2.9
การเฝ้าระวังและบำรุงรักษาอัตโนมัติ
Monitoring & Maintenance| ความสามารถ | รายละเอียด | ความถี่ |
|---|---|---|
| ตรวจสุขภาพบริการService Health | ตรวจ 15 บริการหลัก แจ้งเตือนทางอีเมลและบันทึก audit พร้อมช่วงหน่วงกันแจ้งซ้ำ | ทุก 15 นาที |
| พื้นที่จัดเก็บและดิสก์Storage & Disk | ตรวจทุก volume และดิสก์ของเครื่อง (ระบบ / สำรองข้อมูล) เกณฑ์เตือนปรับได้ 50–99% | ทุก 30 นาที |
| การสำรองและฐานข้อมูลBackup & DB Probe | สถานะการสำรอง WAL, การทดสอบกู้คืนที่ค้าง, ฐานข้อมูลหลัก/สำรอง (ชุด HA แจ้งภายใน ~2 นาที) | ทุก 10 นาที |
| คิวและการเชื่อมต่อQueues, HL7, DICOM Nodes | dead-letter queue ของการรับภาพและ HL7, ปลายทาง HL7 ไม่ตอบ, รายการ DICOM Node ไม่ตรงกัน, สำเนาภาพที่ขาด | ต่อเนื่อง |
| งานทำความสะอาดรายคืนNightly Housekeeping | บันทึก audit / ข้อความ HL7 / ถังขยะเอกสาร เก็บ 90 วัน, Worklist หมดอายุ 7 วัน, ล้าง token และไฟล์ชั่วคราว, จัดการ cache วิดีโอตามอายุและขนาด | ทุกคืน |
2.10
รูปแบบการติดตั้งและขนาดระบบ
Deployment Models & Sizingติดตั้งบน VMware ในศูนย์ข้อมูลของโรงพยาบาล ใช้ IP ภายใน ไม่พึ่งพา Cloud — ตอนติดตั้ง ระบบอ่านขนาดเครื่องจริงแล้วเลือกชุดค่าปรับแต่ง (ฐานข้อมูล, คลังภาพ, cache, จำนวน server) ของระดับที่ใกล้ที่สุดให้อัตโนมัติ และมีเครื่องมือตรวจสอบว่าค่าถูกใช้งานจริง ตัวเลขในตารางคือขนาดอ้างอิงของแต่ละระดับ ไม่ใช่สเปกขั้นต่ำ — ข้อกำหนดขั้นต่ำอยู่ในกรอบด้านล่าง
| ระดับ | vCPU / RAM / SSD (hot) | เหมาะสำหรับ | ที่มาของตัวเลข |
|---|---|---|---|
| XSDemo | 4 vCPU / 8 GB / 250 GB | สาธิตและทดสอบเท่านั้น — ไม่แนะนำสำหรับ production | Demo เท่านั้น |
| SSmall hospital | 8 vCPU / 16 GB / 500 GB | โรงพยาบาลขนาดเล็ก ~10 ผู้ดูภาพพร้อมกัน — ขั้นต่ำสำหรับ production | วัดจริงด้วย load test |
| MGeneral hospital | 16 vCPU / 32 GB / 1 TB | โรงพยาบาลทั่วไป — ขนาดที่วางไว้สำหรับ production ทั่วไป | ค่าประมาณ |
| LLarge hospital | 24 vCPU / 64 GB / 2 TB | โรงพยาบาลขนาดใหญ่ | ค่าประมาณ |
| XLImaging centre | 32 vCPU / 64 GB / 10 TB | ศูนย์ภาพหลายแหล่ง / เก็บข้อมูล hot นาน | ค่าประมาณ |
"ค่าประมาณ" = คำนวณจากสูตรที่ได้จากระดับที่วัดจริง ยังไม่มีเครื่องจริงให้วัด — ต้องทดสอบโหลดซ้ำบนเครื่องของโรงพยาบาลตอนตรวจรับ (acceptance) · เลือกแต่ละมิติแยกกันได้ เช่น 16 vCPU + 32 GB + SSD 1 TB
ข้อกำหนดขั้นต่ำ (Single VM)
CPU / RAMproduction ขั้นต่ำ 8 vCPU / 16 GB · ระบบต้องการอย่างน้อย
6 vCPU (น้อยกว่านี้ติดตั้งไม่ได้
หากไม่ปรับค่าเฉพาะ)
OS diskSSD ≥ 100 GB — ระบบปฏิบัติการ, Docker images และฐานข้อมูล
PostgreSQL ×4
Hot SSDตามคอลัมน์ SSD (hot) ในตาราง — ประเมินได้จาก 14 วัน ×
ปริมาณภาพต่อวัน × 1.5
Cold HDDตามปริมาณภาพที่ต้องเก็บระยะยาว (ข้อมูลที่ไม่มีการเขียนเกิน 14
วันย้ายจาก SSD มาอัตโนมัติ)
Backup diskแยกลูก เริ่มต้นประมาณ 3 เท่าของฐานข้อมูล
และเพิ่มตามปริมาณภาพที่รับต่อวัน (เก็บย้อนหลัง ~14 สัปดาห์) —
ระบบแจ้งเตือนเมื่อใกล้เต็ม
สำเนาภาพhot และ cold มีอย่างละ 2 ลูก (ดิสก์กายภาพคนละลูก) เพื่อเก็บภาพ
2 สำเนา
Single VM (ไม่มี HA)
เครื่องเดียว ≥ 8 vCPU / 16 GB, SSD ระบบ 100 GB + ดิสก์ข้อมูล 5 ลูก (hot ×2, cold ×2, backup) ภาพทุกภาพมี 2 สำเนาบนดิสก์คนละลูก ติดตั้งด้วยสคริปต์อัตโนมัติ
High Availability (L1)
Server 2 เครื่อง + Witness 1 เครื่อง (≥ 2 vCPU / 3 GB) ทุกส่วนมีคู่สำรอง ภาพทำสำเนาข้ามเครื่อง ผ่านการซ้อมดับเครื่องจริงทุกตำแหน่ง
DICOM Storage · Q/R · MWL · DICOMweb
HL7 v2.x ADT · ORM/OMI/OMG · ORU · MLLP
IHE แนวทาง Scheduled Workflow
JPEG-LS Lossless
S3 Object Storage
PostgreSQL 18 + pgBackRest PITR
PDPA RBAC · Data Scope · Audit
2.11
ขอบเขตปัจจุบัน
Current Scopeหมายเหตุ — สิ่งที่ยังไม่รวมในเวอร์ชันปัจจุบัน
- ยังไม่มีระบบเขียนผลอ่านภาพ (Radiology Reporting) — ORU ที่ส่งให้ HIS หมายถึง "ภาพพร้อม" ไม่ใช่ผลอ่าน
- Vantyx ยังไม่ดึงภาพ (Query / Retrieve) จาก PACS อื่น — รับภาพแบบส่งเข้ามา (push) เป็นหลัก และยังไม่เปิด QIDO-RS / STOW-RS ให้ระบบภายนอก
- ฐานข้อมูลสำรองครบถ้วนพร้อม PITR ส่วนไฟล์ภาพ DICOM ป้องกันด้วยการทำสำเนาข้ามดิสก์/ข้ามเครื่อง — การสำรองนอกสถานที่ (3-2-1) ต้องวางแผนเพิ่มตามนโยบายของโรงพยาบาล
- ชุด HA ยังไม่สลับฐานข้อมูลอัตโนมัติ — ปัจจุบันเจ้าหน้าที่สั่งด้วยคำสั่งเดียว เสร็จใน ~1.5 นาที ทำเป็นอัตโนมัติได้ภายหลังโดยไม่ต้องซื้อเครื่องเพิ่ม