CareConnect: Healthcare Logistics Agent

• CareConnect is a healthcare logistics agent that automates appointment scheduling using deterministic safety guardrails and schema-constrained tools.
• The system architecture integrates an LLM-based orchestrator with retrieval-augmented generation and domain-specific tool suites for reliable transaction handling.
• Evaluations report a 91.8% task completion rate and a 23× cost reduction compared to human receptionists, highlighting both effectiveness and efficiency.

Searching arXiv for the primary CareConnect paper and closely related systems to ground the article in current literature. CareConnect is a healthcare operations agent defined as a “safety-first conversational agent for healthcare logistics automation” that automates administrative workflows rather than clinical care. It is designed for appointment booking, modification, cancellation, and facility information retrieval, and it is explicitly not a medical assistant, diagnostic tool, or treatment recommender. The system combines LLM function calling, retrieval-augmented generation, and deterministic safety guardrails to handle language-heavy but structurally bounded scheduling tasks, a setting the paper presents as especially suitable for LLM-based automation because the conversations are natural-language rich while the underlying actions remain transactional and schema-constrained (Hasan et al., 6 Jul 2026).

1. Scope and operational rationale

CareConnect addresses healthcare appointment scheduling as an operational bottleneck caused by manual coordination, fragmented legacy systems, and high administrative overhead. These inefficiencies reduce provider availability and delay patient access to care. The paper also cites that physicians spend an average of 16.6 hours per week on non-clinical tasks, positioning scheduling and related coordination as a repetitive, structured, high-volume process suitable for automation (Hasan et al., 6 Jul 2026).

The system’s scope is deliberately narrow. Allowed requests are healthcare logistics and administrative operations, including appointment booking, modification, cancellation, provider lookup, facility questions, and laboratory preparation guidance. Refused requests are requests for medical advice, treatment recommendations, dosage guidance, diagnosis, symptom interpretation, or emergency triage beyond escalation. This scoping is central to the system thesis: scheduling conversations are often messy in natural form—relative dates, provider preferences, department constraints, changing intentions, and multi-step revisions—but the underlying operations can still be mapped to explicit backend tools with verifiable state transitions (Hasan et al., 6 Jul 2026).

This design choice gives CareConnect a distinct operational identity. The paper repeatedly frames it as a healthcare logistics agent rather than a clinical AI system. That distinction is not cosmetic: it determines the permissible intent space, the tool schemas, the safety policy, and the evaluation criteria. A plausible implication is that the reported reliability depends substantially on this bounded problem formulation rather than on open-ended medical reasoning.

2. Agent architecture and execution model

Architecturally, CareConnect has four main components: an LLM-based agent orchestrator, a deterministic safety filter, a retrieval-augmented generation subsystem, and a domain-specific tool suite. The orchestrator, also called the Agent Router, uses OpenAI’s GPT-4o with native function calling. It maintains conversation history, reasons over user requests, selects tools, and manages multi-turn state (Hasan et al., 6 Jul 2026).

The execution loop is structured and bounded. The system prompt injects contextual metadata such as current date and time, authenticated user identity, scope constraints, and tool-usage rules. The incoming request then passes through a pre-LLM safety filtering stage. Only if the request is judged in scope does the LLM run. The LLM reasons over the conversation and available tool schemas and may emit function calls; tool invocations are validated, executed externally, and their outputs are appended back into context. This loop repeats for up to ten cycles until the model returns a final natural-language answer or reaches the iteration cap. The paper states that the cap exists to prevent uncontrolled reasoning or infinite tool-use loops, but it does not provide formal pseudocode or a finite-state machine (Hasan et al., 6 Jul 2026).

The implementation stack is concrete. The backend uses Python with FastAPI, SQLAlchemy for ORM, and Pydantic for schema validation. The frontend uses React, TypeScript, and Material-UI. Deployment uses Docker Compose with three containerized services: backend, frontend, and ChromaDB as vector store. Persistent data reside in a file-based SQLite database with async support and Docker volumes. Authentication is JWT-based with role-based access control distinguishing patient and admin users. Logging is structured JSON with correlation IDs for request tracing, Prometheus exports metrics such as task completion rate, latency percentiles, tool-call frequencies, and error rates, and cost tracking records prompt and completion token usage per request (Hasan et al., 6 Jul 2026).

