> Cải tiến quy trình liên tục > Quản lý chu trình doanh thu > Chu trình doanh thu Oracle Health > Mẫu dữ liệu

Mẫu dữ liệu quản lý chu trình doanh thu

Chu trình doanh thu Oracle Health

Thuộc tính quản lý chu trình doanh thu(19) Hoạt động trong quy trình quản lý chu trình doanh thu(14) Hướng dẫn trích xuất dữ liệu(1)

Mẫu dữ liệu quản lý chu trình doanh thu

Mẫu này hướng dẫn bạn thu thập dữ liệu phù hợp để phân tích quy trình quản lý chu trình doanh thu. Mẫu liệt kê các trường dữ liệu thiết yếu và những bước chính cần có để tạo nhật ký sự kiện chính xác. Làm theo hướng dẫn này sẽ giúp bạn sắp xếp dữ liệu đúng cấu trúc cho process mining.

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 từ Oracle Health Revenue Cycle

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.

Tải mẫu xuống

Thuộc tính quản lý chu trình doanh thu

Đây là những trường dữ liệu thiết yếu cần có trong nhật ký sự kiện để phân tích quy trình quản lý chu trình doanh thu một cách đầy đủ và hữu ích.

3 Bắt buộc 7 Nên có 9 Không bắt buộc

	Tên	Mô tả
	Billing Event 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 phí. Mã này dùng làm mã hồ sơ cho quy trình chu kỳ doanh thu.
Mô tả Billing Event là mã trường hợp chính, liên kết mọi hoạt động từ ghi nhận khoản phí đến đóng tài khoản cho một khoản mục tính phí riêng biệt. Mỗi Billing Event đại diện cho một trường hợp duy nhất trong quy trình chu kỳ doanh thu, giúp theo dõi xuyên suốt các giai đoạn như gửi yêu cầu thanh toán, ghi nhận thanh toán và các trường hợp bị từ chối hoặc điều chỉnh. Trong phân tích process mining, thuộc tính này là nền tảng để dựng lại luồng quy trình từ đầu đến cuối. Thuộc tính giúp trực quan hóa các biến thể quy trình, tính thời gian xử lý giữa các hoạt động và xác định điểm nghẽn hoặc sai lệch gắn với từng sự kiện tính phí. Vì sao điều này quan trọng Đây là khóa thiết yếu để theo dõi toàn bộ vòng đời của một dịch vụ tính phí, đồng thời hỗ trợ phân tích luồng quy trình và đo lường hiệu suất. Lấy dữ liệu ở đâu Mã định danh này cần là khóa duy nhất có trong các bảng giao dịch thanh toán hoặc khoản phí cốt lõi của Oracle Health Revenue Cycle. Hãy tham khảo tài liệu hệ thống để xác định khóa chính cho các sự kiện khoản phí. Ví dụ BEVNT-987654321BEVNT-987654322BEVNT-987654323
	Dấu thời gian sự kiện EventTimestamp	Ngày giờ chính xác khi một hoạt động được ghi nhận trong hệ thống.
Mô tả Thuộc tính này ghi dấu thời gian của từng hoạt động, cho biết chính xác thời điểm hoạt động diễn ra. Đây là dữ liệu thiết yếu để hiểu thời điểm và thứ tự sự kiện trong chu trình doanh thu của một sự kiện lập hóa đơn cụ thể. Trong phân tích, Dấu thời gian sự kiện được dùng để sắp xếp hoạt động theo trình tự thời gian, tính thời lượng và thời gian xử lý giữa các bước, đồng thời phân tích điểm nghẽn. Đây là cơ sở cho mọi chỉ số process mining dựa trên thời gian, chẳng hạn xác định độ trễ giữa 'Đã gửi yêu cầu thanh toán' và 'Đã nhận thông báo thanh toán'. Vì sao điều này quan trọng Dấu thời gian này rất quan trọng để sắp xếp sự kiện, tính các chỉ số hiệu suất như thời gian chu kỳ và thời lượng, cũng như xác định điểm nghẽn trong quy trình. Lấy dữ liệu ở đâu Mỗi bảng giao dịch hoặc nhật ký sự kiện trong Oracle Health Revenue Cycle cần có cột dấu thời gian cho biết thời điểm tạo bản ghi hoặc thời điểm sự kiện diễn ra. Ví dụ 2023-04-15T09:00:00Z2023-04-18T14:30:00Z2023-05-02T11:25:10Z
	Tên hoạt động ActivityName	Tên của bước hoặc sự kiện cụ thể đã diễn ra trong quy trình chu kỳ doanh thu.
Mô tả Thuộc tính này ghi lại tên từng hoạt động trong vòng đời của một sự kiện lập hóa đơn. Ví dụ: 'Đã ghi nhận khoản phí', 'Đã gửi yêu cầu thanh toán cho bên chi trả' và 'Đã ghi nhận thanh toán'. Các hoạt động này tạo thành những nút trên sơ đồ quy trình được khám phá. Phân tích thứ tự và tần suất hoạt động là trọng tâm của process mining. Thuộc tính này giúp xác định các luồng quy trình phổ biến nhất, phát hiện sai lệch so với quy trình chuẩn và hiểu rõ cách chu kỳ doanh thu vận hành. 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 và phân tích các mẫu quy trình làm việc. 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 các bảng giao dịch cụ thể gắn với những giai đoạn khác nhau của chu kỳ doanh thu trong Oracle Health. Ví dụ Tạo yêu cầu thanh toánNhận thông báo thanh toánKhiếu nại quyết định từ chốiĐóng tài khoản
	Bộ phận thanh toán BillingDepartment	Bộ phận 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 bộ phận thực hiện hoạt động, chẳng hạn 'Ghi nhận khoản phí', 'Mã hóa' hoặc 'Thu hồi công nợ'. Nhờ đó, bạn có thêm bối cảnh về cơ cấu tổ chức trong luồng quy trình. Xem quy trình theo từng bộ phận là việc cần thiết để hiểu các lần bàn giao giữa các nhóm và xác định điểm kém hiệu quả giữa các bộ phận. Thuộc tính này hỗ trợ bảng điều khiển 'Khối lượng công việc của bộ phận thanh toán', cho phép tổng hợp hoạt động và chỉ số hiệu suất theo từng bộ phận. Vì sao điều này quan trọng Gắn hoạt động với các đơn vị trong tổ chức, giúp phân tích việc bàn giao giữa các bộ phận, khối lượng công việc và hiệu suất của nhóm. Lấy dữ liệu ở đâu Thông tin này có thể được lưu trực tiếp trong hồ sơ người dùng của Oracle Health hoặc suy ra từ người dùng hay loại hoạt động. Ví dụ Tiếp nhận bệnh nhânMã hóaThanh toánThu hồi công nợ
	Mã lý do từ chối yêu cầu thanh toán DenialReasonCode	Mã chuẩn cho biết bên chi trả từ chối yêu cầu thanh toán vì lý do gì.
