Software Requirements Specification (SRS)

ระบบรังสีวิทยา (Radiology System)

เวอร์ชัน: 1.0

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

จัดทำโดย: ทีมพัฒนาระบบ HIS โรงพยาบาลค่ายธนรัชน์

สารบัญ

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

1. บทนำ

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

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

1.2 ขอบเขต (Scope)

ระบบรังสีวิทยาจะดำเนินการ:

✅ การจัดการข้อมูลพื้นฐาน - การกำหนดรายการ X-Ray และการเชื่อมโยงค่าบริการ
✅ การส่งตรวจรังสีวิทยา - การรับคำสั่งตรวจจากแผนกต่างๆ ผ่านระบบ Online
✅ การลงทะเบียนและจัดการคิว - การออกเลข XN และจัดการผู้ป่วย
✅ การรายงานผลและการอ่านฟิล์ม - การบันทึกผลโดยรังสีแพทย์
✅ การจัดการฟิล์ม X-Ray - การบันทึกฟิล์มใช้ ฟิล์มเสีย และการยืม-คืนฟิล์ม
✅ การนัดหมายและการติดตาม - การนัดฟังผลและการส่งต่อ
✅ การพิมพ์เอกสาร - Request X-Ray, XN Label, ใบรายงานผล, ใบนัด

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

คำศัพท์	คำอธิบาย
XN	X-Ray Number - หมายเลขการตรวจรังสี
HN	Hospital Number - หมายเลขประจำตัวผู้ป่วย
PACS	Picture Archiving and Communication System - ระบบจัดเก็บและสื่อสารภาพทางการแพทย์
DICOM	Digital Imaging and Communications in Medicine - มาตรฐานการสื่อสารภาพทางการแพทย์
CR	Computed Radiography - เอกซเรย์คอมพิวเตอร์
DR	Digital Radiography - เอกซเรย์ดิจิทัล
CT	Computed Tomography - การถ่ายภาพรังสีคอมพิวเตอร์
MRI	Magnetic Resonance Imaging - การถ่ายภาพด้วยคลื่นแม่เหล็กไฟฟ้า
Ultrasound	การตรวจด้วยคลื่นเสียงความถี่สูง
Fluoroscopy	การตรวจด้วยรังสีแบบเรียลไทม์
Contrast	สารทึบรังสี
Radiologist	รังสีแพทย์ - แพทย์ผู้เชี่ยวชาญด้านรังสีวิทยา
Radiographer	นักรังสีเทคนิค - เจ้าหน้าที่ปฏิบัติการถ่ายรังสี
Film	ฟิล์มเอกซเรย์
Cassette	ตลับใส่ฟิล์ม
View/Projection	ท่า/มุมการถ่ายภาพ
AP	Anterior-Posterior - ท่าถ่ายหน้า-หลัง
PA	Posterior-Anterior - ท่าถ่ายหลัง-หน้า
Lateral	ท่าถ่ายข้าง
Oblique	ท่าถ่ายเฉียง
STAT	Immediate/Urgent - ความเร่งด่วนสูงสุด
Routine	การตรวจแบบปกติ
Template	แม่แบบข้อความรายงานผล

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

TOR ระบบรังสีวิทยา โรงพยาบาลค่ายธนรัชน์
มาตรฐาน DICOM (Digital Imaging and Communications in Medicine)
มาตรฐาน HL7 (Health Level Seven) สำหรับการแลกเปลี่ยนข้อมูล
แนวทางการปฏิบัติงานรังสีวิทยาของกระทรวงสาธารณสุข
พระราชบัญญัติการประกอบโรคศิลปะ พ.ศ. 2542
มาตรฐานความปลอดภัยทางรังสี

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

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

ระบบรังสีวิทยาเป็นส่วนหนึ่งของระบบสารสนเทศโรงพยาบาล (HIS) ที่ทำหน้าที่เป็นศูนย์กลางในการจัดการงานรังสีวิทยาทั้งหมด ตั้งแต่การรับคำสั่งตรวจจากแพทย์ การลงทะเบียน การถ่ายภาพ การรายงานผล และการจัดการฟิล์ม โดยจะเชื่อมโยงกับระบบอื่นๆ ในโรงพยาบาล เช่น ระบบเวชระเบียน ระบบห้องตรวจแพทย์ ระบบห้องฉุกเฉิน ระบบการเงิน และระบบ PACS (ถ้ามี)

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

ระบบมีฟังก์ชันหลัก 5 กลุ่ม:

การจัดการข้อมูลพื้นฐาน - การกำหนดรายการตรวจ ท่า ด้าน ค่าบริการ และรูปแบบการชำระเงิน
การส่งตรวจและลงทะเบียน - การรับคำสั่งตรวจ Online การออก XN การจัดการคิว
การรายงานผลทางรังสี - การบันทึกการใช้ฟิล์ม การอ่านและรายงานผลโดยรังสีแพทย์
การจัดการฟิล์ม X-Ray - การบันทึกฟิล์มใช้ ฟิล์มเสีย และการยืม-คืนฟิล์ม
การพิมพ์เอกสาร - Request X-Ray, XN Label, ใบรายงานผล, ใบนัด

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

ผู้ใช้งาน	บทบาทและหน้าที่
แพทย์ผู้สั่งตรวจ	สั่งตรวจรังสี ดูผลการตรวจ ดูภาพ ดูประวัติการตรวจ
นักรังสีเทคนิค	รับผู้ป่วย ลงทะเบียน ถ่ายภาพ บันทึกฟิล์มใช้ บันทึกฟิล์มเสีย
รังสีแพทย์	อ่านและรายงานผล Lock ผลการอ่าน ให้คำปรึกษา
พยาบาลห้องรังสี	ช่วยเตรียมผู้ป่วย จัดการคิว ประสานงาน
เจ้าหน้าที่เวชระเบียน	ยืม-คืนฟิล์ม ติดตามฟิล์ม จัดเก็บฟิล์ม
เจ้าหน้าที่การเงิน	ตรวจสอบค่าบริการ ออกใบเสร็จ
ผู้ดูแลระบบ	จัดการ Master Data กำหนดสิทธิ์ ตั้งค่าระบบ

2.4 สภาพแวดล้อมการปฏิบัติงาน

ระบบทำงานในสภาพแวดล้อมโรงพยาบาล 24/7
รองรับการใช้งานพร้อมกันหลายผู้ใช้และหลายห้องตรวจ
ทำงานในห้องที่มีแสงสลัว (viewing room) สำหรับการอ่านฟิล์ม
เชื่อมต่อกับเครื่องมือถ่ายภาพรังสีต่างๆ (CR, DR, CT, MRI, Ultrasound)
เชื่อมต่อกับระบบ PACS สำหรับจัดเก็บภาพดิจิทัล
เชื่อมต่อกับระบบอื่นๆ ผ่าน API และฐานข้อมูลกลาง
รองรับการพิมพ์เอกสารและ Label ฟิล์ม

2.5 ข้อจำกัดและข้อกำหนดทั่วไป

ต้องปฏิบัติตามมาตรฐาน DICOM สำหรับการจัดเก็บและสื่อสารภาพทางการแพทย์
ต้องปฏิบัติตามกฎหมายคุ้มครองข้อมูลส่วนบุคคล (PDPA)
ต้องมีระบบรักษาความปลอดภัยของข้อมูลผู้ป่วยและภาพทางการแพทย์
ต้องมีระบบ Audit Trail สำหรับการตรวจสอบการเข้าถึงข้อมูล
ภาพและผลการตรวจต้องเก็บไว้ตามกฎหมาย (อย่างน้อย 5-10 ปี)
ระบบต้องรองรับการทำงานในสถานการณ์ฉุกเฉิน (STAT orders)

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

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

3.1.1 อินเทอร์เฟซผู้ใช้

ระบบต้องมี Web-based Interface ที่ใช้งานง่ายและรวดเร็ว
รองรับการใช้งานบนอุปกรณ์ต่างๆ (Desktop, Tablet, Mobile)
มีระบบ Search และ Auto-complete สำหรับการค้นหาข้อมูล
มี Dashboard แสดงสถานะผู้ป่วยและคิวแบบ Real-time
รองรับการแสดงภาพ DICOM ด้วย DICOM Viewer
มีหน้าจอสำหรับการอ่านฟิล์มที่เหมาะกับการใช้งานในห้องมืด
รองรับการใช้ Template สำหรับการรายงานผล

3.1.2 อินเทอร์เฟซฮาร์ดแวร์

รองรับเครื่องพิมพ์สำหรับพิมพ์เอกสารและ Label ฟิล์ม
เชื่อมต่อกับเครื่อง CR/DR Modality ผ่าน DICOM
เชื่อมต่อกับเครื่อง CT/MRI/Ultrasound ผ่าน DICOM
รองรับเครื่องอ่าน Barcode สำหรับ XN และ HN
รองรับจอภาพความละเอียดสูงสำหรับการอ่านภาพ (Medical Grade Monitor)
รองรับระบบจัดเก็บข้อมูลขนาดใหญ่ (Storage System)

3.1.3 อินเทอร์เฟซซอฟต์แวร์

