Templat data pengelolaan siklus pendapatan
Templat data pengelolaan siklus pendapatan
Ini template data umum kami untuk process mining Manajemen Siklus Pendapatan. Gunakan template khusus sistem untuk mendapatkan panduan yang lebih terarah.
Pilih sistem tertentu- Dapat digunakan untuk process mining di sistem RCM apa pun.
- Atribut dan aktivitas inti untuk membuat log peristiwa yang efektif.
- Sumber daya dasar untuk analisis dan optimalisasi proses yang andal.
Atribut pengelolaan siklus pendapatan
| Nama | Deskripsi | ||
|---|---|---|---|
| ID billing event BillingEventId | Pengenal unik untuk satu layanan atau produk yang diberikan dan menghasilkan biaya. Pengenal ini menjadi ID kasus utama dalam proses siklus pendapatan. | ||
| Deskripsi Billing Event ID adalah kunci unik untuk setiap layanan yang dapat ditagihkan, mulai dari pencatatan biaya awal hingga pembayaran atau penghapusbukuan akhir. ID ini menghubungkan semua aktivitas terkait untuk satu layanan, seperti pembuatan dan pengiriman klaim, penolakan klaim, serta pencatatan pembayaran. Dalam process mining, atribut ini penting untuk merekonstruksi perjalanan setiap Billing Event dari awal hingga akhir. Dengan mengelompokkan semua aktivitas terkait berdasarkan satu Billing Event ID, analis dapat melihat alur proses, menemukan hambatan, mengukur waktu siklus, dan memahami perbedaan penanganan setiap kasus. Atribut ini menjadi dasar analisis yang berpusat pada kasus di seluruh siklus pendapatan. Mengapa ini penting ID ini adalah pengenal kasus utama yang menghubungkan semua aktivitas terkait. Dengan begitu, seluruh siklus pendapatan untuk setiap layanan yang dapat ditagihkan dapat direkonstruksi dan dianalisis. Sumber data Biasanya berupa kunci utama dalam tabel transaksi penagihan atau peristiwa keuangan. Contoh BE-2024-001234INV-987654ACCN-456789012 | |||
| Nama aktivitas ActivityName | Nama langkah, tugas, atau peristiwa tertentu yang terjadi dalam proses siklus pendapatan untuk billing event tertentu. | ||
| Deskripsi Nama Aktivitas menjelaskan tindakan atau tonggak tertentu dalam siklus pendapatan. Contohnya, 'Layanan diberikan', 'Klaim diajukan', 'Pemberitahuan pembayaran diterima', 'Pembayaran dibukukan', dan 'Akun dihapuskan'. Setiap aktivitas adalah langkah dalam proses yang menggunakan waktu dan sumber daya. Atribut ini menjadi dasar process mining karena menentukan simpul dalam peta proses. Analisis urutan, frekuensi, dan durasi aktivitas memungkinkan Anda memvisualisasikan alur proses yang sebenarnya, membandingkannya dengan model yang dirancang, serta menemukan penyimpangan, siklus pengerjaan ulang seperti penolakan klaim, dan inefisiensi. Mengapa ini penting Atribut ini menentukan langkah-langkah proses. Informasi ini penting untuk menemukan dan memvisualisasikan peta proses, mengidentifikasi pengerjaan ulang, dan menganalisis kesesuaian proses. Sumber data Biasanya ditemukan dalam log peristiwa atau tabel transaksi, atau diperoleh dari catatan perubahan status dalam modul penagihan atau klaim. Contoh Klaim diajukanPembayaran dibukukanPengerjaan ulang klaim yang ditolak dimulaiTagihan pasien dikirim | |||
| Stempel waktu peristiwa EventTimestamp | Tanggal dan waktu tepat saat aktivitas tertentu dicatat dalam sistem. | ||
| Deskripsi Stempel Waktu Peristiwa menunjukkan waktu terjadinya atau dicatatnya suatu aktivitas. Informasi ini memberikan konteks kronologis untuk semua peristiwa dalam satu kasus dan membentuk linimasa siklus pendapatan dari awal hingga akhir. Stempel waktu menjadi dasar analisis kinerja dalam process mining. Data ini digunakan untuk menghitung KPI penting, seperti total waktu siklus, durasi antara aktivitas tertentu, dan waktu tunggu. Dengan menganalisis stempel waktu, organisasi dapat menemukan hambatan yang paling banyak menyita waktu, mengukur kepatuhan terhadap perjanjian tingkat layanan, dan memahami dinamika waktu dalam proses. Mengapa ini penting Data ini menyediakan urutan waktu yang diperlukan untuk menghitung durasi siklus, menemukan hambatan, serta menganalisis kinerja dan efisiensi proses. Sumber data Informasi ini biasanya tersedia dalam log transaksi, jejak audit, atau kolom seperti 'tanggal pembuatan' maupun 'tanggal perubahan status' di tabel peristiwa. Contoh 2023-10-26T10:00:00Z2023-11-15T14:35:10Z2024-01-05T09:12:45Z | |||
| Pembaruan data terakhir LastDataUpdate | Waktu terakhir data untuk catatan peristiwa ini diperbarui atau diambil dari sistem sumber. | ||
| Deskripsi Atribut ini mencatat waktu terakhir data diambil dari sistem sumber. Sebagai kolom metadata, atribut ini penting untuk mengetahui seberapa baru dan tepat waktu data yang dianalisis. Atribut ini menunjukkan latensi alur data dan seberapa mutakhir analisis process mining. Di dashboard dan analisis process mining, waktu Pembaruan data terakhir memberi konteks tentang kemutakhiran data. Untuk pemantauan operasional, penting untuk mengetahui apakah tampilan menunjukkan kondisi proses lima menit lalu atau tadi malam. Dengan begitu, pengguna dapat memahami batas kemutakhiran data dan mengambil keputusan berdasarkan rentang waktu yang jelas. Mengapa ini penting Informasi ini memberi konteks penting tentang ketepatan waktu dan kemutakhiran data, sehingga analisis dan keputusan didasarkan pada rentang waktu yang diketahui. Sumber data Informasi ini biasanya ditambahkan saat proses ekstraksi, transformasi, dan pemuatan data (ETL), lalu disimpan sebagai kolom metadata di log peristiwa. Contoh 2024-03-15T02:00:00Z2024-03-15T03:00:00Z2024-03-15T04:00:00Z | |||
| Sistem sumber SourceSystem | Sistem informasi, aplikasi, atau modul tempat data peristiwa diambil. | ||
| Deskripsi Atribut Sistem sumber menunjukkan asal data untuk suatu peristiwa. Dalam lingkungan TI yang kompleks, proses siklus pendapatan sering melibatkan beberapa sistem. Contohnya, sistem Electronic Health Record (EHR) untuk memberikan layanan, sistem penagihan khusus untuk mengirim klaim, dan platform penagihan terpisah. Mengetahui sistem sumber berguna untuk memvalidasi data, menelusuri masalah, dan memahami fragmentasi proses. Informasi ini dapat membantu menemukan ketidaksesuaian antar sistem atau langkah proses yang dikelola di aplikasi berbeda. Perbedaan ini dapat menyebabkan keterlambatan atau kesalahan transfer data. Analisis ini membantu menilai integrasi dan efisiensi keseluruhan arsitektur TI yang mendukung proses. Mengapa ini penting Informasi ini membantu memahami fragmentasi proses di berbagai sistem TI. Informasi ini juga penting untuk memvalidasi data dan menemukan hambatan yang spesifik pada sistem tertentu. Sumber data Informasi ini sering tersedia sebagai kolom standar dalam ekstrak data, atau dapat ditentukan dari tabel maupun file sumber tempat data diambil. Contoh Epic ResoluteOracle HealthR1 RCM PlatformWaystar | |||
| Departemen yang bertanggung jawab ResponsibleDepartment | Departemen, tim, atau area fungsi yang bertanggung jawab menjalankan aktivitas. | ||
| Deskripsi Atribut ini menunjukkan unit organisasi yang terkait dengan langkah proses tertentu, seperti 'Akses Pasien', 'Pengodean', 'Penagihan', atau 'Penagihan Piutang'. Atribut ini membantu memahami pembagian dan serah terima pekerjaan antar tim. Analisis proses berdasarkan departemen penting untuk memahami kolaborasi lintas fungsi dan menemukan hambatan saat pekerjaan berpindah antar tim. Manajer dapat melihat departemen yang terlibat dalam variasi proses tertentu, mengukur efisiensi tiap departemen, dan mengalokasikan sumber daya dengan lebih tepat. Analisis ini juga dapat mengungkap masalah sistemik di suatu departemen yang berdampak pada seluruh siklus pendapatan. Mengapa ini penting Atribut ini membantu menemukan hambatan antar departemen dan menganalisis kinerja tiap area fungsi, sehingga peluang untuk meningkatkan kolaborasi antar tim dapat terlihat. Sumber data Informasi ini dapat tercantum dalam data transaksi atau ditentukan dari data induk yang terkait dengan pengguna yang bertanggung jawab. Contoh Departemen penagihanLayanan pengodeanPengelolaan penolakan klaimPenagihan piutang | |||
| Jumlah penyesuaian AdjustmentAmount | Nilai uang dari penyesuaian, penghapusan piutang, atau pengurangan sesuai kontrak pada saldo akun. | ||
| Deskripsi Jumlah penyesuaian menunjukkan bagian dari jumlah yang ditagihkan yang tidak diharapkan untuk diterima dari penanggung atau pasien. Penyebabnya dapat berupa perjanjian kontrak, diskon, atau penghapusan piutang. Penyesuaian ini mengurangi total piutang dan merupakan bagian normal dari siklus pendapatan. Analisis jumlah penyesuaian beserta alasannya penting untuk memahami integritas pendapatan. Penyesuaian yang tinggi atau tidak terduga dapat menandakan masalah dalam pencatatan biaya, pengodean, atau pengelolaan kontrak. Process mining dapat membantu menemukan variasi proses atau aktivitas tertentu yang menyebabkan tingkat penyesuaian lebih tinggi. Dengan begitu, Anda dapat menelusuri akar masalah dan memaksimalkan pendapatan yang diterima. Mengapa ini penting Atribut ini membantu menganalisis kebocoran pendapatan dengan melacak penghapusan piutang dan pengurangan sesuai kontrak, serta menyoroti potensi masalah dalam proses kontrak atau penagihan. Sumber data Nilai ini biasanya dicatat dalam tabel penyesuaian keuangan atau modul pencatatan pembayaran. Contoh 29.50500.75100.001500.00 | |||
| Jumlah yang ditagihkan BilledAmount | Nilai bruto layanan atau produk yang ditagihkan, sebelum penyesuaian atau pembayaran apa pun. | ||
| Deskripsi Jumlah yang ditagihkan adalah total biaya layanan yang diberikan, sebagaimana tercantum dalam klaim atau faktur. Nilai ini menjadi dasar keuangan untuk peristiwa penagihan dan acuan untuk mengukur transaksi keuangan berikutnya, seperti pembayaran dan penyesuaian. Dalam process mining, analisis Jumlah yang ditagihkan menjadi dasar untuk memahami dampak keuangan dari inefisiensi proses. Nilai ini dapat digunakan untuk mengelompokkan kasus bernilai tinggi dan rendah, serta melihat apakah masalah proses tertentu lebih banyak berdampak pada klaim bernilai tinggi. Menghubungkan jumlah ini dengan metrik seperti durasi siklus atau tingkat penolakan klaim membantu memprioritaskan perbaikan yang berdampak finansial paling besar. Mengapa ini penting Atribut ini menetapkan nilai keuangan awal suatu kasus, sehingga dampak finansial dari inefisiensi proses seperti keterlambatan dan penolakan klaim dapat dianalisis. Sumber data Atribut keuangan utama ini terdapat dalam tabel transaksi pencatatan biaya, penagihan, atau klaim. Contoh 150.002500.75500.0010000.00 | |||
| Kategori layanan ServiceCategory | Kategori, jenis, atau klasifikasi layanan yang diberikan, seperti rawat inap, rawat jalan, atau radiologi. | ||
| Deskripsi Kategori layanan mengelompokkan jenis perawatan atau layanan yang diberikan kepada pasien. Klasifikasinya dapat bersifat umum, seperti 'Rawat inap' dan 'Rawat jalan', atau lebih spesifik berdasarkan departemen, seperti 'Bedah', 'Gawat darurat', atau 'Laboratorium'. Setiap kategori layanan dapat memiliki aturan penagihan, persyaratan penanggung, dan alur proses yang berbeda. Mengelompokkan proses siklus pendapatan berdasarkan Kategori layanan penting untuk menghasilkan analisis yang bermakna. Organisasi dapat membandingkan kinerja berbagai lini layanan, misalnya untuk mengetahui apakah tingkat penolakan klaim prosedur bedah lebih tinggi daripada konsultasi. Perincian ini membantu mengisolasi masalah dan menyesuaikan inisiatif perbaikan dengan kondisi operasional tiap area layanan. Mengapa ini penting Atribut ini memungkinkan perbandingan kinerja berbagai lini layanan dan menunjukkan perbedaan efisiensi, tingkat penolakan klaim, serta siklus pembayaran untuk jenis perawatan tertentu. Sumber data Informasi ini biasanya tersedia dalam catatan perincian biaya atau dapat ditentukan dari kelas pasien, departemen, atau kode prosedur. Contoh Rawat inapRawat jalanGawat daruratRadiologiProsedur bedah | |||
| Kode alasan penolakan klaim DenialReasonCode | Kode standar beserta keterangan yang menunjukkan alasan penanggung menolak klaim. | ||
| Deskripsi Saat penanggung menolak klaim yang diajukan, mereka memberikan Kode alasan penolakan klaim untuk menjelaskan penyebabnya. Kode ini sering mengikuti standar industri, seperti Claim Adjustment Reason Codes (CARCs), dan menunjukkan masalah tertentu, misalnya 'Layanan tidak ditanggung', 'Klaim duplikat', atau 'Informasi tambahan diperlukan'. Atribut ini sangat berguna untuk menelusuri akar masalah dalam siklus pendapatan. Dengan menganalisis frekuensi dan dampak keuangan dari berbagai alasan penolakan, organisasi dapat menemukan kegagalan proses di tahap sebelumnya yang menyebabkan klaim ditolak. Misalnya, banyak penolakan karena 'Informasi pasien tidak benar' menunjukkan masalah dalam proses pendaftaran pasien. Temuan ini mendukung perbaikan berbasis data untuk mencegah penolakan berikutnya dan meningkatkan tingkat pembayaran pada pengajuan pertama. Mengapa ini penting Atribut ini penting untuk menelusuri akar masalah penolakan klaim. Dengan begitu, perbaikan dapat diarahkan ke proses awal dan pertengahan siklus untuk mencegah hilangnya pendapatan di kemudian hari. Sumber data Informasi ini berasal dari berkas electronic remittance advice (ERA) atau explanation of benefits (EOB) yang diterima dari penanggung. Contoh CO-16: Klaim/layanan tidak dilengkapi informasiPR-97: Manfaat untuk layanan ini sudah termasuk dalam pembayaran layanan lainOA-18: Klaim/layanan duplikatCO-22: Perawatan ini mungkin ditanggung penanggung lain sesuai koordinasi manfaat | |||
| Nama penanggung PayerName | Nama perusahaan asuransi, lembaga pemerintah, atau pihak ketiga lain yang bertanggung jawab atas pembayaran. | ||
| Deskripsi Nama penanggung menunjukkan pihak utama yang menerima klaim untuk penggantian biaya. Penanggung dapat berupa perusahaan asuransi komersial seperti Aetna atau UnitedHealthcare, program pemerintah seperti Medicare atau Medicaid, maupun pihak lain. Setiap penanggung memiliki aturan, persyaratan pengajuan, dan pola pembayaran yang berbeda. Atribut ini penting untuk menganalisis kinerja siklus pendapatan. Dengan mengelompokkan proses berdasarkan penanggung, organisasi dapat mengetahui penanggung dengan tingkat penolakan klaim tertinggi, siklus pembayaran terlama, atau permintaan informasi tambahan terbanyak. Hasil analisis ini mendukung tindakan yang lebih terarah, seperti menegosiasikan ulang kontrak, menyesuaikan proses pengajuan untuk penanggung tertentu, dan memusatkan upaya pengelolaan penolakan klaim pada area yang paling membutuhkan. Mengapa ini penting Atribut ini memungkinkan metrik kinerja, seperti tingkat penolakan klaim dan waktu pembayaran, dikelompokkan berdasarkan penanggung. Informasi ini penting untuk menentukan perbaikan dan negosiasi kontrak yang tepat sasaran. Sumber data Informasi ini biasanya terdapat dalam data pendaftaran pasien, asuransi, atau klaim yang terkait dengan peristiwa penagihan. Contoh AetnaCignaMedicareUnitedHealthcare | |||
| Pengguna yang bertanggung jawab ResponsibleUser | Identitas pengguna, karyawan, atau agen otomatis yang melakukan aktivitas. | ||
| Deskripsi Atribut Pengguna yang bertanggung jawab menghubungkan langkah proses dengan orang atau sistem yang menjalankannya. Contohnya, petugas pengodean yang menyelesaikan pengodean medis, spesialis penagihan yang mengirim klaim, atau bot otomatis yang mencatat pembayaran. Pelacakan pengguna menambahkan sudut pandang manusia atau sistem ke dalam analisis proses. Analisis kinerja proses berdasarkan pengguna atau tim dapat menunjukkan kebutuhan pelatihan, menemukan individu berkinerja tinggi, dan membantu membagi beban kerja secara tepat. Atribut ini juga penting untuk kepatuhan dan audit karena setiap tindakan dapat ditelusuri dengan jelas. Dengan atribut ini, Anda dapat menganalisis kinerja dan pemanfaatan sumber daya secara terperinci. Mengapa ini penting Atribut ini memungkinkan analisis kinerja tim dan individu, pembagian beban kerja, serta tingkat otomatisasi. Hasilnya membantu menilai efisiensi sumber daya dan menemukan kebutuhan pelatihan. Sumber data Biasanya ditemukan dalam log transaksi atau jejak audit, pada kolom seperti 'ID Pengguna', 'ID Karyawan', atau 'Pemroses'. Contoh john.doejane.smithAUTO-POSTER-BOTU123456 | |||
| Alasan penyesuaian AdjustmentReason | Alasan penyesuaian keuangan, seperti pengurangan sesuai kontrak atau penghapusan piutang tak tertagih. | ||
| Deskripsi Seperti alasan penolakan klaim, Alasan penyesuaian menjelaskan mengapa sebagian jumlah yang ditagihkan dihapus atau disesuaikan. Alasannya dapat menunjukkan apakah penyesuaian terjadi karena kewajiban kontrak dengan penanggung, kebijakan layanan amal, penghapusan saldo kecil, atau koreksi kesalahan penagihan. Analisis Alasan penyesuaian memberi gambaran tentang integritas pendapatan dan kinerja keuangan. Analisis ini membantu membedakan penyesuaian kontrak yang memang diharapkan dari penghapusan piutang yang sebenarnya dapat dicegah akibat kesalahan internal. Dengan memfilter peta proses berdasarkan alasan penyesuaian tertentu, analis dapat menemukan kelemahan proses yang menyebabkan hilangnya pendapatan dan menentukan fokus perbaikan. Mengapa ini penting Atribut ini memberi konteks untuk penyesuaian keuangan dan membantu membedakan kewajiban kontrak dari hilangnya pendapatan yang dapat dicegah akibat kesalahan proses. Sumber data Ditemukan dalam tabel transaksi keuangan di sistem penagihan atau akuntansi pasien, biasanya terkait dengan transaksi penyesuaian atau penghapusan piutang. Contoh Pengurangan sesuai kontrakPenghapusan saldo kecilPiutang tak tertagihKoreksi kesalahan penagihan | |||
| ID klaim ClaimId | Identitas unik yang diberikan kepada klaim asuransi yang diajukan kepada penanggung. | ||
| Deskripsi ID klaim adalah identitas khusus untuk tagihan yang dikirim ke perusahaan asuransi. Satu peristiwa penagihan dapat menghasilkan beberapa klaim jika tagihan diajukan kepada penanggung utama, sekunder, dan tersier, atau jika klaim dikoreksi lalu diajukan kembali. Pelacakan ID klaim penting untuk memahami detail proses interaksi dengan penanggung. Atribut ini memungkinkan analisis pengulangan pekerjaan akibat pengajuan ulang klaim dan membantu melacak status tagihan tertentu yang dikirim kepada penanggung. Analisis proses berdasarkan ID klaim memberikan gambaran yang lebih terperinci tentang siklus pengajuan dan penyelesaian klaim dibandingkan analisis berdasarkan Peristiwa penagihan saja. Mengapa ini penting Atribut ini memungkinkan pelacakan pengajuan dan pengajuan ulang klaim secara terperinci, sehingga interaksi dengan penanggung dan pengulangan pekerjaan dapat dianalisis lebih mendalam. Sumber data Identitas ini dibuat oleh sistem penagihan saat klaim dibuat dan disimpan dalam tabel pengelolaan klaim. Contoh CLM-2024-555-1239876543210-01TCN-A1B2C3D4E5 | |||
| ID pasien PatientId | Identitas unik pasien yang menerima layanan. | ||
| Deskripsi Patient ID adalah kunci unik untuk setiap pasien dalam indeks induk pasien di sistem layanan kesehatan. ID ini menghubungkan seluruh riwayat layanan klinis dan transaksi keuangan pasien. Billing Event ID mewakili satu kasus layanan, sedangkan Patient ID memungkinkan analisis yang lebih luas atas beberapa kunjungan pasien yang sama. Analisis ini dapat mengungkap masalah berulang, seperti kesalahan pendaftaran yang terus terjadi atau pola penggunaan layanan. Patient ID juga dapat digunakan untuk menganalisis seluruh perjalanan keuangan pasien, sehingga membantu memahami tanggungan biaya dan loyalitas pasien. Mengapa ini penting Atribut ini memungkinkan analisis beberapa peristiwa penagihan untuk pasien yang sama, sehingga masalah berulang dapat ditemukan dan keseluruhan perjalanan keuangan pasien dapat dipahami. Sumber data Identitas utama ini tersedia di hampir semua sistem klinis dan keuangan, dan berasal dari sistem pendaftaran pasien atau EHR. Contoh MRN-100345PAT-987654321202400567 | |||
| Jumlah yang dibayar PaidAmount | Total nilai pembayaran yang diterima dari penanggung dan pasien untuk layanan yang ditagihkan. | ||
| Deskripsi Jumlah yang dibayar adalah total seluruh pembayaran yang dicatat untuk suatu peristiwa penagihan. Jumlah ini mencakup pembayaran dari penanggung asuransi utama dan sekunder, serta pembayaran pasien. Nilai ini menunjukkan uang yang benar-benar diterima untuk layanan yang diberikan. Analisis Jumlah yang dibayar penting untuk mengukur keberhasilan dan efisiensi keuangan siklus pendapatan. Membandingkannya dengan Jumlah yang ditagihkan memberi gambaran tentang pendapatan bersih dan tingkat penagihan. Dalam process mining, atribut ini membantu mengukur hasil keuangan dari berbagai jalur proses dan menemukan ciri klaim yang dibayar penuh dan tepat waktu, dibandingkan dengan klaim yang tidak. Mengapa ini penting Atribut ini mengukur uang yang benar-benar diterima untuk suatu kasus. Informasi ini penting untuk menilai efektivitas penagihan dan kinerja keuangan proses secara keseluruhan. Sumber data Informasi ini terdapat dalam tabel transaksi pencatatan pembayaran atau penerapan kas. Contoh 120.502000.000.00450.25 | |||
| Saldo tertunggak OutstandingBalance | Sisa saldo yang belum dibayar untuk suatu peristiwa penagihan pada waktu tertentu. | ||
| Deskripsi Saldo tertunggak menunjukkan jumlah yang masih harus ditagih untuk suatu peristiwa penagihan. Nilai ini biasanya dihitung dengan mengurangi Jumlah yang dibayar dan Jumlah penyesuaian dari Jumlah yang ditagihkan. Nilainya berubah selama siklus kasus seiring pencatatan pembayaran dan penyesuaian. Atribut ini menjadi indikator utama kondisi piutang. Dalam process mining, analisis saldo tertunggak di berbagai tahap proses membantu mengelola umur piutang dan menentukan prioritas penagihan. Atribut ini dapat menunjukkan jenis kasus atau jalur proses yang cenderung menyisakan saldo tinggi, yang mungkin menandakan masalah pembayaran atau penyelesaian penolakan klaim. Mengapa ini penting Atribut ini menjadi ukuran penting untuk menilai piutang dan efektivitas penagihan. Informasi ini membantu menentukan prioritas tindak lanjut dan menganalisis umur piutang. Sumber data Sering dihitung dari jumlah yang ditagihkan, dibayar, dan disesuaikan. Nilai ini juga dapat disimpan sebagai kolom dalam sistem piutang atau akuntansi pasien. Contoh 50.000.00125.308500.00 | |||
| Status akun AccountStatus | Kondisi terkini akun penagihan dalam siklus pendapatan, seperti 'Ditagihkan', 'Dibayar', atau 'Dalam penagihan piutang'. | ||
| Deskripsi Status akun menunjukkan posisi suatu peristiwa penagihan dalam siklusnya pada waktu tertentu. Status ini mencerminkan hasil aktivitas terakhir, misalnya apakah akun masih terbuka dan menunggu pembayaran, sudah ditutup, dikirim ke penagihan piutang, atau berada dalam kondisi lain. Process mining merekonstruksi alur aktivitas, sedangkan atribut Status akun berguna untuk memfilter dan mengelompokkan kasus berdasarkan kondisinya saat ini. Atribut ini sangat berguna untuk dashboard pemantauan operasional yang menampilkan jumlah dan nilai akun pada berbagai tahap. Contohnya, total piutang yang masih menunggu tanggapan penanggung atau jumlah akun yang baru dikirim ke agen penagihan piutang. Mengapa ini penting Atribut ini menunjukkan kondisi terkini kasus. Informasi ini berguna untuk dashboard operasional dan mengelompokkan analisis berdasarkan posisi akun dalam siklusnya. Sumber data Biasanya berupa kolom status pada catatan utama akun pasien atau peristiwa penagihan di sistem akuntansi pasien. Contoh Ditagihkan, menunggu penanggungLunasDitolakDikirim ke penagihan piutangDitutup, dihapuskan | |||
Aktivitas pengelolaan siklus pendapatan
| Aktivitas | Deskripsi | ||
|---|---|---|---|
| Billing event ditutup | Billing event telah diselesaikan sepenuhnya, saldo terutangnya menjadi nol, dan tidak ada aktivitas lanjutan yang diharapkan. Hal ini dapat terjadi melalui pembayaran, penyesuaian, penghapusan piutang, atau gabungan dari semuanya. | ||
| Mengapa ini penting Aktivitas ini menandai akhir proses dan memungkinkan penghitungan waktu siklus secara keseluruhan. Aktivitas ini memastikan hasil akhir billing event, baik berhasil ditagih maupun dihapuskan. Sumber data Status ini sering disimpulkan saat saldo akun menjadi nol. Beberapa sistem mungkin memiliki status 'Ditutup' atau kolom tanggal penutupan pada catatan akun. Pengumpulan data Simpulkan peristiwa ini dengan menemukan stempel waktu transaksi keuangan terakhir yang membuat saldo billing event menjadi nol. Jenis peristiwa inferred | |||
| Klaim diajukan | Aktivitas ini menandai pengajuan klaim yang telah dibuat, secara elektronik atau melalui dokumen fisik, kepada perusahaan asuransi atau pihak pembayar untuk dinilai. Ini adalah permintaan resmi atas pembayaran layanan yang telah diberikan. | ||
| Mengapa ini penting Pelacakan aktivitas ini penting untuk mengukur waktu siklus layanan hingga tagihan dan menemukan keterlambatan antara pembuatan dan pengajuan klaim. Ini adalah tonggak penting yang menandai saat billing event resmi masuk ke piutang usaha. Sumber data Peristiwa ini biasanya tercatat dalam log transaksi klaim atau tabel antarmuka clearinghouse, sering kali dengan pembaruan status khusus yang menandakan pengiriman berhasil. Pengumpulan data Catat stempel waktu saat status klaim berubah menjadi 'Diajukan', 'Dikirim', atau status lain yang setara. Jenis peristiwa explicit | |||
| Klaim ditolak | Menandai penolakan klaim atau item tertentu oleh pihak pembayar sehingga pembayaran tidak dapat dilakukan. Penolakan ini biasanya diketahui saat penyedia layanan menerima dan memproses dokumen pemberitahuan pembayaran dari pihak pembayar. | ||
| Mengapa ini penting Menemukan klaim yang ditolak merupakan langkah mendasar untuk menganalisis kebocoran pendapatan, tingkat penolakan, dan efektivitas proses penanganan penolakan. Penolakan menjadi pemicu utama pengerjaan ulang dan pengajuan banding. Sumber data Peristiwa ini biasanya tercatat dalam data pemberitahuan pembayaran. Penolakan dapat diketahui dari kode alasan penyesuaian klaim (CARC) yang menunjukkan klaim ditolak. Pengumpulan data Simpulkan peristiwa ini dengan memeriksa data pemberitahuan pembayaran untuk menemukan kode penolakan yang terkait dengan klaim atau baris layanan. Jenis peristiwa inferred | |||
| Layanan diberikan | Aktivitas ini menandai awal billing event, yaitu saat layanan klinis diberikan kepada pasien. Inilah pemicu yang memulai seluruh proses siklus pendapatan untuk satu kunjungan. | ||
| Mengapa ini penting Ini adalah titik awal utama untuk proses dari awal hingga akhir dan menjadi dasar pengukuran total waktu siklus pendapatan. Data ini membantu menemukan jeda antara pemberian layanan klinis dan dimulainya aktivitas penagihan. Sumber data Informasi ini biasanya berasal dari sistem klinis, penjadwalan, atau rekam medis elektronik. Data sering dicatat dari catatan klinis yang telah ditandatangani, log prosedur yang telah diselesaikan, atau catatan pasien keluar. Pengumpulan data Catat stempel waktu saat kunjungan klinis diselesaikan, tanggal layanan, atau tanggal pasien keluar. Jenis peristiwa explicit | |||
| Pembayaran dibukukan | Pembayaran yang diterima resmi diterapkan ke akun pasien dan dialokasikan ke baris layanan tertentu. Tindakan ini memindahkan saldo dari piutang usaha menjadi kas dan mengurangi saldo terutang. | ||
| Mengapa ini penting Ini adalah tonggak keberhasilan penting yang memastikan pendapatan telah diterima dari pihak pembayar. Keterlambatan pembukuan pembayaran dapat mengganggu keakuratan laporan umur piutang usaha dan arus kas. Sumber data Ini adalah transaksi keuangan yang dicatat secara langsung dalam buku besar sistem akuntansi pasien. Setiap penerapan pembayaran seharusnya memiliki tanggal dan waktu transaksi sendiri. Pengumpulan data Gunakan stempel waktu transaksi dari penerapan pembayaran atau jurnal pembukuan kas. Jenis peristiwa explicit | |||
| Akun dihapuskan | Semua upaya penagihan telah dilakukan, tetapi sisa saldo akun dinilai tidak dapat ditagih. Saldo disesuaikan menjadi nol dan diklasifikasikan sebagai piutang tak tertagih, yang menandai kehilangan pendapatan akhir. | ||
| Mengapa ini penting Aktivitas ini merupakan peristiwa keuangan penting yang menandai hilangnya pendapatan. Analisis penghapusan piutang penting untuk memahami tingkat keberhasilan penagihan akhir dan sumber utang yang tidak dapat dipulihkan. Sumber data Ini adalah transaksi keuangan yang dicatat secara langsung, biasanya berupa penyesuaian dengan kode alasan khusus seperti 'Penghapusan Piutang Tak Tertagih' atau 'Diserahkan ke Agen Penagihan'. Pengumpulan data Catat tanggal transaksi penyesuaian yang mengklasifikasikan sisa saldo sebagai piutang tak tertagih. Jenis peristiwa explicit | |||
| Akun disesuaikan | Transaksi selain pembayaran yang mengubah saldo akun, seperti penyesuaian kontraktual, penghapusan saldo kecil, atau diskon sebagai bentuk itikad baik. Penyesuaian ini diperlukan untuk merekonsiliasi akun berdasarkan kontrak dengan pihak pembayar atau kebijakan internal. | ||
| Mengapa ini penting Penyesuaian merupakan salah satu penyebab utama perubahan pendapatan. Analisis aktivitas dan alasan penyesuaian membantu memahami profitabilitas, kinerja kontrak dengan pihak pembayar, dan integritas pendapatan. Sumber data Transaksi ini dicatat secara terpisah dalam buku besar pasien. Setiap transaksi memiliki kode atau jenis transaksi khusus yang menunjukkan alasan penyesuaian. Pengumpulan data Catat tanggal transaksi keuangan selain pembayaran atau biaya yang mengubah saldo akun. Jenis peristiwa explicit | |||
| Biaya layanan dicatat | Menandai pencatatan resmi semua layanan, prosedur, dan perlengkapan yang dapat ditagihkan untuk kunjungan pasien. Aktivitas klinis ini diubah menjadi transaksi keuangan yang dapat ditagihkan. | ||
| Mengapa ini penting Analisis jeda antara pemberian layanan dan pencatatan biaya dapat mengungkap keterlambatan pengakuan pendapatan. Langkah ini penting untuk memastikan semua layanan yang dapat ditagihkan sudah tercatat dan mencegah kebocoran pendapatan. Sumber data Data ini tersedia di tabel transaksi biaya atau log keuangan dalam sistem penagihan atau akuntansi pasien. Setiap item yang dapat ditagihkan seharusnya memiliki stempel waktu pencatatan. Pengumpulan data Gunakan tanggal pencatatan transaksi biaya yang terkait dengan billing event. Jenis peristiwa explicit | |||
| Klaim diajukan kembali | Setelah ditolak, klaim diperbaiki dan dikirim kembali kepada pihak pembayar untuk dipertimbangkan ulang. Ini adalah upaya kedua untuk memperoleh pembayaran sekaligus menutup siklus pengerjaan ulang awal. | ||
| Mengapa ini penting Aktivitas ini penting untuk memahami efisiensi proses penyelesaian penolakan. Pelacakan pengajuan ulang membantu mengukur waktu siklus pengerjaan ulang dan tingkat keberhasilan pengajuan banding. Sumber data Peristiwa ini dicatat sebagai pengajuan klaim baru yang ditautkan ke klaim awal yang ditolak. Cari catatan pengajuan dengan penanda koreksi atau pengajuan ulang. Pengumpulan data Temukan transaksi pengajuan klaim yang merujuk pada ID klaim yang pernah diajukan atau memiliki penanda pengajuan ulang. Jenis peristiwa explicit | |||
| Klaim dibuat | Sistem telah membuat klaim penagihan resmi dengan menggabungkan semua biaya, kode, dan informasi demografis ke dalam format standar. Ini adalah tahap persiapan sebelum klaim dikirim kepada pihak pembayar. | ||
| Mengapa ini penting Ini menandai saat tagihan siap diajukan. Analisis waktu dari tahap ini hingga pengajuan dapat mengungkap keterlambatan sistem atau proses pengelompokan yang memperlambat penagihan. Sumber data Peristiwa ini dibuat oleh sistem dan seharusnya tercatat dalam tabel atau berkas klaim, dengan stempel waktu pembuatan yang jelas pada header klaim. Pengumpulan data Gunakan stempel waktu pembuatan catatan klaim utama yang terkait dengan billing event. Jenis peristiwa explicit | |||
| Pemberitahuan pembayaran diterima | Sistem menerima tanggapan dari pihak pembayar atas klaim yang diajukan, biasanya dalam berkas Electronic Remittance Advice (ERA). Tanggapan ini merinci jumlah yang dibayar, ditolak, atau disesuaikan untuk setiap baris layanan. | ||
| Mengapa ini penting Peristiwa penting ini menentukan jalur proses berikutnya, seperti pembukuan pembayaran, penanganan penolakan, atau penyesuaian. Waktu tunggu hingga pemberitahuan pembayaran diterima menunjukkan kinerja pihak pembayar. Sumber data Peristiwa ini dicatat saat sistem menerima berkas pertukaran data elektronik (EDI), seperti berkas 835, atau saat pengguna memasukkan data secara manual dari dokumen Explanation of Benefits (EOB) versi cetak. Pengumpulan data Gunakan stempel waktu pemrosesan atau impor berkas pemberitahuan pembayaran yang terkait dengan klaim. Jenis peristiwa explicit | |||
| Penagihan dimulai | Akun pasien telah menunggak dan upaya penagihan proaktif dimulai. Upaya ini dapat berupa surat pengingat otomatis atau penyerahan akun kepada petugas penagihan internal maupun eksternal. | ||
| Mengapa ini penting Ini menandai peningkatan upaya untuk menagih piutang yang telah jatuh tempo. Pemantauan aktivitas ini membantu menilai efektivitas strategi penagihan dan kinerja agen penagihan. Sumber data Peristiwa ini sering dicatat melalui perubahan kelas keuangan atau kode status akun, atau penugasan akun ke antrean kerja penagihan atau agen tertentu. Pengumpulan data Simpulkan peristiwa ini dari stempel waktu pertama saat status akun berubah menjadi 'Dalam penagihan', 'Menunggak', atau status serupa. Jenis peristiwa inferred | |||
| Pengerjaan ulang klaim yang ditolak dimulai | Pengguna atau alur kerja otomatis mulai meninjau dan menyelesaikan klaim yang ditolak. Aktivitas ini menandai dimulainya proses internal untuk menyanggah penolakan dan memulihkan potensi pendapatan. | ||
| Mengapa ini penting Aktivitas ini memulai siklus pengerjaan ulang klaim yang ditolak. Analisis waktu antara penolakan dan dimulainya pengerjaan ulang membantu mengukur kecepatan tanggap tim penanganan penolakan dan menemukan penumpukan pekerjaan. Sumber data Data ini dapat diambil dari tindakan pengguna dalam modul penanganan penolakan, perubahan status klaim, atau penugasan klaim yang ditolak ke antrean kerja pengguna. Pengumpulan data Catat stempel waktu saat klaim yang ditolak pertama kali dibuka, ditugaskan, atau statusnya berubah menjadi 'Sedang dikerjakan ulang'. Jenis peristiwa explicit | |||
| Pengodean selesai | Menandakan bahwa petugas pengodean medis telah menetapkan kode klinis standar, seperti kode ICD atau CPT, pada biaya yang dicatat. Langkah ini memastikan layanan direpresentasikan dengan cara yang dapat dipahami dan dinilai oleh pihak pembayar. | ||
| Mengapa ini penting Aktivitas ini penting untuk memastikan klaim akurat dan sering menjadi sumber hambatan. Dengan mengukur durasi tahap pengodean, Anda dapat menemukan peluang untuk meningkatkan produktivitas petugas pengodean dan mengurangi klaim yang tertahan. Sumber data Data ini sering dicatat sebagai perubahan status billing event atau stempel waktu saat tugas terkait pengodean ditandai selesai dalam antrean kerja. Pengumpulan data Temukan stempel waktu saat status pengodean kunjungan berubah menjadi 'Selesai' atau saat kode akhir disetujui. Jenis peristiwa explicit | |||
| Tagihan pasien dikirim | Setelah semua pembayaran asuransi dan penyesuaian dibukukan, tagihan dibuat dan dikirim kepada pasien untuk bagian biaya yang menjadi tanggungannya. Pada tahap ini, penagihan beralih dari pihak pembayar institusi ke pasien. | ||
| Mengapa ini penting Aktivitas ini memulai bagian pembayaran mandiri dalam siklus pendapatan. Pelacakan aktivitas ini membantu menganalisis efektivitas penagihan kepada pasien dan mengukur waktu hingga tagihan dikirim. Sumber data Modul penagihan pasien atau komunikasi mencatat peristiwa ini secara langsung. Sistem seharusnya mencatat tanggal setiap tagihan dibuat atau dikirim. Pengumpulan data Gunakan tanggal pembuatan atau pengiriman dari log riwayat tagihan pasien. Jenis peristiwa explicit | |||
Panduan ekstraksi
Metode ekstraksi berbeda-beda untuk setiap sistem. Untuk petunjuk lengkap,
baca panduan ETL kami atau pilih proses dan sistem tertentu.
Siap memulai?
Pilih salah satu panduan ekstraksi untuk sistem tertentu di bawah ini untuk mengetahui cara mengekspor data. Untuk sistem lain, gunakan templat umum ini sebagai titik awal.
Tingkatkan pengelolaan siklus pendapatan Anda sekarang
Dapatkan wawasan, kurangi penolakan klaim, dan percepat arus kas di semua sistem.
Tidak perlu kartu kredit • Mulai dalam hitungan menit