How pre-visit automation assembles nephrology charts before the appointment starts.

What is a nephrology chart prep and pre-visit planning platform?

TL;DR: A nephrology chart prep and pre-visit planning platform assembles the patient chart before the appointment — retrieving outside dialysis flowsheets, lab trends, and transplant center records, reconciling medications, and filing the results into the EHR as usable data. In nephrology the work is mostly cross-organization retrieval, because the values that drive the visit live in the dialysis organization's system and the transplant center's records rather than in the practice's own chart. The nephrologist opens a chart that's ready for the visit instead of assembling one during it.

What a nephrology chart prep platform actually does

A chart prep platform runs in the window before a scheduled appointment — usually 24 to 72 hours out — and does the assembly work a medical assistant would otherwise do by hand, or that nobody does at all until the physician opens the chart.

For a nephrology practice, that assembly is specific. The platform pulls the most recent monthly dialysis flowsheet from the dialysis organization. It retrieves outside lab results the practice didn't order. It checks whether the transplant center has posted new tacrolimus troughs or surveillance PCRs. It reconciles the medication list against what the dialysis unit is actually administering. Then it files those values into the EHR as discrete, trendable data rather than a PDF someone has to open and read.

The distinction between a filed PDF and discrete data matters more than it sounds. A scanned flowsheet sitting in the media tab is technically in the chart, but the nephrologist still has to open it, find the Kt/V, and compare it mentally to last month's. Extracted data lands in a flowsheet row and trends automatically.

The term "pre-visit planning" comes from primary care, where the AMA's pre-visit planning model covers pre-visit lab ordering, chart review, and team huddles. Nephrology inherits that framework but shifts the center of gravity. Your labs are usually already drawn — they're just drawn somewhere else, by someone else, and they haven't made it into your chart yet.

Why nephrology charts are harder to prep than most

Most specialties prep charts that are mostly complete. Nephrology preps charts that are structurally incomplete by default.

A dialysis patient generates clinical data three times a week inside an organization that isn't your practice and doesn't share your EHR. A transplant patient generates surveillance labs at a transplant center on its own schedule. A CKD patient's eGFR trend may run through a primary care office, a cardiologist, and two different hospital systems. The practice EHR holds your notes — but a meaningful share of the numbers you need to make decisions originated outside it.

This is why generic pre-visit tools underperform in nephrology. They're built to summarize what's already in the chart. The nephrology problem is getting things into the chart in the first place.

The scale is not small. The CDC estimates that roughly 14% of US adults have chronic kidney disease, and NIDDK reports that about 550,000 people in the US receive dialysis, with another third of the kidney failure population living with a transplant. For a practice carrying a few hundred dialysis and transplant patients on recurring monthly visits, the retrieval burden compounds every single month rather than arriving once.

There's a billing dimension too. Monthly capitated payment for dialysis patients depends on documented visits with the supporting clinical picture. When the flowsheet never arrives, you have a documentation gap sitting underneath a claim.

The four layers of pre-visit automation

Most platforms in this category are doing four separable jobs. Evaluating them separately is useful, because vendors are rarely equally good at all four.

  • Retrieval. Getting records out of systems you don't control — dialysis organization portals, transplant center interfaces, outside lab systems, hospital release-of-information queues, and inbound fax. This is the layer that most often decides whether a deployment succeeds, and it's the least glamorous.
  • Extraction. Reading a retrieved document and pulling the values that matter. A monthly flowsheet contains dozens of fields; the ones that change your visit are a much shorter list.
  • Filing. Writing extracted values into the EHR as discrete data in the right place, attached to the right patient and the right encounter. Filing to the wrong patient is the failure mode that erodes staff trust fastest.
  • Surfacing. Flagging what the physician should notice — a phosphorus trending up over three months, a lapsed BK PCR, an access that hasn't been evaluated.

A practice that already has decent retrieval through an existing interface may only need extraction and filing. A practice drowning in fax needs retrieval most. Honey Health's data fetching agent sits primarily in the retrieval-and-filing layers, which is generally where the recurring manual hours are concentrated in nephrology.

How is chart prep different from an AI scribe?

They operate at different points in the visit and solve different problems.

An AI scribe listens during the encounter and produces the note afterward. It reduces documentation time. It does nothing about the fact that the dialysis flowsheet you needed was never in the chart — a scribe can only document the conversation that happened, not supply the data that was missing from it.

Chart prep runs before the visit and changes what information is available when the encounter starts. If the transplant center's latest tacrolimus trough is in the chart at 8 a.m., the visit goes differently than if it surfaces two weeks later.

Practices often end up running both, and they don't conflict. A useful way to think about the split: scribes reduce the cost of documenting the visit, chart prep reduces the cost of preparing for it. If your physicians complain about after-hours charting, a scribe addresses that directly. If they complain about walking into visits without the data they need, or about visits that get rescheduled because records never arrived, that's a chart prep problem and a scribe won't touch it.

