Dialysis Unit Software: Chairs, Machines, Sessions and the Bill

A dialysis unit is the one part of a hospital that runs like a factory and is almost always managed like a clinic. The same patients return three times a week for years. Each session occupies a specific chair, a specific machine and a specific slot, consumes a dialyser and a bloodline set, and generates a bill that is frequently paid by a scheme rather than by the patient.

General hospital software handles this badly, and it handles it badly in a consistent way: it models a dialysis session as an OPD visit. That single modelling decision is the origin of most of the complaints. An OPD visit is an episode; a dialysis session is one instance of a standing schedule, and the difference shows up in scheduling, in stock, in billing and in every report the nephrologist wants.

What makes dialysis different from other outpatient care?

Recurrence. A dialysis patient is not a visit, they are a slot — usually a fixed shift on fixed days of the week, held for months or years, against a finite number of chairs.

That has consequences a visit-shaped system cannot express. Capacity is a grid of chairs times shifts times days, not a doctor's appointment book. A cancelled session is a hole in a recurring pattern that somebody should fill today, not a missed appointment. A new patient cannot be admitted to the programme unless a slot exists, which makes waiting-list management a real function rather than a spreadsheet. And utilisation — the number the unit is actually run on — is sessions delivered against chair-shifts available, which a system that does not model chair-shifts simply cannot compute.

What should dialysis software track for each session?

The clinical parameters, the consumables, the machine and the staff, linked to one session record that is also the billable unit.

At minimum, per session:

• Pre and post weight, target ultrafiltration and achieved ultrafiltration
• Blood pressure at intervals through the session, not only at start and end
• Dialyser type, and whether it is a first use or a reuse with the reuse count
• Bloodline set, needles, heparin dose and any medication given during the session
• The machine used, by asset ID, and the vascular access used
• Start time, end time, and any interruption with its reason
• Nurse and technician on the session, and the nephrologist responsible

The dialyser reuse count is the entry that most general systems have nowhere to put, and it is not optional: reuse is protocol-governed, patient-specific and auditable, and a unit that tracks it on a card taped to the machine has no way to report on it. Tie the dialyser to the patient rather than to the stock ledger alone, and the reuse count becomes a data field instead of a discipline.

How should a dialysis unit be scheduled?

As a recurring assignment of a patient to a chair-shift, with exception handling, rather than as a stream of individual appointments.

The scheduling model that works is a weekly template: this patient occupies chair 4, second shift, Monday–Wednesday–Friday, from this date. Everything else is an exception against that template. A session is cancelled, so the slot is offered. A patient is admitted as an inpatient, so their sessions move to the ward. A holiday shifts the whole grid. A machine goes down for service, so its chairs are unavailable and the patients on them need relocating — which is a biomedical maintenance event and a scheduling event at the same time, and in most hospitals those two facts live in different systems and different heads.

Isolation adds a hard constraint that scheduling must respect rather than leave to memory. Hepatitis B positive patients require dedicated machines and, in most units, a dedicated area. That is a rule the system should enforce when assigning a chair, not a convention the senior nurse holds. A scheduler that will happily assign a seropositive patient to a general machine is a scheduler that will do it on a busy Monday when the person who knows is on leave.

How does dialysis billing differ?

It is high-frequency, low-value, and mostly paid by somebody other than the patient — which inverts the usual billing design.

A hospital's billing is built for episodes: admit, accumulate charges, discharge, bill. Dialysis generates a small bill three times a week, forever, often split across a scheme, a corporate panel and a cash component for consumables outside the package. The work is not in producing any one bill; it is in producing four hundred of them a month without a human touching each one, and in reconciling them against a scheme's payment file afterwards.

What that requires: session completion should generate the charge automatically, with the consumables consumed on that session priced from the actual dialyser and bloodline used rather than from a standard assumption. Package rules need to know what the scheme covers per session and what falls outside. Erythropoietin and iron, often given in the unit, need to attach to the session or to a separate order without a second registration. And the receivables view a unit manager needs is per-scheme and per-month, not per-patient — the claim settlement article covers where those days go.

What reports does a nephrologist actually ask for?

Adequacy, access, and the trends that change treatment — none of which come out of a system that stores sessions as visits.

Kt/V or URR by patient over time, with the sessions that fell below target flagged rather than buried. Interdialytic weight gain trends, which is the number that tells you whether a dietary conversation worked. Vascular access history per patient — fistula, graft or catheter, with dates — because access failure is the dominant cause of hospitalisation in this population. Hospitalisation and mortality by cohort. Machine-level incident history, which is a quality question and a biomedical equipment question at once.

Every one of those is a time series across recurring sessions. A system that records each session as an unrelated visit can produce them only by export and spreadsheet, which is why so many units run on a parallel register the software knows nothing about.

Where Kōami fits

Kōami is a hospital platform rather than a dedicated nephrology product, and the honest framing is that a large standalone dialysis chain should evaluate specialist software alongside us. What Kōami brings is the connection: the session is one record that carries the clinical parameters, consumes stock from the same inventory the pharmacy uses, generates the charge on the same billing engine as the rest of the hospital, and sits on the same patient identity as the nephrology OPD and any admission.

For a hospital running a dialysis unit inside a larger facility, that connection is usually the problem worth solving — the unit's isolation from the hospital's record is what generates the duplicate entry, the untracked consumables and the reconciliation. Bring one week of your session register and one scheme's payment file to a demo, and ask to see the chair-shift grid, the reuse count and the automatic charge from a completed session.