Tim penagihan rumah sakit memproses antrean klaim yang ditolak. Setiap klaim mendapatkan perbaikan yang sama: seseorang mengoreksi sebuah kolom, memasukkan kembali data, dan mengirimkannya kembali. Seminggu kemudian, klaim dengan pola yang sama kembali muncul. Tidak ada yang menanyakan mengapa klaim tersebut ditolak sejak awal, sehingga perbaikan tidak pernah mencapai langkah yang menyebabkan kesalahan tersebut.
Ini adalah skenario ilustratif, bukan kasus yang terdokumentasi. Skenario ini menggambarkan kesenjangan yang ingin ditutup oleh pelatihan tentang akar penyebab penolakan klaim: jarak antara memperbaiki klaim yang ditolak dan mencari tahu bagian mana dari alur kerja yang menyebabkannya.
Panduan ini ditujukan untuk direktur L&D rumah sakit dan pimpinan bidang informatika atau kepatuhan yang bekerja sama dengan mereka. Panduan ini mencakup cara mendeskripsikan masalah kinerja, mendiagnosis kesenjangan pembelajaran dan konteks, merancang persiapan dan praktik, menyelesaikan studi kasus, dan menilai apakah keterampilan tersebut dapat diterapkan pada antrean kerja. Panduan ini berfokus pada desain pelatihan. Gunakan hanya kasus yang telah dianonimkan, dan minta pimpinan siklus pendapatan, informatika, dan kepatuhan Anda untuk memvalidasi setiap kasus, kode, dan jawaban sebelum siapa pun dilatih.
Apa itu pelatihan analisis akar penyebab penolakan klaim?
Pelatihan analisis akar penyebab penolakan klaim mengajarkan staf administrasi untuk menyelidiki pola penolakan yang berulang dan mengidentifikasi penyebab alur kerja di baliknya. Tugas ini bersifat analitis. Staf melihat bukti pada klaim dan dalam catatan, memisahkan apa yang dikatakan pihak pembayar dari apa yang salah di dalam organisasi, dan menjelaskan penyebab yang cukup spesifik sehingga seseorang dapat mengambil tindakan.
fakta cepat
| Pertanyaan | Jawaban singkat |
|---|---|
| Apa tugasnya? | Selidiki pola penolakan yang berulang dan identifikasi penyebab alur kerja. |
| Berapa skor Anda? | Identifikasi penyebab yang tepat, dan tingkat kekambuhan pola penyangkalan tersebut. |
| Apakah pelatihan penyegaran pemrograman sudah cukup? | Tidak. Hal itu membangun pengetahuan tentang aturan, tetapi bukan kebiasaan untuk menelusuri penyebab penolakan tersebut. |
| Siapa yang memvalidasi kontennya? | Seorang pemimpin di bidang siklus pendapatan, informatika, atau kepatuhan, menggunakan kasus-kasus yang telah dianonimkan. |
| Apa yang tidak bisa diperbaiki melalui pelatihan? | Perubahan kebijakan pembayar, batasan sistem, kepegawaian, dan kepemilikan yang tidak jelas atas suatu tahapan. |
| Bagaimana Anda tahu itu berhasil? | Suatu penolakan baru yang belum pernah terjadi sebelumnya, dinilai berdasarkan kriteria yang disepakati, dengan tindak lanjut terhadap kekambuhan. |
1. Jelaskan masalah kinerja tersebut
Mulailah dengan tugas: selidiki pola penolakan yang berulang dan identifikasi penyebab alur kerja. Dua kata memiliki bobot penting. Berulang berarti unit kerja adalah sebuah pola, bukan klaim tunggal. Penyebab alur kerja berarti jawabannya terletak di dalam proses organisasi itu sendiri, bukan pada pembayaran dari pihak pembayar.
Pedoman keuangan layanan kesehatan juga menarik garis yang sama. Dalam sebuah artikel untuk Healthcare Financial Management Association (HFMA), Denise Wilson dan Tracey Tomak menjelaskan tiga lapisan penolakan. Alasannya adalah kode yang dinyatakan oleh pembayar, seperti kode alasan penyesuaian klaim (CARC). Masalahnya adalah kategori yang luas, seperti pengkodean atau dokumentasi. Akar penyebabnya adalah kegagalan internal yang menyebabkan perbedaan pembayaran. Mereka mencatat bahwa mengidentifikasi akar penyebab memerlukan tinjauan internal terhadap rekam medis, biaya, dan klaim yang ditagihkan, dan bahwa data harus mencerminkan akar penyebab sebenarnya, bukan hanya kode alasan pada pengiriman uang.Wilson dan Tomak, HFMAMereka juga mengatakan bahwa akar penyebab harus ditulis sedemikian rupa sehingga pembaca dapat bertindak berdasarkan penyebab spesifik tersebut.
Perbedaan itulah yang menjadi target pelatihan. Penginputan ulang (re-keying) bekerja pada lapisan alasan. Analisis akar penyebab bekerja pada lapisan ketiga.
Tuliskan pernyataan kinerja dalam satu kalimat dan mintalah seorang pemimpin siklus pendapatan untuk memeriksanya: "Diberikan sekelompok penolakan terkait, anggota staf meninjau klaim dan catatan, memisahkan alasan pembayar dari penyebab internal, menyebutkan penyebab spesifik dan mengusulkan perbaikan serta siapa yang bertanggung jawab."
2. Mendiagnosis kesenjangan pembelajaran dan konteks.
Sebelum Anda membuat apa pun, bandingkan tugas tersebut dengan apa yang dipraktikkan dan dinilai oleh program Anda saat ini. Tiga pertanyaan biasanya membedakan kesenjangan pelatihan dari hal lain:
- Apakah praktik saat ini menggunakan tugas yang sebenarnya? Jika pelatihan mengajarkan staf untuk membaca kode alasan dan menerapkan koreksi standar, mereka telah mempraktikkan penginputan ulang data. Jika penilaian berupa kuis tentang definisi kode, itu mengukur daya ingat, bukan investigasi.
- Apa tuntutan kognitifnya? Dalam taksonomi Bloom yang telah direvisi, membandingkan penyangkalan untuk menemukan pola dan menilai penyebab mana yang paling sesuai dengan bukti berada pada tingkat analisis dan evaluasi. Mencari kode berada pada tingkat yang lebih rendah. Mencocokkan aktivitas dengan tingkat tersebut dibahas dalam panduan kami. Mencocokkan aktivitas pembelajaran dengan Taksonomi Bloom.
- Apakah ada hal lain selain keterampilan yang menjadi penghalang? Periksa akses, alat, dan kepemilikan. Staf yang tidak dapat melihat layar pendaftaran, tidak memiliki cara untuk memberi tahu meja depan tentang kesalahan, atau diukur berdasarkan klaim yang diselesaikan per jam akan memasukkan ulang data sesuai dengan pelatihan. Laporkan penyebab yang bukan hasil pelatihan kepada orang yang dapat memperbaikinya.
3. Persiapan dan praktik desain
Setelah Anda mengetahui kesenjangan mana yang dapat ditutup oleh pelatihan, berikan tugas yang berbeda untuk setiap tahapannya.
Persiapan. Periksa prasyarat dengan diagnosis singkat: terminologi penolakan, siklus klaim dari pendaftaran hingga pembayaran, dan arti dari kolom kode alasan. Pembelajaran mandiri cocok untuk tahap ini. Pemeriksaan ulang hanya mengkonfirmasi prasyarat.
Praktek. Gunakan analisis integritas data pada kasus yang telah dianonimkan. Dalam analisis ini, staf mengambil klaim yang ditolak, menelusurinya kembali melalui catatan, biaya, dan registrasi, lalu mencatat di mana kesalahan terjadi. Banyak staf akan menemukan kasus yang sama dengan lebih dari satu cara, jadi diskusi adalah tempat pembelajaran terjadi. Mintalah alasannya, bukan hanya label.
Umpan balik. Hubungkan hal itu dengan keputusan yang diambil, bukan hanya skor total. "Anda mengidentifikasi otorisasi yang hilang, yang merupakan penyebab sebenarnya, tetapi Anda tidak memeriksa apakah otorisasi tersebut hilang atau dimasukkan pada kunjungan yang salah" mengajarkan lebih banyak daripada "7 dari 10".
Masukan langsung atau tinjauan asinkron? Pendampingan langsung (live coaching) memberikan nilai tambah paling besar ketika suatu kasus ambigu dan staf perlu mendengar kolega berpengalaman memisahkan kebijakan pembayar dari kesalahan entri data. Tinjauan asinkron sudah cukup untuk membandingkan pernyataan penyebab tertulis seseorang dengan jawaban model yang diberi anotasi. Banyak tim menggunakan keduanya: persiapan mandiri terlebih dahulu, kemudian sesi yang difasilitasi untuk kasus-kasus tersulit.
4. Kerjakan contoh yang realistis.
Bersifat ilustratif dan anonim. Seorang penanggung jawab siklus pendapatan atau informatika harus memvalidasi kasus dan kriteria jawaban sebelum digunakan.
Kasus. Selama lebih dari satu bulan, sebelas klaim rawat jalan untuk layanan yang sama ditolak dengan alasan pembayaran yang sama. Masing-masing dikoreksi dan diajukan kembali dengan memasukkan kembali kolom yang sama. Tiga dari sebelas klaim tersebut kembali ditolak.
Tugas tersebut. Petugas meninjau klaim dan catatan, memisahkan alasan yang dinyatakan oleh pihak pembayar dari penyebab internal, menyebutkan penyebab spesifik, dan menyatakan informasi atau dukungan lebih lanjut apa yang mereka butuhkan.
Upaya pertama. "Pihak pembayar mengatakan informasinya salah. Saya telah memperbaiki kolom tersebut dan mengirimkannya kembali." Ini hanya mengulangi alasannya dan menerapkan solusi standar. Tidak ada pola atau penyebab yang dicari.
Berikan masukan dan coba lagi. Pelatih menunjuk pada dua fakta dalam kasus ini: kesebelas klaim tersebut menggunakan layanan dan lokasi pendaftaran yang sama, dan tiga klaim yang dikembalikan dikoreksi oleh staf yang berbeda. Permintaan pengulangan meminta orang tersebut untuk melihat di mana kolom tersebut pertama kali dimasukkan dan apakah langkah yang sama menghasilkan kesebelas klaim tersebut.
Upaya yang lebih baik. "Kesebelas klaim tersebut terdaftar di lokasi yang sama, jadi saya pikir kesalahan terjadi saat pendaftaran, bukan saat penagihan. Saya akan mengambil entri pendaftaran untuk klaim tersebut, dan memeriksa apakah kolom tersebut diisi dari nilai default. Jika demikian, memasukkan ulang data saat penagihan akan terus gagal. Saya tidak akan menyebut ini sebagai masalah kebijakan pembayar sampai saya memeriksa bahwa aturan pembayar tidak berubah. Saya akan membagikan temuan ini kepada pimpinan pendaftaran dan menanyakan siapa yang bertanggung jawab atas kolom tersebut." Jawaban ini menyebutkan pola, lokasi spesifik penyebabnya, pemeriksaan yang akan mengkonfirmasi atau menolak kemungkinan tersebut, dan siapa yang perlu bertindak.
Mengapa setiap respons dapat dipertahankan atau tidak lengkap. Nilailah setiap hal berdasarkan kriteria yang telah disetujui, bukan berdasarkan preferensi pelatih. Upaya pertama adalah kebiasaan umum tetapi tetap berada pada lapisan alasan. Upaya yang lebih kuat memisahkan kebijakan pembayar dari entri data dan tetap berada dalam peran orang tersebut.
5. Menilai kemampuan dan merencanakan transfer
Bukti kemampuan adalah respons terhadap pola penyangkalan yang belum pernah dilihat oleh peserta didik. Berikan skor untuk identifikasi penyebab yang benar, dan dari waktu ke waktu, tingkat kekambuhan pola yang mereka selidiki. Rubrik sederhana menggunakan skala 0 hingga 2 per kriteria:
| Kriterium | Bukti yang dapat diamati |
|---|---|
| Eksekusi tugas | Menyelidiki pola penyangkalan dan mencatat bukti di balik penyebab yang disebutkan. |
| Pemikiran | Menjelaskan kendala, alternatif, dan hal-hal yang masih belum pasti. |
| Batas | Menggunakan prosedur yang telah disetujui dan mencari bantuan jika informasi atau wewenang tidak mencukupi. |
Nilai acuan: 0 berarti tidak ada atau tidak didukung, 1 berarti sebagian dengan kelalaian yang relevan, dan 2 berarti lengkap dan dibenarkan berdasarkan kriteria yang disepakati. Definisikan kesalahan kritis secara terpisah, seperti penanganan informasi pasien yang dapat diidentifikasi di luar sistem yang disetujui, sehingga skor keseluruhan tidak dapat menyembunyikan satu kesalahan pun. Rubrik ini adalah usulan, bukan standar kesiapan yang telah divalidasi: sesuaikan dengan penanggung jawab informatika atau kepatuhan dan lakukan uji coba. Panduan kami untuk merancang praktik interaktif dengan umpan balik yang bermanfaat Menunjukkan cara menulis umpan balik yang terkait dengan keputusan.
Rencanakan transfer secara matang. Tambahkan tindak lanjut setelah staf mengerjakan antrean mereka untuk beberapa waktu, seperti tinjauan bulanan di mana setiap orang membawa satu pola penolakan yang mereka selidiki dan apa yang terjadi setelah perbaikan.
Di mana penyampaian interaktif membantu
Format interaktif membantu ketika setiap orang harus berkomitmen sebelum mendengar jawabannya. Dalam sesi langsung, fasilitator dapat menunjukkan ringkasan penolakan yang telah dianonimkan, meminta setiap orang untuk mengetik kemungkinan penyebab dan catatan pertama yang akan mereka periksa, lalu menunjukkan sebaran data sebelum diskusi. Kasus yang sama dapat dijalankan secara mandiri untuk persiapan. AhaSlides mendukung pembelajaran interaktif dan perpindahan antara penyampaian langsung dan mandiri. Jauhkan data pasien sebenarnya dari proses ini, periksa fungsi pembuatan, umpan balik, atau pelaporan spesifik yang Anda rencanakan untuk diandalkan terhadap alur kerja Anda sendiri, dan perlakukan AI, simulator, dan integrasi sistem sebagai eksternal atau belum terkonfirmasi sampai Anda melihatnya berfungsi. Untuk panduan tentang pemilihan format, lihat artikel kami tentang Kapan menggunakan pembelajaran adaptif, interaktif, dan langsung?.
Ukur apa yang berubah.
Tentukan terlebih dahulu apa yang akan menunjukkan bahwa staf mampu melakukan tugas tersebut. Bandingkan identifikasi penyebab yang benar pada pola penolakan yang belum pernah dilihat sebelumnya dengan data dasar, dan lacak tingkat kekambuhan untuk pola yang telah diselidiki. Tentukan siapa yang termasuk, penyebutnya, dan waktunya. Jika hasilnya membaik, periksa perubahan lain apa yang terjadi pada periode yang sama, seperti pembaruan kebijakan pembayar, layar pendaftaran baru, atau perubahan volume klaim, sebelum memberikan kredit untuk pelatihan tersebut.
Kendala yang mungkin masih ada
- Kebijakan pembayar. Beberapa penolakan terjadi setelah perubahan aturan dari pihak pembayar. Investigasi yang baik dapat mengidentifikasi hal ini, tetapi pelatihan tidak dapat mengubahnya.
- Batasan sistem. Jika sistem tidak dapat menunjukkan di mana suatu kolom dimasukkan, staf akan kesulitan untuk melacaknya.
- Kepemilikan. Penyebab yang ditemukan saat pendaftaran memerlukan seseorang di bagian pendaftaran untuk bertanggung jawab atas perbaikannya.
- Liputan kasus. Satu pola penyangkalan menunjukkan satu pola. Sebuah skor tidak menggambarkan penilaian seseorang secara umum.
- Transfer. Performa pada kasus pelatihan tidak sama dengan performa pada antrian penuh.
Sebutkan hal-hal ini kepada sponsor sejak dini dan rencanakan perbaikan terpisah. Pelatihan meningkatkan kemampuan staf dalam menyelidiki masalah. Namun, pelatihan tidak mengubah kondisi di sekitar antrean.
Pertanyaan yang sering diajukan
Apa itu pelatihan analisis akar penyebab penolakan klaim?
Pelatihan ini mengajarkan staf administrasi untuk menyelidiki penolakan klaim yang berulang dan melacaknya ke langkah alur kerja yang menyebabkannya, alih-alih mengoreksi dan mengirimkan kembali setiap klaim.
Apa perbedaan antara akar penyebab dan alasan penyangkalan?
Alasannya adalah kode yang dinyatakan oleh pihak pembayar. Akar penyebabnya adalah kegagalan internal di baliknya. Penolakan dapat memiliki kode alasan yang sama tetapi memiliki beberapa akar penyebab yang berbeda.
Bagaimana Anda menilai apakah staf dapat menemukan akar permasalahan?
Berikan pola penyangkalan yang belum pernah dilihat peserta didik dan beri nilai pada penyebab yang mereka sebutkan dan bukti di baliknya berdasarkan kriteria yang telah disepakati. Kuis kode hanya mengkonfirmasi prasyarat.
Bisakah Anda menggunakan klaim nyata dalam pelatihan?
Gunakan hanya kasus yang telah dianonimkan, dan jangan masukkan informasi pasien ke dalam alat pelatihan apa pun kecuali jika penanggung jawab kepatuhan Anda telah menyetujuinya.
Mulai dari mana
Pilih satu pola penolakan yang berulang. Tulis pernyataan kinerja, minta pemimpin siklus pendapatan atau informatika untuk memvalidasi kasus yang telah dianonimkan, pemeriksaan, dan siapa yang bertanggung jawab atas perbaikannya, serta susun rubrik tiga kriteria dengan skala 0 hingga 2 dan daftar kesalahan kritis. Uji coba dengan kelompok kecil sebelum Anda menerapkannya secara luas.
Untuk melihat bagaimana kasus penolakan dapat dijalankan secara langsung dengan tim Anda sendiri, dan digunakan kembali secara mandiri setelahnya, jelajahi AhaSlides.
