Health monitoring

Abstract

A computer-implemented method of monitoring the health of a subject within an environment using a plurality of sensors is provided. The method detects an occurrence of a health event for the subject based on data from at least one of the plurality of sensors. The method collects data relating to the health event from one or more of the plurality of sensors based on the occurrence of the health event and a type of the health event. The method provides data relating to the health event to a user.

Description

[0001] Health Monitoring

[0002] Field of the Invention

[0003] The present invention relates to health monitoring. In particular, it relates to the collection and provision of data relating to a health event for a monitored subject.

[0004] Background to the Invention

[0005] With the ongoing adoption of the so-called Internet of Things (loT), there is an ever- increasing number of different types of loT devices deployed comprising sensors that are able to provide a wide range of sensory data.

[0006] Some loT devices may comprise sensors that provide data about an environment in which they are deployed. Such sensors may be referred to as environmental or ambient sensors. For example, such sensors may measure physical properties such as temperature, humidity, atmospheric pressure, air quality, sound (such as sound levels and / or sound recordings), light (such as light levels, photographic and / or videographic recordings), vibration, motion and so on.

[0007] Some loT devices may (additionally or alternatively) provide data about a state of an associated system within the environment. For example, various loT devices (such as a smart light switch, smart power socket or smart television) may provide an indication as to whether they are currently active or not. Such devices may also be considered to be environmental or ambient sensors in so far as they provide data about the state of the environment.

[0008] Some loT devices may comprises sensors that provide data about a subject, such as a person. Such sensors may be referred to as personal or subject sensors. For example, such sensors may detect various physiological and / or behavioural properties of the subject, such as heart rate, electroencephalography (EEG), electrocardiography (ECG), body temperature, blood oxygen saturation, weight and so on. Some subject sensors may derive data about the subject by carrying out additional processing on the data received from environmental sensors. For example, a video stream may be processed to identify the subject within the video stream (e.g., using facial recognition) and may be further processed to determine a current state of that person (e.g., moving, sitting, sleeping, etc.). In some cases, at least part of this additional processing may be performed by another computer system external to the loT device that comprises the sensor. Remote patient monitoring aims to monitor a patient’s health outside of a traditional clinical setting, such as within their own homes, by using monitoring devices that can transmit health data back to a medical practitioner that is responsible for the patient’s healthcare. With changes in demographics of a population, particularly as the age distribution of a population shifts from a younger to a more ageing population, the use of technologies such as remote patient monitoring are expected to become increasingly important to fulfilling the healthcare needs of the population.

[0009] Summary of the invention

[0010] It would be desirable to make use of the increasing amount and range of data that is available from loT devices about a subject within an environment in order to improve the monitoring of their health as part of a remote patient monitoring system. In particular, it would be desirable to provide a way of collecting data from the available sensors within an environment to allow any health events experienced by the subject to be fully investigated and understood. That is to say, it would be desirable to collect any data from the environment that can provide context to a health event (i.e., data that is relevant to the health event, but not necessarily directly related to it). At the same time, it would be desirable to avoid collecting any irrelevant (or minimally relevant or less relevant) data from the environment. As will be appreciated, in some cases, it may be impractical or impossible to collect all available data due to system resource limitations (e.g., bandwidth, storage and / or processing limitations). However, even where this is not the case, the collection of superfluous (i.e., irrelevant) data may result in unnecessary consumption of limited resources which could have been better utilised for other purposes. Furthermore, collecting excessive amounts of irrelevant data can be detrimental to the privacy of the monitored subject by providing data about the subject’s actions, behaviour and / or physiology that is not necessary to provide appropriate health monitoring for the subject.

[0011] In a first aspect of the present invention, there is provided a computer-implemented method of monitoring the health of a subject within an environment using a plurality of sensors, the method comprising: detecting an occurrence of a health event for the subject based on data from at least one of the plurality of sensors; collecting data relating to the health event from one or more of the plurality of sensors based on the occurrence of the health event and a type of the health event; and providing data relating to the health event to a user. Collecting the data relating to the health event may comprise determining a window of time during which the health event occurred and collecting data from the one or more sensors that is associated with the window of time.

[0012] Collecting the data relating to the health event may comprise selecting the one or more sensors from which the data is to be collected based on their relationship to a location of the subject during the occurrence of the health event.

[0013] Collecting the data relating to the health event may comprise selecting the one or more sensors from which the data is to be collected based on a respective type of data available from each sensor, wherein the respective type of data available from each of the one or more sensors matches a predetermined type of data that is considered to be relevant to that type of health event.

[0014] The method may further comprise processing the collected data to generate processed data, wherein the data provided to the user comprises the processed data.

[0015] The data relating to the health event that is provided to the user may be derived from the collected data based on a role associated with the user.

[0016] The method may further comprise notifying the user of the occurrence of the health event.

[0017] The plurality of sensors may comprise: one or more personal sensors associated with the subject; and one or more ambient sensors associated with the environment.

[0018] The one or more sensors from which the data is collected may comprise at least one sensor that was not used to detect the occurrence of the health event.

[0019] The method may further comprise: receiving an electronic health record for the subject, the electronic health record comprising medical data about the subject, wherein the detection of the occurrence of the health event is further based on the medical data about the subject.

