Dialysis Center Software That Stops Missed Treatments and Empty Chairs
If you run three clinics or fewer on one modality, stay inside your EMR and stop reading. If you run six or more, mix in-center with home and acutes, and someone on your corporate team maintains the master chair board in a spreadsheet, build the operations layer above your EMR. In our delivery experience a focused first release, meaning a live cross-site chair and capacity system with treatment ingestion and a missed treatment workflow, runs $60,000 to $130,000 and ships in 12 to 16 weeks. A full platform covering EQRS and NHSN reporting, water and biomed logs, machine data, home program tracking, and cost per treatment runs $150,000 to $400,000 phased across 6 to 12 months. Do not build an EMR. Build the operations layer your EMR was never designed to be.
Why chair scheduling and treatment tracking makes or breaks a dialysis operator
It is 4:40pm on a Friday. A hospital case manager faxes a discharge summary for a patient who needs a chair Saturday first shift. Your admissions coordinator opens the master chair board, a spreadsheet with a tab per clinic that was copied from last quarter's version and patched by three different people. Clinic 4 shows an open Tuesday/Thursday/Saturday second shift seat, but that seat is the isolation station with its dedicated machine, and the patient is HBsAg negative, so burning it is the wrong call. Clinic 7 says they have room. The charge nurse at Clinic 7 knows they are down a PCT on Saturday and nobody told the spreadsheet. Two phone calls later the patient goes to a competitor eight miles away, and three treatments a week for a year walk out with him.
The stack under that scene: eCube Clinical or MIQS or Acumen holds the clinical record, and none of them were built as capacity systems. EQRS wants monthly attestation and clinical submission. NHSN wants dialysis event denominators and events on a separate schedule with separate logins. Spectra Laboratories drops lab results as flat files. Your Fresenius 2008T machines compute Kt/V through online clearance monitoring, and that number gets read off a screen and written on a paper flowsheet before someone keys it in again. Staffing lives in UKG. Rides live in the ModivCare portal. Water and RO logs live on a clipboard on the wall behind the biomed bench. Nothing joins to anything.
The leak is quiet, which is why it survives. It is the seats nobody can see, the missed treatment discovered on Monday, the clinical manager who spends the last five days of every month reconciling census in Excel instead of running her floor. Across the operations builds we have shipped, recovered capacity is usually what pays for the project inside the first year, before anyone counts the labor hours.
Problem 1: nobody in the network knows the real open-seat count
Ask your regional director how many placeable seats exist tomorrow across fourteen clinics. You will get a number that is wrong in both directions: seats that look open but cannot legally be filled, and seats that look full because a patient transferred out three weeks ago and the tab was never updated. Meanwhile a nephrologist practice you want referrals from calls, gets "let me check and call you back," and stops calling.
Your EMR cannot fix this because it models encounters, not capacity. There is no constraint engine in it. It does not know that HBsAg-positive patients need a separate room with dedicated machines and staff who are not crossing over that shift, that machine 12 has a preventive maintenance due at its next hour meter threshold, that your state ratio caps a PCT at a given number of stations, that Dr. Patel rounds Tuesday and Friday so his panel sits on those days, or that a chair turn between a 3.5 hour prescription and a 4 hour prescription is not the same turn.
A custom build changes the unit of allocation. Instead of appointments, you model station by shift by weekday pattern, and you make constraints data rather than tribal knowledge: isolation status, machine assignment and PM state, ratio rules per state, charge nurse coverage, transport pickup window, physician rounding day. The output is a live open-seat map across every site that a coordinator can trust, plus a what-if tool: move these three patients from MWF first to TTS second and see what opens. The narrow AI job here is after-hours placement. An agent reads the inbound fax or portal request, extracts patient name, modality, prescription length, access type, insurance, and HBV status, then returns the three seats that are actually legal with the reason each one is legal. Your coordinator confirms in thirty seconds on Saturday morning instead of starting a phone tree on Friday night.
Problem 2: treatment data is stranded between the machine, the flowsheet, and the EMR
Your medical director asks a fair question in QAPI: which shift has the highest rate of shortened treatments, and is it the patients or the process? The answer takes two weeks, comes from a CSV someone emailed, and lags six weeks by the time it is on a slide. Nobody argues with it because nobody trusts it enough to argue.
Off-the-shelf reporting in dialysis EMRs is built for CMS submission, not for running an operation. Most independent stacks have no machine integration at all, so pre-weight, post-weight, UF goal, blood flow rate, time on versus time prescribed, and intradialytic hypotension events get double keyed from paper. Spectra and Quest results land in yet another place. There is no join key that makes a treatment a first-class object with everything about it attached.
A custom build gives you a treatment warehouse. Ingest machine data where the manufacturer allows it, take lab results over HL7 ORU, pull EMR extracts nightly, and reconcile them onto one treatment record. Then compute the operational measures that do not exist today: shortened treatment rate by shift and by station, interdialytic weight gain cohorts above your threshold, patients over ninety days on a catheter ranked by access plan status, Kt/V misses with an attached reason code rather than a shrug. Add drift detection that flags when one station's post-weights start diverging from the rest, which is usually a scale, not a patient.
Problem 3: EQRS, NHSN, and the survey binder eat a week every month
Your clinical manager loses the last five business days of every month. She reconciles admissions, transfers, modality changes, hospitalizations, and deaths in a spreadsheet so the EQRS attestation matches reality. CMS-2728 has to be filed on new patients inside its window. CMS-2746 goes out on deaths. The 2744 annual survey depends on counts nobody trusts. NHSN needs monthly denominators plus each event: pus, redness or swelling at the access site, a positive blood culture, an IV antimicrobial start. Water logs sit on clipboards, chlorine and chloramine per shift, AAMI limits, initialed and filed. Then a surveyor walks in and asks for evidence that crosses six systems.
The EMR handles some EQRS submission and none of the reconciliation, because reconciliation requires knowing what CMS believes versus what you know, and the EMR only knows its own side. NHSN is entirely separate. Biomed and water are outside the EMR's world completely.
The fix is to make compliance a byproduct instead of a project. Event-source patient status so admits, transfers, modality changes, hospitalizations, and deaths are immutable facts with timestamps, which means the 2744 counts compute themselves and the monthly attestation becomes a review, not a rebuild. Generate the EQRS batch and show a reconciliation view of the deltas. Auto-count NHSN denominators from treatments, capture events at the point of care on a twenty second tablet form while the tech is still at the chair, and export the CDA. Move water and RO logs onto the tablet with hard stops on out-of-range values and automatic biomed escalation, so an out-of-range chloramine cannot be initialed past. Add a survey mode that assembles evidence by tag. The model does real work on the intake side: extraction from the 2728 packet, faxed discharge summaries, transfer records from other clinics, and insurance cards, structured with a confidence score and a human check queue for anything below threshold. Intake is still fax-driven, so that is where extraction pays for itself first.
Problem 4: you find out about the missed treatment on Monday
A patient on MWF first shift misses Wednesday. The van ran forty minutes late, she declined the ride, and nobody called. Friday she arrives 4.8 kg over her estimated dry weight, the treatment gets shortened because she cannot tolerate the UF rate, Sunday she is in the emergency department in fluid overload, and you own a hospitalization that shows up in your QIP profile and eats into your shared savings if you sit in a value arrangement.
Your EMR recorded the missed treatment. It recorded it after the fact, with no owner and no clock. The ModivCare portal is a separate login that nobody watches at 6:20am. There is no thirty minute window in which anyone is accountable.
Build for the window. Check-in happens at the station, so at twenty minutes past scheduled the seat lights up as at risk and pings the charge nurse's device. A missed treatment workflow forces a reason code that routes to an owner: transport, patient refusal, hospitalization, staffing. Vendor on-time performance accumulates automatically, which is the only leverage you will ever have in a transport contract negotiation. The model scores tomorrow's first shift on prior no-show pattern, IDWG trend, transport vendor on-time history for that route, ride distance, day pattern, and weather, then hands your coordinator six names to call at 3pm. Six names get called. A two hundred row export does not. When a seat does go dark, offer it by SMS to a standby list ranked by proximity and modality fit.
Problem 5: your labor cost per treatment is a guess and the home program is invisible
You cannot answer whether Clinic 9's third shift should exist. UKG gives you hours by cost center. Your billing system gives you treatments. Nobody joins them, so cost per treatment is a quarterly estimate built by a finance analyst who has never stood in a unit. Agency PCT spend and overtime hide inside the average. Meanwhile your PD patients sit in Baxter Sharesource, home HD lives in Nx2me or a nurse's spreadsheet, and the ETC model rewards a home funnel you cannot see the drop-off in.
A custom build computes cost per treatment nightly by joining timeclock punches, treatment counts, supply consumption (dialyzers, bloodlines, concentrate), and machine hours, sliced by site and by shift. It renders the modality funnel end to end: CKD referral, education session attended, modality choice, home training start, home census, with drop-off at each stage and the name of the person who owns the next step. Then it forecasts census twelve weeks out per site, which is how you decide to open a fourth shift or close one before the quarter tells you.
What this costs and what drives the price up in dialysis
Framed only as Digital Heroes delivery experience across 2,000-plus projects: a focused first release lands at $60,000 to $130,000 and ships in 12 to 16 weeks. That is realistically the cross-site chair and capacity system with constraints, EMR ingestion, check-in, and the missed treatment workflow. A full platform, adding EQRS and NHSN generation, water and biomed logs, machine data, home program tracking, and cost per treatment, runs $150,000 to $400,000 phased across 6 to 12 months.
What pushes you toward the top of those bands in this category specifically: an EMR with no API, which means a database replica or nightly extract and a slower feedback loop; machine data, which is a separate integration per manufacturer and sometimes per model; a second or third lab interface; multi-state ratio and licensure rules; joint venture sites where the nephrology group dictates a different EMR than your corporate one; HIPAA infrastructure with a real audit trail, BAAs, and access review; and offline tolerance, because units lose wifi and a tech at a chair cannot wait for a spinner. Underestimating that last one is the most expensive mistake we see in this vertical.
Build versus buy: take the position
Buy, and stop here, if you run one to three clinics on a single modality, your EMR's scheduling is adequate because your coordinator can hold the whole board in her head, and you have no corporate operations team. The build will not pay back. You will be paying to solve a coordination problem you do not have yet.
Build when the signals are these: six or more sites, or fewer sites at high volume with three shifts and a waitlist; someone's real job has quietly become maintaining a spreadsheet; your regional directors cannot answer the open-seat question in under an hour; you are mixing in-center, home, and acute contracts; you are in a value arrangement where hospitalizations and home rates hit your P&L. And build the layer above your EMR, not a replacement for it. Every operator we have watched try to build the EMR has regretted it. The clinical record, the prescription, the MAR, the CMS submission plumbing: leave them. The chair, the treatment as an operational object, the compliance byproduct, the cost per treatment: nobody sells you those, and they decide your margin.
How to choose a developer for dialysis center software
Make them draw the data model before they quote. Ask a candidate to model a treatment on a whiteboard. If they draw an appointment with a patient and a time, walk. The right answer separates prescription, scheduled session, station assignment, machine assignment, and completed treatment, and it has an opinion about where estimated dry weight lives and why a modality change is an event rather than a field update.
Ask what they have integrated, by name. Not "healthcare experience." Have they moved HL7 v2 ADT and ORU? Have they parsed a lab flat file from Spectra? Have they generated an EQRS batch or an NHSN CDA export? Have they pulled data off dialysis machines, and do they know which manufacturers make that easy and which do not? A team that has done two of those four is credible. A team that has done none will discover the cost during your project.
Make compliance an architecture question, not a checkbox. The right partner talks unprompted about audit trails on every write, immutable event history, role-based access down to the site, break-glass logging, BAAs with every subprocessor, and how the system produces evidence when a surveyor is standing at the desk. If HIPAA comes up only as encryption at rest, they have not done this in a live unit.
Settle ownership and exit in the contract. You own the repository, the infrastructure accounts, and the data, from day one, not at final payment. Ask for the runbook and a named handover plan before kickoff. You will run this system for a decade. Get the wrong answer here and you pay for it five years out, when switching costs are highest.
The evidence behind this guide
Independent findings on why this investment pays off. Every link goes to the primary source.
- The 2015 CHAOS data (based on the modern definition of success) reports that only about 29% of software projects succeed, 52% are challenged, and 19% fail, with the three most important success skills being executive sponsorship, emotional maturity, and user involvement. Source: The Standish Group (reported via InfoQ Q&A with Jennifer Lynch) (2015) →
- The average developer spends more than 17 hours a week dealing with maintenance issues such as debugging and refactoring, and about four of those hours on 'bad code' - waste that equates to nearly $85 billion annually worldwide in opportunity cost. Source: Stripe (2018) →
- SaaS spend averaged $4,830 per employee (up 21.9% year over year), with large enterprises (10,000+ employees) spending roughly $284M annually and running about 660 apps, while organizations wasted an average of $21M annually on unused licenses. Source: Zylo (2025) →
- An analysis of enrollment and completion data for 221 MOOCs (Katy Jordan, published in the International Review of Research in Open and Distributed Learning, IRRODL, 16(3), 2015 - not the Journal of Distance Education) found completion rates ranging from 0.7% to 52.1%, with a median completion rate of 12.6%, and completion negatively correlated with course length (longer courses had lower completion rates) - underscoring how unsupported self-paced online courses struggle to finish learners. Source: Journal of Distance Education (via ERIC / Katharina Jordan) (2015) →
Rohan advises mid-market and enterprise teams on ERP, CRM and custom software, and has led delivery on dozens of business-software builds.
Writes for Digital Heroes, shipping business software for 2,000+ brands across 55+ countries since 2017.