Konfigurasi Billing Multi-Payer SIMRS: BPJS, Asuransi, & Umum (Panduan Lengkap)

Manajemen billing di fasilitas kesehatan modern, baik rumah sakit maupun klinik, merupakan salah satu area operasional paling krusial sekaligus paling kompleks. Dengan beragamnya skema pembayaran di Indonesia—mulai dari Jaminan Kesehatan Nasional (JKN) melalui BPJS Kesehatan, berbagai polis asuransi swasta, hingga pembayaran tunai oleh pasien umum—fasilitas kesehatan (faskes) dihadapkan pada tantangan besar. Setiap skema memiliki regulasi, prosedur klaim, dan struktur tarif yang unik, seringkali berubah, dan memerlukan penanganan spesifik. Tanpa sistem billing multi-payer yang terintegrasi dan efisien dalam Sistem Informasi Manajemen Rumah Sakit (SIMRS) Anda, risiko penolakan klaim, kebocoran pendapatan, keterlambatan pembayaran, dan ketidakpuasan pasien akan meningkat signifikan. Permasalahan ini bukan hanya sekadar urusan administratif, melainkan inti dari keberlanjutan finansial dan kualitas layanan faskes. Artikel ini akan mengupas tuntas arsitektur, detail implementasi teknis, contoh kode, penanganan data, hingga praktik terbaik untuk membangun atau menyempurnakan konfigurasi billing multi-payer di SIMRS Anda, memastikan proses yang akurat, cepat, dan sesuai regulasi.

Konsep Dasar dan Arsitektur Billing Multi-Payer

Sistem billing multi-payer harus dirancang untuk mengakomodasi tiga kategori utama pembayaran yang umum di Indonesia: BPJS Kesehatan, Asuransi Swasta, dan Pasien Umum. Masing-masing memiliki karakteristik dan tantangan tersendiri. BPJS Kesehatan, sebagai jaminan sosial, beroperasi di bawah regulasi ketat seperti Peraturan Menteri Kesehatan (PMK) No. 51 Tahun 2018 tentang Tarif Pelayanan Kesehatan dalam Program Jaminan Kesehatan, menggunakan sistem INACBG (Indonesia Case Base Groups) untuk klaim rawat inap dan rawat jalan, serta VClaim untuk proses verifikasi dan pengajuan klaim. Integrasi dengan sistem P-Care untuk pelayanan primer juga menjadi keharusan.

Asuransi swasta, di sisi lain, memiliki variasi polis, jaringan provider (panel), plafon manfaat, dan prosedur klaim yang sangat beragam. Proses seperti pengajuan Letter of Guarantee (LoG) atau Surat Jaminan, verifikasi eligibilitas online melalui portal khusus asuransi, hingga koordinasi manfaat (CoB) dengan BPJS Kesehatan, menambah lapisan kompleksitas. Sementara itu, pasien umum menuntut transparansi tarif dan kemudahan pembayaran langsung, baik tunai, debit, kartu kredit, maupun e-wallet. Keakuratan dalam penerapan diskon, paket layanan, dan penagihan mandiri menjadi kunci.

Arsitektur ideal untuk billing multi-payer dalam SIMRS adalah modul terpusat yang mampu mengelola seluruh siklus pendapatan, mulai dari pendaftaran pasien, verifikasi eligibilitas, pencatatan tindakan dan obat, perhitungan tagihan, hingga proses klaim dan pelaporan. Komponen kuncinya meliputi: Master Data Payer yang berisi detail setiap asuransi atau skema BPJS; Master Tarif yang memungkinkan penetapan harga berbeda per layanan, tindakan, dan obat berdasarkan jenis payer; Modul Verifikasi yang terintegrasi dengan API eksternal (VClaim, portal asuransi) untuk validasi real-time; Modul Klaim untuk otomatisasi pengajuan klaim ke berbagai pihak; dan Modul Koordinasi Manfaat (CoB) untuk pasien dengan lebih dari satu penjamin. Sebagai contoh, pasien yang datang ke IGD akan melewati proses verifikasi awal; jika terdaftar BPJS, sistem akan memprioritaskan pengecekan eligibilitas BPJS. Apabila kasus tidak dicover BPJS atau pasien memiliki asuransi swasta tambahan, sistem akan mengarahkan ke alur verifikasi asuransi swasta atau opsi pembayaran umum secara fleksibel.

