เทมเพลตข้อมูลการจัดการวงจรรายได้ของคุณ
เทมเพลตข้อมูลการจัดการวงจรรายได้ของคุณ
- คุณลักษณะที่แนะนำให้รวบรวม
- กิจกรรมสำคัญที่ควรติดตาม
- แนวทางการดึงข้อมูล
คุณลักษณะของการจัดการวงจรรายได้
| ชื่อ | คำอธิบาย | ||
|---|---|---|---|
| ชื่อกิจกรรม ActivityName | ชื่อเหตุการณ์หรืองานเฉพาะที่เกิดขึ้นในกระบวนการจัดการวงจรรายได้. | ||
| คำอธิบาย ชื่อกิจกรรมระบุขั้นตอนหนึ่งในกระบวนการวงจรรายได้ เช่น 'ส่งเคลมให้ผู้จ่ายเงินแล้ว' หรือ 'ได้รับชำระเงินแล้ว' ข้อมูลนี้เป็นพื้นฐานสำคัญของ process mining เพราะใช้กำหนดโหนดในแผนผังกระบวนการ การวิเคราะห์ลำดับและความถี่ของกิจกรรมช่วยให้องค์กรเห็นภาพขั้นตอนการทำงานจริง ระบุจุดที่ต่างจากวิธีปฏิบัติมาตรฐาน และค้นหารูปแบบการแก้ไขงานซ้ำที่พบบ่อย การวิเคราะห์นี้ช่วยให้เข้าใจปัญหาด้านประสิทธิภาพและการปฏิบัติตามข้อกำหนดของกระบวนการ. เหตุผลที่สำคัญ ข้อมูลนี้ระบุแต่ละขั้นตอนของกระบวนการ เป็นพื้นฐานของแผนผังกระบวนการและการวิเคราะห์ขั้นตอนการทำงานทุกรูปแบบ. แหล่งข้อมูล โดยทั่วไปได้จากบันทึกเหตุการณ์ ระเบียนการเปลี่ยนสถานะ หรือรหัสธุรกรรมเฉพาะในตารางการปฏิบัติงานของ Optum360. ตัวอย่าง สร้างเคลมแล้วส่งเคลมให้ผู้จ่ายเงินแล้วได้รับชำระเงินแล้วได้รับแจ้งการปฏิเสธเคลมแล้วปิดบัญชีแล้ว | |||
| เวลาเกิดเหตุการณ์ EventTime | เวลาที่ระบุว่ากิจกรรมหรือเหตุการณ์หนึ่งเกิดขึ้นเมื่อใด. | ||
| คำอธิบาย เวลาเกิดเหตุการณ์คือเวลาที่กำกับกิจกรรมแต่ละรายการ โดยระบุวันและเวลาที่เกิดขึ้นอย่างแม่นยำ ข้อมูลด้านเวลานี้จำเป็นต่อการเรียงลำดับเหตุการณ์ของแต่ละเคสตามลำดับเวลา ในการวิเคราะห์ ใช้เวลาเกิดเหตุการณ์คำนวณระยะเวลาระหว่างกิจกรรม วัดระยะเวลาของเคส และระบุคอขวดที่มีเวลารอสะสมนาน ข้อมูลนี้เป็นพื้นฐานของการวิเคราะห์กระบวนการและวัดผลการดำเนินงานตามเวลา. เหตุผลที่สำคัญ เวลานี้สำคัญต่อการเรียงลำดับเหตุการณ์ให้ถูกต้องและคำนวณตัวชี้วัดตามระยะเวลาทั้งหมด เช่น ระยะเวลาของกระบวนการและคอขวด. แหล่งข้อมูล โดยทั่วไปข้อมูลนี้จัดเก็บไว้พร้อมกับระเบียนธุรกรรมหรือการเปลี่ยนสถานะแต่ละรายการในตารางฐานข้อมูลของ Optum360. ตัวอย่าง 2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:22:00Z | |||
| เหตุการณ์การเรียกเก็บเงิน BillingEvent | รหัสเฉพาะของการให้บริการหรือส่งมอบผลิตภัณฑ์หนึ่งรายการที่ทำให้เกิดค่าใช้จ่าย ใช้เป็น Case ID หลัก. | ||
| คำอธิบาย เหตุการณ์การเรียกเก็บเงินใช้เป็นรหัสเคสหลักที่เชื่อมโยงกิจกรรมทั้งหมดของบริการหรือผลิตภัณฑ์หนึ่งรายการที่ทำให้เกิดค่าใช้จ่าย จึงติดตามวงจรการสร้างรายได้และการเรียกเก็บเงินของรายการหรือบริการที่เรียกเก็บเงินได้แต่ละรายการได้อย่างครบถ้วน การวิเคราะห์ process mining โดยใช้เหตุการณ์การเรียกเก็บเงินช่วยให้องค์กรเห็นเส้นทางทั้งหมดตั้งแต่ให้บริการจนได้รับชำระเงินหรือปิดบัญชี มุมมองนี้ช่วยระบุคอขวด วัดระยะเวลาของกระบวนการ และทำความเข้าใจความแตกต่างในการจัดการเคลมหรือใบแจ้งหนี้แต่ละประเภท. เหตุผลที่สำคัญ นี่คือ Case ID หลักที่เชื่อมโยงกิจกรรมทั้งหมดในวงจรรายได้เข้าด้วยกัน ทำให้วิเคราะห์กระบวนการได้ครบตั้งแต่ต้นจนจบ. แหล่งข้อมูล นี่คือคีย์หลักที่เชื่อมโยงระเบียนในตารางเรียกเก็บเงินและเคลมหลักของ Optum360 โปรดดูชื่อและฟิลด์ของตารางที่ใช้ในเอกสาร Optum360. ตัวอย่าง BE-2023-0012345BE-2023-0012346BE-2023-0012347 | |||
| แผนกเรียกเก็บเงิน BillingDepartment | แผนกหรือทีมภายในที่ดูแลหรือดำเนินกิจกรรมเรียกเก็บเงิน. | ||
| คำอธิบาย แอตทริบิวต์แผนกเรียกเก็บเงินใช้ระบุทีมงานหรือหน่วยงานภายในฝ่ายปฏิบัติการด้านวงจรรายได้ที่รับผิดชอบกิจกรรมหนึ่งๆ เช่น ทีมที่ดูแลการลงรหัส การส่งเคลม และการจัดการเคลมที่ถูกปฏิเสธอาจเป็นคนละทีมกัน แอตทริบิวต์นี้จำเป็นต่อการเปรียบเทียบผลการดำเนินงานตามที่แดชบอร์ด 'เกณฑ์เปรียบเทียบผลการดำเนินงานของแผนกเรียกเก็บเงิน' แสดงไว้ ผู้บริหารสามารถเปรียบเทียบประสิทธิภาพ ความเร็ว และความถูกต้องของแต่ละทีม ระบุแนวทางปฏิบัติที่ได้ผล และจัดสรรทรัพยากรเพื่อแก้ไขจุดที่ผลการดำเนินงานยังไม่เป็นไปตามเป้าหมาย. เหตุผลที่สำคัญ ช่วยเปรียบเทียบผลการดำเนินงานของทีมเรียกเก็บเงินแต่ละทีม เพื่อระบุกลุ่มที่ทำผลงานได้ดีและจุดที่ควรปรับปรุง. แหล่งข้อมูล ข้อมูลนี้อาจอนุมานจากผู้ใช้ที่ทำงานนั้น หรือจากฟิลด์ในบัญชีที่ระบุผู้รับผิดชอบ โปรดดูเอกสารประกอบของ Optum360. ตัวอย่าง สำนักงานเรียกเก็บเงินส่วนกลางทีมจัดการเคลมที่ถูกปฏิเสธแผนกลงรหัสบริการด้านการเงินสำหรับผู้ป่วย | |||
| ยอดปรับปรุง AdjustedAmount | มูลค่าของหนี้สูญ การปรับยอดตามสัญญา หรือการแก้ไขยอดเรียกเก็บ. | ||
| คำอธิบาย ยอดปรับปรุงคือส่วนของยอดเรียกเก็บที่คาดว่าจะเรียกเก็บไม่ได้ เนื่องจากข้อตกลงกับผู้ชำระเงิน การแก้ไขการเรียกเก็บ หรือการตัดหนี้สูญอื่นๆ ซึ่งทำให้รายได้ลดลงโดยตรง แอตทริบิวต์นี้สำคัญต่อแดชบอร์ด 'ผลกระทบจากการปรับลดรายได้' และ KPI 'อัตราการปรับลดรายได้' การวิเคราะห์ยอดปรับปรุงช่วยให้เห็นผลกระทบทางการเงินจากสัญญากับผู้ชำระเงิน และค้นหาโอกาสลดรายได้ที่สูญเสียไปด้วยการเรียกเก็บเงินให้ถูกต้องขึ้นหรือเจรจาสัญญาใหม่. เหตุผลที่สำคัญ วัดรายได้ที่สูญเสียไปโดยตรง และจำเป็นต่อการคำนวณ KPI ผลการดำเนินงานทางการเงินและทำความเข้าใจความสามารถในการทำกำไร. แหล่งข้อมูล ข้อมูลนี้อยู่ในระเบียนธุรกรรมการปรับปรุงภายในระบบการเงินของ Optum360. ตัวอย่าง 30.00250.2510.00 | |||
| ยอดเรียกเก็บ BilledAmount | มูลค่ารวมของค่าบริการทั้งหมดที่ส่งไปพร้อมเคลมหรือใบแจ้งหนี้. | ||
| คำอธิบาย ยอดเรียกเก็บคือค่าบริการรวมก่อนหักการชำระเงิน การปรับยอด หรือการตัดหนี้สูญ โดยเป็นมูลค่าเริ่มต้นของลูกหนี้สำหรับรายการเรียกเก็บเงินนั้น แอตทริบิวต์นี้เป็นข้อมูลพื้นฐานสำหรับการวิเคราะห์ทางการเงินด้วย process mining ใช้คำนวณ KPI สำคัญ เช่น อัตราการปรับลดรายได้ และแบ่งกรณีตามมูลค่าเพื่อดูว่าเคลมมูลค่าสูงมีขั้นตอนต่างจากเคลมมูลค่าต่ำหรือใช้เวลานานกว่าหรือไม่. เหตุผลที่สำคัญ ให้ข้อมูลทางการเงินของแต่ละกรณี ช่วยวิเคราะห์ตามมูลค่าและคำนวณ KPI ทางการเงินที่สำคัญ. แหล่งข้อมูล ฟิลด์นี้เป็นข้อมูลมาตรฐานในระเบียนเคลมหรือบัญชีผู้ป่วยทุกบัญชีในตารางการเงินของ Optum360. ตัวอย่าง 150.001250.7585.50 | |||
| รหัสผู้ชำระเงิน PayerId | รหัสเฉพาะของบริษัทประกันหรือผู้ชำระเงินที่รับผิดชอบการเคลม. | ||
| คำอธิบาย รหัสผู้ชำระเงินใช้ระบุบริษัทประกัน โครงการภาครัฐ เช่น Medicare หรือ Medicaid หรือหน่วยงานอื่นที่รับผิดชอบการจ่ายเงินตามเคลมโดยเฉพาะ ผู้ชำระเงินแต่ละรายมักมีกฎ ข้อกำหนดในการส่งเคลม และรูปแบบการจ่ายเงินที่แตกต่างกัน การวิเคราะห์กระบวนการตามรหัสผู้ชำระเงินมีความสำคัญต่อ RCM เพราะช่วยระบุผู้ชำระเงินที่ใช้เวลาจ่ายนานที่สุด มีอัตราปฏิเสธเคลมสูงที่สุด หรือมีกระบวนการอุทธรณ์ซับซ้อนที่สุด ข้อมูลนี้ช่วยให้ฝ่ายเรียกเก็บเงินปรับวิธีดำเนินงานให้เหมาะกับผู้ชำระเงินแต่ละราย เพื่อเร่งการเรียกเก็บเงินและลดภาระงานธุรการ. เหตุผลที่สำคัญ การแบ่งกลุ่มกระบวนการตามผู้ชำระเงินช่วยระบุได้ว่ารายใดทำให้เกิดความล่าช้าหรือการปฏิเสธเคลม และช่วยให้ปรับปรุงการบริหารจัดการผู้ชำระเงินได้ตรงจุด. แหล่งข้อมูล ข้อมูลนี้จัดเก็บไว้ในระเบียนเคลมแต่ละรายการใน Optum360 โปรดดูเอกสารประกอบของ Optum360 เพื่อค้นหาชื่อตารางและฟิลด์ที่เกี่ยวข้องกับผู้ชำระเงิน. ตัวอย่าง PAYER-AETNAPAYER-BCBS-MAPAYER-MEDICAREPAYER-UHC | |||
| รหัสผู้ป่วย PatientId | รหัสเฉพาะของผู้ป่วยที่ได้รับบริการ. | ||
| คำอธิบาย รหัสผู้ป่วยเป็นรหัสเฉพาะที่กำหนดให้ผู้ป่วยแต่ละรายในระบบสุขภาพ ใช้เชื่อมโยงเหตุการณ์การเรียกเก็บเงินหลายรายการกับผู้ป่วยรายเดียว เพื่อให้วิเคราะห์โดยยึดผู้ป่วยเป็นหลักได้ นักวิเคราะห์ใช้รหัสผู้ป่วยตรวจสอบรูปแบบที่เกี่ยวข้องกับผู้ป่วยแต่ละราย เช่น การกลับเข้ารับการรักษาซ้ำบ่อยครั้งหรือประวัติการถูกปฏิเสธเคลม นอกจากนี้ยังใช้แบ่งกลุ่มกระบวนการตามข้อมูลประชากรหรือประวัติผู้ป่วย เพื่อค้นหาข้อมูลเชิงลึกที่ช่วยปรับปรุงประสบการณ์ด้านการเงินของผู้ป่วยได้. เหตุผลที่สำคัญ ช่วยวิเคราะห์โดยยึดผู้ป่วยเป็นหลัก ทำให้เข้าใจเส้นทางด้านการเงินตั้งแต่ต้นจนจบและค้นหารูปแบบที่พบในกลุ่มผู้ป่วยเฉพาะได้. แหล่งข้อมูล รหัสนี้เป็นฟิลด์หลักในข้อมูลหลักผู้ป่วยและตารางธุรกรรมของ Optum360 โปรดดูรายละเอียดในเอกสาร Optum360. ตัวอย่าง PAT-98765PAT-98766PAT-98767 | |||
| รหัสเหตุผลการปฏิเสธเคลม DenialReasonCode | รหัสมาตรฐานจากผู้ชำระเงินที่อธิบายสาเหตุการปฏิเสธเคลม. | ||
| คำอธิบาย เมื่อผู้ชำระเงินปฏิเสธเคลม จะระบุรหัสเหตุผลการปฏิเสธเคลมเพื่ออธิบายปัญหา เช่น 'บริการนี้ไม่อยู่ในความคุ้มครอง' หรือ 'ส่งเคลมซ้ำ' รหัสเหล่านี้ช่วยให้เข้าใจสาเหตุที่แท้จริงของความล่าช้าด้านรายได้และงานแก้ไขซ้ำ ทีมจัดการเคลมที่ถูกปฏิเสธสามารถใช้รหัสเหล่านี้จัดลำดับความสำคัญของงาน ระบุแนวโน้ม และดำเนินการแก้ไขได้ เช่น หากพบการปฏิเสธบ่อยครั้งเพราะ 'ข้อมูลไม่ครบ' อาจเป็นสัญญาณว่ามีปัญหาในขั้นตอนจัดทำเคลม การวิเคราะห์นี้ช่วยลดอัตราการปฏิเสธเคลมและเร่งกระแสเงินสด. เหตุผลที่สำคัญ ระบุสาเหตุที่แท้จริงของการปฏิเสธเคลม ช่วยให้ดำเนินการแก้ไขได้ตรงจุดเพื่อป้องกันการปฏิเสธซ้ำและลดงานแก้ไขที่มีต้นทุนสูง. แหล่งข้อมูล รหัสนี้อยู่ในไฟล์ Electronic Remittance Advice (ERA) ที่ได้รับจากผู้ชำระเงิน และจัดเก็บไว้ในโมดูลจัดการเคลมของ Optum360. ตัวอย่าง CO-16: เคลมหรือบริการมีข้อมูลไม่ครบPR-97: สิทธิประโยชน์สำหรับบริการนี้รวมอยู่ในการจ่ายเงินหรือวงเงินของบริการหรือหัตถการอื่นแล้วOA-18: เคลมหรือบริการซ้ำ | |||
| เป็นงานแก้ไขซ้ำหรือไม่ IsRework | ตัวบ่งชี้ว่ากิจกรรมเป็นส่วนหนึ่งของวงจรการทำงานซ้ำหรือไม่ เช่น การจัดการเคลมที่ถูกปฏิเสธหรือการอุทธรณ์. | ||
| คำอธิบาย ฟิลด์ 'เป็นงานแก้ไขซ้ำหรือไม่' เป็นค่าบูลีนที่ระบุกิจกรรมซึ่งถือเป็นงานแก้ไขซ้ำที่ไม่เพิ่มมูลค่า เช่น 'เริ่มแก้ไขเคลมที่ถูกปฏิเสธ' หรือ 'ส่งคำอุทธรณ์' กิจกรรมเหล่านี้มักเกิดขึ้นเมื่อกระบวนการเบี่ยงเบนจากเส้นทางที่ควรเป็น แอตทริบิวต์นี้ช่วยวัดปริมาณงานแก้ไขซ้ำ ซึ่งบ่งชี้ถึงความไม่มีประสิทธิภาพและต้นทุนโดยตรง ใช้คำนวณ KPI 'อัตรางานแก้ไขซ้ำจากข้อผิดพลาดในการเรียกเก็บเงิน' และช่วยให้แดชบอร์ด 'ระบุคอขวดและวงจรงานแก้ไขซ้ำ' กรองและแสดงวงจรที่ไม่มีประสิทธิภาพเหล่านี้ได้ง่ายขึ้น. เหตุผลที่สำคัญ ช่วยวัดความไม่มีประสิทธิภาพของกระบวนการ โดยทำเครื่องหมายกิจกรรมที่เป็นงานแก้ไขซ้ำ ทำให้วัดและจัดการงานที่สูญเปล่าได้ง่ายขึ้น. แหล่งข้อมูล โดยทั่วไปจะกำหนดค่านี้ด้วยตรรกะทางธุรกิจในเครื่องมือ process mining ตัวอย่างเช่น อาจทำเครื่องหมายกิจกรรมใดๆ ที่เกิดหลังเหตุการณ์ 'ได้รับแจ้งการปฏิเสธเคลม' ว่าเป็นงานแก้ไขซ้ำ. ตัวอย่าง truefalse | |||
| ผู้ใช้ User | รหัสระบุผู้ใช้หรือระบบที่ดำเนินกิจกรรม. | ||
| คำอธิบาย แอตทริบิวต์ผู้ใช้ระบุบุคคล ทีม หรือบอตอัตโนมัติที่รับผิดชอบดำเนินกิจกรรมหนึ่งๆ จึงช่วยวิเคราะห์ผลการดำเนินงานในระดับบุคคลหรือกลุ่มได้ การทราบว่าผู้ใช้หรือทีมใดดำเนินการมีประโยชน์ต่อการประเมินผลิตภาพ คุณภาพ และการปฏิบัติตามขั้นตอนมาตรฐาน อีกทั้งช่วยระบุความต้องการด้านการฝึกอบรมหรือชื่นชมบุคคลและทีมที่ทำผลงานได้ดี และแยกงานที่ทำด้วยตนเองออกจากงานที่ระบบอัตโนมัติจัดการ. เหตุผลที่สำคัญ ระบุผู้รับผิดชอบในแต่ละขั้นตอนของกระบวนการ และช่วยวิเคราะห์ผลการดำเนินงานรายบุคคลหรือรายทีม ซึ่งเป็นข้อมูลสำคัญสำหรับการบริหารทรัพยากรและการฝึกอบรม. แหล่งข้อมูล โดยทั่วไปจะบันทึกรหัสผู้ใช้ไว้ในบันทึกการตรวจสอบหรือประวัติธุรกรรมของระเบียนใน Optum360. ตัวอย่าง j.doem.smithAutoBillerBots.jones | |||
| ผู้ให้บริการ ServiceProvider | แพทย์ แผนก หรือสถานพยาบาลที่ให้บริการซึ่งเรียกเก็บเงินได้. | ||
| คำอธิบาย แอตทริบิวต์นี้ระบุผู้ให้บริการที่รับผิดชอบการให้บริการโดยเฉพาะ เช่น แพทย์ นักบำบัด หรือแผนกในโรงพยาบาล ผู้ให้บริการแต่ละรายอาจมีรูปแบบการเรียกเก็บเงินหรือแนวทางจัดทำเอกสารที่ส่งผลต่อวงจรรายได้แตกต่างกัน การวิเคราะห์ตามผู้ให้บริการช่วยระบุปัญหาที่เกี่ยวข้องกับการบันทึกค่าบริการ ความถูกต้องของการลงรหัส หรือคุณภาพเอกสาร ซึ่งอาจเกิดขึ้นตั้งแต่จุดให้บริการ ข้อมูลนี้ยังช่วยชี้โอกาสในการให้ความรู้แก่ผู้ให้บริการหรือปรับปรุงกระบวนการ เพื่อให้จัดทำเคลมได้ถูกต้องตั้งแต่ต้น. เหตุผลที่สำคัญ ช่วยสืบหาต้นตอของปัญหาการเรียกเก็บเงิน และให้ข้อเสนอแนะพร้อมจัดอบรมบุคลากรทางคลินิกได้ตรงจุด เพื่อปรับปรุงการบันทึกค่าบริการและการจัดทำเอกสาร. แหล่งข้อมูล ข้อมูลนี้เป็นส่วนสำคัญของระเบียนค่าบริการหรือเคลมใน Optum360 และมักเชื่อมโยงกับข้อมูลหลักของผู้ให้บริการ. ตัวอย่าง แพทย์หญิง Emily Carterแผนกรังสีวิทยาศัลยกรรมทั่วไปกายภาพบำบัด | |||
| ยอดชำระแล้ว PaidAmount | มูลค่ารวมที่ได้รับชำระจากผู้ชำระเงินและผู้ป่วยสำหรับบริการที่เรียกเก็บเงิน. | ||
| คำอธิบาย ยอดชำระแล้วคือผลรวมของการชำระเงินทั้งหมดที่บันทึกเข้าบัญชีสำหรับรายการเรียกเก็บเงินหนึ่งๆ ซึ่งแสดงถึงเงินสดที่ได้รับจริง และเป็นตัวชี้วัดหลักของความสำเร็จในวงจรรายได้ การติดตามยอดชำระแล้วในการวิเคราะห์กระบวนการเป็นสิ่งจำเป็นต่อการทำความเข้าใจกระแสเงินสดและผลการดำเนินงานทางการเงินโดยรวม นอกจากนี้ยังใช้วิเคราะห์ความเร็วในการรับชำระ และเปรียบเทียบยอดเรียกเก็บกับยอดที่ได้รับ เพื่อค้นหาปัญหาการชำระเงินไม่ครบหรือหนี้ที่เรียกเก็บไม่ได้. เหตุผลที่สำคัญ แสดงเงินสดที่ได้รับจริง เป็นตัวชี้วัดผลลัพธ์สำคัญของกระบวนการ RCM และจำเป็นต่อการวิเคราะห์กระแสเงินสด. แหล่งข้อมูล โดยทั่วไปข้อมูลนี้จัดเก็บในตารางธุรกรรมการชำระเงิน หรือสรุปไว้ในระดับบัญชีใน Optum360. ตัวอย่าง 120.001000.500.00 | |||
| รหัสบริการ ServiceCode | รหัสหัตถการ เช่น CPT หรือ HCPCS ที่ใช้ระบุบริการที่ให้โดยเฉพาะ. | ||
| คำอธิบาย รหัสบริการเป็นรหัสทางการแพทย์มาตรฐานที่ระบุหัตถการหรือบริการที่ผู้ป่วยได้รับอย่างชัดเจน ต้องใช้รหัสเหล่านี้ในการเรียกเก็บเงิน และเป็นปัจจัยหลักที่กำหนดการเบิกจ่าย การวิเคราะห์กระบวนการตามรหัสบริการอาจเผยให้เห็นว่าหัตถการบางประเภทถูกปฏิเสธบ่อยกว่า ต้องใช้เอกสารประกอบมากกว่า หรือมีรอบการจ่ายเงินนานกว่า ข้อมูลนี้ช่วยให้เข้าใจปัญหาในกระบวนการได้ละเอียดขึ้น และใช้กำหนดแนวทางการลงรหัสและเรียกเก็บเงินสำหรับบริการแต่ละประเภทได้. เหตุผลที่สำคัญ ช่วยวิเคราะห์ตามประเภทบริการทางการแพทย์ เพื่อค้นหารูปแบบการปฏิเสธเคลมหรือความล่าช้าในการชำระเงินที่เกี่ยวข้องกับหัตถการบางประเภท. แหล่งข้อมูล รหัสนี้เป็นข้อมูลพื้นฐานในระเบียนบันทึกค่าบริการและรายละเอียดเคลมใน Optum360. ตัวอย่าง 992137104527447 | |||
| ระบบต้นทาง SourceSystem | ระบบหรือแอปพลิเคชันต้นทางที่บันทึกข้อมูลเหตุการณ์. | ||
| คำอธิบาย ข้อมูลนี้ระบุระบบต้นทางที่ดึงข้อมูลของเหตุการณ์นั้น ในสภาพแวดล้อม IT ที่ซับซ้อน ข้อมูล RCM อาจมาจากแพลตฟอร์ม Optum360 หลัก ระบบเวชระเบียนอิเล็กทรอนิกส์ (EHR) ที่เชื่อมต่อกับระบบอื่น clearinghouse หรือพอร์ทัลผู้ป่วย การทราบระบบต้นทางช่วยตรวจสอบความถูกต้องของข้อมูล แก้ปัญหาการเชื่อมต่อ และวิเคราะห์ความแตกต่างของกระบวนการที่อาจเกิดจากการทำงานของระบบหรือวิธีป้อนข้อมูลที่ต่างกัน. เหตุผลที่สำคัญ ระบุแหล่งที่มาของข้อมูล ซึ่งสำคัญต่อการกำกับดูแลข้อมูล การประเมินคุณภาพ และการทำความเข้าใจความแตกต่างของกระบวนการระหว่างระบบ. แหล่งข้อมูล อาจเป็นค่าคงที่ที่กำหนดไว้ตอนดึงข้อมูล หรือเป็นฟิลด์ในตารางต้นทางที่ระบุแหล่งที่มาของข้อมูล. ตัวอย่าง Optum360EHR-InterfaceClearinghouse-APIPatient-Portal | |||
| ระยะเวลาดำเนินการกรณี CaseDuration | ระยะเวลารวมของวงจรการเรียกเก็บเงิน ตั้งแต่กิจกรรมแรกจนถึงกิจกรรมสุดท้าย. | ||
| คำอธิบาย ระยะเวลาดำเนินการกรณีวัดเวลาตั้งแต่เหตุการณ์แรกจนถึงเหตุการณ์สุดท้ายของรายการเรียกเก็บเงินหนึ่งรายการ เป็น KPI ภาพรวมที่สำคัญสำหรับประเมินประสิทธิภาพของกระบวนการ ตัวชี้วัดนี้ใช้กับแดชบอร์ด 'ภาพรวมระยะเวลาตั้งแต่ต้นจนจบของวงจร RCM' และ KPI 'ระยะเวลาเฉลี่ยของวงจร RCM' การติดตามตัวชี้วัดนี้อย่างต่อเนื่องช่วยให้ผู้บริหารเห็นผลของโครงการปรับปรุงที่มีต่อวงจรรายได้ทั้งหมด. เหตุผลที่สำคัญ แสดงระยะเวลาตั้งแต่ต้นจนจบของกระบวนการ เป็น KPI สำคัญสำหรับวัดความเร็วและประสิทธิภาพโดยรวมของกระบวนการ. แหล่งข้อมูล คำนวณโดยนำเวลาประทับของเหตุการณ์แรกมาลบจากเวลาประทับของเหตุการณ์สุดท้าย สำหรับรหัสกรณี 'BillingEvent' แต่ละรายการ. ตัวอย่าง 30 วัน95 วัน45 วัน | |||
| เวลาสิ้นสุด EndTime | เวลาที่ระบุว่ากิจกรรมเสร็จสิ้นเมื่อใด. | ||
| คำอธิบาย เวลาสิ้นสุดระบุว่ากิจกรรมเสร็จเมื่อใด ส่วนเวลาเริ่มต้นระบุว่าเหตุการณ์เริ่มขึ้นเมื่อใด เวลาสิ้นสุดจำเป็นต่อการคำนวณระยะเวลาของกิจกรรมที่มีช่วงเวลาประมวลผลชัดเจน เช่น กิจกรรม 'เริ่มแก้ไขเคลมที่ถูกปฏิเสธ' และเวลาที่แก้ไขเสร็จ การเปรียบเทียบเวลาเริ่มต้นกับเวลาสิ้นสุดของกิจกรรมช่วยคำนวณเวลาประมวลผล และแยกเวลาทำงานจริงออกจากเวลาว่างหรือเวลารอระหว่างกิจกรรม ทำให้เห็นประสิทธิภาพของกระบวนการได้ละเอียดขึ้น. เหตุผลที่สำคัญ ช่วยคำนวณเวลาประมวลผลของกิจกรรมได้อย่างแม่นยำ และแยกเวลาทำงานจริงออกจากเวลารอในกระบวนการ. แหล่งข้อมูล บางกิจกรรมอาจมีฟิลด์เวลาสิ้นสุดแยกต่างหากในระบบต้นทาง ส่วนกิจกรรมอื่นอาจต้องอนุมานจากเวลาเริ่มต้นของกิจกรรมถัดไป. ตัวอย่าง 2023-10-26T10:15:00Z2023-10-26T11:45:00Z2023-10-27T15:00:00Z | |||
| สถานะบัญชี AccountStatus | สถานะปัจจุบันของบัญชีเรียกเก็บเงินในวงจรรายได้. | ||
| คำอธิบาย สถานะบัญชีแสดงภาพรวมว่ารายการเรียกเก็บเงินอยู่ในขั้นตอนไหนของกระบวนการ เช่น 'รอผู้ชำระเงิน' 'ชำระครบแล้ว' หรือ 'อยู่ระหว่างติดตามหนี้' แอตทริบิวต์นี้ช่วยให้เข้าใจกิจกรรมที่กำลังดำเนินการ คุณสามารถใช้สถานะนี้กรองและแบ่งกลุ่มกรณี เพื่อเน้นดูขั้นตอนเฉพาะของกระบวนการได้ เช่น การวิเคราะห์บัญชีที่ 'อยู่ระหว่างติดตามหนี้' ช่วยให้เข้าใจสาเหตุและปริมาณงานในขั้นตอนที่มีต้นทุนสูงนี้ และนำข้อมูลไปใช้กับแดชบอร์ด 'ปริมาณและสาเหตุของกิจกรรมติดตามหนี้'. เหตุผลที่สำคัญ แสดงสถานะปัจจุบันของกรณีในภาพรวม ช่วยกรองและวิเคราะห์กลุ่มกรณีเฉพาะ เช่น กรณีที่อยู่ระหว่างติดตามหนี้. แหล่งข้อมูล โดยทั่วไปข้อมูลนี้เป็นฟิลด์สรุปในระเบียนบัญชีผู้ป่วยหลักหรือระเบียนเคลมใน Optum360. ตัวอย่าง เปิดอยู่รอผู้ชำระเงินชำระครบแล้วอยู่ระหว่างติดตามหนี้ปิดแล้ว | |||
| อัปเดตข้อมูลล่าสุด LastDataUpdate | เวลาที่ดึงหรือรีเฟรชข้อมูลจากระบบต้นทางครั้งล่าสุด. | ||
| คำอธิบาย ข้อมูลนี้บันทึกวันและเวลาที่ดึงข้อมูลจากระบบต้นทางครั้งล่าสุดและโหลดเข้าสู่เครื่องมือ process mining ช่วยให้ทราบว่าข้อมูลที่กำลังวิเคราะห์เป็นข้อมูลใหม่เพียงใด นักวิเคราะห์และผู้ใช้ทางธุรกิจจำเป็นต้องทราบว่ากำลังดูข้อมูลล่าสุดหรือไม่ ข้อมูลนี้ช่วยให้เข้าใจความล่าช้าของข้อมูลและเป็นเมทาดาทาสำคัญสำหรับโครงการวิเคราะห์. เหตุผลที่สำคัญ ช่วยให้ทราบว่าข้อมูลเป็นปัจจุบันเพียงใด เพื่อให้ผู้ใช้เข้าใจว่าผลการวิเคราะห์อ้างอิงข้อมูลล่าสุดแค่ไหน. แหล่งข้อมูล โดยทั่วไป กระบวนการดึง แปลง และโหลดข้อมูล (ETL) จะสร้างและจัดเก็บเวลานี้. ตัวอย่าง 2023-11-01T02:00:00Z2023-11-02T02:00:00Z | |||
กิจกรรมในการจัดการวงจรรายได้
| กิจกรรม | คำอธิบาย | ||
|---|---|---|---|
| ได้รับข้อมูลบริการ | ระบุจุดเริ่มต้นของเหตุการณ์การเรียกเก็บเงิน เมื่อได้รับข้อมูลบริการทางคลินิกจากเวชระเบียนอิเล็กทรอนิกส์ (EHR) หรือระบบต้นทางอื่น โดยทั่วไป ระบบจะบันทึกเหตุการณ์นี้เป็นรายการในบันทึกหรือธุรกรรม เมื่ออินเทอร์เฟซเชื่อมต่อรับข้อมูลสำเร็จ. | ||
| เหตุผลที่สำคัญ นี่คือเหตุการณ์เริ่มต้นหลักของวงจรรายได้ การวิเคราะห์เวลาตั้งแต่กิจกรรมนี้จนถึงการบันทึกค่าบริการมีความสำคัญต่อการค้นหาความล่าช้าของข้อมูลในขั้นตอนต้น ซึ่งส่งผลต่อกระบวนการทั้งหมด. แหล่งข้อมูล บันทึกไว้ในบันทึกของอินเทอร์เฟซหรือตารางธุรกรรมที่จัดการข้อมูลบริการผู้ป่วยขาเข้าจากระบบภายนอก เช่น EHR ให้ค้นหาเวลาในข้อความ HL7 หรือบันทึกการเรียก API. บันทึก ดึงข้อมูลจากบันทึกการเชื่อมต่อหรือตารางธุรกรรมที่ประทับเวลาเมื่อได้รับข้อมูล. ประเภทเหตุการณ์ explicit | |||
| ได้รับคำแนะนำการจ่ายเงินแล้ว | ระบบได้รับไฟล์คำแนะนำการจ่ายเงินทางอิเล็กทรอนิกส์ (ERA) จากผู้จ่ายเงิน ซึ่งระบุการชำระเงิน การปรับยอด และการปฏิเสธเคลม ระบบบันทึกเหตุการณ์นี้เมื่อรับไฟล์ EDI 835 เข้าระบบ. | ||
| เหตุผลที่สำคัญ กิจกรรมนี้เป็นหมุดหมายสำคัญที่แสดงว่าผู้จ่ายเงินดำเนินการกับเคลมแล้ว ข้อมูลในไฟล์จะกำหนดขั้นตอนถัดไป เช่น การบันทึกการรับชำระเงินหรือการจัดการเคลมที่ถูกปฏิเสธ. แหล่งข้อมูล บันทึกไว้ในบันทึกธุรกรรม EDI สำหรับไฟล์ ANSI 835 ขาเข้า โดยเวลาระบุว่าไฟล์มาถึงและระบบประมวลผลเมื่อใด. บันทึก เวลาที่เกี่ยวข้องกับการรับไฟล์ EDI 835 (Electronic Remittance Advice) เข้าระบบ. ประเภทเหตุการณ์ explicit | |||
| ได้รับแจ้งการปฏิเสธเคลมแล้ว | ผู้จ่ายเงินปฏิเสธเคลมตามที่ระบุในคำแนะนำการจ่ายเงินที่ได้รับ ระบบอนุมานเหตุการณ์นี้โดยตรวจหารหัสเหตุผลการปฏิเสธที่เกี่ยวข้องกับรายการเคลมในข้อมูลคำแนะนำการจ่ายเงิน. | ||
| เหตุผลที่สำคัญ การติดตามเคลมที่ถูกปฏิเสธมีความสำคัญต่อการค้นหาสาเหตุที่แท้จริงของการสูญเสียรายได้และความไม่มีประสิทธิภาพของกระบวนการ กิจกรรมนี้เป็นจุดเริ่มต้นของการจัดการเคลมที่ถูกปฏิเสธและการแก้ไขเคลมเพื่อยื่นอุทธรณ์. แหล่งข้อมูล อนุมานจากข้อมูล Electronic Remittance Advice (EDI 835) โดยระบบตรวจหารหัสเหตุผลการปรับปรุงเคลม (CARCs) ที่ระบุว่าเคลมถูกปฏิเสธ. บันทึก อนุมานจากการตรวจหารหัสการปฏิเสธเคลม (CARCs/RARCs) ในข้อมูลการจ่ายเงิน EDI 835 ที่แยกวิเคราะห์แล้ว. ประเภทเหตุการณ์ inferred | |||
| บันทึกรับชำระเงินแล้ว | นำเงินที่ได้รับไปตัดยอดบัญชีผู้ป่วยและรายการบริการที่เกี่ยวข้องเรียบร้อยแล้ว ผู้ใช้หรือระบบอัตโนมัติดำเนินการนี้เพื่อกระทบยอดเงินที่ได้รับกับค่าบริการค้างชำระ. | ||
| เหตุผลที่สำคัญ กิจกรรมนี้สำคัญต่อการวัดประสิทธิภาพของขั้นตอนบันทึกรับชำระเงินในส่วนงานหลังบ้าน หากบันทึกล่าช้า รายงานลูกหนี้อาจคลาดเคลื่อนและการปิดบัญชีอาจช้าลง. แหล่งข้อมูล ค้นหาได้ในตารางธุรกรรมการชำระเงิน โดยใช้เวลาของธุรกรรมที่บันทึกการรับชำระเงินเป็นเวลาเกิดเหตุการณ์. บันทึก เวลาที่สร้างรายการธุรกรรมการชำระเงินซึ่งนำไปตัดยอดค่าบริการรายการหนึ่ง. ประเภทเหตุการณ์ explicit | |||
| ปิดบัญชีแล้ว | ถือว่าเหตุการณ์การเรียกเก็บเงินเสร็จสมบูรณ์เมื่อยอดคงเหลือเป็นศูนย์และไม่มีรายการอื่นที่คาดว่าจะเกิดขึ้น ระบบอนุมานเหตุการณ์นี้เมื่อยอดบัญชีเป็นศูนย์และสถานะบัญชีเปลี่ยนเป็น 'Closed' หรือสถานะสุดท้ายที่มีความหมายใกล้เคียงกัน. | ||
| เหตุผลที่สำคัญ นี่คือเหตุการณ์สิ้นสุดหลักของกระบวนการ การวัดเวลาตั้งแต่เริ่มจนถึงจุดนี้ช่วยให้เห็นประสิทธิภาพโดยรวมของ RCM. แหล่งข้อมูล อนุมานจากการที่ยอดบัญชีเป็นศูนย์ร่วมกับสถานะบัญชีที่ตั้งเป็น 'Closed', 'Paid in Full' หรือสถานะสุดท้ายที่มีความหมายเทียบเท่ากัน. บันทึก ใช้เวลาล่าสุดระหว่างเวลาบันทึกการชำระเงินงวดสุดท้ายที่ทำให้ยอดเป็นศูนย์ กับเวลาที่สถานะเปลี่ยนเป็น 'Closed'. ประเภทเหตุการณ์ inferred | |||
| ส่งเคลมให้ผู้จ่ายเงินแล้ว | ส่งเคลมที่สร้างขึ้นทางอิเล็กทรอนิกส์ไปยังบริษัทประกันเพื่อพิจารณาแล้ว โมดูลส่งเคลมหรืออินเทอร์เฟซของ clearinghouse จะบันทึกเหตุการณ์นี้เมื่อส่งข้อมูลสำเร็จ. | ||
| เหตุผลที่สำคัญ นี่คือหมุดหมายสำคัญที่เริ่มนับเวลารอการตอบกลับจากผู้จ่ายเงิน ช่วยวัดประสิทธิภาพของขั้นตอนส่งเคลมและค้นหาความล่าช้าในการส่ง. แหล่งข้อมูล ค้นหาได้ในบันทึกธุรกรรมเคลมหรือตารางธุรกรรม EDI (Electronic Data Interchange) โดยเฉพาะรายการส่งไฟล์เคลม 837 ให้มองหาช่อง 'submission timestamp' หรือ 'transmit date'. บันทึก เวลาจากบันทึกธุรกรรม EDI 837 ที่ระบุว่าส่งเคลมสำเร็จ. ประเภทเหตุการณ์ explicit | |||
| ได้รับชำระเงินแล้ว | ระบุว่าได้รับชำระเงินจากผู้จ่ายเงินหรือผู้ป่วยแล้ว โดยมักบันทึกไว้ในคำแนะนำการจ่ายเงิน ระบบอาจดึงเหตุการณ์นี้จากไฟล์การจ่ายเงินอิเล็กทรอนิกส์หรือบันทึกรับเงินสดด้วยตนเอง. | ||
| เหตุผลที่สำคัญ กิจกรรมนี้เป็นข้อมูลพื้นฐานสำหรับวิเคราะห์กระแสเงินสดและวัดความเร็วในการรับชำระเงิน อีกทั้งยังเป็นตัวเริ่มขั้นตอนบันทึกการรับชำระเงิน. แหล่งข้อมูล ดึงข้อมูลจากรายละเอียดการชำระเงินในไฟล์คำแนะนำการจ่ายเงิน EDI 835 หรือไฟล์ lockbox จากธนาคาร โดยมักใช้วันที่ในเช็คหรือวันที่ประมวลผลในไฟล์. บันทึก ดึงข้อมูลจากส่วน BPR ของไฟล์ EDI 835 หรือไฟล์ข้อมูล lockbox ของธนาคาร. ประเภทเหตุการณ์ explicit | |||
| บันทึกค่าบริการแล้ว | ระบุจุดที่นำบริการและเวชภัณฑ์ที่เรียกเก็บเงินได้เข้าสู่ระบบเรียกเก็บเงินอย่างเป็นทางการ โดยเป็นการดำเนินการที่ผู้ใช้หรือระบบทำ ซึ่งจะสร้างรายการธุรกรรมค่าบริการ. | ||
| เหตุผลที่สำคัญ กิจกรรมนี้จำเป็นต่อการวัดระยะเวลาล่าช้าในการบันทึกค่าบริการ ซึ่งหมายถึงเวลาตั้งแต่ให้บริการจนเริ่มเรียกเก็บเงิน การลดช่วงเวลานี้ช่วยเร่งวงจรรายได้โดยตรง. แหล่งข้อมูล ค้นหาได้ในตารางธุรกรรมค่าบริการ ซึ่งมักใช้ชื่อ charge entry หรือ service line โดยใช้เวลาที่สร้างรายการค่าบริการเป็นเวลาของเหตุการณ์. บันทึก เหตุการณ์นี้คือเวลาที่สร้างรายการในตาราง charge master หรือ charge transaction. ประเภทเหตุการณ์ explicit | |||
| ปรับยอดบัญชีแล้ว | บันทึกการปรับยอดตามสัญญา การตัดหนี้สูญ หรือการแก้ไขทางการเงินอื่นลงในบัญชีแล้ว รายการนี้เป็นธุรกรรมทางการเงินที่บันทึกไว้อย่างชัดเจนในบัญชีแยกประเภทของระบบ. | ||
| เหตุผลที่สำคัญ การปรับยอดส่งผลโดยตรงต่อรายได้ที่ได้รับจริง การวิเคราะห์เหตุผลและเวลาที่มีการปรับยอดช่วยค้นหาปัญหาเกี่ยวกับตารางค่าธรรมเนียม สัญญา หรือความถูกต้องในการเรียกเก็บเงิน. แหล่งข้อมูล ค้นหาได้ในตารางธุรกรรมทางการเงิน โดยระบุจากรหัสธุรกรรมเฉพาะสำหรับการตัดหนี้สูญหรือการปรับยอด วันที่ทำธุรกรรมใช้เป็นเวลาเกิดเหตุการณ์. บันทึก วันที่ทำธุรกรรมของรายการในบัญชีแยกประเภททางการเงินที่มีรหัสปรับยอดเฉพาะ. ประเภทเหตุการณ์ explicit | |||
| ยื่นคำอุทธรณ์แล้ว | ยื่นคำอุทธรณ์ต่อผู้จ่ายเงินอย่างเป็นทางการเพื่อโต้แย้งเคลมที่ถูกปฏิเสธแล้ว ผู้ใช้บันทึกการดำเนินการนี้ในโมดูลจัดการเคลมที่ถูกปฏิเสธหรือโมดูลอุทธรณ์. | ||
| เหตุผลที่สำคัญ กิจกรรมนี้เป็นขั้นตอนสำคัญในการเรียกคืนรายได้ การติดตามการยื่นอุทธรณ์และระยะเวลาของแต่ละรอบมีความสำคัญต่อการประเมินประสิทธิผลของแนวทางจัดการเคลมที่ถูกปฏิเสธ. แหล่งข้อมูล บันทึกไว้ในโมดูลติดตามการอุทธรณ์ หรือเป็นประเภทธุรกรรมเฉพาะของเคลม ให้มองหาช่อง 'appeal date' หรือ 'resubmission date'. บันทึก เวลาที่บันทึกไว้เมื่อผู้ใช้ลงรายการว่ายื่นคำอุทธรณ์แล้ว. ประเภทเหตุการณ์ explicit | |||
| เริ่มแก้ไขเคลมที่ถูกปฏิเสธแล้ว | ผู้ใช้หรือเวิร์กโฟลว์อัตโนมัติเริ่มตรวจสอบและจัดการเคลมที่ถูกปฏิเสธแล้ว ระบบอาจบันทึกจากการดำเนินการของผู้ใช้โดยตรง หรืออนุมานจากการเปลี่ยนสถานะเคลม. | ||
| เหตุผลที่สำคัญ กิจกรรมนี้เริ่มรอบการแก้ไขเคลมที่ถูกปฏิเสธ การวัดเวลาตั้งแต่ได้รับแจ้งการปฏิเสธจนเริ่มแก้ไขช่วยให้เห็นงานค้างในคิวจัดการเคลมที่ถูกปฏิเสธ. แหล่งข้อมูล ค้นหาได้ในโมดูลจัดการเคลมที่ถูกปฏิเสธหรือคิวงาน อาจเป็นเวลาที่บันทึกเมื่อผู้ใช้ 'เปิด' หรือ 'รับผิดชอบ' งานจัดการเคลม หรืออนุมานจากการเปลี่ยนสถานะ เช่น จาก 'Denied' เป็น 'In Rework'. บันทึก อนุมานจากการเปลี่ยนสถานะเคลมเป็น 'Rework' หรือ 'Under Review' หรือจากบันทึกการดำเนินการของผู้ใช้โดยตรง. ประเภทเหตุการณ์ inferred | |||
| เริ่มติดตามทวงถามแล้ว | นำบัญชีผู้ป่วยเข้าสู่ขั้นตอนติดตามทวงถามอย่างจริงจังเนื่องจากยังไม่ได้รับชำระ โดยทั่วไปอนุมานจากการเปลี่ยนประเภทหรือสถานะทางการเงินของบัญชี. | ||
| เหตุผลที่สำคัญ กิจกรรมนี้ช่วยระบุบัญชีที่ต้องติดตามอย่างใกล้ชิดขึ้น การวิเคราะห์ความถี่และปัจจัยที่ทำให้เกิดกิจกรรมนี้ช่วยปรับปรุงแนวทางเรียกเก็บเงินในขั้นตอนต้น. แหล่งข้อมูล อนุมานจากการเปลี่ยนสถานะบัญชีเป็น 'Collections', 'Bad Debt' หรือ 'Sent to Agency' โดยใช้วันที่เปลี่ยนสถานะเป็นเวลาเกิดเหตุการณ์. บันทึก เวลาที่ช่องสถานะบัญชีเปลี่ยนเป็นค่าที่เกี่ยวข้องกับการติดตามทวงถาม. ประเภทเหตุการณ์ inferred | |||
| ลงรหัสเสร็จแล้ว | ระบุว่าเจ้าหน้าที่ลงรหัสทางการแพทย์ตรวจเอกสารทางคลินิกและกำหนดรหัส CPT, HCPCS และ ICD ที่เหมาะสมแล้ว โดยทั่วไป ผู้ใช้หรือระบบลงรหัสอัตโนมัติจะบันทึกเหตุการณ์นี้เมื่อทำงานลงรหัสเสร็จ. | ||
| เหตุผลที่สำคัญ การลงรหัสมักเป็นคอขวดที่ทำให้การส่งเคลมล่าช้า การติดตามกิจกรรมนี้ช่วยวัดประสิทธิภาพของเจ้าหน้าที่ลงรหัสและค้นหาความล่าช้าในคิวงาน. แหล่งข้อมูล บันทึกไว้ในโมดูลเวิร์กโฟลว์การลงรหัส หรือดูจากสถานะของเหตุการณ์การเรียกเก็บเงินที่เปลี่ยนจาก 'Pending Coding' เป็น 'Coded' โดยใช้เวลาที่สถานะเปลี่ยนหรือเวลาที่งานเสร็จ. บันทึก เวลาที่อัปเดตสถานะหรือบันทึกรายการ เมื่อผู้ใช้หรือระบบลงรหัสการเข้ารับบริการเสร็จสิ้น. ประเภทเหตุการณ์ explicit | |||
| ส่งใบแจ้งยอดให้ผู้ป่วยแล้ว | สร้างและส่งใบแจ้งยอดค่าบริการส่วนที่ผู้ป่วยต้องชำระแล้ว โมดูลเรียกเก็บเงินจากผู้ป่วยจะบันทึกเหตุการณ์นี้เมื่อสร้างใบแจ้งยอด. | ||
| เหตุผลที่สำคัญ กิจกรรมนี้เริ่มส่วนการเรียกเก็บเงินจากผู้ป่วยโดยตรงของวงจรรายได้ การติดตามช่วยวิเคราะห์ประสิทธิภาพและผลลัพธ์ของการเรียกเก็บเงินจากผู้ป่วย. แหล่งข้อมูล บันทึกไว้ในตารางประวัติการติดต่อผู้ป่วยหรือการสร้างใบแจ้งยอด โดยเวลาระบุว่าสร้างหรือส่งใบแจ้งยอดเมื่อใด. บันทึก เวลาจากบันทึกหรือประวัติการสร้างใบแจ้งยอดผู้ป่วย. ประเภทเหตุการณ์ explicit | |||
| สร้างเคลมแล้ว | ระบบสร้างเคลมที่เรียกเก็บเงินได้ โดยรวบรวมค่าบริการ รหัส และข้อมูลประชากรให้อยู่ในรูปแบบมาตรฐาน เหตุการณ์นี้เกิดจากระบบโดยตรงและมีเวลาที่สร้างบันทึกไว้. | ||
| เหตุผลที่สำคัญ กิจกรรมนี้เป็นจุดเปลี่ยนจากการบันทึกค่าบริการเข้าสู่ขั้นตอนเรียกเก็บเงินอย่างเป็นทางการ และเป็นเงื่อนไขก่อนส่งเคลม ทั้งยังสำคัญต่อการติดตามเวลาประมวลผลภายใน. แหล่งข้อมูล ค้นหาได้ในตารางเคลมหรือบันทึกธุรกรรม เวลาที่สร้างรายการส่วนหัวของเคลมใช้ระบุเวลาเกิดเหตุการณ์. บันทึก ใช้เวลาที่สร้างรายการหลักในตารางฐานข้อมูลเคลม. ประเภทเหตุการณ์ explicit | |||
คู่มือการดึงข้อมูล
ขณะนี้กำลังตรวจสอบวิธีดึงข้อมูลสำหรับกระบวนการนี้ โปรดกลับมาตรวจสอบภายหลัง หรือ ติดต่อเรา เพื่อขอความช่วยเหลือ.
พร้อมเริ่มต้นหรือยัง?
ใช้เทมเพลตนี้ช่วยให้การรวบรวมข้อมูลง่ายขึ้น และเริ่มปรับปรุงกระบวนการจัดการวงจรรายได้ของคุณ ค้นพบข้อมูลเชิงลึกและเพิ่มประสิทธิภาพการทำงานได้อย่างมั่นใจ.
ปรับปรุงการจัดการวงจรรายได้ ลดความล่าช้าได้ตั้งแต่วันนี้
ร่วมกับองค์กรที่ลดระยะเวลาของวงจรลง 30% และเสริมความมั่นคงทางการเงิน.
ไม่ต้องใช้บัตรเครดิต ตั้งค่าเสร็จในไม่กี่นาที.