Kesalahan Sistem Penagihan Rumah Sakit yang Tak Disadari Siapa Pun Selama Tiga Minggu

Pendahuluan

Sebuah sistem rumah sakit regional di Midwest menerapkan pembaruan penjadwalan melalui proses perubahan rutinnya pada musim semi lalu. Tidak ada yang dramatis — hanya pembaruan rutin terkait sinkronisasi waktu pemulangan pasien dengan modul penagihan. Tiga minggu kemudian, seseorang di bagian piutang menyadari adanya sekelompok klaim yang ditolak karena ketidaksesuaian cap waktu. Saat tim TI melacaknya, perbaikan tersebut telah memengaruhi pengajuan klaim asuransi untuk lebih dari empat ratus pasien. Sebenarnya, tidak ada yang melakukan kesalahan. Pembaruan tersebut lulus setiap tes dalam daftar periksa. Hanya saja, itu bukan daftar periksa yang tepat.

Kisah itu terus terngiang di benak saya karena sebenarnya bukan tentang rumah sakit. Ini tentang apa yang terjadi ketika sistem yang diam-diam berjalan di latar belakang suatu organisasi diperlakukan sebagai produk jadi, bukan sebagai infrastruktur yang terus berkembang dan membutuhkan pengawasan rutin.

Otomatisasi yang Anda atur dua tahun lalu bukanlah otomatisasi yang Anda kira

Sebagian besar perusahaan membangun otomatisasi alur kerja pertama mereka untuk mengatasi masalah spesifik yang terlihat jelas. Tim HR bosan mengarahkan permintaan cuti secara manual. Seorang staf operasional penjualan mengotomatisasi penugasan prospek agar perwakilan penjualan berhenti memilih-milih. Otomatisasi ini dibangun dengan alat serupa Power Automate — cepat dikonfigurasi, mudah diserahkan kepada siapa pun yang bersedia mengelolanya, dan sebagian besar tidak terlihat begitu sudah berfungsi.

Masalahnya, “begitu sistem berjalan” menjadi permanen. Tidak ada yang menjadwalkan tinjauan. Orang yang membangunnya pindah tim, atau keluar. Sementara itu, bisnis berubah di sekitar otomatisasi tersebut — bidang CRM baru, hierarki persetujuan yang berbeda, atau merger yang menggandakan volume yang mengalir melalui sistem yang dirancang untuk setengah beban tersebut. Otomatisasi terus berjalan persis seperti yang dirancang, dan itulah tepatnya masalahnya. Sistem itu dirancang untuk perusahaan yang kini tidak lagi ada dalam bentuk yang sama.

Saya pernah melihat sebuah perusahaan logistik menemukan bahwa alur pengalihan pengecualian otomatis telah salah berfungsi tanpa disadari selama sebelas bulan karena vendor mengubah nama bidang API. Solusi sementara? Seseorang telah memasukkan kembali kasus-kasus yang gagal secara manual tanpa memberi tahu siapa pun, dengan asumsi bahwa itu hanya terjadi sekali saja. Itu bukanlah kegagalan alat. Itu adalah kegagalan organisasi untuk meninjau kembali sesuatu yang dianggap stabil oleh semua orang.

Rumah sakit menghadapi risiko yang sama dengan konsekuensi yang jauh lebih besar

Ambil pola yang sama dan terapkan dalam tumpukan sistem klinis dan administratif rumah sakit, dan margin kesalahan akan sangat tipis. Pengembangan perangkat lunak rumah sakit biasanya memprioritaskan kepatuhan dan waktu operasional daripada kemampuan beradaptasi — hal ini dapat dimengerti, mengingat kegagalan penerapan dapat berarti seorang perawat tidak dapat mengakses riwayat pengobatan pada pukul 2 pagi. Namun, kehati-hatian yang sama itu berarti sistem lama sering kali tetap beroperasi jauh lebih lama dari yang seharusnya, ditambal-tambal alih-alih dibangun ulang, karena tidak ada yang ingin menjadi orang yang merusak sesuatu yang menopang beban kerja.

Hasilnya adalah arsitektur yang menumpuk keputusan yang tak ada yang ingat pernah dibuat. Modul penjadwalan terhubung dengan sistem penagihan melalui integrasi yang dibangun pada tahun 2016 untuk vendor yang sudah tidak digunakan rumah sakit sejak 2019. Sistem itu masih berfungsi, sebagian besar. “Sebagian besar” bukanlah kata yang ingin Anda dengar terkait data pasien.

Yang perlahan-lahan berubah adalah kesadaran bahwa ketahanan dalam TI bidang kesehatan bukanlah tentang menghindari perubahan — melainkan tentang membangun sistem yang cukup fleksibel untuk menyerap perubahan tanpa memerlukan keajaiban kecil setiap kali peraturan berubah atau modul EHR baru ditambahkan.

Mengapa “jika tidak rusak” bukanlah ujian yang tepat

Inilah masalahnya pada kedua skenario tersebut: sistem-sistem itu tidak rusak. Mereka berfungsi persis seperti yang dikonfigurasi. Itulah tepatnya mengapa tidak ada yang memeriksanya.

Sistem yang rusak secara definisi akan mendapat perhatian — seseorang mengeluh, sesuatu terhenti, tiket dukungan diajukan. Sistem yang berbahaya adalah yang berjalan lancar di permukaan namun secara diam-diam mulai tidak selaras dengan apa yang sebenarnya dibutuhkan organisasi. Otomatisasi alur kerja yang masih berjalan tetapi mengarahkan ke departemen yang salah. Antarmuka rumah sakit yang masih mengirimkan data tetapi menghapus bidang yang kini diandalkan oleh sistem hilir.

Audit memang tidak glamor, tetapi alternatifnya pun tidak

Solusinya tidak rumit secara konsep, meskipun membosankan dalam praktiknya: jadwalkan tinjauan berkala terhadap segala sesuatu yang berjalan tanpa pengawasan, terlepas dari seberapa baik kinerjanya di masa lalu. Tanyakan siapa yang bertanggung jawab atasnya saat ini. Tanyakan apa yang telah berubah di hulu dan hilir sejak sistem tersebut dibangun. Tanyakan apakah ada yang akan menyadari jika sistem tersebut tiba-tiba berhenti berfungsi besok.

Sebagian besar organisasi mengabaikan hal ini karena terasa seperti pemeliharaan daripada kemajuan, dan pemeliharaan jarang mendapat anggaran atau pujian. Namun, biaya akibat mengabaikannya tidak lenyap — biaya tersebut hanya menunggu, diam-diam, hingga saat seseorang di bagian piutang menyadari bahwa angka-angkanya tidak sesuai.