Method, device and system for monitoring cooking activity

Abstract

One aspect concerns a method for monitoring cooking activity carried out by a device comprising a processor, comprising: - obtaining (201) time series data from one or more sensors (102_i, 103, 104) configured to monitor the use of one or more appliances (101_J) for meal preparation; - obtaining (202_2) a plurality of cooking activity signatures, wherein a cooking activity signature identifies a meal type as a function of the time series sensor data; - determining (202_3) a probability of preparation of a meal type associated with a given cooking activity signature responsive to a match of the given cooking activity signature with the time series sensor data; - generating (202_4) a signal function of at least one determined meal type.

Description

METHOD, DEVICE AND SYSTEM FOR MONITORING COOKING ACTIVITYTECHNICAL FIELD

[0001] A method, device and system for monitoring cooking activity is described. The method, device and system are particularly adapted for monitoring the cooking activity of an individual in the context of monitoring a health status of this individual.BACKGROUND

[0002] Cooking can be considered an important determinant of an individual’s wellbeing, and monitoring cooking activities can provide an insight of people’s health status. A reduction in cooking activity may be indicative of a deteriorating medical condition or worsening frailty. In particular elderly people may gradually lose the ability to cook, which may cause an acceleration of the deterioration of their health status. At present, clinicians and caregivers monitor cooking only to a limited extent for many patients, and this monitoring is often based on patent self-reporting, which may be inaccurate.

[0003] It is desirable to provide a solution that allows monitoring of cooking activity in a more effective way.SUMMARYA first aspect concerns a method for monitoring cooking activity carried out by a device comprising a processor, comprising:- obtaining time series data from one or more sensors configured to monitor the use of one or more appliances for meal preparation;- obtaining a plurality of cooking activity signatures, wherein a cooking activity signature identifies a meal type as a function of the time series sensor data;- determining a probability of preparation of a meal type associated with a given cooking activity signature responsive to a match of the given cooking activity signature with the time series sensor data;- generating a signal function of at least one determined meal type.According to one or more embodiments, the one or more sensors are configured to measure physical quantities associated with the use of the one or more appliances, wherein the physical quantities are representative of one or more among: a type of energy used to power an appliance; a measurable resource used in meal preparation; a measurable physical phenomenon generated by the use of an appliance.According to one or more embodiments, generating a signal comprises obtaining a meal health signature for each meal type, generating a health score as a function of the determination of preparation of one or more meal types, respective probabilities of each meal type preparation and respective meal health signatures.According to one or more embodiments, a given cooking activity signature is representative of the temporal evolution of time series data of a plurality of sensors.According to one or more embodiments, the method further comprises: determining a change in cooking activity frequency as a function of the signal; generating an alert if said change is indicative of a reduction in cooking activity beyond a threshold.As described, the invention uses ambient sensing to monitor the frequency and inferred quality of meal preparation. It allows providing data-driven recommendations for nutritional improvement to caregivers.Another aspect concerns a device comprising a processor and memory storing software code, wherein the processor, when executing the software code, causes the device to carry out one of the methods described herein.Another aspect concerns a system comprising:one or more appliances configured for meal preparation; one or more sensors configured to monitor the use of the one or more appliances and configured to generate time series data indicative of the use of the one or more appliances; a device for processing the sensor data as described herein.BRIEF DESCRIPTION OF THE DRAWINGS

[0004] Example embodiments will be more fully understood from the detailed description provided herein and the accompanying drawings, which are given by way of illustration only.Fig. 1 is a schematic representation of a system according to one or more exemplary embodiments;Fig. 2 is a flow chart of a process according to one or more exemplary embodiments.DETAILED DESCRIPTION

[0005] Various exemplary embodiments will now be described more fully with reference to the accompanying drawings. However, specific structural and functional details disclosed herein are merely representative for purposes of describing example embodiments. The exemplary embodiments may be embodied in many alternate forms and should not be construed as limited to only the embodiments set forth herein. It should be understood that there is no intent to limit example embodiments to the particular forms disclosed.

[0006] It should be appreciated by those skilled in the art that any functions, engines, block diagrams, flow diagrams, state transition diagrams, message sequence charts and / or flowcharts herein represent conceptual views of illustrative circuitry embodying the principles of the exemplary embodiments. Functions, actions or steps described herein can be implemented in hardware or software or any combination thereof, and ordering of these functions, actions or steps may be different from that presented. If implemented in software, the functions, blocks of the block diagrams and / or flowchart illustrations can be implementede.g. using software code executed by a processor or a processing device.

