Sobat IT RS, kalau ada satu topik yang bikin ngelus dada sejagat per-SIMRS-an Indonesia, itu adalah bridging SATUSEHAT. Pokok e ngene: lo udah punya SIMRS jalan, data pasien udah rapi, eh tiba-tiba Kemenkes nge-wajibin semua RS kirim data ke platform SATUSEHAT. Terus lo buka dokumentasi API-nya, lo scroll, lo baca, dan lo sadar: ini nggak sesimpel kirim JSON terus beres. Ada autentikasi token, ada format FHIR, ada terminologi coding yang njelimet, dan yang paling nyebelin: error message-nya kadang cuma balikin kode tanpa penjelasan. Kalau lo lagi ngerjain bridging ini sekarang atau baru mau mulai, artikel ini buat lo.

Gue nggak akan ngulang dokumentasi resmi SATUSEHAT, karena itu bisa lo baca sendiri di portal. Di sini gue fokus ke masalah-masalah nyata yang sering muncul di lapangan, dari pengalaman ngebantu beberapa RS temen sejawat, plus solusi teknis yang langsung bisa lo contek. Anggap ini cheat sheet troubleshooting SATUSEHAT versi lapangan. Dan percaya deh, lo bakal balik ke artikel ini berkali-kali pas jam 10 malam deadline kirim data besok pagi.

1. Token JWT: Dapetin, Simpan, Refresh

Bridging SATUSEHAT pake OAuth 2.0 client credentials, jadi lo perlu token JWT buat setiap request. Masalah pertama yang sering muncul: token expired di tengah-tengah proses kirim data, dan aplikasi lo nggak nge-handle refresh token-nya. Akibatnya, data setengah jalan, dan lo harus kirim ulang dari awal. Ini contoh fungsi simpel di PHP buat handle token dengan caching dan auto-refresh:

function getSATUSEHATToken(): string {
    $cacheKey = 'satusehat_token';
    $token = apcu_fetch($cacheKey);
    if ($token && $token['expires_at'] > time() + 60) {
        return $token['access_token'];
    }
    $resp = http_post(TOKEN_URL, [
        'client_id' => CLIENT_ID,
        'client_secret' => CLIENT_SECRET,
    ]);
    $data = json_decode($resp, true);
    $token = [
        'access_token' => $data['access_token'],
        'expires_at' => time() + $data['expires_in'],
    ];
    apcu_store($cacheKey, $token);
    return $token['access_token'];
}

Beberapa poin penting dari kode di atas: simpan token di cache, refresh sebelum expired (sisa 60 detik), dan jangan panggil endpoint token setiap request karena ada rate limit. Kalau lo pake Redis atau file cache, prinsipnya sama, yang penting token nggak di-generate ulang di setiap HTTP call.

2. Terminologi Coding yang Beda Antar RS

Ini yang bikin darah tinggi. SATUSEHAT pake standar terminologi internasional kayak SNOMED CT, ICD-10, IHS, dan lo harus mapping kode lokal SIMRS lo ke kode standar itu. Contoh: di SIMRS, jenis kelamin ditulis L/P (laki-laki/perempuan), tapi di SATUSEHAT butuh kode SNOMED CT "446151000124109" (male) dan "446141000124107" (female). Masalah makin runyam kalau lo ngirim data dari RS yang punya coding sendiri — misal golongan darah di simpan sebagai "O" tapi SATUSEHAT minta sistem ABO dengan kode spesifik.

Solusi paling waras: bikin tabel mapping terminologi sendiri di database lo. Strukturnya simpel:

CREATE TABLE terminology_mapping (
    id SERIAL PRIMARY KEY,
    domain VARCHAR(50) NOT NULL,          -- misal: 'gender', 'blood_type'
    local_code VARCHAR(100) NOT NULL,     -- kode dari SIMRS internal
    satusehat_code VARCHAR(100) NOT NULL,  -- kode SATUSEHAT/SNOMED
    satusehat_system VARCHAR(255),         -- system URI SNOMED/ICD-10, dll
    UNIQUE(domain, local_code)
);

