Tantangan Coding Medis bagi Software Engineer

Kalau Anda software engineer yang baru masuk ke dunia sistem informasi rumah sakit atau klinik, cepat atau lambat Anda akan ketemu istilah "coding medis" — proses menerjemahkan diagnosis dan tindakan dokter menjadi kode standar seperti ICD-10 atau ICD-9-CM, yang lalu dipakai untuk klaim asuransi, statistik, sampai pelaporan ke regulator. Bagi engineer yang terbiasa berpikir dalam if-else dan lookup table, godaan pertama biasanya sama: "ini kan tinggal mapping teks ke kode, gampang, tinggal bikin sistem otomatis." Saya pernah berpikir begitu, dan butuh waktu untuk sadar kenapa asumsi itu keliru.

Tulisan ini saya buat untuk berbagi kenapa domain coding medis termasuk salah satu area yang paling resisten terhadap otomasi penuh, meski secara teknologi kita punya NLP dan LLM yang makin canggih.

Ambiguitas klinis itu bukan bug, tapi sifat dasar domain

Dalam software biasa, satu input idealnya punya satu output yang benar. Dalam rekam medis, satu catatan dokter bisa punya beberapa interpretasi yang sama-sama valid secara klinis, tapi berbeda kode. Contohnya, catatan "nyeri dada, curiga jantung" bisa dikode sebagai gejala (nyeri dada) atau sebagai kecurigaan diagnosis, tergantung konteks pemeriksaan lanjutan yang kadang tidak tertulis eksplisit di catatan itu sendiri. Dokter menulis untuk dokter lain, bukan untuk parser. Singkatan, istilah lokal, dan asumsi konteks klinis yang "sudah jelas bagi sesama tenaga medis" itu justru yang paling sulit dipegang oleh sistem otomatis, termasuk model bahasa sekalipun. LLM bisa membantu mempercepat proses ini — misalnya sebagai asisten yang mengusulkan kandidat kode — tapi begitu ada ambiguitas semacam ini, keputusan akhir tetap butuh manusia yang paham konteks klinis, bukan hanya pola teks.

Variasi kebiasaan koding antar fasilitas

Ini yang menurut saya sering diremehkan engineer yang baru masuk domain ini: standar kode itu sama secara nasional, tapi kebiasaan penerapannya bisa berbeda-beda antar fasilitas kesehatan. Satu klinik mungkin terbiasa mengkode secara sangat spesifik, sementara fasilitas lain lebih sering memakai kode umum karena keterbatasan waktu petugas koding atau template rekam medis yang berbeda. Kalau Anda membangun sistem yang dipakai lintas fasilitas, model atau aturan yang dilatih dari kebiasaan satu tempat gampang "salah kaprah" ketika dipakai di tempat lain, walau secara teknis kedua kebiasaan itu sama-sama bisa dibenarkan. Sebagai ilustrasi saja, bayangkan sebuah sistem yang akurat di satu fasilitas tapi performanya turun cukup jauh ketika dipindah ke fasilitas lain — bukan karena sistemnya buruk, tapi karena ia belajar pola dari populasi data yang sempit. Implikasinya bagi arsitektur sistem: jangan hardcode aturan koding sebagai satu kebenaran tunggal. Sistem yang baik perlu ruang untuk konfigurasi per fasilitas, mekanisme feedback dari petugas koding, dan audit trail yang jelas kapan keputusan diambil oleh mesin versus oleh manusia.

Di mana peran engineer sebenarnya

Setelah bergelut di area ini, pandangan saya berubah: tujuan realistis bukan menggantikan petugas koding, tapi membangun sistem pendukung keputusan yang mempercepat kerja mereka dan mengurangi kesalahan yang sifatnya mekanis, seperti typo, kode yang sudah tidak berlaku, atau ketidakkonsistenan format. Bagian yang butuh penilaian klinis tetap dikembalikan ke manusia, dengan antarmuka yang membuat proses review itu cepat dan tidak membebani.

Takeaway

Kalau Anda mendesain sistem di area coding medis: rancang untuk manusia-di-tengah-lingkaran (human-in-the-loop), bukan otomasi penuh; sediakan ruang konfigurasi untuk variasi antar fasilitas; dan perlakukan setiap keluaran model sebagai usulan, bukan keputusan final.