[0007] In the present description, functional blocks denoted as “means configured to perform ...” a certain function are to be understood as functional blocks comprising circuitry that is adapted for performing or configured to perform a certain function. Moreover, any entity described herein as “means”, may be implemented as one or more distinct entities or within an entity providing additional functions. When provided by a processor, the functions may be provided by a single processor or several processors. Moreover, the term “processor” includes one or more of a digital signal processor, remote processor, graphical processing units (‘GPUs’), dedicated or generic circuitry, read only memory for storing software, random access memory, and non-volatile storage.

[0008] According to one or more exemplary embodiments, a system comprises a plurality of sensors for acquiring time series data of various physical quantities associated with the use of appliances employed in cooking activities. The physical quantities may concern:- the use of energy (including fuel) necessary to power certain appliances, (e.g. electricity or gas);- use of kitchen resources used in meal preparation, such as water (e.g. for boiling food, as an ingredient, and also for the preparation of drinks); physical phenomena generated by the use of an appliance (e.g. the generation of heat, humidity...).A sensor may be associated with a single appliance (e.g. a smart plug, as described below), or with several appliances (e.g. a heat sensitive camera, as described below). Also, the use of a given appliance may be monitored using a single sensor or a combination of sensors. E.g. the use of a stove can be monitored based on its electricity consumption, as well as the heat and the humidity generated. Use of an appliance (‘event’) at a given instant in time can be characterized by a binary value (‘on’ or ‘off) or by a probability value. Patterns in the time series data - whether from one sensor or several sensors considered in combination - are associated with certain events (e.g. heat of a microwave oven is detected once the door of the oven is opened, but not necessarily before). In other words, the relative chronology of information in the time series data can be used to characterize events.According to one or more embodiments, a database of cooking activity signatures is implemented. A cooking activity signature is a pattern of appliance use associated with a meal. It may concern one or more appliances and possibly the intensity of such use. A cooking activity signature can be derived in various ways based on resources including recipe books, meal cooking instructions... Cooking activity signatures are matched with data derived from the sensor time series data to determine which meals were prepared, and of which type. This determination may yield a probability of preparation of one or more meal types.According to one or more embodiments, a meal health signature can be associated with a meal type, based on the same resources as those based on which the cooking activity signatures were derived from. A meal health signature may be a simple indicator on a healthiness scale, or a more complex vector of various parameter characterizing a meal (calories, fat contents, saturated fat contents, fiber, salt etc. . .). Based on the identified meal types and the meal health signatures (and possibly on the probabilities associated with the identified meal types), a health score can be determined. The health score can be used in various ways to help caretakers and clinicians in their work.

[0009] Fig. 1 is a block diagram of premises 100 with appliances and resources used for meal preparation, e.g. a kitchen, according to one or more embodiments. The kitchen of Fig. 1 comprises up to M appliances lOli. Appliances can for example include one or more among a conventional oven, a microwave oven, a toaster, a coffee blender, a kettle and other appliances that are powered using the mains electrical power grid and are relevant in the frame of an activity in the kitchen.

[0010] An appliance can be associated lOli with a respective resource usage sensor 102i, for providing time series data on the usage of a resource such as electricity or gas. For appliances using electricity, a so-called smart socket can be used. For appliances using gas, a gas flow sensor can be used.

[0011] Not all appliances are necessarily equipped with a specific sensor measuring an energy resource being consumed, i.e. use of such appliances may be derived from other sensors. For that purpose, system 100 may also comprise additional sensors, such as one or more a temperature sensors 103 and one or more humidity sensors 104. The use of an appliance may be derived from its associated resource usage sensor, one or more additional sensors such astemperature and humidity sensors, or from both a resource usage sensor and one or more additional sensors, as described in more detail below. Use of several sensors per appliance allows e.g. to limit the impact of incorrect data from one of the sensors.

