Export Census, Orders and Billing Reports from Long-Term Care EHRs

Pull the reports a skilled nursing or home health operator runs by hand every week, per facility, on a schedule: resident census, UB-04 claim forms by billing month, MDS assessment history, progress notes, order summaries, diagnosis sheets, patient rosters. Each export is a single-purpose agent, and all of them share one login and one facility-selection pattern.

Go-live in as little as 30 min·Browser agent·Customer portal login

See it run on your systems.

We map your process, volume, and exception paths, then recommend a practical first scope.

Overview

What this workflow does

Long-term care and home health EHRs hold operational and billing data behind report screens with no export API. Someone signs in, picks the facility, sets the parameters, runs the report, waits, and downloads the file, for every facility, every cycle. These agents run that sequence for one facility per run and return the file.

On the long-term care EHR the exports available today cover the resident list (thirteen columns: demographics, location, admission and discharge dates, primary physician, primary diagnosis, payer identifiers) as CSV, UB-04 claim forms for a facility and billing month in trial, edited, and final states across Managed Care, Medicare A, Medicare B, and Outpatient payer types, progress notes over a date range, length of stay grouped by payer, stored documents by category, order summary, action summary, evaluation history, MDS assessment history as PDF, and diagnosis sheets covering active and inactive residents.

On home health EHRs the same pattern exports the patient roster (census, active, and pending) as spreadsheets. Order-document extraction for a patient or date window, and physician and insurance-plan directory exports, are in the catalogue pipeline.

How Asteroid runs this workflow

A schedule or request names a facility and a report, Asteroid signs in through your SSO, selects that facility, sets the parameters, runs the report, waits for it to generate, and returns the file, and a facility name that does not match exactly one facility stops the run before anything is run.

How it actually runs

1. 01Sign in through your identity provider’s app portal (the default for most tenants) or the EHR’s direct login.
2. 02Switch to the named facility. The name must match exactly one facility.
3. 03Open the report and set its parameters: billing month for UB-04 exports, date range for progress notes and evaluation history, document category for stored documents. Facility-wide reports leave resident, unit, and floor set to all.
4. 04Submit and poll until the report is ready. Return Pending with the request handle and polled seconds if it is still generating.
5. 05Download the file and return facility, period covered, file name, and outcome as structured JSON.

What lands back in your system

The exported file and a structured record of facility, report, period covered, and outcome (Success, Pending with a request handle, or a named failure) land where your operations or billing team consumes them.

Closing the loop

Nobody on your team reads this JSON. Your system does. Each run delivers its record wherever the work already lives, and the loop closes on its own: requests in, records back, no one in the middle.

Sample JSON Output

{
  "outcome": "success",
  "facility": "Sample Post Acute",
  "report": "Resident List",
  "file_downloaded": true,
  "file_name": "resident_list_sample_post_acute_2026-08.csv",
  "period_covered": "as of 2026-08-31"
}

{
  "outcome": "pending",
  "facility": "Sample Post Acute",
  "report": "UB04 Final",
  "request_handle": "rpt-7f3a21",
  "polled_seconds": 600,
  "explanation": "Report submitted for billing month 2026-07; still generating when polling stopped."
}

One report, one agent, one facility

Every export here is a single-purpose primitive rather than one agent with a report-type menu. That looks like more agents and it is. It is also why a failure names the report and facility that failed, why a new report is a small build instead of a change to a shared one, and why an operator with thirty facilities can run thirty exports in parallel on a schedule and get thirty separate outcomes. The shared part is the login and the facility switch, and that is where the maintenance lives.

At scale

What runs today

Thirteen exports run today as templates on a long-term care EHR, plus patient roster exports on two home health EHRs. Order extraction and directory exports on home health EHRs are in the catalogue pipeline. The same data extraction discipline runs at scale in patient data extraction and sync-back, where one deployment extracts 40,000 patient records a month across 11 EHRs. Downstream, UB-04 exports feed claim status and denial work.

Human in the loop

What escalates to a human

Runs on HIPAA-compliant infrastructure with SOC 2 Type II and a BAA, and every execution leaves a step-by-step audit trail of what was selected, run, and downloaded. A facility name that matches zero or several facilities. The run stops before any report runs and names the mismatch. Exact match is required. The edited UB-04 export. Pauses for a person to confirm before the billing screen opens. Every other export is read-only. A report still generating. Returned as Pending with the request handle and how long the run waited, so a follow-up run collects it instead of re-running it. Login, report, or download failure. Reported with a named reason: login_failed, facility_not_found, report_not_found, report_failed, download_failed, or timeout, plus what happened and where the run stopped.

Frequently asked questions

Which reports are available today, and how is a new one added?

On the long-term care EHR: resident list, UB-04 trial, edited, and final, progress notes, length of stay, document storage by category, order summary, action summary, evaluation history, MDS assessment history, and diagnosis sheets. On home health EHRs: patient roster as census, active, and pending spreadsheets. A new report on an EHR already built is a small addition, because login and facility selection are shared. A new EHR is scoped against your instance with the report list you run today.

How do we run this across many facilities on a schedule?

Each run covers one facility, by design. A thirty-facility operator schedules thirty runs of each export, in parallel, each returning its own file and outcome. A facility that fails does not block the others, and the failure names the facility. Schedules live on the platform, so month-end reports are waiting when the billing team arrives.

What happens when a report is slow to generate?

The agent polls until the report is ready or the polling window ends. If the report is still generating, the run returns Pending with the request handle and the seconds waited, rather than failing or re-submitting. A follow-up run collects the finished report. This keeps large UB-04 and MDS exports from being re-queued on the EHR side.

Which exports write anything, and where is the human gate?

None of them write. Every export is read-only. The one gate is the edited UB-04 export, which pauses for a person to confirm before opening the billing screen, because that screen sits beside submit controls. The confirmation is a click, and the run resumes and downloads. Every other export runs unattended.

What access does the agent need, and how is PHI handled?

An EHR login, usually through your identity provider’s app portal, held in an agent profile scoped to reporting and revocable on your side. Exported files contain PHI and go only to the destination you configure. Structured outputs carry facility, report, period, and file name, not resident data. Every run executes under a BAA on SOC 2 Type II infrastructure.