Cloud Server untuk SIMRS: Cara Memilih Provider yang Tepat

SIMRS yang berjalan di server on-premise berumur tujuh tahun, dengan disk HDD dan UPS yang sudah dua kali gagal, sering jadi titik awal diskusi migrasi ke cloud. Masalahnya, banyak rumah sakit pindah ke cloud hanya karena membandingkan harga per bulan, lalu kecewa ketika modul farmasi dan bridging BPJS justru terasa lebih lambat saat jam sibuk. Di RS dengan 200 tempat tidur dan 150 user aktif, puncak beban terjadi antara pukul 07.30 dan 10.00: pendaftaran, penulisan resep, order penunjang, dan sinkronisasi klaim berjalan bersamaan. Provider cloud yang tepat untuk SIMRS bukan yang termurah, tetapi yang profil storage, latensi jaringan, dan SLA-nya cocok dengan pola beban tersebut. Artikel ini membahas cara memilihnya secara terukur, mulai dari menghitung sizing sampai menguji failover sebelum kontrak ditandatangani.

Mulai dari Profil Beban Kerja SIMRS, Bukan Harga Bulanan

Provider biasanya dipilih lewat perbandingan jumlah vCPU dan RAM di halaman pricing. Cara itu keliru untuk SIMRS karena bottleneck jarang berada di CPU, melainkan di IOPS database dan latensi query rekam medis. Pada instalasi SIMRS berbasis PHP 8.2 dan MySQL 8.0 yang kami kelola, satu halaman rekam medis pasien dengan riwayat 20 kunjungan menghasilkan 30–60 query. Laporan kunjungan harian yang diakses 50 user sekaligus bisa memicu 2.000–3.000 query per menit, dan di sinilah instance 4 vCPU/8 GB dengan disk burst mulai tumbang.

Langkah pertama adalah mengambil baseline dari server existing selama minimal tujuh hari, khususnya puncak Senin dan Selasa. Catat slow query di atas 1,5 detik memakai pt-query-digest atau performance_schema, ukur puncak IOPS dengan iostat -x 5, dan hitung laju pertumbuhan data. Database SIMRS berumur lima tahun umumnya berada di 60–180 GB, ditambah object storage 300–800 GB untuk hasil radiologi, dokumen scan, dan lampiran klaim.

Setelah angka baseline ada, baru pilih tipe instance. Hindari volume dengan burst IOPS untuk partisi data MySQL; pilih yang menjamin baseline. AWS gp3 memungkinkan 3.000–16.000 IOPS dikonfigurasi terpisah dari ukuran volume, sementara provider dengan NVMe lokal seperti UpCloud atau DigitalOcean sering memberi IOPS per dolar lebih tinggi untuk beban read-heavy. Untuk session, master data (ICD-10, tarif, daftar dokter), dan katalog obat, Redis 7.2 memotong waktu render 30–45% karena query berulang tidak lagi menyentuh disk.

Jangan lupa komponen pendukung bridging. Worker antrean untuk pengiriman klaim BPJS dan SatuSehat (FHIR R4), cron pelaporan, serta environment staging biasanya butuh tambahan 2 vCPU/4 GB agar proses antrean tidak berebut CPU dengan aplikasi utama saat tutup buku akhir bulan.

Due Diligence Provider: Jaringan, Kepatuhan, dan SLA

Latensi jaringan sering diabaikan padahal dampaknya langsung terasa. Untuk rumah sakit di Yogyakarta, DIY, dan Magelang, memilih region Jakarta memberi latensi 8–20 ms lewat koneksi fiber, sedangkan region Singapura 40–60 ms. Selisih itu berarti saat klaim massal: request FHIR ke SatuSehat dan pengiriman berkas ke BPJS punya timeout dan mekanisme retry, sehingga latensi tinggi membuat antrean menumpuk dan sebagian request gagal di tengah jalan.

Kepatuhan bukan formalitas. Permenkes 24/2022 mewajibkan penyelenggara rekam medis elektronik menjaga kerahasiaan dan menyediakan audit trail, sementara UU 27/2022 tentang Pelindungan Data Pribadi mengatur pemrosesan data pasien. Praktisnya, pastikan data disimpan di wilayah Indonesia, terenkripsi at-rest dengan AES-256, terenkripsi in-transit minimal TLS 1.2, kunci dikelola lewat KMS, dan log akses bisa diekspor untuk audit. Minta bukti ISO 27001 atau SOC 2 tipe II, bukan sekadar klaim di halaman marketing.

SLA harus dibaca sampai lampiran. Target minimum 99,9% setara sekitar 43 menit downtime per bulan. Tanyakan definisi downtime, apakah maintenance terjadwal dikecualikan, kompensasi yang diberikan, ketersediaan status page, dan apakah post-mortem dibagikan setelah insiden. Untuk SIMRS, tetapkan RTO maksimal 4 jam dan RPO maksimal 15 menit, lalu verifikasi bahwa backup harian benar-benar diuji restore setiap kuartal.