[0012] According to a variant embodiment, a sensor may provide resource consumption data for more than one appliance, i.e. consumption data is aggregated. E.g. a single smart socket can be used to monitor power usage by several appliances. Various techniques can then be applied to carry out load disaggregation, i.e. to associate a resource consumption with an individual appliance. E.g. for disaggregation of electrical loads, techniques described in WO2023 / 138785 or WO2023 / 179836 may be used. For disaggregation of water usage, techniques described in PCT / EP2023 / 057673 may be used.

[0013] According to one or more embodiments, there is at least one sensor in the system collecting data for an appliance to be monitored.

[0014] The various sensors communicate with a processing device 105. The processing device is configured to collect the data from the sensors and to store this data for analysis as described herein. For example, processing device comprises a communication interface 106 for that purpose. Processing device 105 further comprises at least a processor 107, permanent memory 108 and working memory 109. Memory 108 is a non-transitory storage medium. E.g. memory 108 can be ROM or flash memory and contains software code. Memory 108 may be detachable, e.g under the form of a USB stick, SD card or PCMCIA card. Memory 109 is for example RAM. While in the non-limiting example of Fig. 1, processing device receives all sensor input and processes it as described below, sensor data collection and processing may be carried out by several distinct devices. Processing may for example be carried out by a remote server accessing sensor data stored in one or more data storage devices (not illustrated).

[0015] In what follows, an ‘event’ refers to usage of an appliance. For example, in the case of a microwave oven, an event comprises the time interval during which the microwave oven is continuously switched on. The term "type of event" designates the appliance an event is associated with, e.g. kettle, microwave oven etc... For each type of event (e.g. kettle), zero, one or more events can be detected throughout a day.

[0016] According to some embodiments and as further described below, certain data occurring after an event can be useful for identifying the type of event. For example, heat canbe detected after the door of the microwave oven has been opened - this can happen after the event is finished (e.g. the microwave oven is off), yet it helps determining that an event took place and also identifying the type of event.

[0017] Fig. 2 is a flowchart of an overall process for carrying out an analysis of the sensor data according to one or more non-limiting embodiments. The process of figure 2 comprises four subprocesses, respectively called sensor data analysis (201), meal quality analysis (202), change detection (203) and clinical decision support (204). The output of one subprocess is used as input for the subsequent subprocess. Step i within a subprocess 20x is labelled 20x_i in the flowchart.

[0018] The first subprocess (201) concerns sensor data analysis. The input to this step is the time series data from the various sensors. The output of this step comprises, for each type of sensor, an identification of zero or more events occurring as a function of time. For example, the output data allows to determine for every data point in the time series data, whether an appliance is classified as "on" or "off, i.e. "event" or "no event". E.g. the output can have the form of an array per sensor and per timestamp, where the array comprises N values, each of which concerns a given appliance.

[0019] According to a variant embodiment, depending on the type of sensor, the information as to whether a data point corresponds to an event is provided as a probability of an event happening or in a binary manner.

[0020] According to the present embodiment, sensor data analysis comprises a separate analysis for each sensor type. As several sensors may provide data concerning a same appliance, data from distinct sensors covering same event may be considered in parallel in other steps of the present process.

[0021] Steps within subprocess 201 depend on the types of sensors providing time series data. I.e. steps are implemented as a function of at least one corresponding sensor being present or time series data being available from at least one corresponding sensor.

[0022] In step 201 1, data provided by electrical energy sensors is processed. Such a sensor monitors e.g. voltage, current and / or power. Sensor data may be provided as time seriesdata samples, i.e. timestamped data samples, at a frequency depending on the sensor. E.g. a sampling rate between 0.1 Hz to 1MHz or higher can be used. The output of this step can be a matrix of timestamps indicating when particular appliances were switched on and off (or a corresponding probability when considering the variant embodiment mentioned earlier). Probabilities can be determined using a Factorial Hidden Markov Model or a deep learning model such as an autoencoder.

[0023] In step 201 2, data provided by temperature sensors is processed. One or more such sensors may be provided. A sensor may provide a temperature at a specific location, or it may provide temperature for an area. A sensor providing temperature at a given location can be a digital thermometer. The location of such a sensor in the kitchen is known. A sensor providing temperature for an area may be a heat sensitive camera adequately positioned to provide an image of heat-generating appliances in the kitchen.

