Panduan Disaster Recovery Plan

Di tengah dinamika operasional fasilitas kesehatan, risiko kegagalan sistem IT bukanlah sekadar kemungkinan, melainkan keniscayaan yang harus diantisipasi. Bayangkan skenario terburuk: server SIMRS Anda mati mendadak di puncak jam sibuk IGD, data pasien tidak bisa diakses, antrean BPJS mengular, dan resep obat tidak dapat diproses. Dampaknya bukan hanya kerugian finansial yang signifikan, namun juga reputasi yang tercoreng, bahkan yang paling krusial adalah potensi ancaman terhadap keselamatan pasien. Sebuah studi menunjukkan bahwa downtime di sektor kesehatan dapat merugikan rata-rata $9,000 per menit. Inilah mengapa memiliki Disaster Recovery Plan (DRP) yang solid bukan lagi pilihan, melainkan keharusan mutlak bagi setiap rumah sakit, klinik, atau penyedia layanan kesehatan yang mengandalkan teknologi, mulai dari SIMRS, SIM Klinik, hingga sistem integrator bridging BPJS atau SatuSehat. Artikel ini akan memandu Anda secara mendalam, dari konsep dasar hingga implementasi teknis DRP, dilengkapi dengan contoh konkret, versi tool spesifik, dan best practices yang dapat segera Anda terapkan untuk membangun fondasi IT yang tangguh dan memastikan keberlangsungan layanan kesehatan Anda.

Konsep Dasar DRP dan Relevansinya di Sektor Kesehatan

Disaster Recovery Plan (DRP) adalah seperangkat prosedur terstruktur untuk memulihkan infrastruktur dan layanan IT setelah terjadi bencana. DRP merupakan bagian integral dari Business Continuity Plan (BCP), yang memiliki cakupan lebih luas untuk memastikan kelangsungan operasional bisnis secara keseluruhan. Dalam konteks sistem informasi kesehatan, perbedaan ini sangat krusial. BCP akan mencakup aspek non-IT seperti manajemen staf, komunikasi krisis, dan alternatif operasional manual, sementara DRP secara spesifik fokus pada pemulihan sistem SIMRS, database pasien, atau integrasi dengan platform seperti SatuSehat.

Dua metrik kunci dalam DRP yang harus dipahami dan ditentukan secara realistis adalah Recovery Time Objective (RTO) dan Recovery Point Objective (RPO). RTO adalah durasi maksimum yang dapat ditoleransi oleh bisnis untuk downtime sistem setelah insiden, sebelum dampaknya menjadi tidak dapat diterima. Misalnya, untuk sistem pendaftaran IGD atau farmasi di SIMRS, RTO mungkin hanya 1-2 jam. Sementara itu, RPO adalah jumlah data maksimum yang dapat hilang dari sistem karena insiden. Jika RPO ditetapkan 15 menit, berarti sistem harus mampu dipulihkan dengan kehilangan data tidak lebih dari 15 menit terakhir. Untuk data rekam medis elektronik yang sangat krusial, RPO idealnya mendekati nol. Penentuan RTO dan RPO ini harus didasarkan pada Business Impact Analysis (BIA) yang menyeluruh, mengidentifikasi sistem paling kritis dan dampak finansial serta medis dari kegagalannya. Sebagai contoh, sebuah rumah sakit tipe C dengan 150 tempat tidur dan melayani 700 pasien rawat jalan per hari, jika mengalami downtime SIMRS selama 4 jam, potensi kerugian finansial bisa mencapai puluhan juta rupiah dari hilangnya transaksi dan denda BPJS, belum lagi risiko medis akibat penundaan layanan vital.

Proses pengembangan DRP melibatkan beberapa tahapan esensial. Pertama, Risk Assessment untuk mengidentifikasi potensi ancaman (misalnya, kegagalan hardware, serangan siber, bencana alam) dan kerentanannya. Kedua, Business Impact Analysis (BIA) untuk menentukan RTO dan RPO bagi setiap sistem dan proses bisnis kritis, seperti yang diatur dalam Permenkes No. 24 Tahun 2022 tentang Rekam Medis yang menekankan pentingnya keamanan dan ketersediaan data. Ketiga, pengembangan Strategi Recovery, yaitu metode dan teknologi yang akan digunakan untuk memulihkan sistem. Keempat, Implementasi strategi tersebut, termasuk konfigurasi infrastruktur, backup, dan replikasi. Kelima, Pengujian DRP secara berkala untuk memastikan efektivitasnya. Terakhir, Pemeliharaan dan pembaruan DRP secara berkelanjutan, mengingat perubahan teknologi dan kebutuhan bisnis. Standar internasional seperti ISO 22301 (Business Continuity Management System) dapat menjadi referensi berharga dalam membangun kerangka kerja DRP yang komprehensif.

