EHR Extraction & Write-back

Create Patient Records and File Documents in the EHR

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.

See it run on your systems.

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

Scope this workflow See how it works ↓

Overview

What this workflow does

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

From an inbound PDF to a verified document in the right chart

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

1. Sign in to the EHR under credentials held in an agent profile, handling any verification step.
2. Find the patient by name, date of birth, and sex. Verify the account number when supplied. This step is read-only, and an ambiguous match stops the run.
3. If the patient exists, update only the fields provided. If not, create the chart with the demographics, insurance, and referring provider given. Report the account number and rendering provider.
4. Upload every attached PDF into the target folder or under the label the document type implies. One run files into one folder.
5. Mark each document Reviewed when asked, then verify against the EHR’s document tree that the state persisted. Report folder, files, uploaded count, and verified count.
6. Message the named staff member with the document when a signature is required.

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.

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.

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, created, uploaded, and verified.

Frequently asked questions

Which EHRs does this run on today, and how is a new one added?
Patient creation and document filing run in production on a widely used ambulatory EHR, and the fused find-or-create-and-file version runs on a practice-management system.

How does the agent decide whether to create a patient or update one?
It searches by name, date of birth, and sex first, read-only. One match means update, and only the fields you supplied are written; empty inputs leave the chart unchanged. No match means create, with the demographics, insurance, and referring provider provided. More than one match stops the run with the candidates listed.

What does ‘verified’ mean in the output?
After uploading and ticking Reviewed, the agent re-reads the EHR’s own document tree and counts the documents that show as Reviewed there. That count is the reviewed_count in the output. If it does not equal documents_uploaded, the run reports a failure with both numbers.

Sample Outputs

Patient Creation

{
  "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."
}

Document Filing

{
  "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."
}