Remote patient nutrition monitoring that doesn't depend on a call to check in
RPM programs stream vitals continuously; dietary intake has been the exception. BiteQ measures nutrition automatically as a patient eats and syncs it between visits.
Why is nutrition data missing from remote patient monitoring?
A load cell in the handle weighs each bite, an embedded camera identifies the food, and a motion sensor tracks eating pace, so calories, macronutrients, micronutrients and eating behavior are measured as the patient eats rather than recalled at the next appointment.
Remote patient monitoring has matured for vitals: blood pressure cuffs, glucose meters and connected scales all stream data to a care team between appointments, without the patient having to remember or report anything. Dietary intake has been the exception. It has stayed dependent on recall, either a food diary filled out inconsistently or a patient's memory of the last few days at the start of an appointment.
That gap matters because nutrition is often the variable a care plan is actually trying to change, and it's the one with the weakest data behind it. A care team can see a glucose trend line update daily, then have to reconstruct dietary intake from a conversation that depends entirely on what the patient remembers and chooses to report.
BiteQ is built to close that specific gap. The smart spoon and fork measure calories, macronutrients and micronutrients automatically, alongside eating pace and other behavior signals, the same way a connected vitals device measures blood pressure, so nutrition can join the rest of the RPM data stream instead of remaining the one input still reconstructed from memory. It's part of the same shift toward measured, not self-reported, nutrition data that we're bringing to care teams generally.
BiteQ is a measurement and feedback tool, not a medical device. It does not diagnose, treat or replace clinical judgment, and it is not a substitute for the monitoring devices already prescribed as part of a patient's care.
What does a continuous nutrition signal add to an RPM program?
The same measurement that helps an individual user applies directly to a monitored care population.
Data between visits, not just at them
Meals are measured and synced continuously, giving a care team a nutrition trend line instead of a single data point reconstructed at the next appointment.
Objective, not recalled
Calories, macronutrients and portion size come from a sensor reading at the moment of eating, removing the recall-accuracy problem inherent to patient-reported dietary logs.
Built for deployment
Dishwasher-free hand care, a pogo-pin charging dock and Bluetooth LE sync are designed to suit a monitored population and a clinical support workflow, not just an individual consumer.
Continuous
Nutrition data joins vitals as an always-on signal, not a per-visit recall
Per bite
Resolution of measurement, not a once-a-day or once-a-visit summary
Zero logging
Required from the patient for the data to be captured
Who is this built for?
This is built for the teams and programs where between-visit dietary data is the missing piece.
01
RPM program operators adding a dietary signal to an existing vitals-monitoring stack. Where nutrition has been the one input still dependent on patient recall.
02
Care teams managing chronic conditions with a dietary component, such as diabetes. Who need consistent intake data between appointments, not just a conversation at the start of one.
03
Telehealth providers building out remote monitoring service lines. Looking for a measured data source that doesn't add a logging task to the patient's day.
04
Patients who struggle with manual food diaries between appointments. Whether from time, memory, or simply the friction of writing every meal down.
How does a food diary compare to a continuous sensor feed?
What the RPM program gets
Between-visit food diary
BiteQ sensor feed
Data exists only if
Between-visit food diaryThe patient remembers to write it down
BiteQ sensor feedThe utensil is used for the meal
Portion figure
Between-visit food diaryRecreated from memory
BiteQ sensor feedWeighed per bite
Known bias
Between-visit food diaryUnder-reports intake, more so the longer the gap
BiteQ sensor feedSensor reading rather than recall
Consistency with other RPM data
Between-visit food diarySelf-reported, unlike the vitals stream
BiteQ sensor feedMeasured, like the vitals already collected
Patient effort between visits
Between-visit food diaryA daily writing task
BiteQ sensor feedNone beyond eating
A between-visit food diary depends on the patient remembering to fill it out consistently, and depends on their memory being accurate when they do. Both are well-documented weak points: diaries are filled in inconsistently, and recreated meals from memory are known to undercount true intake, especially the longer the gap since the meal.
BiteQ removes both dependencies. The utensil measures the meal as it's eaten, so the data exists whether or not the patient thought to write anything down, and it reflects a sensor reading rather than a reconstructed memory. That shifts nutrition from the least reliable input in a remote monitoring program to one measured the same way as the vitals data already being collected, using the same sensor-and-AI approach described on our data & AI page.
Frequently asked questions about remote patient nutrition monitoring
Is BiteQ a medical device?
Does BiteQ integrate with existing RPM or EHR platforms?
How is patient data shared with the care team?
Does this replace clinical judgment or existing monitoring devices?