Menjaga Komunikasi Positif Antara Programmer SIMRS dan Dokter Spesialis

Menjaga Komunikasi Positif Antara Programmer SIMRS dan Dokter Spesialis

Pernah nggak, Sobat IT RS, ngalamin situasi di mana request fitur dari dokter spesialis terdengar kayak mantra latin? Atau sebaliknya, dokter sampai geleng-geleng kepala karena jawaban kita yang “terlalu teknikal”? Yakin, hampir semua IT rumah sakit pasti pernah. Programmer SIMRS pusing translate istilah medis yang njelimet, dokter frustrasi karena fitur yang jadi nggak sesuai harapan. Akhirnya? Saling melempar "ini salah siapa, sih?"

Padahal, biang keroknya seringkali bukan di skill, tapi di komunikasi yang belum nyambung. Bahasa sehari-hari IT vs medis beda alam. Tapi kolaborasi lancar itu wajib, apalagi sistem informasi rumah sakit (SIMRS) makin vital buat layanan dan akreditasi. Yuk, bedah bareng cara jembatani gap komunikasi supaya fitur SIMRS beneran tepat guna, bukan hasil “permainan tebak-tebakan”.

Pola Umum Gesekan Programmer SIMRS vs Dokter Spesialis

1. Masalah Bahasa: Medis vs Informatika

  • Dokter: “Tolong tambahkan field ‘anamnesis’ yang bisa nyimpan keluhan utama dan riwayat penyakit sekarang.”
  • Programmer: “Field-nya string, atau butuh relasi ke tabel lain? Panjangnya fixed atau flexible? Perlu history tracking, nggak?”

Dokter ngomong proses klinis, programmer mikir struktur data. Dua-duanya logis, tapi kadang nggak nyambung kalau nggak dijembatani.

2. Ekspektasi Fitur vs Realita Teknis

  • Dokter: “Bikin ringkasan rekam medis otomatis, pokoknya tinggal klik langsung keluar!”
  • Programmer: “Data sumber masih manual, format antar poli beda, belum ada mapping kode diagnosis…”

Dokter maunya simple, programmer pusingin keruwetan data di lapangan.

3. Deadline Mendadak

  • Permintaan fitur sering muncul pas audit akreditasi, sidak Dinkes, atau revisi SOP dadakan.
  • Programmer di-brief dadakan, dokternya juga sering nggak sempat detailin spek.

Akibatnya, fitur kelar mepet deadline, testing kurang, bug muncul pas jam-jam kritis.

Cara Jitu Menjembatani Perbedaan Bahasa

1. Bangun Kamus Istilah Mini

  • Bikin file bersama (Google Sheet/Word) berisi istilah medis yang sering muncul di request dokter.
  • Terapkan istilah lokal yang familiar, misal: “Anamnesis” = “Data keluhan utama”, “SOAP” = “Ringkasan per poli”.
  • Tambahkan catatan: contoh isi data, tipe data, dan contoh tampilan di SIMRS.

Contoh struktur kamus istilah:

+-----------+------------------+-------------------+---------------------------+
| Istilah   | Penjelasan Medis | Penjelasan SIMRS  | Contoh                    |
+-----------+------------------+-------------------+---------------------------+
| SOAP      | Format SOAP      | Tabel soap        | Subjektif, Objektif,      |
|           | (rekam medis)    | (id, visit_id,    | Assesment, Plan di satu   |
|           |                  | s, o, a, p)       | form                      |
+-----------+------------------+-------------------+---------------------------+
| Anamnesis | Wawancara pasien | soap.s            | "Nyeri dada sejak 2 hari" |
+-----------+------------------+-------------------+---------------------------+

2. Workshop Bareng: Proses Translate Fitur

  • Jadwalkan sesi rutin (bisa 2 minggu sekali) bareng perwakilan dokter spesialis dan tim IT.
  • Cara jitu: gunakan mockup/bagan alur. Misal, sebelum ngoding, printscreen form atau wireframe, tempelkan kolom yg akan diisi dokter.
  • Praktikkan: setiap fitur baru, dokter jelaskan proses klinis, programmer tunjukin draft skema tabel/flow SIMRS, diskusi bareng sampe ketemu win-win.

