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 minBrowser agentCustomer portal login
We map your process, volume, and exception paths, then recommend a practical first scope.
Building internally? Read the docs →
Overview
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
A facility name, a report type, and its parameters (billing month, date range, or document category)
The report file in your downloads, data lake, or billing pipeline
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.
Edited UB-04 export: a person confirms first: The edited UB-04 export pauses for human confirmation before opening the billing screen, because that screen sits next to submit controls. Every other export is read-only and runs unattended.
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.
{ "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."}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
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. Scope your facility list and report cycle; the rest of the category is in the EHR library.
Human in the loop
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. Posture in full on the security page.
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.
Questions
Month-end in long-term care is a week of report screens. Run them on a schedule and read the files instead. The EHR library covers the rest of the extraction surface.
Disclaimer
Third-party names, including government agencies and registries, are used only to identify systems commonly involved in healthcare operations workflows. Asteroid is not affiliated with, endorsed by, sponsored by, or certified by those third parties unless expressly stated. Workflow availability depends on customer authorization, account permissions, configuration, and applicable system terms.