TL;DR: Chart prep for dialysis and transplant patients differs from general pre-visit planning because the data that drives the visit originates outside the practice — in the dialysis organization's system and the transplant center's records. The work is mostly cross-organization retrieval and reconciliation rather than tidying a chart you already control. Getting it right means defining a specific data list per population, connecting to the outside sources that hold it, and routing conflicting values to a human instead of auto-filing them.
Why these two populations break normal chart prep
Most pre-visit tools assume the chart is basically complete and needs summarizing. For dialysis and transplant patients, that assumption is wrong in a way that matters.
A patient on in-center hemodialysis generates clinical data three times a week inside a dialysis organization that isn't your practice and doesn't share your EHR. A kidney transplant recipient gets surveillance labs drawn on the transplant center's protocol and schedule. In both cases, the numbers your nephrologist needs to make decisions were generated somewhere else, by someone else, and arrive in your chart only if someone goes and gets them.
The population is large enough that this compounds. NIDDK reports about 550,000 people in the US receiving dialysis, with roughly a third of the kidney failure population living with a functioning transplant. These aren't annual visits — dialysis patients are typically seen monthly, which means the retrieval work repeats twelve times a year per patient rather than once.
So the operational question isn't "how do we summarize the chart faster." It's "how do we reliably get outside records in before the visit, month after month, without a person chasing each one."
What dialysis chart prep actually requires
The list is short, stable, and worth writing down explicitly, because "pull the dialysis records" isn't a specification anyone can act on consistently.
For in-center and home dialysis patients, the recurring set is:
- The most recent monthly flowsheet from the dialysis organization
- Adequacy measures — Kt/V and URR
- Volume status — interdialytic weight gain and current dry weight, plus pre- and post-dialysis blood pressures
- Anemia management — hemoglobin, ferritin, transferrin saturation, and current ESA dosing
- Mineral and bone parameters — calcium, phosphorus, and PTH, with binder and vitamin D dosing
- Vascular access — access type, date of last evaluation, and any recent access events or interventions
Home dialysis patients add their own wrinkle. Peritoneal dialysis prescriptions, exchange volumes, and any peritonitis history live in a different part of the dialysis organization's records than in-center flowsheets, and practices frequently discover that their retrieval setup captures one but not the other.
The single most useful design decision is filing these as discrete data rather than a document. A scanned flowsheet in the media tab is technically present, but the nephrologist still has to open it, locate the Kt/V, and mentally compare it to last month. Extracted values land in a flowsheet row and trend on their own.
What transplant chart prep requires
Transplant patients need a different list built around immunosuppression and surveillance, and it changes with time since transplant.
The core set covers tacrolimus or cyclosporine troughs, mycophenolate dosing, and the current prophylaxis regimen. Surveillance adds BK and CMV PCR results, which follow a protocol that tapers as the patient moves further from transplant. Graft function tracking needs creatinine trend and proteinuria, ideally alongside the patient's own post-transplant baseline rather than a general reference range.
Two aspects make transplant retrieval harder than dialysis. First, the schedule isn't uniform — a patient three months out is monitored far more intensively than one five years out, so a fixed monthly pull either over-retrieves or misses. Second, transplant centers vary widely in what they share and through what mechanism. A practice with patients at three transplant centers may be managing three entirely different retrieval paths.
Timing deserves particular care here. An immunosuppression level retrieved after the visit is close to useless for that encounter. If your prep window can't reliably capture the most recent trough before the appointment, the workflow needs adjusting rather than accepting.
Designing the retrieval cadence for each population
One prep schedule will not serve both populations well, and trying to force it is a common early mistake.
Dialysis patients suit a predictable monthly rhythm. The flowsheet posts on a known cycle, the visit recurs monthly, and the data set barely changes. A two-pass approach works cleanly here: an initial pull roughly 72 hours before the visit that identifies anything missing and triggers a request, then a refresh the day before to capture whatever landed in between. Because the cadence is stable, this is also the population where automation shows results fastest.
Transplant patients need a schedule tied to time since transplant rather than the calendar. A patient in the first post-transplant year is monitored intensively, with frequent trough levels and active surveillance PCRs. A patient several years out on stable immunosuppression is monitored far less often. A fixed monthly pull will over-retrieve for the second group and miss values for the first.
The practical approach is to tier your transplant panel — early post-transplant, intermediate, and stable long-term — and set retrieval frequency and prep windows per tier. It takes an afternoon to categorize the panel and prevents a persistent mismatch between when data is needed and when it's fetched.
CKD patients who haven't started kidney replacement therapy sit in a third category, and they're the hardest to systematize because their outside sources are the most scattered. USRDS data shows how large the pre-dialysis CKD population is relative to those on kidney replacement therapy, which means most practices carry far more of these patients than dialysis patients — but with lower visit frequency and less predictable data sources. Most groups automate this last, after the higher-volume repetitive populations are working.
Why missing records create a billing problem too
The clinical gap is obvious. The revenue side gets less attention and is worth naming for anyone building the case internally.
Monthly capitated payment for dialysis patients depends on documented visits with the supporting clinical picture. When the flowsheet never arrived, the encounter may still happen, but the documentation underneath it is thinner than it should be — which becomes a problem during an audit rather than at the time of service.
There's also a rescheduling cost most practices don't measure. When records don't arrive, some visits get pushed. That's an empty slot, a staff member making calls, and a patient making a second trip. Track how often this happens over a month before assuming it's rare; practices are routinely surprised.
Consider tracking the percentage of visits that start with a complete chart as an operational metric alongside your clinical measures. It correlates with both physician satisfaction and clean documentation, and unlike most quality metrics it's straightforward to measure.
Connecting to the sources that hold your data
This is where these projects actually succeed or stall, and it's rarely a technology problem.
Dialysis organizations differ in what they offer. Some provide a portal, some support an interface, and some send nothing but faxed monthly reports. Large dialysis organizations generally have more established data-sharing pathways than independent units, but "more established" still means a negotiation with a named person on their side.
Transplant centers are less standardized still. Expect to work through each one individually, and expect the conversation to involve their release-of-information process rather than an IT integration team.
Plan for fax as a permanent part of the mix rather than a legacy problem that will resolve itself. A meaningful share of nephrology's inbound clinical data still arrives that way, particularly from smaller dialysis units and independent labs. A platform that can extract discrete values from a faxed flowsheet rather than filing the image is doing materially different work than one that just routes documents. Honey Health's data fetching agent covers retrieval and filing across portal, interface, and fax sources, which matters here because most nephrology practices have all three in play simultaneously.
Start these access conversations early. In most implementations, negotiating source access takes longer than configuring the software.
What still needs a human
Automated retrieval handles volume well. It handles contradiction poorly, and nephrology produces contradictions regularly.
When the dialysis unit reports a dry weight that disagrees with your chart, or two sources report different current medications, or a transplant center's creatinine doesn't match the outside lab drawn a day later — a person needs to reconcile that. Software should surface the conflict clearly and stop, not pick a winner. In a specialty where these values drive dosing decisions, a system that resolves conflicts silently is a liability.
The same applies to patient matching. A document arriving without enough identifiers to match confidently should route to a human queue. Auto-filing to the wrong chart is the failure that destroys staff trust fastest, and one incident undoes months of accumulated confidence.
Build the exception queue into the plan from the start and assign it to someone specific. In a well-configured deployment it's a fraction of the prior manual workload — but it isn't zero, and treating it as zero is how these projects disappoint.
Frequently Asked Questions
What data should be pulled before a monthly dialysis visit?
The recurring set is the most recent monthly flowsheet, Kt/V and URR, interdialytic weight gain and dry weight, pre- and post-dialysis blood pressures, ESA dosing with anemia labs, vascular access status, and mineral and bone parameters including calcium, phosphorus, and PTH. File these as discrete values rather than a document so they trend automatically.
How is transplant chart prep different from dialysis chart prep?
Transplant prep centers on immunosuppression levels, surveillance PCRs for BK and CMV, creatinine trend, and proteinuria, while dialysis prep centers on adequacy, volume, anemia, and mineral and bone management. Transplant monitoring also tapers with time since transplant, so a fixed retrieval schedule fits it poorly.
Can chart prep automation pull records from a dialysis organization?
Usually yes, but it requires a data-sharing arrangement with that organization. The mechanism varies — portal access, an interface, or faxed monthly reports. Ask any vendor which specific dialysis organizations they already connect to rather than accepting a general claim of compatibility.
How far ahead should we prep a transplant patient's chart?
Close enough to the visit that the most recent immunosuppression trough is captured, which usually means 24 to 48 hours rather than the longer window that works for dialysis. Levels retrieved after the appointment provide little value for that encounter.
What happens when two sources report conflicting values?
The conflict should route to a human for reconciliation rather than being auto-filed. Conflicting dry weights, medication lists, or lab values are common in nephrology because data arrives from multiple organizations on different schedules. A platform that resolves these silently rather than flagging them introduces risk in a specialty where the numbers drive dosing.