[0020] The type of the health event may be one of one or more types of health events indicated in the electronic health record.

[0021] The electronic health record may further indicate, for each type of health event, a respective set of predetermined types of data that are relevant to that type of health event, wherein the respective type of data available from each of the one or more sensors is a member of the set of predetermined types of data indicated by the electronic health record. Providing the collected data to the user may comprise providing a graphical reconstruction of the occurrence of the health event within a virtual representation of the subject’s environment during the occurrence of the health event based on the collected data.

[0022] In a second aspect of the present invention, there is provided a computer system comprising a processor and a memory storing computer program code for performing a method according to the first aspect.

[0023] In a third aspect of the present invention, there is provided a computer program comprising instructions which, when executed by a computer, cause the computer to carry out a method according to the first aspect.

[0024] Brief Description of the Figures

[0025] Embodiments of the present invention will now be described by way of example only, with reference to the accompanying drawings, in which:

[0026] Figure 1 is a block diagram of a computer system suitable for the operation of embodiments of the present invention.

[0027] Figure 2 is a diagrammatic illustration of an exemplary environment in respect of which embodiments of the invention may operate.

[0028] Figure 3 is a flowchart representation of a method of monitoring the health of the subject within the environment according to embodiments of the invention.

[0029] Detailed Description of Embodiments

[0030] Figure 1 is a block diagram of a computer system 100 suitable for the operation of embodiments of the present invention. The system 100 comprises: a storage 102, a processor 104 and an input / output (I / O) interface 106, which are all communicatively linked over one or more communication buses 108.

[0031] The storage (or storage medium or memory) 102 can be any volatile read / write storage device such as a random access memory (RAM) or a non-volatile storage device such as a hard disk drive, magnetic disc, optical disc, ROM and so on. The storage 102 can be formed as a hierarchy of a plurality of different storage devices, including both volatile and nonvolatile storage devices, with the different storage devices in the hierarchy providing differing capacities and response times, as is well known in the art. The processor 104 may be any processing unit, such as a central processing unit (CPU), which is suitable for executing one or more computer programs (or software or instructions or code). These computer programs may be stored in the storage 102. During operation of the system, the computer programs may be provided from the storage 102 to the processor 104 via the one or more buses 108 for execution. One or more of the stored computer programs, when executed by the processor 104, cause the processor 104 to carry out a method according to an embodiment of the invention, as discussed below (and accordingly configure the system 100 to be a system 100 according to an embodiment of the invention).

[0032] The input / output (I / O) interface 106 provides interfaces to devices 110 for the input or output of data, or for both the input and output of data. The devices 110 may include user input interfaces, such as a keyboard 110a or mouse 110b as well as user output interfaces such as a display 110c. Other devices, such a touch screen monitor (not shown) may provide means for both inputting and outputting data. The input / output (I / O) interface 106 may additionally or alternatively enable the computer system 100 to communicate with other computer systems via one or more networks 112. It will be appreciated that there are many different types of I / O interface that may be used with computer system 100 and that, in some cases, computer system 100 may include more than one I / O interface. Furthermore, there are many different types of device 110 that may be used with computer system 100. The devices 110 that interface with the computer system 100 may vary considerably depending on the nature of the computer system 100 and may include devices not explicitly mentioned above, as would be apparent to the skilled person. For example, in some cases, computer system 100 may be a server without any connected user input / output devices. Such a server may receive data via a network 112, carry out processing according to the received data and provide the results of the processing via a network 112.

[0033] It will be appreciated that the architecture of the system 100 illustrated in figure 1 and described above is merely exemplary and that other computer systems 100 with different architectures (such as those having fewer components, additional components and / or alternative components to those shown in figure 1) may be used in embodiments of the invention. As examples, the computer system 100 could comprise one or more of: a personal computer; a laptop; a tablet; a mobile telephone (or smartphone); a television set (or set top box); a games console; an augmented / virtual reality headset; a server; or indeed any other computing device with sufficient computing resources to carry out a method according to embodiments of this invention.

[0034] Figure 2 is a diagrammatic illustration of an exemplary environment 200 in respect of which embodiments of the invention may operate. In particular, figure 2 illustrates a floorplan of a building within which a subject 220 may live. That is to say, the exemplary environment 200 is a domestic environment for the subject 220. However, in other examples, other types of environments may be used.

[0035] The building comprises a plurality of rooms 210. Each of the rooms 210 has one or more ambient sensors 230 associated with it to monitor at least one physical property of the room 210 (or a portion thereof). For example, a first room 210(1 ) has a first sensor 230(1 ) present, a second room 210(2) has a second sensor 230(2) present, a third room has a third and fourth sensors 230(3) and 230(4) present, and a fourth room 210(4) has a fifth, sixth and seventh sensor 230(5), 230(6) and 230(7) present. Of course it will be appreciated that this is simplified example and that it is generally expected that a greater number of ambient sensors 230 will be present within each room (and accordingly within the environment 200 overall). Similarly, it will be appreciated that there may be parts of the environment 200 (indeed potentially entire rooms) that are not covered by any ambient sensors 230 at all. Furthermore, the environment 200 may, in some cases, comprise one or more external sensors (not shown in figure 2) able to measure physical proprieties immediately outside the building (in which case, the environment 200 in which the subject 200 is monitored may encompass some exterior space, such as a garden, in addition to the interior rooms). As examples, the ambient sensors may measure physical properties such as temperature, humidity, atmospheric pressure, air quality, sound (such as sound levels and / or sound recordings), light (such as light levels, photographic and / or videographic recordings), vibration, motion and so on.

