Mengelola Master Data Pasien Biar Gak Dobel (Duplicate RM)

Sobat IT RS, siapa yang nggak pernah ngelus dada liat data pasien dobel di SIMRS? Laporan klaim BPJS mental, antrian ruangan kacau, kadang pasien sendiri bingung: “Lho pak, saya kok punya dua nomor rekam medis ya?” Nah, deduplikasi data pasien ini ngga bisa cuma ngandelin admin pendaftaran, kudu ada kerja cerdas di level database dan sistem. Yowes, mari kita bedah teknik-teknik deduplikasi master data pasien yang aman, efisien, dan tetap manusiawi.

Kali ini bahas tuntas: dari pola deteksi data ganda, query SQL pencarian duplikasi, sampai workflow merge rekam medis (RM) tanpa bikin IT RS darah tinggi. Langsung ke dalem, biar nggak njelimet di produksi.

Kenapa Data Pasien Sering Dobel?

• Input manual di front office: Operator ngetik data asal. Nama ketik 'Siti Aminah', besok masuk lagi jadi 'Siti Amina' tanpa 'h'.
• Kurang validasi: Sistem pendaftaran hanya cek NIK, no HP, nama persis. Padahal banyak pasien KTP-nya salah cetak/nomor berubah.
• SOP lemah: Petugas buru-buru, data lama nggak dicek, langsung bikin RM baru. Apalagi kalau pasien enggak bawa kartu RM lama.
• Pasien ganti identitas: Ada yang pulang kampung, nikah, ganti nama, update KTP, ganti alamat. Data baru masuk SIMRS, ternyata aslinya pasien lama.

Risiko RM Dobel di Rumah Sakit

• Klaim BPJS gagal, data kepesertaan conflict.
• Riwayat medis nyasar, dokter kaget lihat pasien 'sehat' ternyata punya DM kronis di RM lain.
• Audit akreditasi jeblok, indikator manajemen gagal.
• Duplicate file fisik di filing, storage dan tenaga admin makin babak belur.

Prinsip Deduplikasi Master Data Pasien

• Identifikasi entitas unik: satu pasien = satu RM, apapun variasi penulisan nama/identitas.
• Deteksi kemiripan: Nama, NIK, tanggal lahir, alamat, no HP, dan data keluarga.
• Validasi manual: IT bantu cari, operator verifikasi, baru merge data.
• Audit trail semua perubahan: Siapa merge, alasan, tanggal, backup data lama.

Struktur Tabel Master Pasien (Contoh SIMRS)

CREATE TABLE pasien (
  id SERIAL PRIMARY KEY,
  no_rm VARCHAR(20) UNIQUE,
  nama_lengkap VARCHAR(100),
  nik VARCHAR(16),
  tanggal_lahir DATE,
  alamat TEXT,
  no_hp VARCHAR(15),
  ibu_kandung VARCHAR(100),
  created_at TIMESTAMP,
  updated_at TIMESTAMP
);

Kunci utama: no_rm unik, tapi bisa terjadi ada data ganda dengan nama/nik/nama ibu mirip.

Langkah Deduplikasi Data Pasien

1. Deteksi Duplikasi dengan SQL

Pakai query SQL untuk cari data yang mirip. Contoh deteksi berdasarkan NIK:

SELECT nik, COUNT(*) as jumlah
FROM pasien
WHERE nik IS NOT NULL AND nik <> ''
GROUP BY nik
HAVING COUNT(*) > 1;

Output: daftar NIK yang muncul lebih sekali. Lanjut cek detail tiap NIK:

SELECT * FROM pasien WHERE nik = '3573012345678901';

Kalau NIK kosong/salah, bisa pakai kombinasi nama + tanggal lahir:

SELECT nama_lengkap, tanggal_lahir, COUNT(*) as jumlah
FROM pasien
GROUP BY LOWER(nama_lengkap), tanggal_lahir
HAVING COUNT(*) > 1;

2. Algoritma Fuzzy Matching Nama

Nama kadang beda spasi/typo. Pakai algoritma Levenshtein Distance di PostgreSQL:

SELECT a.id AS id1, b.id AS id2, a.nama_lengkap AS nama1, b.nama_lengkap AS nama2,
       levenshtein(lower(a.nama_lengkap), lower(b.nama_lengkap)) AS dist
FROM pasien a
JOIN pasien b ON a.id < b.id
WHERE a.tanggal_lahir = b.tanggal_lahir
  AND levenshtein(lower(a.nama_lengkap), lower(b.nama_lengkap)) <= 2;

Hasil: pasangan nama mirip (beda typo 1-2 huruf) dengan tanggal lahir sama. Kandidat kuat data dobel.

3. Cek Data Lain: Nama Ibu, No HP, Alamat

Gabungkan parameter lain untuk tingkatkan akurasi:

SELECT id, nama_lengkap, tanggal_lahir, ibu_kandung, no_hp
FROM pasien
WHERE tanggal_lahir = '1985-09-10'
  AND ibu_kandung ILIKE '%sumarni%'
  AND no_hp LIKE '%0812%'
