Arsitektur Mapping Diagnosis: Membangun Jembatan Antara Klinis dan Klaim yang Tahan Perubahan Regulasi

Arsitektur Mapping Diagnosis: Membangun Jembatan Antara Klinis dan Klaim yang Tahan Perubahan Regulasi

Dalam ruang lingkup SIMRS, mungkin tidak ada ketegangan yang lebih abadi daripada ini: di satu sisi, dokter yang fokus mencatat kondisi pasien dengan bahasa klinisnya; di sisi lain, sistem yang menuntut kode standar untuk klaim yang aturannya berubah setiap beberapa tahun. Menjembatani keduanya bukan sekadar masalah teknis, melainkan filosofi desain sistem.

Saya ingin bercerita dari sebuah insiden kecil yang sebenarnya besar. Suatu hari, sebuah rumah sakit menerima koreksi dari pihak BPJS: klaim untuk diagnosis "Asma Bronkial Akut" tidak bisa dibayar karena kode yang digunakan sudah kedaluwarsa. Ternyata, beberapa bulan sebelumnya, terjadi perubahan kecil pada katalog ICD-10 untuk penyakit pernapasan. Apa yang terjadi di sistem? Seorang admin yang panik membuka puluhan ribu rekam medis, mencari diagnosis "Asma Bronkial Akut", dan mengganti kodenya satu per satu secara manual. Proses itu memakan waktu tiga minggu, mengganggu klaim lainnya, dan menimbulkan risiko salah ubah yang tinggi. Di sinilah kita melihat masalahnya bukan pada dokternya (yang hanya menulis apa yang dilihatnya), bukan pada adminnya (yang hanya menjalankan perintah), tapi pada arsitektur sistem yang memaksa data klinis dan kode administratif menyatu dalam satu tempat yang rapuh.

Realitas di lapangan memang sering kali absurd. Seorang dokter senior yang bisa mendiagnosis penyakit langka hanya dari perubahan suara napas, bisa terdiam sepuluh menit di depan komputer hanya untuk memilih kode dari dropdown yang berisi ribuan entri ICD-10. "Saya mau catat 'Gagal Jantung Kongestif Decompensata', tapi di dropdown mana ya? Apakah ini di I50.0 atau I50.9?" Akhirnya, seringkali dipilih yang paling mirip, atau yang paling mudah dicari. Hasilnya? Data klinis yang sebenarnya kaya dan akurat, tereduksi menjadi kode yang mungkin tidak tepat, hanya karena antarmuka sistem dirancang untuk memenuhi kebutuhan administratif, bukan klinis.

Prinsip kunci yang harus kita pegang teguh adalah ini: Data klinis adalah kebenaran pertama. Kode administratif adalah turunan yang bisa berubah. Mereka harus dipisahkan. Seperti memisahkan dinding struktur rumah (yang kokoh dan permanen) dengan cat tembok (yang bisa diganti warna kapan saja). Arsitektur yang baik akan melindungi kebenaran pertama itu dari guncangan perubahan di lapisan turunannya.

Mari kita uraikan arsitektur berlapis ini, dari bawah ke atas:

Lapisan 1: Input & Kamus Diagnosis Lokal
Ini adalah lapisan yang berinteraksi langsung dengan dokter. Di sini, kita tidak menyodorkan dropdown berisi kode ICD. Kita menyodorkan daftar istilah klinis yang familiar dan sudah dinormalisasi. Misalnya: "Diabetes Melitus Tipe 2", "Hipertensi Esensial", "Demam Tifoid". Kamus ini dikelola oleh tim medis dan TI bersama-sama, bisa ditambah sinonim ("DM Tipe 2", "Kencing Manis Tipe 2") untuk memudahkan pencarian. Ketika dokter mengetik "kencing manis", sistem akan menyarankan "Diabetes Melitus Tipe 2" sebagai pilihan standar. Data yang disimpan dari interaksi ini hanyalah: ID Diagnosis Lokal dan mungkin metadata klinis tambahan (tingkat keparahan, komplikasi). Ini adalah data klinis murni.

