Scheduling

EHR Schedule Retrieval and Appointment Read/Write Automation

See a provider’s real availability in the EHRs your software can’t reach, and put appointments onto those calendars, without an integration project. A provider and a date range go in; every open slot comes back grouped by day, in the practice’s own timezone, ready for your scheduling queue, call list, or voice agent.

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

Two jobs, one build. Seeing the schedule: a browser agent signs in to the EHR, opens the provider’s calendar, and walks the requested date range, returning every open slot in a form your scheduling service, voice agent, or call list can use directly. Booking against it: the agent verifies a requested slot against the live calendar, creates the appointment for the right patient, and confirms it landed, or reports the slot as taken rather than overwriting anything.

Each EHR is built as its own configured agent, the same way the payer enrollment forms and state-board checks are: the same primitive runs in production against ambulatory EHRs such as eClinicalWorks, and extends system by system to secondary and hospital EHRs.

How Asteroid runs this workflow

Schedule reads and writes in EHRs your software can't reach

An appointment read, create, reschedule, or cancel request enters the workflow, Asteroid works the EHR calendar the way a scheduler would and applies only the approved change, and the confirmed result comes back with audit evidence, while mismatched patients and conflicting changes route to a person instead of the calendar.

eClinicalWorksAmbulatory EHRs

How it actually runs

  1. 01The agent signs in to the EHR and opens the provider’s schedule view.
  2. 02It walks the calendar across the requested range, week by week, identifying open times inside the provider’s working hours that aren’t booked or blocked.
  3. 03Where the EHR exposes an internal API to its own logged-in session, the agent uses that instead of clicking through the calendar, which is faster and more reliable. Where it doesn’t, it reads the calendar grid itself.
  4. 04In some EHRs, booked appointments are drawn as visual overlays that the page’s own data never exposes: a DOM scraper reads that calendar as wide open. The agent reads the grid the way a person does, so a booked slot is never reported as free.
  5. 05It returns the availability as structured JSON: open start times grouped by date, in the practice’s timezone, with a coverage report naming any part of the range it could not read.

Zero open slots in the range is a normal, successful result: an empty schedule, not an error. And a week that wouldn’t load is reported as unread, never silently skipped, because a gap you know about is schedulable and a gap you don’t is a double-booking waiting to happen.

An appointment read, create, reschedule, or cancel request arrives from your scheduling service, call list, or voice agent

  1. Delivered to your scheduling system

    Current appointment data as structured JSON, or a confirmed schedule change with its timestamp and a per-run record of every appointment read or written.

Patient mismatch or conflicting change: The run stops with the calendar state and candidates it saw (a locked schedule, a conflicting change, or a scheduling rule the build doesn't cover), and a person resolves it once with that evidence in hand.

Looking at a calendar is harmless. Changing one is guarded.

The agent verifies the patient’s identity against the chart before touching anything; a wrong or ambiguous match stops the run rather than booking on the wrong record. It checks the requested slot against the live calendar first, and a taken slot is reported back, not overwritten. And the transition into writing carries a human confirmation gate, so nothing lands on a provider’s calendar unattended unless you deliberately remove that gate.

At scale

One provider’s week, or every calendar you operate on

A single run answers one provider-range question. At scale, retrieval runs nightly across every provider and location you manage, keeping downstream systems synced without a person re-keying calendars between screens, and write runs execute as bookings arrive. The output is built to be consumed by software: this is the workflow that lets a voice agent that captured the appointment request actually finish the job inside the EHR.

Retrieval and read/write are part of the scheduling workflow library, alongside appointment booking and marketplace profile sync.

Human in the loop

What escalates to a human

Schedule data is patient data: runs execute on HIPAA-compliant, SOC 2 Type II infrastructure with a per-run log of every appointment read or written. Full posture on the security page.

A part of the range that wouldn’t load.

Named in the coverage report; the rest of the export still completes.

A requested slot that’s taken.

Reported as unavailable with the calendar as evidence; nothing is moved or overwritten.

A patient who can’t be confidently identified.

The write stops before touching the calendar; wrong-chart writes are the one failure this workflow refuses to risk.

The write gate itself.

Appointment creation pauses for approval by default.

Questions

Frequently asked questions

Each EHR is built as its own configured agent. The primitive runs in production against ambulatory EHRs such as eClinicalWorks and extends system by system. Configuration covers your providers and locations, the date ranges retrieval walks, how working hours and blocked time are read from your calendar setup, where the JSON output lands, and whether the human gate on writes stays on (it's on by default). What never changes: retrieval stays strictly read-only, and writes verify patient and slot first. Your schedulers see the same calendars they always did.

Retrieval and read/write are one workflow in the scheduling workflow library. Every calendar synced by hand is staff time spent re-keying between screens, every day, indefinitely.

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.