Cloud Servers for SIMRS (Hospital Information Systems): How to Choose the Right Provider

Choosing a cloud server for SIMRS is not just comparing price per vCPU. When one hour of downtime occurs during peak hours, patient queues can pile up to 200 people, BPJS VClaim bridging fails, and claims are delayed. On the other hand, SatuSehat integration via FHIR requires a stable connection with low latency so that Encounter and Observation synchronization does not time out midway. Many hospital IT managers get trapped choosing the cheapest provider, then regret it when IOPS drops during registration hours or the support team cannot be contacted at night. This article summarizes concrete criteria—from regulation, technical specifications, to latency testing—that must be checked before moving SIMRS to the cloud, based on deployment experience in type C, D hospitals and multi-branch clinics.

Regulation and Compliance: The Frequently Overlooked Key

Since PMK No. 24 of 2022 on Electronic Medical Records and Law No. 27 of 2022 on Personal Data Protection took effect, medical record data falls into the category of specific personal data. This means the provider you choose is required to store and process data within the territory of Indonesia. Check the physical location of the data center, not just the brand name. Some global providers offer a Jakarta region (AWS ap-southeast-3, GCP asia-southeast2, Azure Indonesia Central), but managed services such as RDS or Cloud SQL sometimes send snapshots to the nearest region such as Singapore by default. Request written confirmation in the Data Processing Agreement.

Once the location is secure, verify the relevant certifications: ISO/IEC 27001 (information security), ISO/IEC 27017 (cloud controls), ISO/IEC 27018 (protection of PII in the cloud), and SOC 2 Type II. Make sure the certificates cover the data center you actually use, not just the group headquarters. Local providers such as Biznet Gio, IDCloudHost, and Telkom Cloud are generally transparent on this matter because domestic regulation is their advantage.

Contract clauses that must be present: data ownership remains with the hospital, the right to an independent audit at least once a year, data breach notification within a maximum of 3x24 hours in accordance with the PDP Law, and an exit plan that explains how to migrate data out without hidden costs. Never rely on generic Terms of Service as a compliance basis—request a healthcare-specific addendum.

Technical Specifications: Calculate from Real Load, Not Feeling

For SIMRS with 150–300 active users, a 20–100 GB database, and 5 years of visit history, a realistic baseline is 8 vCPU, 16–32 GB RAM, and NVMe SSD with sustained IOPS of at least 3,000. Avoid disks that only burst IOPS—during morning registration hours (07.00–09.00), SIMRS can hit 4,000–6,000 IOPS for 20 minutes. If the provider limits burst to only 10 minutes, visit report queries will hang.

Also pay attention to the CPU type: the latest generation Intel Xeon Platinum or AMD EPYC provides higher clock speed for SQL Server or MySQL 8.0. If you use MySQL/MariaDB 10.11, set innodb_buffer_pool_size to 60–70% of RAM, and ensure vCPU is not oversubscribed beyond a 1:2 ratio. Minimum bandwidth of 100 Mbps dedicated per server with guaranteed 1 Gbps burst, because BPJS bridging can send thousands of requests during claim verification hours.

Read the SLA carefully. 99.9% equals 43 minutes of downtime per month, 99.95% equals 21 minutes. Ask about the definition of downtime—whether the maintenance window is included, and whether there is financial compensation (10–30% credit) if the SLA is violated. Serious providers always include automatic credits in the contract, not just marketing promises.

Latency and Connection Resilience Testing to BPJS/SatuSehat

Latency to the BPJS VClaim and SatuSehat FHIR endpoints is a decision factor that is often overlooked. From the Jakarta region, a realistic target is <100 ms to VClaim and <80 ms to SatuSehat, with packet loss <0.1% and jitter <10 ms. If average latency exceeds 150 ms, FHIR Bundle requests for Observation or Encounter risk timing out at the 30-second limit, especially during mass synchronization.

Before signing the contract, request a 7–14 day trial and run the following benchmark from the prospective provider's VM. This script measures the average latency of five attempts to three critical endpoints:

#!/bin/bash
for url in "https://dvlp.bpjs-kesehatan.go.id" \
           "https://api-satusehat.kemkes.go.id" \
           "https://simrs-domain-rs-anda.id"; do
  total=0
  for i in {1..5}; do
    ms=$(curl -o /dev/null -s -w '%{time_total}' "$url")
    total=$(echo "$total + $ms * 1000" | bc -l)
  done
  echo "$url rata-rata: $(echo "scale=0; $total/5" | bc -l) ms"
done

After latency passes, test failover: shut down one NIC or one availability zone, then measure the IP floating failover time. The maximum target is 60 seconds. For SIMRS serving outpatient registration, the target is stricter—45 seconds—because counter queues cannot wait long for reconnection.

Best Practices

1. Conduct synthetic load testing before signing the contract. Run Apache JMeter 5.6 with 100 concurrent virtual users against the registration and pharmacy endpoints for 2 hours; reject providers whose IOPS drop >30% under load.
2. Include data residency and exit plan clauses in the contract. Do not rely on the ToS; ask for an appendix that states the DC location, migration procedure, and data export format (SQL dump + checksum).
3. Enable end-to-end encryption. At-rest via LUKS/dm-crypt or cloud KMS, in-transit with minimum TLS 1.2+; disable TLS 1.0/1.1 on the load balancer.
4. Implement 3-2-1 backups and test restore every quarter. Three copies, two different media, one off-site in another region; document RTO <4 hours and RPO <15 minutes.
5. Choose a provider with 24/7 escalation and a financial SLA. Ask for an on-call engineer number, not just email tickets; check the incident track record via the public status page for the last 6 months.

FAQ

Is it permissible to use a global cloud as long as the region is Jakarta?

Yes. AWS, GCP, and Azure already have Indonesian regions. The condition is to ensure through the DPA that backups and logs are not automatically replicated abroad, and enable the data residency feature if available.

What is a realistic monthly cost for a SIMRS with 200 users?

For compute of 8 vCPU/32 GB, 500 GB NVMe, managed database, and backup, the range is Rp3–6 million per month at a local provider, or Rp5–9 million at a global provider in the Jakarta region. Below Rp2 million, there is usually a compromise on IOPS or SLA.

What are the signs that a provider is not suitable for SIMRS?

Inconsistent IOPS when tested with fio --rw=randwrite --bs=4k --numjobs=4, jitter to the BPJS endpoint >20 ms, and unwillingness to provide audit log access. These three things are enough to eliminate it from the shortlist.

Is SIMRS fully safe in the cloud?

It is safe if the architecture is multi-AZ HA, encryption is active, backups are tested, and admin access uses MFA. A single-VM monolith without a replica remains high risk even on the most expensive cloud.

Choosing a cloud server for SIMRS is a long-term architectural decision, not a commodity purchase. Start with regulatory verification, calculate specifications from real load, then close with latency and failover testing before the contract is signed. If you need technical assistance—from a migration readiness audit, multi-AZ HA design, to BPJS bridging and SatuSehat FHIR integration—Nugroho Setiawan's team is ready to help. Consult your SIMRS or SIM Klinik needs to get provider and architecture recommendations that fit your operational scale, without over-provisioning.

Related solutions by PT Pilar Inovasi Informatika (Pilar Inovasi IT products): SIMRS (Hospital Information System) BPJS & SatuSehat Integration. Need a free consultation?