Audit Log Akses Rekam Medis: Siapa Saja yang Mengintip Data Pasien?

Audit Log Akses Rekam Medis: Siapa Saja yang Mengintip Data Pasien?

Sobat IT RS, siapa nih yang pernah kebagian tugas investigasi akses "aneh-aneh" ke rekam medis? Kadang-kadang, ada dokter atau perawat nyasar akses RME pasien dari ruangan lain, padahal mereka enggak ada urusan di situ. Atau malah, bagian administrasi tiba-tiba buka-buka detail pasien rawat inap, padahal jatahnya cuma lihat administrasi doang. Kalau sudah begini, kepala IT kayak kita pasti langsung kena telpon, "Tolong dicek ya, siapa yang buka data pasien ini!".

Masalah audit log akses RME ini memang sering bikin darah tinggi. Apalagi kalau RS sudah akreditasi MRMIK—semua harus bisa ditelusuri dengan detail: siapa, kapan, buka data pasien mana, dari mana, alasannya apa. Nah, kali ini MinTIRS mau kupas tuntas cara bikin dashboard investigasi anomali akses RME, biar Sobat IT RS bisa cepat deteksi siapa saja yang mengintip data pasien tanpa hak.

Kenapa Audit Log Akses RME Penting Banget?

  • Regulasi & Akreditasi: Standar MRMIK, Peraturan Menteri Kesehatan, sampai aturan BPJS: semua wajib ada log akses yang bisa ditelusuri.
  • Keamanan Data: Lindungi privasi pasien. Jangan sampai data jatuh ke tangan orang yang tidak berwenang.
  • Respons Insiden: Kalau ada kebocoran/investigasi, musti bisa buktikan siapa yang akses data.
  • Audit Internal & Eksternal: Tim audit pasti nanya, "Mana log aksesnya?" Kalau enggak bisa jawab, siap-siap disemprit.

Pondasi: Struktur Tabel Audit Log Akses RME

Sebelum mikir dashboard, pastikan DB sudah simpan log akses dengan struktur yang cukup detail. Minimal, log harus simpan:

  • user_id / username staf
  • timestamp akses
  • action (baca, edit, cetak, hapus, dsb)
  • patient_id (ID pasien yang diakses)
  • source / location (ruangan, workstation, IP, dsb)
  • reason / catatan (jika ada)

Contoh struktur tabel di SQL Server: 


CREATE TABLE audit_log_rme (
  id INT IDENTITY PRIMARY KEY,
  user_id VARCHAR(50),
  access_time DATETIME NOT NULL,
  action VARCHAR(20),
  patient_id VARCHAR(30),
  source_room VARCHAR(20),
  source_ip VARCHAR(20),
  reason VARCHAR(255),
  extra_info JSON
);

Pakai extra_info (tipe JSON) buat simpan data lain, kayak browser, device, dsb. Ponytail: Untuk versi PostgreSQL, pakai jsonb.

Strategi Deteksi Anomali Akses: Siapa yang Ngintip?

Inti masalah: Bagaimana tahu seorang staf akses data pasien yang bukan dari ruangan/area tugasnya?

Langkah 1 - Mapping Staf ke Ruangan Tugas

Bikin tabel mapping: siapa tugas di ruangan mana. Contoh tabel: 


CREATE TABLE staff_ruangan (
  user_id VARCHAR(50),
  kode_ruangan VARCHAR(20),
  tanggal_mulai DATE,
  tanggal_selesai DATE
);
  • Bisa update otomatis (jadwal shift) atau manual (HRD).
  • Kalau staf rotasi, update tanggal mulai/selesai.

Langkah 2 - Analisa Log: Cek Kesesuaian Ruangan

Query cari akses di luar ruangan tugas: 


SELECT 
  l.id,
  l.user_id,
  l.patient_id,
  l.access_time,
  l.source_room,
  s.kode_ruangan AS ruang_tugas
FROM 
  audit_log_rme l
LEFT JOIN 
  staff_ruangan s
  ON l.user_id = s.user_id
     AND l.access_time BETWEEN s.tanggal_mulai AND s.tanggal_selesai
WHERE 
  l.source_room  s.kode_ruangan
  AND l.action = 'baca'
ORDER BY l.access_time DESC;
  • Query ini deteksi akses "aneh": user akses dari ruangan yang bukan area tugas di waktunya.
  • Bisa tambahkan filter AND l.patient_id = 'pasien_spesifik' atau tanggal tertentu.

Dashboard Investigasi Anomali: Komponen Wajib

  • Filter waktu: Pilih range tanggal/jam.
  • Pilih staf/ruangan: Fokus investigasi ke user/area tertentu.
  • List anomali akses: Tampilkan tabel: user, ruangan tugas, ruangan akses, pasien, waktu, action.
  • Export/Download: Untuk bukti audit atau dikirim ke manajemen/SPI.

Contoh layout dashboard (tanpa gambar, format HTML): 



  Rentang Waktu
   - 
  User
  ...
  Ruangan
  ...
  Cari Anomali



  
    Tanggal/Jam
    User
    Ruang Tugas
    Ruang Akses
    Pasien
    Action
    Alasan

Pakai framework dashboard open source kayak Metabase atau Superset biar enggak bikin dari nol. Connect ke DB, buat SQL View dari query anomali, publish di dashboard.

