AI-Powered Conversational Contact Center for Healthcare Patient Communication

clarus_care · Healthcare · 2026 · source Agentic: yes · promotional bias: med · source-backed · extracted with prompt 0.5.4 (schema v2)

Generated from extraction.json — do not edit by hand. Every claim cites verbatim source evidence; stated means the quote directly asserts the claim, implied means it supports it indirectly.

Problem

Domain: Healthcare patient contact center

Clarus Care needed to move from menu-driven IVR to natural patient conversations that can handle multiple intents, preserve urgent handoff, and scale across healthcare customers.

Constraints:

Healthcare calls can include urgent medical concerns
The contact-center platform has a 99.99% availability requirement
Different healthcare facilities need configurable services without extensive code changes

Architecture

Clarus Care's prototype uses Amazon Connect as the contact-center control plane, Amazon Lex for transcription and session state, Lambda fulfillment for orchestration, and Amazon Bedrock as the multi-model layer for urgency classification, intent extraction, information collection, response generation, scheduling, smart transfer, and analytics. A hierarchical service model keeps customer-specific healthcare workflows configurable while preserving one conversation loop.

Diagram confidence: explicit (topology described by the source).

flowchart LR
  patient-channel-interface["patient-channel-interface"]
  amazon-connect-contact-flow["amazon-connect-contact-flow"]
  amazon-lex-session-state["amazon-lex-session-state"]
  lambda-conversation-orchestrator["lambda-conversation-orchestrator"]
  bedrock-model-router["bedrock-model-router"]
  claude-intent-model["claude-intent-model"]
  nova-information-model["nova-information-model"]
  nova-response-model["nova-response-model"]
  hierarchical-service-model["hierarchical-service-model"]
  scheduling-state-machine["scheduling-state-machine"]
  smart-transfer-router["smart-transfer-router"]
  analytics-pipeline["analytics-pipeline"]
  patient-channel-interface --> amazon-connect-contact-flow
  amazon-connect-contact-flow --> amazon-lex-session-state
  amazon-connect-contact-flow --> smart-transfer-router
  amazon-connect-contact-flow --> analytics-pipeline
  amazon-lex-session-state --> lambda-conversation-orchestrator
  lambda-conversation-orchestrator --> bedrock-model-router
  lambda-conversation-orchestrator --> hierarchical-service-model
  lambda-conversation-orchestrator --> scheduling-state-machine
  lambda-conversation-orchestrator --> smart-transfer-router
  bedrock-model-router --> claude-intent-model
  bedrock-model-router --> nova-information-model
  bedrock-model-router --> nova-response-model
  hierarchical-service-model --> bedrock-model-router
  scheduling-state-machine --> bedrock-model-router
  smart-transfer-router --> amazon-connect-contact-flow

Drag to pan · scroll or use +/− to zoom · reconstructed from the source's described component topology

Components

Component	Role	Interacts with
`patient-channel-interface`	Voice and web chat entry point for patients.	`amazon-connect-contact-flow`
`amazon-connect-contact-flow`	Contact-center platform for voice/chat routing, contact flows, availability, and transfer handling.	`amazon-lex-session-state`, `smart-transfer-router`, `analytics-pipeline`
`amazon-lex-session-state`	Transcription and session-state layer that stores conversation history, collected fields, detected intents, and collected information.	`lambda-conversation-orchestrator`
`lambda-conversation-orchestrator`	Fulfillment logic that classifies urgency, extracts intents, gathers missing fields, generates responses, and delegates scheduling.	`bedrock-model-router`, `hierarchical-service-model`, `scheduling-state-machine`, `smart-transfer-router`
`bedrock-model-router`	Unified Bedrock layer that selects Claude or Nova models by task based on accuracy, cost, and latency.	`claude-intent-model`, `nova-information-model`, `nova-response-model`
`claude-intent-model`	Claude 3.5 Sonnet model used for detailed multi-intent extraction and natural-language understanding.	—
`nova-information-model`	Nova Pro model used for faster structured data extraction while maintaining conversational tone.	—
`nova-response-model`	Nova Lite model used to generate low-latency natural responses from conversation state.	—
`hierarchical-service-model`	Configurable urgency, service, and provider-specific intent hierarchy with dynamically injected instructions.	`bedrock-model-router`
`scheduling-state-machine`	Purpose-built appointment module that manages scheduling states, availability checks, confirmation, and next-step prompts.	`bedrock-model-router`
`smart-transfer-router`	Escalation path that transfers urgent cases or user-requested human handoffs while preserving context.	`amazon-connect-contact-flow`
`analytics-pipeline`	Conversation-log processing and dashboard layer for monitoring system performance and patient interactions.	—

