Make sure a patient chart exists in the EHR with the demographics you have, then file the inbound document into it: referral, prior-auth decision, lab or imaging result, signed order. The patient is found or created, the document lands under the right label, and the agent verifies it actually persisted before it reports success.
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
Two single-purpose primitives are built to chain. Patient creation finds the patient by name, date of birth, and sex. If the chart exists, it updates only the fields you supplied, insurance number and referring provider included, and ends with a patient-found outcome. If not, it creates the chart and ends with patient-created. Either way it reports the EHR account number and the rendering provider on record, which every downstream workflow needs.
Document filing takes the PDFs attached to the run, finds the patient (read-only, verifying the account number when you have one), uploads every file into one folder of the chart, and when asked marks each document Reviewed. Then it checks the EHR’s own document tree to confirm the Reviewed state persisted, because the on-screen checkbox can silently fail. It refuses to report success unless the verified count matches the uploaded count.
On practice-management systems the two fuse into one run: find the patient by last name and date of birth or create them, add an insurance case for new patients, file the document under the label its type implies (a referral as Referral Received, a prior-auth decision as Authorization, a lab or imaging result as Medical Report, a DME order as Order), skip a duplicate referral filed in the last seven days, and message the named staff member when a signature is needed.
How Asteroid runs this workflow
A document and patient details arrive from your intake, referral, or documentation pipeline, Asteroid finds or creates the patient, files the PDF under the correct label, verifies it persisted, and notifies staff when a signature is due, and an ambiguous patient match stops the run rather than filing into the wrong chart.
How it actually runs
An inbound PDF with patient demographics, document type, and optional insurance and referring provider
A verified document on the right chart, with the account number back
The EHR account number, rendering provider, folder or label used, files uploaded, and verified-reviewed count return as structured JSON to your intake pipeline, ready for the next step.
Ambiguous or missing patient match: More than one chart matches, or the supplied account number does not match the chart found, and the run stops with the candidates listed. A person resolves identity once. Filing into the wrong chart is the one error this workflow must never make.
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": "patient_created", "account_number": "48213", "first_name": "JANE", "last_name": "SAMPLE", "dob": "01/15/1980", "insurance": "Medicare Part B", "rendering_provider": "SMITH, JOHN", "summary": "New chart created with demographics and insurance; referring provider set."}{ "folder": "Referrals", "documents_uploaded": 2, "files": "referral_2026-08-14.pdf, clinical_notes.pdf", "reviewed_count": 2, "summary": "2 documents filed to Referrals; both verified Reviewed in the document tree."}In more than one EHR, the Reviewed checkbox can be ticked on screen and not saved. A workflow that reports success from the click leaves documents in the review queue and no one knows until a provider asks where the lab result went. This agent re-reads the document tree after every upload and only reports the count it can prove. A mismatch between uploaded and verified is a failure, reported as one. The same discipline applies to patient creation: the account number in the output is read back from the EHR, not assumed from the form.
At scale
Patient creation and document filing run in production today on a widely used ambulatory EHR and on a practice-management system, as the write half of intake pipelines fed by referral network intake and inbound referral capture. Home health and hospice EHR builds, which file signed documents and update the matching order status, are in the catalogue pipeline. Downstream, the account number feeds referral creation and appointment booking. 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 read, created, uploaded, and verified. Posture in full on the security page.
An ambiguous patient match.
More than one chart fits the name and date of birth, or the account number does not match. The run stops with the candidates listed. Nothing is filed.
Patient not found on a filing-only run.
Reported as its own clean outcome, ready to chain into patient creation. Never a guessed match.
No files attached to the run.
The run stops before touching the chart and names the gap.
A Reviewed state that did not persist.
Uploaded count and verified count disagree. Reported as a failure with both numbers, never rounded up to success.
A folder that does not exist in this clinic’s tree.
The agent picks the closest match by name and reports which folder it used, so a person can move the document if the guess was wrong.
Questions
Every intake pipeline ends with someone typing a patient into the EHR and dragging a PDF into the chart. This is that step, done with proof. The EHR library covers the rest of the read and write 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.