What your patients would be using
A note for practitioners who put patients on elimination-and-reintroduction protocols. The software is theirs, not yours: they hold the account, they hold the data, and there is nothing here for you to log into. This is so you know what it tells them, and what it will not.
What it is
Software your patient uses to get through an elimination-and-reintroduction protocol between their appointments. It holds their plan — the base protocol plus whatever you changed — knows which phase they are in, and tells them what is coming: the first week, eating away from home, the challenge that should not land on a holiday.
It is not a calorie tracker, a barcode scanner or a weight-loss app. It has one job, which is getting somebody through a protocol in a state where the results mean something.
The problem it is built for
A reintroduction result is worth only what the elimination behind it was worth. Between appointments three things go wrong, and none of them reach your notes.
Hidden exposures. Soy in the salad dressing, dairy in the non-dairy creamer. The patient does not know they broke the protocol, so they do not report it, and the challenge that follows reads clean when it is not.
Recall. You ask how dairy went, about a challenge that ended three weeks ago, and get an answer assembled on the spot.
Week one. Most of the people who quit quit early, and they quit over lunch and snacks rather than over conviction.
How it works, and what it will not do
The rules are enforced in code, not by a language model. The patient’s effective rule set — the protocol plus your modifications — is checked against every answer before it is shown. A model is used to phrase things and to read menus. It is never the authority on what is allowed. This is the part most worth scrutinising, and we will show you exactly how it works.
It never says what a symptom means. It records what the patient tells it and shows it back. It does not correlate a symptom with a food, does not suggest a cause, and does not produce anything resembling a diagnosis. The rule engine that decides what is allowed cannot read symptom data at all.
It never volunteers a symptom. Handing somebody on an elimination diet a checklist of things to watch for manufactures the symptoms. Patients name their own, in their own words, or nothing is tracked.
Phases advance on confirmation, never on a date. Real life includes lab work, appointments and travel. The app will say a phase looks complete. It will not move somebody on because fourteen days elapsed.
Uncertainty is stated rather than smoothed over. Every food and restaurant answer carries how confident it is, the specific reason for the doubt, and a sentence the patient can say to a server or read on a label. Where the protocol is genuinely ambiguous the app says so and asks them to check with you, rather than picking an answer and sounding sure.
Red flags go to you. Dizziness, vision changes and the like get “eat something now, contact your practitioner today” and a summary they can hand over. The app does not attempt to manage them.
Your modifications are the plan
If you have taken something out of the standard protocol, or put something back in, that is what the patient’s app enforces — not the textbook version. Every rule on their screen says where it came from: the protocol, you, or their own answer at setup. They can see at a glance which restrictions are yours.
Currently supports the standard functional-medicine elimination protocol. AIP and Whole30 are on the roadmap and not in the product.
What comes back to you — not yet
The obvious thing to want is a document your patient brings to the appointment: phases and dates, which challenges ran and what happened, exposures during each challenge window, the symptoms they came in for and how those have moved.
It does not exist yet. Today a patient can show you their plan, their challenge history and their symptom record on screen, which is not the same thing. It is being built, and it is the weakest part of this offer until it is done. You are being told rather than finding out.
Where the data lives
You do not become our customer and we do not become your business associate. The patient signs up, the patient owns the record, the patient decides what to show you. There is no practitioner login and no roster of your patients.
That means no BAA to negotiate. It also means we cannot show you a dashboard, which is deliberate rather than a gap.
The full answer: what is stored, where it goes, what we do not claim, and the two things that are still in progress.
What we are asking for
A small number of practitioners willing to mention it to one or two patients who are about to start, or are early in, an elimination protocol — and to tell us where it is wrong.
In return: direct access to the person who built it, changes made quickly, and no cost during the beta.
How a patient of yours would get in
It is invitation-only while it is being tested, so there is no public sign-up. If you have somebody in mind, email hello@culprithealth.com and we will send them a code directly — please do not send us anything about them beyond the fact that you have someone.
Who is behind it
Questions about data handling are answered at culprithealth.com/for-practitioners/data.
Culprit was built by Eric Street, who ran the protocol himself and wrote it because nothing existing did the job.
It is early software, run by one person. We would rather say that than have you find it out.