Cloud Servers for SIMRS: How to Choose the Right Provider

A SIMRS running on a seven-year-old on-premise server, with HDD disks and a UPS that has failed twice, often becomes the starting point for discussions about migrating to the cloud. The problem is that many hospitals move to the cloud only by comparing monthly prices, then are disappointed when the pharmacy module and BPJS bridging actually feel slower during peak hours. In a hospital with 200 beds and 150 active users, peak load occurs between 07:30 and 10:00: registration, prescription writing, supporting orders, and claim synchronization run simultaneously. The right cloud provider for SIMRS is not the cheapest, but the one whose storage profile, network latency, and SLA match that load pattern. This article discusses how to choose one measurably, from calculating sizing to testing failover before the contract is signed.

Start from the SIMRS Workload Profile, Not the Monthly Price

A provider is usually chosen by comparing the number of vCPUs and RAM on the pricing page. That approach is wrong for SIMRS because the bottleneck is rarely in the CPU, but in database IOPS and medical record query latency. In the PHP 8.2 and MySQL 8.0-based SIMRS installations we manage, one patient medical record page with a history of 20 visits produces 30–60 queries. A daily visit report accessed by 50 users simultaneously can trigger 2,000–3,000 queries per minute, and this is where a 4 vCPU/8 GB instance with burst disks starts to collapse.

The first step is to take a baseline from the existing server for at least seven days, especially the Monday and Tuesday peaks. Record slow queries above 1.5 seconds using pt-query-digest or performance_schema, measure peak IOPS with iostat -x 5, and calculate the data growth rate. A five-year-old SIMRS database is generally 60–180 GB, plus 300–800 GB of object storage for radiology results, scanned documents, and claim attachments.

Once the baseline numbers are available, then choose the instance type. Avoid volumes with burst IOPS for the MySQL data partition; choose one that guarantees baseline. AWS gp3 allows 3,000–16,000 IOPS to be configured separately from volume size, while providers with local NVMe such as UpCloud or DigitalOcean often provide higher IOPS per dollar for read-heavy workloads. For sessions, master data (ICD-10, tariffs, doctor lists), and drug catalogs, Redis 7.2 cuts render time by 30–45% because repeated queries no longer touch disk.

Don't forget the bridging support components. Queue workers for BPJS and SatuSehat (FHIR R4) claim submissions, reporting cron jobs, and the staging environment usually need an additional 2 vCPU/4 GB so that queue processes do not compete for CPU with the main application during month-end closing.

Provider Due Diligence: Network, Compliance, and SLA

Network latency is often overlooked even though its impact is immediately felt. For hospitals in Yogyakarta, DIY, and Magelang, choosing the Jakarta region gives 8–20 ms latency over fiber connections, while the Singapore region gives 40–60 ms. That difference matters during mass claims: FHIR requests to SatuSehat and file submissions to BPJS have timeouts and retry mechanisms, so high latency causes queues to pile up and some requests to fail midway.

Compliance is not a formality. Permenkes 24/2022 requires electronic medical record operators to maintain confidentiality and provide an audit trail, while Law 27/2022 on Personal Data Protection regulates the processing of patient data. In practice, ensure data is stored in Indonesian territory, encrypted at rest with AES-256, encrypted in transit with at least TLS 1.2, keys managed through KMS, and access logs exportable for audit. Request proof of ISO 27001 or SOC 2 Type II, not just claims on a marketing page.

The SLA must be read down to the appendix. A minimum target of 99.9% is equivalent to about 43 minutes of downtime per month. Ask about the definition of downtime, whether scheduled maintenance is excluded, what compensation is provided, the availability of a status page, and whether a post-mortem is shared after an incident. For SIMRS, set a maximum RTO of 4 hours and a maximum RPO of 15 minutes, then verify that daily backups are actually restore-tested every quarter.

Finally, support. A worthy provider has 24/7 on-call engineers with an escalation path to the technical level, not just a chatbot and ticketing system. For IT consulting and application development needs for SIMRS, SIM Klinik, ERP, POS, and websites in Yogyakarta and Magelang, choose a partner willing to sign architecture documents and operational runbooks, not just rent out machines.

Test Latency, Throughput, and Failover Before the Contract

Don't trust synthetic benchmarks on the provider's page. Request a 7–14 day trial, deploy a minimum stack (web app, MySQL, Redis) with an anonymized data copy, then measure from the hospital's network, not from the marketing office.

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

Interpreting the results: local endpoint TTFB should be below 300 ms, jitter below 5 ms, and packet loss 0%. Also record the managed database failover time, typically 60–120 seconds for replica promotion, then ensure the application has connection retry (pool timeout 5 seconds, three attempts with backoff) so users do not see an error page.

Test upload throughput for restore and backup. One hundred GB over a 100 Mbps uplink takes about 2.2 hours; if the provider does not offer seeding via physical disk, a 4-hour RTO is unrealistic. Keep all these numbers in an evaluation document so the decision can be justified to management and the accreditation team.

Best Practices

1. Take baseline IOPS, slow queries, and seven-day data growth before choosing an instance; do not start from a price list.
2. Choose volumes with guaranteed baseline IOPS for the MySQL partition, and separate object storage for radiology and scanned documents.
3. Choose the Indonesia (Jakarta) region to reduce BPJS and SatuSehat bridging latency; measure traceroute from the hospital network, not from the office.
4. Verify a written SLA: 99.9%, RTO ≤ 4 hours, RPO ≤ 15 minutes, clear compensation, and backups tested for restore every quarter.
5. Request a 7–14 day trial and test database failover and restore time before signing an annual contract.

FAQ

What are the minimum cloud server specifications for SIMRS with 150 active users?

Start with 8 vCPU/16 GB for the application, a separate database with 4 vCPU/16 GB and a baseline of 3,000 IOPS, and Redis 2 GB. Adjust after reviewing the baseline slow queries and IOPS peaks from the old server.

May medical record data be stored in an overseas cloud?

Under Indonesian regulations, RME organizers must maintain confidentiality and an audit trail, and the PDP Law governs the transfer of personal data outside the territory. The safe and most easily audited practice is to store patient data in the Indonesia region.

How should you assess a provider that only offers a 99.5% SLA?

99.5% means about 3.6 hours of downtime per month, which is too much for a SIMRS used when registration and pharmacy are open. Propose negotiating to 99.9% or request a multi-zone architecture with automatic failover.

Is multi-cloud necessary for SIMRS?

For most hospitals in DIY and Magelang, no. More important are multi-zone within one provider, cross-region backups, and tested emergency runbooks, because multi-cloud complexity actually adds operational costs.

Choosing a cloud server for SIMRS is an architectural decision, not a purchasing decision. Measure the real workload, verify latency from the hospital network, read the SLA through to the appendix, and test failover before signing. If you are preparing to migrate SIMRS, SIM Klinik, ERP, or POS to the cloud, our team helps with sizing audits, architecture design, and implementation assistance for hospitals and clinics in Yogyakarta, DIY, and Magelang. Start with a 60-minute consultation session using your baseline data.

This article is part of the knowledge base of Nugroho Setiawan, an IT consultant in Jogja (Yogyakarta). Related solutions: SIMRS (Hospital Information System) BPJS & SatuSehat Integration. Need a free consultation?