Detail Implementasi Teknis dalam SIMRS

Untuk membangun sistem billing multi-payer yang kokoh, pemilihan teknologi dan standar yang tepat sangat krusial. Dalam konteks SIMRS, kami merekomendasikan penggunaan PostgreSQL 16.x sebagai database relasional karena keandalannya, skalabilitas, dan dukungan fitur JSONB yang sangat berguna untuk menyimpan data semi-terstruktur dari API eksternal. Struktur tabel kunci meliputi: tabel payers (id, nama, tipe_payer, endpoint_api, kredensial_api, dll.), tabel tariffs (id, item_layanan_id, payer_id, harga, is_aktif, tgl_berlaku, dll.), tabel patient_billing (id, pasien_id, tgl_registrasi, total_tagihan, total_dibayar, sisa_tagihan, status, payer_utama_id, payer_tambahan_id, dll.), dan tabel claim_submissions (id, billing_id, payer_id, tgl_submission, status_klaim, response_api, dll.).

Integrasi API adalah jantung dari billing multi-payer. Untuk BPJS Kesehatan, integrasi dengan VClaim API 2.0 (versi terbaru) dan P-Care API adalah wajib. Kami menyarankan penggunaan library HTTP client seperti GuzzleHttp di PHP atau Axios di Node.js untuk mempermudah interaksi. Untuk asuransi swasta, tantangannya lebih besar karena belum ada standar API tunggal. Umumnya, faskes perlu berintegrasi dengan RESTful API portal asuransi (misalnya AdMedika, Prudential, Manulife) atau, jika tidak tersedia, mengimplementasikan Robotic Process Automation (RPA) untuk berinteraksi dengan portal web asuransi. Penting untuk selalu mengacu pada dokumentasi API resmi dari masing-masing payer.

Di sisi backend, Laravel 11.x dengan PHP 8.2+ adalah pilihan yang sangat baik karena ekosistemnya yang kaya, kemudahan pengembangan, dan fitur-fitur seperti Eloquent ORM yang mempermudah interaksi database. Untuk frontend, Vue.js 3.x yang dibangun dengan Vite menawarkan pengalaman pengguna yang responsif dan efisien. Dalam hal standar data, adopsi FHIR R4 (Fast Healthcare Interoperability Resources Release 4) sangat direkomendasikan untuk representasi data internal pasien, encounter, dan klaim. Meskipun belum semua payer di Indonesia menggunakan FHIR, memetakan data internal ke standar FHIR akan mempermudah integrasi di masa depan, termasuk dengan platform SatuSehat. Jika masih ada sistem lama yang perlu diintegrasikan, pertimbangkan juga untuk mendukung HL7 v2.5.1.

Penggunaan alat bantu seperti Postman untuk pengujian API, Docker untuk deployment yang konsisten, dan Git untuk version control adalah praktik standar yang akan mempercepat pengembangan dan menjaga kualitas kode. Pastikan juga sistem Anda memiliki modul logging yang robust untuk melacak setiap transaksi dan error, misalnya dengan Sentry atau Monolog.

Contoh Kode Implementasi Konfigurasi Payer

Berikut adalah contoh implementasi pada framework Laravel 11.x untuk model Payer dan Tariff, serta servis untuk interaksi dengan API BPJS VClaim.

Pertama, kita definisikan migrasi database untuk tabel payers dan tariffs. Ini akan menjadi fondasi untuk menyimpan data penjamin dan tarif spesifik mereka. Perhatikan kolom endpoint_api dan credentials pada tabel payers yang memungkinkan fleksibilitas untuk berbagai penjamin.

