Struktur ICD-10 Dijelaskan untuk Non-Koder
Kalau Anda membangun sistem informasi kesehatan — rekam medis elektronik, modul klaim, atau sekadar fitur pencarian diagnosa — cepat atau lambat Anda akan bersentuhan dengan ICD-10. Banyak developer memperlakukannya seperti kode pos: string unik yang tinggal disimpan di kolom varchar dan ditampilkan apa adanya. Masalahnya, ICD-10 bukan daftar datar. Ia punya hierarki, dan kalau hierarki ini tidak dipahami sejak desain skema database, banyak fitur yang seharusnya mudah — pencarian, agregasi laporan, validasi — jadi menyakitkan untuk dibangun belakangan.
Saya menulis ini dari sudut pandang praktisi yang pernah membangun sistem yang menyentuh pengkodean diagnosa. Tujuannya bukan mengajarkan Anda jadi koder medis, tapi memberi cukup pemahaman struktural supaya keputusan desain sistem Anda tidak menabrak logika ICD-10 di kemudian hari.
Bab, Blok, dan Kategori: tiga lapis pertama
ICD-10 disusun berjenjang. Lapis paling atas adalah bab (chapter), dikelompokkan berdasarkan sistem tubuh atau jenis kondisi — misalnya bab untuk penyakit infeksi, bab untuk penyakit sistem sirkulasi, bab untuk cedera dan keracunan. Di bawah bab ada blok, rentang kode yang mengelompokkan kondisi yang berkerabat secara klinis dalam bab yang sama.
Lapis berikutnya adalah kategori tiga karakter, formatnya satu huruf diikuti dua digit (misalnya kode di rentang tertentu). Kategori tiga karakter ini sudah cukup spesifik untuk menunjukkan jenis kondisi, tapi belum menunjukkan detail seperti lokasi anatomis atau tahap penyakit.
Subkategori: di sinilah detail klinis hidup
Dari kategori tiga karakter, ICD-10 bisa pecah lagi jadi subkategori empat atau lima karakter dengan menambahkan titik desimal dan digit tambahan. Di sinilah nuansa klinis muncul — sisi kanan atau kiri, akut atau kronis, dengan atau tanpa komplikasi. Dua diagnosa yang berbeda hanya di digit terakhir bisa punya makna klinis, dan kadang implikasi pembiayaan, yang jauh berbeda.
Ini poin penting untuk desain sistem: kalau Anda hanya menyimpan tiga karakter pertama karena "sudah cukup spesifik", Anda kehilangan informasi yang sebenarnya dibutuhkan di hilir — laporan epidemiologi, klaim BPJS, atau analitik klinis. Sebaliknya, kalau UI Anda memaksa user selalu mengisi sampai digit kelima padahal kondisi kliniknya memang hanya bisa dipastikan sampai level kategori, Anda memaksa data yang tidak akurat masuk ke sistem. Idealnya skema database dan form input Anda mengizinkan presisi bertingkat sesuai yang benar-benar diketahui klinisi saat itu.
Kenapa ini penting saat mendesain skema dan pencarian
Karena hierarkinya nyata, ada beberapa implikasi desain yang layak dipikirkan dari awal:
- Indeks dan pencarian — pencarian "semua kode di bawah kategori X" jauh lebih natural kalau kode disimpan sebagai string terstruktur (bukan angka), sehingga pencarian prefix (
LIKE 'X%'atau setara) bekerja alami mengikuti hierarki. - Agregasi laporan — laporan per bab atau per blok butuh tabel referensi hierarki yang eksplisit, bukan cuma tabel kode datar. Menyimpan mapping kode ke induknya sejak awal jauh lebih murah daripada menambahkannya belakangan setelah data jutaan baris.
- Validasi input — sistem idealnya memvalidasi bahwa kode yang dimasukkan benar-benar ada di master ICD-10 terbaru, bukan sekadar cocok pola regex. Master data ICD-10 di-update secara berkala, jadi mekanisme sinkronisasi master data juga perlu jadi bagian desain, bukan tempelan.
Takeaway
ICD-10 bukan sekadar "kode diagnosa", tapi taksonomi berjenjang: bab, blok, kategori, dan subkategori, masing-masing membawa makna. Sebagai developer, tugas kita bukan menghafal seluruh isinya — itu ranah koder medis — tapi memastikan skema data, mekanisme pencarian, dan alur validasi kita selaras dengan struktur ini sejak awal. Investasi kecil di tahap desain ini akan menghemat banyak refactor menyakitkan begitu sistem sudah dipakai produksi dan datanya sudah menumpuk.