การเชื่อมโยงหลัก: - เชื่อมโยงกับระบบเวชระเบียน (1.2.1) - รับข้อมูลผู้ป่วย - เชื่อมโยงกับระบบซักประวัติ (1.2.2) - รับคำสั่งตรวจ ส่งผลการตรวจ - เชื่อมโยงกับระบบห้องตรวจแพทย์ (1.2.3) - รับคำสั่งตรวจ ส่งผลการตรวจ - เชื่อมโยงกับระบบห้องฉุกเฉิน (1.2.4) - รับคำสั่งตรวจ STAT ส่งผลด่วน - เชื่อมโยงกับระบบผู้ป่วยใน (1.2.17) - รับคำสั่งตรวจผู้ป่วยใน ส่งผล - เชื่อมโยงกับระบบการเงิน (1.2.14) - ส่งข้อมูลค่าบริการ - เชื่อมโยงกับระบบ PACS - ส่งภาพ DICOM และข้อมูล - เชื่อมโยงกับระบบงานชันสูตร (1.2.7) - ประสานงานการตรวจแบบรวม

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

4.1 การจัดการข้อมูลพื้นฐาน

4.1.1 การกำหนดรายการ X-Ray

คำอธิบาย: ระบบสามารถจัดการข้อมูลรายการตรวจทางรังสีทุกประเภท

ข้อกำหนด: - FR-4.1.1: ระบบต้องสามารถกำหนดข้อมูลรายการ X-Ray ได้ โดยประกอบด้วย: - รหัสรายการตรวจ (X-Ray Code) - ชื่อรายการตรวจ (ภาษาไทยและภาษาอังกฤษ) - ชื่อย่อของรายการ - ประเภทการตรวจ (Plain X-Ray, Contrast X-Ray, CT, MRI, Ultrasound, Fluoroscopy, etc.) - กลุ่มการตรวจ (Chest, Abdomen, Extremity, Spine, etc.) - คำอธิบายรายละเอียดของการตรวจ - เวลาโดยเฉลี่ยในการตรวจ (นาที) - ความต้องการเตรียมตัวพิเศษ (เช่น อดอาหาร, ดื่มน้ำ) - ข้อห้ามในการตรวจ (Contraindications) - สถานะการใช้งาน (Active/Inactive)

FR-4.1.2: ระบบต้องสามารถกำหนดท่า (View/Projection) สำหรับแต่ละรายการได้ เช่น:
AP (Anterior-Posterior)
PA (Posterior-Anterior)
Lateral (Left/Right)
Oblique
Axial
Decubitus
ท่าพิเศษอื่นๆ
FR-4.1.3: ระบบต้องสามารถกำหนดด้าน (Side) ได้ เช่น:
Left (ซ้าย)
Right (ขวา)
Bilateral (ทั้งสองข้าง)
Center (กลาง)
FR-4.1.4: ระบบต้องสามารถกำหนดจำนวนภาพมาตรฐานสำหรับแต่ละรายการ
FR-4.1.5: ระบบต้องสามารถกำหนดขนาดฟิล์มมาตรฐานที่ใช้สำหรับแต่ละรายการ

4.1.2 การเชื่อมโยงกับหมวดหมู่ค่าบริการ

คำอธิบาย: ระบบสามารถเชื่อมโยงรายการตรวจกับค่าบริการตามสิทธิ์และกลุ่มการรักษา

ข้อกำหนด: - FR-4.1.6: ระบบต้องสามารถเชื่อมโยงกับหมวดหมู่ค่าบริการตามกลุ่มการรักษาพยาบาลทางรังสีวิทยาได้

FR-4.1.7: ระบบต้องสามารถกำหนดค่าบริการแยกตามสิทธิ์การรักษาได้ เช่น:
ประกันสังคม
บัตรทอง/UC
ข้าราชการ
จ่ายเอง
ประกันสุขภาพเอกชน
FR-4.1.8: ระบบต้องสามารถกำหนดค่าบริการแยกตามประเภทผู้ป่วยได้:
ผู้ป่วยนอก (OPD)
ผู้ป่วยใน (IPD)
ผู้ป่วยฉุกเฉิน (ER)

4.1.3 การกำหนดรูปแบบการชำระเงิน

คำอธิบาย: ระบบสามารถกำหนดวิธีการคิดค่าบริการที่หลากหลาย

ข้อกำหนด: - FR-4.1.9: ระบบต้องสามารถกำหนดรูปแบบการชำระเงินได้หลายแบบ: - คิดตามรายการ (Per Examination) - คิดค่าบริการตามจำนวนรายการที่สั่ง - คิดตามฟิล์ม (Per Film) - คิดค่าบริการตามจำนวนและขนาดฟิล์มที่ใช้จริง - คิดแบบแพคเกจ (Package) - คิดค่าบริการแบบรวม - คิดตามท่า (Per View) - คิดค่าบริการตามจำนวนท่าที่ถ่าย

FR-4.1.10: ระบบต้องสามารถกำหนดค่าบริการเพิ่มเติมได้ เช่น:
ค่าสารทึบรังสี (Contrast Media)
ค่าเจ้าหน้าที่ปฏิบัติการ
ค่าอ่านผลนอกเวลา
ค่าบริการนอกสถานที่ (Portable X-Ray)
FR-4.1.11: ระบบต้องสามารถกำหนดอัตราค่าฟิล์มตามขนาด เช่น:
8" x 10"
10" x 12"
11" x 14"
14" x 14"
14" x 17"

4.1.4 การจัดการห้องและเครื่องมือ

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

ข้อกำหนด: - FR-4.1.12: ระบบต้องสามารถกำหนดข้อมูลห้องรังสีได้ โดยระบุ: - รหัสห้อง - ชื่อห้อง - ประเภทห้อง (X-Ray Room, CT Room, MRI Room, Ultrasound Room) - สถานที่ตั้ง - เครื่องมือที่มีในห้อง - สถานะการใช้งาน (Available, Occupied, Maintenance, Out of Service)

FR-4.1.13: ระบบต้องสามารถกำหนดข้อมูลเครื่องมือ (Modality) ได้:
รหัสเครื่อง
ชื่อเครื่อง
ประเภท (CR, DR, CT, MRI, Ultrasound, Fluoroscopy)
ยี่ห้อและรุ่น
AE Title (สำหรับการเชื่อมต่อ DICOM)
IP Address
สถานะการใช้งาน
FR-4.1.14: ระบบต้องสามารถกำหนดรายการตรวจที่สามารถทำได้ในแต่ละห้อง/เครื่อง

4.1.5 การจัดการ Template รายงานผล

คำอธิบาย: ระบบสามารถจัดการแม่แบบข้อความสำหรับการรายงานผล

ข้อกำหนด: - FR-4.1.15: ระบบต้องสามารถสร้างและจัดการ Template รายงานผลได้: - รหัส Template - ชื่อ Template - เนื้อหา Template (Findings และ Impression) - การจัดกลุ่ม Template ตามอวัยวะ/โรค - เจ้าของ Template (Personal/Shared) - คำสำคัญสำหรับการค้นหา

FR-4.1.16: ระบบต้องสามารถกำหนด Template แยกตามรายการตรวจ
FR-4.1.17: ระบบต้องรองรับ Template แบบมีโครงสร้าง (Structured Reporting)
FR-4.1.18: รังสีแพทย์สามารถสร้าง Personal Template ของตนเองได้

4.2 การส่งตรวจรังสีวิทยา

4.2.1 การรับคำสั่งตรวจจากระบบอื่น

คำอธิบาย: ระบบสามารถรับคำสั่งตรวจรังสีจากแผนกต่างๆ ผ่านระบบ Online

ข้อกำหนด: - FR-4.2.1: ระบบต้องสามารถรองรับการจัดเก็บข้อมูลการลงทะเบียนตรวจรักษาทางรังสีวิทยาประกอบด้วยรายละเอียดดังนี้: - แพทย์ผู้สั่ง - ชื่อแพทย์และแผนกที่สั่ง - รายการตรวจ - รายการ X-Ray ที่สั่ง (สามารถสั่งได้หลายรายการ) - ท่า (View/Projection) - ระบุท่าที่ต้องการถ่าย - ด้าน (Side) - ระบุด้านที่ต้องการตรวจ (Left/Right/Bilateral) - วันที่และเวลาที่สั่ง - ความเร่งด่วน - STAT (ด่วนที่สุด), Urgent (เร่งด่วน), Routine (ปกติ) - ห้องที่ต้องการตรวจ - ระบุห้องรังสีที่ต้องการ (ถ้ามี) - สภาพผู้ป่วย - เดินมา, อุ้มมา, รถเข็น, รถนอน - Clinical Information - ข้อมูลทางคลินิก/เหตุผลการส่งตรวจ - ข้อมูลการใช้ Contrast - ระบุว่าต้องการใช้สารทึบรังสีหรือไม่

FR-4.2.2: ระบบต้องสามารถรับคำสั่งตรวจจากระบบต่างๆ แบบ Online ได้:
ระบบซักประวัติ (1.2.2)
ระบบห้องตรวจแพทย์ (1.2.3)
ระบบห้องฉุกเฉิน (1.2.4) - รองรับ STAT Order
ระบบทันตกรรม (1.2.5)
ระบบคลินิกพิเศษ (1.2.9)
ระบบผู้ป่วยใน (1.2.17)
ระบบห้องผ่าตัดและวิสัญญี (1.2.18)
FR-4.2.3: ระบบต้องตรวจสอบความถูกต้องของคำสั่งตรวจ:
ตรวจสอบว่ารายการตรวจสามารถทำได้หรือไม่
ตรวจสอบความซ้ำซ้อนของการตรวจ
แจ้งเตือนหากมีการตรวจซ้ำในระยะเวลาใกล้เคียงกัน
ตรวจสอบข้อห้ามในการตรวจ (เช่น หญิงตั้งครรภ์)
FR-4.2.4: ระบบต้องสามารถส่งข้อมูลค่าบริการไปยังระบบการเงิน (1.2.14) อัตโนมัติ

4.2.2 การพิมพ์ใบ Request X-Ray

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