Studi kasus nyata:

Pada RS X, fitur auto-summary rekam medis gagal dipakai karena hanya 15% dokter mengisi field “plan” di SOAP. Usul dokter: form “plan” terlalu teknis, lebih mudah kalau drop-down. Solusi: setelah workshop, IT revisi field jadi drop-down pilihan + kolom notes, compliance naik ke 80% dalam 2 minggu.

3. Prototyping Cepat: Mockup Bukan Coding Dulu

  • Jangan langsung coding permintaan fitur tanpa dummy/mockup.
  • Pakai tools gratis: Figma, Balsamiq, PowerPoint, atau bahkan kertas.
  • Biarkan dokter klik/lihat simulasi dulu, revisi di situ sebelum eksekusi ke sistem asli.

Contoh flow revisi fitur:

  1. Dokter request: “Butuh summary rawat jalan by poli per minggu.”
  2. Programmer bikin mockup simple (misal, tabel kolom: tanggal, diagnosis utama, terapi).
  3. Dokter review: “Kolom terapi sebaiknya editable, diagnosis utama ambil dari hasil lab.”
  4. Revisi mockup, baru setelah acc, lanjut coding.

Teknik Praktis Komunikasi: Dari Meeting Sampai Chat

1. Standup Meeting: 10 Menit Cukup

  • Meeting panjang sering bikin semua ngantuk dan nggak fokus. Cukup standup singkat: “Masalah, kendala, next step.”
  • Disiplin: setiap meeting, ada notulen singkat (1-2 kalimat per fitur), share ke WA grup, bukan cuma file formal yang nggak dibaca.

2. Chat/WA Group: Hindari “Ngomong Di Udara”

  • Kalau request fitur, minta dokter capture screenshot atau rekam video sekilas workflow di aplikasi lama/manual.
  • Programmer balas dengan diagram/flow yang mudah dipahami, misal: “Field diagnosis mau satu atau multi-entry?”
  • Semua diskusi fitur wajib diarsipkan (searchable), bukan hilang begitu saja setelah chat panjang.

3. Issue Tracker Sederhana

  • Bisa pakai Google Sheet, GitLab Issues, Trello, atau apapun yang mudah diakses semua pihak.
  • Setiap request fitur dicatat: siapa minta, deskripsi singkat, siapa develop, deadline, status, catatan revisi.
  • History perubahan fitur tercatat, gampang tracking dan audit. Dokter juga jadi lebih paham progress pengembangan.

Contoh template issue tracker:

| No | Fitur               | Requestor | Status   | Deadline  | Catatan           |
|----|---------------------|-----------|----------|-----------|-------------------|
| 1  | Ringkasan Medis     | dr. Budi  | On Dev   | 15/7/2024 | Draft wireframe    |
| 2  | Cetak Resume Pasien | dr. Sinta | Approved | 22/7/2024 | Selesai revisi     |
| 3  | Edit Input Lab      | dr. Agus  | Done     | 10/7/2024 | Perbaiki validasi  |

Kunci: Ubah Fitur Medis ke Spesifikasi Teknis, Bukan Cuma “Tahu Pokoknya Jadi”

1. Translate Proses Klinik ke Data Flow SIMRS

  • Mintalah dokter spesialis jelaskan alur klinis dalam bahasa sehari-hari.
  • Programmer gambar flow chart atau tabel input/output data.
  • Identifikasi variable penting: misal, “Diagnosis Primer”, “Therapy”, “Tindakan”, “Follow Up”.
  • Diskusikan: mana yang wajib diisi, mana yang optional, formatnya teks/numerik/dropdown, perlu validasi atau tidak.

Contoh flow chart sederhana:

[Registrasi Pasien] → [Input SOAP] → [Order Lab/Radiologi] → [Hasil Lab] → [Diagnosis] → [Rencana Terapi] → [Follow Up]

