Memetakan Toolkit SATUSEHAT: Memahami Layanan dan Master Data Index untuk Integrasi yang Efektif

Memetakan Toolkit SATUSEHAT: Memahami Layanan dan Master Data Index untuk Integrasi yang Efektif

Setelah memahami SATUSEHAT sebagai jawaban atas fragmentasi data, pertanyaan logis berikutnya adalah: "Lalu, alat dan bahan baku standar apa saja yang disediakan oleh ekosistem ini agar kita, praktisi di lapangan, bisa mulai membangun jembatan integrasi?" Jawabannya terletak pada layanan inti dan Master Data Index-nya.

Kalau kita analogikan, membangun bridging ke SATUSEHAT itu seperti membangun rumah. Anda tahu tujuannya (punya rumah), Anda tahu masalahnya (tanahnya berbukit, dahulunya hutan). Tapi Anda butuh cetak biru, daftar material standar (semen SNI, bata merah ukuran tertentu), dan tukang yang paham cara membaca cetak biru itu. Nah, artikel ini adalah tentang daftar material dan cetak biru dasarnya. Bukan tentang cara mengaduk semen—itu nanti.

Pertama, mari bicara tentang layanan inti (core services). Ini adalah "mesin" yang disediakan SATUSEHAT. Anda tidak perlu membuat mesin ini dari nol; Anda hanya perlu tahu cara menyalakannya dan menghubungkan pipa sistem Anda ke sana. Dua yang paling kritis untuk fase awal integrasi adalah:

1. Master Patient Index (MPI) & Layanan Registrasi Pasien
Ini adalah "buku telepon" nasional untuk identitas pasien. Tugasnya sederhana namun monumental: memastikan satu orang = satu ID. Layanan ini bekerja seperti ini: ketika sistem rumah sakit Anda (melalui bridging) mengirimkan data pasien baru (NIK, nama, tanggal lahir, dll.), MPI akan melakukan pencarian deduplikasi. Apakah NIK ini sudah terdaftar? Jika iya, ia akan mengembalikan ID SATUSEHAT yang sudah ada (Satu Sehat ID/SSID). Jika tidak, ia akan membuat SSID baru dan mengembalikannya ke sistem Anda. Proses ini disebut probabilistic matching—tidak hanya mengandalkan NIK, tapi juga mencocokkan parameter lain seperti nama dan tanggal lahir untuk menghindari duplikasi. Untuk tim IT, ini berarti di sisi Anda harus ada mekanisme untuk menyimpan dan merujuk SSID ini di setiap transaksi terkait pasien tersebut. SSID menjadi kunci utama Anda untuk semua komunikasi data selanjutnya.

2. Layanan Pertukaran Data (Health Exchange Services)
Setelah identitas pasien jelas, Anda perlu mengirim atau menerima data klinisnya. Ini tugas dari Health Exchange. Ia bertindak sebagai "kantor pos" yang terstandar. Anda bungkus data klinis (observasi, kondisi, obat) dalam format FHIR, alamatkan ke SSID tertentu, lalu kirim ke Health Exchange. Layanan ini yang akan memastikan paket sampai ke "tujuan"—bisa ke sistem lain yang membutuhkan, atau ke repositori untuk disimpan. Yang perlu diperhatikan di sini adalah tata cara pengiriman (protokol API, autentikasi, error response) dan jenis paket apa saja yang boleh dikirim (FHIR Resources apa yang didukung). Ini detail teknis yang menentukan apakah "surat" Anda akan diterima atau dikembalikan.

Nah, selain mesin, Anda juga butuh "kamus" dan "bahan baku standar". Inilah yang disebut Master Data Index (MDI). Bayangkan Anda seorang koki di restoran franchise internasional. Anda tidak bisa mengganti tomat dengan terong sesuka hati. Anda harus pakai tomat roma ukuran tertentu, daging sapi grade A, garam dengan kemurnian tertentu. MDI adalah daftar bahan baku standar untuk ekosistem kesehatan Indonesia. Ada enam pilar utamanya:

1. Kode Fasilitas Kesehatan (Fasyankes)
Setiap rumah sakit, puskesmas, klinik, punya kode unik nasional. Ini penting untuk melacak asal-usul data. "Data observasi ini dikirim dari fasilitas mana?" Saat mengirim data, sistem Anda harus menyertakan kode fasyankes pengirim. Begitu juga saat menerima, Anda tahu data itu dari mana.

2. Kode Tenaga Kesehatan
Dokter, perawat, bidan, apoteker—semua memiliki STR (Surat Tanda Registrasi) atau SIP (Surat Izin Praktik) yang dikonversi menjadi kode standar. Setiap kali ada tindakan (pemeriksaan, pemberian resep), kode tenaga kesehatan pelakunya harus dicantumkan. Ini untuk akuntabilitas dan penelusuran.

3. Kode Diagnosis dan Prosedur
Ini mungkin yang paling familiar: ICD-10 (International Classification of Diseases) untuk diagnosis dan ICD-9-CM atau ICPI untuk prosedur. Standar ini memastikan "Demam Berdarah Dengue" di Jayapura dan di Aceh ditulis dengan kode yang sama (A91). Tanpa ini, analisis data nasional untuk penyakit tertentu akan kacau.

4. Kode Farmasi dan Alat Kesehatan (KFA)
Ini adalah salah satu pilar tersulit sekaligus paling penting. KFA adalah katalog nasional yang memuat setiap obat, vaksin, alat kesehatan, dan bahan medis habis pakai di Indonesia. Setiap item punya kode unik, nama, bentuk sediaan, kekuatan, pabrikan, dan harga tertinggi (jika ada). Kenapa sulit? Karena database obat di banyak SIMRS lawas biasanya adalah data lokal yang di-input oleh admin farmasi bertahun-tahun lalu, dengan nama yang tidak standar (misal: "Amoxicillin 500mg cap Sanbe" vs "Amoxsan 500mg kapsul"). Proses mapping atau pencocokan data obat lokal ke Kode KFA adalah pekerjaan besar yang harus dilakukan sebelum integrasi bisa lancar. Tanpa mapping yang benar, data obat tidak akan valid di ekosistem SATUSEHAT.

5. Kode Laboratorium
Memuat standar kode untuk jenis pemeriksaan lab (misal: "Glukosa Darah Puasa") dan hasilnya (nilai, unit, indikator normal/tidak). Standar seperti LOINC (Logical Observation Identifiers Names and Codes) sering diadopsi di sini. Ini memungkinkan hasil lab dari lab komersial di Surabaya bisa dibaca dan ditafsirkan dengan benar oleh dokter di puskesmas di Lombok.

6. Kode Demografi dan Lokasi
Kode provinsi, kabupaten/kota, kecamatan, dan desa/kelurahan (mengacu pada kode Kemendagri). Juga data seperti pendidikan, pekerjaan. Ini untuk keperluan agregasi dan analisis data kesehatan berbasis geografi.

Konflik batin yang muncul di sini biasanya bersifat sangat teknis dan menjemukan, tapi menentukan nasib proyek. Antara keinginan untuk cepat go-live dengan realita pekerjaan mapping data yang monster. Seorang manajer proyek mungkin mendesak: "Kita live dulu, mapping obat nanti sambil jalan." Tapi tim teknis yang paham tahu: jika Kode KFA tidak sesuai, maka seluruh transaksi terkait farmasi (resep, pemberian obat) akan gagal atau menghasilkan data sampah. Atau konflik antara fleksibilitas sistem lama dan kekakuan standar baru. Di sistem lama, field "Agama" mungkin boleh dikosongkan. Di SATUSEHAT, mungkin wajib diisi dengan kode dari pilihan terbatas. Siapa yang akan mengisi ulang puluhan ribu data historis yang kosong itu?