ข้อกำหนด: - FR-4.2.5: ระบบต้องสามารถพิมพ์ใบ Request X-Ray จากจุดที่ส่งตรวจหรือจากห้อง X-Ray ได้

FR-4.2.6: ใบ Request X-Ray ต้องแสดงข้อมูลดังนี้:
ชื่อ-สกุลผู้ป่วย
เพศ
อายุ
HN (หมายเลขผู้ป่วย)
XN (หมายเลขการตรวจรังสี) - ถ้ามีการออก XN แล้ว
รายการที่ส่งตรวจ
ท่าและด้าน
แพทย์ผู้สั่ง
แผนกที่ส่งตรวจ
วันที่และเวลาที่สั่ง
ความเร่งด่วน
สิทธิ์การรักษา
Comment Box - ช่องให้แพทย์แสดงรายละเอียดเพิ่มเติมที่ไม่มีในชุดคำสั่งเอกซเรย์
Clinical Information
Barcode (HN และ XN)
FR-4.2.7: ระบบต้องรองรับการพิมพ์ซ้ำในกรณีใบเสียหายหรือสูญหาย

4.2.3 การแสดงรายการผู้ป่วยที่ส่งตรวจ

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

ข้อกำหนด: - FR-4.2.8: ระบบต้องสามารถแสดงข้อมูลผู้ป่วยที่มีการส่งตรวจรักษาทางห้องรังสีวิทยาแบบ Online

FR-4.2.9: ระบบต้องแสดงข้อมูลดังนี้:
HN (หมายเลขผู้ป่วย)
XN (หมายเลขการตรวจรังสี)
ชื่อ-นามสกุล
อายุ
เพศ
วันที่และเวลาสั่ง
รายการตรวจ
ท่าและด้าน
ความเร่งด่วน (STAT/Urgent/Routine)
แผนกที่สั่ง
แพทย์ผู้สั่ง
สิทธิการรักษา
ค่าใช้จ่าย
สถานะการตรวจ (รอตรวจ/กำลังตรวจ/ตรวจเสร็จ/มีผล)
สถานะการชำระเงิน
FR-4.2.10: ระบบต้องสามารถจัดเรียงและกรองรายการได้:
เรียงตามความเร่งด่วน (STAT ก่อน)
เรียงตามเวลาที่สั่ง
กรองตามห้องตรวจ
กรองตามสถานะ
กรองตามช่วงวันที่
FR-4.2.11: ระบบต้องมีการแจ้งเตือน (Alert) สำหรับ:
STAT Order ใหม่
ผู้ป่วยที่รอนานเกินเกณฑ์
ผู้ป่วยที่มีข้อควรระวังพิเศษ

4.3 การลงทะเบียนและจัดการผู้ป่วย

4.3.1 การค้นหาผู้ป่วย

คำอธิบาย: ระบบสามารถค้นหาข้อมูลผู้ป่วยได้หลายวิธี

ข้อกำหนด: - FR-4.3.1: ระบบต้องสามารถค้นหาผู้ป่วยด้วยหมายเลขประจำตัวผู้ป่วย (HN)

FR-4.3.2: ระบบต้องสามารถค้นหาผู้ป่วยด้วยชื่อและนามสกุล:
ชื่อและนามสกุล
เฉพาะชื่อ
เฉพาะนามสกุล
รองรับการค้นหาแบบ Partial Match
FR-4.3.3: ระบบต้องสามารถค้นหาผู้ป่วยด้วยหมายเลขบัตรประจำตัวประชาชน
FR-4.3.4: ระบบต้องสามารถค้นหาผู้ป่วยด้วย Barcode (HN Barcode)
FR-4.3.5: ระบบต้องแสดงรายการผู้ป่วยที่พบพร้อมข้อมูลสำคัญ:
HN
ชื่อ-นามสกุล
อายุ
เพศ
สิทธิ์หลัก
รูปถ่าย (ถ้ามี)

4.3.2 การเรียกดูประวัติการตรวจ

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

ข้อกำหนด: - FR-4.3.6: ระบบต้องสามารถเรียกดูข้อมูลประวัติการตรวจย้อนหลังได้ ได้แก่: - ประวัติการมารับบริการ - วันที่มาพบแพทย์และแผนกที่มา - การวินิจฉัย - โรคที่ได้รับการวินิจฉัย (ICD Code) - การสั่งจ่ายยา - รายการยาที่ได้รับ - การสั่ง Lab/X-Ray - ประวัติการตรวจ Lab และรังสีวิทยา - การตรวจร่างกาย - ผลการตรวจร่างกาย (PE) - การนัดหมาย - การนัดติดตามผล - การ Admit - ประวัติการรับเข้าเป็นผู้ป่วยใน

FR-4.3.7: ระบบต้องสามารถแสดงประวัติการตรวจรังสีโดยเฉพาะ:
วันที่ตรวจ
XN
รายการที่ตรวจ
ห้องที่ตรวจ
นักรังสีเทคนิคผู้ปฏิบัติการ
รังสีแพทย์ผู้อ่านผล
สถานะผล (มีผล/ไม่มีผล)
สามารถดูภาพและรายงานผลย้อนหลังได้
FR-4.3.8: ระบบต้องสามารถเปรียบเทียบภาพการตรวจคราวปัจจุบันกับคราวก่อนหน้าได้

4.3.3 การลงทะเบียนและออก XN

คำอธิบาย: ระบบสามารถลงทะเบียนผู้ป่วยและออกหมายเลข XN

ข้อกำหนด: - FR-4.3.9: ระบบต้องสามารถลงทะเบียนและทำการออกเลข XN ให้กับผู้ป่วยได้อัตโนมัติ

FR-4.3.10: รูปแบบ XN ต้องกำหนดได้ตามความต้องการ เช่น:
XXXXddmmyyyy#### (รหัสห้อง + วันที่ + running number)
yyyy-mm-dd-#### (ปี-เดือน-วัน-เลขที่)
หรือรูปแบบอื่นตามที่โรงพยาบาลกำหนด
FR-4.3.11: ระบบต้องสามารถออก XN แยกตามห้อง/ประเภทการตรวจได้
FR-4.3.12: ระบบต้องบันทึกข้อมูลการลงทะเบียน:
XN ที่ออกให้
วันที่และเวลาที่ลงทะเบียน
ห้องที่จะตรวจ
เจ้าหน้าที่ผู้ลงทะเบียน
สถานะการตรวจ (รอตรวจ)
FR-4.3.13: ระบบต้องสามารถพิมพ์ XN ติดซองและติดฟิล์มได้
FR-4.3.14: XN Label ต้องประกอบด้วย:
XN (ตัวเลขและ Barcode)
HN
ชื่อ-นามสกุลผู้ป่วย
อายุ/วันเกิด
เพศ
วันที่ตรวจ
รายการที่ตรวจ

4.3.4 การจัดการคิวผู้ป่วย

คำอธิบาย: ระบบสามารถจัดการลำดับคิวผู้ป่วยตามความเหมาะสม

ข้อกำหนด: - FR-4.3.15: ระบบต้องสามารถจัดเรียงคิวผู้ป่วยตามลำดับความสำคัญ: 1. STAT Order (ด่วนที่สุด) 2. Urgent Order (เร่งด่วน) 3. Routine Order (ปกติ) - เรียงตามเวลาที่มาถึง

FR-4.3.16: ระบบต้องสามารถแสดงสถานะคิวแบบ Real-time
FR-4.3.17: ระบบต้องรองรับการ Reschedule คิว (เลื่อนคิว) พร้อมระบุเหตุผล
FR-4.3.18: ระบบต้องสามารถ Hold คิว (พักคิว) ในกรณีที่ผู้ป่วยยังไม่พร้อม
FR-4.3.19: ระบบต้องแสดงเวลาโดยประมาณที่จะถึงคิว
FR-4.3.20: ระบบต้องสามารถแจ้งเตือนผู้ป่วยผ่าน:
หน้าจอแสดงคิว (Queue Display)
ระบบเสียง (Call System)
SMS/Line (ถ้ามีระบบ)

4.3.5 การบันทึกการเริ่มและสิ้นสุดการตรวจ

คำอธิบาย: ระบบสามารถบันทึกเวลาและสถานะการตรวจ

ข้อกำหนด: - FR-4.3.21: ระบบต้องบันทึกเวลาเริ่มการตรวจ (Start Time)

FR-4.3.22: ระบบต้องบันทึกเวลาสิ้นสุดการตรวจ (End Time)
FR-4.3.23: ระบบต้องบันทึกผู้ปฏิบัติการ:
นักรังสีเทคนิคผู้ถ่ายภาพ
พยาบาลประจำห้อง (ถ้ามี)
แพทย์ประจำห้อง (สำหรับบางการตรวจ เช่น Fluoroscopy)
FR-4.3.24: ระบบต้องคำนวณระยะเวลาที่ใช้ในการตรวจอัตโนมัติ
FR-4.3.25: ระบบต้องบันทึกสถานะการตรวจ:
Waiting (รอตรวจ)
In Progress (กำลังตรวจ)
Completed (ตรวจเสร็จ)
Reported (มีผลแล้ว)
Cancelled (ยกเลิก)

4.4 การรายงานผลทางห้องรังสีวิทยา

4.4.1 การบันทึกข้อมูลจำนวนฟิล์มและขนาดฟิล์ม

คำอธิบาย: ระบบสามารถบันทึกการใช้ฟิล์มสำหรับการตรวจแต่ละครั้ง

ข้อกำหนด: - FR-4.4.1: ระบบต้องสามารถบันทึกข้อมูลรายงานผลจำนวนฟิล์มที่ใช้ได้