ORDER BY nama_lengkap;

Workflow Merge Data Pasien

1. IT generate report kandidat dobel (kasih ke admin rekam medis).
2. Tim verifikasi fisik & digital (cek dokumen, kontak pasien jika perlu).
3. Pilih RM master (utamakan RM lama, atau yang sudah banyak kunjungan/riwayat).
4. Update foreign key di tabel transaksi (kunjungan, lab, farmasi, billing): arahkan ke RM master.
5. Backup data RM yang dihapus (arsip, jangan langsung drop).
6. Catat merge di log/audit trail (user, waktu, alasan).

Contoh Update Foreign Key Transaksi

UPDATE kunjungan
SET pasien_id = [id_master]
WHERE pasien_id = [id_duplicate];

Ulangi di semua tabel transaksi yang punya FK ke pasien. Wajib test dulu di staging, jangan langsung di production.

Backup Data Sebelum Merge

-- Backup RM yang akan dihapus
INSERT INTO pasien_deleted
SELECT * FROM pasien WHERE id = [id_duplicate];

Bisa juga: backup full tabel pasien sebelum merge besar-besaran.

-- Backup seluruh tabel
CREATE TABLE pasien_backup_202406 AS TABLE pasien;

Studi Kasus: Merge Data Pasien di RS Swasta

Di RS X, ditemukan 1500 NIK ganda, 3800 nama & tanggal lahir mirip, 120 kasus no RM sama, tapi data beda. Setelah audit:

• ~30% kasus: input NIK salah/typo, pasien sebenarnya beda.
• ~50%: pasien sama, RM double — admin terlalu cepat bikin RM baru karena data lama ‘susah dicari’.
• ~20%: pasien memang beda, tapi nama & tanggal lahir mirip (misal: nama umum seperti “Siti Aminah”).

Langkah:

1. Generate kandidat dobel pakai SQL (NIK, nama+tgl lahir, no HP).
2. Tim RM validasi ke pasien (WA/HP), cek dokumen fisik.
3. Merge RM ganda: update semua transaksi ke RM master, backup data lama, hapus RM duplikat.
4. SOP update: setiap daftar, cek NIK & nama-ibu minimal 3 parameter wajib match sebelum buat RM baru.

Impact: klaim BPJS naik 5%, komplain dokter turun, filing fisik lebih rapi, dan pasien nggak ribet tiap kontrol.

Best Practice: Pencegahan Data Dobel

• Form pendaftaran wajib validasi NIK, nama, tanggal lahir secara realtime sebelum simpan.
• Integrasi dengan Dukcapil (kalau bisa) untuk validasi NIK dan nama otomatis.
• Training admin front office: SOP, cara cari RM lama, komunikasi ke pasien.
• Rutin audit data master setiap bulan — IT generate report duplikasi, admin verifikasi.
• Audit trail di SIMRS: semua merge/dihapus log-nya jelas.

Contoh Validasi Front End: Cek NIK & Nama Sebelum Simpan

// Pseudocode, implementasi sesuaikan framework
function cekDuplikatPasien(nik, nama, tanggal_lahir) {
  // AJAX call ke API SIMRS
  $.get('/api/pasien/cek_duplikat', {nik, nama, tanggal_lahir}, function(data) {
    if (data.found) {
      alert('Data pasien sudah ada. Cek ulang, jangan buat RM baru.');
    }
  });
}

Pengalaman Lapangan: Kenapa Merge Manual Nggak Cukup

Dulu, merge manual setahun sekali. Kerasa? Nggak. Karena tiap bulan pasti ada saja pasien dobel baru. Kuncinya: otomasi deteksi + SOP ketat input data di front office. Di RS kecil, merge data bisa 100-an per bulan. RS besar bisa ribuan. Server pelan-pelan bengkak, user komplain SIMRS lemot, ternyata index tabel pasien gendut gara-gara duplikasi.

Pakai query hunting duplikasi otomatis, bikin dashboard deteksi harian. Sediakan tombol “merge” di aplikasi, bukan cuma di database. Semua perubahan log audit, biar aman pas audit eksternal.

Tips Santai Biar IT RS Nggak Tekor Waktu

• Automasi report duplikasi, kirim email/WA ke admin tiap minggu.
• Script batch update FK transaksi, sekali jalan clear 100 kasus.
• Kasih reward admin yang berhasil merge terbanyak, biar semangat verifikasi.
• Pakai field status “duplikat” sebelum data benar-benar dihapus, biar aman rollback.
• Tabel audit minimal: id, id_master, id_duplicate, user_merge, timestamp, alasan.

Penutup: Deduplikasi Itu Investasi

Master data pasien rapi = kerja tim lancar, SIMRS sehat, klaim BPJS mulus. Pokok e, jangan males hunting data dobel, jangan semuanya serahke admin. IT RS wajib fasilitasi, automasi, dan backup setiap aksi merge. Biar nggak kaget pas audit, dan pasien juga tenang tiap kontrol!