Perluasan maknanya adalah ini: integrasi SATUSEHAT pada dasarnya adalah proyek standardisasi data masif, yang dibungkus dengan teknologi integrasi. Tantangan terbesarnya seringkali bukan di koneksi API-nya (meski itu juga sulit), tapi di transformasi dan pembersihan data di sumber (data cleansing & transformation). Anda memaksa data yang selama ini hidup bebas dan liar di puluhan tabel database legacy, untuk bersedia berdiri rapi mengikuti formasi baris-berbaris nasional.

Oleh karena itu, pendekatan yang bijak adalah memetakan pekerjaan ini secara bertahap. Jangan sekaligus. Mungkin dimulai dengan layanan yang paling krusial: Registrasi Pasien (MPI). Fokuskan energi untuk memastikan setiap pasien baru yang didaftarkan di sistem Anda mendapatkan SSID, dan pasien lama dilakukan pencocokan secara bertahap. Setelah itu, baru naik tingkat ke pertukaran data klinis sederhana, misalnya Pengiriman Diagnosis (Condition) dan Hasil Lab (Observation). Pilar MDI yang diutamakan adalah Kode Fasyankes, Tenaga Kesehatan, dan Diagnosis. Baru setelah itu, masuk ke wilayah yang lebih kompleks: Transaksi Farmasi dengan segala kerumitan mapping KFA-nya.

Memahami peta toolkit ini juga membantu dalam berkomunikasi dengan vendor. Daripada bilang "kami mau integrasi SATUSEHAT," yang samar, lebih baik ditanya: "Apakah solusi bridging Anda sudah mendukung layanan Patient Registry API untuk deduplikasi? Bagaimana modul Anda melakukan mapping otomatis kode obat lokal ke KFA? Apakah sudah ada template FHIR Bundle untuk mengirim data kunjungan (Encounter)?" Pertanyaan spesifik seperti ini memisahkan vendor yang benar-benar paham dari yang sekadar jualan jargon.

Dengan memahami peta layanan dan kamus data standar ini, tim IT RS dan vendor tidak lagi bekerja dalam kegelapan; mereka memiliki blueprint yang jelas untuk menyelaraskan sistem lokal dengan ekosistem nasional, yang pada ujungnya bermuara pada stabilitas layanan dan keandalan data pasien antar fasyankes.

FAQ: Toolkit Teknis dan Dilema di Lapangan

Q: Mana yang harus diprioritaskan: integrasi ke MPI atau penyelesaian mapping KFA dulu?
A: MPI dulu. Karena mendapatkan SSID adalah langkah pertama dan fundamental untuk semua transaksi lain. Mapping KFA bisa berjalan paralel sebagai persiapan untuk fase integrasi farmasi nanti. Jangan menunda langkah pertama hanya karena langkah kelima terlihat sulit.

Q: Apakah kita harus membuang semua kode internal (local code) untuk obat dan diagnosis?
A: Tidak perlu dibuang. Prinsipnya: map, don't replace. Pertahankan kode internal di database Anda untuk menjaga operasional dan laporan internal. Buatlah tabel mapping yang menghubungkan kode internal Anda dengan kode standar MDI (KFA, ICD-10). Sistem bridging Anda yang akan bertugas melakukan translasi saat akan mengirim data ke SATUSEHAT.

Q: Bagaimana jika ada obat atau alat kesehatan di RS kami yang belum terdaftar di KFA?
A: Ini biasa terjadi, terutama untuk alat kesehatan niche atau obat baru. Prosedurnya adalah mengajukan penambahan item ke pengelola KFA (biasanya melalui Kemenkes). Sementara menunggu, data transaksi untuk item itu mungkin tidak bisa dikirim dengan sempurna. Perlu ada kebijakan internal untuk menangani kasus ini, misal dengan mencatatnya secara manual di sistem lain.