<?phpnamespace DatabaseMigrations;use IlluminateDatabaseMigrationsMigration;use IlluminateDatabaseSchemaBlueprint;use IlluminateSupportFacadesSchema;return new class extends Migration{    public function up(): void    {        Schema::create('payers', function (Blueprint $table) {            $table->id();            $table->string('name');            $table->enum('type', ['BPJS', 'ASURANSI', 'UMUM']);            $table->string('api_endpoint')->nullable();            $table->json('api_credentials')->nullable();            $table->boolean('is_active')->default(true);            $table->timestamps();        });        Schema::create('tariffs', function (Blueprint $table) {            $table->id();            $table->foreignId('service_item_id')->constrained('service_items'); // Asumsi ada tabel service_items            $table->foreignId('payer_id')->constrained('payers');            $table->decimal('price', 15, 2);            $table->date('effective_date');            $table->date('end_date')->nullable();            $table->boolean('is_active')->default(true);            $table->timestamps();        });    }    public function down(): void    {        Schema::dropIfExists('tariffs');        Schema::dropIfExists('payers');    }};

Kemudian, kita buat model Eloquent untuk Payer dan Tariff, lengkap dengan relasi. Relasi ini akan mempermudah kita mengambil tarif yang berlaku untuk penjamin tertentu.

<?phpnamespace AppModels;use IlluminateDatabaseEloquentFactoriesHasFactory;use IlluminateDatabaseEloquentModel;use IlluminateDatabaseEloquentRelationsHasMany;class Payer extends Model{    use HasFactory;    protected $fillable = ['name', 'type', 'api_endpoint', 'api_credentials', 'is_active'];    protected $casts = [        'api_credentials' => 'array',        'is_active' => 'boolean',    ];    public function tariffs(): HasMany    {        return $this->hasMany(Tariff::class);    }}<?phpnamespace AppModels;use IlluminateDatabaseEloquentFactoriesHasFactory;use IlluminateDatabaseEloquentModel;use IlluminateDatabaseEloquentRelationsBelongsTo;class Tariff extends Model{    use HasFactory;    protected $fillable = ['service_item_id', 'payer_id', 'price', 'effective_date', 'end_date', 'is_active'];    protected $casts = [        'is_active' => 'boolean',        'effective_date' => 'date',        'end_date' => 'date',    ];    public function serviceItem(): BelongsTo    {        return $this->belongsTo(ServiceItem::class);    }    public function payer(): BelongsTo    {        return $this->belongsTo(Payer::class);    }}

Selanjutnya, contoh servis untuk berinteraksi dengan API BPJS VClaim. Servis ini akan menggunakan kredensial yang tersimpan di tabel payers untuk otentikasi. Anda perlu menginstal GuzzleHttp (composer require guzzlehttp/guzzle) terlebih dahulu.

<?phpnamespace AppServices;use AppModelsPayer;use GuzzleHttpClient;use GuzzleHttpExceptionRequestException;use CarbonCarbon;class BpjsVclaimService{    protected Client $client;    protected Payer $bpjsPayer;    public function __construct()    {        $this->bpjsPayer = Payer::where('type', 'BPJS')->where('is_active', true)->firstOrFail();        $this->client = new Client([            'base_uri' => $this->bpjsPayer->api_endpoint,            'headers' => $this->getBpjsHeaders(),        ]);    }    protected function getBpjsHeaders(): array    {        $consId = $this->bpjsPayer->api_credentials['cons_id'];        $secretKey = $this->bpjsPayer->api_credentials['secret_key'];        $userKey = $this->bpjsPayer->api_credentials['user_key'];        $timestamp = strval(time() * 1000);        $signature = hash_hmac('sha256', $consId . '&' . $timestamp, $secretKey, false);        return [            'X-cons-id' => $consId,            'X-timestamp' => $timestamp,            'X-signature' => $signature,            'user_key' => $userKey,            'Content-Type' => 'application/json',        ];    }    public function checkEligibility(string $noKartu, string $tglPelayanan): array    {        try {            $response = $this->client->get("/peserta/nokartu/{$noKartu}/tglpelayanan/{$tglPelayanan}");            return json_decode($response->getBody()->getContents(), true);        } catch (RequestException $e) {            logger()->error("BPJS VClaim Eligibility Error: " . $e->getMessage(), ['request' => $e->getRequest(), 'response' => $e->hasResponse() ? $e->getResponse() : null]);            throw new Exception("Gagal memeriksa eligibilitas BPJS: " . $e->getMessage());        }    }    public function createSep(array $sepData): array    {        try {            $response = $this->client->post('/SEP/2.0/insert', [                'json' => ['request' => ['t_sep' => $sepData]],            ]);            return json_decode($response->getBody()->getContents(), true);        } catch (RequestException $e) {            logger()->error("BPJS VClaim SEP Creation Error: " . $e->getMessage(), ['request' => $e->getRequest(), 'response' => $e->hasResponse() ? $e->getResponse() : null]);            throw new Exception("Gagal membuat SEP BPJS: " . $e->getMessage());        }    }}

Kode di atas menunjukkan bagaimana kita dapat mengelola data penjamin dan tarif secara terstruktur. Model Payer menyimpan detail otentikasi API dalam format JSON, memungkinkan sistem beradaptasi dengan berbagai kredensial. Servis BpjsVclaimService mengimplementasikan logika untuk membuat header otentikasi sesuai standar BPJS dan melakukan panggilan API. Fungsi checkEligibility dan createSep adalah contoh metode dasar untuk berinteraksi dengan API VClaim. Penanganan error dasar dengan logging juga disertakan untuk membantu proses debugging.

Contoh Payload Data dan Penanganan Error

Interaksi dengan API eksternal, terutama untuk klaim, memerlukan pemahaman mendalam tentang struktur payload yang diharapkan. Berikut adalah contoh payload JSON realistis untuk membuat Surat Eligibilitas Peserta (SEP) melalui API VClaim BPJS versi 2.0. Struktur ini mencakup semua detail yang diperlukan untuk mengidentifikasi pasien, layanan, dan informasi rujukan.

{  "request": {    "t_sep": {      "noKartu": "0001234567890",      "tglSep": "2024-07-26",      "ppkPelayanan": "0101R001",      "jnsPelayanan": "2",      "klsRawat": {        "kodeKelas": "3"      },      "noMR": "MR0012345",      "catatan": "Suspek DHF",      "diagAwal": "A91",      "poliTujuan": "INT",      "asalRujukan": "1",      "tglRujukan": "2024-07-25",      "noRujukan": "RJK0001234567",      "katarak": {        "katarak": "0"      },      "cob": {        "cob": "0"      },      "lakaLantas": {        "statusLaka": "0",        "lokasiLaka": ""      },      "penjamin": {        "penjamin": ""      },      "user": "nugroho.setiawan"    }  }}

Penanganan error adalah bagian krusial dari integrasi API. Skenario umum adalah saat API BPJS mengembalikan error karena data tidak valid atau masalah koneksi. Contoh error message yang sering terjadi:

{  "metaData": {    "code": "400",    "message": "Nomor Kartu BPJS tidak ditemukan atau tidak aktif."  }}

Untuk menangani error semacam ini, strategi yang kokoh sangat diperlukan: Pertama, implementasikan validasi data yang ketat di sisi SIMRS sebelum mengirimkan payload. Misalnya, pastikan nomor kartu BPJS memiliki format yang benar dan tanggal pelayanan tidak di masa depan. Kedua, gunakan mekanisme logging yang detail. Setiap kali terjadi error API, catat payload request, response error, dan timestamp. Ini penting untuk audit dan debugging. Ketiga, terapkan strategi retry dengan exponential backoff untuk error-error transien (misalnya, network timeout atau server sibuk). Jika error persisten (misalnya 'Nomor Kartu tidak ditemukan'), sistem harus segera memberikan notifikasi ke pengguna dengan pesan yang informatif.

Keempat, sediakan alur fallback. Jika verifikasi BPJS gagal karena alasan non-teknis (misalnya pasien memang tidak aktif), sistem harus secara otomatis mengarahkan ke opsi pembayaran asuransi swasta atau umum. Kelima, bangun dashboard monitoring API yang menampilkan status uptime, response time, dan tingkat error dari setiap integrasi. Ini memungkinkan tim IT untuk proaktif dalam menangani masalah sebelum berdampak luas pada operasional. Terakhir, selalu perbarui dokumentasi API dan sesuaikan kode Anda jika ada perubahan pada spesifikasi API dari pihak payer.

Best Practices

1. Standardisasi Master Data yang Konsisten: Pastikan kode layanan, tindakan medis, diagnosis, dan obat-obatan seragam di seluruh sistem SIMRS dan dimapping dengan standar internasional seperti ICD-10/9-CM untuk diagnosis, ICD-9-CM/SNOMED CT untuk tindakan. Konsistensi ini krusial untuk akurasi klaim BPJS (INACBG) dan asuransi swasta, serta meminimalkan potensi dispute.

2. Otomatisasi Verifikasi Eligibilitas Real-time: Integrasikan modul verifikasi dengan API BPJS VClaim dan portal asuransi swasta secara langsung. Verifikasi eligibilitas pasien secara real-time pada saat pendaftaran atau sebelum layanan diberikan akan secara drastis mengurangi penolakan klaim akibat status kepesertaan yang tidak aktif atau polis yang tidak mencakup layanan tertentu.

3. Manajemen Tarif Berjenjang dan Berversi: Implementasikan sistem tarif yang fleksibel, memungkinkan penetapan harga yang berbeda untuk jenis layanan, tindakan, dan obat berdasarkan jenis payer (BPJS, asuransi, umum) serta kelas perawatan. Sistem harus mendukung versioning tarif dengan tanggal efektif berlaku, sehingga riwayat perubahan tarif dapat dilacak dan diaudit.

4. Implementasi Audit Trail Lengkap: Catat setiap aktivitas penting dalam modul billing, termasuk penambahan, perubahan, dan penghapusan data, serta status klaim. Setiap entri harus mencakup identitas pengguna, timestamp, dan detail perubahan. Audit trail yang komprehensif sangat penting untuk akuntabilitas, penyelesaian sengketa, dan kepatuhan terhadap regulasi.

5. Desain Antarmuka Pengguna (UI/UX) yang Intuitif: Pastikan antarmuka untuk petugas billing dan pendaftaran mudah digunakan, meminimalkan kesalahan input data, dan mempercepat alur kerja. Desain yang baik akan mengurangi waktu tunggu pasien dan meningkatkan efisiensi operasional, terutama di lingkungan yang serba cepat seperti rumah sakit.

6. Sistem Pelaporan dan Analitik yang Robust: Sediakan dashboard dan laporan yang menampilkan metrik kunci seperti status klaim (diajukan, disetujui, ditolak, pending), rasio penolakan per payer, pendapatan per jenis payer, dan durasi pembayaran. Data ini esensial untuk analisis kinerja keuangan, identifikasi area masalah, dan pengambilan keputusan strategis oleh manajemen.

7. Keamanan Data dan Kepatuhan Regulasi: Terapkan praktik keamanan data terbaik, termasuk enkripsi data saat transit dan saat disimpan (at rest), otentikasi multi-faktor, dan Role-Based Access Control (RBAC). Pastikan SIMRS Anda mematuhi regulasi seperti UU Perlindungan Data Pribadi (UU PDP), PMK No. 82 Tahun 2013 tentang SIMRS, dan standar keamanan informasi seperti ISO 27001 jika memungkinkan.

8. Strategi Penanganan Kasus Khusus: Siapkan alur kerja dan konfigurasi khusus untuk menangani skenario kompleks seperti Coordination of Benefit (CoB) antara BPJS dan asuransi swasta, pasien rujukan antar faskes, kasus kecelakaan lalu lintas, atau penanganan gawat darurat yang mungkin memiliki prosedur klaim berbeda. Sistem harus mampu mengarahkan petugas secara otomatis.

9. Pelatihan Staf secara Berkala: Lakukan pelatihan rutin untuk semua staf yang terlibat dalam proses billing, termasuk petugas pendaftaran, verifikator, dan staf medis. Ini penting untuk memastikan mereka memahami perubahan regulasi BPJS, prosedur klaim asuransi swasta yang baru, dan cara optimal menggunakan fitur-fitur baru di SIMRS, sehingga mengurangi human error.

FAQ

1. Bagaimana cara SIMRS menangani COB (Coordination of Benefit) antara BPJS dan Asuransi Swasta?
   SIMRS harus memiliki modul COB yang memungkinkan pencatatan dua payer atau lebih untuk satu episode perawatan. Sistem akan memprioritaskan BPJS sebagai payer primer sesuai regulasi yang berlaku, kemudian menghitung sisa tagihan yang dapat diklaim ke asuransi swasta berdasarkan polis dan plafon yang berlaku. Ini memerlukan integrasi data yang kuat antara modul BPJS dan asuransi swasta, serta kemampuan untuk menghasilkan dua jenis klaim terpisah dengan detail yang sesuai untuk masing-masing penjamin.

2. Apa tantangan terbesar dalam integrasi VClaim BPJS dan bagaimana solusinya?
   Tantangan utama seringkali adalah konsistensi data antara SIMRS dan P-Care/VClaim, serta penanganan error API yang terkadang kurang informatif. Solusinya adalah implementasi validasi data yang ketat di sisi SIMRS sebelum mengirim ke VClaim, penggunaan library API wrapper yang handal untuk mengelola otentikasi dan request, dan pembangunan mekanisme retry otomatis dengan logging detail untuk setiap kegagalan. Pastikan juga selalu menggunakan versi API VClaim terbaru untuk kompatibilitas dan fitur keamanan yang diperbarui.

3. Seberapa sering tarif layanan harus diperbarui dalam sistem billing multi-payer?
   Tarif layanan harus diperbarui secara berkala sesuai dengan perubahan kebijakan dari BPJS (misalnya, update INACBG atau regulasi PMK terbaru), revisi kontrak dengan asuransi swasta yang biasanya dilakukan secara tahunan, atau penyesuaian tarif umum oleh manajemen faskes. Idealnya, sistem harus mendukung versioning tarif dan tanggal efektif berlaku, sehingga riwayat tarif tetap tercatat dan dapat diaudit. Peninjauan triwulanan atau semesteran seringkali direkomendasikan untuk tarif asuransi dan umum.

4. Bagaimana SIMRS dapat membantu mengurangi penolakan klaim (dispute) dari payer?
   SIMRS dapat mengurangi penolakan klaim dengan mengotomatisasi verifikasi eligibilitas real-time, memastikan kelengkapan dan akurasi data rekam medis dan billing sebelum klaim diajukan, serta menyediakan fitur peringatan dini untuk potensi klaim yang bermasalah. Implementasi panduan klinis dan protokol perawatan yang terintegrasi juga membantu memastikan kesesuaian tindakan dengan indikasi medis. Selain itu, sistem harus mampu merekam semua bukti pendukung klaim secara digital, seperti hasil pemeriksaan penunjang dan laporan operasi.

5. Apakah ada standar data khusus yang direkomendasikan untuk pertukaran data billing dengan asuransi swasta?
   Meskipun belum ada standar baku yang universal seperti FHIR untuk semua asuransi swasta di Indonesia, banyak yang mulai mengadopsi RESTful API dengan payload JSON. Sangat disarankan untuk bernegosiasi dengan asuransi agar menggunakan standar data yang konsisten (misalnya, menggunakan kode ICD-10 untuk diagnosis, SNOMED CT untuk tindakan). Jika tidak, SIMRS Anda perlu memiliki kemampuan mapping data yang fleksibel untuk menyesuaikan dengan format dan kebutuhan masing-masing asuransi, serta mencatat setiap perubahan format dari waktu ke waktu.

6. Bagaimana cara memastikan keamanan data pasien dan finansial dalam sistem billing multi-payer?
   Keamanan data harus menjadi prioritas utama. Terapkan enkripsi end-to-end untuk data yang transit melalui jaringan dan data at rest yang disimpan dalam database. Gunakan otentikasi multi-faktor untuk akses sistem, dan terapkan Role-Based Access Control (RBAC) untuk membatasi akses berdasarkan peran pengguna. Lakukan audit keamanan secara berkala, pengujian penetrasi, dan pastikan kepatuhan terhadap regulasi privasi data seperti UU Perlindungan Data Pribadi (UU PDP) dan PMK terkait rekam medis elektronik untuk melindungi informasi sensitif pasien.

Mengonfigurasi sistem billing multi-payer yang efektif adalah investasi strategis yang akan membawa dampak positif signifikan pada efisiensi operasional dan stabilitas finansial fasilitas kesehatan Anda. Proses ini memang kompleks, melibatkan integrasi berbagai sistem, kepatuhan terhadap regulasi yang dinamis, dan manajemen data yang presisi. Namun, dengan perencanaan yang matang, pemilihan teknologi yang tepat, dan implementasi praktik terbaik yang kami uraikan, Anda dapat membangun sistem yang tidak hanya mengatasi tantangan, tetapi juga menjadi keunggulan kompetitif. Jika Anda membutuhkan bantuan dalam merancang, mengembangkan, atau mengimplementasikan sistem billing multi-payer yang efisien dan sesuai regulasi, tim Nugroho Setiawan siap menjadi mitra Anda. Dengan pengalaman mendalam di berbagai SIMRS dan integrasi BPJS/SatuSehat/FHIR, kami dapat membantu fasilitas kesehatan Anda mencapai efisiensi operasional dan kepuasan pasien yang lebih baik. Hubungi kami untuk konsultasi lebih lanjut dan wujudkan sistem yang Anda impikan.