BAB VII
Integrasi dan Interoperabilitas Sistem Informasi Kesehatan
API, Pertukaran Data, SATUSEHAT, HL7 FHIR, Identitas Sistem, dan Keamanan Koneksi
7.1 Pendahuluan
Pertemuan ketujuh membawa mahasiswa pada tahap penting dalam transformasi digital kesehatan, yaitu memahami bagaimana berbagai aplikasi yang sebelumnya telah dipelajari dapat saling terhubung dan bertukar informasi.
Sebuah fasilitas kesehatan dapat memiliki aplikasi pendaftaran, Rekam Medis Elektronik (RME), laboratorium, farmasi, klaim, logistik, sumber daya manusia, serta dashboard. Namun, keberadaan banyak aplikasi tidak otomatis menghasilkan Sistem Informasi Kesehatan yang terintegrasi.
Apabila masing-masing aplikasi menggunakan struktur data dan identitas yang berbeda, petugas mungkin tetap harus melakukan input berulang, rekonsiliasi secara manual, atau memindahkan data melalui file yang terpisah.
Dalam konteks administrasi kesehatan, masalah tersebut bukan sekadar persoalan teknis. Duplikasi data dapat meningkatkan beban kerja, menimbulkan perbedaan angka antarunit, memperlambat pelaporan, meningkatkan risiko kesalahan identitas, serta menyulitkan manajemen memperoleh informasi yang utuh.
Integrasi menghubungkan sistem. Interoperabilitas memastikan sistem yang berbeda dapat bertukar informasi dengan struktur dan makna yang dipahami bersama sehingga data dapat digunakan kembali secara benar dalam pelayanan dan administrasi.
7.2 Capaian Pembelajaran Pertemuan
Pertemuan ketujuh mengacu pada CPMK-3 / Sub-CPMK 7. Mahasiswa diharapkan mampu menganalisis arsitektur integrasi/interoperabilitas dan konektivitas ke ekosistem digital kesehatan.
- Membedakan integrasi dan interoperabilitas dalam Sistem Informasi Kesehatan.
- Menjelaskan peran API sebagai antarmuka pertukaran data.
- Menggambarkan alur pertukaran data dari aplikasi sumber sampai sistem tujuan.
- Menjelaskan pengantar HL7 FHIR dan posisi SATUSEHAT dalam ekosistem pertukaran data kesehatan.
- Mengidentifikasi kebutuhan identitas, standardisasi data, validasi, autentikasi, otorisasi, dan logging.
- Menyusun diagram integrasi internal–eksternal pada fasilitas kesehatan.
Mahasiswa menghasilkan diagram integrasi/interoperabilitas yang memperlihatkan aplikasi sumber, lapisan API/integrasi, alur data, sistem eksternal, keamanan koneksi, serta titik monitoring.
7.3 Dari Banyak Aplikasi Menuju Satu Ekosistem Informasi
Fasilitas kesehatan biasanya mengembangkan aplikasi secara bertahap. Pendaftaran mungkin menggunakan satu sistem, laboratorium memakai aplikasi lain, farmasi memiliki aplikasi stok tersendiri, sedangkan pelaporan dilakukan melalui portal yang berbeda.
Setiap aplikasi dapat berjalan baik secara individual. Masalah muncul ketika data harus berpindah dari satu aplikasi ke aplikasi lainnya.
Contohnya:
- Data identitas yang sudah dimasukkan pada pendaftaran seharusnya tidak diketik ulang di laboratorium.
- Hasil laboratorium seharusnya dapat dikaitkan dengan pasien dan kunjungan yang benar.
- Resep dari pelayanan klinis seharusnya dapat diteruskan ke farmasi.
- Data pelayanan seharusnya dapat digunakan kembali untuk klaim dan pelaporan.
Tujuan integrasi bukan sekadar membuat komputer saling mengirim data. Tujuannya adalah mengurangi duplikasi pekerjaan, menjaga konsistensi data, mempercepat pelayanan, memperkuat pelaporan, dan mendukung pengambilan keputusan.
7.4 Integrasi dan Interoperabilitas: Apa Bedanya?
Integrasi adalah proses menghubungkan dua atau lebih sistem agar dapat bekerja dalam satu alur.
Interoperabilitas memiliki cakupan lebih luas. Sistem tidak hanya harus terhubung, tetapi juga harus mampu memahami dan menggunakan informasi yang dipertukarkan secara konsisten.
| Aspek | Integrasi | Interoperabilitas |
|---|---|---|
| Fokus | Menghubungkan sistem atau aplikasi | Memastikan data dapat dipahami dan digunakan secara konsisten |
| Pertanyaan utama | Apakah sistem A dapat mengirim data ke sistem B? | Apakah sistem B memahami identitas, struktur, kode, konteks, dan makna data? |
| Kebutuhan | Koneksi, API/interface, mapping | Standar data, identitas, terminologi, aturan bisnis, validasi, dan keamanan |
| Risiko jika lemah | Data tidak terkirim | Data terkirim tetapi salah dipahami atau tidak dapat digunakan |
7.5 API sebagai Jembatan Antar Sistem
Application Programming Interface (API) dapat dipahami sebagai mekanisme yang memungkinkan suatu aplikasi meminta atau mengirim informasi kepada aplikasi lain berdasarkan aturan yang telah ditentukan.
Dalam ekosistem kesehatan, API memungkinkan aplikasi pendaftaran, RME, laboratorium, farmasi, klaim, dan sistem eksternal berkomunikasi tanpa pengguna harus memindahkan data secara manual.
Alamat atau titik layanan yang menerima permintaan.
Permintaan yang dikirim dari aplikasi sumber.
Data yang dibawa dalam permintaan.
Jawaban sistem tujuan, misalnya berhasil atau gagal.
API dapat dianalogikan sebagai loket pelayanan resmi antar sistem. Loket memiliki alamat, aturan, identitas pemohon, jenis layanan, syarat yang harus dipenuhi, serta bukti apakah transaksi diterima atau ditolak.
7.6 Arsitektur Integrasi Internal dan Eksternal
Integrasi dapat terjadi di dalam organisasi maupun antara fasilitas kesehatan dengan ekosistem di luar organisasi.
Integrasi internal dapat menghubungkan RME, laboratorium, farmasi, pendaftaran, klaim, dan pelaporan. Integrasi eksternal menghubungkan sistem fasilitas dengan platform atau organisasi lain.
RME
Lab
Farmasi
Mapping • Validasi • Security • Logging
Penjamin
Platform Nasional
Lapisan integrasi membantu organisasi mengelola mapping, validasi, keamanan, dan pencatatan transaksi secara lebih terpusat.
7.7 HL7 FHIR sebagai Standar Pertukaran Informasi Kesehatan
Standardisasi dibutuhkan agar berbagai aplikasi tidak menggunakan format pertukaran data yang berbeda-beda.
HL7 FHIR (Fast Healthcare Interoperability Resources) menggunakan unit informasi terstruktur yang disebut resource. Bagi mahasiswa Administrasi Kesehatan, yang terpenting bukan menghafal sintaks pemrogramannya, tetapi memahami makna dan posisi setiap resource dalam proses pelayanan.
| Resource | Makna | Konteks Administrasi |
|---|---|---|
| Patient | Identitas pasien | Menghubungkan pelayanan dengan pasien yang tepat |
| Organization | Identitas organisasi | Menunjukkan fasilitas yang terlibat |
| Practitioner | Tenaga kesehatan | Mengaitkan pelayanan dengan pemberi layanan |
| Encounter | Kunjungan/episode pelayanan | Konteks transaksi pelayanan |
| Observation | Hasil pengamatan/pemeriksaan | Hasil pemeriksaan tertentu |
| Condition | Masalah/kondisi kesehatan | Kondisi atau diagnosis dalam pelayanan |
| MedicationRequest | Permintaan/resep obat | Menghubungkan pelayanan dengan proses farmasi |
FHIR dipelajari pada level konsep agar mahasiswa mampu membaca struktur pertukaran data dan berdiskusi secara efektif dengan tim teknis.
7.8 SATUSEHAT dan Ekosistem Pertukaran Data Kesehatan
SATUSEHAT merupakan bagian dari ekosistem pertukaran data kesehatan nasional yang menghubungkan berbagai sistem informasi atau aplikasi dalam ekosistem digital kesehatan Indonesia.
Dalam konteks fasilitas kesehatan, koneksi tidak cukup hanya memastikan bahwa data dapat dikirim. Fasilitas juga perlu memastikan bahwa:
- data sumber benar;
- identitas konsisten;
- mapping data tepat;
- struktur data valid;
- koneksi aman;
- respons sistem dicatat;
- kesalahan dapat ditindaklanjuti.
Kualitas pertukaran data eksternal sangat bergantung pada kualitas data dan tata kelola proses di dalam fasilitas kesehatan.
7.9 Identitas: Fondasi yang Sering Terabaikan
Pertukaran data hanya bermanfaat apabila sistem dapat memastikan siapa atau apa yang sedang dibicarakan.
Kesalahan identitas dapat menyebabkan data pelayanan dikaitkan dengan pasien yang salah, organisasi yang keliru, atau tenaga kesehatan yang tidak tepat.
Identitas yang perlu dikelola antara lain:
- identitas pasien;
- identitas organisasi;
- lokasi pelayanan;
- tenaga kesehatan;
- aplikasi atau sistem pengirim;
- pengguna atau layanan teknis yang mengakses API.
Masalah interoperabilitas sering terlihat sebagai masalah teknologi, padahal akar masalahnya dapat berasal dari master data yang tidak konsisten, identitas ganda, atau proses administrasi antarunit yang berbeda.
7.10 Alur Pertukaran Data yang Aman dan Terkendali
Pertukaran data yang baik dimulai dari sistem sumber, kemudian data dipetakan, diperiksa identitas dan kelengkapannya, divalidasi, diamankan, lalu dikirim melalui API.
Setelah sistem tujuan menerima data, respons harus dibaca dan dicatat. Transaksi gagal tidak boleh dibiarkan tanpa tindak lanjut.
Organisasi harus menentukan siapa yang memantau kegagalan, siapa yang memperbaiki data sumber, kapan transaksi dikirim ulang, serta bagaimana bukti transaksi disimpan.
7.11 Keamanan Koneksi
Data kesehatan bersifat sensitif. Karena itu, pertukaran informasi harus menggunakan kontrol keamanan yang memadai.
| Kontrol | Tujuan | Pertanyaan Audit |
|---|---|---|
| HTTPS / Enkripsi | Melindungi data selama transmisi | Apakah koneksi menggunakan kanal aman? |
| Autentikasi | Memastikan identitas sistem/pengguna | Siapa yang memiliki credential? |
| Otorisasi | Membatasi akses sesuai fungsi | Apakah aplikasi hanya mengakses data yang dibutuhkan? |
| Token Management | Melindungi credential | Bagaimana token disimpan dan diperbarui? |
| Logging | Menelusuri transaksi dan insiden | Apakah transaksi sukses/gagal dapat ditelusuri? |
| Monitoring & Alert | Mendeteksi gangguan lebih cepat | Siapa menerima notifikasi ketika transaksi gagal? |
7.12 Risiko Integrasi dan Interoperabilitas
| Risiko | Dampak | Mitigasi |
|---|---|---|
| API/sistem tujuan tidak tersedia | Transaksi tertunda/menumpuk | Queue, retry, monitoring, eskalasi |
| Mapping data salah | Informasi keliru | Data dictionary, validasi, testing |
| Identitas tidak konsisten | Duplikasi/salah kait transaksi | Master data dan deduplikasi |
| Credential/token bermasalah | Koneksi ditolak | Pengelolaan credential dan masa berlaku |
| Internet terganggu | Pengiriman eksternal berhenti | Koneksi cadangan, store-and-forward, SOP |
| Logging tidak memadai | Kesalahan sulit ditelusuri | Central logging dan ID transaksi |
7.13 Studi Kasus: Integrasi Puskesmas
Puskesmas “Harapan Sehat”
Puskesmas menggunakan aplikasi pendaftaran dan RME dari vendor A, laboratorium dari vendor B, dan farmasi dari vendor C.
Petugas laboratorium dan farmasi masih mengetik ulang sebagian identitas pasien. Setiap aplikasi memiliki kode pasien sendiri. Internet hanya memiliki satu jalur, dokumentasi API belum lengkap, dan belum tersedia dashboard untuk memantau transaksi yang gagal.
Keinginan manajemen:- identitas pasien tidak perlu diketik ulang;
- hasil laboratorium muncul di RME;
- resep dapat diteruskan ke farmasi;
- transaksi eksternal dapat ditelusuri statusnya.
Tentukan sumber dan tujuan data, identitas yang harus konsisten, posisi API/lapisan integrasi, kontrol keamanan, serta mekanisme penanganan transaksi gagal.
7.14 Contoh Penyelesaian Singkat
Langkah pertama adalah menetapkan satu sumber identitas pasien dan mekanisme pencocokan yang jelas sehingga laboratorium dan farmasi tidak membuat identitas baru secara independen.
Puskesmas kemudian perlu menyusun dokumentasi koneksi yang memuat endpoint, jenis data, format, pemilik proses, serta pihak yang bertanggung jawab jika terjadi kegagalan.
Semua koneksi perlu menggunakan autentikasi, otorisasi, enkripsi, logging, dan monitoring.
Jika pengiriman eksternal gagal, transaksi tidak boleh hilang. Status transaksi perlu disimpan, penyebabnya dianalisis, dan pengiriman diulang melalui mekanisme yang aman setelah masalah selesai.
7.15 Workshop Kelas: Diagram Konektivitas
- Pilih skenario Puskesmas, klinik, atau rumah sakit sederhana.
- Tentukan minimal empat aplikasi internal.
- Tentukan satu atau dua sistem eksternal yang relevan.
- Gambar sumber data, arah pertukaran, lapisan API, dan sistem tujuan.
- Tandai data atau identitas yang harus konsisten.
- Tambahkan kontrol keamanan dan titik monitoring.
- Identifikasi minimal tiga risiko integrasi beserta mitigasinya.
Produk: 1 halaman atau 1 slide diagram konektivitas internal–eksternal beserta narasi singkat.
7.16 Rubrik Penilaian Produk
| Aspek | Bobot | Indikator |
|---|---|---|
| Logika arsitektur integrasi | 25% | Sumber, API, tujuan dan arah data logis |
| Alur & standardisasi data | 25% | Identitas, mapping, validasi dan respons jelas |
| Keamanan koneksi | 20% | Autentikasi, otorisasi, enkripsi dan logging |
| Risiko & mitigasi | 20% | Risiko realistis dan mitigasi relevan |
| Kejelasan penyajian | 10% | Diagram mudah dibaca dan argumentatif |
7.17 Evaluasi Formatif Individu
- Jelaskan perbedaan integrasi dan interoperabilitas dengan contoh pada fasilitas kesehatan.
- Apa fungsi API dalam pertukaran data antar aplikasi?
- Mengapa identitas pasien dan organisasi harus konsisten?
- Sebutkan empat kontrol keamanan pada koneksi API.
- Apa fungsi validasi dan logging setelah data dikirim?
- Jika koneksi eksternal gagal selama dua jam, bagaimana transaksi yang belum terkirim harus dikelola?
7.18 Rangkuman
Integrasi menghubungkan aplikasi, sedangkan interoperabilitas memastikan informasi dapat dipertukarkan dan digunakan dengan struktur serta makna yang konsisten.
API merupakan salah satu mekanisme komunikasi antar sistem, tetapi keberhasilan interoperabilitas juga bergantung pada identitas, standardisasi data, mapping, validasi, keamanan, monitoring, dan tata kelola.
Kompetensi utama administrator kesehatan bukan menulis kode API, tetapi memahami proses, sumber dan tujuan data, risiko, kegagalan transaksi, serta pembagian tanggung jawab antara organisasi dan vendor.
Interoperabilitas adalah gabungan antara proses bisnis + data + teknologi + keamanan + tata kelola. Koneksi yang berhasil secara teknis belum tentu menghasilkan informasi yang benar jika identitas, mapping, validasi dan proses operasional tidak tertata.
7.19 Istilah Kunci
| Istilah | Makna Ringkas |
|---|---|
| Integrasi | Menghubungkan sistem agar bekerja dalam satu alur |
| Interoperabilitas | Kemampuan sistem berbeda bertukar dan menggunakan informasi secara konsisten |
| API | Antarmuka komunikasi antar aplikasi |
| FHIR | Standar pertukaran informasi kesehatan berbasis resource |
| Resource | Unit informasi terstruktur dalam FHIR |
| Payload | Data dalam request atau response API |
| Mapping | Pemetaan elemen data sumber ke struktur tujuan |
| Authentication | Pembuktian identitas sistem/pengguna |
| Authorization | Penentuan hak akses |
| Audit Trail | Catatan aktivitas untuk penelusuran transaksi |
7.20 Refleksi
Jika dua aplikasi dapat saling mengirim data tetapi menggunakan identitas pasien, kode, atau definisi variabel yang berbeda, apakah kedua sistem tersebut sudah dapat disebut interoperabel? Jelaskan alasan dan dampaknya terhadap administrasi kesehatan.
Checklist Review Integrasi/Interoperabilitas
| No. | Pertanyaan Review | Ya/Belum |
|---|---|---|
| 1 | Apakah sumber dan tujuan data sudah jelas? | |
| 2 | Apakah identitas pasien, organisasi, tenaga dan sistem konsisten? | |
| 3 | Apakah mapping data terdokumentasi? | |
| 4 | Apakah validasi dan penanganan error dijelaskan? | |
| 5 | Apakah autentikasi dan otorisasi ditetapkan? | |
| 6 | Apakah jalur transmisi menggunakan koneksi aman? | |
| 7 | Apakah transaksi sukses/gagal dicatat dan dimonitor? | |
| 8 | Apakah terdapat mekanisme eskalasi jika integrasi gagal? |
7.21 Referensi
- Program Studi S1 Administrasi Kesehatan UMS Rappang. RPS OBE Mata Kuliah Infrastruktur Sistem Informasi Kesehatan, 2026.
- Kementerian Kesehatan Republik Indonesia. Dokumentasi SATUSEHAT Platform: FHIR dan Panduan Interoperabilitas.
- Health Level Seven International (HL7). FHIR Specification – Fast Healthcare Interoperability Resources.
- Kementerian Kesehatan Republik Indonesia. Peraturan Menteri Kesehatan Nomor 24 Tahun 2022 tentang Rekam Medis.
Setelah menyelesaikan Bab VII, mahasiswa seharusnya mampu membaca suatu arsitektur integrasi bukan hanya dari jalur koneksinya, tetapi juga dari proses bisnis, identitas, kualitas data, keamanan, monitoring, dan mekanisme penanganan kegagalan.
Program Studi S1 Administrasi Kesehatan – UMS Rappang
Dosen Pengampu: Sunandar Said, S.Kep., Ns., M.Kes.
Komentar
Posting Komentar
Terima kasih atas komentarnya