SLA dan Uptime dalam Kontrak SIMRS: 6 Angka yang Wajib Dikunci Sebelum Tanda Tangan

Kontrak SIMRS yang tidak mengunci angka layanan mengubah setiap gangguan sistem menjadi risiko kas, bukan sekadar keluhan operasional. Sejak klaim JKN bergerak ke jalur rekam medis elektronik terintegrasi SATUSEHAT, satu hari SIMRS padam bisa berarti berkas klaim yang tertunda dan pendapatan yang tertahan. Enam angka berikut adalah yang wajib tertulis di kontrak sebelum tanda tangan — bukan di brosur, bukan di janji lisan sales.

Artikel ini ditujukan untuk Direktur, Wadir Pelayanan, dan champion IT yang menegosiasikan atau memperpanjang kontrak SIMRS. Fokusnya bukan fitur, melainkan Service Level Agreement (SLA): janji layanan yang bisa diukur dan ditagih. Sebuah SIMRS dengan modul lengkap tetapi tanpa SLA yang mengikat adalah aset yang tidak bisa diandalkan ketika paling dibutuhkan.

Mengapa SLA SIMRS kini soal kas, bukan soal IT

Downtime SIMRS dulu adalah masalah kenyamanan; sekarang ia masalah arus kas. Ketika pengajuan klaim JKN bergantung pada pengiriman data rekam medis elektronik, sistem yang padam di akhir bulan bisa menahan seluruh siklus penagihan sampai layanan pulih. Yang tadinya ditangani diam-diam oleh tim IT kini menyentuh laporan keuangan.

Pergeseran ini punya dasar regulasi. Permenkes 6/2026 tentang Rumah Sakit mewajibkan setiap RS mengintegrasikan dokumentasi kegiatannya ke dalam Sistem Informasi Kesehatan Nasional dan melaporkan aktivitas secara digital, dengan masa penyesuaian sampai pertengahan 2028. Di sisi klaim, Surat Edaran Bersama lima lembaga tertanggal 30 Juli 2026 menempatkan pengelolaan klaim JKN pada jalur RME terintegrasi SATUSEHAT. Artinya ketersediaan SIMRS bukan lagi urusan internal — ia menopang kewajiban pelaporan dan aliran pendapatan sekaligus.

Konsekuensinya jelas untuk meja pengadaan: SLA harus dinegosiasikan seolah-olah setiap jam downtime punya harga, karena memang begitu. Enam angka di bawah ini adalah kerangka minimum.

1. Persentase uptime — beserta definisinya

Uptime adalah persentase waktu SIMRS dijamin tersedia, tetapi angka itu tidak berarti apa-apa tanpa empat definisi yang menyertainya: periode pengukuran, jam yang dihitung, pengecualian, dan cara verifikasi. Vendor yang menyodorkan "99,9%" tanpa definisi ini menjual angka yang tidak bisa ditagih.

Perhatikan aritmetika downtime yang tersisa di balik angka besar:

• 99,9% menyisakan sekitar 8,8 jam gangguan per tahun.
• 99,5% menyisakan sekitar 43,8 jam per tahun.
• 99,0% menyisakan sekitar 87,6 jam — lebih dari tiga setengah hari.

Selisih antara 99,9% dan 99,5% terlihat kecil di kertas tetapi berarti puluhan jam layanan yang berbeda. Yang harus dikunci di kontrak: periode pengukuran (bulanan menekan vendor lebih ketat daripada tahunan, karena satu insiden besar tidak bisa "diencerkan" sepanjang tahun), jam yang dihitung (24/7 penuh atau hanya jam operasional), dan daftar pengecualian — pemeliharaan terjadwal yang wajar boleh dikecualikan, tetapi pastikan definisinya tidak begitu lebar sampai gangguan nyata pun lolos.

2. Waktu respons dan waktu resolusi insiden per tingkat keparahan

Uptime menjawab "seberapa sering", tetapi ketika sistem bermasalah yang menentukan adalah seberapa cepat vendor merespons dan menyelesaikan. Kontrak harus memisahkan waktu respons (kapan vendor mulai menangani) dari waktu resolusi (kapan masalah selesai), dan mengikat keduanya pada tingkat keparahan yang didefinisikan.

Tingkat keparahan sebaiknya ditulis eksplisit, misalnya:

• Kritis — SIMRS tidak bisa diakses sama sekali, atau modul yang menopang klaim dan pelayanan pasien berhenti. Respons dalam hitungan belasan menit, penanganan tanpa jeda sampai pulih.
• Tinggi — satu modul penting terganggu tetapi sistem masih berjalan sebagian.
• Sedang/rendah — gangguan yang tidak menghentikan operasional inti.

Kesalahan paling umum adalah kontrak yang hanya mencantumkan waktu respons. Vendor bisa "merespons" dalam 15 menit lalu membutuhkan tiga hari untuk menyelesaikan, dan secara teknis tidak melanggar apa pun. Kunci keduanya, per tingkat keparahan, dengan jam kerja yang jelas apakah 24/7 atau bukan.

