Pakarti pakarti.id
Pakarti · Jakarta, Indonesia

We build software for work that gets audited.

Hospital, laboratory, accounting and operations systems for Indonesian regulated industries. Eight products in production and active development — built so the record still holds up when a regulator, an auditor, or a lawyer asks to see it.

See the portfolio How we build
8
products across three verticals
20
independent services in our largest hospital platform
132
clinical data models in the clinic system alone
1,000+
automated tests, run on every push
What we do

Regulated work has a different failure mode.

Ordinary business software fails visibly — a page errors, someone files a ticket. Regulated software fails quietly, and looking correct: a trial balance that balances but is wrong, a lab result released by someone without the authority to release it, one tenant's data appearing inside another tenant's report.

Those failures are found by an inspector, an auditor, or a court — long after the deploy that caused them. So we design for that moment first: append-only records, isolation enforced by the database rather than by developer discipline, statutory values that are configured and versioned rather than remembered, and delivery guarantees that survive the network going away.

And we work in Indonesian regulatory reality — Kemenkes/SATUSEHAT, BPJS, BPOM, ISO 15189, SAK EP, PPh 21 — rather than an international product bent to fit it. The terms inside our systems are the ones our users already say out loud.

Portfolio

Eight systems, three verticals.

Status is stated plainly. Production means deployed and in real use. Beta means feature-complete for its first scope and being proven in the field. In development means the foundation is built and the surface is still growing.

Product Vertical What it does
Pakarti Klinik Healthcare Information system for Klinik Pratama, from registration through pharmacy and billing
Pakarti Utama Healthcare SIMRS for Madya-class hospitals — 20 services, AI coding assistance, casemix and remuneration
ASTM Gateway Healthcare On-premise analyzer connectivity — ASTM E1381/E1394 with store-and-forward
SatyaLab Healthcare Laboratory console on top of ASTM Gateway — autoverification, microbiology, QC, FHIR results to SATUSEHAT
Akunta Finance Double-entry books and Indonesian tax for SMEs and their accounting firms
Gajii Finance Payroll: PPh 21 TER, BPJS across all five programmes, the Omnibus 75% rule, eight worker types
Pakarti CRM Operations Multi-tenant B2B sales CRM — pipelines, leads, activities, custom fields
Pakarti Support Desk Operations Multi-tenant ticketing with business-hours SLA tracking and database-level isolation
Vertical one — Healthcare

From clinics down to the instrument on the bench.

Four products that interlock: two clinical platforms sized to different facilities, the gateway that talks to laboratory analyzers directly, and the laboratory console that sits on top of it. All of them report to SATUSEHAT and speak FHIR R4 at the boundary.

Pakarti Klinik

Clinic Information System
Production

A complete clinical and administrative system built for Klinik Pratama — one clinic, or a small chain. Outpatient care, pharmacy and billing are the mature core and in use. For facilities with a different scale and billing needs, there's Pakarti Utama, built for that scale from the ground up.

It ships as multi-tenant software with its own control plane: tenant provisioning, entitlement gating at both plan and branch level, admin accounts protected by two-factor authentication, time-boxed support impersonation, tenant data export, and audit-log retention that archives rather than deletes.

Clinical and operational modules
  • Front office — patient registry with duplicate detection, queue management, and a live display board for each service unit
  • Encounter — visit lifecycle, LOINC-coded vital signs, SOAP notes on configurable forms, ICD-10 diagnoses, prescriptions
  • Pharmacy — inventory, goods receipts, inter-branch transfers, stock opname
  • Revenue — invoicing, payments, insurance claims
  • Programmes — Indikator Nasional Mutu reporting, Prolanis, PCare risk screening
  • Onboarding — catalogue importers for drugs, services, practitioners and patients
Integrations
SATUSEHAT FHIR R4 BPJS PCare BPJS VClaim ICD-10 IM LOINC
Operations
  • Nightly database backup, copied offsite every fifteen minutes
  • Error reports rebuilt from an allowlist, so patient data never leaves the host
  • Deployment and on-call runbooks maintained alongside the code
Built with
Rust React Router PostgreSQL 18 Python
132 data models Unit, API and browser suites across every app Continuous integration on every push

Pakarti Utama

SIMRS — Hospital Management Platform, Madya-Class Hospitals
Beta

Our largest platform: twenty independently deployable services behind one Indonesian-language web application, communicating through a durable event exchange rather than direct calls. A patient's journey — registration, queue, examination, prescription, dispensing, invoice — is an event choreography, and a real-time board shows where every patient currently is.

