จัดการ Master Registry

/admin/master-registry คือศูนย์กลางของข้อมูลแคตตาล็อกร่วมระดับโรงพยาบาล โดยรวม SERVICE, PRODUCT และ MEDICINE ไว้ภายใต้เวิร์กโฟลว์ปฏิบัติการเดียว

ทำความเข้าใจโครงสร้างหน้าจอก่อน

ด้านบนสุดของหน้าจอ ผู้ใช้จะเลือกประเภทการทำงานปัจจุบันก่อน

• SERVICE
• PRODUCT
• MEDICINE

ด้านล่าง หน้าจอจะรวมการค้นหา การกรองตาม category การดูรายละเอียด การสร้าง / แก้ไข archive และ bulk upload เข้าด้วยกัน

เหตุใดหน้าจอนี้จึงสำคัญ

• เพื่อให้ treatment, POS, stock และ reporting ใช้รายการอ้างอิงชุดเดียวกัน
• เพื่อจัดการบริการและ items ที่ซ้ำกัน
• เพื่อรักษาความสม่ำเสมอของ category
• เพื่อควบคุมงาน bulk upload และ archive

สามประเภทการทำงาน

SERVICE

• บริการทางคลินิกและบริการปฏิบัติการที่คิดเงินได้แต่ไม่ผูกกับสต็อก

PRODUCT

• สินค้าทั่วไปที่เชื่อมกับสต็อก

MEDICINE

• รายการที่เน้นยา
• มีแนวโน้มเชื่อมกับ lot วันหมดอายุ และการจ่ายยา

Action หลัก

• search
• สลับประเภท
• กรองตาม category
• ดูรายละเอียด
• สร้าง / แก้ไข
• สลับ active / inactive
• ลบ
• bulk upload
• จัดการ category
• archive

แหล่งข้อมูลจะแตกต่างกันตามประเภท

• SERVICE: อิงข้อมูลบริการของสาขา
• PRODUCT / MEDICINE: อิงข้อมูล item ของสาขาและข้อมูลที่เชื่อมกับ stock

กฎของ Category

category คือโครงสร้างสำหรับการดำเนินงานและรายงาน ไม่ใช่เพียงป้ายชื่อ

แนวทางที่ดีของ category

• แยกบริการทางคลินิกออกจากรายการเภสัชกรรม
• แยก category แกนหลักของระบบออกจาก category ที่โรงพยาบาลสร้างเอง
• เคลียร์รายการที่ไม่ถูกจัดหมวดให้เร็ว

service categories อย่าง Hotel, Grooming หรือ Taxi อาจไม่มีประโยชน์ในการใช้งานจริงเมื่อสาขานั้นปิดฟีเจอร์ดังกล่าว ดังนั้นการออกแบบ category จึงผูกกับการเปิดใช้ facility ด้วย

สิ่งที่ควรหลีกเลี่ยง

• category หลายชื่อที่เกือบซ้ำกัน
• category ชั่วคราวที่กลายเป็น category จริงใน production
• การเอาบริการกับยาไปอยู่ในต้นไม้ category เดียวกัน

ใช้ Bulk Upload อย่างระมัดระวัง

bulk upload ทำงานเร็ว แต่สร้างภาระเรื่อง validation ตามมา

สถานการณ์ที่เหมาะ

• โหลด master data เริ่มต้นสำหรับโรงพยาบาลใหม่
• ย้ายข้อมูลจาก ERP เก่าหรือแคตตาล็อกใน spreadsheet

ตรวจสอบก่อนอัปโหลด

• ชื่อซ้ำ
• ความสม่ำเสมอของหน่วย
• การแมป category
• นโยบาย active / inactive
• นโยบายการซิงก์ระหว่างสาขา

Note: Bulk upload มีคุณค่ามากในการโหลดข้อมูลครั้งแรก แต่สภาพแวดล้อมที่มีรายการซ้ำจำนวนมากมักต้องจ่ายคืนด้วยงาน archive cleanup ภายหลัง

กลยุทธ์ Archive

Archive นำข้อมูลหลักที่เลิกใช้แล้วออกจากมุมมองการทำงานหลัก ขณะเดียวกันยังรักษาบริบทสำหรับการตีความประวัติไว้

ตัวเลือกที่เหมาะสำหรับ archive

• รายการที่ไม่ขายหรือไม่ใช้แล้ว
• รายการซ้ำที่ถูกรวมไว้ที่อื่นแล้ว
• ข้อมูลทดสอบ

Warning: การลบรายการที่ถูกใช้ไปแล้วในบิล ใบสั่งยา หรือ stock lots จะทำให้การตีความประวัติยากขึ้น หลายกรณีการปิดใช้งานหรือ archive ปลอดภัยกว่าการลบ

archive จะเปิดรายการ archived แยกตามประเภทที่เลือกอยู่ในขณะนั้น

ความสัมพันธ์กับ Stock และงานทางคลินิก

• services ไหลไปสู่ OPD Plan และ POS
• products และ medicines ไหลไปสู่ stock, pharmacy และการทบทวนที่เน้น inventory
• คุณภาพ category ที่อ่อน จะลดประโยชน์ของการตีความทางการเงินในระบบปลายทาง

เคล็ดลับการใช้งาน

• ค้นหาก่อนสร้าง item ใหม่เสมอ
• จำกัดการสร้าง shared master data ให้กับ admins
• กำหนดภายในให้ชัดว่า "inactive" ต่างจาก "archived" อย่างไร

เอกสารที่เกี่ยวข้อง