Saya ingat persis waktu surat edaran SATUSEHAT pertama turun. Rapat dadakan, direktur tanya "kapan selesai?", dan saya jawab dengan percaya diri: "tiga bulan, Pak."

Itu dua tahun lalu.


Yang Sebenarnya Terjadi di Lapangan

Hampir semua artikel tentang SATUSEHAT yang saya baca nuansanya sama: langkah-langkah integrasi, penjelasan FHIR R4, resource apa yang wajib dikirim. Berguna — tapi itu bukan yang bikin pusing.


Yang bikin pusing adalah hal-hal yang tidak ada di dokumentasi resmi.

Misalnya: Encounter yang sudah dikirim 12.000+ tapi dashboard SATUSEHAT masih angkanya nol selama tiga hari. Panik. Cek log, tidak ada error. Cek token, valid. Ternyata ada delay sisi server Kemenkes yang memang tidak terdokumentasi. Tidak ada notifikasi, tidak ada status page. Kita cuma harus sabar dan nunggu.


Atau: mapping ICD-10 ke SNOMED CT yang "tinggal lookup" ternyata butuh kurasi manual karena diagnosis yang dipakai dokter di RS kita tidak selalu match satu-satu dengan terminology standar. Ada dokter yang nulis "dyspepsia fungsional", ada yang "gastritis", ada yang singkatan sendiri. SIMRS lama tidak strict, jadi data historikal jadi warisan yang repot.

Ini bukan keluhan. Ini konteks — karena kalau kita tidak jujur soal kompleksitasnya, orang IT RS yang baru mulai akan kaget dan merasa sendirian padahal masalah yang sama dialami hampir semua RS.



Vendor RME Itu Mitra, Bukan Pemain Tunggal

Satu hal yang sering salah dipahami: integrasi SATUSEHAT bukan sepenuhnya urusan vendor RME.

Vendor kirim data ke SATUSEHAT berdasarkan apa yang ada di sistem mereka. Tapi data di sistem mereka datang dari workflow klinis di RS kita. Kalau dokter tidak mengisi diagnosis dengan kode yang benar, tidak ada sistem yang bisa kirim data yang benar.

Jadi ujung-ujungnya, yang paling banyak kena getah adalah tim IT RS — yang harus duduk bareng dokter, keperawatan, rekam medis, dan vendor sekaligus. Bukan posisi yang nyaman, tapi itu realitasnya.

Yang berhasil saya lakukan: jadikan pertemuan lintas departemen sebagai rutinitas, bukan event darurat. Satu jam sebulan dengan kepala rekam medis dan perwakilan dokter jauh lebih efektif daripada email blast yang tidak dibaca.


Soal Sanksi dan Akreditasi

Ini yang lebih sensitif dan jarang dibahas terang-terangan.

RS saya pernah kena downgrade akreditasi karena penilaian kepatuhan RME yang tidak mencerminkan kondisi aktual. Data sudah terkirim ribuan, tapi tidak terbaca di sisi penilai. Kami harus buat klarifikasi resmi, lampirkan screenshot dashboard, lampirkan log pengiriman.

Yang saya pelajari: jangan tunggu ada masalah baru mendokumentasikan kepatuhan. Simpan bukti pengiriman secara periodik — screenshot dashboard SATUSEHAT, export log API, rekap bulanan. Bukan untuk gagah-gagahan, tapi karena kalau nanti dipertanyakan, kita punya data yang bisa bicara.

Dan kalau memang ada gap kepatuhan yang nyata — akui, buat roadmap perbaikan, komunikasikan ke manajemen dengan bahasa yang mereka mengerti (risiko operasional, bukan stack trace).


Infrastruktur yang Sering Dilupakan

SATUSEHAT butuh koneksi internet yang stabil dan latensi yang reasonable. Kelihatannya sepele sampai kita sadar bahwa RS kita punya satu ISP tanpa backup, dan ISP itu mati dua kali dalam sebulan.

Selain itu: server SIMRS yang dipakai sejak 2015 dengan RAM 8GB tidak akan happy kalau tiba-tiba harus handle concurrent request ke API eksternal di tengah jam operasional. Ini bukan masalah SATUSEHAT-nya, ini masalah kita tidak pernah review kapasitas infrastruktur secara serius.

Kalau belum pernah hitung berapa request per jam yang digenerate dari alur pasien rawat jalan + rawat inap + IGD secara bersamaan, sekarang waktu yang tepat untuk mulai.


Apa yang Saya Harap Tahu Lebih Awal

Beberapa hal yang kalau saya tahu dari awal, prosesnya lebih lancar:

Baca error response API dengan teliti. Bukan cuma HTTP status code-nya — tapi body-nya. SATUSEHAT sering kasih pesan yang cukup spesifik, tapi mudah dilewatkan kalau kita hanya log status 400 tanpa capture body.

Pisahkan environment sandbox dan production dengan ketat. Pernah ada insiden di mana data test nyasar ke production endpoint karena konfigurasi tidak dipisah dengan benar. Tidak fatal, tapi merepotkan untuk dibersihkan.

Jalin relasi dengan komunitas IT RS lain. Banyak masalah yang saya temukan sudah pernah dialami orang lain. Forum, grup Telegram, atau komunitas seperti PETRIS ini — itu lebih cepat memberikan jawaban praktis daripada nunggu respons tiket ke helpdesk Kemenkes.



Dua tahun integrasi SATUSEHAT mengajarkan satu hal yang tidak ada di dokumentasi manapun: ini bukan proyek IT. Ini proyek perubahan organisasi yang kebetulan banyak bagian teknisnya.


Tim IT yang berhasil bukan yang paling jago coding-nya. Tapi yang paling sabar duduk di tengah-tengah dokter, manajemen, vendor, dan regulasi — dan tetap bisa deliver.

Penulis adalah Kepala IT di RS swasta kelas C di Pekanbaru, Riau. Aktif di komunitas PETRIS dan SATUSEHAT Sumatra.