It is deliberately polyglot, and the language follows the workload. Sixteen services are Rust, and coding assistance and length-of-stay prediction run on Python, because that is where the model tooling lives. Cross-cutting code the Rust services share — auth, org scoping, the outbox dispatcher — lives in one crate rather than being copied per service.

Modules
  • Clinical — Pasien (MPI), Pendaftaran & Antrian, Rawat Jalan, Rawat Inap, IGD, Kamar Operasi
  • Diagnostics — Laboratorium and Radiologi, each on the same catalogue → order → result pattern
  • Records — Rekam Medis & Koding, with AI-assisted ICD-10 suggestion
  • Supply — Farmasi & Inventori: batch tracking, stock opname, transfers, disposal, reorder points
  • Revenue — Billing, Casemix & Klaim INA-CBG, Laporan
  • People — Kepegawaian with practitioner licence tracking, and Remunerasi (jasa medis) with accruals, pools and approval chains
  • Platform — Monitoring & Audit, Integrasi, AI & ML, Pengaturan
Distinctive
  • Coding assistance — full-text ICD retrieval combined with a language model, to shorten the coder's search rather than replace their judgement
  • Length-of-stay prediction — feature extraction, logged predictions, retrainable models
  • Live journey board — every patient's current stage, driven by the event stream
  • Bilingual documentation — 42 pages in Indonesian and English, kept in step by the build
Built with
Rust React Router Python / FastAPI RabbitMQ PostgreSQL
20 services — 12 Rust, 6 TypeScript, 2 Python 19 product modules Per-module end-to-end suites Transactional outbox on every state change

ASTM Gateway

Analyzer Connectivity — on-premise
Beta

The piece that sits on the bench. A bidirectional ASTM E1381/E1394 gateway between laboratory analyzers and the system upstream, connecting over TCP — directly, or through a serial-to-Ethernet converter — with automatic reconnection and backoff.

Every byte is persisted locally before anything else happens: raw frames, then parsed messages, then an outbox. If the link upstream is down, results keep being captured and are forwarded when it returns. A laboratory does not stop running because a switch failed.

Capabilities
  • Device profiles — urine, coagulation and clinical chemistry analyzers today; a new instrument is a profile, not a rewrite
  • Host query — the analyzer asks what to run on a sample and gets an answer synchronously
  • Result normalization — vendor test codes mapped to internal test identifiers, semi-quantitative readings converted to numeric
  • Store and forward — retry with backoff and a bounded attempt count, so one bad message can never block the queue
  • Operations endpoints — health, per-device connection status, outbox statistics
  • Bench simulator — plays the analyzer side, so an integration is proven before anyone touches a live instrument
Protocols
ASTM E1381 ASTM E1394 TCP / serial
Built with
NestJS SQLite Drizzle Docker

Embedded database, single container. It runs on whatever small machine is already in the laboratory.

Protocol layer is pure and free of I/O — framing, session state machine and parser are tested in isolation

SatyaLab

Laboratory Information System — by Pakarti
Beta

A laboratory console that sits on top of ASTM Gateway: receives normalized instrument results, runs autoverification, and manages the order cycle through to result release. The core loop is proven end to end — receive result, autoverify, review/release, FHIR, push to SATUSEHAT — and other domains (microbiology, QC, billing) are built on top of it.

Autoverification follows a CLSI AUTO15 subset: instrument flags, reportable ranges, critical values, and delta checks against the patient's prior result all hold a result for analyst review instead of releasing it automatically — and microbiology is always human-reviewed, never auto-released.

Modules
  • Order & worklist — sample accessioning, specimen tracking, per-instrument worksheets
  • Microbiology — specimen reports, susceptibility testing (AST), and cumulative antibiograms (CLSI M39)
  • QC — Westgard multirule evaluation and Levey-Jennings charts per control series
  • Instruments — idempotent result ingest from a fleet of gateways, per-device host-query orders
  • Referrals & billing — intake from referring clinics, pricing and invoicing
  • Compliance — results released as FHIR R4, pushed to SATUSEHAT, audit trail and role-based access
Integrations
SATUSEHAT FHIR R4 ASTM Gateway
Built with
React Router PostgreSQL Drizzle pg-boss
Ingest is duplicate-safe via a per-gateway idempotency key; the SATUSEHAT push job runs on a separate worker with retry and backoff
Vertical two — Finance & Tax

Numbers that become a filing.