Strategi Implementasi DRP Teknis untuk Sistem Kesehatan

Implementasi Disaster Recovery Plan yang efektif di lingkungan sistem informasi kesehatan memerlukan kombinasi strategi teknis yang teruji. Fokus utama adalah memastikan ketersediaan data dan aplikasi yang tinggi dengan RTO dan RPO yang sesuai dengan kebutuhan klinis dan operasional.

Salah satu fondasi DRP adalah strategi Backup & Restore yang robust. Kami sangat merekomendasikan penerapan 'aturan 3-2-1': setidaknya tiga kopi data, disimpan di dua media penyimpanan yang berbeda, dan satu kopi disimpan di lokasi offsite terpisah. Untuk database SIMRS yang sering menggunakan PostgreSQL 16 atau MySQL 8.x, backup dapat dilakukan menggunakan `pg_dump` atau `mysqldump`. Jadwal backup harus diatur secara cermat: backup penuh (full backup) mingguan, backup diferensial atau inkremental harian, dan backup log transaksi (WAL untuk PostgreSQL) setiap beberapa menit untuk mencapai RPO yang rendah. Penyimpanan offsite bisa memanfaatkan layanan cloud seperti AWS S3, Google Cloud Storage, atau solusi on-premise yang kompatibel S3 seperti MinIO 2024.x yang dapat diimplementasikan di data center terpisah.

Untuk mencapai High Availability (HA) dan RPO mendekati nol, replikasi database adalah kunci. Untuk PostgreSQL 16, streaming replication (Primary-Standby) adalah pilihan yang populer, di mana server standby secara terus-menerus menerima WAL (Write-Ahead Log) dari server primary. Untuk MySQL 8.x, Galera Cluster atau Group Replication menyediakan solusi multi-master yang memungkinkan penulisan ke beberapa node secara bersamaan. Di lapisan aplikasi, load balancing menggunakan Nginx 1.25.x atau HAProxy 2.8.x dapat mendistribusikan trafik ke beberapa instance aplikasi, memastikan bahwa jika satu instance gagal, trafik akan dialihkan ke instance lain secara otomatis. Virtualisasi juga memainkan peran penting; platform seperti VMware ESXi 8.x atau Proxmox VE 8.x menawarkan fitur HA cluster yang secara otomatis memigrasikan VM yang gagal ke host yang sehat.

Pemilihan strategi DR Site (lokasi pemulihan bencana) juga harus dipertimbangkan. Cold Site adalah opsi paling hemat biaya namun dengan RTO terlama, hanya menyediakan ruang kosong dan infrastruktur dasar. Warm Site memiliki hardware yang sudah terpasang dan beberapa data yang direplikasi, menawarkan RTO moderat. Hot Site adalah replika penuh dari lingkungan produksi dengan replikasi data real-time, memberikan RTO terendah (menit atau detik) namun dengan biaya tertinggi. Sebuah rumah sakit besar mungkin memerlukan Hot Site untuk sistem rekam medis inti dan IGD, sementara klinik kecil bisa memulai dengan Warm Site. Untuk sistem integrator bridging BPJS atau SatuSehat, penggunaan message queueing seperti Apache Kafka 3.x memungkinkan replikasi pesan asinkron yang sangat toleran terhadap kegagalan sementara, memastikan pesan tetap terkirim meskipun ada gangguan pada salah satu endpoint.

Contoh Kode dan Konfigurasi DRP

Aspek penting dari DRP adalah otomatisasi. Skrip backup dan konfigurasi replikasi harus dirancang dengan cermat untuk meminimalkan intervensi manual dan mempercepat proses pemulihan. Berikut adalah contoh skrip backup PostgreSQL dan bagian konfigurasi untuk replikasi streaming.

Skrip Backup PostgreSQL untuk SIMRS