Mô tả Khi từ chối yêu cầu thanh toán, bên chi trả cung cấp mã lý do, chẳng hạn như 'Dịch vụ không được bảo hiểm' hoặc 'Yêu cầu thanh toán trùng lặp'. Thuộc tính này ghi nhận mã cùng phần mô tả tương ứng. Phân tích lý do từ chối là bước thiết yếu để cải thiện chu kỳ doanh thu. Qua đó, tổ chức có thể nhận diện các vấn đề thường gặp, như lỗi mã hóa hoặc điều kiện đủ của bệnh nhân, rồi thực hiện biện pháp khắc phục để ngăn các lần từ chối sau. Việc này tác động trực tiếp đến tỷ lệ yêu cầu thanh toán hợp lệ ngay lần đầu và giảm chi phí làm lại. Vì sao điều này quan trọng Cho biết nguyên nhân gốc rễ khiến yêu cầu thanh toán bị từ chối, giúp cải thiện đúng trọng tâm để tăng tỷ lệ yêu cầu hợp lệ ngay lần đầu và đẩy nhanh thu doanh thu. 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 ANSI 835) và cần được lưu trong các bảng yêu cầu thanh toán hoặc thông báo thanh toán của Oracle Health. Ví dụ CO-16: Yêu cầu thanh toán/dịch vụ thiếu thông tin cần thiết để xét duyệt.PR-96: Khoản phí không được bảo hiểm.CO-18: Yêu cầu thanh toán/dịch vụ trùng lặp.
	Người dùng UserPerformingAction	Mã người dùng hoặc tên người thực hiện hoạt động.
Mô tả Thuộc tính này xác định nhân viên hoặc tài khoản hệ thống tự động chịu trách nhiệm thực hiện một hoạt động cụ thể trong quy trình. Đây là thông tin quan trọng để hiểu cách phân bổ khối lượng công việc, hiệu suất của tài nguyên và nhu cầu đào tạo. Trong phân tích, thuộc tính này cho phép lọc sơ đồ quy trình theo người dùng hoặc nhóm, so sánh hiệu suất giữa các tài nguyên và phân tích khối lượng công việc trên bảng điều khiển 'Khối lượng công việc của bộ phận thanh toán'. Thuộc tính cũng giúp xác định người có hiệu suất cao hoặc người cần được hỗ trợ hay đào tạo thêm. Vì sao điều này quan trọng Liên kết hoạt động trong quy trình với người dùng hoặc nhóm cụ thể, giúp phân tích khối lượng công việc, so sánh hiệu suất và xác định nhu cầu đào tạo. Lấy dữ liệu ở đâu Các trường mã người dùng, chẳng hạn 'CREATED_BY' và 'USER_ID', thường có trong các bảng giao dịch thuộc các mô-đun Oracle Health. Ví dụ j.doeasmithBillingBot_AUTOk.williams
	Nhóm bệnh nhân PatientClass	Phân loại lượt khám của bệnh nhân, chẳng hạn nội trú hoặc ngoại trú.
Mô tả Thuộc tính này phân loại loại lượt khám hoặc lần tiếp nhận của bệnh nhân làm phát sinh khoản phí. Các nhóm phổ biến gồm nội trú, ngoại trú, cấp cứu và khám định kỳ. Nhóm bệnh nhân thường quyết định toàn bộ quy trình thanh toán và gửi yêu cầu thanh toán. Mỗi nhóm bệnh nhân có đường đi quy trình và yêu cầu tuân thủ riêng. Phân tích quy trình theo thuộc tính này giúp bạn hiểu những khác biệt đó, điều chỉnh các sáng kiến cải tiến và bảo đảm áp dụng đúng quy trình cho từng nhóm. Vì sao điều này quan trọng Tách riêng các luồng quy trình khác nhau, chẳng hạn nội trú và ngoại trú, vốn có mức độ phức tạp, thời gian xử lý và yêu cầu thanh toán khác nhau. Lấy dữ liệu ở đâu Đây là trường tiêu chuẩn gắn với lượt khám hoặc hồ sơ nhập viện của bệnh nhân trong Oracle Health. Ví dụ Nội trúNgoại trúCấp cứuĐịnh kỳ
	Số dư chưa thanh toán OutstandingBalance	Số tiền còn nợ của giao dịch lập hóa đơn tại một thời điểm nhất định.
Mô tả Thuộc tính này cho biết số tiền hiện còn nợ của một giao dịch lập hóa đơn sau khi đã áp dụng mọi khoản thanh toán và điều chỉnh. Đây là khoản phải thu hiện tại của khoản phí đó. Đây là thuộc tính quan trọng đối với bảng điều khiển 'Phân tích tuổi nợ của số dư chưa thanh toán'. Theo dõi giá trị này theo thời gian giúp giám sát tốc độ luân chuyển tiền mặt, đánh giá hiệu quả thu hồi nợ và tính các KPI tài chính quan trọng như số ngày thu tiền bình quân (DSO). Vì sao điều này quan trọng Theo dõi khoản phải thu hiện tại của từng hồ sơ, cần thiết để quản lý dòng tiền và phân tích hiệu quả thu hồi nợ. Lấy dữ liệu ở đâu Giá trị này thường được tính bằng tổng các giao dịch tài chính (phí, thanh toán, điều chỉnh) của một giao dịch lập hóa đơn. Giá trị này cũng có thể nằm trong một trường của bảng tổng hợp tài khoản. Ví dụ 75.000.00550.80
	Số tiền điều chỉnh AdjustmentAmount	Giá trị tiền của các khoản điều chỉnh số dư tài khoản.
Mô tả Thuộc tính này ghi nhận số tiền của mọi khoản điều chỉnh tài chính áp dụng cho giao dịch lập hóa đơn, chẳng hạn như ưu đãi theo hợp đồng, xóa nợ hoặc sửa sai. Các khoản điều chỉnh làm giảm trực tiếp doanh thu dự kiến từ khoản phí. Bảng điều khiển 'Tác động của điều chỉnh tài khoản' phụ thuộc nhiều vào thuộc tính này. Phân tích số tiền điều chỉnh cùng lý do tương ứng giúp xác định nguồn thất thoát doanh thu, vấn đề trong quản lý hợp đồng hoặc sai sót ở khâu ghi nhận phí ban đầu. Đây là chỉ số quan trọng về tình hình tài chính. Vì sao điều này quan trọng Định lượng doanh thu thất thoát do xóa nợ hoặc sửa sai, giúp xác định và xử lý nguyên nhân gốc rễ làm suy giảm tài chính. Lấy dữ liệu ở đâu Có trong các bảng giao dịch tài chính ghi nhận khoản điều chỉnh hoặc xóa nợ trên tài khoản bệnh nhân. Ví dụ -50.25-120.0025.00
	Tên bên chi trả PayerName	Tên công ty bảo hiểm hoặc bên chi trả thứ ba chịu trách nhiệm thanh toán.
