Cara Konfigurasi Disposisi Surat Berjenjang di E-Office untuk RS dan Klinik

Surat menumpuk di meja sekretariat, sementara Kepala Instalasi mengira surat itu masih di Direktur, dan Direktur mengira sudah diteruskan ke Kabag. Kondisi ini jamak terjadi di rumah sakit dan klinik yang baru memindahkan surat fisik ke E-Office tanpa merancang alur disposisi berjenjang. Dari audit kecil di sebuah RS tipe C dengan 12 unit kerja di DIY, tercatat rata-rata 350 surat masuk per bulan, dan 41% di antaranya melewati SLA internal 3 hari kerja. Waktu tunggu rata-rata 4,7 hari, dengan titik tertinggi justru terjadi di level kedua, bukan level pertama. Akar masalahnya bukan aplikasinya, melainkan konfigurasi: disposisi dibuat satu level, tanpa relasi parent-child, tanpa tenggat per jenjang, dan tanpa eskalasi. Artikel ini membahas cara membangun disposisi surat berjenjang yang rapi di E-Office, dari struktur data sampai aturan eskalasi otomatis.

Konsep Disposisi Berjenjang dan Struktur Datanya

Disposisi satu level hanya menjawab pertanyaan "siapa yang membaca surat ini". Disposisi berjenjang menjawab "siapa menindaklanjuti apa, dalam urutan apa, dan dalam batas waktu berapa lama". Secara teknis, setiap lembar disposisi adalah satu baris data yang menunjuk ke baris disposisi sebelumnya melalui kolom parent_id. Rantai itulah yang membentuk jenjang: penerima awal membuat disposisi ke Kepala Unit (level 1), Kepala Unit meneruskan ke Kabag (level 2), Kabag meneruskan ke Direktur (level 3) dengan tembusan ke Komite Mutu.

Struktur tabel minimal yang perlu disiapkan pada MySQL 8 atau PostgreSQL 14 adalah disposisi(id, surat_id, parent_id, dari_jabatan_id, ke_jabatan_id, level, status, instruksi, deadline, selesai_at). Kolom level sebaiknya dihitung saat insert, bukan diinput manual, agar konsisten. Status memakai enumerasi yang jelas: baru, dibaca, diproses, selesai, ditolak, dan diteruskan. Tanpa status eksplisit, laporan kepatuhan disposisi akan selalu ambigu.

Satu hal yang sering terlewat: disposisi berjenjang bukan berarti wajib berurutan kaku. Di banyak E-Office, Direktur perlu menerima tembusan paralel tanpa memblokir alur di bawahnya. Karena itu pisahkan antara jalur approval (berurutan) dan tembusan (paralel, read-only). Simpan tembusan di tabel terpisah disposisi_tembusan(disposisi_id, jabatan_id) agar query rantai utama tetap bersih.

Sebagai gambaran, dari 350 surat per bulan, sekitar 60% cukup dua level, 30% tiga level, dan 10% melibatkan lintas unit (misalnya surat BPJS yang harus mampir ke Casemix, Keuangan, lalu Direktur). Konfigurasi yang baik memungkinkan ketiga pola ini hidup berdampingan tanpa duplikasi data.

Konfigurasi di Panel Admin E-Office: Langkah Praktis

Sebelum menyentuh menu disposisi, benahi dulu tiga master data yang menjadi fondasinya. Pertama, master jabatan — bedakan jabatan struktural (Kabag, Kepala Instalasi) dari jabatan fungsional (Dokter, Perawat, Apoteker). Kedua, master unit kerja dengan hierarki atasan-bawahan yang eksplisit. Ketiga, mapping user ke jabatan, karena satu orang di RS tipe C sering merangkap dua jabatan sekaligus. Tanpa mapping yang benar, routing rule akan mengarah ke user yang salah.

Langkah berikutnya adalah membuat routing rule berbasis klasifikasi surat, bukan berbasis nama pengirim. Contoh aturan nyata: klasifikasi "Surat Eksternal – Regulasi" selalu masuk ke level 1 Kepala Unit terkait, level 2 Kabag terkait, level 3 Direktur; sedangkan "Surat Internal – Undangan Rapat" hanya level 1 dan tembusan Sekretariat. Simpan aturan ini di tabel routing_rule(klasifikasi_id, urutan, jabatan_id, sla_jam, is_tembusan). Pendekatan tabel jauh lebih mudah diaudit dibanding logika kondisional yang ditanam di kode.