Lapisan 2: Penyimpanan Data Klinis (Core)
Di lapisan database inti, tabel `diagnosis_pasien` akan menyimpan referensi ke `id_diagnosis_lokal` tadi, bersama `id_kunjungan` dan `id_dokter`. Tidak ada kode ICD disini. Hanya hubungan antara pasien, kunjungan, dan konsep klinis. Ini adalah "sumber kebenaran" yang stabil. Sekali disimpan, ia tidak perlu diubah-ubah hanya karena aturan klaim berubah.

Lapisan 3: Tabel Mapping (Jantung Arsitektur)
Inilah lapisan ajaibnya. Sebuah tabel terpisah, misal bernama `mapping_diagnosis`, yang berisi kolom sederhana: - `id_diagnosis_lokal` (kunci ke kamus) - `sistem_kode` (misal: 'ICD-10', 'ICD-11', 'KODE_BPJS_2024', 'SNOMED_CT') - `kode` (misal: 'E11.9' untuk ICD-10) - `deskripsi_kode` (opsional) - `tanggal_efektif_mulai` - `tanggal_efektif_selesai` (untuk menandai kode yang sudah tidak berlaku).

Satu `id_diagnosis_lokal` bisa memiliki banyak baris di tabel ini. "Diabetes Melitus Tipe 2" bisa ter-mapping ke: - ICD-10: E11.9 - ICD-11: 5A11 (misal) - Kode Klaim BPJS Versi 2024: DM02 - SNOMED CT: 44054006 Mapping ini bukan tugas dokter. Ini adalah tugas tim pengelola kode (biasanya dari bagian pelaporan atau IT dengan konsultan medis). Mereka adalah "penerjemah" resmi antara bahasa klinis dan bahasa administratif.

Lapisan 4: Output & Layanan (Adaptif)
Lapisan inilah yang berhubungan dengan dunia luar. Ketika sistem perlu mengirimkan klaim ke BPJS, sebuah service akan: 1. Ambil `id_diagnosis_lokal` dari data kunjungan. 2. Cari di tabel `mapping_diagnosis` dimana `sistem_kode = 'KODE_BPJS_2024'` dan `tanggal_efektif` masih berlaku. 3. Gunakan `kode` yang ditemukan untuk membentuk berkas klaim. Proses yang sama berlaku untuk pelaporan ke Dinkes (mungkin pakai ICD-10), atau pertukaran data SATUSEHAT (mungkin pakai SNOMED CT atau ICD-11). Jika suatu saat BPJS mengganti katalognya ke versi 2025, kita hanya perlu: - Menambahkan mapping baru di tabel `mapping_diagnosis` dengan `sistem_kode = 'KODE_BPJS_2025'`. - Meng-update service klaim untuk menggunakan sistem kode yang baru. Data klinis di lapisan 2 tetap utuh, tidak tersentuh.

Konflik batin dalam mendesain ini biasanya terjadi antara keinginan untuk kesederhanaan jangka pendek dan kompleksitas yang memberi ketahanan jangka panjang. Vendor mungkin berkata, "Untuk apa repot? Simpan saja kode ICD-10 langsung di tabel diagnosis, lebih cepat." Manajemen mungkin bertanya, "Apakah ini tidak membuat sistem jadi lambat karena join tambahan?" Jawabannya: kompleksitas yang terkelola di awal akan menyelamatkan dari chaos yang tak terkelola di kemudian hari. Join satu tabel mapping adalah operasi trivial bagi database modern. Biaya migrasi massal data akibat perubahan regulasi adalah bencana operasional yang nyata.

Perluasan makna dari arsitektur ini sebenarnya adalah prinsip desain yang universal: separasi konsep (separation of concerns). Kita memisahkan apa yang terjadi (klinis) dari bagaimana melaporkannya (administratif). Prinsip ini tidak hanya berlaku untuk diagnosis, tetapi juga untuk prosedur, obat (mapping ke KFA), dan bahkan tenaga kesehatan (mapping STR ke kode nasional). Setiap kali ada dua domain yang berubah dengan kecepatan berbeda, di situlah kita perlu lapisan pemisah.

