Konsep inti

Model asinkron

Satu kunjungan menjadi rantai resource FHIR yang dikirim berurutan. Karena itu pengiriman diterima lebih dulu (202) lalu diproses di latar belakang.

Kirim

POST /v1/satusehat/kunjungan
→ 202 { "request_id": "01J9F3K2M7QX1041G8T5ZC3B0N",
        "status": "pending" }

Periksa

GET /v1/satusehat/kunjungan/01J9F3K2M7QX1041G8T5ZC3B0N
→ 200 { "status": "partial", "retry_scheduled": false,
        "resources": [ … ] }

status dan retry_scheduled menjawab pertanyaan berbeda

status menjawab "seberapa jauh rantai berjalan". retry_scheduled menjawab "apakah gateway akan mencoba lagi". Membaca salah satunya saja adalah sumber kesalahan integrasi paling umum di sistem ini.

complete

retry_scheduled: false

Seluruh rantai masuk. Selesai.

Tidak perlu tindakan.

partial

retry_scheduled: true

Sebagian resource masuk, sisanya akan dicoba lagi otomatis.

Tunggu. Jangan kirim ulang.

partial

retry_scheduled: false

Sebagian resource masuk, sisanya tidak akan terkirim tanpa tindakan.

Butuh manusia. Perbaiki data lalu jalankan ulang.

failed

retry_scheduled: false

Rantai berhenti sebelum ada resource yang masuk.

Perbaiki payload lalu kirim ulang.

Dua request_id yang berbeda

meta.request_id berawalan req_ dan menandai satu panggilan HTTP — pakai itu saat menghubungi dukungan. data.request_id adalah ULID tanpa awalan dan menandai pekerjaan kunjungan yang berjalan di latar belakang — itu yang disimpan di SIMRS dan dipakai untuk memeriksa status.