Setelah rule siap, tetapkan SLA per jenjang dan mekanisme delegasi. Rekomendasi praktis: level 1 mendapat 1 hari kerja (8 jam), level 2 mendapat 2 hari kerja (16 jam), level 3 mendapat 1 hari kerja. Delegasi wajib punya tanggal mulai dan berakhir — jangan gunakan delegasi permanen, karena audit BPJS dan akreditasi biasanya mempertanyakan siapa yang menandatangani pada tanggal tertentu. Terakhir, aktifkan notifikasi berlapis: email saat disposisi masuk, pengingat pada H-1 sebelum tenggat, dan eskalasi ke atasan langsung ketika tenggat terlewati.

Validasi Rantai Disposisi dengan Query Rekursif

Setelah konfigurasi berjalan, jangan langsung percaya pada tampilan UI. Validasi integritas rantai dengan query rekursif, karena masalah paling umum adalah disposisi yang parent_id-nya menunjuk ke surat berbeda, atau rantai yang putus di tengah sehingga surat berhenti tanpa status jelas. Jalankan query berikut pada salinan database sebelum go-live.

WITH RECURSIVE rantai AS (
  SELECT id, surat_id, parent_id, ke_jabatan_id, level, status, 1 AS urutan
  FROM disposisi WHERE surat_id = 1024 AND parent_id IS NULL
  UNION ALL
  SELECT d.id, d.surat_id, d.parent_id, d.ke_jabatan_id, d.level, d.status, r.urutan + 1
  FROM disposisi d JOIN rantai r ON d.parent_id = r.id
  WHERE d.surat_id = r.surat_id
)
SELECT urutan, level, ke_jabatan_id, status
FROM rantai ORDER BY urutan;

Jika hasilnya berhenti sebelum level terakhir yang diharapkan, berarti ada baris yang gagal dibuat — biasanya karena user pada jabatan tersebut sudah nonaktif. Untuk penjadwalan eskalasi, scheduler Laravel 10 (php artisan schedule:work) dengan job harian pukul 07.30 cukup memadai; hindari cron per menit yang membebani database E-Office yang biasanya berjalan satu server dengan SIMRS.

Best Practices

1. Hitung level dan deadline di aplikasi, jangan biarkan user mengisinya manual — sumber utama data kotor adalah input bebas.
2. Terapkan idempotensi pada pembuatan disposisi: satu surat hanya boleh punya satu root disposisi (parent_id IS NULL), dibatasi unique index.
3. Pisahkan jalur approval berurutan dari tembusan paralel ke tabel berbeda agar laporan SLA tidak terdistorsi.
4. Buat dashboard kepatuhan mingguan berisi jumlah disposisi melewati tenggat per unit, dan review di rapat manajemen.
5. Uji skenario negatif sebelum go-live: user resign di tengah rantai, delegasi kedaluwarsa, dan surat dengan dua klasifikasi sekaligus.

FAQ

Apakah disposisi berjenjang wajib berurutan ketat?

Tidak. Yang wajib berurutan hanya jalur approval. Tembusan, informasi, dan koordinasi sebaiknya paralel agar surat tidak tertahan hanya karena satu pihak belum membaca.

Berapa SLA ideal per level disposisi?

Untuk RS dan klinik, 8 jam untuk level 1, 16 jam untuk level 2, dan 8 jam untuk level 3 sudah realistis. Ukur dulu baseline 2 minggu sebelum menetapkan angka final.

Bagaimana menangani pejabat yang cuti atau mutasi?

Gunakan fitur delegasi berbatas tanggal, bukan penggantian user permanen. Saat mutasi, nonaktifkan mapping user-jabatan dan arahkan disposisi berjalan ke pejabat baru lewat proses realokasi.

Apakah konfigurasi ini bisa diterapkan pada E-Office versi lama?

Bisa, selama tabel disposisi masih dapat ditambah kolom parent_id, level, dan deadline. Jika tidak memungkinkan, buat tabel pendamping dan sinkronkan lewat trigger atau job terjadwal.

Konfigurasi disposisi berjenjang yang benar mengubah E-Office dari sekadar arsip digital menjadi alat kendali operasional: setiap surat punya pemilik, tenggat, dan jejak audit yang jelas. Jika tim IT Anda sedang menyiapkan E-Office, SIMRS, SIM Klinik, atau integrasi BPJS/SatuSehat dan butuh pendampingan teknis, kami melayani konsultasi IT dan pengembangan aplikasi untuk wilayah Yogyakarta (DIY) dan Magelang, Jawa Tengah — termasuk audit konfigurasi persuratan, perancangan routing rule, hingga implementasi eskalasi otomatis yang terintegrasi dengan sistem yang sudah berjalan.

Artikel ini bagian dari edukasi Nugroho Setiawan, konsultan IT Jogja. Solusi terkait: SIM Klinik Integrator Bridging BPJS & SatuSehat E-Office. Butuh konsultasi gratis?