Mô tả Thuộc tính này xác định đơn vị được gửi hóa đơn, chẳng hạn công ty bảo hiểm hoặc chương trình của chính phủ như Medicare. Thông tin bên chi trả là yếu tố nền tảng trong phân tích chu kỳ doanh thu. Phân tích quy trình theo bên chi trả có thể cho thấy khác biệt đáng kể về thời gian thanh toán, tỷ lệ từ chối và tỷ lệ khiếu nại thành công. Nhờ đó, bạn có thể xác định bên chi trả gây chậm trễ hoặc thất thoát doanh thu, đồng thời quản lý hiệu quả hợp đồng và quan hệ với các bên chi trả. Vì sao điều này quan trọng Cho phép phân tích quy trình theo từng bên chi trả, qua đó làm rõ sự khác biệt về cách xử lý, tỷ lệ từ chối và tốc độ thanh toán. Đây là thông tin quan trọng để đánh giá hiệu quả tài chính. Lấy dữ liệu ở đâu Thông tin này được lưu trong hồ sơ thanh toán hoặc bảo hiểm của bệnh nhân trong Oracle Health Revenue Cycle. Ví dụ AetnaBlue Cross Blue ShieldUnitedHealthcareMedicareCigna
	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 hoạt động do phần mềm tự động hóa thực hiện, chẳng hạn bot hoặc tác vụ xử lý hàng loạt của hệ thống, với hoạt động do người dùng thực hiện thủ công. Ví dụ, 'Tạo yêu cầu thanh toán' có thể là bước tự động, còn 'Khiếu nại việc từ chối' thường được thực hiện thủ công. Phân tích thuộc tính này giúp hiểu mức độ tự động hóa của quy trình và tác động đến hiệu suất cũng như tỷ lệ lỗi. Bạn có thể dùng thuộc tính này để so sánh hiệu quả giữa luồng tự động và thủ công, đồng thời tìm cơ hội tự động hóa thêm. Vì sao điều này quan trọng Phân biệt hoạt động do người thực hiện với hoạt động do hệ thống xử lý, rất quan trọng để phân tích hiệu quả 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 suy ra từ thuộc tính UserPerformingAction. Ví dụ, hoạt động do các ID người dùng như 'SYSTEM' hoặc 'RPA_BOT' thực hiện sẽ được đánh dấu là tự động. Ví dụ truefalse
	Hệ thống nguồn SourceSystem	Hệ thống dùng để trích xuất dữ liệu sự kiện.
Mô tả Thuộc tính này xác định ứng dụng hoặc mô-đun nguồn nơi dữ liệu được tạo ra. Với quy trình này, giá trị thường là 'Oracle Health Revenue Cycle', nhưng cũng có thể chỉ rõ các mô-đun khác nhau trong hệ thống nếu dữ liệu được tích hợp từ nhiều nơi. Thông tin này hữu ích cho quản trị dữ liệu và xử lý sự cố. Thuộc tính giúp xác nhận nguồn gốc dữ liệu và rất quan trọng trong môi trường có nhiều hệ thống cùng đóng góp dữ liệu cho một quy trình từ đầu đến cuối. Vì sao điều này quan trọng Cho biết nguồn gốc dữ liệu, yếu tố quan trọng để xác thực và quản trị dữ liệu, cũng như hiểu các biến thể quy trình có thể phụ thuộc vào hệ thống. 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, chuyển đổi và nạp dữ liệu (ETL) để ghi nhãn nguồn gốc của tập dữ liệu. Ví dụ OracleHealth-RCMOracleHealth-CernerOH-RevCycle-PROD
	ID bệnh nhân PatientId	Mã định danh duy nhất của bệnh nhân liên quan đến giao dịch lập hóa đơn.
Mô tả Thuộc tính này là mã định danh duy nhất của bệnh nhân đã nhận dịch vụ, thường được gọi là mã hồ sơ bệnh án (MRN). Thuộc tính này liên kết giao dịch tài chính với một cá nhân cụ thể. Dù không phải ID hồ sơ của quy trình, ID bệnh nhân hữu ích để tổng hợp mọi giao dịch lập hóa đơn của một bệnh nhân và xem toàn bộ quá trình tài chính của họ. Khi kết hợp với dữ liệu hồ sơ bệnh nhân chính, thuộc tính này cũng cho phép phân nhóm theo nhân khẩu học hoặc tiền sử bệnh. Vì sao điều này quan trọng Liên kết các giao dịch tài chính với từng bệnh nhân, cho phép phân tích theo bệnh nhân và tổng hợp mọi hoạt động lập hóa đơn của họ. Lấy dữ liệu ở đâu Mã định danh này là thành phần cốt lõi trong hồ sơ bệnh nhân chính và có trong mọi bảng giao dịch liên quan, như phí, yêu cầu thanh toán và thanh toán. Ví dụ MRN-1002345MRN-1002346MRN-1002347
	ID yêu cầu thanh toán ClaimId	Mã định danh duy nhất của 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 duy nhất được gán cho yêu cầu thanh toán tạo và gửi đến bên chi trả để được hoàn trả. Trong suốt vòng đời, một giao dịch lập hóa đơn có thể tạo ra một hoặc nhiều yêu cầu thanh toán, chẳng hạn khi cần gửi bản điều chỉnh. ID yêu cầu thanh toán giúp truy vết một lần gửi cụ thể đến bên chi trả và liên kết trực tiếp với phản hồi, chẳng hạn khoản thanh toán hoặc việc từ chối. Nhờ đó, bạn có thể theo dõi chi tiết hơn trong quy trình chu kỳ doanh thu tổng thể. Vì sao điều này quan trọng Cung cấp mã định danh cụ thể để theo dõi quá trình xử lý yêu cầu thanh toán với bên chi trả, chi tiết hơn so với giao dịch lập hóa đơn tổng thể. Lấy dữ liệu ở đâu Oracle Health tạo ID này khi lập yêu cầu thanh toán và lưu trong bảng yêu cầu thanh toán chính. Ví dụ CLM-2023-55489CLM-2023-55490CLM-2023-55491-C1
	Là công việc làm lại IsRework	Cờ đánh dấu các hoạt động thể hiện việc làm lại hoặc lặp lại công việc.
Mô tả Thuộc tính được tính toán này đánh dấu các hoạt động cho thấy quy trình đi chệch khỏi luồng lý tưởng và phải làm lại. Ví dụ gồm 'Đã gửi yêu cầu thanh toán đã chỉnh sửa' hoặc 'Đã khiếu nại việc từ chối'. Những hoạt động này sẽ không xảy ra nếu quy trình diễn ra suôn sẻ ngay từ đầu. Xác định và định lượng công việc làm lại là mục tiêu quan trọng của process mining. Cờ này giúp lọc và phân tích các vòng lặp làm lại, qua đó đo tần suất, chi phí và nguyên nhân gây kém hiệu quả. Đây là yếu tố thiết yếu để hiểu đúng chi phí do chất lượng kém trong chu kỳ doanh thu. Vì sao điều này quan trọng Giúp định lượng tần suất và tác động của các vòng lặp làm lại, qua đó làm rõ điểm kém hiệu quả trong quy trình và chi phí do chất lượng kém. Lấy dữ liệu ở đâu Đây là thuộc tính suy ra. Thuộc tính được tính trong quá trình chuyển đổi dữ liệu bằng cách áp dụng logic nghiệp vụ để đánh dấu các tên hoạt động cụ thể là công việc làm lại. Ví dụ truefalse
	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.