[0036] The subject 220 may be associated with one or more personal sensors (not shown in Figure 2). As examples, the personal sensors may detect various physiological and / or behavioural properties of the subject 220, such as heart rate, electroencephalography (EEG), electrocardiography (ECG), body temperature, blood oxygen saturation, weight and so on. In some cases, one or more of the personal sensors may be part of a wearable device which may be worn by the subject 220 for substantially periods of time. Accordingly, measurements from such wearable devices may be available on a continuous or at least regular basis. For example, a smart watch may comprise personal sensor(s) for monitoring the subject’s heart rate. In some cases, one or more of the personal sensors may be part of a standalone medical device. Such standalone devices may require the subject to interact with the device 220 for measurements to be taken. Accordingly, personal sensors in such devices may provide measurements at discrete moments in time whenever the subject 220 interacts with the device. For example, smart scales may comprise personal sensor(s) for monitoring the subject’s weight. It will be appreciated that any suitable personal sensor (of which there are a wide range) may be used and that these may be embedded in any suitable type of device (of which there may be an even wider range).

[0037] Accordingly, between the personal sensors associated with the subject 220 and the ambient sensors 230 there are a plurality of sensors within the environment which may be used to monitor the health of the subject 220. This monitoring may be performed by a health monitoring system 240 which is arranged to receive (or collect) data from the ambient sensors 230 deployed in the environment 200 and / or the personal sensors associated with the subject 220 and provide data to one or more users 250 that are responsible for monitoring the health of the subject 220.

[0038] Although for simplicity, the invention will be described herein in respect of a single subject 220 being monitored within the environment 200, it will be appreciated that in some cases, the invention may be used to monitor multiple subjects 220 may within the same environment 200. For example the environment 200 may be a care home or sheltered accommodation facility. In such cases, the data from the environmental sensors within the environment may be used in conjunction with each subject’s personal sensors to carry out the monitoring for that subject 220.

[0039] Each of the one or more users 250 may be associated with a particular role, which can be used to control access to the different data available through the health monitoring system 240. As examples, users may be associated with roles such as: medical specialist (e.g., cardiologist), general practitioner (e.g., GP), physiotherapist, health researcher and family member. However, it will be appreciated that any appropriate roles may be defined and associated with specific users to control access to data from the health monitoring system 240 based on the differing interests that the users associated with each role may have in the data.

[0040] The health monitoring system 240 may be implemented by a computer system, such as the computer system 100 discussed above, which is configured to run a method according to the present invention. This method will now be discussed in more detail with reference to Figure 3, which is a flowchart representation of a method 300 of monitoring the health of the subject 220 within the environment 200 according to embodiments of the invention.

[0041] The method 300 monitors the health of the subject 220 by using the various sensors 230 that are available within the environment 200 (i.e., the ambient sensors 230 associated with the environment 200 and / or the personal sensors associated with the subject 220). The method 300 may start at an optional operation 310 or, where optional operation 310 is not carried out, at an operation 320.

[0042] At optional operation 310, the method 300 receives an Electronic Health Record (EHR) for the subject 220. The EHR comprises medical data about the subject 220 that may be used by the method 300 to carry out the monitoring. For example, the medical data may include physiological parameters of the subject 220, such as their age, weight and height. The medical data may additionally (or alternatively) include details of any medical conditions experienced by the subject 220 as well as any medicine(s) that has been prescribed to treat those conditions.

[0043] The EHR may also specify the monitoring that is to be performed for the subject 220. In particular, the EHR may indicate which type(s) of health event are to be monitored for (e.g., “High Blood Pressure” events). Accordingly, the method 300 may focus on the monitoring of those type(s) of health event and may ignore other type(s) of health event (e.g., High Blood Pressure events may be monitored whilst Low Blood Pressure events or High Temperature events are ignored, and so on). In some cases, only a single type of health event may be monitored for. In other cases, multiple types of health events may be monitored for. Of course, it will be appreciated, that it is not necessary for the type(s) of health event to be specified in an EHR that is provided to the health monitoring system 240 that is performing method 300. Instead, the health monitoring system may be preconfigured (or otherwise separately configured) with the type(s) of health event that are to be monitored for.

[0044] Having received the EHR (in cases where an EHR is received by the method 300) at operation 300, the method 300 proceeds to operation 320. The use of the EHR will be further discussed in relation to the subsequent operations of the method 300.

[0045] At operation 320, the method 300 detects an occurrence of a health event for the subject 220 (which may also be simply referred to as “a health event”). The health event is detected based on data from at least one of the plurality of sensors that are available within the environment 200. In general, it is expected that personal sensors will be predominantly (or exclusively) used to detect the health event. However, this isn’t strictly necessary, and in some cases, the health event may be detected based (either partly or exclusively) on an environmental sensor. For example, an infrared camera in the environment 200 may allow “high temperature” events to be detected.

