Your intake, already done
before they walk in.
Any practice busier than its front desk has the same problem: the same information re-collected by phone, and sometimes no good way to handle a new patient at all besides turning them away. This is one engine that handles new and returning patient intake conversationally, verifies who it's talking to, books a real slot, and hands the doctor a clean summary instead of a transcript.
Both sides, start to finish: a patient taps through intake and books, then a cut to what the doctor actually sees, today's queue and one patient's pre-visit summary built out in full.
Try It Live
Real model, synthetic patient
Pick a specialty to see the same engine reconfigure itself. Cardiology is set to not accepting new patients, matching the real situation this was built for, so a new patient there hits the waitlist, not a calendar. Returning patient requires the demo email below. Type a phrase like "chest pain" anywhere to see the guardrail fire instead of the AI.
Now showing: Maple Street Family Medicine, Dr. Owen Marsh
New patient
Patient side, live demo
Dr. Owen Marsh's screen
What's actually happening with this patient, readable in seconds, not a transcript to scroll through.
Today's queue
Returning · Annual physical
New · New illness or symptom
New · New illness or symptom
Pre-visit summary
Chat a bit on the left, then generate the summary, this is what Dr. Owen Marsh reads instead of scrolling the conversation.
How It Works
Five steps, the whole system, not just the chat
Every screen below is what you just tried above, broken into steps.
01: The conversation starts with options, not a blank box
New or returning, the first message is tappable reasons for the visit, not an open "how can I help," so nobody has to guess what to type.
Tappable options, not a blank box, so nobody has to figure out what to type first.
02: A returning patient is verified, never guessed
Matched against stored records by email before anything is shown, so nobody is greeted by name on a guess that happens to be right.
Confirm it's you
Email on file
Matched, welcome back
03: A new patient's slot never goes to a fake contact
A phone number gets a real code before a calendar slot locks, the same pattern any serious booking system uses before a seat is spoken for.
Confirm your number before we hold a slot
Code sent to (555) 123-4567
A new patient's slot locks only once this step clears, no reserved seat for a contact that doesn't answer.
04: No open slot doesn't mean a lost patient
If the practice isn't accepting new patients right now, it becomes a waitlist entry with a real position, not a conversation that just ends.
Full schedule, not a dead end
This specialty isn't taking new patients today. Instead of turning the conversation away, it goes on a real waitlist with a position number.
You're #4 in line
05: The doctor sees a queue, not a chat log
Every patient's pre-visit status, summary, and visit type sits next to the rest of the day's schedule, in seconds, not a transcript to read.
Doctor's screen, today's queue
A pre-visit summary behind each name, readable in seconds, not a transcript to scroll through.
Tappable options, not a blank box, so nobody has to figure out what to type first.
Security & Safety
Stress-tested, not just assumed safe
This was adversarially tested against the live model, role-hijack attempts, fake system-override instructions, prompt leaks, indirect exfiltration, contraction and leetspeak obfuscation. Each real gap found was fixed and re-verified. No fixed keyword list can catch every possible encoding, that's a structural limit of this approach and worth saying plainly rather than overclaiming it's solved.
A hard, unmodelled safety check
Any phrasing of a serious symptom is caught by a deterministic check before the model is ever called. Safety never depends on the model's judgment, by design.
Prompt-injection resistant by default
Role-override attempts ("ignore your instructions," "you are now...") are deflected client-side and refused again in the system prompt, tested live against both layers.
Obfuscation-aware, not just keyword matching
Leetspeak and punctuation tricks are normalized before the safety check runs, closing the most common way a keyword filter gets talked around.
Scoped to intake, nothing financial
This engine only ever collects visit information and books a slot. It has no access to billing, payment, or insurance claims systems to begin with.
Identity checked before anything is shown
A returning patient is matched against stored records by email first. Nobody is greeted by name, or shown another patient's history, on a guess that happens to be right.
No slot held on an unverified contact
A new patient's phone number gets a real verification code before a calendar slot locks, so a booking can't be made against a number nobody confirmed.
What this deliberately doesn't do yet
- No real EHR or calendar system wired up, the calendar and queue above are a realistic simulation so the flow can be judged properly, a real version connects to the practice's actual scheduling.
- The phone verification code and the SMS reminder are both simulated, no texting provider is wired in, the point here is that the step exists and gates the booking, not the delivery mechanism.
- The AI never assesses how serious a symptom is, that routing is a fixed keyword check, not a model decision, on purpose, and it's the same check across every specialty above.
- This demo uses fake data only. Real patient data needs its own compliant setup, including a signed BAA, before this touches a real clinic.
Thinking about what closing any of these gaps would take for a real practice? Get in touch.
FAQ
Frequently asked questions
Can't find what you're looking for? Reach out and a real person will answer.
Is this specific to cardiology?+
No. The intake engine, safety guardrail, and booking logic are general-purpose. Cardiology here is one configured specialty, shown because it's the real example this was built for, not a separate build.
What happens with a serious symptom?+
A deterministic keyword check runs before the model is ever called. It never depends on the model's judgment, and it fires identically across every specialty.
Is this connected to a real EHR or calendar?+
Not yet. The calendar, queue, and reminders are a realistic simulation so the flow can be judged honestly, see the section above for exactly what's simulated.
Is this HIPAA compliant?+
Not yet, and this demo uses fake data only so that question doesn't apply to it yet. A signed Business Associate Agreement and a compliant hosting setup come before any real patient data touches this.
Why options instead of an open chat to start?+
A tappable reason for the visit gets someone moving in one tap instead of staring at a blank box deciding what to type, the model still handles anything typed in free text after that.
What happens to what a patient types in the demo?+
Nothing is stored against a real identity. This is a working demo with synthetic data, there's no real patient record behind any specialty shown here.
How does a returning patient get identified?+
By email, matched against the demo's stored records before anything is shown. If it doesn't match, nobody is greeted by name or shown a history that isn't theirs.
What happens if the practice isn't taking new patients?+
The conversation doesn't just end. It becomes a waitlist entry with a real position number, so there's still a next step instead of a dead end.
Can this handle more than one specialty or location?+
Yes, that's the point of being general-purpose first. Each specialty configured on top gets its own reason options, system prompt, and booking rules, cardiology here is one example, not a hardcoded path.
What would it take to put this in front of a real practice?+
A real EHR/calendar connection, a signed BAA and compliant hosting, and a real SMS provider for the verification code and reminders, all intentionally deferred for this demo so the conversation flow could be judged on its own first.