Inspiration

In most primary care offices the visit type is chosen by whoever answers the phone, and that person isn't a clinician. From "I need to see the doctor about my sugar, and my knee's been bad" they have to pick between a short follow-up, a longer problem visit or a wellness visit. They get it wrong a lot. Patients over 65 bring nearly four problems to every visit, short slots are the ones that overrun, and since 2021 office visit billing follows the complexity of what actually gets addressed. The idea came from my wife, a physician assistant in primary care. Her point was that clinicians and practice managers live with this every day, but nobody counts it. I then pitched it to a regional health system in North Carolina to see if they had the same problem.

Patients still book by phone. In a Phreesia survey of about 14,000 patients, 65% preferred to schedule by phone and 18% online. So we didn't want another self-scheduling portal. We wanted to meet patients on the channel they already use and give the front desk better information.

What it does

A patient texts the clinic or calls it. VisitFit asks seven short questions in English or Spanish: new or returning, the main reason, anything else to address, new problem or follow-up, how long it's been going on, whether it's urgent, and a final recap to confirm. It skips whatever the patient's record already answers.

The answers go through a clinical knowledge base, not the language model. That produces the recommended visit length, the likely E/M level with the reasoning behind it, the relevant ICD-10 range and flags such as "not seen in 16 months". Emergency words ("chest pain", "can't breathe") stop the intake on any message, give a 911 script and raise an urgent task.

The scheduling team gets the full pre-screen in Amazon Connect:

  • A finished phone intake becomes a live transfer to the VisitFit Scheduling queue, and the agent workspace opens the VisitFit-Handoff view.
  • A finished text intake becomes a Connect task with the same view.
  • The patient gets a confirmation email from Amazon SES in their language.

A person still books the visit, with everything in front of them.

How we built it

  • Text lane: AWS End User Messaging (SMS, RCS, WhatsApp) delivers inbound messages to SNS. A router Lambda puts them on an SQS FIFO queue with one message group per patient, and a worker Lambda hands each turn to the intake agent on Amazon Bedrock AgentCore Runtime (Bedrock Converse with Claude Haiku 4.5, plus AgentCore Memory). Replies go back out through End User Messaging.
  • Voice lane: an Amazon Connect AI agent (Claude Sonnet 4.6) with a Lex bot for English and Spanish. It calls the same clinical tools over MCP through AgentCore Gateway, backed by a Lambda.
  • Shared clinical core: a TypeScript package with the questions, scoring, slot mapping, E/M and ICD-10 logic and emergency rules. Both lanes use it and share one DynamoDB session record, so a patient can start by text and finish on a call.
  • Handoff: intake events go to EventBridge. A dispatcher Lambda stores the handoff, sends the SES email and starts the Connect task. The workspace view is built with the Connect UI builder and opened by an agent UI flow.
  • Deployment: AWS CDK for the platform and a re-runnable boto3 deployer for the Connect side. 277 tests run without touching AWS.
  • Demo site: an SMS and rich chat simulator at visitfit-demo.intelligentvisibility.com that runs the real worker against fictional patients and shows the scheduler's view.

Challenges we ran into

  • Connect workspace views. CloudFormation turned the view template's booleans and numbers into strings, visibility conditions on inputs were rejected, and the view only appeared after fixing a 403 on the agent workspace guides API. We ended up creating the view through the API instead.
  • Live transfer instead of a task. Making a finished call land in a person's queue with the pre-screen attached, and creating a task only when the transfer fails.
  • Real SMS. Toll-free registration came back needing updates and the account is still in the SMS sandbox, so the demo site drives the same worker through a simulator.
  • Spanish that doesn't assume gender. The agent doesn't know the patient's gender, so both agents use phrasing like "¿Ya le han atendido aquí?" instead of gendered participles.

Accomplishments that we're proud of

  • The model never scores, picks the slot or decides an emergency. It only collects answers, and every number on the handoff can be traced back to a rule in the knowledge base.
  • One intake across text and voice, in two languages, ending in the scheduler's own Amazon Connect workspace.

What we learned

Most of the work in a clinical agent is deciding what the model must not do. Keeping decisions deterministic made the agent easier to test and easier to explain to the people who would use it.

What's next

  • Real SMS once the toll-free number is approved, then WhatsApp through a Meta business account and RCS.
  • EHR integration, so returning patients are recognized from the chart.
  • Feeding the structured pre-screen into automated scheduling, so a self-booking page offers slots that fit what the patient brings.
  • A pilot with a primary care practice.

Pre-existing work (disclosure)

The project and repository were created during the submission period. Some earlier work was ported into it and extended:

  • The clinical knowledge base (v1.2.1), the scoring, E/M and handoff logic and their test scenarios came from an earlier VisitFit prototype built earlier in 2026, rewritten in TypeScript for this project.
  • The Connect-side deployer follows the pattern of an earlier internal Intelligent Visibility project.

Everything else, including the AWS CDS text lane, AgentCore Runtime agent, voice agent, handoff, workspace view and demo site, was built for this hackathon. Patients and the clinic in the demo are fictional. Voiceover and music in the video were generated with ElevenLabs.

Built With

Share this project:

Updates

Submission history