เทมเพลตข้อมูลการจัดการวงจรรายได้
เทมเพลตข้อมูลการจัดการวงจรรายได้
นี่คือเทมเพลตข้อมูล process mining ทั่วไปสำหรับ การจัดการวงจรรายได้ หากต้องการคำแนะนำเฉพาะเจาะจง โปรดใช้เทมเพลตสำหรับระบบนั้น.
เลือกระบบที่ต้องการ- ใช้เป็นแนวทางได้กับระบบ RCM ทุกประเภทสำหรับ process mining.
- แอตทริบิวต์และกิจกรรมหลักสำหรับสร้างบันทึกเหตุการณ์ที่มีประสิทธิภาพ.
- แหล่งข้อมูลพื้นฐานสำหรับวิเคราะห์และปรับปรุงกระบวนการอย่างมีประสิทธิภาพ.
แอตทริบิวต์การจัดการวงจรรายได้
| ชื่อ | คำอธิบาย | ||
|---|---|---|---|
| Billing Event ID BillingEventId | รหัสเฉพาะของการให้บริการหรือส่งมอบผลิตภัณฑ์หนึ่งรายการที่ทำให้เกิดค่าบริการ ใช้เป็นรหัสเคสหลักของกระบวนการวงจรรายได้. | ||
| คำอธิบาย Billing Event ID คือคีย์เฉพาะที่กำหนดให้กับบริการที่เรียกเก็บเงินแต่ละรายการ ตั้งแต่บันทึกค่าบริการครั้งแรกจนถึงการชำระเงินหรือการตัดหนี้สูญขั้นสุดท้าย คีย์นี้เชื่อมโยงกิจกรรมที่เกี่ยวข้องทั้งหมดของบริการหนึ่งครั้งเข้าด้วยกัน เช่น การสร้างเคลม การส่งเคลม การปฏิเสธ และการบันทึกการชำระเงิน ใน process mining แอตทริบิวต์นี้จำเป็นต่อการสร้างภาพเส้นทางของ Billing Event ตั้งแต่ต้นจนจบ เมื่อนำกิจกรรมที่เกี่ยวข้องทั้งหมดมาจัดกลุ่มภายใต้ Billing Event ID เดียว นักวิเคราะห์จะเห็นลำดับการทำงาน ระบุคอขวด วัดรอบเวลาดำเนินการ และเข้าใจความแตกต่างในการจัดการแต่ละเคสได้ แอตทริบิวต์นี้เป็นพื้นฐานของการวิเคราะห์ที่ยึดเคสเป็นหลักในวงจรรายรับ เหตุผลที่สำคัญ นี่คือรหัสเคสสำคัญที่เชื่อมโยงกิจกรรมที่เกี่ยวข้องทั้งหมดเข้าด้วยกัน ทำให้สร้างและวิเคราะห์วงจรรายได้ทั้งหมดของบริการที่เรียกเก็บเงินได้แต่ละรายการขึ้นมาใหม่ได้. แหล่งข้อมูล โดยทั่วไปเป็นคีย์หลักในตารางธุรกรรมการเรียกเก็บเงินหรือตารางเหตุการณ์ทางการเงิน. ตัวอย่าง BE-2024-001234INV-987654ACCN-456789012 | |||
| ชื่อกิจกรรม ActivityName | ชื่อของขั้นตอน งาน หรือเหตุการณ์เฉพาะที่เกิดขึ้นในกระบวนการวงจรรายได้ของ billing event รายการหนึ่ง. | ||
| คำอธิบาย ชื่อกิจกรรมอธิบายการดำเนินการหรือหมุดหมายที่เกิดขึ้นในวงจรรายได้ ตัวอย่างเช่น 'ให้บริการแล้ว', 'ส่งเคลมแล้ว', 'ได้รับข้อมูลการชำระเงินแล้ว', 'บันทึกการรับชำระเงินแล้ว' และ 'ตัดบัญชีเป็นหนี้สูญ' แต่ละกิจกรรมเป็นขั้นตอนหนึ่งของกระบวนการที่ใช้เวลาและทรัพยากร คุณลักษณะนี้เป็นพื้นฐานของ process mining เพราะใช้กำหนดจุดต่างๆ ในแผนที่กระบวนการ การวิเคราะห์ลำดับ ความถี่ และระยะเวลาของกิจกรรมเหล่านี้ช่วยแสดงภาพกระบวนการจริง เปรียบเทียบกับโมเดลที่ออกแบบไว้ และระบุจุดเบี่ยงเบน การย้อนกลับไปทำงานซ้ำ เช่น เคลมถูกปฏิเสธ และความไม่มีประสิทธิภาพ. เหตุผลที่สำคัญ คุณลักษณะนี้กำหนดขั้นตอนของกระบวนการ ซึ่งจำเป็นต่อการค้นหาและแสดงภาพแผนที่กระบวนการ ระบุงานที่ต้องทำซ้ำ และวิเคราะห์ความสอดคล้องของกระบวนการ. แหล่งข้อมูล มักพบในบันทึกเหตุการณ์ ตารางธุรกรรม หรือข้อมูลที่ได้จากระเบียนการเปลี่ยนสถานะในโมดูลเรียกเก็บเงินหรือโมดูลเคลม. ตัวอย่าง ส่งเคลมแล้วบันทึกการชำระเงินแล้วเริ่มแก้ไขเคลมที่ถูกปฏิเสธส่งใบแจ้งยอดให้ผู้ป่วยแล้ว | |||
| เวลาที่เกิดเหตุการณ์ EventTimestamp | วันที่และเวลาที่แน่นอนซึ่งระบบบันทึกกิจกรรมหนึ่งๆ. | ||
| คำอธิบาย เวลาที่บันทึกเหตุการณ์ระบุเวลาที่กิจกรรมเกิดขึ้นหรือถูกบันทึกไว้ในระบบ และให้บริบทตามลำดับเวลาของทุกเหตุการณ์ในเคส ตั้งแต่ต้นจนจบวงจรรายได้. เวลาเป็นพื้นฐานของการวิเคราะห์ประสิทธิภาพใน process mining ใช้คำนวณ KPI สำคัญ เช่น ระยะเวลาดำเนินการทั้งหมด ระยะเวลาระหว่างกิจกรรมเฉพาะ และเวลารอคอย เมื่อวิเคราะห์เวลาที่บันทึกไว้ องค์กรจะระบุคอขวดที่ทำให้เคสใช้เวลานานที่สุด วัดการปฏิบัติตามข้อตกลงระดับการให้บริการ และทำความเข้าใจการเปลี่ยนแปลงของกระบวนการตามเวลาได้. เหตุผลที่สำคัญ ข้อมูลนี้ให้ลำดับเวลาที่จำเป็นต่อการคำนวณระยะเวลาของกระบวนการ ระบุคอขวด และวิเคราะห์ประสิทธิภาพของกระบวนการ. แหล่งข้อมูล โดยทั่วไปข้อมูลนี้อยู่ในบันทึกธุรกรรม เส้นทางการตรวจสอบ หรือฟิลด์วันที่สร้างหรือวันที่เปลี่ยนสถานะในตารางเหตุการณ์. ตัวอย่าง 2023-10-26T10:00:00Z2023-11-15T14:35:10Z2024-01-05T09:12:45Z | |||
| การอัปเดตข้อมูลล่าสุด LastDataUpdate | เวลาที่ระบุว่าข้อมูลของระเบียนเหตุการณ์นี้ได้รับการรีเฟรชหรือดึงจากระบบต้นทางครั้งล่าสุดเมื่อใด. | ||
| คำอธิบาย แอตทริบิวต์นี้บันทึกเวลาที่ดึงข้อมูลจากระบบต้นทางครั้งล่าสุด เป็นฟิลด์เมทาดาทาสำคัญที่ช่วยให้เข้าใจว่าข้อมูลที่นำมาวิเคราะห์ใหม่และเป็นปัจจุบันเพียงใด อีกทั้งยังสะท้อนความล่าช้าของไปป์ไลน์ข้อมูลและบอกได้ว่าผลวิเคราะห์ process mining เป็นข้อมูลล่าสุดแค่ไหน ใน dashboard และการวิเคราะห์ process mining เวลาการอัปเดตข้อมูลล่าสุดช่วยให้ผู้ใช้ทราบว่าข้อมูลเป็นปัจจุบันเพียงใด สำหรับการติดตามการปฏิบัติการ จำเป็นต้องรู้ว่าข้อมูลแสดงสถานะกระบวนการเมื่อห้านาทีก่อนหรือเมื่อคืนที่ผ่านมา เพื่อให้ผู้ใช้เข้าใจขอบเขตของข้อมูลและตัดสินใจโดยทราบอายุของข้อมูล. เหตุผลที่สำคัญ ช่วยให้เข้าใจว่าข้อมูลเป็นปัจจุบันและทันเวลาเพียงใด เพื่อให้การวิเคราะห์และการตัดสินใจอ้างอิงช่วงเวลาที่เข้าใจตรงกัน. แหล่งข้อมูล โดยทั่วไปจะเพิ่มข้อมูลนี้ระหว่างขั้นตอนการดึง แปลง และโหลดข้อมูล (ETL) แล้วจัดเก็บเป็นคอลัมน์เมทาดาทาในบันทึกเหตุการณ์. ตัวอย่าง 2024-03-15T02:00:00Z2024-03-15T03:00:00Z2024-03-15T04:00:00Z | |||
| ระบบต้นทาง SourceSystem | ระบบสารสนเทศ แอปพลิเคชัน หรือโมดูลที่ดึงข้อมูลเหตุการณ์ออกมา. | ||
| คำอธิบาย แอตทริบิวต์ระบบต้นทางระบุแหล่งที่มาของข้อมูลสำหรับเหตุการณ์หนึ่งๆ ในระบบไอทีที่ซับซ้อน กระบวนการวงจรรายได้มักเกี่ยวข้องกับหลายระบบ เช่น ระบบเวชระเบียนอิเล็กทรอนิกส์ (EHR) สำหรับบันทึกการให้บริการ ระบบเรียกเก็บเงินเฉพาะทางสำหรับส่งเคลม และแพลตฟอร์มติดตามหนี้อีกระบบหนึ่ง การทราบระบบต้นทางมีประโยชน์ต่อการตรวจสอบความถูกต้องของข้อมูล การแก้ไขปัญหา และการทำความเข้าใจว่ากระบวนการแยกอยู่ในระบบใดบ้าง นอกจากนี้ยังช่วยค้นหาความไม่สอดคล้องระหว่างระบบ หรือระบุขั้นตอนที่จัดการในแอปพลิเคชันต่างกัน ซึ่งอาจทำให้การถ่ายโอนข้อมูลล่าช้าหรือเกิดข้อผิดพลาด การวิเคราะห์นี้ช่วยประเมินการเชื่อมต่อและประสิทธิภาพของสถาปัตยกรรมไอทีโดยรวมที่รองรับกระบวนการ. เหตุผลที่สำคัญ ช่วยให้เห็นว่ากระบวนการแยกอยู่ในระบบไอทีใดบ้าง และจำเป็นต่อการตรวจสอบข้อมูลกับการระบุคอขวดเฉพาะระบบ. แหล่งข้อมูล ข้อมูลนี้มักเป็นฟิลด์มาตรฐานในชุดข้อมูลที่ดึงออกมา หรืออนุมานได้จากตารางหรือไฟล์ต้นทางที่ใช้ดึงข้อมูล. ตัวอย่าง Epic ResoluteOracle HealthR1 RCM PlatformWaystar | |||
| ชื่อผู้จ่ายเงิน PayerName | ชื่อบริษัทประกัน หน่วยงานรัฐ หรือผู้จ่ายเงินบุคคลที่สามซึ่งรับผิดชอบการชำระเงิน. | ||
| คำอธิบาย ชื่อผู้จ่ายเงินระบุหน่วยงานหลักที่ส่งเคลมเพื่อขอรับเงินคืน ผู้จ่ายเงินอาจเป็นบริษัทประกันเอกชน เช่น Aetna หรือ UnitedHealthcare โครงการของรัฐ เช่น Medicare หรือ Medicaid หรือหน่วยงานอื่นๆ ผู้จ่ายเงินแต่ละรายมีข้อกำหนด กฎการส่งเคลม และรูปแบบการชำระเงินที่แตกต่างกัน แอตทริบิวต์นี้สำคัญต่อการวิเคราะห์ประสิทธิภาพของวงจรรายได้ เมื่อแยกวิเคราะห์กระบวนการตามผู้จ่ายเงิน องค์กรจะระบุได้ว่ารายใดมีอัตราการปฏิเสธเคลมสูงที่สุด ใช้เวลาชำระเงินนานที่สุด หรือขอข้อมูลเพิ่มเติมบ่อยที่สุด จากนั้นจึงกำหนดแนวทางแก้ไขให้ตรงจุด เช่น เจรจาสัญญาใหม่ ปรับขั้นตอนการส่งเคลมให้เหมาะกับผู้จ่ายเงินแต่ละราย และมุ่งจัดการเคลมที่ถูกปฏิเสธในจุดที่จำเป็นที่สุด. เหตุผลที่สำคัญ ช่วยแยกวิเคราะห์ตัวชี้วัด เช่น อัตราการปฏิเสธเคลมและระยะเวลาชำระเงินตามผู้จ่ายเงิน ซึ่งจำเป็นต่อการปรับปรุงและเจรจาสัญญาให้ตรงจุด. แหล่งข้อมูล โดยทั่วไปพบข้อมูลนี้ในข้อมูลลงทะเบียนผู้ป่วย ข้อมูลประกัน หรือข้อมูลเคลมที่เชื่อมโยงกับเหตุการณ์เรียกเก็บเงิน. ตัวอย่าง AetnaCignaMedicareUnitedHealthcare | |||
| ผู้ใช้ที่รับผิดชอบ ResponsibleUser | รหัสของผู้ใช้ พนักงาน หรือระบบอัตโนมัติที่ดำเนินกิจกรรม. | ||
| คำอธิบาย แอตทริบิวต์ผู้ใช้ที่รับผิดชอบเชื่อมโยงขั้นตอนของกระบวนการกับบุคคลหรือระบบที่ดำเนินการ เช่น เจ้าหน้าที่ลงรหัสทางการแพทย์ที่ลงรหัสเสร็จแล้ว ผู้เชี่ยวชาญด้านการเรียกเก็บเงินที่ส่งเคลม หรือบอตอัตโนมัติที่บันทึกการชำระเงิน การติดตามผู้ใช้ช่วยให้วิเคราะห์กระบวนการได้ทั้งจากมุมมองของบุคคลและระบบ การวิเคราะห์ประสิทธิภาพของกระบวนการแยกตามผู้ใช้หรือทีมช่วยค้นหาโอกาสในการฝึกอบรม ระบุผู้ที่ทำงานได้ดี และจัดสรรภาระงานให้เหมาะสม นอกจากนี้ยังสำคัญต่อการปฏิบัติตามข้อกำหนดและการตรวจสอบ โดยช่วยระบุผู้รับผิดชอบของแต่ละการดำเนินการได้อย่างชัดเจน แอตทริบิวต์นี้ช่วยให้วิเคราะห์ประสิทธิภาพและการใช้ทรัพยากรได้อย่างละเอียด. เหตุผลที่สำคัญ ช่วยวิเคราะห์ประสิทธิภาพของทีมและบุคคล การกระจายภาระงาน และสัดส่วนงานอัตโนมัติ ทำให้เห็นประสิทธิภาพการใช้ทรัพยากรและความต้องการด้านการฝึกอบรม. แหล่งข้อมูล โดยทั่วไปพบข้อมูลนี้ในบันทึกธุรกรรมหรือเส้นทางการตรวจสอบ ภายใต้ฟิลด์อย่าง 'User ID', 'Employee ID' หรือ 'Processor'. ตัวอย่าง john.doejane.smithAUTO-POSTER-BOTU123456 | |||
| แผนกที่รับผิดชอบ ResponsibleDepartment | แผนก ทีม หรือหน่วยงานที่รับผิดชอบการดำเนินกิจกรรม. | ||
| คำอธิบาย แอตทริบิวต์นี้ระบุหน่วยงานที่เกี่ยวข้องกับขั้นตอนหนึ่งของกระบวนการ เช่น 'ฝ่ายรับผู้ป่วย', 'ฝ่ายลงรหัส', 'ฝ่ายเรียกเก็บเงิน' หรือ 'ฝ่ายติดตามหนี้' ช่วยให้เข้าใจว่ามีการกระจายและส่งต่องานระหว่างทีมอย่างไร การวิเคราะห์กระบวนการแยกตามแผนกจำเป็นต่อการทำความเข้าใจการทำงานร่วมกันระหว่างหน่วยงาน และการระบุคอขวดที่จุดส่งต่องานระหว่างทีม ผู้จัดการสามารถดูได้ว่าแผนกใดเกี่ยวข้องกับกระบวนการแต่ละรูปแบบ วัดประสิทธิภาพของแต่ละแผนก และจัดสรรทรัพยากรได้เหมาะสมยิ่งขึ้น การวิเคราะห์นี้ยังช่วยให้เห็นปัญหาเชิงระบบภายในแผนกที่อาจส่งผลต่อวงจรรายได้ทั้งหมด. เหตุผลที่สำคัญ ช่วยระบุคอขวดระหว่างแผนกและวิเคราะห์ประสิทธิภาพตามหน่วยงาน ทำให้เห็นโอกาสในการทำงานร่วมกันระหว่างทีมให้ดีขึ้น. แหล่งข้อมูล ข้อมูลนี้อาจอยู่ในข้อมูลธุรกรรม หรืออนุมานได้จากข้อมูลหลักที่เชื่อมโยงกับผู้ใช้ที่รับผิดชอบ. ตัวอย่าง ฝ่ายเรียกเก็บเงินฝ่ายบริการลงรหัสฝ่ายจัดการเคลมที่ถูกปฏิเสธฝ่ายติดตามหนี้ | |||
| ยอดปรับปรุง AdjustmentAmount | มูลค่าของรายการปรับปรุง การตัดหนี้สูญ หรือส่วนลดตามสัญญาที่นำไปปรับยอดบัญชี. | ||
| คำอธิบาย ยอดปรับปรุงคือส่วนของยอดเรียกเก็บที่ไม่คาดว่าจะได้รับจากผู้จ่ายเงินหรือผู้ป่วย ด้วยเหตุผลต่างๆ เช่น ข้อตกลงตามสัญญา ส่วนลด หรือการตัดหนี้สูญ รายการเหล่านี้ทำให้ยอดลูกหนี้รวมลดลง และเป็นส่วนหนึ่งของวงจรรายได้ตามปกติ การวิเคราะห์ยอดปรับปรุงและเหตุผลที่เกี่ยวข้องช่วยให้เข้าใจความถูกต้องของรายได้ หากยอดปรับปรุงสูงหรือผิดปกติ อาจบ่งชี้ปัญหาในการบันทึกค่าบริการ การลงรหัส หรือการจัดการสัญญา process mining ช่วยระบุได้ว่ากระบวนการรูปแบบใดหรือกิจกรรมใดทำให้อัตราการปรับปรุงสูงขึ้น เพื่อให้วิเคราะห์หาสาเหตุที่แท้จริงได้ตรงจุดและเพิ่มรายได้ที่เรียกเก็บได้. เหตุผลที่สำคัญ ช่วยวิเคราะห์รายได้ที่สูญเสียไปจากการติดตามยอดตัดหนี้สูญและส่วนลดตามสัญญา พร้อมชี้ปัญหาที่อาจเกิดขึ้นในการทำสัญญาหรือการเรียกเก็บเงิน. แหล่งข้อมูล โดยทั่วไปบันทึกค่านี้ไว้ในตารางรายการปรับปรุงทางการเงินหรือโมดูลบันทึกการชำระเงิน. ตัวอย่าง 29.50500.75100.001500.00 | |||
| ยอดเรียกเก็บ BilledAmount | มูลค่ารวมของบริการหรือสินค้าที่เรียกเก็บ ก่อนหักรายการปรับปรุงหรือยอดชำระ. | ||
| คำอธิบาย ยอดเรียกเก็บคือค่าใช้จ่ายรวมของบริการที่ให้ ซึ่งส่งไปพร้อมกับเคลมหรือใบแจ้งหนี้ นี่คือมูลค่าทางการเงินตั้งต้นของเหตุการณ์เรียกเก็บเงิน และเป็นฐานสำหรับวัดธุรกรรมทางการเงินที่เกิดขึ้นภายหลัง เช่น การชำระเงินและรายการปรับปรุง การวิเคราะห์ยอดเรียกเก็บด้วย process mining เป็นพื้นฐานสำคัญในการทำความเข้าใจผลกระทบทางการเงินจากความไม่มีประสิทธิภาพของกระบวนการ คุณสามารถแบ่งเคสตามมูลค่าสูงและต่ำ เพื่อดูว่าปัญหาบางอย่างส่งผลต่อเคลมที่มีรายได้สูงเป็นพิเศษหรือไม่ เมื่อนำยอดนี้ไปเปรียบเทียบกับตัวชี้วัด เช่น ระยะเวลาดำเนินการหรืออัตราการปฏิเสธเคลม จะช่วยจัดลำดับความสำคัญของการปรับปรุงตามผลกระทบทางการเงินได้. เหตุผลที่สำคัญ ใช้ระบุมูลค่าทางการเงินตั้งต้นของเคส ทำให้วิเคราะห์ผลกระทบจากความไม่มีประสิทธิภาพ เช่น ความล่าช้าและการปฏิเสธเคลมได้. แหล่งข้อมูล แอตทริบิวต์ทางการเงินหลักนี้พบได้ในตารางบันทึกค่าบริการ การเรียกเก็บเงิน หรือธุรกรรมเคลม. ตัวอย่าง 150.002500.75500.0010000.00 | |||
| รหัสเหตุผลการปฏิเสธเคลม DenialReasonCode | รหัสมาตรฐานและคำอธิบายที่ระบุเหตุผลที่ผู้จ่ายเงินปฏิเสธเคลม. | ||
| คำอธิบาย เมื่อผู้จ่ายเงินปฏิเสธเคลมที่ส่งไป จะระบุรหัสเหตุผลการปฏิเสธเคลมเพื่ออธิบายว่าเหตุใดจึงไม่ชำระเงิน รหัสเหล่านี้มักเป็นไปตามมาตรฐานอุตสาหกรรม เช่น Claim Adjustment Reason Codes (CARCs) และชี้ปัญหาเฉพาะ เช่น 'ไม่ครอบคลุมบริการนี้', 'ส่งเคลมซ้ำ' หรือ 'ต้องการข้อมูลเพิ่มเติม' แอตทริบิวต์นี้มีประโยชน์อย่างยิ่งต่อการวิเคราะห์หาสาเหตุที่แท้จริงของปัญหาในวงจรรายได้ เมื่อวิเคราะห์ความถี่และผลกระทบทางการเงินของเหตุผลการปฏิเสธแต่ละประเภท องค์กรจะระบุข้อผิดพลาดในขั้นตอนก่อนหน้าที่ทำให้เคลมถูกปฏิเสธได้ ตัวอย่างเช่น หากเคลมถูกปฏิเสธด้วยเหตุผล 'ข้อมูลผู้ป่วยไม่ถูกต้อง' จำนวนมาก อาจชี้ว่าขั้นตอนลงทะเบียนผู้ป่วยมีปัญหา ข้อมูลนี้ช่วยให้ปรับปรุงกระบวนการโดยอ้างอิงข้อมูลจริง ป้องกันการปฏิเสธเคลมในอนาคต และเพิ่มอัตราการชำระเงินตั้งแต่การส่งเคลมครั้งแรก. เหตุผลที่สำคัญ จำเป็นต่อการวิเคราะห์หาสาเหตุที่แท้จริงของการปฏิเสธเคลม ช่วยปรับปรุงขั้นตอนต้นทางและช่วงกลางของกระบวนการให้ตรงจุด เพื่อป้องกันการสูญเสียรายได้ในอนาคต. แหล่งข้อมูล ข้อมูลนี้มาจากไฟล์คำแนะนำการโอนเงินทางอิเล็กทรอนิกส์ (ERA) หรือคำชี้แจงสิทธิประโยชน์ (EOB) ที่ได้รับจากผู้จ่ายเงิน. ตัวอย่าง CO-16: เคลมหรือบริการมีข้อมูลไม่ครบPR-97: สิทธิประโยชน์สำหรับบริการนี้รวมอยู่ในการชำระเงินของบริการอื่นแล้วOA-18: เคลมหรือบริการซ้ำCO-22: ผู้จ่ายเงินรายอื่นอาจเป็นผู้รับผิดชอบค่าบริการนี้ตามการประสานสิทธิประโยชน์ | |||
| หมวดหมู่บริการ ServiceCategory | หมวดหมู่ ประเภท หรือการจัดประเภทของบริการที่ให้ เช่น ผู้ป่วยใน ผู้ป่วยนอก หรือรังสีวิทยา. | ||
| คำอธิบาย หมวดหมู่บริการใช้จำแนกประเภทการดูแลหรือบริการที่ผู้ป่วยได้รับ อาจเป็นหมวดหมู่กว้างๆ เช่น 'ผู้ป่วยใน' และ 'ผู้ป่วยนอก' หรือหมวดหมู่เฉพาะแผนก เช่น 'ศัลยกรรม', 'ห้องฉุกเฉิน' หรือ 'ห้องปฏิบัติการ' บริการแต่ละหมวดหมู่มักมีกฎการเรียกเก็บเงิน ข้อกำหนดของผู้จ่ายเงิน และขั้นตอนการทำงานที่แตกต่างกัน การแยกวิเคราะห์กระบวนการวงจรรายได้ตามหมวดหมู่บริการจำเป็นต่อการวิเคราะห์ที่มีความหมาย องค์กรสามารถเปรียบเทียบผลการดำเนินงานของบริการแต่ละประเภท เช่น ตรวจสอบว่าอัตราการปฏิเสธเคลมสำหรับการผ่าตัดสูงกว่าการปรึกษาหรือไม่ รายละเอียดระดับนี้ช่วยแยกปัญหาและปรับแนวทางการปรับปรุงให้เหมาะกับการปฏิบัติงานของแต่ละหน่วยบริการ. เหตุผลที่สำคัญ ช่วยเปรียบเทียบผลการดำเนินงานของบริการแต่ละประเภท ทำให้เห็นความแตกต่างด้านประสิทธิภาพ อัตราการปฏิเสธเคลม และระยะเวลาชำระเงินของการดูแลแต่ละประเภท. แหล่งข้อมูล โดยทั่วไปพบข้อมูลนี้ในระเบียนรายละเอียดค่าบริการ หรืออนุมานได้จากประเภทผู้ป่วย แผนก หรือรหัสหัตถการ. ตัวอย่าง ผู้ป่วยในผู้ป่วยนอกห้องฉุกเฉินรังสีวิทยาหัตถการศัลยกรรม | |||
| ยอดคงค้าง OutstandingBalance | ยอดที่ยังไม่ได้ชำระสำหรับเหตุการณ์เรียกเก็บเงิน ณ เวลาหนึ่ง. | ||
| คำอธิบาย ยอดคงค้างคือจำนวนเงินที่ยังต้องเรียกเก็บสำหรับเหตุการณ์เรียกเก็บเงิน โดยทั่วไปคำนวณจากยอดเรียกเก็บ หักยอดชำระและยอดปรับปรุง ค่านี้เปลี่ยนแปลงไปตลอดอายุของเคสเมื่อมีการบันทึกการชำระเงินและรายการปรับปรุง แอตทริบิวต์นี้เป็นตัวชี้วัดสำคัญที่บอกสถานะลูกหนี้ การวิเคราะห์ยอดคงค้างในแต่ละขั้นตอนของกระบวนการด้วย process mining ช่วยจัดการอายุลูกหนี้และจัดลำดับความสำคัญของการติดตามหนี้ คุณสามารถใช้ข้อมูลนี้ระบุประเภทเคสหรือเส้นทางกระบวนการที่มักมียอดคงเหลือสูง ซึ่งอาจบ่งชี้ปัญหาในการชำระเงินหรือการจัดการเคลมที่ถูกปฏิเสธ. เหตุผลที่สำคัญ เป็นตัวชี้วัดสำคัญของลูกหนี้และประสิทธิผลในการเรียกเก็บเงิน ช่วยจัดลำดับความสำคัญของการติดตามและวิเคราะห์อายุลูกหนี้. แหล่งข้อมูล มักคำนวณจากยอดเรียกเก็บ ยอดชำระ และยอดปรับปรุง หรืออาจจัดเก็บเป็นฟิลด์ในระบบลูกหนี้หรือระบบบัญชีผู้ป่วย. ตัวอย่าง 50.000.00125.308500.00 | |||
| ยอดชำระแล้ว PaidAmount | มูลค่ารวมที่ได้รับจากผู้จ่ายเงินและผู้ป่วยสำหรับบริการที่เรียกเก็บ. | ||
| คำอธิบาย ยอดชำระแล้วคือผลรวมของการชำระเงินทั้งหมดที่บันทึกไว้สำหรับเหตุการณ์เรียกเก็บเงินหนึ่งรายการ ซึ่งรวมทั้งเงินจากบริษัทประกันหลักและรอง ตลอดจนเงินที่ผู้ป่วยชำระ ยอดนี้แสดงจำนวนเงินจริงที่เรียกเก็บได้จากบริการที่ให้ การวิเคราะห์ยอดชำระแล้วจำเป็นต่อการวัดผลสำเร็จทางการเงินและประสิทธิภาพของวงจรรายได้ เมื่อนำยอดชำระแล้วไปเปรียบเทียบกับยอดเรียกเก็บ จะช่วยให้เห็นรายได้สุทธิและอัตราการเรียกเก็บเงิน ใน process mining แอตทริบิวต์นี้ช่วยวัดผลลัพธ์ทางการเงินของเส้นทางกระบวนการแต่ละแบบ และระบุลักษณะของเคลมที่ได้รับชำระครบและตรงเวลา เทียบกับเคลมที่ไม่ได้รับชำระครบหรือไม่ตรงเวลา. เหตุผลที่สำคัญ ใช้วัดเงินจริงที่เรียกเก็บได้จากเคส ซึ่งสำคัญต่อการประเมินประสิทธิผลในการเรียกเก็บเงินและผลการดำเนินงานทางการเงินโดยรวมของกระบวนการ. แหล่งข้อมูล ข้อมูลนี้อยู่ในตารางธุรกรรมการบันทึกการชำระเงินหรือการนำเงินสดไปตัดยอด. ตัวอย่าง 120.502000.000.00450.25 | |||
| รหัสเคลม ClaimId | รหัสเฉพาะที่กำหนดให้เคลมประกันซึ่งส่งไปยังผู้จ่ายเงิน. | ||
| คำอธิบาย Claim ID คือตัวระบุเฉพาะของใบเรียกเก็บเงินที่ส่งให้บริษัทประกัน Billing Event หนึ่งรายการอาจมีหลายเคลม หากต้องเรียกเก็บเงินจากผู้จ่ายเงินหลัก ผู้จ่ายเงินรอง และผู้จ่ายเงินลำดับถัดไป หรือหากต้องแก้ไขและส่งเคลมใหม่ การติดตาม Claim ID ช่วยให้เข้าใจรายละเอียดของกระบวนการติดต่อกับผู้จ่ายเงิน ทำให้วิเคราะห์วงจรการแก้งานที่เกิดจากการส่งเคลมซ้ำ และติดตามสถานะของใบเรียกเก็บเงินที่ส่งให้ผู้จ่ายเงินรายใดรายหนึ่งได้ การวิเคราะห์ตาม Claim ID ให้รายละเอียดวงจรการส่งและจัดการเคลมได้มากกว่าการดู Billing Event เพียงอย่างเดียว เหตุผลที่สำคัญ ช่วยติดตามการส่งและส่งเคลมใหม่ได้อย่างละเอียด ทำให้วิเคราะห์การติดต่อกับผู้จ่ายเงินและการทำงานซ้ำได้ชัดเจน. แหล่งข้อมูล ระบบเรียกเก็บเงินสร้างรหัสนี้เมื่อสร้างเคลม และจัดเก็บไว้ในตารางจัดการเคลม. ตัวอย่าง CLM-2024-555-1239876543210-01TCN-A1B2C3D4E5 | |||
| รหัสผู้ป่วย PatientId | รหัสเฉพาะของผู้ป่วยที่ได้รับบริการ. | ||
| คำอธิบาย Patient ID คือคีย์เฉพาะที่กำหนดให้ผู้ป่วยแต่ละรายในดัชนีข้อมูลผู้ป่วยหลักของระบบสุขภาพ ตัวระบุนี้เชื่อมโยงข้อมูลการรักษาและธุรกรรมทางการเงินทั้งหมดของผู้ป่วยรายนั้นในช่วงเวลาต่างๆ Billing Event ID ใช้ระบุเคสของบริการหนึ่งรายการ ส่วน Patient ID ช่วยให้วิเคราะห์ข้อมูลการพบแพทย์หลายครั้งของผู้ป่วยคนเดียวกันได้ในภาพรวม ซึ่งอาจเผยให้เห็นปัญหาที่เกิดซ้ำ เช่น ข้อผิดพลาดในการลงทะเบียนซ้ำๆ หรือรูปแบบการใช้บริการ นอกจากนี้ยังใช้วิเคราะห์เส้นทางการเงินทั้งหมดของผู้ป่วย ซึ่งเป็นประโยชน์ต่อการทำความเข้าใจภาระค่าใช้จ่ายและความภักดีของผู้ป่วย เหตุผลที่สำคัญ ช่วยวิเคราะห์เหตุการณ์เรียกเก็บเงินหลายรายการของผู้ป่วยคนเดียวกัน เพื่อระบุปัญหาที่เกิดซ้ำและทำความเข้าใจเส้นทางทางการเงินโดยรวมของผู้ป่วย. แหล่งข้อมูล รหัสหลักนี้พบได้ในระบบทางคลินิกและระบบการเงินแทบทุกระบบ โดยมาจากระบบลงทะเบียนผู้ป่วยหรือระบบ EHR. ตัวอย่าง MRN-100345PAT-987654321202400567 | |||
| สถานะบัญชี AccountStatus | สถานะปัจจุบันของบัญชีเรียกเก็บเงินในวงจรรายได้ เช่น 'เรียกเก็บเงินแล้ว', 'ชำระแล้ว' หรือ 'อยู่ระหว่างติดตามหนี้'. | ||
| คำอธิบาย สถานะบัญชีแสดงภาพรวมว่าเหตุการณ์เรียกเก็บเงินอยู่ในขั้นตอนใดของวงจร ณ เวลาหนึ่ง สถานะนี้สะท้อนผลจากกิจกรรมล่าสุด เช่น บัญชียังเปิดและรอชำระเงิน ปิดแล้ว ส่งไปติดตามหนี้ หรืออยู่ในสถานะอื่น process mining ใช้สร้างลำดับกิจกรรมของกระบวนการขึ้นใหม่ ส่วนแอตทริบิวต์สถานะบัญชีช่วยกรองและแบ่งเคสตามสถานะปัจจุบันได้เป็นอย่างดี โดยเฉพาะ dashboard ติดตามการปฏิบัติการที่ต้องแสดงจำนวนและมูลค่าของบัญชีในแต่ละขั้นตอน เช่น ยอดลูกหนี้ทั้งหมดที่กำลังรอคำตอบจากผู้จ่ายเงิน หรือจำนวนบัญชีที่เพิ่งส่งให้หน่วยงานติดตามหนี้. เหตุผลที่สำคัญ แสดงสถานะปัจจุบันของเคส เหมาะสำหรับแดชบอร์ดติดตามการปฏิบัติการและการแบ่งผลวิเคราะห์ตามขั้นตอนของบัญชี. แหล่งข้อมูล โดยทั่วไปเป็นฟิลด์สถานะในระเบียนบัญชีผู้ป่วยหลักหรือระเบียนเหตุการณ์เรียกเก็บเงินของระบบบัญชีผู้ป่วย. ตัวอย่าง เรียกเก็บเงินแล้ว รอผู้จ่ายเงินชำระครบแล้วถูกปฏิเสธส่งไปติดตามหนี้แล้วปิดบัญชี ตัดหนี้สูญแล้ว | |||
| เหตุผลในการปรับยอด AdjustmentReason | เหตุผลของการปรับยอดทางการเงิน เช่น ส่วนลดตามสัญญาหรือการตัดหนี้สูญ. | ||
| คำอธิบาย เช่นเดียวกับเหตุผลการปฏิเสธเคลม เหตุผลในการปรับยอดอธิบายว่าทำไมจึงตัดยอดเรียกเก็บบางส่วนหรือปรับยอด เหตุผลนี้ช่วยแยกได้ว่าการปรับยอดเกิดจากข้อผูกพันตามสัญญากับผู้จ่ายเงิน นโยบายการดูแลผู้ป่วยโดยไม่คิดค่าใช้จ่าย การตัดยอดคงเหลือจำนวนเล็กน้อย หรือการแก้ไขข้อผิดพลาดในการเรียกเก็บเงิน การวิเคราะห์เหตุผลในการปรับยอดช่วยให้เข้าใจความถูกต้องของรายได้และผลการดำเนินงานทางการเงิน อีกทั้งช่วยแยกรายการปรับยอดตามสัญญาที่คาดหมายได้ออกจากการตัดหนี้สูญที่ป้องกันได้และเกิดจากข้อผิดพลาดภายใน เมื่อนักวิเคราะห์กรองแผนผังกระบวนการตามเหตุผลในการปรับยอด ก็จะระบุจุดอ่อนของกระบวนการที่ทำให้สูญเสียรายได้โดยไม่จำเป็น และกำหนดแนวทางปรับปรุงได้ตรงจุด. เหตุผลที่สำคัญ ช่วยให้เข้าใจที่มาของการปรับยอดทางการเงิน และแยกข้อผูกพันตามสัญญาออกจากการสูญเสียรายได้ที่ป้องกันได้ซึ่งเกิดจากข้อผิดพลาดในกระบวนการ. แหล่งข้อมูล พบในตารางธุรกรรมทางการเงินของระบบเรียกเก็บเงินหรือระบบบัญชีผู้ป่วย โดยมักเชื่อมโยงกับธุรกรรมการปรับยอดหรือการตัดหนี้สูญ. ตัวอย่าง ส่วนลดตามสัญญาการตัดยอดคงเหลือจำนวนเล็กน้อยหนี้สูญการแก้ไขข้อผิดพลาดในการเรียกเก็บเงิน | |||
กิจกรรมในการจัดการวงจรรายได้
| กิจกรรม | คำอธิบาย | ||
|---|---|---|---|
| เคลมถูกปฏิเสธ | หมายถึงผู้จ่ายเงินปฏิเสธเคลมหรือรายการบางรายการ ทำให้ไม่ได้รับชำระเงิน โดยทั่วไปจะทราบเมื่อผู้ให้บริการได้รับและประมวลผลเอกสารคำแนะนำการชำระเงินจากผู้จ่ายเงิน. | ||
| เหตุผลที่สำคัญ การระบุเคลมที่ถูกปฏิเสธเป็นพื้นฐานสำคัญในการวิเคราะห์รายได้รั่วไหล อัตราการปฏิเสธ และประสิทธิผลของกระบวนการจัดการเคลมที่ถูกปฏิเสธ อีกทั้งยังเป็นจุดเริ่มต้นหลักของการทำงานซ้ำและการยื่นอุทธรณ์. แหล่งข้อมูล โดยทั่วไปพบเหตุการณ์นี้ในข้อมูลคำแนะนำการชำระเงิน โดยระบุจากรหัสเหตุผลการปรับเคลม (CARCs) ที่แสดงว่ามีการปฏิเสธ. บันทึก อนุมานเหตุการณ์นี้ได้จากการตรวจข้อมูลคำแนะนำการชำระเงิน เพื่อหารหัสการปฏิเสธที่เชื่อมโยงกับเคลมหรือรายการบริการ. ประเภทเหตุการณ์ inferred | |||
| บันทึกการชำระเงินแล้ว | นำเงินที่ได้รับไปบันทึกในบัญชีผู้ป่วยอย่างเป็นทางการและจัดสรรให้กับรายการบริการที่เกี่ยวข้อง การดำเนินการนี้ย้ายยอดจากบัญชีลูกหนี้เป็นเงินสดและลดยอดค้างชำระ. | ||
| เหตุผลที่สำคัญ นี่คือหมุดหมายสำคัญที่ยืนยันว่าได้รับรายได้จากผู้จ่ายเงินแล้ว หากบันทึกการรับชำระเงินล่าช้า อาจทำให้ข้อมูลอายุลูกหนี้และรายงานกระแสเงินสดคลาดเคลื่อน. แหล่งข้อมูล นี่คือธุรกรรมทางการเงินที่บันทึกไว้อย่างชัดเจนในบัญชีแยกประเภทของระบบบัญชีผู้ป่วย การบันทึกการรับชำระเงินแต่ละครั้งควรมีวันที่และเวลาของธุรกรรม. บันทึก ใช้เวลาของธุรกรรมจากรายการนำการชำระเงินไปบันทึกหรือสมุดรายวันบันทึกเงินสด. ประเภทเหตุการณ์ explicit | |||
| ปิดเหตุการณ์เรียกเก็บเงินแล้ว | จัดการ billing event เสร็จสมบูรณ์ ยอดค้างชำระเป็นศูนย์ และไม่คาดว่าจะมีกิจกรรมเพิ่มเติม ซึ่งอาจเกิดจากการชำระเงิน การปรับยอด การตัดหนี้สูญ หรือหลายวิธีร่วมกัน. | ||
| เหตุผลที่สำคัญ กิจกรรมนี้เป็นจุดสิ้นสุดของกระบวนการ ทำให้คำนวณระยะเวลาดำเนินการตั้งแต่ต้นจนจบได้ และยืนยันผลลัพธ์สุดท้ายของ billing event ว่าเรียกเก็บเงินสำเร็จหรือตัดหนี้สูญ. แหล่งข้อมูล โดยทั่วไปอนุมานสถานะนี้เมื่อยอดบัญชีเป็นศูนย์ บางระบบอาจมีสถานะ 'Closed' หรือช่องวันที่ปิดบัญชีในระเบียนบัญชีโดยตรง. บันทึก อนุมานเหตุการณ์นี้โดยระบุเวลาของธุรกรรมทางการเงินรายการสุดท้ายที่ทำให้ยอดของ billing event เป็นศูนย์. ประเภทเหตุการณ์ inferred | |||
| ส่งเคลมแล้ว | กิจกรรมนี้หมายถึงการส่งเคลมที่สร้างขึ้นให้บริษัทประกันหรือผู้จ่ายเงินพิจารณา ไม่ว่าจะส่งทางอิเล็กทรอนิกส์หรือเอกสาร เป็นคำขอรับชำระเงินอย่างเป็นทางการสำหรับบริการที่ให้ไป. | ||
| เหตุผลที่สำคัญ การติดตามกิจกรรมนี้สำคัญต่อการวัดระยะเวลาตั้งแต่ให้บริการจนถึงออกใบแจ้งหนี้ และระบุความล่าช้าระหว่างการสร้างเคลมกับการส่งเคลม นี่คือจุดสำคัญที่บอกว่า billing event เข้าสู่บัญชีลูกหนี้อย่างเป็นทางการ. แหล่งข้อมูล โดยทั่วไปบันทึกเหตุการณ์นี้ในบันทึกธุรกรรมเคลมหรือตารางเชื่อมต่อกับ clearinghouse มักมีการอัปเดตสถานะเพื่อระบุว่าส่งข้อมูลสำเร็จ. บันทึก บันทึกเวลาที่สถานะเคลมเปลี่ยนเป็น 'Submitted', 'Transmitted' หรือสถานะอื่นที่มีความหมายเดียวกัน. ประเภทเหตุการณ์ explicit | |||
| ให้บริการแล้ว | กิจกรรมนี้เป็นจุดเริ่มต้นของ billing event โดยระบุเวลาที่ให้บริการทางคลินิกแก่ผู้ป่วย นี่คือเหตุการณ์ที่เริ่มกระบวนการวงจรรายได้ทั้งหมดสำหรับการเข้ารับบริการครั้งนั้น. | ||
| เหตุผลที่สำคัญ นี่คือจุดเริ่มต้นหลักของกระบวนการตั้งแต่ต้นจนจบ ซึ่งใช้วัดระยะเวลารวมของวงจรรายได้ และช่วยระบุช่วงเวลาที่ล่าช้าระหว่างการให้บริการทางคลินิกกับการเริ่มกิจกรรมเรียกเก็บเงิน. แหล่งข้อมูล ข้อมูลนี้มักมาจากระบบงานทางคลินิก ระบบนัดหมาย หรือระบบเวชระเบียนอิเล็กทรอนิกส์ โดยอาจบันทึกจากบันทึกทางคลินิกที่ลงนามแล้ว รายการหัตถการที่เสร็จสมบูรณ์ หรือบันทึกการจำหน่ายผู้ป่วย. บันทึก บันทึกเวลาที่ปิดการเข้ารับบริการทางคลินิก วันที่ให้บริการ หรือวันที่จำหน่ายผู้ป่วย. ประเภทเหตุการณ์ explicit | |||
| ได้รับข้อมูลการชำระเงินแล้ว | ระบบได้รับคำตอบจากผู้จ่ายเงินเกี่ยวกับเคลมที่ส่งไป โดยมักอยู่ในไฟล์ Electronic Remittance Advice (ERA) ซึ่งระบุรายละเอียดการจ่าย การปฏิเสธ หรือการปรับยอดของแต่ละรายการบริการ. | ||
| เหตุผลที่สำคัญ เหตุการณ์นี้เป็นจุดสำคัญที่กำหนดขั้นตอนถัดไป ไม่ว่าจะเป็นการบันทึกการรับชำระเงิน การจัดการเคลมที่ถูกปฏิเสธ หรือการปรับยอด ระยะเวลาจนได้รับข้อมูลการชำระเงินใช้วัดประสิทธิภาพของผู้จ่ายเงิน. แหล่งข้อมูล ระบบบันทึกเหตุการณ์นี้เมื่อนำเข้าไฟล์ electronic data interchange (EDI) เช่น ไฟล์ 835 หรือเมื่อผู้ใช้ป้อนข้อมูลจากเอกสาร Explanation of Benefits (EOB) ด้วยตนเอง. บันทึก ใช้เวลาประมวลผลหรือนำเข้าไฟล์คำแนะนำการชำระเงินที่เชื่อมโยงกับเคลม. ประเภทเหตุการณ์ explicit | |||
| ตัดหนี้สูญแล้ว | ดำเนินการติดตามทวงถามครบทุกวิธีแล้ว และถือว่ายอดคงเหลือในบัญชีเรียกเก็บไม่ได้ ยอดดังกล่าวจะถูกปรับเป็นศูนย์และจัดประเภทเป็นหนี้สูญ ซึ่งถือเป็นการสูญเสียรายได้ขั้นสุดท้าย. | ||
| เหตุผลที่สำคัญ กิจกรรมนี้เป็นเหตุการณ์ทางการเงินสำคัญที่แสดงถึงรายได้ที่สูญเสียไป การวิเคราะห์รายการตัดหนี้สูญจำเป็นต่อการทำความเข้าใจอัตราการเรียกเก็บเงินขั้นสุดท้ายและแหล่งที่มาของหนี้ที่เรียกคืนไม่ได้. แหล่งข้อมูล นี่คือธุรกรรมทางการเงินที่บันทึกไว้อย่างชัดเจน โดยทั่วไปเป็นรายการปรับยอดที่มีรหัสเหตุผลเฉพาะ เช่น 'Bad Debt Write-Off' หรือ 'Sent to Collections Agency'. บันทึก บันทึกวันที่ของธุรกรรมปรับยอดที่จัดประเภทเงินคงเหลือเป็นหนี้สูญ. ประเภทเหตุการณ์ explicit | |||
| บันทึกค่าบริการแล้ว | หมายถึงการบันทึกบริการ หัตถการ และเวชภัณฑ์ที่เรียกเก็บเงินได้ทั้งหมดอย่างเป็นทางการสำหรับการเข้ารับบริการของผู้ป่วย ขั้นตอนนี้แปลงกิจกรรมทางคลินิกให้เป็นรายการทางการเงินที่เรียกเก็บเงินได้. | ||
| เหตุผลที่สำคัญ การวิเคราะห์ช่วงเวลาระหว่างการให้บริการกับการบันทึกค่าบริการช่วยให้เห็นความล่าช้าที่อาจเกิดขึ้นในการรับรู้รายได้ ขั้นตอนนี้สำคัญต่อการตรวจสอบว่าบันทึกบริการที่เรียกเก็บเงินได้ครบถ้วนและป้องกันรายได้รั่วไหล. แหล่งข้อมูล ข้อมูลนี้อยู่ในตารางธุรกรรมค่าบริการหรือบันทึกทางการเงินในระบบเรียกเก็บเงินหรือระบบบัญชีผู้ป่วย รายการที่เรียกเก็บเงินได้แต่ละรายการควรมีเวลาที่สร้างรายการกำกับไว้. บันทึก ใช้วันที่สร้างรายการธุรกรรมค่าบริการที่เชื่อมโยงกับ billing event. ประเภทเหตุการณ์ explicit | |||
| ปรับปรุงบัญชีแล้ว | ธุรกรรมที่ไม่ใช่การชำระเงินซึ่งเปลี่ยนยอดบัญชี เช่น การปรับยอดตามสัญญา การตัดหนี้ยอดคงเหลือเล็กน้อย หรือส่วนลดเพื่อรักษาความสัมพันธ์ การปรับเหล่านี้จำเป็นต่อการกระทบยอดบัญชีตามสัญญากับผู้จ่ายเงินหรือนโยบายภายใน. | ||
| เหตุผลที่สำคัญ การปรับยอดเป็นปัจจัยหลักที่ทำให้รายได้เปลี่ยนแปลง การวิเคราะห์กิจกรรมและเหตุผลของการปรับยอดช่วยให้เข้าใจความสามารถในการทำกำไร ผลการดำเนินงานตามสัญญากับผู้จ่ายเงิน และความถูกต้องของรายได้. แหล่งข้อมูล ระบบบันทึกรายการเหล่านี้เป็นธุรกรรมทางการเงินแยกกันในบัญชีแยกประเภทผู้ป่วย โดยแต่ละรายการมีรหัสหรือประเภทธุรกรรมเฉพาะที่ระบุเหตุผลในการปรับยอด. บันทึก บันทึกวันที่ของธุรกรรมทางการเงินที่ไม่ใช่การรับชำระเงินหรือการเรียกเก็บค่าบริการ ซึ่งทำให้ยอดบัญชีเปลี่ยนแปลง. ประเภทเหตุการณ์ explicit | |||
| เริ่มแก้ไขเคลมที่ถูกปฏิเสธ | ผู้ใช้หรือเวิร์กโฟลว์อัตโนมัติเริ่มตรวจสอบและแก้ไขเคลมที่ถูกปฏิเสธ กิจกรรมนี้เป็นจุดเริ่มต้นของกระบวนการภายในเพื่อโต้แย้งการปฏิเสธและเรียกคืนรายได้ที่อาจสูญเสียไป. | ||
| เหตุผลที่สำคัญ กิจกรรมนี้เริ่มวงจรการแก้ไขเคลมที่ถูกปฏิเสธ การวิเคราะห์ช่วงเวลาระหว่างการปฏิเสธกับการเริ่มแก้ไขช่วยวัดความรวดเร็วในการตอบสนองของทีมจัดการเคลมที่ถูกปฏิเสธและระบุงานค้าง. แหล่งข้อมูล บันทึกข้อมูลนี้ได้จากการดำเนินการของผู้ใช้ในโมดูลจัดการเคลมที่ถูกปฏิเสธ การเปลี่ยนสถานะของเคลม หรือการมอบหมายเคลมที่ถูกปฏิเสธไปยังคิวงานของผู้ใช้. บันทึก บันทึกเวลาที่มีการเปิดเคลมที่ถูกปฏิเสธ มอบหมายเคลม หรือเปลี่ยนสถานะเป็น 'In Rework' เป็นครั้งแรก. ประเภทเหตุการณ์ explicit | |||
| เริ่มติดตามทวงถามแล้ว | บัญชีผู้ป่วยค้างชำระและเริ่มดำเนินการติดตามทวงถามเชิงรุก ตั้งแต่ส่งจดหมายแจ้งเตือนอัตโนมัติไปจนถึงส่งเรื่องให้เจ้าหน้าที่ติดตามหนี้ภายในหรือภายนอก. | ||
| เหตุผลที่สำคัญ ขั้นตอนนี้แสดงว่ามีการยกระดับการติดตามบัญชีลูกหนี้ค้างชำระ การติดตามกิจกรรมนี้ช่วยประเมินประสิทธิผลของกลยุทธ์การติดตามหนี้และผลการดำเนินงานของบริษัทติดตามหนี้. แหล่งข้อมูล โดยทั่วไปบันทึกเหตุการณ์นี้จากการเปลี่ยนประเภททางการเงินของบัญชี รหัสสถานะ หรือการมอบหมายบัญชีไปยังคิวงานติดตามหนี้หรือบริษัทติดตามหนี้โดยเฉพาะ. บันทึก อนุมานเหตุการณ์นี้จากเวลาครั้งแรกที่สถานะบัญชีเปลี่ยนเป็น 'Collections', 'Delinquent' หรือสถานะอื่นที่มีความหมายใกล้เคียงกัน. ประเภทเหตุการณ์ inferred | |||
| ลงรหัสเรียบร้อย | หมายถึงผู้ลงรหัสทางการแพทย์กำหนดรหัสทางคลินิกมาตรฐาน เช่น รหัส ICD หรือ CPT ให้กับค่าบริการที่บันทึกไว้ ขั้นตอนนี้ช่วยให้ผู้จ่ายเงินเข้าใจและพิจารณาบริการได้. | ||
| เหตุผลที่สำคัญ กิจกรรมนี้จำเป็นต่อความถูกต้องของเคลม และมักเป็นจุดที่เกิดคอขวด การวัดระยะเวลาของขั้นตอนลงรหัสช่วยระบุโอกาสเพิ่มประสิทธิภาพการทำงานของผู้ลงรหัสและลดการพักเคลมไว้. แหล่งข้อมูล โดยทั่วไปบันทึกเป็นการเปลี่ยนสถานะของ billing event หรือเวลาที่ทำเครื่องหมายว่างานเกี่ยวกับการลงรหัสในคิวงานเสร็จสมบูรณ์. บันทึก ระบุเวลาที่สถานะการลงรหัสของการเข้ารับบริการเปลี่ยนเป็น 'Complete' หรือเวลาที่อนุมัติรหัสสุดท้าย. ประเภทเหตุการณ์ explicit | |||
| ส่งเคลมอีกครั้งแล้ว | หลังจากถูกปฏิเสธ เคลมได้รับการแก้ไขและส่งกลับไปยังผู้จ่ายเงินเพื่อพิจารณาใหม่ นี่คือความพยายามครั้งที่สองในการขอรับชำระเงิน และเป็นการปิดวงจรการแก้ไขงานรอบแรก. | ||
| เหตุผลที่สำคัญ กิจกรรมนี้สำคัญต่อการทำความเข้าใจประสิทธิภาพของกระบวนการแก้ไขเคลมที่ถูกปฏิเสธ การติดตามการส่งเคลมซ้ำช่วยวัดระยะเวลาการแก้ไขงานและอัตราความสำเร็จของการอุทธรณ์. แหล่งข้อมูล ระบบบันทึกเหตุการณ์นี้เป็นการส่งเคลมรายการใหม่ที่เชื่อมโยงกับเคลมเดิมที่ถูกปฏิเสธ ให้ค้นหารายการส่งเคลมที่มีตัวบ่งชี้การแก้ไขหรือการส่งซ้ำ. บันทึก ระบุธุรกรรมการส่งเคลมที่อ้างอิง Claim ID ที่เคยส่งไปก่อนหน้า หรือมีธงระบุการส่งซ้ำ. ประเภทเหตุการณ์ explicit | |||
| ส่งใบแจ้งยอดให้ผู้ป่วยแล้ว | หลังจากบันทึกการชำระเงินและการปรับยอดจากประกันทั้งหมดแล้ว ระบบจะสร้างใบแจ้งยอดและส่งให้ผู้ป่วยเพื่อเรียกเก็บส่วนที่ผู้ป่วยต้องชำระ ขั้นตอนนี้เปลี่ยนจุดเน้นของการติดตามเก็บเงินจากผู้จ่ายเงินที่เป็นสถาบันมาเป็นผู้ป่วยแต่ละราย. | ||
| เหตุผลที่สำคัญ กิจกรรมนี้เริ่มส่วนการชำระเงินด้วยตนเองของวงจรรายได้ การติดตามช่วยวิเคราะห์ประสิทธิผลของการเรียกเก็บเงินจากผู้ป่วยและวัดระยะเวลาจนถึงการเรียกเก็บเงิน. แหล่งข้อมูล โมดูลเรียกเก็บเงินจากผู้ป่วยหรือโมดูลสื่อสารจะบันทึกเหตุการณ์นี้ไว้อย่างชัดเจน ระบบควรบันทึกวันที่สร้างหรือส่งใบแจ้งยอดแต่ละฉบับ. บันทึก ใช้วันที่สร้างหรือวันที่ส่งจากบันทึกประวัติใบแจ้งยอดผู้ป่วย. ประเภทเหตุการณ์ explicit | |||
| สร้างเคลมแล้ว | ระบบสร้างเคลมเรียกเก็บเงินอย่างเป็นทางการ โดยรวบรวมค่าบริการ รหัส และข้อมูลประชากรศาสตร์ให้อยู่ในรูปแบบมาตรฐาน นี่เป็นขั้นตอนเตรียมการก่อนส่งเคลมให้ผู้จ่ายเงิน. | ||
| เหตุผลที่สำคัญ ขั้นตอนนี้หมายถึงเวลาที่ใบแจ้งหนี้พร้อมเรียกเก็บเงิน การวิเคราะห์ช่วงเวลาตั้งแต่จุดนี้จนถึงการส่งเคลมช่วยระบุความล่าช้าจากระบบหรือการรวมรายการเป็นชุด ซึ่งทำให้กระบวนการเรียกเก็บเงินช้าลง. แหล่งข้อมูล ระบบบันทึกเหตุการณ์นี้โดยอัตโนมัติในตารางหรือไฟล์เคลม โดยควรมีเวลาสร้างส่วนหัวของเคลมที่ชัดเจน. บันทึก ใช้เวลาที่สร้างระเบียนเคลมหลักซึ่งเชื่อมโยงกับ billing event. ประเภทเหตุการณ์ explicit | |||
คู่มือการดึงข้อมูล
วิธีดึงข้อมูลแตกต่างกันไปตามระบบ หากต้องการคำแนะนำโดยละเอียด
พร้อมเริ่มต้นหรือยัง?
เลือกคู่มือการดึงข้อมูลเฉพาะระบบด้านล่างเพื่อดูวิธีส่งออกข้อมูลโดยละเอียด หรือใช้เทมเพลตทั่วไปนี้เป็นจุดเริ่มต้นสำหรับระบบอื่นๆ.
เริ่มปรับปรุงการจัดการวงจรรายได้ของคุณวันนี้
ค้นพบข้อมูลเชิงลึก ลดการปฏิเสธเคลม และเร่งกระแสเงินสดในทุกระบบ.
ไม่ต้องใช้บัตรเครดิต • เริ่มต้นใช้งานได้ในไม่กี่นาที