The interface layer is multimodal but shares the same backend orchestration and safety path. CareConnect supports web chat and WhatsApp for text, and a web-only voice interface using Whisper for ASR and OpenAI TTS for spoken responses. Voice activity detection uses a 1.5 s silence threshold and a 0.5 s minimum recording, with audio captured in WebM and converted for processing. The paper states that only presentation differs across modalities, with voice responses kept shorter to reduce latency (Hasan et al., 6 Jul 2026).

3. Deterministic safety model and bounded tooling

CareConnect’s safety layer sits before the model and is explicitly deterministic. The intent classifier is rule-based and uses curated high-precision multilingual pattern matching in English and Arabic. It detects three especially important categories: emergency-related intents, requests for prescriptive medical guidance, and diagnostic intent. If an emergency is detected, the system bypasses the model and issues a predefined emergency response directive. If a user requests medication recommendations, treatment guidance, dosage information, or diagnosis, the system again bypasses the model and returns a standardized refusal plus redirection to qualified healthcare professionals. The paper repeatedly describes these interventions as “deterministic short-circuit mechanisms” (Hasan et al., 6 Jul 2026).

This safety design is paired with tool-level validation. All tools have strict JSON schemas, required fields, type validation, mutually exclusive field definitions where needed, and cached-state consistency checks before execution. These constraints form a second guardrail layer. Even if the model selects the correct tool class but supplies malformed or inconsistent parameters, execution is blocked before any database state changes occur. The paper emphasizes that all observed tool-call errors were caught by schema validation and integrity checks before database execution, preventing data corruption (Hasan et al., 6 Jul 2026).

The eight domain-specific tools implement the administrative action space:

Tool	Representative endpoint	Administrative function
Appointment Availability Retrieval	search_timeslots	Retrieve available slots
User Appointment Retrieval	get_user_appointments	Return verified appointment records
Appointment Booking	book_appointment	Reserve a selected slot
Provider Directory Access	list_providers	List providers in a department
Appointment Modification	modify_appointment	Reschedule an existing appointment
Communication and Confirmation	send_email_confirmation	Send booking or update emails
Appointment Cancellation	cancel_appointment	Cancel a verified appointment
Knowledge Retrieval	rag_lookup	Answer facility, profile, and lab-prep queries

The orchestration of these tools is workflow-dependent. In a booking flow, the agent may first list providers, then search timeslots, then book a selected slot, and finally send an email confirmation. In a modification flow, it generally retrieves the user’s appointments, identifies the correct appointment identifier, searches alternatives, and then issues a modification call. In a cancellation flow, it retrieves appointments if necessary, asks for explicit confirmation, and only then invokes cancellation. In facility-information and lab-preparation workflows, the transactional tools are bypassed and the RAG tool is used instead. The paper presents this as a clean separation: transactional actions are tool-based and deterministic, while informational responses are retrieval-grounded but non-transactional (Hasan et al., 6 Jul 2026).

Several tool-specific safeguards are notable. Appointment Booking validates both provider identity and slot identifier, and slot IDs are structurally bound to provider information to prevent cross-provider inconsistencies. Appointment Modification requires a verified appointment identifier drawn from the user’s own appointment records, preventing hallucinated or unauthorized changes. Appointment Cancellation requires an explicit confirmation step to reduce accidental cancellation risk. These are narrow mechanisms, but they are central to the system’s transactional correctness.

4. Retrieval subsystem, knowledge scope, and operational implementation

CareConnect’s retrieval-augmented generation subsystem is designed for operational information rather than clinical knowledge. It indexes three document categories: facility documents, provider profiles, and lab test instructions. Facility documents cover parking instructions, building directions, operating hours, and visitor policies. Provider profiles contain biographical information, specialties, education, and languages spoken. Lab test instructions include preparation guidance for common tests such as CBC, lipid panel, and metabolic panel, including fasting requirements, timing instructions, and what to expect (Hasan et al., 6 Jul 2026).

