BOOTINGJRV//SYSTEMS/
A Malaysian clinic runs on a queue that half the patients never booked into, a billing split between cash and a dozen panel rate cards, and a dispensary that empties faster than any stock sheet records. Most clinic software models one of those three well and forces the other two back onto paper.
A clinic management system is the software that holds one clinic day end to end: the queue a patient joins, what was done in the room, what was dispensed, what the panel owes and what the patient actually paid, in a single record instead of four books that have to be reconciled at closing.
The appointment book is the first thing to go. Software built around booked slots assumes the schedule is the truth, and in a general practice here it is not: a meaningful share of the morning walks in without an appointment, and by half past nine the on-screen schedule and the people in the waiting room have nothing to do with each other. Reception stops looking at the system and starts working off a printed list, which means the system now has no idea who is in the building.
The second break is billing, and it is the expensive one. A cash patient pays at the counter and the transaction closes the same minute. A panel patient does not: the visit is billed to an employer scheme or a third-party administrator at that panel's own rate card, submitted separately, and paid weeks later, sometimes partially, sometimes with lines knocked off. Until someone tallies the submitted claims against the payments received, the clinic does not know what it is owed. The asymmetry is structural rather than a matter of diligence: the cash figure closes itself at the counter every evening, and the panel figure only closes when somebody sits down and does the tallying by hand.
The third is dispensing. A clinic here dispenses, which means stock leaves the shelf at the moment a drug is handed over, not at the moment a bill is raised. If the system deducts stock from the bill, every free sample, every dose given in the room and every short-supply substitution drifts the count. The drift is invisible until a stock take, and by then nobody can reconstruct where it came from.
Then there is the paperwork nobody counts as work. Medical certificates, referral letters, medical reports for insurers, repeat prescriptions. Each is a document a patient or an employer will come back for, sometimes months later, and in most clinics the only copy is the carbon under the pad. Reprinting one means writing it again from the notes.
Clinic software mostly fails at the modelling stage rather than the build. It describes a hospital outpatient appointment and then cannot describe an ordinary Tuesday morning in Seremban. These are the objects we start from.
One morning at the counter, from the first patient to the closing tally. We are watching for what gets written twice, where reception abandons the screen, and which of the four books is the one people actually trust. That book usually becomes the data model.
Registration, triage, room, dispensary, counter, with walk-ins and booked patients in the same line. This is the screen a receptionist lives in for eight hours, so it is built for speed and keyboard entry first. If this screen is slower than the printed list, nothing else in the project matters.
Every panel loaded with its own prices, claimable items and limits, so the bill is correct at the counter instead of corrected at submission. Claims are then a queue with states — submitted, paid, short-paid, rejected — which is what turns the receivable into a number on a screen.
Stock deducts at dispensing, with batch and expiry on the line. Reorder levels, a goods-received screen, and a stock take that reconciles against movements rather than replacing them, so a discrepancy leaves a trail instead of being written over.
MCs, referral letters and reports generated from the encounter, numbered, and reprintable months later exactly as issued. Doctor signature and clinic letterhead configured once in settings.
Who sees clinical notes, who sees prices, who can void a receipt, who can see other branches. Enforced with row-level rules in Postgres rather than hidden buttons, and every change written with who and when.
The database is a Supabase project under the clinic's own account, in a region you pick, with the repository and the deployment alongside it. A clinic that cannot move its own patient records without the vendor's cooperation does not really hold them.
This is the part that catches practices out. A clinic's cash patients are individuals who generally do not require an individual e-invoice, so those visits can be reported through LHDN's consolidated route as a periodic summary. The panel and corporate side is the exact opposite: the buyer is a company with a TIN, it wants a proper e-invoice against the claim, and it will chase you for one. The same clinic therefore has to operate both paths on the same day's takings, split by payer rather than by date.
The failure mode is double-reporting. A cash patient who asks for an individual e-invoice — and some do, because they are claiming it back from an employer — has to be issued one, and that visit then has to be pulled out of the consolidated batch. If the system cannot promote a single transaction out of the consolidation, you either refuse the patient or report the same money twice.
The second failure mode is capture. A panel or corporate buyer's TIN, SST registration and address have to be on the record before the claim is raised, not chased at month end from a list of company names. That is a customer-creation problem, not a submission problem, and it is where almost all of the effort actually goes.
Whether your clinic is in scope depends on annual turnover, and the last band came into force on 1 January 2026 for businesses up to RM5 million, with those under RM1 million exempt. Confirm your own position with your tax agent. We build the system and the submission path; we do not file your returns.
Published tiers, seen from a clinic. Hosted on your own Supabase and Vercel accounts, so there is no per-seat licence and no fee for adding your fourth doctor.
One branch done properly: queue, cash and panel billing, dispensing with stock, MC and referral documents, daily tally, roles and audit trail.
Enterprise tier. Per-branch scoping and reporting, group-level dashboards, panel claim tracking across branches, and MyInvois submission with both the consolidated and individual paths.
Starter tier. Five pages, mobile-first, WhatsApp routing and the Google Business Profile work that decides whether you appear in the map pack for your town.