FR-4.4.2: ระบบต้องสามารถบันทึกขนาดฟิล์มที่ใช้ เช่น:
8" x 10"
10" x 12"
11" x 14"
14" x 14"
14" x 17"
ขนาดอื่นๆ ตามที่กำหนด
FR-4.4.3: ระบบต้องสามารถบันทึกจำนวนฟิล์มแยกตามขนาด
FR-4.4.4: ระบบต้องคำนวณค่าบริการตามจำนวนและขนาดฟิล์มอัตโนมัติ (กรณีคิดตามฟิล์ม)
FR-4.4.5: ระบบต้องส่งข้อมูลค่าฟิล์มไปยังระบบการเงิน (1.2.14) อัตโนมัติ
FR-4.4.6: ระบบต้องสามารถแก้ไขจำนวนฟิล์มก่อนการยืนยันผล

4.4.2 การบันทึกข้อมูลฟิล์มเสีย

คำอธิบาย: ระบบสามารถบันทึกการเสียของฟิล์มและสาเหตุ

ข้อกำหนด: - FR-4.4.7: ระบบต้องสามารถบันทึกข้อมูลรายงานผลฟิล์มเสียพร้อมทั้งสาเหตุของการเสียได้

FR-4.4.8: ระบบต้องมีรายการสาเหตุฟิล์มเสียให้เลือก เช่น:
Over Exposure (แสงมากเกินไป)
Under Exposure (แสงน้อยเกินไป)
Motion Artifact (ภาพเบลอจากการเคลื่อนไหว)
Positioning Error (วางท่าไม่ถูกต้อง)
Film Fog (ฟิล์มมัว)
Processor Error (เครื่องล้างฟิล์มมีปัญหา)
Film Damage (ฟิล์มชำรุด)
อื่นๆ (ระบุได้)
FR-4.4.9: ระบบต้องบันทึกจำนวนและขนาดฟิล์มเสีย
FR-4.4.10: ระบบต้องบันทึกผู้รับผิดชอบและเหตุผล
FR-4.4.11: ระบบต้องสามารถออกรายงานฟิล์มเสียได้:
รายงานรายวัน/รายเดือน/รายปี
แยกตามห้อง/เครื่อง
แยกตามผู้ปฏิบัติการ
แยกตามสาเหตุ
FR-4.4.12: ระบบต้องมีการคำนวณอัตราฟิล์มเสีย (Rejection Rate)

4.4.3 การอ่านและรายงานผลโดยรังสีแพทย์

คำอธิบาย: ระบบสามารถจัดการการอ่านและรายงานผลโดยรังสีแพทย์

ข้อกำหนด: - FR-4.4.13: กรณีมีรังสีแพทย์ ระบบต้องสามารถบันทึกข้อมูลผลการอ่านฟิล์มได้

FR-4.4.14: รายงานผลต้องประกอบด้วย:
Technique - เทคนิคการตรวจ
Findings - สิ่งที่พบจากการตรวจ (อธิบายรายละเอียด)
Impression - สรุปผลการตรวจและความเห็น
รังสีแพทย์ผู้อ่าน
วันที่และเวลาที่อ่านผล
ลายเซ็นดิจิทัล (Digital Signature)
FR-4.4.15: ระบบต้องสามารถบันทึกการอ่านผลฟิล์มด้วยการทำชุดข้อความ (Template) เก็บไว้แล้วนำมาใช้งานได้
FR-4.4.16: ระบบต้องสามารถ Load Text File เข้ามาแล้วทำการเปลี่ยนแปลงแก้ไขได้
FR-4.4.17: ระบบต้องรองรับการพิมพ์เสียง (Voice Recognition) สำหรับการบันทึกผล (Optional)
FR-4.4.18: ระบบต้องสามารถแนบภาพ Key Image พร้อมคำอธิบายได้
FR-4.4.19: ระบบต้องสามารถแก้ไขรายงานผลก่อนการ Lock

4.4.4 การ Lock ผลการอ่านฟิล์ม

คำอธิบาย: ระบบสามารถล็อคผลการอ่านเพื่อป้องกันการแก้ไข

ข้อกำหนด: - FR-4.4.20: ระบบต้องสามารถ Lock ผลการอ่านฟิล์มของแพทย์ทั้งหมดได้

FR-4.4.21: เมื่อ Lock แล้วจะไม่สามารถแก้ไขได้ เว้นแต่:
ผู้มีสิทธิ์พิเศษทำการ Unlock
มีการบันทึก Audit Trail ทุกครั้งที่มีการ Unlock และแก้ไข
FR-4.4.22: ระบบต้องแสดงสถานะการ Lock ชัดเจน
FR-4.4.23: ผลที่ Lock แล้วจะถูกส่งไปยังแพทย์ผู้สั่งตรวจอัตโนมัติ

4.4.5 การดูผลการอ่านฟิล์ม Online

คำอธิบาย: แพทย์ผู้สั่งตรวจสามารถดูผลผ่านระบบ Online

ข้อกำหนด: - FR-4.4.24: ผู้สั่งสามารถดูผลการอ่านฟิล์มและผลวินิจฉัยที่รังสีแพทย์บันทึกผ่านระบบ online ได้

FR-4.4.25: ระบบต้องแจ้งเตือนเมื่อมีผลใหม่:
แจ้งเตือนบนระบบ (Notification)
ส่งอีเมล (Optional)
ส่ง SMS/Line (Optional)
FR-4.4.26: แพทย์สามารถดูภาพ (Image Viewer) พร้อมรายงานผลได้
FR-4.4.27: ระบบต้องบันทึก Log การดูผลของแต่ละบุคคล

4.4.6 การตรวจสอบรายการที่ยืนยันผลแล้ว

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

ข้อกำหนด: - FR-4.4.28: ระบบต้องสามารถตรวจสอบราย/ชื่อแสดงรายการที่ยืนยันการลงผลแล้วได้

FR-4.4.29: ระบบต้องแสดงข้อมูล:
XN
HN
ชื่อผู้ป่วย
รายการที่ตรวจ
วันที่ตรวจ
รังสีแพทย์ผู้อ่าน
วันที่และเวลาที่ยืนยันผล
สถานะ (Pending/Reported/Locked)
FR-4.4.30: ระบบต้องสามารถค้นหาและกรองรายการได้:
ตามช่วงวันที่
ตามรังสีแพทย์
ตามสถานะ
ตามรายการตรวจ

4.4.7 การพิมพ์ใบรายงานผล

คำอธิบาย: ระบบสามารถพิมพ์ใบรายงานผลอย่างเป็นทางการ

ข้อกำหนด: - FR-4.4.31: ระบบต้องสามารถพิมพ์ใบรายงานผลที่รังสีแพทย์ลงผลได้

FR-4.4.32: ใบรายงานผลต้องประกอบด้วย:
ข้อมูลโรงพยาบาล (Header)
ข้อมูลผู้ป่วย (HN, ชื่อ, อายุ, เพศ)
XN
วันที่ตรวจ
รายการที่ตรวจ
Technique
Findings
Impression
รังสีแพทย์ผู้อ่าน พร้อมลายเซ็น
วันที่รายงาน
Disclaimer (ถ้ามี)
FR-4.4.33: ระบบต้องรองรับการพิมพ์ซ้ำ พร้อมระบุว่าเป็นสำเนา (Copy)
FR-4.4.34: ระบบต้องสามารถส่งออกเป็น PDF ได้

4.5 การจัดการฟิล์ม X-Ray

4.5.1 การยืม-คืนฟิล์ม X-Ray

คำอธิบาย: ระบบสามารถจัดการการยืมและคืนฟิล์ม X-Ray

ข้อกำหนด: - FR-4.5.1: ระบบต้องสามารถบันทึกการยืมฟิล์ม X-Ray ได้

FR-4.5.2: ระบบต้องสามารถแสดงข้อมูลผู้ยืมได้:
ชื่อผู้ยืม
ตำแหน่ง/แผนก
วันที่และเวลาที่ยืม
วันที่คาดว่าจะคืน
FR-4.5.3: ระบบต้องสามารถแสดงแผนกที่ยืมได้
FR-4.5.4: ระบบต้องสามารถระบุสาเหตุการยืมได้ เช่น:
ประชุมแพทย์ (Conference)
ปรึกษาผู้เชี่ยวชาญ (Consultation)
การศึกษา (Teaching)
การวิจัย (Research)
ผู้ป่วยมาติดตาม (Follow-up)
ส่งต่อโรงพยาบาล (Referral)
อื่นๆ
FR-4.5.5: ระบบต้องสามารถบันทึกเบอร์โทรศัพท์ผู้ยืมได้
FR-4.5.6: ระบบต้องสามารถบันทึกหมายเหตุเพิ่มเติมได้
FR-4.5.7: ระบบต้องสามารถบันทึกการคืนฟิล์มได้:
วันที่และเวลาที่คืน
ผู้รับคืน
สภาพฟิล์ม (ปกติ/ชำรุด/สูญหาย)
FR-4.5.8: ระบบต้องสามารถบันทึกการยืมฟิล์มหลายชุดพร้อมกันได้

4.5.2 การตรวจสอบข้อมูลการยืม-คืน

คำอธิบาย: ระบบสามารถตรวจสอบและติดตามการยืม-คืนฟิล์ม

ข้อกำหนด: - FR-4.5.9: ระบบต้องสามารถตรวจสอบข้อมูลการยืม-คืนได้

