เทมเพลตข้อมูลการจัดการวงจรรายได้ของคุณ
เทมเพลตข้อมูลการจัดการวงจรรายได้ของคุณ
- แอตทริบิวต์ที่แนะนำให้รวบรวม
- กิจกรรมสำคัญที่ควรติดตาม
- แนวทางการดึงข้อมูล
แอตทริบิวต์สำหรับการจัดการวงจรรายได้
| ชื่อ | คำอธิบาย | ||
|---|---|---|---|
| ชื่อกิจกรรม ActivityName | ชื่อของเหตุการณ์หรืองานเฉพาะที่ดำเนินการในกระบวนการจัดการวงจรรายได้. | ||
| คำอธิบาย คุณลักษณะนี้อธิบายขั้นตอนหนึ่งในวงจรรายได้ เช่น 'บันทึกรายการเรียกเก็บแล้ว' 'ส่งเคลมให้ผู้จ่ายเงินแล้ว' หรือ 'ได้รับชำระเงินแล้ว' แต่ละกิจกรรมเป็นหมุดหมายเฉพาะในกระบวนการเรียกเก็บเงินและรับชำระค่าบริการ. การวิเคราะห์กิจกรรมเป็นพื้นฐานของ process mining ช่วยแสดงแผนผังกระบวนการ ระบุเส้นทางที่พบได้บ่อย ค้นหาคอขวดระหว่างขั้นตอน และวัดการปฏิบัติตามขั้นตอนปฏิบัติงานมาตรฐาน. เหตุผลที่สำคัญ กำหนดขั้นตอนในแผนผังกระบวนการ เพื่อให้เห็นภาพ วิเคราะห์ และปรับปรุงลำดับงานในวงจรรายได้ได้. แหล่งข้อมูล โดยทั่วไปได้มาจากบันทึกเหตุการณ์ บันทึกการตรวจสอบ หรือระเบียนการเปลี่ยนสถานะในโมดูลการเรียกเก็บเงินและเคลมของ Epic Resolute. ตัวอย่าง บันทึกรายการเรียกเก็บแล้วส่งเคลมให้ผู้จ่ายเงินแล้วได้รับชำระเงินแล้วปิดบัญชีแล้ว | |||
| เวลาประทับเหตุการณ์ EventTimestamp | วันที่และเวลาที่แน่นอนซึ่งกิจกรรมหรือเหตุการณ์เกิดขึ้น. | ||
| คำอธิบาย เวลาประทับเหตุการณ์บันทึกช่วงเวลาที่กิจกรรมเกิดขึ้น ข้อมูลด้านเวลานี้สำคัญต่อการทำความเข้าใจจังหวะและลำดับของเหตุการณ์ในวงจรรายได้. ในการวิเคราะห์ จะใช้เวลาประทับคำนวณระยะเวลาระหว่างกิจกรรม เช่น ความล่าช้าในการบันทึกรายการเรียกเก็บหรือเวลาที่ใช้บันทึกรับชำระเงิน ช่วยค้นหาคอขวด วัดระยะเวลาของวงจร และวิเคราะห์ผลการดำเนินงานของกระบวนการในช่วงเวลาต่าง ๆ เวลาประทับที่ถูกต้องจำเป็นต่อ KPI และแดชบอร์ดที่อิงเวลาเกือบทั้งหมด. เหตุผลที่สำคัญ คุณลักษณะนี้จำเป็นต่อการคำนวณตัวชี้วัดด้านเวลาทั้งหมด รวมถึงระยะเวลาของวงจรและช่วงเวลาที่ใช้ ซึ่งเป็นข้อมูลพื้นฐานในการค้นหาความล่าช้าและความไม่มีประสิทธิภาพ. แหล่งข้อมูล พบได้ในตารางธุรกรรมหรือบันทึกเหตุการณ์ของ Epic Resolute โดยเชื่อมโยงกับกิจกรรมแต่ละรายการที่บันทึกไว้ ชื่อฟิลด์มักลงท้ายด้วย Dt, DTTM หรือ Time. ตัวอย่าง 2023-04-15T09:30:00Z2023-04-16T11:05:21Z2023-05-01T14:00:00Z | |||
| เหตุการณ์การเรียกเก็บเงิน BillingEvent | รหัสเฉพาะของการให้บริการหรือส่งมอบผลิตภัณฑ์แต่ละครั้งที่ทำให้เกิดรายการเรียกเก็บ และใช้เป็นรหัสเคสหลัก. | ||
| คำอธิบาย เหตุการณ์การเรียกเก็บเงินเป็นรหัสหลักที่เชื่อมกิจกรรมทั้งหมดของวงจรรายได้สำหรับรายการที่เรียกเก็บเงินได้แต่ละรายการ เริ่มต้นเมื่อให้บริการและสิ้นสุดเมื่อชำระยอดครบหรือปิดบัญชี. ในการวิเคราะห์ process mining คุณลักษณะนี้จำเป็นต่อการสร้างเส้นทางตั้งแต่ต้นจนจบของรายการเรียกเก็บแต่ละรายการขึ้นใหม่ ช่วยติดตามกิจกรรมต่าง ๆ เช่น การบันทึกรายการเรียกเก็บ การส่งเคลม การบันทึกรับชำระเงิน และการจัดการเคลมที่ถูกปฏิเสธของแต่ละเหตุการณ์ ทำให้เห็นลำดับกระบวนการและความแตกต่างได้ชัดเจน. เหตุผลที่สำคัญ นี่คือ Case ID พื้นฐานที่จำเป็นต่อการเชื่อมโยงขั้นตอนที่เกี่ยวข้องทั้งหมด เพื่อวิเคราะห์วงจรการสร้างและเรียกเก็บรายได้ของบริการแต่ละรายการได้ครบถ้วน. แหล่งข้อมูล โดยมากจะเป็นรหัสเฉพาะของบัญชีโรงพยาบาล (HAR) หรือรหัสเซสชันการเรียกเก็บเงินใน Epic Resolute โปรดดูเอกสาร Epic Resolute สำหรับตารางเฉพาะ เช่น ระเบียน HAR หรือ Charge Session. ตัวอย่าง BE10098765BE20012345BE30054321 | |||
| ประเภทบริการ ServiceType | หมวดหมู่หรือประเภทของบริการทางการแพทย์ที่ให้แก่ผู้ป่วย. | ||
| คำอธิบาย แอตทริบิวต์นี้ใช้จัดประเภทบริการที่เรียกเก็บเงินได้ เช่น “รังสีวิทยา” “การผ่าตัด” “การปรึกษาแพทย์” หรือ “การเข้ารับบริการที่ห้องฉุกเฉิน” ช่วยให้เข้าใจบริบททางคลินิกของข้อมูลการเงิน การวิเคราะห์วงจรรายได้แยกตามประเภทบริการช่วยให้เห็นความแตกต่างของกระบวนการในแต่ละสาขาคลินิก เช่น หัตถการผ่าตัดอาจมีขั้นตอนบันทึกค่าบริการและข้อกำหนดด้านการอนุมัติที่ซับซ้อนกว่าการเข้ารับบริการทั่วไป ส่งผลให้รูปแบบและความท้าทายของกระบวนการแตกต่างกัน. เหตุผลที่สำคัญ ช่วยให้เข้าใจบริบททางคลินิกของข้อมูลการเงิน และวิเคราะห์ได้ว่าบริการทางการแพทย์แต่ละประเภทส่งผลต่อกระบวนการวงจรรายได้และประสิทธิภาพอย่างไร. แหล่งข้อมูล ดึงข้อมูลจาก charge description master (CDM), สายบริการ หรือแผนกที่เกี่ยวข้องกับรายการเรียกเก็บเงินใน Epic. ตัวอย่าง การผ่าตัดผู้ป่วยในรังสีวิทยาผู้ป่วยนอกบริการฉุกเฉิน | |||
| ผู้ใช้ที่รับผิดชอบ ResponsibleUser | รหัสผู้ใช้หรือพนักงานที่ดำเนินกิจกรรม. | ||
| คำอธิบาย คุณลักษณะนี้บันทึก ID ชื่อ หรือหมายเลขพนักงานของผู้รับผิดชอบงานเฉพาะในวงจรรายได้ เช่น บุคลากรทางคลินิกที่ป้อนรายการเรียกเก็บ เจ้าหน้าที่เรียกเก็บเงินที่ส่งเคลม หรือเจ้าหน้าที่ติดตามหนี้ที่ติดตามเคลมที่ถูกปฏิเสธ. การวิเคราะห์แยกตามผู้ใช้ช่วยระบุผู้ที่ทำงานได้ดี ความต้องการฝึกอบรม และการกระจายภาระงาน เป็นข้อมูลสำคัญสำหรับการจัดการผลการปฏิบัติงานและตรวจสอบความแตกต่างของกระบวนการที่เกี่ยวข้องกับบุคคลหรือบทบาทเฉพาะ. เหตุผลที่สำคัญ ช่วยวิเคราะห์ผลการปฏิบัติงานแยกตามบุคคลหรือบทบาท เพื่อค้นหาโอกาสในการฝึกอบรม ความไม่สมดุลของภาระงาน และคอขวดที่เกี่ยวข้องกับทรัพยากร. แหล่งข้อมูล โดยทั่วไปพบได้ในบันทึกการตรวจสอบหรือบันทึกธุรกรรมของ Epic Resolute และมักเชื่อมโยงกับตารางข้อมูลหลักของผู้ใช้ เช่น ระเบียน EMP. ตัวอย่าง j.doebsmith123User7890 | |||
| แผนกเรียกเก็บเงิน BillingDepartment | แผนกหรือทีมงานที่รับผิดชอบเหตุการณ์หรือกิจกรรมการเรียกเก็บเงิน. | ||
| คำอธิบาย คุณลักษณะนี้ระบุหน่วยงาน เช่น 'แผนกเรียกเก็บเงินผู้ป่วยใน' 'แผนกเรียกเก็บเงินผู้ป่วยนอก' หรือ 'ทีมจัดการเคลมที่ถูกปฏิเสธ' ซึ่งเกี่ยวข้องกับเหตุการณ์การเรียกเก็บเงินหรือดำเนินกิจกรรมเฉพาะ. มิตินี้สำคัญต่อแดชบอร์ด 'ตัวชี้วัดผลการดำเนินงานของแผนกเรียกเก็บเงิน' เพราะช่วยเปรียบเทียบตัวชี้วัดสำคัญ เช่น อัตราการปฏิเสธเคลมหรือเวลาที่ใช้บันทึกรายการเรียกเก็บ ช่วยให้ผู้บริหารระบุแผนกที่ทำผลงานได้ดี กำหนดแนวปฏิบัติที่ดีให้เป็นมาตรฐาน และจัดสรรทรัพยากรได้อย่างเหมาะสม. เหตุผลที่สำคัญ ช่วยเปรียบเทียบผลการดำเนินงานระหว่างแผนก เพื่อค้นหาแนวปฏิบัติที่ดีและส่วนที่ควรปรับปรุงหรือเพิ่มทรัพยากร. แหล่งข้อมูล ข้อมูลนี้อาจเชื่อมโยงกับระเบียนผู้ใช้ บัญชีผู้ป่วย หรือสถานที่ให้บริการใน Epic Resolute. ตัวอย่าง แผนกเรียกเก็บเงินโรคหัวใจRCM แผนกรังสีวิทยาสำนักงานเรียกเก็บเงินส่วนกลาง | |||
| ยอดค้างชำระ OutstandingBalance | จำนวนเงินที่ผู้จ่ายเงินหรือผู้ป่วยยังต้องชำระสำหรับเหตุการณ์การเรียกเก็บเงิน. | ||
| คำอธิบาย คุณลักษณะนี้แสดงยอดลูกหนี้คงเหลือของเหตุการณ์การเรียกเก็บเงิน ณ เวลาที่เกิดกิจกรรม และสะท้อนสถานะทางการเงินของเคสตลอดวงจร. ยอดค้างชำระมีความสำคัญต่อการรายงานทางการเงินและรายงานอายุยอดค้างชำระ การวิเคราะห์ยอดนี้ตามช่วงเวลาและมิติต่าง ๆ เช่น ผู้จ่ายเงินหรือแผนก ช่วยจัดลำดับความสำคัญในการติดตามหนี้ บริหารกระแสเงินสด และประเมินความเสี่ยงทางการเงิน. เหตุผลที่สำคัญ วัดผลกระทบทางการเงินจากความล่าช้าของกระบวนการโดยตรง และจำเป็นต่อการจัดลำดับความสำคัญในการติดตามหนี้ การบริหารกระแสเงินสด และการทำความเข้าใจลูกหนี้การค้า. แหล่งข้อมูล เป็นฟิลด์หลักในระเบียนบัญชีผู้ป่วยหรือบัญชีโรงพยาบาล (HAR) ของ Epic Resolute โดยเป็นยอดสะสมที่อัปเดตตามธุรกรรมทางการเงิน. ตัวอย่าง 1500.00250.750.00 | |||
| รหัสเหตุผลการปฏิเสธเคลม DenialReasonCode | รหัสมาตรฐานที่ระบุเหตุผลที่ผู้จ่ายเงินปฏิเสธเคลมที่ส่งไป. | ||
| คำอธิบาย เมื่อผู้จ่ายเงินปฏิเสธเคลม จะระบุรหัสเหตุผลประกอบ เช่น 'บริการไม่อยู่ในความคุ้มครอง' 'เคลมซ้ำ' หรือ 'ต้องการข้อมูลเพิ่มเติม' รหัสเหล่านี้มักเป็นรหัสมาตรฐาน Claim Adjustment Reason Codes (CARCs). คุณลักษณะนี้เป็นหัวใจของแดชบอร์ด 'อัตราและเหตุผลการปฏิเสธเคลม' การวิเคราะห์ความถี่ของรหัสการปฏิเสธแต่ละประเภทช่วยค้นหาสาเหตุหลัก เช่น ปัญหาการรับรองคุณสมบัติ ข้อผิดพลาดในการลงรหัส หรือการขออนุมัติล่วงหน้าที่ขาดหายไป ทำให้กำหนดแนวทางปรับปรุงได้ตรงจุด. เหตุผลที่สำคัญ อธิบายโดยตรงว่าเหตุใดเคลมจึงถูกปฏิเสธ พร้อมข้อมูลที่นำไปใช้ลดอัตราการปฏิเสธ ป้องกันการสูญเสียรายได้ และเร่งการรับชำระเงินได้. แหล่งข้อมูล ข้อมูลนี้อยู่ในธุรกรรมตอบกลับเคลม เช่น ไฟล์ ANSI 835 ที่ได้รับจากผู้จ่ายเงิน และจัดเก็บไว้ในโมดูลจัดการเคลมของ Epic Resolute. ตัวอย่าง CO-16: เคลมหรือบริการขาดข้อมูลOA-18: เคลมหรือบริการซ้ำPR-96: รายการเรียกเก็บที่ไม่อยู่ในความคุ้มครอง | |||
| เหตุผลการปรับปรุงบัญชี AdjustmentReason | เหตุผลของการปรับปรุงยอดบัญชีผู้ป่วยด้วยตนเองหรือโดยอัตโนมัติ. | ||
| คำอธิบาย คุณลักษณะนี้อธิบายสาเหตุที่ยอดบัญชีเปลี่ยนแปลงโดยไม่ใช่การชำระเงินหรือรายการเรียกเก็บตามปกติ เช่น ส่วนลดตามสัญญากับผู้จ่ายเงิน การตัดหนี้ยอดคงเหลือเล็กน้อย หรือการแก้ไขข้อผิดพลาดในการลงบัญชี. ข้อมูลนี้จำเป็นต่อแดชบอร์ด 'ปริมาณรายการปรับปรุงบัญชีแยกตามประเภท' การวิเคราะห์เหตุผลของรายการปรับปรุงช่วยให้องค์กรค้นหาสาเหตุของรายได้ที่สูญหาย เข้าใจผลกระทบจากสัญญากับผู้จ่ายเงิน และพบความไม่มีประสิทธิภาพหรือข้อผิดพลาดที่อาจเกิดขึ้นในกระบวนการเรียกเก็บเงิน. เหตุผลที่สำคัญ ช่วยให้เห็นรายได้ที่สูญหายและความถูกต้องของการเรียกเก็บเงิน โดยอธิบายสาเหตุที่มีการปรับยอดบัญชี และช่วยลดการตัดหนี้ที่ไม่จำเป็น. แหล่งข้อมูล อยู่ในรายละเอียดธุรกรรมของรายการปรับปรุงในโมดูลบัญชีผู้ป่วยของ Epic Resolute. ตัวอย่าง ส่วนลดตามสัญญาตัดหนี้ยอดคงเหลือเล็กน้อยแก้ไขรายการเรียกเก็บซ้ำ | |||
| ชื่อผู้จ่ายเงิน PayerName | ชื่อบริษัทประกัน หน่วยงานภาครัฐ หรือฝ่ายอื่นที่รับผิดชอบการชำระเงิน. | ||
| คำอธิบาย คุณลักษณะนี้ระบุผู้จ่ายเงินหลักที่เกี่ยวข้องกับเหตุการณ์การเรียกเก็บเงิน เช่น 'Blue Cross Blue Shield' 'Medicare' หรือ 'Aetna' กรณีผู้ป่วยชำระเอง อาจระบุชื่อผู้ป่วย. การแบ่งกระบวนการตามผู้จ่ายเงินช่วยให้วิเคราะห์ได้ว่า ผู้จ่ายเงินรายใดมีอัตราการปฏิเสธเคลมสูง รอบการชำระเงินนาน หรือมีข้อกำหนดซับซ้อน ข้อมูลนี้ช่วยปรับกลยุทธ์การเรียกเก็บเงินให้เหมาะกับผู้จ่ายเงินแต่ละราย เพื่อเพิ่มประสิทธิภาพและเร่งการรับชำระเงิน. เหตุผลที่สำคัญ ช่วยวิเคราะห์ผลการดำเนินงานแยกตามผู้จ่ายเงิน เพื่อระบุผู้จ่ายเงินที่มีอัตราการปฏิเสธเคลมสูงหรือรอบการชำระเงินล่าช้า และกำหนดแนวทางติดตามได้ตรงจุด. แหล่งข้อมูล ข้อมูลนี้เป็นส่วนหนึ่งของรายละเอียดความคุ้มครองของผู้ป่วย และเชื่อมโยงกับบัญชีโรงพยาบาล (HAR) ใน Epic Resolute. ตัวอย่าง Medicare Part BUnitedHealthcareAetna PPO | |||
| เป็นระบบอัตโนมัติหรือไม่ IsAutomated | แฟล็กแบบบูลีนที่ระบุว่ากิจกรรมดำเนินการโดยระบบหรือกระบวนการอัตโนมัติหรือไม่. | ||
| คำอธิบาย แฟล็กนี้ใช้แยกงานที่ระบบดำเนินการโดยอัตโนมัติ เช่น การสร้างเคลมหรือการตรวจสอบสิทธิ์อัตโนมัติ ออกจากงานที่ผู้ใช้ทำด้วยตนเอง การวิเคราะห์แอตทริบิวต์นี้ช่วยให้เข้าใจระดับการทำงานอัตโนมัติในกระบวนการ และใช้เปรียบเทียบประสิทธิภาพกับอัตราข้อผิดพลาดของกิจกรรมอัตโนมัติและกิจกรรมที่ทำด้วยตนเอง ค้นหาโอกาสในการนำระบบอัตโนมัติมาใช้เพิ่มเติม และติดตามการทำงานของบอตหรือกฎของระบบที่มีอยู่. เหตุผลที่สำคัญ แยกกิจกรรมที่ระบบดำเนินการออกจากกิจกรรมที่บุคลากรทำ ซึ่งเป็นข้อมูลสำคัญในการประเมินผลของระบบอัตโนมัติและค้นหาโอกาสในการนำระบบอัตโนมัติมาใช้เพิ่มเติม. แหล่งข้อมูล มักระบุได้จากการตรวจสอบว่า 'ResponsibleUser' ของกิจกรรมเป็นบัญชีระบบหรือบัญชีบริการหรือไม่ หรือกำหนดแฟล็กให้ชื่อกิจกรรมที่ทราบว่าเป็นงานอัตโนมัติ. ตัวอย่าง truefalse | |||
| ยอดปรับปรุง AdjustedAmount | จำนวนเงินของรายการปรับปรุงบัญชี. | ||
| คำอธิบาย ฟิลด์นี้บันทึกจำนวนเงินที่ปรับปรุงบัญชีโดยเฉพาะ อาจเป็นค่าบวกหรือลบ ซึ่งหมายถึงการเพิ่มหรือลดยอดคงเหลือในบัญชี ยอดนี้เป็นตัวชี้วัดหลักของแดชบอร์ด “ปริมาณการปรับปรุงบัญชีแยกตามประเภท” เมื่อนำยอดมารวมตามเหตุผลในการปรับปรุง จะเห็นผลกระทบทางการเงินของการปรับปรุงแต่ละประเภทได้ชัดเจน เช่น รายได้ที่ตัดจำหน่ายตามข้อกำหนดในสัญญา เทียบกับยอดที่สูญเสียจากข้อผิดพลาดที่แก้ไขได้. เหตุผลที่สำคัญ ใช้วัดผลกระทบทางการเงินจากการปรับปรุงบัญชี ช่วยประเมินรายได้ที่รั่วไหลและต้นทุนจากความคลาดเคลื่อนในการเรียกเก็บเงิน. แหล่งข้อมูล อยู่ในตารางรายละเอียดรายการทางการเงินของ Epic Resolute และเชื่อมโยงกับรายการประเภทการปรับปรุง. ตัวอย่าง -1250.45-50.0025.10 | |||
| รหัสเคลม ClaimId | รหัสเฉพาะที่กำหนดให้กับเคลมประกันที่ส่งไปยังผู้จ่ายเงิน. | ||
| คำอธิบาย แอตทริบิวต์นี้คือรหัสเฉพาะของแบบฟอร์มเคลม เช่น CMS-1500 หรือ UB-04 ที่ส่งให้ผู้จ่ายเงิน การเรียกเก็บเงินหนึ่งครั้งอาจมีหลายเคลม หากมีการเรียกเก็บเงินซ้ำหรือยื่นอุทธรณ์ การติดตามด้วยรหัสเคลมช่วยวิเคราะห์ขั้นตอนการส่งเคลมและการจัดการเคลมที่ถูกปฏิเสธได้อย่างละเอียด อีกทั้งช่วยแยกกิจกรรมของเคลมครั้งแรกออกจากกิจกรรมของเคลมที่ส่งซ้ำในภายหลังสำหรับบริการเดียวกัน. เหตุผลที่สำคัญ เป็นรหัสเฉพาะสำหรับติดตามวงจรของการส่งเคลมแต่ละครั้ง ซึ่งจำเป็นต่อการวิเคราะห์การส่งเคลมซ้ำและการยื่นอุทธรณ์. แหล่งข้อมูล โมดูลจัดการเคลมของ Epic Resolute สร้างรหัสนี้เมื่อมีการสร้างเคลม และจัดเก็บไว้ในตารางข้อมูลเคลม. ตัวอย่าง CLM-2023-98765CLAIM-0012345623189A4567 | |||
| รหัสผู้ป่วย PatientId | รหัสเฉพาะของผู้ป่วยที่รับบริการ. | ||
| คำอธิบาย แอตทริบิวต์นี้คือหมายเลขเวชระเบียน (MRN) หรือรหัสเฉพาะอื่นของผู้ป่วย ใช้เชื่อมโยงรายการเรียกเก็บเงินกับบุคคลนั้น โดยทั่วไปจะไม่ใช้ข้อมูลนี้เป็นมิติหลักในการวิเคราะห์เพื่อคุ้มครองความเป็นส่วนตัวของผู้ป่วย แต่จำเป็นต่อการตรวจสอบความถูกต้องของข้อมูล และใช้รวบรวมรายการเรียกเก็บเงินทั้งหมดของผู้ป่วยรายเดียวเพื่อทำความเข้าใจเส้นทางด้านการเงินโดยรวมได้ นอกจากนี้ยังสำคัญต่อการเชื่อมโยงข้อมูลกับกระบวนการทางคลินิกในอนาคต. เหตุผลที่สำคัญ เชื่อมโยงข้อมูลการเงินกับผู้ป่วยรายหนึ่ง ช่วยตรวจสอบความถูกต้องของข้อมูลและอาจนำไปวิเคราะห์เส้นทางของผู้ป่วยโดยรวมได้ แต่ต้องจัดการอย่างระมัดระวังเพื่อคุ้มครองความเป็นส่วนตัว. แหล่งข้อมูล เป็นรหัสพื้นฐานที่พบได้ทั่วทั้ง Epic และเชื่อมโยงกับข้อมูลลงทะเบียนและบัญชีของผู้ป่วย. ตัวอย่าง MRN-1234567MRN-8765432MRN-5551234 | |||
| ระบบต้นทาง SourceSystem | ระบบสารสนเทศที่เป็นแหล่งที่มาของข้อมูล. | ||
| คำอธิบาย คุณลักษณะนี้ระบุระบบต้นทางของระเบียน ซึ่งในกรณีนี้คือ Epic Resolute หากมีหลายระบบที่เชื่อมต่อกัน ฟิลด์นี้ช่วยแยกแหล่งที่มาของข้อมูล. แม้ในมุมมองที่มีระบบเดียว ฟิลด์นี้อาจดูซ้ำซ้อน แต่ถือเป็นแนวปฏิบัติที่ดีสำหรับการกำกับดูแลข้อมูลและการรองรับการขยายระบบ ช่วยให้ระบุที่มาได้ชัดเจน หากภายหลังมีการเชื่อมข้อมูลจากระบบอื่น เช่น แพลตฟอร์มของหน่วยงานติดตามหนี้. เหตุผลที่สำคัญ แสดงที่มาและบริบทของข้อมูล ซึ่งช่วยให้ทราบแหล่งกำเนิดอย่างชัดเจน เป็นประโยชน์ต่อการกำกับดูแลข้อมูลและการแก้ไขปัญหา. แหล่งข้อมูล โดยทั่วไปจะเพิ่มค่าแบบคงที่ระหว่างการดึงและแปลงข้อมูล เพื่อระบุแหล่งที่มาของชุดข้อมูล. ตัวอย่าง Epic ResoluteEpicResolute_V2023 | |||
| ระยะเวลารวมของวงจรรายได้ TotalRevenueCycleTime | ระยะเวลารวมที่คำนวณตั้งแต่เหตุการณ์บริการครั้งแรกจนถึงการชำระเงินครั้งสุดท้ายหรือการปิดบัญชี. | ||
| คำอธิบาย นี่คือ KPI ระดับเคสที่วัดระยะเวลาตั้งแต่ต้นจนจบของวงจรรายได้สำหรับรายการเรียกเก็บเงินหนึ่งครั้ง โดยทั่วไปคำนวณจากเวลาระหว่างกิจกรรม 'ให้บริการแล้ว' กับกิจกรรม 'ได้รับชำระเงิน' หรือ 'ปิดบัญชี' ครั้งสุดท้าย ตัวชี้วัดภาพรวมนี้ช่วยให้เห็นประสิทธิภาพของกระบวนการ RCM ตั้งแต่ต้นจนจบ การติดตาม KPI นี้ตามช่วงเวลาช่วยวัดผลของการปรับปรุงกระบวนการ และใช้เป็นตัวชี้วัดสำคัญของความเร็วในการเปลี่ยนรายได้เป็นเงินสด. เหตุผลที่สำคัญ แสดงภาพรวมประสิทธิภาพของกระบวนการตั้งแต่ต้นจนจบ โดยวัดโดยตรงว่าต้องใช้เวลานานเท่าใดจึงจะเปลี่ยนบริการเป็นเงินสด. แหล่งข้อมูล คำนวณตัวชี้วัดนี้ในเครื่องมือ process mining โดยเลือกเหตุการณ์แรกและเหตุการณ์สุดท้ายของแต่ละเคส แล้วหาผลต่างของเวลา. ตัวอย่าง 259200038880005184000 | |||
| วันครบกำหนดชำระเงิน PaymentDueDate | วันที่คาดว่าจะได้รับชำระค่าบริการที่เรียกเก็บเงิน. | ||
| คำอธิบาย แอตทริบิวต์นี้ระบุวันครบกำหนดชำระเงินตามที่แจ้งไว้ในใบแจ้งหนี้หรือกำหนดไว้ในสัญญากับผู้จ่ายเงิน ใช้เป็นเกณฑ์วัดว่ามีการชำระเงินตรงเวลาหรือไม่ วันครบกำหนดชำระเงินเป็นข้อมูลสำคัญสำหรับจัดทำ “รายงานอายุยอดคงเหลือค้างชำระ” เมื่อนำวันที่ปัจจุบันมาเทียบกับวันครบกำหนดของยอดที่ยังเปิดอยู่ จะจัดกลุ่มลูกหนี้ตามระยะเวลาค้างชำระได้ เช่น 0-30 วัน หรือเกินกำหนด 31-60 วัน ซึ่งช่วยจัดลำดับการติดตามหนี้จากบัญชีที่ค้างชำระนานที่สุด. เหตุผลที่สำคัญ ใช้เป็นฐานในการวิเคราะห์อายุลูกหนี้ ซึ่งสำคัญต่อการจัดลำดับการติดตามหนี้และบริหารความเสี่ยงทางการเงินจากใบเรียกเก็บเงินที่ยังไม่ได้ชำระ. แหล่งข้อมูล วันที่นี้มักคำนวณจากวันที่ในใบแจ้งหนี้และเงื่อนไขการชำระเงินที่บันทึกไว้ในสัญญากับผู้จ่ายเงินหรือข้อมูลบัญชีผู้ป่วยใน Epic. ตัวอย่าง 2023-05-302023-06-152023-07-01 | |||
| เวลาสิ้นสุดเหตุการณ์ EventEndTime | เวลาประทับที่ระบุว่ากิจกรรมเสร็จสิ้นเมื่อใด ใช้คำนวณระยะเวลาของกิจกรรมได้. | ||
| คำอธิบาย แอตทริบิวต์นี้บันทึกเวลาที่กิจกรรมเสร็จสิ้น กิจกรรมหลายอย่างเกิดขึ้นทันที โดย StartTime เท่ากับ EndTime แต่งานบางประเภทใช้เวลานานพอที่จะวัดได้ เช่น การโทรติดตามเคลมที่ถูกปฏิเสธ หากมี EndTime จะคำนวณเวลาที่ใช้ดำเนินกิจกรรมได้โดยตรงจาก 'EndTime' - 'StartTime' ซึ่งแม่นยำกว่าการอนุมานระยะเวลาจากเวลาเริ่มต้นของกิจกรรมถัดไป เพราะคำนึงถึงช่วงเวลาว่างระหว่างขั้นตอนด้วย ข้อมูลนี้เป็นองค์ประกอบสำคัญในการคำนวณแอตทริบิวต์ 'ProcessingTime'. เหตุผลที่สำคัญ ช่วยคำนวณเวลาที่ใช้ทำกิจกรรมแต่ละรายการได้อย่างแม่นยำ ซึ่งจำเป็นต่อการค้นหางานที่ไม่มีประสิทธิภาพและวัดผลิตภาพของทรัพยากร. แหล่งข้อมูล ข้อมูลนี้อาจมีในบางโมดูลของ Epic Resolute ที่ติดตามเวลาเริ่มต้นและสิ้นสุดของงาน เช่น บันทึกคิวงานหรือการจัดการกิจกรรม แต่บ่อยครั้งไม่มีการบันทึกไว้อย่างชัดเจน. ตัวอย่าง 2023-04-15T09:45:00Z2023-04-16T11:15:30Z2023-05-01T14:02:00Z | |||
| อัปเดตข้อมูลล่าสุด LastDataUpdate | เวลาประทับที่ระบุว่าข้อมูลของเหตุการณ์นี้ได้รับการรีเฟรชหรือดึงจากระบบต้นทางครั้งล่าสุดเมื่อใด. | ||
| คำอธิบาย คุณลักษณะนี้แสดงความใหม่ของข้อมูล โดยระบุครั้งล่าสุดที่ดึงระเบียนจาก Epic Resolute เข้าสู่ชุดข้อมูล process mining. ข้อมูลนี้ช่วยให้เข้าใจว่าการวิเคราะห์เป็นปัจจุบันเพียงใด และใช้ตรวจสอบความถูกต้องของข้อมูล ผู้ใช้จึงทราบได้ว่ากำลังดูข้อมูลล่าสุดที่มีหรือไม่ และสามารถจัดการรอบการรีเฟรชข้อมูลได้. เหตุผลที่สำคัญ ช่วยให้ผู้ใช้ทราบว่าข้อมูลที่กำลังวิเคราะห์เป็นปัจจุบันเพียงใด ซึ่งสำคัญต่อการตัดสินใจทางธุรกิจที่ถูกต้องและอิงข้อมูลล่าสุด. แหล่งข้อมูล กระบวนการ ETL (Extract, Transform, Load) จะเพิ่มเวลาประทับนี้ระหว่างนำเข้าข้อมูล. ตัวอย่าง 2023-06-10T02:00:00Z2023-06-11T02:00:00Z | |||
กิจกรรมในการจัดการวงจรรายได้
| กิจกรรม | คำอธิบาย | ||
|---|---|---|---|
| ได้รับชำระเงินแล้ว | หมายถึงการได้รับชำระเงินจากผู้จ่ายเงินหรือผู้ป่วย โดยทั่วไปบันทึกเหตุการณ์นี้เมื่อโหลดคำชี้แจงการจ่ายเงินอิเล็กทรอนิกส์ (ERA) หรือป้อนข้อมูลเช็คที่ได้รับด้วยตนเองเข้าสู่ระบบ. | ||
| เหตุผลที่สำคัญ กิจกรรมนี้เป็นหมุดหมายสำคัญที่ระบุว่ากำลังมีรายได้เข้ามา ระยะเวลาตั้งแต่ส่งเคลมจนได้รับชำระเงินเป็นตัวชี้วัดสำคัญของผลการดำเนินงานด้านลูกหนี้การค้า. แหล่งข้อมูล มีการบันทึกไว้อย่างชัดเจนเป็นธุรกรรมการรับชำระเงินใน Resolute โดยธุรกรรมเหล่านี้มีวันที่ แหล่งที่มา และจำนวนเงิน และมักบันทึกก่อนจัดสรรเงินไปยังรายการเรียกเก็บแต่ละรายการ. บันทึก ดึงธุรกรรมการรับชำระเงินจากบันทึกธุรกรรมทางการเงิน โดยมักระบุได้จากประเภทธุรกรรมเฉพาะ. ประเภทเหตุการณ์ explicit | |||
| บันทึกรับชำระเงินลงบัญชีแล้ว | เหตุการณ์นี้เกิดขึ้นเมื่อจัดสรรเงินที่ได้รับไปยังรายการเรียกเก็บเฉพาะในบัญชีผู้ป่วย การดำเนินการนี้ช่วยลดยอดค้างชำระของเหตุการณ์การเรียกเก็บเงิน. | ||
| เหตุผลที่สำคัญ การบันทึกรับชำระเงินอย่างมีประสิทธิภาพมีความสำคัญต่อการรักษายอดบัญชีให้ถูกต้องและปิดเหตุการณ์การเรียกเก็บเงิน ช่วยให้ระบุยอดคงเหลือสำหรับการเรียกเก็บจากผู้จ่ายเงินรายถัดไปหรือการติดตามหนี้ได้อย่างถูกต้อง. แหล่งข้อมูล มีการบันทึกธุรกรรมนี้ไว้อย่างชัดเจนใน Resolute การบันทึกรับชำระเงินจะเชื่อมธุรกรรมการรับชำระเงินกับธุรกรรมรายการเรียกเก็บอย่างน้อยหนึ่งรายการ โดยบันทึกไว้ในตารางรายละเอียดธุรกรรม. บันทึก ดึงระเบียนธุรกรรมที่จัดสรรเงินชำระให้กับรายการเรียกเก็บ ซึ่งระบุได้จากประเภทธุรกรรมเฉพาะ. ประเภทเหตุการณ์ explicit | |||
| บันทึกรายการเรียกเก็บแล้ว | หมายถึงการบันทึกรายการค่าบริการที่เรียกเก็บได้อย่างเป็นทางการ ใน Epic โดยทั่วไปจะเป็นรายการธุรกรรมที่ลงในบัญชีผู้ป่วยโดยตรง ซึ่งอาจสร้างขึ้นโดยอัตโนมัติจากกิจกรรมทางคลินิกหรือป้อนด้วยตนเอง. | ||
| เหตุผลที่สำคัญ นี่คือหมุดหมายแรกที่สำคัญ การวัดความเร็วและความถูกต้องในการบันทึกรายการเรียกเก็บช่วยเร่งกระบวนการเรียกเก็บเงินและทำให้มั่นใจว่ามีการเรียกเก็บค่าบริการทุกรายการ. แหล่งข้อมูล มีการบันทึกไว้อย่างชัดเจนในบันทึกธุรกรรมของ Resolute รายการเรียกเก็บแต่ละรายการเป็นรายการแยกที่มีวันที่ลงบัญชี วันที่ให้บริการ และจำนวนเงิน โดยมักพบในตารางอย่าง ARPB_TRANSACTIONS. บันทึก ดึงธุรกรรมการลงบัญชีรายการเรียกเก็บจากบันทึกธุรกรรมทางการเงินของระบบ. ประเภทเหตุการณ์ explicit | |||
| ปิดบัญชีแล้ว | นี่คือกิจกรรมสุดท้าย ซึ่งระบุว่ายอดค้างชำระของเหตุการณ์การเรียกเก็บเงินเป็นศูนย์และไม่มีงานค้างอีกต่อไป อาจเกิดจากการชำระเงินครบ การปรับปรุงบัญชี หรือการตัดหนี้. | ||
| เหตุผลที่สำคัญ เหตุการณ์นี้ระบุว่าวงจรรายได้ของเหตุการณ์การเรียกเก็บเงินเสร็จสมบูรณ์ ระยะเวลาตั้งแต่ให้บริการจนปิดบัญชีเป็น KPI สำคัญที่ใช้วัดประสิทธิภาพโดยรวมของกระบวนการ. แหล่งข้อมูล โดยทั่วไปอนุมานเหตุการณ์นี้จากช่วงเวลาที่พบว่ายอดบัญชีของเหตุการณ์การเรียกเก็บเงินเป็นศูนย์และคงอยู่ที่ศูนย์. บันทึก อนุมานโดยคำนวณยอดบัญชีสะสม แล้วระบุเวลาของธุรกรรมสุดท้ายที่ทำให้ยอดเป็นศูนย์. ประเภทเหตุการณ์ inferred | |||
| ผู้จ่ายเงินปฏิเสธเคลม | หมายถึงการได้รับแจ้งจากผู้จ่ายเงินว่าเคลมถูกปฏิเสธ โดยบันทึกเมื่อ Epic ประมวลผลคำชี้แจงการจ่ายเงินอิเล็กทรอนิกส์ (ไฟล์ 835) หรือเมื่อผู้ใช้บันทึกการปฏิเสธด้วยตนเอง. | ||
| เหตุผลที่สำคัญ กิจกรรมนี้เริ่มวงจรการแก้ไขงานที่สำคัญ การวิเคราะห์เหตุผลและจำนวนเคลมที่ถูกปฏิเสธจำเป็นต่อการค้นหาสาเหตุหลัก เพิ่มอัตราการได้รับชำระเงินตั้งแต่ครั้งแรก และลดความล่าช้าในการเรียกเก็บเงิน. แหล่งข้อมูล มีการบันทึกไว้อย่างชัดเจนเป็นธุรกรรมหรือการอัปเดตสถานะของเคลม โดยทั่วไปข้อมูลการปฏิเสธ รวมถึงรหัสเหตุผล จะได้รับทางอิเล็กทรอนิกส์และบันทึกลงในบัญชี. บันทึก กรองประเภทธุรกรรมหรือการอัปเดตสถานะเคลมที่ระบุว่ามีการปฏิเสธ. ประเภทเหตุการณ์ explicit | |||
| ส่งเคลมให้ผู้จ่ายเงินแล้ว | เหตุการณ์นี้ระบุว่าได้ส่งเคลมไปยังบริษัทประกันเพื่อพิจารณาอย่างเป็นทางการแล้ว ใน Epic จะมีการติดตามเหตุการณ์นี้และบันทึกเมื่อส่งไฟล์เคลมอิเล็กทรอนิกส์ไปยัง clearinghouse หรือผู้จ่ายเงิน. | ||
| เหตุผลที่สำคัญ หมุดหมายนี้สำคัญ เพราะเป็นจุดเริ่มนับระยะเวลาการชำระเงินของผู้จ่ายเงิน การวิเคราะห์ช่วยวัดประสิทธิภาพของกระบวนการส่งเคลม และใช้ติดตาม KPI ระยะเวลาส่งใบแจ้งหนี้ถึงผู้จ่ายเงิน. แหล่งข้อมูล มีการบันทึกเหตุการณ์นี้ไว้อย่างชัดเจนใน Resolute ระเบียนเคลมจะแสดงสถานะการส่งและเวลาที่ส่ง. บันทึก บันทึกเวลาที่สถานะเคลมเปลี่ยนเป็น 'Submitted' หรือ 'Transmitted'. ประเภทเหตุการณ์ explicit | |||
| ให้บริการแล้ว | กิจกรรมนี้ระบุเวลาที่ให้บริการทางคลินิกแก่ผู้ป่วย ซึ่งเป็นจุดเริ่มต้นของเหตุการณ์การเรียกเก็บเงิน โดยมักบันทึกจาก Epic EHR (EpicCare) เมื่อบุคลากรทางคลินิกรับรองการตรวจหรือหัตถการ. | ||
| เหตุผลที่สำคัญ นี่คือเหตุการณ์เริ่มต้นหลักของวงจรรายได้ การวิเคราะห์เวลาตั้งแต่จุดนี้จนถึงการบันทึกรายการเรียกเก็บมีความสำคัญต่อการค้นหาความล่าช้าในการเริ่มเรียกเก็บเงินและรายได้ที่อาจสูญหาย. แหล่งข้อมูล โดยทั่วไปอนุมานเหตุการณ์นี้จากเวลาที่ให้บริการหรือเวลาที่เข้ารับบริการในโมดูลทางคลินิก ซึ่งเชื่อมโยงกับบัญชีเรียกเก็บเงิน วันที่ให้บริการในรายการธุรกรรมเรียกเก็บเงินเป็นข้อมูลสำคัญ. บันทึก อนุมานจากวันที่ให้บริการที่ระบุในรายการเรียกเก็บเงินรายการแรกของเหตุการณ์การเรียกเก็บเงิน. ประเภทเหตุการณ์ inferred | |||
| ปรับปรุงบัญชีแล้ว | กิจกรรมนี้หมายถึงธุรกรรมที่ไม่ใช่การชำระเงินแต่ทำให้ยอดบัญชีเปลี่ยนแปลง เช่น การปรับยอดตามสัญญา การตัดหนี้ยอดคงเหลือเล็กน้อย หรือส่วนลดเพื่อรักษาความสัมพันธ์ โดยบันทึกเป็นประเภทธุรกรรมเฉพาะ. | ||
| เหตุผลที่สำคัญ การวิเคราะห์รายการปรับปรุงมีความสำคัญต่อการค้นหารายได้ที่สูญหาย หากรายการปรับปรุงบางประเภทมีจำนวนมาก อาจบ่งชี้ถึงปัญหาเกี่ยวกับตารางค่าบริการ สัญญา หรือแนวปฏิบัติภายใน. แหล่งข้อมูล มีการบันทึกรายการปรับปรุงไว้อย่างชัดเจนในบันทึกทางการเงินของ Resolute โดยแต่ละรายการจะมีประเภทหรือรหัสเหตุผลเฉพาะ. บันทึก กรองประเภทธุรกรรมที่ตรงกับการปรับปรุงทางการเงินหรือการตัดหนี้. ประเภทเหตุการณ์ explicit | |||
| เริ่มติดตามเคลมที่ถูกปฏิเสธแล้ว | กิจกรรมนี้ระบุจุดเริ่มต้นของกระบวนการภายในเพื่อทบทวนและแก้ไขเคลมที่ถูกปฏิเสธ โดยมักบันทึกเมื่อผู้ใช้รับผิดชอบเคลมที่ถูกปฏิเสธใน workqueue หรือเปลี่ยนสถานะเคลม. | ||
| เหตุผลที่สำคัญ การติดตามขั้นตอนนี้ช่วยวัดความรวดเร็วในการตอบสนองของทีมจัดการเคลมที่ถูกปฏิเสธ หากเริ่มติดตามล่าช้าหลังได้รับการปฏิเสธ วงจรรายได้อาจยืดเยื้อโดยไม่จำเป็น. แหล่งข้อมูล โดยทั่วไปอนุมานจากการเปลี่ยนสถานะเคลมหรือประวัติการมอบหมายงานใน workqueue ของ Epic ตัวอย่างเช่น สถานะเคลมอาจเปลี่ยนจาก 'Denied' เป็น 'In Review'. บันทึก อนุมานจากการเปลี่ยนสถานะเคลมหรือรายการในบันทึกการตรวจสอบที่แสดงว่าผู้ใช้เริ่มดำเนินการกับเคลมที่ถูกปฏิเสธแล้ว. ประเภทเหตุการณ์ inferred | |||
| ส่งเคลมอีกครั้งแล้ว | เหตุการณ์นี้เกิดขึ้นหลังจากแก้ไขเคลมที่ถูกปฏิเสธและส่งกลับไปยังผู้จ่ายเงิน เป็นเหตุการณ์ส่งเคลมอีกครั้งที่แยกจากครั้งแรกและเชื่อมโยงกับเคลมต้นฉบับ. | ||
| เหตุผลที่สำคัญ นี่เป็นส่วนสำคัญของวงจรการแก้ไขงาน การวัดเวลาที่ใช้ส่งเคลมอีกครั้งและอัตราความสำเร็จของเคลมที่ส่งซ้ำมีความสำคัญต่อการประเมินประสิทธิผลของกระบวนการแก้ไขเคลมที่ถูกปฏิเสธ. แหล่งข้อมูล มีการบันทึกเหตุการณ์นี้ไว้อย่างชัดเจนเช่นเดียวกับการส่งครั้งแรก แต่มักระบุว่าเป็นการส่งซ้ำ ระเบียนเคลมจะแสดงเวลาส่งใหม่ และอาจมีรหัสการส่งซ้ำด้วย. บันทึก บันทึกเวลาที่ส่งเคลมซึ่งระบุว่าเป็นการแก้ไขหรือส่งซ้ำ. ประเภทเหตุการณ์ explicit | |||
| ส่งยอดคงเหลือไปติดตามหนี้แล้ว | ระบุจุดที่โอนยอดบัญชีที่ยังไม่ได้ชำระเข้าสู่กระบวนการติดตามหนี้ภายในหรือภายนอก โดยมักเป็นการเปลี่ยนสถานะอย่างชัดเจนในบัญชีหรือเหตุการณ์การเรียกเก็บเงิน. | ||
| เหตุผลที่สำคัญ กิจกรรมนี้เริ่มขั้นตอนสุดท้ายของการติดตามยอดค้างชำระ การติดตามอัตราความสำเร็จและระยะเวลาของกระบวนการติดตามหนี้มีความสำคัญต่อการลดหนี้สูญ. แหล่งข้อมูล โดยทั่วไปเป็นเหตุการณ์ที่บันทึกไว้อย่างชัดเจน Epic มีฟังก์ชันสำหรับโอนบัญชีไปยังหน่วยงานติดตามหนี้ ซึ่งจะสร้างรายการบันทึกหรือเปลี่ยนสถานะในบัญชี. บันทึก ระบุการเปลี่ยนสถานะหรือธุรกรรมที่แสดงว่ามีการส่งบัญชีให้หน่วยงานติดตามหนี้แล้ว. ประเภทเหตุการณ์ explicit | |||
| สร้างเคลมแล้ว | กิจกรรมนี้หมายถึงระบบสร้างเคลมหรือใบแจ้งหนี้อย่างเป็นทางการจากรายการเรียกเก็บที่บันทึกไว้ เป็นขั้นตอนเตรียมการก่อนส่งเคลมไปยังผู้จ่ายเงินหรือผู้ป่วย. | ||
| เหตุผลที่สำคัญ การติดตามการสร้างเคลมช่วยแยกความล่าช้าระหว่างการบันทึกรายการเรียกเก็บกับการเตรียมเคลมเพื่อส่งได้ ขั้นตอนภายในนี้มีผลต่อความรวดเร็วโดยรวมของการเรียกเก็บเงิน. แหล่งข้อมูล โดยทั่วไป ระบบจะบันทึกเหตุการณ์นี้เมื่อมีการทำงานของชุดงานสร้างการเรียกเก็บเงินหรือเคลม ระบบจะบันทึกเวลาที่สร้างไฟล์เคลม เช่น ไฟล์ 837 สำหรับบัญชีหนึ่ง ๆ. บันทึก ค้นหารายการบันทึกหรือการเปลี่ยนสถานะที่ระบุว่าเคลมถูกรวบรวมข้อมูลครบและพร้อมส่ง. ประเภทเหตุการณ์ explicit | |||
คู่มือการดึงข้อมูล
ขั้นตอน
- เชื่อมต่อฐานข้อมูล: ขอข้อมูลเข้าสู่ระบบแบบอ่านอย่างเดียวสำหรับฐานข้อมูล Epic Clarity ใช้ SQL client ทั่วไป เช่น DBeaver หรือ Microsoft SQL Server Management Studio เพื่อเชื่อมต่อกับเซิร์ฟเวอร์ฐานข้อมูล
- ระบุตารางหลัก: ตารางหลักที่ใช้ดึงข้อมูล ได้แก่
HSP_ACCOUNTสำหรับข้อมูลเคส,HSP_TRANSACTIONSสำหรับเหตุการณ์ทางการเงิน,CLP_CLAIM_INFOสำหรับสถานะเคลม และF_ARHB_TX_SET_POST_HXสำหรับรายละเอียดการบันทึกการชำระเงิน นอกจากนี้ยังต้องเชื่อมกับไฟล์ข้อมูลหลัก เช่นCLARITY_EMPสำหรับรายละเอียดผู้ใช้ - กำหนดขอบเขต: ก่อนเขียน query ให้กำหนดขอบเขตการวิเคราะห์ ระบุช่วงวันที่ให้ชัดเจน โดยทั่วไปใช้ 3 ถึง 6 เดือน และเลือกพื้นที่ให้บริการของโรงพยาบาล (
SERV_AREA_ID) หรือประเภทบัญชีที่ต้องการรวมหรือตัดออก - เขียน SQL query: สร้าง SQL query โดยใช้ Common Table Expression (CTE) เพื่อเลือกชุดค่า
HSP_ACCOUNT_IDที่อยู่ในขอบเขตที่กำหนดก่อน จากนั้นใช้ชุดนี้เป็นข้อมูลตั้งต้นของเหตุการณ์เรียกเก็บเงิน - รวม query ของแต่ละกิจกรรม: เขียนคำสั่ง
SELECTแยกสำหรับกิจกรรมที่ต้องการทั้ง 12 รายการ โดยดึงข้อมูลจากตารางที่เกี่ยวข้อง และเชื่อมกลับไปยัง CTE แรกเพื่อให้วิเคราะห์เฉพาะบัญชีที่กำหนดไว้ - รวม query ด้วย UNION ALL: ใช้ตัวดำเนินการ
UNION ALLรวมผลลัพธ์จาก query ของแต่ละกิจกรรมเป็นบันทึกเหตุการณ์ชุดเดียว โดยนำแถวจากแต่ละ query มาต่อกัน - จับคู่กับสคีมามาตรฐาน: ในคำสั่ง
SELECTแต่ละรายการ ให้ตั้งชื่อแทนคอลัมน์ให้ตรงกับสคีมาของ ProcessMind เช่นBillingEvent,ActivityName,EventTimestamp,ResponsibleUserเป็นต้น ใช้NULLกับแอตทริบิวต์ที่ไม่เกี่ยวข้องกับกิจกรรมนั้น - เรียกใช้และปรับ query: เรียกใช้ query ทั้งชุดกับฐานข้อมูล Clarity เนื่องจากตารางมีขนาดใหญ่ การประมวลผลอาจใช้เวลานาน หากประสิทธิภาพไม่ดี ให้จำกัดช่วงวันที่เพิ่มเติมหรือเพิ่มตัวกรองที่เจาะจงใน CTE แรก
- ตรวจสอบผลลัพธ์: เมื่อ query ทำงานเสร็จ ให้ตรวจสอบผลลัพธ์สองสามร้อยแถวแรก ยืนยันว่ามีคอลัมน์ครบ รูปแบบเวลาเป็นแบบเดียวกัน และค่า
ActivityNameแสดงตามที่คาดไว้ - ส่งออกเป็น CSV: ส่งออกผลลัพธ์ทั้งหมดจาก SQL client เป็นไฟล์ CSV โดยใช้การเข้ารหัส UTF-8 และมีแถวส่วนหัวที่ระบุชื่อคอลัมน์ถูกต้อง
- เตรียมไฟล์สำหรับอัปโหลด: ก่อนอัปโหลดไปยัง ProcessMind ให้เปิดไฟล์ CSV เพื่อตรวจสอบว่าไม่มีข้อผิดพลาดด้านรูปแบบ ตรวจสอบว่ารูปแบบเวลาเป็นแบบเดียวกัน เช่น
YYYY-MM-DD HH:MI:SSจากนั้นไฟล์ก็พร้อมนำเข้าแล้ว.
การกำหนดค่า
- การเชื่อมต่อฐานข้อมูล: ต้องมีบัญชีผู้ใช้แบบอ่านอย่างเดียวที่เข้าถึงฐานข้อมูล Epic Clarity ได้
- พารามิเตอร์ช่วงวันที่: คิวรีที่ให้มามีตัวแปร
@StartDateและ@EndDateซึ่งต้องกำหนดเพื่อระบุช่วงเวลาวิเคราะห์ แนะนำให้ใช้ช่วง 3 ถึง 6 เดือน เพื่อให้สมดุลระหว่างปริมาณข้อมูลกับประสิทธิภาพ - การจับคู่ตารางและคอลัมน์: คิวรีตั้งสมมติฐานว่าชื่อตารางและคอลัมน์เป็นไปตามมาตรฐานของ Clarity การกำหนดค่าหรือเวอร์ชัน Epic ขององค์กรคุณอาจแตกต่างออกไป จึงอาจต้องปรับชื่อตาราง ชื่อคอลัมน์ หรือเงื่อนไขการเชื่อมตามความเหมาะสม
- รหัสธุรกรรมและสถานะ: คิวรีมีตัวอย่างค่า เช่น
[Your Denial Tx Type]และ[Your Collections Status Code]คุณต้องสอบถามผู้ดูแลระบบ Epic หรือดูไฟล์ข้อมูลหลักที่เกี่ยวข้อง เช่นZC_TX_TYPEหรือZC_ACCOUNT_STATUSเพื่อหารหัสที่ถูกต้องสำหรับระบบของคุณ - การกรอง: เพื่อเพิ่มประสิทธิภาพและให้การวิเคราะห์ตรงประเด็นยิ่งขึ้น ให้เพิ่มตัวกรองใน CTE
BaseAccountsขั้นต้น ตัวกรองที่ใช้บ่อย ได้แก่SERV_AREA_IDเพื่อจำกัดตามพื้นที่ให้บริการของโรงพยาบาล หรือACCOUNT_CLASS_Cเพื่อเน้นการเรียกเก็บเงินผู้ป่วยในหรือผู้ป่วยนอก.
ตัวอย่างคำค้น sql
DECLARE @StartDate DATE = '2023-01-01';
DECLARE @EndDate DATE = '2023-06-30';
WITH BaseAccounts AS (
SELECT DISTINCT
HA.HSP_ACCOUNT_ID
FROM
HSP_ACCOUNT HA
WHERE
HA.ADM_DATE_TIME >= @StartDate
AND HA.ADM_DATE_TIME <= @EndDate
-- Add additional filters here if needed, for example:
-- AND HA.SERV_AREA_ID = [Your Service Area ID]
)
-- 1. Service Rendered
SELECT
tx.HSP_ACCOUNT_ID AS BillingEvent,
'Service Rendered' AS ActivityName,
tx.SERVICE_DATE AS EventTimestamp,
emp.USER_ID AS ResponsibleUser,
dep.DEPARTMENT_NAME AS BillingDepartment,
NULL AS DenialReasonCode,
NULL AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
proc.PROC_NAME AS ServiceType
FROM HSP_TRANSACTIONS tx
INNER JOIN BaseAccounts ba ON tx.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
LEFT JOIN HSP_ACCOUNT acct ON tx.HSP_ACCOUNT_ID = acct.HSP_ACCOUNT_ID
LEFT JOIN CLARITY_EMP emp ON tx.USER_ID = emp.USER_ID
LEFT JOIN CLARITY_DEP dep ON acct.DEPARTMENT_ID = dep.DEPARTMENT_ID
LEFT JOIN CLARITY_EAP proc ON tx.PROC_ID = proc.PROC_ID
WHERE tx.TX_TYPE_C = 1 -- Charge Transaction Type
AND tx.ORIG_REV_TX_ID IS NULL -- Not a reversal
UNION ALL
-- 2. Charges Captured
SELECT
tx.HSP_ACCOUNT_ID AS BillingEvent,
'Charges Captured' AS ActivityName,
tx.POST_DATE AS EventTimestamp,
emp.USER_ID AS ResponsibleUser,
dep.DEPARTMENT_NAME AS BillingDepartment,
NULL AS DenialReasonCode,
NULL AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
proc.PROC_NAME AS ServiceType
FROM HSP_TRANSACTIONS tx
INNER JOIN BaseAccounts ba ON tx.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
LEFT JOIN HSP_ACCOUNT acct ON tx.HSP_ACCOUNT_ID = acct.HSP_ACCOUNT_ID
LEFT JOIN CLARITY_EMP emp ON tx.POSTING_USER_ID = emp.USER_ID
LEFT JOIN CLARITY_DEP dep ON acct.DEPARTMENT_ID = dep.DEPARTMENT_ID
LEFT JOIN CLARITY_EAP proc ON tx.PROC_ID = proc.PROC_ID
WHERE tx.TX_TYPE_C = 1 -- Charge Transaction Type
UNION ALL
-- 3. Claim Generated
SELECT
claim.HSP_ACCOUNT_ID AS BillingEvent,
'Claim Generated' AS ActivityName,
claim.GENERATED_TIME AS EventTimestamp,
NULL AS ResponsibleUser, -- Often a system process
dep.DEPARTMENT_NAME AS BillingDepartment,
NULL AS DenialReasonCode,
NULL AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
NULL AS ServiceType
FROM CLP_CLAIM_INFO claim
INNER JOIN BaseAccounts ba ON claim.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
LEFT JOIN HSP_ACCOUNT acct ON claim.HSP_ACCOUNT_ID = acct.HSP_ACCOUNT_ID
LEFT JOIN CLARITY_DEP dep ON acct.DEPARTMENT_ID = dep.DEPARTMENT_ID
WHERE claim.GENERATED_TIME IS NOT NULL
UNION ALL
-- 4. Claim Submitted to Payer
SELECT
claim.HSP_ACCOUNT_ID AS BillingEvent,
'Claim Submitted to Payer' AS ActivityName,
claim.XMIT_DATE AS EventTimestamp,
NULL AS ResponsibleUser, -- Often a system process
dep.DEPARTMENT_NAME AS BillingDepartment,
NULL AS DenialReasonCode,
NULL AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
NULL AS ServiceType
FROM CLP_CLAIM_INFO claim
INNER JOIN BaseAccounts ba ON claim.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
LEFT JOIN HSP_ACCOUNT acct ON claim.HSP_ACCOUNT_ID = acct.HSP_ACCOUNT_ID
LEFT JOIN CLARITY_DEP dep ON acct.DEPARTMENT_ID = dep.DEPARTMENT_ID
WHERE claim.XMIT_DATE IS NOT NULL
UNION ALL
-- 5. Claim Denied by Payer
SELECT
tx.HSP_ACCOUNT_ID AS BillingEvent,
'Claim Denied by Payer' AS ActivityName,
tx.POST_DATE AS EventTimestamp,
emp.USER_ID AS ResponsibleUser,
dep.DEPARTMENT_NAME AS BillingDepartment,
remit.REMIT_CODE_ID AS DenialReasonCode,
NULL AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
NULL AS ServiceType
FROM HSP_TRANSACTIONS tx
INNER JOIN BaseAccounts ba ON tx.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
LEFT JOIN HSP_ACCOUNT acct ON tx.HSP_ACCOUNT_ID = acct.HSP_ACCOUNT_ID
LEFT JOIN CLARITY_EMP emp ON tx.POSTING_USER_ID = emp.USER_ID
LEFT JOIN CLARITY_DEP dep ON acct.DEPARTMENT_ID = dep.DEPARTMENT_ID
LEFT JOIN F_ARHB_TX_SET_POST_HX remit ON tx.TX_ID = remit.TX_ID
WHERE tx.TX_TYPE_C IN ([Your Denial Tx Type]) -- Placeholder for denial transaction type codes
UNION ALL
-- 6. Denial Follow-Up Initiated (assumes status change on account)
SELECT
hist.HSP_ACCOUNT_ID AS BillingEvent,
'Denial Follow-Up Initiated' AS ActivityName,
hist.CHANGE_AUDIT_DTTM AS EventTimestamp,
emp.USER_ID AS ResponsibleUser,
NULL AS BillingDepartment,
NULL AS DenialReasonCode,
NULL AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
NULL AS ServiceType
FROM HSP_ACCT_STATUS_HX hist
INNER JOIN BaseAccounts ba ON hist.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
LEFT JOIN HSP_ACCOUNT acct ON hist.HSP_ACCOUNT_ID = acct.HSP_ACCOUNT_ID
LEFT JOIN CLARITY_EMP emp ON hist.CHANGE_AUDIT_USER_ID = emp.USER_ID
WHERE hist.ACCOUNT_STATUS_C = [Your Denial Followup Status Code] -- Placeholder for a status indicating follow-up
UNION ALL
-- 7. Claim Resubmitted
SELECT
claim.HSP_ACCOUNT_ID AS BillingEvent,
'Claim Resubmitted' AS ActivityName,
claim.RESUBMIT_DATE AS EventTimestamp,
emp.USER_ID AS ResponsibleUser,
dep.DEPARTMENT_NAME AS BillingDepartment,
NULL AS DenialReasonCode,
NULL AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
NULL AS ServiceType
FROM CLP_CLAIM_INFO claim
INNER JOIN BaseAccounts ba ON claim.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
LEFT JOIN HSP_ACCOUNT acct ON claim.HSP_ACCOUNT_ID = acct.HSP_ACCOUNT_ID
LEFT JOIN CLARITY_DEP dep ON acct.DEPARTMENT_ID = dep.DEPARTMENT_ID
LEFT JOIN CLARITY_EMP emp ON claim.RESUBMIT_USER_ID = emp.USER_ID
WHERE claim.RESUBMIT_DATE IS NOT NULL
UNION ALL
-- 8. Payment Received & 9. Payment Posted to Account (combined for this query)
SELECT
tx.HSP_ACCOUNT_ID AS BillingEvent,
'Payment Posted to Account' AS ActivityName,
tx.POST_DATE AS EventTimestamp,
emp.USER_ID AS ResponsibleUser,
dep.DEPARTMENT_NAME AS BillingDepartment,
NULL AS DenialReasonCode,
NULL AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
NULL AS ServiceType
FROM HSP_TRANSACTIONS tx
INNER JOIN BaseAccounts ba ON tx.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
LEFT JOIN HSP_ACCOUNT acct ON tx.HSP_ACCOUNT_ID = acct.HSP_ACCOUNT_ID
LEFT JOIN CLARITY_EMP emp ON tx.POSTING_USER_ID = emp.USER_ID
LEFT JOIN CLARITY_DEP dep ON acct.DEPARTMENT_ID = dep.DEPARTMENT_ID
WHERE tx.TX_TYPE_C IN ([Your Payer Payment Tx Type], [Your Patient Payment Tx Type]) -- Placeholder for payment transaction types
UNION ALL
-- 10. Account Adjustment Made
SELECT
tx.HSP_ACCOUNT_ID AS BillingEvent,
'Account Adjustment Made' AS ActivityName,
tx.POST_DATE AS EventTimestamp,
emp.USER_ID AS ResponsibleUser,
dep.DEPARTMENT_NAME AS BillingDepartment,
NULL AS DenialReasonCode,
zcar.NAME AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
NULL AS ServiceType
FROM HSP_TRANSACTIONS tx
INNER JOIN BaseAccounts ba ON tx.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
LEFT JOIN HSP_ACCOUNT acct ON tx.HSP_ACCOUNT_ID = acct.HSP_ACCOUNT_ID
LEFT JOIN CLARITY_EMP emp ON tx.POSTING_USER_ID = emp.USER_ID
LEFT JOIN CLARITY_DEP dep ON acct.DEPARTMENT_ID = dep.DEPARTMENT_ID
LEFT JOIN ZC_ADJ_REASON zcar ON tx.ADJ_REASON_C = zcar.ADJ_REASON_C
WHERE tx.TX_TYPE_C IN ([Your Adjustment Tx Type]) -- Placeholder for adjustment transaction types
UNION ALL
-- 11. Balance Sent to Collections
SELECT
acct.HSP_ACCOUNT_ID AS BillingEvent,
'Balance Sent to Collections' AS ActivityName,
hist.CHANGE_AUDIT_DTTM AS EventTimestamp,
emp.USER_ID AS ResponsibleUser,
dep.DEPARTMENT_NAME AS BillingDepartment,
NULL AS DenialReasonCode,
NULL AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
NULL AS ServiceType
FROM HSP_ACCOUNT acct
INNER JOIN BaseAccounts ba ON acct.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
INNER JOIN HSP_ACCT_STATUS_HX hist ON acct.HSP_ACCOUNT_ID = hist.HSP_ACCOUNT_ID AND hist.ACCOUNT_STATUS_C = [Your Collections Status Code]
LEFT JOIN CLARITY_DEP dep ON acct.DEPARTMENT_ID = dep.DEPARTMENT_ID
LEFT JOIN CLARITY_EMP emp ON hist.CHANGE_AUDIT_USER_ID = emp.USER_ID
WHERE acct.ACCOUNT_STATUS_C = [Your Collections Status Code] -- Placeholder for collections status
UNION ALL
-- 12. Account Closed
SELECT
acct.HSP_ACCOUNT_ID AS BillingEvent,
'Account Closed' AS ActivityName,
acct.CLOSED_DATE AS EventTimestamp,
NULL AS ResponsibleUser, -- System or Final transaction user
dep.DEPARTMENT_NAME AS BillingDepartment,
NULL AS DenialReasonCode,
NULL AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
NULL AS ServiceType
FROM HSP_ACCOUNT acct
INNER JOIN BaseAccounts ba ON acct.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
LEFT JOIN CLARITY_DEP dep ON acct.DEPARTMENT_ID = dep.DEPARTMENT_ID
WHERE acct.ACCT_FIN_BALANCE = 0
AND acct.CLOSED_DATE IS NOT NULL
AND acct.CLOSED_DATE BETWEEN @StartDate and @EndDate
ORDER BY
BillingEvent,
EventTimestamp; ขั้นตอน
- ยืนยันว่ามีสิทธิ์เข้าถึงชุดข้อมูลรายได้ของ Epic Clarity ที่ได้รับอนุญาต รวมถึงตารางและวิวต้นทางที่จำเป็นสำหรับประวัติบัญชี ค่าบริการ เคลม การปฏิเสธเคลม การชำระเงิน การปรับยอด การติดตามหนี้ และการปิดบัญชี องค์กรที่ใช้ Epic อาจมีตารางและชื่อคอลัมน์แตกต่างกัน ให้จับคู่ตัวอย่างแต่ละรายการในคิวรีกับออบเจ็กต์ Clarity ที่เกี่ยวข้องในสภาพแวดล้อมของคุณ
- กำหนดช่วงเวลาที่ต้องการดึงข้อมูลด้วย
[Start date parameter]และ[End date parameter]เริ่มต้นด้วยช่วงสามถึงหกเดือน และขยายช่วงหลังจากตรวจสอบประสิทธิภาพคิวรีและความครบถ้วนของเหตุการณ์แล้วเท่านั้น - กำหนดการจับคู่
BillingEventคิวรีใช้HSP_ACCOUNT.HSP_ACCOUNT_IDเป็นรหัสเคสเริ่มต้นเมื่อมีข้อมูล หากองค์กรกำหนดเหตุการณ์การเรียกเก็บเงินในระดับค่าบริการ เคลม หรือเคส ให้เปลี่ยนการจับคู่เป็นตัวระบุที่ได้รับอนุมัติ และใช้ตัวระบุนั้นอย่างสอดคล้องกันในทุกแหล่งกิจกรรม - จับคู่แต่ละกิจกรรมกับเวลาประทับและคุณลักษณะต้นทางที่เชื่อถือได้ กิจกรรม Service Rendered ควรใช้เวลาประทับการให้บริการหรือการเสร็จสิ้นเคสที่มีเอกสารกำกับ กิจกรรม Charges Captured ควรใช้เวลาประทับการบันทึกค่าบริการ กิจกรรม Claim Generated และ Claim Submitted to Payer ควรใช้เวลาประทับตามวงจรชีวิตของเคลม กิจกรรมการปฏิเสธเคลม การติดตาม การส่งเคลมซ้ำ การชำระเงิน การปรับยอด การติดตามหนี้ และการปิดบัญชี ต้องใช้เวลาประทับธุรกรรมหรือสถานะที่มีเอกสารกำกับ
- แทนตัวอย่างแหล่งข้อมูลในวงเล็บเหลี่ยมทั้งหมดในคิวรี ได้แก่
[Your service source table],[Your charge source table],[Your claim source table],[Your denial source table],[Your follow-up source table],[Your payment source table],[Your adjustment source table],[Your collections source table]และ[Your account closure source table]อย่าใช้รหัสธุรกรรมที่ไม่มีเอกสารอ้างอิง ให้ใช้ค่าธุรกรรมหรือสถานะที่ทีมรายงาน Epic อนุมัติ - เรียกใช้คิวรีในไคลเอนต์ SQL หรือแพลตฟอร์มรายงานที่องค์กรอนุมัติ ตรวจสอบว่ามีแถวของกิจกรรมทั้ง 12 รายการอย่างชัดเจน ProcessMind จะไม่อนุมานเหตุการณ์ในวงจรชีวิตที่ขาดหายจากยอดคงเหลือ สถานะ หรือลำดับเหตุการณ์
- ตรวจสอบโครงสร้างผลลัพธ์ โดยต้องมี
BillingEvent,ActivityName,EventTimestamp,ResponsibleUser,BillingDepartment,DenialReasonCode,AdjustmentReason,OutstandingBalanceและServiceTypeเก็บเวลาประทับพร้อมข้อมูลเขตเวลาหรือเวลาท้องถิ่น และเก็บตัวระบุต้นทางไว้ในข้อมูลตรวจสอบภายในหากได้รับอนุญาต - ตรวจสอบลำดับเวลาภายในแต่ละ
BillingEventการเกิดข้อมูลซ้ำ อัตราค่า null จำนวนกิจกรรม และการกระทบยอดกับรายงานจากระบบต้นทาง ตรวจสอบเหตุการณ์นอกช่วงเวลาที่ร้องขอ ซึ่งจำเป็นต่อการทำความเข้าใจเคสที่เริ่มก่อนหรือสิ้นสุดหลังช่วงดังกล่าว - ส่งออกผลลัพธ์เป็นไฟล์ที่คั่นด้วยตัวคั่นหรือการเชื่อมต่อฐานข้อมูลที่ ProcessMind รองรับ ให้หนึ่งแถวแทนหนึ่งเหตุการณ์ ใช้ชื่อคอลัมน์ที่คงที่ รูปแบบเวลาประทับที่สอดคล้องกัน การเข้ารหัส UTF-8 และไม่มีเซลล์ผสานหรือยอดรวมเพื่อการนำเสนอ ขณะอัปโหลด ให้กำหนด
BillingEventเป็นรหัสเคสActivityNameเป็นกิจกรรม และEventTimestampเป็นเวลาของเหตุการณ์.
การกำหนดค่า
- การจับคู่แหล่งข้อมูล: การติดตั้ง Epic Clarity แต่ละแห่งอาจแตกต่างกัน แทนตัวอย่างออบเจ็กต์ต้นทางและคอลัมน์ในวงเล็บเหลี่ยมด้วยตาราง วิว หรือชั้นรายงานที่ได้รับอนุมัติและมีเอกสารระบุในสภาพแวดล้อมของคุณ อย่าสันนิษฐานว่ามีตารางหรือฟิลด์นั้น เพียงเพราะพบได้ทั่วไปในการติดตั้ง Epic แห่งอื่น
- รหัสเคส: คิวรีเริ่มต้นใช้
HSP_ACCOUNT.HSP_ACCOUNT_IDในการจับคู่ ยืนยันว่าองค์กรกำหนดBillingEventเป็นบัญชี เคส เคลม ค่าบริการ หรือคีย์ธุรกิจอื่นที่ได้รับอนุมัติ - ช่วงวันที่: เริ่มต้นด้วยข้อมูลสามถึงหกเดือน เพิ่มช่วงย้อนหลังเมื่อเคสอาจเริ่มก่อนช่วงรายงาน และเพิ่มช่วงติดตามผลเมื่อเคลม การปฏิเสธเคลม การชำระเงิน หรือการปิดบัญชีอาจเกิดขึ้นหลังวันที่ให้บริการ
- เวลาประทับของกิจกรรม: กำหนดเวลาประทับที่เชื่อถือได้หนึ่งค่าต่อกิจกรรม อย่าใช้เวลาแยกข้อมูล เวลาโหลดไฟล์ หรือเวลาสถานะปัจจุบันแทนเวลาที่เกิดเหตุการณ์ทางธุรกิจจริง เว้นแต่จะมีเอกสารระบุว่าเป็นเวลาของเหตุการณ์จากระบบต้นทาง
- ตัวกรอง: ใช้ตัวกรอง
[Company Code filter],[Document Type filter],[Department filter], ผู้จ่ายเงิน พื้นที่ให้บริการ และประเภทบัญชี เฉพาะเมื่อมีเอกสารกำกับคำจำกัดความและจำเป็นต่อการวิเคราะห์ ใช้ตัวกรองให้สอดคล้องกันในทุกส่วนUNION ALL - การจับคู่ธุรกรรมและสถานะ: กำหนดค่าที่องค์กรอนุมัติสำหรับการบันทึกค่าบริการ การสร้างเคลม การส่งเคลม การปฏิเสธเคลม การติดตาม การส่งเคลมซ้ำ การรับชำระเงิน การบันทึกการชำระเงิน การปรับยอด การติดตามหนี้ และการปิดบัญชี คิวรีจงใจใช้ตัวอย่างค่า เนื่องจากค่าธุรกรรมและโครงสร้างแหล่งข้อมูลของ Epic แตกต่างกันในแต่ละการติดตั้ง
- การจัดการค่า null: คงค่า NULL ไว้สำหรับคุณลักษณะที่ไม่เกี่ยวข้องกับกิจกรรม อย่าแทนเหตุผลการปฏิเสธเคลม เหตุผลการปรับยอด ผู้ใช้ แผนก หรือประเภทบริการที่ขาดหายด้วยค่าที่สร้างขึ้นเอง
- ประสิทธิภาพ: จำกัดแถวต้นทางด้วยคอลัมน์วันที่ที่มีดัชนีและตัวกรององค์กรที่ได้รับอนุมัติก่อนเชื่อมกับ
HSP_ACCOUNTหลีกเลี่ยงการใช้ฟังก์ชันกับคอลัมน์เวลาประทับที่มีดัชนีในเงื่อนไขกรอง หากข้อมูลประวัติมีปริมาณมาก ให้พิจารณาสร้างวิวรายงานที่ได้รับอนุมัติสำหรับแต่ละกิจกรรมต้นทาง - การกำจัดข้อมูลซ้ำ: อย่าลบเหตุการณ์ที่ซ้ำกันหากไม่มีหลักเกณฑ์ที่มีเอกสารกำกับ การชำระเงิน การปรับยอด การส่งเคลม หรือการเปลี่ยนสถานะหลายครั้งอาจเป็นเหตุการณ์ที่ถูกต้องสำหรับ
BillingEventเดียวกัน - ข้อกำหนดเบื้องต้น: สิทธิ์ที่จำเป็นอาจรวมถึงสิทธิ์รายงาน Epic Clarity การเข้าถึงข้อมูลวงจรรายได้และประวัติบัญชี สภาพแวดล้อมเรียกใช้ SQL ที่ได้รับอนุมัติ และการอนุมัติจากองค์กรสำหรับข้อมูลสุขภาพที่ได้รับการคุ้มครอง การเข้าถึงประวัติเคลม รายการชำระเงิน คิวงาน การติดตามหนี้ และการปิดบัญชี ขึ้นอยู่กับโมดูลและการเชื่อมต่อ Epic ที่ได้รับไลเซนส์และติดตั้งไว้.
ตัวอย่างคำค้น sql
WITH
service_rendered AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Service Rendered' AS ActivityName,
CAST(s.[Service rendered timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(s.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(s.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(NULL AS VARCHAR(100)) AS DenialReasonCode,
CAST(NULL AS VARCHAR(100)) AS AdjustmentReason,
CAST(s.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(s.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN [Your service source table] s
ON s.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE s.[Service rendered timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND s.[Service rendered timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND [Your company code filter]
),
charges_captured AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Charges Captured' AS ActivityName,
CAST(t.[Charge captured timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(t.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(t.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(NULL AS VARCHAR(100)) AS DenialReasonCode,
CAST(NULL AS VARCHAR(100)) AS AdjustmentReason,
CAST(t.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(t.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN AR_PB_TRANSACTIONS t
ON t.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE t.[Charge captured timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND t.[Charge captured timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND t.[Charge transaction filter]
AND [Your company code filter]
),
claim_generated AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Claim Generated' AS ActivityName,
CAST(c.[Claim generated timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(c.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(c.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(NULL AS VARCHAR(100)) AS DenialReasonCode,
CAST(NULL AS VARCHAR(100)) AS AdjustmentReason,
CAST(c.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(c.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN [Your claim source table] c
ON c.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE c.[Claim generated timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND c.[Claim generated timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND c.[Claim generated status filter]
AND [Your company code filter]
),
claim_submitted AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Claim Submitted to Payer' AS ActivityName,
CAST(c.[Claim submitted timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(c.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(c.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(NULL AS VARCHAR(100)) AS DenialReasonCode,
CAST(NULL AS VARCHAR(100)) AS AdjustmentReason,
CAST(c.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(c.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN [Your claim source table] c
ON c.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE c.[Claim submitted timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND c.[Claim submitted timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND c.[Claim submitted status filter]
AND [Your company code filter]
),
claim_denied AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Claim Denied by Payer' AS ActivityName,
CAST(d.[Denial timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(d.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(d.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(d.[Denial reason code column] AS VARCHAR(100)) AS DenialReasonCode,
CAST(NULL AS VARCHAR(100)) AS AdjustmentReason,
CAST(d.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(d.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN [Your denial source table] d
ON d.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE d.[Denial timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND d.[Denial timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND d.[Denial status filter]
AND [Your company code filter]
),
denial_follow_up AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Denial Follow-Up Initiated' AS ActivityName,
CAST(f.[Follow-up timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(f.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(f.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(f.[Denial reason code column] AS VARCHAR(100)) AS DenialReasonCode,
CAST(NULL AS VARCHAR(100)) AS AdjustmentReason,
CAST(f.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(f.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN [Your follow-up source table] f
ON f.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE f.[Follow-up timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND f.[Follow-up timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND f.[Follow-up status filter]
AND [Your company code filter]
),
claim_resubmitted AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Claim Resubmitted' AS ActivityName,
CAST(c.[Claim resubmitted timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(c.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(c.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(NULL AS VARCHAR(100)) AS DenialReasonCode,
CAST(NULL AS VARCHAR(100)) AS AdjustmentReason,
CAST(c.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(c.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN [Your claim source table] c
ON c.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE c.[Claim resubmitted timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND c.[Claim resubmitted timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND c.[Claim resubmitted status filter]
AND [Your company code filter]
),
payment_received AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Payment Received' AS ActivityName,
CAST(p.[Payment received timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(p.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(p.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(NULL AS VARCHAR(100)) AS DenialReasonCode,
CAST(NULL AS VARCHAR(100)) AS AdjustmentReason,
CAST(p.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(p.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN [Your payment source table] p
ON p.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE p.[Payment received timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND p.[Payment received timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND p.[Payment received status filter]
AND [Your company code filter]
),
payment_posted AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Payment Posted to Account' AS ActivityName,
CAST(p.[Payment posted timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(p.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(p.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(NULL AS VARCHAR(100)) AS DenialReasonCode,
CAST(NULL AS VARCHAR(100)) AS AdjustmentReason,
CAST(p.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(p.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN [Your payment source table] p
ON p.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE p.[Payment posted timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND p.[Payment posted timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND p.[Payment posted status filter]
AND [Your company code filter]
),
account_adjustment AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Account Adjustment Made' AS ActivityName,
CAST(x.[Adjustment timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(x.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(x.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(NULL AS VARCHAR(100)) AS DenialReasonCode,
CAST(x.[Adjustment reason column] AS VARCHAR(100)) AS AdjustmentReason,
CAST(x.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(x.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN [Your adjustment source table] x
ON x.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE x.[Adjustment timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND x.[Adjustment timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND x.[Adjustment transaction filter]
AND [Your company code filter]
),
balance_collections AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Balance Sent to Collections' AS ActivityName,
CAST(k.[Collections timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(k.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(k.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(NULL AS VARCHAR(100)) AS DenialReasonCode,
CAST(NULL AS VARCHAR(100)) AS AdjustmentReason,
CAST(k.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(k.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN [Your collections source table] k
ON k.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE k.[Collections timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND k.[Collections timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND k.[Collections status filter]
AND [Your company code filter]
),
account_closed AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Account Closed' AS ActivityName,
CAST(z.[Account closed timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(z.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(z.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(NULL AS VARCHAR(100)) AS DenialReasonCode,
CAST(NULL AS VARCHAR(100)) AS AdjustmentReason,
CAST(z.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(z.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN [Your account closure source table] z
ON z.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE z.[Account closed timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND z.[Account closed timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND z.[Account closed status filter]
AND [Your company code filter]
)
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM service_rendered
UNION ALL
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM charges_captured
UNION ALL
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM claim_generated
UNION ALL
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM claim_submitted
UNION ALL
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM claim_denied
UNION ALL
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM denial_follow_up
UNION ALL
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM claim_resubmitted
UNION ALL
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM payment_received
UNION ALL
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM payment_posted
UNION ALL
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM account_adjustment
UNION ALL
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM balance_collections
UNION ALL
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM account_closed
ORDER BY BillingEvent, EventTimestamp, ActivityName; พร้อมเริ่มต้นหรือยัง?
ใช้ข้อมูลที่แม่นยำเพื่อเพิ่มประสิทธิภาพกระบวนการจัดการวงจรรายได้ของคุณ เริ่มปรับปรุงประสิทธิภาพและผลการดำเนินงานทางการเงินได้วันนี้.
เพิ่มประสิทธิภาพสูงสุด ปรับปรุงการจัดการวงจรรายได้ได้ทันที
ค้นหาจุดที่ RCM ใน Epic Resolute ไม่มีประสิทธิภาพ และลดระยะเวลาของวงจรลง 30%.
ไม่ต้องใช้บัตรเครดิต เริ่มปรับปรุงกระบวนการได้วันนี้.