Rekonsiliasi Obat di RME: Tantangan Integrasi Farmasi & Rawat Inap

Rekonsiliasi Obat di RME: Tantangan Integrasi Farmasi & Rawat Inap

Pernah ngalamin pasien pindah ruang, resep berubah, eh entri obat di RME malah ngaco? Sering banget, Sobat IT RS. Apalagi kalau farmasi sama rawat inap masih kayak “dua dunia” — sistem nggak nyambung, data dobel, risiko salah kasih obat makin besar. Kepala IT sering dikomplain, “Pak, ini pasien sudah stop antibiotik kok di sistem masih muncul?” atau, “Kok di farmasi muncul dua kali order obat sama?”

Pokok e, interaksi obat yang salah itu bikin deg-degan. Dikit-dikit report ke IT, padahal akar masalahnya: integrasi data antara farmasi & rawat inap di RME (Rekam Medis Elektronik) masih njelimet. Bahaya bener kalau sampai ada pasien salah dapat obat gara-gara sistem IT nggak sinkron. Yuk, bedah bareng tantangan rekonsiliasi obat ini, plus tips teknis biar sistem lebih aman dan waras.

Kenapa Rekonsiliasi Obat Jadi Problem Kronis?

Rekonsiliasi obat artinya nyocokin semua obat yang dikonsumsi pasien — baik dari resep baru, obat bawa sendiri, maupun sisa yang terdahulu. Ini wajib, apalagi saat pasien:

  • Masuk rawat inap dari IGD atau poliklinik
  • Pindah antar ruang/ruang perawatan
  • Pulang dari RS (discharge)
  • Order obat berubah/revisi resep

Problemnya di SIMRS muncul karena:

  • Farmasi dan rawat inap sering pakai subsistem yang beda vendor atau belum satu database
  • Format data entri obat nggak seragam — kadang kode farmasi beda sama kode medis
  • Proses approval/review order obat masih manual
  • Interaksi perubahan (misal: revisi dosis, stop obat) nggak otomatis update ke semua modul

Contoh Kasus: Order Obat Ganda & Interaksi Obat Salah

Studi Kasus 1: Obat Ganda Karena Duplikasi Order

  • Pasien masuk rawat inap, dapat order antibiotik dari dokter A.
  • Dokter jaga revisi dosis di sistem rawat inap, tapi farmasi belum update order lama.
  • Farmasi terima dua entri: satu dosis lama, satu dosis baru. Sistem nggak auto-cancel order lama.
  • Farmasi racik dua kali — pasien hampir dapat dua kali dosis.

Fatal kalau nggak dicek manual. IT RS kena getahnya, dianggap “sistem error”.

Studi Kasus 2: Interaksi Obat Tidak Terdeteksi

  • Dokter order obat baru lewat EMR, misal antiinflamasi + antikoagulan.
  • Farmasi punya database interaksi obat, tapi sistem rawat inap nggak auto-check.
  • Obat diracik, interaksi bahaya tidak terdeteksi, pasien berisiko pendarahan.

Ini sering kejadian kalau farmasi dan rawat inap jalan sendiri-sendiri.

Struktur Data Obat: Wajib Sinkron!

Struktur Tabel Order Obat (Contoh di SIMRS)


-- Tabel order_obat di rawat inap
CREATE TABLE order_obat_rawat_inap (
  id_order SERIAL PRIMARY KEY,
  no_rm VARCHAR(20),
  tgl_order TIMESTAMP,
  kode_obat VARCHAR(20),
  nama_obat VARCHAR(255),
  dosis VARCHAR(50),
  frekuensi VARCHAR(20),
  route VARCHAR(20),
  status_order VARCHAR(20), -- aktif, stop, revisi, batal
  id_dokter INT,
  catatan TEXT
);

-- Tabel order_obat di farmasi
CREATE TABLE order_obat_farmasi (
  id_order_farmasi SERIAL PRIMARY KEY,
  id_order_rawat_inap INT,
  no_rm VARCHAR(20),
  kode_obat VARCHAR(20),
  tgl_order TIMESTAMP,
  dosis VARCHAR(50),
  status_farmasi VARCHAR(20), -- diterima, proses, selesai, batal
  id_farmasis INT,
  catatan TEXT
);

