> การปรับปรุงกระบวนการอย่างต่อเนื่อง > การจัดการวงจรรายได้ > R1 RCM > เทมเพลตข้อมูล

เทมเพลตข้อมูลสำหรับการจัดการวงจรรายได้

R1 RCM

แอตทริบิวต์สำหรับการจัดการวงจรรายได้(19) กิจกรรมในการจัดการวงจรรายได้(14) คู่มือการดึงข้อมูล(1)

เทมเพลตข้อมูลสำหรับการจัดการวงจรรายได้

เทมเพลตนี้ช่วยวางแนวทางรวบรวมข้อมูลที่จำเป็นสำหรับวิเคราะห์กระบวนการจัดการวงจรรายได้ โดยระบุแอตทริบิวต์สำคัญที่ควรเก็บและกิจกรรมหลักที่ควรติดตาม พร้อมคำแนะนำในการดึงข้อมูลจากระบบ R1 RCM เพื่อเตรียมเริ่มทำ process mining ได้อย่างมีประสิทธิภาพ.

แอตทริบิวต์ที่แนะนำให้รวบรวม
กิจกรรมสำคัญที่ควรติดตามเพื่อค้นพบกระบวนการ
คำแนะนำโดยละเอียดในการดึงข้อมูลจาก R1 RCM

เพิ่งเริ่มใช้บันทึกเหตุการณ์ใช่ไหม เรียนรู้ วิธีสร้าง event log สำหรับ process mining.

ดาวน์โหลดเทมเพลต

แอตทริบิวต์สำหรับการจัดการวงจรรายได้

ฟิลด์ข้อมูลเหล่านี้เป็นรายการแนะนำสำหรับบันทึกเหตุการณ์ เพื่อวิเคราะห์กระบวนการจัดการวงจรรายได้ได้อย่างครบถ้วน.

5 จำเป็น 6 แนะนำ 8 ไม่บังคับ

	ชื่อ	คำอธิบาย
	ชื่อกิจกรรม ActivityName	ชื่อเหตุการณ์ทางธุรกิจหรืองานที่เกิดขึ้น ณ ช่วงเวลาหนึ่งในกระบวนการวงจรรายได้.
คำอธิบาย คุณลักษณะนี้ระบุขั้นตอนหรือจุดสำคัญหนึ่งรายการในกระบวนการจัดการวงจรรายได้ของเหตุการณ์เรียกเก็บเงินแต่ละรายการ กิจกรรมแสดงงานที่เกิดขึ้น เช่น 'บันทึกค่าบริการแล้ว' 'ส่งเคลมแล้ว' หรือ 'บันทึกการรับชำระเงินแล้ว' การวิเคราะห์ลำดับกิจกรรมเป็นหัวใจของ process mining ช่วยให้ค้นพบการไหลของกระบวนการจริง ระบุคอขวดที่ทำให้กิจกรรมเริ่มต้นล่าช้า และตรวจพบขั้นตอนที่ต้องทำซ้ำโดยไม่จำเป็น เช่น 'เคลมถูกปฏิเสธ' ตามด้วย 'เริ่มแก้ไขการปฏิเสธเคลม'. เหตุผลที่สำคัญ แอตทริบิวต์นี้กำหนดขั้นตอนในกระบวนการ ช่วยแสดงแผนผังกระบวนการ คำนวณระยะเวลาระหว่างขั้นตอน และระบุความเบี่ยงเบนหรือการทำงานซ้ำ. แหล่งข้อมูล โดยทั่วไปข้อมูลนี้มาจากบันทึกเหตุการณ์ รายการเปลี่ยนสถานะ หรือรหัสธุรกรรมในโมดูลต่างๆ ของ R1 RCM อาจต้องจับคู่รหัสทางเทคนิคกับชื่อที่เข้าใจง่ายสำหรับธุรกิจ. ตัวอย่าง บันทึกค่าบริการส่งเคลมแล้วได้รับผลพิจารณาเคลมจากผู้ชำระเงินบันทึกการชำระเงินแล้วปิดบัญชีแล้ว
	เวลาเกิดเหตุการณ์ EventTime	วันและเวลาที่ระบุว่ากิจกรรมหรือเหตุการณ์เกิดขึ้นเมื่อใด.
คำอธิบาย เวลาเกิดเหตุการณ์ระบุวันและเวลาที่ระบบบันทึกกิจกรรมไว้อย่างแม่นยำ ข้อมูลด้านเวลานี้เป็นพื้นฐานสำคัญในการวิเคราะห์กระบวนการ ใน process mining ระบบใช้เวลาประทับนี้เรียงเหตุการณ์ตามลำดับเวลาและคำนวณระยะเวลาระหว่างกิจกรรม ซึ่งจำเป็นต่อการวิเคราะห์ประสิทธิภาพ นอกจากนี้ยังใช้คำนวณตัวชี้วัดสำคัญ เช่น ระยะเวลารอบงาน เวลาประมวลผล และเวลารอ เพื่อระบุคอขวดและวัดประสิทธิภาพได้. เหตุผลที่สำคัญ เวลาประทับนี้เป็นพื้นฐานของการวิเคราะห์ด้านเวลา ทั้งการคำนวณระยะเวลารอบงาน การระบุคอขวด และการติดตามประสิทธิภาพของกระบวนการเทียบกับ SLA. แหล่งข้อมูล โดยทั่วไปจะอยู่ในฟิลด์ “Creation Date” “Timestamp” หรือ “Last Update Date” ซึ่งเชื่อมโยงกับธุรกรรมหรือรายการเปลี่ยนสถานะแต่ละรายการใน R1 RCM. ตัวอย่าง 2023-10-26T10:00:00Z2023-10-27T14:35:10Z2023-11-05T09:12:45Z
	เหตุการณ์เรียกเก็บเงิน BillingEvent	รหัสเฉพาะของบริการหรือรายการที่เรียกเก็บเงินได้หนึ่งรายการ ใช้เป็นรหัสเคสหลักเพื่อติดตามวงจรรายได้ทั้งหมด.
คำอธิบาย รหัสเหตุการณ์เรียกเก็บเงินใช้ระบุรายการให้บริการหรือส่งมอบผลิตภัณฑ์แต่ละรายการที่มีการเรียกเก็บเงิน รหัสนี้เชื่อมโยงกิจกรรมที่เกี่ยวข้องทั้งหมดเข้าด้วยกัน ตั้งแต่การให้บริการและบันทึกค่าบริการครั้งแรก ไปจนถึงการส่งเคลม การบันทึกการรับชำระเงิน และการปิดบัญชีในที่สุด การวิเคราะห์วงจรชีวิตของเหตุการณ์เรียกเก็บเงินแต่ละรายการด้วย process mining ช่วยให้เห็นภาพวงจรรายได้ตั้งแต่ต้นจนจบ คุณสามารถติดตามเส้นทางของค่าบริการแต่ละรายการ ค้นหาเส้นทางที่เกิดขึ้นบ่อย วัดรอบเวลาดำเนินการระหว่างจุดสำคัญ และทำความเข้าใจความแตกต่างที่ทำให้เกิดความล่าช้าหรือรายได้รั่วไหล. เหตุผลที่สำคัญ รหัสนี้จำเป็นสำหรับจัดกลุ่มกิจกรรมที่เกี่ยวข้องให้เป็นเคสเดียวกัน ทำให้วิเคราะห์กระบวนการวงจรรายได้ของเหตุการณ์ที่เรียกเก็บเงินแต่ละรายการได้ครบถ้วนและแม่นยำ. แหล่งข้อมูล นี่คือคีย์หลักที่เชื่อมโยงตารางต่างๆ ซึ่งเกี่ยวข้องกับการรับบริการของผู้ป่วย ค่าใช้จ่าย เคลม และการชำระเงิน โปรดดูเอกสาร R1 RCM เพื่อระบุฟิลด์ที่ใช้ โดยมักเป็นรหัสรายการรับบริการหรือรหัสเคลม. ตัวอย่าง BE-2023-0012345BE-2023-0054321BE-2024-0098765
	ระบบต้นทาง SourceSystem	ระบบบันทึกข้อมูลต้นทางที่ใช้ดึงข้อมูลเหตุการณ์ออกมา.
คำอธิบาย แอตทริบิวต์นี้ระบุแอปพลิเคชันหรือโมดูลต้นทางที่สร้างข้อมูลของเหตุการณ์นั้น ในสภาพแวดล้อมที่ซับซ้อนอย่างระบบสาธารณสุข ข้อมูลอาจมาจาก EMR โมดูลเรียกเก็บเงิน ศูนย์รับส่งเคลม หรือแพลตฟอร์มติดตามหนี้ การทราบระบบต้นทางมีความสำคัญต่อการตรวจสอบความถูกต้องของข้อมูล และการวิเคราะห์ความแตกต่างของกระบวนการที่อาจเกิดจากระบบบางระบบโดยเฉพาะ นอกจากนี้ยังช่วยแก้ปัญหาข้อมูลไม่สอดคล้องกัน และทำความเข้าใจระบบเทคโนโลยีที่เกี่ยวข้องกับกระบวนการ. เหตุผลที่สำคัญ ระบุแหล่งที่มาของข้อมูล ซึ่งจำเป็นต่อการกำกับดูแลและตรวจสอบข้อมูล รวมถึงทำความเข้าใจว่าระบบต่างๆ ทำงานร่วมกันอย่างไรในกระบวนการตั้งแต่ต้นจนจบ. แหล่งข้อมูล มักเป็นค่าคงที่ที่เพิ่มระหว่างการดึงข้อมูล เพื่อระบุระบบต้นทาง เช่น “R1 RCM”. ตัวอย่าง R1 RCMCernerEpic
	อัปเดตข้อมูลล่าสุด LastDataUpdate	เวลาประทับของการรีเฟรชหรือดึงข้อมูลจากระบบต้นทางครั้งล่าสุด.