Pendalaman implementasinya membutuhkan perhatian pada detail. Pertama, kita butuh tool untuk mengelola kamus diagnosis lokal dan mapping-nya—sebuah antarmuka admin yang intuitif. Kedua, kita perlu mekanisme penanganan kasus dimana mapping belum ada. Misalnya, dokter memilih diagnosis langka yang belum punya kode BPJS. Sistem harus bisa menandai ini sebagai "pending mapping" dan tetap menyimpan data klinisnya, sambil memberi alert ke tim pengelola kode. Ketiga, kita butuh versioning dan audit trail di tabel mapping. Siapa yang menambah mapping? Kapan? Untuk kebutuhan apa? Ini penting untuk pelacakan jika terjadi kesalahan.

Pada akhirnya, arsitektur seperti ini bukan hanya soal teknologi. Ini soal mengubah pola pikir. Dari pola pikir "input data sekali untuk semua kebutuhan" menjadi "input data untuk kebenaran klinis, generate output untuk kebutuhan kontekstual". Ini mengakui bahwa dunia kesehatan adalah dunia yang dinamis: ilmu berkembang, regulasi berubah, sistem eksternal bermutasi. Sistem informasi kita harus menjadi kapal yang lentur, bukan menara yang kaku, agar bisa berlayar menghadapi ombak perubahan yang pasti datang.

Dengan menerapkan arsitektur berlapis ini, tim IT RS dan vendor bukan hanya menyelesaikan masalah mapping hari ini, tetapi lebih penting, mereka membangun ketahanan sistem terhadap gejolak regulasi esok hari—sebuah investasi yang langsung terasa dampaknya pada stabilitas layanan dan keandalan data pasien.

FAQ: Dilema dan Detail Teknis Arsitektur Mapping

Q: Bukankah ini membuat dependensi baru, yaitu tim pengelola kode? Bagaimana jika tim ini tidak ada?
A: Benar, ini adalah pergeseran tanggung jawab. Daripada membebani setiap dokter dengan detail kode, kita memusatkannya pada tim spesialis. Jika tim belum ada, ini saatnya membentuknya—bisa terdiri dari perawat rekam medis yang paham koding, staf IT, dan konsultan medis. Ini lebih efisien dan mengurangi error secara sistematis.

Q: Bagaimana dengan data historis puluhan ribu diagnosis yang sudah tersimpan sebagai kode ICD-10 langsung?
A: Ini pekerjaan rumah yang besar tapi sekali waktu. Dibutuhkan proyek migrasi untuk "memisahkan" data lama: ekstrak kode ICD-10 lama, cari kandidat diagnosis lokal yang sesuai (otomatis atau manual), simpan sebagai data klinis baru, dan buat mapping-nya. Proses ini disebut "refactoring database". Pahit di awal, tapi menyelamatkan masa depan.

Q: Apakah tidak memperlambat pencarian laporan? Misal, saya mau cari semua pasien dengan diagnosis tertentu berdasarkan kode ICD-10.
A: Tidak signifikan. Query-nya akan menjadi JOIN antara tabel diagnosis_pasien, kamus diagnosis, dan tabel mapping dengan filter sistem_kode='ICD-10'. Dengan indeks yang tepat pada kolom kunci, performanya setara dengan mencari langsung di kolom kode. Bahkan, dengan penyimpanan terpisah, Anda bisa membuat view (virtual table) bernama `view_diagnosis_icd10` yang sudah berisi mapping siap pakai, sehingga pengguna akhir tidak merasakan kompleksitasnya.