Studi Kasus: Investigasi Akses RME Tanpa Hak

Kasus nyata di RS kelas C: Kepala ruangan lapor, ada pasien VIP yang datanya diakses oleh staf administrasi pendaftaran, padahal pasien sedang dirawat inap. Investigasi pakai audit log.

  1. Cek log: Filter action = 'baca', patient_id = 'ID pasien'.
  2. Dapat list user yang akses, waktu, ruangan akses.
  3. Cross-check user ke tabel staff_ruangan dan jadwal shift.
  4. Ditemukan: User admin pendaftaran buka RME pasien jam 22.00, padahal shift dan ruangannya beda.
  5. Hasil investigasi: User mengaku iseng/penasaran, belum ada mekanisme blokir otomatis.
  6. Tindak lanjut: Blokir akses, peringatan ke user, edukasi ulang, update SOP akses RME.

Audit log jadi kunci untuk membuktikan siapa melakukan apa, kapan, dari mana.

Peningkatan: Blokir & Notifikasi Otomatis Anomali

  • Trigger/Rule di Backend: Tambahkan trigger di app/DB, kalau ada akses di luar ruangan tugas, langsung log peringatan atau kirim notifikasi ke supervisor/IT.
  • Soft Lock: Bisa tambahkan rule: kalau user akses >X kali di luar ruangan dalam periode tertentu, blokir otomatis dan minta klarifikasi.
  • Email/WA Notif: Integrasi dengan modul notifikasi, kirim alert ke manajer tiap kali anomali dideteksi.

Contoh pseudo-code trigger (di aplikasi/DB): 


IF akses.user_id NOT IN (
  SELECT user_id FROM staff_ruangan
  WHERE kode_ruangan = akses.source_room
    AND akses.access_time BETWEEN tanggal_mulai AND tanggal_selesai
)
THEN
  INSERT INTO audit_alert_log (...)
  -- Kirim notif ke admin
END IF

Tips Praktis: Maintenance & Validasi Audit Log

  • Pastikan log tidak bisa dihapus user biasa: Tabel audit wajib readonly, hanya bisa diakses admin/security officer.
  • Backup log berkala: Jangan sampai log hilang karena rotasi DB atau disk penuh. Simpan arsip di storage terpisah/enkripsi.
  • Validasi integritas: Cek ada gap/injeksi/penghapusan log. Gunakan checksum atau append-only logs (WORM storage kalau serius banget).
  • Rotate & purge log lama: Untuk RS besar, log bisa makan storage. Rajin purge yang lebih dari 5 tahun (atau sesuai regulasi). Arsip offline dulu sebelum hapus.

Catatan Penting: Keterbatasan & Skema Ideal

  • Mapping staff-ruangan harus selalu up-to-date: Kalau mapping ngaco, dashboard anomali juga salah deteksi.
  • Shift dadakan, tugas emergency: Kadang-kadang staf akses di luar ruangan tugas karena emergency/shift tambahan. Harus siapkan field reason dan SOP input alasan.
  • Device sharing: Ruangan sering gonta-ganti PC, kadang workstation dipakai ramai-ramai. Idealnya, enforce login per-user + log IP/MAC/device ID.

Performa Dashboard: Hindari Query Berat

Kalau log sudah jutaan baris, query anomali bisa bikin server DB megap-megap. Tips:

  • Indexing: Index di kolom user_id, access_time, source_room.
  • Partitioning: Bagi tabel berdasarkan bulan/tahun.
  • Materialized View: Untuk query yang sering dipakai, buat materialized view, refresh per jam/hari.

Contoh index di SQL Server: 


CREATE INDEX idx_audit_user_time ON audit_log_rme (user_id, access_time);
CREATE INDEX idx_audit_room ON audit_log_rme (source_room);

Ponytail: Untuk scale ke miliaran log, pertimbangkan ELK Stack (Elasticsearch/Logstash/Kibana) atau SIEM, tapi butuh resource lebih.

Checklist Implementasi Dashboard Audit Log RME

  • Tabel audit lengkap (user, waktu, ruangan, action, pasien)
  • Mapping staff ke ruangan & shift update real-time
  • SQL View/query deteksi anomali akses
  • Dashboard filter: tanggal, user, ruangan, pasien
  • Export/printout hasil investigasi
  • Maintenance backup & integritas log
  • SOP tindak lanjut anomali akses

Penutup: Audit Log, Tameng IT RS dari Kebocoran Data

Audit log akses RME bukan cuma formalitas compliance, tapi tameng utama privasi data pasien di RS. Bikin dashboard investigasi anomali akses itu wajib, bukan pilihan. Dengan log yang lengkap, mapping staff yang update, dan dashboard yang user friendly, tim IT bisa cepat deteksi kalau ada "pengintip" data pasien yang enggak berhak. Bukan cuma buat jaga-jaga kalau ditanya auditor, tapi juga buat melindungi RS dari masalah hukum dan reputasi. Pokok e, jangan sampai kecolongan. Semoga tips di atas bisa langsung dipraktikkan Sobat IT RS. Kalau ada studi kasus atau skrip query lain yang mau didiskusikan, tulis di kolom komentar atau langsung japri MinTIRS!