Skrip shell ini dapat dijalankan secara otomatis melalui cron job setiap hari. Skrip ini akan membuat dump database yang dikompresi dan menghapus backup yang lebih tua dari 7 hari, memastikan manajemen ruang penyimpanan yang efisien. Contoh ini menggunakan PostgreSQL versi 16.x.

#!/bin/bash
# Skrip Otomatisasi Backup PostgreSQL SIMRS

# Konfigurasi Database
DB_USER="simrs_admin"
DB_NAME="simrs_db"

# Direktori Penyimpanan Backup
BACKUP_DIR="/mnt/backups/postgresql"
TIMESTAMP=$(date +%Y%m%d_%H%M%S)
BACKUP_FILE="${BACKUP_DIR}/simrs_db_backup_${TIMESTAMP}.sql.gz"

# Pastikan direktori backup ada
mkdir -p "${BACKUP_DIR}"

echo "[$(date)] Memulai backup database ${DB_NAME}..."

# Lakukan backup menggunakan pg_dump dan kompresi dengan gzip
if pg_dump -U "${DB_USER}" -d "${DB_NAME}" -Fc | gzip > "${BACKUP_FILE}"; then
    echo "[$(date)] Backup berhasil disimpan ke ${BACKUP_FILE}"
    
    # Hapus backup lama (simpan 7 hari terakhir)
    find "${BACKUP_DIR}" -type f -name "simrs_db_backup_*.sql.gz" -mtime +7 -delete
    echo "[$(date)] Backup lama telah dihapus (lebih dari 7 hari)."
else
    echo "[$(date)] ERROR: Backup database GAGAL! Periksa log."
    exit 1
fi

echo "[$(date)] Proses backup selesai."

Skrip ini menggunakan format `-Fc` untuk `pg_dump` yang menghasilkan format kustom, lebih fleksibel untuk restore. Parameter `-mtime +7` pada `find` memastikan hanya file yang lebih tua dari 7 hari yang dihapus, menjaga riwayat backup yang cukup. Pastikan user `simrs_admin` memiliki hak akses yang cukup dan `.pgpass` file dikonfigurasi jika tidak ingin memasukkan password secara interaktif.

Konfigurasi Replikasi Streaming PostgreSQL (Primary Server)

Untuk mencapai RPO rendah atau mendekati nol, replikasi streaming adalah solusi yang tepat. Ini memungkinkan data dari server primary secara real-time direplikasi ke server standby. Berikut adalah bagian penting dari konfigurasi `postgresql.conf` dan `pg_hba.conf` pada server primary (PostgreSQL 16.x).

# postgresql.conf (Pada Primary Server)
listen_addresses = '*'          # Izinkan koneksi dari semua IP (sesuaikan untuk keamanan)
wal_level = replica             # Aktifkan WAL archiving dan streaming replikasi
max_wal_senders = 10            # Jumlah maksimum koneksi WAL sender
wal_keep_size = 5GB             # Atau lebih, tergantung frekuensi WAL dan RPO yang diinginkan
archive_mode = on               # Aktifkan mode pengarsipan WAL
archive_command = 'cp %p /mnt/wal_archive/%f' # Contoh sederhana, bisa pakai pg_receivewal
                                            # atau rsync ke lokasi aman

# pg_hba.conf (Pada Primary Server)
# Izinkan koneksi replikasi dari IP standby server
host    replication     all             192.168.1.0/24          scram-sha-256
                                        # Ganti dengan IP atau subnet standby Anda

Pada server standby, setelah melakukan base backup dari primary (misalnya dengan `pg_basebackup`), Anda perlu mengkonfigurasi `postgresql.conf` dengan `primary_conninfo` yang menunjuk ke server primary dan `restore_command` jika menggunakan WAL archiving. Untuk PostgreSQL 12 ke atas, file `recovery.conf` tidak lagi digunakan dan semua konfigurasi replikasi dipindahkan ke `postgresql.conf`. Pastikan `replication_user` memiliki hak akses yang sesuai. Implementasi ini akan memungkinkan server standby mengambil alih peran primary dengan cepat jika terjadi kegagalan, meminimalkan downtime dan kehilangan data.

Simulasi Kegagalan dan Penanganan

Meskipun sistem telah dirancang dengan redundansi dan backup, kegagalan tetap dapat terjadi, terutama pada integrasi dengan sistem eksternal seperti SatuSehat atau BPJS. Memahami bagaimana sistem bereaksi terhadap kegagalan dan memiliki strategi penanganan yang jelas adalah bagian krusial dari DRP.