Mô tả Thuộc tính này cho biết thời điểm tập dữ liệu được cập nhật gần nhất. Nhờ đó, bạn biết dữ liệu đang phân tích mới đến đâu, điều quan trọng để đánh giá mức độ cập nhật của thông tin thu được từ phân tích process mining. Người dùng có thể kiểm tra thuộc tính này để xác nhận mình đang xem thông tin quy trình mới nhất. Thuộc tính giúp bạn biết dữ liệu được cập nhật đến thời điểm nào, đồng thời là một phần quan trọng trong quản trị dữ liệu và bảo đảm chất lượng. Vì sao điều này quan trọng Cho biết dữ liệu mới đến đâu, giúp bảo đảm việc phân tích và ra quyết định dựa trên thông tin cập nhật. Lấy dữ liệu ở đâu Đây là trường siêu dữ liệu thường được tạo và điền trong quá trình ETL nạp dữ liệu vào nền tảng process mining. Ví dụ 2023-10-27T02:00:00Z2023-10-28T02:00:00Z
	Lý do khiếu nại hóa đơn DisputeReason	Lý do khách hàng hoặc bệnh nhân đưa ra khi khiếu nại hóa đơn hoặc khoản phí.
Mô tả Thuộc tính này ghi nhận lý do bệnh nhân hoặc bên chịu trách nhiệm khác khiếu nại hóa đơn. Lý do có thể là tính phí sai, dịch vụ chưa được cung cấp hoặc vấn đề trong quá trình xử lý bảo hiểm. Thông tin này rất cần thiết cho bảng điều khiển 'Chỉ số xử lý khiếu nại hóa đơn'. Hiểu được các lý do khiếu nại phổ biến nhất giúp xác định vấn đề mang tính hệ thống trong quy trình ghi nhận phí, mã hóa hoặc lập hóa đơn. Xử lý nguyên nhân gốc rễ có thể giảm đáng kể tỷ lệ khiếu nại và khối lượng công việc hành chính cần thiết để giải quyết. Vì sao điều này quan trọng Cho biết lý do hóa đơn bị khiếu nại, giúp xác định trực tiếp các vấn đề về độ chính xác hoặc tính rõ ràng của hóa đơn cần khắc phục. Lấy dữ liệu ở đâu Thông tin này có thể được lưu trong mô-đun quản lý vụ việc hoặc dịch vụ khách hàng của Oracle Health, liên kết với tài khoản bệnh nhân. Ví dụ Tính phí sai dịch vụTính phí trùng lặpLập hóa đơn bảo hiểm saiChưa cung cấp dịch vụ
	Số tiền phí ChargeAmount	Tổng giá trị tiền của dịch vụ hoặc sản phẩm được lập hóa đơn.
Mô tả Thuộc tính này thể hiện số tiền ban đầu chưa trừ chiết khấu của một dịch vụ, trước khi áp dụng bất kỳ khoản điều chỉnh, ưu đãi theo hợp đồng hoặc thanh toán nào. Đây là giá trị tài chính khởi điểm của giao dịch lập hóa đơn. Theo dõi số tiền phí rất quan trọng khi phân tích tài chính, chẳng hạn để tính tổng giá trị dịch vụ đã cung cấp và hiểu tác động tài chính của các khoản điều chỉnh hoặc xóa nợ sau đó. Đây là mốc cơ sở để đo lường doanh thu thực nhận. Vì sao điều này quan trọng Xác định giá trị tài chính ban đầu của hồ sơ, làm cơ sở cho mọi phân tích tài chính và đánh giá tác động tiếp theo. Lấy dữ liệu ở đâu Có trong các bảng chi tiết phí hoặc giao dịch phí của Oracle Health. Ví dụ 150.001250.7585.50
	Thời điểm kết thúc sự kiện EventEndTime	Dấu thời gian đánh dấu thời điểm hoàn tất một hoạt động, nếu có.
Mô tả StartTime đánh dấu thời điểm bắt đầu hoạt động, còn EventEndTime đánh dấu thời điểm kết thúc. Không phải hoạt động nào cũng có thời điểm kết thúc riêng, vì nhiều sự kiện diễn ra tức thời. Tuy nhiên, trường này rất hữu ích với các hoạt động kéo dài, chẳng hạn 'Khiếu nại quyết định từ chối', vốn có thể mất thời gian xử lý. Thuộc tính này giúp tính chính xác hơn thời gian xử lý của từng hoạt động. Nhờ đó, bạn có thể phân biệt thời gian chờ, tức khoảng thời gian giữa các hoạt động, với thời gian xử lý, tức thời gian dành cho một hoạt động. Vì sao điều này quan trọng Giúp tính trực tiếp thời gian hoàn tất một hoạt động, đồng thời phân biệt thời gian xử lý với thời gian chờ. Lấy dữ liệu ở đâu Một số bảng giao dịch trong Oracle Health Revenue Cycle có thể chứa cả dấu thời gian bắt đầu và kết thúc cho các tác vụ cụ thể kéo dài. Ví dụ 2023-04-15T09:05:14Z2023-04-18T16:00:00Z

Bắt buộc Nên có Không bắt buộc

Hoạt động trong quy trình quản lý chu trình doanh thu

Đây là những bước và mốc quan trọng cần ghi lại trong nhật ký sự kiện để trực quan hóa và phân tích chính xác chu trình doanh thu.

5 Nên có 9 Không bắt buộc

	Hoạt động	Mô tả
	Đóng tài khoản	Hoạt động cuối cùng, cho biết số dư tài khoản bằng 0 và dự kiến không còn giao dịch nào khác. Trạng thái này thường được suy ra khi số dư tài khoản về 0.
Vì sao điều này quan trọng Đánh dấu chu kỳ doanh thu đã hoàn tất thành công. Thời gian để đạt trạng thái này là chỉ số quan trọng về hiệu quả tổng thể của quy trình. Lấy dữ liệu ở đâu Thông thường, trạng thái này được suy ra bằng cách xác định lần đầu số dư còn phải thu của tài khoản về 0 và tiếp tục ở mức 0 sau khi ghi nhận mọi khoản thanh toán và điều chỉnh. Thu thập Được tính khi số dư tài khoản lần đầu bằng 0 sau khi ghi nhận mọi khoản phí và thanh toán. Loại sự kiện calculated
	Ghi nhận thanh toán	Đây là việc phân bổ khoản thanh toán nhận từ bên chi trả vào các khoản phí tương ứng trong tài khoản bệnh nhân. Đây là giao dịch tài chính do người dùng hoặc quy trình tự động ghi nhận.
Vì sao điều này quan trọng Hiệu quả ghi nhận thanh toán ảnh hưởng đến độ chính xác của các khoản phải thu. Chậm trễ ở bước này có thể làm sai lệch tình hình tài chính và trì hoãn việc thanh toán cho bên chi trả thứ cấp. Lấy dữ liệu ở đâu Dữ liệu nằm trong các bảng giao dịch thanh toán. Mỗi lần ghi nhận thanh toán có mã giao dịch riêng và dấu thời gian tương ứng. Thu thập Giao dịch tài chính được ghi nhận khi khoản thanh toán được phân bổ vào tài khoản. Loại sự kiện explicit
	Gửi yêu cầu thanh toán cho bên chi trả	Đây là việc gửi yêu cầu thanh toán đã tạo đến công ty bảo hiểm hoặc bên chi trả, bằng phương thức điện tử hoặc giấy. Hệ thống cần ghi lại ngày giờ gửi.
