SIMRS untuk Developer: Gambaran Besar

Kalau Anda seorang developer yang baru pindah domain ke sistem informasi manajemen rumah sakit (SIMRS), rasanya bisa cukup mengagetkan. Ini bukan sekadar CRUD dengan tabel users dan products. Ada alur kerja klinis yang harus diikuti dengan tepat, ada kewajiban regulasi, dan ada konsekuensi nyata kalau data salah atau sistem down. Tulisan ini adalah pengantar gambaran besar arsitektur SIMRS yang biasanya saya jelaskan ke developer yang baru masuk ke domain ini, supaya tidak perlu meraba-raba sendiri dari nol.

Modul inti yang hampir selalu ada

Hampir semua SIMRS, sekecil apa pun, punya beberapa modul inti yang saling terhubung mengikuti perjalanan pasien:

Pendaftaran/registrasi — titik masuk data pasien, baik rawat jalan maupun rawat inap. Di sinilah nomor rekam medis dibuat atau dicocokkan dengan pasien lama.
Rekam medis elektronik (RME) — mencatat anamnesis, diagnosa, tindakan, dan resep. Modul ini biasanya paling sensitif karena berisi data kesehatan pribadi.
Penunjang medis — laboratorium, radiologi, dan farmasi. Masing-masing sering punya alur order-hasil sendiri yang harus tersinkron balik ke RME.
Billing dan klaim — menghitung tarif layanan dan, untuk fasilitas yang bekerja sama dengan BPJS Kesehatan, menyiapkan data klaim sesuai format yang ditentukan.
Manajemen rawat inap — bed management, mutasi ruangan, sampai proses pemulangan pasien.

Sebagai developer, cara paling cepat memahami sistem ini adalah dengan menelusuri satu alur pasien secara utuh, dari pendaftaran sampai pulang, lalu melihat tabel apa saja yang tersentuh di setiap langkah. Diagram ER akan jauh lebih masuk akal setelah Anda punya gambaran alur nyatanya.

Integrasi eksternal yang tidak bisa dihindari

Berbeda dari aplikasi bisnis pada umumnya, SIMRS di Indonesia hampir pasti perlu terhubung ke sistem eksternal seperti BPJS Kesehatan (untuk SEP dan klaim) dan platform interoperabilitas kesehatan nasional. Beberapa hal yang perlu diperhatikan soal integrasi semacam ini:

Kontrak API pihak eksternal bisa berubah tanpa banyak pemberitahuan, jadi lapisan integrasi sebaiknya diisolasi rapi, bukan dicampur langsung ke logika bisnis inti.
Selalu siapkan mekanisme retry dan logging yang jelas — begitu request keluar ke pihak ketiga, Anda kehilangan kendali atas latensi dan ketersediaannya.
Jangan asumsikan integrasi selalu sukses. Alur kerja di rumah sakit tidak boleh berhenti total hanya karena satu layanan eksternal sedang bermasalah; idealnya ada jalur manual sebagai fallback.

Karakteristik teknis yang khas domain ini

Beberapa kebiasaan teknis berikut umum ditemui di SIMRS dan sebaiknya jadi pertimbangan sejak desain awal:

Audit trail hampir selalu wajib. Siapa mengubah data apa, kapan, harus bisa ditelusuri — bukan sekadar updated_at.
Concurrency jadi isu nyata: di jam sibuk, beberapa petugas bisa mengakses data pasien atau antrian yang sama secara bersamaan, jadi race condition harus diantisipasi, bukan diabaikan.
Ketersediaan tinggi lebih krusial dibanding aplikasi bisnis biasa, karena unit gawat darurat berjalan 24/7. Downtime di jam kerja bukan sekadar gangguan, tapi bisa memengaruhi pelayanan pasien secara langsung.
Kepekaan data menuntut kontrol akses berlapis; tidak semua role perlu — atau boleh — melihat seluruh isi rekam medis.

Sebagai ilustrasi, bayangkan satu perawat menyimpan hasil vital sign pasien tepat saat dokter membuka rekam medis yang sama untuk menulis resep — desain data dan locking Anda harus menangani skenario semacam ini dengan wajar, bukan hanya berharap tidak pernah terjadi bersamaan.

Takeaway

SIMRS pada dasarnya adalah sistem informasi bisnis biasa yang berjalan di domain dengan taruhan lebih tinggi: alurnya mengikuti perjalanan pasien, integrasinya sering keluar ke pihak eksternal yang tidak Anda kendalikan, dan kesalahan kecil bisa berdampak nyata. Kalau Anda baru masuk ke domain ini, mulai dari memahami alur pasien end-to-end, lalu pelajari istilah-istilah domainnya — itu akan mempercepat semua keputusan teknis berikutnya jauh lebih baik daripada langsung membaca skema database.