Epic integration for patient meal planning
Foodzilla runs as a SMART on FHIR app inside Epic. A clinician opens it from the patient's chart, and the demographics, allergies, problem list, vitals and laboratory results they need are already mapped into the meal planner.
Nothing travels the other way. The app reads from Epic and writes nothing to the patient record, which is usually the first question your Epic team will ask.
Epic patient chart
A clinician launches Foodzilla from the activity menu.
Foodzilla meal plan
Mapped into the client record, ready to plan against.
What is the Foodzilla Epic integration?
It is a SMART on FHIR application, built and registered for your Epic environment, that opens from within Epic and reads the clinical data a dietitian needs to plan a patient's food. We follow Epic's own guidance for how a third-party app launches, authorises and asks for data.
The point is to remove the retyping. Without it, a dietitian reads the chart on one screen and keys height, weight, allergies and diagnoses into a nutrition tool on another, which is slow and is where mistakes get in. With it, the plan starts from the record.
- What it is
- A SMART on FHIR app, built and registered for your Epic environment.
- What it reads
- Demographics, allergies, problem list, vitals and laboratory results.
- What it writes
- Nothing. There is no write-back to the patient record.
- Which plan
- Enterprise, delivered as a scoped project with your Epic team.
What we read, and what we do with it
Five groups of clinical data, each mapped to something the meal planner actually uses.
| Epic data | FHIR resource | What Foodzilla does with it |
|---|---|---|
| Demographics | Patient | Name, date of birth, sex and contact details fill the client record, so energy and protein targets are calculated for the right person rather than a typed guess. |
| Allergies and intolerances | AllergyIntolerance | Each substance becomes an exclusion on the account, so meal plan generation and recipe search stop returning food the patient reacts to. |
| Problem list | Condition | Active conditions set the clinical context for the plan and switch on the dietary presets your team has agreed to for that condition. |
| Vitals | Observationvital-signs | Height, weight and related measurements feed the anthropometry and the energy calculation, and give the dietitian a baseline to plan against. |
| Laboratory results | Observationlaboratory | The results your team chooses to map, such as HbA1c, lipids or renal markers, sit beside the plan so the clinician can see what they are planning around. |
We agree the mapping with your clinical team before go-live, field by field. Where Epic holds something you would rather not send to a meal planner, we leave it out.
How a clinician uses it
Nobody leaves Epic to start, and nobody types a patient's details twice.
- 1A clinician opens the patient's chart in Epic.
- 2They launch Foodzilla from the activity menu, and Epic passes the launch context.
- 3Foodzilla asks Epic for an access token using the read scopes your team approved.
- 4The five data groups are mapped into a Foodzilla client record for that patient.
- 5The clinician builds and reviews the meal plan, then shares it the way your organisation already shares patient material.
What the build covers
Written plainly so your Epic team can check it against their own list.
In scope
- SMART on FHIR application build
- App registration in your Epic environment
- EHR launch setup, so the app opens from the patient chart
- Clinical data mapping for demographics, allergies, problem list, vitals and laboratory results
- Connection testing against your non-production environment
- Mapping review and sign-off with your clinical team
Not in scope
- Write-back of any kind. Foodzilla writes nothing to the patient record
- Orders, scheduling, billing or clinical documentation in Epic
- Bulk or population-level data extracts
- Changes inside Epic itself, which stays with your Epic team
- Launching the app from outside Epic, which is separate work if you need it
Why your Epic team will sign this off
Read-only by registration
The app asks Epic for read scopes only. There are no write scopes in the registration, so a mistake on our side still cannot change a patient record.
Data moves on a clinician's action
Patient data comes across when somebody launches the app from a chart. There is no background sync and no overnight job pulling your patient list.
Non-production first
We build and test the connection against your non-production environment. Nothing touches production until your team decides it should and moves it there.
Your hosting region and paperwork
Enterprise accounts choose the AWS region their data sits in. We can complete your security questionnaire, sign a BAA, and give you a data-flow summary and our sub-processor list.
Who this is for
Hospital dietetics departments, clinical nutrition teams and health organisations running Epic that want a meal plan to start from the patient record instead of a retyped intake form.
It suits teams where dietitians already work in Epic all day and the nutrition tool is the one thing sitting outside it.
- An Epic contact who can register and approve a third-party app in your environment
- Access to your non-production environment for the build and the connection testing
- A clinician who can review the data mapping and sign it off
Epic integration questions
Related Features
Explore more tools built for nutrition professionals
Enterprise
Hosting region, client and staff limits, security documentation and integration work.
Learn moreSingle sign-on
Staff sign in with Google Workspace or Microsoft Entra ID, on your own address.
Learn moreSecurity and privacy
How we store, encrypt and separate the data you put in Foodzilla.
Learn moreHIPAA compliance
A locked-down workspace for recipes and meal plans, with no patient data in it.
Learn moreSoftware for clinics
What Foodzilla looks like in a practice with more than one clinician.
Learn moreAll integrations
Every system Foodzilla connects to, directly or through Zapier.
Learn moreScope your Epic build
Tell us which Epic environment you run, roughly how many patients and clinicians the account needs to hold, and whether you have a go-live date to work back from.