Elation's Two-Level Status: No-Show Is a Detail

The Appointment object's status is a nested object, not a string. Its status.status field takes one of ten documented values: Scheduled, Confirmed, Checked Out, Cancelled, With Doctor, In Room, Checked In, In Room - Vitals Taken, Not Seen, and Billed.

Read that list again looking for a no-show. It isn't there.

What's there is Not Seen, and alongside it a second field, status.status_detail, which is only valid when the status is Not Seen. That field takes No Show, Left Without Seeing, or Other.

So a missed appointment in Elation is the pair Not Seen / No Show. And critically, Not Seen on its own does not mean the patient no-showed. The pair Not Seen / Left Without Seeing describes a patient who physically came to the clinic, sat in the waiting room, and gave up.

Those two people need completely different messages. One never arrived and may not know they missed anything. The other showed up, waited, and left unhappy, and sending them a chirpy sorry we missed you, let's rebook is going to land badly, because you didn't miss them. They missed you.

That's a distinction most EHRs cannot express and most recall systems therefore don't make. Elation hands it over for free.

status.status_date is read-only and carries when the status was set, which gives you the timing without needing a separate event log. A no-show from this morning and one from six weeks ago justify different outreach, and this field is how you tell them apart.

status.room accepts only rooms that actually exist in the practice, which is a small validation gift.

Elsewhere on the object, mode is an enum of IN_PERSON or VIDEO, worth branching on, because a missed telehealth visit is very often a technology failure rather than a scheduling one, and here's how to test your camera recovers more of those than let's find a new time.

reason is a structured appointment type rather than free text, capped at 50 characters, which means you can group recall by visit type without parsing prose. description and instructions are the free-text fields, each capped at 500.

duration is in minutes and constrained: 5-minute increments, between 1 and 1440. If you're proposing replacement slots programmatically, respect that granularity or your writes get rejected.

And is_blocking is read-only. A blocking entry occupies calendar time without being a patient visit, and any availability calculation that ignores it will confidently offer time that doesn't exist.

The workflow this shape suggests is narrower and better than the usual one. Find appointments where status.status is Not Seen. Split on status.status_detail. For No Show, run the standard recovery sequence: acknowledge, offer specific times, keep it short. For Left Without Seeing, route to a human, because that's a service-recovery conversation and an automated message makes it worse. For Other, do nothing automatic; the value exists precisely because the situation didn't fit a category.

Then filter by status.status_date so the workflow works recent misses rather than re-litigating the past, and check whether the patient has since booked before contacting them.

That last check is the one people skip, and it's the one that causes complaints.

Four of the ten statuses describe a patient who is physically in the building right now: Checked In, In Room, In Room - Vitals Taken, and With Doctor.

Most integrations ignore these, treating anything that isn't scheduled, cancelled, or missed as noise. That's a missed opportunity, because together they form an ordered sequence through a visit, and the gaps between them are measurable.

A patient sitting at Checked In for fifty minutes is a wait-time problem visible in the data before it becomes a complaint. A patient at In Room who never reaches In Room - Vitals Taken is a room that's occupied but not progressing. With Doctor to Checked Out is the actual clinical encounter duration, usually quite different from the duration the appointment was scheduled for.

None of this requires extra instrumentation. The statuses are already being set by staff in the normal course of the day, and status.status_date timestamps each transition. A recall workflow already polling appointments gets the operational view nearly free.

Cancelled is its own top-level status and it should be its own workflow. A cancellation is a freed slot and an intact relationship, because the patient told you. The action is to fill the gap and rebook them, not to run recovery messaging at them.

Conflating cancellations with no-shows produces the worst outreach in healthcare: a message implying someone failed to show up when they in fact called ahead to cancel. Elation's data model makes this trivially avoidable, so there's no excuse for it.

Billed sits at the end of the status list and it's easy to treat as an accounting concern rather than a scheduling one. It's worth one rule in your logic: an appointment that reached Billed completed successfully, so nothing in a recall or recovery workflow should ever touch it.

That sounds obvious until you consider how these systems usually decay. A recall query written as everything that isn't Scheduled or Confirmed quietly includes Billed, Checked Out, and every in-progress status, and starts messaging patients who were seen last week. Enumerate the statuses you want rather than excluding the ones you don't. The list is only ten values and it's documented.

Elation documents a REST API, a FHIR API, and HL7 for lab and imaging results. For scheduling work the REST API is the one. Elation describes the Appointment resource as representing the full schedule for every physician and staff member in a practice.

Endpoints follow a versioned path, with the sandbox at sandbox.elationemr.com/api/2.0/appointments/{id}/, and authentication is OAuth2 with bearer tokens.

One small deprecation to note: telehealth_details was deprecated as of June 2024. Don't build new work on it.

Everything above comes from Elation's public API documentation, not from an Elation integration Recupra runs in production. Field names, enum values, and constraints are quoted from those docs and should be verified against current documentation before you build against them.