Pakarti pakarti.id
Pakarti · Jakarta, Indonesia

Kami membangun perangkat lunak untuk pekerjaan yang diaudit.

Sistem rumah sakit, laboratorium, akuntansi, dan operasional untuk industri teregulasi di Indonesia. Delapan produk, yang telah kami kembangkan — dibangun agar catatannya tetap tegak ketika regulator, auditor, atau analis memintanya.

Lihat portofolio Cara kami membangun
8
produk di tiga vertikal
20
service independen di platform rumah sakit terbesar kami
132
model data klinis di sistem klinik saja
1.000+
pengujian otomatis, berjalan di setiap push
Apa yang kami kerjakan

Pekerjaan teregulasi punya cara gagal yang berbeda.

Perangkat lunak bisnis biasa gagal secara kasatmata — halaman error, ada yang membuat tiket. Perangkat lunak teregulasi gagal diam-diam, dan tampak benar: neraca saldo yang seimbang tetapi salah, hasil laboratorium yang dirilis oleh orang tanpa kewenangan merilisnya, data satu klien yang muncul di laporan klien lain.

Kegagalan seperti itu ditemukan oleh inspektur, auditor, atau analis — jauh setelah rilis yang menyebabkannya. Karena itu kami merancang untuk momen tersebut lebih dulu: catatan yang hanya bisa ditambah, isolasi yang ditegakkan oleh basis data alih-alih oleh kedisiplinan pengembang, nilai statutori yang dikonfigurasi dan berversi alih-alih diingat, serta jaminan pengiriman yang bertahan saat jaringan hilang.

Dan kami bekerja di dalam realitas regulasi Indonesia — Kemenkes/SATUSEHAT, BPJS, BPOM, ISO 15189, SAK EP, PPh 21 — bukan produk internasional yang dipaksakan untuk berfungsi. Istilah di dalam sistem kami adalah istilah yang sudah diucapkan pengguna setiap hari.

Portofolio

Delapan sistem, tiga vertikal.

Statusnya kami tulis apa adanya. Produksi berarti sudah dipasang dan dipakai sungguhan. Beta berarti lengkap untuk cakupan pertamanya dan sedang dibuktikan di lapangan. Dalam pengembangan berarti fondasinya sudah ada dan permukaannya masih bertambah.

Produk Vertikal Fungsinya
Pakarti Klinik Kesehatan Sistem informasi untuk Klinik Pratama, dari pendaftaran sampai farmasi dan penagihan
Pakarti Utama Kesehatan SIMRS untuk RS Kelas Madya — 20 service, bantuan koding berbasis AI, casemix dan remunerasi
ASTM Gateway Kesehatan Konektivitas alat analisis di lokasi — ASTM E1381/E1394 dengan simpan-dan-teruskan
SatyaLab Kesehatan Konsol laboratorium di atas ASTM Gateway — autoverifikasi, mikrobiologi, QC, hasil FHIR ke SATUSEHAT
Akunta Keuangan Pembukuan berpasangan dan pajak Indonesia untuk UKM dan kantor akuntannya
Gajii Keuangan Penggajian: PPh 21 TER, BPJS lima program, aturan Omnibus 75%, delapan jenis pekerja
Pakarti CRM Operasional CRM penjualan B2B multi-tenant — pipeline, prospek, aktivitas, field khusus
Pakarti Support Desk Operasional Tiket layanan multi-tenant dengan SLA berbasis jam kerja dan isolasi di tingkat basis data
Vertikal satu — Kesehatan

Dari klinik pratama hingga ke alat di atas meja laboratorium.

Empat produk yang saling mengunci: dua platform klinis untuk ukuran fasilitas yang berbeda, gateway yang berbicara langsung dengan alat analisis laboratorium, dan konsol laboratorium yang duduk di atasnya. Semuanya melapor ke SATUSEHAT dan berbahasa FHIR R4 di batas integrasinya.

Pakarti Klinik

Sistem Informasi Klinik
Produksi

Sistem klinis dan administratif lengkap yang dibangun untuk Klinik Pratama — satu klinik, atau jaringan kecil. Rawat jalan, farmasi, dan penagihan adalah inti yang sudah matang dan dipakai. Untuk fasilitas dengan skala dan kebutuhan penagihan yang berbeda, ada Pakarti Utama, dibangun untuk skala itu sejak awal.