FR-4.5.10: ระบบต้องแสดงสถานะของฟิล์ม:
In Archive (อยู่ในห้องเก็บ)
On Loan (ยืมออกไป)
Overdue (เกินกำหนดคืน)
Lost (สูญหาย)
Damaged (ชำรุด)
FR-4.5.11: ระบบต้องสามารถค้นหาข้อมูลการยืมได้:
ตาม HN/XN
ตามชื่อผู้ยืม
ตามแผนกที่ยืม
ตามช่วงวันที่ยืม
ตามสถานะ (ยืมอยู่/คืนแล้ว/เกินกำหนด)
FR-4.5.12: ระบบต้องสามารถแสดงรายการฟิล์มที่ยืมค้างได้
FR-4.5.13: ระบบต้องมีการแจ้งเตือนฟิล์มเกินกำหนดคืน:
แจ้งเตือนอัตโนมัติเมื่อใกล้ครบกำหนด
แจ้งเตือนเมื่อเกินกำหนด
ส่งการแจ้งเตือนไปยังผู้ยืมและหน่วยงาน
FR-4.5.14: ระบบต้องสามารถออกรายงานการยืม-คืนได้:
รายงานรายวัน/รายเดือน
รายงานฟิล์มค้างคืน
รายงานฟิล์มสูญหาย
สถิติการยืมแยกตามแผนก

4.5.3 การจัดเก็บและสืบค้นฟิล์ม

คำอธิบาย: ระบบสามารถช่วยในการจัดเก็บและสืบค้นฟิล์ม

ข้อกำหนด: - FR-4.5.15: ระบบต้องสามารถบันทึกตำแหน่งจัดเก็บฟิล์มได้: - อาคาร/ชั้น - ตู้เก็บฟิล์ม (Cabinet) - ชั้น (Shelf) - ตำแหน่ง (Position)

FR-4.5.16: ระบบต้องสามารถสืบค้นตำแหน่งฟิล์มได้รวดเร็ว
FR-4.5.17: ระบบต้องบันทึกวันที่จัดเก็บฟิล์ม
FR-4.5.18: ระบบต้องแจ้งเตือนฟิล์มที่ครบกำหนดทำลาย (ตามระเบียบกำหนด)

4.6 การนัดหมายและการส่งต่อ

4.6.1 การนัดหมายเพื่อฟังผล

คำอธิบาย: ระบบสามารถนัดหมายผู้ป่วยมาฟังผลในวันอื่น

ข้อกำหนด: - FR-4.6.1: ระบบต้องสามารถนัดหมายเพื่อฟังผลในวันอื่นได้

FR-4.6.2: ระบบต้องบันทึกข้อมูลการนัด:
วันที่นัด
เวลานัด
สถานที่นัด (คลินิก/แผนก)
แพทย์ที่นัด
เหตุผลการนัด
หมายเหตุพิเศษ
FR-4.6.3: ระบบต้องสามารถพิมพ์ใบนัดได้
FR-4.6.4: ใบนัดต้องประกอบด้วย:
ข้อมูลผู้ป่วย (HN, ชื่อ)
XN
วันที่ตรวจ
รายการที่ตรวจ
วันเวลาที่นัด
สถานที่นัด
แพทย์ที่นัด
คำแนะนำเพิ่มเติม
FR-4.6.5: ระบบต้องสามารถส่งการแจ้งเตือนการนัดหมาย:
SMS (ถ้ามีระบบ)
Line/App (ถ้ามีระบบ)
โทรศัพท์ติดต่อ

4.6.2 การส่งตรวจต่อ

คำอธิบาย: ระบบสามารถบันทึกการส่งผู้ป่วยไปตรวจต่อ

ข้อกำหนด: - FR-4.6.6: ระบบต้องสามารถบันทึกการส่งตรวจผู้ป่วยไปตามห้องตรวจต่างๆ ได้ เช่น: - ส่งกลับห้องตรวจเดิม - ส่งต่อคลินิกพิเศษ - ส่งต่อแผนกอื่น - ส่งต่อโรงพยาบาลอื่น (Refer)

FR-4.6.7: ระบบต้องบันทึกข้อมูลการส่งต่อ:
จุดหมายปลายทาง
เหตุผลการส่งต่อ
วันที่ส่งต่อ
แพทย์ผู้ส่ง
เอกสารที่ส่งไปด้วย (รายงานผล, ฟิล์ม, CD)
FR-4.6.8: ระบบต้องสามารถพิมพ์เอกสารส่งต่อได้

4.7 การจัดการภาพดิจิทัลและ PACS Integration

🔷 [OPTIONAL - นอกขอบเขต TOR / สำหรับการพัฒนาในอนาคต]

หมายเหตุสำคัญ: - ส่วนนี้ ไม่อยู่ในขอบเขต TOR ที่ระบุไว้ - TOR เดิมเน้นการใช้ฟิล์ม X-Ray แบบดั้งเดิม (Film-based System) - เนื้อหาในส่วนนี้จัดทำขึ้นเพื่อรองรับการพัฒนาในอนาคต เมื่อโรงพยาบาลพร้อมจะเปลี่ยนเป็นระบบดิจิทัล - สามารถเลือก Implement หรือข้ามไปก่อนได้ตามความพร้อม

4.7.1 การรับและจัดเก็บภาพ DICOM (Optional)

คำอธิบาย: ระบบสามารถรับและจัดการภาพในรูปแบบ DICOM

ข้อกำหนด: - FR-4.7.1: ระบบต้องรองรับการรับภาพจากเครื่องมือผ่าน DICOM Protocol: - DICOM C-Store (รับภาพจากเครื่อง) - DICOM Worklist (ส่งรายการตรวจไปยังเครื่อง) - DICOM Query/Retrieve (ค้นหาและดึงภาพ)

FR-4.7.2: ระบบต้องตรวจสอบความสมบูรณ์ของภาพ DICOM:
Patient Information
Study Information
Series Information
Image Quality
FR-4.7.3: ระบบต้องสามารถจับคู่ภาพกับ XN อัตโนมัติ
FR-4.7.4: ระบบต้องสามารถจัดเก็บภาพในรูปแบบ DICOM Standard

4.7.2 DICOM Viewer (Optional)

คำอธิบาย: ระบบมี Viewer สำหรับการดูภาพทางการแพทย์

ข้อกำหนด: - FR-4.7.5: ระบบต้องมี DICOM Viewer สำหรับการดูภาพ

FR-4.7.6: DICOM Viewer ต้องมีฟังก์ชันพื้นฐาน:
Zoom In/Out
Pan (เลื่อนภาพ)
Window/Level Adjustment (ปรับความสว่าง/ความคมชัด)
Rotate (หมุนภาพ)
Flip (กลับภาพ)
Measurement (วัดระยะ, มุม, พื้นที่)
Annotation (เขียนหมายเหตุ)
Compare Mode (เปรียบเทียบภาพ)
Cine Loop (เล่นภาพต่อเนื่อง สำหรับ CT/MRI)
FR-4.7.7: Viewer ต้องรองรับการแสดงภาพหลายจอ (Multi-monitor)
FR-4.7.8: Viewer ต้องรองรับการแสดงภาพหลายรูปแบบ:
Single Image
Multi-image Layout (1x2, 2x2, 2x3, etc.)
Stack Mode (ซ้อนทับภาพ)

4.7.3 PACS Integration (Optional)

คำอธิบาย: ระบบสามารถเชื่อมต่อกับระบบ PACS ภายนอก

ข้อกำหนด: - FR-4.7.9: ระบบต้องสามารถส่งภาพไปยัง PACS Server อัตโนมัติ

FR-4.7.10: ระบบต้องสามารถดึงภาพจาก PACS กลับมาดูได้
FR-4.7.11: ระบบต้องรองรับการ Backup ภาพไปยัง Storage หลายตัว
FR-4.7.12: ระบบต้องมีกลไกการ Auto-Archive ภาพเก่า
FR-4.7.13: ระบบต้องสามารถ Export ภาพเป็น CD/DVD สำหรับผู้ป่วย

4.8 รายงานและสถิติ

4.8.1 รายงานเชิงสถิติ

คำอธิบาย: ระบบสามารถสร้างรายงานและสถิติการให้บริการ

ข้อกำหนด: - FR-4.8.1: ระบบต้องสามารถออกรายงานสถิติการตรวจรังสี: - จำนวนผู้ป่วยแยกตามประเภทการตรวจ - จำนวนการตรวจแยกตามห้อง/เครื่อง - จำนวนการตรวจแยกตามแผนกที่ส่ง - จำนวนการตรวจแยกตามแพทย์ผู้สั่ง - สถิติความเร่งด่วน (STAT/Urgent/Routine)

FR-4.8.2: ระบบต้องสามารถออกรายงานผลการดำเนินงาน:
จำนวนผู้ป่วยที่รับบริการรายวัน/รายเดือน/รายปี
เวลาเฉลี่ยในการตรวจ (Turn Around Time)
เวลาเฉลี่ยในการรายงานผล (Reporting Time)
อัตราการตรวจซ้ำ (Repeat Rate)
อัตราฟิล์มเสีย (Rejection Rate)
FR-4.8.3: ระบบต้องสามารถออกรายงานรายได้:
รายได้จากค่าตรวจรังสี แยกตามสิทธิ์
รายได้จากฟิล์ม
รายได้จาก Contrast
รายได้แยกตามห้อง/เครื่อง
FR-4.8.4: ระบบต้องสามารถออกรายงาน Workload:
จำนวนงานของนักรังสีเทคนิค
จำนวนผลที่รังสีแพทย์อ่าน
ประสิทธิภาพการใช้งานเครื่อง

4.8.2 Dashboard และ Real-time Monitoring

คำอธิบาย: ระบบมี Dashboard สำหรับติดตามการทำงาน

