A nephrology EHR is the clinical record for a kidney practice and, very often, for the dialysis units its physicians round in. It follows a patient from early chronic kidney disease through dialysis or transplant, and lab trends, staging rules and federal facility requirements shape almost every screen.
This guide covers CKD staging data, the dialysis facility timelines in 42 CFR Part 494, reporting to CMS through EQRS, the treatment record behind the ESRD bundled payment, monthly physician billing, and the failure points that make kidney care software hard to get right.
What is a nephrology EHR?
Connecting a kidney practice and its dialysis units?
Agnotic builds nephrology software for the client: lab and staging feeds, dialysis machine interfaces, EQRS data preparation and EHR integration.
A nephrology EHR is a clinical record built around kidney function over time. It stores eGFR and urine albumin results as staged trends, runs the comprehensive assessments and care plans that federal rules require of dialysis facilities, captures each dialysis treatment, and feeds patient data to the CMS EQRS system.
Two settings meet in one patient. The office practice manages earlier stages of chronic kidney disease, transplant referral and dialysis planning. The dialysis facility runs the recurring treatments under its own Medicare conditions for coverage for ESRD facilities.
Those settings frequently run different software. The nephrologist signs notes in the practice EHR and also writes orders and progress notes in the facility's dialysis system, so the integration question appears early in almost every kidney care project.
A useful way to scope the work is to follow one patient for a year. List every lab result, visit, treatment, assessment and report that patient generates, note which system creates it and which systems need it, and the integration map falls out of that list.
How should CKD staging live in the record?
CKD staging should be computed from discrete lab results and stored with the method that produced it, not typed into a problem list. The KDIGO 2024 guideline classifies CKD by cause, GFR category (G1 to G5) and albuminuria category (A1 to A3), a scheme it calls CGA, and requires the abnormality to persist for more than 3 months.
- GFR category: calculated from each eGFR result, with the lab's reported value kept next to any value the system recalculates.
- Albuminuria category: calculated from the urine albumin-to-creatinine ratio, which is a separate order from serum creatinine and often arrives on a different day.
- Persistence: the stage changes only when results over the required period agree, so one acute drop during an admission does not restage a patient.
- Cause: the C in CGA is a clinical judgment, such as diabetic kidney disease or glomerulonephritis, entered and owned by the nephrologist rather than inferred by the software.
The equation behind each eGFR value matters as much as the number. Laboratories have changed estimating equations over the years, including a move away from equations that used race. A record that stores only the reported eGFR, without the equation name and the serum creatinine, cannot recalculate the history, and a trend line can shift on the date the lab switched.
Staging also drives work. A patient moving into the later stages typically needs dialysis modality education, vascular access planning and a transplant referral discussion, so a stage change should create tasks for the care team rather than a silent label update.
The display deserves design time. Nephrologists read kidney function as a slope, so a chart of eGFR over several years with stage bands, medication starts and hospital admissions marked on it answers more questions than a table of the last five results.
Which Part 494 timelines does dialysis software track?
Dialysis software tracks the assessment and care plan clocks in the Medicare conditions for coverage for ESRD facilities. Under 42 CFR 494.80, the interdisciplinary team completes a comprehensive assessment within the latter of 30 calendar days or 13 outpatient hemodialysis sessions, then reassesses at least annually for stable patients and at least monthly for unstable ones.
Each clock starts from a specific event, so the system needs that event as a dated field. For the initial assessment, that means the first outpatient dialysis session and a running count of sessions, because whichever limit comes later sets the due date.
- Owned sections: the assessment spans the dialysis prescription, anemia, bone disease, nutrition, psychosocial needs, vascular access and transplant suitability, and each section belongs to a discipline such as the dietitian or social worker.
- Section status: each owner sees which sections are open for which patients, rather than one shared form that nobody knows is unfinished.
- Care plan link: the plan of care is built from the completed assessment, so findings flow into goals instead of being retyped.
- Stability flag: the unstable flag carries a reason, the person who set it and the date, because it changes the reassessment interval.
- Due list: the scheduler recalculates the next due date the moment the flag or the session count changes, and shows overdue items at the top.
Surveyors read these records, so the audit trail matters. Every signature, date change and section completion should be logged with the user and time, and a late assessment should stay visibly late rather than being backdated.
How does facility data reach EQRS?
Dialysis facilities send patient and clinical data to CMS through the ESRD Quality Reporting System (EQRS). EQRS took over the roles and functions of the older CROWNWeb system in November 2020, so vendor documents that still say CROWNWeb describe the same reporting duty.
- Patient events: admissions, transfers, modality changes, transplants and deaths, so EQRS knows which facility is responsible for each patient.
- Medical evidence: the ESRD medical evidence form for a patient starting dialysis, completed in EQRS with a signed copy handled as EQRS guidance describes.
- Clinical data: lab values and treatment measures used by quality measures, entered by hand or sent in batches from the facility's own system.
Batch submission saves hours of rekeying, but it moves the quality problem upstream. Every lab result needs a reliable collection date, a link to the right patient and a code the measure logic can read, so the mapping work happens long before the file is built.
A practical sequence for a batch feed looks like this. First, reconcile the facility's patient list with EQRS so every active patient matches. Second, map each lab and treatment field to the EQRS element and record the mapping in a document both teams sign. Third, run a parallel month where staff still enter data by hand and the feed's output is compared line by line. Only then switch off manual entry.
The dialysis treatment record
Each dialysis session produces its own record: pre and post weight, blood pressure, ultrafiltration goal and volume removed, blood and dialysate flow rates, the access used and any events during treatment. Many machines can send these values to the facility system through an interface, with staff confirming them at the chairside.
Payment is the second reason the treatment record matters. Medicare pays outpatient dialysis through a bundled per-treatment payment that also covers many dialysis-related drugs and laboratory tests, so the record should flag whether each drug or lab order is part of the dialysis bundle or for an unrelated condition.
Home dialysis changes the source of the data. Home hemodialysis and peritoneal dialysis patients record treatments themselves, often through a machine that uploads to the manufacturer's platform, so the facility record has to import those sessions and show gaps when a patient stops sending them.
- Machine feed: confirm which values the machine sends, how often, and how a session is matched to the patient in the chair.
- Chairside review: staff accept or correct imported values before the session is signed, and the record keeps both.
- Home import: decide how often home sessions are pulled, who reviews them and what counts as a missed treatment.
- Bundle flag: set it at order entry so billing does not have to guess later.
How do nephrologists bill monthly ESRD care?
Nephrologists bill outpatient dialysis care with monthly codes, not per visit. For in-center patients the code depends on the number of face-to-face visits in the month and the patient's age, while home dialysis months are paid at a single monthly rate by age.
The visit log is where integration pays off. When the nephrologist documents rounds in the facility system, the practice billing team needs those encounters in the practice EHR before month end, or the claim drops to a lower visit tier.
- Visit capture: each face-to-face visit with date, location and practitioner, pulled from the facility system rather than reported from memory.
- Month-end check: a report of patients whose visit count is one short of the next tier, while there is still time to see them.
- Partial months: hospital stays, transfers and deaths change how the month is billed, so these events need to reach billing as well.
- Shared care: when a partner or advanced practice provider rounds, the record shows who saw the patient, so the monthly claim goes to the right practitioner.
Failure points in kidney care software
- eGFR without its equation: history cannot be recalculated, and trend lines jump when the lab changes method.
- Staging from one result: a single acute drop stages a patient as CKD without the persistence KDIGO requires.
- Unstable flag with no date: monthly reassessments are missed because the scheduler still uses the annual interval.
- Two records, no feed: rounding notes stay in the dialysis system and the practice bills the wrong visit tier.
- Hand-entered EQRS data: values typed twice drift apart, and quality measure results differ from the chart.
- Bundle flag missing: drugs and labs that belong in the dialysis bundle are billed separately, or the reverse.
- Home sessions invisible: when a home machine stops uploading, nobody sees the gap until the monthly review.
A useful test before go-live is to replay a full month of real treatment, lab and rounding data through the new feeds, then compare the staging, assessment due dates and visit tiers with what staff calculated by hand.
How Agnotic can help
Kidney care software spends most of its effort moving data between the lab, the dialysis chair, the practice chart and CMS. Agnotic Technologies designs and builds those data paths for the client: staging logic on discrete lab results, dialysis machine and home treatment imports, assessment schedulers, EQRS batch preparation and the rounding feeds that keep monthly billing accurate.
Agnotic works inside the client's chosen EHR and dialysis system through their supported interfaces, so each system stays the record for its own setting while the patient's story stays in one piece.
Plan a nephrology EHR integration with Agnotic
Review EHR integration services for kidney practices, or browse the EHR integration hub for lab and dialysis interface articles.
Related reading on Agnotic
Continue with lab results messaging, EHR integrations and other specialty record guides.
