ขั้นตอนการซ่อม¶

โมดูล ขั้นตอนการซ่อม (roots_hemms_workflow) แทนที่ขั้นตอนงานซ่อมบำรุง สามขั้นเริ่มต้นของ Odoo (New / In Progress / Repaired) ด้วย ขั้นตอนการซ่อมของโรงพยาบาล 5 ขั้น ที่แผนก BME ของไทยใช้ — ชุดสถานะที่ ผู้ตรวจประเมินจะขอให้คุณอธิบายระหว่างการเยี่ยมประเมินเพื่อรับรอง HA

ทุกการเปลี่ยนผ่านถูกจับเวลาเทียบกับ SLA ต่อขั้น ทุกการเปลี่ยนผ่านถูกเขียนลง บันทึกการตรวจสอบที่แก้ไขไม่ได้ และการ์ดคัมบังทุกใบมีป้ายระดับความวิกฤตเพื่อให้ ผู้จัดการ BME คัดกรองได้ในพริบตา

ห้าขั้น¶

โมดูลเตรียมขั้นเหล่านี้เมื่อติดตั้ง (ป้ายสองภาษา — ชื่อภาษาไทยเป็นชื่อหลัก สำหรับเจ้าหน้าที่หอผู้ป่วย ป้ายภาษาอังกฤษสำหรับผู้ตรวจประเมินและผู้ดูแลระบบ):

หมายเลขลำดับเว้นห่างทีละ 10 เพื่อให้ผู้ดูแลระบบแทรกขั้นแบบกำหนดเองได้ภายหลัง โดยไม่ต้องเปลี่ยนหมายเลขใหม่ ขั้น Received เป็นขั้นเดียวที่มี fold=True และ done=True — Odoo ถือว่าเป็นคอลัมน์ปลายทาง ยุบไว้ในคัมบังโดยค่าเริ่มต้น

เครื่องสถานะ (state machine)¶

stateDiagram-v2
    direction LR
    [*] --> Submitted: Ward staff opens ticket
    [*] --> PM_Scheduled: roots_hemms_pm cron
    PM_Scheduled --> Pending_Review: BME tech acknowledges
    Submitted --> Pending_Review: BME manager picks up
    Pending_Review --> In_Repair: assignment + diagnosis
    In_Repair --> Awaiting_Pickup: repair complete
    Awaiting_Pickup --> Received: ward staff collects
    Received --> [*]

    Submitted: ส่งซ่อม\n(Submitted)\nSLA 4h
    Pending_Review: รอตรวจสอบ\n(Pending Review)\nSLA 8h
    In_Repair: กำลังซ่อม\n(In Repair)\nSLA 24h
    Awaiting_Pickup: ซ่อมเสร็จ - รอรับ\n(Awaiting Pickup)\nSLA 8h
    Received: รับงานแล้ว\n(Received)\nDone
    PM_Scheduled: PM Scheduled\n(roots_hemms_pm)\nSLA 72h

ขั้นตอนการทำงาน ไม่ได้ บังคับสถานะอย่างเข้มงวด — maintenance.stage ใช้ คัมบังที่เรียงตามลำดับมาตรฐานของ Odoo ดังนั้นผู้ใช้ใด ๆ ที่มีสิทธิ์แก้ไขสามารถ ลากการ์ดถอยหลังหรือข้ามคอลัมน์ได้ บันทึกการตรวจสอบจับทุกการเคลื่อนไหวไม่ว่าทิศทาง ใด ดังนั้นการเปลี่ยนผ่านถอยหลังจึงมองเห็นได้ทั้งโดยผู้จัดการและผู้ตรวจประเมิน

ทำไมจึงสำคัญ¶

การมองเห็นขั้นตอนการทำงานทางคลินิก¶

ขั้นตอนเริ่มต้นของ Odoo ไม่แยกแยะ "ช่างกำลังซ่อมอยู่" ออกจาก "ช่างซ่อมเสร็จ แล้วแต่ยังไม่มีใครจากหอผู้ป่วยมารับ" ในโรงพยาบาล สองสถานะนี้อยู่ในคิวที่ต่างกัน โดยสิ้นเชิง — อันหนึ่งเป็นปัญหาของ BME อีกอันเป็นปัญหาของหอผู้ป่วย การแยกพวกมัน ออกจากกันช่วยปลดล็อก KPI ของทีม BME

หลักฐานสำหรับผู้ตรวจประเมิน¶

ผู้ตรวจประเมิน HA และ ISO 15189 ถาม: "แสดงเครื่องช่วยหายใจที่เสีย 10 เครื่อง ล่าสุดให้ดู แต่ละเครื่องถูกแจ้งเมื่อไร แต่ละขั้นใช้เวลาเท่าไร ใครเป็นผู้ลงนาม?" บันทึกการตรวจสอบ (hemms.stage.transition.log) ตอบคำถามนั้นได้ด้วยการสืบค้น ครั้งเดียว

ความรับผิดชอบด้าน SLA¶

แต่ละขั้นมีระยะเวลาที่คาดหวังของตัวเอง เมื่อคำขออยู่ใน Pending Review เกิน 8 ชั่วโมง การ์ดคัมบังจะพลิกเป็นป้าย SLA สีแดงและฟอร์มจะแสดงแบนเนอร์ ธงนี้ ถูกคำนวณฝั่ง SQL (ดู _search_roots_is_sla_breached ใน models/maintenance_request.py) เพื่อให้ตัวกรองค้นหา SLA Breached ขยาย รองรับคำขอย้อนหลังนับหมื่นรายการได้โดยไม่หมดเวลา

