Tantangan IT Kesehatan di Luar Kota Besar

Kebanyakan tutorial dan best practice yang beredar di internet diam-diam mengasumsikan satu hal: internet stabil, listrik stabil, dan ada tim IT lengkap yang siap dipanggil kapan saja. Ketika saya membangun dan menjaga sistem untuk fasilitas kesehatan di luar kota besar, asumsi itu runtuh satu per satu. Bukan berarti tidak bisa dikerjakan — tapi cara berpikirnya harus berbeda sejak dari desain arsitektur, bukan ditambal belakangan setelah sistem down.

Konektivitas yang tidak bisa diandalkan

Di kota besar, kita terbiasa mendesain sistem yang selalu online: setiap transaksi langsung memanggil API, setiap perubahan langsung tersinkron ke server pusat. Di banyak fasilitas kesehatan luar kota, koneksi internet bisa putus beberapa kali sehari, kadang berjam-jam. Kalau sistem rekam medis atau billing bergantung penuh pada koneksi real-time ke server pusat, satu kali putus internet berarti pelayanan pasien ikut terhenti — dan ini bukan skenario langka, tapi kondisi yang harus diasumsikan akan terjadi.

Pendekatan yang lebih tahan banting adalah desain offline-first: aplikasi tetap bisa mencatat data secara lokal, lalu melakukan sinkronisasi ke server pusat begitu koneksi kembali tersedia. Sebagai ilustrasi, pola sederhananya kira-kira seperti ini:

// simpan transaksi lokal dulu
$transaksi = Transaksi::create([...]);

// antrikan untuk sinkron, jangan panggil API langsung
SyncQueue::create([
    'model' => 'Transaksi',
    'payload' => $transaksi->toArray(),
    'status' => 'pending',
]);

Job terjadwal yang berjalan setiap beberapa menit lalu mencoba mengirim antrian ini ke server pusat, dan aman diulang kalau gagal. Prinsipnya: koneksi putus adalah kondisi normal yang harus ditoleransi sistem, bukan kejadian luar biasa yang menyebabkan error.

Listrik dan perangkat keras yang terbatas

Pemadaman listrik bergilir atau tegangan yang tidak stabil juga jadi variabel yang harus dipertimbangkan. Server lokal, router, dan perangkat jaringan idealnya berada di belakang UPS yang cukup untuk shutdown yang aman, bukan sekadar mencegah restart mendadak. Saya juga belajar untuk menghindari dependency yang terlalu berat pada layanan cloud tunggal untuk fungsi krusial sehari-hari — kalau internet dan listrik sama-sama tidak stabil, sistem yang bisa jalan secara lokal (misalnya lewat container yang ringan dan self-contained) jauh lebih realistis dibanding sistem yang wajib online untuk fungsi paling dasar.

Sumber daya manusia IT yang terbatas

Di kota besar, kalau ada masalah, biasanya ada tim IT yang bisa datang dalam hitungan menit. Di luar kota besar, sering kali hanya ada satu atau dua orang yang memegang semua urusan teknis, atau bahkan tidak ada sama sekali di lokasi. Konsekuensinya, sistem harus didesain supaya operasional harian bisa dijalankan oleh staf non-IT — proses restart, backup, dan pemulihan sederhana sebaiknya bisa dilakukan lewat panduan singkat, bukan harus menunggu engineer datang.

Di sisi saya sebagai penanggung jawab IT, ini juga berarti berinvestasi di tooling untuk dukungan jarak jauh: akses aman ke server dari jauh untuk diagnosis dan perbaikan tanpa harus hadir fisik, monitoring yang mengirim notifikasi sebelum masalah membesar, dan dokumentasi troubleshooting yang ditulis untuk orang yang tidak paham istilah teknis.

Memilih teknologi yang realistis untuk lingkungan terbatas

Tren memakai AI/LLM di berbagai proses kesehatan juga perlu disesuaikan dengan konteks ini. Kalau selalu bergantung pada API model besar di cloud, sistem otomatis ikut lumpuh saat internet putus. Untuk kebutuhan yang sifatnya krusial dan berulang, menjalankan model yang lebih ringan secara lokal — meski dengan trade-off kapabilitas — bisa jadi pilihan yang lebih dapat diandalkan dibanding kecepatan atau kualitas maksimal yang bergantung sepenuhnya pada koneksi eksternal.

Yang saya pelajari

Intinya, membangun sistem kesehatan di luar kota besar bukan soal menggunakan teknologi yang lebih sederhana, tapi soal mendesain untuk kegagalan sebagai hal yang wajar: internet putus, listrik naik-turun, dan tenaga IT terbatas. Sistem yang tangguh di lingkungan seperti ini justru sering kali lebih tangguh juga ketika dijalankan di kota besar — karena sejak awal sudah dirancang untuk tidak rapuh.