[0046] The method 300 may employ any suitable detector to detect the health event. For example, the detector may be a machine learning model may be trained using an appropriate machine learning technique (e.g., by training a neural network to detect the health event based on the available data) to detect occurrences of the health event. Similarly, the detector may be provided through the application of a set of predefined rules by an expert system to detect occurrences of the health event. Furthermore, the detector may utilise either “anomaly-based” detection or “signature-based” detection techniques, as discussed below.

[0047] Anomaly-based detection seeks to detect health events by determining whether the data that has been received from the sensors is “normal” or not. Where the data is abnormal (or “anomalous”), an occurrence of a health event may be considered to be detected. Accordingly, the anomaly-based detection makes use of a “normality model” that embodies knowledge of what is to be considered normal. This normality model may be derived by using machine learning techniques to train a model based on a normal dataset (i.e., data in which anomalies aren’t present) or by specifying an appropriate set of rules for use by an expert system.

[0048] By contrast to anomaly-based detection, signature-based detection is based on specific knowledge of the characteristics of the type of health event that is to be detected. For example, machine learning techniques may be used to generate a model from a dataset that comprises data indicative of a specific type of health event occurring that can then be used to detect future occurrences of that type of health event. Similarly, a set of rules may be generated for use by an expert system to determine whether a particular type of health event has occurred. Again, the signature-based detection may be based on a generic “signature” (i.e. machine learning model or set of rules for detecting occurrences of the health event) of the health event that is generally appropriate for members of a wider population or may be personalised for the subject 220 being monitored (i.e. the specific parameters of the type of health event that the subject 220 is being monitored for). Again, similar to the normality models, the signatures may in the simplest cases be based on a single type of measurement. However, in other cases, multiple types of measurements may be used to account for the multivariate nature of detecting some types of health event.

[0049] In some simple cases, the detection of a health event may be based on a univariate analysis of the available data (regardless of whether anomaly-based detection or signaturebased detection is being used). That is to say, only a single type of measurement may be considered in order to detect the health event. For example, an “anomalous high blood pressure” or “high blood pressure” health event might be detected based solely on measurements of the subject’s blood pressure. However, in other cases, the detection of a health event may be based on a multivariate analysis of the available data. That is to say, multiple different types of measurement may be considered in order to detect the health event. For example, in addition to measurements of the subject’s blood pressure, the detection of a “high blood pressure” health event might be additionally based on data indicating a current activity of the subject 220. Accordingly, a certain level of blood pressure might lead to detection of the health event in some circumstances (e.g., when the subject 220 is at rest) but not in others (e.g., when the subject 220 is exercising). Other factors may also be incorporated into the detection of the health event. For example, temporal factors such as a time at which the health event occurred or a duration for which measurements exceed a predetermined level may also be taken into account. For example, a “high pulse rate” health event might only be considered to have been detected when the measured pulsed rate exceeds a predetermined level for a predetermined period of time (e.g., 30 minutes). As will be appreciated by those skilled in the art, such factors may be either implicitly embodied in a machine learning model by specifying an appropriate set of inputs and training data or may be explicitly specified in rules for use by an expert system.

[0050] The detection of the health events may, in some cases, be generic. That is to say, the detection is not personalised to the specific physiology of the subject 220 but is instead based on the average physiology of a broader population to which the subject 220 belongs. For example, a machine learning model for performing the detection (either a normality model or one trained to detect the signature of a specific health event) may be trained on data from multiple subjects from within the population. Similarly, a set of rules may be defined for use by an expert system to enable detection of the health event based on the typical physiology within the population. Of course, it will be appreciated that generic detection may still take account of the subject’s individual physiology by taking the medical data in the EHR (where one is provided) as an input. Accordingly, the output from a generic detection model may still account for factors such as the subject’s age, weight and height, as well as any medical conditions and / or medicines being used by the subject 220.

[0051] In other cases, however, the detection of the health event(s) may be tailored (or personalised) to the subject 220 being monitored. For example, a machine learning model for performing the detection may be trained on data for the subject 220 or rules for use by an expert system may be tailored to that individual’s physiology and / or the specifics of the health condition being monitored for the in that individual.

[0052] As will be appreciated by those skilled in the art, tailoring a machine learning model or rule set for use by an expert system can be time consuming and expensive. Accordingly, in some cases, a hybrid approach may be used by the health monitoring system 240. Specifically, the health monitoring system 240 may initially use a generic detection technique (whether anomaly-based or signature-based), which may be adapted over time as knowledge about the specific physiology and / or health condition of the subject 220 builds up. For example, whenever an occurrence of a health event is reviewed and determined to have been a false positive (that is, not actually an occurrence of the health event in the subject 220), the model or rule set used for detection may be adjusted accordingly (e.g. by retraining a machine learning model using the new data or adapting the rule set used by an expert system). This approach may be useful as it allows monitoring to begin without incurring the expense and delay of creating a personalised normality model for the subject 220 up front (i.e., before any monitoring is performed).