คำอธิบาย แอตทริบิวต์นี้ระบุเวลาล่าสุดที่มีการอัปเดตข้อมูลสำหรับการวิเคราะห์ process mining และช่วยให้ทราบว่าข้อมูลที่นำมาวิเคราะห์เป็นปัจจุบันเพียงใด ข้อมูลนี้สำคัญต่อการจัดทำรายงานและแดชบอร์ด เพราะช่วยให้ผู้ใช้ทราบว่าข้อมูลเชิงลึกเกี่ยวกับกระบวนการเป็นข้อมูลล่าสุดถึงเมื่อใด อีกทั้งช่วยกำหนดความคาดหวังเรื่องความทันเวลาของข้อมูล และทำให้ตัดสินใจโดยเข้าใจช่วงเวลาของข้อมูลที่ใช้. เหตุผลที่สำคัญ ช่วยให้ทราบว่าข้อมูลเป็นปัจจุบันเพียงใด เพื่อให้นักวิเคราะห์และผู้เกี่ยวข้องเข้าใจว่าข้อมูลเชิงลึกเกี่ยวกับกระบวนการอัปเดตถึงเมื่อใด. แหล่งข้อมูล เวลาประทับนี้สร้างขึ้นระหว่างกระบวนการดึง แปลง และโหลดข้อมูล (ETL) โดยปกติจะกำหนดให้กับชุดข้อมูลทั้งหมด. ตัวอย่าง 2024-05-20T08:00:00Z2024-05-21T08:00:00Z
	ชื่อผู้จ่ายเงิน PayerName	ชื่อบริษัทประกัน หน่วยงานรัฐ หรือผู้ป่วยที่รับผิดชอบการชำระเงิน.
คำอธิบาย แอตทริบิวต์นี้ระบุผู้จ่ายเงินหลักของเคลม ซึ่งอาจเป็นบริษัทประกันเอกชน เช่น Aetna หน่วยงานรัฐ เช่น Medicare หรือผู้ป่วยที่ชำระค่าใช้จ่ายเอง การวิเคราะห์กระบวนการแยกตามผู้จ่ายเงินเป็นพื้นฐานสำคัญของการจัดการวงจรรายได้ ช่วยให้เห็นว่าผู้จ่ายเงินบางรายมีอัตราการปฏิเสธเคลมสูงกว่า ใช้เวลาชำระเงินนานกว่า หรือมีข้อกำหนดในการส่งเคลมซับซ้อนกว่า ข้อมูลเชิงลึกเหล่านี้ช่วยให้องค์กรปรับกระบวนการและจัดสรรทรัพยากรเพื่อรับมือกับรูปแบบการทำงานของผู้จ่ายเงินแต่ละรายได้อย่างเหมาะสม. เหตุผลที่สำคัญ ช่วยแบ่งกลุ่มกระบวนการตามผู้จ่ายเงิน เพื่อระบุความล่าช้า รูปแบบการปฏิเสธเคลม หรือพฤติกรรมการชำระเงินของแต่ละราย ซึ่งจำเป็นต่อการเพิ่มประสิทธิภาพรายได้. แหล่งข้อมูล ค้นหาได้จากข้อมูลประกันหรือข้อมูลประชากรของผู้ป่วยที่เชื่อมโยงกับเคลมใน R1 RCM. ตัวอย่าง MedicareUnitedHealthcareBlue Cross Blue ShieldAetnaผู้ป่วยชำระเอง
	ผู้ใช้ที่ได้รับมอบหมาย AssignedUser	รหัสหรือชื่อผู้ใช้ของพนักงานที่ทำกิจกรรมนั้น.
คำอธิบาย แอตทริบิวต์นี้ระบุผู้รับผิดชอบงานแต่ละรายการในกระบวนการ เช่น เจ้าหน้าที่เรียกเก็บเงินที่สร้างเคลม นักวิเคราะห์ที่แก้ไขเคลมที่ถูกปฏิเสธ หรือผู้เชี่ยวชาญที่บันทึกการชำระเงิน การวิเคราะห์แยกตามผู้ใช้ช่วยให้เข้าใจการกระจายงาน ประสิทธิภาพของแต่ละคน และความต้องการด้านการฝึกอบรม อีกทั้งยังช่วยระบุผู้ใช้ที่ทำงานได้มีประสิทธิภาพ หรือผู้ที่อาจเกี่ยวข้องกับอัตราข้อผิดพลาดที่สูงขึ้น เพื่อนำไปวางแผนการบริหารและปรับปรุงกระบวนการได้ตรงจุด. เหตุผลที่สำคัญ ช่วยวิเคราะห์ประสิทธิภาพของทีมและรายบุคคล รวมถึงการกระจายงาน และช่วยระบุโอกาสในการฝึกอบรมหรือความเบี่ยงเบนของกระบวนการที่เกี่ยวข้องกับผู้ใช้บางราย. แหล่งข้อมูล โดยทั่วไปจะอยู่ในฟิลด์ “UserID” “Processor” หรือ “UpdatedBy” ในบันทึกธุรกรรมของ R1 RCM. ตัวอย่าง jdoeasmithp.jonesBOT_RPA01
	แผนกเรียกเก็บเงิน BillingDepartment	แผนกหรือทีมงานที่รับผิดชอบกิจกรรมนั้น.
คำอธิบาย แอตทริบิวต์นี้ระบุหน่วยงานที่ดำเนินขั้นตอนนั้น เช่น “บันทึกค่าใช้จ่าย” “ส่งเคลม” หรือ “จัดการเคลมที่ถูกปฏิเสธ” ช่วยให้เข้าใจการส่งต่องานระหว่างทีมต่างๆ ข้อมูลนี้สำคัญต่อการวิเคราะห์ปริมาณงานของแต่ละแผนกและระบุคอขวดระหว่างหน่วยงาน เมื่อกรองแผนผังกระบวนการตามแผนก องค์กรจะเห็นว่าการส่งต่องานส่วนใดราบรื่นและส่วนใดล่าช้า ซึ่งช่วยจัดสรรทรัพยากรและปรับปรุงกระบวนการทำงานขององค์กร. เหตุผลที่สำคัญ ช่วยวิเคราะห์ประสิทธิภาพของกระบวนการแยกตามหน่วยงาน และระบุคอขวด ข้อจำกัดด้านทรัพยากร หรือแนวทางปฏิบัติที่ดีของแต่ละทีม. แหล่งข้อมูล ข้อมูลนี้อาจดึงมาจากโปรไฟล์ผู้ใช้ใน R1 RCM หรือจัดเก็บไว้ในข้อมูลธุรกรรมเป็น “Department Code”. ตัวอย่าง บันทึกค่าใช้จ่ายการจัดการเคลมการปฏิเสธเคลมและการอุทธรณ์บันทึกการชำระเงิน
	ยอดเงินในใบแจ้งหนี้ InvoiceAmount	มูลค่ารวมของค่าใช้จ่ายในใบแจ้งหนี้หรือเคลม.
คำอธิบาย คุณลักษณะนี้ระบุยอดเรียกเก็บเงินรวมสำหรับบริการที่ให้ในเหตุการณ์เรียกเก็บเงินแต่ละรายการ ซึ่งสะท้อนรายได้ที่คาดว่าจะได้รับจากเคลม การวิเคราะห์ยอดใบแจ้งหนี้มีความสำคัญต่อ process mining ด้านการเงิน ช่วยจัดลำดับความสำคัญของเคลมมูลค่าสูง ทำความเข้าใจผลกระทบทางการเงินจากความล่าช้าหรือการปฏิเสธเคลม และแบ่งกลุ่มกระบวนการตามมูลค่า ตัวอย่างเช่น การวิเคราะห์อาจพบว่าเคลมที่มียอดเกินจำนวนหนึ่งใช้เส้นทางการทำงานด้วยมือที่แตกต่างจากรายการอื่น. เหตุผลที่สำคัญ ช่วยให้เห็นบริบททางการเงินของกระบวนการ วิเคราะห์ผลกระทบของความแตกต่างในกระบวนการต่อรายได้ และจัดลำดับความสำคัญของเคสมูลค่าสูงเพื่อปรับปรุง. แหล่งข้อมูล อยู่ในตารางหลักส่วนหัวของเคลมหรือใบแจ้งหนี้ใน R1 RCM โดยมักใช้ชื่อ “TotalBilledAmount” หรือชื่อใกล้เคียง. ตัวอย่าง 150.002500.7585.5012000.00
	รหัสเหตุผลการปฏิเสธเคลม DenialReasonCode	รหัสมาตรฐานจากผู้จ่ายเงินที่อธิบายสาเหตุการปฏิเสธเคลม.
