Cara Memantau Pengiriman SATUSEHAT Setiap Hari: Terkirim, Tertahan, Gagal | MedMinutes
Halaman bukti · Integration Hub

Memantau SATUSEHAT tiap hari: yang terkirim, yang tertahan, dan yang diam-diam berhenti.

Status “terhubung” tidak memberi tahu apa pun. Halaman ini menjelaskan empat angka yang wajib dibaca setiap hari, dua jebakan penghitungan yang membuat laporan terlihat benar padahal salah, dan bagaimana kami menjalankannya di lingkungan produksi.

Cek Kesiapan SATUSEHAT — 5 menit Bicara dengan Integration Specialist

Terdaftar di registry Penyedia Sistem RME SATUSEHAT Kemenkes (no. 250)

Praktik dan angka diambil dari satu fasilitas produksi, pembacaan 3 September 2026. Ditinjau ulang tiap bulan — peninjauan berikutnya paling lambat 11 Oktober 2026.

Jawaban singkat

Pemantauan harian pengiriman SATUSEHAT berarti membaca empat angka setiap pagi untuk periode 24 jam terakhir: berapa resource terkirim, berapa tertahan beserta sebabnya, berapa gagal beserta kode galatnya, dan berapa kunjungan yang berhasil dibaca dari SIMRS malam sebelumnya. Angka keempat itu yang paling sering dilewatkan, padahal dialah yang membedakan “rumah sakit sedang sepi” dari “pengambilan data gagal dan tidak ada yang tahu”. Di atas keempatnya berdiri satu angka berjangka panjang: berapa dari 18 jenis resource yang pernah terkirim sejak go-live. Angka jangka panjang dan angka 24 jam berasal dari sumber yang berbeda dan tidak boleh dibandingkan langsung.

Empat angka harian, beserta definisinya

Sebuah angka pemantauan tidak berguna tanpa penyebutnya. Kolom terakhir menyebutkan apa yang membuat angka itu berubah, karena di situlah tindakan diambil.

Definisi yang kami pakai di lingkungan produksi. Porsi diambil dari periode pengukuran 18–24 Agustus 2026 (±2.300 resource per hari).
Angka Artinya Porsi terukur Yang menggerakkannya
Terkirim Resource yang benar-benar jadi di SATUSEHAT dan punya identitas balik dari platform. 61,2% Volume kunjungan dan kelengkapan data hari itu.
Tertahan Sengaja belum dikirim karena prasyaratnya belum lengkap. Bukan kegagalan — tetapi juga bukan keberhasilan. 38,7% Kelengkapan data induk rumah sakit: identitas nakes, padanan terminologi, kode obat dan vaksin.
Gagal Ditolak platform dengan kode galat, setelah percobaan ulang habis. 0,09% Kesalahan struktur kiriman, token, atau tabrakan dengan pengirim lain.
Kunjungan terbaca Jumlah kunjungan rawat jalan, gawat darurat, dan rawat inap yang berhasil ditarik dari SIMRS pada sapuan malam. dilaporkan per jenis Kesehatan SIMRS dan jaringan. Nol di sini bukan berarti tidak ada pasien.

Geser tabel ke samping untuk melihat seluruh kolom.

17 / 18

Jenis resource pernah terkirim

Sejak go-live, tanpa filter waktu. Rinciannya di matriks resource.

±2.300

Resource per hari

16.266 dibagi 7 hari, 18–24 Agustus 2026, satu fasilitas.

50.000+

Kumulatif per 3 September 2026

Metode dan batasannya di halaman angka pengiriman.

Dua jebakan yang membuat laporan harian terlihat benar padahal salah

Keduanya kami alami sendiri, bukan hipotesis. Keduanya juga tidak memunculkan satu pun pesan galat — itulah yang membuatnya mahal.

Jebakan 1 — angka jangka panjang disandingkan dengan angka 24 jam

Gejala

Laporan menyebut “17 dari 18 jenis resource sudah terkirim”, tetapi rincian di bawahnya hanya memuat 12 baris. Pembaca menyimpulkan ada 5 jenis yang berhenti mengalir.

Penyebab

Dua angka menjawab dua pertanyaan berbeda. Cakupan dihitung sepanjang sejarah sejak go-live tanpa filter waktu; rincian dihitung untuk 24 jam terakhir. Selain itu ada empat resource turunan — obat, penyerahan obat, permintaan pemeriksaan, dan spesimen — yang dikirim di dalam pengiriman induknya sehingga tidak pernah memiliki baris antrean sendiri, dan karena itu tidak akan pernah muncul di rincian harian.