Q: Apa yang dimaksud dengan "probabilistic matching" di MPI? Seakurat apa?
A Ia tidak hanya mencari kesamaan persis NIK. Misal, ada pasien dengan NIK salah ketik satu digit, tapi nama dan tanggal lahir sama, dan alamat mirip. Algoritma akan memberi "skor kemiripan" dan mungkin tetap mencocokkannya sebagai orang yang sama, atau mengirimkan flag untuk konfirmasi manual. Akurasinya tinggi, tapi tidak 100%. Itulah mengapa tetap perlu mekanisme review dan merge manual untuk kasus-kasus abu-abu.

Q: Apakah semua layanan ini tersedia via API publik? Atau ada yang harus melalui VPN/koneksi khusus?
A Sebagian besar layanan inti (MPI, Health Exchange) diakses via API over internet dengan keamanan token OAuth2. Namun, untuk alasan keamanan dan performa, seringkali ada rekomendasi atau keharusan untuk menggunakan jaringan khusus (seperti Jaringan Kesehatan Nasional/JKN) atau VPN yang disediakan. Pastikan untuk memeriksa dokumentasi terbaru dari tim SATUSEHAT mengenai infrastruktur jaringan yang disarankan.

Q: Seberapa sering MDI (terutama KFA) diperbarui? Bagaimana cara kami update mapping-nya?
A KFA diperbarui secara berkala (bulanan atau triwulanan) dengan obat-obatan baru, perubahan harga, dll. Ini berarti mapping Anda bukan sekali jadi. Sistem bridging atau middleware Anda harus memiliki mekanisme untuk mengimpor file update KFA dan memperbarui tabel mapping secara (semi)otomatis. Jika tidak, suatu hari obat yang dulu sudah ter-mapping bisa jadi tidak valid lagi karena kodenya berubah.

Q: Apakah ada "sandbox" atau lingkungan uji coba untuk semua layanan ini sebelum go-live?
A Ya, seharusnya ada. SATUSEHAT menyediakan lingkungan sandbox (UAT/User Acceptance Testing) yang mirip dengan produksi, tetapi dengan data dummy. Ini adalah arena latihan yang wajib digunakan untuk menguji seluruh alur integrasi, dari registrasi pasien hingga pengiriman data klinis, sebelum dialihkan ke lingkungan produksi yang sesungguhnya. Jangan pernah skip fase ini.

Mapping the SATUSEHAT Toolkit: Understanding Services and Master Data Index for Effective Integration

After understanding SATUSEHAT as the answer to data fragmentation, the next logical question is: "So, what tools and standard raw materials does this ecosystem provide so that we, practitioners in the field, can start building the integration bridge?" The answer lies in its core services and Master Data Index.

To use an analogy, building a bridge to SATUSEHAT is like building a house. You know the goal (to have a house), you know the problems (the land is hilly, it used to be a forest). But you need a blueprint, a list of standard materials (SNI cement, bricks of a specific size), and workers who know how to read that blueprint. Well, this article is about that list of materials and the basic blueprint. Not about how to mix cement—that's for later.

First, let's talk about core services. These are the "engines" provided by SATUSEHAT. You don't need to build these engines from scratch; you just need to know how to start them and connect your system's pipes to them. The two most critical for the early integration phase are:

1. Master Patient Index (MPI) & Patient Registration Service
This is the national "phone book" for patient identities. Its task is simple yet monumental: ensuring one person = one ID. This service works like this: when your hospital system (via the bridge) sends new patient data (NIK, name, date of birth, etc.), the MPI will perform a deduplication search. Is this NIK already registered? If yes, it will return the existing SATUSEHAT ID (SSID). If not, it will create a new SSID and return it to your system. This process is called probabilistic matching—not only relying on NIK but also matching other parameters like name and date of birth to avoid duplication. For the IT team, this means on your side there must be a mechanism to store and reference this SSID in every transaction related to that patient. The SSID becomes your primary key for all subsequent data communications.