[0053] The method 300 may, in some cases, be configured to detect a single type of health event (e.g., occurrences of “high blood pressure” events). In such cases, the type of each health event is implicit (they are all of the single type of health event that the method is configured to detect). However, in other cases, the method 300 may be configured to detect many different types of health events. In such cases, a separate detector may be used to detect each different type of health event. Accordingly, each occurrence of a health event may be associated with a respective type of health event to which it relates (e.g., based on which detector detected it). As will be appreciated, any combination of detector types may be used in a health monitoring system 240 that is configured to detect multiple types of health event. That is to say, a mixture of anomaly-based and signature-based detectors may be used. Additionally, or alternatively, a mixture of generic and personalised detectors may be used. However, it will also be appreciated that it is possible to create a machine learning model or set of rules for use by an expert system that may classify the input data into more than one type of health event, such that a single detector may be used to detect occurrences of multiple different types of health events. In such cases, the classification of the data indicates the respective type of health event that has been detected for each occurrence.

[0054] Where an EHR is used, the EHR may additionally include monitoring configuration data for use by the health monitoring system 240 in monitoring the subject. The monitoring configuration data may indicate the types of health event that the subject is to be monitored for. In addition to indicating the types of health event that are to be detected, the monitoring configuration data may also include detector configuration data that can be used to configure a detector to detect occurrences of the health event. For example, the EHR may indicate a set of weights for detecting a particular type of health event. This set of weights may be used to configure a neural network to detect occurrences of that type of health event. Similarly, a set of rules may be indicated by the EHR that can be used to configure an expert system to detect occurrences of that type of health event. Of course, it is not necessary for the EHR to include such monitoring configuration data and, in some cases, the detectors may be configured via alternative means, such as by being preconfigured (e.g. the health monitoring system 240 may comprise a number of preconfigured detectors for detecting different types of health events) or by obtaining their configuration from an alternative source. In some cases, a combination of these approaches may be used, for example the detector for a first type of event may be preconfigured whilst the configuration for a detector for a second type of event is provided by the EHR. This may be useful, for example, when a combination of generic health events and personalised health events are to be monitored for - the generic health events may be detected using preconfigured detectors whilst configuration for the personalised health events may be provided in the EHR.

[0055] In any case, having detected the occurrence of a health event for the subject 220 at operation 320, the method 300 proceeds to an operation 330.

[0056] At operation 330, the method 300 collects data relating to the health event. This data is collected from one or more of the plurality of sensors 230 that are available within the environment 200. In some cases, the data may be collected directly from the sensors 230 themselves. Additionally or alternatively, the data may be collected from one or more datastores (not shown in figure 2) that is configured to store data from the sensors 230.

[0057] As will be appreciated, the amount of data that is available within the environment 200 may be vast. Some of this data may be useful in understanding the wider context surrounding the occurrence of the health event. However, other data may be less relevant, marginally relevant or completely irrelevant to understanding the health event. Accordingly, the method 300 utilises the information about the occurrence of the health event, such as the time and location within the environment at which the health event occurred, as well as the nature (or type) of the health event in order to determine (or select) which data should be collected in order for the occurrence of the health event to be investigated and / or understood more comprehensively. In particular, the method 300 seeks to select the more relevant data that as available from within the environment 200.

[0058] In some cases, the method 300 may determine a window of time from which data should be collected (which will be referred to herein as the “collection window”). The data that is collected in such cases is data associated with points of time within the determined window. Any data associated with points of time outside of the window of time may not be collected. The collection window may comprise a predetermined amount of time prior to the detected start of the occurrence of the health event and / or a predetermined amount of time subsequent to the detected end of the occurrence of the health event. This can help to capture data of relevance in the lead up to the health event and / or during the recovery from the health event. The predetermined amount of time prior and / or subsequent to the health event that is captured may be different for different types of health event. Similarly, a different predetermined amount of time may be captured prior to the event compared to the amount of time captured after the event.

[0059] Additionally, or alternatively, the method 300 may select the sensors from which the data should be collected based on the location of each sensor relative to the occurrence of the health event. For example, the method 300 may identify any sensors 230 that provide data relating to an area of interest encompassing the location(s) of the subject 220 during the time period that the health event was determined to have occurred. Any data that is not associated with a point within the area of interest may not be collected.

[0060] In some cases, this area of interest may, for example, be defined based on the structural boundaries of the environment 200 within which the subject 220 is being monitored. That is to say, for example, the method 200 may identify which room 210 the subject 220 was in when the health event and may collect data from sensors 230 that are associated with that room. With reference to figure 2, as an example, if the health event occurred while the subject 220 was at the illustrated location, the method 300 might identify the fourth room 210(4) as being the area of interest and may collect data from the fifth, sixth and seventh sensors 230(5), 230(6) and 230(7) accordingly.

[0061] In other cases, this area of interest may, for example, be defined as being any points within a predetermined distance of a location of the subject 220 during the health event. The predetermined distance may be dependent on the type of the health event. With reference to figure 2, as an example, if the health event occurred while the subject 220 was at the illustrated location, the method 300 may define an area of interest as a circle (or sphere) of predetermined radius about that location (not shown in figure 2) which encompasses the fifth and sixth sensors 230(5) and 230(6), but not the seventh sensor 230(7) which is also in that room. Accordingly, in this example, the method 300 may collect data from the fifth and sixth sensors 230(6) and 230(6), but ignore the data available from the other sensors, including the seventh sensor 230(7).

