Turning Care Coordination into a Conversation

About the Client

Our client operates a consumer platform that helps older adults age in place. The product connects seniors and their families to independent home health and home service providers, and gives them a single place to manage care: appointments and reminders, medication tracking, shared access for family members and care partners, secure document storage, and direct contact with human care advisors.

The company came to us to build one specific part of that product: the conversational layer across that experience: an AI assistant that could understand what a user needed, help identify appropriate services, interact by voice or text, and initiate real-world actions such as contacting providers.

The Challenge

Two problems drove the work.

The first is a market problem. Seniors who want to stay in their homes have a hard time finding providers for the specific help they need, whether that is post-surgical support, mobility assistance, transportation to appointments, or routine household help. The supply exists, but it is fragmented and difficult to search.

The second is an interface problem. The people who need this help most are often the least well served by conventional app design. Multi-step search flows, filter menus, and dense provider directories create friction at exactly the point where a user is already stressed or unwell. Our client's position was that the interface should not require the user to learn it. A user should be able to say what they need in plain language, by typing or speaking, and the product should take it from there.

That premise is straightforward to describe and difficult to build. A natural language interface in a healthcare context has to be fast enough to feel conversational, constrained enough to avoid giving medical advice it is not qualified to give, and handled carefully enough that protected health information never ends up somewhere it should not be.

Our Approach

The work moved through four stages that overlapped considerably in practice: defining use cases and constraints, selecting an LLM strategy, building the integration and orchestration layer, and establishing logging, evaluation, and governance.

Defining the use cases and constraints

Before selecting a model or writing integration code, we worked with the client to define what the assistant was actually for. The core use cases were chat-based support for general questions, summaries of companion and provider visits, task matching and routing based on user intent,

We then defined the constraints, which mattered more than the use cases in shaping the build:

• Latency. The assistant had to respond quickly enough to feel like a conversation rather than a form submission. This constraint influenced model selection, prompt length, and how much work could happen in a single turn.
• Safety. The system needed guardrails that reduced unsupported responses and reliably redirected requests outside the assistant's intended scope, particularly questions that could be interpreted as requests for medical advice.
• Data handling. The system had to be built so that protected health information was redacted or excluded wherever it was not strictly required, particularly in logs.

Writing those constraints down early is what made the rest of the build tractable. Every later decision was measured against them.

Choosing an LLM strategy

For the MVP, we selected a hosted API model rather than a fine-tuned or self-hosted one. Anthropic Claude handles the reasoning and conversation. The decision was deliberate: fine-tuning and self-hosting introduce MLOps overhead that is difficult to justify before you have real usage data to fine-tune against.

We intentionally kept the model layer replaceable. The architecture left room for future retrieval augmentation, model specialization, or alternative deployment strategies as usage patterns and requirements became clearer. A future RAG layer could ground responses in the client's visit guides, FAQs, and internal documentation using semantic retrieval.

Building the integration and orchestration layer

The model was only one component. The real product was the orchestration around it. It is an orchestration layer that has to move between text, voice, retrieval, and real-world action.

We built a secure proxy backend in Node.js so that the mobile app never communicates directly with model providers. That proxy handles authentication, request shaping, error handling, and response fallbacks, so a provider timeout or a malformed response degrades into a usable message rather than a failure state in the app.

On the client side, the app is React Native running on Expo. Users can type or speak, and the interface shows a thinking indicator while a response is being generated, which turned out to matter: without it, older users assumed the app had frozen and started tapping. Chat history is stored on the user's device.

Voice runs through a Python service built on LiveKit Agent, handling real-time audio transport and turn-taking, with ElevenLabs for speech synthesis. Tavily provides web retrieval for questions that require current external information.

The hardest part was not answering the user's question. It was acting on it. When a user asks for a medication reminder we not only created an alarm but also made the user aware of any additional medication related notices like food intake. Working out what the agent could say, what it could not, what got logged, and where the boundaries sat took a significant share of the engineering effort on this project.

Alongside that, the assistant had to integrate with the rest of the platform: the admin portal, geolocation services, scheduling, translation, provider records, and family member permissions. Each of those integrations carried its own compliance considerations, and we worked through them with the client rather than handing back a list of requirements.

Logging, evaluation, and iteration

An AI feature that cannot be measured cannot be improved. We built structured interaction logging that records redacted versions of user input and model responses alongside session metadata such as timestamp and session ID. We added in-product feedback capture so users could indicate whether a response was helpful, which gives the client a labeled dataset for future tuning and guardrail work.

We also instrumented the operational side: prompt length, latency, API cost per session, and unexpected behavior. Cost and latency tracking are not glamorous, but they are what keeps an AI feature economically viable as usage grows.

This is where most of the project's effort actually went. Getting a model to answer a question is quick. Getting it to answer consistently - within latency targets, without drifting toward medical advice, and across the wide range of ways users expressed the same need through speech and text - took repeated cycles of prompt revision, test, evaluation, and revision again.

Guardrails and governance

We hardened the system prompt to define the assistant's role explicitly, including what it is not. Requests that cross into individualized medical guidance are routed to defined responses that decline to advise and direct the user toward appropriate human support. We implemented filters to redact PHI before logging and to detect and redirect unsupported categories. Those controls are documented so the client's team can extend them as the product grows.

The Result

The client launched an MVP in which the primary interface for finding and arranging home care and support services is a conversation. Instead of navigating provider categories, filters, and contact information manually, a user can now describe the outcome they need and let the platform coordinate the next steps. A user asks for what they need in plain English, by voice or text, and the system interprets the request, searches for matching providers, contacts them where necessary, and coordinates the result.

Just as importantly, the client now has the infrastructure underneath it: a secure proxy layer, logging designed to support the client's HIPAA and privacy requirements, a feedback loop, guardrails that are written down rather than implied, and a documented path to retrieval augmentation and model fine-tuning as usage data accumulates. The assistant can be improved based on evidence rather than intuition, which is the difference between an AI feature that ages well and one that has to be rebuilt.

Why Healthcare AI Requires a Different Approach

This project reflects a pattern we've seen across our work in healthcare. We built Anthem's Sydney Care mobile telehealth product, launched during the early months of the COVID-19 pandemic, as lead mobile development partner. We worked with K Health to scale its AI healthcare platform across systems using Kotlin Multiplatform, including a unified video layer for virtual visits and server-side localization for multilingual care. We rebuilt Freshpaint's mobile SDKs so healthcare marketers could run attribution without exposing protected health information.

The pattern across all of it is the same. Healthcare products carry constraints that most consumer software does not, and those constraints have to be designed into the system from the beginning rather than added at the end. That is the work.