Tindakan

Rincian per jenis dipindahkan sumbernya ke catatan resource yang benar-benar jadi di SATUSEHAT, dan kalimat cakupan ditulis dengan rentang waktunya secara eksplisit lalu ditempatkan setelah rincian, bukan sebelum.

Ekor yang mahal

Begitu sumbernya dipindah, laporan sempat mencetak penanda internal — penanda bahwa sebuah kunjungan sudah ditutup — sebagai kalau-kalau jenis resource, dan ikut menggelembungkan angka judul dari 874 menjadi 1.341. Pelajarannya: tabel penanda idempotensi bukan daftar resource; apa pun yang dibaca dari sana untuk dilaporkan wajib disaring lewat daftar jenis resource yang sah.

Untuk pembeli

Minta vendor menyebutkan jendela waktu dan sumber di setiap angka laporan. Dua angka tanpa jendela waktu di satu halaman yang sama cepat atau lambat akan bertentangan.

Jebakan 2 — laporan berisi angka nol yang terbaca seolah rumah sakit berhenti

Gejala

Laporan pagi berbunyi “terkirim hari ini 2.816 rekam — dari 0 kunjungan, 0 rawat jalan, 0 gawat darurat, 0 rawat inap”. Dua angka dalam satu kalimat saling meniadakan.

Penyebab

Yang gagal adalah pembacaan kunjungan pada sapuan malam, bukan pengirimannya. Backend rumah sakit membalas galat server di tengah penelusuran halaman. Galat itu tidak masuk daftar galat sementara sehingga tidak pernah dicoba ulang, padahal ia hanya kelelahan sesaat. Lebih buruk lagi, tiga jenis kunjungan dipanggil berurutan tanpa penyekat: satu gagal membuat dua sisanya tidak pernah dijalankan. 2.816 rekam yang dilaporkan itu sisa antrean hari sebelumnya.

Tindakan

Galat server dimasukkan ke kelompok galat sementara dan ikut dicoba ulang dengan jeda bertingkat; setiap jenis kunjungan disekat sendiri; dan jejak sapuan disimpan sebagai catatan tersendiri sehingga laporan bisa membaca statusnya.

Bukti hasil

Laporan sekarang menolak berangkat ke penerima bila jejak sapuan menyatakan gagal: yang keluar adalah alarm ke kanal internal, bukan angka nol ke grup rumah sakit. Datanya sendiri tidak hilang — sapuan menyapu mundur beberapa hari, sehingga kunjungan yang terlewat menyusul pada sapuan berikutnya.

Untuk pembeli

Tanyakan satu hal ini: kalau pengambilan data dari SIMRS gagal semalam, apakah laporan pagi berhenti atau tetap terbit dengan angka nol? Laporan yang tetap terbit akan melatih semua orang mengabaikannya.

Ritme harian yang kami jalankan

Pemantauan bukan dasbor yang menunggu dibuka. Ia rangkaian pekerjaan berjadwal yang berakhir di layar orang yang bisa bertindak. Berikut urutan yang berjalan di satu fasilitas produksi.

Waktu Indonesia Barat. Pengiriman berjalan malam hari agar tidak berebut sumber daya dengan jam pelayanan.
WaktuYang berjalanKalau gagal
23:45 Sinkronisasi identitas tenaga kesehatan dari data induk rumah sakit ke identitas nasional. Catatan terkait nakes itu tertahan, tidak dikirim setengah jadi.
23:59 Sapuan pengiriman: membaca kunjungan yang sudah memenuhi syarat, menyusun resource, mengirim, mencatat hasilnya. Jejak sapuan menyimpan sebabnya; kunjungan yang terlewat disusul sapuan berikutnya.
Pagi Laporan internal ke kanal teknis kami: terkirim, tertahan per sebab, gagal per kode, dan status sapuan. Alarm ke kanal internal yang sama.
Pagi, hari kerja Laporan ke grup teknis rumah sakit, mengikuti kalender hari libur nasional. Tidak berangkat. Gagal-tertutup: kanal internal berbunyi, grup rumah sakit tidak disentuh.

Geser tabel ke samping untuk melihat seluruh kolom.

Tiga aturan isi laporan

  • Teksnya disusun di satu tempat. Kalau pengirim pesan menyusun angkanya sendiri, cepat atau lambat dua kanal melaporkan angka berbeda untuk hari yang sama dan tak ada yang tahu mana yang benar.
  • Pesan galat mentah tidak pernah dicetak. Laporan versi lama pernah memuat identitas pasien karena mencetak galat apa adanya; sebab kegagalan sekarang dikelompokkan di kueri, bukan disalin.
  • Kode diterjemahkan jadi nama. “Kode DU078 menahan 94 catatan” tidak bisa ditindaklanjuti; nama dokter yang bersangkutan bisa.

