Templat data pengelolaan siklus pendapatan Anda
Templat data pengelolaan siklus pendapatan Anda
- Atribut data yang disarankan untuk analisis menyeluruh
- Aktivitas proses utama yang perlu dilacak
- Panduan praktis untuk mengekstrak data dari Waystar
Atribut pengelolaan siklus pendapatan
| Nama | Deskripsi | ||
|---|---|---|---|
| Nama aktivitas ActivityName | Nama peristiwa bisnis atau langkah tertentu yang terjadi dalam proses siklus pendapatan, seperti “Klaim dikirim” atau “Pembayaran dibukukan”. | ||
| Deskripsi Atribut ini menjelaskan aktivitas yang membentuk proses siklus pendapatan dari awal hingga akhir. Setiap nilai mewakili langkah, pencapaian, atau tugas tertentu pada peristiwa penagihan, seperti membuat klaim, menerima penolakan, atau membukukan pembayaran. Menganalisis urutan dan frekuensi aktivitas ini menjadi dasar process mining. Analisis ini memungkinkan Anda melihat peta proses, menemukan proses pengerjaan ulang, misalnya “Klaim ditolak” yang diikuti “Klaim diperbaiki”, serta mengukur waktu antar langkah. Hal ini penting untuk memahami efisiensi proses dan kepatuhan. Mengapa ini penting Atribut ini menentukan langkah-langkah dalam peta proses, yang menjadi dasar untuk memvisualisasikan dan menganalisis alur kerja siklus pendapatan. Sumber data Dihasilkan dari log peristiwa, catatan perubahan status, atau jenis transaksi dalam modul klaim dan penagihan Waystar. Contoh Klaim dikirim ke penjaminKlaim ditolakPembayaran dibukukanAkun ditutup | |||
| Peristiwa penagihan BillingEvent | ID unik untuk satu layanan atau produk yang diberikan dan menghasilkan tagihan. ID ini menjadi kasus dalam proses siklus pendapatan. | ||
| Deskripsi Peristiwa penagihan berfungsi sebagai ID kasus utama yang menghubungkan semua aktivitas, mulai dari pencatatan tagihan hingga penutupan akun untuk layanan tertentu yang dapat ditagihkan. Peristiwa ini mewakili seluruh siklus satu klaim atau tagihan pasien. Dalam process mining, analisis perjalanan setiap peristiwa penagihan memberikan gambaran menyeluruh tentang siklus pendapatan. Analisis ini membantu menemukan jalur proses yang umum, penyimpangan, dan hambatan yang memengaruhi klaim tertentu. Rincian ini penting untuk memahami kinerja proses dan menemukan bagian yang perlu diperbaiki, seperti keterlambatan pengiriman klaim atau pembukuan pembayaran. Mengapa ini penting Ini adalah ID kasus utama yang menghubungkan semua aktivitas terkait siklus pendapatan, sehingga proses dari awal hingga akhir dapat ditelusuri untuk setiap item yang dapat ditagihkan. Sumber data Biasanya berupa kunci utama dari tabel transaksi penagihan atau klaim utama di Waystar. Lihat dokumentasi Waystar untuk mengetahui nama tabel dan kolom yang tepat. Contoh BE-2024-0012345BE-2024-0012346BE-2024-0012347 | |||
| Stempel waktu peristiwa EventTimestamp | Tanggal dan waktu tepat saat aktivitas terjadi. | ||
| Deskripsi Stempel waktu peristiwa mencatat waktu tepat saat suatu aktivitas berlangsung. Stempel waktu ini penting untuk mengurutkan peristiwa secara kronologis dan menghitung durasi antar langkah dalam proses. Dalam analisis proses, stempel waktu digunakan untuk menghitung indikator kinerja utama seperti waktu siklus, waktu tunggu, dan waktu pemrosesan. Contohnya, selisih antara stempel waktu “Klaim dikirim” dan “Pembayaran dibukukan” menunjukkan total waktu siklus pembayaran. Stempel waktu yang akurat penting untuk menganalisis hambatan dan memantau kinerja. Mengapa ini penting Stempel waktu diperlukan untuk mengurutkan peristiwa, menghitung waktu siklus, dan menganalisis kinerja proses. Data ini menjadi dasar waktu dalam analisis. Sumber data Ini adalah kolom standar yang tersedia pada hampir setiap transaksi atau catatan perubahan status di Waystar. Namanya sering berupa “Tanggal dibuat”, “Tanggal transaksi”, atau sejenisnya. Contoh 2023-10-26T10:00:00Z2023-10-27T14:35:10Z2023-11-05T09:15:00Z | |||
| Pembaruan data terakhir LastDataUpdate | Stempel waktu yang menunjukkan kapan data untuk peristiwa ini terakhir kali diperbarui atau diekstrak. | ||
| Deskripsi Atribut ini mencatat waktu terakhir data diekstrak dari sistem sumber. Ini bukan waktu terjadinya peristiwa bisnis, melainkan waktu catatan diambil untuk dianalisis. Informasi ini penting untuk tata kelola data dan mengetahui seberapa baru data dalam analisis process mining. Pengguna dapat memastikan apakah informasi yang dilihat sudah terbaru. Informasi ini juga penting untuk mengelola pemuatan data bertahap. Mengapa ini penting Menunjukkan kebaruan data agar informasi tetap transparan. Hal ini penting untuk pelaporan dan analisis yang akurat dan tepat waktu. Sumber data Stempel waktu ini biasanya dibuat dan ditambahkan ke setiap baris oleh proses ETL (Extract, Transform, Load) saat data dimasukkan. Contoh 2024-01-15T02:00:00Z2024-01-16T02:00:00Z | |||
| Sistem sumber SourceSystem | Sistem atau aplikasi asal data peristiwa. | ||
| Deskripsi Atribut ini menunjukkan sistem sumber yang menghasilkan data peristiwa. Dalam lingkungan TI yang kompleks, peristiwa siklus pendapatan dapat berasal dari berbagai modul Waystar atau sistem eksternal terintegrasi, seperti Electronic Health Record (EHR). Mengetahui sistem sumber penting untuk memvalidasi data, mengatasi masalah, dan memahami variasi proses yang mungkin disebabkan oleh perbedaan perilaku sistem. Informasi ini membantu mengaitkan masalah proses dengan aplikasi atau antarmuka yang tepat. Mengapa ini penting Menunjukkan asal data. Informasi ini penting untuk tata kelola data, jaminan kualitas, dan memahami variasi proses di berbagai sistem. Sumber data Sering kali berupa nilai tetap (“Waystar”) yang ditambahkan saat ekstraksi data, atau dapat ditentukan dari modul atau tabel tertentu dalam sistem. Contoh Waystar RCMModul penagihan WaystarAntarmuka EHR | |||
| Jenis layanan ServiceType | Kategori atau jenis layanan medis yang diberikan, seperti “Radiologi”, “Konsultasi”, atau “Prosedur bedah”. | ||
| Deskripsi Jenis layanan mengelompokkan layanan yang diberikan kepada pasien dan dapat ditagihkan. Setiap jenis layanan biasanya memiliki kode penagihan, tarif penggantian biaya, dan tingkat kerumitan proses yang berbeda. Atribut ini memungkinkan analisis siklus pendapatan secara terperinci berdasarkan departemen klinis atau lini layanan. Atribut ini membantu menjawab pertanyaan seperti, “Lini layanan mana yang paling sering mengalami keterlambatan penagihan?” atau “Apakah tingkat penolakan prosedur bedah lebih tinggi daripada konsultasi?” Informasi ini penting untuk menganalisis kinerja departemen dan menentukan perbaikan proses yang tepat. Mengapa ini penting Memungkinkan analisis kinerja proses berdasarkan departemen klinis atau lini layanan, sehingga perbedaan efisiensi dan profitabilitas dapat diketahui. Sumber data Biasanya ditentukan dari kode prosedur (CPT/HCPCS) atau dikaitkan dengan departemen yang memberikan layanan di Waystar. Contoh RadiologiKonsultasi kardiologiKunjungan ke unit gawat daruratOperasi rawat jalan | |||
| Jumlah tagihan BilledAmount | Total biaya yang ditagihkan untuk layanan yang diberikan dalam klaim. | ||
| Deskripsi Jumlah tagihan adalah total biaya kotor untuk layanan yang diberikan kepada pasien, sebelum penyesuaian, pengurangan sesuai kontrak, atau pembayaran diterapkan. Nilai ini merupakan jumlah awal klaim yang diajukan kepada payer. Atribut ini penting untuk analisis keuangan dan memahami nilai uang yang mengalir dalam proses. Atribut ini dapat digunakan untuk mengelompokkan analisis berdasarkan nilai klaim, menemukan tren biaya untuk berbagai layanan, dan menghitung dampak keuangan dari inefisiensi proses seperti penolakan atau keterlambatan pembayaran. Ini adalah metrik dasar bagi sebagian besar dasbor keuangan. Mengapa ini penting Menunjukkan total nilai klaim, sehingga dampak keuangan dari keterlambatan proses, penolakan, dan penyesuaian dapat dianalisis. Sumber data Kolom keuangan standar pada klaim atau layar entri tagihan di Waystar. Contoh 150.001250.75540.50 | |||
| Kode alasan penolakan DenialReasonCode | Kode standar yang menunjukkan alasan payer menolak klaim. | ||
| Deskripsi Saat payer menolak klaim, payer memberikan kode alasan yang menjelaskan penolakan tersebut. Kode ini dapat menunjukkan masalah seperti informasi yang tidak lengkap, layanan yang tidak ditanggung, atau kesalahan pengodean. Atribut ini menyimpan kode tersebut. Menganalisis kode alasan penolakan merupakan langkah penting untuk memperbaiki siklus pendapatan. Organisasi dapat menemukan penyebab utama penolakan, seperti kesalahan yang sering terjadi di departemen tertentu atau masalah dalam memenuhi persyaratan payer tertentu. Data ini menjadi dasar dasbor “Tingkat dan alasan penolakan klaim” serta membantu menyusun strategi untuk mencegah penolakan berikutnya dan meningkatkan tingkat pembayaran pada pengajuan pertama. Mengapa ini penting Atribut ini penting untuk menganalisis penyebab utama penolakan klaim, sehingga tindakan yang tepat dapat mengurangi kehilangan pendapatan dan pengerjaan ulang. Sumber data Diisi dalam catatan klaim saat terjadi penolakan. Informasi ini diterima dari payer melalui rincian pembayaran. Contoh CO-16: Informasi klaim/layanan tidak lengkapPR-96: Biaya layanan tidak ditanggungCO-22: Layanan ini mungkin ditanggung payer lain | |||
| Nama payer PayerName | Nama perusahaan asuransi atau payer pihak ketiga yang bertanggung jawab atas klaim. | ||
| Deskripsi Atribut ini menunjukkan payer tertentu, seperti perusahaan asuransi, program pemerintah seperti Medicare, atau entitas lain yang bertanggung jawab memutuskan dan membayar klaim. Setiap payer mungkin memiliki persyaratan pengajuan, jadwal pembayaran, dan pola penolakan yang berbeda. Menganalisis proses berdasarkan nama payer penting untuk mengetahui payer mana yang memiliki siklus pembayaran terlama, tingkat penolakan tertinggi, atau proses paling rumit. Organisasi dapat menyesuaikan strategi, memprioritaskan tindak lanjut kepada payer yang bermasalah, dan menegosiasikan kontrak yang lebih baik. Mengapa ini penting Mengelompokkan proses berdasarkan payer penting untuk menemukan hambatan, alasan penolakan, dan keterlambatan pembayaran yang spesifik pada payer tertentu. Sumber data Tersedia dalam informasi klaim atau penagihan dan terhubung dengan detail asuransi pasien di Waystar. Contoh AetnaBlue Cross Blue ShieldCignaMedicare Part B | |||
| Saldo terutang OutstandingBalance | Sisa jumlah yang masih harus ditagih untuk peristiwa penagihan. | ||
| Deskripsi Saldo terutang menunjukkan jumlah piutang usaha saat ini untuk suatu peristiwa penagihan. Nilainya dihitung dengan mengurangi pembayaran dan penyesuaian yang telah diterapkan dari jumlah tagihan. Metrik keuangan ini penting untuk mengelola arus kas dan piutang usaha. Metrik ini menjadi atribut utama dalam dasbor “Saldo terutang dan umur piutang”, yang membantu organisasi melacak total piutang, menemukan akun dengan saldo tinggi, dan memprioritaskan upaya penagihan. Memantau nilai ini dari waktu ke waktu menunjukkan efektivitas proses penagihan. Mengapa ini penting Mengukur piutang usaha secara langsung. Informasi ini penting untuk mengelola arus kas, memprioritaskan penagihan, dan menilai kesehatan keuangan. Sumber data Biasanya dihitung dalam modul pelaporan Waystar (Jumlah tagihan - Jumlah yang dibayar - Penyesuaian). Jika kolom langsung tidak tersedia, nilainya mungkin perlu dihitung saat ekstraksi data. Contoh 30.00270.25540.50 | |||
| Status klaim ClaimStatus | Status klaim saat ini dalam siklusnya, seperti “Diajukan”, “Menunggu”, “Dibayar”, atau “Ditolak”. | ||
| Deskripsi Status klaim menunjukkan posisi suatu peristiwa penagihan dalam siklus pendapatan pada waktu tertentu. Status ini menandai pencapaian terakhir, misalnya apakah klaim sudah dikirim, sedang ditinjau payer, sudah dibayar, atau ditolak. Atribut ini penting untuk pelaporan keuangan dan pengelolaan operasional. Dalam process mining, atribut ini membantu memahami kondisi terkini semua kasus yang masih terbuka dan menganalisis berapa lama kasus berada dalam status tertentu, seperti “Menunggu adjudikasi payer”. Informasi ini mendukung dasbor “Saldo terutang dan umur piutang” secara langsung. Mengapa ini penting Memberikan gambaran terkini tentang semua klaim yang sedang diproses, sehingga hambatan dapat dianalisis dan pekerjaan dapat diprioritaskan. Sumber data Kolom standar pada catatan klaim atau penagihan di Waystar, yang diperbarui seiring kemajuan klaim dalam siklus. Contoh DiajukanDiakui oleh payerDitolakDibayar lunas | |||
| ID pasien PatientId | ID unik pasien yang menerima layanan. | ||
| Deskripsi Atribut ini adalah ID unik pasien yang terkait dengan peristiwa penagihan. ID ini menghubungkan transaksi keuangan dengan orang yang menerima layanan. Peristiwa penagihan menjadi kasus, sedangkan ID pasien memungkinkan analisis yang berfokus pada pasien. ID ini dapat membantu menemukan pasien yang berkunjung berulang kali, memahami perjalanan keuangan pasien dari awal hingga akhir dalam beberapa kunjungan, dan menganalisis apakah demografi pasien tertentu berkaitan dengan masalah pembayaran atau tingkat penolakan yang lebih tinggi. ID ini juga memungkinkan semua aktivitas penagihan untuk satu orang digabungkan. Mengapa ini penting Memungkinkan analisis yang berfokus pada pasien dan memberikan gambaran perjalanan keuangan seseorang dalam beberapa peristiwa penagihan. Sumber data Kolom standar pada catatan klaim atau pendaftaran pasien di Waystar, atau ditautkan dari EHR. Contoh MRN-887654MRN-902101MRN-123456 | |||
| Jenis payer PayerType | Kategori payer, seperti “Komersial”, “Medicare”, atau “Bayar sendiri”. | ||
| Deskripsi Jenis payer mengelompokkan payer ke dalam kategori yang lebih luas berdasarkan karakteristiknya. Pengelompokan ini memberikan gambaran yang lebih umum daripada nama payer tertentu. Atribut ini berguna untuk analisis strategis dan pelaporan. Pimpinan dapat memahami tren kinerja di berbagai kategori payer utama, misalnya membandingkan kinerja keseluruhan payer pemerintah dengan perusahaan asuransi komersial. Informasi ini dapat membantu pengambilan keputusan strategis terkait kontrak payer dan alokasi sumber daya. Mengapa ini penting Memungkinkan analisis tingkat tinggi dengan mengelompokkan payer ke dalam kategori seperti komersial atau pemerintah, yang biasanya memiliki pola pembayaran dan aturan berbeda. Sumber data Biasanya ditentukan dengan memetakan nama payer ke daftar kategori yang telah ditetapkan. Logika ini mungkin tersedia di Waystar atau perlu dibuat saat transformasi data. Contoh KomersialMedicareMedicaidBayar sendiri | |||
| Jumlah penyesuaian AdjustedAmount | Total nilai keuangan yang disesuaikan atau dihapus untuk peristiwa penagihan. | ||
| Deskripsi Jumlah penyesuaian adalah total semua penyesuaian keuangan terhadap saldo suatu peristiwa penagihan. Ini mencakup pengurangan sesuai kontrak dengan pembayar, serta penghapusan atau koreksi lainnya. Metrik ini menjadi indikator utama dalam dashboard 'Tingkat dan dampak penyesuaian akun'. Dengan menjumlahkan nilai ini berdasarkan kode alasan atau pembayar, Anda dapat melihat dampak finansial dari kebocoran pendapatan. Metrik ini membantu mengukur kerugian dan menyusun alasan bisnis untuk menangani penyebab utama penyesuaian. Mengapa ini penting Mengukur pendapatan yang hilang akibat penghapusan dan penyesuaian, serta menunjukkan dampak finansial dari masalah penagihan dan ketentuan kontrak. Sumber data Bersumber dari transaksi penyesuaian keuangan di Waystar. Anda mungkin perlu menjumlahkan beberapa entri penyesuaian untuk satu peristiwa penagihan. Contoh 250.2550.0015.80 | |||
| Jumlah yang dibayar PaidAmount | Total pembayaran yang diterima dan dibukukan dari payer atau pasien untuk klaim. | ||
| Deskripsi Atribut ini mencatat total pembayaran yang berhasil diterima untuk suatu peristiwa penagihan. Jumlah ini mencakup pembayaran dari payer asuransi utama dan sekunder, serta pembayaran dari pasien. Jumlah yang dibayar merupakan metrik hasil utama dalam siklus pendapatan. Metrik ini digunakan untuk menghitung hasil akhir dari tagihan dan mengukur efektivitas seluruh proses. Membandingkan jumlah tagihan dengan jumlah yang dibayar menunjukkan kinerja keuangan dan membantu menemukan kebocoran pendapatan. Metrik ini penting bagi dasbor efektivitas penagihan dan kesehatan keuangan secara keseluruhan. Mengapa ini penting Mengukur kas yang benar-benar diterima. Ini merupakan metrik hasil utama untuk menilai keberhasilan keseluruhan proses siklus pendapatan. Sumber data Diperoleh dari transaksi pembukuan pembayaran yang terkait dengan klaim di Waystar. Jumlahnya mungkin perlu dihitung dengan menjumlahkan beberapa catatan pembayaran. Contoh 120.00980.500.00 | |||
| Kelas pasien PatientClass | Menunjukkan status pasien untuk kunjungan, seperti “Rawat inap” atau “Rawat jalan”. | ||
| Deskripsi Kelas pasien mengelompokkan jenis kunjungan pasien, yang sering menentukan aturan penagihan dan tarif penggantian biaya. Kelas yang umum mencakup rawat inap, rawat jalan, dan gawat darurat. Menganalisis siklus pendapatan berdasarkan kelas pasien dapat menunjukkan perbedaan proses yang signifikan. Contohnya, klaim rawat inap sering kali lebih rumit dan memiliki siklus pembayaran lebih panjang daripada klaim rawat jalan. Pengelompokan ini penting untuk menetapkan target kinerja yang realistis dan menyesuaikan inisiatif perbaikan proses dengan kebutuhan setiap kelas. Mengapa ini penting Membantu mengelompokkan proses berdasarkan tingkat kerumitan kunjungan, misalnya rawat inap dan rawat jalan, yang sering berkaitan dengan perbedaan aturan penagihan dan waktu siklus. Sumber data Kolom standar dalam data pendaftaran pasien atau kunjungan di Waystar maupun EHR sumber. Contoh Rawat inapRawat jalanGawat darurat | |||
| Kode alasan penyesuaian AdjustmentReasonCode | Kode yang menjelaskan alasan penyesuaian keuangan pada saldo akun. | ||
| Deskripsi Saat saldo akun berubah karena alasan selain pembayaran, seperti pengurangan sesuai kontrak atau penghapusan piutang, kode alasan penyesuaian digunakan untuk mencatat penyebabnya. Atribut ini menyimpan kode tersebut. Menganalisis kode ini penting untuk dasbor “Tingkat dan dampak penyesuaian akun”. Analisis ini membantu menemukan penyebab utama kebocoran pendapatan, seperti penyesuaian kontrak yang sering terjadi pada payer tertentu atau penghapusan piutang akibat kesalahan penagihan. Memahami alasan ini merupakan langkah awal untuk mengurangi kehilangan pendapatan yang sebenarnya dapat dihindari. Mengapa ini penting Menjelaskan alasan pendapatan disesuaikan atau dihapuskan, sehingga memberikan informasi penting tentang kebocoran pendapatan dan kinerja kontrak payer. Sumber data Terkait dengan transaksi penyesuaian pada modul pencatatan pembayaran atau piutang usaha Waystar. Contoh Kewajiban kontraktualPenghapusan saldo kecilKoreksi kesalahan penagihan | |||
| Pembayaran pada pengajuan pertama IsFirstPassPayment | Penanda yang menunjukkan apakah klaim dibayar dengan benar pada pengajuan pertama, tanpa penolakan atau penyesuaian. | ||
| Deskripsi Atribut boolean hasil perhitungan ini menunjukkan apakah klaim dibayar tanpa kejadian negatif, seperti penolakan, penolakan pengajuan, atau permintaan informasi tambahan. Nilai 'true' menandakan proses klaim tersebut berjalan lancar dan efisien. Atribut ini mendukung KPI 'Tingkat pembayaran pada pengajuan pertama', yang menjadi ukuran penting efisiensi siklus pendapatan secara keseluruhan. Dengan menganalisis karakteristik klaim yang tidak dibayar pada pengajuan pertama, misalnya berdasarkan pembayar atau jenis layanan, Anda dapat menemukan penyebab utama pengerjaan ulang dan keterlambatan pembayaran. Peningkatan tingkat ini mempercepat arus kas dan menekan biaya operasional. Mengapa ini penting Mengukur langsung kualitas penagihan dan pemrosesan klaim. Tingkat pembayaran pada pengajuan pertama yang tinggi menunjukkan proses yang efisien dengan sedikit pengerjaan ulang. Sumber data Atribut turunan ini dihitung saat transformasi data. Logikanya memeriksa apakah peristiwa 'Payment Posted' terjadi tanpa didahului peristiwa seperti 'Claim Denied' atau 'Account Adjusted'. Contoh truefalse | |||
| Pengguna yang bertanggung jawab ResponsibleUser | Pengguna atau petugas yang melakukan aktivitas, seperti petugas penagihan, pengode, atau spesialis penagihan piutang. | ||
| Deskripsi Atribut ini menunjukkan karyawan atau pengguna sistem yang melakukan aktivitas tertentu dalam proses. Contohnya, atribut ini dapat menunjukkan petugas penagihan yang mengirim klaim atau petugas penagihan piutang yang memulai panggilan tindak lanjut. Menganalisis proses berdasarkan pengguna membantu memahami pembagian beban kerja, kinerja individu, dan kebutuhan pelatihan. Analisis ini dapat menunjukkan apakah pengguna tertentu lebih sering melakukan kesalahan atau lebih cepat menyelesaikan penolakan. Informasi ini berguna untuk pengelolaan tim dan pengendalian kualitas di departemen siklus pendapatan. Mengapa ini penting Menetapkan penanggung jawab untuk setiap langkah proses, sehingga kinerja individu atau tim dapat dianalisis dan kebutuhan pelatihan dapat diketahui. Sumber data Tersedia dalam jejak audit atau log transaksi untuk peristiwa di Waystar, biasanya dengan nama seperti “UserID”, “ProcessedBy”, atau sejenisnya. Contoh jsmithadavisbilling_bot_01 | |||
| Tanggal jatuh tempo pembayaran PaymentDueDate | Tanggal batas pembayaran untuk faktur atau klaim. | ||
| Deskripsi Tanggal jatuh tempo pembayaran ditetapkan oleh penyedia layanan atau tercantum dalam kontrak dengan pembayar. Tanggal ini menunjukkan kapan pembayaran seharusnya diterima dan menjadi acuan untuk mengukur ketepatan waktu pembayaran. Atribut ini penting untuk dashboard 'Saldo tertunggak dan umur piutang'. Atribut ini digunakan untuk menghitung umur piutang dan mengelompokkannya, misalnya menjadi '0-30 hari', '31-60 hari', dan seterusnya. Analisis umur piutang merupakan praktik keuangan standar untuk mengelola piutang usaha dan menentukan prioritas penagihan akun yang telah jatuh tempo. Mengapa ini penting Menjadi dasar untuk menghitung umur piutang usaha, yang penting untuk mengelola penagihan dan memahami ketepatan waktu arus kas. Sumber data Dapat ditemukan pada catatan faktur atau klaim. Tanggal ini mungkin dihitung berdasarkan tanggal faktur dan ketentuan pembayaran. Contoh 2023-11-252023-12-152024-01-30 | |||
| Waktu dari layanan hingga faktur ServiceToInvoiceCycleTime | Waktu yang berlalu sejak layanan selesai hingga biaya dicatat dan klaim dibuat. | ||
| Deskripsi Metrik ini, yang juga dikenal sebagai 'jeda pencatatan biaya', mengukur efisiensi proses penagihan di tahap awal. Perhitungannya menggunakan selisih waktu antara peristiwa 'Service Provided/Completed' dan peristiwa 'Charges Captured' atau 'Claim Created'. Atribut ini mendukung langsung dashboard 'Waktu siklus layanan hingga faktur'. Keterlambatan pada tahap ini, yang dikenal sebagai jeda pencatatan biaya, menunda dimulainya siklus pembayaran dan memperlambat arus kas. Pemantauan metrik ini membantu memastikan semua layanan ditagihkan dengan cepat dan akurat, mencegah pendapatan hilang, serta mempercepat seluruh siklus pendapatan. Mengapa ini penting Mengukur efisiensi penagihan di tahap awal. Mengurangi jeda pencatatan biaya penting untuk mempercepat seluruh siklus pendapatan dan mencegah biaya tidak tercatat. Sumber data Dihitung saat transformasi data dengan mengurangi cap waktu peristiwa layanan dari cap waktu pencatatan biaya atau pembuatan klaim. Contoh 2 hari 8 jam1 hari 0 jam5 hari 1 jam | |||
Aktivitas pengelolaan siklus pendapatan
| Aktivitas | Deskripsi | ||
|---|---|---|---|
| Akun ditutup | Siklus penagihan telah selesai, dengan saldo akun mencapai nol melalui pembayaran dan penyesuaian. Ini menandai berakhirnya siklus pendapatan untuk kasus tersebut. | ||
| Mengapa ini penting Ini adalah titik akhir utama proses. Mengukur waktu hingga penutupan dan persentase akun yang berhasil ditutup merupakan indikator kinerja keseluruhan yang penting. Sumber data Peristiwa ini dihitung dan biasanya disimpulkan saat kolom saldo terutang untuk peristiwa penagihan menjadi nol di sistem akuntansi pasien. Pengumpulan data Dihitung saat jumlah pembayaran dan penyesuaian sama dengan total tagihan. Jenis peristiwa calculated | |||
| Biaya layanan tercatat | Menandai pencatatan layanan yang dapat ditagihkan ke dalam sistem siklus pendapatan. Peristiwa ini biasanya dicatat secara eksplisit saat pengguna menyelesaikan entri biaya atau saat data diterima dari sistem klinis. | ||
| Mengapa ini penting Ini adalah titik awal proses penagihan. Menganalisis waktu dari selesainya layanan hingga pencatatan biaya sangat penting untuk menemukan kebocoran pendapatan dan keterlambatan di tahap awal. Sumber data Peristiwa ini dicatat dalam tabel entri biaya atau transaksi di Waystar. Biasanya, catatan tersebut memuat stempel waktu pembuatan saat biaya disimpan atau diselesaikan. Pengumpulan data Peristiwa dicatat saat entri biaya disimpan atau diselesaikan. Jenis peristiwa explicit | |||
| Klaim dikirim ke penjamin | Pengiriman klaim penagihan secara elektronik kepada penjamin asuransi untuk diproses. Ini adalah serah terima penting dari sistem penyedia layanan ke sistem penjamin melalui clearinghouse. | ||
| Mengapa ini penting Tonggak penting yang memulai penghitungan waktu respons penjamin. Data ini diperlukan untuk mengukur KPI siklus pembayaran dan menemukan penumpukan pengajuan. Sumber data Fungsi clearinghouse Waystar mencatat tanggal dan waktu pengiriman berkas klaim secara eksplisit. Cari catatan pengiriman atau riwayat status klaim. Pengumpulan data Dicatat dalam riwayat pengajuan klaim atau log transaksi setelah pengiriman berhasil. Jenis peristiwa explicit | |||
| Klaim dinilai | Payer telah memproses klaim dan memutuskan pembayaran. Peristiwa ini tercatat saat Electronic Remittance Advice (ERA), atau file 835, diterima dari payer. | ||
| Mengapa ini penting Ini adalah titik keputusan utama dalam proses. Di sini ditentukan apakah klaim akan dibayar atau ditolak, yang berdampak langsung pada arus pendapatan dan alur kerja penanganan penolakan. Sumber data Disimpulkan dari tanggal penerimaan ERA (file 835) yang terkait dengan klaim di Waystar. File ERA memuat keputusan terperinci dari payer. Pengumpulan data Disimpulkan dari tanggal pemrosesan file ERA/835 yang diterima dari payer. Jenis peristiwa inferred | |||
| Klaim ditolak | Payer menolak klaim dan tidak akan membayar, sebagaimana dijelaskan dalam Electronic Remittance Advice (ERA). Peristiwa ini memulai penanganan penolakan atau proses pengerjaan ulang. | ||
| Mengapa ini penting Mendukung KPI “Tingkat Penolakan Klaim” secara langsung. Mengetahui seberapa sering klaim ditolak dan alasannya sangat penting untuk perbaikan proses dan pemulihan pendapatan. Sumber data Disimpulkan dari kode penolakan tertentu, yang disebut Claim Adjustment Reason Codes (CARCs), dalam ERA (file 835) yang diterima. Pengumpulan data Diperoleh dari kode alasan penyesuaian klaim (CARCs) dalam file ERA yang menunjukkan penolakan. Jenis peristiwa inferred | |||
| Pembayaran dibukukan | Pembayaran yang diterima diterapkan atau direkonsiliasi dengan akun pasien dan klaim terkait. Aktivitas ini memindahkan saldo dari piutang usaha menjadi kas. | ||
| Mengapa ini penting Ini adalah langkah akhir yang sangat penting dalam siklus payer. Langkah ini mendukung KPI volume pembukuan pembayaran dan jeda waktu, serta memastikan akun diperbarui secara akurat dan tepat waktu. Sumber data Di Waystar, tindakan ini dicatat secara langsung saat pengguna membukukan pembayaran dari ERA. Banyak sistem juga mencatat peristiwa ini saat fitur pembukuan otomatis digunakan. Pengumpulan data Peristiwa dicatat saat pembayaran dari ERA diterapkan ke klaim, baik secara manual maupun melalui pembukuan otomatis. Jenis peristiwa explicit | |||
| Aktivitas penagihan dimulai | Akun pasien telah menunggak dan upaya penagihan aktif dimulai. Upaya ini dapat berupa pengingat otomatis atau pengalihan akun ke agen penagihan pihak ketiga. | ||
| Mengapa ini penting Mendukung dasbor “Efektivitas Aktivitas Penagihan”. Dasbor ini membantu menganalisis biaya dan tingkat keberhasilan upaya penagihan atas piutang usaha yang telah lama tertunggak. Sumber data Biasanya disimpulkan dari perubahan status akun di Waystar menjadi “Penagihan” atau “Piutang tak tertagih”, yang memulai alur kerja berbeda. Pengumpulan data Disimpulkan dari perubahan status akun menjadi “Penagihan” atau “Piutang tak tertagih”. Jenis peristiwa inferred | |||
| Akun disesuaikan | Saldo akun disesuaikan secara manual atau berdasarkan kontrak. Penyesuaian dapat berupa penghapusan piutang, pengurangan sesuai kontrak, diskon pasien, atau koreksi lainnya. | ||
| Mengapa ini penting Penting untuk memahami kebocoran pendapatan. Menganalisis penyesuaian membantu menemukan masalah pada daftar tarif, pengelolaan kontrak, atau utang yang tidak tertagih. Sumber data Setiap penyesuaian keuangan harus dicatat sebagai transaksi untuk keperluan audit. Peristiwa ini akan tercatat secara langsung dalam tabel transaksi akun. Pengumpulan data Dicatat sebagai jenis transaksi tertentu dalam buku besar akun. Jenis peristiwa explicit | |||
| Klaim dibuat | Menandai pembuatan klaim penagihan resmi dari biaya yang telah dicatat. Ini adalah langkah internal saat sistem mengumpulkan informasi sebelum mengirimkannya kepada penjamin. | ||
| Mengapa ini penting Mengukur efisiensi internal dalam pembuatan klaim. Keterlambatan pada tahap ini dapat menunda seluruh siklus pembayaran, bahkan sebelum klaim keluar dari sistem penyedia layanan. Sumber data Peristiwa ini dapat dicatat secara eksplisit, tetapi sering kali disimpulkan dari stempel waktu pertama yang terkait dengan catatan klaim dalam modul manajemen klaim Waystar. Pengumpulan data Disimpulkan dari tanggal pembuatan catatan klaim dalam tabel klaim utama. Jenis peristiwa inferred | |||
| Klaim diperbaiki dan dikirim ulang | Setelah ditolak, klaim diperbaiki dan dikirim kembali ke payer. Ini menandai dimulainya kembali siklus adjudikasi untuk klaim tersebut. | ||
| Mengapa ini penting Ini adalah proses pengerjaan ulang yang penting. Menganalisis frekuensi dan alasan pengiriman ulang membantu menemukan penyebab utama kesalahan awal, seperti kesalahan pengodean atau data demografis. Sumber data Disimpulkan dengan menemukan peristiwa “Klaim dikirim ke payer” yang baru untuk klaim yang sebelumnya ditolak. Sistem mungkin juga memiliki status khusus untuk klaim yang dikirim ulang. Pengumpulan data Disimpulkan dari peristiwa pengiriman baru yang terkait dengan ID klaim yang sebelumnya ditolak. Jenis peristiwa inferred | |||
| Konfirmasi penerimaan dari penjamin diterima | Sistem penjamin mengonfirmasi penerimaan berkas klaim yang dikirim. Biasanya, konfirmasi ini berupa respons otomatis, seperti laporan 277CA atau 999, yang menunjukkan klaim telah diterima untuk diproses. | ||
| Mengapa ini penting Mengonfirmasi keberhasilan pengiriman dan membantu menemukan penolakan di tahap awal akibat format atau kesalahan data sebelum proses penilaian klaim dimulai. Dengan begitu, koreksi dapat dilakukan lebih cepat. Sumber data Dicatat dalam tabel status klaim atau berkas respons di modul clearinghouse Waystar setelah berkas konfirmasi dari penjamin diproses. Pengumpulan data Peristiwa dicatat setelah berkas konfirmasi elektronik dari penjamin diproses. Jenis peristiwa explicit | |||
| Penolakan diajukan banding | Pengguna mengambil tindakan untuk menyanggah penolakan klaim, biasanya dengan mengirim ulang klaim yang telah diperbaiki atau mengajukan banding resmi. Aktivitas ini merupakan langkah penting dalam proses pengerjaan ulang. | ||
| Mengapa ini penting Mengukur efisiensi tim penanganan penolakan. Melacak waktu dari penolakan hingga pengajuan banding serta tingkat keberhasilan banding penting untuk mengoptimalkan upaya pemulihan. Sumber data Tindakan ini mungkin dicatat sebagai aktivitas atau catatan pengguna secara langsung di modul penanganan penolakan. Tindakan ini juga dapat disimpulkan dari perubahan status klaim yang ditolak. Pengumpulan data Peristiwa dicatat saat pengguna mendokumentasikan pengajuan banding atau mengubah status klaim menjadi “Diajukan banding”. Jenis peristiwa explicit | |||
| Pernyataan saldo pasien dikirim | Setelah adjudikasi asuransi, pernyataan saldo dibuat dan dikirim kepada pasien untuk menagih sisa saldo. Fokus penagihan pun beralih dari payer ke pasien. | ||
| Mengapa ini penting Peristiwa ini memulai siklus pembayaran pasien. Menganalisis efektivitas dan waktu pengiriman pernyataan saldo penting untuk mengelola piutang pasien dan meningkatkan pengalaman pasien. Sumber data Modul penagihan pasien mencatat peristiwa ini secara langsung saat kumpulan pernyataan saldo dibuat atau dikirim secara elektronik maupun ke vendor percetakan. Pengumpulan data Peristiwa dicatat dalam riwayat korespondensi pasien saat pernyataan saldo dibuat. Jenis peristiwa explicit | |||
Panduan ekstraksi
Metode ekstraksi untuk proses ini sedang divalidasi. Silakan kembali lagi nanti atau hubungi kami untuk mendapatkan bantuan.
Siap memulai?
Lanjutkan langkah Anda untuk mengoptimalkan pengelolaan siklus pendapatan. Manfaatkan wawasan dari data ini untuk meningkatkan efisiensi dan memperbaiki arus kas mulai hari ini.
Optimalkan pengelolaan siklus pendapatan dan tingkatkan arus kas sekarang
Temukan inefisiensi, percepat waktu siklus hingga 30%, dan tingkatkan arus kas.
Tidak perlu kartu kredit. Mulai optimalkan proses Anda hari ini.