Templat data Revenue Cycle Management Anda

Optum360
Templat data Revenue Cycle Management Anda

Templat data Revenue Cycle Management Anda

Templat ini membantu Anda mengumpulkan data yang diperlukan untuk menganalisis proses Revenue Cycle Management. Di dalamnya tercantum atribut penting yang perlu dikumpulkan, aktivitas utama yang perlu dipantau, serta panduan praktis untuk mengekstrak data. Ikuti templat ini agar data Anda siap dianalisis dengan process mining.
  • Atribut yang disarankan untuk dikumpulkan
  • Aktivitas utama yang perlu dilacak
  • Panduan ekstraksi data
Baru mengenal log peristiwa? Pelajari cara membuat log peristiwa process mining.

Atribut Revenue Cycle Management

Berikut kolom data yang disarankan untuk disertakan dalam event log agar analisis Revenue Cycle Management lebih menyeluruh.
3 Wajib 6 Disarankan 10 Opsional
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
Wajib Disarankan Opsional

Aktivitas Revenue Cycle Management

Berikut tahapan dan pencapaian proses utama yang perlu dicatat dalam event log agar proses dapat ditemukan dengan akurat.
6 Disarankan 9 Opsional
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
Disarankan Opsional

Panduan ekstraksi data

Cara mengambil data dari Optum360

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.

Mulai uji coba gratis

Tidak perlu kartu kredit. Penyiapan hanya beberapa menit.