Automating Appointment Confirmations in Healthie

A Healthie appointment carries a boolean called confirmed. True means someone confirmed. False means nobody has. There is no third state for “we asked and they haven't answered”, no timestamp for when confirmation happened, and no record of who did it, whether that was the patient, the front desk, or an integration.

So confirmed: false is genuinely ambiguous. It covers the appointment booked four minutes ago that nobody has contacted yet, and the one you've texted three times with no reply. Those are opposite situations and the EHR represents them identically.

If your reminder logic reads confirmed and nothing else, it will treat both the same way. That's the failure mode: patients who booked this morning get a “please confirm” text intended for someone who has been ignoring you for a week.

The fix isn't in Healthie. It's keeping your own record of what you've sent and when, and using confirmed only as the stop condition.

Appointments also carry pm_status, a string holding the appointment's own state, where a cancellation shows up as "Cancelled". The two fields are completely independent, which is the same property that makes filling a cancelled slot in Healthie its own piece of work.

An appointment can be confirmed: true and pm_status: "Cancelled" at the same time, and the API will not complain. That combination is not a bug. It's what happens when a patient confirms on Monday and cancels on Wednesday. The confirmation was real, and nothing clears it.

Any reminder job that filters on confirmed alone will eventually text somebody about a visit that no longer exists. Read both fields, always.

The hard part of a confirmation flow isn't sending the message. It's knowing when to send it, and when to stop.

Healthie supports webhooks. When an appointment changes, it POSTs to your endpoint, signed with a secret you configure. That gives you the events: booked, changed, cancelled.

What webhooks don't give you is a timer. Healthie will tell you an appointment was created; it won't tell you that it's now 24 hours out and nobody has confirmed. That scheduling lives on your side, and it's the part people underestimate.

Concretely, you need to hold:

• When each reminder in the sequence is due, per appointment.
• What has already been sent, so a retry doesn't duplicate.
• A cancellation of all pending sends when confirmed flips or pm_status changes.

The third one is where things break in practice. If a patient confirms by replying to the first text, the second and third are already scheduled. Cancelling them requires that your scheduler can find and remove them by appointment, not just fire them blindly.

A reminder that arrives at 3am does more damage than no reminder at all, and it's an easy mistake to make when the appointment time and the patient's local time are stored separately.

Healthie appointments carry a start time. The patient's timezone is a property of the patient record, not the appointment. A practice with patients in three timezones, which is routine for telehealth, has appointments whose “9am” means three different moments depending on who's attending.

Send-time logic has to resolve the patient's timezone, not the practice's. This is the single most common cause of complaints about automated reminders, and it has nothing to do with the messaging channel.

When a patient replies to confirm, you update the appointment. Healthie's update path takes the appointment's field set, not a partial patch, which means you need the appointment's current shape before you can change one flag on it.

The fields involved include appointment_type_id, contact_type, appointment_location_id, location, room_id, external_videochat_url, insurance_billing_enabled, is_blocker and notes. Read the appointment, flip confirmed, write it back with everything else intact.

Miss one and you'll silently clear it. The most damaging omission is external_videochat_url. Drop it while confirming a telehealth visit and the patient now has a confirmed appointment with no video link, which they discover at the appointment.

Confirmation flows work off a horizon, everything in the next 48 hours say, and that lookup is the part that scales badly.

Healthie's availability query, availableSlotsForRange, is scoped to one provider and one appointment type per call. Booked appointments are read per patient. Neither gives you “every appointment tomorrow across the practice” in a single request, which is exactly the shape a reminder job wants.

In practice you keep your own index: mirror appointments locally as webhooks arrive, and run the reminder sweep against your copy rather than against Healthie. The EHR stays the source of truth, but you stop asking it a question it isn't built to answer quickly.

That local mirror needs to survive a missed webhook. Endpoints go down, deploys drop requests, and an appointment your copy never heard about is an appointment nobody gets reminded of. A periodic reconciliation against Healthie, even a slow nightly one, is what keeps a silent gap from becoming a pattern of missed reminders.

• API access. Per Healthie's pricing page, API access is an Enterprise add-on. The price isn't published, so it's negotiated per account.
• An API key. Generated from Settings once access is enabled.
• A webhook endpoint and its signing secret. So appointment changes arrive as events.
• A scheduler you control. This is the piece that isn't in Healthie and can't be.

Things worth knowing before you commit:

• confirmed has no timestamp. You cannot ask Healthie when an appointment was confirmed, or reconstruct it later. If that matters for your reporting, record it yourself at the moment you write the flag.
• There's no field distinguishing a patient confirmation from a staff one. Both set the same boolean. Confirmation rate as a metric will be inflated by anything your front desk marks manually.
• Healthie doesn't manage message delivery. Bounces, opt-outs and carrier failures are yours to track, and an opt-out has to stop the sequence without touching the appointment.
• A confirmed appointment is not a kept appointment. Confirmation reduces no-shows; it doesn't eliminate them, and confirmed: true should never be treated as attendance.