Data flow

A patient enters through voice or web chat. Amazon Connect routes the contact, Lex transcribes and stores conversational state, Lambda invokes Bedrock models to classify urgency and intents, collect missing fields, generate responses, and hand scheduling to a purpose-built state machine. Urgent cases or explicit requests trigger smart transfer, and the conversation logs feed analytics dashboards.

3 supporting quotes

“A patient initiates contact through either a phone call or web chat interface.”article, stated

“Lex handles transcription and maintains conversation state.”article, stated

“fulfillment function processes the conversation using Claude 3.5 Sonnet and Nova models through Bedrock to:”article, stated

Why this architecture

The architecture separates reliable contact-center routing from model-driven understanding: Connect supplies healthcare-grade availability and multi-channel operations, Lex maintains state, Bedrock enables task-specific model selection, and the hierarchical service model makes per-facility customization configurable rather than hardcoded. Scheduling is split out because appointment flow has explicit states and confirmation logic.

“while providing comprehensive contact center capabilities across voice and chat channels.”article, stated

“At the heart of this system is the ability of Bedrock to provide access to multiple foundation models, enabling the team to select the optimal model for each specific task based on accuracy, cost, and latency requirements.”article, stated

Models used: Anthropic Claude 3.5 Sonnet · Amazon Nova Pro · Amazon Nova Lite · Amazon Nova Micro · Amazon Bedrock foundation models

Scale

Clarus Care served more than 16,000 users across over 40 medical specialties.
“Clarus is the fastest growing healthcare call management company, serving over 16,000 users across 40+ specialties.”article, stated
The system was designed around 15 million annual patient calls.
“The company handles 15 million patient calls annually and maintains a 99% client retention rate.”article, stated
The backend processing target was under 3 seconds.
“<3 second latency for backend processing and response to the user”article, stated
The contact-center availability requirement was 99.99% SLA.
“High availability with a 99.99% SLA requirement to facilitate reliable patient communication”article, stated
The intent hierarchy has three primary levels: urgency, service, and provider-specific handling.
“The hierarchical service model organizes intents into three primary levels:”article, stated

Alternatives considered (roads not taken)

Rigid menu-tree IVR

Rejected because: The prototype uses language models to understand multiple intents in one call and queue them for sequential processing instead of forcing patients through one-intent menus.

“Rather than forcing patients through rigid menu trees, the system can leverage powerful language models to understand when a patient mentions both a prescription refill and a billing question”article, stated

Single-model conversation handling

Rejected because: The team routed different tasks to Claude 3.5 Sonnet, Nova Pro, and Nova Lite to balance detailed understanding with low-latency interaction.

“To optimize for both quality and latency, the solution leverages the model selection flexibility of Bedrock for various conversation tasks”article, stated

Hardcoding each provider workflow

Rejected because: The hierarchical service model injects custom instructions into prompts so facilities can be customized without changing core code.

“Each intent in the model includes custom instructions that can be dynamically injected into Bedrock prompts, allowing for highly configurable behavior without code changes.”article, stated

Patterns

`model-routing` (contact-center-nlu)

Clarus selects Claude 3.5 Sonnet or Nova models depending on the task's accuracy, cost, and latency needs.

“the ability of Bedrock to provide access to multiple foundation models, enabling the team to select the optimal model for each specific task based on accuracy, cost, and latency requirements.”article, stated