Vì sao điều này quan trọng Hoạt động này bắt đầu chu kỳ thanh toán. Phân tích thời gian từ lúc gửi đến khi nhận tiền là yếu tố then chốt để hiểu hiệu quả của bên chi trả và số ngày phải thu (DSO). Lấy dữ liệu ở đâu Dữ liệu lấy từ mô-đun quản lý yêu cầu thanh toán, nơi ghi lại các lần truyền dữ liệu. Hãy tìm dấu thời gian gửi hoặc lần đổi trạng thái thành 'Đã gửi' trong lịch sử yêu cầu thanh toán. Thu thập Sự kiện được ghi nhận khi yêu cầu thanh toán được truyền thành công qua trung tâm xử lý. Loại sự kiện explicit
	Tạo lượt khám của bệnh nhân	Đánh dấu thời điểm tạo tài khoản bệnh nhân cho một lần khám hoặc dịch vụ cụ thể. Đây thường là sự kiện được hệ thống đăng ký kích hoạt rõ ràng hoặc được ghi nhận qua luồng Admit/Discharge/Transfer (ADT).
Vì sao điều này quan trọng Đây là điểm khởi đầu của toàn bộ chu kỳ doanh thu cho một sự kiện lập hóa đơn, giúp phân tích tổng thời gian xử lý và độ chính xác của việc ghi nhận. Lấy dữ liệu ở đâu Dữ liệu lấy từ nhật ký của Patient Registration hoặc mô-đun ADT. Hãy tìm sự kiện tạo lượt khám hoặc dấu thời gian sớm nhất gắn với lượt khám hay mã tài chính. Thu thập Sự kiện được ghi nhận khi bệnh nhân đăng ký hoặc nhập viện. Loại sự kiện explicit
	Tạo yêu cầu thanh toán	Đánh dấu thời điểm tổng hợp các khoản phí riêng lẻ thành yêu cầu thanh toán chính thức, chẳng hạn UB-04 hoặc CMS-1500. Đây là sự kiện do hệ thống tạo, đồng thời lập hóa đơn ban đầu.
Vì sao điều này quan trọng Đây là cột mốc quan trọng, cho biết hồ sơ đã sẵn sàng gửi yêu cầu thanh toán cho bên chi trả. Đây cũng là điểm kết thúc để đo độ trễ nội bộ từ ghi nhận khoản phí đến lập hóa đơn. Lấy dữ liệu ở đâu Sự kiện được ghi rõ trong nhật ký hoặc bảng tạo yêu cầu thanh toán. Hãy tìm dấu thời gian tạo bản ghi yêu cầu thanh toán chính gắn với lượt khám. Thu thập Sự kiện được ghi nhận khi tạo bản ghi yêu cầu thanh toán. Loại sự kiện explicit
	Bắt đầu thu hồi công nợ	Cho biết tài khoản bệnh nhân đã được chuyển sang quy trình thu hồi công nợ do chưa thanh toán. Hoạt động này thường được ghi nhận qua thay đổi nhóm tài chính hoặc trạng thái của tài khoản.
Vì sao điều này quan trọng Đây là bước quan trọng trong quản lý nợ khó đòi. Phân tích nguyên nhân khiến tài khoản đến giai đoạn này và tỷ lệ thu hồi thành công là việc thiết yếu đối với tình hình tài chính. Lấy dữ liệu ở đâu Suy ra từ việc trường trạng thái tài khoản chuyển thành 'Thu hồi công nợ' hoặc 'Nợ khó đòi'. Lần đổi trạng thái này cần có dấu thời gian tương ứng. Thu thập Suy ra từ việc trạng thái tài khoản chuyển thành 'Thu hồi công nợ' hoặc trạng thái tương tự. Loại sự kiện inferred
	Điều chỉnh tài khoản	Đây là khoản điều chỉnh tài chính đối với số dư tài khoản, chẳng hạn khoản giảm trừ theo hợp đồng, khoản xóa nợ hoặc chiết khấu. Mỗi lần điều chỉnh là một giao dịch tài chính riêng biệt.
Vì sao điều này quan trọng Các khoản điều chỉnh ảnh hưởng trực tiếp đến doanh thu. Phân tích tần suất, loại và số tiền điều chỉnh giúp phát hiện thất thoát doanh thu và sai sót trong thanh toán. Lấy dữ liệu ở đâu Dữ liệu nằm trong các bảng giao dịch tài chính. Mỗi khoản điều chỉnh được ghi thành một dòng riêng, kèm mã giao dịch và dấu thời gian cụ thể. Thu thập Giao dịch tài chính được ghi nhận kèm mã điều chỉnh cụ thể. Loại sự kiện explicit
	Ghi nhận khoản phí	Đây là bước nhập các dịch vụ hoặc vật phẩm tính phí vào tài khoản bệnh nhân. Việc này có thể diễn ra tự động từ hệ thống lâm sàng hoặc do nhân viên nhập thủ công.
Vì sao điều này quan trọng Hoạt động này rất quan trọng để đo lường độ trễ ghi nhận khoản phí, tức thời gian từ khi cung cấp dịch vụ đến khi bắt đầu thanh toán. Khoảng thời gian này ảnh hưởng trực tiếp đến dòng tiền và tính toàn vẹn của doanh thu. Lấy dữ liệu ở đâu Dữ liệu lấy từ các bảng giao dịch khoản phí, dựa trên dấu thời gian tạo của từng dòng khoản phí. Trong Oracle Health, dữ liệu này thường nằm trong các bảng liên quan đến khoản phí. Thu thập Tạo mục nhật ký giao dịch cho mỗi khoản phí mới. Loại sự kiện explicit
	Gửi bảng kê cho bệnh nhân	Đánh dấu thời điểm lập và gửi hóa đơn cho phần chi phí bệnh nhân còn phải trả. Đây là hành động được mô-đun thanh toán cho bệnh nhân ghi nhận rõ ràng.
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. Theo dõi hoạt động này giúp phân tích hiệu quả thu tiền từ bệnh nhân. Lấy dữ liệu ở đâu Dữ liệu lấy từ nhật ký thanh toán cho bệnh nhân hoặc nhật ký thư từ. Hệ thống cần ghi lại ngày lập hoặc gửi từng bảng kê. Thu thập Sự kiện được ghi nhận khi bảng kê cho bệnh nhân được lập và in ra hoặc gửi bằng phương thức điện tử. Loại sự kiện explicit
	Gửi yêu cầu thanh toán đã chỉnh sửa	Đây là việc gửi yêu cầu thanh toán đã sửa đổi hoặc chỉnh sửa cho bên chi trả, thường sau khi bị từ chối hoặc được yêu cầu bổ sung thông tin. Hoạt động này được xác định qua lần gửi yêu cầu mới có chỉ báo chỉnh sửa.
Vì sao điều này quan trọng Hoạt động này là một phần quan trọng trong vòng xử lý lại các trường hợp bị từ chối. Tần suất cao cho thấy yêu cầu thanh toán ban đầu có vấn đề về độ chính xác. Lấy dữ liệu ở đâu Dữ liệu lấy từ nhật ký gửi yêu cầu thanh toán. Hãy tìm lần gửi mới cho một lượt khám đã có, thường được đánh dấu bằng mã gửi lại hoặc số lần gửi cao hơn. Thu thập Sự kiện ghi nhận việc gửi lại yêu cầu thanh toán, thường được nhận biết qua mã loại tần suất gửi yêu cầu cụ thể. Loại sự kiện explicit
	Khiếu nại quyết định từ chối	Hành động của người dùng hoặc hệ thống cho biết yêu cầu thanh toán bị từ chối đang được khiếu nại. Hoạt động này thường được ghi nhận qua cập nhật trạng thái hoặc một tác vụ cụ thể được tạo trong hàng đợi công việc.
