Templat data pengelolaan siklus pendapatan Anda
Templat data pengelolaan siklus pendapatan Anda
- Atribut yang disarankan untuk dikumpulkan
- Aktivitas utama yang perlu dilacak
- Panduan ekstraksi
Atribut pengelolaan siklus pendapatan
| Nama | Deskripsi | ||
|---|---|---|---|
| Nama aktivitas ActivityName | Nama peristiwa atau tugas tertentu yang dilakukan dalam proses Revenue Cycle Management. | ||
| Deskripsi Atribut ini menjelaskan satu langkah dalam siklus pendapatan, seperti 'Biaya layanan dicatat', 'Klaim diajukan kepada penanggung', atau 'Pembayaran diterima'. Setiap aktivitas menandai tahap tertentu dalam proses penagihan dan penerimaan pembayaran atas suatu layanan. Analisis aktivitas menjadi dasar process mining. Anda dapat memvisualisasikan peta proses, menemukan jalur yang umum, mengidentifikasi hambatan antar langkah, dan mengukur kesesuaian dengan prosedur operasi standar. Mengapa ini penting Atribut ini menentukan langkah-langkah dalam peta proses sehingga alur kerja dalam siklus pendapatan dapat divisualisasikan, dianalisis, dan dioptimalkan. Sumber data Biasanya diambil dari log peristiwa, jejak audit, atau catatan perubahan status dalam modul penagihan dan klaim Epic Resolute. Contoh Biaya layanan dicatatKlaim diajukan kepada penanggungPembayaran diterimaAkun ditutup | |||
| Peristiwa penagihan BillingEvent | Pengenal unik untuk satu layanan atau produk yang diberikan dan menghasilkan biaya. Pengenal ini berfungsi sebagai ID kasus utama. | ||
| Deskripsi Peristiwa Penagihan adalah pengenal utama yang menghubungkan semua aktivitas dalam siklus pendapatan untuk suatu item yang dapat ditagihkan. Proses dimulai saat layanan diberikan dan berakhir saat akun lunas atau ditutup. Dalam analisis process mining, atribut ini penting untuk merekonstruksi perjalanan setiap biaya dari awal hingga akhir. Anda dapat melacak aktivitas seperti pencatatan biaya, pengajuan klaim, pencatatan pembayaran, dan penanganan penolakan untuk setiap peristiwa penagihan. Hasilnya, alur proses dan variasinya terlihat jelas. Mengapa ini penting Ini adalah ID Kasus utama yang menghubungkan semua langkah terkait. Dengan pengenal ini, Anda dapat menganalisis seluruh siklus pendapatan dan penagihan untuk setiap layanan. Sumber data Pengenal ini biasanya berupa nomor unik untuk akun rumah sakit (HAR) atau sesi biaya tertentu di Epic Resolute. Lihat dokumentasi Epic Resolute untuk tabel tertentu, seperti catatan HAR atau Charge Session. Contoh BE10098765BE20012345BE30054321 | |||
| Stempel waktu peristiwa EventTimestamp | Tanggal dan waktu tepat saat aktivitas atau peristiwa tertentu terjadi. | ||
| Deskripsi Stempel Waktu Peristiwa mencatat waktu terjadinya suatu aktivitas. Data waktu ini penting untuk memahami kapan dan dalam urutan apa peristiwa terjadi dalam siklus pendapatan. Dalam analisis, stempel waktu digunakan untuk menghitung durasi antaraktivitas, seperti jeda pencatatan biaya atau waktu pencatatan pembayaran. Data ini membantu menemukan hambatan, mengukur waktu siklus, dan menganalisis kinerja proses dalam berbagai periode. Stempel waktu yang akurat diperlukan untuk hampir semua KPI dan dasbor berbasis waktu. Mengapa ini penting Atribut ini penting untuk menghitung semua metrik berbasis waktu, termasuk waktu siklus dan durasi. Metrik tersebut menjadi dasar untuk menemukan keterlambatan dan inefisiensi. Sumber data Tersedia di tabel transaksi atau log peristiwa Epic Resolute dan terkait dengan setiap aktivitas yang tercatat. Nama kolom sering diakhiri dengan Dt, DTTM, atau Time. Contoh 2023-04-15T09:30:00Z2023-04-16T11:05:21Z2023-05-01T14:00:00Z | |||
| Alasan penyesuaian AdjustmentReason | Alasan penyesuaian manual atau otomatis pada saldo akun pasien. | ||
| Deskripsi Atribut ini menjelaskan alasan saldo akun berubah di luar pembayaran atau biaya standar. Alasannya dapat berupa potongan kontrak dengan penanggung, penghapusan saldo kecil, atau koreksi kesalahan pencatatan. Atribut ini penting untuk dasbor 'Volume penyesuaian akun berdasarkan jenis'. Dengan menganalisis alasan penyesuaian, organisasi dapat menemukan sumber kebocoran pendapatan, memahami dampak kontrak dengan penanggung, serta mendeteksi inefisiensi atau kesalahan dalam proses penagihan. Mengapa ini penting Atribut ini menjelaskan alasan perubahan saldo akun sehingga membantu mengungkap kebocoran pendapatan dan menilai ketepatan penagihan. Dengan begitu, penghapusan piutang yang tidak perlu dapat dikurangi. Sumber data Tersedia dalam detail transaksi penyesuaian di modul akuntansi pasien Epic Resolute. Contoh Potongan kontrakPenghapusan saldo kecilKoreksi biaya duplikat | |||
| Departemen penagihan BillingDepartment | Departemen atau tim fungsional yang bertanggung jawab atas peristiwa atau aktivitas penagihan. | ||
| Deskripsi Atribut ini menunjukkan unit organisasi yang terkait dengan peristiwa penagihan atau yang melakukan aktivitas tertentu, seperti 'Penagihan rawat inap', 'Penagihan rawat jalan', atau 'Tim penanganan penolakan'. Dimensi ini penting untuk dasbor 'Metrik kinerja departemen penagihan'. Anda dapat membandingkan metrik utama, seperti tingkat penolakan atau waktu pencatatan biaya, secara berdampingan. Manajemen dapat menemukan departemen berkinerja tinggi, menstandarkan praktik terbaik, dan mengalokasikan sumber daya secara efektif. Mengapa ini penting Atribut ini memungkinkan perbandingan kinerja antar-departemen. Anda dapat menemukan praktik terbaik serta area yang perlu diperbaiki atau mendapat sumber daya tambahan. Sumber data Informasi ini mungkin terhubung ke catatan pengguna, akun pasien, atau lokasi layanan di Epic Resolute. Contoh Penagihan kardiologiRCM radiologiKantor penagihan pusat | |||
| Jenis layanan ServiceType | Kategori atau jenis layanan medis yang diberikan. | ||
| Deskripsi Atribut ini mengelompokkan layanan yang ditagihkan, misalnya sebagai 'Radiologi', 'Bedah', 'Konsultasi', atau 'Kunjungan unit gawat darurat'. Atribut ini memberi konteks klinis pada data keuangan. Analisis siklus pendapatan berdasarkan jenis layanan dapat mengungkap variasi proses di bidang klinis tertentu. Misalnya, prosedur bedah mungkin memerlukan pencatatan biaya dan otorisasi yang lebih rumit daripada kunjungan rawat jalan biasa. Akibatnya, alur proses dan tantangannya pun berbeda. Mengapa ini penting Memberi konteks klinis pada data keuangan sehingga Anda dapat menganalisis dampak berbagai jenis layanan medis terhadap proses siklus pendapatan dan efisiensinya. Sumber data Bersumber dari master deskripsi biaya (CDM), lini layanan, atau departemen yang terkait dengan transaksi biaya di Epic. Contoh Bedah rawat inapRadiologi rawat jalanLayanan gawat darurat | |||
| Kode alasan penolakan DenialReasonCode | Kode standar yang menunjukkan alasan penanggung menolak klaim yang diajukan. | ||
| Deskripsi Saat menolak klaim, penanggung memberikan kode alasan, misalnya 'Layanan tidak ditanggung', 'Klaim duplikat', atau 'Informasi tambahan diperlukan'. Kode ini sering mengikuti standar Claim Adjustment Reason Codes (CARCs). Atribut ini menjadi dasar dasbor 'Tingkat dan alasan penolakan klaim'. Dengan menganalisis frekuensi setiap kode penolakan, Anda dapat menemukan penyebab utama, seperti masalah kredensial, kesalahan kode, atau prapersetujuan yang belum ada. Temuan ini membantu menentukan inisiatif perbaikan yang tepat. Mengapa ini penting Atribut ini menjelaskan secara langsung alasan klaim ditolak. Wawasannya dapat digunakan untuk mengurangi tingkat penolakan, mencegah kehilangan pendapatan, dan mempercepat pembayaran. Sumber data Data ini terdapat dalam transaksi respons klaim, seperti berkas ANSI 835, yang diterima dari penanggung dan disimpan di modul pengelolaan klaim Epic Resolute. Contoh CO-16: Informasi klaim/layanan tidak lengkapOA-18: Klaim/layanan duplikatPR-96: Biaya tidak ditanggung | |||
| Pengguna yang bertanggung jawab ResponsibleUser | ID pengguna atau karyawan yang melakukan aktivitas. | ||
| Deskripsi Atribut ini mencatat ID pengguna, nama, atau nomor karyawan yang bertanggung jawab menyelesaikan tugas tertentu dalam siklus pendapatan. Contohnya, tenaga klinis yang memasukkan biaya, petugas penagihan yang mengajukan klaim, atau petugas penagihan piutang yang menindaklanjuti penolakan. Analisis berdasarkan pengguna membantu menemukan kinerja terbaik, kebutuhan pelatihan, dan pembagian beban kerja. Informasi ini penting untuk pengelolaan kinerja dan penyelidikan penyimpangan proses yang terkait dengan individu atau peran tertentu. Mengapa ini penting Atribut ini memungkinkan analisis kinerja berdasarkan individu atau peran. Anda dapat menemukan kebutuhan pelatihan, ketimpangan beban kerja, dan hambatan terkait sumber daya. Sumber data Biasanya tersedia di jejak audit atau log transaksi Epic Resolute dan sering terhubung ke tabel data induk pengguna, misalnya catatan EMP. Contoh j.doebsmith123User7890 | |||
| Saldo terutang OutstandingBalance | Jumlah yang masih harus dibayar oleh penanggung atau pasien untuk peristiwa penagihan. | ||
| Deskripsi Atribut ini menunjukkan saldo piutang usaha saat ini untuk suatu peristiwa penagihan pada waktu aktivitas berlangsung. Nilainya mencerminkan kondisi keuangan kasus sepanjang siklusnya. Saldo terutang penting untuk pelaporan keuangan dan 'Laporan umur saldo terutang'. Dengan menganalisis nilai ini dari waktu ke waktu dan berdasarkan dimensi seperti penanggung atau departemen, Anda dapat memprioritaskan upaya penagihan, mengelola arus kas, dan menilai risiko keuangan. Mengapa ini penting Atribut ini mengukur langsung dampak keuangan dari keterlambatan proses. Informasi ini penting untuk memprioritaskan penagihan, mengelola arus kas, dan memahami piutang usaha. Sumber data Ini adalah kolom utama pada catatan akun pasien atau akun rumah sakit (HAR) di Epic Resolute. Saldo berjalan ini diperbarui oleh transaksi keuangan. Contoh 1500.00250.750.00 | |||
| Diotomatisasi IsAutomated | Penanda boolean yang menunjukkan apakah aktivitas dilakukan oleh sistem atau proses otomatis. | ||
| Deskripsi Penanda ini membedakan tugas yang dijalankan otomatis oleh sistem, seperti pembuatan klaim atau pemeriksaan kelayakan otomatis, dari tugas yang dilakukan secara manual oleh pengguna. Analisis atribut ini membantu Anda memahami tingkat otomatisasi proses. Anda dapat membandingkan efisiensi dan tingkat kesalahan aktivitas otomatis dengan aktivitas manual, menemukan peluang untuk menambah otomatisasi, serta memantau kinerja bot atau aturan sistem yang sudah digunakan. Mengapa ini penting Membedakan aktivitas yang dijalankan sistem dari aktivitas yang dilakukan manusia. Informasi ini penting untuk mengevaluasi dampak otomatisasi dan menemukan peluang otomatisasi baru. Sumber data Biasanya ditentukan dengan memeriksa apakah 'ResponsibleUser' suatu aktivitas adalah akun sistem atau layanan, atau dengan menandai nama aktivitas tertentu yang diketahui berjalan otomatis. Contoh truefalse | |||
| ID klaim ClaimId | Pengenal unik yang diberikan kepada klaim asuransi yang diajukan kepada pembayar. | ||
| Deskripsi Atribut ini adalah ID khusus untuk formulir klaim, seperti CMS-1500 atau UB-04, yang dikirim kepada pembayar. Satu peristiwa penagihan dapat melibatkan beberapa klaim jika layanan ditagihkan ulang atau diajukan banding. Pelacakan berdasarkan ID klaim berguna untuk menganalisis secara terperinci proses pengajuan klaim dan pengelolaan penolakan. Cara ini membantu membedakan aktivitas pada klaim awal dari aktivitas pada klaim berikutnya yang diajukan ulang untuk layanan yang sama. Mengapa ini penting Memberikan pengenal terperinci untuk melacak siklus setiap pengajuan klaim, yang penting untuk menganalisis pengajuan ulang dan banding. Sumber data Dibuat oleh modul pengelolaan klaim Epic Resolute saat klaim dibuat. ID ini disimpan di tabel data klaim. Contoh CLM-2023-98765CLAIM-0012345623189A4567 | |||
| ID pasien PatientId | Pengenal unik untuk pasien yang menerima layanan. | ||
| Deskripsi Atribut ini adalah Nomor Rekam Medis (MRN) atau pengenal unik lain untuk pasien. Atribut ini menghubungkan peristiwa penagihan keuangan dengan individu tertentu. Untuk melindungi privasi pasien, atribut ini biasanya tidak digunakan sebagai dimensi analisis utama. Namun, atribut ini penting untuk validasi data dan dapat digunakan untuk menggabungkan semua peristiwa penagihan seorang pasien agar perjalanan keuangannya dapat dipahami secara menyeluruh. Atribut ini juga penting untuk kemungkinan integrasi dengan data proses klinis. Mengapa ini penting Menghubungkan data keuangan dengan pasien tertentu untuk memvalidasi data dan memungkinkan analisis yang lebih luas atas seluruh perjalanan pasien. Namun, data ini harus ditangani dengan hati-hati demi menjaga privasi. Sumber data Pengenal dasar yang digunakan di berbagai bagian Epic dan terhubung dengan catatan pendaftaran serta akun pasien. Contoh MRN-1234567MRN-8765432MRN-5551234 | |||
| Jumlah penyesuaian AdjustedAmount | Nilai uang dari transaksi penyesuaian. | ||
| Deskripsi Kolom ini mencatat jumlah spesifik dalam mata uang akun yang disesuaikan. Nilainya bisa positif atau negatif, yang menunjukkan kredit atau debit pada saldo akun. Jumlah ini menjadi metrik utama untuk dashboard 'Volume penyesuaian akun berdasarkan jenis'. Dengan menjumlahkan nilai berdasarkan alasan penyesuaian, Anda dapat melihat dampak keuangan setiap jenis penyesuaian. Contohnya, berapa banyak pendapatan yang dihapus karena kewajiban kontrak dibandingkan dengan kerugian akibat kesalahan yang sebenarnya bisa diperbaiki. Mengapa ini penting Mengukur dampak keuangan penyesuaian akun, sehingga kebocoran pendapatan dan biaya akibat ketidakakuratan penagihan dapat diketahui. Sumber data Tersimpan di tabel detail transaksi keuangan Epic Resolute dan terkait dengan transaksi jenis penyesuaian. Contoh -1250.45-50.0025.10 | |||
| Nama penanggung PayerName | Nama perusahaan asuransi, lembaga pemerintah, atau pihak lain yang bertanggung jawab membayar. | ||
| Deskripsi Atribut ini menunjukkan penanggung utama untuk suatu peristiwa penagihan, seperti 'Blue Cross Blue Shield', 'Medicare', atau 'Aetna'. Untuk pembayaran mandiri, atribut ini dapat menunjukkan pasien. Mengelompokkan proses berdasarkan penanggung merupakan teknik analisis yang berguna. Anda dapat mengetahui apakah penanggung tertentu memiliki tingkat penolakan lebih tinggi, siklus pembayaran lebih lama, atau persyaratan yang lebih rumit. Temuan ini membantu menyesuaikan strategi penagihan untuk setiap penanggung agar proses lebih efisien dan pembayaran lebih cepat. Mengapa ini penting Atribut ini memungkinkan analisis kinerja berdasarkan penanggung. Anda dapat menemukan penanggung dengan tingkat penolakan tinggi atau siklus pembayaran lambat, lalu menentukan strategi tindak lanjut yang tepat. Sumber data Informasi ini merupakan bagian dari detail cakupan pasien yang terhubung ke akun rumah sakit (HAR) di Epic Resolute. Contoh Medicare Part BUnitedHealthcareAetna PPO | |||
| Pembaruan data terakhir LastDataUpdate | Stempel waktu yang menunjukkan kapan data untuk peristiwa ini terakhir diperbarui atau diekstrak dari sistem sumber. | ||
| Deskripsi Atribut ini menunjukkan kebaruan data, yaitu kapan catatan terakhir diambil dari Epic Resolute ke dataset process mining. Informasi ini penting untuk memahami ketepatan waktu analisis dan memvalidasi data. Pengguna dapat mengetahui apakah data yang dilihat merupakan informasi terbaru yang tersedia. Atribut ini juga penting untuk mengelola siklus pembaruan data. Mengapa ini penting Atribut ini membantu pengguna memahami seberapa baru data yang dianalisis. Informasi tersebut penting untuk mengambil keputusan bisnis yang akurat berdasarkan data terkini. Sumber data Stempel waktu ini ditambahkan oleh proses ETL (Extract, Transform, Load) saat data dimasukkan. Contoh 2023-06-10T02:00:00Z2023-06-11T02:00:00Z | |||
| Sistem sumber SourceSystem | Sistem informasi asal data. | ||
| Deskripsi Atribut ini menunjukkan sistem asal catatan. Dalam konteks ini, sistemnya adalah Epic Resolute. Jika beberapa sistem terintegrasi, kolom ini membantu membedakan asal data. Meski tampak berulang jika hanya ada satu sistem, pencatatan ini merupakan praktik yang baik untuk tata kelola data dan skalabilitas. Asal data tetap jelas jika kelak data dari sistem lain, seperti platform agen penagihan terpisah, ikut diintegrasikan. Mengapa ini penting Atribut ini memberikan informasi penting tentang asal-usul dan konteks data. Dengan begitu, asal data jelas, sehingga tata kelola data dan pemecahan masalah lebih mudah. Sumber data Biasanya berupa nilai tetap yang ditambahkan saat proses ekstraksi dan transformasi data untuk menandai asal dataset. Contoh Epic ResoluteEpicResolute_V2023 | |||
| Tanggal jatuh tempo pembayaran PaymentDueDate | Tanggal batas pembayaran untuk layanan yang ditagihkan. | ||
| Deskripsi Atribut ini menunjukkan batas waktu pembayaran yang tercantum pada faktur atau ditetapkan dalam kontrak dengan pembayar. Tanggal ini menjadi acuan untuk mengukur ketepatan waktu pembayaran. Tanggal jatuh tempo pembayaran diperlukan untuk membuat 'Laporan umur saldo tertunggak'. Dengan membandingkan tanggal saat ini dengan tanggal jatuh tempo saldo yang belum dibayar, piutang dapat dikelompokkan berdasarkan umur, misalnya 0-30 hari atau 31-60 hari lewat jatuh tempo. Pengelompokan ini membantu menentukan prioritas penagihan untuk akun yang paling lama tertunggak. Mengapa ini penting Menjadi dasar analisis umur piutang, yang penting untuk menentukan prioritas penagihan dan mengelola risiko keuangan akibat tagihan yang belum dibayar. Sumber data Tanggal ini biasanya dihitung berdasarkan tanggal faktur dan ketentuan pembayaran yang tersimpan dalam kontrak pembayar atau informasi akun pasien di Epic. Contoh 2023-05-302023-06-152023-07-01 | |||
| Total waktu siklus pendapatan TotalRevenueCycleTime | Total durasi yang dihitung dari peristiwa layanan pertama hingga pembayaran terakhir atau penutupan akun. | ||
| Deskripsi KPI tingkat kasus ini mengukur durasi siklus pendapatan dari awal hingga akhir untuk satu peristiwa penagihan. Biasanya, durasi dihitung dari selisih waktu antara aktivitas 'Layanan diberikan' dan aktivitas terakhir, yaitu 'Pembayaran diterima' atau 'Akun ditutup'. Metrik tingkat tinggi ini memberikan gambaran menyeluruh tentang efisiensi proses RCM. Dengan melacak KPI ini dari waktu ke waktu, Anda dapat mengukur dampak inisiatif perbaikan proses dan memantau kecepatan konversi layanan menjadi kas. Mengapa ini penting Memberikan gambaran efisiensi proses dari awal hingga akhir dan mengukur langsung waktu yang dibutuhkan untuk mengubah layanan menjadi kas. Sumber data Metrik ini dihitung di alat process mining dengan memilih peristiwa pertama dan terakhir pada setiap kasus, lalu menghitung selisih waktunya. Contoh 259200038880005184000 | |||
| Waktu akhir peristiwa EventEndTime | Stempel waktu yang menunjukkan kapan suatu aktivitas selesai. Data ini berguna untuk menghitung durasi aktivitas. | ||
| Deskripsi Atribut ini mencatat waktu selesainya suatu aktivitas. Banyak aktivitas berlangsung seketika, sehingga StartTime sama dengan EndTime. Namun, beberapa tugas memiliki durasi yang dapat diukur, misalnya panggilan tindak lanjut atas penolakan klaim. Jika tersedia, EndTime memungkinkan Anda menghitung langsung waktu pemrosesan aktivitas ('EndTime' - 'StartTime'). Cara ini lebih akurat daripada memperkirakan durasi dari waktu mulai aktivitas berikutnya karena memperhitungkan waktu jeda antar langkah. Atribut ini juga menjadi komponen penting untuk menghitung atribut 'ProcessingTime'. Mengapa ini penting Memungkinkan penghitungan durasi setiap aktivitas secara tepat. Informasi ini penting untuk menemukan tugas yang tidak efisien dan mengukur produktivitas sumber daya. Sumber data Data ini mungkin tersedia di beberapa modul Epic Resolute yang mencatat waktu mulai dan selesai tugas, seperti log antrean kerja atau pengelolaan aktivitas. Namun, waktu ini sering kali tidak dicatat secara eksplisit. Contoh 2023-04-15T09:45:00Z2023-04-16T11:15:30Z2023-05-01T14:02:00Z | |||
Aktivitas pengelolaan siklus pendapatan
| Aktivitas | Deskripsi | ||
|---|---|---|---|
| Akun ditutup | Ini adalah aktivitas terakhir. Saldo terutang pada peristiwa penagihan telah mencapai nol dan tidak ada aktivitas tertunda. Hal ini dapat terjadi karena pembayaran penuh, penyesuaian, atau penghapusan piutang. | ||
| Mengapa ini penting Peristiwa ini menandai selesainya siklus pendapatan untuk suatu peristiwa penagihan. Durasi dari layanan diberikan hingga akun ditutup merupakan KPI penting untuk mengukur efisiensi proses secara keseluruhan. Sumber data Peristiwa ini biasanya disimpulkan dari data. Tentukan kapan saldo akun untuk peristiwa penagihan mencapai nol dan tetap nol. Pengumpulan data Simpulkan dengan menghitung saldo akun berjalan dan menemukan stempel waktu transaksi terakhir yang membuat saldo menjadi nol. Jenis peristiwa inferred | |||
| Biaya layanan dicatat | Aktivitas ini mencatat secara resmi biaya yang dapat ditagihkan untuk layanan yang diberikan. Di Epic, biasanya berupa transaksi yang dicatat pada akun pasien, baik yang dibuat otomatis dari tindakan klinis maupun yang dimasukkan secara manual. | ||
| Mengapa ini penting Ini adalah tonggak awal yang penting. Mengukur kecepatan dan ketepatan pencatatan biaya membantu mempercepat penagihan dan memastikan semua layanan yang diberikan ditagihkan. Sumber data Tercatat secara langsung dalam log transaksi Resolute. Setiap biaya merupakan entri tersendiri yang memuat tanggal pencatatan, tanggal layanan, dan jumlah. Data ini sering ditemukan di tabel seperti ARPB_TRANSACTIONS. Pengumpulan data Ambil transaksi pencatatan biaya dari log transaksi keuangan sistem. Jenis peristiwa explicit | |||
| Klaim diajukan kepada penanggung | Peristiwa ini menandai saat klaim resmi dikirim kepada penanggung asuransi untuk diproses. Di Epic, peristiwa ini dilacak dan dicatat saat berkas klaim elektronik dikirim ke clearinghouse atau penanggung. | ||
| Mengapa ini penting Tonggak ini penting karena memulai penghitungan waktu pembayaran oleh penanggung. Analisis tahap ini membantu mengukur efisiensi pengiriman klaim dan mendukung KPI Waktu Pengiriman Faktur kepada Penanggung. Sumber data Peristiwa ini tercatat secara langsung di Resolute. Catatan klaim memuat status pengajuan dan stempel waktu pengirimannya. Pengumpulan data Ambil stempel waktu saat status klaim berubah menjadi 'Submitted' atau 'Transmitted'. Jenis peristiwa explicit | |||
| Klaim ditolak penanggung | Peristiwa ini menandai diterimanya pemberitahuan dari penanggung bahwa klaim ditolak. Data ini tercatat saat Epic memproses electronic remittance advice (berkas 835) atau saat pengguna memasukkan penolakan secara manual. | ||
| Mengapa ini penting Aktivitas ini memulai rangkaian pengerjaan ulang yang penting. Menganalisis alasan dan jumlah penolakan membantu menemukan penyebab utama, meningkatkan tingkat pembayaran pada pengajuan pertama, dan mengurangi keterlambatan penagihan. Sumber data Tercatat secara langsung sebagai transaksi atau pembaruan status pada klaim. Informasi penolakan, termasuk kode alasannya, biasanya diterima secara elektronik dan dicatat pada akun. Pengumpulan data Saring jenis transaksi atau pembaruan status klaim tertentu yang menunjukkan penolakan. Jenis peristiwa explicit | |||
| Layanan diberikan | Aktivitas ini menandai saat layanan klinis diberikan kepada pasien dan memulai peristiwa penagihan. Data ini biasanya tercatat di Epic EHR (EpicCare) saat tenaga klinis menyetujui kunjungan atau prosedur. | ||
| Mengapa ini penting Ini adalah peristiwa awal utama dalam siklus pendapatan. Mengukur waktu dari tahap ini hingga pencatatan biaya layanan penting untuk menemukan keterlambatan awal penagihan dan potensi kebocoran pendapatan. Sumber data Peristiwa ini biasanya disimpulkan dari stempel waktu layanan atau kunjungan di modul klinis yang terhubung ke akun penagihan. Tanggal layanan pada transaksi biaya menjadi titik data utama. Pengumpulan data Disimpulkan dari tanggal layanan yang terkait dengan transaksi biaya pertama untuk peristiwa penagihan. Jenis peristiwa inferred | |||
| Pembayaran dicatat pada akun | Peristiwa ini terjadi saat pembayaran yang diterima diterapkan atau dialokasikan ke biaya tertentu pada akun pasien. Tindakan ini mengurangi saldo terutang untuk peristiwa penagihan. | ||
| Mengapa ini penting Pencatatan pembayaran yang efisien penting untuk menjaga ketepatan saldo akun dan menuntaskan peristiwa penagihan. Dengan begitu, sisa saldo dapat diketahui dengan tepat untuk penagihan sekunder atau penagihan piutang. Sumber data Ini merupakan transaksi yang tercatat secara langsung di Resolute. Pencatatan pembayaran menghubungkan transaksi pembayaran dengan satu atau beberapa transaksi biaya, dan hubungan ini tercatat di tabel detail transaksi. Pengumpulan data Ambil catatan transaksi yang menerapkan pembayaran ke suatu biaya. Transaksi ini dapat dikenali dari jenis transaksi tertentu. Jenis peristiwa explicit | |||
| Pembayaran diterima | Peristiwa ini menandai diterimanya pembayaran dari penanggung atau pasien. Biasanya tercatat saat electronic remittance advice (ERA) dimuat atau cek manual dimasukkan ke sistem. | ||
| Mengapa ini penting Aktivitas ini merupakan tonggak penting yang menandakan pendapatan mulai diterima. Waktu antara pengajuan klaim dan penerimaan pembayaran menjadi ukuran utama kinerja piutang usaha. Sumber data Tercatat secara langsung sebagai transaksi pembayaran di Resolute. Transaksi ini memuat tanggal, sumber, dan jumlah, sering kali sebelum dialokasikan sepenuhnya ke biaya tertentu. Pengumpulan data Ambil transaksi pembayaran dari log transaksi keuangan, biasanya dengan menyaring jenis transaksi tertentu. Jenis peristiwa explicit | |||
| Klaim diajukan ulang | Peristiwa ini terjadi setelah klaim yang ditolak diperbaiki dan dikirim kembali kepada penanggung. Pengajuan ini merupakan peristiwa tersendiri yang terhubung dengan klaim awal. | ||
| Mengapa ini penting Ini bagian penting dari rangkaian pengerjaan ulang. Mengukur waktu hingga pengajuan ulang dan tingkat keberhasilan klaim yang diajukan ulang penting untuk memahami efektivitas proses penyelesaian penolakan. Sumber data Peristiwa ini tercatat secara langsung seperti pengajuan awal, tetapi biasanya ditandai sebagai pengajuan ulang. Catatan klaim memuat stempel waktu pengajuan baru dan mungkin juga kode pengajuan ulang. Pengumpulan data Ambil stempel waktu pengajuan klaim yang ditandai sebagai koreksi atau pengajuan ulang. Jenis peristiwa explicit | |||
| Klaim dibuat | Aktivitas ini menandai saat sistem membuat klaim atau faktur resmi berdasarkan biaya yang telah dicatat. Ini merupakan tahap persiapan sebelum klaim dikirim kepada penanggung atau pasien. | ||
| Mengapa ini penting Dengan melacak pembuatan klaim, Anda dapat menemukan keterlambatan antara pencatatan biaya dan persiapan klaim untuk diajukan. Tahap internal ini dapat memengaruhi ketepatan waktu penagihan secara keseluruhan. Sumber data Biasanya tercatat saat proses batch pembuatan tagihan atau klaim dijalankan. Sistem mencatat stempel waktu ketika berkas klaim, seperti berkas 837, dibuat untuk suatu akun. Pengumpulan data Temukan entri log atau perubahan status yang menunjukkan klaim telah disusun dan siap diajukan. Jenis peristiwa explicit | |||
| Penyesuaian akun dilakukan | Aktivitas ini mencatat transaksi selain pembayaran yang mengubah saldo akun, seperti penyesuaian kontrak, penghapusan saldo kecil, atau diskon sebagai bentuk itikad baik. Transaksi ini tercatat dengan jenis khusus. | ||
| Mengapa ini penting Analisis penyesuaian penting untuk menemukan kebocoran pendapatan. Jumlah penyesuaian tertentu yang tinggi dapat menunjukkan masalah pada daftar tarif, kontrak, atau kebijakan internal. Sumber data Tercatat secara langsung sebagai transaksi penyesuaian dalam log keuangan Resolute. Setiap penyesuaian memiliki jenis atau kode alasan tertentu. Pengumpulan data Saring jenis transaksi yang berkaitan dengan penyesuaian keuangan atau penghapusan piutang. Jenis peristiwa explicit | |||
| Saldo dikirim ke penagihan piutang | Tahap ini menandai saat saldo akun yang belum dibayar dialihkan ke proses penagihan internal atau eksternal. Biasanya, status akun atau peristiwa penagihan berubah secara langsung. | ||
| Mengapa ini penting Aktivitas ini memulai tahap akhir penagihan saldo yang belum dibayar. Melacak tingkat keberhasilan dan waktu siklus penagihan penting untuk mengurangi piutang tak tertagih. Sumber data Biasanya tercatat sebagai peristiwa langsung. Epic menyediakan fungsi untuk mengalihkan akun ke agen penagihan, yang akan membuat entri log atau mengubah status akun. Pengumpulan data Temukan perubahan status atau transaksi yang menunjukkan akun telah diserahkan kepada agen penagihan. Jenis peristiwa explicit | |||
| Tindak lanjut penolakan dimulai | Aktivitas ini menandai dimulainya proses internal untuk meninjau dan menyelesaikan klaim yang ditolak. Biasanya tercatat saat pengguna mengambil alih klaim yang ditolak di antrean kerja atau mengubah statusnya. | ||
| Mengapa ini penting Data ini membantu mengukur kecepatan respons tim penanganan penolakan. Keterlambatan antara penolakan dan dimulainya tindak lanjut dapat memperpanjang siklus pendapatan. Sumber data Biasanya disimpulkan dari perubahan status klaim atau riwayat penugasannya di antrean kerja Epic. Contohnya, status klaim berubah dari 'Denied' menjadi 'In Review'. Pengumpulan data Simpulkan dari perubahan status klaim atau entri log audit yang menunjukkan pengguna mulai menangani penolakan. Jenis peristiwa inferred | |||
Panduan ekstraksi
Langkah
- Buat koneksi ke database: Dapatkan kredensial hanya-baca untuk database Epic Clarity. Gunakan klien SQL standar, seperti DBeaver atau Microsoft SQL Server Management Studio, untuk terhubung ke server database.
- Tentukan tabel utama: Tabel utama untuk ekstraksi ini mencakup
HSP_ACCOUNTuntuk informasi kasus,HSP_TRANSACTIONSuntuk peristiwa keuangan,CLP_CLAIM_INFOuntuk status klaim, danF_ARHB_TX_SET_POST_HXuntuk detail pencatatan pembayaran. Anda juga perlu menggabungkan file master sepertiCLARITY_EMPuntuk detail pengguna. - Tentukan cakupan: Sebelum menulis kueri, tentukan cakupan analisis. Tetapkan rentang tanggal tertentu, biasanya 3 hingga 6 bulan, lalu tentukan area layanan rumah sakit (
SERV_AREA_ID) atau kelas akun yang ingin disertakan atau dikecualikan. - Susun kueri SQL: Buat kueri SQL dengan Common Table Expression (CTE) untuk memilih terlebih dahulu nilai
HSP_ACCOUNT_IDyang termasuk dalam cakupan. Hasil ini menjadi populasi dasar peristiwa penagihan. - Gabungkan kueri aktivitas satu per satu: Untuk masing-masing dari 12 aktivitas yang diperlukan, tulis pernyataan
SELECTterpisah untuk mengambil data dari tabel terkait. Gabungkan setiap kueri dengan CTE awal agar hanya akun yang ditentukan yang dianalisis. - Gabungkan kueri dengan UNION ALL: Gunakan operator
UNION ALLuntuk menggabungkan hasil semua kueri aktivitas menjadi satu log peristiwa. Operator ini menumpuk baris dari setiap kueri secara vertikal. - Sesuaikan dengan skema standar: Di setiap pernyataan
SELECT, beri alias pada kolom agar sesuai dengan skema ProcessMind yang diperlukan, sepertiBillingEvent,ActivityName,EventTimestamp, danResponsibleUser. GunakanNULLuntuk atribut yang tidak berlaku bagi aktivitas tertentu. - Jalankan dan sempurnakan kueri: Jalankan kueri lengkap pada database Clarity. Proses ini mungkin memerlukan waktu cukup lama karena ukuran tabel. Jika kinerjanya bermasalah, persempit rentang tanggal atau tambahkan filter yang lebih spesifik pada CTE awal.
- Periksa hasil: Setelah kueri selesai, periksa beberapa ratus baris pertama. Pastikan semua kolom tersedia, stempel waktu menggunakan format yang konsisten, dan nilai
ActivityNameyang berbeda muncul sesuai harapan. - Ekspor ke CSV: Ekspor seluruh hasil dari klien SQL ke file CSV. Pastikan file menggunakan encoding UTF-8 dan memiliki baris header dengan nama kolom yang benar.
- Siapkan file untuk diunggah: Sebelum mengunggah ke ProcessMind, buka file CSV dan pastikan tidak ada kesalahan format. Periksa konsistensi format stempel waktu, misalnya
YYYY-MM-DD HH:MI:SS. File kini siap dimuat.
Konfigurasi
- Koneksi database: Anda memerlukan akun pengguna hanya-baca yang memiliki akses ke database Epic Clarity.
- Parameter rentang tanggal: Kueri yang disediakan menggunakan variabel
@StartDatedan@EndDate. Tetapkan nilai variabel ini untuk menentukan periode analisis. Rentang 3 hingga 6 bulan disarankan agar volume data tetap seimbang dengan kinerja. - Pemetaan tabel dan kolom: Kueri ini mengasumsikan nama tabel dan kolom Clarity standar. Konfigurasi atau versi Epic di organisasi Anda mungkin berbeda. Sesuaikan nama tabel, nama kolom, atau kondisi penggabungan bila diperlukan.
- Kode transaksi dan status: Kueri ini memuat penanda tempat seperti
[Your Denial Tx Type]dan[Your Collections Status Code]. Hubungi administrator sistem Epic atau periksa file master terkait, sepertiZC_TX_TYPEatauZC_ACCOUNT_STATUS, untuk menemukan kode yang benar bagi sistem Anda. - Pemfilteran: Untuk meningkatkan kinerja dan memusatkan analisis, tambahkan filter ke CTE
BaseAccountsawal. Filter yang umum mencakupSERV_AREA_IDuntuk membatasi area layanan rumah sakit atauACCOUNT_CLASS_Cuntuk memilih penagihan rawat inap atau rawat jalan.
Contoh kueri 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; Langkah
- Pastikan Anda memiliki akses resmi ke kumpulan data siklus pendapatan Epic Clarity, termasuk tabel dan tampilan sumber yang diperlukan untuk riwayat akun, biaya, klaim, penolakan, pembayaran, penyesuaian, penagihan, dan penutupan. Ketersediaan tabel dan penamaan kolom berbeda antarorganisasi Epic. Petakan setiap penanda tempat dalam kueri ke objek Clarity yang sesuai di lingkungan Anda.
- Tentukan periode ekstraksi menggunakan [Start date parameter] dan [End date parameter]. Mulailah dengan periode tiga hingga enam bulan, lalu perpanjang hanya setelah memvalidasi kinerja kueri dan kelengkapan peristiwa.
- Tetapkan pemetaan BillingEvent. Jika tersedia, kueri menggunakan HSP_ACCOUNT.HSP_ACCOUNT_ID sebagai pengenal kasus bawaan. Jika organisasi Anda menetapkan peristiwa penagihan pada tingkat biaya, klaim, atau kunjungan, ganti pemetaan tersebut dengan pengenal yang disetujui dan gunakan pengenal yang sama secara konsisten di setiap sumber aktivitas.
- Petakan setiap aktivitas sumber ke stempel waktu dan atribut sumber yang berwenang. Untuk Service Rendered, gunakan stempel waktu penyelesaian layanan atau kunjungan yang terdokumentasi. Untuk Charges Captured, gunakan stempel waktu pencatatan biaya. Untuk Claim Generated dan Claim Submitted to Payer, gunakan stempel waktu yang sesuai dalam siklus klaim. Penolakan, tindak lanjut, pengajuan ulang, pembayaran, penyesuaian, penagihan, dan penutupan harus menggunakan stempel waktu transaksi atau status yang terdokumentasi.
- Ganti semua penanda tempat sumber dalam tanda kurung siku pada kueri, termasuk [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], dan [Your account closure source table]. Jangan mengganti kode transaksi yang belum terdokumentasi. Gunakan nilai transaksi atau status yang disetujui tim pelaporan Epic Anda.
- Jalankan kueri di klien SQL atau platform pelaporan yang disetujui organisasi. Pastikan semua dua belas label aktivitas muncul sebagai baris tersendiri. ProcessMind tidak menyimpulkan peristiwa siklus yang hilang dari saldo, status, atau urutan peristiwa.
- Periksa skema hasil. Hasil harus memuat BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, dan ServiceType. Sertakan dokumentasi zona waktu atau waktu lokal pada stempel waktu. Jika diizinkan, simpan pengenal sumber dalam ekstrak audit internal.
- Validasi urutan kronologis dalam setiap BillingEvent, duplikasi, tingkat nilai kosong, jumlah aktivitas, dan rekonsiliasi dengan laporan sistem sumber. Periksa peristiwa di luar periode yang diminta jika diperlukan untuk memahami kasus yang dimulai sebelum atau berakhir setelah periode tersebut.
- Ekspor hasil sebagai file berpemisah atau melalui koneksi database yang didukung ProcessMind. Gunakan satu baris untuk setiap peristiwa, nama kolom yang konsisten, format stempel waktu yang seragam, encoding UTF-8, serta tanpa sel gabungan atau total untuk penyajian. Saat mengunggah, tetapkan BillingEvent sebagai pengenal kasus, ActivityName sebagai aktivitas, dan EventTimestamp sebagai stempel waktu peristiwa.
Konfigurasi
- Pemetaan sumber: Implementasi Epic Clarity berbeda-beda. Ganti setiap penanda tempat objek sumber dan kolom dalam tanda kurung siku dengan tabel, tampilan, atau lapisan pelaporan yang disetujui dan terdokumentasi di lingkungan Anda. Jangan berasumsi suatu tabel atau kolom tersedia hanya karena umum digunakan pada implementasi Epic lain.
- Pengenal kasus: Pemetaan kueri bawaan menggunakan HSP_ACCOUNT.HSP_ACCOUNT_ID. Pastikan apakah organisasi Anda menetapkan BillingEvent sebagai akun, kunjungan, klaim, biaya, atau kunci bisnis lain yang disetujui.
- Rentang tanggal: Mulailah dengan tiga hingga enam bulan. Sertakan periode penelusuran ke belakang jika kasus dapat dimulai sebelum jendela pelaporan, dan sertakan periode tindak lanjut jika klaim, penolakan, pembayaran, atau penutupan dapat terjadi setelah tanggal layanan.
- Stempel waktu aktivitas: Tetapkan satu stempel waktu yang berwenang untuk setiap aktivitas. Jangan mengganti waktu peristiwa bisnis yang sebenarnya dengan waktu ekstraksi, waktu pemuatan file, atau waktu status saat ini, kecuali sumber sistem mendokumentasikannya sebagai stempel waktu peristiwa.
- Filter: Terapkan filter [Company Code filter], [Document Type filter], [Department filter], pembayar, area layanan, dan kelas akun hanya jika definisinya terdokumentasi dan diperlukan untuk analisis. Gunakan filter yang sama di semua bagian UNION ALL.
- Pemetaan transaksi dan status: Tetapkan nilai yang disetujui organisasi untuk pencatatan biaya, pembuatan klaim, pengajuan klaim, penolakan, tindak lanjut, pengajuan ulang, penerimaan pembayaran, pencatatan pembayaran, penyesuaian, penagihan, dan penutupan. Kueri ini sengaja menggunakan penanda tempat karena nilai transaksi dan struktur sumber Epic berbeda-beda antarimplementasi.
- Penanganan nilai kosong: Pertahankan NULL untuk atribut yang tidak berlaku bagi suatu aktivitas. Jangan mengisi alasan penolakan, alasan penyesuaian, pengguna, departemen, atau jenis layanan yang tidak tersedia dengan nilai rekaan.
- Kinerja: Batasi baris sumber menggunakan kolom tanggal yang terindeks dan filter organisasi yang disetujui sebelum menggabungkannya dengan HSP_ACCOUNT. Hindari penggunaan fungsi pada kolom stempel waktu terindeks dalam kondisi kueri. Jika riwayat mentah berukuran besar, pertimbangkan untuk menyiapkan setiap aktivitas sumber dalam tampilan pelaporan yang disetujui.
- Penghapusan duplikasi: Jangan menghapus peristiwa duplikat tanpa aturan yang terdokumentasi. Beberapa pembayaran, penyesuaian, pengajuan, atau perubahan status dapat menjadi peristiwa yang sah untuk satu BillingEvent.
- Prasyarat: Akses yang diperlukan mungkin mencakup otorisasi pelaporan Epic Clarity, akses ke data siklus pendapatan dan riwayat akun, lingkungan eksekusi SQL yang disetujui, serta persetujuan organisasi untuk informasi kesehatan yang dilindungi. Ketersediaan riwayat klaim, pengiriman pembayaran, antrean kerja, penagihan, dan penutupan bergantung pada modul serta antarmuka Epic yang dilisensikan dan diterapkan.
Contoh kueri 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; Siap memulai?
Gunakan data yang akurat untuk mengoptimalkan proses pengelolaan siklus pendapatan Anda. Mulai tingkatkan efisiensi dan kinerja keuangan hari ini.
Tingkatkan efisiensi: optimalkan pengelolaan siklus pendapatan sekarang
Temukan inefisiensi RCM di Epic Resolute dan kurangi waktu siklus hingga 30%.
Tidak perlu kartu kredit. Mulai optimalkan proses hari ini.