คำอธิบาย เมื่อผู้จ่ายเงินปฏิเสธเคลม จะระบุรหัสเหตุผล เช่น CARC (Claim Adjustment Reason Code) เพื่ออธิบายการตัดสินใจ รหัสเหล่านี้เป็นมาตรฐานและระบุปัญหา เช่น “บริการนี้ไม่อยู่ในความคุ้มครอง” หรือ “ส่งเคลมซ้ำ” แอตทริบิวต์นี้สำคัญอย่างยิ่งต่อการจัดการเคลมที่ถูกปฏิเสธ การวิเคราะห์ความถี่ของรหัสเหตุผลแต่ละประเภทช่วยให้องค์กรระบุและแก้ไขสาเหตุหลักของการปฏิเสธได้ ไม่ว่าจะเกี่ยวข้องกับสิทธิ์ของผู้ป่วย ข้อผิดพลาดในการลงรหัส หรือความจำเป็นทางการแพทย์ ข้อมูลนี้ช่วยลดการทำงานซ้ำและเร่งกระแสเงินสดโดยตรง. เหตุผลที่สำคัญ ระบุสาเหตุเฉพาะที่เคลมถูกปฏิเสธ ช่วยวิเคราะห์ต้นตอเพื่อลดการปฏิเสธในอนาคต ลดการทำงานซ้ำ และเพิ่มอัตราการชำระเงินตั้งแต่การส่งครั้งแรก. แหล่งข้อมูล ข้อมูลนี้ได้รับจากผู้จ่ายเงินในรูปแบบคำแนะนำการชำระเงินทางอิเล็กทรอนิกส์ (ไฟล์ ERA หรือ 835) และจัดเก็บไว้ในโมดูลจัดการเคลมของ R1 RCM. ตัวอย่าง CO-16: เคลมหรือบริการขาดข้อมูลที่จำเป็นต่อการพิจารณา.PR-97: สิทธิประโยชน์สำหรับบริการนี้รวมอยู่ในการชำระเงินหรือค่าอนุญาตของบริการอื่นแล้ว.CO-22: ตามการประสานสิทธิประโยชน์ ผู้จ่ายเงินรายอื่นอาจเป็นผู้รับผิดชอบความคุ้มครองนี้.OA-18: เคลมหรือบริการซ้ำกันทุกประการ.
	สถานะใบแจ้งหนี้ InvoiceStatus	สถานะปัจจุบันของใบแจ้งหนี้หรือเคลมในวงจรการดำเนินงาน.
คำอธิบาย คุณลักษณะนี้ระบุสถานะล่าสุดที่ทราบของเหตุการณ์เรียกเก็บเงิน เช่น 'ส่งแล้ว' 'ชำระแล้ว' 'ถูกปฏิเสธ' หรือ 'อยู่ระหว่างติดตามหนี้' ซึ่งแสดงสถานะของใบแจ้งหนี้ในกระบวนการ ณ เวลาหนึ่ง สถานะใบแจ้งหนี้มีความสำคัญต่อการจัดทำรายงานอายุหนี้และติดตามสถานะของลูกหนี้การค้า ใน process mining คุณสามารถใช้สถานะนี้กรองเคสที่ค้างอยู่ในขั้นตอนใดขั้นตอนหนึ่ง หรือวิเคราะห์ผลลัพธ์ของกระบวนการแต่ละรูปแบบ เช่น เปรียบเทียบเส้นทางของเคลมที่ 'ชำระแล้ว' กับ 'ถูกปฏิเสธ'. เหตุผลที่สำคัญ แสดงสถานะปัจจุบันของแต่ละเคส ซึ่งจำเป็นต่อการจัดทำรายงานอายุลูกหนี้และวิเคราะห์ผลลัพธ์สุดท้ายของเส้นทางกระบวนการต่างๆ. แหล่งข้อมูล โดยทั่วไปเป็นฟิลด์สถานะในระเบียนหลักของเคลมหรือบัญชีใน R1 RCM. ตัวอย่าง รอส่งส่งให้ผู้จ่ายเงินแล้วถูกปฏิเสธชำระครบแล้วอยู่ระหว่างติดตามหนี้
	เป็นการทำงานซ้ำ IsRework	ตัวบ่งชี้ที่คำนวณขึ้นเพื่อระบุกิจกรรมในวงจรการทำงานซ้ำ เช่น การส่งเคลมที่ถูกปฏิเสธอีกครั้ง.
คำอธิบาย แอตทริบิวต์นี้เป็นตัวบ่งชี้แบบบูลีนที่มักคำนวณระหว่างการวิเคราะห์ process mining โดยจะเป็น “true” หากกิจกรรมเป็นการทำขั้นตอนก่อนหน้าซ้ำ หรืออยู่ในลำดับที่บ่งชี้ว่ามีการแก้ไขข้อผิดพลาด เช่น กิจกรรมใดๆ ที่เกิดขึ้นหลัง “เคลมถูกปฏิเสธ” การระบุงานที่ต้องทำซ้ำเป็นความสามารถสำคัญของ process mining เพราะช่วยวัดปริมาณเวลา แรงงาน และทรัพยากรที่สูญเปล่า เมื่อระบุงานที่ต้องทำซ้ำได้ องค์กรจะมุ่งปรับปรุงเพื่อป้องกันข้อผิดพลาดที่เป็นต้นเหตุ ซึ่งช่วยเพิ่มประสิทธิภาพได้อย่างชัดเจน. เหตุผลที่สำคัญ ช่วยวัดความถี่และผลกระทบของการทำงานซ้ำ เช่น การปฏิเสธเคลม เพื่อวิเคราะห์และลดความไม่มีประสิทธิภาพกับความพยายามที่สูญเปล่าได้ตรงจุด. แหล่งข้อมูล ฟิลด์นี้ไม่มีอยู่ในระบบต้นทาง แต่เครื่องมือ process mining จะคำนวณจากลำดับกิจกรรม เช่น ตรวจพบกิจกรรม “ส่งเคลมแล้ว” ที่เกิดขึ้นมากกว่าหนึ่งครั้งในเคสเดียวกัน. ตัวอย่าง truefalse
	เป็นระบบอัตโนมัติ IsAutomated	ตัวบ่งชี้ว่ากิจกรรมดำเนินการโดยระบบอัตโนมัติหรือผู้ใช้ที่เป็นบุคคล.
คำอธิบาย แอตทริบิวต์แบบบูลีนนี้แยกงานที่ซอฟต์แวร์ทำโดยอัตโนมัติ เช่น บอต RPA ที่ส่งเคลม ออกจากงานที่พนักงานทำด้วยตนเอง การวิเคราะห์แอตทริบิวต์นี้ช่วยให้เข้าใจผลกระทบและประสิทธิผลของการนำระบบอัตโนมัติมาใช้ คุณสามารถเปรียบเทียบความเร็ว ต้นทุน และอัตราข้อผิดพลาดของกระบวนการอัตโนมัติกับกระบวนการที่ทำด้วยตนเอง เพื่อค้นหาโอกาสใหม่ในการใช้ระบบอัตโนมัติและวัดผลตอบแทนจากการลงทุนของบอตที่ใช้อยู่. เหตุผลที่สำคัญ แยกกิจกรรมที่ทำโดยบุคคลออกจากกิจกรรมที่ระบบดำเนินการ ซึ่งจำเป็นต่อการวัดผลของระบบอัตโนมัติต่อประสิทธิภาพ ต้นทุน และคุณภาพของกระบวนการ. แหล่งข้อมูล ข้อมูลนี้อาจอนุมานจากฟิลด์ “AssignedUser” ซึ่งกำหนดรหัสผู้ใช้บางรายการให้บอตโดยเฉพาะ เช่น “BOT_RPA01” หรือบางระบบอาจมีฟิลด์สำหรับระบุธุรกรรมอัตโนมัติโดยตรง. ตัวอย่าง truefalse
	ผลการติดตามหนี้ CollectionOutcome	ผลลัพธ์สุดท้ายของการติดตามยอดค้างชำระ.
