Cara Membuat Laporan RL Rumah Sakit Otomatis dari SIMRS

Setiap awal bulan, tim rekam medis rumah sakit dengan 120 tempat tidur dan sekitar 18.000 kunjungan rawat jalan biasanya menghabiskan 4–6 hari kerja hanya untuk merekap laporan RL (Rumah Sakit) sebelum batas unggah ke e-SIRS tanggal 10. Data kunjungan ditarik manual dari SIMRS ke Excel, diagnosa ICD-10 disalin satu per satu, lalu angka BOR, LOS, dan TOI dihitung ulang dengan kalkulator. Hasilnya: laporan sering terlambat, angka tidak konsisten antar petugas, dan manajemen baru tahu ada lonjakan kunjungan poli setelah rapat bulanan. Padahal seluruh bahan mentahnya sudah ada di database SIMRS, hanya belum diolah otomatis. Artikel ini membahas cara membangun pipeline laporan RL otomatis dari SIMRS — mulai dari memetakan tabel, menulis query, memvalidasi, sampai menghasilkan file Excel siap unggah, dengan contoh kode yang bisa langsung dijalankan.

Kenapa Rekap Manual Laporan RL Selalu Jadi Bottleneck

Laporan RL bukan satu berkas, melainkan kumpulan form dengan definisi operasional berbeda: RL 1.1 (identitas RS), RL 2.1 (ketersediaan tempat tidur), RL 3.1 (data dasar), RL 4.1–4.3 (morbiditas rawat inap, rawat jalan, dan rawat darurat), serta RL 5.1–5.3 (kunjungan dan indikator rawat inap). Satu petugas yang mengerjakan semuanya secara manual hampir pasti akan memakai definisi berbeda di form yang berbeda, karena masing-masing form menuntut cara hitung yang tidak sama.

Contoh nyata yang sering terjadi: jumlah kunjungan rawat jalan dihitung dengan COUNT(DISTINCT no_rkm_medis). Cara ini membuat pasien kontrol yang datang tiga kali dalam sebulan hanya terhitung sekali, sehingga RL 5.1 kurang dari seharusnya. Sebaliknya, kalau semua baris registrasi dijumlahkan tanpa filter, kunjungan berstatus batal dan pasien yang pindah poli ikut terhitung. Padanan yang benar adalah menghitung nomor transaksi kunjungan yang sah, lalu menghitung pasien baru secara terpisah berdasarkan riwayat 6 bulan terakhir.

Masalah serupa muncul di indikator rawat inap. BOR dihitung dari hari perawatan dibagi (tempat tidur × jumlah hari dalam bulan). SIMRS menyimpan tanggal masuk dan keluar, tetapi laporan bulanan yang hanya memakai tanggal keluar akan salah total untuk pasien yang masuk 28 Januari dan pulang 3 Februari — hari rawatnya harus dipotong ke bulan masing-masing. Kesalahan sekecil ini membuat rekap manual tidak pernah benar-benar stabil dari bulan ke bulan.

Memetakan Sumber Data RL di Skema SIMRS

Pada SIMRS Khanza — yang paling banyak dipakai RS tipe C/D dan klinik di DIY — data inti tersimpan di MySQL/MariaDB pada tabel reg_periksa (kunjungan), pasien, poliklinik, diagnosa_pasien, prosedur_pasien, kamar_inap, kamar, bangsal, penjab, dan petugas. SIMRS komersial punya nama tabel berbeda, tetapi logikanya hampir selalu sama: ada tabel transaksi kunjungan, tabel diagnosa dengan penanda diagnosa utama, dan tabel kamar untuk rawat inap.

Tiga kolom wajib dipahami sebelum menulis query apa pun. status_lanjut membedakan Ralan dan Ranap; stts menandai kunjungan Sudah, Belum, atau Batal — baris Batal harus selalu dikecualikan. diagnosa_pasien.prioritas = 1 adalah diagnosa utama, sedangkan prioritas 2 dan seterusnya adalah diagnosa sekunder yang tidak boleh dipakai untuk RL 4.x. Untuk segmentasi penjamin (umum, BPJS, asuransi), ambil dari penjab.kd_pj.

Satu aturan arsitektur yang tidak boleh dilanggar: jangan pernah menjalankan query rekap berat langsung ke database produksi saat jam poliklinik. Buat replica read-only atau database staging yang diisi proses ETL harian pukul 01.00, lalu arahkan seluruh pelaporan ke sana. Ini menghindari tabel reg_periksa terkunci saat ribuan transaksi masuk pagi hari.

Membangun Pipeline Otomatis: View SQL, Validasi, Ekspor Excel

Pipeline minimal terdiri dari lima tahap: view SQL per form RL, script validasi, generator Excel sesuai template e-SIRS, arsip snapshot, dan proses unggah. Buat view bernama jelas seperti vw_rl51 dan vw_rl43, simpan definisinya di Git, dan perlakukan seperti kode aplikasi — bukan query ad-hoc di spreadsheet pribadi yang hanya dipahami satu orang.