Q: Siapa yang bertanggung jawab jika mapping salah dan menyebabkan klaim ditolak?
A: Dengan arsitektur ini, tanggung jawab menjadi jelas. Tim pengelola kode bertanggung jawab atas akurasi mapping di tabel `mapping_diagnosis`. Dokter bertanggung jawab atas pemilihan diagnosis lokal yang tepat. Sistem bertanggung jawab untuk menjalankan proses mapping sesuai logika. Audit trail di tabel mapping akan menunjukkan siapa yang membuat atau mengubah mapping tersebut.

Q: Bagaimana cara menangani diagnosis yang sangat spesifik dengan banyak modifier (misal: "Ulkus diabetik kaki kanan derajat 3")?
A: Diagnosis lokal bisa bersifat hierarkis atau dilengkapi dengan atribut metadata. Anda bisa memiliki diagnosis induk "Ulkus Diabetik" dan menyimpan modifier "lokasi: kaki kanan" dan "derajat: 3" sebagai field terpisah di tabel diagnosis_pasien. Mapping kemudian bisa dilakukan dengan logika yang lebih cerdas, misalnya gabungan dari diagnosis induk dan modifier menghasilkan kode ICD-10 yang berbeda (misal L97.411). Ini lebih kompleks, tetapi prinsip pemisahan data klinis dan kode tetap sama.

Q: Apakah prinsip ini juga berlaku untuk integrasi dengan SATUSEHAT yang membutuhkan FHIR Resources?
A: Sangat berlaku, dan justru sangat cocok. Diagnosis lokal di SIMRS Anda akan menjadi sumber klinis. Saat mengirim data Condition resource ke SATUSEHAT, sistem bridging Anda akan melakukan mapping dari diagnosis lokal ke kode standar yang diwajibkan SATUSEHAT (misal, SNOMED CT atau ICD-11), dengan merujuk pada tabel mapping khusus dengan `sistem_kode='SATUSEHAT_FHIR'`. Jika standar SATUSEHAT berubah, Anda hanya update mapping, tidak ubah data klinis.

Q: Arsitektur ini terlihat bagus, tetapi apakah ada vendor SIMRS yang sudah menerapkannya?
A: Vendor-vendor besar dan modern cenderung mulai mengadopsi pola serupa, meski mungkin dengan nama berbeda. Ini menjadi pembeda kualitas. Saat memilih atau mengevaluasi vendor, tanyakan: "Bagaimana sistem Anda menangani perubahan kode klasifikasi penyakit? Apakah saya harus migrasi data manual?" Jawabannya akan mengungkap kedewasaan arsitektural mereka.

Diagnosis Mapping Architecture: Building a Bridge Between Clinical and Claims That Withstands Regulatory Change

Within the scope of a Hospital Information System (HIS), there may be no more enduring tension than this: on one side, doctors focused on recording patient conditions in their clinical language; on the other, the system demanding standard codes for claims whose rules change every few years. Bridging the two is not just a technical problem, but a system design philosophy.

I want to tell a story from a small incident that was actually big. One day, a hospital received a correction from the national health insurer (BPJS): claims for the diagnosis "Acute Bronchial Asthma" could not be paid because the code used was obsolete. It turned out, a few months earlier, there had been a minor change to the ICD-10 catalog for respiratory diseases. What happened in the system? A panicked administrator opened tens of thousands of medical records, searched for the diagnosis "Acute Bronchial Asthma", and changed the code one by one manually. The process took three weeks, disrupted other claims, and carried a high risk of error. Here we see the problem was not with the doctor (who only wrote what they observed), not with the admin (who was just following orders), but with the system architecture that forced clinical data and administrative codes to merge in one fragile place.

The reality on the ground is indeed often absurd. A senior doctor who can diagnose a rare disease just from a change in breath sounds, can sit silently for ten minutes in front of a computer just to choose a code from a dropdown containing thousands of ICD-10 entries. "I want to record 'Congestive Heart Failure Decompensated', but where is it in the dropdown? Is it under I50.0 or I50.9?" In the end, often the most similar or easiest to find is chosen. The result? Clinical data that is actually rich and accurate, reduced to a code that may be incorrect, simply because the system interface was designed to meet administrative needs, not clinical ones.

