Mẫu dữ liệu quản lý chu kỳ doanh thu

Epic Resolute
Mẫu dữ liệu quản lý chu kỳ doanh thu

Mẫu dữ liệu quản lý chu kỳ doanh thu

Mẫu này hướng dẫn bạn thu thập dữ liệu cần thiết để tối ưu quy trình quản lý chu kỳ doanh thu. Mẫu nêu các thuộc tính dữ liệu thiết yếu, hoạt động chính cần theo dõi và cách trích xuất thông tin từ hệ thống nguồn. Hãy dùng tài nguyên này để bảo đảm bạn có đủ dữ liệu cần thiết cho việc phân tích và cải tiến quy trình.
  • 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
Chưa quen với nhật ký sự kiện? Tìm hiểu cách tạo nhật ký sự kiện cho process mining.

Các thuộc tính trong quản lý chu kỳ doanh thu

Đây là các trường dữ liệu nên có trong event log để phân tích và tối ưu quy trình quản lý chu kỳ doanh thu.
3 Bắt buộc 6 Nên có 10 Không bắt buộc
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
Bắt buộc Nên có Không bắt buộc

Các hoạt động trong quản lý chu kỳ doanh thu

Đây là các bước và mốc chính cần ghi lại trong event log để khám phá quy trình và đo lường hiệu suất chính xác.
7 Nên có 5 Không bắt buộc
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
Nên có Không bắt buộc

Hướng dẫn trích xuất dữ liệu

Cách lấy dữ liệu từ Epic Resolute

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ỳ.

Bắt đầu dùng thử miễn phí

Không cần thẻ tín dụng. Bắt đầu tối ưu ngay hôm nay.