Contoh Payload Integrasi FHIR R4 (Pasien)

Ketika SIMRS Anda mencoba mengirimkan data pasien ke platform SatuSehat menggunakan standar FHIR R4, payload JSON seperti ini akan dikirim:

{
  "resourceType": "Patient",
  "id": "example-patient-id",
  "meta": {
    "profile": [
      "https://fhir.kemkes.go.id/r4/StructureDefinition/Patient"
    ]
  },
  "identifier": [
    {
      "system": "http://terminology.kemkes.go.id/CodeSystem/nik",
      "value": "3276011708890002"
    }
  ],
  "name": [
    {
      "use": "official",
      "text": "Budi Santoso"
    }
  ],
  "gender": "male",
  "birthDate": "1989-08-17"
}

Bayangkan skenario di mana platform SatuSehat sedang mengalami gangguan atau beban tinggi, dan permintaan ini gagal terkirim.

Contoh Error Message

Aplikasi integrator Anda mungkin menerima respons error seperti ini:

{
  "code": 503,
  "message": "Service Unavailable: Downstream system (SatuSehat) is currently unreachable or experiencing high load. Please try again later.",
  "timestamp": "2024-07-26T10:30:00Z"
}

Strategi Penanganan Kegagalan Integrasi

Penanganan error seperti ini memerlukan strategi yang terencana untuk memastikan data tidak hilang dan dapat dikirimkan kembali saat sistem pulih:

1. Retry Mechanism dengan Exponential Backoff: Daripada langsung menyerah, aplikasi integrator harus mencoba kembali pengiriman data. Implementasikan strategi exponential backoff, di mana setiap percobaan ulang memiliki jeda waktu yang semakin panjang. Misalnya, percobaan pertama setelah 5 detik, kedua setelah 10 detik, ketiga setelah 20 detik, dan seterusnya, hingga jumlah percobaan maksimum (misal 5 kali). Ini mengurangi beban pada sistem yang sedang down dan memberi waktu untuk pulih. Untuk aplikasi berbasis Laravel 11.x, fitur Queue dengan retry dan delay dapat dimanfaatkan. Untuk Node.js 20 LTS, library seperti `async-retry` dapat digunakan.
2. Queueing System (Message Queues): Untuk pesan yang gagal setelah beberapa kali retry, jangan buang. Masukkan pesan tersebut ke dalam antrean (queue) yang persisten seperti RabbitMQ 3.12.x atau Apache Kafka 3.x. Antrean ini berfungsi sebagai penyangga, menyimpan pesan yang belum berhasil diproses. Setelah sistem eksternal pulih, pesan-pesan ini dapat diproses ulang secara asinkron oleh worker atau konsumen dari antrean. Ini menjamin RPO yang lebih baik untuk data integrasi.
3. Alerting dan Monitoring: Sistem harus terintegrasi dengan solusi monitoring (misalnya Prometheus 2.x dengan Grafana 10.x) yang secara proaktif mendeteksi kegagalan integrasi. Ketika jumlah error 503 melebihi ambang batas tertentu dalam periode waktu tertentu, notifikasi harus segera dikirimkan melalui PagerDuty atau Slack kepada tim IT yang bertanggung jawab. Ini memungkinkan respons cepat dan intervensi manual jika diperlukan.
4. Fallbacks dan Mode Offline Sementara: Dalam beberapa kasus, jika sistem eksternal seperti SatuSehat mengalami downtime yang panjang, aplikasi SIMRS mungkin perlu beroperasi dalam mode terbatas atau 'offline sementara'. Data yang seharusnya dikirim ke SatuSehat akan disimpan secara lokal di SIMRS dan ditandai untuk sinkronisasi nanti. Begitu koneksi pulih, data akan otomatis disinkronisasi. Ini penting untuk menjaga layanan klinis tetap berjalan, sesuai dengan PMK No. 24 Tahun 2022 yang menggarisbawahi pentingnya kelangsungan pelayanan kesehatan.

Best Practices DRP untuk Sektor Kesehatan

