Service Level Agreement

SERVICE LEVEL AGREEMENT (SLA)

Layanan Sistem Informasi Manajemen Fasilitas Pelayanan Kesehatan (SyncMed)
Nomor Dokumen	01/SLA/OTI/III/2026
Tanggal Efektif	1 Maret 2026
Pihak Terlibat	Tim IT Support Oxy Technology Indonesia (OTI) (Vendor) [Nama Rumah Sakit/Klinik]

1. Pendahuluan

Dokumen ini berfungsi sebagai perjanjian formal tingkat layanan antara Oxy Technology Indonesia (OTI) ("Penyedia Layanan/Vendor") dan [Nama Rumah Sakit/Klinik] ("Klien/Fasyankes") terkait penyediaan, dukungan, pemeliharaan, dan pengembangan aplikasi SyncMed.

Tujuan dari SLA ini adalah untuk menyepakati target kinerja, keandalan sistem, penanganan insiden, serta batasan layanan penyesuaian fitur guna menjamin kelancaran operasional pelayanan kesehatan secara profesional.

2. Definisi dan Ruang Lingkup Layanan

Layanan yang dicakup dalam perjanjian ini terbatas pada perangkat lunak (software) aplikasi SyncMed.

Masalah yang berkaitan dengan perangkat keras fisik (hardware), jaringan internet (ISP), kelistrikan, maupun malfungsi pada aplikasi pihak ketiga pendukung (seperti XAMPP lokal, E-Klaim BPJS milik pemerintah) berada di luar cakupan SLA ini, sebagaimana diatur lebih rinci dalam Operational Interface Agreement (OIA).

2.1. Modul Aplikasi Inti

Dukungan teknis mencakup, namun tidak terbatas pada modul-modul kritis berikut:

Front-Office: Pendaftaran Pasien (Rawat Jalan, Inap, IGD).
Clinical: Rekam Medis Elektronik (RME/EMR).
Ancillary: Manajemen Farmasi, Laboratorium, dan Radiologi.
Back-Office: Billing (Kasir), Klaim Asuransi/BPJS, dan Pelaporan Manajerial.

2.2. Model Hosting

SLA ini berlaku dan mengikat baik pada model implementasi On-Premise (server berada di lokasi Klien) maupun Cloud (infrastruktur dikelola Vendor). Khusus On-Premise, garansi performa bergantung pada pemenuhan spesifikasi minimal hardware oleh Klien.

3. Jam Operasional Dukungan (Support Hours)

Mengingat sifat kritis layanan kesehatan, Penyedia Layanan menyediakan skema dukungan sebagai berikut:

Layanan Aktif (Active Support):

Pukul 08.00 – 21.00 (12 Jam) – Tim Support tersedia untuk merespons insiden dan panduan operasional via Grup Komunikasi.

Layanan Darurat (Emergency On-Call):

Pukul 21.00 – 08.00 (12 Jam) – Tim standby hanya untuk menangani insiden dengan Prioritas Critical (P1) seperti mati total.

4. Jaminan Ketersediaan (Service Availability)

Penyedia Layanan menjamin tingkat ketersediaan (Uptime) aplikasi SyncMed sebesar 99% dihitung secara akumulatif dalam satu bulan kalender.

Perhitungan persentase Uptime ini disesuaikan dengan Jam Operasional (Working Hours) Klien. Sebagai contoh:

Untuk layanan Klinik:
Dihitung berdasarkan jam buka layanan (misal: Senin - Jumat pukul 08:00 - 21:00 waktu setempat).
Untuk layanan Rumah Sakit:
Dihitung secara penuh 24 jam sehari, 7 hari seminggu (24/7) mengikuti sifat layanan IGD dan Rawat Inap.

Pengecualian Waktu Henti (Downtime Exclusions): Berhentinya layanan pada kondisi-kondisi berikut tidak akan dihitung sebagai downtime (waktu henti) yang mengurangi persentase Uptime bulanan:

Pemeliharaan Terencana (Scheduled Maintenance):
Pemeliharaan atau pembaruan sistem yang dilakukan di luar jam kerja aktif (misalnya pada hari Sabtu, Minggu, atau dini hari) yang telah diinformasikan sebelumnya.
Gangguan Infrastruktur Lokal Fasyankes:
Insiden yang disebabkan oleh pemadaman listrik, putusnya koneksi jaringan/internet (ISP) lokal, atau kerusakan perangkat keras.
Kesalahan Pengguna (Client Error):
Malfungsi atau hilangnya akses yang terbukti disebabkan oleh kelalaian operasional user, kelalaian konfigurasi lokal, atau penyalahgunaan fitur oleh Klien.
Di Luar Jam Operasional:
Gangguan sistem yang terjadi murni di luar jam operasional resmi Klien (khusus untuk layanan dengan model working hours).

5. Matriks Prioritas Insiden

Klasifikasi insiden didasarkan pada dampak teknis terhadap keselamatan pasien dan operasional Fasyankes.

Level Prioritas	Kode	Definisi & Dampak Operasional
CRITICAL	P1	Sistem Mati Total (System Down). Dampak fatal terhadap operasional medis. Pasien massal tidak bisa didaftarkan, RME tidak bisa diakses sama sekali, risiko keselamatan terancam.
HIGH	P2	Fungsi Utama Terganggu. Sistem berjalan namun performa sangat lambat atau fitur vital (misal: bridging resep) gagal (error), namun terdapat workaround (solusi manual sementara).
MEDIUM	P3	Gangguan Minor. Masalah/ bug pada sistem yang mengganggu efisiensi kerja satu atau dua unit operasional, namun tidak melumpuhkan fungsi layanan medis dasar.
LOW	P4	Permintaan Fitur / Penyesuaian (Change Request). Tidak ada malfungsi sistem. Klien meminta modifikasi, penambahan, atau perubahan tampilan (Diatur pada Bab 9).

6. Target Waktu Layanan (Response & Resolution Time)

Penyedia Layanan berkomitmen memenuhi target waktu penyelesaian (SLA) berikut:

Prioritas	Waktu Tanggap (Response Time)	Waktu Penyelesaian (Resolution Time)	Frekuensi Update Status
Critical (P1)	< 15 Menit	< 4 Jam	Setiap 30 Menit
High (P2)	< 60 Menit	< 8 Jam	Setiap 2 Jam
Medium (P3)	< 4 Jam (Jam Kerja)	< 3 Hari Kerja	Saat terjadi perubahan status
Low (P4)	< 1 Hari Kerja	Mengikuti Estimasi Kalender Developer	Sesuai kesepakatan penyesuaian

7. Manajemen Pemeliharaan (Maintenance Management)

7.1. Pembaruan Rutin Mingguan (Weekly Update):

Dilakukan secara berkala setiap hari Minggu dini hari (di luar jam sibuk, umumnya pukul 23.00 - 04.00). Aktivitas ini mencakup optimalisasi sistem ringan dan minor patching.

7.2. Pemeliharaan Terencana (Scheduled Maintenance):

Dilakukan untuk pembaruan besar (major upgrade) di luar jam sibuk dengan pemberitahuan tertulis selambat-lambatnya 3x24 jam sebelum pemeliharaan terencana dilakukan. Durasi pemeliharaan poin 1 dan 2 tidak mengurangi perhitungan persentase Uptime bulanan.

7.3. Pemeliharaan Darurat (Emergency Maintenance):

Dilakukan segera tanpa pemberitahuan jika terdapat ancaman keamanan siber tingkat tinggi (security vulnerability) atau ditemukannya bug kritis (critical bug) yang berpotensi merusak data atau melumpuhkan sistem operasional.

8. Penalti dan Kredit Layanan (Service Credits)

Jika Penyedia Layanan gagal memenuhi target Availability (99%) dalam satu bulan akibat kelalaian sistem internal SyncMed (Bukan karena Force Majeure, kelalaian user, atau putusnya internet/listrik lokal Fasyankes), maka Klien berhak atas pemotongan biaya langganan bulanan (Service Credit):