คำอธิบาย แอตทริบิวต์นี้อธิบายผลลัพธ์ของการติดตามชำระเงินจากบัญชีที่ค้างชำระ ผลลัพธ์ที่เป็นไปได้ ได้แก่ “ชำระครบแล้ว” “ตกลงชำระยอดที่ลดลง” “จัดเป็นหนี้สูญ” หรือ “ยังแก้ไขไม่ได้” การติดตามผลการติดตามหนี้จำเป็นต่อการประเมินประสิทธิผลของกระบวนการ เมื่อวิเคราะห์ว่ากิจกรรมใดนำไปสู่ผลลัพธ์แบบใด องค์กรจะปรับกลยุทธ์ติดตามหนี้ เพิ่มอัตราการเรียกเก็บเงินคืน และตัดสินใจได้อย่างมีข้อมูลว่าจะยุติการติดตามเมื่อใดและตัดยอดคงเหลือเป็นหนี้สูญ ข้อมูลนี้ช่วยสนับสนุนแดชบอร์ดประสิทธิภาพกิจกรรมติดตามหนี้. เหตุผลที่สำคัญ วัดประสิทธิผลของกระบวนการติดตามหนี้จากการติดตามผลการจัดการบัญชีค้างชำระจนได้ข้อยุติ ช่วยปรับกลยุทธ์ติดตามหนี้ให้เหมาะสม. แหล่งข้อมูล ข้อมูลนี้น่าจะอยู่ในฟิลด์สถานะของบัญชีผู้ป่วยหรือในโมดูลติดตามหนี้โดยเฉพาะของ R1 RCM. ตัวอย่าง ชำระครบแล้วตกลงชำระยอดที่ลดลงส่งให้บริษัทติดตามหนี้ภายนอกตัดเป็นหนี้สูญ
	ยอดเงินที่ปรับปรุง AdjustmentAmount	มูลค่าเงินของรายการปรับปรุงยอดคงเหลือในบัญชี.
คำอธิบาย แอตทริบิวต์นี้บันทึกมูลค่าของรายการปรับปรุงทางการเงินที่เกิดขึ้นกับบัญชีผู้ป่วยหลังจากเรียกเก็บเงินครั้งแรก รายการปรับปรุงอาจเป็นยอดบวกหรือลบ และรวมถึงส่วนลดตามสัญญา การตัดหนี้สูญ หรือการแก้ไขยอด การติดตามยอดเงินที่ปรับปรุงมีความสำคัญต่อการทำความเข้าใจความถูกต้องของรายได้ หากมียอดปรับปรุงติดลบสูง อาจบ่งชี้ว่ารายได้รั่วไหลจากปัญหา เช่น การบันทึกค่าใช้จ่ายไม่ถูกต้องหรือหนี้ที่เรียกเก็บไม่ได้ การวิเคราะห์ข้อมูลนี้ช่วยระบุผลกระทบทางการเงินจากข้อผิดพลาดในการเรียกเก็บเงินและความไม่มีประสิทธิภาพในการติดตามหนี้. เหตุผลที่สำคัญ ช่วยวัดรายได้ที่รั่วไหลและการแก้ไขทางการเงิน พร้อมระบุผลกระทบด้านมูลค่าเงินจากการเรียกเก็บเงินไม่ถูกต้อง ภาระผูกพันตามสัญญา หรือหนี้สูญ. แหล่งข้อมูล ค้นหาได้จากบันทึกธุรกรรมที่เกี่ยวข้องกับการปรับปรุงบัญชีหรือการบันทึกการชำระเงินใน R1 RCM. ตัวอย่าง -50.2520.00-1200.00
	รหัสบริการ ServiceCode	รหัสเรียกเก็บเงินของบริการหรือหัตถการที่ให้ เช่น รหัส CPT หรือ HCPCS.
คำอธิบาย รหัสบริการ เช่น รหัส CPT (Current Procedural Terminology) เป็นรหัสทางการแพทย์มาตรฐานที่ใช้แจ้งผู้จ่ายเงินเกี่ยวกับหัตถการและบริการทางการแพทย์ ศัลยกรรม และการวินิจฉัย เพื่อขอรับชำระเงินคืน การวิเคราะห์กระบวนการตามรหัสบริการจำเป็นต่อการค้นหาปัญหาการเรียกเก็บเงินที่เกี่ยวข้องกับการดูแลแต่ละประเภท ช่วยให้เห็นว่าหัตถการใดถูกปฏิเสธบ่อยที่สุด ใช้เวลาชำระเงินนานที่สุด หรือต้องแก้ไขงานซ้ำมากที่สุด เพื่อนำไปปรับปรุงการลงรหัสและการเรียกเก็บเงินได้ตรงจุด. เหตุผลที่สำคัญ ช่วยวิเคราะห์กระบวนการตามประเภทบริการที่ให้ ซึ่งเป็นกุญแจสำคัญในการระบุรูปแบบการปฏิเสธเคลมหรือความล่าช้าในการชำระเงินที่เกี่ยวข้องกับหัตถการแต่ละประเภท. แหล่งข้อมูล ข้อมูลนี้อยู่ในระดับรายการย่อยของค่าใช้จ่ายหรือเคลมแต่ละรายการใน R1 RCM. ตัวอย่าง 992139928573560
	รหัสผู้ป่วย PatientId	รหัสเฉพาะของผู้ป่วยที่ได้รับบริการ.
คำอธิบาย แอตทริบิวต์นี้คือรหัสเฉพาะที่กำหนดให้ผู้ป่วยในระบบสาธารณสุข ซึ่งมักเรียกว่าหมายเลขเวชระเบียน (MRN) แม้การดูแลผู้ป่วยรายบุคคลจะไม่ใช่จุดเน้น แต่คุณสามารถใช้รหัสผู้ป่วยวิเคราะห์ปัญหาการเรียกเก็บเงินที่เกิดซ้ำกับผู้ป่วยรายเดิมได้ นอกจากนี้ยังใช้แบ่งกลุ่มกระบวนการตามข้อมูลประชากรหรือประวัติผู้ป่วยได้ หากเชื่อมโยงกับข้อมูลผู้ป่วยอื่นๆ ซึ่งอาจช่วยค้นหาปัญหาเชิงระบบที่กระทบผู้ป่วยบางกลุ่ม. เหตุผลที่สำคัญ ช่วยวิเคราะห์เหตุการณ์เรียกเก็บเงินในระดับผู้ป่วย เพื่อค้นหาปัญหาหรือรูปแบบที่เกิดซ้ำกับผู้ป่วยรายเดิมจากการเข้ารับบริการหลายครั้ง. แหล่งข้อมูล รหัสนี้เป็นส่วนสำคัญของข้อมูลประชากรผู้ป่วย ซึ่งเชื่อมโยงกับรายการรับบริการและเคลมทุกรายการใน R1 RCM. ตัวอย่าง MRN837262MRN937281MRN103847
	ระยะเวลาตั้งแต่ให้บริการจนได้รับชำระเงิน ServiceToPaymentCycleTime	ระยะเวลารวมที่คำนวณตั้งแต่ให้บริการจนถึงบันทึกการชำระเงินครั้งสุดท้าย.
คำอธิบาย ตัวชี้วัดนี้วัดระยะเวลาตั้งแต่ต้นจนจบของวงจรรายได้สำหรับเหตุการณ์เรียกเก็บเงินหนึ่งรายการ โดยแสดงเวลาทั้งหมดที่องค์กรใช้เปลี่ยนบริการที่ให้ไปเป็นเงินสด นี่คือตัวชี้วัดประสิทธิภาพหลัก (KPI) ที่สำคัญต่อสถานะทางการเงิน การวิเคราะห์ระยะเวลานี้ช่วยระบุจุดสำคัญที่ควรเร่งกระบวนการ เมื่อแยกรอบเวลาดำเนินการออกเป็นส่วนย่อย เช่น 'เวลาจนถึงการเรียกเก็บเงิน' และ 'เวลาจนถึงการชำระเงิน' องค์กรจะเห็นโอกาสสำคัญที่สุดในการเพิ่มกระแสเงินสดได้ชัดเจน. เหตุผลที่สำคัญ KPI ระดับภาพรวมที่สำคัญนี้วัดประสิทธิภาพโดยรวมของวงจรเปลี่ยนรายได้เป็นเงินสด ซึ่งส่งผลโดยตรงต่อกระแสเงินสดขององค์กร. แหล่งข้อมูล นี่คือตัวชี้วัดที่คำนวณจากผลต่างของเวลาระหว่างกิจกรรม 'ให้บริการแล้ว' และ 'บันทึกการรับชำระเงินแล้ว' สำหรับเหตุการณ์เรียกเก็บเงินหนึ่งรายการ. ตัวอย่าง 35 วัน 8 ชั่วโมง92 วัน 4 ชั่วโมง15 วัน 12 ชั่วโมง
	เหตุผลในการปรับปรุง AdjustmentReason	เหตุผลของการปรับปรุงทางการเงิน เช่น “ส่วนลดตามสัญญา” หรือ “ตัดหนี้สูญ”.
คำอธิบาย แอตทริบิวต์นี้ระบุสาเหตุที่มีการปรับปรุงทางการเงินในบัญชี โดยเหตุผลมักเป็นรหัสหรือคำอธิบายมาตรฐานที่จัดประเภทการปรับปรุง การวิเคราะห์เหตุผลในการปรับปรุงช่วยค้นหาสาเหตุหลักของรายได้ที่รั่วไหล ตัวอย่างเช่น หากพบการ “ตัดหนี้สูญยอดคงเหลือจำนวนน้อย” บ่อยครั้ง อาจแสดงว่ากระบวนการติดตามหนี้สำหรับยอดเงินจำนวนน้อยไม่มีประสิทธิภาพ ส่วนการ “ให้ส่วนลดตามสัญญา” บ่อยครั้งอาจเป็นผลตามปกติของการเจรจากับผู้จ่ายเงิน การวิเคราะห์นี้ช่วยสนับสนุนแดชบอร์ดการตรวจสอบการปรับปรุงยอดเรียกเก็บเงินและการปฏิบัติตามข้อกำหนด. เหตุผลที่สำคัญ อธิบายสาเหตุของการปรับปรุงรายได้ ช่วยระบุต้นตอของการสูญเสียรายได้ เช่น ปัญหาสัญญา ข้อผิดพลาดในการเรียกเก็บเงิน หรือการติดตามหนี้ที่ไม่สำเร็จ. แหล่งข้อมูล โดยทั่วไปเป็นฟิลด์รหัสหรือข้อความในระเบียนธุรกรรมเดียวกับ AdjustmentAmount ใน R1 RCM. ตัวอย่าง ส่วนลดตามสัญญาตัดหนี้สูญตัดหนี้สูญยอดคงเหลือจำนวนน้อยแก้ไขข้อผิดพลาดในการเรียกเก็บเงิน