1. Lakukan Business Impact Analysis (BIA) secara Berkala: Identifikasi secara akurat sistem dan proses bisnis paling kritis di fasilitas Anda, seperti pendaftaran pasien, rekam medis elektronik, dan farmasi. Tentukan RTO dan RPO yang realistis berdasarkan dampak finansial dan medis dari setiap downtime. Ini harus menjadi dasar untuk semua keputusan DRP Anda.
2. Desain Arsitektur Resilien dengan High Availability (HA): Terapkan konfigurasi HA untuk semua komponen kunci, termasuk database, server aplikasi, dan jaringan. Manfaatkan teknologi seperti load balancing (Nginx 1.25.x, HAProxy 2.8.x), klaster database (PostgreSQL streaming replication, Galera Cluster), dan virtualisasi dengan fitur HA (VMware ESXi 8.x, Proxmox VE 8.x).
3. Terapkan Kebijakan Backup 3-2-1 yang Ketat: Pastikan semua data penting, terutama rekam medis pasien dan data keuangan, memiliki setidaknya tiga kopi. Dua kopi harus disimpan di media penyimpanan yang berbeda, dan satu kopi harus disimpan di lokasi offsite yang aman dan terpisah secara geografis, misalnya di cloud storage yang terenkripsi.
4. Otomatisasi Proses Backup dan Recovery: Gunakan skrip, cron jobs, dan alat orkestrasi untuk mengotomatisasi proses backup dan recovery. Ini akan meminimalkan potensi kesalahan manusia, mempercepat waktu pemulihan, dan memastikan konsistensi. Otomatisasi juga mencakup pengujian integritas backup secara berkala.
5. Uji DRP secara Rutin dan Dokumentasikan Hasilnya: Lakukan simulasi bencana setidaknya setahun sekali, atau lebih sering untuk sistem yang sangat kritis. Uji skenario kegagalan penuh, termasuk failover dan restore dari backup. Dokumentasikan setiap langkah, hasil pengujian, dan identifikasi area yang perlu perbaikan, lalu perbarui DRP Anda sesuai temuan.
6. Libatkan Seluruh Stakeholder dalam Pelatihan DRP: Pastikan tidak hanya tim IT, tetapi juga manajemen, staf medis, dan pengguna akhir memahami peran mereka dalam DRP. Lakukan pelatihan rutin tentang prosedur darurat, komunikasi krisis, dan penggunaan sistem alternatif jika sistem utama tidak tersedia.
7. Dokumentasi DRP yang Lengkap dan Terkini: DRP harus didokumentasikan dengan sangat jelas, mencakup prosedur langkah demi langkah, daftar kontak darurat, lokasi semua backup, dan konfigurasi infrastruktur. Simpan dokumen ini di lokasi yang aman, baik fisik maupun digital, dan pastikan dapat diakses bahkan saat sistem utama tidak berfungsi.
8. Prioritaskan Keamanan Data di Seluruh Siklus DRP: Pastikan semua data yang di-backup dan direplikasi dienkripsi, baik saat transit maupun saat disimpan (encryption at rest and in transit). Patuhi regulasi privasi data seperti PMK No. 24 Tahun 2022 tentang Rekam Medis Elektronik dan standar keamanan data lainnya untuk melindungi informasi sensitif pasien.
9. Pertimbangkan Solusi Cloud-based DRP (DRaaS): Untuk skalabilitas, efisiensi biaya, dan kemudahan pengelolaan, manfaatkan layanan Disaster Recovery as a Service (DRaaS) dari penyedia cloud terkemuka seperti AWS, Azure, atau GCP. DRaaS dapat menyediakan replikasi VM, failover otomatis, dan infrastruktur cadangan yang siap pakai di lokasi geografis yang berbeda.

FAQ