The vector store is ChromaDB, and the embedding model is OpenAI’s text-embedding-3-large with 3072-dimensional embeddings. Documents are chunked into 512-token windows with 50-token overlap. Retrieval uses cosine similarity with top-k set to 5, plus metadata-based filtering when applicable. The paper reports that retrieval accuracy peaks at $k = 5$, which is therefore fixed for all RAG-enabled queries (Hasan et al., 6 Jul 2026).

This subsystem is integrated as a tool rather than as a universal augmentation layer. The model decides when a query is informational and should invoke semantic retrieval rather than a transactional API. This suggests a deliberate partition between knowledge-grounded informational assistance and state-changing administrative action. The same section of the paper also makes clear that the RAG layer is intended for facility information, provider profile questions, and laboratory preparation guidance, not for diagnosis or treatment recommendations.

The operational cost structure is specified unusually concretely. The paper states that an average booking conversation uses about 800 input tokens and 2000 output tokens under GPT-4o pricing of \$2.50 per million input tokens and \$10.00 per million output tokens. The itemized cost table is: GPT-4o input \$0.0020, GPT-4o output \$0.0200, vector search \$0.008, email \$0.0004, infrastructure \$0.002, for a total average operational cost of **\$0.0324 per appointment*. The human baseline is *\$0.75 per interaction** (Hasan et al., 6 Jul 2026).

5. Benchmark design, performance, and cost efficiency

The evaluation uses a synthetic but production-like database to avoid privacy and compliance concerns. It contains 30 patient accounts with realistic names and contact details, 60 healthcare providers across more than 20 medical departments, laboratory test definitions with preparation instructions, and historical appointment records across web, WhatsApp, and voice channels. The benchmark comprises 680 synthetically generated task-oriented scenarios, each with predefined conversation histories, expected tool-call sequences, success criteria, and prohibited behaviors (Hasan et al., 6 Jul 2026).

The scenarios are divided into five categories: Standard Workflows (160), Appointment Modifications (130), Information Retrieval (130), Safety Compliance (150), and Edge Case Handling (110). Standard Workflows include single-turn and multi-turn booking with date specification, department selection, provider preferences, relative date handling, and ambiguity resolution. Appointment Modifications cover rescheduling and cancellation with confirmation. Information Retrieval includes parking, hours, directions, lab preparation, provider listings, test result retrieval, and multi-part questions. Safety Compliance includes emergency detection, medical-advice refusal, diagnosis rejection, and boundary enforcement. Edge Case Handling includes no available slots, ambiguous provider names, past-date requests, conflicting constraints, multi-step modifications, and under-specified situations (Hasan et al., 6 Jul 2026).

The metrics are precisely defined. Task Completion Rate requires correct tool sequence, accurate parameters, and an appropriate final response. Safety Compliance measures correct handling of safety-critical scenarios, including emergency detection and refusal behaviors. Response Latency is measured end-to-end and reported at $p50$, $p90$, and $p99$. Tool Call Accuracy measures correct tool selection and parameter values, including slot ID format, date conversion, and required-field completion. Multi-Turn Coherence measures whether context is maintained correctly across longer dialogues. Cost per Task combines API pricing and infrastructure overhead (Hasan et al., 6 Jul 2026).

Across all 680 scenarios, CareConnect achieves a 91.8% task completion rate, corresponding to 624/680 passed tests. Category-wise performance is 90.6% for Standard Workflows, 88.5% for Appointment Modifications, 92.3% for Information Retrieval, 96.0% for Safety Compliance, and 90.9% for Edge Case Handling. Tool-call accuracy is 94.8%, corresponding to 3,283 correct invocations out of 3,462. The paper stresses that incorrect tool calls did not result in data corruption because schema validation and integrity checks blocked invalid execution (Hasan et al., 6 Jul 2026).

