เทมเพลตข้อมูลการจัดการวงจรรายได้ของคุณ
เทมเพลตข้อมูลการจัดการวงจรรายได้ของคุณ
- แอตทริบิวต์ที่แนะนำให้รวบรวม
- กิจกรรมสำคัญที่ควรติดตาม
- คำแนะนำการดึงข้อมูลจาก Oracle Health Revenue Cycle
แอตทริบิวต์การจัดการวงจรรายได้
| ชื่อ | คำอธิบาย | ||
|---|---|---|---|
| ชื่อกิจกรรม ActivityName | ชื่อของขั้นตอนหรือเหตุการณ์ที่เกิดขึ้นในกระบวนการวงจรรายได้. | ||
| คำอธิบาย คุณลักษณะนี้บันทึกชื่อกิจกรรมแต่ละรายการที่เกิดขึ้นตลอดวงจรของรายการเรียกเก็บเงิน ตัวอย่างเช่น 'บันทึกค่าบริการ' 'ส่งเคลมให้ผู้จ่าย' และ 'บันทึกการรับชำระเงิน' กิจกรรมเหล่านี้เป็นจุดต่างๆ ในแผนผังกระบวนการที่ค้นพบ การวิเคราะห์ลำดับและความถี่ของกิจกรรมเป็นหัวใจของ process mining คุณลักษณะนี้ช่วยระบุเส้นทางกระบวนการที่พบบ่อยที่สุด ค้นหาความเบี่ยงเบนจากขั้นตอนมาตรฐาน และทำความเข้าใจขั้นตอนการปฏิบัติงานของวงจรรายได้. เหตุผลที่สำคัญ คุณลักษณะนี้กำหนดขั้นตอนในกระบวนการ ช่วยให้เห็นแผนผังกระบวนการและวิเคราะห์รูปแบบเวิร์กโฟลว์. แหล่งข้อมูล โดยทั่วไปได้มาจากบันทึกเหตุการณ์ ระเบียนการเปลี่ยนสถานะ หรือตารางธุรกรรมเฉพาะที่เกี่ยวข้องกับขั้นตอนต่างๆ ของวงจรรายได้ใน Oracle Health. ตัวอย่าง สร้างเคลมแล้วได้รับเอกสารแจ้งการชำระเงินแล้วยื่นอุทธรณ์การปฏิเสธเคลมแล้วปิดบัญชีแล้ว | |||
| เวลาที่เกิดเหตุการณ์ EventTimestamp | วันที่และเวลาที่แน่นอนซึ่งระบบบันทึกกิจกรรมไว้. | ||
| คำอธิบาย คุณลักษณะนี้ระบุเวลาของแต่ละกิจกรรม เพื่อบอกช่วงเวลาที่เกิดขึ้นอย่างแม่นยำ จำเป็นต่อการทำความเข้าใจเวลาและลำดับเหตุการณ์ในวงจรรายได้ของรายการเรียกเก็บเงินแต่ละรายการ ในการวิเคราะห์ จะใช้เวลาที่เกิดเหตุการณ์เพื่อเรียงลำดับกิจกรรมตามเวลา คำนวณระยะเวลาและเวลารอบระหว่างขั้นตอนต่างๆ และวิเคราะห์คอขวด ข้อมูลนี้เป็นพื้นฐานของตัวชี้วัด process mining ที่อิงตามเวลา เช่น การระบุความล่าช้าระหว่าง 'ส่งเคลมแล้ว' กับ 'ได้รับเอกสารแจ้งการชำระเงิน'. เหตุผลที่สำคัญ เวลานี้สำคัญต่อการเรียงลำดับเหตุการณ์ คำนวณตัวชี้วัดประสิทธิภาพทั้งหมด เช่น เวลาของแต่ละรอบและระยะเวลา รวมถึงระบุคอขวดในกระบวนการ. แหล่งข้อมูล ตารางธุรกรรมหรือบันทึกเหตุการณ์แต่ละตารางใน Oracle Health Revenue Cycle ควรมีคอลัมน์เวลาเพื่อระบุเวลาที่สร้างระเบียนหรือเกิดเหตุการณ์. ตัวอย่าง 2023-04-15T09:00:00Z2023-04-18T14:30:00Z2023-05-02T11:25:10Z | |||
| เหตุการณ์เรียกเก็บเงิน BillingEvent | รหัสเฉพาะของการให้บริการหรือส่งมอบผลิตภัณฑ์แต่ละครั้งที่ทำให้เกิดค่าบริการ ใช้เป็นรหัสกรณีสำหรับกระบวนการวงจรรายได้. | ||
| คำอธิบาย Billing Event ทำหน้าที่เป็นรหัสเคสหลักที่เชื่อมโยงกิจกรรมทั้งหมด ตั้งแต่การบันทึกค่าบริการไปจนถึงการปิดบัญชี สำหรับรายการที่เรียกเก็บเงินแต่ละรายการ Billing Event แต่ละรายการแทนกระบวนการวงจรรายรับหนึ่งกรณี จึงติดตามเส้นทางผ่านขั้นตอนต่างๆ ได้อย่างครบถ้วน เช่น การส่งเคลม การบันทึกการชำระเงิน และกรณีที่อาจถูกปฏิเสธหรือมีการปรับยอด ในการวิเคราะห์ process mining แอตทริบิวต์นี้เป็นพื้นฐานสำหรับสร้างภาพลำดับการทำงานตั้งแต่ต้นจนจบ ช่วยให้เห็นรูปแบบกระบวนการ คำนวณรอบเวลาดำเนินการระหว่างกิจกรรม และระบุคอขวดหรือความคลาดเคลื่อนที่เกี่ยวข้องกับรายการเรียกเก็บเงินแต่ละรายการได้ เหตุผลที่สำคัญ นี่คือรหัสสำคัญสำหรับติดตามวงจรทั้งหมดของบริการที่เรียกเก็บเงินได้ และใช้วิเคราะห์เส้นทางกระบวนการและวัดผลการดำเนินงาน. แหล่งข้อมูล รหัสนี้ควรเป็นคีย์เฉพาะที่มีอยู่ในตารางธุรกรรมหลักด้านการเรียกเก็บเงินหรือค่าบริการของ Oracle Health Revenue Cycle โปรดดูเอกสารระบบเพื่อระบุคีย์หลักของรายการค่าบริการ. ตัวอย่าง BEVNT-987654321BEVNT-987654322BEVNT-987654323 | |||
| ชื่อผู้จ่าย PayerName | ชื่อบริษัทประกันหรือผู้จ่ายบุคคลที่สามที่รับผิดชอบการชำระเงิน. | ||
| คำอธิบาย คุณลักษณะนี้ระบุหน่วยงานที่เรียกเก็บเงิน เช่น บริษัทประกันหรือโครงการของรัฐบาลอย่าง Medicare ข้อมูลผู้จ่ายเป็นพื้นฐานสำคัญของการวิเคราะห์วงจรรายได้ การวิเคราะห์กระบวนการแยกตามผู้จ่ายช่วยให้เห็นความแตกต่างของระยะเวลาชำระเงิน อัตราการปฏิเสธเคลม และอัตราความสำเร็จของการอุทธรณ์ นอกจากนี้ยังช่วยระบุผู้จ่ายที่ทำให้เกิดความล่าช้าหรือสูญเสียรายได้ และเป็นข้อมูลสำคัญสำหรับการบริหารสัญญาและความสัมพันธ์กับผู้จ่าย. เหตุผลที่สำคัญ ช่วยแยกวิเคราะห์กระบวนการตามผู้จ่าย เพื่อให้เห็นรูปแบบการดำเนินงาน อัตราการปฏิเสธเคลม และความเร็วในการชำระเงินที่แตกต่างกัน ซึ่งสำคัญต่อผลการดำเนินงานทางการเงิน. แหล่งข้อมูล ข้อมูลนี้จัดเก็บอยู่ในระเบียนการเรียกเก็บเงินหรือประกันของผู้ป่วยใน Oracle Health Revenue Cycle. ตัวอย่าง AetnaBlue Cross Blue ShieldUnitedHealthcareMedicareCigna | |||
| ประเภทผู้ป่วย PatientClass | การจัดประเภทการเข้ารับบริการของผู้ป่วย เช่น ผู้ป่วยในหรือผู้ป่วยนอก. | ||
| คำอธิบาย คุณลักษณะนี้จัดประเภทการเข้ารับบริการของผู้ป่วยที่ทำให้เกิดค่าบริการ โดยประเภทที่พบบ่อย ได้แก่ ผู้ป่วยใน ผู้ป่วยนอก ผู้ป่วยฉุกเฉิน และผู้ป่วยที่มารับบริการต่อเนื่อง ประเภทผู้ป่วยมักกำหนดขั้นตอนการเรียกเก็บเงินและการส่งเคลมทั้งหมด ผู้ป่วยแต่ละประเภทมีเส้นทางกระบวนการและข้อกำหนดด้านการปฏิบัติตามข้อกำหนดที่แตกต่างกัน การวิเคราะห์กระบวนการตามคุณลักษณะนี้ช่วยให้เข้าใจความแตกต่าง วางแผนการปรับปรุงให้เหมาะสม และมั่นใจว่ามีการปฏิบัติตามขั้นตอนที่ถูกต้องสำหรับผู้ป่วยแต่ละประเภท. เหตุผลที่สำคัญ แยกเส้นทางกระบวนการที่แตกต่างกัน เช่น ผู้ป่วยในกับผู้ป่วยนอก ซึ่งมีความซับซ้อน ระยะเวลา และข้อกำหนดการเรียกเก็บเงินไม่เหมือนกัน. แหล่งข้อมูล เป็นฟิลด์มาตรฐานที่เชื่อมโยงกับรายการรับบริการหรือระเบียนการรับผู้ป่วยเข้ารักษาใน Oracle Health. ตัวอย่าง ผู้ป่วยในผู้ป่วยนอกฉุกเฉินเกิดซ้ำ | |||
| ผู้ใช้ UserPerformingAction | รหัสหรือชื่อผู้ใช้ของผู้ที่ทำกิจกรรม. | ||
| คำอธิบาย คุณลักษณะนี้ระบุพนักงานหรือผู้ใช้ระบบอัตโนมัติที่รับผิดชอบกิจกรรมหนึ่งๆ ในกระบวนการ จำเป็นต่อการทำความเข้าใจการกระจายงาน ประสิทธิภาพของทรัพยากร และความต้องการด้านการฝึกอบรม ในการวิเคราะห์ คุณลักษณะนี้ช่วยกรองแผนผังกระบวนการตามผู้ใช้หรือทีม เปรียบเทียบประสิทธิภาพของทรัพยากรแต่ละกลุ่ม และวิเคราะห์ภาระงานในแดชบอร์ด 'ภาระงานแผนกเรียกเก็บเงิน' นอกจากนี้ยังช่วยระบุผู้ที่ทำงานได้ดีหรือผู้ที่อาจต้องการความช่วยเหลือหรือการฝึกอบรมเพิ่มเติม. เหตุผลที่สำคัญ เชื่อมโยงกิจกรรมในกระบวนการกับผู้ใช้หรือทีม ช่วยวิเคราะห์ภาระงาน เปรียบเทียบประสิทธิภาพ และค้นหาโอกาสในการฝึกอบรม. แหล่งข้อมูล โดยทั่วไปตารางธุรกรรมในโมดูลต่างๆ ของ Oracle Health จะมีฟิลด์รหัสผู้ใช้ เช่น 'CREATED_BY' และ 'USER_ID'. ตัวอย่าง j.doeasmithBillingBot_AUTOk.williams | |||
| แผนกเรียกเก็บเงิน BillingDepartment | แผนกหรือทีมงานที่รับผิดชอบกิจกรรม. | ||
| คำอธิบาย คุณลักษณะนี้ระบุแผนกที่ทำกิจกรรม เช่น 'บันทึกค่าบริการ' 'ลงรหัส' หรือ 'ติดตามหนี้' และแสดงบริบทด้านองค์กรของเส้นทางกระบวนการ การวิเคราะห์กระบวนการแยกตามแผนกจำเป็นต่อการทำความเข้าใจการส่งต่องานระหว่างทีมและการระบุจุดที่ทำงานข้ามฝ่ายได้ไม่มีประสิทธิภาพ นอกจากนี้ยังช่วยจัดกลุ่มกิจกรรมและตัวชี้วัดประสิทธิภาพตามแผนกในแดชบอร์ด 'ภาระงานแผนกเรียกเก็บเงิน'. เหตุผลที่สำคัญ ระบุกิจกรรมตามหน่วยงาน ซึ่งสำคัญต่อการวิเคราะห์การส่งต่องานระหว่างแผนก ภาระงาน และประสิทธิภาพของทีม. แหล่งข้อมูล ข้อมูลนี้อาจจัดเก็บไว้ในข้อมูลโปรไฟล์ผู้ใช้ของ Oracle Health โดยตรง หรืออนุมานจากผู้ใช้หรือประเภทกิจกรรม. ตัวอย่าง บริการผู้ป่วยการลงรหัสการเรียกเก็บเงินการติดตามหนี้ | |||
| ยอดคงค้าง OutstandingBalance | ยอดที่ยังไม่ได้ชำระสำหรับรายการเรียกเก็บ ณ เวลาที่กำหนด. | ||
| คำอธิบาย แอตทริบิวต์นี้แสดงยอดคงค้างของรายการเรียกเก็บหลังจากนำการชำระเงินและรายการปรับปรุงทั้งหมดมาคำนวณแล้ว ซึ่งเป็นลูกหนี้การค้าที่ยังคงค้างสำหรับยอดเรียกเก็บนั้น แอตทริบิวต์นี้สำคัญต่อแดชบอร์ด 'อายุยอดคงค้าง' การวิเคราะห์ยอดนี้ตามช่วงเวลาช่วยติดตามความเร็วของกระแสเงินสด ประเมินประสิทธิผลของการติดตามหนี้ และคำนวณ KPI ทางการเงินที่สำคัญ เช่น จำนวนวันขายค้างรับ (DSO). เหตุผลที่สำคัญ ติดตามลูกหนี้การค้าคงค้างของแต่ละเคส ซึ่งจำเป็นต่อการบริหารกระแสเงินสดและวิเคราะห์ประสิทธิผลของการติดตามหนี้. แหล่งข้อมูล โดยทั่วไปคำนวณจากผลรวมของธุรกรรมทางการเงินทั้งหมดสำหรับรายการเรียกเก็บนั้น เช่น ยอดเรียกเก็บ การชำระเงิน และรายการปรับปรุง หรืออาจจัดเก็บเป็นฟิลด์ในตารางสรุปบัญชี. ตัวอย่าง 75.000.00550.80 | |||
| ยอดปรับปรุง AdjustmentAmount | มูลค่าเงินของรายการปรับปรุงยอดบัญชี. | ||
| คำอธิบาย แอตทริบิวต์นี้บันทึกยอดปรับปรุงทางการเงินที่นำมาใช้กับรายการเรียกเก็บ เช่น ส่วนลดตามสัญญา การตัดหนี้สูญ หรือการแก้ไขรายการ การปรับปรุงเหล่านี้ทำให้รายได้ที่คาดว่าจะได้รับจากยอดเรียกเก็บลดลงโดยตรง แดชบอร์ด 'ผลกระทบจากการปรับปรุงบัญชี' ใช้แอตทริบิวต์นี้เป็นหลัก การวิเคราะห์ยอดปรับปรุงและเหตุผลที่เกี่ยวข้องช่วยให้พบแหล่งที่มาของรายได้ที่สูญเสีย ปัญหาในการจัดการสัญญา หรือข้อผิดพลาดในขั้นตอนบันทึกยอดเรียกเก็บตั้งแต่แรก จึงเป็นตัวชี้วัดสำคัญด้านสถานะทางการเงิน. เหตุผลที่สำคัญ วัดรายได้ที่สูญเสียจากการตัดหนี้สูญหรือการแก้ไขรายการ ช่วยให้ระบุและแก้ไขสาเหตุที่ทำให้สถานะทางการเงินถดถอย. แหล่งข้อมูล อยู่ในตารางธุรกรรมทางการเงินที่บันทึกรายการปรับปรุงหรือตัดหนี้สูญจากบัญชีผู้ป่วย. ตัวอย่าง -50.25-120.0025.00 | |||
| รหัสเหตุผลที่ปฏิเสธเคลม DenialReasonCode | รหัสมาตรฐานที่ระบุเหตุผลที่ผู้จ่ายเงินปฏิเสธเคลม. | ||
| คำอธิบาย เมื่อผู้จ่ายเงินปฏิเสธเคลม จะระบุรหัสเหตุผลประกอบ เช่น 'บริการไม่อยู่ในความคุ้มครอง' หรือ 'ส่งเคลมซ้ำ' แอตทริบิวต์นี้บันทึกรหัสและคำอธิบายที่เกี่ยวข้อง การวิเคราะห์เหตุผลที่เคลมถูกปฏิเสธเป็นพื้นฐานสำคัญในการปรับปรุงวงจรรายได้ ช่วยให้องค์กรพบรูปแบบปัญหาที่เกิดซ้ำ เช่น การลงรหัสหรือสิทธิ์ผู้ป่วย และดำเนินการแก้ไขเพื่อป้องกันการปฏิเสธในอนาคต ซึ่งส่งผลโดยตรงต่ออัตราเคลมที่ถูกต้องตั้งแต่ครั้งแรก และช่วยลดต้นทุนจากการทำงานซ้ำ. เหตุผลที่สำคัญ ระบุสาเหตุหลักที่เคลมถูกปฏิเสธ ช่วยให้ปรับปรุงได้ตรงจุด เพิ่มอัตราเคลมที่ถูกต้องตั้งแต่ครั้งแรก และเร่งการจัดเก็บรายได้. แหล่งข้อมูล ข้อมูลนี้ได้รับจากคำแนะนำการโอนเงินทางอิเล็กทรอนิกส์ (ไฟล์ ANSI 835) ของผู้จ่ายเงิน และควรจัดเก็บไว้ในตารางเคลมหรือตารางการโอนเงินของ Oracle Health. ตัวอย่าง CO-16: เคลมหรือบริการขาดข้อมูลที่จำเป็นต่อการพิจารณา.PR-96: รายการเรียกเก็บไม่อยู่ในความคุ้มครอง.CO-18: เคลมหรือบริการซ้ำ. | |||
| เป็นการทำงานซ้ำ IsRework | ตัวบ่งชี้กิจกรรมที่เป็นการแก้ไขงานหรือทำซ้ำ. | ||
| คำอธิบาย แอตทริบิวต์ที่คำนวณขึ้นนี้ใช้ระบุกิจกรรมที่เบี่ยงเบนจาก 'เส้นทางปกติ' และทำให้ต้องกลับไปทำงานซ้ำ ตัวอย่างเช่น 'ส่งเคลมที่แก้ไขแล้ว' หรือ 'ยื่นอุทธรณ์การปฏิเสธเคลม' ซึ่งไม่ควรเกิดขึ้นหากกระบวนการดำเนินไปอย่างถูกต้องตั้งแต่ครั้งแรก การระบุและวัดปริมาณงานซ้ำเป็นเป้าหมายสำคัญของ process mining ตัวบ่งชี้นี้ช่วยกรองและวิเคราะห์วงจรการทำงานซ้ำทั้งหมดได้ง่ายขึ้น ทำให้วัดความถี่ ต้นทุน และสาเหตุของความไม่มีประสิทธิภาพในกระบวนการได้ และช่วยให้เข้าใจต้นทุนที่แท้จริงของคุณภาพในวงจรรายได้. เหตุผลที่สำคัญ ช่วยวัดความถี่และผลกระทบของวงจรการทำงานซ้ำ ทำให้เห็นความไม่มีประสิทธิภาพของกระบวนการและต้นทุนจากคุณภาพที่ไม่ดี. แหล่งข้อมูล แอตทริบิวต์นี้ได้มาจากการคำนวณระหว่างการแปลงข้อมูล โดยใช้กฎทางธุรกิจระบุชื่อกิจกรรมที่ถือเป็นการทำงานซ้ำ. ตัวอย่าง truefalse | |||
| เป็นระบบอัตโนมัติ IsAutomated | ตัวบ่งชี้ว่ากิจกรรมดำเนินการโดยระบบอัตโนมัติหรือผู้ใช้. | ||
| คำอธิบาย แอตทริบิวต์แบบค่าจริง/เท็จนี้ใช้แยกกิจกรรมที่ซอฟต์แวร์ดำเนินการอัตโนมัติ เช่น บอตหรืองานประมวลผลตามรอบของระบบ ออกจากกิจกรรมที่ผู้ใช้ทำด้วยตนเอง ตัวอย่างเช่น 'สร้างเคลม' อาจเป็นขั้นตอนอัตโนมัติ ส่วน 'ยื่นอุทธรณ์การปฏิเสธเคลม' มักเป็นงานที่ผู้ใช้ทำ การวิเคราะห์แอตทริบิวต์นี้ช่วยให้เข้าใจระดับการใช้ระบบอัตโนมัติในกระบวนการและผลต่อประสิทธิภาพกับอัตราข้อผิดพลาด คุณยังใช้เปรียบเทียบผลการทำงานระหว่างขั้นตอนอัตโนมัติกับขั้นตอนที่ทำด้วยตนเอง และหาโอกาสนำระบบอัตโนมัติมาใช้เพิ่มเติมได้. เหตุผลที่สำคัญ แยกกิจกรรมที่คนทำออกจากกิจกรรมที่ระบบดำเนินการ ซึ่งจำเป็นต่อการวิเคราะห์ประสิทธิผลของระบบอัตโนมัติและหาโอกาสนำระบบอัตโนมัติมาใช้เพิ่มเติม. แหล่งข้อมูล โดยทั่วไปอนุมานจากแอตทริบิวต์ UserPerformingAction เช่น หากรหัสผู้ใช้เป็น 'SYSTEM' หรือ 'RPA_BOT' จะระบุว่าเป็นกิจกรรมอัตโนมัติ. ตัวอย่าง truefalse | |||
| ยอดเรียกเก็บ ChargeAmount | มูลค่ารวมของบริการหรือผลิตภัณฑ์ที่เรียกเก็บเงิน. | ||
| คำอธิบาย แอตทริบิวต์นี้แสดงยอดเรียกเก็บเริ่มต้นสำหรับบริการ ก่อนหักส่วนลดหรือรายการปรับปรุงตามสัญญา และก่อนนำเงินที่ชำระมาหัก จึงเป็นมูลค่าตั้งต้นของรายการเรียกเก็บเงิน การติดตามยอดเรียกเก็บมีความสำคัญต่อการวิเคราะห์ทางการเงิน เช่น การคำนวณมูลค่ารวมของบริการที่ให้ไป และการประเมินผลกระทบทางการเงินจากรายการปรับปรุงหรือการตัดหนี้สูญในภายหลัง ยอดนี้ยังใช้เป็นฐานในการวัดรายได้ที่เรียกเก็บได้จริง. เหตุผลที่สำคัญ ระบุมูลค่าทางการเงินเริ่มต้นของเคส ซึ่งเป็นข้อมูลพื้นฐานสำหรับการวิเคราะห์ทางการเงินและประเมินผลกระทบในขั้นต่อไป. แหล่งข้อมูล อยู่ในตารางรายละเอียดรายการเรียกเก็บหรือตารางธุรกรรมการเรียกเก็บของ Oracle Health. ตัวอย่าง 150.001250.7585.50 | |||
| รหัสเคลม ClaimId | รหัสเฉพาะของเคลมประกันที่ส่งให้ผู้จ่ายเงิน. | ||
| คำอธิบาย แอตทริบิวต์นี้คือรหัสเฉพาะที่กำหนดให้กับเคลมซึ่งจัดทำและส่งให้ผู้จ่ายเงินเพื่อขอรับเงินชดเชย รายการเรียกเก็บหนึ่งรายการอาจมีเคลมหนึ่งรายการหรือมากกว่าตลอดวงจร เช่น เมื่อจำเป็นต้องแก้ไขข้อมูล รหัสเคลมช่วยติดตามการส่งเคลมแต่ละรายการไปยังผู้จ่ายเงิน และเชื่อมโยงกับผลตอบกลับโดยตรง เช่น การชำระเงินหรือการปฏิเสธเคลม จึงติดตามรายละเอียดได้มากกว่าการดูรายการเรียกเก็บโดยรวม. เหตุผลที่สำคัญ ใช้ระบุและติดตามสถานะของเคลมกับผู้จ่ายเงินได้อย่างเฉพาะเจาะจง โดยมีรายละเอียดมากกว่าการติดตามรายการเรียกเก็บโดยรวม. แหล่งข้อมูล Oracle Health สร้างรหัสนี้เมื่อสร้างเคลม และจัดเก็บไว้ในตารางเคลมหลัก. ตัวอย่าง CLM-2023-55489CLM-2023-55490CLM-2023-55491-C1 | |||
| รหัสผู้ป่วย PatientId | รหัสเฉพาะของผู้ป่วยที่เกี่ยวข้องกับรายการเรียกเก็บ. | ||
| คำอธิบาย แอตทริบิวต์นี้เป็นรหัสเฉพาะของผู้ป่วยที่ได้รับบริการ ซึ่งมักเรียกว่าหมายเลขเวชระเบียน (MRN) ใช้เชื่อมโยงธุรกรรมทางการเงินกับบุคคลนั้น แม้รหัสผู้ป่วยจะไม่ใช่รหัสเคสของกระบวนการ แต่ก็ช่วยรวบรวมรายการเรียกเก็บทั้งหมดของผู้ป่วยแต่ละราย เพื่อให้เห็นภาพรวมธุรกรรมทางการเงินของผู้ป่วย นอกจากนี้ยังใช้แบ่งกลุ่มตามข้อมูลประชากรหรือประวัติผู้ป่วยได้ หากเชื่อมกับข้อมูลหลักของผู้ป่วย. เหตุผลที่สำคัญ เชื่อมโยงธุรกรรมทางการเงินกับผู้ป่วยแต่ละราย ช่วยวิเคราะห์โดยยึดผู้ป่วยเป็นหลักและรวบรวมกิจกรรมการเรียกเก็บเงินทั้งหมดของผู้ป่วย. แหล่งข้อมูล รหัสนี้เป็นข้อมูลหลักในระเบียนผู้ป่วย และจะปรากฏในตารางธุรกรรมที่เกี่ยวข้อง เช่น รายการเรียกเก็บ เคลม และการชำระเงิน. ตัวอย่าง MRN-1002345MRN-1002346MRN-1002347 | |||
| ระบบต้นทาง SourceSystem | ระบบที่ดึงข้อมูลเหตุการณ์ออกมา. | ||
| คำอธิบาย คุณลักษณะนี้ระบุแอปพลิเคชันหรือโมดูลต้นทางของข้อมูล สำหรับกระบวนการนี้ โดยทั่วไปคือ 'Oracle Health Revenue Cycle' แต่อาจระบุโมดูลต่างๆ ภายในระบบได้ หากนำข้อมูลมาจากหลายแหล่ง ข้อมูลนี้มีประโยชน์ต่อการกำกับดูแลข้อมูลและการแก้ไขปัญหา ช่วยยืนยันที่มาของข้อมูล และสำคัญในกรณีที่มีหลายระบบร่วมกันจัดการกระบวนการตั้งแต่ต้นจนจบ. เหตุผลที่สำคัญ ระบุที่มาของข้อมูล ซึ่งจำเป็นต่อการตรวจสอบความถูกต้อง การกำกับดูแลข้อมูล และการทำความเข้าใจความแตกต่างของกระบวนการที่อาจขึ้นอยู่กับระบบ. แหล่งข้อมูล มักเป็นค่าคงที่ที่เพิ่มระหว่างขั้นตอนการดึง แปลง และโหลดข้อมูล (ETL) เพื่อระบุแหล่งที่มาของชุดข้อมูล. ตัวอย่าง OracleHealth-RCMOracleHealth-CernerOH-RevCycle-PROD | |||
| เวลาสิ้นสุดเหตุการณ์ EventEndTime | เวลาที่ระบุว่ากิจกรรมเสร็จสิ้น หากมีข้อมูล. | ||
| คำอธิบาย StartTime ระบุเวลาเริ่มต้นของกิจกรรม ส่วน EventEndTime ระบุเวลาสิ้นสุด กิจกรรมบางอย่างไม่มีเวลาสิ้นสุดที่ชัดเจน เพราะเป็นเหตุการณ์ที่เกิดขึ้นทันที แต่ฟิลด์นี้มีประโยชน์มากสำหรับกิจกรรมที่ใช้เวลา เช่น 'ยื่นอุทธรณ์การปฏิเสธเคลม' ซึ่งอาจต้องใช้เวลาจัดการ คุณลักษณะนี้ช่วยคำนวณเวลาที่ใช้ดำเนินกิจกรรมแต่ละรายการได้แม่นยำขึ้น และแยกเวลารอระหว่างกิจกรรมออกจากเวลาที่ใช้ทำกิจกรรม. เหตุผลที่สำคัญ ช่วยคำนวณเวลาที่ใช้ทำกิจกรรมให้เสร็จได้โดยตรง และแยกเวลาประมวลผลออกจากเวลารอ. แหล่งข้อมูล ตารางธุรกรรมบางรายการใน Oracle Health Revenue Cycle อาจมีทั้งเวลาเริ่มต้นและเวลาสิ้นสุดของงานเฉพาะที่ใช้เวลานาน. ตัวอย่าง 2023-04-15T09:05:14Z2023-04-18T16:00:00Z | |||
| เหตุผลที่โต้แย้ง DisputeReason | เหตุผลที่ลูกค้าหรือผู้ป่วยแจ้งเมื่อโต้แย้งใบแจ้งหนี้หรือยอดเรียกเก็บ. | ||
| คำอธิบาย แอตทริบิวต์นี้บันทึกเหตุผลที่ผู้ป่วยหรือผู้รับผิดชอบค่าใช้จ่ายโต้แย้งใบเรียกเก็บเงิน เช่น เรียกเก็บไม่ถูกต้อง ไม่ได้รับบริการ หรือมีปัญหาในการดำเนินการกับประกัน ข้อมูลนี้จำเป็นต่อแดชบอร์ด 'ตัวชี้วัดการจัดการข้อโต้แย้งใบแจ้งหนี้' การทำความเข้าใจเหตุผลที่พบบ่อยช่วยให้พบปัญหาเชิงระบบในการบันทึกยอดเรียกเก็บ การลงรหัส หรือขั้นตอนเรียกเก็บเงิน การแก้ไขสาเหตุเหล่านี้ช่วยลดข้อโต้แย้งและภาระงานธุรการที่ต้องใช้ในการจัดการได้อย่างมาก. เหตุผลที่สำคัญ อธิบายสาเหตุที่มีการโต้แย้งใบแจ้งหนี้ ช่วยให้เห็นปัญหาด้านความถูกต้องหรือความชัดเจนของการเรียกเก็บเงินที่ต้องแก้ไข. แหล่งข้อมูล ข้อมูลนี้น่าจะจัดเก็บในโมดูลจัดการเคสหรือบริการลูกค้าของ Oracle Health และเชื่อมโยงกับบัญชีผู้ป่วย. ตัวอย่าง เรียกเก็บค่าบริการไม่ถูกต้องเรียกเก็บเงินซ้ำเรียกเก็บเงินจากประกันไม่ถูกต้องไม่ได้ให้บริการ | |||
| อัปเดตข้อมูลล่าสุด LastDataUpdate | เวลาที่ระบุว่ามีการรีเฟรชหรือดึงข้อมูลของเหตุการณ์นี้ครั้งล่าสุดเมื่อใด. | ||
| คำอธิบาย คุณลักษณะนี้แสดงเวลาที่อัปเดตชุดข้อมูลล่าสุด ช่วยให้ทราบว่าข้อมูลที่นำมาวิเคราะห์เป็นข้อมูลใหม่เพียงใด ซึ่งสำคัญต่อการพิจารณาความทันเวลาของข้อมูลเชิงลึกจากการวิเคราะห์ process mining ผู้ใช้ตรวจสอบคุณลักษณะนี้เพื่อยืนยันว่ากำลังดูข้อมูลกระบวนการล่าสุด ช่วยให้เข้าใจว่าข้อมูลเป็นปัจจุบันเพียงใด และเป็นส่วนสำคัญของการกำกับดูแลและการประกันคุณภาพข้อมูล. เหตุผลที่สำคัญ ระบุความใหม่ของข้อมูล เพื่อให้มั่นใจว่าการวิเคราะห์และการตัดสินใจอ้างอิงข้อมูลล่าสุด. แหล่งข้อมูล โดยทั่วไปฟิลด์ข้อมูลเมตานี้สร้างและเติมค่าระหว่างขั้นตอน ETL ที่โหลดข้อมูลเข้าสู่แพลตฟอร์ม process mining. ตัวอย่าง 2023-10-27T02:00:00Z2023-10-28T02:00:00Z | |||
กิจกรรมการจัดการวงจรรายได้
| กิจกรรม | คำอธิบาย | ||
|---|---|---|---|
| บันทึกการรับชำระเงินแล้ว | หมายถึงการนำเงินที่ได้รับจากผู้จ่ายไปลงในค่าบริการที่เกี่ยวข้องในบัญชีผู้ป่วย เป็นธุรกรรมทางการเงินที่ผู้ใช้หรือกระบวนการอัตโนมัติบันทึกไว้. | ||
| เหตุผลที่สำคัญ ประสิทธิภาพในการบันทึกการรับชำระเงินส่งผลต่อความถูกต้องของบัญชีลูกหนี้ หากล่าช้าอาจทำให้ข้อมูลทางการเงินคลาดเคลื่อนและทำให้การเรียกเก็บเงินจากผู้จ่ายรายที่สองล่าช้าตามไปด้วย. แหล่งข้อมูล ค้นหาได้ในตารางธุรกรรมการชำระเงิน การบันทึกการรับชำระเงินแต่ละครั้งจะมีรหัสธุรกรรมเฉพาะและเวลาที่เกี่ยวข้อง. บันทึก ระบบบันทึกธุรกรรมทางการเงินเมื่อนำเงินไปลงในบัญชีแล้ว. ประเภทเหตุการณ์ explicit | |||
| ปิดบัญชีแล้ว | กิจกรรมสุดท้ายที่ระบุว่ายอดคงเหลือในบัญชีเป็นศูนย์และไม่คาดว่าจะมีกิจกรรมเพิ่มเติม โดยมักอนุมานเมื่อยอดคงเหลือในบัญชีเป็นศูนย์. | ||
| เหตุผลที่สำคัญ แสดงว่าวงจรรายได้เสร็จสมบูรณ์ ระยะเวลาที่ใช้จนถึงสถานะนี้เป็นตัวชี้วัดสำคัญของประสิทธิภาพกระบวนการโดยรวม. แหล่งข้อมูล โดยทั่วไปอนุมานจากเวลาครั้งแรกที่ยอดค้างชำระในบัญชีเป็นศูนย์และยังคงเป็นศูนย์หลังบันทึกการชำระเงินและการปรับยอดทั้งหมดแล้ว. บันทึก คำนวณเมื่อยอดคงเหลือในบัญชีเป็นศูนย์ครั้งแรก หลังบันทึกค่าบริการและการชำระเงินทั้งหมดแล้ว. ประเภทเหตุการณ์ calculated | |||
| ส่งเคลมให้ผู้จ่ายแล้ว | หมายถึงการส่งเคลมที่สร้างขึ้นให้บริษัทประกันหรือผู้จ่าย ทั้งทางอิเล็กทรอนิกส์หรือเอกสาร ระบบควรบันทึกวันที่และเวลาที่ส่ง. | ||
| เหตุผลที่สำคัญ กิจกรรมนี้เป็นจุดเริ่มต้นของรอบการรับชำระเงิน การวิเคราะห์เวลาตั้งแต่ส่งเคลมจนถึงรับชำระช่วยให้เข้าใจประสิทธิภาพของผู้จ่ายและ Days Sales Outstanding (DSO). แหล่งข้อมูล ข้อมูลมาจากโมดูลจัดการเคลม ซึ่งบันทึกเหตุการณ์การส่ง ให้ค้นหาเวลาที่ส่งหรือการเปลี่ยนสถานะเป็น 'ส่งแล้ว' ในประวัติเคลม. บันทึก ระบบบันทึกเหตุการณ์เมื่อส่งเคลมผ่าน clearinghouse สำเร็จ. ประเภทเหตุการณ์ explicit | |||
| สร้างเคลมแล้ว | ระบุจุดที่รวบรวมค่าบริการแต่ละรายการเป็นเคลมเรียกเก็บเงินอย่างเป็นทางการ เช่น UB-04 หรือ CMS-1500 เหตุการณ์นี้ระบบสร้างขึ้นเพื่อออกใบแจ้งหนี้ฉบับแรก. | ||
| เหตุผลที่สำคัญ เหตุการณ์สำคัญนี้แสดงว่าพร้อมเรียกเก็บเงินจากผู้จ่ายแล้ว และเป็นจุดสิ้นสุดที่ใช้วัดระยะเวลาตั้งแต่บันทึกค่าบริการจนถึงเรียกเก็บเงินภายในองค์กร. แหล่งข้อมูล เป็นเหตุการณ์ที่บันทึกไว้อย่างชัดเจนในบันทึกหรือตารางการสร้างเคลม ให้ค้นหาเวลาที่สร้างระเบียนเคลมหลักซึ่งเชื่อมโยงกับรายการรับบริการ. บันทึก ระบบบันทึกเหตุการณ์เมื่อสร้างระเบียนเคลม. ประเภทเหตุการณ์ explicit | |||
| สร้างรายการรับบริการผู้ป่วยแล้ว | ระบุการสร้างบัญชีผู้ป่วยสำหรับการเข้ารับบริการหรือการรักษาแต่ละครั้ง โดยทั่วไปจะเป็นเหตุการณ์ที่ระบบบันทึกไว้อย่างชัดเจนเมื่อระบบลงทะเบียนหรือข้อมูล Admit/Discharge/Transfer (ADT) เริ่มทำงาน. | ||
| เหตุผลที่สำคัญ เหตุการณ์นี้เป็นจุดเริ่มต้นของวงจรรายได้ทั้งหมดสำหรับรายการเรียกเก็บเงินแต่ละรายการ ช่วยวิเคราะห์ระยะเวลารวมของกระบวนการและความถูกต้องของการลงทะเบียน. แหล่งข้อมูล ข้อมูลมาจากบันทึกของโมดูล Patient Registration หรือ ADT ให้ค้นหาเหตุการณ์สร้างรายการรับบริการ หรือเวลาแรกสุดที่เชื่อมโยงกับรายการรับบริการหรือหมายเลขทางการเงิน. บันทึก ระบบบันทึกเหตุการณ์เมื่อลงทะเบียนหรือรับผู้ป่วยเข้ารักษา. ประเภทเหตุการณ์ explicit | |||
| ได้รับแจ้งการปฏิเสธเคลมแล้ว | ระบุเหตุการณ์ที่ผู้จ่ายปฏิเสธเคลมหรือรายการค่าบริการบางรายการ ตามที่ระบุในเอกสารแจ้งการชำระเงิน โดยมักอนุมานเหตุการณ์นี้จากรหัสการปฏิเสธในข้อมูลการชำระเงิน. | ||
| เหตุผลที่สำคัญ การติดตามการปฏิเสธเคลมจำเป็นต่อการหาสาเหตุที่แท้จริง เช่น ข้อผิดพลาดในการลงรหัสหรือปัญหาสิทธิ์การรักษา และช่วยเพิ่มอัตราเคลมที่ถูกต้องตั้งแต่ครั้งแรก. แหล่งข้อมูล อนุมานจากข้อมูลเอกสารแจ้งการชำระเงิน (ERA/835) เมื่อยอดที่ถูกปฏิเสธของเคลมหรือรายการค่าบริการไม่เป็นศูนย์ และมีรหัสเหตุผลการปฏิเสธที่เกี่ยวข้อง ระบบจะถือว่าเกิดเหตุการณ์นี้. บันทึก อนุมานจากข้อมูลเอกสารแจ้งการชำระเงินที่มีรหัสเหตุผลการปฏิเสธ (CARCs/RARCs). ประเภทเหตุการณ์ inferred | |||
| ได้รับเอกสารแจ้งการชำระเงินแล้ว | หมายถึงการได้รับ Electronic Remittance Advice (ERA) หรือเอกสาร Explanation of Benefits (EOB) จากผู้จ่าย เอกสารนี้ระบุว่าค่าบริการใดได้รับชำระ ถูกปฏิเสธ หรือถูกปรับยอด. | ||
| เหตุผลที่สำคัญ นี่คือการตอบกลับครั้งแรกจากผู้จ่าย ซึ่งสำคัญต่อการทำความเข้าใจความเร็วในการรับชำระเงินและการพบแนวโน้มการปฏิเสธเคลมตั้งแต่เนิ่นๆ. แหล่งข้อมูล บันทึกไว้ในโมดูลประมวลผลเอกสารแจ้งการชำระเงิน ให้ค้นหาเวลาที่นำเข้าไฟล์ ERA หรือสร้างไฟล์ เช่น ไฟล์ธุรกรรม 835 ที่เชื่อมโยงกับเคลม. บันทึก ระบบบันทึกเหตุการณ์เมื่อนำเข้าและประมวลผลไฟล์แจ้งการชำระเงินจากผู้จ่าย เช่น ANSI 835. ประเภทเหตุการณ์ explicit | |||
| บันทึกค่าบริการแล้ว | หมายถึงการบันทึกบริการหรือรายการที่เรียกเก็บเงินได้ลงในบัญชีผู้ป่วย ซึ่งอาจเกิดขึ้นโดยอัตโนมัติจากระบบคลินิก หรือเจ้าหน้าที่เป็นผู้บันทึกด้วยตนเอง. | ||
| เหตุผลที่สำคัญ กิจกรรมนี้สำคัญต่อการวัดระยะเวลาตั้งแต่ให้บริการจนถึงบันทึกค่าบริการ ซึ่งส่งผลโดยตรงต่อกระแสเงินสดและความถูกต้องของรายได้. แหล่งข้อมูล ดึงข้อมูลจากตารางธุรกรรมค่าบริการ โดยใช้เวลาที่สร้างรายการค่าบริการแต่ละรายการ ใน Oracle Health ข้อมูลนี้มักอยู่ในตารางที่เกี่ยวข้องกับค่าบริการ. บันทึก สร้างรายการในบันทึกธุรกรรมสำหรับค่าบริการใหม่แต่ละรายการ. ประเภทเหตุการณ์ explicit | |||
| ปรับยอดบัญชีแล้ว | หมายถึงการปรับยอดทางการเงินในบัญชี เช่น ค่าเผื่อส่วนลดตามสัญญา การตัดหนี้สูญ หรือส่วนลด การปรับยอดแต่ละครั้งเป็นธุรกรรมทางการเงินแยกกัน. | ||
| เหตุผลที่สำคัญ การปรับยอดส่งผลต่อรายได้โดยตรง การวิเคราะห์ความถี่ ประเภท และจำนวนเงินช่วยให้พบรายได้ที่สูญหายและความคลาดเคลื่อนในการเรียกเก็บเงิน. แหล่งข้อมูล ค้นหาได้ในตารางธุรกรรมทางการเงิน การปรับยอดแต่ละครั้งจะบันทึกเป็นรายการแยก พร้อมรหัสธุรกรรมและเวลาเฉพาะ. บันทึก ระบบบันทึกธุรกรรมทางการเงินพร้อมรหัสการปรับยอดเฉพาะ. ประเภทเหตุการณ์ explicit | |||
| ยื่นอุทธรณ์การปฏิเสธเคลมแล้ว | การดำเนินการของผู้ใช้หรือระบบที่ระบุว่ากำลังยื่นอุทธรณ์เคลมที่ถูกปฏิเสธ โดยทั่วไปบันทึกเป็นการอัปเดตสถานะหรือสร้างงานเฉพาะในคิวงาน. | ||
| เหตุผลที่สำคัญ กิจกรรมนี้เริ่มวงจรการแก้ไขงาน การวิเคราะห์ความถี่และอัตราความสำเร็จของการอุทธรณ์มีความสำคัญต่อการปรับปรุงการเรียกคืนรายได้. แหล่งข้อมูล อาจเป็นเหตุการณ์ที่ผู้ใช้เริ่มดำเนินการโดยตรง หรืออนุมานจากการเปลี่ยนสถานะของเคลม เช่น 'ยื่นอุทธรณ์แล้ว' หรือ 'อยู่ระหว่างตรวจสอบ'. บันทึก การเปลี่ยนสถานะหรือเหตุการณ์ที่บันทึกไว้เมื่อผู้ใช้เริ่มกระบวนการอุทธรณ์เคลมที่ถูกปฏิเสธ. ประเภทเหตุการณ์ explicit | |||
| เริ่มติดตามหนี้แล้ว | ระบุว่าบัญชีผู้ป่วยเข้าสู่กระบวนการติดตามหนี้เนื่องจากไม่ชำระเงิน โดยทั่วไปตรวจพบจากการเปลี่ยนประเภททางการเงินหรือสถานะของบัญชี. | ||
| เหตุผลที่สำคัญ ขั้นตอนนี้สำคัญต่อการจัดการหนี้สูญ การวิเคราะห์ปัจจัยที่ทำให้บัญชีมาถึงขั้นนี้และอัตราความสำเร็จในการติดตามหนี้มีความสำคัญต่อสถานะทางการเงิน. แหล่งข้อมูล อนุมานจากการเปลี่ยนช่องสถานะบัญชีเป็น 'ติดตามหนี้' หรือ 'หนี้สูญ' โดยการเปลี่ยนสถานะนี้ควรมีเวลาที่เกี่ยวข้อง. บันทึก อนุมานจากการเปลี่ยนสถานะบัญชีเป็น 'ติดตามหนี้' หรือสถานะที่มีความหมายใกล้เคียงกัน. ประเภทเหตุการณ์ inferred | |||
| ลงรหัสค่าบริการแล้ว | หมายถึงขั้นตอนที่ผู้ลงรหัสทางการแพทย์กำหนดรหัสมาตรฐาน เช่น CPT หรือ ICD-10 ให้กับค่าบริการที่บันทึกไว้ โดยมักติดตามจากการเปลี่ยนสถานะของค่าบริการหรือรายการรับบริการ. | ||
| เหตุผลที่สำคัญ ความล่าช้าในการลงรหัสเป็นคอขวดที่พบได้บ่อย การติดตามกิจกรรมนี้ช่วยให้เห็นจุดที่ไม่มีประสิทธิภาพในเวิร์กโฟลว์การลงรหัสและผลกระทบต่อระยะเวลาการเรียกเก็บเงิน. แหล่งข้อมูล มักอนุมานจากการเปลี่ยนสถานะของรายการรับบริการหรือชุดค่าบริการ เช่น จาก 'ยังไม่ได้ลงรหัส' เป็น 'ลงรหัสแล้ว' โดยต้องมีเวลาที่เปลี่ยนสถานะ. บันทึก อนุมานจากการเปลี่ยนสถานะรายการรับบริการหรือค่าบริการเป็น 'ลงรหัสแล้ว' หรือ 'พร้อมเรียกเก็บเงิน'. ประเภทเหตุการณ์ inferred | |||
| ส่งเคลมฉบับแก้ไขแล้ว | หมายถึงการส่งเคลมฉบับแก้ไขหรือฉบับปรับปรุงให้ผู้จ่าย ซึ่งมักเกิดขึ้นหลังเคลมถูกปฏิเสธหรือมีการขอข้อมูลเพิ่มเติม ระบุได้จากการส่งเคลมใหม่ที่มีตัวบ่งชี้ว่าเป็นฉบับแก้ไข. | ||
| เหตุผลที่สำคัญ กิจกรรมนี้เป็นส่วนสำคัญของวงจรแก้ไขงานเพื่อจัดการการปฏิเสธเคลม หากเกิดขึ้นบ่อย แสดงว่าเคลมฉบับแรกอาจมีปัญหาด้านความถูกต้อง. แหล่งข้อมูล ดึงข้อมูลจากบันทึกการส่งเคลม ให้ค้นหาการส่งเคลมใหม่สำหรับรายการรับบริการเดิม ซึ่งมักระบุด้วยรหัสส่งซ้ำหรือหมายเลขครั้งที่สูงขึ้น. บันทึก เหตุการณ์ที่บันทึกเมื่อส่งเคลมซ้ำ โดยมักระบุได้จากรหัสประเภทความถี่ของเคลมโดยเฉพาะ. ประเภทเหตุการณ์ explicit | |||
| ส่งใบแจ้งยอดให้ผู้ป่วยแล้ว | ระบุเหตุการณ์ที่สร้างและส่งใบเรียกเก็บเงินส่วนที่ผู้ป่วยต้องรับผิดชอบ โดยโมดูลเรียกเก็บเงินผู้ป่วยจะบันทึกการดำเนินการนี้ไว้อย่างชัดเจน. | ||
| เหตุผลที่สำคัญ ขั้นตอนนี้เริ่มส่วนการชำระเงินของผู้ป่วยในวงจรรายได้ การติดตามช่วยวิเคราะห์ประสิทธิผลของการติดตามรับชำระจากผู้ป่วย. แหล่งข้อมูล ข้อมูลมาจากบันทึกการเรียกเก็บเงินหรือการติดต่อผู้ป่วย ระบบควรบันทึกวันที่สร้างหรือส่งใบแจ้งยอดแต่ละฉบับ. บันทึก ระบบบันทึกเหตุการณ์เมื่อสร้างใบแจ้งยอดผู้ป่วยและพิมพ์หรือส่งทางอิเล็กทรอนิกส์. ประเภทเหตุการณ์ explicit | |||
คู่มือการดึงข้อมูล
ขั้นตอน
- ขอสิทธิ์เข้าถึงฐานข้อมูล: ขอข้อมูลรับรองแบบอ่านอย่างเดียวสำหรับฐานข้อมูล Oracle Health Revenue Cycle โดยต้องเข้าถึงสคีมาที่มีข้อมูลผู้ป่วย การพบแพทย์ การเรียกเก็บเงิน และธุรกรรมทางการเงิน โดยทั่วไปต้องได้รับอนุมัติจากทีมรักษาความปลอดภัยด้าน IT และทีมดูแลฐานข้อมูล
- ระบุชื่อสคีมาและตาราง: ประสานงานกับผู้ดูแลฐานข้อมูลหรือนักวิเคราะห์ระบบเพื่อยืนยันชื่อสคีมาและตารางที่ใช้จริงใน Oracle Health ของคุณ ชื่อในคำค้นเป็นเพียงตัวอย่างที่ใช้กันทั่วไป จึงต้องจับคู่กับสภาพแวดล้อมของคุณ
- ติดตั้งไคลเอนต์ SQL: ติดตั้งไคลเอนต์ SQL ที่รองรับ เช่น Oracle SQL Developer หรือ DBeaver บนเครื่องของคุณ ใช้เครื่องมือนี้เชื่อมต่อฐานข้อมูลและเรียกใช้สคริปต์ดึงข้อมูล
- เชื่อมต่อฐานข้อมูล: ตั้งค่าการเชื่อมต่อใหม่ในไคลเอนต์ SQL โดยใช้โฮสต์ พอร์ต ชื่อบริการ และข้อมูลรับรองที่ได้รับ ทดสอบการเชื่อมต่อเพื่อยืนยันว่าใช้งานได้
- ปรับแต่งคำค้น SQL: คัดลอกสคริปต์ SQL ที่ให้ไว้ไปยังหน้าต่างแก้ไขคำค้นใหม่ ค้นหาค่าตัวอย่าง เช่น
[START_DATE]และ[END_DATE]แล้วแทนที่ด้วยช่วงวันที่ที่ต้องการวิเคราะห์ เช่น '2023-01-01' ปรับเงื่อนไขตัวกรองตามความต้องการ เช่น กรองตาม Patient Class ที่กำหนด - เรียกใช้สคริปต์ดึงข้อมูล: เรียกใช้สคริปต์ SQL ที่ปรับแต่งแล้ว คำค้นนี้ดึงข้อมูลหลายส่วน จึงอาจใช้เวลาตั้งแต่หลายนาทีจนถึงหลายชั่วโมง ขึ้นอยู่กับช่วงวันที่และขนาดฐานข้อมูล
- ตรวจผลลัพธ์เบื้องต้น: เมื่อคำค้นทำงานเสร็จ ให้ตรวจดูข้อมูลสองสามร้อยแถวแรกในตารางผลลัพธ์ของไคลเอนต์ SQL ตรวจหาข้อผิดพลาดที่เห็นได้ชัด เช่น คอลัมน์ที่มีแต่ค่าว่าง หรือรูปแบบข้อมูลไม่ถูกต้อง เพื่อยืนยันว่าสคริปต์ทำงานตามที่ควร
- ส่งออกข้อมูลเป็น CSV: ส่งออกผลลัพธ์ทั้งหมดเป็นไฟล์ CSV และใช้การเข้ารหัส UTF-8 เพื่อป้องกันปัญหาอักขระ ตรวจสอบว่าไฟล์มีแถวหัวคอลัมน์ตามชื่อที่กำหนดใน alias ของคำค้น เช่น "BillingEvent" และ "ActivityName"
- เตรียมไฟล์สำหรับอัปโหลด: ก่อนอัปโหลดไปยังเครื่องมือ process mining ให้เปิดไฟล์ CSV เพื่อตรวจสอบความถูกต้อง ยืนยันว่ารูปแบบเวลาเป็นแบบเดียวกันและหัวคอลัมน์ตรงกับแอตทริบิวต์ที่กำหนดทุกประการ จากนั้นไฟล์ก็พร้อมอัปโหลดแล้ว.
การกำหนดค่า
- ช่วงวันที่: คำค้นใช้ตัวแทนค่า
[START_DATE]และ[END_DATE]ควรกำหนดช่วงวันที่ให้ชัดเจนและเหมาะสมเพื่อควบคุมปริมาณข้อมูล แนะนำให้เริ่มวิเคราะห์จากข้อมูลย้อนหลัง 3 ถึง 6 เดือน - การกรองข้อมูล: ชุดข้อมูลเริ่มต้นจะกรองตามวันที่ลงทะเบียนการพบแพทย์ (
reg_dt_tm) ในส่วนRelevantEncountersคุณสามารถเพิ่มคำสั่งWHEREในส่วนนี้เพื่อจำกัดขอบเขต เช่นe.patient_class_code IN ('INPATIENT', 'OUTPATIENT')เพื่อเลือกประเภทการพบแพทย์ที่ต้องการ - ประสิทธิภาพ: การค้นข้อมูลโดยตรงจากฐานข้อมูลที่ใช้งานจริงอาจกระทบต่อประสิทธิภาพ แนะนำอย่างยิ่งให้ดึงข้อมูลนอกช่วงเวลาที่มีการใช้งานสูง หรือใช้ฐานข้อมูลสำเนาแบบอ่านอย่างเดียว หากมี
- ข้อกำหนดเบื้องต้น: วิธีนี้ต้องใช้บัญชีผู้ใช้ฐานข้อมูลที่มีสิทธิ์
SELECTสำหรับทุกตารางที่อ้างอิงในคำค้น รวมถึงตารางการพบแพทย์ การเรียกเก็บเงิน ค่าใช้จ่าย เคลม การโอนเงิน และธุรกรรมทางการเงิน - การจับคู่ตารางและคอลัมน์: สคริปต์ที่ให้มาใช้ชื่อตารางและคอลัมน์ตัวอย่างที่พบได้ทั่วไป คุณต้องตรวจสอบและจับคู่ชื่อเหล่านี้กับชื่อจริงในสคีมาฐานข้อมูล Oracle Health ขององค์กร ตัวอย่างเช่น
FINANCIAL_TRANSACTIONอาจใช้ชื่อAR_TRANSACTIONSในระบบของคุณ.
ตัวอย่างคำค้น sql
WITH RelevantEncounters AS (
SELECT
e.billing_event_id
FROM ENCOUNTER e
WHERE e.reg_dt_tm BETWEEN TO_DATE('[START_DATE]', 'YYYY-MM-DD') AND TO_DATE('[END_DATE]', 'YYYY-MM-DD')
)
SELECT
e.billing_event_id AS "BillingEvent",
'Patient Encounter Created' AS "ActivityName",
e.reg_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
pyr.payer_name AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
e.total_account_balance AS "OutstandingBalance",
NULL AS "DenialReasonCode"
FROM ENCOUNTER e
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON e.reg_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON e.reg_facility_org_id = org.organization_id
LEFT JOIN PAYER pyr ON e.primary_payer_id = pyr.payer_id
UNION ALL
SELECT
cd.billing_event_id AS "BillingEvent",
'Charges Captured' AS "ActivityName",
cd.charge_entry_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
pyr.payer_name AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
cd.charge_balance AS "OutstandingBalance",
NULL AS "DenialReasonCode"
FROM CHARGE_DETAIL cd
JOIN ENCOUNTER e ON cd.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON cd.entry_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON cd.performing_dept_org_id = org.organization_id
LEFT JOIN PAYER pyr ON e.primary_payer_id = pyr.payer_id
UNION ALL
SELECT
ch.billing_event_id AS "BillingEvent",
'Charges Coded' AS "ActivityName",
ch.coded_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
pyr.payer_name AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
e.total_account_balance AS "OutstandingBalance",
NULL AS "DenialReasonCode"
FROM CODING_HISTORY ch
JOIN ENCOUNTER e ON ch.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON ch.coder_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON p.default_org_id = org.organization_id
LEFT JOIN PAYER pyr ON e.primary_payer_id = pyr.payer_id
UNION ALL
SELECT
cl.billing_event_id AS "BillingEvent",
'Claim Generated' AS "ActivityName",
cl.create_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
pyr.payer_name AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
cl.claim_balance AS "OutstandingBalance",
NULL AS "DenialReasonCode"
FROM CLAIM cl
JOIN ENCOUNTER e ON cl.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON cl.create_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON cl.billing_entity_org_id = org.organization_id
LEFT JOIN PAYER pyr ON cl.payer_id = pyr.payer_id
UNION ALL
SELECT
csl.billing_event_id AS "BillingEvent",
'Claim Submitted To Payer' AS "ActivityName",
csl.submission_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
pyr.payer_name AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
cl.claim_balance AS "OutstandingBalance",
NULL AS "DenialReasonCode"
FROM CLAIM_SUBMISSION_LOG csl
JOIN CLAIM cl ON csl.claim_id = cl.claim_id
JOIN ENCOUNTER e ON cl.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON csl.submit_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON cl.billing_entity_org_id = org.organization_id
LEFT JOIN PAYER pyr ON cl.payer_id = pyr.payer_id
WHERE csl.submission_type = 'INITIAL'
UNION ALL
SELECT
ra.billing_event_id AS "BillingEvent",
'Remittance Received' AS "ActivityName",
ra.remit_received_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
pyr.payer_name AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
e.total_account_balance AS "OutstandingBalance",
NULL AS "DenialReasonCode"
FROM REMITTANCE_ADVICE ra
JOIN ENCOUNTER e ON ra.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON ra.processed_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON ra.processing_org_id = org.organization_id
LEFT JOIN PAYER pyr ON ra.payer_id = pyr.payer_id
UNION ALL
SELECT
ft.billing_event_id AS "BillingEvent",
'Payment Posted' AS "ActivityName",
ft.transaction_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
pyr.payer_name AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
ft.ending_balance AS "OutstandingBalance",
NULL AS "DenialReasonCode"
FROM FINANCIAL_TRANSACTION ft
JOIN ENCOUNTER e ON ft.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON ft.post_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON ft.post_dept_org_id = org.organization_id
LEFT JOIN PAYER pyr ON ft.payer_id = pyr.payer_id
WHERE ft.transaction_type_code = 'PAYMENT'
UNION ALL
SELECT
rd.billing_event_id AS "BillingEvent",
'Denial Received' AS "ActivityName",
ra.remit_received_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
pyr.payer_name AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
e.total_account_balance AS "OutstandingBalance",
rd.denial_reason_code AS "DenialReasonCode"
FROM REMITTANCE_DETAIL rd
JOIN REMITTANCE_ADVICE ra ON rd.remit_id = ra.remit_id
JOIN ENCOUNTER e ON ra.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON ra.processed_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON ra.processing_org_id = org.organization_id
LEFT JOIN PAYER pyr ON ra.payer_id = pyr.payer_id
WHERE rd.denial_reason_code IS NOT NULL
UNION ALL
SELECT
at.billing_event_id AS "BillingEvent",
'Denial Appealed' AS "ActivityName",
at.appeal_filed_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
pyr.payer_name AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
e.total_account_balance AS "OutstandingBalance",
at.related_denial_code AS "DenialReasonCode"
FROM APPEAL_TRACKING at
JOIN ENCOUNTER e ON at.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON at.appeal_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON p.default_org_id = org.organization_id
LEFT JOIN PAYER pyr ON at.payer_id = pyr.payer_id
UNION ALL
SELECT
csl.billing_event_id AS "BillingEvent",
'Corrected Claim Submitted' AS "ActivityName",
csl.submission_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
pyr.payer_name AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
cl.claim_balance AS "OutstandingBalance",
NULL AS "DenialReasonCode"
FROM CLAIM_SUBMISSION_LOG csl
JOIN CLAIM cl ON csl.claim_id = cl.claim_id
JOIN ENCOUNTER e ON cl.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON csl.submit_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON cl.billing_entity_org_id = org.organization_id
LEFT JOIN PAYER pyr ON cl.payer_id = pyr.payer_id
WHERE csl.submission_type = 'CORRECTED'
UNION ALL
SELECT
psl.billing_event_id AS "BillingEvent",
'Patient Statement Sent' AS "ActivityName",
psl.statement_sent_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
NULL AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
psl.statement_balance AS "OutstandingBalance",
NULL AS "DenialReasonCode"
FROM PATIENT_STATEMENT_LOG psl
JOIN ENCOUNTER e ON psl.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON psl.sent_by_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON p.default_org_id = org.organization_id
UNION ALL
SELECT
ash.billing_event_id AS "BillingEvent",
'Collection Activity Started' AS "ActivityName",
ash.status_change_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
NULL AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
ash.account_balance AS "OutstandingBalance",
NULL AS "DenialReasonCode"
FROM ACCOUNT_STATUS_HISTORY ash
JOIN ENCOUNTER e ON ash.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON ash.change_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON ash.responsible_org_id = org.organization_id
WHERE ash.new_status_code = 'COLLECTIONS'
UNION ALL
SELECT
ft.billing_event_id AS "BillingEvent",
'Account Adjusted' AS "ActivityName",
ft.transaction_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
pyr.payer_name AS "PayerName",
e.patient_class_code AS "PatientClass",
ft.transaction_amount AS "AdjustmentAmount",
ft.ending_balance AS "OutstandingBalance",
ft.adjustment_reason_code AS "DenialReasonCode"
FROM FINANCIAL_TRANSACTION ft
JOIN ENCOUNTER e ON ft.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON ft.post_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON ft.post_dept_org_id = org.organization_id
LEFT JOIN PAYER pyr ON ft.payer_id = pyr.payer_id
WHERE ft.transaction_type_code = 'ADJUSTMENT'
UNION ALL
SELECT
e.billing_event_id AS "BillingEvent",
'Account Closed' AS "ActivityName",
e.account_closed_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
NULL AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
0 AS "OutstandingBalance",
NULL AS "DenialReasonCode"
FROM ENCOUNTER e
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON e.closed_by_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON e.reg_facility_org_id = org.organization_id
WHERE e.total_account_balance = 0 AND e.account_closed_dt_tm IS NOT NULL;พร้อมเริ่มต้นหรือยัง?
ใช้เทมเพลตนี้เตรียมข้อมูลให้พร้อม แล้วเริ่มปรับปรุงกระบวนการจัดการวงจรรายได้ของคุณได้เลย.
ปรับปรุงวงจรรายได้ให้รับชำระเงินได้เร็วขึ้น
ลดคอขวด ลดระยะเวลาของวงจรลง 30% และเพิ่มกระแสเงินสด.
ไม่ต้องใช้บัตรเครดิต ตั้งค่าเสร็จได้ในไม่กี่นาที.