2. Health Data Exchange Services
Once the patient's identity is clear, you need to send or receive their clinical data. This is the job of the Health Exchange. It acts as the standardized "post office." You wrap clinical data (observations, conditions, medications) in FHIR format, address it to a specific SSID, then send it to the Health Exchange. This service ensures the package reaches its "destination"—either to another system that needs it or to a repository for storage. What needs attention here are the shipping procedures (API protocol, authentication, error response) and what types of packages are allowed to be sent (which FHIR Resources are supported). These technical details determine whether your "letter" will be accepted or returned.

Now, besides the engine, you also need a "dictionary" and "standard raw materials." This is called the Master Data Index (MDI). Imagine you are a chef in an international franchise restaurant. You can't replace tomatoes with eggplants as you wish. You must use roma tomatoes of a specific size, grade A beef, salt of a certain purity. MDI is the list of standard raw materials for the Indonesian health ecosystem. There are six main pillars:

1. Health Facility Code (Fasyankes)
Every hospital, community health center, clinic has a unique national code. This is important for tracking data provenance. "Where was this observation data sent from?" When sending data, your system must include the sender's facility code. Likewise, when receiving, you know where the data is from.

2. Healthcare Worker Code
Doctors, nurses, midwives, pharmacists—all have their STR (Registration Certificate) or SIP (Practice License) converted into a standard code. Whenever there is an action (examination, prescribing), the code of the healthcare worker who performed it must be included. This is for accountability and traceability.

3. Diagnosis and Procedure Codes
This might be the most familiar: ICD-10 (International Classification of Diseases) for diagnosis and ICD-9-CM or ICPI for procedures. This standard ensures "Dengue Hemorrhagic Fever" in Jayapura and in Aceh is written with the same code (A91). Without this, national data analysis for specific diseases would be chaotic.

4. Pharmacy and Medical Device Code (KFA)
This is one of the most difficult and most important pillars. KFA is the national catalog containing every drug, vaccine, medical device, and consumable medical supply in Indonesia. Each item has a unique code, name, dosage form, strength, manufacturer, and maximum price (if any). Why is it difficult? Because drug databases in many legacy HIS are usually local data input by pharmacy admins years ago, with non-standard names (e.g., "Amoxicillin 500mg cap Sanbe" vs "Amoxsan 500mg capsule"). The process of mapping or matching local drug data to KFA codes is a huge task that must be done before integration can run smoothly. Without correct mapping, drug data will not be valid in the SATUSEHAT ecosystem.

5. Laboratory Codes
Contains standard codes for types of lab tests (e.g., "Fasting Blood Glucose") and their results (value, unit, normal/abnormal indicator). Standards like LOINC (Logical Observation Identifiers Names and Codes) are often adopted here. This allows lab results from a commercial lab in Surabaya to be read and interpreted correctly by a doctor at a health center in Lombok.

6. Demographic and Location Codes
Province, regency/city, district, and village codes (referring to the Ministry of Home Affairs codes). Also data like education, occupation. This is for aggregation and geographic-based health data analysis.

The inner conflict that arises here is usually very technical and tedious, yet determines the fate of the project. Between the desire to go live quickly and the reality of the monstrous data mapping work. A project manager might push: "Let's go live first, drug mapping can be done later along the way." But the technical team who understands knows: if the KFA Code is incorrect, then all pharmacy-related transactions (prescriptions, drug administration) will fail or produce garbage data. Or the conflict between the flexibility of the old system and the rigidity of the new standard. In the old system, the "Religion" field might be allowed to be empty. In SATUSEHAT, it might be mandatory to fill with a code from a limited list. Who will fill in tens of thousands of historical empty data?

