Templat data Revenue Cycle Management Anda
Templat data Revenue Cycle Management Anda
- Atribut yang disarankan untuk dikumpulkan
- Aktivitas utama yang perlu dilacak
- Panduan ekstraksi data
Atribut Revenue Cycle Management
| Nama | Deskripsi | ||
|---|---|---|---|
| Nama Aktivitas ActivityName | Nama peristiwa atau tugas tertentu yang terjadi dalam proses pengelolaan siklus pendapatan. | ||
| Deskripsi Nama Aktivitas menjelaskan langkah dalam proses siklus pendapatan, seperti 'Klaim diajukan kepada penanggung' atau 'Pembayaran diterima'. Atribut ini menjadi dasar process mining karena menentukan simpul dalam peta proses. Dengan menganalisis urutan dan frekuensi aktivitas, organisasi dapat melihat alur proses yang sebenarnya, menemukan penyimpangan dari prosedur standar, dan mengidentifikasi pola pekerjaan ulang yang umum. Analisis ini membantu memahami inefisiensi proses dan masalah kepatuhan. Mengapa ini penting Atribut ini menentukan setiap langkah proses, menjadi dasar peta proses dan memungkinkan analisis berdasarkan alur. Sumber data Biasanya, data ini diambil dari log peristiwa, catatan perubahan status, atau kode transaksi tertentu dalam tabel operasional Optum360. Contoh Klaim dibuatKlaim diajukan kepada penanggungPembayaran diterimaKlaim ditolakAkun ditutup | |||
| Peristiwa penagihan BillingEvent | ID unik untuk satu layanan atau produk yang diberikan dan menghasilkan biaya. ID ini berfungsi sebagai ID kasus utama. | ||
| Deskripsi Peristiwa Penagihan berfungsi sebagai ID kasus utama yang menghubungkan semua aktivitas terkait satu layanan atau produk yang diberikan dan menghasilkan biaya. Dengan ID ini, Anda dapat melacak seluruh siklus perolehan dan penagihan pendapatan untuk setiap layanan atau barang yang ditagihkan. Dalam process mining, analisis berdasarkan Peristiwa Penagihan membantu organisasi melihat perjalanan lengkap dari pemberian layanan hingga pembayaran akhir atau penutupan akun. Tampilan ini penting untuk menemukan hambatan, mengukur waktu siklus, dan memahami perbedaan penanganan klaim atau faktur. Mengapa ini penting Ini adalah ID Kasus utama yang menghubungkan semua aktivitas terkait dalam siklus pendapatan, sehingga Anda dapat menganalisis proses secara menyeluruh dari awal hingga akhir. Sumber data Ini adalah kunci utama yang menghubungkan catatan dalam tabel inti penagihan dan klaim Optum360. Lihat dokumentasi Optum360 untuk mengetahui nama tabel dan kolom tertentu. Contoh BE-2023-0012345BE-2023-0012346BE-2023-0012347 | |||
| Waktu Peristiwa EventTime | Stempel waktu yang menunjukkan kapan aktivitas atau peristiwa tertentu terjadi. | ||
| Deskripsi Waktu Peristiwa adalah stempel waktu untuk setiap aktivitas yang menunjukkan tanggal dan waktu terjadinya secara tepat. Data waktu ini diperlukan untuk menyusun urutan kronologis peristiwa dalam setiap kasus. Dalam analisis, Waktu Peristiwa digunakan untuk menghitung waktu siklus antaraktivitas, mengukur durasi kasus, dan menemukan hambatan yang menyita banyak waktu tunggu. Data ini menjadi dasar analisis proses berbasis waktu dan pengukuran kinerja. Mengapa ini penting Stempel waktu ini penting untuk menyusun urutan peristiwa dengan benar dan menghitung semua metrik durasi, seperti waktu siklus dan waktu yang terbuang akibat hambatan. Sumber data Informasi ini biasanya disimpan bersama setiap transaksi atau catatan perubahan status dalam tabel database Optum360. Contoh 2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:22:00Z | |||
| Departemen Penagihan BillingDepartment | Departemen atau tim internal yang mengelola atau melakukan aktivitas penagihan. | ||
| Deskripsi Atribut Departemen Penagihan menunjukkan tim atau bagian tertentu dalam operasional siklus pendapatan yang bertanggung jawab atas suatu aktivitas. Misalnya, tim yang berbeda dapat menangani pengodean, pengajuan klaim, dan pengelolaan penolakan. Atribut ini penting untuk membandingkan kinerja, seperti yang diminta oleh dashboard 'Tolok Ukur Kinerja Departemen Penagihan'. Pimpinan dapat membandingkan efisiensi, kecepatan, dan ketepatan tiap tim, menemukan praktik yang efektif, serta mengalokasikan sumber daya untuk mengatasi kesenjangan kinerja. Mengapa ini penting Memungkinkan perbandingan kinerja antar tim penagihan untuk menemukan tim berkinerja tinggi dan bagian yang perlu diperbaiki. Sumber data Informasi ini dapat ditentukan dari pengguna yang melakukan tugas atau dari kolom pada akun yang menunjukkan penanggung jawab. Lihat dokumentasi Optum360. Contoh Kantor Penagihan PusatTim Pengelolaan PenolakanDepartemen PengodeanLayanan Keuangan Pasien | |||
| ID Pasien PatientId | ID unik untuk pasien yang menerima layanan. | ||
| Deskripsi ID Pasien adalah ID unik yang diberikan kepada setiap pasien dalam sistem layanan kesehatan. ID ini menghubungkan beberapa peristiwa penagihan dengan satu pasien, sehingga analisis dapat dilakukan berdasarkan pasien. Dengan ID Pasien, analis dapat meneliti pola pada pasien tertentu, seperti rawat inap ulang yang sering atau riwayat penolakan klaim. ID ini juga memungkinkan proses dikelompokkan berdasarkan demografi atau riwayat pasien, sehingga dapat mengungkap wawasan penting untuk memperbaiki pengalaman keuangan pasien. Mengapa ini penting Memungkinkan analisis berdasarkan pasien untuk memahami perjalanan keuangan dari awal hingga akhir dan menemukan pola pada kelompok pasien tertentu. Sumber data ID ini merupakan kolom utama dalam data induk pasien dan tabel transaksi Optum360. Lihat dokumentasi Optum360 untuk detailnya. Contoh PAT-98765PAT-98766PAT-98767 | |||
| ID Penanggung PayerId | Pengenal unik perusahaan asuransi atau penanggung yang bertanggung jawab atas klaim. | ||
| Deskripsi ID Penanggung menunjukkan perusahaan asuransi tertentu, program pemerintah seperti Medicare atau Medicaid, atau entitas lain yang bertanggung jawab membayar klaim. Setiap penanggung biasanya memiliki aturan, persyaratan pengajuan, dan pola pembayaran sendiri. Dalam RCM, analisis proses berdasarkan ID Penanggung sangat penting. Analisis ini membantu mengetahui penanggung dengan siklus pembayaran terlama, tingkat penolakan tertinggi, atau proses banding paling rumit. Dengan informasi ini, bagian penagihan dapat menyesuaikan strategi untuk tiap penanggung agar pembayaran lebih cepat dan beban administrasi berkurang. Mengapa ini penting Mengelompokkan proses berdasarkan penanggung penting untuk mengetahui pihak yang menyebabkan keterlambatan atau penolakan, sehingga pengelolaan penanggung dapat diperbaiki secara terarah. Sumber data Informasi ini tersimpan pada setiap catatan klaim di Optum360. Lihat dokumentasi Optum360 untuk mengetahui nama tabel dan kolom terkait penanggung. Contoh PAYER-AETNAPAYER-BCBS-MAPAYER-MEDICAREPAYER-UHC | |||
| Jumlah Penyesuaian AdjustedAmount | Nilai uang dari penghapusan piutang, penyesuaian kontrak, atau koreksi terhadap jumlah yang ditagihkan. | ||
| Deskripsi Jumlah Penyesuaian menunjukkan bagian dari jumlah yang ditagihkan yang diperkirakan tidak akan tertagih karena perjanjian dengan penanggung, koreksi penagihan, atau penghapusan piutang lainnya. Nilai ini langsung mengurangi pendapatan. Atribut ini penting untuk dashboard 'Dampak Penyesuaian Pendapatan' dan KPI 'Tingkat Penyesuaian Pendapatan'. Analisis penyesuaian membantu mengetahui dampak keuangan dari kontrak dengan penanggung dan menemukan peluang untuk mengurangi kebocoran pendapatan melalui penagihan yang lebih akurat atau negosiasi kontrak. Mengapa ini penting Mengukur langsung kebocoran pendapatan. Atribut ini penting untuk menghitung KPI kinerja keuangan dan memahami profitabilitas. Sumber data Informasi ini terdapat dalam catatan transaksi penyesuaian di sistem keuangan Optum360. Contoh 30.00250.2510.00 | |||
| Jumlah yang Ditagihkan BilledAmount | Total nilai uang dari semua biaya yang diajukan dalam klaim atau faktur. | ||
| Deskripsi Jumlah yang Ditagihkan adalah total biaya kotor atas layanan yang diberikan, sebelum pembayaran, penyesuaian, atau penghapusan piutang. Nilai ini menjadi saldo awal piutang untuk transaksi penagihan. Atribut ini menjadi dasar analisis keuangan dalam process mining. Nilainya digunakan untuk menghitung KPI penting seperti Tingkat Penyesuaian Pendapatan. Anda juga dapat mengelompokkan kasus berdasarkan nilai untuk melihat apakah klaim bernilai tinggi diproses secara berbeda atau mengalami keterlambatan lebih lama dibanding klaim bernilai rendah. Mengapa ini penting Memberikan konteks keuangan untuk setiap kasus, sehingga Anda dapat menganalisis berdasarkan nilai dan menghitung KPI keuangan penting. Sumber data Kolom ini tersedia pada setiap klaim atau akun pasien di tabel keuangan Optum360. Contoh 150.001250.7585.50 | |||
| Kode Alasan Penolakan DenialReasonCode | Kode standar dari penanggung yang menjelaskan alasan klaim ditolak. | ||
| Deskripsi Saat menolak klaim, penanggung memberikan Kode Alasan Penolakan yang menjelaskan masalahnya, misalnya 'Layanan Tidak Ditanggung' atau 'Klaim Duplikat'. Kode ini penting untuk memahami penyebab utama keterlambatan pendapatan dan pekerjaan ulang. Analisis kode ini membantu tim pengelolaan penolakan menentukan prioritas, menemukan pola, dan melakukan tindakan korektif. Misalnya, seringnya penolakan karena 'Informasi Tidak Lengkap' dapat menunjukkan masalah dalam proses pembuatan klaim. Analisis ini menjadi bagian penting dalam mengurangi tingkat penolakan dan mempercepat arus kas. Mengapa ini penting Menunjukkan penyebab utama klaim ditolak, sehingga tindakan dapat diarahkan untuk mencegah penolakan berulang dan mengurangi pekerjaan ulang yang mahal. Sumber data Kode ini tercantum dalam berkas Electronic Remittance Advice (ERA) yang diterima dari penanggung dan disimpan di modul pengelolaan klaim Optum360. Contoh CO-16: Klaim/layanan tidak memiliki informasi yang diperlukanPR-97: Manfaat untuk layanan ini sudah termasuk dalam pembayaran/tunjangan untuk layanan atau prosedur lainOA-18: Klaim/layanan duplikat | |||
| Apakah Pekerjaan Ulang IsRework | Penanda yang menunjukkan apakah suatu aktivitas merupakan bagian dari siklus pekerjaan ulang, seperti pengelolaan penolakan atau banding. | ||
| Deskripsi Apakah Pekerjaan Ulang adalah penanda boolean yang menunjukkan aktivitas yang dianggap sebagai pekerjaan ulang tanpa nilai tambah, seperti 'Pekerjaan Ulang Penolakan Dimulai' atau 'Banding Diajukan'. Aktivitas ini biasanya terjadi saat proses menyimpang dari alur yang seharusnya. Atribut ini membantu mengukur jumlah pekerjaan ulang dalam proses, yang menunjukkan inefisiensi dan biaya secara langsung. Atribut ini digunakan untuk menghitung KPI 'Tingkat Pekerjaan Ulang akibat Kesalahan Penagihan' dan mendukung dashboard 'Identifikasi Hambatan dan Siklus Pekerjaan Ulang' dengan memudahkan Anda menyaring dan melihat siklus yang tidak efisien. Mengapa ini penting Membantu mengukur inefisiensi proses dengan menandai aktivitas yang merupakan pekerjaan ulang, sehingga pemborosan lebih mudah diukur dan ditangani. Sumber data Biasanya ditentukan menggunakan logika bisnis dalam alat process mining. Misalnya, aktivitas apa pun setelah kejadian 'Penolakan Diterima' dapat ditandai sebagai pekerjaan ulang. Contoh truefalse | |||
| Durasi Kasus CaseDuration | Total waktu siklus transaksi penagihan, dari aktivitas pertama hingga aktivitas terakhir. | ||
| Deskripsi Durasi Kasus mengukur total waktu dari kejadian pertama hingga kejadian terakhir dalam satu transaksi penagihan. Ini merupakan KPI utama untuk menilai efisiensi proses secara keseluruhan. Metrik ini mendukung dashboard 'Gambaran Umum Waktu Siklus RCM dari Awal hingga Akhir' dan KPI 'Rata-rata Waktu Siklus RCM'. Dengan memantau metrik ini dari waktu ke waktu, pimpinan dapat melihat dampak inisiatif perbaikan terhadap seluruh siklus pendapatan. Mengapa ini penting Menunjukkan waktu siklus proses dari awal hingga akhir. KPI ini penting untuk mengukur kecepatan dan efisiensi proses secara keseluruhan. Sumber data Dihitung dengan mengurangi stempel waktu kejadian pertama dari stempel waktu kejadian terakhir untuk setiap ID kasus 'BillingEvent' yang unik. Contoh 30 hari95 hari45 hari | |||
| Jumlah yang Dibayar PaidAmount | Total nilai uang yang diterima dari penanggung dan pasien untuk layanan yang ditagihkan. | ||
| Deskripsi Jumlah yang Dibayar adalah total seluruh pembayaran yang dicatat pada akun untuk satu transaksi penagihan. Nilai ini menunjukkan kas yang benar-benar diterima dan menjadi ukuran utama keberhasilan siklus pendapatan. Dalam analisis proses, jumlah pembayaran perlu dipantau untuk memahami arus kas dan kinerja keuangan secara keseluruhan. Nilai ini dapat digunakan untuk menganalisis kecepatan pembayaran dan membandingkan jumlah yang ditagihkan dengan jumlah yang diterima, sehingga kekurangan pembayaran atau piutang yang tidak tertagih dapat diketahui. Mengapa ini penting Menunjukkan kas yang benar-benar diterima. Ini merupakan ukuran hasil utama proses RCM dan penting untuk analisis arus kas. Sumber data Nilai ini biasanya tersimpan di tabel transaksi pembayaran atau dirangkum pada tingkat akun di Optum360. Contoh 120.001000.500.00 | |||
| Kode Layanan ServiceCode | Kode prosedur, seperti CPT atau HCPCS, yang menunjukkan layanan tertentu yang diberikan. | ||
| Deskripsi Kode Layanan adalah kode medis standar yang menunjukkan secara tepat prosedur atau layanan yang diberikan kepada pasien. Kode ini diperlukan untuk penagihan dan menjadi faktor utama dalam menentukan penggantian biaya. Analisis proses berdasarkan Kode Layanan dapat menunjukkan prosedur yang lebih sering ditolak, memerlukan dokumentasi tambahan, atau memiliki siklus pembayaran lebih lama. Dengan begitu, Anda dapat memahami tantangan proses secara lebih terperinci dan menyusun kebijakan pengodean serta penagihan untuk jenis layanan tertentu. Mengapa ini penting Memungkinkan analisis berdasarkan jenis layanan medis, sehingga pola penolakan atau keterlambatan pembayaran untuk prosedur tertentu dapat diketahui. Sumber data Kode ini menjadi bagian penting dari catatan entri biaya dan rincian klaim di Optum360. Contoh 992137104527447 | |||
| Pembaruan Data Terakhir LastDataUpdate | Stempel waktu penyegaran atau ekstraksi data terbaru dari sistem sumber. | ||
| Deskripsi Atribut ini mencatat tanggal dan waktu terakhir data diambil dari sistem sumber dan dimuat ke perangkat process mining. Informasi ini memberi konteks tentang kebaruan data yang dianalisis. Analis dan pengguna bisnis perlu mengetahui apakah data yang mereka lihat sudah mutakhir. Informasi ini membantu menetapkan ekspektasi terkait jeda pembaruan data dan menjadi metadata penting dalam setiap proyek analisis. Mengapa ini penting Memberi konteks penting tentang kebaruan data agar pengguna mengetahui seberapa mutakhir hasil analisis. Sumber data Stempel waktu ini biasanya dibuat dan disimpan oleh proses ekstraksi, transformasi, dan pemuatan data (ETL). Contoh 2023-11-01T02:00:00Z2023-11-02T02:00:00Z | |||
| Pengguna User | Pengenal pengguna atau agen sistem yang melakukan aktivitas. | ||
| Deskripsi Atribut Pengguna menunjukkan orang, tim, atau bot otomatis tertentu yang bertanggung jawab menjalankan suatu aktivitas. Dengan atribut ini, kinerja dapat dianalisis pada tingkat individu maupun kelompok. Mengetahui pengguna atau tim yang melakukan suatu tindakan berguna untuk menilai produktivitas, kualitas, dan kepatuhan terhadap prosedur standar. Informasi ini dapat membantu menemukan kebutuhan pelatihan atau mengapresiasi individu dan tim berkinerja tinggi. Atribut ini juga membantu membedakan tugas yang dilakukan secara manual dari tugas yang ditangani otomatis. Mengapa ini penting Menetapkan penanggung jawab untuk setiap langkah proses dan memungkinkan analisis kinerja per individu atau tim. Informasi ini penting untuk pengelolaan sumber daya dan pelatihan. Sumber data ID pengguna biasanya tercatat dalam log audit atau riwayat transaksi di Optum360. Contoh j.doem.smithAutoBillerBots.jones | |||
| Penyedia layanan ServiceProvider | Dokter, departemen, atau fasilitas yang memberikan layanan yang dapat ditagihkan. | ||
| Deskripsi Atribut ini menunjukkan penyedia tertentu, seperti dokter, terapis, atau departemen rumah sakit, yang bertanggung jawab memberikan layanan. Pola penagihan atau kebiasaan dokumentasi tiap penyedia dapat memengaruhi siklus pendapatan. Analisis berdasarkan penyedia layanan membantu menemukan masalah pencatatan biaya, ketepatan pengodean, atau kualitas dokumentasi yang berawal di tempat layanan diberikan. Hasilnya dapat menunjukkan perlunya edukasi bagi penyedia atau perbaikan proses agar klaim yang diajukan sudah benar sejak awal. Mengapa ini penting Membantu menelusuri masalah penagihan hingga ke sumbernya, sehingga staf klinis dapat menerima masukan dan pelatihan yang sesuai untuk meningkatkan pencatatan biaya dan dokumentasi. Sumber data Informasi ini menjadi bagian penting dari catatan biaya atau klaim di Optum360 dan sering kali terhubung dengan data induk penyedia. Contoh Dr. Emily CarterDepartemen RadiologiBedah UmumTerapi Fisik | |||
| Sistem Sumber SourceSystem | Sistem atau aplikasi asal tempat data peristiwa dicatat. | ||
| Deskripsi Atribut ini menunjukkan sistem sumber tempat data untuk suatu peristiwa diambil. Dalam lingkungan TI yang kompleks, data RCM dapat berasal dari platform inti Optum360, sistem Rekam Medis Elektronik (EHR) yang terhubung, clearinghouse, atau portal pasien. Mengetahui sistem sumber berguna untuk memvalidasi data, mengatasi masalah integrasi, dan menganalisis variasi proses yang mungkin disebabkan oleh perbedaan perilaku sistem atau praktik entri data. Mengapa ini penting Menunjukkan asal data. Informasi ini penting untuk tata kelola data, penilaian kualitas, dan pemahaman variasi proses di berbagai sistem. Sumber data Nilai ini dapat ditetapkan saat ekstraksi data atau diambil dari kolom dalam tabel sumber yang menunjukkan asal data. Contoh Optum360Antarmuka EHRAPI clearinghousePortal pasien | |||
| Status Akun AccountStatus | Kondisi terkini akun penagihan dalam siklus pendapatan. | ||
| Deskripsi Status Akun menunjukkan posisi suatu transaksi penagihan dalam keseluruhan proses, misalnya 'Menunggu Penanggung', 'Lunas', atau 'Dalam Penagihan'. Atribut ini memberi konteks pada aktivitas yang sedang dilakukan. Status ini berguna untuk menyaring dan mengelompokkan kasus agar Anda dapat berfokus pada bagian proses tertentu. Misalnya, analisis semua akun yang berstatus 'Dalam Penagihan' dapat membantu memahami penyebab dan jumlah kasus pada bagian proses yang memakan biaya ini. Informasi tersebut mendukung dashboard 'Volume dan Penyebab Aktivitas Penagihan'. Mengapa ini penting Memberikan gambaran umum tentang kondisi terkini suatu kasus, sehingga Anda dapat menyaring dan menganalisis kelompok kasus tertentu, seperti akun yang sedang ditagih. Sumber data Biasanya berupa kolom ringkasan pada catatan utama akun pasien atau klaim di Optum360. Contoh TerbukaMenunggu PenanggungLunasDalam PenagihanDitutup | |||
| Waktu Selesai EndTime | Stempel waktu yang menunjukkan kapan suatu aktivitas selesai. | ||
| Deskripsi Waktu Selesai menandai berakhirnya suatu aktivitas. Waktu Mulai menunjukkan kapan peristiwa terjadi, sedangkan Waktu Selesai diperlukan untuk menghitung durasi aktivitas yang memiliki waktu pemrosesan tersendiri, seperti 'Pekerjaan ulang klaim ditolak dimulai' hingga selesai. Dalam analisis proses, perbandingan Waktu Mulai dan Waktu Selesai digunakan untuk menghitung waktu pemrosesan. Dengan begitu, Anda dapat membedakan waktu kerja aktif dari waktu menganggur, yaitu waktu tunggu antaraktivitas, dan melihat efisiensi proses dengan lebih terperinci. Mengapa ini penting Memungkinkan penghitungan waktu pemrosesan aktivitas secara tepat dan membantu membedakan waktu kerja aktif dari waktu tunggu dalam proses. Sumber data Untuk beberapa aktivitas, sistem sumber mungkin memiliki kolom stempel waktu tersendiri. Untuk aktivitas lainnya, waktunya mungkin perlu disimpulkan dari waktu mulai aktivitas berikutnya. Contoh 2023-10-26T10:15:00Z2023-10-26T11:45:00Z2023-10-27T15:00:00Z | |||
Aktivitas Revenue Cycle Management
| Aktivitas | Deskripsi | ||
|---|---|---|---|
| Akun ditutup | Peristiwa penagihan dianggap selesai saat saldo akun nol dan tidak ada aktivitas lanjutan yang diperkirakan. Peristiwa ini disimpulkan ketika saldo akun menjadi nol dan statusnya berubah menjadi 'Ditutup' atau status akhir serupa. | ||
| Mengapa ini penting Ini adalah peristiwa akhir utama dalam proses. Mengukur total waktu siklus hingga tahap ini memberikan gambaran menyeluruh tentang efisiensi RCM. Sumber data Disimpulkan dari gabungan kondisi saldo akun yang mencapai nol dan kolom status akun yang diatur ke 'Ditutup', 'Lunas', atau status akhir yang setara. Pengumpulan data Stempel waktu terbaru dari pencatatan pembayaran terakhir yang membuat saldo menjadi nol atau perubahan status menjadi 'Ditutup'. Jenis peristiwa inferred | |||
| Data layanan diterima | Menandai dimulainya peristiwa penagihan, saat informasi layanan klinis diterima dari Rekam Medis Elektronik (EHR) atau sistem sumber lainnya. Peristiwa ini biasanya tercatat dalam entri log atau catatan transaksi yang dibuat oleh antarmuka integrasi setelah data berhasil diterima. | ||
| Mengapa ini penting Ini adalah peristiwa awal utama dalam siklus pendapatan. Analisis waktu dari aktivitas ini hingga pencatatan biaya penting untuk menemukan keterlambatan data di tahap awal yang berdampak pada seluruh proses. Sumber data Tercatat dalam log antarmuka atau tabel transaksi yang menangani data layanan pasien dari sistem eksternal seperti EHR. Cari stempel waktu pesan HL7 atau log panggilan API. Pengumpulan data Diambil dari log integrasi atau tabel transaksi yang diberi stempel waktu saat data diterima. Jenis peristiwa explicit | |||
| Klaim diajukan kepada penanggung | Klaim yang telah dibuat dikirim secara elektronik kepada penanggung asuransi untuk diproses. Peristiwa ini dicatat secara langsung oleh modul pengajuan klaim atau antarmuka clearinghouse setelah pengiriman berhasil. | ||
| Mengapa ini penting Ini adalah tonggak penting yang memulai penghitungan waktu respons penanggung. Data ini membantu mengukur efisiensi proses pengajuan klaim dan menemukan keterlambatan pengiriman. Sumber data Data ini terdapat di log transaksi klaim atau tabel transaksi EDI (Electronic Data Interchange), khususnya catatan pengiriman berkas klaim 837. Cari kolom 'stempel waktu pengajuan' atau 'tanggal pengiriman'. Pengumpulan data Stempel waktu dari log transaksi EDI 837 yang menunjukkan klaim berhasil diajukan. Jenis peristiwa explicit | |||
| Klaim ditolak | Penanggung menolak klaim, sebagaimana tercantum dalam rincian pembayaran yang diterima. Peristiwa ini disimpulkan dengan memeriksa data rincian pembayaran untuk menemukan kode alasan penolakan pada baris klaim. | ||
| Mengapa ini penting Melacak penolakan penting untuk menemukan akar penyebab hilangnya pendapatan dan inefisiensi proses. Aktivitas ini menjadi awal dari seluruh proses penanganan penolakan dan pekerjaan ulang pengajuan banding. Sumber data Disimpulkan dari data Electronic Remittance Advice (EDI 835). Sistem mengenali kode alasan penyesuaian klaim (CARC) yang menandakan penolakan. Pengumpulan data Disimpulkan dengan mendeteksi kode penolakan tertentu (CARC/RARC) dalam data rincian pembayaran EDI 835 yang telah diuraikan. Jenis peristiwa inferred | |||
| Pembayaran dicatat | Pembayaran yang diterima berhasil dialokasikan ke akun pasien dan baris layanan yang sesuai. Tindakan ini dilakukan secara langsung oleh pengguna atau sistem otomatis untuk mencocokkan pembayaran dengan biaya yang belum dilunasi. | ||
| Mengapa ini penting Aktivitas ini penting untuk mengukur efisiensi proses penerapan pembayaran di bagian administrasi. Keterlambatan pencatatan dapat mengganggu pelaporan piutang dan menunda penutupan akun. Sumber data Data ini terdapat di tabel transaksi pembayaran. Stempel waktu transaksi saat pembayaran dicatat digunakan sebagai waktu peristiwa. Pengumpulan data Stempel waktu pembuatan catatan transaksi pembayaran yang dialokasikan ke biaya tertentu. Jenis peristiwa explicit | |||
| Rincian pembayaran diterima | Sistem menerima berkas rincian pembayaran elektronik (ERA) dari penanggung, yang memuat informasi pembayaran, penyesuaian, dan penolakan. Peristiwa ini tercatat saat sistem menerima berkas EDI 835. | ||
| Mengapa ini penting Aktivitas ini merupakan tonggak penting yang menandakan penanggung telah memproses klaim. Isi berkas menentukan tindakan berikutnya, seperti pencatatan pembayaran atau penanganan penolakan. Sumber data Tercatat dalam log transaksi EDI untuk berkas ANSI 835 yang masuk. Stempel waktunya menunjukkan kapan berkas diterima dan diproses oleh sistem. Pengumpulan data Stempel waktu yang terkait dengan penerimaan berkas EDI 835 (Electronic Remittance Advice). Jenis peristiwa explicit | |||
| Aktivitas penagihan dimulai | Akun pasien masuk ke proses penagihan aktif karena pembayaran belum diterima. Peristiwa ini biasanya disimpulkan dari perubahan kelas keuangan atau status akun. | ||
| Mengapa ini penting Peristiwa ini menandai akun yang memerlukan tindak lanjut lebih intensif. Analisis frekuensi dan pemicu aktivitas ini membantu memperbaiki strategi penagihan di tahap awal. Sumber data Disimpulkan dari perubahan status akun menjadi 'Penagihan', 'Piutang tak tertagih', atau 'Dikirim ke agen penagihan'. Tanggal perubahan status menjadi stempel waktu peristiwa. Pengumpulan data Stempel waktu saat kolom status akun berubah menjadi nilai yang terkait dengan penagihan. Jenis peristiwa inferred | |||
| Akun disesuaikan | Penyesuaian kontraktual, penghapusbukuan, atau koreksi keuangan lainnya telah dicatat pada akun. Transaksi keuangan ini dicatat secara langsung dalam buku besar sistem. | ||
| Mengapa ini penting Penyesuaian berdampak langsung pada realisasi pendapatan. Analisis alasan dan waktu penyesuaian penting untuk menemukan masalah pada daftar tarif, kontrak, atau akurasi penagihan. Sumber data Data ini terdapat di tabel transaksi keuangan dan dapat dikenali melalui kode transaksi khusus untuk penghapusbukuan atau penyesuaian. Tanggal transaksi digunakan sebagai waktu peristiwa. Pengumpulan data Tanggal transaksi entri dalam buku besar keuangan dengan kode penyesuaian tertentu. Jenis peristiwa explicit | |||
| Biaya dicatat | Menandai saat layanan dan perlengkapan yang dapat ditagihkan secara resmi dimasukkan ke sistem penagihan. Tindakan ini dilakukan secara langsung oleh pengguna atau sistem, lalu menghasilkan catatan transaksi biaya. | ||
| Mengapa ini penting Aktivitas ini penting untuk mengukur jeda pencatatan biaya, yaitu waktu antara pemberian layanan dan dimulainya penagihan. Mengurangi jeda ini akan mempercepat siklus pendapatan. Sumber data Data ini biasanya ada di tabel transaksi biaya, yang sering disebut tabel entri biaya atau baris layanan. Stempel waktu pembuatan catatan biaya digunakan sebagai waktu peristiwa. Pengumpulan data Waktu peristiwa diambil dari stempel waktu pembuatan catatan dalam tabel master biaya atau transaksi biaya. Jenis peristiwa explicit | |||
| Klaim dibuat | Sistem telah membuat klaim yang dapat ditagihkan dengan menggabungkan semua biaya, kode, dan informasi demografi ke dalam format standar. Peristiwa ini dibuat oleh sistem dan memiliki stempel waktu pembuatan. | ||
| Mengapa ini penting Aktivitas ini menandai peralihan dari pencatatan biaya ke proses penagihan resmi. Aktivitas ini harus selesai sebelum klaim diajukan dan penting untuk melacak waktu pemrosesan internal. Sumber data Data ini terdapat di tabel klaim atau log transaksi. Stempel waktu pembuatan catatan utama klaim menandai waktu peristiwa. Pengumpulan data Diambil dari stempel waktu pembuatan catatan utama pada tabel database klaim. Jenis peristiwa explicit | |||
| Pekerjaan ulang klaim ditolak dimulai | Pengguna atau alur kerja otomatis mulai meninjau dan menyelesaikan klaim yang ditolak. Peristiwa ini dapat dicatat langsung melalui tindakan pengguna atau disimpulkan dari perubahan status klaim. | ||
| Mengapa ini penting Aktivitas ini memulai proses pekerjaan ulang untuk klaim yang ditolak. Mengukur waktu dari penerimaan penolakan hingga dimulainya pekerjaan ulang membantu menemukan penumpukan dalam antrean penanganan penolakan. Sumber data Data ini terdapat di modul penanganan penolakan atau antrean kerja. Waktunya dapat dicatat langsung saat pengguna 'membuka' atau 'mengambil' tugas penolakan, atau disimpulkan dari perubahan status seperti 'Ditolak' menjadi 'Sedang dikerjakan ulang'. Pengumpulan data Disimpulkan dari perubahan status klaim menjadi 'Pekerjaan ulang' atau 'Sedang ditinjau', atau dari log tindakan pengguna. Jenis peristiwa inferred | |||
| Pembayaran diterima | Menandakan bahwa pembayaran diterima dari penanggung atau pasien, biasanya sebagai bagian dari rincian pembayaran. Peristiwa ini dapat diambil langsung dari berkas rincian pembayaran elektronik atau log penerimaan kas manual. | ||
| Mengapa ini penting Aktivitas ini penting untuk menganalisis arus kas dan mengukur kecepatan pembayaran. Aktivitas ini juga memicu proses pencatatan pembayaran. Sumber data Diambil dari informasi pembayaran dalam berkas rincian pembayaran EDI 835 atau berkas lockbox dari bank. Tanggal cek atau tanggal pemrosesan dalam berkas biasanya digunakan. Pengumpulan data Diambil dari segmen BPR dalam berkas EDI 835 atau berkas data lockbox bank. Jenis peristiwa explicit | |||
| Pengajuan banding dikirim | Pengajuan banding resmi dikirim kepada penanggung untuk menyanggah klaim yang ditolak. Tindakan ini dicatat langsung oleh pengguna dalam modul penanganan penolakan atau pengajuan banding. | ||
| Mengapa ini penting Aktivitas ini merupakan langkah penting dalam proses pemulihan pendapatan. Melacak pengajuan banding dan durasi siklusnya penting untuk memahami efektivitas strategi penyelesaian penolakan. Sumber data Tercatat dalam modul pelacakan pengajuan banding atau sebagai jenis transaksi tertentu pada klaim. Cari kolom 'tanggal pengajuan banding' atau 'tanggal pengajuan ulang'. Pengumpulan data Stempel waktu yang dicatat saat pengguna mencatat pengiriman pengajuan banding. Jenis peristiwa explicit | |||
| Pengodean selesai | Menandakan bahwa petugas pengodean medis telah meninjau dokumentasi klinis dan menetapkan kode CPT, HCPCS, dan ICD yang sesuai. Peristiwa ini biasanya dicatat secara langsung saat pengguna atau mesin pengodean otomatis menyelesaikan tugas pengodean. | ||
| Mengapa ini penting Pengodean sering menjadi hambatan yang menunda pengajuan klaim. Dengan melacak aktivitas ini, Anda dapat mengukur produktivitas petugas pengodean dan menemukan keterlambatan dalam antrean pengodean. Sumber data Tercatat dalam modul alur kerja pengodean atau melalui perubahan status peristiwa penagihan dari 'Menunggu pengodean' menjadi 'Sudah dikodekan'. Stempel waktu perubahan status atau penyelesaian tugas digunakan. Pengumpulan data Stempel waktu pembaruan status atau entri log saat pengguna atau sistem menyelesaikan pengodean kunjungan. Jenis peristiwa explicit | |||
| Pernyataan tagihan dikirim kepada pasien | Pernyataan tagihan dibuat dan dikirim kepada pasien untuk bagian tagihan yang harus dibayar pasien. Peristiwa ini dicatat secara langsung oleh modul penagihan pasien saat pernyataan dibuat. | ||
| Mengapa ini penting Aktivitas ini memulai bagian pembayaran mandiri dalam siklus pendapatan. Pelacakannya membantu menganalisis efisiensi dan efektivitas penagihan kepada pasien. Sumber data Tercatat dalam tabel riwayat korespondensi pasien atau pembuatan pernyataan tagihan. Stempel waktunya menunjukkan kapan pernyataan dibuat atau dikirim. Pengumpulan data Stempel waktu dari log atau tabel riwayat pembuatan pernyataan tagihan pasien. Jenis peristiwa explicit | |||
Panduan ekstraksi data
Metode ekstraksi untuk proses ini sedang divalidasi. Silakan kembali lagi nanti atau hubungi kami untuk mendapatkan bantuan.
Siap memulai?
Gunakan templat ini untuk mempermudah pengumpulan data dan mulai meningkatkan proses Revenue Cycle Management Anda. Temukan wawasan yang berguna dan tingkatkan efisiensi dengan yakin.
Tingkatkan Revenue Cycle Management dan kurangi keterlambatan
Bergabunglah dengan para pemimpin yang memangkas waktu siklus hingga 30% dan memperkuat kondisi keuangan.
Tidak perlu kartu kredit. Penyiapan hanya beberapa menit.