The key principle we must hold firmly is this: Clinical data is the primary truth. Administrative codes are derivatives that can change. They must be separated. Like separating the structural walls of a house (which are solid and permanent) from the wall paint (which can be changed in color anytime). Good architecture will protect that primary truth from shocks in its derivative layers.

Let's break down this layered architecture, from bottom to top:

Layer 1: Input & Local Diagnosis Dictionary
This is the layer that interacts directly with the doctor. Here, we do not present a dropdown full of ICD codes. We present a list of familiar, normalized clinical terms. For example: "Type 2 Diabetes Mellitus", "Essential Hypertension", "Typhoid Fever". This dictionary is managed jointly by the medical and IT teams, can include synonyms ("DM Type 2", "Type 2 Diabetes") for easier searching. When a doctor types "diabetes", the system will suggest "Type 2 Diabetes Mellitus" as the standard choice. The data stored from this interaction is only: Local Diagnosis ID and possibly additional clinical metadata (severity, complications). This is pure clinical data.

Layer 2: Clinical Data Storage (Core)
In the core database layer, the `patient_diagnosis` table will store a reference to that `local_diagnosis_id`, along with `visit_id` and `doctor_id`. No ICD codes here. Only the relationship between patient, visit, and clinical concept. This is the stable "source of truth". Once stored, it does not need to be changed just because claim rules change.

Layer 3: Mapping Table (The Heart of the Architecture)
This is the magical layer. A separate table, perhaps named `diagnosis_mapping`, containing simple columns: - `local_diagnosis_id` (key to the dictionary) - `code_system` (e.g., 'ICD-10', 'ICD-11', 'BPJS_CODE_2024', 'SNOMED_CT') - `code` (e.g., 'E11.9' for ICD-10) - `code_description` (optional) - `effective_date_start` - `effective_date_end` (to mark codes that are no longer valid).

One `local_diagnosis_id` can have many rows in this table. "Type 2 Diabetes Mellitus" could be mapped to: - ICD-10: E11.9 - ICD-11: 5A11 (for example) - BPJS Claim Code Version 2024: DM02 - SNOMED CT: 44054006 This mapping is not the doctor's task. It is the task of the code management team (usually from the reporting or IT department with a medical consultant). They are the official "translators" between clinical language and administrative language.

Layer 4: Output & Services (Adaptive)
This is the layer that interacts with the outside world. When the system needs to submit a claim to BPJS, a service will: 1. Take the `local_diagnosis_id` from the visit data. 2. Look up in the `diagnosis_mapping` table where `code_system = 'BPJS_CODE_2024'` and the `effective_date` is still valid. 3. Use the found `code` to form the claim file. The same process applies for reporting to the Health Office (maybe using ICD-10), or data exchange with SATUSEHAT (maybe using SNOMED CT or ICD-11). If one day BPJS changes its catalog to version 2025, we only need to: - Add a new mapping in the `diagnosis_mapping` table with `code_system = 'BPJS_CODE_2025'`. - Update the claim service to use the new code system. The clinical data in layer 2 remains intact, untouched.

The inner conflict in designing this usually occurs between the desire for short-term simplicity and the complexity that provides long-term resilience. A vendor might say, "Why bother? Just store the ICD-10 code directly in the diagnosis table, it's faster." Management might ask, "Doesn't this make the system slower due to extra joins?" The answer: managed complexity at the beginning will save you from unmanaged chaos later. Joining one mapping table is a trivial operation for modern databases. The cost of mass data migration due to regulatory change is a real operational disaster.

The expanded meaning of this architecture is actually a universal design principle: separation of concerns. We separate what happened (clinical) from how to report it (administrative). This principle applies not only to diagnoses but also to procedures, drugs (mapping to KFA), and even healthcare workers (mapping STR to national codes). Whenever two domains change at different speeds, that's where we need a separation layer.