`confidence-thresholding` (urgent-routing)

A focused Bedrock prompt classifies initial patient statements as urgent or non-urgent to guide routing.

“The system uses a focused prompt that analyzes the patient’s initial statement against a predefined list of urgent intent categories, returning either “urgent” or “non_urgent””article, stated

`prompt-chaining` (multi-intent-dialogue)

The system extracts intents, queues them, and loops through layered model calls to collect required information naturally.

“Once intents are identified, they are added to a processing queue. The system then works through each intent sequentially, making additional model calls in multiple layers”article, stated

`agent-memory` (conversation-state)

Lex session attributes store collected information, history, detected intents, and context across Bedrock invocations.

“These attributes serve as the conversation’s memory, storing everything from the user’s collected information and conversation history to detected intents and collected information.”article, stated

`observability-tracing` (contact-center-analytics)

Conversation logs flow into an analytics pipeline and dashboard for system performance and patient-interaction insights.

“The team also built an analytics pipeline that processes conversation logs to provide valuable insights into system performance and patient interactions.”article, stated

Tradeoffs

Which model to use for each conversational task.

Chose Claude for detailed intent extraction and Nova Pro for faster structured data collection over one model for all contact-center tasks.

Rationale: Different steps need different balances of language understanding, latency, cost, and conversational quality.

“uses Anthropic’s Claude 3.5 Sonnet through Bedrock for detailed analysis that can identify multiple intents”article, stated

“employs a faster model, Amazon Nova Pro, through Bedrock for structured data extraction while maintaining conversational tone.”article, stated

How to implement appointment scheduling.

Chose a separate purpose-built state-machine module over handling scheduling entirely inside the main intent handler.

Rationale: Scheduling has explicit states, next steps, confirmation branches, and availability rules that benefit from a controlled module.

“The scheduling component of the solution is handled in a separate, purpose-built module.”article, stated

Gotchas (what bit them)

Traditional IVR cannot handle natural multi-intent healthcare calls well.

Root cause: Rigid menus force patients to navigate one option at a time and leave messages for later processing.

Resolution: The new system detects multiple intents in a single interaction and processes them sequentially.

“Previously, patients navigated through rigid menu options to leave messages, which are then transcribed and processed.”article, stated

Customer-specific contact flows can become hard to reuse.

Root cause: Healthcare practices have different service models, required fields, and routing needs.

Resolution: Clarus designed an interchangeable service model and dynamic prompt injection so customization requires minimal code/config changes.

“Formatting the contact center call flow and service model in a way that is interchangeable for different customers, with minimal code and configuration changes”article, stated

Patient and provider names are difficult to transcribe and match.

Root cause: Voice interfaces must handle name variants such as Dr. Smith, Dr. Jennifer Smith, or Jenny Smith.

Resolution: The solution matches provider names mentioned by patients to the correct provider record rather than relying on rigid extension/name matching.

“The solution automatically matches provider names mentioned by patients to the correct provider in the system.”article, stated

Evaluation

Clarus evaluates against contact-center success criteria, model latency/accuracy, urgent routing, availability, transcript/call analytics, and future Bedrock automated/human evaluations.

Metrics: 99.99% SLA · latency · accuracy · call quality · patient interaction metrics · multi-intent resolution

“High availability with a 99.99% SLA requirement to facilitate reliable patient communication”article, stated

“Bedrock Evaluations for automated and human-based conversation evaluation”article, stated

Outcomes

The prototype supports natural-language voice and web-chat interfaces.
It can handle multiple patient intents in a single conversation.
It includes smart transfer for urgent cases or explicit patient requests.
It creates a scalable foundation for Clarus's growing healthcare customer base.

Clarus serves more than 16,000 users across 40-plus specialties and handles 15 million patient calls annually.

“serving over 16,000 users across 40+ specialties. The company handles 15 million patient calls annually and maintains a 99% client retention rate.”article, stated

“The transition from a traditional menu-driven IVR to an AI-powered conversational interface enables Clarus to help enhance patient experience”article, stated