Dikirim sebagai perangkat lunak multi-tenant dengan control plane sendiri: penyediaan tenant, penguncian hak modul di tingkat paket maupun cabang, akun admin dengan autentikasi dua faktor, impersonasi dukungan berbatas waktu, ekspor data tenant, dan retensi log audit yang mengarsipkan alih-alih menghapus.

Modul klinis dan operasional
  • Front office — registri pasien dengan deteksi duplikat, manajemen antrian, dan papan tayang langsung untuk tiap unit layanan
  • Pemeriksaan — siklus kunjungan, tanda vital berkode LOINC, catatan SOAP pada formulir yang dapat dikonfigurasi, diagnosis ICD-10, resep
  • Farmasi — stok, penerimaan barang, transfer antar cabang, stock opname
  • Pendapatan — penagihan, pembayaran, klaim asuransi
  • Program — pelaporan Indikator Nasional Mutu, Prolanis, skrining risiko PCare
  • Onboarding — importer katalog obat, layanan, tenaga medis, dan pasien
Integrasi
SATUSEHAT FHIR R4 BPJS PCare BPJS VClaim ICD-10 IM LOINC
Operasional
  • Backup basis data tiap malam, disalin ke luar lokasi tiap lima belas menit
  • Laporan error disusun ulang dari daftar-izin, sehingga data pasien tidak pernah meninggalkan server
  • Runbook penerapan dan on-call dirawat bersama kodenya
Dibangun dengan
Rust React Router PostgreSQL 18 Python
132 model data Suite unit, API, dan browser di seluruh aplikasi Continuous integration di setiap push

Pakarti Utama

SIMRS — Platform Manajemen Rumah Sakit, RS Kelas Madya
Produksi

Platform terbesar kami: dua puluh service yang dapat dirilis terpisah di belakang satu aplikasi web berbahasa Indonesia, berkomunikasi lewat exchange event yang durabel alih-alih panggilan langsung. Perjalanan pasien — pendaftaran, antrian, pemeriksaan, resep, penyerahan obat, invoice — adalah koreografi event, dan sebuah papan real-time menunjukkan posisi setiap pasien saat ini.

Poliglot secara sengaja, dan bahasanya mengikuti beban kerjanya. Enam belas service ditulis dalam Rust, sedangkan bantuan koding rekam medis dan prediksi lama rawat berjalan di Python, karena di sanalah perkakas modelnya hidup. Kode lintas-potong yang dipakai bersama service Rust — auth, pelingkupan organisasi, dispatcher outbox — hidup di satu crate, bukan disalin ke tiap service.

Modul
  • Klinis — Pasien (MPI), Pendaftaran & Antrian, Rawat Jalan, Rawat Inap, IGD, Kamar Operasi
  • Penunjang — Laboratorium dan Radiologi, keduanya memakai pola katalog → order → hasil yang sama
  • Rekam medis — Rekam Medis & Koding, dengan saran ICD-10 berbantuan AI
  • Logistik — Farmasi & Inventori: pelacakan batch, stock opname, transfer, pemusnahan, titik pemesanan ulang
  • Pendapatan — Billing, Casemix & Klaim INA-CBG, Laporan
  • SDM — Kepegawaian dengan pelacakan lisensi tenaga medis, dan Remunerasi (jasa medis) dengan akrual, pool, dan rantai persetujuan
  • Platform — Monitoring & Audit, Integrasi, AI & ML, Pengaturan
Yang membedakan
  • Bantuan koding (rekam medis) — pencarian teks penuh ICD digabung dengan model bahasa, untuk memperpendek pencarian koder, bukan menggantikan penilaiannya
  • Prediksi lama rawat — ekstraksi fitur, prediksi yang tercatat, model yang bisa dilatih ulang
  • Papan alur langsung — tahap setiap pasien saat ini, digerakkan aliran event
  • Dokumentasi dwibahasa — 42 halaman dalam bahasa Indonesia dan Inggris, dijaga selaras oleh proses build