Vì sao điều này quan trọng Hoạt động này bắt đầu một vòng xử lý lại. Phân tích tần suất khiếu nại và tỷ lệ khiếu nại thành công là việc rất quan trọng để tối ưu nỗ lực thu hồi doanh thu. Lấy dữ liệu ở đâu Đây có thể là sự kiện do người dùng chủ động ghi nhận hoặc được suy ra từ thay đổi trạng thái của yêu cầu thanh toán, chẳng hạn thành 'Đã khiếu nại' hoặc 'Đang xem xét'. Thu thập Thay đổi trạng thái hoặc sự kiện được ghi nhận khi người dùng bắt đầu khiếu nại yêu cầu thanh toán bị từ chối. Loại sự kiện explicit
	Mã hóa khoản phí	Đây là bước nhân viên mã hóa y tế gán mã chuẩn hóa, như CPT hoặc ICD-10, cho các khoản phí đã ghi nhận. Hoạt động này thường được theo dõi qua thay đổi trạng thái của khoản phí hoặc lượt khám.
Vì sao điều này quan trọng Chậm trễ trong khâu mã hóa là một điểm nghẽn thường gặp. Theo dõi hoạt động này giúp phát hiện điểm kém hiệu quả trong quy trình làm việc mã hóa và đánh giá ảnh hưởng của chúng đến thời gian thanh toán. Lấy dữ liệu ở đâu Hoạt động này thường được suy ra từ thay đổi trạng thái của lượt khám hoặc lô khoản phí, chẳng hạn từ 'Chưa mã hóa' sang 'Đã mã hóa'. Cần có dấu thời gian của lần đổi trạng thái này. Thu thập Suy ra từ việc trạng thái lượt khám hoặc khoản phí chuyển thành 'Đã mã hóa' hoặc 'Sẵn sàng thanh toán'. Loại sự kiện inferred
	Nhận thông báo thanh toán	Đánh dấu thời điểm nhận Electronic Remittance Advice (ERA) hoặc Explanation of Benefits (EOB) bản giấy từ bên chi trả. Tài liệu này nêu rõ khoản phí 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 Đây là phản hồi đầu tiên từ bên chi trả, rất quan trọng để hiểu tốc độ thanh toán và sớm phát hiện xu hướng từ chối. Lấy dữ liệu ở đâu Được ghi nhận trong mô-đun xử lý thông báo thanh toán. Hãy tìm dấu thời gian nhập hoặc tạo tệp ERA, chẳng hạn tệp giao dịch 835, được liên kết với yêu cầu thanh toán. Thu thập Sự kiện được ghi nhận khi nhập và xử lý tệp thông báo thanh toán của bên chi trả, chẳng hạn ANSI 835. Loại sự kiện explicit
	Nhận thông báo từ chối	Đánh dấu thời điểm bên chi trả từ chối yêu cầu thanh toán hoặc một số dòng khoản phí, theo thông tin trong thông báo thanh toán. Sự kiện này thường được suy ra từ mã từ chối trong dữ liệu thông báo thanh toán.
Vì sao điều này quan trọng Theo dõi các trường hợp từ chối là việc cần thiết để tìm nguyên nhân gốc rễ, chẳng hạn lỗi mã hóa hoặc vấn đề về điều kiện hợp lệ, và cải thiện tỷ lệ yêu cầu thanh toán hợp lệ ngay từ đầu. Lấy dữ liệu ở đâu Suy ra từ dữ liệu thông báo thanh toán (ERA/835). Sự kiện này được kích hoạt khi yêu cầu thanh toán hoặc một dòng khoản phí có số tiền bị từ chối khác 0 và có mã lý do từ chối tương ứng. Thu thập Suy ra từ dữ liệu thông báo thanh toán có mã lý do từ chối (CARCs/RARCs). Loại sự kiện inferred

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ừ Oracle Health Revenue Cycle

Các bước

Yêu cầu quyền truy cập cơ sở dữ liệu: Xin thông tin đăng nhập chỉ đọc cho cơ sở dữ liệu Oracle Health Revenue Cycle. Bạn cần quyền truy cập các schema chứa dữ liệu bệnh nhân, lượt khám, thanh toán và giao dịch tài chính. Thông thường, bạn cần được bộ phận bảo mật CNTT và quản trị cơ sở dữ liệu phê duyệt.
Xác định tên schema và bảng: Làm việc với quản trị viên cơ sở dữ liệu hoặc chuyên viên phân tích hệ thống để xác nhận tên schema và bảng chính xác trong phiên bản Oracle Health của bạn. Các tên trong truy vấn chỉ là tên mẫu phổ biến, cần ánh xạ sang môi trường cụ thể của bạn.
Cài đặt ứng dụng SQL: Cài một ứng dụng SQL tương thích, chẳng hạn Oracle SQL Developer hoặc DBeaver, trên máy tính. Bạn sẽ dùng ứng dụng này để kết nối cơ sở dữ liệu và chạy tập lệnh trích xuất.
Kết nối cơ sở dữ liệu: Tạo kết nối mới trong ứng dụng SQL bằng máy chủ, cổng, tên dịch vụ và thông tin đăng nhập được cung cấp. Kiểm tra để đảm bảo kết nối thành công.
Tùy chỉnh truy vấn SQL: Sao chép tập lệnh SQL được cung cấp vào cửa sổ soạn truy vấn mới. Tìm các giá trị giữ chỗ như [START_DATE] và [END_DATE], rồi thay bằng khoảng ngày cần phân tích, chẳng hạn '2023-01-01'. Điều chỉnh bộ lọc theo nhu cầu phân tích, ví dụ lọc theo một Patient Class cụ thể.
Chạy tập lệnh trích xuất: Chạy tập lệnh SQL đã tùy chỉnh. Truy vấn được thiết kế để lấy dữ liệu đầy đủ nên có thể mất từ vài phút đến vài giờ, tùy vào khoảng ngày và quy mô cơ sở dữ liệu.
Kiểm tra kết quả ban đầu: Khi truy vấn chạy xong, xem vài trăm dòng đầu trong bảng kết quả của ứng dụng SQL. Kiểm tra các lỗi dễ nhận thấy như cột toàn giá trị null hoặc định dạng dữ liệu sai để xác nhận tập lệnh chạy đúng.
Xuất dữ liệu sang CSV: Xuất toàn bộ kết quả thành tệp CSV. Dùng mã hóa UTF-8 để tránh lỗi ký tự. Đảm bảo tệp có hàng tiêu đề với tên cột theo bí danh trong truy vấn, chẳng hạn "BillingEvent", "ActivityName".
Chuẩn bị tải dữ liệu lên: Trước khi tải lên công cụ process mining, mở tệp CSV để kiểm tra tính toàn vẹn. Xác nhận định dạng dấu thời gian nhất quán và tiêu đề cột khớp chính xác với các thuộc tính yêu cầu. Sau đó, tệp đã sẵn sàng để tải lên.