คุณสมบัติหลัก¶

• 5 ขั้นที่เตรียมไว้ พร้อมชื่อสองภาษา TH+EN ชั่วโมง SLA ต่อขั้น และคำใบ้ "บทบาทผู้รับผิดชอบเริ่มต้น" (ward_staff, bme_manager, bme_technician, bme_manager_signoff)
• วิดเจ็ต "เวลาในขั้น" แบบสด บนฟอร์ม + รายการ + คัมบัง (รูปแบบ float_time)
• แบนเนอร์การเกินกำหนด SLA บนฟอร์ม การตกแต่งแถวสีแดง บนรายการ ป้าย SLA สีแดง บนการ์ดคัมบัง — ข้อมูลเดียวกัน สามการนำเสนอ
• ป้ายระดับความวิกฤตของเครื่องมือแพทย์ บนการ์ดทุกใบ (เขียว / เหลือง / แดง) — ดึงแบบ related จากเครื่องมือแพทย์ มีดัชนีเพื่อการกรองที่รวดเร็ว
• แท็บร่องรอยการตรวจสอบ บนฟอร์มคำขอ — รายการแบบอ่านอย่างเดียวของทุกการ เปลี่ยนผ่านขั้น พร้อมเวลา ผู้กระทำ ขั้นต้นทาง ขั้นปลายทาง และชั่วโมงที่ใช้ใน ขั้นก่อนหน้า
• บันทึกการตรวจสอบการเปลี่ยนผ่านขั้น ภายใต้ Maintenance → Configuration — หน้าจอสำหรับผู้จัดการเท่านั้นที่ค้นหาข้ามทุกคำขอ มีประโยชน์สำหรับหลักฐานต่อ ผู้ตรวจประเมิน
• ตัวกรองค้นหา workflow สามตัว: My Responsibility (ผู้รับผิดชอบปัจจุบัน = ฉัน), SLA Breached (ตัวจับเวลาที่ใช้งานอยู่เกินกำหนด), Critical Equipment (ระดับความวิกฤตสีแดง) พร้อมตัวเลือก "Group By" สามตัว: ตามขั้น ตามผู้รับผิดชอบปัจจุบัน และตามระดับความวิกฤตของเครื่องมือแพทย์
• ข้อความอัตโนมัติเมื่อเปลี่ยนขั้น — ทุกการเปลี่ยนผ่านบันทึกโน้ตลงใน chatter ของคำขอ (Stage changed: A → B) โดยใช้ mail.mt_note ดังนั้นร่องรอยการตรวจสอบจึงคงอยู่แม้ว่าโมเดลบันทึกจะถูกกรอง
• รายการตรวจสอบขั้นเริ่มต้น — ขั้นแรกที่คำขอเข้าสู่ (Submitted, PM Scheduled หรือขั้นที่ผู้ดูแลระบบกำหนดเอง) ถูกบันทึกเองด้วย from_stage_id ว่างเปล่า ดังนั้นร่องรอยจึงสมบูรณ์ตั้งแต่การสร้าง

Dependency ของโมดูล¶

ผู้ใช้งานปลายน้ำของโมดูลนี้:

• roots_hemms_pm — เพิ่มขั้นเริ่มต้น PM Scheduled + เครื่องยนต์แผน
• roots_hemms_spare_parts — เชื่อมโยงคำขอจัดเตรียมกับขั้นของคำขอซ่อมบำรุง
• roots_hemms_service_contracts — แบนเนอร์ความคุ้มครองอ่านบนคำขอเดียวกัน ตั้งค่า roots_is_billable_to_hospital

สัญญาอนุญาต: LGPL-3 ระดับความสมบูรณ์: Alpha (ส่งใน Q1 ปรับแกร่งใน การรัน CI ของ Q7)

ไปต่อที่ไหน¶

• เริ่มต้นใช้งาน — เปิดและเดินงานผ่านทั้งห้าขั้นใน 5 นาที
• การตั้งค่า — ปรับชั่วโมง SLA เพิ่มขั้นแบบกำหนดเอง ACL สำหรับบันทึกการตรวจสอบ
• ขั้นตอนการทำงาน — สถานการณ์เชิงแก้ไข สร้างจาก PM ค้างที่ รอตรวจสอบ ยกเลิก จัดการโดยผู้ขาย
• การรายงาน — คัมบัง รายการ ปฏิทิน pivot บันทึกการตรวจสอบ สำหรับหลักฐานต่อผู้ตรวจประเมิน

โมดูลที่เกี่ยวข้อง¶

• ระดับความวิกฤตของเครื่องมือแพทย์ — ขับเคลื่อน ป้ายสีแดง/เหลือง/เขียวบนการ์ดทุกใบ
• การบำรุงรักษาเชิงป้องกัน — ให้ขั้นเริ่มต้น PM Scheduled
• อะไหล่ — เมนูย่อย Stock Requests ใช้คัมบังคำขอร่วมกัน
• สัญญาบริการ — แบนเนอร์ความคุ้มครอง เหนือหัวข้อคำขอ