The expanded meaning is this: SATUSEHAT integration is essentially a massive data standardization project, wrapped in integration technology. Its biggest challenge is often not in the API connection (though that's also difficult), but in the data transformation and cleansing at the source (data cleansing & transformation). You are forcing data that has lived freely and wildly in dozens of legacy database tables to willingly stand in neat formation following the national marching order.

Therefore, a wise approach is to map this work in stages. Not all at once. Maybe start with the most crucial service: Patient Registration (MPI). Focus energy on ensuring every new patient registered in your system gets an SSID, and old patients are matched gradually. After that, move up to exchanging simple clinical data, for example Sending Diagnoses (Condition) and Lab Results (Observation). The MDI pillars prioritized are Facility Codes, Healthcare Worker Codes, and Diagnosis Codes. Only then, move into more complex territory: Pharmacy Transactions with all the complexities of KFA mapping.

Understanding this toolkit map also helps in communicating with vendors. Instead of saying vaguely "we want SATUSEHAT integration," it's better to ask: "Does your bridging solution already support the Patient Registry API for deduplication? How does your module perform automatic mapping of local drug codes to KFA? Is there a FHIR Bundle template for sending visit (Encounter) data?" Specific questions like these separate vendors who truly understand from those who just sell jargon.

By understanding this map of services and standard data dictionaries, hospital IT teams and vendors no longer work in the dark; they have a clear blueprint to align local systems with the national ecosystem, which ultimately leads to service stability and the reliability of patient data across health facilities.

Q&A: Technical Toolkit and Field Dilemmas

Q: Which should be prioritized: MPI integration or completing KFA mapping first?
A: MPI first. Because obtaining an SSID is the first and fundamental step for all other transactions. KFA mapping can run in parallel as preparation for the later pharmacy integration phase. Don't delay the first step just because the fifth step looks difficult.

Q: Do we have to discard all our internal codes (local codes) for drugs and diagnoses?
A: No need to discard. The principle is: map, don't replace. Keep your internal codes in your database to maintain operations and internal reports. Create a mapping table that links your internal codes with the standard MDI codes (KFA, ICD-10). Your bridging system will be tasked with performing translation when sending data to SATUSEHAT.

Q: What if there are drugs or medical devices in our hospital that are not yet registered in KFA?
A: This commonly happens, especially for niche medical devices or new drugs. The procedure is to submit an addition request for the item to the KFA manager (usually through the Ministry of Health). While waiting, transaction data for that item may not be sent perfectly. There needs to be an internal policy to handle this case, for example by recording it manually in another system.

Q: What is meant by "probabilistic matching" in MPI? How accurate is it?
A: It doesn't just look for an exact NIK match. For example, a patient with a NIK typo by one digit, but the same name and date of birth, and a similar address. The algorithm will give a "similarity score" and might still match them as the same person, or send a flag for manual confirmation. Its accuracy is high, but not 100%. That's why there still needs to be a mechanism for manual review and merging for gray-area cases.

Q: Are all these services available via public API? Or are some through VPN/special connection?
A: Most core services (MPI, Health Exchange) are accessed via API over the internet with OAuth2 token security. However, for security and performance reasons, there are often recommendations or requirements to use a special network (like the National Health Network/JKN) or a provided VPN. Be sure to check the latest documentation from the SATUSEHAT team regarding recommended network infrastructure.

Q: How often is the MDI (especially KFA) updated? How do we update our mapping?
A: KFA is updated periodically (monthly or quarterly) with new drugs, price changes, etc. This means your mapping is not a one-time job. Your bridging system or middleware must have a mechanism to import KFA update files and update the mapping table (semi)automatically. If not, one day a drug that was previously mapped may become invalid because its code changed.

Q: Is there a "sandbox" or test environment for all these services before go-live?
A: Yes, there should be. SATUSEHAT provides a sandbox environment (UAT/User Acceptance Testing) similar to production, but with dummy data. This is a mandatory training arena to test the entire integration flow, from patient registration to sending clinical data, before switching to the actual production environment. Never skip this phase.