Dibangun dengan
Rust React Router Python / FastAPI RabbitMQ PostgreSQL
20 service — 16 Rust, 4 TypeScript, 2 Python 19 modul produk Suite end-to-end per modul Transactional outbox di setiap perubahan state

ASTM Gateway

Konektivitas Alat Analisis — di lokasi
Beta

Bagian yang duduk di atas meja laboratorium. Gateway dua arah ASTM E1381/E1394 antara alat analisis dan sistem di hulu, terhubung lewat TCP — langsung, atau melalui konverter serial-ke-Ethernet — dengan penyambungan ulang dan backoff otomatis.

Setiap byte disimpan lokal sebelum apa pun terjadi: frame mentah dulu, lalu pesan yang terurai, lalu outbox. Bila jalur ke hulu putus, hasil tetap ditangkap dan diteruskan ketika jalur kembali. Laboratorium tidak berhenti bekerja karena sebuah switch rusak.

Cakupan
  • Profil alat — urinalisis, koagulasi, dan kimia klinik saat ini; alat baru berarti satu profil, bukan penulisan ulang
  • Host query — alat bertanya pemeriksaan apa yang harus dijalankan untuk sebuah sampel dan mendapat jawaban seketika
  • Normalisasi hasil — kode pemeriksaan vendor dipetakan ke identitas internal, hasil semikuantitatif diubah menjadi numerik
  • Simpan dan teruskan — percobaan ulang dengan backoff dan batas jumlah percobaan, sehingga satu pesan rusak tidak pernah menyumbat antrean
  • Endpoint operasional — health, status koneksi per alat, statistik outbox
  • Simulator meja — memerankan sisi alat, sehingga integrasi terbukti sebelum ada yang menyentuh instrumen sungguhan
Protokol
ASTM E1381 ASTM E1394 TCP / serial
Dibangun dengan
NestJS SQLite Drizzle Docker

Basis data tertanam, satu kontainer. Berjalan di mesin kecil apa pun yang sudah ada di laboratorium.

Lapisan protokol murni dan bebas I/O — framing, state machine sesi, dan parser diuji terpisah

SatyaLab

Sistem Informasi Laboratorium — oleh Pakarti
Beta

Konsol laboratorium yang duduk di atas ASTM Gateway: menerima hasil alat yang sudah dinormalisasi, menjalankan autoverifikasi, dan mengelola siklus order sampai hasil dirilis. Alur intinya sudah terbukti ujung ke ujung — terima hasil, autoverifikasi, tinjau/rilis, FHIR, dorong ke SATUSEHAT — dan domain lain (mikrobiologi, QC, billing) dibangun di atas alur itu.

Autoverifikasi mengikuti subset CLSI AUTO15: flag instrumen, rentang yang bisa dilaporkan, nilai kritis, dan uji delta terhadap hasil sebelumnya pasien, semuanya menahan hasil untuk ditinjau analis alih-alih dirilis otomatis — dan mikrobiologi selalu ditinjau manusia, tidak pernah lolos otomatis.

Modul
  • Order & worklist — penerimaan sampel, pelacakan spesimen, lembar kerja per instrumen
  • Mikrobiologi — laporan spesimen, uji kepekaan (AST), dan antibiogram kumulatif (CLSI M39)
  • QC — aturan Westgard multirule dan bagan Levey-Jennings per seri kontrol
  • Instrumen — ingest hasil idempoten dari armada gateway, host-query order per alat
  • Rujukan & billing — intake rujukan dari klinik pengirim, tarif dan penagihan
  • Kepatuhan — hasil dirilis sebagai FHIR R4, didorong ke SATUSEHAT, jejak audit dan hak akses per peran
Integrasi
SATUSEHAT FHIR R4 ASTM Gateway
Dibangun dengan
React Router PostgreSQL Drizzle pg-boss
Ingest tahan duplikat lewat kunci idempoten per gateway; job SATUSEHAT berjalan di worker terpisah dengan retry dan backoff
Vertikal dua — Keuangan & Pajak

Angka yang berujung menjadi pelaporan.

Pembukuan dan penggajian untuk perusahaan Indonesia. Keduanya menghasilkan angka yang berakhir di sebuah pelaporan statutori, dan itulah yang menetapkan standarnya: nilai statutori dikonfigurasi dan berversi alih-alih diingat, uang tidak pernah melewati bilangan titik-mengambang, dan buku besar tidak bisa disunting setelah dicatat.

