SatuSehat: Apa yang Perlu Diketahui Developer

Kalau Anda mengembangkan sistem informasi untuk klinik atau rumah sakit di Indonesia, cepat atau lambat Anda akan berhadapan dengan kebutuhan integrasi data kesehatan lintas fasilitas. Selama bertahun-tahun bekerja di sistem klinik dan rumah sakit, saya melihat sendiri bagaimana data pasien biasanya terkunci rapi di satu sistem, tapi nyaris tidak bisa "berbicara" dengan sistem fasilitas lain. Di sinilah konsep interoperabilitas data kesehatan nasional, yang di Indonesia direpresentasikan lewat platform SatuSehat, menjadi relevan buat kita sebagai developer.

Kenapa Interoperabilitas Itu Masalah Teknis yang Nyata

Secara historis, setiap vendor sistem rekam medis punya skema database sendiri, istilah sendiri, bahkan cara penomoran pasien sendiri. Ini bukan cuma soal beda nama kolom—ini soal beda model data secara fundamental. Satu sistem mungkin menyimpan diagnosis sebagai teks bebas, sistem lain memakai kode ICD-10, sistem lain lagi punya kombinasi keduanya dengan struktur yang berbeda.

Interoperabilitas mencoba menyelesaikan ini bukan dengan memaksa semua orang memakai database yang sama, melainkan dengan menyepakati format pertukaran data yang sama. Standar yang paling banyak dipakai secara global untuk ini adalah HL7 FHIR (Fast Healthcare Interoperability Resources), dan SatuSehat sebagai platform interoperabilitas nasional Indonesia dibangun di atas standar ini. Sebagai developer, ini artinya kita tidak perlu menciptakan format baru—kita perlu memahami resource FHIR yang relevan (seperti Patient, Encounter, Observation, Condition) dan bagaimana memetakan data internal aplikasi kita ke bentuk itu.

Apa yang Sebenarnya Perlu Disiapkan di Level Arsitektur

Dari sudut pandang praktis, ada beberapa hal yang biasanya perlu dipikirkan sejak awal, bukan ditempel belakangan:

  • Layer mapping/adapter terpisah. Jangan menaruh logika transformasi ke FHIR langsung di controller atau model utama. Buat lapisan tersendiri yang menerjemahkan entity internal (misalnya model Pasien di Laravel) ke resource FHIR yang sesuai. Ini memudahkan saat standar berubah versi—dan standar interoperabilitas memang cenderung berevolusi.
  • Autentikasi dan otorisasi berbasis OAuth2. Platform interoperabilitas kesehatan pada umumnya menggunakan alur OAuth2 client credentials untuk komunikasi server-to-server. Pastikan token disimpan dan di-refresh dengan aman, dan jangan pernah hardcode client secret di kode—simpan di environment variable atau secret manager.
  • Idempotency dan retry. Panggilan ke API eksternal bisa gagal karena banyak alasan—timeout jaringan, rate limit, atau downtime sesaat. Desain proses sinkronisasi data supaya aman diulang (idempotent), misalnya dengan job queue yang punya mekanisme retry dan backoff, bukan proses sinkron yang blocking di request-response cycle.
  • Validasi kode terminologi. Kode diagnosis, prosedur, atau obat perlu mengikuti sistem koding standar (ICD-10, ICD-9-CM, KFA/kode farmasi nasional, dan sejenisnya). Ini sering jadi sumber error paling besar karena data historis di sistem lama sering tidak konsisten atau memakai kode lokal yang perlu dipetakan dulu.

Pola Umum: Sinkronisasi Berkala vs Real-Time

Ada dua pendekatan umum yang biasa dipakai tim developer. Pertama, sinkronisasi berkala (batch), misalnya job terjadwal yang mengirim data kunjungan setiap beberapa jam. Ini lebih sederhana diimplementasikan dan lebih toleran terhadap gangguan jaringan sesaat, tapi ada jeda waktu sebelum data tersedia di sisi platform nasional. Kedua, event-driven, di mana setiap perubahan data (misalnya pasien baru terdaftar, atau kunjungan selesai) langsung memicu proses pengiriman melalui queue. Sebagai ilustrasi, pada sistem dengan volume kunjungan cukup tinggi, pendekatan event-driven dengan queue asynchronous biasanya lebih terasa manfaatnya dibanding polling database secara berkala—tapi ini bukan angka baku, sesuaikan dengan skala dan kebutuhan riil sistem Anda.

Yang penting dipegang dari awal: pisahkan proses bisnis inti aplikasi (pencatatan rekam medis, billing, dsb) dari proses integrasi ke platform eksternal. Kalau API eksternal sedang down, aplikasi utama Anda tetap harus bisa jalan normal—integrasi seharusnya bersifat tambahan, bukan dependency yang memblokir operasional.

Takeaway

Interoperabilitas data kesehatan bukan sekadar "hit API lalu selesai"—ini soal desain arsitektur yang memisahkan concern internal dan eksternal, menangani autentikasi dengan aman, dan membangun proses yang tahan terhadap kegagalan jaringan. Kalau Anda baru mulai eksplorasi FHIR dan SatuSehat, mulai dari membaca spesifikasi resource yang relevan dengan alur kerja Anda (biasanya Patient dan Encounter jadi titik awal yang baik), lalu bangun adapter layer sebelum menyentuh proses bisnis utama aplikasi.