Yang pernah patah di sini

  • Jalur pengambilan laporan pernah mati dua hari karena akses jarak jauh ke server rumah sakit tertutup. Alarm bekerja dan grup rumah sakit tidak menerima angka palsu, tetapi laporannya memang tidak terbit. Jalurnya kemudian dipindah agar tidak lagi bergantung pada akses itu.
  • Pengiriman pertama laporan gagal karena bentuk kiriman ke gerbang pesan tidak sesuai, dan tidak ketahuan sehari sebelumnya karena pengujian dijalankan dalam mode kering — mode kering tidak pernah menyentuh gerbangnya, jadi tidak pernah membuktikan apa pun.
  • Balasan “sukses” dari sebuah antarmuka bukan bukti pesan sampai. Yang kami anggap bukti adalah status akhir di sisi penerima.

Tujuh pertanyaan untuk menguji pemantauan vendor mana pun

Termasuk kami. Jawaban yang tidak bisa ditunjukkan di layar dalam lima menit sebaiknya dianggap belum ada.

  1. Berapa kunjungan yang berhasil dibaca dari SIMRS semalam?

    Bukan berapa yang terkirim. Angka ini yang membedakan rumah sakit sepi dari pengambilan data yang mati.

  2. Apa lima sebab penahan terbesar hari ini, dengan jumlahnya?

    Daftar sebab tanpa jumlah tidak bisa diprioritaskan. Jumlah tanpa nama pemilik data tidak bisa ditindaklanjuti.

  3. Jendela waktu setiap angka di laporan ini apa?

    24 jam, sejak go-live, atau bulan berjalan. Dua angka berbeda jendela di satu paragraf adalah cacat, bukan gaya penulisan.

  4. Kalau sapuan gagal semalam, apa yang terjadi pada laporan pagi ini?

    Jawaban yang benar: tidak terbit, dan ada alarm. Jawaban yang salah: terbit dengan angka nol.

  5. Berapa yang gagal, dengan kode galatnya, dan sudah dicoba ulang berapa kali?

    Gagal permanen dan gagal sementara menuntut tindakan yang berbeda. Laporan yang menggabungkan keduanya menyembunyikan yang permanen.

  6. Dari 18 jenis resource, mana yang belum pernah terkirim sekali pun?

    Ini pertanyaan cakupan, bukan pertanyaan harian. Jawabannya harus menyebut jenisnya, bukan sekadar angka.

  7. Apakah laporan ini pernah mencetak data pasien?

    Pesan galat mentah dari platform bisa memuat identitas. Minta lihat contoh laporan hari ketika banyak kegagalan, bukan hari yang bersih.

Batas dari apa yang bisa kami buktikan

Metode

  • Angka porsi berasal dari periode 18–24 Agustus 2026, penyebutnya disebutkan di halaman angka pengiriman.
  • Kejadian diambil dari catatan operasional dan basis data pengiriman, bukan dari ingatan.
  • Perbaikan disebut selesai hanya bila terlihat dari efeknya di produksi — bukan karena kodenya sudah ditulis atau balasan antarmuka bernilai sukses.

Keterbatasan

  • Semua pengalaman di halaman ini berasal dari satu fasilitas produksi pada rentang waktu yang pendek.
  • Ritme jam di atas cocok untuk rumah sakit yang menerima pengiriman malam hari. Fasilitas dengan kebutuhan mendekati waktu nyata perlu rancangan berbeda.
  • Rincian teknis diringkas agar tidak mengungkap sistem maupun identitas fasilitas.

Halaman bukti

Error duplicate & data tertahan

Penyebab sebenarnya, dan mengapa menimpa data adalah tindakan yang tidak bisa ditarik.

Halaman bukti

Matriks kesiapan resource

Dukungan produk, bukti produksi, dan prasyarat fasilitas, per jenis resource.

Halaman bukti

Angka pengiriman produksi

Rata-rata harian, denominator, metode, dan tanggal pembaruan.

Hari ini, berapa data rumah sakit Anda yang tertahan?

Enam pertanyaan cukup untuk menebak penahan pertama Anda, dan jawabannya langsung terbaca tanpa menunggu tim kami.

Cek Kesiapan SATUSEHAT Kembali ke Integration Hub