Pelajaran dari Lima Tahun di Sistem Klinik dan Rumah Sakit

Lima tahun terakhir saya habiskan membangun dan merawat sistem informasi di lingkungan klinik dan rumah sakit — mulai dari modul rekam medis, integrasi dengan BPJS, sampai belakangan mengarahkan tim IT secara penuh. Kalau ada satu hal yang paling banyak mengubah cara saya menulis kode, itu bukan framework atau bahasa pemrograman tertentu, melainkan cara saya memandang "apa artinya software yang benar". Di domain kesehatan, bug bukan sekadar tiket yang harus ditutup sebelum sprint berakhir. Ada pasien, ada tenaga medis, dan ada alur kerja nyata di baliknya. Refleksi ini saya tulis bukan sebagai cerita insiden tertentu, tapi sebagai kumpulan pelajaran umum yang saya rasa relevan untuk siapa pun yang bekerja di sistem dengan taruhan tinggi.

Data yang salah lebih berbahaya daripada data yang hilang

Di banyak domain, kalau sebuah field kosong atau proses gagal, sistem bisa menampilkan error dan pengguna tahu ada yang salah. Di sistem klinik, yang jauh lebih berbahaya adalah data yang terlihat benar padahal sebenarnya salah — misalnya hasil mapping diagnosis yang keliru, atau satuan dosis yang tertukar karena kesalahan konversi. Ini mengubah cara saya mendesain validasi: saya jadi lebih suka sistem yang gagal secara eksplisit (menolak menyimpan, menampilkan peringatan) daripada sistem yang mencoba "menebak" nilai default demi kenyamanan pengguna. Sebagai ilustrasi, alih-alih membiarkan field kosong otomatis terisi nilai default paling umum, saya lebih memilih memaksa input eksplisit atau menandai baris tersebut untuk ditinjau manual. Prinsip ini sekarang saya bawa ke domain lain juga: lebih baik proses berhenti dan berteriak, daripada diam-diam menghasilkan output yang salah tapi meyakinkan.

Alur kerja manusia harus dipahami sebelum alur kerja sistem dirancang

Perawat, dokter, dan petugas rekam medis punya urutan kerja yang sudah terbentuk lama sebelum aplikasi apa pun ditulis. Kesalahan yang paling sering saya lihat — dan pernah saya lakukan sendiri di awal karier — adalah mendesain sistem berdasarkan asumsi alur ideal di atas kertas, bukan alur nyata di lapangan yang sering terpotong, tertunda, atau dikerjakan di luar urutan karena kondisi darurat. Praktik yang menurut saya cukup efektif: sebelum menulis satu baris kode untuk fitur baru, duduk sebentar dengan pengguna sebenarnya dan minta mereka menunjukkan langkah-langkah yang biasa mereka lakukan, termasuk "jalan pintas" yang tidak tertulis di SOP. Fitur yang dibangun tanpa langkah ini biasanya butuh revisi besar begitu dipakai di kondisi nyata.

Keandalan infrastruktur bukan sekadar checklist DevOps

Ketika sebuah aplikasi e-commerce down beberapa menit, itu kerugian bisnis. Ketika sistem antrean atau resep di fasilitas kesehatan down, dampaknya langsung terasa di ruang tunggu dan ruang periksa. Ini membuat saya jauh lebih serius soal hal-hal yang sebelumnya terasa "nice to have": backup yang benar-benar teruji lewat proses restore, monitoring yang memberi peringatan sebelum masalah membesar, dan desain arsitektur yang mengasumsikan komponen bisa gagal kapan saja — jaringan terputus, koneksi database timeout, layanan eksternal seperti BPJS lambat merespons. Dengan Docker dan orkestrasi container, saya jadi terbiasa memisahkan setiap layanan agar kegagalan satu komponen tidak menjatuhkan semuanya, dan selalu punya rencana rollback yang sudah dicoba, bukan hanya didokumentasikan.

Takeaway

Bekerja lama di domain kesehatan mengajarkan saya bahwa "software yang benar" itu jauh lebih luas daripada "kode yang lolos test". Ia mencakup desain yang jujur soal ketidakpastian data, pemahaman mendalam terhadap alur kerja manusia, dan infrastruktur yang dibangun dengan asumsi bahwa sesuatu akan gagal. Pelajaran-pelajaran ini sekarang menjadi kerangka berpikir saya di hampir semua proyek, bukan hanya yang berhubungan dengan kesehatan.