Mẫu dữ liệu quản lý chu kỳ doanh thu
Mẫu dữ liệu quản lý chu kỳ doanh thu
- Các thuộc tính nên thu thập
- Hoạt động chính cần theo dõi để khám phá quy trình
- Hướng dẫn chi tiết cách trích xuất dữ liệu từ R1 RCM
Thuộc tính quản lý chu kỳ doanh thu
| Tên | Mô tả | ||
|---|---|---|---|
| Sự kiện lập hóa đơn BillingEvent | Mã định danh duy nhất cho một dịch vụ hoặc hạng mục tính phí, dùng làm mã hồ sơ chính để theo dõi toàn bộ chu kỳ doanh thu. | ||
| Mô tả Mã sự kiện lập hóa đơn đại diện cho một lần cung cấp dịch vụ hoặc sản phẩm phát sinh khoản phí. Mã này liên kết mọi hoạt động liên quan, từ lúc cung cấp dịch vụ và ghi nhận khoản phí, đến khi gửi hồ sơ yêu cầu thanh toán, ghi nhận khoản thanh toán và cuối cùng là đóng tài khoản. Trong process mining, phân tích vòng đời của từng sự kiện lập hóa đơn giúp bạn nắm được toàn bộ chu kỳ doanh thu. Bạn có thể theo dõi hành trình của một khoản phí, tìm các luồng xử lý phổ biến, đo thời gian giữa những mốc quan trọng và hiểu những khác biệt dẫn đến chậm trễ hoặc thất thoát doanh thu. Vì sao điều này quan trọng Mã định danh này giúp nhóm mọi hoạt động liên quan vào cùng một hồ sơ, từ đó phân tích đầy đủ và chính xác chu kỳ doanh thu của từng sự kiện tính phí. Lấy dữ liệu ở đâu Đây là khóa chính liên kết các bảng về lượt khám, khoản phí, hồ sơ yêu cầu thanh toán và khoản thanh toán. Hãy tham khảo tài liệu R1 RCM để xác định trường cụ thể, thường liên quan đến mã lượt khám hoặc mã hồ sơ yêu cầu. Ví dụ BE-2023-0012345BE-2023-0054321BE-2024-0098765 | |||
| Tên hoạt động ActivityName | Tên của sự kiện nghiệp vụ hoặc tác vụ cụ thể diễn ra tại một thời điểm trong chu kỳ doanh thu. | ||
| Mô tả Thuộc tính này mô tả một bước hoặc mốc trong quy trình quản lý chu kỳ doanh thu của một sự kiện lập hóa đơn. Hoạt động thể hiện công việc đang được thực hiện, chẳng hạn như “Đã ghi nhận khoản phí”, “Đã gửi hồ sơ yêu cầu” hoặc “Đã ghi sổ khoản thanh toán”. Phân tích trình tự hoạt động là trọng tâm của process mining. Qua đó, bạn có thể khám phá luồng quy trình thực tế, tìm điểm nghẽn khiến hoạt động mất nhiều thời gian mới bắt đầu và phát hiện các vòng lặp làm lại không cần thiết, chẳng hạn như “Hồ sơ yêu cầu bị từ chối” rồi đến “Bắt đầu xử lý lại hồ sơ bị từ chối”. Vì sao điều này quan trọng Thuộc tính này xác định các bước trong quy trình, giúp trực quan hóa sơ đồ quy trình, tính thời gian chuyển tiếp và phát hiện sai lệch cũng như công việc phải làm lại. Lấy dữ liệu ở đâu Thông tin này thường được lấy từ nhật ký sự kiện, bản ghi thay đổi trạng thái hoặc mã giao dịch trong các mô-đun R1 RCM. Có thể cần ánh xạ mã kỹ thuật sang tên dễ hiểu với người dùng nghiệp vụ. Ví dụ Đã ghi nhận khoản phíĐã gửi yêu cầu thanh toánĐã nhận kết quả xét duyệt từ bên thanh toánĐã ghi nhận thanh toánĐã đóng tài khoản | |||
| Thời điểm sự kiện EventTime | Dấu thời gian cho biết thời điểm một hoạt động hoặc sự kiện cụ thể diễn ra. | ||
| Mô tả Thời điểm sự kiện cho biết chính xác ngày giờ một hoạt động được ghi nhận trong hệ thống. Đây là dữ liệu thời gian nền tảng để phân tích quy trình. Trong process mining, dấu thời gian giúp sắp xếp sự kiện theo trình tự thời gian và tính khoảng thời gian giữa các hoạt động, yếu tố quan trọng để phân tích hiệu suất. Bạn có thể tính các chỉ số như thời gian chu kỳ, thời gian xử lý và thời gian chờ. Những chỉ số này giúp tìm điểm nghẽn và đo lường hiệu quả. Vì sao điều này quan trọng Dấu thời gian này là cơ sở cho mọi phân tích liên quan đến thời gian, từ tính thời gian chu kỳ và tìm điểm nghẽn đến theo dõi hiệu suất quy trình so với SLA. Lấy dữ liệu ở đâu Trong R1 RCM, trường này thường có tên “Creation Date”, “Timestamp” hoặc “Last Update Date” và gắn với từng giao dịch hoặc bản ghi thay đổi trạng thái. Ví dụ 2023-10-26T10:00:00Z2023-10-27T14:35:10Z2023-11-05T09:12:45Z | |||
| Hệ thống nguồn SourceSystem | Hệ thống lưu trữ dữ liệu gốc mà từ đó dữ liệu sự kiện được trích xuất. | ||
| Mô tả Thuộc tính này cho biết ứng dụng hoặc mô-đun nguồn đã tạo dữ liệu cho một sự kiện cụ thể. Trong môi trường phức tạp như y tế, dữ liệu có thể đến từ hệ thống EMR, mô-đun lập hóa đơn, đơn vị xử lý hồ sơ yêu cầu hoặc nền tảng thu hồi nợ. Biết hệ thống nguồn rất quan trọng để xác thực dữ liệu và phân tích những khác biệt trong quy trình có thể chỉ xuất hiện ở một số hệ thống. Thông tin này cũng giúp xử lý dữ liệu không nhất quán và hiểu các hệ thống công nghệ tham gia vào quy trình. Vì sao điều này quan trọng Thuộc tính này xác định nguồn gốc dữ liệu, giúp quản trị và xác thực dữ liệu, đồng thời cho biết các hệ thống tương tác với nhau như thế nào trong toàn bộ quy trình. Lấy dữ liệu ở đâu Giá trị này thường được thêm cố định trong quá trình trích xuất dữ liệu để xác định hệ thống nguồn, chẳng hạn như “R1 RCM”. Ví dụ R1 RCMCernerEpic | |||
| Lần cập nhật dữ liệu gần nhất LastDataUpdate | Dấu thời gian của lần làm mới hoặc trích xuất dữ liệu gần nhất từ hệ thống nguồn. | ||
| Mô tả Thuộc tính này cho biết lần gần nhất dữ liệu dùng cho phân tích process mining được cập nhật. Nhờ đó, bạn biết dữ liệu đang phân tích mới đến mức nào. Thông tin này hữu ích khi lập báo cáo và bảng điều khiển vì cho người dùng biết các thông tin về quy trình được cập nhật đến thời điểm nào. Điều này giúp mọi người hiểu rõ độ trễ của dữ liệu và đưa ra quyết định dựa trên khung thời gian đã biết. Vì sao điều này quan trọng Thuộc tính này cho biết dữ liệu mới đến mức nào, giúp nhà phân tích và các bên liên quan biết thông tin về quy trình đã được cập nhật gần đây hay chưa. Lấy dữ liệu ở đâu Dấu thời gian này được tạo trong quá trình trích xuất, chuyển đổi và tải dữ liệu (ETL), thường áp dụng cho toàn bộ tập dữ liệu. Ví dụ 2024-05-20T08:00:00Z2024-05-21T08:00:00Z | |||
| Mã lý do từ chối hồ sơ yêu cầu DenialReasonCode | Mã chuẩn do bên chi trả cung cấp, giải thích lý do từ chối hồ sơ yêu cầu. | ||
| Mô tả Khi từ chối hồ sơ yêu cầu, bên chi trả sẽ cung cấp mã lý do, chẳng hạn như CARC (Claim Adjustment Reason Code), để giải thích quyết định. Các mã này được chuẩn hóa và cho biết vấn đề như “Dịch vụ không được bảo hiểm” hoặc “Hồ sơ yêu cầu trùng lặp”. Thuộc tính này rất quan trọng trong việc xử lý hồ sơ bị từ chối. Bằng cách phân tích tần suất của từng mã lý do, tổ chức có thể tìm và xử lý nguyên nhân gốc rễ, dù vấn đề liên quan đến điều kiện tham gia bảo hiểm của bệnh nhân, lỗi mã hóa hay thiếu căn cứ về tính cần thiết của dịch vụ y tế. Nhờ đó, tổ chức có thể giảm công việc làm lại và đẩy nhanh dòng tiền. Vì sao điều này quan trọng Thuộc tính này cho biết lý do cụ thể khiến hồ sơ yêu cầu bị từ chối, giúp tìm nguyên nhân gốc rễ để giảm số lần từ chối trong tương lai, hạn chế việc làm lại và tăng tỷ lệ được thanh toán ngay lần đầu. Lấy dữ liệu ở đâu Thông tin này được nhận từ bên chi trả qua thông báo thanh toán điện tử (tệp ERA hoặc 835) và lưu trong mô-đun quản lý hồ sơ yêu cầu của R1 RCM. Ví dụ CO-16: Hồ sơ yêu cầu hoặc dịch vụ thiếu thông tin cần thiết để xét duyệt.PR-97: Quyền lợi cho dịch vụ này đã được tính trong khoản thanh toán hoặc mức cho phép của một dịch vụ khác.CO-22: Theo quy định phối hợp quyền lợi, một bên chi trả khác có thể chi trả cho dịch vụ này.OA-18: Hồ sơ yêu cầu hoặc dịch vụ trùng khớp hoàn toàn. | |||
| Người dùng được giao AssignedUser | Mã người dùng hoặc tên nhân viên đã thực hiện hoạt động. | ||
| Mô tả Thuộc tính này xác định người chịu trách nhiệm thực hiện một tác vụ cụ thể trong quy trình. Đó có thể là nhân viên lập hóa đơn tạo hồ sơ yêu cầu, nhà phân tích xử lý lại hồ sơ bị từ chối hoặc chuyên viên ghi sổ khoản thanh toán. Phân tích theo người dùng giúp bạn hiểu cách phân bổ khối lượng công việc, hiệu suất cá nhân và nhu cầu đào tạo. Qua đó, bạn có thể nhận biết người dùng nào làm việc hiệu quả nhất hoặc thường liên quan đến nhiều lỗi hơn, từ đó tập trung quản lý và cải tiến quy trình đúng chỗ. Vì sao điều này quan trọng Thuộc tính này giúp phân tích hiệu suất của nhóm và từng cá nhân, phân bổ khối lượng công việc, đồng thời tìm cơ hội đào tạo hoặc sai lệch quy trình liên quan đến một người dùng cụ thể. Lấy dữ liệu ở đâu Trong nhật ký giao dịch R1 RCM, trường này thường có tên “UserID”, “Processor” hoặc “UpdatedBy”. Ví dụ jdoeasmithp.jonesBOT_RPA01 | |||
| Phòng lập hóa đơn BillingDepartment | Phòng ban hoặc nhóm chức năng chịu trách nhiệm thực hiện hoạt động. | ||
| Mô tả Thuộc tính này cho biết đơn vị trong tổ chức, chẳng hạn như “Nhập khoản phí”, “Gửi hồ sơ yêu cầu” hoặc “Xử lý hồ sơ bị từ chối”, đã thực hiện một bước trong quy trình. Nhờ đó, bạn hiểu công việc được bàn giao giữa các nhóm như thế nào. Thông tin này rất quan trọng để phân tích năng suất của từng phòng ban và tìm điểm nghẽn giữa các nhóm chức năng. Khi lọc sơ đồ quy trình theo phòng ban, tổ chức có thể thấy khâu bàn giao nào diễn ra suôn sẻ và khâu nào bị chậm trễ. Từ đó, tổ chức có thể phân bổ tài nguyên và cải tiến quy trình. Vì sao điều này quan trọng Thuộc tính này giúp phân tích hiệu suất quy trình theo từng đơn vị trong tổ chức, qua đó tìm điểm nghẽn riêng của nhóm, hạn chế về tài nguyên hoặc cách làm hiệu quả. Lấy dữ liệu ở đâu Thông tin này có thể được lấy từ hồ sơ người dùng trong R1 RCM hoặc lưu trong dữ liệu giao dịch dưới dạng “Department Code”. Ví dụ Ghi nhận khoản phíQuản lý yêu cầu thanh toánTừ chối và kháng nghịGhi sổ khoản thanh toán | |||
| Số tiền trên hóa đơn InvoiceAmount | Tổng giá trị các khoản phí trên hóa đơn hoặc hồ sơ yêu cầu thanh toán. | ||
| Mô tả Thuộc tính này thể hiện tổng số tiền đã lập hóa đơn cho các dịch vụ trong một sự kiện lập hóa đơn. Đây là khoản doanh thu dự kiến thu được từ hồ sơ yêu cầu thanh toán. Phân tích số tiền trên hóa đơn rất quan trọng trong process mining tài chính. Bạn có thể ưu tiên các hồ sơ có giá trị cao, hiểu tác động tài chính của việc chậm trễ hoặc từ chối, và phân nhóm quy trình theo giá trị. Chẳng hạn, phân tích có thể cho thấy các hồ sơ vượt một mức tiền nhất định đi theo luồng xử lý khác, cần nhiều thao tác thủ công hơn. Vì sao điều này quan trọng Thuộc tính này bổ sung bối cảnh tài chính cho quy trình, giúp phân tích tác động của các biến thể quy trình đến doanh thu và ưu tiên cải tiến những hồ sơ có giá trị cao. Lấy dữ liệu ở đâu Trong R1 RCM, trường này nằm trong bảng chính của hồ sơ yêu cầu hoặc hóa đơn, thường có tên “TotalBilledAmount” hoặc tương tự. Ví dụ 150.002500.7585.5012000.00 | |||
| Tên bên chi trả PayerName | Tên công ty bảo hiểm, cơ quan nhà nước hoặc bệnh nhân chịu trách nhiệm thanh toán. | ||
| Mô tả Thuộc tính này xác định bên chi trả chính cho hồ sơ yêu cầu. Đó có thể là công ty bảo hiểm thương mại như Aetna, đơn vị chi trả của chính phủ như Medicare hoặc chính bệnh nhân đối với phần tự thanh toán. Phân tích quy trình theo bên chi trả là việc thiết yếu trong quản lý chu kỳ doanh thu. Qua đó, bạn có thể phát hiện bên chi trả nào thường từ chối nhiều hơn, thanh toán lâu hơn hoặc yêu cầu hồ sơ phức tạp hơn. Những thông tin này giúp tổ chức điều chỉnh quy trình và tài nguyên để xử lý hiệu quả các yêu cầu riêng của từng bên chi trả. Vì sao điều này quan trọng Thuộc tính này giúp phân nhóm quy trình theo bên chi trả để tìm chậm trễ, kiểu từ chối hoặc cách thức thanh toán riêng của từng bên, từ đó tối ưu doanh thu. Lấy dữ liệu ở đâu Thông tin này nằm trong dữ liệu bảo hiểm hoặc nhân khẩu học của bệnh nhân, được liên kết với hồ sơ yêu cầu trong R1 RCM. Ví dụ MedicareUnitedHealthcareBlue Cross Blue ShieldAetnaTự thanh toán | |||
| Trạng thái hóa đơn InvoiceStatus | Trạng thái hiện tại của hóa đơn hoặc hồ sơ yêu cầu trong vòng đời xử lý. | ||
| Mô tả Thuộc tính này cho biết trạng thái gần nhất của một sự kiện lập hóa đơn, chẳng hạn như “Đã gửi”, “Đã thanh toán”, “Bị từ chối” hoặc “Đang thu hồi nợ”. Nhờ đó, bạn biết hóa đơn đang ở bước nào trong quy trình tại một thời điểm nhất định. Trạng thái hóa đơn rất quan trọng để lập báo cáo công nợ theo tuổi nợ và theo dõi tình hình các khoản phải thu. Trong process mining, bạn có thể dùng thuộc tính này để lọc những hồ sơ bị mắc ở một trạng thái cụ thể hoặc phân tích kết quả của các biến thể quy trình, chẳng hạn như so sánh luồng xử lý của hồ sơ “Đã thanh toán” và “Bị từ chối”. Vì sao điều này quan trọng Thuộc tính này cho biết trạng thái hiện tại của từng hồ sơ, cần thiết để lập báo cáo tuổi nợ và phân tích kết quả cuối cùng của các luồng quy trình khác nhau. Lấy dữ liệu ở đâu Trong R1 RCM, đây thường là trường trạng thái trên hồ sơ yêu cầu hoặc hồ sơ tài khoản chính. Ví dụ Chờ gửiĐã gửi cho bên chi trảBị từ chốiĐã thanh toán đầy đủĐang trong quy trình thu hồi nợ | |||
| Có phải làm lại IsRework | Cờ được tính toán để xác định hoạt động thuộc vòng lặp làm lại, chẳng hạn như gửi lại hồ sơ yêu cầu đã bị từ chối. | ||
| Mô tả Thuộc tính dạng đúng/sai này thường được tính trong quá trình phân tích process mining. Giá trị là “true” nếu hoạt động lặp lại một bước trước đó hoặc thuộc chuỗi hoạt động cho thấy có lỗi cần sửa, chẳng hạn như bất kỳ hoạt động nào diễn ra sau “Hồ sơ yêu cầu bị từ chối”. Phát hiện công việc làm lại là một trong những khả năng hữu ích nhất của process mining. Thuộc tính này giúp định lượng công sức, thời gian và tài nguyên bị lãng phí trong quy trình. Khi xác định được công việc làm lại, tổ chức có thể tập trung ngăn ngừa những lỗi gây ra tình trạng này, từ đó cải thiện đáng kể hiệu quả. Vì sao điều này quan trọng Thuộc tính này giúp định lượng tần suất và tác động của công việc làm lại, chẳng hạn như hồ sơ yêu cầu bị từ chối, để tập trung phân tích và giảm lãng phí, kém hiệu quả. Lấy dữ liệu ở đâu Đây không phải là trường trong hệ thống nguồn. Công cụ process mining tính thuộc tính này dựa trên trình tự hoạt động, chẳng hạn như phát hiện hoạt động “Đã gửi hồ sơ yêu cầu” xuất hiện nhiều lần trong cùng một hồ sơ. Ví dụ truefalse | |||
| Có tự động hóa IsAutomated | Cờ cho biết hoạt động do hệ thống tự động hay người dùng thực hiện. | ||
| Mô tả Thuộc tính dạng đúng/sai này phân biệt tác vụ do phần mềm tự động hóa thực hiện, chẳng hạn như bot RPA gửi hồ sơ yêu cầu, với tác vụ do nhân viên thực hiện thủ công. Phân tích thuộc tính này giúp hiểu tác động và hiệu quả của các sáng kiến tự động hóa. Bạn có thể so sánh tốc độ, chi phí và tỷ lệ lỗi giữa quy trình tự động và thủ công, từ đó tìm thêm cơ hội tự động hóa và đo lường ROI của các bot hiện có. Vì sao điều này quan trọng Thuộc tính này phân biệt hoạt động do người thực hiện với hoạt động do hệ thống thực hiện, giúp đo lường tác động của tự động hóa đến hiệu quả, chi phí và chất lượng quy trình. Lấy dữ liệu ở đâu Có thể xác định thuộc tính này từ trường “AssignedUser”, trong đó một số mã người dùng được dành riêng cho bot, chẳng hạn như “BOT_RPA01”. Một số hệ thống có trường riêng để đánh dấu giao dịch tự động. Ví dụ truefalse | |||
| Kết quả thu hồi nợ CollectionOutcome | Kết quả cuối cùng của các hoạt động thu hồi khoản dư chưa thanh toán. | ||
| Mô tả Thuộc tính này mô tả kết quả của nỗ lực thu khoản nợ quá hạn. Các kết quả có thể gồm “Đã thanh toán đầy đủ”, “Đã dàn xếp”, “Đã chuyển thành nợ khó đòi” hoặc “Chưa giải quyết”. Theo dõi kết quả thu hồi nợ rất quan trọng để đánh giá hiệu quả của quy trình. Bằng cách phân tích hoạt động nào dẫn đến kết quả nào, tổ chức có thể tối ưu chiến lược thu hồi, tăng tỷ lệ thu hồi và quyết định khi nào nên dừng thu nợ rồi xóa số dư. Thông tin này hỗ trợ bảng điều khiển Hiệu suất hoạt động thu hồi nợ. Vì sao điều này quan trọng Thuộc tính này đo lường hiệu quả của quy trình thu hồi nợ bằng cách theo dõi kết quả xử lý cuối cùng của các tài khoản quá hạn, giúp tối ưu chiến lược thu hồi. Lấy dữ liệu ở đâu Thông tin này có thể nằm trong trường trạng thái của tài khoản bệnh nhân hoặc trong mô-đun thu hồi nợ riêng của R1 RCM. Ví dụ Đã thanh toán đầy đủĐã dàn xếp với số tiền thấp hơnĐã chuyển cho đơn vị thu hồi nợ bên ngoàiĐã xóa thành nợ khó đòi | |||
| Lý do điều chỉnh AdjustmentReason | Lý do điều chỉnh tài chính, chẳng hạn như “Khoản giảm trừ theo hợp đồng” hoặc “Xóa nợ khó đòi”. | ||
| Mô tả Thuộc tính này cho biết lý do điều chỉnh tài chính trên tài khoản. Lý do thường được thể hiện bằng mã chuẩn hóa hoặc mô tả phân loại loại điều chỉnh. Phân tích lý do điều chỉnh giúp tìm nguyên nhân gốc rễ gây thất thoát doanh thu. Ví dụ, nếu thường xuyên xóa các khoản dư nhỏ, quy trình thu hồi nợ đối với khoản tiền nhỏ có thể chưa hiệu quả. Trong khi đó, các khoản giảm trừ theo hợp đồng thường xuyên là điều đã dự kiến trong quá trình đàm phán với bên chi trả. Phân tích này hỗ trợ bảng điều khiển Kiểm toán điều chỉnh hóa đơn và tuân thủ. Vì sao điều này quan trọng Thuộc tính này giải thích lý do điều chỉnh doanh thu, giúp tìm nguyên nhân gốc rễ gây thất thoát như vấn đề hợp đồng, lỗi lập hóa đơn hoặc thu hồi nợ không thành công. Lấy dữ liệu ở đâu Trong R1 RCM, đây thường là trường mã hoặc văn bản nằm trong cùng bản ghi giao dịch với AdjustmentAmount. Ví dụ Khoản giảm trừ theo hợp đồngXóa nợ khó đòiXóa khoản dư nhỏĐiều chỉnh lỗi lập hóa đơn | |||
| Mã bệnh nhân PatientId | Mã định danh duy nhất của bệnh nhân đã sử dụng dịch vụ. | ||
| Mô tả Thuộc tính này là mã định danh duy nhất được cấp cho bệnh nhân trong hệ thống y tế, thường gọi là mã hồ sơ bệnh án (MRN). Dù phân tích không tập trung vào việc chăm sóc từng bệnh nhân, bạn vẫn có thể dùng mã bệnh nhân để tìm các vấn đề lập hóa đơn lặp lại theo thời gian. Nếu liên kết với dữ liệu bệnh nhân khác, mã này cũng giúp phân nhóm quy trình theo nhân khẩu học hoặc tiền sử bệnh nhân, từ đó có thể phát hiện vấn đề mang tính hệ thống ảnh hưởng đến một số nhóm nhất định. Vì sao điều này quan trọng Thuộc tính này giúp phân tích các sự kiện lập hóa đơn theo từng bệnh nhân, qua đó tìm vấn đề hoặc xu hướng lặp lại qua nhiều lượt khám. Lấy dữ liệu ở đâu Mã định danh này là phần cốt lõi trong dữ liệu nhân khẩu học của bệnh nhân, được liên kết với mọi lượt khám và hồ sơ yêu cầu trong R1 RCM. Ví dụ MRN837262MRN937281MRN103847 | |||
| Mã dịch vụ ServiceCode | Mã lập hóa đơn cho dịch vụ hoặc thủ thuật cụ thể đã cung cấp, chẳng hạn như mã CPT hoặc HCPCS. | ||
| Mô tả Mã dịch vụ, chẳng hạn như mã CPT (Current Procedural Terminology), là mã y tế chuẩn dùng để báo cáo các thủ thuật và dịch vụ y tế, phẫu thuật, chẩn đoán cho bên chi trả để được hoàn trả chi phí. Phân tích quy trình theo mã dịch vụ giúp tìm vấn đề lập hóa đơn liên quan đến từng loại hình chăm sóc. Bạn có thể biết thủ thuật nào thường bị từ chối, có thời gian thanh toán lâu nhất hoặc cần làm lại nhiều nhất, từ đó tập trung cải tiến cách mã hóa và lập hóa đơn. Vì sao điều này quan trọng Thuộc tính này giúp phân tích quy trình theo loại dịch vụ đã cung cấp, qua đó tìm kiểu từ chối hoặc chậm trễ thanh toán liên quan đến từng thủ thuật. Lấy dữ liệu ở đâu Trong R1 RCM, thông tin này nằm ở cấp dòng chi tiết của từng khoản phí hoặc hồ sơ yêu cầu. Ví dụ 992139928573560 | |||
| Số tiền điều chỉnh AdjustmentAmount | Giá trị tiền tệ của khoản điều chỉnh số dư tài khoản. | ||
| Mô tả Thuộc tính này ghi nhận giá trị của mọi khoản điều chỉnh tài chính trên tài khoản bệnh nhân sau lần lập hóa đơn đầu tiên. Khoản điều chỉnh có thể tăng hoặc giảm, bao gồm khoản giảm trừ theo hợp đồng, khoản xóa nợ hoặc khoản sửa sai. Theo dõi số tiền điều chỉnh rất quan trọng để hiểu tính chính xác của doanh thu. Nhiều khoản điều chỉnh âm có thể cho thấy doanh thu bị thất thoát do ghi nhận khoản phí sai hoặc nợ không thể thu hồi. Phân tích dữ liệu này giúp xác định tác động tài chính của lỗi lập hóa đơn và việc thu hồi nợ kém hiệu quả. Vì sao điều này quan trọng Thuộc tính này định lượng doanh thu thất thoát và các khoản điều chỉnh tài chính, giúp xác định tác động bằng tiền của sai sót lập hóa đơn, nghĩa vụ hợp đồng hoặc nợ khó đòi. Lấy dữ liệu ở đâu Trong R1 RCM, thông tin này nằm trong nhật ký giao dịch liên quan đến điều chỉnh tài khoản hoặc ghi sổ khoản thanh toán. Ví dụ -50.2520.00-1200.00 | |||
| Thời gian từ cung cấp dịch vụ đến thanh toán ServiceToPaymentCycleTime | Tổng thời gian được tính từ lúc cung cấp dịch vụ đến khi ghi sổ khoản thanh toán cuối cùng. | ||
| Mô tả Chỉ số này đo tổng thời gian từ đầu đến cuối của chu kỳ doanh thu cho một sự kiện lập hóa đơn. Chỉ số cho biết tổ chức cần bao lâu để chuyển dịch vụ đã cung cấp thành tiền thu được. Đây là chỉ số hiệu suất chính (KPI) quan trọng đối với tình hình tài chính. Phân tích thời gian này giúp tìm những khâu cần đẩy nhanh. Khi chia thời gian chu kỳ thành từng phần, chẳng hạn như “thời gian đến lúc lập hóa đơn” và “thời gian đến lúc thanh toán”, tổ chức có thể xác định cơ hội lớn nhất để cải thiện dòng tiền. Vì sao điều này quan trọng Đây là KPI tổng quan quan trọng, đo lường hiệu quả chung của chu kỳ chuyển đổi thành tiền và tác động trực tiếp đến dòng tiền của tổ chức. Lấy dữ liệu ở đâu Đây là chỉ số được tính toán bằng khoảng thời gian giữa dấu thời gian của hoạt động “Đã cung cấp dịch vụ” và “Đã ghi sổ khoản thanh toán” trong một sự kiện lập hóa đơn. Ví dụ 35 ngày 8 giờ92 ngày 4 giờ15 ngày 12 giờ | |||
Hoạt động trong quản lý chu kỳ doanh thu
| Hoạt động | Mô tả | ||
|---|---|---|---|
| Đã đóng tài khoản | Sự kiện lập hóa đơn đã được giải quyết hoàn toàn, số dư bằng không và tài khoản chính thức được đóng. Điều này cho thấy chu kỳ doanh thu của lần khám cụ thể đã hoàn tất thành công. | ||
| Vì sao điều này quan trọng Đây là sự kiện kết thúc của luồng xử lý thông thường. Đo thời gian đóng tài khoản giúp bảo đảm các công việc hành chính được hoàn tất hiệu quả và hồ sơ được chốt. Lấy dữ liệu ở đâu Sự kiện này được suy ra khi số dư tài khoản về không và trạng thái cuối cùng chuyển thành “Đã đóng” hoặc “Đã thanh toán đầy đủ”. Dấu thời gian được lấy từ giao dịch tài chính cuối cùng đưa số dư về không. Thu thập Suy ra khi số dư tài khoản về không, trạng thái chuyển thành “Đã đóng” và có dấu thời gian hoạt động cuối cùng. Loại sự kiện inferred | |||
| Đã ghi nhận khoản phí | Hoạt động này ghi nhận chính thức tất cả dịch vụ, thủ thuật và vật tư có tính phí trong một lần khám của bệnh nhân. Đây là bước nhập dữ liệu quan trọng, chuyển hoạt động lâm sàng thành giao dịch tài chính. | ||
| Vì sao điều này quan trọng Đánh dấu thời điểm bàn giao từ hoạt động lâm sàng sang hoạt động tài chính. Đây là điểm bắt đầu để đo thời gian lập hóa đơn và yêu cầu thanh toán, đồng thời giúp phát hiện lượng hồ sơ phí tồn đọng. Lấy dữ liệu ở đâu Được ghi nhận trong mô-đun nhập khoản phí của R1 RCM hoặc nhận qua giao diện kết nối với EHR. Sự kiện này thường được đánh dấu bằng nhật ký giao dịch cụ thể hoặc dấu thời gian tạo hồ sơ khoản phí. Thu thập Được xác định bằng dấu thời gian tạo hồ sơ giao dịch khoản phí trong bảng lập hóa đơn. Loại sự kiện explicit | |||
| Đã ghi nhận thanh toán | Khoản thanh toán đã nhận được chính thức phân bổ vào tài khoản bệnh nhân, làm giảm số dư còn nợ. Đây là bước cuối cùng để đối soát khoản thanh toán với các dịch vụ đã lập hóa đơn. | ||
| Vì sao điều này quan trọng Hoạt động này là điểm kết thúc để tính thời gian từ cung cấp dịch vụ đến thanh toán và thời gian ghi nhận thanh toán. Hoạt động xác nhận doanh thu đã được ghi nhận và tài khoản được cập nhật chính xác. Lấy dữ liệu ở đâu Được ghi nhận thành giao dịch tài chính cụ thể trong mô-đun kế toán bệnh nhân của R1 RCM. Mỗi lần ghi nhận gồm ngày, số tiền và nguồn thanh toán. Thu thập Được ghi nhận thành giao dịch cụ thể có ngày hạch toán khi người dùng hoặc quy trình tự động phân bổ khoản thanh toán. Loại sự kiện explicit | |||
| Đã gửi yêu cầu thanh toán | Yêu cầu thanh toán đã tạo được gửi điện tử đến bên thanh toán có trách nhiệm, chẳng hạn như công ty bảo hiểm. Đây là lần đầu tiên quy trình lập hóa đơn liên lạc với bên ngoài để yêu cầu hoàn trả chi phí. | ||
| Vì sao điều này quan trọng Đây là mốc quan trọng, đánh dấu thời điểm bắt đầu tính thời gian chờ bên thanh toán hoàn trả. Theo dõi mốc này giúp kiểm soát hồ sơ chờ gửi và bảo đảm gửi đúng hạn theo yêu cầu của bên thanh toán. Lấy dữ liệu ở đâu Sự kiện này được ghi nhận thành giao dịch cụ thể khi yêu cầu thanh toán được truyền đến đơn vị trung gian xử lý. Hệ thống lưu dấu thời gian gửi và thông tin xác nhận. Thu thập Được ghi nhận rõ ràng thành giao dịch có dấu thời gian gửi khi yêu cầu thanh toán được chuyển qua đơn vị trung gian xử lý. Loại sự kiện explicit | |||
| Đã nhận thanh toán | Khoản thanh toán được nhận từ bên thanh toán hoặc bệnh nhân. Sự kiện này đánh dấu thời điểm nhận tiền, nhưng tiền chưa được phân bổ vào tài khoản hoặc dịch vụ cụ thể. | ||
| Vì sao điều này quan trọng Đại diện cho dòng tiền vào. Khoảng thời gian từ “Đã nhận thanh toán” đến “Đã ghi nhận thanh toán” là chỉ số quan trọng để đánh giá hiệu quả xử lý hậu cần và độ trễ khi đối soát tiền. Lấy dữ liệu ở đâu Được ghi nhận từ tệp chuyển tiền điện tử của bên thanh toán hoặc từ quá trình xử lý thanh toán của bệnh nhân. Sự kiện tương ứng với ngày tiền được gửi vào tài khoản hoặc ngày nhận tệp. Thu thập Được ghi nhận từ ngày thanh toán có hiệu lực trong tệp ERA hoặc ngày giao dịch thanh toán của bệnh nhân. Loại sự kiện explicit | |||
| Dịch vụ đã cung cấp | Đây là thời điểm dịch vụ hoặc thủ thuật có tính phí dành cho bệnh nhân được hoàn tất. Sự kiện này thường được ghi nhận trong hệ thống lâm sàng hoặc hệ thống xếp lịch, đồng thời là điểm khởi đầu của chu kỳ doanh thu. | ||
| Vì sao điều này quan trọng Đây là điểm bắt đầu để tính KPI thời gian từ cung cấp dịch vụ đến thanh toán. Phân tích khoảng thời gian từ sự kiện này giúp xác định các khâu chậm trễ ở đầu chu kỳ doanh thu. Lấy dữ liệu ở đâu Dữ liệu thường lấy từ hồ sơ sức khỏe điện tử (EHR) hoặc hệ thống quản lý phòng khám được tích hợp với R1 RCM. Sự kiện này thường được suy ra từ dấu thời gian “Ngày cung cấp dịch vụ” hoặc “Hoàn tất thủ thuật” trong hồ sơ bệnh nhân. Thu thập Suy ra từ dấu thời gian “Ngày cung cấp dịch vụ” gắn với lần khám của bệnh nhân. Loại sự kiện inferred | |||
| Bắt đầu hoạt động thu hồi công nợ | Tài khoản của bệnh nhân đã quá hạn thanh toán và các hoạt động thu hồi công nợ được bắt đầu chủ động. Các hoạt động này có thể gồm gửi thư nhắc tự động hoặc chuyển hồ sơ cho chuyên viên thu hồi công nợ. | ||
| Vì sao điều này quan trọng Đánh dấu thời điểm bắt đầu quy trình thu hồi công nợ tốn nhiều chi phí. Phân tích hiệu quả và thời gian xử lý của các hoạt động này giúp tối ưu chiến lược thu hồi nợ khó đòi. Lấy dữ liệu ở đâu Sự kiện này có thể được ghi nhận hoặc suy ra từ thay đổi trạng thái khi tài khoản được chuyển vào hàng đợi thu hồi công nợ hoặc được gán mã trạng thái thu hồi công nợ trong R1 RCM. Thu thập Suy ra từ việc trạng thái tài khoản chuyển thành “Đang thu hồi công nợ” hoặc “Quá hạn”. Loại sự kiện inferred | |||
| Bắt đầu xử lý lại yêu cầu bị từ chối | Người dùng hoặc quy trình làm việc tự động bắt đầu kiểm tra và xử lý yêu cầu thanh toán bị từ chối. Việc này có thể gồm sửa mã hóa, gửi hồ sơ bổ sung hoặc khiếu nại quyết định của bên thanh toán. | ||
| Vì sao điều này quan trọng Đánh dấu thời điểm bắt đầu vòng xử lý lại tốn kém đối với yêu cầu bị từ chối. Đo thời gian ở giai đoạn này là yếu tố then chốt để đánh giá hiệu quả của nhóm xử lý yêu cầu bị từ chối. Lấy dữ liệu ở đâu Sự kiện này thường được suy ra từ việc trạng thái yêu cầu bị từ chối chuyển thành “Đang xử lý lại” hoặc “Đang xem xét” trong hàng đợi công việc hay mô-đun quản lý từ chối của R1 RCM. Thu thập Suy ra từ thay đổi trạng thái trong hàng đợi xử lý yêu cầu bị từ chối hoặc từ thao tác đầu tiên của người dùng trên yêu cầu đó. Loại sự kiện inferred | |||
| Chuyển tài khoản sang nợ khó đòi | Mọi nỗ lực thu hồi công nợ đã được thực hiện nhưng số dư còn lại được xác định là không thể thu hồi. Khoản này được xóa sổ thành nợ khó đòi, đồng nghĩa với việc doanh thu bị mất hoàn toàn. | ||
| Vì sao điều này quan trọng Đây là kết quả tiêu cực của quy trình và gây thất thoát doanh thu trực tiếp. Phân tích những trường hợp kết thúc bằng nợ khó đòi có thể cho thấy các mẫu không thanh toán và cơ hội cải thiện hoạt động thu hồi công nợ. Lấy dữ liệu ở đâu Đây thường là giao dịch cụ thể trong R1 RCM, chuyển số dư chưa thanh toán sang một nhóm nợ khó đòi riêng. Giao dịch thường do người dùng thực hiện hoặc được kích hoạt theo quy tắc phân loại nợ quá hạn tự động. Thu thập Được ghi nhận thành giao dịch tài chính cụ thể để xóa sổ số dư, thường gắn với việc chuyển khoản nợ cho đơn vị thu hồi công nợ bên ngoài. Loại sự kiện explicit | |||
| Đã điều chỉnh tài khoản | Một giao dịch không phải thanh toán được ghi vào tài khoản để thay đổi số dư. Giao dịch này có thể gồm điều chỉnh theo thỏa thuận với bên thanh toán, xóa khoản dư nhỏ hoặc sửa sai. | ||
| Vì sao điều này quan trọng Số lần điều chỉnh cao có thể cho thấy vấn đề về biểu phí, quản lý hợp đồng hoặc lỗi lập hóa đơn. Theo dõi các khoản điều chỉnh là việc thiết yếu để phân tích tính chính xác của doanh thu. Lấy dữ liệu ở đâu Được ghi nhận thành loại giao dịch cụ thể trong mô-đun kế toán bệnh nhân của R1 RCM. Mỗi khoản điều chỉnh có mã, số tiền và ngày hạch toán. Thu thập Được ghi nhận thành giao dịch điều chỉnh riêng biệt, có thể nhận diện bằng mã giao dịch duy nhất. Loại sự kiện explicit | |||
| Đã nhận kết quả xét duyệt từ bên thanh toán | Hệ thống nhận phản hồi từ bên thanh toán về yêu cầu đã gửi, thường qua tệp Electronic Remittance Advice (ERA). Phản hồi này nêu rõ khoản nào được thanh toán, bị từ chối hoặc điều chỉnh. | ||
| Vì sao điều này quan trọng Sự kiện này tạo ra bước rẽ quan trọng trong quy trình, quyết định bước tiếp theo là ghi nhận thanh toán hay xử lý yêu cầu bị từ chối. Phân tích sự kiện giúp hiểu rõ cách bên thanh toán xử lý và tốc độ thanh toán. Lấy dữ liệu ở đâu Được ghi nhận khi R1 RCM xử lý tệp chuyển tiền điện tử từ bên thanh toán, chẳng hạn như tệp ANSI 835. Sự kiện được đánh dấu bằng dấu thời gian xử lý tệp. Thu thập Được ghi nhận khi tiếp nhận và xử lý tệp Electronic Remittance Advice (ERA/835). Loại sự kiện explicit | |||
| Đã tạo bảng kê cho bệnh nhân | Sau khi bảo hiểm xét duyệt, hệ thống tạo bảng kê cho bệnh nhân, nêu rõ số dư còn lại mà bệnh nhân cần thanh toán. Khoản này có thể gồm đồng thanh toán, khoản khấu trừ hoặc dịch vụ không được bảo hiểm chi trả. | ||
| Vì sao điều này quan trọng Hoạt động này bắt đầu phần thanh toán của bệnh nhân trong chu kỳ doanh thu. Phân tích thời điểm và tần suất tạo bảng kê rất quan trọng để quản lý việc thu tiền từ bệnh nhân và dòng tiền. Lấy dữ liệu ở đâu Thường được ghi nhận khi chạy quy trình theo lô để tạo và in hoặc gửi bảng kê cho bệnh nhân qua phương thức điện tử. R1 RCM sẽ lưu ngày tạo bảng kê. Thu thập Được ghi nhận thành giao dịch khi chạy quy trình theo lô để tạo bảng kê cho bệnh nhân. Loại sự kiện explicit | |||
| Đã tạo yêu cầu thanh toán | Hệ thống tạo yêu cầu thanh toán chính thức dựa trên các khoản phí đã ghi nhận. Quá trình này tổng hợp thông tin nhân khẩu học của bệnh nhân, thông tin bảo hiểm và mã dịch vụ theo định dạng chuẩn. | ||
| Vì sao điều này quan trọng Đây là mốc quan trọng trong nội bộ, trước khi gửi yêu cầu ra bên ngoài. Chậm trễ ở bước này có thể cho thấy vấn đề về mã hóa, xác thực dữ liệu hoặc cấu hình hệ thống, làm chậm toàn bộ quy trình lập hóa đơn. Lấy dữ liệu ở đâu Đây là sự kiện nội bộ trong hệ thống R1 RCM. Sự kiện này có thể được ghi nhận dưới dạng thay đổi trạng thái trên tài khoản lập hóa đơn hoặc dấu thời gian tạo chính hồ sơ yêu cầu thanh toán. Thu thập Suy ra từ việc trạng thái chuyển thành “Đã tạo yêu cầu thanh toán” hoặc từ dấu thời gian tạo hồ sơ yêu cầu thanh toán. Loại sự kiện inferred | |||
| Yêu cầu thanh toán bị từ chối | Bên thanh toán từ chối thanh toán toàn bộ yêu cầu hoặc một số khoản mục cụ thể. Lý do từ chối được ghi nhận và bắt đầu quy trình làm lại, khiếu nại. | ||
| Vì sao điều này quan trọng Hoạt động này cho thấy doanh thu bị thất thoát và quy trình kém hiệu quả. Phân tích lý do từ chối là bước thiết yếu để tìm nguyên nhân gốc rễ và nâng cao tỷ lệ yêu cầu được chấp thuận ngay lần đầu. Lấy dữ liệu ở đâu Đây không phải là một sự kiện riêng biệt mà là trạng thái được suy ra từ thông tin trong tệp ERA đã xử lý. Các mã từ chối cụ thể trong dữ liệu chuyển tiền sẽ làm thay đổi trạng thái của yêu cầu thanh toán. Thu thập Suy ra từ các mã từ chối trong tệp ERA đã xử lý, khiến trạng thái yêu cầu thanh toán chuyển thành “Bị từ chối”. Loại sự kiện inferred | |||
Hướng dẫn trích xuất dữ liệu
Các bước
- Đăng nhập vào nền tảng R1 RCM bằng tài khoản người dùng có quyền truy cập các mô-đun Business Intelligence hoặc báo cáo.
- Mở mục báo cáo trên nền tảng. Mục này có thể mang tên "Business Intelligence", "Reporting Portal" hoặc "Analytics".
- Tìm công cụ tạo báo cáo tùy chỉnh hoặc truy vấn mới. Công cụ này cho phép bạn chọn các trường dữ liệu và logic trích xuất.
- R1 RCM không cung cấp sẵn một nhật ký sự kiện thống nhất. Vì vậy, bạn cần kết hợp dữ liệu từ nhiều nguồn để tạo nhật ký. Cấu hình truy vấn được cung cấp dùng UNION ALL để gộp sự kiện từ nhiều đối tượng nghiệp vụ thành một nhật ký theo trình tự thời gian.
- Sao chép toàn bộ truy vấn trong mục "Query" của tài liệu này và dán vào trình chỉnh sửa truy vấn hoặc giao diện cấu hình báo cáo tùy chỉnh.
- Cấu hình tham số báo cáo, đặc biệt là khoảng thời gian. Thay các chỗ giữ chỗ
'{StartDate}'và'{EndDate}'trong truy vấn để xác định kỳ trích xuất, chẳng hạn 6 tháng gần nhất. - Thêm các bộ lọc cần thiết khác, chẳng hạn cơ sở, phòng ban hoặc nhóm bên thanh toán cụ thể, để thu hẹp phạm vi dữ liệu.
- Chạy báo cáo. Truy vấn sẽ chạy trên cơ sở dữ liệu R1 RCM và tạo kết quả theo các tham số bạn đã chọn.
- Khi báo cáo chạy xong, chọn chức năng xuất dữ liệu. Chọn CSV (Comma Separated Values) làm định dạng xuất vì định dạng này tương thích trực tiếp với ProcessMind.
- Tải tệp CSV xuống và mở để kiểm tra nhanh. Đảm bảo tiêu đề cột khớp với các thuộc tính bắt buộc:
BillingEvent,ActivityName,EventTime,SourceSystemvàLastDataUpdate. - Kiểm tra định dạng ngày giờ trong các cột
EventTimevàLastDataUpdatecó nhất quán hay không trước khi tải tệp lên ProcessMind.
Cấu hình
- Điều kiện cần: Cần có tài khoản người dùng đủ quyền truy cập và tạo báo cáo tùy chỉnh trong mô-đun Business Intelligence của R1 RCM.
- Loại báo cáo: Dùng truy vấn tùy chỉnh hoặc công cụ tạo báo cáo nâng cao, hỗ trợ truy xuất dữ liệu phức tạp và câu lệnh UNION ALL để kết hợp các tập dữ liệu.
- Khoảng thời gian: Để kiểm soát hiệu suất và dung lượng dữ liệu, bạn cần lọc theo một khoảng thời gian cụ thể. Với lần phân tích đầu tiên, nên bắt đầu bằng khoảng 3 đến 6 tháng. Áp dụng bộ lọc ngày cho trường dấu thời gian chính của từng hoạt động.
- Bộ lọc chính: Ngoài khoảng thời gian, hãy cân nhắc lọc theo
Facility ID,Payer TypehoặcBilling Departmentđể tập trung phân tích vào một số khu vực vận hành và giảm dung lượng tệp xuất. - Định dạng xuất: Luôn chọn CSV làm định dạng đầu ra. Tệp có cấu trúc rõ ràng và dễ được các công cụ process mining đọc.
- Lên lịch: Nếu mô-đun báo cáo R1 RCM hỗ trợ, bạn có thể lên lịch chạy báo cáo định kỳ, chẳng hạn hằng tuần hoặc hằng tháng, để tự động cập nhật dữ liệu phục vụ việc theo dõi liên tục.
Truy vấn mẫu sql
SELECT
c.ClaimID AS BillingEvent,
'Service Rendered' AS ActivityName,
c.ServiceDate AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
c.ClinicianID AS AssignedUser,
d.DepartmentName AS BillingDepartment,
c.TotalChargeAmount AS InvoiceAmount,
p.PayerName AS PayerName,
'Rendered' AS InvoiceStatus,
NULL AS DenialReasonCode
FROM [ServiceAndChargeData] c
JOIN [Departments] d ON c.DepartmentID = d.DepartmentID
JOIN [Payers] p ON c.PayerID = p.PayerID
WHERE c.ServiceDate BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
c.ClaimID AS BillingEvent,
'Charges Captured' AS ActivityName,
c.ChargeEntryTimestamp AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
c.ChargeEntryUserID AS AssignedUser,
d.DepartmentName AS BillingDepartment,
c.TotalChargeAmount AS InvoiceAmount,
p.PayerName AS PayerName,
'Open' AS InvoiceStatus,
NULL AS DenialReasonCode
FROM [ServiceAndChargeData] c
JOIN [Departments] d ON c.DepartmentID = d.DepartmentID
JOIN [Payers] p ON c.PayerID = p.PayerID
WHERE c.ChargeEntryTimestamp BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
cl.ClaimID AS BillingEvent,
'Claim Created' AS ActivityName,
cl.CreationTimestamp AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
cl.CreatedByUserID AS AssignedUser,
cl.BillingDepartment AS BillingDepartment,
cl.TotalAmount AS InvoiceAmount,
cl.PayerName AS PayerName,
'Created' AS InvoiceStatus,
NULL AS DenialReasonCode
FROM [ClaimsData] cl
WHERE cl.CreationTimestamp BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
cl.ClaimID AS BillingEvent,
'Claim Submitted' AS ActivityName,
cl.SubmissionTimestamp AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
cl.SubmittedByUserID AS AssignedUser,
cl.BillingDepartment AS BillingDepartment,
cl.TotalAmount AS InvoiceAmount,
cl.PayerName AS PayerName,
'Submitted' AS InvoiceStatus,
NULL AS DenialReasonCode
FROM [ClaimsData] cl
WHERE cl.SubmissionTimestamp BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
era.ClaimID AS BillingEvent,
'Payer Adjudication Received' AS ActivityName,
era.ReceivedTimestamp AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
'System' AS AssignedUser,
pa.BillingDepartment AS BillingDepartment,
pa.InvoiceAmount AS InvoiceAmount,
era.PayerName AS PayerName,
'Adjudicated' AS InvoiceStatus,
NULL AS DenialReasonCode
FROM [RemittanceAdvice] era
JOIN [PatientAccounts] pa ON era.ClaimID = pa.BillingEvent
WHERE era.ReceivedTimestamp BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
d.ClaimID AS BillingEvent,
'Claim Denied' AS ActivityName,
d.DenialTimestamp AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
'System' AS AssignedUser,
cl.BillingDepartment AS BillingDepartment,
cl.TotalAmount AS InvoiceAmount,
cl.PayerName AS PayerName,
'Denied' AS InvoiceStatus,
d.ReasonCode AS DenialReasonCode
FROM [DenialsLog] d
JOIN [ClaimsData] cl ON d.ClaimID = cl.ClaimID
WHERE d.DenialTimestamp BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
dr.ClaimID AS BillingEvent,
'Denial Rework Started' AS ActivityName,
dr.ReworkStartTimestamp AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
dr.AssignedUserID AS AssignedUser,
cl.BillingDepartment AS BillingDepartment,
cl.TotalAmount AS InvoiceAmount,
cl.PayerName AS PayerName,
'In Rework' AS InvoiceStatus,
dr.OriginalDenialCode AS DenialReasonCode
FROM [DenialRework] dr
JOIN [ClaimsData] cl ON dr.ClaimID = cl.ClaimID
WHERE dr.ReworkStartTimestamp BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
ps.PatientAccountID AS BillingEvent,
'Patient Statement Generated' AS ActivityName,
ps.GenerationTimestamp AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
ps.GeneratedByUserID AS AssignedUser,
pa.BillingDepartment AS BillingDepartment,
ps.StatementBalance AS InvoiceAmount,
'Patient' AS PayerName,
'Patient Billed' AS InvoiceStatus,
NULL AS DenialReasonCode
FROM [PatientStatements] ps
JOIN [PatientAccounts] pa ON ps.PatientAccountID = pa.BillingEvent
WHERE ps.GenerationTimestamp BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
p.AssociatedClaimID AS BillingEvent,
'Payment Received' AS ActivityName,
p.ReceiptTimestamp AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
p.ProcessedByUserID AS AssignedUser,
pa.BillingDepartment AS BillingDepartment,
p.PaymentAmount AS InvoiceAmount,
p.PayerName AS PayerName,
'Payment Pending' AS InvoiceStatus,
NULL AS DenialReasonCode
FROM [PaymentsLog] p
JOIN [PatientAccounts] pa ON p.AssociatedClaimID = pa.BillingEvent
WHERE p.ReceiptTimestamp BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
pt.ClaimID AS BillingEvent,
'Payment Posted' AS ActivityName,
pt.PostingTimestamp AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
pt.PostedByUserID AS AssignedUser,
pa.BillingDepartment AS BillingDepartment,
pt.PostedAmount AS InvoiceAmount,
pt.PayerName AS PayerName,
'Partially Paid' AS InvoiceStatus,
NULL AS DenialReasonCode
FROM [PaymentTransactions] pt
JOIN [PatientAccounts] pa ON pt.ClaimID = pa.BillingEvent
WHERE pt.PostingTimestamp BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
a.ClaimID AS BillingEvent,
'Account Adjustment Made' AS ActivityName,
a.AdjustmentTimestamp AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
a.AdjusterID AS AssignedUser,
pa.BillingDepartment AS BillingDepartment,
a.AdjustmentAmount AS InvoiceAmount,
pa.PayerName AS PayerName,
'Adjusted' AS InvoiceStatus,
NULL AS DenialReasonCode
FROM [Adjustments] a
JOIN [PatientAccounts] pa ON a.ClaimID = pa.BillingEvent
WHERE a.AdjustmentTimestamp BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
ca.PatientAccountID AS BillingEvent,
'Collection Activity Started' AS ActivityName,
ca.ActivityTimestamp AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
ca.AssignedAgentID AS AssignedUser,
'Collections' AS BillingDepartment,
pa.CurrentBalance AS InvoiceAmount,
'Patient' AS PayerName,
'In Collections' AS InvoiceStatus,
NULL AS DenialReasonCode
FROM [CollectionsActivity] ca
JOIN [PatientAccounts] pa ON ca.PatientAccountID = pa.BillingEvent
WHERE ca.ActivityTimestamp BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
pa.BillingEvent AS BillingEvent,
'Account Placed in Bad Debt' AS ActivityName,
pa.BadDebtPlacementDate AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
pa.BadDebtUserID AS AssignedUser,
'Finance' AS BillingDepartment,
pa.CurrentBalance AS InvoiceAmount,
'Patient' AS PayerName,
'Bad Debt' AS InvoiceStatus,
NULL AS DenialReasonCode
FROM [PatientAccounts] pa
WHERE pa.BadDebtPlacementDate BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
pa.BillingEvent AS BillingEvent,
'Account Closed' AS ActivityName,
pa.ClosureDate AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
'System' AS AssignedUser,
pa.BillingDepartment AS BillingDepartment,
0 AS InvoiceAmount,
pa.PayerName AS PayerName,
'Closed' AS InvoiceStatus,
NULL AS DenialReasonCode
FROM [PatientAccounts] pa
WHERE pa.ClosureDate BETWEEN '{StartDate}' AND '{EndDate}' AND pa.CurrentBalance = 0;Sẵn sàng bắt đầu?
Dùng mẫu này để đơn giản hóa việc thu thập dữ liệu và bắt đầu tối ưu quy trình quản lý chu kỳ doanh thu. Chúng tôi luôn sẵn sàng hỗ trợ bạn trong từng bước.
Tối ưu R1 RCM ngay hôm nay, nâng cao hiệu quả chu kỳ doanh thu
Loại bỏ điểm nghẽn RCM, giảm 30% thời gian xử lý và cải thiện dòng tiền.
Không cần thẻ tín dụng. Bắt đầu chỉ trong vài phút.