3. RTO dan RPO untuk pemulihan bencana

RTO dan RPO adalah dua angka pemulihan bencana yang paling sering hilang dari kontrak SIMRS, padahal keduanya menentukan seberapa parah sebuah kegagalan besar akan terasa. RTO (Recovery Time Objective) adalah batas berapa lama sistem boleh padam sebelum kembali beroperasi. RPO (Recovery Point Objective) adalah batas berapa banyak data yang boleh hilang, diukur mundur dari titik gangguan.

Contoh konkret memperjelas bedanya. RPO empat jam berarti bila server rusak pukul 14.00, data sejak backup terakhir pukul 10.00 bisa hilang — empat jam entri klinis dan transaksi. Bagi RS yang mengandalkan RME untuk klaim, kehilangan empat jam dokumentasi bukan sekadar merepotkan; ia bisa berarti berkas klaim yang tidak lengkap.

Yang harus dikunci: RTO dan RPO dalam satuan waktu yang tegas (jam, bukan "secepatnya"), skenario yang dicakup (kegagalan server, kerusakan pusat data, serangan siber), dan kewajiban uji pemulihan berkala yang dibuktikan dengan laporan. Angka pemulihan yang tidak pernah diuji adalah asumsi, bukan jaminan.

4. Jaminan dan tenggat ekspor data

Jaminan ekspor data adalah pasal yang paling diabaikan saat tanda tangan dan paling menyakitkan saat berpisah. Tanpa itu, data rekam medis RS bisa tersandera di dalam sistem vendor ketika kontrak berakhir — dan RS kehilangan daya tawar justru di saat paling genting, yaitu saat ingin pindah.

Kontrak wajib mengunci empat hal: format ekspor yang terbaca mesin dan terstruktur (basis data atau berkas standar yang bisa diimpor, bukan ribuan cetakan PDF), cakupan data yang diserahkan (seluruh rekam medis, data transaksi, dan metadata — bukan sebagian), tenggat penyerahan setelah pemutusan kontrak, dan kewajiban pemusnahan salinan di sisi vendor setelah serah terima.

Bagian terakhir ini bukan sekadar kebersihan administratif. UU 27/2022 tentang Pelindungan Data Pribadi menempatkan RS sebagai pengendali data pasien dengan kewajiban memastikan data diproses secara sah dan dilindungi, termasuk saat berada di tangan pihak ketiga pemroses. Kontrak yang tidak mengatur pengembalian dan pemusnahan data meninggalkan RS memikul tanggung jawab hukum atas salinan yang tidak lagi bisa ia kendalikan.

5. Service credit dan penalti yang bisa dijalankan

Penalti hanya berguna bila bisa ditagih tanpa perang administrasi. Bentuk yang paling bisa dijalankan adalah service credit: potongan biaya langganan yang berlaku otomatis begitu SLA terlampaui, dihitung dari laporan ketersediaan yang diterbitkan vendor sendiri. Model ini memindahkan beban dari RS — yang harus membuktikan pelanggaran — ke mekanisme yang jalan dengan sendirinya.

Yang harus dikunci: besaran kredit yang bertingkat sesuai keparahan pelanggaran (semakin jauh di bawah target, semakin besar potongan), cara perhitungan yang otomatis dari laporan bulanan, dan ambang pemutusan — berapa kali pelanggaran berturut-turut yang memberi RS hak mengakhiri kontrak tanpa penalti. Tanpa ambang ini, vendor bisa terus melanggar sambil membayar kredit kecil, dan RS terkunci.

Hindari penalti yang mengharuskan RS mengajukan klaim manual satu per satu. Dalam praktik, tim yang sibuk jarang menuntut kredit setiap kali sistem lambat, sehingga penalti seperti itu tampak bagus di kertas tetapi nyaris tidak pernah tertagih.

6. Frekuensi backup, retensi, dan bukti kepatuhan keamanan

Angka terakhir menyatukan tiga janji yang sering dibiarkan kabur: seberapa sering data dicadangkan, berapa lama disimpan, dan bagaimana keamanannya dibuktikan. Ketiganya harus jadi angka dan kewajiban, bukan pernyataan niat di brosur.

Yang dikunci di kontrak: frekuensi backup (harian penuh, atau lebih sering untuk data transaksi) yang konsisten dengan RPO yang sudah disepakati di poin 3, periode retensi yang selaras dengan kewajiban penyimpanan rekam medis, lokasi dan enkripsi cadangan, serta bukti kepatuhan — laporan uji keamanan berkala dan pemberitahuan insiden dalam tenggat yang ditentukan. UU 27/2022 mewajibkan pengendali dan pemroses data melindungi data pribadi dan memberitahukan kegagalan pelindungan; kontrak harus menerjemahkan kewajiban itu menjadi tenggat dan format laporan yang konkret, bukan klausul umum.

Backup yang tidak pernah diuji pulih setara dengan tidak ada backup. Sertakan kewajiban vendor menunjukkan hasil pemulihan uji secara berkala, sama seperti RTO/RPO di poin 3.