How much time does pre-visit planning actually save?

The physician-time numbers are well documented, though most of the published research comes from primary care rather than nephrology specifically.

AMA research on EHR workload found that chart review alone consumes about 1.1 hours for every 8 hours of scheduled patient care, with inbox work adding roughly another 0.8 hours. A 2024 study tracking primary care physicians from 2019 to 2023 found both categories moving in the wrong direction, with chart review time up 13% and inbox time up 24% over that period.

On the savings side, the AMA's pre-visit planning work estimates roughly 30 minutes of combined physician and staff time returned per day, which it values at about $26,400 per physician per year at 220 clinic days.

Treat that as a directional benchmark rather than a promise. It was measured in primary care, and your result depends on how much of your retrieval work is already handled by an existing interface. What we'd suggest instead: measure staff minutes per chart on one visit type before you change anything, then measure the same thing 60 days after. Practices with heavy dialysis and transplant panels tend to see the largest gap, because their baseline retrieval burden is the highest.

Who owns chart prep inside the practice?

The platform is software, but the workflow around it needs an owner, and practices that skip this step tend to get uneven results.

In most nephrology practices the work currently belongs to whoever has time — a medical assistant on Monday, the front desk on Thursday, the physician at 9 p.m. when nobody got to it. That diffusion is part of why the burden is hard to measure. Nobody's job description says "retrieve the dialysis flowsheet," so nobody reports being behind on it.

After automation, the ownership picture changes shape. The retrieval itself stops being a person's task, but three responsibilities appear in its place:

  1. Exception handling. Someone works the queue of records that couldn't be matched, retrieved, or reconciled. This is usually a fraction of prior volume, but it's real and recurring.
  2. Source monitoring. When a dialysis organization changes its portal or a connection quietly breaks, somebody needs to notice before a week of charts go unprepped.
  3. Quality spot-checks. Sampling filed values against source documents, weekly at first and less often once confidence is established.

Practices commonly assign all three to one experienced MA or a clinical operations coordinator rather than splitting them. That person becomes the human check on the system, and the role tends to be more skilled and less repetitive than what it replaced.

We'd flag one pattern to avoid: treating the platform as fully autonomous from day one. The groups that pilot on a single visit type, watch the exception queue closely for a month, then expand are the ones whose staff still trust the tool a year later.

What a chart prep platform won't do for you

Being clear about the limits is the fastest way to avoid a disappointing deployment.

It won't make clinical decisions. The platform surfaces that phosphorus has climbed for three months; deciding what to do about it stays with the nephrologist. Any vendor blurring that line deserves scrutiny.

It won't eliminate the human exception queue. When two sources report conflicting dry weights, or a document arrives without enough identifiers to match a patient confidently, that needs a person. A well-designed platform routes those cases cleanly instead of guessing. Expect a real exception rate and staff it deliberately — the practices that skip this step are the ones that lose confidence in the tool after a bad auto-file.

It also won't fix a source you can't access. If the dialysis organization won't grant a data connection, no amount of AI creates one. In most implementations, negotiating source-system access takes longer than configuring the software, and that sequencing surprises people. Ask any vendor which of your specific sources they already connect to, and treat a vague answer as a red flag.

Frequently Asked Questions

How far in advance should chart prep run?

Most practices run a 24-to-72-hour window. Too early and you miss labs that resulted after the prep ran; too late and there's no time to chase a missing record before the visit. A common pattern is an initial pass at 72 hours to identify gaps and trigger requests, then a refresh pass the day before.

Does a nephrology chart prep platform replace medical assistants?

Generally no — it shifts what they do. The repetitive retrieval and data entry moves to software, while staff handle exceptions, conflicting values, and records that require a phone call. Most practices report reallocating that time to patient-facing work rather than reducing headcount.

Does this work with our existing nephrology EHR?

It depends on the integration method available. Platforms typically write back through an established interface, an API, or direct EHR integration. Ask specifically how a vendor files discrete data — not just documents — into your system, since document-only filing leaves most of the manual work in place.

What data should chart prep pull for a dialysis patient?

The recurring short list is the monthly flowsheet, Kt/V and URR, interdialytic weight gain and dry weight, pre- and post-dialysis blood pressures, ESA dosing, vascular access status, and mineral and bone labs including calcium, phosphorus, and PTH. Transplant patients need a different set built around immunosuppression levels and surveillance PCRs.

Is patient data retrieval through these platforms HIPAA-compliant?

It should be. Any vendor handling protected health information needs to operate under a signed business associate agreement and maintain appropriate safeguards under the HIPAA Security Rule. Ask for the BAA, ask where data is stored and how long it's retained, and treat HITRUST certification as a useful signal rather than a requirement.

More of our Article
CLINIC TYPE
LOCATION
INTEGRATIONS
More of our Article and Stories