[0062] Where the subject 220 moves during the occurrence of the health event, the boundary of the area of interest may, for example, be defined by the locus of points that are a predetermined distance from a route taken by the subject 220 through the environment 200. Similarly, as another example, multiple room(s) may be identified as defining the area of interest in such a case. Returning to figure 2, as an example, if the subject 220 has moved from the third room 210(3) through the first room 210(1 ) to the fourth room 210(4) during the occurrence of the health event, then the area of interest may be considered to include the first, third and fourth rooms. Accordingly, in that example, data may be collected from the first, third, fourth, fifth, sixth, and seventh sensors 230(1), 230(3), 230(4), 230(5), 230(6) and 230(7).

[0063] Although the sensors 230 are illustrated as being associated with a specific location, it will be appreciated that at least some of these sensors may be associated with an area of coverage. That is to say, each sensor 230 may be able to monitor a physical property of the environment 200 within a certain area. Accordingly, in some cases, data may be collected by method 300 at operation 330 from any sensors 230 for which the associated area of coverage overlaps with the area of interest.

[0064] It will also be appreciated that where a window of time over which data should be collected has been defined (as discussed above), the area of interest may be defined with reference to the subject’s location over that window time and not just during the detected occurrence of the health event. That is to say, the area of interest may be defined based on the subject’s locations during the predetermined amount of time prior to the detected start of the occurrence of the health event and / or the predetermined amount of time subsequent to the detected end of the occurrence of the health event.

[0065] Additionally, or alternatively the method 300 may select the sensors from which the data should be collected based on the type of data available from each sensor. In such cases, there may be a predetermined association as to which types of data are relevant for providing context to each type of health event. For example, it may be predetermined that “room temperature” data and “air quality” data are types of data that would be useful context for a “high heart rate” event. The method 300 may then identify which sensors 230 provide relevant data for the health event and collects the data from those sensors 230. The method 300 may ignore the data that is available from other sensors 230. Continuing the previously discussed example, the fifth and sixth sensors 230(5) and 230(6) may provide types of data which is predetermined as being relevant to the type of health event (e.g. they may be a “room temperature” sensor and an “air quality” sensor), whilst the seventh sensor 230(7) may provide a type of data which is not predetermined as being relevant to the type of health event (e.g. it may be an “audio” sensor). Accordingly, in that example, the method 300 may collect the data from the fifth and sixth sensors 230(5) and 230(6) and not collect any data from the seventh sensor 230(7). As will be appreciated, the above techniques can be combined in any suitable manner. For example, in some cases, all three techniques may be used together. That is to say, the method 300 may define a time window for which the data should be collected, an area of interest for which the data should be collected and select sensors 230 from within that area of interest based on the types of data provided by those sensors 230.

[0066] Where an EHR is used with the method 300 (i.e., where an EHR is received at operation 310, as described above), the EHR may indicate data collection parameters for instructing the method 300 to collect the data at operation 330. For example, the EHR may specify the predetermined amount of time to be used when determining a collection window (i.e. the amount of time prior to the detected start of the occurrence that is to be included in the collection window and / or a predetermined amount of time subsequent to the detected end of the occurrence of the health event that is to be included in the collection windows) for one or more, or all, of the types of health event that are to be detected. Similarly, the EHR may (additionally or alternatively) indicate how the area of interest (as discussed above) should be determined for one or more, or all, of the types of health event that are to be detected. For example, the EHR may specify the predetermined distance from the location of the subject 220 from which data should be collected during an occurrence of a health event of a particular type. Similarly, the EHR may (additionally or alternatively) indicate what types of data are contextually relevant to one or more, or all, of the types of health event that are to be detected.

[0067] Through the collection of data from the available sensors 230 in the environment 200, the method 300 gathers data about the health event that provides context for the occurrence of the health event. Indeed, through the techniques discussed above, the data that is collected can include data from one or more sensors that were not used to detect the occurrence of the health event (i.e. sensors which provide data about physical properties of the environment and / or physiological (and / or behavioural) properties of the subject 220 which is not directly related to the health event). In any case, having collected the data at operation 330, the method 300 may proceed to an optional operation 340 or, if optional operation 340 is not carried out, the method 300 proceeds to an operation 350.

[0068] At optional operation 340, the method 300 the method may further process the collected data to generate processed data. This processing may reduce some or all of the collected data into processed data which may be provided to the user 250 (at operation 350) instead of some or all of the data that was collected. For example, temperature data at each of a plurality of time points during the occurrence of the health event may be processed to provide an average temperature during the occurrence of the health event. As a further example, a plurality of data series from motion sensors, such as gyroscopes, attached to the users may be processed (or classified) to determine an activity of the user (e.g. sitting, sleeping, walking, exercising, etc.) and this activity may be provided to the user 250 instead of (or in addition to) the data series from the motion sensors. The skilled person will appreciate that any suitable form of further processing may be carried out on the collected data during operation 340. Having carried out any processing during operation 340, the method 300 proceeds to operation 350.

[0069] At operation 350, the method 300 provides the collected data to a user 250. The collected data can then be presented to the user 250 to allow the user 250 to gain an understanding of the health event(s) that have occurred for the subject 220.

[0070] In some cases, the method 300 may notify the user 250 of the occurrence of the health event at the time that it is detected (or at least soon after). This can allow the user 250 to review the collected data shortly after a health event occurs and potentially provide assistance to the subject 220 in a timely manner. As will be appreciated, the notification of the occurrence of a health event may be dependent upon the role of a user 250. For example, users having a first role might be notified of occurrences of health events whilst users having a second role might not be. Similarly, the notification of the occurrence of a health event may be dependent upon the type of the health event. For example, notifications may be issued for occurrences of a first type of health event but may not be issued for occurrences of a second type of health event. These two approaches may, in some cases, be combined, such that the notifications are dependent on both the role of the user and type of the health event.