Perhatikan kolom id_order_rawat_inap di farmasi, ini kunci buat relasi ke order rawat inap. Kalau field ini kosong atau mapping salah, auto: chaos. Obat bisa double, status nggak nyambung.

Mapping Kode Obat

  • Pastikan master obat (tabel master_obat) satu sumber, baik di farmasi maupun rawat inap.
  • Minimal, pakai kode unik (id_obat/kode_obat) yang konsisten di semua modul.
  • Format: Kode Farmasi = Kode Medis = Kode Distribusi

-- Tabel master_obat (wajib shared)
CREATE TABLE master_obat (
  kode_obat VARCHAR(20) PRIMARY KEY,
  nama_obat VARCHAR(255),
  bentuk VARCHAR(30),
  satuan VARCHAR(10),
  kategori VARCHAR(30),
  aktif BOOLEAN
);

Kalau master obat beda-beda, order obat gagal konek. Kalau sudah begini, fix: migrasi dan mapping dulu sebelum ngomong integrasi module.

Rekonsiliasi: Workflow & Skenario Integrasi

Basic Workflow Integrasi Order Obat

  1. Dokter entry order obat di RME (rawat inap)
  2. Order terekam, status: aktif, dikirim ke farmasi (status: diterima)
  3. Farmasi proses, update status (proses/selesai/batal)
  4. Jika dokter revisi/stop obat, sistem auto-update semua order terkait di farmasi
  5. Farmasi cek interaksi obat otomatis sebelum racik (pakai DB interaksi)

Diagram Sederhana Integrasi


[Rawat Inap] --(order baru/revisi/stop)--> [Farmasi]
 [|]                                    [|]
 DB master_obat                DB master_obat
 [|]                                    [|]
[v]                                   [v]
Interaksi Cek            Notifikasi ke dokter/farmasi

SQL Query Rekonsiliasi Order Obat

Contoh Query: Cari Order Obat Ganda


-- Cek order ganda untuk pasien dan obat yang sama, status masih aktif
SELECT no_rm, kode_obat, COUNT(*)
FROM order_obat_rawat_inap
WHERE status_order = 'aktif'
GROUP BY no_rm, kode_obat
HAVING COUNT(*) > 1;

Cara manual deteksi order ganda. Bisa dijadwalkan sebagai job rutin, kirim notifikasi ke farmasi/IT kalau ada temuan.

Query: Daftar Obat Pasien, Status Terbaru


SELECT o.no_rm, o.kode_obat, m.nama_obat, o.dosis, o.status_order, f.status_farmasi
FROM order_obat_rawat_inap o
LEFT JOIN master_obat m ON o.kode_obat = m.kode_obat
LEFT JOIN order_obat_farmasi f ON f.id_order_rawat_inap = o.id_order
WHERE o.no_rm = '12345678'
ORDER BY o.tgl_order DESC;

Langsung monitor: status di rawat inap & farmasi harus sinkron. Kalau status_order sudah “stop” tapi status_farmasi masih “proses”, segera cek workflow.

Query: Cek Interaksi Obat Otomatis


-- Tabel interaksi_obat (farmasi)
CREATE TABLE interaksi_obat (
  kode_obat_1 VARCHAR(20),
  kode_obat_2 VARCHAR(20),
  risiko VARCHAR(100),
  level_risiko VARCHAR(20), -- minor, major, contraindicated
  catatan TEXT
);

-- Query cek interaksi antar semua obat aktif pasien
SELECT a.kode_obat AS obat1, b.kode_obat AS obat2, i.risiko, i.level_risiko
FROM order_obat_rawat_inap a
JOIN order_obat_rawat_inap b
  ON a.no_rm = b.no_rm
  AND a.id_order < b.id_order
  AND a.status_order = 'aktif'
  AND b.status_order = 'aktif'
JOIN interaksi_obat i
  ON a.kode_obat = i.kode_obat_1
  AND b.kode_obat = i.kode_obat_2
WHERE a.no_rm = '12345678';

Bisa diotomatisasi: saat dokter order/revisi obat, sistem langsung cek ke tabel interaksi, tampilkan warning sebelum order dikirim ke farmasi.

Antisipasi Human Error: Validasi & Notifikasi