จำเป็น แนะนำ ไม่บังคับ

กิจกรรมในการจัดการวงจรรายได้

ขั้นตอนและจุดสำคัญของกระบวนการที่ควรบันทึกในบันทึกเหตุการณ์ เพื่อค้นพบกระบวนการจัดการวงจรรายได้ได้อย่างแม่นยำ.

6 แนะนำ 8 ไม่บังคับ

	กิจกรรม	คำอธิบาย
	ได้รับชำระเงินแล้ว	ได้รับชำระเงินจากผู้ชำระเงินหรือผู้ป่วย เหตุการณ์นี้หมายถึงได้รับเงินแล้ว แต่ยังไม่ได้นำเงินไปลงบัญชีของบัญชีหรือรายการบริการที่เกี่ยวข้อง.
เหตุผลที่สำคัญ หมายถึงเงินสดรับ ช่วงเวลาระหว่าง 'ได้รับชำระเงิน' กับ 'บันทึกการชำระเงิน' เป็นตัวชี้วัดสำคัญในการทำความเข้าใจประสิทธิภาพงานหลังบ้านและความล่าช้าในการกระทบยอดเงินสด. แหล่งข้อมูล บันทึกจากไฟล์ส่งเงินอิเล็กทรอนิกส์ของผู้ชำระเงิน หรือจากการประมวลผลการชำระเงินของผู้ป่วย เหตุการณ์นี้ตรงกับวันที่ฝากเงินหรือวันที่ได้รับไฟล์. บันทึก บันทึกจากวันที่มีผลของการชำระเงินในไฟล์ ERA หรือวันที่ทำธุรกรรมชำระเงินของผู้ป่วย. ประเภทเหตุการณ์ explicit
	บันทึกการชำระเงินแล้ว	นำเงินที่ได้รับไปลงบัญชีผู้ป่วยอย่างเป็นทางการ ทำให้ยอดค้างชำระลดลง นี่เป็นขั้นตอนสุดท้ายในการกระทบยอดการชำระเงินกับบริการที่เรียกเก็บเงิน.
เหตุผลที่สำคัญ กิจกรรมนี้เป็นจุดสิ้นสุดสำหรับคำนวณเวลาตั้งแต่ให้บริการจนได้รับชำระเงิน และเวลารอบการบันทึกการชำระเงิน อีกทั้งยืนยันว่ารับรู้รายได้แล้วและอัปเดตบัญชีอย่างถูกต้อง. แหล่งข้อมูล บันทึกเป็นธุรกรรมทางการเงินโดยตรงในโมดูลบัญชีผู้ป่วยของ R1 RCM การบันทึกแต่ละครั้งมีวันที่ จำนวนเงิน และแหล่งที่มา. บันทึก บันทึกเป็นธุรกรรมเฉพาะพร้อมวันที่บันทึก เมื่อผู้ใช้หรือกระบวนการอัตโนมัตินำการชำระเงินไปลงบัญชี. ประเภทเหตุการณ์ explicit
	บันทึกค่าบริการ	กิจกรรมนี้หมายถึงการบันทึกบริการ หัตถการ และเวชภัณฑ์ทั้งหมดที่เรียกเก็บเงินได้สำหรับการเข้ารับบริการของผู้ป่วยอย่างเป็นทางการ เป็นขั้นตอนสำคัญในการป้อนข้อมูลเพื่อแปลงกิจกรรมทางคลินิกเป็นธุรกรรมทางการเงิน.
เหตุผลที่สำคัญ เป็นจุดส่งต่องานจากฝ่ายคลินิกไปยังฝ่ายการเงิน และเป็นจุดเริ่มต้นในการวัดเวลารอบการสร้างใบแจ้งหนี้และเคลม อีกทั้งช่วยระบุงานค้างในการบันทึกค่าบริการ. แหล่งข้อมูล บันทึกในโมดูลบันทึกค่าบริการของ R1 RCM หรือรับข้อมูลผ่านอินเทอร์เฟซจาก EHR โดยทั่วไปเหตุการณ์นี้ระบุได้จากบันทึกธุรกรรมเฉพาะหรือเวลาที่สร้างรายการค่าบริการ. บันทึก ระบุจากเวลาที่สร้างรายการธุรกรรมค่าบริการในตารางวางบิล. ประเภทเหตุการณ์ explicit
	ปิดบัญชีแล้ว	จัดการเหตุการณ์วางบิลเสร็จสมบูรณ์โดยไม่มียอดคงเหลือ และปิดบัญชีอย่างเป็นทางการ ซึ่งหมายถึงวงจรรายได้ของการเข้ารับบริการครั้งนี้เสร็จสิ้น.
เหตุผลที่สำคัญ นี่คือเหตุการณ์สิ้นสุดของเส้นทางปกติที่สำเร็จ การวัดเวลารอบการปิดบัญชีช่วยให้มั่นใจว่างานธุรการเสร็จอย่างมีประสิทธิภาพและปิดบันทึกเรียบร้อย. แหล่งข้อมูล อนุมานเหตุการณ์นี้เมื่อยอดบัญชีเป็นศูนย์และกำหนดสถานะสุดท้ายเป็น 'ปิดแล้ว' หรือ 'ชำระครบแล้ว' โดยใช้เวลาของธุรกรรมทางการเงินล่าสุดที่ทำให้ยอดเป็นศูนย์. บันทึก อนุมานเมื่อยอดบัญชีเป็นศูนย์และกำหนดสถานะ 'ปิดแล้ว' พร้อมเวลาประทับของกิจกรรมสุดท้าย. ประเภทเหตุการณ์ inferred
	ส่งเคลมแล้ว	ส่งเคลมที่สร้างขึ้นทางอิเล็กทรอนิกส์ไปยังผู้ชำระเงินที่รับผิดชอบ เช่น บริษัทประกัน นี่เป็นการติดต่อกับหน่วยงานภายนอกครั้งแรกในกระบวนการวางบิลเพื่อขอรับเงินชดเชย.
เหตุผลที่สำคัญ เป็นหมุดหมายสำคัญที่เริ่มนับเวลารอการชำระเงินจากผู้ชำระเงิน การติดตามขั้นตอนนี้ช่วยตรวจสอบงานส่งเคลมค้างและให้แน่ใจว่าส่งเคลมภายในกำหนด. แหล่งข้อมูล ระบบบันทึกเหตุการณ์นี้เป็นธุรกรรมโดยตรงเมื่อส่งเคลมไปยังศูนย์รับส่งข้อมูล โดยบันทึกเวลาส่งและรายละเอียดการยืนยัน. บันทึก บันทึกเป็นธุรกรรมโดยตรงพร้อมเวลาส่ง เมื่อส่งเคลมผ่านศูนย์รับส่งข้อมูล. ประเภทเหตุการณ์ explicit
	ให้บริการเสร็จสิ้น	หมายถึงจุดที่ให้บริการหรือทำหัตถการที่เรียกเก็บเงินได้แก่ผู้ป่วยเสร็จสิ้น เหตุการณ์นี้มักบันทึกจากระบบคลินิกหรือระบบนัดหมาย และเป็นจุดเริ่มต้นของวงจรรายได้.
เหตุผลที่สำคัญ นี่คือจุดเริ่มต้นสำหรับ KPI เวลาตั้งแต่ให้บริการจนได้รับชำระเงิน การวิเคราะห์เวลาตั้งแต่เหตุการณ์นี้ช่วยระบุความล่าช้าในช่วงต้นของวงจรรายได้. แหล่งข้อมูล โดยทั่วไปข้อมูลมาจากเวชระเบียนอิเล็กทรอนิกส์ (EHR) หรือระบบบริหารจัดการสถานพยาบาลที่เชื่อมต่อกับ R1 RCM มักอนุมานจากเวลา 'วันที่ให้บริการ' หรือ 'ทำหัตถการเสร็จ' ในประวัติผู้ป่วย. บันทึก อนุมานจากเวลาประทับ 'วันที่ให้บริการ' ที่เชื่อมโยงกับการเข้ารับบริการของผู้ป่วย. ประเภทเหตุการณ์ inferred
	เคลมถูกปฏิเสธ	ผู้ชำระเงินปฏิเสธการจ่ายเคลมทั้งหมดหรือบางรายการ ระบบบันทึกเหตุผลที่ปฏิเสธและเริ่มกระบวนการแก้ไขงานและยื่นอุทธรณ์.
