Templat data pengelolaan siklus pendapatan Anda
Templat data pengelolaan siklus pendapatan Anda
- Atribut yang disarankan untuk dikumpulkan
- Aktivitas utama untuk dilacak saat menemukan proses
- Panduan terperinci untuk mengekstrak data dari R1 RCM
Atribut pengelolaan siklus pendapatan
| Nama | Deskripsi | ||
|---|---|---|---|
| Nama Aktivitas ActivityName | Nama peristiwa bisnis atau tugas tertentu yang terjadi pada suatu waktu dalam proses siklus pendapatan. | ||
| Deskripsi Atribut ini menjelaskan satu langkah atau tahap penting dalam proses pengelolaan siklus pendapatan untuk suatu peristiwa penagihan. Aktivitas menunjukkan pekerjaan yang dilakukan, seperti 'Biaya Dicatat', 'Klaim Diajukan', atau 'Pembayaran Dibukukan'. Urutan aktivitas menjadi dasar process mining. Analisisnya membantu menemukan alur proses yang sebenarnya, mengidentifikasi hambatan saat aktivitas terlalu lama untuk dimulai, dan mendeteksi pengulangan pekerjaan yang tidak perlu, misalnya 'Klaim Ditolak' diikuti 'Penanganan Ulang Penolakan Dimulai'. Mengapa ini penting Atribut ini menentukan langkah-langkah proses sehingga Anda dapat melihat peta proses, menghitung waktu perpindahan, serta mengidentifikasi penyimpangan dan pekerjaan ulang. Sumber data Informasi ini biasanya berasal dari log peristiwa, catatan perubahan status, atau kode transaksi di berbagai modul R1 RCM. Kode teknis mungkin perlu dipetakan ke nama yang mudah dipahami oleh tim bisnis. Contoh Biaya DicatatKlaim DikirimKeputusan Pembayar DiterimaPembayaran DicatatAkun Ditutup | |||
| Peristiwa Penagihan BillingEvent | Pengenal unik untuk satu layanan atau item yang dapat ditagihkan. Pengenal ini menjadi ID kasus utama untuk melacak seluruh siklus pendapatan. | ||
| Deskripsi Billing Event ID mewakili satu layanan atau pengiriman produk yang menghasilkan tagihan. ID ini menghubungkan semua aktivitas terkait, mulai dari pemberian layanan dan pencatatan biaya hingga pengiriman klaim, pencatatan pembayaran, dan penutupan akun. Dalam process mining, analisis siklus hidup setiap Billing Event memberikan gambaran menyeluruh tentang siklus pendapatan. Anda dapat menelusuri perjalanan satu tagihan dari awal hingga akhir, menemukan jalur yang umum, mengukur waktu siklus di antara pencapaian penting, dan memahami variasi yang menyebabkan keterlambatan atau hilangnya pendapatan. Mengapa ini penting Pengenal ini penting untuk mengelompokkan semua aktivitas terkait dalam satu kasus. Dengan begitu, analisis proses siklus pendapatan untuk setiap peristiwa yang dapat ditagihkan menjadi lengkap dan akurat. Sumber data Ini adalah kunci utama yang menghubungkan berbagai tabel terkait kunjungan pasien, biaya, klaim, dan pembayaran. Lihat dokumentasi R1 RCM untuk mengetahui kolom yang tepat, biasanya terkait dengan ID kunjungan atau klaim. Contoh BE-2023-0012345BE-2023-0054321BE-2024-0098765 | |||
| Waktu Peristiwa EventTime | Stempel waktu yang menunjukkan kapan aktivitas atau peristiwa tertentu terjadi. | ||
| Deskripsi Waktu Peristiwa menunjukkan tanggal dan waktu yang tepat saat aktivitas dicatat di sistem. Informasi waktu ini menjadi dasar untuk memahami proses melalui analisis berbasis waktu. Dalam process mining, stempel waktu digunakan untuk mengurutkan peristiwa secara kronologis dan menghitung durasi antaraktivitas. Ini penting untuk menganalisis kinerja. Anda dapat menghitung metrik utama seperti waktu siklus, waktu pemrosesan, dan waktu tunggu untuk menemukan hambatan dan mengukur efisiensi. Mengapa ini penting Stempel waktu ini menjadi dasar semua analisis terkait waktu, termasuk penghitungan waktu siklus, identifikasi hambatan, dan pemantauan kinerja proses terhadap SLA. Sumber data Biasanya tersedia sebagai kolom 'Creation Date', 'Timestamp', atau 'Last Update Date' pada setiap transaksi atau catatan perubahan status di R1 RCM. Contoh 2023-10-26T10:00:00Z2023-10-27T14:35:10Z2023-11-05T09:12:45Z | |||
| Pembaruan Data Terakhir LastDataUpdate | Stempel waktu pembaruan atau ekstraksi data terbaru dari sistem sumber. | ||
| Deskripsi Atribut ini menunjukkan kapan terakhir kali data untuk analisis process mining diperbarui. Informasi ini memberi konteks tentang kebaruan data yang dianalisis. Informasi ini penting untuk pelaporan dan pembuatan dashboard karena memberi tahu pengguna seberapa mutakhir wawasan proses yang ditampilkan. Dengan begitu, pengguna dapat memahami ketepatan waktu data dan mengambil keputusan berdasarkan rentang waktu yang jelas. Mengapa ini penting Memberi konteks penting tentang kebaruan data agar analis dan pemangku kepentingan mengetahui seberapa mutakhir wawasan proses yang tersedia. Sumber data Stempel waktu ini dibuat selama proses ekstraksi, transformasi, dan pemuatan data (ETL), biasanya untuk seluruh kumpulan data. Contoh 2024-05-20T08:00:00Z2024-05-21T08:00:00Z | |||
| Sistem Sumber SourceSystem | Sistem pencatatan asal data peristiwa diekstrak. | ||
| Deskripsi Atribut ini menunjukkan aplikasi atau modul sumber yang menghasilkan data untuk suatu peristiwa. Dalam lingkungan yang kompleks seperti layanan kesehatan, data dapat berasal dari EMR, modul penagihan, clearinghouse klaim, atau platform penagihan. Mengetahui sistem sumber penting untuk memvalidasi data dan menganalisis variasi proses yang mungkin hanya terjadi pada sistem tertentu. Informasi ini membantu menelusuri ketidakkonsistenan data dan memahami sistem teknologi yang mendukung proses. Mengapa ini penting Menunjukkan asal data. Informasi ini penting untuk tata kelola dan validasi data, serta untuk memahami interaksi antarsistem dalam proses dari awal hingga akhir. Sumber data Nilai ini sering kali ditambahkan secara tetap saat ekstraksi data untuk menunjukkan sistem asal data, misalnya 'R1 RCM'. Contoh R1 RCMCernerEpic | |||
| Departemen Penagihan BillingDepartment | Departemen atau tim fungsional yang bertanggung jawab menjalankan aktivitas. | ||
| Deskripsi Atribut ini menunjukkan unit organisasi, seperti 'Pencatatan Biaya', 'Pengajuan Klaim', atau 'Penanganan Penolakan', yang menjalankan langkah proses tertentu. Atribut ini membantu memahami perpindahan pekerjaan antartim. Informasi ini penting untuk menganalisis keluaran tiap departemen dan menemukan hambatan lintas fungsi. Dengan memfilter peta proses berdasarkan departemen, organisasi dapat melihat perpindahan pekerjaan yang lancar dan bagian yang mengalami keterlambatan. Hasilnya dapat mendukung alokasi sumber daya dan perbaikan proses organisasi. Mengapa ini penting Mendukung analisis kinerja proses berdasarkan unit organisasi dan membantu menemukan hambatan khusus tim, keterbatasan sumber daya, atau praktik yang baik. Sumber data Informasi ini dapat diambil dari profil pengguna di R1 RCM atau disimpan sebagai 'Department Code' dalam data transaksi. Contoh Pencatatan BiayaManajemen KlaimPenolakan dan BandingPembukuan Pembayaran | |||
| Jumlah Faktur InvoiceAmount | Nilai total biaya pada faktur atau klaim. | ||
| Deskripsi Atribut ini menunjukkan total jumlah yang ditagihkan untuk layanan dalam suatu peristiwa penagihan. Nilai ini mencerminkan pendapatan yang diharapkan dari klaim. Analisis jumlah faktur penting untuk process mining keuangan. Analisis ini membantu memprioritaskan klaim bernilai tinggi, memahami dampak finansial keterlambatan proses atau penolakan, dan mengelompokkan proses berdasarkan nilai. Misalnya, analisis dapat menunjukkan bahwa klaim di atas jumlah tertentu mengikuti alur yang berbeda dan lebih banyak dikerjakan secara manual. Mengapa ini penting Memberi konteks keuangan untuk proses, sehingga Anda dapat menganalisis dampak variasi proses terhadap pendapatan dan memprioritaskan kasus bernilai tinggi untuk diperbaiki. Sumber data Tersedia di tabel utama klaim atau header faktur di R1 RCM, biasanya dengan nama 'TotalBilledAmount' atau yang serupa. Contoh 150.002500.7585.5012000.00 | |||
| Kode Alasan Penolakan DenialReasonCode | Kode standar dari penanggung yang menjelaskan alasan klaim ditolak. | ||
| Deskripsi Saat penanggung menolak klaim, mereka memberikan kode alasan, seperti CARC (Claim Adjustment Reason Code), untuk menjelaskan keputusan tersebut. Kode standar ini menunjukkan masalah seperti 'Layanan Tidak Ditanggung' atau 'Klaim Duplikat'. Atribut ini sangat penting untuk penanganan penolakan. Dengan menganalisis frekuensi setiap kode alasan, organisasi dapat menemukan dan mengatasi akar penyebab penolakan, baik terkait kelayakan pasien, kesalahan pengodean, maupun kebutuhan medis yang tidak terpenuhi. Analisis ini membantu mengurangi pekerjaan ulang dan mempercepat arus kas. Mengapa ini penting Menunjukkan alasan spesifik klaim ditolak. Informasi ini mendukung analisis akar penyebab untuk mengurangi penolakan berikutnya, menekan pekerjaan ulang, dan meningkatkan tingkat pembayaran pada pengajuan pertama. Sumber data Informasi ini diterima dari penanggung melalui electronic remittance advice (ERA atau file 835) dan disimpan dalam modul pengelolaan klaim R1 RCM. Contoh CO-16: Klaim/layanan tidak memiliki informasi yang diperlukan untuk adjudikasi.PR-97: Manfaat untuk layanan ini sudah termasuk dalam pembayaran/kelonggaran untuk layanan lain.CO-22: Perawatan ini mungkin ditanggung penanggung lain sesuai koordinasi manfaat.OA-18: Klaim/layanan yang sama persis telah diajukan sebelumnya. | |||
| Nama Penanggung PayerName | Nama perusahaan asuransi, lembaga pemerintah, atau pasien yang bertanggung jawab atas pembayaran. | ||
| Deskripsi Atribut ini menunjukkan penanggung utama untuk klaim. Penanggung dapat berupa perusahaan asuransi komersial seperti Aetna, lembaga pemerintah seperti Medicare, atau pasien sendiri untuk bagian yang dibayar mandiri. Analisis proses berdasarkan penanggung menjadi dasar pengelolaan siklus pendapatan. Analisis ini dapat menunjukkan penanggung dengan tingkat penolakan lebih tinggi, siklus pembayaran lebih lama, atau persyaratan pengajuan yang lebih rumit. Wawasan ini membantu organisasi menyesuaikan proses dan sumber daya untuk menangani pola tiap penanggung. Mengapa ini penting Memungkinkan proses dikelompokkan berdasarkan penanggung untuk menemukan keterlambatan, pola penolakan, atau perilaku pembayaran tertentu. Informasi ini penting untuk mengoptimalkan pendapatan. Sumber data Tersedia dalam informasi asuransi atau demografi pasien yang terhubung dengan klaim di R1 RCM. Contoh MedicareUnitedHealthcareBlue Cross Blue ShieldAetnaBayar Mandiri | |||
| Pengguna yang Ditugaskan AssignedUser | ID pengguna atau nama karyawan yang melakukan aktivitas. | ||
| Deskripsi Atribut ini menunjukkan orang yang bertanggung jawab menjalankan tugas tertentu dalam proses. Misalnya, petugas penagihan yang membuat klaim, analis yang menangani ulang penolakan, atau spesialis yang membukukan pembayaran. Analisis berdasarkan pengguna membantu memahami pembagian beban kerja, kinerja individu, dan kebutuhan pelatihan. Analisis ini dapat menunjukkan pengguna yang bekerja paling efisien atau yang terkait dengan tingkat kesalahan lebih tinggi, sehingga upaya pengelolaan dan perbaikan proses dapat lebih terarah. Mengapa ini penting Mendukung analisis kinerja tim dan individu serta pembagian beban kerja. Atribut ini juga membantu menemukan kebutuhan pelatihan atau penyimpangan proses yang terkait dengan pengguna tertentu. Sumber data Biasanya tersedia sebagai kolom 'UserID', 'Processor', atau 'UpdatedBy' dalam log transaksi R1 RCM. Contoh jdoeasmithp.jonesBOT_RPA01 | |||
| Status Faktur InvoiceStatus | Status terkini faktur atau klaim dalam siklusnya. | ||
| Deskripsi Atribut ini menunjukkan status terakhir yang diketahui dari suatu peristiwa penagihan, seperti 'Diajukan', 'Dibayar', 'Ditolak', atau 'Dalam Proses Penagihan'. Status ini memberi gambaran posisi faktur dalam proses pada waktu tertentu. Status faktur penting untuk membuat laporan umur piutang dan memantau kondisi piutang usaha. Dalam process mining, status ini dapat digunakan untuk menyaring kasus yang tertahan pada status tertentu atau menganalisis hasil berbagai variasi proses, misalnya membandingkan alur klaim 'Dibayar' dan 'Ditolak'. Mengapa ini penting Memberi gambaran status terkini setiap kasus. Informasi ini penting untuk membuat laporan umur piutang dan menganalisis hasil akhir dari berbagai alur proses. Sumber data Biasanya berupa kolom status pada catatan utama klaim atau akun di R1 RCM. Contoh Menunggu PengajuanDiajukan ke PenanggungDitolakLunasDalam Proses Penagihan | |||
| Alasan Penyesuaian AdjustmentReason | Alasan penyesuaian keuangan, seperti 'Keringanan Kontraktual' atau 'Penghapusan Piutang Tak Tertagih'. | ||
| Deskripsi Atribut ini menjelaskan alasan penyesuaian keuangan pada akun. Alasan biasanya berupa kode atau keterangan standar yang mengelompokkan jenis penyesuaian. Analisis alasan penyesuaian membantu menemukan akar penyebab hilangnya pendapatan. Misalnya, seringnya 'Penghapusan Saldo Kecil' dapat menunjukkan proses penagihan yang tidak efisien untuk jumlah kecil, sedangkan 'Keringanan Kontraktual' yang sering terjadi merupakan bagian wajar dari negosiasi dengan penanggung. Analisis ini mendukung dashboard Audit Penyesuaian Penagihan dan Kepatuhan. Mengapa ini penting Menjelaskan alasan di balik penyesuaian pendapatan dan membantu menemukan akar penyebab kehilangan pendapatan, seperti masalah kontrak, kesalahan penagihan, atau kegagalan penagihan. Sumber data Biasanya berupa kolom kode atau teks dalam catatan transaksi yang sama dengan AdjustmentAmount di R1 RCM. Contoh Keringanan KontraktualPenghapusan Piutang Tak TertagihPenghapusan Saldo KecilKoreksi Kesalahan Penagihan | |||
| Hasil Penagihan CollectionOutcome | Hasil akhir upaya penagihan saldo yang belum dibayar. | ||
| Deskripsi Atribut ini menjelaskan hasil upaya menagih pembayaran dari akun yang menunggak. Hasilnya dapat berupa 'Lunas', 'Diselesaikan dengan Jumlah Lebih Rendah', 'Dimasukkan sebagai Piutang Tak Tertagih', atau 'Belum Terselesaikan'. Melacak hasil penagihan penting untuk mengevaluasi efektivitas proses penagihan. Dengan menganalisis aktivitas yang menghasilkan tiap jenis hasil, organisasi dapat mengoptimalkan strategi penagihan, meningkatkan tingkat pemulihan, dan menentukan kapan upaya penagihan perlu dihentikan serta saldo dihapuskan. Informasi ini mendukung dashboard Kinerja Aktivitas Penagihan. Mengapa ini penting Mengukur efektivitas proses penagihan dengan melacak penyelesaian akhir akun yang menunggak. Informasi ini membantu mengoptimalkan strategi penagihan. Sumber data Kemungkinan berupa kolom status pada akun pasien atau dalam modul khusus penagihan di R1 RCM. Contoh LunasDiselesaikan dengan Jumlah Lebih RendahDikirim ke Agen EksternalDihapuskan sebagai Piutang Tak Tertagih | |||
| ID Pasien PatientId | Pengenal unik untuk pasien yang menerima layanan. | ||
| Deskripsi Atribut ini adalah ID unik yang diberikan kepada pasien dalam sistem layanan kesehatan, sering disebut Nomor Rekam Medis (MRN). Meski analisis tidak berfokus pada perawatan pasien secara individu, ID Pasien dapat digunakan untuk menemukan masalah penagihan berulang pada pasien yang sama dari waktu ke waktu. Jika dihubungkan dengan data pasien lainnya, ID ini juga dapat membantu mengelompokkan proses berdasarkan demografi atau riwayat pasien dan mengungkap masalah sistemik yang berdampak pada kelompok tertentu. Mengapa ini penting Memungkinkan analisis peristiwa penagihan pada tingkat pasien untuk menemukan masalah atau pola berulang pada pasien tertentu di berbagai kunjungan. Sumber data Pengenal ini merupakan bagian utama dari data demografi pasien yang terhubung dengan setiap kunjungan dan klaim di R1 RCM. Contoh MRN837262MRN937281MRN103847 | |||
| Jumlah Penyesuaian AdjustmentAmount | Nilai uang dari penyesuaian saldo akun. | ||
| Deskripsi Atribut ini mencatat nilai penyesuaian keuangan pada akun pasien setelah penagihan awal. Penyesuaian dapat menambah atau mengurangi saldo, termasuk keringanan kontraktual, penghapusan, atau koreksi. Melacak jumlah penyesuaian penting untuk memahami keakuratan pendapatan. Penyesuaian negatif dalam jumlah besar dapat menunjukkan hilangnya pendapatan akibat pencatatan biaya yang keliru atau piutang yang tidak tertagih. Analisis data ini membantu menemukan dampak finansial dari kesalahan penagihan dan ketidakefisienan penagihan. Mengapa ini penting Mengukur hilangnya pendapatan dan koreksi keuangan. Informasi ini membantu menunjukkan dampak finansial dari ketidakakuratan penagihan, kewajiban kontraktual, atau piutang tak tertagih. Sumber data Tersedia dalam log transaksi terkait penyesuaian akun atau pembukuan pembayaran di R1 RCM. Contoh -50.2520.00-1200.00 | |||
| Kode Layanan ServiceCode | Kode penagihan untuk layanan atau prosedur tertentu, seperti kode CPT atau HCPCS. | ||
| Deskripsi Kode layanan, seperti kode CPT (Current Procedural Terminology), adalah kode medis standar untuk melaporkan prosedur dan layanan medis, bedah, serta diagnostik kepada penanggung agar mendapat penggantian biaya. Analisis proses berdasarkan kode layanan penting untuk menemukan masalah penagihan pada jenis perawatan tertentu. Analisis ini dapat menunjukkan prosedur yang paling sering ditolak, memiliki siklus pembayaran terlama, atau paling sering perlu dikerjakan ulang. Hasilnya membantu mengarahkan perbaikan praktik pengodean dan penagihan. Mengapa ini penting Memungkinkan analisis proses berdasarkan jenis layanan yang diberikan. Ini penting untuk menemukan pola penolakan atau keterlambatan pembayaran yang terkait dengan prosedur tertentu. Sumber data Informasi ini tersedia pada tingkat item baris untuk setiap biaya atau klaim di R1 RCM. Contoh 992139928573560 | |||
| Otomatis IsAutomated | Penanda yang menunjukkan apakah aktivitas dilakukan oleh sistem otomatis atau pengguna. | ||
| Deskripsi Atribut boolean ini membedakan tugas yang dijalankan oleh otomatisasi perangkat lunak, seperti bot RPA untuk pengajuan klaim, dari tugas yang dilakukan karyawan secara manual. Analisis atribut ini penting untuk memahami dampak dan efektivitas inisiatif otomatisasi. Anda dapat membandingkan kecepatan, biaya, dan tingkat kesalahan proses otomatis dengan proses manual. Hasilnya membantu menemukan peluang otomatisasi baru dan mengukur ROI bot yang sudah digunakan. Mengapa ini penting Membedakan aktivitas yang dilakukan manusia dan sistem. Informasi ini penting untuk mengukur dampak otomatisasi terhadap efisiensi, biaya, dan kualitas proses. Sumber data Informasi ini dapat diambil dari kolom 'AssignedUser' jika ID pengguna tertentu dikhususkan untuk bot, misalnya 'BOT_RPA01'. Beberapa sistem juga memiliki kolom khusus untuk menandai transaksi otomatis. Contoh truefalse | |||
| Pekerjaan Ulang IsRework | Penanda hasil perhitungan yang menunjukkan aktivitas dalam rangkaian pekerjaan ulang, seperti pengajuan ulang klaim yang ditolak. | ||
| Deskripsi Atribut boolean ini biasanya dihitung selama analisis process mining. Nilainya menjadi 'true' jika aktivitas mengulangi langkah sebelumnya atau termasuk dalam rangkaian yang menunjukkan adanya koreksi kesalahan, misalnya aktivitas apa pun setelah 'Klaim Ditolak'. Menemukan pekerjaan ulang adalah salah satu kemampuan utama process mining. Analisis ini mengukur waktu, upaya, dan sumber daya yang terbuang dalam proses. Dengan menandai pekerjaan ulang, organisasi dapat memusatkan perbaikan pada pencegahan kesalahan yang menyebabkannya sehingga efisiensi meningkat. Mengapa ini penting Membantu mengukur frekuensi dan dampak pekerjaan ulang, seperti penolakan klaim, sehingga analisis dapat diarahkan untuk mengurangi inefisiensi dan upaya yang terbuang. Sumber data Kolom ini tidak tersedia di sistem sumber. Alat process mining menghitungnya berdasarkan urutan aktivitas, misalnya dengan mendeteksi aktivitas 'Klaim Diajukan' yang terjadi lebih dari sekali untuk kasus yang sama. Contoh truefalse | |||
| Waktu Siklus Layanan hingga Pembayaran ServiceToPaymentCycleTime | Total durasi yang dihitung sejak layanan diberikan hingga pembayaran akhir dibukukan. | ||
| Deskripsi Metrik ini mengukur durasi siklus pendapatan dari awal hingga akhir untuk satu peristiwa penagihan. Metrik ini menunjukkan waktu yang dibutuhkan organisasi untuk mengubah layanan yang diberikan menjadi uang tunai. Ini adalah Indikator Kinerja Utama (KPI) yang penting untuk kesehatan keuangan. Analisis durasi ini membantu menemukan bagian proses yang paling perlu dipercepat. Dengan menguraikan waktu siklus menjadi beberapa bagian, seperti 'waktu hingga penagihan' dan 'waktu hingga pembayaran', organisasi dapat menemukan peluang terbesar untuk memperbaiki arus kas. Mengapa ini penting KPI utama ini mengukur efisiensi keseluruhan siklus konversi kas dan berdampak langsung pada arus kas organisasi. Sumber data Ini adalah metrik hasil perhitungan. Nilainya merupakan selisih waktu antara stempel waktu aktivitas 'Service Rendered' dan 'Payment Posted' untuk Billing Event tertentu. Contoh 35 hari 8 jam92 hari 4 jam15 hari 12 jam | |||
Aktivitas pengelolaan siklus pendapatan
| Aktivitas | Deskripsi | ||
|---|---|---|---|
| Akun Ditutup | Peristiwa penagihan telah diselesaikan sepenuhnya, saldo menjadi nol, dan akun resmi ditutup. Ini menandakan siklus pendapatan untuk kunjungan tersebut telah selesai. | ||
| Mengapa ini penting Ini adalah peristiwa akhir untuk jalur proses normal. Mengukur waktu siklus penutupan akun membantu memastikan tugas administrasi selesai dengan efisien dan catatan dituntaskan. Sumber data Disimpulkan saat saldo akun menjadi nol dan status akhir 'Ditutup' atau 'Lunas' diterapkan. Stempel waktunya diambil dari transaksi keuangan terakhir yang membuat saldo menjadi nol. Pengumpulan data Disimpulkan saat saldo akun menjadi nol, status 'Ditutup' diterapkan, dan stempel waktu aktivitas akhir tercatat. Jenis peristiwa inferred | |||
| Biaya Dicatat | Aktivitas ini menandai pencatatan resmi semua layanan, prosedur, dan perlengkapan yang dapat ditagihkan untuk kunjungan pasien. Ini adalah langkah penting dalam entri data yang mengubah aktivitas klinis menjadi transaksi keuangan. | ||
| Mengapa ini penting Menandai peralihan dari operasional klinis ke operasional keuangan. Ini menjadi titik awal untuk mengukur waktu siklus pembuatan faktur dan klaim, serta membantu menemukan penumpukan entri biaya. Sumber data Dicatat di modul entri biaya R1 RCM atau diterima melalui antarmuka dari EHR. Peristiwa ini biasanya ditandai oleh log transaksi tertentu atau stempel waktu pembuatan catatan biaya. Pengumpulan data Diidentifikasi dari stempel waktu pembuatan catatan transaksi biaya di tabel penagihan. Jenis peristiwa explicit | |||
| Klaim Dikirim | Klaim yang sudah dibuat dikirim secara elektronik kepada pembayar yang bertanggung jawab, seperti perusahaan asuransi. Ini menandai komunikasi pertama dengan pihak luar untuk memperoleh penggantian biaya. | ||
| Mengapa ini penting Tonggak penting yang memulai penghitungan waktu penggantian biaya oleh pembayar. Pelacakan tahap ini membantu memantau penumpukan klaim dan memastikan klaim diajukan kepada pembayar tepat waktu. Sumber data Peristiwa ini dicatat sebagai transaksi saat klaim dikirim ke clearinghouse. Sistem mencatat stempel waktu pengiriman dan detail konfirmasi. Pengumpulan data Dicatat secara eksplisit sebagai transaksi dengan stempel waktu pengiriman saat klaim dikirim melalui clearinghouse. Jenis peristiwa explicit | |||
| Layanan Diberikan | Menandai saat layanan atau prosedur yang dapat ditagihkan selesai diberikan kepada pasien. Peristiwa ini biasanya dicatat di sistem klinis atau penjadwalan dan memicu dimulainya siklus pendapatan. | ||
| Mengapa ini penting Ini menjadi titik awal KPI waktu siklus layanan hingga pembayaran. Dengan menganalisis waktu sejak peristiwa ini, Anda dapat menemukan keterlambatan di tahap awal siklus pendapatan. Sumber data Biasanya bersumber dari Rekam Medis Elektronik (EHR) atau sistem manajemen praktik yang terintegrasi dengan R1 RCM. Peristiwa ini sering disimpulkan dari stempel waktu 'Tanggal Layanan' atau 'Prosedur Selesai' di rekam pasien. Pengumpulan data Disimpulkan dari stempel waktu 'Tanggal Layanan' yang terkait dengan kunjungan pasien. Jenis peristiwa inferred | |||
| Pembayaran Dicatat | Pembayaran yang diterima resmi dialokasikan ke akun pasien sehingga saldo terutang berkurang. Ini adalah langkah terakhir untuk mencocokkan pembayaran dengan layanan yang ditagihkan. | ||
| Mengapa ini penting Aktivitas ini menjadi titik akhir untuk menghitung waktu siklus layanan hingga pembayaran dan pencatatan pembayaran. Aktivitas ini memastikan pendapatan diakui dan akun diperbarui secara akurat. Sumber data Dicatat sebagai transaksi keuangan di modul akuntansi pasien R1 RCM. Setiap pencatatan mencakup tanggal, jumlah, dan sumber pembayaran. Pengumpulan data Dicatat sebagai transaksi tertentu dengan tanggal pencatatan saat pengguna atau proses otomatis mengalokasikan pembayaran. Jenis peristiwa explicit | |||
| Pembayaran Diterima | Pembayaran diterima dari pembayar atau pasien. Peristiwa ini menandai penerimaan dana, tetapi dana tersebut belum dialokasikan ke akun atau layanan tertentu. | ||
| Mengapa ini penting Menandai masuknya dana. Jarak waktu antara 'Pembayaran Diterima' dan 'Pembayaran Dicatat' menjadi metrik penting untuk memahami efisiensi administrasi keuangan dan keterlambatan rekonsiliasi kas. Sumber data Dicatat dari berkas pengiriman uang elektronik pembayar atau dari pemrosesan pembayaran pasien. Peristiwa ini mengacu pada tanggal setoran atau tanggal berkas diterima. Pengumpulan data Dicatat dari tanggal efektif pembayaran di berkas ERA atau tanggal transaksi pembayaran pasien. Jenis peristiwa explicit | |||
| Aktivitas Penagihan Dimulai | Akun pasien menunggak dan upaya penagihan proaktif dimulai. Upaya ini dapat berupa surat pengingat otomatis hingga penanganan oleh spesialis penagihan. | ||
| Mengapa ini penting Menandai dimulainya proses penagihan yang membutuhkan banyak biaya. Analisis efektivitas dan waktu siklus aktivitas ini membantu menyempurnakan strategi penagihan utang macet. Sumber data Peristiwa ini kemungkinan dicatat atau disimpulkan dari perubahan status saat akun dipindahkan ke antrean kerja penagihan atau diberi kode status penagihan di R1 RCM. Pengumpulan data Disimpulkan dari perubahan status akun menjadi 'Dalam Penagihan' atau 'Menunggak'. Jenis peristiwa inferred | |||
| Akun Ditetapkan sebagai Piutang Macet | Semua upaya penagihan telah dilakukan, tetapi saldo akun yang tersisa dinilai tidak dapat ditagih. Saldo dihapus sebagai piutang macet dan menjadi kerugian pendapatan akhir. | ||
| Mengapa ini penting Ini menandakan hasil proses yang merugikan dan hilangnya pendapatan secara langsung. Analisis kasus yang berakhir sebagai piutang macet dapat mengungkap pola gagal bayar dan peluang untuk meningkatkan penagihan. Sumber data Biasanya dicatat sebagai transaksi di R1 RCM saat saldo terutang dipindahkan ke kategori piutang macet tertentu. Pemindahan ini sering dipicu oleh pengguna atau aturan umur piutang otomatis. Pengumpulan data Dicatat sebagai transaksi keuangan tertentu untuk menghapus saldo, sering kali disertai pemindahan ke agen penagihan eksternal. Jenis peristiwa explicit | |||
| Keputusan Pembayar Diterima | Sistem menerima tanggapan pembayar atas klaim yang dikirim, biasanya dalam berkas Electronic Remittance Advice (ERA). Tanggapan ini merinci jumlah yang dibayar, ditolak, atau disesuaikan. | ||
| Mengapa ini penting Peristiwa ini menjadi titik percabangan penting dalam proses. Langkah berikutnya bisa berupa pencatatan pembayaran atau penanganan penolakan. Analisis tahap ini membantu memahami perilaku pembayar dan kecepatan pembayaran. Sumber data Dicatat saat berkas pengiriman uang elektronik dari pembayar, seperti berkas ANSI 835, diproses oleh R1 RCM. Peristiwa ini ditandai dengan stempel waktu pemrosesan berkas. Pengumpulan data Dicatat saat berkas Electronic Remittance Advice (ERA/835) diterima dan diproses. Jenis peristiwa explicit | |||
| Klaim Dibuat | Klaim penagihan resmi dibuat di sistem berdasarkan biaya yang sudah dicatat. Proses ini menggabungkan demografi pasien, informasi asuransi, dan kode layanan ke dalam format standar. | ||
| Mengapa ini penting Ini adalah tonggak internal penting sebelum klaim dikirim ke pihak luar. Keterlambatan pada tahap ini dapat menunjukkan masalah pengodean, validasi data, atau konfigurasi sistem yang memperlambat seluruh proses penagihan. Sumber data Ini adalah peristiwa internal di sistem R1 RCM. Peristiwa ini kemungkinan dicatat sebagai perubahan status pada akun penagihan atau melalui stempel waktu pembuatan data klaim. Pengumpulan data Disimpulkan dari perubahan status menjadi 'Klaim Dibuat' atau stempel waktu pembuatan catatan klaim. Jenis peristiwa inferred | |||
| Klaim Ditolak | Pembayar menolak membayar seluruh klaim atau beberapa item di dalamnya. Alasan penolakan dicatat dan proses pengerjaan ulang serta banding dimulai. | ||
| Mengapa ini penting Aktivitas ini menandakan hilangnya pendapatan dan ketidakefisienan proses. Analisis alasan penolakan penting untuk menemukan akar penyebab dan meningkatkan tingkat penerimaan klaim pada pengajuan pertama. Sumber data Ini bukan peristiwa tersendiri, melainkan status yang disimpulkan dari detail dalam berkas ERA yang telah diproses. Kode penolakan tertentu dalam data pengiriman uang mengubah status klaim. Pengumpulan data Disimpulkan dari kode penolakan dalam berkas ERA yang telah diproses, yang mengubah status klaim menjadi 'Ditolak'. Jenis peristiwa inferred | |||
| Pengerjaan Ulang Penolakan Dimulai | Pengguna atau alur kerja otomatis mulai menyelidiki dan menyelesaikan klaim yang ditolak. Proses ini dapat mencakup koreksi kode, pengiriman dokumen, atau pengajuan banding atas keputusan pembayar. | ||
| Mengapa ini penting Menandai dimulainya proses pengerjaan ulang yang mahal untuk klaim yang ditolak. Mengukur waktu pada tahap ini penting untuk memahami efisiensi tim penanganan penolakan. Sumber data Peristiwa ini sering disimpulkan dari perubahan status klaim yang ditolak menjadi 'Pengerjaan Ulang Berlangsung' atau 'Sedang Ditinjau' di antrean kerja atau modul penanganan penolakan R1 RCM. Pengumpulan data Disimpulkan dari perubahan status di antrean kerja penanganan penolakan atau dari tindakan pertama pengguna pada klaim yang ditolak. Jenis peristiwa inferred | |||
| Penyesuaian Akun Dibuat | Transaksi selain pembayaran dicatat untuk mengubah saldo akun. Transaksi ini dapat mencakup penyesuaian kontraktual berdasarkan perjanjian dengan pembayar, penghapusan saldo kecil, atau koreksi. | ||
| Mengapa ini penting Jumlah penyesuaian yang tinggi dapat menandakan masalah pada daftar tarif, pengelolaan kontrak, atau kesalahan penagihan. Pelacakan penyesuaian penting untuk menganalisis integritas pendapatan. Sumber data Dicatat sebagai jenis transaksi tertentu di modul akuntansi pasien R1 RCM. Setiap penyesuaian memiliki kode, jumlah, dan tanggal pencatatan. Pengumpulan data Dicatat sebagai transaksi penyesuaian tersendiri yang dapat dikenali melalui kode transaksi unik. Jenis peristiwa explicit | |||
| Pernyataan Tagihan Pasien Dibuat | Setelah keputusan asuransi ditetapkan, pernyataan tagihan dibuat untuk merinci sisa saldo yang harus dibayar pasien. Saldo ini dapat berupa biaya bersama, deductible, atau layanan yang tidak ditanggung. | ||
| Mengapa ini penting Aktivitas ini memulai tahap pembayaran pasien dalam siklus pendapatan. Waktu dan frekuensinya penting untuk mengelola penagihan kepada pasien dan arus kas. Sumber data Biasanya dicatat sebagai peristiwa saat proses batch dijalankan untuk membuat dan mencetak atau mengirim pernyataan tagihan pasien secara elektronik. R1 RCM akan mencatat tanggal pernyataan dibuat. Pengumpulan data Dicatat sebagai transaksi saat proses batch untuk membuat pernyataan tagihan pasien dijalankan. Jenis peristiwa explicit | |||
Panduan ekstraksi
Langkah
- Masuk ke platform R1 RCM menggunakan akun pengguna yang memiliki izin untuk mengakses modul business intelligence atau pelaporan.
- Buka bagian pelaporan di platform. Namanya mungkin "Business Intelligence", "Reporting Portal", atau "Analytics".
- Cari alat untuk membuat laporan atau kueri khusus. Alat ini memungkinkan Anda menentukan kolom data dan logika yang akan digunakan untuk ekstraksi.
- Karena R1 RCM tidak menyediakan log peristiwa terpadu siap pakai, Anda perlu menyusunnya dengan menggabungkan data dari berbagai sumber. Konfigurasi kueri yang disediakan menggunakan pendekatan UNION ALL untuk menggabungkan peristiwa dari berbagai objek bisnis menjadi satu log kronologis.
- Salin seluruh kueri dari bagian "Query" dalam dokumen ini, lalu tempelkan ke editor kueri atau antarmuka konfigurasi laporan khusus.
- Atur parameter laporan, terutama rentang tanggal. Isi placeholder
'{StartDate}'dan'{EndDate}'dalam kueri untuk menentukan periode ekstraksi, misalnya 6 bulan terakhir. - Tambahkan filter lain yang diperlukan, seperti fasilitas, departemen, atau kelompok pembayar tertentu, untuk membatasi cakupan data.
- Jalankan laporan. Kueri akan dijalankan pada basis data R1 RCM dan menghasilkan data sesuai parameter yang Anda tentukan.
- Setelah laporan selesai, cari opsi untuk mengekspor data. Pilih CSV (Comma Separated Values) sebagai format ekspor karena format ini kompatibel langsung dengan ProcessMind.
- Unduh file CSV yang dihasilkan, lalu periksa sekilas. Pastikan nama kolom sesuai dengan atribut yang diperlukan:
BillingEvent,ActivityName,EventTime,SourceSystem, danLastDataUpdate. - Sebelum mengunggah file ke ProcessMind, pastikan format tanggal dan waktu pada kolom
EventTimedanLastDataUpdatekonsisten.
Konfigurasi
- Prasyarat: Anda memerlukan akun pengguna dengan izin yang memadai untuk mengakses dan membuat laporan khusus dalam modul Business Intelligence R1 RCM.
- Jenis laporan: Gunakan kueri khusus atau pembuat laporan lanjutan yang mendukung pengambilan data kompleks dan pernyataan UNION ALL untuk menggabungkan beberapa kumpulan data.
- Rentang tanggal: Untuk menjaga kinerja dan mengendalikan volume data, batasi laporan ke periode tertentu. Untuk analisis awal, sebaiknya mulai dengan rentang 3 hingga 6 bulan. Terapkan filter tanggal pada kolom stempel waktu utama untuk setiap aktivitas.
- Filter utama: Selain rentang tanggal, pertimbangkan filter
Facility ID,Payer Type, atauBilling Departmentuntuk memusatkan analisis pada area operasional tertentu dan mengurangi ukuran ekspor. - Format ekspor: Selalu pilih CSV sebagai format keluaran. Dengan begitu, file tersusun rapi dan mudah dibaca oleh alat process mining.
- Penjadwalan: Jika modul pelaporan R1 RCM mendukungnya, jadwalkan laporan agar berjalan berkala, misalnya mingguan atau bulanan, untuk memperbarui data secara otomatis dan memantau proses secara berkelanjutan.
Contoh kueri sql
SELECT
c.ClaimID AS BillingEvent,
'Service Rendered' AS ActivityName,
c.ServiceDate AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
c.ClinicianID AS AssignedUser,
d.DepartmentName AS BillingDepartment,
c.TotalChargeAmount AS InvoiceAmount,
p.PayerName AS PayerName,
'Rendered' AS InvoiceStatus,
NULL AS DenialReasonCode
FROM [ServiceAndChargeData] c
JOIN [Departments] d ON c.DepartmentID = d.DepartmentID
JOIN [Payers] p ON c.PayerID = p.PayerID
WHERE c.ServiceDate BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
c.ClaimID AS BillingEvent,
'Charges Captured' AS ActivityName,
c.ChargeEntryTimestamp AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
c.ChargeEntryUserID AS AssignedUser,
d.DepartmentName AS BillingDepartment,
c.TotalChargeAmount AS InvoiceAmount,
p.PayerName AS PayerName,
'Open' AS InvoiceStatus,
NULL AS DenialReasonCode
FROM [ServiceAndChargeData] c
JOIN [Departments] d ON c.DepartmentID = d.DepartmentID
JOIN [Payers] p ON c.PayerID = p.PayerID
WHERE c.ChargeEntryTimestamp BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
cl.ClaimID AS BillingEvent,
'Claim Created' AS ActivityName,
cl.CreationTimestamp AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
cl.CreatedByUserID AS AssignedUser,
cl.BillingDepartment AS BillingDepartment,
cl.TotalAmount AS InvoiceAmount,
cl.PayerName AS PayerName,
'Created' AS InvoiceStatus,
NULL AS DenialReasonCode
FROM [ClaimsData] cl
WHERE cl.CreationTimestamp BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
cl.ClaimID AS BillingEvent,
'Claim Submitted' AS ActivityName,
cl.SubmissionTimestamp AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
cl.SubmittedByUserID AS AssignedUser,
cl.BillingDepartment AS BillingDepartment,
cl.TotalAmount AS InvoiceAmount,
cl.PayerName AS PayerName,
'Submitted' AS InvoiceStatus,
NULL AS DenialReasonCode
FROM [ClaimsData] cl
WHERE cl.SubmissionTimestamp BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
era.ClaimID AS BillingEvent,
'Payer Adjudication Received' AS ActivityName,
era.ReceivedTimestamp AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
'System' AS AssignedUser,
pa.BillingDepartment AS BillingDepartment,
pa.InvoiceAmount AS InvoiceAmount,
era.PayerName AS PayerName,
'Adjudicated' AS InvoiceStatus,
NULL AS DenialReasonCode
FROM [RemittanceAdvice] era
JOIN [PatientAccounts] pa ON era.ClaimID = pa.BillingEvent
WHERE era.ReceivedTimestamp BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
d.ClaimID AS BillingEvent,
'Claim Denied' AS ActivityName,
d.DenialTimestamp AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
'System' AS AssignedUser,
cl.BillingDepartment AS BillingDepartment,
cl.TotalAmount AS InvoiceAmount,
cl.PayerName AS PayerName,
'Denied' AS InvoiceStatus,
d.ReasonCode AS DenialReasonCode
FROM [DenialsLog] d
JOIN [ClaimsData] cl ON d.ClaimID = cl.ClaimID
WHERE d.DenialTimestamp BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
dr.ClaimID AS BillingEvent,
'Denial Rework Started' AS ActivityName,
dr.ReworkStartTimestamp AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
dr.AssignedUserID AS AssignedUser,
cl.BillingDepartment AS BillingDepartment,
cl.TotalAmount AS InvoiceAmount,
cl.PayerName AS PayerName,
'In Rework' AS InvoiceStatus,
dr.OriginalDenialCode AS DenialReasonCode
FROM [DenialRework] dr
JOIN [ClaimsData] cl ON dr.ClaimID = cl.ClaimID
WHERE dr.ReworkStartTimestamp BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
ps.PatientAccountID AS BillingEvent,
'Patient Statement Generated' AS ActivityName,
ps.GenerationTimestamp AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
ps.GeneratedByUserID AS AssignedUser,
pa.BillingDepartment AS BillingDepartment,
ps.StatementBalance AS InvoiceAmount,
'Patient' AS PayerName,
'Patient Billed' AS InvoiceStatus,
NULL AS DenialReasonCode
FROM [PatientStatements] ps
JOIN [PatientAccounts] pa ON ps.PatientAccountID = pa.BillingEvent
WHERE ps.GenerationTimestamp BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
p.AssociatedClaimID AS BillingEvent,
'Payment Received' AS ActivityName,
p.ReceiptTimestamp AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
p.ProcessedByUserID AS AssignedUser,
pa.BillingDepartment AS BillingDepartment,
p.PaymentAmount AS InvoiceAmount,
p.PayerName AS PayerName,
'Payment Pending' AS InvoiceStatus,
NULL AS DenialReasonCode
FROM [PaymentsLog] p
JOIN [PatientAccounts] pa ON p.AssociatedClaimID = pa.BillingEvent
WHERE p.ReceiptTimestamp BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
pt.ClaimID AS BillingEvent,
'Payment Posted' AS ActivityName,
pt.PostingTimestamp AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
pt.PostedByUserID AS AssignedUser,
pa.BillingDepartment AS BillingDepartment,
pt.PostedAmount AS InvoiceAmount,
pt.PayerName AS PayerName,
'Partially Paid' AS InvoiceStatus,
NULL AS DenialReasonCode
FROM [PaymentTransactions] pt
JOIN [PatientAccounts] pa ON pt.ClaimID = pa.BillingEvent
WHERE pt.PostingTimestamp BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
a.ClaimID AS BillingEvent,
'Account Adjustment Made' AS ActivityName,
a.AdjustmentTimestamp AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
a.AdjusterID AS AssignedUser,
pa.BillingDepartment AS BillingDepartment,
a.AdjustmentAmount AS InvoiceAmount,
pa.PayerName AS PayerName,
'Adjusted' AS InvoiceStatus,
NULL AS DenialReasonCode
FROM [Adjustments] a
JOIN [PatientAccounts] pa ON a.ClaimID = pa.BillingEvent
WHERE a.AdjustmentTimestamp BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
ca.PatientAccountID AS BillingEvent,
'Collection Activity Started' AS ActivityName,
ca.ActivityTimestamp AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
ca.AssignedAgentID AS AssignedUser,
'Collections' AS BillingDepartment,
pa.CurrentBalance AS InvoiceAmount,
'Patient' AS PayerName,
'In Collections' AS InvoiceStatus,
NULL AS DenialReasonCode
FROM [CollectionsActivity] ca
JOIN [PatientAccounts] pa ON ca.PatientAccountID = pa.BillingEvent
WHERE ca.ActivityTimestamp BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
pa.BillingEvent AS BillingEvent,
'Account Placed in Bad Debt' AS ActivityName,
pa.BadDebtPlacementDate AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
pa.BadDebtUserID AS AssignedUser,
'Finance' AS BillingDepartment,
pa.CurrentBalance AS InvoiceAmount,
'Patient' AS PayerName,
'Bad Debt' AS InvoiceStatus,
NULL AS DenialReasonCode
FROM [PatientAccounts] pa
WHERE pa.BadDebtPlacementDate BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
pa.BillingEvent AS BillingEvent,
'Account Closed' AS ActivityName,
pa.ClosureDate AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
'System' AS AssignedUser,
pa.BillingDepartment AS BillingDepartment,
0 AS InvoiceAmount,
pa.PayerName AS PayerName,
'Closed' AS InvoiceStatus,
NULL AS DenialReasonCode
FROM [PatientAccounts] pa
WHERE pa.ClosureDate BETWEEN '{StartDate}' AND '{EndDate}' AND pa.CurrentBalance = 0; Siap memulai?
Gunakan templat ini untuk mempermudah pengumpulan data dan mulai mengoptimalkan pengelolaan siklus pendapatan Anda. Kami siap membantu Anda di setiap tahap.
Optimalkan R1 RCM Anda sekarang: tingkatkan efisiensi siklus pendapatan
Atasi hambatan RCM, kurangi waktu siklus hingga 30%, dan tingkatkan arus kas.
Tidak perlu kartu kredit. Mulai dalam hitungan menit.