[0024] According to one embodiment, the kitchen area is represented as a two- dimensional spatial grid and this grid is used to map the output of each sensor. Each kitchen appliance is assigned a two-dimensional coordinate in the grid, and this facilitates sensor fusion in step 202 by identifying the temperature proximal to each appliance. For a given heat sensor, the grid can for example comprise binary values indicating whether the temperature at a particular location is below or above a given threshold as a function of time, based on the time series data for a given sensor. Temperature data may also be expressed as a continuous variable within a specified range, or represented as an ordinal variable, e.g. with three or more levels of heat.

[0025] The two-dimension grid is translated into probability distributions. E.g. each grid point is associated with an array of probabilities between 0 and 1. Each element of an array represents the naive probability of a particular appliance being off or on, or of an appliance status (e.g. ‘door open’), based on its heat signature. For example, the array contains probabilities for ‘kettle on’, ‘stove on’, ‘oven opened’.

[0026] In step 201 3, data provided by other sensors, if any, is processed.

[0027] One or more hygrometers can be used for monitoring humidity (e.g. in ml per cubic centimeter). A single hygrometer can be placed in the kitchen or multiple hygrometers can be placed around the kitchen area. E.g. a hygrometer can be placed over a single givenappliance, such as the stove, to specifically monitor humidity associated with this appliance being used. In case multiple humidity sensors are used, humidity can be estimated for individual appliances as a function of these multiple sensors. E.g. if Humidity Sensor #1 is located near the kettle, the data for this sensor is assigned to the kettle. If the stove is located e.g. 1 meter from Humidity Sensor 1, and is 2 meters from Humidity Sensor 2, then the humidity for the stove can be determined e.g. as a simple function of the output of the two sensors, e.g. a linear combination of the sensor outputs as a function of the respective distances between the appliance and the two sensors.

[0028] A water flow sensor can be used to quantify the volume of water used. Data can be expressed in volume per time unit, e.g. in gallons per minute. For the purpose of providing a numerical illustrative example, the sampling rate may for example be of one second. The water flow sensor may be positioned to detect volume for a given fixture (e.g. the kitchen sink). Alternatively, in some embodiments, the sensor may measure the aggregate flow for the entire home, with disaggregation being performed, as described above.

[0029] A gas flow sensor can be used to measure the volume of gas flowing through a cooker or stove. The output of the data processing is similar to that of a smart socket, i.e. a binary output indicating whether the cooker is on or not, as a function of time.

[0030] In step 201 4, the processed output of the various sensors is stored in a database. The database may be stored in memory 109 or in a long term storage unit such as a local or remote server (not illustrated).

[0031] The second subprocess (202) analyzes the events detected in the first subprocess. The output of the second subprocess is a score representative of the detected cooking activity as a function of the respective probabilities of certain meals having been prepared.

[0032] In step 202 1, time series data from several sensors is considered in a combined fashion (‘sensor fusion’). In case the sampling rate differs between the different sensors, the output data from the previous subprocess is first temporally aligned in a fashion know per se (e.g through linear or polynomial interpolation or other techniques) to adapt the sampling rate, as needed and obtain data at the same timestamps. Sensor fusion enables taking into accountarrays from subprocess 201 that contain conflicting information. E.g. electrical data may indicate a probable use of appliance X but this is ruled out by another array (e.g. the pattern of humidity or temperature data).

[0033] Output of several sensors is considered in a combined fashion in order to detect temporal patterns associated with certain types of events. It is to be noted that patterns can also be associated with a single sensor.

[0034] For example, a toaster generates heat and consumes electricity, but does not generate humidity. Thus, depending on the implementation, up to three different sensor types can be considered in a combined fashion in order to detect an event of the type ‘toaster’.

[0035] Another example is a microwave oven, which consumed electricity, but for which heat is not detected during the cooking process, until the microwave oven door is open. After the microwave has finished the cooking process and food is removed, a heat increase can be detected, potentially associated with a change in humidity. Depending on the implementation, up to three sensor types can be considered for detecting an event of the type ‘microwave oven’.

[0036] Yet another example concerns a kettle. A kettle generates heat and humidity and has a characteristic electricity consumption signature.

