Rekam Medis Elektronik: Konsep Dasar bagi Engineer

Saat pertama kali diminta membangun modul rekam medis, saya kira ini cuma soal bikin form input lalu simpan ke database. Ternyata rekam medis elektronik (RME) punya struktur khas yang kalau dipahami sejak awal, akan sangat memudahkan hidup saya sebagai engineer—dan kalau salah dimodelkan, akan jadi utang teknis yang menyakitkan bertahun-tahun ke depan. Tulisan ini saya tulis dari sudut pandang orang yang membangun sistemnya, bukan yang memakainya sehari-hari sebagai tenaga medis.

Yang membuat RME berbeda dari sistem transaksional biasa adalah sifat datanya: satu kunjungan pasien menghasilkan data yang sangat heterogen—narasi bebas, kode terstandar, angka vital, dan relasi antar-entitas yang saling bergantung. Kalau kita perlakukan semua itu seperti tabel invoice biasa, sistem akan cepat rapuh saat kebutuhan pelaporan atau interoperabilitas (misalnya integrasi dengan BPJS atau SATUSEHAT) mulai masuk.

Struktur SOAP: Kenapa Formatnya Begitu

SOAP—Subjective, Objective, Assessment, Plan—adalah format dokumentasi klinis yang sudah dipakai puluhan tahun sebelum ada sistem digital. Sebagai engineer, saya tidak perlu mengubah cara dokter berpikir; tugas saya memetakan pola pikir itu ke struktur data yang masuk akal.

• Subjective: keluhan pasien, biasanya teks bebas. Saya biasanya simpan ini sebagai kolom teks panjang, bukan dipecah-pecah paksa jadi field terstruktur—karena memaksakan struktur di sini justru menghilangkan nuansa klinis yang penting.
• Objective: hasil pemeriksaan fisik, tanda vital, hasil lab. Bagian ini jauh lebih cocok distrukturkan, karena nilainya numerik dan berulang (tekanan darah, suhu, dsb), sehingga enak dipakai untuk tren dan grafik.
• Assessment: kesimpulan diagnosis dokter. Di sinilah kode diagnosis masuk.
• Plan: rencana tindakan, resep, atau rujukan.

Kalau dimodelkan secara sederhana, satu kunjungan (encounter) menjadi entitas induk, dan keempat komponen SOAP menjadi child record yang berelasi ke encounter tersebut—bukan kolom-kolom di satu tabel lebar.

Diagnosis: Kenapa Harus Terkode, Bukan Teks Bebas

Bagian yang paling sering diremehkan engineer baru di domain ini adalah diagnosis. Dokter menulis diagnosis dalam bahasa natural, tapi sistem yang baik wajib memetakannya ke kode standar seperti ICD-10. Alasannya bukan birokrasi semata: kode terstandar inilah yang memungkinkan agregasi data lintas fasilitas, klaim asuransi, dan analitik epidemiologi berjalan konsisten.

Dari sisi desain data, ini berarti tabel diagnosis idealnya menyimpan dua hal sekaligus: teks asli yang ditulis dokter (untuk audit dan konteks klinis), dan kode terstandar hasil pemetaan (untuk pelaporan). Saya juga selalu membedakan diagnosis utama dan diagnosis sekunder sebagai atribut eksplisit, karena keduanya punya implikasi berbeda untuk klaim dan statistik—kalau digabung jadi satu daftar tanpa penanda, laporan turunannya akan sulit diverifikasi.

Tindakan/Prosedur: Relasi Many-to-Many yang Sering Terlewat

Tindakan medis (prosedur, tindakan penunjang, obat yang diberikan) hampir selalu berelasi many-to-many dengan encounter: satu kunjungan bisa punya banyak tindakan, dan satu jenis tindakan dipakai di banyak kunjungan berbeda. Di sinilah saya sering melihat desain pemula terjebak—menyimpan tindakan sebagai kolom teks di tabel kunjungan, alih-alih tabel pivot dengan kode tindakan standar (semacam ICD-9-CM untuk prosedur).

Praktik yang saya pegang: setiap tindakan punya kode, biaya, dan status (direncanakan, dikerjakan, dibatalkan) sebagai record terpisah yang terhubung ke encounter—bukan sekadar deskripsi bebas.

Yang Saya Bawa Pulang

Intinya sederhana: rekam medis elektronik itu perkawinan antara narasi klinis yang perlu tetap bebas dan longgar, dengan data terstruktur yang perlu konsisten dan terkode. Tugas kita sebagai engineer bukan memaksakan semuanya jadi struktur kaku, tapi mengenali bagian mana yang butuh fleksibilitas dan bagian mana yang butuh standardisasi—lalu memodelkan relasi antar-entitasnya (encounter, diagnosis, tindakan) dengan jujur sesuai realitas klinisnya, bukan sesuai kemudahan skema database semata.