[0071] In addition, or as an alternative to the use of notifications, the method 300 may provide the user 250 with an index of health event occurrences that have been detected. That is to say, the data associated with each occurrence of a health event may be stored by the health monitoring system 240 (or by another system accessible by the health monitoring system 240) and provided to a user 250 in response to a request for data associated with that occurrence of the health event. This can enable the user 250 to review historical events that have occurred for the subject 220. Therefore, in such cases, rather than providing the data directly to the user 250 shortly after its collection, the method 300 may instead store the collected data for provision to the user 250 at a later point in time.

[0072] In some cases, the method 300 may provide the collected data to the user 250 through the use of a virtual environment (e.g., the metaverse). That is to say, the method 300 may use the collected data to provide a graphical reconstruction of the occurrence of the health event within a virtual representation of the subject’s environment 200 during the occurrence of the health event based on the collected data. In other words, the collected data may be used to configure virtual model(s) (or digital twins) of the environment 200, the subject 220 and any other object(s) of note within the environment to reflect their respective configurations at the time of (and during) the health event. This may improve the user’s ability to understand and investigate the health event. Where such virtual model(s) are used, an EHR may be associated with the subject’s digital twin in the virtual environment. Accordingly, in such cases, the method 300 may be able to access the EHR (i.e., at operation 310) from the subject’s digital twin.

[0073] Of course, it will be appreciated that any other suitable techniques for providing the collected data to the user 250 may be used instead. In any case, having provided the data to the user 250 (or stored it for provision to the user 250 at a later point in time), the method 300 proceeds to an operation 360.

[0074] At operation 360, the method 300 determines whether the monitoring should continue. If it is determined the monitoring should be continue, the method 300 reiterates to operation 320 and repeats operations 320-360 in relation to any further occurrences of health events that are detected. Otherwise, the method 300 ends. As will be appreciated, it is generally expected that the method 300 will be run continuously to detect all occurrences of health events for the subject 220 as and when they arrive. In such cases, it may be determined at operation 360 that the method 300 should continue monitoring unless some form of “shutdown” or “stop” signal is received. This “shutdown” or “stop” signal may be manually provided by a user of the health monitoring system 240. In other cases, the monitoring may stop at a predetermined point in time or after a predetermined amount of time has elapsed. In such cases, a timer may be set which issues the “shutdown” or “stop” signal at the appropriate time. Alternatively, the method 300 may determine at operation 360 whether the predetermined point in time has been reached or the predetermined amount of time has elapsed when determining whether to continue processing. In other cases, the method 300 may simply continue until a predetermined number of occurrences of a health event have occurred. In the simplest case therefore, where the predetermined number of occurrences is one, a single iteration of method 300 may be performed. Similarly, the “shutdown” or “stop” signal may be issued in response to a certain condition being detected based on the sensor data from the environment 200.

[0075] As will be appreciated from the foregoing description of the invention, the method 300 may operate to detect occurrences of health events for a subject 220 within an environment substantially in real time. That is to say, data may be collected for occurrences of health events as they occur. However, it is also possible for the invention to operate in a retrospective (or historical) manner. In particular, historical data from the sensors 230 within the environment may be available. For example, one or more data stores (not shown in figure 2) may operate locally within the environment 200 to maintain a historical record of the sensor data for the environment 200. Similarly, historical data from the personal sensors may also be available. For example, historical data for personal sensors may be stored on the device in which the sensor is contained, in a data store locally within the environment 200 or in a data store externally from the environment 200, such as in the cloud. In such cases, the invention may carry out the steps of the method 300 in respect of this historical data instead. For example, a medical professional investigating the subject’s medical condition may be interested in historical instances of a particular type of health event. In such cases, the method 200 may iterate over the historical data to detect occurrences of that health event (as discussed in relation to operation 320 above), collect data for each occurrence of the health event (as discussed in relation to operation 330 above) from the data store(s), optionally process that data (as discussed in relation to operation 340 above), and ultimately provide that data to the medical professional in their capacity as the user 250 of the system 240 - for example, by providing an index of detected occurrences of the health event from the available historical data and providing the data for each occurrence in response to a request from the user 250 for the data associated with that occurrence.

[0076] As noted earlier, where the system is used by multiple users 250 to monitor the subject 220, the invention may employ Role-Based Access Control to limit access to the data to that which is appropriate for each user 250 according to their associated role. In such cases, the collection and / or provision of data to the user (at operations 330 and 350 respectively), may be based on the role associated with the user 250 on behalf of which the data is being collected and / or provided to. Furthermore, the processing of the data (at operation 340) may also be based on the role of the user 250. This processing may serve to summarise the data (e.g., by providing an average of the data, or by categorising the data into a fixed number of categories) to a level appropriate for that user’s 250 legitimate purposes in a way that obscures other details that are not needed.