[0037] According to one exemplary embodiment, a Convolutional Neural Network (CNN) is used to accomplish sensor combination. The CNN may be a one-dimensional CNN. The neural network is trained on a dataset of events for appliances, e.g. kettle. This dataset can be generated by manually switching appliances on, and by manually labeling 'on' and 'off times for events. Thus, the training data comprises two parts. A first part comprises the sensor data, i.e. the arrays of timestamped sensor output (one array per sensor). A second part is also timestamped and comprises arrays of labels. These labels can for example be binary to indicate that a given appliance is on or off. There is one array per appliance (e.g. one array of values for a kettle, one array for a micro wave, etc).

[0038] The network is trained using a process of gradient descent. The technique of k- fold cross validation can be used, whereby the data is segmented into 'k' number of segments, e.g. 60% of data may be training data, 20% validation data, and 20% test data can be withheld for an eventual assessment of accuracy. In k-fold cross validation, the training and validation datasets are swapped to reduce variance in the trained model. The model can be trained until itoverfits and then the optimal number of epochs can be identified. The learning rate and other hyperparameters (e.g. model architecture) can be systematically varied using grid search or similar techniques.

[0039] The output is for example a softmax array for each timestamp, although other output formats may be considered. The softmax array contains the probabilities of each event type occurring. The probability of no event occurring can also be indicated, although this probability may be implicitly derived from the event type probabilities.

[0040] E.g. assuming three appliances are present in the kitchen, probabilities may be: kettle = 0.4, toaster = 0.05, stove hob = 0.45, no event = 0.1 - where the probability of ‘no event’ complements the sum of the probabilities of the event types to 1.

[0041] Optionally, the output of this step is compressed. This can for example be achieved by eliminating timestamps at which no event occurred, e.g. if no event occurred for eight hours between 11 am and 7 pm, it is assumed that no activity took place in the kitchen and the arrays for each timestamp in this time interval may be discarded. Other data compression techniques may be used, such as recording the estimated start and end times of each event type (e.g. kettle on / off). Also, data may optionally be retained for time intervals with a significant degree of uncertainty. A user may optionally label this data in order to increase model accuracy.

[0042] According to variant exemplary embodiment, an ensemble-based approach combining on one hand an expert rule-based approach and deep learning models that learn the likelihood of events occurring, their duration their mapping to cooking appliances is implemented. The rule-based system learns general cooking rules or facts, such as meal time preparation for specific dishes or types of meals, or the use of specific ingredients. Instead of training a model on example data, the model will learn from training based on rules. Other approaches that may be implemented rely on link prediction based on graph embedding, or semantic reasoning based on knowledge graphs.

[0043] In step 202_2, meal health signatures and cooking activity signatures are obtained, e.g. from a database (not shown). According to one embodiment, signatures in thedatabase are programmed manually. According to another embodiment, signatures in the database are obtained automatically through natural language processing (NLP) analysis of text documents. Such documents include cookbooks and online database of recipes, as well as cooking instructions for less complex meals, such as on food packaging (e.g. microwave pizza, instant noodles...). A cooking activity signature can be expressed as time series data, with a number of arrays per timestamp. A cooking activity signature can be obtained by extracting information such as preparation time, types of appliances used, cooking temperature. . . A health signature is based on nutritional information derived from a list of ingredients, explicit nutritional information provided or an overall health score of a meal. A cooking activity signature and a health signature for a same meal type are linked in the database, such that when a cooking activity signature is found in the sensor data, a corresponding meal type is identified.

[0044] An example recipe for the extracting of a cooking activity signature and a health signature is provided in table 1 and the text below the table. This recipe contains data on typical nutritional values per serving, i.e. kcal, overall fat, saturated fat, carbohydrates, sugars, fibre, protein, salt. The data can be automatically extracted from the recipe using a neural network such as decoder-only architecture large language model. In the specific example recipe, no detailed analysis of the ingredients is necessary.

