บทที่ 1
บทนำ
1.1 ความเป็นมาและความสำคัญของปัญหา
เนื่องจากโรงพยาบาลของรัฐเป็นหน่วยงานที่ให้บริการด้านการรักษาพยาบาลและบริการ
ทางด้านสาธารณสุขต่าง ๆ ที่มีความใกล้ชิดประชาชนและมีการให้บริการประชาชนเป็นปริมาณ
มากในแต่ละวัน ซึ่งจะมีปัญหาเรื่องความล่าช้าในการให้บริการ จึงสมควรอย่างยิ่งที่จะนำ
เทคโนโลยีสารสนเทศมาปรับปรุงการให้บริการให้สะดวกรวดเร็วขึ้น อันจะให้ประโยชน์ต่อ
ประชาชนผู้เข้ารับบริการโดยตรง และสืบเนื่องจากกระทรวงสาธารณสุขได้ดำเนินการจัดทำ
“แผนแม่บทเทคโนโลยีสารสนเทศ กระทรวงสาธารณสุข ปี 2540-2544 ” ขึ้น ซึ่งเป็น
แผนงานรวมเพื่อให้การพัมนาเทคโนโลยีสารสนเทศของหน่วยงานในกระทรวงสาธารณสุขเป็นไป
อย่างพร้อมเพรียงในทิศทางเดียวกันและข้อมูลต่าง ๆ มีมาตรฐานซึ่งสามารถเชื่อมโยงกันได้
โครงงานนี้จึงอาศัยข้อมูลพื้นฐานสำหรับพัฒนาระบบให้บริการรักษาพยาบาลของสำนักงาน
ปลัดกระทรวงสาธารณสุขในการพัฒนาในส่วนของฐานข้อมูลคลังยาและห้องจ่ายยาเพื่อให้ได้
ระบบงานที่มีมาตรฐานข้อมูลพื้นฐานเดียวกันสามารถแลกเปลี่ยนข้อมูลระหว่างโรงพยาบาลและนำ
ข้อมูลมาประมวลร่วมกันได้ในอนาคต โครงงานนี้จึงยังเป็นเพียงโครงงานนำร่อง (Pilot
Project) ซึ่งสามารถนำไปพัฒนาเชื่อมต่อกับฐานข้อมูลงานโรงพยาบาลในส่วนอื่น ๆ เพื่อให้
ได้ระบบฐานข้อมูลโรงพยาบาลทั้งระบบอย่างสมบูรณ์ในอนาคตต่อไป
1.2 วัตถุประสงค์
พัฒนาระบบสารสนเทศโรงพยาบาลส่วนของคลังยาและห้องจ่ายยาสำหรับโรงพยาบาล
เพื่อสนับสนุนการบริหารการจัดการคลังยาและห้องจ่ายยา
1.3 ขอบเขตของโครงงาน
โครงงานนี้มีขอบเขตอยู่ 2 ประการคือ
2
1.3.1 พัฒนาระบบฐานข้อมูลคลังยาและห้องจ่ายยาให้สามารถทำงานเก็บรวบรวม
ข้อมูล
สำคัญๆในการดำเนินงานของระบบ โดยแบ่งขั้นตอนกระบวนการ (Process) ออกเป็นระบบ
ต่างๆ ดังนี้
1.3.1.1. ส่วนของการบันทึกลงทะเบียนเวชภัณฑ์
1.3.1.2. ส่วนของการบันทึกใบอนุมัติสั่งซื้อเวชภัณฑ์
1.3.1.3. ส่วนของการบันทึกใบสั่งซื้อเวชภัณฑ์
1.3.1.4. ส่วนของการบันทึกการตรวจรับเวชภัณฑ์จากใบส่งของ
1.3.1.5. ส่วนของการบันทึกการรับเวชภัณฑ์จากหน่วยงานอื่น
1.3.1.6. ส่วนของการบันทึกใบเบิกเวชภัณฑ์ตามใบเบิก
1.3.1.7. ส่วนของการบันทึกการอนุมัติจ่ายเวชภัณฑ์ให้หน่วยงานอื่น
1.3.1.8. ส่วนของการบันทึกการจ่ายเวชภัณฑ์ให้หน่วยงานอื่น
1.3.1.9. ส่วนของการบันทึกใบเบิกเวชภัณฑ์จากคลังใหญ่
1.3.1.10. ส่วนของการบันทึกรับเวชภัณฑ์จากคลังใหญ่
1.3.1.11. ส่วนของการบันทึกรับเวชภัณฑ์จากหน่วยงานอื่น
1.3.1.12. ส่วนของการบันทึกใบสั่งยา
1.3.1.13. ส่วนของการบันทึกจ่ายเวชภัณฑ์ตามใบสั่งยา
1.3.1.14. ส่วนของการบันทึกจ่ายเวชภัณฑ์ให้หน่วยงานอื่น
1.3.1.15. ส่วนของการตรวจเช็คยาที่หมดอายุ
1.3.2 การนำเสนอรูปแบบของโปรแกรมระบบสารสนเทศโรงพยาบาลส่วนของคลังยา
และห้องจ่ายยาโดยใช้สถาปัตยกรรมแบบ Client /Server จัดการในส่วนของฐานข้อมูลใช้
การออกแบบฐานข้อมูลแบบฐานข้อมูลเชิงสัมพันธ์ (Relational Database Model)
1.4 ข้อตกลงเบื้องต้น
1.4.1 ระบบสารสนเทศโรงพยาบาล ส่วนของคลังยาและห้องจ่ายยาที่จะทำการ
พัฒนาขึ้นใน
ครั้งนี้จะเป็นการพัฒนาแบบ Client /Server ซึ่งมุ่งเน้นการพัฒนาในส่วนของคลังยาและ
ห้องจ่ายยา
1.4.2 ในการพัฒนาระบบจะมีการจำลองบาง Module ของการทำงานในฝ่าย/ส่วน
อื่นของงาน
3
สารสนเทศโรงพยาบาลขึ้นมาใช้ก่อน เพื่อความสะดวกในการพัฒนาโปรแกรม เช่นเรื่องใบสั่งยา
จากห้องตรวจของแพทย์ หรือประเภทของคนไข้ใน / นอกจากฝ่ายเวชระเบียน เป็นต้น
1.4.3 ระบบการรักษาความปลอดภัยรวมถึงการติดตั้งและตั้งค่า configuration
ต่าง ๆ จะ
กระทำเพียงเบื้องต้นไม่ลงลึกไปถึงส่วนที่ต้องใช้จริง
1.5 การดำเนินงาน
1.5.1 ศึกษาเอกสารที่เกี่ยวข้องกับคลังยาและห้องจ่ายยา รวมถึงเอกสารที่เกี่ยวข้องกับ
การพัฒนาโปรแกรม
1.5.2 ออกแบบฐานข้อมูล
1.5.3 ออกแบบหน้าจอที่ใช้ในการติดต่อกับฐานข้อมูล
1.5.4 พัฒนาโปรแกรม
1.5.5 ทดสอบและปรับปรุงการใช้งานของโปรแกรมที่พัฒนา
1.5.6 สรุปผลการดำเนินการและจัดทำโครงงานฉบับสมบูรณ์
1.6 เครื่องมือที่ใช้ในการดำเนินงาน
ส่วนของ Software
ระบบปฏิบัติการ : WindowsXP ServicePack 1
ระบบปฏิบัติการ Server : Linux Redhat
9.0,Windows 2000 Server
ระบบฐานข้อมูล : MySQL Server 4.0.15
ภาษาที่ใช้ในการพัฒนาWeb Site : Delphi 7.0 Enterprise
Edition
ส่วนของ Hardware
เครื่องคอมพิวเตอร์ PC AMD Athlon XP1800+1533 MHz, RAM
512 MB, Hard disk 40 GB LAN Card, พร้อมอุปกรณ์ต่อพ่วงอื่น ๆ
ครบชุด
4
1.7 แหล่งข้อมูลอ้างอิง
1.7.1 คู่มือพื้นฐานสำหรับการพัฒนาระบบคอมพิวเตอร์เครือข่ายเพื่อการรักษาพยาบาลของ
สำนักเทคโนโลยีสารสนเทศ สำนักปลัดกระทรวงสาธารณสุข กระทรวงสาธารณสุข
1.7.2 ฝ่ายการแพทย์ โรงพยาบาลศูนย์สรรพสิทธิประสงค์ จ.อุบลราชธานี
1.7.3 ฝ่ายการพยาบาล โรงพยาบาลศูนย์สรรพสิทธิประสงค์ จ. อุบลราชธานี
1.7.4 ฝ่ายเภสัชกรรมชุมชนและคุ้มครองผู้บริโภค สำนักงานสาธารณสุข จ.ยโสธร
1.7.5 บัญชีเสนอราคารวมภาษีมูลค่าเพิ่ม องค์การเภสัชกรรม (Price List 2004)
1.7.6 ราคากลางของยาตามบัญชียาหลักแห่งชาติ (ฉบับที่2) พ.ศ. 2545 สำนักปลัด
กระทรวงสาธารณสุข ตามประกาศกระทรวงสาธารณสุข ลงวันที่ 17 พ.ย. 2542
1.7.7 บัญชียาหลักแห่งชาติ พ.ศ. 2542 คณะกรรมการแห่งชาติด้านยา
1.8 การทดสอบระบบ
ในการทดสอบจะแบ่งเป็น 2 ระยะ ดังนี้
1.8.1 การทดสอบโดยผู้พัฒนาขณะทำการพัฒนาระบบ
1.8.2 การทดสอบแบบ Black Box โดยเภสัชกร / เจ้าหน้าที่ผู้ปฏิบัติงานในส่วนของ
คลังยาและห้องจ่ายยาที่พัฒนาขึ้นด้วยการทดลองใช้งานจริง ตาม Check List ประสิทธิภาพ
ของระบบที่จัดทำขึ้นเพื่อใช้ในการทดสอบดูข้อผิดพลาดและข้อ แก้ไขปรับปรุง
1.9 กลุ่มเป้าหมาย / หน่วยงานที่จะนำไปใช้
สถานพยาบาลหรือโรงพยาบาลของรัฐที่มีความสนใจต้องการนำไปใช้งานหรือพัฒนา
ร่วมกับระบบสารสนเทศโรงพยาบาลในส่วนอื่น ๆ
1.10 ประโยชน์ที่คาดว่าจะได้รับ
1.10.1 สามารถสนับสนุนการบริหารการจัดการคลังยาและห้องจ่ายยาให้เป็นไปอย่างมี
ประสิทธิภาพและสอดคล้องกับความต้องการของผู้ใช้งาน
1.10.2 สามารถใช้งานร่วมกับระบบฐานข้อมูลอื่นๆ ของระบบสารสนเทศโรงพยาบาลที่
พัฒนาขึ้นจากข้อมูลพื้นฐานสำหรับพัฒนาระบบงานให้บริการรักษาพยาบาลของสำนักงาน
ปลัดกระทรวงสาธารณสุข
1.10.3 ได้ศึกษาและเข้าใจการทำงานในส่วนของคลังยาและห้องจ่ายยา ซึ่งเป็นส่วนหนึ่ง
ในระบบสารสนเทศโรงพยาบาล
1.10.4 สามารถเป็นแนวทางในการพัฒนาระบบข้อมูลใช้ในโครงการหลักประกันสุขภาพ
ของกระทรวงสาธารณสุขในอนาคตได้
1.10.5 เพื่อเป็นแนวทางให้โรงพยาบาลทั่วไปสามารถใช้ระบบฐานข้อมูลคลังยาและห้อง
5
จ่ายยาที่มีข้อมูลพื้นฐานซึ่งสามารถเชื่อมโยงและทำงานร่วมกันได้
บทที่ 2
วรรณกรรมที่เกี่ยวข้อง
2.1 ระบบฐานข้อมูล (Database System) (ศิริลักษณ์, 2542 :14-28)
แนวความคิดเบื้องต้นของฐานข้อมูล คือการใช้งานฐานข้อมูลเดียวสำหรับข้อมูลที่เกี่ยวข้อง
กันทั้งหมด โดยฐานข้อมูลดังกล่าวจะถูกควบคุมโดยซอฟต์แวร์ชุดหนึ่ง แทนที่จะใช้งานแฟ้มข้อมูล
คอมพิวเตอร์ที่กระจัดกระจายและมีการดูแลโดยผู้ใช้กลุ่มต่าง ๆ กัน เป้าหมายสูงสุดของ
แนวความคิดเกี่ยวกับฐานข้อมูลคือการที่ข้อมูลแต่ละชุดถูกป้อนและจัดเก็บเพียงครั้งเดียว ผู้ใช้ที่
ได้รับสิทธิ์ทุกคนจะสามารถเรียกใช้ข้อมูลที่จัดเก็บอยู่ได้อย่างง่ายดายและรวดเร็ว รวมทั้งการที่
ข้อมูลเป็นอิสระจากโปรแกรมเฉพาะกิจใด ๆ
ระบบฐานข้อมูลจะประกอบขึ้นจากคอมพิวเตอร์ Hardware Software และ
ผู้ใช้งาน นั่นก็คือ
การทำงานร่วมกันของฐานข้อมูล ระบบจัดการฐานข้อมูลและบุคคลที่ใช้งานฐานข้อมูลนั้น
ประโยชน์ของฐานข้อมูลก็คือการลดความซ้ำซ้อนของข้อมูล เพิ่มความเป็นอันหนึ่งอันเดียวกันของ
ข้อมูล ทำให้ข้อมูลเป็นอิสระ เพิ่มความสะดวกในการรวบรวมและแบ่งกันใช้ข้อมูล เพิ่ม
ประสิทธิภาพในการเข้าถึงข้อมูล รวมศูนย์ความปลอดภัยและลดค่าใช้จ่าย อย่างไรก็ดีฐานข้อมูลก็
มีจุดด้อยอยู่ นั่นคือมีความซับซ้อนสูงกว่าและมีค่าใช้จ่ายเริ่มต้นที่สูงกว่า ต้องมีการอบรมผู้ใช้งาน
รวมทั้งต้องมีการแปลงข้อมูลเก่าให้อยู่ในรูปแบบของฐานข้อมูล
ระบบฐานข้อมูลสามารถแบ่งได้ตามวิธีการใช้งาน การวางโครงสร้างและการจัดการ
ข้อมูล รวมทั้งความสัมพันธ์ระหว่างข้อมูลที่จัดเก็บอยู่ เรียกว่า แบบจำลองข้อมูล (Data Models) ซึ่ง
แบ่งออกเป็น 3 แบบด้วยกันคือ
2.1.1 แบบจำลองแบบลำดับชั้น (The Hierarchical Model) แบบจำลองแบบลำดับชั้น
ได้ถูกพัฒนาโดย IBM ในปี 1968 โดยระบบฐานข้อมูลที่ใช้แบบจำลองประเภทนี้จะเชื่อมโยงข้อมูล
ที่อยู่ภายในด้วยความสัมพันธ์แบบลำดับชั้น และส่วนมากจะรวมเอาข้อมูลทั้งหมดไว้ในไฟล์ขนาด
ใหญ่เพียงไฟล์เดียว
ในระบบจัดการฐานข้อมูลแบบลำดับชั้นกลุ่มของฟิลด์จะเรียกว่า Segment แทนการเรียก
เรคคอร์ด และชิ้นของข้อมูลซึ่งอยู่บนสุดของลำดับชั้นจะเรียกว่า Parent Element ซึ่งจะมี Child
Element จำนวนหนึ่งอยู่ระดับถัดจาก Parent Element ลงมา
6
สมมติว่าต้องการเก็บตัวอย่างข้อมูลของมหาวิทยาลัยแห่งหนึ่ง โดยในมหาวิทยาลัย
(University) มี m คณะ (Faculty) แต่ละคณะมี n ภาควิชา (Department) แต่ละภาควิชามีนักเรียน
(Student) สังกัดอยู่จำนวน o คน นักเรียนแต่ละคนต้องเรียน p วิชา (Course) และแต่ละภาควิชามี
อาจารย์ (Staff) จำนวน q คน จะเขียนโครงสร้างฐานข้อมูลแบบจำลองแบบลำดับชั้นได้ดังนี้
FACULTY-RELATIONSHIP
DEPT-REL.
FACULTY-REL.
STUDENT-REL.
COURSE-REL.
ภาพที่ 2-1 โครงสร้างฐานข้อมูลแบบลำดับชั้น
จากรูปจะเห็นได้ว่าแบบจำลองแบบลำดับชั้นเป็นการรวมความสัมพันธ์ระหว่าง Parent
และ Child เข้าด้วยกัน ปัญหาของแบบจำลองแบบลำดับชั้นคือมี Element ใด
Element หนึ่ง (Child Element) จะมี Element ที่อยู่เหนือขึ้นไปที่สัมพันธ์กัน
โดยตรง (Parent Element) มากกว่าหนึ่งความสัมพันธ์ไม่ได้ และแต่ละ Element จะ
อยู่ได้เพียงที่เดียวเท่านั้น
UNIVERSITY
FACULTY
DEPARTMENT
STAFF
STUDENT
COURSE
7
แบบจำลองแบบลำดับชั้นจะพบการใช้งานมากในเครื่องระดับ Mainframe และ
Minicomputer เช่น ระบบ Information Management System หรือ
IMS จากไอบีเอ็ม เป็นต้น
2.1.2 แบบจำลองแบบเครือข่าย (The Network Model) แบบจำลองแบบ
เครือข่ายได้รับการพัฒนาขึ้นเมื่อปลายปี 1960 มีหลักการที่คล้ายกับแบบจำลองแบบลำดับชั้น
นั่นคือมีการจัด ข้อมูลอยู่ในความสัมพันธ์แบบ Parent – Child แต่ Element ที่เป็น
Child สามารถมีความสัมพันธ์กับ Element ที่เป็น Parent ได้มากกว่าหนึ่ง Element
นั่นคือสามารถมีความสัมพันธ์ของข้อมูลในแบบ N:M ได้นั่นเอง ทำให้แบบจำลองแบบ
เครือข่ายสามารถแปลงเป็นแบบจำลองแบบลำดับชั้นได้ แต่แบบจำลองแบบลำดับชั้นจะแปลงเป็น
แบบจำลองแบบเครือข่ายไม่ได้
ภาพที่ 2-2 โครงสร้างฐานข้อมูลแบบเครือข่าย
2.1.3 แบบจำลองแบบความสัมพันธ์ (The Relational Model)แบบจำลองแบบ
ความสัมพันธ์
เป็นแบบจำลองที่ได้รับความนิยมสูงสุดในปัจจุบัน โดยระบบฐานข้อมูลส่วนมากจะใช้แบบจำลอง
ชนิดนี้ในการจัดการข้อมูลที่เก็บอยู่ เรียกว่าฐานข้อมูลที่ใช้แบบจำลองแบบความสัมพันธ์นี้ว่า
ฐานข้อมูลเชิงสัมพันธ์ (RDBMS)ไฟล์ในระบบการจัดการฐานข้อมูลแบบความสัมพันธ์เป็น
ไฟล์ที่เข้าใจความหมายได้ง่าย ระหว่างไฟล์ต่าง ๆ มีข้อมูลที่ซ้ำซ้อนกันน้อยมาก ทำให้ประหยัด
เนื้อที่ของหน่วยเก็บข้อมูล รวมทั้งสามารถเพิ่มหรือลดข้อมูลได้ง่าย ในระบบการจัดการฐานข้อมูล
ประเภทนี้มักจะไม่มีการจัดโครงสร้างของไฟล์ใหม่ จะมีก็เป็นการสร้างไฟล์ใหม่ขึ้นมาเพิ่มเท่านั้น
ในกรณีที่มีการเปลี่ยนแปลงความต้องการขององค์กรก็จะเป็นการเพิ่มหรือลบไฟล์ หรือเพิ่มหรือลบ
ฟิล์ดเท่านั้น หรืออาจรวมไฟล์สองไฟล์เข้าด้วยกันก็ได้ แต่การรวมไฟล์ขนาดใหญ่สองไฟล์จะทำ
ให้เกิดไฟล์ที่มีขนาดใหญ่มากและต้องใช้เวลาในการทำงานนาน
UNIVERSITY
ENGLISH COMPUT MATHEMAT
Vasa Som Sun
8
ACCOU
NT
NAME ADDR
(I) HEADER FILE
ACCOU
NT
ITEM DESCRIP
TION
QUANT
ITY
ITEM EXT.C
OS
(II) ITEM FILE
ภาพที่ 2-3 โครงสร้างตารางฐานข้อมูลเชิงสัมพันธ์
2.2 ระบบจัดการฐานข้อมูล (DataBase Management Systems: DBMS)
(อำไพ, 2543 :30-34)
ระบบจัดการฐานข้อมูล หรือที่นิยมเรียกว่า DBMS คือชุดของโปรแกรมคอมพิวเตอร์ซึ่ง
ทำหน้าที่สร้าง ดูแลรักษา และใช้งานส่วนต่าง ๆ ของฐานข้อมูล
User/Programmer
Stored Database
Definition
Stored Database
(META-DATA)
ภาพที่ 2-4 ระบบฐานข้อมูล
Application Programs/Queries
Software to process
queries/programs
Software to access
stored data
9
ระบบจัดการฐานข้อมูลในระยะแรกจะถูกพัฒนาเพื่อใช้บนเครื่องเมนเฟรม แต่ในปัจจุบัน
สามารถพบได้ในคอมพิวเตอร์ทุกขนาด โดยมีอัตราการเติบโตของการใช้งานประมาณ 30-
35% ต่อปีโดยปกติแล้ววิธีการเรียกใช้ ตลอดจนเพิ่มเติมหรือเปลี่ยนแปลงแก้ไขข้อมูลที่จัดเก็บไว้
ในฐาน ข้อมูลมีวิธีต่าง ๆ ดังนี้
2.2.1.1 เชื่อมโยงกับภาษาการโปรแกรม (Programming Language
Interface) นิยมใช้วิธีนี้ใน
การเขียนโปรแกรมที่ต้องมีการเรียกใช้หรือแก้ไขค่าของข้อมูลในฐานข้อมูลตลอดจนการสร้าง
รายงานที่มีการคำนวณซับซ้อน อาจใช้ภาษา COBOL, C หรือภาษาในระดับสูงและสูงมาก
อื่น ๆ ในการเชื่อมต่อเข้ากับฐานข้อมูลก็ได้
2.2.1.2 ภาษาในการจัดการข้อมูล (Query Languages) เป็นภาษาที่ถูกออกแบบ
มาโดยเฉพาะ
ให้ใช้กับฐานข้อมูล นิยมใช้กันมากในปัจจุบัน เพราะใช้ง่ายและเรียกดูข้อมูลได้อย่างรวดเร็ว
จัดเป็นภาษาในยุคที่สี่ ไม่ต้องมีการแปลภาษา (Compile) หรือ เชื่อมโยง (Link) ก่อนใช้
งาน
2.2.1.3 ตัวสร้างรายงาน (Report Generator) ถูกออกแบบมาให้สร้างรายงานที่
ซับซ้อนและมี
ขนาดใหญ่หรือยาวมากได้อย่างรวดเร็ว
2.2.1.4 โปรแกรมอรรถประโยชน์ของระบบ (System Utilities) จะเป็น
โปรแกรมที่ถูกใช้งาน
โดยผู้จัดการระบบ (System Manage) หรือที่นิยมเรียกว่า ผู้ดูแลระบบฐานข้อมูล
(Database Administrator) โปรแกรมประเภทนี้นิยมใช้ในการ เก็บสำรอง
(Backup) ฐานข้อมูล เรียกข้อมูลจากฐานข้อมูล หรือจัดเก็บข้อมูลไว้ในฐานข้อมูล รวมทั้งการ
เรียกคืน (Restore) ข้อมูลในกรณีที่ระบบมีปัญหา
2.2.2 คุณสมบัติของระบบจัดการฐานข้อมูล
ระบบจัดการฐานข้อมูลที่ดีจะต้องมีคุณสมบัติดังนี้
2.2.2.1 ต้องมีการใช้งานทรัพยากรของคอมพิวเตอร์อย่างมีประสิทธิภาพ
2.2.2.2 ต้องมีความเร็วในการตอบคำถามที่ผู้ใช้ถามอยู่ในเกณฑ์ที่ยอมรับได้(โดย
ปกติ
มักจะหมายถึงตอบทันทีทันใด)
2.2.2.3 ต้องมีความเข้ากันได้กับ Hardware Software และข้อมูลที่มีใช้งานอยู่เดิม เพื่อ
10
ลดค่าใช้จ่ายในการเปลี่ยนแปลงให้เหลือน้อยที่สุด
2.2.2.4 ประสิทธิภาพ รวมทั้งจะต้องยืดหยุ่นพอที่จะจัดการกับการเปลี่ยนแปลงหรือ
เปลี่ยนรูปแบบของข้อมูลในฐานข้อมูล
2.2.2.5 ต้องให้ความสะดวกกับผู้ใช้ในการเรียกใช้งานฐานข้อมูล เช่นมีภาษาใน
การ
สอบถามข้อมูล (Query Language)
2.2.2.6 ต้องมีระบบรักษาความถูกต้องของข้อมูลโดยการสำรองข้อมูล รวมทั้ง
ป้องกันผู้ใช้จากการทำงานผิดพลาดต่าง ๆ
2.2.2.7 ต้องมีระบบรักษาความลับของข้อมูลในฐานข้อมูลนั้น เช่นมีคุณสมบัติ
การ
ตรวจสอบ Password และรหัสพิเศษในการเข้าใช้งาน
2.2.3 ภาษาอธิบายข้อมูล (Data Definition Language)
นิยมเรียกว่า DDL จะเป็นภาษาที่ใช้ในการอธิบายถึงโครงสร้าง (Schema) ของ
ข้อมูลที่เก็บอยู่ในฐานข้อมูล โดยภายในโครงสร้างนี้แต่ละฟิล์ดในเรคคอร์ดจะมีการกำหนดชื่อ
ความยาว และชนิดของข้อมูล นอกจากนี้ DDL ยังใช้ในการอธิบาย โครงสร้างย่อ
(Subschemas) ซึ่งใช้กำหนดฟิล์ดที่ผู้ใช้สามารถเรียกใช้งานได้ และผู้ใช้แต่ละคนจะสามารถ
เข้าถึงโครงสร้างย่อยที่แตกต่างกันไป ทำให้สามารถใช้ป้องกันข้อมูลที่เป็นความลับได้
2.2.4 ภาษาสอบถามข้อมูล (Query Language)
ภาษาในการสอบถามข้อมูลเชิงคำสั่ง (Command-Oriented Query
Language) เป็นภาษาที่ถูกออกแบบมาโดยเฉพาะ เพื่อใช้กับงานการจัดการข้อมูลที่อยู่ใน
ฐานข้อมูล จะมีลักษณะการใช้งานคล้ายกับการใช้ภาษาอังกฤษ ทำให้ผู้ใช้ไม่ต้องมีความรู้ทาง
คอมพิวเตอร์สูงมากนักก็สามารถเรียกใช้ได้โดยสะดวกโดยทั่วไปมีคำสั่งหลัก ๆ ดังนี้
ตารางที่ 2-1 ตัวอย่างคำสั่งของภาษาในการสอบถามข้อมูลเชิงคำสั่ง
คำสั่ง วัตถุประสงค์
INSERT RECORD เพิ่มข้อมูลชุดใหม่ลงไฟล์
DELETE RECORD ลบข้อมูลชุดหนึ่งออกจากไฟล์
SELECT เลือกข้อมูลชุดที่ต้องการ
PROJECT เลือกฟิล์ดที่ต้องการ
JOIN สร้างไฟล์ใหม่โดยประกอบด้วยฟิล์ดต่างๆ
จากไฟล์สองไฟล์
11
ภาษาในการสอบถามข้อมูลที่ได้รับความนิยมสูงสุดในปัจจุบัน คือ Structured
Query Language (SQL) ซึ่งมีการใช้งานอย่างกว้างขวางนับตั้งแต่เริ่มนำมาใช้ในเครื่อง
เมนเฟรมของ IBM ในปี 1980 ในปัจจุบันมีการใช้งานตั้งแต่เครื่องระดับไมโครคอมพิวเตอร์
จนถึงระดับเมนเฟรม
2.3 ประวัติของภาษา SQL (ศิริลักษณ์, 2542 :30-35)
ในช่วงทศวรรษที่ 1970 นักคณิตศาสตร์ชื่อ Dr. CODD ได้ทำงานวิจัยให้กับ
IBM เกี่ยวกับทางด้านทฤษฎีความสัมพันธ์ของข้อมูล และได้นิยามฐานข้อมูลเชิงสัมพันธ์ด้วย
คณิตศาสตร์ของเซ็ตและพริดิเคตโลจิก มีการตีพิมพ์เพื่อเผยแพร่ในงานสัมนาระบบจัดการ
ฐานข้อมูลเชิงสัมพันธ์ใน หัวข้อ “A Relational Model of Data for Large
Shared Data Banks” ซึ่งมีกฎสำหรับฐานข้อมูลเชิงสัมพันธ์ที่เรียกว่า 12 Fidelity
Rules (กฎแห่งความซื่อสัตย์ 12 ข้อ) หรือกฎ 12 ข้อของ COOD’s
2.3.1 กฎข้อที่ 0 Foundation Rule กฎที่เป็น DBMS แบบเชิงสัมพันธ์ จะต้อง
สามารถจัดการกับฐานข้อมูลทั้งหมดได้ด้วยความสามารถเชิงสัมพันธ์
2.3.2 กฎข้อที่ 1 Information Ruleข้อมูลทั้งหมดในระบบฐานข้อมูลเชิงสัมพันธ์
(รวมทั้งชื่อตาราง ชื่อคอลัมภ์) ในระดับ Logical หรือ ระดับ Conceptual จะต้องแสดง
ให้เห็นอย่างชัดเจนในรูปของตาราง
2.3.3 กฎข้อที่ 2 Guaranteed Rule ทุกค่าของข้อมูลในระบบฐานข้อมูลเชิง
สัมพันธ์ จะต้องรับประกันได้ว่าสามารถเข้าถึงโดยการรวมชื่อตาราง ค่าของ Primary Key
และชื่อของคอลัมภ์
2.3.4 กฎข้อที่ 3 Systematic null Value Rule ระบบการจัดการฐานข้อมูล
(DBMS) ได้จัดเตรียมระบบในการสนับสนุน – จัดการกับค่าว่าง (Null) ค่าที่แตกต่างจาก
Default และค่าศูนย์ (0)
2.3.5 กฎข้อที่ 4 Active Online Relational Catalog Ruleลักษณะของ
ฐานข้อมูลและสิ่งที่อยู่ภายในจะต้องแสดงให้เห็นในระดับตรรกะ (Logical Level) เหมือน
ตาราง และสามารถเรียกดู แก้ไขโดยใช้ภาษาฐานข้อมูลชุดเดิมกับที่ใช้เรียกดูข้อมูลในระบบ
2.3.6 กฎข้อที่ 5 Comprehensive data sublanguage Ruleจะต้องมี
ภาษาระดับสูงในการทำงานเพื่อ การกำหนดความสัมพันธ์ในการนิยามโครงสร้างของข้อมูล
(Data Definition) การจัดการข้อมูล (Data Manipulation) การรักษาความบูรณ
ภาพของข้อมูล (Integrity) มีอำนาจควบคุมและการทำ Transaction
12
2.3.7 กฎข้อที่ 6 View Update Rule ต้องสามารถ Update แก้ไขข้อมูลผ่าน
ทาง View ได้โดยที่โปรแกรมจัดการฐานข้อมูลจะต้องเป็นตัวจัดการพิจารณาให้หรือไม่ให้ผู้ใช้
แก้ไขข้อมูลผ่าน View
2.3.8 กฎข้อที่ 7 Set Level Update Rule ระบบจัดการข้อมูล (DBMS)
จะต้องทำได้มากกว่าการให้ผู้ใช้เรียกดูข้อมูล คือต้องให้ผู้ใช้สามารถเพิ่ม (Insert) แก้ไข
(Update) ลบ (Delete) ข้อมูลได้
2.3.9 กฎข้อที่ 8 Physical data independence Rule ระบบจัดการข้อมูล
(DBMS) จะต้องมีความเป็นอิสระของข้อมูล ในระดับกายภาพ โดยการเปลี่ยนแปลงใด ๆ จะ
ไม่ส่งผลกระทบต่อโปรแกรมใช้งานซึ่งอยู่ในระดับที่สูงกว่า
2.3.10 กฎข้อที่ 9 Logical data independence Rule ระบบจัดการข้อมูล
(DBMS) จะต้องมีความอิสระของข้อมูลในระดับตรรกะ (Logical) โดยการเปลี่ยนแปลง
ใด ๆ ในส่วนนี้จะไม่ส่งผลกระทบต่อโปรแกรมใช้งานซึ่งอยู่ในระดับสูงกว่า
2.3.11 กฎข้อที่ 10 Integrity independence Rule ความถูกต้องความบูรณ
ภาพของข้อมูลในระบบฐานข้อมูลจะต้องถูกจัดเก็บในแคตาล็อกของระบบ และมีความเป็นอิสระ
ในการจัดเก็บข้อมูลโดยไม่ขึ้นกับโปรแกรมหรือระดับที่สูงกว่า
2.3.12 กฎข้อที่ 11 Distribution independence Rule ระบบจัดการข้อมูล
(DBMS) จะต้องมีความเป็นอิสระต่อการกระจายข้อมูล ไม่สนใจว่าข้อมูลจะอยู่ที่ใด หรือส่วน
ในบนระบบ Network
2.3.13 กฎข้อที่ 12 Nonsubversion Rule ระบบจัดการข้อมูล (DBMS)
จะต้องไม่ให้ภาษาฐานข้อมูล หรือภาษา low level ละเมินกฎของความบูรณภาพ
(Integrity) อย่างเด็ดขาด
ประมาณปี 1970 ได้มีการพัฒนาภาษาในยุคที่ 4 (4 GLs = Fourth
Generation Language) คือภาษา SQL (Structured Query Language)
ถูกออกแบบและพัฒนาโดย DD. Chamberlin ณ ห้องวิจัยของบริษัท IBM ในรัฐซานโฮ
เซ่ และมีการพัฒนาจนกลายเป็นผลิตภัณฑ์ในเชิงพาณิชย์ตั้งแต่ประมาณปี ค.ศ. 1981 เช่น
VM/CMS (IBM Corp.), ORACLE (Oracle Corp.), Data General
SQL (Data Gen. Corp.), SYBASE (Sybase Inc.), DB2 (IBM
Corp.) ประมาณปี ค.ศ. 1982 หน่วยงานกำหนดมาตราฐาน ANSI (American
National Standards Institute) ได้มีกำหนดมาตรฐานให้ภาษา SQL เป็น
ANSI-86, ANSI-89 และ ANSI-92 SQL ตามลำดับ และเข้าสู่การปรับปรุง
13
มาตรฐานจากเดิมมาเป็น SQL/2 และ SQL/3 ตามแบบ ISO (International
Standard Organization)
2.4 สถาปัตยกรรม Client/Server (อำไพ, 2543 :36-38)
ระบบ Client / Server เป็นสถาปัตยกรรมซอฟต์แวร์ที่ระบบซอฟต์แวร์ได้รับการ
ออกแบบให้แยกเป็น 2 ส่วน ส่วนแรกเรียกว่าส่วน Client และอีกส่วนเรียกว่าส่วน Server
ซอฟต์แวร์ส่วน Client ต้องสื่อสารติดต่อกับส่วน Server ดังรูปที่ 2-5 โดยที่ซอฟต์แวร์
ส่วนClient จะขอให้ข้อมูลจากซอฟต์แวร์ส่วน Server ซอฟต์แวร์ส่วน Server จะ
ตอบสนองโดยการดึงข้อมูลจากฐานข้อมูล แล้วส่งไปยังส่วน Client เพื่อประมวลผลต่อไป โดย
ส่วนของ Client กับ Server สามารถแบ่งได้เป็น
2.4.1 อยู่เครื่องเดียวกัน
2.4.2 อยู่คนละเครื่องแต่เชื่อมผ่านเครือข่ายได้ 3 แบบ
2.4.2.1. LAN (Local Area Network)
2.4.2.2. WAN (Wide Area Network)
2.4.2.3. Internet
โดยการแบ่งส่วนของซอฟต์แวร์ระหว่าง Client และ Server สามารถแสดงได้ดังภาพ
ที่ 2-5
ขอข้อมูล
ข้อมูล
ภาพที่ 2-5 การแยกซอฟต์แวร์ส่วน Client และ Server
ซอฟต์แวร์
Client
ซอฟต์แวร์
Server
14
ปกติแล้วข้อมูลจะอยู่ข้าง Server ในฐานข้อมูล ซึ่งอาจเป็นฐานข้อมูล MS Access
ฐานข้อมูล MS SQL Server ฐานข้อมูล Oracle ฐานข้อมูล Informix ฐานข้อมูล
DB2 ข้าง Client จะส่งคำสั่ง SQL ขอใช้ข้อมูลไปยัง Server แล้ว Server จะ
ตีความหมายของคำสั่ง SQL Statement แล้วดึงข้อมูลจากฐานข้อมูลส่งไปยัง Client
2.4.3 Model ของกระบวนงาน Client / Server อธิบายได้ว่า Client คือ
ซอฟต์แวร์ที่เป็นกระบวนงานในการขอบริการหรือข้อมูล (Launcher/Requester
Process) ซึ่ง Client Application จะติดต่อกับ Client Application อื่นได้
และใช้ทรัพยากรร่วมกันและติดต่อขอใช้ข้อมูลและบริการจาก Server ต่าง ๆ ทำให้เพิ่มขีด
ความสามารถของผู้ใช้งาน Client สามารถมีหน้าจอของตัวเองที่ได้รับการออกแบบมาให้ผู้ใช้
สามารถใช้งานได้สะดวก โดยที่ไม่ต้องมีความรู้ด้านกลไกที่อยู่เบื้อหลัง นั่นคือ Client จะซ่อน
ความซับซ้อนของระบบปฏิบัติการเครือข่าย (Network Operating System) วิธีการ
นำข้อมูลมาใช้ทำให้ผู้ใช้รู้สึกว่าสามารถทำงานได้อย่างสะดวกตาม Business Rule ที่ตัวเอง
เข้าใจ
Server เป็นซอฟต์แวร์ที่สามารถตอบสนองต่อการขอบริการและข้อมูลของ Client
โดย Server มีหน้าที่ตีความ Request ของ Client การจัดการกับขั้นตอนการ Access
ข้อมูลหลังบริการ การให้บริการข้อมูลเฉพาะที่ต้องใช้ ซอฟต์แวร์ Server อาจอยู่บนเครื่อง
คอมพิวเตอร์เครื่องเดียวกัน หรือบนต่างเครื่องกันก็ได้ ส่วนเครื่องที่ Run Server ได้นั้นจะ
เป็นเครื่องระดับ Pentium ระดับ Mini หรือ Mainframe แล้วแต่ระบบ
เครือข่ายเป็นตัวที่ทำหน้าที่ถ่ายเทข้อมูลระหว่าง Client กับ Server เครือข่ายจะต้อง
Transparent ในสายตาทุกฝ่าย ปกติแล้วเครือข่ายจะมีการใช้ Protocol อยู่หลายตัวใน
การควบคุม การส่งและการรับข้อมูล Protocol เหล่านี้ต้องสามารถได้รับการเปลี่ยนแปลงโดย
ที่ผู้ใช้ (ไม่ว่าจะเป็นคนหรือโปรแกรม) ไม่ต้องกังวล
2.4.4 Gartner Client-Server Reference Model การจำแนกคุณลักษณะ
ของกระบวนงาน Client และ Server ที่ไม่ติดกับคุณลักษณะของ Hardware หรือที่
เรียกว่า Logical Process ไว้ดังนี้
2.4.4.1 ฟังก์ชันงาน งาน Client – Server จำแนกเป็น 3 ฟังก์ชัน
ก). Presentation Form (งานหน้าจอและรวมกับกรรมวิธีหน้าจอ)
ข). Business Logic (กรรมวิธีงานธุรกิจของระบบ)
ค). Data Management ( กระบวนการนำข้อมูลมาใช้)
2.4.4.2 รูปแบบการใช้ฟังก์ชัน
15
ก). แบบ Intact นั่นคือฟังก์ชันงานนั้นประกอบด้วยโปรแกรมที่อยู่บน
Platformเดียวกัน
ข). แบบ Distributed นั่นคือฟังก์ชันงานกระจายอยู่บน Platform
หลาย
Platform(หรือหลาย Server) ซึ่งการใช้งานข้อมูลหรือบริการอาจจะต้องเรียกจากหลาย
Server
2.4.4.3 จำนวนชั้น
ก). แบบ Two-Tier (มี Client กับ Database Server ) มี
Server เดียวนั่นเอง
ข). แบบ Multi-Tier มี Client และ Server ต่าง ๆ ซึ่ง Server
หลาย ๆ ตัวนี้แต่ละตัวจะมีหน้าที่เฉพาะ
Database Server
a) 2-tier Client / Server
Application Server
Database Server
b) 3-tier Client / Server
ภาพที่ 2-6 ลักษณะ Client/Server แบบ 2-tier และ 3-tier
2.4.4.4 การออกแบบระบบ Client / Server การออกแบบระบบ Client /
Server ทำได้ 2 แบบ ได้แก่แบบ Structured Design และแบบ Object –
Oriented Design การออกแบบ Structured Design นั้นเป็นแบบปกติ
(Conventional) ที่เข้าใจกันโดยที่มีรูปแบบขั้นตอนเป็นไปตาม Life Cycle แบบ
Water Fall ดังภาพที่ 2-7
Client
Client
Requirement
Analysis
16
ภาพที่ 2-7 วงจรชีวิตแบบ Water Fall สำหรับการพัฒนาระบบ Client /
Server
ในการออกแบบระบบ Client / Server นั้นตัวโปรแกรมจะได้รับการแบ่งเป็น 3
ส่วนได้
เช่น ส่วนหน้าจอ (Presentation) ส่วนโปรแกรม (Business Logic) และส่วน
บริหารข้อมูล
(Data Management) ตามภาพที่ 2- 8 ซึ่งส่วนหน้าจอนั้นจะมีการออกแบบและกำหนด
มาตรฐาน
GUI (Graphical User
Interface)
Delphi Programming
Routine
Implementation Business
Logic
Accessing Database
ภาพที่ 2-8 การแบ่งโปรแกรม Client / Server เป็น 3 ส่วน
2.4.4.5 Graphical User Interface การออกแบบส่วนนี้จะมีการ Paint
หน้าจอ และนิยาม Property ต่าง ๆ ไว้เป็นโครง โดยที่หน้าจอจะต้องออกแบบให้ใช้งาน
สอดคล้องกับกระบวนงานของธุรกิจนั้น
Logical Design
Physical Design
Coding
Testing
Deployment
Use & Maintenance
Presentation
Business Logic
Data Management
17
2.4.4.6 Business Logic ส่วน Business Logic นั้นคือส่วนที่ผู้ออกแบบจะกำหนดมาเป็น
Pseudo Code หรือ Flow Chart โดยมีการกำหนด Data Validation และกรรมวิธีการจัดการกับ Event
ที่ไม่คาดหมาย ตอดจนสถานภาพเบื้องต้นของแต่ละหน้าจอ
2.4.4.7 Data Managementส่วนการดึงข้อมูลจากฐานข้อมูลมาใช้นั้น จะมีการกำหนด
ชัดเจนถึงกรรมวิธีว่าจะเรียกใช้โดยตรงหรือเป็นการเรียกใช้แบบส่งคำสั่งไปให้ทำงานข้าง Server
แล้วส่งแต่ผลลัพธ์กลับมาข้าง Client เพื่อการแสดงผล เรื่องการกำหนดงานควรจะทำที่ข้าง Client
หรือข้าง Server หรือทั้งสองข้างซึ่งจะมีผลต่อความเร็ว
2.5 ระบบงาน Hospital Management Information System
(HMIS)
ปัจจุบันนี้ได้มีการใช้ซอฟต์แวร์เพื่อบริหาร/ จัดการเกี่ยวกับระบบข้อมูลของโรงพยาบาล
หรือที่เรียกว่า Hospital Management Information System (HMIS) ซึ่ง
ซอฟต์แวร์นี้จะช่วยในการจัดการด้านข้อมูล สร้างการเข้าถึงข้อมูลที่ง่ายขึ้น สะดวกในการ
เปลี่ยนแปลงแก้ไข (Update) และทำให้เราสามารถใช้ในการติดตามข้อมูลทุกด้านของผู้ป่วยที่
เราต้องการทราบ
HMIS จะ Compiles โดยอาศัยมาตรฐานสากล (International
Standards) 3 ตัวด้วยกันคือ (ICD10) (DRG) (HL7) ซึ่งออกแบบมาเพื่อรองรับ
การทำงานในส่วนต่าง ๆ ดังนี้
2.5.1 Patient’s Management Function
2.5.2 Order Communication
2.5.3 Pharmacy
2.5.4 Laboratory
2.5.5 Blood Bank
2.5.6 Radiology
2.5.7 Operation Theater
2.5.8 Dietary & Service
2.5.9 Accidents & Emergency
2.5.10 Nursing Care
2.5.11 Medical Record
2.5.12 Patient’s Financial Management
โดยการทำงานในส่วนของระบบคลังยาและห้องจ่ายยา (Pharmacy) นั้นมีมาตรฐานงานดังนี้
2.5.1.1 สนับสนุนการทำงานของคลังยาและห้องจ่ายยาย่อย ๆ ทั้งหลายใน
18
โรงพยาบาลเดียวกัน
2.5.1.2 อนุญาติให้มีการประเมินผลจากห้องจ่ายยาหลาย ๆ ห้องในเวลาเดียวกัน
2.5.1.3 สนับสนุนการใช้หน่วยในการวัด (Measurement)ได้หลากหลายหน่วย
2.5.1.4 ทำการควบคุมคลังยา (Drug Inventory) ได้อย่างสมบูรณ์
2.5.1.5 รองรับนโยบายด้านราคา / ค่าใช้จ่ายได้หลากหลาย
2.5.1.6 ควบคุมการจ่ายยาประเภทยาควบคุมพิเศษ ณ ช่วงเวลาที่มีการสั่งยาและการจ่าย
ยา
ให้กับผู้ป่วย
2.5.1.7 ตรวจสอบยาหมดอายุ
2.5.1.8 ตรวจสอบโดยอัตโนมัติในเรื่องการแพ้ยาของผู้ป่วย
2.5.1.9 มีระบบรองช่วยในการพิจารณาเลือกใช้ยาในกลุ่มที่ออกฤทธิ์เหมือนกัน หรือใช้
ทดแทนกันได้
2.5.1.10 ช่วยให้ผู้ใช้สามารถเลือกใช้ยาตามข้อระบุได้
2.5.1.11 มีการใช้ระบบ Barcode ในการทำงาน
2.5.1.12 ดูแลและทำงานกับ Drug Manufacturing
2.5.1.13 ออกรายงานโดยละเอียดเพื่อประโยชน์ในการควบคุมระบบคลังยาและ
ห้อง จ่ายยา
2.5.1.14 ออกรายงานเกี่ยวกับการวิเคราะห์ด้านการเงิน
2.5.1.15 มีระบบจัดการ / รองรับเรื่องปฏิกิริยาระหว่าง Drug to Drug และ
Drug to Food
2.6 Health Level Seven (HL7)
เป็นหนึ่งในมาตรฐานข้อมูล (Protocal) ที่พัฒนาโดย ANSI-accredited Standards Developing
Organizations (SDOs) สำหรับข้อมูล ที่เป็นมาตรฐานใช้ในการแลกเปลี่ยนข้อมูลกัน เช่น ข้อมูลของ
คนไข้ ซึ่งจะอยู่ในกระบวนการต่างๆ ของระบบโรงพยาบาลเพื่อเป็นมาตรฐานเดียวกัน ในการที่จะ
สามารถแลกเปลี่ยนข้อมูลของคนไข้ในฐานข้อมูล ซึ่งมาจากที่แตกต่างกันได้ จึงได้มีการพัฒนา ให้
เป็นรูปแบบเดียวกัน ซึ่งก็คือ HL7 สรุปได้ว่า: HL7 ก็คือ มาตรฐาน ที่ใช้ในการกำหนดเพื่อให้
สามารถ ที่จะแลกเปลี่ยนข้อมูล กันได้ระหว่างโปรแกรม (ข้อมูลก็คือ ข้อมูลคนไข้ เช่น ชื่อ นามสกุล
วันเดือนปีเกิด ที่อยู่ ผลการตรวจรายงานเป็นต้น)
2.6.1 ความหมายของ HL7 "Level Seven" หมายถึง ระดับที่สูงที่สุดในรูปแบบ
การสื่อสารข้อมูล ตามแบบของ ISO (International Standards Organization)
19
ซึ่งเป็นแบบการสื่อสารข้อมูลแบบเปิดที่เรียกว่า Open Systems Interconnection
(OSI) ซึ่ง ระดับ 7 คือ ระดับการทำงานของโปรแกรม (Application Level)ความ
จำเป็นในการใช้ โปรแกรมระบบโรงพยาบาล ที่เป็นในรูปแบบของ HL7 คำตอบก็ขึ้นอยู่กับ
ความเป็นของ งานที่เกี่ยวข้องกับข้อมูลคนไข้มากกว่า สำหรับโรงพยาบาลที่จำเป็นต้องใช้
โปรแกรมที่เป็นไปตาม HL7 คือ โรงพยาบาล ที่มีโปรแกรม หลายระบบ ซึ่ง ทำให้การ
แลกเปลี่ยนข้อมูลระหว่างฐานข้อมูลมีปัญหาคือไม่สามารถใช้ร่วมกันได้ตัวอย่างเช่นระบบ
โรงพยาบาล ซึ่งแยกเป็น
2.6.1.1 Order Entry (Observation, Pharmacy, Dietary,
and Supplies)
2.6.1.2 Scheduling (Appointment Scheduling and
Resources)
2.6.1.3 Medical Records/Information Management
(Document Management
Services and Resources)
2.6.1.4 Patient Administration (Admission, Discharge,
and Transfer Transactions
2.6.1.5 Observation Reporting (Observation Report
Messages)
2.6.1.6 Financial Management (Patient Accounting and
Charges)
2.6.1.7 Patient Care (Problem-Oriented Records)
2.6.1.8 Xray (RIS) Lab (LIS)
ซึ่งถ้าหากโปรแกรมเหล่านี้ใช้ฐานข้อมูลคนละชุดจะสามารถแลกเปลี่ยนข้อมูลคนไข้ได้ถ้าเป็นไป
ตาม HL7 ถ้าระบบที่ใช้อยู่ได้ออกแบบฐานข้อมูลชุดเดียวกันแล้ว ในแง่ของเทคนิค ก็สามารถที่
จะดึงข้อมูลต่างมาตรฐานกันมาใช้ด้วยกัน
2.7 Delphi
Delphi เป็นซอฟต์แวร์ที่ใช้ในการเขียนโปรแกรมเพื่อสร้างแอพพลิเคชัน หรือซอฟต์แวร์
อีกที โดยจะประกอบด้วยเครื่องมือชนิดต่าง ๆ ที่ใช้ให้การเขียนโปรแกรมทำได้อย่างสะดวก โดย
ตัว Delphi เป็นเครื่องมือเขียนโปรแกรมชนิด Visual Programming เช่นเดียวกัน
Visual Basic หรือ Visual C++ โดยมีข้อดี คือ สามารถเขียนโปรแกรมได้ง่าย และ
ให้ผลงานออกมาอย่างรวดเร็ว ซึ่งจะแตกต่างจากเครื่องมือเขียนโปรแกรมรุ่นเดิม ๆ เช่น Turbo
Pascal หรือ Borland C ที่มีความยุ่งยากในการใช้งานและการเรียนรู้ในการเขียนโปรแกรม
20
ดังนั้นจึงจัดให้ Delphi 7.0 เป็นซอฟต์แวร์ประเภท RAD หรือ Rapid
Application Development ซึ่งแปลว่าสามารถสร้างแอพลิเคชันได้อย่างรวดเร็ว
2.7.1 จุดเด่นของ Delphi 7.0 เนื่องจากDelphi 7.0 นั้นผ่านการพัฒนามาเกือบ
10 ปี ตั้งแต่เวอร์ชัน 1.0 ที่ทำงานบน Windows 3.1X โดยมีจุดเด่นมาก คือโปรแกรมที่
ได้จากการเขียนมีขนาดเล็ก ทำงานได้รวดเร็ว ซึ่งมักจะถูกนำไปเปรียบเทียบกับ Visual
Basic 3.0 ในสมัยนั้น อีกประการหนึ่ง Delphi 7.0 ใช้ภาษาออบเจ็กต์ปาสคาลจึงเคยถูก
เปรียบเทียบว่าเป็น Visual Pascal มาแล้ว
เวอร์ชันปัจจุบันของ Delphi นั้นได้รับการพัฒนาให้สามารถสร้างแอพลิเคชันที่ทำงาน
บน Windows ได้ดีเหมือนเดิม โดยมีการปรับปรุงให้สามารถพัฒนาแอพลิเคชันตาม
แนวความคิดของ .NET ซึ่งจะช่วยให้สามารถเขียนโปรแกรมครั้งเดียวแล้วนำไปใช้งานบน
อุปกรณ์ต่างๆ ได้ ขณะเดียวกันก็ได้รับการพัฒนาให้สามารถพัฒนาแอพลิเคชันแบบข้ามแพล็ต
ฟอร์มได้ นั่นคือสามารถพัฒนาแอพลิเคชันที่ทำงานได้บนทั้ง Windows และ Linux
นั่นเอง
2.7.1.1 ความสามารถของ Delphi 7
ก). สร้างแอพลิเคชันสำหรับ Windows ได้อย่างรวดเร็ว และใช้ได้กับ
หลายเวอร์ชัน ซึ่งแอพลิเคชันที่สร้างจาก Delphi ได้รับการยกย่องอย่างมากในด้านขนาด
โปรแกรมที่เล็กกะทัดรัด และทำงานได้อย่างรวดเร็ว เมื่อเทียบกันแอพลิเคชันที่สร้างจากเครื่องมือ
อื่นๆ
ข).สร้างระบบงานด้านฐานข้อมูล ได้หลายรูปแบบ มีวิธีการและเครื่องมือใน
การสร้างระบบงาน ระบบรายงานสำหรับงานในด้านต่าง ๆ เช่น ระบบบัญชี ระบบบริหารงาน
บุคคล ระบบคลังสินค้า หรือแม้แต่ระบบจองตั๋วในโรงภาพยนต์ชั้นนำ แอพลิเคชันที่เกี่ยวกับ
ฐานข้อมูลที่สร้างจาก Delphi สามารถนำไปใช้งานกับระบบฐานข้อมูลชั้นนำแทบทุกชนิดทั่ว
โลก นับตั้งแต่ระบบฐานข้อมูลส่วนบุคคลทั้ง Access, Paradox, Foxpro ไปจนถึง
ระบบฐานข้อมูลขนาดใหญ่ทั้ง Oracle, Sybase, SQL Server รวมถึงระบบไฟล์ชนิด
ต่างๆ ได้ด้วย
ค). สร้างแอพลิเคชันรองรับ .NET Web Service
ง). พอร์ตโปรแกรมไปใช้งานบน Linux ได้ง่าย โดยผ่านเครื่องมือที่มีชื่อ
ว่า
Kylix
2.8 Case Tools
21
การวิเคราะห์และออกแบบระบบในปัจจุบัน นิยมใช้ Case Tools เป็นเครื่องมือในการ
ทำงาน ซึ่งจะช่วยให้การวิเคราะห์และออกแบบระบบเกิดความสะดวกรวดเร็วมากยิ่งขึ้นสำหรับการ
สร้างแบบจำลองต่าง ๆ เนื่องจาก Case Tools สามารถตรวจสอบความผิดพลาดในระหว่าง
การสร้างแบบจำลองได้ และยังสามารถสร้าง Data Dictionary ให้อัตโนมัติอีกด้วย
ความสามารถของ Visio 2002 ในการสร้าง DFD
2.8.1 สามารถใช้สัญลักษณ์ตามทฤษฏีต่าง ๆ เช่น OMT,
Yourdon/DeMarco,
Gane&Sarson
2.8.2 ตรวจสอบความถูกต้องและสอดคล้องของ Data Flows ได้
2.8.3 สามารถสร้าง Process Hierarchy หรือแบ่งย่อยแผนภาพได้
2.8.4 สามารถเพิ่ม Data Items (Data Attributes) ได้จากการสร้าง DFD
และนำไปใช้ในการ
สร้าง E-R Diagram ได้
2.8.5 สามารถใช้ OLE Technology ในการเชื่อมโยงแบบจำลองที่สร้างขึ้นไปยัง
แอพลิเคชัน
อื่นได้
2.8.6 สามารถสร้าง Data Dictionary ได้โดยอัตโนมัติจากรายละเอียดของแต่ละ
สัญลักษณ์ที่กำหนดไว้ในระหว่างการสร้าง DFD
2.9 สรุป
จากที่กล่าวมาในเบื้องต้น ระบบสารสนเทศโรงพยาบาลส่วนของคลังยาและห้องจ่ายได้นำ
ทฤษฎีเหล่านี้มาประยุกต์ใช้ในการออกแบบและพัฒนาระบบกล่าวคือ ได้มีการประยุกต์ใช้
สถาปัตยกรรมแบบ Client/Server ในการรับส่งข้อมูลระหว่างเครื่องคอมพิวเตอร์ที่เป็นแม่
ข่ายกับเครื่องคอมพิวเตอร์ที่เป็นลูกข่าย โดยเลือกใช้ฐานข้อมูลแบบเชิงสัมพันธ์ (Relational
Model) ในการออกแบบฐานข้อมูล ใช้ MySQL เป็นฐานข้อมูลและใช้ Delphi 7.0
เป็นภาษาในการพัฒนาการซึ่งในการวิเคราะห์และออกแบบระบบสารสนเทศโรงพยาบาลส่วนของ
คลังยาและห้องจ่ายยานี้ได้ยึดหลักระบบมาตรฐานข้อมูลของ HL7
บทที่ 4
ผลการทดสอบระบบ
ในกระบวนการทดสอบระบบสารสนเทศโรงพยาบาล:ส่วนของคลังยาและห้องจ่ายยานี้ผู้
จัดทำโครงงานใช้วิธีการทดสอบระบบแบบ แบล็กบอกซ์ (black box testing) โดยแบ่ง
การทดสอบออกเป็น 2 ส่วนดังต่อไปนี้
4.1 การทดสอบโดยผู้พัฒนาระบบ ซึ่งเป็นการทดสอบที่ผู้พัฒนาสมมุติข้อมูลขึ้นที่เรียกว่า
Test Data แล้วนำข้อมูลที่สมมุติขึ้นป้อนเข้าสู่ระบบในส่วนการทำงานต่าง ๆ ข้อมูลที่นำมา
ทดสอบเป็นทั้งข้อมูลที่ถูกต้องและไม่ถูกต้อง
ผู้จัดทำโครงการได้ออกแบบตารางสำหรับบันทึกผลการทดสอบ โดยแบ่งการทดสอบเป็น 2
ส่วนดังนี้คือ
4.1.1 ตารางบันทึกผลการทดสอบสำหรับการใช้งานระบบ
4.1.2 ตารางบันทึกผลการทดสอบสำหรับการทำงานห้องจ่ายยาและชำระเงิน
ในการทดสอบ จะป้อนข้อมูลที่สมมุติขึ้นสู่ระบบในการทำงานด้านต่างๆ แล้วผู้ทดสอบจะบันทึก
เครื่องหมาย ��ลงในช่องของการทดสอบเมื่อป้อนข้อมูลถูกต้อง และป้อนข้อมูลผิดพลาด ดัง
แสดงในตารางที่ 4-1
ตารางที่ 4-1 ตารางบันทึกผลการทดสอบสำหรับการตรวจสอบการเข้าใช้ระบบ
การทดสอบ
งาน
ป้อนข้อมูลถูกต้อง ป้อนข้อมูลไม่ถูกต้อง
ตรวจสอบการเข้าใช้ระบบงาน
- ป้อน Login Name และ
Password ไม่ถูกต้อง
��
- ป้อน Login Name เกิน ��
- ป้อน Password เกิน ��
จากการทดสอบเมื่อป้อนข้อมูลถูกต้องระบบจะอนุญาติให้ผู้ใช้สามารถ Login เข้าใช้งาน
ระบบได้ แต่หากป้อนข้อมูลไม่ถูกต้องระบบจะทำการเตือนเพื่อให้ผู้ใช้ป้อนข้อมูลแต่ละประเภทให้
ถูกต้องเสียก่อน
44
ตารางที่ 4-2 ตารางบันทึกผลการทดสอบสำหรับการทำงานห้องจ่ายยาและชำระเงิน
การทดสอบ
งาน
ป้อนข้อมูลถูกต้อง ป้อนข้อมูลไม่ถูกต้อง
การบันทึกข้อมูลยา / เวชภัณฑ์ใหม่
-ป้อนข้อมูลถูกต้อง ��
-ไม่ป้อนรหัสยา / เวชภัณฑ์ ��
-ไม่ป้อนชื่อยา / เวชภัณฑ์ ��
-ไม่ป้อนประเภทยา/เวชภัณฑ์ ��
-ไม่ป้อนราคาต้นทุน/หน่วย ��
-ไม่ป้อนราคาต้นทุน / หน่วยเป็นตัวเลข ��
-ไม่ป้อนราคาขาย / หน่วย ��
-ไม่ป้อนราคาขาย / หน่วยเป็นตัวเลข ��
-ไม่ป้อนปริมาณคงเหลือในคลัง ��
-ป้อนปริมาณคงเหลือต่ำกว่า 0 ��
-ไม่ป้อนปริมาณคงเหลือเป็นตัวเลข ��
-ไม่ป้อนปริมาณคงคลังต่ำสุด ��
-ไม่ป้อนปริมาณคงคลังต่ำสุดเป็นตัวเลข ��
-ป้อนปริมาณคงเหลือต่ำสุดต่ำกว่า 0 ��
-ไม่ป้อนวันที่หมดอายุ ��
-ไม่ป้อนวันที่เป็นตัวเลข ��
-ป้อนวันที่น้อยกว่า 1 หรือมากกว่า 31 ��
-ไม่ป้อนปีหมดอายุ ��
-ไม่ป้อนปีหมดอายุเป็นตัวเลข ��
-ป้อนปีหมดอายุต่ำกว่า 2000 ��
การบันทึกข้อมูล Lab ใหม่
-ป้อนข้อมูลถูกต้อง ��
-ไม่ป้อนข้อมูลรหัส Lab ��
-ไม่ป้อนชื่อ Lab ��
- ไม่ป้อนราคาต้นทุน / หน่วย ��
45
ตารางที่ 4-2 ตารางบันทึกผลการทดสอบสำหรับการทำงานห้องจ่ายยาและชำระเงิน (ต่อ)
การทดสอบ
งาน
ป้อนข้อมูลถูกต้อง ป้อนข้อมูลไม่ถูกต้อง
-ไม่ป้อนราคาต้นทุน / หน่วยเป็นตัวเลข ��
-ไม่ป้อนราคาขาย / หน่วย ��
-ไม่ป้อนราคาขาย / หน่วยเป็นตัวเลข ��
-ไม่ป้อนปริมาณคงเหลือในคลัง ��
-ป้อนปริมาณคงเหลือต่ำกว่า 0 ��
-ไม่ป้อนปริมาณคงเหลือเป็นตัวเลข ��
-ไม่ป้อนปริมาณคงคลังต่ำสุด ��
-ไม่ป้อนปริมาณคงคลังต่ำสุดเป็นตัวเลข ��
-ป้อนปริมาณคงเหลือต่ำสุดต่ำกว่า 0 ��
-ไม่ป้อนวันที่หมดอายุ (ประเภทใช้เวชภัณฑ์) ��
-ไม่ป้อนวันที่เป็นตัวเลข (ประเภทใช้
เวชภัณฑ์)
��
-ป้อนวันที่น้อยกว่า 1 หรือมากกว่า 31
(ประเภทใช้เวชภัณฑ์)
��
-ไม่ป้อนปีหมดอายุ (ประเภทใช้เวชภัณฑ์) ��
-ไม่ป้อนปีหมดอายุเป็นตัวเลข (ประเภทใช้
เวชภัณฑ์)
��
-ป้อนปีหมดอายุต่ำกว่า 2000 (ประเภทใช้
เวชภัณฑ์)
��
แก้ไขข้อมูลยา / เวชภัณฑ์
-ป้อนข้อมูลถูกต้อง ��
-ไม่ป้อนรหัสยา / เวชภัณฑ์ ��
-ไม่ป้อนชื่อยา / เวชภัณฑ์ ��
-ไม่ป้อนประเภทยา / เวชภัณฑ์ ��
-ไม่ป้อนราคาต้นทุน / หน่วย ��
-ไม่ป้อนราคาต้นทุน / หน่วยเป็นตัวเลข ��
46
ตารางที่ 4-2 ตารางบันทึกผลการทดสอบสำหรับการทำงานห้องจ่ายยาและชำระเงิน (ต่อ)
การทดสอบ
งาน
ป้อนข้อมูลถูกต้อง ป้อนข้อมูลไม่ถูกต้อง
-ไม่ป้อนราคาขาย / หน่วย ��
-ไม่ป้อนราคาขาย / หน่วยเป็นตัวเลข ��
-ไม่ป้อนปริมาณคงเหลือในคลัง ��
-ป้อนปริมาณคงเหลือต่ำกว่า 0 ��
-เปลี่ยนข้อมูลปริมาณคงเหลือ ��
-ไม่ป้อนปริมาณคงคลังต่ำสุด ��
-ไม่ป้อนปริมาณคงคลังต่ำสุดเป็นตัวเลข ��
-ป้อนปริมาณคงเหลือต่ำสุดต่ำกว่า 0 ��
-ไม่ป้อนวันที่หมดอายุ ��
-ไม่ป้อนวันที่เป็นตัวเลข ��
-ป้อนวันที่น้อยกว่า 1 หรือมากกว่า 31 ��
-ไม่ป้อนปีหมดอายุ ��
-ไม่ป้อนปีหมดอายุเป็นตัวเลข ��
-ป้อนปีหมดอายุต่ำกว่า 2000 ��
แก้ไขข้อมูล Lab
-ป้อนข้อมูลถูกต้อง ��
-ไม่ป้อนข้อมูลรหัส Lab ��
-ไม่ป้อนชื่อ Lab ��
-ไม่ป้อนราคาต้นทุน / หน่วย ��
-ไม่ป้อนราคาต้นทุน /หน่วยเป็นตัวเลข ��
-ไม่ป้อนราคาขาย / หน่วย ��
-ไม่ป้อนราคาขาย / หน่วยเป็นตัวเลข ��
-ไม่ป้อนปริมาณคลเหลือในคลัง ��
-เปลี่ยนจำนวนคงเหลือ ��
-ไม่ป้อนปริมาณคงคลังต่ำสุด ��
ตารางที่ 4-2 ตารางบันทึกผลการทดสอบสำหรับการทำงานห้องจ่ายยาและชำระเงิน (ต่อ)
47
งาน การทดสอบ ��
ป้อนข้อมูลถูกต้อง ป้อนข้อมูลไม่ถูกต้อง
-ไม่ป้อนปริมาณคงคลังต่ำสุดเป็นตัวเลข ��
-ไม่ป้อนวันทีเป็นหมดอายุ (ประเภทใช้
เวชภัณฑ์)
��
-ป้อนวันที่น้อยกว่า 1 หรือมากกว่า 31(
ประเภทใช้เวชภัณฑ์)
��
-ไม่ป้อนปีหมดอายุ (ประเภทใช้เวชภัณฑ์) ��
-ไม่ป้อนปีหมดอายุเป็นตัวเลข (ประเภทใช้
เวชภัณฑ์)
��
-ป้อนปีหมดอายุต่ำกว่า 2000 (ประเภทใช้
เวชภัณฑ์)
��
ปรับปรุงปริมาณยา / เวชภัณฑ์ / Lab เข้า
คลัง
-ป้อนข้อมูลถูกต้อง ��
-ไม่ป้อนปริมาณที่รับเข้า ��
-ไม่ป้อนปริมาณเป็นตัวเลข ��
-ป้อนปริมาณต่ำกว่า 0 ��
-ไม่ป้อนราคาต้นทุน / หน่วยเป็นตัวเลข ��
-ไม่ป้อนราคาขาย / หน่วยเป็นตัวเลข ��
-ไม่ป้อนวันที่ ��
-ไม่ป้อนวันที่เป็นตัวเลข ��
-ป้อนวันที่น้อยกว่า 1 หรือมากกว่า 31 ��
-ไม่ป้อนเดือน ��
-ไม่ป้อนเดือนเป็นตัวเลข ��
-ป้อนเดือนต่ำกว่า 1 หรือมากกว่า 12 ��
-ไม่ป้อนปี ��
-ไม่ป้อนปีเป็นตัวเลข ��
-ป้อนปีต่ำกว่า 2000 ��
48
จากการทดสอบทำให้ทราบว่าเมื่อป้อนข้อมูลที่ถูกต้องระบบจึงจะทำงานตามที่ผู้ใช้ต้องการ
แต่ถ้าหากมีการป้อนค่าของข้อมูลที่ผิดพลาดระบบจะมีการเตือนผู้ใช้และไม่ทำงานตามที่ถูกสั่ง
จนกว่าจะป้อนค่าของข้อมูลที่ถูกต้องสอดคล้องกับที่ระบบกำหนดไว้
4.2 หลังจากที่ได้นำระบบนี้ไปทดสอบตามวิธีการแบบ Black Box เรียบร้อยแล้ว
ต่อไปก็จะเป็นการนำระบบงานนี้ไปประเมินเพื่อหาประสิทธิภาพของระบบ และเป็นการทดสอบ
เพื่อยอมรับระบบโดยผู้ใช้ (Acceptance Test by Users) ซึ่งกระบวนการประเมิน
ระบบนี้ เป็นการประเมินเพื่อหาประสิทธิภาพของโครงงานระบบสารสนเทศโรงพยาบาล:ส่วน
ของคลังยาและห้องจ่ายยาที่ได้พัฒนาขึ้น ซึ่งจะมีการแบ่งการประเมินระบบออกเป็น 4 ส่วน
ด้วยกันคือ
4.2.1 Function Requirement Test
4.2.2 Functional Test
4.2.3 Usability Test
4.2.4 Security Test
ในการประเมินแต่ละด้าน จะกำหนดเกณฑ์การให้คะแนนออกเป็น 2 ด้าน คือ เกณฑ์การ
ให้คะแนนเชิงคุณภาพ และเกณฑ์การให้คะแนนเชิงปริมาณ ซึ่งในเกณฑ์การให้คะแนนเชิงคุณภาพ
และเชิงปริมาณนั้นจะแบ่งออกเป็น 5 ระดับด้วยกัน คือ
ตารางที่ 4-3 เกณฑ์การให้คะแนนของแบบประเมิน
ระดับเกณฑ์การให้คะแนน
เชิงคุณภาพ เชิงปริมาณ ความหมาย
ดีมาก 10 9 ระบบสามารถสนับสนุนและรองรับการทำงานเกี่ยวกับงาน
นั้น ๆ ได้อย่างมีประสิทธิภาพในระดับดีมาก
ดี 8 7 ระบบสามารถสนับสนุนและรองรับการทำงานเกี่ยวกับงาน
นั้น ๆ ได้อย่างมีประสิทธิภาพในระดับดี
ปานกลาง 6 5 ระบบสามารถสนับสนุนและรองรับการทำงานเกี่ยวกับงาน
นั้น ๆ ได้อย่างมีประสิทธิภาพในระดับปานกลาง
น้อย 4 3 ระบบสามารถสนับสนุนและรองรับการทำงานเกี่ยวกับงาน
นั้น ๆ ได้อย่างมีประสิทธิภาพในระดับน้อย
น้อยมาก 2 1 ระบบสามารถสนับสนุนและรองรับการทำงานเกี่ยวกับงาน
นั้น ๆ ได้อย่างมีประสิทธิภาพในระดับน้อยมาก
49
การประเมินระบบด้าน Functional Requirement Test
การประเมินระบบด้าน Functional Requirement Test เป็นการประเมินเพื่อดู
ว่าระบบที่ได้พัฒนานั้นมีความถูกต้องและมีประสิทธิภาพตามความต้องการของผู้ใช้มากน้อย
เพียงใด ซึ่งในการประเมินระบบนี้ ผู้วิจัยได้ออกแบบการประเมินโดยแบ่งหัวข้อที่จะใช้ในการ
ประเมินระบบออกเป็น 7 หัวข้อ ซึ่งผลการประเมินระบบด้าน Functional
Requirement Test ปรากฏดังตารางที่ 4-4 และ 4-5
ตารางที่ 4-4 แสดงผลการประเมินประสิทธิภาพของระบบด้าน Functional
Requirement Test
(สำหรับผู้บริหาร)
หัวข้อการประเมิน คะแนน
เฉลี่ย
(X)
ส่วนเบี่ยงเบน
มาตรฐาน
(SD)
ค่า t ระดับ
ประสิทธิภาพ
1. ความสามารถในการค้นหาข้อมูล
สะดวก รวดเร็วขึ้น
8.2 0.84 - ดี
2. ความสามารถในการช่วยลดความ
ล่าช้าและลดความผิดพลาดได้ดี
8.6 0.55 - ดี
3. ความสามารถในการลดภาระใน
การทำงานของผู้ใช้
8.6 1.14 - ดี
4. ความสามารถในการรายงานผล
การดำเนินงานได้อย่างรวดเร็ว
8.4 0.55 - ดี
5. การรายงานผลตรงกับความ
ต้องการของผู้ใช้โปรแกรม
8.2 0.45 - ดี
6. ความสามารถในการลดความ
เสียหายต่อข้อมูล
8 0.71 - ดี
7. ความพึงพอใจกับโปรแกรมที่
นำไปใช้
8.2 0.84 - ดี
รวม 8.31 0.23 12.98 ดี
50
ตารางที่ 4-5 แสดงผลการประเมินประสิทธิภาพของระบบด้าน Functional
Requirement Test
(สำหรับผู้ปฏิบัติหน้าที่)
หัวข้อการประเมิน คะแนน
เฉลี่ย
(X)
ส่วนเบี่ยงเบน
มาตรฐาน
(SD))
ค่า t ระดับ
ประสิทธิภาพ
1. ความสามารถในการค้นหาข้อมูล
สะดวก รวดเร็วขึ้น
8.0 0.71 - ดี
2. ความสามารถในการช่วยลดความ
ล่าช้าและลดความผิดพลาดได้ดี
8.2 0.45 - ดี
3. ความสามารถในการลดภาระใน
การทำงานของผู้ใช้
8.2 0.84 - ดี
4. ความสามารถในการรายงานผล
การดำเนินงานได้อย่างรวดเร็ว
8.6 0.55 - ดี
5. การรายงานผลตรงกับความ
ต้องการของผู้ใช้โปรแกรม
8.4 1.14 - ดี
6. ความสามารถในการลดความ
เสียหายต่อข้อมูล
8.4 0.89 - ดี
7. ความพึงพอใจกับโปรแกรมที่
นำไปใช้
8.6 0.89 - ดี
รวม 8.34 0.22 13.52 ดี
จากแบบประเมินข้อที่ 1-7 (ภาคผนวก ข)
จากตารางที่ 4-4 และตารางที่ 4-5 เมื่อพิจารณาถึงระดับการประเมินหาประสิทธิภาพ
โดยผู้เชี่ยวชาญ เกี่ยวกับระบบสารสนเทศโรงพยาบาล:ส่วนของคลังยาและห้องจ่ายยาในด้าน
Functional Requirement Test สำหรับผู้บริหารพบว่ามีคะแนนเฉลี่ยเท่ากับ 8.31
ซึ่งอยู่ในเกณฑ์การประเมินประสิทธิภาพระดับดีและสำหรับผู้ปฏิบัติหน้าที่มีคะแนนเฉลี่ยเท่ากับ
8.34 ซึ่งอยู่ในเกณฑ์การประเมินประสิทธิภาพระดับดีเช่นเดียวกันโดยเมื่อพิสูจน์โดยวิธีการหาค่า
t-test ที่ระดับนัยสำคัญ .05
51
การประเมินระบบด้าน Functional Test
การประเมินระบบด้าน Functional Test เป็นการประเมินเพื่อดูว่าระบบที่ได้พัฒนา
มานั้นมีความถูกต้องและมีประสิทธิภาพสามารถทำงานได้ตามหน้าที่ (Function) ที่มีอยู่ใน
ระบบมากน้อยเพียงใด ซึ่งในการประเมินระบบนี้ผู้วิจัยได้ออกแบบการประเมินโดยแบ่งหัวข้อที่จะ
ใช้ในการประเมินระบบออกเป็น 9 หัวข้อ ซึ่งผลการประเมินระบบด้าน Functional Test
ปรากฏดังตารางที่
4-6 และตารางที่ 4-7
ตารางที่ 4-6 แสดงผลการประเมินประสิทธิภาพของระบบด้าน Functional Test
(สำหรับผู้บริหาร)
หัวข้อการประเมิน คะแนน
เฉลี่ย
(X)
ส่วนเบี่ยงเบน
มาตรฐาน
(SD)
ค่า t ระดับ
ประสิทธิภาพ
1. ความถูกต้องของการจัดเก็บแต่ละ
ประเภท
8.2 0.84 - ดี
2. ความถูกต้องของการปรับปรุง
แก้ไขข้อมูลแต่ละประเภท
8.8 0.45 - ดี
3. ความสามารถในการแจ้งเตือน
ข้อผิดพลาด
7.6 0.89 - ดี
4. ความถูกต้องในการสืบค้นข้อมูล 7.4 0.89 - ดี
5. ความสามารถในการประมวลผล
ข้อมูลได้ถูกต้อง
8 0.71 - ดี
6. ความสามารถในการรายงานผล
ด้านการเงินได้ถูกต้อง
8.4 0.55 - ดี
7. ความสามารถในการกำหนด
ขอบเขตของข้อมูลที่ป้อน
8.8 0.45 - ดี
8. ความสามารถในการตรวจสอบ
ความถูกต้องของข้อมูลที่ป้อน
8 0.71 - ดี
9. ความสมบูรณ์ของข้อมูลในระบบ 8 1.00 - ดี
รวม 8.13 0.48 5.29 ดี
52
ตารางที่ 4-7 แสดงผลการประเมินประสิทธิภาพของระบบด้าน Functional Test
(สำหรับผู้ปฏิบัติหน้าที่)
หัวข้อการประเมิน คะแนน
เฉลี่ย
(X)
ส่วนเบี่ยงเบน
มาตรฐาน
(SD)
ค่า t ระดับ
ประสิทธิภาพ
1. ความถูกต้องของการจัดเก็บแต่ละ
ประเภท
7.8 0.45 - ดี
ตารางที่ 4-7 แสดงผลการประเมินประสิทธิภาพของระบบด้าน Functional Test
(สำหรับผู้ปฏิบัติหน้าที่) (ต่อ)
หัวข้อการประเมิน คะแนน
เฉลี่ย
(X)
ส่วนเบี่ยงเบน
มาตรฐาน
(SD)
ค่า t ระดับ
ประสิทธิภาพ
2. ความถูกต้องของการปรับปรุง
แก้ไขข้อมูลแต่ละประเภท
8.0 0.71 - ดี
3. ความสามารถในการแจ้งเตือน
ข้อผิดพลาด
7.4 0.55 - ดี
4. ความถูกต้องในการสืบค้นข้อมูล 8.2 0.45 - ดี
5. ความสามารถในการประมวลผล
ข้อมูลได้ถูกต้อง
8 1.00 - ดี
6. ความสามารถในการรายงานผล
ด้านการเงินได้ถูกต้อง
8.4 0.55 - ดี
7. ความสามารถในการกำหนด
ขอบเขตของข้อมูลที่ป้อน
8.8 0.84 - ดี
8. ความสามารถในการตรวจสอบ
ความถูกต้องของข้อมูลที่ป้อน
8 0.71 - ดี
9. ความสมบูรณ์ของข้อมูลในระบบ 7.8 0.84 - ดี
รวม 8.04 0.40 5.89 ดี
จากแบบประเมินข้อที่ 8-19 (ภาคผนวก ข)
จากตารางที่ 4-6 และตารางที่ 4-7 เมื่อพิจารณาถึงระดับการประเมินหาประสิทธิภาพ
โดยผู้เชี่ยวชาญเกี่ยวกับระบบสารสนเทศโรงพยาบาล:ส่วนของคลังยาและห้องจ่ายยาในด้าน
53
Functional Test สำหรับผู้บริหารพบว่ามีคะแนนเฉลี่ยเท่ากับ 8.13 ซึ่งอยู่ในเกณฑ์การ
ประเมินประสิทธิภาพระดับดีและสำหรับผู้ปฏิบัติหน้าที่มีคะแนนเฉลี่ยเท่ากับ 8.04 ซึ่งอยู่ใน
เกณฑ์การประเมินประสิทธิภาพระดับดีเช่นกันโดยเมื่อพิสูจน์โดยวิธีการหาค่า t-test ที่ระดับ
นัยสำคัญ .05
การประเมินระบบด้าน Usability Test
การประเมินระบบด้าน Usability Test เป็นการประเมินเพื่อดูว่าระบบที่ได้พัฒนามา
นั้นมีความสามารถในการใช้งานเป็นอย่างไร เช่น ความง่ายต่อการใช้งานมากน้อยเพียงใด มี
ความเร็วในการประมวลผลเป็นอย่างไร ซึ่งในการประเมินระบบนี้ ผู้วิจัยได้ออกแบบการประเมิน
โดยแบ่ง หัวข้อที่จะใช้ในการประเมินระบบออกเป็น 7 หัวข้อ ซึ่งผลการประเมินระบบด้าน
Usability Test ปรากฏดังตารางที่ 4-8 และตารางที่ 4-9
ตารางที่ 4-8 แสดงผลการประเมินประสิทธิภาพของระบบด้าน Usability Test (สำหรับ
ผู้บริหาร)
หัวข้อการประเมิน คะแนน
เฉลี่ย
(X)
ส่วนเบี่ยงเบน
มาตรฐาน
(SD)
ค่า t ระดับ
ประสิทธิภาพ
1. ขั้นตอนในการทำงานของ
โปรแกรมง่ายต่อการใช้งาน
7.2 0.84 - ดี
2. แบบฟอร์มในการป้อนข้อมูลมี
ความเข้าใจง่ายต่อการป้อน ข้อมูล
ของผู้ใช้
7.6 0.55 - ดี
3. ความสมดุลของสีของตัวอักษร
และองค์ประกอบของหน้าจอ
8.4 1.34 - ดี
4. ความง่ายในการเรียนรู้การใช้งาน
ด้วยตัวเอง
7.6 0.55 - ดี
5. การเพิ่มและแก้ไขข้อมูลทำได้ง่าย 8.4 0.89 - ดี
6. ความสะดวกรวดเร็วในการ
เลือกใช้เมนู
8.8 0.84 - ดี
7. ความง่ายในการเรียกใช้
โปรแกรม
8.8 0.45 - ดี
54
รวม 8.11 0.64 3.89 ดี
ตารางที่ 4-9 แสดงผลการประเมินประสิทธิภาพของระบบด้าน Usability Test
(สำหรับผู้ปฏิบัติหน้าที่)
หัวข้อการประเมิน คะแนน
เฉลี่ย
(X)
ส่วนเบี่ยงเบน
มาตรฐาน
(SD)
ค่า t ระดับ
ประสิทธิภาพ
1. ขั้นตอนในการทำงานของ
โปรแกรมง่ายต่อการใช้งาน
7.4 0.55 - ดี
2. แบบฟอร์มในการป้อนข้อมูลมี
ความเข้าใจง่ายต่อการป้อน ข้อมูล
ของผู้ใช้
7.8 0.45 - ดี
3. ความสมดุลของสีของตัวอักษร
และองค์ประกอบของหน้าจอ
8.6 0.55 - ดี
ตารางที่ 4-9 แสดงผลการประเมินประสิทธิภาพของระบบด้าน Usability Test
(สำหรับผู้ปฏิบัติหน้าที่) (ต่อ)
หัวข้อการประเมิน คะแนน
เฉลี่ย
(X)
ส่วนเบี่ยงเบน
มาตรฐาน
(SD)
ค่า t ระดับ
ประสิทธิภาพ
4. ความง่ายในการเรียนรู้การใช้งาน
ด้วยตัวเอง
8.8 0.84 - ดี
5. การเพิ่มและแก้ไขข้อมูลทำได้ง่าย 8.4 0.45 - ดี
6. ความสะดวกรวดเร็วในการ
เลือกใช้เมนู
8.4 0.55 - ดี
7. ความง่ายในการเรียกใช้
โปรแกรม
8.8 0.45 - ดี
รวม 8.31 0.53 5.58 ดี
จากแบบประเมินข้อที่ 17-23 (ภาคผนวก ข)
จากตารางที่ 4-8 และตารางที่ 4-9 เมื่อพิจารณาถึงระดับการประเมินประสิทธิภาพ โดย
ผู้เชี่ยวชาญเกี่ยวกับระบบสารสนเทศโรงพยาบาล:ส่วนของคลังยาและห้องจ่ายยาในด้าน
Usability Test สำหรับผู้บริหารพบว่ามีคะแนนเฉลี่ยเท่ากับ 8.11 ซึ่งอยู่ในเกณฑ์การ
55
ประเมินประสิทธิภาพระดับดีและสำหรับผู้ปฏิบัติหน้าที่พบว่ามีคะแนนเฉลี่ยเท่ากับ 8.31 ซึ่งอยู่
ในเกณฑ์การประเมิน ประสิทธิภาพระดับดีเช่นกันเมื่อพิสูจน์โดยวิธีการหาค่า t-test ที่ระดับ
นัยสำคัญ .05
การประเมินระบบด้าน Security Test
การประเมินระบบด้าน Security Test เป็นการประเมินเพื่อดูว่าระบบที่ได้พัฒนามา
นั้นมีการตรวจสอบการเข้าใช้ข้อมูลในระบบของผู้ใช้ และกำหนดระดับการทำงานได้อย่างถูกต้อง
ซึ่งในการประเมินระบบนี้ผู้วิจัยได้ออกแบบการประเมินโดยแบ่งหัวข้อที่จะใช้ในการประเมิน
ออกเป็น 2 หัวข้อ ซึ่งผลการประเมินระบบด้านSecurity Test ปรากฏดังตารางที่ 4-10
และตารางที่ 4-11
ตารางที่ 4-10 แสดงผลการประเมินประสิทธิภาพของระบบด้าน Security Test
(สำหรับผู้บริหาร)
หัวข้อการประเมิน คะแนน
เฉลี่ย
(X)
ส่วนเบี่ยงเบน
มาตรฐาน
(SD)
ค่า t ระดับ
ประสิทธิภาพ
1. ความสามารถในการจำกัดระดับ
การใช้งานของผู้ใช้
8.2 0.84 - ดี
ตารางที่ 4-10 แสดงผลการประเมินประสิทธิภาพของระบบด้าน Security Test
(สำหรับผู้บริหาร) (ต่อ)
หัวข้อการประเมิน คะแนน
เฉลี่ย
(X)
ส่วนเบี่ยงเบน
มาตรฐาน
(SD)
ค่า t ระดับ
ประสิทธิภาพ
2. ความสามารถในการตรวจสอบ
สิทธิในการเข้าใช้งานระบบ
8.4 0.89 - ดี
รวม 8.3 0.14 20.59 ดี
ตารางที่ 4-11 แสดงผลการประเมินประสิทธิภาพของระบบด้าน Security Test
(สำหรับผู้ปฏิบัติหน้าที่)
56
หัวข้อการประเมิน คะแนน
เฉลี่ย
(X)
ส่วนเบี่ยงเบน
มาตรฐาน
(SD)
ค่า t ระดับ
ประสิทธิภาพ
1. ความสามารถในการจำกัดระดับ
การใช้งานของผู้ใช้
7.8 0.45 - ดี
2. ความสามารถในการตรวจสอบ
สิทธิในการเข้าใช้งานระบบ
8.0 0.71 - ดี
รวม 7.9 0.14 14.26 ดี
จากแบบประเมินข้อที่ 24 – 25 (ภาคผนวก ข)
จากตารางที่ 4-10 และตารางที่ 4-11 เมื่อพิจารณาถึงระดับการประเมินหา
ประสิทธิภาพโดยผู้เชี่ยวชาญ เกี่ยวกับระบบสารสนเทศโรงพยาบาล:ส่วนของคลังยาและห้องจ่าย
ยาในด้าน Security Test สำหรับผู้บริหารพบว่ามีคะแนนเฉลี่ยเท่ากับ 8.3 ซึ่งอยู่ในเกณฑ์
การประเมินประสิทธิภาพระดับดี และสำหรับผู้ปฏิบัติหน้าที่พบว่ามีคะแนนเฉลี่ยเท่ากับ 7.9 ซึ่ง
อยู่ในเกณฑ์การประเมิน ประสิทธิภาพอยู่ในระดับดีเช่นเดียวกันเมื่อพิสูจน์โดยวิธีการหาค่า ttest
ที่ระดับนัยสำคัญ .05
บทที่ 3
การวิเคราะห์และออกแบบระบบ
วิธีการดำเนินงานของการพัฒนาระบบบริหารคลังยาและห้องจ่ายยานี้ ผู้วิจัยได้แบ่งวิธีการ
ดำเนินงานออกเป็น 6 ขั้นตอนด้วยกันคือ
3.1 การศึกษาระบบงานเดิม
3.2 การวิเคราะห์ระบบ
3.3 การออกแบบระบบ
3.4 ขั้นตอนการพัฒนาระบบ
3.5 การทดสอบระบบและเก็บรวบรวมข้อมูล
3.6 การวิเคราะห์ข้อมูลและสถิติในการวิเคราะห์ข้อมูล
3.1 การศึกษาระบบงานเดิม
การดำเนินงานที่เกี่ยวกับงานคลังยาและห้องจ่ายยาในปัจจุบัน สามารถแบ่งการทำงานใน
ส่วนต่าง ๆได้ดังนี้
3.1.1 การรับข้อมูลนำเข้าของยาและเวชภัณฑ์ที่มิใช่ยา จะต้องมีเจ้าหน้าที่ / พนักงานของ
ทาง
โรงพยาบาลที่เกี่ยวข้องในการจัดทำแฟ้มยาและเวชภัณฑ์เป็นผู้บันทึกรายละเอียดทุกครั้ง โดยจะ
บันทึกข้อมูลการนำเข้า และปรับปรุงข้อมูลเดิมในแฟ้มยาและเวชภัณฑ์ที่รับผิดชอบ
3.1.2 การเบิกยาและเวชภัณฑ์ที่มิใช่ยาออกจากคลังยา จะต้องมีการเก็บรายละเอียดทุกครั้ง
โดย
เจ้าหน้าที่ / พนักงานที่เกี่ยวข้อง โดยแบ่งการเบิกจ่ายออกเป็น การเบิกจ่ายให้กับคลังย่อยภายใน
โรงพยาบาล และการเบิกจ่ายให้กับหน่วยงานในกรณีที่มีการหยิบยืมหรือแลกเปลี่ยนยากัน ในกรณี
ที่เป็นการยืมหรือแลกเปลี่ยนยาเจ้าหน้าที่ / พนักงานจะต้องสำรวจรายการยาที่จะทำการยืมหรือ
แลกเปลี่ยนโดยตรวจดูปริมาณ วันหมดอายุ และข้อมูลจำเป็นอื่น ซึ่งจะกระทำได้ต่อเมื่อมีข้อมูลจาก
หน่วยงานสนับสนุนอื่นๆ ครบ
3.1.3 การสำรวจคลังยาและเวชภัณฑ์ที่มิใช่ยาต่าง ๆ จะต้องใช้เจ้าหน้าที่ /พนักงานที่มี
หน้าที่
รับผิดชอบในส่วนงานที่เกี่ยวข้องทั้งหมดกระทำร่วมกัน และส่งรายงานมายังส่วนกลางในการดูแล
ยาและเวชภัณฑ์ที่มิใช่ยาเพื่อประมวลผลรวมอีกครั้งเพื่อให้ได้ข้อมูลที่ใช้ช่วยในการวางแผนจัดซื้อ
หรือการใช้ยาและเวชภัณฑ์ให้สอดคล้องกับความเป็นจริง
22
3.2 วิเคราะห์ระบบงาน
ในการวิเคราะห์และออกแบบระบบงานใหม่ ได้มีการนำเอาเทคโนโลยีด้านคอมพิวเตอร์และ
ระบบเครือข่ายในสถาปัตยกรรมแบบ Client/Server เข้ามาประยุกต์ใช้กับระบบสารสนเทศ
โรงพยาบาลส่วนของคลังยาและห้องจ่ายยา ซึ่งในระบบงานเดิมจะประมวลผลขั้นตอน
(Process) ต่าง ๆ ของระบบงานโดยพนักงาน / เจ้าหน้าที่ของทางโรงพยาบาล แต่ระบบงาน
ใหม่ที่จัดทำขึ้นจะประมวลผลด้วยคอมพิวเตอร์โดยพนักงาน / เจ้าหน้าที่เป็นเพียงผู้สั่งงานเท่านั้น
โดยจะมีการทำงานดังนี้
3.2.1 การรับข้อมูลนำเข้าของยาและเวชภัณฑ์ที่มิใช่ยา จะมีการบันทึกผ่านทางหน้าจอ
คอมพิวเตอร์โดยพนักงาน / เจ้าหน้าที่ผู้มีหน้าที่รับผิดชอบ ทั้งการรับยาและเวชภัณฑ์ที่มิใช่ยาจาก
บริษัทผู้ขายหรือจากหน่วยงานอื่น ซึ่งระบบจะบันทึกรายละเอียดการรับเข้าของยาและเวชภัณฑ์ที่
มิใช่ยาโดยละเอียดและปรับปรุงแฟ้มยาและเวชภัณฑ์ที่มิใช่ยานี้ให้โดยอัตโนมัติ
3.2.2 การเบิกยาและเวชภัณฑ์ที่มิใช่ยาออกจากคลังยาและมีการบันทึกรายละเอียดในการเบิก
ผ่านทางหน้าจอคอมพิวเตอร์ ซึ่งจะเป็นการบันทึกตามประเภทว่าเป็นการเบิกเพื่อจ่ายห้องยาภายใน
โรงพยาบาลหรือการเบิกเพื่อจ่ายให้แก่หน่วยงานอื่นที่ร้องขอ รวมทั้งการเบิกจ่ายยาและเวชภัณฑ์ที่
มิใช่ยาของห้องจ่ายยาเพื่อจ่ายให้แก่ผู้ป่วยตามใบสั่งแพทย์เป็นต้น ซึ่งการบันทึกรายละเอียดเหล่านี้
ระบบจะทำการปรับปรุงแฟ้มยาและเวชภัณฑ์ที่มิใช่ยา
3.2.3 การสำรวจคลังยา (Stock) สามารถเรียกดูปริมาณยาและเวชภัณฑ์ที่มิใช่ยาได้ผ่าน
ทาง
หน้าจอคอมพิวเตอร์โดยสามารถให้รายละเอียดได้ถึงปริมาณที่มีอยู่ วันหมดอายุของยาและ
เวชภัณฑ์แต่ละรายการ รวมถึงข้อมูลต่าง ๆ ที่ใช้ช่วยในการวางแผนจัดซื้อยาและเวชภัณฑ์อื่นๆ
เพิ่มเติมได้
ระบบสารสนเทศโรงพยาบาลส่วนของคลังยาและห้องจ่ายยานี้ได้ใช้ Data Flow
Diagram (DFD) เป็นเครื่องมือในการวิเคราะห์ระบบ โดยแสดงการไหลของข้อมูลและ
ความสัมพันธ์ของ ข้อมูลที่ได้จากการวิเคราะห์ระบบ ดังต่อไปนี้
3.2.4 Context Diagram ซึ่งเป็น Data Flow ระดับบนสุดซึ่งแสดงให้เห็น
ภาพรวมของข้อมูล
เข้าและผลลัพธ์ของระบบ ดังแสดงในภาพที่ 3-1 โดยแสดงให้เห็นถึงความสัมพันธ์ของเอนทิตี้
(Entity) หลักจำนวนทั้งสิ้น 6 เอนทิตี้ (Entity) คือ ผู้จำหน่ายเวชภัณฑ์ แพทย์ หน่วยงาน
อื่นๆ ที่เกี่ยวข้องซึ่งในที่นี้หมายรวมถึง โรงพยาบาล สถานีอนามัยในเขตการรับผิดชอบดูแลของ
โรงพยาบาลหลัก คลังเวชภัณฑ์ คลังย่อย และห้องจ่ายยาที่มีกับระบบ
23
3.2.5 Data Flow Diagram 0 เพื่อแสดงการไหลของข้อมูลของระบบโดยรวม
และขั้นตอน
การทำงานโดยรวม ดังแสดงในภาพที่ 3-2 ซึ่งจะอธิบายเพิ่มเติมในส่วนของติดต่อแลกเปลี่ยน
ข้อมูลของแต่ละเอนทิตี้ (Entity) กับระบบสารสนเทศโรงพยาบาลส่วนของคลังยาและห้องจ่าย
ยาจาก Context Diagram โดยจะเห็นได้ว่าระบบจะเริ่มมีการทำงานตั้งแต่การลงรับ
เวชภัณฑ์จากใบนำส่งเวชภัณฑ์ของผู้จำหน่ายเวชภัณฑ์ จากนั้นจึงทำการรับเวชภัณฑ์เข้าคลัง
เวชภัณฑ์ซึ่งเป็นคลังใหญ่ของโรงพยาบาล โดยในขั้นตอนนี้จะรวมถึงการรับเวชภัณฑ์ที่ได้จาก
รายการจ่ายคืนจากหน่วยงานอื่นๆที่เกี่ยวข้องด้วย หลังจากนั้นจะการจัดทำ Stock Card ของ
เวชภัณฑ์ที่รับเข้ามาแล้วสรุปรายการเวชภัณฑ์ที่มีส่งให้กับแพทย์เพื่อใช้เป็นข้อมูลสนับสนุนในการ
สั่งจ่ายเวชภัณฑ์แต่ละชนิด ขั้นตอนต่อมาคือการจ่ายเวชภัณฑ์ซึ่งแบ่งออกเป็นการจ่ายเวชภัณฑ์ตาม
ข้อมูลการสั่งจ่ายเวชภัณฑ์ที่ได้จากแพทย์ในกรณีที่มีการตรวจรักษาผู้ป่วยนอก การจ่ายเวชภัณฑ์
ให้กับคลังย่อยภายในโรงพยาบาล เช่น หอผู้ป่วยใน เป็นต้น นอกจากนี้ยังรวมถึงการจ่ายเวชภัณฑ์
ให้กับหน่วยงานอื่นๆ ซึ่งอาจอยู่ในรูปของการแลกเปลี่ยนเวชภัณฑ์หรือการยืม-คืนเวชภัณฑ์ระหว่าง
หน่วยงาน และจะทำการปรับยอดเวชภัณฑ์ในคลังเวชภัณฑ์ โดยในขั้นตอนการทำงานสุดท้ายของ
ระบบคือการตัดยอดเวชภัณฑ์ประจำปีงบประมาณเพื่อจัดเตรียมแผนการสั่งซื้อเวชภัณฑ์จากผู้
จำหน่ายเวชภัณฑ์หรือการจัดซื้อเวชภัณฑ์ร่วมกับหน่วยงานอื่น ๆ
3.2.6 Data Flow Diagram Level 1 เพื่อแสดงความสัมพันธ์ของข้อมูลโดย
ละเอียดในแต่
ละขั้นของการทำงานของระบบ โดยมีด้วยกัน 6 ขั้นตอน เริ่มตั้งแต่ขั้นตอนการลงรายการรับ
เวชภัณฑ์ แสดงดังภาพที่ 3-3 ขั้นตอนการรับเวชภัณฑ์เข้าคลังเวชภัณฑ์แสดงดังภาพที่ 3-4
ขั้นตอนในการจัดทำ Stock Card แสดงดังภาพที่ 3-5 ขั้นตอนการจ่ายเวชภัณฑ์แสดงดังภาพ
ที่ 3-6 ขั้นตอนการปรับยอดเวชภัณฑ์แสดงดังภาพที่ 3-7 และขั้นตอนในการตัดยอดเวชภัณฑ์
ประจำปีงบประมาณแสดงดังภาพที่ 3-8
3.2.7 E-R Diagram เพื่อแสดงความสัมพันธ์ของข้อมูลโดยรวมภายในระบบ ดัง
แสดง
ในภาพที่ 3-9
24
25
26
27
28
29
30
31
การออกแบบฐานข้อมูลของระบบ
ในส่วนของการออกแบบฐานข้อมูลของระบบจะใช้ E-R Diagram มาช่วยในการ
นำเสนอโครงสร้างของฐานข้อมูลและความสัมพันธ์ระหว่างเอนทิตี้ในระบบดังแสดงในภาพที่ 3-
9 หลังจากนั้นจึงแปลง E-R Diagram เป็นตารางเก็บข้อมูล ดังตารางที่ 3-1
ตารางที่ 3-1 ชื่อย่อเวชภัณฑ์ drugalias
Field Type Key Description
Icode Varchar(7) PK รหัสยา
Aliasname Varchar(50) ชื่อสามัญยา
ตารางที่ 3-2 ประเภทเงินงบประมาณ drugbdgtype
32
Field Type Key Description
Bdgtype char(1) PK รหัสประเภทเงิน
Name varchar(150) ชื่อของประเภทเงิน
ตารางที่ 3-3 บริษัทผู้จำหน่าย drugcom
Field Type Key Description
Icode char(7) PK รหัสยา
Phmdlr char(3) บริษัทผู้จำหน่าย
Price double(22,3) ราคา
ตารางที่ 3-4 รายการรับเวชภัณฑ์เข้าคลังย่อย drugdepartment
Field Type Key Description
Contact varchar(250) ชื่อผู้ติดต่อ
Phmdlr char(3) PK บริษัทผู้จำหน่าย
Phmname varchar(250) ชื่อบริษัทผู้ผลิต
Phmtype char(1) ประเภทของยา
Recpcode varchar(4) รหัสใบรับของ
Genericname varchar(100) ชื่อทางวิทยาศาสตร์
ตารางที่ 3-5 ข้อมูลเวชภัณฑ์(ฉลาก) druggpo
Field Type Key Description
Hasproduct Smallint(6) รหัสการผลิต
Icode Varchar(7) PK รหัสยา
Itemnote Text คำบรรยาย
Price Double(22,3) ราคา
ตารางที่ 3-6 คำอธิบายเสริม drughint
Field Type Key Description
Hc Char(2) PK รหัสบรรยาย
Hinttext Varchar(150) คำบรรยายสรรพคุณยา
33
ตารางที่ 3-7 รายละเอียดเวชภัณฑ์ drugitems
Field Type Key Description
Icode varchar(7) PK รหัสยา
Name varchar(100) PK ชื่อยา
Strength varchar(15) PK หน่วยนับความแรง
Units varchar(50) PK หน่วยนับย่อย
Unitprice double(22,3) ราคาต่อหน่วยย่อย
Dosageform varchar(100) รูปแบบการบรรจุ
Criticalpriori
ty
int(11) ลำดับความสำคัญ
Drugaccount char(1) ประเภทในบัญชียาหลัก
Drugcategor
y
varchar(150) PK กลุ่มของเวชภัณฑ์
Drugnote varchar(150) หมายเหตุค้นหา
Hintcode char(2) PK รหัสช่วยในการใช้ยา
Istatus char(1) สถานภาพของเวชภัณฑ์
Lastupdatest
dprice
datetime แก้ไขครั้งสุดท้าย
Lockprice char(1) ล็อคการแก้ไขราคา
Lockprint char(1) ล็อคการพิมพ์
Field Type Key Description
Maxlevel int(11) จำนวนสูงสุดในคลัง
Minlevel int(11) จำนวนต่ำสุดในคลัง
Maxunitperd
ose
int(11) จำนวนจ่ายสูงสุด/ครั้ง
Packqty int(11) จำนวนบรรจุต่อหน่วย
Reorderqty int(11) จำนวนสั่งซื้อใหม่ในแต่ละครั้ง
Stdprice double(22,3) ราคากลาง
Stdtaken varchar(30) วิธีการใช้ปกติ
Therapeutic varchar(150) กลุ่มการออกฤทธิ์(ย่อย)
34
Therapeuticg
roup
varchar(150) กลุ่มการออกฤทธิ์(หลัก)
ตารางที่ 3-8 รายการเวชภัณฑ์ในโรงพยาบาล drugjoin
Field Type Key Description
Icode char(7) PK รหัสยา
Bdgyear Date PK รหัสประเภทงบประมาณ
Startdate Date วันที่เริ่มใช้
Enddate Date วันยุติการใช้
Price double(22,3) ราคา
Phmdlr char(3) บริษัทตัวแทนจำหน่าย
ตารางที่ 3-9 รายการรับเวชภัณฑ์เข้าคลัง drugminp
Field Type Key Description
Minpno varchar(9) PK ลำดับของเลขเอกสาร
Invno varchar(100) PK เลขที่ใบส่งของ
Minptype char(2) ประเภทการรับเข้า
Bdgtype char(1) ประเภทของเงินที่จ่าย
Dscamt double(22,3) ส่วนลด
Inpdate datetime วันที่รับเข้า
Note varchar(100) หมายเหตุ
ตารางที่ 3-9 รายการรับเวชภัณฑ์ drugminp (ต่อ)
Field Type Key Description
Pono varchar(100) เลขเอกสารที่สั่งซื้อ
Phmdlr char(3) บริษัทตัวแทนจำหน่าย/จ่าย
Vatamt double(22,3) ภาษามูลค่าเพิ่ม
ตารางที่ 3-10 ประเภทการรับเวชภัณฑ์ drugminptype
Field Type Key Description
Minptype char(2) PK ประเภทการรับเข้า
Name varchar(100) PK ชื่อประเภทการรับเข้า
35
ตารางที่ 3-11 รายละเอียดการรับเวชภัณฑ์ drugminpdt
Field Type Key Description
Minpno varchar(9) PK รหัสเลขเอกสาร
Icode varchar(7) PK รหัสยา
Costrate double(22,3) ราคารับเข้า
Expdate Datetime วันหมดอายุ
Inpqty int(11) จำนวนรับเข้า
Lotno varchar(50) เลขที่ล็อตที่รับเข้า
Packqty int(11) จำนวน/ภาชนะบรรจุ
Vatamt double(22,3) ภาษีมูลค่าเพิ่ม
ตารางที่ 3-12 แผนการจัดซื้อ drugorderplan
Field Type Key Description
Icode char(7) PK รหัสยา
period1 int(11) ระยะแรก
period2 int(11) ระยะที่สอง
period3 int(11) ระยะที่สาม
period4 int(11) ระยะที่สี่
Planyear datetime ปีงบประมาณ
ตารางที่ 3-13 รายการจ่ายเวชภัณฑ์ drugpaylist
Field Type Key Description
Payref varchar(6) PK รหัสเลขที่การจ่าย
Expiredate datetime วันหมดอายุของรายการจ่าย
Icode varchar(7) PK รหัสยา
Lotno varchar(15) PK รหัสล็อตรายการที่จ่าย
Minpno varchar(9) รหัสเลขเอกสารของรายการจ่าย
Qty int(11) จำนวนจ่าย
Unitprice double(22,3) ราคาต้นทุนที่จ่าย
36
ตารางที่ 3-14 ข้อมูลอ้างอิงรายการจ่ายเวชภัณฑ์ drugpayref
Field Type Key Description
Payref varchar(6) PK หน่วยงานที่รับ
Paydate datetime PK วันที่จ่าย
Guarantor varchar(35) ผู้รับรองการจ่ายยา
Linkref varchar(100) การติดต่อผู้รับจากการจ่าย
Payamount double(22,3) จำนวนที่จ่าย
Ptype char(2) PK ประเภทการจ่าย
Recpcode varchar(4) รหัสรับของรายการจ่าย
ตารางที่ 3-15 ผู้จ่ายเวชภัณฑ์drugphmtype
Field Type Key Description
Phmtype char(1) PK ประเภทผู้จ่าย
Name varchar(250) ชื่อผู้จ่าย
ตารางที่ 3-16 ประเภทการจ่ายเวชภัณฑ์ drugptype
Field Type Key Description
Ptype char(2) PK ประเภทการจ่าย
ตารางที่ 3-16 ประเภทการจ่ายเวชภัณฑ์ drugtype (ต่อ)
Field Type Key Description
Ptypename varchar(75) ชื่อประเภทการจ่าย
ตารางที่ 3-17 รับเวชภัณฑ์ drugrecipient
Field Type Key Description
Recpcode varchar(4) PK เลขที่รับ
Recipient varchar(45) ผู้รับ
Recptype char(1) รหัสประเภทการรับ
ตารางที่ 3-18 ประเภทการรับเวชภัณฑ์ drugrtype
Field Type Key Description
Rcode char(1) PK รหัสการรับ
37
Rtype varchar(100) ประเภทการรับ
ตารางที่ 3-19 ชื่อมาตรฐานของเวชภัณฑ์ drugstdgeneric
Field Type Key Description
Genericname varchar(150) ชื่อทางวิทยาศาสตร์
Genericgroup varchar(150) PK กลุ่มของชื่อยา
ตารางที่ 3-20 คลังเวชภัณฑ์ drugstock
Field Type Key Description
Icode Varchar(7) PK รหัสยา
Lotno Varchar(50) PK รหัสล็อตของยา
Minpno Varchar(9) PK รหัสเอกสาร
Costrate Double(22,3) ราคารับเข้า
Expiredate Datetime วันที่หมดอายุ
Leftqty int(11) จำนวนที่ใช้ไป
Payqty int(11) จำนวนที่จ่าย
ตารางที่ 3-20 คลังเวชภัณฑ์ drugstock (ต่อ)
Field Type Key Description
Quantity int(11) ปริมาณรวม
Receivedate Datetime วันที่รับเข้า
ตารางที่ 3-21 แผนการสั่งเวชภัณฑ์เข้าคลัง drugstockproposeorder
Field Type Key Description
Podate Date PK วันที่คาดการจะสั่ง
Icode char(7) PK รหัสยา
Dflag char(1) สถานะยา
Islock Smallint(6) PK รหัสคลัง
Orderqty int(11) ปริมาณการสั่ง
Unitprice Double(22,3) ราคาต่อหน่วย
ตารางที่ 3-22 ตัวแทนจำหน่ายเวชภัณฑ์ drugsupport
38
Field Type Key Description
Icode varchar(7) PK รหัสยา
Drugnote Text หมายเหตุ
Phmdlr char(3) บริษัทตัวแทนจำหน่าย
ตารางที่ 3-23 รายการยืมเวชภัณฑ์ drugtempreorder
Field Type Key Description
Guarantor varchar(35) ผู้รับรอง
Icode varchar(7) PK รหัสยา
Linkref varchar(100) PK สถานที่ติดต่อผู้รับ
Paydate Datetime วันที่จ่าย
Payref varchar(6) ผู้จ่าย
Ptype char(2) ประเภทการจ่าย
Qty int(11) ปริมาณการจ่าย
ตารางที่ 3-23 รายการยืมเวชภัณฑ์ drugtempreorder
Field Type Key Description
Recpcode varchar(4) รหัสการรับของรายการจ่าย
ตารางที่ 3-24 หน่วยเวชภัณฑ์ drugunits
Field Type Key Description
Units varchar(50) ขนาดบรรจุต่อหน่วย
ตารางที่ 3-25 วิธีการใช้เวชภัณฑ์ drugusage
Field Type Key Description
Drugusage varchar(4) PK วิธีการใช้ยา
Code varchar(25) PK รหัสย่อวิธีการใช้
Name1 varchar(150) ชื่อสามัญ
Name2 varchar(150) ชื่อสามัญ2
name3 varchar(150) ชื่อสามัญ 3
Shortlist varchar(50) สรุปวิธีการใช้
39
Idrlink varchar(20) รหัสเชื่อมโยงโหมด 1
3.4 การพัฒนาระบบ
หลังจากวิเคราะห์และออกแบบระบบเรียบร้อยแล้ว จะเป็นขั้นตอนการพัฒนาระบบ โดยใน
การจัดทำสารนิพนธ์ครั้งนี้ได้ใช้โปรแกรม Delphi 7.0 ร่วมกับโปรแกรมจัดการฐานข้อมูล MySQL
เป็นเครื่องมือในการพัฒนาระบบ เนื่องจากเป็นเครื่องมือที่ใช้งานได้ง่ายและสนับสนุน
ระบบปฏิบัติการได้หลากหลายรูปแบบ อีกทั้ง Delphi 7.0 มี Component ของ Delphi 7.0 ช่วยใน
การพัฒนามากมายหลายประเภทและสามารถหา Download ได้ จากนั้นจึงออกแบบส่วนประสาน
กับผู้ใช้ (User Interface Design) ซึ่งเกี่ยวข้องกับการออกแบบหน้าจอ (Screen) ฟอร์มต่าง ๆ (Form)
อันได้แก่ฟอร์มของการทำงานในการลงรายการรับเวชภัณฑ์ ฟอร์มของการทำงานในการรับ
เวชภัณฑ์เข้าคลัง ฟอร์มของการทำงานในการการทำ Stock Card ฟอร์มของการทำงานในการการ
ปรับยอด เวชภัณฑ์ และฟอร์มการทำงานในการในการตัดยอดเวชภัณฑ์ และรูปแบบของการ
รายงานผล (Report) โดยที่หน้าจอต่าง ๆ อธิบายได้ดังภาคผนวก ค
โดยเมื่อพัฒนาระบบจะกระทำควบคู่ไปกับการศึกษาการใช้งาน Delphi เพราะ Delphi มีการ
พัฒนาเพิ่มเติมอยู่เสมอและมี Component ใหม่ๆที่ง่ายต่อการนำมาเป็นเครื่องมือเสริมเพื่อพัฒนาให้
ระบบมีความสมบูรณ์อยู่เสมอ และในระหว่างที่พัฒนาระบบอยู่นั้นได้ทำการทดสอบและเก็บ
รวบรวมข้อมูลเพื่อนำมาใช้เป็นแนวทางในการปรับเปลี่ยนแก้ไขให้ระบบมีความสมบูรณ์มากยิ่งขึ้น
3.4.1 การทดสอบระบบและเก็บรวบรวมข้อมูล ในการทดสอบระบบที่พัฒนาขึ้นใช้วิธีการ
ทดสอบแบบแบล็กบอกซ์ (Black Box Testing) โดยแบ่งการทดสอบเป็น 2 ส่วน ดังต่อไปนี้
3.4.1.1 การทดสอบโดยการสมมุติข้อมูลขึ้น ซึ่งข้อมูลที่สมมุติเป็นข้อมูลหลายรูป
แบบโดยเฉพาะบางข้อมูลที่เป็นข้อมูลที่ทำให้เกิดความผิดพลาด เช่น การป้อนข้อมูลผิดประเภท
เพื่อตรวจสอบหาความผิดพลาดของระบบ
3.4.1.2 การทดสอบโดยผู้ใช้ระบบ เป็นการทดสอบโดยให้ผู้ที่มีทำงานและผู้ที่มี
ความเชี่ยวชาญในการทดสอบระบบทำการทดสอบ โดยให้ทดสอบในด้านต่าง ๆรวม 4 ด้านคือ
ก). Functional Requirement Test
ข). Functional Test
ค). Usability Test
ง). Security Test
3.5 การวิเคราะห์ข้อมูลและสถิติที่ใช้ในการวิเคราะห์ข้อมูล
40
จากข้อมูลที่ได้จากแบบประเมินผลประสิทธิภาพของระบบที่ได้จากผู้ทดสอบระบบ สามารถ
นำมาแปลงเป็นระดับประสิทธิภาพคือ
9.00-10 หมายถึง มีประสิทธิภาพอยู่ในระดับที่ผู้ใช้พึงพอใจดีมาก
7.00-8.99 หมายถึง มีประสิทธิภาพอยู่ในระดับที่ผู้ใช้พึงพอใจดี
5.00-6.99 หมายถึง มีประสิทธิภาพอยู่ในระดับที่ผู้ใช้พึงพอใจปานกลาง
3.00-4.99 หมายถึง มีประสิทธิภาพอยู่ในระดับที่ผู้ใช้พึงพอใจน้อย
1.00-2.99 หมายถึง มีประสิทธิภาพอยู่ในระดับที่ผู้ใช้พึงพอใจน้อยมาก
นำข้อมูลที่ได้มาวิเคราะห์ผลทางสถิติ โดยการหาค่าเฉลี่ย ส่วนเบี่ยงเบนมาตรฐานและค่า t
3.5.1 สถิติที่ใช้ในการวิเคราะห์
3.5.1.1 ค่าคะแนนเฉลี่ย ( X ) จากสูตร
X = ΣX
N
เมื่อ X = ค่าเฉลี่ยเลขคณิต
N = จำนวนผู้ทดสอบ
ΣX = ผลรวมของคะแนนทั้งหมด
3.5.2 ส่วนเบี่ยงเบนมาตรฐาน (SD)
SD = nΣd2 – (Σd)2
n(n-1)
เมื่อ SD = ส่วนเบี่ยงเบนมาตรฐานของผลต่าง
d = ผลต่างระหว่างข้อมูลแต่ตัวอย่าง
n = จำนวนตัวอย่าง
d = ค่าเฉลี่ยของผลต่าง
3.5.3 t-test
t = μ - x
SD
√ n
เมื่อ μ = ค่าเฉลี่ยของกลุ่มประชากร
x = ค่าเฉลี่ยเลขคณิต
SD = ส่วนเบี่ยงเบนมาตรฐานของผลต่าง
41
n = ประชากร
บทที่ 5
สรุปผลการจัดทำโครงงานและข้อเสนอแนะ
การพัฒนาระบบสารสนเทศโรงพยาบาล:ส่วนของคลังยาและห้องจ่ายยาครั้งนี้ มีจุดประสงค์
เพื่อช่วยอำนวยความสะดวกในการทำงานของเจ้าหน้าที่ในโรงพยาบาลโดยทั่วไป ทั้งในด้านการ
จัดเก็บ สืบค้น แก้ไข ลบข้อมูลต่างๆ โดยผู้วิจัยได้รับการประเมินประสิทธิภาพของระบบโดยผู้ที่
ทำงานในโรงพยาบาลต่าง ๆ ด้วยวิธีการสาธิตและทดลองใช้โปรแกรมและประเมินผลการทำงาน
ด้านต่าง ๆ จากแบบประเมินประสิทธิภาพที่จัดทำขึ้น เพื่อให้ทราบถึงประสิทธิภาพของระบบ และ
คำแนะนำในการพัฒนาระบบการสอบในครั้งนี้
5.1 สรุปผลการประเมินประสิทธิภาพของระบบ
เมื่อได้นำระบบที่ได้พัฒนานี้ไปทดสอบเพื่อประเมินประสิทธิภาพของระบบ สามารถ
สรุปผลการประเมินแต่ละด้านได้ดังนี้
สำหรับผู้บริหาร
5.1.1 ผลการประเมินด้าน Functional Requirement Test มีประสิทธิภาพอยู่
ในระดับดี
5.1.2 ผลการประเมินด้าน Functional Test มีประสิทธิภาพอยู่ในระดับดี
5.1.3 ผลการประเมินด้าน Usability Test มีประสิทธิภาพอยู่ในระดับดี
5.1.4 ผลการประเมินด้าน Security Test มีประสิทธิภาพอยู่ในระดับดี
สำหรับผู้ปฎิบัติหน้าที่
5.2.1 ผลการประเมินด้าน Functional Requirement Test มีประสิทธิภาพอยู่
ในระดับดี
5.2.2 ผลการประเมินด้าน Functional Test มีประสิทธิภาพอยู่ในระดับดี
5.2.3 ผลการประเมินด้าน Usability Test มีประสิทธิภาพอยู่ในระดับดี
5.2.4 ผลการประเมินด้าน Security Test มีประสิทธิภาพอยู่ในระดับดี
หลังจากที่ได้ทราบถึงผลการประเมินประสิทธิภาพของระบบในแต่ละด้านเรียบร้อยแล้วนำ
เอาผลการประเมินในแต่ละด้านมาผ่านระเบียบวิธีการทางสถิติ เพื่อหาค่าเฉลี่ย (Mean) อีกครั้ง
สำหรับผู้บริหารพบว่าได้ค่าเฉลี่ย 8.21 และสำหรับผู้ปฏิบัติหน้าที่พบว่าได้ค่าเฉลี่ยเท่ากับ
8.145สามารถสรุปผลการประเมินประสิทธิภาพโดยรวมของระบบได้ว่าระบบสารสนเทศ
โรงพยาบาลส่วนของคลังยาและห้องจ่ายยานี้มีประสิทธิภาพการทำงานอยู่ในระดับที่ผู้ใช้พึงพอใจดี
57
5.2 ข้อเสนอแนะโดยผู้เชี่ยวชาญ
จากการที่ได้นำระบบสารสนเทศโรงพยาบาล:ส่วนของคลังยาและห้องจ่ายยาไปให้
ผู้เชี่ยวชาญประเมินระบบแล้ว ผู้เชี่ยวชาญแต่ละท่านมีข้อเสนอแนะในส่วนต่าง ๆ ดังนี้
5.2.1 ระบบสารสนเทศโรงพยาบาล:ส่วนของคลังยาและห้องจ่ายยานี้เหมาะสมกับการ
ใช้งาน
ทั่วๆ ไป ไม่เหมาะกับการนำไปใช้กับโรงพยาบาลขนาดใหญ่ที่มีความซับซ้อนในการทำงานมาก
เนื่องจากขาดการตั้งค่ารายละเอียดที่จำเป็นต่อการใช้งาน
5.2.2 ผู้ใช้ต้องมีความรู้ในการใช้คอมพิวเตอร์พื้นฐานและเข้าใจการทำงานของระบบ เพราะ
ในบางขั้นตอนอาจจะมีความซับซ้อน
5 . 3 คำแนะนำจากผู้วิจัย
ระบบสารสนเทศโรงพยาบาล:ส่วนของคลังยาและห้องจ่ายยานี้ ผู้วิจัยมีข้อเสนอแนะเพื่อให้
การพัฒนามีความสมบูรณ์มากขึ้นและก่อให้เกิดประโยชน์สูงสุดในการพัฒนาครั้งต่อไป ผู้วิจัยมี
ข้อเสนอแนะดังนี้
5.3.1 ระบบนี้ยังมีการทำงานไม่ครบถ้วนในบางส่วน เช่น ระบบผู้ป่วยในไม่มีระบบ
ห้อง
ปฏิบัติการที่สมบูรณ์ ยังไม่มีระบบสั่งซื้อและระบบการเงินที่สมบูรณ์
5.3.2 การที่จะใช้ระบบสารสนเทศโรงพยาบาล:ส่วนของคลังยาและห้องจ่ายยาให้
สมบูรณ์
ต้องมีการพัฒนาระบบสารเทศโรงพยาบาลในส่วนต่างๆควบคู่กันไปด้วยเนื่องจากมีหลายโมดูล
การทำงานที่มีความสัมพันธ์เกี่ยวเนื่องกันในการนำ ข้อมูลมาใช้กับระบบ
5.3.3 การพัฒนาขั้นต่อไปควรคำนึงถึงเทคโนโลยีที่สามารถรองรับการเปลี่ยนแปลงได้
ใน
ระยะเวลาไม่ต่ำกว่า 5 ปี
5.3.4 ควรพัฒนาให้มีระบบเชื่อมโยงกับระบบฐานข้อมูลของสำนักหลักประกันสุขภาพ
แห่ง
ชาติเพื่ออำนวยความสะดวกในการทำงานต่อไปในอนาคต
