CASE STUDY · HEALTHCARE · GENERATIVE AI
Building a Patient-Safe AI Diet Assistant: 13 Constrained GPT-4o mini Modules Across 15+ GI Conditions
A US-licensed gastroenterology practice needed patients to follow strict medical diets — celiac disease, Crohn’s, IBS, cirrhosis — without calling the front desk over every meal. We built a Flutter app whose 13 AI modules all run through one GPT-4o mini engine, with every response filtered through the patient’s diagnosed condition, physician-approved diet plan, dietary preference, and allergies. Rule-based prompt templates enforce those constraints; the model never answers outside them.
See if this maps to your stack 30-second skim: jump to what it would take in your environment.
Why patients fail medical diets (and why PDFs can’t save them)
The client is a US-licensed gastroenterologist, one of the healthcare AI engagements we run, treating celiac disease, Crohn’s disease, IBS, cirrhosis, chronic constipation, and more than fifteen digestive disorders in total. For most of these conditions, diet is not lifestyle advice. It is the treatment, or the thing that keeps the treatment working. The practice came to us for a generative AI development engagement with an unusual constraint: the AI could never be wrong in a dangerous direction.
Prescribing the diet takes minutes in the consult room. Living it is everything that happens after. We mapped where adherence actually broke, and it broke in four places: the grocery aisle, where a patient reads an ingredient label and cannot tell whether hydrolyzed wheat protein ends their week; the restaurant table, where the menu says nothing about preparation; the pantry, where packaged foods hide triggers behind marketing language; and prep week, where a missed instruction means an incomplete colonoscopy and a rescheduled procedure. GI literature consistently reports inadequate bowel preparation in roughly one in four colonoscopies, and meta-analysis puts non-compliance with the preparation diet among the independent risk factors, at roughly two and a half times the odds.
The practice’s existing tool for all of this was printed PDF diet sheets. A PDF cannot answer ‘can I eat this, right now, given my diagnosis.’ So patients guessed, or they called the front desk, or they typed the question into whatever chatbot was already on their phone.
Why raw ChatGPT is the wrong answer for medical diets
Patients were already using AI before this project existed. They pasted menu items into free chatbots and asked whether something was gluten free. The answers came back fluent, confident, and blind to everything that mattered: the diagnosis, the physician’s specific plan, the nut allergy on file, the fact that this patient is three days from a colonoscopy.
A general-purpose model is agreeable by design. Ask it whether you can eat something and it will usually find a way to say yes, with caveats a stressed patient will not read. Plausible-but-wrong is more dangerous here than obviously wrong, because plausible gets eaten.
This is a documented problem, not our opinion. Recent clinical-safety research on patient-facing LLMs describes exactly this failure mode — responses that are conditionally correct yet medically inappropriate for the person asking — and peer-reviewed work in safety-critical medical settings reaches the same conclusion: unconstrained generation does not belong in front of patients.
To be precise about our position: the problem is not the LLM. It is the missing constraint system around it.
How do you make an LLM safe enough for medical diet advice?
Every patient in the app has four pieces of structured intake: the diagnosed condition, the physician-approved diet plan for that condition, the dietary preference (vegetarian, vegan, or non-vegetarian), and the allergy list. No request reaches GPT-4o mini without all four.
The enforcement mechanism is rule-based prompt templates assembled server-side, never in the app. Each of the fifteen-plus conditions maps to a rule set the physician reviewed: foods that are allowed, restricted, or forbidden, plus condition-specific logic — fiber staging for diverticular recovery, sodium and protein handling for cirrhosis, FODMAP phases for IBS. The template wraps the patient’s question inside those rules before the model ever sees it, and a structured output format defines what a valid answer looks like. The model completes inside a box; it does not get to choose the box.
Refusals are designed, not accidental. When a celiac patient asks for a regular pasta recipe, the app does not lecture and does not comply. It returns a compliant alternative with a one-line reason. When the model’s confidence in a verdict is low, the answer is ‘I can’t verify this — ask your care team,’ which we treat as a correct output, not a failure.
“We didn’t ask the model to be careful. We built the system so it couldn’t be careless.”
We rejected two alternatives on the way here. Fine-tuning bakes rules into weights where no physician can audit them. A frontier model with soft prompting buys eloquence without buying enforcement. The winning pattern — hard constraints around a capable-enough model — is the same one behind our rule-constrained tender document analysis system, and it holds here with higher stakes.
What clinics actually compare
| Dimension | Printed diet handouts | Generic diet apps | Patient + raw ChatGPT | Constrained clinical assistant (this build) |
|---|---|---|---|---|
| Condition awareness | Generic per condition at best | Calorie and macro focus, condition-blind | None — answers from general priors | Encoded per diagnosis, physician-reviewed |
| Physician-plan fidelity | Static snapshot, drifts immediately | Not represented | Not represented | Enforced on every response |
| Allergy enforcement | Patient’s memory | Manual filters, easy to bypass | Only if restated every time | Hard constraint, cannot be skipped |
| Restaurant and grocery context | Absent | Barcode lookup at best | Text-only guesswork | Menu photos, barcodes, labels — verdicts in context |
| Hallucination exposure | Not applicable | Low (no generation) | Unbounded | Bounded by templates and output schemas |
| Auditability | High but frozen | Vendor black box | None | Every rule set reviewable by the physician |
| Ongoing cost to clinic | Printing plus front-desk calls | Per-seat subscriptions | Free, with liability | Cents per patient-month at published API rates |
The system: one engine, thin surfaces
The app is Flutter on iOS and Android from a single codebase, because a specialty clinic does not need two native teams. A server-side application layer is where constraint assembly lives: it stores the rule sets and patient profiles and builds every prompt server-side, so the client app never talks to the model directly and never holds the rule logic.
The reasoning core is OpenAI GPT-4o mini over the API, used in both text and vision modes. Four supporting services do the non-reasoning work. Google Gemini generates recipe imagery so meal plans read like food instead of homework. The Open Food Facts API resolves barcode scans into ingredient data. The Instacart API turns an approved grocery list into a placed order. A push-and-email reminder service runs prep schedules and plan nudges.
The architectural decision worth copying: there are thirteen modules but one engine. The meal planner, the menu analyzer, and the barcode scanner are the same constrained core wearing different inputs. A new module is a new template and a new screen, not a new AI system.
Thirteen modules, three jobs
We group the modules by the job they do for the patient, because that is how usage clusters.
Plan. Condition Intake collects the four constraints and turns them into the structured profile every other module reads from. The AI Meal Planner builds day and week plans inside the patient’s rule set. The Recipe Generator produces compliant recipes with Gemini-generated imagery. The Grocery List Builder converts a plan into a shoppable list. The Diet Chatbot answers the long tail, from coffee during prep to almond flour, under the same constraints as everything else.
Verify. The Barcode Scanner turns a packaged product into a verdict by grounding the answer in Open Food Facts ingredient data rather than in model memory. The Ingredient Label Reader covers everything the barcode database has never seen: photograph the panel, extract the list, run the same check. The Restaurant Menu Analyzer reads a photographed menu and marks what is safe, risky, or fixable. The Probiotic Evaluator assesses supplement labels against the patient’s condition, a question GI patients ask constantly and diet sheets never answer.
Act. One-click Instacart Ordering moves the approved list into a cart without the second manual pass where substitution errors creep in. The Colonoscopy Prep Scheduler sequences the dietary run-up day by day. The Reminder System pushes the right instruction at the right hour by notification and email. Care-Team Escalation is the thirteenth: when the engine returns a cannot-verify answer, the question routes to the practice instead of dead-ending on the patient’s screen.
Planning modules generate inside constraints. Verification modules judge the real world against constraints. Action modules put the plan in motion. Different verbs, one filter.
A menu photo becomes a verdict
Here is the pipeline patients use most, end to end. A patient at a restaurant photographs the menu. GPT-4o mini’s vision mode extracts the dishes and probable ingredients, including the ones menus do not print, like the butter basting on the fish. Each candidate dish then runs through the constraint check: condition rules first, then the physician’s plan, then preference, then allergies. The patient gets a three-state verdict per dish — eat, avoid, or modify — with a one-line reason: ask for it grilled instead of breaded; the sauce typically contains cream.
Barcodes ride the same spine with better data: scan, resolve through Open Food Facts, run the actual ingredient list through the same check, return the verdict plus a nutritional breakdown. Packaged-food labels are the middle case — photograph, extract, check.
The verdict format is deliberate. A patient standing at a table does not want a nutrition essay; they want a decision with a reason they can act on in thirty seconds. Verbosity is a safety problem here: the longer the answer, the less of it gets read. Sub-three-second verdicts were a design requirement rather than an outcome we discovered: past that, a patient at a table stops waiting and guesses.
Why GPT-4o mini instead of GPT-4o?
Because the safety does not live in the model. Once hard constraints, per-condition rule sets, and structured outputs carry the safety load, the model’s job shrinks to language competence inside a bounded space — and a mini-class model is fully capable of that at a fraction of frontier cost.
The economics decide it. Model a patient’s full month across all thirteen modules, covering plans, chats, menu photos and scans, and at OpenAI’s published GPT-4o mini rates of $0.15 per million input tokens and $0.60 per million output, the bill lands under a quarter. The entire patient panel runs for less per month than a single staff hour. GPT-4o is listed at $2.50 and $10.00 for the same tokens, so the identical workload costs roughly sixteen times more and buys eloquence the templates already make unnecessary.
The ROI arithmetic for the practice sits on the other side of that number: inference at cents per patient-month, set against the two costs it offsets — front-desk time spent answering food questions, and rescheduled procedures, where every avoided reschedule protects a procedure slot that a US practice cannot easily refill at short notice. The spend and the offset are not in the same unit class.
Where the small model strains — rare multi-constraint collisions, genuinely ambiguous ingredients — the system compensates by design: tighter templates, and the ask-your-care-team fallback.
“Pick the model after you’ve decided where the safety lives. If the answer is ‘in the model,’ start over.”
Data handling and compliance
Everything the app personalizes on — diagnosis, the physician’s plan, allergies — is health information, and we architected as if that sentence were the whole spec. Deciding where the safety lives before choosing a model is the first thing our AI consulting work settles.
No identifying patient data crosses the model boundary. Personalization data lives server-side under access control, and prompt assembly strips it down to a condition profile before anything is sent: the model sees celiac disease, gluten-free and fiber-staged, vegetarian, tree nuts. It never sees a person. Identified records stay inside the practice’s own environment, prompts are assembled server-side so the client app never holds the rule logic, and no patient data is used to train any model. Consumer chatbot products are excluded from the architecture entirely — OpenAI does not sign business associate agreements for its consumer-tier ChatGPT products, which is why patient use of free chatbots was part of the problem statement.
On regulatory positioning: the app supports adherence to a plan a physician already prescribed. It does not diagnose, and it does not treat. Where a practice’s own obligations go beyond that, business associate agreements, retention schedules and audit posture, those stay with the practice and its counsel. Architecture reduces the exposure; it does not decide the regulatory question for you.
What’s running today
The app is in the hands of the practice’s patients. All thirteen modules are in production, the reminder system is running prep sequences ahead of scheduled procedures, and the Diet Chatbot’s question log has become a standing input to rule-set refinement.
What we deliberately did not claim here: adherence percentages and rescheduling deltas. The practice reports the direction is positive, but a number we have not measured is a number we will not print.
“Brainy Neurals clearly cared about the patients this was built for. Someone with a chronic condition can now check what is safe to eat in seconds, which takes real pressure off our clinicians.”
Lessons learned
The rule sets were the project.
Encoding fifteen-plus conditions into template logic a model cannot wander out of took longer than the entire app build, and physician review cycles were the critical path, not engineering. Budget for that inversion.
The real world is the edge case.
Handwritten specials boards, low-light menu photos, regional dish names, products Open Food Facts has never seen. We stopped treating these as accuracy failures and started designing for them: confidence thresholds, and an honest can’t-verify answer instead of a guess. An unverifiable answer delivered confidently is the only true failure state this product has.
Small models need structure, not encouragement.
Free-form generation invited drift; strict output schemas removed it — the same validation-layer discipline that made our text-to-CAD floor plan system trustworthy. Most of our safety wins came from constraining the output format, not from prompt wording.
The chatbot log is a roadmap.
Patients asked about alcohol, fasting windows, supplements, airplane food — questions no printed sheet anticipated. The question log now drives rule-set updates and told us which module to build next.
“The hard part wasn’t teaching a model medicine. It was encoding one physician’s judgment into rules the model couldn’t wander out of.”
Could this work for your patient population?
The pattern ports to any specialty where a clinician prescribes a plan patients must execute daily without supervision. Nephrology is the most direct fit — renal diets are numeric rule sets, potassium and phosphorus and sodium ceilings, and they template cleanly. Endocrinology and diabetes management, bariatric pre- and post-op protocols, and oncology nutrition during treatment all share the shape: a physician-owned rule set, a patient making twenty unsupervised food decisions a week, and a liability bar that rules out unconstrained AI.
What porting takes: the clinician’s rule sets in reviewable form, four constraints’ worth of patient intake, roughly the same integration surface — a food-data source, ordering, notifications — and the discipline to keep the model inside the box. For EU deployments the architecture holds under GDPR, with data-residency and consent adjustments in place of the US framing. As with every engagement we run, the client owns 100% of the IP at handover: every line of code, every prompt template, every rule set.
If you run a specialty practice or a digital-health product with this shape, the scoping conversation is short, and it usually starts as a four-to-six week proof of concept. The pattern is proven; the variable is your rule sets.
Where this goes next
The single-practice build is the template for the multi-clinic version. The engine, the constraint architecture, and the module surfaces stay fixed; each practice brings its own physician-reviewed rule sets and its own branding. That is a SaaS shape, per-practice configuration over shared and hardened infrastructure, and the build was scoped so that step does not require starting again. For the next specialty, the first question will not be whether AI can do this. It will be whose rules it is running.
Where are you in the journey?
Frequently asked questions
Is ChatGPT HIPAA compliant for patient-facing apps?
Consumer ChatGPT is not HIPAA compliant: OpenAI does not sign business associate agreements for its free or subscription chat products, so protected health information cannot lawfully move through them. Compliant paths exist at the platform level — API use under a signed BAA, or architectures that de-identify data before it reaches the model. This build takes the second path and excludes consumer chat products entirely: the backend reduces each request to a condition profile before any call is made, so nothing identifying reaches the model.
Can AI safely create meal plans for medical conditions like celiac disease?
Yes, when generation is constrained — and only then. Safe means the system enforces the diagnosis, the physician’s plan, and the allergy list on every response, rather than trusting a general model’s training. For celiac disease (spelled coeliac in the UK and Australia), gluten exclusion is a hard rule the model cannot override, not a preference it usually remembers. Unconstrained chatbots do not clear this bar.
How much does it cost to build an AI diet app?
For a build of this scope — a cross-platform app, a constrained LLM core, multimodal verification, and third-party integrations — expect a low-six-figure engagement, with module count, integration surface, and compliance scope as the main drivers. Running cost surprises in the other direction: on GPT-4o mini, inference lands at cents per patient-month at published token rates, so growth does not punish the clinic.
Can AI read a restaurant menu for allergens and diet restrictions?
Yes. Multimodal models read photographed menus, extract dishes and likely ingredients, and evaluate each against a patient’s restrictions, returning eat, avoid, or modify verdicts with reasons. The accuracy limits are physical rather than conceptual: handwriting, poor lighting, unlisted preparation details. A production system handles those with confidence thresholds and an explicit can’t-verify answer instead of a guess.
Is an AI diet app a medical device?
It depends on the claims the software makes, not the technology it uses. An app that supports adherence to a diet a physician already prescribed — without diagnosing conditions or directing treatment — sits differently under FDA software guidance than one that makes clinical decisions. Note that the general-wellness carve-out is narrow: guidance updated in January 2026 keeps disease-specific claims outside it, so condition-linked software of this kind needs a positioning review rather than an assumption. This build supports a prescribed plan and refers uncertainty back to the care team. Regulatory posture should be reviewed per product and per market.
Which digestive conditions can an AI diet assistant support?
Any condition whose dietary protocol can be written down and reviewed. This deployment covers more than fifteen, including celiac disease, Crohn’s disease, IBS, cirrhosis, and chronic constipation, each with its own rule set. The practical boundary is not the AI; it is whether a clinician can express the protocol as reviewable rules. If yes, it templates. More deployments across problem shapes live on our case studies hub.