Dasar Hukum

• Permenkes 6/2026 tentang Rumah Sakit — mewajibkan RS mengintegrasikan dokumentasi kegiatan ke Sistem Informasi Kesehatan Nasional dan melaporkan aktivitas secara digital, dengan masa penyesuaian sampai pertengahan 2028 (RS Kelas D Pratama berizin mendapat kelonggaran lebih panjang). Menjadi dasar mengapa ketersediaan dan pelaporan SIMRS bersifat wajib, bukan opsional.
• UU 27/2022 tentang Pelindungan Data Pribadi — menempatkan RS sebagai pengendali data pasien dengan kewajiban memproses data secara sah, melindunginya (termasuk di tangan pemroses pihak ketiga), memberitahukan kegagalan pelindungan, serta konsekuensi administratif atas pelanggaran. Menjadi dasar klausul ekspor, pemusnahan, dan keamanan data.
• Surat Edaran Bersama Percepatan Implementasi RME Terintegrasi SATUSEHAT dalam Pengelolaan Klaim JKN (30 Juli 2026) — menempatkan pengelolaan klaim JKN pada jalur RME terintegrasi SATUSEHAT, yang membuat downtime SIMRS berdampak langsung pada penagihan.

Cek Kontrak Sebelum Tanda Tangan

Sebelum menyetujui kontrak SIMRS, pastikan enam angka ini tertulis eksplisit dan terukur, bukan tersirat:

• Persentase uptime beserta periode pengukuran, jam yang dihitung, dan daftar pengecualian.
• Waktu respons dan waktu resolusi, dipisah per tingkat keparahan.
• RTO dan RPO dalam satuan jam, dengan kewajiban uji pemulihan.
• Format, cakupan, tenggat ekspor data, dan kewajiban pemusnahan salinan vendor.
• Service credit otomatis dengan ambang pemutusan kontrak.
• Frekuensi backup, retensi, enkripsi, dan bukti kepatuhan keamanan.

Kontrak yang mengunci keenamnya mengubah janji layanan menjadi kewajiban yang bisa ditagih. Kontrak yang membiarkannya kabur menyerahkan RS pada itikad baik vendor — taruhan yang terlalu mahal ketika klaim dan pelaporan kini bergantung pada sistem yang sama.

FAQ

Berapa uptime SIMRS yang wajar dikunci di kontrak?

Yang penting bukan angka tunggal, melainkan definisinya. Uptime 99,9% terdengar tinggi tetapi tetap menyisakan sekitar 8,8 jam gangguan per tahun; 99,5% menyisakan sekitar 43,8 jam. Kunci di kontrak: persentase ketersediaan, periode pengukuran (bulanan lebih ketat daripada tahunan), jam yang dihitung (24/7 atau jam operasional), dan pengecualian apa saja yang tidak dihitung sebagai downtime. Angka tanpa definisi ini tidak bisa ditagih.

Apa beda RTO dan RPO dalam kontrak SIMRS?

RTO (Recovery Time Objective) adalah batas berapa lama sistem boleh mati sebelum kembali beroperasi setelah gangguan besar. RPO (Recovery Point Objective) adalah batas berapa banyak data yang boleh hilang, diukur dalam waktu mundur dari titik gangguan. RTO menjawab "berapa lama padam", RPO menjawab "berapa jam entri terakhir yang hilang". Keduanya harus ditulis sebagai angka, bukan janji "secepatnya".

Kenapa jaminan ekspor data harus ada di kontrak SIMRS?

Karena tanpa itu, data rekam medis RS bisa tersandera di sistem vendor saat kontrak berakhir. Kontrak wajib mengunci format ekspor yang terbaca (bukan cetakan PDF massal), cakupan data yang diserahkan, tenggat penyerahan setelah pemutusan, dan kewajiban pemusnahan salinan di sisi vendor sesuai UU 27/2022 tentang Pelindungan Data Pribadi.

Apakah penalti SLA benar-benar bisa ditagih ke vendor?

Bisa, jika mekanismenya otomatis dan tidak bergantung pada klaim manual RS. Bentuk yang paling bisa dijalankan adalah service credit — potongan biaya langganan yang berlaku otomatis begitu SLA terlampaui, dihitung dari laporan ketersediaan yang diterbitkan vendor sendiri. Penalti yang mengharuskan RS mengajukan tuntutan satu per satu jarang tertagih.

Sumber

• Peraturan Menteri Kesehatan Nomor 6 Tahun 2026 tentang Rumah Sakit — JDIH Kementerian Kesehatan (jdih.kemkes.go.id).
• Undang-Undang Nomor 27 Tahun 2022 tentang Pelindungan Data Pribadi — JDIH BPK RI (peraturan.bpk.go.id).
• Surat Edaran Bersama Percepatan Implementasi Rekam Medis Elektronik Terintegrasi SATUSEHAT dalam Pengelolaan Klaim JKN, 30 Juli 2026 — Kementerian Kesehatan & BPJS Kesehatan.