Pahami batas antara administrasi lokal dan interoperabilitas
Profil dokter untuk jadwal, fee, booking, dan laporan lokal dapat berbeda kebutuhan dengan profil praktisi yang digunakan dalam komunikasi SATUSEHAT. Pemisahan tanggung jawab ini membantu klinik mengelola banyak dokter tanpa mengubah identitas praktisi yang telah dipasangkan untuk pertukaran data.
Data lokal tetap menjadi sumber operasional harian. SATUSEHAT menerima representasi klinis sesuai resource dan kontrak API yang berlaku, bukan seluruh struktur internal aplikasi.
Siapkan identitas utama
- Identitas organisasi atau fasilitas sesuai akun dan konfigurasi integrasi.
- Identitas praktisi yang telah dipetakan dengan benar.
- Pasien memiliki NIK valid ketika diwajibkan untuk pencarian IHS.
- Nama, tanggal lahir, jenis kelamin, dan alamat tidak saling bertentangan.
- ID hasil pencarian disimpan terisolasi per entitas dan tidak digunakan lintas pasien.
Pencarian pasien sebaiknya memiliki antrean kerja dan retry yang aman. Jangan mengirim ratusan permintaan sekaligus. Simpan status per pasien agar kegagalan dapat dilanjutkan tanpa mengulang semua proses.
Pastikan encounter memiliki konteks
Resource klinis memerlukan hubungan yang jelas dengan pasien, organisasi, praktisi, dan encounter. Catatan SOAP atau diagnosis saja tidak cukup apabila konteks kunjungan belum terbentuk. Sistem harus mengetahui kapan episode pelayanan dimulai, statusnya, dan kapan diselesaikan.
Untuk alur khusus seperti kehamilan, rawat inap, atau pelayanan gigi, jangan menerapkan nilai default dari alur lain. Mapping generik perlu memiliki guardrail agar resource tidak membawa konteks klinis yang salah.
Gunakan orkestrasi yang idempotent
Setiap langkah pengiriman perlu menyimpan identifier lokal, identifier SATUSEHAT, status respons, waktu, dan error yang aman untuk ditampilkan. Idempotensi mencegah resource ganda ketika jaringan putus setelah server menerima request tetapi aplikasi belum menerima respons.
- Bentuk payload dari snapshot data yang sudah divalidasi.
- Cari identifier remote yang pernah tersimpan.
- Lakukan create atau update sesuai keadaan.
- Simpan respons dan relasinya dalam transaksi lokal.
- Masukkan kegagalan sementara ke retry queue dengan batas percobaan.
Jangan samakan “API merespons” dengan “data klinis selesai”
Pemeriksaan GET atau validasi token hanya membuktikan konektivitas. Keberhasilan klinis perlu dibuktikan melalui resource yang benar-benar tercipta, saling terhubung, dan dapat ditelusuri kembali ke encounter lokal.
Monitor secara operasional
Buat dashboard status yang membedakan belum siap, siap dikirim, terkirim, perlu koreksi data, dan gagal sementara. Tampilkan pesan yang dapat ditindaklanjuti tanpa membocorkan credential atau payload pasien ke log umum.