Validasi adalah bagian yang paling sering dilewatkan. Empat aturan wajib: total kunjungan harus sama dengan jumlah nomor transaksi unik; total pasien keluar sama dengan pasien hidup ditambah pasien mati; tidak ada kode ICD-10 kosong (isi default Z00.0 atau tandai untuk koreksi); dan BOR harus berada di rentang 0–100 persen. Jika salah satu gagal, pipeline berhenti dan mengirim notifikasi, bukan menghasilkan angka yang salah.

Contoh berikut menarik data RL 5.1 dari Khanza menggunakan Python 3.12, pandas 2.2, SQLAlchemy 2.0, dan openpyxl 3.1:

import pandas as pd
from sqlalchemy import create_engine

engine = create_engine("mysql+pymysql://etl:rahasia@10.0.0.9/sik?charset=utf8mb4")
sql = """SELECT r.no_rawat, r.no_rkm_medis, r.kd_poli,
       COALESCE(d.kd_penyakit,'Z00.0') AS icd10
FROM reg_periksa r
LEFT JOIN diagnosa_pasien d ON d.no_rawat=r.no_rawat AND d.prioritas=1
WHERE r.status_lanjut='Ralan' AND r.stts='Sudah'
  AND r.tgl_registrasi BETWEEN :awal AND :akhir"""
df = pd.read_sql(sql, engine, params={"awal":"2025-01-01","akhir":"2025-01-31"})
df["pasien_baru"] = ~df["no_rkm_medis"].duplicated()
df.to_excel("RL51_2025-01.xlsx", index=False)

Setelah file terbentuk, simpan ke folder per periode dan catat hash SHA-256-nya sebagai bukti audit. Untuk unggah ke e-SIRS, perlu diketahui bahwa e-SIRS belum menyediakan API publik; otomasi penuh dengan Playwright 1.44 bisa dilakukan tetapi rapuh terhadap perubahan antarmuka. Pendekatan yang lebih aman adalah semi-otomatis: file Excel divalidasi otomatis, operator hanya menekan unggah.

Best Practices

1. Pisahkan setiap form RL ke view SQL bernama dan versikan di Git agar perubahan definisi bisa dilacak dan di-rollback.
2. Dokumentasikan data dictionary satu halaman: arti status_lanjut, stts, prioritas, dan kd_pj, plus pemetaan ICD-10 yang dipakai.
3. Buat user database khusus ETL dengan hak GRANT SELECT saja, dan simpan kredensial di environment variable, bukan hardcoded di script.
4. Lakukan parallel run 3 bulan: bandingkan hasil otomatis versus manual dengan target selisih 0 untuk kunjungan dan maksimal 0,5 persen untuk morbiditas sebelum mematikan proses lama.
5. Jadwalkan lewat cron atau systemd timer (misal 0 2 2 * *), simpan snapshot, dan kirim notifikasi email atau Telegram Bot API jika validasi gagal.

FAQ

Berapa lama implementasi otomasi laporan RL?

Untuk RL 4.x dan RL 5.x dengan satu SIMRS dan skema yang sudah dipahami, 2–4 minggu sudah cukup: satu minggu mapping dan view SQL, satu minggu validasi, dan dua minggu parallel run. Form dengan definisi rumit seperti indikator rawat inap biasanya butuh iterasi tambahan.

SIMRS saya closed-source dan vendor tidak memberi akses database, bagaimana?

Minta opsi export terjadwal ke CSV atau akses ke replica read-only. Jika benar-benar tertutup, bangun database pelaporan mandiri yang diisi dari file export harian, lalu jalankan pipeline yang sama di atasnya. Yang penting sumber angkanya tetap satu, bukan rekap ketikan tangan.

Apakah hasilnya bisa langsung terkirim ke e-SIRS?

Belum sepenuhnya. e-SIRS masih berbasis unggah berkas, jadi otomasi realistis berhenti pada file Excel yang sudah tervalidasi. Otomasi klik dengan browser automation bisa dicoba, tetapi biaya perawatannya tinggi setiap kali tampilan e-SIRS berubah.

Bagaimana keamanan data pasiennya?

Batasi kolom yang diekspor: laporan RL tidak membutuhkan nama dan NIK lengkap, cukup nomor rekam medis terenkripsi atau hash. Terapkan retensi berkas, akses berbasis peran, dan log siapa yang menghasilkan serta mengunduh berkas, sejalan dengan kewajiban UU PDP.

Otomasi laporan RL bukan proyek besar yang harus menunggu anggaran baru. Mulai dari satu form yang paling menyita waktu — biasanya RL 5.1 — buktikan selisihnya nol selama tiga bulan, lalu perluas ke RL 4.x dan indikator rawat inap. Jika tim internal Anda belum punya kapasitas untuk membangun pipeline ini, layanan konsultasi IT dan pengembangan aplikasi SIMRS, SIM Klinik, ERP, POS, serta website dari kami mencakup pendampingan teknis untuk rumah sakit dan klinik di Yogyakarta, DIY, dan Magelang, Jawa Tengah — termasuk audit skema database, pembuatan view pelaporan, dan pelatihan tim rekam medis.

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