Clinical Note and Document Push into Ambulatory EHRs

File clinical notes and documents into the right patient’s chart in the EHR, with the patient verified before anything is written, every upload confirmed against the EHR’s own document tree, and a find-or-create step for patients who aren’t in the system yet. The write-back half that every AI scribe and intake pipeline is missing.

Overview

What this workflow does

Plenty of tools produce clinical documents; almost none can put them where they belong, because ambulatory EHRs don’t offer a write API for it. This workflow closes that gap with a browser agent. It finds the patient by name and date of birth, verifying the account number when provided, uploads the attached documents into the chart’s target folder, and, when asked to, marks each one Reviewed, then verifies that the Reviewed state actually persisted in the EHR’s document tree rather than trusting the on-screen checkbox, which can silently fail. It refuses to claim success unless the verified count matches the uploaded count. It runs in production today in a widely used ambulatory EHR.

When the patient doesn’t exist yet, a companion find-or-create workflow makes the chart first: it matches by name, date of birth, and sex, updates only the fields you provided if the patient exists, and creates the chart behind its own human gate if not, returning the account number either way. Empty inputs never overwrite existing chart values, and nothing is ever invented to fill a field.

A finalized note, filed in the right chart and proven there

A finalized note arrives approved for filing, Asteroid matches the patient in the EHR, files the document unaltered into the target folder, and verifies it against the EHR's own document tree, with any match it isn't certain of stopped and handed to staff, because a wrong-chart filing is the one error this workflow refuses to make.

How it actually runs

1. Sign in to the EHR with credentials from an agent profile.
2. Find the patient by name and date of birth, verifying the account number when provided. A wrong or ambiguous match stops the run; a missing patient reports patient-not-found, ready to chain into chart creation.
3. Confirm with a human before anything is written to the chart.
4. Upload each attached document into the target folder, and mark it Reviewed when configured to.
5. Verify the Reviewed state against the EHR’s document tree, and report the folder, files, upload count, and verified-reviewed count.

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.

{
  "folder": "Correspondence",
  "files": [
    "visit_note_2026-07-15.pdf"
  ],
  "documents_uploaded": 1,
  "reviewed_count": 1,
  "summary": "1 document filed; Reviewed state verified in the tree."
}

What escalates to a human

Chart writes are PHI operations end to end: HIPAA-compliant infrastructure, SOC 2 Type II, a BAA, and an audit trail that records every document filed and every verification performed. Full posture on the security page.

Every chart write.

A human confirms after the patient is found and before anything is uploaded.

Creating a new chart.

Find-or-create has a second gate specifically on creation; new patient records don’t appear without sign-off.

A wrong or ambiguous patient.

Identity mismatches stop the run; the agent never touches a chart it isn’t certain about.

A verification miss.

If the reviewed count doesn’t match, the run reports the discrepancy instead of success.

Frequently asked questions

Our filing rules for folders, Reviewed status, and new patients are our own. What configures?

Configuration covers your target folders in the chart's document tree, whether each document gets marked Reviewed, which identity fields you supply, and whether the find-or-create path for new patients is enabled with its own creation gate. The verification discipline is fixed: patient matched before anything is written, every upload confirmed against the EHR's document tree, and success refused unless the verified count matches the uploaded count. Your scribes and staff keep producing documents exactly as they do now; only the filing changes hands.

What access is required, given our EHR has no document API?

That's the point of the build: ambulatory EHRs don't offer a write API for document filing, so the agent signs in with credentials from an agent profile and works the chart the way a medical assistant would. It runs in production today in a widely used ambulatory EHR. Documents arrive from your scribe or documentation pipeline; results come back as structured JSON naming the folder, files, upload count, and verified-reviewed count. Credentials are scoped to filing, rotatable and revocable, and every document filed and verification performed is recorded on HIPAA-compliant, SOC 2 Type II infrastructure.

What stops a filing run, and how does the handoff work?

A wrong or ambiguous patient match stops the run. The agent never touches a chart it isn't certain about, and never fabricates identity data to force a match. A missing patient reports patient-not-found, structured to chain into find-or-create behind its own human gate. A verification miss (the Reviewed count in the document tree not matching the uploads) is reported as a discrepancy, not success. Each stop lands with a person alongside what the agent saw.