Akunta

Akuntansi Berpasangan & Pajak
Produksi

Pembukuan berpasangan untuk UKM Indonesia, dengan konsol untuk kantor akuntan yang mengerjakan pembukuan itu. Kegagalan yang menjadi alasan produk ini ada tertulis di dalam sumbernya sendiri: neraca saldo yang seimbang tetapi salah.

Buku besar hanya bisa ditambah, dan basis data yang menegakkannya. Trigger menolak setiap update atau delete pada entri yang sudah diposting, dan entri yang tidak seimbang ditolak oleh deferred constraint saat commit — bukan sekadar oleh kode aplikasi yang bisa dilewati perubahan di kemudian hari. Koreksi adalah entri pembalik bertanggal di periode terbuka. Tidak ada unpost. Setiap laporan adalah proyeksi atas baris jurnal, sehingga laporan tidak mungkin berbeda dari buku besar dan tetap benar.

Cakupan
  • Buku besar — bagan akun, dimensi, kalender fiskal, saldo awal, tutup periode, tutup tahun
  • Piutang dan utang — faktur, tagihan, penerimaan, pembayaran, umur piutang
  • Kas dan bank — rekonsiliasi terhadap rekening koran
  • Persediaan — perhitungan harga pokok yang diposting lewat mesin yang sama dengan yang lain
  • PPN — Faktur Pajak dan penomoran NSFP
  • Pemotongan — dua arah, dengan register yang direkonsiliasi kembali ke buku besar
  • Laporan — Neraca, Laba Rugi, Arus Kas, Buku Besar
Standar
SAK EP SAK EMKM PPN Faktur Pajak NSFP

SAK EP adalah kernelnya; SAK EMKM adalah profil penyajian di atas buku besar yang sama, sehingga perusahaan yang tumbuh melampaui satu tidak perlu bermigrasi ke yang lain.

Untuk kantor akuntan
  • Akses diberikan per pengguna, per klien — satu login, banyak set pembukuan
  • Penugasan diterima oleh klien, tidak pernah diklaim sendiri oleh kantor
  • Row-level security di basis data sebagai batas kedua yang independen
  • Role basis data aplikasi tidak diizinkan melewatinya
325 pengujian otomatis Uang disimpan sebagai desimal titik-tetap dari ujung ke ujung Log audit hanya-tambah, ditegakkan trigger

Gajii

Penggajian Indonesia
Produksi

Penggajian statutori untuk pemberi kerja Indonesia — PPh 21 dihitung dengan metode TER, BPJS lima program dengan batas upah masing-masing, dan validasi aturan Omnibus Law bahwa gaji pokok minimal 75% dari total upah reguler.

Tabel tarif berversi menurut tanggal berlaku. Parameter pajak Indonesia berubah setiap Januari, dan penggajian yang dihitung ulang untuk periode sebelumnya harus memakai aturan yang berlaku saat itu, bukan aturan yang berlaku sekarang. Itu keputusan skema, bukan filter laporan.

Permukaan kepatuhan
  • PPh 21 — status PTKP dipetakan ke bracket TER-nya
  • BPJS — Kesehatan, JHT, JP, JKK, dan JKM, masing-masing dengan porsi pemberi kerja dan pekerja serta batas upahnya sendiri
  • Omnibus Law — aturan gaji pokok 75% diperiksa sebelum proses berjalan, bukan ditemukan setelahnya
  • Desember — rekonsiliasi tahunan ditangani di jalur sendiri, terpisah dari jalur bulanan
Aturan perancangan
  • Setiap nilai uang adalah desimal titik-tetap — rupiah tidak pernah dibulatkan lewat float
  • Perhitungan kepatuhan adalah fungsi murni tanpa efek samping, sehingga bisa diuji langsung terhadap contoh yang diterbitkan
  • Konfigurasi statutori yang hilang memunculkan error; tidak pernah mundur ke nilai yang sekadar masuk akal
Di sekitar mesinnya

