The assistant that reads a family’s whole care picture — records, documents, medications, benefits — dropped into your EHR, your portal, or your internal tools with a script tag. Bound to one patient, scoped by you, revocable in a click.
A patient chart knows the diagnosis, the medication list, and the last four visits. It does not know whether this family qualifies for a waiver, what the denial letter that arrived on Tuesday actually means, who to call about transport to dialysis, or which of the six people involved is supposed to do the next thing.
That gap is where caregivers live. They leave your product to find the answer, and most of the time they do not find it — they call, they wait, they repeat the same story to the fourth person, and they come back with nothing your system can use.
Ellie closes the gap without you building any of it. One script tag, scoped to one plan, answering from the record you already have.
The widget takes one piece of context from you — the patient, member or client currently on screen — and binds the whole conversation to it. That single fact is what makes it useful in places a general chatbot isn’t.
Drop the widget into the patient view your clinicians and families already use. It opens bound to that patient — the record, the medications, the documents, the care team. Nobody picks a patient, so nobody picks the wrong one.
The plan is bound server-side into the session token. A prompt that names a different patient cannot reach one.
The questions that eat a navigator's day — what does this cover, what happens when the waiver runs out, what do I do with this letter — get answered in the tool they are already working in, with the family's actual record in context.
Same orchestrator as the Eleplan app: benefits corpus, documents, medications, care team, and the plan itself.
A caregiver standing in someone's kitchen can ask what changed since the last visit, what the new prescription is for, or what the family was told at discharge — and attach the paperwork they were just handed.
Drag-and-drop or paperclip uploads run the same OCR and extraction pipeline as the Eleplan app.
Intake tools, referral queues, benefits screeners, the admin console nobody outside your company will ever see. If it renders HTML and knows which person it is looking at, it can carry Ellie.
No framework, no bundler, no build step. A plain script tag and a shadow root that will not touch your CSS.
It runs the same orchestrator as the Eleplan app — the same tools, the same knowledge base, the same benefits corpus — with the plan fixed to the one you bound at mint time.
Diagnoses, medications, documents, appointments, the care team and who is responsible for what — the same knowledge base the Eleplan app answers from, scoped to the bound plan.
A federal + state corpus of programs, and for each one the eligibility notes and the link to apply — not a list of names. It also knows what the family already told us they receive, so it stops recommending what they already have.
Attach a discharge summary, a denial letter, an EOB, a photo of a pill bottle. It goes through the same OCR and extraction pipeline as the app, and becomes answerable within seconds.
Headings, tables, lists, and links that are actually clickable — because the useful half of a benefits answer is the link to the application form.
Tokens as they arrive, and the tool it is running while it runs ("Loading benefits…"), so a slow answer reads as work rather than as a hang.
Sessions expire in five minutes; conversations do not. History is pinned to your user, so a renewed session picks up mid-thread instead of starting over.
A 380px corner bubble or an 880px panel, remembered per user. Every answer copies as markdown, because it is going into a chart note or a referral.
Shadow DOM isolation both ways: your page cannot break the widget and the widget cannot leak into your page. Title, launcher label and starter prompts are yours to set.
There is no SDK to adopt and no framework to match. The whole integration is one endpoint on your side and two tags on the page.
One long-lived elk_ key, scoped to the origins you name and the plans that opted in.
One endpoint, behind your own auth. It decides who is allowed to talk and which plan they get.
Two script tags. The widget calls your endpoint, gets a five-minute session, and starts.
<script> window.EllieWidgetConfig = { // we send this with your key chatUrl: "https://<id>.lambda-url.us-east-1.on.aws/", sessionEndpoint: "/api/ellie-token", // you mint it projectId: currentPatientId, // your id };</script><script src="https://cdn.eleplan.com/v0/ellie-widget.js" defer></script>// The long-lived key never reaches a browser.app.post('/api/ellie-token', requireYourAuth, async (req, res) => { const url = 'https://production-api.eleplan.com/client/embed/session'; const r = await fetch(url, { method: 'POST', headers: { Authorization: `Embed ${process.env.ELEPLAN_KEY}`, 'Content-Type': 'application/json', }, body: JSON.stringify({ project_id: mapToEleplanPlan(req.user.patientId), external_user_id: req.user.id, // audit only }), }); res.json(await r.json()); // { session_token: "els_…" }});That’s the whole integration. Optional extras: pass uploadBase to turn on document attachment, suggestions to seed starter prompts, and title to rename the panel.
You are putting this on a page that shows patient data. So the interesting question isn’t what it can do — it’s what it can’t, and who decides.
Your server holds a long-lived key (elk_) and trades it for a short-lived browser session (els_) per user. The key never reaches a page. A leaked session token is worth five minutes, on one plan.
Sessions are only minted for origins you registered. A copy of your page on someone else's domain gets a 403, not a conversation.
A plan is reachable through the embed only when it has been explicitly included. Enabling a partner does not silently enable everyone in the account.
The bound plan travels in the session token. The browser cannot pivot to another patient, and neither can the prompt — a request body that claims a different plan is ignored.
Keys carry status, expiry and a per-minute limit; revoking one takes effect on the next mint. A global kill switch can take the whole embed surface down without a deploy.
You pin a version in the script URL. v0 stays v0 forever — improvements ship as v1, and you move when you are ready.
Give them somewhere to ask the questions your system was never built to answer — without sending them anywhere else, and without building any of it yourself.