Cấu hình

Khoảng ngày: Truy vấn dùng các giá trị giữ chỗ [START_DATE] và [END_DATE]. Cần xác định khoảng ngày cụ thể, hợp lý để kiểm soát lượng dữ liệu. Nên bắt đầu với khoảng từ 3 đến 6 tháng.
Lọc dữ liệu: Tập dữ liệu ban đầu được lọc theo ngày đăng ký lượt khám (reg_dt_tm) trong phần RelevantEncounters. Bạn có thể thêm các mệnh đề WHERE khác vào phần này để thu hẹp phạm vi, chẳng hạn e.patient_class_code IN ('INPATIENT', 'OUTPATIENT') để tập trung vào một số loại lượt khám.
Hiệu suất: Truy vấn trực tiếp cơ sở dữ liệu đang vận hành có thể ảnh hưởng đến hiệu suất. Nên chạy trích xuất vào giờ thấp điểm hoặc dùng bản sao chỉ đọc của cơ sở dữ liệu vận hành nếu có.
Điều kiện cần: Phương pháp này yêu cầu tài khoản cơ sở dữ liệu có quyền SELECT trên tất cả bảng được tham chiếu trong truy vấn, bao gồm các bảng về lượt khám, thanh toán, khoản phí, yêu cầu thanh toán, khoản hoàn trả và giao dịch tài chính.
Ánh xạ bảng và cột: Tập lệnh được cung cấp dùng tên bảng và cột phổ biến, mang tính đại diện. Bạn cần xác minh và ánh xạ chúng sang tên thực tế trong schema cơ sở dữ liệu Oracle Health của tổ chức. Ví dụ, FINANCIAL_TRANSACTION có thể được đặt tên là AR_TRANSACTIONS trong hệ thống của bạn.

Truy vấn mẫu sql

WITH RelevantEncounters AS (
  SELECT 
    e.billing_event_id
  FROM ENCOUNTER e
  WHERE e.reg_dt_tm BETWEEN TO_DATE('[START_DATE]', 'YYYY-MM-DD') AND TO_DATE('[END_DATE]', 'YYYY-MM-DD')
)
SELECT
  e.billing_event_id AS "BillingEvent",
  'Patient Encounter Created' AS "ActivityName",
  e.reg_dt_tm AS "EventTimestamp",
  p.name_full_formatted AS "UserPerformingAction",
  org.organization_name AS "BillingDepartment",
  pyr.payer_name AS "PayerName",
  e.patient_class_code AS "PatientClass",
  NULL AS "AdjustmentAmount",
  e.total_account_balance AS "OutstandingBalance",
  NULL AS "DenialReasonCode"
FROM ENCOUNTER e
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON e.reg_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON e.reg_facility_org_id = org.organization_id
LEFT JOIN PAYER pyr ON e.primary_payer_id = pyr.payer_id
UNION ALL
SELECT
  cd.billing_event_id AS "BillingEvent",
  'Charges Captured' AS "ActivityName",
  cd.charge_entry_dt_tm AS "EventTimestamp",
  p.name_full_formatted AS "UserPerformingAction",
  org.organization_name AS "BillingDepartment",
  pyr.payer_name AS "PayerName",
  e.patient_class_code AS "PatientClass",
  NULL AS "AdjustmentAmount",
  cd.charge_balance AS "OutstandingBalance",
  NULL AS "DenialReasonCode"
FROM CHARGE_DETAIL cd
JOIN ENCOUNTER e ON cd.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON cd.entry_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON cd.performing_dept_org_id = org.organization_id
LEFT JOIN PAYER pyr ON e.primary_payer_id = pyr.payer_id
UNION ALL
SELECT
  ch.billing_event_id AS "BillingEvent",
  'Charges Coded' AS "ActivityName",
  ch.coded_dt_tm AS "EventTimestamp",
  p.name_full_formatted AS "UserPerformingAction",
  org.organization_name AS "BillingDepartment",
  pyr.payer_name AS "PayerName",
  e.patient_class_code AS "PatientClass",
  NULL AS "AdjustmentAmount",
  e.total_account_balance AS "OutstandingBalance",
  NULL AS "DenialReasonCode"
FROM CODING_HISTORY ch
JOIN ENCOUNTER e ON ch.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON ch.coder_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON p.default_org_id = org.organization_id
LEFT JOIN PAYER pyr ON e.primary_payer_id = pyr.payer_id
UNION ALL
SELECT
  cl.billing_event_id AS "BillingEvent",
  'Claim Generated' AS "ActivityName",
  cl.create_dt_tm AS "EventTimestamp",
  p.name_full_formatted AS "UserPerformingAction",
  org.organization_name AS "BillingDepartment",
  pyr.payer_name AS "PayerName",
  e.patient_class_code AS "PatientClass",
  NULL AS "AdjustmentAmount",
  cl.claim_balance AS "OutstandingBalance",
  NULL AS "DenialReasonCode"
FROM CLAIM cl
JOIN ENCOUNTER e ON cl.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON cl.create_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON cl.billing_entity_org_id = org.organization_id
LEFT JOIN PAYER pyr ON cl.payer_id = pyr.payer_id
UNION ALL
SELECT
  csl.billing_event_id AS "BillingEvent",
  'Claim Submitted To Payer' AS "ActivityName",
  csl.submission_dt_tm AS "EventTimestamp",
  p.name_full_formatted AS "UserPerformingAction",
  org.organization_name AS "BillingDepartment",
  pyr.payer_name AS "PayerName",
  e.patient_class_code AS "PatientClass",
  NULL AS "AdjustmentAmount",
  cl.claim_balance AS "OutstandingBalance",
  NULL AS "DenialReasonCode"
FROM CLAIM_SUBMISSION_LOG csl
JOIN CLAIM cl ON csl.claim_id = cl.claim_id
JOIN ENCOUNTER e ON cl.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON csl.submit_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON cl.billing_entity_org_id = org.organization_id
LEFT JOIN PAYER pyr ON cl.payer_id = pyr.payer_id
WHERE csl.submission_type = 'INITIAL'
UNION ALL
SELECT
  ra.billing_event_id AS "BillingEvent",
  'Remittance Received' AS "ActivityName",
  ra.remit_received_dt_tm AS "EventTimestamp",
  p.name_full_formatted AS "UserPerformingAction",
  org.organization_name AS "BillingDepartment",
  pyr.payer_name AS "PayerName",
  e.patient_class_code AS "PatientClass",
  NULL AS "AdjustmentAmount",
  e.total_account_balance AS "OutstandingBalance",
  NULL AS "DenialReasonCode"
FROM REMITTANCE_ADVICE ra
JOIN ENCOUNTER e ON ra.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON ra.processed_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON ra.processing_org_id = org.organization_id
LEFT JOIN PAYER pyr ON ra.payer_id = pyr.payer_id
UNION ALL
SELECT
  ft.billing_event_id AS "BillingEvent",
  'Payment Posted' AS "ActivityName",
  ft.transaction_dt_tm AS "EventTimestamp",
  p.name_full_formatted AS "UserPerformingAction",
  org.organization_name AS "BillingDepartment",
  pyr.payer_name AS "PayerName",
  e.patient_class_code AS "PatientClass",
  NULL AS "AdjustmentAmount",
  ft.ending_balance AS "OutstandingBalance",
  NULL AS "DenialReasonCode"
