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
- Các hoạt động chính cần theo dõi
- Hướng dẫn trích xuất dữ liệu
Các thuộc tính trong quản lý chu kỳ doanh thu
| Tên | Mô tả | ||
|---|---|---|---|
| Dấu thời gian sự kiện EventTimestamp | Ngày và giờ chính xác khi một hoạt động hoặc sự kiện cụ thể diễn ra. | ||
| Mô tả Dấu thời gian sự kiện ghi lại thời điểm một hoạt động diễn ra. Dữ liệu thời gian này rất quan trọng để hiểu thời điểm và thứ tự các sự kiện trong chu trình doanh thu. Khi phân tích, dấu thời gian được dùng để tính khoảng thời gian giữa các hoạt động, chẳng hạn độ trễ khi ghi nhận khoản thu hoặc thời gian ghi nhận thanh toán. Dữ liệu này giúp phát hiện điểm nghẽn, đo thời gian chu trình và phân tích hiệu quả quy trình qua các giai đoạn khác nhau. Dấu thời gian chính xác là yếu tố thiết yếu đối với hầu hết KPI và bảng điều khiển dựa trên thời gian. Vì sao điều này quan trọng Thuộc tính này cần thiết để tính mọi chỉ số dựa trên thời gian, bao gồm thời gian chu trình và thời lượng, vốn rất quan trọng để phát hiện chậm trễ và kém hiệu quả. Lấy dữ liệu ở đâu Có trong các bảng giao dịch hoặc nhật ký sự kiện của Epic Resolute, gắn với từng hoạt động được ghi nhận. Tên trường thường có hậu tố như Dt, DTTM hoặc Time. Ví dụ 2023-04-15T09:30:00Z2023-04-16T11:05:21Z2023-05-01T14:00:00Z | |||
| Sự kiện thanh toán BillingEvent | Mã định danh duy nhất cho một lần cung cấp dịch vụ hoặc sản phẩm phát sinh khoản thu, được dùng làm mã định danh trường hợp chính. | ||
| Mô tả Sự kiện thanh toán là mã định danh cốt lõi, liên kết mọi hoạt động trong chu trình doanh thu của một khoản có thể lập hóa đơn cụ thể. Sự kiện bắt đầu khi dịch vụ được cung cấp và kết thúc khi tài khoản được thanh toán đầy đủ hoặc đóng lại. Trong phân tích process mining, thuộc tính này rất cần thiết để dựng lại toàn bộ hành trình của từng khoản thu. Nhờ đó, bạn có thể theo dõi các hoạt động như ghi nhận khoản thu, gửi yêu cầu bồi thường, ghi nhận thanh toán và xử lý yêu cầu bị từ chối cho từng sự kiện thanh toán, từ đó thấy rõ luồng quy trình và các biến thể. Vì sao điều này quan trọng Đây là mã trường hợp cốt lõi, cần thiết để liên kết mọi bước liên quan và phân tích toàn bộ vòng đời tạo doanh thu, thu tiền cho từng dịch vụ. Lấy dữ liệu ở đâu Đây thường là mã định danh duy nhất của tài khoản bệnh viện (HAR) hoặc một phiên ghi nhận khoản thu cụ thể trong Epic Resolute. Tham khảo tài liệu Epic Resolute để biết các bảng cụ thể như HAR hoặc bản ghi Charge Session. Ví dụ BE10098765BE20012345BE30054321 | |||
| Tên hoạt động ActivityName | Tên của sự kiện hoặc tác vụ cụ thể được thực hiện trong quy trình quản lý chu trình doanh thu. | ||
| Mô tả Thuộc tính này mô tả một bước trong chu trình doanh thu, chẳng hạn như 'Đã ghi nhận khoản thu', 'Đã gửi yêu cầu bồi thường cho bên chi trả' hoặc 'Đã nhận thanh toán'. Mỗi hoạt động là một cột mốc riêng trong quy trình lập hóa đơn và thu tiền cho dịch vụ. Phân tích hoạt động là nền tảng của process mining. Việc này giúp trực quan hóa sơ đồ quy trình, xác định các luồng phổ biến, phát hiện điểm nghẽn giữa các bước và đo mức độ tuân thủ quy trình vận hành chuẩn. Vì sao điều này quan trọng Xác định các bước trong sơ đồ quy trình, giúp bạn trực quan hóa, phân tích và tối ưu luồng công việc trong chu trình doanh thu. Lấy dữ liệu ở đâu Thông tin này thường được lấy từ nhật ký sự kiện, nhật ký kiểm tra hoặc bản ghi thay đổi trạng thái trong các phân hệ thanh toán và yêu cầu bồi thường của Epic Resolute. Ví dụ Khoản thu đã được ghi nhậnĐã gửi yêu cầu bồi thường cho bên chi trảĐã nhận thanh toánĐã đóng tài khoản | |||
| Bộ phận thanh toán BillingDepartment | Bộ phận hoặc nhóm chức năng phụ trách sự kiện hay hoạt động thanh toán. | ||
| Mô tả Thuộc tính này cho biết đơn vị trong tổ chức, chẳng hạn 'Thanh toán nội trú', 'Thanh toán ngoại trú' hoặc 'Nhóm xử lý yêu cầu bị từ chối', có liên quan đến sự kiện thanh toán hoặc thực hiện một hoạt động cụ thể. Chiều dữ liệu này rất quan trọng đối với bảng điều khiển 'Chỉ số hiệu suất bộ phận thanh toán', giúp so sánh các chỉ số chính giữa các bộ phận, chẳng hạn tỷ lệ yêu cầu bị từ chối hoặc thời gian ghi nhận khoản thu. Nhờ đó, quản lý có thể xác định bộ phận hoạt động tốt, chuẩn hóa cách làm hiệu quả và phân bổ tài nguyên hợp lý. Vì sao điều này quan trọng Cho phép so sánh hiệu suất giữa các bộ phận, giúp xác định cách làm hiệu quả và những nơi cần cải thiện hoặc bổ sung tài nguyên. Lấy dữ liệu ở đâu Thông tin này có thể được liên kết với hồ sơ người dùng, tài khoản bệnh nhân hoặc địa điểm cung cấp dịch vụ trong Epic Resolute. Ví dụ Bộ phận thanh toán tim mạchRCM chẩn đoán hình ảnhVăn phòng thanh toán trung tâm | |||
| Loại dịch vụ ServiceType | Nhóm hoặc loại dịch vụ y tế đã được cung cấp. | ||
| Mô tả Thuộc tính này phân loại dịch vụ được tính phí, chẳng hạn như “Chẩn đoán hình ảnh”, “Phẫu thuật”, “Tư vấn” hoặc “Khám cấp cứu”. Thuộc tính cung cấp bối cảnh lâm sàng cho dữ liệu tài chính. Phân tích chu kỳ doanh thu theo loại dịch vụ có thể giúp phát hiện những khác biệt trong quy trình ở từng chuyên khoa. Ví dụ, phẫu thuật có thể cần ghi nhận chi phí và xin phê duyệt phức tạp hơn một lần khám thông thường, dẫn đến cách xử lý và thách thức khác nhau. Vì sao điều này quan trọng Bổ sung bối cảnh lâm sàng cho dữ liệu tài chính, giúp phân tích tác động của từng loại dịch vụ y tế đến quy trình chu kỳ doanh thu và hiệu quả của quy trình. Lấy dữ liệu ở đâu Được lấy từ danh mục mô tả khoản phí (CDM), tuyến dịch vụ hoặc khoa liên quan đến giao dịch tính phí trong Epic. Ví dụ Phẫu thuật nội trúChẩn đoán hình ảnh ngoại trúDịch vụ cấp cứu | |||
| Lý do điều chỉnh AdjustmentReason | Lý do điều chỉnh số dư tài khoản bệnh nhân theo cách thủ công hoặc tự động. | ||
| Mô tả Thuộc tính này giải thích lý do số dư tài khoản thay đổi ngoài các khoản thanh toán hoặc khoản thu thông thường. Lý do có thể gồm mức giảm trừ theo hợp đồng với bên chi trả, xóa khoản dư nhỏ hoặc sửa lỗi ghi nhận. Thuộc tính này rất cần thiết cho bảng điều khiển 'Số lượng điều chỉnh tài khoản theo loại'. Phân tích lý do điều chỉnh giúp tổ chức xác định nguồn thất thoát doanh thu, hiểu tác động của hợp đồng với bên chi trả và phát hiện điểm kém hiệu quả hoặc lỗi tiềm ẩn trong quy trình thanh toán. Vì sao điều này quan trọng Giải thích lý do số dư tài khoản thay đổi, giúp làm rõ thất thoát doanh thu và độ chính xác của thanh toán, đồng thời giảm các khoản xóa nợ không cần thiết. Lấy dữ liệu ở đâu Có trong chi tiết giao dịch của các khoản điều chỉnh thuộc phân hệ kế toán bệnh nhân của Epic Resolute. Ví dụ Mức giảm trừ theo hợp đồngXóa khoản dư nhỏĐiều chỉnh khoản thu trùng lặp | |||
| Mã lý do từ chối DenialReasonCode | Mã chuẩn cho biết lý do bên chi trả từ chối yêu cầu bồi thường đã gửi. | ||
| Mô tả Khi từ chối yêu cầu bồi thường, bên chi trả cung cấp mã lý do giải thích việc từ chối, chẳng hạn 'Dịch vụ không được bảo hiểm', 'Yêu cầu trùng lặp' hoặc 'Cần thêm thông tin'. Các mã này thường được chuẩn hóa thành Mã lý do điều chỉnh yêu cầu bồi thường (CARC). Thuộc tính này là nền tảng của bảng điều khiển 'Tỷ lệ và lý do yêu cầu bồi thường bị từ chối'. Phân tích tần suất của từng mã giúp xác định nguyên nhân gốc rễ, chẳng hạn vấn đề về chứng nhận, lỗi mã hóa hoặc thiếu phê duyệt trước, từ đó triển khai cải tiến đúng mục tiêu. Vì sao điều này quan trọng Giải thích trực tiếp lý do yêu cầu bồi thường bị từ chối, cung cấp thông tin hữu ích để giảm tỷ lệ từ chối, ngăn thất thoát doanh thu và đẩy nhanh thanh toán. Lấy dữ liệu ở đâu Dữ liệu này có trong giao dịch phản hồi yêu cầu bồi thường, chẳng hạn tệp ANSI 835, do bên chi trả gửi và được lưu trong phân hệ quản lý yêu cầu bồi thường của Epic Resolute. Ví dụ CO-16: Yêu cầu/dịch vụ thiếu thông tinOA-18: Yêu cầu/dịch vụ trùng lặpPR-96: Khoản thu không được bảo hiểm | |||
| Người dùng phụ trách ResponsibleUser | Mã định danh của người dùng hoặc nhân viên đã thực hiện hoạt động. | ||
| Mô tả Thuộc tính này ghi lại ID người dùng, tên hoặc mã nhân viên của người phụ trách hoàn thành một tác vụ cụ thể trong chu trình doanh thu. Đó có thể là nhân viên lâm sàng nhập khoản thu, nhân viên thanh toán gửi yêu cầu bồi thường hoặc nhân viên thu hồi nợ theo dõi yêu cầu bị từ chối. Phân tích theo người dùng giúp xác định người làm tốt, tìm nhu cầu đào tạo và hiểu cách phân bổ khối lượng công việc. Đây là thông tin quan trọng để quản lý hiệu suất và điều tra sai lệch quy trình liên quan đến cá nhân hoặc vai trò cụ thể. Vì sao điều này quan trọng Cho phép phân tích hiệu suất theo từng người hoặc vai trò, giúp xác định nhu cầu đào tạo, mất cân đối khối lượng công việc và điểm nghẽn liên quan đến tài nguyên. Lấy dữ liệu ở đâu Thông tin này thường có trong nhật ký kiểm tra hoặc nhật ký giao dịch của Epic Resolute, thường được liên kết với bảng dữ liệu người dùng chính, chẳng hạn bản ghi EMP. Ví dụ j.doebsmith123User7890 | |||
| Số dư còn nợ OutstandingBalance | Số tiền bên chi trả hoặc bệnh nhân còn nợ cho sự kiện thanh toán. | ||
| Mô tả Thuộc tính này thể hiện số dư khoản phải thu hiện tại của một sự kiện thanh toán cụ thể tại thời điểm hoạt động diễn ra. Số dư phản ánh tình trạng tài chính của trường hợp trong suốt vòng đời. Số dư còn nợ rất quan trọng đối với báo cáo tài chính và 'Báo cáo tuổi nợ số dư còn nợ'. Phân tích số dư theo thời gian và theo các chiều dữ liệu như bên chi trả hoặc bộ phận giúp ưu tiên việc thu hồi nợ, quản lý dòng tiền và đánh giá rủi ro tài chính. Vì sao điều này quan trọng Đo trực tiếp tác động tài chính của việc quy trình chậm trễ, đồng thời rất cần thiết để ưu tiên thu hồi nợ, quản lý dòng tiền và theo dõi khoản phải thu. Lấy dữ liệu ở đâu Đây là trường dữ liệu cốt lõi trong hồ sơ tài khoản bệnh nhân hoặc tài khoản bệnh viện (HAR) của Epic Resolute. Số dư được cập nhật liên tục theo các giao dịch tài chính. Ví dụ 1500.00250.750.00 | |||
| Có tự động hóa IsAutomated | Cờ đúng/sai cho biết hoạt động do hệ thống hoặc quy trình tự động thực hiện. | ||
| Mô tả Cờ này phân biệt tác vụ do hệ thống tự động thực hiện, chẳng hạn tạo yêu cầu thanh toán hoặc kiểm tra điều kiện hợp lệ tự động, với tác vụ do người dùng thực hiện thủ công. Phân tích thuộc tính này giúp bạn hiểu mức độ tự động hóa của quy trình. Bạn có thể so sánh hiệu quả và tỷ lệ lỗi giữa hoạt động tự động với hoạt động thủ công, tìm cơ hội tự động hóa thêm và theo dõi hiệu suất của bot hoặc quy tắc hệ thống hiện có. Vì sao điều này quan trọng Phân biệt hoạt động do hệ thống thực hiện với hoạt động do con người thực hiện. Đây là cơ sở để đánh giá tác động của tự động hóa và tìm cơ hội tự động hóa mới. Lấy dữ liệu ở đâu Thuộc tính này thường được xác định bằng cách kiểm tra xem “ResponsibleUser” của hoạt động có phải là tài khoản hệ thống hoặc tài khoản dịch vụ hay không, hoặc đánh dấu các tên hoạt động đã biết là tự động. Ví dụ truefalse | |||
| Hệ thống nguồn SourceSystem | Hệ thống thông tin nơi dữ liệu được tạo ra. | ||
| Mô tả Thuộc tính này xác định hệ thống nguồn của bản ghi, trong trường hợp này là Epic Resolute. Nếu có nhiều hệ thống được tích hợp, trường này giúp phân biệt nguồn dữ liệu. Dù có vẻ dư thừa khi chỉ xem dữ liệu từ một hệ thống, đây vẫn là cách làm tốt để quản trị dữ liệu và mở rộng về sau. Trường này giúp xác định rõ nguồn nếu sau này tích hợp dữ liệu từ hệ thống khác, chẳng hạn nền tảng riêng của đơn vị thu hồi nợ. Vì sao điều này quan trọng Cung cấp thông tin quan trọng về nguồn gốc và bối cảnh dữ liệu, giúp xác định rõ dữ liệu đến từ đâu. Điều này rất cần thiết cho việc quản trị dữ liệu và xử lý sự cố. Lấy dữ liệu ở đâu Đây thường là giá trị cố định được thêm trong quá trình trích xuất và chuyển đổi dữ liệu để ghi nhãn nguồn gốc của tập dữ liệu. Ví dụ Epic ResoluteEpicResolute_V2023 | |||
| ID bệnh nhân PatientId | Mã định danh duy nhất của bệnh nhân nhận dịch vụ. | ||
| Mô tả Thuộc tính này là Mã hồ sơ bệnh án (MRN) hoặc mã định danh duy nhất khác của bệnh nhân. Thuộc tính liên kết giao dịch lập hóa đơn với một cá nhân cụ thể. Để bảo vệ quyền riêng tư của bệnh nhân, thuộc tính này thường không được dùng làm chiều phân tích chính. Tuy vậy, thuộc tính rất cần thiết để xác thực dữ liệu và có thể dùng để tổng hợp mọi giao dịch lập hóa đơn của một bệnh nhân, qua đó hiểu rõ toàn bộ hành trình tài chính của họ. Thuộc tính này cũng quan trọng nếu cần tích hợp với dữ liệu quy trình lâm sàng. Vì sao điều này quan trọng Liên kết dữ liệu tài chính với một bệnh nhân cụ thể, hỗ trợ xác thực dữ liệu và mở rộng phân tích toàn bộ hành trình của bệnh nhân. Cần xử lý cẩn trọng để bảo vệ quyền riêng tư. Lấy dữ liệu ở đâu Mã định danh cơ bản có trong toàn bộ Epic, liên kết với hồ sơ đăng ký và tài khoản của bệnh nhân. Ví dụ MRN-1234567MRN-8765432MRN-5551234 | |||
| ID yêu cầu thanh toán ClaimId | Mã định danh duy nhất được gán cho yêu cầu thanh toán bảo hiểm gửi đến bên chi trả. | ||
| Mô tả Thuộc tính này là ID cụ thể của biểu mẫu yêu cầu thanh toán, chẳng hạn CMS-1500 hoặc UB-04, gửi đến bên chi trả. Một lần lập hóa đơn có thể liên quan đến nhiều yêu cầu nếu dịch vụ được lập hóa đơn lại hoặc kháng nghị. Theo dõi bằng ID yêu cầu thanh toán hữu ích khi phân tích chi tiết các quy trình gửi yêu cầu và xử lý từ chối. Thuộc tính này giúp phân biệt hoạt động của yêu cầu ban đầu với hoạt động của yêu cầu gửi lại sau đó cho cùng một dịch vụ. Vì sao điều này quan trọng Cung cấp mã định danh chi tiết để theo dõi vòng đời của từng yêu cầu thanh toán, rất cần thiết khi phân tích việc gửi lại và kháng nghị. Lấy dữ liệu ở đâu Được tạo khi yêu cầu thanh toán được lập trong mô-đun quản lý yêu cầu thanh toán của Epic Resolute và lưu trong các bảng dữ liệu yêu cầu thanh toán. Ví dụ CLM-2023-98765CLAIM-0012345623189A4567 | |||
| Lần cập nhật dữ liệu gần nhất LastDataUpdate | Dấu thời gian cho biết lần gần nhất dữ liệu của sự kiện này được làm mới hoặc trích xuất từ hệ thống nguồn. | ||
| Mô tả Thuộc tính này cho biết dữ liệu mới đến mức nào, tức thời điểm gần nhất bản ghi được lấy từ Epic Resolute vào tập dữ liệu process mining. Thông tin này giúp đánh giá mức độ cập nhật của phân tích và kiểm tra dữ liệu. Người dùng có thể biết mình đang xem thông tin mới nhất hiện có hay không, đồng thời theo dõi chu kỳ làm mới dữ liệu. Vì sao điều này quan trọng Giúp người dùng biết dữ liệu đang phân tích được cập nhật đến thời điểm nào. Đây là yếu tố quan trọng để đưa ra quyết định kinh doanh chính xác dựa trên thông tin mới nhất. Lấy dữ liệu ở đâu Dấu thời gian này được thêm trong quá trình ETL (trích xuất, chuyển đổi, tải) khi nạp dữ liệu. Ví dụ 2023-06-10T02:00:00Z2023-06-11T02:00:00Z | |||
| Ngày đến hạn thanh toán PaymentDueDate | Ngày dự kiến hoàn tất thanh toán cho dịch vụ đã lập hóa đơn. | ||
| Mô tả Thuộc tính này xác định hạn thanh toán ghi trên hóa đơn hoặc theo hợp đồng với bên chi trả. Đây là mốc để đo lường việc thanh toán đúng hạn. Ngày đến hạn thanh toán rất cần thiết để lập “Báo cáo tuổi nợ số dư chưa thanh toán”. So sánh ngày hiện tại với ngày đến hạn của các khoản còn mở sẽ giúp phân loại khoản phải thu theo thời gian quá hạn, chẳng hạn 0-30 ngày hoặc quá hạn 31-60 ngày. Nhờ đó, bạn có thể ưu tiên thu hồi các khoản quá hạn lâu nhất. Vì sao điều này quan trọng Là cơ sở để phân tích tuổi nợ phải thu, giúp ưu tiên thu hồi nợ và quản lý rủi ro tài chính từ các hóa đơn chưa thanh toán. Lấy dữ liệu ở đâu Ngày này thường được tính dựa trên ngày lập hóa đơn và điều khoản thanh toán lưu trong hợp đồng với bên chi trả hoặc thông tin tài khoản bệnh nhân trong Epic. Ví dụ 2023-05-302023-06-152023-07-01 | |||
| Số tiền điều chỉnh AdjustedAmount | Giá trị tiền tệ của một giao dịch điều chỉnh. | ||
| Mô tả Trường này ghi lại số tiền cụ thể của một khoản điều chỉnh tài khoản. Giá trị có thể dương hoặc âm, tương ứng với khoản ghi có hoặc ghi nợ vào số dư tài khoản. Đây là chỉ số chính cho dashboard “Tổng giá trị điều chỉnh tài khoản theo loại”. Cộng giá trị này theo lý do điều chỉnh sẽ cho thấy rõ tác động tài chính của từng loại điều chỉnh, chẳng hạn doanh thu bị xóa sổ do nghĩa vụ hợp đồng so với khoản thất thoát do lỗi có thể khắc phục. Vì sao điều này quan trọng Định lượng tác động tài chính của các khoản điều chỉnh tài khoản, giúp đo lường thất thoát doanh thu và chi phí do sai sót trong lập hóa đơn. Lấy dữ liệu ở đâu Nằm trong các bảng chi tiết giao dịch tài chính của Epic Resolute, gắn với các giao dịch thuộc loại điều chỉnh. Ví dụ -1250.45-50.0025.10 | |||
| Tên bên chi trả PayerName | Tên công ty bảo hiểm, cơ quan chính phủ hoặc bên khác 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 liên quan đến sự kiện thanh toán, chẳng hạn 'Blue Cross Blue Shield', 'Medicare' hoặc 'Aetna'. Nếu bệnh nhân tự thanh toán, thuộc tính này có thể ghi tên bệnh nhân. Phân nhóm quy trình theo bên chi trả là một cách phân tích hữu ích. Cách này có thể cho thấy một số bên chi trả có tỷ lệ từ chối cao hơn, chu kỳ thanh toán dài hơn hoặc yêu cầu phức tạp hơn. Từ đó, bạn có thể điều chỉnh cách thanh toán cho từng bên để nâng cao hiệu quả và đẩy nhanh việc nhận tiền. Vì sao điều này quan trọng Cho phép phân tích hiệu suất theo bên chi trả, làm rõ bên nào có tỷ lệ từ chối cao hoặc chu kỳ thanh toán chậm để bạn xây dựng cách theo dõi phù hợp. Lấy dữ liệu ở đâu Thông tin này nằm trong phần chi tiết bảo hiểm của bệnh nhân và được liên kết với tài khoản bệnh viện (HAR) trong Epic Resolute. Ví dụ Medicare Phần BUnitedHealthcareAetna PPO | |||
| Thời điểm kết thúc sự kiện EventEndTime | Dấu thời gian cho biết khi nào một hoạt động hoàn tất, hữu ích để tính thời lượng hoạt động. | ||
| Mô tả Thuộc tính này ghi lại thời điểm hoàn tất một hoạt động. Nhiều hoạt động diễn ra tức thời, khi StartTime bằng EndTime, nhưng một số tác vụ có thời lượng đo được, chẳng hạn cuộc gọi theo dõi yêu cầu thanh toán bị từ chối. Khi có dữ liệu EndTime, bạn có thể tính trực tiếp thời gian xử lý hoạt động bằng cách lấy “EndTime” trừ “StartTime”. Cách này chính xác hơn việc suy ra thời lượng từ thời điểm bắt đầu hoạt động tiếp theo, vì tính cả thời gian chờ giữa các bước. Đây là thành phần quan trọng để tính thuộc tính “ProcessingTime”. Vì sao điều này quan trọng Giúp tính chính xác thời gian hoàn tất từng hoạt động, từ đó xác định các tác vụ kém hiệu quả và đo năng suất sử dụng tài nguyên. Lấy dữ liệu ở đâu Dữ liệu này có thể có trong một số mô-đun Epic Resolute theo dõi thời điểm bắt đầu và kết thúc tác vụ, chẳng hạn nhật ký hàng đợi công việc hoặc quản lý hoạt động. Thông thường, dữ liệu này không được theo dõi riêng. Ví dụ 2023-04-15T09:45:00Z2023-04-16T11:15:30Z2023-05-01T14:02:00Z | |||
| Tổng thời gian chu kỳ doanh thu TotalRevenueCycleTime | Tổng thời lượng được tính từ sự kiện cung cấp dịch vụ đầu tiên đến lần thanh toán cuối cùng hoặc khi tài khoản được đóng. | ||
| Mô tả Đây là KPI ở cấp hồ sơ, đo tổng thời gian từ đầu đến cuối của chu kỳ doanh thu cho một lần lập hóa đơn. Thông thường, chỉ số được tính bằng khoảng thời gian từ hoạt động “Đã cung cấp dịch vụ” đến hoạt động “Đã nhận thanh toán” hoặc “Đã đóng tài khoản” cuối cùng. Chỉ số tổng quan này cho thấy hiệu quả chung của quy trình RCM. Theo dõi KPI theo thời gian giúp đo tác động của các sáng kiến cải tiến quy trình và cho biết tốc độ chuyển dịch vụ thành tiền mặt. Vì sao điều này quan trọng Cho thấy hiệu quả quy trình từ đầu đến cuối, đo trực tiếp thời gian chuyển một dịch vụ thành tiền mặt. Lấy dữ liệu ở đâu Chỉ số này được tính trong công cụ process mining bằng cách lọc sự kiện đầu tiên và cuối cùng của mỗi hồ sơ, rồi tính khoảng thời gian giữa hai sự kiện. Ví dụ 259200038880005184000 | |||
Các hoạt động trong quản lý chu kỳ doanh thu
| Hoạt động | Mô tả | ||
|---|---|---|---|
| Bên chi trả từ chối yêu cầu bồi thường | Sự kiện này ghi nhận thông báo từ bên chi trả rằng yêu cầu bồi thường đã bị từ chối. Thông tin được ghi lại khi Epic xử lý thông báo thanh toán điện tử (tệp 835) hoặc khi người dùng nhập khoản từ chối thủ công. | ||
| Vì sao điều này quan trọng Hoạt động này mở đầu một vòng xử lý lại quan trọng. Phân tích lý do và số lượng yêu cầu bị từ chối là điều cần thiết để tìm nguyên nhân gốc rễ, cải thiện tỷ lệ được thanh toán ngay lần đầu và giảm chậm trễ thu tiền. Lấy dữ liệu ở đâu Được ghi rõ dưới dạng giao dịch hoặc cập nhật trạng thái của yêu cầu bồi thường. Thông tin từ chối, bao gồm mã lý do, thường được nhận qua hệ thống điện tử và ghi vào tài khoản. Thu thập Lọc theo loại giao dịch cụ thể hoặc cập nhật trạng thái yêu cầu bồi thường cho biết yêu cầu bị từ chối. Loại sự kiện explicit | |||
| Đã đóng tài khoản | Đây là hoạt động cuối cùng, cho biết số dư còn nợ của sự kiện thanh toán đã về 0 và không còn hoạt động nào đang chờ xử lý. Tài khoản có thể được đóng sau khi thanh toán đầy đủ, điều chỉnh hoặc xóa nợ. | ||
| Vì sao điều này quan trọng Sự kiện này đánh dấu chu trình doanh thu của một sự kiện thanh toán đã hoàn tất thành công. Thời gian từ khi cung cấp dịch vụ đến khi đóng tài khoản là KPI quan trọng để đánh giá hiệu quả quy trình tổng thể. Lấy dữ liệu ở đâu Đây thường là sự kiện được suy ra. Xác định sự kiện bằng cách tìm thời điểm số dư tài khoản của sự kiện thanh toán về 0 và duy trì ở mức 0. Thu thập Suy ra bằng cách tính tổng số dư tài khoản lũy kế và xác định dấu thời gian của giao dịch cuối cùng đưa số dư về 0. Loại sự kiện inferred | |||
| Đã ghi nhận thanh toán vào tài khoản | Đây là thời điểm khoản thanh toán đã nhận được phân bổ cho các khoản thu cụ thể trên tài khoản bệnh nhân. Thao tác này làm giảm số dư còn nợ của sự kiện thanh toán. | ||
| Vì sao điều này quan trọng Ghi nhận thanh toán hiệu quả rất quan trọng để duy trì số dư tài khoản chính xác và hoàn tất các sự kiện thanh toán. Việc này giúp xác định đúng số dư còn lại để lập hóa đơn cho bên chi trả thứ cấp hoặc thu hồi nợ. Lấy dữ liệu ở đâu Đây là giao dịch được ghi rõ trong Resolute. Khi ghi nhận thanh toán, giao dịch thanh toán được liên kết với một hoặc nhiều giao dịch khoản thu và lưu trong các bảng chi tiết giao dịch. Thu thập Lấy bản ghi giao dịch phân bổ khoản thanh toán cho một khoản thu, có thể nhận diện bằng loại giao dịch cụ thể. Loại sự kiện explicit | |||
| Đã gửi yêu cầu bồi thường cho bên chi trả | Sự kiện này đánh dấu thời điểm yêu cầu bồi thường được gửi chính thức cho bên bảo hiểm để xét duyệt. Trong Epic, sự kiện được theo dõi và ghi lại khi tệp yêu cầu điện tử được truyền đến đơn vị trung gian xử lý hoặc bên chi trả. | ||
| Vì sao điều này quan trọng Đây là cột mốc quan trọng vì từ thời điểm này, thời hạn thanh toán của bên chi trả bắt đầu được tính. Phân tích mốc này giúp đo hiệu quả truyền yêu cầu và hỗ trợ KPI Thời gian gửi hóa đơn đến bên chi trả. Lấy dữ liệu ở đâu Đây là sự kiện được ghi rõ trong Resolute. Hồ sơ yêu cầu bồi thường có trạng thái gửi và dấu thời gian cho biết thời điểm yêu cầu được gửi. Thu thập Lấy dấu thời gian khi trạng thái yêu cầu bồi thường chuyển thành 'Submitted' hoặc 'Transmitted'. Loại sự kiện explicit | |||
| Đã nhận thanh toán | Sự kiện này ghi nhận khoản thanh toán nhận từ bên chi trả hoặc bệnh nhân. Thông tin thường được ghi lại khi nạp thông báo thanh toán điện tử (ERA) hoặc nhập séc thủ công vào hệ thống. | ||
| Vì sao điều này quan trọng Hoạt động này là cột mốc quan trọng, cho biết doanh thu đang về. Thời gian từ lúc gửi yêu cầu bồi thường đến khi nhận thanh toán là thước đo quan trọng về hiệu quả khoản phải thu. Lấy dữ liệu ở đâu Được ghi rõ thành giao dịch thanh toán trong Resolute. Giao dịch có ngày, nguồn và số tiền, thường được ghi lại trước khi phân bổ đầy đủ vào từng khoản thu. Thu thập Lấy giao dịch thanh toán từ nhật ký giao dịch tài chính, thường nhận diện bằng loại giao dịch cụ thể. Loại sự kiện explicit | |||
| Dịch vụ được cung cấp | Hoạt động này đánh dấu thời điểm dịch vụ lâm sàng được cung cấp cho bệnh nhân, từ đó phát sinh sự kiện thanh toán. Thông tin thường được ghi nhận trong Epic EHR (EpicCare) khi nhân viên lâm sàng xác nhận lượt khám hoặc thủ thuật. | ||
| Vì sao điều này quan trọng Đây là sự kiện bắt đầu chính của chu trình doanh thu. Phân tích khoảng thời gian từ lúc này đến khi ghi nhận khoản thu rất quan trọng để phát hiện chậm trễ khi bắt đầu thanh toán và nguy cơ thất thoát doanh thu. Lấy dữ liệu ở đâu Sự kiện này thường được suy ra từ dấu thời gian của dịch vụ hoặc lượt khám trong các phân hệ lâm sàng được liên kết với tài khoản thanh toán. Ngày cung cấp dịch vụ trên giao dịch khoản thu là dữ liệu then chốt. Thu thập Suy ra từ ngày cung cấp dịch vụ gắn với giao dịch khoản thu đầu tiên của sự kiện thanh toán. Loại sự kiện inferred | |||
| Khoản thu đã được ghi nhận | Đây là bước ghi nhận chính thức các khoản thu có thể lập hóa đơn cho dịch vụ đã cung cấp. Trong Epic, khoản thu thường được ghi thành giao dịch cụ thể trên tài khoản bệnh nhân, có thể tự động tạo từ hoạt động lâm sàng hoặc được nhập thủ công. | ||
| Vì sao điều này quan trọng Đây là cột mốc đầu tiên rất quan trọng. Đo tốc độ và độ chính xác khi ghi nhận khoản thu giúp đẩy nhanh quy trình thanh toán và đảm bảo mọi dịch vụ đã cung cấp đều được lập hóa đơn. Lấy dữ liệu ở đâu Được ghi rõ trong nhật ký giao dịch của Resolute. Mỗi khoản thu là một mục riêng, có ngày ghi sổ, ngày cung cấp dịch vụ và số tiền. Thông tin thường nằm trong các bảng như ARPB_TRANSACTIONS. Thu thập Lấy các giao dịch ghi nhận khoản thu từ nhật ký giao dịch tài chính của hệ thống. Loại sự kiện explicit | |||
| Bắt đầu theo dõi yêu cầu bị từ chối | Hoạt động này đánh dấu thời điểm bắt đầu quy trình nội bộ để xem xét và xử lý yêu cầu bồi thường bị từ chối. Thông tin thường được ghi lại khi người dùng nhận xử lý yêu cầu trong hàng đợi công việc hoặc thay đổi trạng thái của yêu cầu. | ||
| Vì sao điều này quan trọng Theo dõi bước này giúp đo mức độ phản hồi của nhóm xử lý yêu cầu bị từ chối. Nếu việc theo dõi bắt đầu chậm sau khi yêu cầu bị từ chối, chu trình doanh thu có thể kéo dài không cần thiết. Lấy dữ liệu ở đâu Sự kiện này thường được suy ra từ thay đổi trạng thái hoặc lịch sử phân công yêu cầu trong hàng đợi công việc của Epic. Ví dụ, trạng thái yêu cầu có thể chuyển từ 'Denied' sang 'In Review'. Thu thập Suy ra từ thay đổi trạng thái yêu cầu hoặc mục nhật ký kiểm tra cho thấy người dùng đã bắt đầu xử lý yêu cầu bị từ chối. Loại sự kiện inferred | |||
| Chuyển số dư sang thu hồi nợ | Mốc này đánh dấu thời điểm số dư chưa thanh toán được chuyển sang quy trình thu hồi nợ nội bộ hoặc bên ngoài. Thường đây là thay đổi trạng thái cụ thể trên tài khoản hoặc sự kiện thanh toán. | ||
| Vì sao điều này quan trọng Hoạt động này mở đầu giai đoạn cuối của việc thu hồi số dư chưa thanh toán. Theo dõi tỷ lệ thành công và thời gian xử lý của quy trình thu hồi nợ là điều cần thiết để giảm nợ khó đòi. Lấy dữ liệu ở đâu Đây thường là sự kiện được ghi rõ. Epic có chức năng chuyển tài khoản cho đơn vị thu hồi nợ, tạo mục nhật ký hoặc thay đổi trạng thái trên tài khoản. Thu thập Tìm thay đổi trạng thái hoặc giao dịch cho biết tài khoản đã được chuyển cho đơn vị thu hồi nợ. Loại sự kiện explicit | |||
| Đã điều chỉnh tài khoản | Hoạt động này ghi nhận giao dịch không phải thanh toán làm thay đổi số dư tài khoản, chẳng hạn điều chỉnh theo hợp đồng, xóa khoản dư nhỏ hoặc giảm giá thiện chí. Giao dịch được lưu với một loại cụ thể. | ||
| Vì sao điều này quan trọng Phân tích các khoản điều chỉnh là bước quan trọng để phát hiện thất thoát doanh thu. Số lượng lớn một số loại điều chỉnh có thể cho thấy vấn đề về biểu phí, hợp đồng hoặc chính sách nội bộ. Lấy dữ liệu ở đâu Được ghi rõ thành giao dịch điều chỉnh trong nhật ký tài chính của Resolute. Mỗi khoản điều chỉnh có loại hoặc mã lý do cụ thể. Thu thập Lọc các loại giao dịch tương ứng với điều chỉnh tài chính hoặc xóa nợ. Loại sự kiện explicit | |||
| Đã gửi lại yêu cầu bồi thường | Sự kiện này xảy ra sau khi yêu cầu bồi thường bị từ chối đã được chỉnh sửa và gửi lại cho bên chi trả. Đây là lần gửi riêng, được liên kết với yêu cầu ban đầu. | ||
| Vì sao điều này quan trọng Đây là bước quan trọng trong vòng xử lý lại. Đo thời gian gửi lại và tỷ lệ thành công của các yêu cầu được gửi lại là điều cần thiết để đánh giá hiệu quả xử lý yêu cầu bị từ chối. Lấy dữ liệu ở đâu Đây là sự kiện được ghi rõ, tương tự lần gửi đầu tiên nhưng thường được đánh dấu là gửi lại. Hồ sơ yêu cầu sẽ có dấu thời gian gửi mới và có thể kèm mã gửi lại. Thu thập Lấy dấu thời gian của lần gửi yêu cầu bồi thường được đánh dấu là đã chỉnh sửa hoặc gửi lại. Loại sự kiện explicit | |||
| Đã tạo yêu cầu bồi thường | Hoạt động này đánh dấu thời điểm hệ thống tạo yêu cầu bồi thường hoặc hóa đơn chính thức dựa trên các khoản thu đã ghi nhận. Đây là bước chuẩn bị trước khi gửi yêu cầu cho bên chi trả hoặc bệnh nhân. | ||
| Vì sao điều này quan trọng Theo dõi thời điểm tạo yêu cầu bồi thường giúp xác định độ trễ giữa lúc ghi nhận khoản thu và lúc chuẩn bị gửi yêu cầu. Đây là bước nội bộ quan trọng, có thể ảnh hưởng đến thời gian thanh toán tổng thể. Lấy dữ liệu ở đâu Sự kiện này thường được ghi lại khi một tác vụ theo lô tạo hóa đơn hoặc yêu cầu bồi thường chạy. Hệ thống sẽ ghi dấu thời gian khi tạo tệp yêu cầu bồi thường, chẳng hạn tệp 837, cho một tài khoản. Thu thập Tìm các mục nhật ký hoặc thay đổi trạng thái cho biết yêu cầu bồi thường đã được tổng hợp và sẵn sàng gửi. Loại sự kiện explicit | |||
Hướng dẫn trích xuất dữ liệu
Các bước
- Thiết lập kết nối cơ sở dữ liệu: Lấy thông tin đăng nhập chỉ có quyền đọc cho cơ sở dữ liệu Epic Clarity. Dùng ứng dụng SQL tiêu chuẩn như DBeaver hoặc Microsoft SQL Server Management Studio để kết nối với máy chủ cơ sở dữ liệu.
- Xác định các bảng chính: Các bảng chính cần trích xuất gồm
HSP_ACCOUNTđể lấy thông tin hồ sơ,HSP_TRANSACTIONSđể lấy sự kiện tài chính,CLP_CLAIM_INFOđể lấy trạng thái yêu cầu thanh toán vàF_ARHB_TX_SET_POST_HXđể lấy chi tiết ghi nhận thanh toán. Bạn cũng cần kết hợp với các tệp dữ liệu chính nhưCLARITY_EMPđể lấy thông tin người dùng. - Xác định phạm vi: Trước khi viết truy vấn, hãy xác định phạm vi phân tích. Chọn khoảng thời gian cụ thể, thường là 3 đến 6 tháng, và xác định khu vực dịch vụ bệnh viện (
SERV_AREA_ID) hoặc nhóm tài khoản cần đưa vào hay loại trừ. - Viết truy vấn SQL: Tạo truy vấn SQL dùng Common Table Expression (CTE) để trước tiên chọn các giá trị
HSP_ACCOUNT_IDthuộc phạm vi đã xác định. Đây sẽ là tập dữ liệu cơ sở gồm các lần lập hóa đơn. - Kết hợp truy vấn cho từng hoạt động: Với mỗi hoạt động trong số 12 hoạt động bắt buộc, viết một câu lệnh
SELECTriêng để lấy dữ liệu từ các bảng liên quan. Kết hợp lại với CTE ban đầu để chỉ phân tích các tài khoản đã chọn. - Gộp truy vấn bằng UNION ALL: Dùng toán tử
UNION ALLđể gộp kết quả của từng truy vấn hoạt động thành một event log thống nhất. Các hàng từ mỗi truy vấn sẽ được xếp nối tiếp nhau. - Ánh xạ sang lược đồ chuẩn: Trong mỗi câu lệnh
SELECT, đặt bí danh cho các cột để khớp với lược đồ ProcessMind yêu cầu, chẳng hạnBillingEvent,ActivityName,EventTimestamp,ResponsibleUser. DùngNULLcho các thuộc tính không áp dụng với hoạt động cụ thể. - Chạy và tinh chỉnh truy vấn: Chạy toàn bộ truy vấn trên cơ sở dữ liệu Clarity. Do các bảng có thể rất lớn, quá trình này có thể mất nhiều thời gian. Nếu hiệu suất không đạt yêu cầu, hãy thu hẹp khoảng thời gian hoặc thêm bộ lọc cụ thể hơn trong CTE ban đầu.
- Kiểm tra kết quả: Khi truy vấn chạy xong, kiểm tra vài trăm hàng đầu tiên. Xác nhận có đủ các cột, dấu thời gian dùng định dạng nhất quán và các giá trị
ActivityNamexuất hiện như dự kiến. - Xuất sang CSV: Xuất toàn bộ kết quả từ ứng dụng SQL sang tệp CSV. Đảm bảo tệp dùng mã hóa UTF-8 và có hàng tiêu đề với tên cột chính xác.
- Chuẩn bị tải lên: Trước khi tải lên ProcessMind, mở tệp CSV để kiểm tra lỗi định dạng. Xác nhận dấu thời gian nhất quán, chẳng hạn
YYYY-MM-DD HH:MI:SS. Sau đó, tệp đã sẵn sàng để nhập vào hệ thống.
Cấu hình
- Kết nối cơ sở dữ liệu: Cần có tài khoản người dùng chỉ có quyền đọc và được cấp quyền truy cập cơ sở dữ liệu Epic Clarity.
- Tham số khoảng thời gian: Truy vấn được cung cấp dùng các biến
@StartDatevà@EndDate. Bạn cần đặt giá trị cho hai biến này để xác định kỳ phân tích. Nên chọn khoảng thời gian từ 3 đến 6 tháng để cân bằng giữa khối lượng dữ liệu và hiệu suất. - Ánh xạ bảng và cột: Truy vấn giả định tên bảng và cột Clarity theo chuẩn. Cấu hình hoặc phiên bản Epic của tổ chức bạn có thể khác. Bạn có thể cần điều chỉnh tên bảng, tên cột hoặc điều kiện kết hợp cho phù hợp.
- Mã giao dịch và trạng thái: Truy vấn có các chỗ giữ chỗ như
[Your Denial Tx Type]và[Your Collections Status Code]. Hãy hỏi quản trị viên hệ thống Epic hoặc kiểm tra các tệp dữ liệu chính liên quan, chẳng hạnZC_TX_TYPEhoặcZC_ACCOUNT_STATUS, để tìm mã phù hợp với hệ thống của bạn. - Bộ lọc: Để truy vấn chạy nhanh hơn và tập trung vào phạm vi cần phân tích, hãy thêm bộ lọc vào CTE
BaseAccountsban đầu. Các bộ lọc thường dùng gồmSERV_AREA_IDđể giới hạn theo khu vực dịch vụ bệnh viện hoặcACCOUNT_CLASS_Cđể tập trung vào hóa đơn nội trú hoặc ngoại trú.
Truy vấn mẫu 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; Các bước
- Xác nhận bạn có quyền truy cập được phê duyệt vào tập dữ liệu chu kỳ doanh thu của Epic Clarity, bao gồm các bảng và khung nhìn nguồn cần thiết để lấy lịch sử tài khoản, khoản phí, yêu cầu thanh toán, từ chối, thanh toán, điều chỉnh, thu hồi và đóng tài khoản. Các tổ chức dùng Epic có thể khác nhau về bảng sẵn có và cách đặt tên cột. Hãy ánh xạ từng chỗ giữ chỗ trong truy vấn với đối tượng Clarity tương ứng trong môi trường của bạn.
- Xác định kỳ trích xuất bằng [Start date parameter] và [End date parameter]. Ban đầu, hãy dùng khoảng thời gian từ ba đến sáu tháng. Chỉ kéo dài kỳ sau khi đã kiểm tra hiệu suất truy vấn và tính đầy đủ của sự kiện.
- Thiết lập ánh xạ BillingEvent. Theo mặc định, truy vấn dùng HSP_ACCOUNT.HSP_ACCOUNT_ID làm mã định danh hồ sơ nếu có. Nếu tổ chức xác định một lần lập hóa đơn ở cấp khoản phí, yêu cầu thanh toán hoặc lần khám, hãy thay ánh xạ bằng mã định danh đã được phê duyệt và dùng nhất quán mã đó cho mọi nguồn hoạt động.
- Ánh xạ từng hoạt động nguồn với dấu thời gian có thẩm quyền và thuộc tính nguồn tương ứng. Với Service Rendered, dùng dấu thời gian hoàn tất dịch vụ hoặc lần khám đã được ghi nhận. Với Charges Captured, dùng dấu thời gian ghi nhận khoản phí. Với Claim Generated và Claim Submitted to Payer, dùng dấu thời gian tương ứng trong vòng đời yêu cầu thanh toán. Các hoạt động từ chối, theo dõi, gửi lại, thanh toán, điều chỉnh, thu hồi và đóng tài khoản cần dùng dấu thời gian giao dịch hoặc trạng thái đã được ghi nhận.
- Thay mọi chỗ giữ chỗ nguồn trong ngoặc vuông của truy vấn, gồm [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] và [Your account closure source table]. Không thay bằng mã giao dịch chưa được xác nhận. Hãy dùng giá trị giao dịch hoặc trạng thái đã được nhóm báo cáo Epic của bạn phê duyệt.
- Chạy truy vấn trong ứng dụng SQL hoặc nền tảng báo cáo được tổ chức phê duyệt. Xác nhận cả mười hai nhãn hoạt động đều được trả về thành các hàng riêng. ProcessMind không suy ra sự kiện vòng đời bị thiếu từ số dư, trạng thái hoặc thứ tự sự kiện.
- Kiểm tra lược đồ kết quả. Kết quả phải có BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance và ServiceType. Giữ lại thông tin múi giờ hoặc giờ địa phương của dấu thời gian. Nếu được phép, lưu các mã định danh nguồn trong một bản trích xuất phục vụ kiểm tra nội bộ.
- Xác thực thứ tự thời gian trong từng BillingEvent, cách xử lý sự kiện trùng lặp, tỷ lệ giá trị rỗng, số lượng hoạt động và đối chiếu với báo cáo hệ thống nguồn. Kiểm tra các sự kiện nằm ngoài kỳ yêu cầu nhưng cần thiết để hiểu hồ sơ bắt đầu trước hoặc kết thúc sau kỳ đó.
- Xuất kết quả thành tệp phân tách bằng dấu phân cách hoặc dùng kết nối cơ sở dữ liệu được ProcessMind hỗ trợ. Mỗi hàng tương ứng với một sự kiện. Dùng tên cột ổn định, định dạng dấu thời gian nhất quán, mã hóa UTF-8 và không gộp ô hay thêm dòng tổng hợp để trình bày. Khi tải lên, đặt BillingEvent làm mã định danh hồ sơ, ActivityName làm hoạt động và EventTimestamp làm dấu thời gian sự kiện.
Cấu hình
- Ánh xạ nguồn: Cấu hình Epic Clarity khác nhau giữa các tổ chức. Thay từng chỗ giữ chỗ cho đối tượng và cột nguồn trong ngoặc vuông bằng bảng, khung nhìn hoặc lớp báo cáo đã được phê duyệt và ghi nhận trong môi trường của bạn. Đừng mặc định rằng bảng hoặc trường có tồn tại chỉ vì chúng thường dùng trong một cấu hình Epic khác.
- Mã định danh hồ sơ: Truy vấn mặc định dùng HSP_ACCOUNT.HSP_ACCOUNT_ID. Xác nhận tổ chức định nghĩa BillingEvent là tài khoản, lần khám, yêu cầu thanh toán, khoản phí hay khóa nghiệp vụ khác đã được phê duyệt.
- Khoảng thời gian: Bắt đầu với ba đến sáu tháng. Thêm khoảng thời gian nhìn lại nếu hồ sơ có thể bắt đầu trước kỳ báo cáo, và thêm khoảng thời gian theo dõi nếu yêu cầu thanh toán, từ chối, thanh toán hoặc đóng tài khoản có thể xảy ra sau ngày cung cấp dịch vụ.
- Dấu thời gian hoạt động: Chọn một dấu thời gian có thẩm quyền cho mỗi hoạt động. Tránh dùng thời điểm trích xuất, thời điểm tải tệp hoặc thời điểm trạng thái hiện tại thay cho thời điểm sự kiện nghiệp vụ thực tế, trừ khi đó là dấu thời gian sự kiện được hệ thống nguồn ghi nhận.
- Bộ lọc: Chỉ áp dụng các bộ lọc [Company Code filter], [Document Type filter], [Department filter], bên chi trả, khu vực dịch vụ và nhóm tài khoản khi định nghĩa của chúng đã được ghi nhận và cần thiết cho phân tích. Dùng bộ lọc nhất quán trong mọi nhánh
UNION ALL. - Ánh xạ giao dịch và trạng thái: Cấu hình các giá trị đã được tổ chức phê duyệt cho việc ghi nhận khoản phí, tạo yêu cầu thanh toán, gửi yêu cầu thanh toán, từ chối, theo dõi, gửi lại, nhận thanh toán, ghi nhận thanh toán, điều chỉnh, thu hồi và đóng tài khoản. Truy vấn cố ý dùng chỗ giữ chỗ vì giá trị giao dịch và cấu trúc nguồn Epic khác nhau tùy cấu hình.
- Xử lý giá trị rỗng: Giữ
NULLcho các thuộc tính không áp dụng với hoạt động. Không tự điền giá trị cho lý do từ chối, lý do điều chỉnh, người dùng, khoa hoặc loại dịch vụ bị thiếu. - Hiệu suất: Giới hạn hàng nguồn bằng các cột ngày có chỉ mục và bộ lọc tổ chức đã được phê duyệt trước khi kết hợp với HSP_ACCOUNT. Tránh dùng hàm trên cột dấu thời gian có chỉ mục trong điều kiện lọc. Nếu dữ liệu lịch sử thô quá lớn, hãy cân nhắc tạo khung nhìn báo cáo đã được phê duyệt cho từng hoạt động nguồn.
- Loại trùng: Không xóa sự kiện trùng lặp nếu chưa có quy tắc được ghi nhận. Nhiều lần thanh toán, điều chỉnh, gửi yêu cầu hoặc thay đổi trạng thái có thể là các sự kiện hợp lệ của cùng một BillingEvent.
- Điều kiện cần có: Có thể cần quyền báo cáo Epic Clarity, quyền truy cập dữ liệu chu kỳ doanh thu và lịch sử tài khoản, môi trường chạy SQL được phê duyệt và sự chấp thuận của tổ chức khi xử lý thông tin sức khỏe được bảo vệ. Việc có dữ liệu lịch sử yêu cầu thanh toán, giải trình thanh toán, hàng đợi công việc, thu hồi và đóng tài khoản hay không còn tùy thuộc vào các mô-đun và giao diện Epic đã được cấp phép và triển khai.
Truy vấn mẫu 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; Bạn đã sẵn sàng bắt đầu chưa?
Dữ liệu chính xác giúp bạn khai thác tốt hơn quy trình quản lý chu kỳ doanh thu. Bắt đầu cải thiện hiệu quả và kết quả tài chính ngay hôm nay.
Nâng cao hiệu quả: tối ưu quản lý chu kỳ doanh thu ngay hôm nay
Xác định điểm kém hiệu quả trong RCM của Epic Resolute, giảm 30% thời gian chu kỳ.
Không cần thẻ tín dụng. Bắt đầu tối ưu ngay hôm nay.