AfterCare

Inspiration Hospitals discharge patients into a gap. Nurses are busy, follow-up calls get skipped, and warning signs — missed meds, worsening pain, shortness of breath — often show up only when the patient is already back in the ER.

We wanted a system that actually calls the patient, asks the right clinical questions for their diagnosis, and puts a clear risk signal in front of the care team — not another dashboard that waits for someone to remember to check in.

CALL-E made that possible: a real voice agent that can hold a structured conversation and return results we can score, store, and escalate.

What it does AfterCare is a post-discharge clinical workspace. Care teams register a patient with consent, attach a disease protocol, and schedule follow-up calls. CALL-E then places the call, asks protocol questions (symptoms, pain, medications, warning signs), and sends the transcript and structured result back to AfterCare.

From there we:

Score clinical risk (low / medium / high / critical) from the conversation Flag emergencies and alert the doctor by SMS Retry missed outreach within attempt limits Show clinic overview, call activity, patients, and protocols in one admin UI Let staff ask the clinic in plain language (“who is overdue?”, “tell me about that patient”) via an AI assistant that queries live data Live calls never go out without consent on file.

How we built it Voice: CALL-E for outbound patient follow-ups and doctor warning calls, with signed webhooks for completion, transcripts, and structured results Backend: FastAPI, PostgreSQL, SQLAlchemy, Alembic; APScheduler for due follow-ups Clinical logic: Disease protocols (questions, emergency keywords, result schemas) that become the CALL-E task and result schema Risk: Combine CALL-E structured fields with LLM extraction (Gemini / Claude) and keyword safety checks Search: sentence-transformers + pgvector so the assistant can search patients and call transcripts by meaning, not just exact match Alerts: Twilio SMS Frontend: Next.js admin workspace — Overview, Activity, Patients, Protocols, AI Assistant Ops: Dry-run mode so we can demo the full loop without placing live calls

Challenges we ran into Turning a free-form phone conversation into something clinicians can trust — structured fields, risk levels, and summaries that don’t invent facts Webhook reliability: retries, idempotency, and distinguishing patient follow-ups from doctor warning calls Teaching the assistant to use tools correctly (list patients before guessing an ID, don’t duplicate cards, don’t dump every clinic metric unless asked) Keeping the product consent-aware and non-diagnostic — it summarizes recorded data; it does not prescribe

Accomplishments that we're proud of An end-to-end loop: protocol → scheduled call → CALL-E conversation → risk score → dashboard → emergency escalation Protocols that clinics can create and edit without writing prompts by hand An assistant that answers from real clinic tools, not hallucinated patient lists Semantic search over patients and transcripts A UI meant for a working care team, not a demo-only chatbot

What we learned Voice agents are only useful if the rest of the system is boring and reliable: consent, scheduling, retries, signed webhooks, and a clear owner when something is high-risk.

We also learned that tool-using assistants need tight prompts and result cards. If the model calls the same list twice, the UI looks broken even when the data is right. Grounding beats a longer reply.

What’s next for AfterCare Auto-open a patient detail when the clinic has exactly one matching patient Multi-language outreach for the regions we already infer from phone numbers Richer protocol libraries (procedure-specific pathways, not only disease codes) Stronger audit trails for who saw an alert and what they did next Hospital pilots: fewer missed follow-ups, faster escalation, measurable readmission impact