Akun pengguna internal, data perusahaan, dan pendaftaran dasar karyawan — data induk yang dibutuhkan satu proses penggajian, tidak lebih. Ini sengaja bukan HRIS: tidak ada rekrutmen, penilaian kinerja, atau pengelolaan cuti.

Dibangun dengan
Rust React Router PostgreSQL
Dirancang berdampingan dengan Akunta — pembukuan terpisah, tenant terpisah, satu titik integrasi
Vertikal tiga — Operasional Bisnis

Sistem yang mengelilingi inti teregulasi.

Perangkat lunak penjualan dan dukungan yang dibangun dengan standar yang sama. Keduanya multi-tenant, dan pada keduanya batas tenant ditegakkan oleh basis data alih-alih dipercayakan kepada setiap kueri yang akan pernah ditulis siapa pun.

Pakarti CRM

CRM Penjualan B2B
Produksi

CRM penjualan multi-tenant yang mencakup pekerjaan harian tim B2B: kontak, perusahaan, deal di beberapa pipeline, prospek dengan konversi, dan aktivitas yang dicatat pada record mana pun. Field khusus, akses berbasis peran, log audit, dan pencarian ke seluruh data.

Yang pertama kami tunjuk bukan sebuah fitur. Backup berjalan dari kontainer yang terpisah dari aplikasi, karena backup harus tetap bekerja justru pada hari-hari saat aplikasinya tidak — crash loop, migrasi gagal, rilis buruk. Backup lama hanya dipangkas setelah yang baru terverifikasi. Salinan luar-lokasi menyalin dan tidak pernah mencerminkan, sehingga penghapusan lokal — tidak sengaja maupun berniat jahat — tidak bisa mengikutinya ke sana. Prosedur pemulihannya tertulis dan dimaksudkan untuk dilatih.

Cakupan
  • Record — kontak, perusahaan, deal, prospek, dan aktivitas (tugas, telepon, rapat, catatan)
  • Pipeline — beberapa pipeline pada papan kanban, konversi prospek menjadi kontak, perusahaan, dan deal sekaligus
  • Konfigurasi — field khusus per jenis record
  • Akses — izin berbasis peran dengan log audit di belakangnya
  • Data — impor dan ekspor, pengurutan dan paginasi di seluruh modul
  • Surel — surat transaksional dan notifikasi dengan preferensi per pengguna
  • Lampiran — penyimpanan berkompatibilitas S3 (Cloudflare R2, Backblaze B2, MinIO, AWS) atau volume berkas lokal, sesuai kebutuhan penerapan
Penerapan
  • Satu perintah menyalakan seluruh stack; migrasi dan seed berjalan sebelum API hidup
  • Setiap service menunggu health check sungguhan, bukan timer
  • Login dan refresh token dibatasi lebih ketat daripada sisa API, karena di situlah credential stuffing mendarat
Dibangun dengan
Rust React Router PostgreSQL Redis Docker Compose
Backup malam terverifikasi, salinan luar-lokasi, latihan pemulihan terdokumentasi Rate limiting konsisten lintas restart dan instance

Pakarti Support Desk

Tiket Multi-Tenant & SLA
Produksi

Tiket layanan dengan setiap pelanggan masuk ke ruang kerjanya sendiri di hostname sendiri. Isolasi berjalan di dua lapis independen: pembatasan di tingkat aplikasi yang mengembalikan kosong bila tenant tidak diset, dan row-level security PostgreSQL di bawahnya yang ditegakkan oleh role basis data yang tidak diizinkan melewatinya. Keduanya gagal-tertutup. Tidak satu pun dipercaya sendirian.

Setiap perubahan status tiket melewati satu pintu service, sehingga aturan yang ditambahkan di sana berlaku untuk semua pemanggil — tampilan web, job latar, surel masuk — bukan hanya untuk layar yang terakhir kali diperbarui.

Cakupan
  • Siklus hidup — baru, terbuka, tertunda, selesai, dan tertutup, bisa dibuka kembali, dengan event audit di setiap transisi
  • Organisasi — tim, kategori, balasan siap pakai, tiket terkait, lampiran
  • SLA — kalender jam kerja mingguan dengan hari libur, kebijakan per prioritas, dan event pelanggaran yang tercatat sekali dan hanya sekali
  • Penomoran — urutan per tenant dengan format yang dapat diatur, token tanggal, dan reset berkala
  • Papan — papan tiket yang menyegar sendiri dengan pencarian, penyaringan, dan prioritas diurutkan menurut keparahan, bukan abjad
  • Intake — surel masuk Office 365, dapat diuji tanpa kredensial hidup