ข้อกำหนด: - FR-4.8.5: ระบบต้องมี Dashboard แสดงข้อมูล Real-time: - จำนวนผู้ป่วยรอตรวจ - จำนวนผู้ป่วยกำลังตรวจ - จำนวนผู้ป่วยรอผล - สถานะห้อง/เครื่อง - STAT Order ที่รอดำเนินการ

FR-4.8.6: Dashboard ต้องแสดงกราฟและ Chart ที่เข้าใจง่าย
FR-4.8.7: Dashboard ต้อง Refresh อัตโนมัติ

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

5.1 ประสิทธิภาพของระบบ (Performance Requirements)

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

NFR-5.1.1: ระบบต้องมีเวลาตอบสนองไม่เกิน 3 วินาที สำหรับการทำงานปกติ
NFR-5.1.2: การค้นหาข้อมูลต้องได้ผลลัพธ์ภายใน 2 วินาที
NFR-5.1.3: การโหลดภาพ DICOM ขนาดปกติต้องไม่เกิน 5 วินาที
NFR-5.1.4: การพิมพ์เอกสารต้องเริ่มพิมพ์ภายใน 3 วินาที

5.1.2 ปริมาณการใช้งาน

NFR-5.1.5: ระบบต้องรองรับผู้ใช้งานพร้อมกันอย่างน้อย 50 คน
NFR-5.1.6: ระบบต้องรองรับการเก็บภาพอย่างน้อย 10 TB
NFR-5.1.7: ระบบต้องรองรับการตรวจอย่างน้อย 500 ครั้ง/วัน
NFR-5.1.8: ระบบต้องสามารถเก็บข้อมูลย้อนหลังอย่างน้อย 10 ปี

5.1.3 ความพร้อมใช้งาน (Availability)

NFR-5.1.9: ระบบต้องมีความพร้อมใช้งาน (Uptime) อย่างน้อย 99.5%
NFR-5.1.10: ระบบต้องสามารถทำงานได้ 24 ชั่วโมง 7 วัน
NFR-5.1.11: Planned Downtime สำหรับ Maintenance ต้องไม่เกิน 4 ชั่วโมง/เดือน
NFR-5.1.12: ระบบต้องมี Failover Mechanism สำหรับกรณีเซิร์ฟเวอร์หลักล้มเหลว

5.2 ความปลอดภัย (Security Requirements)

5.2.1 การยืนยันตัวตนและสิทธิ์การใช้งาน

NFR-5.2.1: ผู้ใช้ต้อง Login ด้วย Username และ Password
NFR-5.2.2: รองรับ Single Sign-On (SSO) กับระบบ HIS
NFR-5.2.3: Password ต้องมีความซับซ้อนตามมาตรฐาน (ความยาวขั้นต่ำ 8 ตัวอักษร, ผสมตัวเลขและสัญลักษณ์)
NFR-5.2.4: ระบบต้องมีการกำหนดสิทธิ์การใช้งานตาม Role-Based Access Control (RBAC)
NFR-5.2.5: Session Timeout หลังไม่มีการใช้งาน 30 นาที
NFR-5.2.6: รองรับ Two-Factor Authentication (2FA) สำหรับผู้ใช้สิทธิ์สูง (Optional)

5.2.2 การเข้ารหัสข้อมูล

NFR-5.2.7: ข้อมูลส่วนบุคคลของผู้ป่วยต้องถูกเข้ารหัสในฐานข้อมูล
NFR-5.2.8: การส่งข้อมูลผ่านเครือข่ายต้องใช้ HTTPS/TLS
NFR-5.2.9: ภาพ DICOM ที่ส่งผ่านเครือข่ายต้องเข้ารหัส
NFR-5.2.10: Password ต้องเก็บในรูปแบบ Hash (เช่น bcrypt, SHA-256)

5.2.3 Audit Trail และ Logging

NFR-5.2.11: ระบบต้องบันทึก Log ทุกการเข้าถึงข้อมูลผู้ป่วย
NFR-5.2.12: ระบบต้องบันทึก Log การแก้ไขข้อมูลสำคัญ (Who, What, When)
NFR-5.2.13: ระบบต้องบันทึก Log การ Login/Logout
NFR-5.2.14: ระบบต้องบันทึก Log การดูและดาวน์โหลดภาพ
NFR-5.2.15: Log ต้องเก็บไว้อย่างน้อย 2 ปี และไม่สามารถแก้ไขได้
NFR-5.2.16: ระบบต้องมี Audit Report สำหรับตรวจสอบการใช้งาน

5.2.4 ความเป็นส่วนตัวของข้อมูล (Privacy)

NFR-5.2.17: ระบบต้องปฏิบัติตาม พ.ร.บ. คุ้มครองข้อมูลส่วนบุคคล (PDPA)
NFR-5.2.18: ข้อมูลผู้ป่วยต้องสามารถ Anonymize ได้สำหรับการวิจัย
NFR-5.2.19: ระบบต้องมีกลไกการลบข้อมูลตามคำขอของผู้ป่วย (Right to be Forgotten)
NFR-5.2.20: ระบบต้องแสดง Consent Form ก่อนการเก็บข้อมูลละเอียดอ่อน

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

5.3.1 ความทนทานต่อข้อผิดพลาด

NFR-5.3.1: ระบบต้องมี Error Handling ที่ดี แสดงข้อความที่เข้าใจง่าย
NFR-5.3.2: ระบบต้องไม่ Crash เมื่อเกิด Error แต่ต้อง Log และ Alert
NFR-5.3.3: ระบบต้องมีกลไก Auto-Recovery จากข้อผิดพลาดที่ไม่ร้ายแรง
NFR-5.3.4: ระบบต้อง Validate ข้อมูลก่อนบันทึกเพื่อป้องกัน Data Corruption

5.3.2 การสำรองและกู้คืนข้อมูล

NFR-5.3.5: ระบบต้องมี Automatic Backup ทุกวัน
NFR-5.3.6: ระบบต้องเก็บ Backup อย่างน้อย 3 Generation
NFR-5.3.7: ระบบต้องมี Backup นอกสถานที่ (Off-site Backup) สำหรับกรณีภัยพิบัติ
NFR-5.3.8: ระบบต้องสามารถกู้คืนข้อมูลได้ภายใน 4 ชั่วโมง (Recovery Time Objective - RTO)
NFR-5.3.9: ข้อมูลที่สูญหายต้องไม่เกิน 1 ชั่วโมง (Recovery Point Objective - RPO)
NFR-5.3.10: ระบบต้องมีการทดสอบการกู้คืนข้อมูลอย่างน้อยปีละ 2 ครั้ง

5.4 ความสามารถในการบำรุงรักษา (Maintainability)

5.4.1 การบำรุงรักษาระบบ

NFR-5.4.1: ระบบต้องออกแบบแบบ Modular สามารถแก้ไขส่วนใดส่วนหนึ่งได้โดยไม่กระทบส่วนอื่น
NFR-5.4.2: Code ต้องมี Comment และ Documentation ที่ดี
NFR-5.4.3: ระบบต้องมี Development, Testing, และ Production Environment แยกกัน
NFR-5.4.4: ระบบต้องสามารถ Update Version ได้โดยไม่ทำให้ข้อมูลเดิมเสียหาย
NFR-5.4.5: ระบบต้องมี Version Control และ Change Log ที่ชัดเจน

5.4.2 การตรวจสอบและแก้ไขปัญหา

NFR-5.4.6: ระบบต้องมี Error Log ที่ละเอียดพอสำหรับการแก้ไขปัญหา
NFR-5.4.7: ระบบต้องมี Health Check Dashboard สำหรับ Admin
NFR-5.4.8: ระบบต้องมี Alert System เมื่อเกิดปัญหา (Email, SMS)
NFR-5.4.9: ระบบต้องมี Remote Monitoring และ Support

5.5 ความสามารถในการขยายระบบ (Scalability)

NFR-5.5.1: ระบบต้องสามารถขยายจำนวนผู้ใช้งานได้โดยไม่ต้องเปลี่ยนสถาปัตยกรรม
NFR-5.5.2: ระบบต้องสามารถเพิ่ม Storage สำหรับเก็บภาพได้ง่าย
NFR-5.5.3: ระบบต้องรองรับ Load Balancing สำหรับกระจายภาระงาน
NFR-5.5.4: Database ต้องสามารถ Scale Out (เพิ่มเซิร์ฟเวอร์) ได้
NFR-5.5.5: ระบบต้องรองรับการเชื่อมต่อ Modality เพิ่มเติมได้โดยง่าย

5.6 ความสามารถในการใช้งาน (Usability)

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

NFR-5.6.1: ผู้ใช้ใหม่ต้องสามารถเรียนรู้ฟังก์ชันพื้นฐานได้ภายใน 2 ชั่วโมง
NFR-5.6.2: ระบบต้องมี UI/UX ที่ใช้งานง่าย สอดคล้องกับมาตรฐาน
NFR-5.6.3: ระบบต้องมี Help System หรือ User Manual ในระบบ
NFR-5.6.4: ระบบต้องมี Tooltip และ Hint สำหรับฟังก์ชันที่ซับซ้อน
NFR-5.6.5: Font ต้องมีขนาดที่อ่านง่าย และรองรับภาษาไทย-อังกฤษ
NFR-5.6.6: สีที่ใช้ต้องเหมาะสมกับสภาพแวดล้อมห้องมืด (สำหรับการอ่านฟิล์ม)

5.6.2 การรองรับความผิดพลาดของผู้ใช้

