Referral Intake

Detect and Extract New Referrals from Referral Networks

Watch the referral networks and hospital portals your referrals arrive through, pick up every new referral addressed to your providers, download its documents, and deliver metadata plus files to your intake endpoint. Then mark it received in the network, and request records on the ones that arrived empty.

Go-live in as little as 30 minBrowser agentCustomer portal login

See it run on your systems.

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

Building internally? Read the docs →

Overview

What this workflow does

Post-acute and specialty providers receive referrals through care-coordination networks and through the community-provider portals that hospitals host, and someone watches those inboxes. This agent watches instead. It signs in, scans the incoming-referral queue for referrals in New status addressed to your target providers (or all providers, with an exclusion list that always wins), and processes each one without opening anything outside scope.

For each qualifying referral it opens the detail, extracts the metadata (patient, referring provider, insurance, authorization number and window, received date), downloads every attached document, and delivers one multipart request to your intake webhook: a metadata JSON part plus one part per file. On a successful delivery it changes the referral’s status from New to Received in the same run. A referral that arrived with no documents is not delivered; the agent posts a one-time note to the referring provider requesting records and leaves it in New so a later run picks it up.

Referral discovery and extraction on hospital-hosted referral portals, where each health system runs its own instance and new-or-updated referrals are polled from a lookback watermark, are in the catalogue pipeline on the same shape.

How Asteroid runs this workflow

From a referral in the network to a structured intake event

On a schedule, Asteroid scans the network’s incoming queue for new referrals to your providers, downloads each one’s documents, delivers metadata and files to your intake endpoint, marks the referral received, and requests records on any that arrived without documents, and a delivery your endpoint rejects leaves the referral untouched for a retry.

Care-coordination referral networksHospital-hosted referral portals

How it actually runs

  1. 01Sign in to the referral network under credentials held in an agent profile and dismiss any welcome or maintenance overlays.
  2. 02Open the incoming-referrals queue and collect the IDs of every referral in New status addressed to your target providers or to any provider. Excluded providers are never opened. Nothing is modified in this step.
  3. 03For each referral: open the detail, verify the receiving provider is in scope, extract metadata, and download all attached files.
  4. 04With one or more files: deliver metadata and files to your intake webhook in one multipart request. On a 2xx response, set the referral’s status to Received.
  5. 05With no files: post the standard records-request note to the referring provider and leave the referral in New.
  6. 06Report processed, received, records-requested, and failed referral IDs. A run that finds nothing new is a successful run.

A scheduled run, or a new referral appearing in the network’s incoming queue

  1. One intake event per referral, with documents, in your pipeline

    Each referral arrives at your webhook as structured metadata plus files, and the run reports counts: processed, marked received, records requested, and any delivery that failed, by referral ID.

A referral with no documents: Not delivered. The agent posts a one-time note to the referring provider requesting records and leaves the referral in New. A later run picks it up once documents arrive. Your intake never receives an empty referral.

Closing the loop

What lands back in your system

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.

referrals processed · json
{
"processed_count": 4,
"received_count": 4,
"docs_requested_count": 1,
"docs_requested_ids": "R-1187",
"failed_ids": "",
"summary": "4 referrals delivered and marked Received; records requested on 1 referral with no documents."
}
webhook metadata part · json
{
"referral_id": "R-1184",
"patient": { "name": "SAMPLE, JANE", "dob": "1958-03-02" },
"referring_provider": "EXAMPLE HOSPITAL CASE MANAGEMENT",
"receiving_provider": "Dr. Sample Provider",
"insurance": "Medicare A",
"authorization_number": "AUTH-0000",
"authorization_window": "2026-08-10 to 2026-09-09",
"referral_received_date": "2026-08-14T15:22:00Z",
"files": 3
}
Delivered toYour APIWebhooksGoogle SheetsSlackEmailAll integrations →

The agent makes two writes

The agent can change a referral’s status to Received and post one standard records-request note. Those are its only writes to the network. Declining, cancelling, deleting, or forwarding a referral is blocked in the agent itself, not just discouraged in its instructions. Referral metadata and documents are PHI, and they go to exactly one place: the intake endpoint you configure. Nothing is logged or copied elsewhere.

At scale

The front of the intake loop

The care-coordination network agent runs today as a template, cloned from a production intake deployment. Hospital-hosted referral portal discovery and extraction are in the catalogue pipeline. Downstream of your webhook, patient creation and document filing puts the referral into the EHR, and inbound referral capture creates and works the referral record. One production intake deployment processes over 16,000 referrals a month through this loop. The rest of the category is in the referral-intake library; bring your referral sources to scoping.

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 read, downloaded, delivered, and marked. Posture in full on the security page.

A referral with no documents.

Not delivered. A records-request note goes to the referring provider and the referral stays in New for a later run.

A delivery your endpoint rejects.

The referral stays in New, its ID is reported under failed, and nothing is marked received. Retry is a re-run.

A referral for an excluded provider.

Never opened, never included, never modified. Exclusion wins over targeting.

A login or page failure.

Reported with the reason and how many referrals were processed before the failure. Login is retried once, not repeatedly.

Questions

Frequently asked questions

The care-coordination network agent runs today. Hospital-hosted referral portals, where each health system runs its own branded instance for community and post-acute providers, are in the pipeline on the same shape: poll for referrals new or updated since a watermark, then extract each one in full. Each source is its own agent build. Bring the source and a login and it is scoped against your instance; the webhook contract on the output side stays the same.

The referral-intake library covers the full inbound path, from network inbox to booked appointment.

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.