Terakhir, support. Provider yang layak punya engineer on-call 24/7 dengan jalur eskalasi ke level teknis, bukan hanya chatbot dan sistem tiket. Untuk kebutuhan konsultasi IT dan pengembangan aplikasi SIMRS, SIM Klinik, ERP, POS, maupun website di Yogyakarta dan Magelang, pilih partner yang bersedia menandatangani dokumen arsitektur dan runbook operasional, bukan hanya menyewakan mesin.

Uji Latensi, Throughput, dan Failover Sebelum Kontrak

Jangan percaya benchmark sintetis di halaman provider. Minta trial 7–14 hari, deploy stack minimum (web app, MySQL, Redis) dengan salinan data anonim, lalu ukur dari jaringan rumah sakit, bukan dari kantor marketing.

for host in simrs.rsud.example.id api.bpjs-kesehatan.go.id; do
  echo "== $host =="
  ping -c 20 "$host" | tail -1
  for i in 1 2 3 4 5; do
    curl -o /dev/null -s -w "TTFB %{time_starttransfer}s\n" "https://$host/"
  done
done

Interpretasi hasilnya: TTFB endpoint lokal sebaiknya di bawah 300 ms, jitter di bawah 5 ms, dan packet loss 0%. Catat juga waktu failover managed database, umumnya 60–120 detik untuk promosi replica, lalu pastikan aplikasi punya connection retry (pool timeout 5 detik, tiga kali percobaan dengan backoff) agar user tidak melihat halaman error.

Uji throughput upload untuk restore dan backup. Seratus GB lewat uplink 100 Mbps membutuhkan sekitar 2,2 jam; jika provider tidak menyediakan seeding via disk fisik, RTO 4 jam tidak realistis. Simpan semua angka ini dalam dokumen evaluasi agar keputusan bisa dipertanggungjawabkan ke manajemen dan tim akreditasi.

Best Practices

1. Ambil baseline IOPS, slow query, dan pertumbuhan data tujuh hari sebelum memilih instance; jangan mulai dari daftar harga.
2. Pilih volume dengan baseline IOPS terjamin untuk partisi MySQL, dan pisahkan object storage untuk radiologi serta dokumen scan.
3. Pilih region Indonesia (Jakarta) untuk menekan latensi bridging BPJS dan SatuSehat; ukur traceroute dari jaringan RS, bukan dari kantor.
4. Verifikasi SLA tertulis: 99,9%, RTO ≤ 4 jam, RPO ≤ 15 menit, kompensasi jelas, dan backup diuji restore setiap kuartal.
5. Minta trial 7–14 hari dan uji failover database serta waktu restore sebelum menandatangani kontrak tahunan.

FAQ

Berapa spesifikasi minimum cloud server untuk SIMRS 150 user aktif?

Mulai dari 8 vCPU/16 GB untuk aplikasi, database terpisah 4 vCPU/16 GB dengan baseline 3.000 IOPS, dan Redis 2 GB. Sesuaikan setelah melihat baseline slow query dan puncak IOPS dari server lama.

Apakah data rekam medis boleh disimpan di cloud luar negeri?

Secara regulasi Indonesia, penyelenggara RME wajib menjaga kerahasiaan dan audit trail, dan UU PDP mengatur transfer data pribadi ke luar wilayah. Praktik aman dan paling mudah diaudit adalah menyimpan data pasien di region Indonesia.

Bagaimana menilai provider yang hanya memberi SLA 99,5%?

99,5% berarti sekitar 3,6 jam downtime per bulan, terlalu besar untuk SIMRS yang dipakai saat pendaftaran dan farmasi buka. Ajukan negosiasi ke 99,9% atau minta arsitektur multi-zone dengan failover otomatis.

Apakah perlu multi-cloud untuk SIMRS?

Untuk sebagian besar RS di DIY dan Magelang, tidak. Yang lebih penting adalah multi-zone dalam satu provider, backup lintas region, dan runbook darurat yang diuji, karena kompleksitas multi-cloud justru menambah biaya operasional.

Memilih cloud server untuk SIMRS adalah keputusan arsitektur, bukan keputusan belanja. Ukur beban kerja nyata, verifikasi latensi dari jaringan rumah sakit, baca SLA sampai lampiran, dan uji failover sebelum tanda tangan. Jika Anda sedang menyiapkan migrasi SIMRS, SIM Klinik, ERP, atau POS ke cloud, tim kami membantu audit sizing, desain arsitektur, dan pendampingan implementasi untuk rumah sakit dan klinik di Yogyakarta, DIY, dan Magelang. Mulai dari sesi konsultasi 60 menit dengan data baseline Anda.

Artikel ini bagian dari edukasi Nugroho Setiawan, konsultan IT Jogja. Solusi terkait: SIMRS Integrator Bridging BPJS & SatuSehat. Butuh konsultasi gratis?