Tenaga Kesehatan Kelelahan Menangani Kekacauan Penjadwalan Palantir: Algoritma yang Membebani, Bukan Membantu

Janji Efisiensi yang Menghasilkan Kekacauan

Empat bulan terakhir, Amber Retzloff, perawat perawatan intensif di Florida, mengajukan permintaan untuk 50 shift spesifik berdurasi 12 jam. Lebih dari setengahnya, kata dia, perangkat lunak penjadwalan berbasis Palantir yang digunakan rumah sakitnya justru menempatkannya di shift lain—sering kali tanpa pemberitahuan sebelumnya. Akibatnya, dia harus mengejar kebijakan manual, menukar jadwal dengan rekan kerja, dan mengorbankan waktu istirahat hanya untuk memastikan unit perawatan intensif tetap terisi.

Kisah Retzloff bukan kasus terisolasi. Laporan Tired yang diterbitkan 2 Oktober 2026 mengungkap bahwa sejumlah rumah sakit besar dan jaringan radiologi di AS yang mengadopsi platform Foundry Palantir untuk mengotomatisasi penjadwalan staf justru menghadapi gelembung kesalahan: shift ganda, kosongnya posisi kritis, dan staf yang ditugaskan di luar keahlian atau preferensi mereka.

Bagaimana Algoritma Penjadwalan Palantir Bekerja—dan Mengapa Gagal

Platform Foundry Palantir dipasarkan sebagai “sistem operasi” data enterprise yang mengintegrasikan sumber data terpecah—kehadiran, kredensial, volume pasien, kontrak sindikat—ke dalam satu lapisan semantik, lalu menjalankan model optimisasi untuk menghasilkan jadwal mingguan. Secara teori, pendekatan ini seharusnya mengurangi beban administratif manajer keperawatan dan meminimalkan biaya lembur.

Namun, wawancara dengan dua puluh lebih perawat, teknisi radiologi, dan manajer unit di tiga sistem kesehatan besar menunjukkan pola kegagalan berulang:

• Keterbatasan data masukan: Sistem sering tidak memiliki visibilitas real-time atas cuti sakit mendadak, pembatalan prosedur, atau perubahan akut volume pasien di darurat.
• Ketidakmampuan menangani pengecualian klinis: Seorang perawat ICU dengan sertifikasi CRRT (Continuous Renal Replacement Therapy) bisa dijadwalkan ke unit Mess-bedah umum hanya karena algoritma mengoptimalkan “jumlah kepala” tanpa mempertimbangkan kecocokan keterampilan.
• Umpan balik tertutup: Staf tidak memiliki saluran langsung untuk menolak atau mengoreksi penugasan yang salah sebelum jadwal dipublikasikan.

“Kami dijualkan visi ‘penjadwalan cerdas’, tetapi yang kami dapatkan adalah spreadsheet yang berpura-pura pintar,” ujar seorang manajer keperawatan senior di jaringan rumah sakit Midwest yang meminta anonimitas. “Setiap hari Senin tim kami menghabiskan tiga hingga empat jam hanya untuk memperbaiki kesalahan sistem sebelum shift dimulai.”

Dampak Nyata: Burnout, Keselamatan Pasien, dan Rotasi Staf

Studi internal salah satu sistem kesehatan yang diduga melibatkan Palantir—tidak dipublikasikan namun dibagikan ke Tired—menunjukkan peningkatan 23% laporan kelelahan berlebih (excessive fatigue reports) di antara perawat ICU dalam enam bulan pasca-implementasi. Angka turnover perawat tetap naik 1,8 poin persen dibanding periode sebelumnya.

Lebih mengkhawatirkan, tiga insiden near-miss keselamatan pasien tercatat terkait penugasan perawat yang tidak memiliki kompentensi spesifik untuk pasien ventilator atau infus vasopressor. “Algoritma tidak tahu bedanya antara perawat yang baru lulus orientasi dan yang sudah sepuluh tahun menangani ECMO,” kata Retzloff. “Kami yang harus menutupi celahnya.”

Pola Luas: Otomatisasi Tanpa Konteks Klinis