Dibangun dengan
Django PostgreSQL RLS htmx Alpine.js Django-Q2

Tanpa Redis, dan tanpa build frontend terpisah. Job latar memakai PostgreSQL sebagai broker, sehingga satu penerapan berarti sebuah basis data dan sebuah aplikasi — tidak ada lagi yang perlu dioperasikan, dipantau, atau hilang.

Isolasi, diuji jujur

Row-level security diverifikasi lewat koneksi basis data kedua yang sungguhan memakai role terbatas — bukan lewat koneksi istimewa milik test runner, yang akan membuat setiap policy lulus diam-diam.

184 pengujian otomatis CI menjalankan definisi kontainer yang sama dengan yang dijalankan pengembang
Cara kami membangun

Enam aturan yang muncul di setiap basis kode milik kami.

Ini bukan cita-cita di slide. Masing-masing ditegakkan di tempat yang tidak bisa dibatalkan diam-diam oleh sebuah pull request — constraint basis data, trigger, pemberian role, atau pengujian yang gagal dengan keras.

Isolasi adalah urusan basis data

Multi-tenancy yang hanya ditegakkan di kode aplikasi berjarak satu filter terlupa dari kebocoran. Kami menaruh row-level security di bawahnya, dan menjalankan aplikasi sebagai role yang tidak bisa melewatinya — sehingga kueri yang lupa filternya mengembalikan kosong, bukan segalanya.

Akunta · Support Desk · Pakarti Klinik · Pakarti Utama

Catatan hanya bisa ditambah

Bila sebuah catatan punya bobot hukum, ia tidak pernah diperbarui dan tidak pernah dihapus. Entri buku besar yang sudah diposting dikoreksi dengan entri pembalik. Log audit dilindungi trigger, bukan kebiasaan. Jalur break-glass ada, tidak tersedia bagi aplikasi, dan penggunaannya adalah insiden dengan catatan tertulis.

Akunta · Support Desk

At-least-once, tidak pernah at-most-once

Pesan yang penting ditulis ke outbox di dalam transaksi yang sama dengan perubahan state yang menghasilkannya, lalu dikirim terpisah. Penerima melakukan deduplikasi berdasarkan kunci yang disertakan dan aman diputar ulang. Tidak ada hal penting yang bergantung pada keberhasilan panggilan jaringan tepat pada saat panggilan itu dibuat.

Pakarti Utama · ASTM Gateway

Nilai statutori tidak pernah diingat

Tidak ada tarif pajak, ambang, batas, atau tenggat yang ditulis dari ingatan, disimpulkan dari komentar, atau diinterpolasi dari tahun di sebelahnya. Tabel referensi membawa tanggal berlaku, sehingga menghitung ulang tahun lalu memakai aturan tahun lalu. Konfigurasi yang hilang memunculkan error alih-alih mengganti dengan sesuatu yang tampak benar.

Akunta · Gajii

Backup dilatih, dan disimpan di luar jangkauan

Backup yang hanya hidup di server basis data bukanlah backup — ia mati bersama mesinnya. Milik kami berjalan dari proses terpisah, memangkas hanya setelah yang baru terverifikasi, dan pergi ke luar lokasi lewat job yang menyalin dan tidak pernah mencerminkan, sehingga penghapusan lokal tidak bisa mengikutinya. Prosedur pemulihannya tertulis dan dimaksudkan untuk dilatih sebelum dibutuhkan.

Pakarti CRM · Pakarti Klinik

Luring adalah syarat, bukan penurunan mutu

Instrumen dan perangkat lapangan tetap bekerja ketika jaringan tidak. Data ditangkap lokal lebih dulu, diantrekan berurutan, dan diteruskan saat tersambung kembali — dengan batas jumlah percobaan, sehingga satu pesan rusak tidak pernah menyumbat semua yang mengantre di belakangnya.

ASTM Gateway
Pekerjaan khusus