Ketersediaan Bulanan (Uptime)	Kompensasi / Kredit Layanan
99% - 100%	Target Tercapai (Tidak ada kompensasi)
97% - 98.99%	Pemotongan 5% dari biaya bulanan
95% - 96.99%	Pemotongan 10% dari biaya bulanan
Kurang dari 95%	Pemotongan 20% & Hak Tinjau Ulang Kontrak

9. Manajemen Permintaan Penyesuaian Fitur (Change Request Quota)

Untuk menjaga keberlanjutan pengembangan perangkat lunak, Penyedia Layanan memberlakukan sistem Kuota Penyesuaian Tahunan untuk setiap permintaan perubahan/penambahan fitur baru dalam SIMRS SyncMed. Klausul ini TIDAK BERLAKU untuk perbaikan error/bug sistem (Prioritas P1-P3), di mana perbaikan bug sepenuhnya menjadi kewajiban Penyedia Layanan tanpa dikenakan pemotongan kuota atau biaya tambahan.

9.1. Alokasi Kuota Berbasis Volume Layanan

Setiap Klien pada dasarnya diberikan kuota dasar sebanyak 10 Unit Penyesuaian per Tahun Kontrak tanpa dikenakan biaya tambahan.

Namun, Klien dapat memperoleh Tambahan Unit Kuota (hingga maksimal total 15 Unit) yang perhitungannya didasarkan pada rata-rata jumlah pasien per bulan Klien pada tahun sebelumnya. Skema penambahan kuota ditetapkan sebagai berikut:

Kategori	Rata-rata Jumlah Pasien per Bulan	Tambahan Kuota	Total Kuota Tahunan
Dasar	< 500 pasien	+ 0 Unit	10 Unit
1	501 - 2.000 pasien	+ 1 Unit	11 Unit
2	2.001 - 4.000 pasien	+ 2 Unit	12 Unit
3	4.001 - 6.000 pasien	+ 3 Unit	13 Unit
4	Di atas 6.000 pasien	+ 5 Unit	15 Unit (Maksimal)

(Catatan: Total kuota ini di-reset setiap pergantian tahun kontrak. Sisa kuota tidak dapat diakumulasi atau dipindahkan ke tahun berikutnya).

9.2. Perhitungan Kompleksitas & Pemotongan Unit

Setiap permintaan Klien (P4) akan dianalisis secara teknis oleh tim Developer OTI untuk menentukan besaran unit yang akan dipotong. Skema pemotongan didasarkan pada tingkat kompleksitas:

9.2.1 Penyesuaian Minor (Memotong 1 - 3 Unit):

Contoh: Penambahan filter pencarian sederhana, perubahan parameter pada format cetak laporan, penambahan kolom data non-kalkulatif.

9.2.2. Penyesuaian Sedang (Memotong 4 - 5 Unit):

Contoh: Perubahan tata letak antarmuka (User Interface/UI) yang mengubah struktur formulir rekam medis, penambahan kalkulasi rumus baru pada modul tertentu.

9.2.3. Penyesuaian Kompleks (Memotong 6 - 10 Unit):

Contoh: Pembuatan dashboard visualisasi data baru, penambahan modul operasional yang belum ada, atau integrasi (bridging) dengan sistem/API pihak ketiga di luar Kemenkes/BPJS.

9.3. Kelebihan Penggunaan (Out of Scope / Chargeable)

Apabila total kuota tahunan milik Klien (antara 10 hingga 15 Unit sesuai kategori) telah habis terpakai, Klien tetap dapat mengajukan permintaan penyesuaian tambahan dengan skema Berbayar (Chargeable). Tarif untuk setiap unit tambahan akan disesuaikan dengan tingkat kompleksitas permintaan dan estimasi jam kerja (man-hours) Developer yang akan ditagihkan secara terpisah.