เหตุผลที่สำคัญ กิจกรรมนี้ชี้ให้เห็นรายได้ที่สูญเสียและความไม่มีประสิทธิภาพของกระบวนการ การวิเคราะห์เหตุผลที่เคลมถูกปฏิเสธมีความสำคัญต่อการค้นหาสาเหตุที่แท้จริงและเพิ่มอัตราการอนุมัติเคลมตั้งแต่ครั้งแรก. แหล่งข้อมูล นี่ไม่ใช่เหตุการณ์ที่บันทึกแยกต่างหาก แต่เป็นสถานะที่อนุมานจากรายละเอียดในไฟล์ ERA ที่ประมวลผลแล้ว รหัสการปฏิเสธเฉพาะในข้อมูลการส่งเงินจะทำให้สถานะเคลมเปลี่ยนไป. บันทึก อนุมานจากรหัสการปฏิเสธในไฟล์ ERA ที่ประมวลผลแล้ว ซึ่งเปลี่ยนสถานะเคลมเป็น 'ถูกปฏิเสธ'. ประเภทเหตุการณ์ inferred
	จัดบัญชีเป็นหนี้สูญ	ดำเนินการติดตามหนี้ครบทุกวิธีแล้ว และถือว่ายอดคงเหลือที่เหลือเรียกเก็บไม่ได้ ยอดดังกล่าวถูกตัดเป็นหนี้สูญ ซึ่งหมายถึงการสูญเสียรายได้ในขั้นสุดท้าย.
เหตุผลที่สำคัญ ผลลัพธ์นี้เป็นผลลัพธ์เชิงลบของกระบวนการและทำให้สูญเสียรายได้โดยตรง การวิเคราะห์เคสที่กลายเป็นหนี้สูญช่วยให้เห็นรูปแบบการไม่ชำระเงินและโอกาสในการปรับปรุงการติดตามหนี้. แหล่งข้อมูล โดยทั่วไปเป็นธุรกรรมโดยตรงใน R1 RCM ที่ย้ายยอดค้างชำระไปยังหมวดหนี้สูญเฉพาะ ซึ่งมักเริ่มจากผู้ใช้หรือกฎกำหนดอายุหนี้อัตโนมัติ. บันทึก บันทึกเป็นธุรกรรมทางการเงินเฉพาะเพื่อตัดยอดคงเหลือเป็นหนี้สูญ โดยมักเชื่อมโยงกับการโอนบัญชีให้บริษัทติดตามหนี้ภายนอก. ประเภทเหตุการณ์ explicit
	ได้รับผลพิจารณาเคลมจากผู้ชำระเงิน	ระบบได้รับคำตอบจากผู้ชำระเงินเกี่ยวกับเคลมที่ส่งไป โดยมักอยู่ในไฟล์ Electronic Remittance Advice (ERA) ซึ่งระบุรายละเอียดว่าเคลมใดได้รับชำระ ถูกปฏิเสธ หรือปรับยอด.
เหตุผลที่สำคัญ เหตุการณ์นี้เป็นจุดแยกสำคัญของกระบวนการ โดยกำหนดว่าขั้นตอนถัดไปจะเป็นการบันทึกการชำระเงินหรือการจัดการเคลมที่ถูกปฏิเสธ การวิเคราะห์ช่วยให้เข้าใจพฤติกรรมของผู้ชำระเงินและความเร็วในการชำระเงิน. แหล่งข้อมูล บันทึกเมื่อ R1 RCM ประมวลผลไฟล์ส่งเงินอิเล็กทรอนิกส์จากผู้ชำระเงิน เช่น ไฟล์ ANSI 835 โดยใช้เวลาที่ประมวลผลไฟล์เป็นเวลาของเหตุการณ์. บันทึก บันทึกเมื่อรับและประมวลผลไฟล์ Electronic Remittance Advice (ERA/835). ประเภทเหตุการณ์ explicit
	ปรับยอดบัญชีแล้ว	บันทึกธุรกรรมที่ไม่ใช่การชำระเงินลงในบัญชีเพื่อปรับยอด ซึ่งอาจรวมถึงการปรับตามสัญญากับผู้ชำระเงิน การตัดยอดคงเหลือจำนวนเล็กน้อย หรือการแก้ไขรายการ.
เหตุผลที่สำคัญ การปรับยอดจำนวนมากอาจบ่งชี้ถึงปัญหาเกี่ยวกับตารางค่าบริการ การจัดการสัญญา หรือข้อผิดพลาดในการวางบิล การติดตามการปรับยอดจึงสำคัญต่อการวิเคราะห์ความถูกต้องของรายได้. แหล่งข้อมูล บันทึกเป็นประเภทธุรกรรมเฉพาะในโมดูลบัญชีผู้ป่วยของ R1 RCM การปรับยอดแต่ละครั้งมีรหัส จำนวนเงิน และวันที่บันทึก. บันทึก บันทึกเป็นธุรกรรมปรับยอดแยกต่างหาก ซึ่งระบุได้ด้วยรหัสธุรกรรมเฉพาะ. ประเภทเหตุการณ์ explicit
	เริ่มกิจกรรมติดตามหนี้	บัญชีผู้ป่วยค้างชำระและเริ่มดำเนินการติดตามหนี้เชิงรุก ซึ่งอาจมีตั้งแต่ส่งจดหมายเตือนอัตโนมัติไปจนถึงมอบหมายให้ผู้เชี่ยวชาญด้านการติดตามหนี้.
เหตุผลที่สำคัญ เป็นจุดเริ่มต้นของกระบวนการติดตามหนี้ที่มีต้นทุนสูง การวิเคราะห์ประสิทธิผลและเวลารอบของกิจกรรมเหล่านี้ช่วยปรับกลยุทธ์การเรียกเก็บหนี้สูญให้เหมาะสม. แหล่งข้อมูล เหตุการณ์นี้อาจบันทึกหรืออนุมานจากการเปลี่ยนสถานะ เมื่อย้ายบัญชีไปยังคิวงานติดตามหนี้หรือกำหนดรหัสสถานะติดตามหนี้ใน R1 RCM. บันทึก อนุมานจากการเปลี่ยนสถานะบัญชีเป็น 'ติดตามหนี้' หรือ 'ค้างชำระ'. ประเภทเหตุการณ์ inferred
	เริ่มแก้ไขเคลมที่ถูกปฏิเสธ	ผู้ใช้หรือเวิร์กโฟลว์อัตโนมัติเริ่มตรวจสอบและแก้ไขเคลมที่ถูกปฏิเสธ ซึ่งอาจรวมถึงการแก้รหัสบริการ ส่งเอกสาร หรือยื่นอุทธรณ์คำตัดสินของผู้ชำระเงิน.
เหตุผลที่สำคัญ ติดตามจุดเริ่มต้นของวงจรแก้ไขงานที่มีต้นทุนสูงสำหรับเคลมที่ถูกปฏิเสธ การวัดเวลาที่ใช้ในช่วงนี้เป็นกุญแจสำคัญในการทำความเข้าใจประสิทธิภาพของทีมจัดการเคลมที่ถูกปฏิเสธ. แหล่งข้อมูล มักอนุมานจากการเปลี่ยนสถานะของเคลมที่ถูกปฏิเสธเป็น 'กำลังแก้ไข' หรือ 'อยู่ระหว่างตรวจสอบ' ในคิวงานหรือโมดูลจัดการเคลมที่ถูกปฏิเสธของ R1 RCM. บันทึก อนุมานจากการเปลี่ยนสถานะในคิวงานจัดการเคลมที่ถูกปฏิเสธ หรือจากการดำเนินการครั้งแรกของผู้ใช้กับเคลมที่ถูกปฏิเสธ. ประเภทเหตุการณ์ inferred
	สร้างเคลมแล้ว	ระบบสร้างเคลมวางบิลอย่างเป็นทางการจากค่าบริการที่บันทึกไว้ โดยรวบรวมข้อมูลประชากรของผู้ป่วย ข้อมูลประกัน และรหัสบริการให้อยู่ในรูปแบบมาตรฐาน.
เหตุผลที่สำคัญ นี่คือหมุดหมายสำคัญภายในองค์กรก่อนส่งเคลมออกไป ความล่าช้าในขั้นตอนนี้อาจบ่งชี้ถึงปัญหาการลงรหัส การตรวจสอบข้อมูล หรือการตั้งค่าระบบที่ทำให้กระบวนการวางบิลทั้งหมดช้าลง. แหล่งข้อมูล นี่คือเหตุการณ์ภายในระบบ R1 RCM ซึ่งอาจบันทึกเป็นการเปลี่ยนสถานะของบัญชีวางบิล หรือใช้เวลาที่สร้างรายการเคลม. บันทึก อนุมานจากการเปลี่ยนสถานะเป็น 'สร้างเคลมแล้ว' หรือเวลาที่สร้างรายการเคลม. ประเภทเหตุการณ์ inferred
	สร้างใบแจ้งยอดผู้ป่วยแล้ว	หลังจากผู้ประกันพิจารณาเคลมแล้ว ระบบจะสร้างใบแจ้งยอดให้ผู้ป่วย โดยระบุยอดคงเหลือที่ผู้ป่วยต้องรับผิดชอบ เช่น ค่าร่วมจ่าย ค่าเสียหายส่วนแรก หรือบริการที่ไม่อยู่ในความคุ้มครอง.