Validasi Query di Backend

  • Prevent order obat duplikat untuk pasien yang sama, status aktif
  • Reject order revisi kalau status lama belum diubah
  • Wajib warning untuk interaksi obat berisiko tinggi
  • Log setiap perubahan (history) order obat

-- Validasi duplikat order (pseudo code)
IF EXISTS (
  SELECT 1 FROM order_obat_rawat_inap
  WHERE no_rm = :no_rm
    AND kode_obat = :kode_obat
    AND status_order = 'aktif'
)
THEN
  RAISE ERROR 'Order obat sudah ada dan masih aktif!'

Notif ke Farmasi & Dokter

  • Notif otomatis jika ada order obat baru, revisi, atau stop
  • Notif warning jika ditemukan interaksi obat major/contraindicated
  • Notif ke IT jika ada anomali status order (status tidak sinkron antar modul)

Jangan andalkan WA/manual — sistem harus ada push notification/inbox khusus di dashboard farmasi & rawat inap.

Audit Trail: Jejak Digital Order Obat

Audit trail itu wajib — biar gampang tracking kalau ada kasus “salah kasih obat”. Simpan history setiap perubahan order, siapa yang entry/edit/approve, timestamp, dan status lama vs baru.


-- Tabel history_order_obat
CREATE TABLE history_order_obat (
  id_history SERIAL PRIMARY KEY,
  id_order INT,
  aksi VARCHAR(20), -- entry, revisi, stop, batal, approve
  user_id INT,
  timestamp TIMESTAMP,
  old_status VARCHAR(20),
  new_status VARCHAR(20),
  catatan TEXT
);

Kalau pasien komplain, tinggal tarik history. Gampang tracking siapa “biang kerok”-nya, bukan cuma “sistem error”.

Integrasi API: Single Source of Truth Order Obat

Kalau SIMRS sudah modular/microservice: integrasi pakai API, satu endpoint order obat, farmasi & rawat inap subscribe ke event perubahan. Contoh endpoint:


POST /api/order-obat
{
  "no_rm": "12345678",
  "kode_obat": "AMX500",
  "dosis": "500 mg",
  "frekuensi": "3x1",
  "route": "oral",
  "status_order": "aktif",
  "user_id": 12,
  "catatan": "resep awal"
}

Setiap perubahan order dipublish ke topic “order_obat_update”, farmasi & rawat inap auto-sync status dan data. Kalau belum bisa full API, minimal: batch sync antar DB setiap beberapa menit (cron job), meski lebih rawan delay.

Best Practice Pengelolaan Rekonsiliasi Obat

  • Single master obat: semua modul pakai satu referensi master
  • Mapping order_id: setiap order obat punya ID unik, digunakan di semua modul
  • Auto update status order: perubahan di satu modul langsung update ke modul lain
  • Real-time interaksi cek: wajib warning kalau ada interaksi berbahaya
  • Uji workflow: lakukan simulasi pindah ruang, revisi, stop, discharge untuk cek konsistensi data
  • Audit trail aktif: log semua perubahan, pastikan traceable

Checklist Integrasi Rekonsiliasi Obat

  • Kode obat satu sumber?
  • Status order sinkron di farmasi & rawat inap?
  • Ada validasi order duplikat?
  • Sistem cek interaksi sebelum order dikirim?
  • Ada notifikasi anomali ke user terkait?
  • Audit trail on?

Kalau ada yang jawab “belum”, siap-siap sering “lembur gara-gara error order obat”.

Penutup: Fix Simple, Rawat Konsistensi Data

Masalah order obat bukan cuma urusan IT, tapi nyawa pasien bisa taruhannya. Seringkali solusi teknisnya nggak ribet: sinkronisasi data, validasi, notifikasi, audit trail. Jangan biarkan farmasi dan rawat inap kayak LDR — pastikan sistem IT mereka “ngobrol” tiap saat. Kalau perlu, bikin monitoring harian: cek order ganda, status tidak sinkron, interaksi obat major belum di-warning.

Intinya, Sobat IT RS, rekonsiliasi obat itu kerja bareng — modul farmasi, rawat inap, dokter, dan IT harus satu napas. Sistem solid, pasien aman, kepala IT tidur nyenyak. Jangan nunggu error baru gerak, audit struktur datamu sekarang!