Deepening its implementation requires attention to detail. First, we need a tool to manage the local diagnosis dictionary and its mapping—an intuitive admin interface. Second, we need a mechanism to handle cases where mapping does not yet exist. For example, a doctor selects a rare diagnosis that has no BPJS code yet. The system must be able to flag this as "pending mapping" while still storing the clinical data, and alert the code management team. Third, we need versioning and audit trails in the mapping table. Who added a mapping? When? For what purpose? This is important for tracing if an error occurs.

In the end, an architecture like this is not just about technology. It's about changing mindsets. From a mindset of "input data once for all needs" to "input data for clinical truth, generate output for contextual needs". It acknowledges that the world of healthcare is dynamic: science evolves, regulations change, external systems mutate. Our information system must be a flexible ship, not a rigid tower, to sail through the waves of change that are sure to come.

By implementing this layered architecture, hospital IT teams and vendors are not only solving today's mapping problem, but more importantly, they are building system resilience against tomorrow's regulatory upheavals—an investment whose impact is immediately felt in service stability and the reliability of patient data.

Q&A: Dilemmas and Technical Details of Mapping Architecture

Q: Doesn't this create a new dependency, namely the code management team? What if this team doesn't exist?
A: Correct, this is a shift in responsibility. Instead of burdening every doctor with code details, we centralize it with a specialist team. If the team doesn't exist yet, it's time to form one—it could consist of medical record nurses who understand coding, IT staff, and a medical consultant. This is more efficient and reduces errors systematically.

Q: What about historical data of tens of thousands of diagnoses already stored directly as ICD-10 codes?
A: This is a big but one-time homework. A migration project is needed to "separate" the old data: extract the old ICD-10 code, find a suitable local diagnosis candidate (automatically or manually), save it as new clinical data, and create its mapping. This process is called "database refactoring". Bitter at first, but it saves the future.

Q: Doesn't it slow down report searches? For example, I want to find all patients with a specific diagnosis based on an ICD-10 code.
A: Not significantly. The query would be a JOIN between the patient_diagnosis table, the diagnosis dictionary, and the mapping table filtered by code_system='ICD-10'. With proper indexes on key columns, the performance is equivalent to searching directly in a code column. In fact, with separate storage, you can create a view (virtual table) named `view_diagnosis_icd10` that already contains ready-to-use mapping, so end-users don't feel the complexity.

Q: Who is responsible if the mapping is wrong and causes a claim to be rejected?
A: With this architecture, responsibility becomes clear. The code management team is responsible for the accuracy of mapping in the `diagnosis_mapping` table. The doctor is responsible for choosing the correct local diagnosis. The system is responsible for executing the mapping process according to logic. The audit trail in the mapping table will show who created or changed that mapping.

Q: How to handle very specific diagnoses with many modifiers (e.g., "Diabetic ulcer right foot grade 3")?
A: Local diagnoses can be hierarchical or supplemented with metadata attributes. You could have a parent diagnosis "Diabetic Ulcer" and store modifiers "location: right foot" and "grade: 3" as separate fields in the patient_diagnosis table. Mapping can then be done with smarter logic, for example, a combination of the parent diagnosis and modifiers results in a different ICD-10 code (e.g., L97.411). This is more complex, but the principle of separating clinical data and codes remains the same.

Q: Does this principle also apply to integration with SATUSEHAT which requires FHIR Resources?
A: Very much so, and in fact, it's a perfect fit. Your HIS's local diagnosis will be the clinical source. When sending Condition resource data to SATUSEHAT, your bridging system will perform mapping from the local diagnosis to the standard code required by SATUSEHAT (e.g., SNOMED CT or ICD-11), by referring to a special mapping table with `code_system='SATUSEHAT_FHIR'`. If the SATUSEHAT standard changes, you only update the mapping, not the clinical data.

Q: This architecture looks good, but are there any HIS vendors that have implemented it?
A: Large and modern vendors tend to start adopting similar patterns, though perhaps under different names. This becomes a quality differentiator. When selecting or evaluating a vendor, ask: "How does your system handle changes in disease classification codes? Do I have to do manual data migration?" The answer will reveal their architectural maturity.