Dengan tabel ini, setiap kali lo kirim data, lo tinggal JOIN atau lookup kode mapping-nya. Nggak perlu hardcode di kode aplikasi, dan kalau ada perubahan terminologi dari Kemenkes, lo cukup update tabel tanpa deploy ulang aplikasi. Satu catatan penting: mapping terminologi ini harus dimaintain secara berkala karena SATUSEHAT kadang update versi standar. Jadwalkan review mapping setiap bulan atau tiap ada rilis baru dari portal, biar nggak tiba-tiba kode SNOMED lo udah nggak berlaku dan data langsung kena reject.

3. Timeout dan Retry: Jangan Kirim Ulang Sembarangan

API SATUSEHAT kadang lemot, terutama pas jam banyak RS serentak kirim data (biasanya pagi hari pas klaim BPJS). Kalau lo pake timeout default 30 detik, siap-siap aja gagal terus. Beberapa tips:

  • Set timeout HTTP minimal 60 detik untuk endpoint SATUSEHAT.
  • Implement retry dengan exponential backoff: kalau gagal, tunggu 2 detik, lalu 4, lalu 8, maksimal 3 kali coba.
  • Jangan langsung retry kalau dapet HTTP 409 Conflict — itu artinya data udah ada, cek dulu resource ID-nya sebelum kirim ulang.
  • Simpan log setiap request beserta status code dan response body, biar lo bisa debug kalau ada data yang kelewat.

4. Validasi Data Sebelum Kirim

Jangan mengandalkan API SATUSEHAT buat validasi data lo. Validasi dulu dari sisi SIMRS sebelum ngirim. Data yang sering bikin reject:

  • NIK pasien kosong atau format salah (harus 16 digit).
  • Tanggal lahir nggak valid atau formatnya salah (SATUSEHAT pake ISO 8601: YYYY-MM-DD).
  • Diagnosa yang belum di-mapping ke ICD-10 — ini sering kejadian di RS yang dokter-nya nulis diagnosa bebas teks.

Bikin validasi pre-send yang ngecek semua mandatory field sebelum payload di-encode ke JSON. Ini ngehemat kuota retry dan nggak bikin antrian data lo numpuk karena bolak-balik kena reject.

5. Logging dan Monitoring yang Bisa Dibaca Manusia

Data SATUSEHAT itu banyak, dan kalau nggak dilogging dengan bener, lo bakal kesulitan tracking mana yang udah ke-kirim, mana yang gagal, dan mana yang masih antri. Gue rekomendasiin struktur log minimal:

  • Timestamp request dan response
  • Endpoint yang dipanggil
  • HTTP status code
  • Resource ID yang dikembalikan SATUSEHAT (simpan di database!)
  • Error message dari response body

Salah satu kesalahan fatal adalah nggak nyimpan resource ID yang dikembalikan SATUSEHAT setelah data berhasil dikirim. Resource ID itu lo butuhin kalau nanti mau update atau ngecek status data di portal SATUSEHAT. Simpan di tabel tersendiri atau di kolom tambahan di tabel pasien/diagnosa lo. Resource ID ini juga jadi bukti kalau data lo udah sampai dan diterima, yang suatu saat bisa nyelamatin lo pas audit.

Kalau lo udah punya log yang rapi, langkah selanjutnya bikin alert sederhana. Misalnya kalau ada 5 request gagal berturut-turut dalam 10 menit, kirim notifikasi ke Telegram atau Slack. Nggak perlu nunggu programmer ngecek dashboard setiap jam. Alert ini bikin lo tau duluan pas ada masalah, sebelum dokter atau kepala ruangan yang nanya "kenapa data SATUSEHAT nggak ke-kirim?"

Mulai dari Sekarang, Jangan Ditunda

Bridging SATUSEHAT emang pusing, tapi makin ditunda makin numpuk datanya. Mulai dari yang paling gampang: daftarin RS lo ke portal SATUSEHAT, dapatkan client ID dan secret, terus coba kirim satu data pasien dummy dulu. Begitu berhasil, baru deh lo scale secara bertahap. Kalau lo punya pengalaman, error konyol, atau trik soal bridging SATUSEHAT yang nggak ada di dokumentasi resmi, share di kolom komentar, Sobat AITI. Kita lebih butuh pengalaman lapangan daripada slide presentasi Kemenkes.