Portfolio Systems Artifact · Appointment Management IVA

Appointment Management IVA Operating Framework

A condensed portfolio version of an enterprise appointment-management playbook: patient-state logic, intent routing, PMS/API orchestration, retry controls, escalation design, configurable rules, and KPI instrumentation.

Patient State EngineHMIHY + AuthIntent RoutingPMS/API WritebackEscalation Controls

What This Framework Proves

This is not a call script. It is an operating model for production-grade healthcare IVA delivery.

Product Thinking

Turns messy appointment workflows into clean intent paths, edge-case rules, and measurable success criteria.

Systems Thinking

Separates IVR, AI, authentication, PMS/API actions, policy rules, audit logging, and escalation handoff.

Implementation Judgment

Defines what the AI can do, when it must stop, what lives in config, and what engineering must validate before launch.

Operating Principles

The full internal playbook uses 10 design principles. This portfolio version groups them into five senior-level principles.

Mirror the Best Human Rep

  • Natural, concise, helpful.
  • No robotic menus.
  • One clear next step.

Separate IVR from AI

  • Disclosures happen once.
  • Language and routing resolve before the AI speaks.
  • AI focuses on workflow completion.

Verify Before Disclosure

  • ANI + DOB validation.
  • Silent validation.
  • No readback of stored PHI.

Put Rules in Config

  • Office hours.
  • Cancellation windows.
  • Fees, locations, languages, routing destinations.

Instrument from Day One

  • Track containment.
  • Track retries and pivots.
  • Track transfers and API failures.

Design for the Break

Every flow defines happy path, edge case, and escalation before launch, because production is where goblins bring clipboards.

Patient State Engine

Before the AI assistant speaks, ANI lookup places the caller into a state that determines greeting, authentication, and available actions.

A

Known Caller · Upcoming Appointment

ANI matches an existing patient and appointment exists. IVA can personalize the opening, then verify DOB before sharing appointment details.

B

Known Caller · No Upcoming Appointment

ANI matches an existing patient but no appointment is on file. IVA uses neutral greeting, verifies DOB, then routes to scheduling or FAQ.

C

Unknown ANI · Treat as New

No match or lookup timeout. IVA proceeds neutrally, captures phone/DOB or new-patient path, and avoids exposing system failure.

Core Flow Architecture

The compact version: one linear control spine with branchable intent paths.

1 · IVR Layer

Disclosure, language selection, emergency message, and silent ANI lookup occur before AI pickup.

2 · HMIHY + Auth

Greeting varies by state. DOB is collected as second factor before patient-specific details.

3 · Intent Router

Routes schedule, reschedule, confirm, cancel, FAQ, after-hours, urgent, or live-agent request.

4 · PMS/API Action

Reads availability or appointment details, then writes booking, confirmation, cancellation, or reschedule only after confirmation.

5 · Close / Escalate

Logs outcome, reads safe confirmation, asks HEMIHY, or passes context to staff.

Intent Inventory

Supported intents are intentionally constrained. Anything outside the inventory pivots or transfers.

IntentWho Can Use ItPrimary System ActionEscalation Trigger
ScheduleExisting or new patientSearch availability → hold/offer slot → book after confirmationNo availability, policy mismatch, API/writeback failure
RescheduleKnown patient with appointmentHold old appointment → find new slot → atomic swap after confirmationCancellation window, fee disclosure, no alternate slot
ConfirmKnown patient with appointmentVerify → read safe appointment summary → confirm statusNo appointment found, multiple appointments, API failure
CancelKnown patient with appointmentVerify → disclose policy if needed → cancel only after confirmationRestricted window, procedure type, patient frustration
FAQAny callerRead public practice info onlyClinical, billing, insurance-specific, or account-specific question
After-HoursAny caller outside open hoursOffer self-service if safe; route voicemail/call center/emergency destinations by configUrgent/emergency, human request, unsupported workflow

API / PMS Operation Map

Generic PMS operation model designed to map cleanly to Denticon, Dentrix Ascend, OpenDental, ModMed, Axium, or another scheduling source of truth.

Workflow StepSample OperationData UsedGuardrail
Patient matchGET/patients/searchANI, DOB, last name, phone, patient IDNo patient-specific disclosure before verified match.
Appointment lookupGET/appointmentsPatient ID, location, date rangeOnly read back after identity confirmed.
Availability searchGET/appointments/availabilityLocation, provider, appointment type, preferenceOnly present returned slots. Never invent availability.
Book appointmentPOST/appointmentsPatient ID, slot ID, provider, location, appointment typeWriteback only after explicit confirmation.
ReschedulePATCH/appointments/{appointmentId}Old appt ID, new slot, reason, patient IDAtomic swap. Do not cancel old slot before new slot confirms.
CancelPOST/appointments/{appointmentId}/cancelAppointment ID, reason, policy flagApply cancellation window and fee rules before writeback.
AuditPOST/interaction-eventsIntent, state, retries, API status, outcome, transfer reasonMinimize PHI and preserve operational context.

Universal Retry + Escalation Rules

A single source of truth prevents each flow from inventing its own retry logic.

TriggerMax AttemptsFinal ActionKPI Event
DOB mismatch2 totalTransfer to staff for verificationauth_failed
Intent unclear / silence2 repromptsTransfer with captured utterance/contextintent_unclear
Slot declined3 rounds of 2 slotsTransfer or offer callbackslot_round_exhausted
PMS write failure1 retry, then alternateDo not confirm; transfer with selected slot contextpms_write_failed
Out-of-scope intent0Immediate transferout_of_scope
Hostile / distressed caller1 de-escalationTransfer to humanbehavioral_transfer

Configuration Model

The system is built to avoid prompt spaghetti. Business rules live in tenant configuration.

Tenant Config

  • AGENT_NAME
  • PRACTICE_LOCATIONS
  • SPANISH_PATH_ENABLED
  • AFTER_HOURS_DESTINATIONS
  • SUPPORTED_INTENTS

Workflow Rules

  • AUTH_MAX_ATTEMPTS
  • SLOT_ROUNDS_MAX
  • MIN_BOOKING_DAYS
  • NOTICE_RULE_HOURS
  • PMS_WRITE_RETRY
Product Principle

If a rule changes by client, location, office hour, language, or appointment type, it belongs in config, not hard-coded prompt language.

KPI Instrumentation

This framework is designed to be measurable from day one, not retrofitted after launch.

Product KPIs

  • Task completion rate.
  • Intent accuracy.
  • Containment by intent.
  • Repeat caller rate.

Operational KPIs

  • Transfer rate.
  • Retry rate.
  • Slot acceptance rate.
  • PMS writeback success.

Quality Signals

  • Auth failures.
  • API failures.
  • Policy exceptions.
  • Escalation reasons.

Sample Interaction Slice

A tiny slice of the full framework showing how scripting, verification, API logic, and guardrails combine.

StepIVA BehaviorSystem BehaviorControl
Greeting“Hi, this is [Agent Name]. How can I help you today?”State A/B/C already resolved from ANI lookup.No PHI disclosed.
IntentCaller asks to reschedule.Intent router checks whether upcoming appointment exists.If no appointment, pivot to schedule.
Auth“Can I get the patient’s date of birth?”DOB silently validates against PMS/EHR.2 attempts max.
Availability“I found two openings…”Availability returned from PMS/API.Only source-system slots shown.
Writeback“Would you like me to move your appointment to Tuesday at 10?”Appointment update sent after explicit confirmation.Atomic swap; old appt held until new writeback succeeds.
Close“You’re all set. Is there anything else I can help with?”Outcome and KPI event logged.Audit trail complete.