Skip to main content
POST
Live-fetch patients
This is an async operation that fetches up-to-date patient data directly from the EMR system. If the newest data is not critical, consider using the GET /patients endpoint instead for faster results from cached data.

Optional Includes

Use include to opt into additional live-fetch payloads. The API accepts either:
  • a comma-delimited string, for example include: "insurances"
  • an array of strings, for example include: ["insurances"]
Currently supported include values:
  • insurances
  • problems
  • medical_history
  • labs
  • labs.results (orders plus discrete result values; implies labs)
  • referrals (eClinicalWorks; the patient’s incoming, outgoing, and external referrals, each with diagnoses)
  • tasks
  • tasks.notes (tasks plus attatched notes; implies tasks)
  • all_pages (eClinicalWorks; fetch every page of a name or dob search instead of just the first — see below)
tasks.notes implies tasks — you do not need to pass both. Requesting tasks.notes makes an extra live fetch per task to pull its note history, so only request it when you need the notes.

Example Request

Narrowing a Search (eClinicalWorks)

A name or dob search returns a single page of matches (eClinicalWorks caps this at 20). A common name, or a busy date of birth, can easily exceed one page. Add one secondary filter to narrow the results at the source:
  • Narrow a name search with dob (YYYY-MM-DD) or phone (222-333-4444).
  • Narrow a dob search with a name (first_name / last_name).
Only one secondary filter is allowed. The filter is applied by the EMR (it intersects both criteria server-side), so it reduces the result set rather than trimming it after the fact. A name plus a date of birth resolves to the same intersection whichever one you use as search_by. If the first page was still capped, the completion webhook returns has_more: true and a message telling you to narrow further. To fetch every page instead of narrowing, add include: ["all_pages"]. This makes one extra EMR call per page, so prefer a secondary filter when you can.

Response Data

Patient data includes comprehensive information including active medications and associated pharmacies:

Insurances Array

insurances is only returned when include contains insurances. It is currently supported for eClinicalWorks.
The top-level insurance_name and insurance_subscriber_number fields remain convenience fields on the patient object. When present, prefer insurances[] for record-specific insurance details and update targeting.

Guarantors Array

eClinicalWorks only. Each entry represents a guarantor on the patient’s account. Empty array if the lookup fails. The top-level patient_balance and account_balance fields (numbers, in dollars) are returned alongside the guarantors. Both are null if the lookup fails.

Alerts Object

eClinicalWorks only. Contains the patient’s billing and global alerts. May be null if the alerts lookup fails.

Medications Array

Each patient includes an array of active medications with the following fields:

Pharmacies Array

Each patient includes an array of associated pharmacies with the following fields:

Encounters Array

Each patient includes an array of encounters (past and upcoming appointments) returned by the EMR. Field availability varies by EMR and visit type. Telephone encounters (visit_type: "TEL") are enriched with additional fields including caller, message, actions, notes, assigned_to, answered_by, priority, and has_attachment. The top-level last_appointment_date field is derived from the encounters array and reflects the most recent appointment date for the patient.

Tasks Array

ModMed Gastro only. Returned only when include contains tasks (or tasks.notes). Each entry is a task from the patient’s chart. ModMed Gastro models telephone encounters as tasks with category: "Telephone Encounter" — use category to distinguish task types. All task types are returned; filter client-side on category if you only want a subset.

Task Notes Array

Each task’s notes[] (present only with tasks.notes) contains its note history, most recent first:

Webhook Notifications

When the patient fetch is complete, we will send a webhook to your registered endpoint. Here is an example of what the webhook payload will look like:
has_more is true only when a name or dob search was capped and more matches exist (it is absent or false otherwise, and when include: ["all_pages"] fetched everything). message is present only when has_more is true.

Authorizations

client_id
string
header
required
client_secret
string
header
required
access_token
string
header
required

Body

application/json
search_by
enum<string> | null

Search mode: name, dob, phone, or mrn.

Available options:
name,
dob,
phone,
mrn
first_name
string | null

Patient first name. At least one of first_name / last_name is required for name mode.

Example:

"Jane"

last_name
string | null

Patient last name.

Example:

"Doe"

dob
string<date> | null

Date of birth (YYYY-MM-DD). Required for dob mode.

Example:

"1980-01-15"

phone
string | null

Phone (222-333-4444). Required for phone mode.

Example:

"555-123-4567"

mrn
string | null

Medical Record Number. Required for mrn mode.

Example:

"12345"

include
enum<string>

Additional chart sections to enrich, as a comma-separated string or an array of tokens. Accepted tokens depend on the EMR (see x-allowed-values-for-emrs).

Available options:
insurances,
tasks,
tasks.notes,
problems,
medical_history,
labs,
labs.results,
referrals,
documents,
encounters,
encounters.details,
encounters.appointment_notes,
encounters.referral,
episodes,
notes,
assessments,
care_plans,
clinical_notes,
medical,
treatment_plan,
point_of_care,
all_pages
callback_urls

URL(s) to receive the results webhook for this live fetch, in addition to the account webhook.

Example:

Response

Live-fetch request accepted; results delivered by webhook

success
boolean
required
message
string
required
job_id