Proyek sistem digital ruang pacu dan amprah obat rumah sakit ini dimulai dari sebuah keluhan. Keluhan yang disampaikan dengan nada lelah, dari seorang koordinator perawat yang sudah bertahun-tahun menjalankan proses yang sama: menulis, mengantar formulir, menunggu konfirmasi, menulis lagi. Tidak semua proyek pengembangan software dimulai dari sebuah brief yang rapi.
“Kami tidak kekurangan tenaga. Kami kekurangan waktu dan sebagian besar waktu itu habis untuk hal-hal yang seharusnya sudah otomatis.”
Dari situ, kami mulai.
Konteks: Dua Proses yang Masih Berjalan Manual
Sebelum membangun apapun, Alifbata Digital perlu memahami dua sistem yang akan kami sentuh, bukan dari perspektif teknis, tapi dari perspektif orang yang menjalankannya setiap hari.
Ruang Pacu
Ruang pacu (recovery room atau RR) adalah unit di mana pasien dipantau setelah prosedur anestesi sebelum dipindahkan ke ruang rawat. Kondisi pasien berubah cepat. Keputusan harus dibuat dalam hitungan menit.
Namun pencatatan kondisi pasien, tanda vital, tindakan yang dilakukan, catatan anestesi, evaluasi pemindahan. Semuanya masih dilakukan secara manual di formulir kertas. Setiap shift, perawat menyalin ulang data ke dalam buku rekap. Setiap minggu, rekap itu diarsipkan. Dan setiap kali ada audit atau evaluasi, seseorang harus membuka-buka tumpukan arsip fisik itu dengan tangan.
Amprah Obat
Proses pengadaan obat dari depo farmasi ke unit perawatan, yang disebut “amprah obat”, melibatkan formulir permintaan tertulis, antrian verifikasi apoteker, hingga distribusi fisik. Dalam kondisi normal, proses ini membutuhkan waktu yang cukup lama. Dalam kondisi darurat, setiap menit yang tertunda adalah risiko.
Masalah lain: tidak ada visibilitas real-time. Perawat tidak tahu apakah permintaan mereka sudah diproses. Apoteker tidak punya antrean yang terstruktur. Manajemen tidak punya data agregat untuk evaluasi konsumsi obat per unit.
Tantangan Teknis, Kenapa Ini Bukan Proyek Biasa
Membangun aplikasi untuk lingkungan medis bukan sekadar soal CRUD (Create, Read, Update, Delete). Ada lapisan kompleksitas yang tidak akan Anda temukan di proyek e-commerce atau manajemen konten biasa.
Pertama, toleransi terhadap kesalahan sangat rendah. Data yang salah bukan hanya masalah UX, ia bisa berdampak langsung pada keselamatan pasien. Setiap field, setiap validasi, setiap alur konfirmasi harus dirancang dengan asumsi bahwa pengguna sedang dalam kondisi sibuk dan tertekan.
Kedua, pengguna tidak bisa dilatih lama. Perawat, apoteker, dan dokter punya waktu sangat terbatas untuk mempelajari sistem baru. Antarmuka harus intuitif secara radikal, kalau seseorang perlu berpikir lebih dari dua detik untuk menemukan tombol yang tepat, desain kita gagal.
Ketiga, data harus bisa diaudit. Regulasi layanan kesehatan mensyaratkan jejak audit yang lengkap. Siapa yang mengubah apa, kapan, dan dari data apa, semuanya harus tersimpan.
Keempat, sistem tidak boleh mati. Downtime di lingkungan rumah sakit bukan sekadar gangguan operasional. Ini keputusan desain arsitektur yang harus dipikirkan sejak awal.
Keputusan Teknologi: Mengapa Memilih PHP
Kami membangun kedua aplikasi ini menggunakan PHP. Di era di mana semua orang berlomba-lomba menggunakan framework JavaScript terbaru atau arsitektur microservice yang kompleks, memilih PHP untuk proyek ini adalah keputusan yang sangat disengaja, bukan karena keterbatasan, tapi karena pertimbangan matang.
PHP adalah bahasa yang “membosankan” dengan cara terbaik
Dalam rekayasa perangkat lunak, “membosankan” adalah pujian. Teknologi yang membosankan adalah teknologi yang sudah terbukti, didokumentasikan dengan baik, dan tidak akan memberi Anda kejutan tidak menyenangkan di tengah proses deployment.
PHP telah berjalan di lebih dari 77% server web di seluruh dunia. Ekosistemnya matang. Library-nya ada untuk hampir semua kebutuhan. Dan yang paling penting untuk konteks ini, developer PHP lebih mudah ditemukan, sehingga proyek ini tidak akan bottleneck pada ketersediaan talent spesifik.
Kurva belajar yang rendah untuk maintenance jangka panjang
Salah satu risiko terbesar dalam proyek untuk institusi seperti rumah sakit adalah siapa yang akan merawat sistem ini 3 tahun dari sekarang? Kalau kami membangun dengan framework yang sangat spesifik atau arsitektur yang rumit, rumah sakit menjadi tergantung penuh pada vendor.
Dengan PHP yang terstruktur dengan baik, tim internal rumah sakit atau developer lokal mana pun bisa masuk, memahami kode, dan melakukan modifikasi yang diperlukan tanpa harus mempelajari ekosistem yang eksotis.
Performa yang lebih dari cukup
Untuk use case seperti ini puluhan hingga ratusan concurrent user dalam satu institusi, PHP modern dengan caching yang tepat mampu menangani beban dengan sangat baik. Kami tidak sedang membangun platform dengan jutaan pengguna. Kami membangun alat kerja untuk satu rumah sakit, dengan pengguna yang jumlahnya terdefinisi dan terprediksi.
Arsitektur dan Pendekatan Pengembangan
Struktur Aplikasi
Kami mengadopsi pendekatan MVC (Model-View-Controller) yang bersih tanpa bergantung pada framework berat. Ini memberi kami fleksibilitas untuk menyesuaikan arsitektur dengan kebutuhan spesifik domain medis, sekaligus mempertahankan keterbacaan kode yang tinggi.
Untuk database, kami menggunakan MySQL dengan skema yang dirancang untuk auditability, setiap tabel utama memiliki kolom created_by, updated_by, created_at, updated_at, dan tabel log terpisah yang menyimpan riwayat perubahan setiap record.
Autentikasi menggunakan sistem role-based yang ketat: perawat, apoteker, dokter, supervisor, dan administrator memiliki hak akses berbeda yang diterapkan di level controller, bukan hanya di level UI.
Aplikasi 1: Sistem Ruang Pacu
Modul utama yang kami bangun untuk ruang pacu meliputi:
Registrasi pasien masuk — Pasien yang masuk ke ruang pacu diregistrasi dengan data dari sistem rawat inap (integrasi via API sederhana), sehingga perawat tidak perlu menginput ulang data dasar.
Pemantauan tanda vital — Form input tanda vital yang dioptimalkan untuk kecepatan: field yang paling sering diisi ada di posisi paling mudah dijangkau, validasi range normal ditampilkan langsung sebagai referensi, dan data tersimpan dengan timestamp otomatis.
Catatan tindakan — Setiap tindakan yang dilakukan (pemberian obat, prosedur, evaluasi) dicatat dengan struktur terstandar yang memudahkan evaluasi klinis dan audit.
Evaluasi pemindahan — Sistem skoring Aldrete (atau modifikasinya) terintegrasi langsung, sehingga keputusan pemindahan pasien dari ruang pacu terdokumentasi secara klinis, bukan hanya administratif.
Laporan shift — Rekap otomatis per shift yang bisa dicetak atau diekspor, menggantikan proses penulisan manual yang sebelumnya memakan waktu 15-20 menit di akhir setiap shift.
Aplikasi 2: Sistem Amprah Obat
Alur yang kami digitalisasi:
Pembuatan permintaan obat — Perawat membuat permintaan langsung dari browser, memilih obat dari daftar formularium yang sudah terstandardisasi. Sistem secara otomatis memeriksa apakah permintaan masuk dalam batas dosis wajar dan menampilkan peringatan jika ada potensi interaksi sederhana.
Antrean verifikasi apoteker — Semua permintaan masuk ke dashboard apoteker secara real-time. Apoteker bisa memverifikasi, memodifikasi (misalnya substitusi generik), atau menolak dengan catatan alasan — semua terdokumentasi.
Notifikasi status — Perawat pemohon mendapat update status permintaan mereka: diterima, diproses, siap diambil, atau ditolak dengan alasan.
Manajemen stok sederhana — Bukan sistem farmasi lengkap, tapi cukup untuk memberikan visibilitas stok pada level depo unit sehingga permintaan yang tidak bisa dipenuhi terdeteksi lebih awal.
Rekap konsumsi obat — Laporan konsumsi per unit, per periode, per jenis obat — data yang sebelumnya harus dikompilasi manual kini tersedia dalam hitungan detik.
Pendekatan UI/UX: Merancang untuk Kondisi Tekanan Tinggi
Ini bagian yang paling sering diremehkan dalam proyek untuk institusi medis, dan juga bagian yang menurut kami paling penting.
Perawat yang mengisi data tanda vital mungkin baru saja menangani kondisi darurat. Apoteker yang memverifikasi permintaan mungkin menangani belasan permintaan secara bersamaan. Dokter yang meninjaui catatan mungkin sedang berdiri, membaca dari tablet, sambil berbicara dengan rekan.
Prinsip desain yang kami terapkan:
Teks besar, kontras tinggi. Tidak ada teks kecil di area input kritis. Semua label jelas dan kontrastif, bisa dibaca di bawah pencahayaan ruang klinis yang bervariasi.
Konfirmasi untuk aksi destruktif, kemudahan untuk aksi rutin. Menghapus data membutuhkan konfirmasi dua langkah. Tapi mengisi data rutin harus bisa dilakukan dengan klik sesedikit mungkin.
Pesan error yang memandu, bukan menghukum. Kalau ada input yang salah, sistem tidak hanya menampilkan “Input tidak valid.” Ia menjelaskan apa yang salah dan apa yang diharapkan.
Mode offline-first sebagai failsafe. Untuk fungsi-fungsi kritis, kami mengimplementasikan penyimpanan lokal sementara yang akan tersinkronisasi ketika koneksi kembali — memastikan data tidak hilang jika jaringan intranet rumah sakit sesekali tidak stabil.
Proses Implementasi: Mengubah Sistem yang Sedang Berjalan
Salah satu keputusan paling penting bukan soal teknologi — tapi soal bagaimana cara berpindah dari sistem lama ke sistem baru tanpa mengganggu operasional.
Kami menggunakan pendekatan implementasi paralel selama dua minggu: sistem lama tetap berjalan, sistem baru digunakan bersamaan. Ini memberi petugas waktu untuk terbiasa, memberi kami waktu untuk menemukan bug yang tidak terdeteksi di lingkungan testing, dan yang paling penting — memberi semua pihak kepercayaan bahwa sistem baru bisa diandalkan sebelum sistem lama benar-benar ditinggalkan.
Pelatihan dilakukan per kelompok kecil (5-8 orang), langsung di unit masing-masing, dengan skenario yang diambil dari kasus nyata yang pernah mereka hadapi. Bukan presentasi PowerPoint tentang fitur — tapi simulasi situasi kerja aktual.
Feedback dari pelatihan ini juga langsung kami jadikan input untuk revisi UI sebelum go-live penuh.
Hasil: Apa yang Berubah
Setelah sistem berjalan penuh, perubahan yang paling terasa bukan yang kami perkirakan sebelumnya.
Kami mengira dampak terbesar adalah kecepatan. Dan memang, waktu proses amprah obat turun signifikan. Rekap shift yang dulu 15-20 menit kini selesai otomatis.
Tapi dampak yang paling sering disebut oleh staf adalah sesuatu yang lebih intangible: berkurangnya kecemasan administratif.
Sebelumnya, ada selalu kekhawatiran di benak petugas: apakah formulir saya sudah sampai? Apakah data saya sudah dicatat dengan benar? Apakah rekap shift saya lengkap? Dengan sistem digital, semua itu terkonfirmasi secara instan. Data masuk, status tercatat, dan sistem memberi tanda bahwa semuanya sudah tersimpan.
Itu bukan fitur yang ada di spesifikasi teknis manapun. Tapi itulah salah satu nilai terbesar yang dibawa oleh digitalisasi yang dilakukan dengan benar.
Pelajaran yang Kami Bawa
Setelah proyek ini selesai, ada beberapa hal yang akan selalu kami bawa ke proyek serupa di masa depan:
Habiskan lebih banyak waktu di lapangan sebelum menulis satu baris kode. Kami menghabiskan hampir sepertiga total waktu proyek hanya untuk observasi dan wawancara. Keputusan itu terbayar berlipat ganda.
Kesederhanaan adalah fitur, bukan kekurangan. Ada banyak fitur yang kami putuskan untuk tidak dibangun — bukan karena tidak bisa, tapi karena menambahnya akan menambah kompleksitas tanpa nilai proporsional. Sistem yang lebih ramping lebih mudah dipelajari, lebih mudah dirawat, dan lebih jarang rusak.
Teknologi yang tepat bukan yang terbaru, tapi yang paling sesuai konteksnya. PHP bukan pilihan yang glamor. Tapi ia adalah pilihan yang tepat untuk proyek ini, dengan konteks ini, untuk institusi ini.
Implementasi adalah setengah dari pekerjaan. Software yang bagus yang diimplementasikan dengan buruk akan gagal. Investasi waktu dan perhatian pada proses transisi sama pentingnya dengan kualitas kode itu sendiri.
Semacam Penutup
Digitalisasi di lingkungan layanan kesehatan bukan tentang mengadopsi teknologi terkini. Ia tentang memindahkan hambatan yang selama ini menghalangi tenaga medis dari fokus pada hal yang paling penting: merawat pasien.
Dua aplikasi yang kami bangun ini tidak mengubah cara dokter mendiagnosis atau cara perawat merawat. Yang berubah adalah lapisan administratif di antara mereka dan pekerjaan klinis mereka, lapisan yang selama ini mengambil waktu, energi, dan konsentrasi yang seharusnya bisa digunakan untuk hal yang lebih bermakna.
Kalau Anda sedang mempertimbangkan proyek serupa di institusi Anda, kami senang untuk berbagi pengalaman lebih lanjut — tantangan teknis, dinamika organisasi, atau strategi implementasi yang efektif.
Jika rumah sakit atau institusi kesehatan Anda sedang menghadapi tantangan serupa — proses manual yang memperlambat pelayanan, data yang tersebar, atau sistem lama yang sudah tidak memadai — Alifbata Digital siap membantu merancang solusinya. Kami mengerjakan proyek digitalisasi layanan kesehatan secara end-to-end, mulai dari analisis kebutuhan hingga implementasi dan pelatihan; selengkapnya bisa Anda lihat di halaman Healthcare Digital Solution dan Web Development kami. Kalau Anda ingin tahu investasi yang dibutuhkan, kami menyediakan informasi transparan di halaman Harga — karena kami percaya keputusan yang baik dimulai dari informasi yang jelas.
Artikel ini ditulis berdasarkan pengalaman langsung pengembangan dua web aplikasi untuk digitalisasi ruang pacu dan sistem amprah obat di lingkungan rumah sakit. Detail teknis tertentu disederhanakan untuk keterbacaan umum.