Kami juga membangun yang tidak ada di halaman ini.

Tidak setiap kebutuhan muat ke dalam produk, dan dalam pekerjaan teregulasi kebutuhan yang tidak muat biasanya justru yang paling menentukan — kewajiban pelaporan khas izin Anda, instrumen yang tidak diintegrasikan siapa pun, proses yang sudah dikenal inspektur Anda dengan namanya. Pekerjaan itu kami terima, dengan syarat yang sama seperti produk kami sendiri.

Bentuk satu

Lisensi dan implementasi

Ambil salah satu platform di atas dan jalankan — konfigurasi, migrasi katalog dan data induk, kredensial integrasi, pelatihan, dan cutover-nya sendiri.

  • Hosting terkelola, atau di lokasi pada pusat data Anda sendiri
  • Data diimpor dari apa pun yang Anda tinggalkan, termasuk kertas
  • Runbook diserahkan, bukan sekadar kredensial
Bentuk dua

Perluas sebuah platform

Bangun kebutuhan Anda sebagai modul di atas sistem yang sudah ada. Anda mendapat buku besarnya, model tenancy-nya, jejak auditnya, dan integrasinya yang sudah dibangun dan sudah diuji — dan hanya membayar bagian yang memang milik Anda.

  • Modul, laporan, dan ekspor regulatori baru
  • Integrasi dengan sistem yang sudah Anda jalankan
  • Konektivitas instrumen dan perangkat
Bentuk tiga

Bangun dari nol

Sistem milik Anda sendiri, di domain Anda, dibangun dengan standar di halaman ini: isolasi di basis data, catatan yang tidak bisa ditulis ulang diam-diam, dan nilai statutori yang dikonfigurasi alih-alih diingat.

  • Penggalian kebutuhan yang dimulai dari apa yang harus bisa dibuktikan
  • Kode sumber dan dokumentasi menjadi milik Anda
  • Serah terima ke tim Anda, atau dukungan berkelanjutan — Anda yang menentukan

Satu hal yang akan kami sampaikan lebih awal alih-alih terlambat: bila menurut kami sebuah kebutuhan lebih baik dilayani oleh sesuatu yang bukan buatan kami, kami akan mengatakannya. Dalam pekerjaan seperti ini kesalahan yang mahal bukanlah memilih vendor yang keliru — melainkan memilih vendor yang menyetujui segalanya.

Kemitraan

Sebagian pekerjaan ini lebih baik dikerjakan bersama.

Produk kami menyentuh titik-titik yang sudah dilayani orang lain — alat di meja laboratorium, klinik yang mengirim sampel, kota yang tidak bisa kami datangi setiap minggu. Bila Anda sudah berada di titik itu, kita bisa saling melengkapi.

Distributor alat & reagen

Konektivitas dalam paket penempatan

Setiap alat yang Anda tempatkan tetap harus tersambung ke sistem dan melapor ke SATUSEHAT. ASTM Gateway dan SatyaLab bisa menjadi bagian dari paket penempatan Anda, sehingga laboratorium menerima alat yang sudah bekerja, bukan alat yang menunggu integrasi.

  • Profil alat baru dibangun sekali, dipakai di setiap lokasi
  • Harga per lokasi atau per bulan, dibundel ke kontrak Anda
Jaringan klinik & lab rujukan

Order dan hasil yang mengalir sendiri

Klinik yang memakai Pakarti Klinik bisa mengirim order ke laboratorium rujukan yang memakai SatyaLab, dan hasilnya kembali ke rekam medis pasien — tanpa ketik ulang, tanpa kertas yang hilang di jalan.

  • Untuk lab yang melayani banyak klinik, dan klinik yang merujuk ke satu lab
  • Kedua sisi tetap memegang datanya masing-masing
Mitra implementasi regional

Penjualan dan dukungan di kota Anda

Perusahaan TI lokal yang menjual, memasang, dan menjadi dukungan lini pertama di wilayahnya, dengan bagi hasil. Kami menyediakan dokumentasi, pelatihan, dan dukungan lini kedua.

  • Berlaku untuk seluruh portofolio, bukan hanya kesehatan
  • Pelanggan tetap tercatat atas nama mereka sendiri
Label putih

Platform kami, merek Anda