[0077] Although the foregoing description has focussed on the monitoring of a subject in a medical context - that is to say, in a context in which the subject is a human. It is also envisaged that the invention could equally be employed to monitor the health of a machine. For example, the environment 200 may be a factory or warehouse and the subject may be an industrial machine. Such a machine may be static or mobile (e.g. an autonomous vehicle or drone). In such cases, the “personal sensors” may be sensors associated with the machine (e.g. embedded sensors within the machine) for monitoring the machine’s operation. Similarly, the “health event” in such cases may be a fault condition for the machine in which the machine is no longer able to operate normally. It will be appreciated that, as in the medical context discussed above, many different types of fault condition may exist for a machine and similar techniques to those discussed above (e.g. the use of anomaly-based and / or signature-based techniques) may be used to detect occurrences of each type of fault condition. In such cases, a monitoring system operating according to the invention may be deployed to monitor the machine by detecting occurrences of a fault condition and collecting contextual data from the available sensors (e.g. embedded and / or environmental sensors) relating to the occurrences of the fault condition (in a similar manner to that described above in the medical context). It will be appreciated that similar techniques for selecting the data that should be collected may be used (as described above for the medical context). This contextual data may be provided to a user of the monitoring system to improve the user’s understanding and / or analysis of the fault condition of the machine.

[0078] Insofar as embodiments of the invention described are implementable, at least in part, using a software-controlled programmable processing device, such as a microprocessor, digital signal processor or other processing device, data processing apparatus or system, it will be appreciated that a computer program for configuring a programmable device, apparatus or system to implement the foregoing described methods is envisaged as an aspect of the present invention. The computer program may be embodied as source code or undergo compilation for implementation on a processing device, apparatus or system or may be embodied as object code, for example. Suitably, the computer program is stored on a carrier medium in machine or device readable form, for example in solid-state memory, magnetic memory such as disk or tape, optically or magneto-optically readable memory such as compact disk or digital versatile disk etc., and the processing device utilises the program or a part thereof to configure it for operation. The computer program may be supplied from a remote source embodied in a communications medium such as an electronic signal, radio frequency carrier wave or optical carrier wave. Such carrier media are also envisaged as aspects of the present invention. It will be understood by those skilled in the art that, although the present invention has been described in relation to the above-described example embodiments, the invention is not limited thereto and that there are many possible variations and modifications which fall within the scope of the invention. The scope of the present invention includes any novel features or combination of features disclosed herein. The applicant hereby gives notice that new claims may be formulated to such features or combination of features during prosecution of this application or of any such further applications derived therefrom. In particular, with reference to the appended claims, features from dependent claims may be combined with those of the independent claims and features from respective independent claims may be combined in any appropriate manner and not merely in the specific combinations enumerated in the claims.

Claims

CLAIMS1 . A computer-implemented method of monitoring the health of a subject within an environment using a plurality of sensors, the method comprising: detecting an occurrence of a health event for the subject based on data from at least one of the plurality of sensors; collecting data relating to the health event from one or more of the plurality of sensors based on the occurrence of the health event and a type of the health event; and providing data relating to the health event to a user.

2. The method of claim 1 , wherein collecting the data relating to the health event comprises determining a window of time during which the health event occurred and collecting data from the one or more sensors that is associated with the window of time.

3. The method of any one of the preceding claims, wherein collecting the data relating to the health event comprises selecting the one or more sensors from which the data is to be collected based on their relationship to a location of the subject during the occurrence of the health event.

4. The method of any one of the preceding claims, wherein collecting the data relating to the health event comprises selecting the one or more sensors from which the data is to be collected based on a respective type of data available from each sensor, wherein the respective type of data available from each of the one or more sensors matches a predetermined type of data that is considered to be relevant to that type of health event.

5. The method of any one of the preceding claims further comprising processing the collected data to generate processed data, wherein the data provided to the user comprises the processed data.

6. The method of any one of the preceding claims, wherein the data relating to the health event that is provided to the user is derived from the collected data based on a role associated with the user.

7. The method of any one of the preceding claims further comprising: notifying the user of the occurrence of the health event.

8. The method of any one of the preceding claims, wherein the plurality of sensors comprise: one or more personal sensors associated with the subject; and one or more ambient sensors associated with the environment.

9. The method of any one of the preceding claims, wherein the one or more sensors from which the data is collected comprises at least one sensor that was not used to detect the occurrence of the health event.

10. The method of any one of the preceding claims, further comprising: receiving an electronic health record for the subject, the electronic health record comprising medical data about the subject, wherein the detection of the occurrence of the health event is further based on the medical data about the subject.11 . The method of claim 10, wherein the type of the health event is one of one or more types of health events indicated in the electronic health record.

12. The method of claim 11 , when dependent on claim 4, the electronic health record further indicating, for each type of health event, a respective set of predetermined types of data that are relevant to that type of health event, wherein the respective type of data available from each of the one or more sensors is a member of the set of predetermined types of data indicated by the electronic health record.

13. The method of any one of the preceding claims, wherein providing the collected data to the user comprises providing a graphical reconstruction of the occurrence of the health event within a virtual representation of the subject’s environment during the occurrence of the health event based on the collected data.

14. A computer system comprising a processor and a memory storing computer program code for performing the steps of any one of claims 1 to 13.

15. A computer program comprising instructions which, when executed by a computer, cause the computer to carry out the method of any one of claims 1 to 13.

Images