NFR-5.6.7: ระบบต้องมี Confirmation Dialog สำหรับการทำงานสำคัญ (ลบ, ยกเลิก, Lock)
NFR-5.6.8: ระบบต้องมี Undo Function สำหรับการแก้ไขที่ยังไม่ Save
NFR-5.6.9: ระบบต้องแสดง Validation Message ทันทีเมื่อกรอกข้อมูลผิด
NFR-5.6.10: ระบบต้องมี Auto-Save สำหรับข้อมูลที่กำลังแก้ไข

5.7 ความเข้ากันได้ (Compatibility)

5.7.1 ความเข้ากันได้กับฮาร์ดแวร์

NFR-5.7.1: รองรับ Windows Server 2016 ขึ้นไป
NFR-5.7.2: รองรับ Linux Server (Ubuntu, CentOS)
NFR-5.7.3: รองรับ Database: SQL Server, MySQL, PostgreSQL
NFR-5.7.4: รองรับเครื่อง Modality ที่เป็นมาตรฐาน DICOM

5.7.2 ความเข้ากันได้กับซอฟต์แวร์

NFR-5.7.5: รองรับ Web Browser: Chrome, Firefox, Edge, Safari (เวอร์ชันล่าสุด)
NFR-5.7.6: รองรับ Mobile Browser: iOS Safari, Android Chrome
NFR-5.7.7: รองรับการเชื่อมต่อกับ HIS ผ่าน HL7 หรือ REST API
NFR-5.7.8: รองรับการเชื่อมต่อกับ PACS ผ่าน DICOM Protocol

5.7.3 มาตรฐานและโปรโตคอล

NFR-5.7.9: ระบบต้องปฏิบัติตามมาตรฐาน DICOM 3.0
NFR-5.7.10: ระบบต้องปฏิบัติตามมาตรฐาน HL7 v2.x หรือ FHIR
NFR-5.7.11: ระบบต้องปฏิบัติตามมาตรฐาน IHE (Integrating the Healthcare Enterprise) Profiles
NFR-5.7.12: ระบบต้องรองรับ ICD-10, ICD-11 Coding

5.8 การทำงานในสถานการณ์พิเศษ

5.8.1 โหมดฉุกเฉิน (Emergency Mode)

NFR-5.8.1: ระบบต้องมีโหมด STAT สำหรับผู้ป่วยฉุกเฉิน
NFR-5.8.2: STAT Order ต้องมี Priority สูงสุดในคิว
NFR-5.8.3: ระบบต้องแจ้งเตือน Alert สำหรับ STAT Order ใหม่

5.8.2 โหมด Offline (Disaster Recovery)

NFR-5.8.4: ระบบต้องสามารถทำงานแบบ Offline ได้ในกรณีเครือข่ายขัดข้อง
NFR-5.8.5: เมื่อเครือข่ายกลับมาใช้ได้ ระบบต้อง Sync ข้อมูลอัตโนมัติ
NFR-5.8.6: ระบบต้องมีกลไก Conflict Resolution สำหรับข้อมูลที่ซ้ำ

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

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

6.1.1 การรับข้อมูลผู้ป่วย

การเชื่อมโยง: ระบบรังสีวิทยารับข้อมูลประจำตัวผู้ป่วยจากระบบเวชระเบียน

ข้อมูลที่แลกเปลี่ยน: - HN (หมายเลขผู้ป่วย) - ข้อมูลส่วนตัว (ชื่อ, นามสกุล, เพศ, วันเกิด) - ที่อยู่และข้อมูลติดต่อ - สิทธิ์การรักษา - รูปถ่ายผู้ป่วย

วิธีการเชื่อมโยง: REST API หรือ Database View (Read-only)

ความถี่: Real-time เมื่อมีการค้นหาหรือลงทะเบียนผู้ป่วย

6.2 ระบบซักประวัติ (1.2.2)

6.2.1 การรับคำสั่งตรวจจากห้องซักประวัติ

การเชื่อมโยง: ระบบรังสีวิทยารับคำสั่งตรวจรังสีจากห้องซักประวัติ

ข้อมูลที่แลกเปลี่ยน: - Order ID - HN - รายการตรวจที่สั่ง - ท่าและด้าน - Clinical Information - ความเร่งด่วน - แพทย์ผู้สั่ง - วันที่สั่ง

วิธีการเชื่อมโยง: REST API (POST /radiology/orders)

ความถี่: Real-time เมื่อแพทย์สั่งตรวจ

6.2.2 การส่งผลการตรวจกลับ

การเชื่อมโยง: ระบบรังสีวิทยาส่งผลการตรวจและรายงานกลับระบบซักประวัติ

ข้อมูลที่แลกเปลี่ยน: - XN - Order ID - สถานะผล (Pending/Completed/Reported) - รายงานผล (Findings, Impression) - รังสีแพทย์ผู้อ่าน - วันที่รายงาน - Link ดูภาพ (PACS URL) - Optional สำหรับระบบดิจิทัล

วิธีการเชื่อมโยง: REST API (PUT /radiology/results) หรือ Webhook

ความถี่: Real-time เมื่อรังสีแพทย์ Lock ผล

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

การเชื่อมโยง: คล้ายกับระบบซักประวัติ - รับคำสั่งและส่งผล

ข้อมูลเพิ่มเติม: - ผลการตรวจร่างกาย (Physical Examination) สำหรับ Clinical Correlation - ภาพถ่ายจากห้องตรวจ (ถ้ามี)

6.4 ระบบห้องฉุกเฉิน (1.2.4)

6.4.1 การรับ STAT Order

การเชื่อมโยง: ระบบรังสีวิทยารับคำสั่ง STAT จากห้องฉุกเฉิน

ความพิเศษ: - STAT Order ต้องมี Priority สูงสุด - แจ้งเตือนทันทีเมื่อมี Order ใหม่ - ต้องมีการรายงานผลด่วน (Preliminary Report ภายใน 30 นาที)

ข้อมูลเพิ่มเติม: - สาเหตุฉุกเฉิน/อุบัติเหตุ - Trauma Score - สภาพคลินิก

6.5 ระบบผู้ป่วยใน (1.2.17)

6.5.1 การรับคำสั่งตรวจผู้ป่วยใน

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

ข้อมูลเพิ่มเติม: - AN (Admission Number) - Ward (หอผู้ป่วย) - เตียง (Bed Number) - ความสามารถในการเคลื่อนย้าย - การตรวจแบบ Portable (นำเครื่องไปตรวจที่เตียง)

6.5.2 การประสานงานการตรวจ

การเชื่อมโยง: ประสานเวลาและสถานที่ตรวจ

กระบวนการ: - กรณีผู้ป่วยเคลื่อนย้ายได้ → นัดมาที่ห้องรังสี - กรณีผู้ป่วยเคลื่อนย้ายไม่ได้ → จัดทีม Portable X-Ray

6.6 ระบบการเงิน (1.2.14)

6.6.1 การส่งข้อมูลค่าบริการ

การเชื่อมโยง: ระบบรังสีวิทยาส่งข้อมูลค่าบริการไปยังระบบการเงิน

ข้อมูลที่ส่ง: - XN - HN - รายการตรวจ และค่าบริการ - จำนวนและขนาดฟิล์ม และค่าฟิล์ม - ค่า Contrast (ถ้ามี) - ส่วนลด (ถ้ามี) - สิทธิ์การรักษา - วันที่ตรวจ

วิธีการเชื่อมโยง: REST API (POST /billing/charges)

เวลา: Real-time หลังการลงทะเบียนหรือหลังการตรวจเสร็จ

6.6.2 การตรวจสอบสถานะการชำระเงิน

การเชื่อมโยง: ตรวจสอบว่าผู้ป่วยชำระเงินแล้วหรือยัง

การใช้งาน: บางโรงพยาบาลกำหนดให้ต้องชำระเงินก่อนส่งผล

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

6.7.1 การตรวจสอบสิทธิ์การรักษา

การเชื่อมโยง: ตรวจสอบสิทธิ์และความคุ้มครอง

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

วิธีการเชื่อมโยง: Modal Integration หรือ REST API

6.8 ระบบงานชันสูตร (1.2.7)

6.8.1 การประสานงานการตรวจ

การเชื่อมโยง: ประสานงานกรณีที่ต้องตรวจทั้ง Lab และรังสี

กรณีพิเศษ: - การตรวจที่ต้องใช้ Lab ก่อน (เช่น ตรวจ Creatinine ก่อน CT Contrast) - การตรวจร่วมกัน (เช่น Nuclear Medicine)

6.9 ระบบ PACS (ภายนอก) - 🔷 [OPTIONAL]

หมายเหตุ: ส่วนนี้เป็น Optional สำหรับโรงพยาบาลที่ใช้ระบบดิจิทัล

6.9.1 การส่งและรับภาพ (Optional)

การเชื่อมโยง: ส่งภาพ DICOM ไปเก็บใน PACS

Protocol: DICOM C-Store, DICOM Query/Retrieve

ข้อมูล: - ภาพ DICOM พร้อม Metadata - Study Information - Series Information

6.9.2 การดูภาพจาก PACS (Optional)

การเชื่อมโยง: ดึงภาพจาก PACS มาแสดง

วิธีการ: - DICOM Viewer ฝังใน HIS - เปิด External PACS Viewer (Deep Link)

6.10 ระบบห้องผ่าตัดและวิสัญญี (1.2.18)

6.10.1 การรับคำสั่งตรวจก่อนผ่าตัด

การเชื่อมโยง: รับคำสั่งตรวจรังสีก่อนผ่าตัด (Pre-operative)

ข้อมูลพิเศษ: - วันที่วางแผนผ่าตัด - ประเภทการผ่าตัด - ความจำเป็นของผล (Critical)

6.10.2 Intra-operative Imaging

การเชื่อมโยง: การตรวจรังสีระหว่างผ่าตัด (ถ้ามีบริการ)