1. Apa perbedaan antara DRP dan BCP? DRP (Disaster Recovery Plan) secara spesifik berfokus pada pemulihan infrastruktur dan sistem teknologi informasi setelah terjadi bencana, memastikan data dan aplikasi dapat kembali berfungsi. Sementara itu, BCP (Business Continuity Plan) adalah rencana yang lebih luas dan komprehensif yang mencakup strategi dan prosedur untuk menjaga fungsi bisnis penting tetap berjalan selama dan setelah gangguan, termasuk aspek non-IT seperti manajemen sumber daya manusia, komunikasi, dan operasional manual. DRP adalah komponen kunci dari BCP.
2. Seberapa sering Disaster Recovery Plan (DRP) harus diuji? Idealnya, DRP harus diuji setidaknya setahun sekali untuk memastikan semua prosedur masih relevan, efektif, dan tim terkait familier dengan prosesnya. Untuk sistem yang sangat kritis dengan RTO dan RPO yang sangat rendah, pengujian mungkin perlu dilakukan lebih sering, misalnya setiap enam bulan atau bahkan triwulanan. Pengujian harus mencakup skenario failover penuh dan pemulihan data dari backup.
3. Bagaimana cara menentukan RTO dan RPO yang tepat untuk sistem kesehatan? Penentuan RTO (Recovery Time Objective) dan RPO (Recovery Point Objective) didasarkan pada Business Impact Analysis (BIA) yang mendalam. BIA akan mengevaluasi dampak finansial, operasional, dan reputasi dari downtime setiap sistem. Sistem kritis seperti pendaftaran IGD, farmasi, atau data rekam medis mungkin memerlukan RTO dalam hitungan menit dan RPO mendekati nol, sedangkan sistem pendukung seperti pelaporan bulanan bisa memiliki RTO/RPO yang lebih fleksibel, misalnya beberapa jam atau satu hari.
4. Apakah DRP hanya untuk bencana alam? Tidak. DRP mencakup berbagai jenis bencana dan insiden yang dapat mengganggu operasional IT. Ini termasuk kegagalan hardware (misalnya, server crash), serangan siber (seperti ransomware atau DDoS), kesalahan manusia (misalnya, penghapusan data yang tidak disengaja), pemadaman listrik yang berkepanjangan, kebakaran, dan bahkan pandemi yang membatasi akses fisik ke fasilitas. DRP adalah rencana komprehensif untuk setiap peristiwa yang mengancam ketersediaan sistem.
5. Apakah menggunakan layanan cloud menjamin DRP yang sempurna? Layanan cloud seperti AWS, Azure, atau GCP memang menawarkan infrastruktur yang sangat tangguh, redundansi bawaan, dan ketersediaan tinggi di berbagai region atau Availability Zone. Namun, keberadaan DRP yang efektif tetap menjadi tanggung jawab pengguna. Anda harus merancang arsitektur aplikasi Anda di cloud agar tahan bencana (misalnya, dengan replikasi antar-region, backup otomatis, dan konfigurasi failover) dan memiliki prosedur pemulihan yang jelas. Cloud menyediakan alatnya, tetapi Anda perlu membangun rencananya.
6. Bagaimana cara memulai DRP jika budget terbatas untuk fasilitas kesehatan kecil? Jika budget terbatas, mulailah dengan mengidentifikasi aset IT yang paling kritis dan melindungi mereka terlebih dahulu. Gunakan solusi open-source untuk backup dan replikasi data (misalnya, `pg_dump`, `rsync`, atau skrip shell sederhana). Pertimbangkan strategi cold site atau warm site yang lebih hemat biaya, di mana infrastruktur cadangan tidak selalu berjalan penuh. Prioritaskan RPO/RTO berdasarkan BIA yang realistis untuk sistem yang paling berdampak langsung pada keselamatan pasien dan operasional inti, dan tingkatkan secara bertahap seiring dengan ketersediaan sumber daya.

Membangun Disaster Recovery Plan (DRP) yang efektif bukan sekadar daftar tugas teknis, melainkan investasi strategis dalam keberlanjutan dan ketahanan operasional fasilitas kesehatan Anda. Di sektor yang sangat sensitif terhadap waktu dan data seperti kesehatan, setiap menit downtime dapat memiliki konsekuensi yang jauh lebih besar daripada sekadar kerugian finansial. Dengan memahami konsep dasar, menerapkan strategi teknis yang tepat, mengotomatisasi proses, dan secara rutin menguji DRP Anda, Anda tidak hanya melindungi data dan sistem, tetapi juga menjaga kepercayaan pasien dan memastikan kualitas layanan yang berkelanjutan. DRP yang solid adalah jaminan bahwa fasilitas Anda siap menghadapi berbagai skenario terburuk. Jika Anda membutuhkan bantuan profesional dalam merancang, mengimplementasi, atau menguji DRP yang sesuai dengan kebutuhan spesifik SIMRS, SIM Klinik, atau integrasi sistem kesehatan Anda, tim Nugroho Setiawan dengan pengalaman luas kami di berbagai solusi IT kesehatan siap membantu. Hubungi kami untuk konsultasi gratis dan mari kita bangun fondasi IT yang kuat dan tangguh bersama, demi pelayanan kesehatan yang prima dan tanpa henti.