Books and payroll for Indonesian companies. Both produce figures that end up on a statutory return, and that sets the standard: statutory values are configured and versioned rather than remembered, money never passes through a floating-point number, and the ledger cannot be edited after the fact.

Akunta

Double-Entry Accounting & Tax
Production

Double-entry books for Indonesian SMEs, with a console for the accounting firms that keep those books. The failure this product exists to prevent is written into its own source: a trial balance that balances but is wrong.

The ledger is append-only and the database enforces it. Triggers refuse any update or delete on a posted entry, and an unbalanced entry is rejected by a deferred constraint at commit — not merely by application code that a future change could route around. A correction is a reversing entry dated in an open period. There is no unpost. Every report is a projection over journal lines, so a report cannot disagree with the ledger and still be right.

Coverage
  • General ledger — chart of accounts, dimensions, fiscal calendar, opening balances, period close, year-end close
  • Receivables and payables — invoices, bills, receipts, payments, ageing
  • Cash and bank — reconciliation against statements
  • Inventory — costing that posts through the same engine as everything else
  • Value-added tax — PPN, Faktur Pajak, and NSFP numbering
  • Withholding — both directions, with a register reconciled back to the ledger
  • Statements — Neraca, Laba Rugi, Arus Kas, Buku Besar
Standards
SAK EP SAK EMKM PPN Faktur Pajak NSFP

SAK EP is the kernel; SAK EMKM is a presentation profile over the same ledger, so a company that outgrows one does not migrate to the other.

For accounting firms
  • Access granted per user, per client — one login, many sets of books
  • An engagement is accepted by the client, never claimed by the firm
  • Row-level security in the database as a second, independent boundary
  • The application's database role is not permitted to bypass it
325 automated tests Money held as fixed-point decimal end to end Append-only audit log, enforced by trigger

Gajii

Indonesian Payroll
Production

Statutory payroll for Indonesian employers — PPh 21 calculated by the TER method, BPJS across all five programmes with their respective wage ceilings, and validation of the Omnibus Law rule that basic salary must be at least 75% of total regular pay.

Rate tables are versioned by effective date. Indonesian tax parameters change each January, and a payroll recalculated for a prior period must use the law that applied then, not the law that applies now. That is a schema decision, not a report filter.

Compliance surface
  • PPh 21 — PTKP status categories mapped to their TER brackets
  • BPJS — Kesehatan, JHT, JP, JKK and JKM, each with employer and employee shares and its own ceiling
  • Omnibus Law — the 75% basic-salary rule checked before a run, not discovered after one
  • December — annual reconciliation handled on its own path, separate from the monthly one
Design rules
  • Every monetary value is a fixed-point decimal — rupiah never round through a float
  • Compliance calculations are pure functions with no side effects, so they can be tested directly against published figures
  • Missing statutory configuration raises an error; it never falls back to something plausible
Around the engine

Internal user accounts, company details, and basic employee registration — the master data a payroll run needs, and no more. It is deliberately not an HRIS: no recruitment, no performance reviews, no leave management.

Built with
Rust React Router PostgreSQL
Designed to sit alongside Akunta — separate books, separate tenants, one integration seam
Vertical three — Business Operations

The systems around the regulated core.

Sales and support software built to the same standard. Both are multi-tenant, and in both the tenant boundary is enforced by the database rather than entrusted to every query anyone will ever write.

Pakarti CRM

B2B Sales CRM
Production

A multi-tenant sales CRM covering the daily work of a B2B team: contacts, companies, deals across multiple pipelines, leads with conversion, and activities logged against any record. Custom fields, role-based access, an audit log, and search across everything.

What we would point at first is not a feature. Backups run from a container separate from the application, because backups have to keep working on exactly the days the application does not — a crash loop, a failed migration, a bad deploy. Old backups are pruned only after a new one is verified. The offsite copy copies and never mirrors, so a local deletion, accidental or hostile, cannot follow them there. The restore procedure is written down and meant to be rehearsed.

Capabilities
  • Records — contacts, companies, deals, leads, and activities (task, call, meeting, note)
  • Pipeline — multiple pipelines on a kanban board, lead conversion into contact, company and deal together
  • Configuration — custom fields per record type
  • Access — role-based permissions with an audit log behind them
  • Data — import and export, sorting and pagination throughout
  • Email — transactional and notification mail with per-user preferences
  • Attachments — S3-compatible storage (Cloudflare R2, Backblaze B2, MinIO, AWS) or a local filesystem volume, whichever suits the deployment