กรณีพิเศษ: - C-Arm Fluoroscopy - ต้องส่งภาพ Real-time ไปห้องผ่าตัด

6.11 สรุปการเชื่อมโยง (Integration Summary)

ระบบ	ประเภทการเชื่อมโยง	ข้อมูลหลัก	Protocol/Method
เวชระเบียน (1.2.1)	รับข้อมูล	ข้อมูลผู้ป่วย	REST API, DB View
ซักประวัติ (1.2.2)	2-way	Order, Result	REST API
ห้องตรวจ (1.2.3)	2-way	Order, Result, PE	REST API
ห้องฉุกเฉิน (1.2.4)	2-way (STAT)	STAT Order, Result	REST API + Alert
ผู้ป่วยใน (1.2.17)	2-way	IPD Order, Result	REST API
การเงิน (1.2.14)	ส่งข้อมูล	Billing Charges	REST API
ตรวจสอบสิทธิ (1.2.15)	Query	สิทธิ์การรักษา	Modal/REST API
งานชันสูตร (1.2.7)	ประสานงาน	Lab+Rad Order	REST API
ห้องผ่าตัด (1.2.18)	รับ Order	Pre/Intra-op Order	REST API
PACS (External) 🔷	2-way (Optional)	DICOM Images	DICOM Protocol

7. บทสรุป

7.1 สรุปความต้องการ

เอกสาร SRS นี้ได้กำหนดความต้องการซอฟต์แวร์สำหรับระบบรังสีวิทยาของโรงพยาบาลค่ายธนรัชน์ ครอบคลุม:

✅ การจัดการข้อมูลพื้นฐาน - รายการตรวจ, ค่าบริการ, ห้อง, Template (18 FRs)

✅ การส่งตรวจและลงทะเบียน - การรับ Order, การพิมพ์ Request, การออก XN, การจัดการคิว (25 FRs)

✅ การรายงานผลทางรังสี - การบันทึกฟิล์ม, การอ่านผล, การ Lock, การดูผล Online (31 FRs)

✅ การจัดการฟิล์ม X-Ray - การยืม-คืน, การตรวจสอบ, การจัดเก็บ (18 FRs)

✅ การนัดหมายและการส่งต่อ - การนัดฟังผล, การส่งตรวจต่อ (8 FRs)

✅ รายงานและสถิติ - Dashboard, Reports (7 FRs)

🔷 การจัดการภาพดิจิทัล (Optional) - DICOM, PACS, Viewer (13 FRs) - สำหรับระบบดิจิทัลในอนาคต

รวมทั้งสิ้น 107 Functional Requirements (Core) + 13 FRs (Optional)

7.2 ความสอดคล้องกับ TOR

ระบบนี้ครอบคลุม TOR ระบบรังสีวิทยา 100% โดยมีการขยายรายละเอียดเพิ่มเติม:

✅ ครอบคลุม TOR (Core Requirements): - TOR 1.2.8.1 ข้อมูลพื้นฐาน → ขยายเป็น FR-4.1.1 ถึง FR-4.1.18 - TOR 1.2.8.2 การส่งตรวจรังสีวิทยา → ขยายเป็น FR-4.2.1 ถึง FR-4.3.25 - TOR 1.2.8.3 การรายงานผล → ขยายเป็น FR-4.4.1 ถึง FR-4.4.34 - TOR 1.2.8.4 การยืม-คืนฟิล์ม → ขยายเป็น FR-4.5.1 ถึง FR-4.5.18 - TOR 1.2.8.5 การพิมพ์ → รวมอยู่ใน FR-4.2.5-4.2.7, FR-4.4.31-4.4.34, FR-4.6.3-4.6.4

🔷 นอกขอบเขต TOR (Optional - สำหรับอนาคต): - การจัดการภาพดิจิทัลและ PACS Integration (Section 4.7) → FR-4.7.1 ถึง FR-4.7.13 - TOR เดิมเน้นระบบ Film-based แต่ได้เพิ่มส่วนนี้เพื่อรองรับการเปลี่ยนผ่านสู่ระบบดิจิทัลในอนาคต

7.3 ประโยชน์ที่คาดว่าจะได้รับ

7.3.1 ด้านประสิทธิภาพการทำงาน

ลดเวลารอคอยของผู้ป่วย ด้วยระบบจัดการคิวที่ดี
เพิ่มความรวดเร็วในการรายงานผล ด้วย Template และ Load Text
ลดภาระงานเอกสาร ด้วยระบบ Online และการพิมพ์อัตโนมัติ
เพิ่มความแม่นยำในการบันทึก ด้วย Validation และ Auto-calculation

7.3.2 ด้านคุณภาพการดูแล

แพทย์ได้รับผลการตรวจรวดเร็วขึ้น ผ่านระบบ Online
สามารถเปรียบเทียบภาพย้อนหลังได้ง่าย ช่วยการวินิจฉัย
ลดการตรวจซ้ำที่ไม่จำเป็น ด้วยระบบเตือนการตรวจซ้ำ
มีระบบติดตาม STAT Order เพื่อความปลอดภัยของผู้ป่วย

7.3.3 ด้านการจัดการ

มีรายงานสถิติที่แม่นยำ สำหรับการวางแผน
ลดฟิล์มเสีย ด้วยการวิเคราะห์และติดตาม
จัดการฟิล์มได้ดีขึ้น ด้วยระบบยืม-คืนและติดตาม
ควบคุมรายได้ได้แม่นยำ ด้วยการบันทึกฟิล์มใช้จริง

7.3.4 ด้านความปลอดภัย

ข้อมูลผู้ป่วยได้รับการคุ้มครอง ตาม PDPA
มี Audit Trail สำหรับการตรวจสอบการเข้าถึงข้อมูล
ภาพทางการแพทย์ได้รับการเก็บรักษาอย่างปลอดภัย
มีระบบสำรองข้อมูลที่เชื่อถือได้

7.4 ข้อแนะนำในการพัฒนา

7.4.1 ลำดับความสำคัญในการพัฒนา (Phase)

Phase 1: Core Functions (3-4 เดือน) - การจัดการข้อมูลพื้นฐาน (Master Data) - การรับ Order จากระบบอื่น - การลงทะเบียนและออก XN - การบันทึกฟิล์มและค่าบริการ - การพิมพ์เอกสารพื้นฐาน

Phase 2: Reporting Functions (2-3 เดือน) - การอ่านและรายงานผลโดยรังสีแพทย์ - Template Management - การ Lock และ Unlock ผล - การส่งผลกลับระบบต้นทาง - การยืม-คืนฟิล์ม

Phase 3: Enhancement (1-2 เดือน) - การนัดหมายและติดตาม - Dashboard และรายงานขั้นสูง - การปรับปรุง UI/UX

Phase 4: 🔷 Digital Transformation (Optional - Future Phase)

หมายเหตุ: Phase นี้เป็น Optional สำหรับการพัฒนาในอนาคต เมื่อโรงพยาบาลพร้อมเปลี่ยนเป็นระบบดิจิทัล - DICOM Integration - PACS Integration - DICOM Viewer - การจัดการภาพดิจิทัล - Mobile Application (Optional) - AI Integration (Optional)

7.4.2 ข้อควรระวังในการพัฒนา

สำหรับ Core System (Film-based): - Film Management: ต้องมีระบบติดตามฟิล์มที่แม่นยำ - Reporting: ต้องมี Template ที่ครอบคลุมและใช้งานง่าย - Integration: ต้องเชื่อมโยงกับระบบอื่นได้อย่างราบรื่น - Security: ข้อมูลทางการแพทย์ละเอียดอ่อน ต้องมีความปลอดภัยสูง - User Training: ผู้ใช้ต้องได้รับการฝึกอบรมอย่างเพียงพอ

สำหรับ Optional Digital System (เมื่อ Implement ในอนาคต): - DICOM Compliance: ต้องทดสอบกับเครื่อง Modality หลายรุ่นหลายยี่ห้อ - Performance: การจัดการภาพขนาดใหญ่ต้องมีประสิทธิภาพ - Storage: ต้องมี Storage เพียงพอสำหรับภาพดิจิทัล (TB-PB ระดับ) - Backup: ภาพต้องมีการสำรองข้อมูลที่เชื่อถือได้

7.5 การบำรุงรักษาและพัฒนาต่อยอด

สำหรับระบบ Core: - ต้องมีการ Patch Security Updates อย่างสม่ำเสมอ - ควรมีการรับ Feedback จากผู้ใช้เพื่อปรับปรุง UI/UX - ปรับปรุง Template รายงานผลให้ทันสมัย - เพิ่มประสิทธิภาพการจัดการฟิล์ม

สำหรับการเตรียมรับ Digital Transformation (อนาคต): - ติดตามเทคโนโลยี DICOM และ PACS ที่เปลี่ยนแปลง - ศึกษาการเปลี่ยนผ่านจาก Film-based เป็น Digital ของโรงพยาบาลอื่น - วางแผนงบประมาณและ Timeline สำหรับการ Upgrade - ควรศึกษาเทคโนโลยีใหม่ๆ เช่น AI สำหรับช่วยการอ่านภาพ

เอกสารนี้จัดทำขึ้นเพื่อใช้เป็นแนวทางในการพัฒนาระบบรังสีวิทยา และจะได้รับการปรับปรุงตามความต้องการที่เปลี่ยนแปลงและมาตรฐานสากล

วันที่จัดทำ: 23 ตุลาคม 2568
ผู้จัดทำ: ทีมพัฒนาระบบ HIS โรงพยาบาลค่ายธนรัชน์
เวอร์ชัน: 1.0
สถานะ: Draft for Review