FKTP vs FKRTL: Perbedaan yang Memengaruhi Desain Sistem

Salah satu kesalahan yang paling sering saya lihat ketika tim engineering baru masuk ke domain kesehatan adalah menganggap semua "sistem informasi fasilitas kesehatan" itu sama. Padahal dalam ekosistem JKN di Indonesia, ada pembedaan mendasar antara FKTP (Fasilitas Kesehatan Tingkat Pertama) dan FKRTL (Fasilitas Kesehatan Rujukan Tingkat Lanjut), dan pembedaan ini bukan sekadar istilah administratif. Kalau saya bangun modul rekam medis atau billing tanpa memahami bedanya, hasilnya biasanya sistem yang terlalu sederhana untuk rumah sakit, atau terlalu berat untuk puskesmas/klinik. Tulisan ini saya buat sebagai orientasi cepat buat developer yang baru mulai kerja di sistem kesehatan, supaya keputusan desain dari awal sudah tepat.

Apa Bedanya Secara Layanan

Secara sederhana, FKTP adalah pintu masuk pertama pasien: puskesmas, klinik pratama, dokter praktik perorangan, atau klinik gigi. Layanannya bersifat promotif, preventif, dan kuratif dasar. FKRTL adalah fasilitas rujukan lanjutan, biasanya rumah sakit, yang menangani kasus yang butuh spesialis, tindakan, atau rawat inap.

Perbedaan ini melahirkan alur kerja (workflow) yang berbeda secara struktural, bukan cuma beda kompleksitas. Di FKTP, satu kunjungan biasanya selesai dalam satu siklus: pendaftaran, pemeriksaan, diagnosis, resep, selesai. Di FKRTL, satu episode perawatan bisa melintasi banyak unit: IGD atau poli rawat jalan, penunjang (lab, radiologi), rawat inap, kamar operasi, sampai akhirnya pasien pulang atau dirujuk lagi. Kalau saya modelkan keduanya dengan skema data yang sama, salah satu sisi pasti dipaksakan.

Dampaknya ke Desain Data Model

Contoh paling konkret ada di konsep "kunjungan" (encounter). Di sistem FKTP, satu tabel kunjungan dengan status sederhana biasanya cukup:

kunjungan
- id
- pasien_id
- tanggal
- diagnosis_utama
- status (selesai / batal)

Di FKRTL, satu episode perawatan butuh entitas yang lebih berlapis, karena satu pasien bisa berpindah unit berkali-kali dalam satu episode yang sama:

episode_perawatan
- id
- pasien_id
- jenis (rawat_jalan / rawat_inap / igd)
- status

perpindahan_unit
- episode_id
- unit_asal
- unit_tujuan
- waktu_pindah

tindakan
- episode_id
- kode_tindakan
- waktu
- petugas_id

Kalau saya paksakan model FKTP untuk FKRTL, saya akan kesulitan merepresentasikan pasien yang pindah dari IGD ke ruang rawat inap, lalu ke kamar operasi, dalam satu episode yang sama. Sebaliknya, memakai model FKRTL yang berlapis untuk klinik kecil hanya menambah friksi ke petugas yang sebenarnya cuma butuh alur cepat.

Dampaknya ke Integrasi dan Klaim

Perbedaan level layanan ini juga menentukan bagaimana sistem harus terintegrasi dengan sistem eksternal, terutama untuk keperluan klaim JKN. FKTP umumnya bekerja dengan skema kapitasi dan sebagian nonkapitasi, di mana pembiayaan dihitung per jumlah peserta terdaftar, bukan per kunjungan. Ini berarti sistem FKTP perlu kuat di sisi manajemen kepesertaan dan pelaporan kunjungan agregat, tapi tidak selalu butuh detail biaya per tindakan yang sangat rinci.

FKRTL sebaliknya, bekerja dengan skema klaim per episode perawatan (paket INA-CBG dan sejenisnya), yang mensyaratkan detail diagnosis, prosedur, dan lama rawat yang lengkap dan konsisten sebelum klaim bisa diajukan. Karena itu di sistem FKRTL, saya selalu menempatkan validasi kelengkapan data sebagai gate sebelum status episode bisa ditutup, bukan sebagai pengecekan terpisah setelah pasien pulang. Kalau validasi ini baru dijalankan belakangan, tim casemix atau billing akan menemukan data yang bolong justru saat sudah waktunya klaim diajukan, dan itu jauh lebih mahal untuk diperbaiki.

Contoh sederhana pola validasi yang saya pakai sebagai ilustrasi (bukan implementasi final, karena aturan bisnisnya bisa berbeda per fasilitas):

function bisaDitutup(EpisodePerawatan $episode): bool
{
    return $episode->diagnosis_utama !== null
        && $episode->tindakan()->exists()
        && $episode->has_discharge_summary;
}

Yang Perlu Diingat Saat Merancang Fitur

Beberapa prinsip yang saya pegang setiap kali mulai desain fitur baru untuk sistem kesehatan:

• Jangan asumsikan satu model data cocok untuk FKTP dan FKRTL sekaligus. Lebih baik punya modul inti yang fleksibel, lalu tambahkan lapisan khusus sesuai jenis fasilitas, daripada memaksakan satu skema untuk semua.
• Pahami alur bisnis nyata sebelum menulis skema database. Bicara dengan tim rekam medis atau casemix biasanya lebih membuka wawasan daripada membaca dokumentasi teknis saja.
• Perlakukan validasi kelengkapan data sebagai bagian dari alur kerja klinis, bukan hanya sebagai gate teknis di lapisan billing.
• Kalau fasilitas Anda punya keduanya (misalnya jaringan klinik yang juga punya rumah sakit rujukan), pertimbangkan arsitektur modular yang memisahkan konteks FKTP dan FKRTL secara jelas, meski berbagi identitas pasien yang sama.

Intinya, FKTP dan FKRTL bukan cuma istilah administratif dari BPJS. Keduanya mencerminkan dua model layanan klinis yang berbeda, dan sistem informasi yang baik harus mengikuti bentuk layanan itu, bukan sebaliknya. Kalau desain data dan alur kerja sudah selaras dengan realita klinis sejak awal, urusan integrasi dan pelaporan jauh lebih mudah dijaga konsistensinya ke depannya.