FROM FINANCIAL_TRANSACTION ft
JOIN ENCOUNTER e ON ft.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON ft.post_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON ft.post_dept_org_id = org.organization_id
LEFT JOIN PAYER pyr ON ft.payer_id = pyr.payer_id
WHERE ft.transaction_type_code = 'PAYMENT'
UNION ALL
SELECT
  rd.billing_event_id AS "BillingEvent",
  'Denial Received' AS "ActivityName",
  ra.remit_received_dt_tm AS "EventTimestamp",
  p.name_full_formatted AS "UserPerformingAction",
  org.organization_name AS "BillingDepartment",
  pyr.payer_name AS "PayerName",
  e.patient_class_code AS "PatientClass",
  NULL AS "AdjustmentAmount",
  e.total_account_balance AS "OutstandingBalance",
  rd.denial_reason_code AS "DenialReasonCode"
FROM REMITTANCE_DETAIL rd
JOIN REMITTANCE_ADVICE ra ON rd.remit_id = ra.remit_id
JOIN ENCOUNTER e ON ra.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON ra.processed_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON ra.processing_org_id = org.organization_id
LEFT JOIN PAYER pyr ON ra.payer_id = pyr.payer_id
WHERE rd.denial_reason_code IS NOT NULL
UNION ALL
SELECT
  at.billing_event_id AS "BillingEvent",
  'Denial Appealed' AS "ActivityName",
  at.appeal_filed_dt_tm AS "EventTimestamp",
  p.name_full_formatted AS "UserPerformingAction",
  org.organization_name AS "BillingDepartment",
  pyr.payer_name AS "PayerName",
  e.patient_class_code AS "PatientClass",
  NULL AS "AdjustmentAmount",
  e.total_account_balance AS "OutstandingBalance",
  at.related_denial_code AS "DenialReasonCode"
FROM APPEAL_TRACKING at
JOIN ENCOUNTER e ON at.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON at.appeal_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON p.default_org_id = org.organization_id
LEFT JOIN PAYER pyr ON at.payer_id = pyr.payer_id
UNION ALL
SELECT
  csl.billing_event_id AS "BillingEvent",
  'Corrected Claim Submitted' AS "ActivityName",
  csl.submission_dt_tm AS "EventTimestamp",
  p.name_full_formatted AS "UserPerformingAction",
  org.organization_name AS "BillingDepartment",
  pyr.payer_name AS "PayerName",
  e.patient_class_code AS "PatientClass",
  NULL AS "AdjustmentAmount",
  cl.claim_balance AS "OutstandingBalance",
  NULL AS "DenialReasonCode"
FROM CLAIM_SUBMISSION_LOG csl
JOIN CLAIM cl ON csl.claim_id = cl.claim_id
JOIN ENCOUNTER e ON cl.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON csl.submit_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON cl.billing_entity_org_id = org.organization_id
LEFT JOIN PAYER pyr ON cl.payer_id = pyr.payer_id
WHERE csl.submission_type = 'CORRECTED'
UNION ALL
SELECT
  psl.billing_event_id AS "BillingEvent",
  'Patient Statement Sent' AS "ActivityName",
  psl.statement_sent_dt_tm AS "EventTimestamp",
  p.name_full_formatted AS "UserPerformingAction",
  org.organization_name AS "BillingDepartment",
  NULL AS "PayerName",
  e.patient_class_code AS "PatientClass",
  NULL AS "AdjustmentAmount",
  psl.statement_balance AS "OutstandingBalance",
  NULL AS "DenialReasonCode"
FROM PATIENT_STATEMENT_LOG psl
JOIN ENCOUNTER e ON psl.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON psl.sent_by_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON p.default_org_id = org.organization_id
UNION ALL
SELECT
  ash.billing_event_id AS "BillingEvent",
  'Collection Activity Started' AS "ActivityName",
  ash.status_change_dt_tm AS "EventTimestamp",
  p.name_full_formatted AS "UserPerformingAction",
  org.organization_name AS "BillingDepartment",
  NULL AS "PayerName",
  e.patient_class_code AS "PatientClass",
  NULL AS "AdjustmentAmount",
  ash.account_balance AS "OutstandingBalance",
  NULL AS "DenialReasonCode"
FROM ACCOUNT_STATUS_HISTORY ash
JOIN ENCOUNTER e ON ash.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON ash.change_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON ash.responsible_org_id = org.organization_id
WHERE ash.new_status_code = 'COLLECTIONS'
UNION ALL
SELECT
  ft.billing_event_id AS "BillingEvent",
  'Account Adjusted' AS "ActivityName",
  ft.transaction_dt_tm AS "EventTimestamp",
  p.name_full_formatted AS "UserPerformingAction",
  org.organization_name AS "BillingDepartment",
  pyr.payer_name AS "PayerName",
  e.patient_class_code AS "PatientClass",
  ft.transaction_amount AS "AdjustmentAmount",
  ft.ending_balance AS "OutstandingBalance",
  ft.adjustment_reason_code AS "DenialReasonCode"
FROM FINANCIAL_TRANSACTION ft
JOIN ENCOUNTER e ON ft.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON ft.post_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON ft.post_dept_org_id = org.organization_id
LEFT JOIN PAYER pyr ON ft.payer_id = pyr.payer_id
WHERE ft.transaction_type_code = 'ADJUSTMENT'
UNION ALL
SELECT
  e.billing_event_id AS "BillingEvent",
  'Account Closed' AS "ActivityName",
  e.account_closed_dt_tm AS "EventTimestamp",
  p.name_full_formatted AS "UserPerformingAction",
  org.organization_name AS "BillingDepartment",
  NULL AS "PayerName",
  e.patient_class_code AS "PatientClass",
  NULL AS "AdjustmentAmount",
  0 AS "OutstandingBalance",
  NULL AS "DenialReasonCode"
FROM ENCOUNTER e
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON e.closed_by_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON e.reg_facility_org_id = org.organization_id
WHERE e.total_account_balance = 0 AND e.account_closed_dt_tm IS NOT NULL;

Sẵn sàng bắt đầu?

Dùng mẫu này để chuẩn bị dữ liệu phù hợp. Bắt đầu cải tiến quy trình quản lý chu trình doanh thu ngay hôm nay.

Quay lại hướng dẫn cải tiến

Tải mẫu xuống

Cải thiện chu trình doanh thu để nhận thanh toán nhanh hơn

Loại bỏ điểm nghẽn, rút ngắn thời gian chu trình 30% và cải thiện dòng tiền.

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

Không cần thẻ tín dụng. Thiết lập chỉ trong vài phút.

Mẫu dữ liệu quản lý chu trình doanh thu

Mẫu dữ liệu quản lý chu trình doanh thu

Thuộc tính quản lý chu trình doanh thu

Hoạt động trong quy trình quản lý chu trình doanh thu

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

Truy vấn SQL trực tiếp trên các schema cơ sở dữ liệu Oracle Health

Các bước

Cấu hình

Truy vấn mẫu sql

Sẵn sàng bắt đầu?

Cải thiện chu trình doanh thu để nhận thanh toán nhanh hơn