Latency remains within an operationally usable range. Median latency is 2.2 seconds, $p90$ is 4.2 seconds, and $p99$ is 8.7 seconds. RAG-enabled responses are slower and more variable than tool-only interactions, with mean 2.6 s and $2.50 per million input tokens and \$0 versus mean 2.0 s and $2.50 per million input tokens and \$1, attributed to vector-search overhead. Voice mode adds approximately 0.5 to 1.2 seconds per request, while WhatsApp does not differ significantly from the web interface. Under concurrent loads of up to 50 users, median latency remained below 3.0 seconds with near-linear throughput (Hasan et al., 6 Jul 2026).

The limited RAG ablation varies top-k retrieval from 1 to 10 and reports retrieval accuracy of 78.4% at $2.50 per million input tokens and \$2, 92.8% at $2.50 per million input tokens and \$3, and 91.3% at $2.50 per million input tokens and \$4, which is why the system fixes top-k at 5. By contrast, there is no ablation of safety layers or schema validation, so the contribution of those mechanisms remains architectural and inferential rather than experimentally isolated.

The cost comparison is practically significant. At \$2.50 per million input tokens and \$50.75 per interaction. Table III in the paper compares CareConnect with the human baseline as follows: success rate 91.8% vs 85%, average duration 3 requests × 2.2 s = 6.6 s vs 180 s, availability 24/7 vs 9am–5pm, and scalability unlimited vs 20/hr. The paper explicitly notes, however, that the human baseline is estimated from industry data rather than measured in the same environment, so the comparison should be interpreted cautiously (Hasan et al., 6 Jul 2026).

6. Failure modes, limitations, and place in healthcare AI

The paper reports 56 failed scenarios and identifies three dominant failure modes. The largest is constraint conflict resolution, accounting for 21 failures (37.5%), where users impose mutually incompatible requirements and the agent fails to negotiate alternatives within the turn budget. The second is context drift in long dialogues, accounting for 18 failures (32.1%), especially after six or more turns. The third is ambiguous temporal expressions, accounting for 11 failures (19.6%), particularly around phrases such as “next Friday” near week boundaries. The remaining 6 failures (10.7%) involve malformed input handling and concurrent slot contention (Hasan et al., 6 Jul 2026).

These errors expose the central tradeoffs of the design. Narrow scope and deterministic filtering improve safety but reduce conversational flexibility relative to more open-ended agents. Schema-constrained tools improve correctness and prevent harmful side effects but require substantial upfront engineering and can introduce brittleness in edge cases. RAG improves answer quality for facility and preparation questions but adds latency variance. The ten-iteration cap prevents runaway tool use but can truncate negotiations that require prolonged back-and-forth. The paper suggests that formal constraint-satisfaction methods would better handle multi-dimensional scheduling conflicts.

The limitations are substantial and explicitly stated. The benchmark is synthetic, though production-like, and does not establish performance in live hospitals. Real-world deployment would require IRB-approved clinical validation, integration with hospital systems such as HL7 FHIR, usability studies with actual patients, and longitudinal assessment of trust and adoption. The work also does not include a full red-team analysis, calibrated uncertainty estimates, formal verification of safety policies, or live integration with enterprise scheduling software. Privacy and compliance burdens are partly sidestepped by the use of synthetic data (Hasan et al., 6 Jul 2026).

Within healthcare AI, CareConnect is best understood as a tightly scoped operational agent rather than a medical AI system. Its contribution is the combination of deterministic safety routing before model invocation, schema-constrained tool orchestration for transactional correctness, and a separate RAG path for operational information. The system allows logistics requests such as scheduling, changing, canceling, provider lookup, parking, directions, and laboratory preparation; it refuses medical advice, diagnosis, and symptom interpretation; and it escalates emergencies through fixed responses rather than model-generated reasoning. This suggests a broader design principle: LLMs appear most defensible in healthcare when they are bounded by explicit scope, deterministic refusal and escalation logic, and validated transactional interfaces rather than being asked to operate as general clinical reasoners.