Kasus Palantir mencerminkan tren lebih luas di teknologi kesehatan: vendor platform data enterprise—Palantir, Microsoft (Cloud for Healthcare), Google (Care Studio), Amazon (HealthLake)—menjual modul penjadwalan atau manajemen operasional sebagai “solusi AI” tanpa melibatkan pengguna akhir (para perawat, teknisi, dokter) dalam desain workflow.

Penelitian Journal of the American Medical Informatics Association (2024) meninjau 17 implementasi penjadwalan berbasis AI di rumah sakit AS dan menemukan bahwa hanya 4 di antaranya yang melibatkan staf klinis sebagai co-designer. Hasilnya: sistem yang cerdas secara matematis tetapi bodoh secara kontekstual.

“Masalahnya bukan matematika optimisasi,” jelas Dr. Maya Patel, informatis klinis di UC San Diego Health. “Masalahnya adalah fungsi objektif yang sempit—meminimalkan biaya tenaga—tanpa variabel kelelahan kognitif, kontinuitas perawatan, atau kepuasan staf.”

Apa yang Bisa Dilakukan Rumah Sakit Sekarang

Bagi pemimpin TI dan klinis yang mengevaluasi atau sudah mengimplementasikan alat serupa, beberapa langkah konkret dapat mengurangi risiko:

1. Tetapkan “manusia dalam lingkaran” (human-in-the-loop) wajib: Setiap jadwal yang dihasilkan algoritma harus divalidasi oleh manajer unit sebelum dipublikasikan. Tidak ada pengecualian.
2. Bangun loop umpan balik real-time: Integrasikan tombol “tolak/komentar” di aplikasi mobile staf yang masuk ke sistem penjadwalan dalam hitungan menit, bukan hari.
3. Perluas fungsi objektif: Tambahkan bobot untuk kontinuitas perawatan (pasien yang sama, perawat yang sama), kecocokan keterampilan, dan preferensi staf—bukan hanya biaya dan cakupan.
4. Uji coba bertahap dengan metrik keseimbangan: Lacak bukan hanya fill rate shift, tapi juga overtime hours, float pool usage, skor kelelahan (mis. skala Maslach), dan insiden keselamatan.
5. Kontrak keluar (exit clause): Pastikan kontrak vendor memungkinkan penggulungan (roll-back) ke sistem lama dalam 30 hari tanpa denda besar jika metrik keseimbangan melenceng.

Pelajaran untuk Ekosistem AI Kesehatan Indonesia

Di Indonesia, rumah sakit rujukan besar seperti RSUPN Cipto Mangunkusumo, RSUP Dr. Sardjito, atau jaringan Siloam mulai mengeksplorasi analitik operasional dan penjadwalan otomatis. Pelajaran dari kasus Palantir jelas: jangan beli “kotak hitam” optimisasi tanpa melibatkan perawat dan dokter sebagai pemangku kepentingan utama sejak hari nol.

Kementerian Kesehatan (Kemenkes) dan Badan Pengkajian dan Penerapan Teknologi (BPPT) sebaiknya menetapkan standar clinical usability untuk perangkat lunak penunjang keputusan klinis dan operasional—termasuk penjadwalan—seperti yang sudah ada untuk perangkat Mess fisik. Sertifikasi “layak klinis” harus mencakup uji coba pengguna nyata, bukan hanya validasi akurasi model.

Kesimpulan: Teknologi Harus Melayani Manusia, Bukan Sebaliknya

Palantir dan sejenisnya menawarkan daya tarik data terintegrasi dan optimisasi skala besar. Namun tanpa desain yang menghormati realitas klinis—kelelahan, kecocokan keterampilan, kontinuitas perawatan—algoritma justru menciptakan beban kerja baru bagi mereka yang seharusnya dibantu.

Amber Retzloff merangkumnya dengan sederhana: “Saya tidak butuh AI yang memberitahu saya kapan bekerja. Saya butuh sistem yang mendengarkan saat saya bilang ‘saya tidak bisa shift malam ini karena saya sudah 36 jam jagaan minggu ini’. Hingga sistem itu ada, kami yang membersihkan kekacauannya.”

Bagi pemutus keputusan teknologi di rumah sakit Indonesia dan global, pesannya jernih: validasi dengan pengguna akhir, ukur dampak manusiawi, dan siap menggulirkan mundur jika teknologi justru menyakiti orang yang paling dekat dengan pasien.