Valant Cancel / Confirm / Reschedule Workflows

The Situation

Valant had appointment reminders. Patients had no way to respond.

SMS appointment reminders were going out — but they were one-way. Patients who wanted to confirm and cancel only had one option: call the office. Staff were fielding inbound calls for tasks the system could automate. No-shows were happening on appointments where patients had every intention of canceling but no easy way to do it.

At the same time, the patient portal had no self-service appointment management at all. Patients could view their appointments but couldn't act on them. The gap between what patients expected from a modern healthcare experience and what the platform offered was widening.

The assignment: Own the full product definition for two-way SMS reply handling confirm and cancel; portal cancel, request new and reschedule appointment workflows; practice-side configuration, staff-facing queue management, and TCPA compliance — across every appointment type in the system.

The Challenge

Appointments in a behavioral health EMR are not simple events.

This was not a “add a reply button to a text message” problem. The complexity surfaced fast in discovery and only grew from there.

Individual, group, recurring, and group recurring appointment types each require different cancellation and confirmation logic — one workflow does not fit all
Cancellation code rules vary by practice, by timing (within-hours vs. over-hours), and must apply consistently whether the cancel comes via SMS, portal, or app
Staff needed a single operational surface to act on patient-initiated events — not four different places to check
TCPA compliance required full opt-out and re-opt-in handling, audit trails, and suppression logic that couldn't be bolted on at the end
Inbound SMS reply processing required a message handler with fuzzy matching, digit-based reply parsing (1/2/9), and dead-letter routing — the single most critical unresolved technical dependency going into handoff
The reschedule model had to ship as a request queue rather than real-time scheduling without that tradeoff feeling like a limitation to patients

The Approach

Discovery-first. Configuration-led. Queue-anchored.

With scope spanning SMS infrastructure, portal UX, staff workflows, billing logic, and compliance, the approach required clear sequencing — Practice Settings had to be defined first because every patient-facing capability was gated behind it.

01 Discovery

Workflow mapping across all appointment types, SMS variable and template audit, cancellation code rule analysis, TCPA research, Appointment Communication and Reminder Rules scoping; developer-facing workflow presentation documenting end-to-end system behavior across all appointment types and channels

02 Architecture

Full epic definition across 13+ features; sequenced development chain from configuration layer through patient-facing workflows through staff queue; identified inbound SMS handler as critical path dependency

03 Requirements

Grooming-ready user stories and acceptance criteria across Practice Settings, SMS reply processing, template library, Appointments Queue, Queue History, patient portal cancel/reschedule/request new, group/recurring logic, and TCPA compliance

04 Prototype & Handoff

Prototype completed across all major flows; full epic packaged for development handoff with open technical dependencies flagged and scoped for resolution

The configuration layer was designed to give practices full control before any patient-facing feature went live:

Portal Appointment Actions Toggle

Enable/disable self-service at the practice level

Placeholder Categories

Configurable per request type (new request vs. reschedule), visible instantly on the scheduler

Cancellation Code Rules

Within-hours and over-hours primary code logic, synced across all cancel channels and all appointment types

SMS Eligibility Rules

Service-code-level suppression, invalid number handling, carrier block logging

The patient workflows were defined for clarity and low friction:

SMS replies of 1 (confirm), 9 (cancel), or STOP/START processed through a two-way message handler with fuzzy matching and digit-based parsing
Portal cancel flow with optional cancellation reason and courtesy notice configurable by the practice
Reschedule as a request submission model — patient selects a preferred new date/time, staff reviews and acts from the queue
Group and recurring appointments handled per patient, per occurrence — no series-wide side effects

The staff surface was designed around a single queue, not scattered notifications:

Appointments Queue

All patient-initiated events surfaced in one place — new requests, reschedule requests, cancels, confirms, SMS opt-outs

Queue Modals

Editable, with primary code override capability and full logging

Queue History

Permanent, immutable audit trail of every staff action on every row

Remove vs. Delete

Informational rows removable without a Delete permission; actionable rows require deliberate staff action

What Was Delivered

A complete product definition, ready for development.

This project was fully scoped, prototyped, and handed off before development began. What was delivered:

13+ Features with full acceptance criteria

4 Appointment types fully scoped

3 Channels defined end-to-end

A grooming-ready epic spanning 13+ features, every appointment type, and every cancel and confirm channel
Acceptance criteria written for the happy path, edge cases, and failure states — including group recurring cancellations, within-hours code rule application, and TCPA opt-out recovery
A prototype covering all major patient-facing and staff-facing flows
A clear critical path with the inbound SMS handler flagged as the primary technical dependency to resolve before development could begin
Scope boundaries documented — request-only reschedule, no real-time availability, no per-provider overrides — with future phase recommendations included

The foundation was built. The system was ready to be built on top of it.

Reflection

What this project taught me.

“The hardest part of a workflow this wide is holding the logic consistently across every edge case. A group recurring appointment with a cancellation inside the cutoff window, where the patient has previously opted out of SMS and back in — that scenario has to behave correctly, not just the simple one. The only way to get there is writing the acceptance criteria before you write the stories, not after.”

This project reinforced that in a product with many appointment types, many cancel channels, and many configuration options, the acceptance criteria are the product. The features are only as reliable as the conditions that define them. Every AC written in grooming is a scenario that doesn't become a bug in QA.