Deployment
  • One command brings up the whole stack; migrations run and seed before the API starts
  • Every service waits on a real health check rather than a timer
  • Login and token-refresh are rate-limited harder than the rest of the API, because that is where credential stuffing lands
Built with
Rust React Router PostgreSQL Redis Docker Compose
Nightly verified backup, offsite copy, documented restore drill Rate limiting consistent across restarts and instances

Pakarti Support Desk

Multi-Tenant Ticketing & SLA
Production

Support ticketing where each customer reaches their own workspace on their own hostname. Isolation runs on two independent layers: application-level scoping that returns nothing when no tenant is set, and PostgreSQL row-level security enforced beneath it by a database role that is not permitted to bypass it. Both fail closed. Neither is trusted alone.

Every ticket state change goes through a single service entry point, so a rule added there applies to every caller — the web view, a background job, an inbound email — rather than to whichever screen was updated most recently.

Capabilities
  • Lifecycle — new, open, pending, resolved and closed, reopenable, with an audit event on every transition
  • Organisation — teams, categories, canned responses, related tickets, attachments
  • SLA — weekly business-hours calendars with holidays, per-priority policies, and breach events recorded once and only once
  • Numbering — per-tenant sequences with configurable formats, date tokens and periodic resets
  • Board — live-refreshing ticket board with search, filtering, and priority sorted by severity rather than alphabetically
  • Intake — Office 365 inbound mail, testable without live credentials
Built with
Django PostgreSQL RLS htmx Alpine.js Django-Q2

No Redis, and no separate frontend build. Background jobs use PostgreSQL as the broker, so a deployment is a database and an application — nothing else to operate, monitor, or lose.

Isolation, tested honestly

Row-level security is verified over a second, real database connection using the restricted role — not through the test runner's privileged one, which would make every policy silently pass.

184 automated tests CI runs the same container definition a developer runs locally
How we build

Six rules that appear in every codebase we own.

These are not aspirations on a slide. Each one is enforced somewhere a pull request cannot quietly undo it — a database constraint, a trigger, a role grant, or a test that fails loudly.

Isolation belongs in the database

Multi-tenancy enforced only in application code is one forgotten filter away from a breach. We put row-level security underneath it, and run the application as a role that cannot bypass it — so the query that forgets its filter returns nothing rather than everything.

Akunta · Support Desk · Pakarti Klinik · Pakarti Utama

The record is append-only

Where a record carries legal weight, it is never updated and never deleted. A posted ledger entry is corrected by a reversing entry. Audit logs are protected by triggers, not by convention. A break-glass path exists, is unavailable to the application, and using it is an incident with a written record.

Akunta · Support Desk

At-least-once, never at-most-once

A message that matters is written to an outbox inside the same transaction as the state change that produced it, then delivered separately. Receivers deduplicate on a supplied key and are safe to replay. Nothing important depends on a network call succeeding at the exact moment it is made.

Pakarti Utama · ASTM Gateway

Statutory values are never remembered

No tax rate, threshold, ceiling or deadline is written from memory, inferred from a comment, or interpolated from an adjacent year. Reference tables carry an effective date, so recalculating last year uses last year's law. Missing configuration raises an error rather than substituting something that looks right.

Akunta · Gajii

Backups are rehearsed, and kept out of reach

A backup that lives only on the database host is not a backup — it dies with the machine. Ours run from a separate process, prune only after a new one is verified, and go offsite by a job that copies and never mirrors, so a local deletion cannot follow them. The restore procedure is written down and meant to be practised before it is needed.

Pakarti CRM · Pakarti Klinik

Offline is a requirement, not a degradation

Instruments and field devices keep working when the network does not. Data is captured locally first, queued in order, and forwarded on reconnect — with a bounded retry count, so one bad message can never block everything queued behind it.

ASTM Gateway
Custom work

We also build what is not on this page.

Not every requirement fits a product, and in regulated work the requirements that do not fit are usually the ones that matter most — a reporting obligation specific to your licence, an instrument nobody else integrates, a process your inspector already knows by name. We take that work, and we take it on the same terms as our own.

Engagement one

License and implement

Take one of the platforms above and put it into service — configuration, catalogue and master-data migration, integration credentials, training, and the cutover itself.

  • Managed hosting, or on-premise in your own data centre
  • Data imported from whatever you are leaving, including paper
  • Runbooks handed over, not just credentials
Engagement two

Extend a platform

Build your requirement as a module on an existing system. You get the ledger, the tenancy model, the audit trail and the integrations already built and already tested — and pay only for the part that is yours.

  • New modules, reports, and regulatory exports
  • Integrations with systems you already run
  • Instrument and device connectivity