เหตุผลที่สำคัญ กิจกรรมนี้เริ่มช่วงการชำระเงินจากผู้ป่วยในวงจรรายได้ การวิเคราะห์เวลาและความถี่มีความสำคัญต่อการจัดการการเรียกเก็บเงินจากผู้ป่วยและกระแสเงินสด. แหล่งข้อมูล โดยทั่วไปบันทึกเป็นเหตุการณ์เมื่อเรียกใช้กระบวนการชุดเพื่อสร้างและพิมพ์หรือส่งใบแจ้งยอดผู้ป่วยทางอิเล็กทรอนิกส์ R1 RCM จะบันทึกวันที่สร้างใบแจ้งยอด. บันทึก บันทึกเป็นธุรกรรมเมื่อเรียกใช้กระบวนการชุดเพื่อสร้างใบแจ้งยอดผู้ป่วย. ประเภทเหตุการณ์ explicit

แนะนำ ไม่บังคับ

คู่มือการดึงข้อมูล

วิธีดึงข้อมูลจาก R1 RCM

ขั้นตอน

เข้าสู่ระบบแพลตฟอร์ม R1 RCM ด้วยบัญชีผู้ใช้ที่มีสิทธิ์เข้าถึงโมดูล Business Intelligence หรือการรายงาน.
ไปที่ส่วนรายงานของแพลตฟอร์ม ซึ่งอาจใช้ชื่อว่า "Business Intelligence", "Reporting Portal" หรือ "Analytics".
ค้นหาเครื่องมือสำหรับสร้างรายงานหรือคิวรีแบบกำหนดเอง ซึ่งช่วยให้คุณระบุฟิลด์ข้อมูลและตรรกะที่ต้องการใช้ดึงข้อมูลได้.
เนื่องจาก R1 RCM ไม่มีบันทึกเหตุการณ์แบบรวมที่สร้างไว้ล่วงหน้า คุณต้องสร้างขึ้นโดยรวมข้อมูลจากแหล่งต่างๆ การกำหนดค่าคิวรีที่ให้มาจะใช้วิธี UNION ALL เพื่อรวมเหตุการณ์จากออบเจ็กต์ทางธุรกิจต่างๆ ให้เป็นบันทึกตามลำดับเวลาเดียวกัน.
คัดลอกคิวรีทั้งหมดจากส่วน "Query" ในเอกสารนี้ แล้ววางลงในตัวแก้ไขคิวรีหรือหน้ากำหนดค่าของรายงานแบบกำหนดเอง.
กำหนดพารามิเตอร์รายงาน โดยเฉพาะช่วงวันที่ ตั้งค่าตัวแทน '{StartDate}' และ '{EndDate}' ในคิวรีเพื่อระบุช่วงเวลาที่ต้องการดึงข้อมูล เช่น 6 เดือนล่าสุด.
เพิ่มตัวกรองอื่นๆ ที่จำเป็นในการกำหนดค่ารายงาน เช่น สถานพยาบาล แผนก หรือกลุ่มผู้ชำระเงิน เพื่อจำกัดขอบเขตข้อมูล.
เรียกใช้รายงาน คิวรีจะทำงานกับฐานข้อมูล R1 RCM และสร้างผลลัพธ์ตามพารามิเตอร์ที่คุณกำหนด.
เมื่อรายงานทำงานเสร็จแล้ว ให้เลือกส่งออกข้อมูล แล้วเลือก CSV (Comma Separated Values) เป็นรูปแบบไฟล์ ซึ่งใช้กับ ProcessMind ได้โดยตรง.
ดาวน์โหลดไฟล์ CSV แล้วเปิดตรวจสอบเบื้องต้น ชื่อหัวคอลัมน์ต้องตรงกับแอตทริบิวต์ที่กำหนด ได้แก่ BillingEvent, ActivityName, EventTime, SourceSystem และ LastDataUpdate.
ตรวจสอบให้แน่ใจว่ารูปแบบวันที่และเวลาในคอลัมน์ EventTime และ LastDataUpdate สอดคล้องกัน ก่อนอัปโหลดไฟล์ไปยัง ProcessMind.

การกำหนดค่า

ข้อกำหนดเบื้องต้น: ต้องมีบัญชีผู้ใช้ที่มีสิทธิ์เพียงพอในการเข้าถึงและสร้างรายงานแบบกำหนดเองในโมดูล R1 RCM Business Intelligence.
ประเภทรายงาน: ใช้คิวรีแบบกำหนดเองหรือตัวสร้างรายงานขั้นสูงที่ดึงข้อมูลซับซ้อนและใช้คำสั่ง UNION ALL เพื่อรวมชุดข้อมูลต่างๆ ได้.
ช่วงวันที่: เพื่อควบคุมประสิทธิภาพและปริมาณข้อมูล ควรกรองตามช่วงเวลาที่กำหนด แนะนำให้เริ่มวิเคราะห์ครั้งแรกด้วยช่วง 3 ถึง 6 เดือน โดยใช้ฟิลด์เวลาหลักของแต่ละกิจกรรมเป็นตัวกรองวันที่.
ตัวกรองสำคัญ: นอกจากช่วงวันที่แล้ว ให้พิจารณากรองตาม Facility ID, Payer Type หรือ Billing Department เพื่อเน้นพื้นที่ปฏิบัติการที่ต้องการและลดขนาดไฟล์ส่งออก.
รูปแบบไฟล์ส่งออก: เลือก CSV เป็นรูปแบบผลลัพธ์เสมอ เพื่อให้ได้ไฟล์ที่มีโครงสร้างชัดเจนและเครื่องมือ process mining อ่านได้ง่าย.
การตั้งเวลารายงาน: หากโมดูลรายงาน R1 RCM รองรับ ให้ตั้งเวลารายงานให้ทำงานซ้ำ เช่น รายสัปดาห์หรือรายเดือน เพื่อให้ข้อมูลอัปเดตโดยอัตโนมัติและติดตามได้ต่อเนื่อง.

ตัวอย่างคำค้น sql

SELECT
    c.ClaimID AS BillingEvent,
    'Service Rendered' AS ActivityName,
    c.ServiceDate AS EventTime,
    'R1 RCM' AS SourceSystem,
    GETDATE() AS LastDataUpdate,
    c.ClinicianID AS AssignedUser,
    d.DepartmentName AS BillingDepartment,
    c.TotalChargeAmount AS InvoiceAmount,
    p.PayerName AS PayerName,
    'Rendered' AS InvoiceStatus,
    NULL AS DenialReasonCode
FROM [ServiceAndChargeData] c
JOIN [Departments] d ON c.DepartmentID = d.DepartmentID
JOIN [Payers] p ON c.PayerID = p.PayerID
WHERE c.ServiceDate BETWEEN '{StartDate}' AND '{EndDate}'

UNION ALL

SELECT
    c.ClaimID AS BillingEvent,
    'Charges Captured' AS ActivityName,
    c.ChargeEntryTimestamp AS EventTime,
    'R1 RCM' AS SourceSystem,
    GETDATE() AS LastDataUpdate,
    c.ChargeEntryUserID AS AssignedUser,
    d.DepartmentName AS BillingDepartment,
    c.TotalChargeAmount AS InvoiceAmount,
    p.PayerName AS PayerName,
    'Open' AS InvoiceStatus,
    NULL AS DenialReasonCode
FROM [ServiceAndChargeData] c
JOIN [Departments] d ON c.DepartmentID = d.DepartmentID
JOIN [Payers] p ON c.PayerID = p.PayerID
WHERE c.ChargeEntryTimestamp BETWEEN '{StartDate}' AND '{EndDate}'

UNION ALL

SELECT
    cl.ClaimID AS BillingEvent,
    'Claim Created' AS ActivityName,
    cl.CreationTimestamp AS EventTime,
    'R1 RCM' AS SourceSystem,
    GETDATE() AS LastDataUpdate,
    cl.CreatedByUserID AS AssignedUser,
    cl.BillingDepartment AS BillingDepartment,
    cl.TotalAmount AS InvoiceAmount,
    cl.PayerName AS PayerName,
    'Created' AS InvoiceStatus,
    NULL AS DenialReasonCode
FROM [ClaimsData] cl
WHERE cl.CreationTimestamp BETWEEN '{StartDate}' AND '{EndDate}'

UNION ALL

SELECT
    cl.ClaimID AS BillingEvent,
    'Claim Submitted' AS ActivityName,
    cl.SubmissionTimestamp AS EventTime,
    'R1 RCM' AS SourceSystem,
    GETDATE() AS LastDataUpdate,
    cl.SubmittedByUserID AS AssignedUser,
    cl.BillingDepartment AS BillingDepartment,
    cl.TotalAmount AS InvoiceAmount,
    cl.PayerName AS PayerName,
    'Submitted' AS InvoiceStatus,
    NULL AS DenialReasonCode