[0045] According to one embodiment, a meal health signature is mapped to a meal health score. The health score provides a standardized format for evaluating healthiness, e.g. in the form of predefined categories. E.g. in the above example, the nutritional values may be compared to value ranges for assigning a health score between 1 (or ‘A’) and 5 (or ('E’), with 1 (or ‘A’) representing a very healthy meal and 5 (or ‘E’ Representing a rather unhealthy meal. The score may of course be represented differently, e.g. by a set of labels such as ‘healthy’, ‘dubious’ etc., or by a set of colors (e.g. red, orange, green).

[0046] From the same source, data relating to the cooking activity signature is as follows:- "saucepan on a medium heat. . . fry for 10 minutes”;- "reduce the heat... fry for 10 minutes";- "increase the heat to medium -high... for 3-4 minutes";- “reduce heat ... for 1 hour and 15 minutes”.

[0047] The cooking activity signature data can be extracted using the same type of model as the meal health signature (i.e. a decoder-only architecture) but with prompt engineering to extract the relevant pieces of information (such as appliance type, heat level, duration). Prompt engineering refers to the process of designing, testing and implementing text prompts for large language models. The energy signature can be obtained by translating the heat levels into power for a stove hob. The humidity signature can be obtained based on low levels of humidity during the initial frying phases of the sauce preparation, and medium levels during the simmering phase and high levels during pasta cooking. The resultant cooking activity signature is then expressed as time series data, with a number of arrays per timestamp. One array for energy comprises units of watts. A second array comprises heat (e.g. time series of temperature values). A third array comprises estimated humidity levels. Optionally, these arrays can associate a probability with a bounded value range, with a probability indicating the probability that the true value lies within the bounded range.

[0048] Example recipe: Spaghetti Bolognese, for six people.Table 1

[0049] Ingredients: “1 tbsp olive oil; 4 slices of bacon, finely chopped; 2 medium onions, finely chopped; 2 carrots, trimmed and finely chopped; 2 celery sticks, finely chopped; 2 garlic cloves finely chopped; 500g beef; 800g canned tomatoes; a handful of basil leaves; 1 Input data for autoencoder: the "event type" time-series data based on sensors (e.g. oven, micro wave).

[0050] Preparation: “Put a large saucepan on the stove, on medium heat, and add 1 tbsp olive oil. Add chopped bacon and fry for 10 minutes. Reduce the heat and add the onions, carrots, celery sticks and garlic. Fry for 10 mins. Increase the heat to medium-high, add beef and cook for 3-4 minutes. Add tomatoes, basil, oregano, bay leaves, tomato puree, beef stock and red wine. Bring to the boil, reduce heat and let simmer for 1 hour and 15 minutes. Cook 400g spaghetti for 8 minutes in salted boiling water. Drain spaghetti, service with sauce and with grated parmesan cheese.”

[0051] In step 202 3, one or more meal types corresponding to the sensor data are determined. The input to this step includes the output of the sensor data fusion step 202 1, as well as the cooking activity signatures and meal health signatures of step 202-2. A mapping of the sensor data to the cooking activity signatures is carried out. A match indicates a meal type (or several meal types) with an associated probability of occurrence. According to one embodiment, the matching is for example carried out using an autoencoder neural network architecture. Based on a meal type, a corresponding meal health signature can be readily obtained.

[0052] In step 202 4, a summary score is determined. The input to this step comprises the meal type or types determined in the previous step, along with their respective probabilities of occurrence. For example, the input may be as follows: microwave dinner (2% probability), roast meat with vegetables (70% probability), boiled vegetables with oven cooked pie (28% probability). A summary health score is determined based on the health signatures corresponding to the meal types and their probabilities. For example, a linear combination of the meal health signatures can be obtained, with the probabilities being used as weighting coefficients.

[0053] The third subprocess (203) concerns sensor data analysis.

[0054] In a first step (203 1), statistical trends in cooking activity are established. The time-series of meal types Based on the output of the previous step, the time-series of meal types can be mapped to a corresponding "health score" time-series. This time series is then characterized using metrics such as mean, standard deviation, percentiles and cyclical patterns. Weekdays may be considered separately from weekends, since activity may differ. The time of the year may be taken into consideration.

[0055] In a second step (203 2), thresholds are obtained for the metrics. Thresholds may be stored in memory 109. Thresholds can for example be determined using a statistical approach for the individual under observation (e.g. based on a certain percentile value, a probability of occurrence...). Alternatively, a threshold can be based on a learned probability of adverse events or clinically significant change, for example based on a learning system using outcomes of interest for a comparable cohort of patients, such as predictive models for outcomes such as hospitalization, mortality, or events such as myocardial infarction, stroke and falls resulting in injury.

[0056] In a third step (203 3), as data is collected by processing device 105, the metrics for the new data are compared to corresponding thresholds. A change is identified when a threshold is exceeded.

[0057] The fourth subprocess (203) concerns clinical decision support and uses as input the changes detected by the previous step. Such changes may be processed as described by the processing device 105, or may be transmitted for processing by remote devices, e.g. devices

[0058] In a first step (204 1), the clinical significance of a change is determined.The clinical significance of a change can for example be based on the estimated change in caloric intake and the nutritional value of prepared meals. Alternatively, clinical significance can be derived from statistical correlation of changes and health status.

[0059] In a second step (204 2), an individual intervention strategy is determined, as a function of one or more changes identified in the previous subprocess. An individual intervention strategy comprises at least one action responsive to the clinical significance of a change. An individual intervention strategy can include meal delivery services if a patient is incapacitated, home help, home delivery of ingredients, or supplementation with certain foodtypes or ingredients.

[0060] In a third step (204 3), clinical decision support information is provided. The purpose of this information is to help clinicians make better decisions for monitored individuals. Decision support information can help reduce the cognitive burden on clinicians and improve outcomes.The information output by the processing device 105 - whether an identified change, the clinical significance thereof, or any of the input and output data of other subprocesses and steps - can be displayed or otherwise provided to a care professional by integration with existing electronic health record management systems. Such systems may be located in hospitals, with primary care providers or other healthcare providers. The interfaces to such systems may be configured according to an established standard such as the ‘Fast Healthcare Interoperability Resource’ standard. Data can be coded according to various formats, e.g. JSON, XML, RDF, and be transmitted via web-based protocols. The processing device - or a system it provides information to - may recommend patient counselling. For example, a conversation with the monitored individual can be suggested, in order to better understand their cooking activity pattern. A list of key items to discuss can be generated. Clinical decision support can be integrated into a clinical workflow, but may also comprise a standalone application. The clinical decision support may comprise an alert with a recommended course of action. Clinical decision support may also comprise automated ordering of investigative tests to monitor nutritional status with results subsequently shared with clinicians. E.g. Monitored individuals can be classified using a simple traffic light system. For example, a "red" category is assigned to individuals requiring most urgent follow-up, e.g. a phone call or visit from a nutritionist, based on the clinical significance that was detected for a change. Individuals in "orange" and "green" categories have lower priority levels. This traffic light system is one example of a simple tool used for population health management. Patients with an abrupt change in eating habits (e.g. a statistically significant reduction in 'healthy meals' cooked using a stove or oven), or a gradual longer-term change in habits, can be allocated to a higher risk category.

Claims

CLAIMS A method for monitoring cooking activity carried out by a device (105) comprising a processor, comprising:- obtaining (201) time series data from one or more sensors (102_i, 103, 104) configured to monitor the use of one or more appliances (101 J) for meal preparation;- obtaining (202_2) a plurality of cooking activity signatures, wherein a cooking activity signature identifies a meal type as a function of the time series sensor data;- determining (202 3) a probability of preparation of a meal type associated with a given cooking activity signature responsive to a match of the given cooking activity signature with the time series sensor data;- generating (202 4) a signal function of at least one determined meal type.

2. The method according to claim 1, wherein the one or more sensors are configured to measure physical quantities associated with the use of the one or more appliances, wherein the physical quantities are representative of one or more among: a type of energy used to power an appliance; a measurable resource used in meal preparation; a measurable physical phenomenon generated by the use of an appliance.

3. The method of one of the claims 1 or 2, wherein generating a signal comprises obtaining a meal health signature for each meal type, generating a health score as a function of the determination of preparation of one or more meal types, respective probabilities of each meal type preparation and respective meal health signatures.

4. The method according to one of the claims 1 to 3, wherein a given cooking activity signature is representative of the temporal evolution of time series data of a plurality of sensors.

5. The method according to one of the claims 1 to 4, further comprising: determining a change in cooking activity frequency as a function of the signal; generating an alert if said change is indicative of a reduction in cooking activity beyonda threshold.

6. Device (105) comprising a processor and memory storing software code, wherein the processor, when executing the software code, causes the device to carry out the method according to one of the claims 1 to 5.

7. A system (100) comprising: one or more appliances (101 J) configured for meal preparation; one or more sensors ( 102_i, 103, 104) configured to monitor the use of the one or more appliances and configured to generate time series data indicative of the use of the one or more appliances; a device (105) according to claim 6.

Images