2. Contoh Struktur Tabel SIMRS untuk Data Rekam Medis

-- Struktur tabel "soap" (SQL Server)
CREATE TABLE soap (
  id INT IDENTITY(1,1) PRIMARY KEY,
  visit_id INT NOT NULL,
  s NVARCHAR(255), -- Subjektif: keluhan utama
  o NVARCHAR(255), -- Objektif: hasil pemeriksaan
  a NVARCHAR(255), -- Assessment: diagnosis
  p NVARCHAR(255), -- Plan: rencana terapi
  created_at DATETIME DEFAULT GETDATE(),
  updated_at DATETIME NULL
);

-- Struktur tabel "diagnosis"
CREATE TABLE diagnosis (
  id INT IDENTITY(1,1) PRIMARY KEY,
  soap_id INT NOT NULL,
  kode_icd10 NVARCHAR(20),
  deskripsi NVARCHAR(255),
  created_at DATETIME DEFAULT GETDATE()
);

Dengan tabel di atas, data SOAP bisa direlasikan ke diagnosis sesuai standar medis. Tapi harus jelas ke dokter bahwa “p” di tabel bukan hanya rencana, bisa juga notes tambahan, jadi perlu kompromi tampilan di aplikasi.

3. Contoh Query Monitoring Data Entry

  • Pakai query ini untuk pantau compliance dokter dalam mengisi data:
-- Query: Persentase SOAP terisi lengkap per dokter
SELECT
  dokter_id,
  COUNT(*) AS total_kunjungan,
  SUM(CASE WHEN s IS NOT NULL AND o IS NOT NULL AND a IS NOT NULL AND p IS NOT NULL THEN 1 ELSE 0 END) AS lengkap,
  (SUM(CASE WHEN s IS NOT NULL AND o IS NOT NULL AND a IS NOT NULL AND p IS NOT NULL THEN 1 ELSE 0 END) * 100.0
      / COUNT(*)) AS persentase_lengkap
FROM
  soap
GROUP BY
  dokter_id;

Data ini bisa jadi bahan diskusi bareng: dokter lihat kendala di lapangan, IT paham titik lemah interface/form SIMRS.

Jangan Lupa: Saling Hargai, Komplain Bukan Makian

  • Kalau ada bug/error, usahakan dokumentasi error/jam kejadiannya, bukan sekadar “tadi pagi errornya, pokoknya nggak bisa!”
  • IT harus sabar translate permintaan dokter, dokter juga belajar sedikit istilah teknis biar diskusi lebih nyambung.
  • Kalau sudah deadlock diskusi, minta user experience dari perawat/operator, supaya dapat sudut pandang lapangan.

Ringkasan Praktis (Checklist Kolaborasi Programmer & Dokter)

  • Buat kamus istilah bareng (Google Sheet, update berkala).
  • Setiap request fitur, wajib ada mockup/simulasi sebelum coding.
  • Catat request fitur di tracker bersama, status update rutin.
  • Diskusikan alur klinis → alur data (flowchart/tabel relasi).
  • Review bersama hasil jadi, open feedback dari user.
  • Jangan baper kalau revisi bolak-balik, proses ini wajar.
  • Jaga komunikasi: jangan terlalu teknis/medis, cari bahasa tengah.

Penutup: SIMRS Bukan Aplikasi Sakti, Kolaborasi Kuncinya

Sobat IT RS, SIMRS itu hidup dari interaksi manusia. Fitur canggih percuma kalau hasilnya nggak nyambung kebutuhan klinis. Programmer dan dokter spesialis harus saling belajar bahasa masing-masing. Perlahan, project SIMRS di RS jadi lebih tepat guna, minim drama, dan user beneran merasa dilibatkan. Kuncinya: komunikasi positif, sabar, dan jangan gengsi nanya. Pokok e, fitur SIMRS yang bener itu hasil gotong royong—bukan adu kuat siapa yang paling keras suaranya.