Engagement three

Build from nothing

A system of your own, in your domain, built to the standard on this page: isolation in the database, records that cannot be quietly rewritten, and statutory values that are configured rather than remembered.

  • Discovery that starts with what has to be provable
  • Source code and documentation are yours
  • Handover to your team, or ongoing support — your call

One thing we will say early rather than late: if we think a requirement is better served by something we did not build, we will tell you. In this line of work the expensive mistake is not choosing the wrong vendor — it is choosing one who agreed with everything.

Partnerships

Some of this work is better done together.

Our products touch points other people already serve — the analyzer on the bench, the clinic sending samples, the city we can't visit every week. If you're already at one of those points, we can complete each other.

Analyzer & reagent distributors

Connectivity inside the placement deal

Every analyzer you place still has to be connected to a system and report to SATUSEHAT. ASTM Gateway and SatyaLab can be part of your placement package, so the laboratory receives an instrument that already works, not one waiting on integration.

  • A new device profile is built once and reused at every site
  • Priced per site or per month, bundled into your contract
Clinic networks & referral labs

Orders and results that move on their own

Clinics on Pakarti Klinik can send orders to a referral laboratory on SatyaLab, and the results come back into the patient's record — no retyping, no paper lost in transit.

  • For labs serving many clinics, and clinics referring to one lab
  • Each side keeps ownership of its own data
Regional implementation partners

Sales and support in your city

Local IT firms that sell, install, and provide first-line support in their region, on a revenue share. We provide documentation, training, and second-line support.

  • Covers the whole portfolio, not just healthcare
  • Customers stay on record in their own name
White label

Our platform, your brand

Laboratory chains, hospital groups, or service providers that want to run one of our platforms under their own name, with the customization they actually need.

  • Your brand, domain, and workflows
  • Updates and regulatory compliance stay with us

We usually start with a pilot at a few sites and no exclusivity, so both sides can see the partnership working before either commits to more.

Propose a partnership Start on WhatsApp
Standards & integrations

The regulatory surface we already speak.

Every item below is implemented in shipping code rather than promised on a roadmap. Where an integration is verified against a mock instead of a live regulator sandbox, we say so during evaluation — not after signing.

Health — national systems
SATUSEHAT BPJS PCare BPJS VClaim INA-CBG E-Klaim SEP Prolanis Indikator Nasional Mutu
Health — clinical standards
FHIR R4 ICD-10 IM ICD-9-CM IM LOINC UCUM ISO 15189 CLSI AUTO15
Instruments
ASTM E1381 ASTM E1394 Serial and TCP bridging
Finance & tax
SAK EP SAK EMKM PPN Faktur Pajak / NSFP PPh 21 TER PTKP Withholding
Employment
BPJS Kesehatan BPJS JHT BPJS JP BPJS JKK BPJS JKM Omnibus Law 75%
Platform
PostgreSQL row-level security S3-compatible storage Docker Compose Self-hosted or managed
Procurement

Submit your RFP.

Some of our buyers procure through a formal process rather than a self-serve trial — which makes sense for software that touches patient data, tax filings, or records that get audited. Send us your RFP or terms of reference; we'll reply directly with an honest fit, including where the answer is only partial, not a generic proposal that agrees to everything.

Include in your RFP
  • Scope — your organization, scale (branches, users, transactions per month), and the modules you need
  • Compliance — the regulators and standards you're bound by (SATUSEHAT, BPJS, DJP, or others), and what you need to be able to prove under audit
  • Current systems — what you run today, and what has to integrate or be migrated
  • Timeline & format — your procurement deadline, and which documents you need from us (technical proposal, security questionnaire, pricing reference)
Send RFP by email Start on WhatsApp
Get in touch

Tell us which regulator you answer to.

Whether it is Kemenkes, BPJS, BPOM or DJP, the first conversation is the same: what has to be provable, who has to sign it, and what happens today when the network drops. Bring us that, and we will tell you honestly which of these systems fits, which needs work first, and which does not apply to you at all.

Start a conversation Review the portfolio
Email halo@pakarti.id
WhatsApp +62 823-1001-0749
Web pakarti.id
Office address Aiwork Office Space, Jl. TB. Simatupang Kav. IS No.01, Kel. Ragunan, Kec. Pasar Minggu, Jakarta Selatan, DKI Jakarta 12310
Deployment Managed hosting, or on-premise in your data centre or cloud account
Engagement Product licensing, implementation, or custom development on top of the platforms above