Jaringan laboratorium, grup rumah sakit, atau penyedia layanan yang ingin menjalankan salah satu platform kami di bawah namanya sendiri, dengan penyesuaian yang memang dibutuhkan.

  • Merek, domain, dan alur kerja milik Anda
  • Pembaruan dan kepatuhan regulasi tetap kami jaga

Kami biasanya memulai dengan pilot di beberapa lokasi dan tanpa eksklusivitas, supaya kedua pihak bisa melihat kerja samanya berjalan sebelum ada komitmen yang lebih besar.

Ajak kami bermitra Mulai lewat WhatsApp
Standar & integrasi

Permukaan regulasi yang sudah kami kuasai.

Setiap butir di bawah ini sudah berjalan di dalam kode yang kami kirimkan, bukan dijanjikan di peta jalan. Bila sebuah integrasi baru terverifikasi terhadap endpoint uji dan belum terhadap sandbox regulator yang sesungguhnya, kami menyampaikannya saat evaluasi — bukan setelah tanda tangan.

Kesehatan — sistem nasional
SATUSEHAT BPJS PCare BPJS VClaim INA-CBG E-Klaim SEP Prolanis Indikator Nasional Mutu
Kesehatan — standar klinis
FHIR R4 ICD-10 IM ICD-9-CM IM LOINC UCUM ISO 15189 CLSI AUTO15
Instrumen
ASTM E1381 ASTM E1394 Jembatan serial dan TCP
Keuangan & pajak
SAK EP SAK EMKM PPN Faktur Pajak / NSFP PPh 21 TER PTKP Pemotongan
Ketenagakerjaan
BPJS Kesehatan BPJS JHT BPJS JP BPJS JKK BPJS JKM Omnibus Law 75%
Platform
PostgreSQL row-level security Penyimpanan kompatibel S3 Docker Compose Mandiri atau terkelola
Pengadaan

Ajukan RFP Anda.

Sebagian klien kami, membeli lewat proses pengadaan formal, bukan ujicoba mandiri — dan itu wajar untuk perangkat lunak yang menyentuh data pasien, pajak, atau catatan yang diaudit. Kirimkan RFP atau kerangka acuan Anda; kami akan membalas langsung dengan kecocokan yang sebenarnya, termasuk bila jawabannya sebagian tidak cocok, bukan proposal generik yang menyetujui semuanya.

Sertakan dalam RFP Anda
  • Ruang lingkup — organisasi Anda, skala (jumlah cabang, pengguna, transaksi per bulan), dan modul yang dibutuhkan
  • Kepatuhan — regulator dan standar yang mengikat Anda (SATUSEHAT, BPJS, DJP, atau lainnya), dan bukti apa yang harus bisa ditunjukkan saat diaudit
  • Sistem berjalan — apa yang dipakai hari ini, dan apa yang harus terintegrasi atau dimigrasikan
  • Linimasa & format — tenggat pengadaan Anda, dan dokumen apa yang dibutuhkan dari kami (proposal teknis, kuesioner keamanan, referensi harga)
Kirim RFP lewat surel Mulai lewat WhatsApp
Hubungi kami

Ceritakan regulator mana yang Anda pertanggungjawabkan.

Entah itu Kemenkes, BPJS, BPOM, atau DJP, percakapan pertamanya sama: apa yang harus bisa dibuktikan, siapa yang harus menandatanganinya, dan apa yang terjadi hari ini ketika jaringan putus. Bawakan itu kepada kami, dan kami akan mengatakan dengan jujur mana dari sistem ini yang cocok, mana yang masih perlu dikerjakan, dan mana yang sama sekali tidak berlaku untuk Anda.

Mulai percakapan Tinjau portofolio
Surel halo@pakarti.id
WhatsApp +62 823-1001-0749
Web pakarti.id
Alamat kantor Aiwork Office Space, Jl. TB. Simatupang Kav. IS No.01, Kel. Ragunan, Kec. Pasar Minggu, Jakarta Selatan, DKI Jakarta 12310
Penerapan Hosting terkelola, atau di lokasi pada pusat data atau akun cloud Anda
Bentuk kerja sama Lisensi produk, implementasi, atau pengembangan khusus di atas platform di atas