FROM [ClaimsData] cl
WHERE cl.SubmissionTimestamp BETWEEN '{StartDate}' AND '{EndDate}'

UNION ALL

SELECT
    era.ClaimID AS BillingEvent,
    'Payer Adjudication Received' AS ActivityName,
    era.ReceivedTimestamp AS EventTime,
    'R1 RCM' AS SourceSystem,
    GETDATE() AS LastDataUpdate,
    'System' AS AssignedUser,
    pa.BillingDepartment AS BillingDepartment,
    pa.InvoiceAmount AS InvoiceAmount,
    era.PayerName AS PayerName,
    'Adjudicated' AS InvoiceStatus,
    NULL AS DenialReasonCode
FROM [RemittanceAdvice] era
JOIN [PatientAccounts] pa ON era.ClaimID = pa.BillingEvent
WHERE era.ReceivedTimestamp BETWEEN '{StartDate}' AND '{EndDate}'

UNION ALL

SELECT
    d.ClaimID AS BillingEvent,
    'Claim Denied' AS ActivityName,
    d.DenialTimestamp AS EventTime,
    'R1 RCM' AS SourceSystem,
    GETDATE() AS LastDataUpdate,
    'System' AS AssignedUser,
    cl.BillingDepartment AS BillingDepartment,
    cl.TotalAmount AS InvoiceAmount,
    cl.PayerName AS PayerName,
    'Denied' AS InvoiceStatus,
    d.ReasonCode AS DenialReasonCode
FROM [DenialsLog] d
JOIN [ClaimsData] cl ON d.ClaimID = cl.ClaimID
WHERE d.DenialTimestamp BETWEEN '{StartDate}' AND '{EndDate}'

UNION ALL

SELECT
    dr.ClaimID AS BillingEvent,
    'Denial Rework Started' AS ActivityName,
    dr.ReworkStartTimestamp AS EventTime,
    'R1 RCM' AS SourceSystem,
    GETDATE() AS LastDataUpdate,
    dr.AssignedUserID AS AssignedUser,
    cl.BillingDepartment AS BillingDepartment,
    cl.TotalAmount AS InvoiceAmount,
    cl.PayerName AS PayerName,
    'In Rework' AS InvoiceStatus,
    dr.OriginalDenialCode AS DenialReasonCode
FROM [DenialRework] dr
JOIN [ClaimsData] cl ON dr.ClaimID = cl.ClaimID
WHERE dr.ReworkStartTimestamp BETWEEN '{StartDate}' AND '{EndDate}'

UNION ALL

SELECT
    ps.PatientAccountID AS BillingEvent,
    'Patient Statement Generated' AS ActivityName,
    ps.GenerationTimestamp AS EventTime,
    'R1 RCM' AS SourceSystem,
    GETDATE() AS LastDataUpdate,
    ps.GeneratedByUserID AS AssignedUser,
    pa.BillingDepartment AS BillingDepartment,
    ps.StatementBalance AS InvoiceAmount,
    'Patient' AS PayerName,
    'Patient Billed' AS InvoiceStatus,
    NULL AS DenialReasonCode
FROM [PatientStatements] ps
JOIN [PatientAccounts] pa ON ps.PatientAccountID = pa.BillingEvent
WHERE ps.GenerationTimestamp BETWEEN '{StartDate}' AND '{EndDate}'

UNION ALL

SELECT
    p.AssociatedClaimID AS BillingEvent,
    'Payment Received' AS ActivityName,
    p.ReceiptTimestamp AS EventTime,
    'R1 RCM' AS SourceSystem,
    GETDATE() AS LastDataUpdate,
    p.ProcessedByUserID AS AssignedUser,
    pa.BillingDepartment AS BillingDepartment,
    p.PaymentAmount AS InvoiceAmount,
    p.PayerName AS PayerName,
    'Payment Pending' AS InvoiceStatus,
    NULL AS DenialReasonCode
FROM [PaymentsLog] p
JOIN [PatientAccounts] pa ON p.AssociatedClaimID = pa.BillingEvent
WHERE p.ReceiptTimestamp BETWEEN '{StartDate}' AND '{EndDate}'

UNION ALL

SELECT
    pt.ClaimID AS BillingEvent,
    'Payment Posted' AS ActivityName,
    pt.PostingTimestamp AS EventTime,
    'R1 RCM' AS SourceSystem,
    GETDATE() AS LastDataUpdate,
    pt.PostedByUserID AS AssignedUser,
    pa.BillingDepartment AS BillingDepartment,
    pt.PostedAmount AS InvoiceAmount,
    pt.PayerName AS PayerName,
    'Partially Paid' AS InvoiceStatus,
    NULL AS DenialReasonCode
FROM [PaymentTransactions] pt
JOIN [PatientAccounts] pa ON pt.ClaimID = pa.BillingEvent
WHERE pt.PostingTimestamp BETWEEN '{StartDate}' AND '{EndDate}'

UNION ALL

SELECT
    a.ClaimID AS BillingEvent,
    'Account Adjustment Made' AS ActivityName,
    a.AdjustmentTimestamp AS EventTime,
    'R1 RCM' AS SourceSystem,
    GETDATE() AS LastDataUpdate,
    a.AdjusterID AS AssignedUser,
    pa.BillingDepartment AS BillingDepartment,
    a.AdjustmentAmount AS InvoiceAmount,
    pa.PayerName AS PayerName,
    'Adjusted' AS InvoiceStatus,
    NULL AS DenialReasonCode
FROM [Adjustments] a
JOIN [PatientAccounts] pa ON a.ClaimID = pa.BillingEvent
WHERE a.AdjustmentTimestamp BETWEEN '{StartDate}' AND '{EndDate}'

UNION ALL

SELECT
    ca.PatientAccountID AS BillingEvent,
    'Collection Activity Started' AS ActivityName,
    ca.ActivityTimestamp AS EventTime,
    'R1 RCM' AS SourceSystem,
    GETDATE() AS LastDataUpdate,
    ca.AssignedAgentID AS AssignedUser,
    'Collections' AS BillingDepartment,
    pa.CurrentBalance AS InvoiceAmount,
    'Patient' AS PayerName,
    'In Collections' AS InvoiceStatus,
    NULL AS DenialReasonCode
FROM [CollectionsActivity] ca
JOIN [PatientAccounts] pa ON ca.PatientAccountID = pa.BillingEvent
WHERE ca.ActivityTimestamp BETWEEN '{StartDate}' AND '{EndDate}'

UNION ALL

SELECT
    pa.BillingEvent AS BillingEvent,
    'Account Placed in Bad Debt' AS ActivityName,
    pa.BadDebtPlacementDate AS EventTime,
    'R1 RCM' AS SourceSystem,
    GETDATE() AS LastDataUpdate,
    pa.BadDebtUserID AS AssignedUser,
    'Finance' AS BillingDepartment,
    pa.CurrentBalance AS InvoiceAmount,
    'Patient' AS PayerName,
    'Bad Debt' AS InvoiceStatus,
    NULL AS DenialReasonCode
FROM [PatientAccounts] pa
WHERE pa.BadDebtPlacementDate BETWEEN '{StartDate}' AND '{EndDate}'

UNION ALL

SELECT
    pa.BillingEvent AS BillingEvent,
    'Account Closed' AS ActivityName,
    pa.ClosureDate AS EventTime,
    'R1 RCM' AS SourceSystem,
    GETDATE() AS LastDataUpdate,
    'System' AS AssignedUser,
    pa.BillingDepartment AS BillingDepartment,
    0 AS InvoiceAmount,
    pa.PayerName AS PayerName,
    'Closed' AS InvoiceStatus,
    NULL AS DenialReasonCode
FROM [PatientAccounts] pa
WHERE pa.ClosureDate BETWEEN '{StartDate}' AND '{EndDate}' AND pa.CurrentBalance = 0;

พร้อมเริ่มต้นหรือยัง?

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

กลับไปยังคู่มือการปรับปรุง

ดาวน์โหลดเทมเพลต

เพิ่มประสิทธิภาพ R1 RCM วันนี้ เพื่อยกระดับประสิทธิภาพวงจรรายได้

แก้คอขวดใน RCM ลดระยะเวลารอบการทำงาน 30% และเพิ่มกระแสเงินสด.

เริ่มทดลองใช้ฟรี

ไม่ต้องใช้บัตรเครดิต เริ่มใช้งานได้ในไม่กี่นาที.

เทมเพลตข้อมูลสำหรับการจัดการวงจรรายได้

เทมเพลตข้อมูลสำหรับการจัดการวงจรรายได้

แอตทริบิวต์สำหรับการจัดการวงจรรายได้

กิจกรรมในการจัดการวงจรรายได้

คู่มือการดึงข้อมูล

ส่งออกรายงาน Business Intelligence จาก R1 RCM

ขั้นตอน

การกำหนดค่า

ตัวอย่างคำค้น sql

พร้อมเริ่มต้นหรือยัง?

เพิ่มประสิทธิภาพ R1 RCM วันนี้ เพื่อยกระดับประสิทธิภาพวงจรรายได้